Date: Fri, 8 Jun 2012 11:39:25 +0200 (CEST) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-stable@FreeBSD.ORG, pluknet@gmail.com Subject: Re: 9-stabe: cd device gone, ATA_CAM panics Message-ID: <201206080939.q589dPoT004398@lurza.secnetix.de> In-Reply-To: <CAE-mSO%2BwRwgb-GE1UXvVAffDJc8NoONQ05LoQFuhdoN%2BNLgPdw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sergey Kandaurov <pluknet@gmail.com> wrote:
> This is a wild guess, but see below.
> [...]
> Probably the way to fix this is to modify
> cam_periph_release_locked_buses() to test CAM_PERIPH_INVALID either.
>
> how about this patch?
> (beware: it was not compile tested, just speculating)
Thanks for your detailed analysis!
I'm afraid the patch is not correct. With that patch, the
following page fault occurs (same output as before until
"removing device entry"):
(cd0:ata2:0:0:0): removing device entry
(cd0:nobus:X:X): removing device entry
Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address = 0x20
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff807a0d03
stack pointer = 0x28:0xffffff80002a9270
frame pointer = 0x28:0xffffff80002a9290
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 12 (g_event)
trap number = 12
panic: page fault
cpuid = 4
KDB: stack backtrace:
#0 0xffffffff807a3ca6 at kdb_backtrace+0x66
#1 0xffffffff8076d75e at panic+0x1ce
#2 0xffffffff809b7400 at trap_fatal+0x290
#3 0xffffffff809b773d at trap_pfault+0x1ed
#4 0xffffffff809b7d5e at trap+0x3ce
#5 0xffffffff809a282f at calltrap+0x8
#6 0xffffffff806d6a16 at disk_destroy+0x26
#7 0xffffffff802ba687 at cdcleanup+0x97
#8 0xffffffff802a1e79 at camperiphfree+0x99
#9 0xffffffff802a203e at cam_periph_release_locked+0x1e
#10 0xffffffff802a2f62 at cam_periph_release+0x52
#11 0xffffffff802babdd at cdclose+0xbd
#12 0xffffffff806d7342 at g_disk_access+0x242
#13 0xffffffff806db628 at g_access+0x188
#14 0xffffffff806fc353 at g_raid_md_taste_ddf+0x1f3
#15 0xffffffff806e96e6 at g_raid_taste+0x126
#16 0xffffffff806db0dd at g_new_provider_event+0x6d
#17 0xffffffff806d8c18 at g_run_events+0x1e8
Uptime: 48s
Automatic reboot in 15 seconds - press any key on the console to abort
By the way, there is a long delay (~20s) before the two
"ata2: reset tp1" lines. I guess something hangs here and
causes a time-out. I didn't have such delays with 8.x.
I need a working DVD drive, so I'm now considering to
downgrade to 8-stable. But then again, TMPFS didn't work
a well for me as it does in 9-stable (which was the main
reason for me to upgrade), so I'm kind of stuck in a
difficult situation.
I'm willing to test more patches, of course. :-)
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
> Can the denizens of this group enlighten me about what the
> advantages of Python are, versus Perl ?
"python" is more likely to pass unharmed through your spelling
checker than "perl".
-- An unknown poster and Fredrik Lundh
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201206080939.q589dPoT004398>