Hi Phil,
Phillip Ezolt wrote:
> Hi All,
>
> Qlogic SCSI support seems broken on 2.4.0-test11 on a Miata (Digital Personal WorkStation 600au).
>
> When starting up, we get a machine check after initialing the qlogic SCSI code.
>
> Using the Alpha kgdb, we figured out that the code is dying in scsi_wait_request().
Wow, I'm impressed! I didn't realize that kgdb worked on Alpha...Were
you using the remote kgdb? (You can answer me offline to save
bandwidth.) This would be a _huge_ help in trying to figure out why my
Wildfire^WGS160 is crashing with the DISCONTIGMEM code that I stole from
Jay and have been hacking on.
Speaking of that system, it has two QLogic adapters in it (both 1040Bs,
like the Miata), and they are working just fine under 2.4.0-test11
(obviously, without my changes ;). It looks like it's probably the
platform code that's busted. I can't remember...are those Pyxis or
CIA? Anyway, could this have something to do with the PCI & PCI bridge
work that Richard and Ivan just submitted?
- Pete
>
> Here's the backtrace:
>
> scsi_wait_req (SRpnt=0xfffffc0001f9b480, cmnd=0xfffffc890000a078,
> buffer=0x100, bufflen=2, timeout=17891584, retries=6144)
> at /usr/src/linux/include/asm/atomic.h:85
> (gdb) where
> #0 scsi_wait_req (SRpnt=0xfffffc0001f9b480, cmnd=0xfffffc890000a078,
> buffer=0x100, bufflen=2, timeout=17891584, retries=6144)
> at /usr/src/linux/include/asm/atomic.h:85
> #1 0xfffffc00004107f0 in scan_scsis_single (channel=0, dev=41080, lun=0,
> max_dev_lun=0xfffffc00001efa30, sparse_lun=0xfffffc00001efa34,
> SDpnt2=0xfffffc00001efa38, shpnt=0xfffffc00005ff800,
> scsi_result=0xfffffc00001ef930 "\001") at scsi_scan.c:516
> #2 0xfffffc0000410548 in scan_scsis (shpnt=0xfffffc00005ff800, hardcoded=1,
> hchannel=0, hid=0, hlun=0) at scsi_scan.c:403
> #3 0xfffffc0000404f58 in scsi_register_host (tpnt=0xfffffc000058fb80)
> at scsi.c:1904
> #4 0xfffffc00004dac50 in init_this_scsi_driver ()
> #5 0xfffffc00004c2bec in do_initcalls ()
> #6 0xfffffc00004c2c6c in do_basic_setup ()
> #7 0xfffffc0000310078 in init (unused=0x0) at init/main.c:775
>
>
> Note: On the working kernels, the two controllers are 0x800 apart, but
> on the broken kernels, they are only 0x400. Could the overlap
> cause problems?
>
>
-
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/
This archive was generated by hypermail 2b29 : Thu Nov 30 2000 - 21:00:25 EST