Date: Wed, 15 Feb 2017 22:37:41 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: freebsd-geom@FreeBSD.org, freebsd-scsi@FreeBSD.org Subject: Re: cd + geom -> panic on media change Message-ID: <07e08996-49d4-3817-cf2b-01504e25ca67@FreeBSD.org> In-Reply-To: <6a59787c-ecba-80db-a669-d0987466e3f8@FreeBSD.org> References: <6a59787c-ecba-80db-a669-d0987466e3f8@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15/02/2017 22:33, Andriy Gapon wrote: > > I had an Audio CD in a DVD drive. > I booted with that CD in and this is how it was reported: > cd0: <Optiarc DVD RW AD-7191S 1.02> Removable CD-ROM SCSI device > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: 392MB (200919 2048 byte sectors) > > I see that there is some special code in scsi_cd.c that sets sector size to 2352 > for Audio CDs, but that was not reflected in the report quoted above. > > Later I popped out the CD (using the physical eject button, if that matters) and > popped in a UDF formatted DVD disk. That resulted in the following panic: > > panic: wrong offset 472559440 for sectorsize 2048 By the way, I see that all requests going down pass through g_io_check() which would reject such a request with EINVAL. Why do we have the KASSERT in g_io_request() then? > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff8043517b = db_trace_self_wrapper+0x2b/frame > 0xfffffe0504bc8870 > kdb_backtrace() at 0xffffffff80685289 = kdb_backtrace+0x39/frame 0xfffffe0504bc8920 > vpanic() at 0xffffffff8064ce8c = vpanic+0x14c/frame 0xfffffe0504bc8960 > panic() at 0xffffffff8064cbd3 = panic+0x43/frame 0xfffffe0504bc89c0 > g_io_request() at 0xffffffff805c3b81 = g_io_request+0x3e1/frame 0xfffffe0504bc8a00 > g_read_data() at 0xffffffff805c48e7 = g_read_data+0x77/frame 0xfffffe0504bc8a40 > g_part_gpt_probe() at 0xffffffff805df0d1 = g_part_gpt_probe+0x111/frame > 0xfffffe0504bc8a80 > G_PART_PROBE() at 0xffffffff805daa0b = G_PART_PROBE+0x4b/frame 0xfffffe0504bc8aa0 > g_part_probe() at 0xffffffff805da366 = g_part_probe+0xc6/frame 0xfffffe0504bc8af0 > g_part_taste() at 0xffffffff805d8de7 = g_part_taste+0x147/frame 0xfffffe0504bc8b30 > g_new_provider_event() at 0xffffffff805c7a0b = g_new_provider_event+0x10b/frame > 0xfffffe0504bc8b50 > one_event() at 0xffffffff805c2a4f = one_event+0xff/frame 0xfffffe0504bc8b70 > g_run_events() at 0xffffffff805c2875 = g_run_events+0x65/frame 0xfffffe0504bc8b90 > g_event_procbody() at 0xffffffff805c4f38 = g_event_procbody+0x58/frame > 0xfffffe0504bc8ba0 > fork_exit() at 0xffffffff80614800 = fork_exit+0xd0/frame 0xfffffe0504bc8bf0 > fork_trampoline() at 0xffffffff80837a7e = fork_trampoline+0xe/frame > 0xfffffe0504bc8bf0 > > The actual DVD has size 680368 x 2048. > I did some basic math and 472559440 == 200919 * 2352 - 2048. > Given that the code was probing GPT, the offset is consistent with mediasize > still being the old size of the Audio CD while the sector size being 2048. > Seems like the disk properties were not properly updated before posting the new > provider event. > > Patches and suggestions are welcome :) > Thank you! > -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?07e08996-49d4-3817-cf2b-01504e25ca67>