Re: LOR kernel trap
I am build freebsd-current w/ cvs snap on 2003.11.11 and have some problem: 2. kernel trap cpuid = 0 acic id = 00 This has been fixed in later snaps. Thanks, I now try 5.1-CURRENT FreeBSD 5.1-CURRENT #8: Fri Nov 21 23:12:09 MSK 2003. This trap seems fixed. And I now see 'kernel: stray irq7' -- Slawa Olhovchenkov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
fxp floods network on panic
I have an up to date SMP machine with an Intel 10/100 card and fxp driver. The machine has started to panic during running make release, and when it does, the intel card floods the network and pretty much wipes it out. ie no machines on the same switch can even ping each other. The switch is lit up like a christmas tree, and rebooting the box immediately brings the network to life. The machine is hung solid, so even though I have serial access to it, I cant reboot it to clear the condition. I seem to remember that the Intel card can go into some sort of test mode on a panic. Is there any way of preventing this? Or did I just imagine that? Lawrence Farr EPC Direct Limited ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dumb question 'Bad system call' after make world
Hello, On Fri, Nov 21, 2003 at 09:44:17PM -0500, Barney Wolff wrote: Does make world build a kernel? I didn't think so, and OP's message indicates that make world is all he did. I suspect re-install is the best answer now. Yes, make world does not build or install kernels. I'd also go for reinstall, provided the OP has not yet put a lot of work into customising the install... Will somebody please tell me when make world is ever correct in the environment of the last several years? I've been unable to understand its continued existence as a target. One of it's last hideouts seems to be the make release target... -- 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: fxp floods network on panic
On Sat, Nov 22, 2003 at 09:10:54AM -, Lawrence Farr wrote: I have an up to date SMP machine with an Intel 10/100 card and fxp driver. The machine has started to panic during running make release, and when it does, the intel card floods the network and pretty much wipes it out. ie no machines on the same switch can even ping each other. The switch is lit up like a christmas tree, and rebooting the box immediately brings the network to life. The machine is hung solid, so even though I have serial access to it, I cant reboot it to clear the condition. I seem to remember that the Intel card can go into some sort of test mode on a panic. Is there any way of preventing this? Or did I just imagine that? Known problem. Set hw.fxp_noflow: 1 Kris pgp0.pgp Description: PGP signature
Re: Updated acpi_cpu patch
On Sat, 22 Nov 2003, Lukas Ertl wrote: Ah, this would explain why I can see the C3 states change after a suspend/resume - USB is dead then :-) I'm gonna try without USB and send you the output again. Yes, looks better now: hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185 hw.acpi.cpu.cx_lowest: 3 hw.acpi.cpu.cx_history: 0/0 451979/0 2361/15 805279/27634 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]
geom-ata forever cycle
5.1-current of 2003-11-20 hangs during kernel initialization with forever cycle around geom partitioning detection and ATA read failure. Message rate is too fast to record, no stopping is available, no serial console. Previous 5-current on this machine was of 2003-05-23. How to diagnose? dmesg of May's current says: start_init: trying /sbin/init ad0: UDMA ICRC error cmd=read fsbn 4397730 of 4397730-4397857 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569ad0: success settin g PIO4 on Intel ICH2 chip falling back to PIO mode Main FreeBSD here is 4.9-release which doesn't complaint to crc errors. Kernel config wasn't changed: machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident nn15 maxusers0 #To statically compile in device wiring instead of /boot/device.hints hints GENERIC.hints #Default places to look for devices. makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options SCHED_4BSD options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support #optionsUFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev # Debugging for use in -current options DDB #Enable the kernel debugger options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS options WITNESS #Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN#Don't run witness on spinlocks for speed device isa device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device ether device loop# Network loopback device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory disks # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter device speaker #Play IBM BASIC-style noises out your speaker # To include support for VGA VESA video modes options VESA # Turn on extra debugging checks and output for VESA support. options VESA_DEBUG # Enable i386 a.out binary support options COMPAT_AOUT # Enable the linux-like proc filesystem support (requires COMPAT_LINUX # and PSEUDOFS) options COMPAT_LINUX options LINPROCFS options MSGBUF_SIZE=131072 #options
Re: geom-ata forever cycle
Personally I dont think this is GEOM related. I had a drive start doing this to me (happens often as I work in a large datacenter) and the drive is about to die. What brand drive is it and how old is it? You may waanna look into replacing the drive if you have that option. I had one tonight that did that to me, swap the drive, fixed. Regards, Nick H. Network Operations Center [EMAIL PROTECTED] Please rate my performance! http://www.supportteam.net/rate.php3 Please submit all new support requests to http://ticketmonster.hostingsupport.com/ --- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. - Original Message - From: Valentin Nechayev [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 22, 2003 5:08 AM Subject: geom-ata forever cycle 5.1-current of 2003-11-20 hangs during kernel initialization with forever cycle around geom partitioning detection and ATA read failure. Message rate is too fast to record, no stopping is available, no serial console. Previous 5-current on this machine was of 2003-05-23. How to diagnose? dmesg of May's current says: start_init: trying /sbin/init ad0: UDMA ICRC error cmd=read fsbn 4397730 of 4397730-4397857 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569ad0: success settin g PIO4 on Intel ICH2 chip falling back to PIO mode Main FreeBSD here is 4.9-release which doesn't complaint to crc errors. Kernel config wasn't changed: machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident nn15 maxusers 0 #To statically compile in device wiring instead of /boot/device.hints hints GENERIC.hints #Default places to look for devices. makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options SCHED_4BSD options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support #options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev # Debugging for use in -current options DDB #Enable the kernel debugger options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS options WITNESS #Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed device isa device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device ether device loop # Network loopback device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory disks # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter device speaker #Play IBM BASIC-style noises
Re: geom-ata forever cycle
Here's a snippet of dmesg that was before the drive was swapped: Nov 22 09:58:04 juan kernel: ad3: UDMA ICRC error cmd=read fsbn 0 of 0-15 retrying Nov 22 09:58:04 juan last message repeated 2 times Nov 22 09:58:04 juan kernel: ad3: UDMA ICRC error cmd=read fsbn 0 of 0-15 falling back to PIO mode Nov 22 09:58:40 juan kernel: ad2: UDMA ICRC error cmd=write fsbn 1756413 of 1756413-1756497 retrying Nov 22 09:58:40 juan last message repeated 2 times Nov 22 09:58:41 juan kernel: ad2: UDMA ICRC error cmd=write fsbn 34624421 of 34624421-34624548 retrying Nov 22 09:58:42 juan kernel: ad2: UDMA ICRC error cmd=write fsbn 41273248 of 41273248-41273374 retrying Nov 22 09:58:42 juan last message repeated 2 times Nov 22 09:58:42 juan kernel: ad2: UDMA ICRC error cmd=write fsbn 41273248 of 41273248-41273374 falling back to PIO mode After replacing the drive, error gone. Regards, Nick H. Network Operations Center [EMAIL PROTECTED] Please rate my performance! http://www.supportteam.net/rate.php3 Please submit all new support requests to http://ticketmonster.hostingsupport.com/ --- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. - Original Message - From: Nick H. -- Network Operations [EMAIL PROTECTED] To: Valentin Nechayev [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, November 22, 2003 5:45 AM Subject: Re: geom-ata forever cycle Personally I dont think this is GEOM related. I had a drive start doing this to me (happens often as I work in a large datacenter) and the drive is about to die. What brand drive is it and how old is it? You may waanna look into replacing the drive if you have that option. I had one tonight that did that to me, swap the drive, fixed. Regards, Nick H. Network Operations Center [EMAIL PROTECTED] Please rate my performance! http://www.supportteam.net/rate.php3 Please submit all new support requests to http://ticketmonster.hostingsupport.com/ --- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. - Original Message - From: Valentin Nechayev [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 22, 2003 5:08 AM Subject: geom-ata forever cycle 5.1-current of 2003-11-20 hangs during kernel initialization with forever cycle around geom partitioning detection and ATA read failure. Message rate is too fast to record, no stopping is available, no serial console. Previous 5-current on this machine was of 2003-05-23. How to diagnose? dmesg of May's current says: start_init: trying /sbin/init ad0: UDMA ICRC error cmd=read fsbn 4397730 of 4397730-4397857 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569ad0: success settin g PIO4 on Intel ICH2 chip falling back to PIO mode Main FreeBSD here is 4.9-release which doesn't complaint to crc errors. Kernel config wasn't changed: machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident nn15 maxusers 0 #To statically compile in device wiring instead of /boot/device.hints hints GENERIC.hints #Default places to look for devices. makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options SCHED_4BSD options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support #options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem
Locking problem with snapshots...
I had some transient panic today that resulted in a hard panic that I had to pull the plug on to reboot... once up again and the background file system check was running, I picked up this dandy of a panic: panic: lockmgr: locking against myself panic messages: --- panic: lockmgr: locking against myself syncing disks, buffers remaining... panic: bremfree: removing a buffer not on a queue Uptime: 4m51s Dumping 255 MB [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 16[CTRL-C to abort] [CTRL-C to abort] 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- Reading symbols from /boot/kernel/snd_maestro3.ko...done. Loaded symbols for /boot/kernel/snd_maestro3.ko Reading symbols from /boot/kernel/snd_pcm.ko...done. Loaded symbols for /boot/kernel/snd_pcm.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc0533229 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc0533608 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc057dfd1 in bremfreel (bp=0xd087f438) at /usr/src/sys/kern/vfs_bio.c:649 #4 0xc057dedb in bremfree (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:631 #5 0xc0582831 in getblk (vp=0xcbdae924, blkno=-1509388, size=16384, slpflag=0, slptimeo=0, flags=0) at /usr/src/sys/kern/vfs_bio.c:2470 #6 0xc057e0a2 in breadn (vp=0xcbdae924, blkno=0, size=0, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at /usr/src/sys/kern/vfs_bio.c:702 #7 0xc057e04c in bread (vp=0x0, blkno=0, size=0, cred=0x0, bpp=0x0) at /usr/src/sys/kern/vfs_bio.c:684 #8 0xc06804c3 in ffs_balloc_ufs2 (vp=0xcbdae924, startoffset=0, size=16384, cred=0xc16b3f00, flags=131072, bpp=0xd6756a40) at /usr/src/sys/ufs/ffs/ffs_balloc.c:706 #9 0xc06892ce in ffs_copyonwrite (devvp=0xcb8f4924, bp=0xd081e5e8) at /usr/src/sys/ufs/ffs/ffs_snapshot.c:1992 #10 0xc04efdc2 in spec_xstrategy (vp=0xcb8f4924, bp=0xd081e5e8) at /usr/src/sys/fs/specfs/spec_vnops.c:474 #11 0xc04efebb in spec_specstrategy (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:534 #12 0xc04eefd8 in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:122 #13 0xc06a681c in ufs_strategy (ap=0x0) at vnode_if.h:1141 #14 0xc06a7718 in ufs_vnoperate (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2793 #15 0xc057e8dd in bwrite (bp=0xd081e5e8) at vnode_if.h:1116 #16 0xc057f34c in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1152 #17 0xc0696c7f in ffs_fsync (ap=0xd6756c24) at /usr/src/sys/ufs/ffs/ffs_vnops.c:247 #18 0xc0695d49 in ffs_sync (mp=0xcb7e7400, waitfor=3, cred=0xc16b3f00, td=0xc16cb780) at vnode_if.h:627 #19 0xc059709a in sync_fsync (ap=0xd6756cc4) at /usr/src/sys/kern/vfs_subr.c:3515 #20 0xc0593052 in sched_sync () at vnode_if.h:627 #21 0xc051bf00 in fork_exit (callout=0xc0592d60 sched_sync, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:793 This looks like it's up Kirk's alley, but I figured I'd send it here in case someone else has some info on this. I've still got the vmcore if anyone wants to take a crack at it. FWIW, as some back story, I was compiling gdb6-release, the machine panic'ed the 1st time. Once back up, not more than 90sec after the machine was up, I kicked off the build of GDB again and am pretty sure that's what 'caused this. -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
How to fix this in 5.1-REL??
I end up with the following when I run `make world` on 5.1-RELEASE-p10. cut /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/eh_globals.cc:33: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/eh_personality.cc:34: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory /usr/src/contrib/libstdc++/libsupc++/eh_personality.cc:38:23: unwind-pe.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/eh_terminate.cc:34: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/eh_throw.cc:32: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/eh_type.cc:32: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/pure.cc:31: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/vec.cc:37: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/lib/libstdc++. *** Error code 1 Stop in /usr/src/gnu/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Best regards, Odhiambo Washington Wananchi Online Ltd. --+- Odhiambo W. wash(at)wananchi(dot)com . WANANCHI ONLINE LTD (Nairobi, KE) http://www.wananchi.com/email/ . 1ere Etage, Loita Hse, Loita St., Mobile: (+254) 722 743 223 . # 10286, 00100 NAIROBI --+- What the hell, go ahead and put all your eggs in one basket. It takes a lot of hard work to made something easy. Then when you're done, people look at it and ask, Oh, it's so simple; what was the big deal? --Ralph Johnson smime.p7s Description: S/MIME cryptographic signature
Re: dumb question 'Bad system call' after make world
On Fri, 21 Nov 2003, Barney Wolff wrote: Will somebody please tell me when make world is ever correct in the environment of the last several years? I've been unable to understand its continued existence as a target. From my normal world-building script: DESTDIR=/c/z/root \ MAKEOBJDIRPREFIX=/c/z/obj \ time -l make -s world /tmp/world.out 21 Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
localhost adress
Since my last current (FreeBSD renaissance.homeip.net 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri Nov 21 17:49:36 CET 2003), I couldn't use anymore local network program like mlnet (telnet localhost 4000) or squid as my adress is 81.65.xx.xx (from my modem-cable) instead of 127.0.0.1. I didn't have this trouble with -CURRENT on the 17th of November. Is it related to tcp hostcache or is something weird in my config ? Anthony. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Bernd Walter [EMAIL PROTECTED] wrote: On Fri, Nov 21, 2003 at 12:35:50PM -0500, Brian F. Feldman wrote: Doug White [EMAIL PROTECTED] wrote: The OHCI driver is largely synced with NetBSD so you might see if they have the same bug. I'll look around for a bootable NetBSD CD. NetBSD is different in that point. This might be the underlying wierdness we were seeing in gtetlow's microdrive with transfers over 8k. The one-page-crossing ohci limitation is really annoying. Is there a way to add a quirk for max 8k transfers or anything? Even though that would be patently lame, I'd like to get some sort of workaround here. I don't even know what is supposed to be the problem here -- the fact that it's an ohci controller, an ohci+ehci controller, or that it's some specific controller issue... We never did any page crossing on ohci/ehci bevor the newbus change took place. Found it!!! Definitely a problem created then... --- ohci.c 12 Nov 2003 01:40:11 - 1.138 +++ ohci.c 22 Nov 2003 03:28:42 - @@ -569,7 +569,7 @@ cur-td.td_cbp = htole32(dataphys); cur-nexttd = next; cur-td.td_nexttd = htole32(next-physaddr); - cur-td.td_be = htole32(DMAADDR(dma, curlen - 1)); + cur-td.td_be = htole32(DMAADDR(dma, offset + curlen - 1)); cur-len = curlen; cur-flags = OHCI_ADD_LEN; cur-xfer = xfer; I'm a lot happier now :-) Let's start trying to get this stuff merged in! -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Why is emmintrin.h not installed?
Hi,
while building transcode today, I got the following error:
8-
=== transcode-0.6.10 depends on file: /usr/local/bin/nasm - found
=== transcode-0.6.10 depends on file: /usr/local/bin/ffmpeg - not
found
===Verifying install for /usr/local/bin/ffmpeg in
/usr/ports/multimedia/ffmpeg
=== Building for ffmpeg-0.4.8
gmake -C libavcodec all
gmake[1]: Entering directory
`/usr/ports/multimedia/ffmpeg/work/ffmpeg-0.4.8/libavcodec'
cc -O -pipe -march=athlon-tbird -I/usr/local/include -O3 -ffast-math
-fomit-frame-pointer -g -O3 -Wall -DHAVE_AV_CONFIG_H -I..
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -msse -c -o
i386/fft_sse.o i386/fft_sse.c
In file included from i386/fft_sse.c:24:
/usr/include/xmmintrin.h:1227:23: emmintrin.h: No such file or directory
gmake[1]: *** [i386/fft_sse.o] Error 1
gmake[1]: Leaving directory
`/usr/ports/multimedia/ffmpeg/work/ffmpeg-0.4.8/libavcodec'
gmake: *** [lib] Error 2
*** Error code 2
Stop in /usr/ports/multimedia/ffmpeg.
*** Error code 1
Stop in /usr/ports/multimedia/transcode.
8
Why isn't that file installed together with xmmintrin.h and mmintrin.h
by $SRC/gnu/usr.bin/cc/include/Makefile?
-8-
--- gnu/usr.bin/cc/include/Makefile.org Sat Nov 22 13:54:14 2003
+++ gnu/usr.bin/cc/include/Makefile Sat Nov 22 13:54:28 2003
@@ -5,7 +5,7 @@
.PATH: ${GCCDIR}/config/${GCC_CPU}
.if ${TARGET_ARCH} == i386 || ${TARGET_ARCH} == amd64
-INCS= mmintrin.h xmmintrin.h
+INCS= emmintrin.h mmintrin.h xmmintrin.h
.elif ${TARGET_ARCH} == ia64
INCS= ia64intrin.h
.endif
8--
[System info: FreeBSD klamath 5.1-CURRENT FreeBSD 5.1-CURRENT #13: Mon
Nov 17 22:55:15 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KLAMATH
i386]
Regards,
--
Andreas Kohn [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
On Sat, Nov 22, 2003 at 08:08:29AM -0500, Brian F. Feldman wrote: Found it!!! Definitely a problem created then... --- ohci.c 12 Nov 2003 01:40:11 - 1.138 +++ ohci.c 22 Nov 2003 03:28:42 - @@ -569,7 +569,7 @@ cur-td.td_cbp = htole32(dataphys); cur-nexttd = next; cur-td.td_nexttd = htole32(next-physaddr); - cur-td.td_be = htole32(DMAADDR(dma, curlen - 1)); + cur-td.td_be = htole32(DMAADDR(dma, offset + curlen - 1)); cur-len = curlen; cur-flags = OHCI_ADD_LEN; cur-xfer = xfer; I'm a lot happier now :-) Let's start trying to get this stuff merged in! Great news! -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to fix this in 5.1-REL??
On Sat, Nov 22, 2003 at 03:16:06PM +0300, Odhiambo Washington wrote: I end up with the following when I run `make world` on 5.1-RELEASE-p10. Did you read UPDATING? Kris pgp0.pgp Description: PGP signature
Re: How to fix this in 5.1-REL??
On Sat, Nov 22, 2003 at 03:16:06PM +0300, Odhiambo Washington wrote: I end up with the following when I run `make world` on 5.1-RELEASE-p10. Did you read UPDATING? Kris pgp0.pgp Description: PGP signature
Re: xl0: watchdog timeout
Matt Smith wrote: Jimmy Selgen wrote: On Fri, 2003-11-21 at 21:29, Kris Kennaway wrote: On Fri, Nov 21, 2003 at 09:22:49PM +0100, Jimmy Selgen wrote: I saw this with some of sam's locking changes that (temporarily) broke DUMMYNET. I see you're using ipfilter - it's possible that this configuration has not been well-tested. Are you passing much traffic through ipfilter on this box? The box in question is my workstation, so I guess i'm not passing that much traffic through ipfilter. Also, when I said that the NIC still worked, I might have mislead you a bit. I had about 5-10 timeouts while scp'ing the dmesg output to my other workstation. Data seems to move from userland to the kernel, then get stuck in buffers there for 10-15 seconds, generating timeouts, before they're shipped off. I assume this is expected behaviour when a NIC isnt behaving correctly. It would be helpful if you can do a binary search to narrow down when the problem started. What would you have me search ? I'm a faily seasoned C programmer (12 years experience, some of them doing RTOS kernel work), but dont know much about FreeBSD kernel development, or the process of checking out different kernel revisions. I've tried a build without IPFILTER, and the problem still exists. I've also tried booting with ACPI disabled, and the problem is still there. I have attached a copy of my kernel config file, in case i'm doing something wrong. snip kernel file I have just noticed that my xl0 card is misbehaving as well. I have a 3c905c in my desktop and noticed that an ftp of a file from another machine on the lan (100 meg switched) was only going at around 70KB/sec. Normally I get around 9MB/sec. A netstat -bi xl0 shows lots of errors: NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 3081878 217616 3778632119 2451968 6 368229701 0 I also have this in my messages file: xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 240 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 300 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 360 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 420 bytes I do not currently have any debugging options compiled into this kernel. FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Nov 18 20:05:52 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 I am actually in the process of building a new world/kernel to update it again as I thought it might be something that's fixed. I unfortunatly can not boot the old kernel to see if it works fine in that because of the statfs changes so it *could* possibly be the NIC has gone funny. I also have a 3c905a and a 3c905b in my router machine and this is showing no issues at all with the same dated kernel. Matt. I am now running a 5.2-BETA kernel from today and still have the problem with my xl0 card here. I can only get a max throughput of around 110KB/sec through it. And I am getting huge amounts of errors in the interface stats (5 minutes after booting): NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 217042 1290 57669634 309460 0 208178476 0 So the question is, is this my network card has died and I need to throw it out or is it related to Jimmy Selgen's email about the watchdog timeouts? It's a shame I can't boot an old kernel to test really. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MAJOR number
Thanks! Best regards, Roman Kurakin M. Warner Losh wrote: In message: [EMAIL PROTECTED] Roman Kurakin [EMAIL PROTECTED] writes: : ??? ce Cronyx Tau-32 E1 adapter I've checked -stable and -current. You may have: 185 ce Cronyx Tau-32 E1 adapeter [EMAIL PROTECTED] for your adapter. Sorry for the hassles in getting it. I'll be checking in this shortly, but we're in a freeze right now so it may take a little while. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: geom-ata forever cycle
Sat, Nov 22, 2003 at 05:45:09, nickh wrote about Re: geom-ata forever cycle: Personally I dont think this is GEOM related. I had a drive start doing Yes, it is ATAng related, AFAIS, but triggers GEOM forever cycle. this to me (happens often as I work in a large datacenter) and the drive is about to die. What brand drive is it and how old is it? You may waanna look into replacing the drive if you have that option. I had one tonight that did that to me, swap the drive, fixed. System has IBM DJNA-351520 and IBM IC35L040AVER07. They are alive and good. All other systems, including Win98, RedHat 8.0, FreeBSD 4.9 and FreeBSD-5.1 of May 2003, works well with these drivers. Hence, only fresh -current is broken. Full dmesg.boot of oldest -current follows. Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-BETA-20030523 #2: Sun May 25 00:28:30 EEST 2003 root@:/var/obj/var/HEAD/src/sys/nn15 Preloaded elf kernel /boot/kernel/kernel at 0xc044c000. Preloaded elf module /boot/modules/if_rl.ko at 0xc044c1f4. Preloaded elf module /boot/modules/miibus.ko at 0xc044c2a0. Calibrating clock(s) ... i8254 clock: 1193010 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 799435869 Hz Timecounter TSC frequency 799435869 Hz CPU: Intel Celeron (799.44-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268369920 (255 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00473000 - 0x0fb31fff, 258732032 bytes (63167 pages) avail memory = 255709184 (243 MB) bios32: Found BIOS32 Service Directory header at 0xc00fad00 bios32: Entry = 0xfb190 (c00fb190) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb1c0 pnpbios: Found PnP BIOS data at 0xc00fbbb0 pnpbios: Entry = f:bbe0 Rev = 1.0 Other BIOS signatures found: null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 00 01 80 00 05 02 07 01 00 01 1a 01 00 01 23 01 00 01 00 01 01 01 02 01 03 01 04 01 05 01 06 01 07 01 08 01 09 01 0a 01 0b 01 0c 01 0e 01 0f 01 VESA: 33 mode(s) found VESA: v3.0, 8192k memory, flags:0x1, mode table:0xc03ac7c2 (122) VESA: NVidia VESA: NVidia Corporation Riva TNT Chip Rev B1 npx0: math processor on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=11308086) pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00fded0 PCI-Only Interrupts: 5 9 11 Location Bus Device Pin Link IRQs slot 1 02A 0x60 3 4 5 7 9 10 11 14 15 slot 1 02B 0x61 3 4 5 7 9 10 11 14 15 slot 1 02C 0x62 3 4 5 7 9 10 11 14 15 slot 1 02D 0x63 3 4 5 7 9 10 11 14 15 slot 2 28A 0x68 3 4 5 7 9 10 11 14 15 slot 2 28B 0x69 3 4 5 7 9 10 11 14 15 slot 2 28C 0x6a 3 4 5 7 9 10 11 14 15 slot 2 28D 0x6b 3 4 5 7 9 10 11 14 15 slot 3 20A 0x60 3 4 5 7 9 10 11 14 15 slot 3 20B 0x61 3 4 5 7 9 10 11 14 15 slot 3 20C 0x62 3 4 5 7 9 10 11 14 15 slot 3 20D 0x63 3 4 5 7 9 10 11 14 15 slot 4 21A 0x61 3 4 5 7 9 10 11 14 15 slot 4 21B 0x62 3 4 5 7 9 10 11 14 15 slot 4 21C 0x63 3 4 5 7 9 10 11 14 15 slot 4 21D 0x60 3 4 5 7 9 10 11 14 15 slot 5 26A 0x62 3 4 5 7 9 10 11 14 15 slot 5 26B 0x63 3 4 5 7 9 10 11 14 15 slot 5 26C 0x60 3 4 5 7 9 10 11 14 15 slot 5 26D 0x61 3 4 5 7 9 10 11 14 15 slot 6 27A 0x63 3 4 5 7 9 10 11 14 15 slot 6 27B 0x60 3 4 5 7 9 10 11 14 15 slot 6 27C 0x61 3 4 5 7 9 10 11 14 15 slot 6 27D 0x62 3 4 5 7 9 10 11 14 15 slot 7 29A 0x61 3 4 5 7 9 10 11 14 15 slot 7 29B 0x62 3 4 5 7 9 10 11 14 15 slot 7 29C 0x63 3 4 5 7 9 10 11 14 15 slot 7 29D 0x60 3 4 5 7 9 10 11 14 15 slot 8 2 10A 0x62 3 4 5 7 9 10 11 14 15 slot 8 2 10B 0x63 3 4 5 7 9 10 11 14 15 slot 8 2 10C 0x60 3 4 5 7 9 10 11 14 15 slot 8 2 10D 0x61 3 4 5 7 9 10 11 14 15 embedded0 31A 0x60 3 4 5 7 9 10 11 14 15 embedded0 31B 0x61 3 4 5 7 9 10 11 14 15 embedded0 31C 0x6b 3 4 5 7 9 10 11 14 15 embedded0 31D 0x63 3 4 5 7 9 10 11 14 15 embedded01A
Re: Fatal error 'Spinlock called when not threaded' when trying toupgrade kdelibs-3.1.4 port
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 O ../dcop/dcopidl/dcopidl ./ksycoca.h ksycoca.kidl || ( rm -f ksycoca.kidl ; false ) Fatal error 'Spinlock called when not threaded.' at line 88 in file /usr/src/lib/libpthread/thread/thr_spinlock.c (errno = 0) Abort trap (core dumped) Something on your system is hosed. I just built all of KDE 3.1.4 on my current system with /etc/libmap.conf pointed at libkse; no problems at all. I used to get this before KDE was modified to use REINPLACE to set $PTHREAD_LIBS. I was setting it to kse but something was causing KDE to link against kse and libc_r. Without libmap.conf pointing libc_r to libkse I would get that error. - -- Jonathan Fosburgh AIX/SAN Administrator UT MD Anderson Cancer Center Houston, TX Home Page: http://www.fosburgh.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD4DBQE/v3OiqUvQmqp7omYRAqpkAJ9M/TmDCXkUElUl+w90tyRPR2wS6gCWNDHn zHVVK3QnecDmiSRKOU5MsQ== =7fCb -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: geom-ata forever cycle
heh. IBM? It's bad. All of the ones that I had (also running -current from within 24 hours) that were spitting that were bad (All were POS IBMs too!). Just my guess, however. Regards, Nick H. Network Operations Center [EMAIL PROTECTED] Please rate my performance! http://www.supportteam.net/rate.php3 Please submit all new support requests to http://ticketmonster.hostingsupport.com/ --- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. - Original Message - From: Valentin Nechayev [EMAIL PROTECTED] To: Nick H. -- Network Operations [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, November 22, 2003 8:21 AM Subject: Re: geom-ata forever cycle Sat, Nov 22, 2003 at 05:45:09, nickh wrote about Re: geom-ata forever cycle: Personally I dont think this is GEOM related. I had a drive start doing Yes, it is ATAng related, AFAIS, but triggers GEOM forever cycle. this to me (happens often as I work in a large datacenter) and the drive is about to die. What brand drive is it and how old is it? You may waanna look into replacing the drive if you have that option. I had one tonight that did that to me, swap the drive, fixed. System has IBM DJNA-351520 and IBM IC35L040AVER07. They are alive and good. All other systems, including Win98, RedHat 8.0, FreeBSD 4.9 and FreeBSD-5.1 of May 2003, works well with these drivers. Hence, only fresh -current is broken. Full dmesg.boot of oldest -current follows. Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-BETA-20030523 #2: Sun May 25 00:28:30 EEST 2003 root@:/var/obj/var/HEAD/src/sys/nn15 Preloaded elf kernel /boot/kernel/kernel at 0xc044c000. Preloaded elf module /boot/modules/if_rl.ko at 0xc044c1f4. Preloaded elf module /boot/modules/miibus.ko at 0xc044c2a0. Calibrating clock(s) ... i8254 clock: 1193010 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 799435869 Hz Timecounter TSC frequency 799435869 Hz CPU: Intel Celeron (799.44-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV, PAT,PSE36,MMX,FXSR,SSE real memory = 268369920 (255 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00473000 - 0x0fb31fff, 258732032 bytes (63167 pages) avail memory = 255709184 (243 MB) bios32: Found BIOS32 Service Directory header at 0xc00fad00 bios32: Entry = 0xfb190 (c00fb190) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb1c0 pnpbios: Found PnP BIOS data at 0xc00fbbb0 pnpbios: Entry = f:bbe0 Rev = 1.0 Other BIOS signatures found: null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 00 01 80 00 05 02 07 01 00 01 1a 01 00 01 23 01 00 01 00 01 01 01 02 01 03 01 04 01 05 01 06 01 07 01 08 01 09 01 0a 01 0b 01 0c 01 0e 01 0f 01 VESA: 33 mode(s) found VESA: v3.0, 8192k memory, flags:0x1, mode table:0xc03ac7c2 (122) VESA: NVidia VESA: NVidia Corporation Riva TNT Chip Rev B1 npx0: math processor on motherboard npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=11308086) pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00fded0 PCI-Only Interrupts: 5 9 11 Location Bus Device Pin Link IRQs slot 1 02A 0x60 3 4 5 7 9 10 11 14 15 slot 1 02B 0x61 3 4 5 7 9 10 11 14 15 slot 1 02C 0x62 3 4 5 7 9 10 11 14 15 slot 1 02D 0x63 3 4 5 7 9 10 11 14 15 slot 2 28A 0x68 3 4 5 7 9 10 11 14 15 slot 2 28B 0x69 3 4 5 7 9 10 11 14 15 slot 2 28C 0x6a 3 4 5 7 9 10 11 14 15 slot 2 28D 0x6b 3 4 5 7 9 10 11 14 15 slot 3 20A 0x60 3 4 5 7 9 10 11 14 15 slot 3 20B 0x61 3 4 5 7 9 10 11 14 15 slot 3 20C 0x62 3 4 5 7 9 10 11 14 15 slot 3 20D 0x63 3 4 5 7 9 10 11 14
What's changed relating to localhost then?
I've just updated to 5.2-BETA today and have noticed that my spamd is now rejecting all connections from spamc because they are not coming from 127.0.0.1 any more. It's now using my public IP address of 82.x.x.x: Nov 22 14:38:30 womble spamd[657]: unauthorized connection from 82-32-25-111.cable.ubr04.azte.blueyonder.co.uk [82.32.25.111] at port 49167 I noticed somebody reported a similar thing earlier. I'm actually in the process of reverting to a -current of 2003.11.14.00.00.00 because my xl0 ethernet card is acting up as mentioned in another thread so I want to see if it works with that kernel. (Can't go further back due to statfs). Also one of my machines running 5.2-BETA just hung dead within 5 minutes of booting. I don't have DDB etc configured though so can't tell why. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's changed relating to localhost then?
I've just updated to 5.2-BETA today and have noticed that my spamd is now rejecting all connections from spamc because they are not coming from 127.0.0.1 any more. It's now using my public IP address of 82.x.x.x: Nov 22 14:38:30 womble spamd[657]: unauthorized connection from 82-32-25-111.cable.ubr04.azte.blueyonder.co.uk [82.32.25.111] at port 49167 I noticed somebody reported a similar thing earlier. It was me, I'm glad not to be dumb. I note also that metacity takes ages to start. I'm waiting a new change to network code in order to compile another -CURRENT. I'm actually in the process of reverting to a -current of 2003.11.14.00.00.00 because my xl0 ethernet card is acting up as mentioned in another thread so I want to see if it works with that kernel. (Can't go further back due to statfs). Also one of my machines running 5.2-BETA just hung dead within 5 minutes of booting. I don't have DDB etc configured though so can't tell why. Matt. ___ [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: What's changed relating to localhost then?
I noticed the same thing yesterday when postgresql stopped working properly because there wasn't an entry for my public IP in the pg_hba.conf file. If you telnet to 127.0.0.1 the system still believes you are coming from your public IP. Bizarre that. Other IPs don't act that way. My system has two public IPs and 127.0.0.1. If I telnet to myself on either of the public IPs then I appear from the correct IP. However 127.0.0.1 no longer seems to work that way and that does break a number of things that expect to be connected to by 127.0.0.1 -Steve On Sat, Nov 22, 2003 at 02:46:54PM +, Matt Smith wrote: I've just updated to 5.2-BETA today and have noticed that my spamd is now rejecting all connections from spamc because they are not coming from 127.0.0.1 any more. It's now using my public IP address of 82.x.x.x: Nov 22 14:38:30 womble spamd[657]: unauthorized connection from 82-32-25-111.cable.ubr04.azte.blueyonder.co.uk [82.32.25.111] at port 49167 I noticed somebody reported a similar thing earlier. I'm actually in the process of reverting to a -current of 2003.11.14.00.00.00 because my xl0 ethernet card is acting up as mentioned in another thread so I want to see if it works with that kernel. (Can't go further back due to statfs). Also one of my machines running 5.2-BETA just hung dead within 5 minutes of booting. I don't have DDB etc configured though so can't tell why. Matt. ___ [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: How to fix this in 5.1-REL??
/usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such= file or directory mkdep: compile failed *** Error code 1 =20 Stop in /usr/src/gnu/lib/libstdc++. *** Error code 1 I'm running 5.1-CURRENT now, but I was able to build 5.1-RELEASE-p10. I suspect you need to re-cvsup your sources, which I've had to do several times. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On 2003-11-22 at 00:39:45 Tim Kientzle wrote: Right now, /sbin/init is statically linked. Not here... I've built everything with WITH_DYNAMICROOT since the time the option was introduced, and as such: # file /sbin/init /sbin/init: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 5.0.1, dynamically linked (uses shared libs), stripped # ldd /sbin/init /sbin/init: libutil.so.3 = /lib/libutil.so.3 (0x28074000) libcrypt.so.2 = /lib/libcrypt.so.2 (0x2807f000) libc.so.5 = /lib/libc.so.5 (0x28097000) In fact, the only statically linked executable I can currently find in my base system (= -CURRENT as of 2003-11-11) is /sbin/devd... pgp0.pgp Description: PGP signature
Re: How to make a USB wireless adapter device work in FreeBSD (DWL-120)?
Am 21.11.2003 um 03:37 schrieb ALeXiS AsTeRX: I'm quite new to FreeBSD, and I would like to know how to make a D-Link (DWL-120) USB wireless adapter work in FreeBSD, or at least whether there is any driver supporting that, or something in development currently.. product ATMEL UHB1240x3301 UHB124 hub product ATMEL DWL1200x7602 DWL-120 Wireless adapter Daan Vreeken and Stuart Walsh have been working on porting the Linux driver; see the archives and Google. You might need to ask Stuart for his latest set of patches. Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
Garrett Wollman wrote: You forgot: * Allow statically-linked programs to use dynamic NSS modules by forking a (dynamically-linked) resolver process when needed. This leads to a related, but widely disparaged option: * Have a persistent NSS caching daemon with an RPC interface that all programs can access for NSS lookups. You might call such a program `nscd'. (Might as well be honest about it.) Both of these options may incidentally help to resolve threading issues in the C library (although that would not be the preferred way of doing so). Regardless of how NSS is implemented, it will be useful to have some type of caching (even if optional). On a large system, you can beat the hell out of your LDAP server otherwise. Of course, you can use a local replica of your LDAP server. But that doesn't help if are using a different database like Postgres as the backend for your nss/pam setup. But if a nscd (or equivalent) is added to FreeBSD, we need to do a better job than the Linux nscd. We had real problems with the Linux nscd in a previous project. If I remember, it assumes that the mapping between username - uid was 1-1. We added an attribute to our LDAP schema so we could specify the reverse mapping in situations where more than one username mapped to the same uid. But we could never get it to work correctly, since Linux nscd made some assumption that were difficult to change. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
On Sat, Nov 22, 2003 at 08:08:29AM -0500, Brian F. Feldman wrote: We never did any page crossing on ohci/ehci bevor the newbus change took place. Found it!!! Definitely a problem created then... --- ohci.c 12 Nov 2003 01:40:11 - 1.138 +++ ohci.c 22 Nov 2003 03:28:42 - @@ -569,7 +569,7 @@ cur-td.td_cbp = htole32(dataphys); cur-nexttd = next; cur-td.td_nexttd = htole32(next-physaddr); - cur-td.td_be = htole32(DMAADDR(dma, curlen - 1)); + cur-td.td_be = htole32(DMAADDR(dma, offset + curlen - 1)); cur-len = curlen; cur-flags = OHCI_ADD_LEN; cur-xfer = xfer; I'm a lot happier now :-) Let's start trying to get this stuff merged in! Cool as!!! Good call. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = pgp0.pgp Description: PGP signature
Re: Unfortunate dynamic linking for everything
* Tim Kientzle [EMAIL PROTECTED] [031121 18:40]: Leo Bicknell wrote: To boot a machine into single user mode you need a kernel, init, and /bin/sh (minimally). It would seem to me that alone is a good argument for those three things to be static. * Rewrite dlopen() to not require dynamic linking. There were some patches for this submitted at one point. As I recall, the people who looked at them were not entirely comfortable with them. (I'd be concerned about version conflict problems with this approach: what happens when a dynamically-loaded NSS module refers to a libc function? Does that get resolved to the already statically-linked version? Or does another copy of libc get dynamically linked with potential version conflicts? Does anyone know?) I personally think this is worth researching, though I have my doubts. I took a look at the glibc implementation of dlopen() breifly, since that does function from within libc.a. It appears that you *do* get more than one loaded copy of libc. The copy of dlopen() that is built when #ifndef SHARED includes a flag: __libc_multiple_libcs that is set to 1. Additionally, I was reading comments from some of the glibc developers who basically claim that dlopen() in a static binary *only* works if you dlopen() a NSS module. It isn't guaranteed to work in the general case because the static binary has no DYNAMIC elf section to resolve external references etc. I suspect this means NSS modules are limited in what they are allowed to reference and still work? I haven't looked in much detail on their implementation but it certainly looks like a hack just to make NSS work, which I don't think is a good long-term solution. --Mike pgp0.pgp Description: PGP signature
Re: dumb question 'Bad system call' after make world
On Sat, Nov 22, 2003 at 11:42:04PM +1100, Bruce Evans wrote: On Fri, 21 Nov 2003, Barney Wolff wrote: Will somebody please tell me when make world is ever correct in the environment of the last several years? I've been unable to understand its continued existence as a target. From my normal world-building script: DESTDIR=/c/z/root \ MAKEOBJDIRPREFIX=/c/z/obj \ time -l make -s world /tmp/world.out 21 Oh, so it's only correct when you're not really installing world on the system you're building on? Would replacing this with ( make buildworld make installworld ) really be a hardship? Must we continue to invite innocents to clobber their systems? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's changed relating to localhost then?
Matt Smith wrote: I've just updated to 5.2-BETA today and have noticed that my spamd is now rejecting all connections from spamc because they are not coming from 127.0.0.1 any more. It's now using my public IP address of 82.x.x.x: Yes, same problem here: at first, amavis refused to accept mails from postfix and when I started to try to fix it (without having enough black coffee inside) I got postfix to bounce all undelivered mail (~100-200 mails lost). :-/ I got amavis+postfix working again, but they still don't use the loopback interface. It would be nice if someone could help me to understand the reason for this. :) thanks, Uwe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's changed relating to localhost then?
Steve Ames [EMAIL PROTECTED] writes: If you telnet to 127.0.0.1 the system still believes you are coming from your public IP. Bizarre that. Other IPs don't act that way. My system has two public IPs and 127.0.0.1. If I telnet to myself on either of the public IPs then I appear from the correct IP. However 127.0.0.1 no longer seems to work that way and that does break a number of things that expect to be connected to by 127.0.0.1 I can confirm this behaviour. It is possible to force the local address to 127.0.0.1 though. [EMAIL PROTECTED] ~]$ telnet 127.0.0.1 25 [19:39] Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 borg.borderworlds.dk ESMTP Postfix Nov 22 19:39:44 borg postfix/smtpd[2683]: connect from borg.borderworlds.dk[10.1.0.2] [EMAIL PROTECTED] ~]$ telnet -s 127.0.0.1 127.0.0.1 25 [19:40] Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 borg.borderworlds.dk ESMTP Postfix Nov 22 19:40:06 borg postfix/smtpd[2683]: connect from localhost[127.0.0.1] Fortunately this behaviour didn't break anything here, but it does seem broken nonetheless. I updated my machine earlier today and got 5.2-BETA: FreeBSD borg.borderworlds.dk 5.2-BETA FreeBSD 5.2-BETA #3: Sat Nov 22 13:25:47 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BORG i386 -- Best regards Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
In message: [EMAIL PROTECTED] Bruce M Simpson [EMAIL PROTECTED] writes: : On Thu, Nov 20, 2003 at 04:31:10PM -0800, Tim Kientzle wrote: : * /rescue/vi is currently unusable if /usr is missing because : the termcap database is in /usr. One possibility : would be to build a couple of default termcap entries : into ncurses or into vi. : : My suggested candidates are vt100 and cons25. The comconsole port installs : an /etc/ttys entry using vt100. This is also the default terminal type for : most dialup entries. Timing Solutions uses the following minimal termcap for its embedded applications. It has a number of terminals that it supports, while still being tiny. it is 3.5k in size, which was the goal ( 4k block size we were using). One could SED this down by another 140 bytes or so. Removing the comments and the verbose names would net another 300 odd bytes. The terminals supported are vt220, vt102, vt100, xterm, xterms, cons25w, cons25 and ansi. This seems a reasonable number: neither too few, nor too many. It lets people connect 'normal' terminals to the serial port (most PCs have vt100/vt220 emulation), as well as PC to PC connection on the console or xterm. I'd be happy to commit this as /etc/termcap.tiny. vi could then look for both termcap and termcap.tiny and things would just work. Comments? Warner vt200|vt220|vt220am|vt200am|dec-vt220|dec-vt200|dec vt200 series with jump scroll:\ :@7=\E[4~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kh=\E[1~:\ :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:\ :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\ :ve=\E[?25h:vi=\E[?25l:k0@:im@:ei@:\ :F1=\E[23~:F2=\E[24~:ic=\E[@:IC=\E[%d@:ec=\E[%dX:tc=vt102: vt100|dec-vt100|vt100-am|vt100am|dec vt100:\ :do=2\E[B:co#80:li#24:cl=50\E[H\E[J:sf=2*\ED:\ :le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\ :ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\ :md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:\ :is=\E\E[?1;3;4;5l\E[?7;8h\E[1;24r\E[24;1H:\ :if=/usr/share/tabset/vt100:nw=2\EE:ho=\E[H:\ :as=2\E(0:ae=2\E(B:ac=llmmkkjjuuttvvwwqqxxnnpprr``aa:\ :rs=\E\E[?1;3;4;5l\E[?7;8h:ks=\E[?1h\E=:ke=\E[?1l\E:\ :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=\177:\ :k0=\EOy:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\EOt:\ :k6=\EOu:k7=\EOv:k8=\EOl:k9=\EOw:k;=\EOx:@8=\EOM:\ :K1=\EOq:K2=\EOr:K3=\EOs:K4=\EOp:K5=\EOn:pt:sr=2*\EM:vt#3:xn:\ :sc=2\E7:rc=2\E8:cs=5\E[%i%d;%dr:UP=2\E[%dA:DO=2\E[%dB:RI=2\E[%dC:\ :LE=2\E[%dD:ct=2\E[3g:st=2\EH:ta=^I:ms:bl=^G:cr=^M:eo:it#8:ut:\ :RA=\E[?7l:SA=\E[?7h: vt102|dec-vt102-am|vt102am|vt100 w/adv. video:\ :al=\E[L:dl=\E[M:im=\E[4h:ei=\E[4l:mi:dc=\E[P:\ :AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:tc=vt100-np: vt100-np|dec-vt100-np|vt100 with no padding (for psl games):\ :do=\E[B:cl=\E[H\E[J:sf=\ED:as=\E(0:ae=\E(B:\ :cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:nw=\EE:\ :ce=\E[K:cd=\E[J:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:\ :md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:sr=\EM:\ :sc=\E7:rc=\E8:cs=\E[%i%d;%dr:UP=\E[%dA:DO=\E[%dB:RI=\E[%dC:\ :LE=\E[%dD:ct=\E[3g:st=\EH:tc=vt100-am: xterm|vs100|xterm terminal emulator (X window system):\ :li#65:\ :kh=\EOH:@7=\EOF:kb=^H:kD=^?:\ :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:km:\ :is=\E\E[?1;3;4;5l\E[?7;8h\E[1;65r\E[65;1H:\ :rs=\E\E[?1;3;4;5l\E[?7;8h:\ :tc=vt220: xterms|vs100s|xterm terminal emulator (small)(X window system):\ :is=\E\E[?1;3;4;5l\E[?7;8h\E[1;24r\E[24;1H:\ :li#24:tc=xterm: # for syscons # common entry without semigraphics cons25w|ansiw|ansi80x25-raw:\ :al=\E[L:am:bs:NP:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:co#80:\ :dc=\E[P:dl=\E[M:do=\E[B:bt=\E[Z:ho=\E[H:ic=\E[@:li#25:cb=\E[1K:\ :ms:nd=\E[C:pt:rs=\E[x\E[m\Ec:so=\E[7m:se=\E[m:up=\E[A:\ :pa#64:Co#8:AF=\E[3%dm:AB=\E[4%dm:op=\E[x:sc=\E7:rc=\E8:\ :k1=\E[M:k2=\E[N:k3=\E[O:k4=\E[P:k5=\E[Q:k6=\E[R:k7=\E[S:k8=\E[T:\ :k9=\E[U:k;=\E[V:F1=\E[W:F2=\E[X:K2=\E[E:nw=\E[E:ec=\E[%dX:\ :kb=^H:kh=\E[H:ku=\E[A:kd=\E[B:kl=\E[D:kr=\E[C:le=^H:eo:sf=\E[S:sr=\E[T:\ :kN=\E[G:kP=\E[I:@7=\E[F:kI=\E[L:kD=\177:kB=\E[Z:\ :IC=\E[%d@:DC=\E[%dP:SF=\E[%dS:SR=\E[%dT:AL=\E[%dL:DL=\E[%dM:\ :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:cv=\E[%i%dd:ch=\E[%i%d`:bw:\ :mb=\E[5m:md=\E[1m:mh=\E[30;1m:mr=\E[7m:me=\E[m:bl=^G:ut:it#8:km: cons25|ansis|ansi80x25:\ :ac=l\332m\300k\277j\331u\264t\303v\301w\302q\304x\263n\305`^Da\260f\370g\361~\371.^Y-^Xh\261I^U0\333y\363z\362:\ :tc=cons25w: dosansi|ANSI.SYS standard crt:\ :am:bs:ce=\E[K:cl=\E[2J:cm=\E[%i%d;%dH:co#80:\ :do=\E[B:li#25:mi:nd=\E[C:\ :se=\E[m:so=\E[7m:up=\E[A:us=\E[4m:ue=\E[m:\ :md=\E[1m:mh=\E[m:mb=\E[5m:me=\E[m:\ :kh=\EG:kb=^h:ku=\EH:kd=\EP:kl=\EK:kr=\EM:\ :k1=\E;:k2=\E:k3=\E=:k4=\E:k5=\E?:\
RE: dumb question 'Bad system call' after make world
From: Barney Wolff [mailto:[EMAIL PROTECTED] Sent: Saturday, November 22, 2003 1:14 PM To: Bruce Evans Cc: [EMAIL PROTECTED] Subject: Re: dumb question 'Bad system call' after make world On Sat, Nov 22, 2003 at 11:42:04PM +1100, Bruce Evans wrote: On Fri, 21 Nov 2003, Barney Wolff wrote: Will somebody please tell me when make world is ever correct in the environment of the last several years? I've been unable to understand its continued existence as a target. From my normal world-building script: DESTDIR=/c/z/root \ MAKEOBJDIRPREFIX=/c/z/obj \ time -l make -s world /tmp/world.out 21 Oh, so it's only correct when you're not really installing world on the system you're building on? Would replacing this with ( make buildworld make installworld ) really be a hardship? Must we continue to invite innocents to clobber their systems? For interest, in case this happens to someone else, i 'fixed' it by booting from the mini iso disk, inserting disk 2 (live), going to a shell, and copying all of /bin, /usr/bin, /usr/lib, /usr/libexec, /lib over to the hd, rebooting, and then doing the rest of the normal steps. --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fatal error 'Spinlock called when not threaded' when trying toupgrade kdelibs-3.1.4 port
On Sat, 22 Nov 2003, Jonathan E Fosburgh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 O ../dcop/dcopidl/dcopidl ./ksycoca.h ksycoca.kidl || ( rm -f ksycoca.kidl ; false ) Fatal error 'Spinlock called when not threaded.' at line 88 in file /usr/src/lib/libpthread/thread/thr_spinlock.c (errno = 0) Abort trap (core dumped) Something on your system is hosed. I just built all of KDE 3.1.4 on my current system with /etc/libmap.conf pointed at libkse; no problems at all. I used to get this before KDE was modified to use REINPLACE to set $PTHREAD_LIBS. I was setting it to kse but something was causing KDE to link against kse and libc_r. Without libmap.conf pointing libc_r to libkse I would get that error. Right, in general, you can't build with PTHREAD_LIBS set to anything other than default (-lc_r). There are patches in the PR system to make KDE build cleanly when PTHREAD_LIBS is set to -lkse, but even when applied, there are other ports that will still have problems. In short, unless you know what you are doing or want to help make ports honor PTHREAD_LIBS, do not touch PTHREAD_LIBS. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: What's changed relating to localhost then?
From: Christian Laursen [mailto:[EMAIL PROTECTED] Steve Ames [EMAIL PROTECTED] writes: If you telnet to 127.0.0.1 the system still believes you are coming from your public IP. Bizarre that. Other IPs don't act that way. My system has two public IPs and 127.0.0.1. If I telnet to myself on either of the public IPs then I appear from the correct IP. However 127.0.0.1 no longer seems to work that way and that does break a number of things that expect to be connected to by 127.0.0.1 I can confirm this behaviour. It is possible to force the local address to 127.0.0.1 though. [EMAIL PROTECTED] ~]$ telnet 127.0.0.1 25 [19:39] Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 borg.borderworlds.dk ESMTP Postfix Nov 22 19:39:44 borg postfix/smtpd[2683]: connect from borg.borderworlds.dk[10.1.0.2] [EMAIL PROTECTED] ~]$ telnet -s 127.0.0.1 127.0.0.1 25 [19:40] Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 borg.borderworlds.dk ESMTP Postfix Nov 22 19:40:06 borg postfix/smtpd[2683]: connect from localhost[127.0.0.1] Fortunately this behaviour didn't break anything here, but it does seem broken nonetheless. This seems to break amd: amd[751]: Map support for: root, passwd, hesiod, union, nis, ndbm, file, error. amd[751]: AMFS: nfs, link, nfsx, nfsl, host, linkx, program, union, inherit, ufs, amd[751]: cdfs, pcfs, auto, direct, toplvl, error. amd[751]: FS: cd9660, nfs, nfs3, msdosfs, ufs, unionfs. amd[751]: Network 1: wire=10.128.2.0 (netnumber=10.128.2). amd[751]: Network 2: wire=192.168.3.0 (netnumber=192.168.3). amd[751]: My ip addr is 127.0.0.1 amd[752]: released controlling tty using setsid() amd[752]: file server localhost, type local, state starts up amd[753]: /phaedrus: disabling nfs congestion window amd[752]: ignoring request from 10.128.2.57:1018, expected 127.0.0.1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
serial console, inappropriate ioctl?
I have a current system configured to use a serial console. I'm getting a 'login_tty /dev/console: Inappropriate ioctl for device' to the console every few seconds. bash-2.05b# cat /boot.config -Dh In /etc/ttys, i have set console as: console /usr/libexec/getty std.115200 vt100 on secure and also have: ttyd0 /usr/libexec/getty std.115200 vt100 on secure in the /boot/device.hints, i have: hint.sio.0.flags=0x30 bash-2.05b# uname -a FreeBSD bsd7.phaedrus.sandvine.com 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Sat Nov 22 16:39:04 EST 2003 [EMAIL PROTECTED]:/d2/obj/d2/src/sys/GENERIC i386 Nov 22 18:03:16 bsd7 getty[940]: login_tty /dev/console: Inappropriate ioctl for device Nov 22 18:03:16 bsd7 init: getty repeating too quickly on port /dev/console, sleeping 30 secs Any suggestions on what this might be coming from? --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI and APM testing on Dell Inspiron 8200
I'm having difficulty getting battery and thermal status. If I compile the kernel with APM support I get battery statistics but if I try to put APM/ACPI in the kernel ACPI reports that another PM system is enabled and doesn't load the /dev/acpi device. If I take APM out and compile in ACPI I get /dev/acpi and all that goes with it; but the battery status does not show up correctly. I've attached 2 files, test1.log which is with: device acpi device apm in the kernel. (Which brings me to the point, in the NOTES file it's noted that device acpi is deprecated, but if you don't add the device you don't get acpi support...) Then test2.log is with only acpi support compiled in. Another thing I tested while I was testing was suspend states. With apm compiled in I tried doing a 'apm -z'. Suspending seems to work fine, however, when you try to bring it back it says it is resyncing the disks (think this was the last message) and then it sits there frozen; meanwhile the harddrive light is constantly on. I let it sit there for a minute and still had no signs of activity. If I go into X suspend works with the only hitch that the screen goes all white before it blacks out and upon unsuspending the screen is still all white with traces of colors of the background. Then with ACPI compiled in I tried dropping it to S1 with 'acpiinfo -s 1'. Again it seems to drop into the state just fine, however the LCD does not black out upon suspending. But the power light starts flashing like it should. Then when you hit the power button the screen blanks out. However, otherwise it unsuspends, I was able to sucessfully Ssh into the machine. I don't know if it's related but changing the hw.acpi.reset_video to 0 made no difference. Also to note, with X running S1 works fine with the exception that when it is suspended the display does not turn off, but when you come out of S1 the display goes back into X. I was able to sucessfully suspend it and bring it back using the lidswitch too, with same exceptions. S3, S4 and S5 all result in the computer rebooting though. Processor is P4m. Video card is ATI Radeon 9k mobility. If you need any other information please feel free to contact me. -- Ryan leadZERO Sommers Gamer's Impact President [EMAIL PROTECTED] ICQ: 1019590 AIM/MSN: leadZERO -= http://www.gamersimpact.com =-Script started on Sat Nov 22 13:53:08 2003 lilshadow# dms[Keg[Ksg|[K | grep -i apm apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 WARNING: apm_saver module requires apm enabled lilshadow# dmesg | grep -i apm[K[K[Kacpi Preloaded acpi_dsdt /boot/acpi_dsdt.aml at 0xc07811cc. Features=0xbfebf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE ACPI: DSDT was overridden. ACPI-0375: *** Info: Table [DSDT] replaced by host OS acpi0: Other PM system enabled. lilshadow# apm APM version: 1.2 APM Management: Enabled AC Line status: on-line Battery status: charging Remaining battery life: 100% Remaining battery time: 2:34:00 Number of batteries: 2 Battery 0: Battery status: not present Battery 1: Battery status: charging Remaining battery life: 100% Remaining battery time: 2:34:00 Resume timer: disabled Resume on ring indicator: disabled APM Capabilities: global suspend state resume timer from suspend lilshadow# acpiinfo[K[K[K[Kconf -i 0 acpiconf: /dev/acpi: No such file or directory lilshadow# acpiconf -i 0[K1 acpiconf: /dev/acpi: No such file or directory lilshadow# exit exit Script done on Sat Nov 22 13:53:50 2003 Script started on Sat Nov 22 14:11:19 2003 lilshadow# dmesg | grep -i apm lilshadow# dmesg | grep -i apm[K[K[Kaci[Kpi Preloaded acpi_dsdt /boot/acpi_dsdt.aml at 0xc077e1cc. Features=0xbfebf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE ACPI: DSDT was overridden. ACPI-0375: *** Info: Table [DSDT] replaced by host OS acpi0: DELL CPi R on motherboard Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: Thermal Zone on acpi0 acpi_acad0: AC Adapter on acpi0 acpi_cmbat0: Control Method Battery on acpi0 acpi_cmbat1: Control Method Battery on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 ppc0 port
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Fri, Nov 21, 2003 at 03:33:51PM -0600, Guy Helmer wrote: Tim Kientzle wrote: Guy Helmer wrote: Thanks to /rescue and the live filesystem archives on current.freebsd.org, I was able to recover a machine that I hosed after the statfs change by trying to installworld without building booting a new kernel first. Great! Any changes you could suggest to /rescue based on that experience? Sure -- I could have used the ftp client (or fetch) in /rescue :-) (/me ducks) You wouldn't have had it pre-dynamic /: fetch is /usr/bin/fetch ftp is /usr/bin/ftp ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Fri, Nov 21, 2003 at 02:11:30PM -0800, Tim Kientzle wrote: Thanks to /rescue and the live filesystem archives on current.freebsd.org, I was able to recover ... I could have used the ftp client (or fetch) in /rescue :-) Yes, fetch would be useful. I imagine a lot of people in emergency situations will need to pull things over a network connection. Looks like it would only add about 65k (20k for fetch, another 45k for libfetch which isn't already in the crunched /rescue binary). Submit a PR on this Please, NO. There wasn't an FTP client available for this type of recovery pre-/rescue, there shouldn't be one now. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI and APM testing on Dell Inspiron 8200
On Sat, 22 Nov 2003, Ryan Sommers wrote: I'm having difficulty getting battery and thermal status. If I compile the kernel with APM support I get battery statistics but if I try to put APM/ACPI in the kernel ACPI reports that another PM system is enabled and doesn't load the /dev/acpi device. Yes, you can have either ACPI or APM, but not both at the same time. If I take APM out and compile in ACPI I get /dev/acpi and all that goes with it; but the battery status does not show up correctly. The log you have posted shows that you're running on AC, that's why battery time is 0. Plus, you somehow made it to fill up the battery to 118%. :-) The log also shows that you're loading a customized DSDT at boot, maybe that is borked. (Which brings me to the point, in the NOTES file it's noted that device acpi is deprecated, but if you don't add the device you don't get acpi support...) Yes, this info is currently out-of-date. There were some recent changes to the interrupt code that made it necessary to compile acpi into the kernel. I'm not sure if someone already works on making it a module again. Generally, you should use acpidump(8) to dump your ACPI tables and ASL, put it on a website and post a link to it here. Maybe someone can take a look at it then. 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: HEADS UP: /bin and /sbin are now dynamically linked
At 5:22 PM -0800 2003/11/22, David O'Brien wrote: Please, NO. There wasn't an FTP client available for this type of recovery pre-/rescue, there shouldn't be one now. Why? Why cut your nose off to spite your face? Even though this capability may not have existed before, why shouldn't we have it now? -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
In message: [EMAIL PROTECTED] Bruce Evans [EMAIL PROTECTED] writes: : On Sat, 22 Nov 2003, M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : Bruce M Simpson [EMAIL PROTECTED] writes: : : On Thu, Nov 20, 2003 at 04:31:10PM -0800, Tim Kientzle wrote: : : * /rescue/vi is currently unusable if /usr is missing because : : the termcap database is in /usr. One possibility : : would be to build a couple of default termcap entries : : into ncurses or into vi. : : : : My suggested candidates are vt100 and cons25. The comconsole port installs : : an /etc/ttys entry using vt100. This is also the default terminal type for : : most dialup entries. : : Timing Solutions uses the following minimal termcap for its embedded : applications. It has a number of terminals that it supports, while : still being tiny. it is 3.5k in size, which was the goal ( 4k block : size we were using). One could SED this down by another 140 bytes or : so. Removing the comments and the verbose names would net another 300 : odd bytes. : : What's wrong with FreeBSD's /usr/src/etc/termcap.small, except it is : twice as large and has a weird selection of entries (zillions of : variants of cons25, dosansi and pc3). Mine is better because it has a more representative slice of currently used terminal types. Maybe we should replace termcap.small with mine (maybe with the copyright notice). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic when trying to mount cd9660 as udf
By accident, I tried to mount a CD as UDF, and got the follwoing panic:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc06c2f6c
stack pointer = 0x10:0xcda4bac0
frame pointer = 0x10:0xcda4bacc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 530 (mount_udf)
This seems to be easily reproducable. First I got it on my workstation
running 5.2-BETA, and I then reproduced it on my test machine which runs
-CURRENT from 4 days ago:
FreeBSD cardassian.borderworlds.dk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Nov 19
04:22:32 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
The output in this mail is from the test machine.
This is the backtrace I got from the resulting crashdump:
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc066d6fb in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc066dafd in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc048ac32 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc048ab92 in db_command (last_cmdp=0xc0938360, cmd_table=0xc08c3c00,
aux_cmd_tablep=0xc08baa04, aux_cmd_tablep_end=0xc08baa1c)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc048acd5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc048dcd5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc0812dcc in kdb_trap (type=12, code=0, regs=0xcda4ba80)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc08294d6 in trap_fatal (frame=0xcda4ba80, eva=0)
at /usr/src/sys/i386/i386/trap.c:816
#9 0xc0829182 in trap_pfault (frame=0xcda4ba80, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#10 0xc0828d23 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1040053552, tf_esi = 1, tf_ebp =
-844842292, tf_isp = -844842324, tf_ebx = 0, tf_edx = 4, tf_ecx = 1, tf_eax = 0,
tf_trapno = 12, tf_err = 0, tf_eip = -1066651796, tf_cs = 8, tf_eflags = 66182, tf_esp
= 6, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:420
#11 0xc0814818 in calltrap () at {standard input}:94
#12 0xc06c3913 in vfs_mount_destroy (mp=0x0, td=0x0)
at /usr/src/sys/kern/vfs_mount.c:537
#13 0xc06c472f in vfs_domount (td=0xc20c7dc0, fstype=0xc2020ad0 udf,
fspath=0xc2020ab0 /mnt, fsflags=1, fsdata=0xc2020c00, compat=0)
at /usr/src/sys/kern/vfs_mount.c:938
#14 0xc06c3a39 in vfs_nmount (td=0x0, fsflags=0, fsoptions=0x0)
at /usr/src/sys/kern/vfs_mount.c:581
#15 0xc06c353d in nmount (td=0x0, uap=0xcda4bd10)
at /usr/src/sys/kern/vfs_mount.c:407
#16 0xc0829870 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077940702, tf_esi = 8, tf_ebp =
-1077940972, tf_isp = -844841612, tf_ebx = 5, tf_edx = -1077940736, tf_ecx = 10,
tf_eax = 378, tf_trapno = 12, tf_err = 2, tf_eip = 671876783, tf_cs = 31, tf_eflags =
582, tf_esp = -1077942196, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1010
#17 0xc081486d in Xint0x80_syscall () at {standard input}:136
--
Best regards
Christian Laursen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sat, 22 Nov 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Bruce Evans [EMAIL PROTECTED] writes: : On Sat, 22 Nov 2003, M. Warner Losh wrote: : Timing Solutions uses the following minimal termcap for its embedded : applications. It has a number of terminals that it supports, while : still being tiny. it is 3.5k in size, which was the goal ( 4k block : size we were using). One could SED this down by another 140 bytes or : so. Removing the comments and the verbose names would net another 300 : odd bytes. : : What's wrong with FreeBSD's /usr/src/etc/termcap.small, except it is : twice as large and has a weird selection of entries (zillions of : variants of cons25, dosansi and pc3). Mine is better because it has a more representative slice of currently used terminal types. Maybe we should replace termcap.small with mine (maybe with the copyright notice). I agree. termcap.small is amazingly uncurrent. However, perhaps some merging and reducing is in order. Why is a full cons25 or vt2xx needed? vi only needs a few capabilities. I think we mostly use copies of large termcap entries because copying the whole things is easier. Bruce Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
In message: [EMAIL PROTECTED] Bruce Evans [EMAIL PROTECTED] writes: : Mine is better because it has a more representative slice of currently : used terminal types. Maybe we should replace termcap.small with mine : (maybe with the copyright notice). : : I agree. termcap.small is amazingly uncurrent. However, perhaps some : merging and reducing is in order. Why is a full cons25 or vt2xx needed? : vi only needs a few capabilities. I think we mostly use copies of large : termcap entries because copying the whole things is easier. You have a good point. My termcap was done so that we could run a number of applications... Grepping seems unsatisfying to find out which keys are used. Do you have a list? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Sony PCG-GRX570 laptop, panic on boot w/ 5.1R and -current
I've been trying to install something 5-ish on a Sony PCG-GRX570 laptop. I started off trying to boot off of the 5.1 release CD, normally, w/out acpi, and safe. Every option panic-ed, with essentially the same message (see below), although it followed a different driver depending on how it was booted. Then I installed 4.7 (since I had the CD), cvsup-ed my repository, and cvs up'ed /usr/src to the 5-current. I followed the section on moving from 4 to 5-current in UPDATING to build the world, etc I had to work around a bit of previously reported 4.7/5 weirdness in /usr/include, but it went w/out any trouble. When I reached the point where I was supposed to boot the new kernel in single user mode, the 5-current kernel paniced: miibus0: MII bux in fxp0 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x63696d20 fault code= supervisor write, page not present instruction pointer = 0x8:0xc0659df3 stack pointer = 0x10:0xc0c217ac frame pointer = 0x10:0xc0c217cc code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 Stopped atithread_add_handler+0x163: movl%ebx,0(%eax) db I've seen several similar reports in the archives for late last summer. The general answer seemed to be that people were having hardware trouble. I don't think that is the case in my case, unless -current is doing something very strange, since the same machine runs well enough under 4.7 to buildworld and buildkernel, and the same hardware has been running Suse and Win2000. How can I help get this solved? g. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
M. Warner Losh wrote: : I agree. termcap.small is amazingly uncurrent. However, perhaps some : merging and reducing is in order. Why is a full cons25 or vt2xx needed? : vi only needs a few capabilities. I think we mostly use copies of large : termcap entries because copying the whole things is easier. You have a good point. My termcap was done so that we could run a number of applications... Grepping seems unsatisfying to find out which keys are used. Do you have a list? Warner Is the extra maintenance worth it to save a few hundred bytes? It might even make sense to dynamically generate termcap.tiny at build time by pulling out the entries in /etc/termcap for a selected list of terminal types. Then, no extra maintenance would be needed. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
how about no copy of vi, or termcap and one copy of ed? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
boyd, rounin wrote: how about no copy of vi, or termcap and one copy of ed? Is this where we start swapping stories about when I was a young sysadmin, we didn't need no stinkin vi. We used ed and liked it!. :-) Actually, as a sysadmin who's grown old, fat, and lazy, I would prefer to not need to use ed ever again. There's no need to be masochistic. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Is this where we start swapping stories about when I was a young sysadmin, we didn't need no stinkin vi. We used ed and liked it!. :-) No, this is where we, out of respect for the mbox size of our fellow readers of -current, take this thread to -chat. Please. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
From: Richard Coleman [EMAIL PROTECTED] Is this where we start swapping stories about when I was a young sysadmin, we didn't need no stinkin vi. We used ed and liked it!. :-) the point is that when you really want your valuable data back (without resorting to backups) a small, simple toolkit is superior to abitrary and gratuitous complexity. or you could goto fonfon; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] please review. file descriptor passing for libc_r.
On Sat, 22 Nov 2003, Alfred Perlstein wrote: This should make things work properly for apps that are linked against libc_r and use filedescriptor passing. Can someone review and approve it please? This isn't needed. Any time a file descriptor is used, a call should first be made to _FD_LOCK() which ends up calling _thread_fd_lock() which then calls _thread_fd_table_init() for the file descriptor. If there's a reason that this is necessary, then I think it is just covering up another problem. I think I made this same comment a couple of years ago ;-) -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
In message: [EMAIL PROTECTED] Richard Coleman [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : : : I agree. termcap.small is amazingly uncurrent. However, perhaps some : : merging and reducing is in order. Why is a full cons25 or vt2xx needed? : : vi only needs a few capabilities. I think we mostly use copies of large : : termcap entries because copying the whole things is easier. : : You have a good point. My termcap was done so that we could run a : number of applications... : : Grepping seems unsatisfying to find out which keys are used. Do you : have a list? : : Warner : : Is the extra maintenance worth it to save a few hundred bytes? Generating them automatically can be kind of difficult. termcap doesn't change that often. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Mark Linimon wrote: Is this where we start swapping stories about when I was a young sysadmin, we didn't need no stinkin vi. We used ed and liked it!. :-) No, this is where we, out of respect for the mbox size of our fellow readers of -current, take this thread to -chat. Please. You know, its never been done on our mailing lists that I can remember, but this thread is certainly one that I'm seriously thinking of killing at the mailing list gateway for the first time. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] please review. file descriptor passing for libc_r.
* Daniel Eischen [EMAIL PROTECTED] [031122 20:46] wrote: On Sat, 22 Nov 2003, Alfred Perlstein wrote: This should make things work properly for apps that are linked against libc_r and use filedescriptor passing. Can someone review and approve it please? This isn't needed. Any time a file descriptor is used, a call should first be made to _FD_LOCK() which ends up calling _thread_fd_lock() which then calls _thread_fd_table_init() for the file descriptor. If there's a reason that this is necessary, then I think it is just covering up another problem. I think I made this same comment a couple of years ago ;-) Oh, ok paranioa on my part then. thanks! -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sat, 22 Nov 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Richard Coleman [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : : : I agree. termcap.small is amazingly uncurrent. However, perhaps some : : merging and reducing is in order. Why is a full cons25 or vt2xx needed? : : vi only needs a few capabilities. I think we mostly use copies of large : : termcap entries because copying the whole things is easier. : : You have a good point. My termcap was done so that we could run a : number of applications... : : Grepping seems unsatisfying to find out which keys are used. Do you : have a list? nvi/cl/cl_bsd.c has a possibly complete enough list in its terminfo translation table. : Is the extra maintenance worth it to save a few hundred bytes? Probably not, if this is mainly for use by rescue on larger (multi-megabyte) disks. I used an 8K termcap on 1200MB floppy rescue disks many years ago, Generating them automatically can be kind of difficult. termcap doesn't change that often. As someone pointed out, ed is sufficient. It's all we had on the root partition. I remember how to use it mainly from using it there. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
xmms compile problems
This is the last snip of output. What I did was get the patch from http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/57198 to fix the problem I have with the new ata driver not recongizing some deprecated ioctl. Anyone have any suggestions? I am running current. Thanks, Jason cc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../xmms -I/usr/X11R6/include/gtk12 -I/usr/local/include/glib12 -D_THREAD_SAFE -I/usr/local/include -I/usr/X11R6/include -I../../intl -I../.. -I/usr/local/include -O -pipe -march=athlon-xp -Wall -Wpointer-arith -finline-functions -ffast-math -fomit-frame-pointer -c cdaudio.c -fPIC -DPIC -o cdaudio.lo cdaudio.c:865: error: syntax error before '-' token cdaudio.c:95: warning: `seek' used but never defined cdaudio.c:96: warning: `get_time' used but never defined cdaudio.c:97: warning: `get_song_info' used but never defined cdaudio.c:98: warning: `get_volume' used but never defined cdaudio.c:99: warning: `set_volume' used but never defined cdaudio.c:806: warning: `play_ioctl' defined but not used cdaudio.c:819: warning: `get_current_frame' defined but not used cdaudio.c:840: warning: `drive_get_volume' defined but not used cdaudio.c:852: warning: `drive_set_volume' defined but not used cdaudio.c:864:1: unterminated #ifdef cdaudio.c:800:1: unterminated #ifdef gmake[3]: *** [cdaudio.lo] Error 1 gmake[3]: Leaving directory `/usr/ports/multimedia/xmms/work/xmms-1.2.8/Input/cdaudio' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/multimedia/xmms/work/xmms-1.2.8/Input' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/multimedia/xmms/work/xmms-1.2.8' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Stop in /usr/ports/multimedia/xmms. *** Error code 1 Stop in /usr/ports/multimedia/xmms. barton# ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
