Messages in this thread | | | Date | Wed, 22 Nov 2000 00:43:46 +0100 | From | Kurt Garloff <> | Subject | Re: PROBLEM: tmscsim driver on test11-pre7 stops working when starting X |
| |
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 [unhandled content-type:application/pgp-signature] | |