daily CVS update output

2017-08-28 Thread NetBSD source update

Updating src tree:
P src/bin/ps/ps.1
P src/libexec/ld.elf_so/arch/aarch64/mdreloc.c
P src/sbin/mount_procfs/mount_procfs.8
P src/share/man/man9/extent.9
P src/share/man/man9/kauth.9
P src/sys/arch/evbarm/conf/std.rockchip
P src/sys/arch/evbarm/conf/std.zynq
P src/sys/arch/x86/x86/procfs_machdep.c
P src/sys/kern/kern_ktrace.c
P src/tests/net/net/t_tcp.c

Updating xsrc tree:


Killing core files:




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  54575328 Aug 29 03:04 ls-lRA.gz


Re: iscsi-initiator no longer compatible with librefuse

2017-08-28 Thread Sverre Froyen

> On 2017-08-26, at 02:47, Michael van Elst  wrote:
> 
> sve...@viewmark.com (Sverre Froyen) writes:
> 
>> The changes to librefuse last year require changes to iscsi-initiator. This 
>> is because of argument changes for fuse_main. The symptom is a "fuse: no 
>> mountpoint specified” error. Has anyone looked at this?
> 
> Probably not. Is there a reason to use that iscsi-initiator? The in-kernel
> one is much better.

The only reason was that I discovered the iscsi-initiator/iscsi-target version 
first and they worked fine. Now, a quick test of the in-kernel version results 
in a stream of

sd0(iscsi0:0:0:0): QUEUE FULL resulted in 0 openings

after a few seconds of stress (performing a "cvs update -dP” on the netbsd-7 
branch). It this point, the machine is non-responsive until a reboot. Light use 
seems to work OK.

My setup is as follows:

NetBSD-current VM running on a MacBook Pro OS X 10.12.6 under VMware Fusion.

10 GB filesystem image file on the Mac containing netbsd-7 served up using 
netbsd-iscsi-target from pkgsrc (yes, iscsi-target is running on the Mac).

Previously I’ve used this setup extensively with iscsi-initiator and vnd on the 
NetBSD VM.

I can always use NFS to provide the filesystem image files to the NetBSD. It’s 
only about 10-20% slower but, for some reason, iscsi appeals to me as a 
cleverer solution.

Regards,
Sverre

PS I was able to fix the fuse_main args issue by adding a conditional

opts.mountpoint = *argv;

in fuse_main_real. This makes iscsi-initiator start up. However, attempting to 
use the remote file causes a hang in the read system call (perhaps another args 
change).

PPS I notice that iscsi_initiator installs in /sbin whereas librefuse is in 
/usr/lib. Seems like iscsi_initiator (and iscsi_target?) should be moved to 
/usr/sbin.













Re: Ralink usb not working in Netbsd 8 (RPI2 and SUNXI)

2017-08-28 Thread Nick Hudson

On 08/28/17 18:29, co...@sdf.org wrote:

One of the possible causes is changes in the driver itself, too.
We've synced the source with the version of the code in another BSD.

yeah, thinking it is probably this..




Which card is it?


run0 at uhub1 port 4
run0: Ralink 802.11 n WLAN, rev 2.00/1.01, addr 6
run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 
c8:3a:35:c9:1e:0c
run0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
run0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 
36Mbps 48Mbps 54Mbps


from the earlier message.

Nick



Re: iscsi-initiator no longer compatible with librefuse

2017-08-28 Thread Michael van Elst
On Mon, Aug 28, 2017 at 11:25:15AM -0600, Sverre Froyen wrote:
> 
> The only reason was that I discovered the iscsi-initiator/iscsi-target 
> version first and they worked fine. Now, a quick test of the in-kernel 
> version results in a stream of
> 
>   sd0(iscsi0:0:0:0): QUEUE FULL resulted in 0 openings
> 
> after a few seconds of stress (performing a "cvs update -dP? on the netbsd-7 
> branch). It this point, the machine is non-responsive until a reboot. Light 
> use seems to work OK.

That message usually says that the target is either slow or lies in
how many concurrent requests it can handle. It may stall the iscsi
connection, but it shouldn't make the machine non-responsive. I haven't
seen it forever, but I mostly test the in-kernel initiator against
Linux, FreeBSD (FreeNAS) and istgt.


> My setup is as follows:
> 
> NetBSD-current VM running on a MacBook Pro OS X 10.12.6 under VMware Fusion.
> 
> 10 GB filesystem image file on the Mac containing netbsd-7 served up using 
> netbsd-iscsi-target from pkgsrc (yes, iscsi-target is running on the Mac).

You run -current on the VM but have a netbsd-7 image attached?

In my experience net/istgt is a much better iscsi target. No idea wether
it builds or runs under MacOS.




> PPS I notice that iscsi_initiator installs in /sbin whereas librefuse is in 
> /usr/lib. Seems like iscsi_initiator (and iscsi_target?) should be moved to 
> /usr/sbin.

Hmm. iscsi-initiator and iscsi-target are both in /usr/sbin.

iscsid and iscsictl are in /sbin.



Greetings,
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."


Re: gdb misbehaviour

