swap_pager: indefinite wait buffer
My server just literally was brought to it's knees with this message spewing on the console: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1203133, size: 4096 (blkno and size were varying) Some searching says that this is or was a bug. Has this been fixed yet? If so, what should I upgrade to? I'm currently running 6.3 Michael Grant ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swap_pager: indefinite wait buffer
On 5 Mar 2008, at 10:06, Michael Grant wrote: My server just literally was brought to it's knees with this message spewing on the console: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1203133, size: 4096 (blkno and size were varying) Some searching says that this is or was a bug. Has this been fixed yet? If so, what should I upgrade to? I'm currently running 6.3 You may consider partition backed swap instead of file backed swap if that is the case. Michael Grant ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] - Ruben PGP.sig Description: This is a digitally signed message part
Re: swap_pager: indefinite wait buffer
On Wed, Mar 5, 2008 at 11:08 AM, Ruben van Staveren [EMAIL PROTECTED] wrote: On 5 Mar 2008, at 10:06, Michael Grant wrote: My server just literally was brought to it's knees with this message spewing on the console: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1203133, size: 4096 (blkno and size were varying) Some searching says that this is or was a bug. Has this been fixed yet? If so, what should I upgrade to? I'm currently running 6.3 You may consider partition backed swap instead of file backed swap if that is the case. Hmm, I can't easily do that, I didn't leave any empty partitions around as I never considered swapping to a file to be a so bad. Is swapping to a file so bad under normal conditions? Does this mean that this bug is still not fixed in 7.0? Is there any way to do anything akin to Partition Magic on ufs to shrink the fs? (not sure if it's ufs1 or ufs2, mount reports it as 'ufs'). Michael Grant ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swap_pager: indefinite wait buffer
Michael Grant wrote: On Wed, Mar 5, 2008 at 11:08 AM, Ruben van Staveren [EMAIL PROTECTED] wrote: On 5 Mar 2008, at 10:06, Michael Grant wrote: My server just literally was brought to it's knees with this message spewing on the console: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1203133, size: 4096 (blkno and size were varying) Some searching says that this is or was a bug. Has this been fixed yet? If so, what should I upgrade to? I'm currently running 6.3 You may consider partition backed swap instead of file backed swap if that is the case. Hmm, I can't easily do that, I didn't leave any empty partitions around as I never considered swapping to a file to be a so bad. Is swapping to a file so bad under normal conditions? The message indicates that it took 30 seconds to complete an operation, so it was timed out assuming the I/O was lost by the device. In your case it was probably not lost, just delayed for more than 30 seconds by an overloaded filesystem. Does this mean that this bug is still not fixed in 7.0? It's not clear whether it's a bug or your disk is just too overloaded to complete the filesystem operation in a reasonable time period (swapping to a file is slower than swapping to a partition, which is already something you never want to do in normal operation). You can increase the timeout by editing the kernel. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Do I get them all? Now: swap_pager: indefinite wait buffer ... ?
May 3rd kernel on this one still ... swap_pager: indefinite wait buffer: bufobj: 0, blkno: 654, size: 4096 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[5.4-p6] Trouble with swap_pager: indefinite wait buffer on LSI(PERC4)-RAID on Dell PE6650
Hi *, one of our Dell PE6650 (4x Xeon, HTT, 2GB RAM) crash from time to time with kernel messages like: swap_pager: indefinite wait buffer: device amrd1s1d, blkno 77 Any access to the RAID is impossible (e.g. login on console, shutdown, ... ), have to powercycle it. What is the meaning of this message? What is the causation for this error? Does swap_pager crash the RAID? Maybe under load? Maybe any locking/SMP? swap seems to work: Swap: 2048M Total, 144K Used, 2048M Free Some technical details: * This filesystem is pretty loaded/stressed by the webserver/CMS and periodic rsync-jobs. Filesystem SizeUsed Avail Capacity iusedifree %iused Mounted on /dev/amrd1s1d265G 77G167G32% 1415076 344546184% /data * There is a 2GB swap on amrd0s2b (or what is the problem with swap_pager?) * From dmesg: amr0: LSILogic MegaRAID 1.51 mem 0xfce0-0xfce0 irq 21 at device 1.0 on pci3 amr0: LSILogic PERC 4/DC Firmware 351S, BIOS 1.10, 128MB RAM amrd0: LSILogic MegaRAID logical drive on amr0 amrd0: 69880MB (143114240 sectors) RAID 1 (optimal) amrd1: LSILogic MegaRAID logical drive on amr0 amrd1: 279800MB (573030400 sectors) RAID 5 (optimal) * from pciconf: [EMAIL PROTECTED]:1:0: class=0x010400 card=0x05181028 chip=0x19601000 rev=0x01 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' class= mass storage subclass = RAID * a typical load average is 1.02, 1.05, 1.05 (actually 52 httpd processes, have seen up to 120 httpd) * Kernel is 5.4-RELEASE-p6 with GENERIC plus SMP include GENERIC ident PE6650 options SMP Is there anything I can do? Any switches? sysctl? Is 6.0-RELEASE or will 6.1-RELEASE be a solution for that? Any patches in 5-STABLE? Need more info? Need more testing? I have a second machine of this which acts as a standby/fallback-system. I may test some things here (without workload). TIA Regards Raphael Becker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [5.4-p6] Trouble with swap_pager: indefinite wait buffer on LSI(PERC4)-RAID on Dell PE6650
Raphael H. Becker wrote: Hi *, swap_pager: indefinite wait buffer: device amrd1s1d, blkno 77 Any access to the RAID is impossible (e.g. login on console, shutdown, ... ), have to powercycle it. What is the meaning of this message? I have encountered this error once before, and it meant that it timed out trying to access the disk/partition where swap was. It also coincided with a network card (fxp0) timeout, but I'm not sure that was related. The system was unresponsive from the console or remotely until it was completely power cycled, the reset button wasn't enough. What is the causation for this error? Probably a disk/controller/SCSI timeout of some sort amr0: LSILogic MegaRAID 1.51 mem 0xfce0-0xfce0 irq 21 at device 1.0 on pci3 Mine also happened to be on an LSI/amr based card, but not a Dell. It's an older dual CPU PIII-800. Is there anything I can do? Any switches? sysctl? Is 6.0-RELEASE or will 6.1-RELEASE be a solution for that? Any patches in 5-STABLE? In my case, after some hair pulling, it turned out to be a bad SCSI cable. You might check your cabling and termination, and perhaps swap the cable even if it looks good -- mine looked better than the cable I replaced it with. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5
Oliver Fromme wrote: Uwe Doering [EMAIL PROTECTED] wrote: Oliver Fromme wrote: If they're really identical (i.e. the same size and same geometry), then you can use dd(1) for duplication, like this: # dd if=/dev/ad0 of=/dev/ad1 bs=64k conv=noerror,sync The noerror,sync part is important so the dd command will not stop when it hits any bad spots on the source drive and instead will fill the blocks with zeroes on the destination drive. Since it's only the swap partition, you shouldn't lose any data. I would like to point out that the conclusion you're drawing in the last sentence is invalid IMHO. I'm afraid I don't agree. indefinite wait buffer messages at apparently random block numbers just indicate that the pager was unable to access the swap area (in its entirety!) when it wanted to. It means that the disk drive was either dead at that point in time or busy trying to deal with a bad sector. This sector could have been anywhere on the disk. It just kept the disk drive busy for long enough that the pager started to complain. The OP specifically said that the swap_pager messages were the only kernel messages that he got. That indicates that only the swap partition is affected, because otherwise there would have been other kernel messages indicating I/O errors from one of the filesystems on that disk. Your assumption here is that the filesystem code would become impatient, too. This in not the case. The swap pager has a timeout built in (20 seconds IIRC) after which it prints a warning message and continues waiting, but there is nothing like this in the filesystem code. If the disk drive is dead or busy trying to deal with a bad sector in a filesystem the kernel will wait silently and indefinitely until either the disk drive succeeds in recovering the sector, or it fails to do so. In the latter case the kernel would log an I/O error. But only when it hears back from the disk drive and not any earlier, in contrast to the swap pager. That's why you often see only swap pager messages in case of a dying disk drive. I checked the kernel sources, but of course I could have missed the relevant lines. In this case I would appreciate a pointer to the place at which the filesystem code generates a warning message comparable to that from the swap pager. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers [EMAIL PROTECTED] | http://www.escapebox.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5
Uwe Doering [EMAIL PROTECTED] wrote: Oliver Fromme wrote: If they're really identical (i.e. the same size and same geometry), then you can use dd(1) for duplication, like this: # dd if=/dev/ad0 of=/dev/ad1 bs=64k conv=noerror,sync The noerror,sync part is important so the dd command will not stop when it hits any bad spots on the source drive and instead will fill the blocks with zeroes on the destination drive. Since it's only the swap partition, you shouldn't lose any data. I would like to point out that the conclusion you're drawing in the last sentence is invalid IMHO. I'm afraid I don't agree. indefinite wait buffer messages at apparently random block numbers just indicate that the pager was unable to access the swap area (in its entirety!) when it wanted to. It means that the disk drive was either dead at that point in time or busy trying to deal with a bad sector. This sector could have been anywhere on the disk. It just kept the disk drive busy for long enough that the pager started to complain. The OP specifically said that the swap_pager messages were the only kernel messages that he got. That indicates that only the swap partition is affected, because otherwise there would have been other kernel messages indicating I/O errors from one of the filesystems on that disk. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C++ is to C as Lung Cancer is to Lung. -- Thomas Funke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5
Oliver Fromme wrote: Zoltan Frombach [EMAIL PROTECTED] wrote: Apr 29 02:10:14 www kernel: swap_pager: indefinite wait buffer: device: ad0s1a, blkno: 328636, size: 8192 Apr 29 02:10:24 www kernel: swap_pager: indefinite wait buffer: device: ad0s1e, blkno: 329842, size: 4096 [...] The error message indicates that there was an I/O error accessing the swap area on your disk. Usually that's an indication for a hardware failure, e.g. a dying disk. I happen to have an identical hard drive around here, unused. If I hook it up as a slave (IDE) drive, is there a way I can mirror the dying drive to the spare one (with all partitions, etc, intact)? If they're really identical (i.e. the same size and same geometry), then you can use dd(1) for duplication, like this: # dd if=/dev/ad0 of=/dev/ad1 bs=64k conv=noerror,sync The noerror,sync part is important so the dd command will not stop when it hits any bad spots on the source drive and instead will fill the blocks with zeroes on the destination drive. Since it's only the swap partition, you shouldn't lose any data. I would like to point out that the conclusion you're drawing in the last sentence is invalid IMHO. indefinite wait buffer messages at apparently random block numbers just indicate that the pager was unable to access the swap area (in its entirety!) when it wanted to. It means that the disk drive was either dead at that point in time or busy trying to deal with a bad sector. This sector could have been anywhere on the disk. It just kept the disk drive busy for long enough that the pager started to complain. Since the swap area is usually just a minor portion of the disk it is therefore much more likely that the bad sector is located in a filesystem. So if you copy the disk and ignore i/o errors in this situation you _do_ run a very real risk of losing data! Unfortunately you can't do much about it but you should at least be aware of it. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers [EMAIL PROTECTED] | http://www.escapebox.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5
Hello All, I have a pretty stable FreeBSD 5.3-p5 production server which worked just fine - until today. I host over 100+ web sites on it (Apache + PHP4 + MySQL), email, ftp, etc. There was a time when it was up for over 6 months without a reboot. So it is stable. But today I had a strange problem with this server. I could ping it, but nothing else worked. I had to reboot it by plugging the power. After it came back, this is what I've found in the log file (and nothing else). Apr 29 02:10:14 www kernel: swap_pager: indefinite wait buffer: device: ad0s1a, blkno: 328636, size: 8192 Apr 29 02:10:24 www kernel: swap_pager: indefinite wait buffer: device: ad0s1e, blkno: 329842, size: 4096 Apr 29 02:10:24 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 330511, size: 8192 Apr 29 02:10:24 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 331470, size: 8192 Apr 29 02:10:24 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 332030, size: 4096 Apr 29 02:10:49 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 332257, size: 8192 Apr 29 02:10:49 www kernel: swap_pager: indefinite wait buffer: device: ad0s1a, blkno: 332309, size: 4096 Apr 29 02:11:14 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 332252, size: 8192 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1a, blkno: 332301, size: 4096 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 332260, size: 4096 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1a, blkno: 332307, size: 8192 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 332229, size: 8192 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 328470, size: 16384 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 328967, size: 16384 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 329231, size: 4096 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 329479, size: 16384 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 329673, size: 16384 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 332224, size: 4096 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 329234, size: 16384 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 316002, size: 4096 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 332185, size: 16384 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 331763, size: 8192 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 318855, size: 4096 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1a, blkno: 319335, size: 4096 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319135, size: 4096 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319196, size: 16384 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319146, size: 16384 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319243, size: 8192 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319191, size: 8192 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319235, size: 4096 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319183, size: 4096 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319232, size: 12288 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319276, size: 8192 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319189, size: 8192 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319327, size: 4096 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319186, size: 12288 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319206, size: 8192 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 319256, size: 4096 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 301096, size: 4096 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 301145, size: 8192 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 301468, size: 8192 Apr 29 02:33:35 www kernel: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 301887, size: 4096 Apr 29
Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5
Zoltan Frombach [EMAIL PROTECTED] wrote: Apr 29 02:10:14 www kernel: swap_pager: indefinite wait buffer: device: ad0s1a, blkno: 328636, size: 8192 Apr 29 02:10:24 www kernel: swap_pager: indefinite wait buffer: device: ad0s1e, blkno: 329842, size: 4096 [...] The error message indicates that there was an I/O error accessing the swap area on your disk. Usually that's an indication for a hardware failure, e.g. a dying disk. I happen to have an identical hard drive around here, unused. If I hook it up as a slave (IDE) drive, is there a way I can mirror the dying drive to the spare one (with all partitions, etc, intact)? If they're really identical (i.e. the same size and same geometry), then you can use dd(1) for duplication, like this: # dd if=/dev/ad0 of=/dev/ad1 bs=64k conv=noerror,sync The noerror,sync part is important so the dd command will not stop when it hits any bad spots on the source drive and instead will fill the blocks with zeroes on the destination drive. Since it's only the swap partition, you shouldn't lose any data. However, one disadvantage of dd is that it copies the drive on block level, which means that it will also copy empty blocks which aren't used at all. Neither does it make sense to copy the swap partition. If the filesystems on that drive don't contain much data, it might be mor efficient to copy the data on filesystem level. To do that, copy just the boot sector and disklabel (using dd(1) to copy the first 64k or something should be sufficient), then newfs the filesystems, mount them and copy the contents with an appropriate tool. I recommend cpdup from the port collection, because it's fast and easy to use, but cpio should work as well (and it's in the base of pretty much every UNIX system). Performing newfs + filesystem copy also has the advantage that you're starting with fresh, unfragmented filesystems, and it gives you the opportunity to finetune the parameters if necessary, such as the inode density (newfs -i). Any help/comments would be appreciated. Please CC me, as I am not a subscriber of this list. Thanks!!! In that case you should set the Reply-To header in your mail appropriately. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5
Steve, Thank you for your quick response! Try to mirror the disk with dd (if=/dev/ad0 of=/dev/ad1 bs=1m) I assume I have to do this in single user mode. Right? You should really think about getting a RAID controller, i can recommend you a 2 channel 3ware controller (less than 100$) Would you please email me the product name and model number? Thanks!! Zoltan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5
At 06:23 AM 29/04/2005, Zoltan Frombach wrote: Apr 29 02:10:24 www kernel: swap_pager: indefinite wait buffer: device: ad0s1e, blkno: 329842, size: 4096 As others have said, it looks to be a hard drive about to die. You can get more info with /usr/ports/sysutils/smartmontools/. It can give some simple diagnostics that might confirm this for you. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5
0x002a 253 252 000Old_age ys - 0 208 Spin_Buzz 0x002a 253 252 000Old_age ys - 0 209 Offline_Seek_Performnce 0x0024 200 200 000Old_age line - 0 99 Unknown_Attribute 0x0004 253 253 000Old_age line - 0 100 Unknown_Attribute 0x0004 253 253 000Old_age line - 0 101 Unknown_Attribute 0x0004 253 253 000Old_age line - 0 SMART Error Log Version: 1 ATA Error Count: 1 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It wraps after 49.710 days. Error 1 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours) When the command that caused the error occurred, the device was in an unknown state. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 04 51 50 40 97 03 10 Error: ABRT Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ef fe 00 00 00 00 10 00 00:05:42.512 SET FEATURES [Reserved for CFA] c3 3d 00 00 00 00 10 00 00:05:42.464 [VENDOR SPECIFIC] c3 e4 00 00 00 00 10 00 00:05:42.432 [VENDOR SPECIFIC] c3 3d 00 00 00 00 10 00 00:05:42.432 [VENDOR SPECIFIC] 70 00 00 00 5e 20 10 00 00:05:42.368 SEEK [OBS-7] SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 100 Not_testing 200 Not_testing 300 Not_testing 400 Not_testing 500 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. Thank you for looking at it!! Please response if you have any comments about the above output. Thanks a lot!! Zoltan - Original Message - At 06:23 AM 29/04/2005, Zoltan Frombach wrote: Apr 29 02:10:24 www kernel: swap_pager: indefinite wait buffer: device: ad0s1e, blkno: 329842, size: 4096 As others have said, it looks to be a hard drive about to die. You can get more info with /usr/ports/sysutils/smartmontools/. It can give some simple diagnostics that might confirm this for you. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swap_pager: indefinite wait buffer?
At 09:53 AM 12/2/1999 -0600, Jim King wrote: Sorry if this doesn't belong on -stable, but I didn't get a response on -questions. I got this in my messages file: Dec 1 09:10:20 cgi /kernel: swap_pager: indefinite wait buffer: device: 0x20401, blkno: 776, size: 4096 Dec 1 09:11:31 cgi /kernel: swap_pager: indefinite wait buffer: device: 0x20401, blkno: 776, size: 4096 Dec 1 09:11:32 cgi last message repeated 2 times What exactly does this mean? I'm afraid that it means some disk hardware is flaking out. If that's the case how do I know which disk had the problem? (I have swap space on two drives.) OK, call me a doofus for not searching the mailing list archives. To answer my own question, this means that a pageout took longer than 20 seconds on device major 4, minor 0x20001, which happens to be /dev/da0s1b on my system (swap space on the first drive). The usual advice is that this is harmless. It does NOT indicate failing hardware. However, it does indicate a busy disk, and if it happens a lot you should probably add swap space on another drive (already done, unfortunately) and/or more memory. I saw this question a lot in the archives. Would this be a good one for the FAQ? Jim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: swap_pager: indefinite wait buffer?
I saw this question a lot in the archives. Would this be a good one for the FAQ? Any question you see a lot in the archives is, by definition, good for a FAQ entry. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
