usb stick problem
Howdy! I encountered something minor to usual problems, people have on this list, but it makes me nervous. I bought brand new usb flash stick and used it to solve the issue on handheld. After putting files on it, I have them in format 8.3. The option to mount -t was msdosfs. It should bring me long file names, but it does not. Mu stupid question would be: did I chose wrong file system? Or is this usb drive preformatted in something strange like fat16? This manner surprised me so much, that I did not believed my eyes. 6.2 on amd64. Best regards Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek eth isn't detected in Intel DG31PR mobo
On 10/11/07, Pyun YongHyeon [EMAIL PROTECTED] wrote: On Wed, Oct 10, 2007 at 05:08:13PM +0300, Abdullah Ibn Hamad Al-Marri wrote: On 10/10/07, Pyun YongHyeon [EMAIL PROTECTED] wrote: On Wed, Oct 10, 2007 at 04:46:50AM +0300, Abdullah Ibn Hamad Al-Marri wrote: Hello Guys, Maybe this is in HEAD? I'm not sure. intel says Gigabit (10/100/1000 Mbits/sec) LAN subsystem using the Realtek* RTL8111-GR Gigabit Ethernet Controller Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-STABLE #0: Sat Sep 8 03:21:29 AST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WEB Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz (2666.62-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3fdSSE3,RSVD2,MON,DS_CPL,VMX,b6,EST,TM2,b9,CX16,b14,b15 AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 2 real memory = 3210739712 (3062 MB) avail memory = 3143385088 (2997 MB) ACPI APIC Table: INTEL DG31PR FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2.0 irqs 0-23 on motherboard acpi0: INTEL on motherboard acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 2000 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci0: display, VGA at device 2.0 (no driver attached) pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 17 at device 28.1 on pci0 pci3: ACPI PCI bus on pcib3 rl0: Realtek RTL8168B PCI-E Gigabit Ethernet Adapter port 0xc000-0xc0ff mem 0xd002-0xd0020fff irq 17 at device 0.0 on pci3 rl0: [GIANT-LOCKED] version:1.73 rl0: Ethernet address: 00:19:d1:a7:a4:72 rl0: Ethernet address: 00:19:d1:a7:a4:72 pcib4: ACPI PCI-PCI bridge at device 30.0 on pci0 pci4: ACPI PCI bus on pcib4 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH7 SATA300 controller port 0xd060-0xd067,0xd050-0xd053,0xd040-0xd047,0xd030-0xd033,0xd020-0xd02f irq 17 at device 31.2 on pci0 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_button0: Sleep Button on acpi0 acpi_button1: Power Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd0: [GIANT-LOCKED] ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec ipfw2 initialized, divert loadable, rule-based forwarding disabled, default to accept, logging limited to 1 packets/entry by default ad4: 238475MB WDC WD2500KS-00MJB0 02.01C03 at ata2-master SATA150 ad6: 238475MB WDC WD2500KS-00MJB0 02.01C03 at ata3-master SATA150 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a [EMAIL PROTECTED]:0:0: class=0x02 card=0xd6088086 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' class = network subclass = ethernet So I used Realtek driver to get it working. = = Realtek 8139C/8139C+/8169S/8169SB/8169SC/8168B/8101E Driver for FreeBSD v4.x/5.x/6.0 = = shouldn't be re0 instead of rl0? Could someone please look into it, Pyun? Try attached patch. I've touched rl(4) too because rl(4) should not attach to unsupported hardwares.
Re: FreeBSD 7.0 interrupt storm with irq0: clk
On 10/13/07, Nate Lawson [EMAIL PROTECTED] wrote: Rolf Witt wrote: Abdullah Ibn Hamad Al-Marri schrieb: Hello, I'm getting interrupt storm lately. No, you use Polling and the interrupt-rate is 1000HZ (your HZ-Option). Thats ok. IM# vmstat -i interrupt total rate irq0: clk 278426173 1000 options DEVICE_POLLING options HZ=1000 He's right. The above options say run my clock at 1000 hz and poll. -- Nate Thank you guys. I removed them. But still same issue with irq0: clk but less now. IM# vmstat -i interrupt total rate irq0: clk 37009569 1000 irq4: fxp0 2886384 77 irq8: rtc4736510127 irq14: ata079714 2 Total 44712177 1208 -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7
Esa Karkkainen wrote: I get Fatal double fault error when writing to a filesystem mounted from NFS server. Both NFS server and client are running 6.2-RELEASE-p7. I've attached dmesg from client and kernel config from server and client. Both have same these NFS options in /etc/rc.conf rpcbind_enable=YES nfs_server_enable=YES nfs_client_enable=YES nfs_reserved_port_only=YES rpc_lockd_enable=YES rpc_statd_enable=YES I have three kernel crash dumps available. The panic message is same in vmcore.0 and .1 Fatal double fault: eip = 0xc0608015 esp = 0xe3955000 ebp = 0xe3955020 panic: double fault Panic message in vmcore.2 has different eip and ebp values. Fatal double fault: eip = 0xc063242a esp = 0xe3955000 ebp = 0xe3955008 panic: double fault And here is backtrace from vmcore.2, which is identical to backtrace found in vmcore.0 and vmcore.1. Unfortunately the backtrace contains no information. # kgdb kernel.debug /home/crash/vmcore.2 Fatal double fault: eip = 0xc063242a Can you look up these IPs in the kernel symbol table (see the developers handbook)? This might give at least one clue, although I'm not sure it is relevant. You might also update to RELENG_6, I think there was at least one bug fixed that might have caused such a thing. Also try to rule out memory failure etc. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Question about 'top' values on memory usage
Hello! Maybe someone with deeper knowledge of the internals of FreeBSD can clean up something for me (any for many others)^ Here are lines from my top: PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 9258 hordelo_ru1 40 40992K 4260K accept 0 0:00 0.00% httpd 9257 hordelo_ru1 440 40992K 4296K select 1 0:00 0.00% httpd 9259 hordelo_ru1 40 40992K 4292K select 1 0:00 0.00% httpd As you see, 'size' is the same for all processes, while RES varies. As i understand, the real memory taken by a process is RES and SIZE include a bunch of shares .so libs, so, if more httpd's started each will take only about 4300K more, so, 100 https will take 43K to run, right? Another question is that is httpd uses threads (as provided by FreeBSD) starting a new thread will or will not copy executable copy and data? Basically, will a new thread eat another 4300K or just a little bit for its data? All this i need to calculate maximum possible number of https i can run on a box with certain amount of memory and select proper MPM for Apache. Somehow, i could not find any practical info on this regarding FreeBSD. Thank you in advance! -- Regards, Artem Kuchin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5
we are trying to diagnose errors seen on 6.2, SMP, amd64, cvsup'ed of 2007-10-09 Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x Opteron 2216, da3 is on a 3ware 9550-12 we are seeing this error: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 on a 12 GB Hyperdrive the offset changes sometimes, but it is always 81064794x and well out the 12GB range. We did have the Hyperdrive connected directly to the mainboards SATA0 (ad4) with similar errors. We used to have a md instead of the hyperdrive before, coming up with similar errors. Blocksize on the partition is 8192 (newsfs -b 8192 ..). We did have a blocksize of 65536 before, but after some hours (sometimes days), the machine will be unresponsible with newbuf as a waitmessage in top and has to be hard-reset. Regarding newbuf, as well as nbufkv and nbufbs, I will write a seperate message to the list. According to systat -vm, da3 does tps 500 (yes, that's a lot) This leads to an assumption, the error has to do with very high IOs per second on a SMP machine. The system-disk is a RAID1 on an ICP 5805. All other disks (51) are 20 gstripe'd partitions. Any hint to diagnose / fix the problem is well appreciated. Cheers, Dieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5
d_elbracht wrote: we are trying to diagnose errors seen on 6.2, SMP, amd64, cvsup'ed of 2007-10-09 Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x Opteron 2216, da3 is on a 3ware 9550-12 we are seeing this error: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 on a 12 GB Hyperdrive the offset changes sometimes, but it is always 81064794x and well out the 12GB range. We did have the Hyperdrive connected directly to the mainboards SATA0 (ad4) with similar errors. We used to have a md instead of the hyperdrive before, coming up with similar errors. Blocksize on the partition is 8192 (newsfs -b 8192 ..). We did have a blocksize of 65536 before, but after some hours (sometimes days), the machine will be unresponsible with newbuf as a waitmessage in top and has to be hard-reset. Regarding newbuf, as well as nbufkv and nbufbs, I will write a seperate message to the list. According to systat -vm, da3 does tps 500 (yes, that's a lot) This leads to an assumption, the error has to do with very high IOs per second on a SMP machine. The system-disk is a RAID1 on an ICP 5805. All other disks (51) are 20 gstripe'd partitions. Any hint to diagnose / fix the problem is well appreciated. Cheers, Dieter I can geneate 30,000 I/O's per second for hours on end on several types of storage hardware on FreeBSD SMP, and have no problems. Since you're seeing this problem both when connected to a 3ware controller and when connected to a simple ATA/SATA controller (both of which have also been observed to do high amounts of I/O with no problems), I suspect that the problem is with your disk device, not with FreeBSD. I don't know anything about a hyperdrive though, so more information might help. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
AW: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5
we are trying to diagnose errors seen on 6.2, SMP, amd64, cvsup'ed of 2007-10-09 Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x Opteron 2216, da3 is on a 3ware 9550-12 we are seeing this error: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 on a 12 GB Hyperdrive the offset changes sometimes, but it is always 81064794x and well out the 12GB range. We did have the Hyperdrive connected directly to the mainboards SATA0 (ad4) with similar errors. We used to have a md instead of the hyperdrive before, coming up with similar errors. Blocksize on the partition is 8192 (newsfs -b 8192 ..). We did have a blocksize of 65536 before, but after some hours (sometimes days), the machine will be unresponsible with newbuf as a waitmessage in top and has to be hard-reset. Regarding newbuf, as well as nbufkv and nbufbs, I will write a seperate message to the list. According to systat -vm, da3 does tps 500 (yes, that's a lot) This leads to an assumption, the error has to do with very high IOs per second on a SMP machine. The system-disk is a RAID1 on an ICP 5805. All other disks (51) are 20 gstripe'd partitions. Any hint to diagnose / fix the problem is well appreciated. Cheers, Dieter I can geneate 30,000 I/O's per second for hours on end on several types of storage hardware on FreeBSD SMP, and have no problems. Since you're seeing this problem both when connected to a 3ware controller and when connected to a simple ATA/SATA controller (both of which have also been observed to do high amounts of I/O with no problems), I suspect that the problem is with your disk device, not with FreeBSD. I don't know anything about a hyperdrive though, so more information might help. Scott Well, how about this: We used to have a md instead of the hyperdrive before, coming up with similar errors. here ist some info about the hyperdrive. http://www.hyperossystems.co.uk/ We could go back the the md (memory-disk) to try again. What exactly does the offset in the error-message mean ? Isn't that like a seek on the disk ? And what does error=5 mean ? Sure, the whole thing could be a problem of the application running. It's diablo 5. The history file (dhistory) about 2 GB in size resides on the hyperdrive. Dieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
newbuf, nbufkv, nbufbs
We have 2 machines involved with this problem. machine1, SMP, i386, 4 GB RAM was recently upgraded from 5.4 to 6.2 cvsup'ed 2007-10-10 a partition of about 2.5 TB (gstripe -s 1048576) was newfs'ed with blocksize of 65536 and fragsize of 8192 On 5.4, this was running for months with no problem. On 6.2 after a few hours of high thruput (network tx and rx 400-500 Mbit each), it became unresponsible with top showing a lot of processes with waitmessage newbuf. So, reset, fsck etc and it run again, only after a few hours, it became unresponsible again, showing processes with nbufkv and nbufbs this time, I did newfs with blocksize of 32768 and fragsize of 4096 and it's running. Thruput is decreased to 300-400 Mbit Note, it did NEVER show the problem on 5.4 machine2, SMP, amd64, 16 GB RAM, 6.2 cvsup'ed 2007-10-09 20 partitions involving 51 disks, all gstripe -s 1048576, newfs -b 65536 -f 8192 1 partion of 12 GB, (da3s1a) newfs -b 65536 -f 8192 after a few hours, top shows newbuf and the machine is unresponsible. tps on da3s1a is 500, the others are 100 I did newfs -b 8192 -f 1024 /dev/da3s1a and it's running without the problem (yet) The problem seems to have to do with -b 65536 and lot's of IOPS ond 6.2 Any clue ? e.g. increase BKVASIZE to 131072 and kern.nbuf to 32768 ? Cheers, Dieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5
On Sun, 14 Oct 2007, d_elbracht wrote: we are trying to diagnose errors seen on 6.2, SMP, amd64, cvsup'ed of 2007-10-09 Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x Opteron 2216, da3 is on a 3ware 9550-12 we are seeing this error: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 on a 12 GB Hyperdrive I trashed a perfectly disk drive before learning that there is a serious bug in g_vfs. Apparently it is one of those things which shows up in some configurations and not others. Although I am told they are unable to isolate the problem, all the reports I've seen were from people using AMD systems. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
AW: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5
--- Scott Long [EMAIL PROTECTED] wrote: I can geneate 30,000 I/O's per second for hours on end on several types of storage hardware on FreeBSD SMP, and have no problems. Since you're seeing this problem both when connected to a 3ware controller and when connected to a simple ATA/SATA controller (both of which have also been observed to do high amounts of I/O with no problems), I suspect that the problem is with your disk device, not with FreeBSD. I don't know anything about a hyperdrive though, so more information might help. Scott I would say so, too... Especially because errno 5 is EIO: http://www.freebsd.org/cgi/man.cgi?query=errnoapropos=0sekti on=0manpath=FreeBSD+6.2-RELEASEformat=html -Arne I would agree with you on that, if the error (EIO) is NOT because of the READ going wrong in the first place. From my understanding, the offset 81064794762854400 is NOT within the 12 GB of the drive anymore. Or, does the offset mean something else ? Dieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb stick problem
* Zoran Kolic [EMAIL PROTECTED] [2007-10-14 08:48]: I encountered something minor to usual problems, people have on this list, but it makes me nervous. I bought brand new usb flash stick and used it to solve the issue on handheld. After putting files on it, I have them in format 8.3. The option to mount -t was msdosfs. It should bring me long file names, but it does not. Mu stupid question would be: did I chose wrong file system? Or is this usb drive preformatted in something strange like fat16? This sounds like the documented behavior if the drive was empty or had no long filenames when you mounted it. From mount_msdosfs(8): If neither -s nor -l are given, mount_msdosfs searches the root directory of the file system to be mounted for any existing Win'95 long filenames. If no such entries are found, but short DOS filenames are found, -s is the default. Otherwise -l is assumed. -o longnames should do the trick. Alson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5
Lars Eighner wrote: On Sun, 14 Oct 2007, d_elbracht wrote: we are trying to diagnose errors seen on 6.2, SMP, amd64, cvsup'ed of 2007-10-09 Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x Opteron 2216, da3 is on a 3ware 9550-12 we are seeing this error: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 on a 12 GB Hyperdrive I trashed a perfectly disk drive before learning that there is a serious bug in g_vfs. Apparently it is one of those things which shows up in some configurations and not others. Although I am told they are unable to isolate the problem, all the reports I've seen were from people using AMD systems. Are you talking about problems with ATA controllers, AMD64 (or i386+PAE), and more than 4GB of RAM? Or something else? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0 interrupt storm with irq0: clk
Abdullah Ibn Hamad Al-Marri wrote: On 10/13/07, Nate Lawson [EMAIL PROTECTED] wrote: Rolf Witt wrote: Abdullah Ibn Hamad Al-Marri schrieb: Hello, I'm getting interrupt storm lately. No, you use Polling and the interrupt-rate is 1000HZ (your HZ-Option). Thats ok. IM# vmstat -i interrupt total rate irq0: clk 278426173 1000 options DEVICE_POLLING options HZ=1000 He's right. The above options say run my clock at 1000 hz and poll. -- Nate Thank you guys. I removed them. But still same issue with irq0: clk but less now. IM# vmstat -i interrupt total rate irq0: clk 37009569 1000 irq4: fxp0 2886384 77 irq8: rtc4736510127 irq14: ata079714 2 Total 44712177 1208 I don't see a storm -- it's coming in at exactly 1000 per second. The above shows your machine probably has been up about 10 hours. -- Nate ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0 interrupt storm with irq0: clk
On 2007-Oct-14 15:36:39 +0300, Abdullah Ibn Hamad Al-Marri [EMAIL PROTECTED] wrote: On 10/13/07, Nate Lawson [EMAIL PROTECTED] wrote: Rolf Witt wrote: Abdullah Ibn Hamad Al-Marri schrieb: Hello, I'm getting interrupt storm lately. ... But still same issue with irq0: clk but less now. IM# vmstat -i interrupt total rate irq0: clk 37009569 1000 So far, you haven't provided any evidence of any interrupt storm or how it might be related to acpi. And 7.0 isn't stable yet. The default HZ is 1000 so unless you explicitly change it in your kernel config, you should have 1000 clock interrupts/sec. -- Peter Jeremy pgpinGFhpu8Dx.pgp Description: PGP signature
Re: FreeBSD 7.0 interrupt storm with irq0: clk
On 2007-Oct-14 15:36:39 +0300, Abdullah Ibn Hamad Al-Marri [EMAIL PROTECTED] wrote: On 10/13/07, Nate Lawson [EMAIL PROTECTED] wrote: Rolf Witt wrote: Abdullah Ibn Hamad Al-Marri schrieb: Hello, I'm getting interrupt storm lately. ... But still same issue with irq0: clk but less now. IM# vmstat -i interrupt total rate irq0: clk 37009569 1000 So far, you haven't provided any evidence of any interrupt storm or how it might be related to acpi. And 7.0 isn't stable yet. The default HZ is 1000 so unless you explicitly change it in your kernel config, you should have 1000 clock interrupts/sec. -- Peter Jeremy Actually no more interrupt after I added these options back to my kernel while it's UP not SMP, and vmstat output has changed totally. # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic# I/O APIC IM# vmstat -i interrupt total rate irq14: ata0 4837 0 irq23: fxp0 2203298 86 cpu0: timer 50755929 1999 Total 52964064 2086 I even don't see irq0 in vmstat at all. Any hints? Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV. http://tv.yahoo.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about 'top' values on memory usage
In the last episode (Oct 14), Artem Kuchin said: Maybe someone with deeper knowledge of the internals of FreeBSD can clean up something for me (any for many others)^ Here are lines from my top: PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 9258 hordelo_ru1 40 40992K 4260K accept 0 0:00 0.00% httpd 9257 hordelo_ru1 440 40992K 4296K select 1 0:00 0.00% httpd 9259 hordelo_ru1 40 40992K 4292K select 1 0:00 0.00% httpd As you see, 'size' is the same for all processes, while RES varies. As i understand, the real memory taken by a process is RES and SIZE include a bunch of shares .so libs, so, if more httpd's started each will take only about 4300K more, so, 100 https will take 43K to run, right? The memory used by a process is SIZE. RES is the amount of that memory that's in memory. The rest would either be still on disk (in the form of executable or mmaped pages that haven't been accessed), in swap, or prezeroed pages that haven't been accessed yet (large blocks of malloc()'ed memory for example). Processes forked from the same parent can share the same pages until one process writes to one (a copy is then made so the other processes still see the right data). Chances are that those three httpd processes are sharing 99% of their pages. I don't know of any easy way of determing exactly how much non-shared memory a particular process has. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0 interrupt storm with irq0: clk
Abdullah Ibn Hamad Al-Marri wrote: On 2007-Oct-14 15:36:39 +0300, Abdullah Ibn Hamad Al-Marri [EMAIL PROTECTED] wrote: On 10/13/07, Nate Lawson [EMAIL PROTECTED] wrote: Rolf Witt wrote: Abdullah Ibn Hamad Al-Marri schrieb: Hello, I'm getting interrupt storm lately. ... But still same issue with irq0: clk but less now. IM# vmstat -i interrupt total rate irq0: clk 37009569 1000 So far, you haven't provided any evidence of any interrupt storm or how it might be related to acpi. And 7.0 isn't stable yet. The default HZ is 1000 so unless you explicitly change it in your kernel config, you should have 1000 clock interrupts/sec. Actually no more interrupt after I added these options back to my kernel while it's UP not SMP, and vmstat output has changed totally. # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic# I/O APIC IM# vmstat -i interrupt total rate irq14: ata0 4837 0 irq23: fxp0 2203298 86 cpu0: timer 50755929 1999 Total 52964064 2086 I even don't see irq0 in vmstat at all. Any hints? All you did was enable the lapic timer. I'm sorry that I don't have time to explain all the PC stuff to you, just stick with GENERIC and you'll be fine. -- Nate ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0 interrupt storm with irq0: clk
On Sun, Oct 14, 2007 at 01:03:44PM -0700, Abdullah Ibn Hamad Al-Marri wrote: On 2007-Oct-14 15:36:39 +0300, Abdullah Ibn Hamad Al-Marri [EMAIL PROTECTED] wrote: On 10/13/07, Nate Lawson [EMAIL PROTECTED] wrote: Rolf Witt wrote: Abdullah Ibn Hamad Al-Marri schrieb: Hello, I'm getting interrupt storm lately. ... But still same issue with irq0: clk but less now. IM# vmstat -i interrupt total rate irq0: clk 37009569 1000 So far, you haven't provided any evidence of any interrupt storm or how it might be related to acpi. And 7.0 isn't stable yet. The default HZ is 1000 so unless you explicitly change it in your kernel config, you should have 1000 clock interrupts/sec. -- Peter Jeremy Actually no more interrupt after I added these options back to my kernel while it's UP not SMP, and vmstat output has changed totally. # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic# I/O APIC IM# vmstat -i interrupt total rate irq14: ata0 4837 0 irq23: fxp0 2203298 86 cpu0: timer 50755929 1999 Total 52964064 2086 I even don't see irq0 in vmstat at all. Any hints? It looks like different timecounters are used depending on your kernel options. In the first case you probably used TSC or i8254 as timecounter while in the second (where you get timer interrupts on cpu0 instead of on irq0) you use ACPI as timecounter. The output of 'sysctl kern.timecounter.choice' for both cases might be illuminating. In any case there is still no indication of any interrupt storm. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5
d_elbracht wrote: we are trying to diagnose errors seen on 6.2, SMP, amd64, cvsup'ed of 2007-10-09 Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x Opteron 2216, da3 is on a 3ware 9550-12 we are seeing this error: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 on a 12 GB Hyperdrive the offset changes sometimes, but it is always 81064794x and well out the 12GB range. Yes. According to systat -vm, da3 does tps 500 (yes, that's a lot) That's not a lot :) That's actually low for a modern solid state drive. This leads to an assumption, the error has to do with very high IOs per second on a SMP machine. Either that or file system errors. Does fsck run ok or does it say anything unusual? There are several theoretical reasons for such errors that are connected with the fact you use solid state drives, but all are tricky to diagnose if you don't have a certain repeatable test you can try. For example: some SSDs optimize writes to spread out the IO on the chips, but some do it by looking into file system structures to determine where it's safe to relocate the write - obviously this works only with a known and supported file system. This is a really wild guess, but maybe the SSD firmware has error somewhere in this area, trying to interpret UFS as it was FAT? If you manage to get a repeatable failure test, you can try formatting the drive as FAT32 and trying it on that. Or maybe it's just a bad drive... The system-disk is a RAID1 on an ICP 5805. All other disks (51) are 20 gstripe'd partitions. 51 drives and 20 partitions? signature.asc Description: OpenPGP digital signature
Re: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5
Ivan Voras wrote: d_elbracht wrote: we are trying to diagnose errors seen on 6.2, SMP, amd64, cvsup'ed of 2007-10-09 Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x Opteron 2216, da3 is on a 3ware 9550-12 we are seeing this error: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 on a 12 GB Hyperdrive the offset changes sometimes, but it is always 81064794x and well out the 12GB range. Yes. According to systat -vm, da3 does tps 500 (yes, that's a lot) That's not a lot :) That's actually low for a modern solid state drive. This leads to an assumption, the error has to do with very high IOs per second on a SMP machine. Either that or file system errors. Does fsck run ok or does it say anything unusual? No, filesystem corruption has nothing to do with g_vfs_done messages. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5
Scott Long wrote: Ivan Voras wrote: Either that or file system errors. Does fsck run ok or does it say anything unusual? No, filesystem corruption has nothing to do with g_vfs_done messages. Well, perhaps not directly but I think filesystem corruption can indirectly cause g_vfs_done messages. If a filesystem is corrupt, the filesystem might attempt to read an out-of-range block, leading to a g_vfs_done error. This was the case for some of the arcmsr problems last year. In this case, I think the original poster said that the block number was out of range for the device. Regards, Jan Mikkelsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5
Jan Mikkelsen wrote: Scott Long wrote: Ivan Voras wrote: Either that or file system errors. Does fsck run ok or does it say anything unusual? No, filesystem corruption has nothing to do with g_vfs_done messages. Well, perhaps not directly but I think filesystem corruption can indirectly cause g_vfs_done messages. If a filesystem is corrupt, the filesystem might attempt to read an out-of-range block, leading to a g_vfs_done error. This was the case for some of the arcmsr problems last year. In this case, I think the original poster said that the block number was out of range for the device. Regards, Jan Mikkelsen Yeah, you're right, the block number is absurd, and it could well be caused by a bad block pointer in the filesystem. It sounds like he's getting this problem even on fresh installs, which ordinarily would point to a bad driver. If it's happening with both TWA and ATA, it's hard to blame both of those drivers. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Realtek eth isn't detected in Intel DG31PR mobo
On Sun, Oct 14, 2007 at 03:24:33PM +0300, Abdullah Ibn Hamad Al-Marri wrote:
[...]
Pyrun,
I hope you are doing well.
Thank you for the patch, and your good attempt to help with this issue.
I spent 2 hours with the patch it did detect the Ethernet as re0 but the
network did not work at all even though it said connected at auto 100 mbps
full duplex. The server sent out a packet storm of arp traffic or some kind
of traffic which caused a lot of problems in my overall network. I'm not
exactly sure what happened but maybe you know about it. So I removed the
patch and used the rl0 driver from Realtek again.
It's very strange I didn't see anything like it before.
Sorry, please try again with attached patch.
I guess I've misprogrammed Rx filter.
--
Regards,
Pyun YongHyeon
Index: sys/dev/re/if_re.c
===
RCS file: /home/ncvs/src/sys/dev/re/if_re.c,v
retrieving revision 1.95
diff -u -r1.95 if_re.c
--- sys/dev/re/if_re.c 14 Aug 2007 02:00:04 - 1.95
+++ sys/dev/re/if_re.c 15 Oct 2007 01:43:20 -
@@ -180,6 +180,8 @@
RealTek 8168/8111B PCIe Gigabit Ethernet },
{ RT_VENDORID, RT_DEVICEID_8168, RL_HWREV_8168_SPIN2,
RealTek 8168/8111B PCIe Gigabit Ethernet },
+ { RT_VENDORID, RT_DEVICEID_8168, RL_HWREV_8168_SPIN3,
+ RealTek 8168/8111B PCIe Gigabit Ethernet },
{ RT_VENDORID, RT_DEVICEID_8169, RL_HWREV_8169,
RealTek 8169 Gigabit Ethernet },
{ RT_VENDORID, RT_DEVICEID_8169, RL_HWREV_8169S,
@@ -221,6 +223,7 @@
{ RL_HWREV_8100E, RL_8169, 8100E},
{ RL_HWREV_8101E, RL_8169, 8101E},
{ RL_HWREV_8168_SPIN2, RL_8169, 8168},
+ { RL_HWREV_8168_SPIN3, RL_8169, 8168},
{ 0, 0, NULL }
};
@@ -676,14 +679,18 @@
*/
hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
-
- if (hwrev == RL_HWREV_8100E || hwrev == RL_HWREV_8101E ||
- hwrev == RL_HWREV_8168_SPIN1 || hwrev == RL_HWREV_8168_SPIN2) {
+ switch (hwrev) {
+ case RL_HWREV_8100E:
+ case RL_HWREV_8101E:
+ case RL_HWREV_8168_SPIN1:
+ case RL_HWREV_8168_SPIN2:
CSR_WRITE_4(sc, RL_MAR0, bswap32(hashes[1]));
CSR_WRITE_4(sc, RL_MAR4, bswap32(hashes[0]));
- } else {
+ break;
+ default:
CSR_WRITE_4(sc, RL_MAR0, hashes[0]);
CSR_WRITE_4(sc, RL_MAR4, hashes[1]);
+ break;
}
}
@@ -1314,6 +1321,7 @@
case RL_HWREV_8169_8110SB:
case RL_HWREV_8169_8110SC:
case RL_HWREV_8168_SPIN2:
+ case RL_HWREV_8168_SPIN3:
re_gmii_writereg(dev, 1, 0x1f, 0);
re_gmii_writereg(dev, 1, 0x0e, 0);
break;
Index: sys/pci/if_rl.c
===
RCS file: /home/ncvs/src/sys/pci/if_rl.c,v
retrieving revision 1.170
diff -u -r1.170 if_rl.c
--- sys/pci/if_rl.c 24 Jul 2007 01:24:03 - 1.170
+++ sys/pci/if_rl.c 15 Oct 2007 01:43:20 -
@@ -756,14 +756,31 @@
hwrev = CSR_READ_4(sc, RL_TXCFG) RL_TXCFG_HWREV;
bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
- /* Don't attach to 8139C+ or 8169/8110 chips. */
- if (hwrev == RL_HWREV_8139CPLUS ||
- (hwrev == RL_HWREV_8169
- t-rl_did == RT_DEVICEID_8169) ||
- hwrev == RL_HWREV_8169S ||
- hwrev == RL_HWREV_8110S) {
+ /*
+* Don't attach to 8139C+/8169/8169S/8110S/8168
+* 8111/8101E chips.
+*/
+ switch (hwrev) {
+ case RL_HWREV_8139CPLUS:
+ case RL_HWREV_8110S:
+ case RL_HWREV_8169S:
+ case RL_HWREV_8101:
+ case RL_HWREV_8100:
+ case RL_HWREV_8169_8110SB:
+ case RL_HWREV_8169_8110SC:
+ case RL_HWREV_8168_SPIN1:
+ case RL_HWREV_8100E:
+ case RL_HWREV_8101E:
+ case RL_HWREV_8168_SPIN2:
+ case RL_HWREV_8168_SPIN3:
t++;
continue;
+ case RL_HWREV_8169:
+ if (t-rl_did == RT_DEVICEID_8169) {
+ t++;
+ continue;
+ }
+ break;
}
device_set_desc(dev, t-rl_name);
