svn commit: r289834 - head/sys/x86/x86

[Oliver Pinter]

On 10/26/15, Adrian Chadd <adrian.chadd at gmail.com> wrote:
> Hi,
>
> I'll take a photo of it when it breaks next.
>
> Would you mind reverting it for now until we can figure it out?

btw, this was the two kernel panic what I got:

Fatal trap 12: page fault while in kernel mode
cpuid = 11; apic id = 03
fault virtual address   = 0x30
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff808a2d22
stack pointer           = 0x28:0xfffffe07cc75a6f0
frame pointer           = 0x28:0xfffffe07cc75a770
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         = 5 (doneq0)
trap number             = 12
panic: page fault
cpuid = 11
KDB: stack backtrace:
#0 0xffffffff80641647 at kdb_backtrace+0x67
#1 0xffffffff80606762 at vpanic+0x182
#2 0xffffffff806067e3 at panic+0x43
#3 0xffffffff8084eef1 at trap_fatal+0x351
#4 0xffffffff8084f0e4 at trap_pfault+0x1e4
#5 0xffffffff8084e82f at trap+0x4bf
#6 0xffffffff80830d57 at calltrap+0x8
#7 0xffffffff8063beab at _bus_dmamap_load_ccb+0x1fb
#8 0xffffffff8063bc51 at bus_dmamap_load_ccb+0x91
#9 0xffffffff8042dcad at ata_dmaload+0x11d
#10 0xffffffff8042df7e at ata_begin_transaction+0x7e
#11 0xffffffff8042c18e at ataaction+0x9ce
#12 0xffffffff802a220f at xpt_run_devq+0x5bf
#13 0xffffffff802a17ad at xpt_action_default+0x94d
#14 0xffffffff802c0024 at adastart+0x8b4
#15 0xffffffff802a2e93 at xpt_run_allocq+0x193
#16 0xffffffff802c0ea0 at adadone+0x280
#17 0xffffffff802a5310 at xpt_done_process+0x3a0
Uptime: 1m40s

Fatal trap 12: page fault while in kernel mode
cpuid = 11; apic id = 03
fault virtual address   = 0x30
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff808a2d22
stack pointer           = 0x28:0xfffffe07cc737710
frame pointer           = 0x28:0xfffffe07cc737790
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         = 13 (g_down)
trap number             = 12
panic: page fault
cpuid = 11
KDB: stack backtrace:
#0 0xffffffff80641647 at kdb_backtrace+0x67
#1 0xffffffff80606762 at vpanic+0x182
#2 0xffffffff806067e3 at panic+0x43
#3 0xffffffff8084eef1 at trap_fatal+0x351
#4 0xffffffff8084f0e4 at trap_pfault+0x1e4
#5 0xffffffff8084e82f at trap+0x4bf
#6 0xffffffff80830d57 at calltrap+0x8
#7 0xffffffff8063beab at _bus_dmamap_load_ccb+0x1fb
#8 0xffffffff8063bc51 at bus_dmamap_load_ccb+0x91
#9 0xffffffff8042dcad at ata_dmaload+0x11d
#10 0xffffffff8042df7e at ata_begin_transaction+0x7e
#11 0xffffffff8042c18e at ataaction+0x9ce
#12 0xffffffff802a220f at xpt_run_devq+0x5bf
#13 0xffffffff802a17ad at xpt_action_default+0x94d
#14 0xffffffff802c0024 at adastart+0x8b4
#15 0xffffffff802a2e93 at xpt_run_allocq+0x193
#16 0xffffffff802c0735 at adastrategy+0xf5
#17 0xffffffff80554206 at g_disk_start+0x426
Uptime: 2m29s


Extra info, it's a Dell R410, with 2x1TB disc in mirrored raidz + plus
a gmirrored partition.

>
>
>
> -adrian
>
>
> On 26 October 2015 at 05:53, Oliver Pinter
> <oliver.pinter at hardenedbsd.org> wrote:
>> Hi Roger!
>>
>> On 10/26/15, Roger Pau Monné <royger at freebsd.org> wrote:
>>> El 26/10/15 a les 13.24, Adrian Chadd ha escrit:
>>>> Hi,
>>>>
>>>> I've started seeing panics on -head with ATA code doing a dmamap load
>>>> -> panic. I'll test by reverting this patch and see what happens, but
>>>> when it /does/ happen I can't get a crashdump, so debugging will be
>>>> less easy.
>>>>
>>>> Has anyone else seen this?
>>>
>>> I've got another report regarding ATA page-faults from Oliver Pinter.
>>> The crash he was seeing was caused by bus_dmamap_load_ccb, but the calls
>>> to the specific dma functions where optimized away. Can you figure out
>>> which bounce_* function causes this specifically?
>>
>> I have already deleted the broken kernel, and I'm now running on
>> kernel without this patch.
>>
>>>
>>> Thanks, Roger.
>>>
>>> _______________________________________________
>>> svn-src-head at freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/svn-src-head
>>> To unsubscribe, send any mail to "svn-src-head-unsubscribe at freebsd.org"
>>>
>