Messages in this thread | | | Date | Tue, 12 Feb 2013 18:29:35 +0000 (UTC) | From | "Artem S. Tashkinov" <> | Subject | Re: Abysmal HDD/USB write speed after sleep on a UEFI system |
| |
Feb 12, 2013 11:30:20 PM, Linus Torvalds wrote: >On Mon, Feb 11, 2013 at 10:25 PM, Artem S. Tashkinov wrote: >> Hello Linus, >> >> I 've already posted a bug report (https://bugzilla.kernel.org/show_bug.cgi?id=53551), >> a message to LKML (http://lkml.indiana.edu/hypermail/linux/kernel/1302.1/00837.html) >> and so far I 've received zero response even though the bug is quite critical as it prevents >> me from using suspend altogether. >> >> I wonder if you could tell me who is responsible for this problem and who I need to CC in >> bugzilla. > >According to your bugzilla it doesn 't really seem to be strictly >UEFI-specific, and it 's hard to tell what subsystem is to blame. > >A few things to try to pinpoint: > > (a) Is it *only* write performance that suffers, or is it other >performance too? Networking (DMA? Perhaps only writing *to* the >network?)? CPU?
I've tested hdpard -tT --direct and the output on boot and after suspend is quite similar.
I've also checked my network read/write speed, and it's the same ~ 100MBit/sec (I have no 1Gbit computers on my network unfortunately).
> > (b) the fact that it apparently happens with both SATA and USB >implies that it 's neither, and is more likely something core like >memory speed (mtrr, caching) or PCI (DMA, burst sizes, whatever).
I've no idea, please, check my bug report where I've just added lots of information including a diff between on boot and after suspend.
lspci outputs differ quite substantially, but the things that have change say nothing to me - you'll want to see it for yourself. I see changes like:
- Changed: MRL- PresDet- LinkState- + Changed: MRL- PresDet+ LinkState-
i.e. PresDet minus to PresDet plus.
- Address: 00000000fee0f00c Data: 41e1 + Address: 0000000000000000 Data: 0000
- Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- TAbort- > (c) can you find anything that changes over the suspend/resume? IOW, >look at things like "lspci -vvxxx" before-and-after, and see what >changed on the bridges leading to both things etc. > >The performance drop sounds extreme enough that it sounds like caches >got disabled or something, but that should show up as CPU performance >in general being slow, not just writes to disk. But basically, I think >we need more clues about which sub-area is actually the culprit. My >*guess* would be some core PCI thing not being initialized, but I >don 't see how you could even make PCI go that slow. Interrupt >problems? DMA failures? I have no idea. > >Has it ever worked? Suspend on desktop motherboards used to be quite >spotty (nobody ever used it, manufacturers didn 't care), but it >generally has gotten better since people use it more these days..
I remember it used to work before, but I've never suspended more than once during one boot session before (this time I did it out of pure curiosity) and I've never run Linux from UEFI.
> >Added lkml and Bjorn to the participants, in case anybody has any ideas.. >
I'll gladly provide any information you need.
Thanks a lot,
Artem
| |