Re: Panic from vesa_configure()

[Alan Cox]

On 01/09/2016 13:48, Adrian Chadd wrote:
> On 9 January 2016 at 11:30, John Baldwin  wrote:
>> On Thursday, January 07, 2016 01:47:32 AM Cy Schubert wrote:
>>> In message >> om>
>>> , Jeremie Le Hen writes:
 On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd  
 wrote
 :
> can you copy/paste the file:line that each of those stackframes 
> represents?
>
> I may have an idea or two..
 Sure here we go:

 (kgdb) list *vesa_configure+0x270
 0x80b25cd0 is in vesa_configure 
 (/usr/src-svn/sys/dev/fb/vesa.c:827).

 (kgdb) list *vga_init+0x65
 0x80b286e5 is in vga_init (/usr/src-svn/sys/dev/fb/vga.c:1402).

 (kgdb) list *isavga_attach+0x92
 0x80b9afd2 is in isavga_attach 
 (/usr/src-svn/sys/isa/vga_isa.c:224).
>>> Here is what I see. Only happens on real hardware (not VirtualBox VMs).
>>>
>>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
>>> uart0: console (9600,n,8,1)
>>> acpi_alloc_wakeup_handler: can't alloc wake memory
>> This is probably related to the same cause.  Both this and the x86 BIOS stuff
>> need "low" memory (memory below 1MB).
>>
>> x86bios_alloc() uses contigmalloc() as does acpi_alloc_wakeup_handler().
>> Perhaps the recent changes to contigmalloc() affect this?  In particular,
>> try reverting r292469 to see if that fixes the issue.
> Can't we just keep a pool of those pages around and not give them out
> unless someone specifically asks for low memory?

vm_phys.c already implements a "soft segregation" under which these
pages are only allocated as a last resort, unless
kmem_alloc_{attr,contig}() or contigmalloc() is called.

What happened is that r292469 changed the order in which we pull from
the free lists for kmem_alloc_{attr,contig}() and contigmalloc() so that
a bunch of, for example, contigmalloc(low=0, high=4GB) calls, could
potentially exhaust physical memory in the range [0, 1MB).  In other
words, we're no longer getting the soft segregation among contigmalloc()
calls.
 
> (The physmem code has explicit clue to do this if we wanted it to; it
> has lowmem bits for allocation. I thought it was all working fine.)
>
>
> -a
>


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Alan Cox]

On 01/09/2016 14:05, Alan Cox wrote:
> On 01/09/2016 13:48, Adrian Chadd wrote:
>> On 9 January 2016 at 11:30, John Baldwin  wrote:
>>> On Thursday, January 07, 2016 01:47:32 AM Cy Schubert wrote:
 In message 
 
 , Jeremie Le Hen writes:
> On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd  
> wrote
> :
>> can you copy/paste the file:line that each of those stackframes 
>> represents?
>>
>> I may have an idea or two..
> Sure here we go:
>
> (kgdb) list *vesa_configure+0x270
> 0x80b25cd0 is in vesa_configure 
> (/usr/src-svn/sys/dev/fb/vesa.c:827).
>
> (kgdb) list *vga_init+0x65
> 0x80b286e5 is in vga_init (/usr/src-svn/sys/dev/fb/vga.c:1402).
>
> (kgdb) list *isavga_attach+0x92
> 0x80b9afd2 is in isavga_attach 
> (/usr/src-svn/sys/isa/vga_isa.c:224).
 Here is what I see. Only happens on real hardware (not VirtualBox VMs).

 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
 uart0: console (9600,n,8,1)
 acpi_alloc_wakeup_handler: can't alloc wake memory
