Dr Neuhaus niccy go not recognized
During make of kernel: cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../i4b/layer1/i4b_isic_pnp.c ../../i4b/layer1/i4b_isic_pnp.c:53: warning: #warning "Fix i4b pnp!" Is this a "simple" matter of the right options to config, or does it involve changes to the code? Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #130: Sat Nov 6 18:14:11 CET 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/GINA Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (337.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 67096576 (65524K bytes) avail memory = 61603840 (60160K bytes) Preloaded elf kernel "kernel" at 0xc0357000. VESA: v2.0, 4096k memory, flags:0x1, mode table:0xc00c0e38 (ce38) VESA: S3 Incorporated Trio3D. Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 vga-pci0: S3 model 8904 graphics accelerator at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX4 IDE controller at device 4.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller irq 9 at device 4.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ugen0: vendor 0x0553 product 0x0002, rev 1.00/1.00, addr 2 intpm0: Intel 82371AB Power management controller at device 4.3 on pci0 intpm0: I/O mapped e800 intpm0: intr IRQ 9 enabled revision 0 smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped e400 pcm0: AudioPCI ES1370 irq 5 at device 11.0 on pci0 ed1: NE2000 PCI Ethernet (RealTek 8029) irq 10 at device 12.0 on pci0 ed1: address 00:80:ad:50:40:cf, type NE2000 (16 bit) fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 pca0 at port 0x40 on isa0 pca0: PC speaker audio driver unknown0: ISDN PnP ISA pass. Adaptor DNT2039 at port 0x200-0x201,0x202-0x203 irq 11 on isa0 i4b: ISDN call control device attached i4bisppp: 4 ISDN SyncPPP device(s) attached i4bctl: ISDN system control port attached i4bipr: 4 IP over raw HDLC ISDN device(s) attached (VJ header compression) i4btel: 2 ISDN telephony interface device(s) attached i4brbch: 4 raw B channel access device(s) attached i4btrc: 2 ISDN trace device(s) attached ad0: ST38641A/3.11 ATA-4 disk at ata0 as master ad0: 8207MB (16809660 sectors), 16676 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 0 depth queue, UDMA33 Creating DISK ad0 Creating DISK wd0 ad1: IBM-DTTA-350640/T54OA73A ATA-4 disk at ata0 as slave ad1: 6197MB (12692295 sectors), 13431 cyls, 15 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 31 depth queue, UDMA33 Creating DISK ad1 Creating DISK wd1 Mounting root from ufs:/dev/wd1s3a To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: doscmd broken on current?
Is doscmd working for anyone on current? Here I just get: - I have tried it on a single processor and SMP -current and both do the same thing. I had it working a while back, so I think my configuration is ok. Ideas on how to look into this? Start by invoking it with the various debug/trace options. I'd guess that it may be broken by the signal-related changes that were made recently. hehehe It dies at the very first vm86 instruction, so I guess something isn't setup correctly to enter vm86 mode via the sigreturn(): I bet that someone got smart and disallowed PSL_VM in eflags on a return to user-mode. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: doscmd broken on current?
John Hay wrote: Hmmm I see the sigreturn man page hasn't been updated, it still says that sigreturn takes a struct sigcontext * argument, while the signal.h file says it takes ucontext_t *. Sigreturn still takes a struct sigcontext*. It also takes a ucontext_t. I think the header should define sigreturn to take a struct sigcontext*... -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: show stopper for Gcc 2.95.2 conversion
"David O'Brien" writes: On Sat, Nov 06, 1999 at 10:34:18AM +0100, Gary Jennejohn wrote: Here's a patch to bus.h which works for both EGCS and GCC 2.95.2. I have Here is the patch I've been working on (before I 1st got BDE's reply). The changes are mostly from OpenBSD + style changes for the way we do things. Can you also test this one? [patch snipped] This patch also works with both compilers. Seems kind of hairy, though. Any idea why GCC 2.95.2 produces so much more code ? # ls -l /kernel*gc* -rwxr-xr-x 1 root wheel 1753591 Nov 7 10:50 /kernel.egcs* -rwxr-xr-x 1 root wheel 1788387 Nov 7 10:57 /kernel.gcc* well, it's not all that much more. --- Gary Jennejohn Home - [EMAIL PROTECTED] Work - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stuck with ~year old current
Taavi Talvik wrote: Only alternative to get these from outside is to upgrade graduall.. but who knows which intermediate source repository dates are good for it? Mike once said (and, ergo, can be found on the mailing list archives): "We do not support upgrading to -current from anything else than the latest -stable." There's your answer. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] What y'all wanna do? Wanna be hackers? Code crackers? Slackers Wastin' time with all the chatroom yakkers? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stuck with ~year old current
"Daniel C. Sobral" wrote: Taavi Talvik wrote: Only alternative to get these from outside is to upgrade graduall.. but who knows which intermediate source repository dates are good for it? Mike once said (and, ergo, can be found on the mailing list archives): "We do not support upgrading to -current from anything else than the latest -stable." Does this still hold after the recent signal changes ? TfH (I assume Yes, if one first upgrade the kernel, then the world) There's your answer. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] What y'all wanna do? Wanna be hackers? Code crackers? Slackers Wastin' time with all the chatroom yakkers? 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: Serious locking problem in CURRENT
On Sat, Nov 06, 1999 at 01:29:16PM -0600, Jonathan Lemon wrote: From the manual page for flock: NOTES Locks are on files, not file descriptors. That is, file descriptors du- plicated through dup(2) or fork(2) do not result in multiple instances of a lock, but rather multiple references to a single lock. If a process holding a lock on a file forks and the child explicitly unlocks the file, the parent will lose its lock. Doesn't this make it impossible to hold a lock on a file when you want to fork a child to do some task 'cos the lock will be dropped when the child closes its copy of the file discriptor on exit? Either it's a posix goof or the lock shouldn't be let go until either explicitly released or the last instance of the file discriptor is closed? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious locking problem in CURRENT
On Sun, Nov 07, 1999 at 02:01:02AM +0100, Ollivier Robert wrote: Right but in Postfix case this is not the case. The "master" process run to check whether Postfix is running or not is definitely NOT a child of the real "master" process. But if the real master process forks and then it's child closes the fd which the lock was on, then the master process will have lost it's lock. Is this likely? Does the real master fork children to do stuff? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stuck with ~year old current
Lauri Laupmaa wrote: On Fri, 5 Nov 1999, Michael Reifenberger wrote: The flag is probably -fformat-extensions so eliminate it from /usr/share/mk/bsd.kern.mk. Then build linker/kernel/world. Thank you all who replied! The trick was to take new loader from running system, because it was impossible to build one with old gcc... Impossible is a little bit too harsh. I do it all the time on freefall, which runs -stable. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] What y'all wanna do? Wanna be hackers? Code crackers? Slackers Wastin' time with all the chatroom yakkers? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stuck with ~year old current
Thierry Herbelot wrote: Mike once said (and, ergo, can be found on the mailing list archives): "We do not support upgrading to -current from anything else than the latest -stable." Does this still hold after the recent signal changes ? TfH (I assume Yes, if one first upgrade the kernel, then the world) You assume correctly. -stable loader can load -current kernel. Well, it could until very recently. I don't know if the new stuff Mike is doing will introduce any incompatibility. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] What y'all wanna do? Wanna be hackers? Code crackers? Slackers Wastin' time with all the chatroom yakkers? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP sockets stuck in the CLOSING state
[bringing this back to -current, with a Bcc to -security] "Kenneth D. Merry" [EMAIL PROTECTED] writes: Jonathan Lemon wrote... In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Before I spend a lot of time hunting this down, I figured it might be worth asking -- is there any particular reason why TCP sockets may be getting stuck in the CLOSING state more often now? Not sure. But here's a tcpdump trace of a socket that ends up in the CLOSING state. (on the host ``cache''). [...] 1. the other end (folly) never acks the FIN. The packets at timestamp .492154 and .492160 do not cover the FIN in the sequence space. Yet the host `folly' closes the socket. This is weird, and probably deserves some investigation (at least if cache and folly are on the same LAN; otherwise there's a non-zero possibility of the ACK simply getting lost on the way) 2. the end that is stuck in CLOSING (cache) never retransmits the FIN. (The tcpdump extends for about 5 minutes after the last packet, with 0 packets lost). It's not supposed to (according to RFC793). Both machines are running -current from early this week. Those are definitely odd. After looking through the changes since June, I think (and DES seems to agree) that the problems are most likely in your timeout code from August. Most every other change in the TCP stack has been cosmetic, or #ifdefed, so it wouldn't be enabled by default. He is going to try to find the problem, although it's most likely a pretty subtle bug. Well, the TCP state machine was never a fun read, amd I haven't had time to look very closely at the problem yet, but it seems that there is no way for a connection to leave the TCPS_CLOSING state other than the receipt of an ACK matching a previously sent FIN. If the ACK gets lost, the connection is stuck in TCPS_CLOSING forever (I have a connection that's been stuck in TCPS_CLOSING for at least three days now). The only instance I can find where a connection in TCPS_CLOSING state is closed even if no ACK has been received is when the socket has the SO_KEEPALIVE option set (tcp_timer_keep() in tcp_timer.c). Note that the state transition diagram in RFC793 does not specify a timeout for the CLOSING - TIME_WAIT transition, so any faithful implementation of RFC793 has this bug (but why doesn't this happen on -STABLE, or on pre-August -CURRENT?) This hints at a potential DoS vulnerability. Hack a TCP stack to never acknowledge FIN segments, and blast away at your victim; chances are he'll run out of mbufs before you run out of source ports (each source port can only be used once in the attack). Give me a few hours and I might be able to verify this vulnerability experimentally. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dr Neuhaus niccy go not recognized
From the keyboard of Charlie ROOT: During make of kernel: cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../i4b/layer1/i4b_isic_pnp.c ../../i4b/layer1/i4b_isic_pnp.c:53: warning: #warning "Fix i4b pnp!" Is this a "simple" matter of the right options to config, or does it involve changes to the code? PnP support for i4b in -current was disabled during the conversion of -current to the new-bus/new-pnp architecture; as a result all PnP ISDN cards i4b supports do no longer work. hellmuth -- Hellmuth MichaelisTel +49 40 559747-70 HCS Hanseatischer Computerservice GmbHFax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: doscmd broken on current?
Is doscmd working for anyone on current? Here I just get: - I have tried it on a single processor and SMP -current and both do the same thing. I had it working a while back, so I think my configuration is ok. Ideas on how to look into this? Start by invoking it with the various debug/trace options. I'd guess that it may be broken by the signal-related changes that were made recently. hehehe It dies at the very first vm86 instruction, so I guess something isn't setup correctly to enter vm86 mode via the sigreturn(): I bet that someone got smart and disallowed PSL_VM in eflags on a return to user-mode. Nope it wasn't that bad. I'm not sure if this is the correct fix, but with this patch I can boot dos again. Can someone with more knowledge of the signal stuff look and say if this is correct/enough? The redirector don't work though. I just get a "File not Found" error when trying to dir any of the redirected directories. John -- John Hay -- [EMAIL PROTECTED] Index: doscmd.c === RCS file: /home/ncvs/src/usr.bin/doscmd/doscmd.c,v retrieving revision 1.11 diff -u -r1.11 doscmd.c --- doscmd.c1999/10/13 23:48:35 1.11 +++ doscmd.c1999/11/07 12:50:06 @@ -258,6 +258,7 @@ sigemptyset(uc.uc_sigmask); sigaltstack(NULL, uc.uc_stack); +uc.uc_mcontext.mc_onstack = uc.uc_stack.ss_flags; if (tmode) tracetrap(REGS); To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP sockets stuck in the CLOSING state
On Nov 11, 1999 at 01:41:48PM +0100, Dag-Erling Smorgrav wrote: [bringing this back to -current, with a Bcc to -security] "Kenneth D. Merry" [EMAIL PROTECTED] writes: Jonathan Lemon wrote... In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: Before I spend a lot of time hunting this down, I figured it might be worth asking -- is there any particular reason why TCP sockets may be getting stuck in the CLOSING state more often now? Not sure. But here's a tcpdump trace of a socket that ends up in the CLOSING state. (on the host ``cache''). [...] 1. the other end (folly) never acks the FIN. The packets at timestamp .492154 and .492160 do not cover the FIN in the sequence space. Yet the host `folly' closes the socket. This is weird, and probably deserves some investigation (at least if cache and folly are on the same LAN; otherwise there's a non-zero possibility of the ACK simply getting lost on the way) Good point. I'll try taking a tcpdump on both sides to see if the ACK is getting lost, or if it just isn't getting sent at all. Note that the state transition diagram in RFC793 does not specify a timeout for the CLOSING - TIME_WAIT transition, so any faithful implementation of RFC793 has this bug (but why doesn't this happen on -STABLE, or on pre-August -CURRENT?) I'm not sure abuot that one. But I've just committed a fix to tcp_fsm.h, which will cause it to re-transmit a FIN in CLOSING state. The FIN was originally taken out by Garrett in rev 1.5, and restored by dg in rev 1.6. However, it was re-removed in 1.10 when Garrett made a large commit, presumably he hadn't taken it out of his local tree. It fixes the problem here (at least, I can't replicate the problem any more). I'm not sure if I'm fixing the symptoms rather than the actual problem then, though. NetBSD has the same fix in their tree as well. I'm pretty sure that I've seen this problem on -current going back as early as March as well. This hints at a potential DoS vulnerability. Hack a TCP stack to never acknowledge FIN segments, and blast away at your victim; chances are he'll run out of mbufs before you run out of source ports (each source port can only be used once in the attack). Give me a few hours and I might be able to verify this vulnerability experimentally. Do let me know if this is the case. I was considering this last night, but was too tired to try an figure out how to generate a TCP stream that would ACK everything but the FIN. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious locking problem in CURRENT
David Malone wrote:
On Sat, Nov 06, 1999 at 01:29:16PM -0600, Jonathan Lemon wrote:
From the manual page for flock:
NOTES
Locks are on files, not file descriptors. That is, file descriptors du-
plicated through dup(2) or fork(2) do not result in multiple instances of
a lock, but rather multiple references to a single lock. If a process
holding a lock on a file forks and the child explicitly unlocks the file,
the parent will lose its lock.
Doesn't this make it impossible to hold a lock on a file when you
want to fork a child to do some task 'cos the lock will be dropped
when the child closes its copy of the file discriptor on exit?
Either it's a posix goof or the lock shouldn't be let go until
either explicitly released or the last instance of the file discriptor
is closed?
The lock doesn't seem to be released until *explicitly* released, like
the manual page says. I don't think closing the descriptor counts as
an explicit unlock, though I am probably wrong. Run this program,
you'll see the parent still has the lock. Change close(fd) to flock(fd,
LOCK_UN) and you'll see it doesn't. It's possible I've misunderstood
something though.
#include fcntl.h
#include err.h
#include stdio.h
#include unistd.h
int
main(void) {
int fd;
fd = open("lock", O_CREAT|O_RDWR, 0600);
if (fd 0)
err(1, "open");
if (flock(fd, LOCK_EX) != 0)
err(1, "flock");
switch (fork()) {
case -1:
err(1, "fork");
case 0:
close(fd);
_exit(0);
default:
sleep(2);
break;
}
system("lsof | less");
return (0);
}
--
Ben Smithurst| PGP: 0x99392F7D
[EMAIL PROTECTED] | key available from keyservers and
| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ESS 1868 driver, again
Peter Wemm wrote: As to why the 1869 isn't working for you, that's anybody's guess. You might try posting the 'dmesg' output (not from syslog) and your complete config file, as well as any other pertinant information you can think of. Ok here is the (hopefully) complete information. -current cvsupped ~2 hours ago. If seems there will no interrupts be generated. If I try to play something, nothing happens, if I run "vmstat -i" then, there are 0 interrupts for irq 5 (pcm0). Daniel kernel config file: machine i386 ident LAPTOP maxusers6 options PQ_LARGECACHE cpu I686_CPU options COMPAT_43 options SYSVSHM options SYSVSEM options SYSVMSG options MD5 options DDB options KTRACE options PERFMON options UCONSOLE options INET pseudo-device ether pseudo-device loop pseudo-device bpf pseudo-device tun options ICMP_BANDLIM options FFS options NFS options NFS_NOSERVER options CD9660 options MSDOSFS options PROCFS options FFS_ROOT options SOFTUPDATES options QUOTA options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L controller scbus0 device da0 device pass0 pseudo-device pty options MSGBUF_SIZE=20480 controller isa0 controller pnp0 options PNPBIOS controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 options ATKBD_DFLT_KEYMAP makeoptions ATKBD_DFLT_KEYMAP="german.iso" device psm0at atkbdc? irq 12 options PSM_HOOKAPM options PSM_RESETAFTERSUSPEND device vga0at isa? port ? conflicts options VGA_WIDTH90 options VESA pseudo-device splash device sc0 at isa? options MAXCONS=6 options SC_DFLT_FONT makeoptions SC_DFLT_FONT=iso options SC_PIXEL_MODE device npx0at nexus? port IO_NPX flags 0x0 irq 13 controller ata0 device atadisk0 device atapicd0 options ATA_ENABLE_ATAPI_DMA controller fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device sio0at isa? port IO_COM1 flags 0x10 irq 4 device sio1at isa? port IO_COM2 irq 3 device ed0 device pcm0 device apm0at nexus? device joy0at isa? port IO_GAME controller pci0 controller pcic0 at isa? irq 10 controller pcic1 at isa? irq 10 controller card0 options PCIC_RESUME_RESET controller ppbus0 controller vpo0at ppbus? device lpt0at ppbus? device ppi0at ppbus? device ppc0at isa? port? irq 7 drq 3 controller uhci0 controller usb0 device ugen0 options HZ=500 dmesg output of verbose boot: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #241: Sun Nov 7 13:48:17 CET 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/ROCK Calibrating clock(s) ... TSC clock: 232125177 Hz, i8254 clock: 1193284 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium II/Xeon/Celeron (232.11-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 67108864 (65536K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x002ef000 - 0x03ffafff, 64012288 bytes (15628 pages) avail memory = 62169088 (60712K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f66a0 bios32: Entry = 0xfd7e0 (c00fd7e0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x203 pnpbios: Found PnP BIOS data at 0xc00f66d0 pnpbios: Entry = f:a62f Rev = 1.0 Other BIOS signatures found: ACPI: VESA: information block 56 45 53 41 00 02 6b 00 00 c0 00 00 00 00 f6 8c 00 c0 10 00 00 00 b4 27 00 c0 b5 27 00 c0 b6 27 00 c0 b7 27 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 11 mode(s) found VESA: v2.0, 1024k memory, flags:0x0, mode table:0xc00c8cf6 (c0008cf6) VESA: Copyright 1994 TRIDENT MICROSYSTEMS INC. VESA: Pentium Pro MTRR support enabled pci_open(1):mode 1 addr port (0x0cf8) is 0x80001010 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71928086) npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2
Re: sio working
Warner Losh wrote: In message [EMAIL PROTECTED] "D. Rock" writes: : device sio0at isa? port IO_COM1 flags 0x10 irq 4 : device sio1at isa? port IO_COM2 irq 3 These look good. IIRC, the kernel I tested with also had: device sio2at isa? port IO_COM3 irq 5 disabled or device sio2 in it, but I may be misremembering. Just make sure that you use the config entry that gives you a port at 0x3e8, since most laptops have COM1 and COM2 which really cannot be disabled (well, the BIOS says you can disable them, but I've seen a few where the BIOS disabling is broken). Already did that. I used a config entry for 0x3e8 and one for 0x2e8. Windows 98 configured the card for IRQ 11 I/O 0x3e8 BTW. Just some more pccard questions: When will removing cards (and therefor also suspend/resume) work again? If I remove the netcard or suspend the machine, the system will freeze. I also get a NMI if I insert my netcard (DLink DE-660). If DDB is compiled in I can just continue. Interesting the NMI wasn't generated during initial configuration (via DHCP), but when I tried some ping tests: pccard: card inserted, slot 0 sio2: irq maps: 0x105 0x105 0x105 0x105 sio2: probe failed test(s): 0 1 4 6 7 9 sio2: irq maps: 0x105 0x105 0x105 0x105 sio2: probe failed test(s): 0 1 4 6 7 9 pccard: card inserted, slot 1 ed0 at port 0x240-0x25f irq 15 slot 1 on pccard0 ed0: address 00:80:c8:8b:66:e9, type NE2000 (16 bit) bpf: ed0 attached NMI ... going to debugger ( [the first two sio2 lines were with config index for port 0x3e8, the other ones with config index for 0x2e8] Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dr Neuhaus niccy go not recognized
From the keyboard of Leif Neland: PnP support for i4b in -current was disabled during the conversion of -current to the new-bus/new-pnp architecture; as a result all PnP ISDN cards i4b supports do no longer work. Anybody working on re-enabling it, and if so, any time-horisonts? Yes, no. I still hope documentation for the new-bus, new-pnp architecture will be made available at sufficient time before 4.0-RELEASE code freeze. hellmuth -- Hellmuth MichaelisTel +49 40 559747-70 HCS Hanseatischer Computerservice GmbHFax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dr Neuhaus niccy go not recognized
On Sun, Nov 07, 1999 at 03:16:48PM +0100, Leif Neland wrote: PnP support for i4b in -current was disabled during the conversion of -current to the new-bus/new-pnp architecture; as a result all PnP ISDN cards i4b supports do no longer work. Anybody working on re-enabling it, and if so, any time-horisonts? Depends on which card you use. I have attempted to do the conversion for some cards. You are welcome to test it, but don't expect it to work out of the box, I don't have the hardware to test it. It works for the hardware I have access to. If the code will be brought into i4b at all, it will not be before the i4b-PCI card code has been converted too and the concept and code is sophisticated enough for Hellmuth to accept it (and from what he wrote before, that won't be before there is other documentation than RTSL for the newbus system) . Some other people have shown interest in converting the PCI code. If it takes time I won't blame them, I don't have any spare time until mid january either. -- German Tischler, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious locking problem in CURRENT
On Sat, 6 Nov 1999, Dmitrij Tejblum wrote: Brian Fundakowski Feldman wrote: There were zero comments about what order things happen in; in fact, the ordering in this case is Just Plain Lame (TM). It's much more correct to explicitly check for fp-f_count == 1. Not sure what you mean. The commit clearly states that POSIX and BSD locking intentionally handled in different ways here. Frankly, I see nothing lame in the ordering. The second VOP_ADVLOCK just should be moved to fdrop(). Yes, but you implied that there was some part of the commenting that I must have missed in rev.1.68, but there was nothing about that. I think I'll get an okay from bruce and move the unlock to fdrop(); I have still been pondering which is more correct, actually. BTW, I have another little concern with that commit: It make possible for last close() of a file descriptor to return 0 instead of the error from VOP_CLOSE(), and the error from VOP_CLOSE() to be ignored. When a process do closef() on a descriptor "held" by another process (by fhold(), e.g. the process do read() on the descriptor), it will just return 0 without the call to fo_close(). Then, when the other process drop the descriptor, fdrop() call fo_close() but the error is thrown away. No? Yes, this is what I thought you could have meant. But would you rather lose that error in a corner case or do locking on the fd/fdtable or just let the system crash in that case? I'm open for a better solution. Dima -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libvgl - status and perspectives
-On [19991106 04:01], Andrzej Bialecki ([EMAIL PROTECTED]) wrote: Today I noticed accidentally that either libvgl is broken, or the demo program does something wrong - the mouse cursor doesn't move. But this brings more general question regarding console graphics library. As it is today, libvgl is almost useless due to very limited set of functions. There were discussions whether to port SVGAlib or GGI. Do you know if someone is working/planning to work on it? libggi has more support for FreeBSD than svgalib has and it also seems to be preferred over svgalib due to security hassles and all that. So you might want to try that route. -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best In every stone sleeps a crystal... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious locking problem in CURRENT
According to David Malone: But if the real master process forks and then it's child closes the fd which the lock was on, then the master process will have lost it's lock. Is this likely? Does the real master fork children to do stuff? All the time. "master" is an inetd-like daemon which spawn children according to master.cf. Everything run by Postfix is a child of "master"... I see your point and that's likely what happen. You're confirming what I thought about locking brokeness. That's bad. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #75: Tue Nov 2 21:03:12 CET 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new home directory for daemon
Problem: ~daemon/tmp should not be the same directory as ~root/tmp/ Suggestion: new home directory: daemon:*:1:1::0:0:Owner of many system processes:/daemon:/sbin/nologin + extend BSD.root.dist to create ~daemon/tmp Given existing current/src/: etc/master.passwd: root::0:0::0:0:Charlie :/root:/bin/csh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin etc/group: wheel:*:0:root daemon:*:1:daemon etc/BSD.root.dist: .. root .. (but no root/tmp created) So assuming a manually created secure private /root/tmp with owner root, group wheel, mode 700 This was just posted to the list, rather than made a send-pr, as I guess there may be better solutions ... Any Comments / Improvements ? -- Julian Stacey www.freebsd.org/~jhs/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stuck with ~year old current
"We do not support upgrading to -current from anything else than the latest -stable." Does this still hold after the recent signal changes ? TfH (I assume Yes, if one first upgrade the kernel, then the world) You assume correctly. -stable loader can load -current kernel. Well, it could until very recently. I don't know if the new stuff Mike is doing will introduce any incompatibility. The last incompatibility was around March or so, when the load address of the kernel changed. Anything postdating that is basically equi-functional. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: doscmd broken on current? fixed
Ok, with these patches doscmd is working for me again. I can boot dos and
run the topspeed C compiler like I used to a few months ago.
If nobody has any complaints I'll commit it. I'm just not 100% sure about
the patch to doscmd.c and would like if someone with more knowledge about
the signal stuff would just look at it. There is just too many signal
related functions and structures and it isn't always clear (to me at least)
what should be filled in for whom.
John
--
John Hay -- [EMAIL PROTECTED]
Index: cwd.c
===
RCS file: /home/ncvs/src/usr.bin/doscmd/cwd.c,v
retrieving revision 1.5
diff -u -r1.5 cwd.c
--- cwd.c 1999/10/12 22:20:18 1.5
+++ cwd.c 1999/11/07 18:59:06
@@ -198,7 +198,7 @@
u_char *np;
Path_t *d;
u_char tmppath[1024];
-u_char snewpath = newpath;
+u_char *snewpath = newpath;
if (where[0] != '\0' where[1] == ':') {
drive = drlton(*where);
@@ -253,7 +253,7 @@
} else {
if (np[-1] != '\\')
*np++ = '\\';
- while (*np = *dir++ np - snewpath 1023)
+ while ((*np = *dir++) np - snewpath 1023)
++np;
}
}
Index: doscmd.c
===
RCS file: /home/ncvs/src/usr.bin/doscmd/doscmd.c,v
retrieving revision 1.11
diff -u -r1.11 doscmd.c
--- doscmd.c1999/10/13 23:48:35 1.11
+++ doscmd.c1999/11/07 12:50:06
@@ -258,6 +258,7 @@
sigemptyset(uc.uc_sigmask);
sigaltstack(NULL, uc.uc_stack);
+uc.uc_mcontext.mc_onstack = uc.uc_stack.ss_flags;
if (tmode)
tracetrap(REGS);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: show stopper for Gcc 2.95.2 conversion
"Daniel C. Sobral" writes: Gary Jennejohn wrote: Any idea why GCC 2.95.2 produces so much more code ? Mmmm... O'Brien, could you make sure the space-critical code in sys/boot compiles ok? I still have GCC 2.95.2 installed. This is what I get in /sys/boot: === i386/boot2 (cd /usr/src/sys/boot/i386/boot2; m4 -DFLAGS=0 boot1.m4 boot1.s) | as -o boot1.o ld -nostdlib -static -N -e start -Ttext 0x7c00 -o boot1.out boot1.o objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 2/dev/null cc -elf -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -fno-builtin -Os -malign-functions=0 -malign-jumps=0 -malign-loops=0 -mrtd -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -c boot2.c (cd /usr/src/sys/boot/i386/boot2; m4 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 sio.s) | as -o sio.o ld -nostdlib -static -N -Ttext 0x1000 -o boot2.out /usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x1000 -f bin -b /usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.01 size=700 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=15c0 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1ec0 text=200 data=1cc0 org=0 entry=0 -192 bytes available --- Gary Jennejohn Home - [EMAIL PROTECTED] Work - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new sigaction struct
Marcel, Just curious as to what the motivation for re-ordering the sa_flags and sa_mask members in sigaction were? The manpage still describes the old order BTW. My Alpha box has been limping through a package build and I've noticed a number of ports that seem to be falling over for signal-related changes. One in particular would be the rawio port which expects sa_mask to be before sa_flags in struct sigaction. Thanks. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious locking problem in CURRENT
On Sun, 7 Nov 1999, David Malone wrote: The lock doesn't seem to be released until *explicitly* released, like the manual page says. I don't think closing the descriptor counts as an explicit unlock, though I am probably wrong. Run this program, you'll see the parent still has the lock. Change close(fd) to flock(fd, LOCK_UN) and you'll see it doesn't. It's possible I've misunderstood something though. On -current it seems to be unlocking regardless - which I think it the problem. If you have to explicitly unlock then that seems fine. There is something broken in -CURRENT with file locking since I've experienced this with sendmail 8.9.3. I compared this to a 3.3-RELEASE machine running sendmail 8.9.3 and it doesn't exhibit the same problem. You can do a little test of the file locking, might be a bit tricky if you have a busy system, but it would be interesting to see the result: Run sendmail with -bd -q1m Send a message to an "unused" IP address on your local network, e.g. date | sendmail 'nobody@[123.123.123.123]' (substitute an appropriate IP address of course). This should have the (backgrounded) original sendmail process sitting waiting with the queue file locked for just over one minute, so you need to hurry a bit with the rest: Run 'mailq' - does this message have a '*' in the first column (it should)? Take the queue ID for the message - shown in the first column of mailq output (immediately following the '*', if any) - say XAA01234, and do a verbose queue run for just that ID: sendmail -v -qIXAA01234 (substituting the queue ID you got of course, i.e. -qIyourID) - this should just print Running XAA03875 (sequence 1 of 1) XAA03875: locked and then exit - does it? From the above tests, the file locking does work in general. However, it could still be a race condition. Here's another test, which will be more of the sendmail situation: Create a little shell script #!/bin/sh sleep 300 cat /tmp/message.$$ and an alias pointing to it: testalias: "|/path/to/script" - then set the daemon to run with -q1m, and send a single mail to "testalias". If the problem appears in this test, you should have (after 5 minutes) multiple /tmp/message.n (the n being process IDs) files, each containing the message you sent. If you check /tmp in 10 minutes, you will notice that some messages will overlap in -CURRENT of having the same message regenerated a few times while on 3.3-RELEASE, it will only show one /tmp/message.n file. And then just to repeat the test, do the following but this time send the single message to testalias with the command: sendmail -odq -oi testalias messagefile It might also be worth testing with sendmail -odi -oi testalias messagefile The last form will seem to hang until the message is delivered. If there is only one '/tmp/message.n' produced in each of these tests, it will suggest that your system is losing its locks over the fork made for delivery. With '-odq', the message is placed in the queue for later delivery attempts, and the queue run does not normally fork for delivery. With '-odi' it is delivered interactively without a fork. With neither of those operands, or with '-odb', there is a fork before delivery. On all of these tests, 3.3-RELEASE will generate only one /tmp/message.n while -CURRENT will generate multiple /tmp/message.n. My -CURRENT system is using sources as of 10/30/99 5:30AM PDT. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rm error code on FAT
Does anybody can explain why two absolutely identical attempts to remove
unexistent files on UFS and FAT32 yields different error codes ("No such
file or directory" and "Invalid argument" respectively)? This breaks "rm
-f" behaviour, because instead of expected "0", "rm -f" on FAT returns
error code instead.
bash-2.03# mount
/dev/ad0s2a on / (ufs, local, noatime, soft-updates, writes: sync 231
async 5542)
procfs on /proc (procfs, local)
/dev/ad0s1 on /mnt (msdos, local)
bash-2.03# rm /tmp/*.no_such_files
rm: /tmp/*.no_such_files: No such file or directory
bash-2.03# rm /mnt/*.no_such_files
rm: /mnt/*.no_such_files: Invalid argument
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: help
Please note that you've mailed this to a freebsd specific mailing list which is designed for discussions of issues with freebsd-current. This is is not subtitled, "A reference for script-kiddie wannabies." Please insert 50c for your next attempt, and good day. (Translation: You've sent your question to an inappropriate mailing list, and you're not likely to get a good answer here, so go search at rootshell instead). Lo and behold, jg once said: I want to know where I could find Nestea v3. Where I can find? And where I could find a program that has the same effect that the nestea or better. It helps me. THANK YOU! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- work: [EMAIL PROTECTED] me: [EMAIL PROTECTED] MIT Laboratory for Computer Science http://www.angio.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rm error code on FAT
On Mon, 8 Nov 1999, Maxim Sobolev wrote:
Does anybody can explain why two absolutely identical attempts to remove
unexistent files on UFS and FAT32 yields different error codes ("No such
file or directory" and "Invalid argument" respectively)? This breaks "rm
-f" behaviour, because instead of expected "0", "rm -f" on FAT returns
error code instead.
unlink("/mnt/*.no_such_files") on msdosfs returns EINVAL because the
pathname contains the invalid character '*'. EINVAL used to be a
documented errno for pathnames containing characters with their high
bit set). This documentation should have been made filesystem-
dependent instead of removing it.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
sh bug
Try this in -current $ cat some_file | head I have to use ^C to regain control. Jean-Marc -- Jean-Marc ZucconiPGP Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh bug
Jean-Marc Zucconi writes: Try this in -current $ cat some_file | head I have to use ^C to regain control. ... and reverting to rev. 1.22 of eval.c fixes the problem. Jean-Marc -- Jean-Marc ZucconiPGP Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: show stopper for Gcc 2.95.2 conversion
Gary Jennejohn wrote: Mmmm... O'Brien, could you make sure the space-critical code in sys/boot compiles ok? I still have GCC 2.95.2 installed. This is what I get in /sys/boot: === i386/boot2 (cd /usr/src/sys/boot/i386/boot2; m4 -DFLAGS=0 boot1.m4 boot1.s) | as -o boot1.o ld -nostdlib -static -N -e start -Ttext 0x7c00 -o boot1.out boot1.o objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 2/dev/null cc -elf -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -fno-builtin -Os -malign-functions=0 -malign-jumps=0 -malign-loops=0 -mrtd -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -c boot2.c (cd /usr/src/sys/boot/i386/boot2; m4 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 sio.s) | as -o sio.o ld -nostdlib -static -N -Ttext 0x1000 -o boot2.out /usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x1000 -f bin -b /usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.01 size=700 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=15c0 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1ec0 text=200 data=1cc0 org=0 entry=0 -192 bytes available Well, the flags seem correct (in particular -Os). It would be interesting to see what's the difference in the assembler code generated by both. Unfortunately, I cannot upgrade my system for the time being. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] What y'all wanna do? Wanna be hackers? Code crackers? Slackers Wastin' time with all the chatroom yakkers? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
