Oops in generic_getxattr+0x25 with Debian #189
Labels
Type: Architecture
Indicates an issue is specific to a single processor architecture
Milestone
Comments
|
Terrible bug report, didn't even give kernel version: Linux huge 2.6.32-5-686 |
|
If you can consistent reproduce this bug please attach the full stack trace from dmesg if possible. Also be aware that 32-bit kernels are not supported, tested, or expected to work. Perhaps at some point, but not today. |
|
Oops, I didn't even notice it was 32bit.
Today: Linux huge 2.6.32-5-amd64 #1 SMP Tue Mar 8 22:49:26 UTC 2011 x86_64 GNU/Linux
Compiled and inserted. Can not make it happen. Everything works like a charm.
<pre><code>
Apr 5 15:31:56 huge kernel: [ 267.173008] Oops: 0000 [#1] SMP
Apr 5 15:31:56 huge kernel: [ 267.173008] last sysfs file: /sys/devices/virtua
l/zpios/zpios/uevent
Apr 5 15:31:56 huge kernel: [ 267.173008] Modules linked in: zpios zfs(P) zcom
mon(P) zunicode(P) znvpair(P) zavl(P) splat spl zlib zlib_deflate loop snd_pcm s
nd_timer parport_pc parport evdev snd button soundcore processor i2c_piix4 i2c_c
ore psmouse snd_page_alloc serio_raw pcspkr ext3 jbd mbcache sg sd_mod sr_mod cr
c_t10dif cdrom ata_generic ata_piix libata uhci_hcd 8139too ehci_hcd floppy scsi
_mod thermal thermal_sys usbcore nls_base 8139cp mii [last unloaded: scsi_wait_s
can]
Apr 5 15:31:56 huge kernel: [ 267.173008]
Apr 5 15:31:56 huge kernel: [ 267.173008] Pid: 2246, comm: ls Tainted: P
(2.6.32-5-686 #1) HVM domU
Apr 5 15:31:56 huge kernel: [ 267.173008] EIP: 0060:[<c10c6e01>] EFLAGS: 00010
202 CPU: 1
Apr 5 15:31:56 huge kernel: [ 267.173008] EIP is at generic_getxattr+0x25/0x5f
Apr 5 15:31:56 huge kernel: [ 267.173008] EAX: f8675b1b EBX: 000000e6 ECX:
00000075 EDX: f660fe84
Apr 5 15:31:56 huge kernel: [ 267.173008] ESI: f8679fa0 EDI: f660fe84 EBP:
f501bedc ESP: f660fe4c
Apr 5 15:31:56 huge kernel: [ 267.173008] DS: 007b ES: 007b FS: 00d8 GS: 00e0
SS: 0068
Apr 5 15:31:56 huge kernel: [ 267.173008] Process ls (pid: 2246, ti=f660e000
task=f54e8440 task.ti=f660e000)
Apr 5 15:31:56 huge kernel: [ 267.173008] Stack:
Apr 5 15:31:56 huge kernel: [ 267.173008] 00000000 c10c6ddc f660fe84 f6a4c908
00000000 c10c754f 00000000 00000017
Apr 5 15:31:56 huge kernel: [ 267.173008] <0> 00000000 00000000 f6a4c908
c10c75d9 00000000 00000000 74737973 702e6d65
Apr 5 15:31:56 huge kernel: [ 267.173008] <0> 7869736f 6c63615f 6363615f
00737365 c10b96fc f6a4c770 f6f8d800 f6f8d868
Apr 5 15:31:56 huge kernel: [ 267.173008] Call Trace:
Apr 5 15:31:56 huge kernel: [ 267.173008] [<c10c6ddc>] ?
generic_getxattr+0x0/0x5f
Apr 5 15:31:56 huge kernel: [ 267.173008] [<c10c754f>] ? vfs_getxattr+0x73/0x79
Apr 5 15:31:56 huge kernel: [ 267.173008] [<c10c75d9>] ? getxattr+0x84/0xe3
Apr 5 15:31:56 huge kernel: [ 267.173008] [<c10b96fc>] ? __follow_mount+0x1e/0x56
Apr 5 15:31:56 huge kernel: [ 267.173008] [<c10c4b07>] ?
mntput_no_expire+0x17/0xb6
Apr 5 15:31:56 huge kernel: [ 267.173008] [<c10b963d>] ?
path_to_nameidata+0x19/0x26
Apr 5 15:31:56 huge kernel: [ 267.173008] [<c10ba21a>] ?
__link_path_walk+0x5d9/0x5de
Apr 5 15:31:56 huge kernel: [ 267.173008] [<c10c4b07>] ?
mntput_no_expire+0x17/0xb6
Apr 5 15:31:56 huge kernel: [ 267.173008] [<c10bc6c2>] ? user_path_at+0x40/0x5f
Apr 5 15:31:56 huge kernel: [ 267.173008] [<c10b5ec6>] ? sys_lstat64+0x1e/0x23
Apr 5 15:31:56 huge kernel: [ 267.173008] [<c10c76f7>] ? sys_getxattr+0x37/0x48
Apr 5 15:31:56 huge kernel: [ 267.173008] [<c10030fb>] ?
sysenter_do_call+0x12/0x28
Apr 5 15:31:56 huge kernel: [ 267.173008] Code: 5f 5d c3 90 90 90 55 57 89 d7
56 53 83 ec 04 85 d2 89 0c 24 8b 68 10 8b 85 a4 00 00 00 8b 40 70 74 28 8b 18 8d
70 04 eb 1d 89 fa <8b> 03 eb 02 42 40 8a 08 84 c9 74 06 38 0a 74 f4 eb 04 85 d2 75
Apr 5 15:31:56 huge kernel: [ 267.173008] EIP: [<c10c6e01>]
generic_getxattr+0x25/0x5f SS:ESP 0068:f660fe4c
Apr 5 15:31:56 huge kernel: [ 267.173008] CR2: 00000000000000e6
Apr 5 15:31:56 huge kernel: [ 267.235427] ---[ end trace 7b88a5942df7d560 ]---
</pre></code>
It is very consistent, but only on 32bit. Perhaps it does not matter then. Although, everything else worked really great even under 32bit kernel.
That pre-code thing only seems to work 50% of the time... also, it is ok to close this if you want. The 64bit code is awesome.
|
|
Thanks for the additional debugging. I'm glad it works for you as expected on a 64-bit box. I'm going to leave the issue open for now because it looks like there's a real bug here, but I'll put it at the bottom of our todo list since it's a 32-bit issue. We will fix it at some point. |
prateekpandey14
pushed a commit
to prateekpandey14/zfs
that referenced
this issue
Mar 13, 2019
When replica gets disconnected with target due to timeout, there might be some IOs that are not responded for long time. There are ZIO delay logs that helps in debugging this issue. This PR is to logs at uZFS layer regarding high latent IOs. Signed-off-by: Vishnu Itta <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
spl-0.6.0-rc2 zfs-0.6.0-rc2 both compile without issue. All modules loads correctly. zpool and zfs operations generally work, and on zfs file systems, I can mkdir/rmdir/cp/dd/ and "ls" without issue. But "ls -l", or things that call stat/xattr will generate Oops.
The text was updated successfully, but these errors were encountered: