Messages in this thread | | | Date | Sun, 04 Oct 2009 20:58:48 -0700 (PDT) | Subject | Re: [bisected] 2.6.31 regression sis5513 PIO Mode 0 hang | From | David Miller <> |
| |
From: David Fries <david@fries.net> Date: Sun, 4 Oct 2009 21:55:50 -0500
> First, if I'm going to do much debugging, how would I force the > ethernet device to come up first so I have netconsole? > > How is the problem patch, > + ide_port_for_each_dev(i, drive, hwif) { > + if (port_ops && port_ops->set_pio_mode) > + port_ops->set_pio_mode(drive, 0); > + } > > Different from using hdparm to set the mode? I do this, > hdparm -p 0 /dev/hda > hdparm -X pio0 /dev/hda > and the benchmarks give me about what I would expect 7MB/s instead of > the normal 40MB/s. > > Then I can re-enable with, > hdparm -p 4 /dev/hda > hdparm -X udma5 /dev/hda > hdparm -d 1 /dev/hda > hda: UDMA/100 mode selected > and the drive is back up to speed, and obviously the kernel didn't > freeze. Should there be anything different between what the patch > tried, and and hdparm's doing, other than kernel initiated and start > and a user program later on?
From your original hang trace I can only guess that the problematic sequence is putting your CDROM into PIO0, then putting it into PIO4, and then immediately reading the TOC.
This is what the ide-cd.c code does right about where you get the hang.
Debugging this further is really totally pointless for a subsystem that should be in deep maintainence mode, so I'm just going to revert.
Thanks.
| |