Re: urtwn timeout and system freez

2015-03-06 Thread Evgeny Zhavoronkov
I confirm. I have the same issue.

On Fri, Mar 6, 2015 at 10:45 AM, Remi Locherer 
wrote:

> Hi,
>
> Since about fall 2014 I see "urtwn0 timeout" every now an then like
> others that reported it. An unplug and replut of the urtwn device
> usually helped.
>
> But with the snapshots from March 1st and 3rd the system just freezes
> when I unplug the urtwn device after I see the timeout message in
> xconsole. The system just freezes and does not drop to ddb.
>
> With the snapshot from February 20 I did not observe these freezes.
>
> Outputs of lsusb -v and dmesg below.
>
> Remi
>
>
> Bus 000 Device 001: ID 1912:
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   3.00
>   bDeviceClass9 Hub
>   bDeviceSubClass 0 Unused
>   bDeviceProtocol 1 Single TT
>   bMaxPacketSize0 9
>   idVendor   0x1912
>   idProduct  0x
>   bcdDevice1.00
>   iManufacturer   1 Renesas
>   iProduct2 xHCI root hub
>   iSerial 0
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   25
> bNumInterfaces  1
> bConfigurationValue 1
> iConfiguration  0
> bmAttributes 0x40
>   (Missing must-be-set bit!)
>   Self Powered
> MaxPower0mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   1
>   bInterfaceClass 9 Hub
>   bInterfaceSubClass  0 Unused
>   bInterfaceProtocol  0 Full speed (or root) hub
>   iInterface  0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes3
>   Transfer TypeInterrupt
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0002  1x 2 bytes
> bInterval 255
> Hub Descriptor:
>   bLength  13
>   bDescriptorType  42
>   nNbrPorts 4
>   wHubCharacteristic 0x
> Ganged power switching
> Ganged overcurrent protection
> TT think time 8 FS bits
>   bPwrOn2PwrGood   10 * 2 milli seconds
>   bHubContrCurrent  0 milli Ampere
>   DeviceRemovable0x00
>   PortPwrCtrlMask0x00
>  Hub Port Status:
>Port 1: .0900 Unknown Speed Recovery
>Port 2: .0900 Unknown Speed Recovery
>Port 3: .0900 Unknown Speed Recovery
>Port 4: .0900 Unknown Speed Recovery
> Device Status: 0x0001
>   Self Powered
>
> Bus 001 Device 001: ID 8086: Intel Corp.
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass9 Hub
>   bDeviceSubClass 0 Unused
>   bDeviceProtocol 1 Single TT
>   bMaxPacketSize064
>   idVendor   0x8086 Intel Corp.
>   idProduct  0x
>   bcdDevice1.00
>   iManufacturer   1 Intel
>   iProduct2 EHCI root hub
>   iSerial 0
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   25
> bNumInterfaces  1
> bConfigurationValue 1
> iConfiguration  0
> bmAttributes 0x40
>   (Missing must-be-set bit!)
>   Self Powered
> MaxPower0mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   1
>   bInterfaceClass 9 Hub
>   bInterfaceSubClass  0 Unused
>   bInterfaceProtocol  0 Full speed (or root) hub
>   iInterface  0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes3
>   Transfer TypeInterrupt
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0008  1x 8 bytes
> bInterval  12
> Hub Descriptor:
>   bLength  10
>   bDescriptorType  41
>   nNbrPorts 3
>   wHubCharacteristic 0x0002
> No power switching (usb 1.0)
> Ganged overcurrent protection
> TT think time 8 FS bits
>   bPwrOn2PwrGood  200 * 2 milli seconds
>   bHubContrCurrent  0 milli Ampere
>   DeviceRemovable0x00
>   PortPwrCtrlMask0x00
>  Hub Port Status:
>Port 1: .0503 highspeed power enable connect
>Port 2: .0500 highspeed power
>Port 3: .0500

Re: urtwn timeout and system freez

