Re: Basic vt100 console "noisy"
On 2019-11-20 23:20, Rhialto wrote: On Wed 20 Nov 2019 at 21:44:56 +0100, Johnny Billquist wrote: You might want to look at the syslogd configuration then? That might be one source of messages being printed. Furthermore, they are only printed to the first console. If you enable more (ttyE[0-3] in /etc/ttys I think, and wscons=YES in /etc/rc.conf), you can login on other consoles that are quiet. Well, those are not even the console. They might appear on the same physical screen, but from the OS point of view, they are different terminals. But yes, you have a good point there. Switch to another terminal, and you should also not be bothered by output to the console. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Basic vt100 console "noisy"
On Wed, 20 Nov 2019, Rhialto wrote: Date: Wed, 20 Nov 2019 23:20:40 +0100 From: Rhialto To: Johnny Billquist Cc: Clay Daniels , netbsd-users , Scott Bennett Subject: Re: Basic vt100 console "noisy" On Wed 20 Nov 2019 at 21:44:56 +0100, Johnny Billquist wrote: You might want to look at the syslogd configuration then? That might be one source of messages being printed. Furthermore, they are only printed to the first console. If you enable more (ttyE[0-3] in /etc/ttys I think, and wscons=YES in /etc/rc.conf), you can login on other consoles that are quiet. Thanks so much Johnny & Olaf. The other consoles look promising. Does this relate to the NetBSD Guide Chap 3.9 Disk Prep process for selecting bootblocks? http://www.netbsd.org/docs/guide/en/chap-exinst.html#exinst-disk-preparation-process I have just been selecting the BIOS console, and maybe I should select one of the serial ports, or option g : Use existing bootblocks ? I think the console selection is the clue. I will play with this and try a fresh install with one of the serial ports, like com0. Clay -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" clays.sh...@sdf.org SDF Public Access UNIX System - http://sdf.org
Re: Strange behaviour on PCEngines APU2
In article <5dd59183.10...@shangtai.net>, Staffan Thomén wrote: >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? Use a powered usb hub. christos
Re: Basic vt100 console "noisy"
On Wed 20 Nov 2019 at 21:44:56 +0100, Johnny Billquist wrote: > You might want to look at the syslogd configuration then? That might be one > source of messages being printed. Furthermore, they are only printed to the first console. If you enable more (ttyE[0-3] in /etc/ttys I think, and wscons=YES in /etc/rc.conf), you can login on other consoles that are quiet. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Basic vt100 console "noisy"
On 2019-11-20 21:39, Clay Daniels wrote: I'm having real trouble with my console window if I'm not running an X window. There is constant system "chatter" about devices and such that interupts what I'm trying to do. The worst problem is when I try to use vi and it interupts me in mid-line. I realize it may be my old machine, a 2014 HP Pavilion23 All-in-one. But I have allocated the whole disk to NetBSD, and would like to get it to work. I'm going to try a re-install, but will hold off to see if anyone has any suggestions on how to "quiet down" the console "chatter". You might want to look at the syslogd configuration then? That might be one source of messages being printed. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Basic vt100 console "noisy"
I'm having real trouble with my console window if I'm not running an X window. There is constant system "chatter" about devices and such that interupts what I'm trying to do. The worst problem is when I try to use vi and it interupts me in mid-line. I realize it may be my old machine, a 2014 HP Pavilion23 All-in-one. But I have allocated the whole disk to NetBSD, and would like to get it to work. I'm going to try a re-install, but will hold off to see if anyone has any suggestions on how to "quiet down" the console "chatter". Thanks, Clay clays.sh...@sdf.org SDF Public Access UNIX System - http://sdf.org
Re: Strange behaviour on PCEngines APU2
Staffan Thomén writes: > 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. I conclude that you have found a bug (not sure where yet) and it's overwhelmingly likely this isn't about your apu2. > 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) > 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 device was working flawlessly on the soekris. Which I'm pretty sure has only USB2. usb dmesg from a net6501: usb0 at ohci0: USB revision 1.0 usb1 at ohci1: USB revision 1.0 usb2 at ohci2: USB revision 1.0 usb3 at ehci0: USB revision 2.0 usb4 at ohci3: USB revision 1.0 usb5 at ohci4: USB revision 1.0 usb6 at ohci5: USB revision 1.0 usb7 at ehci1: USB revision 2.0 whereas apu2d4 usb0 at xhci0: USB revision 3.0 usb1 at xhci0: USB revision 2.0 usb2 at ehci0: USB revision 2.0 Looking at my apu2, it seems to have xhci and ehci and no ohci, so I wonder if xhci now does USB1/2/3, and your device is USB1. 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.
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?
Re: [users] a panics are popping up
On Wed, Nov 20, 2019 at 02:06:21PM +, Luis P. Mendes wrote: > [...] > Nov 16 03:15:21 netpi /netbsd: [ 50.7997124] /usr/pkgsrc: replaying log to > disk > Nov 16 03:15:21 netpi /netbsd: [ 50.8497155] /usr/pkg: replaying log to disk > Nov 16 03:15:21 netpi /netbsd: [ 86378.4861499] panic: /usr/pkgsrc: bad dir > ino 238065 at offset 12: missing NUL in name > [&.] namlen=2 You need to run fsck -f on /usr/pkgsrc -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: [users] a panics are popping up
On 20191119 12:57:07 -0500, Bob Bernstein wrote: My NetBSD install is rebooting itself on odd occasions. This is $ uname -a NetBSD nebby.localdomain 9.0_BETA NetBSD 9.0_BETA (GENERIC) #0: Sun Aug 18 14:36:49 UTC 2019 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64 I have not done any tinkering with this install beyond cvs-up-ing my pkgsrc (using current) and then running pkg_rolling-replace. It is conceivable that these panic reboots have resulted from the last time I carried out those two steps. On the occasion of these reboots the system simply dutifully reboots back to its command prompt. This post has been composed and sent from thee system under consideration. Any thoughts would be appreciated. Sorry about the long log included; this is a snip from /var/log/messages: -- snip-- Nov 19 00:00:00 nebby syslogd[163]: restart Nov 19 00:13:15 nebby syslogd[277]: restart Nov 19 00:13:15 nebby /netbsd: [ 520189.1917046] panic: kernel diagnostic assertion "uvm_page_locked_p(pg)" failed: file "/usr/src/sys/arch/x86/x86/pmap.c", line 3511 Nov 19 00:13:15 nebby /netbsd: [ 520189.1917046] cpu1: Begin traceback... Nov 19 00:13:15 nebby /netbsd: [ 520189.1917046] vpanic() at netbsd:vpanic+0x160 Nov 19 00:13:15 nebby /netbsd: [ 520189.1917046] stge_eeprom_wait.isra.4() at netbsd:stge_eeprom_wait.isra.4 Nov 19 00:13:15 nebby /netbsd: [ 520189.1917046] pmap_remove_pte() at netbsd:pmap_remove_pte+0x3c4 Nov 19 00:13:15 nebby /netbsd: [ 520189.1917046] pmap_remove() at netbsd:pmap_remove+0x3b4 Nov 19 00:13:15 nebby /netbsd: [ 520189.2017145] uvm_unmap_remove() at netbsd:uvm_unmap_remove+0x253 Nov 19 00:13:15 nebby /netbsd: [ 520189.2017145] sys_munmap() at netbsd:sys_munmap+0x6a Nov 19 00:13:15 nebby /netbsd: [ 520189.2017145] syscall() at netbsd:syscall+0x181 Nov 19 00:13:15 nebby /netbsd: [ 520189.2017145] --- syscall (number 73) --- Nov 19 00:13:15 nebby /netbsd: [ 520189.2017145] 76d6c4578fda: Nov 19 00:13:15 nebby /netbsd: [ 520189.2017145] cpu1: End traceback... Nov 19 00:13:15 nebby /netbsd: Nov 19 00:13:15 nebby /netbsd: [ 520189.2017145] dumping to dev 0,1 (offset=2840, size=720735): Nov 19 00:13:15 nebby /netbsd: [ 520189.2017145] dump Skipping crash dump on recursive panic Nov 19 00:13:15 nebby /netbsd: [ 520190.3622040] panic: atastart: channel 0 busy, xfer not possible Nov 19 00:13:15 nebby /netbsd: [ 520190.3622040] cpu1: Begin traceback... Nov 19 00:13:15 nebby /netbsd: [ 520190.3622040] vpanic() at netbsd:vpanic+0x160 Nov 19 00:13:15 nebby /netbsd: [ 520190.3622040] snprintf() at netbsd:snprintf Nov 19 00:13:15 nebby /netbsd: [ 520190.3622040] ata_get_xfer() at netbsd:ata_get_xfer Nov 19 00:13:15 nebby /netbsd: [ 520190.3622040] wdc_ata_bio() at netbsd:wdc_ata_bio+0x7b Nov 19 00:13:15 nebby /netbsd: [ 520190.3622040] wd_dumpblocks() at netbsd:wd_dumpblocks+0x111 Nov 19 00:13:15 nebby /netbsd: [ 520190.3722084] dk_dump() at netbsd:dk_dump+0x172 Nov 19 00:13:15 nebby /netbsd: [ 520190.3722084] dump_header_flush() at netbsd:dump_header_flush+0x6d Nov 19 00:13:15 nebby /netbsd: [ 520190.3722084] dump_header_addbytes() at netbsd:dump_header_addbytes+0x40 Nov 19 00:13:15 nebby /netbsd: [ 520190.3722084] dump_header_addseg() at netbsd:dump_header_addseg+0x1e Nov 19 00:13:15 nebby /netbsd: [ 520190.3722084] dump_seg_iter() at netbsd:dump_seg_iter+0x107 Nov 19 00:13:15 nebby /netbsd: [ 520190.3722084] cpu_dump() at netbsd:cpu_dump+0x6a Nov 19 00:13:15 nebby /netbsd: [ 520190.3722084] dodumpsys() at netbsd:dodumpsys+0xfc Nov 19 00:13:15 nebby /netbsd: [ 520190.3722084] dumpsys() at netbsd:dumpsys+0x1d Nov 19 00:13:15 nebby /netbsd: [ 520190.3822126] vpanic() at netbsd:vpanic+0x169 Nov 19 00:13:15 nebby /netbsd: [ 520190.3822126] stge_eeprom_wait.isra.4() at netbsd:stge_eeprom_wait.isra.4 Nov 19 00:13:15 nebby /netbsd: [ 520190.3822126] pmap_remove_pte() at netbsd:pmap_remove_pte+0x3c4 Nov 19 00:13:15 nebby /netbsd: [ 520190.3822126] pmap_remove() at netbsd:pmap_remove+0x3b4 Nov 19 00:13:15 nebby /netbsd: [ 520190.3822126] uvm_unmap_remove() at netbsd:uvm_unmap_remove+0x253 Nov 19 00:13:15 nebby /netbsd: [ 520190.3922167] sys_munmap() at netbsd:sys_munmap+0x6a Nov 19 00:13:15 nebby /netbsd: [ 520190.3922167] syscall() at netbsd:syscall+0x181 Nov 19 00:13:15 nebby /netbsd: [ 520190.3922167] --- syscall (number 73) --- Nov 19 00:13:15 nebby /netbsd: [ 1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, Nov 19 00:13:15 nebby /netbsd: [ 1.000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, Nov 19 00:13:15 nebby /netbsd: [ 1.000] 2018, 2019 The NetBSD Foundation, Inc. All rights reserved. Nov 19 00:13:15 nebby /netbsd: [ 1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993 Nov 19 00:13:15 nebby /netbsd: [ 1.000] The Regents of the University of California. All rights reserved. Nov 19 00:13:15 nebby /netbsd: Nov 19 00:13:15 nebby /netbsd: [ 1.000]
