Re: ZFS repeatable reboot 8.0-RC1
Note: I tried setting vfs.zfs.arc_max=32M and zfs mem usage still grew past its limits and the machine rebooted. Forwarding a note I received... " >> Your machine is starving! > How can this be, there is over 500MiB free ram at all times? I'm sysctl vm.kmem_size_max I've got the following in my kernel configuration file options KVA_PAGES=512 and in /boot/loader.conf vm.kmem_size_max=1536M vm.kmem_size=1536M On two machines with 2G of RAMboth 8.0-RC1/i386 the ZFS tuning guide gives a better idea of how to play with things like that http://wiki.freebsd.org/ZFSTuningGuide " Some questions... Am I reading correctly that vm.kmem_size is how much ram the kernel initially allocates for itself on boot? And that vm.kmem_size_min and vm.kmem_size_max are the range that vm.kmem_size is allowed to float naturally within at runtime? Is KVA_PAGES the hard max space the kern is allowed/capable of addressing/using at runtime? Such that I could set kmem_size_max to the KVA_PAGES limit and then vm.kmem_size will grow into it as needed? With the caveat of course that with the below defaults and hardware, if I just bumped vm.kmem_size_max to 1GiB [as per KVA_PAGES limit] I'd have to add maybe another 1GiB ram so that this new vm.kmem_size_max kernel reservation wouldn't conflict with userland memory needs when vm.kmem_size grows to it? And KVA_PAGES is typically say 1/3 of installed ram? If vm.kmem_size starts out being under vm.kmem_size_max, can user apps use the unused space (vm.kmem_size_max - vm.kmem_size) until vm.kmem_size grows to vm.kmem_size_max and the kernel kills them off? Or can user apps only use (ram = user apps + [KVA_PAGES hard limit and/or vm.kmem_size_max])? What is the idea behind setting vm.kmem_size = vm.kmem_size_max? Should not just vm.kmem_size_max be set and allow vm.kmem_size [unset] to grow up to vm.kmem_size_max instead of allocating it all at boot with vm.kmem_size? Maybe someone can wikify these answers? I think I need to find more to read and then test one by one to see what changes. With untuned defaults and 1GiB ram I have: #define KVA_PAGES 256 # gives 1GiB kern address space vm.kmem_size_max: 335544320 # auto calculated by the kernel at boot? Less than KVA_PAGES? vm.kmem_size_min: 0 vm.kmem_size: 335544320 # amount in use at runtime? I'm still figuring out how to find and add all the kernel memory. Here's zfs: vfs.zfs.arc_meta_limit: 52428800 vfs.zfs.arc_meta_used: 56241732 # greater than meta_limit? vfs.zfs.arc_min: 26214400 vfs.zfs.arc_max: 209715200 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 kstat.zfs.misc.arcstats.p: 20589785 # was 104857600 on boot kstat.zfs.misc.arcstats.c: 128292242 # was 209715200 on boot kstat.zfs.misc.arcstats.c_min: 26214400 kstat.zfs.misc.arcstats.c_max: 209715200 loader(8) vm.kmem_size Sets the size of kernel memory (bytes). This overrides the value determined when the kernel was compiled. Modifies VM_KMEM_SIZE. vm.kmem_size_min vm.kmem_size_max Sets the minimum and maximum (respectively) amount of ker- nel memory that will be automatically allocated by the ker- nel. These override the values determined when the kernel was compiled. Modifies VM_KMEM_SIZE_MIN and VM_KMEM_SIZE_MAX. sys/i386/include/pmap.h /* * Size of Kernel address space. This is the number of page table pages * (4MB each) to use for the kernel. 256 pages == 1 Gigabyte. * This **MUST** be a multiple of 4 (eg: 252, 256, 260, etc). * For PAE, the page table page unit size is 2MB. This means that 512 pages * is 1 Gigabyte. Double everything. It must be a multiple of 8 for PAE. */ #ifndef KVA_PAGES #ifdef PAE #define KVA_PAGES 512 #else #define KVA_PAGES 256 #endif #endif sys/i386/conf/NOTES # Change the size of the kernel virtual address space. Due to # constraints in loader(8) on i386, this must be a multiple of 4. # 256 = 1 GB of kernel address space. Increasing this also causes # a reduction of the address space in user processes. 512 splits # the 4GB cpu address space in half (2GB user, 2GB kernel). For PAE # kernels, the value will need to be double non-PAE. A value of 1024 # for PAE kernels is necessary to split the address space in half. # This will likely need to be increased to handle memory sizes >4GB. # PAE kernels default to a value of 512. # options KVA_PAGES=260 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mfi(4) endless loop kernel output on attach
On Thursday 15 October 2009 11:16:23 am pluknet wrote: > 2009/10/15 John Baldwin : > > On Thursday 15 October 2009 5:51:19 am pluknet wrote: > >> Hi. > >> > >> This is 7.2-R. Seen on IBM x3650M2. > >> > >> During the boot I get those endless looping kernel messages while on > >> mfi(4) attach phase. > >> It's getting more odd since 7.2 booted and worked fine on exactly this > >> server model > >> months ago (on different box though).. Any hints? > > > > We just had some boxes die like this (but spewing a different loop of > > messages > > on boot related to continuously scheduling patrol reads and consistency > > checks that finished immediately) at work. We fixed them by swapping out > > the > > controller. We might try stick them in a different box and reflashing them > > using mfiutil(8) to see if it's some sort of corrupted state that flashing > > the adapter fixes. > > > > In your case it looks lik the firmware keeps crashing and restarting. > > Probably it is. Though clearing logs helped me. Well, from your other e-mail it seems it was just dumping lots of old logs since the previous clean shutdown. (I almost mentioned that case in my original e-mail). In that case you can simply let it finish walking through all the logs or you can set loader tunables to raise the minimum class of message so it skips all the lower priority info messages when walking the log. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
Steven Hartland wrote: We're not running 8 yet but we do have a 7.x box which its under fairly high IO load doing mrtg graphs which has similar behaviour. When typing a command on ssh it will freeze for may seconds. We have a FreeBSD 7.2 cacti box running on a dell 1950 that has the same problems. RRDs are disk i/o hogs, and when disk i/o shoots up, the box becomes non-responsive for a few seconds. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mfi(4) endless loop kernel output on attach
2009/10/15 John Baldwin : > On Thursday 15 October 2009 5:51:19 am pluknet wrote: >> Hi. >> >> This is 7.2-R. Seen on IBM x3650M2. >> >> During the boot I get those endless looping kernel messages while on >> mfi(4) attach phase. >> It's getting more odd since 7.2 booted and worked fine on exactly this >> server model >> months ago (on different box though).. Any hints? > > We just had some boxes die like this (but spewing a different loop of messages > on boot related to continuously scheduling patrol reads and consistency > checks that finished immediately) at work. We fixed them by swapping out the > controller. We might try stick them in a different box and reflashing them > using mfiutil(8) to see if it's some sort of corrupted state that flashing > the adapter fixes. > > In your case it looks lik the firmware keeps crashing and restarting. Probably it is. Though clearing logs helped me. -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mfi(4) endless loop kernel output on attach
On Thursday 15 October 2009 5:51:19 am pluknet wrote: > Hi. > > This is 7.2-R. Seen on IBM x3650M2. > > During the boot I get those endless looping kernel messages while on > mfi(4) attach phase. > It's getting more odd since 7.2 booted and worked fine on exactly this > server model > months ago (on different box though).. Any hints? We just had some boxes die like this (but spewing a different loop of messages on boot related to continuously scheduling patrol reads and consistency checks that finished immediately) at work. We fixed them by swapping out the controller. We might try stick them in a different box and reflashing them using mfiutil(8) to see if it's some sort of corrupted state that flashing the adapter fixes. In your case it looks lik the firmware keeps crashing and restarting. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mfi(4) endless loop kernel output on attach
>> >> This is 7.2-R. Seen on IBM x3650M2. >> >> During the boot I get those endless looping kernel messages while on >> mfi(4) attach phase. >> It's getting more odd since 7.2 booted and worked fine on exactly this >> server model >> months ago (on different box though).. Any hints? >> > > After the looked endless loop the kernel eventually finished > the mfi(4) initialization and continued its booting. > Is it expected to do so long initialization? > Replying to myself. As someone pointed out in the private email, that's due to the large log contained on non-volatile memory in the controller. MegaCli -AdpEventLog -GetEventLogInfo -aAll cleaned up 'em all. Sorry for noise. -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [bce] panic on boot in bce(4) on 7.2: invalid ife->ifm_data (0xa)
2009/8/6 Xin LI :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> pluknet wrote:
>> Hi.
>>
>> I got the following kernel panic on boot:
>> invalid ife->ifm_data (0xa) in mii_phy_setmedia
>>
>> This is near /sys/dev/mii/mii_physubr.c:126
>> KASSERT(ife->ifm_data >=0 && ife->ifm_data < MII_NMEDIA,
>> ("invalid ife->ifm_data (0x%x) in mii_phy_setmedia",
>> ife->ifm_data));
>
> I believe that this was because the (un)merged brgphy bits. Is it
> possible for you to use 7.2-STABLE instead? Otherwise you will need a
> patched kernel:
>
> http://people.freebsd.org/~delphij/misc/bce-5709phy.diff
>
> Please make sure that you have a full kernel build.
>
I see no panic with this patch on 7.2.
Thanks.
--
wbr,
pluknet
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
8.0-RC1/amd64, ZFS panic
panic: mtx_lock() of destroyed mutex @ /usr/src/sys/kern/vfs_subrc:2467 cpuid = 1 I was doing a zfs destroy -r of a dataset. The dataset has had many snapshot receives done. # uname -a FreeBSD 8.0-RC1 FreeBSD 8.0-RC1 #1: Tue Oct 13 14:11:08 CEST 2009 root@:/usr/obj/usr/src/sys/DEBUG amd64 (kernel config: added WITNESS, etc to have debugging information, doing some ZFS send/receive tests) It's a VMWare virtual machine, and I've frozen it. Borja. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mfi(4) endless loop kernel output on attach
2009/10/15 pluknet : > Hi. > > This is 7.2-R. Seen on IBM x3650M2. > > During the boot I get those endless looping kernel messages while on > mfi(4) attach phase. > It's getting more odd since 7.2 booted and worked fine on exactly this > server model > months ago (on different box though).. Any hints? > After the looked endless loop the kernel eventually finished the mfi(4) initialization and continued its booting. Is it expected to do so long initialization? Almost at the end of kernel boot / near to multiuser start it panicked with: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia Though that's offtopic here. >From last part of dmesg: mfi0: 29365 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 29366 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 29367 (boot + 64s/0x0008/info) - Battery Present mfi0: 29368 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 29369 (boot + 64s/0x0020/info) - Board Revision mfi0: 29370 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 29371 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=, scsiType=0, portMap=00, sasAddr=5000c500138d46b5, mfi0: 29372 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 29373 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 29374 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=, scsiType=0, portMap=01, sasAddr=5000c500138d842d, mfi0: 29375 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 29376 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 29377 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=, scsiType=0, portMap=04, sasAddr=5000c500138d7d75, mfi0: 29378 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 29379 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 29380 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=, scsiType=0, portMap=05, sasAddr=5000c500138d7835, mfi0: 29381 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 29382 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 29383 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=, scsiType=0, portMap=02, sasAddr=5000c500138d60b5, mfi0: 29384 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 29385 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 29386 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd, mfi0: 29387 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 29388 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 29389 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=, scsiType=0, portMap=06, sasAddr=5000c500138d6839, mfi0: 29390 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 29391 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 29392 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d, mfi0: 29393 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 29394 (boot + 144s/0x0008/info) - Battery temperature is normal ioapic0: routing intpin 16 (PCI IRQ 16) to vector 52 mfi0: [MPSAFE] mfi0: [ITHREAD] pcib8: irq 16 at device 28.4 on pci0 pcib8: domain0 pcib8: secondary bus 6 pcib8: subordinate bus 10 pcib8: I/O decode0xf000-0xfff pcib8: memory decode 0x9700-0x978f pcib8: prefetched decode 0x9600-0x96ff pci6: on pcib8 pci6: domain=0, physical bus=6 found-> vendor=0x101b, dev=0x0452, revid=0x01 domain=0, bus=6, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x0b (2750 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, 64 bit pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 pcib8: slot 0 INTA is routed to irq 16 pcib9: irq 16 at device 0.0 on pci6 pcib9: domain0 pcib9: secondary bus 7 pcib9: subordinate bus 7 pcib9: I/O decode0xf000-0xfff pcib9: memory decode 0x9700-0x978f pcib9: prefetched decode 0x9600-0x96ff pci7: on pcib9 pci7: domain=0, physical bus=7 found-> vendor=0x102b, dev=0x0530, revid=0x00 domain=0, bus=7, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x20 (8000 ns) intpin=a, irq=11 powerspec 1 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0x9600, size 24, enabled pcib9: requested memory
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
Ivan Voras wrote: 2009/10/13 Larry Rosenman : note huge packet loss. It looks like it's VM fault or something like it. It sounds like the VM is failing to execute the guest during certain types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go amiss to confirm that the VM really is suspending the guest It's VMWare ESXi underneath, which is *Officially Not Linux* though some ducks may disagree - anyway, I suspect tracing the host in this way is next to impossible without some kind of diamondium-level contract. What information do you need? I have a platinum VMWare contract. What version of ESXi? Hi, It is ESXi 3.5 - but if the problem is really in ESXi I presume anyone could reproduce it. My setup is nothing special - Xeon 5405, 8 GB RAM, SATA drives on ICH9. As for what data is needed, it depends on what you can get - from this discussion thread it looks like it would be enough to verify that disk IO doesn't leave VM processes waiting (i.e. that disk IO doesn't interfere with CPU-bound or idle virtual machines). Though now when I think of it - doesn't Linux ATA driver poll IO in some funky way, expecting to get lower latency that way? Another data point - the OS in the VM in question hanged today sometime after 5 AM in the following way: * console nonresponsive (also to ctrl-alt-del) * ssh login nonresponsive (timeout) * ping works (!) Judging by the last seen timestamp, the machine should have been in the process of receiving rsync backups - so IO-bound. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
mfi(4) endless loop kernel output on attach
Hi. This is 7.2-R. Seen on IBM x3650M2. During the boot I get those endless looping kernel messages while on mfi(4) attach phase. It's getting more odd since 7.2 booted and worked fine on exactly this server model months ago (on different box though).. Any hints? mfi0: 5428 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5429 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5430 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5431 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5432 (boot + 64s/0x0008/info) - Battery Present mfi0: 5433 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5434 (boot + 64s/0x0020/info) - Board Revision mfi0: 5435 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5436 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=, scsiType=0, portMap=00, sasAddr=5000c500138d46b5, mfi0: 5437 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5438 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5439 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=, scsiType=0, portMap=01, sasAddr=5000c500138d842d, mfi0: 5440 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5441 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5442 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=, scsiType=0, portMap=04, sasAddr=5000c500138d7d75, mfi0: 5443 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5444 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5445 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=, scsiType=0, portMap=05, sasAddr=5000c500138d7835, mfi0: 5446 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5447 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5448 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=, scsiType=0, portMap=02, sasAddr=5000c500138d60b5, mfi0: 5449 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5450 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5451 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd, mfi0: 5452 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5453 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5454 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=, scsiType=0, portMap=06, sasAddr=5000c500138d6839, mfi0: 5455 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5456 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5457 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d, mfi0: 5458 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5459 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5460 (308390540s/0x0020/info) - Time established as 10/09/09 8:02:20; (256 seconds since power on) mfi0: 5461 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5462 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5463 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5464 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5465 (boot + 64s/0x0008/info) - Battery Present mfi0: 5466 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5467 (boot + 64s/0x0020/info) - Board Revision mfi0: 5468 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5469 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=, scsiType=0, portMap=00, sasAddr=5000c500138d46b5, mfi0: 5470 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5471 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5472 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=, scsiType=0, portMap=01, sasAddr=5000c500138d842d, mfi0: 5473 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5474 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5475 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=, scsiType=0, portMap=04, sasAddr=5000c500138d7d75, mfi0: 5476 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5477 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5478 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=, scsiType=0, portMap=05, sasAddr=5000c500138d7835, mfi0: 5479 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5480 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5481 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=, scsiType=0, portMap=02, sasAd
Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others)
On Oct 12, 2009, at 10:45 AM, Thomas Backman wrote: >Here's the original thread (not from the beginning, though): >http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html >Long story short, my version: when the disk is stressed hard enough, >console IO becomes COMPLETELY unbearable. 10+ seconds to switch >between windows in screen(1), running (or even typing) simple >commands, etc. This happens both via SSH and the serial console. >How to reproduce/test: >1) time file /etc/* > /dev/null a few times, or something similar that >uses the disk; write down a common/average/median/whatever time. >2) cat /dev/zero > /uncompressed_fs/filename # please make *sure* it's >uncompressed, since ZFS with lzjb/gzip enabled will squish this into a >kilobyte-sized file, thus creating virtually *no* IO. >3) When cat has been running say 10 seconds, re-time command #1 and do >some interactive stuff - run commands, edit files, etc. Hi Thomas, I'm trying to reproduce the issue though I don't have any ZFS filesystems. I'm not using SSH neither serial console. My system is quite responsive. I'm using a VmWare system with 2 cpu support, 1MB RAM with FreeBSD 7.2-RELEASE. I don't know if the issue is related to ZFS or your hardware configuration but can you report what top(1) say during the slowdown? -- Giovanni Trematerra ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
