kernel panic with iomega hdd 250 ext3

Help
2004-06-02
2004-09-16
  • Nobody/Anonymous

    Borrowed an iomega hdd250 with a single ext3 partition, to use via firewire (from an iBook 900MHz). Using 1.2 of the ext2/3 driver, I found the following oddities, apparently due to the large partition size:

    - even if the partition had been unmounted correctly, it would refuse to mount it without a full fschk -- taking over 1hr. seemed to ignore that it was ext3. Boxes running linux (PPC and i368) would mount it immediately -- although sometimes could see it not "clean" and use the journal.

    - the HD had ~120GB in use, and I was capturing video -- large clips totalling about 30GB more. After capturing 8GB, any write to the FS would stall forever. Nothing showed up in the logs, but access to the destination directory was locked (`ls -la` would block on the stalled write operation).

    - it is possible that writes were just too slow -- and seemed stalled. In practice, if the write operation was cancelled, after a few minutes the operation would "complete", and the drive was usable again. However, we lost hope of the write operations completing, even with the smallest files we were using (3MB)

    - reading earlier files was fast. Reading the last file that had been written successfully was extremely slow, or would stall.

      - reading/writing was tested using rsync and cp. Logs did not show anything interesting at all. top didn't show much activity from the kernel; I assume it was just blocking.

      - the fs was perfectly operational from linux boxes-- we removed the files that seemed to be "corrupt", but it didn't make much of a difference

    - I remounted the drive over USB 1.1. Read operations were ok, but trying to write new files resulted in a kernel panic. Panic log follows: 

    [martin@est252-254:~]$ cat /Library/Logs/panic.log
    Wed Jun  2 14:23:04 2004

    panic(cpu 0): ext2_cmap: allocation requested inside a block (possible filesystem corruption): qbmask=4095, inode=16924685, offset=32634368, blkoff=1536
    Latest stack backtrace for cpu 0:
          Backtrace:
             0x0008391C 0x00083E00 0x0001EDA4 0x1DF3E59C 0x000B82BC 0x000BC100 0x000BBDC4 0x000BBBF0
             0x1DF3928C 0x000CDB88 0x00209F38 0x0020A030 0x00244A94 0x00094400 0x00090009
          Kernel loadable modules in backtrace (with dependencies):
             net.sourceforge.ext2fs.fs.ext2(1.2)@0x1df2b000
    Proceeding back via exception chain:
       Exception state (sv=0x1D605280)
          PC=0x9001040C; MSR=0x0000F030; DAR=0xF00BFEF4; DSISR=0x42000000; LR=0x00005210; R1=0xBFFFE9C0; XCP=0x00000030 (0xC00 - System call)

    Kernel version:
    Darwin Kernel Version 7.4.0:
    Wed May 12 16:58:24 PDT 2004; root:xnu/xnu-517.7.7.obj~7/RELEASE_PPC

    *********

    Last but not least, this all happened during DebConf4, in Porto Alegre, Brazil, and many, many Debian developers were here chuckling at my woes ;)

     
    • Brian Bergstrand

      That kp is most likely the result of a bad/not full-spec USB interface on the enclosure. There are several threads in this forum that document USB problems with OS X and devices that are not fully spec-compliant. There was also a bug opened about the same panic that turned out to be -- surprise a USB problem (#926208).

      As for the other problems, this almost sounds like a hardware problem too. But OS X does not seem to be as finckey about Firewire devices not conforming to spec.

      What were the sizes of the indivual video clips? Were you doing multiple streams at once? Was the capture camera also on the Firewire bus?

      Can you capture to the internal drive and then try cp'ing the file. I've tested files up to 4.5GB, and haven't seen a problem.

      I have an 80GB drive here with a 50GB ext2 partition. I'll try doing some capturing with my iSight to see if I can reproduce the problem.

      Any more info. you have would be helpful.

      Finally, journaling is NOT supported, and most likely never will be. Ext3 is backward compatilbe with Ext2, but you just don't get journaling.

      Thanks.

       
    • Nobody/Anonymous

      Brian,

      thanks for the reply! A bit more info...

      - The camera was also on the FW bus during the capture.

      - Files range from a couple MB to 1.5GB.

      - Using cp and rsync triggered the problem as well -- with and without the camera on the FW bus.

      - Only one stream at a time, no other operation on the HD while capturing.

      I don't think it has anything to do with streaming or with the camera itself. It really seems a problem at the fs or protocol level. I could successfully write up to ~130MB of the drive. Anything past that point would block infinitely.

      cheers,

      martin langhoff

       
      • Brian Bergstrand

        Hmmm, is it any file over ~130MB, or just the video captures? I've never had a problem, and so far you're the first to report one. It could be an issue with the drive size. Is it possible to reformat the drive and do the capturing on say a 50GB partition. If it works, then there's probably an issue with the big fs size. Unfortunately, I don't have a drive that big.

        Also, before reformatting could you remove the drive from the external enclosure and plug it directly onto the IDE bus and run your tests?  I just want to eliminate as much hardware as possible. Especially since both devices are on the same bus. I know the current G5's suffer from some FW problems, and I've heard that some older G4's do as well.

        Thanks.

         
    • martin langhoff

      martin langhoff - 2004-06-08

      Oops, sorry. I meant over 130GB (not MB) occupied on the drive (out of 250GB). Past a certain point, any file, regardless of size, would never complete the write.

      I will get my hands on the drive again in a few days. Unfortunately, it isn't mine, so repartitioning and case disassembly aren't likely.

      I'll keep you posted.

      martin

       
    • martin langhoff

      martin langhoff - 2004-06-16

      I've managed to get my hands on the drive and:

      - Using a knoppix CD to boot the mac under linux (2.4.x), the HD works perfectly.

      - Under OSX again, formatting and using the drive as HFS+ works perfectly.

      I will keep testing, and see if I can get a repro. Unfortunately it is very time consuming because the extension forces a fsck every bloody time.

      cheers,

      martin

       
      • Brian Bergstrand

        Like I said I don't have that big of a drive here. I will try to reproduce the problem on my 50GB partition. Do you know if the orignal filesystem had directory indexes enabled?

        If it comes down to it, you could send me the drive. But if it's not yours, then the owner probably would not like that. :)

        I'm busy with another Ext2 issue right now, but I will try to get to this ASAP.

        Thanks.

         
    • Yee-Ting Li

      Yee-Ting Li - 2004-09-14

      hi, i have related experiences and am iinterested in the outcome of this thread.

      i'm using a new 15" powerbook with osx 10.3.5 with 1.3 of ext2fsx. i have a external usb2 drive (sarotech hardbox with maxtor 120gb) formated on a linux host with ext2 as a single partition. it's very very full; only have about 3gb left on the device.

      i can't mount the drive without doing a full fsck either, but after that everything seems fine; i can get disktool to mount it automatically and i can browse read and write operations no probs.

      however, i'm in need to archive some of the files (zip). so i fire up the zip command line, and wham! it does a kernel panic:

      panic(cpu 0): ext2_cmap: allocation requested inside a block (possible filesystem corruption): qbmask=4095, inode=12697604, offset=1244160, blkoff=3072
      Latest stack backtrace for cpu 0:
            Backtrace:
               0x000836E4 0x00083BC8 0x0001EDA4 0x2064F6A8 0x000B82DC 0x000BBACC 0x000B8A08 0x000B8B88
               0x000BAB40 0x000BA5E0 0x206493F8 0x000CDFCC 0x0022150C 0x00221324 0x002452B4 0x00094200
               0xFFEBEBEB
            Kernel loadable modules in backtrace (with dependencies):
               net.sourceforge.ext2fs.fs.ext2(1.2.1)@0x2063c000
      Proceeding back via exception chain:
         Exception state (sv=0x2E0E1780)
            PC=0x9000EACC; MSR=0x0000D030; DAR=0x00063000; DSISR=0x42000000; LR=0x00009910; R1=0xBFFFF8C0; XCP=0x00000030 (0xC00 - System call)

      Kernel version:
      Darwin Kernel Version 7.5.0:
      Thu Aug  5 19:26:16 PDT 2004; root:xnu/xnu-517.7.21.obj~3/RELEASE_PPC

       
    • Yee-Ting Li

      Yee-Ting Li - 2004-09-14

      hi, i have related experiences and am iinterested in the outcome of this thread.

      i'm using a new 15" powerbook with osx 10.3.5 with 1.3 of ext2fsx. i have a external usb2 drive (sarotech hardbox with maxtor 120gb) formated on a linux host with ext2 as a single partition. it's very very full; only have about 3gb left on the device.

      i can't mount the drive without doing a full fsck either, but after that everything seems fine; i can get disktool to mount it automatically and i can browse read and write operations no probs.

      however, i'm in need to archive some of the files (zip). so i fire up the zip command line, and wham! it does a kernel panic:

      panic(cpu 0): ext2_cmap: allocation requested inside a block (possible filesystem corruption): qbmask=4095, inode=12697604, offset=1244160, blkoff=3072
      Latest stack backtrace for cpu 0:
            Backtrace:
               0x000836E4 0x00083BC8 0x0001EDA4 0x2064F6A8 0x000B82DC 0x000BBACC 0x000B8A08 0x000B8B88
               0x000BAB40 0x000BA5E0 0x206493F8 0x000CDFCC 0x0022150C 0x00221324 0x002452B4 0x00094200
               0xFFEBEBEB
            Kernel loadable modules in backtrace (with dependencies):
               net.sourceforge.ext2fs.fs.ext2(1.2.1)@0x2063c000
      Proceeding back via exception chain:
         Exception state (sv=0x2E0E1780)
            PC=0x9000EACC; MSR=0x0000D030; DAR=0x00063000; DSISR=0x42000000; LR=0x00009910; R1=0xBFFFF8C0; XCP=0x00000030 (0xC00 - System call)

      Kernel version:
      Darwin Kernel Version 7.5.0:
      Thu Aug  5 19:26:16 PDT 2004; root:xnu/xnu-517.7.21.obj~3/RELEASE_PPC

      so far i've tried reading and writing to the device with zip, and reading from the drive but storing the zip on my laptop drive. both crash with the same trace.

      any suggestions?

      Yee.

       
    • Yee-Ting Li

      Yee-Ting Li - 2004-09-14

      further information:

      i tried copying the data over from Finder this time; that worked. then i deleted the files using rm in termiinal and that was fine. i then tried copying the 6mb zip back to the drive.. and yep, it paniced again....

      problems with writing?

      also any chance of implementing something that can mount WITHOUT a check? i tend to forget what i was doing after waiting about an hour for a fsck...

      also when i boot with the usb drive connected, the system doesn't boot for ages, saying that it's waiting for local file systems/disks. (yep, i'm lazy to unplug the usb also...!)

      Yee.

       
      • Brian Bergstrand

        Yee,

        This panic has so far been associated only with certain USB drives. If you can, use Firewire or IDE. It seems some USB drives work, but a few unlucky ones cause this problem. FW and IDE always work w/o problem.

        The reason the system doesn't boot for ages is because the disk manager is fsck'ing the drive. Large drives can take a very long to time to fsck. The stupid thing is that the disk manager does not try to repair the drive it only runs fsck in read-only mode to verify it.

         
        • Yee-Ting Li

          Yee-Ting Li - 2004-09-16

          thanks for the reply - after reading some of the older messages this was exactly what i thought also.

          is this all down to the apple implementation of usb mass storage? it's just that i have had absolutely no problems with the drive on windoze and linux boxes...

          is there anyway of not fscking the disk when its connected? it just defies the purpose of plug and play when you have to wait an hour before you can access the drive...

           
          • Brian Bergstrand

            Others have reported the same experience, the drive works fine on PC's, but causes this problem on Macs. The only thing I can think of is that the Macs are much more sensitive to USB inconsistencies. Do you have any other USB devices (besides kbd/mouse) plugged in at the same time as the drive?

             

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks