Electronics > Repair

Tektronix DPO 4104 kernel panic

(1/5) > >>

Hi all. First time post here. Please let me know if I should post to another forum/area.

I recently acquired a not-working DPO 4104. I know nothing of its history. It is in a splash-screen boot-loop. I managed to figure out where the serial port is, and captured the following log:

--- Quote ---... [normal stuff]
## Booting image at f0000000 ...
   Image Name:   Linux-2.4.20_mvl31-440ep_eval
   Image Type:   PowerPC Linux Multi-File Image (gzip compressed)
   Data Size:    1441010 Bytes =  1.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Image 0:  1033953 Bytes = 1009.7 kB
   Image 1:   407042 Bytes = 397.5 kB
   Verifying Checksum ... OK
   Uncompressing Multi-File Image ... OK
cmdline is console=ttyS0,9600 quiet bigphysarea=519 panic=2 root=/dev/mtdblock7 rw mem=131072k
   Loading Ramdisk to 07f2b000, end 07f8e602 ... OK
kernel BUG at page_alloc.c:104!
Oops: Exception in kernel mode, sig: 4
NIP: C0036248 XER: 00000000 LR: C0036248 SP: C01E8820 REGS: c01e8770 TRAP: 0700    Not tainted
MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DEAR: 00004000, ESR: 08000000
TASK = c01e6960[0] 'swapper' Last syscall: 0
[... goes into reboot loop]

--- End quote ---

The error condition is flagged in the kernel when pages are being freed, so this looks like completely bogus page, or a double-free.

--- Quote ---        if (!VALID_PAGE(page))

--- End quote ---

This is repeats exactly the same way everytime.

My initial suspicion is that the scope was improperly updated, or the update failed for some reason and the scope is effectively bricked.

There could be a hardware failure I guess (bad DRAM cell(s) since this is happening with a RAM disk?).

Is there anything that can be done at this point? - either more debug or some sort of flash of a new image? A traditional "firmware update" is not possible since the machine cannot boot to any level of functionality.

Thanks for any ideas!

By the boot log it doesn't look like it gets to the firmware update step but you might want to try the "FORCE" firmware method in the manual just to be thorough. Ramdisk load is the last line which is curious. You could be right about a bad flash but I'm afraid it could also be bad RAM that it tries to access after the initial copy.

I wish I had a copy of the flash chip for you to try programming but I haven't been able to find one for my MSO4104. On mine it is a 4M flash chip at U822 but contains more than just the bootloader or it would be a simple task. I'm interested to see if this thread gains any traction because I am in a similar situation. Please update with anything you learn as it would help me and others in the future.

I got to thinking about this kernel panic... It is unlikely that the firmware is borked - if that were the case, I doubt that it would even get out of the gate. Now the kernel panic in this case is the result of the kernel finding a free page (i.e., the valid bit in the PTE is clear) where it thinks it should have a valid page. Assuming that the kernel is fine (the scope did work once after all), that means that when the kernel wrote the PTE to set the page base along with the valid and R/W/X bits, the valid bit (and maybe others as well) did not get set. So bad DDR DRAM.

So I bought four new DRAMs ($2.50 each at mouser). The plan was to desolder and replace each dram in turn, verifying that the scope didn't break worse after each one.

Well, I got lucky. The first DRAM I replaced fixed the problem, all the POST passed and the scope is functional!

Now all I need to do is find a replacement map/zoom button, get some probes, and get it calibrated...

Wow that's great, thanks for posting the update. Always feels good to fix something like that.

Great job! Thank you for updating the thread.

Care to speculate on the bootloader freezing at the F in the FLASH: 64MB line? I haven't found the solution yet.


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version