Re: [9front] usb hid defunct?

Re: [9front] usb hid defunct?

[cinap_lenrek]

can you repeat the usb/usbd -ddd trace with your usb stick? i suspect
that one uses ehci, which should work. but all low/fullspeed devices
are fucked because the uhci doesnt work? (interrupt problems as the
controller shows nintr 0, ntdintr 0 and nqhintr 0 ....)

--
cinap

Re: [9front] usb hid defunct?

[Ethan Grammatikidis]

On Thu, Nov 23, 2017, at 10:18 PM, cinap_lenrek@felloff.net wrote:
> no problem. you provided all the evidence needed to figure
> it out. so thanks for your patience. :)

thank you :)

-- 
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9front] usb hid defunct?

[cinap_lenrek]

no problem. you provided all the evidence needed to figure
it out. so thanks for your patience. :)

--
cinap

Re: [9front] usb hid defunct?

[Ethan Grammatikidis]

On Thu, Nov 23, 2017, at 09:45 PM, cinap_lenrek@felloff.net wrote:
> there are many possibilities. like if you used a usb2.0 hub
> before, it would go thru the ehci controller, which got its
> interrupts fine regardless of *acpi= or not and it would be
> fine.
> 
> i'm thinking about adding a check in the ohci/uhci drivers
> for this. basically after a timeout, we can call the isr
> manually and see if that fixed the problem. if thats the
> case we could report the condition so i dont need to dig
> into the code each time some usb shit isnt working.
> 
> ran out of time... 
> 
> --
> cinap

i've got to admit i probably used *acpi=1 before. 
i'm sorry to make work.


-- 
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9front] usb hid defunct?

[cinap_lenrek]

there are many possibilities. like if you used a usb2.0 hub
before, it would go thru the ehci controller, which got its
interrupts fine regardless of *acpi= or not and it would be
fine.

i'm thinking about adding a check in the ohci/uhci drivers
for this. basically after a timeout, we can call the isr
manually and see if that fixed the problem. if thats the
case we could report the condition so i dont need to dig
into the code each time some usb shit isnt working.

ran out of time... 

--
cinap

Re: [9front] usb hid defunct?

[Ethan Grammatikidis]

logged flash drive insert & disconnect at:
http://okturing.com/src/1768/body

i would have logged this before you asked, but i felt my brain
starting to go and thought it would be better to paste what i had.

On Fri, Nov 17, 2017, at 06:31 PM, cinap_lenrek@felloff.net wrote:
> ok, i did a little experiment now, commenting out the intrenable()
> line from the uhci driver and i can completely reproduce the effect
> you have.
> 
> port attaches get as far as setaddr which then times out and its
> gone. but all highspeed devices work (usb stick).
> 
> so it really looks like your uhci controller is not getting its
> interrupts for some reason, but the ehci is.
> 
> so i'd do the standard things first:
> 
> try booting with: *acpi=

sufficient! the known-good keyboard and mouse work with this. 
here's the log:
http://okturing.com/src/1770/body

i remember thinking i'd make a default installation this time.
by the time i wanted to plug a keyboard and mouse in 
i'd forgotten all about *acpi.

Re: [9front] usb hid defunct?

[cinap_lenrek]

ok, i did a little experiment now, commenting out the intrenable()
line from the uhci driver and i can completely reproduce the effect
you have.

port attaches get as far as setaddr which then times out and its
gone. but all highspeed devices work (usb stick).

so it really looks like your uhci controller is not getting its
interrupts for some reason, but the ehci is.

so i'd do the standard things first:

try booting with: *acpi=

if still doesnt work, go to legacy isa interrupts: *nomp=1

--
cinap

Re: [9front] usb hid defunct?

[cinap_lenrek]

the problem is that the "setaddr" tansaction fails. basically, when
you plug something in, usbd notices as it polls the status of the
hub where the port is on. that sets some bits and then we enable
the port, which runs the speed negotiation... and then we do attach.
the device comes up with address 0. then we try to set the address
to something unique (9 in this case) as the bus as *every* device
comes up with address 0 on attach :). that fails, so we give up and
turn the port off again.

i'll try to simulate this issue on my t23, it has uhci controller
as well.

--
cinap

Re: [9front] usb hid defunct?

[Ethan Grammatikidis]

On Fri, Nov 17, 2017, at 12:48 PM, cinap_lenrek@felloff.net wrote:
> thank you, this is usefull. i'll look at after i get home from work. and yes, please
> make these dumps also for your known-to-be-working keyboard/mouse too.
> 
> --
> cinap

done:
http://okturing.com/src/1759/body


-- 
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9front] usb hid defunct?

[cinap_lenrek]

thank you, this is usefull. i'll look at after i get home from work. and yes, please
make these dumps also for your known-to-be-working keyboard/mouse too.

--
cinap

Re: [9front] usb hid defunct?

[Ethan Grammatikidis]

I did have some trouble with that mouse when it worked (with a kernel from 2015 I think), and I don't recall ever using that keyboard with 9front. If you like, I could log events from a mouse and keyboard I formerly had no trouble with (but do now).

-- 
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9front] usb hid defunct?

[Ethan Grammatikidis]

On Thu, Nov 16, 2017, at 06:29 PM, cinap_lenrek@felloff.net wrote:
> ok, given that you don't see any output from /dev/usbevents,
> i'd start with debugging usbd which handles device attaches/detaches.
> if that doesnt work, then nusb/kb isnt even started and we do not
> have to look into it until this is resolved.

> 
> then post the output when you attach the usb keyboard.
> 
> alternatively, you can boot with boot parameter: nousbrc=1
> and then start nusb/usbd -ddd manually and get some debug
> output.

did this because you know what i'm like with installing kernels.
here's a log with a few comments:
http://okturing.com/src/1758/body

-- 
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9front] usb hid defunct?

[cinap_lenrek]

ok, given that you don't see any output from /dev/usbevents,
i'd start with debugging usbd which handles device attaches/detaches.
if that doesnt work, then nusb/kb isnt even started and we do not
have to look into it until this is resolved.

change /sys/src/9/boot/nusbrc like:

- if(! nusb/usbd)
+ if(! nusb/usbd $usbdebug)
	exit

build a new kernel and reboot with boot parameter: usbdebug=-ddd

then post the output when you attach the usb keyboard.

alternatively, you can boot with boot parameter: nousbrc=1
and then start nusb/usbd -ddd manually and get some debug
output.

--
cinap

Re: [9front] usb hid defunct?

[cinap_lenrek]

ok, also still works fine on my t23 with uhci.

--
cinap

Re: [9front] usb hid defunct?

[cinap_lenrek]

no messages in usbevent sounds like an issue with the controller driver?

usb mouse works fine on my x230 using ehci. does the x61 is uhci no?

i don't see any obvious changes that could cause this. uhci driver
got some fixes regarding isochronous transfers (usb audio). and
uhci got some boot print format changes, but thats about it.

--
cinap

Re: [9front] usb hid defunct?

[hiro]

you are aware there's even xhci now? i haven't tried older external
usb keyboards/mice in a while on my t43 because the resolution is so
high i need to sit right in front of it anyway.