NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/44002: 3ware 9690 (ld driver) doesn't respond after transfer big amount of data
The following reply was made to PR kern/44002; it has been noted by GNATS.
From: Jiri Novotny <novotny%ics.muni.cz@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost,
netbsd-bugs%NetBSD.org@localhost,
novotny%ics.muni.cz@localhost
Subject: Re: kern/44002: 3ware 9690 (ld driver) doesn't respond after
transfer big amount of data
Date: Fri, 29 Oct 2010 13:40:32 +0200
Hi,
> On Thu, Oct 28, 2010 at 09:25:02PM +0000, Jiri Novotny wrote:
> > 0 0 ioflush 0 0 58 52 124 0 0 18040 genput DL-
> ?
>
> That one there's probably the thing it's stuck behind. Since all the
> other stuff looks normal and/or idle, though, I guess it means that
> I/O to the twa went off and never came back. Which given the other
> symptoms is not unexpected.
It looks like this, the same message is ever time it freeze.
>
> > > So twa0 shares interrupt with wm0 and uhci0.
> > > I have 2 systems with 3ware (these are 9550X, not 9650 though),
> > > but the controllers are alone on their interrupt line.
> > > I'm not sure if this can be the problem, but I would try to
> > > disable some devices so that twa0 doens't share interrupt with
> > > anything else.
> >
> > Could you give me a hint how to disable these devices,
> > or how can I say to twa to use other interupt line than uhci ?
> > I have keyboard and mouse on usb, but dosn't metter
> > because I use remote access. On other hand, I have system on USB
> > disk ...
>
> You can disable devices at boot time (boot -c from the boot prompt,
> then "disable uhci0") but if your keyboard is connected via usb that
> may not go so well.
I did check it. Fortunately keyboard and USB disk were at other controller.
There was also wm0 at the same interupt, I disabled it as well. So there is
an interupt assigment after disable uhci and wm:
ioapic0 at mainbus0 apid 2: pa 0xfec00000, version 20, 24 pins
ioapic1 at mainbus0 apid 3: pa 0xfecc0000, version 20, 24 pins
ioapic2 at mainbus0 apid 4: pa 0xfecc0400, version 20, 24 pins
twa0: interrupting at ioapic0 pin 16
ehci0: interrupting at ioapic0 pin 18
ehci1: interrupting at ioapic0 pin 23
ahcisata0: interrupting at ioapic0 pin 17
ichsmb0: interrupting at ioapic0 pin 17
the behavior is still the same, so I guess the issue is not done by
shared interupts.
When I did this set of tests I didn't saw anything suspicious at console but
"twa0: clearing controller queue error"
Any idea what else to do ?
Best regards
Jiri
Home |
Main Index |
Thread Index |
Old Index