Re: urtw0: could not allocate USB transfers
On Wednesday 02 March 2011 18:01:19 Etienne Robillard wrote: > On 02/03/11 11:47 AM, John Baldwin wrote: > > On Wednesday, March 02, 2011 11:00:26 am Etienne Robillard wrote: > >> On 02/25/2011 07:31, Bernhard Schmidt wrote: > >>> On Friday, February 25, 2011 12:47:12 Etienne Robillard wrote: > On 25/02/11 06:18 AM, Bernhard Schmidt wrote: > > On Friday, February 25, 2011 11:03:04 Etienne Robillard wrote: > >> On 25/02/11 04:11 AM, Bernhard Schmidt wrote: > >>> On Thursday, February 24, 2011 21:51:23 joseph wrote: > Hello, > > i decided to get my laptop wlan via usb because my internal device > > > > isn't > > > supported yet. > The usb device is a logilink WL0006 unit its vendorid is 0x0bda > and > > > > the > > > productid says 0x8187. > My search results say that this device depends on a RTL8187 > chipset. I tried both, load the kernel module at boot time and > compile kernel withe urtw, but i get the same output at dmesg > > device_attach: urtw0 attach returned 6 > urtw0: addr > > > > 2> > > > on usbus3 > urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE > device_attach: urtw0 attach returned 6 > > im running FreeBSD 8.1-RELEASE-p2 amd64. > > What might be the reason for this error? > Thanks for all hints. > >>> > >>> Well, I have no clue about USB.. but this smells like one of the > >>> endpoints is 'not there'. At least I can't find any reference to > >>> it in the Linux driver. Wanna give attached patch a shot? > >> > >> Hi Bernard, > >> > >> For rt287x based cards, you can try using rt28700 chipset instead of > >> urtw0 on > >> FreeBSD 8. > >> > >> The former is not in the stable src tree, but could be retrieved > >> from > > > > here: > >> https://gthc.org/distfiles/freebsd/rt2870_fbsd8.tar.gz > >> > >> Any takers to make module rt28700 (if_rt2870) officially part of the > >> FreeBSD src tree? > > > > I'm a bit confused now, shouldn't the rt2870 be supported by run(4)? > > On a site-note, this is Ralink chipset not a Realtek one. > > I believe this is a different implementation for RT8187 usb network > adapters than > run(4). However in my view I found urtw0 buggy, but would certainly > take a look at run(4) to > compare the results with wireless networking agaisnt the other driver > (rt28700). > >>> > >>> Yeah, urtw(4) has a few flaws.. > >>> > >>> - urtw(4): Realtek RTL8187B/RTL8187L > >>> - rum(4): Ralink RT2501/RT2601 > >>> - run(4): Ralink RT2700/RT2800/RT3000 > >>> > >>> So it seems the driver you've posted conflicts with run(4). From a > >>> quick glance at it, it seems to support 11n? If so, can I talk you > >>> into working on getting those bits merged? > >>> Thanks! > >>> > >>> -- > >>> Bernhard > >>> X-UID: 10549 > >>> Status: > >>> X-Keywords: > >>> Content-Length: 0 > >> > >> I forwarded this thread on -current. > >> > >> Please also find below a stack trace produced with option KDB_UNATTENDED > >> for the rt28700 driver (if_rt28700). > >> > >> On another side note, I have not being able to load > >> the runfw firmware module anymore after having updated > >> the src tree for 8.2-STABLE ? > >> > >> $ sudo kldload /boot/kernel/runfw.ko > >> kldload: can't load /boot/kernel/runfw.ko: Exec format error > > > > Here is your real error in dmesg: > >> KLD runfw.ko: depends on firmware - not available or version mismatch > >> linker_load_file: Unsupported file type > > > > You need to kldload firmware.ko or make sure 'device firmware' is in your > > kernel config. > > Hi, > > Many thanks. This explains the change of behavior attempting to kldload > runfw.ko > without the firmware assist module. :) > > However I find strange that run(4) requires such a firmware to be preloaded > when the rt2870 driver doesn't require it! > > Cheers, Maybe that's due to a missing MODULE_DEPEND() line in the .c file of urtw0. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on i386/pc98
TB --- 2011-03-03 06:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-03-03 06:30:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-03-03 06:30:00 - cleaning the object tree TB --- 2011-03-03 06:30:21 - cvsupping the source tree TB --- 2011-03-03 06:30:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-03-03 06:35:55 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2011-03-03 06:35:55 - ERROR: unable to cvsup the source tree TB --- 2011-03-03 06:35:55 - 1.98 user 12.95 system 354.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc/powerpc
TB --- 2011-03-02 17:26:26 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-03-02 17:26:26 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-03-02 17:26:26 - cleaning the object tree TB --- 2011-03-02 17:26:43 - cvsupping the source tree TB --- 2011-03-02 17:26:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-03-02 17:26:56 - building world TB --- 2011-03-02 17:26:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-02 17:26:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-02 17:26:56 - TARGET=powerpc TB --- 2011-03-02 17:26:56 - TARGET_ARCH=powerpc TB --- 2011-03-02 17:26:56 - TZ=UTC TB --- 2011-03-02 17:26:56 - __MAKE_CONF=/dev/null TB --- 2011-03-02 17:26:56 - cd /src TB --- 2011-03-02 17:26:56 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 2 17:26:56 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Mar 2 19:08:30 UTC 2011 TB --- 2011-03-02 19:08:31 - generating LINT kernel config TB --- 2011-03-02 19:08:31 - cd /src/sys/powerpc/conf TB --- 2011-03-02 19:08:31 - /usr/bin/make -B LINT TB --- 2011-03-02 19:08:31 - building LINT kernel TB --- 2011-03-02 19:08:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-02 19:08:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-02 19:08:31 - TARGET=powerpc TB --- 2011-03-02 19:08:31 - TARGET_ARCH=powerpc TB --- 2011-03-02 19:08:31 - TZ=UTC TB --- 2011-03-02 19:08:31 - __MAKE_CONF=/dev/null TB --- 2011-03-02 19:08:31 - cd /src TB --- 2011-03-02 19:08:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 2 19:08:31 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/iommu_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/mmu_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/pic_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/platform_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector cc: /src/sys/netgraph/netflow/netflow_v9.c: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-03-02 19:09:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-03-02 19:09:37 - ERROR: failed to build lint kernel TB --- 2011-03-02 19:09:37 - 5089.11 user 861.66 system 6191.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc64/powerpc
TB --- 2011-03-02 17:26:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-03-02 17:26:34 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-03-02 17:26:34 - cleaning the object tree TB --- 2011-03-02 17:26:55 - cvsupping the source tree TB --- 2011-03-02 17:26:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-03-02 17:27:12 - building world TB --- 2011-03-02 17:27:12 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-02 17:27:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-02 17:27:12 - TARGET=powerpc TB --- 2011-03-02 17:27:12 - TARGET_ARCH=powerpc64 TB --- 2011-03-02 17:27:12 - TZ=UTC TB --- 2011-03-02 17:27:12 - __MAKE_CONF=/dev/null TB --- 2011-03-02 17:27:12 - cd /src TB --- 2011-03-02 17:27:12 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 2 17:27:12 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Mar 2 19:01:33 UTC 2011 TB --- 2011-03-02 19:01:33 - generating LINT kernel config TB --- 2011-03-02 19:01:33 - cd /src/sys/powerpc/conf TB --- 2011-03-02 19:01:33 - /usr/bin/make -B LINT TB --- 2011-03-02 19:01:33 - building LINT kernel TB --- 2011-03-02 19:01:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-02 19:01:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-02 19:01:33 - TARGET=powerpc TB --- 2011-03-02 19:01:33 - TARGET_ARCH=powerpc64 TB --- 2011-03-02 19:01:33 - TZ=UTC TB --- 2011-03-02 19:01:33 - __MAKE_CONF=/dev/null TB --- 2011-03-02 19:01:33 - cd /src TB --- 2011-03-02 19:01:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 2 19:01:33 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/iommu_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/mmu_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/pic_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/powerpc/powerpc/platform_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector cc: /src/sys/netgraph/netflow/netflow_v9.c: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-03-02 19:02:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-03-02 19:02:41 - ERROR: failed to build lint kernel TB --- 2011-03-02 19:02:41 - 4483.01 user 979.91 system 5767.00 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on sparc64/sparc64
TB --- 2011-03-02 17:33:14 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-03-02 17:33:14 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-03-02 17:33:14 - cleaning the object tree TB --- 2011-03-02 17:33:28 - cvsupping the source tree TB --- 2011-03-02 17:33:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-03-02 17:33:42 - building world TB --- 2011-03-02 17:33:42 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-02 17:33:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-02 17:33:42 - TARGET=sparc64 TB --- 2011-03-02 17:33:42 - TARGET_ARCH=sparc64 TB --- 2011-03-02 17:33:42 - TZ=UTC TB --- 2011-03-02 17:33:42 - __MAKE_CONF=/dev/null TB --- 2011-03-02 17:33:42 - cd /src TB --- 2011-03-02 17:33:42 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 2 17:33:42 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Mar 2 18:38:18 UTC 2011 TB --- 2011-03-02 18:38:18 - generating LINT kernel config TB --- 2011-03-02 18:38:18 - cd /src/sys/sparc64/conf TB --- 2011-03-02 18:38:18 - /usr/bin/make -B LINT TB --- 2011-03-02 18:38:18 - building LINT kernel TB --- 2011-03-02 18:38:18 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-02 18:38:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-02 18:38:18 - TARGET=sparc64 TB --- 2011-03-02 18:38:18 - TARGET_ARCH=sparc64 TB --- 2011-03-02 18:38:18 - TZ=UTC TB --- 2011-03-02 18:38:18 - __MAKE_CONF=/dev/null TB --- 2011-03-02 18:38:18 - cd /src TB --- 2011-03-02 18:38:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 2 18:38:18 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ofw/ofw_bus_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/ofw/ofw_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector cc: /src/sys/netgraph/netflow/netflow_v9.c: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-03-02 18:39:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-03-02 18:39:39 - ERROR: failed to build lint kernel TB --- 2011-03-02 18:39:39 - 3014.28 user 652.13 system 3984.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: urtw0: could not allocate USB transfers
On 02/03/11 11:47 AM, John Baldwin wrote: > On Wednesday, March 02, 2011 11:00:26 am Etienne Robillard wrote: > >> On 02/25/2011 07:31, Bernhard Schmidt wrote: >> >>> On Friday, February 25, 2011 12:47:12 Etienne Robillard wrote: >>> >>> On 25/02/11 06:18 AM, Bernhard Schmidt wrote: > On Friday, February 25, 2011 11:03:04 Etienne Robillard wrote: > > > >> On 25/02/11 04:11 AM, Bernhard Schmidt wrote: >> >> >> >>> On Thursday, February 24, 2011 21:51:23 joseph wrote: >>> >>> >>> >>> Hello, i decided to get my laptop wlan via usb because my internal device > isn't > supported yet. The usb device is a logilink WL0006 unit its vendorid is 0x0bda and > the > productid says 0x8187. My search results say that this device depends on a RTL8187 chipset. I tried both, load the kernel module at boot time and compile kernel withe urtw, but i get the same output at dmesg device_attach: urtw0 attach returned 6 urtw0:>>> > 2> > on usbus3 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE device_attach: urtw0 attach returned 6 im running FreeBSD 8.1-RELEASE-p2 amd64. What might be the reason for this error? Thanks for all hints. >>> Well, I have no clue about USB.. but this smells like one of the >>> endpoints is 'not there'. At least I can't find any reference to >>> it in the Linux driver. Wanna give attached patch a shot? >>> >>> >>> >>> >> Hi Bernard, >> >> For rt287x based cards, you can try using rt28700 chipset instead of >> urtw0 on >> FreeBSD 8. >> >> The former is not in the stable src tree, but could be retrieved from >> > here: > >> https://gthc.org/distfiles/freebsd/rt2870_fbsd8.tar.gz >> >> Any takers to make module rt28700 (if_rt2870) officially part of the >> FreeBSD src tree? >> >> >> > I'm a bit confused now, shouldn't the rt2870 be supported by run(4)? On > a site-note, this is Ralink chipset not a Realtek one. > > > > I believe this is a different implementation for RT8187 usb network adapters than run(4). However in my view I found urtw0 buggy, but would certainly take a look at run(4) to compare the results with wireless networking agaisnt the other driver (rt28700). >>> Yeah, urtw(4) has a few flaws.. >>> >>> - urtw(4): Realtek RTL8187B/RTL8187L >>> - rum(4): Ralink RT2501/RT2601 >>> - run(4): Ralink RT2700/RT2800/RT3000 >>> >>> So it seems the driver you've posted conflicts with run(4). From a >>> quick glance at it, it seems to support 11n? If so, can I talk you >>> into working on getting those bits merged? >>> Thanks! >>> >>> -- >>> Bernhard >>> X-UID: 10549 >>> Status: >>> X-Keywords: >>> Content-Length: 0 >>> >>> >>> >> I forwarded this thread on -current. >> >> Please also find below a stack trace produced with option KDB_UNATTENDED >> for the rt28700 driver (if_rt28700). >> >> On another side note, I have not being able to load >> the runfw firmware module anymore after having updated >> the src tree for 8.2-STABLE ? >> >> $ sudo kldload /boot/kernel/runfw.ko >> kldload: can't load /boot/kernel/runfw.ko: Exec format error >> > Here is your real error in dmesg: > > >> KLD runfw.ko: depends on firmware - not available or version mismatch >> linker_load_file: Unsupported file type >> > You need to kldload firmware.ko or make sure 'device firmware' is in your > kernel config. > > Hi, Many thanks. This explains the change of behavior attempting to kldload runfw.ko without the firmware assist module. :) However I find strange that run(4) requires such a firmware to be preloaded when the rt2870 driver doesn't require it! Cheers, -- Etienne Robillard Company: Green Tea Hackers Club Occupation: Software Developer (and CEO) E-mail: e...@gthcfoundation.org Work phone: 450-936-2123 Website (Company): https://gthc.org/ Website (Blog): https://gthc.org/blog/ PGP public key fingerprint:F2A9 32EA 8E7C 460F 1728 A1A7 649C 7F17 A086 DDEC During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell If a free society cannot help the many who are poor, it cannot save the few who are rich. -- John F. Kennedy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send
Re: urtw0: could not allocate USB transfers
On Wednesday, March 02, 2011 11:00:26 am Etienne Robillard wrote: > On 02/25/2011 07:31, Bernhard Schmidt wrote: > > On Friday, February 25, 2011 12:47:12 Etienne Robillard wrote: > > > >> On 25/02/11 06:18 AM, Bernhard Schmidt wrote: > >> > >>> On Friday, February 25, 2011 11:03:04 Etienne Robillard wrote: > >>> > >>> > On 25/02/11 04:11 AM, Bernhard Schmidt wrote: > > > > On Thursday, February 24, 2011 21:51:23 joseph wrote: > > > > > > > >> Hello, > >> > >> i decided to get my laptop wlan via usb because my internal device isn't > >> supported yet. > >> The usb device is a logilink WL0006 unit its vendorid is 0x0bda and the > >> productid says 0x8187. > >> My search results say that this device depends on a RTL8187 chipset. > >> I tried both, load the kernel module at boot time and compile kernel > >> withe urtw, but i get the same output at dmesg > >> > >> device_attach: urtw0 attach returned 6 > >> urtw0: > >> on usbus3 > >> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE > >> device_attach: urtw0 attach returned 6 > >> > >> im running FreeBSD 8.1-RELEASE-p2 amd64. > >> > >> What might be the reason for this error? > >> Thanks for all hints. > >> > >> > >> > > Well, I have no clue about USB.. but this smells like one of the > > endpoints is 'not there'. At least I can't find any reference to > > it in the Linux driver. Wanna give attached patch a shot? > > > > > > > Hi Bernard, > > For rt287x based cards, you can try using rt28700 chipset instead of > urtw0 on > FreeBSD 8. > > The former is not in the stable src tree, but could be retrieved from here: > > https://gthc.org/distfiles/freebsd/rt2870_fbsd8.tar.gz > > Any takers to make module rt28700 (if_rt2870) officially part of the > FreeBSD src tree? > > > >>> I'm a bit confused now, shouldn't the rt2870 be supported by run(4)? On > >>> a site-note, this is Ralink chipset not a Realtek one. > >>> > >>> > >>> > >> I believe this is a different implementation for RT8187 usb network > >> adapters than > >> run(4). However in my view I found urtw0 buggy, but would certainly take > >> a look at run(4) to > >> compare the results with wireless networking agaisnt the other driver > >> (rt28700). > >> > > Yeah, urtw(4) has a few flaws.. > > > > - urtw(4): Realtek RTL8187B/RTL8187L > > - rum(4): Ralink RT2501/RT2601 > > - run(4): Ralink RT2700/RT2800/RT3000 > > > > So it seems the driver you've posted conflicts with run(4). From a > > quick glance at it, it seems to support 11n? If so, can I talk you > > into working on getting those bits merged? > > Thanks! > > > > -- > > Bernhard > > X-UID: 10549 > > Status: > > X-Keywords: > > Content-Length: 0 > > > > > I forwarded this thread on -current. > > Please also find below a stack trace produced with option KDB_UNATTENDED > for the rt28700 driver (if_rt28700). > > On another side note, I have not being able to load > the runfw firmware module anymore after having updated > the src tree for 8.2-STABLE ? > > $ sudo kldload /boot/kernel/runfw.ko > kldload: can't load /boot/kernel/runfw.ko: Exec format error Here is your real error in dmesg: > KLD runfw.ko: depends on firmware - not available or version mismatch > linker_load_file: Unsupported file type You need to kldload firmware.ko or make sure 'device firmware' is in your kernel config. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Request for review/testing: switching the default installer
On Wednesday, March 02, 2011 10:36:58 am Nathan Whitehorn wrote: > On 02/28/11 09:20, John Baldwin wrote: > > On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote: > >> BSDinstall has acquired at this point its final form (prior to a future > >> merge with pc-sysinstall), and I believe is ready to replace sysinstall > >> on the 9.0 snapshot ISOs. Barring any objections, I would like to pull > >> this switch 2 weeks from today, on the 14th of March. > >> > >> A patch to the release infrastructure code can be found here (make > >> release must be run with Makefile.bsdinstall using this patch to get > >> non-sysinstall media): > >> http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff > > Hmm, does your installed world include the pre-built mergemaster database? > > That should really be preserved. > > > > It happens here in the old release Makefile: > > > > # Install the system into the various distributions. > > release.2: > > cd ${.CURDIR}/..&& ${CROSSMAKE} distrib-dirs > > DESTDIR=${RD}/trees/base > > cd ${.CURDIR}/..&& ${CROSSMAKE} ${WORLD_FLAGS} distributeworld \ > > DISTDIR=${RD}/trees > > sh ${.CURDIR}/scripts/mm-mtree.sh -F "${CROSSENV}" -D > > "${RD}/trees/base" > > touch ${.TARGET} > > > > I use a one-line patch locally to bootstrap etcupdate into the worlds I > > package up at work via a similar one-liner. > > And this is why sending out patches for review is a good idea. I've > updated my code to call into this script, though it would be nice if, > say, make distribution handled this. Thanks for pointing it out. > > >> Test ISOs for amd64 and i386 can be found here: > >> http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110222.iso.bz2 > >> http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110224.iso.bz2 > >> > >> More recent test ISOs, as well as ones for other architectures, may be > >> available at: > >> http://wiki.freebsd.org/BSDInstall > >> > >> Bug reports would be very appreciated at this time. There are three > >> known bugs currently, which will be fixed soon, so please don't report > >> these: error reporting is not graceful if there are no writable disks in > >> the system, you must select at least one optional component, and the doc > >> build is not currently connected to the releases. > >> > >> There are some changes to the distribution format involved in this > >> patch, which are outlined below, and about which I would also appreciate > >> feedback: > >> - The src tree is not split up into pieces (e.g. ssbin) as with sysinstall > > I would at least like to have src split up into two pieces: > > > > 1) would be equivalent of sbase and ssys of old distributions, so you could > > choose to just install kernel sources along with the top-level Makefile bits > > to build kernels. I commonly install this subset on production machines so > > I > > can install a custom kernel in a pinch. > > > > 2) would be everything else in the source tree. > > This is a little bit tricky, since it involves inter-distribution > dependencies which don't currently exist (e.g. you need sbase for ssys > to be useful, and for severythingelse to be useful). I suppose that the > top-level Makefile bits are small and could end up in both archives, > where one can overwrite the other with the same thing. Would that solve > your problem? Hmm, my thinking is ssys would include sbase, and severythingelse would require ssys. That is already true since libc needs syscall.mk from the kernel sources anyway. From a user perspective you end up with three choices: no sources, kernel sources, or all sources. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Request for review/testing: switching the default installer
On 03/02/11 10:06, TAKAHASHI Yoshihiro wrote: In article<4d6bb5e3.6020...@freebsd.org> Nathan Whitehorn writes: BSDinstall has acquired at this point its final form (prior to a future merge with pc-sysinstall), and I believe is ready to replace sysinstall on the 9.0 snapshot ISOs. Barring any objections, I would like to pull this switch 2 weeks from today, on the 14th of March. A patch to the release infrastructure code can be found here (make release must be run with Makefile.bsdinstall using this patch to get non-sysinstall media): http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff In Makefile.bsdinstall: +cdrom: + echo kernel_options=\"-C\"> ${DISTDIR}/release/boot/loader.conf + sh /usr/src/release/${TARGET}/mkisoimages.sh -b FreeBSD_Install ${DISTDIR}/release.iso ${DISTDIR}/release + rm ${DISTDIR}/release/boot/loader.conf ${TARGET} must be ${TARGET_ARCH} because pc98 and sunv4 don't have mkisoimages.sh script. I was thinking of just copying the i386/mkisoimages.sh and making the -G behavior the default. It seems to me to make more sense to use MACHINE than MACHINE_ARCH for this, since pc98 seems to have different requirements than i386. We could just copy the sparc64 install script for sun4v. Do you have a plan to add a floppy support as boot device? Pc98 machines which can boot from CD-ROM are very limited. So we usually use FD for boot media to install. No, I hadn't thought about this. If there aren't any machines you care about that don't have a CD drive at all, we could try a CD-bootloader-on-a-floppy as a solution. I think a totally floppy based install would be very difficult to arrange, however. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Request for review/testing: switching the default installer
In article <4d6bb5e3.6020...@freebsd.org> Nathan Whitehorn writes: > BSDinstall has acquired at this point its final form (prior to a > future merge with pc-sysinstall), and I believe is ready to replace > sysinstall on the 9.0 snapshot ISOs. Barring any objections, I would > like to pull this switch 2 weeks from today, on the 14th of March. > > A patch to the release infrastructure code can be found here (make > release must be run with Makefile.bsdinstall using this patch to get > non-sysinstall media): > http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff In Makefile.bsdinstall: +cdrom: + echo kernel_options=\"-C\" > ${DISTDIR}/release/boot/loader.conf + sh /usr/src/release/${TARGET}/mkisoimages.sh -b FreeBSD_Install ${DISTDIR}/release.iso ${DISTDIR}/release + rm ${DISTDIR}/release/boot/loader.conf ${TARGET} must be ${TARGET_ARCH} because pc98 and sunv4 don't have mkisoimages.sh script. Do you have a plan to add a floppy support as boot device? Pc98 machines which can boot from CD-ROM are very limited. So we usually use FD for boot media to install. --- TAKAHASHI Yoshihiro ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: urtw0: could not allocate USB transfers
On 02/25/2011 07:31, Bernhard Schmidt wrote: On Friday, February 25, 2011 12:47:12 Etienne Robillard wrote: On 25/02/11 06:18 AM, Bernhard Schmidt wrote: On Friday, February 25, 2011 11:03:04 Etienne Robillard wrote: On 25/02/11 04:11 AM, Bernhard Schmidt wrote: On Thursday, February 24, 2011 21:51:23 joseph wrote: Hello, i decided to get my laptop wlan via usb because my internal device isn't supported yet. The usb device is a logilink WL0006 unit its vendorid is 0x0bda and the productid says 0x8187. My search results say that this device depends on a RTL8187 chipset. I tried both, load the kernel module at boot time and compile kernel withe urtw, but i get the same output at dmesg device_attach: urtw0 attach returned 6 urtw0: on usbus3 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE device_attach: urtw0 attach returned 6 im running FreeBSD 8.1-RELEASE-p2 amd64. What might be the reason for this error? Thanks for all hints. Well, I have no clue about USB.. but this smells like one of the endpoints is 'not there'. At least I can't find any reference to it in the Linux driver. Wanna give attached patch a shot? Hi Bernard, For rt287x based cards, you can try using rt28700 chipset instead of urtw0 on FreeBSD 8. The former is not in the stable src tree, but could be retrieved from here: https://gthc.org/distfiles/freebsd/rt2870_fbsd8.tar.gz Any takers to make module rt28700 (if_rt2870) officially part of the FreeBSD src tree? I'm a bit confused now, shouldn't the rt2870 be supported by run(4)? On a site-note, this is Ralink chipset not a Realtek one. I believe this is a different implementation for RT8187 usb network adapters than run(4). However in my view I found urtw0 buggy, but would certainly take a look at run(4) to compare the results with wireless networking agaisnt the other driver (rt28700). Yeah, urtw(4) has a few flaws.. - urtw(4): Realtek RTL8187B/RTL8187L - rum(4): Ralink RT2501/RT2601 - run(4): Ralink RT2700/RT2800/RT3000 So it seems the driver you've posted conflicts with run(4). From a quick glance at it, it seems to support 11n? If so, can I talk you into working on getting those bits merged? Thanks! -- Bernhard X-UID: 10549 Status: X-Keywords: Content-Length: 0 I forwarded this thread on -current. Please also find below a stack trace produced with option KDB_UNATTENDED for the rt28700 driver (if_rt28700). On another side note, I have not being able to load the runfw firmware module anymore after having updated the src tree for 8.2-STABLE ? $ sudo kldload /boot/kernel/runfw.ko kldload: can't load /boot/kernel/runfw.ko: Exec format error $ objdump -x /boot/kernel/runfw.ko /boot/kernel/runfw.ko: file format elf64-x86-64 /boot/kernel/runfw.ko architecture: i386:x86-64, flags 0x0011: HAS_RELOC, HAS_SYMS start address 0x Sections: Idx Name Size VMA LMA File off Algn 0 .text 0056 0040 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .rodata.str1.1 001f 0096 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 set_modmetadata_set 0020 00b8 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 3 set_sysinit_set 0008 00d8 2**3 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 4 .data 20d4 00e0 2**4 CONTENTS, ALLOC, LOAD, RELOC, DATA 5 .bss 21b4 2**2 ALLOC 6 .comment 0026 21b4 2**0 CONTENTS, READONLY SYMBOL TABLE: ld .text ld .rodata.str1.1 ld .data l F .text 0056 runfw_fw_modevent l O set_modmetadata_set0008 __set_modmetadata_set_sym__mod_metadata_md_runfw_fw_on_firmware 2000 l O .data 0018 _mod_metadata_md_runfw_fw_on_firmware 0008 l O set_modmetadata_set0008 __set_modmetadata_set_sym__mod_metadata_runfw_fw_version 2020 l O .data 0018 _mod_metadata_runfw_fw_version l O set_sysinit_set0008 __set_sysinit_set_sym_runfw_fwmodule_sys_init 2040 l O .data 0018 runfw_fwmodule_sys_init 0010 l O set_modmetadata_set0008 __set_modmetadata_set_sym__mod_metadata_md_runfw_fw 2060 l O .data 0018 _mod_meta
Re: svn commit: r219178 - head/sys/crypto/aesni
On Wed, Mar 02, 2011 at 02:56:58PM +, Konstantin Belousov wrote: > Author: kib > Date: Wed Mar 2 14:56:58 2011 > New Revision: 219178 > URL: http://svn.freebsd.org/changeset/base/219178 > > Log: > Fix a bug in the result of manual assembly. > > Reported by:Stefan Grundmann > PR: kern/155118 > MFC after: 3 days The end result of this bug should affect only AES256 variants, causing wrong keyschedule calculation. If you have a geli partition with 256bit key that worked with previous version of aesni(4), best strategy is backup, reinitialize geli volume with the new driver, then restore. Sorry. > > Modified: > head/sys/crypto/aesni/aeskeys_amd64.S > head/sys/crypto/aesni/aeskeys_i386.S > > Modified: head/sys/crypto/aesni/aeskeys_amd64.S > == > --- head/sys/crypto/aesni/aeskeys_amd64.S Wed Mar 2 14:39:26 2011 > (r219177) > +++ head/sys/crypto/aesni/aeskeys_amd64.S Wed Mar 2 14:56:58 2011 > (r219178) > @@ -162,7 +162,7 @@ ENTRY(aesni_set_enckey) > .byte 0x66,0x0f,0x3a,0xdf,0xc8,0x20 > call_key_expansion_256b > // aeskeygenassist $0x40,%xmm2,%xmm1 # round 7 > - .byte 0x66,0x0f,0x3a,0xdf,0xca,0x20 > + .byte 0x66,0x0f,0x3a,0xdf,0xca,0x40 > call_key_expansion_256a > retq > .Lenc_key192: > > Modified: head/sys/crypto/aesni/aeskeys_i386.S > == > --- head/sys/crypto/aesni/aeskeys_i386.S Wed Mar 2 14:39:26 2011 > (r219177) > +++ head/sys/crypto/aesni/aeskeys_i386.S Wed Mar 2 14:56:58 2011 > (r219178) > @@ -167,7 +167,7 @@ ENTRY(aesni_set_enckey) > .byte 0x66,0x0f,0x3a,0xdf,0xc8,0x20 > call_key_expansion_256b > // aeskeygenassist $0x40,%xmm2,%xmm1 # round 7 > - .byte 0x66,0x0f,0x3a,0xdf,0xca,0x20 > + .byte 0x66,0x0f,0x3a,0xdf,0xca,0x40 > call_key_expansion_256a > .cfi_adjust_cfa_offset -4 > leave pgpzHhVAf80vY.pgp Description: PGP signature
Re: Request for review/testing: switching the default installer
On 02/28/11 09:20, John Baldwin wrote: On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote: BSDinstall has acquired at this point its final form (prior to a future merge with pc-sysinstall), and I believe is ready to replace sysinstall on the 9.0 snapshot ISOs. Barring any objections, I would like to pull this switch 2 weeks from today, on the 14th of March. A patch to the release infrastructure code can be found here (make release must be run with Makefile.bsdinstall using this patch to get non-sysinstall media): http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff Hmm, does your installed world include the pre-built mergemaster database? That should really be preserved. It happens here in the old release Makefile: # Install the system into the various distributions. release.2: cd ${.CURDIR}/..&& ${CROSSMAKE} distrib-dirs DESTDIR=${RD}/trees/base cd ${.CURDIR}/..&& ${CROSSMAKE} ${WORLD_FLAGS} distributeworld \ DISTDIR=${RD}/trees sh ${.CURDIR}/scripts/mm-mtree.sh -F "${CROSSENV}" -D "${RD}/trees/base" touch ${.TARGET} I use a one-line patch locally to bootstrap etcupdate into the worlds I package up at work via a similar one-liner. And this is why sending out patches for review is a good idea. I've updated my code to call into this script, though it would be nice if, say, make distribution handled this. Thanks for pointing it out. Test ISOs for amd64 and i386 can be found here: http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110222.iso.bz2 http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110224.iso.bz2 More recent test ISOs, as well as ones for other architectures, may be available at: http://wiki.freebsd.org/BSDInstall Bug reports would be very appreciated at this time. There are three known bugs currently, which will be fixed soon, so please don't report these: error reporting is not graceful if there are no writable disks in the system, you must select at least one optional component, and the doc build is not currently connected to the releases. There are some changes to the distribution format involved in this patch, which are outlined below, and about which I would also appreciate feedback: - The src tree is not split up into pieces (e.g. ssbin) as with sysinstall I would at least like to have src split up into two pieces: 1) would be equivalent of sbase and ssys of old distributions, so you could choose to just install kernel sources along with the top-level Makefile bits to build kernels. I commonly install this subset on production machines so I can install a custom kernel in a pinch. 2) would be everything else in the source tree. This is a little bit tricky, since it involves inter-distribution dependencies which don't currently exist (e.g. you need sbase for ssys to be useful, and for severythingelse to be useful). I suppose that the top-level Makefile bits are small and could end up in both archives, where one can overwrite the other with the same thing. Would that solve your problem? -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Capsicum merge in progress (was: Re: Capsicum -- 9.x merge in sight)
On Sat, 22 Jan 2011, Robert Watson wrote: Jon and my current plan is to merge, over the next few months, various kernel features required to support Capscium sandboxing for FreeBSD 9.0: first capability mode support (this week), then capabilities themselves (which are a form of file descriptor in Capsicum), followed by process descriptors (a file descriptor alternative to process IDs that may be used by supporting applications). The current plan is *not* to merge libcapsicum, a userspace library used by certain applications to construct sandboxes, as we feel the API remains insufficiently mature at this point. However, the Capsicum system calls can still be used directly by applications, including Chromium. We would distribute libcapsicum as a package alongside 9.0, just not as a supported OS API for the time being. FYI: Jon and I have now started the merge; I committed basic kernel capability mode support yesterday (cap_enter(2), cap_getmode(2), new errno values, capabilities.conf). Over the next few weeks we'll merge man pages, additional kernel support for capability mode and capabilities, including delegated file system subtrees in capability mode, cap_new(2) and friends, process descriptors, and so on. Kernel support for these features will remain conditional on compiling in options CAPABILITIES (and later options PROCDESC) for the time being. Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fwd: OpenSSL 1.0.0d for Freebsd HEAD
On Wed, Mar 02, 2011 at 10:58:00AM +0100, Alexandre Martins wrote: > Hello, > > This sound great :) > > SIGILL is raised when the program try to execute an assembly code that the > CPU > cannot execute. It mean that the library or the binary is miscompiled. > Not necessarily, the sparc64 code f.e. also kills programs with SIGILL when they corrupt overflow their stack or the stack pointer is courrupt. Marius ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fwd: OpenSSL 1.0.0d for Freebsd HEAD
Hello, This sound great :) SIGILL is raised when the program try to execute an assembly code that the CPU cannot execute. It mean that the library or the binary is miscompiled. Regards, On Tuesday 01 March 2011 20:20:58 Marius Strobl wrote: > On Tue, Mar 01, 2011 at 10:31:16AM +0100, Alexandre Martins wrote: > > Dear, > > > > Have you extracted the tarball fo openssl source (1.0.0d) in > > crypto/openssl ? > > Ah, I missed that, the last couple of mails in this thread were only > talking about the patch :) > With the tarball untared it actually builds and works on sparc64 as > far as ssh(d) and HTTPS via fetch are concerned. The problem reports > (programs getting killed with SIGILL probably due to an infinite > recursion or some such) were about apache and unbound using an > OpenSSL 1.0.0 port. I'm not sure whether their use of OpenSSL would > make a difference or the port is broken. > > Marius -- Alexandre Martins NETASQ signature.asc Description: This is a digitally signed message part.
Re: [TESTING]: boot2 changes
On Wed, Mar 02, 2011 at 02:28:54AM +, Alexander Best wrote: > On Mon Feb 28 11, Roman Divacky wrote: > > hi there, > > > > I have a patch that shrinks boot2 some: > > > > 1) it switches kname to be just a pointer instead of an array > >thus avoiding a couple of memcpy()s > > > > 2) it changes ioctl to unsigned from uint8_t > > > > 3) it changes the first keyhit limit to 5 seconds from 3 > >so that constant propagation can take place > > > > 4) it changes the ticks overflow computation as suggested by bde@ > > > > 5) it removes bi_basemem/bi_extmem/bi_memsizes_valid setting from > >bootinfo as it is unused > > > > > > the patch: > > > > http://lev.vlakno.cz/~rdivacky/boot2-almost-there-diet.patch > > > > It works for me and I'd like you to review/test this patch > > did you also take a look at the code in sys/boot/i386/common? many functions > in > sys/boot/i386/boot2/boot2.c are also defined there and some seem to contain > improved code. > > e.g. was the return type of xputc() changed from int to void, i think that's > quite a resonable change and might reduce the boot2 binary size further. I have some more experimental changes locally, and I am working on that, dont worry :) roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"