On Wednesday 19 January 2005 12:13 am, Oliver Neukum wrote:
> Am Dienstag, 18. Januar 2005 20:59 schrieb David Brownell:
> > It's possible that some PCMCIA changes affected this too. I seem
> > to recall thinking that the cardbus/pcmcia logic should have been
> > notifying the OHCI code about the
Am Dienstag, 18. Januar 2005 20:59 schrieb David Brownell:
> It's possible that some PCMCIA changes affected this too. I seem
> to recall thinking that the cardbus/pcmcia logic should have been
> notifying the OHCI code about the disconnect before the IRQ logic
> saw it ... and I wouldn't swear th
Hi,
Alan Stern:
> > The cleanup logic -- hc_died() and friends -- isn't working lately.
> > That's in usbcore now, since it's logic that all HCDs need to have.
> > One symptom of the cleanup failing would be URBs never returning...
>
> This definitely could be the problem. Among other things, hc
On Tue, 18 Jan 2005, David Brownell wrote:
> This sounds like that deadlock we were getting a lot back when the
> locking inside usbcore got completely overhauled. If there weren't
> any messages from the HCD indicating that it saw the disconnect,
> that could be more likely.
No, it's clear from
On Tuesday 18 January 2005 8:26 am, Alan Stern wrote:
>
> Khubd isn't doing anything. But hald sure is!
>
> It's trying to read /proc/bus/usb/devices, and in the process it locks
> each device as it reads the information for that device. Apparently it
> has worked its way up to one of the dev
Hi,
Alan Stern:
> It's not an ordering problem. And you're right that normally reading the
> file doesn't block -- or more precisely, it doesn't block for long.
> However the kernel does need to transfer the various strings from the
> device (the strings aren't cached in the kernel) and that wi
On Tue, 18 Jan 2005, Matthias Urlichs wrote:
> Hi,
>
> Alan Stern:
> > It's trying to read /proc/bus/usb/devices, and in the process it locks
> > each device as it reads the information for that device. Apparently it
> > has worked its way up to one of the devices on your card, and it holds th
Hi,
Alan Stern:
> It's trying to read /proc/bus/usb/devices, and in the process it locks
> each device as it reads the information for that device. Apparently it
> has worked its way up to one of the devices on your card, and it holds the
> lock on that device thus blocking usb_disconnect.
>
On Tue, 18 Jan 2005, Matthias Urlichs wrote:
> Suspect 1:
>
> hald D 0 4942 1 4996 4938 (NOTLB)
>c17d1c98 0082 0002 0002 016d2980 ddb4b580 d990bcfc
>dd86fe84 0286 df098980 dd86fe84 e06a5065 da589a80 c13f6060
>8
On Tue, 18 Jan 2005, Matthias Urlichs wrote:
> Any ideas why this happens (after 4000+ cycles, no less) would be
> appreciated.
>
> This is 2.6.11-rc1-mm1.. Will try plain -rc1 next.
>
> cardctl D C13F007B 0 11374 4366 (NOTLB)
> c4787e40 0082 c4787de4 c13f007b
Hi,
Alan Stern:
> On Tue, 18 Jan 2005, Matthias Urlichs wrote:
>
> > Any ideas why this happens (after 4000+ cycles, no less) would be
> > appreciated.
> >
> > This is 2.6.11-rc1-mm1.. Will try plain -rc1 next.
plain -rc1 locks up on eject. Sometimes. :-/
> > cardctl D C13F007B 0 1
Hi,
Greg KH:
> This is a cardbus USB adapter that you have removed from the system?
Yes and no -- I'm "cardctl eject"ing it, but physically it's still plugged
in (otherwise there'd be no need to do the eject ;-).
> Are there any USB devices attached to it when you do this?
>
Yes -- three serial
On Tue, Jan 18, 2005 at 06:18:06AM +0100, Matthias Urlichs wrote:
> Any ideas why this happens (after 4000+ cycles, no less) would be
> appreciated.
>
> This is 2.6.11-rc1-mm1.. Will try plain -rc1 next.
>
> cardctl D C13F007B 0 11374 4366 (NOTLB)
> c4787e40 00
Any ideas why this happens (after 4000+ cycles, no less) would be
appreciated.
This is 2.6.11-rc1-mm1.. Will try plain -rc1 next.
cardctl D C13F007B 0 11374 4366 (NOTLB)
c4787e40 0082 c4787de4 c13f007b c13f6060 0001 0001
de49308
14 matches
Mail list logo
