On a related note, using bootup autotuning with PIIX support under
2.3.5 (by providing an "ide0=autotune" boot argument) will cause an
Oops.
The culprit is the "ide_wait_cmd()" call at the end of
"piix_tune_drive()". The code in "ide-probe.c" that does bootup
autotuning calls the interface's "tuneproc" before "init_irq()" (which
assigns the drive to an "hwgroup") has been called. Therefore, the
drive's "hwgroup" is still NULL, and after the call trace
ide_wait_cmd->ide_do_drive_cmd->do_hwgroup_request, we crash when we
try to lock on the "&hwgroup->spinlock".
Moving the bootup autotuning in "ide-probe.c" so it occurs after
"hwgroup" assignment doesn't help. We get a little further, but in
"start_request" the sector range check fails at:
if ((blockend < block) || (blockend > drive->part[minor&PARTN_MASK].nr_sects))
because the partition table hasn't been loaded.
I'm not sure what the best solution is. We could work around the
problems by, respectively, checking for a NULL "hwgroup" and skipping
the range check when the start and end sectors are zero. However, the
real fact is that the kernel isn't ready for an "ide_wait_cmd()" call
this early in the boot process.
Does anyone have any insight? Should bootup autotuning be delayed
until after the partition tables have been read and the kernel is
ready to handle "ide_wait_cmd()"s normally? Would this break anything
else? Or should bootup autotuning be abandoned altogether?
Kevin Buhr <buhr@stat.wisc.edu>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/