Re: [BISECT] Kernel panic, RIP bitmap_create

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Wed, May 2, 2012 at 10:58 PM, NeilBrown <neilb@xxxxxxx> wrote:
> On Wed, 2 May 2012 22:05:44 -0700 Karl Newman <siliconfiend@xxxxxxxxx> wrote:
>
>> Hi,
>>
>> I'm attempting to use kernel 3.4-rc? but keep running into a kernel panic on
>> boot, with RIP pointing to bitmap_create. I tried 3.4-rc1, 3.4-rc4 and
>> 3.4-rc5 and they all have the kernel panic, while 3.3.4 boots fine. I have
>> my root on raid 5 with an internal bitmap, and the kernel panic occurs if I
>> use the built-in kernel autodetect or during the root array assembly via
>> mdadm inside a dracut-generated initramfs. I bisected it down to the
>> following commit:
>> 61a0d80ce4ab5b4fb9ecb38f1fb19654778b71ed
>>
>> md/bitmap: discard CHUNK_BLOCK_SHIFT macro
>>
>> Be redefining ->chunkshift as the shift from sectors to chunks rather than
>> bytes to chunks, we can just use "bitmap->chunkshift" which is shorter than
>> the macro call, and less indirect.
>>
>> Signed-off-by: NeilBrown <neilb@xxxxxxx>
>>
>> My bisect testing including a scary commit where 2 of 3 drives had their
>> UUIDs zeroed when I booted with it! Fortunately I found the mailing list
>> archives with the solution and I was able to recover everything and keep
>> bisecting (although I was tempted to quit and just give the range of
>> commits...).
>>
>> I hope this fix can make it into the next 3.4-rc kernel.
>
> I do too, but first I would need to know what the fix is, and I cannot see
> anything in that commit what would change the behaviour of md at all.
>
> Do you have a copy of the full stack trace provided when Linux crashed?  That
> could be useful.
> Also what bitmap chunk size are you using? Maybe the output of
>  mdadm -X
> and
>  mdadm -E
>
> of one of the devices in the array would help.
>
> Thanks a lot for the report and going to the trouble of bisecting, it is
> really appreciated.
>
> NeilBrown

I'm not sure how to go about getting the full stack trace. The
motherboard has no serial port, so that's not an option. Unless the
kernel supports USB to serial adapters for that purpose, in which case
I might be able to borrow a couple Keyspans. Or I could sit and try
and transcribe the whole thing...(!) I'm a little nervous about
tripping the all-zeros UUID bug again, although it only happened once
and it doesn't seem to be related to that commit. Anyway, here's some
data from the array:

# mdadm -E /dev/sda3
/dev/sda3:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 60bf4ee8:e6e3e14f:073e21cd:ed2abb54
  Creation Time : Wed May  2 20:22:47 2012
     Raid Level : raid5
  Used Dev Size : 29302400 (27.94 GiB 30.01 GB)
     Array Size : 58604800 (55.89 GiB 60.01 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 127

    Update Time : Wed May  2 23:01:45 2012
          State : active
Internal Bitmap : present
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 863c968f - correct
         Events : 2

         Layout : left-symmetric
     Chunk Size : 128K

      Number   Major   Minor   RaidDevice State
this     0       8        3        0      active sync   /dev/sda3

   0     0       8        3        0      active sync   /dev/sda3
   1     1       8       19        1      active sync   /dev/sdb3
   2     2       8       35        2      active sync   /dev/sdc3

# mdadm -X /dev/sda3
        Filename : /dev/sda3
           Magic : 6d746962
         Version : 4
            UUID : 60bf4ee8:e6e3e14f:073e21cd:ed2abb54
          Events : 1
  Events Cleared : 1
           State : OK
       Chunksize : 64 MB
          Daemon : 5s flush period
      Write Mode : Normal
       Sync Size : 29302400 (27.94 GiB 30.01 GB)
          Bitmap : 448 bits (chunks), 0 dirty (0.0%)
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[ATA RAID]     [Linux SCSI Target Infrastructure]     [Managing RAID on Linux]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device-Mapper]     [Kernel]     [Linux Books]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Photos]     [Yosemite Photos]     [Yosemite News]     [AMD 64]     [Linux Networking]

Add to Google Powered by Linux