Kernel compiling woes part -1 --- or bug in tar?

[bitpusher]

I need to compile the kernel (because of more than 4 UARTS in my machine and to use UIO for proprietary hardware) in TinyCore 5.0.1.

However I already found some traps before I even could type make.

Found the how-to at http://wiki.tinycorelinux.net/wiki:custom_kernel, but it dose not really describe the files found at http://tinycorelinux.net/5.x/x86/release/src/kernel/ - "patched" seems quite obvious, but maybe the how-to could benefit from a rework?

Next I downloaded linux-3.8.13-patched.txz and tried to unpack with tar - which unpacks some files but stops with
"short read"  - in spite of the fact that the txz is intact.
Tried it with tar.tcz (1.26) from the apps installed - stopped at a different point with the same error message...
Tried it with linux-3.12.2.tar.xz from kernel.org - same problem.

When I finally tried to unpack linux-3.12.2.tar.xz with xz it seemed to work - at least it finished without error.
However when I used xz on linux-3.8.13-patched.txz it left me with a tar-file. On this tar-file the tar from TinyCore seemed to work OK then.

Am I overlooking the obvious or doing something wrong here?
BTW: I found some older discussions on a bug of the xz embedded in tiny core causing a "short read" error - on the other hand xz seemed to finally work for me?

[coreplayer2]

try

tar xf linux-3.8.13-patched.txz

[gerald_clark]

No need to compile.
Use the boot code 8250.nr_uarts=X where X is the number of uarts you have.

[bitpusher]

try

tar xf linux-3.8.13-patched.txz

As to be expected, I can not reproduce the "short read" today!

However I am pretty sure I used tar xvf linux-3.8.13-patched.txz yesterday.

But when I tried again today:

tc@box:~/dokument/gcc$ tar xf linux-3.8.13-patched.txz
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
tc@box:~/dokument/gcc$

Different complain from tar, but does not succeed either.

Now if I do the same in a "real" directory on sda1:

tc@box:/mnt/sda1/dokument/gcc$ tar xf linux-3.8.13-patched.tar
tc@box:/mnt/sda1/dokument/gcc$

So the problem seems to be filesystem related?

[bitpusher]

No need to compile.
Use the boot code 8250.nr_uarts=X where X is the number of uarts you have.

I have already tried
8250.nr_uarts=5.
While this gives me /dev/ttyS4 in the filesystem:

tc@box:~$ ls /dev/ttyS* -l
crw-rw---- 1 root staff 4, 64 Dez  3 08:31 /dev/ttyS0
crw-rw---- 1 root staff 4, 65 Dez  3 08:31 /dev/ttyS1
crw-rw---- 1 root staff 4, 66 Dez  3 08:31 /dev/ttyS2
crw-rw---- 1 root staff 4, 67 Dez  3 08:31 /dev/ttyS3
crw-rw---- 1 root staff 4, 68 Dez  3 08:31 /dev/ttyS4

tc@box:~$ setserial -g /dev/ttyS*
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: 16550A, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: unknown, Port: 0x0000, IRQ: 0

The problems start when I try to configure ttyS4.
Setting the address and IRQ works OK, but the UART is not auto-detected:

tc@box:~$ setserial -g /dev/ttyS*
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: 16550A, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: unknown, Port: 0x03a8, IRQ: 2

I could live with setting the UART-type manually, but as soon as I set it with setserial I get:

tc@box:~$ setserial -g /dev/ttyS*
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: 16550A, Port: 0x03e8, IRQ: 10
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 11
/dev/ttyS4: Device or resource busy


Searching the net gave me the impression that at some point CONFIG_SERIAL_8250_RUNTIME_UARTS was set to 4 at some point, while it was 32 before.
From what I understood I will have to change CONFIG_SERIAL_8250_RUNTIME_UARTS to make more than 4 UARTS work.

[curaga]

CONFIG_SERIAL_8250_RUNTIME_UARTS kernel help:

Set this to the maximum number of serial ports you want the kernel to register at boot time. This can be overridden with the module parameter "nr_uarts", or boot-time parameter 8250.nr_uarts

[bitpusher]

CONFIG_SERIAL_8250_RUNTIME_UARTS kernel help:

Set this to the maximum number of serial ports you want the kernel to register at boot time. This can be overridden with the module parameter "nr_uarts", or boot-time parameter 8250.nr_uarts

