Re: xhci not working with urtwn

[Takahiro Hayashi]

On 2016/07/17 20:41, Nick Hudson wrote:

On 17-Jul-16 10:01 AM, Takahiro Hayashi wrote:

Hi,

The patch is generally good, but I'm confused by this part...




@@ -3483,12 +3606,7 @@ xhci_device_ctrl_start(struct usbd_xfer
  XHCI_TRB_2_BYTES_SET(len);
  control = (isread ? XHCI_TRB_3_DIR_IN : 0) |
  XHCI_TRB_3_TYPE_SET(XHCI_TRB_TYPE_DATA_STAGE) |
-XHCI_TRB_3_CHAIN_BIT | XHCI_TRB_3_ENT_BIT;
-xhci_trb_put(>xx_trb[i++], parameter, status, control);
-
-parameter = (uintptr_t)xfer | 0x3;
-status = XHCI_TRB_2_IRQ_SET(0);
-control = XHCI_TRB_3_TYPE_SET(XHCI_TRB_TYPE_EVENT_DATA) |
+(usbd_xfer_isread(xfer) ? XHCI_TRB_3_ISP_BIT : 0) |
  XHCI_TRB_3_IOC_BIT;
  xhci_trb_put(>xx_trb[i++], parameter, status, control);
  }



Where is the xfer pointer put int the TRBs for a control transfer now?


When ED_BIT == 0, Transfer Event has the physical address of causing TRB in 
trb_0,
so xhci_event_transfer calculates the index to TRB table, and then xfer is 
obtained
from xr->xr_cookies[idx] in the ring.


--
t-hash

Re: xhci not working with urtwn

[Takahiro Hayashi]

Hi,

On 2016/07/08 00:44, co...@sdf.org wrote:

hi,
my urtwn (EW-7811Un) is failing with xhci.
it still works if I use another machine which has USB2 ports on a recent
kernel (i.e. it is not a urtwn(4) problem).

in dmesg I see:
urtwn0: could not load firmware page 0


Can you try attached patch?

It seems that Intel xHC may fail to handle control transfer
with Link TRB if it uses EVENT_DATA TRB.
This patch avoids using EVENT_DATA and adds some improvements.


--
t-hash
--- sys/dev/usb/xhci.c.orig 2016-07-10 11:45:17.0 +0900
+++ sys/dev/usb/xhci.c  2016-07-17 03:55:54.0 +0900
@@ -520,6 +520,17 @@ xhci_trb_get_idx(struct xhci_ring *xr, u
return 0;
 }
 
+static unsigned int
+xhci_get_epstate(struct xhci_softc * const sc, struct xhci_slot * const xs,
+u_int dci)
+{
+   uint32_t *cp;
+
+   usb_syncmem(>xs_dc_dma, 0, sc->sc_pgsz, BUS_DMASYNC_POSTREAD);
+   cp = xhci_slot_get_dcv(sc, xs, dci);
+   return XHCI_EPCTX_0_EPSTATE_GET(le32toh(cp[0]));
+}
+
 /* --- */
 
 void
