compaq proliant dl360 G3 nic driver
hi, I have installed FreeBSD 4.7R on a compaq proliant dl360 G3 to find out that the nics are not being recognized.. has this been dealt with in current ? -- Does artificial plants need artificial water ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BOOT2_UFS=UFS1_ONLY works for today's current
On Saturday 22 February 2003 08:55 pm, Giorgos Keramidas wrote: Just in case anyone tries to build today's current and sees it fail because of boot2, you can always set BOOT2_UFS=UFS1_ONLY or BOOT2_UFS=UFS2_ONLY in your make.conf and rebuild. I added BOOT2_UFS=UFS2_ONLY to my make.conf, and my buildworld still dies in boot2. I'm trying to upgrade from a Feb. 19 -current (because it's crashing all the time, and I need to enable debugging stuff). Is there a fix, or would other information be helpful? -David -- http://www.seektruth.org Astronomy and Astrophysics Center The University of Chicago To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI
Sergey Matveychuk wrote: I'v cvsup'ed from 5.0-RELEASE to RELENG_5_0_0 last night and ACPI doesn't work now. When booting I'v got a message: ACPI autoload failed - no such file or directory. How to fix? That's saying the acpi.ko module was not built and installed. When you install your new kernel, use the Makefile target, instead of using cp, or it won't install the modules it builds. If you did this, then check your make.conf to see if you are specifically telling it to not build modules, or only telling it to build specific modules, etc.. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [Re: cc: Internal error: Illegal instruction (program as)
On Sat, Feb 22, 2003 at 11:18:42PM -0800, Terry Lambert [EMAIL PROTECTED] wrote: I thought this was the default in 5.x GENERIC; has someone turned these options off in the default config?!? I certainly haven't seen changes to locore.s, pmap.c, and machdep.c that would fix the problem by working around the CPU bug. Can't say anything for Paul's case, he probably had custom kernel then? If I can remember peter did the options conditional for CPU type, so only P4 owners get'em at boot time. Check the Feb 12 commit logs. -- Vallo Kallaste To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [Re: cc: Internal error: Illegal instruction (program as)
Vallo Kallaste wrote: On Sat, Feb 22, 2003 at 11:18:42PM -0800, Terry Lambert [EMAIL PROTECTED] wrote: I thought this was the default in 5.x GENERIC; has someone turned these options off in the default config?!? I certainly haven't seen changes to locore.s, pmap.c, and machdep.c that would fix the problem by working around the CPU bug. Can't say anything for Paul's case, he probably had custom kernel then? If I can remember peter did the options conditional for CPU type, so only P4 owners get'em at boot time. Check the Feb 12 commit logs. That's too bad, since it's not a P4 specific problem. AMD and other Intel processors will also have the same problem (AMD seems to have lifted the logic circuit designs directly). The problem has definitely been around since the P3 days (the P3 is where I saw it first). The only thing that's going to be a factor is amount of memory in the system, and certain tuning parameters, in which case the workaround is accidental. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [Re: cc: Internal error: Illegal instruction (program as)
I thought this was the default in 5.x GENERIC; has someone turned these options off in the default config?!? I certainly haven't seen changes to locore.s, pmap.c, and machdep.c that would fix the problem by working around the CPU bug. Can't say anything for Paul's case, he probably had custom kernel then? If I can remember peter did the options conditional for CPU type, so only P4 owners get'em at boot time. Check the Feb 12 commit logs. He did add code to do it, but disabled it again in the next commit. See rev 1.386 and 1.387 of sys/i386/i386/pmap.c. Note the _nots at the end of the #ifdefs. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
Hello Soeren, I am sorry, but the last demsg output I have sent was not complete. I had captured that from /var/log/messages which does not seem to contain everything... Enclosed is a new one done with a serial console. Here I think the culprit can be seen as lines like: (probe2:ata2:0:0:0): CAM Status 0x39 Anything I can do to help investigate this further? Michael Soeren Schmidt wrote: It seems Anders Andersson wrote: On Sat, Feb 22, 2003 at 01:02:33PM +0100, [EMAIL PROTECTED] wrote: If you say int broke in the 20feb timeframe I think sos' ATA megacommit is the main suspect... Yes, sos ATA commit is what broke my sparc64 also (already informed sos in private mail), but he didnt have any direct ideas about the cause. Your problem is different, you dont see the disks due to missing interrupts, here the disks are found and read from but it falls apart later... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- - michael class, viktor-renner str. 39, 72074 tuebingen, frg E-Mail: [EMAIL PROTECTED] Phone: +49 7031 14-3707 (work) +49 7071 81950 (private) - Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS drive E: is disk3 BIOS 639kB/1047488kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Sat Feb 15 14:17:10 MET 2003) Loading /boot/defaults/loader.conf Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Booting [/boot/kernel/kernel] in 8 seconds... Booting [/boot/kernel/kernel] in 7 seconds... Booting [/boot/kernel/kernel] in 6 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK unload OK load /boot/kernel.test/kernel OK load /boot/kernel.test/acpi.ko OK boot -v SMAP type=01 base= len= 0009fc00 SMAP type=02 base= 0009fc00 len= 0400 SMAP type=02 base= 000f len= 0001 SMAP type=01 base= 0010 len= 3fef SMAP type=03 base= 3fff len= 8000 SMAP type=04 base= 3fff8000 len= 8000 SMAP type=02 base= fec0 len= 1000 SMAP type=02 base= fee0 len= 1000 SMAP type=02 base= len= 0001 Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sun Feb 23 08:59:21 MET 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/MCSMP2 Preloaded elf kernel /boot/kernel.test/kernel at 0xc0566000. Preloaded elf module /boot/kernel.test/acpi.ko at 0xc05660bc. Calibrating clock(s) ... i8254 clock: 1193225 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 996558899 Hz CPU: Intel Pentium III (996.56-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) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0059 - 0x3ffd, 1067778048 bytes (260688 pages) avail memory = 1037332480 (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 bios32: Found BIOS32 Service Directory header at 0xc00fdad0 bios32: Entry = 0xfdae0 (c00fdae0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdb01 pnpbios: Found PnP BIOS data at 0xc00f6e40 pnpbios: Entry = f:5c04 Rev = 1.0 Other BIOS signatures found: null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff 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 pci_open(1):mode 1 addr port (0x0cf8) is 0x80010048 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=06911106) pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00f7530 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded01A 0x01 3 4 5 7 9 10 11 12 14 15 embedded01B 0x02 3 4 5 7 9 10 11 12 14 15 embedded01C 0x03 3 4 5 7 9 10 11 12 14 15
Re: Mounting Root fails with error 22 (EINVAL)
It seems Michael Class wrote: Hello Soeren, I am sorry, but the last demsg output I have sent was not complete. I had captured that from /var/log/messages which does not seem to contain everything... Enclosed is a new one done with a serial console. Here I think the culprit can be seen as lines like: (probe2:ata2:0:0:0): CAM Status 0x39 Anything I can do to help investigate this further? Loose atapi-cam please and let me know if that helps -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
Hi! Here on my system it does not help :-(, I've never had atapicam configured. Christian. On Sunday, 23. February 2003 11:17, Soeren Schmidt wrote: It seems Michael Class wrote: Hello Soeren, I am sorry, but the last demsg output I have sent was not complete. I had captured that from /var/log/messages which does not seem to contain everything... Enclosed is a new one done with a serial console. Here I think the culprit can be seen as lines like: (probe2:ata2:0:0:0): CAM Status 0x39 Anything I can do to help investigate this further? Loose atapi-cam please and let me know if that helps -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BOOT2_UFS=UFS1_ONLY works for today's current
Thank you for your info., Giorgos. BOOT2_UFS=UFS1_ONLY in /etc/make.conf made my buildworld OK. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
On Sun, 23 Feb 2003, Soeren Schmidt wrote: It seems Michael Class wrote: Hello Soeren, I am sorry, but the last demsg output I have sent was not complete. I had captured that from /var/log/messages which does not seem to contain everything... Enclosed is a new one done with a serial console. Here I think the culprit can be seen as lines like: (probe2:ata2:0:0:0): CAM Status 0x39 Anything I can do to help investigate this further? Loose atapi-cam please and let me know if that helps -Søren Been there, done that. No change! Michael To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: compaq proliant dl360 G3 nic driver
use the latest RELENG_4 L. Jankok ([EMAIL PROTECTED]) wrote: hi, I have installed FreeBSD 4.7R on a compaq proliant dl360 G3 to find out that the nics are not being recognized.. has this been dealt with in current ? -- Does artificial plants need artificial water ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Paul Saab Technical Yahoo [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI
That's saying the acpi.ko module was not built and installed. When you install your new kernel, use the Makefile target, instead of using cp, or it won't install the modules it builds. If you did this, then check your make.conf to see if you are specifically telling it to not build modules, or only telling it to build specific modules, etc.. I build modules with buildworld and install it with installworld. No cp. All modules installed well. I'll check acpi.ko. Sem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current buildworld fails 24 hours
On Sun, 23 Feb 2003, Yamada Ken Takeshi wrote: I have the following error with make buildworld since Feb. 21th, 0900GMT with my P3x2 box. boot2 seems exceeding the size limit, any fix? Same here, with the sources of today (upped en builded twice, but both time's the same error) Regards, Richard. Paul Vixie in an interview with Sendmail.net: Now that the Internet has the full spectrum of humanity as users, the technology is showing its weakness: it was designed to be used by friendly, smart people. Spammers, as an example of a class, are neither friendly nor smart. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
Can somebody please use cvs update -D date to do a binary search and identify which exact commit caused the problem ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SIO interrupt level buffer overflows
Hi I've had a resurgence of these starting a few days ago. Basically whenever there is fairly heavy IO (I mean as heavy as IO can get on a COM port) the console starts spewing these messages. [brane-dead] ~ # uptime 5:05PM up 1 day, 8:39, 1 user, load averages: 2.02, 2.10, 2.09 [brane-dead] ~ # grep interrupt-level /var/log/messages |tail Feb 23 17:15:17 brane-dead kernel: sio1: 793 more interrupt-level buffer overflows (total 316848) Feb 23 17:15:18 brane-dead kernel: sio1: 39 more interrupt-level buffer overflows (total 316887) Feb 23 17:15:26 brane-dead kernel: sio1: 33 more interrupt-level buffer overflows (total 316920) Feb 23 17:15:28 brane-dead kernel: sio1: 1 more interrupt-level buffer overflow (total 316921) Feb 23 17:15:29 brane-dead kernel: sio1: 256 more interrupt-level buffer overflows (total 317177) Feb 23 17:15:31 brane-dead kernel: sio1: 80 more interrupt-level buffer overflows (total 317257) Feb 23 17:15:32 brane-dead kernel: sio1: 64 more interrupt-level buffer overflows (total 317321) Feb 23 17:15:35 brane-dead kernel: sio1: 64 more interrupt-level buffer overflows (total 317385) Feb 23 17:15:41 brane-dead kernel: sio1: 64 more interrupt-level buffer overflows (total 317449) Feb 23 17:15:53 brane-dead kernel: sio1: 320 more interrupt-level buffer overflows (total 317769) It's affecting throughput on my leased line by causing errors and retransmissions. [brane-dead] ~ # grep HDLC errors /var/log/ppp.log |tail Feb 23 16:57:44 brane-dead ppp[187]: Phase: deflink: HDLC errors - FCS: 17, ADDR: 0, COMD: 0, PROTO: 0 Feb 23 16:58:46 brane-dead ppp[187]: Phase: deflink: HDLC errors - FCS: 16, ADDR: 0, COMD: 0, PROTO: 0 Feb 23 16:59:47 brane-dead ppp[187]: Phase: deflink: HDLC errors - FCS: 26, ADDR: 0, COMD: 0, PROTO: 0 Feb 23 17:00:48 brane-dead ppp[187]: Phase: deflink: HDLC errors - FCS: 27, ADDR: 0, COMD: 0, PROTO: 0 Feb 23 17:01:49 brane-dead ppp[187]: Phase: deflink: HDLC errors - FCS: 10, ADDR: 0, COMD: 0, PROTO: 0 Feb 23 17:02:50 brane-dead ppp[187]: Phase: deflink: HDLC errors - FCS: 18, ADDR: 0, COMD: 0, PROTO: 0 Feb 23 17:03:51 brane-dead ppp[187]: Phase: deflink: HDLC errors - FCS: 2, ADDR: 0, COMD: 0, PROTO: 0 Feb 23 17:04:53 brane-dead ppp[187]: Phase: deflink: HDLC errors - FCS: 1, ADDR: 0, COMD: 0, PROTO: 0 Feb 23 17:05:54 brane-dead ppp[187]: Phase: deflink: HDLC errors - FCS: 20, ADDR: 0, COMD: 0, PROTO: 0 Feb 23 17:06:55 brane-dead ppp[187]: Phase: deflink: HDLC errors - FCS: 39, ADDR: 0, COMD: 0, PROTO: 0 I suspect the kernel isn't servicing the interrupts quickly enough. Is there any chance this is related to making sio0 my console? Any ideas? I know this was discussed about a year ago but that discussion was inconclusive. The system is SMP (dual Pii-266) using SCHED_4BSD without WITNESS. dmesg.boot follows. Ian -- Ian Freislich Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #16: Sat Feb 22 08:20:17 SAST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/BRANE-DEAD Preloaded elf kernel /boot/kernel/kernel at 0xc0412000. Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) Origin = GenuineIntel Id = 0x634 Stepping = 4 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 201261056 (191 MB) avail memory = 190816256 (181 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: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdc60 pcib0: Intel 82443LX (440 LX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 IOAPIC #0 intpin 16 - irq 2 IOAPIC #0 intpin 17 - irq 16 IOAPIC #0 intpin 18 - irq 17 agp0: Intel 82443LX (440 LX) host to PCI bridge mem 0xe000-0xe3ff 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 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.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 0xd000-0xd01f irq 12 at device 7.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 7.3 (no driver attached) xl0: 3Com
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html Sun Feb 23 03:38:01 EST 2003 cvs [update aborted]: /work/repo/CVSROOT: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
On Sunday, 23. February 2003 14:46, [EMAIL PROTECTED] wrote: Can somebody please use cvs update -D date to do a binary search and identify which exact commit caused the problem ? The kernel of '2/20/2003 19:55 GMT' boots fine, but the kernel of '2/20/2003 20:03 GMT' doesn't. The commits in between those time frame are: U sys/conf/files U sys/dev/ata/ata-all.c U sys/dev/ata/ata-all.h U sys/dev/ata/ata-card.c U sys/dev/ata/ata-cbus.c U sys/dev/ata/ata-chipset.c U sys/dev/ata/ata-disk.c U sys/dev/ata/ata-disk.h U sys/dev/ata/ata-dma.c U sys/dev/ata/ata-isa.c U sys/dev/ata/ata-pci.c U sys/dev/ata/ata-pci.h U sys/dev/ata/ata-raid.c U sys/dev/ata/ata-raid.h U sys/dev/ata/atapi-all.c U sys/dev/ata/atapi-all.h U sys/dev/ata/atapi-cd.c U sys/dev/ata/atapi-cd.h U sys/dev/ata/atapi-fd.c U sys/dev/ata/atapi-fd.h U sys/dev/ata/atapi-tape.c U sys/dev/ata/atapi-tape.h U sys/sys/ata.h I don't know how to narrow this down, because I think they all depend on each other and my knowledge of the ata driver is ... well ... limited :). But I'll try it ... Christian. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html Sun Feb 23 11:38:00 EST 2003 cvs [update aborted]: /work/repo/CVSROOT: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
It seems that I managed to break the tagged queueing support somehow, so please disable tags while I look hunt for the problem.. I'll commit a disable tags patch to -current in a few... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP! ATA driver updates...
I have corrected a number of problems on Serverworks ALI chipsets and it has been committed to -current. There is an outstanding problem with having tags enabled on ATA disks, and I have temporarily disabled tags support until I nail that nasty problem. So please update your sources and let me know if there is still any problems.. Thanks! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BOOT2_UFS=UFS1_ONLY works for today's current
On Sun, 23 Feb 2003, David Syphers wrote: David, I added BOOT2_UFS=UFS2_ONLY to my make.conf, and my buildworld still dies in boot2. I'm trying to upgrade from a Feb. 19 -current (because it's crashing all the time, and I need to enable debugging stuff). Is there a fix, or would other information be helpful? Same problem over here. I reverted back the last commit on /usr/src/sys/ufs/ffs/fs.h in my source tree and that fixed the build. Of course, this is a workaround !! Regards, Richard. Paul Vixie in an interview with Sendmail.net: Now that the Internet has the full spectrum of humanity as users, the technology is showing its weakness: it was designed to be used by friendly, smart people. Spammers, as an example of a class, are neither friendly nor smart. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSH (TCP?) lag
On 2003-02-22 22:49, Andre Guibert de Bruet [EMAIL PROTECTED] wrote: I find myself waiting up to two seconds for data to flush to the terminal on a 28 line 'ls -l'. net.inet.tcp.delayed_ack doesn't appear to cause this behavior on 4.7-stable. Did we inadvertently break the 100ms clause with the latest TCP patches? Jonathan Lemon has already posted a message that says he knows there is a bug in the recent changes. He's looking into it. To make things work without delays you should (temporarily) enable net.inet.tcp.delayed_ack=0. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSH (TCP?) lag
On 17:21+0200, Feb 23, 2003, Giorgos Keramidas wrote: On 2003-02-22 22:49, Andre Guibert de Bruet [EMAIL PROTECTED] wrote: I find myself waiting up to two seconds for data to flush to the terminal on a 28 line 'ls -l'. net.inet.tcp.delayed_ack doesn't appear to cause this behavior on 4.7-stable. Did we inadvertently break the 100ms clause with the latest TCP patches? Jonathan Lemon has already posted a message that says he knows there is a bug in the recent changes. He's looking into it. To make things work without delays you should (temporarily) enable net.inet.tcp.delayed_ack=0. This bug is already fixed: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3988161+0+archive/2003/cvs-all/20030223.cvs-all -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
[EMAIL PROTECTED] wrote: Can somebody please use cvs update -D date to do a binary search and identify which exact commit caused the problem ? Hello, I am getting the following result: A Kernel check out with the following command works: cvs -d /space/CVSROOT co -D 2003-02-20 00:00-P src the one check out with the following command does not work cvs -d /space/CVSROOT co -D 2003-02-20 11:00 -P src Unfortunately I have to leave now and cannot dig deeper into this. The system I am doing this on is on MET timzone (and I am not sure on the implications on the cvs command ...). Michael -- - michael class, viktor-renner str. 39, 72074 tuebingen, frg E-Mail: [EMAIL PROTECTED] Phone: +49 7031 14-3707 (work) +49 7071 81950 (private) - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
A note about boot2
I had to add two lines to my make.conf to get boot2 to compile: UFS2_BOOT=UFS1_ONLY UFS1_ONLY=yes If you are using UFS2 you need to edit appropriately, of course. _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI
On Sun, Feb 23, 2003 at 03:54:30PM +0300, Sergey Matveychuk wrote: That's saying the acpi.ko module was not built and installed. When you install your new kernel, use the Makefile target, instead of using cp, or it won't install the modules it builds. If you did this, then check your make.conf to see if you are specifically telling it to not build modules, or only telling it to build specific modules, etc.. I build modules with buildworld and install it with installworld. No cp. All modules installed well. I'll check acpi.ko. MODULES_WITH_WORLD causes modules to be installed during installworld. But when you later do installkernel, it renames /boot/kernel to /boot/kernel.old, so all your modules end up there. Don't use MODULES_WITH_WORLD, or use ``make reinstallkernel'' which is safe for MODULES_WITH_WORLD environment. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Kernel panic on shutdown of X server.
This problem started about Feb 19 and continues thru today's updates. Everything seems to work great until I shut down the X server at which time I get a fatal 'page fault while in kernel mode.' I have two -CURRENT machines at the moment and only the one with the nVidia driver (and kernel module) has the page fault problem. I know the nVidia people don't support the driver for -CURRENT but it has been working perfectly until now, so something important in the kernel changed about four days ago, apparently. Anyone else seeing this? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI
MODULES_WITH_WORLD causes modules to be installed during installworld. But when you later do installkernel, it renames /boot/kernel to /boot/kernel.old, so all your modules end up there. Don't use MODULES_WITH_WORLD, or use ``make reinstallkernel'' which is safe for MODULES_WITH_WORLD environment. I see it now. Thanks. I'v fixed it just going into /sys/modules/acpi and making install. Sem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI
Ruslan Ermilov wrote: On Sun, Feb 23, 2003 at 03:54:30PM +0300, Sergey Matveychuk wrote: That's saying the acpi.ko module was not built and installed. When you install your new kernel, use the Makefile target, instead of using cp, or it won't install the modules it builds. If you did this, then check your make.conf to see if you are specifically telling it to not build modules, or only telling it to build specific modules, etc.. I build modules with buildworld and install it with installworld. No cp. All modules installed well. I'll check acpi.ko. MODULES_WITH_WORLD causes modules to be installed during installworld. But when you later do installkernel, it renames /boot/kernel to /boot/kernel.old, so all your modules end up there. Don't use MODULES_WITH_WORLD, or use ``make reinstallkernel'' which is safe for MODULES_WITH_WORLD environment. This only works for a new kernel where the modules you have are binary compatible with both it and the old kernel. In reality, you probably *want* the old modules under kernel.old, and *entirely new* modules under kernel, to go with the new kernel. Otherwise you end up with kernel.old with old kernel and new modules, or kernel.old with old kernel and old modules, but you never get new kernel with new modules. In other words: don't use MODULES_WITH_WORLD, it's a bad idea. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic on shutdown of X server.
walt wrote: This problem started about Feb 19 and continues thru today's updates. Everything seems to work great until I shut down the X server at which time I get a fatal 'page fault while in kernel mode.' I have two -CURRENT machines at the moment and only the one with the nVidia driver (and kernel module) has the page fault problem. I know the nVidia people don't support the driver for -CURRENT but it has been working perfectly until now, so something important in the kernel changed about four days ago, apparently. Anyone else seeing this? Which scheduler are you using? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI
Sergey Matveychuk wrote: MODULES_WITH_WORLD causes modules to be installed during installworld. But when you later do installkernel, it renames /boot/kernel to /boot/kernel.old, so all your modules end up there. Don't use MODULES_WITH_WORLD, or use ``make reinstallkernel'' which is safe for MODULES_WITH_WORLD environment. I see it now. Thanks. I'v fixed it just going into /sys/modules/acpi and making install. You should be able to do all of them, unless you make.conf has problems, by: cd /sys/i386/compile/GENERIC make make install To do your kernel and module builds and installs (avoid using installkernel, if you are not going to update everything from scratch each time). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BOOT2_UFS=UFS1_ONLY works for today's current
On Sunday 23 February 2003 11:10 am, Richard Arends wrote: On Sun, 23 Feb 2003, David Syphers wrote: I added BOOT2_UFS=UFS2_ONLY to my make.conf, and my buildworld still dies in boot2. I'm trying to upgrade from a Feb. 19 -current (because it's crashing all the time, and I need to enable debugging stuff). Is there a fix, or would other information be helpful? Same problem over here. I reverted back the last commit on /usr/src/sys/ufs/ffs/fs.h in my source tree and that fixed the build. Of course, this is a workaround !! Okay, I've verified that the problem is due to rev. 1.39 of /usr/src/sys/ufs/ffs/fs.h. Peter Wemm pointed out that the problem is not the commit, but gcc's bad handling of 64-bit operations. Nonetheless, this commit does break world for a lot of people... is there some official solution? The make.conf line only works for UFS1 - if it's set to UFS2, buildworld still fails. (Am I correct in assuming a 5.0-R install defaults to UFS2?) -David -- http://www.seektruth.org Astronomy and Astrophysics Center The University of Chicago To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic on shutdown of X server.
Terry Lambert wrote: walt wrote: This problem started about Feb 19 and continues thru today's updates. Everything seems to work great until I shut down the X server at which time I get a fatal 'page fault while in kernel mode.' I have two -CURRENT machines at the moment and only the one with the nVidia driver (and kernel module) has the page fault problem. I know the nVidia people don't support the driver for -CURRENT but it has been working perfectly until now, so something important in the kernel changed about four days ago, apparently. Anyone else seeing this? Which scheduler are you using? I have options SCHED_4BSD in my config file. I'll try the other one and see if it changes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic on shutdown of X server.
On 11:50-0800, Feb 23, 2003, walt wrote: This problem started about Feb 19 and continues thru today's updates. Everything seems to work great until I shut down the X server at which time I get a fatal 'page fault while in kernel mode.' I have two -CURRENT machines at the moment and only the one with the nVidia driver (and kernel module) has the page fault problem. I know the nVidia people don't support the driver for -CURRENT but it has been working perfectly until now, so something important in the kernel changed about four days ago, apparently. Anyone else seeing this? Yes. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1225336+0+archive/2003/cvs-all/20030223.cvs-all -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
WLAN
Hi, does anybody know wether FreeBSD supports PCMCIA cards for wireless lan based on 802.11g (54MBit/s) standard? Sincerley Gerald Mixa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/share/man/man4 Makefile
On Sat, 22 Feb 2003 17:24:48 -0700 (MST) M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] James E. Flemer [EMAIL PROTECTED] writes: : There are some non-if_* modules in there now that seem to : be only documented in /usr/src, exca is a good example. exca is there just for the pleasure of cbb (and soon pcic)... No one would load it on their own. Warner And eventually that fact will be documented. -- Tom Rhodes To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: INVARIANTS-related fs panic on alpha
On Fri, Feb 14, 2003 at 06:51:19PM -0800, Kris Kennaway wrote: On Fri, Feb 14, 2003 at 04:53:07PM -0800, Kirk McKusick wrote: I have tried running my test machine out of filesystem space (repeatedly) and have not been able to get this panic. I will keep running that test in the hopes that it will show up. In the meantime, if you can come up with an example that reliably triggers it, that would be most helpful. Hmm. The machines that have panicked are likely to have been under extreme disk load at the time they ran out of space (e.g. extracting several dozen large tarballs simultaneously) [1]. I'll have to see if I can trigger this. Kris [1] Due to the stupidity of the bento package build scheduler and various other contributing factors. Got this again when a filesystem filled up. Kris pgp0.pgp Description: PGP signature
Re: INVARIANTS-related fs panic on alpha
On Sun, Feb 23, 2003 at 01:37:24PM -0800, Kris Kennaway wrote: Hmm. The machines that have panicked are likely to have been under extreme disk load at the time they ran out of space (e.g. extracting several dozen large tarballs simultaneously) [1]. I'll have to see if I can trigger this. Kris [1] Due to the stupidity of the bento package build scheduler and various other contributing factors. Got this again when a filesystem filled up. I got a crashdump and gdb backtrace this time..let me know if you want it. Kris pgp0.pgp Description: PGP signature
Re: cvs commit: src/share/man/man4 Makefile
In message: [EMAIL PROTECTED] Tom Rhodes [EMAIL PROTECTED] writes: : On Sat, 22 Feb 2003 17:24:48 -0700 (MST) : M. Warner Losh [EMAIL PROTECTED] wrote: : : In message: : [EMAIL PROTECTED] : James E. Flemer [EMAIL PROTECTED] writes: : : There are some non-if_* modules in there now that seem to : : be only documented in /usr/src, exca is a good example. : : exca is there just for the pleasure of cbb (and soon pcic)... No one : would load it on their own. : : Warner : : : And eventually that fact will be documented. Done. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ATAPI CDROM drive not found
Hello, I've just noticed that recent -CURRENT kernels (from at least 2 days to now, but I suspect it might be a little longer) do not find my ATAPI CDROM drive. The kernel config file is the same as before, kernel CFLAGS are also the same (and I've even tried building the kernel without any non-default CFLAGS, same result), so I doubt it could be that. Perhaps it's something ata(4)-related that's not been sync'ed with /src/UPDATING? Just for the record, the drive appears at the BIOS check on boot, and Win2k on the very same box recognizes it perfectly. Thanks, Fred -- We are simple killers of people and destroyers of property. pgp0.pgp Description: PGP signature
[no subject]
auth 60ff6b89 unsubscribe freebsd-current [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BOOT2_UFS=UFS1_ONLY works for today's current
On Sun, Feb 23, 2003 at 02:49:52PM -0600, David Syphers wrote: fails. (Am I correct in assuming a 5.0-R install defaults to UFS2?) You are not correct. 5.0-R, and infact 5-CURRENT still default to ufs1. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BOOT2_UFS=UFS1_ONLY works for today's current
David Syphers wrote: Okay, I've verified that the problem is due to rev. 1.39 of /usr/src/sys/ufs/ffs/fs.h. Peter Wemm pointed out that the problem is not the commit, but gcc's bad handling of 64-bit operations. Nonetheless, this commit does break world for a lot of people... is there some official solution? The make.conf line only works for UFS1 - if it's set to UFS2, buildworld still fails. (Am I correct in assuming a 5.0-R install defaults to UFS2?) Yes. And 4.x upgrades, which are far more common, default to UFS. Personally, I think the changes should be #ifdef'ed the current version of GCC; when GCC rev's, hopefully its 64 bit operations handling will have improved. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: WLAN
On Mon, 2003-02-24 at 07:27, Gerald Mixa wrote: does anybody know wether FreeBSD supports PCMCIA cards for wireless lan based on 802.11g (54MBit/s) standard? Nope.. 802.11g isn't a final standard yet either (note no WiFi logo on 11g stuff) Personally I'd wait a bit until the standard is finalised and the interoperability tests are done before buying any of it. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VIA8235 audio support
On Sun, 2003-02-23 at 10:22, Orion Hodson wrote: The VIA8233/8235 audio driver has undergone another revision in an attempt to provide support for the VIA8235. The code is in -CURRENT as of 5 minutes ago. Several people have reported quiet/inaudible sound on P4 boards with this southbridge. If you have a VIA8235 based board, I'd be interested to know if it works for you as several people have reported quiet/near-silent operation with this chipset and I do not have the relevant h/w. The new code paths are used by the h/w that I do have access to (VIA8233C) so testing this code is low risk: the worst case is no sound :-) If you have a suitable board, but are not running -CURRENT. Let me know what version of FreeBSD you'd like it for and I'll do the relevant work for some small number of requests since I really want to resolve this issue. I have such a chipset but it seems to work fine. It's an Epox 8K9AI with a VIA 8235 south bridge, and I'm running FreeBSD 4.7 (almost 4.8-PRE). I merged the changes from -current (didn't apply cleanly but I think I got it right) and it still works, so that is a good start :) :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
machdep.guessed_bootdev sysctl on i386
Hello gang. Nothing big, but important...
Can someone tell me if the machdep.guessed_bootdev sysctl is helpful at
all? I think it's a waste, and it's pretty limited and only available
on the i386.
It currently guesses 'wd' instead of 'ad' for the dev. nodes, .e.g:
hiten:~/ sysctl machdep.gussed_bootdev
machdep.guessed_bootdev: /dev/wd0s1a
SCSI drives are shown right (da) but ATA drives mess up, i.e. it is
still thinking we have the 'wd' system. It's either that we nuke this
sysctl or apply the attached patch to sysctl, which has been reviewed
and tested by people on IRC with positive results.
Comments / objections appreciated.
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
Index: src/sbin/sysctl/sysctl.c
===
RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.51
diff -u -r1.51 sysctl.c
--- src/sbin/sysctl/sysctl.c22 Jan 2003 00:34:22 - 1.51
+++ src/sbin/sysctl/sysctl.c22 Feb 2003 14:21:13 -
@@ -460,9 +460,7 @@
int majdev;
char *name;
} maj2name[] = {
- 30, ad,
- 0, wd,
- 1, wfd,
+ 0, ad,
2, fd,
4, da,
-1, NULL/* terminator */
Re: BOOT2_UFS=UFS1_ONLY works for today's current
On Sun, 23 Feb 2003, Terry Lambert wrote: David Syphers wrote: Okay, I've verified that the problem is due to rev. 1.39 of /usr/src/sys/ufs/ffs/fs.h. Peter Wemm pointed out that the problem is not the commit, but gcc's bad handling of 64-bit operations. Nonetheless, this commit does break world for a lot of people... is there some official solution? The make.conf line only works for UFS1 - if it's set to UFS2, buildworld still fails. (Am I correct in assuming a 5.0-R install defaults to UFS2?) Yes. And 4.x upgrades, which are far more common, default to UFS. Personally, I think the changes should be #ifdef'ed the current version of GCC; when GCC rev's, hopefully its 64 bit operations handling will have improved. This would wrong, since ufs2 depends on the changes to actually work for file systems larger than about 1TB. Blaming gcc's 64-bit operations seems to be wrong anyway. gcc actually has good handling of (32, 32) - 64 bit operations which are the only types involved here in at least fs.h, boot2 still fits for me when it is compiled the previous version of gcc. It has 19 bytes to spare: %%% textdata bss dec hex filename 512 0 0 512 200 obj-UFS1_AND_UFS2/boot1.o 512 0 0 512 200 obj-UFS1_AND_UFS2/boot1.out 5228 25212073731ccd obj-UFS1_AND_UFS2/boot2.o 5439 25219676601dec obj-UFS1_AND_UFS2/boot2.out 91 0 0 91 5b obj-UFS1_AND_UFS2/sio.o 512 0 0 512 200 obj-UFS1_ONLY/boot1.o 512 0 0 512 200 obj-UFS1_ONLY/boot1.out 4999 25186468881ae8 obj-UFS1_ONLY/boot2.o 5211 25194071761c08 obj-UFS1_ONLY/boot2.out 91 0 0 91 5b obj-UFS1_ONLY/sio.o 512 0 0 512 200 obj-UFS2_ONLY/boot1.o 512 0 0 512 200 obj-UFS2_ONLY/boot1.out 5046 25199270631b97 obj-UFS2_ONLY/boot2.o 5255 25206873481cb4 obj-UFS2_ONLY/boot2.out 91 0 0 91 5b obj-UFS2_ONLY/sio.o %%% The fixes in fs.h are: % Index: fs.h % === % RCS file: /home/ncvs/src/sys/ufs/ffs/fs.h,v % retrieving revision 1.38 % retrieving revision 1.39 % diff -u -1 -r1.38 -r1.39 % --- fs.h 10 Jan 2003 06:59:34 - 1.38 % +++ fs.h 22 Feb 2003 00:19:26 - 1.39 % @@ -33,3 +33,3 @@ % * @(#)fs.h8.13 (Berkeley) 3/21/95 % - * $FreeBSD: src/sys/ufs/ffs/fs.h,v 1.38 2003/01/10 06:59:34 marcel Exp $ % + * $FreeBSD: src/sys/ufs/ffs/fs.h,v 1.39 2003/02/22 00:19:26 mckusick Exp $ % */ % @@ -498,3 +498,3 @@ % */ % -#define cgbase(fs, c) ((ufs2_daddr_t)((fs)-fs_fpg * (c))) % +#define cgbase(fs, c) (((ufs2_daddr_t)(fs)-fs_fpg) * (c)) % #define cgdmin(fs, c) (cgstart(fs, c) + (fs)-fs_dblkno) /* 1st data */ This changes a (32, 32) - 32 bit (possibly overflowing) operation to a (32, 32) - 64 bit (never overflowing) operation. The 1386 hardware already does the wider operation so all gcc has to do is not discard the high 32-bits, which it does reasonably well. % @@ -543,5 +543,5 @@ % #define lfragtosize(fs, frag)/* calculates ((off_t)frag * fs-fs_fsize) */ \ % - ((off_t)(frag) (fs)-fs_fshift) % + (((off_t)(frag)) (fs)-fs_fshift) % #define lblktosize(fs, blk) /* calculates ((off_t)blk * fs-fs_bsize) */ \ % - ((off_t)(blk) (fs)-fs_bshift) % + (((off_t)(blk)) (fs)-fs_bshift) % /* Use this only when `blk' is known to be small, e.g., NDADDR. */ These changes have no effect except to add style bugs (see below). The casts were inserted in the correct place in rev.1.7 to fix similar overflow bugs for _files_ larger than 2GB. Now we're fixing overflow for block numbers larger than 2G. % @@ -573,3 +573,3 @@ % (fs)-fs_cstotal.cs_nffree - \ % - ((off_t)((fs)-fs_dsize) * (percentreserved) / 100)) % + (((off_t)((fs)-fs_dsize)) * (percentreserved) / 100)) % This change has no effect for many reasons: - it just adds style bugs (see below). - the macro is not used in the boot blocks. - fs_dsize already happens to have the same type as off_t (both have type int64_t). off_t is a bogus type to cast to anyway. We start with a block count and multiply by a percentage. This is unrelated to file sizes, but overflow happens to be prevented by the maxiumum percentage (100) being smaller than the minimum block size (4096). All of these changes add style bugs IMO. Except for the change to cgbase(), they add redundant parentheses around (cast)(foo)-bar, but properly parenthesized macros are hard enough to read with only non-redundant parentheses. The change to cgbase() moves parentheses so that they are redundant instead of just wrong. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BOOT2_UFS=UFS1_ONLY works for today's current
From: David Syphers [EMAIL PROTECTED] To: Kirk McKusick [EMAIL PROTECTED] Subject: Re: BOOT2_UFS=UFS1_ONLY works for today's current Date: Sun, 23 Feb 2003 14:49:52 -0600 Cc: [EMAIL PROTECTED] On Sunday 23 February 2003 11:10 am, Richard Arends wrote: On Sun, 23 Feb 2003, David Syphers wrote: I added BOOT2_UFS=UFS2_ONLY to my make.conf, and my buildworld still dies in boot2. I'm trying to upgrade from a Feb. 19 -current (because it's crashing all the time, and I need to enable debugging stuff). Is there a fix, or would other information be helpful? Same problem over here. I reverted back the last commit on /usr/src/sys/ufs/ffs/fs.h in my source tree and that fixed the build. Of course, this is a workaround !! Okay, I've verified that the problem is due to rev. 1.39 of /usr/src/sys/ufs/ffs/fs.h. Peter Wemm pointed out that the problem is not the commit, but gcc's bad handling of 64-bit operations. Nonetheless, this commit does break world for a lot of people... is there some official solution? The make.conf line only works for UFS1 - if it's set to UFS2, buildworld still fails. (Am I correct in assuming a 5.0-R install defaults to UFS2?) -David -- http://www.seektruth.org Astronomy and Astrophysics Center The University of Chicago I have committed the following fix which reverts to using the previous broken version of cgbase in ufsread.c. It will work fine provided that your filesystem is smaller than 1.5Tb. Kirk McKusick Index: ufsread.c === RCS file: /usr/ncvs/src/sys/boot/common/ufsread.c,v retrieving revision 1.9 diff -c -r1.9 ufsread.c *** ufsread.c 2002/12/14 19:39:44 1.9 --- ufsread.c 2003/02/24 04:44:50 *** *** 28,33 --- 28,35 #include ufs/ufs/dinode.h #include ufs/ffs/fs.h + #undef cgbase + #define cgbase(fs, c) ((ufs2_daddr_t)((fs)-fs_fpg * (c))) /* * We use 4k `virtual' blocks for filesystem data, whatever the actual To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATAPI CDROM drive not found
Fred Souza wrote: I've just noticed that recent -CURRENT kernels (from at least 2 days to now, but I suspect it might be a little longer) do not find my ATAPI CDROM drive. This happened to me today, but it turned out that the drive wasn't recognized after a reboot if there was an audio CD already in the drive (ie, acd0 didn't show up in dmesg at all). If I rebooted with an empty drive, all was well. Anyone else notice this? - Rahul I'll send dmesg etc if relevant; my drive is acd0: LG DVD-ROM DRN-8080B/3.10 DVD-ROM drive at ata1 as master acd0: 512KB buffer, UDMA33 acd0: Reads: CD-R, CD-RW, CD-DA stream, DVD-ROM, DVD-R, packet acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machdep.guessed_bootdev sysctl on i386
Hiten Pandya wrote: Hello gang. Nothing big, but important... Can someone tell me if the machdep.guessed_bootdev sysctl is helpful at all? I think it's a waste, and it's pretty limited and only available on the i386. It currently guesses 'wd' instead of 'ad' for the dev. nodes, .e.g: hiten:~/ sysctl machdep.gussed_bootdev machdep.guessed_bootdev: /dev/wd0s1a SCSI drives are shown right (da) but ATA drives mess up, i.e. it is still thinking we have the 'wd' system. It's either that we nuke this sysctl or apply the attached patch to sysctl, which has been reviewed and tested by people on IRC with positive results. I've seen this used with FORTH code in order to automatically identify the correct device, after a failure to load modules from the wrong guess. The guess comes from the BIOS. THere are some Dell systems where the BIOS doesn't set up the BX register correctly; I don't know if there are any systems besides Dell where this is an issue. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machdep.guessed_bootdev sysctl on i386
On Sun, 23 Feb 2003, Hiten Pandya wrote:
Can someone tell me if the machdep.guessed_bootdev sysctl is helpful at
all? I think it's a waste, and it's pretty limited and only available
on the i386.
It is not helpful. Someone removed the initialization of the kernel
variable bootdev for i386's, so AFAICS bootdev is always unused on i386's
except for being misinterpreted by sysctl(8). A variable named bootdev is
still initialized on sparc64's, but sparc64's don't have the sysctl.
It currently guesses 'wd' instead of 'ad' for the dev. nodes, .e.g:
hiten:~/ sysctl machdep.gussed_bootdev
machdep.guessed_bootdev: /dev/wd0s1a
SCSI drives are shown right (da) but ATA drives mess up, i.e. it is
still thinking we have the 'wd' system. It's either that we nuke this
I don't see how it can work for SCSI drives. Its kernel variable is
statically initialized to 0 and never changed on i386's , so its
sysctl(3) always returns 0 and sysctl(8) always interprets it as wd.
sysctl or apply the attached patch to sysctl, which has been reviewed
and tested by people on IRC with positive results.
% Index: src/sbin/sysctl/sysctl.c
% ===
% RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v
% retrieving revision 1.51
% diff -u -r1.51 sysctl.c
% --- src/sbin/sysctl/sysctl.c 22 Jan 2003 00:34:22 - 1.51
% +++ src/sbin/sysctl/sysctl.c 22 Feb 2003 14:21:13 -
% @@ -460,9 +460,7 @@
% int majdev;
% char *name;
% } maj2name[] = {
% - 30, ad,
% - 0, wd,
% - 1, wfd,
% + 0, ad,
% 2, fd,
% 4, da,
% -1, NULL/* terminator */
This table and the corresponding function are very bogus, and can be
simplified to always printing wd0mumble in the old broken version,
and always ad0mumble in the new broken version. 0 certainly isn't
ad's major number. All of the major numbers in this table rotted long
ago. They are major numbers for block devices, but block devices were
axed in FreeBSD-4.0.
I didn't remove the initialization of the kernel bootdev variable for
i386's in my version and it the sysctl still mostly works for me, but
for bogus reasons:
- I use old boot blocks which have old major numbers hard-coded in them.
- booting works because the kernel ignores the bogus major numbers.
- sysctl(8) works because its hard-coded old major numbers are the same
as the ones in the boot blocks.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: BOOT2_UFS=UFS1_ONLY works for today's current
Bruce Evans wrote: Personally, I think the changes should be #ifdef'ed the current version of GCC; when GCC rev's, hopefully its 64 bit operations handling will have improved. This would wrong, since ufs2 depends on the changes to actually work for file systems larger than about 1TB. If it's not going to compile correctly, it's not going to work. What we are bitching about here is that someone wants to use 64 bit operations that GCC can't handle. Waving our hands isn't going to make the problem go away, and adding code that doesn't compile correctly with the current compiler won't, either. Blaming gcc's 64-bit operations seems to be wrong anyway. gcc actually has good handling of (32, 32) - 64 bit operations which are the only types involved here in at least fs.h, boot2 still fits for me when it is compiled the previous version of gcc. It has 19 bytes to spare: So we're agreed: it's a GCC issue, which is resolved by downgrading the compiler, or by upgrading it, after the new version is fixed (which is the direction I suggested going). % -#define cgbase(fs, c) ((ufs2_daddr_t)((fs)-fs_fpg * (c))) % +#define cgbase(fs, c) (((ufs2_daddr_t)(fs)-fs_fpg) * (c)) % #define cgdmin(fs, c) (cgstart(fs, c) + (fs)-fs_dblkno) /* 1st data */ This changes a (32, 32) - 32 bit (possibly overflowing) operation to a (32, 32) - 64 bit (never overflowing) operation. The 1386 hardware already does the wider operation so all gcc has to do is not discard the high 32-bits, which it does reasonably well. So it is agreed that this is good? [ ... rest of patches == style bugs ... ] All of these changes add style bugs IMO. Except for the change to cgbase(), they add redundant parentheses around (cast)(foo)-bar, but properly parenthesized macros are hard enough to read with only non-redundant parentheses. The change to cgbase() moves parentheses so that they are redundant instead of just wrong. OK... so what should be done? Just the cgbase() change? Does this fix the compiler revision dependent problem in such a way that the code does not need to be conditionalized on the compiler revision to avoid being broken? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machdep.guessed_bootdev sysctl on i386
In message [EMAIL PROTECTED], Hiten Pandya writes: --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello gang. Nothing big, but important... Can someone tell me if the machdep.guessed_bootdev sysctl is helpful at all? I think it's a waste, and it's pretty limited and only available on the i386. It isn't and it should be deleted I think. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machdep.guessed_bootdev sysctl on i386
[EMAIL PROTECTED] (Mon, Feb 24, 2003 at 07:10:59AM +0100) wrote:
In message [EMAIL PROTECTED], Hiten Pandya writes:
--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hello gang. Nothing big, but important...
Can someone tell me if the machdep.guessed_bootdev sysctl is helpful at
all? I think it's a waste, and it's pretty limited and only available
on the i386.
It isn't and it should be deleted I think.
Okay. I have attached a patch which will nuke the sysctl, and replace
it's use in picobsd's mfs_tree rc scripts with something better, but
which still needs review. I have not tested the patch, but this patch
should not fail, hopefully.
Cheers.
--
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/
Index: src/release/picobsd/mfs_tree/etc/rc
===
RCS file: /home/ncvs/src/release/picobsd/mfs_tree/etc/rc,v
retrieving revision 1.9
diff -u -r1.9 rc
--- src/release/picobsd/mfs_tree/etc/rc 17 Nov 2002 20:19:34 - 1.9
+++ src/release/picobsd/mfs_tree/etc/rc 24 Feb 2003 06:21:31 -
@@ -7,7 +7,7 @@
HOME=/; export HOME
PATH=/bin; export PATH
-dev=`sysctl -n machdep.guessed_bootdev`
+dev=`mount | grep 'on / ' | awk '{ print $1 }'`
[ -c ${dev} ] || dev=/dev/fd0
trap echo 'Reboot interrupted'; exit 1 3
Index: src/release/picobsd/mfs_tree/stand/update
===
RCS file: /home/ncvs/src/release/picobsd/mfs_tree/stand/update,v
retrieving revision 1.5
diff -u -r1.5 update
--- src/release/picobsd/mfs_tree/stand/update 11 Mar 2002 05:15:44 - 1.5
+++ src/release/picobsd/mfs_tree/stand/update 24 Feb 2003 06:20:08 -
@@ -5,7 +5,7 @@
thefiles=$*
[ -z $thefiles ] \
thefiles=/etc/rc.conf /etc/rc.firewall /etc/master.passwd
-dev=`sysctl -n machdep.guessed_bootdev`
+dev=`mount | grep 'on / ' | awk '{ print $1 }'`
[ -c ${dev} ] || dev=/dev/fd0
mount ${dev} /mnt
if [ $? != 0 ] ; then
Index: src/sbin/sysctl/sysctl.c
===
RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.51
diff -u -r1.51 sysctl.c
--- src/sbin/sysctl/sysctl.c22 Jan 2003 00:34:22 - 1.51
+++ src/sbin/sysctl/sysctl.c24 Feb 2003 06:05:01 -
@@ -451,55 +451,6 @@
return 0;
}
-#ifdef __i386__
-/*
- * Code to map a bootdev major number into a suitable device name.
- * Major numbers are mapped into names as in boot2.c
- */
-struct _foo {
- int majdev;
- char *name;
-} maj2name[] = {
- 30, ad,
- 0, wd,
- 1, wfd,
- 2, fd,
- 4, da,
- -1, NULL/* terminator */
-};
-
-static int
-machdep_bootdev(u_long value)
-{
- int majdev, unit, slice, part;
- struct _foo *p;
-
- if (value B_MAGICMASK != B_DEVMAGIC) {
- printf(invalid (0x%08x), value);
- return 0;
- }
- majdev = B_TYPE(value);
- unit = B_UNIT(value);
- slice = B_SLICE(value);
- part = B_PARTITION(value);
- if (majdev == 2) { /* floppy, as known to the boot block... */
- printf(/dev/fd%d, unit);
- return 0;
- }
- for (p = maj2name; p-name != NULL p-majdev != majdev ; p++) ;
- if (p-name != NULL) { /* found */
- if (slice == WHOLE_DISK_SLICE)
- printf(/dev/%s%d%c, p-name, unit, part);
- else
- printf(/dev/%s%ds%d%c,
- p-name, unit, slice - BASE_SLICE + 1, part + 'a');
- } else
- printf(unknown (major %d unit %d slice %d part %d),
- majdev, unit, slice, part);
- return 0;
-}
-#endif
-
/*
* This formats and outputs the value of one variable
*
@@ -593,10 +544,6 @@
if (!nflag)
printf(%s%s, name, sep);
fmt++;
-#ifdef __i386__
- if (!strcmp(name, machdep.guessed_bootdev))
- return machdep_bootdev(*(unsigned long *)p);
-#endif
val = ;
while (len = sizeof(long)) {
if(*fmt == 'U')
Index: src/sys/i386/i386/machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.554
diff -u -r1.554 machdep.c
--- src/sys/i386/i386/machdep.c 20 Feb 2003 05:35:52 - 1.554
+++ src/sys/i386/i386/machdep.c 24 Feb 2003 06:03:34 -
@@ -1175,10 +1175,6 @@
SYSCTL_INT(_machdep, CPU_WALLCLOCK, wall_cmos_clock,
CTLFLAG_RW, wall_cmos_clock, 0, );
-u_long bootdev;/* not a dev_t - encoding is different */
-SYSCTL_ULONG(_machdep, OID_AUTO, guessed_bootdev,
- CTLFLAG_RD, bootdev, 0, Maybe the Boot device (not in dev_t format));
-
/*
* Initialize 386 and
Re: BOOT2_UFS=UFS1_ONLY works for today's current
On Sun, 23 Feb 2003, Terry Lambert wrote: Bruce Evans wrote: Personally, I think the changes should be #ifdef'ed the current version of GCC; when GCC rev's, hopefully its 64 bit operations handling will have improved. This would wrong, since ufs2 depends on the changes to actually work for file systems larger than about 1TB. If it's not going to compile correctly, it's not going to work. That is a feature :-). What we are bitching about here is that someone wants to use 64 bit operations that GCC can't handle. Waving our hands isn't going to make the problem go away, and adding code that doesn't compile correctly with the current compiler won't, either. I doubt that it is a problem with 64-bitness. Handling 64 bits just takes more code, and the macro is apparently used a lot (it is used deeply nested so it is not obvious how often it is expanded). I suspect the problem is more from increased register pressure that happens to afect the current compiler more. This changes a (32, 32) - 32 bit (possibly overflowing) operation to a (32, 32) - 64 bit (never overflowing) operation. The 1386 hardware already does the wider operation so all gcc has to do is not discard the high 32-bits, which it does reasonably well. So it is agreed that this is good? I hope so. The result doesn't always fit in 32 bits when the file system size exceeds about 1TB. Discarding nonzero high bits probably causes corrupt file systems. OK... so what should be done? Just the cgbase() change? Does this fix the compiler revision dependent problem in such a way that the code does not need to be conditionalized on the compiler revision to avoid being broken? Kirk committed a quick fix. The bug is unlikely to matter in boot code. Root file systems shouldn't be larger than 1TB. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machdep.guessed_bootdev sysctl on i386
On Mon, 24 Feb 2003, I wrote: On Sun, 23 Feb 2003, Hiten Pandya wrote: Can someone tell me if the machdep.guessed_bootdev sysctl is helpful at all? I think it's a waste, and it's pretty limited and only available on the i386. It is not helpful. Someone removed the initialization of the kernel variable bootdev for i386's, so AFAICS bootdev is always unused on i386's except for being misinterpreted by sysctl(8). A variable named bootdev is still initialized on sparc64's, but sparc64's don't have the sysctl. Oops. I missed that bootdev is initialized in locore. It is just not used in the kernel, except to pass the boot block's idea of the boot device on to userland. Things work iff userland agrees with the boot blocks about how the boot device is encoded. The bug is apaprently that some boot blocks pass the boot device in an incompatible way. I can't see the bug. E.g., boot2 still attempts to encode ad devices with major 30 as is required for backwards compatibility (booting old kernels) and sideways compatibility (interpretation by sysctl(8)). It currently guesses 'wd' instead of 'ad' for the dev. nodes, .e.g: hiten:~/ sysctl machdep.gussed_bootdev machdep.guessed_bootdev: /dev/wd0s1a SCSI drives are shown right (da) but ATA drives mess up, i.e. it is still thinking we have the 'wd' system. It's either that we nuke this I don't see how it can work for SCSI drives. Its kernel variable is statically initialized to 0 and never changed on i386's , so its sysctl(3) always returns 0 and sysctl(8) always interprets it as wd. Now I see how it can work %-). Is your booting method different for SCSI drives? ... I didn't remove the initialization of the kernel bootdev variable for i386's in my version and it the sysctl still mostly works for me, but for bogus reasons: - I use old boot blocks which have old major numbers hard-coded in them. - booting works because the kernel ignores the bogus major numbers. - sysctl(8) works because its hard-coded old major numbers are the same as the ones in the boot blocks. I tested with plain -current and old boot blocks. The sysctl still reports ad disks correctly. I don't care about the sysctl but want to keep the boot blocks as backwards compatible as possible. That means passing the boot device in the old encoding, which only takes a couple of lines of code. Current kernels ignore this and use a device name passed in the environment. This is presumably returned by the kenv syscall although not by a sysctl, so the sysctl is certainly not needed. I didn't test this since my boot blocks are too old and simple to pass an environment. They pass the device name more directly. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
nvidia.ko load failed on -current
Before blaming me, i know it is not supported for 5.x or -current, but i think some of us have that stuff already running on -current. I've been in hospital for many weeks and now i updated my system (late November) to the currents current. After adding the missing include, i successfully compiled the nvidia driver but loading the kernel module leads to: Feb 24 08:17:08 Twoflower kernel: link_elf: symbol rman_get_start undefined Feb 24 08:17:08 Twoflower kernel: KLD file nvidia.ko - could not finalize loading Anyone an idea? Jan -- Jan Stocker [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