I wish I could agree with you, but from the same file:

config SERIAL_8250_NR_UARTS
   int "Maximum number of 8250/16550 serial ports"
   depends on SERIAL_8250
   default "4"
   help
     Set this to the number of serial ports you want the driver
     to support.  This includes any ports discovered via ACPI or
     PCI enumeration and any ports that may be added at run-time
     via hot-plug, or any ISA multi-port serial cards.

And there is no overriding boot-time paramter mentioned.
Also this matches my observation that I can get all 5 physical UARTS to work when I assign any of them to ttyS0 ... ttyS3 - but can't get any physical UART to work as ttyS4.

[bitpusher]

OK, after changing to a "real" directory (see above) I advanced to step 6 of http://wiki.tinycorelinux.net/wiki:custom_kernel.

However this is what I get:

tc@box:/mnt/sda1/dokument/gcc/linux-3.8.13-patched$ make oldconfig
  HOSTCC  scripts/basic/fixdep
In file included from /usr/include/bits/posix1_lim.h:157:0,
                 from /usr/include/limits.h:145,
                 from /tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/include-fixed/limits.h:169,
                 from /tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/include-fixed/syslimits.h:7,
                 from /tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/include-fixed/limits.h:34,
                 from scripts/basic/fixdep.c:114:
/usr/include/bits/local_lim.h:39:26: fatal error: linux/limits.h: Datei oder Verzeichnis nicht gefunden
compilation terminated.
make[1]: *** [scripts/basic/fixdep] Error 1
make: *** [scripts_basic] Error 2


Thus make is looking for linux/limits.h but can't find it.

There are two limits.h in the source tree:

tc@box:/mnt/sda1/dokument/gcc/linux-3.8.13-patched$ find -iname limits.h
./include/uapi/linux/limits.h
./arch/arm/include/asm/limits.h

but obviously not in the directory where make is looking for it?

[curaga]

$ grep SERIAL_8250_NR_UARTS config-3.8.13-tinycore
CONFIG_SERIAL_8250_NR_UARTS=32

[tinypoodle]

try

tar xf linux-3.8.13-patched.txz

As to be expected, I can not reproduce the "short read" today!

However I am pretty sure I used tar xvf linux-3.8.13-patched.txz yesterday.

But when I tried again today:

tc@box:~/dokument/gcc$ tar xf linux-3.8.13-patched.txz
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
tc@box:~/dokument/gcc$

Different complain from tar, but does not succeed either.

Now if I do the same in a "real" directory on sda1:

tc@box:/mnt/sda1/dokument/gcc$ tar xf linux-3.8.13-patched.tar
tc@box:/mnt/sda1/dokument/gcc$

So the problem seems to be filesystem related?

Out of space?

[bitpusher]

try

tar xf linux-3.8.13-patched.txz

As to be expected, I can not reproduce the "short read" today!

However I am pretty sure I used tar xvf linux-3.8.13-patched.txz yesterday.

But when I tried again today:

tc@box:~/dokument/gcc$ tar xf linux-3.8.13-patched.txz
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
tc@box:~/dokument/gcc$

Different complain from tar, but does not succeed either.

Now if I do the same in a "real" directory on sda1:

tc@box:/mnt/sda1/dokument/gcc$ tar xf linux-3.8.13-patched.tar
tc@box:/mnt/sda1/dokument/gcc$

So the problem seems to be filesystem related?

Out of space?

I thought of this too after it worked with the "real" directory, but it seems like there still is some space left:

tc@box:~/dokument/gcc$ df -i
Filesystem             Inodes IUsed IFree IUse% Mounted on
rootfs                    54K   48K  6,4K   89% /

[tinypoodle]

"df -i" shows inodes, not space.

[bitpusher]

"df -i" shows inodes, not space.

Ah, yes, exactly. Note to self: Read what you pasted before posting.

tc@box:~/dokument/gcc$ df
Filesystem              Size  Used Avail Use% Mounted on
rootfs                  394M  297M   97M  76% /

tc@box:~/dokument/gcc$ df -i
Filesystem             Inodes IUsed IFree IUse% Mounted on
rootfs                    54K   48K  6,4K   89% /

[tinypoodle]

tmpfs is also limited by currently free shared mem (RAM + swapspace).

[bmarkus]

Just checked, my kernel build dir including modules after compilation is 1.8 GByte. If you do not have 2 GB free file system space, no way to do that.