PDA

View Full Version : kernel panic in my own kernel



EvilJack
09-20-2004, 07:32 PM
My new lba48 2.2.4-TiVo3.0 kernel has been crapping
out on me. It says up for several hours and then:

Unable to handle kernel paging request at virtual address 00001000, epc == 00001000, ra == 00001000
Oops in fault.c:do_page_fault, line 172:
$0 : 00000000 9001d400 00000000 00000002
$4 : 820bac20 820bac20 0000540d 7fff7820
$8 : 00000000 2aca211c 8005a920 00000003
$12: 00000000 00001000 00000000 7fff78d0
$16: 820bac20 8005a9bc 00000802 00000000
$20: ffffffff 00000010 00000000 00000001
$24: 00000000 2aca2108
$28: 8051e000 8051ff18 00000001 00001000
epc : 00001000
Status: 9001d403
Cause : 00000008
Process genkey (pid: 229, stackpage=8051e000)
Stack: 7fff7870 00001000 100010f8 00000001 00000001 8001c904 1000ef0c 100100cc
1000da0c 00000000 ffffffff 00000000 00000000 9001d400 00000fd6 fffffffe
00000008 0000540d 7fff7820 00000001 0000d400 00000010 00000000 00001000
00000000 00001000 00000000 7fff78d0 ffffffff 00001000 100010f8 00000001
00000001 00000010 00000000 00000001 00000000 2aca2108 00000001 00000000
2ad63e90 ...
Trace: (none)
Code: (Bad address in epc)

Kernel panic: Die called

--------------------------------------------------------------------

Can anyone read anything from this?

what's 'genkey'?

I get a similar crash and burn if I remove my usb
ethernet adapter... it's says:
Process khubd (pid: 111, stackpage=82964000)
instead....

Does anyone have any ideas?

Thanks - jack

EvilJack
09-30-2004, 09:37 AM
I've rebuilt using the SAME source but a GCC-3.0 cross compiler and
so far, no kernel panics.

I did notice that I swap file was not loading and I had to run mkswap
on it. I don't know if I was having swap problems before when my
kernel was crashing or if the swap stuff was messed up later.

jack

Gromit
10-03-2004, 05:59 AM
... I did notice that I swap file was not loading and I had to run mkswap on it. I don't know if I was having swap problems before when my kernel was crashing or if the swap stuff was messed up later. ...I did the mfstools + tivopart trick (http://www.dealdatabase.com/forum/showthread.php?t=25219) to enlarge hda1 and change swap to 128MB. Since tivopart doesn't attempt to restore the swap partition after altering the partitions, I had to do that myself. I did a "mkswap -v1" while my drive was on my PC (Fedora Linux). Since then, my TiVo (SD-DVR40) hasn't had a working swap.

Just now I tried a mkswap on the TiVo. It doesn't have the -v option (always uses -v0 "old style" format). A "swapon -a" successfully activated my swap :).

So Jack, how did you do the latest mkswap that worked? What had you done to your swap before that (for example, do a mfstool restore with a big -s, or use tivopart?)

