Re: 2.6.37 and other things.
Hi Michael,
On Sun, 27 Feb 2011, Michael Tomkins wrote:
> Decided to compile the stable: 2.6.37.1 from kernel.org and it compiled
> straight out of a "make oldconfig ; make vmlinux modules
> modules_install" using Thorsten's 2.6.32 .config! Although it did take 3
> days on a quadra 650/605/605 cluster (so its mac only?).
Did you use gcc-4.4?
> Kernel and modules are here http://mich431.net/m68k/img.tar.gz, will be
> stripping them down a lot in the next compile.
I've also built some kernel binaries for 2.6.37.1 (using the etch-m68k gcc
4.1 cross-compiler) after playing with CPU optimisation flags.
I didn't tell the mailing list about them yet because I haven't been able
to test them (my powerbook seems to have developed some issues with its
CF-card to IDE to SCSI setup). I should have the hardware situation sorted
soon though.
Anyway, some untested kernel binaries may be found here if you want to
try them:
http://www.telegraphics.com.au/~fthain/mac68k-kernel-binaries/
> What apt packages do I need to do a "make deb-pkg", mine fails on
> hostenv each time. Thus the part built image (debian/tmp/ directory
> output).
>
> Finn, the RTC is picking up a time but the month is -1 out and muddled
> time zone (Q650), eg, got 8am 27 Jan 2011 when it was 9pm 26 Feb 2011. I
> have Aust EST set as tzdata, and sydney on the MacOS 7.5.
The +11 hours is the AEST offset from UTC, so part of the problem seems to
be that debian is misconfigured (it thinks the hardware clock is in UTC
but it is actually localtime. MacOS uses localtime so dual-booting means
you have to tell Linux about this).
The -1 month is a bit odd. It sounds like an off-by-one bug somewhere but
I've no idea where... Perhaps try
# strace -v hwclock --localtime --show
> This is very annoying, as every time the e2fsck fails on mount time of
> the disk, I have gotten around this by setting the date a few months
> forward on the Mac before starting.
If you are using extfs, try this
# tune2fs -i 0 /dev/sdXX
>
> Also there was a network error
Are you referring to this? (copied from your log file)
[ 369.800000] *** ADDRESS ERROR *** FORMAT=2
[ 369.810000] Current process id is 1451
[ 369.820000] BAD KERNEL TRAP: 00000000
[ 369.830000] Modules linked in: ipv6 evdev
[ 369.850000] PC: [<001e93ce>] __ip_route_output_key+0x2ec/0x936
[ 369.860000] SR: 2000 SP: 04b49dc0 a2: 0868e1b0
[ 369.870000] d0: 08734600 d1: 00000000 d2: 00000000 d3: 0021d800
[ 369.880000] d4: c0a801fe d5: 00000000 a0: 08734600 a1: 08734600
[ 369.890000] Process ntpdate (pid: 1451, task=0868e1b0)
[ 369.900000] Frame format=2 instr addr=001e7450
[ 369.910000] Stack from 04b49df8:
[ 369.910000] 04b49ee4 003292c4 00000000 00000000 00000035 efe9ec62 04b49ea8 001d712a
[ 369.930000] 0859a470 003292c4 00000002 00000001 00000000 c0a801fe c0a8016a 00000000
[ 369.960000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 369.990000] 00000000 180001fd 08513b40 00000011 0020acdc 003292c4 04b49ee4 04b49ea8
[ 370.010000] 00000010 04b49f08 00000000 efe97264 0000f371 efe9723c 00c09540 c02d8a18
[ 370.030000] c02d6000 04b49f90 0859a420 00000000 00000000 00000000 00000000 c0a801fe
[ 370.070000] Call Trace: [<001d712a>] dst_release+0x0/0x6e
[ 370.080000] [<0020acdc>] ip4_datagram_connect+0x210/0x27c
[ 370.090000] [<0000f371>] slog2+0x20d/0x8f0
[ 370.100000] [<001c1fd2>] sys_connect+0x8c/0xb6
[ 370.110000] [<00020035>] copy_process+0x53d/0xc1c
[ 370.120000] [<00007058>] do_page_fault+0xa8/0x21c
[ 370.130000] [<00007132>] do_page_fault+0x182/0x21c
[ 370.140000] [<00003b86>] buserr_c+0x1bc/0x632
[ 370.150000] [<0000f371>] slog2+0x20d/0x8f0
[ 370.160000] [<001c2f34>] sys_socketcall+0x2c0/0x2ee
[ 370.170000] [<0000268e>] syscall+0x8/0xc
[ 370.180000] [<0008c022>] link_path_walk+0x1c0/0xa86
> on the second boot but this did not repeat on the third boot, (the first
> boot had the disk error and refused to continue) Dmesg and klog here.
> http://mich431.net/m68k/kern.log.gz http://mich431.net/m68k/dmesg.1.gz
>
> And finally and easy way to freeze the kernel is to cat /var/log/*log
> over the network with a ssh connection, almost always freezes at 1-2
> pages for 5-10 seconds.
:( I'd hoped that this problem went away. I guess not. I will try to
reproduce the problem. Does it still happen continually and
intermittently or does it require the steps you describe?
Finn
>
> Now to work at a ramdisk :)
>
Reply to: