Messages in this thread |  | | Date | Mon, 18 Sep 2000 17:22:01 -0700 | From | "David S. Miller" <> | Subject | Re: [PATCH] Re: SCSI scanning |
| |
Date: Mon, 18 Sep 2000 15:58:02 -0700 (PDT) From: Linus Torvalds <torvalds@transmeta.com>
The SCSI stuff is pretty straightforward, and it works for me (and I also built a kernel with all regular x86-capable SCSI drivers included, so the others got at least that level of testing). But there are some non-x86 scsi drivers out there etc, so give it a whirl.
Did you try to boot these kernels containing scsi devices you don't have? I don't see how it could work (actually I do, see below).
Look at drivers/scsi/scsi.c:scsi_unregister_host, near the end we have code like this:
if (tpnt->present) return;
...
remove_proc_entry(tpnt->proc_name, proc_scsi);
Compare this to the code in scsi_register_host which explicitly does not create the procfs nodes if tpnt->present == 0.
Is this another case of ix86 not trapping NULL pointer derefernces during bootup? I got it on Sparc in strlen of tpnt->proc_name as a result of this remove_proc_entry() call. Is there some way to make ix86 start trapping on NULL pointers earlier in the boot sequence so these kinds of bugs don't live very long?
Anyways, the code at the end of scsi_unregister_host should rather be something like:
if (tpnt->present) { remove_proc_entry(tpnt->proc_name, proc_scsi); return; }
...
Later, David S. Miller davem@redhat.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |