Re: CVS commit: src/share/man/man4
Sorry about that! Best regards, Radoslaw > On 27 Jul 2018, at 18:12, Andreas Gustafsson wrote: > > Module Name: src > Committed By: gson > Date: Fri Jul 27 16:12:40 UTC 2018 > > Modified Files: > src/share/man/man4: Makefile > > Log Message: > Add missing backslash to unbreak the build > > > To generate a diff of this commit: > cvs rdiff -u -r1.659 -r1.660 src/share/man/man4/Makefile > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > Modified files: > > Index: src/share/man/man4/Makefile > diff -u src/share/man/man4/Makefile:1.659 src/share/man/man4/Makefile:1.660 > --- src/share/man/man4/Makefile:1.659 Fri Jul 27 12:02:26 2018 > +++ src/share/man/man4/Makefile Fri Jul 27 16:12:40 2018 > @@ -1,4 +1,4 @@ > -#$NetBSD: Makefile,v 1.659 2018/07/27 12:02:26 rkujawa Exp $ > +#$NetBSD: Makefile,v 1.660 2018/07/27 16:12:40 gson Exp $ > # @(#)Makefile8.1 (Berkeley) 6/18/93 > > MAN= aac.4 ac97.4 acardide.4 aceride.4 acphy.4 \ > @@ -61,7 +61,7 @@ MAN=aac.4 ac97.4 acardide.4 aceride.4 a > sm.4 smsh.4 sn.4 sony.4 spc.4 speaker.4 spif.4 sqphy.4 ss.4 \ > st.4 ste.4 stge.4 sti.4 stpcide.4 sv.4 strip.4 \ > svwsata.4 swsensor.4 swwdog.4 sysmon.4 \ > - tap.4 tc.4 tcds.4 tcp.4 tcu.4 tdvfb.4 tea5767radio.4 termios.4 tfb.4 > + tap.4 tc.4 tcds.4 tcp.4 tcu.4 tdvfb.4 tea5767radio.4 termios.4 tfb.4 \ > thinkpad.4 ti.4 tl.4 tlp.4 tlphy.4 tpm.4 tprof.4 tr.4 tra.4 \ > trm.4 tsllux.4 tty.4 tun.4 tqphy.4 twa.4 twe.4 txp.4 \ > uark.4 ubsec.4 udp.4 uep.4 ug.4 uha.4 uk.4 ukphy.4 unix.4 userconf.4 \ >
Re: CVS commit: src/share/man/man4/man4.macppc
Hi. > +.An Tsubai Masanari Aq Mt tsu...@netbsd.org Tsubai is inactive, according to status file his account is suspended. Will anyone be able to reach him via this address? If not, then I am not sure if retroactively adding his address makes sense. Best regards, Radoslaw signature.asc Description: Message signed with OpenPGP
Re: CVS commit: src
Hi Frank. > On 04 Nov 2015, at 18:06, Frank Wille wrote: > > Module Name: src > Committed By: phx > Date: Wed Nov 4 17:06:23 UTC 2015 > > Modified Files: > src/distrib/sets/lists/xdebug: md.amiga > src/distrib/sets/lists/xserver: md.amiga > src/external/mit/xorg/server/drivers: Makefile > src/external/mit/xorg/server/xorg-server/hw/xfree86/xorgos: Makefile > src/share/mk: bsd.own.mk > > Log Message: > Build a wsfb Xorg server for amiga. Does this result in a working X11 on NetBSD/amiga for cards which support wsdisplay? Best regards, Radoslaw signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CVS commit: src/sys/arch/amiga/include
Hi. > On 1 Jun 2015, at 19:16, Frank Wille wrote: > > Module Name: src > Committed By: phx > Date: Mon Jun 1 17:16:57 UTC 2015 > > Modified Files: > src/sys/arch/amiga/include: vmparam.h > > Log Message: > Remove unused KUSER_AREA, SYSPTSIZE, USRPTSIZE. > Bump MAXTSIZ and MAXDSIZ to the same values atari is using. > This makes gcc 4.8 (/usr/libexec/cc1) load and execute. Shall we pull this to NetBSD 7? It also includes gcc 4.8, so has the same exact problem. -- Best regards, Radoslaw Kujawa
Re: CVS commit: src/sys/arch/evbarm/conf
Hello! On 30 Sep 2013, at 3:36 PM, KIYOHARA Takashi wrote: > +# On-chip Gigabit Ethernet Controller Interface > +mvgbec* at mvsoc? offset ? > +mvgbe* at mvgbec? port ? irq ? > +makphy* at mii? phy ? Does that really work on your AX3 board? If so, I've got to check it on mine too. From data sheet it seems that ethernet controller in Armada XP is totally different from whatever was present in previous chips. But I heard it has an undocumented backwards compatibility mode (which may not be present in future chip revision). -- Best regards, Radoslaw Kujawa signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CVS commit: src/sys/arch/amiga/conf
Thanks. On 2 Sep 2013, at 9:24 AM, Nick Hudson wrote: > Module Name: src > Committed By: skrll > Date: Mon Sep 2 07:24:17 UTC 2013 > > Modified Files: > src/sys/arch/amiga/conf: DRACO GENERIC INSTALL > > Log Message: > Re-gen. Hi rkujawa. > > > To generate a diff of this commit: > cvs rdiff -u -r1.171 -r1.172 src/sys/arch/amiga/conf/DRACO > cvs rdiff -u -r1.303 -r1.304 src/sys/arch/amiga/conf/GENERIC > cvs rdiff -u -r1.121 -r1.122 src/sys/arch/amiga/conf/INSTALL > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > Modified files: > > Index: src/sys/arch/amiga/conf/DRACO > diff -u src/sys/arch/amiga/conf/DRACO:1.171 > src/sys/arch/amiga/conf/DRACO:1.172 > --- src/sys/arch/amiga/conf/DRACO:1.171 Sun Jun 30 21:38:55 2013 > +++ src/sys/arch/amiga/conf/DRACO Mon Sep 2 07:24:17 2013 > @@ -1,9 +1,9 @@ > -# $NetBSD: DRACO,v 1.171 2013/06/30 21:38:55 rmind Exp $ > +# $NetBSD: DRACO,v 1.172 2013/09/02 07:24:17 skrll Exp $ > # > # This file was automatically created. > # Changes will be lost when make is run in this directory. > # > -# Created from: # NetBSD: GENERIC.in,v 1.110 2013/01/29 21:04:55 rkujawa Exp > $ > +# Created from: # NetBSD: GENERIC.in,v 1.119 2013/08/11 16:15:52 rkujawa Exp > $ > # > ## > # GENERIC machine description file > @@ -29,7 +29,7 @@ include "arch/amiga/conf/std.amiga" > > options INCLUDE_CONFIG_FILE # embed config file in kernel binary > > -#ident "GENERIC-$Revision: 1.171 $" > +#ident "GENERIC-$Revision: 1.172 $" > > > maxusers 8 > @@ -298,6 +298,9 @@ ed* at zbus0# Hydra, ASDG > LanRover > es* at zbus0# CEI A4066 EthernetPLUS > qn* at zbus0# Quicknet > > +xsh* at zbus0# X-Surf 100 > +ne* at xshbus? # NE2000 chip on X-Surf 100 > + > xsurf*at zbus0# X-Surf > ne* at xsurfbus?# NE2000 chip on X-Surf > gencp*at xsurfbus?# clockports on X-Surf > > Index: src/sys/arch/amiga/conf/GENERIC > diff -u src/sys/arch/amiga/conf/GENERIC:1.303 > src/sys/arch/amiga/conf/GENERIC:1.304 > --- src/sys/arch/amiga/conf/GENERIC:1.303 Sun Jun 30 21:38:55 2013 > +++ src/sys/arch/amiga/conf/GENERIC Mon Sep 2 07:24:17 2013 > @@ -1,9 +1,9 @@ > -# $NetBSD: GENERIC,v 1.303 2013/06/30 21:38:55 rmind Exp $ > +# $NetBSD: GENERIC,v 1.304 2013/09/02 07:24:17 skrll Exp $ > # > # This file was automatically created. > # Changes will be lost when make is run in this directory. > # > -# Created from: # NetBSD: GENERIC.in,v 1.110 2013/01/29 21:04:55 rkujawa Exp > $ > +# Created from: # NetBSD: GENERIC.in,v 1.119 2013/08/11 16:15:52 rkujawa Exp > $ > # > ## > # GENERIC machine description file > @@ -29,7 +29,7 @@ include "arch/amiga/conf/std.amiga" > > options INCLUDE_CONFIG_FILE # embed config file in kernel binary > > -#ident "GENERIC-$Revision: 1.303 $" > +#ident "GENERIC-$Revision: 1.304 $" > > > maxusers 8 > @@ -381,6 +381,9 @@ ed* at zbus0# Hydra, ASDG > LanRover > es* at zbus0# CEI A4066 EthernetPLUS > qn* at zbus0# Quicknet > > +xsh* at zbus0# X-Surf 100 > +ne* at xshbus? # NE2000 chip on X-Surf 100 > + > xsurf*at zbus0# X-Surf > ne* at xsurfbus?# NE2000 chip on X-Surf > gencp*at xsurfbus?# clockports on X-Surf > @@ -541,6 +544,16 @@ bthidev* at bthub? > # Bluetooth Audio support > #btsco* at bthub? > > +# USB > +slhci* at zbus?# Thylacine > +usb* at slhci? > + > +uhub*at usb? > +uhub*at uhub? port ? > + > +uhidev* at uhub? port ? configuration ? interface ? > +uhid*at uhidev? reportid ? > + > # > # accept filters > pseudo-device accf_data # "dataready" accept filter > > Index: src/sys/arch/amiga/conf/INSTALL > diff -u src/sys/arch/amiga/conf/INSTALL:1.121 > src/sys/arch/amiga/conf/INSTALL:1.122 > --- src/sys/arch/amiga/conf/INSTALL:1.121 Sun Jun 30 21:38:55 2013 > +++ src/sys/arch/amiga/conf/INSTALL Mon Sep 2 07:24:17 2013 > @@ -1,9 +1,9 @@ > -# $NetBSD: INSTALL,v 1.121 2013/06/30 21:38:55 rmind Exp $ > +# $NetBSD: INSTALL,v 1.122 2013/09/02 07:24:17 skrll Exp $ > # > # This file was automatically created. > # Changes will be lost when make is run in this directory. > # > -# Created from: # NetBSD: GENERIC.in,v 1.110 2013/01/29 21:04:55 rkujawa Exp > $ > +# Created from: # NetBSD: GENERIC.in,v 1.119 2013/08/11 16:15:52 rkujawa Exp > $ > # > ## > # GENERIC machine description file > @@ -29,7 +29,7 @@ include "arch/amiga/conf/std.amiga" > > options INCLUDE_CONFIG_FILE
Re: CVS commit: src/share/man/man4/man4.amiga
On 9 Aug 2013, at 5:35 PM, Paul Goyette wrote: > Module Name: src > Committed By: pgoyette > Date: Fri Aug 9 15:35:54 UTC 2013 > > Modified Files: > src/share/man/man4/man4.amiga: Makefile > > Log Message: > Make the xsh man pages to unbreak the build (sets lists were updated to > expect these man pages, but they were not being built) Thanks, I've actually modified the Makefile but forgot to commit it… -- Best regards, Radoslaw Kujawa signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CVS commit: src/sys/dev/marvell
Hi. On 3 Aug 2013, at 9:39 AM, KIYOHARA Takashi wrote: > Module Name: src > Committed By: kiyohara > Date: Sat Aug 3 07:39:31 UTC 2013 > > Modified Files: > src/sys/dev/marvell: gttwsi.c gttwsireg.h > > Log Message: > Issue the STOP-bit if needed. > And remove #ifdef ARMADAXP. Did you actually test this on Armada? -- Best regards, Radoslaw Kujawa
Re: CVS commit: src/sys/dev/bluetooth
age=0x Const, logical range 0..1 Feature id=9 size=8 count=1 page=0xff01 usage=0x000b Variable, logical range 0..1 Feature id=9 size=8 count=2 page=0x usage=0x Const, logical range 0..1 End collection -- Best regards, Radoslaw Kujawa
Re: CVS commit: src/sys/dev/bluetooth
Hi. On 2 sty 2012, at 11:00, Iain Hibbert wrote: > On Sun, 1 Jan 2012, Radoslaw Kujawa wrote: > >> I can easily reproduce this problem with Apple Wireless Keyboard >> (version without numeric keypad) on NetBSD/amd64 HEAD. If this patch is >> not applied, pressing caps lock always results in panic, as in photo. > > Hmm, how long have you been using a Bluetooth keyboard? I've just started. I was using Bluetooth stack for other things for a long time, but never really used keyboard on NetBSD (until now). > I wonder if > something else has changed recently (I've been busy lately - my source is > from early October, and I want to test something else before updating) I originally saw this problem on a kernel from August 9. Then I've updated to current, to see if this issue persists. So it's not a recent problem. > Also, what kernel options do you have? I am using i386 Do you have MP machine? Maybe this problem is triggered only on MP? > and have always > used DIAGNOSTIC (built in now) and I have run with LOCKDEBUG in the past > though am not at the moment I do have DIAGNOSTIC. Full config: http://c0ff33.net/drop/NBWS Now I also added LOCKDEBUG. >>> and btkbd should really be Bluetooth agnostic since its the same as >>> ukbd (except that ukbd is tied too closely to the USB stack) >> >> So we shouldn't fiddle with bt_lock in btkbd.c ? > > Really, no we shouldn't.. (...) Ok, so I shall revert this once we find the correct solution. >>> btkbd_set_leds() may be called from wskbd directly (by pressing caps lock >>> on your built-in keyboard for instance) >> >> I've tested this patch by pressing the caps lock key on bt keyboard and >> issuing wsconsctl ledstate=1, and both methods work. > > Do you have a built in keyboard? wsconsctl uses the ioctl, and bt > keyboard calls the function with the bt_lock held, but if you press the > caps-lock on the built in keyboard then wscons calls the set_leds routine > directly, I think? (thus, no lock will be acquired, when sending the > output report, which is not obviously going to break immediately, but..) I've connected the USB keyboard again to work on this problem ;). I'll search for PS/2 keyboard... Pressing the caps lock on USB keyboard does not light the LED on bluetooth keyboard. However, using wsconsctl -w ledstate=1 does light the LED on both keyboards. AFAIK it should use the same method to light the led, no matter if it was from userland app or by pressing the key on other keyboard? >>> probably it should be that bt_lock is released in bthidev_input() >>> before calling the hid_output function.. >> >> I'm not sure if I understand correctly. The bthidev_input() does not >> acquire bt_lock at all. > > it is called from within the bluetooth protocol stack, so will be holding > it already (thats where the 'locking against myself' originates) Ok, I understood later that it is already held in bthidev_input(), mrg pointed out that it was probably acquired in hci_intr(). > Just dropping the lock and reaquiring it around the sc_input/sc_feature > call is probably not exactly the right thing to do though (as the stack > will not be aware that that might have happened and data structures could > have changed), Yesterday I've tried dropping the lock this way (around sc_input/sc_feature loop), however this results in MUTEX_OWNER(mtx->mtx_owner) == curthread assertion failed. Looks like the lock is held by another thread? > it really should disassociate from the context, maybe doing > the call from a callout or separate task instead. Wouldn't that again lead to the situation where mtx_owner assertion will fail? If we call mutex_exit() from other thread than the one which acquired the lock, it will certainly fail. I understand that callout or separate task will be executed in another thread. > bthidev0: report ID 17, len = 1 ignored > > messages you got.. that is not normal (likely not relevant to the locking > issue though), how did you trigger them, is it just caps lock? No, that's the FN key. -- Best regards, Radoslaw Kujawa
Re: CVS commit: src/sys/dev/bluetooth
Hi Iain. Sorry, I should have consulted you before committing this. On 1 sty 2012, at 20:44, Iain Hibbert wrote: > On Sat, 31 Dec 2011, Radoslaw Kujawa wrote: > >> Module Name: src >> Committed By:rkujawa >> Date:Sat Dec 31 01:16:09 UTC 2011 >> >> Modified Files: >> src/sys/dev/bluetooth: bthidev.c btkbd.c >> >> Log Message: >> Fix panic triggered by pressing the caps lock key: >> http://c0ff33.net/drop/bt_caps_panic.jpg > > this does not seem right - I've never had such a panic, I can easily reproduce this problem with Apple Wireless Keyboard (version without numeric keypad) on NetBSD/amd64 HEAD. If this patch is not applied, pressing caps lock always results in panic, as in photo. > and btkbd should > really be Bluetooth agnostic since its the same as ukbd (except that > ukbd is tied too closely to the USB stack) So we shouldn't fiddle with bt_lock in btkbd.c ? > btkbd_set_leds() may be called from wskbd directly (by pressing caps lock > on your built-in keyboard for instance) I've tested this patch by pressing the caps lock key on bt keyboard and issuing wsconsctl ledstate=1, and both methods work. > probably it should be that bt_lock is released in bthidev_input() before > calling the hid_output function.. I'm not sure if I understand correctly. The bthidev_input() does not acquire bt_lock at all. -- Best regards, Radoslaw Kujawa