>>> This is probably related to the same cause.  Both this and the x86 BIOS 
>>> stuff
>>> need "low" memory (memory below 1MB).
>>>
>>> x86bios_alloc() uses contigmalloc() as does acpi_alloc_wakeup_handler().
>>> Perhaps the recent changes to contigmalloc() affect this?  In particular,
>>> try reverting r292469 to see if that fixes the issue.
>> Can't we just keep a pool of those pages around and not give them out
>> unless someone specifically asks for low memory?
> vm_phys.c already implements a "soft segregation" under which these
> pages are only allocated as a last resort, unless
> kmem_alloc_{attr,contig}() or contigmalloc() is called.
>
> What happened is that r292469 changed the order in which we pull from
> the free lists for kmem_alloc_{attr,contig}() and contigmalloc() so that
> a bunch of, for example, contigmalloc(low=0, high=4GB) calls, could
> potentially exhaust physical memory in the range [0, 1MB).  In other
> words, we're no longer getting the soft segregation among contigmalloc()
> calls.
>  

This patch should suffice to restore the soft segregation among
contigmalloc() calls.

Index: vm/vm_phys.c
===
--- vm/vm_phys.c(revision 293580)
+++ vm/vm_phys.c(working copy)
@@ -1372,12 +1372,12 @@ restartdom:
return (NULL);
}
m_run = NULL;
-   for (segind = 0; segind < vm_phys_nsegs; segind++) {
+   for (segind = vm_phys_nsegs - 1; segind >= 0; segind--) {
seg = _phys_segs[segind];
-   if (seg->start >= high)
+   if (seg->start >= high || seg->domain != domain)
+   continue;
+   if (low >= seg->end)
break;
-   if (low >= seg->end || seg->domain != domain)
-   continue;
if (low <= seg->start)
pa_start = seg->start;
else
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Adrian Chadd]

On 9 January 2016 at 11:30, John Baldwin  wrote:
> On Thursday, January 07, 2016 01:47:32 AM Cy Schubert wrote:
>> In message > om>
>> , Jeremie Le Hen writes:
>> > On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd  
>> > wrote
>> > :
>> > > can you copy/paste the file:line that each of those stackframes 
>> > > represents?
>> > >
>> > > I may have an idea or two..
>> >
>> > Sure here we go:
>> >
>> > (kgdb) list *vesa_configure+0x270
>> > 0x80b25cd0 is in vesa_configure 
>> > (/usr/src-svn/sys/dev/fb/vesa.c:827).
>> >
>> > (kgdb) list *vga_init+0x65
>> > 0x80b286e5 is in vga_init (/usr/src-svn/sys/dev/fb/vga.c:1402).
>> >
>> > (kgdb) list *isavga_attach+0x92
>> > 0x80b9afd2 is in isavga_attach 
>> > (/usr/src-svn/sys/isa/vga_isa.c:224).
>>
>> Here is what I see. Only happens on real hardware (not VirtualBox VMs).
>>
>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
>> uart0: console (9600,n,8,1)
>> acpi_alloc_wakeup_handler: can't alloc wake memory
>
> This is probably related to the same cause.  Both this and the x86 BIOS stuff
> need "low" memory (memory below 1MB).
>
> x86bios_alloc() uses contigmalloc() as does acpi_alloc_wakeup_handler().
> Perhaps the recent changes to contigmalloc() affect this?  In particular,
> try reverting r292469 to see if that fixes the issue.

Can't we just keep a pool of those pages around and not give them out
unless someone specifically asks for low memory?

(The physmem code has explicit clue to do this if we wanted it to; it
has lowmem bits for allocation. I thought it was all working fine.)


-a
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[John Baldwin]

On Thursday, January 07, 2016 01:47:32 AM Cy Schubert wrote:
> In message  om>
> , Jeremie Le Hen writes:
> > On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd  
> > wrote
> > :
> > > can you copy/paste the file:line that each of those stackframes 
> > > represents?
> > >
> > > I may have an idea or two..
> > 
> > Sure here we go:
> > 
> > (kgdb) list *vesa_configure+0x270
> > 0x80b25cd0 is in vesa_configure 
> > (/usr/src-svn/sys/dev/fb/vesa.c:827).
> > 
> > (kgdb) list *vga_init+0x65
> > 0x80b286e5 is in vga_init (/usr/src-svn/sys/dev/fb/vga.c:1402).
> > 
> > (kgdb) list *isavga_attach+0x92
> > 0x80b9afd2 is in isavga_attach (/usr/src-svn/sys/isa/vga_isa.c:224).
> 
> Here is what I see. Only happens on real hardware (not VirtualBox VMs).
> 
> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> uart0: console (9600,n,8,1)
> acpi_alloc_wakeup_handler: can't alloc wake memory

This is probably related to the same cause.  Both this and the x86 BIOS stuff
need "low" memory (memory below 1MB).

x86bios_alloc() uses contigmalloc() as does acpi_alloc_wakeup_handler().
Perhaps the recent changes to contigmalloc() affect this?  In particular,
try reverting r292469 to see if that fixes the issue.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Alan Cox]

