Re: usb/140477: [umass] [patch] allow boot-time attachment of daX devices to GEOM_ELI

2009-11-12 Thread Eygene Ryabinkin
The following reply was made to PR usb/140477; it has been noted by GNATS.

From: Eygene Ryabinkin rea-f...@codelabs.ru
To: Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net
Cc: bug-follo...@freebsd.org
Subject: Re: usb/140477: [umass] [patch] allow boot-time attachment of daX
 devices to GEOM_ELI
Date: Thu, 12 Nov 2009 12:11:17 +0300

 Bjoern, good day.
 
 Thu, Nov 12, 2009 at 07:28:03AM +, Bjoern A. Zeeb wrote:
  has this changed recently, that it no longer works?  I seem to
  remember that it had perfectly worked before this year.
 
 Yes, it used to work with up to 7.anything.  But it seems that with
 the new USB stack we have asynchronous discovery and attachment, so
 other subsystems are started when this process isn't yet fully
 completed, so root mount is getting closer and, for my case, root
 mount typically waits only for the completion of USB tasks.
 
 My gut feeling is that the device discovery prior to the USBv2 was
 done synchronously, but with USBv2 kernel use async callbacks.  Though,
 I may be wrong in this judgement.
 
 You can try it yourself -- plugged USB stick with geli volume that is
 marked as attach-on-boot should show the current behaviour.
 -- 
 Eygene
  ____   _.--.   #
  \`.|\.....-'`   `-._.-'_.-'`   #  Remember that it is hard
  /  ' ` ,   __.--'  #  to read the on-line manual
  )/' _/ \   `-_,   /#  while single-stepping the kernel.
  `-' `\_  ,_.-;_.-\_ ',  fsc/as   #
  _.-'_./   {_.'   ; /   #-- FreeBSD Developers handbook
 {_.-``-' {_/#
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org


Re: usb/140477: [umass] [patch] allow boot-time attachment of daX devices to GEOM_ELI

2009-11-12 Thread Bjoern A. Zeeb
The following reply was made to PR usb/140477; it has been noted by GNATS.

From: Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net
To: Eygene Ryabinkin rea-f...@codelabs.ru
Cc: bug-follo...@freebsd.org
Subject: Re: usb/140477: [umass] [patch] allow boot-time attachment of daX
 devices to GEOM_ELI
Date: Thu, 12 Nov 2009 10:43:56 + (UTC)

 On Thu, 12 Nov 2009, Eygene Ryabinkin wrote:
 
 Hi,
 
  Bjoern, good day.
 
  Thu, Nov 12, 2009 at 07:28:03AM +, Bjoern A. Zeeb wrote:
  has this changed recently, that it no longer works?  I seem to
  remember that it had perfectly worked before this year.
 
  Yes, it used to work with up to 7.anything.  But it seems that with
  the new USB stack we have asynchronous discovery and attachment, so
  other subsystems are started when this process isn't yet fully
  completed, so root mount is getting closer and, for my case, root
  mount typically waits only for the completion of USB tasks.
 
  My gut feeling is that the device discovery prior to the USBv2 was
  done synchronously, but with USBv2 kernel use async callbacks.  Though,
  I may be wrong in this judgement.
 
  You can try it yourself -- plugged USB stick with geli volume that is
  marked as attach-on-boot should show the current behaviour.
 
 I am doing that regularly, on HEAD (last updated in October). But I
 see I lacked coffee this morning, wanted to say earlier this year.
 
 -- 
 Bjoern A. Zeeb It will not break if you know what you are doing.
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org


Re: usb/140477: [umass] [patch] allow boot-time attachment of daX devices to GEOM_ELI

2009-11-12 Thread Eygene Ryabinkin
The following reply was made to PR usb/140477; it has been noted by GNATS.

From: Eygene Ryabinkin rea-f...@codelabs.ru
To: Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net
Cc: bug-follo...@freebsd.org
Subject: Re: usb/140477: [umass] [patch] allow boot-time attachment of daX
 devices to GEOM_ELI
Date: Thu, 12 Nov 2009 16:29:54 +0300

 Thu, Nov 12, 2009 at 10:43:56AM +, Bjoern A. Zeeb wrote:
  I am doing that regularly, on HEAD (last updated in October). But I
  see I lacked coffee this morning, wanted to say earlier this year.
 
 Then it will be interesting to see on which point your kernel is
 attaching the daX devices.  Could you, please, show your dmesg?
 -- 
 Eygene
  ____   _.--.   #
  \`.|\.....-'`   `-._.-'_.-'`   #  Remember that it is hard
  /  ' ` ,   __.--'  #  to read the on-line manual
  )/' _/ \   `-_,   /#  while single-stepping the kernel.
  `-' `\_  ,_.-;_.-\_ ',  fsc/as   #
  _.-'_./   {_.'   ; /   #-- FreeBSD Developers handbook
 {_.-``-' {_/#
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org


[madwimax] madwimax-0.1.1 patch for FreeBSD 8 (very buggy)

2009-11-12 Thread Alexander Samarin
HOWTO:

yume$ fetch ftp://ftp.enikasoft.ru/pub/madwimax-freebsd8.patch;
yume$ fetch http://madwimax.googlecode.com/files/madwimax-0.1.1.tar.gz;
yume$ tar xf madwimax-0.1.1.tar.gz

yume$ cd madwimax-0.1.1
yume$ export libusb1_CFLAGS=-I/usr/include
yume$ export libusb1_LIBS=-L/usr/lib -lusb
yume$ ./configure --without-man-pages
yume$ echo '#define MADWIMAX_VERSION_MACRO madwimax-0.1.1-freebsd'  \
include/madwimax_version.h
yume$ cd src
yume$ patch  ../../madwimax-freebsd8.patch
yume$ make

yume$ su
yume# kldload if_tap
yume# ./madwimax
...
Allocated tap interface: tap0
...

On other console:

yume$ su
yume# dhclient tap0
yume# cat /var/db/dhclient.leases.tap
...
  option routers XXX.XXX.XXX.XXX;
  option domain-name-servers YYY.YYY.YYY.YYY;
...
yume# route delete default
yume# route add default XXX.XXX.XXX.XXX
yume# echo nameserver YYY.YYY.YYY.YYY  /etc/resolv.conf



Tested on FreeBSD 8.0-RC2 i386; modem Samsung SWC-U200.
Usually works fine (ping normal - less than 1% packet loss; http ok)
Sometimes crashes in libusb:

yume# ./madwimax
...
Allocated tap interface: tap0
zsh: segmentation fault (core dumped)  ./madwimax
yume# gdb ./madwimax madwimax.core
GNU gdb 6.1.1 [FreeBSD]
...
Core was generated by `madwimax'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /usr/lib/libusb.so.2...done.
Loaded symbols for /usr/lib/libusb.so.2
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  libusb10_submit_transfer_sub (pdev=0x28209480, endpoint=4 '\004') at
libusb10.c:1116
1116 if (sxfer-rem_len)
[New Thread 28201140 (LWP 100077)]
(gdb) bt
#0  libusb10_submit_transfer_sub (pdev=0x28209480, endpoint=4 '\004') at
libusb10.c:1116
#1  0x280acf23 in libusb_cancel_transfer (uxfer=0x282250c8) at
libusb10.c:1297
#2  0x280ac615 in libusb10_do_transfer (devh=0x28209480,
endpoint=Variable endpoint is not available.
) at libusb10_io.c:509
#3  0x280ac757 in libusb_bulk_transfer (devh=0x28209480,
endpoint=Variable endpoint is not available.
) at libusb10_io.c:552
#4  0x08049874 in set_data (data=0xbfbfab80 WC\024, size=26) at
wimax.c:224
#5  0x0804a914 in main (argc=1, argv=0x280ad160) at wimax.c:652
(gdb) print *pxfer0 
$1 = {pdev = 0x28209480, callback = 0x280ad160
libusb10_bulk_intr_proxy, priv_sc0 = 0x28209480,
  priv_sc1 = 0x0, ppBuffer = 0x28226094, pLength = 0x28226090,
maxTotalLength = 16384,
  maxFrames = 1, nFrames = 1, aFrames = 1, timeout = 0, timeComplete =
0, trIndex = 16,
  maxPacketLen = 512, flags = 0 '\0', status = 1 '\001', is_opened = 1
'\001',
  is_pending = 1 '\001', is_cancel = 1 '\001', is_draining = 0 '\0',
is_restart = 0 '\0'}
(gdb) print *pxfer1
$2 = {pdev = 0x28209480, callback = 0x280b0380 dummy_callback,
priv_sc0 = 0x0,
  priv_sc1 = 0x0, ppBuffer = 0x0, pLength = 0x0, maxTotalLength = 0,
  maxFrames = 0, nFrames = 0, aFrames = 0, timeout = 0, timeComplete =
0, trIndex = 17,
  maxPacketLen = 0, flags = 0 '\0', status = 0 '\0', is_opened = 0 '\0',
  is_pending = 0 '\0', is_cancel = 0 '\0', is_draining = 0 '\0',
is_restart = 0 '\0'}
(gdb) print *sxfer 
Variable sxfer is not available.

Near libusb10.c:1116:
1115 sxfer = libusb20_tr_get_priv_sc1(pxfer0);
1116 if (sxfer-rem_len)

Near libusb20.c:258:
257 void   *
258 libusb20_tr_get_priv_sc1(struct libusb20_transfer *xfer)
259 {
260 return (xfer-priv_sc1);
261 }

Because of pxfer0-priv_sc1 is NULL from core dump, I think that it is
a libusb implementation bug.



PS:
Also I've commented this call at wimax.c:847:

847 //libusb_cancel_transfer(req_transfer);

because of segmentation fault when program going to terminate.
(this is inside exit_release_resources() function)


--
Best regards,  Alexander Samarin
mailto:sa...@enikasoft.ru
https://www.fsora.ru (waits for FreeBSD 8.0-RELEASE)


diff -u src-old/tap_dev.c src/tap_dev.c
--- src-old/tap_dev.c	2009-07-04 07:54:13.0 +0400
+++ src/tap_dev.c	2009-11-12 10:37:56.0 +0300
@@ -28,10 +28,18 @@
 
 #include sys/ioctl.h
 #include sys/socket.h
+#if defined(__linux__)
 #include linux/if.h
 #include linux/if_arp.h
 #include linux/if_ether.h
 #include linux/if_tun.h
+#elif defined(__FreeBSD__)
+#include net/ethernet.h
+#include net/if.h
+#include net/if_arp.h
+#include net/if_tap.h
+#include net/if_tun.h
+#endif
 
 #include wimax.h
 
@@ -83,14 +91,21 @@
 	struct ifreq ifr;
 	int fd;
 
+#if defined(__linux__)
 	if ((fd = open(/dev/net/tun, O_RDWR))  0)
+#elif defined(__FreeBSD__)
+	if ((fd = open(istun ? /dev/tun : /dev/tap, O_RDWR))  0)
+#endif
 		return tun_open_common0(dev, istun);
 
 	memset(ifr, 0, sizeof(ifr));
+#if defined(__linux__)
 	ifr.ifr_flags = (istun ? IFF_TUN : IFF_TAP) | IFF_NO_PI;
+#endif
 	if (*dev)
 		strncpy(ifr.ifr_name, dev, IFNAMSIZ);
 
+#if defined(__linux__)
 	if (ioctl(fd, TUNSETIFF, (void *) ifr)  0) {
 		if (errno == EBADFD) {
 			/*