Can't use gpt labels re-importing pool
I just upgraded from 7.2 to 8.0. Under 7.2 the pool was like : NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad6p1 ONLINE 0 0 0 ad10p1 ONLINE 0 0 0 ad8p1 ONLINE 0 0 0 ad4p1 ONLINE 0 0 0 I'd like to use gpt labels or gptids reimporting the pool. # ls /dev/gpt disk1 disk2 disk3 disk4 # ls /dev/gptid 0902db4e-d462-11de-96bd-001d923bc7a0 9fb111f8-d426-11de-99bc-001d923bc7a0 1be29091-d9dc-11de-9f4a-001d923bc7a0 ffb4e96a-d497-11de-96bd-001d923bc7a0 I did # zpool import -d /dev/gpt tank and I got tank ONLINE raidz1 ONLINE ada1p1 ONLINE ada3p1 ONLINE ada2p1 ONLINE gpt/disk4 ONLINE Now, how to force zpool import to only use gpt labels (or uuids) ? Or at least get back to coherent situation ( zpool export tank / zpool import gives the same now. and zpool import -d /dev, as zpool import -d /dev/gptid gives nothing ) ? Thanks in advance. Arnaud ___ 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: Can't use gpt labels re-importing pool
On 11/26/09, Arnaud Houdelette arnaud.houdele...@tzim.net wrote: I just upgraded from 7.2 to 8.0. Under 7.2 the pool was like : NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad6p1 ONLINE 0 0 0 ad10p1 ONLINE 0 0 0 ad8p1 ONLINE 0 0 0 ad4p1 ONLINE 0 0 0 I'd like to use gpt labels or gptids reimporting the pool. # ls /dev/gpt disk1 disk2 disk3 disk4 # ls /dev/gptid 0902db4e-d462-11de-96bd-001d923bc7a0 9fb111f8-d426-11de-99bc-001d923bc7a0 1be29091-d9dc-11de-9f4a-001d923bc7a0 ffb4e96a-d497-11de-96bd-001d923bc7a0 I did # zpool import -d /dev/gpt tank and I got tank ONLINE raidz1 ONLINE ada1p1 ONLINE ada3p1 ONLINE ada2p1 ONLINE gpt/disk4 ONLINE Now, how to force zpool import to only use gpt labels (or uuids) ? Or at least get back to coherent situation ( zpool export tank / zpool import gives the same now. and zpool import -d /dev, as zpool import -d /dev/gptid gives nothing ) ? Use 'zpool replace' to change the zfs pool to use the gpt names: zpool replace tank ada1p1 gpt/disk1 zpool replace tank ada2p1 gpt/disk2 zpool replace tank ada3p1 gpt/disk3 NOTE: make sure you use the correct gpt names for each partition, as the above assumes that ada1p1 is labeled as disk1. Scot ___ 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: Can't use gpt labels re-importing pool
On Thu, Nov 26, 2009 at 02:40:17AM -0600, Scot Hetzel wrote: On 11/26/09, Arnaud Houdelette arnaud.houdele...@tzim.net wrote: I just upgraded from 7.2 to 8.0. Under 7.2 the pool was like : NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad6p1 ONLINE 0 0 0 ad10p1 ONLINE 0 0 0 ad8p1 ONLINE 0 0 0 ad4p1 ONLINE 0 0 0 I'd like to use gpt labels or gptids reimporting the pool. # ls /dev/gpt disk1 disk2 disk3 disk4 # ls /dev/gptid 0902db4e-d462-11de-96bd-001d923bc7a0 9fb111f8-d426-11de-99bc-001d923bc7a0 1be29091-d9dc-11de-9f4a-001d923bc7a0 ffb4e96a-d497-11de-96bd-001d923bc7a0 I did # zpool import -d /dev/gpt tank and I got tank ONLINE raidz1 ONLINE ada1p1 ONLINE ada3p1 ONLINE ada2p1 ONLINE gpt/disk4 ONLINE Now, how to force zpool import to only use gpt labels (or uuids) ? Or at least get back to coherent situation ( zpool export tank / zpool import gives the same now. and zpool import -d /dev, as zpool import -d /dev/gptid gives nothing ) ? Use 'zpool replace' to change the zfs pool to use the gpt names: zpool replace tank ada1p1 gpt/disk1 zpool replace tank ada2p1 gpt/disk2 zpool replace tank ada3p1 gpt/disk3 NOTE: make sure you use the correct gpt names for each partition, as the above assumes that ada1p1 is labeled as disk1. I'm a bit curious about something, so maybe someone can help me understand: Why are people bothering with GPT labels (or in some cases, glabels) when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what circumstance would the device name change dynamically in this situation? I've never witnessed this happening with AHCI, at least on Intel systems, and I've hot-swapped hard disks many times over. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: how to disable APM using camcontrol cmd
Denis Shaposhnikov wrote: I'm trying to replace sysutils/ataidle which doesn't work with new acpi(4). May be somebody could tell me args for camcontrol cmd ada0 -a cmd XX XX XX XX XX XX XX XX to disable APM and acoustic management (AAM) for my HDD? To set APM level: camcontrol cmd ada0 -a EF 05 00 00 00 00 00 00 00 00 xx 00 To disable it: camcontrol cmd ada0 -a EF 85 00 00 00 00 00 00 00 00 00 00 To set AAM level: camcontrol cmd ada0 -a EF 42 00 00 00 00 00 00 00 00 xx 00 To disable it: camcontrol cmd ada0 -a EF C2 00 00 00 00 00 00 00 00 00 00 You can check result with: camcontrol identify ada0 -- Alexander Motin ___ 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: 8.0-RC USB/FS problem
On Thursday 26 November 2009 08:30:52 Guojun Jin wrote: Most crash had the same back trace. This is also true when USB access hangs, then unplug the drive. I think from the backtrace that this is not an USB issue. It is a file-system issue. --HPS ___ 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: Can't use gpt labels re-importing pool
On Thu, Nov 26, 2009 at 8:50 AM, Jeremy Chadwick free...@jdc.parodius.comwrote: I'm a bit curious about something, so maybe someone can help me understand: Why are people bothering with GPT labels (or in some cases, glabels) when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what circumstance would the device name change dynamically in this situation? I've never witnessed this happening with AHCI, at least on Intel systems, and I've hot-swapped hard disks many times over. My home server has 6 x ICH10 SATA ports using ahci(4), and 2 x SiL 3128 SATA ports using siis(4). When I first set it up, I created a raidz pool using MBR/BSD slices/partitions on the drives on the ahci controllers, (ie zpool create tank raidz ada[0-5]s1d). I then shutdown, connected a couple of drives to the siis controller, and booted up again. This caused the pool to fail to be imported, as the drives on siis came up as ada0 and ada1. I then wiped out the pool, and restarted the install, but this time using GPT partitioning and labelling each partition that I use. Now I can connect my drives on any interface, any order and it works correctly, always. I also get a nice label for each drive that I can scribble on the drive cage, and I can tell exactly what physical device is referred to by a label. The only cost to this was having to remember to label the drives - well worth it imo. Cheers Tom ___ 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: how to disable APM using camcontrol cmd
Hello, On Thu, 26 Nov 2009 11:09:05 +0200 Alexander Motin m...@freebsd.org wrote: To set APM level: camcontrol cmd ada0 -a EF 05 00 00 00 00 00 00 00 00 xx 00 To disable it: camcontrol cmd ada0 -a EF 85 00 00 00 00 00 00 00 00 00 00 Yes, it works! Thank you very much! ___ 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: Can't use gpt labels re-importing pool
On 11/26/09, Jeremy Chadwick free...@jdc.parodius.com wrote: I'm a bit curious about something, so maybe someone can help me understand: Why are people bothering with GPT labels (or in some cases, glabels) when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what circumstance would the device name change dynamically in this situation? There was a thread about this problem where the drives had changed their device names due to a change in the kernel drive (Current list from July): http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009377.html Through out this thread there were various suggests on how he could recover the system, and prevent the problem from occurring in the future. One of the suggestions was that use of zpool replace to change from device names to using glabel labels. http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009440.html I've never witnessed this happening with AHCI, at least on Intel systems, and I've hot-swapped hard disks many times over. Using glabels, gpt labels, or gptid solves the problem of not needing to remember which device name the drive originally had. For instance, on a zfs zraid pool with 3 disks (ad1 ad2 ad3) you could disconnect the pool from one computer and connect it to another system and it wouldn't matter which order you reconnected the drives (1 2 3 or 3 1 2) as the pool would still be recognized when it is imported on the new system. Also if the new system already has drives ad1 and ad2, it wouldn't matter. Scot ___ 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: Can't use gpt labels re-importing pool
Scot Hetzel wrote: On 11/26/09, Arnaud Houdelette arnaud.houdele...@tzim.net wrote: Scot Hetzel wrote: On 11/26/09, Arnaud Houdelette arnaud.houdele...@tzim.net wrote: I just upgraded from 7.2 to 8.0. Under 7.2 the pool was like : NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad6p1 ONLINE 0 0 0 ad10p1 ONLINE 0 0 0 ad8p1 ONLINE 0 0 0 ad4p1 ONLINE 0 0 0 I'd like to use gpt labels or gptids reimporting the pool. # ls /dev/gpt disk1 disk2 disk3 disk4 # ls /dev/gptid 0902db4e-d462-11de-96bd-001d923bc7a0 9fb111f8-d426-11de-99bc-001d923bc7a0 1be29091-d9dc-11de-9f4a-001d923bc7a0 ffb4e96a-d497-11de-96bd-001d923bc7a0 I did # zpool import -d /dev/gpt tank and I got tank ONLINE raidz1 ONLINE ada1p1 ONLINE ada3p1 ONLINE ada2p1 ONLINE gpt/disk4 ONLINE Now, how to force zpool import to only use gpt labels (or uuids) ? Or at least get back to coherent situation ( zpool export tank / zpool import gives the same now. and zpool import -d /dev, as zpool import -d /dev/gptid gives nothing ) ? Use 'zpool replace' to change the zfs pool to use the gpt names: zpool replace tank ada1p1 gpt/disk1 zpool replace tank ada2p1 gpt/disk2 zpool replace tank ada3p1 gpt/disk3 NOTE: make sure you use the correct gpt names for each partition, as the above assumes that ada1p1 is labeled as disk1. Scot Mmmh, zpool replace will resilver the drive, won't it ? Yes, it will resilver the drive, but it shouldn't take as long as it will recognize that it is the same drive. Just wait for the resilver process to finish before changing the next drive. Moreover, I can't use replace as when adaXp1 is used, the corresponding /dev/gpt entry disapears. Unless you mean that I can use replace before import ? There was a discussion about this back in July: http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009440.html In that discussion, they had used glabel to label each drive, and then use zpool replace on the active pool to change it to use the label. Just make sure that you use the gpt name that you assigned to ada1p1, when replacing it. Scot That does not work or there's something I'm doing wrong. # uname -a FreeBSD carenath.tzim.net 8.0-RELEASE FreeBSD 8.0-RELEASE #26: Wed Nov 25 23:43:22 CET 2009 t...@carenath.tzim.net:/usr/obj/usr/src/sys/CARENATH amd64 As I said, the label is not present in /dev/gpt while used with adaXp1 ( here ada1p1 has label HD753LJ-1) : # ls /dev/gpt HD753LJ-4 zfs-boot # zpool replace tank ada1p1 gpt/HD753LJ-1 cannot open 'gpt/HD753LJ-1': no such GEOM provider If I offline the drive first, I get another error : # zpool offline tank ada1p1 # zpool replace tank ada1p1 gpt/HD753LJ-1 invalid vdev specification use '-f' to override the following errors: /dev/gpt/HD753LJ-1 is part of active pool 'tank' # zpool replace -f tank ada1p1 gpt/HD753LJ-1 invalid vdev specification the following errors must be manually repaired: /dev/gpt/HD753LJ-1 is part of active pool 'tank' I know there is the solution of cleaning the disk and resilvering, but if I could avoid this ? Arnaud ___ 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: Can't use gpt labels re-importing pool
On Thu, Nov 26, 2009 at 5:29 PM, Scot Hetzel swhet...@gmail.com wrote: On 11/26/09, Jeremy Chadwick free...@jdc.parodius.com wrote: I'm a bit curious about something, so maybe someone can help me understand: Why are people bothering with GPT labels (or in some cases, glabels) when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what circumstance would the device name change dynamically in this situation? There was a thread about this problem where the drives had changed their device names due to a change in the kernel drive (Current list from July): http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009377.html Through out this thread there were various suggests on how he could recover the system, and prevent the problem from occurring in the future. One of the suggestions was that use of zpool replace to change from device names to using glabel labels. http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009440.html I've never witnessed this happening with AHCI, at least on Intel systems, and I've hot-swapped hard disks many times over. Using glabels, gpt labels, or gptid solves the problem of not needing to remember which device name the drive originally had. For instance, on a zfs zraid pool with 3 disks (ad1 ad2 ad3) you could disconnect the pool from one computer and connect it to another system and it wouldn't matter which order you reconnected the drives (1 2 3 or 3 1 2) as the pool would still be recognized when it is imported on the new system. Also if the new system already has drives ad1 and ad2, it wouldn't matter. Scot for some reasons it sounds to me like 'avoiding problem' since device name shouldn't matter in zfs (or so I read) -- O ascii ribbon campaign - stop html mail - www.asciiribbon.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: Can't use gpt labels re-importing pool
According to Arnaud Houdelette: As I said, the label is not present in /dev/gpt while used with adaXp1 ( here ada1p1 has label HD753LJ-1) : # ls /dev/gpt HD753LJ-4 zfs-boot # zpool replace tank ada1p1 gpt/HD753LJ-1 cannot open 'gpt/HD753LJ-1': no such GEOM provider I know there is the solution of cleaning the disk and resilvering, but if I could avoid this ? Do you load glabel in loader.conf? I think that in order to be able to use GPT labels in GEOM (and thus ZFS), you set them with gpart, glabel will load them in the kernel and you then can use them for zfs. I recently moved from ata to ahci and wanted to use labels for the swap partitions. So I added a label to my swap partitions with gpart, they got recognized by geom thru glabel and I was able to use /dev/gpt/swapN instead of the usual /dev/adNp2 that were there before. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ ___ 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: Can't use gpt labels re-importing pool
Edho P Arief wrote: for some reasons it sounds to me like 'avoiding problem' since device name shouldn't matter in zfs (or so I read) Theoretically, you should be right, but the details are still fuzzy. At the very least, the sequence zpool export - shuffle drives around - zpool import should work without problems, though ZFS might pick up different drive names if multiple labels are present; for example if using partitions, some of the drives in the pool could be imported as adXp1 and others as gptid/... so a manual intervention might be needed to keep things consistent. ___ 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: Can't use gpt labels re-importing pool
Jeremy Chadwick wrote: Why are people bothering with GPT labels (or in some cases, glabels) when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what circumstance would the device name change dynamically in this situation? I've never witnessed this happening with AHCI, at least on Intel systems, and I've hot-swapped hard disks many times over. It isn't specific to AHCI, but this is where most people encountered it first. The issue in question is how to make ZFS survive drive renaming for any cause - driver change, controller change, drive shuffling, etc. In general, ZFS will taste individual drives on zpool import so will try to do the right thing, but it might pick up different labels for different drives, etc. Using glabel tricks simply makes the naming a bit more consistent. ___ 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: Can't use gpt labels re-importing pool
On Nov 26, 2009, at 1:56 PM, Ivan Voras wrote: Jeremy Chadwick wrote: Why are people bothering with GPT labels (or in some cases, glabels) when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what circumstance would the device name change dynamically in this situation? I've never witnessed this happening with AHCI, at least on Intel systems, and I've hot-swapped hard disks many times over. It isn't specific to AHCI, but this is where most people encountered it first. The issue in question is how to make ZFS survive drive renaming for any cause - driver change, controller change, drive shuffling, etc. In general, ZFS will taste individual drives on zpool import so will try to do the right thing, but it might pick up different labels for different drives, etc. Using glabel tricks simply makes the naming a bit more consistent. What about zpool import -d /dev/gpt/ ? Though last time I tried this it refused to work for some reason. Regards, Niki Denev ___ 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
atacontrol spindown equivalent for ahci/ada
Is there a equivalent command (camcontrol something ... ?) to atacontrol spindown when using ahci(4) ? I'd like to continue using this feature to reduce power consumption during night hours. Arnaud ___ 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: Can't use gpt labels re-importing pool
On Thu, Nov 26, 2009 at 12:56:50PM +0100, Ivan Voras wrote: Jeremy Chadwick wrote: Why are people bothering with GPT labels (or in some cases, glabels) when AHCI (whether it be ataahci.ko or ahci.ko) is in use? Under what circumstance would the device name change dynamically in this situation? I've never witnessed this happening with AHCI, at least on Intel systems, and I've hot-swapped hard disks many times over. It isn't specific to AHCI, but this is where most people encountered it first. The issue in question is how to make ZFS survive drive renaming for any cause - driver change, controller change, drive shuffling, etc. In general, ZFS will taste individual drives on zpool import so will try to do the right thing, but it might pick up different labels for different drives, etc. Using glabel tricks simply makes the naming a bit more consistent. What I'm having trouble understanding is where the more consistent concept comes from. I guess it ultimately depends on one's system configuration. For example: Tom Evans' situation greatly benefits from use of labels, since his configuration consists of 1) multiple SATA controllers, and 2) moving drives around between different controllers. This isn't going to happen in most production server environments, where the there is a static number of disks and (usually) a single controller. This is the situation I was referring to; environment or configuration would have been a more accurate choice of word. On 4-disk Supermicro systems (Intel ICHx + AHCI based, with hot-swap drive bays, with FreeBSD 7.x/8.x and ataahci), depending on what ICHx ports the drives are plugged into, your drive bays/disks are going to be static/consistent. SATA port #0 = ad4, SATA port #1 = ad6, and so on. These won't change unless you do something like, say, disable a SATA port or disable AHCI mode in the BIOS. Regardless, I'm almost certain I've made the mistake on a 4-disk system of doing (physical) system cleaning, which involves dusting out all of the bays and so on -- and ended up inserting a drive/carrier/disk into a bay which it wasn't part of prior to the shutdown. zpool import took care of things for me. If someone wants me to validate my own memory (the more I work Grave shift the more I find my memory failing me...), I'd be more than happy to spend a weekend messing around moving disks + reporting back what the behaviour is on RELENG_8. I have a spare 5-disk (6 ports) system which can be used for this purpose (Supermicro X7SBA + 5 disks). I spend most of my time messing around with disks at my night job as is... :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: atacontrol spindown equivalent for ahci/ada
Arnaud Houdelette wrote: Is there a equivalent command (camcontrol something ... ?) to atacontrol spindown when using ahci(4) ? I'd like to continue using this feature to reduce power consumption during night hours. Arnaud ___ 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 someone even wrote a script. Search the OpenBSD archives ___ 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: atacontrol spindown equivalent for ahci/ada
Hello, On Thu, 26 Nov 2009 14:45:17 +0100 Arnaud Houdelette arnaud.houdele...@tzim.net wrote: Is there a equivalent command (camcontrol something ... ?) to atacontrol spindown when using ahci(4) ? camcontrol standby works for me. It stops my HDD. ___ 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
8.0 kernel fails to build if some USB drivers are trimmed out; error in /sys/conf/files
Happy Thanksgiving to everyone in the US (and elsewhere as well)! I encountered a strange bug when I was trimming the GENERIC FreeBSD RELEASE-8.0 kernel to omit drivers for hardware that would not be used on one target platform. I removed all of the USB Ethernet drivers except for udav (Davicom USB Ethernet) and tried to rebuild the kernel. The build stopped at the point where the kernel was linked, reporting undefined references in the file /sys/usb/net/if_udav.c to uether_pause, uether_ifdetach, uether_getmii, and other routines with similar names. I discovered that these functions are defined in the file usb_ethernet.c, which is in the same directory as if_udav.c. A look at the file /usr/src/sys/i386/compile/KERNELNAME/Makefile showed that usb_ethernet.o was missing from the list of object files in the variable OBJS. Because the Makefile wasn't properly triggering the compilation of usb_ethernet.c or including usb_ethernet.o in the list of files to be linked, the build was aborting at link time due to the unresolved references. After a bit of research (I am admittedly unfamiliar with all of the details of the kernel build system), it appears to me that this problem is the result of the use of parentheses on line 1623 of the file /sys/conf/files. This is the only place in any of the kernel dependency metadata where parentheses are used around a list of driver names, and removing them seems to solve the problem. More experimentation seems to indicate that the GENERIC kernel builds by sheer luck, due to an odd quirk in the config utility. The utility happens to do the right thing when at least one of the drivers in the middle of the parenthesized list (that is, not the first or last) is included in the kernel, as is true in GENERIC. This masks the bug. But the config utility produces an incorrect list of dependencies when none of the drivers in the middle of the parenthesized list is included in the kernel. I'll leave it to the committers to decide whether it is better to make the config utility handle parentheses correctly, or simply to make sure that no parentheses are used in the kernel dependency metadata. I've submitted this bug as PR 140904. ___ 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: 8.0 kernel fails to build if some USB drivers are trimmed out; error in /sys/conf/files
On Thu, Nov 26, 2009 at 10:43:13AM -0700, Brett Glass wrote: I encountered a strange bug when I was trimming the GENERIC FreeBSD RELEASE-8.0 kernel to omit drivers for hardware that would not be used on one target platform. I removed all of the USB Ethernet drivers except for udav (Davicom USB Ethernet) and tried to rebuild the kernel. The build stopped at the point where the kernel was linked, reporting undefined references in the file /sys/usb/net/if_udav.c to uether_pause, uether_ifdetach, uether_getmii, and other routines with similar names. I discovered that these functions are defined in the file usb_ethernet.c, which is in the same directory as if_udav.c. Missing symbols are almost always the sign of a missing device directive inside of the kernel configuration file. In this case, they're part of sys/dev/usb/net/usb_ethernet.[ch], which should be being built. You absolutely need to include the following devices in addition to device udav: device ether device miibus I assume you did leave device usb and related pieces (meaning lines around that area) intact. Keeping it simple: can we see your kernel configuration file in its entirety? It isn't included in the PR, nor in this Email. More experimentation seems to indicate that the GENERIC kernel builds by sheer luck, due to an odd quirk in the config utility. I haven't used config since the early 3.x days. I'm certain make buildkernel and friends relies on it, but configuring a kernel + building a kernel is a lot simpler now. Read /usr/src/Makefile, starting with the line For individuals wanting to upgrade their sources. The steps there are accurate. I don't think parenthesis are the core of the problem, given that there are many other devices in /sys/conf/files which utilise said method. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: 8.0 kernel fails to build if some USB drivers are trimmed out; error in /sys/conf/files
On 11/26/09, Jeremy Chadwick free...@jdc.parodius.com wrote: I don't think parenthesis are the core of the problem, given that there are many other devices in /sys/conf/files which utilise said method. There are only 2 places in the /sys/conf/files which use this method, and both of them are for usb drivers: # USB ethernet drivers # dev/usb/net/if_aue.coptional aue dev/usb/net/if_axe.coptional axe dev/usb/net/if_cdce.c optional cdce dev/usb/net/if_cue.coptional cue dev/usb/net/if_kue.coptional kue dev/usb/net/if_rue.coptional rue dev/usb/net/if_udav.c optional udav dev/usb/net/usb_ethernet.c \ optional (aue | axe | cdce | cue | kue | rue | udav) : # USB serial and parallel port drivers # dev/usb/serial/u3g.coptional u3g dev/usb/serial/uark.c optional uark dev/usb/serial/ubsa.c optional ubsa dev/usb/serial/ubser.c optional ubser dev/usb/serial/uchcom.c optional uchcom dev/usb/serial/ucycom.c optional ucycom dev/usb/serial/ufoma.c optional ufoma dev/usb/serial/uftdi.c optional uftdi dev/usb/serial/ugensa.c optional ugensa dev/usb/serial/uipaq.c optional uipaq dev/usb/serial/ulpt.c optional ulpt dev/usb/serial/umct.c optional umct dev/usb/serial/umodem.c optional umodem dev/usb/serial/umoscom.coptional umoscom dev/usb/serial/uplcom.c optional uplcom dev/usb/serial/uslcom.c optional uslcom dev/usb/serial/uvisor.c optional uvisor dev/usb/serial/uvscom.c optional uvscom dev/usb/serial/usb_serial.c optional ucom | \ (u3g | uark | ubsa | ubser | uchcom | ucycom | ufoma | uftdi | ugensa | uipaq | ulpt | umct | umodem | umoscom | uplcom | uslcom | uvisor | uvscom) It would be interesting if this also breaks for compiling 'USB serial and parallel port drivers' into the kernel. Scot ___ 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: 5.5-STABLE to 88.0-RELEASE
can one go from 5.5 to 8.0 using the normal hammer, or is it multi-stage, and i should just blow it away and go from install? randy It is do able, but you need to rebuild all ports. And to go from 5.5 to 8 it is adviced to go trough all major version, like 6 and 7 and then go to 8. So my take is, backup all your data, and config files and do a reinstall. This way you make sure there are no un needed libs and old stuff laying around which can clobber your system. Regards, Johan Hendriks ___ 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: 8.0-RC USB/FS problem
Shall I fill a defect? or someone on this mailing list can take care of this problem before release. -Jin -Original Message- From: Hans Petter Selasky [mailto:hsela...@c2i.net] Sent: Thu 11/26/2009 12:20 AM To: Guojun Jin Cc: freebsd-...@freebsd.org; b...@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Thursday 26 November 2009 08:30:52 Guojun Jin wrote: Most crash had the same back trace. This is also true when USB access hangs, then unplug the drive. I think from the backtrace that this is not an USB issue. It is a file-system issue. --HPS ___ 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: 8.0-RC USB/FS problem
On Nov 26, 2009, at 8:25 PM, Guojun Jin wrote: Shall I fill a defect? or someone on this mailing list can take care of this problem before release. -Jin 8.0 is halfway out already, you can download -RELEASE ISOs or upgrade using freebsd-update. The main announcement just hasn't been made yet. Regards, Thomas___ 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: 8.0-R USB/FS problem
Be clear, the recent (last 5 days) tests are based on -RELEASE made on 21st, not RC any more, so I changed title now. Since this problem occurs on multiple machines (not just single one), with different USB drives, so I would like this to be fixed before the formal release if possible. -Original Message- From: Thomas Backman [mailto:seren...@exscape.org] Sent: Thu 11/26/2009 11:48 AM To: Guojun Jin Cc: Hans Petter Selasky; b...@freebsd.org; freebsd-stable; freebsd-...@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Nov 26, 2009, at 8:25 PM, Guojun Jin wrote: Shall I fill a defect? or someone on this mailing list can take care of this problem before release. -Jin 8.0 is halfway out already, you can download -RELEASE ISOs or upgrade using freebsd-update. The main announcement just hasn't been made yet. Regards, Thomas ___ 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: 5.5-STABLE to 88.0-RELEASE
Johan Hendriks wrote: can one go from 5.5 to 8.0 using the normal hammer, or is it multi-stage, and i should just blow it away and go from install? randy It is do able, but you need to rebuild all ports. And to go from 5.5 to 8 it is adviced to go trough all major version, like 6 and 7 and then go to 8. So my take is, backup all your data, and config files and do a reinstall. This way you make sure there are no un needed libs and old stuff laying around which can clobber your system. Regards, Johan Hendriks ___ 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 I believe you'll have to wait quite some time for 88.0. ;) A lot of config files have changed since 5.5. Some have been added and some have been removed and others been changed in various ways. I'd suggest either removing all ports, then going through the 5.5 - 6.0 - 7.0 - 8.0 and be sure to run the mergemaster, make delete-old, make delete-old-libs at each stage and finally install the ports you need or back up your data (not the config files), do a fresh install of 8.0 and configure from scratch, restore the data, install the ports you need. I may be paranoid suggesting this, and others may disagree with me, however I've had problems caused by config files changing after upgrading. Good Luck, Rolf Nielsen ___ 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: 5.5-STABLE to 88.0-RELEASE
I'd suggest either removing all ports, then going through the 5.5 - 6.0 - 7.0 - 8.0 and be sure to run the mergemaster, make delete-old, make delete-old-libs at each stage and finally install the ports you need or back up your data (not the config files) no thanks. too much of a mess, and very little on the system that i really need. it's just that it is remote. but i'll visit and install perhaps the section labeled To upgrade in-place from 5.x-stable to current should be edited or removed from /usr/src/UPDATING. :) thanks all randy ___ 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: 5.5-STABLE to 88.0-RELEASE
On Fri, Nov 27, 2009 at 05:43:23AM +0900, Randy Bush wrote: [... suggestions and advise upgrading 5.5 to 88^H ...] perhaps the section labeled To upgrade in-place from 5.x-stable to current should be edited or removed from /usr/src/UPDATING. :) That's something I found curious as well. ;-) My vote would be to update it to the previous version or 7.x, whichever is most accurate and/or fits best. If 5.x is accurate, forgive me for sending this email. -- If you continually give, you will continually have. - www.chinese-fortune-cookie.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: Panic possibly related to glabel/geom and siis(4)
This is similar to what I have fight on last two weeks (was 8.0-RC USB/FS). My back trace from the panic is some different from yours, but the behave is the same. When access USB drives from 8.0-RC and 8.0-R will cause drives dead, vanish or reset, thus causing panic. From both cases, it looks like a hotplug/automount related problem. --- On Tue, 11/24/09, Steve Polyack kor...@comcast.net wrote: From: Steve Polyack kor...@comcast.net Subject: Panic possibly related to glabel/geom and siis(4) To: freebsd-hardw...@freebsd.org, freebsd-stable freebsd-stable@FreeBSD.org, freebsd-g...@freebsd.org Date: Tuesday, November 24, 2009, 5:40 PM I have a system running 8.0-PRERELEASE with multiple drives and SATA port multipliers (siis controllers and PMPs). All of the attached drives are labeled via glabel(8) and then included into a ZFS pool. During some testing to determine how the system would react to a dead drive (simulated by physically removing a drive during operation), I was able to produce a panic. Now, I know that the SATA PMP and siis(4) code to handle and recover from device errors is incomplete, but I believe the crash may be particular to using glabel'd drives. Basically, after removing a drive while the zpool is in use and issues 'camcontrol reset' and 'rescan' on the appropriate bus, the physical device associated with the drive disappears. In this case: (pass5:siisch7:0:15:0): lost device (pass5:siisch7:0:15:0): removing device entry (ada2:siisch7:0:0:0): lost device and /dev/ada2 disappears. However, the associated glabel /dev/label/bigdisk07 remains. Since my ZFS pool is created based on the drive glabels, I believe this is why ZFS never notices the drives disappear either. Do glabels typically go away after a physical device is lost? Should this not be the case? After some runtime with the physical device missing, a kernel panic is produced: ada2:siisch7:0:0:0): Synchronize cache failed (ada2:siisch7:0:0:0): removing device entry Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 14 fault virtual address = 0x48 fault code = supervisor write data, page not present instruction pointer = 0x20:0x8035f375 stack pointer = 0x28:0xff86db60 frame pointer = 0x28:0xff86db70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2 (g_event) [thread pid 2 tid 100014 ] Stopped at _mtx_lock_flags+0x15: lock cmpxchgq %rsi,0x18(%rdi) db bt Tracing pid 2 tid 100014 td 0xff00014d4ab0 _mtx_lock_flags() at _mtx_lock_flags+0x15 vdev_geom_release() at vdev_geom_release+0x33 vdev_geom_orphan() at vdev_geom_orphan+0x15c g_run_events() at g_run_events+0x104 g_event_procbody() at g_event_procbody+0x55 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff86dd30, rbp = 0 --- I'm open to try patches and other suggestions. Thanks. ___ freebsd-hardw...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to freebsd-hardware-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
8.0-RELEASE completed...
Just a quick note in case there are people here who aren't subscribed to the freebsd-announce@ mailing list. We have completed the 8.0-RELEASE cycle. Details about the release are available from the main web site, in particular the announcement itself is available here: http://www.freebsd.org/releases/8.0R/announce.html Thanks for all the help with testing during the release process, as well as your continued support of FreeBSD. -- Ken Smith - From there to here, from here to | kensm...@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: 8.0-RELEASE completed...
From: Ken Smith kensm...@cse.buffalo.edu Date: Thu, 26 Nov 2009 20:06:23 -0500 Sender: owner-freebsd-sta...@freebsd.org Just a quick note in case there are people here who aren't subscribed to the freebsd-announce@ mailing list. We have completed the 8.0-RELEASE cycle. Details about the release are available from the main web site, in particular the announcement itself is available here: http://www.freebsd.org/releases/8.0R/announce.html Thanks for all the help with testing during the release process, as well as your continued support of FreeBSD. And congratulations and thanks to the entire FreeBSD release engineering team and the contributors. It's a .0 release, but my experience with it through the release cycle has been excellent. I especially appreciate the new USB stack which has fixed all sorts of annoying issues (and a couple that were a lot more than annoying) in the old stack. Great job! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: 8.0-RELEASE completed...
Some questions that I hope are not too far OT:: On Thu, Nov 26, 2009 at 07:06:01PM -0800, Kevin Oberman wrote: From: Ken Smith kensm...@cse.buffalo.edu Date: Thu, 26 Nov 2009 20:06:23 -0500 Sender: owner-freebsd-sta...@freebsd.org Just a quick note in case there are people here who aren't subscribed to the freebsd-announce@ mailing list. We have completed the 8.0-RELEASE cycle. Details about the release are available from the main web site, in particular the announcement itself is available here: http://www.freebsd.org/releases/8.0R/announce.html Thanks for all the help with testing during the release process, as well as your continued support of FreeBSD. And congratulations and thanks to the entire FreeBSD release engineering team and the contributors. It's a .0 release, but my experience with it through the release cycle has been excellent. I especially appreciate the new USB stack which has fixed all sorts of annoying issues (and a couple that were a lot more than annoying) in the old stack. /* I echo Kevin's congrats, of course; it ain't getting any *easier*, certainly. */ Altho I am still some time from having my migration from the 1998 Kayak - 2009 Dell done and working, will it be possible to upgrade my 32bit 7.2-R, p4 to a 64bit 8.0? Even tho i am documenting __everything__, it isn't something I would care to do more than necessary. In going from 32bits to 64, does the filesystem change? My hunch is that it does, but thought I would get that clear as a first step. My Intell duo-core is very fast; would moving to the 64-bit system be a net gain or loss [in performance]. Eventuaaly, I *will* have 64-bit micros, killers or otherwise, :-) ... thanks in advance. Great job! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.netPhone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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 -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix http://jottings.thought.org http://transfinite.thought.org The 7.31a release of Jottings: http://jottings.thought.org/index.php ___ 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: openoffice stuck in _umtx_op
Mikhail T. wrote: I'm trying to start OOo, and it hangs at start-up -- after popping up its banner page. ktrace shows the following, slowly repeating, sequence of events: [...] 32726 soffice.bin CALL _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fbfeef0) 32726 soffice.bin RET _umtx_op -1 errno 60 Operation timed out 32726 soffice.bin CALL gettimeofday(0x7fbfef70,0) 32726 soffice.bin RET gettimeofday 0 32726 soffice.bin CALL clock_gettime(0,0x7fbfef00) 32726 soffice.bin RET clock_gettime 0 32726 soffice.bin CALL _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fbfeef0) 32726 soffice.bin RET _umtx_op -1 errno 60 Operation timed out 32726 soffice.bin CALL gettimeofday(0x7fbfef70,0) 32726 soffice.bin RET gettimeofday 0 32726 soffice.bin CALL clock_gettime(0,0x7fbfef00) 32726 soffice.bin RET clock_gettime 0 32726 soffice.bin CALL _umtx_op(0x805d09060,0x8,0x1,0x805d09040,0x7fbfeef0) [...] what's happening? `ipcs -a' does not show anything extraordinary and there is nothing in syslog either... The machine is running 7.2-STABLE/amd64 (as of Oct 25). Any ideas? Thanks! Mikhail, I don't use OOo on FreeBSD, so I can't help you directly. However, I see similar behaviour on Kubuntu Linux. If I double click on some files that are associated with OOo, I see the splash screen and it hangs forever. If I start OOo from the command line without any parameters, it works correctly - I then open the file from the menu. Maybe that's a workaround for you for now. I haven't seen any bugs on the OOo site that seem to match this. I'll try to get a reproducable case and report it. Graham ___ 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
