Re: CURRENT breaks some perl?
Raymond Hicks wrote:
I have had a problem with running infobot after my recent cvsup to
current. I have heard that there is a problem with the newer perl
version.. is this a result of that? Here is error:
deepwoods# Missing braces on \N{} at ./src/Irc.pl line 131, near " $b"
Missing braces on \N{} at ./src/Irc.pl line 133, near " $b"
Missing braces on \N{} at ./src/Irc.pl line 152, within string
Compilation failed in require at ./infobot line 39.
BEGIN failed--compilation aborted at ./infobot line 42.
Welp, hard to help you here since there isn't any version info for the
infobot, but.. I am succesfully running a blootbot 1.0.0pre4 (infobot
derivative) in -CURRENT, and haven't seen any such problem. If there is
indeed a problem with the new perl (which is in -STABLE too I believe),
I'm sure it's been fixed by now. Just about every new box that gets
rolled out with perl comes with 5.6.0 nowadays..
The only problem I've seen, since ~October? is the ocassional exec bug
from backticked execs in perl from the infobot. In this case, it was for
ps/tail to find out it's current memory. We just commented out the
memory usage check and perl no longer core dumps.
Just for reference, here are two of the perl core dumps from November
(libc actually!)
#0 0x2819e1b8 in kill () from /usr/lib/libc_r.so.5
#1 0x281eb652 in abort () from /usr/lib/libc_r.so.5
#2 0x281b6095 in _thread_exit () from /usr/lib/libc_r.so.5
#3 0x281af4ba in _pq_remove () from /usr/lib/libc_r.so.5
#4 0x281b1d55 in _thread_kern_scheduler () from /usr/lib/libc_r.so.5
#5 0x0 in ?? ()
#0 0x2819e184 in getegid () from /usr/lib/libc_r.so.5
#1 0x281eb61e in abort () from /usr/lib/libc_r.so.5
#2 0x281b6015 in _thread_exit () from /usr/lib/libc_r.so.5
#3 0x281af42e in _pq_init () from /usr/lib/libc_r.so.5
#4 0x281b1cd5 in _thread_kern_scheduler () from /usr/lib/libc_r.so.5
#5 0x0 in ?? ()
/ Thomas Stromberg
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: IDE RAID (HPT-370/Abit KT7-RAID) install questions..
On Sat, 26 Aug 2000, Mike Smith wrote: This is not an "IDE RAID" controller. It's an IDE controller with some lame "RAID" software in the BIOS. We don't support this. Hopefully this thread will save the next poor soul who tries this. Just to put the final nail in the coffin.. I went ahead and installed on an old WDMA2 drive of mine, and put /var and /usr on what hopefully was a striped RAID. Well, I pulled the second drive offline, and.. it still booted up beautifully. So the striping in bios on the HPT-370 is indeed meaningless. C'est la vie. Now the question is, what ATA-100 RAID solutions are there that are fully supported? I'd guess the Promise board, but the last time I guessed (err.. last week), I got a supported chipset with an unsupported feature :) Just so I don't go do anything stupid, anyone secretly working on drivers for this behind our backs, or is it as good as junk? BTW, these IBM 75GXP drives off of the HPT-370 are amazingly fast for IDE. It was fast enough to fool me into thinking the striping might have been working. Ahh, the delusions hope brings. / Thomas For the buildbox here, I decided to go ahead with Soren's ATA-100 RAID suggestion, and bought an Abit KT7-RAID motherboard, which has an onboard Highpoint HPT-370 ATA-100 RAID. I'm using two 15G IBM 75GX drives on it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
IDE RAID (HPT-370/Abit KT7-RAID) install questions..
(excuse complete ignorance as far as IDE RAID below) For the buildbox here, I decided to go ahead with Soren's ATA-100 RAID suggestion, and bought an Abit KT7-RAID motherboard, which has an onboard Highpoint HPT-370 ATA-100 RAID. I'm using two 15G IBM 75GX drives on it. So after a long day of hacking at getting Cyclone Interchange to run under FreeBSD, I decided to go for the install today w/ 2820-CURRENT. I set up the RAID BIOS to stripe together both of the drives, each as a master on their own channel. The controller shows up in the FreeBSD bootup, as well as the drives with UDMA100, but.. While "lsdev" from the boot floppy shows one drive, in FreeBSD fdisk they show up as two 15G drives (ad4s1 ad6s1) rather then a 30G concatanated one. Am I missing something here? I've never done IDE RAID, let alone on-board RAID. Are they striped, but show up as seperate due to the lack of emulation? I went ahead and installed FreeBSD as a 6G partition.. and everything looked good (and fast!), but when I rebooted, BootEasy saw the FreeBSD bootblock, but it compained that it couldn't find any ufs partition. However, "lsdev" from the floppies saw a ufs and swap partition when checked. Do I have to install / on a non-RAIDed drive so that the boot loader has a chance? In any case, much thanks goes to Soren for adding support for the HPT-370 (and for the ATA drivers in general). I don't owe him just a beer, but probably a keg or two for all the IDE boxes that I've installed FreeBSD on :) thomas r. stromberg [EMAIL PROTECTED] senior systems administratorhttp://www.afterthought.org/ research triangle commerce, inc. 1.919.657.1317 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mtree -L problems in ports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan van Beerschoten wrote: btw, I have some big problems with the new version of mtree .. it seems that the -L flag has been abandoned.. which results in almost every port I try to install failing.. I have recompiled mtree from the tree and installed in manually (because at first my world failed as wel). Almost all 'make install's fail on mtree using -L option. Am I missing something about the mtree replacement that I should have to know ? -Steve It's probably been fixed by now, but what I did when I first had the mtree problem was set NO_MTREE in /usr/ports/Mk/bsd.port.mk - Not sure of the side affects though (anyone care to enligtnen me?) Im sure there is a more elegant solution, I was just looking for a quicky. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.2 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE5fZ1foyBzPESpFVQRAi+XAJwLJ/ae/lv0upHXZT0809bYqMz7YACbBwZI KUk+zU+eg1tmCayUgq5nuAw= =XSok -END PGP SIGNATURE- -- thomas r. stromberg: [EMAIL PROTECTED] senior systems administrator : http://www.afterthought.org/ research triangle commerce, inc. :1.919.657.1317 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: No /boot/loader (dangerously dedicated)
Doug White wrote: On Wed, 19 Jul 2000, Doug Barton wrote: As for geometry, I tried both with and without "dangerously dedicated." My understanding was that if I used the dos partition entry method that we should be able to pick up the geometry correctly, but should I try the old dos fdisk trick as well? Also, would the adaptec setting to translate 1G be affecting this? It's on currently, which it is on all my other motherboards of similar vintage. Your boot disk is now *required* (or will be very very soon) to have a proper slice table in -CURRENT; dedicated disks are deprecated in order to get a smarter boot0. Speaking of boot0 you might try using boot0cfg to force packet mode. Even though this does not directly affect -STABLE right now (I hope?), I think it'd probably be a good idea to maybe turn off the dangerously dedicated option in sysinstall (or at least turn the question off). At least in -CURRENT if nowhere else, so no one shoots themself in the foot. This would defititely help out at work, as I would no longer get the question from all of our users during the install "Should I be dedicated or not?" -- thomas r. stromberg [EMAIL PROTECTED] senior systems administratorhttp://www.afterthought.org/ research triangle commerce, inc. 1.919.657.1317 bless(\$Perl++);# the power to hack. http://www.perl.com/ #include freebsd.h /* the power to serve. http://www.freebsd.org/ */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SB Live (or RAM parity?) crash on today's -CURRENT
'panic: RAM parity error, likely hardware failure.'
This one had me confused at first, because it blamed a RAM parity
error. As this is a brand new machine (Gateway GP-800), so I first thought
I got a bad batch. Then I realized this only happens with apps that try to
do sound stuff. It's also doubtful that it's a RAM parity error due to the
severe compiling workout I've given it in the last 24 hours (134 ports, a
few kernels and several attempts make world).
Unfortunatly, since this machine was installed with
yesterdays build to begin with, I cannot confirm whether or sound works on
older builds (if needed for testing, I can rollback to an earlier kern
revision..). I can get it to crash just by playing mpg123 or restarting
esd.
machine:
FreeBSD aesthetic.detachment.org 5.0-CURRENT FreeBSD 5.0-CURRENT
#0: Thu Jul 6 12:55:50 EDT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/AESTHETIX i386
gdb -k backtrace:
=
IdlePTD 3555328
initial pcb at 2dd180
panicstr: RAM parity error, likely hardware failure.
panic messages:
---
panic: RAM parity error, likely hardware failure.
syncing disks... 14 11
done
Uptime: 10m21s
dumping to dev #ad/0x20001, offset 786432
dump ata0: resetting devices .. done
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111
110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90
89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15
14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
#1 0xc0151320 in poweroff_wait (junk=0xc0291e80, howto=-903562160)
at ../../kern/kern_shutdown.c:553
#2 0xc0260341 in isa_nmi (cd=0) at ../../i386/isa/intr_machdep.c:254
#3 0xc025a652 in trap (frame={tf_fs = -1058078704, tf_es = 16,
tf_ds = -903610352, tf_edi = -1058025472, tf_esi = 49151,
tf_ebp = -903562084, tf_isp = -903562108, tf_ebx = 4, tf_edx = 4260,
tf_ecx = 49151, tf_eax = 49151, tf_trapno = 19, tf_err = 0,
tf_eip = -1072503013, tf_cs = 8, tf_eflags = 582, tf_esp = 16,
tf_ss = -903562048}) at ../../i386/i386/trap.c:583
#4 0xc012e71b in emu_wr (sc=0xc0efd000, regno=4, data=49151, size=4)
at machine/cpufunc.h:331
#5 0xc012e807 in emu_wrptr (sc=0xc0efd000, chn=0, reg=16, data=49151)
at ../../dev/sound/pci/emu10k1.c:258
#6 0xc012ef82 in emu_vwrite (sc=0xc0efd000, v=0xc0efd088)
at ../../dev/sound/pci/emu10k1.c:585
#7 0xc012f21b in emupchan_trigger (data=0xc0efda88, go=1)
at ../../dev/sound/pci/emu10k1.c:719
#8 0xc0135a58 in chn_trigger (c=0xc0ef9800, go=1)
at ../../dev/sound/pcm/channel.c:1251
#9 0xc0134a06 in chn_wrintr (c=0xc0ef9800)
at ../../dev/sound/pcm/channel.c:385
#10 0xc013503f in chn_intr (c=0xc0ef9800) at
../../dev/sound/pcm/channel.c:785
#11 0xc01350b7 in chn_start (c=0xc0ef9800) at
../../dev/sound/pcm/channel.c:811
#12 0xc0134b33 in chn_write (c=0xc0ef9800, buf=0xca24bedc)
at ../../dev/sound/pcm/channel.c:476
#13 0xc0135e70 in dsp_write (d=0xc0ef7c00, chan=0, buf=0xca24bedc,
flag=131089)
at ../../dev/sound/pcm/dsp.c:194
#14 0xc0137e21 in sndwrite (i_dev=0xc0efa800, buf=0xca24bedc, flag=131089)
at ../../dev/sound/pcm/sound.c:359
#15 0xc018bffd in spec_write (ap=0xca24be70)
at ../../miscfs/specfs/spec_vnops.c:291
#16 0xc0221c38 in ufsspec_write (ap=0xca24be70)
at ../../ufs/ufs/ufs_vnops.c:1857
#17 0xc02220ed in ufs_vnoperatespec (ap=0xca24be70)
at ../../ufs/ufs/ufs_vnops.c:2305
#18 0xc01874e4 in vn_write (fp=0xc105ae00, uio=0xca24bedc,
cred=0xc102f200,
flags=0, p=0xca212100) at vnode_if.h:363
#19 0xc0161ca6 in dofilewrite (p=0xca212100, fp=0xc105ae00, fd=4,
buf=0x8056000, nbyte=4096, offset=-1, flags=0) at ../../sys/file.h:157
#20 0xc0161b9b in write (p=0xca212100, uap=0xca24bf80)
at ../../kern/sys_generic.c:308
#21 0xc025af01 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134569984, tf_esi = 55, tf_ebp = -1077937444,
tf_isp = -903561260, tf_ebx = 671725864, tf_edx = 671686271,
tf_ecx = 7807, tf_eax = 4, tf_trapno = 22, tf_err = 2,
tf_eip = 672214240, tf_cs = 31, tf_eflags = 663, tf_esp =
-1077937488,
tf_ss = 47}) at ../../i386/i386/trap.c:1126
#22 0xc0250205 in Xint0x80_syscall ()
#23 0x804a0d9 in ?? ()
#24 0x804901d in ?? ()
dmesg:
==
CPU: Pentium III/Pentium III Xeon/Celeron (796.54-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x683 Stepping = 3
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM
real memory = 134217728 (131072K bytes)
avail memory = 127098880 (124120K bytes)
Preloaded elf kernel "kernel" at 0xc0352000.
Pentium Pro MTRR support enabled
md0: Malloc disk
npx0: math processor on
Re: SB Live (or RAM parity?) crash on today's -CURRENT
Its in the dmesg from my post, but: CPU: Pentium III/Pentium III Xeon/Celeron (796.54-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM real memory = 134217728 (131072K bytes) avail memory = 127098880 (124120K bytes) .. pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pci0: Intel 82443BX (440 BX) host to PCI bridge at 0.0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: NVidia Riva Ultra Vanta TNT2 graphics accelerator at 0.0 irq 11 .. pci0: Intel 82371AB/EB (PIIX4) USB controller at 7.2 irq 9 pci0: Intel 82371AB Power management controller at 7.3 pcm0: Creative EMU10K1 port 0x10a0-0x10bf irq 11 at device 14.0 on pci0 xl0: 3Com 3c905C-TX Fast Etherlink XL port 0x1000-0x107f mem 0xf400-0xf47f irq 10 at device 15.0 on pci0 Good luck.. happy to test patches. thomas r. stromberg [EMAIL PROTECTED] senior systems administratorhttp://www.afterthought.org/ research triangle commerce, inc. 1.919.657.1317 bless(\$Perl++);# the power to hack. http://www.perl.com/ #include freebsd.h /* the power to serve. http://www.freebsd.org/ */ On Thu, 6 Jul 2000, Doug Barton wrote: On Thu, 6 Jul 2000, Thomas Stromberg wrote: 'panic: RAM parity error, likely hardware failure.' This one had me confused at first, because it blamed a RAM parity error. As this is a brand new machine (Gateway GP-800), so I first thought I got a bad batch. Then I realized this only happens with apps that try to do sound stuff. This is a known problem with all PCI sound cards. It happens most often with ECC ram, but it also happens without. What kind of NIC do you have, and specifically, is it a PCI card or ISA? We're trying to track that bit down too. Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xmms broken by either libc_r or sound
For now I'm just using mpg123 (gqmpeg works too of course, as a front-end, but I hate it's list manager).. mpg123 seems to work fine on all of my -current machines. thomas r. stromberg [EMAIL PROTECTED] senior systems administratorhttp://www.afterthought.org/ research triangle commerce, inc.1.919.657.1317 'FreeBSD - the power to serve' 'Perl - the power to hack' On Wed, 14 Jun 2000, Alfred Perlstein wrote: xmms is a really good test for libc_r and the sound system. xmms no longer plays back mp3s, other mp3 players are working fine. Any ideas? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Streamlining FreeBSD Installations
As far as keeping them "up to date", this is what we do: - Have a local cvsup-mirror server - All FreeBSD workstations and servers cvsup (just ports) off of it nightly. - Our central build server (which doubles as an insanely overpowered SMP dns server), builds -STABLE, and all kernels nightly When we want to upgrade a machine to current, we just: mount buildbox:/usr/src /usr/src mount buiildbox:/usr/obj /usr/obj cd /usr/src make installworld mergemaster cd /usr/src/sys/compile/mykernel make install reboot This process takes about 15 min on our 100M/s network. We don't do it too often of course, because of the downtime involved, but. As far as keeping the machines "identical", you may want to look into one of the hacks i've seen where in a school lab they boot off a floppy which dd's the hard drives off of an nfs share. I can't remember where I saw this unfortunatly. (not sure if this answers your question, but I hope it odes) - Thomas R. Stromberg Senior Systems Administrator : smtp[[EMAIL PROTECTED]]Research Triangle Commerce, Inc. : http[afterthought.org] pots[1.919.657.1317] : irc[helixblue] FreeBSD Contributor, Perl Hacker : - On Fri, 17 Mar 2000, Forrest Aldrich wrote: There was mentioned that someone was "appointed" (perhaps unwillingly :) to look into this one... who? I was also curious about what people do to keep a fleet of FreeBSD machines up-to-date with CVSup and buildworld. I can't imagine manually going to more than 100 machines and doing the same thing manually... how time consuming. To summarize again, we are deploying status monitoring machines into POPs, across the US. Those machines are identical in terms of hardware, et al. We were hoping to find a means by which to streamline the installation process, such that we could create (say) custom boot floppies where you'd input minimum information (IP address, hostname, domain, etc.) and it would then go off and perform the installation (from fdisk, newfs... to editing packet filters appropriately, which make require a "template" of sorts). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
repost of procfs crashes in -CURRENT (no html)..
Sorry about the html posting, it seems that Mozilla M13 decided to rape my
message. I hate html postings just as much as you do (thank god for
procmail filters), and will send this one using pine so Mozilla doesn't
try to rethink my e-mail for me.
Kernel:
===
FreeBSD karma.afterthought.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Mon Feb
14 23:00:42 GMT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/KARMA i386
Background:
3 users. One with X running me, and two users running breakwidgets
binary testing script, which make use of a minimized version of the
"killall" perl script which reads procfs.
This crash appears to be the old one where when two processes read procfs
simultaneously, ugly things can happen. mdillon described this in more
depth to me once but I've since lost the e-mail. I posted similar crash
reports in late November early december. He suggested having my
programs "lock" procfs reads so only one could do it's killall function at
a time. Unfortunatly, the binary testing script is very time sensitive and
this would slow things down my current run-through is about 48 hours
paralleled on 4 machines
The kernel is a GENERIC one with ipv6, softupdates, and pcm added to it.
Crash #1:
=
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc014e194 in poweroff_wait (junk=0xc02b9480, howto=-871862272) at
../../kern/kern_shutdown.c:554
#2 0xc022d064 in vm_fault (map=0xc031ee28, vaddr=3423105024, fault_type=1
'\001', fault_flags=0) at ../../vm/vm_fault.c:240
#3 0xc02810d2 in trap_pfault (frame=0xcc136cc4, usermode=0,
eva=3423108180) at ../../i386/i386/trap.c:788
#4 0xc0280d37 in trap (frame={tf_fs = -871170032, tf_es = -871170032,
tf_ds = 16, tf_edi = -871142055, tf_esi = -871142025,
tf_ebp = -871141804, tf_isp = -871142160, tf_ebx = -872323392,
tf_edx = 0, tf_ecx = -872323392, tf_eax = -871859336,
tf_trapno = 12, tf_err = 0, tf_eip = -1072160861, tf_cs = 8,
tf_eflags = 66118, tf_esp = 0, tf_ss = 0})
at ../../i386/i386/trap.c:423
#5 0xc0181fa3 in procfs_dostatus (curp=0xcc145e00, p=0xcc0166c0,
pfs=0xc14abf60, uio=0xcc136eec)
at ../../miscfs/procfs/procfs_status.c:115
#6 0xc0182590 in procfs_rw (ap=0xcc136ea0) at
../../miscfs/procfs/procfs_subr.c:277
#7 0xc017dc0a in vn_read (fp=0xc14431c0, uio=0xcc136eec, cred=0xc1450700,
flags=0, p=0xcc145e00) at vnode_if.h:334
#8 0xc015ac50 in dofileread (p=0xcc145e00, fp=0xc14431c0, fd=6,
buf=0x8235000, nbyte=4096, offset=-1, flags=0)
at ../../sys/file.h:140
#9 0xc015ab57 in read (p=0xcc145e00, uap=0xcc136f80) at
../../kern/sys_generic.c:111
#10 0xc028167e in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077946820, tf_esi = 672915688,
tf_ebp = -1077946996, tf_isp = -871141420, tf_ebx = 672858084,
tf_edx = 672809512, tf_ecx = 136531968, tf_eax = 3,
tf_trapno = 0, tf_err = 2, tf_eip = 672818732, tf_cs = 31, tf_eflags
= 659, tf_esp = -1077947040, tf_ss = 47})
at ../../i386/i386/trap.c:1055
Crash #2:
=
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc014e194 in poweroff_wait (junk=0xc02b9480, howto=-873472000) at
../../kern/kern_shutdown.c:554
#2 0xc022d064 in vm_fault (map=0xc031ee28, vaddr=3421495296, fault_type=1
'\001', fault_flags=0) at ../../vm/vm_fault.c:240
#3 0xc02810d2 in trap_pfault (frame=0xcbe0ccc4, usermode=0,
eva=3421498452) at ../../i386/i386/trap.c:788
#4 0xc0280d37 in trap (frame={tf_fs = -874512368, tf_es = -874512368,
tf_ds = 16, tf_edi = -874459817, tf_esi = -874459788,
tf_ebp = -874459564, tf_isp = -874459920, tf_ebx = -873997056,
tf_edx = 0, tf_ecx = -873997056, tf_eax = -873469064,
tf_trapno = 12, tf_err = 0, tf_eip = -1072160861, tf_cs = 8,
tf_eflags = 66118, tf_esp = 0, tf_ss = 0})
at ../../i386/i386/trap.c:423
#5 0xc0181fa3 in procfs_dostatus (curp=0xcbd7df20, p=0xcbe7dd00,
pfs=0xc154ac20, uio=0xcbe0ceec)
at ../../miscfs/procfs/procfs_status.c:115
#6 0xc0182590 in procfs_rw (ap=0xcbe0cea0) at
../../miscfs/procfs/procfs_subr.c:277
#7 0xc017dc0a in vn_read (fp=0xc1469200, uio=0xcbe0ceec, cred=0xc153d180,
flags=0, p=0xcbd7df20) at vnode_if.h:334
#8 0xc015ac50 in dofileread (p=0xcbd7df20, fp=0xc1469200, fd=5,
buf=0x8253000, nbyte=4096, offset=-1, flags=0)
at ../../sys/file.h:140
#9 0xc015ab57 in read (p=0xcbd7df20, uap=0xcbe0cf80) at
../../kern/sys_generic.c:111
#10 0xc028167e in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077945828, tf_esi = 136638564,
tf_ebp = -1077946004, tf_isp = -874459180, tf_ebx = 672858084,
tf_edx = 672809512, tf_ecx = 136654848, tf_eax = 3,
tf_trapno = 0, tf_err = 2, tf_eip = 672818732, tf_cs = 31, tf_eflags
= 663, tf_esp = -1077946048, tf_ss = 47})
at ../../i386/i386/trap.c:1055
#11 0xc0276646 in Xint0x80_syscall ()
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
procfs crash in -CURRENT (multi-read)
Just letting you guys know, the nasty multiple-read bug in procfs still
exists. I'm preparing a new smashwidgets report for 4.0 (should be ready
for tommorow, will post here), and in the process happened to shoot myself
in the foot by having two breakwidgets scripts go simultaneously. breakwidgets
reads /proc quite a bit (actually, with a minimized copy of /usr/bin/killall),
and things go bad when "worlds collide".So if any of you decide
to play with multiple /proc readers, use locks :0 Please note that this
crash is very very hard for me to duplicate.. this is after about 32 hours
of running the script that does the proc read. (full vmcore, conf, and kernel.debug available on request)..FreeBSD
karma.afterthought.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Mon Feb 14 23:00:42
GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/KARMA
i386dumping to dev #ad/0x20001, offset 1109472dump ata0: resetting devices .. done128
127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110
109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89
88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41
40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1---#0 boot (howto=256) at ../../kern/kern_shutdown.c:304304 dumppcb.pcb_cr3 = rcr3();(kgdb) bt#0 boot (howto=256) at ../../kern/kern_shutdown.c:304#1 0xc014e194 in poweroff_wait (junk=0xc02b9480, howto=-871862272) at ../../kern/kern_shutdown.c:554#2 0xc022d064 in vm_fault (map=0xc031ee28, vaddr=3423105024, fault_type=1 '\001', fault_flags=0) at ../../vm/vm_fault.c:240#3 0xc02810d2 in trap_pfault (frame=0xcc136cc4, usermode=0, eva=3423108180) at ../../i386/i386/trap.c:788#4 0xc0280d37 in trap (frame={tf_fs = -871170032, tf_es = -871170032, tf_ds = 16, tf_edi = -871142055, tf_esi = -871142025,
tf_ebp = -871141804, tf_isp = -871142160, tf_ebx = -872323392, tf_edx
= 0, tf_ecx = -872323392, tf_eax = -871859336, tf_trapno = 12, tf_err = 0, tf_eip = -1072160861, tf_cs = 8, tf_eflags = 66118, tf_esp = 0, tf_ss = 0}) at ../../i386/i386/trap.c:423#5
0xc0181fa3 in procfs_dostatus (curp=0xcc145e00, p=0xcc0166c0, pfs=0xc14abf60,
uio=0xcc136eec) at ../../miscfs/procfs/procfs_status.c:115#6 0xc0182590 in procfs_rw (ap=0xcc136ea0) at ../../miscfs/procfs/procfs_subr.c:277#7 0xc017dc0a in vn_read (fp=0xc14431c0, uio=0xcc136eec, cred=0xc1450700, flags=0, p=0xcc145e00) at vnode_if.h:334#8
0xc015ac50 in dofileread (p=0xcc145e00, fp=0xc14431c0, fd=6, buf=0x8235000,
nbyte=4096, offset=-1, flags=0) at ../../sys/file.h:140#9 0xc015ab57 in read (p=0xcc145e00, uap=0xcc136f80) at ../../kern/sys_generic.c:111#10
0xc028167e in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi
= -1077946820, tf_esi = 672915688, tf_ebp = -1077946996, tf_isp = -871141420, tf_ebx = 672858084, tf_edx = 672809512, tf_ecx = 136531968, tf_eax = 3, tf_trapno = 0, tf_err = 2, tf_eip = 672818732, tf_cs = 31, tf_eflags = 659, tf_esp = -1077947040, tf_ss = 47}) at ../../i386/i386/trap.c:1055#11 0xc0276646 in Xint0x80_syscall ()
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Suggestions for Gigabit cards for -CURRENT
We're currently looking at upgrading several of our FreeBSD servers (dual PIII-600's, 66MHz PCI) and some Sun Ultra's to Gigabit Ethernet. We plan to hook these machines into our Cisco Catalyst 5000 server. They will most likely move to be running FreeBSD 4.x by the time that we actually get our budget approved. What experiences do you guys have with the cards? Currently we're looking at the ~$1000 range, specifically at Alteon 512k's ($1000) for the FreeBSD servers and Sun Gigabit 2.0's ($2000) for the Sun servers. I was interested in the Myrinet cards (for obvious reasons), but they appear to require a Myrinet switch (though I found myself slightly confused so I may be wrong) rather then being able to hook into our Catalyst 5000. The Intel PRO/1000 Gigabit cards look rather nice too, but I haven't seen drivers yet for FreeBSD (Linux yes). I'm pretty much purchasing on marketing and reputation rather then any experience here, so any help would be much appreciated. -- === Thomas R. StrombergAsst. IS Manager / Systems Guru FreeBSD Contrib, Security Geek, etc. Research Triangle Commerce, Inc. http://www.afterthought.org/ http://www.rtci.com/ [EMAIL PROTECTED] [EMAIL PROTECTED] --- MCSE: McDonald's Certified Service Engineer ===eof To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_null, local nfs, and jail..
On 13-Jan-2000 Matthew Dillon wrote: : Sometimes we just want to nfs-mount things on the same : machine. : :Sick, poor in performance and the wrong tool for the job. :See mount_null(8) for more details on how to do it right. : Unfortunately, you still end up needing to do this for some tasks like cfs: localhost:/ /crypt nfs rw,port=3049,intr,nfsv2,noauto 0 0 Granted, cfs can be rewritten to do it otherwise, but the nfs filter is about the only way to reliably make it cross platform.. However, thanks for the pointer on nullfs.. does this work with jail(8)? Or will it not cross the filesystem boundary.. Thomas R. Stromberg Asst. IS Manager / Systems Guru FreeBSD Contrib, BeOS Dev, Security GeekResearch Triangle Commerce, Inc. http://www.afterthought.org/http://www.rtci.com/ [EMAIL PROTECTED][EMAIL PROTECTED] ===eof To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT crash under high exec() loads.. (vm_map_insert?)
:If you notice, both times it crashed on vm_map_insert. Try bumping up PMAP_SHPGPERPROC. From LINT: # # Set the number of PV entries per process. Increasing this can # stop panics related to heavy use of shared memory. However, that can # (combined with large amounts of physical memory) cause panics at # boot time due the kernel running out of VM space. # # If you're tweaking this, you might also want to increase the sysctls # "vm.v_free_min", "vm.v_free_reserved", and "vm.v_free_target". # # The value below is the one more than the default. # options PMAP_SHPGPERPROC=201 Try bumping it up to 1000 and see if that solves your crashes. If that doesn't work, and there's any chance of getting a kernel dump, try getting a kernel dump. Make sure you use a debug (compiled -g) kernel. While I can't say I truly see the correlation, you definitely know more about how it works then me. I've cvsupp'd and upped it to 1000. One question I have, is what exactly -are- pv's? The machine itself isn't under too much load during the testing, and definitely does not used a lot of shared memory. During one of the tests yesterday (c89) it was doing ~8000 execs per minute, with a load of 0.23. I've also got plenty of RAM left over. Here is what it currently looks like: last pid: 7121; load averages: 0.75, 0.31, 0.15 up 0+00:16:15 09:21:55 59 processes: 3 running, 56 sleeping CPU states: 36.0% user, 0.0% nice, 63.2% system, 0.8% interrupt, 0.0% idle Mem: 57M Active, 8412K Inact, 16M Wired, 2292K Cache, 9628K Buf, 8280K Free Swap: 786M Total, 22M Used, 764M Free, 2% Inuse This is basically X, Netscape, and 5800 exec()'s a minute. I've got debugging in my kernel, and I'll send you full results if and when it crashes again. -- == thomas r. stromberg smtp:[EMAIL PROTECTED] assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc.finger:[EMAIL PROTECTED] 'om mani pedme hung'pots://1.919.380.9771:3210 [eof]= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
semi-HEADS-UP (dumpon now wants raw disk device)
While this was mentioned in the commit log for dumpon.c by phk, I figure I'd save you the loss of a kernel core to find out like the one I lost this morning. In rc.conf (or wherever you load dumpon) make sure you change it to using a raw device. dumpon no longer accepts block devices, as they were just cleaned out of -CURRENT. This relates to the heads up that Brian Somers sent on Sunday. You need to make world first or at least rebuild savecore/dumpon, as ache made some commits to it this morning. IE, old dumpdev in /etc/rc.conf:dumpdev="/dev/wd0s1b" Should be changed to: dumpdev="/dev/rwd0s1b" -- == thomas r. stromberg smtp:[EMAIL PROTECTED] assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc.finger:[EMAIL PROTECTED] 'om mani pedme hung'pots://1.919.380.9771:3210 [eof]= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: semi-HEADS-UP (dumpon now wants raw disk device)
" I see no needs of this change. I have -current dumpon/savecore work with old entrly like /dev/wd0... savecore understand both character and old block devices now. While I see your commit in cvsweb to savecore, I still run into this (just cvsupp'd off of cvsup6.freebsd.org and rebuilt it): [root@karma] dumpon grep \$FreeBSD dumpon.c "$FreeBSD: src/sbin/dumpon/dumpon.c,v 1.8 1999/11/28 16:24:46 phk Exp $"; [root@karma] dumpon dumpon /dev/wd0s1b dumpon: /dev/wd0s1b: must specify a block device [root@karma] dumpon dumpon /dev/rwd0s1b [root@karma] dumpon Bug or Feature? FreeBSD karma.afterthought.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Tue Nov 30 09:03:33 EST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/KARMA i386 -- == thomas r. stromberg smtp:[EMAIL PROTECTED] assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc.finger:[EMAIL PROTECTED] 'om mani pedme hung'pots://1.919.380.9771:3210 [eof]= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: block devices dumpon.
"Andrey A. Chernov" wrote:
On Tue, Nov 30, 1999 at 10:49:57AM -0500, Thomas Stromberg wrote:
[root@karma] dumpon dumpon /dev/wd0s1b
dumpon: /dev/wd0s1b: must specify a block device
[root@karma] dumpon dumpon /dev/rwd0s1b
[root@karma] dumpon
Bug or Feature?
This message is confusing and means just opposite.
I'll fix dumpon to accept both device types (to work with older kernels too)
The bug is that you not rebuild your /dev
I thought all I needed to do was "./MAKEDEV all" in /dev after a
mergemaster (I also tried MAKEDEV drive) However, I guess this is not
the case. Evidentally if I makedev a drive or all, it does not MAKEDEV
the slices. I could of sworn it was supposed to.. alas! Learn something
new every day.
In any case the new 1.9 commit still acts strange (imho), I put some
output on the bottom. Thanks for your help btw! Nothing teaches you
better then a good screwup :)
[root@karma] /dev uname -a
FreeBSD karma.afterthought.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Tue
Nov 30 09:03:33 EST 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/KARMA i386
[root@karma] /dev ./MAKEDEV all
[root@karma] /dev ls wd0s*
crw-r- 1 root operator3, 0x00020002 Nov 30 12:09 wd0s1
brw-r- 1 root operator0, 0x0002 Nov 16 11:09 wd0s1a
brw-r- 1 root operator0, 0x00020001 Nov 29 18:06 wd0s1b
brw-r- 1 root operator0, 0x00020002 Aug 17 11:40 wd0s1c
brw-r- 1 root operator0, 0x00020003 Nov 16 16:48 wd0s1d
brw-r- 1 root operator0, 0x00020004 Nov 16 11:09 wd0s1e
brw-r- 1 root operator0, 0x00020005 Nov 16 11:09 wd0s1f
brw-r- 1 root operator0, 0x00020006 Nov 16 11:09 wd0s1g
brw-r- 1 root operator0, 0x00020007 Nov 16 11:09 wd0s1h
crw-r- 1 root operator3, 0x00030002 Nov 30 12:09 wd0s2
crw-r- 1 root operator3, 0x00040002 Nov 30 12:09 wd0s3
crw-r- 1 root operator3, 0x00050002 Nov 30 12:09 wd0s4
[root@karma] /dev ./MAKEDEV wd0s1b
[root@karma] /dev ./MAKEDEV wd0s1a
[root@karma] /dev ls -la wd0s*
crw-r- 1 root operator3, 0x00020002 Nov 30 12:09 wd0s1
crw-r- 1 root operator3, 0x0002 Nov 30 12:09 wd0s1a
crw-r- 1 root operator3, 0x00020001 Nov 30 12:09 wd0s1b
crw-r- 1 root operator3, 0x00020002 Nov 30 12:09 wd0s1c
crw-r- 1 root operator3, 0x00020003 Nov 30 12:09 wd0s1d
crw-r- 1 root operator3, 0x00020004 Nov 30 12:09 wd0s1e
crw-r- 1 root operator3, 0x00020005 Nov 30 12:09 wd0s1f
crw-r- 1 root operator3, 0x00020006 Nov 30 12:09 wd0s1g
crw-r- 1 root operator3, 0x00020007 Nov 30 12:09 wd0s1h
crw-r- 1 root operator3, 0x00030002 Nov 30 12:09 wd0s2
crw-r- 1 root operator3, 0x00040002 Nov 30 12:09 wd0s3
crw-r- 1 root operator3, 0x00050002 Nov 30 12:09 wd0s4
Output of the new 1.9 dumpon on block slices:
---
[root@karma] /dev ls -la wd0s1b
brw-r--r-- 1 root wheel0, 0x00020001 Nov 30 12:17 wd0s1b
[root@karma] /dev dumpon /dev/wd0s1b
dumpon: sysctl: kern.dumpdev: Device not configured
[root@karma] /dev ./MAKEDEV wd0s1b
[root@karma] /dev dumpon /dev/wd0s1b
[root@karma] /dev sysctl -a|grep kern.dump
kern.dumpdev: { major = 3, minor = 131073 }
Still burps a wee bit. But after I looked at it again it's easy to tell
why. I guess a sysctl gets put into place (I'm still not sure from
where?) called kern.dumpdev that records the original device data
specified from /etc/rc.conf .. of course, when I last booted, mine was
set to /dev/rwd0s1b, which has those properties ..
I'm just wondering why it checks those properties rather then using the
properties of the specified file (/dev/wd0s1b in that case)..
--
==
thomas r. stromberg smtp:[EMAIL PROTECTED]
assistant is manager / systems guru http://thomas.stromberg.org
research triangle commerce, inc.finger:[EMAIL PROTECTED]
'om mani pedme hung'pots://1.919.380.9771:3210
[eof]=
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
-CURRENT crash under high exec() loads.. (vm_map_insert?)
While doing some testing (and actually, in the middle of me trying to post some results) for the FreeBSD Auditing project, my 4.0-CURRENT box crashed. These tests involved a barrage of automated exec() calls which I suspect is what tore it down. I had a similar crash two weeks ago, but did not have the kernel set for debug mode, so I wrote just a quick summary on the bottom of the trace. This may of course have absolutely nothing to do with the testing, as it was (at time of crash) testing /usr/bin/bc, which is mostly waiting on the timeout to kill it off because of the interactive mode. Otherwise there was ~960,000 accumulated exec()'s altogether in a 5 hour period. As you can see, cron is the process that crashed it. Two weeks ago it was an eggdrop. I've not had any crashes in -CURRENT while this program was not running however. If you notice, both times it crashed on vm_map_insert. Enviroment: --- Machine: PIII-500, 96M RAM uname: FreeBSD karma.afterthought.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Tue Nov 23 07:31:52 EST 1999 root@:/usr/src/sys/compile/KARMA i386 load: ~1.20 Conditions: --- X w/ Netscape 4.7 was running 'breakwidgets' was pumping out up to 5000 exec() calls a minute. (depending on timeouts). At time of crash it was probably more like 30-100 execs a minute. (I suspect the latter, naturally). Dump: - IdlePTD 3022848 initial pcb at 26d3e0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01d7a67 stack pointer = 0x10:0xccd67df0 frame pointer = 0x10:0xccd67e0c 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 = 128 (cron) interrupt mask = none trap number = 12 panic: page fault syncing disks... 32 9 done dumping to dev #wd/0x20001, offset 1413889 dump 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xc0131e80 in boot () #1 0xc013221d in panic () #2 0xc0215102 in trap_fatal () #3 0xc0214db5 in trap_pfault () #4 0xc0214987 in trap () #5 0xc01d7a67 in vm_map_insert () === #6 0xc01d7c88 in vm_map_find () #7 0xc01d6e93 in kmem_alloc_pageable () #8 0xc0211a3e in pmap_pinit () #9 0xc01d7650 in vmspace_alloc () #10 0xc01d950c in vmspace_fork () #11 0xc01d6a28 in vm_fork () #12 0xc012c96f in fork1 () #13 0xc012c1f6 in fork () #14 0xc021533a in syscall () #15 0xc0209d36 in Xint0x80_syscall () #16 0x804aeee in ?? () #17 0x8049c4d in ?? () #18 0x8049a15 in ?? () #19 0x80497d9 in ?? () Two weeks beforehand this was the crash trace (I wrote it down, if need be, I can re-type all the nasty details) vm_map_insert c0272568, 0, 0, 0, cf294000 @ 0x18c === vm_map_find kmem_alloc_pageable pmap_pinit vmspace_alloc vmspace_exec exec_new_vmspace eec_elf_imgact execve syscall xint0x80_syscall -- == thomas r. stromberg smtp:[EMAIL PROTECTED] assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc.finger:[EMAIL PROTECTED] 'om mani pedme hung'pots://1.919.380.9771:3210 [eof]= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Bad 'grep' behaviour in -CURRENT, faulty binary detection?
I just happened to notice this today. For some reason 'grep' seems to think that 'set' output is binary, not text. Seems that GNU grep 2.3 is a little too sensitive to text/binary detection. This only seems to affect -CURRENT because -STABLE runs GNU grep 2.0. (This was committed October 28th). Now, I haven't looked at exactly how the code works, but it evidentally looks at the beginning of the file to detect it. You can use -a to override this of course. I'm not sending a PR or anything since this is 'arguable' on whether or not it's a bug or just being over sensitive. Here is an example of the output: FreeBSD 4.0-CURRENT (11NOV99): == [chenresig@karma] chenresig grep -V grep (GNU grep) 2.3 .. [root@karma] src set|grep karma Binary file (standard input) matches [root@karma] src set|head '!'=0 '#'=0 '$'=607 '*'=() -=569Xis 0=su '?'=0 @=() ARGC=0 FreeBSD 3.3-STABLE (09NOV99): = grouper# grep -V GNU grep version 2.0 grouper# set|grep grouper DISPLAY=grouper:10.0 HOST=grouper.aquarium.rtci.com grouper# set|head '!'=0 '#'=0 '$'=2647 '*'=() -=569Xils 0=-zsh '?'=0 @=() ARGC=0 BAUD=38400 -- == thomas r. stromberg smtp:[EMAIL PROTECTED] assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc.finger:[EMAIL PROTECTED] 'om mani pedme hung'pots://1.919.380.9771:3210 [eof]= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bad 'grep' behaviour in -CURRENT, faulty binary detection?
David O'Brien wrote: On Thu, Nov 11, 1999 at 03:29:05PM -0500, Thomas Stromberg wrote: I just happened to notice this today. For some reason 'grep' seems to think that 'set' output is binary, not text. Seems that GNU grep 2.3 is a little too sensitive to text/binary detection. I've got a notion to change this. The -CURRENT grep is also very misleading w/ ``grep -l'' in that you will get "hits" on binary files because you can't see that "is a binary file" message to know better. The output of that message should be asked for with an option, not the default. I can't imagine how many people are going to get weird/eronious output from scripts now due to it. I think it's good as a default, nothing annoys me more then "grep -R function *" in a source directory and hitting all the binaries and getting my screen splattered with high ascii. I just wish it's binary detection was a wee bit more accurate.. I don't see what's wrong with "grep -l", it does exactly what I expected it to do. It's just expected to tell you that a file matched, not anything more (anything more could cause grave problems with scripts, including some I've written).. [root@karma] /tmp grep -l expat * expat expat-0.7.6.tar.gz wv (or maybe I'm just not understanding the issue). -- == thomas r. stromberg smtp:[EMAIL PROTECTED] assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc.finger:[EMAIL PROTECTED] 'om mani pedme hung'pots://1.919.380.9771:3210 [eof]= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still waiting for xl driver reports
Jim Bloom wrote: I keep seeing a watchdog timeout with my 3c905B-TX every time the machine boots. It seems to occur after everything has been probed and /etc/rc has completed; around the time I get my login banner. I am running the dhcp client to get my IP address. I don't pound on the network very much so I can't tell you how performance is. Jim Bloom I get the same.. dmesg: -- xl0: 3Com 3c905C-TX Fast Etherlink XL irq 11 at device 14.0 on pci0 xl0: Ethernet address: 00:50:da:07:87:4c .. sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) changing root device to wd0s1a WARNING: / was not properly dismounted xl0: watchdog timeout xl0: promiscuous mode enabled xl0: watchdog timeout uname: -- FreeBSD asho.zarathushtra.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Tue Oct 12 14:23:39 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/SPENTA_MAINYU i386 -- === Thomas Stromberg, Assistant IS Manager / Systems Guru smtp:[EMAIL PROTECTED] Research Triangle Commerce, Inc. pots://919.380.9771 x3210 === To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ipfilter no longer in -CURRENT, whats the direction? (off to ipfw?)
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/ipnat/Attic/Makefile 1.2 Sun Oct 10 15:08:35 1999 UTC by peter CVS Tags: HEAD Diffs to 1.1 FILE REMOVED Nuke the old antique copy of ipfilter from the tree. This is old enough to be dangerous. It will better serve us as a port building a KLD, ala SKIP. Although a heads up in -CURRENT or -security about this would of been nice, ye old ipfilter is gone. I definitely cannot disagree with the fact that it is an antique copy, and it's a shame that no one seems to be taking care of it in the tree. At least in the past, ipfilter was for many a much better option then ipfw. Has ipfw improved to the point where it functions better as a company firewall then ipfilter? (Okay, so the group user firewalling is neat, but not really applicable for a corporate border firewall) ipfilters website: http://coombs.anu.edu.au/~avalon/ip-filter.html For why I feel ipfilter is better then ipfw (this post was written back in December '98, ipfw may have changed greatly since): http://www.freebsd.org/cgi/getmsg.cgi?fetch=117538+122112+/usr/local/www/db/text/1998/freebsd-current/19981227.freebsd-current (the big 'wanton atticizing discussion') A summary of it being: - Multiplatform. Runs on IRIX, Solaris, Linux. Comes shipped with FreeBSD, OpenBSD, and NetBSD. Keeps us in sync with the other BSD's. - Better logging then ipfw (has ipfw improved? Thats why I switched to ipfilter in the first place) It's a shame that no one seems to want to maintain ipfilter in our tree. As far as a 'port building kld', I think this may not be the 'smartest' way, seeing as anyone who is running a serious firewall would disable kld's immediately anyhow. So my question is, what's the direction we're taking here? -- === Thomas Stromberg, Assistant IS Manager / Systems Guru smtp:[EMAIL PROTECTED] Research Triangle Commerce, Inc. pots://919.380.9771 x3210 === To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
newpcm broke the Esoniq 1371 Driver Hack?
I've been using the Esoniq 1371 Driver from http://www.freebsd.org/~ghelmer/es1371/ (written by Russell Cattelan?) on my 4.0-CURRENT box for a few weeks now. It's just a hack replacement for es1370.c/es1370_reg.h, but it worked fine up until a week ago or so when I presume the newpcm code went into place. It works against my 27AUG99 kernel however. Does anyone here have plans to integrate the ES-1371 patch into the -CURRENT tree? I'm afraid my skills are not in the driver development area. For reference, the old kernel boots up with this info: pcm0: AudioPCI ES1371 irq 11 at device 12.0 on pci0 pcm0: using I/O space register mapping at 0x1080 es1371: codec vendor revision 0 es1371: codec features none es1371: stereo enhancement: no 3D stereo enhancement -- === Thomas Stromberg, Assistant IS Manager / Systems Guru smtp:[EMAIL PROTECTED] Research Triangle Consultants, Inc. http://afterthought.org 919.380.9771 x3210 irc://Mithra@EFnet FreeBSD Contributor / BeOS Dev 18330 === "if you do nothing enough, something's bound to happen.." === To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel Panic at boot with -CURRENT (last 2-3 days)
Background: --- Work recently assigned me a Gateway GP7-500 (PIII-500mhz, 96M RAM) to replace my older 333mhz PII that's been running FreeBSD 3.2.. Of course, as my testing machine, I wanted to run FreeBSD 4.0-CURRENT on it, and installed the 19990806 snapshot without a problem, and then cvsupped it to -CURRENT. Problem: This was on 17AUG, my kernel panic'd, I just assumed I left something out, but then I saw that GENERIC panic'd as well, and has panic'd since 17AUG, and continues to do so with the -CURRENT snapshot of an hour ago. However, GENERIC from 19990806 works just fine. I decided that after 3 days of kernel panics that it's a real problem and not just some little -CURRENT breakage. I decided yesterday that maybe I need to make world first, so I did. No dice there. And an hour ago, I also rm -Rf'd /usr/src, cvsupped to -CURRENT, made world again, and attempted to rebuild the kernel. Boot Sequence: -- If you want to see dmesg.boot from the 4.0-19990806-CURRENT snapshot, it's at http://haloblack.org/misc/dmesg.boot FreeBSD 4.0-CURRENT #0: thu Aug 19 12:44:12 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC+DDB Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III (498.67-MHz 686-class CPU) Origin = "Genuine Intel" Id = 0x672 Stepping = 2 Features = blah blah blah real memory = 100663296 (98304K bytes) config di lnc0 config di le0 .. .. config q avail memory = 93708288 (91512K bytes) Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x58:0xbc28 stack pointer = 0x10:0xed4 frame pointer = 0x10:0xf20 code segment= base 0xc00f, limit 0x, type 0x1b = DPL 0, pres 1, def32 0, gran 0 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = net tty bio cam kernel: type 9 trap, code=0 Stopped at 0xbc28: repeat, DDB? -- Med vanlig halsingar, -------- thomas stromberg [TRS40/SM0VVW]: smtp([EMAIL PROTECTED]) systems guru / asst. is manager: http(www.afterthought.org) research triangle consultants, inc : pots(919.380.9771 x3210) http://www.rtci.com: fax(919.380.1727) FreeBSD: The Power to Serve! : icq(17468041) BeOS Developer ID: 18330 : efnet(Mithra) : "if you do nothing enough, something's bound to happen.." : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
