Re: Help review the FAQ
On 11/27/2012 08:44 AM, Andrea Venturoli wrote: On 11/26/12 23:09, Bas Smeelen wrote: Probable addition 8.8 I get a lot of 'spurious interrupts detected' messages on a modified i386 build kernel and my computer does not work right. What did I do wrong? You have a single processor computer, build your own customized kernel and disabled options SMP (multiprocessor). Probably you also disabled the line below, device apic# I/O APIC This is code for the advanced programmable interrupt controller which also controls interrupts for your attached devices, being ethernet cards and others. Do not disable this device. While I don't know about apic, there used to be "KEEP THIS!!!" comments in GENERIC's conf file. I guess this would be more on the spot than a FAQ you'd read *after* removing this. Just my 2c. bye av. You're probably right. It must have been before 6.3-RELEASE, where there are no KEEP THIS comments in GENERIC. Though in NOTES it says "Mandatory". It is a very stupid user error on my side, which I stumbled upon quite a time ago and maybe not even FAQ worthy then. ___ 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"
simple patch for portsnap to use wget
Hi all, I was in trouble for a while because I was using FreeBSD behind an http proxy (a palo alto for what it means) and the portsnap command was unable to handle updates reporting always "file does not exist". After digging I found that the problem was in the phttpget command used internally from portsnap: phttpget is not able to handle an http_proxy variable in the form of http://user:password@proxy:port since the first colon is understood as a port separator and therefore phttpget tries to connect to the host "user" on port "password@proxy:port". Since I did not found much documentation about how to solve the problem, and nobody on the forum was able to point me in any direction (see http://forums.freebsd.org/showthread.php?t=28849) I wrote a simple patch to modify portsnap to use wget instead of phttpget. Of course, this means you have to install wget first, and also the laminating of the files to download has slightly changed within portsnap, but I'm using it from several days and updates now and it seems to work well. Now the question is: should this patch, or better the idea of using wget or another alike substitute to phttpget, be integrated into the system? I've tested it on FreeBSD-9-STABLE. Regards, Luca portsnap_wget.patch Description: Binary data ___ 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: Help review the FAQ
On 11/26/12 23:09, Bas Smeelen wrote: Probable addition 8.8 I get a lot of 'spurious interrupts detected' messages on a modified i386 build kernel and my computer does not work right. What did I do wrong? You have a single processor computer, build your own customized kernel and disabled options SMP (multiprocessor). Probably you also disabled the line below, device apic# I/O APIC This is code for the advanced programmable interrupt controller which also controls interrupts for your attached devices, being ethernet cards and others. Do not disable this device. While I don't know about apic, there used to be "KEEP THIS!!!" comments in GENERIC's conf file. I guess this would be more on the spot than a FAQ you'd read *after* removing this. Just my 2c. bye av. ___ 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: bge on the new Mac Mini
On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: > On 11/21/12 21:08, YongHyeon PYUN wrote: > > On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: > >> On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: > >>> On 11/20/12 03:52, YongHyeon PYUN wrote: > On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: > > Hi all, > > > > Over the last month or so I've installed FreeBSD 9 (-stable) on several > > Mac > > Minis via the memstick image; they seem to be pretty good little boxes > > for > > things like offsite secondary nameservers, for example, and they're > > easily > > replaced in case of problems. > > > > However, the newest minis have slightly different hardware, and FreeBSD > > can't > > find the built-in NIC. pciconf -lv on the new mini shows it as > > > > none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 > > rev=0x01 > > It seems this controller is BCM57766. > > > hdr=0x00 > > vendor = 'Broadcom Corporation' > > class = network > > subclass = ethernet > > > > The previous edition mini (that works) reports > > > > bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 > > rev=0x10 hdr=0x00 > > vendor = 'Broadcom Corporation' > > device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' > > class = network > > subclass = ethernet > > > > Is there a chance that adding the new card/chip info to the current > > driver would > > allow it to work? I'll be happy to test and report back. I'm afraid I'm > > not > > familiar enough with hardware at that level to figure out the patch > > myself. > > > > Try attached patch and let me know whether the patch works or not. > If the patch works please share dmesg output(bge(4) and brgphy(4) > output only). > Note, the patch was generated against CURRENT. > > >>> > >>> I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h > >>> from > >> > >> I guess you also need to copy brgphy.c from HEAD to > >> /usr/src/sys/dev/mii directory. > >> > >>> HEAD using svnweb.freebsd.org. The patch installed cleanly and there were > >>> no > >>> errors during the build, but still no NIC. > >> > >> Does it mean you're not seeing bge0 interface? Or you can't pass > >> any traffic via bge0? > > > > Oops, it seems I've not included your device ID in the diff. > > Try attach one instead. Make sure you use brgphy.c from HEAD. > > > > There's progress! With your latest patch using brgphy.c, if_bge.c, and > if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the > moment I try to configure it the box locks up completely; it won't even toggle > the caps lock LED. > > Booting single user and running ifconfig shows: > > bge0: flags=8802 metric 0 mtu 1500 > options=8009b > ether a8:20:66:11:3b:d6 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > > I did a verbose boot; here's the part that seems to be relevant to bge0: > > bge0: > mem > 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 > bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E ^ All these information are garbage which indicates a bug in the diff. > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: OUI 0x001be9, model 0x0024, rev. 1 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: bpf attached > bge0: Ethernet address: a8:20:66:11:3b:d6 > ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 > > I greatly appreciate your efforts. I'm sorry for the delay getting back with > you, but we had a busy Thanksgiving weekend. > Try again with attached bge.57766.diff3. Thanks for testing! ___ 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: Write Failed message with 9.1-RC3
Mark, Shutdown happens cleanly. My pciconf.log is attached. sysctl.conf is empty. Kernel is uncustomized amd64: FreeBSD herschel.biodesign.asu.edu 9.1-RC3 FreeBSD 9.1-RC3 #0 r242324: Tue Oct 30 00:58:57 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 loader.conf: zfs_load="YES" geom_eli_load="YES" ahci_load="YES" vfs.root.mountfrom="zfs:zroot" debug.acpi.max_tasks="128" #vboxdrv_load="YES" kern.maxfiles="65536" kldstat: Id Refs AddressSize Name 1 46 0x8020 1323388 kernel 21 0x81524000 2084d8 zfs.ko 32 0x8172d000 5c58 opensolaris.ko 41 0x81733000 1f988geom_eli.ko 52 0x81753000 2b470crypto.ko 62 0x8177f000 dde0 zlib.ko 71 0x81812000 15c2 fdescfs.ko 81 0x81814000 3dfc linprocfs.ko 92 0x81818000 1f3dclinux.ko 101 0x81838000 a0e linsysfs.ko 112 0x81839000 29f1 vboxnetflt.ko 122 0x8183c000 2c018vboxdrv.ko 132 0x81869000 87b2 netgraph.ko 141 0x81872000 1579 ng_ether.ko 151 0x81874000 3f8a vboxnetadp.ko 161 0x81878000 ce8a ipfw.ko 171 0x81885000 21d green_saver.ko ZFS Properties: NAME PROPERTY VALUE SOURCE storage mountpointlegacy local storage atime off local storage/home mountpoint/home local storage/jailsmountpoint/jails local storage/storage mountpoint /storage local zrootmountpointlegacy local zrootchecksum fletcher4 local storage/home xattr off temporary storage/jailsxattr off temporary storage/storage xattr off temporary storage/storage/tt xattr off temporary zrootxattr off temporary ZFS Status: pool: storage state: ONLINE scan: scrub repaired 0 in 9h21m with 0 errors on Sat Nov 17 12:23:44 2012 config: NAMESTATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 da6 ONLINE 0 0 0 da7 ONLINE 0 0 0 cache da8 ONLINE 0 0 0 errors: No known data errors pool: zroot state: ONLINE scan: scrub repaired 0 in 0h14m with 0 errors on Sat Nov 17 03:16:09 2012 config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 da11p2 ONLINE 0 0 0 da10p2 ONLINE 0 0 0 errors: No known data errors On Mon, Nov 26, 2012 at 9:09 PM, Mark Saad wrote: > > > > On Nov 26, 2012, at 4:01 PM, "Reed A. Cartwright" wrote: > >> I'm new to this list... >> >> I'm running a bioinformatics server using 9.1-RC3 (64 cores, 512GB >> ram). I have a ZFS raid-z2 array attached to an LSI controller with a >> SSD cache drive. > > Can you tell us more about this server . Can you post the output of pciconf > -lv , > What do you have in loader.conf and sysctl.conf ? Do you se a custom kernel > build; What are the changes you made to that config ? >> >> Since upgrading to 9.1-RC2/3 (for AVX support), I have been >> experiencing hard drive lockups with the message "write failed" >> printed to the console. After this reading from the hard drives no >> longer work, but the machine is not locked up. If the appropriate >> files are in the cache, I can log in and execute programs. I know the >> LSI driver has been updated in 9.1 and I have updated my cards' bios >> to match. It doesn't seem to make a difference. >> >> Once I was able to run top, and saw that many processes were stuck in >> the 'tx->tx' state. > > What does your zfs config look like can you post the output if zpool status ? > What zfz options have you set on pool and filesystens ? > > Lastly In a shutdown -h now , does the system properly shutdown ,does it > crash and dump core ? >> >> So far, no corruption appears to have occurred in the drives. >> >> I'm about to downgrade to 9.0, but I wanted
Re: Write Failed message with 9.1-RC3
On Nov 26, 2012, at 4:01 PM, "Reed A. Cartwright" wrote: > I'm new to this list... > > I'm running a bioinformatics server using 9.1-RC3 (64 cores, 512GB > ram). I have a ZFS raid-z2 array attached to an LSI controller with a > SSD cache drive. Can you tell us more about this server . Can you post the output of pciconf -lv , What do you have in loader.conf and sysctl.conf ? Do you se a custom kernel build; What are the changes you made to that config ? > > Since upgrading to 9.1-RC2/3 (for AVX support), I have been > experiencing hard drive lockups with the message "write failed" > printed to the console. After this reading from the hard drives no > longer work, but the machine is not locked up. If the appropriate > files are in the cache, I can log in and execute programs. I know the > LSI driver has been updated in 9.1 and I have updated my cards' bios > to match. It doesn't seem to make a difference. > > Once I was able to run top, and saw that many processes were stuck in > the 'tx->tx' state. What does your zfs config look like can you post the output if zpool status ? What zfz options have you set on pool and filesystens ? Lastly In a shutdown -h now , does the system properly shutdown ,does it crash and dump core ? > > So far, no corruption appears to have occurred in the drives. > > I'm about to downgrade to 9.0, but I wanted to know if anyone has any > idea what the issue is. > > -- > Reed A. Cartwright, PhD > Assistant Professor of Genomics, Evolution, and Bioinformatics > School of Life Sciences > Center for Evolutionary Medicine and Informatics > The Biodesign Institute > Arizona State University > ___ > 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" --- Mark saad | mark.s...@longcount.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RELEASE
On 11/26/12 23:48, Bas Smeelen wrote: On 11/26/12 23:36, Rick Miller wrote: On Mon, Nov 26, 2012 at 5:25 PM, Bas Smeelen wrote: Hi Just modify newvers.sh to 9.1-RELEASE recompile and your on RELEASE :) Who has a no non-release policy, management? It's not just management, Just to sum it up Make sure you document with second and third party approval! What you did and How you did it There is no reason to document for Why you did it, though this can be beneficial. With this, it comes to that the FreeBSD development and distributing model is very well, let's say highly transparent, it is up to you as a systems administrator or even developer (they are more out in the clear though) to account for (document and get this approved) and be transparant for all the actions that have been commited, to the FDA for instance in the industries (Pharma, Biomed, etc, I work in). I guess fbi, cia, nsa or other 'higher' governmental institutions don't have to account for this, because they are much smarter anyway. I apologise for the dutch grammar. Cheers checked, they don't have a clue, that's what we're here for but also software engineers, checked, mutually accepted, they know what you're up to, and keep them clear, be honest and even better, they know what they're up to, but try to blame you for just keep them as very close 'friends' it helps when you are able to 'clean up their messes sometimes' architects is like in between management and software engineers, dangerous maybe , and business folks. management or otherwise When a company runs a service whose production SLA is 100%, many tend to be less forgiving. 100% that's a dare! For them it may be 100%, for me I am at 98% then, at best 99,636% :) There is a lot of playfield unknown There's a lot riding on running a development branch in production, even if it is a "Release Candidate". Agree 100% :) RELEASE is better than RC or even BETA for sakes ;) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RELEASE
On 11/26/12 23:36, Rick Miller wrote: On Mon, Nov 26, 2012 at 5:25 PM, Bas Smeelen wrote: Hi Just modify newvers.sh to 9.1-RELEASE recompile and your on RELEASE :) Who has a no non-release policy, management? It's not just management, checked, they don't have a clue, that's what we're here for but also software engineers, checked, mutually accepted, they know what you're up to, and keep them clear, be honest and even better, they know what they're up to, but try to blame you for just keep them as very close 'friends' it helps when you are able to 'clean up their messes sometimes' architects is like in between management and software engineers, dangerous maybe , and business folks. management or otherwise When a company runs a service whose production SLA is 100%, many tend to be less forgiving. 100% that's a dare! For them it may be 100%, for me I am at 98% then, at best 99,636% :) There is a lot of playfield unknown There's a lot riding on running a development branch in production, even if it is a "Release Candidate". Agree 100% :) RELEASE is better than RC or even BETA for sakes ;) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RELEASE
On Mon, Nov 26, 2012 at 5:25 PM, Bas Smeelen wrote: > Hi > Just modify newvers.sh to 9.1-RELEASE recompile and your on RELEASE :) > Who has a no non-release policy, management? It's not just management, but also software engineers, architects, and business folks. When a company runs a service whose production SLA is 100%, many tend to be less forgiving. There's a lot riding on running a development branch in production, even if it is a "Release Candidate". -- Take care Rick Miller ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RELEASE
On 11/26/12 22:42, mat...@hush.ai wrote: Hi. With the recent delays from the security incident and the three SAs out of the way, what now are we waiting for? I think we should just get rid of the release schedule on FreeBSD.org if we aren't even going to be close to the set dates. RC3 has been really stable for me, but we have a no non-release policy on production machines. We're so far behind compared to http://www.freebsd.org/releases/9.1R/schedule.html (which has already been updated multiple times because of delay after delay) Hi Just modify newvers.sh to 9.1-RELEASE recompile and your on RELEASE :) Who has a no non-release policy, management? 9.1-RC3 is working for me very well also ___ 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"
9.1-RELEASE
Hi. With the recent delays from the security incident and the three SAs out of the way, what now are we waiting for? I think we should just get rid of the release schedule on FreeBSD.org if we aren't even going to be close to the set dates. RC3 has been really stable for me, but we have a no non-release policy on production machines. We're so far behind compared to http://www.freebsd.org/releases/9.1R/schedule.html (which has already been updated multiple times because of delay after delay) ___ 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: Help review the FAQ
On 11/20/12 20:25, Eitan Adler wrote: On 19 November 2012 15:07, Aldis Berjoza wrote: 19.11.2012, 22:04, "Andrea Venturoli" : On 11/19/12 18:44, Eitan Adler wrote: Hey all, The FAQ for FreeBSD needs a significant amount of updating and changing. The first step in that process is to figure out what needs to be changed. If you can a take a moment and thoroughly review just one question and add your comments and concerns it would be immensely helpful. http://wiki.freebsd.org/ThwackAFAQ ... I've migrated the comments on the mailing list to the wiki and will working on fixing them shortly. Content patches are appreciated but not required. Ideally every row on the wiki will be either green or red. Fixing the content is a very long term project. Probable addition 8.8 I get a lot of 'spurious interrupts detected' messages on a modified i386 build kernel and my computer does not work right. What did I do wrong? You have a single processor computer, build your own customized kernel and disabled options SMP (multiprocessor). Probably you also disabled the line below, device apic# I/O APIC This is code for the advanced programmable interrupt controller which also controls interrupts for your attached devices, being ethernet cards and others. Do not disable this device. ___ 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: Help review the FAQ
On 11/26/12 22:27, Schaich Alonso wrote: On 2012-11-26 (Monday) 22:15:27 Miroslav Lachman wrote: [...] So a kernel alone has 12MB, with debug symbols 62MB (12+50). And all *.symbols files can be deleted (if more space on /boot is needed) I don't know how it should be mentioned in FAQ. Miroslav Lachman Specifying WITHOUT_KERNEL_SYMBOLS=YES in src.conf to not generate debug information IMO is a cleaner and more preferable solution then deleting the files, and it also reduces the amount of storage space needed for /usr/obj (or whereever else the kernel's built) by about 1GB on STABLE-9. Thanks for this (man 5 src.conf) I guess this way is preferred instead of customizing the kernel configuration file? From the manpage I understand the symbol files will not get installed, but will still be build. To decrease building time, one should modify the kernel configuration file anyway? ___ 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: Help review the FAQ
On 2012-11-26 (Monday) 22:15:27 Miroslav Lachman wrote: > [...] > > So a kernel alone has 12MB, with debug symbols 62MB (12+50). > And all *.symbols files can be deleted (if more space on /boot is needed) > I don't know how it should be mentioned in FAQ. > > Miroslav Lachman Specifying WITHOUT_KERNEL_SYMBOLS=YES in src.conf to not generate debug information IMO is a cleaner and more preferable solution then deleting the files, and it also reduces the amount of storage space needed for /usr/obj (or whereever else the kernel's built) by about 1GB on STABLE-9. Schaich Alonso ___ 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: Help review the FAQ
On 11/26/12 22:20, Bas Smeelen wrote: On 11/26/12 22:02, Doug Hardie wrote: On 26 November 2012, at 12:53, Bas Smeelen wrote: On 11/26/12 21:27, Bas Smeelen wrote: On 11/26/12 17:25, Jakub Lach wrote: Thanks! Regarding FAQ, some info about journalling should be added to "Chapter 9 Disks, File Systems, and Boot Loaders", especially now, when SU+J is default. Please also add: SU+J does not work (yet) with dump on a live filesystem i.e. use snapshot. If you want to use snapshot (dump -L) then disable the soft updates journal for that filesystem It would be helpful to include information on how to do that during install (still trying to figure that out myself), and using the recover CD for when you forget to do it during install. Right now, when installing a new system it's easiest to reboot to single user mode after the install and tunefs -j disable 'the filesystems' to disable journaling of soft updates. When changing the root ( / ) filesystem in single user mode, reboot immediately after disabling the soft updates journal otherwise it will still be enabled. No need for a rescue cd/usb here. If you want to accomplish this during the install, choose shell at the disk partitioning part and add slices and/or partitions with gpart and then newfs them with the appropriate options, then mount them on /mnt and the appropriate places beneath and continue the install by quitting the shell. There are some nice entries on http://wiki.freebsd.org/RootOnZFS Just substitute the ZFS stuff with the easier gpart and then newfs -U etc... then make sure the filesystems are mounted under /mnt and continue the installation. I hope that I will not confuse you too much with the proposed solution i.e. use these resources as a guideline. Else see reboot to single user mode after install above and tunefs ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Help review the FAQ
On 11/26/12 22:15, Miroslav Lachman wrote: Bas Smeelen wrote: On 11/26/12 16:57, Jakub Lach wrote: [...] Thanks Miroslav Lachman for the reply with the correct sizes for GENERIC kernels. Change FAQ 8.3 Why is my kernel so big? Nowadays kernels are compiled in /debug mode by default/. Kernels built in debug mode contain many symbols that are used for debugging, thus greatly increasing the size of the kernel. Note that there will be little or no performance decrease from running a debug kernel, and it is useful in case of a system panic. However I think that debug symbols are in another files (*.symbols) FreeBSD 8.3-RELEASE amd64 GENERIC > ls -lh /boot/kernel/kernel* -r-xr-xr-x 1 root wheel 12M May 8 2012 /boot/kernel/kernel -r-xr-xr-x 1 root wheel 50M May 8 2012 /boot/kernel/kernel.symbols So a kernel alone has 12MB, with debug symbols 62MB (12+50). And all *.symbols files can be deleted (if more space on /boot is needed) I don't know how it should be mentioned in FAQ. You are right. From the FAQ I understand with 'kernel so big' the contents of the /boot/kernel directory is being referred to as a whole? Thus disabling (commenting) makeoptions DEBUG=-g (which is default the last couple of releases, since 7?) and then rebuilding and installing the kernel you get rid if them 'the right way' So FAQ 8.3 is still right just changing that nowadays it's default for GENERIC to be build with the debug symbols. ___ 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: When did Xorg remove support for keyboards, and mice?!
Greetings Ian, and thank you for your reply... > On Mon, 2012-11-26 at 12:25 -0800, Chris H wrote: >> Greetings, >> Seems I get bitten by this every time I build a desktop on a new freebsd >> install. >> After all these years, I'd have the _definitive_ answer by now. >> I just put (built) a copy of 8.3 on an x(i)386 (AMD32) box. Built/installed >> kernel && world. All went pretty well. Just finished building Xorg and >> friends. >> Chose xfce4 as a desktop. The mouse and keyboard work "famously" on a tty. >> But >> HALD(8) && DBUS haven't a clue. I get the idea these have been abandoned. :/ >> Anyway, I have hald_enable="YES" and dbus_enable="YES" in rc.conf(5). >> I have the following in xorg.conf: >> Section "ServerLayout" >> Identifier "Layout0" >> Screen 0 "Screen0" >> InputDevice"Keyboard0" "CoreKeyboard" >> InputDevice"Mouse0" "CorePointer" >> Also tried: >> Option "AutoAddDevices" "false" >> but didn't work. >> >> Section "InputDevice" >> # generated from default >> Identifier "Mouse0" >> Driver "mouse" >> Option "Protocol" "auto" >> Option "Device" "/dev/sysmouse" >> Option "ZAxisMapping" "4 5 6 7" >> EndSection >> >> Section "InputDevice" >> # generated from default >> Identifier "Keyboard0" >> Driver "keyboard" >> EndSection >> >> The error(s) returned when attempting to use X is|are: >> (II) config/hal: Adding input device AT Keyboard >> (II) LoadModule: "kbd" >> (WW) Warning, couldn't open module kbd >> (II) UnloadModule: "kbd" >> (EE) Failed to load module "kbd" (module does not exist, 0) >> (EE) No input driver matching `kbd' >> (EE) config/hal: NewInputDeviceRequest failed (15) >> (II) config/hal: Adding input device PS/2 Mouse >> (II) LoadModule: "mouse" >> (WW) Warning, couldn't open module mouse >> (II) UnloadModule: "mouse" >> (EE) Failed to load module "mouse" (module does not exist, 0) >> (EE) No input driver matching `mouse' >> (EE) config/hal: NewInputDeviceRequest failed (15) >> >> There is nothing in dmesg(8) to indicate any trouble. >> >> Whats a person to do? install Windows? OSX? >> >> Thank you for all your time and consideration. > > Have you tried just not having an xorg.conf file? I'm running 8.3 with > hal and it's working just fine for me with no conf file. > > Also, from those messages, I'd guess it's detecting the hardware, then > failing to find the drivers. If so, I suppose it could be because > they're missing, or because of a path problem of some sort. For me, the > drivers are in: > > revolution > ll /usr/local/lib/xorg/modules/input/ > total 82 > -rwxr-xr-x 1 root wheel 919B Feb 12 2012 kbd_drv.la* > -rwxr-xr-x 1 root wheel24k Feb 12 2012 kbd_drv.so* > -rwxr-xr-x 1 root wheel 933B Feb 12 2012 mouse_drv.la* > -rwxr-xr-x 1 root wheel50k Feb 12 2012 mouse_drv.so* > > -- Ian Right you are! I was about to respond to my OP, but you beat me to it. I'm running another copy of 8.3 (albeit on an AMD64), and was comparing installed files, and noticed _exactly_ that which you so _rightly_ pointed out; the absence of kbd && mouse drivers. I can't figure why they didn't get installed this time. I tried pretty hard to follow the same path as my last install. D'OH! Anyway, thank you again Ian. I _really_ appreciate it. --Chris > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Help review the FAQ
On 11/26/12 22:02, Doug Hardie wrote: On 26 November 2012, at 12:53, Bas Smeelen wrote: On 11/26/12 21:27, Bas Smeelen wrote: On 11/26/12 17:25, Jakub Lach wrote: Thanks! Regarding FAQ, some info about journalling should be added to "Chapter 9 Disks, File Systems, and Boot Loaders", especially now, when SU+J is default. Please also add: SU+J does not work (yet) with dump on a live filesystem i.e. use snapshot. If you want to use snapshot (dump -L) then disable the soft updates journal for that filesystem It would be helpful to include information on how to do that during install (still trying to figure that out myself), and using the recover CD for when you forget to do it during install. Right now, when installing a new system it's easiest to reboot to single user mode after the install and tunefs -j disable 'the filesystems' to disable journaling of soft updates. If you want to accomplish this during the install, choose shell at the disk partitioning part and add slices and/or partitions with gpart and then newfs them with the appropriate options, then mount them on /mnt and the appropriate places beneath and continue the install by quitting the shell. There are some nice entries on http://wiki.freebsd.org/RootOnZFS Just substitute the ZFS stuff with the easier gpart and then newfs -U etc... then make sure the filesystems are mounted under /mnt and continue the installation. I hope that I will not confuse you too much with the proposed solution i.e. use these resources as a guideline. Else see reboot to single user mode after install above and tunefs ___ 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: Help review the FAQ
Bas Smeelen wrote: On 11/26/12 16:57, Jakub Lach wrote: [...] Thanks Miroslav Lachman for the reply with the correct sizes for GENERIC kernels. Change FAQ 8.3 Why is my kernel so big? Nowadays kernels are compiled in /debug mode by default/. Kernels built in debug mode contain many symbols that are used for debugging, thus greatly increasing the size of the kernel. Note that there will be little or no performance decrease from running a debug kernel, and it is useful in case of a system panic. However I think that debug symbols are in another files (*.symbols) FreeBSD 8.3-RELEASE amd64 GENERIC > ls -lh /boot/kernel/kernel* -r-xr-xr-x 1 root wheel 12M May 8 2012 /boot/kernel/kernel -r-xr-xr-x 1 root wheel 50M May 8 2012 /boot/kernel/kernel.symbols So a kernel alone has 12MB, with debug symbols 62MB (12+50). And all *.symbols files can be deleted (if more space on /boot is needed) I don't know how it should be mentioned in FAQ. Miroslav Lachman ___ 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: Help review the FAQ
On 26 November 2012, at 12:53, Bas Smeelen wrote: > On 11/26/12 21:27, Bas Smeelen wrote: >> On 11/26/12 17:25, Jakub Lach wrote: >>> Thanks! >>> >>> Regarding FAQ, some info about journalling should be added to >>> "Chapter 9 Disks, File Systems, and Boot Loaders", especially now, >>> when SU+J is default. > > Please also add: > SU+J does not work (yet) with dump on a live filesystem i.e. use snapshot. > If you want to use snapshot (dump -L) then disable the soft updates journal > for that filesystem It would be helpful to include information on how to do that during install (still trying to figure that out myself), and using the recover CD for when you forget to do it during install. ___ 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"
Write Failed message with 9.1-RC3
I'm new to this list... I'm running a bioinformatics server using 9.1-RC3 (64 cores, 512GB ram). I have a ZFS raid-z2 array attached to an LSI controller with a SSD cache drive. Since upgrading to 9.1-RC2/3 (for AVX support), I have been experiencing hard drive lockups with the message "write failed" printed to the console. After this reading from the hard drives no longer work, but the machine is not locked up. If the appropriate files are in the cache, I can log in and execute programs. I know the LSI driver has been updated in 9.1 and I have updated my cards' bios to match. It doesn't seem to make a difference. Once I was able to run top, and saw that many processes were stuck in the 'tx->tx' state. So far, no corruption appears to have occurred in the drives. I'm about to downgrade to 9.0, but I wanted to know if anyone has any idea what the issue is. -- Reed A. Cartwright, PhD Assistant Professor of Genomics, Evolution, and Bioinformatics School of Life Sciences Center for Evolutionary Medicine and Informatics The Biodesign Institute Arizona State University ___ 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: When did Xorg remove support for keyboards, and mice?!
On Mon, 2012-11-26 at 12:25 -0800, Chris H wrote: > Greetings, > Seems I get bitten by this every time I build a desktop on a new freebsd > install. > After all these years, I'd have the _definitive_ answer by now. > I just put (built) a copy of 8.3 on an x(i)386 (AMD32) box. Built/installed > kernel && world. All went pretty well. Just finished building Xorg and > friends. > Chose xfce4 as a desktop. The mouse and keyboard work "famously" on a tty. But > HALD(8) && DBUS haven't a clue. I get the idea these have been abandoned. :/ > Anyway, I have hald_enable="YES" and dbus_enable="YES" in rc.conf(5). > I have the following in xorg.conf: > Section "ServerLayout" > Identifier "Layout0" > Screen 0 "Screen0" > InputDevice"Keyboard0" "CoreKeyboard" > InputDevice"Mouse0" "CorePointer" > Also tried: > Option"AutoAddDevices" "false" > but didn't work. > > Section "InputDevice" > # generated from default > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/sysmouse" > Option "ZAxisMapping" "4 5 6 7" > EndSection > > Section "InputDevice" > # generated from default > Identifier "Keyboard0" > Driver "keyboard" > EndSection > > The error(s) returned when attempting to use X is|are: > (II) config/hal: Adding input device AT Keyboard > (II) LoadModule: "kbd" > (WW) Warning, couldn't open module kbd > (II) UnloadModule: "kbd" > (EE) Failed to load module "kbd" (module does not exist, 0) > (EE) No input driver matching `kbd' > (EE) config/hal: NewInputDeviceRequest failed (15) > (II) config/hal: Adding input device PS/2 Mouse > (II) LoadModule: "mouse" > (WW) Warning, couldn't open module mouse > (II) UnloadModule: "mouse" > (EE) Failed to load module "mouse" (module does not exist, 0) > (EE) No input driver matching `mouse' > (EE) config/hal: NewInputDeviceRequest failed (15) > > There is nothing in dmesg(8) to indicate any trouble. > > Whats a person to do? install Windows? OSX? > > Thank you for all your time and consideration. Have you tried just not having an xorg.conf file? I'm running 8.3 with hal and it's working just fine for me with no conf file. Also, from those messages, I'd guess it's detecting the hardware, then failing to find the drivers. If so, I suppose it could be because they're missing, or because of a path problem of some sort. For me, the drivers are in: revolution > ll /usr/local/lib/xorg/modules/input/ total 82 -rwxr-xr-x 1 root wheel 919B Feb 12 2012 kbd_drv.la* -rwxr-xr-x 1 root wheel24k Feb 12 2012 kbd_drv.so* -rwxr-xr-x 1 root wheel 933B Feb 12 2012 mouse_drv.la* -rwxr-xr-x 1 root wheel50k Feb 12 2012 mouse_drv.so* -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Help review the FAQ
This may be request for new questions, or this can be supplemented partially in hardware ones I think; - new default partition layout and it's justification (single partition nowadays, I believe?) - default block size and it's justification (is it 4K? why?) - NCQ support with ada/ahci - ahci power managment [*] - why or why not default settings are just fine with SSD (regarding journaling, SU, trim and what not). Sorry for requesting content rather than reviewing existing one, but I think this info important for modern FAQ. * power-management-support description is lacking, apm is obsolete, no mention of ahci. I think this is more of less complete sketch of power saving facilities in FreeBSD- http://wiki.freebsd.org/TuningPowerConsumption -- View this message in context: http://freebsd.1045724.n5.nabble.com/Help-review-the-FAQ-tp5762326p5764423.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Help review the FAQ
On 11/26/12 21:27, Bas Smeelen wrote: On 11/26/12 17:25, Jakub Lach wrote: Thanks! Regarding FAQ, some info about journalling should be added to "Chapter 9 Disks, File Systems, and Boot Loaders", especially now, when SU+J is default. Please also add: SU+J does not work (yet) with dump on a live filesystem i.e. use snapshot. If you want to use snapshot (dump -L) then disable the soft updates journal for that filesystem Add to FAQ 9.4 Which partitions can safely use Soft Updates? I have heard that Soft Updates on / can cause problems. Journaled Soft Updates (SU+J) is now default on FreeBSD 9.x-RELEASE installs. This feature keeps a journal on soft updates which avoids a background filesystem check and speeds up a filesystem check during boot to a few seconds or less. For history and technical details see: http://jeffr-tech.livejournal.com/22716.html and http://www.*bsdcan*.org/2010/schedule/attachments/141_suj-slides.pdf This can also be enabled/disabled with tunefs -j enable | disable For more information see man 8 tunefs New FAQ 9.28 I have heard about TRIM for Solid State Drives (SSD), is it supported by FreeBSD? The TRIM filesystem flag is very useful for devices that use flash-memory (SSD for instance) and support the BIO_DELETE command. This flag is not enabled by default and can be enabled/disabled with tunefs -t enable | disable For more information see man 8 tunefs -t enable | disable Turn on/off the TRIM enable flag. If enabled, and if the under- lying device supports the BIO_DELETE command, the file system will send a delete request to the underlying device for each freed block. The trim enable flag is typically set when the underlying device uses flash-memory as the device can use the delete command to pre-zero or at least avoid copying blocks that have been deleted. Important when using tunefs: This utility does not work on active file systems. To change the root file system, the system must be rebooted after the file system is tuned. FIlesystems have to be mounted read-only or not mounted at all ___ 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"
When did Xorg remove support for keyboards, and mice?!
Greetings, Seems I get bitten by this every time I build a desktop on a new freebsd install. After all these years, I'd have the _definitive_ answer by now. I just put (built) a copy of 8.3 on an x(i)386 (AMD32) box. Built/installed kernel && world. All went pretty well. Just finished building Xorg and friends. Chose xfce4 as a desktop. The mouse and keyboard work "famously" on a tty. But HALD(8) && DBUS haven't a clue. I get the idea these have been abandoned. :/ Anyway, I have hald_enable="YES" and dbus_enable="YES" in rc.conf(5). I have the following in xorg.conf: Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" InputDevice"Keyboard0" "CoreKeyboard" InputDevice"Mouse0" "CorePointer" Also tried: Option "AutoAddDevices" "false" but didn't work. Section "InputDevice" # generated from default Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "InputDevice" # generated from default Identifier "Keyboard0" Driver "keyboard" EndSection The error(s) returned when attempting to use X is|are: (II) config/hal: Adding input device AT Keyboard (II) LoadModule: "kbd" (WW) Warning, couldn't open module kbd (II) UnloadModule: "kbd" (EE) Failed to load module "kbd" (module does not exist, 0) (EE) No input driver matching `kbd' (EE) config/hal: NewInputDeviceRequest failed (15) (II) config/hal: Adding input device PS/2 Mouse (II) LoadModule: "mouse" (WW) Warning, couldn't open module mouse (II) UnloadModule: "mouse" (EE) Failed to load module "mouse" (module does not exist, 0) (EE) No input driver matching `mouse' (EE) config/hal: NewInputDeviceRequest failed (15) There is nothing in dmesg(8) to indicate any trouble. Whats a person to do? install Windows? OSX? Thank you for all your time and consideration. ___ 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: Help review the FAQ
On 11/26/12 16:57, Jakub Lach wrote: As a reminder, this isn't a contest in kernel size :) Didn't mean to, I just put it there to state that 1.5 - 2.5 MB for a GENERIC kernel is not appropriate anymore. More useful would be if somebody would check GENERIC on i386/amd64 for FAQ update. Thanks Miroslav Lachman for the reply with the correct sizes for GENERIC kernels. Change FAQ 8.3 Why is my kernel so big? Nowadays kernels are compiled in /debug mode by default/. Kernels built in debug mode contain many symbols that are used for debugging, thus greatly increasing the size of the kernel. Note that there will be little or no performance decrease from running a debug kernel, and it is useful in case of a system panic. However ___ 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: Help review the FAQ
On 11/26/12 17:25, Jakub Lach wrote: Thanks! Regarding FAQ, some info about journalling should be added to "Chapter 9 Disks, File Systems, and Boot Loaders", especially now, when SU+J is default. Add to FAQ 9.4 Which partitions can safely use Soft Updates? I have heard that Soft Updates on / can cause problems. Journaled Soft Updates (SU+J) is now default on FreeBSD 9.x-RELEASE installs. This feature keeps a journal on soft updates which avoids a background filesystem check and speeds up a filesystem check during boot to a few seconds or less. For history and technical details see: http://jeffr-tech.livejournal.com/22716.html and http://www.*bsdcan*.org/2010/schedule/attachments/141_suj-slides.pdf This can also be enabled/disabled with tunefs -j enable | disable For more information see man 8 tunefs New FAQ 9.28 I have heard about TRIM for Solid State Drives (SSD), is it supported by FreeBSD? The TRIM filesystem flag is very useful for devices that use flash-memory (SSD for instance) and support the BIO_DELETE command. This flag is not enabled by default and can be enabled/disabled with tunefs -t enable | disable For more information see man 8 tunefs -t enable | disable Turn on/off the TRIM enable flag. If enabled, and if the under- lying device supports the BIO_DELETE command, the file system will send a delete request to the underlying device for each freed block. The trim enable flag is typically set when the underlying device uses flash-memory as the device can use the delete command to pre-zero or at least avoid copying blocks that have been deleted. Important when using tunefs: This utility does not work on active file systems. To change the root file system, the system must be rebooted after the file system is tuned. FIlesystems have to be mounted read-only or not mounted at all ___ 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: Samsung SSD 840 PRO fails to probe
On 11/26/12 14:27, Alexander Motin wrote:
Hi.
On 26.11.2012 20:51, Adam McDougall wrote:
My co-worker ordered a Samsung 840 PRO series SSD for his desktop but we
found 9.0-rel would not probe it and 9.1-rc3 shows some errors. I got
past the problem with a workaround of disabling AHCI mode in the BIOS
which drops it to IDE mode and it detects fine, although runs a little
slower. Is there something I can try to make it probe properly in AHCI
mode? We also tried moving it to the SATA data and power cables from
the working SATA HD so I don't think it is the port or controller
driver. The same model motherboard from another computer did the same
thing. Thanks.
dmesg line when it is working:
ada0: ATA-9 SATA 3.x device
dmesg lines when it is not working: (hand transcribed from a picture)
(aprobe0:ahcich0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00
00 40 00 00 00 00 05 00
(aprobe0:ahcich0:0:0): CAM status: ATA Status Error
(aprobe0:ahcich0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT )
(aprobe0:ahcich0:0:0): RES: 51 04 00 00 00 40 00 00 00 00 00
(aprobe0:ahcich0:0:0): Retrying command
(aprobe0:ahcich0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00
00 40 00 00 00 00 05 00
(aprobe0:ahcich0:0:0): CAM status: ATA Status Error
(aprobe0:ahcich0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT )
(aprobe0:ahcich0:0:0): RES: 51 04 00 00 00 40 00 00 00 00 00
(aprobe0:ahcich0:0:0): Error 5, Retries exhausted
I believe that is SSD's firmware bug. Probably it declares support for
SATA Asynchronous Notifications in its IDENTIFY data, but returns error
on attempt to enable it. Switching controller to legacy mode disables
that functionality and so works as workaround. Patch below should
workaround the problem from the OS side:
--- ata_xpt.c (revision 243561)
+++ ata_xpt.c (working copy)
@@ -745,6 +745,14 @@ probedone(struct cam_periph *periph, union ccb *do
goto noerror;
/*
+* Some Samsung SSDs report supported Asynchronous
Notification,
+* but return ABORT on attempt to enable it.
+*/
+ } else if (softc->action == PROBE_SETAN &&
+ status == CAM_ATA_STATUS_ERROR) {
+ goto noerror;
+
+ /*
* SES and SAF-TE SEPs have different IDENTIFY commands,
* but SATA specification doesn't tell how to identify
them.
* Until better way found, just try another if first fail.
Thanks for the prompt response and patch, that worked!
___
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: Samsung SSD 840 PRO fails to probe
Hi.
On 26.11.2012 20:51, Adam McDougall wrote:
My co-worker ordered a Samsung 840 PRO series SSD for his desktop but we
found 9.0-rel would not probe it and 9.1-rc3 shows some errors. I got
past the problem with a workaround of disabling AHCI mode in the BIOS
which drops it to IDE mode and it detects fine, although runs a little
slower. Is there something I can try to make it probe properly in AHCI
mode? We also tried moving it to the SATA data and power cables from
the working SATA HD so I don't think it is the port or controller
driver. The same model motherboard from another computer did the same
thing. Thanks.
dmesg line when it is working:
ada0: ATA-9 SATA 3.x device
dmesg lines when it is not working: (hand transcribed from a picture)
(aprobe0:ahcich0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00
00 40 00 00 00 00 05 00
(aprobe0:ahcich0:0:0): CAM status: ATA Status Error
(aprobe0:ahcich0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT )
(aprobe0:ahcich0:0:0): RES: 51 04 00 00 00 40 00 00 00 00 00
(aprobe0:ahcich0:0:0): Retrying command
(aprobe0:ahcich0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00
00 40 00 00 00 00 05 00
(aprobe0:ahcich0:0:0): CAM status: ATA Status Error
(aprobe0:ahcich0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT )
(aprobe0:ahcich0:0:0): RES: 51 04 00 00 00 40 00 00 00 00 00
(aprobe0:ahcich0:0:0): Error 5, Retries exhausted
I believe that is SSD's firmware bug. Probably it declares support for
SATA Asynchronous Notifications in its IDENTIFY data, but returns error
on attempt to enable it. Switching controller to legacy mode disables
that functionality and so works as workaround. Patch below should
workaround the problem from the OS side:
--- ata_xpt.c (revision 243561)
+++ ata_xpt.c (working copy)
@@ -745,6 +745,14 @@ probedone(struct cam_periph *periph, union ccb *do
goto noerror;
/*
+* Some Samsung SSDs report supported Asynchronous
Notification,
+* but return ABORT on attempt to enable it.
+*/
+ } else if (softc->action == PROBE_SETAN &&
+ status == CAM_ATA_STATUS_ERROR) {
+ goto noerror;
+
+ /*
* SES and SAF-TE SEPs have different IDENTIFY commands,
* but SATA specification doesn't tell how to identify
them.
* Until better way found, just try another if first fail.
--
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"
Samsung SSD 840 PRO fails to probe
Hello, My co-worker ordered a Samsung 840 PRO series SSD for his desktop but we found 9.0-rel would not probe it and 9.1-rc3 shows some errors. I got past the problem with a workaround of disabling AHCI mode in the BIOS which drops it to IDE mode and it detects fine, although runs a little slower. Is there something I can try to make it probe properly in AHCI mode? We also tried moving it to the SATA data and power cables from the working SATA HD so I don't think it is the port or controller driver. The same model motherboard from another computer did the same thing. Thanks. dmesg line when it is working: ada0: ATA-9 SATA 3.x device dmesg lines when it is not working: (hand transcribed from a picture) (aprobe0:ahcich0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00 00 40 00 00 00 00 05 00 (aprobe0:ahcich0:0:0): CAM status: ATA Status Error (aprobe0:ahcich0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (aprobe0:ahcich0:0:0): RES: 51 04 00 00 00 40 00 00 00 00 00 (aprobe0:ahcich0:0:0): Retrying command (aprobe0:ahcich0:0:0): SETFEATURES ENABLE SATA FEATURE. ACB: ef 10 00 00 00 40 00 00 00 00 05 00 (aprobe0:ahcich0:0:0): CAM status: ATA Status Error (aprobe0:ahcich0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (aprobe0:ahcich0:0:0): RES: 51 04 00 00 00 40 00 00 00 00 00 (aprobe0:ahcich0:0:0): Error 5, Retries exhausted ___ 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: Help review the FAQ
On 26 November 2012 11:25, Jakub Lach wrote: > Thanks! > > Regarding FAQ, some info about journalling should be added to > "Chapter 9 Disks, File Systems, and Boot Loaders", especially now, > when SU+J is default. which question does this apply to, or is this a request for new questions? -- Eitan Adler ___ 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: Help review the FAQ
Thanks! Regarding FAQ, some info about journalling should be added to "Chapter 9 Disks, File Systems, and Boot Loaders", especially now, when SU+J is default. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Help-review-the-FAQ-tp5762326p5764360.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Help review the FAQ
Jakub Lach wrote: As a reminder, this isn't a contest in kernel size :) More useful would be if somebody would check GENERIC on i386/amd64 for FAQ update. FreeBSD 8.3-RELEASE amd64 GENERIC > ls -lh /boot/kernel/kernel -r-xr-xr-x 1 root wheel12M May 8 2012 /boot/kernel/kernel FreeBSD 8.2-RELEASE-p3 i386 GENERIC > ls -lh /boot/kernel/kernel -r-xr-xr-x 1 root wheel11M Jan 8 2012 /boot/kernel/kernel FreeBSD 9.0-RELEASE amd64 GENERIC > ls -lh /boot/kernel/kernel -r-xr-xr-x 1 root wheel14M Jan 3 2012 /boot/kernel/kernel Miroslav Lachman ___ 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: Help review the FAQ
As a reminder, this isn't a contest in kernel size :) More useful would be if somebody would check GENERIC on i386/amd64 for FAQ update. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Help-review-the-FAQ-tp5762326p5764353.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Help review the FAQ
Again, sorry for confusion :) ls -la /boot/kernel/kernel -r-xr-xr-x 1 root wheel 5842267 25 lis 18:32 /boot/kernel/kernel Yes, it could be artificially smaller still, but delegating to modules things I would load witch each startup would be absurd. First size was whole directory with modules. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Help-review-the-FAQ-tp5762326p5764351.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Help review the FAQ
On 11/26/2012 04:26 PM, Volodymyr Kostyrko wrote: 26.11.2012 16:49, Jakub Lach: Absolutely not, it's a heavily stripped custom kernel on this machine on /boot/. Do you call this heavily stripped? :) > ls -la /boot/kernel/kernel -r-xr-xr-x 1 root wheel 5757970 Nov 26 10:57 /boot/kernel/kernel However it's very hard to strip kernel further and make it usable for all machines. I was pointing to that, if my kernel is 9 MB, there's no way GENERIC could be 1.5-2.5 MB. That's true... i386 kernel with the only devices I need without debug symbols is 4.5MB on 7.4-STABLE fb1:/home/Freebee % uname -a FreeBSD fb1 7.4-STABLE FreeBSD 7.4-STABLE #7: Mon Nov 26 11:27:42 CET 2012 root@fb1:/usr/obj/usr/src/sys/FB1 i386 fb1:/home/Freebee % ls -lh /boot/kernel/kernel -r-xr-xr-x 1 root wheel 4.6M Nov 26 11:27 /boot/kernel/kernel amd64 same story on 9.1-RC3 is 6.3MB [Freebee@sys:~] $ uname -a FreeBSD sys 9.1-RC3 FreeBSD 9.1-RC3 #0: Wed Oct 31 11:56:55 CET 2012 root@sys:/usr/obj/usr/src/sys/SYS amd64 [Freebee@sys:~] $ ls -hl /boot/kernel/kernel -r-xr-xr-x 1 root wheel 6.3M Oct 31 11:56 /boot/kernel/kernel ___ 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: Help review the FAQ
26.11.2012 16:49, Jakub Lach: Absolutely not, it's a heavily stripped custom kernel on this machine on /boot/. Do you call this heavily stripped? :) > ls -la /boot/kernel/kernel -r-xr-xr-x 1 root wheel 5757970 Nov 26 10:57 /boot/kernel/kernel However it's very hard to strip kernel further and make it usable for all machines. I was pointing to that, if my kernel is 9 MB, there's no way GENERIC could be 1.5-2.5 MB. That's true... -- Sphinx of black quartz, judge my vow. ___ 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: bge on the new Mac Mini
On 11/21/12 21:08, YongHyeon PYUN wrote: > On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: >> On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: >>> On 11/20/12 03:52, YongHyeon PYUN wrote: On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: > Hi all, > > Over the last month or so I've installed FreeBSD 9 (-stable) on several > Mac > Minis via the memstick image; they seem to be pretty good little boxes for > things like offsite secondary nameservers, for example, and they're easily > replaced in case of problems. > > However, the newest minis have slightly different hardware, and FreeBSD > can't > find the built-in NIC. pciconf -lv on the new mini shows it as > > none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 > rev=0x01 It seems this controller is BCM57766. > hdr=0x00 > vendor = 'Broadcom Corporation' > class = network > subclass = ethernet > > The previous edition mini (that works) reports > > bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' > class = network > subclass = ethernet > > Is there a chance that adding the new card/chip info to the current > driver would > allow it to work? I'll be happy to test and report back. I'm afraid I'm > not > familiar enough with hardware at that level to figure out the patch > myself. > Try attached patch and let me know whether the patch works or not. If the patch works please share dmesg output(bge(4) and brgphy(4) output only). Note, the patch was generated against CURRENT. >>> >>> I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h from >> >> I guess you also need to copy brgphy.c from HEAD to >> /usr/src/sys/dev/mii directory. >> >>> HEAD using svnweb.freebsd.org. The patch installed cleanly and there were no >>> errors during the build, but still no NIC. >> >> Does it mean you're not seeing bge0 interface? Or you can't pass >> any traffic via bge0? > > Oops, it seems I've not included your device ID in the diff. > Try attach one instead. Make sure you use brgphy.c from HEAD. > There's progress! With your latest patch using brgphy.c, if_bge.c, and if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the moment I try to configure it the box locks up completely; it won't even toggle the caps lock LED. Booting single user and running ifconfig shows: bge0: flags=8802 metric 0 mtu 1500 options=8009b ether a8:20:66:11:3b:d6 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active I did a verbose boot; here's the part that seems to be relevant to bge0: bge0: mem 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x001be9, model 0x0024, rev. 1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: a8:20:66:11:3b:d6 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 I greatly appreciate your efforts. I'm sorry for the delay getting back with you, but we had a busy Thanksgiving weekend. Thank you! -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: Help review the FAQ
Absolutely not, it's a heavily stripped custom kernel on this machine on /boot/. I was pointing to that, if my kernel is 9 MB, there's no way GENERIC could be 1.5-2.5 MB. Sorry for confusion. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Help-review-the-FAQ-tp5762326p5764313.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: buildworld with clang breaks because no cc
Dimitry Andric-4 wrote > As said earlier, since you seem to be doing multithreaded builds, the > actual error is obscured here. It will have occurred some time before > the part of the log you posted. Thanks for your help Dimitry. I commented out THREADS = 6 in buildflags.conf and re-ran make release. The build completed without any error - so it was just the threaded make that was causing the relase problem. Regards. -- View this message in context: http://freebsd.1045724.n5.nabble.com/buildworld-with-clang-breaks-because-no-cc-tp5763472p5764283.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: buildworld with clang breaks because no cc
On 2012-11-26 12:11, Beeblebrox wrote: Some strange errors continue - I'm not complaining, just informing: /asp/src/release > # make release OR # make cdrom etc.. breaks at kernel.txz: ===> zlib (install) install -o root -g wheel -m 555 zlib.ko //usr/obj/asp/src/release/dist/kernel/boot/kernel kldxref //usr/obj/asp/src/release/dist/kernel/boot/kernel 1 error *** [kernel.txz] Error code 2 As said earlier, since you seem to be doing multithreaded builds, the actual error is obscured here. It will have occurred some time before the part of the log you posted. Can you upload the full log somewhere? ___ 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: buildworld with clang breaks because no cc
Some strange errors continue - I'm not complaining, just informing:
/asp/src/release > # make release OR # make cdrom etc.. breaks at
kernel.txz:
===> zlib (install)
install -o root -g wheel -m 555 zlib.ko
//usr/obj/asp/src/release/dist/kernel/boot/kernel
kldxref //usr/obj/asp/src/release/dist/kernel/boot/kernel
1 error
*** [kernel.txz] Error code 2
If I remove in /etc/make.conf the call to buildflags.conf and just have in
make.conf:
CC=clang
CXX=clang++
CPP=clang-cpp
Then it works without any problems. My buildflags.conf as before only has:
/asp/src | /asp/src/* | /usr/src | /usr/src/*{
CC= clang
CPP=clang-cpp
CXX=clang++
# USE_CCACHE
# USE_CCACHE_CPP2
# USE_DISTCC
THREADS=6
NO_CLEAN
}
/asp/ports | /asp/ports/*{ stuff...
Regards.
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/buildworld-with-clang-breaks-because-no-cc-tp5763472p5764269.html
Sent from the freebsd-stable mailing list archive at Nabble.com.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Some new hardware with 9.1 does not reboot easily
on 26/11/2012 12:10 Patrick Lamaiziere said the following: > As far I can see it fails because there is no getnewvnode_reserve() > / get_newvnode_drop_reserve() in 9.1. The patch is for stable/9. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Some new hardware with 9.1 does not reboot easily
Le Fri, 23 Nov 2012 23:41:32 +0100, Willem Jan Withagen a écrit : Hello, > >> I'm waiting for the system to come back up, and will put the svn > >> diff on my webserver, unless it is oke to post a 1200 lines of > >> diff?? > > > > I think that a webserver option would be better. > > Thanks again. > > Oke, > > Diff is at: > http://www.tegenbosch28.nl/FreeBSD/Diffs/9.1-ZFS-reboot.diff > And is against a checkout of this morning: r243433 > Hope it works for others. Hmm, the patch does not apply on r243433. -- |Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c |=== |--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c (revision 243433) |+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c (working copy) -- Patching file sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c using Plan A... Hunk #1 succeeded at 1717 (offset -42 lines). Hunk #2 succeeded at 1809 (offset -42 lines). Hunk #3 succeeded at 1843 (offset -42 lines). Hunk #4 succeeded at 1880 (offset -42 lines). Hunk #5 succeeded at 1926 (offset -42 lines). Hunk #6 succeeded at 2080 (offset -42 lines). |Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c |=== |--- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c (revision 243433) |+++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c (working copy) -- Patching file sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c using Plan A... Hunk #1 succeeded at 135. Hunk #2 succeeded at 508. Hunk #3 succeeded at 746. Hunk #4 succeeded at 757. Hunk #5 failed at 1150. Hunk #6 succeeded at 1179 (offset -5 lines). Hunk #7 failed at 1192. Hunk #8 succeeded at 1250 (offset -1 lines). Hunk #9 succeeded at 1400 (offset -6 lines). Hunk #10 succeeded at 1417 (offset -1 lines). Hunk #11 succeeded at 1420 (offset -6 lines). Hunk #12 succeeded at 1440 (offset -1 lines). 2 out of 12 hunks failed--saving rejects to sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c.rej As far I can see it fails because there is no getnewvnode_reserve() / get_newvnode_drop_reserve() in 9.1. Thansk, Regards. -- Patrick Lamaizière Centre de Ressources Informatiques CRI Central Université de Rennes 1 Tél: 02 23 23 71 45 ___ 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: confirm that csup is still usable fos the new 9.1
Quoth Chris Rees : > On 26 Nov 2012 08:12, "Perry Hutchison" wrote: > > Kevin Oberman wrote: > > > > > ... don't bet that csup and cvs will be around long ... > > > It's really time to get away from CVS and I suspect > > > it will be going away sooner than had been planned. > > > > Once csup goes away, how will a base-only system update > > the sources, e.g. to follow a security branch? > > freebsd-update will update your sources for you. It would be convenient if, before csup disappears, the 'Sychronising your Source' section in the Handbook could be updated to contain instructions for updating *just the source* using freebsd-update. Even if this is as simple as 'Components src' it would be good to state that explicitly; it would also be useful to give a procedure for moving from a csupped tree to one which freebsd-update will be able to apply deltas to, if that's possible without redownloading the whole source tree. In general, it's not terribly clear to me what will happen if I run freebsd-update on a system I have built from source. How does it know where to start from when it downloads deltas: does it assume `uname -r` accurately reflects the exact current state of the system? What will happen if I patch my source and then run freebsd-update without reverting those changes: will it revert them for me, like csup did, will it make a mess, or will the update fail? It would also be better, IMHO, to change the language in that section to recommend freebsd-update for those running RELEASE branches, and reserve the svn recommendation for those tracking development branches. Ben ___ 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: confirm that csup is still usable fos the new 9.1
On 26/11/2012 08:07, Perry Hutchison wrote: > Once csup goes away, how will a base-only system update > the sources, e.g. to follow a security branch? freebsd-update(8) Cheers, Matthew ___ 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: confirm that csup is still usable fos the new 9.1
On 26 Nov 2012 08:12, "Perry Hutchison" wrote: > > Kevin Oberman wrote: > > > ... don't bet that csup and cvs will be around long ... > > It's really time to get away from CVS and I suspect > > it will be going away sooner than had been planned. > > Once csup goes away, how will a base-only system update > the sources, e.g. to follow a security branch? freebsd-update will update your sources for you. Chris ___ 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: confirm that csup is still usable fos the new 9.1
Kevin Oberman wrote: > ... don't bet that csup and cvs will be around long ... > It's really time to get away from CVS and I suspect > it will be going away sooner than had been planned. Once csup goes away, how will a base-only system update the sources, e.g. to follow a security branch? ___ 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"
