[PATCH] 2.5.14 IDE 56
- Push poll_timeout down from the hwgroup to the channel. We are resetting the channel and not a whole hwgroup. This way using multiple pdc202xxx cards should magically start to work with multiple performance and resets will no longer lock the system. - Updates for PDC4030 by Peter Denison <peterd@marshadder.uklinux.net>. - Make ide_raw_taskfile don't care about request buffers. They where always NULL. - Port set multi mode count over from the special setting interface to ide_raw_taskfile. Fix errors in the corresponding interrupt handler in one go as well. It turned out that this is precisely the same code as in task_no_data_intr, so we can nuke it altogether. And finally we have found some problems with the set_pio_mode() command which can fail with -EBUSY - this is in esp. probably *very* common during boot hdparm usage those days! (OK it was masked by reportig too early that it finished... Crap Crap utter crap it was!!!) Right now hdparm should just be extendid to properly sync and retry on -EBUSY and everything should be fine. And now the 1 Milion EUR question for everybody who loves to put driver settings in to /proc: How the hell could echo > /proc/ide/ide0/settings blah blah blah blah handle properly cases like -EIO, -EBUSY and so on??? Having the possibility o do it does not mean that it is a good idea to use it. OK. After realizing the simple fact that quite a lot of low level hardware manipulating ioctls may require assistance in usage from proper logic which is *very* unlikely to be implemented in a bash (for me preferable still ksh) I have made my mind up. /proc/ide will be nuked. - Execute the recalibration for error recovery on precisely the same request as the one which failed. - Remove set geometry. It's crap by means of standard specification. Because: 1. We rely on the existence of the identify command anyway. 2. This command was obsoleted *before* the identify command existed as far as I can see. 2. I'm able to have a look at what other ATA/ATAPI drivers in the wild do: They don't do it. - Just call tuneproc in set_pio_mode() directly - we are already behind the rq queue there. - After we have uncovered the broken logics behind the whole ioctl handling we now just have made ide_spin_wait_hwgroup() waiting for a proper somehow longer timeout before giving up. This was previously just hiding the broken concept of setting ioctl values through /proc/ide/ideX/settings - now it just really helps hdparm to not to give up too early. (It shouldn't probably play wreck havock on the global driver spin lock as well. I will look in to this later.) - Scrap the non necessary, to say the least, disabling of interrupts for 3, read it again please, 3 seconds, on the local CPU inside ide_spin_wait_hwgroup(). Spin lock handling needs checking there badly as I see now as well... Hey apparently any "special" requests are gone. We now have only to deal with REQ_DEVICE_ACB and REQ_DEVICE_CMD. One of them is still too much and will be killed.
Showing
Please register or sign in to comment