Hello,
Brent W. Baccala, on Wed 17 Aug 2016 10:58:41 -1000, wrote:
> OK, I seem to have gotten a handle on this thing now.
Cool :)
> First, there's a missing mutex unlock in mach_defpager. I'm attaching two
> patches. One fixes the debug printfs in mach_defpager/default_pager.c, which
> obviou
Aloha -
OK, I seem to have gotten a handle on this thing now.
First, there's a missing mutex unlock in mach_defpager. I'm attaching two
patches. One fixes the debug printfs in mach_defpager/default_pager.c,
which obviously haven't been compiled for a while. Use %p and %lx instead
of %x to sile
Aloha -
I've updated to the latest Debian kernel package, which includes Samuel's
patch. (thank you)
This fixes the symbol table problem, but my VM still locks up after a
failed swapoff.
I do, however, get symbolic names displayed correctly from the kernel
debugger at that point.
Obviously, th
On Fri, Aug 12, 2016 at 09:07:48PM +0200, Samuel Thibault wrote:
> > I'm curious: what makes it definitely wrong on a PC ?
>
> A PC has BIOS stuff between A and 10.
Right, misread a 0 again.
--
Richard Braun
Richard Braun, on Fri 12 Aug 2016 21:06:48 +0200, wrote:
> On Fri, Aug 12, 2016 at 07:53:08PM +0200, Samuel Thibault wrote:
> > That's what I'm talking about, and that's the second part of the printfs
> > above, and they are wrong: 1-100 is definitely wrong on a PC,
> > and it includes the
On Fri, Aug 12, 2016 at 07:53:08PM +0200, Samuel Thibault wrote:
> That's what I'm talking about, and that's the second part of the printfs
> above, and they are wrong: 1-100 is definitely wrong on a PC,
> and it includes the debugging symbols.
I'm curious: what makes it definitely wrong o
Samuel Thibault, on Fri 12 Aug 2016 19:53:08 +0200, wrote:
> Yes, but only the heap. The load of segments not containing the heap is
> full:
>
> vm_page_load 1-100 1-100
> vm_page_load 7a00-7ffe 7a00-7ffe
(and only loading the available part of the heap would not p
Richard Braun, on Fri 12 Aug 2016 19:57:10 +0200, wrote:
> On Fri, Aug 12, 2016 at 05:17:26PM +0200, Samuel Thibault wrote:
> > biosmem: heap: 114f000-7a00
> >
> > and objdump shows:
> >
> > LOAD off0x1000 vaddr 0x8100 paddr 0x0100 align 2**12
> > filesz 0x0011470
On Fri, Aug 12, 2016 at 07:57:10PM +0200, Richard Braun wrote:
> On Fri, Aug 12, 2016 at 05:17:26PM +0200, Samuel Thibault wrote:
> > biosmem: heap: 114f000-7a00
> >
> > and objdump shows:
> >
> > LOAD off0x1000 vaddr 0x8100 paddr 0x0100 align 2**12
> > filesz 0x0
On Fri, Aug 12, 2016 at 05:17:26PM +0200, Samuel Thibault wrote:
> biosmem: heap: 114f000-7a00
>
> and objdump shows:
>
> LOAD off0x1000 vaddr 0x8100 paddr 0x0100 align 2**12
> filesz 0x00114700 memsz 0x00114700 flags r-x
> LOAD off0x00116000 vaddr 0x81115
Richard Braun, on Fri 12 Aug 2016 19:50:51 +0200, wrote:
> On Fri, Aug 12, 2016 at 07:08:07PM +0200, Samuel Thibault wrote:
> > More precisely though, adding debugging to vm_page_load:
> >
> > vm_page_load 1-100 1-100
> > vm_page_load 100-7a00 114f000-79c41000
> > vm_page_l
On Fri, Aug 12, 2016 at 07:08:07PM +0200, Samuel Thibault wrote:
> More precisely though, adding debugging to vm_page_load:
>
> vm_page_load 1-100 1-100
> vm_page_load 100-7a00 114f000-79c41000
> vm_page_load 7a00-7ffe 7a00-7ffe
>
> I.e. it properly skips t
Samuel Thibault, on Fri 12 Aug 2016 19:08:07 +0200, wrote:
> What is supposed to exclude everything else? (modules, VGA BIOS, etc.)
I'm tempted to apply the attached patch at least to the Debian package
to brown-tape-fix the issue.
What it does is:
- Make biosmem_load_segment look for the bigges
Hello,
Samuel Thibault, on Fri 12 Aug 2016 17:27:42 +0200, wrote:
> Samuel Thibault, on Fri 12 Aug 2016 17:17:26 +0200, wrote:
> > biosmem: heap: 114f000-7a00
> >
> > and objdump shows:
> >
> > LOAD off0x1000 vaddr 0x8100 paddr 0x0100 align 2**12
> > filesz 0x001
Samuel Thibault, on Fri 12 Aug 2016 17:17:26 +0200, wrote:
> biosmem: heap: 114f000-7a00
>
> and objdump shows:
>
> LOAD off0x1000 vaddr 0x8100 paddr 0x0100 align 2**12
> filesz 0x00114700 memsz 0x00114700 flags r-x
> LOAD off0x00116000 vaddr 0x81115000 pa
Brent W. Baccala, on Thu 11 Aug 2016 15:29:27 -1000, wrote:
> On Wed, Aug 10, 2016 at 4:33 AM, Richard Braun <[1]rbr...@sceen.net> wrote:
>
> On Wed, Aug 10, 2016 at 04:26:35PM +0200, Richard Braun wrote:
> > the boot loader (see MULTIBOOT_FLAGS in boothdr.S), and at
> > some point, la
On Wed, Aug 10, 2016 at 4:33 AM, Richard Braun wrote:
> On Wed, Aug 10, 2016 at 04:26:35PM +0200, Richard Braun wrote:
> > the boot loader (see MULTIBOOT_FLAGS in boothdr.S), and at
> > some point, late during the boot process, module data are freed
> > using (see free_bootstrap_pages in bootstra
On Wed, Aug 10, 2016 at 04:26:35PM +0200, Richard Braun wrote:
> the boot loader (see MULTIBOOT_FLAGS in boothdr.S), and at
> some point, late during the boot process, module data are freed
> using (see free_bootstrap_pages in bootstrap.c). This might
Using vm_page_manage().
--
Richard Braun
On Tue, Aug 09, 2016 at 03:37:00PM -1000, Brent W. Baccala wrote:
> GDB on the kernel shows a seemingly corrupted ELF symbol table when
> elf_db_search_symbol() is called.
The symbol table is preserved by the early allocation code
(see biosmem.c) and should normally never be touched. But I've
just
On Mon, Aug 8, 2016 at 9:32 PM, Justus Winter wrote:
> Hello,
>
> "Brent W. Baccala" writes:
>
> > I don't have to swapoff to have "symptoms". The kernel debugger normally
> > shows symbolic names, i.e:
> >
> > Stopped at machine_idle+0xe: leave
> > machine_idle(0,81a2c630,3806f64,0,9b448b3
Hello,
"Brent W. Baccala" writes:
> Further progress trying to track this down:
>
> I don't have to shutdown the system to have problems. "swapoff /dev/hd0s5"
> is enough to cause problems, once enough swap is in use. After a failed
> swapoff, I have an extra 98 storeio processes running!
:(
Further progress trying to track this down:
I don't have to shutdown the system to have problems. "swapoff /dev/hd0s5"
is enough to cause problems, once enough swap is in use. After a failed
swapoff, I have an extra 98 storeio processes running!
I don't have to swapoff to have "symptoms". The
Hi,
Justus Winter wrote:
>Have you tried using halt-hurd instead of shutdown? As far as I can
>remember, halt-hurd has never caused file system corruption for me,
>but I'm pretty sure shutdown did way back when I was still trying
>to use it.
That is correct. halt-hurd is basically halt -f, whi
"Brent W. Baccala" writes:
> On Sat, Aug 6, 2016 at 7:59 AM, Justus Winter wrote:
>
>>
>> To prevent filesystem damage, try the following. Break into the kernel
>> debugger, and kill the auth server using:
>>
>> !task_terminate($task5)
>>
>> Then continue using "c", and /hurd/startup should cle
On Sat, Aug 6, 2016 at 7:59 AM, Justus Winter wrote:
>
> To prevent filesystem damage, try the following. Break into the kernel
> debugger, and kill the auth server using:
>
> !task_terminate($task5)
>
> Then continue using "c", and /hurd/startup should cleanly shutdown the
> system.
>
>
The pro
Please use a MUA that does not break threads like this.
Esa Peuha writes:
> Have you tried using halt-hurd instead of shutdown? As far as I can
> remember, halt-hurd has never caused file system corruption for me,
> but I'm pretty sure shutdown did way back when I was still trying
> to use it.
Have you tried using halt-hurd instead of shutdown? As far as I can
remember, halt-hurd has never caused file system corruption for me,
but I'm pretty sure shutdown did way back when I was still trying
to use it.
Hi :)
"Brent W. Baccala" writes:
> Aloha!
>
> Well, I think that I've resolved my boot hangs by removing the
> -no-kvm-irqchip flag, now I'm trying to resolve the occasional hang when
> the system shuts down. The filesystem always gets corrupted if the system
> can't cleanly halt, so it's a rea
Aloha!
Well, I think that I've resolved my boot hangs by removing the
-no-kvm-irqchip flag, now I'm trying to resolve the occasional hang when
the system shuts down. The filesystem always gets corrupted if the system
can't cleanly halt, so it's a real problem.
Here's some debugging info from the
29 matches
Mail list logo