Todd Miller has an updated mkswap that accepts -v1 (see this page (http://www.courtesan.com/tivo/bigdisk.html) for more info), but a v1 ("new style") swapfile won't work on the TiVo unless the kernel and swapon are updated to deal with the v1 format. Todd has a kernel patch for that too. I thought about including it in the LBA48 kernel I'm working on, but think I'll hold off -- if TiVo sneaks in a software update that I don't stop, that will be one more thing that could lead to "bad things" happening.

(I've had some interesting glitches :eek: trying to get my LBA48 kernel working, but I'll post more about that elsewhere, once I get it working)

EvilJack
10-03-2004, 11:02 AM
I took a different approach and I don't recall what I did
exactly. ;( I think I have old-mans-desease....

I took the new 'scripts are bad' approach so I did my own
tivopart... I did something like:
mfsrestore -s2048 -r4 -lzi /backup.mfs /dev/hdc
which did NOT expand MFS to fill my drive.

I tried mfsrestore -s2048 -r4 -xzpi /backup.mfs /dev/hdc
several tries and it would not work. It always hung up at
the end.... so... I got:
mfsrestore -s2048 -r4 -lzi /backup.mfs /dev/hdc
to work.

Next, I mounted and tar'd up /dev/hdc7 ( root file system )
so I could restore it later.

Next I used pdisk to shrink /dev/hdc8 ( swap )
to 127Meg and I expanded /dev/hdc7 to 2G.

Then I formated the new, larger /dev/hdc7 as an
ext2 filesystem. I then untarred my saved filesystem
to the newly formated partion.

I think that I might have run mkswap but maybe not....
I don't recall....

I used pdisk to add the two needed MFS partitions
in /dev/hdc14 and /dev/hdc15 and then I used
mfsadd to activate the new partions.

I'd like to figure out how to use 4 ( or 2 ) MFS Patitions
instead of 6, but I don't now how to merge/expand
MFS partions and not loose the data ( menus, options,
etc )

After the disk was prepared, I did the killhdinitrd stuff
on the kernel and I set up my monte stuff and
rc.sysinit.author stuff.

When I booted, everything was fine.... I was doing
something with tivoweb and noticed I didn't have any
swap. I ran mkswap on the tivo and then activated it.

So far I have:
Uptime 3d 15h 43m 51s
====================================
Space Summary
Total Space - 235393 MB 100.0% 239:16:44
Total Used 142 212418 MB 90.2% 214:06:35
Total Free - 22975 MB 9.8% 23:21:15
====================================

No problems rebooting ( once I started restarting tivoweb
every 24 hours ) or any MFS corruption problems. I've
got about 140 shows recorded and the menu response
is pretty poor on some menus.

My tivo hasn't gone much past 214 hours... it is
erasing shows rather than using the last 23 hours....
I don't know why exactly.... I've tried to tell tivo not
to delete any shows, but a few are still out there and
I think they are getting deleted as the new shows
are getting recorded... I'm goint to try tell what ever
is left to not delete and see if I can get that last 24
hours recorded today....

If you have the 2.4.4 kernel and have lba48 problems,
let me know. We can compare notes.

jack

alldeadhomiez
10-03-2004, 11:18 AM
I did the mfstools + tivopart trick (http://www.dealdatabase.com/forum/showthread.php?t=25219) to enlarge hda1 and change swap to 128MB. Since tivopart doesn't attempt to restore the swap partition after altering the partitions, I had to do that myself. I did a "mkswap -v1" while my drive was on my PC (Fedora Linux). Since then, my TiVo (SD-DVR40) hasn't had a working swap.

Interesting - I had not even noticed the byte order problem, and have been using "mkswap -v0" on the PC side in my imaging script for quite some time. However, I also had this in my startup scripts on the TiVo:


swapon /dev/hda8 || ( mkswap /dev/hda8 ; swapon /dev/hda8 )

which defaults to -v1 with the Debian mkswap I've been using. So things were eventually set up correctly before the TiVo software booted for the first time.

Since I no longer run a 2.4.4-based software version, I don't know if it properly handled the larger swap space I allocated.

EvilJack
10-03-2004, 11:21 AM
Since I no longer run a 2.4.4-based software version, I don't know if it properly handled the larger swap space I allocated.

What kernel ( and what Tivo ) do you run? I have a RID
tivo, so I know I can't go to Tivo 4.0 ( not 100% sure
why... but I know it doesn't work at present ) but I would
like to get a 2.4.18 or 2.4.20 kernel working with my
3.1.1c tivo unit.....

jack

alldeadhomiez
10-03-2004, 12:28 PM
What kernel ( and what Tivo ) do you run? I have a RID
tivo, so I know I can't go to Tivo 4.0 ( not 100% sure
why... but I know it doesn't work at present ) but I would
like to get a 2.4.18 or 2.4.20 kernel working with my
3.1.1c tivo unit.....

Running 3.1.1c with a kernel that is not 2.4.4 is non-trivial AFAICT, but you can run 3.1.5 or 3.1.5d (which ship with 2.4.20) on your unit.

EvilJack
10-03-2004, 12:41 PM
Running 3.1.1c with a kernel that is not 2.4.4 is non-trivial AFAICT, but you can run 3.1.5 or 3.1.5d (which ship with 2.4.20) on your unit.


any hints to getting 3.1.5d to run on my RID DVR40 box?
I have these files:
-rw-r--r-- 1 root root 20991 Sep 20 04:07 GZetc.cpio
-rw-r--r-- 1 root root 859953 Sep 20 04:07 GZbin.cpio
-rw-r--r-- 1 root root 1205242 Sep 20 04:07 GZkernel.cpio
-rw-r--r-- 1 root root 36993 Sep 20 04:08 GZprom.cpio
-rw-r--r-- 1 root root 2025409 Sep 20 04:08 GZlib.cpio
-rw-r--r-- 1 root root 348307 Sep 20 04:08 GZsbin.cpio
-rw-r--r-- 1 root root 5964457 Sep 20 04:08 GZtvbin.cpio
-rw-r--r-- 1 root root 696247 Sep 20 04:08 GZtvlib.cpio
-rw-r--r-- 1 root root 87552 Sep 20 04:08 utils.cpio

which I from from the MFS file system before they went
away. These were in the swSytem MFS directory. I have
tried to put these back into the MFS file system so I can do
that swInstall.tcl thing.... but I can't dbload them in so that
they show up as new software.

I've looked at the swInstall.tcl stuff and tried to
manually untar/cpio the files and install them that
way and it mostly worked until I rebooted and the
MFS file system seemed to get pretty trashed.

do I need something other than those 9 files above
to get the MFS file system to upgrade?

Any help would be appreicated.

Thanks - jack

alldeadhomiez
10-03-2004, 01:34 PM
any hints to getting 3.1.5d to run on my RID DVR40 box?
I have these files:
-rw-r--r-- 1 root root 20991 Sep 20 04:07 GZetc.cpio
-rw-r--r-- 1 root root 859953 Sep 20 04:07 GZbin.cpio
-rw-r--r-- 1 root root 1205242 Sep 20 04:07 GZkernel.cpio
-rw-r--r-- 1 root root 36993 Sep 20 04:08 GZprom.cpio
-rw-r--r-- 1 root root 2025409 Sep 20 04:08 GZlib.cpio
-rw-r--r-- 1 root root 348307 Sep 20 04:08 GZsbin.cpio
-rw-r--r-- 1 root root 5964457 Sep 20 04:08 GZtvbin.cpio
-rw-r--r-- 1 root root 696247 Sep 20 04:08 GZtvlib.cpio
-rw-r--r-- 1 root root 87552 Sep 20 04:08 utils.cpio

If you wrap those files in a simple MFS object, then create a slice out of them, you can dbload them and they will again show up in /SwModule .


do I need something other than those 9 files above
to get the MFS file system to upgrade?

You need the SwSystem object and its dependencies (mostly contained in the swsystem slice). Extracting that from an image is not easy.

Gromit
10-03-2004, 03:07 PM
(I did a "mkswap -v1" in Fedora on my PC, and after that point my Tivo didn't use the swap)


Interesting - I had not even noticed the byte order problem, ...It may just be due to my sleep deprivation, but were you suggesting that my using mkswap in Fedora ran into the byte order problem? Or just that my post made you notice the byte order issue also applies to mkswap? I was under the impression that my Tivo (S2 DTV combo) uses the same byte order as my PC -- only S1 boxes have the reversed byte order. Is that accurate?


...and have been using "mkswap -v0" on the PC side in my imaging script for quite some time. However, I also had this in my startup scripts on the TiVo:

[if 1st swapon fails then do a plain "mkswap" and another swapon]
which defaults to -v1 with the Debian mkswap I've been using. So things were eventually set up correctly before the TiVo software booted for the first time.I think your imaging script's -v0 swap was always accepted by your TiVo, so the swapon failure case in your startup script never got called (neat trick, though). If you think your TiVo ever really did run with a v1 swapfile while still using a 2.4.4 kernel, that would appear to be contrary to what Todd says (on his "big disk" page (http://www.courtesan.com/tivo/bigdisk.html)):
A note about version 1 swap partitions

The new-style swap header, which is necessary to utilize a swap partition larger than 128MiB, will not be recognized by the stock TiVo kernel. This is not a fatal problem (a TiVo will boot up just fine without a swap partition) but on a stand-alone TiVo with only 16MiB of memory things are pretty cramped without swap (and the indexer will be unable to run).

alldeadhomiez
10-03-2004, 05:38 PM
(I did a "mkswap -v1" in Fedora on my PC, and after that point my Tivo didn't use the swap)

It may just be due to my sleep deprivation, but were you suggesting that my using mkswap in Fedora ran into the byte order problem? Or just that my post made you notice the byte order issue also applies to mkswap? I was under the impression that my Tivo (S2 DTV combo) uses the same byte order as my PC -- only S1 boxes have the reversed byte order. Is that accurate?

I never noticed a byte order issue at all.

I believe he was referring to structs in the swap signature which are potentially written out little endian on an Intel PC, but read as big endian on the TiVo. I haven't checked to see if that's actually happening.

Series1 byteswapping on the PC needs to happen at a lower level so that you can still mount the partitions. I don't think it's related.


I think your imaging script's -v0 swap was always accepted by your TiVo, so the swapon failure case in your startup script never got called (neat trick, though). If you think your TiVo ever really did run with a v1 swapfile while still using a 2.4.4 kernel, that would appear to be contrary to what Todd says (on his "big disk" page (http://www.courtesan.com/tivo/bigdisk.html)):

Well, he might have been referring to the ancient 2.1.24 kernel used on the Series1, which won't use v1 swap space.

I'll update my scripts to use -v1 on the PC and see if the swap space is usable on new images.