Regression test failure #421
Comments
|
Are you sure you have 0.6.0-rc6? I was seeing the same issue which is why I applied the 5cbf6db patch which should briefly disables the udev rules which were causing the issue. |
|
I downloaded the archive rather then checking out the git repo. The file was named 0.6.0-rc6, so unless there were multiple releases under that version name, I am sure that I have it. I'm going to try grabbing the latest version from git, will let you know. |
|
root@debian:/usr/local/libexec/zfs# ./zconfig.sh -c Same issue with 5cbf6db. I notice you only mention 90-zfs.rules in the commit message, would 60-zpool.rules and 60-zvol.rules cause similar issues? (Should I even have these in rules.d?) |
|
90-zfs.rules should be the only rule you need to disable. Now I disable it simply by renaming it which worked on my test system but perhaps your version of udev works differently? I haven't tested on wheezy. You could try simply removing it, it's not strictly required just helpful when using zfs as your root filesystem. The 60-zpool.rules and 60-zvol.rules you'll need to leave in place or udev won't correctly populate /dev/ with the needed devices. |
|
Do I want to reenable 90-zfs.rules once the test pass, or should it be binned completely? Otherwise experiencing the same failures until 90 is disabled. |
|
You don't need it for normal operation, if it's causing trouble just remove it. Did that resolve your zconfig.sh test issues? |
|
Yes, removing that file has resolved the issue I was having. All zconfig.sh tests pass now. |
|
Alright, I'll give this a try in wheezy. Perhaps just renaming the rule while the test running isn't going to be enough, moving it somewhere else might be needed. |
|
Are you restarting udev? That may or may not be necessary. (I'm unsure, I On Wed, Oct 19, 2011 at 11:54 AM, Brian Behlendorf <
|
|
I'm not restarting udev, and I did test the changes on Lenny and Squeeze just not Wheezy. |
|
Closing as stale |
It is known that mutexes in Linux are not safe when using them to synchronize the freeing of object in which the mutex is embedded: http://lwn.net/Articles/575477/ The known places in ZFS which are suspected to suffer from the race condition are zio->io_lock and dbuf->db_mtx. * zio uses zio->io_lock and zio->io_cv to synchronize freeing between zio_wait() and zio_done(). * dbuf uses dbuf->db_mtx to protect reference counting. This patch fixes this kind of race by forcing serialization on mutex_exit() with a spin lock, making the mutex safe by sacrificing a bit of performance and memory overhead. This issue most commonly manifests itself as a deadlock in the zio pipeline caused by a process spinning on the damaged mutex. Similar deadlocks have been reported for the dbuf->db_mtx mutex. And it can also cause a NULL dereference or bad paging request under the right circumstances. This issue any many like it are linked off the openzfs#2523 issue. Specifically this fix resolves at least the following outstanding issues: openzfs#401 openzfs#2523 openzfs#2679 openzfs#2684 openzfs#2704 openzfs#2708 openzfs#2517 openzfs#2827 openzfs#2850 openzfs#2891 openzfs#2897 openzfs#2247 openzfs#2939 Signed-off-by: Chunwei Chen <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Signed-off-by: Richard Yao <[email protected]> Closes openzfs#421
I just installed zfs-0.6.0-rc6 on Debian wheezy x64 (Linux debian 3.0.0-1-amd64 #1 SMP Sat Aug 27 16:21:11 UTC 2011 x86_64 GNU/Linux), and I'm seeing failures when running zconfig.sh -c:
root@debian:/usr/local/libexec/zfs# ./zconfig.sh -c
1 persistent zpool.cache Pass
2 scan disks for pools to import Pass
3 zpool import/export device Pass
4 zpool insmod/rmmod device zfs.sh: Unload these modules with 'zfs.sh -u':
zfs zcommon zunicode znvpair zavl spl
Fail (10)
root@debian:/usr/local/libexec/zfs# ./zfs.sh -u
root@debian:/usr/local/libexec/zfs# ./zconfig.sh -c
1 persistent zpool.cache zfs.sh: Unload these modules with 'zfs.sh -u':
zfs zcommon zunicode znvpair zavl spl
Fail (1)
Not sure if this is relevant, but I was seeing the same issue that's described in #233 until I manually copied all the .rules files from udev/rules.d in the archive to my /etc/udev/rules.d directory and restarted udev.
The text was updated successfully, but these errors were encountered: