[Btrfs-devel] kernel BUG at volumes.c:1404!

[Chris Mason]

On Friday 25 April 2008, Peter Teoh wrote:
> I keep  getting the following whenever I did a  "mount -t btrfs
> /dev/sdc1 /mnt/btrfs".   The partition was mountable the last  time
> round.   As shown below, it is just a  1GB thumbdrive.

Looks like that super block is corrupted.  Can you think of anything that 
would have caused problems?

I'll work up a commit to be more tolerant during read_sys_array.

-chris

>
> scsi 3:0:0:0: Direct-Access     TREK     TDMINIG4         1.00 PQ: 0 ANSI:
> 2 sd 3:0:0:0: [sdc] 2015231 512-byte hardware sectors (1032 MB)
> sd 3:0:0:0: [sdc] Write Protect is off
> sd 3:0:0:0: [sdc] Mode Sense: 00 00 00 00
> sd 3:0:0:0: [sdc] Assuming drive cache: write through
> sd 3:0:0:0: [sdc] 2015231 512-byte hardware sectors (1032 MB)
> sd 3:0:0:0: [sdc] Write Protect is off
> sd 3:0:0:0: [sdc] Mode Sense: 00 00 00 00
> sd 3:0:0:0: [sdc] Assuming drive cache: write through
>  sdc: sdc1
> sd 3:0:0:0: [sdc] Attached SCSI removable disk
> sd 3:0:0:0: Attached scsi generic sg3 type 0
> device fsid d54e88dfe7045a33-5c0a895e8fb74296 devid 1 transid 19 /dev/sdc1
> ------------[ cut here ]------------
> kernel BUG at /sda4/download/linux_linus/btrfs-unstable/volumes.c:1404!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: btrfs nls_utf8 loop ipt_MASQUERADE iptable_nat
> nf_nat bridge autofs4 hidp rfcomm l2cap bluetooth sunrpc
> nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state nf_conntrack
> ipt_REJECT iptable_filter ip_tables xt_tcpudp ip6t_REJECT
> ip6table_filter ip6_tables x_tables cpufreq_ondemand acpi_cpufreq
> dm_mirror dm_multipath dm_mod sbs sbshc radeon drm ipv6 snd_intel8x0
> snd_seq_dummy snd_intel8x0m snd_ac97_codec ac97_bus snd_seq_oss
> snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss
> snd_pcm snd_timer snd firewire_ohci firewire_core soundcore ipw2200
> ieee80211 sdhci mmc_core video b44 button iTCO_wdt iTCO_vendor_support
> output ssb crc_itu_t mii i2c_i801 battery joydev snd_page_alloc
> ieee80211_crypt dcdbas i2c_core pcspkr ac sr_mod sg cdrom usb_storage
> ata_generic ahci ata_piix libata sd_mod scsi_mod ext3 jbd ehci_hcd
> ohci_hcd uhci_hcd [last unloaded: microcode]
>
> Pid: 8018, comm: mount Not tainted (2.6.25-rc9 #5)
> EIP: 0060:[<f8bf0b70>] EFLAGS: 00010a16 CPU: 0
> EIP is at btrfs_read_sys_array+0x97/0xaa [btrfs]
> EAX: 000000c5 EBX: 000001d8 ECX: cdb80000 EDX: 00000000
> ESI: f170a32c EDI: 00000000 EBP: d63f7dfc ESP: d63f7dd0
>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process mount (pid: 8018, ti=d63f7000 task=c6ade6e0 task.ti=d63f7000)
> Stack: c6a86200 ed745188 00000047 ed745188 00000246 c570abc4 000000bf
> 04854f00 00000001 00001000 f170a154 d63f7e3c f8bdb4e2 f14698a0 e1f2f600
> f170abc4 00001000 00001000 00001000 c6a86c00 c6a86200 f16ee600 f170a000
> f16eee00 Call Trace:
>  [<f8bdb4e2>] ? open_ctree+0x5bf/0x7c7 [btrfs]
>  [<f8bcd4d2>] ? btrfs_get_sb_bdev+0x134/0x2d8 [btrfs]
>  [<c04288c4>] ? irq_exit+0x53/0x6b
>  [<f8bcd6ba>] ? btrfs_get_sb+0x44/0x5f [btrfs]
>  [<c0475821>] ? vfs_kern_mount+0x81/0xf7
>  [<c04758db>] ? do_kern_mount+0x32/0xb9
>  [<c048794c>] ? do_new_mount+0x46/0x74
>  [<c0487b03>] ? do_mount+0x189/0x1a7
>  [<c045a2ed>] ? __get_free_pages+0x45/0x4c
>  [<c0485f40>] ? copy_mount_options+0x27/0x10b
>  [<c0487b85>] ? sys_mount+0x64/0x9b
>  [<c04048c6>] ? sysenter_past_esp+0x5f/0x85
>  =======================
> Code: 0b eb fe 8b 45 d8 89 da e8 30 68 ff ff 0f b7 c0 85 c0 75 04 0f
> 0b eb fe c1 e0 05 83 c0 30 8d 74 06 11 8d 1c 18 8d 7c 07 11 eb 04 <0f>
> 0b eb fe 3b 7d dc 72 93 8d 65 f4 31 c0 5b 5e 5f 5d c3 55 89
> EIP: [<f8bf0b70>] btrfs_read_sys_array+0x97/0xaa [btrfs] SS:ESP
> 0068:d63f7dd0
>
>
> uname -r:
>
> 2.6.25-rc9
>
> lsmod:
>
> btrfs                 208952  2
>
> My tip is:
>
> changeset:   513:1c4e9af4dfe7
> tag:         tip
> user:        Chris Mason <chris.mason at oracle.com>
> date:        Tue Apr 22 13:26:47 2008 -0400
> summary:     Fix the unplug_io_fn to grab a consistent copy of
> page->mapping
>
> Even after reboot the  kernel, the same thing happened.   And the
> second time of issuing the same mount command, will result in mount
> blocking, but not the first time.
>
> Any clue?