Re: NFS/Vinum problems
:The thing is i'm not sure if it's vinum, I could also duplicate this on
:another machine without vinum.. except I duplicated it differently..
:
:Consider the following perl script:
:
:#!/usr/bin/perl
:for ( ; ; ) {
:system("fetch http://www.web.site/index.html");
:}
:
:Of course, replacing the site with something else, but on this one box
:(and the raid), it panic'd the box.. See if you can duplicate this on any
:4.0/5.0 boxes you have, I have tried on both and it worked, however it
:does not crash 3.x boxes..
:
:Try your luck,
:Jason DiCioccio
Ok, I'm a bit confused.
You are running this script on the NFS client while CD'd into an
NFS mount and the NFS server is crashing?
Or are you running this on the NFS server while CD'd into a local
disk mount and the NFS server is crashing?
I presume the web site you are fetching from is not crashing.
Have you tried exporting a non-raid mount from the server to the
client to see if that crashes? The only thing that happens to me
when I run the above script on an NFS client while CD'd into an NFS
server is that the client winds up with thousands of sockets
in TIME_WAIT on the client until it runs out and starts getting
'socket is not connected' errors (I was using a web server on my LAN
so the fetches were completeing very quickly). But the NFS
server didn't have any problems.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NFS/Vinum problems
::Jason DiCioccio Another possibility -- could you post your 'dmesg' output? One thing that NFS does do is severely exercise both the network and the SCSI device in a concurrent fashion. If you happen to be using an NCR SCSI chipset, that could be the cause of the problem (though I have never in my life seen the panic message you posted in relation to the NCR cards). If you can get the panic regularly then it may be worthwhile trying to get some more information out of it. If you compile up a kernel with the DDB option and your console is not running X, then the kernel will drop into DDB on the console when it panics and allow you to do a stack 'trace'. You may also be able to then dump the machine by typing 'panic' manually at the ddb prompt after copying down the trace information. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/Vinum problems
Here is my dmesg output, and btw, sorry.. the perl script was not running on the NFS volume, just regularly on a regular 4.0 box, and it crashed the box (yes, I had login limits set), I was just giving another example of what seems to be some instability in 4.0 under high loads.. Here my dmesg from the raid/nfs server: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Fri Mar 31 00:03:37 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/RAID Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 186006596 Hz CPU: IDT WinChip C6 (186.01-MHz 586-class CPU) Origin = "CentaurHauls" Id = 0x541 Stepping = 1 Features=0x8000b5FPU,DE,TSC,MSR,MCE,MMX real memory = 50331648 (49152K bytes) config en ed0 config po ed0 0x240 config ir ed0 5 config iom ed0 0xd8000 config f ed0 0 config q avail memory = 45297664 (44236K bytes) Preloaded elf kernel "kernel" at 0xc036f000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc036f09c. npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: DEC 21050 PCI-PCI bridge at device 3.0 on pci0 pci1: PCI bus on pcib1 isab0: Intel 82375EB PCI-EISA bridge at device 4.0 on pci0 eisa0: EISA bus on isab0 mainboard0: HWPc0d1 (System Board) on eisa0 slot 0 isa0: ISA bus on isab0 ahc0: Adaptec aic7855 SCSI adapter port 0xf800-0xf8ff mem 0xfedff000-0xfed f irq 15 at device 5.0 on pci0 ahc0: Using left over BIOS settings ahc0: aic7855 Single Channel A, SCSI Id=7, 3/255 SCBs ahc1: Adaptec aic7855 SCSI adapter port 0xf400-0xf4ff mem 0xfedfe000-0xfedfeff f irq 15 at device 6.0 on pci0 ahc1: Using left over BIOS settings ahc1: aic7855 Single Channel A, SCSI Id=7, 3/255 SCBs fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3b0-0x3cf iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA (mono) 16 virtual consoles, flags=0x200 ed0 at port 0x240-0x25f iomem 0xd8000-0xd9fff irq 5 drq 0 on isa0 ed0: address 00:00:c0:00:dc:ba, type SMC8416T (16 bit) Waiting 15 seconds for SCSI devices to settle vinum: loaded da1 at ahc1 bus 0 target 1 lun 0 da1: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da5 at ahc1 bus 0 target 5 lun 0 da5: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da5: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da5: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da6 at ahc1 bus 0 target 6 lun 0 da6: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da6: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da6: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da4 at ahc1 bus 0 target 4 lun 0 da4: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da4: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da4: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da3 at ahc1 bus 0 target 3 lun 0 da3: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da3: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da3: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da2 at ahc1 bus 0 target 2 lun 0 da2: HP 2.13 GB 1st ### 1212 Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da2: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) Mounting root from ufs:/dev/da0s1a cd0 at ahc0 bus 0 target 5 lun 0 cd0: TOSHIBA CD-ROM XM-5301TA 1535 Removable CD-ROM SCSI-2 device cd0: 4.032MB/s transfers (4.032MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present da0 at ahc0 bus 0 target 0 lun 0 da0: SGI SeagateST12550N 2703 Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 2048MB (4195116 512 byte sectors: 64H 32S/T 2048C) WARNING: / was not properly dismounted vinum: reading configuration from /dev/da6s1e vinum: updating configuration from /dev/da5s1e vinum: updating configuration from /dev/da4s1e vinum: updating configuration from /dev/da3s1e vinum: updating configuration from /dev/da2s1e vinum: updating configuration from /dev/da1s1e I hope this helps.. and i'll setup crash dumping on raid, thanks for your time On Fri, 31 Mar 2000, Matthew Dillon wrote: ::Jason DiCioccio Another possibility -- could you post your 'dmesg' output? One thing that NFS does do is severely exercise both the network and the SCSI device in a concurrent fashion. If you happen to be using an NCR SCSI chipset, that could be the
Re: NFS/Vinum problems
One more thing, here's my kernel config file just in case you need it: machine i386 cpu I586_CPU ident RAID maxusers64 makeoptions DEBUG=-g#Build kernel with gdb(1) debug options DDB_UNATTENDED options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep options NFS #Network Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM#Rate limit bad replies options NMBCLUSTERS=10240 options VINUMDEBUG #enable Vinum debugging hooks device isa device eisa device pci # Floppy drives device fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device cd # CD device pass# Passthrough device (direct SCSI access) device mlx # Mylex DAC960 family # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device vga0at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? # Floating point support - do not disable. device npx0at nexus? port IO_NPX irq 13 # ISA Ethernet NICs. device ed0 at isa? port 0x240 irq 5 iomem 0xd8000 # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop# Network loopback pseudo-device ether # Ethernet support pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device vinum #Vinum concat/mirror/raid driver pseudo-device snp # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter On Fri, 31 Mar 2000, Matthew Dillon wrote: ::Jason DiCioccio Another possibility -- could you post your 'dmesg' output? One thing that NFS does do is severely exercise both the network and the SCSI device in a concurrent fashion. If you happen to be using an NCR SCSI chipset, that could be the cause of the problem (though I have never in my life seen the panic message you posted in relation to the NCR cards). If you can get the panic regularly then it may be worthwhile trying to get some more information out of it. If you compile up a kernel with the DDB option and your console is not running X, then the kernel will drop into DDB on the console when it panics and allow you to do a stack 'trace'. You may also be able to then dump the machine by typing 'panic' manually at the ddb prompt after copying down the trace information. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
