Project

General

Profile

Bug #2154

Panic DL460 G1 zpool create -f test c2t0d0s0

Added by Piotr Jasiukajtis over 8 years ago. Updated over 8 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
zfs - Zettabyte File System
Start date:
2012-02-20
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

I have an interesting example here.

The machine is HP DL460 G1.

'zpool create -f test c2t0d0s0' ends in kernel panic. c2t0d0s0 contains an old zpool (build b118 as I recall).

Tested on b148, b151a.

Screenshots from kmdb attached.


Files

stack.png (75.2 KB) stack.png stack Piotr Jasiukajtis, 2012-02-20 09:55 AM
spa.png (68.2 KB) spa.png spa Piotr Jasiukajtis, 2012-02-20 09:55 AM
zio_root.png (83.5 KB) zio_root.png zio_root Piotr Jasiukajtis, 2012-02-20 09:55 AM
panic_1.png (83.9 KB) panic_1.png Piotr Jasiukajtis, 2012-02-20 03:55 PM
panic_2.png (89.8 KB) panic_2.png Piotr Jasiukajtis, 2012-02-20 03:55 PM
stack.png (101 KB) stack.png Piotr Jasiukajtis, 2012-02-20 03:56 PM
ashift.png (102 KB) ashift.png Piotr Jasiukajtis, 2012-02-20 05:51 PM

Related issues

Related to illumos gate - Bug #348: ZFS should handle DKIOCGMEDIAINFOEXT failureResolved2010-10-152013-08-01

Actions
Related to OpenIndiana Distribution - Bug #3016: Kernel Panic with text install with HP Smart ArrayNew2012-07-22

Actions

History

#1

Updated by Rich Lowe over 8 years ago

  • Status changed from New to Feedback

The actual panic message is in none of your screenshots, that's going to make this really difficult.

#2

Updated by Piotr Jasiukajtis over 8 years ago

Right, just forgot about it.
Here are a new snapshots, this time from oi_151a.

#3

Updated by Piotr Jasiukajtis over 8 years ago

stack trace attached

#4

Updated by Rich Lowe over 8 years ago

I swear I have seen this somehere before, related to a bad ashift being decided upon for the drives.

Can you do *panic_thread::findstack -v to get a trace with arguments?

When you've done that, could you do:

<the argument of zio_vdev_io_start>::print zio_t io_vd->vdev_top->vdev_ashift

That is, if in the stack you see:

...
zio_vdev_io_start(ffffffaa04eba8)
...

Do

ffffffaa04eba8::print zio_t io_vd->vdev_top->vdev_ashift

#5

Updated by Rich Lowe over 8 years ago

If it is the incorrect ashift issue, it comes down to READ_CAPACITY formats again (I finally found where I remembered it from)

#6

Updated by Rich Lowe over 8 years ago

Actually, the stack trace I didn't see covers that, ashift is 0x14
(argument to zio_buf_alloc is 0x10000,

-((-(1<<9)) & (-(1<<0x14)))
== 0x10000)

#7

Updated by Piotr Jasiukajtis over 8 years ago

You're right. ashift is 0x14.

I need to mention the panic doesn't occur immediately after zpool create command.
You need to wait at least few seconds for that, sometimes 30s or more.

Rich Lowe wrote:

Actually, the stack trace I didn't see covers that, ashift is 0x14
(argument to zio_buf_alloc is 0x10000, [...] == 0x10000)

Also available in: Atom PDF