Hi,
I've made my linux-from-scratch with latest stable (2.4.19) kernel, made
swap, turned it on but it doesn't work. It seems it does but when there's
not enough memory, the system crashes. Either it kills the application
desiring more memory (gcc or something) or crashes the kernel with memory
dump. Neither the 2.4.20-pre5-ac3 helped.
Thank you for your help,
Vladimir Trebicky
--
Vladimir Trebicky
[email protected]
On Sat, 2002-10-26 at 16:14, Vladim?r T?ebick? wrote:
> Hi,
>
> I've made my linux-from-scratch with latest stable (2.4.19) kernel, made
> swap, turned it on but it doesn't work. It seems it does but when there's
> not enough memory, the system crashes. Either it kills the application
> desiring more memory (gcc or something) or crashes the kernel with memory
> dump. Neither the 2.4.20-pre5-ac3 helped.
Does this occur if you take a kernel build on a standard distribution
and boot it on your box rather than one generated by a hand built tool
chain ?
> I've made my linux-from-scratch with latest stable (2.4.19) kernel, made
> swap, turned it on but it doesn't work. It seems it does but when there's
> not enough memory, the system crashes. Either it kills the application
> desiring more memory (gcc or something) or crashes the kernel with memory
> dump. Neither the 2.4.20-pre5-ac3 helped.
Does your swap partition show up in /proc/swaps? It has to contain
something like this:
Filename Type Size Used Priority
/dev/hda6 partition 506008 0 -1
Btw, do you see something swap-related in dmesg? Like:
Unable to find swap-space signature
Unable to handle swap header version ...
Swap area shorter than signature indicates
Empty swap-file
And do you actually see something like this:
Adding Swap: 506008k swap-space (priority -1)
How did you initialized the swap partition? Recent kernels support both
v1 and v2 swaps, which is can be set for mkswap using -v0 (-v1).
Actually i mean did you initialized it at all? 8)
-alex
> Does your swap partition show up in /proc/swaps? It has to contain
> something like this:
I have
/dev/hda6 partition 594364 0 -1
in my /proc/swaps
> Btw, do you see something swap-related in dmesg? Like:
>
> Unable to find swap-space signature
> Unable to handle swap header version ...
> Swap area shorter than signature indicates
> Empty swap-file
>
> And do you actually see something like this:
> Adding Swap: 506008k swap-space (priority -1)
>
In dmesg I see only this, but some problem with signanture is in syslog (at
the
end of this mail)
$ dmesg | grep swap
Starting kswapd
Adding Swap: 594364k swap-space (priority -1)
> How did you initialized the swap partition? Recent kernels support both
> v1 and v2 swaps, which is can be set for mkswap using -v0 (-v1).
> Actually i mean did you initialized it at all? 8)
I just created a partition with fdisk /dev/hda6, done "mkswap /dev/hda6" put
the information to /etc/fstab and turned it on with "swapon -a". TOP shows
Swap: 594364K av, 0K used, 594364K free
syslog logs these kinds of kernel messages (those I guess are important):
Sep 29 22:04:19 shunka kernel: swap_free: Bad swap offset entry 1b3d0000
...
Sep 29 22:04:19 shunka kernel: swap_free: Bad swap offset entry 1b3d0000
...
Sep 10 10:03:28 shunka2 kernel: swap_dup: Bad swap file entry 00000022
...
Sep 4 21:30:40 shunka kernel: Unable to find swap-space signature //
!!!!!!!!
...
Oct 26 19:25:29 shunka kernel: <1>Unable to handle kernel paging request at
virtual address 2064656e
Oct 26 19:25:29 shunka kernel: printing eip:
Oct 26 19:25:29 shunka kernel: c012f781
Oct 26 19:25:29 shunka kernel: *pde = 00000000
Oct 26 19:25:29 shunka kernel: Oops: 0000
Oct 26 19:25:29 shunka kernel: CPU: 0
Oct 26 19:25:29 shunka kernel: EIP: 0010:[<c012f781>] Not tainted
Oct 26 19:25:29 shunka kernel: EFLAGS: 00010202
Oct 26 19:25:29 shunka kernel: eax: c026a19c ebx: c026a19c ecx: c105f584
edx: 2064656e
Oct 26 19:25:29 shunka kernel: esi: c95472f8 edi: c1d57000 ebp: c95472f8
esp: c459de94
Oct 26 19:25:29 shunka kernel: ds: 0018 es: 0018 ss: 0018
Oct 26 19:25:29 shunka kernel: Process cpp0 (pid: 12431, stackpage=c459d000)
Oct 26 19:25:29 shunka kernel: Stack: c105f584 c012f465 c026a19c 01d56067
c105f584 c012091c cb728da0 080be6e4
Oct 26 19:25:29 shunka kernel: 080be6e4 c3823080 c0120963 cb728da0
c60fd7a0 c95472f8 00000001 080be6e4
Oct 26 19:25:29 shunka kernel: cb728da0 080be6e4 080be6e4 c3823080
c0120b8b cb728da0 c60fd7a0 080be6e4
Oct 26 19:25:29 shunka kernel: Call Trace: [<c012f465>] [<c012091c>]
[<c0120963>] [<c0120b8b>] [<c010fe47>]
Oct 26 19:25:29 shunka kernel: [<c010fd34>] [<c0121f78>] [<c0122067>]
[<c0120f40>] [<c0108844>]
Oct 26 19:25:29 shunka kernel:
Oct 26 19:25:29 shunka kernel: Code: 8b 02 89 83 b4 00 00 00 c7 02 00 00 00
00 89 d0 5b c3 90 56
Oct 26 19:25:29 shunka kernel: <1>Unable to handle kernel paging request at
virtual address 6164262c
Oct 26 19:25:29 shunka kernel: printing eip:
Oct 26 19:25:29 shunka kernel: c012f510
Oct 26 19:25:29 shunka kernel: *pde = 00000000
Oct 26 19:25:29 shunka kernel: Oops: 0000
Oct 26 19:25:29 shunka kernel: CPU: 0
Oct 26 19:25:29 shunka kernel: EIP: 0010:[<c012f510>] Not tainted
Oct 26 19:25:29 shunka kernel: EFLAGS: 00010206
Oct 26 19:25:29 shunka kernel: eax: 61642628 ebx: c1089dfc ecx: 00000010
edx: c954713c
Oct 26 19:25:29 shunka kernel: esi: c026a19c edi: c3789760 ebp: 08448000
esp: c459dd10
Oct 26 19:25:29 shunka kernel: ds: 0018 es: 0018 ss: 0018
Oct 26 19:25:29 shunka kernel: Process cpp0 (pid: 12431, stackpage=c459d000)
Oct 26 19:25:29 shunka kernel: Stack: c954713c 00017000 00007000 c011fa1d
c60fd5c0 cb728da0 00017000 08048000
Oct 26 19:25:29 shunka kernel: 08448000 c3823084 c3823084 00000008
00000000 0805f000 c3823080 00000000
Oct 26 19:25:29 shunka kernel: 0805f000 c0122192 cb728da0 08048000
00017000 cb728da0 c459de60 c459c000
Oct 26 19:25:29 shunka kernel: Call Trace: [<c011fa1d>] [<c0122192>]
[<c0112212>] [<c0116265>] [<c0108d59>]
Oct 26 19:25:29 shunka kernel: [<c0110037>] [<c010fd34>] [<c012091c>]
[<c0120963>] [<c0120b8b>] [<c010fe47>]
Oct 26 19:25:29 shunka kernel: [<c015e6c2>] [<c0108844>] [<c012f781>]
[<c012f465>] [<c012091c>] [<c0120963>]
Oct 26 19:25:29 shunka kernel: [<c0120b8b>] [<c010fe47>] [<c010fd34>]
[<c0121f78>] [<c0122067>] [<c0120f40>]
Oct 26 19:25:29 shunka kernel: [<c0108844>]
Oct 26 19:25:29 shunka kernel:
Oct 26 19:25:29 shunka kernel: Code: 39 50 04 75 0e 56 53 57 50 e8 76 02 00
00 83 c4 10 eb 08 89
Oct 26 19:25:29 shunka kernel: <1>Unable to handle kernel paging request at
virtual address 2064656e
Oct 26 19:25:29 shunka kernel: printing eip:
Oct 26 19:25:29 shunka kernel: c012f781
Oct 26 19:25:29 shunka kernel: *pde = 00000000
Oct 26 19:25:29 shunka kernel: Oops: 0000
Oct 26 19:25:29 shunka kernel: CPU: 0
Oct 26 19:25:29 shunka kernel: EIP: 0010:[<c012f781>] Not tainted
Oct 26 19:25:29 shunka kernel: EFLAGS: 00010202
Oct 26 19:25:29 shunka kernel: eax: c026a19c ebx: c026a19c ecx: c97fe744
edx: 2064656e
Oct 26 19:25:29 shunka kernel: esi: c97fe744 edi: 081d1e42 ebp: c39f4080
esp: c6657ebc
Oct 26 19:25:29 shunka kernel: ds: 0018 es: 0018 ss: 0018
Oct 26 19:25:29 shunka kernel: Process cc1 (pid: 12432, stackpage=c6657000)
Oct 26 19:25:29 shunka kernel: Stack: c110d17c c012f465 c026a19c c110d17c
081d1e42 c0120aa1 cb7289e0 081d1e42
Oct 26 19:25:29 shunka kernel: 081d1e42 c39f4080 c0120b8b cb7289e0
c493ed40 081d1e42 00000000 c97fe744
Oct 26 19:25:29 shunka kernel: cb7289e0 081d1e42 cb7289fc c493ed40
c010fe47 cb7289e0 c493ed40 081d1e42
Oct 26 19:25:29 shunka kernel: Call Trace: [<c012f465>] [<c0120aa1>]
[<c0120b8b>] [<c010fe47>] [<c010fd34>]
Oct 26 19:25:29 shunka kernel: [<c01e0e5d>] [<c01e0f5e>] [<c01173ea>]
[<c0109c0d>] [<c0108844>]
Oct 26 19:25:29 shunka kernel:
Oct 26 19:25:29 shunka kernel: Code: 8b 02 89 83 b4 00 00 00 c7 02 00 00 00
00 89 d0 5b c3 90 56
...
Oct 26 19:20:52 shunka kernel: kernel BUG at page_alloc.c:117!
Oct 26 19:20:52 shunka kernel: invalid operand: 0000
Oct 26 19:20:52 shunka kernel: CPU: 0
Oct 26 19:20:52 shunka kernel: EIP: 0010:[<c012ab39>] Not tainted
Oct 26 19:20:52 shunka kernel: EFLAGS: 00010282
Oct 26 19:20:52 shunka kernel: eax: 01000010 ebx: c1111d40 ecx: c026a19c
edx: c10c42a4
Oct 26 19:20:52 shunka kernel: esi: 00000000 edi: 00148000 ebp: 085e5000
esp: c8fb1e30
Oct 26 19:20:52 shunka kernel: ds: 0018 es: 0018 ss: 0018
Oct 26 19:20:52 shunka kernel: Process cc1 (pid: 12012, stackpage=c8fb1000)
Oct 26 19:20:52 shunka kernel: Stack: c1111d40 001e9000 00148000 085e5000
c01173ea 00000046 00000000 c026a19c
Oct 26 19:20:52 shunka kernel: c103400c c026a1d8 00000216 ffffffff
00003321 c012b389 c012b807 c1111d40
Oct 26 19:20:52 shunka kernel: c011f5f9 c1111d40 c3af5cb4 c011fa2b
05441067 c493ec80 cb728bc0 001e9000
Oct 26 19:20:52 shunka kernel: Call Trace: [<c01173ea>] [<c012b389>]
[<c012b807>] [<c011f5f9>] [<c011fa2b>]
Oct 26 19:20:52 shunka kernel: [<c0122192>] [<c0112212>] [<c0116265>]
[<c011b21a>] [<c01085cf>] [<c010fd34>]
Oct 26 19:20:52 shunka kernel: [<c0122067>] [<c01173ea>] [<c0120f40>]
[<c0108844>] [<c0108774>]
Oct 26 19:20:52 shunka kernel:
Oct 26 19:20:52 shunka kernel: Code: 0f 0b 75 00 2c c1 22 c0 8b 43 18 24 eb
89 43 18 c6 43 24 05
Thanks,
Vladimir Trebicky
--
Vladimir Trebicky
[email protected]
Vladim?r Trebick?, Sun, Oct 27, 2002 09:51:17 +0100:
> > Does your swap partition show up in /proc/swaps? It has to contain
> > something like this:
> I have
> /dev/hda6 partition 594364 0 -1
looks ok.
> > Btw, do you see something swap-related in dmesg? Like:
>
> In dmesg I see only this, but some problem with signanture is in syslog
> (at the end of this mail)
>
> $ dmesg | grep swap
> Starting kswapd
> Adding Swap: 594364k swap-space (priority -1)
>
> > How did you initialized the swap partition? Recent kernels support both
> > v1 and v2 swaps, which is can be set for mkswap using -v0 (-v1).
> > Actually i mean did you initialized it at all? 8)
>
> I just created a partition with fdisk /dev/hda6, done "mkswap /dev/hda6" put
May i assume you did swapoff before?
> the information to /etc/fstab and turned it on with "swapon -a". TOP shows
> Swap: 594364K av, 0K used, 594364K free
>
> syslog logs these kinds of kernel messages (those I guess are important):
>
> Sep 29 22:04:19 shunka kernel: swap_free: Bad swap offset entry 1b3d0000
> ...
> Sep 29 22:04:19 shunka kernel: swap_free: Bad swap offset entry 1b3d0000
> ...
> Sep 10 10:03:28 shunka2 kernel: swap_dup: Bad swap file entry 00000022
You change hostname inbetween or this is just a typo?
> Sep 4 21:30:40 shunka kernel: Unable to find swap-space signature //
> !!!!!!!!
Wow. Any of the errors above prevents swap partition from being used.
How did you manage to see anything in /proc/swaps?
I suggest you do:
swapoff /dev/hda6
badblocks /dev/hda6
Alternatively, you can try
dd if=/dev/zero of=/dev/hda6; mkswap /dev/hda6
Look for "SWAP-SPACE" (old swap) or "SWAPSPACE2" (the new one).
Just to make sure you've initialized the partition properly.
Than turn it on: swapon /dev/hda6; tail /var/log/syslog
> Oct 26 19:25:29 shunka kernel: <1>Unable to handle kernel paging request at
> virtual address 2064656e
Oops, you've sent, is pretty useless without decoding. Read
Documentation/oops-tracing.txt from the kernel source tree.
-alex
Am Sonntag, 27. Oktober 2002 09:51 schrieb Vladim?r Trebick?:
> > Does your swap partition show up in /proc/swaps? It has to contain
> > something like this:
>
> I have
> /dev/hda6 partition 594364 0 -1
> in my /proc/swaps
>
> > Btw, do you see something swap-related in dmesg? Like:
> >
> > Unable to find swap-space signature
> > Unable to handle swap header version ...
> > Swap area shorter than signature indicates
> > Empty swap-file
> >
> > And do you actually see something like this:
> > Adding Swap: 506008k swap-space (priority -1)
>
> In dmesg I see only this, but some problem with signanture is in syslog
> (at the
> end of this mail)
>
> $ dmesg | grep swap
> Starting kswapd
> Adding Swap: 594364k swap-space (priority -1)
>
> > How did you initialized the swap partition? Recent kernels support both
> > v1 and v2 swaps, which is can be set for mkswap using -v0 (-v1).
> > Actually i mean did you initialized it at all? 8)
>
> I just created a partition with fdisk /dev/hda6, done "mkswap /dev/hda6"
> put the information to /etc/fstab and turned it on with "swapon -a". TOP
> shows Swap: 594364K av, 0K used, 594364K free
>
> syslog logs these kinds of kernel messages (those I guess are important):
>
> Sep 29 22:04:19 shunka kernel: swap_free: Bad swap offset entry 1b3d0000
> ...
> Sep 29 22:04:19 shunka kernel: swap_free: Bad swap offset entry 1b3d0000
> ...
> Sep 10 10:03:28 shunka2 kernel: swap_dup: Bad swap file entry 00000022
> ...
> Sep 4 21:30:40 shunka kernel: Unable to find swap-space signature
> // !!!!!!!!
> ...
Just one hint, maybe this works: dump your swap partition witz zeros, i.e.
dd if=/dev/zero of=/dev/hda6
Keep an eye on the logs (Any IO-errors here regarding /dev/hda6?)
re-create your swap partition with mkswap
Of course, you should turn off swapping before starting this ;-)
Greetings,
Alex
--
Alexander Puchmayr Systemadministrator for Theoretical Physics
University Linz, Austria e-mail: [email protected]
Altenbergerstrasse 69 phone: +43/732/2468-8633
A-4040 Linz-Auhof FAX: +43/732/2468-8585
> You change hostname inbetween or this is just a typo?
yes, I did ;-)
> Wow. Any of the errors above prevents swap partition from being used.
> How did you manage to see anything in /proc/swaps?
> I suggest you do:
> swapoff /dev/hda6
> badblocks /dev/hda6
Badblocks finds each time ONE bad block at the end of the partition no
matter where I create it or how large the partition is. Syslog shows this
message:
Oct 27 10:57:45 shunka kernel: attempt to access beyond end of device
Oct 27 10:57:45 shunka kernel: 03:06: rw=0, want=594376, limit=594373
Oct 27 10:57:45 shunka kernel: attempt to access beyond end of device
Oct 27 10:57:45 shunka kernel: 03:06: rw=0, want=594376, limit=594373
> Alternatively, you can try
>
> dd if=/dev/zero of=/dev/hda6; mkswap /dev/hda6
>
the same occurs when I try to
dd if=/dev/zero of=/dev/hda6 bs=1024 count=594373
dd: writing `/dev/hda6': Input/output error
594373+0 records in
594372+0 records out
---
Oct 27 11:40:40 shunka kernel: attempt to access beyond end of device
Oct 27 11:40:40 shunka kernel: 03:06: rw=0, want=594376, limit=594373
I've tried many times to repartition the whole disk...
> Look for "SWAP-SPACE" (old swap) or "SWAPSPACE2" (the new one).
> Just to make sure you've initialized the partition properly.
> Than turn it on: swapon /dev/hda6; tail /var/log/syslog
where should I try to find it? ("SWAP-SPACE" | "SWAPSPACE2")
> Oops, you've sent, is pretty useless without decoding. Read
> Documentation/oops-tracing.txt from the kernel source tree.
I have some problem with ksymoops - some unresolved symbols. I read about it
and problems with binutils and their libraries. I hope, I'll solve this
quick.
What means the problems I (only) once noticed about the signature?
Thanks,
Vladimir Trebicky
--
Vladimir Trebicky
[email protected]
On Sun, Oct 27, 2002 at 12:07:44PM +0100, Vladim?r T?ebick? wrote:
> > Wow. Any of the errors above prevents swap partition from being used.
> > How did you manage to see anything in /proc/swaps?
> > I suggest you do:
> > swapoff /dev/hda6
> > badblocks /dev/hda6
> Badblocks finds each time ONE bad block at the end of the partition no
> matter where I create it or how large the partition is. Syslog shows this
> message:
> Oct 27 10:57:45 shunka kernel: attempt to access beyond end of device
> Oct 27 10:57:45 shunka kernel: 03:06: rw=0, want=594376, limit=594373
That's not a badblock. That's an kernel IDE bug. Andre Hedrick and Alan
Cox will love to see this.
> > Look for "SWAP-SPACE" (old swap) or "SWAPSPACE2" (the new one).
> > Just to make sure you've initialized the partition properly.
> > Than turn it on: swapon /dev/hda6; tail /var/log/syslog
> where should I try to find it? ("SWAP-SPACE" | "SWAPSPACE2")
At the beginning. The searching for it doesn't make sense now.
> What mean the problems I (only) once noticed about the signature?
Nothing special. You just have something broken in a particularly
unpredictable way.
On Sun, 2002-10-27 at 12:50, Alex Riesen wrote:
> On Sun, Oct 27, 2002 at 12:07:44PM +0100, Vladim?r T?ebick? wrote:
> > > Wow. Any of the errors above prevents swap partition from being used.
> > > How did you manage to see anything in /proc/swaps?
> > > I suggest you do:
> > > swapoff /dev/hda6
> > > badblocks /dev/hda6
> > Badblocks finds each time ONE bad block at the end of the partition no
> > matter where I create it or how large the partition is. Syslog shows this
> > message:
> > Oct 27 10:57:45 shunka kernel: attempt to access beyond end of device
> > Oct 27 10:57:45 shunka kernel: 03:06: rw=0, want=594376, limit=594373
>
> That's not a badblock. That's an kernel IDE bug. Andre Hedrick and Alan
> Cox will love to see this.
Not on a kernel built with an untrusted hand built tool chain
> > That's not a badblock. That's an kernel IDE bug. Andre Hedrick and Alan
> > Cox will love to see this.
>
> Not on a kernel built with an untrusted hand built tool chain
>
Well, I don't know what could possibly cause this kind of error except
kernel.
No matter what application I use to read or write /dev/hda6. Which part
of my tool chain do you have in mind?
Thanks,
Vladimir Trebicky
--
Vladimir Trebicky
[email protected]
On Sun, 2002-10-27 at 14:48, Vladim?r T?ebick? wrote:
> > > That's not a badblock. That's an kernel IDE bug. Andre Hedrick and Alan
> > > Cox will love to see this.
> >
> > Not on a kernel built with an untrusted hand built tool chain
> >
> Well, I don't know what could possibly cause this kind of error except
> kernel.
> No matter what application I use to read or write /dev/hda6. Which part
> of my tool chain do you have in mind?
gcc and binutils. I get so many weird never duplicated reports from
linux from scratch people that don't happen to anyone else that I treat
them with deep suspicion. Especially because it sometimes goes away if
they instead build the same kernel with Debian/Red Hat/.. binutils/gcc
Hi Alan
> On Sun, 2002-10-27 at 14:48, Vladim?r T?ebick? wrote:
> > > > That's not a badblock. That's an kernel IDE bug. Andre Hedrick and
> > > > Alan Cox will love to see this.
> > >
> > > Not on a kernel built with an untrusted hand built tool chain
> > >
> > Well, I don't know what could possibly cause this kind of error except
> > kernel.
> > No matter what application I use to read or write /dev/hda6. Which
> > part of my tool chain do you have in mind?
>
> gcc and binutils. I get so many weird never duplicated reports from
> linux from scratch people that don't happen to anyone else that I treat
> them with deep suspicion. Especially because it sometimes goes away if
> they instead build the same kernel with Debian/Red Hat/.. binutils/gcc
Not that I would know better or have an idea why this bug happens, but to
say "Bugger off if you have an lfs system" is a bit lousy, I think. After
all, lfs has not really an "unstrusted toolchain", as compared to
RH/Suse's/Debian "trustworthy computing toolchains":
lfs has a manual with clearly specified package versions, patches and
order of "toolchaining". It might well be a bug in that chain, but other
distros have bugs, too. Signing software doesn't make it superior, after
all.
However, the error does not happen on my crappy lfs system, but then
again, I run it in a vmware, with the virtual disks set up as scsi...
Bye
Tim
On Sun, Oct 27, 2002 at 08:41:10PM +0100, Tim Tassonis wrote:
> Not that I would know better or have an idea why this bug happens, but to
> say "Bugger off if you have an lfs system" is a bit lousy, I think. After
> all, lfs has not really an "unstrusted toolchain", as compared to
> RH/Suse's/Debian "trustworthy computing toolchains":
Sorry, tons of people that have absolute no clue about the package
internals set up their systems themselves and make mistakes. nothing
spectacular, but they just don't have those people who know the
packages in detail and can notice and fix the bugs. Just get binary
rpm/deb whatever of the toolchain and reproduce.
> lfs has a manual with clearly specified package versions, patches and
> order of "toolchaining". It might well be a bug in that chain, but other
> distros have bugs, too. Signing software doesn't make it superior, after
> all.
but having people who understand the software maintain the
packages sometimes helps :)
> Sorry, tons of people that have absolute no clue about the package
> internals set up their systems themselves and make mistakes. nothing
> spectacular, but they just don't have those people who know the
> packages in detail and can notice and fix the bugs. Just get binary
> rpm/deb whatever of the toolchain and reproduce.
As I said, I can't reproduce it even on my lfs system, maybe because my
disks are scsi. So reproducing on my Red Hat wouldn't really help, would
it?
> > lfs has a manual with clearly specified package versions, patches and
> > order of "toolchaining". It might well be a bug in that chain, but
> > other distros have bugs, too. Signing software doesn't make it
> > superior, after all.
>
> but having people who understand the software maintain the
> packages sometimes helps :)
As far as I know, lfs does not maintain the packages. binutils and gcc are
maintained by FSF to my knowledge.
Bye
Tim
On Sun, 2002-10-27 at 19:41, Tim Tassonis wrote:
> Not that I would know better or have an idea why this bug happens, but to
> say "Bugger off if you have an lfs system" is a bit lousy, I think. After
> all, lfs has not really an "unstrusted toolchain", as compared to
> RH/Suse's/Debian "trustworthy computing toolchains":
I get bugs that are clearly caused by miscompiled tool chains from Linux
from scratch people. I trust the RH, SuSE and Debian tool chains because
they have any neccessary patches applied for compiler bugs and they are
running against a properly built glibc and binutils.
If you simply grab the latest and greatest of everything from
ftp.gnu.org then quite often it won't work.
If you'd like to me to spend hours debugging an LFS system where its
probably a tool error, then you can ask for current hourly rates.
Alan
On 27 Oct 2002 21:17:34 +0000
Alan Cox <[email protected]> wrote:
> On Sun, 2002-10-27 at 19:41, Tim Tassonis wrote:
> > Not that I would know better or have an idea why this bug happens, but
> > to say "Bugger off if you have an lfs system" is a bit lousy, I think.
> > After all, lfs has not really an "unstrusted toolchain", as compared
> > to RH/Suse's/Debian "trustworthy computing toolchains":
>
> I get bugs that are clearly caused by miscompiled tool chains from Linux
> from scratch people. I trust the RH, SuSE and Debian tool chains because
> they have any neccessary patches applied for compiler bugs and they are
> running against a properly built glibc and binutils.
>
> If you simply grab the latest and greatest of everything from
> ftp.gnu.org then quite often it won't work.
That's certainly true and before claiming a kernel bug, I would try
against a Red Hat System personally. Still, lfs does have gcc patches
included, it's not just cvs checkout from the relevant packages. It also
seems to have a sane order of compiling everything.
> If you'd like to me to spend hours debugging an LFS system where its
> probably a tool error, then you can ask for current hourly rates.
That wasn't actually my idea. And you are right, before claiming a kernel
bug one should probably always try to reproduce it against a different
system.
Bye
Tim
Hi all,
Lately I've been struggeling with kernels Oopsing in page_alloc.c,
rmqueue() function. The line which triggers the Oops is actually in
expand() which is inlined from rmqueue() (and others). In my kernel source
(2.4.20-pre11), expand looks like this :
#define MARK_USED(index, order, area) \
__change_bit((index) >> (1+(order)), (area)->map)
static inline struct page * expand (zone_t *zone, struct page *page,
unsigned long index, int low, int high, free_area_t * area)
{
unsigned long size = 1 << high;
while (high > low) {
if (BAD_RANGE(zone,page))
BUG();
area--;
high--;
size >>= 1;
list_add(&(page)->list, &(area)->free_list);
MARK_USED(index, high, area);
index += size;
page += size;
}
if (BAD_RANGE(zone,page))
BUG();
return page;
}
The line that triggers the BUG is the last BAD_RANGE check. The module
that calls __alloc_pages() is doing it in the following way :
addr = __get_free_page(GFP_KERNEL);
and frees the page with free_page(addr);
The machine configuration is RedHat 7.3 (gcc-2.96-110,
binutils-2.11.93.0.2-11), 2 Xeon processors @ 2.2 GHz and 2GB RAM.
The module in question is not a part of the kernel tree, but the source is
available if someone is interested. However, I'm really interrested in
situations that could cause BAD_RANGE() to fail (since it is commented
with a "Temporary debugging check") because of the above usage (which
seems very straight forward to me).
The really strange thing is that the problem seem to disappear if I apply
the per_cpu_pages patch by Ingo Molnar as found in the RedHat
2.4.18-17.7.x kernel with a few modifications to make it fit on
2.4.20-pre11 (attached).
Any help greatly appreciated.
Thanks,
--
Steffen Persvold | Scali AS
mailto:[email protected] | http://www.scali.com
Tel: (+47) 2262 8950 | Olaf Helsets vei 6
Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY