Bug 9156
Summary: | IDE DMA <-> CPU HLT <-> EHCI-HCD | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Helmut (bgrpt) |
Component: | IDE | Assignee: | io_ide (io_ide) |
Status: | CLOSED WILL_NOT_FIX | ||
Severity: | normal | CC: | alan |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.23 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | Patch to solve the problem (bootparameter disableviahlt) |
Description
Helmut
2007-10-13 02:49:02 UTC
Created attachment 13142 [details]
Patch to solve the problem (bootparameter disableviahlt)
Some current comparisons with patch without boot 38sec 39sec suspend-resume with small memory footprint 10 13 suspend-resume with bigger memory footprint 15 20 Thanks for brining this back (it is one of the problems that has slipped through the cracks while I was on hiatus). Overall the patch direction is good but there are still some issues to be investigated: * We should _really_ make the code detect the affected VIA host bridge chipset and apply the needed quirk without the need for user intervention (most users won't know about the boot parameter, also people would try it for the unrelated IDE problems). * Workaround code belongs to via82xxx host driver and not core IDE code (additional bonus would be that it becomes easy to port the fix later to libata :). * I don't remember the details of the discussion - did we go anywhere with trying to disable "HALT Command Detect" bit? [ http://www.rhcf.com/sis-bin/ultimatebb.cgi?ubb=get_topic;f=7;t=000078;p=0 ] If this works it would be much better solution over disabling HLT globally. Could you look into the above issues and post the revised patch version to linux-ide@vger.kernel.org? If you run into some problems don't hesitate to send a mail anyway - nowadays there are many knowledgeable people hanging on linux-ide@ which should be able help. Thank you for your reply. * I'm not a big kernel hacker so only a bit of C and lot of luck revealed the solution to me, in short, at the moment I've no clue how to implement the chipset detection. * ??? You say the fix should be placed somewhere else? * Yes we did: http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg40926.html >"VIA Apollo KT266/A/333" but RxD2 & RxD5 (the one from the VIA KT333CF) >are used instead of Rx92 and Rx95. Setting them by setpci as described in >http://www.daniel.nofftz.net/linux/Athlon-Powersaving-HOWTO.html >works also as expected. ATM I'm bit short on time until at least 1.1.2008 so if it isn't of priority: I need some information where to look for the above. otherwise it would be great if someone else can look into it (Be sure I'll do background jobs like compiling/testing if needed till then.) Alan, there is enough data about this issue. We just need somebody with some time at hand to review previous discussions and prepare final patch version. Well it was last touched in 2007 Doing a drive-by rejection of valid open bugreports without checking the current status is not going to improve the situation a tiny bit. OTOH help is welcomed. This should really not be assigned to IDE subsystem, as what seems like is needed is some kind of chipset-specific PCI quirk. Disabling halt only during IDE transfers is likely no good solution since other DMA accesses can occur at any time, often without prior kernel knowledge, and are likely also affected. The chipset settings likely need to be fixed to not get into this busted state. |