Re: NFSv3 on freebsd--solaris
On Thu, 26 Aug 1999, Dmitrij Tejblum wrote: Doug Rabson wrote: This is probably because our server detects that the directory has been modified and rejects the solaris client's directory cookies. I think we should not ever reject a client's cookie. Consider a local program that scan the directoty with the getdirentries() syscall. The offset in the directory is essentially the cookie that would be sent to an NFS client. But we never "reject" the offset, and everyone is happy. (Not to mention NFSv2, where we never reject a client's cookie too). So, what we are trying to achieve by rejecting a NFSv3 client's cookie? Notify the client that the directory contents may have been compacted and therefore that their seek offsets are now wrong. Instead of recovering, the solaris client barfs. Its a solaris bug really IMHO, it is very arguable. Why the client should "recover" after "stale cookie" error, but should not recover after "stale filehandle" error? How should it perform the recovery: If a reliable recovery is possible, why it is not done on the server? Stale cookie is completely different from stale filehandle and in general it isn't possible to recover on the server. (After all, Sun know how NFSv3 should work, since they wrote the spec, right? :-|) From rfc1813: In the NFS version 3 protocol, each READDIR request includes both a cookie and a cookie verifier. For the first call, both are set to 0. The response includes a new cookie verifier, with a cookie per entry. For subsequent READDIRs, the client must present both the cookie and the corresponding cookie verifier. If the server detects that the cookie is no longer valid, the server will reject the READDIR request with the status, NFS3ERR_BAD_COOKIE. The client should be careful to avoid holding directory entry cookies across operations that modify the directory contents, such as REMOVE and CREATE. It seems to me that the solaris client is holding directory cookies across a REMOVE operation and therefore should expect to get stale cookie errors occaisionally. Our NFS client used to have the same problem (a long time ago) and I put code into it to re-read the directory if its cookies are stale. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
K6-2 motherboards Was, Re: Softupdates reliability?
[moved to chat] : Yes, you stand a far better chance of making this hack work with a 66MHz : part.No the newer std parts are not designed to run with a 66MHz FSB, : you should always order them as /66. Note that AMD has stopped making : these chips due to low demand for them (with 100MHz boards $80 USA the : price/performance is usually worth it for most folks.) : : The USA... your prices tend to be a lot better than ours. I could can the : T2P4 but that would also mean I had to can the SIMMs (everything is DIMMs : now), get an AGP videocard and can the perfectly fine Millenium II (I need : the extra PCI slot quite badly) and buy a new CPU. Oh, and buy an ATX case. : In the end that is quite a bit more than $80. Unfortunately. I like the Tyan "Trinity", S1590AT. SIMM sockets, DIMM sockets, highly variable clocks and voltages throughout, AT *or* ATX power, PS/2 mouse, USB header, IR support. Works with K6-2 and K6-3 to 500MHz. 1AGP + 4PCI + 4ISA. Very flexible. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Softupdates reliability?
On Wed, 25 Aug 1999, Wilko Bulte wrote: The USA... your prices tend to be a lot better than ours. I could can the T2P4 but that would also mean I had to can the SIMMs (everything is DIMMs now), get an AGP videocard and can the perfectly fine Millenium II (I need the extra PCI slot quite badly) and buy a new CPU. Oh, and buy an ATX case. In the end that is quite a bit more than $80. Unfortunately. Doesn't Asus make an AT formfactor Super 7 motherboard w/ a 100mhz bus? I'm pretty sure it has DIMM and SIMM slots on it too (well I think their ATX board does too); obviously using both at the same time won't work well.. Yes, the do, forget the model number, but the few we looked at we did not like the ASUS version as they went with the Ali chipset, and we have had better luck with the Via MVP3. We use the Soltek SL54U1/U5, works great, and if you want it in ATX DIMM only order the SL56D1. You can look at thier products on www.soltek.com.tw, we are an authorized distributor who stocks both the SL54U5 (was stocking SL54U1, but they are in very short supply due to cache chip shortage) and SL56D1. Both are sub $80.00 boards, both run FreeBSD just dandy. -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C597 fast ethernet support
I've got a 100Mbit 3COM EISA ethernet interface. Here are the particulars: vx0: 3Com 3C597-TX Network Adapter at 0x5000-0x501f, 0x5c80-0x5c89 vx0: irq 12 (edge) on eisa0 slot 5 I've been running it for a while now at 10Mbit. From what I can gather, the vx driver doesn't support fast ethernet. I'd be happy to lend the card to anyone interested The vx driver supports FE speeds, just not very well. The problem is caused by the fact that the vx driver uses the 3com programmed I/O mechanism for talking to the nic, and this protocol is just not up to dealing with 100mbit speeds because its 4-byte buffer is far too small to handle large amounts of data very quickly. Its been some while since I've used the vx driver myself, but I remember being pretty disappointed by the speed of it. There's more about this in http://www.freebsd.org/~wpaul/3Com/. Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world failure (signal 11 in cpp)
Hi folks, To answer my own question, I came into work this morning and found my console full of messages... spec_getpages: I/O read failure: (error code=0) bp 0xc36fe9a0 vp 0xc92ce000 size: 0, resid: 0, a_count: 4096, valid: 0x0 nread: 0, reqpage: 0, pindex: 9, pcount: 1 vm_fault: pager read error, pid 56587 (yacc) Aug 25 23:53:56 FreeBSD /kernel: pid 56587 (yacc), uid 0: exited on signal 11 (c ore dumped) spec_getpages: I/O read failure: (error code=0) bp 0xc36ffe20 vp 0xc92ce000 size: 0, resid: 0, a_count: 65536, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 16 spec_getpages: I/O read failure: (error code=0) bp 0xc37000b0 vp 0xc92ce000 size: 0, resid: 0, a_count: 4096, valid: 0x0 nread: 0, reqpage: 0, pindex: 9, pcount: 1 vm_fault: pager read error, pid 6178 (yacc) Aug 26 00:34:27 FreeBSD /kernel: pid 6178 (yacc), uid 0: exited on signal 11 (co re dumped) If I reboot my system with a kernel which is about two weeks old, things run fine... I'm not sure where to go from here... I'd appreciate any help. Again, my source (and kernel which is failing) is current as of 11:30pm EST, 8/25/99. Thanks, -John On Wednesday, 25 August 1999 at 23:39:56 -0400, John W. DeBoskey wrote: Hi, I'm having problems making world... before I dig into this, does anyone already know what's going on? My source is current as of 11:30pm EST. thanks, John === cpp cc -O -pipe -I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc -I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/config -DFREEBSD_NATIVE -DHAVE_CONFIG_H -DDEFAULT_TARGET_VERSION=\"egcs-2.91.66\" -DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -I/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -DPREFIX=\"/usr\" -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c yacc -o cexp.c /usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cexp.y *** Signal 11 The canonical explanation for this sort of thing is processor or memory problems. Would that fit? Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current kernel problems (spec_getpages vm_fault)
Hi, Following up my own mail on sig 11 problems, I beleive the problem is kernel related. Running a kernel with sources current as of 11:30am EST, I get the following during a make world: spec_getpages: I/O read failure: (error code=0) bp 0xc3700ec8 vp 0xc92ce000 size: 0, resid: 0, a_count: 12288, valid: 0x0 nread: 0, reqpage: 0, pindex: 14, pcount: 3 vm_fault: pager read error, pid 37394 (install) Aug 26 14:08:44 FreeBSD /kernel: pid 37394 (install), uid 0: exited on signal 11 (core dumped) which is generated by this portion of the make world: install -c -s -o root -g wheel -m 555 nvi /usr/obj/usr/src/tmp/usr/bin *** Signal 11 If I reboot with a kernel built on Aug 16, I can run a complete make world with no failures. I realize alot of changes have gone into the system over the last few days. If someone can give me some pointers on getting the information required to debug the problem, I'll be more than happy to dig into it. Thanks, John -- dmesg output for the machine in question: 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 #0: Thu Aug 26 13:47:34 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/FreeBSD Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 398775825 Hz CPU: Pentium II/Xeon/Celeron (398.78-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 = 134217728 (131072K bytes) avail memory = 126881792 (123908K bytes) Preloaded elf kernel "kernel" at 0xc0306000. Pentium Pro MTRR support enabled ccd0-3: Concatenated disk drivers 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: ATI model 4742 graphics accelerator irq 3 at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ide_pci0: Intel PIIX4 Bus-master IDE controller at device 7.1 on pci0 chip1: UHCI USB controller irq 11 at device 7.2 on pci0 chip2: Intel 82371AB Power management controller at device 7.3 on pci0 fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 10 at device 13.0 on pci0 fxp0: Ethernet address 00:a0:c9:2d:14:1b ahc0: Adaptec 2940 Ultra SCSI adapter irq 9 at device 14.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs pcib2: PCI to PCI bridge (vendor=1011 device=0024) at device 15.0 on pci0 pci2: PCI bus on pcib2 vga-pci1: Matrox MGA 2164W graphics accelerator irq 3 at device 9.0 on pci2 ahc1: Adaptec 2940/DUAL Ultra SCSI adapter irq 11 at device 10.0 on pci2 ahc1: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc2: Adaptec 2940/DUAL Ultra SCSI adapter irq 10 at device 10.1 on pci2 ahc2: aic7895 Single Channel B, SCSI Id=7, 16/255 SCBs ti0: 3Com 3c985-SX Gigabit Ethernet irq 3 at device 11.0 on pci2 ti0: Ethernet address: 00:60:08:f5:c6:e5 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 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa0 wdc0: unit 0 (wd0): Maxtor 90645D3, DMA, 32-bit, multi-block-16 wd0: 6149MB (12594960 sectors), 12495 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at port 0x170-0x177 irq 15 on isa0 wdc1: unit 0 (atapi): NEC CD-ROM DRIVE:28C/3.02, removable, dma, iordy wdc1: ATAPI CD-ROMs not configured 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: configured irq 3 not in bitmap of probed irqs 0 Waiting 5 seconds for SCSI devices to settle changing root device to wd0s1a da5 at ahc2 bus 0 target 3 lun 0 da5: iomega jaz 2GB E.16 Removable Direct Access SCSI-2 device da5: 20.000MB/s transfers (20.000MHz, offset 15) da5: 1911MB (3915600 512 byte sectors: 255H 63S/T 243C) da2 at ahc0 bus 0 target 3 lun 0 da2: SEAGATE ST19171W 0023 Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 8683MB (17783112 512 byte sectors: 255H 63S/T 1106C) da3 at ahc0 bus 0 target 4 lun 0 da3: SEAGATE ST19171W 0023 Fixed Direct Access SCSI-2 device da3: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da3: 8683MB (17783112 512 byte sectors: 255H 63S/T 1106C) da0 at ahc0 bus 0 target 1 lun 0 da0: SEAGATE ST34572W 0784 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8,
Re: -current kernel problems (spec_getpages vm_fault)
fixed earlier today... On Thu, 26 Aug 1999, John W. DeBoskey wrote: Hi, Following up my own mail on sig 11 problems, I beleive the problem is kernel related. Running a kernel with sources current as of 11:30am EST, I get the following during a make world: spec_getpages: I/O read failure: (error code=0) bp 0xc3700ec8 vp 0xc92ce000 size: 0, resid: 0, a_count: 12288, valid: 0x0 nread: 0, reqpage: 0, pindex: 14, pcount: 3 vm_fault: pager read error, pid 37394 (install) Aug 26 14:08:44 FreeBSD /kernel: pid 37394 (install), uid 0: exited on signal 11 (core dumped) which is generated by this portion of the make world: install -c -s -o root -g wheel -m 555 nvi /usr/obj/usr/src/tmp/usr/bin *** Signal 11 If I reboot with a kernel built on Aug 16, I can run a complete make world with no failures. I realize alot of changes have gone into the system over the last few days. If someone can give me some pointers on getting the information required to debug the problem, I'll be more than happy to dig into it. Thanks, John -- dmesg output for the machine in question: 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 #0: Thu Aug 26 13:47:34 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/FreeBSD Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 398775825 Hz CPU: Pentium II/Xeon/Celeron (398.78-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 = 134217728 (131072K bytes) avail memory = 126881792 (123908K bytes) Preloaded elf kernel "kernel" at 0xc0306000. Pentium Pro MTRR support enabled ccd0-3: Concatenated disk drivers 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: ATI model 4742 graphics accelerator irq 3 at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ide_pci0: Intel PIIX4 Bus-master IDE controller at device 7.1 on pci0 chip1: UHCI USB controller irq 11 at device 7.2 on pci0 chip2: Intel 82371AB Power management controller at device 7.3 on pci0 fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 10 at device 13.0 on pci0 fxp0: Ethernet address 00:a0:c9:2d:14:1b ahc0: Adaptec 2940 Ultra SCSI adapter irq 9 at device 14.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs pcib2: PCI to PCI bridge (vendor=1011 device=0024) at device 15.0 on pci0 pci2: PCI bus on pcib2 vga-pci1: Matrox MGA 2164W graphics accelerator irq 3 at device 9.0 on pci2 ahc1: Adaptec 2940/DUAL Ultra SCSI adapter irq 11 at device 10.0 on pci2 ahc1: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc2: Adaptec 2940/DUAL Ultra SCSI adapter irq 10 at device 10.1 on pci2 ahc2: aic7895 Single Channel B, SCSI Id=7, 16/255 SCBs ti0: 3Com 3c985-SX Gigabit Ethernet irq 3 at device 11.0 on pci2 ti0: Ethernet address: 00:60:08:f5:c6:e5 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 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa0 wdc0: unit 0 (wd0): Maxtor 90645D3, DMA, 32-bit, multi-block-16 wd0: 6149MB (12594960 sectors), 12495 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at port 0x170-0x177 irq 15 on isa0 wdc1: unit 0 (atapi): NEC CD-ROM DRIVE:28C/3.02, removable, dma, iordy wdc1: ATAPI CD-ROMs not configured 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: configured irq 3 not in bitmap of probed irqs 0 Waiting 5 seconds for SCSI devices to settle changing root device to wd0s1a da5 at ahc2 bus 0 target 3 lun 0 da5: iomega jaz 2GB E.16 Removable Direct Access SCSI-2 device da5: 20.000MB/s transfers (20.000MHz, offset 15) da5: 1911MB (3915600 512 byte sectors: 255H 63S/T 243C) da2 at ahc0 bus 0 target 3 lun 0 da2: SEAGATE ST19171W 0023 Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 8683MB (17783112 512 byte sectors: 255H 63S/T 1106C) da3 at ahc0 bus 0 target 4 lun 0 da3: SEAGATE ST19171W 0023 Fixed Direct Access SCSI-2 device da3: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da3: 8683MB (17783112
Re: -current kernel problems (spec_getpages vm_fault)
swapping on a vn device? the 'size' and 'resid' of 0 looks suspicious. a fix was just committed to teh vn code that may fix this if that's your problem. On Thu, 26 Aug 1999, John W. DeBoskey wrote: Hi, Following up my own mail on sig 11 problems, I beleive the problem is kernel related. Running a kernel with sources current as of 11:30am EST, I get the following during a make world: spec_getpages: I/O read failure: (error code=0) bp 0xc3700ec8 vp 0xc92ce000 size: 0, resid: 0, a_count: 12288, valid: 0x0 nread: 0, reqpage: 0, pindex: 14, pcount: 3 vm_fault: pager read error, pid 37394 (install) Aug 26 14:08:44 FreeBSD /kernel: pid 37394 (install), uid 0: exited on signal 11 (core dumped) which is generated by this portion of the make world: install -c -s -o root -g wheel -m 555 nvi /usr/obj/usr/src/tmp/usr/bin *** Signal 11 If I reboot with a kernel built on Aug 16, I can run a complete make world with no failures. I realize alot of changes have gone into the system over the last few days. If someone can give me some pointers on getting the information required to debug the problem, I'll be more than happy to dig into it. Thanks, John -- dmesg output for the machine in question: 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 #0: Thu Aug 26 13:47:34 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/FreeBSD Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 398775825 Hz CPU: Pentium II/Xeon/Celeron (398.78-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 = 134217728 (131072K bytes) avail memory = 126881792 (123908K bytes) Preloaded elf kernel "kernel" at 0xc0306000. Pentium Pro MTRR support enabled ccd0-3: Concatenated disk drivers 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: ATI model 4742 graphics accelerator irq 3 at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ide_pci0: Intel PIIX4 Bus-master IDE controller at device 7.1 on pci0 chip1: UHCI USB controller irq 11 at device 7.2 on pci0 chip2: Intel 82371AB Power management controller at device 7.3 on pci0 fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 10 at device 13.0 on pci0 fxp0: Ethernet address 00:a0:c9:2d:14:1b ahc0: Adaptec 2940 Ultra SCSI adapter irq 9 at device 14.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs pcib2: PCI to PCI bridge (vendor=1011 device=0024) at device 15.0 on pci0 pci2: PCI bus on pcib2 vga-pci1: Matrox MGA 2164W graphics accelerator irq 3 at device 9.0 on pci2 ahc1: Adaptec 2940/DUAL Ultra SCSI adapter irq 11 at device 10.0 on pci2 ahc1: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc2: Adaptec 2940/DUAL Ultra SCSI adapter irq 10 at device 10.1 on pci2 ahc2: aic7895 Single Channel B, SCSI Id=7, 16/255 SCBs ti0: 3Com 3c985-SX Gigabit Ethernet irq 3 at device 11.0 on pci2 ti0: Ethernet address: 00:60:08:f5:c6:e5 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 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa0 wdc0: unit 0 (wd0): Maxtor 90645D3, DMA, 32-bit, multi-block-16 wd0: 6149MB (12594960 sectors), 12495 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at port 0x170-0x177 irq 15 on isa0 wdc1: unit 0 (atapi): NEC CD-ROM DRIVE:28C/3.02, removable, dma, iordy wdc1: ATAPI CD-ROMs not configured 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: configured irq 3 not in bitmap of probed irqs 0 Waiting 5 seconds for SCSI devices to settle changing root device to wd0s1a da5 at ahc2 bus 0 target 3 lun 0 da5: iomega jaz 2GB E.16 Removable Direct Access SCSI-2 device da5: 20.000MB/s transfers (20.000MHz, offset 15) da5: 1911MB (3915600 512 byte sectors: 255H 63S/T 243C) da2 at ahc0 bus 0 target 3 lun 0 da2: SEAGATE ST19171W 0023 Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 8683MB (17783112 512 byte sectors: 255H 63S/T 1106C) da3 at ahc0 bus 0 target 4 lun 0 da3: SEAGATE ST19171W 0023 Fixed
Re: -current kernel problems (spec_getpages vm_fault)
:swapping on a vn device? :the 'size' and 'resid' of 0 looks suspicious. : :a fix was just committed to teh vn code that may fix this if that's your :problem. A fix was? When? Where? What? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
The size and resid of 0 is because it decides to use a sectorsize of zero due to the si_bsize fields being empty. In message [EMAIL PROTECTED], Jul ian Elischer writes: swapping on a vn device? the 'size' and 'resid' of 0 looks suspicious. a fix was just committed to teh vn code that may fix this if that's your problem. On Thu, 26 Aug 1999, John W. DeBoskey wrote: Hi, Following up my own mail on sig 11 problems, I beleive the problem is kernel related. Running a kernel with sources current as of 11:30am EST, I get the following during a make world: spec_getpages: I/O read failure: (error code=0) bp 0xc3700ec8 vp 0xc92ce000 size: 0, resid: 0, a_count: 12288, valid: 0x0 nread: 0, reqpage: 0, pindex: 14, pcount: 3 vm_fault: pager read error, pid 37394 (install) Aug 26 14:08:44 FreeBSD /kernel: pid 37394 (install), uid 0: exited on signal 11 (core dumped) which is generated by this portion of the make world: install -c -s -o root -g wheel -m 555 nvi /usr/obj/usr/src/tmp/usr/bin *** Signal 11 If I reboot with a kernel built on Aug 16, I can run a complete make world with no failures. I realize alot of changes have gone into the system over the last few days. If someone can give me some pointers on getting the information required to debug the problem, I'll be more than happy to dig into it. Thanks, John -- dmesg output for the machine in question: 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 #0: Thu Aug 26 13:47:34 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/FreeBSD Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 398775825 Hz CPU: Pentium II/Xeon/Celeron (398.78-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 = 134217728 (131072K bytes) avail memory = 126881792 (123908K bytes) Preloaded elf kernel "kernel" at 0xc0306000. Pentium Pro MTRR support enabled ccd0-3: Concatenated disk drivers 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: ATI model 4742 graphics accelerator irq 3 at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ide_pci0: Intel PIIX4 Bus-master IDE controller at device 7.1 on pci0 chip1: UHCI USB controller irq 11 at device 7.2 on pci0 chip2: Intel 82371AB Power management controller at device 7.3 on pci0 fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 10 at device 13.0 on pci0 fxp0: Ethernet address 00:a0:c9:2d:14:1b ahc0: Adaptec 2940 Ultra SCSI adapter irq 9 at device 14.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs pcib2: PCI to PCI bridge (vendor=1011 device=0024) at device 15.0 on pci0 pci2: PCI bus on pcib2 vga-pci1: Matrox MGA 2164W graphics accelerator irq 3 at device 9.0 on pci2 ahc1: Adaptec 2940/DUAL Ultra SCSI adapter irq 11 at device 10.0 on pci2 ahc1: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc2: Adaptec 2940/DUAL Ultra SCSI adapter irq 10 at device 10.1 on pci2 ahc2: aic7895 Single Channel B, SCSI Id=7, 16/255 SCBs ti0: 3Com 3c985-SX Gigabit Ethernet irq 3 at device 11.0 on pci2 ti0: Ethernet address: 00:60:08:f5:c6:e5 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 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa0 wdc0: unit 0 (wd0): Maxtor 90645D3, DMA, 32-bit, multi-block-16 wd0: 6149MB (12594960 sectors), 12495 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at port 0x170-0x177 irq 15 on isa0 wdc1: unit 0 (atapi): NEC CD-ROM DRIVE:28C/3.02, removable, dma, iordy wdc1: ATAPI CD-ROMs not configured 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: configured irq 3 not in bitmap of probed irqs 0 Waiting 5 seconds for SCSI devices to settle changing root device to wd0s1a da5 at ahc2 bus 0 target 3 lun 0 da5: iomega jaz 2GB E.16 Removable Direct Access SCSI-2 device da5: 20.000MB/s transfers (20.000MHz, offset 15) da5: 1911MB (3915600 512 byte sectors: 255H 63S/T 243C) da2 at ahc0 bus 0 target 3 lun 0 da2: SEAGATE ST19171W 0023 Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz,
Re: Docs blows up make release
-stable, -current, On Sun, Aug 22, 1999 at 11:05:11AM +0100, Nik Clayton wrote: [ cc'd to -current ] On Sat, Aug 21, 1999 at 07:54:51PM -0400, jack wrote: mode ugly monolingual American Will support for building release docs in English only be revived? /mode For the immediate future, it looks like it will -- it seems as though we don't have the man power to make the necessary changes to sysinstall to support "installing the docs as packages", so I'm going to fix up src/release/Makefile as necessary to cope with the new directory structure. With thanks to Jack O'Neill, this is now done. They're only in -current at the moment, but they should backport to -stable fairly easily. I'd be obliged if those if you who like to do these things grabbed a copy of -current that has r1.504 of src/release/Makefile, and tried building a release with that, and a copy of the doc/ tree that's of a similar vintage. Everything should pretty much work. Brickbats should be sent my way if it doesn't. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
I am positive that I just saw a checkin from phk that initialised the initial default transfer size. On Thu, 26 Aug 1999, Matthew Dillon wrote: :swapping on a vn device? :the 'size' and 'resid' of 0 looks suspicious. : :a fix was just committed to teh vn code that may fix this if that's your :problem. A fix was? When? Where? What? -Matt 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: -current kernel problems (spec_getpages vm_fault)
On Thu, 26 Aug 1999, Poul-Henning Kamp wrote: The size and resid of 0 is because it decides to use a sectorsize of zero due to the si_bsize fields being empty. yes, but didn't I just see you commit a fix for that? In message [EMAIL PROTECTED], Jul ian Elischer writes: swapping on a vn device? the 'size' and 'resid' of 0 looks suspicious. a fix was just committed to teh vn code that may fix this if that's your problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
which would be this commit... phk 1999/08/26 07:46:11 PDT Modified files: sys/dev/ccd ccd.c Log: Initialize the dev-si_bsize fields. Submitted by: tegge Reviewed by: phk Revision ChangesPath 1.53 +5 -1 src/sys/dev/ccd/ccd.c I need to figure out why my 11:30am EST cvsup didn't pick this file up. It's 44 minutes infront of cvsup... Thanks! john The size and resid of 0 is because it decides to use a sectorsize of zero due to the si_bsize fields being empty. In message [EMAIL PROTECTED], Jul ian Elischer writes: swapping on a vn device? the 'size' and 'resid' of 0 looks suspicious. a fix was just committed to teh vn code that may fix this if that's your problem. On Thu, 26 Aug 1999, John W. DeBoskey wrote: Hi, Following up my own mail on sig 11 problems, I beleive the problem is kernel related. Running a kernel with sources current as of 11:30am EST, I get the following during a make world: spec_getpages: I/O read failure: (error code=0) bp 0xc3700ec8 vp 0xc92ce000 size: 0, resid: 0, a_count: 12288, valid: 0x0 nread: 0, reqpage: 0, pindex: 14, pcount: 3 vm_fault: pager read error, pid 37394 (install) Aug 26 14:08:44 FreeBSD /kernel: pid 37394 (install), uid 0: exited on signal 11 (core dumped) which is generated by this portion of the make world: install -c -s -o root -g wheel -m 555 nvi /usr/obj/usr/src/tmp/usr/bin *** Signal 11 If I reboot with a kernel built on Aug 16, I can run a complete make world with no failures. I realize alot of changes have gone into the system over the last few days. If someone can give me some pointers on getting the information required to debug the problem, I'll be more than happy to dig into it. Thanks, John -- dmesg output for the machine in question: 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 #0: Thu Aug 26 13:47:34 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/FreeBSD Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 398775825 Hz CPU: Pentium II/Xeon/Celeron (398.78-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 = 134217728 (131072K bytes) avail memory = 126881792 (123908K bytes) Preloaded elf kernel "kernel" at 0xc0306000. Pentium Pro MTRR support enabled ccd0-3: Concatenated disk drivers 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: ATI model 4742 graphics accelerator irq 3 at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ide_pci0: Intel PIIX4 Bus-master IDE controller at device 7.1 on pci0 chip1: UHCI USB controller irq 11 at device 7.2 on pci0 chip2: Intel 82371AB Power management controller at device 7.3 on pci0 fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 10 at device 13.0 on pci0 fxp0: Ethernet address 00:a0:c9:2d:14:1b ahc0: Adaptec 2940 Ultra SCSI adapter irq 9 at device 14.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs pcib2: PCI to PCI bridge (vendor=1011 device=0024) at device 15.0 on pci0 pci2: PCI bus on pcib2 vga-pci1: Matrox MGA 2164W graphics accelerator irq 3 at device 9.0 on pci2 ahc1: Adaptec 2940/DUAL Ultra SCSI adapter irq 11 at device 10.0 on pci2 ahc1: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc2: Adaptec 2940/DUAL Ultra SCSI adapter irq 10 at device 10.1 on pci2 ahc2: aic7895 Single Channel B, SCSI Id=7, 16/255 SCBs ti0: 3Com 3c985-SX Gigabit Ethernet irq 3 at device 11.0 on pci2 ti0: Ethernet address: 00:60:08:f5:c6:e5 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 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa0 wdc0: unit 0 (wd0): Maxtor 90645D3, DMA, 32-bit, multi-block-16 wd0: 6149MB (12594960 sectors), 12495 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at port 0x170-0x177 irq 15 on isa0 wdc1: unit 0 (atapi): NEC CD-ROM DRIVE:28C/3.02, removable, dma, iordy wdc1: ATAPI CD-ROMs not configured 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
Re: -current kernel problems (spec_getpages vm_fault)
Ah my mistake, it was ccd. I remembered vn. I guess vinum, vn, and ccd need all have the correct bisize code.. On Thu, 26 Aug 1999, John W. DeBoskey wrote: which would be this commit... phk 1999/08/26 07:46:11 PDT Modified files: sys/dev/ccd ccd.c Log: Initialize the dev-si_bsize fields. Submitted by: tegge Reviewed by: phk Revision ChangesPath 1.53 +5 -1 src/sys/dev/ccd/ccd.c I need to figure out why my 11:30am EST cvsup didn't pick this file up. It's 44 minutes infront of cvsup... Thanks! john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
That fixes a problem with ccd, but not the one causing John's failures. You will note that with John's failure's the I/O is properly page-aligned. The fix to ccd deals with a misalignment problem. But I believe I have found the problem... it is a bug in vm/swap_pager.c that occurs when you have more then one swap partition. The code is improperly crossing a physical disk device boundry and vm/vm_swap.c is returning a failure because of that. For example, if you attempt to read 8K from a swap-backed VN device and 4K of it is in one swap partition and the other 4K is in another, vm/swap_pager.c is not properly breaking up the transaction. I'll have a fix in a moment. -Matt :which would be this commit... : :phk 1999/08/26 07:46:11 PDT : : Modified files: :sys/dev/ccd ccd.c : Log: : Initialize the dev-si_bsize fields. : : Submitted by: tegge : Reviewed by: phk : : Revision ChangesPath : 1.53 +5 -1 src/sys/dev/ccd/ccd.c : : : I need to figure out why my 11:30am EST cvsup didn't pick :this file up. It's 44 minutes infront of cvsup... : :Thanks! :john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
tentative fix (was Re: -current kernel problems (spec_getpages vm_fault))
The first part of this patch is not yet part of my multipatch at
http://www.backplane.com/FreeBSD4/
This is a tentative fix, but I believe it to be correct. Until
yesterday I was testing swap-backed VN with only one swap partition,
otherwise this would have been found and fixed long ago :-(
I'm doing a buildworld stress test now to make sure it's been fixed.
-Matt
Index: swap_pager.c
===
RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v
retrieving revision 1.124
diff -u -r1.124 swap_pager.c
--- swap_pager.c1999/08/23 23:55:03 1.124
+++ swap_pager.c1999/08/26 20:20:09
@@ -830,13 +830,19 @@
splx(s);
/*
-* Do we have to flush our current collection?
+* Do we have to flush our current collection? Yes if:
+*
+* - no swap block at this index
+* - swap block is not contiguous
+* - we cross a physical disk boundry in the
+*stripe.
*/
if (
nbp (
(blk SWAPBLK_NONE) ||
-nbp-b_blkno + btoc(nbp-b_bcount) != blk
+nbp-b_blkno + btoc(nbp-b_bcount) != blk ||
+((nbp-b_blkno ^ blk) dmmax_mask)
)
) {
++cnt.v_swapin;
@@ -857,6 +863,7 @@
if (nbp == NULL) {
nbp = getchainbuf(bp, swapdev_vp,
B_READ|B_ASYNC);
nbp-b_blkno = blk;
+ nbp-b_bcount = 0;
nbp-b_data = data;
}
nbp-b_bcount += PAGE_SIZE;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
On Thu, Aug 26, 1999 at 10:35:27PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Matthew Dillon writes: That fixes a problem with ccd, but not the one causing John's failures. You will note that with John's failure's the I/O is properly page-aligned. The fix to ccd deals with a misalignment problem. No it doesn't. johns failure is clearly the si_bsize* problem, the tell-tale sign is all the zeros in there. What John didn't tell us is if he uses vn, ccd or vinum (or something else!) Well, I just had much the same blowup with source from last night and I'm using vinum, (and not vn or ccd). Recompiling now to see if it's still there. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
In message [EMAIL PROTECTED], Christopher Masto writes:
On Thu, Aug 26, 1999 at 10:35:27PM +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Matthew Dillon writes:
That fixes a problem with ccd, but not the one causing John's failures.
You will note that with John's failure's the I/O is properly page-aligned.
The fix to ccd deals with a misalignment problem.
No it doesn't. johns failure is clearly the si_bsize* problem, the
tell-tale sign is all the zeros in there. What John didn't tell
us is if he uses vn, ccd or vinum (or something else!)
Well, I just had much the same blowup with source from last night
and I'm using vinum, (and not vn or ccd).
Recompiling now to see if it's still there.
Ok, I havn't touched vinum (grog generally want to do this himself),
the fix is probably something like this:
Index: vinum.c
===
RCS file: /home/ncvs/src/sys/dev/vinum/vinum.c,v
retrieving revision 1.29
diff -u -r1.29 vinum.c
--- vinum.c 1999/08/24 02:18:55 1.29
+++ vinum.c 1999/08/26 21:04:03
@@ -271,6 +271,9 @@
int devminor; /* minor number */
devminor = minor(dev);
+dev-si_bsize_phys = DEV_BSIZE;
+dev-si_bsize_best = BLKDEV_IOSIZE;
+dev-si_bsize_max = MAXBSIZE;
error = 0;
/* First, decide what we're looking at */
switch (DEVTYPE(dev)) {
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
On Thu, Aug 26, 1999 at 11:04:44PM +0200, Poul-Henning Kamp wrote: Well, I just had much the same blowup with source from last night and I'm using vinum, (and not vn or ccd). Recompiling now to see if it's still there. Ok, I havn't touched vinum (grog generally want to do this himself), I will try that fix next. FYI, here's what it looked like: (I don't know what's with the garbage, maybe it was my serial console) [everything apparently normal until..] Doing initial network setup: hostname. lgo0: flags=8049UeP,LOOPBACK,RUNNIsNG,MULTICAST mt:u 16384 inet 1 27.0.0.1 netmaskI 0xff00 /O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 60512, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 15 Flushed all rules. 00100 allow ip from any to any via lo0 00200 deny ip from asny to 127.0.0.0/p8 65000 allow iep from any to ancy Firewall rule_s loaded, startigng divert daemones:. add net deftault: gateway 16p7.206.208.254 Aadditional routingg options: tcp eextensions=NO TCPs keepalive=YES.: routing daemons :. Mounting NFSI file systems. /O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 5672, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 2 /etc/rc: chflags: I/O error /etc/rc: chown: sI/O error padditional daemoens:c_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 24352, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 6 syslogd/etc/rc: syslogds: I/O error p. ec_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 8192, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 2 Doing additionals network setup: pportmape/etc/rc: /usr/sbcin/portmap: I/O _error getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 8192, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 2 . Starting finasl network daemonps:. e/etc/rc: kvm_mkdcb: I/O error _getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 4132, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 2 /etc/rc: dev_mkdb: I/O error spec_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 49152, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 12 /etc/rc: /usr/bin/objformat: I/O error setting a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout starting standarsd daemons:p inetdec_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 24576, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 6 /etc/rc: inetd: sI/O error p cronec_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 24576, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 6 /etc/rc: cron: Is/O error p sendmailec_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 57344, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 14 /etc/rc: /usr/sbsin/sendmail: I/Op error e. c_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 4088, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 1 /etc/rc: uname: I/O error Local package initialization:spec_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a86c0 size: 0, resid: 0, a_count: 75, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 1 /etc/rc: /usr/loscal/etc/rc.d/50.pm3.sh: I/O errore c_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a86c0 size: 0, resid: 0, a_count: 81, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 1 /etc/rc: /usr/loscal/etc/rc.d/sshpd.sh: I/O errore c. _getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 4248, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 2 /etc/rc: mktemp: I/O error Thu Aug 26 16:14:22 EDT 1999cu: Got hangup signal I'll let you know if the patch to vinum cures it. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
In article [EMAIL PROTECTED], John W. DeBoskey [EMAIL PROTECTED] wrote: I need to figure out why my 11:30am EST cvsup didn't pick this file up. It's 44 minutes infront of cvsup... Most mirror sites update themselves hourly from cvsup-master, which updates itself every 6 minutes from freefall. If the file still isn't there after 1 hour 6 minutes, then please send me the details. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
On Thu, Aug 26, 1999 at 11:04:44PM +0200, Poul-Henning Kamp wrote: Ok, I havn't touched vinum (grog generally want to do this himself), the fix is probably something like this: Index: vinum.c === RCS file: /home/ncvs/src/sys/dev/vinum/vinum.c,v retrieving revision 1.29 diff -u -r1.29 vinum.c --- vinum.c 1999/08/24 02:18:55 1.29 +++ vinum.c 1999/08/26 21:04:03 @@ -271,6 +271,9 @@ int devminor;/* minor number */ devminor = minor(dev); +dev-si_bsize_phys = DEV_BSIZE; +dev-si_bsize_best = BLKDEV_IOSIZE; +dev-si_bsize_max = MAXBSIZE; Bingo! Thank you. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
In message [EMAIL PROTECTED], Christopher Masto writes: Index: vinum.c === RCS file: /home/ncvs/src/sys/dev/vinum/vinum.c,v retrieving revision 1.29 diff -u -r1.29 vinum.c --- vinum.c 1999/08/24 02:18:55 1.29 +++ vinum.c 1999/08/26 21:04:03 @@ -271,6 +271,9 @@ int devminor; /* minor number */ devminor = minor(dev); +dev-si_bsize_phys = DEV_BSIZE; +dev-si_bsize_best = BLKDEV_IOSIZE; +dev-si_bsize_max = MAXBSIZE; Bingo! Thank you. Cool, I expect grog will commit it soon. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
In message 15454.935598612@localhost "Jordan K. Hubbard" writes: : I think people are being almost clinically paranoid here. Hasbro and : folks got upset over TRADEMARK infringement, e.g. from using a name : they had trademarked. I rather doubt that Warner Bros. have managed : to trademark the name "matrix" since it's already a common english : word. "Boggle" and "Tetris" don't fall into that category. Hasbro has sued the owners of Clue.com (Clue Computing) for trademark infringement. clue is a word from the dictionary... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
: int devminor; /* minor number */ : : devminor = minor(dev); : +dev-si_bsize_phys = DEV_BSIZE; : +dev-si_bsize_best = BLKDEV_IOSIZE; : +dev-si_bsize_max = MAXBSIZE; : :Bingo! Thank you. : :Cool, I expect grog will commit it soon. : :-- :Poul-Henning Kamp FreeBSD coreteam member :[EMAIL PROTECTED] "Real hackers run -current on their laptop." The patch for ccd is not quite right. Here is the patch from my big fat patch at http://www.backplane.com/FreeBSD4/ The problem is that you cannot simply set the physical sector size to DEV_BSIZE if the underlying device has a larger sector size. If you do, specfs's blocksize alignment (another fix in my big fat patch) will be incorrect and result in an I/O error on the physical media. For example, swap-backed VN devices have a sector size of one page, i.e. 4K. -Matt Matthew Dillon [EMAIL PROTECTED] Index: ccd.c === RCS file: /home/ncvs/src/sys/dev/ccd/ccd.c,v retrieving revision 1.53 diff -u -r1.53 ccd.c --- ccd.c 1999/08/26 14:46:10 1.53 +++ ccd.c 1999/08/26 23:22:43 @@ -1417,6 +1417,12 @@ lp-d_ncylinders = ccg-ccg_ncylinders; lp-d_secpercyl = lp-d_ntracks * lp-d_nsectors; + dev-si_bsize_phys = lp-d_secsize; + dev-si_bsize_best = BLKDEV_IOSIZE; + dev-si_bsize_max = MAXBSIZE; +if (dev-si_bsize_best lp-d_secsize) +dev-si_bsize_best = lp-d_secsize; + strncpy(lp-d_typename, "ccd", sizeof(lp-d_typename)); lp-d_type = DTYPE_CCD; strncpy(lp-d_packname, "fictitious", sizeof(lp-d_packname)); To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
multipatch #5 available (includes VN CCD fixes)
I've synced my source tree and updated my big-fat patch to include fixes to the VN device and CCD device as well as all the other stuff it already contains. http://www.backplane.com/FreeBSD4/ -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
On Thursday, 26 August 1999 at 22:35:27 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Matthew Dillon writes: That fixes a problem with ccd, but not the one causing John's failures. You will note that with John's failure's the I/O is properly page-aligned. The fix to ccd deals with a misalignment problem. No it doesn't. johns failure is clearly the si_bsize* problem, the tell-tale sign is all the zeros in there. What John didn't tell us is if he uses vn, ccd or vinum (or something else!) Indirectly he told us that he's not using Vinum. If you're running Vinum, you'll see something like this in the dmesg output: ... da4: CDC 94181-15 0293 Fixed Direct Access SCSI-CCS device da4: 3.300MB/s transfers da4: 573MB (1173930 512 byte sectors: 64H 32S/T 573C) vinum: loaded vinum: reading configuration from /dev/da5e vinum: updating configuration from /dev/da3h vinum: updating configuration from /dev/da4h vinum: updating configuration from /dev/da1s1h vinum: updating configuration from /dev/da2h Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Existance of /var/backups for periodic/daily
On 16 Aug, Rodney W. Grimes wrote:
The 200-220 periodic files under daily expect that the directory
/var/backups exist when they run to back up various files. If you
delete this directory, the "cp" commands will error.
There seems to be two ways to fix the files.
1. Add a "if [ ! -d $bak ] ; then exit fi" to the top
of the files, or
2. Add a "mkdir -p $bak" to the top.
Do others consider this an error, and if so which is the preferred
fix?
I consider it an error, but prefer neither fix, here is something more
defensive and verbose in light of failure modes:
if [ ! -e $bak ] ; then
echo "${0}: $bak missing, creating";
mkdir -p $bak;
else
if [ ! -d $bak ] ; then
echo "${0}: $bak exists and is not a directory, aborting";
exit 1;
fi
fi
Another take on this is to *not* do the backups if the directory doesn't
exist... I'll probably send-pr something like the above however
--
Stephen J. Roznowski([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Docs blows up make release
* From: "Jordan K. Hubbard" [EMAIL PROTECTED] * This makes the ports tree have a dependency on the doc tree. I don't think * this dependency should be there. It's bad enough that the src/ tree * depends on doc/ (and the reason I want the documentation available as * packages is to remove this dependency), having ports depend on the doc tree * as well just means that when things go out of sync in doc for a while I get * both you and Satoshi complaining at me, instead of just you :-) * * Erm, I think the ports tree is pretty darn loose about "dependencies" * since they're easily updated. Consider, for example, the fact that * some ports are dependent on the organization of binary tarballs over * at Netscape, or depend on WordPerfect's linux distribution RPM. Those * are some pretty heavy deps, and depending on something in our own doc * tree is certainly no worse. :) Yes. It shouldn't be hard to keep them synced, just like all the other ports that require the src tree to be around. Another advantage of having them in the ports tree is the build checking done at regular intervals. All the japanese/handbook stuff that's going on right now, these are the problems of the textproc/docbook* ports (missing files from PLIST, missing dependencies). People installing these from packages will see the exact same problem when they try to build the handbook (with or without the japanese/handbook port). * Putting the package building rules in the doc/ Makefiles also (and this * is just my personal opinion) makes it easier for people to see how the * documentation packages are built. The ports Makefile structure is a * marvel, but it contains a lot of code that's not necessary for building * documentation packages (the "automagically add man pages to the PLIST * i" code, for example) that makes it more difficult for the interested * learner to browse and understand what's going on. * * Now this is a point which is more germin. So, you figure on making a * similar sort of "package" target under doc? I guess it really doesn't * matter where these things live, as long as it's still automated.. The chief concern I have is that this might result in yet another place you (Jordan) have to pick up stuff from before the release. Having these as ports will at least put them on the normal distribution channel along with all the other packages. Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Softupdates reliability?
On Thu, 26 Aug 1999, Rodney W. Grimes wrote: You can look at thier products on www.soltek.com.tw, we are an authorized distributor who stocks both the SL54U5 (was stocking SL54U1, but they are in very short supply due to cache chip shortage) and SL56D1. Both are sub $80.00 boards, both run FreeBSD just dandy. Well, right now I'm happy with my BX based board. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
Hi, Sorry for taking so long to reply. I have an isdn line to my office which has been acting up lately (or should I say acting down?). Anyways, yes, I am using a ccd. I also have a machine with a dpt raid4 controller that I probably need to check to see if it still works My setup is below: Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/wd0s1a25406335349 19838915%/ /dev/wd0s1g 3054702 1218081 159224543%/mirror /dev/wd0s1f 2032623 981267 88874752%/usr /dev/wd0s1e508143 251009 21648354%/var mfs:60 89287 636175784 8%/tmp procfs 440 100%/proc /dev/ccd0a32778302 3015602 0%/usr/obj /dev/ccd0b5384181 1100 4952347 0%/snap /dev/ccd1c 17235719 6912829 894403344%/pub /dev/da4c 2032500 355979 151392119%/cdwork bbsrv01:/afs 9000 900 0%/afs pid209@FreeBSD:/u 000 100%/u pid209@FreeBSD:/nfs 000 100%/nfs I have 2 ccd setups, one which is the entire array, and one which is partitioned. With the new kernel from earlier today, they all seem to be behaving much better now. Thanks folks! John On Thursday, 26 August 1999 at 22:35:27 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Matthew Dillon writes: That fixes a problem with ccd, but not the one causing John's failures. You will note that with John's failure's the I/O is properly page-aligned. The fix to ccd deals with a misalignment problem. No it doesn't. johns failure is clearly the si_bsize* problem, the tell-tale sign is all the zeros in there. What John didn't tell us is if he uses vn, ccd or vinum (or something else!) Indirectly he told us that he's not using Vinum. If you're running Vinum, you'll see something like this in the dmesg output: ... da4: CDC 94181-15 0293 Fixed Direct Access SCSI-CCS device da4: 3.300MB/s transfers da4: 573MB (1173930 512 byte sectors: 64H 32S/T 573C) vinum: loaded vinum: reading configuration from /dev/da5e vinum: updating configuration from /dev/da3h vinum: updating configuration from /dev/da4h vinum: updating configuration from /dev/da1s1h vinum: updating configuration from /dev/da2h Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
On Thursday, 26 August 1999 at 16:25:14 -0700, Matthew Dillon wrote: int devminor; /* minor number */ devminor = minor(dev); +dev-si_bsize_phys = DEV_BSIZE; +dev-si_bsize_best = BLKDEV_IOSIZE; +dev-si_bsize_max = MAXBSIZE; Bingo! Thank you. Cool, I expect grog will commit it soon. So did I until I read this message. The patch for ccd is not quite right. Here is the patch from my big fat patch at http://www.backplane.com/FreeBSD4/ The problem is that you cannot simply set the physical sector size to DEV_BSIZE if the underlying device has a larger sector size. If you do, specfs's blocksize alignment (another fix in my big fat patch) will be incorrect and result in an I/O error on the physical media. For example, swap-backed VN devices have a sector size of one page, i.e. 4K. Vinum currently doesn't track the sector size of the drives. I'll have to put some code in there to DTRT. In the meantime, I'll set si_bsize_best to 4K in the hope that this will be OK. Are there any larger block sizes in current use? Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
