Intel H55 and em0
I recently picked up a H55-based motherboard, and the ethernet interface isn't autodetected. dmesg lists it as the following: pci0: network, ethernet at device 25.0 (no driver attached) And pciconf lists this: no...@pci0:0:25:0: class=0x02 card=0x8086 chip=0x10ef8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet I'm actually not sure it's an em device, but it's definitely gigabit, and googling suggests that others have recently run into the same issue. Since I'll probably have to recompile, is this currently working in recent builds of 8.0? This was just a vanilla 8.0 release image. Would some simple change tell the driver to recognize this card? Thanks in advance. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel H55 and em0
The device subfamily on those motherboards is called PCH, and its only in the em driver as of last December, The CVS delta of if_em is 1.27. You can either update to STABLE/8 or CURRENT. If you wish to just pull the e1000 driver directory it should work fine in 8.0 RELEASE also. Cheers, Jack On Wed, Mar 31, 2010 at 11:29 PM, David Ehrmann ehrm...@gmail.com wrote: I recently picked up a H55-based motherboard, and the ethernet interface isn't autodetected. dmesg lists it as the following: pci0: network, ethernet at device 25.0 (no driver attached) And pciconf lists this: no...@pci0:0:25:0: class=0x02 card=0x8086 chip=0x10ef8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet I'm actually not sure it's an em device, but it's definitely gigabit, and googling suggests that others have recently run into the same issue. Since I'll probably have to recompile, is this currently working in recent builds of 8.0? This was just a vanilla 8.0 release image. Would some simple change tell the driver to recognize this card? Thanks in advance. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel H55 and em0
OH, as to my last statement, the code in CURRENT will NOT work on 8.0 RELEASE, it would require a change to sys/conf/files, and it also has a fix in the stack that is not in RELEASE. SO taking the latest would require you take the whole tree. Jack On Wed, Mar 31, 2010 at 11:39 PM, Jack Vogel jfvo...@gmail.com wrote: The device subfamily on those motherboards is called PCH, and its only in the em driver as of last December, The CVS delta of if_em is 1.27. You can either update to STABLE/8 or CURRENT. If you wish to just pull the e1000 driver directory it should work fine in 8.0 RELEASE also. Cheers, Jack On Wed, Mar 31, 2010 at 11:29 PM, David Ehrmann ehrm...@gmail.com wrote: I recently picked up a H55-based motherboard, and the ethernet interface isn't autodetected. dmesg lists it as the following: pci0: network, ethernet at device 25.0 (no driver attached) And pciconf lists this: no...@pci0:0:25:0: class=0x02 card=0x8086 chip=0x10ef8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet I'm actually not sure it's an em device, but it's definitely gigabit, and googling suggests that others have recently run into the same issue. Since I'll probably have to recompile, is this currently working in recent builds of 8.0? This was just a vanilla 8.0 release image. Would some simple change tell the driver to recognize this card? Thanks in advance. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
- Original Message From: Ganbold ganb...@gmail.com To: PseudoCylon moonlightak...@yahoo.ca Cc: freebsd-current@freebsd.org Sent: Wed, March 31, 2010 8:08:29 AM Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless Does stock run(4) support hostap mode yet? No. There were some bugs and I thought I fixed them. So, I called for test. It seems the driver is working on x86, but not on mips. hostap mode should work on your other computer with i386. I'm still working on patch. It panics where there wasn't any changes made. Strange... AK __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
gpart failing with no such geom after gpt corruption
Hello ZFS and GPT hackers :) I'm sending this message to both freebsd-current and freebsd-fs because it doesn't seems to be a CURRENT-specific issue. Yesterday I tried to migrate my mixed UFS/RAIDZ config to clean RAIDZ with GPT boot. I've following mostly this guide: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 I'm using CURRENT on 3x40GB HDDs (ad0-ad3) and additional 250GB HDD has been used for data migration (ad4). Data was copied form RAIDZ to 250GB HDD, GPT sheme was created on 40GB HDDs, then new zpool on them, and finally data went back to RAIDZ. Booting from RAIDZ was succesful, so far so good. After a while I've noticed some SMART errors on ad1, so I've booted machine with seatools for dos and made long test. One bad sector was found and reallocated, nothing to worry about. As I was in seatools already, I've decided to adjust LBA size on that disk (seatools can do that), because it was about 30MB larger than the other two, and because of that I had to adjust size of freebsd-zfs partition on that disk to match exact size of others (otherwise 'zpool create' will complain). So LBA was adjusted and system rebooted. Yes, I was aware that changing disk size probably end with corrupted GPT and data loss, but it doesn't seem to be a big deal for me as far as 2/3 of zpool is alive, because I can always recreate gpt and resilver ad1. Unfortunately it wasn't so easy. First of all system booted, and as I expected kernel message shows GPT error on ad1. Zpool was degraded but alive and kicking. However, when I tried to execute any gpart command on ad1, it return: ad1: no such geom ad1 was present under /dev, and it could be accessed by sysinstall/fdisk, but no with gpart. I've created bsd slice with sysinstall on ad1 and rebooted, with hope that after reboot I could acces ad1 with gpart and recreate GPT scheme. Another surprise - system didn't boot at all, rebooting after couple of seconds in loader (changing boot device didn't make a difference). Only way I could boot system at this moment was connecting 250GB HDD which fortunately still had data from zpool migration and boot from it. Another surprise - kernel was still complaining about GPT corruption on ad1. I had no other ideas so I ran dd if=/dev/zero of=/dev/ad1 bs=512 count=512 to clear beginning of the hdd. After that disk was still unaccesible fromt gpart, so I tried sysinstall/fdisk againt to create standard BSD partitioning scheme and rebooted system. After that finally gpart started to talk with ad1 and GPT scheme and zpool has been recreated and work as it supposed to. Still, how can we clear broken GPT data after it got corrupted? Why gpart has been showing ad1: no such geom, and how can we deal with this problem? Finally, why gptzfsboot failed with GPT corrupted on other disk after trying to fix it, while it booted at first place? Or maybe changing LBA size of already partitioned HDD is extreme case, and the only way these problems could be triggered ;)? Cheers! -- Bartosz Stec ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel H55 and em0
Thanks. I'll give STABLE/8 a try. Jack Vogel wrote: OH, as to my last statement, the code in CURRENT will NOT work on 8.0 RELEASE, it would require a change to sys/conf/files, and it also has a fix in the stack that is not in RELEASE. SO taking the latest would require you take the whole tree. Jack On Wed, Mar 31, 2010 at 11:39 PM, Jack Vogel jfvo...@gmail.com mailto:jfvo...@gmail.com wrote: The device subfamily on those motherboards is called PCH, and its only in the em driver as of last December, The CVS delta of if_em is 1.27. You can either update to STABLE/8 or CURRENT. If you wish to just pull the e1000 driver directory it should work fine in 8.0 RELEASE also. Cheers, Jack On Wed, Mar 31, 2010 at 11:29 PM, David Ehrmann ehrm...@gmail.com mailto:ehrm...@gmail.com wrote: I recently picked up a H55-based motherboard, and the ethernet interface isn't autodetected. dmesg lists it as the following: pci0: network, ethernet at device 25.0 (no driver attached) And pciconf lists this: no...@pci0:0:25:0: class=0x02 card=0x8086 chip=0x10ef8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet I'm actually not sure it's an em device, but it's definitely gigabit, and googling suggests that others have recently run into the same issue. Since I'll probably have to recompile, is this currently working in recent builds of 8.0? This was just a vanilla 8.0 release image. Would some simple change tell the driver to recognize this card? Thanks in advance. ___ freebsd-current@freebsd.org mailto:freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org mailto:freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel H55 and em0
Jack Vogel jfvo...@gmail.com wrote: The device subfamily on those motherboards is called PCH, and its only in the em driver as of last December, The CVS delta of if_em is 1.27. You can either update to STABLE/8 or CURRENT. If you wish to just pull the e1000 driver directory it should work fine in 8.0 RELEASE also. 8-STABLE doesn't work for me. The ethernet device is not recognized, and I get warnings about interrupt storms on irq19 (atapci1), which I don't see with 8-RELEASE. That might be a matter of missing diagnostics in the release kernel (the numbers from 'vmstat -i' seem to suggest this). The board is an Intel DH55HC with an i3-530. Sources for -STABLE checked out this morning; I simply built a GENERIC kernel. tg -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart failing with no such geom after gpt corruption
2010/4/1 Bartosz Stec bartosz.s...@it4pro.pl: Hello ZFS and GPT hackers :) I'm sending this message to both freebsd-current and freebsd-fs because it doesn't seems to be a CURRENT-specific issue. Yesterday I tried to migrate my mixed UFS/RAIDZ config to clean RAIDZ with GPT boot. I've following mostly this guide: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 I'm using CURRENT on 3x40GB HDDs (ad0-ad3) and additional 250GB HDD has been used for data migration (ad4). Data was copied form RAIDZ to 250GB HDD, GPT sheme was created on 40GB HDDs, then new zpool on them, and finally data went back to RAIDZ. Booting from RAIDZ was succesful, so far so good. After a while I've noticed some SMART errors on ad1, so I've booted machine with seatools for dos and made long test. One bad sector was found and reallocated, nothing to worry about. As I was in seatools already, I've decided to adjust LBA size on that disk (seatools can do that), because it was about 30MB larger than the other two, and because of that I had to adjust size of freebsd-zfs partition on that disk to match exact size of others (otherwise 'zpool create' will complain). So LBA was adjusted and system rebooted. Yes, I was aware that changing disk size probably end with corrupted GPT and data loss, but it doesn't seem to be a big deal for me as far as 2/3 of zpool is alive, because I can always recreate gpt and resilver ad1. Unfortunately it wasn't so easy. First of all system booted, and as I expected kernel message shows GPT error on ad1. Zpool was degraded but alive and kicking. However, when I tried to execute any gpart command on ad1, it return: ad1: no such geom Are you sure you created a partition scheme with gpart on ad1 before issuing partition-related gpart commands ? ad1 was present under /dev, and it could be accessed by sysinstall/fdisk, but no with gpart. I've created bsd slice with sysinstall on ad1 and rebooted, with hope that after reboot I could acces ad1 with gpart and recreate GPT scheme. Another surprise - system didn't boot at all, rebooting after couple of seconds in loader (changing boot device didn't make a difference). Only way I could boot system at this moment was connecting 250GB HDD which fortunately still had data from zpool migration and boot from it. Another surprise - kernel was still complaining about GPT corruption on ad1. I had no other ideas so I ran dd if=/dev/zero of=/dev/ad1 bs=512 count=512 to clear beginning of the hdd. After that disk was still unaccesible fromt gpart, so I tried sysinstall/fdisk againt to create standard BSD partitioning scheme and rebooted system. After that finally gpart started to talk with ad1 and GPT scheme and zpool has been recreated and work as it supposed to. Still, how can we clear broken GPT data after it got corrupted? Why gpart has been showing ad1: no such geom, and how can we deal with this problem? Finally, why gptzfsboot failed with GPT corrupted on other disk after trying to fix it, while it booted at first place? Or maybe changing LBA size of already partitioned HDD is extreme case, and the only way these problems could be triggered ;)? Cheers! -- Bartosz Stec ___ freebsd...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to freebsd-fs-unsubscr...@freebsd.org -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Re: Intel H55 and em0
Yup, gonna MFC the code from CURRENT to STABLE/8 first thing next week, at least that's my plan. Sorry, I thought STABLE/8 already had PCH in it, my bad. I checked and the ALTQ fix is in the tree, so pulling the directory from HEAD and adding it to STABLE/8 should work fine. MFC will be coming first thing Monday. Jack On Thu, Apr 1, 2010 at 9:11 AM, Jan Henrik Sylvester m...@janh.de wrote: On 01/-10/-28163 20:59, Jack Vogel wrote: OH, as to my last statement, the code in CURRENT will NOT work on 8.0 RELEASE, it would require a change to sys/conf/files, and it also has a fix in the stack that is not in RELEASE. SO taking the latest would require you take the whole tree. Jack On Wed, Mar 31, 2010 at 11:39 PM, Jack Vogeljfvo...@gmail.com wrote: The device subfamily on those motherboards is called PCH, and its only in the em driver as of last December, The CVS delta of if_em is 1.27. You can either update to STABLE/8 or CURRENT. If you wish to just pull the e1000 driver directory it should work fine in 8.0 RELEASE also. Cheers, Jack In your correction, you did not really mention 8-STABLE, you only warn about putting e1000 from CURRENT to 8.0-RELEASE. I got the same problem: http://lists.freebsd.org/pipermail/freebsd-mobile/2010-March/011952.html Since I did not get a reply, I put the whole e1000 directory from CURRENT into 8-STABLE. Is there any problem with that? (It _seems_ to work so far.) Are you going to MFC the PCH devices to 8-STABLE any time soon? Thanks, Jan Henrik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel H55 and em0
On Thu, Apr 1, 2010 at 10:30 AM, Thomas Gellekum thomas.gelle...@gmx.de wrote: Jack Vogel jfvo...@gmail.com wrote: The device subfamily on those motherboards is called PCH, and its only in the em driver as of last December, The CVS delta of if_em is 1.27. You can either update to STABLE/8 or CURRENT. If you wish to just pull the e1000 driver directory it should work fine in 8.0 RELEASE also. 8-STABLE doesn't work for me. The ethernet device is not recognized, and I get warnings about interrupt storms on irq19 (atapci1), which I don't see with 8-RELEASE. That might be a matter of missing diagnostics in the release kernel (the numbers from 'vmstat -i' seem to suggest this). Ditto. I have a Intel BOXDH55TC MB w/ a Core i3-530, 8GB RAM. Grabbed RELENG_8 , which http://www.freebsd.org/doc/handbook/cvs-tags.html says is stable.8. Compiled an amd64 GENERIC kernel. Could not recognize the ethernet. Had to go to CURRENT to get it working. Nathan Mates ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart failing with no such geom after gpt corruption
On Apr 1, 2010, at 6:23 AM, Bartosz Stec wrote: Unfortunately it wasn't so easy. First of all system booted, and as I expected kernel message shows GPT error on ad1. Zpool was degraded but alive and kicking. However, when I tried to execute any gpart command on ad1, it return: ad1: no such geom If the GPT is rejected, no GEOM is created in the kernel. It's the GEOM that gpart(8) talks to, so the error indicates that the GPT is not accepted after you changed the disk size. For all practical purposes ad1 doesn't have a partitioning. The only gpart command you can use is: gpart create -s gpt ad1 This creates a new GPT on the disk, wiping out whatever was there... -- Marcel Moolenaar xcl...@mac.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart failing with no such geom after gpt corruption
2010/4/1 Bartosz Stec bartosz.s...@it4pro.pl: Hello ZFS and GPT hackers :) I'm sending this message to both freebsd-current and freebsd-fs because it doesn't seems to be a CURRENT-specific issue. Yesterday I tried to migrate my mixed UFS/RAIDZ config to clean RAIDZ with GPT boot. I've following mostly this guide: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 I'm using CURRENT on 3x40GB HDDs (ad0-ad3) and additional 250GB HDD has been used for data migration (ad4). Data was copied form RAIDZ to 250GB HDD, GPT sheme was created on 40GB HDDs, then new zpool on them, and finally data went back to RAIDZ. Booting from RAIDZ was succesful, so far so good. After a while I've noticed some SMART errors on ad1, so I've booted machine with seatools for dos and made long test. One bad sector was found and reallocated, nothing to worry about. As I was in seatools already, I've decided to adjust LBA size on that disk (seatools can do that), because it was about 30MB larger than the other two, and because of that I had to adjust size of freebsd-zfs partition on that disk to match exact size of others (otherwise 'zpool create' will complain). So LBA was adjusted and system rebooted. I don't understand why you adjusted LBA. You're using GPT partitions, so, couldn't you just make the zfs partition the same size on all disks by adjusting it to the smallest disk, and let free space at the end of the bigger ones ? Cheers, Olivier Yes, I was aware that changing disk size probably end with corrupted GPT and data loss, but it doesn't seem to be a big deal for me as far as 2/3 of zpool is alive, because I can always recreate gpt and resilver ad1. Unfortunately it wasn't so easy. First of all system booted, and as I expected kernel message shows GPT error on ad1. Zpool was degraded but alive and kicking. However, when I tried to execute any gpart command on ad1, it return: ad1: no such geom ad1 was present under /dev, and it could be accessed by sysinstall/fdisk, but no with gpart. I've created bsd slice with sysinstall on ad1 and rebooted, with hope that after reboot I could acces ad1 with gpart and recreate GPT scheme. Another surprise - system didn't boot at all, rebooting after couple of seconds in loader (changing boot device didn't make a difference). Only way I could boot system at this moment was connecting 250GB HDD which fortunately still had data from zpool migration and boot from it. Another surprise - kernel was still complaining about GPT corruption on ad1. I had no other ideas so I ran dd if=/dev/zero of=/dev/ad1 bs=512 count=512 to clear beginning of the hdd. After that disk was still unaccesible fromt gpart, so I tried sysinstall/fdisk againt to create standard BSD partitioning scheme and rebooted system. After that finally gpart started to talk with ad1 and GPT scheme and zpool has been recreated and work as it supposed to. Still, how can we clear broken GPT data after it got corrupted? Why gpart has been showing ad1: no such geom, and how can we deal with this problem? Finally, why gptzfsboot failed with GPT corrupted on other disk after trying to fix it, while it booted at first place? Or maybe changing LBA size of already partitioned HDD is extreme case, and the only way these problems could be triggered ;)? Cheers! -- Bartosz Stec ___ freebsd...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to freebsd-fs-unsubscr...@freebsd.org -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Re: Intel H55 and em0
On 01/-10/-28163 20:59, Jack Vogel wrote: OH, as to my last statement, the code in CURRENT will NOT work on 8.0 RELEASE, it would require a change to sys/conf/files, and it also has a fix in the stack that is not in RELEASE. SO taking the latest would require you take the whole tree. Jack On Wed, Mar 31, 2010 at 11:39 PM, Jack Vogeljfvo...@gmail.com wrote: The device subfamily on those motherboards is called PCH, and its only in the em driver as of last December, The CVS delta of if_em is 1.27. You can either update to STABLE/8 or CURRENT. If you wish to just pull the e1000 driver directory it should work fine in 8.0 RELEASE also. Cheers, Jack In your correction, you did not really mention 8-STABLE, you only warn about putting e1000 from CURRENT to 8.0-RELEASE. I got the same problem: http://lists.freebsd.org/pipermail/freebsd-mobile/2010-March/011952.html Since I did not get a reply, I put the whole e1000 directory from CURRENT into 8-STABLE. Is there any problem with that? (It _seems_ to work so far.) Are you going to MFC the PCH devices to 8-STABLE any time soon? Thanks, Jan Henrik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart failing with no such geom after gpt corruption
Olivier Smedts wrote: 2010/4/1 Bartosz Stec bartosz.s...@it4pro.pl: Hello ZFS and GPT hackers :) I'm sending this message to both freebsd-current and freebsd-fs because it doesn't seems to be a CURRENT-specific issue. Yesterday I tried to migrate my mixed UFS/RAIDZ config to clean RAIDZ with GPT boot. I've following mostly this guide: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 I'm using CURRENT on 3x40GB HDDs (ad0-ad3) and additional 250GB HDD has been used for data migration (ad4). Data was copied form RAIDZ to 250GB HDD, GPT sheme was created on 40GB HDDs, then new zpool on them, and finally data went back to RAIDZ. Booting from RAIDZ was succesful, so far so good. After a while I've noticed some SMART errors on ad1, so I've booted machine with seatools for dos and made long test. One bad sector was found and reallocated, nothing to worry about. As I was in seatools already, I've decided to adjust LBA size on that disk (seatools can do that), because it was about 30MB larger than the other two, and because of that I had to adjust size of freebsd-zfs partition on that disk to match exact size of others (otherwise 'zpool create' will complain). So LBA was adjusted and system rebooted. I don't understand why you adjusted LBA. You're using GPT partitions, so, couldn't you just make the zfs partition the same size on all disks by adjusting it to the smallest disk, and let free space at the end of the bigger ones ? For that matter, my understanding is that ZFS just doesn't care. If you have disks of different sized in a raidz, the pool size will be limited by the size of the smallest device. If those devices are replaced with larger ones, then the pool just grows to take advantage of the additional available space. robert. Cheers, Olivier Yes, I was aware that changing disk size probably end with corrupted GPT and data loss, but it doesn't seem to be a big deal for me as far as 2/3 of zpool is alive, because I can always recreate gpt and resilver ad1. Unfortunately it wasn't so easy. First of all system booted, and as I expected kernel message shows GPT error on ad1. Zpool was degraded but alive and kicking. However, when I tried to execute any gpart command on ad1, it return: ad1: no such geom ad1 was present under /dev, and it could be accessed by sysinstall/fdisk, but no with gpart. I've created bsd slice with sysinstall on ad1 and rebooted, with hope that after reboot I could acces ad1 with gpart and recreate GPT scheme. Another surprise - system didn't boot at all, rebooting after couple of seconds in loader (changing boot device didn't make a difference). Only way I could boot system at this moment was connecting 250GB HDD which fortunately still had data from zpool migration and boot from it. Another surprise - kernel was still complaining about GPT corruption on ad1. I had no other ideas so I ran dd if=/dev/zero of=/dev/ad1 bs=512 count=512 to clear beginning of the hdd. After that disk was still unaccesible fromt gpart, so I tried sysinstall/fdisk againt to create standard BSD partitioning scheme and rebooted system. After that finally gpart started to talk with ad1 and GPT scheme and zpool has been recreated and work as it supposed to. Still, how can we clear broken GPT data after it got corrupted? Why gpart has been showing ad1: no such geom, and how can we deal with this problem? Finally, why gptzfsboot failed with GPT corrupted on other disk after trying to fix it, while it booted at first place? Or maybe changing LBA size of already partitioned HDD is extreme case, and the only way these problems could be triggered ;)? Cheers! -- Bartosz Stec ___ freebsd...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to freebsd-fs-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart failing with no such geom after gpt corruption
Bartosz, One thing to remember is that GPT stores it's header and entry tables at both the start and end of the disk for redundancy. As far as I understand it, by making the disk physically smaller, the GPT primary header and entry data would have become invalid as the last partition would now be ending past the end of the disk Partition table format OffsetLength Content 0 8 Signature (EFI PART, 45 46 49 20 50 41 52 54) ... 248Current LBA (location of this header copy) 328Backup LBA (location of the other header copy) 408First usable LBA for partitions (primary partition table last LBA + 1) 488Last usable LBA (secondary partition table first LBA - 1) ... GUID partition entry format OffsetLength Content 016Partition type GUID ... 328First LBA (little-endian) 408Last LBA (inclusive, usually odd) ... See http://en.wikipedia.org/wiki/GUID_Partition_Table ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart failing with no such geom after gpt corruption
Robert Noland wrote: Olivier Smedts wrote: 2010/4/1 Bartosz Stec bartosz.s...@it4pro.pl: Hello ZFS and GPT hackers :) I'm sending this message to both freebsd-current and freebsd-fs because it doesn't seems to be a CURRENT-specific issue. Yesterday I tried to migrate my mixed UFS/RAIDZ config to clean RAIDZ with GPT boot. I've following mostly this guide: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 I'm using CURRENT on 3x40GB HDDs (ad0-ad3) and additional 250GB HDD has been used for data migration (ad4). Data was copied form RAIDZ to 250GB HDD, GPT sheme was created on 40GB HDDs, then new zpool on them, and finally data went back to RAIDZ. Booting from RAIDZ was succesful, so far so good. After a while I've noticed some SMART errors on ad1, so I've booted machine with seatools for dos and made long test. One bad sector was found and reallocated, nothing to worry about. As I was in seatools already, I've decided to adjust LBA size on that disk (seatools can do that), because it was about 30MB larger than the other two, and because of that I had to adjust size of freebsd-zfs partition on that disk to match exact size of others (otherwise 'zpool create' will complain). So LBA was adjusted and system rebooted. I don't understand why you adjusted LBA. You're using GPT partitions, so, couldn't you just make the zfs partition the same size on all disks by adjusting it to the smallest disk, and let free space at the end of the bigger ones ? For that matter, my understanding is that ZFS just doesn't care. If you have disks of different sized in a raidz, the pool size will be limited by the size of the smallest device. If those devices are replaced with larger ones, then the pool just grows to take advantage of the additional available space. balrog% gpart show = 34 2097085 md0 GPT (1.0G) 34 1281 freebsd-boot (64K) 162 20969572 freebsd-zfs (1.0G) = 34 2097085 md1 GPT (1.0G) 34 1281 freebsd-boot (64K) 162 20969572 freebsd-zfs (1.0G) = 34 4194237 md2 GPT (2.0G) 34 1281 freebsd-boot (64K) 162 41941092 freebsd-zfs (2.0G) balrog% zpool status pool: test state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM testONLINE 0 0 0 raidz1ONLINE 0 0 0 md0p2 ONLINE 0 0 0 md1p2 ONLINE 0 0 0 md2p2 ONLINE 0 0 0 errors: No known data errors balrog% zpool list NAME SIZE USED AVAILCAP HEALTH ALTROOT test 2.98G 141K 2.98G 0% ONLINE - robert. robert. Cheers, Olivier Yes, I was aware that changing disk size probably end with corrupted GPT and data loss, but it doesn't seem to be a big deal for me as far as 2/3 of zpool is alive, because I can always recreate gpt and resilver ad1. Unfortunately it wasn't so easy. First of all system booted, and as I expected kernel message shows GPT error on ad1. Zpool was degraded but alive and kicking. However, when I tried to execute any gpart command on ad1, it return: ad1: no such geom ad1 was present under /dev, and it could be accessed by sysinstall/fdisk, but no with gpart. I've created bsd slice with sysinstall on ad1 and rebooted, with hope that after reboot I could acces ad1 with gpart and recreate GPT scheme. Another surprise - system didn't boot at all, rebooting after couple of seconds in loader (changing boot device didn't make a difference). Only way I could boot system at this moment was connecting 250GB HDD which fortunately still had data from zpool migration and boot from it. Another surprise - kernel was still complaining about GPT corruption on ad1. I had no other ideas so I ran dd if=/dev/zero of=/dev/ad1 bs=512 count=512 to clear beginning of the hdd. After that disk was still unaccesible fromt gpart, so I tried sysinstall/fdisk againt to create standard BSD partitioning scheme and rebooted system. After that finally gpart started to talk with ad1 and GPT scheme and zpool has been recreated and work as it supposed to. Still, how can we clear broken GPT data after it got corrupted? Why gpart has been showing ad1: no such geom, and how can we deal with this problem? Finally, why gptzfsboot failed with GPT corrupted on other disk after trying to fix it, while it booted at first place? Or maybe changing LBA size of already partitioned HDD is extreme case, and the only way these problems could be triggered ;)? Cheers! -- Bartosz Stec ___ freebsd...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to freebsd-fs-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list
Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
Xin LI wrote:
On Wed, Mar 31, 2010 at 6:56 PM, Tom Uffnert...@uffner.com wrote:
Michael Butler wrote:
This breaks most (if not all) of the QT4-dependent ports for the lack of
a definition of off64_t.
it also breaks multimedia/mplayer, graphics/ImageMagick, and
print/ghostscript8 everything that depends on it.
Just because they used to compile DOES NOT mean they were right. It's
NOT right to define _LARGEFILE64_SOURCE on FreeBSD, see:
http://www.delorie.com/gnu/docs/glibc/libc_13.html
i realize this. i was just adding to the list of ports that no longer
build after this change. ghostscript is kind of important for print
support.
i doubt this is right either, but it is a quick dirty way to
make mplayer compile again:
--- configure.orig 2010-04-01 15:49:37.0 -0400
+++ configure 2010-04-01 15:50:50.0 -0400
@@ -5337,7 +5337,7 @@
#include dvdread/nav_read.h
int main(void) { return 0; }
EOF
-cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE \
+cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 \
-ldvdread $_ld_dl _dvdread=yes _res_comment=external
fi
fi
@@ -7412,8 +7412,6 @@
if test $_largefiles = yes || freebsd ; then
CFLAGS=$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
if test $_dvdread = yes || test $_libdvdcss_internal = yes ; then
-# dvdread support requires this (for off64_t)
-CFLAGS=$CFLAGS -D_LARGEFILE64_SOURCE
cygwin CFLAGS=$CFLAGS -DSYS_CYGWIN
fi
fi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart failing with no such geom after gpt corruption
On 2010-04-01 19:34, Marcel Moolenaar wrote: On Apr 1, 2010, at 6:23 AM, Bartosz Stec wrote: Unfortunately it wasn't so easy. First of all system booted, and as I expected kernel message shows GPT error on ad1. Zpool was degraded but alive and kicking. However, when I tried to execute any gpart command on ad1, it return: ad1: no such geom If the GPT is rejected, no GEOM is created in the kernel. It's the GEOM that gpart(8) talks to, so the error indicates that the GPT is not accepted after you changed the disk size. For all practical purposes ad1 doesn't have a partitioning. The only gpart command you can use is: gpart create -s gpt ad1 This creates a new GPT on the disk, wiping out whatever was there... It was a middle of night when I played with that, so I'm not remember clearly if I tried it simpliest way like above or not. Maybe not, and all noise I made was pointless and caused by my inexperience with gpart. Probably I just expected output from gpart show ad1 be more like no valid partitioning scheme on device or error in GPT table, please recreate partition scheme in place of mystic geom message ;) Sorry for noise, thanks for a hint and happy easter everyone :) -- Bartosz Stec ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
On Thu, Apr 1, 2010 at 12:59 PM, Tom Uffner t...@uffner.com wrote:
Xin LI wrote:
On Wed, Mar 31, 2010 at 6:56 PM, Tom Uffnert...@uffner.com wrote:
Michael Butler wrote:
This breaks most (if not all) of the QT4-dependent ports for the lack of
a definition of off64_t.
it also breaks multimedia/mplayer, graphics/ImageMagick, and
print/ghostscript8 everything that depends on it.
Just because they used to compile DOES NOT mean they were right. It's
NOT right to define _LARGEFILE64_SOURCE on FreeBSD, see:
http://www.delorie.com/gnu/docs/glibc/libc_13.html
i realize this. i was just adding to the list of ports that no longer
build after this change. ghostscript is kind of important for print
support.
i doubt this is right either, but it is a quick dirty way to
make mplayer compile again:
--- configure.orig 2010-04-01 15:49:37.0 -0400
+++ configure 2010-04-01 15:50:50.0 -0400
@@ -5337,7 +5337,7 @@
#include dvdread/nav_read.h
int main(void) { return 0; }
EOF
- cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE \
+ cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 \
-ldvdread $_ld_dl _dvdread=yes _res_comment=external
fi
fi
@@ -7412,8 +7412,6 @@
if test $_largefiles = yes || freebsd ; then
CFLAGS=$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
if test $_dvdread = yes || test $_libdvdcss_internal = yes ; then
- # dvdread support requires this (for off64_t)
- CFLAGS=$CFLAGS -D_LARGEFILE64_SOURCE
cygwin CFLAGS=$CFLAGS -DSYS_CYGWIN
fi
fi
I think the latest (1.2.4.1) zlib has a bug that prevents using
-D_LARGEFILE64_SOURCE at all, and expects -D_LARGEFILE64_SOURCE=1.
I'll submit a patch to upstream :(
Cheers,
--
Xin LI delp...@delphij.net http://www.delphij.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart failing with no such geom after gpt corruption
On 2010-04-01 21:02, Robert Noland wrote: After a while I've noticed some SMART errors on ad1, so I've booted machine with seatools for dos and made long test. One bad sector was found and reallocated, nothing to worry about. As I was in seatools already, I've decided to adjust LBA size on that disk (seatools can do that), because it was about 30MB larger than the other two, and because of that I had to adjust size of freebsd-zfs partition on that disk to match exact size of others (otherwise 'zpool create' will complain). So LBA was adjusted and system rebooted. I don't understand why you adjusted LBA. You're using GPT partitions, so, couldn't you just make the zfs partition the same size on all disks by adjusting it to the smallest disk, and let free space at the end of the bigger ones ? Well yes, I could indeed, and this is exactly what I did at the first time (before LBA count adjusting). But while I was already using software which could adjust LBA to make all HDD appear to be same size, I've decided to do it to never have to remember about it while partitioning ;) At least 'gpart show' isn't showing any unused (wasted) space now ;) : # gpart show = 34 78165293 ad0 GPT (37G) 34 1281 freebsd-boot (64K) 162 20971522 freebsd-swap (1.0G) 2097314 760680133 freebsd-zfs (36G) = 34 78165293 ad1 GPT (37G) 34 1281 freebsd-boot (64K) 162 20971522 freebsd-swap (1.0G) 2097314 760680133 freebsd-zfs (36G) = 34 78165293 ad2 GPT (37G) 34 1281 freebsd-boot (64K) 162 20971522 freebsd-swap (1.0G) 2097314 760680133 freebsd-zfs (36G) For that matter, my understanding is that ZFS just doesn't care. If you have disks of different sized in a raidz, the pool size will be limited by the size of the smallest device. If those devices are replaced with larger ones, then the pool just grows to take advantage of the additional available space. robert. Well, here's what man zpool says about zpool create: (...) The use of differently sized devices within a single raidz or mirror group is also flagged as an error unless -f is specified. I know I could force it, I just didn't know if I should. After all it's just easier to type 3 times: gpt add -t freebsd-zfs -l diskN to use all free space on device than checking numbers on other disks and type gpt add -b 2097314 -s 76068013 -t freebsd-zfs -l diskN and that's why all story begins :) -- Bartosz Stec ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
Xin LI delp...@gmail.com writes: Tom Uffner t...@uffner.com writes: Michael Butler i...@protected-networks.net writes: This breaks most (if not all) of the QT4-dependent ports for the lack of a definition of off64_t. it also breaks multimedia/mplayer, graphics/ImageMagick, and print/ghostscript8 everything that depends on it. Just because they used to compile DOES NOT mean they were right. It's NOT right to define _LARGEFILE64_SOURCE on FreeBSD, see: http://www.delorie.com/gnu/docs/glibc/libc_13.html Nor is it correct on Linux. As the above link says, _LARGEFILE64_SOURCE is a hack that was introduced to ease the transition from 32-bit off_t to 64-bit off_t. The correct idiom is to define _FILE_OFFSET_BITS to 64 before including sys/types.h and sys/stat.h. http://www.delorie.com/gnu/docs/glibc/libc_13.html That was *fourteen years ago*, almost to the day. There is *no* excuse for using this hack today. *Especially* in software that was written long after that document was published. *Especially* when all you need to do to get it right is add AC_SYS_LARGEFILE to configure.ac and use off_t, struct stat and stat() / lstat() (without the 64 suffix) as if none of this had ever happened. And yes, I *will* keep harping on this until people Get It. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Results of BIND RFC
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Greetings, SUMMARY On February 21 I sent a message to freebsd-a...@freebsd.org detailing the current state of BIND on FreeBSD, and plans for the future. You can see that message here: http://lists.freebsd.org/pipermail/freebsd-arch/2010-February/009908.html In that message I asked for feedback on my plans for dealing with BIND in the base. There wasn't much response on the lists, however I did receive a great deal of response privately, all more or less to the effect of, Do we really need to continue having BIND in the base at all? After careful consideration and private discussion about this issue the conclusion has been reached that the answer to this question is, No. Therefore we will be removing BIND from the FreeBSD base. BACKGROUND Back in the day when the FreeBSD project started there was really only one show in the DNS town, BIND. In the last 10 years several truly viable, first-class DNS options have been developed, in both the authoritative and resolving server spaces. There are ports available for each of these options, and many FreeBSD users take advantage of them. There are of course also ports available for all supported BIND versions, as well as dns/bind9 for BIND version 9.3 which has been EOL'ed by ISC but is still in FreeBSD version 6. This also leads to the issue mentioned in the post above, the desynchronization between FreeBSD and ISC release schedules. While FreeBSD 6 is scheduled to EOL in November of this year, it contains BIND version 9.3.6-P1, which has long been EOL. There are a number of problems related to upgrading the version of BIND in a release branch of FreeBSD. Given the ease with which FreeBSD users can upgrade BIND with the ports tree, and given the characteristics of the vulnerabilities that have come to light with BIND 9.3.x to date, this hasn't been a problem. There is no guarantee that this will continue to be the case. This problem will reappear again in FreeBSD version 7 with BIND 9.4, and FreeBSD version 8 with BIND 9.6. PROS This change will have several advantages. 1) Users of all FreeBSD versions will be able to have easy access to the latest versions of BIND, and an easy upgrade path that does not involve a full OS upgrade. 2) The release synchronization problem mentioned above will no longer be a problem. 3) Users of other DNS solutions will no longer need to customize their build using the various WITH/WITHOUT_BIND* knobs. CONS Of course this change will have some costs. Users of named who rely on the current defaults will have some change management to deal with, however the costs will be minimal. The one area that has come up repeatedly in previous discussions about this topic is that users like having access to the command line tools dig, host, and nslookup. To deal with that issue I will be creating a bind-tools port so that those who want just those tools can easily add them, without the overhead of the rest of the BIND suite. If anyone has suggestions for other BIND tools that should be included in the port, please let me know. IMPLEMENTATION TIMELINE I will be removing BIND from HEAD today. Removal from the other branches will occur far enough in advance of their upcoming releases to ensure that the users have a chance to shake things out first. I'll also be committing the bind-tools and bind-config ports today so that users will continue to have easy access to the work I've done on named.conf, rc.d/named, etc. I have been maintaining BIND in the base for almost 8 years now, and while it's been challenging in a lot of ways, it's also been a great privilege to be able to help the FreeBSD community in this way. I can't say that I'll miss the drama of src updates though. :) Many happy returns of the day, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iEYEAREDAAYFAku1G1sACgkQyIakK9Wy8PuPgQCfdrhgscMQ+KPLcoRXx66f4f6M T8wAniZqULdwM+4oRsbOkFSDZIceWn0u =Syor -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Results of BIND RFC
May I only hope this is legit and not a April Fool's joke :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
bridged wlan/ether still the same
i have a year old 8 soekris system i am about to upgrade. it is pppoe externally, and has a bridged natted wireless/ether internal net. .. || | b --wlan0| | r| 192.168.0.0/24 ext iij| i --- vr1| LAN hosts, PPP/NAT ---|vr0--- d| DHCP Clients WAN | g --- vr2| ... | e| | 0 --- vr3| || `' /etc/rc.conf ppp_enable=YES ppp_mode=dedicated ppp_nat=YES ppp_profile=iij hostapd_enable=YES wlans_ath0=wlan0 create_args_wlan0=wlanmode ap mode 11g channel 11 up cloned_interfaces=bridge0 ifconfig_bridge0=192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 addm wlan1 up ifconfig_vr1=up ifconfig_vr2=up ifconfig_vr3=up /etc/hostap.conf interface=wlan0 ctrl_interface=/var/run/hostapd logger_syslog=-1 logger_syslog_level=0 ssid=rgnet-crypt country_code=JP hw_mode=g wpa=2 wpa_key_mgmt=WPA-PSK wpa_passphrase=notreally wpa_pairwise=CCMP TKIP /etc/ppp/ppp.conf entry iij: set device PPPoE:vr0 set MRU 1454 # NTT suggests this value set MTU 1454 accept CHAP enable lqr add default HISADDR nat enable yes set authname nope set authkey peon is this still gonna work? is this a reasonable way to do this? i ask because, if it does not, i will not have usable connectivity to get help fixing it :) randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Results of BIND RFC
May I only hope this is legit and not a April Fool's joke :) actually, as an unbound user, i would be quite happy to have bind removed. bloated, ever-buggy, config religion, ... randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Results of BIND RFC
On 04/01/2010 23:48, Randy Bush wrote: May I only hope this is legit and not a April Fool's joke :) actually, as an unbound user, i would be quite happy to have bind removed. bloated, ever-buggy, config religion, ... randy At least I hope that this will be removed and added to the distribution as a package upon release time. -- jhell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
Hi, Tom,
On Thu, Apr 1, 2010 at 12:59 PM, Tom Uffner t...@uffner.com wrote:
[...]
i realize this. i was just adding to the list of ports that no longer
build after this change. ghostscript is kind of important for print
support.
i doubt this is right either, but it is a quick dirty way to
make mplayer compile again:
--- configure.orig 2010-04-01 15:49:37.0 -0400
+++ configure 2010-04-01 15:50:50.0 -0400
@@ -5337,7 +5337,7 @@
#include dvdread/nav_read.h
int main(void) { return 0; }
EOF
- cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE \
+ cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 \
-ldvdread $_ld_dl _dvdread=yes _res_comment=external
fi
fi
@@ -7412,8 +7412,6 @@
if test $_largefiles = yes || freebsd ; then
CFLAGS=$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
if test $_dvdread = yes || test $_libdvdcss_internal = yes ; then
- # dvdread support requires this (for off64_t)
- CFLAGS=$CFLAGS -D_LARGEFILE64_SOURCE
cygwin CFLAGS=$CFLAGS -DSYS_CYGWIN
fi
fi
Specifying -DFOO basically means in C code one have:
%%%
#define FOO 1
%%%
This would not cause problem for zlib, at least not for zlib 1.2.4.1.
However, defining it do cause *64 interfaces being included, the
assumption doesn't seem right, according to my understanding of GNU
libc's manual.
I was wrong in a previous e-mail that it's not -D_LARGEFILE64_SOURCE
itself being broken, but #define _LARGEFILE64_SOURCE broken if it's
not defined as '1'. GNU libc seems to test whether this is defined,
rather than testing it against '1' (zlib do this).
So in conclusion:
a) We actually face two different types of problems, one is defining
_LARGEFILE64_SOURCE on FreeBSD, this is not right. It should not be
defined at all; another is to have #define _LARGEFILE64_SOURCE
instead of #define _LARGEFILE64_SOURCE 1, this type would break not
only on FreeBSD but perhaps some other platforms, unfortunately this
seems to be common. Should one hit either case, please have it fixed
by upstream developers, as it would benefit not only FreeBSD but also
other platforms.
b) For now I have implemented a temporary solution on -HEAD by
unifdef'ing _LARGEFILE64_SOURCE, _LFS64_SOURCE on zlib.h and zconf.h,
so ports may appear as fixed. This is not ideal since it makes us
to diverge away from zlib. A better solution is under discussion and
this situation MAY change in the next import.
Cheers,
--
Xin LI delp...@delphij.net http://www.delphij.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Results of BIND RFC
On Thu, 01 Apr 2010 15:16:59 -0700 Doug Barton do...@freebsd.org mentioned: Of course this change will have some costs. Users of named who rely on the current defaults will have some change management to deal with, however the costs will be minimal. The one area that has come up repeatedly in previous discussions about this topic is that users like having access to the command line tools dig, host, and nslookup. To deal with that issue I will be creating a bind-tools port so that those who want just those tools can easily add them, without the overhead of the rest of the BIND suite. If anyone has suggestions for other BIND tools that should be included in the port, please let me know. Hey, Doug! While it certainly might make sense to drop BIND out of the base, I'm not sure dropping bind tools as well from it is the best decision. How hard it will be to continue maintaining bind tools inside the base (so the critical ones like dig and nslookup still will be available), while moving the rest of it (the server itself and supporting tools) to the port? -- Stanislav Sedov ST4096-RIPE pgpvEm8qc8zyJ.pgp Description: PGP signature
