Re: siisch1: Error while READ LOG EXT
the drive has reallocated some sectors and normally drives should never reallocate sectors unless it has trouble reading/writing to them. also, that drive has known firmware problems so it sounds like the drive needs replacing On Feb 9, 2012 10:38 AM, Mike Tancsa m...@sentex.net wrote: On 2/9/2012 11:34 AM, Jeremy Chadwick wrote: You will probably need to track these drives on a regular basis. That is to say, set up some cronjob or similar that logs the above output to a file (appends data to it), specifically output from smartctl -A (not -a and not -x) and smartctl -l sataphy on a per-disk basis. smartd can track SMART attribute changes, but does not track GPLog changes. Make sure to put timestamps in your logs. Thanks very much for having a look, and the suggestions. It think this is the way to go to see which drive my have errors incrementing. Alexander, is there a better way you can suggest ? As for fixing the problem: I have no idea how you would go about this. Use of port multipliers involves additional cables, possibly of shoddy quality, or other components which may not be decent/reliable. Possibly. Cables are one of those things I am happy to pay extra for better quality but how does one assess quality of such parts. Overall, this is just one of the many reasons why I avoid PMs, as well as avoid eSATA (especially eSATA). Yeah, at some point it doesnt really work with too many PMs, especially if you cant query the thing to find out where things are bad. I think for the next version of this box I will use the newer generation 3ware SAS/SATA controller ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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 ___ 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: known problems with 8.x and HP DL16 G5 server?
On Thu, Feb 09, 2012 at 10:24:11PM -0800, Jeremy Chadwick wrote: On Thu, Feb 09, 2012 at 04:02:12PM -0800, Julian Elischer wrote: On 2/9/12 1:56 PM, Jeremy Chadwick wrote: On Thu, Feb 09, 2012 at 01:48:29PM -0800, Julian Elischer wrote: does anyone know of problems with freebsd and this system? the kernel We tried to boot seems to stop somewhere in the ahci probing. Few things: 1) Possible to get full console output (e.g. serial, etc.) from a verbose boot? it's freebsd 8.2 from a TrueNAS/FreeNAS. I'm actually at ix-systems at the moment.. but I wasnhoping someone could save us some time by saying Oh yeah, merge in change number xx 2) Can you also provide the exact release/tag/kernel/thing you're trying to install or upgrade to (8.x is a little vague; there are all sorts of changes that happen between tags). For example 8.1 is not going to behave the same necessarily as 8.2. 3) When you say ahci probing, are you booting a standard installation CD/DVD/memstick of, say, 8.2? If so, those won't make use of the AHCI-to-CAM translation layer (and that AHCI code is also different than the native-ATA-AHCI code), so you might try, when booting the system, dropping to the loader prompt and issuing load ahci.ko before typing boot. See if that helps. If it does, great, use it (ahci_load=yes in /boot/loader.conf) permanently (and benefit from things like NCQ too). let me forward you an image... 4) If it's an Intel ESB2 controller, I believe there were some fixes or identification shims put in place for this in recent RELENG_8, which wouldn't be available in RELENG_8_2 or 8.2-RELEASE CD/DVDs. I could be remembering the wrong controller though. Hmm... that may be what we are looking for. I'll try get more info. For others: the last few lines in the kernel log are: acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter HPET frequency 14318180 Hz quality 900 acpi: wakeup code va 0xff848311d000 pa 0x4000 ahc_isa_probe 0: ioport 0xc00 alloc failed I don't see any indication of AHCI problems here (or AHCI at all). ahc_isa_probe is for the ahc(4) controller -- Adaptec SCSI. A verbose boot might be more helpful. Can you tru hint.ahc.0.disabled=1 ? ___ 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
Reducing the need to compile a custom kernel
Hi, during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module). Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? Bye, Alexander. -- Cheit's Lament: If you help a friend in need, he is sure to remember you-- the next time he's in need. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Reducing the need to compile a custom kernel
On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? For me, the two big ones are IPSEC (which, as I understand it, we cannot ship with GENERIC due to export laws), and KDB_UNATTENDED. The latter may be a sysctl tunable, I never bothered to look. Regards, Glen ___ 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: Reducing the need to compile a custom kernel
On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: Hi, during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module). Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? I need (not on every machine, granted) IPSEC and MROUTING Bye, Alexander. -- Cheit's Lament: If you help a friend in need, he is sure to remember you-- the next time he's in need. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Buki pgpUbS8jASfwB.pgp Description: PGP signature
Re: Reducing the need to compile a custom kernel
On 2012-02-10 14:56:04 (+0100), Alexander Leidinger alexan...@leidinger.net wrote: The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? VIMAGE and IPSEC I currently require both of them. The VIMAGE is sort of optional. I could run everything unjailed, but I prefer this. IPSEC is required, unless I add a separate device. That's for a little home gateway (HP Microserver thingy), doing file serving (NFS/ZFS), mail, web, backup, ... Regards, Kristof ___ 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: Reducing the need to compile a custom kernel
2012/2/10 Marek 'Buki' Kozlovský free...@dev.null.cz On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: Hi, during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module). Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? I need (not on every machine, granted) IPSEC and MROUTING Bye, Alexander. -- Cheit's Lament: If you help a friend in need, he is sure to remember you-- the next time he's in need. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 Buki IPFIREWALL_DEFAULT_TO_ACCEPT, DEVICE_POLLING and HZ=1000. /Andreas ___ 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: Reducing the need to compile a custom kernel
Le 10 févr. 2012 à 15:36, Marek 'Buki' Kozlovský a écrit : On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? quota support for me, but I heard that they will be soon added in GENERIC maybe it is done for latest versions btw ? All my boxes sticking to 7.x and 8.x box for the moment thus I didn't checked already. Regards___ 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: Reducing the need to compile a custom kernel
On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: Hi, during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module). Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? - INET without INET6 - SOFTUPDATES, UFS_ACL, AUDIT, SCTP (left out for embedded devices) - Björn may add INET6 without INET - SCHED_ULE vs. SCHED_4BSD - No vga console/atkbd/psm for embedded devices - CPU_SOEKRIS, CPU_GEODE, CPU_ELAN, NO_SWAPPING for embedded devices - IPSTEALTH, IPSEC, IPSEC_FILTERTUNNEL, IPFILTER, ALTQ for firewalls - probably more I also always specify exactly one CPU type (on i386), know it made a difference in the 386/486/586 era but am not sure how much difference it makes nowadays. HTH Paul Schenkeveld ___ 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: Reducing the need to compile a custom kernel
On 10/2/2012 15:56, Alexander Leidinger wrote: Hi, during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module). Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options which are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? Hello, we are currently using on every server (in order to maintain a single custom kernel) the following options: IPFIREWALL IPFIREWALL_DEFAULT_TO_ACCEPT IPFIREWALL_FORWARD ROUTETABLES=n Soon, we will also add: IPSEC IPSEC_FILTERTUNNEL IPSEC_NAT_T crypto enc Finally, once we upgrade our jail setup VIMAGE will be also a must. Regards, Panagiotis -- Panagiotis J. ChristiasNetwork Management Center p.christ...@noc.ntua.grNational Technical Univ. of Athens, GREECE ___ 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: Reducing the need to compile a custom kernel
Alexander Leidinger wrote: during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module). Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? The list would be too long for me, that's a sample what I add to my MINIMAL after stripping GENERIC: option DEVICE_POLLING option BPF_JITTER option DIRECTIO option SC_ALT_MOUSE_IMAGE option SC_MOUSE_CHAR=0x3 option ZERO_COPY_SOCKETS option SW_WATCHDOG option ALTQ option ALTQ_CBQ option ALTQ_RED option ALTQ_RIO option ALTQ_HFSC option ALTQ_CDNR option ALTQ_PRIQ option ALTQ_NOPCC device atpic device mptable I even don't use them on most machines however I prefer to build all machines from one kernel config however even this is impossible because for example I can't select scheduler by modules. Some point can be superseded in future for example current work on ULE seems promising. For example, why there are no modules for atpic and mptable? I don't need them on most machines but I can't load them at boot time. -- 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: Reducing the need to compile a custom kernel
On Fri, February 10, 2012 11:56, Alexander Leidinger wrote: Hi, during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module). Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? Its a great thing this Alexander, but for me mainly I need PF+ALTQ and soekris stuff (apart from things other said before). matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ 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: Reducing the need to compile a custom kernel
On 10. Feb 2012, at 15:56 , Panagiotis Christias wrote: On 10/2/2012 15:56, Alexander Leidinger wrote: Hi, during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module). Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options which are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? Hello, we are currently using on every server (in order to maintain a single custom kernel) the following options: IPFIREWALL IPFIREWALL_DEFAULT_TO_ACCEPT loadable, tunable there for this IPFIREWALL_FORWARD ROUTETABLES=n melifaro and I are working on this; he'll fix the netgraph netflow part and I'll fix the #ifdefs and the tunable will be enough. Soon, we will also add: IPSEC IPSEC_FILTERTUNNEL IPSEC_NAT_T crypto enc IPSEC_FILTERTUNNEL has long been obsolete. Finally, once we upgrade our jail setup VIMAGE will be also a must. I have read that multiple times already and I'd love to but that's a looong way. The plan might be to one day provide a 2nd kernel to install from and that freebsd-update can handle but we'll see. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Reducing the need to compile a custom kernel
On 10. Feb 2012, at 13:56 , Alexander Leidinger wrote: Hi, during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module). And you completely seem to have missed the discussion about a device ID DB and loader being able to probe and load them for you? With that sound, firewire, but also NICs and storage drivers can mostly go away... But it needs infrastructure... lots of ... feel free to resume that thread but stable@ is obviously the wrong place. Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? As a lot of the results will show... various parts of the network stack being loadable, which is not as easy as it sounds, especially making them unloadable again currently ... /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: Reducing the need to compile a custom kernel
2012/2/10 Andreas Nilsson andrn...@gmail.com: IPFIREWALL_DEFAULT_TO_ACCEPT, DEVICE_POLLING and HZ=1000. HZ can be set via /boot/loader.conf, and I think via sysctl as well. -- Freddie Cash fjwc...@gmail.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: known problems with 8.x and HP DL16 G5 server?
On Fri, Feb 10, 2012 at 8:23 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Thu, Feb 09, 2012 at 10:24:11PM -0800, Jeremy Chadwick wrote: On Thu, Feb 09, 2012 at 04:02:12PM -0800, Julian Elischer wrote: On 2/9/12 1:56 PM, Jeremy Chadwick wrote: On Thu, Feb 09, 2012 at 01:48:29PM -0800, Julian Elischer wrote: does anyone know of problems with freebsd and this system? the kernel We tried to boot seems to stop somewhere in the ahci probing. Few things: 1) Possible to get full console output (e.g. serial, etc.) from a verbose boot? it's freebsd 8.2 from a TrueNAS/FreeNAS. I'm actually at ix-systems at the moment.. but I wasnhoping someone could save us some time by saying Oh yeah, merge in change number xx 2) Can you also provide the exact release/tag/kernel/thing you're trying to install or upgrade to (8.x is a little vague; there are all sorts of changes that happen between tags). For example 8.1 is not going to behave the same necessarily as 8.2. 3) When you say ahci probing, are you booting a standard installation CD/DVD/memstick of, say, 8.2? If so, those won't make use of the AHCI-to-CAM translation layer (and that AHCI code is also different than the native-ATA-AHCI code), so you might try, when booting the system, dropping to the loader prompt and issuing load ahci.ko before typing boot. See if that helps. If it does, great, use it (ahci_load=yes in /boot/loader.conf) permanently (and benefit from things like NCQ too). let me forward you an image... 4) If it's an Intel ESB2 controller, I believe there were some fixes or identification shims put in place for this in recent RELENG_8, which wouldn't be available in RELENG_8_2 or 8.2-RELEASE CD/DVDs. I could be remembering the wrong controller though. Hmm... that may be what we are looking for. I'll try get more info. For others: the last few lines in the kernel log are: acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter HPET frequency 14318180 Hz quality 900 acpi: wakeup code va 0xff848311d000 pa 0x4000 ahc_isa_probe 0: ioport 0xc00 alloc failed I don't see any indication of AHCI problems here (or AHCI at all). ahc_isa_probe is for the ahc(4) controller -- Adaptec SCSI. A verbose boot might be more helpful. Can you tru hint.ahc.0.disabled=1 ? ___ 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 Is this a Dl165 G5 or a G5p . Also have you tried to change the sata settings in the bios from AHCI to RAID or compat ? I am currently using the G5 , G5p and G7 with 7.3 , 7.4 and 8.3 and , I have seen this issue once or twice but I could not remember what the fix was. I think playing with the bios options for AHCI and reseatting the cables and backplane resolved this for me the last time. -- mark saad | nones...@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
New BSD Installer
Guys, This should really be reverted to sysinstall until the new installer is at least in a state where it consistently works... the most important part of a new users experience is the installer and the few new installs I have done lately I've just installed 8.2 and upgraded from there as the new installer is terribly buggy. Few things: - On my installs at least, if there is an unknown ftp connection problem the installer will just bail and say it has been aborted - this consistently happens when ftp.de is selected - there is no method of stepping back through the install - If a dhcp lease request times out manual configuration isn't offered I realise that a lot of work has gone into it and it's nice and new, but really unless it's finished it shouldn't be the default. Thanks, J ___ 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: New BSD Installer
Joe Holden wrote: Guys, This should really be reverted to sysinstall until the new installer is at least in a state where it consistently works... the most important part of a new users experience is the installer and the few new installs I have done lately I've just installed 8.2 and upgraded from there as the new installer is terribly buggy. Few things: - On my installs at least, if there is an unknown ftp connection problem the installer will just bail and say it has been aborted - this consistently happens when ftp.de is selected - there is no method of stepping back through the install - If a dhcp lease request times out manual configuration isn't offered Another one I've just encountered several times: For some reason the output for setting root password has new lines and lots of space between the various bits of text and isn't taking any input (see http://i.imgur.com/lTP5b.png) The lack of installation progress or emergency shell on another terminal is also something that I think should be considered - being able to see whats going on and getting error output from the commands the installer is running is invaluable. I realise that a lot of work has gone into it and it's nice and new, but really unless it's finished it shouldn't be the default. Thanks, J ___ 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: New BSD Installer
On 02/10/2012 06:56 PM, Joe Holden wrote: Guys, This should really be reverted to sysinstall until the new installer is at least in a state where it consistently works... the most important part of a new users experience is the installer and the few new installs I have done lately I've just installed 8.2 and upgraded from there as the new installer is terribly buggy. Hi, I am highly against reverting. Old installer is not GPT aware and in fact is unmaintained for a very long time. About ftp - its probably needs to be handled better, but most of the user i think using cd/dvd image, so it is not an issue. And new installer is written on shell, so i think its better to fix broken parts then to revert it to outdated and unmaintained code. P.S. i personally had no problems with a new installer, used it from DVD. ___ 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: New BSD Installer
Alex Samorukov wrote: On 02/10/2012 06:56 PM, Joe Holden wrote: Guys, This should really be reverted to sysinstall until the new installer is at least in a state where it consistently works... the most important part of a new users experience is the installer and the few new installs I have done lately I've just installed 8.2 and upgraded from there as the new installer is terribly buggy. Hi, I am highly against reverting. Old installer is not GPT aware and in fact is unmaintained for a very long time. True, there is that. About ftp - its probably needs to be handled better, but most of the user i think using cd/dvd image, so it is not an issue. And new installer is written on shell, so i think its better to fix broken parts then to revert it to outdated and unmaintained code. True also perhaps, could be more user friendly though especially for people just installing it - I have been using my own install scripts and such since 5 but am giving the new installer a go at the moment... P.S. i personally had no problems with a new installer, used it from DVD. ___ 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: New BSD Installer
Joe Holden wrote: Alex Samorukov wrote: On 02/10/2012 06:56 PM, Joe Holden wrote: Guys, This should really be reverted to sysinstall until the new installer is at least in a state where it consistently works... the most important part of a new users experience is the installer and the few new installs I have done lately I've just installed 8.2 and upgraded from there as the new installer is terribly buggy. Hi, I am highly against reverting. Old installer is not GPT aware and in fact is unmaintained for a very long time. True, there is that. About ftp - its probably needs to be handled better, but most of the user i think using cd/dvd image, so it is not an issue. And new installer is written on shell, so i think its better to fix broken parts then to revert it to outdated and unmaintained code. True also perhaps, could be more user friendly though especially for people just installing it - I have been using my own install scripts and such since 5 but am giving the new installer a go at the moment... P.S. i personally had no problems with a new installer, used it from DVD. On a related note - does the new installer have any kind of config file for unattended installs a la sysinstall? ___ 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: Reducing the need to compile a custom kernel
I've done this a few times. The /boot/loader takes a _long_ time to suck in the 25 odd modules my eeepc requires to load a completely modular kernel. It takes a _very long_ time to suck these in over USB. It's a great idea and I think we should start down this path in the 10-CURRENT trajectory but those load times need to be tweaked if possible. Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: siisch1: Error while READ LOG EXT
On 2/9/2012 1:37 PM, Mike Tancsa wrote: On 2/9/2012 11:34 AM, Jeremy Chadwick wrote: You will probably need to track these drives on a regular basis. That is to say, set up some cronjob or similar that logs the above output to a file (appends data to it), specifically output from smartctl -A (not -a and not -x) and smartctl -l sataphy on a per-disk basis. smartd can track SMART attribute changes, but does not track GPLog changes. Make sure to put timestamps in your logs. Thanks very much for having a look, and the suggestions. It think this is the way to go to see which drive my have errors incrementing. Alexander, is there a better way you can suggest ? Got a few more of the READ LOG EXT errors and I did a snapshot of all the disks post error to compare with the snapshots from cron this AM. Unfortunately some of the deltas were on the one new port multiplier and some were on the motherboard sata. Feb 9 04:34:55 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:05:53 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:06:53 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:07:06 backup3 last message repeated 3 times Feb 10 16:18:24 backup3 last message repeated 16 times Feb 10 16:18:24 backup3 kernel: Feb 10 16:18:39 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:19:10 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:20:27 backup3 last message repeated 4 times Feb 10 16:20:27 backup3 kernel: Feb 10 16:20:30 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:21:33 backup3 kernel: siisch1: Error while READ LOG EXT Feb 10 16:23:23 backup3 last message repeated 8 times On ada4, -199 UDMA_CRC_Error_Count-O--CK 200 199 000-13 +199 UDMA_CRC_Error_Count-O--CK 200 199 000-32 SATA Phy Event Counters (GP Log 0x11) ID Size Value Description -0x0001 2 13 Command failed due to ICRC error -0x0002 2 13 R_ERR response for data FIS -0x0003 2 13 R_ERR response for device-to-host data FIS +0x0001 2 32 Command failed due to ICRC error +0x0002 2 32 R_ERR response for data FIS +0x0003 2 32 R_ERR response for device-to-host data FIS 0x0004 20 R_ERR response for host-to-device data FIS -0x0005 20 R_ERR response for non-data FIS -0x0006 20 R_ERR response for device-to-host non-data FIS +0x0005 21 R_ERR response for non-data FIS +0x0006 21 R_ERR response for device-to-host non-data FIS 0x0007 20 R_ERR response for host-to-device non-data FIS 0x000a 20 Device-to-host register FISes sent due to a COMRESET 0x000b 20 CRC errors within host-to-device FIS -0x8000 4 744462 Vendor specific +0x8000 4 785195 Vendor specific General Purpose Log 0x10 [NCQ Command Error log], Page 0-0 (of 1) -000: 05 00 41 84 04 9a 53 40 00 00 00 00 00 00 00 00 |..A...S@| +000: 06 00 41 84 f2 39 6d 40 2d 00 00 00 00 00 00 00 |..A..9m@-...| -1f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa || +1f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 25 |...%| ada5 -199 UDMA_CRC_Error_Count-O--CK 200 200 000-11 +199 UDMA_CRC_Error_Count-O--CK 200 200 000-22 -0x0001 2 11 Command failed due to ICRC error -0x0002 2 11 R_ERR response for data FIS -0x0003 2 11 R_ERR response for device-to-host data FIS +0x0001 2 22 Command failed due to ICRC error +0x0002 2 22 R_ERR response for data FIS +0x0003 2 22 R_ERR response for device-to-host data FIS ada6 -199 UDMA_CRC_Error_Count-O--CK 200 200 000-8 +199 UDMA_CRC_Error_Count-O--CK 200 200 000-25 SATA Phy Event Counters (GP Log 0x11) ID Size Value Description -0x0001 28 Command failed due to ICRC error -0x0002 28 R_ERR response for data FIS -0x0003 28 R_ERR response for device-to-host data FIS +0x0001 2 25 Command failed due to ICRC error +0x0002 2 25 R_ERR response for data FIS +0x0003 2 25 R_ERR response for device-to-host data FIS 0x0004 20 R_ERR response for host-to-device data FIS 0x0005 20 R_ERR response for non-data FIS 0x0006 20 R_ERR response for device-to-host non-data FIS 0x0007 20 R_ERR response for host-to-device non-data FIS 0x000a 20 Device-to-host register FISes sent due to a COMRESET 0x000b 20 CRC errors within host-to-device FIS -0x8000 4 744462 Vendor specific +0x8000 4 785195 Vendor specific ada7 -199 UDMA_CRC_Error_Count-O--CK 200 200 000-13 +199 UDMA_CRC_Error_Count-O--CK 200 200 000-30 SATA Phy Event Counters (GP Log 0x11) ID Size
Re: New BSD Installer
Alex Samorukov m...@os2.kiev.ua writes: On 02/10/2012 06:56 PM, Joe Holden wrote: Guys, This should really be reverted to sysinstall until the new installer is at least in a state where it consistently works... the most important part of a new users experience is the installer and the few new installs I have done lately I've just installed 8.2 and upgraded from there as the new installer is terribly buggy. Hi, I am highly against reverting. Old installer is not GPT aware and in fact is unmaintained for a very long time. About ftp - its probably needs to be handled better, but most of the user i think using cd/dvd image, so it is not an issue. And new installer is written on shell, so i think its better to fix broken parts then to revert it to outdated and unmaintained code. The major problem I saw is that I couldn't find any mention of the packages on the CD/DVD in any of the menus. Is there really no way of installing them, or did I manage to overlook it? I ran through it twice and ended up using sysinstall both times to install the packages. -- Carl Johnsonca...@peak.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: Reducing the need to compile a custom kernel
On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: during some big discussions in the last monts on various lists, one of the problems was that some people would like to use freebsd-update but can't as they are using a custom kernel. With all the kernel modules we provide, the need for a custom kernel should be small, but on the other hand, we do not provide a small kernel-skeleton where you can load just the modules you need. My below comments apply to RELENG_8, amd64. Just noting that here. I have no plans to upgrade to RELENG_9 or newer. This should be easy to change. As a first step I took the generic kernel and removed all devices which are available as modules, e.g. the USB section consists now only of the USB_DEBUG option (so that the module is build like with the current generic kernel). I also removed some storage drivers which are not available as a module. The rationale is, that I can not remove CAM from the kernel config if I let those drivers inside (if those drivers are important enough, someone will probably fix the problem and add the missing pieces to generate a module). This is a core (meaning key) problem as I see it. There is no definitive list of what drivers can/will work as modules vs. being compiled in to the kernel statically. Furthermore, there is evidence on the mailing lists where users experience different behaviour in drivers when built as modules than if statically included: em(4) is one such example (I can dig up the post if needed). Jack often asks me why we include em(4) statically. :-) Such a kernel would cover situations where people compile their own kernel because they want to get rid of some unused kernel code (and maybe even need the memory this frees up). The question is, is this enough? Or asked differently, why are you compiling a custom kernel in a production environment (so I rule out debug options zhich are not enabled in GENERIC)? Are there options which you add which you can not add as a module (SW_WATCHDOG comes to my mind)? If yes, which ones and how important are they for you? Excellent question, and I would love to share with folks the list of things we tweak in our kernel config vs. GENERIC: * Removal: option INET6 * Removal: option SCTP * Removal: option COMPAT_FREEBSD32 * Removal: option COMPAT_FREEBSD4 * Removal: option COMPAT_FREEBSD5 * Removal: option COMPAT_FREEBSD6 * Removal: option COMPAT_FREEBSD7 * Setting: option PRINTF_BUFR_SIZE=256 * Addition: option KDTRACE_HOOKS * Addition: option FLOWTABLE - Note: Despite this, we disable use of flowtable via sysctl due to severe bugs as we have no indication this has been fixed: http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/060289.html * Addition: option BREAK_TO_DEBUGGER * Addition: option ALT_BREAK_TO_DEBUGGER * Addition: option KDB * Addition: option KDB_TRACE * Addition: option DDB * Addition: option DDB_NUMSYM * Addition: option GDB * Addition: option KTR * Addition: option KTR_ENTRIES=262144 * Addition: option KTR_COMPILE=(KTR_SCHED) * Addition: option KTR_MASK=(KTR_SCHED) * Removal: device ata - Note: Our config has the following comment: # NOTE: device ata is missing because we use the Modular ATA core # to only include the ATA-related drivers we need (e.g. AHCI). * Removal: device atapifd * Removal: device atapist * Removal: All device/options relating to SCSI controllers * Addition: device atacore * Addition: device ataisa * Addition: device atapci * Addition: device ataahci * Addition: device ataintel * Removal: device ch * Removal: device sa * Removal: All device/options pertaining to RAID controllers * Removal: All device/options pertaining to PCMCIA/CardBus * Removal: All device/options pertaining to parallel ports * Removal: device puc * Removal: All PCI Ethernet NICs (with and without miibus), with the exception being em * Removal: All ISA Ethernet NICs * Removal: All Wireless NICs * Removal: device vlan * Removal: device tun * Removal: device gif * Removal: device faith * Removal: option USB_DEBUG * Removal: device ulpt * Removal: All device/options pertaining to USB serial devices * Removal: All device/options pertaining to USB Ethernet devices * Removal: All device/options pertaining to USB Wireless devices * Removal: All device/options pertaining to FireWire * Addition: device coretemp * Addition: device smbus * Addition: device smb * Addition: device ichsmb * Addition: device ichwd - Note: We do not use features of this driver given known problems with the watchdog firing during ddb and similar environments. I have no idea if this has been fixed, but I do remember it being confirmed as a problem. * Addition: options ALTQ * Addition: options ALTQ_CBQ * Addition: options ALTQ_RED * Addition: options ALTQ_RIO * Addition: options ALTQ_HFSC * Addition: options ALTQ_CDNR * Addition: options ALTQ_PRIQ * Addition: options ALTQ_NOPCC I want to note
Re: Reducing the need to compile a custom kernel
On 02/10/2012 12:13, Adrian Chadd wrote: I've done this a few times. The /boot/loader takes a _long_ time to suck in the 25 odd modules my eeepc requires to load a completely modular kernel. For those modules not directly related to booting you're better off putting them in kld_list in rc.conf. It's available already in 9, and in [78]-stable. hth, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: Reducing the need to compile a custom kernel
On Fri, Feb 10, 2012 at 04:25:21PM -0700, Ian Lepore wrote: On Fri, 2012-02-10 at 15:10 -0800, Jeremy Chadwick wrote: * Addition: device ichwd - Note: We do not use features of this driver given known problems with the watchdog firing during ddb and similar environments. I have no idea if this has been fixed, but I do remember it being confirmed as a problem. It used to be that watchdog 0 in ddb disabled the watchdog, then when we upgraded to 8.2 that stopped working. One day I discovered (via typo) that now just watchdog without a numeric parm disables it. I'm not positive that applies to the ichwd but it works that way for the hardware watchdog on our arm platforms. This won't work for us. This requires manual intervention. When we have a machine that panic's, we want it sitting at a ddb prompt indefinitely until an admin gets to it to find out what happened. There may be some way to automatically run ddb commands when ddb is induced, but I haven't dug into it yet. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Reducing the need to compile a custom kernel
On Fri, 2012-02-10 at 15:10 -0800, Jeremy Chadwick wrote: * Addition: device ichwd - Note: We do not use features of this driver given known problems with the watchdog firing during ddb and similar environments. I have no idea if this has been fixed, but I do remember it being confirmed as a problem. It used to be that watchdog 0 in ddb disabled the watchdog, then when we upgraded to 8.2 that stopped working. One day I discovered (via typo) that now just watchdog without a numeric parm disables it. I'm not positive that applies to the ichwd but it works that way for the hardware watchdog on our arm platforms. -- 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: siisch1: Error while READ LOG EXT
Mike, I wanted to make you aware of this commit that just came through: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_da.c I would recommend trying this out first to see if it improves your situation with disks on the PM. mav@ might be able to state with more certainty if that commit could address the problems you're seeing, and I know that you're seeing these errors on non-PM-attached devices too, which I'll look at in a bit. But I wanted to make you aware of the above. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: siisch1: Error while READ LOG EXT
On 2/10/2012 8:27 PM, Jeremy Chadwick wrote: Mike, I wanted to make you aware of this commit that just came through: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_da.c Thanks, I did see that. I was going to wait until Monday to csup up once all the weekend level zeros are done. The prior kernels from Nov 28th never saw these READ LOG EXT errors on either of these 2 big zfs boxes ---Mike I would recommend trying this out first to see if it improves your situation with disks on the PM. mav@ might be able to state with more certainty if that commit could address the problems you're seeing, and I know that you're seeing these errors on non-PM-attached devices too, which I'll look at in a bit. But I wanted to make you aware of the above. -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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
hang during dump (reproducible)
Hi, I was reliably seeing a hang during panic in stable/8 -r231144 (and 8.2 release) with an active ssh session. The SCHEDULER_STOPPED patch fixed it, once I found it: http://lists.freebsd.org/pipermail/freebsd-current/2011-December/030127.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063824.html Many thanks to Attilio Rao, Kostik Belousov, and Andriy Gapon. And anybody else involved. However, when I looked at the commit I noticed this: $ svn log -r228424 svn://svn.freebsd.org/base ... MFC after: 3 months (or never) I'm not sure whether never is still considered an option, but it would be useful for me if 8.3 release, when it comes, does not hang this way during panic. But thanks for the patch, regardless. Problem details: If I did a sysctl debug.kdb.panic=1 from the console while the machine was idle, the dump would complete and the machine would reboot and come up with a good core. If I did the same command remotely via ssh, it would hang every time. I also usually would see a hang if I had an active ssh session printing things while I caused a panic from the console. Occasionally in that case it would continue and make a good core if I killed the ssh session from the client side. An open but idle ssh session did not seem to induce a hang. If anybody wants other details, I'd be happy to provide them. Jake Holland ___ 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-stable from i386 to amd64
is there a recipe for moving from i386 to amd64? on a very remote system, i made the migration from 7.4 to 8.2 to 9.0, all 32-bit. it was done with repeated make buildworld make kernel.new [0] nextboot -k kernel.new reboot make installworld etc [0] - well, there were some mv(1)s in there :) so after it was happy with 9.0 i386, i went to move to amd64 with make buildworld TARGET=amd64 make kernel TARGET=amd64 DESTDIR=kernel.new [0] nextboot -k kernel.new reboot it did not come back from the reboot, and required a manual reset. i have no console access to the machine, not my choice. clue bat please. randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9-stable from i386 to amd64
On 02/10/2012 20:56, Randy Bush wrote: is there a recipe for moving from i386 to amd64? Other than backup and reinstall, no. As you already discovered the old world won't run on the new kernel. Installing the new world before reboot isn't safe either, as at some point in the process it'll blow up. Sorry, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: 9-stable from i386 to amd64
On Feb 11, 2012, at 12:48 AM, Doug Barton wrote: On 02/10/2012 20:56, Randy Bush wrote: is there a recipe for moving from i386 to amd64? Other than backup and reinstall, no. As you already discovered the old world won't run on the new kernel. Installing the new world before reboot isn't safe either, as at some point in the process it'll blow up. I recall doing it and then going on to do other bad things (like putting a 4.9/i386 jail on the 7.2 amd64 host). I'm pretty sure I had some back and forth about it on this list, but I'm having no luck finding it. I was local to the box though, so errors were a bit easier to work around. A few vague snippets I remember: -grabbing lib32 from somewhere and installing it -ensuring COMPAT_FREEBSD32 was in the kernel -possibly something complicated with /libexec/ld-elf.so.1 and its 32-bit friend I wish I could remember more. It was one of those you cannot/should not do this challenges that often suck down many hours. Maybe I misremembered the whole thing and gave in and reinstalled even. I do recall finding a few encouraging hacks in the archives though. Thanks, Charles Sorry, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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 -- Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet www.bway.net sp...@bway.net - 212.655.9344 ___ 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-stable from i386 to amd64
On 11. Feb 2012, at 05:48 , Doug Barton wrote: On 02/10/2012 20:56, Randy Bush wrote: is there a recipe for moving from i386 to amd64? Other than backup and reinstall, no. As you already discovered the old world won't run on the new kernel. Installing the new world before reboot isn't safe either, as at some point in the process it'll blow up. heh? An i386 world should run (almost) fine on an amd64 kernel. I know people who have done that update (but I know of no one done it headless). One trick is to install to a swap partition boot that and then update the normal installation but you need to know what you are doing in that case as well. If you are very careful, that can be done headless - did a re-paritioning in a similar way lately. But in general it's all a gamble if not a streamlined process and no console. /bz PS: do you happen to know why the amd64 kernel did hang on boot? -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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-stable from i386 to amd64
In the last episode (Feb 10), Randy Bush said: is there a recipe for moving from i386 to amd64? on a very remote system, i made the migration from 7.4 to 8.2 to 9.0, all 32-bit. it was done with repeated make buildworld make kernel.new [0] nextboot -k kernel.new reboot make installworld etc [0] - well, there were some mv(1)s in there :) so after it was happy with 9.0 i386, i went to move to amd64 with make buildworld TARGET=amd64 make kernel TARGET=amd64 DESTDIR=kernel.new [0] nextboot -k kernel.new reboot it did not come back from the reboot, and required a manual reset. i have no console access to the machine, not my choice. clue bat please. You probably got bit by a mismatched /libexec/ld-elf.so. The kernel expects that to be the native version, and on a 64-bit kernel it also expects a ld-elf32.so to be the compat 32-bit version. When you rebooted onto the 64-bit kernel, it couldn't find /libexec/ld-elf32.so to run any of the 32-bit binaries on the system. My guess is that your reboot attempt died in /sbin/init, prompting for a path to /bin/sh. If you compiled with a static /bin/sh for performance, it probably died very early in /etc/rc. I think copying ld-elf.so over to ld-elf32.so might have been all you needed to boot, but that would end up with a 64-bit kernel running a true 32-bit userland with all the libraries in the wrong place, and your installworld step would replace them with their 64-bit equivalents and your install would die halfway through, leaving you with a large mess to clean up. The cleanest upgrade path is to prepare your 32-bit root to be bootable by both 32- and 64-bit kernels: copy the ld-elf32.so that was built during your buildworld over to /libexec/ld-elf32.so, and also make copies of /lib and /usr/lib to /lib32 and /usr/lib32 respectively. That way when you reboot to a 64-bit kernel, your 32-bit executables will be running correctly out of compat32 paths and your installworld should succeed. When I did all this on a local system, I made judicious use of ZFS snapshots and clones, preserving a bootable clone of my original system plus intermediate versions all the way until I was happy with the result. I've never done it completely remotely, but if you do a trial run or two on a local machine or VM, you should be able to it confidently remotely. -- Dan Nelson dnel...@allantgroup.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: 9-stable from i386 to amd64
heh? An i386 world should run (almost) fine on an amd64 kernel. I know people who have done that update (but I know of no one done it headless). i am not sure i want to be the first :) PS: do you happen to know why the amd64 kernel did hang on boot? nope. dmesg -a did not help on reset randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9-stable from i386 to amd64
Sorry, I wasn't clear. There are various hacky solutions that you can use if you're safely within shouting distance of the system. But Randy specified very remote, thus the answer to his question is no. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: 9-stable from i386 to amd64
The cleanest upgrade path is to prepare your 32-bit root to be bootable by both 32- and 64-bit kernels: copy the ld-elf32.so that was built during your buildworld over to /libexec/ld-elf32.so, and also make copies of /lib and /usr/lib to /lib32 and /usr/lib32 respectively. That way when you reboot to a 64-bit kernel, your 32-bit executables will be running correctly out of compat32 paths and your installworld should succeed. When I did all this on a local system, I made judicious use of ZFS snapshots and clones, preserving a bootable clone of my original system plus intermediate versions all the way until I was happy with the result. I've never done it completely remotely, but if you do a trial run or two on a local machine or VM, you should be able to it confidently remotely. if i get some time next week, i will try under fusion here on my mba. worse comes to worst, i'll learn something. thanks! randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
dhclient script adjustments
After recent merges to stable/8 I am now seeing errors on bootup of the following for three interfaces that will never see the light of DHCP. ? /etc/rc.d/dhclient: ERROR: 'dc1' is not a DHCP-enabled interface Can someone please revert these changes or some other action. ? -- ;s =; pgpxhgHXGR3Ek.pgp Description: PGP signature
Re: 9-stable from i386 to amd64
On Sat, Feb 11, 2012 at 12:02:07AM -0600, Dan Nelson wrote: In the last episode (Feb 10), Randy Bush said: is there a recipe for moving from i386 to amd64? on a very remote system, i made the migration from 7.4 to 8.2 to 9.0, all 32-bit. it was done with repeated make buildworld make kernel.new [0] nextboot -k kernel.new reboot make installworld etc [0] - well, there were some mv(1)s in there :) so after it was happy with 9.0 i386, i went to move to amd64 with make buildworld TARGET=amd64 make kernel TARGET=amd64 DESTDIR=kernel.new [0] nextboot -k kernel.new reboot it did not come back from the reboot, and required a manual reset. i have no console access to the machine, not my choice. clue bat please. You probably got bit by a mismatched /libexec/ld-elf.so. The kernel expects that to be the native version, and on a 64-bit kernel it also expects a ld-elf32.so to be the compat 32-bit version. When you rebooted onto the 64-bit kernel, it couldn't find /libexec/ld-elf32.so to run any of the 32-bit binaries on the system. My guess is that your reboot attempt died in /sbin/init, prompting for a path to /bin/sh. If you compiled with a static /bin/sh for performance, it probably died very early in /etc/rc. These statements are false, esp. worrying is that they are interwinned with some facts that get tilted to support false presumption. Kernel do not care about which interpreter is /libexec/ld-elf.so. The path to the interpreter is specified in the binary itself. So if you have 32bit binary that put '/libexec/ld-elf.so.1' into PH_INTERP, and /libexec/ld-elf.so.1 is 32bit, then amd64 kernel properly executes that combination. Kernel has a hack that falls back to try to use /libexec/ld-elf32.so.1 for some 'brands' of ELF images, in particular, for 32bit binaries. This is done to help in situation when 32bit binaries also specified the same path for interpreter. If you have 32bit world installed and booted 64bit kernel, it will boot. It is the same as running 32bit world in the jail. The management functions, like configuring network interfaces, ZFS and many other system setup functionality does not work, indeed. I think copying ld-elf.so over to ld-elf32.so might have been all you needed to boot, but that would end up with a 64-bit kernel running a true 32-bit userland with all the libraries in the wrong place, and your installworld step would replace them with their 64-bit equivalents and your install would die halfway through, leaving you with a large mess to clean up. Absolute false. The cleanest upgrade path is to prepare your 32-bit root to be bootable by both 32- and 64-bit kernels: copy the ld-elf32.so that was built during your buildworld over to /libexec/ld-elf32.so, and also make copies of /lib and /usr/lib to /lib32 and /usr/lib32 respectively. That way when you reboot to a 64-bit kernel, your 32-bit executables will be running correctly out of compat32 paths and your installworld should succeed. When I did all this on a local system, I made judicious use of ZFS snapshots and clones, preserving a bootable clone of my original system plus intermediate versions all the way until I was happy with the result. I've never done it completely remotely, but if you do a trial run or two on a local machine or VM, you should be able to it confidently remotely. -- Dan Nelson dnel...@allantgroup.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 pgp1XcZGXdzR3.pgp Description: PGP signature