On Sat, Jan 9, 2016 at 12:44 AM, Adrian Chadd 
wrote:

> It shouldn't have changed though; you're just requesting memory to use
> for x86bios calls.
>
> +jhb - any ideas?
>
>

Yes, there is insufficient free (or reclaimable) physical memory below 1MB,
so contigmalloc() fails.

This is almost certainly a side-effect of r292469, specifically, this part:

"Make vm_phys_alloc_contig() a little smarter (and more efficient in some
cases).  Specifically, use vm_phys_segs[] earlier to avoid scanning free
page lists that can't possibly contain suitable pages.

That part of the change has altered the order in which we allocate from the
free lists corresponding to different ranges of physical addresses, so
contigmalloc(low=0, high=4GB) might well consume memory from physical
addresses [0, 1MB), whereas before it wouldn't consume such physical memory
as long as physical memory between 16MB and 4GB was available.



>
>
>
> On 8 January 2016 at 20:53, Cy Schubert  wrote:
> > Cy Schubert writes:
> >> In message <201601080107.u0817kdw078...@slippy.cwsent.com>, Cy Schubert
> >> writes:
> >> > In message
>  >> c
> >> > om>
> >> > , Adrian Chadd writes:
> >> > > Ok,
> >> > >
> >> > > So try adding this check:
> >> > >
> >> > > vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
> >> > > if (vmbuf == NULL) {
> >> > > printf("%s: x86bios_alloc failed!\n", __func__);
> >> > > goto fail;
> >> > > }
> >> > >
> >> > > ... that call shouldn't be failing, but if it's truely failing on
> the
> >> > > bcopy(), the only reason is because vmbuf is NULL.
> >> >
> >> > Thanks. I'll try this.
> >> >
> >> > vesa.c hasn't changed for a while so I suspect the root cuase may be
> >> > somewhere else (we're probably treating the symptom here). Nice thing
> about
> >>
> >> > using the same mobo and cpu combination on all my machines (except
> >> > laptops), failures are completely reproducible. Might be a good idea
> to put
> >>
> >> > in a dtrace probe too.
> >>
> >> Hi Adrian,
> >>
> >> Your patch fixed the issue. I've included a dtrace probe. I suspect the
> >> error may be BIOS specific and the dtrace probe should help in tracking
> it
> >> down. Does this look good to commit?
> >
> > A bit of multitasking going on here. I should have included the patch. :~
> >
> >
> >
> >
> > Cheers,
> > Cy Schubert  or 
> > FreeBSD UNIX:     Web:  http://www.FreeBSD.org
> >
> > The need of the many outweighs the greed of the few.
> >
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Cy Schubert]

