[no subject]
3205Z Movies for people over 18 years old And the best part is- they are Free http://66.150.211.22/movies /FONTFONT SIZE=5 PTSIZE=18A HREF=http://66.150.211.22/movies;AOL Members /A/B/FONTFONT SIZE=3 PTSIZE=10/BBR FONT COLOR=#fd SIZE=3 PTSIZE=10 to leave list [EMAIL PROTECTED] 3450C To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: `cat /dev/io` leads to system lockup.
On Fri, Dec 20, 2002 at 07:24:15PM +1100, Bruce Evans wrote: On Fri, 20 Dec 2002, Sean Kelly wrote: On my 5.0-CURRENT kernel built 45 minutes ago, I can bring my system to its knees by doing # cat /dev/io While I understand that this isn't exactly something one would normally be doing, is it really something that should bring the system down? No. Writing to /dev/io is not supported. write(2) to a device that doesn't support writing should return -1 and set errno to ENODEV. This was broken mainly by removing the default case from mem.c:mmrw(). This causes mmrw() to loop endlessly without giving up control. Giant locking in -current makes this especially fatal -- mmrw() holds Giant so even most interrupt handlers are blocked. In RELENG_4 the only bug near here is that mmrw() returns ENXIO instead of ENODEV for writes to /dev/io. Thanks for pointing out where the code which handles /dev/io was. I see exactly what you mean, and I came up with a 2 liner that fixes it on my system. Could somebody check/commit this? edgemaster# cat /dev/io cat: /dev/io: Operation not supported by device edgemaster# Index: sys/i386/i386/mem.c === RCS file: /usr/home/ncvs/src/sys/i386/i386/mem.c,v retrieving revision 1.99 diff -p -u -r1.99 mem.c --- sys/i386/i386/mem.c 11 Oct 2002 14:58:28 - 1.99 +++ sys/i386/i386/mem.c 21 Dec 2002 07:54:29 - @@ -195,6 +195,8 @@ mmrw(dev_t dev, struct uio *uio, int fla return (EFAULT); error = uiomove((caddr_t)(int)uio-uio_offset, (int)c, uio); continue; + default: + return (ENODEV); } if (error) -- Sean Kelly | PGP KeyID: D2E5E296 [EMAIL PROTECTED] | http://www.zombie.org msg49155/pgp0.pgp Description: PGP signature
Re: -CURRENT panic on SMP Athlon box.
On Sat, Dec 21, 2002 at 08:51:27AM +0100, Poul-Henning Kamp wrote: + My SMP Athlon box paniced again tonight, and this time my serial + console caught it in the act. + + I have no idea what has caused this, and have no idea if it has any + significance for 5.0-R or not. I wonder if we have a memory leak ? Maybe a good way to debug it is to show memory statistics just like sysctl kern.malloc do, befor this panic (or any panic caused by insufficient memory) is called? -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg49156/pgp0.pgp Description: PGP signature
Re: PFIL_HOOKS should be made default in 5.0
On Fri, Dec 20, 2002 at 11:29:19PM +0200, Vallo Kallaste vallo wrote: Yes, and this undefined symbols message will make no sense from user perspective. Then fix it. The fix is trivial: [description of possible fix snipped] As I've stated several times and as you most certainly know I'm not developer. What are you trying to accomplish by the phrase then fix it? Put me down, eh? I have encountered this problem several times and for the first time the message about unresolved symbol(s) made no sense and forced me to do time consuming searches over the 'Net to get a clue what's going on. Will we want to get possible users using FreeBSD or will we want argue about it to death? The users get bored and move on, that's it. Uh, sorry Terry. I was lightly drunk (just got back from party) yesterday when I wrote this. Althought the writing has some right points (from my side of view), the overall tone is rude. I'm so sorry. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sym0 not working any more / Interrupt problem
Hello, with a current current kernel, my system can not allocate an interrupt for an symbios 875 SCSIcontroller any more. This worked (without any changes on the hardware inbetween with a kernel from Dec 2nd.) Enclosed is the complete dmesg output. Any hints what I could try? Michael -- - michael class, viktor-renner str. 39, 72074 tuebingen, frg E-Mail: [EMAIL PROTECTED] Phone: +49 7031 14-3707 (work) +49 7071 81950 (private) - Copyright (c) 1992-2002 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.0-CURRENT #0: Sat Dec 21 12:00:24 MET 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/MCSMP2 Preloaded elf kernel /boot/kernel/kernel at 0xc0552000. Preloaded elf module /boot/kernel/acpi.ko at 0xc05520a8. Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (996.55-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 1073676288 (1023 MB) avail memory = 1037541376 (989 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: AMIINT VIA_694X on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 8 entries at 0xc00f7530 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA100 controller port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xcc00-0xcc1f irq 10 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ulpt0: Hewlett-Packard DeskJet 990C, rev 1.10/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode uhci1: VIA 83C572 USB controller port 0xd800-0xd81f irq 10 at device 7.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub1: port error, restarting port 1 uhub1: port error, giving up port 1 uhub1: port error, restarting port 2 uhub1: port error, giving up port 2 pci0: serial bus, SMBus at device 7.4 (no driver attached) xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xc800-0xc87f mem 0xde80-0xdeff irq 9 at device 9.0 on pci0 xl0: Ethernet address: 00:10:5a:d7:dd:9c miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative EMU10K1 port 0xc400-0xc41f irq 5 at device 10.0 on pci0 bktr0: BrookTree 878 mem 0xdedfe000-0xdedfefff irq 10 at device 11.0 on pci0 bktr0: Hauppauge Model 61344 D121 bktr0: Detected a MSP3410D-B4 at 0x80 bktr0: Hauppauge WinCast/TV, Philips FR1216 PAL FM tuner, msp3400c stereo, remote control. pci0: multimedia at device 11.1 (no driver attached) sym0: 875 port 0x82000134-0x82000137,0xdffe-0xdffe00ff mem 0xf1020-0xf103f,0xdfffe000-0xdfffefff,0xdf00-0xdfff at device 12.0 on pci0 sym0: failed to allocate IRQ resource device_probe_and_attach: sym0 attach returned 6 acpi_button1: Sleep Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f
Re: pam_setenv() crashes rshd...
Mikhail Teterin [EMAIL PROTECTED] writes: The following patch fixes (works around?) the problem for me (pam_setenv is rather inefficiently implemented by the vendor, BTW), I am the vendor. What's wrong with pam_setenv()? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pam_setenv() crashes rshd...
Mikhail Teterin [EMAIL PROTECTED] writes: The following patch fixes (works around?) the problem for me (pam_setenv is rather inefficiently implemented by the vendor, BTW), I am the vendor. What's wrong with pam_setenv()? I only went into the code to see where it may be crashing my rshd and noticed the mild inefficiency. Did not know where the code is from either. Sorry if I offended you. The pam_setenv and pam_putenv are backwards, IMHO. putenv should be using setenv -- not the other way around. Currently, the setenv takes NAME and VALUE separately, mallocs a new buffer, sprintfs %s=%s into it, sends the buffer to putenv, which re-parses it and frees it. I think, pam_setenv should be doing the actual dirty work, with putenv being a wrapper. This would save some cycles (and, possibly, syscalls -- from malloc), but, of course, it would not be very significant with todays hardware, yada, yada... Would you have any other comments about my original post -- why is pam_setenv causing the segfault somewhere, and is there anything wrong with my patch? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ssh authentification broken, only public keys work
Fixed, thanks. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lock order reversals in sys_pipe.c and kern_sig.c
[2002-11-18 11:39] Alfred Perlstein said:
| * Kris Kennaway [EMAIL PROTECTED] [021118 11:06] wrote:
| I've just turned witness back on on the bento cluster, and got the
| following lock order reversals a number of times overnight:
|
| Nov 18 07:45:40 user.crit gohan11 kernel: 1st 0xc6887200 pipe mutex (pipe mutex)
|@ /local0/src-client/sys/kern/sys_pipe.c:465
| Nov 18 07:45:40 user.crit gohan11 kernel: 2nd 0xc0447780 sigio lock (sigio lock)
|@ /local0/src-client/sys/kern/kern_sig.c:2225
| Nov 18 10:28:47 user.crit gohan10 kernel: 1st 0xc4941580 pipe mutex (pipe mutex)
|@ /local0/src-client/sys/kern/sys_pipe.c:1038
| [...]
|
| Are these known problems?
|
| Well now they are, I will investigate as time permits.
Maybe this will help. The attached prog causes a LOR message. I dug
thru the kernel source from fcntl to fsetown, but am little more than
lost at this point...
thanks.
brent
--
Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing. -- Duane Allman
#include unistd.h
#include fcntl.h
#include stdio.h
/*
This program causes the following LOR. Strangely, it will only cause
the LOR _once_. To repeat, you must reboot.
lock order reversal
1st 0xc526c180 pipe mutex (pipe mutex) @ /usr/src/sys/kern/sys_pipe.c:465
2nd 0xc051ef80 sigio lock (sigio lock) @ /usr/src/sys/kern/kern_sig.c:2225
Debugger(witness_lock)
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db trace
Debugger(c04961d5,c051ef80,c04ccf5a,c04ccf5a,c04cf7e1) at Debugger+0x54
witness_lock(c051ef80,8,c04cf7e1,8b1,c526c180) at witness_lock+0x667
_mtx_lock_flags(c051ef80,0,c04cf7e1,8b1,23) at _mtx_lock_flags+0xb1
pgsigio(c4f2fe58,17,0,1ad,0) at pgsigio+0x30
pipe_read(c4f28654,e0286c7c,c5024680,0,c4de28c0) at pipe_read+0x516
dofileread(c4de28c0,c4f28654,3,bfbffca3,1) at dofileread+0xd2
read(c4de28c0,e0286d10,c04e9042,407,3) at read+0x6b
syscall(2f,2f,2f,bfbffcd8,bfbffce0) at syscall+0x28e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (3, FreeBSD ELF32, read), eip = 0x280b09c3, esp = 0xbfbffc7c, ebp =
0xbfbffcb0 ---
*/
int
main(int argc, char** argv)
{
int fd[2];
long flags;
char buf[1];
if (pipe(fd) == 0) {
flags = fcntl(fd[0], F_GETFL, 0);
fcntl(fd[0], F_SETFL, flags | O_NONBLOCK | O_ASYNC);
fcntl(fd[0], F_SETOWN, getpid());/* -- causes LOR in read() */
read(fd[0], buf, 1);
close(fd[0]);
close(fd[1]);
}
else
{
perror(fifo);
}
return 0;
}
Re: -CURRENT panic on SMP Athlon box.
Pawel Jakub Dawidek wrote:
On Sat, Dec 21, 2002 at 08:51:27AM +0100, Poul-Henning Kamp wrote:
+ My SMP Athlon box paniced again tonight, and this time my serial
+ console caught it in the act.
+=20
+ I have no idea what has caused this, and have no idea if it has any
+ significance for 5.0-R or not. I wonder if we have a memory leak ?
Maybe a good way to debug it is to show memory statistics just like sysctl
kern.malloc do, befor this panic (or any panic caused by insufficient
memory) is called?
It might not just be an Athlon specific problem, or running out of
RAM, cos I've got Intel a half a gig of RAM ...
My SMP running {yesterday's (roughly, via ctm)} current, is also
regularly panicing with a variety of different messages. Box ran
just fine with 4.7-REL single CPU, for short time with dual CPU,
(but I didnt run that long with a dual config 4.7, cos I couldnt
access my IDE bus in dual cpu mode on 4.7 (reported)).
I checked the Asus ftp site, unfortuantely I do have the newest BIOS,
(so no easy hope of a solution there), so now I `just' have to:
- learn about kernel hints file (I still include GENERIC's)
- read my fresh downloaded Asus BIOS .pdf manual, check settings,
- read the FreeBSD handbook on trapping debug messages to a serial
port, so I can easily trap edit post them here,
then I can give current@ meaningful debugs,
meanwhile FWIW dmesg config diff appended:
--
Copyright (c) 1992-2002 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.0-CURRENT #0: Thu Dec 19 23:42:47 CET 2002
[EMAIL PROTECTED]:/usr/ftp/public/freebsd/work/current/src/sys/i386/compile/DUAL
Preloaded elf kernel /boot/kernel/kernel at 0xc0b0.
Preloaded mfs_root /boot/mfsroot at 0xc0b000a8.
Preloaded elf module /boot/kernel/acpi.ko at 0xc0b000ec.
Timecounter i8254 frequency 1193182 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x650 Stepping = 0
Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real memory = 536858624 (511 MB)
avail memory = 509820928 (486 MB)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 - irq 0
IOAPIC #0 intpin 16 - irq 12
IOAPIC #0 intpin 17 - irq 5
IOAPIC #0 intpin 19 - irq 9
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0
cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
md0: Preloaded image /boot/mfsroot 4423680 bytes at 0xc067c958
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: ASUS P2L97-DS on motherboard
ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
Using $PIR table, 7 entries at 0xc00f0d20
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-safe frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
acpi_cpu0: CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
agp0: Intel 82443LX (440 LX) host to PCI bridge mem 0xe400-0xe7ff at device
0.0 on pci0
pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci1: display, VGA at device 0.0 (no driver attached)
isab0: PCI-ISA bridge at device 4.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 ATA33 controller port 0xd800-0xd80f at device 4.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xd400-0xd41f irq 9 at device
4.2 on pci0
usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
Timecounter PIIX frequency 3579545 Hz
pci0: bridge, PCI-unknown at device 4.3 (no driver attached)
ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xd000-0xd0ff mem
0xde80-0xde800fff irq 9 at device 6.0 on pci0
aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
fxp0: Intel Pro 10/100B/100+ Ethernet port 0xb800-0xb81f mem
0xde00-0xde0f,0xe100-0xe1000fff irq 5 at device 11.0 on pci0
fxp0: Ethernet address 00:a0:c9:9c:e0:a5
inphy0: i82555 10/100 media interface on miibus0
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5
irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/9 bytes threshold
plip0: PLIP network interface on ppbus0
lpt0: Printer on ppbus0
lpt0: Interrupt-driven port
ppi0: Parallel
Re: pam_setenv() crashes rshd...
Mikhail Teterin [EMAIL PROTECTED] writes: The pam_setenv and pam_putenv are backwards, IMHO. putenv should be using setenv -- not the other way around. Currently, the setenv takes NAME and VALUE separately, mallocs a new buffer, sprintfs %s=%s into it, sends the buffer to putenv, which re-parses it and frees it. I think, pam_setenv should be doing the actual dirty work, with putenv being a wrapper. This would save some cycles (and, possibly, syscalls -- from malloc), but, of course, it would not be very significant with todays hardware, yada, yada... No, the storage format for environment variables is part of the API and is intended for compatibility with libc. Doing it your way would be backward. Would you have any other comments about my original post -- why is pam_setenv causing the segfault somewhere, and is there anything wrong with my patch? Thanks! I don't know why it crashes, and I haven't looked at the patch. I probably won't have time for it until early next year. In the meantime, merry Christmas and a happy New Year :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
Sergey Mokryshev wrote: I'm really not a fan of NO_PFIL_HOOKS as an option. I'm not talking about NO_PFIL_HOOKS but options PFIL_HOOKS in GENERIC. Too many people may foot shoot themselves trying to upgrade from 4-STABLE to 5.0. If you make them non-optional, which is what started this thread, then you *are* talking about having to add an option in to get rid of them. I understand that people all want their pet software to run out of the box without modification. Probably the correct thing to do is to wire in ipfilter as a Netgraph module. AFAIK Solaris, HP-UX and others lack Netgraph support, but support pfil. They support Streams, instead. Same ecological niche. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make(1) core dumps on buildworld
cvsupped 2 hrs ago with cvsup2.freebsd.org. When trying to to buildworld, make(1) core dumped with error 139.Here is the backtrace: (gdb) backtrace #0 0x08073395 in __smakebuf () #1 0x0805a7f6 in Var_Parse (str=0x80a7540 X\n\b0Z\n\b, ctxt=0x80a5860, err=134519156, lengthPtr=0x80a4780, freePtr=0x80a4780) at /usr/src/usr.bin/make/var.c:1435 #2 0x0805a7c7 in Var_Parse (str=0x80a7540 X\n\b0Z\n\b, ctxt=0x8049974, err=134891392, lengthPtr=0x8054578, freePtr=0x80bde70) at /usr/src/usr.bin/make/var.c:1430 #3 0x08049f18 in CompatRunCommand (cmdp=0x80a4780, gnp=0x8092880) at /usr/src/usr.bin/make/compat.c:312 #4 0x0805a7f6 in Var_Parse (str=0x809e8e0 \220T\n\b A\v\b, ctxt=0x80a5490, err=134520192, lengthPtr=0x8092880, freePtr=0x80bde70) at /usr/src/usr.bin/make/var.c:1435 #5 0x0805a7c7 in Var_Parse (str=0x809e8e0 \220T\n\b A\v\b, ctxt=0x8049d80, err=134817920, lengthPtr=0x805a59a, freePtr=0x80c3800) at /usr/src/usr.bin/make/var.c:1430 #6 0x08049dd6 in CompatRunCommand (cmdp=0x8092880, gnp=0x8092880) at /usr/src/usr.bin/make/compat.c:239 #7 0x0804a205 in CompatMake (gnp=0x80c3800, pgnp=0x1) at /usr/src/usr.bin/make/compat.c:450 #8 0x08050d0e in MainParseArgs (argc=3, argv=0x8092880) at /usr/src/usr.bin/make/main.c:337 #9 0x0804814c in _start () It always core dumps randomly in making libraries, libmsun and libkvm for example. dmesg follows: Preloaded elf kernel /boot/kernel/kernel.debug at 0xc046d000. Preloaded elf module /boot/kernel/acpi.ko at 0xc046d0b0. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1595159872 Hz CPU: Pentium 4 (1595.16-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf12 Stepping = 2 Features=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,P AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 268369920 (255 MB) avail memory = 255909888 (244 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: AMIINT AMIINT10 on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 Using $PIR table, 9 entries at 0xc00f7550 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82850 host to AGP bridge mem 0xe800-0xebff at device 0.0 o n pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 rl0: RealTek 8139 10/100BaseTX port 0xac00-0xacff mem 0xefefff00-0xefef ir q 10 at device 1.0 on pci2 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:40:95:07:53:6b miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Intel Pro 10/100B/100+ Ethernet port 0xa800-0xa81f mem 0xefd0-0xefdf ,0xe77ff000-0xe77f irq 12 at device 2.0 on pci2 fxp0: Ethernet address 00:90:27:13:a4:48 inphy0: i82555 10/100 media interface on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 ATA100 controller port 0xff00-0xff0f at device 31.1 on pci 0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at device 31.2 (no driver attached) pci0: serial bus, SMBus at device 31.3 (no driver attached) pci0: serial bus, USB at device 31.4 (no driver attached) pci0: multimedia, audio at device 31.5 (no driver attached) acpi_button1: Sleep Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 fdc0: cmd 3 failed at out byte 1 of 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: cmd 3 failed at out byte 1 of 3 pmtimer0 on isa0 orm0: Option ROMs at iomem 0xe-0xe0fff,0xc-0xcbfff on isa0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f 0-0x3f5 irq 6 drq 2 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec IP Filter: v3.4.29 initialized. Default = pass all, Logging = enabled acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5% ad0: 12949MB IBM-DJNA-371350 [26310/16/63] at ata0-master UDMA66 acd0: CDROM CD-ROM TW 120D at ata1-master PIO3 pass0 at ata1 bus 0 target 0 lun 0 pass0: I DE CD-ROM TW120D 1.30 Removable CD-ROM SCSI-0 device pass0: 11.000MB/s transfers
Re: PFIL_HOOKS should be made default in 5.0
On Sat, 21 Dec 2002, Terry Lambert wrote: Sergey Mokryshev wrote: I'm really not a fan of NO_PFIL_HOOKS as an option. I'm not talking about NO_PFIL_HOOKS but options PFIL_HOOKS in GENERIC. Too many people may foot shoot themselves trying to upgrade from 4-STABLE to 5.0. If you make them non-optional, which is what started this thread, then you *are* talking about having to add an option in to get rid of them. I understand that people all want their pet software to run out of the box without modification. I did not start this thread :-) I've filled a PR a while ago. Since PFIL code is optional - let it be. IMHO it is good to keep the same behaviour of the default installations between versions, but entries in UPDATING, RELEASE NOTES and, probably later, FAQ will ease the transition. Probably the correct thing to do is to wire in ipfilter as a Netgraph module. AFAIK Solaris, HP-UX and others lack Netgraph support, but support pfil. They support Streams, instead. Same ecological niche. Never get a chance to dig in. Perhaps in the future. Darren states that PFIL code was derived from NetBSD so there are no licensing issues. Sergey Mokryshev. -- Sergey S. Mokryshev [EMAIL PROTECTED] SMP453, MOKR-RIPN To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
Darren Reed wrote:
This is a reasonable argument... if it's possible to tune it so
that it's fast. Hacking in the IP Filter hooks unonditionally
for code that can't really be distributed as part of the system
because of its license, and thus making things slower, with no
chance to make them faster later, is not my idea of A Really
Good Thing(tm).
I don't understand this paragraph at all.
The original posting in this thread gave a patch to unconditionalize
the PFIL_HOOKS thing, so that the ipfilter module could load on a
default kernel, without having to do a reasonable amount of work.
The initial reason claimed for doing this was to avoid the error
message about unresolved symbols, when trying to load the ipfilter
module. In other words, it was a complaint that the messages were
not specific to the problem, but were rather the generic messages.
My response to that was that you could create accessor/mutator
functions which were always defined, but not always functional.
By using these functions, instead of trying to access the pointers
directly, there are no undefined symbols, and you get the specific
error message, rather than the generic: any message you want it to
print.
But the complaint was just an ecuse. The real reason is that the
people complaining don't want to have to recompile the kernel to
use the ipfilter module: the complaint was because they wanted it
to be resolved in a particular way, so that they got a result that
they weren't willing to ask for directly. Solving the first one
left them unhappy.
That's fine; now that the truth has come out, instead of being
coyly hidden in a side issue, it's obvious what's wanted.
But compiling the kernel with the hooks in place is not the only
way to solve the problem.
Things would be a lot easier if people would ask for what they
want, instead of trying to out-strategize the people they expect
to say no, if they were to ask for what they really wanted. 8-(.
The purpose of pfil(9) is not to facilitate ipfilter but to act
as a mechanism for anything to filter packets to use it as the
way to receive packets. Ideally ipfw* should also use pfil(9)
and not have those large chunks of code in ip_{in,out}put.c.
Yeah, that's the reason that BPF and netgraph and streams and ...
were invented, too. Wouldn't it be great if everyone adopted the
API I like best? 8-) 8-).
Probably the correct thing to do is to wire in ipfilter as a
Netgraph module.
If/when the joining between layer 2 and layer 3 in the kernel
uses netgraph rather than the current mechanisms, then it would
be appropriate to use netgraph for ipfilter.
That's not a good demand; here's why: There are two types of
data paths: (1) the fast path, and (2) the path for research and
for things that are going to be slow anyway, by their nature.
The ipfilter code is in the second category.
It's really bogus to insist that everything take the slow path
because something slow has to take the slow path.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
panic in netinet/tcp_syncache.c: syncache_timer
I'd like a review of the following fix I'd like to commit.
The syncache_timer() function seems to have a locking problem causing
panics, even after yesterday's patches.
This apparently occurs when there are unexpired syncache entries
while the corresponding listening socket is closed. tcp_close()
destroys the relevant lock in the inpcb structure, which causes
INP_LOCK() on that structure in the next syncache_timer() call to
panic.
I'm testing the patch below, which simply removes the inpcb locking
and avoids the panic. It seems safe to me since we're running splnet,
but I'm not sure it's correct since I suppose the locking is there
for a reason...
--- tcp_syncache.c.old Sat Dec 21 03:03:22 2002
+++ tcp_syncache.c Sat Dec 21 17:50:10 2002
@@ -384,14 +384,12 @@
break;
sc = nsc;
inp = sc-sc_tp-t_inpcb;
- INP_LOCK(inp);
if (slot == SYNCACHE_MAXREXMTS ||
slot = tcp_syncache.rexmt_limit ||
inp-inp_gencnt != sc-sc_inp_gencnt) {
nsc = TAILQ_NEXT(sc, sc_timerq);
syncache_drop(sc, NULL);
tcpstat.tcps_sc_stale++;
- INP_UNLOCK(inp);
continue;
}
/*
@@ -400,7 +398,6 @@
* entry on the timer chain until it has completed.
*/
(void) syncache_respond(sc, NULL);
- INP_UNLOCK(inp);
nsc = TAILQ_NEXT(sc, sc_timerq);
tcpstat.tcps_sc_retransmitted++;
TAILQ_REMOVE(tcp_syncache.timerq[slot], sc, sc_timerq);
--
Pierre Beyssac [EMAIL PROTECTED] [EMAIL PROTECTED]
Free domains: http://www.eu.org/ or mail [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
Sergey Mokryshev wrote: Darren states that PFIL code was derived from NetBSD so there are no licensing issues. This is Darren Reed's ipfilter.c code, which he will not allow to be distributed modified, and so Theo got all upset and diked it out of OpenBSD , and then wrote a clone of it, right? There *are* licensing issues; it's an issue of interpretation; I can't believe you missed the explosion on the mailing list over the clarification of interpretation Darren posted... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Compile problem again (warnings)
Hi ! I am back at developing some stuff for FreeBSD, but I am again getting warnings are treated as errors problem and it seems that -DNO_WERROR doesn't work anymore. Is there a solution ofr this? I use gcc (Prerelease 3.1). Must I recompile world again? Andy ** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * [EMAIL PROTECTED] * Sentinel, BH 90210, True's Trooper, * *[EMAIL PROTECTED] * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender* * ICQ-UIC: 4911125 * * PGP key available *http://www.atechnet.dhs.org/~andy/ * ** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in netinet/tcp_syncache.c: syncache_timer
Can you try upgrading to rev 1.29 of tcp_syncache.c which I committed yesterday? I suspect that should fix this problem. Jeffrey To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in netinet/tcp_syncache.c: syncache_timer
On Sat, Dec 21, 2002 at 10:57:35AM -0800, Jeffrey Hsu wrote: Can you try upgrading to rev 1.29 of tcp_syncache.c which I committed yesterday? I suspect that should fix this problem. No, I believed that too when I saw your patch, but it didn't solve my problem. -- Pierre Beyssac [EMAIL PROTECTED] [EMAIL PROTECTED] Free domains: http://www.eu.org/ or mail [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compile problem again (warnings)
Aleksander Rozman - Andy wrote: Hi ! I am back at developing some stuff for FreeBSD, but I am again getting warnings are treated as errors problem and it seems that -DNO_WERROR doesn't work anymore. Is there a solution for this? I use gcc (Prerelease 3.1). Must I recompile world again? I don't know much about the details but if you're running -CURRENT then you are definitely behind the times. $ gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021119 (release) If your source tree is up to date then you do need to make buildworld again. And probably you would need to rm -rf /usr/include/* before make installworld, to get rid of the obsolete headers. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in netinet/tcp_syncache.c: syncache_timer
I'm testing the patch below, which simply removes the inpcb locking and avoids the panic. It seems safe to me since we're running splnet, but I'm not sure it's correct since I suppose the locking is there for a reason... It's safe to remove those inp locks. We only use the generation count to check to see if the inp has been deleted. Jeffrey To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in netinet/tcp_syncache.c: syncache_timer
Pierre, can you see if this patch fixes your problem? Thanks.
Jeffrey
Index: tcp_syncache.c
===
RCS file: /home/ncvs/src/sys/netinet/tcp_syncache.c,v
retrieving revision 1.30
diff -u -r1.30 tcp_syncache.c
--- tcp_syncache.c 20 Dec 2002 11:24:02 - 1.30
+++ tcp_syncache.c 21 Dec 2002 19:52:18 -
@@ -384,14 +384,12 @@
break;
sc = nsc;
inp = sc-sc_tp-t_inpcb;
- INP_LOCK(inp);
if (slot == SYNCACHE_MAXREXMTS ||
slot = tcp_syncache.rexmt_limit ||
inp-inp_gencnt != sc-sc_inp_gencnt) {
nsc = TAILQ_NEXT(sc, sc_timerq);
syncache_drop(sc, NULL);
tcpstat.tcps_sc_stale++;
- INP_UNLOCK(inp);
continue;
}
/*
@@ -399,6 +397,7 @@
* to modify another entry, so do not obtain the next
* entry on the timer chain until it has completed.
*/
+ INP_LOCK(inp);
(void) syncache_respond(sc, NULL);
INP_UNLOCK(inp);
nsc = TAILQ_NEXT(sc, sc_timerq);
Re: panic in netinet/tcp_syncache.c: syncache_timer
On Sat, Dec 21, 2002 at 12:03:24PM -0800, Jeffrey Hsu wrote: Pierre, can you see if this patch fixes your problem? Thanks. Yes, it does. Actually I tried that before, but then I thought locking at this place was probably unnecessary because it seemed to apply to the generation count only. As matter of fact I just committed the previous patch I sent before I saw your mail... probably we should commit yours instead? -- Pierre Beyssac [EMAIL PROTECTED] [EMAIL PROTECTED] Free domains: http://www.eu.org/ or mail [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
NEWCARD, devd, sio and PCCARD_FUNCTION_SERIAL cards
Dear Warner and Hackers, Is there any way (on -current with NEWCARD) devd can prevent sio driver from attaching to *ANY* pc-card that has PCCARD_FUNCTION_SERIAL? From what i understand devd can load driver modules, but it only comes to play when card is not recognized, right? The particular problem is that 3COM Bluetooth PC-CARD has PCCARD_FUNCTION_SERIAL, thus sio driver claims it knows the card. Later sio driver fails to attach because it does not recognize UART and game over. Other drivers and devd do not even have a change to look at the card. If i hack sio_pccard_match() function and filter out 3COM card (or take out sio driver completely) then everything is working. Do we need 'ignore list' for the sio driver? Is there a better way? thanks, max p.s. BTW, OLDCARD and pccardd work just fine. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FreeBSD 5.0-RC2 now available
All, FreeBSD 5.0-RC2 has been uploaded to ftp-master and is showing up on most of the primary mirrors. ia32, ia64, pc98, and alpha images are available now; sparc64 will be pushed out once it becomes available. I'd like to thank Marcel Moolenaar for providing the ia64 bits and Takahashi Yoshihiro for proving the pc98 bits. The plan going forward is to cut an RC3 in early January, followed by 5.0-RELEASE a week later. This will hopefully allow enough time to finish all of the outstanding TODO items and test the new dual UFS1/UFS2 bootblocks before release. The TODO list is at http://www.freebsd.org/releases/todo.html and has been updated with several new items. We are coming down to the wire for 5.0 and any help with the remaining items would be greatly appreciated. Once again, thanks to everyone who helped with RC2, and I encourage everyone to download and test it. The Release Engineering Team To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NEWCARD, devd, sio and PCCARD_FUNCTION_SERIAL cards
In message: [EMAIL PROTECTED] Maksim Yevmenkin [EMAIL PROTECTED] writes: : Dear Warner and Hackers, : : Is there any way (on -current with NEWCARD) devd can : prevent sio driver from attaching to *ANY* pc-card : that has PCCARD_FUNCTION_SERIAL? Sure. Just have sio_pccard_match return -100. I've just committed the change to do this. No need to do anything else, I think. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0-RC2 now available
Scott Long wrote: All, FreeBSD 5.0-RC2 has been uploaded to ftp-master and is showing up on most of the primary mirrors. ia32, ia64, pc98, and alpha images are available now; sparc64 will be pushed out once it becomes available. I'd like to thank Marcel Moolenaar for providing the ia64 bits and Takahashi Yoshihiro for proving the pc98 bits. The plan going forward is to cut an RC3 in early January, followed by 5.0-RELEASE a week later. This will hopefully allow enough time to finish all of the outstanding TODO items and test the new dual UFS1/UFS2 bootblocks before release. The TODO list is at http://www.freebsd.org/releases/todo.html and has been updated with several new items. We are coming down to the wire for 5.0 and any help with the remaining items would be greatly appreciated. Once again, thanks to everyone who helped with RC2, and I encourage everyone to download and test it. The Release Engineering Team To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Oops, as many have pointed out, the 5.0 TODO list is at http://www.freebsd.org/releases/5.0R/todo.html. Sorry for the confusion. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VLAN v.s. NIC with VLAN hardware support bug.
In article [EMAIL PROTECTED], Daniel C. Sobral [EMAIL PROTECTED] wrote: Does fxp have hardware support for vlans? I use vlans extensively and never noticed a problem. The 82550 and 82551 chips support hardware insertion/stripping of VLAN tags. But our driver doesn't currently make use of that feature. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VLAN v.s. NIC with VLAN hardware support bug.
On Sat, Dec 21, 2002 at 02:42:30AM +0100, Dan Lukes wrote the words in effect of: IFAIK no. I tried it also during debug of my problem. But it doesn't support 1000BaseTX, so it isn't decision for my purpose. The only cards with HW vlan support on STABLE are nge, bge, txp, gx, em, ti (ti aren't affected by reported bug as it strips the priority bits at driver level). Dan, I believe you submitted a PR about this [1], what does patch try to solve, regarding VLAN hardware support? [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/46405 Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: WEIRD! div() broken on -CURRENT?
On Sat, 21 Dec 2002, Tim Robbins wrote: On Fri, Dec 20, 2002 at 08:43:25PM -0800, Juli Mallett wrote: * De: Tim Robbins [EMAIL PROTECTED] [ Data: 2002-12-20 ] [ Subjecte: Re: WEIRD! div() broken on -CURRENT? ] On Fri, Dec 20, 2002 at 09:24:39PM -0500, Joe Marcus Clarke wrote: I'm doing something wrong, right? I mean, this can't be right. I've verified this now on a P4 running: [...] I can reproduce it here. It looks like gcc is using a strange calling convention that the i386 div.S does not understand (MI div.c seems to, though). TenDRA and GCC3 use a different struct return format than we used to use (see http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01783.html) and we never had a flag day for the old format, and there's no UPDATING or whatnot notes about this AFAIK. This means at least div has to change to use the new calling convention. [...] I've imported the versions of div.S and ldiv.S from NetBSD HEAD which work properly with the new calling convention. Thanks for mentioning (on IRC) that the pcc struct return convention had something to do with it. Did we really mean to change this? It is a relatively recent change. From cvs history: % RCS file: /home/ncvs/src/contrib/gcc/config/freebsd.h,v % Working file: freebsd.h % head: 1.37 % ... % % revision 1.37 % date: 2002/04/30 17:22:42; author: obrien; state: Exp; lines: +34 -460 % MI bits for Gcc 3.1. % This contains mounds changes, one of which breaks 5-10 (?) years of binary compatibility within gcc-compiled objects: % Index: freebsd.h % === % RCS file: /home/ncvs/src/contrib/gcc/config/freebsd.h,v % retrieving revision 1.36 % retrieving revision 1.37 % diff -u -2 -r1.36 -r1.37 % --- freebsd.h 14 May 2001 22:45:26 - 1.36 % +++ freebsd.h 30 Apr 2002 17:22:42 - 1.37 % ... % -/* Don't default to pcc-struct-return, because gcc is the only compiler, and % - we want to retain compatibility with older gcc versions % - (even though the SVR4 ABI for the i386 says that records and unions are % - returned in memory). */ % -#undef DEFAULT_PCC_STRUCT_RETURN % -#define DEFAULT_PCC_STRUCT_RETURN 0 I think gcc didn't override its default of DEFAULT_PCC_STRUCT_RETURN = 1 on i386's meany years ago, since bcc uses this method of returning structs and ISTR copying the gcc behaviour. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RC2 install report, three problems
Hi all, Trying to install 5.0 RC2 on my new laptop, it fails miserably on everything I try. Let me explain the three different problems. 1) ATA problem The laptop has as SIS chipset, and uses a SIS900 ATA controller. Disable ULTRA DMA does help. See this posting with a possible workaround. It would be nice if at least this workaround gets committed to 5.0R. http://www.freebsd.org/cgi/query-pr.cgi?pr=30836 2.) Failing to read MAC adresse, missing PHYS This PR should definitly be committed to 5.0, it's waiting since a long time. Without this patch, all laptop users with integrated nic and a SIS 642 chipset cannot use FreeBSD. http://www.geocrawler.com/archives/3/152/2002/6/0/9065467/ 3.) Unable to install from a Realtec pcmcia card (Realtek RTL8139) The card is properly detected, but it seems that it doesn't get power turned on. Looks like Warner needs to fix something here. All we get here are rl0: watchdog timeout. I'm willing to provide more informations about this issue. I gave up now after a very frustrating session. It seems that I'll have to install over parallel or serial IP connection again. Someone should definitly look at Wpauls PR's and commit the ones that are ready. It looks like work has stalled there for a long time. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GEOM prevents bootblocks writing
Now I can't update my bootblocks to new ones using 'disklabel -B da0s1', checklabel() disklabel function return error preventing actual write with following diagnostic: partition b: partition extends past end of unit partition c: partition extends past end of unit Warning, partition c doesn't start at 0! Warning, An incorrect partition c may cause problems for standard system utilities Warning, partition d: size 0, but offset 32 Warning, partition e: size 0, but offset 32 Warning, partition f: size 0, but offset 32 Warning, partition g: size 0, but offset 32 Warning, partition h: size 0, but offset 32 In fact, this is exact the same diagnostic as from 'disklabel -r da0s1': # /dev/da0s1c: type: SCSI disk: da0s1 label: flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 17500 sectors/unit: 35842016 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 34611200 324.2BSD 2048 1638464 # (Cyl.0*- 16900) b: 1230816 34611232 swap# (Cyl. 16900*- 17500*) c: 35842016 32unused0 0 # (Cyl.0*- 17500*) partition b: partition extends past end of unit partition c: partition extends past end of unit Warning, partition c doesn't start at 0! Warning, An incorrect partition c may cause problems for standard system utilities Warning, partition d: size 0, but offset 32 Warning, partition e: size 0, but offset 32 Warning, partition f: size 0, but offset 32 Warning, partition g: size 0, but offset 32 Warning, partition h: size 0, but offset 32 For comparison see just 'disklabel da0s1' output which indicate no errors and no mysterious offset 32 in the data: # /dev/da0s1c: type: SCSI disk: da0s1 label: flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 17500 sectors/unit: 35842016 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 3461120004.2BSD 2048 1638464 # (Cyl.0 - 16899) b: 1230816 34611200 swap# (Cyl. 16900 - 17500*) c: 358420160unused0 0 # (Cyl.0 - 17500*) Please fix this GEOM bug, to allow to update bootblocks at least. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RC2 install report, three problems
Soeren, 1) ATA problem The laptop has as SIS chipset, and uses a SIS900 ATA controller. Disable ULTRA DMA does help. See this posting with a possible workaround. It would be nice if at least this workaround gets committed to 5.0R. http://www.freebsd.org/cgi/query-pr.cgi?pr=30836 Of course this link belongs to the NIC problem too. The correct link is: http://www.freebsd.org/cgi/query-pr.cgi?pr=43345 Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RC2 install report, three problems
In message: [EMAIL PROTECTED] Martin Blapp [EMAIL PROTECTED] writes: : 3.) Unable to install from a Realtec pcmcia card (Realtek RTL8139) : : The card is properly detected, but it seems that it doesn't get : power turned on. Looks like Warner needs to fix something here. All : we get here are rl0: watchdog timeout. dmesg output here? Looks like there's no interrupts for the card. One other thing to try is to wait until after you've booted to insert the card (and after if_rl.ko is loaded). There's currently a minor problem with doing a kldload if_.ko for a cardbus card that's inserted into the unit and has failed to activate at least once. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RC2 install report, three problems
Hi, dmesg output here? Looks like there's no interrupts for the card. [...] cbb0: PCI-Cardbus Bridge at device 9.0 on pci0 cardbus0: CardBusbus on cbb0 pccard0: 16-bit PCCardbus on cbb0 pci_cfg_intr_virgin: using routable interrupt 4 pci_cfgintr: 0:9 INTA routed to irq 4 cbb1: PCI-Cardbus Bridge at device 9.0 on pci0 cardbus1: CardBusbus on cbb1 pccard1: 16-bit PCCardbus on cbb1 pci_cfg_intr_virgin: using routable interrupt 4 pci_cfgintr: 0:9 INTA routed to irq 4 [...] Manufacuture ID:1b02 Functions: Network adapter, Multi Functions Function extension: 0102 Function extension: 0280969800 Function extension: 0200e1f505 Product Version:5.0 Product Name: Cardbus PC Card Fast Ethernet Cardbus PCCard CIS Reading done: cbb1: Cardbus card activation failed. If I insert the card after probing and loading modules, the system freezes. If I let the card in, I get: rl0: RealTek 8139 10/100BaseTX port 0x1200-0x137f mem 0x88002000 - 0x8800217f irq 4 at device 0.0 on cardbus1 rl0: ethernet address 00:10:60:5a:bb:bd miibus0: MII bus on rl0 rlphy0 RealTek inter media interface on miibus0 The leds are turned of, dhclient fails. If I take the card out the system freezes. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NEWCARD, devd, sio and PCCARD_FUNCTION_SERIAL cards
Dear Warner and Hackers, --- M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Maksim Yevmenkin [EMAIL PROTECTED] writes: : Dear Warner and Hackers, : : Is there any way (on -current with NEWCARD) devd can : prevent sio driver from attaching to *ANY* pc-card : that has PCCARD_FUNCTION_SERIAL? Sure. Just have sio_pccard_match return -100. I've just committed the change to do this. No need to do anything else, I think. Nope :( It does not work. I applied patch to /sys/dev/sio/sio_pccard.c and recompile my kernel with NEWCARD. It seems devd pays no attention when i plug or unplug the 3COM card. I have attached dmesg output and my devd.conf file. I was trying to get devd to kldload ng_bt3c module, but it did not work. Am i missing something obvious here? thanks, max __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com Copyright (c) 1992-2002 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.0-CURRENT #64: Sat Dec 21 16:19:17 PST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/BEETLE Preloaded elf kernel /boot/kernel/kernel at 0xc0463000. Preloaded elf module /boot/kernel/nmdm.ko at 0xc04630a8. Preloaded elf module /boot/kernel/acpi.ko at 0xc0463154. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 597786166 Hz CPU: Pentium III/Pentium III Xeon/Celeron (597.79-MHz 686-class CPU) Origin = GenuineIntel Id = 0x681 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 201195520 (191 MB) avail memory = 190681088 (181 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: TOSHIB 750 on motherboard Using $PIR table, 10 entries at 0xc00f4ee0 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz can't fetch resources for \\_SB_.PCI0.FNC0.PRT1 - AE_BAD_DATA acpi_timer0: 24-bit timer at 3.579545MHz port 0xfe08-0xfe0b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.LNKA irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.11.0 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.11.1 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.9.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.13.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.12.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.5.3 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.15.0 \\_SB_.LNKA irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.16.0 before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - \\_SB_.LNKA irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.11.0 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.11.1 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.9.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.13.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.12.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.5.3 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.15.0 \\_SB_.LNKA irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 0.16.0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 initial configuration \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 1.0.0 before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - \\_SB_.LNKD irq 11: [ 3 4 5 6 7 10 11 12] low,level,sharable 1.0.0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 5.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xfff0-0x at device 5.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xff80-0xff9f irq 11 at device 5.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 5.3 (no driver attached) pci0: unknown at device 9.0 (no driver attached) cbb0: ToPIC100
Re: NEWCARD, devd, sio and PCCARD_FUNCTION_SERIAL cards
In message: [EMAIL PROTECTED] Maksim Yevmenkin [EMAIL PROTECTED] writes: : Dear Warner and Hackers, : : --- M. Warner Losh [EMAIL PROTECTED] wrote: : In message: [EMAIL PROTECTED] : Maksim Yevmenkin [EMAIL PROTECTED] writes: : : Dear Warner and Hackers, : : : : Is there any way (on -current with NEWCARD) devd can : : prevent sio driver from attaching to *ANY* pc-card : : that has PCCARD_FUNCTION_SERIAL? : : Sure. Just have sio_pccard_match return -100. I've just committed : the change to do this. No need to do anything else, I think. : : Nope :( It does not work. I applied patch to /sys/dev/sio/sio_pccard.c : and recompile my kernel with NEWCARD. It seems devd pays no attention : when i plug or unplug the 3COM card. I have attached dmesg output and : my devd.conf file. I was trying to get devd to kldload ng_bt3c module, : but it did not work. Am i missing something obvious here? Yes. You need to have ng_bt3c loaded before you insert the card. That's because of three reasons: 1) We don't detach a device when it 'won' the bidding on the device with a bid 0 when a new driver is loaded. 2) There device is known, so devctl doesn't report anything to devd because it is known (it will report the sio attach). 3) devd ignores all unknown devices at the current time. I'm working on most of these issues, but not the 'rescan' issue. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NEWCARD, devd, sio and PCCARD_FUNCTION_SERIAL cards
Dear Warner and Hackers,
--- M. Warner Losh [EMAIL PROTECTED] wrote:
In message: [EMAIL PROTECTED]
Maksim Yevmenkin [EMAIL PROTECTED] writes:
: :
: : Is there any way (on -current with NEWCARD) devd can
: : prevent sio driver from attaching to *ANY* pc-card
: : that has PCCARD_FUNCTION_SERIAL?
:
: Sure. Just have sio_pccard_match return -100. I've just committed
: the change to do this. No need to do anything else, I think.
:
: Nope :( It does not work. I applied patch to /sys/dev/sio/sio_pccard.c
: and recompile my kernel with NEWCARD. It seems devd pays no attention
: when i plug or unplug the 3COM card. I have attached dmesg output and
: my devd.conf file. I was trying to get devd to kldload ng_bt3c module,
: but it did not work. Am i missing something obvious here?
Yes. You need to have ng_bt3c loaded before you insert the card.
That's because of three reasons:
1) We don't detach a device when it 'won' the bidding on the device
with a bid 0 when a new driver is loaded.
2) There device is known, so devctl doesn't report anything to devd
because it is known (it will report the sio attach).
3) devd ignores all unknown devices at the current time.
I'm working on most of these issues, but not the 'rescan' issue.
Cool. It works if i kldload ng_bt3c before i insert the card.
However i could not get devd to execute proper attach commands
from the config file. It seems devd always wants to execute
/etc/devd-generic {start|stop} device
I took a quick look at the devd sources and could not find the
place where devd calls proper attach commands from the config
file. I saw few XXX comments in process_event() function and
almost convince myself that this is not done yet :) Anyway this
is not a big problem for me :)
thanks,
max
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: NEWCARD, devd, sio and PCCARD_FUNCTION_SERIAL cards
Yes, devd is kinda hardwired at the moment. I have some changes in my tree that I need to finish up before the release. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: ffs_blkfree in recent JPSNAP
'ello all! My 5.0-CURRENT-20021215-JPSNAP system is reliably panic-ing and dropping into the debugger a few minutes after booting. I was in the process of trying to boot 5.0-RC2's installation floppies, and the boot failed due to a faulty floppy. So I told the loader to boot from my root partition on my HDD instead. This produced some error messages about filesystems not being properly dismounted (not sure if that is true...), but booted anyway. Now, every boot from the HDD produces the panics. After being up for a few minutes, the machine panics saying (all messages hand-transcribed): dev=ad0s1e, block=6, fs=/tmp panic: ffs_blkfree: freeing free block Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx, in_Debugger() Unfortunately I don't (yet) know the first thing about how to debug something like this, so for the hell of it I typed trace and got the following (I'm missing out the values inside the ()'s as thats a lot of writing - but I'll report back anything that the developers need to know) : Debugger(...) panic(...) ffs_blkfree(...) indir_trunc(...) handle_workitem_freeblocks(...) process_worklist_item(...) softdep_process_worklist(...) sched_sync(...) fork_exit(...) fork_trampoline(...) If anybody needs more information then please let me know, as I said I have it panic-ing reliably. I guess that booting single-user and then fsck-ing might well fix the problem, but I wanted to take the opportunity to report what is one of the very few panics I've had in many years of FreeBSD usage. And I'm planning to install RC2 on this machine anyway. Thanks! Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
In some email I received from Terry Lambert, sie wrote: Sergey Mokryshev wrote: Darren states that PFIL code was derived from NetBSD so there are no licensing issues. This is Darren Reed's ipfilter.c code, which he will not allow to be distributed modified, and so Theo got all upset and diked it out of OpenBSD , and then wrote a clone of it, right? There *are* licensing issues; it's an issue of interpretation; I can't believe you missed the explosion on the mailing list over the clarification of interpretation Darren posted... I can't believe you missed it all being sorted out in the end :-) (i.e. there is no longer any issue) Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
In some email I received from Terry Lambert, sie wrote: Sergey Mokryshev wrote: I'm really not a fan of NO_PFIL_HOOKS as an option. I'm not talking about NO_PFIL_HOOKS but options PFIL_HOOKS in GENERIC. Too many people may foot shoot themselves trying to upgrade from 4-STABLE to 5.0. If you make them non-optional, which is what started this thread, then you *are* talking about having to add an option in to get rid of them. Seriously, Terry, how many NO_foo options exist, today ? I understand that people all want their pet software to run out of the box without modification. I'm not the one who wants that, it's people who USE FreeBSD. You remember users, don't you Terry ? :) Probably the correct thing to do is to wire in ipfilter as a Netgraph module. AFAIK Solaris, HP-UX and others lack Netgraph support, but support pfil. They support Streams, instead. Same ecological niche. That's STREAMS thank you very much! I'll talk more on that point in another email. Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
In some email I received from Terry Lambert, sie wrote:
[...]
The original posting in this thread gave a patch to unconditionalize
the PFIL_HOOKS thing, so that the ipfilter module could load on a
default kernel, without having to do a reasonable amount of work.
ipfilter being the only code that currently uses that mechanism.
At least I think it's a better approach than using the LKM hooks
present in FreeBSD prior to 5.x
My response to that was that you could create accessor/mutator
functions which were always defined, but not always functional.
By using these functions, instead of trying to access the pointers
directly, there are no undefined symbols, and you get the specific
error message, rather than the generic: any message you want it to
print.
That doesn't work when ipfilter is compiled outside of the kernel
build directory (as often happens), where it is going to be unaware
of whether or not PFIL_HOOKS has been defined for the kernel.
The real reason is that the
people complaining don't want to have to recompile the kernel to
use the ipfilter module:
That or any other module that uses the pfil(9) interface.
the complaint was because they wanted it
to be resolved in a particular way, so that they got a result that
they weren't willing to ask for directly. Solving the first one
left them unhappy.
But compiling the kernel with the hooks in place is not the only
way to solve the problem.
It is a better step forward than the proposal I've seen you put
forward about accessor hooks and having them prevent the obscure
modload error message.
The purpose of pfil(9) is not to facilitate ipfilter but to act
as a mechanism for anything to filter packets to use it as the
way to receive packets. Ideally ipfw* should also use pfil(9)
and not have those large chunks of code in ip_{in,out}put.c.
Yeah, that's the reason that BPF and netgraph and streams and ...
were invented, too. Wouldn't it be great if everyone adopted the
API I like best? 8-) 8-).
Terry, did you have any hand in writing netgraph ? I've seen hardly
anyone else put their hand up in favour of it so I'm suspecting a
certain amount of bias here :-) :)
Well, for BPF it works. Lots of devices have bpf_*tap()s in them
and nobody bothers about the overhead from that.
For STREAMS you don't need to do anything.
I suppose I'm trying to push pfil(9) into the same kind of role as
BPF.
Probably the correct thing to do is to wire in ipfilter as a
Netgraph module.
If/when the joining between layer 2 and layer 3 in the kernel
uses netgraph rather than the current mechanisms, then it would
be appropriate to use netgraph for ipfilter.
That's not a good demand; here's why: There are two types of
data paths: (1) the fast path, and (2) the path for research and
for things that are going to be slow anyway, by their nature.
Well, let me describe how ipfilter works in a STREAMS environment,
or rather, how version 4.0 of ipfilter works.
To separate the STREAMS gunk out of ipfilter (or as much as possible)
I wrote an equivalent of pfil(9) for HP-UX 11/Solaris. That is a
STREAMS module that gets push'd onto the network device before the
IP module does so all IP traffic goes through pfil(9). IPFilter
registers with pfil(9) to intercept the packets that would otherwise
be going straight through it to the IP routines.
For it to be worthwhile to use netgraph on FreeBSD, FreeBSD would need
to be re-engineered such that the linkage between layer 2 devices (all
of the ethernet cards, etc) and layer 3 code (ip, ipv6, etc) was done
through netgraph - or at least that's how I see it. From a security
perspective that's definately how I'd want it to be - the filtering
as the middle man, not some inspector hanging off the side somewhere.
The ipfilter code is in the second category.
It's really bogus to insist that everything take the slow path
because something slow has to take the slow path.
I think you're missing the point about why people want everything to
take the slow path. People are using it for security and when you're
doing that, there is no fast path or slow path, there is only a
secure path.
btw, I did make an effort to read how to use netgraph and I'm shocked.
It looks like even more effort to use than STREAMS and not in a good
way either.
Darren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Again (panic: Duplicate free of item 0xfffffc00069199e0 from zone 0xfffffc0007d31800(VMSPACE))
Unfortunately I just had another panic on alpha: Slab at 0xfc0006919fb8, freei 18 = 0. panic: Duplicate free of item 0xfc00069199e0 from zone 0xfc0007d31800(VMSPACE) db_print_backtrace() at db_print_backtrace+0x18 panic() at panic+0x104 uma_dbg_free() at uma_dbg_free+0x170 uma_zfree_arg() at uma_zfree_arg+0x150 vmspace_free() at vmspace_free+0xe4 swapout_procs() at swapout_procs+0x428 vm_daemon() at vm_daemon+0x74 fork_exit() at fork_exit+0x100 exception_return() at exception_return --- root of call graph --- panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 db This is with the patch committed by dillon a few days ago. FreeBSD axp4.FreeBSD.org 5.0-RC FreeBSD 5.0-RC #0: Wed Dec 18 20:53:06 PST 2002 [EMAIL PROTECTED]:/local0/obj/alpha/a/asami/portbuild/alpha/src-client/sys/NETBOOT alpha Kris msg49199/pgp0.pgp Description: PGP signature
Re: Again (panic: Duplicate free of item 0xfffffc00069199e0 from zone 0xfffffc0007d31800(VMSPACE))
On Sat, Dec 21, 2002 at 09:49:40PM -0800, Kris Kennaway wrote: This is with the patch committed by dillon a few days ago. FreeBSD axp4.FreeBSD.org 5.0-RC FreeBSD 5.0-RC #0: Wed Dec 18 20:53:06 PST 2002 [EMAIL PROTECTED]:/local0/obj/alpha/a/asami/portbuild/alpha/src-client/sys/NETBOOT alpha Oops, I assumed this patch was already MFCed, when it was only done so tonight..I was running a RELENG_5_0 kernel here, looks like. Kris msg49200/pgp0.pgp Description: PGP signature
script bug: rc.sendmail
To disable sendmail, one expects to set sendmail_enable=NO in /etc/rc.conf. /etc/rc.sendmail looks for sendmail_enable=[Nn][Oo][Nn][Ee] (should be [Nn][Oo] to conform with standard usage.) The consequence is that an administrator may intend to disable sendmail, but it will still be enabled. g. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: script bug: rc.sendmail
On Sun, Dec 22, 2002 at 12:06:02AM -0600, Geoffrey T. Falk wrote: To disable sendmail, one expects to set sendmail_enable=NO in /etc/rc.conf. /etc/rc.sendmail looks for sendmail_enable=[Nn][Oo][Nn][Ee] (should be [Nn][Oo] to conform with standard usage.) The consequence is that an administrator may intend to disable sendmail, but it will still be enabled. man rc.sendmail -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: GCC ABI breakage
An undetected change in GCC 3.2.1-release sources, imported on December 4th, 2002, effectively caused an ABI change on FreeBSD/i386 5.x. The change in GCC source is believed to be a bug and the issue will be brought to attention of GCC developers. Necessary changes to bring our traditional calling convention back have been applied to both CURRENT and RELENG_5_0 branch. Unfortunately, this means that all the software, compiled during the breakage window and which is using functions returning structs by value, will have to be recompiled. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