2017-08-28 Thread John D. Baker
On Mon, 28 Aug 2017 16:28:06 +0100, Patrick Welche 
wrote:

> While trying to update pkgsrc glib-networking on -current/amd64, I
> saw that gio-querymodules kept dumping core.

I can't speak to the 'gdb' issue, but your description of the situation
that prompted it sounds like toolchain/51266.

When did you last build "glib2" and "gobject-introspection"?  Was it with
a system before this change:

  http://mail-index.netbsd.org/source-changes/2017/07/19/msg086477.html

or after?  It has been my observation that packages built before the
above change will continue to have problems, notably 'gio-querymodules'
segfaulting during the de-install of a package being updated/replaced.

-- 
|/"\ John D. Baker, KN5UKS   NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645



Re: Ralink usb not working in Netbsd 8 (RPI2 and SUNXI)

2017-08-28 Thread trebol



On Mon, 28 Aug 2017, Nick Hudson wrote:


On 08/28/17 18:29, co...@sdf.org wrote:

One of the possible causes is changes in the driver itself, too.
We've synced the source with the version of the code in another BSD.

yeah, thinking it is probably this..




Which card is it?


run0 at uhub1 port 4
run0: Ralink 802.11 n WLAN, rev 2.00/1.01, addr 6
run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 
c8:3a:35:c9:1e:0c

run0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
run0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 
36Mbps 48Mbps 54Mbps



from the earlier message.

Nick




The usb card itself is Invectec INV-USB11N. Maybe someone with another one 
can make a test too.


Re: Ralink usb not working in Netbsd 8 (RPI2 and SUNXI)

2017-08-28 Thread coypu
One of the possible causes is changes in the driver itself, too.
We've synced the source with the version of the code in another BSD.

Which card is it?


gdb misbehaviour

2017-08-28 Thread Patrick Welche
While trying to update pkgsrc glib-networking on -current/amd64,
I saw that gio-querymodules kept dumping core. I don't understand
the gdb output:

quantz# gdb /usr/pkg/bin/gio-querymodules  
GNU gdb (GDB) 7.12
...
(gdb) break main
Breakpoint 1 at 0x401438: file gio-querymodules.c, line 132.
(gdb) run /usr/pkg/lib/gio/modules
Starting program: /usr/pkg/bin/gio-querymodules /usr/pkg/lib/gio/modules

Breakpoint 1, main (argc=2, argv=0x7f7fe7a0) at gio-querymodules.c:132
132   if (argc == 1)
(gdb) n
139   setlocale (LC_ALL, "");
(gdb) 
142   g_type_ensure (G_TYPE_OBJECT);
(gdb) 
144   for (i = 1; i < argc; i++)
(gdb) 
145 query_dir (argv[i]);
(gdb) 
144   for (i = 1; i < argc; i++)
(gdb) 
147   return 0;
(gdb) 
148 }
(gdb) 
0x0040101b in ___start ()
(gdb) 
Single stepping until exit from function ___start,
which has no line number information.

Program received signal SIGSEGV, Segmentation fault.
0x7f7ff4c0979f in ?? ()
(gdb) 
Cannot find bounds of current function


"return 0;" didn't? (This is a 20 August system)

Cheers,

Patrick


Re: USB device detection problem

2017-08-28 Thread Mike Pumford



On 25/08/2017 13:51, Nick Hudson wrote:

On 06/25/17 11:06, Mike Pumford wrote:
Just trying to fire up NetBSD 8-BETA on my builder machine but I've 
run into a bit of a showstopper (for me) bug in the new kernel.


On NetBSD 7-STABLE (Apr 14th) my KVM is detected as:
uhub6 at uhub1 port 6:  , class 9/0, rev 1.10/1.00, addr 1
uhub6: 4 ports with 4 removable, self powered

And then the kernel carries on an finds the keyboard and mouse 
downstream of that device.


In NetBSD 8 I get:
uhub6 at uhub1 port 6: vendor 0557 (0x557) product 8021 (0x8021), 
class 9/0, rev 1.10/1.00, addr 1

uhub6: 4 ports with 4 removable, self powered


uhub6: device problem, disabling port 1

This means I have no console keyboard. Anything I can do to help track 
this down?


I've also attached full dmesg from Both 8-BETA and 7.1-STABLE.


So, to be clear these builds are from recent netbsd-8 and netbsd-7 trees 
and therefore both have approximately the same sys/dev/usb code?


Just got back from a holiday so I'm still catching up. Yes they were 
from recent netbsd-8 and netbsd-7. Probably fetched and built just 
before I sent out the e-mail.



If so, I wonder if using msi interrupts is part of the problem?


-xhci0 at pci0 dev 20 function 0: vendor 0x8086 product 0x8cb1 (rev. 0x00)
-xhci0: interrupting at ioapic0 pin 21
+xhci0 at pci0 dev 20 function 0: vendor 8086 product 8cb1 (rev. 0x00)
+xhci0: interrupting at msi2 vec 0

Can you check interrupt counters (vmstat -i) ?

I will do that a little bit later on. One oddity is that if I move the 
keyboard/mouse connection to a USB3 port rather than one of the USB2 
only ports it actually works perfectly on 8-BETA.


Mike




Mike


Nick