On Mon, Nov 20, 2000 at 03:03:03AM +0100, Malte Cornils wrote:
> my Dawicontrol 2974 SCSI-adapter fails with kernel 2.4.0-test10
> with pre-11 and reiserfs for kernel test-10 patched in:
>
> --
> Nov 20 01:30:23 wh36-b407 kernel: scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 Read (10) 00 00 08 c0 6c 00 00 f8 00
> Nov 20 01:30:23 wh36-b407 kernel: DC390: Abort command (pid 0, DCB c12c11c0, SRB 00000000)
> Nov 20 01:30:23 wh36-b407 kernel: DC390: Status of last IRQ (DMA/SC/Int/IRQ): 0890cc20
> Nov 20 01:30:23 wh36-b407 kernel: DC390: Register dump: SCSI block:
> Nov 20 01:30:23 wh36-b407 kernel: DC390: XferCnt Cmd Stat IntS IRQS FFIS Ctl1 Ctl2 Ctl3 Ctl4
> Nov 20 01:30:23 wh36-b407 kernel: DC390: 000000 44 10 cc 00 80 17 48 18 04
> Nov 20 01:30:23 wh36-b407 kernel: DC390: Register dump: DMA engine:
> Nov 20 01:30:23 wh36-b407 kernel: DC390: Cmd STrCnt SBusA WrkBC WrkAC Stat SBusCtrl
> Nov 20 01:30:23 wh36-b407 kernel: DC390: 80 00001000 051a4000 00000000 051a5000 00 03080000
> Nov 20 01:30:23 wh36-b407 kernel: DC390: Register dump: PCI Status: 0200
> Nov 20 01:30:23 wh36-b407 kernel: DC390: In case of driver trouble read linux/drivers/scsi/README.tmscsim
> Nov 20 01:30:23 wh36-b407 kernel: DC390: Aborted pid 0 with status 0
pid 0: So, already the device scan fails?
I'll have to look up the register dump to analyze it. Would you test the
patch I sent you on top of 2.0e5, please?
> This happened on the second bootup with the new kernel, when kdm
> was starting Xfree 4.0.1 from Debian woody.
> Nov 20 01:29:34 wh36-b407 kernel: Bad boy: tmscsim (at 0xc02bf732) called us without a dev_id!
Fixed in 2.0eX, BTW.
> I noted there's a new version of the driver on the maintainer's (Kurt
> Garloff) homepage, but last time I tested it and reported an oops with
> 2.4.test-something he didn't reply at all (that's not an offense, it's
> understandable with the amount of work he's doing for KDE2 etc).
I tend to answer mails, where I know a solution very quickly, but tend to
not send messages like "Thanks I got your mail, I'll look into it!"
Actually, when I got some time to do some work, I look for yet unanswered
mails.
> So should I
> a) try with his patch again; my oops report for that is attached below
> b) wait you can make of this bugreport
> c) provide any further info/testing?
Test the patch on 2.0e5 I sent you, please.
> BTW, 2.2.17 with the stock tmscsim works fine everytime; with that kernel
> (and no other changes) the system is excessively stable :)
That's at least something!
> CU, Yours Malte #8-)
>
> PS: Please cc me, I'm usually watching the lists I report bugs to, but LKML
> is a bit... excessive; I'll monitor the list from time to time, but can't
> guarantee timely responses...
Nor can I. Actually, messages concerning drivers I maintain are sorted by
procmailrc to a different folder :-)
> The next boot, while in the fsck-Phase for the SCSI drive (SysRq
> didn't work *that* well obviously :)) I got the oops. There were
> some lines scrolling by which I unfortunately couldn't write down
> fast enough, but I did copy the oops:
>
> Oops: 0000
Should be fixed in 2.0e5 and later.
> Also, the oops occured when I was sharing interrupts (but this is
> PCI, so there should be no problems, right?).
That's correct only if level triggered IRQs are used.
> I just fear that Linus might avoid large patches for the now
> imminent 2.4... :-?
The 2.0d driver does not work correctly with 2.4, and I'm trying to make
sure 2.0f will be perfect. I don't see why Linus should refuse to accept
a patch.
Regards,
-- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security
This archive was generated by hypermail 2b29 : Thu Nov 23 2000 - 21:00:22 EST