I've put in some debugging info to see where it gets to during the
cold-plug/unplug/hotplug process, and have included an edited version
of the /var/log/messages output during this time frame.
Hopefully it might shed some light on the situation.
Sorry for its length.
Also, since I've been seein
Alan Stern replied:
> On Sun, 9 May 2004, Fulko Hew wrote:
> >
> > So far I haven't put in any tracing information, but I have been
playing
> > with the latest Knoppix release that provides kernel 2.6.5
> > And the hotplug works with it.
> >
> > S
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 13. Mai 2004 20:09 schrieb Alan Stern:
> > On Thu, 13 May 2004, Oliver Neukum wrote:
> >
> > > Hi,
> > >
> > > this stick is acting up.
> > > I just mounted it and got (no disconnection physically):
> >
> > It looks like some sort of I/O
So far I haven't put in any tracing information, but I have been playing
with the latest Knoppix release that provides kernel 2.6.5
And the hotplug works with it.
So could it be a difference in initialization between kernel 2.6.5 and 2.6.6
or could it be something I (and RedHat) have left out of my
I've been testing Fedora Core 2 on my Centrino laptop,
and it hotplugging USB devices doesn't appear to
work with this kernel on this hardware.
If the USB devices are plugged in before booting, they are detected.
When the USB device is unplugged, thats detected too,
but plug-in in _after_ boot does
Greg KH wrote:
On Sun, May 02, 2004 at 08:34:03PM -0400, Fulko Hew wrote:
I've been testing Fedora Core 2 on my Centrino laptop,
and it hotplugging USB devices doesn't appear to
work with this kernel on this hardware.
"nothing"? Hm, not good. Care to enable CONFIG_USB_DE
Greg KH wrote:
On Sun, May 02, 2004 at 08:34:03PM -0400, Fulko Hew wrote:
I've been testing Fedora Core 2 on my Centrino laptop,
and it hotplugging USB devices doesn't appear to
work with this kernel on this hardware.
"nothing"? Hm, not good. Care to enable CONFIG_USB_DE
Alan Stern <[EMAIL PROTECTED]> replied:
>On Mon, 3 May 2004, Fulko Hew wrote:
>
>> I managed to figure out how to fetch/configure and install 2.6.6-rc3...
>> and re-ran the test, and got the same results...
>> ie. no activity on hot-plug. :-(
>>
>> So wha
Alan Stern continued:
>On Tue, 4 May 2004 [EMAIL PROTECTED] wrote:
>
>> Here is my dump of /proc/driver/uhci/000:00:1d.1 after the various
stages:
>
... snip ...
>> == after hot-plug ==
>>
>> HC status
>> usbcmd= 0008 Maxp32 EGSM
>> usbstat = 0020 HCHalted
>> usbint=
Alan Stern <[EMAIL PROTECTED]> continued with:
... snip ...
>> Now is it truely the controller that didn't detect the plugin, or
>> that it didn't report the plugin via an interrupt to driver sw that
>> eventually updates this info?
>
>The contents of the /proc file are taken directly from regis
Alan Stern wrote:
That's right, but it's not entirely right. When no devices are attached
(like when you unplugged your drive) the controller is suspended. While
suspended it can still detect connections; it just doesn't perform DMA
and doesn't drive the USB bus. A connection triggers an int
Alan Stern wrote:
On Tue, 4 May 2004, Randy.Dunlap wrote:
On Tue, 4 May 2004 11:58:35 -0400 (EDT) Alan Stern wrote:
| > == after hot-un-plug ==
| >
| > HC status
| > usbcmd= 0008 Maxp32 EGSM
| > usbstat = 0020 HCHalted
| > usbint= 000f
| > usbfrnum = (0)2
Alan Stern <[EMAIL PROTECTED]>@lists.sourceforge.net wrote:
... snip ...
>> >No, it is normal. When no devices are attached the driver halts the
>> >controller to reduce PCI utilization and avoid DMA activity, thereby
>> >permitting improved power management.
>> >
>> Then is it safe to assume,
Alan Stern wrote:
Sure. uhci_irq() in drivers/usb/host/uhci-hcd.c receives the interrupt
and sets uhci->resume_detect to 1. Then hc_state_transitions() in the
same file sees uhci->resume_detect and calls wakeup_hc() to restart the
controller.
The first thing
to prove is that the interrupt never
Alan Stern replied:
>On Wed, 5 May 2004, Fulko Hew wrote:
>
>> Well your right. Both coldplug and hotplug does not get me to uhci_irq
(),
>> but then again neither does the unplug. ;-|
>> The unplug does get to core/usb.c:usb_disconnect()
>>
>> Whats the
Alan Stern replied:
>>
>> >If it works initially, before you unplug the device, then interrupts
are
>> >enabled.
>>
>> But...
>> I put in a printk() at the start of the interrupt handler: uhci_irq()
>> and it _never_ gets called!... ever!
>
>Well, that's bad. Didn't you say before that when th
Alan Stern and I exchanged:
> > The first thing
> > to prove is that the interrupt never happens. Then to figure out why.
I can tell you why. No interrupt happened because the controller didn't
request one, because it never realized that anything was connected to the
port. But if you want to in
17 matches
Mail list logo
