Announcement

Collapse
No announcement yet.

Bad News: Could Not Boot weaknees_lba_boot_cd - Good News: Hinsdale Worked

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Bad News: Could Not Boot weaknees_lba_boot_cd - Good News: Hinsdale Worked

    First, I want to compliment you on the interactive TiVo Upgrade. It's well written. I just finished upgrading a 649080 DT to a 300 GB Seagate DB35 drive and by all I can tell thus far it's working very well. The problem was weaknees_lba_boot_cd.iso, not the interactive instructions (which were informative, even though I ultimately had to do the Hinsdale method).

    The weaknees ISO burned just fine and would start to boot, and then dump out completely (no bash) with a "panic" error. The screen scrolled past so fast with messages it was impossible to read them all. It appeared that Linux had problems finding or perhaps using the IDE interrupts.

    After several attempts, including trying to force using bios IRQs (with a command switch added at the boot prompt), I gave up, downloaded the LBA48 ISO for use with the Hinsdale method, and burned it. Got the same panic error - but noted that there was an option to boot with no DMA. That finally worked and Linux booted (I presume drive access was now in PIO Block Mode instead of (U)DMA). Following the Hinsdale instructions I was able to completely copy the old 80 GB drive to the new 300 GB drive, including preserving all the setup options, season passes, and recordings. Took a l-o-n-g time -- about 12 hours -- presumably because UDMA was disabled -- PIO Block Mode *is* quite slow with read/write compared to UDMA. My normal configuration of a machine is hard drive on primary EIDE channel and optical drive on secondary EIDE channel. I pulled the WinXP drive completely and put the TiVo drives on the primary EIDE channel as master and slave (leaving the CD/DVD on the secondary as master). Had to translate the MFSTools command line(s) to the hda and hdb for the two TiVo drives, but that wasn't a problem.

    Unfortunately I could not boot the weaknees lba ISO with DMA switched off. The motherboard is a Soyo K8USA DRAGON Ultra Black Label, with socket 754 AMD Athlon 64 3400+. Supporting chipset (Northbridge/Southbridge) are an AMD 8151 (aka ALi/ULi M1687) and ALi/ULi M1563. This is not an ancient motherboard (e.g. resurrected Socket 7 box), although it's one of the earlier Socket 754 board architectures for the Athlon 64, but am wondering if that was part of the problem. However, that Northbridge/Southbridge is fully supported by at least SuSe Linux at least from somewhere around v9.x onward (haven't checked Ubuntu or Red Hat) which leaves me a little puzzled.

    After completing the Hinsdale method with DMA turned off, it also occurred to me that motherboards in this class support APIC - which allows newer O/S to number interrupts beyond 16 in the O/S layer (even though they're still shared at the hardware layer) - and that was turned on in the BIOS (Win9x/ME doesn't support it, don't know about Win2k, but WinXP does). I'm not savvy enough about Linux to know if it supports APIC.

    Searched the fora here and although I found a reboot loop problem, I didn't see any mention of a kernel "panic error" that failed to boot, completely dumping out of Linux. At some point when you do other revisions, you might consider adding a switch to turn DMA off with the Weaknees bootable CD. It's what saved me with the bootable CD I burned to use the Hinsdale method.

    Any clues as to what I might have done differently to boot the Weaknees CD would be most welcome. We have three TiVos. The other two are older, single tuner 240080 models and know at some point I will upgrade at least one of them to a bigger drive - one of which is beginning to show early signs of drive failure - and would like to use the Weaknees bootable CD if possible - most hopefully with UDMA support to make file transfer much faster.

    Postscript about the 649080 DT TiVo:
    The drive I found inside was a Western Digital Caviar SE, model WD0800BB which is a general purpose desktop computer EIDE drive. Within the WD Caviar SE line, the "BB" models have the smaller cache (the "JB" have the larger cache).

    Thanks,
    -- John Lind

  • #2
    Thanks for the details.

    We have heard over the years about each disk and CD not working in certain situations with certain hardware. To be honest, as these are free utilities with free downloads, we just haven't been able to purchase other types of test equipment to troubleshoot these issues. We do update our CD regularly (most recently to work with SATA drives) but we really don't find other test PCs. We use pretty mainstream Dells here, and if it works for us on all of our machines, it generally works on 98% of PCs out there.
    Been here a long time . . .

    Comment


    • #3
      Originally posted by WK-Michael View Post
      Thanks for the details.

      We have heard over the years about each disk and CD not working in certain situations with certain hardware. To be honest, as these are free utilities with free downloads, we just haven't been able to purchase other types of test equipment to troubleshoot these issues. We do update our CD regularly (most recently to work with SATA drives) but we really don't find other test PCs. We use pretty mainstream Dells here, and if it works for us on all of our machines, it generally works on 98% of PCs out there.
      That's why I suggested a command line "switch" option to turn (U)DMA drive access off when booting the CD -- defaulting to (U)DMA "on" with a message about turning it off using the switch if boot problems are encountered. I'm thinking that's most likely an easier thing to implement -- a one-time mod -- than trying to chase the moving target of motherboard Northbridge/Southbridge chipsets. It would provide a "work around" for any mobo chipset past, present or future, that has a fatal error problem with (U)DMA drive access implemention in the CD's Linux.

      Further note:
      The ULi M1687/M1563 chipset isn't used much any more for AMD-64 socket 754 boards, having been overtaken by the newer nForce and Via chipsets two to three years ago. In the world of AMD-64 socket 754 and socket 939 mobos, nForce and Via chipsets are the most common now, but remain a moving target (just like Intel chipsets for Intel micros). I realize the headache this can cause.

      Thanks,
      -- John

      Comment

      Working...
      X