daily CVS update output
Updating src tree: P src/common/lib/libc/arch/arm/atomic/atomic_cas_64.S P src/common/lib/libc/atomic/atomic_init_testset.c P src/external/mpl/bind/lib/libisc/Makefile P src/games/backgammon/common_source/check.c P src/lib/libc/gen/devname.c P src/sys/arch/evbppc/obs405/obs600_autoconf.c P src/sys/arch/mac68k/mac68k/intr.c P src/sys/arch/x86/x86/pmap.c P src/sys/arch/x86/x86/procfs_machdep.c P src/sys/dev/mii/dmphy.c P src/sys/dev/mii/glxtphy.c P src/sys/dev/nvmm/nvmm.c P src/sys/dev/nvmm/x86/nvmm_x86_svm.c P src/sys/dev/nvmm/x86/nvmm_x86_vmx.c P src/sys/external/bsd/drm2/dist/drm/i915/intel_ddi.c P src/sys/external/bsd/drm2/dist/drm/i915/intel_display.c P src/sys/external/bsd/drm2/dist/drm/i915/intel_sdvo.c P src/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_bo.c P src/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_usif.c P src/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/subdev/clk/nouveau_nvkm_subdev_clk_gt215.c P src/sys/net/zlib.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 40153859 Feb 19 03:03 ls-lRA.gz
panic with mount_union in installer
Hi, I got a panic during a kind of exotic install try of -current (8.99.34) on amd64. Due to large number of GPT partitions I quickly got a total of 19 wedges (up to dk18) with only 16 of them available in /dev (install/53992). Manual mknod in /dev/ wasn't possible due to r/o filesystem (cd-image), so I made a directory in tmpfs-mounted /tmp, some device nodes inside and then I mounted that dir with mount_union over /dev: mkdir /tmp/dev cd /tmp/dev mknod dk16 b 168 16 mknod rdk16 c 168 16 ... mount_union /tmp/dev /dev 1. newfs -O 2 name=... was successful 2. mount name=... /targetroot/... was successful 3. and during untar process I got following panic: http://smutek.pl/netbsd/netbsd-8-99-34-adm64-union-crash.jpg http://smutek.pl/netbsd/netbsd-8-99-34-adm64-union-crash-bt.jpg Regards, -- Piotr 'aniou' Meyer
lockdebug kernel instacrash when npf enabled
Hi, I updated an evbarm host from current as of 2018-12-09 to today's sources. Had some issues with hangs in npf so enabled lockdebug and it crashed immediately with this message: Enabling NPF. [ 22.6038371] panic: kernel debugging assertion "pserialize_not_in_read_section()" failed: file "/work/src/sys/kern/kern_mutex.c", line 527 [ 22.7529500] cpu0: Begin traceback... [ 22.7976654] 0x99deba54: netbsd:db_panic+0x14 [ 22.8465447] 0x99deba6c: netbsd:vpanic+0x194 [ 22.8985454] 0x99deba84: netbsd:__aeabi_uldivmod [ 22.9505468] 0x99debb04: netbsd:mutex_enter+0x5f4 [ 22.9994280] 0x99debb4c: netbsd:npf_table_lookup+0x134 [ 23.0597517] 0x99debb74: netbsd:npf_cop_table+0x70 [ 23.1169500] 0x99debba4: netbsd:bpf_filter_ext+0x73c [ 23.1741482] 0x99debc24: netbsd:npf_ruleset_inspect+0x164 [ 23.2375871] 0x99debccc: netbsd:npf_packet_handler+0x1cc [ 23.2999868] 0x99debd24: netbsd:pfil_run_hooks+0x128 [ 23.3582278] 0x99debe1c: netbsd:ip_output+0x7ac [ 23.4175060] 0x99debe7c: netbsd:ip_forward+0x1a4 [ 23.4653506] 0x99debf4c: netbsd:ipintr+0x115c [ 23.5225442] 0x99debfac: netbsd:softint_dispatch+0x114 [ 23.5766292] 0x9a729cc4: netbsd:softint_switch+0x58 [ 23.6348677] 0x9a729d44: netbsd:irq_entry+0x88 [ 23.6920657] 0x9a729db4: netbsd:mutex_enter+0x5bc [ 23.7409489] 0x9a729e24: netbsd:pmap_remove+0x15c [ 23.7960705] 0x9a729e7c: netbsd:uvm_unmap_remove+0x258 [ 23.8563886] 0x9a729eac: netbsd:uvmspace_free+0xec [ 23.9135859] 0x9a729f14: netbsd:exit1+0x1a0 [ 23.9697447] 0x9a729f34: netbsd:sys_exit+0x3c [ 24.0186247] 0x9a729fac: netbsd:syscall+0x18c
Re: problems with USB/CDC serial (umodem) - devices work with Linux, Mac OS X, and FreeBSD, but not NetBSD
mar...@duskware.de (Martin Husemann) writes: >On Mon, Feb 18, 2019 at 09:11:51AM -0800, Rob Newberry wrote: >> I'm pretty sure there are differences in how NetBSD's USB modem class >> driver interacts with the device from how other platforms do. For the >> time being, I'm trying to read the code of the NetBSD and the FreeBSD >> drivers, along with the USB CDC spec, to see what's going on. >Hmm, I thought I would be using umodem, but actually it is u3g. >However, I am pretty sure that at that level the driver does not >do anything special but just pass on the data in both ways. I'm using umodem for a 3G interface, nothing special there. You also see from the traces that the same data is sent and the first byte received is also the same. This could be as simple as a timeout on NetBSD, I first thought something was using very small timeouts that cannot be handled with our low HZ value, but the code seems to use only timeouts of at least several seconds. The code also uses a rare combination of select() and poll() to wait for input. I tend to believe the problem is not related to USB or umodem at all. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: problems with USB/CDC serial (umodem) - devices work with Linux, Mac OS X, and FreeBSD, but not NetBSD
>> Note that your FreeBSD installation writes something completely different >> to the device. > > It has been pointed out off list that the FreeBSD ascii version is just > differently encoded (with "." for unprintable character), and the > packet written is actually identical. > > So I have no idea why the device answers differently (and no idea how to > debug this unless the device itself offers some debug options). Thanks so much for the time so far. I appreciate it (using ktrace was a good skill to pick up). I'm pretty sure there are differences in how NetBSD's USB modem class driver interacts with the device from how other platforms do. For the time being, I'm trying to read the code of the NetBSD and the FreeBSD drivers, along with the USB CDC spec, to see what's going on. Based on experience, I'm sure this would go a LOT faster if I had a USB sniffer device that showed me what was sent and what was received at the USB layer -- then I could go back to the code and understand that. But unfortunately, I don't have access to a sniffer yet :-(. There might be something in the USB code that already verbosely dumps I/O -- I'm still trying to get myself re-familiarized with the USB code in NetBSD, so maybe I'll find it. If not, I may end up trying to add that. Rob
Re: problems with USB/CDC serial (umodem) - devices work with Linux, Mac OS X, and FreeBSD, but not NetBSD
On Mon, Feb 18, 2019 at 09:11:51AM -0800, Rob Newberry wrote: > I'm pretty sure there are differences in how NetBSD's USB modem class > driver interacts with the device from how other platforms do. For the > time being, I'm trying to read the code of the NetBSD and the FreeBSD > drivers, along with the USB CDC spec, to see what's going on. Hmm, I thought I would be using umodem, but actually it is u3g. However, I am pretty sure that at that level the driver does not do anything special but just pass on the data in both ways. Martin
Re: problems with USB/CDC serial (umodem) - devices work with Linux, Mac OS X, and FreeBSD, but not NetBSD
mar...@duskware.de (Martin Husemann) writes: >> NetBSD: >> 600 1 wpantund GIO fd 4 wrote 7 bytes >> "~\M^A\^B\^A\M-E\M-2~" >> FreeBSD writes 7 bytes, then reads back about 8 bytes: >> 907 wpantund GIO fd 4 wrote 7 bytes >> 0x 7e81 0201 c5b2 7e >> |~.~| >Note that your FreeBSD installation writes something completely different >to the device. NetBSD writes the same bytes, that's just vis style. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: problems with USB/CDC serial (umodem) - devices work with Linux, Mac OS X, and FreeBSD, but not NetBSD
On Mon, Feb 18, 2019 at 09:24:33AM +0100, Martin Husemann wrote: > Note that your FreeBSD installation writes something completely different > to the device. It has been pointed out off list that the FreeBSD ascii version is just differently encoded (with "." for unprintable character), and the packet written is actually identical. So I have no idea why the device answers differently (and no idea how to debug this unless the device itself offers some debug options). Martin
Re: problems with USB/CDC serial (umodem) - devices work with Linux, Mac OS X, and FreeBSD, but not NetBSD
On Sun, Feb 17, 2019 at 08:21:23PM -0800, Rob Newberry wrote: > > Please show us more details, like: > > > > - kernel messages how the devices attach > > On NetBSD: > > umodem0 at uhub2 port 1 configuration 1 interface 1 > umodem0: Nordic Semiconductor (0x1915) nRF52840 OpenThread Device > (0xcafe), rev 2.00/1.00, addr 4, iclass 2/2 > umodem0: data interface 2, has CM over data, has no break > umodem0: status change notification available > ucom0 at umodem0 So this looks like it is working just fine. > NetBSD writes 7 bytes, selects and gets back 1 byte, but it's clearly not the > data we're expecting. I do understand that data arriving over serial ports > can be corrupted, but this seems odd for "corruption" -- the data IS NOT what > we expect every time on NetBSD, and IS what we expect every time on FreeBSD. > > NetBSD: > > 600 1 wpantund GIO fd 4 wrote 7 bytes > "~\M^A\^B\^A\M-E\M-2~" > FreeBSD writes 7 bytes, then reads back about 8 bytes: > > 907 wpantund GIO fd 4 wrote 7 bytes > 0x 7e81 0201 c5b2 7e > |~.~| Note that your FreeBSD installation writes something completely different to the device. You will have to find out how it comes to that command and what it actually sends, and why on NetBSD wpantund seems to write pure giberish. Martin
Re: xhci power to external device
g...@lexort.com (Greg Troxel) writes: >Rhialto writes: >> I have an external harddisk, like so: (output from usbdevs -v) >> >> Controller /dev/usb0: >> addr 0: super speed, self powered, config 1, xHCI Root Hub(0x), vendor >> 8086(0x8086), rev 1.00(0x0100) >> port 1 addr 9: super speed, power 224 mA, config 1, Elements 25A1(0x25a1), >> Western Digital(0x1058), rev 10.14(0x1014), serial >> >> I have some reason to believe it does nog get enough power from the >> port. Is the "power 224 mA" how the current is actually limited? Or can >> the device draw more without telling us? >My impression is: > USB ports and devices are limited to 500 mA, per the spec. (But, > there are various schemes for USB chargers to communciate that they > support more, so devices can be willing to draw more) USB2 ports are limited to 100mA and devices may communicate that they want more (up to 500mA) and then are signaled to draw more power. USB3 is similar but allows other limits, 150mA default and 900mA max. There are also USB3 options that allow even more power, e.g. for USB chargers. That information is mostly used to calculate the power budget, If it would be exceeded, the device isn't allowed to draw more power. Many USB controllers cannot limit the power output, so even when a device is denied the extra power (or didn't even dare to communicate and is only allowed the minimum) it could just draw higher currents. Some USB controllers that can limit the power output only switch between minimum and unlimited. That's also allowed so that a USB2 device asking for 500mA can actually draw 900mA on a USB3 port without violating the spec. > I have never heard of a port that can throttle what it supplies. Throttling would cause the voltage to drop, which of course happens when a device tries to draw more current than the port can provide. A USB controller that limits power output on a port does this to protect the port. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
