Re: usb/xhci lock issue on HEAD
On Thursday 12 July 2018 00:54:45 Martin Husemann wrote: > You commented out a bit too much and it does not find your boot device? > > /* > * If wildcarded root and we the boot device wasn't determined, > * ask the user. > */ > if (rootspec == NULL && bootdv == NULL) > boothowto |= RB_ASKNAME; > > (kern_subr.c:257) > > You normally would see something like: > > [..] > boot device: wd0 > root on wd0a dumps on wd0b > root file system type: ffs > > but if it can not identify the device, it tries to ask you for it (and > runs into an unrelated usb bug). > No, I didn't comment out anything to do with the boot and root devices. It is true I ran into an unrelated usb bug, but there must also be a bug somewhere where the bootdv ends up NULL. I got past this problem by fixing the root device in the kernel config. The problems are the same on my wifi branch and head. So this is not my bug. The kernel (from both branches) says: boot device: I copied GENERIC and then removed a bunch of drivers and changed options, but left in all the 802.11 devices. It works and I have been running it for a while. I then removed all the 802.11 devices except urtwn and it can't find the boot device. That is the only difference between the working kernel and the kernel that doesn't know about the boot device. This is on HEAD. --Phil
Re: usb/xhci lock issue on HEAD
On Wed, Jul 11, 2018 at 09:34:20PM -0700, Phil Nelson wrote: > I'm not sure why this kernel is calling cngetsn() at setroot() time. You commented out a bit too much and it does not find your boot device? /* * If wildcarded root and we the boot device wasn't determined, * ask the user. */ if (rootspec == NULL && bootdv == NULL) boothowto |= RB_ASKNAME; (kern_subr.c:257) You normally would see something like: [..] boot device: wd0 root on wd0a dumps on wd0b root file system type: ffs but if it can not identify the device, it tries to ask you for it (and runs into an unrelated usb bug). Martin
Re: usb/xhci lock issue on HEAD
On Wednesday 11 July 2018 22:32:13 Patrick Welche wrote: > "boot netbsd -a" ? No, just "boot netbsd.wifi" to boot my special wifi kernel that I'm sure will crash and don't want it doing an autoboot to. --Phil
Re: usb/xhci lock issue on HEAD
On Wed, Jul 11, 2018 at 09:34:20PM -0700, Phil Nelson wrote: > I'm not sure why this kernel is calling cngetsn() at setroot() time. "boot netbsd -a" ? P
usb/xhci lock issue on HEAD
Hello, Has anyone run into this? I created a special kernel for my 802.11 work that removes a lot of unneeded drivers from my setup, stuff like raid, ntfs and so forth. I got a working kernel out of it. Then, to work on the 802.11, I commented out every 802.11 driver except the urtwn driver. This new kernel without the the 802.11 drivers no panics as follows: panic: kernel diagnostic assertion "mutex_owned(&sc->sc_lock)" failed: file "../../../../dev/usb/xhci.c", line 2049 [6.459749] cpu0: Begin traceback... [6.459749] vpanic() at netbsd:vpanic+0x16f [6.459749] ch_voltag_convert_in() at netbsd:ch_voltag_convert_in [6.459749] xhci_softintr() at netbsd:xhci_softintr+0x5d7 [6.459749] xhci_poll() at netbsd:xhci_poll+0x37 [6.459749] ukbd_cngetc() at netbsd:ukbd_cngetc+0x113 [6.459749] wskbd_cngetc() at netbsd:wskbd_cngetc+0xc8 [6.459749] wsdisplay_getc() at netbsd:wsdisplay_getc+0x2f [6.459749] cngetc() at netbsd:cngetc+0x4d [6.459749] cngetsn() at netbsd:cngetsn+0x71 [6.459749] setroot() at netbsd:setroot+0x46f [6.459749] main() at netbsd:main+0x4a5 [6.459749] cpu0: End traceback... [6.459749] fatal breakpoint trap in supervisor mode [6.459749] trap type 1 code 0 rip 0x8021de15 cs 0x8 rflags 0x202 cr2 0 ilevel 0x8 rsp 0x81451a70 [6.459749] curlwp 0x81020920 pid 0.1 lowest kstack 0x8144d2c0 fatal protection fault in supervisor mode [6.459749] trap type 4 code 0 rip 0x8087caea cs 0x8 rflags 0x10282 cr2 0 ilevel 0x8 rsp 0x81451480 [6.459749] curlwp 0x81020920 pid 0.1 lowest kstack 0x8144d2c0 rebooting... I'm not sure why this kernel is calling cngetsn() at setroot() time. Has anyone seen this before? --Phil