In message <56917d49.1000...@rice.edu>, Alan Cox writes:
> This is a multi-part message in MIME format.
> --080104010900060709060805
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 7bit
> 
> On 01/09/2016 14:05, Alan Cox wrote:
> > On 01/09/2016 13:48, Adrian Chadd wrote:
> >> On 9 January 2016 at 11:30, John Baldwin  wrote:
> >>> On Thursday, January 07, 2016 01:47:32 AM Cy Schubert wrote:
>  In message  il.c
>  om>
>  , Jeremie Le Hen writes:
> > On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd 
>  wrote
> > :
> >> can you copy/paste the file:line that each of those stackframes repres
> ents?
> >>
> >> I may have an idea or two..
> > Sure here we go:
> >
> > (kgdb) list *vesa_configure+0x270
> > 0x80b25cd0 is in vesa_configure (/usr/src-svn/sys/dev/fb/vesa.c
> :827).
> >
> > (kgdb) list *vga_init+0x65
> > 0x80b286e5 is in vga_init (/usr/src-svn/sys/dev/fb/vga.c:1402).
> >
> > (kgdb) list *isavga_attach+0x92
> > 0x80b9afd2 is in isavga_attach (/usr/src-svn/sys/isa/vga_isa.c:
> 224).
>  Here is what I see. Only happens on real hardware (not VirtualBox VMs).
> 
>  uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
>  uart0: console (9600,n,8,1)
>  acpi_alloc_wakeup_handler: can't alloc wake memory
> >>> This is probably related to the same cause.  Both this and the x86 BIOS s
> tuff
> >>> need "low" memory (memory below 1MB).
> >>>
> >>> x86bios_alloc() uses contigmalloc() as does acpi_alloc_wakeup_handler().
> >>> Perhaps the recent changes to contigmalloc() affect this?  In particular,
> >>> try reverting r292469 to see if that fixes the issue.
> >> Can't we just keep a pool of those pages around and not give them out
> >> unless someone specifically asks for low memory?
> > vm_phys.c already implements a "soft segregation" under which these
> > pages are only allocated as a last resort, unless
> > kmem_alloc_{attr,contig}() or contigmalloc() is called.
> >
> > What happened is that r292469 changed the order in which we pull from
> > the free lists for kmem_alloc_{attr,contig}() and contigmalloc() so that
> > a bunch of, for example, contigmalloc(low=0, high=4GB) calls, could
> > potentially exhaust physical memory in the range [0, 1MB).  In other
> > words, we're no longer getting the soft segregation among contigmalloc()
> > calls.
> >  
> 
> This patch should suffice to restore the soft segregation among
> contigmalloc() calls.

This fixes it.

pcib2:  at device 15.0 on pci0
pci2:  on pcib2
vgapci0:  mem 0xe800-0xefff,0xfddfe000-0xfdd
f irq 16 at device 0.0 on pci2
vgapci0: Boot video device
amdtemp0:  on hostb3
acpi_tz0:  on acpi0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (9600,n,8,1)
orm0:  at iomem 0xc-0xcc7ff on isa0
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
atkbdc0:  at port 0x60,0x64 on isa0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
powernow0:  on cpu0
powernow1:  on cpu1


-- 
Cheers,
Cy Schubert  or 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Adrian Chadd]

It shouldn't have changed though; you're just requesting memory to use
for x86bios calls.

+jhb - any ideas?


-a


On 8 January 2016 at 20:53, Cy Schubert  wrote:
> Cy Schubert writes:
>> In message <201601080107.u0817kdw078...@slippy.cwsent.com>, Cy Schubert
>> writes:
>> > In message > c
>> > om>
>> > , Adrian Chadd writes:
>> > > Ok,
>> > >
>> > > So try adding this check:
>> > >
>> > > vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
>> > > if (vmbuf == NULL) {
>> > > printf("%s: x86bios_alloc failed!\n", __func__);
>> > > goto fail;
>> > > }
>> > >
>> > > ... that call shouldn't be failing, but if it's truely failing on the
>> > > bcopy(), the only reason is because vmbuf is NULL.
>> >
>> > Thanks. I'll try this.
>> >
>> > vesa.c hasn't changed for a while so I suspect the root cuase may be
>> > somewhere else (we're probably treating the symptom here). Nice thing about
>>
>> > using the same mobo and cpu combination on all my machines (except
>> > laptops), failures are completely reproducible. Might be a good idea to put
>>
>> > in a dtrace probe too.
>>
>> Hi Adrian,
>>
>> Your patch fixed the issue. I've included a dtrace probe. I suspect the
>> error may be BIOS specific and the dtrace probe should help in tracking it
>> down. Does this look good to commit?
>
> A bit of multitasking going on here. I should have included the patch. :~
>
>
>
>
> Cheers,
> Cy Schubert  or 
> FreeBSD UNIX:     Web:  http://www.FreeBSD.org
>
> The need of the many outweighs the greed of the few.
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Cy Schubert]