@@ -1281,7 +1292,7 @@ xhci_unconfigure_endpoint(struct usbd_pi
 
 /* 4.6.8, 6.4.3.7 */
 static usbd_status
-xhci_reset_endpoint(struct usbd_pipe *pipe)
+xhci_reset_endpoint_locked(struct usbd_pipe *pipe)
 {
struct xhci_softc * const sc = XHCI_PIPE2SC(pipe);
struct xhci_slot * const xs = pipe->up_dev->ud_hcpriv;
@@ -1292,17 +1303,31 @@ xhci_reset_endpoint(struct usbd_pipe *pi
XHCIHIST_FUNC(); XHCIHIST_CALLED();
DPRINTFN(4, "slot %u dci %u", xs->xs_idx, dci, 0, 0);
 
+   KASSERT(mutex_owned(>sc_lock));
+
trb.trb_0 = 0;
trb.trb_2 = 0;
trb.trb_3 = XHCI_TRB_3_SLOT_SET(xs->xs_idx) |
XHCI_TRB_3_EP_SET(dci) |
XHCI_TRB_3_TYPE_SET(XHCI_TRB_TYPE_RESET_EP);
 
-   err = xhci_do_command(sc, , USBD_DEFAULT_TIMEOUT);
+   err = xhci_do_command_locked(sc, , USBD_DEFAULT_TIMEOUT);
 
return err;
 }
 
+static usbd_status
+xhci_reset_endpoint(struct usbd_pipe *pipe)
+{
+   struct xhci_softc * const sc = XHCI_PIPE2SC(pipe);
+
+   mutex_enter(>sc_lock);
+   usbd_status ret = xhci_reset_endpoint_locked(pipe);
+   mutex_exit(>sc_lock);
+
+   return ret;
+}
+
 /*
  * 4.6.9, 6.4.3.8
  * Stop execution of TDs on xfer ring.
@@ -1342,7 +1367,7 @@ xhci_stop_endpoint(struct usbd_pipe *pip
  * error will be generated.
  */
 static usbd_status
-xhci_set_dequeue(struct usbd_pipe *pipe)
+xhci_set_dequeue_locked(struct usbd_pipe *pipe)
 {
struct xhci_softc * const sc = XHCI_PIPE2SC(pipe);
struct xhci_slot * const xs = pipe->up_dev->ud_hcpriv;
@@ -1354,6 +1379,8 @@ xhci_set_dequeue(struct usbd_pipe *pipe)
XHCIHIST_FUNC(); XHCIHIST_CALLED();
DPRINTFN(4, "slot %u dci %u", xs->xs_idx, dci, 0, 0);
 
+   KASSERT(mutex_owned(>sc_lock));
+
xhci_host_dequeue(xr);
 
/* set DCS */
@@ -1363,11 +1390,23 @@ xhci_set_dequeue(struct usbd_pipe *pipe)
XHCI_TRB_3_EP_SET(dci) |
XHCI_TRB_3_TYPE_SET(XHCI_TRB_TYPE_SET_TR_DEQUEUE);
 
-   err = xhci_do_command(sc, , USBD_DEFAULT_TIMEOUT);
+   err = xhci_do_command_locked(sc, , USBD_DEFAULT_TIMEOUT);
 
return err;
 }
 
+static usbd_status
+xhci_set_dequeue(struct usbd_pipe *pipe)
+{
+   struct xhci_softc * const sc = XHCI_PIPE2SC(pipe);
+
+   mutex_enter(>sc_lock);
+   usbd_status ret = xhci_set_dequeue_locked(pipe);
+   mutex_exit(>sc_lock);
+
+   return ret;
+}
+
 /*
  * Open new pipe: called from usbd_setup_pipe_flags.
  * Fills methods of pipe.
@@ -1510,12 +1549,14 @@ xhci_close_pipe(struct usbd_pipe *pipe)
 
 /*
  * Abort transfer.
- * May be called from softintr context.
+ * Should be called with sc_lock held.
  */
 static void
 xhci_abort_xfer(struct usbd_xfer *xfer, usbd_status status)
 {
struct xhci_softc * const sc = XHCI_XFER2SC(xfer);
+   struct xhci_slot * const xs = xfer->ux_pipe->up_dev->ud_hcpriv;
+   const u_int dci = xhci_ep_get_dci(xfer->ux_pipe->up_endpoint->ue_edesc);
 
XHCIHIST_FUNC(); XHCIHIST_CALLED();
DPRINTFN(4, "xfer %p pipe %p status %d",
@@ -1532,10 +1573,66 @@ xhci_abort_xfer(struct usbd_xfer *xfer, 
return;
}
 
-   /* XXX need more stuff */
+   /*
+* If an abort is already in progress then just wait for it to
+* complete and return.
+*/
+   if (xfer->ux_hcflags & UXFER_ABORTING) {
+   DPRINTFN(4, "already aborting", 0, 0, 0, 0);
+#ifdef DIAGNOSTIC
+   if (status == USBD_TIMEOUT)
+   DPRINTFN(4, "TIMEOUT while aborting", 0, 0, 0, 0);
+#endif
+   /* Override the status which might be USBD_TIMEOUT. */
+   xfer->ux_status = status;
+   DPRINTFN(4, "xfer %p waiting for abort to finish", xfer, 0, 0,
+   0);
+   xfer->ux_hcflags |= UXFER_ABORTWAIT;
+   while (xfer->ux_hcflags & UXFER_ABORTING)
+   cv_wait(>ux_hccv, >sc_lock);
+  

Re: xhci not working with urtwn

[Takahiro Hayashi]

Hi,

On 2016/07/08 00:44, co...@sdf.org wrote:

hi,
my urtwn (EW-7811Un) is failing with xhci.
it still works if I use another machine which has USB2 ports on a recent
kernel (i.e. it is not a urtwn(4) problem).

in dmesg I see:
urtwn0: could not load firmware page 0

what's the way to get the most info?


Can you rebuild kernel with

options USB_DEBUG
options URTWN_DEBUG

patch dev/usb/if_urtwn.c with:

--- sys/dev/usb/if_urtwn.c.orig 2016-06-10 23:26:46.0 +0900
+++ sys/dev/usb/if_urtwn.c  2016-07-08 01:28:01.0 +0900
@@ -26,6 +26,7 @@
 __KERNEL_RCSID(0, "$NetBSD: if_urtwn.c,v 1.45 2016/06/10 13:27:15 ozaki-r Exp 
$");
 
 #ifdef _KERNEL_OPT

+#include "opt_usb.h"
 #include "opt_inet.h"
 #endif
 


boot kernel with -d and set this?

w/l urtwn_debug 

urtwn driver should print out all debug messages.


--
t-hash

Re: Crash in xhci driver

[Takahiro Hayashi]

On 2016/06/30 19:45, Paul Goyette wrote:

On Thu, 30 Jun 2016, Takahiro Hayashi wrote:


Can you add these kernel options:

options DIAGNOSTIC
options USB_DEBUG
options XHCI_DEBUG


I am starting a rebuild now.  I will be able to install the new kernel tomorrow.


and, set this sysctl?

hw.xhci.debug=14


Sure - I'll add it to my /etc/sysctl.conf file


however, I have no idea to see the logs without kbd.


Will the info be kept in a crash dump?  I am modifying my set-up to just dump, 
instead of stopping in ddb.


I think you can read - "vmstat -u usbhist -M core", but I've not tried that.


cheers,
--
t-hash

Re: Crash in xhci driver

[Takahiro Hayashi]

On 2016/06/30 10:17, Paul Goyette wrote:

I got this crash again.  This time I was paying a bit more attention.

The system actually froze for a few seconds (maybe 10 or 15 seconds), but it 
was still running.  No keyboard or mouse input was processed, however my xclock 
was still updating the clock display.

Then it switched to wscons display 0 and dropped into the debugger.

There were a whole slew of WARNING: SPL NOT LOWERED ON SYSCALL ... messages, 
more than a full page.  The last such message was


WARNING: SPL NOT LOWERED ON SYSCALL 320 4 EXIT bd626a08 6

and then the same stack trace as before.  No actual panic message was displayed.

I have not yet tried the patch you have suggested - as soon as I finish my 
current project, I'll rebuild and reinstall with your patch.


Can you add these kernel options:

options DIAGNOSTIC
options USB_DEBUG
options XHCI_DEBUG

and, set this sysctl?

hw.xhci.debug=14

however, I have no idea to see the logs without kbd.



On Mon, 27 Jun 2016, Paul Goyette wrote:


On Mon, 27 Jun 2016, Takahiro Hayashi wrote:


Hi,

On 2016/06/27 09:22, Paul Goyette wrote:

Hmmm, my system was totally idle (just running xlockmore's "maze" screen 
saver!), and suddenly panic()d.

Here's the traceback (manually transcribed):

vpanic + 0x140
cd_play_msf
xhci_new_device + 0x821
usbd_new_device + 0x3e
uhub_explore + 0x2fa
usb_discover.isra.2 + 0x4e (interesting symbol name!)
usb_event_thread + 0x7c

According to gdb(1), this was the KASSERT() at sys/dev/usb/xhci.c:2106

2101//hexdump("slot context", cp, sc->sc_ctxsz);
2102uint8_t addr = XHCI_SCTX_3_DEV_ADDR_GET(cp[3]);
2103DPRINTFN(4, "device address %u", addr, 0, 0, 0);
2104/* XXX ensure we know when the hardware does something
2105   we can't yet cope with */
2106KASSERT(addr >= 1 && addr <= 127);
2107dev->ud_addr = addr;
2108/* XXX dev->ud_addr not necessarily unique on bus */
2109KASSERT(bus->ub_devices[dev->ud_addr] == NULL);
2110bus->ub_devices[dev->ud_addr] = dev;

No devices were being inserted (or removed), so I'm unsure why it would be 
calling xhci_new_device().  The comments in the source seem to say that this 
code only gets called when a new device has been found


Does your PC have usb keyboard and mice?


Yes, one USB keyboard, one USB mouse


What is the PCI vendor and product number of xHCI?


xhci0 at pci0 dev 20 function 0: vendor 8086 product 8c31 (rev. 0x05)
xhci0: interrupting at msi0 vec 0
xhci0: xHCI version 1.0
usb0 at xhci0: USB revision 3.0


Does your kernel say anything before panic after boot?


Hard to tell, since it was on my X display, running the "maze" module from xlockmore.  :) 
 When the panic occurred, it "jumped" to the console display, displayed the panic 
message, and displayed a 'db' prompt.  Of course, since the keyboard is USB, it was unuseable at 
that point!  :)


and, How frequently does the panic happen?


I've been running this kernel for a couple of weeks now, and the panic occurred 
only one time.


could you try this patch?

--- sys/dev/usb/xhci.c.bak2016-06-13 01:32:30.0 +0900
+++ sys/dev/usb/xhci.c2016-06-27 18:27:55.0 +0900
@@ -2091,8 +2129,10 @@ xhci_new_device(device_t parent, struct
 /* 4.3.4 Address Assignment */
err = xhci_set_address(dev, slot, false);
-if (err)
+if (err) {
+printf("%s: set address w/ bsr %u\n", __func__, err);
goto bad;
+}
 /* Allow device time to set new address */
usbd_delay_ms(dev, USB_SET_ADDRESS_SETTLE);
@@ -2103,7 +2143,8 @@ xhci_new_device(device_t parent, struct
DPRINTFN(4, "device address %u", addr, 0, 0, 0);
/* XXX ensure we know when the hardware does something
   we can't yet cope with */
-KASSERT(addr >= 1 && addr <= 127);
+KASSERTMSG(addr >= 1 && addr <= 127, "addr %u out of range",
+addr);
dev->ud_addr = addr;
/* XXX dev->ud_addr not necessarily unique on bus */
KASSERT(bus->ub_devices[dev->ud_addr] == NULL);


I will add this on my next kernel build.  The messages look useful, even if I 
cannot reproduce my panic!




--
t-hash

Re: Crash in xhci driver

[Takahiro Hayashi]

Hi,

On 2016/06/27 20:10, Paul Goyette wrote:

On Mon, 27 Jun 2016, Takahiro Hayashi wrote:


ddb.commandonenter may help you (a little).


What command would you like me to execute?


Ah, never mind please, you seems already have "trace".




Does syslogd write anything to /var/log/messages ?


No.




--
t-hash

Re: Crash in xhci driver

[Takahiro Hayashi]

Hi,

On 2016/06/27 19:22, Paul Goyette wrote:

On Mon, 27 Jun 2016, Takahiro Hayashi wrote:


Hi,

On 2016/06/27 09:22, Paul Goyette wrote:

Hmmm, my system was totally idle (just running xlockmore's "maze" screen 
saver!), and suddenly panic()d.

Here's the traceback (manually transcribed):

vpanic + 0x140
cd_play_msf
xhci_new_device + 0x821
usbd_new_device + 0x3e
uhub_explore + 0x2fa
usb_discover.isra.2 + 0x4e (interesting symbol name!)
usb_event_thread + 0x7c

According to gdb(1), this was the KASSERT() at sys/dev/usb/xhci.c:2106

2101//hexdump("slot context", cp, sc->sc_ctxsz);
2102uint8_t addr = XHCI_SCTX_3_DEV_ADDR_GET(cp[3]);
2103DPRINTFN(4, "device address %u", addr, 0, 0, 0);
2104/* XXX ensure we know when the hardware does something
2105   we can't yet cope with */
2106KASSERT(addr >= 1 && addr <= 127);
2107dev->ud_addr = addr;
2108/* XXX dev->ud_addr not necessarily unique on bus */
2109KASSERT(bus->ub_devices[dev->ud_addr] == NULL);
2110bus->ub_devices[dev->ud_addr] = dev;

No devices were being inserted (or removed), so I'm unsure why it would be 
calling xhci_new_device().  The comments in the source seem to say that this 
code only gets called when a new device has been found


Thank you for your feedback.


Does your PC have usb keyboard and mice?


Yes, one USB keyboard, one USB mouse


What is the PCI vendor and product number of xHCI?


xhci0 at pci0 dev 20 function 0: vendor 8086 product 8c31 (rev. 0x05)
xhci0: interrupting at msi0 vec 0
xhci0: xHCI version 1.0
usb0 at xhci0: USB revision 3.0


It's intel chip.




Does your kernel say anything before panic after boot?


Hard to tell, since it was on my X display, running the "maze" module from xlockmore.  :) 
 When the panic occurred, it "jumped" to the console display, displayed the panic 
message, and displayed a 'db' prompt.  Of course, since the keyboard is USB, it was unuseable at 
that point!  :)


ddb.commandonenter may help you (a little).
Does syslogd write anything to /var/log/messages ?




and, How frequently does the panic happen?


I've been running this kernel for a couple of weeks now, and the panic occurred 
only one time.


could you try this patch?

--- sys/dev/usb/xhci.c.bak2016-06-13 01:32:30.0 +0900
+++ sys/dev/usb/xhci.c2016-06-27 18:27:55.0 +0900
@@ -2091,8 +2129,10 @@ xhci_new_device(device_t parent, struct
 /* 4.3.4 Address Assignment */
err = xhci_set_address(dev, slot, false);
-if (err)
+if (err) {
+printf("%s: set address w/ bsr %u\n", __func__, err);
goto bad;
+}
 /* Allow device time to set new address */
usbd_delay_ms(dev, USB_SET_ADDRESS_SETTLE);
@@ -2103,7 +2143,8 @@ xhci_new_device(device_t parent, struct
DPRINTFN(4, "device address %u", addr, 0, 0, 0);
/* XXX ensure we know when the hardware does something
   we can't yet cope with */
-KASSERT(addr >= 1 && addr <= 127);
+KASSERTMSG(addr >= 1 && addr <= 127, "addr %u out of range",
+addr);
dev->ud_addr = addr;
/* XXX dev->ud_addr not necessarily unique on bus */
KASSERT(bus->ub_devices[dev->ud_addr] == NULL);


I will add this on my next kernel build.  The messages look useful, even if I 
cannot reproduce my panic!




--
t-hash

Re: Crash in xhci driver

[Takahiro Hayashi]

Hi,

On 2016/06/27 09:22, Paul Goyette wrote:

Hmmm, my system was totally idle (just running xlockmore's "maze" screen 
saver!), and suddenly panic()d.

Here's the traceback (manually transcribed):

vpanic + 0x140
cd_play_msf
xhci_new_device + 0x821
usbd_new_device + 0x3e
uhub_explore + 0x2fa
usb_discover.isra.2 + 0x4e (interesting symbol name!)
usb_event_thread + 0x7c

According to gdb(1), this was the KASSERT() at sys/dev/usb/xhci.c:2106

2101//hexdump("slot context", cp, sc->sc_ctxsz);
2102uint8_t addr = XHCI_SCTX_3_DEV_ADDR_GET(cp[3]);
2103DPRINTFN(4, "device address %u", addr, 0, 0, 0);
2104/* XXX ensure we know when the hardware does something
2105   we can't yet cope with */
2106KASSERT(addr >= 1 && addr <= 127);
2107dev->ud_addr = addr;
2108/* XXX dev->ud_addr not necessarily unique on bus */
2109KASSERT(bus->ub_devices[dev->ud_addr] == NULL);
2110bus->ub_devices[dev->ud_addr] = dev;

No devices were being inserted (or removed), so I'm unsure why it would be 
calling xhci_new_device().  The comments in the source seem to say that this 
code only gets called when a new device has been found


Does your PC have usb keyboard and mice?
What is the PCI vendor and product number of xHCI?
Does your kernel say anything before panic after boot?
and, How frequently does the panic happen?



Obviously, the hardware did "some we can't yet cope with"   :)


could you try this patch?

--- sys/dev/usb/xhci.c.bak  2016-06-13 01:32:30.0 +0900
+++ sys/dev/usb/xhci.c  2016-06-27 18:27:55.0 +0900
@@ -2091,8 +2129,10 @@ xhci_new_device(device_t parent, struct
 
 		/* 4.3.4 Address Assignment */

err = xhci_set_address(dev, slot, false);
-   if (err)
+   if (err) {
+   printf("%s: set address w/ bsr %u\n", __func__, err);
goto bad;
+   }
 
 		/* Allow device time to set new address */

usbd_delay_ms(dev, USB_SET_ADDRESS_SETTLE);
@@ -2103,7 +2143,8 @@ xhci_new_device(device_t parent, struct
DPRINTFN(4, "device address %u", addr, 0, 0, 0);
/* XXX ensure we know when the hardware does something
   we can't yet cope with */
-   KASSERT(addr >= 1 && addr <= 127);
+   KASSERTMSG(addr >= 1 && addr <= 127, "addr %u out of range",
+   addr);
dev->ud_addr = addr;
/* XXX dev->ud_addr not necessarily unique on bus */
KASSERT(bus->ub_devices[dev->ud_addr] == NULL);


cheers,
--
t-hash

Re: umass problem with xhci (USB 3)

[Takahiro Hayashi]

Hi,

On 2016/06/04 09:34, Paul Goyette wrote:

With a kernel built from sources dated 2016-05-29 at 23:57:35 UTC, when 
attaching my external hard drive (near-line backup device), I get the following 
messages:

uhub0 at usb0: vendor 8086 xHCI Root Hub, class 9/0, rev 1.00/1.00, addr 0
...
Jun  4 08:21:37 pokey /netbsd: umass0 at uhub0 port 2 configuration 1 interface 0
Jun  4 08:21:37 pokey /netbsd: umass0: Western Digital Ext HDD 1021, rev 
2.00/20.02, addr 24
Jun  4 08:21:37 pokey /netbsd: umass0: using SCSI over Bulk-Only
Jun  4 08:21:37 pokey /netbsd: umass0: failed to create xfers

Interestingly, even though this motherboard has both USB2 and USB3 ports, and 
dmesg includes

uhub1 at usb1: vendor 8086 EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
...
uhub2 at uhub1 port 1: vendor 8087 product 8000, class 9/0, rev 2.00/0.05, addr2

but every device I plug in, regardless of USB connector, gets attached to uhub0 
(the one for xHCI)!  So I cannot get the external drive to work by connecting 
to a USB2 port.

Any suggestions?


To avoid the problem, please add "userconf=disable xhci*" to /boot.cfg.

The xhci driver tries to route all USB ports (even 2.0) to xhci
as possible if it's Intel PCH. (see sys/dev/pci/xhci_pci.c)
You can see some information about port routing by booting kernel -x.


--
t-hash

Re: nick-nhusb merge coming soon

[Takahiro Hayashi]

On 2016/04/14 17:40, Nick Hudson wrote:

I summarise known problems:

+ KASSERT(sc->sc_command_addr == 0) in xhci_do_command() may fail.
+ My ASM1042 card does not work at all.  No interrupts.
  It works on FreeBSD and OpenBSD.



http://nxr.netbsd.org/xref/src-freebsd/sys/dev/usb/controller/xhci.c#1226

Is that relevant here?


Not sure, but I'll try it.


+ Implementation of upm_abort is imcomplete.

I'll try and look into this soon.


I mean implementation of abort_xfer method in xhci.c is incomplete.


+ Link Power management is not implemented.
+ Isochronous transfer is not implemented.
+ Stream protocol is not supported.


Takers? :)


+ Address of root hub is 0 (but it works anyway).


I'll also try and look into this


+ On the xhci of Intel PCH:
  + The address assigned to device increases when reattaching device.
  + HS hub in 3.0 hub under 3.0 port is disconnected and reconnected every
several minutes repeatedly.


ENOHARDWARE


Does your laptop have Intel chipset?






regards,
--
t-hash


Thanks,
Nick




thanks,
--
t-hash

Re: nick-nhusb merge coming soon

[Takahiro Hayashi]

On 2016/04/13 16:56, Nick Hudson wrote:

On 04/13/16 08:15, Paul Goyette wrote:

On Wed, 13 Apr 2016, Nick Hudson wrote:


Hi,

I think the first phase of nick-nhusb is in a state ready to be
merged. I'd like to merge it in the next few days, but in the meantime
I've put some kernels for testing here:

   http://www.netbsd.org/~skrll/nick-nhusb


Please test and report success or failure.

I can provide kernels to other platforms on request.


Kewl!

Does this include xhci support for USB3 (ie, removal of the "experimental" tag)?


There is some support for USB3 which has come with the patches from Takahiro 
HAYASHI.

xhci(4) still needs quite a bit of love to be fully ready.


xhci(4) is still imcomplete and experimental.
It needs more work.

I summarise known problems:

+ KASSERT(sc->sc_command_addr == 0) in xhci_do_command() may fail.
+ My ASM1042 card does not work at all.  No interrupts.
  It works on FreeBSD and OpenBSD.
+ Implementation of upm_abort is imcomplete.
+ Link Power management is not implemented.
+ Isochronous transfer is not implemented.
+ Stream protocol is not supported.
+ Address of root hub is 0 (but it works anyway).
+ On the xhci of Intel PCH:
  + The address assigned to device increases when reattaching device.
  + HS hub in 3.0 hub under 3.0 port is disconnected and reconnected every
several minutes repeatedly.


regards,
--
t-hash

Re: panic in arptimer

[Takahiro Hayashi]

Hello,

On 2015/10/20 16:59, Ryota Ozaki wrote:

On Mon, Oct 19, 2015 at 6:33 PM, Ryota Ozaki <ozak...@netbsd.org> wrote:

Hi,

I've reproduced the panic on my machine and I'm investing
the problem.


A possible fix has been committed. Could you try a latest kernel?
(a kernel binary will be built in several hours.)


I have updated my local tree and confirmed the problem is fixed.
Thank you for working on this prob.


tips: by doing sysctl -w net.inet.arp.keep=30, you don't need to
wait for 1200 seconds.


Thank you for nice tip.



Thank you for the report,
   ozaki-r

On Mon, Oct 19, 2015 at 4:10 PM, Takahiro Hayashi <t.hash...@gmail.com> wrote:

Hello,

Kernel panics in arptimer after detaching network interface.
See dmesg below please.
It happened on NetBSD/amd64 on GENERIC.201510182130Z from nyftp.
I think this problem looks like kern/50186.


BTW I think this problem is different from PR kern/50186.

Regards,
   ozaki-r



How-To-Repeat:
1. Boot kernel into single user mode with "boot netbsd -s".
2. sysctl -w net.inet6.ip6.auto_linklocal=0
3. ifconfig interface .
4. Send one ping to other host.
5. Detach the interface with "drvctl -d".
6. Wait about 1200 seconds (actually 1200 sec after ping is sent).


I saw following panic after detaching "re0".

fatal page fault in supervisor mode
trap type 6 code 0 rip 808cbf2f cs 8 rflags 10246 cr2
873c7368 ilevel 2 rsp fe80dabd1f08
curlwp 0xfe81071a30c0 pid 0.22 lowest kstack 0xfe80dabce2c0
kernel: page fault trap, code=0
Stopped in pid 0.22 (system) at netbsd:arptimer+0xc4:   movq
360(%r15),%rdi
db{1}> bt
arptimer() at netbsd:arptimer+0xc4
callout_softclock() at netbsd:callout_softclock+0x1d0
softint_dispatch() at netbsd:softint_dispatch+0xd3
DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfe80dabd1ff0
Xsoftintr() at netbsd:Xsoftintr+0x4f
--- interrupt ---
0:
db{1}> show reg
ds  1ee8
es  4040
fs  600
gs  3d5e
rdi fe81078c8a00
rsi f800
rbp fe80dabd1f38
rbx fe81078c8908
rdx 0
rcx 7
rax fe81071a30c4
r8  fe8107184040
r9  7d
r10 fe811eb244f4
r11 246
r12 fe81078c8a00
r13 fe81078c89b0
r14 0
r15 873c7008
rip 808cbf2farptimer+0xc4
cs  8
rflags  10246
rsp fe80dabd1f08
ss  10
netbsd:arptimer+0xc4:   movq360(%r15),%rdi
db{1}>


I met folloging panic after "drvctl -d axe0".

fatal page fault in supervisor mode
trap type 6 code 2 rip 8011bcdd cs 8 rflags 10282 cr2 0 ilevel 2 rsp
fe80dabd1f00
curlwp 0xfe81071a30c0 pid 0.22 lowest kstack 0xfe80dabce2c0
kernel: page fault trap, code=0
Stopped in pid 0.22 (system) at netbsd:rw_enter+0x2d:   lock cmpxchgq
%rcx,0(%
rdi)
db{1}> bt
rw_enter() at netbsd:rw_enter+0x2d
callout_softclock() at netbsd:callout_softclock+0x1d0
softint_dispatch() at netbsd:softint_dispatch+0xd3
DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfe80dabd1ff0
Xsoftintr() at netbsd:Xsoftintr+0x4f
--- interrupt ---
0:
db{1}> show reg
ds  1ee8
es  0
fs  fc00
gs  3d5e
rdi 0
rsi 1
rbp fe80dabd1f38
rbx fe811dbc8188
rdx 0
rcx fe81071a30c4
rax 0
r8  fe8107184040
r9  7d
r10 fe811eb244f4
r11 246
r12 fe811dbc8280
r13 fe811dbc8230
r14 0
r15 fe811de0b010
rip 8011bcddrw_enter+0x2d
cs  8
rflags  10282
rsp fe80dabd1f00
ss  10
netbsd:rw_enter+0x2d:   lock cmpxchgq   %rcx,0(%rdi)
db{1}>


--
t-hash




--
t-hash

panic in arptimer

[Takahiro Hayashi]

Hello,

Kernel panics in arptimer after detaching network interface.
See dmesg below please.
It happened on NetBSD/amd64 on GENERIC.201510182130Z from nyftp.
I think this problem looks like kern/50186.

How-To-Repeat:
1. Boot kernel into single user mode with "boot netbsd -s".
2. sysctl -w net.inet6.ip6.auto_linklocal=0
3. ifconfig interface .
4. Send one ping to other host.
5. Detach the interface with "drvctl -d".
6. Wait about 1200 seconds (actually 1200 sec after ping is sent).


I saw following panic after detaching "re0".

fatal page fault in supervisor mode
trap type 6 code 0 rip 808cbf2f cs 8 rflags 10246 cr2 873c7368 
ilevel 2 rsp fe80dabd1f08
curlwp 0xfe81071a30c0 pid 0.22 lowest kstack 0xfe80dabce2c0
kernel: page fault trap, code=0
Stopped in pid 0.22 (system) at netbsd:arptimer+0xc4:   movq360(%r15),%rdi
db{1}> bt
arptimer() at netbsd:arptimer+0xc4
callout_softclock() at netbsd:callout_softclock+0x1d0
softint_dispatch() at netbsd:softint_dispatch+0xd3
DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfe80dabd1ff0
Xsoftintr() at netbsd:Xsoftintr+0x4f
--- interrupt ---
0:
db{1}> show reg
ds  1ee8
es  4040
fs  600
gs  3d5e
rdi fe81078c8a00
rsi f800
rbp fe80dabd1f38
rbx fe81078c8908
rdx 0
rcx 7
rax fe81071a30c4
r8  fe8107184040
r9  7d
r10 fe811eb244f4
r11 246
r12 fe81078c8a00
r13 fe81078c89b0
r14 0
r15 873c7008
rip 808cbf2farptimer+0xc4
cs  8
rflags  10246
rsp fe80dabd1f08
ss  10
netbsd:arptimer+0xc4:   movq360(%r15),%rdi
db{1}>


I met folloging panic after "drvctl -d axe0".

fatal page fault in supervisor mode
trap type 6 code 2 rip 8011bcdd cs 8 rflags 10282 cr2 0 ilevel 2 rsp 
fe80dabd1f00
curlwp 0xfe81071a30c0 pid 0.22 lowest kstack 0xfe80dabce2c0
kernel: page fault trap, code=0
Stopped in pid 0.22 (system) at netbsd:rw_enter+0x2d:   lock cmpxchgq   %rcx,0(%
rdi)
db{1}> bt
rw_enter() at netbsd:rw_enter+0x2d
callout_softclock() at netbsd:callout_softclock+0x1d0
softint_dispatch() at netbsd:softint_dispatch+0xd3
DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfe80dabd1ff0
Xsoftintr() at netbsd:Xsoftintr+0x4f
--- interrupt ---
0:
db{1}> show reg
ds  1ee8
es  0
fs  fc00
gs  3d5e
rdi 0
rsi 1
rbp fe80dabd1f38
rbx fe811dbc8188
rdx 0
rcx fe81071a30c4
rax 0
r8  fe8107184040
r9  7d
r10 fe811eb244f4
r11 246
r12 fe811dbc8280
r13 fe811dbc8230
r14 0
r15 fe811de0b010
rip 8011bcddrw_enter+0x2d
cs  8
rflags  10282
rsp fe80dabd1f00
ss  10
netbsd:rw_enter+0x2d:   lock cmpxchgq   %rcx,0(%rdi)
db{1}>


--
t-hash

show kernhist in crash

[Takahiro HAYASHI]

Anyone interested in the patch of adding show kernhist to crash(8)?



--- src/sys/sys/kernhist.h.orig 2014-03-31 16:25:43.0 +0900
+++ src/sys/sys/kernhist.h  2015-05-09 22:32:06.0 +0900
@@ -86,7 +86,7 @@ LIST_HEAD(kern_history_head, kern_histor
 #defineKERNHIST_UVMUBCHIST 0x0004  /* ubchist */
 #defineKERNHIST_UVMLOANHIST0x0008  /* loanhist */
 
-#ifdef _KERNEL

+#if defined(_KERNEL) || defined(_KMEMUSER)
 
 /*

  * macros to use the history/tracing code.  note that KERNHIST_LOG
@@ -216,6 +216,10 @@ do { \
 #endif
 
 
+#ifdef _KMEMUSER

+#include stdio.h   /* for printf */
+#endif
+
 static inline void kernhist_entry_print(const struct kern_history_ent *);
 
 static inline void

--- src/usr.sbin/crash/Makefile.orig2015-02-10 18:49:36.0 +0900
+++ src/usr.sbin/crash/Makefile 2015-05-09 22:35:11.0 +0900
@@ -35,6 +35,7 @@ S=${.CURDIR}/../../sys
 CPPFLAGS+= -I${.CURDIR} -I${.OBJDIR} -I${S} -fno-strict-aliasing
 CPPFLAGS+= -DDDB_VERBOSE_HELP -DDB_MAX_LINE=1000 -D_KMEMUSER
 CPPFLAGS+= -UDB_MACHINE_COMMANDS
+CPPFLAGS+= -DKERNHIST -DDDB -Wno-format-nonliteral
 
 # ddb files from kernel

 .PATH: $S/ddb
@@ -42,6 +43,7 @@ SRCS+=db_command.c db_lwp.c db_proc.c d
 SRCS+= db_access.c db_elf.c db_examine.c
 SRCS+= db_expr.c db_lex.c db_output.c db_print.c
 SRCS+= db_sym.c db_variables.c db_write_cmd.c
+CPPFLAGS.db_command.c += -DKERNHIST -DDDB -Wno-format-nonliteral
 
 .PATH:	${S}/arch/${MACHINE}/${MACHINE}

 .PATH: ${S}/arch/${MACHINE_ARCH}/${MACHINE_ARCH}
--- src/usr.sbin/crash/crash.c.orig 2014-10-06 22:57:38.0 +0900
+++ src/usr.sbin/crash/crash.c  2015-05-09 23:10:13.0 +0900
@@ -53,6 +53,7 @@ __RCSID($NetBSD: crash.c,v 1.8 2014/10/
 #include err.h
 #include ctype.h
 #include util.h
+#include sys/kernhist.h
 
 #include extern.h
 
@@ -72,6 +73,8 @@ static struct nlist nl[] = {

{ .n_name = _osrelease },
 #defineX_PANICSTR  1
{ .n_name = _panicstr },
+#defineX_KERN_HISTORIES2
+   { .n_name = _kern_histories },
{ .n_name = NULL },
 };
 
@@ -301,6 +304,50 @@ cnputc(int c)

putc(c, ofp);
 }
 
+#define FMTLEN 1024

+#define FNLEN 128
+
+void
+kernhist_dump(struct kern_history *l)
+{
+   unsigned int lcv;
+   struct kern_history kh;
+   struct kern_history_ent ke;
+   char fmt[FMTLEN];
+   char fn[FNLEN];
+
+   db_read_bytes((db_addr_t)l, sizeof(kh), (char *)kh);
+   lcv = kh.f;
+   do {
+   db_read_bytes((db_addr_t)kh.e[lcv], sizeof(ke), (char *)ke);
+   if (ke.fmt) {
+   db_read_bytes((db_addr_t)ke.fmt, sizeof(fmt), fmt);
+   db_read_bytes((db_addr_t)ke.fn, sizeof(fn), fn);
+   fmt[FMTLEN-1] = '\0';
+   fn[FNLEN-1] = '\0';
+   ke.fmt = fmt;
+   ke.fn = fn;
+   kernhist_entry_print(ke);
+   }
+   lcv = (lcv + 1) % kh.n;
+   } while (lcv != kh.f);
+}
+
+void
+kernhist_print(void (*pr)(const char *, ...))
+{
+   struct kern_history_head khh;
+
+   if (nl[X_KERN_HISTORIES].n_value == 0) {
+   warnx(kernhist is not available);
+   return;
+   }
+
+   db_read_bytes(nl[X_KERN_HISTORIES].n_value, sizeof(khh), (char *)khh);
+
+   kernhist_dump(LIST_FIRST(khh));
+}
+
 __dead static void
 usage(void)
 {


--
t-hash

Re: point2point network interfaces cannot receive ipv6 packets

[Takahiro HAYASHI]

hi,

Add tech-net@ to To:.

On 2015/04/09 21:39, Justin Cormack wrote:

On 9 April 2015 at 12:10, Kengo NAKAHARA k-nakah...@iij.ad.jp wrote:

Hi,

On 2015/04/03 16:14, Takahiro HAYASHI wrote:

It seems that IFF_POINTTOPOINT interfaces like tun and gif cannot
receive ipv6 packets.
This occurs on NetBSD/amd64 -current since Feb 27 2015.

For example, establishing gif tunnnel between 2 hosts.

[host1] --- [host2]
192.168.0.1   192.168.0.2  ipv4 address of real interface
fd00::1   fd00::2  gif address

When I ping6, a host can send ICMPv6 ECHO(128), but the other host
returns ICMPv6 DST_UNREACH(1) code UNREACH_ADDR(3) to pinging host.


I think the reason of this issue is below commit:
 
http://www.nerv.org/netbsd/?q=id:20150226T095446Z.75354d997222ae09acc944ba1c6cf573c3ea724b

This commit changes the route entry for gif as describe below
== before ==
Internet6:
DestinationGatewayFlagsRefs 
 UseMtu Interface
fd00::2link#13UHL 0 
   0  -  lo0
== before ==
== after ==
Internet6:
DestinationGatewayFlagsRefs 
 UseMtu Interface
fd00::2fd00::2UH  - 
   -  -  gif0
== after ==

This route change caused the function flow change in ip6_input(), in
paticular the below line
 http://nxr.netbsd.org/xref/src/sys/netinet6/ip6_input.c#497
After above commit, this statement become false, and then, the packets
is discarded through line#565.

I found the above reason, however I have no idea to fix this issue...


Thank you for your analysis.
Newer netstat shows gif0 route like this:

fd00::2fd00::2UHl  
--  -  gif0



Could you file a PR?


I'll do.



Justin



--
t-hash

Re: Help: USB 3.0 xHCI driver does not support non-root hub

[Takahiro HAYASHI]

Hello,

I think 3.0 hub should work with this patch, but
either HS hub or SS hub in 3.0 hub may not be recognised.

still xhci is at best experimental.


Fixes:

- Fix incorrect route string was set.
  Correct route string does not contain root hub port.
- Fix FS and LS devices were not recognised.
  Speed values were swapped.

Known bugs:

- 3.0 hub should work, but either HS hub or SS hub in 3.0 hub
  may not be recognised.
  It looks one of these simultaneous interrupts is lost.
- xhci may not recognise devices at boot.
  This is regression.
- Detaching hubs or devices may cause panic.
- MTT,TTT and TT* fields in slot context is not set.
- Power management is not implemented.

Misc bugs:

- Closing pipe does not work correctly,
  e.g. ifconfig axen0 up - down - up won't work.
- Some of umass devices won't work due to STALL error.
  They don't understand MODE_SENSE_{6,10} command but stalls.
  xhci.c cannot recover stalled bulk endpoints.
- xhci.c cannot handle cross-64k transfer yet.
- Memory leaks here and there in error paths.
- Slot leaks.
  Devices cannot be added more than 32 times on xhci.
- Conextant umodem is not recognised (fail with XACT/PARAMETER).
  hm what is missing...
- may not work on big endian.
- Address of root hub is 0.
- needs more comments.


If your xhci fortunately recognise 3.0 hub successfully,
things will go like this:

# usbdevs -dv -f /dev/usb5
Controller /dev/usb5:
addr 0: super speed, self powered, config 1, xHCI Root Hub(0x), NetBSD(0x000
0), rev 1.00
  uhub0
 port 1 addr 1: super speed, self powered, config 1, USB3.0 Hub(0x0616), Genesys
Logic(0x05e3), rev 4.01
   uhub6
  port 1 powered
  port 2 powered
  port 3 addr 3: super speed, power 124 mA, config 1, AX88179(0x1790), ASIX Elec
. Corp.(0x0b95), rev 1.00, serial xx
axen0
  port 4 addr 2: super speed, power 126 mA, config 1, ADATA USB Flash Drive(0x31
2b), ADATA(0x125f), rev 11.00, serial 
umass0
 port 2 powered
# dd if=/dev/rsd0d bs=256k count=1024 of=/dev/null msgfmt=human
1024+0 records in
1024+0 records out
268435456 bytes (256 MB) transferred in 3.614 secs (74276551 bytes/sec - 71 MB/s
ec)
#


Thanks,
--
t-hash
--- src/sys/dev/usb/uhub.c.orig 2014-08-14 07:02:24.0 +0900
+++ src/sys/dev/usb/uhub.c  2014-10-12 09:08:20.0 +0900
@@ -38,12 +38,15 @@
 #include sys/cdefs.h
 __KERNEL_RCSID(0, $NetBSD: uhub.c,v 1.126 2014/08/13 06:26:32 skrll Exp $);
 
+#include opt_usb.h
+
 #include sys/param.h
 #include sys/systm.h
 #include sys/kernel.h
 #include sys/malloc.h
 #include sys/device.h
 #include sys/proc.h
+#include sys/sysctl.h
 
 #include sys/bus.h
 
@@ -52,14 +55,44 @@ __KERNEL_RCSID(0, $NetBSD: uhub.c,v 1.1
 #include dev/usb/usbdi_util.h
 #include dev/usb/usbdivar.h
 
-#ifdef UHUB_DEBUG
-#define DPRINTF(x) if (uhubdebug) printf x
-#define DPRINTFN(n,x)  if (uhubdebug(n)) printf x
-intuhubdebug = 0;
-#else
+#ifdef USB_DEBUG
+#ifndef UHUB_DEBUG
+#define uhubdebug 0
 #define DPRINTF(x)
 #define DPRINTFN(n,x)
-#endif
+#else
+intuhubdebug = 0;
+#define DPRINTF(x) if (uhubdebug) printf x
+#define DPRINTFN(n,x)  if (uhubdebug(n)) printf x
+
+SYSCTL_SETUP(sysctl_hw_uhub_setup, sysctl hw.uhub setup)
+{
+   int err;
+   const struct sysctlnode *rnode;
+   const struct sysctlnode *cnode;
+
+   err = sysctl_createv(clog, 0, NULL, rnode,
+   CTLFLAG_PERMANENT, CTLTYPE_NODE, uhub,
+   SYSCTL_DESCR(uhub global controls),
+   NULL, 0, NULL, 0, CTL_HW, CTL_CREATE, CTL_EOL);
+
+   if (err)
+   goto fail;
+
+   /* control debugging printfs */
+   err = sysctl_createv(clog, 0, rnode, cnode,
+   CTLFLAG_PERMANENT|CTLFLAG_READWRITE, CTLTYPE_INT,
+   debug, SYSCTL_DESCR(Enable debugging output),
+   NULL, 0, uhubdebug, sizeof(uhubdebug), CTL_CREATE, CTL_EOL);
+   if (err)
+   goto fail;
+
+   return;
+fail:
+   aprint_error(%s: sysctl_createv failed (err = %d)\n, __func__, err);
+}
+#endif /* UHUB_DEBUG */
+#endif /* USB_DEBUG */
 
 struct uhub_softc {
device_tsc_dev; /* base device */
@@ -77,7 +110,12 @@ struct uhub_softc {
u_char  sc_running;
 };
 
+#if 1
+#define UHUB_IS_HIGH_SPEED(sc) \
+((sc)-sc_proto == UDPROTO_HSHUBSTT || (sc)-sc_proto == UDPROTO_HSHUBMTT)
+#else
 #define UHUB_IS_HIGH_SPEED(sc) ((sc)-sc_proto != UDPROTO_FSHUB)
+#endif
 #define UHUB_IS_SINGLE_TT(sc) ((sc)-sc_proto == UDPROTO_HSHUBSTT)
 
 #define PORTSTAT_ISSET(sc, port) \
@@ -182,6 +220,47 @@ uhub_attach(device_t parent, device_t se
}
 
/* Get hub descriptor. */
+#if 1
+   memset(hubdesc, 0, sizeof(hubdesc));
+   if (dev-speed == USB_SPEED_SUPER  dev-depth != 0) {
+   usb_hub_ss_descriptor_t hubssdesc;
+
+   /* XXX: should add member hubssdesc to usbd_hub ? */
+   memset(hubssdesc, 0, sizeof(hubssdesc));
+   req.bmRequestType = UT_READ_CLASS_DEVICE;

Re: Help: USB 3.0 xHCI driver does not support non-root hub

[Takahiro HAYASHI]

On 10/12/14 12:34, I wrote:

- 3.0 hub should work, but either HS hub or SS hub in 3.0 hub
   may not be recognised.
   It looks one of these simultaneous interrupts is lost.


uhub_intr() drops latter interrupt while uhub is exploring
(sc_explorepending=1) for devices of former interrupt.

I tried to change root hub of xhci not to overlap SS and HS ports,
and add force rescan like roothub for ehci does in uhub.c.

uPD720200:

xhci0: SP: 03000402 20425355 0201
xhci0: SP: 0202 20425355 0203


# usbdevs -dv -f /dev/usb5
Controller /dev/usb5:
addr 0: super speed, self powered, config 1, xHCI Root Hub(0x), NetBSD(0x000
0), rev 1.00
  uhub0
 port 1 addr 7: super speed, self powered, config 1, USB 3.0 HUB
(0x0812), VLI Labs, Inc.(0x2109), rev 85.71
   uhub8
  port 1 powered
  port 2 powered
  port 3 addr 8: super speed, self powered, config 1, USB3.0 Hub(0x0616), Genesy
sLogic(0x05e3), rev 4.01
uhub9
   port 1 powered
   port 2 powered
   port 3 powered
   port 4 powered
  port 4 powered
 port 2 powered
 port 3 addr 5: high speed, self powered, config 1, USB 2.0 HUB
(0x2812), vendor 2109(0x2109), rev 85.70
   uhub6
  port 1 powered
  port 2 powered
  port 3 addr 6: high speed, self powered, config 1, USB2.0 Hub(0x0610), Genesys
Logic(0x05e3), rev 4.01
uhub7
   port 1 powered
   port 2 powered
   port 3 powered
   port 4 powered
  port 4 powered
 port 4 powered
#

BayTrail:

xhci0: SP: 02000802 20425355 30100601
xhci0: SP: 03000802 20425355 1107


# usbdevs -dv
Controller /dev/usb0:
addr 0: super speed, self powered, config 1, xHCI Root Hub(0x), NetBSD(0x000
0), rev 1.00
  uhub0
 port 1 addr 3: high speed, self powered, config 1, USB 2.0 HUB
(0x2812), vendor 2109(0x2109), rev 85.70
   uhub3
  port 1 powered
  port 2 powered
  port 3 addr 4: high speed, self powered, config 1, USB2.0 Hub(0x0610), Genesys
Logic(0x05e3), rev 4.01
uhub4
   port 1 powered
   port 2 powered
   port 3 powered
   port 4 powered
  port 4 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 powered
 port 6 powered
 port 7 addr 1: super speed, self powered, config 1, USB 3.0 HUB
(0x0812), VLI Labs, Inc.(0x2109), rev 85.71
   uhub1
  port 1 powered
  port 2 powered
  port 3 addr 2: super speed, self powered, config 1, USB3.0 Hub(0x0616), Genesy
sLogic(0x05e3), rev 4.01
uhub2
   port 1 powered
   port 2 powered
   port 3 powered
   port 4 powered
  port 4 powered
#


--
t-hash

Re: Help: USB 3.0 xHCI driver does not support non-root hub

[Takahiro HAYASHI]

hi,

On 09/15/14 23:46, Ryo ONODERA wrote:

Hi,

Our xHCI USB 3.0 driver with Intel Lynx Point/Lynx Point-LP, Renesas uPD70202
and Fresco Logic 0x1b73/0x1100 xHCI chips does not support non-root hub
as following.
I believe our xHCI driver have no non-root hub support.

I have tested some USB 1.1/2.0/3.0 hubs, and gotten same results.
Address Device Command TRB execution just after Enable Slot Command TRB
execution fails with USB Transaction Error.


I got PARAMETER error when i connected usb 2.0 thumb drive to
my uPD720200 xhci via 2.0 hub.


I have spent some weeks, but I cannot find why Address Device Command fails.
(If your want to use Intel Lynx Point/Lynx Point-LP xHC, please
apply a patch in http://gnats.netbsd.org/49076.)


I think that's because incorrect route string (always 0x0) and
incorrect root hub port is set in slot context.


Anyone have a clue for xHCI's non-root hub support?
I really need any clue for non-root hub support.


Can you try this patch?

This patch tries to add route string support for hubs.
Caveats:
- SS hub is currently not supported.
  SS hub will work as HS hub.
  I'm not sure both of SS and HS hub in SS hub can be
  attached on one roothub port.
- Detaching hub may cause panic.
  xhci may try to transfer on unplugged port.
- HUB,MTT,TTT and TT* fields in slot context is not set.


--- src/sys/dev/usb/xhci.c.orig 2014-10-03 21:18:24.0 +0900
+++ src/sys/dev/usb/xhci.c  2014-10-04 08:59:16.0 +0900
@@ -615,8 +760,12 @@ xhci_init(struct xhci_softc *sc)
 
 	XHCIHIST_FUNC(); XHCIHIST_CALLED();
 
+#if 0

+   sc-sc_bus.usbrev = USBREV_3_0;
+#else
/* XXX Low/Full/High speeds for now */
sc-sc_bus.usbrev = USBREV_2_0;
+#endif
 
 	cap = xhci_read_4(sc, XHCI_CAPLENGTH);

caplength = XHCI_CAP_CAPLENGTH(cap);
@@ -1139,8 +1449,7 @@ xhci_open(usbd_pipe_handle pipe)
return USBD_IOERROR;
 
 	/* Root Hub */

-   if (dev-depth == 0  dev-powersrc-portno == 0 
-   dev-speed != USB_SPEED_SUPER) {
+   if (dev-depth == 0  dev-powersrc-portno == 0) {
switch (ed-bEndpointAddress) {
case USB_CONTROL_ENDPOINT:
pipe-methods = xhci_root_ctrl_methods;
@@ -1194,13 +1631,24 @@ xhci_rhpsc(struct xhci_softc * const sc,
if (xfer == NULL)
return;
 
-	if (!(port = sc-sc_hs_port_start 

-   port  sc-sc_hs_port_start + sc-sc_hs_port_count))
-   return;
+   xfer-pipe-device-speed =
+   XHCI_PS_SPEED_GET(xhci_op_read_4(sc, XHCI_PORTSC(port)));
 
-	port -= sc-sc_hs_port_start;

-   port += 1;
-   DPRINTFN(4, hs port %u status change, port, 0, 0, 0);
+   if (port = sc-sc_hs_port_start 
+   port  sc-sc_hs_port_start + sc-sc_hs_port_count) {
+   port -= sc-sc_hs_port_start;
+   port += 1;
+   DPRINTFN(4, hs port %u status change, port, 0, 0, 0);
+   } else if (port = sc-sc_ss_port_start 
+   port  sc-sc_ss_port_start + sc-sc_ss_port_count) {
+   port -= sc-sc_ss_port_start;
+   port += 1;
+   DPRINTFN(4, ss port %u status change, port, 0, 0, 0);
+   } else {
+   /* cannot happen */
+   DPRINTFN(0, port %u out of range, port, 0, 0, 0);
+   return;
+   }
 
 	p = KERNADDR(xfer-dmabuf, 0);

memset(p, 0, xfer-length);
@@ -1468,7 +1974,7 @@ xhci_new_device(device_t parent, usbd_bu
usbd_status err;
usb_device_descriptor_t *dd;
struct usbd_device *hub;
-   struct usbd_device *adev;
+   uint32_t route = 0;
int rhport = 0;
struct xhci_slot *xs;
uint32_t *cp;
@@ -1515,28 +2017,32 @@ xhci_new_device(device_t parent, usbd_bu
up-device = dev;
 
 	/* Locate root hub port */

-   for (adev = dev, hub = dev;
-   hub != NULL;
-   adev = hub, hub = hub-myhub) {
-   DPRINTFN(4, hub %p, hub, 0, 0, 0);
-   }
-   DPRINTFN(4, hub %p, hub, 0, 0, 0);
-
-   if (hub != NULL) {
-   for (int p = 0; p  hub-hub-hubdesc.bNbrPorts; p++) {
-   if (hub-hub-ports[p].device == adev) {
-   rhport = p;
-   }
-   }
-   } else {
-   rhport = port;
+   for (hub = dev; hub != NULL; hub = hub-myhub) {
+   uint32_t dep;
+
+   DPRINTFN(4, hub %p depth %d upport %p upportno %d,
+   hub, hub-depth, hub-powersrc,
+   hub-powersrc ? hub-powersrc-portno : 0);
+
+   if (hub-powersrc == NULL)
+   continue;
+   dep = hub-depth;
+   if (dep == 0)
+   continue;
+
+   route |= hub-powersrc-portno  ((dep - 1) * 4);
}
+   DPRINTFN(4, hub %p route %05x, hub, route, 0, 0);
+
if (speed == USB_SPEED_SUPER) {
-   rhport += sc-sc_ss_port_start - 1;
+

named build breakage with NAMED_USE_PTHREADS=no

[Takahiro HAYASHI]

Hello,

#else is missing in bind/dist/lib/isc/task_p.h.
I need this to run named on i486 that does not have CX8.

Index: src/external/bsd/bind/dist/lib/isc/task_p.h
===
RCS file: /cvsroot/src/external/bsd/bind/dist/lib/isc/task_p.h,v
retrieving revision 1.5
diff -u -p -r1.5 task_p.h
--- src/external/bsd/bind/dist/lib/isc/task_p.h 1 Mar 2014 03:24:39 -   
1.5
+++ src/external/bsd/bind/dist/lib/isc/task_p.h 13 Mar 2014 16:04:02 -
@@ -30,6 +30,7 @@ isc__taskmgr_pause(isc_taskmgr_t *taskmg
 
 void

 isc__taskmgr_resume(isc_taskmgr_t *taskmgr);
+#else
 isc_boolean_t
 isc__taskmgr_ready(isc_taskmgr_t *taskmgr);
 


--
t-hash

Re: named build breakage with NAMED_USE_PTHREADS=no

[Takahiro HAYASHI]

(03/29/14 21:58), I wrote:

#else is missing in bind/dist/lib/isc/task_p.h.
I need this to run named on i486 that does not have CX8.


Thank you for fix.

--
t-hash

Re: Automated report: NetBSD-current/i386 build failure

[Takahiro HAYASHI]

(03/30/14 07:46), Hisashi T Fujinaka wrote:

On Sun, 30 Mar 2014, Takahiro HAYASHI wrote:


(03/30/14 07:21), NetBSD Test Fixture wrote:

 --- task.pico ---
 cc1: warnings being treated as errors
 
/tmp/bracket/build/2014.03.29.20.53.55-i386/src/external/bsd/bind/dist/lib/isc/task.c:1643:1:
 error: no previous prototype for 'isc__taskmgr_resume'
 *** [task.pico] Error code 1
 nbmake[8]: stopped in 
/tmp/bracket/build/2014.03.29.20.53.55-i386/src/external/bsd/bind/lib/libisc


task_p.h should be:

#if defined(ISC_PLATFORM_USETHREADS)
void
isc__taskmgr_pause(isc_taskmgr_t *taskmgr);

void
isc__taskmgr_resume(isc_taskmgr_t *taskmgr);
#else
isc_boolean_t
isc__taskmgr_ready(isc_taskmgr_t *taskmgr);

isc_result_t
isc__taskmgr_dispatch(isc_taskmgr_t *taskmgr);
#endif /* !ISC_PLATFORM_USETHREADS */


I'm going to test and then can commit it.


joerg@ has already fixed this, and it builds completely.
Thank you!

--
t-hash

DRMKMS requires i2cexec and i2c_bitbang

[Takahiro HAYASHI]

files.drmkms should be fixed like following diff, or
build will fail if there are no other devices that require
i2cexec and i2c_bitbang, e.g. tl or cxdtv.

Index: src/sys/external/bsd/drm2/drm/files.drmkms
===
RCS file: /cvsroot/src/sys/external/bsd/drm2/drm/files.drmkms,v
retrieving revision 1.2
diff -u -r1.2 files.drmkms
--- src/sys/external/bsd/drm2/drm/files.drmkms  18 Mar 2014 18:20:42 -  
1.2
+++ src/sys/external/bsd/drm2/drm/files.drmkms  25 Mar 2014 19:21:37 -
@@ -11,7 +11,7 @@
 define drmkms_i2c
 
 define	drmkms

-device drmkms: drmkms_linux, drmkms_i2c
+device drmkms: drmkms_linux, drmkms_i2c, i2cexec, i2c_bitbang
 attach drmkms at drmkmsbus
 
 defflag		opt_drmkms.h	DRMKMS_DEBUG


--
t-hash

Re: something's wrong

[Takahiro HAYASHI]

Hello,

On Tue, 26 Nov 2013 21:20:45 +
Mindaugas Rasiukevicius rm...@netbsd.org wrote:

 Thomas Klausner w...@netbsd.org wrote:
  On Tue, Nov 26, 2013 at 08:34:15PM +, Mindaugas Rasiukevicius wrote:
   Thomas, Takahiro: can you try with the following change?
   
   http://mail-index.netbsd.org/source-changes/2013/11/26/msg049508.html
  
  Thanks for looking at this!
  
  The immediate effect is worse though: repeatable panic right after
  avail memory:
  panic: kernel diagnostic assertion level  SOFTINT_CONST failed: file
  .../sys/kern/kern_softint.c, line 343 fatal breakpoint trap in
  supervisor mode
 
 That was a bit too quick from me.  Sorry about that.  Please cvs up.

Thank you for debugging.

I checked out tree and run new kernel.
At least I can say, building speed gets back as fast as it takes on
6.99.23. It took more than 2 hours for amd64 on 6.99.27 w/ 8 cpu,
however, now it takes 38 min.

--
t-hash

Re: something's wrong

[Takahiro HAYASHI]

Hello,

Today I met hangup on 2 logical cpu box.

This box runs -current 2013.11.15.16.06.06 UTC with LOCKDEBUG.
I was doing ./build release for amd64 from HEAD tree
and running systat on console.
There are no network traffics other than ntp and incoming bcast/mcast.

There are no processes waiting on xchicv.
All tstile process waits on proc_lock.

I'll try to do same ./build on main build box w/ 8 threads.


fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 8015716d cs 8 rflags 202 cr2 7f7ff780c3d0 ilevel 
8 rsp fe8001003a78
curlwp 0xfe813fb27880 pid 0.2 lowest kstack 0xfe800100
Stopped in pid 0.2 (system) at  netbsd:breakpoint+0x5:  leave
db{0} ps
PIDLID S CPU FLAGS   STRUCT LWP *   NAME WAIT
219  1 3   1 0   fe811bee9980 as tstile
172851 3   1 0   fe81108ef560   x86_64--netbsd-o tstile
8698 1 3   0 0   fe810c426000cc1 tstile
148471 3   0 0   fe811bee9540   x86_64--netbsd-g tstile
242741 3   080   fe811fdea4e0 sh wait
146761 3   0 4   fe81116b0140 sh wait
4749 1 3   0 4   fe81393ceb00   x86_64--netbsd-g tstile
167931 3   1 40080   fe81393ce6c0 sh wait
249191 3   0 0   fe81209a74a0 nbmake tstile
196581 3   080   fe810912b600 sh wait
292511 3   0 0   fe811d12a500 nbmake tstile
296171 3   080   fe813b4a7260 sh wait
01 3   0 0   fe813b4a76a0 nbmake tstile
148911 3   180   fe8111365040 sh wait
157211 3   180   fe811fdea0a0 nbmake wait
103581 3   180   fe810afe62e0 sh wait
4902 1 3   0 0   fe81393ce280 nbmake tstile
164081 3   080   fe81209a78e0 sh wait
251411 3   0 0   fe813e634240 nbmake tstile
216821 3   0 0   fe8121c2b0e0 systat tstile
2631 1 3   080   fe8119ee52a0 sh wait
2172 1 3   0 0   fe813f1a3600 nbmake tstile
2449 1 3   080   fe813d9712c0 sh wait
2552 1 3   0 0   fe813e634680 nbmake tstile
2121 1 3   080   fe813d971b40 sh wait
2206 1 3   0 0   fe81076ec1a0 nbmake tstile
538  1 3   080   fe813e634ac0 sh wait
556  1 3   180   fe813f1a3a40 sh wait
559  1 3   180   fe813f1e9a60 sh wait
379  1 3   180   fe813f1a31c0   tcsh pause
372  1 3   180   fe81076ec5e0  login wait
341  1 3   080   fe813d8a7220   sshd select
311  1 3   080   fe813f1e9620 powerd kqueue
301  1 3   180   fe813eedc200   ntpd pause
176  1 2   0 0   fe813d8a7660syslogd
11 3   180   fe810779c160   init wait
0   52 3   0   200   fe813eedca80physiod physiod
0   51 3   0   200   fe81076eca20   aiodoned aiodoned
0   50 3   0   200   fe810775a120ioflush syncer
0   49 3   0   200   fe810781c180   pgdaemon pgdaemon
0   45 3   1   200   fe810775a560   usb4 usbevt
0   44 3   1   200   fe810775a9a0   usb3 usbevt
0   43 3   0   200   fe810763f100   usb2 usbevt
0   42 3   0   200   fe810763f540   usb1 usbevt
0   41 3   0   200   fe810775b9c0   usb0 usbevt
0   40 3   0   200   fe810781c5c0   usb5 usbevt
0   39 3   0   200   fe810781ca00  npfgc npfgccv
0   38 3   0   200   fe810775b580  unpgc unpgc
0   37 3   1   200   fe810775b140vmem_rehash vmem_rehash
0   36 3   0   200   fe810779c5a0  coretemp1 coretemp1
0   35 3   1   200   fe810779c9e0  coretemp0 coretemp0
0   26 3   0   200   fe810763f980atabus1 atath
0   25 3   1   200   fe81076210e0atabus0 atath
0   24 3   0   200   fe8107621520 usbtask-dr usbtsk
0   23 3   0   200   fe8107621960 usbtask-hc usbtsk
0   22 3   1   200   fe81074ef0c0xcall/1 xcall
0   21 1   1   200   fe81074ef500  softser/1
0   20 3   1   200   fe81074ef940  softclk/1 tstile
0   19 1   1   200   fe81074b00a0  softbio/1
0   18 1   1   200   

Re: something's wrong

[Takahiro HAYASHI]

Hello,

Thank you for your kindly explanation.

I will post ddb log in other mail as it gets quite large.


Regards,
--
t-hash

Re: something's wrong

[Takahiro HAYASHI]

Hello,

On Tue, 5 Nov 2013 10:07:49 +
David Brownlee a...@netbsd.org wrote:

 I've noticed a recent netbsd-6 xen DOM0 hanging on similar big
 compiles (firefox24/25) if run while the DOMUs are active. Possibly
 unrelated, but just as a data point.

I saw NetBSD/amd64 6.1_STABLE dom0 panics once while installing
netbsd-6 by doing ./build install=/ , but cannot reproduce it.
It resembles kern/48372.


uvm_fault(0x806f5860, 0x0, 1) - e
fatal page fault in supervisor mode
trap type 6 code 0 rip 802d4bc0 cs e030 rflags 10206 cr2  10 cpl 8 rsp 
a0001759bb80
kernel: page fault trap, code=0
Stopped in pid 0.9 (system) at  netbsd:vmem_xalloc+0x201:   movq10(%rax)
,%rax
?
ds  fffd
es  f1d2
fs  bb70
gs  b880
rdi 6
rsi 805d25b0static_bts+0x5b0
rbp a0001759bc50
rbx 4
rdx 0
rcx fffd
rax 0
r8  0
r9  0
r10 f000
r11 0
r12 805ceaf0static_vmems+0x1090
r13 1000
r14 805ceb08static_vmems+0x10a8
r15 0
rip 802d4bc0vmem_xalloc+0x201
cs  e030
rflags  10206
rsp a0001759bb80
ss  e02b
netbsd:vmem_xalloc+0x201:   movq10(%rax),%rax
db bt
vmem_xalloc() at netbsd:vmem_xalloc+0x201
vmem_alloc() at netbsd:vmem_alloc+0x7f
bt_refill() at netbsd:bt_refill+0x14f
vmem_xalloc() at netbsd:vmem_xalloc+0x80
vmem_alloc() at netbsd:vmem_alloc+0x7f
pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c
pool_grow() at netbsd:pool_grow+0x33
pool_get() at netbsd:pool_get+0x47
pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d
pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f
uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2
vmem_xalloc() at netbsd:vmem_xalloc+0xacd
vmem_alloc() at netbsd:vmem_alloc+0x7f
bt_refill() at netbsd:bt_refill+0x14f
vmem_xalloc() at netbsd:vmem_xalloc+0x80
vmem_alloc() at netbsd:vmem_alloc+0x7f
pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c
pool_grow() at netbsd:pool_grow+0x33
pool_get() at netbsd:pool_get+0x47
pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d
pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f
uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2
vmem_xalloc() at netbsd:vmem_xalloc+0xacd
vmem_alloc() at netbsd:vmem_alloc+0x7f
bt_refill() at netbsd:bt_refill+0x14f
vmem_xalloc() at netbsd:vmem_xalloc+0x80
vmem_alloc() at netbsd:vmem_alloc+0x7f
pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c
pool_grow() at netbsd:pool_grow+0x33
pool_get() at netbsd:pool_get+0x47
pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d
pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f
uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2
vmem_xalloc() at netbsd:vmem_xalloc+0xacd
vmem_alloc() at netbsd:vmem_alloc+0x7f
pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c
pool_grow() at netbsd:pool_grow+0x33
pool_get() at netbsd:pool_get+0x47
pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d
pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f
uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2
vmem_xalloc() at netbsd:vmem_xalloc+0xacd
vmem_alloc() at netbsd:vmem_alloc+0x7f
pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c
pool_grow() at netbsd:pool_grow+0x33
pool_get() at netbsd:pool_get+0x47
pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d
pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f
uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2
vmem_xalloc() at netbsd:vmem_xalloc+0xacd
vmem_alloc() at netbsd:vmem_alloc+0x7f
pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c
pool_grow() at netbsd:pool_grow+0x33
pool_get() at netbsd:pool_get+0x47
pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d
pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f
uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2
vmem_xalloc() at netbsd:vmem_xalloc+0xacd
vmem_alloc() at netbsd:vmem_alloc+0x7f
pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c
pool_grow() at netbsd:pool_grow+0x33
pool_get() at netbsd:pool_get+0x47
pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d
pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f
uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2
vmem_xalloc() at netbsd:vmem_xalloc+0xacd
vmem_alloc() at netbsd:vmem_alloc+0x7f
pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c
pool_grow() at netbsd:pool_grow+0x33
pool_get() at netbsd:pool_get+0x47
pool_cache_put_slow() at netbsd:pool_cache_put_slow+0x18d
pool_cache_put_paddr() at netbsd:pool_cache_put_paddr+0x8f
uvm_km_kmem_alloc() at netbsd:uvm_km_kmem_alloc+0xf2
vmem_xalloc() at netbsd:vmem_xalloc+0xacd
vmem_alloc() at netbsd:vmem_alloc+0x7f
pool_page_alloc_meta() at netbsd:pool_page_alloc_meta+0x2c
pool_grow() at netbsd:pool_grow+0x33
pool_get() at netbsd:pool_get+0x47
pool_cache_put_slow() at