Re: 9.2-RC3 - suspend/resume causes slow system performance
I was able to track this down by building kernels against /base/stable/9 (it took -hours!-). The issue does occur with commit 244616, but does not occur with 244614. The only difference is a small patch to /usr/src/sys/dev/acpica/acpi_cpu.c - this code appears to do with c-state processing. I'll note it in the ticket, but somebody might want to look at this ASAP On Thu, Aug 29, 2013 at 7:10 AM, Adrian Chadd adr...@freebsd.org wrote: Wow. Uhm, can you downgrade to 9.1 and see if it still happens? Would you be able to bisect the kernel source and see if you can find where along stable/9 it happened? That's the fastest way to determine what broke. Thanks! -adrian On 29 August 2013 06:32, Mike Harding mvhard...@gmail.com wrote: I opened a ticket about this: kern/181632 Basically, if I do a 'zzz' and then wake the system up, operations like a buildworld or portmaster take much longer after the resume - systat shows very low CPU/disk utilization. It's 100% repeatable, I don't recall this happening on 9.1 I build 9.2-RC3 from source (as I have for years) - this is a fairly generic SMP system (i5 750 with 4 cpus). Let me know if I can provide any data - this is a fairly significant regression for me as I have taken to bringing the system up as needed vs. leaving it on all of the time. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.2-RC3 - suspend/resume causes slow system performance
On 29 August 2013 23:46, Mike Harding mvhard...@gmail.com wrote: I was able to track this down by building kernels against /base/stable/9 (it took -hours!-). Wow, thanks! The issue does occur with commit 244616, but does not occur with 244614. The only difference is a small patch to /usr/src/sys/dev/acpica/acpi_cpu.c - this code appears to do with c-state processing. I'll note it in the ticket, but somebody might want to look at this ASAP That's awesome. It's a very small ACPI patch. Let's see if the others who are having this issue can test this out and report back! Thanks! -adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Boot problem if a ZFS log device is missing
On 29/08/2013 11.01, Andriy Gapon wrote: on 29/08/2013 11:27 Maurizio Vairani said the following: I am able to boot the PC without a cache device but not without a log device. Why ? The log could potentially contain uncommitted entries. Without the log device there is no knowing if it did or did not. And if it did then the pool is inconsistent state without the log device and so it can not be imported. The cache is not persistent and so there is nothing needed from it upon a boot. Thank you for the clear and concise reply. Yesterday I have done some test. If I remove the stick from the USB port, before the shutdown the PC, it don't crash but continues to works. Then I am able to reboot the laptop without inserting the stick with a pool that works in degraded mode. From the end user point of view a PC should always boot, even with a missing ZFS log device. Regards Maurizio ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Suggest changing dirhash defaults for FreeBSD 9.2.
Observation relevant to tuning vfs.ufs.dirhash_maxmem: When swap is in use dirhash_mem hovers between 10% and 20% of dirhash_maxmem due to frequent scavenging. This indicates active dirhash_mem effectively behaves differently during low memory, and that the dirhash_reclaimage setting is effectively irrelevant during low memory. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Suggest-changing-dirhash-defaults-for-FreeBSD-9-2-tp5839351p5840292.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC?
On Fri, Aug 30, 2013 at 3:07 AM, Andy Farkas an...@andyit.com.au wrote: There's still plenty of laptops that would be crippled if these were removed. Indeed: dc0: Abocom FE2500 10/100BaseTX port 0x1000-0x10ff mem 0x8800-0x880003ff irq 11 at device 0.0 on cardbus1 -andyf Just to be clear, I'm not suggesting to retire the drivers but to take them out of the GENERIC kernel config and move them to be loaded as modules only. Adrian Chadd undestood perfectly what I was after. -Kimmo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Boot problem if a ZFS log device is missing
on 30/08/2013 00:38 Charles Sprickman said the following: If one is willing to accept that data is lost (like the log device is totally smoked), is there a way to boot knowing that you may have some data loss, or is the only option to boot alternate media and force a pool import (assuming that works without the log device)? I think it's the latter. I am not aware of any way to select a behavior similar to import -m or import -F during boot. Perhaps... ZFS_IMPORT_MISSING_LOG should be a default behavior for a root pool or maybe the behavior could be controllable by a tunable. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Boot problem if a ZFS log device is missing
on 30/08/2013 13:37 Andriy Gapon said the following: on 30/08/2013 00:38 Charles Sprickman said the following: If one is willing to accept that data is lost (like the log device is totally smoked), is there a way to boot knowing that you may have some data loss, or is the only option to boot alternate media and force a pool import (assuming that works without the log device)? I think it's the latter. I am not aware of any way to select a behavior similar to import -m or import -F during boot. Perhaps... ZFS_IMPORT_MISSING_LOG should be a default behavior for a root pool or maybe the behavior could be controllable by a tunable. Maurizio, you might want to try the following patch as an interim solution for your environment: --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c @@ -4112,6 +4112,7 @@ spa_import_rootpool(const char *name) } spa-spa_is_root = B_TRUE; spa-spa_import_flags = ZFS_IMPORT_VERBATIM; + spa-spa_import_flags |= ZFS_IMPORT_MISSING_LOG; /* XXX make tunable */ /* * Build up a vdev tree based on the boot device's label config. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Boot problem if a ZFS log device is missing
Maurizio Vairani wrote: On 29/08/2013 11.01, Andriy Gapon wrote: on 29/08/2013 11:27 Maurizio Vairani said the following: I am able to boot the PC without a cache device but not without a log device. Why ? The log could potentially contain uncommitted entries. Without the log device there is no knowing if it did or did not. And if it did then the pool is inconsistent state without the log device and so it can not be imported. The cache is not persistent and so there is nothing needed from it upon a boot. Thank you for the clear and concise reply. Yesterday I have done some test. If I remove the stick from the USB port, before the shutdown the PC, it don't crash but continues to works. Then I am able to reboot the laptop without inserting the stick with a pool that works in degraded mode. From the end user point of view a PC should always boot, even with a missing ZFS log device. Regards Maurizio ___ freebsd...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to freebsd-fs-unsubscr...@freebsd.org I do not agree with the following. From the end user point of view a PC should always boot, even with a missing ZFS log device. I think it should give you a option to import the pool or not import the pool! There could be a situation when you are not sure that the ZIL is commited, in that situation it would be handy if you can suspend the boot and make sure the ZIL is there when you reboot or import after you attached the ZIL. I would hate it when it corrups my data just because we always import. with or without the ZIL. In your test you remove the ZIL, and when you reboot then it imports correctly, as far as my knowledge goes this is ok, because when the pool is exported there is no left data in the ZIL, it was not there when we exported, so we can import even without the missing ZIL without problem. regards Johan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Boot problem if a ZFS log device is missing
On Fri, 30 Aug 2013 12:58:29 +0200, Johan Hendriks joh.hendr...@gmail.com wrote: Maurizio Vairani wrote: On 29/08/2013 11.01, Andriy Gapon wrote: on 29/08/2013 11:27 Maurizio Vairani said the following: I am able to boot the PC without a cache device but not without a log device. Why ? The log could potentially contain uncommitted entries. Without the log device there is no knowing if it did or did not. And if it did then the pool is inconsistent state without the log device and so it can not be imported. The cache is not persistent and so there is nothing needed from it upon a boot. Thank you for the clear and concise reply. Yesterday I have done some test. If I remove the stick from the USB port, before the shutdown the PC, it don't crash but continues to works. Then I am able to reboot the laptop without inserting the stick with a pool that works in degraded mode. From the end user point of view a PC should always boot, even with a missing ZFS log device. Regards Maurizio ___ freebsd...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to freebsd-fs-unsubscr...@freebsd.org I do not agree with the following. From the end user point of view a PC should always boot, even with a missing ZFS log device. I think it should give you a option to import the pool or not import the pool! There could be a situation when you are not sure that the ZIL is commited, in that situation it would be handy if you can suspend the boot and make sure the ZIL is there when you reboot or import after you attached the ZIL. I would hate it when it corrups my data just because we always import. with or without the ZIL. In your test you remove the ZIL, and when you reboot then it imports correctly, as far as my knowledge goes this is ok, because when the pool is exported there is no left data in the ZIL, it was not there when we exported, so we can import even without the missing ZIL without problem. I think he was just lucky his system wasn't writing a lot to the ZIL at the moment of removal. So his system was in a consistent state. Otherwise you just miss data which is in the ZIL and not on disk. BTW: Not everything goes through the ZIL. It is not the same as a journal. Only sync writes go to the ZIL. If you don't use databases or NFS or other software which wants to make sure data is on stable storage, you might rarely use the ZIL. Ronald. regards Johan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Boot problem if a ZFS log device is missing
On 30/08/2013 13.45, Ronald Klop wrote: On Fri, 30 Aug 2013 12:58:29 +0200, Johan Hendriks joh.hendr...@gmail.com wrote: Maurizio Vairani wrote: On 29/08/2013 11.01, Andriy Gapon wrote: on 29/08/2013 11:27 Maurizio Vairani said the following: I am able to boot the PC without a cache device but not without a log device. Why ? The log could potentially contain uncommitted entries. Without the log device there is no knowing if it did or did not. And if it did then the pool is inconsistent state without the log device and so it can not be imported. The cache is not persistent and so there is nothing needed from it upon a boot. Thank you for the clear and concise reply. Yesterday I have done some test. If I remove the stick from the USB port, before the shutdown the PC, it don't crash but continues to works. Then I am able to reboot the laptop without inserting the stick with a pool that works in degraded mode. From the end user point of view a PC should always boot, even with a missing ZFS log device. Regards Maurizio ___ freebsd...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to freebsd-fs-unsubscr...@freebsd.org I do not agree with the following. From the end user point of view a PC should always boot, even with a missing ZFS log device. I think it should give you a option to import the pool or not import the pool! No problem I agree, a step in the right direction. There could be a situation when you are not sure that the ZIL is commited, in that situation it would be handy if you can suspend the boot and make sure the ZIL is there when you reboot or import after you attached the ZIL. I would hate it when it corrups my data just because we always import. with or without the ZIL. In your test you remove the ZIL, and when you reboot then it imports correctly, as far as my knowledge goes this is ok, because when the pool is exported there is no left data in the ZIL, it was not there when we exported, so we can import even without the missing ZIL without problem. I think he was just lucky his system wasn't writing a lot to the ZIL at the moment of removal. So his system was in a consistent state. Otherwise you just miss data which is in the ZIL and not on disk. I have removed the stick when there isn't R/W to the disk. BTW: Not everything goes through the ZIL. It is not the same as a journal. Only sync writes go to the ZIL. If you don't use databases or NFS or other software which wants to make sure data is on stable storage, you might rarely use the ZIL. Thanks for the explanation. Ronald. regards Johan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Regards Maurizio ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: gmirror crash writing to disk? Or is it su+j crash?
On Thu, Aug 29, 2013 at 4:35 PM, Zaphod Beeblebrox zbee...@gmail.comwrote: So I have a system running: FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 03:02:55 EDT 2013 r...@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 and it has two 2T SATA disks. To keep this post short, the crash.txt is here. https://uk.eicat.ca/owncloud/public.php?service=filest=fea9d25579fe0c4afb808859e80e1493 now curiously, while running a make -j4 buildkernel ... almost every time ... it crashes with: g_vfs_done():mirror/walke[WRITE(offset=516764794880, length=65536)]error = 11 /usr: got error 11 while accessing filesystem panic: softdep_deallocate_dependencies: unrecovered I/O error ... no error report from the hard drives, simply an error report from the mirror. The filesystem is ufs with su+j... but I'm not sure this matters here. Run fsck. -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Some PR never seen to delete
Hi, In the past I've sent some PR that has never been seen, I think we should close them now. 2010/09/16 kern/150628 [acd] [ata] burncd(1) can't write to optical drive 2010/07/14 ports/148591 x11 information note for x11-drivers/xf86-input-synaptic 2010/12/01 kern/152750 wireless[ath] ath0 lot of bad series hwrate 2010/12/12 bin/153052 [patch] watch(8) breaks tty on error 2011/01/25 ports/154288 glewis[patch] games/nethack*: remove old ports and cleanup latest 2011/02/07 kern/154567 wireless[ath] ath(4) lot of bad series(0) 2011/07/01 conf/158557rc [patch] /etc/rc.d/pf broken messages 2012/11/05 kern/173408 acpi[acpi] [regression] ACPI Regression: battery does not update often 2012/11/22 kern/173840 snd_hda(4) volume mixer not working anymore 2012/11/24 kern/173896 Kernel does not boot if splash loaded and hint.sc.0.vesa_mode set 2012/12/23 ports/174650 xfcex11-wm/xfce4 crash with exaGetPixmapFirstPixel called for invalid bpp 1 2012/12/28 kern/174766 acpi[acpi] Random acpi panic 2013/01/31 kern/175722 wireless[ath]lot of bad seriesx hwrate in kernel messages Some are still valid but will never been taken so I propose to close them. Cheers, -- Demelier David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: gmirror crash writing to disk? Or is it su+j crash?
I was going to mention that I ran fsck _twice_, but I forgot. Then when that didn't fix it, I dumped the filesystem, newfs'd it and restored it. Then I fsck'd it for good measure. This particular crash immediately follows that treatment. I can do this in a loop: boot - make -j4 buildkernel - crash - single user - fsck - fsck again -\ ^-/ On Fri, Aug 30, 2013 at 8:47 AM, Adam Vande More amvandem...@gmail.comwrote: On Thu, Aug 29, 2013 at 4:35 PM, Zaphod Beeblebrox zbee...@gmail.comwrote: So I have a system running: FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 03:02:55 EDT 2013 r...@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 and it has two 2T SATA disks. To keep this post short, the crash.txt is here. https://uk.eicat.ca/owncloud/public.php?service=filest=fea9d25579fe0c4afb808859e80e1493 now curiously, while running a make -j4 buildkernel ... almost every time ... it crashes with: g_vfs_done():mirror/walke[WRITE(offset=516764794880, length=65536)]error = 11 /usr: got error 11 while accessing filesystem panic: softdep_deallocate_dependencies: unrecovered I/O error ... no error report from the hard drives, simply an error report from the mirror. The filesystem is ufs with su+j... but I'm not sure this matters here. Run fsck. -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Some PR never seen to delete
Why would you want to have valid ones closed? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Some-PR-never-seen-to-delete-tp5840405p5840455.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: gmirror crash writing to disk? Or is it su+j crash?
Wiadomość napisana przez Zaphod Beeblebrox zbee...@gmail.com w dniu 29 sie 2013, o godz. 23:35: So I have a system running: FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 03:02:55 EDT 2013 r...@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 and it has two 2T SATA disks. To keep this post short, the crash.txt is here. https://uk.eicat.ca/owncloud/public.php?service=filest=fea9d25579fe0c4afb808859e80e1493 Login error. now curiously, while running a make -j4 buildkernel ... almost every time ... it crashes with: g_vfs_done():mirror/walke[WRITE(offset=516764794880, length=65536)]error = 11 /usr: got error 11 while accessing filesystem panic: softdep_deallocate_dependencies: unrecovered I/O error This is softupdates panic caused by write operation returning error 11, which, according to 'man errno', is EDEADLK. To be honest, I have no idea why gmirror might be returning this error. ... no error report from the hard drives, simply an error report from the mirror. Note that ahci(4) does not log errors unless you're running with bootverbose. The filesystem is ufs with su+j... but I'm not sure this matters here. It does, kind of - without soft updates/SUJ, the error would be non-fatal - it wouldn't panic the box, but it would (probably) cause data corruption. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Lost CAM Access to DVD Writer
I guess this one did not make it back from USENET to gateway I just tried to write to a DVD using both a PC running 9.2-RC3-p0 and 9.2-STABLE r255036 on different computers and get the following error on both computers when a blank is inserted: Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): CAM status: SCSI Status Error Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI status: Check Condition Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): Error 6, Unretryable error Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): cddone: got error 0x6 back Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): READ(10). CDB: 28 00 00 00 00 00 00 00 01 00 I tried a new DVD drive in both computers. One is a i386 with PATA interface and the other is an AMD with SATA. Both computers have the GENERIC kernel loaded. I also tried using new DVD's of both +R -R and a CD in the drives with the same result. When I try to write to a DVD or CD, I get the following message: :-( Unable to CAMGETPASSTHRU for /dev/cd0 Inappropriate ioctl for device. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: gmirror crash writing to disk? Or is it su+j crash?
On Fri, 2013-08-30 at 21:50 +0200, Edward Tomasz Napierała wrote: Wiadomość napisana przez Zaphod Beeblebrox zbee...@gmail.com w dniu 29 sie 2013, o godz. 23:35: So I have a system running: FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 03:02:55 EDT 2013 r...@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 and it has two 2T SATA disks. To keep this post short, the crash.txt is here. https://uk.eicat.ca/owncloud/public.php?service=filest=fea9d25579fe0c4afb808859e80e1493 Login error. now curiously, while running a make -j4 buildkernel ... almost every time ... it crashes with: g_vfs_done():mirror/walke[WRITE(offset=516764794880, length=65536)]error = 11 /usr: got error 11 while accessing filesystem panic: softdep_deallocate_dependencies: unrecovered I/O error This is softupdates panic caused by write operation returning error 11, which, according to 'man errno', is EDEADLK. To be honest, I have no idea why gmirror might be returning this error. ... no error report from the hard drives, simply an error report from the mirror. Note that ahci(4) does not log errors unless you're running with bootverbose. The filesystem is ufs with su+j... but I'm not sure this matters here. It does, kind of - without soft updates/SUJ, the error would be non-fatal - it wouldn't panic the box, but it would (probably) cause data corruption. One of the few places in the kernel that uses EDEADLK is in geom_io.c (line 642 in -current) in g_io_transient_map_bio()... g_io_deliver(bp, EDEADLK/* XXXKIB */); -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: gmirror crash writing to disk? Or is it su+j crash?
My bad. New link for the core.txt.4: https://uk.eicat.ca/owncloud/public.php?service=filest=f471e5afae483342cd20dc390e9c2dd7 On Fri, Aug 30, 2013 at 4:51 PM, Ian Lepore i...@freebsd.org wrote: On Fri, 2013-08-30 at 21:50 +0200, Edward Tomasz Napierała wrote: Wiadomość napisana przez Zaphod Beeblebrox zbee...@gmail.com w dniu 29 sie 2013, o godz. 23:35: So I have a system running: FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 03:02:55 EDT 2013 r...@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 and it has two 2T SATA disks. To keep this post short, the crash.txt is here. https://uk.eicat.ca/owncloud/public.php?service=filest=fea9d25579fe0c4afb808859e80e1493 Login error. now curiously, while running a make -j4 buildkernel ... almost every time ... it crashes with: g_vfs_done():mirror/walke[WRITE(offset=516764794880, length=65536)]error = 11 /usr: got error 11 while accessing filesystem panic: softdep_deallocate_dependencies: unrecovered I/O error This is softupdates panic caused by write operation returning error 11, which, according to 'man errno', is EDEADLK. To be honest, I have no idea why gmirror might be returning this error. ... no error report from the hard drives, simply an error report from the mirror. Note that ahci(4) does not log errors unless you're running with bootverbose. The filesystem is ufs with su+j... but I'm not sure this matters here. It does, kind of - without soft updates/SUJ, the error would be non-fatal - it wouldn't panic the box, but it would (probably) cause data corruption. One of the few places in the kernel that uses EDEADLK is in geom_io.c (line 642 in -current) in g_io_transient_map_bio()... g_io_deliver(bp, EDEADLK/* XXXKIB */); -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: gmirror crash writing to disk? Or is it su+j crash?
Because someone said that there would be no logging of unerlying ATA errors without verbose, I rebooted with verbose and tried the same make -j4 again... and here is the relatively similar core.txt.5 https://uk.eicat.ca/owncloud/public.php?service=filest=d99648ef5876b91c5957148445e60c87 Looking at it, gmirror is dropping the same error and the underlying hardware is not causing the error... On Fri, Aug 30, 2013 at 6:09 PM, Zaphod Beeblebrox zbee...@gmail.comwrote: My bad. New link for the core.txt.4: https://uk.eicat.ca/owncloud/public.php?service=filest=f471e5afae483342cd20dc390e9c2dd7 On Fri, Aug 30, 2013 at 4:51 PM, Ian Lepore i...@freebsd.org wrote: On Fri, 2013-08-30 at 21:50 +0200, Edward Tomasz Napierała wrote: Wiadomość napisana przez Zaphod Beeblebrox zbee...@gmail.com w dniu 29 sie 2013, o godz. 23:35: So I have a system running: FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 03:02:55 EDT 2013 r...@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386 and it has two 2T SATA disks. To keep this post short, the crash.txt is here. https://uk.eicat.ca/owncloud/public.php?service=filest=fea9d25579fe0c4afb808859e80e1493 Login error. now curiously, while running a make -j4 buildkernel ... almost every time ... it crashes with: g_vfs_done():mirror/walke[WRITE(offset=516764794880, length=65536)]error = 11 /usr: got error 11 while accessing filesystem panic: softdep_deallocate_dependencies: unrecovered I/O error This is softupdates panic caused by write operation returning error 11, which, according to 'man errno', is EDEADLK. To be honest, I have no idea why gmirror might be returning this error. ... no error report from the hard drives, simply an error report from the mirror. Note that ahci(4) does not log errors unless you're running with bootverbose. The filesystem is ufs with su+j... but I'm not sure this matters here. It does, kind of - without soft updates/SUJ, the error would be non-fatal - it wouldn't panic the box, but it would (probably) cause data corruption. One of the few places in the kernel that uses EDEADLK is in geom_io.c (line 642 in -current) in g_io_transient_map_bio()... g_io_deliver(bp, EDEADLK/* XXXKIB */); -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Lost CAM Access to DVD Writer
On Fri, Aug 30, 2013 at 15:36:23 -0400, Thomas Laus wrote: I guess this one did not make it back from USENET to gateway I just tried to write to a DVD using both a PC running 9.2-RC3-p0 and 9.2-STABLE r255036 on different computers and get the following error on both computers when a blank is inserted: Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): CAM status: SCSI Status Error Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI status: Check Condition Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): Error 6, Unretryable error Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): cddone: got error 0x6 back Aug 30 11:04:41 shack kernel: (cd0:ata3:0:0:0): READ(10). CDB: 28 00 00 00 00 00 00 00 01 00 I tried a new DVD drive in both computers. One is a i386 with PATA interface and the other is an AMD with SATA. Both computers have the GENERIC kernel loaded. I also tried using new DVD's of both +R -R and a CD in the drives with the same result. When I try to write to a DVD or CD, I get the following message: :-( Unable to CAMGETPASSTHRU for /dev/cd0 Inappropriate ioctl for device. You probably need to recompile whatever application you're using to burn CDs. Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
