Re: Compiling 2.4.1: undefined reference to `__buggy_fxsr_alignment'
I used regular gcc 2.95.2 and it compiled and linked without problems. Thanks. Shawn Starr wrote: > > pgcc borks 2.4.1 kernel and prereleases (sadly I found this out the same > way). > > Shawn. > Matt Yourst wrote: > > > Hi, > > > > I just tried to compile 2.4.1 and I'm getting the error "undefined > > reference to `__buggy_fxsr_alignment'" when trying to do the final > > link. It looks like this check was something 2.4.1 added to > > include/asm-i386/bugs.h to fail the kernel build if part of the thread > > structure wasn't aligned on a 16-byte boundary (which seems to make > > sense given FXSR's alignment requirements.) When was this check added? > > I assumed it was a bug in 2.4.0 that was just recently discovered, but > > I didn't see anything in the ChangeLog to that effect. >... - Matt T. YourstMassachusetts Institute of Technology [EMAIL PROTECTED] 617.225.7690 513 French House - 476 Memorial Drive - Cambridge, MA 02139 - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Compiling 2.4.1: undefined reference to `__buggy_fxsr_alignment'
Hi, I just tried to compile 2.4.1 and I'm getting the error "undefined reference to `__buggy_fxsr_alignment'" when trying to do the final link. It looks like this check was something 2.4.1 added to include/asm-i386/bugs.h to fail the kernel build if part of the thread structure wasn't aligned on a 16-byte boundary (which seems to make sense given FXSR's alignment requirements.) When was this check added? I assumed it was a bug in 2.4.0 that was just recently discovered, but I didn't see anything in the ChangeLog to that effect. The problem is that I don't know how to fix it (at least not reliably and cleanly.) I tried rearranging the fields in the task structure, but the alignment still wasn't right. I did apply a few non-standard patches that expanded the task structure, but the additional fields came well after the task's struct thread (which was causing the alignment problem.) FYI, I'm compiling with pgcc 2.95.2 and linking with binutils/ld 2.10 (I've used both of these successfully for countless kernel compiles before this.) Anyone else had this problem? - Matt Yourst - Matt T. YourstMassachusetts Institute of Technology [EMAIL PROTECTED] 617.225.7690 513 French House - 476 Memorial Drive - Cambridge, MA 02139 - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Compiling 2.4.1: undefined reference to `__buggy_fxsr_alignment'
Hi, I just tried to compile 2.4.1 and I'm getting the error "undefined reference to `__buggy_fxsr_alignment'" when trying to do the final link. It looks like this check was something 2.4.1 added to include/asm-i386/bugs.h to fail the kernel build if part of the thread structure wasn't aligned on a 16-byte boundary (which seems to make sense given FXSR's alignment requirements.) When was this check added? I assumed it was a bug in 2.4.0 that was just recently discovered, but I didn't see anything in the ChangeLog to that effect. The problem is that I don't know how to fix it (at least not reliably and cleanly.) I tried rearranging the fields in the task structure, but the alignment still wasn't right. I did apply a few non-standard patches that expanded the task structure, but the additional fields came well after the task's struct thread (which was causing the alignment problem.) FYI, I'm compiling with pgcc 2.95.2 and linking with binutils/ld 2.10 (I've used both of these successfully for countless kernel compiles before this.) Anyone else had this problem? - Matt Yourst - Matt T. YourstMassachusetts Institute of Technology [EMAIL PROTECTED] 617.225.7690 513 French House - 476 Memorial Drive - Cambridge, MA 02139 - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Compiling 2.4.1: undefined reference to `__buggy_fxsr_alignment'
I used regular gcc 2.95.2 and it compiled and linked without problems. Thanks. Shawn Starr wrote: pgcc borks 2.4.1 kernel and prereleases (sadly I found this out the same way). Shawn. Matt Yourst wrote: Hi, I just tried to compile 2.4.1 and I'm getting the error "undefined reference to `__buggy_fxsr_alignment'" when trying to do the final link. It looks like this check was something 2.4.1 added to include/asm-i386/bugs.h to fail the kernel build if part of the thread structure wasn't aligned on a 16-byte boundary (which seems to make sense given FXSR's alignment requirements.) When was this check added? I assumed it was a bug in 2.4.0 that was just recently discovered, but I didn't see anything in the ChangeLog to that effect. ... - Matt T. YourstMassachusetts Institute of Technology [EMAIL PROTECTED] 617.225.7690 513 French House - 476 Memorial Drive - Cambridge, MA 02139 - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: / on ramfs, possible? [yes! - patch included]
Hi, I read your post and I think I have just what you're looking for. I've attached a patch that allows you to mount root as ramfs and populate it directly from a tar archive (specified just like an initrd image, but without having to deal with a fixed-size initrd or pivot_root at all.) This was based on some earlier work from the Linux router project that I rewrote and ported to 2.2 and 2.4 a few months ago. I didn't post it to the list since I figured it was too late for 2.4.0, but if you're interested, here it is. Here's the Configure.help description: CONFIG_RAMFS_ROOT Allow the kernel to mount a ramfs namespace as the root filesystem or as a pre-root filesystem for running a /linuxrc script (similar to how initial RAM disk (initrd) support works.) Since ramfs has no physical or virtual block device to provide its data as an initrd image would, you must provide a standard tar format archive to be extracted into the empty ramfs root filesystem. Currently this tar archive may *not* be compressed (i.e., tar.gz style); if compression is desired, use a bootloader with automatic gunzip support such as GRUB. To specify the tar archive used to build the root filesystem, use the initrd= kernel command line option (except with a tar archive instead of a real ext2/minix/romfs filesystem image.) To mount the tar archive as the actual root filesystem, specify the same initrd= option above and also include "root=/dev/ramfs" in the kernel command line. You may enable both this option and initrd support; however, if a tar archive is detected instead of an initrd-supported filesystem image, this option will override initrd support. Note: Some versions of GNU tar create invalid archives that cannot be extracted by the kernel. In particular, tar may add a file to an archive without previously adding its containing directory. If your ramfs archive does not mount correctly because of this, try creating it in another way or with another file order. (Patch should apply to 2.4.0-test10-pre6 on i386. It needs to be updated for other architectures, mostly in setup.c though.) I hope this is helpful. Maybe the maintainers would like to comment on this too (i.e., might it be considered for 2.4.1, etc.?) - Matt Yourst - Matt T. YourstMassachusetts Institute of Technology [EMAIL PROTECTED] 617.225.7690 513 French House - 476 Memorial Drive - Cambridge, MA 02136 - linux-ramfs-tar-root.diff
Re: / on ramfs, possible? [yes! - patch included]
Hi, I read your post and I think I have just what you're looking for. I've attached a patch that allows you to mount root as ramfs and populate it directly from a tar archive (specified just like an initrd image, but without having to deal with a fixed-size initrd or pivot_root at all.) This was based on some earlier work from the Linux router project that I rewrote and ported to 2.2 and 2.4 a few months ago. I didn't post it to the list since I figured it was too late for 2.4.0, but if you're interested, here it is. Here's the Configure.help description: CONFIG_RAMFS_ROOT Allow the kernel to mount a ramfs namespace as the root filesystem or as a pre-root filesystem for running a /linuxrc script (similar to how initial RAM disk (initrd) support works.) Since ramfs has no physical or virtual block device to provide its data as an initrd image would, you must provide a standard tar format archive to be extracted into the empty ramfs root filesystem. Currently this tar archive may *not* be compressed (i.e., tar.gz style); if compression is desired, use a bootloader with automatic gunzip support such as GRUB. To specify the tar archive used to build the root filesystem, use the initrd=filename kernel command line option (except with a tar archive instead of a real ext2/minix/romfs filesystem image.) To mount the tar archive as the actual root filesystem, specify the same initrd=filename option above and also include "root=/dev/ramfs" in the kernel command line. You may enable both this option and initrd support; however, if a tar archive is detected instead of an initrd-supported filesystem image, this option will override initrd support. Note: Some versions of GNU tar create invalid archives that cannot be extracted by the kernel. In particular, tar may add a file to an archive without previously adding its containing directory. If your ramfs archive does not mount correctly because of this, try creating it in another way or with another file order. (Patch should apply to 2.4.0-test10-pre6 on i386. It needs to be updated for other architectures, mostly in setup.c though.) I hope this is helpful. Maybe the maintainers would like to comment on this too (i.e., might it be considered for 2.4.1, etc.?) - Matt Yourst - Matt T. YourstMassachusetts Institute of Technology [EMAIL PROTECTED] 617.225.7690 513 French House - 476 Memorial Drive - Cambridge, MA 02136 - linux-ramfs-tar-root.diff
[BUG] 2.4.0-test10-pre4: kernel BUG at vmscan.c:102!
The following bug was just logged for 2.4.0-test10-pre4.
The machine was recompiling glibc (off a ReiserFS 3.6.18 filesystem)
and X was just running a screensaver at the time this happened. X was
locked up and I couldn't switch to a console, so I killed it with
Alt+SysRq. I was then able to get a task list with Alt+SysRq and cc1
was in the D state (along with kswapd in the Z state.) At this point I
synced and rebooted.
Oct 19 17:52:26 argentium kernel: kernel BUG at vmscan.c:102!
Oct 19 17:52:26 argentium kernel: invalid operand:
Oct 19 17:52:26 argentium kernel: CPU:0
Oct 19 17:52:26 argentium kernel: EIP:
0010:[try_to_swap_out+250/848]
Oct 19 17:52:26 argentium kernel: EFLAGS: 00010282
Oct 19 17:52:26 argentium kernel: eax: 001c ebx: 0100 ecx:
c12ea000 edx:
Oct 19 17:52:26 argentium kernel: esi: c11c6858 edi: 0001 ebp:
06af2045 esp: c12ebee4
Oct 19 17:52:26 argentium kernel: ds: 0018 es: 0018 ss: 0018
Oct 19 17:52:26 argentium kernel: Process kswapd (pid: 2,
stackpage=c12eb000)
Oct 19 17:52:26 argentium kernel: Stack: c01f42c5 c01f4484 0066
0809 0808e000 c6af0234 0808a000 0809
Oct 19 17:52:26 argentium kernel:c012bc03 c1314c60 c6a4b4a0
0808d000 c6af0234 0004 0808a000 c6a4b4a0
Oct 19 17:52:26 argentium kernel:c1314c60 0848a000
c6af3080 0809 0809 c6af3080 c012be10
Oct 19 17:52:26 argentium kernel: Call Trace: [tvecs+6653/33176]
[tvecs+7100/33176] [swap_out_vma+323/480] [swap_out+368/496]
[refill_inactive+272/544] [do_try_to_free_pages+153/192]
[kswapd+183/432]
Oct 19 17:52:26 argentium kernel:[kernel_thread+36/48]
Oct 19 17:52:26 argentium kernel: Code: 0f 0b 83 c4 0c 90 f7 c5 02 00
00 00 74 18 6a 68 68 84 44 1f
Oct 19 17:56:07 argentium kernel: SysRq: Emergency Sync
Oct 19 17:56:08 argentium kernel: Syncing device 03:06 ... OK
Oct 19 17:56:08 argentium kernel: Syncing device 03:07 ... OK
Oct 19 17:56:08 argentium kernel: Syncing device 03:01 ... OK
Oct 19 17:56:08 argentium kernel: Done.
Oct 19 17:56:11 argentium kernel: SysRq: Show State
Oct 19 17:56:11 argentium kernel:
Oct 19 17:56:11 argentium kernel: task PCstack pid
father child younger older
Oct 19 17:56:11 argentium kernel: init S C1229F2C 3076
1 0 740 (NOTLB)
Oct 19 17:56:11 argentium kernel:sig: 0
: X
Oct 19 17:56:11 argentium kernel: kswapdZ C021ED40 5940
2 1(L-TLB) 3
Oct 19 17:56:11 argentium kernel:sig: 0
: X
Oct 19 17:56:11 argentium kernel: kreclaimd S 0286 6648
3 1(L-TLB) 4 2
Oct 19 17:56:11 argentium kernel:sig: 0
: X
Oct 19 17:56:11 argentium kernel: kflushd S 5796
4 1(L-TLB) 5 3
Oct 19 17:56:11 argentium kernel:sig: 0
: X
Oct 19 17:56:11 argentium kernel: kupdate S C12E5FC4 6052
5 1(L-TLB) 6 4
Oct 19 17:56:11 argentium kernel:sig: 0
fff9 : X
Oct 19 17:56:11 argentium kernel: kreiserfsd S C132DFC0 5820
6 1(L-TLB) 15 5
Oct 19 17:56:11 argentium kernel:sig: 0
: X
...
FYI, mm/vmscan.c:
if (PageSwapCache(page)) {
entry.val = page->index;
swap_duplicate(entry);
if (pte_dirty(pte))
> BUG();
if (pte_write(pte))
BUG();
set_pte(page_table, swp_entry_to_pte(entry));
drop_pte:
UnlockPage(page);
mm->rss--;
-
Matt T. YourstMassachusetts Institute of Technology
[EMAIL PROTECTED] 617.225.7690
513 French House - 476 Memorial Drive - Cambridge, MA 02136
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.4.0-test10-pre4: kernel BUG at vmscan.c:102!
The following bug was just logged for 2.4.0-test10-pre4.
The machine was recompiling glibc (off a ReiserFS 3.6.18 filesystem)
and X was just running a screensaver at the time this happened. X was
locked up and I couldn't switch to a console, so I killed it with
Alt+SysRq. I was then able to get a task list with Alt+SysRq and cc1
was in the D state (along with kswapd in the Z state.) At this point I
synced and rebooted.
Oct 19 17:52:26 argentium kernel: kernel BUG at vmscan.c:102!
Oct 19 17:52:26 argentium kernel: invalid operand:
Oct 19 17:52:26 argentium kernel: CPU:0
Oct 19 17:52:26 argentium kernel: EIP:
0010:[try_to_swap_out+250/848]
Oct 19 17:52:26 argentium kernel: EFLAGS: 00010282
Oct 19 17:52:26 argentium kernel: eax: 001c ebx: 0100 ecx:
c12ea000 edx:
Oct 19 17:52:26 argentium kernel: esi: c11c6858 edi: 0001 ebp:
06af2045 esp: c12ebee4
Oct 19 17:52:26 argentium kernel: ds: 0018 es: 0018 ss: 0018
Oct 19 17:52:26 argentium kernel: Process kswapd (pid: 2,
stackpage=c12eb000)
Oct 19 17:52:26 argentium kernel: Stack: c01f42c5 c01f4484 0066
0809 0808e000 c6af0234 0808a000 0809
Oct 19 17:52:26 argentium kernel:c012bc03 c1314c60 c6a4b4a0
0808d000 c6af0234 0004 0808a000 c6a4b4a0
Oct 19 17:52:26 argentium kernel:c1314c60 0848a000
c6af3080 0809 0809 c6af3080 c012be10
Oct 19 17:52:26 argentium kernel: Call Trace: [tvecs+6653/33176]
[tvecs+7100/33176] [swap_out_vma+323/480] [swap_out+368/496]
[refill_inactive+272/544] [do_try_to_free_pages+153/192]
[kswapd+183/432]
Oct 19 17:52:26 argentium kernel:[kernel_thread+36/48]
Oct 19 17:52:26 argentium kernel: Code: 0f 0b 83 c4 0c 90 f7 c5 02 00
00 00 74 18 6a 68 68 84 44 1f
Oct 19 17:56:07 argentium kernel: SysRq: Emergency Sync
Oct 19 17:56:08 argentium kernel: Syncing device 03:06 ... OK
Oct 19 17:56:08 argentium kernel: Syncing device 03:07 ... OK
Oct 19 17:56:08 argentium kernel: Syncing device 03:01 ... OK
Oct 19 17:56:08 argentium kernel: Done.
Oct 19 17:56:11 argentium kernel: SysRq: Show State
Oct 19 17:56:11 argentium kernel:
Oct 19 17:56:11 argentium kernel: task PCstack pid
father child younger older
Oct 19 17:56:11 argentium kernel: init S C1229F2C 3076
1 0 740 (NOTLB)
Oct 19 17:56:11 argentium kernel:sig: 0
: X
Oct 19 17:56:11 argentium kernel: kswapdZ C021ED40 5940
2 1(L-TLB) 3
Oct 19 17:56:11 argentium kernel:sig: 0
: X
Oct 19 17:56:11 argentium kernel: kreclaimd S 0286 6648
3 1(L-TLB) 4 2
Oct 19 17:56:11 argentium kernel:sig: 0
: X
Oct 19 17:56:11 argentium kernel: kflushd S 5796
4 1(L-TLB) 5 3
Oct 19 17:56:11 argentium kernel:sig: 0
: X
Oct 19 17:56:11 argentium kernel: kupdate S C12E5FC4 6052
5 1(L-TLB) 6 4
Oct 19 17:56:11 argentium kernel:sig: 0
fff9 : X
Oct 19 17:56:11 argentium kernel: kreiserfsd S C132DFC0 5820
6 1(L-TLB) 15 5
Oct 19 17:56:11 argentium kernel:sig: 0
: X
...
FYI, mm/vmscan.c:
if (PageSwapCache(page)) {
entry.val = page-index;
swap_duplicate(entry);
if (pte_dirty(pte))
BUG();
if (pte_write(pte))
BUG();
set_pte(page_table, swp_entry_to_pte(entry));
drop_pte:
UnlockPage(page);
mm-rss--;
-
Matt T. YourstMassachusetts Institute of Technology
[EMAIL PROTECTED] 617.225.7690
513 French House - 476 Memorial Drive - Cambridge, MA 02136
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
> >I am working on a project that is going to find the current limit of >16-bits for device numbers to be a pain. While looking around in the >linux-kernel archive, ... > This is the whole reason Linux 2.4 uses devfs (device filesystem) - there is no need to use device numbers; you just register the name in the /dev/whatever namespace and it's done. (The kernel will assign a unique old-style 16-bit number for compatibility purposes as needed.) See linux/Documentation/filesystems/devfs/README for the full story. - Matt Yourst - Matt T. YourstMassachusetts Institute of Technology [EMAIL PROTECTED] 617.225.7690 513 French House - 476 Memorial Drive - Cambridge, MA 02136 - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
I am working on a project that is going to find the current limit of 16-bits for device numbers to be a pain. While looking around in the linux-kernel archive, ... This is the whole reason Linux 2.4 uses devfs (device filesystem) - there is no need to use device numbers; you just register the name in the /dev/whatever namespace and it's done. (The kernel will assign a unique old-style 16-bit number for compatibility purposes as needed.) See linux/Documentation/filesystems/devfs/README for the full story. - Matt Yourst - Matt T. YourstMassachusetts Institute of Technology [EMAIL PROTECTED] 617.225.7690 513 French House - 476 Memorial Drive - Cambridge, MA 02136 - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test7 doesn't boot on Fujitsu Lifebook 765DX
It looks like 2.4.0-test7 won't boot on a Fujitsu Lifebook 765DX. The kernel immediately hard reboots very early in the setup phase, before it even displays the Uncompressing Linux message (or so it looks.) The machine's relevant specs: Fujitsu Lifebook 765DX Pentium MMX 133 MHz 48 MB of RAM (up from the standard 32 MB) The kernel was compiled for a generic 586 (the actual CPU is a Pentium MMX 133) with gcc 2.95.2, with all CPU-specific extras disabled. NFS root support, initrd, romfs and ramfs were compiled into the bzImage; everything else was modular (and never loaded.) The boot loader was grub 0.5.96, with both the kernel and initrd loaded off a floppy. I even tried explicitly specifying mem=48M since I've heard the BIOS has bugs on some Fujitsu laptops. Note that the diskette boots perfectly on my Dell Inspiron and several other machines with at least a Pentium CPU, so it must be something with this specific machine. I have not tried 2.2.x series kernels, but since the machine is someone else's, I don't have unlimited access to experiment with it. Any ideas? Thanks. - Matt T. YourstMassachusetts Institute of Technology [EMAIL PROTECTED] 617.225.7690 513 French House - 476 Memorial Drive - Cambridge, MA 02136 - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
