Re: Plugging in ADB-enabled Android device makes kernel panic with xhci
On Thu, Aug 23, 2018 at 08:45:54PM +0900, Bryan Linton wrote: > So I found some time to try to bisect this, but was hampered by my > phone being somewhat temperamental. > > Everything up to July 3rd was fine. No crashes occurred. > > On a July 15th checkout, my system panicked when trying to run adb > with my phone connected. > > Unfortunately when I tried to bisect this further, my phone began > refusing to connect to my computer. I get a generic > "uhub0: device problem, disabling port 2" > error and cannot get my phone to attach to my computer even if I > reboot it, plug/unplug it, etc. > > I'll see if I can try to bisect this further once I figure out > what the problem is with my phone, but in the meantime, I wanted > to at least update the bugs@ list with my findings so far. > > I see a few potential commits in that time-frame that could be > responsible, so I'm going to see if I can manage to narrow this > down even further. > > -- > Bryan Hi Bryan, I've narrowed it down. Last kernel where adb works: June 24 09:59:46 MDT 2018 1st Kernel where adb panics: June 25 13:10:32 MDT 2018 I did notice when my phone's booted into LineageOS and I have ADB turned on, when I connect the phone via USB I get: ugen1 at uhub0 port 7 "motorola XT1039" rev 2.00/2.28 addr 8 However, I'm not able to actually connect to it with adb shell or anything else. It says: Error device offline or something. When I boot the phone into recovery mode, the phone shows up like this when I plug it in: ugen1 at uhub0 port 7 "Motorola Moto G LTE" rev 2.00/2.28 addr 4 (different name!) and I am able use adb shell, adb push/pull, etc.. I think there's some issue with LineageOS' ADB mode, but that's not really relevant here (it's a separate issue and outside of OpenBSD perhaps though I'll have to test with Linux or some other OS.) I'm going to look at the commits next. -Tom
Re: Plugging in ADB-enabled Android device makes kernel panic with xhci
On Thu, Aug 23, 2018 at 08:45:54PM +0900, Tom Murphy wrote: > I've narrowed it down. > >Last kernel where adb works: June 24 09:59:46 MDT 2018 >1st Kernel where adb panics: June 25 13:10:32 MDT 2018 > > I did notice when my phone's booted into LineageOS and I have ADB >turned on, when I connect the phone via USB I get: > >ugen1 at uhub0 port 7 "motorola XT1039" rev 2.00/2.28 addr 8 > > However, I'm not able to actually connect to it with adb shell or >anything else. It says: Error device offline or something. > > When I boot the phone into recovery mode, the phone shows up like >this when I plug it in: > > ugen1 at uhub0 port 7 "Motorola Moto G LTE" rev 2.00/2.28 addr 4 > > (different name!) and I am able use adb shell, adb push/pull, etc.. > > I think there's some issue with LineageOS' ADB mode, but that's not >really relevant here (it's a separate issue and outside of OpenBSD >perhaps though I'll have to test with Linux or some other OS.) > > I'm going to look at the commits next. > >-Tom I can verify that this commit is what makes the kernel panic when adb is run and an Android device is connected to the machine with ADB enabled: https://marc.info/?l=openbsd-cvs&m=152996258723362&w=2 CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2018/06/25 10:06:27 Modified files: sys/kern : vfs_syscalls.c lib/libc/sys : dup.2 Log message: During open(2), release the fdp lock before calling vn_open(9). This lets other threads of the process modify the file descriptor table even if the vn_open(9) call blocks. The change has an effect on dup2(2) and dup3(2). If the new descriptor is the same as the one reserved by an unfinished open(2), the system call will fail with error EBUSY. The accept(2) system call already behaves like this. Issue pointed out by art@ via mpi@ Tested in a bulk build by ajacoutot@ OK mpi@ * * * I tested kernels compiled just before that commit and right after, and that commit makes the kernel panic. -Tom
Re: axen Ethernet device errors on both USB3.0 and USB2.0 ports
On Fri, Aug 24, 2018 at 06:02:20AM +, sc.dy...@gmail.com wrote: > On 2018/08/19 09:40, Stefan Sperling wrote: > > On Sun, Aug 19, 2018 at 11:05:04AM +0200, Stefan Sperling wrote: > >> On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote: > >>> It would help if you could send a clean version that applies to -current. > >> > >> One of the attachments was in fact clean but yes, this > >> thread has been much too noisy to follow easily. > >> > >> Try this. > > > > Unfortunately, while this diff does indeed work on xhci(4), I've just > > found that this diff breaks axen(4) attached to ehci(4) completely. > > > > I see several "axen0: rxeof: too short transfer" in dmesg and > > almost all packets are lost. Even my Ethernet switch gives up > > eventually and disables the port. > > > > So this diff is not ready to be committed. > > I didn't check if axen works on ehci. > On my ehci (intel PCH) that bug is reproduced, and > I found that it works on ehci with 16kB RX buffer. > I preserve the original bufsz decision code. I applied axen5.diff and xhci.diff and tested the resulting kernel on an old Samsung notebook that has ehci and xhci (demesg and usbdevs below). When the axen dongle is attached via xhci it gets link but dhclient never gets a lease. This works when attached via ehci. But after some light traffic (browsing with netsurf) the systme panics. Here the output from ddb (copied by hand): kernel: page fault trap, code=0 Stopped at memcpy+0x15:repe movsq (%rsi),%es:(rdi) ddb{1}> show panic kernel page fault uvm_fault(0xffdef19438, 0x0, 0, 1) -> e memcpy(79e3..) at memcpy+0x15 end trace frame: 0x800032e06cd0, cound: 0 ddb{1} trace memcpy(79e...) at memcpy+0x15 ptcread(5b11cd.) at ptcread+0x1eb spec_read(70e.) at spec_read+0xab VOP_READ(4b037..) at VOP_RAED+0x49 vn_read(af8b.) at dofilereadv+0xe0 sys_read(9862) at sys_read+0x5c syscall(822b.) at syscall+0x32a Xsyscall(0,3,0,3,f,1954e...) at Xsyscall+0x128 end of kernel end trace frame 0x7f7d3430, count: -9 ddb{1}> mach ddb 0 Stopped at x86_ipi_db+0x12: popq%r11 ddb{0}> trace x86_ipi_db(5d...) at x86_ipi_db+0x12 x86_ipi_handler() at x86_ipi_handler+0x80 Xresume_lapic_ipi(9,ff.) at Xresume_lapic_ipi+0x23 ___mp_lock(58ifaff) at ___mp_lock+0x68 intr_handler(a26f9) at intr_handler+0x40 Xintr_ioapic_edge12_untramp(6,fff...) at Xintr_ioapic_edge12_untramp+0x19f ___mp_lock(58faff...) at___mp_lock+0x68 intr_handler(a26f9) at intr_handler+040 Xintr_ioapic_edge25_untramp(0,3,..) at Xintr_ioapic_edge25_untramp+0x19f acpicpu_idle() at acpicpu_idle+0x166 sched_idle(0) at sced_idle+0x245 end trace frame: 0x0, count: -11 ddb{0} This does not happen when running a snapshot kernel. dmesg + usbdevs -vvv OpenBSD 6.4-beta (GENERIC.MP) #0: Sat Aug 25 19:45:29 CEST 2018 r...@530u.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8462659584 (8070MB) avail mem = 8196993024 (7817MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0840 (63 entries) bios0: vendor Phoenix Technologies Ltd. version "05XK" date 02/10/2012 bios0: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG SSDT SSDT UEFI UEFI UEFI acpi0: wakeup devices P0P1(S4) GLAN(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz, 1597.58 MHz, 06-2a-07 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz, 1895.69 MHz, 06-2a-07 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 14 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpip
[unveil] kernel panic for mfs/read-only filesystems during reboot
I'm got kernel panic on OpenBSD 6.4-beta (GENERIC.MP) #260: Sat Aug 25 02:10:42 MDT 2018 when experimenting with mfs and read-only filesystems. # shutdown -r now shutdown: unveil: Read-only file system # mount /dev/sd0a on / type ffs (local, read-only) mfs:35132 on /dev type mfs (asynchronous, local, noexec, nosuid, size=102400 512-blocks) mfs:74539 on /etc type mfs (asynchronous, local, nodev, nosuid, size=102400 512-blocks) mfs:26844 on /tmp type mfs (asynchronous, local, nodev, noexec, nosuid, size=204800 512-blocks) mfs:54540 on /var type mfs (asynchronous, local, nodev, noexec, nosuid, size=102400 512-blocks) mfs:55695 on /var/log type mfs (asynchronous, local, nodev, noexec, nosuid, size=262144 512-blocks) /dev/sd0d on /usr type ffs (local, nodev, read-only) /dev/sd0e on /usr/local type ffs (local, nodev, nosuid, read-only) /dev/sd0f on /data type ffs (local, nodev, nosuid, read-only) # reboot panic: kernel diagnostic assertion "vp->v_uvcount == 0" failed: file "/usr/src/sys/kern/kern_unveil.c", line 748 Stopped at db_enter+0x12: popq%r11 TIDPIDUID PRFLAGS PFLAGS CPU COMMAND *469083 35132 0 0 01K mount_mfs 240741 31688 0 0x14000 0x2000 reaper db_enter() at db_enter+0x12 panic() at panic+0x120 __assert(816afd14,800021147ec0,0,ff006fc21338) at __assert+0x24 unveil_removevnode(b3fdf0663036209b) at unveil_removevnode+0xf2 dounmount_leaf(36a320cd3cded2ab,80096c00,0) at dounmount_leaf+0x69 dounmount(bf305e5e97ceba2d,80096c00,80008008) at dounmount+0xfa mfs_start(3167c81713baac45,80096c00,ff007f63e000) at mfs_start+0xf9 sys_mount(a36477f38b506169,150,80008008) at sys_mount+0x5b5 syscall(bc035fa0eb20afa4) at syscall+0x32a Xsyscall(6,15,7f7da610,15,7f7daaac,7f7daf8d) at Xsyscall+0x128 end of kernel end trace frame: 0x7f7dae00, count: 5 https://www.openbsd.org/ddb.html describes the minimum info required in bug reports. Insufficient info makes it difficult to find and fix bugs. ddb{1}> show panic kernel diagnostic assertion "vp->v_uvcount == 0" failed: file "/usr/src/sys/ker n/kern_unveil.c", line 748 ddb{1}> show uvm Current UVM status: pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12 504236 VM pages: 10856 active, 2913 inactive, 0 wired, 460030 free (57336 zer o) min 10% (25) anon, 10% (25) vnode, 5% (12) vtext freemin=16807, free-target=22409, inactive-target=0, wired-max=168078 faults=131805, traps=130457, intrs=12942, ctxswitch=38035 fpuswitch=0 softint=15328, syscalls=340659, kmapent=16 fault counts: noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0 ok relocks(total)=7550(7550), anget(retries)=49584(0), amapcopy=56876 neighbor anon/obj pg=3853/52486, gets(lock/unlock)=24354/7550 cases: anon=40560, anoncow=9024, obj=20857, prcopy=3497, przero=57861 daemon and swap counts: woke=0, revs=0, scans=0, obscans=0, anscans=0 busy=0, freed=0, reactivate=0, deactivate=0 pageouts=0, pending=0, nswget=0 nswapdev=1 swpages=526127, swpginuse=0, swpgonly=0 paging=0 kernel pointers: objs(kern)=0x81ca11a0 ddb{1}> show bcstats Current Buffer Cache status: numbufs 5869 busymapped 0, delwri 12 kvaslots 6302 avail kva slots 6302 bufpages 22694, dmapages 22694, dirtypages 21 pendingreads 0, pendingwrites 0 highflips 0, highflops 0, dmaflips 0 ddb{1}> trace db_enter() at db_enter+0x12 panic() at panic+0x120 __assert(816afd14,800021147ec0,0,ff006fc21338) at __assert+0x24 unveil_removevnode(b3fdf0663036209b) at unveil_removevnode+0xf2 dounmount_leaf(36a320cd3cded2ab,80096c00,0) at dounmount_leaf+0x69 dounmount(bf305e5e97ceba2d,80096c00,80008008) at dounmount+0xfa mfs_start(3167c81713baac45,80096c00,ff007f63e000) at mfs_start+0xf9 sys_mount(a36477f38b506169,150,80008008) at sys_mount+0x5b5 syscall(bc035fa0eb20afa4) at syscall+0x32a Xsyscall(6,15,7f7da610,15,7f7daaac,7f7daf8d) at Xsyscall+0x128 end of kernel end trace frame: 0x7f7dae00, count: -10 - steps to reproduce: * create fs setup as in mount output below * shutdown -r * reboot # mount /dev/sd0a on / type ffs (local, read-only) mfs:35132 on /dev type mfs (asynchronous, local, noexec, nosuid, size=102400 512-blocks) mfs:74539 on /etc type mfs (asynchronous, local, nodev, nosuid, size=102400 512-blocks) mfs:26844 on /tmp type mfs (asynchronous, local, nodev, noexec, nosuid, size=204800 512-blocks) mfs:54540 on /var type mfs (asynchronous, local, nodev, noexec, nosuid, size=102400 512-blocks) mfs:55695 on /var/log type mfs (asynchronous, local, nodev, noexec, nosuid, size=262144 512-blocks) /dev/sd0d on /usr type ffs (local, nodev, read-only) /dev/sd0e on /usr/local type ffs (local, nodev, nosuid, read-only) /dev/sd0f on /data type ffs