[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/39093: usb doesn't work anymore on IBM T43p
On Mon, Jul 07, 2008 at 10:36:35AM +0200, Kurt Schreiner wrote:
> On Sun, Jul 06, 2008 at 09:31:32PM +0200, Manuel Bouyer wrote:
> > On Fri, Jul 04, 2008 at 09:42:54PM +0200, Kurt Schreiner wrote:
> > > > Do you mean is started failing on Jun 27, or that it worked on Jun 27
> > > > and
> > > > started failing later ? I commited some changes to the USB drivers on
> > > > Jun 28.
> > > First failure is from Jun 27. Here's the relevant excerpt from
> > > /var/log/messages
> > OK, so it's probably not caused by uhci.c rev 1.223. You could try reverting
> > it to 1.222 to see if it changes anything, but I don't think so.
> Over the weekend I played around w/ older kernels from source back to
> Jun 14 20:21 - the problem appears sooner or later... Even the kernel
> compiled on Jun 14 18:43 which (I thought?) worked previously shows
> the problem. I've found a very old kernel from May, 4 which booted fine
> and didn't show the problem but new userland (ifconfig etc) doesn't work
> so well. I'll experiment more later at home...
OK, so it's definitively not related to my changes.
> > > /var/log/messages)
> > there's still more than one minute before getting the first message (and
> > probably more than that because syslog doesn't start right after init).
> > So I guess something is corrupting uhci's memory.
> > Could you see if not using ath (maybe disabling it with boot -c) would
> > avoid the issue ?
> Just tried w/ ath disabled using one of the "problematic" kernels built
> saturday and until now no error message! Hmmmmmmm....
> Same w/ a kernel just built from fresh sources: no problems so far...
> So the questions are: What and why is ath doing bad to uhci?
> Maybe this excerpt from /var/log/messages* could give a clue?
> /var/log/messages.9.gz:Jun 7 21:40:17 ipaddi /netbsd: ath0: hardware error;
I don't know what these "hardware error" really means.
The cause of the UHCI errors is probably because the UHCI DMA descriptors
are invalid (or the controller thinks so). This could be because something
else is writing to memory and corrupts the UHCI DMA memory,
or because the some other device, or a chipset bug, cause data corruption
on the PCI bus when the UHCI controllers are doing their DMA reads.
Manuel Bouyer, LIP6, Universite Paris VI.
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |