Auto-reply: Re: Re: Details
This is an automated response. Please read this important message. Please use one of the following to contact a Customer Support Representative: For domain names purchased directly through Register.com, please visit us at: Register.com Customer Support http://register.com/create_ticket.cgi For domain names purchased through one of our Global Network Partners, please visit us at: Register.coms Global Partner Network Support Web Site http://gpn-enduser.register.com Sincerely, Customer Support ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: bundirty: buffer 0xc776e118 still on queue 2
--qYrsQHciA3Wqs7Iv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 21, 2003 at 01:40:54PM +1000, Tim Robbins wrote: > On Thu, Aug 21, 2003 at 12:26:07AM +0200, Christian Brueffer wrote: >=20 > > Hi, > >=20 > > just got a panic on following 5.1-CURRENT machine: > >=20 > > FreeBSD gondor.middleearth 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Thu Aug > > 7 21:32:39 CEST 2003 [EMAIL PROTECTED] konia.hitnet.rwth-aachen.de:/usr/obj= /usr/src/sys/GONDOR i386 > >=20 > > A dump is available if anyone needs specific information. > [...] > > panic: bundirty: buffer 0xc776e118 still on queue 2^M > [...] > > #2 0xc0254007 in panic (fmt=3D0xc03cc0ef "bundirty: buffer %p still on= queue %d")^M > > at /usr/src/sys/kern/kern_shutdown.c:550^M > > #3 0xc029b291 in bundirty (bp=3D0xc776e118) at /usr/src/sys/kern/vfs_b= io.c:1121^M > > #4 0xc029bde1 in brelse (bp=3D0xc776e118) at /usr/src/sys/kern/vfs_bio= .c:1436^M > > #5 0xc02efcb8 in nfs_writebp (bp=3D0xc776e118, force=3D1, td=3D0xc2c17= e40)^M > > at /usr/src/sys/nfsclient/nfs_vnops.c:2987^M > > #6 0xc02e02c3 in nfs_bwrite (bp=3D0x0) at /usr/src/sys/nfsclient/nfs_b= io.c:76^M > > #7 0xc029dd41 in getblk (vp=3D0xc2c77b68, blkno=3D400, size=3D15360, s= lpflag=3D256, slptimeo=3D0, flags=3D0)^M > > at /usr/src/sys/kern/vfs_bio.c:2512^M > > #8 0xc02e21e5 in nfs_getcacheblk (vp=3D0xc2c77b68, bn=3D400, size=3D15= 360, td=3D0xc2c17e40)^M > > at /usr/src/sys/nfsclient/nfs_bio.c:1037^M >=20 > I think I recognise this backtrace. Did you have a read-only NFS mount > active at the time of the crash? In any case, a copy of your NFS entries = from > /etc/fstab (with any private data removed) would be helpful in tracking t= his > problem down. >=20 No, all mounts were read-write. # DeviceMountpoint FStype Options DumpPas= s# /dev/da0s1b noneswapsw 0 0 /dev/da0s1a / ufs rw 1 1 /dev/da0s1f /usrufs rw 2 2 /dev/da0s1e /varufs rw 2 2 /dev/cd0c /cdrom cd9660 ro,noauto 0 0 linproc /compat/linux/proc linprocfs rw 0 0 x.x.x.x:/usr/ports /usr/ports nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/src/usr/srcnfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/obj/usr/objnfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/doc/usr/docnfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/www/usr/wwwnfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/home/chris /usr/home/chris nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/mnt/daten/ISOs /mnt/ISOs nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/mnt/daten/foo /mnt/foo nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/mnt/bigspace/bar /mnt/bar nfs rw,soft,bg,intr,nfsv3,rdirplus,-r=3D= 32768,-w=3D32768 0 0 x.x.x.x:/mnt/daten /mnt/daten nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/mnt/private /mnt/private nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/openbsd /usr/openbsd nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/netbsd /usr/netbsd nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/stable/src /usr/stable-src nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 - Christian --=20 Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --qYrsQHciA3Wqs7Iv Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/RGNVbHYXjKDtmC0RAoYrAJwN82v27AzaXasul5yfiEFz4BVpQwCg/eYY n0EF+Wdkm/zwgb8/ahtbq40= =ERIm -END PGP SIGNATURE- --qYrsQHciA3Wqs7Iv--
[current tinderbox] failure on sparc64/sparc64
___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on ia64/ia64
___ [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
___ [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
___ [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 --- mkdir /home/des/tinderbox/CURRENT/alpha TB --- mkdir /home/des/tinderbox/CURRENT/alpha/alpha ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on amd64/amd64
___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: bundirty: buffer 0xc776e118 still on queue 2
On Thu, Aug 21, 2003 at 12:26:07AM +0200, Christian Brueffer wrote: > Hi, > > just got a panic on following 5.1-CURRENT machine: > > FreeBSD gondor.middleearth 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Thu Aug > 7 21:32:39 CEST 2003 [EMAIL PROTECTED] > konia.hitnet.rwth-aachen.de:/usr/obj/usr/src/sys/GONDOR i386 > > A dump is available if anyone needs specific information. [...] > panic: bundirty: buffer 0xc776e118 still on queue 2^M [...] > #2 0xc0254007 in panic (fmt=0xc03cc0ef "bundirty: buffer %p still on queue %d")^M > at /usr/src/sys/kern/kern_shutdown.c:550^M > #3 0xc029b291 in bundirty (bp=0xc776e118) at /usr/src/sys/kern/vfs_bio.c:1121^M > #4 0xc029bde1 in brelse (bp=0xc776e118) at /usr/src/sys/kern/vfs_bio.c:1436^M > #5 0xc02efcb8 in nfs_writebp (bp=0xc776e118, force=1, td=0xc2c17e40)^M > at /usr/src/sys/nfsclient/nfs_vnops.c:2987^M > #6 0xc02e02c3 in nfs_bwrite (bp=0x0) at /usr/src/sys/nfsclient/nfs_bio.c:76^M > #7 0xc029dd41 in getblk (vp=0xc2c77b68, blkno=400, size=15360, slpflag=256, > slptimeo=0, flags=0)^M >at /usr/src/sys/kern/vfs_bio.c:2512^M > #8 0xc02e21e5 in nfs_getcacheblk (vp=0xc2c77b68, bn=400, size=15360, > td=0xc2c17e40)^M >at /usr/src/sys/nfsclient/nfs_bio.c:1037^M I think I recognise this backtrace. Did you have a read-only NFS mount active at the time of the crash? In any case, a copy of your NFS entries from /etc/fstab (with any private data removed) would be helpful in tracking this problem down. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall spec_getpages panic (with VM overtones)
At Wed, 20 Aug 2003 17:31:39 -0400 (EDT),
Robert Watson wrote:
> > *c0529513 = "/usr/src/sys/fs/specfs/spec_vnops.c", line 0x300 is line 768:
> >
> > 766 gotreqpage = 0;
> > 767 VM_OBJECT_LOCK(vp->v_object);
> > 768 vm_page_lock_queues();
> > 769 for (i = 0, toff = 0; i < pcount; i++, toff = nextoff) {
> >
> > so ap->a_vp is null. I'#m afraid that's the limit of my ddb ability.
> >
> > Any suggestions as to where I should go from here? I don't really have
> > the facility at the moment to make release to test patches but will try
> > to if necessary.
>
> Is it ap->a_vp that's NULL, or vp->v_object that's NULL? vp is
> dereferenced several times before that in the code, so if vp is really
> NULL at line 767, we're probably talking about memory corruption. But if
> vp->v_object is NULL, then it could be we're not creating a VM object
> along some code path.
FWIW, ffs_getpages() at ffs_vnops.c:938, dp->v_object is NULL. Where
this should be allocated?
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall spec_getpages panic (with VM overtones)
At Wed, 20 Aug 2003 17:31:39 -0400 (EDT),
Robert Watson wrote:
> > *c0529513 = "/usr/src/sys/fs/specfs/spec_vnops.c", line 0x300 is line 768:
> >
> > 766 gotreqpage = 0;
> > 767 VM_OBJECT_LOCK(vp->v_object);
> > 768 vm_page_lock_queues();
> > 769 for (i = 0, toff = 0; i < pcount; i++, toff = nextoff) {
> >
> > so ap->a_vp is null. I'#m afraid that's the limit of my ddb ability.
> >
> > Any suggestions as to where I should go from here? I don't really have
> > the facility at the moment to make release to test patches but will try
> > to if necessary.
>
> Is it ap->a_vp that's NULL, or vp->v_object that's NULL? vp is
> dereferenced several times before that in the code, so if vp is really
> NULL at line 767, we're probably talking about memory corruption. But if
> vp->v_object is NULL, then it could be we're not creating a VM object
> along some code path.
At least I checked with printf() debugging, it seems vp->v_object is
NULL.
Should I check in ffs_getpages(), too?
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WiFi hardware support - ADM8211 chipset
In message: <[EMAIL PROTECTED]> Andrew Naylor <[EMAIL PROTECTED]> writes: : Can support for the ADM8211 be included in the next releases of freeBSD Maybe. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
WiFi hardware support - ADM8211 chipset
Having recently purchased a Belkin card, I foound that it now uses the ADM8211 chipset and is not supported in any current or stable release of freeBSD. I have found that NetBSD now has a port of the driver for the ADM8211 chip. Can support for the ADM8211 be included in the next releases of freeBSD (Please!) I am back to windoze to use the WiFi card, and it sux! Andrew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 card: CardBus card activiation failed
Looks like 1.91,1.92 broke things, and 1.93 fixes it. Please let me know if I'm smoking the happy weed or not :-) Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 card: CardBus card activiation failed
In message: <[EMAIL PROTECTED]> Lukas Ertl <[EMAIL PROTECTED]> writes: : On Wed, 20 Aug 2003, M. Warner Losh wrote: : : > OK. I think I can't do much more until I get home and try it again on : > my machine. Unless you can back out last night's changes to pccbb.c : > and try again. From the debug you sent me, that's the only thing in : > the loop. : : Reverting to rev. 1.90 of pccbb.c fixes the problem and the card works : again. That's good to know. I'll look into it in more detail. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Current panic in pmap/VM
John Baldwin writes: > > pmap_ts_referenced() > > vm_pageout_scan() > > vm_pageout() > > fork_exit() > > fork_trampoline() > > > > I'm happy to try patches if anyone has ideas. > > Having the fault address as well as the source file/line of > where the fault occurs could be helpful. >From 2 panics, I have 2 addresses - 0xc02cbbab and 0xc02cfb9b (Custom kernels, so I doubt those will help). The source file is src/sys/i386/i386/pmap.c, and it is in the pmap_ts_referenced() function (a short function) at about line 2895. I'm suspecting that a lock is needed. I'll need to put a serial debugger on to go any further. Does this work, or will I be wasting effort? (Getting that cable in is going to be a _pain_). 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]"
panic: bundirty: buffer 0xc776e118 still on queue 2
--h31gzZEtNLTqOjlF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi,
just got a panic on following 5.1-CURRENT machine:
FreeBSD gondor.middleearth 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Thu Aug
7 21:32:39 CEST 2003 [EMAIL PROTECTED] konia.hitnet.rwth-aachen.de:/usr/obj/usr=
/src/sys/GONDOR i386
A dump is available if anyone needs specific information.
GNU gdb 5.3 (FreeBSD)^M
Copyright 2002 Free Software Foundation, Inc.^M
GDB is free software, covered by the GNU General Public License, and you ar=
e^M
welcome to change it and/or distribute copies of it under certain condition=
s.^M
Type "show copying" to see the conditions.^M
There is absolutely no warranty for GDB. Type "show warranty" for details.=
^M
This GDB was configured as "i386-portbld-freebsd5.0"...^M
panic: bundirty: buffer 0xc776e118 still on queue 2^M
panic messages:^M
---^M
panic: bundirty: buffer 0xc776e118 still on queue 2^M
^M
syncing disks, buffers remaining... 2225 2225 2225 2225 2225 2225 2225 2225=
2225 2225 2225 2225 2225 2225 2225 2225 2225 2225 2225 2225 ^M
giving up on 80 buffers^M
Uptime: 8d3h14m30s^M
Dumping 255 MB^M
16 32 48 64[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 80[CTRL-=
C to abort] [CTRL-C to abort] [CTRL-C to abort] 96 112 128 144 160 176 192=
208 224 240^M
---^M
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240^M
240 dumping++;^M
(kgdb) bt^M
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240^M
#1 0xc0253c71 in boot (howto=3D256) at /usr/src/sys/kern/kern_shutdown.c:3=
72^M
#2 0xc0254007 in panic (fmt=3D0xc03cc0ef "bundirty: buffer %p still on que=
ue %d")^M
at /usr/src/sys/kern/kern_shutdown.c:550^M
#3 0xc029b291 in bundirty (bp=3D0xc776e118) at /usr/src/sys/kern/vfs_bio.c=
:1121^M
#4 0xc029bde1 in brelse (bp=3D0xc776e118) at /usr/src/sys/kern/vfs_bio.c:1=
436^M
#5 0xc02efcb8 in nfs_writebp (bp=3D0xc776e118, force=3D1, td=3D0xc2c17e40)=
^M
at /usr/src/sys/nfsclient/nfs_vnops.c:2987^M
#6 0xc02e02c3 in nfs_bwrite (bp=3D0x0) at /usr/src/sys/nfsclient/nfs_bio.c=
:76^M
#7 0xc029dd41 in getblk (vp=3D0xc2c77b68, blkno=3D400, size=3D15360, slpfl=
ag=3D256, slptimeo=3D0, flags=3D0)^M
at /usr/src/sys/kern/vfs_bio.c:2512^M
#8 0xc02e21e5 in nfs_getcacheblk (vp=3D0xc2c77b68, bn=3D400, size=3D15360,=
td=3D0xc2c17e40)^M
at /usr/src/sys/nfsclient/nfs_bio.c:1037^M
#9 0xc02e1df0 in nfs_write (ap=3D0x0) at /usr/src/sys/nfsclient/nfs_bio.c:=
854^M
#10 0xc02b8a92 in vn_write (fp=3D0xc27a3880, uio=3D0xd5112c7c, active_cred=
=3D0xc2a5c980, flags=3D0, td=3D0xc2c17e40)^M
at vnode_if.h:432^M
#11 0xc027b5a8 in dofilewrite (td=3D0xc2c17e40, fp=3D0xc27a3880, fd=3D0, bu=
f=3D0x975b000, nbyte=3D0, offset=3D0, ^M
flags=3D0) at /usr/src/sys/sys/file.h:249^M
#12 0xc027b3de in write (td=3D0xc2c17e40, uap=3D0xd5112d10) at /usr/src/sys=
/kern/sys_generic.c:330^M
#13 0xc0383f13 in syscall (frame=3D^M
{tf_fs =3D 47, tf_es =3D 47, tf_ds =3D 47, tf_edi =3D 0, tf_esi
=3D=
677275520, tf_ebp =3D -1077939912, tf_isp =3D -720294540, tf_ebx =3D 67728=
7604, tf_edx =3D 22, tf_ecx =3D 677287604, tf_eax =3D 4, tf_trapno =3D 0, t=
f_err =3D 2, tf_eip =3D 677631647, tf_cs =3D 31, tf_eflags =3D 518, tf_esp =
=3D -1077939972, tf_ss =3D 47})^M
at /usr/src/sys/i386/i386/trap.c:1008
- Christian =20
=20
--=20
Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
--h31gzZEtNLTqOjlF
Content-Type: application/pgp-signature
Content-Disposition: inline
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (FreeBSD)
iD8DBQE/Q/V/bHYXjKDtmC0RAuOfAKDdT0njACl5W2KRU73CY9lsN5aR6QCdHJ4p
5bckzKE/DAWesK1808FfeX0=
=q5XC
-END PGP SIGNATURE-
--h31gzZEtNLTqOjlF--
Re: ath0 card: CardBus card activiation failed
On Wed, 20 Aug 2003, M. Warner Losh wrote: > OK. I think I can't do much more until I get home and try it again on > my machine. Unless you can back out last night's changes to pccbb.c > and try again. From the debug you sent me, that's the only thing in > the loop. Reverting to rev. 1.90 of pccbb.c fixes the problem and the card works again. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Cannot mount cdrom: "device busy" error on 5.1-RELEASE-p2
I'm hoping this will be a simple question to answer, so here goes. Whenever I try to mount a cdrom I get the following: borges[141]% sudo mount -t cd9660 /dev/acd0 /cdrom cd9660: /dev/acd0: Device busy I tried a umount -f just to see if some process was hanging on to it for some reason (even though it was freshly booted just yesterday and I haven't used the cdrom at all since then) and I get: borges[142]% sudo umount -f /dev/acd0 umount: unmount of /dev/acd0 failed: Invalid argument I had a similar problem before with 5.0-RELEASE and someone suggested I set my cdrom drive as a "slave" (I had it set as secondary master) which worked fine for some strange reason. Come to think of it, I haven't used the cdrom drive at all since I did a clean install of 5.1-RELEASE last month so, AFAIK, my drive hasn't worked at all with 5.1 but was coerced into working on 5.0. borges[143]% dmesg | grep acd0 acd0: CD-RW at ata1-slave WDMA2 I thought I would ask here as I rarely have luck with questions pertaining to 5.x on freebsd-questions. Any ideas? TIA, Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Getting from 5.1-RELEASE to RELENG_5_1
I am looking at moving various hosts from 4.x to 5.1 but have run into a problem with my test machine. I've successfully installed 5.1-RELEASE (from CD) but want to rebuild the system to customise it to its environment. The machine in question does not have enough local disk space to hold both /usr/src and /usr/obj. When I tried to NFS mount the space, the 'make buildworld' would consistently wedge the machine in "stage 1: bootstrap tools" building games/fortune/strfile. I tried using local disk for /usr/obj and NFS mounting just /usr/src. This got somewhat further but again wedged the machine. "Wedged" means no response via network or local keyboard, needing reset to recover. Has anyone else seen NFS problems with 5.1-RELEASE? The client is a P-133 with 96MB RAM. The server is a PIII running roughly 4.6. They are both using 100baseTX full-duplex 802.1Q trunks to a common switch. My alternative (preferred) option is to do a build world/kernel on another faster machine (the NFS server used above). This fails with multiple definitions of _sigaction and _sigprocmask building libpthread. Looking back thru the archives, I gather this has been fixed in -CURRENT but it's not in RELENG_5_1 because it's not security-related. Any suggestions for a way forward? Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall spec_getpages panic (with VM overtones)
On Wed, 20 Aug 2003, Gavin Atkinson wrote:
> On the 8th August [EMAIL PROTECTED] mentioned he was getting a panic
> with FreeBSD inside VMware where _mtx_lock is being called with a NULL
> mutex from spec_getpages. I'm also seeing this, 100% reproducible, on
> real hardware. (see message ID [EMAIL PROTECTED] for
> the original posters email and jhb's reply) For me, Sysinstall panics
> during the extraction of the base package:
>
> (note that I do not get to see a register dump) kernel: type 12 trap,
> code=0
>
> _mtx_lock_flags(0,0,c0529513,300,) at _mtx_lock_flags+0x43
> spec_getpages(cce33b3c,54,0,cce33b2c,0) at spec_getpages+0x26c
> ffs_getpages(cce33b80,0,c05459de,274,c05c63e0) at ffs_getpages+0x5f6
> vnode_pager_getpages(c0bebafc,cce33c70,1,0,cce33c20) at
> vnode_pager_getpages+0x73 vm_fault(c1259900,819b000,1,0,c12534c0) at
> vm_fault+0x8e2 trap_pfault(cce33d48,1,819b004,200,819b004) at
> trap_pfault+0x109 trap(2f,2f,2f,82e533c,0) at trap+0x1fc calltrap() at
> calltrap+0x5
I've been getting similar reports locally from our trustedbsd_sebsd
branch. We thought originally it was a local merge problem we introduced
due to some inconsistent merging of specfs changes, but I think we have
now have eliminated that. I suppose I'm relieved... (?)
> I first noticed this with the 20030811 JPSNAP, but have tried with the
> 9th July 2003 JPSNAP, and yesterdays snapshot, and see the same result
> on both. I see the same panic whether installing over the net or from
> CD. With 64 meg of ram, it panics half way through the read the chunks
> that make up the base package, upping the ram to 256 allows it to read
> all of the chunks before panicing.
Sounds identical.
> *c0529513 = "/usr/src/sys/fs/specfs/spec_vnops.c", line 0x300 is line 768:
>
> 766 gotreqpage = 0;
> 767 VM_OBJECT_LOCK(vp->v_object);
> 768 vm_page_lock_queues();
> 769 for (i = 0, toff = 0; i < pcount; i++, toff = nextoff) {
>
> so ap->a_vp is null. I'#m afraid that's the limit of my ddb ability.
>
> Any suggestions as to where I should go from here? I don't really have
> the facility at the moment to make release to test patches but will try
> to if necessary.
Is it ap->a_vp that's NULL, or vp->v_object that's NULL? vp is
dereferenced several times before that in the code, so if vp is really
NULL at line 767, we're probably talking about memory corruption. But if
vp->v_object is NULL, then it could be we're not creating a VM object
along some code path.
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]"
Re: 5.1-R: zero byte core file.
On Wed, 20 Aug 2003, Yogeshwar Shenoy wrote: > While using 5.1-RELEASE, I find that if my application program seg > faults, it produces "programname.core"; but it is 0 bytes. I ran the > exact same program on another machine that was running 4.4-RELEASE, and > I do get a core file that I can use with gdb. I'd really appreciate if > someone could help me resolve this. > > Additional details: - It is not specific to the application program. I > tried a 2 line program: > char p[8]; > memcpy(p, "1234567890123456789012345678901234567890", 40); > with same results on 5.1-R(0 byte core file) and 4.4-R(usable core > file) > > - "ulimit -a" on the 5.1-R machine gives >core file size (blocks, -c) unlimited > > - Just to be sure I used getrlimit() to find what the limit for > RLIMIT_CORE is in my processes, and it is RLIM_INFINITY. > > - I did the basic checks like write permission on current directory, it > looks fine. > > Can someone help me resolve this? With 5.1-CURRENT from July, I get: paprika:~/tmp/core> ./tmp Segmentation fault (core dumped) paprika:~/tmp/core> ls -l total 348 drwxr-xr-x 2 rwatson rwatson 512 Aug 20 17:23 ./ drwxr-xr-x 9 rwatson rwatson 512 Aug 20 17:23 ../ -rwxr-xr-x 1 rwatson rwatson4677 Aug 20 17:23 tmp* -rw-r--r-- 1 rwatson rwatson 131 Aug 20 17:23 tmp.c -rw--- 1 rwatson rwatson 323584 Aug 20 17:23 tmp.core The corefile isn't very useful, since the stack is completely hosed by the operations, but I do get a core that I can point gdb at. Some elements of core file generation are platform-specific: what architecture are you running on? And, just to confirm, "df ." indicates you have space, right? 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]"
Re: [current tinderbox] failure on alpha/alpha
Andrew Gallatin <[EMAIL PROTECTED]> writes: > > cc1: error: invalid option `tune=ev5' > > cc1: error: invalid option `ieee' > > cc1: error: bad value (ev4) for -mcpu= switch > I assume that this is a crossbuild problem? No, the filesystem it was running on got yanked away in the middle of the run. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.1-R: zero byte core file.
While using 5.1-RELEASE, I find that if my application program seg faults, it produces "programname.core"; but it is 0 bytes. I ran the exact same program on another machine that was running 4.4-RELEASE, and I do get a core file that I can use with gdb. I'd really appreciate if someone could help me resolve this. Additional details: - It is not specific to the application program. I tried a 2 line program: char p[8]; memcpy(p, "1234567890123456789012345678901234567890", 40); with same results on 5.1-R(0 byte core file) and 4.4-R(usable core file) - "ulimit -a" on the 5.1-R machine gives core file size(blocks, -c) unlimited - Just to be sure I used getrlimit() to find what the limit for RLIMIT_CORE is in my processes, and it is RLIM_INFINITY. - I did the basic checks like write permission on current directory, it looks fine. Can someone help me resolve this? Thanks, Yogeshwar. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sound card woes
Hello, On Wed, Aug 20, 2003 at 03:20:55PM -0400, Matt Gostick wrote: > I have a SND Blaster 16 in my computer. I was using FreeBSD 4.8 and > 'device pcm' in my kernel config file, worked great. I've completely > re-installed with 5.1R and recompiled my kernel with 'device pcm'. > Unfortunately sound doesn't work. You also could add 'device sbc' to your kernel config since that is the SB bridge driver. But the card should work with PCM only. What does 'cat /dev/sndstat' say? The issue is probably some resource conflict. Since you have an SB 16, I'll have to ask: is it ISA? Or ISAPnP? Or PCI? PCI should "just work" but if it is ISA, you will need some tweaking. > I no longer have a /dev/snd0 device - I think I had one before... how > do I make devices in 5.1R??? MAKEDEV is no longer available... and > section 9.5 of the FreeBSD manual says: "If you are running FreeBSD 5.0 > or later you can safely skip this section. These versions use devfs(5) > to allocate device nodes transparently for the user" You do not need this, devfs will create the device for you when needed. -- Regards: Szilveszter ADAM Budapest Hungary ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 card: CardBus card activiation failed
In message: <[EMAIL PROTECTED]> Lukas Ertl <[EMAIL PROTECTED]> writes: : On Wed, 20 Aug 2003, M. Warner Losh wrote: : : > In message: <[EMAIL PROTECTED]> : > Lukas Ertl <[EMAIL PROTECTED]> writes: : > : Built last night after cvsup (times are CEST): : > : : > : $ ls -l /boot/kernel.old/kernel : > : -r-xr-xr-x 1 root wheel 4164476 20 Aug 00:03 /boot/kernel.old/kernel : > : > I was afraid you'd say that. Are you building from a tree you check : > out of CVS, or a tree managed directly by cvsup? : : A tree managed directly by cvsup. OK. I think I can't do much more until I get home and try it again on my machine. Unless you can back out last night's changes to pccbb.c and try again. From the debug you sent me, that's the only thing in the loop. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 card: CardBus card activiation failed
On Wed, 20 Aug 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Lukas Ertl <[EMAIL PROTECTED]> writes: > : Built last night after cvsup (times are CEST): > : > : $ ls -l /boot/kernel.old/kernel > : -r-xr-xr-x 1 root wheel 4164476 20 Aug 00:03 /boot/kernel.old/kernel > > I was afraid you'd say that. Are you building from a tree you check > out of CVS, or a tree managed directly by cvsup? A tree managed directly by cvsup. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 card: CardBus card activiation failed
In message: <[EMAIL PROTECTED]> Lukas Ertl <[EMAIL PROTECTED]> writes: : Built last night after cvsup (times are CEST): : : $ ls -l /boot/kernel.old/kernel : -r-xr-xr-x 1 root wheel 4164476 20 Aug 00:03 /boot/kernel.old/kernel I was afraid you'd say that. Are you building from a tree you check out of CVS, or a tree managed directly by cvsup? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 card: CardBus card activiation failed
On Wed, 20 Aug 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Lukas Ertl <[EMAIL PROTECTED]> writes: > : On Wed, 20 Aug 2003, Martin Jessa wrote: > : > : > It works, unplug the card once or twice and try again. > : > Same shit happens to me pretty frequently. > : > : The card has worked _perfectly_ on first plug-in before I built the kernel > : this morning, so I'd say there's a regression somewhere. > > When was your previous kernel? Built last night after cvsup (times are CEST): $ ls -l /boot/kernel.old/kernel -r-xr-xr-x 1 root wheel 4164476 20 Aug 00:03 /boot/kernel.old/kernel regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Current panic in pmap/VM
On 20-Aug-2003 Mark Murray wrote: > Hi all > > I'm getting a repeatable panic on i386/SMP CURRENT with a big C++ > compile (one of the KDE3 things). It is a "page fault in kernel mode", > and the hand-transcribed backtrace is > > pmap_ts_referenced() > vm_pageout_scan() > vm_pageout() > fork_exit() > fork_trampoline() > > I'm happy to try patches if anyone has ideas. Having the fault address as well as the source file/line of where the fault occurs could be helpful. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 card: CardBus card activiation failed
In message: <[EMAIL PROTECTED]> Lukas Ertl <[EMAIL PROTECTED]> writes: : On Wed, 20 Aug 2003, Martin Jessa wrote: : : > It works, unplug the card once or twice and try again. : > Same shit happens to me pretty frequently. : : The card has worked _perfectly_ on first plug-in before I built the kernel : this morning, so I'd say there's a regression somewhere. When was your previous kernel? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Release seems to be broken or maybe I missed a change.
Subject: Release seems to be broken or maybe I missed a change., On Wed, 20 Aug 2003 10:34:43 -0700, [EMAIL PROTECTED] wrote: > With cvsup early this morning. Make release generated Which version of src/libexec/rtld-elf/Makefile are you using ? This problem was fixed a few days ago. > install -o root -g wheel -m 444 rtld.1.gz /usr/share/man/man1 > /usr/share/man/man1/ld-elf.so.1.1.gz -> /usr/share/man/man1/rtld.1.gz > /usr/share/man/man1/ld.so.1.gz -> /usr/share/man/man1/rtld.1.gz > /usr/libexec/ld-elf.so.1 -> /libexec/ld-elf.so.1 > ln: /usr/libexec/ld-elf.so.1: Operation not permitted > *** Error code 1 -- Shin-ichi YOSHIMOTO <[EMAIL PROTECTED]> http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Current panic in pmap/VM
Hi all I'm getting a repeatable panic on i386/SMP CURRENT with a big C++ compile (one of the KDE3 things). It is a "page fault in kernel mode", and the hand-transcribed backtrace is pmap_ts_referenced() vm_pageout_scan() vm_pageout() fork_exit() fork_trampoline() I'm happy to try patches if anyone has ideas. 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]"
Auto-reply: Re: Re: Details
This is an automated response. Please read this important message. Please use one of the following to contact a Customer Support Representative: For domain names purchased directly through Register.com, please visit us at: Register.com Customer Support http://register.com/create_ticket.cgi For domain names purchased through one of our Global Network Partners, please visit us at: Register.coms Global Partner Network Support Web Site http://gpn-enduser.register.com Sincerely, Customer Support ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sound card woes
I have a SND Blaster 16 in my computer. I was using FreeBSD 4.8 and 'device pcm' in my kernel config file, worked great. I've completely re-installed with 5.1R and recompiled my kernel with 'device pcm'. Unfortunately sound doesn't work. I no longer have a /dev/snd0 device - I think I had one before... how do I make devices in 5.1R??? MAKEDEV is no longer available... and section 9.5 of the FreeBSD manual says: "If you are running FreeBSD 5.0 or later you can safely skip this section. These versions use devfs(5) to allocate device nodes transparently for the user" I've written the -questions list and they told me to try wrinting here. What do I do? Thanks, Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 card: CardBus card activiation failed
On Wed, 20 Aug 2003, Martin Jessa wrote: > It works, unplug the card once or twice and try again. > Same shit happens to me pretty frequently. The card has worked _perfectly_ on first plug-in before I built the kernel this morning, so I'd say there's a regression somewhere. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath0 card: CardBus card activiation failed
It works, unplug the card once or twice and try again. Same shit happens to me pretty frequently. > Hi, > > with a kernel from this morning I can't get my ath0 Cardbus device up > again, when I plug it in, I get: > > cbb1: CardBus card activation failed > > The card has worked fine up until now. Maybe some of the recent commits > to pccbb.c/pccard.c broke something? > > regards, > le > > -- > Lukas Ertl eMail: [EMAIL PROTECTED] > UNIX Systemadministrator Tel.: (+43 1) 4277-14073 > Vienna University Computer Center Fax.: (+43 1) 4277-9140 > University of Vienna http://mailbox.univie.ac.at/~le/ > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [current tinderbox] failure on alpha/alpha
On Wed, Aug 20, 2003 at 01:59:42PM -0400, Andrew Gallatin wrote: > > Tinderbox writes: > > > cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -DIN_GCC -DHAVE_CONFIG_H > -DPREFIX=\"/usr\" > -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools > > -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools > > -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc > > -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/config > > -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/f > -I. -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/contrib/gcc/f/stc.c > > cc1: error: invalid option `tune=ev5' > > cc1: error: invalid option `ieee' > > cc1: error: bad value (ev4) for -mcpu= switch > > I assume that this is a crossbuild problem? FWIW on a true alpha buildworld ran fine last night. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [current tinderbox] failure on alpha/alpha
Tinderbox writes: > cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" > -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools > > -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools > > -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc > > -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/config > > -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/f > -I. -c > /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/contrib/gcc/f/stc.c > cc1: error: invalid option `tune=ev5' > cc1: error: invalid option `ieee' > cc1: error: bad value (ev4) for -mcpu= switch I assume that this is a crossbuild problem? Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Release seems to be broken or maybe I missed a change.
With cvsup early this morning. Make release generated install -o root -g wheel -m 444 rtld.1.gz /usr/share/man/man1 /usr/share/man/man1/ld-elf.so.1.1.gz -> /usr/share/man/man1/rtld.1.gz /usr/share/man/man1/ld.so.1.gz -> /usr/share/man/man1/rtld.1.gz /usr/libexec/ld-elf.so.1 -> /libexec/ld-elf.so.1 ln: /usr/libexec/ld-elf.so.1: Operation not permitted *** Error code 1 Stop in /usr/src/libexec/rtld-elf. *** Error code 1 Stop in /usr/src/libexec. *** Error code 1 Stop in /usr/src. *** Error code 1 I seem to remember something similar in make world a few days back, ed - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1, Data Corruption, Intel, Oh my! [patch]
On Wed, Aug 20, 2003 at 10:09:34AM -0700, Nate Lawson wrote: > I haven't had time to test your patch unfortunately but just wanted to let > you know of a corner case to be aware of. To suspend, ACPI maps in and > identity page table (phys == virt) and switches to real mode. I'm not > sure if your patches change the ability to access the first 1M or change > the way such a mapping would be done, but it would be useful if you > thought about this. The code is in /sys/i386/acpica/acpi_wakeup.c: > acpi_sleep_machdep(). A P==V mapping is also done during the startup of the APs on SMP. There should not be a problem. Also, this change loads the kernel at 0x40 (so at the next 4M) just to be sure to not map that first 4M region in a 4M page, in particular to prevent from exposing holes in the region via a 4M page at any time. It should be noted that the changes leave the page tables describing the kernel with 4K-page ptes lying around in order to accomodate the P==V switchover in mp_machdep.c, so the legacy 4K page tables are still around, should they be required in a different mapping (like the mp_machdep one). In any case, it would still be nice if the acpi users (for whom acpi works for the most part) could give the patch a try as well (I have a decent-sized list of testers but would nonetheless welcome/appreciate more). > Thanks, > -Nate Cheers, -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI on Tyan Motherboard
On 20-Aug-2003 David O'Brien wrote:
> On Tue, Aug 19, 2003 at 06:13:19PM -0400, John Baldwin wrote:
>> > Following up your suggestion that it is a hardware problem, I decided
>> > to try updating the BIOS from version 2.10 to 2.14. Now start up
>> > produces lots of ACPI error messages.
> ...
>> The 2.10 is the version of the PCI BIOS specification that your motherboard
>> BIOS supports. It is unrelated to the version of your motherboard BIOS.
>
> NO. His "2.10" above *IS* the version of his BIOS. I know exactly what
> version he had and has now. He is correct about the extra ACPI error
> verbage.
David, please read his dmesg:
pcibios: BIOS version 2.10
Do you know where that comes from?
/sys/i386/pci/pci_cfgreg.c:
int
pci_cfgregopen(void)
{
...
v = pcibios_get_version();
if (v > 0)
printf("pcibios: BIOS version %x.%02x\n", (v & 0xff00) >> 8,
v & 0xff);
...
}
I'm not stupid, ok? The version of the PCI BIOS spec that his BIOS
implements has no relation to the vendor firmware revision of his
BIOS beyond perhaps mere coincidence. FreeBSD has no code in it to
go figure out his firmware revision and print it to the bloody screen
claiming that it has something to do with PCI.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI on Tyan Motherboard
On 19-Aug-2003 David Xu wrote: > On Wednesday 20 August 2003 02:49, John Baldwin wrote: >> >> Here's how it works: The BIOS/hardware monitor the power button. When an >> OS tells the BIOS that it is ACPI, then the BIOS doesn't do an instant turn >> off when the power button is pressed, but waits to do so until the power >> button has been held down for 4 seconds. If the power button after 4 >> seconds doesn't work, it's still a hardware problem. FreeBSD can not fix >> your hardware problem. When you press the power button with an ACPI OS >> running, the hardware sends an interrupt to the OS. The OS then shuts down >> and asks the BIOS (via ACPI) to power off the machine. If the machine >> doesn't physically turn off, it's because your BIOS is screwed up and >> didn't handle the power down command properly. The fact that the 4 second >> trick (which as above bypasses FreeBSD completely and has the BIOS call >> that power down method itself) produces the same broken results means that >> this bug is in your hardware. >> >> FreeBSD sleeps for a bit when it does a halt -p as a workaround for broken >> IDE disks which claim that writes have hit the media when they are still in >> the disks cache, so that is a separate issue. >> >> If you want more info on ACPI and how it works, feel free to head on over >> to www.acpi.info and read the spec for yourself. > > Windows 2000 can shutdown my Tiger 230T in very short time, while FreeBSD > is always timeouted with halt -p. > I dont't think it is hardware or BIOS problem, FreeBSD must be wrong in > something, just like FreeBSD ATA bug for my Tiger 230T, all OS I have in > hand work fine, only FreeBSD does not. In this case, David, the machine still screws up even with the hardware 4 second override. FreeBSD has no possible control over the override, that is _only_ handled in hardware and the BIOS. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1, Data Corruption, Intel, Oh my! [patch]
I haven't had time to test your patch unfortunately but just wanted to let you know of a corner case to be aware of. To suspend, ACPI maps in and identity page table (phys == virt) and switches to real mode. I'm not sure if your patches change the ability to access the first 1M or change the way such a mapping would be done, but it would be useful if you thought about this. The code is in /sys/i386/acpica/acpi_wakeup.c: acpi_sleep_machdep(). Thanks, -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs mounts on FreeBSD 5.1
On Wed, 20 Aug 2003, [iso-8859-1] Claus Guttesen wrote: > Hi. > > I'm trying to nfs-mount a FreeBSD 5.1 client on a > Redhat 7.3 nfs-server. I have the line > nfs_client_enable="YES" in /etc/rc.conf and > nfsclient.ko is loaded. > > The error I get is > [udp] nfs-srv:/mount/a: RPCMNT: clnt_create: RPC: > Program not registered Looks like portmap/rpcbind is not running on the server, client, or both. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sysinstall spec_getpages panic
Hi,
On the 8th August [EMAIL PROTECTED] mentioned he was getting a panic
with FreeBSD inside VMware where _mtx_lock is being called with a NULL
mutex from spec_getpages. I'm also seeing this, 100% reproducible, on real
hardware. (see message ID [EMAIL PROTECTED] for the
original posters email and jhb's reply) For me, Sysinstall panics during
the extraction of the base package:
(note that I do not get to see a register dump)
kernel: type 12 trap, code=0
_mtx_lock_flags(0,0,c0529513,300,) at _mtx_lock_flags+0x43
spec_getpages(cce33b3c,54,0,cce33b2c,0) at spec_getpages+0x26c
ffs_getpages(cce33b80,0,c05459de,274,c05c63e0) at ffs_getpages+0x5f6
vnode_pager_getpages(c0bebafc,cce33c70,1,0,cce33c20) at vnode_pager_getpages+0x73
vm_fault(c1259900,819b000,1,0,c12534c0) at vm_fault+0x8e2
trap_pfault(cce33d48,1,819b004,200,819b004) at trap_pfault+0x109
trap(2f,2f,2f,82e533c,0) at trap+0x1fc
calltrap() at calltrap+0x5
I first noticed this with the 20030811 JPSNAP, but have tried with the 9th
July 2003 JPSNAP, and yesterdays snapshot, and see the same result on
both. I see the same panic whether installing over the net or from CD.
With 64 meg of ram, it panics half way through the read the chunks that
make up the base package, upping the ram to 256 allows it to read all of
the chunks before panicing.
*c0529513 = "/usr/src/sys/fs/specfs/spec_vnops.c", line 0x300 is line 768:
766 gotreqpage = 0;
767 VM_OBJECT_LOCK(vp->v_object);
768 vm_page_lock_queues();
769 for (i = 0, toff = 0; i < pcount; i++, toff = nextoff) {
so ap->a_vp is null. I'#m afraid that's the limit of my ddb ability.
Any suggestions as to where I should go from here? I don't really have the
facility at the moment to make release to test patches but will try to if
necessary.
Gavin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on ia64/ia64
TB --- mkdir /home/des/tinderbox/CURRENT/ia64 TB --- mkdir /home/des/tinderbox/CURRENT/ia64/ia64 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on amd64/amd64
TB --- mkdir /home/des/tinderbox/CURRENT TB --- mkdir /home/des/tinderbox/CURRENT/amd64 TB --- mkdir /home/des/tinderbox/CURRENT/amd64/amd64 ___ [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 --- mkdir /home/des/tinderbox/CURRENT/i386 TB --- mkdir /home/des/tinderbox/CURRENT/i386/i386 ___ [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 --- mkdir /home/des/tinderbox/CURRENT/sparc64 TB --- mkdir /home/des/tinderbox/CURRENT/sparc64/sparc64 ___ [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-08-20 16:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-08-20 16:00:01 - 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-08-20 16:01:51 - 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.. [...] cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/f -I. -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/contrib/gcc/f/src.c cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/f -I. -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/contrib/gcc/f/st.c cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/f -I. -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/contrib/gcc/f/sta.c cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/f -I. -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/contrib/gcc/f/stb.c cc -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../cc_tools -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/config -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc/f -I. -c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/contrib/gcc/f/stc.c cc1: error: invalid option `tune=ev5' cc1: error: invalid option `ieee' cc1: error: bad value (ev4) for -mcpu= switch *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc/f771. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin/cc. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu/usr.bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/gnu. *** Error code 1 S
[current tinderbox] failure on i386/pc98
TB --- mkdir /home/des/tinderbox/CURRENT/i386/pc98 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is rl broken?
[ On Tuesday, August 19, Doug White wrote: ] > On Tue, 19 Aug 2003, John Reynolds~ wrote: > > > sendto: permission denied > > Turn off ipfw, then try again. > Oooops! Sorry, my bad. cut-n-paste error left firewall stuff in this machine's config (which it shouldn't have) and I didn't have the firewall "opened". Mystery solved. Thanks! -Jr -- John ReynoldsSr. Physical Design Engineer - WCCG/CCE PDE Intel Corporation MS: CH6-210 Phone: 480-554-9092RIM PIN: 10326855 [EMAIL PROTECTED] (e-mail with "PAGE" in subj to forward to RIM) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dhclient/route buggy under 5.1-RELEASE
Just an FYI: I've noticed some bugginess in dhclient or route under 5.1-RELEASE. It seems to be tied to route handling somehow. For example, last night I shut down my wi0 interface and brought up my fxp0 interface using dhclient. For some reason, ANYTHING that had to access the network would just "spin" (for lack of a better word). CPU was at or near 98% _idle_, but any programs that used the network were incredibly slow to start (like, 30 minutes for LinNeighborhood, etc...). I also ran netstat, and it "hung" after writing the field descriptions to the terminal. Bringing my fxp0 interface down would always solve the problem and all programs would speed up again (but obviously they no longer had network connectivity). I solved the problem by killing dhclient, flushing my routes, and adding my default route back in using 'route add'. I ran ktrace on my mozilla process while all of this was happening (the window hadn't appeared yet, but mozilla-bin was running), and here is a sample of the kdump output: -- BEGIN kdump OUTPUT -- 946 mozilla-bin RET sendto 28/0x1c 946 mozilla-bin CALL gettimeofday(0xbfbfde90,0) 946 mozilla-bin RET gettimeofday 0 946 mozilla-bin CALL kevent(0xc,0xbfbfdeb0,0x1,0xbfbfdeb0,0x1,0xbfbfde00) 946 mozilla-bin RET kevent 0 946 mozilla-bin CALL poll(0x8088000,0x1,0) 946 mozilla-bin RET poll 0 946 mozilla-bin CALL poll(0x8088000,0x2,0x1388) 946 mozilla-bin RET poll 0 946 mozilla-bin CALL gettimeofday(0x28875178,0) 946 mozilla-bin RET gettimeofday 0 946 mozilla-bin CALL kevent(0xc,0,0,0xbfbfdeb0,0x1,0xbfbfde00) 946 mozilla-bin RET kevent 0 946 mozilla-bin CALL fstat(0xd,0xbfbfdda0) 946 mozilla-bin RET fstat 0 946 mozilla-bin CALL close(0xd) 946 mozilla-bin RET close 0 946 mozilla-bin CALL socket(0x2,0x2,0) 946 mozilla-bin RET socket 13/0xd 946 mozilla-bin CALL fcntl(0xd,0x3,0) 946 mozilla-bin RET fcntl 2 946 mozilla-bin CALL fcntl(0xd,0x4,0x6) 946 mozilla-bin RET fcntl 0 946 mozilla-bin CALL sendto(0xd,0xbfbfe130,0x1c,0,0x28956730,0x10) 946 mozilla-bin GIO fd 13 wrote 28 bytes "\M-m\M-q\^A\0\0\^A\0\0\0\0\0\0 trevarthan\0\0\^A\0\^A" 946 mozilla-bin RET sendto 28/0x1c 946 mozilla-bin CALL gettimeofday(0xbfbfde90,0) 946 mozilla-bin RET gettimeofday 0 946 mozilla-bin CALL kevent(0xc,0xbfbfdeb0,0x1,0xbfbfdeb0,0x1,0xbfbfde00) 946 mozilla-bin RET kevent 0 946 mozilla-bin CALL poll(0x8088000,0x1,0) 946 mozilla-bin RET poll 0 946 mozilla-bin CALL poll(0x8088000,0x2,0x1388) 946 mozilla-bin RET poll 0 946 mozilla-bin CALL gettimeofday(0x28875178,0) 946 mozilla-bin RET gettimeofday 0 946 mozilla-bin CALL kevent(0xc,0,0,0xbfbfdeb0,0x1,0xbfbfde00) 946 mozilla-bin RET kevent 0 946 mozilla-bin CALL fstat(0xd,0xbfbfdda0) 946 mozilla-bin RET fstat 0 946 mozilla-bin CALL close(0xd) 946 mozilla-bin RET close 0 946 mozilla-bin CALL socket(0x2,0x2,0) 946 mozilla-bin RET socket 13/0xd 946 mozilla-bin CALL fcntl(0xd,0x3,0) 946 mozilla-bin RET fcntl 2 946 mozilla-bin CALL fcntl(0xd,0x4,0x6) 946 mozilla-bin RET fcntl 0 946 mozilla-bin CALL sendto(0xd,0xbfbfe130,0x1c,0,0x28956740,0x10) 946 mozilla-bin GIO fd 13 wrote 28 bytes "\M-m\M-q\^A\0\0\^A\0\0\0\0\0\0 trevarthan\0\0\^A\0\^A" 946 mozilla-bin RET sendto 28/0x1c 946 mozilla-bin CALL gettimeofday(0xbfbfde90,0) 946 mozilla-bin RET gettimeofday 0 946 mozilla-bin CALL kevent(0xc,0xbfbfdeb0,0x1,0xbfbfdeb0,0x1,0xbfbfde00) 946 mozilla-bin RET kevent 0 946 mozilla-bin CALL poll(0x8088000,0x1,0) 946 mozilla-bin RET poll 0 946 mozilla-bin CALL poll(0x8088000,0x2,0x1388) 946 mozilla-bin RET poll 0 946 mozilla-bin CALL gettimeofday(0x28875178,0) 946 mozilla-bin RET gettimeofday 0 946 mozilla-bin CALL kevent(0xc,0,0,0xbfbfdeb0,0x1,0xbfbfde00) 946 mozilla-bin RET kevent 0 946 mozilla-bin CALL fstat(0xd,0xbfbfdda0) 946 mozilla-bin RET fstat 0 946 mozilla-bin CALL close(0xd) 946 mozilla-bin RET close 0 946 mozilla-bin CALL socket(0x2,0x2,0) 946 mozilla-bin RET socket 13/0xd 946 mozilla-bin CALL fcntl(0xd,0x3,0) 946 mozilla-bin RET fcntl 2 946 mozilla-bin CALL fcntl(0xd,0x4,0x6) 946 mozilla-bin RET fcntl 0 946 mozilla-bin CALL sendto(0xd,0xbfbfe130,0x1c,0,0x28956730,0x10) 946 mozilla-bin GIO fd 13 wrote 28 bytes "\M-m\M-q\^A\0\0\^A\0\0\0\0\0\0 trevarthan\0\0\^A\0\^A" 946 mozilla-bin RET sendto 28/0x1c 946 mozilla-bin CALL gettimeofday(0xbfbfde90,0) 946 mozilla-bin RET gettimeofday 0 946 mozilla-bin CALL kevent(0xc,0xbfbfdeb0,0x1,0xbfbfdeb0,0x1,0xbfbfde00) 946 mozilla-bin RET kevent 0 946 mozilla-bin CALL poll(0x8088000,0x1,0) 946 mozilla-bin RET poll 0 946 mozilla-bin CALL poll(0x8088000,0x2,0x2710) 946 mozilla-bin RET poll 0 946 mozilla-bin CALL
Re: ath0 card: CardBus card activiation failed
In message: <[EMAIL PROTECTED]> Lukas Ertl <[EMAIL PROTECTED]> writes: : with a kernel from this morning I can't get my ath0 Cardbus device up : again, when I plug it in, I get: : : cbb1: CardBus card activation failed : : The card has worked fine up until now. Maybe some of the recent commits : to pccbb.c/pccard.c broke something? H, I'm using this card just fine right now. Can you set 'hw.cbb.debug=1' in your boot loader (or set it with sysctl) and send me the results of a card insertion? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1, Data Corruption, Intel, Oh my! [patch]
All of the Email I have received from the many people testing this patch (THANKS!!!) has been positive so far with respect to the data corruption problem. There remains one outstanding issue to be resolved prior to committing this and due to the nature of the problem, it's been taking a little longer for me to fix it. The issue has to do with running the patch in combination with APM (I am told that the APM problem actually existed in the past as well but was somehow only apparent when running with DISABLE_PSE). I *think* that the problem has to do with our bios code switching to the page 0 stack which somehow leads to problems when this patch is applied (or when stock -current is used but with DISABLE_PSE). Because I don't have any machine that use the APM code, debugging the problem consists of me changing something, then providing a patch to someone with APM, and then waiting for the results. This is a time-consuming process, but as soon as the problem is addressed, I will commit the changes. Thanks to everyone who has helped test this so far. Regards, -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ath0 card: CardBus card activiation failed
Hi, with a kernel from this morning I can't get my ath0 Cardbus device up again, when I plug it in, I get: cbb1: CardBus card activation failed The card has worked fine up until now. Maybe some of the recent commits to pccbb.c/pccard.c broke something? regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: My details
Subject: This is an AutoResponse from eBay Thank you for your response. As this is an automated email, please do not reply. If you have a question for eBay Customer Support, please visit the following eBay Help page. This page will help you locate the answer to your question, or assist you in contacting eBay Customer Support. http://pages.ebay.com/help/index_popup.html To change your notification preferences, which determine how you would like eBay to communicate with you, please visit our Notification Preferences Change page (please note that it might take a few days to process your request). http://cgi3.ebay.com/aw-cgi/eBayISAPI.dll?OptinLoginShow As always, we appreciate your patronage. Regards, eBay -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Strange keyboard behavior
Latest -current, just cvsuped and build world/kernel yesterday. In a nutshell, if I reboot out of FreeBSD, my keyboard becomes non-functional, until I power my laptop off/on again. For example, say I use reboot(8) to boot out of FreeBSD. When the boot loader comes up, which in my case is LILO, I find that I cannot navigate with the keyboard. Seemingly, none of the keys work. To diagnose what was going on, I configured LILO to boot straight into Linux. OK, so I reboot out of FreeBSD, and reach the LILO menu. I hit a few keys, and see no response. Once Linux boots, I can see the keys that I hit "replaying" on the screen. Apparently, what's going on is the keyboard buffer isn't being flushed. This is only when I reboot after running FreeBSD-current. If I power-on from the off state, or reboot from Linux or Windows, the keyboard behavior is normal. Also, once running FreeBSD, keyboard behavior is normal (provided I boot "cold" or from any other OS, not FreeBSD). Maybe it's something specific to my HP Pavilion notebook and the latest FreeBSD-current... :-/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is rl broken?
On Tue, 19 Aug 2003, John Reynolds~ wrote: > > This thread originally taken from the -stable mailing list, but I'm seeing > weird things in -current now, so I thought I'd ask > > > I cvsup'd and rebuilt a FreeBSD 4.8 system last Friday after receiving the > > realpath security advisory. The machine is remote and the NIC uses the rl > > driver. After booting the machine I had no network connectivity. The > > person at the remote site says the boot was normal and he could see that the > > NIC was properly configured but he could not ping it and I could not login. > > We booted off kernel.old and everything came up fine. > > > > I have a machine with an Intel nic using the fxp driver that is exhibiting the > same sort of weirdness. I just installed 5.1-RELEASE on it after it was built > and things were rock solid. I got my NIC configured to use DHCP in my LAN here > at home, everything's fine. then I cvsup and buildworld/kernel (the same > kernel config that an *identical* system on my LAN is using) and test out the > new kernel before installkernel and dhclient seems to finish properly and the > interface seems configured correctly with the correct IP. netstat -r shows the > right stuff, but I can't even ping the NIC itself. It says > > sendto: permission denied > > when I try to ping the NIC itself and *also* 127.0.0.1. If I revert back to the > 5.1-RELEASE kernel with the same hardware and zero config changes, everything > is hunky dory again. Sorry, I'm light on details--I need to do some more > experiments and will cut-n-paste what I see, but I wanted to see if anybody > else is experiencing anything oddball like this. Sounds like you've put IPFIREWALL in your kernel without IPFIREWALL_DEFAULT_TO_ACCEPT. Either add this to your kernel or add an ipfw rule as allows: ipfw add allow ip from any to any 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: Thank you!
Subject: This is an AutoResponse from eBay Thank you for your response. As this is an automated email, please do not reply. If you have a question for eBay Customer Support, please visit the following eBay Help page. This page will help you locate the answer to your question, or assist you in contacting eBay Customer Support. http://pages.ebay.com/help/index_popup.html To change your notification preferences, which determine how you would like eBay to communicate with you, please visit our Notification Preferences Change page (please note that it might take a few days to process your request). http://cgi3.ebay.com/aw-cgi/eBayISAPI.dll?OptinLoginShow As always, we appreciate your patronage. Regards, eBay -- ___ [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-08-20 10:41:50 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-08-20 10:41:50 - 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-08-20 10:44:28 - 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-08-20 11:40:43 - 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 Wed Aug 20 11:40:43 GMT 2003 >>> Kernel build for GENERIC completed on Wed Aug 20 11:49:38 GMT 2003 TB --- 2003-08-20 11:49:38 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-08-20 11:49:38 - 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 Wed Aug 20 11:49:38 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/pccbb/pccbb.c:265: warning: `cbb_read_config' declared `static' but never defined /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/pccbb/pccbb.c:267: warning: `cbb_write_config' declared `static' but never defined /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/pccbb/pccbb.c:297: warning: `cbb_remove_res' defined but not used /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/pccbb/pccbb.c:311: warning: `cbb_find_res' defined but not used /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/pccbb/pccbb.c:323: warning: `cbb_insert_res' defined but not used /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/pccbb/pccbb.c:889: warning: `cbb_setup_intr' defined but not used /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/pccbb/pccbb.c:920: warning: `cbb_teardown_intr' defined but not used /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/pccbb/pccbb.c:1330: warning: `cbb_do_power' defined but not used *** 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-08-20 11:53:33 - /usr/bin/make returned exit code 1 TB --- 2003-08-20 11:53:33 - ERROR: failed to build lint kernel TB --- 2003-08-20 11:53:33 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: an driver / Cisco Aironet 340 stopped working
Martin Blapp writes: > > Hi, > > > Now I tested this at work with ISC DHCPD V3.0.1rc9 and it works just > > fine. > > with the freebsd dhclient, or a unmodified V3.0.1rc9 one ? > > > For some reason Cisco dhcp server doesn't like FreeBSD anymore > > if connect comes from an0 driver :-) > > Can you test the V3.0.1rc9 one at home too ? > I've to clarify this a little. I just used different dhcp server so FreeBSD side was always using the same latest dhclient cvsupped week ago. ISC dhcp server works with an0 and em0 Cisco dhcp server works with em0 but not with an0 Tomppa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: an driver / Cisco Aironet 340 stopped working
Hi, > Now I tested this at work with ISC DHCPD V3.0.1rc9 and it works just > fine. with the freebsd dhclient, or a unmodified V3.0.1rc9 one ? > For some reason Cisco dhcp server doesn't like FreeBSD anymore > if connect comes from an0 driver :-) Can you test the V3.0.1rc9 one at home too ? > Tomppa > Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: an driver / Cisco Aironet 340 stopped working
Martin Blapp writes: > > Hi, > > > DHCPREQUEST on em0 to 255.255.255.255 port 67 > > DHCPACK from 212.226.167.254 > > bound to 212.226.167.247 -- renewal in 228123 seconds. > > So the first time it works ? You get an IP here ... > > > an0: Found Link on interface > > DHCPDISCOVER on an0 to 255.255.255.255 port 67 interval 6 > > DHCPDISCOVER on an0 to 255.255.255.255 port 67 interval 13 > > DHCPDISCOVER on an0 to 255.255.255.255 port 67 interval 7 > > DHCPDISCOVER on an0 to 255.255.255.255 port 67 interval 9 > > DHCPDISCOVER on an0 to 255.255.255.255 port 67 interval 11 > > DHCPDISCOVER on an0 to 255.255.255.255 port 67 interval 15 > > No DHCPOFFERS received. > > No working leases in persistent database - sleeping. > > Why don't you get an IP here ? Does the server see your requests ? > If not, the an0 driver is broken for your card. > > IMHO it's not dhclient fault here. > Now I tested this at work with ISC DHCPD V3.0.1rc9 and it works just fine. For some reason Cisco dhcp server doesn't like FreeBSD anymore if connect comes from an0 driver :-) Tomppa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 08/20/2003 04:00 make buildkernel failed: aac_disk.c:276:warning: uintmax_t format
[EMAIL PROTECTED] wrote: > After successful cvsup of complete system sources on 08.20.2003 around > 04:00, and a successful make buildworld, make builkernel failed with the > following: > > cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstric > t-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fforma > t-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I > /usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/c > ontrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_glo > bal.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-str > ings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/aac/a > ac_disk.c > /usr/src/sys/dev/aac/aac_disk.c: In function `aac_disk_dump': > /usr/src/sys/dev/aac/aac_disk.c:276: warning: uintmax_t format, different type a > rg (arg 2) > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/GENERIC. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > root: make buildkernel Already fixed, please cvsup again. Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fwcontrol -r missing a close() call
On Wed, Aug 20, 2003 at 01:11:45AM -0700, Terry Lambert wrote: > I used to think this way too. Then I had to deal with some > multithreaded applications that failed to pthread_join() or > pthread_kill() their threads, AND with applications that had I'm using kqueue() instead for my current project. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on ia64/ia64
TB --- 2003-08-20 09:20:22 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-08-20 09:20: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-08-20 09:23:04 - 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 >>> stage 4: make dependencies >>> stage 4: building everything.. TB --- 2003-08-20 10:28:11 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Aug 20 10:28:12 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/pccbb/pccbb.c:265: warning: `cbb_read_config' declared `static' but never defined /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/pccbb/pccbb.c:267: warning: `cbb_write_config' declared `static' but never defined /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/pccbb/pccbb.c:297: warning: `cbb_remove_res' defined but not used /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/pccbb/pccbb.c:311: warning: `cbb_find_res' defined but not used /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/pccbb/pccbb.c:323: warning: `cbb_insert_res' defined but not used /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/pccbb/pccbb.c:889: warning: `cbb_setup_intr' defined but not used /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/pccbb/pccbb.c:920: warning: `cbb_teardown_intr' defined but not used /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/pccbb/pccbb.c:1330: warning: `cbb_do_power' defined but not used *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/modules/cbb. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC. *** 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-08-20 10:41:50 - /usr/bin/make returned exit code 1 TB --- 2003-08-20 10:41:50 - ERROR: failed to build generic kernel TB --- 2003-08-20 10:41:50 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
08/20/2003 04:00 make buildkernel failed: aac_disk.c:276: warning:uintmax_t format
After successful cvsup of complete system sources on 08.20.2003 around 04:00, and a successful make buildworld, make builkernel failed with the following: cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstric t-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fforma t-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I /usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/c ontrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_glo bal.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-str ings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/aac/a ac_disk.c /usr/src/sys/dev/aac/aac_disk.c: In function `aac_disk_dump': /usr/src/sys/dev/aac/aac_disk.c:276: warning: uintmax_t format, different type a rg (arg 2) *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. root: make buildkernel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nfs mounts on FreeBSD 5.1
Hi. I'm trying to nfs-mount a FreeBSD 5.1 client on a Redhat 7.3 nfs-server. I have the line nfs_client_enable="YES" in /etc/rc.conf and nfsclient.ko is loaded. The error I get is [udp] nfs-srv:/mount/a: RPCMNT: clnt_create: RPC: Program not registered The mount-command is mount_nfs -o port=2049 nfs-srv:/mount/a /mount/a I've tried nfs v.2 and 3 as options, but no change. The Linux-server is accepting nfs-mount-requests from other clients so the server itself is OK. Doing a tcpdump gives me: sidsel/home/claus#>tcpdump udp port nfs tcpdump: listening on fxp0 11:34:11.177302 sidsel.1061287510 > nfs-srv.nfs: 40 null 11:34:11.177421 nfs-srv.nfs > sidsel.1061287510: reply ok 24 null (DF) The FreeBSD 5.1 client is tracking tag=RELENG_5_1 cvsup'ed 14. Aug. 2003. Only IPv4. regards Claus Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dhclient and pid file
Hi I just noticed that dhclient takes 'ages' to write it's pidfile. Shell-constructs similar to this dhclient -q -1 -pf /etc/dhclient.pid fxp0 [ -e /etc/dhclient.pid ] && kill -9 `cat /etc/dhclient.pid` do not work because dhclient is too slow in writing its pid file. is this the expected behaviour with pid-file writing daemons? thanks, t. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Regarding recent spam on the list
Bill Moran wrote: > Just curious if anyone knows the origin of all these auto-responses, etc. > > I'm seeing a lot of these on every list I'm subscribed to (not all of them > FreeBSD related) so I was wondering if some Windows trojan is running rampant > and using these list addresses as return addys? > > Anyone know? Yes. There are a number of machines in the texas.gov domain that are infected with the SoBIG worm because the morons running them are too dumb to install Windows patches from 6 months ago, and to split their inbound and outbound mail servers and filter out outbound mail from forged "from" addresses with an IP address that happens to be in their netblock, but with a source domain that is not one of the domains under their immediate control. One of these machines is 204.65.42.107, which is in the netblock subdelegated to access.texas.gov. There are about 4 others. but that one in particular has someone who is subscribed to the FreeBSD mailing lists. Be warned that if you post to these mailing lists at all, the user on that machine subscribed to the list will end up using *your* email address will be used to forge outbound email to other people by the worm. Most people who build out email infrastructure have no idea of what they are doing. On the plus side, whoever is running that frigging machine is liable under California law for a fine of $10,000 and up to 3 years in jail, since forging a "from" address belonging to someone else is now a felony in California. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PPTP Question
Hi, On Wed, 20 Aug 2003, Evgeny Ivanov wrote: > > Hello Guys > > I was wondering if someone is using MPD as a PPTP server. millions of users are doing this :-) > I have a question regarding the MPD and looking experienced users . MPD is now hosted on http://sourceforge.net/projects/mpd MPD has his own mailinglist: [EMAIL PROTECTED] bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com JAWA Management Software GmbH - http://www.jawa.at Tel: ++43-(0)316-403274-12 - GSM: ++43-(0)676-84 03 15 712 --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fwcontrol -r missing a close() call
Dan Nelson wrote:
> In the last episode (Aug 19), Andre Guibert de Bruet said:
> > open("/dev/fw0.0",0x2,01001132500) = 3 (0x3)
> > ioctl(3,FW_IBUSRST,0xbfbff400) = 0 (0x0)
> > exit(0x0)
> > process exit, rval = 0
> >
> > We're not closing fd #3 before exiting the process. This is also the case
> > with 4.8-STABLE.
> >
> > Semantics? Nit-picking? Both? :)
>
> Why bother closing a fd when exit() will do it for you? You don't
> close stdout when you're done with it :)
I used to think this way too. Then I had to deal with some
multithreaded applications that failed to pthread_join() or
pthread_kill() their threads, AND with applications that had
called blocking calls on fd's in one thread, and then closed
the fd's out from under the blocking calls in another, thus
triggering a kernel panic, AND applications which failed to
realize a signal may interrupt a close() call, making it
return -1 with errno == EINTR, thus leaking descriptors on any
close that was interrupted by a signal.
After dealing with all that, I have to say that the lack of an
explicit close of an fd is an incredibly bad example for any
programmer who might read your code. As such, it should be
fixed, since it may be your own foot you are shooting in the
future by providing a bad example to some programmer that then
writes code that you decide you want to run on your machine.
Don't even get me started on the people who think that all the
world is Linux, and fail to bzero() their sockaddr_in's before
filling out only some of the structure members, and having all
the various connect/bind/other socket related calls fail on
non-Linux machines because the programmers didn't know how to
properly use the interfaces they were calling.
-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PPTP Question
Hello Guys I was wondering if someone is using MPD as a PPTP server. I have a question regarding the MPD and looking experienced users . ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freebsd-current@freebsd.org
Robert Watson wrote: > Can't speak to the specifics of this, but you want to be very careful not > to use kernel modules with PAE: modules are currently without the context > of the kernel configuration file, and PAE introduces possible binary > incompatibility with modules that dig into VM (which many drivers do). This is a good argument for defining it as it's own port, like IA64 or SPARC or whatever. > Various > conversations have happened regarding how to address this problem, and I'm > not sure we've come up with the right answer yet. There seem to be two > conflicting directions: build modules in the context of a kernel module > (and get conditionally compiled type/structure/code/... pieces), and try > to make the module build entirely independent of a kernel configuration. The approach I prefer is: PAE gives you access to up to 64G of real memory, and you really only use it when you have more than 4G of physical memory (my understanding of the memory architecture on the hardware where this would be used is that the minimum ends up being 6G). So you should have no objection to compiling all the drivers in statically, since it's not like you need to save the space. 8-) 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 i386/i386
TB --- 2003-08-20 06:41:28 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-08-20 06:41:28 - 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-08-20 06:43:41 - 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-08-20 07:45:51 - 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 Wed Aug 20 07:45:51 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/ddb/db_variables.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/ddb/db_watch.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/ddb/db_write_cmd.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/aac/aac.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib
