On Sat, Dec 13, 2003 at 08:33:57AM -0500, Robert Watson wrote: > On Sat, 13 Dec 2003, Thierry Herbelot wrote: > > Le Saturday 13 December 2003 11:11, Tim Bishop a écrit : > > > > > > As I've said, I am using vinum to mirror my swap. However, I set dumpdev > > > > Vinum to mirror also the swap ? Please explain what you are trying to > > achieve ? > > Presumably uptime via fault tolerance: the goal of putting swap and > temporary storage on a mirrored array is to avoid a single disk failure > from taking you down. Losing your swap partition can have disastrous > consequences on any data stored in the partition, including application > data... That said, I believe the problem being experienced here is that > the swap subsystem currently expects to talk to a GEOM object, and when it > looks at Vinum it finds a non-GEOM object. This can probably be worked > around by tricking GEOM into sticking a GEOM wrapper on the Vinum > partition you want to use for swap, such as using a Vinum partition as > backing for a vnode-backed md device. That said, I can't reach my test > boxes at work that I use for occasional Vinum testing due to a firewall > outage, so I can't test it right this moment. The long-term fix is to > make GEOM speak the disk(9) API at the top end, rather than the character > device API. Back to this again. As a result of what was said above I took the decision to put my swap straight onto the disk, rather than going via vinum. I figure my uptime is dire at the moment due to panics, so redundant swap isn't an issue :-) I thought this was working fine, but overnight another panic: ---------- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0166429 stack pointer = 0x10:0xd60359cc frame pointer = 0x10:0xd6035a00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 27 (syncer) trap number = 12 panic: page fault syncing disks, buffers remaining... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0166429 stack pointer = 0x10:0xd60355cc frame pointer = 0x10:0xd6035600 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 27 (syncer) trap number = 12 panic: page fault Uptime: 3d8h54m22s Dumping 496 MB ata0: resetting devices .. done ad0: timeout sending command=c5 s=d0 e=00 ad0: error executing commandata0: resetting devices .. ata0-slave: timeout waiting for cmd=ec s=00 e=00 ata0-slave: ATA identify failed done ad0: timeout waiting for DRQata0: resetting devices .. ata0-slave: timeout waiting for cmd=ec s=00 e=00 ata0-slave: ATA identify failed done ad0: timeout waiting for DRQata0: resetting devices .. done ad0: timeout waiting for DRQ Fatal trap 12: page fault while in kernel mode fault virtual address = 0x28 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0131c20 stack pointer = 0x10:0xd60351f8 frame pointer = 0x10:0xd6035250 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 27 (syncer) trap number = 12 panic: page fault Uptime: 3d8h54m34s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... ---------- As you can see in the middle of that it attempts to do a dump, but that fails too. So I'm really stuck in a position where I can't provide any more debugging information. An obvious step to me seems to be to upgrade to 5.2 (I'm still on 5.1 at the moment) and hope the issue has been fixed. Cheers, Tim. -- Tim Bishop http://www.bishnet.net/tim PGP Key: 0x5AE7D984Received on Wed Jan 14 2004 - 23:52:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:38 UTC