Date: Sun, 10 Jan 2016 22:47:59 -0800 From: Colin Percival <cperciva@freebsd.org> To: freebsd-xen@freebsd.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <royger@FreeBSD.org> Cc: hps@freebsd.org, kib@freebsd.org Subject: Re: recent disk-related breakage Message-ID: <5693501F.9060008@freebsd.org> In-Reply-To: <56934B8F.8050503@freebsd.org> References: <56934B8F.8050503@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm rather suspicious of r292255 here -- royger, hps, kib, can any of you comment on whether it would be responsible for making non-page-aligned I/Os no longer get split on page boundaries? The commit message is suggestive, but I don't know the code very well. (If I don't hear back I'll determine if it's responsible experimentally, but testing a "system no longer boots" bug in EC2 is painfully slow and it's getting late here.) Colin Percival On 01/10/16 22:28, Colin Percival wrote: > Some time in early December, disk I/O broke. The EC2 image built from r291495 > works fine; the EC2 image built from r292413 is broken. > > Symptoms: > 1. growfs reports "superblock not recognized" > > 2. fsck reports lots of "UNKNOWN FILE TYPE"s and after a few seconds provokes > "panic: XEN disk driver data cannot cross a page boundary" > xbd_mksegarray() at xbd_mksegarray+0x4b/frame 0xfffffe0f4dadb420 > > xbd_queue_cb() at xbd_queue_cb+0x1e8/frame 0xfffffe0f4dadb490 > > bus_dmamap_load_bio() at bus_dmamap_load_bio+0xad/frame 0xfffffe0f4dadb4f0 > > xbd_startio() at xbd_startio+0x194/frame 0xfffffe0f4dadb530 > > xbd_strategy() at xbd_strategy+0x6a/frame 0xfffffe0f4dadb560 > > g_disk_start() at g_disk_start+0x37c/frame 0xfffffe0f4dadb5d0 > > g_io_request() at g_io_request+0x39d/frame 0xfffffe0f4dadb630 > > g_part_start() at g_part_start+0x2b5/frame 0xfffffe0f4dadb6b0 > > g_io_request() at g_io_request+0x39d/frame 0xfffffe0f4dadb710 > > g_io_request() at g_io_request+0x39d/frame 0xfffffe0f4dadb770 > > g_dev_strategy() at g_dev_strategy+0x171/frame 0xfffffe0f4dadb7b0 > > physio() at physio+0x440/frame 0xfffffe0f4dadb850 > > devfs_read_f() at devfs_read_f+0xe7/frame 0xfffffe0f4dadb8b0 > > dofileread() at dofileread+0x98/frame 0xfffffe0f4dadb900 > > kern_readv() at kern_readv+0x68/frame 0xfffffe0f4dadb950 > > sys_read() at sys_read+0x60/frame 0xfffffe0f4dadb9a0 > > > Does anyone remember touching any relevant bits of code in that timeframe? > -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5693501F.9060008>