Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1279151

Re: 4.3+: Atheros ethernet fails after resume from s2ram, due to order 4 allocation

From Pavel Machek <pavel@ucw.cz>
Newsgroups linux.kernel
Subject Re: 4.3+: Atheros ethernet fails after resume from s2ram, due to order 4 allocation
Date 2015-11-28 16:00 +0100
Message-ID <qzP8K-1HY-17@gated-at.bofh.it> (permalink)
References <qz7Kq-7Fr-23@gated-at.bofh.it> <qzmzL-lM-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi!


> >         /*                                                                      
> >          * real ring DMA buffer                                                 
> >          * each ring/block may need up to 8 bytes for alignment, hence the      
> >          * additional bytes tacked onto the end.                                
> >          */
> >         ring_header->size = size =
> >                 sizeof(struct atl1c_tpd_desc) * tpd_ring->count * 2 +
> >                 sizeof(struct atl1c_rx_free_desc) * rx_desc_count +
> >                 sizeof(struct atl1c_recv_ret_status) * rx_desc_count +
> >                 8 * 4;
> > 
> >         ring_header->desc = pci_alloc_consistent(pdev, ring_header->size,
> >                                 &ring_header->dma);
> 
> Why is pci_alloc_consistent doing an unconditional GFP_ATOMIC
> allocation? atl1_setup_ring_resources already does GFP_KERNEL
> allocation in the same function so this should be sleepable
> context. I think we should either add pci_alloc_consistent_gfp if
> there are no explicit reasons to not do so or you can workaround

There's existing interface "dma_alloc_coherent" which can be used.

I did not yet try with __GFP_REPEAT, but GFP_KERNEL should already be
big improvement.

Let me send a patch..
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

4.3+: Atheros ethernet fails after resume from s2ram, due to order 4  allocation Pavel Machek <pavel@ucw.cz> - 2015-11-26 17:40 +0100
  Re: 4.3+: Atheros ethernet fails after resume from s2ram, due to  order 4 allocation Francois Romieu <romieu@fr.zoreil.com> - 2015-11-26 23:00 +0100
  Re: 4.3+: Atheros ethernet fails after resume from s2ram, due to  order 4 allocation Michal Hocko <mhocko@kernel.org> - 2015-11-27 09:30 +0100
    [PATCH] Improve Atheros ethernet driver not to do order 4 GFP_ATOMIC  allocation Pavel Machek <pavel@ucw.cz> - 2015-11-28 16:00 +0100
      Re: [PATCH] Improve Atheros ethernet driver not to do order 4  GFP_ATOMIC allocation Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> - 2015-11-29 23:00 +0100
      Re: [PATCH] Improve Atheros ethernet driver not to do order 4  GFP_ATOMIC allocation Michal Hocko <mhocko@kernel.org> - 2015-11-30 14:30 +0100
    Re: 4.3+: Atheros ethernet fails after resume from s2ram, due to  order 4 allocation Pavel Machek <pavel@ucw.cz> - 2015-11-28 16:00 +0100

csiph-web