2015-03-06 Thread Stefan Sperling
On Fri, Mar 06, 2015 at 08:45:20AM +0100, Remi Locherer wrote:
> Hi,
> 
> Since about fall 2014 I see "urtwn0 timeout" every now an then like 
> others that reported it. An unplug and replut of the urtwn device
> usually helped.
> 
> But with the snapshots from March 1st and 3rd the system just freezes
> when I unplug the urtwn device after I see the timeout message in
> xconsole. The system just freezes and does not drop to ddb.
> 
> With the snapshot from February 20 I did not observe these freezes.
> 
> Outputs of lsusb -v and dmesg below.
> 
> Remi
> 

Hi Remi,

I've discussed this with mpi. We're unsure what's going on exactly. 

Can you please really make sure you're not dropping into ddb (i.e.
don't detach the device while in X, but when on console)?
 
Can you please apply this diff and let us know if you see any STATUS=?
lines with it when the problem happens (again, console, not X)?

Thanks.

Index: if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.42
diff -u -p -r1.42 if_urtwn.c
--- if_urtwn.c  10 Feb 2015 23:25:46 -  1.42
+++ if_urtwn.c  6 Mar 2015 08:12:23 -
@@ -1635,7 +1635,7 @@ urtwn_rxeof(struct usbd_xfer *xfer, void
int len, totlen, pktlen, infosz, npkts;
 
if (__predict_false(status != USBD_NORMAL_COMPLETION)) {
-   DPRINTF(("RX status=%d\n", status));
+   printf("RX status=%d\n", status);
if (status == USBD_STALLED)
usbd_clear_endpoint_stall_async(sc->rx_pipe);
if (status != USBD_CANCELLED)
@@ -1703,7 +1703,7 @@ urtwn_txeof(struct usbd_xfer *xfer, void
TAILQ_INSERT_TAIL(&sc->tx_free_list, data, next);
 
if (__predict_false(status != USBD_NORMAL_COMPLETION)) {
-   DPRINTF(("TX status=%d\n", status));
+   printf("TX status=%d\n", status);
if (status == USBD_STALLED)
usbd_clear_endpoint_stall_async(data->pipe);
ifp->if_oerrors++;



panic: attempt to execute user address in supervisor mode

2015-03-06 Thread ben
>Synopsis:  kernel panic when something attempts to execute user address in 
>supervisor mode
>Category:  system
>Environment:
System  : OpenBSD 5.6
Details : OpenBSD 5.6-stable (GENERIC) #2: Wed Jan 14 10:21:38 PST 
2015
 
r...@new.tilderoot.com:/usr/src/sys/arch/amd64/compile/GENERIC

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
Honestly, I haven't noticed anything that can trigger this.  It's 
happened during the night when the system is basically idle.
>How-To-Repeat:
Unknown.
>Fix:
Unknown.


dmesg:
OpenBSD 5.6-stable (GENERIC) #2: Wed Jan 14 10:21:38 PST 2015
r...@new.tilderoot.com:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1056899072 (1007MB)
avail mem = 1020080128 (972MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfbd3f (10 entries)
bios0: vendor QEMU version "QEMU" date 01/01/2007
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: QEMU Virtual CPU version 0.9.1, 2667.11 MHz
cpu0: 
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,LONG,PERF
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 40960MB, 83886080 sectors
atapiscsi0 at pciide0 channel 0 drive 1
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom removable
wd0(pciide0:0:0): using PIO mode 0, DMA mode 2
cd0(pciide0:0:1): using PIO mode 0
atapiscsi1 at pciide0 channel 1 drive 0
scsibus2 at atapiscsi1: 2 targets
cd1 at scsibus2 targ 0 lun 0:  ATAPI 5/cdrom removable
cd1(pciide0:1:0): using PIO mode 0
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 1 int 11
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 1 int 10
iic0 at piixpm0
iic0: addr 0x18 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 
00= 01= 02= 03= 04= 05= 06= 07=
iic0: addr 0x1a 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 
00= 01= 02= 03= 04= 05= 06= 07=
iic0: addr 0x29 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 
00= 01= 02= 03= 04= 05= 06= 07=
iic0: addr 0x2b 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 
00= 01= 02= 03= 04= 05= 06= 07=
iic0: addr 0x4c 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 
00= 01= 02= 03= 04= 05= 06= 07=
iic0: addr 0x4e 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 
00= 01= 02= 03= 04= 05= 06= 07=
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
em0 at pci0 dev 3 function 0 "Intel 82540EM" rev 0x03: apic 1 int 11, address 
52:54:00:27:31:70
virtio0 at pci0 dev 4 function 0 "Qumranet Virtio Memory" rev 0x00: Virtio 
Memory Balloon Device
viomb0 at virtio0
virtio0: apic 1 int 11
virtio1 at pci0 dev 5 function 0 "Qumranet Virtio Console" rev 0x00: Virtio 
Console Device
virtio1: no matching child driver; not configured
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: density unknown
fd1 at fdc0 drive 1: density unknown
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
nvram: invalid checksum
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on wd0a (4b065d5d21359f13.a) swap on wd0b dump on wd0b
WARNING: / was not properly unmounted
clock: un

Re: urtwn timeout and system freez

2015-03-06 Thread Remi Locherer
On Fri, Mar 06, 2015 at 09:15:23AM +0100, Stefan Sperling wrote:
> On Fri, Mar 06, 2015 at 08:45:20AM +0100, Remi Locherer wrote:
> > Hi,
> > 
> > Since about fall 2014 I see "urtwn0 timeout" every now an then like 
> > others that reported it. An unplug and replut of the urtwn device
> > usually helped.
> > 
> > But with the snapshots from March 1st and 3rd the system just freezes
> > when I unplug the urtwn device after I see the timeout message in
> > xconsole. The system just freezes and does not drop to ddb.
> > 
> > With the snapshot from February 20 I did not observe these freezes.
> > 
> > Outputs of lsusb -v and dmesg below.
> > 
> > Remi
> > 
> 
> Hi Remi,
> 
> I've discussed this with mpi. We're unsure what's going on exactly. 
> 
> Can you please really make sure you're not dropping into ddb (i.e.
> don't detach the device while in X, but when on console)?

Your assumption is right! Switching from X to console _before_ unplugging
the urtwn device gives me an ddb promt. I made photos from trace and ps:

* page fault trap: https://relo.ch/urtwn_freeze/IMG_20150306_184105.jpg
* trace cpu 0 - 3: https://relo.ch/urtwn_freeze/IMG_20150306_192412.jpg
* ps part 1: https://relo.ch/urtwn_freeze/IMG_20150306_192537.jpg
* ps part 2: https://relo.ch/urtwn_freeze/IMG_20150306_192708.jpg

I'll apply the below diff and report back with the results.

> Can you please apply this diff and let us know if you see any STATUS=?
> lines with it when the problem happens (again, console, not X)?
> 
> Thanks.
> 
> Index: if_urtwn.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
> retrieving revision 1.42
> diff -u -p -r1.42 if_urtwn.c
> --- if_urtwn.c10 Feb 2015 23:25:46 -  1.42
> +++ if_urtwn.c6 Mar 2015 08:12:23 -
> @@ -1635,7 +1635,7 @@ urtwn_rxeof(struct usbd_xfer *xfer, void
>   int len, totlen, pktlen, infosz, npkts;
>  
>   if (__predict_false(status != USBD_NORMAL_COMPLETION)) {
> - DPRINTF(("RX status=%d\n", status));
> + printf("RX status=%d\n", status);
>   if (status == USBD_STALLED)
>   usbd_clear_endpoint_stall_async(sc->rx_pipe);
>   if (status != USBD_CANCELLED)
> @@ -1703,7 +1703,7 @@ urtwn_txeof(struct usbd_xfer *xfer, void
>   TAILQ_INSERT_TAIL(&sc->tx_free_list, data, next);
>  
>   if (__predict_false(status != USBD_NORMAL_COMPLETION)) {
> - DPRINTF(("TX status=%d\n", status));
> + printf("TX status=%d\n", status);
>   if (status == USBD_STALLED)
>   usbd_clear_endpoint_stall_async(data->pipe);
>   ifp->if_oerrors++;
> 



Re: urtwn timeout and system freez

2015-03-06 Thread Martin Pieuchot
On 06/03/15(Fri) 22:06, Remi Locherer wrote:
> On Fri, Mar 06, 2015 at 09:15:23AM +0100, Stefan Sperling wrote:
> > On Fri, Mar 06, 2015 at 08:45:20AM +0100, Remi Locherer wrote:
> > > Hi,
> > > 
> > > Since about fall 2014 I see "urtwn0 timeout" every now an then like 
> > > others that reported it. An unplug and replut of the urtwn device
> > > usually helped.
> > > 
> > > But with the snapshots from March 1st and 3rd the system just freezes
> > > when I unplug the urtwn device after I see the timeout message in
> > > xconsole. The system just freezes and does not drop to ddb.
> > > 
> > > With the snapshot from February 20 I did not observe these freezes.
> > > 
> > > Outputs of lsusb -v and dmesg below.
> > > 
> > > Remi
> > > 
> > 
> > Hi Remi,
> > 
> > I've discussed this with mpi. We're unsure what's going on exactly. 
> > 
> > Can you please really make sure you're not dropping into ddb (i.e.
> > don't detach the device while in X, but when on console)?
> 
> Your assumption is right! Switching from X to console _before_ unplugging
> the urtwn device gives me an ddb promt. I made photos from trace and ps:
> 
> * page fault trap: https://relo.ch/urtwn_freeze/IMG_20150306_184105.jpg
> * trace cpu 0 - 3: https://relo.ch/urtwn_freeze/IMG_20150306_192412.jpg
> * ps part 1: https://relo.ch/urtwn_freeze/IMG_20150306_192537.jpg
> * ps part 2: https://relo.ch/urtwn_freeze/IMG_20150306_192708.jpg

It looks like we're trying to remove a transfer from the list of pending
xfers when it has not yet been added to it.

Could you tell me if the diff below fixes your issue?

Index: ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.175
diff -u -p -r1.175 ehci.c
--- ehci.c  28 Feb 2015 09:22:59 -  1.175
+++ ehci.c  6 Mar 2015 22:21:28 -
@@ -2716,7 +2716,7 @@ ehci_abort_xfer(struct usbd_xfer *xfer, 
 
DPRINTF(("ehci_abort_xfer: xfer=%p pipe=%p\n", xfer, epipe));
 
-   if (sc->sc_bus.dying) {
+   if (sc->sc_bus.dying || xfer->status == USBD_NOT_STARTED) {
/* If we're dying, just do the software part. */
s = splusb();
xfer->status = status;  /* make software ignore it */
@@ -2728,6 +2728,12 @@ ehci_abort_xfer(struct usbd_xfer *xfer, 
 #endif
usb_transfer_complete(xfer);
splx(s);
+   return;
+   }
+
+   /* Transfer is already done. */
+   if (xfer->status != USBD_IN_PROGRESS) {
+   DPRINTF(("%s: already done \n", __func__));
return;
}
 



Re: uvm_fault with bwi on i386 when scanning or bringing up.

2015-03-06 Thread Michael
> I think this is how a null-pointer call shows up in ddb.
>
> Does the diff below help?
>


Perfect! That stopped the uvm_fault occuring, scanning now works well;
however when actually connecting to an AP I get a number of
bwi0: watchdog timeout
and although it successfully can acquire a DHCP address on bootup, no
traffic can be passed. (pings and traceroutes just hang without
output).
I will re-add in the debug code that Stefan provided before and post
another dmesg tomrrow unless different debug code would be needed for
a watchdog timeout error?



ksh: parsing problem: quote in comment in command substitution

2015-03-06 Thread Sébastien Marie
Hi,

I encounter a problem of parsing in ksh(1): a quote in a comment in a
command substitution $(...) or `...` is parsed as quote and a closing quote
is expected.

Here code snippet that expose the problem:

$ cat test.sh
echo $(echo abc |
# comment
cat)

echo $(echo abc |
# comment with quote '
cat)

$ ksh ./test.sh
abc
./test.sh[9]: no closing quote


As side note, bash(1) don't have this parsing problem.

$ bash ./test.sh
abc
abc
$ 

Thanks.
-- 
Sébastien Marie