Re: NetBSD 10 and framebuffer consoles setup vs 9.3 (font, multiple...)
RVP wrote: and the system will now use the larger font if you have a high enough display. Otherwise, you would end up with an unreadable chars. on, say, 4K displays. Surely this should be against the display density? (i.e. DPI) That of course means being able to read the DPI from somewhere, but isn't that a thing that EDID does? Staffan
MNT Reform2 (NXP LPC IFLASH) usb problem
Hey! I have a MNT Reform2 ARM-based open-sores laptop that I hope to get NetBSD on at some point (currently hampered by me having gotten the more powerful ls1028a cpu module instead of the i.mx8 one which is not properly supported by u-boot so no graphical console on boot. I have some plans to use the onboard serial port to see what a netbsd thumbstick does, but I need to build some hardware for that.) Onward to the subject, I wanted to update the LCP firmware on the laptop, which is done by mounting an internal USB device on another computer and copying (the official documentation uses dd for some reason) a file to a FAT filelesystem. I set the reform to flash-firmware mode and NetBSD detected the expected usb device properly but after that all I get from the device is I/O error: [21.611880] umass1 at uhub3 port 3 configuration 1 interface 0 [21.611880] umass1: NXP (0x1fc9) LPC1XXX IFLASH (0x000b), rev 2.00/7.04, addr 5 [21.611880] umass1: using SCSI over Bulk-Only [21.611880] scsibus1 at umass1: 2 targets, 1 lun per target [21.611880] sd1 at scsibus1 target 0 lun 0: disk removable [21.611880] sd1: fabricating a geometry [21.611880] sd1: 34816, 0 cyl, 64 head, 32 sec, 512 bytes/sect x 68 sectors [21.611880] autoconfiguration error: sd1: unable to open device, error = 5 At first I tried plugging it into my trusty x220 laptop and then I tried plugging it in to my windows desktop--which worked, I could see the firmware.bin file--but when I booted a netbsd install thumbdrive on the same desktop, I got EIO again. This is not just the autoconfigurator, but any communication attempt with the disk results in EIO. Clearly something is not working properly, thoughts? Staffan
Re: Blocklistd + postfix
Martin Neitzel wrote: Brook Milligan wrote: BM> Does it make sense that failed SMTP authentication should trigger BM> blocklistd events? What irks me about blocklistd(8) is the lack of a way of correcting such mishaps quickly. blocklisctctl(8) should not just have the current "dump" sub-command to investigate the blocked entries; having some "release/cleanup" facilities would be a real bonus. Restoring access directly with npfctl (or whatever is used) doesn't feel right to me. Indeed! I built a small tool[0] that lets my friends unblock themselves/eachother when they have an accident. What's bad with it is that it's unreliable as blocklistd keeps its own database and does not sync back changes from npf even as it maintains a rule id (did the rule go away? then reset counters!). While we're wishing, I would propose a manual report sub-command as well for programs that can run a program on an event in som way--perhaps even a shellscript/cron-based logwatcher--so that they don't necessarily have to be patched to integrate. It would broaden the possibilities but perhaps there are security implications that I'm not thinking of. A PAM module would probably be pretty simple to build as well (I have some experience there). I have too many projects going on to nominate myself for patching any of this, however wishing is still free and those who don't ask don't get... That turned into a bit of a sleepy stream of consciousness, apologies. Staffan [0] https://git.shangtai.net/staffan/unblacklist
Re: Access FFS partition on GPT on ZVOL
Michael van Elst wrote: m...@petermann-it.de (Matthias Petermann) writes: saturn$ doas dmsetup create net-export --table "34 2147483581 linear /dev/zvol/rdsk/tank/backup/vhost/vol/net-export 0" create and load called Please try: --table "0 2147483581 linear /dev/zvol/dsk/tank/backup/vhost/vol/net-export 34" left side is the offset + size of a chunk of your new mapped device right side is the backing store (must be the block device) and the offset on the backing store. Worked for me, thanks! This means I don't have to patch zvol.c any more for mounting snapshots :-) Staffan
Re: Access FFS partition on GPT on ZVOL
Being a curious person, and because this might let me avoid the zvol patch (and I now have a spare system to test these things on), I tried it too: surtr# uname -a NetBSD surtr 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug 4 15:30:37 UTC 2022 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64 surtr# zfs create -V 1G tank/export surtr# cat <> /etc/iscsi/targets: extent0 /dev/zvol/rdsk/tank/export 0 1024MB target0=surtr.exportrw extent0 0.0.0.0/0 EOF surtr# /etc/rc.d/iscsi_target onestart (initialize and create filesystem on windows client, add a file for good measure) surtr# dmsetup create exportdm --table "0 1073741824 linear /dev/zvol/dsk/tank/export 0" surtr# gpt -m 1073741824 -s 512 show /dev/mapper/rexportdm start size index contents 01 PMBR 11 Pri GPT header 2 32 Pri GPT table 3432734 1 GPT part - Windows reserved 32768 2060288 2 GPT part - Windows basic data 2093056 4063 Unused 2097119 32 Sec GPT table 20971511 Sec GPT header gpt wouldn't let me show unless I specified -m and -s, perhaps setgeometry would make that work. and then... no way of getting at the partitions that I could think of. surtr# dkctl /dev/mapper/exportdm addwedge xxx 32768 2060288 NTFS dkctl: /dev/mapper/exportdm: addwedge: Inappropriate ioctl for device surtr# ccdconfig -c ccd0 0 /dev/mapper/exportdm ccdconfig: ioctl (CCDIOCSET): /dev/rccd0d: Invalid argument Staffan
Re: ucom, umodem and conbee II
David Brownlee wrote: On Sat, 3 Sept 2022 at 12:14, Staffan Thomén wrote: Nevermind, I rewrote my program in C and umodem works perfectly fine, although I do note that I had to use O_NONBLOCK, something the GFCFlasher program explicitly omits. Glad to hear you found a solution. Could it be down to default port settings across different systems? Nah, I found out later after having twiddled with my code some more that it wasn't actually accepting my command, I was receiving but not sending (hence why O_NONBLOCK worked). Turns out that the serial protocol is little-endian and it was upset with me for sending messages that I said were 0x9000 bytes long, not 0x9... :-) Would you be using https://phoscon.de/en/conbee2/ ? Looks interesting - I have a bunch of hue lights/sensors/plugs and use https://github.com/bahamas10/hueadm to poke at them from my NetBSD box as needed (such as a script to ensure the printer plug is on before printing, or to gradually turn down some lights at night :) but I've always wondered what other options might be provided by poking at the individual devices more directly... Exactly that ConBee II. The device seems really nice (and you get the protocol docs! although they don't mention the litte-endian bit..), and it does talk to some philips hue plugs I bought; I could control them when I plugged the conbee into my windows PC and used the official software. While I got into this whole replace-my-433MHz-system-with-zigbee thing I also bought one of the usb connected CC2531 boards and it seems to also use umodem. They're a bit tricky though because TI designates the chip as a zigbee-sniffer, so you have to flash them using some pins on the board in order to use them as a controller. Haven't really looked at that yet and I don't have a programmer (but maybe I could convince an arduino to do the programming). Both of these could be of interest to you, I'm not sure if the hue (or even zigbee, I haven't been doing my homework :-) allows more than one controller though, could be interesting to find out. I'm not sure where I'm going with this project yet, it was a fun diversion trying to talk to the conebee, but zigbee is a whole thing itself and my code can only request the firmware version from the device so far (and handle unsolicited messages from the device). Code can be found here: https://git.shangtai.net/staffan/cdeconz/ (this url will not be permanent, the official software is called deconz and I don't want to confuse my code with theirs) Feel free to grab a copy if you want to play with it though :-) Cheers, Staffan
Re: Access FFS partition on GPT on ZVOL
Matthias Petermann wrote: Am I doing something fundamentally wrong here? Or does this require a kernel newer than 9.3? In order to do this (something I needed as well, but with NTFS for backing up an iscsi-exported photos zvol) you need to patch zfs so that ccd can use zvols as components; see this thread: http://mail-index.netbsd.org/netbsd-users/2020/02/26/msg024099.html (patch linked here: http://mail-index.netbsd.org/netbsd-users/2020/02/27/msg024123.html) I'm a little sad that this (or something more convenient) hasn't been included in -9 :-/ I have written a shellscript that lets me mount snapshots of zvols locally for backup purposes if that is interesting, since the process has a number of steps. I run snapshot refresh from cron. https://git.shangtai.net/staffan/snapshot Staffan
Re: ucom, umodem and conbee II
Nevermind, I rewrote my program in C and umodem works perfectly fine, although I do note that I had to use O_NONBLOCK, something the GFCFlasher program explicitly omits. Sorry about the noise, Staffan
ucom, umodem and conbee II
Dear hive-mind, I recently procured a conbee II zigbee controller and some sensors to switch my aging 433MHz system over to something neater. For fun I thought I'd plug it into my netbsd laptop and see if I could talk to it, and maybe build some lightweight control software that could plug into my existing system instead of having to use the nodejs monstrosities that are so popular these days. The manufacturer provides documentation for the serial device protocol so it seemed viable. The device is detected just fine by netbsd 9.3_STABLE (althoug always twice, for some reason, it attaches, then detaches and then attaches again, I suspect that the first time is a firmware update mode) However the device refuses to reply to any message. I tried prototyping in python using the serial library but it never responds with anything. I know it wants 8N1 and I've tried various speeds but no response what so ever. Reads always hang, but writes seem to work. Code here: https://git.shangtai.net/staffan/pydeconz From what I can read from the official software's linux or "posix" or windows code, the python serial library does everything that they do with regards to open flags and tcsetattr. What's more, I tried the official flash tool and it also seems to hang on NetBSD just like my code (even after I changed it so that it sets the speed to 115200 even if the device name is called "ttyU" and not "ttyACM" so there's an indication that it may also be flawed in other ways). Just to eliminate hardware failures, I tried it under windows, and that worked fine. I also tried building a GENERIC-derived kernel with options USBVERBOSE, options USB_DEBUG and options UCOM_DEBUG but that didn't seem to provide any more information, even after setting hw.ucom.debug to 1. Any ideas to what I'm doing wrong? Is it something with NetBSD's umodem driver that needs special attention? Staffan dmesg below: [29.364000] umodem3 at uhub5 port 2 configuration 1 interface 0 [29.364000] umodem3: dresden elektronik ingenieurtechnik GmbH (0x1cf1) ConBee II (0x30), rev 2.01/1.00, addr 4, iclass 2/2 [29.364000] umodem3: data interface 1, has CM over data, has no break [29.364000] umodem3: status change notification available [29.364000] ucom3 at umodem3 [32.235155] ucom3: detached [32.235155] umodem3: detached [32.235155] umodem3: at uhub5 port 2 (addr 4) disconnected [33.335597] umodem3 at uhub5 port 2 configuration 1 interface 0 [33.335597] umodem3: dresden elektronik ingenieurtechnik GmbH (0x1cf1) ConBee II (0x30), rev 2.01/1.00, addr 4, iclass 2/2 [33.335597] umodem3: data interface 1, has CM over data, has no break [33.335597] umodem3: status change notification available [33.335597] ucom3 at umodem3
Re: Status of syspkg or similar
Sad Clouds wrote: On Sat, 22 May 2021 17:43:31 +0900 Yuuki Enomoto wrote: Hello, From what I can tell the feature is somewhat unfinished/abandoned? Yes. "build.sh syspkgs" can create packages. But these may remove exist files/directories by install. I think, we should fix it completely and/or make sysinst support this for testing. A hybrid/staged solution might be worth considering. I've often thought about how the not-exactly-core utilities like tmux (but window would probably not have fallen into this category were it still there), postfix and bind (possibly also ssh, openssl might be too difficult to extract) _that have more alternate/newer versions in pkgsrc_ could live in their own set so I wouldn't have to install them and then just install the pkgsrc version and be stuck with two. That set would then be a prime target for syspkg, leaving everything else in the sets that might have more complicated dependencies and/or were historically part of the berkeley distribution. I'm not too familiar with syspkg, but perhaps the pkg tools then could be taught to upgrade them to pkgsrc if the admin wants to (hell, this might even be there already). .2c Staffan Because this is just me sprouting my musings, it's just sent to the list. It's ok to CC me.
About bridges
Hey! I was toying with bridging three of the four ethernet ports on an pcengines apu4d4 recently and bumped into something that made me unsure if I understood how to use bridges correctly. My setup is like this: wm1 configured with an address wm2 no address, just up wm3 same as 2 and the bridge: brconfig bridge0 add wm1 stp wm1 add wm2 stp wm2 add wm3 stp wm3 This all works, packets flow and addresses are learned on all interfaces, but ONLY if there is a cable with a link on wm1. It seems to be that if there is no link on wm1 the interface (status: no carrier and address shows ) gets disabled in the bridge, which kind of sucks because then the host has no address and communication stops. I tried looking for pseudo devices that I could use on the bridge for the host interface so that it wouldn't matter which port you plug a network in to, but the only thing I could attach to the bridge was a tap device and using that as the host if doesn't seem to work. The only other devices that I've done bridging on (except my Xen host, but that's a load of virtual interfaces connected to one real one which always had a link) are Mikrotik routerboards and there you could set an address on the bridge device itself; something that you cannot do on netbsd, apparently. So how is this supposed to work? Can I force the interface with an address to stay enabled somehow or is there a pseudo-device that I haven't found that I should be using? Staffan
Re: A single-board computer for NetBSD
Mike Pumford wrote: On 26/08/2020 13:12, Greg Troxel wrote: My recommendation to the broader question of "router box to run NetBSD" is the PC Engines apu2. This is a fanless system with a 4-core amd64-compatible processor: I'll second this recomendation. I'm also using one as my gateway firewall. Currently running NetBSD 8.2-STABLE as an npf firewall. I've successfully rewritten the BIOS on mine using flashrom on linux and the brief test I did of the NetBSD version of flashrom suggests it ought to work. It does correctly identify the BIOS flash chip successfully. Here's a third recommendation for the APU2 systems. They are very nice (although I am annoyed by the bios resetting my (real) serial terminal every time it hands over to the operating system, making the terminal go through it's boot-up reset cycle, but that's coreboot). I'm also pretty sure that I updated the rom using flashrom(8) on NetBSD. Staffan
Re: dk for z/lvm volumes?
Michael van Elst wrote: On Mon, Jun 29, 2020 at 07:08:40PM +0300, Staffan Thomén wrote: Chavdar Ivanov wrote: # ccdconfig -c ccd0 0 /dev/zvol/dsk/internal1/photos@backup You are mapping a snapshot, it will be r/o. You have to promote it first. While it's true that the snapshot is r/o, surely it shouldn't crash the system. Surely not. I'll have a look at the ccd driver. And is there a reason why ccd would require r/w? Neither the infrastructure to access such layered disk devices, nor the drivers themselves handle read-only components. The drivers are ccd, cgd and raidframe. Doesn't look that difficult to implement for ccd and cgd, not so sure about raidframe. Good news! I found another way to crash my system! I tried cloning the snapshot and then creating the ccd worked, manually creating a dk on the ccd worked, mounting a ntfs on the gpt worked, listing files on the ntfs worked, reading files off the ntfs worked. However... bluegleam# dkctl ccd0 makewedges [ 184722.7286780] Mutex error: mutex_vector_enter,564: locking against myself [ 184722.7286780] lock address : 0xc380065c6a40 [ 184722.7286780] current cpu : 0 [ 184722.7286780] current lwp : 0xc38007290aa0 [ 184722.7286780] owner field : 0xc38007290aa0 wait/spin: 0/0 [ 184722.7286780] panic: lock error: Mutex: mutex_vector_enter,564: locking against myself: lock 0xc380065c6a40 cpu 0 lwp 0xc38007290aa0 [ 184722.7286780] cpu0: Begin traceback... [ 184722.7286780] vpanic() at netbsd:vpanic+0x143 [ 184722.7286780] snprintf() at netbsd:snprintf [ 184722.7286780] filt_logread() at netbsd:filt_logread [ 184722.7286780] mutex_vector_enter() at netbsd:mutex_vector_enter+0x158 [ 184722.7286780] ccdopen() at netbsd:ccdopen+0x52 [ 184722.7286780] spec_open() at netbsd:spec_open+0x175 [ 184722.7286780] VOP_OPEN() at netbsd:VOP_OPEN+0x4c [ 184722.7286780] dkwedge_discover() at netbsd:dkwedge_discover+0xb4 [ 184722.7286780] disk_ioctl() at netbsd:disk_ioctl+0xd3 [ 184722.7286780] ccdioctl() at netbsd:ccdioctl+0x1c9 [ 184722.7386785] VOP_IOCTL() at netbsd:VOP_IOCTL+0x54 [ 184722.7386785] vn_ioctl() at netbsd:vn_ioctl+0xa5 [ 184722.7386785] sys_ioctl() at netbsd:sys_ioctl+0x547 [ 184722.7386785] syscall() at netbsd:syscall+0x9c [ 184722.7386785] --- syscall (number 54) --- [ 184722.7386785] 724a0b5681ba: [ 184722.7386785] cpu0: End traceback... [ 184722.7386785] dumping to dev 4,1 (offset=1048575, size=0): not possible [ 184722.7386785] rebooting... (XEN) Hardware Dom0 shutdown: rebooting machine Ngh. ccdconfig -g was also a bit odd that it listed ccd0 four times. But this time no crash there. Staffan
Re: dk for z/lvm volumes?
Michael van Elst wrote: On Mon, Jun 29, 2020 at 07:08:40PM +0300, Staffan Thomén wrote: Chavdar Ivanov wrote: # ccdconfig -c ccd0 0 /dev/zvol/dsk/internal1/photos@backup You are mapping a snapshot, it will be r/o. You have to promote it first. While it's true that the snapshot is r/o, surely it shouldn't crash the system. Surely not. I'll have a look at the ccd driver. And is there a reason why ccd would require r/w? Neither the infrastructure to access such layered disk devices, nor the drivers themselves handle read-only components. The drivers are ccd, cgd and raidframe. Doesn't look that difficult to implement for ccd and cgd, not so sure about raidframe. Thank you for your efforts, if we get this stable it'll be pretty massively useful to me Staffan
Re: dk for z/lvm volumes?
Chavdar Ivanov wrote: # ccdconfig -c ccd0 0 /dev/zvol/dsk/internal1/photos@backup You are mapping a snapshot, it will be r/o. You have to promote it first. While it's true that the snapshot is r/o, surely it shouldn't crash the system. And is there a reason why ccd would require r/w? Staffan
Re: dk for z/lvm volumes?
Michael van Elst wrote: mlel...@serpens.de (Michael van Elst) writes: mlel...@serpens.de (Michael van Elst) writes: ci4...@gmail.com (Chavdar Ivanov) writes: # ccdconfig -c ccd0 0 /dev/zvol/dsk/pail/nbsd1 ccdconfig: ioctl (CCDIOCSET): /dev/ccd0d: Inappropriate ioctl for device That's a bug in the zfs driver. I've prepared a patch for -current that fixes this issue. http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/zvol.patch I had occasion to try this patch (downloaded on June 19) on my Xen dom0 today, and things didn't go well; # ccdconfig -c ccd0 0 /dev/zvol/dsk/internal1/photos@backup ccdconfig: ioctl (CCDIOCSET): /dev/ccd0d: Read-only file system ...and a subsequent... # ccdconfig -g ...instantly rebooted the system (no crash dump). I wasn't monitoring the console so I don't know if any error was printed by the kernel. Nothing was recorded in syslog. This is NetBSD 9.0_STABLE from June 19 (built at the same time as the patched z, with xen 4.11 (4.11.3nb2) Staffan
Re: dk for z/lvm volumes?
Greg Troxel wrote: The other thing you can do is export the zvol snapshot via iscsi and use an iscsi initiator on netbsd to mount it. I tried this particular flavor of filesystem/network pretzel and when a full backup ran, it worked for a while and then killed my system DEAD. Not even the IPMI console would respond. The zvol lived on the dom0, exported via iscsi, but I used a domU for the initiator since I didn't have iscsi support in my dom0. Staffan
Re: dk for z/lvm volumes?
Replying to you both in one here.. Chavdar Ivanov wrote: On Wed, 26 Feb 2020 at 18:18, Greg Troxel wrote: Staffan Thomén writes: I couldn't coax dkctl to create dk devices for the gpt on the volume, and dkctl seems like a bit of a mismatch for creating arbitrary dk:s anyway as it seems mostly directed at bare drives (cache settings etc). From the NetBSD point of view there is a zvol, and you are letting iscsi manage it. So there's nothing to tell netbsd to read a gpt/mbr and deal. Indeed, but that's where dkctl comes in with makewedges to tell netbsd to scan for wedges, but that doesn't work (wonderfully it says "Read-only file system" on the (admittedly read only) volume snapshot). The other thing you can do is export the zvol snapshot via iscsi and use an iscsi initiator on netbsd to mount it. This would work, but seems like a bit of a pretzel of a solution. What I'm mostly wondering is if it wouldn't be sensible to extend dk to be able to be used with volumes. > [...] perhaps looking at it from the Windows initiator would have more sense - unless the backup is supposed to be done on the NetBSD host, in which case the suggestion would be to # zfs send pail/nbsd1> nbsd1.zfsfs and then backup the resulting zfs stream, which you can cmpress of course. Yup, this would definitely work, but it's terribly inefficient on tape use since I can't do block-level differential backups. Whenever the volume filesystem changes, I have to backup the entire thing. Staffan
dk for z/lvm volumes?
Hey, I recently wanted to set up backup of a (snapshot of a) zvol that I had exported via iscsi to a windows machine, and got stumped because windows didn't just create a ntfs filesystem on the volume, it also added a partition table and so mount_ntfs and ntfs-3g couldn't find the filesystem on it. I couldn't coax dkctl to create dk devices for the gpt on the volume, and dkctl seems like a bit of a mismatch for creating arbitrary dk:s anyway as it seems mostly directed at bare drives (cache settings etc). My other thought was using vnconfig, but that doesn't seem like the right tool either. This left me with a couple of questions, is dk the right fit for getting at partitions on logical volumes? Could a tool be written that does this so we wouldn't have to load down dkctl with features that aren't really related to disks or is dk* not the right device and a new driver is needed? Have I just missted something? Thoughts? Staffan
Re: Strange behaviour on PCEngines APU2
Greg Troxel wrote: Staffan Thomén writes: Christos Zoulas wrote: Any suggestions? Use a powered usb hub. That would be very inconvenient as the server is rackmounted and there's only IE320 C14 outlets in the rack. Could you please elaborate on this? Is the device drawing too much power? According to usbdevs it seems to want 90mA. I think Christos's theory is that very often, there are problems in USB due to power, and that absent being 100% sure that this isn't the case, testing with a powered hub is useful. I suppose you could also use a non-powered USB2 hub. Turns out a powered hub did not solve the problem. I left it in overnight and when I woke up it was back to pseudo-hung. Right now I've removed the usb devices to see if it recovers. Staffan
Re: Strange behaviour on PCEngines APU2
Greg Troxel wrote: And I suspect that 2 of the four logical ports on uhub3 appear at J11 (internal USB2). But on my system nothing is plugged in to that jack and nothing attaches to the ehci hub. uhub1 ports 1 and 2 appear to be the external connectors (as USB2) and on mine show up as a disk and a 4-port powered hub. Given that your tellstick is surely plugged into one of the external ports (where it works as xhci) I am at a loss to understand how it is apparently attaching to ehci. (I believe you; but something is very odd here.) You know, you are absolutely right. The tellstick can't possibly have been connected to the ehci, both ports on the front panel are on uhub1 and that is on xhci0. The damn things are even colored blue. My initial trouble must have been just sheer idiocy on my part. In any event, I've bought a powered hub and am trying to see if that improves things. On that note, back when USB harddrives first came out, there were those two male to one female usb cables that used one port for power+data and one for just power. Could that save me the trouble of hooking up power for a hub? Thoughts? Staffan
Re: Strange behaviour on PCEngines APU2
Christos Zoulas wrote: Any suggestions? Use a powered usb hub. That would be very inconvenient as the server is rackmounted and there's only IE320 C14 outlets in the rack. Could you please elaborate on this? Is the device drawing too much power? According to usbdevs it seems to want 90mA. Staffan
Re: Strange behaviour on PCEngines APU2
On 2019-11-20 22:05, Greg Troxel wrote: Normally the tellstick would attach as a uftdi device with an ucom, but because the controlling daemon uses libftdi I've disabled those and it's attached as an ugen device. Slightly surprising that the daemon doesn't just use a serial port. (aoetec zstick seems to just be serial) I expect it's because they use the same code for windows. There was also a problem communicating with it when it attached using ehci, disabling ehci made it connect through an uhub attached to xhci and it started to work. Apparently something isn't working right though, but I don't know any knobs to twiddle here. Are you sure you didn't get that backwards? ehci is USB2, and xhci is USB3. Is the tellstick a USB3 device, or USB2, or ? The tellstick is probably a USB2 device (it's a bit hard to tell..), but somehow it still attached and worked on the xhci; this is from the dmesg in the first message in this thread: usb1 at xhci0: USB revision 2.0 uhub1 at usb1: vendor 1022 (0x1022) xHCI Root Hub (), class 9/0, rev 2.00/1.00, addr 0 ugen0 at uhub1 port 1 ugen0: Telldus (0x1781) TellStick Duo (0xc31), rev 2.00/6.00, addr 1 I just tried setting it up on my laptop running 8.1_STABLE from June 10th, and it works with either ehci or xhci, but with xhci it only works on one specific usb port. If I let it attach via ehci, it works on any of the three ports. On the lenovo x220: usb0 at xhci0: USB revision 3.0 usb1 at xhci0: USB revision 2.0 uhub1 at usb1: vendor 1033 (0x1033) xHCI Root Hub (), class 9/0, rev 2.00/1.00, addr 0 uhub1: 2 ports with 2 removable, self powered ugen0 at uhub1 port 1 ugen0: Telldus (0x1781) TellStick Duo (0cx31), rev 2.00/6.00, addr 1 The man page for xhci indicates that it is for 1.x, 2.0 and 3.0 devices, and hints that the xhci driver is for some particular communication method between the OS and the controller. As far as I can tell, the tellstick doesn't cause any issues on the x220 when connected via xhci. I tried reading the status from it once a second and running a ping at the same time without issue. I would be looking at trying to add attachment quirks so that the device is not attached by the USB controller that causes problems, which is like removing it for this devive, but not in general. I guess that would be useful if I ever needed the USB ports for anything else. I've mainly been too busy with work/tired to experiment on the apu2 (also it's the main gateway in my network and a pain in the ass if it hangs). Time willing I will do some tests this weekend. Staffan
Re: Strange behaviour on PCEngines APU2
Greg Troxel wrote: Staffan Thomén writes: I recently got a PCEngines APU2 (not sure of the exact model) to replace my failing Soekris gateway As Joseph taught Eliza to say, many others have the same sorts of feelings. Except that my net5501 was fine, just slow, and I got an apu2d4. Yeah, my net6501 started to exhibit a well known fault (the "Red LED of Death") where it doesn't get as far as the bios when booting "warm" (once running it would keep running though). You can still use the +++ command on the serial console to get to the uManager when it is in this state, but it has to cool down for a couple of hours unplugged before it'd boot back up again. Someone on the Internet(tm) claimed that replacing two caps near the power connector helped, but that didn't solve the problem on mine. Anyway, I found what was causing the issue, if not how. I have a telldus tellstick 433MHz "home automation" controller connected via USB to the system, and removing it completely cleared the problem. The APU has been running for several days now without issue. However I really would like to be able to control my lights... Normally the tellstick would attach as a uftdi device with an ucom, but because the controlling daemon uses libftdi I've disabled those and it's attached as an ugen device. There was also a problem communicating with it when it attached using ehci, disabling ehci made it connect through an uhub attached to xhci and it started to work. Apparently something isn't working right though, but I don't know any knobs to twiddle here. The device was working flawlessly on the soekris. Any suggestions?
Strange behaviour on PCEngines APU2
Hi! I recently got a PCEngines APU2 (not sure of the exact model) to replace my failing Soekris gateway and some strange behaviour appeared after I took it in production. After the system has been running for a few hours, it seems to stop being able to send packets on the internal wired network interface (possibly also the external, I can't tell) on a per-process basis, and seems to mostly affect IPv4. ICMP and UDP seems more prone to failure than TCP retransmission?). For instance, if I ping a host on my network from the gateway, only a few icmp requests go out (checked with tcpdump), sometimes one, sometimes ten but then it just sits there. The process seems to be stuck in select, if top is to believed. Attaching a debugger yields; (gdb) bt #0 0x70e3f803e28a in poll () from /lib/libc.so.12 #1 0x2f003a6f in main () Once I quit the debugger, sometimes a few packets get sent (and received) again. Pressing ctrl-c stops the ping process properly, and it says it sent and received 8/8 packets or whatever. Disabling pf did nothing. Packet forwarding seems to work just fine. I also have a small daemon that I wrote that listens to pflog devices that decodes the log and sends the messages to syslog. These also seem to stop in the same maner as ping, but in read() in pcap_loop(). Once the system is in this state, it can't reboot itself either, presumably waiting something somewhere. The apu2 is flashed with the latest firmware available, and that made no difference. Since this is a new system, I don't know if it's faulty or if netbsd is doing the strange stuff. Advice? I will probably try to roll back my sources to this summer sometime and see if an older kernel works, the kernel that was optimized for my NET6501 appeared to not have the same problem, but I am not sure. current kernel config: include "arch/amd64/conf/GENERIC" # no need for this (no X11) no options INSECURE # not a mac no options DKWEDGE_METHOD_APPLE # is a gateway options GATEWAY # I prefer pf no options IPFILTER_LOG no options IPFILTER_LOOKUP no options IPFILTER_COMPAT dmesg: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 8.1_STABLE (APU2) #1: Thu Nov 14 06:56:15 EET 2019 d...@power.shangtai.net:/usr/build/src/sys/arch/amd64/compile/obj/APU2 total memory = 1919 MB avail memory = 1840 MB rnd: seeded with 256 bits timecounter: Timecounters tick every 10.000 msec Kernelized RAIDframe activated running cgd selftest aes-xts-256 aes-xts-512 done [455] uftdi* disabled [185] ehci* disabled [186] ehci* disabled timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 PC Engines apu2 (1.0) mainbus0 (root) ACPI: RSDP 0x000F3AF0 24 (v02 COREv4) ACPI: XSDT 0x7EEA70E0 74 (v01 COREv4 COREBOOT CORE 20180531) ACPI: FACP 0x7EEA8DF0 F4 (v04 COREv4 COREBOOT CORE 20180531) ACPI: DSDT 0x7EEA7280 001B6E (v02 COREv4 COREBOOT 00010001 INTL 20180531) ACPI: FACS 0x7EEA7240 40 ACPI: SSDT 0x7EEA8EF0 0001EA (v02 COREv4 COREBOOT 002A CORE 20180531) ACPI: MCFG 0x7EEA90E0 3C (v01 COREv4 COREBOOT CORE 20180531) ACPI: TPM2 0x7EEA9120 4C (v04 COREv4 COREBOOT CORE 20180531) ACPI: APIC 0x7EEA9170 7E (v02 COREv4 COREBOOT CORE 20180531) ACPI: HEST 0x7EEA91F0 0001D0 (v01 COREv4 COREBOOT CORE 20180531) ACPI: IVRS 0x7EEA93C0 000108 (v01 COREv4 COREBOOT CORE 20180531) ACPI: SSDT 0x7EEA94D0 0048A6 (v02 AMDAGESA0002 MSFT 0400) ACPI: SSDT 0x7EEADD80 0007C8 (v01 AMDAGESA0001 AMD 0001) ACPI: HPET 0x7EEAE550 38 (v01 COREv4 COREBOOT CORE 20180531) ACPI: Executed 2 blocks of module-level executable AML code ACPI: 4 ACPI AML tables successfully acquired and loaded ioapic0 at mainbus0 apid 4: pa 0xfec0, version 0x21, 24 pins ioapic1 at mainbus0 apid 5: pa 0xfec2, version 0x21, 32 pins cpu0 at mainbus0 apid 0 cpu0: AMD GX-412TC SOC , id 0x730f01 cpu0: package 0, core 0, smt 0 cpu1 at mainbus0 apid 1 cpu1: AMD GX-412TC SOC , id 0x730f01 cpu1: package 0, core 1, smt 0 cpu2 at mainbus0 apid 2 cpu2: AMD GX-412TC SOC , id 0x730f01 cpu2: package 0, core 2, smt 0 cpu3 at mainbus0 apid 3 cpu3: AMD GX-412TC SOC , id 0x730f01 cpu3: package 0, core 3, smt 0 acpi0 at mainbus0: Intel ACPICA 20170303 acpi0: X/RSDT: OemId , AslId acpi0: MCFG: segment 0, bus 0-63, address 0xf800 acpi0: SCI interrupting at int 9 timecounter: Timecounter "ACPI-Safe" frequency
Re: The state of SAS
Mike Pumford wrote: Configuration is probably done through the BIOS interface. I've always used the cards in non-RAID mode so I'm not really sure. I spent a while trying to convince the controller to pass through the tape drive and some spare drives I had, but to no avail. The BIOS GUI would just tell me that I couldn't make raid set of tape drives. I looked at the (very cryptic) "pre boot" console, and it seems it takes MegaCli parameters; -AdpGetProp enablejbod -a0 would indeed tell me Disabled, however -AdpSetProp enablejbod -a0 Just gave me a syntax error. Its possible a card in RAID mode can't handle a stand alone device. Never had access to a SAS tape drive so thats outside my area of knowledge. Seems like this is exactly the case. Although some Googling indicated that enabling jbod mode would not destroy extant sets, so that's encouraging. Should be no need for scans the devices should just appear as they are plugged in. It certainly worked that way on NetBSD when I did some testing with a SAS disk enclosure a while back. But what about non-disk devices? Did you try a CD drive? The LSI raid HBAs can usually be flashed with non-RAID firmware if you want to use them in that mode. I've not yet come across any generation of LSI card that this can't be done up to and including the current SAS3 chips. Firmware is typically flashed with lsiutil. Not sure if that runs on NetBSD but it certainly does on linux so a quick boot off a live filesystem linux CD should let you experiment with that. lsiutil also provides other diagnostics like bus topology which might help work out why your tape drive isn't working. Flashing sounds dangerous, and I expect I'd need at least a second card to get the existing data off my RAID sets unless there are firmwares that do both RAID and passthru. Does LSI provide official images or is it a question of someone grabbing firmware images of another card that just happens to work? Staffan
The state of SAS
Hello list I've fairly recently started to get into SAS as I got a server that supports it, and am still a little confused about how it works, and the support we have in NetBSD. The machine has a SuperMicro-branded LSI MegaRAID 2108 card and it works fine with the mfi driver, although I don't seem to have any way of configuring it from a running system (bioctl can list the volumes and that's about it) which is a bit of a drag. I also recently got a SAS tape drive, and connected it to the system and nothing happened. This might of course be because either a) the raid controller card does not support tape drives or b) they have to be configured and the card bios does not do it automatically. My questions then are; How does SAS really work (in NetBSD); specifically tape drives? Is it completely transport agnostic and st(4) will just attach? Can I scan the scsibus and expect things Just Work like with SCSI? What about with a non-raid HBA? The mfii driver seems to support some older LSI SAS controllers (9200-series) which is fine, are there any other alternatives for non-raid SAS, because raid cards are such a pain? If anyone would be so kind as to reduce my ignorance in the area, I'd be very grateful. Staffan
Re: /var on tmpfs
Don NetBSD wrote: I've a box with a DoM. I'd like to mount / as ro and create a tmpfs for /var (and /tmp). I don't think anything else NEEDS to be rw (the infrequent changes to /etc can be made by unlocking / to make those changes). I imagine I can just make a tarball of a skeletal /var and unpack this over /var, once mounted? Is there a preexisting mechanism for this sort of thing? Or, do I roll my own? How about using union mounts? I don't think you can do that for /, but for /var it should let you have your cake and eat it too. Just a thought. Staffan
Re: suspend-to-RAM intel-x86 issues and tests
David Brownlee wrote: On Thu, 27 Sep 2018 at 22:20, Riccardo Mottola wrote: Hi David, David Brownlee wrote: So I conclude that having the system mounted on USB causes issues (which manifests themselves slightly different on different computers) and while it probably should work, it is not a test and adds more issues. Would it be make sense to try booting a CD install image on some of the machines (to avoid the USB) issue? for those machines which have an optical drive, I can do so! To help NetBSD improve, this and more. Would using the install CD enough to test an ACPI suspend? is it enabled at all? Install CDs though do not usually enable DRM console, which is often a problematic component in sleep. Actually testing with/without drm would probably also be helpful - if a machine can reliably suspend/resume without DRM or active USB then it means that people can focus just on the DRM side. In any case, three ThinkPads have netbsd8 release on it, so testing is easier and they exhibit issues: T30, R51 and T43 (the latter with a regression compared to release). SO perhaps it is best fixing those first, before attempting more delicate work on others. Again, it might be interesting to see if the regression is in suspend/resume with DRM or more general :) Just for fun I disabled i915drmkms on my X220 running 8.0_STABLE and put it in S3 mode. It went to sleep, but when I tried the power button again I was left with a blank screen but glowing power button and bluetooth icon. I then tried it with nothing disabled and not having X running and it came back from sleep! *jaw drops* I must always have tried it with X running and it just wouldn't recover after the disk reattached (the high resolution console was still configured and working). wifi doesn't work though, the iwn driver complains: iwn0: could not load firmware .text section iwn0: could not load firmware iwn0: could not initialize hardware After some more testing, it's enough that I switch to the console before pressing the sleep button and it will come back, but xdm seems to go away. After a long while it restarts and I have an xlogin prompt again. Anyway, in my case it works _better_ with drm enabled. Staffan
Re: fail2ban or sshguard or blacklistd (or what else)?
Mayuresh wrote: I wish to set up a utility that would monitor logs of various services for a server on the internet and block nasty IPs. How do above options compare and which one is more common on NetBSD? So far, I tried using fail2ban and my impressions are: 1. Just too many dependencies, took long time to build. 2. Using default configuration it did not appear to do anything precious after watching it for some time when there were many auth failures seen in authlog. Mayuresh A bit late to the party, but py-denyhosts (pkgsrc://security/py-denyhosts) has worked great on a xen domU I had that didn't have pf support for my usual pf-based solution. It uses /etc/hosts.deny and only depends on python. Staffan
Re: vioif(4) ipv6 issues?
Staffan Thomén wrote: Greg Troxel wrote: Jeff Rizzo writes: I just noticed that a host of mine running as a Xen guest is not getting (or maybe just sending) ipv6 packets correctly. It's running pretty much the same as some physical hosts, and the only difference I can see is the Xen (and vioif) aspect. Are you using a bridge for xvifN.0 on the dom0? Try using ping6 to the link-local (fe80::) addresses. Remember to use %ifname as it appears in ifconfig (other end's address, your ifname). Try running tcpdump in promiscuous mode on both ends. That can hide some mcast programming/filtering bugs to help diagnosis. First, ping the ll address of the xvif from the domU, and vice versa. The tone I imagined in your email seems to suggest that you know why this is happening. I am seeing this exact problem on my Xen setup, it's a NetBSD 7.1 dom0 with 7.1 domU:s using xvif linked to the real wm with a bridge. The domUs sometimes become completely unresponsive on ipv6, but then recover. ipv4 seems completely unaffected. Sometimes the dom0 is also unresponsive on v6. It seems to happen as the domUs are idle, with little to no traffic, because one of the VMs host my (v6) irc session and it has stayed up for 30+ days. Following up on my own mail here, sorry. I did some investigation and noticed that listing the entries in NDP on my v6 gateway showed the nonresponsive (xen domU) hosts as having expired. This would explain the unresponsiveness. Next I dumped the traffic going through the dom0's interface, and saw the gateway querying ff02:: of the expired hosts repeatedly but not getting a reply (this seems like a fallback broadcast). So I looked a little closer, and my domU:s were using dhcpcd to handle ipv6, so I put 'ipv4only' in dhcpcd.conf, set net.inet6.ip6.accept_rtadv to 1 in sysctl, enabled rtsold and restarted networking. Voila, the problem went away completely. I'm guessing this is a bug in dhcpcd and that it doesn't reply to neighbour solicitation queries properly when there's a transparent hop like bridge(4) in the network. The expire times seem to become very short (looks like 60 seconds) where hosts directly connected get 24 hours. Maybe this can help the OP. Staffan
Re: vioif(4) ipv6 issues?
Greg Troxel wrote: Jeff Rizzo writes: I just noticed that a host of mine running as a Xen guest is not getting (or maybe just sending) ipv6 packets correctly. It's running pretty much the same as some physical hosts, and the only difference I can see is the Xen (and vioif) aspect. Are you using a bridge for xvifN.0 on the dom0? Try using ping6 to the link-local (fe80::) addresses. Remember to use %ifname as it appears in ifconfig (other end's address, your ifname). Try running tcpdump in promiscuous mode on both ends. That can hide some mcast programming/filtering bugs to help diagnosis. First, ping the ll address of the xvif from the domU, and vice versa. The tone I imagined in your email seems to suggest that you know why this is happening. I am seeing this exact problem on my Xen setup, it's a NetBSD 7.1 dom0 with 7.1 domU:s using xvif linked to the real wm with a bridge. The domUs sometimes become completely unresponsive on ipv6, but then recover. ipv4 seems completely unaffected. Sometimes the dom0 is also unresponsive on v6. It seems to happen as the domUs are idle, with little to no traffic, because one of the VMs host my (v6) irc session and it has stayed up for 30+ days. Staffan
