Re: [RFC] FDT fix for 64 bit platforms
On Sat, Oct 15, 2011 at 2:01 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/14/11 14:10, Jayachandran C. wrote: I'm planning commit this -CURRENT if there an no objections. In the current implementation, phandle is used to store a pointer to the location inside the device tree. Since phandle_t is u32, this will not work on 64 bit platforms. With this fix, the phandle is the offset from the start of device tree pointer 'fdtp', which will be 32 bit. Review or testing from device tree users will be welcome. JC. Why not use offsets into the FDT rather than full pointers? I believe having phandles greater than 32 bits violates the FDT spec, and declaring that the FDT can't itself be larger than 4 GB seems reasonable. I am actually using the offset from the beginning of FDT (fdtp) as phandle. I cannot use the usual fdt offset (after off_dt_struct) as phandle, because in that case offset of 0 is valid, but phandle 0 should not be valid. JC. ___ 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: x.0 RELASE isn't for production.
Am Fri, 14 Oct 2011 11:55:28 +0400 schrieb Pavel Timofeev tim...@gmail.com: That's what most people think. Hi! I'm not thinking this. This is made up by users who only adapt slowly to changes and features. Look at the whole crowd which got furious about the new Microsoft Office. I tell you, in one year, no one will cry about it anymore. Sometimes, I feel like I am the only who is happy about good ideas, even when they change something drastically. The most people think Whoa... I have to learn again!... and then silently accept it when it is very late, because everyone else already migrated. This has nothing to do with release quality, because the efforts to make a production release of x.0 are much higher, in my opinion. So the quality is generally better, if you have enough time to make this release. For me the worst FreeBSD release ever was 5.3. Even 5.0 BETAs worked better on my hardware. I also stopped using FreeBSD at that time until 7.0 BETAs arrived. And when BETA/RC time comes users rush like mad to test it. And they find errors and bugs. Writing PR, emails and even !pathes! But the lion's share of these pathes doesn't get into the coming BETA or RC. Yes. I'm waiting for my /sbin/dump fix to get verified and committed. It's really disappointing to see the next release without a functioning backup possibility (for my configuration here). Fortunately, I don't see a fixed release date, yet. I hope the developers fix as much as possible even when we see 9.0R in late 2012. -- Martin signature.asc Description: PGP signature
Re: x.0 RELASE isn't for production.
MHO different OS releases (Unix or not) are usually at the state of FreeBSD current regarding stability. FreeBSD late BETA and early RC are usually very stable. Therefore the approximate one month period between the first beta and the release is adequate time. I see your point, especially after installing NetBSD on my new computer and having big problems, like not being able to startx or not neing able to boot at all. On the old computer, I also had big problems with NetBSD, including release, stable and current versions. Building FreeBSD or NetBSD from source might be not feasible on older computers short on RAM and/or disk space. There are more frequent current FreeBSD snapshots available on http://pub.allbsd.org/pub/FreeBSD-snapshots/ This site also has snapshots for other BSDs. Tom ___ 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: 9.x installer and GPT vs geom, features in bsdinstall
On 10/13/11, Oliver Hartman wrote: On 10/13/11 10:39, Johan Hendriks wrote: Hello all. I just used the 9.0 B3 installer, and it defaults to GPT, which is nice. However, and there has been some discussions about it, it would be nice if the installer warns me that i could get in trouble if i want to use gmirror and the like. Also i find it a little strange that the default mode, GPT in this case is in some sort not compatible with the other default geom structure. For a newcomer or for people who use gmirror and glabel on a regular basis because there somewhat default, it could strike them if they start using the default GPT. It is not logical. Two default ways to do things that are in a way not compatible. So a warning at the installer level could make a lot of users aware of this, and they can decide what to do, use GPT or go back to the old MBR. They can start looking at the mailling list and so on to make the right decision is GPT acceptable for me or not. And not install FreeBSD and find out later that you could not use your old gmirror and glabel tactics without corrupting the GPT structure. Just my thoughts about this. regards, Johan Hendriks Shouldn't be there also a warning that GPT can not be used with the FreeBSD native bootselector? I had trouble installing FreeBSD 9.0-CURRENT a while ago with default being GPT on my notebook and also wanting a Windows 7/x64 for presentations, selectable via the FreeBSD bootselector. This was possible with MBR, but it seems gone with GPT. Regards, Oliver GPT shouldn't be installed with ANY bootselector present on the same device ! But, I noticed that when installing 9.0B1 on 2nd slice of a MBR disk (1st slice with 8.2), using expert mode in Bsdinstall, (so selecting a MBR installation), I did not have the expected choice (like in sysinstall) between a MBR bootloader, a standard MBR , or don't touch to bootsector; (no damage for me, as my bootselector --grub--is installed on a separate disk dedicated to rescue and booting, allowing me to be more safe when testing newer releases); could this usefull previous choice be merged in Bsdinstall ? Later, I installed the 9.0B3 on a free disk, using the guided mode in Bsdinstall, and selecting an GPT installation, that worked fine; but I found very few differences between guided and expert mode (both require a minimal expertise). The use of auto choice would be too more documented, instead of letting the user to see what will happen ?. I agree with the suggestion to introduce warnings in the installer itself, against the most dangerous incompatibilities, between gpt and geom, or whatever that could appear during the beta testing; but more generally the question is : what level of information need to be present in the installation medium, apart of the installer, allowing non-expert to succed installation whit a minimum of mistakes; it is obvious that having a look on the mailing lists BEFORE to begin is very helpfull, and a digest of the most important threads could appear as a README-1st or an installation-FAQ with the proper comments, at the ordinary-user level? Regards Roger ___ 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
portsnap fails: look: tINDEX.new: File too large
Since today's morning I receive on every box this message shown below while doing a 'portsnap fetch'. What's wrong and how to repair? Regards, Oliver Looking up portsnap.FreeBSD.org mirrors... 5 mirrors found. Fetching snapshot tag from portsnap1.FreeBSD.org... done. Fetching snapshot metadata... done. look: tINDEX.new: File too large Portsnap metadata appears bogus. Cowardly refusing to proceed any further. ___ 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: [RFC] FDT fix for 64 bit platforms
On 10/15/11 01:12, Jayachandran C. wrote: On Sat, Oct 15, 2011 at 2:01 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/14/11 14:10, Jayachandran C. wrote: I'm planning commit this -CURRENT if there an no objections. In the current implementation, phandle is used to store a pointer to the location inside the device tree. Since phandle_t is u32, this will not work on 64 bit platforms. With this fix, the phandle is the offset from the start of device tree pointer 'fdtp', which will be 32 bit. Review or testing from device tree users will be welcome. JC. Why not use offsets into the FDT rather than full pointers? I believe having phandles greater than 32 bits violates the FDT spec, and declaring that the FDT can't itself be larger than 4 GB seems reasonable. I am actually using the offset from the beginning of FDT (fdtp) as phandle. I cannot use the usual fdt offset (after off_dt_struct) as phandle, because in that case offset of 0 is valid, but phandle 0 should not be valid. Why shouldn't phandle 0 be valid? The invalid phandle is -1. This is one of the problems with our existing FDT code -- it makes all kinds of wrong assumptions like this about IEEE 1275. -Nathan ___ 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: [RFC] FDT fix for 64 bit platforms
On Sat, Oct 15, 2011 at 8:43 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/15/11 01:12, Jayachandran C. wrote: On Sat, Oct 15, 2011 at 2:01 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/14/11 14:10, Jayachandran C. wrote: I'm planning commit this -CURRENT if there an no objections. In the current implementation, phandle is used to store a pointer to the location inside the device tree. Since phandle_t is u32, this will not work on 64 bit platforms. With this fix, the phandle is the offset from the start of device tree pointer 'fdtp', which will be 32 bit. Review or testing from device tree users will be welcome. JC. Why not use offsets into the FDT rather than full pointers? I believe having phandles greater than 32 bits violates the FDT spec, and declaring that the FDT can't itself be larger than 4 GB seems reasonable. I am actually using the offset from the beginning of FDT (fdtp) as phandle. I cannot use the usual fdt offset (after off_dt_struct) as phandle, because in that case offset of 0 is valid, but phandle 0 should not be valid. Why shouldn't phandle 0 be valid? The invalid phandle is -1. This is one of the problems with our existing FDT code -- it makes all kinds of wrong assumptions like this about IEEE 1275. Well, the existing FDT code returns 0 as the invalid handle and I do not want to change that in this commit. If the return value is really wrong, we will need a bigger exercise to change the return value and fix any callers which are affected by that change. JC. ___ 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: [RFC] FDT fix for 64 bit platforms
On Oct 15, 2011, at 9:33 AM, Jayachandran C. wrote: On Sat, Oct 15, 2011 at 8:43 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/15/11 01:12, Jayachandran C. wrote: On Sat, Oct 15, 2011 at 2:01 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/14/11 14:10, Jayachandran C. wrote: I'm planning commit this -CURRENT if there an no objections. In the current implementation, phandle is used to store a pointer to the location inside the device tree. Since phandle_t is u32, this will not work on 64 bit platforms. With this fix, the phandle is the offset from the start of device tree pointer 'fdtp', which will be 32 bit. Review or testing from device tree users will be welcome. JC. Why not use offsets into the FDT rather than full pointers? I believe having phandles greater than 32 bits violates the FDT spec, and declaring that the FDT can't itself be larger than 4 GB seems reasonable. I am actually using the offset from the beginning of FDT (fdtp) as phandle. I cannot use the usual fdt offset (after off_dt_struct) as phandle, because in that case offset of 0 is valid, but phandle 0 should not be valid. Why shouldn't phandle 0 be valid? The invalid phandle is -1. This is one of the problems with our existing FDT code -- it makes all kinds of wrong assumptions like this about IEEE 1275. Well, the existing FDT code returns 0 as the invalid handle and I do not want to change that in this commit. If the return value is really wrong, we will need a bigger exercise to change the return value and fix any callers which are affected by that change. It should be fairly easy to change the base from fdtp to the usual fdt offset, so let me propose the following: 1. JC commits what he has and based on the current code. 2. We get all the facts on the table. I say this because I read different and contradictory things (0 being an invalid phandle in OF, negative phandles exist, etc). 3. We change the implementation, if such is warranted, in a separate effort. The point really is that 0 is an invalid phandle right now, right or wrong, and JCs changes are based on that. I see no problem proceeding on the path we're on, while we discuss what's the correct implementation and whether or not we should have a course change... Thoughts? -- Marcel Moolenaar mar...@xcllnt.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: [RFC] FDT fix for 64 bit platforms
On 2011-10-15, at 18:48, Marcel Moolenaar wrote: On Oct 15, 2011, at 9:33 AM, Jayachandran C. wrote: On Sat, Oct 15, 2011 at 8:43 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/15/11 01:12, Jayachandran C. wrote: On Sat, Oct 15, 2011 at 2:01 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 10/14/11 14:10, Jayachandran C. wrote: I'm planning commit this -CURRENT if there an no objections. In the current implementation, phandle is used to store a pointer to the location inside the device tree. Since phandle_t is u32, this will not work on 64 bit platforms. With this fix, the phandle is the offset from the start of device tree pointer 'fdtp', which will be 32 bit. Review or testing from device tree users will be welcome. JC. Why not use offsets into the FDT rather than full pointers? I believe having phandles greater than 32 bits violates the FDT spec, and declaring that the FDT can't itself be larger than 4 GB seems reasonable. I am actually using the offset from the beginning of FDT (fdtp) as phandle. I cannot use the usual fdt offset (after off_dt_struct) as phandle, because in that case offset of 0 is valid, but phandle 0 should not be valid. Why shouldn't phandle 0 be valid? The invalid phandle is -1. This is one of the problems with our existing FDT code -- it makes all kinds of wrong assumptions like this about IEEE 1275. Well, the existing FDT code returns 0 as the invalid handle and I do not want to change that in this commit. If the return value is really wrong, we will need a bigger exercise to change the return value and fix any callers which are affected by that change. It should be fairly easy to change the base from fdtp to the usual fdt offset, so let me propose the following: 1. JC commits what he has and based on the current code. 2. We get all the facts on the table. I say this because I read different and contradictory things (0 being an invalid phandle in OF, negative phandles exist, etc). 3. We change the implementation, if such is warranted, in a separate effort. The point really is that 0 is an invalid phandle right now, right or wrong, and JCs changes are based on that. I see no problem proceeding on the path we're on, while we discuss what's the correct implementation and whether or not we should have a course change... Thoughts? The patch looks fine to me, but we didn't have a chance yet to test it on any PPC/ARM system, have you, Marcel? Regarding the phandle validity I need to recall the context as this was a while back and I don't quite remember all constraints and motivations. Rafal ___ 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: -CURRENT (BETA1) zfs pool recognized as corrupted
Currently I have a strange situation when I have running system on my zroot but I can't import this pool when booted from memstick. I was trying to understand what is going on and here are my observations. My partition table is: gpart show -l = 34 250069613 ada0 GPT (119G) 34128 1 (null) (64k) 162 1886 5 (null) (943k) 2048 16777216 2 linux0 (8.0G) 16779264 33554432 3 home0 (16G) 50333696 199735951 4 disk0 (95G) but in /dev/gpt I only see: ls /dev/gpt/* /dev/gpt/home0 /dev/gpt/home0.eli /dev/gpt/linux0 (home is encrypted). I have a regular system installed and running on this pool. Filesystem to boot from is called 'zroot' and it can only boot when my whole loader.conf is used. With only zfs.ko booting stops with boot prompt asking for filesystem to boot from, menu shows all my gpt partitions and id's correctly so I don't understand why it can't find it. Below is my loader.conf: # Kernel Options kern.ipc.shmseg=1024 kern.ipc.shmmni=1024 kern.maxproc=1 # GEOM encrypted device geom_eli_load=YES geom_label_load=YES geom_mbr_load=YES # Intel System management bus smb_load=YES smbus_load=YES ichsmb_load=YES ichwd_load=YES # Use AHCI instead of ataahci ahci_load=YES # AHCI deprecated ataahci #ataahci_load=NO ataintel_load=YES # Intel HDA sound driver snd_hda_load=YES # PS/2 Mouse psm_load=NO # USB ehci_load=YES ohci_load=YES uhci_load=YES # USB mouse ums_load=YES # POSIX Semaphores # Required by Firefox sem_load=YES # ACPI drivers acpi_load=YES acpi_video_load=YES acpi_ibm_load=YES acpi_dock_load=YES # Linuxulator linux_load=YES # Linux specific pseudo-devices lindev_load=YES # Bluetooth driver ng_ubt_load=YES # Intel Centrino driver iwn6000fw_load=YES iwn6050fw_load=YES if_iwn_load=YES # Realtek driver if_re_load=YES # Intel wireless driver #if_wpi_load=YES legal.intel_ipw.license_ack=1 legal.intel_iwi.license_ack=1 legal.intel_wpi.license_ack=1 legal.intel_iwn.license_ack=1 # Virtualbox driver (kmod) vboxdrv_load=YES # ATAPICAM module # required to write DVD atapicam_load=YES # USB Printer # required by HP D2360 ulpt_load=NO ugen_load=YES # Network pseudo-interface which supports failover if_lagg_load=YES # Joystick support joy_load=YES # Thermal sensor for Core2 Duo coretemp_load=YES # Be verbose on ACPI hw.acpi.verbose=1 hw.acpi.reset_video=0 debug.acpi.resume_beep=1 # Firewire drivers firewire_load=YES fwe_load=YES fwip_load=YES # PF firewall driver, # be carefull, when enabled it disables all network traffic, even ping ipfw_load=NO pf_load=NO # Trusted Platform Module tpm_load=YES # TMPFS driver # I'm using mdmfs for /tmp now tmpfs_load=NO # Boot splash screen #hint.sc.0.flags=0x0180 #hint.sc.0.vesa_mode=0x0118 loader_logo=beastie #vesa_load=YES #splash_pcx_load=YES #bitmap_load=YES #bitmap_name=/boot/splash.pcx # Kernel debugger through firewire and dcons dcons_load=YES dcons_gdb=1 dcons_crom_load=YES boot_multicons=YES hw.firewire.phydma_enable=1 #hw.firewire.dcons_crom.force_console=1 # ZFS driver and settings zfs_load=YES # Disable ZFS prefetching # http://southbrain.com/south/2008/04/the-nightmare-comes-slowly-zfs.html # Increases overall speed of ZFS, but when disk flushing/writes occur, # system is less responsive (due to extreme disk I/O). # NOTE: 8.0-RC1 disables this by default on systems = 4GB RAM anyway vfs.zfs.prefetch_disable=1 # Increase vm.kmem_size to allow for ZFS ARC to utilise more memory. #vm.kmem_size=512M #vm.kmem_size_max=1024M #vfs.zfs.arc_max=100M # Disable UMA (uma(9)) for ZFS; amd64 was moved to exclusively use UMA # on 2010/05/24. # http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html #vfs.zfs.zio.use_uma=0 # Decrease ZFS txg timeout value from 30 (default) to 5 seconds. This # should increase throughput and decrease the bursty stalls that # happen during immense I/O with ZFS. # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007343.html # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007355.html vfs.zfs.txg.timeout=5 # WebCam and DVB support cuse4bsd_load=YES # Memory Stick and SD Card controller mmc_load=YES mmcsd_load=YES sdhci_load=YES # 3G modem card u3g_load=YES # Load File-System Support libiconv_load=YES libmchain_load=YES cd9660_iconv_load=YES msdosfs_iconv_load=YES ntfs_load=NO ntfs_iconv_load=NO udf_load=YES udf_iconv_load=YES # Desktop optimizations # see http://forums.freebsd.org/showthread.php?p=123657#post123657 # boot delay autoboot_delay=10 beastie_disable=NO # page share factor per proc vm.pmap.shpgperproc=512 # open files kern.maxfiles=49312 kern.maxfilesperproc=16384 # avoid additional 128 interrupts per second per core hint.atrtc.0.clock=0 # do not power devices without driver hw.pci.do_power_nodriver=3 # reduce sound generated interrupts hint.pcm.0.buffersize=65536 hint.pcm.1.buffersize=65536 hint.pcm.2.buffersize=65536 hw.snd.feeder_buffersize=65536 hw.snd.latency=7 #
nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII]
Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for rl(4) only 8129 need testing, 8139 don't) please give the following patch a try in order to ensure it doesn't break anything? for 9/head: http://people.freebsd.org/~marius/mii_bitbang.diff for 8: http://people.freebsd.org/~marius/mii_bitbang.diff8 Thanks, Marius ___ 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
HEADSUP: Call for FreeBSD Status Reports - 3Q/2011
Dear all, I would like to remind you that the next round of status reports covering the third quarter of 2011 were due on October 15th, 2011. As this initiative is very popular among our users, I would like to ask you to submit your status reports as soon as possible, so that we can compile the report in a timely fashion. Do not hesitate and write us a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you consider interested is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to mont...@freebsd.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- Kind regards Daniel Gerzo ___ 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: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII]
On Sun, Oct 16, 2011 at 02:46:23AM +0200, Damien Fleuriot wrote: On 15 Oct 2011, at 22:56, Marius Strobl mar...@alchemy.franken.de wrote: Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for rl(4) only 8129 need testing, 8139 don't) please give the following patch a try in order to ensure it doesn't break anything? for 9/head: http://people.freebsd.org/~marius/mii_bitbang.diff for 8: http://people.freebsd.org/~marius/mii_bitbang.diff8 Thanks, Marius While I don't have any box with this hardware, I'm thinking you might want to get a bit more specific about what you want tested... What do you think the patch might break ? Basically, if there's something wrong with the patch the driver should fail to attach, if it still does and gets a link all should be fine. Marius ___ 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
