Re: policy on GPL'd drivers?
On Tue, May 27, 2003 at 10:23:04AM -0400, Alexander Kabaev wrote: On Tue, 27 May 2003 07:20:17 -0700 Steve Kargl [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 08:45:29AM -0400, Alexander Kabaev wrote: On Tue, 27 May 2003 14:36:26 +0200 I and no doubt many others will insist on keeping GPLed drivers out of the tree. I have no objections for this drivers to be confined in ports though. kargl[205] ls /sys/gnu/dev/sound/pci csaimg.h* emu10k1-ac97.h emu10k1.h maestro3_dsp.h maestro3_reg.h The maestro3 driver is in the tree and is covered by the GPL for the same reasons that David will need to GPL the FreeBSD version of the nForce driver. -- Steve This doesn't mean it is an open season for contaminating the tree with GPL. Nobody said so. But this is a policy set by core.. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 10:40AM, Alexander Kabaev [EMAIL PROTECTED] wrote: On Tue, 27 May 2003 10:32:42 -0500 David Leimbach [EMAIL PROTECTED] wrote: Ugh... the network driver portion of the nforce drivers is *not* GPL'd but it has a linux only and anti-reverse engineeing clause. Dave Then using the diver on FreeBSD will be a NVidia's license violation, wouldn't it? One more reason to keep it out of the tree. Just the network driver... the audio driver in the tarball is still GPL'd. Either which way I doubt either driver will go into the tree. I don't see any good reason to stick any of it in the kernel unless its absolutely necessary. I am not a religious person when it comes to licensing. I just don't like GPL style restrictions. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Buildkernel broken
Hello, I cvsupped the source this morning and I get: [...] === firewire/firewire cc -O -pipe -march=pentium2 -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/dev/firewire/firewire.c cc -O -pipe -march=pentium2 -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/dev/firewire/fwohci.c In file included from /usr/src/sys/dev/firewire/fwohci.c:72: @/dev/firewire/fwdma.h:38: redefinition of `bus_dmasync_op_t' machine/bus_dma.h:94: `bus_dmasync_op_t' previously declared here *** Error code 1 [...] Krzysztof ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Buildkernel broken
-Original Message- From: Krzysztof Parzyszek [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2003 11:50 AM To: [EMAIL PROTECTED] Subject: Buildkernel broken Hello, I cvsupped the source this morning and I get: [...] === firewire/firewire cc -O -pipe -march=pentium2 -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/dev/firewire/firewire.c cc -O -pipe -march=pentium2 -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/dev/firewire/fwohci.c In file included from /usr/src/sys/dev/firewire/fwohci.c:72: @/dev/firewire/fwdma.h:38: redefinition of `bus_dmasync_op_t' machine/bus_dma.h:94: `bus_dmasync_op_t' previously declared here *** Error code 1 [...] I have the exact same problem. I think it has something to do with a commit from this morning. I commented out the offending #define in fwdma.h and the module compiles fine now. -Will ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tue, 27 May 2003 10:49:40 -0500 David Leimbach [EMAIL PROTECTED] wrote: On Tuesday, May 27, 2003, at 10:40AM, Alexander Kabaev [EMAIL PROTECTED] wrote: On Tue, 27 May 2003 10:32:42 -0500 David Leimbach [EMAIL PROTECTED] wrote: Ugh... the network driver portion of the nforce drivers is *not* GPL'd but it has a linux only and anti-reverse engineeing clause. Dave Then using the diver on FreeBSD will be a NVidia's license violation, wouldn't it? One more reason to keep it out of the tree. Just the network driver... the audio driver in the tarball is still GPL'd. Well, network driver is a special case as it is this weird binary 'kernel' + OS shim combination which is getting popular lately. Have you thought about getting NVidia's permission to link non-GPLed shims with their binary object? A quick scan through NVidia audio driver sources suggests that the device is very similar to Intel ICH2 AC'97-based cards. Should you see is BSD-led ich.c driver can be reused instead of the Linux driver? -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
Alexander Kabaev wrote: Wilko Bulte [EMAIL PROTECTED] wrote: Yes, see for example the GPL_ed floating point emulator. Aside: I thought the license had been changed on this? I and no doubt many others will insist on keeping GPLed drivers out of the tree. I have no objections for this drivers to be confined in ports though. So will anyone with lawyers who wants to distribute a precompiled kernel binary. Since the console will work without the driver statically compiled into the kernel, a kernel module is really the best course of action for something like this, so that a kernel with, for example, licensed proprietary ISDN drivers, or the proprietary licensed OSS sound drivers, can still use the driver without a license conflict. Remember that's it's legal to to distribute seperate binaries, as long as you comply with the GPL for the GPL'ed binary, but it's a violation of clause 6(b) of the GPL to combine them into one binary and distribute them, if you are legally obligated to not give out the source code for the non-GPL'ed portion. And since the only thing that gives you the right to use the code in the first place is the license... -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
. Well, network driver is a special case as it is this weird binary 'kernel' + OS shim combination which is getting popular lately. Have you thought about getting NVidia's permission to link non-GPLed shims with their binary object? I have thought about it... but don't know enough to pursue it at the moment. I am quite the amatuer... A quick scan through NVidia audio driver sources suggests that the device is very similar to Intel ICH2 AC'97-based cards. Should you see is BSD-led ich.c driver can be reused instead of the Linux driver? From the release notes: the audio driver is based on the open source i810 audio driver but has been modified to work with NVIDIA hardware. I don't want to guess how much modification will be needed to make the nvidia one work. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
Remember that's it's legal to to distribute seperate binaries, as long as you comply with the GPL for the GPL'ed binary, but it's a violation of clause 6(b) of the GPL to combine them into one binary and distribute them, if you are legally obligated to not give out the source code for the non-GPL'ed portion. And since the only thing that gives you the right to use the code in the first place is the license... IANAL but I think the GPL has provisions for binaries that contain code that is not necessarily dependant but merely aggregated into one package. Still I agree... it must be a module for more than one very good reason :). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Buildkernel broken
Date: Tue, 27 May 2003 12:17:18 -0400 From: Will Saxon [EMAIL PROTECTED] I cvsupped the source this morning and I get: [...] === firewire/firewire ... In file included from /usr/src/sys/dev/firewire/fwohci.c:72: @/dev/firewire/fwdma.h:38: redefinition of `bus_dmasync_op_t' machine/bus_dma.h:94: `bus_dmasync_op_t' previously declared here *** Error code 1 [...] I have the exact same problem. I think it has something to do with a commit from this morning. I commented out the offending #define in fwdma.h and the module compiles fine now. I decided to go ahead and hack the code a bit (on my tree); the following patch (relaative to /usr/src) seems to work for me: Index: sys/dev/firewire/fwdma.h === RCS file: /cvs/freebsd/src/sys/dev/firewire/fwdma.h,v retrieving revision 1.1 diff -u -r1.1 fwdma.h --- sys/dev/firewire/fwdma.h17 Apr 2003 03:38:02 - 1.1 +++ sys/dev/firewire/fwdma.h27 May 2003 16:14:57 - @@ -34,7 +34,7 @@ * $FreeBSD: src/sys/dev/firewire/fwdma.h,v 1.1 2003/04/17 03:38:02 simokawa Exp $ */ -#if __FreeBSD_version = 500111 +#if (__FreeBSD_version = 500111) (__FreeBSD_version 500113) typedef int bus_dmasync_op_t; #endif Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Based on what I have seen to date, the use of Microsoft products is not consistent with reliability. I recommend FreeBSD for reliable systems. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD V5.0 and USB to Serial on Toshiba Satellite 1110
My Notebook (Toshiba Satellite 1110) does not have serial ports, so I wanted to connect a serial adapter. The adapter is recognized (see below), but I can't access any of the serial ports: [EMAIL PROTECTED] minicom minicom: cannot open /dev/ucom0: Device not configured [EMAIL PROTECTED] [EMAIL PROTECTED] cu -l ucom0 /dev/ucom0: Device not configured link down [EMAIL PROTECTED] cu -l ucom1 /dev/ucom1: Device not configured link down [EMAIL PROTECTED] I will be happy about any hint! (the USB-mouse is working flawless!) R. Kaestner -- Configuration data: [EMAIL PROTECTED] uname -a FreeBSD sat 5.0-RELEASE-p7 FreeBSD 5.0-RELEASE-p7 #0: Sun May 25 14:02:46 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/RFK i386 [EMAIL PROTECTED] /boot/device.hints: = # rfk: Versuch USB: (just one of my attempts to get things running) hint.uftdi.0.at=uhub hint.uftdi.0.disabled=0 hint.ucom.0.at=uftdi hint.ucom.0.disabled=0 [EMAIL PROTECTED] tail -f /var/log/messages === May 26 13:05:38 sat kernel: uhub2: Texas Instruments TUSB2046 hub, class 9/0, rev 1.10/1.25, addr 2 May 26 13:05:38 sat kernel: uhub2: 4 ports with 4 removable, bus powered May 26 13:05:40 sat kernel: ucom0: FTDI USB FAST SERIAL ADAPTER, rev 1.10/2.00, addr 3 May 26 13:05:40 sat kernel: ucom1: FTDI USB FAST SERIAL ADAPTER, rev 1.10/2.00, addr 4 May 26 13:10:34 sat kernel: uhub2: at uhub1 port 2 (addr 2) disconnected May 26 13:10:34 sat kernel: ucom0: detached May 26 13:10:34 sat kernel: ucom1: detached May 26 13:10:34 sat kernel: uhub2: detached excerpt from /usr/src/sys/i386/conf/RFK = # USB support device uhci # UHCI PCI-USB interface device ohci # OHCI PCI-USB interface device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # Human Interface Devices device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires mii device aue # ADMtek USB ethernet device cue # CATC USB ethernet device kue # Kawasaki LSI USB ethernet # aus LINT: device umodem device ucom device uftdi device uplcom device ubsa device uvscom device uvisor device ufm (NOTE: scbus and da are also configured) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday, May 27, 2003, at 01:40PM, David O'Brien [EMAIL PROTECTED] wrote: On Tue, May 27, 2003 at 07:43:15AM -0500, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Depending on the functionality the driver provides, and the kernel API's it uses; having it as a port may be impractical. The driver probably needs to change with the kernel and that is hard to handle as a port. I agree it could get sticky. But a patch or series of patches per kernel delta [as needed] may not be so bad. There has to be a fairly simple way to map the two together :). And I really only would have to support releases. I'd prefer to burn that bridge once I've got a working driver though Don't want to jump ahead too much for fear of the old bike shed. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Just give me a good smack...
I don't know what the hell happened but it won't happen again as I am now vowing to avoid using the Safari, .mac webmail combination. For some reason it kept coming back with no server response and giving me no confirmation that the mail was ever sent via webmail... I just retried a few times and apparently all of them went but I was never told. now's your chance to get free hits on me! Deep apologies... Dave Leimbach ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD V5.0 and USB to Serial on Toshiba Satellite 1110
On Tue, May 27, 2003 at 08:38:51PM +0200, Richard Kaestner wrote: My Notebook (Toshiba Satellite 1110) does not have serial ports, so I wanted to connect a serial adapter. The adapter is recognized (see below), but I can't access any of the serial ports: [EMAIL PROTECTED] minicom minicom: cannot open /dev/ucom0: Device not configured Update to -current. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
make buildkernel currently broken in sys/pci/agp_intel.c
cc -c -O -pipe -march=athlon -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/pci/agp_intel.c /usr/src/sys/pci/agp_intel.c: In function `agp_intel_attach': /usr/src/sys/pci/agp_intel.c:173: `value' undeclared (first use in this function) /usr/src/sys/pci/agp_intel.c:173: (Each undeclared identifier is reported only once /usr/src/sys/pci/agp_intel.c:173: for each function it appears in.) *** Error code 1 This is probably because of rev. 1.13, which jhb@ committed just about an hour ago. Fix: ---8--- Index: sys/pci/agp_intel.c === RCS file: /u/cvs/cvs/src/sys/pci/agp_intel.c,v retrieving revision 1.13 diff -u -r1.13 agp_intel.c --- sys/pci/agp_intel.c 27 May 2003 18:23:56 - 1.13 +++ sys/pci/agp_intel.c 27 May 2003 19:28:38 - @@ -131,6 +131,7 @@ struct agp_gatt *gatt; u_int32_t type = pci_get_devid(dev); int error; + u_long value; error = agp_generic_attach(dev); if (error) ---8--- regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universität Wien http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Timecounter TSC frequency 451024462
Roberto Nunnari [EMAIL PROTECTED] writes: What is interesting is that with 4.7-Stable the faulty timer was handled correctly (or correctly ignored).. That's because 4.7 incorrectly fails to use ACPI to configure the system. As a result, 4.7 is unusable on newer laptops (which no longer support APM) and possibly also some high-end servers (where you need ACPI to figure out correct interrupt routing). so I'd suggest to fix in software the hardware bug in 5.1-Release, or at least in -current. There's no reliable way to do so. We *already* try to check that the clock we choose is correct. The best we can do is flag the chipset as known bad and never use the ACPI timer on that chipset, which will penalize motherboards which use this chipset but have correct ACPI tables. I already had fixed it with sysctl, but I'll give a try to the loader.conf solution as well. Using sysctl is an imperfect solution as the clock will run at double speed for a while before /etc/rc.d/sysctl is run. If you're running a lengthy fsck due to a power outage, that may be a long time. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[Fwd: cvs commit: www/en/releases/5.1R schedule.sgml]
All, As noted below, the release engineering team has decided to delay the RELENG_5_1 branch by three days in order to allow time for a few more items on the TODO list to be addressed. We apologize for the slip, but feel that it is neccessary to make 5.1 be a good release. The Release Engineering Team Original Message Subject: cvs commit: www/en/releases/5.1R schedule.sgml Date: Tue, 27 May 2003 13:11:39 -0700 (PDT) From: Scott Long [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] scottl 2003/05/27 13:11:39 PDT FreeBSD doc repository Modified files: en/releases/5.1R schedule.sgml Log: Update the schedule to reflect slipping the branch by three days. We are almost there, just need a clean up a few things. Revision ChangesPath 1.10 +14 -14www/en/releases/5.1R/schedule.sgml ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
tinderbox currently slightly broken
JFYI, there seems to be a bug in Perl 5.6.1 (which is what's installed on the -CURRENT tinderbox machine) which causes the entire process to bomb when a build fails and it tries to mail out the report. Failure reports (there have been a couple lately) won't be mailed out until this is fixed. I've contacted the admins, so I hope it won't be too long. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FBSD 5.1b2 Inst. Results on Dell i8500
On Thu, May 22, 2003 at 11:05:03PM +0200, Mark Santcroos wrote:
The same here, that's what I mentioned earlier, that I need to investigate
this. Hope to have that fixed before 'de haan kraait' tomorrow morning ;-)
Can you send me your whole asl, I'm curious how close it is to mine.
Hrm, a bit later than anticipated, got ill after skipping too many nights,
had to take a break :-)
However, with the following patch, fdc, sio, and ppc attach under acpi
instead of isa again!
With a stock kernel and patched dsdt I have a fully working system again.
All Dell laptop users with problems might want to give this a look as at
least Stijn's Inspirion 8500 has exactly the same dsdt as mine (Latitude
C640).
Mark
ps. Bob, sorry for arguing that it might be acpica, I come from a world
where I assume hardware is not the first thing to look at when things
break ...
--- c640.aslWed May 14 02:07:27 2003
+++ c640_custom.asl Tue May 27 22:18:14 2003
@@ -120,9 +120,9 @@
Method (SXX5, 2, NotSerialized)
{
-If (LLess (Arg1, SizeOf (Arg0)))
+If (LLess (Arg1, SizeOf (DerefOf(Arg0
{
-CreateByteField (Arg0, Arg1, SX20)
+CreateByteField (DerefOf(Arg0), Arg1, SX20)
SXX6 (0x7C, SX20)
}
}
@@ -133,16 +133,16 @@
Store (0x00, Local0)
While (LLess (Local0, SXX2))
{
-SXX5 (SXX0, Local0)
+SXX5 (RefOf(SXX0), Local0)
Increment (Local0)
}
}
Method (SXX8, 2, NotSerialized)
{
-If (LLess (Arg1, SizeOf (Arg0)))
+If (LLess (Arg1, SizeOf (DerefOf (Arg0
{
-CreateByteField (Arg0, Arg1, SX20)
+CreateByteField (DerefOf(Arg0), Arg1, SX20)
Store (SXX6 (0x7D, 0x00), SX20)
}
}
@@ -153,7 +153,7 @@
While (LLess (Local0, SXX3))
{
Add (SXX2, Local0, Local1)
-SXX8 (SXX0, Local1)
+SXX8 (RefOf (SXX0), Local1)
Increment (Local0)
}
}
@@ -217,9 +217,9 @@
Method (SX43, 2, NotSerialized)
{
-If (LLess (Arg1, SizeOf (Arg0)))
+If (LLess (Arg1, SizeOf (DerefOf(Arg0
{
-CreateByteField (Arg0, Arg1, SX20)
+CreateByteField (DerefOf(Arg0), Arg1, SX20)
Store (SX40 (), SX20)
}
}
@@ -238,7 +238,7 @@
{
Store (SX40 (), Local0)
Name (SX23, Buffer (Local0) {})
-SX44 (SX23, Local0)
+SX44 (Refof(SX23), Local0)
Return (SX23)
}
@@ -277,7 +277,7 @@
SX30 (Arg0)
SX11 ()
Name (PGET, Buffer (SXX3) {})
-SX44 (PGET, SXX3)
+SX44 (RefOf(PGET), SXX3)
SX12 ()
Return (PGET)
}
--
Mark SantcroosRIPE Network Coordination Centre
http://www.ripe.net/home/mark/New Projects Group/TTM
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FBSD 5.1b2 Inst. Results on Dell i8500
On Tue, May 27, 2003 at 10:28:32PM +0200, Mark Santcroos wrote: On Thu, May 22, 2003 at 11:05:03PM +0200, Mark Santcroos wrote: The same here, that's what I mentioned earlier, that I need to investigate this. Hope to have that fixed before 'de haan kraait' tomorrow morning ;-) Can you send me your whole asl, I'm curious how close it is to mine. Hrm, a bit later than anticipated, got ill after skipping too many nights, had to take a break :-) However, with the following patch, fdc, sio, and ppc attach under acpi instead of isa again! Great work! I'm off to test this right now! With a stock kernel and patched dsdt I have a fully working system again. All Dell laptop users with problems might want to give this a look as at least Stijn's Inspirion 8500 has exactly the same dsdt as mine (Latitude C640). It's in Inspiron 4150 FWIW, but there is enough reason to believe that most Dell laptops use the same code, yes. I'll report back ASAP. --Stijn -- Oh good, my dog found the chainsaw. -- Lilo, Disney's Lilo Stitch pgp0.pgp Description: PGP signature
HEADSUP: acpi patches in the tree
I have committed changes to nsalloc.c and dsmethod.c. Please cvsup and test ACPI, especially if you had problems with it (that were not present before 0228 was imported). Commit message follows: Fix false AE_NOT_FOUND messages, reported in NetBSD port-i386/20897. NetBSD dsmethod.c rev 1.7 Fix parent-child loop problem Fix a reference count problem that may cause unexpected memory free Intel 20030512 ACPICA drop (nsalloc.c) Approved by:re (jhb) Obtained from: NetBSD, Intel Reported by:mbr, kochi AT netbsd.org -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FBSD 5.1b2 Inst. Results on Dell i8500
On Tue, May 27, 2003 at 10:55:11PM +0200, Stijn Hoop wrote: On Tue, May 27, 2003 at 10:28:32PM +0200, Mark Santcroos wrote: With a stock kernel and patched dsdt I have a fully working system again. All Dell laptop users with problems might want to give this a look as at least Stijn's Inspirion 8500 has exactly the same dsdt as mine (Latitude C640). I'll report back ASAP. Success on my Inspiron 4150. After unsuccesfully trying to apply the patch to the asl dumped by acpidump I got to my senses and tried to apply it to the iasl disassembled version. That worked in one shot. Thanks for all the hard work, Mark! --Stijn -- In the force if Yoda's so strong, construct a sentence with words in the proper order then why can't he? pgp0.pgp Description: PGP signature
Re: Libthr stable enough for testing
On Mon, 2003-05-26 at 17:51, Mike Makonnen wrote: Most major locking work in libthr is finished. I believe it is stable enough now that it can be used for most applications[1]. I would appreciate it if people would try it out and report any bugs. Just installed a freshly cvsup-ped current and decided to give it a go. So far, everything seems to still be working (KDE, Mozilla, Evolution are my biggest consumers of libc_r AFAICT). artsd now works in Threaded OSS mode (before it would just hang and never access the dsp device) and plays mp3s much smoother. The only indication of a problem in my ten minutes of testing is that konsole seems to die with a signal 6 on startup about 50% of the time. Here's the reported backtrace: (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... 0x290456c3 in wait4 () from /usr/lib/libc.so.5 #0 0x290456c3 in wait4 () from /usr/lib/libc.so.5 #1 0x29036ab5 in waitpid () from /usr/lib/libc.so.5 #2 0x28ff2b75 in _waitpid (wpid=7, status=0x7, options=7) at /usr/src/lib/libthr/thread/thr_syscalls.c:396 #3 0x2867809f in KCrash::defaultCrashHandler(int) () from /usr/local/lib/libkdecore.so.5 #4 signal handler called #5 0x290453a3 in kill () from /usr/lib/libc.so.5 #6 0x2935ab47 in TEPty::makePty(bool) () from /usr/local/lib/konsole.so #7 0x2935abda in TEPty::startPgm(char const*, QValueListQCString, char const*) () from /usr/local/lib/konsole.so #8 0x2935b3fa in TEPty::commSetupDoneC() () from /usr/local/lib/konsole.so #9 0x28633f7d in KProcess::start(KProcess::RunMode, KProcess::Communication) () from /usr/local/lib/libkdecore.so.5 #10 0x2935a426 in TEPty::run(char const*, QStrList, char const*, bool, char const*, char const*) () from /usr/local/lib/konsole.so #11 0x2937eff9 in TESession::run() () from /usr/local/lib/konsole.so #12 0x29380e89 in TESession::qt_invoke(int, QUObject*) () from /usr/local/lib/konsole.so #13 0x289be288 in QObject::activate_signal(QConnectionList*, QUObject*) () from /usr/X11R6/lib/libqt-mt.so.3 #14 0x28c8cc2d in QSignal::signal(QVariant const) () from /usr/X11R6/lib/libqt-mt.so.3 #15 0x289d7cb8 in QSignal::activate() () from /usr/X11R6/lib/libqt-mt.so.3 #16 0x289dea73 in QSingleShotTimer::event(QEvent*) () from /usr/X11R6/lib/libqt-mt.so.3 #17 0x289614f5 in QApplication::internalNotify(QObject*, QEvent*) () from /usr/X11R6/lib/libqt-mt.so.3 #18 0x289612be in QApplication::notify(QObject*, QEvent*) () from /usr/X11R6/lib/libqt-mt.so.3 #19 0x285ff489 in KApplication::notify(QObject*, QEvent*) () from /usr/local/lib/libkdecore.so.5 #20 0x2893d727 in QEventLoop::activateTimers() () from /usr/X11R6/lib/libqt-mt.so.3 #21 0x2891c861 in QEventLoop::processEvents(unsigned) () from /usr/X11R6/lib/libqt-mt.so.3 #22 0x28975020 in QEventLoop::enterLoop() () from /usr/X11R6/lib/libqt-mt.so.3 #23 0x28974f58 in QEventLoop::exec() () from /usr/X11R6/lib/libqt-mt.so.3 #24 0x28961681 in QApplication::exec() () from /usr/X11R6/lib/libqt-mt.so.3 #25 0x2935fbdd in main () from /usr/local/lib/konsole.so #26 0x0804cabf in execpath_avoid_loops(QCString const, int, char const*, bool) () #27 0x0804d82d in execpath_avoid_loops(QCString const, int, char const*, bool) () #28 0x0804dcd7 in execpath_avoid_loops(QCString const, int, char const*, bool) () #29 0x0804ecf9 in main () #30 0x0804b085 in _start () Unfortunately I don't see any way to tell exactly what it is that is missing the debugging symbols... Will report back if I find anything else that isn't working. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: acpi patches in the tree
Subject: HEADSUP: acpi patches in the tree, On Tue, 27 May 2003 14:06:50 -0700 (PDT), Nate Lawson wrote: I have committed changes to nsalloc.c and dsmethod.c. Please cvsup and test ACPI, especially if you had problems with it (that were not present before 0228 was imported). After this update, I found some error messages like this: acpi0: IntelR AWRDACPI on motherboard ACPI-0438: *** Error: Looking up [\\_OS_] in namespace, AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0._INI] (Node 0xc21b73e0), AE_NOT_FOUND -- Shin-ichi YOSHIMOTO [EMAIL PROTECTED] http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR in vm_object/vm_kern
Hi! I just got the below LOR on: FreeBSD lap.snicki.dk 5.1-BETA FreeBSD 5.1-BETA #49: Tue May 27 22:28:31 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAP i386 sources from about half an hour before the kernel build. lock order reversal 1st 0xc5fd3378 vm object (vm object) @ /usr/src/sys/vm/vm_object.c:512 2nd 0xc082f110 system map (system map) @ /usr/src/sys/vm/vm_kern.c:325 Stack backtrace: backtrace(c03a3dff,c082f110,c03b06e3,c03b06e3,c03b057e) at backtrace+0x17 witness_lock(c082f110,8,c03b057e,145,e4351a90) at witness_lock+0x697 _mtx_lock_flags(c082f110,0,c03b057e,145,c5d795f0) at _mtx_lock_flags+0xb1 _vm_map_lock(c082f0b0,c03b057e,145,c02457e4,3246) at _vm_map_lock+0x36 kmem_malloc(c082f0b0,1000,101,e4351b24,c032add5) at kmem_malloc+0x65 page_alloc(c083a240,1000,e4351b17,101,c03eb46c) at page_alloc+0x27 slab_zalloc(c083a240,101,c03b1f47,66f,c083a924) at slab_zalloc+0x155 uma_zone_slab(c083a240,101,c03b1f47,66f,0) at uma_zone_slab+0xd8 uma_zalloc_internal(c083a240,0,101,6ef,0) at uma_zalloc_internal+0x55 uma_zfree_arg(c083a900,c6051cf0,0,e4351bcc,c0312b28) at uma_zfree_arg+0x2cc dev_pager_putfake(c6051cf0,0,c03afdab,bc,c5fd3378) at dev_pager_putfake+0x3a dev_pager_dealloc(c5fd3378,1,c03b1e4a,10b,0) at dev_pager_dealloc+0xc8 vm_pager_deallocate(c5fd3378,0,c03b1020,25e,c041f308) at vm_pager_deallocate+0x3 d vm_object_terminate(c5fd3378,0,c03b1020,200,c5f88438) at vm_object_terminate+0x1 f4 vm_object_deallocate(c5fd3378,c5f88438,c5fd3378,c5f88438,e4351c9c) at vm_object_ deallocate+0x20f vm_map_entry_delete(c1b7f100,c5f88438,c03b0751,86e,c039f6ec) at vm_map_entry_del ete+0x3b vm_map_delete(c1b7f100,282e4000,282e6000,2000,282e4000) at vm_map_delete+0x453 vm_map_remove(c1b7f100,282e4000,282e6000,0,c5d7cd88) at vm_map_remove+0x55 munmap(c5d795f0,e4351d10,c03b5c41,3fb,2) at munmap+0x9e syscall(2f,2f,bfbf002f,8225bb0,882) at syscall+0x26e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (73), eip = 0x282524e3, esp = 0xbfbff99c, ebp = 0xbfbff9b8 --- Dennis Kristensen Computer Science student at Aalborg University E-mail: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
David Leimbach wrote: On Tuesday, May 27, 2003, at 10:40AM, Alexander Kabaev [EMAIL PROTECTED] wrote: On Tue, 27 May 2003 10:32:42 -0500 David Leimbach [EMAIL PROTECTED] wrote: Ugh... the network driver portion of the nforce drivers is *not* GPL'd but it has a linux only and anti-reverse engineeing clause. Dave Then using the diver on FreeBSD will be a NVidia's license violation, wouldn't it? One more reason to keep it out of the tree. Just the network driver... the audio driver in the tarball is still GPL'd. Either which way I doubt either driver will go into the tree. I don't see any good reason to stick any of it in the kernel unless its absolutely necessary. I am not a religious person when it comes to licensing. I just don't like GPL style restrictions. Did you ever ask NVidia about they position on this? Perhaps they are more flexible then you may think and this whole discussion is simply pointless. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI crash
I feel your pain, my thinkpad doesn't co-operate with 5.1 either... ajt. On Tue, May 27, 2003 at 11:10:26AM -0400, Mikhail Kruk wrote: Hello, I've seen this reported before, but don't see a resolution. Maybe my logs will help solve the problem. When my Gateway laptop boots, I get a couple of logs about ACPI problems. See attached dmesg.txt Later (10-30 minutes) I get a crash with the following trace. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x80790ab0 fault code= supervisor read, page not present instruction pointer = 0x8:0xc06ea4d0 stack pointer = 0x10:0xcd10bbf0 frame pointer = 0x19:0xcd10bbf0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 6 (acpi_task1) kernel: type 12 trap, code=0 Stopped atAcpiNsMapHandleToNode+0x20: cmpb$0xaa,0(%edx) trace: AcpiNsMapHandleToNode contrib/dev/acpica/nsutils.c AcpiGetHandle acpi_pwer_switch_consumer dev/acpica/acpi_powerres.c acpi_tz_switch_cooler_on dev/acpica/acpi_thermal.c acpi_ForeachPackageObject dev/acpica/acpi_thermal.c acpi_tz_monitor atcpi_task_thread fork_exit fork_trampoline The trace is always the same, but the process is different (acpi_task1, _task2, _thermal) The problem is easily reproduced by doing a big compilation (kernel or buildworld). See also: http://polkan2.dyndns.org/~meshko/foo.dsdt http://polkan2.dyndns.org/~meshko/foo.asl I also have a couple of related questions. 1) I tried putting some debug outputs in acpi code, and messages that I put in contrib/dev/acpica/* are showing up. However messages I put in dev/acpica do not seem to go anywhere. I can't find any object files generated from that directory. What am I missing? 2) Is there a workaround for this problem before ACPI gets fixed? I tried booting without it (unset acpi_enable), but it just hangs during the boot. Would it work if I disabled some part of ACPI? Would the laptop overheat if I do that? Can I somehow enable APM instead of ACPI? RedHat 8 works fine on the same laptop and it seems to be using APM only, no ACPI. Please cc: me, not subscribed. Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-BETA #0: Fri May 23 12:28:16 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc071a000. Preloaded elf module /boot/kernel/acpi.ko at 0xc071a0a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 2392954684 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2392.95-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE real memory = 267911168 (255 MB) avail memory = 252489728 (240 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: GATEWA 400 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00fdf10 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82845 host to AGP bridge mem 0xec00-0xefff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0x1800-0x181f irq 10 at device 29.0 on pci0 usb0: Intel 82801CA/CAM (ICH3) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 cbb0: O2Micro OZ6912/6972 PCI-CardBus Bridge irq 10 at device 2.0 on pci2 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 pci2: multimedia, audio at device 3.0 (no driver attached) fwohci0: vendor=104c, dev=8026 fwohci0: 1394 Open Host Controller Interface mem 0xe820-0xe8203fff,0xe8206000-0xe82067ff irq 10 at device 5.0 on pci2 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channel is 4. fwohci0: EUI64 00:e0:b8:04:01:01:ec:f1 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 if_fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:e0:b8:01:ec:f1 sbp0: SBP2/SCSI
Re: LOR in vm_object/vm_kern
On Wed, May 28, 2003 at 12:21:21AM +0200, Dennis Kristensen wrote: Hi! I just got the below LOR on: FreeBSD lap.snicki.dk 5.1-BETA FreeBSD 5.1-BETA #49: Tue May 27 22:28:31 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAP i386 sources from about half an hour before the kernel build. lock order reversal 1st 0xc5fd3378 vm object (vm object) @ /usr/src/sys/vm/vm_object.c:512 2nd 0xc082f110 system map (system map) @ /usr/src/sys/vm/vm_kern.c:325 Thanks, this has been reported n times already. Kris pgp0.pgp Description: PGP signature
panic: don't do that, in ugen(4)
Running `quickcam' twice from: http://people.freebsd.org/~jmallett/qce-freebsd.tgz Yields the following loveliness: %%% Script started on Tue May 27 17:59:35 2003 ([EMAIL PROTECTED]:~)1% gdb -k /boot/kernel/kernel vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... (no debugging symbols found)... panic: bremfree: removing a buffer not on a queue panic messages: --- panic: don't do that syncing disks, buffers remaining... 1806 panic: bremfree: removing a buffer not on a queue Uptime: 6m34s Dumping 191 MB ata0: resetting devices .. ata0: pre reset mask=03 ostat0=50 ostat2=00 ad0: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: after reset mask=03 stat0=50 stat1=00 ad0: ATA 01 a5 ata0: devices=01 ad0: success setting BIOSPIO on Intel PIIX4 chip done ad0: timeout waiting for DRQata0: resetting devices .. ata0: pre reset mask=03 ostat0=d0 ostat2=d0 ad0: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: after reset mask=03 stat0=50 stat1=00 ad0: ATA 01 a5 ata0-slave: ATA 01 a5 ata0: devices=03 ata0-slave: timeout waiting for cmd=ec s=00 e=00 ata0-slave: ATA identify failed ad0: success setting BIOSPIO on Intel PIIX4 chip done 16 32 48 64 80 96 112 128 144 160 176 --- Reading symbols from /boot/kernel/acpi.ko...(no debugging symbols found)... done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/logo_saver.ko... (no debugging symbols found)...done. Loaded symbols for /boot/kernel/logo_saver.ko #0 0xc030d6eb in doadump () (kgdb) bt #0 0xc030d6eb in doadump () #1 0xc030dd13 in boot () #2 0xc030e05b in panic () #3 0xc0351e12 in bremfreel () #4 0xc0351cf5 in bremfree () #5 0xc0355397 in getblk () #6 0xc0351ef2 in breadn () #7 0xc0351e9c in bread () #8 0xc04273d2 in ffs_update () #9 0xc043bc5f in ffs_fsync () #10 0xc043acfe in ffs_sync () #11 0xc03677fb in sync () #12 0xc030d92d in boot () #13 0xc030e05b in panic () #14 0xc02ede12 in destroy_dev () #15 0xc02a369f in ugen_destroy_devnodes () #16 0xc02a48db in ugen_set_interface () #17 0xc02a4e2c in ugen_do_ioctl () #18 0xc02a5367 in ugenioctl () #19 0xc02d538e in spec_ioctl () #20 0xc02d4ac8 in spec_vnoperate () #21 0xc036fbe1 in vn_ioctl () #22 0xc0334098 in ioctl () #23 0xc049a27e in syscall () ---Type return to continue, or q return to quit--- #24 0xc04896ed in Xint0x80_syscall () ---Can't read userspace from dump, or kernel process--- ([EMAIL PROTECTED]:~)2% uname -a FreeBSD big-lizard.backyard.newgold.net 5.1-BETA-20030522-JPSNAP FreeBSD 5.1-BETA-20030522-JPSNAP #0: Thu May 22 00:15:14 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Script done on Tue May 27 18:01:06 2003 %%% Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Latest -Current ACPI issues...
Hello all. I just finished rebuilding -Current as of about 6:45pm EST and have now noticed the following on boot: [EMAIL PROTECTED]/home/jmw: uname -a FreeBSD neuro.charter.net 5.1-BETA FreeBSD 5.1-BETA #2: Tue May 27 18:39:04 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GEN i386 [EMAIL PROTECTED]/home/jmw: [...dmesg snippage...] acpi0: INTEL D845EBT2 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f4660 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz ACPI-0438: *** Error: Looking up [\\_OS_] in namespace, AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed [\\OSFL] (Node 0xc10e8980), AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed [\\_SB_.SYSM._CRS] (Node 0xc3c0f740), AE_NOT_FOUND acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 [...dmesg snippage...] If there is any other information that can be provided, please do let me know and I will try to provide it. Finally, are there any resources that fully describe ACPI so that I may be better able to understand it as a whole, as well as if something like this happens again, I'd be able to provide a better report. Thank you, John Wilson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tuesday 27 May 2003 08:43, David Leimbach wrote: On Tuesday, May 27, 2003, at 07:36 AM, Wilko Bulte wrote: On Tue, May 27, 2003 at 02:35:41PM +0200, Stijn Hoop wrote: On Tue, May 27, 2003 at 07:28:29AM -0500, David Leimbach wrote: I have the GPLd source to the nforce drivers for Linux to support the nVidia nforce and nforce2 drivers in the kernel. To port these to FreeBSD would be an interesting task [if it hasn't already been done] and I have been looking for an excuse to get down and dirty with FBSD. [Yes... talk is cheap... just do it... Nike-a-go-go etc etc... :)] What is the policy on drivers that are clearly going to have to be GPLd by the viral clause since I am referencing a GPL driver to do the porting work myself? Are these allowed in the kernel? Yes, see for example the GPL_ed floating point emulator. However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. Get someone to pair with you and do a clean-room implementation. One of you studies the GPL'd driver and writes a specification. The other writes a BSD-licensed driver from the specification, BUT NEVER ONCE LOOKS AT THE GPL'D SOURCE. Virus removed. -- Chris BeHanna http://www.pennasoft.com Principal Consultant PennaSoft Corporation [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
David Leimbach [EMAIL PROTECTED] writes: Ugh... the network driver portion of the nforce drivers is *not* GPL'd but it has a linux only and anti-reverse engineeing clause. ...which is null and void in countries with proper IP laws, such as Norway. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: acpi patches in the tree
On Wed, 28 May 2003, Shin-ichi YOSHIMOTO wrote:
After this update, I found some error messages like this:
acpi0: IntelR AWRDACPI on motherboard
ACPI-0438: *** Error: Looking up [\\_OS_] in namespace, AE_NOT_FOUND
ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0._INI] (Node
0xc21b73e0), AE_NOT_FOUND
Please try the attached patch and see if it changes things for you.
-Nate--- nsalloc.c 29 Apr 2003 18:37:59 - 1.1.1.17
+++ nsalloc.c 27 May 2003 19:20:12 -
@@ -305,7 +321,7 @@
ACPI_NAMESPACE_NODE *Node, /* New Child*/
ACPI_OBJECT_TYPEType)
{
-UINT16 OwnerId = 0;
+UINT16 OwnerId = TABLE_ID_DSDT;
ACPI_NAMESPACE_NODE *ChildNode;
#ifdef ACPI_ALPHABETIC_NAMESPACE
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2267] Re: HEADSUP: acpi patches in the tree
On Tue, 27 May 2003, Nate Lawson wrote: On Wed, 28 May 2003, Shin-ichi YOSHIMOTO wrote: After this update, I found some error messages like this: acpi0: IntelR AWRDACPI on motherboard ACPI-0438: *** Error: Looking up [\\_OS_] in namespace, AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0._INI] (Node 0xc21b73e0), AE_NOT_FOUND Please try the attached patch and see if it changes things for you. Also, is the only problem these messages or is functionality broken? I see these messages too: acpi0: IBMTP-1Aon motherboard ACPI-0438: *** Error: Looking up [\\_OS_] in namespace, AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed [\\_SB_._INI] (Node 0xc11c07a0), AE_NOT_FOUND But they are actually an improvement for me as I get these messages instead when I have that patch applied: acpi0: IBMTP-1Aon motherboard pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00fdeb0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.FDC_._INI] (Node 0xc32e0200), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__._INI] (Node 0xc32d93c0), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BAT0._STA] (Node 0xc32dbbc0), AE_NOT_EXIST ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BAT0._STA] (Node 0xc32dbbc0), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BAT1._STA] (Node 0xc32dba40), AE_NOT_EXIST ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BAT1._STA] (Node 0xc32dba40), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BGID] (Node 0xc32e0340), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BINI] (Node 0xc32e0360), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BSTA] (Node 0xc32e03a0), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.IDE0.SCND.MSTR._STA] (Node 0xc32e0260), AE_NOT_EXIST ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0.IDE0.SCND.MSTR._STA] (Node 0xc32e0260), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BGID] (Node 0xc32e0340), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BINI] (Node 0xc32e0360), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BSTA] (Node 0xc32e03a0), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.USB0.URTH.UNST._STA] (Node 0xc32e0880), AE_NOT_EXIST ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0.USB0.URTH.UNST._STA] (Node 0xc32e0880), AE_NOT_EXIST Either way, I have the same functionality. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: acpi patches in the tree
Subject: Re: HEADSUP: acpi patches in the tree, Please try the attached patch and see if it changes things for you. OK. I tried youre patch. Error messages is gone :-) Thanks ! acpi0: IntelR AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00fdee0 acpi0: power button is handled as a fixed feature programming model. -- Shin-ichi YOSHIMOTO [EMAIL PROTECTED] http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: don't do that, in ugen(4)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 28 May 2003 00:06 am, Juli Mallett wrote: Running `quickcam' twice from: http://people.freebsd.org/~jmallett/qce-freebsd.tgz Yields the following loveliness: [..] This is the same issue another person (Mark Blackman) is seeing with the Speedtouch software. I submitted a patch to the kernel recently which alleviated the problem for me (and others), but Mark is still having problems (albeit slightly different since the patch) with ugen_set_interface panicing inside /sys/dev/usb/ugen.c. I'll be looking into this either tomorrow or the next day, to try to work out how it's still occurring and fix it. If anyone else decides to take a look, it may help to see the patch recently committed to ugen.c: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/ugen.c.diff?r1=1.69r2=1.70f=h It's related to the way ugen treats device nodes since; since devfs was introduced into the kernel, there have been stricter rules on how the kernel can manipulate device nodes, and ugen.c is (apparently) still breaking these rules. Cheers, Jay - -- http://www.evilrealms.net/ - Systems Administrator Developer http://www.ic.ac.uk/ - Imperial College, 2nd year CS student -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+1AgffJLn3O/2GbERAjlrAKCxOMROjqZdSKHmYoywNt/85JQW4gCbBAQO OT6Z2VJGht+J1gctuWLZqN4= =M6D7 -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2269] Re: HEADSUP: acpi patches in the tree
On Wed, 28 May 2003, Shin-ichi YOSHIMOTO wrote: Subject: Re: HEADSUP: acpi patches in the tree, Please try the attached patch and see if it changes things for you. OK. I tried youre patch. Error messages is gone :-) Thanks ! Please respond to my other email as well. Without that patch, do you have problems or is it just the error message? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2269] Re: HEADSUP: acpi patches in the tree
Subject: Re: [acpi-jp 2269] Re: HEADSUP: acpi patches in the tree, On Tue, 27 May 2003 17:56:47 -0700 (PDT), Nate Lawson wrote: Please respond to my other email as well. Without that patch, do you have problems or is it just the error message? Oh, sorry. Without that patch, no problems. It's only the error message. -- Shin-ichi YOSHIMOTO [EMAIL PROTECTED] http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: passwd NIS+ YP compat mode
On Tue, 27 May 2003 21:46:04 +0900, TOMITA Yoshinori
[EMAIL PROTECTED] said:
T Hello all,
T After cvsup-ed today 2003-5-27 and make buildworld and so on,
T NIS passwd database are completely ignored.
T But NIS group database seems to be used as usual.
T Out NIS server is actually NIS+ in YP comaptible mode.
T I traced the function getpwnam() and reached following code.
T What can I do ?
T ==[getpwent.c]=
T static int
T nis_map(char *domain, enum nss_lookup_type how, char *buffer, size_t bufsize,
T int *master)
T...
T rv = yp_order(domain, buffer, order); -- this returns YPERR_YPERR
T if (rv == 0)
T return (NS_SUCCESS);
T ==[yplib.c]=
T int
T yp_order(char *indomain, char *inmap, int *outorder)
T...
T /*
T * NIS+ in YP compat mode doesn't support the YPPROC_ORDER
T * procedure.
T */
T if (r == RPC_PROCUNAVAIL) {
T return(YPERR_YPERR); --- Here
T }
T
I hope this patch will solve this problem for users living under NIS+
servers.
I guess yp_order() is used to check masswd.by* or master.passwd.by*
databese really exists. yp_master() can be used for this purpose. But
I do not know the cost of yp_master() compared to yp_order().
--- /usr/src/lib/libc/gen/getpwent.c.bakTue May 27 08:47:24 2003
+++ /usr/src/lib/libc/gen/getpwent.cWed May 28 09:35:50 2003
@@ -938,14 +938,15 @@
nis_map(char *domain, enum nss_lookup_type how, char *buffer, size_t bufsize,
int *master)
{
- int rv, order;
+ int rv;
+ char*outname;
*master = 0;
if (geteuid() == 0) {
if (snprintf(buffer, bufsize, master.passwd.by%s,
(how == nss_lt_id) ? uid : name) = bufsize)
return (NS_UNAVAIL);
- rv = yp_order(domain, buffer, order);
+ rv = yp_master(domain, buffer, outname);
if (rv == 0) {
*master = 1;
return (NS_SUCCESS);
@@ -954,7 +955,7 @@
if (snprintf(buffer, bufsize, passwd.by%s,
(how == nss_lt_id) ? uid : name) = bufsize)
return (NS_UNAVAIL);
- rv = yp_order(domain, buffer, order);
+ rv = yp_master(domain, buffer, outname);
if (rv == 0)
return (NS_SUCCESS);
return (NS_UNAVAIL);
--
---
TOMITA Yoshinori
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tue, 27 May 2003 22:13, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. There are already a number of kernel modules in the ports tree (eg nvidia drivers, ltmdm modem driver, aureal sound driver, etc). The only downside is that there are no hooks into the build process so you have to be VERY careful when you update your kernel, or you get panics :( (I found this recently, some change broke all of my 3rd party modules and caused panics when I tried to load them). I would really like some way of getting external modules rebuilt at the same time as buildkernel and friends, otherwise you have to remember to rebuild the affected ports, and it is a pain in the ass. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
I have been burnt by this in the past also. I think that it would be useful if you could allow kernel modules to be bound to a particular kernel version/date/whatever, and have external modules refuse to load and/or complain if the kernel is upgraded. This should prevent unnecessary kernel panics when you upgrade. The Linux kernel has been doing this for years. Seeya...Q On Wed, 2003-05-28 at 12:17, Daniel O'Connor wrote: On Tue, 27 May 2003 22:13, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. There are already a number of kernel modules in the ports tree (eg nvidia drivers, ltmdm modem driver, aureal sound driver, etc). The only downside is that there are no hooks into the build process so you have to be VERY careful when you update your kernel, or you get panics :( (I found this recently, some change broke all of my 3rd party modules and caused panics when I tried to load them). I would really like some way of getting external modules rebuilt at the same time as buildkernel and friends, otherwise you have to remember to rebuild the affected ports, and it is a pain in the ass. -- Seeya...Q -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _ / Quinton Dolan - [EMAIL PROTECTED] __ __/ / / __/ / / /__ / _// / Gold Coast, QLD, Australia __/ __/ __/ / / - / Ph: +61 419 729 806 ___ / _\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
Q wrote: I have been burnt by this in the past also. I think that it would be useful if you could allow kernel modules to be bound to a particular kernel version/date/whatever, and have external modules refuse to load and/or complain if the kernel is upgraded. This should prevent unnecessary kernel panics when you upgrade. The Linux kernel has been doing this for years. Seeya...Q For the love of god, no! This creates a support nightmare. What happens when a user installs his system and recompiles the kernel without changing the source at all? His modules won't work, but there is no reason why they shouldn't. What if one of those now non-working modules is a driver for his hard drive? Scott On Wed, 2003-05-28 at 12:17, Daniel O'Connor wrote: On Tue, 27 May 2003 22:13, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. There are already a number of kernel modules in the ports tree (eg nvidia drivers, ltmdm modem driver, aureal sound driver, etc). The only downside is that there are no hooks into the build process so you have to be VERY careful when you update your kernel, or you get panics :( (I found this recently, some change broke all of my 3rd party modules and caused panics when I tried to load them). I would really like some way of getting external modules rebuilt at the same time as buildkernel and friends, otherwise you have to remember to rebuild the affected ports, and it is a pain in the ass. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
Don't overreact. I'm not suggesting taking the linux approach of versioning every module. But rather allowing the loader or a module (most likely a 3rd part or from a port) the ability to make a decision based on some internal revision/date based version as to whether it is safe to proceed to load. I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. Seeya...Q On Wed, 2003-05-28 at 13:13, Scott Long wrote: Q wrote: I have been burnt by this in the past also. I think that it would be useful if you could allow kernel modules to be bound to a particular kernel version/date/whatever, and have external modules refuse to load and/or complain if the kernel is upgraded. This should prevent unnecessary kernel panics when you upgrade. The Linux kernel has been doing this for years. Seeya...Q For the love of god, no! This creates a support nightmare. What happens when a user installs his system and recompiles the kernel without changing the source at all? His modules won't work, but there is no reason why they shouldn't. What if one of those now non-working modules is a driver for his hard drive? Scott On Wed, 2003-05-28 at 12:17, Daniel O'Connor wrote: On Tue, 27 May 2003 22:13, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. There are already a number of kernel modules in the ports tree (eg nvidia drivers, ltmdm modem driver, aureal sound driver, etc). The only downside is that there are no hooks into the build process so you have to be VERY careful when you update your kernel, or you get panics :( (I found this recently, some change broke all of my 3rd party modules and caused panics when I tried to load them). I would really like some way of getting external modules rebuilt at the same time as buildkernel and friends, otherwise you have to remember to rebuild the affected ports, and it is a pain in the ass. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
Q wrote: Don't overreact. Heh. I live this hell every day with Linux in my day job. I'm not suggesting taking the linux approach of versioning every module. But rather allowing the loader or a module (most likely a 3rd part or from a port) the ability to make a decision based on some internal revision/date based version as to whether it is safe to proceed to load. Ideally, every API would be versioned, and developers would be careful to architect their work so that the interfaces would be stable and gratuitous incompatibilities would be avoided. Alas, that is not always the case. I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. I'm really of the opinion that these ports should either live in the sys/ tree, or that magic should be devised to make sure that they are built along with the rest of the modules. Scott Seeya...Q On Wed, 2003-05-28 at 13:13, Scott Long wrote: Q wrote: I have been burnt by this in the past also. I think that it would be useful if you could allow kernel modules to be bound to a particular kernel version/date/whatever, and have external modules refuse to load and/or complain if the kernel is upgraded. This should prevent unnecessary kernel panics when you upgrade. The Linux kernel has been doing this for years. Seeya...Q For the love of god, no! This creates a support nightmare. What happens when a user installs his system and recompiles the kernel without changing the source at all? His modules won't work, but there is no reason why they shouldn't. What if one of those now non-working modules is a driver for his hard drive? Scott On Wed, 2003-05-28 at 12:17, Daniel O'Connor wrote: On Tue, 27 May 2003 22:13, David Leimbach wrote: However the idea is that all GPL infected stuff be isolated, allowing a fully working kernel without GPL stuff in there. Sounds like a kernel module is the way to go then. Perhaps it could exist in the ports tree instead of the mainline kernel sources :). I know I'd be happy with that... the problem is hosting the driver since I am sure patching it won't be enough to map the linux innards to freebsd's. There are already a number of kernel modules in the ports tree (eg nvidia drivers, ltmdm modem driver, aureal sound driver, etc). The only downside is that there are no hooks into the build process so you have to be VERY careful when you update your kernel, or you get panics :( (I found this recently, some change broke all of my 3rd party modules and caused panics when I tried to load them). I would really like some way of getting external modules rebuilt at the same time as buildkernel and friends, otherwise you have to remember to rebuild the affected ports, and it is a pain in the ass. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
* Scott Long [EMAIL PROTECTED] [030527 23:51]: I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. I'm really of the opinion that these ports should either live in the sys/ tree, or that magic should be devised to make sure that they are built along with the rest of the modules. Wouldn't it be sufficient to simply install the port modules into /boot/kernel instead of /usr/local/wherever/it/goes/now? I understand why most aren't put there now, due to the seperation of base system from ports etc. But I would the benefits of violating that principle outweigh the detriments: each time you reinstall your kernel, /boot/kernel is moved out of the way... taking all the outdated modules with it. Your port modules would fail to load, not being in the right place, but that's far better than a panic. --Mike pgp0.pgp Description: PGP signature
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 13:17, Scott Long wrote: I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. I'm really of the opinion that these ports should either live in the sys/ tree, or that magic should be devised to make sure that they are built along with the rest of the modules. Agreed :) I don't think it makes sense committing them into the sys tree, as it bloats everyones system and has potential licensing problems. Maybe the kernel build stuff can look in /usr/local/src/sys/modules for things to build or something.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel module inconsistency was policy on GPL'd drivers?
You could achieve the same result without breaking a bunch of cardinal rules by taking an MD5 hash of the kernel when the port is first installed, then modify the rc.d script that loads the module to only run if that MD5 hash matches the current kernel. If a mismatch occurs it should spew out an error saying the port should be reinstalled. This would most definitely work, although I'm not sure if this is the best way of resolving the issue in the longer term. Seeya...Q On Wed, 2003-05-28 at 14:04, Michael Edenfield wrote: * Scott Long [EMAIL PROTECTED] [030527 23:51]: I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. I'm really of the opinion that these ports should either live in the sys/ tree, or that magic should be devised to make sure that they are built along with the rest of the modules. Wouldn't it be sufficient to simply install the port modules into /boot/kernel instead of /usr/local/wherever/it/goes/now? I understand why most aren't put there now, due to the seperation of base system from ports etc. But I would the benefits of violating that principle outweigh the detriments: each time you reinstall your kernel, /boot/kernel is moved out of the way... taking all the outdated modules with it. Your port modules would fail to load, not being in the right place, but that's far better than a panic. --Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel module inconsistency was policy on GPL'd drivers?
Q wrote: You could achieve the same result without breaking a bunch of cardinal rules by taking an MD5 hash of the kernel when the port is first installed, then modify the rc.d script that loads the module to only run if that MD5 hash matches the current kernel. If a mismatch occurs it should spew out an error saying the port should be reinstalled. This would most definitely work, although I'm not sure if this is the best way of resolving the issue in the longer term. Don't forget that some modules need to be loaded at boot time. Also, if I recompile my kernel to trim down an unused driver, the MD5 will change. Scott Seeya...Q On Wed, 2003-05-28 at 14:04, Michael Edenfield wrote: * Scott Long [EMAIL PROTECTED] [030527 23:51]: I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. I'm really of the opinion that these ports should either live in the sys/ tree, or that magic should be devised to make sure that they are built along with the rest of the modules. Wouldn't it be sufficient to simply install the port modules into /boot/kernel instead of /usr/local/wherever/it/goes/now? I understand why most aren't put there now, due to the seperation of base system from ports etc. But I would the benefits of violating that principle outweigh the detriments: each time you reinstall your kernel, /boot/kernel is moved out of the way... taking all the outdated modules with it. Your port modules would fail to load, not being in the right place, but that's far better than a panic. --Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-BETA2 FAILURE on IBM A30p Thinkpad
Kevin Oberman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] From: Jesse D. Guardiani [EMAIL PROTECTED] Date: Sat, 24 May 2003 02:12:32 -0400 Sender: [EMAIL PROTECTED] Andre Guibert de Bruet [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] Does you r kernel configuration have: options DISABLE_PSE options DISABLE_PG_G I don't know. Does it? I was using the kernel that comes on the CDROM that I burned from an ISO image. I have no clue what options it is compiled with. That's part of what I find so frustrating. :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel module inconsistency was policy on GPL'd drivers?
Hi, there! On Wednesday 28 May 2003 08:25, Scott Long wrote: SL Don't forget that some modules need to be loaded at boot time. Also, if SL I recompile my kernel to trim down an unused driver, the MD5 will SL change. It'll change even if you do not mess with the configuration at all: the uname information (the compile date) will change anyway. I'd rather see something like PORTS_KMODS=audio/aureal-kmod xxx/yyy knob in the /etc/make.conf Regards, Alexey. -- ,, | A quoi ca sert d'etre sur la terre | Alexey V. Neyman | Si c'est pour faire nos vies a genoux! | mailto:[EMAIL PROTECTED] `--( Les Rois du Monde )-' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
In message: [EMAIL PROTECTED]
Daniel O'Connor [EMAIL PROTECTED] writes:
: The only downside is that there are no hooks into the build process so you
: have to be VERY careful when you update your kernel, or you get panics :(
This is true. I'd thought that MODULES_OVERRIDE would help, but ports
builds and kernel builds are different enough to make this not easy to
do.
Wanna test a patch? Add a 'makeoptions PORTS_MODULES=comms/ltmdm' to
your config file and apply the following patch. Lemme know how well
(or poorly) it works. There's likely some hidden assumptions that
make it appear to work for me.
Warner
--- sys/conf/kern.post.mk#10Tue May 27 22:34:04 2003
+++ sys/conf/kern.post.mk Tue May 27 22:34:04 2003
@@ -41,6 +41,20 @@
.endif
.endif
+.if defined(PORTS_MODULES)
+modules: ports-all
+ports-all:
+.for __i in ${PORTS_MODULES}
+ cd /usr/ports/${__i}; ${MAKE} all
+.endfor
+
+modules-install: ports-install
+ports-install:
+.for __i in ${PORTS_MODULES}
+ cd /usr/ports/${__i}; ${MAKE} install
+.endfor
+.endif
+
.if !defined(DEBUG)
FULLKERNEL=${KERNEL_KO}
.else
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
In message: [EMAIL PROTECTED] Daniel O'Connor [EMAIL PROTECTED] writes: : Maybe the kernel build stuff can look in /usr/local/src/sys/modules for things : to build or something.. YUCK! Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: acpi patches in the tree
On Tuesday 27 May 2003 07:58 pm, Nate Lawson wrote: On Wed, 28 May 2003, Shin-ichi YOSHIMOTO wrote: After this update, I found some error messages like this: acpi0: IntelR AWRDACPI on motherboard ACPI-0438: *** Error: Looking up [\\_OS_] in namespace, AE_NOT_FOUND ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0._INI] (Node 0xc21b73e0), AE_NOT_FOUND Please try the attached patch and see if it changes things for you. -Nate I was having freezing on S3 problems (same as above), but this patch fixed it. -- Anish Mistry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel module inconsistency was policy on GPL'd drivers?
In message: [EMAIL PROTECTED]
Alexey Neyman [EMAIL PROTECTED] writes:
: I'd rather see something like
: PORTS_KMODS=audio/aureal-kmod xxx/yyy
: knob in the /etc/make.conf
Funny, I had similar thoughts before seeing your patch. Here's my
latest patch. You could put it in /etc/make.conf, but that's really
the wrong place because you typically would want to tie it to a
specific kernel config. However, there's nothing stopping you from
doing that if you want. I'd do it as a makeoptions, ala
MODULES_OVERRIDE.
This version fixes two bugs: make clean (reported by alex!), and
propigationg of SYSDIR. I suppose that I should replace /usr/ports
with something like PORTSDIR too, eh?
Warner
--- //depot/user/imp/freebsd-imp/sys/conf/kern.post.mk#10
+++ /paco/imp/p4/src/sys/conf/kern.post.mk
@@ -21,6 +21,19 @@
${target:S/^reinstall$/install/:S/^clobber$/cleandir/}
.endif
.endfor
+# Handle out of tree ports
+.if defined(PORTS_MODULES)
+.if defined(SYSDIR)
+PORTSMODULESENV=SYSDIR=${SYSDIR}
+.endif
+.for target in all install clean
+${target}: ports-${target}
+ports-${target}:
+.for __i in ${PORTS_MODULES}
+ cd /usr/ports/${__i}; ${PORTSMODULESENV} ${MAKE} ${target}
+.endfor
+.endfor
+.endif
.ORDER: kernel-install modules-install
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 14:41, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel O'Connor [EMAIL PROTECTED] writes: : Maybe the kernel build stuff can look in /usr/local/src/sys/modules for : things to build or something.. YUCK! *WHY?* I have asked this before BTW, and I haven't been told why it sucks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel module inconsistency was policy on GPL'd drivers?
Yes, I'm aware of the implications.. I was merely proposing a ports legal way of achieving the same result that Mike put forward without stuffing a foreign module into /boot. Although, like I said, this is not really a long term solution to the problem. All the port's originating kernel modules I am aware of use /usr/local/etc/rc.d scripts to load the module, and would therefore work with my suggested approach. If you manually loaded it using /boot/loader.conf you would need to put the module into /boot/kernel anyway, which would get moved out the next time you installed a new kernel. I guess the real question is which is more acceptable to the average user. Reinstalling a couple of ports each time you install a new kernel, or risking a kernel panic by not doing it? Obviously it would be better if you only needed to reinstall something only IF it was really required, but unless their is some alternative way of knowing this before loading the module it's hard to determine when that might be without causing a kernel panic. Seeya...Q On Wed, 2003-05-28 at 14:25, Scott Long wrote: Q wrote: You could achieve the same result without breaking a bunch of cardinal rules by taking an MD5 hash of the kernel when the port is first installed, then modify the rc.d script that loads the module to only run if that MD5 hash matches the current kernel. If a mismatch occurs it should spew out an error saying the port should be reinstalled. This would most definitely work, although I'm not sure if this is the best way of resolving the issue in the longer term. Don't forget that some modules need to be loaded at boot time. Also, if I recompile my kernel to trim down an unused driver, the MD5 will change. Scott Seeya...Q On Wed, 2003-05-28 at 14:04, Michael Edenfield wrote: * Scott Long [EMAIL PROTECTED] [030527 23:51]: I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. I'm really of the opinion that these ports should either live in the sys/ tree, or that magic should be devised to make sure that they are built along with the rest of the modules. Wouldn't it be sufficient to simply install the port modules into /boot/kernel instead of /usr/local/wherever/it/goes/now? I understand why most aren't put there now, due to the seperation of base system from ports etc. But I would the benefits of violating that principle outweigh the detriments: each time you reinstall your kernel, /boot/kernel is moved out of the way... taking all the outdated modules with it. Your port modules would fail to load, not being in the right place, but that's far better than a panic. --Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
David Leimbach wrote: IANAL but I think the GPL has provisions for binaries that contain code that is not necessarily dependant but merely aggregated into one package. Linking is not mere agregation. If you can cite the section of the GPL you are talking about, it would be useful (this is a strawman: I have been dealing with lawyers over the GPL since 1992). Still I agree... it must be a module for more than one very good reason :). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Wed, 28 May 2003 14:22, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel O'Connor [EMAIL PROTECTED] writes: : The only downside is that there are no hooks into the build process so : you have to be VERY careful when you update your kernel, or you get : panics :( This is true. I'd thought that MODULES_OVERRIDE would help, but ports builds and kernel builds are different enough to make this not easy to do. Wanna test a patch? Add a 'makeoptions PORTS_MODULES=comms/ltmdm' to your config file and apply the following patch. Lemme know how well (or poorly) it works. There's likely some hidden assumptions that make it appear to work for me. I don't see how it can work properly.. You need 'FORCE_PKG_REGISTER=' in the install target. I don't think how the patch is structured is sensible though :) 1) If the port is updated between builds you end up with two version of the port installed. 2) You can't control where the module gets put - arguably this isn't a calamity, but I think it makes more sense for the modules to end up in /boot/modules, or some analog to it that is in $PREFIX. IMHO a standard should be set WRT item 2 so future ports writers know what the proper way to do it is :) I guess the problem with mandating somewhere in $PREFIX is that the loader can't load it, so that's no good. I guess the only choice left is /boot/modules. Any comments? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
By doing that aren't you assuming that the kernel will be installed on the machine that built it, and not potentially somewhere else? What about sysinstall upgrades that don't require src? Seeya...Q On Wed, 2003-05-28 at 15:17, Daniel O'Connor wrote: On Wed, 28 May 2003 14:41, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel O'Connor [EMAIL PROTECTED] writes: : Maybe the kernel build stuff can look in /usr/local/src/sys/modules for : things to build or something.. YUCK! *WHY?* I have asked this before BTW, and I haven't been told why it sucks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