In message <201601080107.u0817kdw078...@slippy.cwsent.com>, Cy Schubert 
writes:
> In message  om>
> , Adrian Chadd writes:
> > Ok,
> > 
> > So try adding this check:
> > 
> > vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
> > if (vmbuf == NULL) {
> > printf("%s: x86bios_alloc failed!\n", __func__);
> > goto fail;
> > }
> > 
> > ... that call shouldn't be failing, but if it's truely failing on the
> > bcopy(), the only reason is because vmbuf is NULL.
> 
> Thanks. I'll try this.
> 
> vesa.c hasn't changed for a while so I suspect the root cuase may be 
> somewhere else (we're probably treating the symptom here). Nice thing about 
> using the same mobo and cpu combination on all my machines (except 
> laptops), failures are completely reproducible. Might be a good idea to put 
> in a dtrace probe too.

Hi Adrian,

Your patch fixed the issue. I've included a dtrace probe. I suspect the 
error may be BIOS specific and the dtrace probe should help in tracking it 
down. Does this look good to commit?


-- 
Cheers,
Cy Schubert  or 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Cy Schubert]

Cy Schubert writes:
> In message <201601080107.u0817kdw078...@slippy.cwsent.com>, Cy Schubert 
> writes:
> > In message  c
> > om>
> > , Adrian Chadd writes:
> > > Ok,
> > > 
> > > So try adding this check:
> > > 
> > > vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
> > > if (vmbuf == NULL) {
> > > printf("%s: x86bios_alloc failed!\n", __func__);
> > > goto fail;
> > > }
> > > 
> > > ... that call shouldn't be failing, but if it's truely failing on the
> > > bcopy(), the only reason is because vmbuf is NULL.
> > 
> > Thanks. I'll try this.
> > 
> > vesa.c hasn't changed for a while so I suspect the root cuase may be 
> > somewhere else (we're probably treating the symptom here). Nice thing about
>  
> > using the same mobo and cpu combination on all my machines (except 
> > laptops), failures are completely reproducible. Might be a good idea to put
>  
> > in a dtrace probe too.
> 
> Hi Adrian,
> 
> Your patch fixed the issue. I've included a dtrace probe. I suspect the 
> error may be BIOS specific and the dtrace probe should help in tracking it 
> down. Does this look good to commit?

A bit of multitasking going on here. I should have included the patch. :~



Index: vesa.c
===
--- vesa.c  (revision 293386)
+++ vesa.c  (working copy)
@@ -819,6 +819,11 @@
regs.R_AX = 0x4f00;
 
vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
+   if (vmbuf == NULL) {
+   printf("%s: x86bios_alloc failed!\n", __func__);
+   DTRACE_PROBE1(x86bios_alloc_failed, int, vmbuf);
+   goto fail;
+   }
 
regs.R_ES = X86BIOS_PHYSTOSEG(offs);
regs.R_DI = X86BIOS_PHYSTOOFF(offs);
Cheers,
Cy Schubert  or 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Cy Schubert]

In message 
, Adrian Chadd writes:
> Ok,
> 
> So try adding this check:
> 
> vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
> if (vmbuf == NULL) {
> printf("%s: x86bios_alloc failed!\n", __func__);
> goto fail;
> }
> 
> ... that call shouldn't be failing, but if it's truely failing on the
> bcopy(), the only reason is because vmbuf is NULL.

Thanks. I'll try this.

vesa.c hasn't changed for a while so I suspect the root cuase may be 
somewhere else (we're probably treating the symptom here). Nice thing about 
using the same mobo and cpu combination on all my machines (except 
laptops), failures are completely reproducible. Might be a good idea to put 
in a dtrace probe too.


-- 
Cheers,
Cy Schubert  or 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.




___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Cy Schubert]

