Subject: Re: ACPI vs VIA USB (netbsd-4 vs netbsd-3)
To: Michael van Elst <mlelstv@serpens.de>
From: Stephen Borrill <netbsd@precedence.co.uk>
List: port-i386
Date: 10/23/2007 15:56:10
On Mon, 22 Oct 2007, Michael van Elst wrote:
> On Mon, Oct 22, 2007 at 09:32:55AM +0100, Stephen Borrill wrote:
>> On Sun, 21 Oct 2007, Michael van Elst wrote:
>>> netbsd@precedence.co.uk (Stephen Borrill) writes:
>>>> To follow myself up, here's the relevant output with usbdebug and
>>>> uhcidebug set to 10 as I plug in the pendrive with a usb mouse plugged in:
>>> This looks like uhub_explore.
>>> Can you please repeat the test with uhubdebug set to 10 as well?
>> Sure:
>
> If I understand the code correctly the following
> happens:
>
>> uhub_explore: uhub2 port 1 status 0x0108 0x0000
>> uhub_explore: port=1 !C_CONNECT_STATUS
>
> Port 1 says:
> - has power (0x0100)
> - overcurrent (0x0008)
[snip]
> I don't understand where the 'overcurrent' comes from when
> the same hardware worked fine with netbsd3.

And more importantly, it works with netbsd-4 if acpi is disabled.

>> uhub_explore: uhub2 port 2 status 0x0308 0x0003
>> uhub_explore: C_PORT_ENABLED
>
> Port 2 says:
> - low speed device (0x0200)
> - has power (0x0100)
> - overcurrent (0x0008)
>
> the status changed
> - connect (0x0001), i.e. the port is now disconnected
> - enabled (0x0002), i.e. the port is now disabled
>
> The following is the driver reacting to the disconnect.
>
>> uhub_explore: status change hub=1 port=2
>> uhub_explore: device addr=2 disappeared on port 2
>> uhub_disconnect: up=0xc0e11144 dev=0xc0e24680 port=2
>> usb_disconnect_port: disconnect subdevs
>> uhidev0: at uhub2 port 2 (addr 2) disconnected
>> wsmouse1 detached
>> ums0 detached
>> uhidev0 detached
>> uhub_explore: port=2 !CURRENT_CONNECT_STATUS

I noticed that with acpi disabled, the mouse disconnects and then 
reconnects immediately as the umass device is picked up, i.e. it seems as 
though the kick to reconnect isn't happening in the acpi case. The same 
behaviour is seen with 3.1_STABLE+acpi.

At the moment, I'm trying to go back through time in CVS to work 
out when the problem first started (which is very tedious!). I've 
currently got it down to somewhere between Feb and Aug 2006...

-- 
Stephen