dmesg huawei E3351 as req.
umsm0 at uhub3 port 3 configuration 1 interface 0 HUAWEI HUAWEI Mobile rev 2.00/1.02 addr 4 ucom0 at umsm0 umsm1 at uhub3 port 3 configuration 1 interface 1 HUAWEI HUAWEI Mobile rev 2.00/1.02 addr 4 ucom1 at umsm1 umsm2 at uhub3 port 3 configuration 1 interface 2 HUAWEI HUAWEI Mobile rev 2.00/1.02 addr 4 ucom2 at umsm2 umsm0: this device is not using CDC notify message in intr pipe. Please send your dmesg to bugs@openbsd.org, thanks. umsm0: intr buffer 0xc1 0x1 0x3 0x0 0x0 0x0 0x0 umsm0: this device is not using CDC notify message in intr pipe. Please send your dmesg to bugs@openbsd.org, thanks. umsm0: intr buffer 0xc1 0x1 0x3 0x0 0x0 0x0 0x0 -- ole ole.hellqv...@gmail.com
Re: uvm_fault with bwi on i386 when scanning or bringing up.
On Sat, Mar 07, 2015 at 03:35:29PM -0330, Michael wrote: So here is the mentioned bootup/dmesg output with Stefans debug patch, where the snip in this output is, is just me typing in the command to shutdown as it is quite hard to work with the system with the number of messages being printed. After the snip is the bit of output before a shutdown with a different timeout message, wasn't sure if it was related but figure it'd be better to include it. Let me know if you need anything further. I can't find anything inherently bad in there. The interrupts you're getting are receive interrupts. So it seems receive is working, but transmit is broken (watchdog timeout triggers if attempts to transmit time out). I don't know why this is happenning. Does anything change if you move really close to the AP?
Re: uvm_fault with bwi on i386 when scanning or bringing up.
On 7 March 2015 at 01:18, Michael lesniewskis...@gmail.com wrote: I think this is how a null-pointer call shows up in ddb. Does the diff below help? snip 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 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? So here is the mentioned bootup/dmesg output with Stefans debug patch, where the snip in this output is, is just me typing in the command to shutdown as it is quite hard to work with the system with the number of messages being printed. After the snip is the bit of output before a shutdown with a different timeout message, wasn't sure if it was related but figure it'd be better to include it. Let me know if you need anything further. OpenBSD/i386 BOOT 3.26 boot booting hd0a:/bsd: 9785820+1068236 [72+409696+404353]=0xb20c70 entry point at 0x200120 [ using 814536 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2015 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.7 (GENERIC) #8: Sat Mar 7 13:49:51 NST 2015 r...@lucy.my.domain:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz (GenuineIntel 686-class) 2 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,CNXT-ID,PERF real mem = 804675584 (767MB) avail mem = 779149312 (743MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: date 01/07/04, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xf76a0 (62 entries) bios0: vendor Dell Computer Corporation version A13 date 01/07/2004 bios0: Dell Computer Corporation Latitude C840 acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) UAR1(S3) USB0(S1) USB1(S1) USB2(S1) MODM(S3) PCIE(S3) MPCI(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus 2 (PCIE) acpiprt3 at acpi0: bus -1 (MPCI) acpicpu0 at acpi0acpicpu0: struck PSS entry, core frequency equals last acpicpu0: struck PSS entry, core frequency equals last acpicpu0: invalid _PSS length : C2 acpipwrres0 at acpi0: PADA, resource for ADPT acpitz0 at acpi0: critical temperature is 94 degC acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 not present acpibat1 at acpi0: BAT1 not present acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PBTN acpibtn2 at acpi0: SBTN acpidock0 at acpi0: GDCK not docked (0) acpivideo0 at acpi0: VID_ bios0: ROM list: 0xc/0xf800 0xcf800/0x800! cpu0 at mainbus0: (uniprocessor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82845 Host rev 0x04 intelagp0 at pchb0 agp0 at intelagp0: aperture at 0xe800, size 0x400 ppb0 at pci0 dev 1 function 0 Intel 82845 AGP rev 0x04 pci1 at ppb0 bus 1 1:0:0: mem address conflict 0x8000/0x2 vga1 at pci1 dev 0 function 0 NVIDIA GeForce4 440 Go rev 0xa3 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) uhci0 at pci0 dev 29 function 0 Intel 82801CA/CAM USB rev 0x02: irq 11 uhci1 at pci0 dev 29 function 2 Intel 82801CA/CAM USB rev 0x02: irq 11 ppb1 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0x42 pci2 at ppb1 bus 2 xl0 at pci2 dev 0 function 0 3Com 3c905C 100Base-TX rev 0x78: irq 11, address 00:0b:db:1e:b3:e4 exphy0 at xl0 phy 24: 3Com internal media interface cbb0 at pci2 dev 1 function 0 TI PCI4451 CardBus rev 0x00: irq 11 cbb1 at pci2 dev 1 function 1 TI PCI4451 CardBus rev 0x00: irq 11 TI PCI4451 FireWire rev 0x00 at pci2 dev 1 function 2 not configured bwi0 at pci2 dev 3 function 0 Broadcom BCM4306 rev 0x02: irq 11 bwi0: bwi_power_on bwi0: regwin: type 0x800, rev 2, vendor 0x4243 bwi0: BBP id 0x4306, BBP rev 0x2, BBP pkg 0 bwi0: nregwin 6, cap 0x002a bwi0: regwin: type 0x812, rev 4, vendor 0x4243 bwi0: has TX stats bwi0: regwin: type 0x80d, rev 1, vendor 0x4243 bwi0: regwin: type 0x807, rev 1, vendor 0x4243 bwi0: regwin: type 0x804, rev 7, vendor 0x4243 bwi0: regwin: type 0x812, rev 4, vendor 0x4243 bwi0: ignore second MAC bwi0: bwi_power_on bwi0: bus rev 0 bwi0: PCI is enabled bwi0: card flags 0x000f bwi0: 0th led, act 2, lowact 0 bwi0: 1th led, act 5, lowact 0 bwi0: 2th led, act 4, lowact 0 bwi0: 3th led, act 0, lowact 0 bwi0: MAC was already disabled bwi0: PHY is linked bwi0: PHY type 2, rev 1, ver 1 bwi0: RF manu 0x17f, type 0x2050, rev 2 bwi0: bus rev 0 bwi0: PHY is linked bwi0: 30bit bus space bwi0: max txpower from sprom: 57 dBm bwi0: invalid antenna gain in sprom bwi0: ant gain 8 dBm bwi0:
Re: uvm_fault with bwi on i386 when scanning or bringing up.
I can't find anything inherently bad in there. The interrupts you're getting are receive interrupts. So it seems receive is working, but transmit is broken (watchdog timeout triggers if attempts to transmit time out). I don't know why this is happenning. Does anything change if you move really close to the AP? So I tried with my phone setup as a hotspot AP, I set it right next to the laptop and configured it so that it would use the phone. The phone does recognise that there is a device that connects to it successfully. Apologies for the length of this output, I have noted where I started typing the command with _start_ and the end of the typing with _end_, there is also another _end_ noting where I ctrl-c'd the ping, so hopefully that makes it a little easier to see. OpenBSD/i386 BOOT 3.26 boot booting hd0a:/bsd: 9785820+1068236 [72+409696+404353]=0xb20c70 entry point at 0x200120 [ using 814536 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2015 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.7 (GENERIC) #8: Sat Mar 7 13:49:51 NST 2015 r...@lucy.my.domain:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz (GenuineIntel 686-class) 2 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,CNXT-ID,PERF real mem = 804675584 (767MB) avail mem = 779149312 (743MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: date 01/07/04, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xf76a0 (62 entries) bios0: vendor Dell Computer Corporation version A13 date 01/07/2004 bios0: Dell Computer Corporation Latitude C840 acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) UAR1(S3) USB0(S1) USB1(S1) USB2(S1) MODM(S3) PCIE(S3) MPCI(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus 2 (PCIE) acpiprt3 at acpi0: bus -1 (MPCI) acpicpu0 at acpi0acpicpu0: struck PSS entry, core frequency equals last acpicpu0: struck PSS entry, core frequency equals last acpicpu0: invalid _PSS length : C2 acpipwrres0 at acpi0: PADA, resource for ADPT acpitz0 at acpi0: critical temperature is 94 degC acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 not present acpibat1 at acpi0: BAT1 not present acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PBTN acpibtn2 at acpi0: SBTN acpidock0 at acpi0: GDCK not docked (0) acpivideo0 at acpi0: VID_ bios0: ROM list: 0xc/0xf800 0xcf800/0x800! cpu0 at mainbus0: (uniprocessor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82845 Host rev 0x04 intelagp0 at pchb0 agp0 at intelagp0: aperture at 0xe800, size 0x400 ppb0 at pci0 dev 1 function 0 Intel 82845 AGP rev 0x04 pci1 at ppb0 bus 1 1:0:0: mem address conflict 0x8000/0x2 vga1 at pci1 dev 0 function 0 NVIDIA GeForce4 440 Go rev 0xa3 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) uhci0 at pci0 dev 29 function 0 Intel 82801CA/CAM USB rev 0x02: irq 11 uhci1 at pci0 dev 29 function 2 Intel 82801CA/CAM USB rev 0x02: irq 11 ppb1 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0x42 pci2 at ppb1 bus 2 xl0 at pci2 dev 0 function 0 3Com 3c905C 100Base-TX rev 0x78: irq 11, address 00:0b:db:1e:b3:e4 exphy0 at xl0 phy 24: 3Com internal media interface cbb0 at pci2 dev 1 function 0 TI PCI4451 CardBus rev 0x00: irq 11 cbb1 at pci2 dev 1 function 1 TI PCI4451 CardBus rev 0x00: irq 11 TI PCI4451 FireWire rev 0x00 at pci2 dev 1 function 2 not configured bwi0 at pci2 dev 3 function 0 Broadcom BCM4306 rev 0x02: irq 11 bwi0: bwi_power_on bwi0: regwin: type 0x800, rev 2, vendor 0x4243 bwi0: BBP id 0x4306, BBP rev 0x2, BBP pkg 0 bwi0: nregwin 6, cap 0x002a bwi0: regwin: type 0x812, rev 4, vendor 0x4243 bwi0: has TX stats bwi0: regwin: type 0x80d, rev 1, vendor 0x4243 bwi0: regwin: type 0x807, rev 1, vendor 0x4243 bwi0: regwin: type 0x804, rev 7, vendor 0x4243 bwi0: regwin: type 0x812, rev 4, vendor 0x4243 bwi0: ignore second MAC bwi0: bwi_power_on bwi0: bus rev 0 bwi0: PCI is enabled bwi0: card flags 0x000f bwi0: 0th led, act 2, lowact 0 bwi0: 1th led, act 5, lowact 0 bwi0: 2th led, act 4, lowact 0 bwi0: 3th led, act 0, lowact 0 bwi0: MAC was already disabled bwi0: PHY is linked bwi0: PHY type 2, rev 1, ver 1 bwi0: RF manu 0x17f, type 0x2050, rev 2 bwi0: bus rev 0 bwi0: PHY is linked bwi0: 30bit bus space bwi0: max txpower from sprom: 57 dBm bwi0: invalid antenna gain in sprom bwi0: ant gain 8 dBm bwi0: region/domain max txpower 76 dBm bwi0: max txpower 57 dBm bwi0: sprom idle tssi: 0x003e bwi0: TSSI-TX power map: 71 71 70 70 70 70 70 69 69 69
Re: urtwn timeout and system freez
On Fri, Mar 06, 2015 at 11:24:27PM +0100, Martin Pieuchot wrote: 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? I built a kernel with this diff and the diff from Stefan applied on a cvs checkout from yesterday. I could provoke an urtwn0 timeout with running speedtest-cli. * TX status and page fault trap: https://relo.ch/urtwn_freeze/IMG_20150307_134913.jpg * trace cpu 2,0,1,3: https://relo.ch/urtwn_freeze/IMG_20150307_135150.jpg I tested the same with urtwn plugged to the xhci port. The timeout also happens but I can unplug the device without the system dropping to ddb.
Re: uvm_fault with bwi on i386 when scanning or bringing up.
On Sat, Mar 07, 2015 at 04:29:40PM -0330, Michael wrote: I can't find anything inherently bad in there. The interrupts you're getting are receive interrupts. So it seems receive is working, but transmit is broken (watchdog timeout triggers if attempts to transmit time out). I don't know why this is happenning. Does anything change if you move really close to the AP? So I tried with my phone setup as a hotspot AP, I set it right next to the laptop and configured it so that it would use the phone. The phone does recognise that there is a device that connects to it successfully. Apologies for the length of this output, I have noted where I started typing the command with _start_ and the end of the typing with _end_, there is also another _end_ noting where I ctrl-c'd the ping, so hopefully that makes it a little easier to see. So this shows that associating and DHCP works. And then no ping. I suspect this is simply the calibration problem mentioned in the bwi(4) man page: CAVEATS Some chips are incorrectly calibrated due to the lack of documentation, which can slow the amount of traffic to the point of being unusable. Which is a long-standing bug. I could never reproduce the situation where it doesn't work at all. But the bwi device in my macppc is far from stable. Ping times vary considerably and there occasional are stalls. Sometimes it just works though. On my list of many things to fix in wifi, this one is pretty low, unfortunately.