In message 
, Jeremie Le Hen writes:
> On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd  wrote
> :
> > can you copy/paste the file:line that each of those stackframes represents?
> >
> > I may have an idea or two..
> 
> Sure here we go:
> 
> (kgdb) list *vesa_configure+0x270
> 0x80b25cd0 is in vesa_configure (/usr/src-svn/sys/dev/fb/vesa.c:827).
> 
> (kgdb) list *vga_init+0x65
> 0x80b286e5 is in vga_init (/usr/src-svn/sys/dev/fb/vga.c:1402).
> 
> (kgdb) list *isavga_attach+0x92
> 0x80b9afd2 is in isavga_attach (/usr/src-svn/sys/isa/vga_isa.c:224).

Here is what I see. Only happens on real hardware (not VirtualBox VMs).

uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (9600,n,8,1)
acpi_alloc_wakeup_handler: can't alloc wake memory
orm0:  at iomem 0xc-0xcc7ff on isa0
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x80bb7284
stack pointer   = 0x28:0x81e4f960
frame pointer   = 0x28:0x81e4f970
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0x81e4f4f0
vpanic() at vpanic+0x182/frame 0x81e4f570
panic() at panic+0x43/frame 0x81e4f5d0
trap_fatal() at trap_fatal+0x351/frame 0x81e4f630
trap_pfault() at trap_pfault+0x1e4/frame 0x81e4f690
trap() at trap+0x46e/frame 0x81e4f8a0
calltrap() at calltrap+0x8/frame 0x81e4f8a0
--- trap 0xc, rip = 0x80bb7284, rsp = 0x81e4f970, rbp = 
0x81e4f970 ---
bcopy() at bcopy+0x24/frame 0x81e4f970
vesa_configure() at vesa_configure+0x270/frame 0x81e4fb60
vga_init() at vga_init+0x65/frame 0x81e4fb80
isavga_attach() at isavga_attach+0x92/frame 0x81e4fbc0
device_attach() at device_attach+0x420/frame 0x81e4fc20
isa_probe_children() at isa_probe_children+0x211/frame 0x81e4fc90
mi_startup() at mi_startup+0x108/frame 0x81e4fcb0
btext() at btext+0x2c
Uptime: 1s
acpi0: reset failed - timeout
Automatic reboot in 15 seconds - press a key on the console to abort

It's getting late here. I'll try digging around tomorrow.


-- 
Cheers,
Cy Schubert  or 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Jeremie Le Hen]

On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd  wrote:
> can you copy/paste the file:line that each of those stackframes represents?
>
> I may have an idea or two..

Sure here we go:

(kgdb) list *vesa_configure+0x270
0x80b25cd0 is in vesa_configure (/usr/src-svn/sys/dev/fb/vesa.c:827).

(kgdb) list *vga_init+0x65
0x80b286e5 is in vga_init (/usr/src-svn/sys/dev/fb/vga.c:1402).

(kgdb) list *isavga_attach+0x92
0x80b9afd2 is in isavga_attach (/usr/src-svn/sys/isa/vga_isa.c:224).

-- 
Jeremie Le Hen
j...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Ryan Stone]

On Sun, Dec 20, 2015 at 4:02 PM, Jeremie Le Hen  wrote:

> For some reason, "call doadump"
> didn't work (any idea why?), so I took a picture.
>

I have no idea about the panic, but doadump failed because the crash
happened too early for the dump device to be configured yet.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Adrian Chadd]

can you copy/paste the file:line that each of those stackframes represents?

I may have an idea or two..


-a


On 20 December 2015 at 15:40, Ryan Stone  wrote:
> On Sun, Dec 20, 2015 at 4:02 PM, Jeremie Le Hen  wrote:
>
>> For some reason, "call doadump"
>> didn't work (any idea why?), so I took a picture.
>>
>
> I have no idea about the panic, but doadump failed because the crash
> happened too early for the dump device to be configured yet.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Panic from vesa_configure()

[Jeremie Le Hen]

Hey guys,

I got the panic below with r292509.  For some reason, "call doadump"
didn't work (any idea why?), so I took a picture.

I checked today's commits, there doesn't seem to be to be a fix.

Any clue?

https://people.freebsd.org/~jlh/vesa_panic.jpg

Regards,
-- 
Jeremie Le Hen
j...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"