Re: [Testing wanted] USB patch for HAL
Here are some of the results from testing based on your instructions and
patches in IRC earlier today.
First, per your instructions, I removed sg by modifying
/usr/src/sys/conf/files and rebuilding the kernel:
--- files.orig 2011-06-25 16:26:46.0 -0500
+++ files 2011-06-25 16:26:58.0 -0500
@@ -127,3 +127,2 @@
cam/scsi/scsi_ses.coptional ses
-cam/scsi/scsi_sg.c optional sg
cam/scsi/scsi_targ_bh.coptional targbh
Curiously, with this change, /dev/sg0 was still created and sg0 still
appeared in `camcontrol devlist`, but things were better. hald still
stopped working after the first detach, but was not unkillable and started
working again after it was restarted. And whether or not hald was
restarted, the USB bus no longer wedged and continued to work properly.
Next, leaving the above patch in place, I rebuilt the kernel with the
patch you provided for /usr/src/sys/cam/cam_xpt.c:
--- cam_xpt.c 2011-06-26 00:16:44.0 +0200
+++ cam_xpt.c 2011-06-26 00:16:13.0 +0200
@@ -3592,6 +3592,9 @@
xpt_free_ccb(free_ccb);
sim->ccb_count--;
} else {
+ /* reset private data */
+ memset(&free_ccb->ccb_h.periph_priv, 0,
sizeof(free_ccb->ccb_h.periph_priv));
+
SLIST_INSERT_HEAD(&sim->ccb_freeq, &free_ccb->ccb_h,
xpt_links.sle);
}
With this change, the USB bus continued to operate as expected while
attaching and detaching a USB flash drive. On start up, hald was not
detecting the attach/detach events, but started working and kept working
after restarting it. In summary, with both of the above changes,
everything worked pretty much correctly.
I know this is still inconclusive, but I wanted to report what I had so
far. After I get some sleep, I'll proceed with trying to get the back
traces inside cam_periph_release_locked that you asked for.
--
Greg Rivers
___
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: sys/boot/i386/boot2 (install) fail
On 06/24/2011 13:39, Doug Barton wrote: On r223514M, kernel installed Ok, then after reboot and attempt to installworld I first get a failure that "btxld" is not found. So I add that to ITOOLS and then I get this. Any ideas? Building again with a clean /usr/obj "solved" this problem, FYI. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules]
2011/6/26 Hans Petter Selasky : > Hi, > > I see that a lot of PCI device drivers use code to check their ID's. > > [...] I seem to recall devd doesn't process PCI because it is event-driven and there are no "events" associated with PCI cards. Perhaps it could be modified to scan for PCI cards via libpci on initialization and generate "fake" events for them? -- Robert Millan ___ 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: [Testing wanted] USB patch for HAL
On Sunday 26 June 2011 09:27:22 Greg Rivers wrote: > With this change, the USB bus continued to operate as expected while > attaching and detaching a USB flash drive. On start up, hald was not > detecting the attach/detach events, but started working and kept working > after restarting it. In summary, with both of the above changes, > everything worked pretty much correctly. Try this patch to hald: cd /usr/ports/sysutils/hal/files fetch http://hselasky.homeunix.org:8192/patch-hald_freebsd_hf-usb2.c cd .. make all deinstall install clean --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"
Re: LLVM: llvm-as, llvm-ld and so on not contained in FreeBSD core contrib?
On 2011-06-25 17:53, Hartmann, O. wrote:
On 06/25/11 10:10, Roman Divacky wrote:
On Sat, Jun 25, 2011 at 09:57:52AM +0200, Hartmann, O. wrote:
Hello.
Just for my couriosity: I'm missing llvm-as, llvm-ld and other binutils
from LLVM and was wondering why they are contained in the port's llvm
collection but not in FreeBSD's source contribution.
There's no use for these utilities in FreeBSD base system.
I build FreeBSD 9 with CLANG. But as a missing llvm-as and llvm-ld (or
llvm-ar) would imply, the binaries are generated via binutils from
theGNU suite, aren't they?
llvm-{as,ld,ar} are not replacements for those from binutils. llvm-*
work on the llvm bitcode only and are of no use for normal object
files.
dim@ made a patch that adds those utilities if you really need them
http://lists.freebsd.org/pipermail/freebsd-toolchain/2011-June/000216.html
By default when you compile things with clang it uses its own assembler
(ie. it goes directly from C -> .o) so typically only gnu ld is used
in the compilation chain.
roman
Thank you very much. Patched and works.
What's the general opinion on applying this to -current? Otherwise
it'll be sitting in my private tree, possibly bit-rotting. :) For
people that are experimenting with llvm and/or clang, these additional
tools might sometimes come in handy.
For normal users, it won't have any impact, except for a few extra
source files in the tree. These tools will not be built by default.
___
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: [Testing wanted] USB patch for HAL
On Sun, 26 Jun 2011, Hans Petter Selasky wrote: On Sunday 26 June 2011 09:27:22 Greg Rivers wrote: With this change, the USB bus continued to operate as expected while attaching and detaching a USB flash drive. On start up, hald was not detecting the attach/detach events, but started working and kept working after restarting it. In summary, with both of the above changes, everything worked pretty much correctly. Try this patch to hald: cd /usr/ports/sysutils/hal/files fetch http://hselasky.homeunix.org:8192/patch-hald_freebsd_hf-usb2.c cd .. make all deinstall install clean With this patch, and the CAM patches still in place, the USB bus works fine, but hald never sees any attach/detach events, even after restarting it. I reverted the CAM patches and tested again with the same result. So this patch to hald does stop the CAM sg errors, and prevents the USB from wedging. It just doesn't detect attach events. -- Greg Rivers ___ 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: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules]
On Jun 26, 2011, at 4:33 AM, Robert Millan wrote: > 2011/6/26 Hans Petter Selasky : >> Hi, >> >> I see that a lot of PCI device drivers use code to check their ID's. >> >> [...] > > I seem to recall devd doesn't process PCI because it is event-driven and > there are no "events" associated with PCI cards. That's totally false. > Perhaps it could be modified to scan for PCI cards via libpci on > initialization > and generate "fake" events for them? Since your premise is false, this solution also is false. Devices are handled in a completely uniform manner in the system. When they attach, an attach even is generated. When they detach, a detach event is generated. When there is no driver attached after the probe/attach sequence, a NOMATCH event is generated. Events are queued up during the early boot process until devd can run. They are then processed in order. Devices that haven't had a driver attach to them would be processed when devd had a chance to start. Warner ___ 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"
Build failure during 9-CURRENT make world
Hi all, Just trying to install 9-CURRENT (csupped today) for my Xbox. What I did: mounted all partitions under /mnt cd /usr/cursrc/src make KERNCONF=CERBERUS DESTDIR=/mnt world kernel *chug chug* ===> usr.bin/clang/clang (all) c++ -O2 -pipe -I/usr/cursrc/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/cursrc/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/cursrc/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/usr/cursrc/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd9.0\" -fstack-protector -fno-exceptions -fno-rtti -o clang cc1_main.o cc1as_main.o driver.o /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontendtool/libclangfrontendtool.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver/libclangdriver.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangserialization/libclangserialization.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/libclangparse.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/libclangsema.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangstaticanalyzerfrontend/libclangstaticanalyzerfrontend.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangstaticanalyzercheckers/libclangstaticanalyzercheckers.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangstaticanalyzercore/libclangstaticanalyzercore.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysis/libclanganalysis.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangindex/libclangindex.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangrewrite/libclangrewrite.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangast/libclangast.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/libclanglex.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/libllvmipo.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvminstrumentation/libllvminstrumentation.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/libllvmbitreader.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparser/libllvmasmparser.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmdisassembler/libllvmarmdisassembler.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmparser/libllvmarmasmparser.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcodegen/libllvmarmcodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminstprinter/libllvmarminstprinter.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminfo/libllvmarminfo.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscodegen/libllvmmipscodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpccodegen/libllvmpowerpccodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinstprinter/libllvmpowerpcinstprinter.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcinfo.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86disassembler/libllvmx86disassembler.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmparser/libllvmx86asmparser.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86codegen/libllvmx86codegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmselectiondag/libllvmselectiondag.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprinter/libllvmasmprinter.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmmcparser/libllvmmcparser.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmscalaropts/libllvmscalaropts.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvminstcombine/libllvminstcombine.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmtransformutils/libllvmtransformutils.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmipa/libllvmipa.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmanalysis/libllvmanalysis.a /usr/ob
Re: Build failure during 9-CURRENT make world
On 2011-06-26 20:43, Chris Rees wrote: ... cd /usr/cursrc/src make KERNCONF=CERBERUS DESTDIR=/mnt world kernel ... /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a: could not read symbols: File format not recognized ... Any ideas please??? The file /usr/obj/cursrc/src/lib/clang/libllvmcodegen/libllvmcodegen.a is busted, for some reason. My guess would be that you built it for a different architecture. You can try removing it, and building again, or if you want to use brute force, zap your entire /usr/obj and rebuild. ___ 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: LLVM: llvm-as, llvm-ld and so on not contained in FreeBSD core contrib?
On 06/26/11 15:42, Dimitry Andric wrote:
On 2011-06-25 17:53, Hartmann, O. wrote:
On 06/25/11 10:10, Roman Divacky wrote:
On Sat, Jun 25, 2011 at 09:57:52AM +0200, Hartmann, O. wrote:
Hello.
Just for my couriosity: I'm missing llvm-as, llvm-ld and other
binutils
from LLVM and was wondering why they are contained in the port's llvm
collection but not in FreeBSD's source contribution.
There's no use for these utilities in FreeBSD base system.
I build FreeBSD 9 with CLANG. But as a missing llvm-as and llvm-ld (or
llvm-ar) would imply, the binaries are generated via binutils from
theGNU suite, aren't they?
llvm-{as,ld,ar} are not replacements for those from binutils. llvm-*
work on the llvm bitcode only and are of no use for normal object
files.
dim@ made a patch that adds those utilities if you really need them
http://lists.freebsd.org/pipermail/freebsd-toolchain/2011-June/000216.html
By default when you compile things with clang it uses its own assembler
(ie. it goes directly from C -> .o) so typically only gnu ld is used
in the compilation chain.
roman
Thank you very much. Patched and works.
What's the general opinion on applying this to -current? Otherwise
it'll be sitting in my private tree, possibly bit-rotting. :) For
people that are experimenting with llvm and/or clang, these additional
tools might sometimes come in handy.
For normal users, it won't have any impact, except for a few extra
source files in the tree. These tools will not be built by default.
I can only speak for myself and several people of my department, which
are doing experiments with LLVM.
It is nice to have the knob building the missing tools on demand (should
be documented anywhere). I like it and I appreciate your work.
Oliver
___
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: Build failure during 9-CURRENT make world
On 26 June 2011 19:55, Dimitry Andric wrote: > On 2011-06-26 20:43, Chris Rees wrote: > ... >> >> cd /usr/cursrc/src >> make KERNCONF=CERBERUS DESTDIR=/mnt world kernel > > ... >> >> >> /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a: >> could not read symbols: File format not recognized > > ... >> >> Any ideas please??? > > The file /usr/obj/cursrc/src/lib/clang/libllvmcodegen/libllvmcodegen.a > is busted, for some reason. My guess would be that you built it for a > different architecture. You can try removing it, and building again, or > if you want to use brute force, zap your entire /usr/obj and rebuild. > I thought I'd tried that... Turns out I hadn't! The file was corrupted presumably because of a disk full error that I had since corrected. I hang my head in shame accordingly. Thanks, Chris ___ 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: MFC
On Fri, 24 Jun 2011 15:03:50 +0300 Andriy Gapon wrote: > on 24/06/2011 14:44 Johan Hendriks said the following: > > Hello all i have a question regarding MFC > > > > At the svn page from head most revisions comments contain a line > > like MFC after:x weeks or x days. or x months. > > Is this done automaticly, or is this still done by the auther. > > It's done manually. 'MFC after' only states original intent. > Sometimes developers forget to do MFC; sometimes they discover new > circumstances which prevent MFC; etc. As there is an automatic reminder-mail to the developer when the MFC time is triggered, I would not say the developer forgets, it's more that he hasn't the time for it or he voluntary deletes the mail before MFCing (for whatever reason, a showstopper issue may be one of the possible reasons). Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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"
/var/crash permissions
the FreeBSD Developers' Handbook recommends /var/crash to have drwx-- permissions [1]. ``make installworld'' alters those permissions to drwxr-x---. one of the two is trolling. which one? [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN ___ 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: /var/crash permissions
On Sun, Jun 26, 2011 at 11:33:00PM +0200, deeptec...@gmail.com wrote: > the FreeBSD Developers' Handbook recommends /var/crash to have > drwx-- permissions [1]. ``make installworld'' alters those > permissions to drwxr-x---. one of the two is trolling. which one? > > [1] > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN It used to be that the permissions were as stated in the handbook but were changed to allow access to the directory by those in group wheel. But as the files that are still created in that directory are still created with a umask of 077 the directories mode being 750 doesnt make any sense as the files there are still not readable by anyone but root owned processes. At this time I would say that the handbook should be changed to reflect its current mode of 750 since its easy to alter the contained files than it is for a user to mess with mtree permissions if they want wheel users to have access to that directory. ___ 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"
Clang buildworld failure due to multiple definitions of __isnanf
I've both seen reports and experienced make buildworld with clang failing in usr.bin/xlint/lint1 (really, make kernel-toolchain is what fails), because lint1 is statically linked, and there is a definition of __isnanf in both libc and libm. GCC, on the other hand, builds just fine. The file tree.c in usr.bin/xlint/lint1 calls both isnan and finite from math.h. After some investigation, I figured out what's going on. math.h includes a macro version of isnan, which expands out to an expression that calls isnan, __isnanl, and __isnanf. GCC seems to treat all of these as builtin functions, and implements them with its code generator, rather than generating calls. Clang, on the other hand, does not, which leaves calls to __isnanf in the resulting object file, which will result in multiple definitions at link time. There are several possible solutions. The workaround I used is to add -Wl,--allow-multiple-definition to LDADD in the makefile for xlint. A better solution, I think, is to modify math.h with something like this: #ifdef __clang__ #define isnan(n) __builtin_isnan(n) ... #endif (It might be a good idea to add these kinds of definitions for all of clang's builtins, actually.) Anyway, I hope this helps someone. PS. Sorry I don't have build logs, assembler output, etc. My FreeBSD machine's wireless card isn't supported (yet). -- Eric McCorkle Computer Science Ph.D Student, University of Massachusetts Research Intern, IBM Research ___ 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: Clang buildworld failure due to multiple definitions of __isnanf
On Sun, Jun 26, 2011 at 10:32:02PM -0400, Eric McCorkle wrote: > > A better solution, I think, is to modify math.h with something like this: > > #ifdef __clang__ > #define isnan(n) __builtin_isnan(n) > ... > #endif Please, no. Don't touch math.h. -- Steve ___ 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: [Testing wanted] USB patch for HAL
Sorry for slightly off-topic post but (see below) On Sun, 26 Jun 2011, Greg Rivers wrote: On Sun, 26 Jun 2011, Hans Petter Selasky wrote: On Sunday 26 June 2011 09:27:22 Greg Rivers wrote: With this change, the USB bus continued to operate as expected while attaching and detaching a USB flash drive. On start up, hald was not detecting the attach/detach events, but started working and kept working after restarting it. In summary, with both of the above changes, everything worked pretty much correctly. Try this patch to hald: cd /usr/ports/sysutils/hal/files fetch http://hselasky.homeunix.org:8192/patch-hald_freebsd_hf-usb2.c cd .. make all deinstall install clean With this patch, and the CAM patches still in place, the USB bus works fine, but hald never sees any attach/detach events, even after restarting it. I reverted the CAM patches and tested again with the same result. So this patch to hald does stop the CAM sg errors, and prevents the USB from wedging. It just doesn't detect attach events. -- Greg Rivers ___ I'm fairly aware this would be only a workaround rather than a proper solution but isn't it enough to just tell hald to ignore /dev/sg*? What I did was put into /usr/local/etc/hal/fdi/preprobe an fdi I've spotted some time ago (sorry can't recall the original URL) and so far everything works with patched HAL but without any changes to kernel. amd64-CURRENT, desktop, USB mouse and storage devices (flash and HDD). Hope this helps (and sorry for OT again), Vladimir 30-ignore-sg.fdi true true true ___ 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"
