Anyone using a Jabra USB Headset with -current?
Hi! I just plugged a Jabra headset into my laptop, and the results were somewhat underwhelming. I have tried both connecting the headset directly to the laptop via a USB cable, and also by using the pre-paired bluetooth to USB dongle supplied with the headset. The symptoms are more or less the same (see below). Has anyone managed to use a Jabra Headset (phone + mic) successfully with -current? $ uname -mrs NetBSD 9.99.82 amd64 Excerpts from dmesg (after I plugged in the cable): [71.345366] uaudio0 at uhub1 port 2 configuration 1 interface 0 [71.345366] uaudio0: vendor 0b0e (0x0b0e) Jabra Evolve 65 (0x030c), rev 2.00/2.91, addr 2 [71.355369] uaudio0: autoconfiguration error: no usable endpoint found [71.355369] uaudio0: autoconfiguration error: audio descriptors make no sense, error=4 [71.355369] uhidev0 at uhub1 port 2 configuration 1 interface 3 [71.355369] uhidev0: vendor 0b0e (0x0b0e) Jabra Evolve 65 (0x030c), rev 2.00/2.91, addr 2, iclass 3/0 [71.365368] uhidev0: 155 report ids [71.365368] uhid0 at uhidev0 reportid 1: input=2, output=0, feature=0 [71.365368] uhid1 at uhidev0 reportid 2: input=2, output=2, feature=0 [71.365368] uhid2 at uhidev0 reportid 4: input=2, output=2, feature=1 [71.365368] uhid3 at uhidev0 reportid 5: input=63, output=63, feature=0 [71.365368] uhid4 at uhidev0 reportid 154: input=0, output=0, feature=63 [71.365368] uhid5 at uhidev0 reportid 155: input=2, output=0, feature=0 Any hints as to what might be the problem? Any suggestions as to what to do? -jarle -- "People who deal with bits should expect to get bitten." -- Jon Bentley
Side effects when taring up /dev
Hi, I observed some weird behavior when I ran tar on a filesystem with a /dev directory. I ran the equivalent of: (cd / && tar -cf - . ) | (cd /somewhere && tar -xpf - ) and got the following error messages: tar: Couldn't list extended attributes: Invalid argument tar: Couldn't list extended attributes: Invalid argument tar: Couldn't list extended attributes: Invalid argument tar: Couldn't list extended attributes: Invalid argument tar: Couldn't list extended attributes: Invalid argument tar: Couldn't list extended attributes: Invalid argument On the console, I got: [ 72536.9865017] cd0: sector size 0 [ 72537.0265040] cd0: sector size 0 [ 72633.4720213] tap0: detached and then the console would no longer accept any input. I had to hup the getty process to get it going again. This was on a Sun Enterprise 450 Ultrasparc system, with a real CD player installed, and a real serial port console. I tried something similar on a Xen/amd64 VM running NetBSD 9.99.75. A simple (cd /dev && tar -cf /dev/null ./tap) gave similar error messages from tar, and the console message: [ 454.6728584] tap0: detached It seems that tar opens the ./tap device and then tries to retrieve some acl attributes. I speculate that somehow this again causes a tap0 device to be created, and then shortly deleted again. Should tar really open a device node like this? Many devices will "do stuff" on open, and I would say it is not expected that running tar in a directory with device nodes should change the system state like that. -jarle -- There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors.
Re: BlackBox, SloppyFocus and -current
Robert Elz writes: > Date:Mon, 30 Jan 2017 19:50:37 +0100 (CET) > From: Jarle Greipsland > Message-ID: <20170130.195037.3233.ja...@uninett.no> > > | I noticed that new X11 code was imported back in August. Might > | this have something to do with my sloppyfocus problem? > > I use blackbox70 with sloppy focus, on a (not up to date, but more > recent than that) amd64 current, and don't have any problems (with > blackbox anyway.) My system is: > > NetBSD andromeda.noi.kre.to 7.99.43 NetBSD 7.99.43 (VBOX64-1.2-20161202) #21: > Sat Dec 3 00:43:51 ICT 2016 > k...@magnolia.noi.kre.to:/usr/obj/current/kernels/amd64/VBOX64 amd64 > > It certainly includes X11 more recent than last August. Ok. Thank you for the data point. -jarle
BlackBox, SloppyFocus and -current
Hi, I just upgraded a system from -current as of June 2016 to -current as of a few days ago. On this system I use blackbox70 from pkgsrc as my window manager, and the upgrade seems to have affected this program negatively. Blackbox is configured to use SloppyFocus as its focus model, but it no longer works (quite) correctly. When the pointer is moved from one window to another, the focus will leave the first window, but never "arrive" in the second window. This used to work. If I click the window bar, focus usually gets set correctly. Does anybody else see this problem? I noticed that new X11 code was imported back in August. Might this have something to do with my sloppyfocus problem? -jarle -- "The average pointer points somewhere in X." -- Henry Spencer
Re: OpenVPN causes fresh -current to crash
Tom Ivar Helbekkmo writes: [ ... ] > Oh, and it's the client that hangs; the server seems to be just fine, > and a reboot of the client makes NFS reads behave normally again. On > the server, the output file got created, but is zero bytes. The error > logged on the client when it gets stuck is this console output: [ ... ] Could this be another manifestation of PR/50432? -jarle -- "A firewall that lets NFS through is like a seatbelt that is designed to let your face reach the dashboard." -- m...@tis.com (Marcus J Ranum)
Re: wm devices don't work under current amd64
Masanobu SAITOH writes: > On 2016/11/28 17:16, Masanobu SAITOH wrote: >> Hello, Jarle. >> >> On 2016/11/27 0:45, Jarle Greipsland wrote: [ ... ] >>> Was this problem ever fixed? >> >> Perhaps no. I've added a lot of changes into if_wm.c, but I've not >> touched vlan related stuff. > > > Please test the latest -current. knakahara found a problem: [ ... ] >> cvs rdiff -u -r1.234 -r1.235 src/sys/net/if_ethersubr.c >> cvs rdiff -u -r1.93 -r1.94 src/sys/net/if_vlan.c As far as I can tell, with these changes, the problem is gone. -jarle -- "We apologize for the error in last week's paper in which we stated that Mr. Arnold Dogbody was a defective in the police force. We meant, of course, that Mr. Dogbody is a detective in the police farce." -- Correction notice in the Ely Standard, a British newspaper
Re: i915 hangs after 201612251500Z changes
Cherry G. Mathew writes: >>>>>> "Jarle" == Jarle Greipsland writes: > Jarle> Cherry G. Mathew writes: > >>>>>>> "Jun" == Jun Ebihara writes: > Jarle> [ ... ] > >> Does the following patch solve your problem ? > >> > >> -- > >> ~cherry > >> > >> --- x86_machdep.c.~1.80.~ 2017-01-02 21:20:21.682422476 +0530 > >> +++ x86_machdep.c 2017-01-09 13:20:12.018133390 +0530 > >> @@ -938,7 +938,7 @@ > >> msgbuf_p_seg[msgbuf_p_cnt++].paddr = > >> ctob(uvm_physseg_get_avail_end(x)); > >> > >> /* Now find where the new avail_end is. */ > >> - avail_end = ctob(uvm_physseg_get_avail_end(x)); > >> + avail_end = ctob(uvm_physseg_get_highest_frame()); > >> > >> if (sz == reqsz) > >> return; > Jarle> I cannot speak for Jun Ebihara, but this patch made my Lenovo > Jarle> T400s boot again. Without this patch it would just reset early > Jarle> in the boot process, return to the BIOS, and try again. > > There was still an error in the above patch - I checked in the complete > change on -current. > > Could you test it and let us know how it goes please ? I tried a new -current kernel with x86_machdep.c version 1.81, and it booted just fine. Even better than last time -- now also dmesg could get hold of msgbuf and print out the boot messages. Excellent work! -jarle
Incorrect link status for wm0 network interface?
Hi, I have just booted a -current i386 GENERIC kernel on my Lenovo T400s laptop (userland is of 7.99.32 vintage). There seems to be something strange going on with regards to the carrier status for the built in wm0 network interface. When left unconfigured, it reports 'active' as its status. As soon as I bring the interface up with ifconfig, the status changes to 'no carrier'. However, the interface acquires an IPv6 address through SLAAC, so something is working. But the 'dhcpcd -6 --nodhcp6 wm0' command that would normally solicit a default route from the network hangs waiting for carrier on the interface. If I enter a static default route, things behave as normal. # ifconfig wm0 wm0: flags=0x8843 mtu 1500 capabilities=7ff80 capabilities=7ff80 capabilities=7ff80 enabled=0 ec_capabilities=7 ec_enabled=0 address: 00:11:22:33:44:55 media: Ethernet autoselect (none) status: no carrier inet6 fe80::0211:22ff:fe33:4455%wm0 prefixlen 64 detached scopeid 0x2 inet6 ::0211:22ff:fe33:4455 prefixlen 64 autoconf (Unfortunately, I cannot get a dmesg dump from the current system. dmesg complains 'dmesg: can't get msgbuf: Device not configured'.) The wm0 part of the dmesg from the 7.99.32 incarnation of the systems shows wm0 at pci0 dev 25 function 0: 82801I mobile (AMT) LAN Controller (rev. 0x03) wm0: interrupting at msi0 vec 0 wm0: PCI-Express bus wm0: 2048 words FLASH wm0: Ethernet address 00:11:22:33:44:55 makphy0 at wm0 phy 2: Marvell 88E1149 Gigabit PHY, rev. 1 makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto Any guesses as to what might be wrong? -jarle
Re: i915 hangs after 201612251500Z changes
Cherry G. Mathew writes: >> "Jun" == Jun Ebihara writes: [ ... ] > Does the following patch solve your problem ? > > -- > ~cherry > > --- x86_machdep.c.~1.80.~ 2017-01-02 21:20:21.682422476 +0530 > +++ x86_machdep.c 2017-01-09 13:20:12.018133390 +0530 > @@ -938,7 +938,7 @@ > msgbuf_p_seg[msgbuf_p_cnt++].paddr = > ctob(uvm_physseg_get_avail_end(x)); > > /* Now find where the new avail_end is. */ > - avail_end = ctob(uvm_physseg_get_avail_end(x)); > + avail_end = ctob(uvm_physseg_get_highest_frame()); > > if (sz == reqsz) > return; I cannot speak for Jun Ebihara, but this patch made my Lenovo T400s boot again. Without this patch it would just reset early in the boot process, return to the BIOS, and try again. -jarle
Re: wm devices don't work under current amd64
Masanobu SAITOH writes: > Hi. > > On 2016/03/07 21:12, Tobias Nygren wrote: >> On Mon, 7 Mar 2016 20:57:02 +0900 >> Masanobu SAITOH wrote: >> >>> One of the possibility is that the multicast filter table and broadcast >>> bit in a register aren't set correctly on ICH9. >> >> I'm not sure if this is relevant to the discussion, but I have a wm(4) >> device (8086:1502) on -current that does not work after boot. It comes >> to life only after running "tcpdump -n -i wm0" once. I am using vlan(4), >> but haven't checked if that makes any difference. I usually run the >> tcpdump command then forget about it until the next reboot. > > It must be a bug! Could you tell me how you set up network interface include > vlan? (e.g. part of /etc/rc.conf, /etc/ifconfig.xxx, and the output of > "ifconfig -a) Was this problem ever fixed? I am experiencing very similar problems with -current as of yesterday. My system is a SuperMicro X7SPA-HF used as a router with a non-vlan interface towards my ISP (wm1), and a vlan'ed interface for a number of internal networks (wm0). An old kernel 7.99.21 from October last year works fine: [ ... ] ppb0 at pci0 dev 28 function 0: vendor 8086 product 2940 (rev. 0x02) ppb0: PCI Express capability version 1 x4 @ 2. 5GT/s pci1 at ppb0 bus 1 pci1: i/o space, memory space enabled, rd/line, wr/inv ok ppb1 at pci0 dev 28 function 4: vendor 8086 product 2948 (rev. 0x02) ppb1: PCI Express capability version 1 x1 @ 2. 5GT/s pci2 at ppb1 bus 2 pci2: i/o space, memory space enabled, rd/line, wr/inv ok wm0 at pci2 dev 0 function 0: Intel i82574L (rev. 0x00) wm0: for TX interrupting at msix0 vec 0 affinity to 0 wm0: for RX interrupting at msix0 vec 1 affinity to 1 wm0: for RX interrupting at msix0 vec 2 affinity to 2 wm0: for LINK interrupting at msix0 vec 3 wm0: PCI-Express bus wm0: 2048 words (8 address bits) SPI EEPROM, version 1.9.0, Image Unique ID wm0: Ethernet address 00:xx:xx:xx:xx:xx makphy0 at wm0 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1 makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ppb2 at pci0 dev 28 function 5: vendor 8086 product 294a (rev. 0x02) ppb2: PCI Express capability version 1 x1 @ 2.5GT/s pci3 at ppb2 bus 3 pci3: i/o space, memory space enabled, rd/line, wr/inv ok wm1 at pci3 dev 0 function 0: Intel i82574L (rev. 0x00) wm1: for TX interrupting at msix1 vec 0 affinity to 0 wm1: for RX interrupting at msix1 vec 1 affinity to 1 wm1: for RX interrupting at msix1 vec 2 affinity to 2 wm1: for LINK interrupting at msix1 vec 3 wm1: PCI-Express bus wm1: 512 words (8 address bits) SPI EEPROM, version 1.9.0, Image Unique ID wm1: Ethernet address 00:yy:yy:yy:yy:yy makphy1 at wm1 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1 makphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto With a current kernel from yesterday (7.99.42) however, the vlan interfaces on wm0 do not work. The dmesg also looks slightly different (the interrupt routing seems different): ppb0 at pci0 dev 28 function 0: vendor 8086 product 2940 (rev. 0x02) ppb0: PCI Express capability version 1 x4 @ 2. 5GT/s pci1 at ppb0 bus 1 pci1: i/o space, memory space enabled, rd/line, wr/inv ok ppb1 at pci0 dev 28 function 4: vendor 8086 product 2948 (rev. 0x02) ppb1: PCI Express capability version 1 x1 @ 2. 5GT/s pci2 at ppb1 bus 2 pci2: i/o space, memory space enabled, rd/line, wr/inv ok wm0 at pci2 dev 0 function 0: Intel i82574L (rev. 0x00) wm0: for TX and RX interrupting at msix0 vec 0 affinity to 1 wm0: for TX and RX interrupting at msix0 vec 1 affinity to 2 wm0: for LINK interrupting at msix0 vec 2 wm0: PCI-Express bus wm0: 2048 words (8 address bits) SPI EEPROM, version 1.9.0, Image Unique ID wm0: Ethernet address 00:xx:xx:xx:xx:xx makphy0 at wm0 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1 makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ppb2 at pci0 dev 28 function 5: vendor 8086 product 294a (rev. 0x02) ppb2: PCI Express capability version 1 x1 @ 2.5GT/s pci3 at ppb2 bus 3 pci3: i/o space, memory space enabled, rd/line, wr/inv ok wm1 at pci3 dev 0 function 0: Intel i82574L (rev. 0x00) wm1: for TX and RX interrupting at msix1 vec 0 affinity to 1 wm1: for TX and RX interrupting at msix1 vec 1 affinity to 2 wm1: for LINK interrupting at msix1 vec 2 wm1: PCI-Express bus wm1: 512 words (8 address bits) SPI EEPROM, version 1.9.0, Image Unique ID wm1: Ethernet address 00:yy:yy:yy:yy:yy makphy1 at wm1 phy 1: Marvell 88E1149 Gigabit PHY, rev. 1 makphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto With this kernel, I have to do a tcpdump of one or two packets on wm0 until it starts to work, as suggest by tnn@ in his message from March. Any idea what might be the problem? -jarle
Re: Mangled file system directory panic
chris...@astron.com (Christos Zoulas) writes: > In article <20160811.153708.78150616.ja...@uninett.no>, > Jarle Greipsland wrote: >>> The panic messages reported by crash is something like: >>> System panicked: /mnt: bad dir ino 42369 at offset 560: NUL in name [] >>i=0, namlen=4 [ ... ] >>I have since managed to pin-point where things started to go >>wrong -- CVS commit-wise. A -current kernel from CVS with tag >>'2016.04.03.03.00.00' works just fine, while a kernel with tag >>'2016.04.03.07.00.00' panics. The only significant commit in >>that interval is a change of compiler for the i386 port to GCC >>5.3 (http://mail-index.netbsd.org/source-changes/2016/04/03/msg073782.html). >> >>Are there known bugs in our compiler for (plain) i486 systems? >> > > Please try compiling ufs_lookup.c with -O0... I have now tried a kernel with the following lines in the config file: makeoptions CPUFLAGS="-march=i486 -fno-tree-vrp" makeoptions "CPUFLAGS.ufs_lookup.c"+="-O0" makeoptions DEBUG="-g" # compile full symbol table It still panics. -jarle -- "I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, "We left all that stuff out. If there's an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'" Tom van Vleck and Dennis Ritchie about Multics <-> UNIX relationship
Re: Mangled file system directory panic
co...@sdf.org writes: > On Thu, Aug 11, 2016 at 03:37:08PM +0200, Jarle Greipsland wrote: >> [ Followups to port-i386, please ] >> I wrote[1]: >> > I have a system where I can almost deterministally provoke a >> > kernel panic by doing a 'tar -zxpf comp.tgz'. >> > >> > The panic messages reported by crash is something like: >> > System panicked: /mnt: bad dir ino 42369 at offset 560: NUL in name [] >> > i=0, namlen=4 [ ... ] >> I have since managed to pin-point where things started to go >> wrong -- CVS commit-wise. A -current kernel from CVS with tag >> '2016.04.03.03.00.00' works just fine, while a kernel with tag >> '2016.04.03.07.00.00' panics. The only significant commit in >> that interval is a change of compiler for the i386 port to GCC >> 5.3 (http://mail-index.netbsd.org/source-changes/2016/04/03/msg073782.html). >> >> Are there known bugs in our compiler for (plain) i486 systems? [ ... ] > Is that PR/51094? It certainly looks closely related, symptom-wise. I have tried the suggested workaround, but the kernel still panics. -jarle
Re: Mangled file system directory panic
[ Followups to port-i386, please ] I wrote[1]: > I have a system where I can almost deterministally provoke a > kernel panic by doing a 'tar -zxpf comp.tgz'. > > The panic messages reported by crash is something like: > System panicked: /mnt: bad dir ino 42369 at offset 560: NUL in name [] i=0, > namlen=4 > [ ... ] > NetBSD 7.99.34 (DARLING) #1: Sat Jul 30 20:01:15 CEST 2016 > ja...@singsaker.uninett.no:/usr/obj/sys/arch/i386/compile/DARLING > total memory = 127 MB > avail memory = 120 MB > timecounter: Timecounters tick every 10.000 msec > timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 > Generic PC > mainbus0 (root) > cpu0 at mainbus0 > cpu0: Intel 486-class > eisa0 at mainbus0 > isa0 at mainbus0 [ ... ] I have since managed to pin-point where things started to go wrong -- CVS commit-wise. A -current kernel from CVS with tag '2016.04.03.03.00.00' works just fine, while a kernel with tag '2016.04.03.07.00.00' panics. The only significant commit in that interval is a change of compiler for the i386 port to GCC 5.3 (http://mail-index.netbsd.org/source-changes/2016/04/03/msg073782.html). Are there known bugs in our compiler for (plain) i486 systems? -jarle [1]: http://mail-index.netbsd.org/current-users/2016/07/30/msg029876.html -- You are in a dark room with a compiler, emacs, an internet connection, and a thermos of coffee. Your move ? -- David A. Honig
Mangled file system directory panic
Hi, I have a system where I can almost deterministally provoke a kernel panic by doing a 'tar -zxpf comp.tgz'. The panic messages reported by crash is something like: System panicked: /mnt: bad dir ino 42369 at offset 560: NUL in name [] i=0, namlen=4 The directory mangling is quite severe, so that fsck does not always manage to fix the problems. I have had to newfs the partition a number of times, including zeroing it out completely. I have since also managed to duplicate the problem on a file backed vnd, which makes the recovery somewhat smoother. The backtrace below is from after doing: # vndconfig vnd0 /home/testdisk.dsk # newfs -O 2 /dev/rvnd0a # mount /dev/vnd0a /mnt # cd /mnt # tar -zxpf /usr/rel/i386/binary/sets/comp.tgz The backtrace from the kernel core dump is: Backtrace from time of crash is available. crash> bt _KERNEL_OPT_NPNPBIOS(0,104,c0112c44,104,c040ef6c,c7a9cbd4,c03001db,104,0,c1128ca c) at 0 __kernel_end(104,0,c1128cac,0,c7cb8230,c7a9cbe4,c0300250,c040ef6c,c7a9cbf0,c7a9c ca4) at c7a9cbf0 vpanic(c040ef6c,c7a9cbf0,c7a9cca4,c0278b11,c040ef6c,c0e13100,a581,0,230,c04d18e0 ) at vpanic+0x11b snprintf(c040ef6c,c0e13100,a581,0,230,c04d18e0,200,0,1ff,0) at snprintf ufs_lookup(c7a9ccb4,c1126b84,c03e9000,c1126ae0,c7a9ccf8,c7a9ced0,c7a9ccf8,c1126a e0,c7a9cd08,c03432c6) at ufs_lookup+0x4e1 VOP_LOOKUP(c1126ae0,c7a9ccf8,c7a9ced0,c0368816,c7a9cdc0,c7a9cea8,c7a9cd08,c7a9cd 68,c7a9ced0,0) at VOP_LOOKUP+0x31 lookup_once(c7a9cd6c,c02f9c5f,c0908408,c0f55f20,c7a9cd34,c02f9c5f,c0908408,0,0,c 7a9cd50) at lookup_once+0x166 namei_tryemulroot(0,c10fad30,c7a9cea8,c7a9ced0,20,0,0,0,c7a9cea8,c7a9ce84) at na mei_tryemulroot+0x4c7 namei(c7a9cea8,,c10e3780,c10fad3d,c08fad80,c5b5d211,297,c02f8d00,0,c10fa d28) at namei+0x22 vn_open(c7a9cea8,a03,180,0,c0bcd004,c107d500,8,0,c10fad30,c0b93800) at vn_open+0 x83 do_open(c0f55d40,0,c10fad30,a02,180,c7a9cf3c,0,c10fad30,c0f55d40,c7a9cfa8) at do _open+0xb0 do_sys_openat(a02,180,c7a9cf3c,c7a9cf60,c7a9cf9c,c012fa7e,c0f55d40,c7a9cf68,c7a9 cf60,c0496264) at do_sys_openat+0x58 sys_open(c0f55d40,c7a9cf68,c7a9cf60,c0496264,c7a9cf68,5,0,0,bb9010e0,a02) at sys _open+0x22 syscall() at syscall+0x7e --- syscall (number 5) --- bba7b747: The dmesg: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016 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 7.99.34 (DARLING) #1: Sat Jul 30 20:01:15 CEST 2016 ja...@singsaker.uninett.no:/usr/obj/sys/arch/i386/compile/DARLING total memory = 127 MB avail memory = 120 MB timecounter: Timecounters tick every 10.000 msec timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 Generic PC mainbus0 (root) cpu0 at mainbus0 cpu0: Intel 486-class eisa0 at mainbus0 isa0 at mainbus0 lpt0 at isa0 port 0x378-0x37b irq 7 aic0 at isa0 port 0x340-0x35f irq 11 scsibus0 at aic0: 8 targets, 8 luns per target com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo pckbc0 at isa0 port 0x60-0x64 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 attimer0 at isa0 port 0x40-0x43 wdc0 at isa0 port 0x1f0-0x1f7 irq 14 atabus0 at wdc0 channel 0 we0 at isa0 port 0x280-0x29f iomem 0xd-0xd3fff irq 9 we0: WD8013EBT Ethernet (16-bit) we0: Ethernet address 00:00:c0:32:63:1c vga0 at isa0 port 0x3b0-0x3df iomem 0xa-0xb wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskbd0 wsmux1: connecting to wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 sysbeep0 at pcppi0 fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2 attimer0: attached to pcppi0 timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 scsibus0: waiting 2 seconds for devices to settle... fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec IPsec: Initialized Security Association Processing. wd0 at atabus0 drive 0 wd0: wd0: drive supports 16-sector PIO transfers, LBA addressing wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) boot device: wd0 root on wd0a dumps on wd0b root file system type: ffs kern.module.path=/stand/i386/7.99.34/modules fdcresult: timeout (st0 0x20 cyl 0) fd0: timeout<3>fdcresult: timeout (st0 0x20 cyl 0) fd0: timeout<3>fdcresult: timeout (st0 0x20 cyl 0) fd0: timeout<3>fdcresult: timeout (st0 0x20 cyl 0) fd0: timeout<3>fdcresult: timeout (st0 0x20 cyl 0) fd0: timeout<3>fdcresult: timeout (st0 0x20 cyl 0) fd0: timeoutfd0a: hard error reading fsbn 0 of 0-2 (st0 0x20 st1 0x0 st2 0x0 cyl 0 head 0 sec 0) wsdisplay0: screen 1 added (80x25, vt100 emulation) wsdisplay0: screen 2 added (80x25, vt100 emulation) wsdisplay0: screen 3 added (80x2
Re: blacklistd is now available for current (comments?)
chris...@zoulas.com (Christos Zoulas) writes: > > You can get it from http://www.netbsd.org/~christos/blacklistd.tar.gz > > Appended is the README file. I wrote this over the weekend, it seems to > work :-) Please let me know what you think? Is it useful? Should I commit > it to the base system? Do you have any suggestions to improve it? [ ... ] > The configuration file contains entries of the form: > > # Blacklist rule > # Porttypeprotocolowner nfail disable > ssh stream tcp * 6 60m > ssh stream tcp6* 6 60m What about hosts with multiple addresses and multiple instances of the same daemon? I.e. an ssh daemon for ordinary login on IP address a.b.c.d, and an anoncvs ssh daemon on a.b.c.e, and you want different policies for how to blacklist remote clients? Maybe do something like postfix, and allow a.b.c.d:ssh as a service specifier instead of just a port number/name? -jarle -- "Crime in multi-storey car parks. That is wrong on so many different levels." -- Tim Vine
Re: drmkms solid hang on T200 laptop booting GENERIC amd64
Dave Tyson writes: > I have been testing current on a Lenovo T200 (type 2504) on and off for a > while. I think the last successful boot of current was GENERIC from 29th > October before the KMS code was add the the GENERIC config. IIRC the DRMKMS > kernel from that base would hang. > > With GENERIC (AMD64) CVS'ed and compiled from a couple of days ago the system > boots and then hangs in the KMS code. kernel messages just before hang: [ ... ] > DRM error in init_ring_common: render ring initialization failed ctl 0001f001 > head 0543b084 tail start 3000 > warning: /usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_pm.c:5734: > !power_domains->domain_use_count[domain] > I see the exact same thing on a Lenovo T400s with NetBSD/i386 current. I have also found that if I boot an older kernel with drmkms enabled first (single-user and immediate reboot-command is sufficient), then the current kernel boots all the way to multi-user, and X11 works. -jarle
Re: 5 GHz band support for Intel WiFi chips?
Anders Magnusson writes: >> my impression from various web sites is that the Intel WiFi >> device in my Lenovo T400s laptop has support for the 5 GHz band >> channels. However, it seems to never associate with any access >> points using such channels. It always ends up using some of the >> 2.4 GHz channels instead, or not being able to associate with any >> access point at all. >> > Just FYI: There are versions of the T400 that do not have 5GHz. > You need to check the exact chip ID. According to the NetBSD pcidevs file iwn0 at pci2 dev 0 function 0: vendor 0x8086 product 0x4236 (rev. 0x00) translates to product INTEL WIFI_LINK_5300_2 0x4236 WiFi Link 5300 and the product brief[*] on Intel's web pages states that this is part of a series that supports the dual bands 2.4 GHz / 5 GHz. Is there an even more detailed chip ID I should look for? Also, ifconfig -m iwn0 lists a number of 'mode 11a' media types. I did also compile a kernel with IWN_DEBUG defined and set the iwn_debug variable to 2 and got the following output: iwn0 at pci2 dev 0 function 0: vendor 0x8086 product 0x4236 (rev. 0x00) iwn0: interrupting at ioapic0 pin 17 EEPROM found SKU capabilities=0x00f0 radio config=0x7708 adding chan 1 flags=0x6f maxpwr=15 adding chan 2 flags=0x6f maxpwr=15 adding chan 3 flags=0x6f maxpwr=15 adding chan 4 flags=0x6f maxpwr=15 adding chan 5 flags=0x6f maxpwr=15 adding chan 6 flags=0x6f maxpwr=15 adding chan 7 flags=0x6f maxpwr=15 adding chan 8 flags=0x6f maxpwr=15 adding chan 9 flags=0x6f maxpwr=15 adding chan 10 flags=0x6f maxpwr=15 adding chan 11 flags=0x6f maxpwr=15 adding chan 12 flags=0x61 maxpwr=15 adding chan 13 flags=0x61 maxpwr=15 adding chan 36 flags=0xe1 maxpwr=15 adding chan 40 flags=0xe1 maxpwr=15 adding chan 44 flags=0xe1 maxpwr=15 adding chan 48 flags=0xe1 maxpwr=15 adding chan 52 flags=0x31 maxpwr=15 adding chan 56 flags=0x31 maxpwr=15 adding chan 60 flags=0x31 maxpwr=15 adding chan 64 flags=0x31 maxpwr=15 adding chan 100 flags=0x31 maxpwr=15 adding chan 104 flags=0x31 maxpwr=15 adding chan 108 flags=0x31 maxpwr=15 adding chan 112 flags=0x31 maxpwr=15 adding chan 116 flags=0x31 maxpwr=15 adding chan 120 flags=0x31 maxpwr=15 adding chan 124 flags=0x31 maxpwr=15 adding chan 128 flags=0x31 maxpwr=15 adding chan 132 flags=0x31 maxpwr=15 adding chan 136 flags=0x31 maxpwr=15 adding chan 140 flags=0x31 maxpwr=15 adding chan 149 flags=0xa1 maxpwr=15 adding chan 153 flags=0xa1 maxpwr=15 adding chan 157 flags=0xa1 maxpwr=15 adding chan 161 flags=0xa1 maxpwr=15 adding chan 165 flags=0xa1 maxpwr=15 calib version=4 pa type=0 voltage=0 crystal calibration 0x00770077 iwn0: MIMO 3T3R, MoW, address xx:xx:xx:xx:xx:xx iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps I believe the channels from 36 and upwards are part of the 11a set, and should be found in the 5 GHz band. Now, it is of course entirely possible that this is just something that the chip itself supports, and that the device that the chip is part of is not wired to support these channels. How could I get to know that? Furthermore, if I do 'ifconfig iwn0 mode 11a up', and then run 'wlanctl -a | grep -B 1 freq' from time to time, I get: ess <> chan 44 freq 5220MHz flags 0340 -- ess <> chan 1 freq 2412MHz flags 04e0 -- ess <> chan 120 freq 5600MHz flags 0340 -- ess <> chan 13 freq 2472MHz flags 06e0 -- ess <> chan 116 freq 5580MHz flags 0340 -- ess <> chan 157 freq 5785MHz flags 0340 -- ess <> chan 36 freq 5180MHz flags 0340 -- ess <> chan 100 freq 5500MHz flags 0340 -- ess <> chan 132 freq 5660MHz flags 0340 -- ess <> chan 165 freq 5825MHz flags 0340 -- ess <> chan 40 freq 5200MHz flags 0340 -- ess <> chan 100 freq 5500MHz flags 0340 -- ess <> chan 128 freq 5640MHz flags 0340 -- ess <> chan 161 freq 5805MHz flags 0340 -- ess <> chan 13 freq 2472MHz flags 06e0 so to me it seems that the driver is cycling through the 11a channel set trying (unsuccessfully) to find a network to which to associate. Any suggestions to what more I might try? Or can someone offer authoritative insights whether this can be made to work at all, with our current 802.11 framework and the iwn driver? -jarle [*]http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ultimate-n-wifi-link-5300-brief.pdf -- "Whiteboards are remarkable."
5 GHz band support for Intel WiFi chips?
Hi, my impression from various web sites is that the Intel WiFi device in my Lenovo T400s laptop has support for the 5 GHz band channels. However, it seems to never associate with any access points using such channels. It always ends up using some of the 2.4 GHz channels instead, or not being able to associate with any access point at all. It identifies itself as: iwn0 at pci2 dev 0 function 0: vendor 0x8086 product 0x4236 (rev. 0x00) iwn0: interrupting at ioapic0 pin 17 iwn0: MIMO 3T3R, MoW, address xx:xx:xx:xx:xx:xx iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps Does the NetBSD 80211 framework have support for the 5 GHz channels? Does our driver for this Intel series of chips support the 5 GHz channels? Do I need to configure the device in any particular way? Or have I misunderstood something, and the chip in question does not support the 5 GHz band channels after all? Is there anybody, with a similar device, that has successfully used the 5 GHz band channels? -jarle -- There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors.
NetBSD/i386 6.1_STABLE instability?
Hi, I have recently upgraded a i386-system from a 6.1_STABLE version from early January to a 6.1_STABLE version freshly built today. I find that the new version is not quite stable. If I put some pkgsrc build load on the system, the kernel (GENERIC) will eventually panic. If I boot the old kernel the system is again stable, and I can build a bunch of packages from pkgsrc without incident. The panic messages uvm_fault(0xc2bf1290, 0x44000, 2) -> 0xe fatal page fault in supervisor mode trap type 6 code 2 eip c08771ff cs 8 eflags 10286 cr2 44014 ilevel 8 panic: trap cpu1: Begin traceback... printf_nolog(c0bb124f,e1af57ec,e1af57ec,c08771ff,8,10286,44014,8,1,e1af57de) at netbsd:printf_nolog trap_tss() at netbsd:trap_tss --- trap via task gate --- 9: cpu1: End traceback... The traceback from a GENERIC kernel with debug symbols: (gdb) bt #0 0xc05a43d8 in maybe_dump (howto=260) at /usr/src/sys/arch/i386/i386/machdep.c:878 #1 cpu_reboot (howto=260, bootstr=0x0) at /usr/src/sys/arch/i386/i386/machdep.c:899 #2 0xc079430a in vpanic (fmt=0xc0bb124f "trap", ap=0xe1af575c "\354W¯\341\354W¯\341\377qÀ\b") at /usr/src/sys/kern/subr_prf.c:308 #3 0xc07943af in panic (fmt=0xc0bb124f "trap") at /usr/src/sys/kern/subr_prf.c:205 #4 0xc07e2c4c in trap (frame=0xe1af57ec) at /usr/src/sys/arch/i386/i386/trap.c:396 #5 0xc010cf48 in ?? () #6 0xc0877e21 in uvm_pagealloc_strat (obj=0xc2aa721c, off=36864, anon=0x0, flags=, strat=0, free_list=0) at /usr/src/sys/uvm/uvm_page.c:1274 #7 0xc087dbc9 in uvn_findpage (uobj=0xc2aa721c, offset=, pgp=0xe1af59d4, flags=0) at /usr/src/sys/uvm/uvm_vnode.c:254 #8 0xc087dcdd in uvn_findpages (uobj=0xc2aa721c, offset=, npagesp=0xe1af5a10, pgs=0xe1af59d0, flags=0) at /usr/src/sys/uvm/uvm_vnode.c:216 #9 0xc0332fa0 in genfs_getpages (v=0xe1af5a34) at /usr/src/sys/miscfs/genfs/genfs_io.c:335 #10 0xc08b05ef in VOP_GETPAGES (vp=0xc2aa721c, offset=32768, m=0xe1af5a90, count=0xe1af5ad4, centeridx=0, access_type=3, advice=0, flags=7682) at /usr/src/sys/kern/vnode_if.c:1394 #11 0xc086b004 in ubc_alloc (uobj=0xc2aa721c, offset=32768, lenp=0xe1af5b18, advice=0, flags=6) at /usr/src/sys/uvm/uvm_bio.c:573 #12 0xc086b5a0 in ubc_uiomove (uobj=0xc2aa721c, uio=0xe1af5c70, todo=16384, advice=0, flags=6) at /usr/src/sys/uvm/uvm_bio.c:726 #13 0xc030da45 in ffs_write (v=0xe1af5c0c) at /usr/src/sys/ufs/ufs/ufs_readwrite.c:393 #14 0xc08af8ac in VOP_WRITE (vp=0xc2aa721c, uio=0xe1af5c70, ioflag=16, cred=0xc5ba1d80) at /usr/src/sys/kern/vnode_if.c:430 #15 0xc0894393 in vn_write (fp=0xc2c44840, offset=0xc2c44840, uio=0xe1af5c70, cred=0xc5ba1d80, flags=1) at /usr/src/sys/kern/vfs_vnops.c:567 #16 0xc07aa262 in dofilewrite (fd=4, fp=0xc2c44840, buf=0xbb97b000, nbyte=16384, offset=0xc2c44840, flags=1, retval=0xe1af5d28) at /usr/src/sys/kern/sys_generic.c:355 #17 0xc07aa397 in sys_write (l=0xc5db6aa0, uap=0xe1af5d00, retval=0xe1af5d28) at /usr/src/sys/kern/sys_generic.c:323 #18 0xc07b59ba in sy_call (rval=0xe1af5d28, uap=0xe1af5d00, l=0xc5db6aa0, sy=0xc0c36bd0) at /usr/src/sys/sys/syscallvar.h:61 #19 syscall (frame=0xe1af5d48) at /usr/src/sys/arch/x86/x86/syscall.c:179 #20 0xc010056d in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Does this point out a bug to someone? -jarle
Re: Problems with IPMI and wm? sharing a physical Ethernet port
Masanobu SAITOH writes: >> >> Two days ago, I fixed some bugs about BMC (if_wm.c rev. 1.260). >> >> Today I tested with Supermicro X7SPA-HF. This is the same >> product that the first mail reported. I connected only one >> Ethernet port "LAN1" to a switch. This port is shared with BMC. >> The LAN1 port (wm0) works fine. Great! > Could anyone test other motherboard which had a problem with BMC? Unfortunately, the system that caused me to report these problems is now in production, and I cannot easily test the changes. Prior to putting it into production I discovered that if I configured the BMC to use a dedicated VLAN, configured the switch port as a "trunked port", and then used a different VLAN id for wm0 in NetBSD, things would actually work. The IPMI functionality would then still be available even after NetBSD had started up. I probably should have reported this to the community. Sorry about that. I may be able to test your fixes later this year, but it would be better if someone else, with similar equipment, could test this before that. -jarle -- "[P]ostulating that the VAX architecture would be missing any instruction `XYZ' is like playing Russian roulette with five bullets instead of one." -- Dave McGuire on port-vax
Re: IPSEC does not bring ip_ecn.o into the kernel
Greg Troxel writes: > Jarle Greipsland writes: [ ... ] >> Maybe sys/conf/files should be updated so that netinet/ip_ecn.c >> is marked as a dependency of ipsec directly (since kame_ipsec >> and fast_ipsec seem to be deprecated)? > > I just commited a change to sys/conf/files that drops the kame_ipsec > specifier on a few files. Much better. Thank you! -jarle -- For a good prime, call: 391581 * 2^216193 - 1
IPSEC does not bring ip_ecn.o into the kernel
Hi, I tried building a -current kernel with IPSEC enabled, but with both the gif and stf pseudo-devices disabled. The build process fails when trying to link the new kernel: xform_ipip.o: In function `ipip_output': xform_ipip.c:(.text+0x419): undefined reference to `ip_ecn_ingress' xform_ipip.c:(.text+0x617): undefined reference to `ip_ecn_ingress' xform_ipip.o: In function `_ipip_input.clone.0': xform_ipip.c:(.text+0xbd4): undefined reference to `ip_ecn_egress' xform_ipip.c:(.text+0xd13): undefined reference to `ip_ecn_egress' Maybe sys/conf/files should be updated so that netinet/ip_ecn.c is marked as a dependency of ipsec directly (since kame_ipsec and fast_ipsec seem to be deprecated)? -jarle -- "... except from the fact that it doesn't work, what do you think about the program?"
