[-CURRENT tinderbox] failure on ia64/ia64
TB --- 2003-06-15 05:03:22 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-06-15 05:03:22 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-15 05:07:26 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4: building libraries [...] cc -O -pipe -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libkvm/kvm_file.c -o kvm_file.o cc -O -pipe -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libkvm/kvm_getloadavg.c -o kvm_getloadavg.o cc -O -pipe -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libkvm/kvm_getswapinfo.c -o kvm_getswapinfo.o cc -O -pipe -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libkvm/kvm_proc.c -o kvm_proc.o /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libkvm/kvm_proc.c:129: `P_THREADED' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libkvm/kvm_proc.c:129: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libkvm/kvm_proc.c:129: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libkvm. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-06-15 05:23:22 - /usr/bin/make returned exit code 1 TB --- 2003-06-15 05:23:22 - ERROR: failed to build world TB --- 2003-06-15 05:23:22 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on i386/i386
TB --- 2003-06-15 04:22:57 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-06-15 04:22:57 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-15 04:25:47 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4: building libraries [...] cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm_file.c -o kvm_file.o cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm_getloadavg.c -o kvm_getloadavg.o cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm_getswapinfo.c -o kvm_getswapinfo.o cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm_proc.c -o kvm_proc.o /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm_proc.c:129: `P_THREADED' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm_proc.c:129: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libkvm/kvm_proc.c:129: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libkvm. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-06-15 04:40:32 - /usr/bin/make returned exit code 1 TB --- 2003-06-15 04:40:32 - ERROR: failed to build world TB --- 2003-06-15 04:40:32 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on alpha/alpha
TB --- 2003-06-15 04:00:16 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-06-15 04:00:16 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-15 04:02:40 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries [...] cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libkvm/kvm_file.c -o kvm_file.o cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libkvm/kvm_getloadavg.c -o kvm_getloadavg.o cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libkvm/kvm_getswapinfo.c -o kvm_getswapinfo.o cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -DLIBC_SCCS -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libkvm -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libkvm/kvm_proc.c -o kvm_proc.o /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libkvm/kvm_proc.c:129: `P_THREADED' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libkvm/kvm_proc.c:129: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libkvm/kvm_proc.c:129: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libkvm. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-06-15 04:18:46 - /usr/bin/make returned exit code 1 TB --- 2003-06-15 04:18:46 - ERROR: failed to build world TB --- 2003-06-15 04:18:46 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
World is still broken. Please fix.
Is anybody testing his changes before he commits them ? In file included from /usr/obj/usr/src/i386/usr/include/sys/types.h:45, from /usr/src/usr.bin/xlint/llib/llib-lposix:39: /usr/obj/usr/src/i386/usr/include/sys/cdefs.h:148:2: #error FreeBSD alloca support needed for this compiler *** Error code 1 Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: World is still broken. Please fix.
Martin Blapp said: In file included from /usr/obj/usr/src/i386/usr/include/sys/types.h:45, from /usr/src/usr.bin/xlint/llib/llib-lposix:39: /usr/obj/usr/src/i386/usr/include/sys/cdefs.h:148:2: #error FreeBSD alloca support needed for this compiler *** Error code 1 DES sent me a patch for this as I reported it yesterday. I have just this minute succesfully built world with it applied, so DES it works fine. Regards, Matt. -- email: [EMAIL PROTECTED] - web: http://xtaz.co.uk/ Hardware, n.: The parts of a computer system that can be kicked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: rpc.yppasswdd working again
Small, but important message for NIS users. All users who had problems with NIS should rebuild their world. Long outstanding problems have been fixed and rpc.yppasswdd allows root again to change passwords on ypmaster without knowledge of the users password. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Unable to build world. multiple symptoms
I updated my 5.0-CURRENT sources yesterday (Saturday morning) and ran my buildworld script. When the compiles failed, I searched the mailing lists and found someone else having the same problem. His solution was to change the -j value (I was running with -j10 on my dual processor AMD). I have tried all the way down to -j1 and the compiles still fail. I took the -j value out completely and it still fails. Running without the -j value at all got me the error message #error FreeBSD alloca support needed for this compiler from /usr/obj/usr/src/i386/usr/include/sys/cdefs.h: I cannot find any response in the archive to either Email. I saved tails of some of the failing compiles with various -j values if someone wants to see them. TIA for any help. Cheers... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to build world. multiple symptoms
On Sun, Jun 15, 2003 at 08:11:16AM -0400, Tom Parquette wrote: I updated my 5.0-CURRENT sources yesterday (Saturday morning) and ran my buildworld script. When the compiles failed, I searched the mailing lists and found someone else having the same problem. His solution was to change the -j value (I was running with -j10 on my dual processor AMD). I have tried all the way down to -j1 and the compiles still fail. I took the -j value out completely and it still fails. Running without the -j value at all got me the error message #error FreeBSD alloca support needed for this compiler from /usr/obj/usr/src/i386/usr/include/sys/cdefs.h: I cannot find any response in the archive to either Email. I saved tails of some of the failing compiles with various -j values if someone wants to see them. Please resup and try again. -- Rgdz,/\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to build world. multiple symptoms
On Sun, Jun 15, 2003 at 08:11:16AM -0400, Tom Parquette wrote: ... # Running without the -j value at all got me the error message #error # FreeBSD alloca support needed for this compiler from # /usr/obj/usr/src/i386/usr/include/sys/cdefs.h: This was fixed in rev 1.71 of cdefs.h. Update your source tree. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: rpc.yppasswdd working again
Martin Blapp writes: Small, but important message for NIS users. All users who had problems with NIS should rebuild their world. Long outstanding problems have been fixed and rpc.yppasswdd allows root again to change passwords on ypmaster without knowledge of the users password. Does this not create a vulnerability? Example: Bad Guy sets up a personal workstation with himself as root and steals an IP address from the machine he just switched off. Now he can change passwords on the server at will. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.firewall not executed?
On Sat, 14 Jun 2003, Kris Kennaway wrote: I just noticed that my ipfw rules were not loaded the last time I rebooted. My rc.conf is included below - has something changed recently so that these settings are not enough? I didn't see anything relevant in UPDATING. My /etc/firewall.conf exists and is readable (and unchanged since 2002). Kris # $FreeBSD: src/etc/defaults/rc.conf,v 1.156 2002/08/30 13:01:42 hm Exp $ hostname=citusc17.usc.edu # Set this! nisdomainname=cituscdomain# Set to NIS domain if using NIS (or NO). firewall_enable=YES # Set to YES to enable firewall functionality firewall_type=/etc/firewall.conf # Firewall type (see /etc/rc.firewall) ^^ This is wrong. Set it to UNKNOWN. There's firewall_script for that. Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB locks on laptops.
On Sat, 14 Jun 2003, David Gilbert wrote: While I thought it might be an isolated example, I have several laptops ... all of which lock up their ports when usb devices are connected. Typical messages include: usb3: unrecoverable error, controller halted and usb3: device problem, disabling port 3 ... which is an example from a new laptop with usb2.0, but an older laptop with usb1.0 gives similar messages. Jun 14 00:09:48 canoe /kernel: uhub0: device problem, disabling port 2 Now... on non-portable hardware, usb ports all seem to work. All of my desktop machine's USB ports work just fine with the same hardware. Any ideas? Disabling ACPI fixed this type of issue on a couple of HP notebooks I have access to. Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: rpc.yppasswdd working again
hi, All users who had problems with NIS should rebuild their world. Long outstanding problems have been fixed and rpc.yppasswdd allows root again to change passwords on ypmaster without knowledge of the users password. Does this not create a vulnerability? Example: Bad Guy sets up a personal workstation with himself as root and steals an IP address from the machine he just switched off. Now he can change passwords on the server at will. It is only possible on the ypmaster server. And if you are root you can edit the password files directly, can't you :-) ? Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.firewall not executed?
On Sun, Jun 15, 2003 at 09:36:23AM -0400, Andre Guibert de Bruet wrote: On Sat, 14 Jun 2003, Kris Kennaway wrote: I just noticed that my ipfw rules were not loaded the last time I rebooted. My rc.conf is included below - has something changed recently so that these settings are not enough? I didn't see anything relevant in UPDATING. My /etc/firewall.conf exists and is readable (and unchanged since 2002). Kris # $FreeBSD: src/etc/defaults/rc.conf,v 1.156 2002/08/30 13:01:42 hm Exp $ hostname=citusc17.usc.edu # Set this! nisdomainname=cituscdomain# Set to NIS domain if using NIS (or NO). firewall_enable=YES # Set to YES to enable firewall functionality firewall_type=/etc/firewall.conf # Firewall type (see /etc/rc.firewall) ^^ This is wrong. Set it to UNKNOWN. There's firewall_script for that. It is not incorrect. See rc.firewall. By providing a filename for the firewall_type, rc.firewall will instead load the ipfw rules from the given filename. From rc.firewall: # Define the firewall type in /etc/rc.conf. Valid values are: # open - will allow anyone in # client - will try to protect just this machine # simple - will try to protect a whole network # closed - totally disables IP services except via lo0 interface # UNKNOWN - disables the loading of firewall rules. # filename - will load the rules in the given filename (full path # required) However, I unfortunately do not have an answer for Kris as to why the rules aren't loading anymore. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-RELEASE TODO
This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. FreeBSD 5.2 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.2. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.2-RELEASE ++ |Issue| Status | Responsible | Description | |-+--+-+-| | | | | KSE M:N threading | | | | | support is reaching | | | | | experimental yet| | | | Julian | usable status on| | Production-quality | In | Elischer, David | i386 for| | M:N threading | progress | Xu, Daniel | 5.1-RELEASE. M:N| | | | Eischen | threading should be | | | | | productionable and | | | | | usable on all | | | | | platforms by| | | | | 5.2-RELEASE.| |-+--+-+-| | | | | Currently, the MD | | | | | elements of KSE are | | | | | present only for| | | | | the i386 platform, | | | | | limiting use of KSE | | | | | to the i386 | | | | | platform. It is | | | | | highly desirable to | | KSE support for | | Jake| make KSE available | | sparc64, alpha, | -- | Burkholder, --, | on non-i386 | | ia64| | -- | platforms for | | | | | 5.2-RELEASE so that | | | | | KSE can see more| | | | | broad exposure, and | | | | | the performance | | | | | benefits of KSE can | | | | | be visible to users | | | | | of the 64-bit | | | | | FreeBSD | | | | | architectures. | |-+--+-+-| | | | | Kris Kennaway | | | | | reports high| | | | | instability of | | | | | 5-CURRENT on ia64 | | | In | Marcel | machines, such as | | ia64 stability | Progress | Moolenaar | the pluto* | | | | | machines. These | | | | | problems need to be | | | | | fixed in order to | | | | | get a successful| | | | | package build. | |-+--+-+-| | | | | ia64 serial console | | | | | support is reported | | | | | to not be | | | | | functional on HP| | | In | Marcel | Itanium2 platforms. | | ia64 sio support| progress | Moolenaar, | A reworking of the | | | | Warner Losh | sio driver to | | | | | improve platform| | | | | independence and| |
Patch review [was: Re: viapropm doesnt like sys/dev/pci.c rev 1.214]
On Thu, Jun 05, 2003 at 04:17:38AM -0700, Terry Lambert wrote:
How about RF_DONTCHECK or RF_ALWAYSWORKS? It better implies
what's happening here, since you're going to assume success in
the face of diagnostics to the contrary.
So instead of:
if (flag)
return (0);
command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
if (command bit)
return (0);
device_printf(child, failed to enable %s mapping!\n, error);
return (ENXIO);
You do:
command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
if ((command bit) || flag)
return (0);
device_printf(child, failed to enable %s mapping!\n, error);
return (ENXIO);
Yeah, I know the disctinction is subtle, but there migh be other
PCI_READ_CONFIG() results later that people care about, besides
just this one bit, which *do* work on some other chip with the
same issue.
Sounds good like that? (ignore more changes in amdpm.c. Just consider
that RF_DONTCHECK was added to the resource allocation). Note that
AMD-768 PM has the same flaw as the VIA chipset.
Index: dev/cardbus/cardbus_cis.c
===
RCS file: /home/ncvs/src/sys/dev/cardbus/cardbus_cis.c,v
retrieving revision 1.37
diff -u -r1.37 cardbus_cis.c
--- dev/cardbus/cardbus_cis.c 24 May 2003 23:23:41 - 1.37
+++ dev/cardbus/cardbus_cis.c 15 Jun 2003 16:05:16 -
@@ -457,7 +457,7 @@
* Mark the appropriate bit in the PCI command register so that
* device drivers will know which type of BARs can be used.
*/
- pci_enable_io(child, type);
+ pci_enable_io(child, type, 0);
return (0);
}
@@ -624,7 +624,7 @@
rman_get_start(res) | ((*rid == CARDBUS_ROM_REG)?
CARDBUS_ROM_ENABLE : 0),
4);
- PCI_ENABLE_IO(cbdev, child, SYS_RES_MEMORY);
+ PCI_ENABLE_IO(cbdev, child, SYS_RES_MEMORY, 0);
/* Flip to the right ROM image if CIS is in ROM */
if (CARDBUS_CIS_SPACE(*start) == CARDBUS_CIS_ASI_ROM) {
Index: dev/hifn/hifn7751.c
===
RCS file: /home/ncvs/src/sys/dev/hifn/hifn7751.c,v
retrieving revision 1.13
diff -u -r1.13 hifn7751.c
--- dev/hifn/hifn7751.c 11 Mar 2003 22:47:06 - 1.13
+++ dev/hifn/hifn7751.c 15 Jun 2003 16:03:43 -
@@ -616,7 +616,7 @@
/* reenable busmastering */
pci_enable_busmaster(dev);
- pci_enable_io(dev, HIFN_RES);
+ pci_enable_io(dev, HIFN_RES, 0);
/* reinitialize interface if necessary */
if (ifp-if_flags IFF_UP)
Index: dev/pci/pci.c
===
RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.214
diff -u -r1.214 pci.c
--- dev/pci/pci.c 16 Apr 2003 03:15:08 - 1.214
+++ dev/pci/pci.c 15 Jun 2003 15:25:57 -
@@ -583,7 +583,7 @@
}
int
-pci_enable_io_method(device_t dev, device_t child, int space)
+pci_enable_io_method(device_t dev, device_t child, int space, u_int flags)
{
u_int16_t command;
u_int16_t bit;
@@ -607,7 +607,7 @@
}
pci_set_command_bit(dev, child, bit);
command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
- if (command bit)
+ if ((command bit) || (flags RF_DONTCHECK))
return (0);
device_printf(child, failed to enable %s mapping!\n, error);
return (ENXIO);
@@ -1365,7 +1365,7 @@
* Enable the I/O mode. We should also be allocating
* resources too. XXX
*/
- if (PCI_ENABLE_IO(dev, child, type))
+ if (PCI_ENABLE_IO(dev, child, type, flags))
return (NULL);
break;
}
Index: dev/pci/pci_if.m
===
RCS file: /home/ncvs/src/sys/dev/pci/pci_if.m,v
retrieving revision 1.5
diff -u -r1.5 pci_if.m
--- dev/pci/pci_if.m16 Apr 2003 03:15:08 - 1.5
+++ dev/pci/pci_if.m15 Jun 2003 15:23:23 -
@@ -70,6 +70,7 @@
device_tdev;
device_tchild;
int space;
+ u_int flags;
};
METHOD int disable_io {
Index: dev/pci/pci_private.h
===
RCS file: /home/ncvs/src/sys/dev/pci/pci_private.h,v
retrieving revision 1.8
diff -u -r1.8 pci_private.h
--- dev/pci/pci_private.h 16 Apr 2003 03:15:08 - 1.8
+++ dev/pci/pci_private.h 15 Jun 2003 15:27:55 -
@@ -56,7 +56,8 @@
int reg, u_int32_t val, int width);
intpci_enable_busmaster_method(device_t dev, device_t child);
intpci_disable_busmaster_method(device_t dev, device_t child);
-int
Re: HEADS UP: rpc.yppasswdd working again
he can change passwords on the server at will. From the rpc.yppasswdd manpage: The FreeBSD version of rpc.yppasswdd also allows the super-user on the NIS master server to perform more sophisticated updates on the NIS passwd maps. The super-user can modify any field in any user's master.passwd entry in any domain, and can do so without knowing the user's existing NIS password (when the server receives a request from the super-user, the password authentication check is bypassed). Furthermore, if the server is invoked with the -a flag, the super-user can even add new entries to the maps using ypchpass(1). Again, this only applies to the super-user on the NIS master server: none of these special functions can be performed over the network. The rpc.yppasswdd utility can only be run on a machine that is an NIS master server. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: rpc.yppasswdd working again
Martin Blapp writes: maps using ypchpass(1). Again, this only applies to the super-user on the NIS master server: none of these special functions can be performed over the network. I am happy! M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA C3
On Fri, Jun 13, 2003 at 06:33:56PM -0700, David Yeske wrote: Anyone have a VIA C3? I'm running FreeBSD current on one and I don't see any gcc flags for the VIA C3. I think it has MMX and 3dnow, but it does not have SSE? Up to the Ezra kernel the C3 doesn't suppoert SSE. Only the newest C3-kernel named Nehemiah does have it. I was wondering what gcc flags other VIA C3 users are using on FreeBSD. I am not sure what optimizations are safe for this cpu running FreeBSD. CPU: VIA/IDT Unknown (998.70-MHz 686-class CPU) Origin = CentaurHauls Id = 0x689 Stepping = 9 Features=0x803035FPU,DE,TSC,MSR,MTRR,PGE,MMX This one doesn't seem to support SSE, though I wonder why there is this unknown. My C3 here is an Ezra and is identified as Samuel2 with id=067a. However, if you have a C3 without SSE, it's basically a K6 with MMX and 3dNow. So I'm using CPUTYPE=k6-3 in /etc/make.conf. Up to now this has been working fine for me. cu Gerrit -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Question about developers handbook definition of encumbered.
As I am slowly trying to get my feet wet with kernel programming I was browsing through the developers handbook. The following surprised me a bit: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ policies-encumbered.html So this claims that GNU licensing is *not* encumbered... is this correct? Based on recent discussion threads on this list I would assume it is not correct. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum and/or geom panic on alpha
On Sat, Jun 14, 2003 at 03:15:27PM +0930, Greg 'groggy' Lehey wrote: On Tuesday, 10 June 2003 at 14:05:11 +0200, Bernd Walter wrote: fatal kernel trap: Stopped at g_dev_strategy+0x44:stq t0,0x20(v0) 0x20 t0=0x1a61da400,v0=0x0 db trace g_dev_strategy() at g_dev_strategy+0x44 launch_requests() at launch_requests+0x390 prologue botch: displacement 128 frame size botch: adjust register offsets? vinumstart() at vinumstart+0x250 prologue botch: displacement 64 frame size botch: adjust register offsets? intr_n() at 0xccec340 Can you check the locals of launch_requests(), please? Unfortunately it's currently not possible. IIRC gdb -k doesn't work on alpha and I can't get a crashdump. Last night I had the same panic on an i386 system, but it refused to do a crashdump :( Currently I'm seeing this problem on the following systems: SMP alpha / 21164A CPUs / 5.1-RELEASE UP alpha / 21164A CPU / 5.1-CURRENT (8th june) UP i386 / AMD K6 CPU / 5.1-BETA (10th may with some NFS fixes) I will arrange things for a remote gdb session and hope for the next panic to happen on the prepared machine. -- 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]
tweaks to sysctl integer value parsing (report any problems)
Last night, I committed some tweaks to how sysctl integer value parsing occurs. The motivation for these changes was the outcome of finding the following in my sysctl.conf: kern.maxfiles=4000 Which, to my great sadness, occurred on a box without DDB or remote power. For the uninitiated, until my recent commit, the 4000 would converted to 0, resulting in severely degraded operation (your kernel now exists solely to report that it is out of files after a reboot). Now, sysctl will reject poorly formatted values that will be converted to integers, as well as empty strings in the integer conversion. This means that the following will now generate an error: kern.maxfiles= # previously: 0 kern.maxfiles=5 # previously: 5 I'm not convinced my changes are 100% ideal, so I'm going to be on the lookout for posts saying my sysctl.conf no longer works!, and perhaps we can refine the approach a bit. On the other hand, I now have only one working foot after my recent foot-shooting exercise, so I'm fairly convinced that some change, even if not this precise change, is necessary :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on alpha/alpha
TB --- 2003-06-15 16:00:15 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-06-15 16:00:15 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-15 16:04:47 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-15 17:02:16 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sun Jun 15 17:02:16 GMT 2003 Kernel build for GENERIC completed on Sun Jun 15 17:13:36 GMT 2003 TB --- 2003-06-15 17:13:36 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-15 17:13:36 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sun Jun 15 17:13:36 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-06-15 17:16:47 - /usr/bin/make returned exit code 1 TB --- 2003-06-15 17:16:47 - ERROR: failed to build lint kernel TB --- 2003-06-15 17:16:47 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems with pcmcia on 5.1-RELEASE
I have just installed FreeBSD 5.1-RELEASE on my laptop, and everything but my trusty pcmcia cdrom drive is working great. The kernel finds the pcmcia slot: cbb0: ToPIC100 PCI-CardBus Bridge at device 11.0 on pci0 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 However, when I insert the card, I get the following: pccard0: unknown card (manufacturer=0x, product=0x) at function 0 pccard0:CIS info: FREECOM, PCCARD-IDE, REV836 From what I can read in /etc/defaults/pccard.conf, this device is supposed to be supported (And it always worked fine under linux). I have put pccard_enable=YES in my rc.conf, but pccardd doesn't start because there is no /dev/card0. Does anyone have a hint, that will help me get this working? Thanks in advance. -- Best regards Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on i386/i386
TB --- 2003-06-15 17:18:23 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-06-15 17:18:23 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-15 17:21:51 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-15 18:14:53 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sun Jun 15 18:14:53 GMT 2003 Kernel build for GENERIC completed on Sun Jun 15 18:28:27 GMT 2003 TB --- 2003-06-15 18:28:27 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-15 18:28:27 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sun Jun 15 18:28:27 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-06-15 18:33:15 - /usr/bin/make returned exit code 1 TB --- 2003-06-15 18:33:15 - ERROR: failed to build lint kernel TB --- 2003-06-15 18:33:15 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with pcmcia on 5.1-RELEASE
Does anyone have a hint, that will help me get this working?
[cut and paste]
--- ata-card.c 3 Jun 2003 01:30:55 - 1.13
+++ ata-card.c 15 Jun 2003 18:46:28 -
@@ -53,6 +53,8 @@
PCMCIA_CARD(OEM2, IDE, 0),
PCMCIA_CARD(PANASONIC, KXLC005, 0),
PCMCIA_CARD(TEAC, IDECARDII, 0),
+ { FREECOM PCCARD-IDE, PCCARD_VENDOR_ANY, PCCARD_PRODUCT_ANY, 0,
+ { FREECOM, PCCARD-IDE, NULL, NULL } },
{NULL}
};
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on i386/pc98
TB --- 2003-06-15 18:33:18 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-06-15 18:33:18 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-15 18:36:07 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-15 19:29:03 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sun Jun 15 19:29:03 GMT 2003 Kernel build for GENERIC completed on Sun Jun 15 19:40:24 GMT 2003 TB --- 2003-06-15 19:40:24 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-15 19:40:24 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sun Jun 15 19:40:24 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-06-15 19:44:01 - /usr/bin/make returned exit code 1 TB --- 2003-06-15 19:44:01 - ERROR: failed to build lint kernel TB --- 2003-06-15 19:44:01 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: misc/53327: Important fix for Latin-american keymap(Latin-amer.kbd)
Hi guys, Last time I submitted a change to this file it took like a year to get it committed.. any chance this can be committed and MFC really soon? It would make a continent happy :). cheers, Pedro. --- [EMAIL PROTECTED] ha scritto: Thank you very much for your problem report. It has the internal identification `misc/53327'. The individual assigned to look at your report is: freebsd-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=53327 Category: misc Responsible:freebsd-bugs Synopsis: Important fix for Latin-american keymap Arrival-Date: Sat Jun 14 14:10:14 PDT 2003 __ Yahoo! Mail: 6MB di spazio gratuito, 30MB per i tuoi allegati, l'antivirus, il filtro Anti-spam http://it.yahoo.com/mail_it/foot/?http://it.mail.yahoo.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with pcmcia on 5.1-RELEASE
Matthew N. Dodd [EMAIL PROTECTED] writes:
Does anyone have a hint, that will help me get this working?
[cut and paste]
--- ata-card.c 3 Jun 2003 01:30:55 - 1.13
+++ ata-card.c 15 Jun 2003 18:46:28 -
@@ -53,6 +53,8 @@
PCMCIA_CARD(OEM2, IDE, 0),
PCMCIA_CARD(PANASONIC, KXLC005, 0),
PCMCIA_CARD(TEAC, IDECARDII, 0),
+ { FREECOM PCCARD-IDE, PCCARD_VENDOR_ANY, PCCARD_PRODUCT_ANY, 0,
+ { FREECOM, PCCARD-IDE, NULL, NULL } },
{NULL}
};
Thanks, this gets me an extra ata-channel when I insert the card.
However, no devices are found on it.
ata2: FREECOM PCCARD-IDE at port 0x100-0x10f irq 11 function 0 config 1 on pccard0
vulcan# atacontrol info ata2
Master: no device present
Slave: no device present
I believe tha master should be the cdrom drive.
--
Best regards
Christian Laursen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
write access to dos partition hangs system completely
FreeBSD titan.klemm.apsfilter.org 5.1-RC FreeBSD 5.1-RC #0: Sun Jun 1 14:21:32 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TITAN5 i386 When I mount my dos partition read write and copy some data to it it immediately freezes the system. Is this a known problem ? The DOS (/dosc) partition is ~30 GB large, FAT32. Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s1 30701264 27581456 311980890%/dosc /dev/ad2s5 20472848 4272688 1620016021%/dosd dmesg output: 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-RC #0: Sun Jun 1 14:21:32 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TITAN5 Preloaded elf kernel /boot/kernel/kernel at 0xc04d8000. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04d81f4. Preloaded elf module /boot/kernel/snd_emu10k1.ko at 0xc04d82a0. Preloaded elf module /boot/kernel/acpi.ko at 0xc04d8350. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 997461662 Hz CPU: Intel Pentium III (997.46-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 536854528 (511 MB) avail memory = 516145152 (492 MB) Pentium Pro MTRR support enabled VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc03eb202 (122) VESA: NVidia npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS MED_2001 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 6 entries at 0xc00f0eb0 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 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xfc00-0xfdff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686A UDMA66 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 5 at device 4.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ulpt0: Hewlett-Packard PSC 2200 Series, rev 2.00/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode umass0: Hewlett-Packard PSC 2200 Series, rev 2.00/1.00, addr 2 ugen0: Syncrosoft Protected Executer, rev 1.10/1.01, addr 3 uhci1: VIA 83C572 USB controller port 0xd000-0xd01f irq 5 at device 4.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pcm0: Creative EMU10K1 port 0xb800-0xb81f irq 9 at device 9.0 on pci0 pcm0: TriTech TR28023 AC97 Codec pci0: multimedia, audio at device 10.0 (no driver attached) fxp0: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 0x9800-0x983f mem 0xed00-0xed0f,0xed80-0xed800fff irq 10 at device 11.0 on pci0 fxp0: Ethernet address 00:d0:b7:ba:c1:c2 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse Explorer, device ID 4 orm0: Option ROMs at iomem 0xcc000-0xccfff,0xc-0xcb7ff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0% ad0: 76319MB ST380021A [155061/16/63] at ata0-master UDMA66 ad2: 38166MB ST340823A [77545/16/63] at ata1-master UDMA66 acd0: CD-RW
Re: Problems with pcmcia on 5.1-RELEASE
On Sun, 15 Jun 2003, Christian Laursen wrote: However, no devices are found on it. ata2: FREECOM PCCARD-IDE at port 0x100-0x10f irq 11 function 0 config 1 on pccard0 vulcan# atacontrol info ata2 Master: no device present Slave: no device present I believe tha master should be the cdrom drive. 'atacontrol attach 2' or 'atacontrol reinit 2' -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: write access to dos partition hangs system completely
[EMAIL PROTECTED] wrote: FreeBSD titan.klemm.apsfilter.org 5.1-RC FreeBSD 5.1-RC #0: Sun Jun 1 14:21:32 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TITAN5 i386 When I mount my dos partition read write and copy some data to it it immediately freezes the system. Is this a known problem ? I do have exactly the same problem with my CF-Reader. I don't know why but I can hardly imagine it has to do with MSDOSFS. I have my new CF-Reader (4in1 Datafab USB Reader (umass-sim)) under suspicion. Perhaps someone could isolate this bug. If I can do anything please let me know (I'm not used to debuggers etc.) Best regards, -Harry The DOS (/dosc) partition is ~30 GB large, FAT32. Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s1 30701264 27581456 311980890%/dosc /dev/ad2s5 20472848 4272688 1620016021%/dosd dmesg output: 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-RC #0: Sun Jun 1 14:21:32 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TITAN5 Preloaded elf kernel /boot/kernel/kernel at 0xc04d8000. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04d81f4. Preloaded elf module /boot/kernel/snd_emu10k1.ko at 0xc04d82a0. Preloaded elf module /boot/kernel/acpi.ko at 0xc04d8350. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 997461662 Hz CPU: Intel Pentium III (997.46-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,MMX,FXSR,SSE real memory = 536854528 (511 MB) avail memory = 516145152 (492 MB) Pentium Pro MTRR support enabled VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc03eb202 (122) VESA: NVidia npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS MED_2001 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 6 entries at 0xc00f0eb0 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 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xfc00-0xfdff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686A UDMA66 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 5 at device 4.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ulpt0: Hewlett-Packard PSC 2200 Series, rev 2.00/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode umass0: Hewlett-Packard PSC 2200 Series, rev 2.00/1.00, addr 2 ugen0: Syncrosoft Protected Executer, rev 1.10/1.01, addr 3 uhci1: VIA 83C572 USB controller port 0xd000-0xd01f irq 5 at device 4.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pcm0: Creative EMU10K1 port 0xb800-0xb81f irq 9 at device 9.0 on pci0 pcm0: TriTech TR28023 AC97 Codec pci0: multimedia, audio at device 10.0 (no driver attached) fxp0: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 0x9800-0x983f mem 0xed00-0xed0f,0xed80-0xed800fff irq 10 at device 11.0 on pci0 fxp0: Ethernet address 00:d0:b7:ba:c1:c2 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse Explorer, device ID 4 orm0: Option ROMs
Re: Problems with pcmcia on 5.1-RELEASE
Matthew N. Dodd [EMAIL PROTECTED] writes: On Sun, 15 Jun 2003, Christian Laursen wrote: However, no devices are found on it. ata2: FREECOM PCCARD-IDE at port 0x100-0x10f irq 11 function 0 config 1 on pccard0 vulcan# atacontrol info ata2 Master: no device present Slave: no device present I believe tha master should be the cdrom drive. 'atacontrol attach 2' or 'atacontrol reinit 2' I'm sorry, but that doesn't give anything. vulcan# atacontrol attach 2 atacontrol: ioctl(ATAATTACH): File exists vulcan# atacontrol reinit 2 Master: no device present Slave: no device present vulcan# atacontrol detach 2 vulcan# atacontrol attach 2 Master: no device present Slave: no device present -- Best regards Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-06-15 21:07:21 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-15 21:07:21 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-15 21:09:31 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-15 22:01:24 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sun Jun 15 22:01:24 GMT 2003 Kernel build for GENERIC completed on Sun Jun 15 22:10:12 GMT 2003 TB --- 2003-06-15 22:10:12 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-15 22:10:13 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sun Jun 15 22:10:13 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-15 22:12:57 - /usr/bin/make returned exit code 1 TB --- 2003-06-15 22:12:57 - ERROR: failed to build lint kernel TB --- 2003-06-15 22:12:57 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OK, how about now? PFIL_HOOKS
Now that 5.0 has been released, can we please make PFIL_HOOKS the default? 5.1 released, still not committed. How about now? :) -- Michael Nottebrock And the reasons? There are no reasons. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Possible EHCI bugs
I was recently contacted by an individual at Transmeta who was trying to use FreeBSD current with a board containing an EHCI USB controller and encountered some problems with it. He original intent was to use FreeBSD's USB 2.0 support and the if_axe driver to help debug a problem with said hardware combination with another OS which shall remain nameless. Along the way, he discovered the following: - The USB_ATTACH() routine in if_axe.c would lead to a panic because uaa-iface was NULL. I consider this a bit peculiar because a) with my own test setup (my laptop, with UHCI controller), uaa-iface is always populated, and b) uaa-iface is set to something during the USB_PROBE() routine (it must be, otherwise the probe would fail). I worked around this by grabbing the interface handle using usbd_device2interface_handle(), but having the EHCI driver behave inconsistently with respect to the UHCI and OHCI driver seems a bit counterintuitive. - The system panics under load. In this case, the load was induced by running bonnie on an NFS filesystem mount over the axe0 interface. Below is the console output with stack trace: stray irq 7 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-CURRENT #3: Fri Jun 13 00:40:59 PDT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/EHCI Preloaded elf kernel /boot/kernel/kernel at 0xc0722000. Preloaded elf module /boot/kernel/acpi.ko at 0xc0722294. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 800032593 Hz CPU: Transmeta Proprietary/Confidential-NDA Required (800.03-MHz 686-class CPU) Origin = GenuineTMx86 Id = 0xf24 real memory = 233766912 (222 MB) avail memory = 219463680 (209 MB) npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00fdf00 ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.AC__._STA] (Node 0xc227d4c0), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\_SB_.PCI0.AC__._STA] (Node 0xc227d4c0), AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.BATT._STA] (Node 0xc227d400), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\_SB_.PCI0.BATT._STA] (Node 0xc227d400), AE_AML_REGION_LIMIT acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.AC__._STA] (Node 0xc227d4c0), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\_SB_.PCI0.AC__._STA] (Node 0xc227d4c0), AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.BATT._STA] (Node 0xc227d400), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\_SB_.PCI0.BATT._STA] (Node 0xc227d400), AE_AML_REGION_LIMIT acpi_timer0: 32-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 4 INTA is routed to irq 11 pcib0: slot 14 INTB is routed to irq 10 pcib0: slot 15 INTA is routed to irq 11 pcib0: slot 15 INTB is routed to irq 10 pcib0: slot 15 INTD is routed to irq 7 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib1: slot 0 INTA is routed to irq 11 pci1: display, VGA at device 0.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 2.0 on pci0 pci2: ACPI PCI bus on pcib2 isab0: PCI-ISA bridge at device 3.0 on pci0 isa0: ISA bus on isab0 pci0: bridge, PCI-unknown at device 3.1 (no driver attached) pci0: multimedia, audio at device 4.0 (no driver attached) atapci0: AcerLabs Aladdin UDMA100 controller port 0x80a0-0x80af,0x374-0x377,0x170-0x17f,0x3f4-0x3f7,0x1f0-0x1ff at device 14.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: network, ethernet at device 14.1 (no driver attached) ohci0: AcerLabs M5237 (Aladdin-V) USB controller mem 0xe-0xe0fff irq 11 at device 15.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: AcerLabs M5237 (Aladdin-V) USB controller on ohci0 usb0: USB revision 1.0 uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: device problem, disabling port 2 ohci1: AcerLabs M5237 (Aladdin-V) USB controller mem 0xe8002000-0xe8002fff irq 10 at device 15.1 on pci0 usb1: OHCI version 1.0, legacy support usb1: AcerLabs M5237 (Aladdin-V) USB controller on ohci1 usb1: USB revision 1.0 uhub1: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0: EHCI
Re: Possible EHCI bugs
On Sun, Jun 15, 2003 at 03:59:48PM -0700, Bill Paul wrote: I was recently contacted by an individual at Transmeta who was trying to use FreeBSD current with a board containing an EHCI USB controller and encountered some problems with it. He original intent was to use FreeBSD's USB 2.0 support and the if_axe driver to help debug a problem with said hardware combination with another OS which shall remain nameless. Along the way, he discovered the following: - The USB_ATTACH() routine in if_axe.c would lead to a panic because uaa-iface was NULL. I consider this a bit peculiar because a) with my own test setup (my laptop, with UHCI controller), uaa-iface is always populated, and b) uaa-iface is set to something during the USB_PROBE() routine (it must be, otherwise the probe would fail). I worked around this by grabbing the interface handle using usbd_device2interface_handle(), but having the EHCI driver behave inconsistently with respect to the UHCI and OHCI driver seems a bit counterintuitive. - The system panics under load. In this case, the load was induced by running bonnie on an NFS filesystem mount over the axe0 interface. USB_DEBUG with sysctl hw.usb.ehci.debug=1 during attach and shortly befor the panic could help. I hope it doesn't produce too much output during bonnie run. The first case could be timing thing - some devices behave differently on high speed than on full speed. Fri Jun 13 01:01:06 PDT 2003 Jaxe0: read PHY failed axe0: read PHY failed axe0: read PHY failed axe0: read PHY failed Were these over time or shortly befor the panic? Memory modified after free 0xc22e8310(12) panic: Most recently used by USB This seems to indicate something in the USB code is re-using a free()ed memory buffer. Unfortunately, I don't have this particular hardware available to me, and I don't know how much debugging support the individual at Transmeta will be able to offer. (He has his own problems.) Hopefully this will at least help spur some investigation. Unfortunately there are many places where such problems could happen. Without reviewing the complete ehci code it's difficult to get an idea about what went wrong. -- 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]
Re: reviving rp-pppoe
Matthias Andree schrieb: Hi, as a band-aid fix, because 5.1-CURRENT's ppp or netgraph or whatever is spoiled and PPPoE no longer works Isn't this supposed to be fixed by the backouts of the c-standard related changes to bsd.sys.mk? -- Michael Nottebrock ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: reviving rp-pppoe
On Mon, Jun 16, 2003 at 01:37:03AM +0200, Michael Nottebrock wrote: Matthias Andree schrieb: Hi, as a band-aid fix, because 5.1-CURRENT's ppp or netgraph or whatever is spoiled and PPPoE no longer works Isn't this supposed to be fixed by the backouts of the c-standard related changes to bsd.sys.mk? Yes. Kris pgp0.pgp Description: PGP signature
Re: rc.firewall not executed?
On Sun, Jun 15, 2003 at 09:36:23AM -0400, Andre Guibert de Bruet wrote: On Sat, 14 Jun 2003, Kris Kennaway wrote: I just noticed that my ipfw rules were not loaded the last time I rebooted. My rc.conf is included below - has something changed recently so that these settings are not enough? I didn't see anything relevant in UPDATING. My /etc/firewall.conf exists and is readable (and unchanged since 2002). Kris # $FreeBSD: src/etc/defaults/rc.conf,v 1.156 2002/08/30 13:01:42 hm Exp $ hostname=citusc17.usc.edu # Set this! nisdomainname=cituscdomain# Set to NIS domain if using NIS (or NO). firewall_enable=YES # Set to YES to enable firewall functionality firewall_type=/etc/firewall.conf # Firewall type (see /etc/rc.firewall) ^^ This is wrong. Set it to UNKNOWN. There's firewall_script for that. Nope..read rc.firewall(5) :-) Kris pgp0.pgp Description: PGP signature
qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
I've been running qmail for years and like it, installed pretty much per www.LifeWithQmail.org. My main system was running FreeBSD 5.0-RELEASE and -CURRENT and qmail was fine. When I just upgraded to 5.1-CURRENT a couple days back, the qmail-send process started using all CPU. last pid: 22793; load averages: 1.06, 1.02, 1.00 up 0+08:13:46 20:36:32 74 processes: 2 running, 72 sleeping Mem: 38M Active, 51M Inact, 84M Wired, 28K Cache, 73M Buf, 452M Free Swap: 2048M Total, 2048M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 615 qmails 1320 1228K 616K RUN483:00 96.88% 96.88% qmail-send I noticed an identical complaint on the qmail list, to which there have so far been no replies (except you should ask the FreeBSD list): From: Luca Morettoni [EMAIL PROTECTED] Subject: qmail on FreeBSD 5.1-CURRENT To: [EMAIL PROTECTED] [...] qmail is run under daemontools and all work fine (the configuration is 2 years old!), but when I delivery the first mail (localy or remote) the qmail-send process fire up to 100% of CPU infinitely All other mail are right delivery, and the CPU use is the only problem, I see in qmail-send.c that select() function, after the first message, allways return 1 A truss shows me it's running in a tight loop over this code: open(lock/trigger,0x4,027757775230)= 8 (0x8) stat(todo,0xbfbffa00) = 0 (0x0) open(todo,0x4,01) = 9 (0x9) fstat(9,0xbfbffa00) = 0 (0x0) fcntl(0x9,0x2,0x1) = 0 (0x0) fstatfs(0x9,0xbfbff900) = 0 (0x0) getdirentries(0x9,0x8059000,0x1000,0x805a214)= 512 (0x200) gettimeofday(0xbfbffbc8,0x0) = 0 (0x0) select(0x9,0xbfbffcbc,0xbfbffc3c,0x0,0xbfbffc24) = 1 (0x1) gettimeofday(0xbfbffbc8,0x0) = 0 (0x0) gettimeofday(0xbfbffbc8,0x0) = 0 (0x0) select(0x9,0xbfbffcbc,0xbfbffc3c,0x0,0xbfbffc24) = 1 (0x1) gettimeofday(0xbfbffbc8,0x0) = 0 (0x0) getdirentries(0x9,0x8059000,0x1000,0x805a214)= 0 (0x0) lseek(9,0x0,0) = 0 (0x0) close(9) = 0 (0x0) gettimeofday(0xbfbffbc8,0x0) = 0 (0x0) select(0x9,0xbfbffcbc,0xbfbffc3c,0x0,0xbfbffc24) = 1 (0x1) gettimeofday(0xbfbffbc8,0x0) = 0 (0x0) close(8) = 0 (0x0) open(lock/trigger,0x4,027757775230)= 8 (0x8) I see nothing besides usual message delivery information in qmail's logs. Failing that, I rebuilt qmail and it seemed to have fixed it, but I didn't wait long enough: it's pegged at 100% CPU, constantly. If what Luca says is true, maybe it hadn't sent a message yet. Anyone else seen this or know what in FreeBSD-5.1 might have changed to cause this? Any thoughts on how I might go about diagnosing this any better? Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
sendmail authentication
I have been trying to get smtp authentication to work with Sendmail I have looked over and tried many times to install sasl and go through the directions on the following freebsd web page http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/smtp-auth.html When I get to the point of make sendmail I get the following error At the end of the make process I get CC: /usr/src/lib/libsmutil/libsmutil.a: No such file or directory CC: /usr/src/lib/libsm.a: No such file or directory *** Error code 1 The freebsd doc says the following about compiling sendmail: The compile of sendmail should not have any problems if /usr/src has not been changed extensively and the shared libraries it needs are available This is a fresh install of FreeBSD 4.8. I have not changed anything except installing apache, qpopper, and webmin. Any help would be appreciated. Thanks, Gary ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible EHCI bugs
On Sun, Jun 15, 2003 at 03:59:48PM -0700, Bill Paul wrote: I was recently contacted by an individual at Transmeta who was trying to use FreeBSD current with a board containing an EHCI USB controller and encountered some problems with it. He original intent was to use FreeBSD's USB 2.0 support and the if_axe driver to help debug a problem with said hardware combination with another OS which shall remain nameless. Along the way, he discovered the following: - The USB_ATTACH() routine in if_axe.c would lead to a panic because uaa-iface was NULL. I consider this a bit peculiar because a) with my own test setup (my laptop, with UHCI controller), uaa-iface is always populated, and b) uaa-iface is set to something during the USB_PROBE() routine (it must be, otherwise the probe would fail). I worked around this by grabbing the interface handle using usbd_device2interface_handle(), but having the EHCI driver behave inconsistently with respect to the UHCI and OHCI driver seems a bit counterintuitive. After the first quick reply now with a bit rethinking... The parameter is handled with common code - no differences here. This could possibly happen with every controller. And we have a hardware problem with the OHCI controller. As it's a companion controller sharing the mechanical port this could result in problems. ohci0: AcerLabs M5237 (Aladdin-V) USB controller mem 0xe-0xe0fff irq 11 at device 15.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting Workaround code responds here - I can't say if successfully, but I've seen other negative reports with OHCI part of Acer chips. usb0: AcerLabs M5237 (Aladdin-V) USB controller on ohci0 usb0: USB revision 1.0 uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: device problem, disabling port 2 The connected device failed! I asume it's the axe device, which should get probed here, because the ehci controller is not active yet. USB_DEBUG should tell us more about the cause. Note: we are strictly USB1.x at this time. ohci1: AcerLabs M5237 (Aladdin-V) USB controller mem 0xe8002000-0xe8002fff irq 10 at device 15.1 on pci0 usb1: OHCI version 1.0, legacy support usb1: AcerLabs M5237 (Aladdin-V) USB controller on ohci1 usb1: USB revision 1.0 uhub1: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered No problems reported with the second OHCI controller. ehci0: EHCI (generic) USB 2.0 controller mem 0xe8003400-0xe80034ff irq 7 at device 15.3 on pci0 ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: EHCI (generic) USB 2.0 controller on ehci0 usb2: USB revision 2.0 uhub2: AcerLabs EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered 6 Ports, but we have only 4 found by companion controllers! Those numbers should be identic. I'm missing PCI device 15:2! Maybe that should be a third OHCI controller with the remaning 2 ports. I'm not saying, that this is the reason for the reported problems, but I can tell you for shure that EHCI depends on working companion controllers. After this mass of problems I could also easily imagine hardwarebugs in the EHCI controller as well. We should get the hardware working first, befor we start fixing possibly symptoms in upper layers. This seems to indicate something in the USB code is re-using a free()ed memory buffer. Unfortunately, I don't have this particular hardware available to me, and I don't know how much debugging support the individual at Transmeta will be able to offer. (He has his own problems.) Hopefully this will at least help spur some investigation. It would be good if theres a chance to retry this test with a NEC based controller. Currently I'm not shure if it's really a software bug. -- 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]
Unable to boot 5.x on a Tyan S1836 Dual 333Mhz
I have been unable to boot 5 on this on particular system for several months and I'm at a loss as to what's causing the problem. The problems started right after I updated the BIOS to 1.18.02 from Tyan. Previously I believe it was running 1.16b. Note, that before the BIOS update, the system was able to boot 5-CURRENT w/o a problem. Now, I guess a solution would be to go back to 1.16b (I assume, haven't tried), but I don't understand why this new BIOS isn't working. The thing is, I have an almost identical machine with the same BIOS revision running -CURRENT w/o problems. The biggest difference is that the other machine has an older, ATI Mach64 PCI video card, whereas this one uses an All-In-Wonder Pro. Also, this machine has Windows XP on a separate disk and if I switch to boot from that disk, it boots and runs w/o a problem. Machine specs: Processor: Intel Pentium II 333 Mhz (dual) MP table spec. set to 1.1 motherboard: Tyan Thunder 100 S1836 (onboard ethernet, sound, ATA and SCSI) RAM: two 128 MB PC-100 DIMMs, for a total of 256 MB of RAM Disk: two SCSI drives, each on separate SCSI channels, attached to the motheboards internal AIC-7895 SCSI. One disk is a Wide/40, on channel B and a Fast 20 on Channel A. Also, on channel A there is a Sony DDS3 tape drive. There was a copy of 6 month old -CURRENT on the Fast/20 drive, but through all the experimentation, I am unable to boot from it any longer. Video: ATI All-In-Wonder Pro (Rage2 chipset) 8MB VRAM. Besides the All-In-Wonder, there are no other PCI slots being used. On the motherboard there is built in sound (SB Vibra 16) and ethernet (Intel 82559). I'm using PS/2 kb and mouse. I've tried countless BIOS settings. I've even reset the CMOS to be sure I haven't changed anything. I've tried both the optimal and fail safe AMI BIOS profiles, to no avail. I've tried enabling/disabling ACPI, PnP, APM, SCSI, ATA (normally disabled, since this machine is all-SCSI) USB and Parallel ports. I've changed the scan order of the PCI slots to last-first. None of it makes a difference.. always leading to the boot seen below: Here is a detailed boot log taken from a Serial terminal after using the 5.1-R boot disks (kern and mfsroot) to boot the system. I had to use a serial console, as when it crashes, it scrolls so fast I can't see where it stops. Also, it never hits the kernel debugger. Though, when booting from diskettes is DDB included? Here it goes: OK boot -v SMAP type=01 base= len=0009fc00 SMAP type=02 base=0009fc00 len=0400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=0ff0 SMAP type=02 base=fec0 len=1000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fffc len=0004 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-RELEASE #0: Thu Jun 5 03:08:07 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOOTMFS Preloaded elf kernel /kernel at 0xc07ec000. Preloaded mfs_root /mfsroot at 0xc07ec1dc. Calibrating clock(s) ... i8254 clock: 1193079 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 133636927 Hz Timecounter TSC frequency 133636927 Hz CPU: Pentium II/Pentium II Xeon/Celeron (133.64-MHz 686-class CPU) Origin = GenuineIntel Id = 0x633 Stepping = 3 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,M CA,CMOV,MMX real memory = 268435456 (256 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00813000 - 0x0fb59fff, 255094784 bytes (62279 pages) avail memory = 252334080 (240 MB) bios32: Found BIOS32 Service Directory header at 0xc00fdb40 bios32: Entry = 0xfdb50 (c00fdb50) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdb71 pnpbios: Found PnP BIOS data at 0xc00f72c0 pnpbios: Entry = f:6964 Rev = 1.0 Other BIOS signatures found: null: null device, zero device mem: memory I/O Pentium Pro MTRR support enabled md0: Preloaded image /mfsroot 4423680 bytes at 0xc03b2cdc npx0: math processor on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71a08086) pcibios: BIOS version 2.10 pcib0: Intel 82443GX host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f800, size 26, enabled found- vendor=0x8086, dev=0x71a0, revid=0x00 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2210, cachelnsz=0 (dwords)
Bogus temporary gethostbyaddr_r() in libc for 6 years
There's a bogus implementation of gethostbyaddr_r() in
lib/libc/net/gethostnamadr.c that was committed 6 years and nine
months ago:
/*
* Temporary function (not thread safe)
*/
int gethostbyaddr_r(const char *addr, int len, int type,
struct hostent *result, struct hostent_data *buffer)
{
struct hostent *hp;
int ret;
if ((hp = gethostbyaddr(addr, len, type)) == NULL) {
ret = -1;
} else {
memcpy(result, hp, sizeof(struct hostent));
ret = 0;
}
return(ret);
}
What's the deal here? Despite the fact that this is not prototyped in
a header, some ports are detecting this, and -- one assumes -- not
behaving correctly since this implementation isn't thread-safe.
Kris
pgp0.pgp
Description: PGP signature
Multiple cardbus devices? (RFI)
In continuing my quest to make FreeBSD current run flawlessly on my laptop, I'm trying to track down some issues with using multiple cardbus cards (more info on my particular problem and a workaround at the end of this message). I'd like to gather some information from people who have cardbus controllers with multiple slots and two or more cards to test. I'd appreciate it if some people could take a few minutes and privately send me the following information: 1. Attach message for the cardbus controller (including model and resources) 2. Attach messages for the first card 3. Attach messages for the second card 4. Whether or not both cards work correctly 5. Any odd messages on unplugging the cards It would be nice to see if this differs depending on the order in which the cards are inserted. Bootverbose is good for an extra bonus, but even plain dmesg output is useful. - The problem I've been seeing occurs on this controller: cbb0: TI1450 PCI-CardBus Bridge mem 0x4200-0x42000fff irq 11 at device 4.0 on pci0 cbb1: TI1450 PCI-CardBus Bridge mem 0x4208-0x42080fff irq 11 at device 4.1 on pci0 I have reason to suspect that it may be an alignment issue. Devices which allocate 4096 bytes, such as the two ohci components on a USB card, seem to work regardless. Devices which only allocate 256 bytes (ehci, xl) seem to interfere with each other. I've tried an awful hack of forcing a minimum size of 0x1000 for all resource allocations made by cardbus devices to make sure they're page-aligned and it seems to be working. There are occasional watchdog timeouts on the xl device, but it is at least functioning at the same time as the USB. Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sendmail authentication
When I get to the point of make sendmail I get the following error At the end of the make process I get CC: /usr/src/lib/libsmutil/libsmutil.a: No such file or directory CC: /usr/src/lib/libsm.a: No such file or directory *** Error code 1 If you haven't done a make world, do: cd /usr/src/lib/libsmutil make depend make obj make cd /usr/src/lib/libsm make depend make obj make Then you can build sendmail. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible EHCI bugs
Bernd Walter wrote: Note: we are strictly USB1.x at this time. There was a recent PCI attach patch that I thought fixed this? I know it hasn't been integrated yet (for God knows why), but it seemed to fix the problems. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bogus temporary gethostbyaddr_r() in libc for 6 years
Kris Kennaway wrote: There's a bogus implementation of gethostbyaddr_r() in lib/libc/net/gethostnamadr.c that was committed 6 years and nine months ago: [...] What's the deal here? Despite the fact that this is not prototyped in a header, some ports are detecting this, and -- one assumes -- not behaving correctly since this implementation isn't thread-safe. It should be removed. It's really hard to write a multithreaded version of this function, since it's essentially a request/response protocol. The most correct implementation would use a seperate worker thread and queue requests to it. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FTP client dumping core
On 05-Jun-2003 Fred Souza wrote: | Try this patch: | | Yes, it works now, thanks. Will this patch be commited to src, or | should I keep it and apply locally? | | Please try the latest lukemftp import which includes Maxim's patch. Mike -- Mike Heffner [EMAIL PROTECTED] [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
I've been running qmail for years and like it, installed pretty much per www.LifeWithQmail.org. My main system was running FreeBSD 5.0-RELEASE and -CURRENT and qmail was fine. When I just upgraded to 5.1-CURRENT a couple days back, the qmail-send process started using all CPU. [snip] Anyone else seen this or know what in FreeBSD-5.1 might have changed to cause this? Any thoughts on how I might go about diagnosing this any better? I saw this too, but couldn't get it fixed either. My solution (hopefully temporary) was to switch to another MTA. Fred -- I used to think romantic love was a neurosis shared by two, a supreme foolishness. I no longer thought that. There's nothing foolish in loving anyone. Thinking you'll be loved in return is what's foolish. -- Rita Mae Brown pgp0.pgp Description: PGP signature
Re: Possible EHCI bugs
Terry Lambert wrote this message on Sun, Jun 15, 2003 at 19:40 -0700: Bernd Walter wrote: Note: we are strictly USB1.x at this time. There was a recent PCI attach patch that I thought fixed this? Are you talking about the patch to check for multifunction devices? I know it hasn't been integrated yet (for God knows why), but it seemed to fix the problems. If this is the patch you are talking about, I asked for x86 testing, but I haven't heard any responses that it fixes (or even runs) on x86 systems. But also, I need to improve the sparc arch bit some too. Jake has some suggestions to make it a bit cleaner. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible EHCI bugs
On Sun, Jun 15, 2003 at 07:40:21PM -0700, Terry Lambert wrote: Bernd Walter wrote: Note: we are strictly USB1.x at this time. There was a recent PCI attach patch that I thought fixed this? I know it hasn't been integrated yet (for God knows why), but it seemed to fix the problems. The only one I remember was a pci_enable_busmaster thing, which was required for cardbus and is already commited. The symptoms were differently. -- 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]
Re: rc.firewall not executed?
On Sun, 15 Jun 2003, Kris Kennaway wrote: On Sun, Jun 15, 2003 at 09:36:23AM -0400, Andre Guibert de Bruet wrote: On Sat, 14 Jun 2003, Kris Kennaway wrote: I just noticed that my ipfw rules were not loaded the last time I rebooted. My rc.conf is included below - has something changed recently so that these settings are not enough? I didn't see anything relevant in UPDATING. My /etc/firewall.conf exists and is readable (and unchanged since 2002). Kris # $FreeBSD: src/etc/defaults/rc.conf,v 1.156 2002/08/30 13:01:42 hm Exp $ hostname=citusc17.usc.edu # Set this! nisdomainname=cituscdomain# Set to NIS domain if using NIS (or NO). firewall_enable=YES # Set to YES to enable firewall functionality firewall_type=/etc/firewall.conf # Firewall type (see /etc/rc.firewall) ^^ This is wrong. Set it to UNKNOWN. There's firewall_script for that. Nope..read rc.firewall(5) :-) Well, I'm assuming that you're refering to the rc.firewall that's in section 8 of the manual; And yes, I stand corrected. But I still think that firewall_script is more intuitive... ;) Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Thanks for repairing PPPoE
Hi, with tonights cvsup of 5.1-CURRENT my ppp is up and running again. Thanks to who- or whatever did it. Regards, Uli. +---+ |Peter Ulrich Kruppa| | - Wuppertal - | | Germany | +---+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible EHCI bugs
John-Mark Gurney wrote: Terry Lambert wrote this message on Sun, Jun 15, 2003 at 19:40 -0700: Bernd Walter wrote: Note: we are strictly USB1.x at this time. There was a recent PCI attach patch that I thought fixed this? Are you talking about the patch to check for multifunction devices? Yes. It got at least one USB 2.x device working. I know it hasn't been integrated yet (for God knows why), but it seemed to fix the problems. If this is the patch you are talking about, I asked for x86 testing, but I haven't heard any responses that it fixes (or even runs) on x86 systems. Sorry, I really don't have any USB equipment. But also, I need to improve the sparc arch bit some too. Jake has some suggestions to make it a bit cleaner. Anything that works is better than anything that doesn't. 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on alpha/alpha
TB --- 2003-06-16 04:00:15 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-06-16 04:00:15 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-16 04:02:35 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-16 05:00:31 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Mon Jun 16 05:00:31 GMT 2003 Kernel build for GENERIC completed on Mon Jun 16 05:11:52 GMT 2003 TB --- 2003-06-16 05:11:52 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-06-16 05:11:52 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Jun 16 05:11:53 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-06-16 05:15:08 - /usr/bin/make returned exit code 1 TB --- 2003-06-16 05:15:08 - ERROR: failed to build lint kernel TB --- 2003-06-16 05:15:08 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible EHCI bugs
Terry Lambert wrote this message on Sun, Jun 15, 2003 at 22:10 -0700: John-Mark Gurney wrote: Terry Lambert wrote this message on Sun, Jun 15, 2003 at 19:40 -0700: There was a recent PCI attach patch that I thought fixed this? Are you talking about the patch to check for multifunction devices? Yes. It got at least one USB 2.x device working. I know it hasn't been integrated yet (for God knows why), but it seemed to fix the problems. If this is the patch you are talking about, I asked for x86 testing, but I haven't heard any responses that it fixes (or even runs) on x86 systems. Sorry, I really don't have any USB equipment. Tis ok. Hopefully someone else will speak up. But also, I need to improve the sparc arch bit some too. Jake has some suggestions to make it a bit cleaner. Anything that works is better than anything that doesn't. 8-). :) True, but I don't want to catch a trap that shouldnh't be caught. I'm working on it right now, so it should be added in the next day or two. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
