authentication errors on 'make fetchindex' in /usr/ports
I am trying to upgrade a 12.1-stable system installed back in July to 12.2-stable. I downloaded the new ports hierarchy and now when I attempt to run 'make fetchindex' I get these errors: /usr/bin/env fetch -am -o /usr/ports/INDEX-12.bz2 https://www.FreeBSD.org/ports/INDEX-12.bz2 Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 546533376:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: fetch: https://www.FreeBSD.org/ports/INDEX-12.bz2: Authentication error Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 546533376:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: Can someone help? Thanks, Bob -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: install: gcache.8.gz: No such file or directory on 'make installworld'
On Tue, Sep 22, 2020 at 05:25:58PM +0100, Sergey Kandaurov wrote: > On Tue, 22 Sep 2020 at 16:50, Bob Willcox wrote: > > > When I run 'make installworld' following a 'make world' it fails with this > > error: > > > > ===> lib/geom (install) > > ===> lib/geom/cache (install) > > install -s -o root -g wheel -m 444 -S geom_cache.so /lib/geom/ > > install -o root -g wheel -m 444geom_cache.so.debug > > /usr/lib/debug/lib/geom/ > > install -o root -g wheel -m 444 gcache.8.gz /usr/share/man/man8/ > > install: gcache.8.gz: No such file or directory > > *** Error code 71 > > > > Are you sure you ran ``make world''? > Because if not in HISTORICAL_MAKE_WORLD or DESTDIR, > it won't produce you a cookie. > You probably want to substitute it with ``make buildworld''. Actually, I'm doing a 'make buildworld' and not 'make world'. Is there something I can check regarding the "HISTORICAL_MAKE_WORLD or DESTDIR" you mentioned? Thanks, Bob -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
install: gcache.8.gz: No such file or directory on 'make installworld'
When I run 'make installworld' following a 'make world' it fails with this error: ===> lib/geom (install) ===> lib/geom/cache (install) install -s -o root -g wheel -m 444 -S geom_cache.so /lib/geom/ install -o root -g wheel -m 444geom_cache.so.debug /usr/lib/debug/lib/geom/ install -o root -g wheel -m 444 gcache.8.gz /usr/share/man/man8/ install: gcache.8.gz: No such file or directory *** Error code 71 Can anyone tell me what I'm missing? I just updated my /usr/src to 365971 yesterday. Thanks, Bob -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New Xorg - different key-codes
On Thu, Mar 12, 2020 at 11:11:53AM +0100, Michael Gmelin wrote: > > > On Thu, 12 Mar 2020 10:31:40 +0100 > Alexander Leidinger wrote: > > > Hi, > > > > This command sets the keyboard layout. You are supposed to set the > > keyboard layout which matches the physical layout of the hardware. > > This hadn't changed, it's a fundamental part of X11 since I know it > > (X11 6.5) and even before... > > [snip] > > Exactly. I just personally prefer to use setxkbmap, as all my setups are > single user (one unprivileged user per machine that runs X, no shared > machines) and customization happens in $HOME that way. Makes it a > bit easier to setup a new machine (no digging in Xorg configs) and > reading ~/.xinitrc basically tells me all about my current config. > > Plus, setxkbmap makes it easy to experiment, as it's applies changes > while X is running, even if one makes the those changes permanently in > an xorg config file later. And the resulting command is just one line > (in my case as short as "setxkbmap -model pc105 -layout de"), makes it > easier to support people. > > Another useful application of the command is for debugging: > "setxkbmap -query" will tell you what's currently configured (regardless > how that configuration was done), e.g., > > On a machine running xorg 1.18: > > # setxkbmap -query > rules: base > model: pc105 > layout: de > > On a machine running xorg 1.20: > rules: evdev > model: pc105 > layout: de > > In both cases the same setxkbmap command was used in ~/.xinitrc to set > model and layout. Rules were taken from Xorg's default config, which > changed to evdev in 1.20. I ran "setxkbmap -query" on my home workstation that hasn't had X updated on it yet and this is what I got: rules: base model: pc105 layout: us So presumably that was the default setting from when I installed the system last April. I plan to run this again after I update xorg on this system, but not too sure when I'll get to that. Bob -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New Xorg - different key-codes
On Thu, Mar 12, 2020 at 04:53:32PM +0100, Michael Gmelin wrote: > > > On Thu, 12 Mar 2020 10:36:42 -0500 > Bob Willcox wrote: > > > On Thu, Mar 12, 2020 at 07:24:42AM -0500, Bob Willcox wrote: > > > On Wed, Mar 11, 2020 at 11:46:49PM +0100, Michael Gmelin wrote: > > > > > > > > > > > > SNIP SNAP > > > > >> It might fix the ???Down key opens application launcher??? > > > > >> problem by applying the correct keymap (you have to select the > > > > >> correct one, ???de??? probably won???t cut it for you). At > > > > >> least it did with xfce, where it was important to run it > > > > >> before the wm starts - you could also try running it > > > > >> afterwards to see if it makes a difference. > > > > > > > > > > I don't know about that problem. What I'm experiencing is the > > > > > Alt-up,down,left,right keys don't work as they used to in my > > > > > ctwm window manager. They used to move the current window to > > > > > the closest boundry in the direction indicated by the key that > > > > > is also pressed (while holding the Alt key down). Also, > > > > > Alt-shift-up,down,left,right would expand the window in the > > > > > direction indicated by the key. These actions seem to do > > > > > nothing now. > > > > > > > > I don???t know much about ctwm, but why don???t you give it a > > > > shot? > > > > > > I plan to sometime today when I get into the office. But since it's > > > my work system and I am dependent on it to do my job, I've just > > > been a little hesitant. > > > > Ok, I added this to my ~/.xinitrc file: > > > > setxkbmap -model pc105 -layout us > > > > and my ctwm window adjustment hot keys are working again. :) > > > > I do wonder why it was deemed ok to change the default behavior for > > the key mappings? Couldn't the default mappings have remained the > > same with change to evdev? This change certainly violated the > > "principle of least surprise" for me. > > > > > > I think the change was unavoidable, but it could've been communicated > better. Then again, time and resources are limited and I'm quite > grateful the graphics team finally made that necessary push forward. > > I'm curious how people set their keyboard layout in the past though, > is it possible that the defaults just worked for US users? I always had > to set it explicitly (setxkbmap or in Xorg.conf), so I was never really > affected by this change. > > -m > > p.s. What does "setxkbmap -query" show if you start X without setting > the keymap in .xinitrc? I'll have to try that when I get home tonight on one of my other systems as I really can't afford to take the time to restart X on this system now...got to get some work done. :) Bob > > -- > Michael Gmelin -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New Xorg - different key-codes
On Thu, Mar 12, 2020 at 07:24:42AM -0500, Bob Willcox wrote: > On Wed, Mar 11, 2020 at 11:46:49PM +0100, Michael Gmelin wrote: > > > > > > > On 11. Mar 2020, at 23:25, Bob Willcox wrote: > > > > > > ???On Wed, Mar 11, 2020 at 11:04:18PM +0100, Michael Gmelin wrote: > > >> > > >> > > >>>> On 11. Mar 2020, at 22:58, Bob Willcox wrote: > > >>> > > >>> ???On Wed, Mar 11, 2020 at 02:48:56PM +0100, Michael Gmelin wrote: > > >>>> ??? > > >>>>>> On 11. Mar 2020, at 10:29, Mark Martinec > > >>>>>> wrote: > > >>>>> ??? > > >>>>>> > > >>>>>>> I just updated my laptop from source, and somewhere along the way > > >>>>>>> the key-codes Xorg sees changed. > > >>>>>> Indeed. This doesn't just affect -CURRENT: it happened to me on > > >>>>>> -STABLE last week, so I'm copying that list too. > > >>>>> > > >>>>> And a "Down" key now opens and closes a KDE "Application Launcher", > > >>>>> alternatively with its original function (which makes editing a > > >>>>> frustration). > > >>>>> > > >>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244354 > > >>>>> > > >>>>> > > >>>> > > >>>> This *might* help you: > > >>>> > > >>>> https://lists.freebsd.org/pipermail/freebsd-x11/2020-February/025046.html > > >>>> > > >>>> (Short version: run setxkbmap in ~/.xinitrc, e.g., > > >>>> setxkbmap -model pc105 -layout de) > > >>> > > >>> Will running that command return my key mappings back to what they use > > >>> to be? > > >>> > > >> > > >> It might fix the ???Down key opens application launcher??? problem by > > >> applying the correct keymap (you have to select the correct one, > > >> ???de??? probably won???t cut it for you). At least it did with xfce, > > >> where it was important to run it before the wm starts - you could also > > >> try running it afterwards to see if it makes a difference. > > > > > > I don't know about that problem. What I'm experiencing is the > > > Alt-up,down,left,right keys > > > don't work as they used to in my ctwm window manager. They used to move > > > the current window > > > to the closest boundry in the direction indicated by the key that is also > > > pressed (while > > > holding the Alt key down). Also, Alt-shift-up,down,left,right would > > > expand the window in > > > the direction indicated by the key. These actions seem to do nothing now. > > > > > > > I don???t know much about ctwm, but why don???t you give it a shot? > > I plan to sometime today when I get into the office. But since it's my work > system and I > am dependent on it to do my job, I've just been a little hesitant. Ok, I added this to my ~/.xinitrc file: setxkbmap -model pc105 -layout us and my ctwm window adjustment hot keys are working again. :) I do wonder why it was deemed ok to change the default behavior for the key mappings? Couldn't the default mappings have remained the same with change to evdev? This change certainly violated the "principle of least surprise" for me. > > Bob > > -- > Bob Willcox| It's possible that the whole purpose of your life is to > b...@immure.com | serve as a warning to others. > Austin, TX | -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New Xorg - different key-codes
On Wed, Mar 11, 2020 at 11:46:49PM +0100, Michael Gmelin wrote: > > > > On 11. Mar 2020, at 23:25, Bob Willcox wrote: > > > > ???On Wed, Mar 11, 2020 at 11:04:18PM +0100, Michael Gmelin wrote: > >> > >> > >>>> On 11. Mar 2020, at 22:58, Bob Willcox wrote: > >>> > >>> ???On Wed, Mar 11, 2020 at 02:48:56PM +0100, Michael Gmelin wrote: > >>>> ??? > >>>>>> On 11. Mar 2020, at 10:29, Mark Martinec > >>>>>> wrote: > >>>>> ??? > >>>>>> > >>>>>>> I just updated my laptop from source, and somewhere along the way > >>>>>>> the key-codes Xorg sees changed. > >>>>>> Indeed. This doesn't just affect -CURRENT: it happened to me on > >>>>>> -STABLE last week, so I'm copying that list too. > >>>>> > >>>>> And a "Down" key now opens and closes a KDE "Application Launcher", > >>>>> alternatively with its original function (which makes editing a > >>>>> frustration). > >>>>> > >>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244354 > >>>>> > >>>>> > >>>> > >>>> This *might* help you: > >>>> > >>>> https://lists.freebsd.org/pipermail/freebsd-x11/2020-February/025046.html > >>>> > >>>> (Short version: run setxkbmap in ~/.xinitrc, e.g., > >>>> setxkbmap -model pc105 -layout de) > >>> > >>> Will running that command return my key mappings back to what they use to > >>> be? > >>> > >> > >> It might fix the ???Down key opens application launcher??? problem by > >> applying the correct keymap (you have to select the correct one, ???de??? > >> probably won???t cut it for you). At least it did with xfce, where it was > >> important to run it before the wm starts - you could also try running it > >> afterwards to see if it makes a difference. > > > > I don't know about that problem. What I'm experiencing is the > > Alt-up,down,left,right keys > > don't work as they used to in my ctwm window manager. They used to move the > > current window > > to the closest boundry in the direction indicated by the key that is also > > pressed (while > > holding the Alt key down). Also, Alt-shift-up,down,left,right would expand > > the window in > > the direction indicated by the key. These actions seem to do nothing now. > > > > I don???t know much about ctwm, but why don???t you give it a shot? I plan to sometime today when I get into the office. But since it's my work system and I am dependent on it to do my job, I've just been a little hesitant. Bob -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New Xorg - different key-codes
On Wed, Mar 11, 2020 at 11:04:18PM +0100, Michael Gmelin wrote: > > > > On 11. Mar 2020, at 22:58, Bob Willcox wrote: > > > > ???On Wed, Mar 11, 2020 at 02:48:56PM +0100, Michael Gmelin wrote: > >> ??? > >>>> On 11. Mar 2020, at 10:29, Mark Martinec > >>>> wrote: > >>> ??? > >>>> > >>>>> I just updated my laptop from source, and somewhere along the way > >>>>> the key-codes Xorg sees changed. > >>>> Indeed. This doesn't just affect -CURRENT: it happened to me on > >>>> -STABLE last week, so I'm copying that list too. > >>> > >>> And a "Down" key now opens and closes a KDE "Application Launcher", > >>> alternatively with its original function (which makes editing a > >>> frustration). > >>> > >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244354 > >>> > >>> > >> > >> This *might* help you: > >> > >> https://lists.freebsd.org/pipermail/freebsd-x11/2020-February/025046.html > >> > >> (Short version: run setxkbmap in ~/.xinitrc, e.g., > >> setxkbmap -model pc105 -layout de) > > > > Will running that command return my key mappings back to what they use to > > be? > > > > It might fix the ???Down key opens application launcher??? problem by > applying the correct keymap (you have to select the correct one, ???de??? > probably won???t cut it for you). At least it did with xfce, where it was > important to run it before the wm starts - you could also try running it > afterwards to see if it makes a difference. I don't know about that problem. What I'm experiencing is the Alt-up,down,left,right keys don't work as they used to in my ctwm window manager. They used to move the current window to the closest boundry in the direction indicated by the key that is also pressed (while holding the Alt key down). Also, Alt-shift-up,down,left,right would expand the window in the direction indicated by the key. These actions seem to do nothing now. Bob -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New Xorg - different key-codes
On Wed, Mar 11, 2020 at 02:48:56PM +0100, Michael Gmelin wrote: > ??? > >> On 11. Mar 2020, at 10:29, Mark Martinec > >> wrote: > > ??? > >> > >>> I just updated my laptop from source, and somewhere along the way > >>> the key-codes Xorg sees changed. > >> Indeed. This doesn't just affect -CURRENT: it happened to me on > >> -STABLE last week, so I'm copying that list too. > > > > And a "Down" key now opens and closes a KDE "Application Launcher", > > alternatively with its original function (which makes editing a > > frustration). > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244354 > > > > > > This *might* help you: > > https://lists.freebsd.org/pipermail/freebsd-x11/2020-February/025046.html > > (Short version: run setxkbmap in ~/.xinitrc, e.g., > setxkbmap -model pc105 -layout de) Will running that command return my key mappings back to what they use to be? -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Certificate verification failures on 'make fetchindex' in /usr/ports
Thanks alot Mike. That worked for me. Out of curriosity, is this a fairly recent change? For some reason I've never experienced this issue before, though it's been a number of months that I last installed a new system. Bob On Tue, Feb 11, 2020 at 09:17:01AM -0500, Mike Jakubik wrote: > Hi Bob, > > > > You need to install the root certificate bundle. > > > > cd /usr/ports/security/ca_root_nss/ && make install clean > > > > Cheers. > > > On Tue, 11 Feb 2020 09:07:12 -0500 Bob Willcox wrote > > > > Hi All, > > I just installed a recent snapshot of 12.1 on a new system and when I run > 'make fetchindex' > in the /usr/ports directory I get this: > > bob@han:0 /usr/ports> make fetchindex > /usr/bin/env fetch -am -o /usr/ports/INDEX-12.bz2 > https://www.FreeBSD.org/ports/INDEX-12.bz2 > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt > Authority X3 > 34370596864:error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify > failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: > fetch: https://www.FreeBSD.org/ports/INDEX-12.bz2: Authentication error > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt > Authority X3 > 34370596864:error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify > failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: > fetch: https://www.FreeBSD.org/ports/INDEX-12.bz2: Authentication error > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt > Authority X3 > 34370596864:error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify > failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: > fetch: https://www.FreeBSD.org/ports/INDEX-12.bz2: Authentication error > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt > Authority X3 > 34370596864:error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify > failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: > fetch: https://www.FreeBSD.org/ports/INDEX-12.bz2: Authentication error > Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt > Authority X3 > 34370596864:error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify > failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: > > Can anyone tell me how to fix this? Why would I be getting certificate > verification > failures? What am I missing? This is a brand new install and I have installed > very > little else (pdksh, ksh93, & bsdrcmds is all). > > Thanks, > Bob > > -- > Bob Willcox| It's possible that the whole purpose of your life is to > mailto:b...@immure.com | serve as a warning to others. > Austin, TX | > ___ > mailto:freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "mailto:freebsd-stable-unsubscr...@freebsd.org; > > > > > > Mike Jakubik > > https://www.swiftsmsgateway.com/ > > > > Disclaimer: This e-mail and any attachments are intended only for the use of > the addressee(s) and may contain information that is privileged or > confidential. If you are not the intended recipient, or responsible for > delivering the information to the intended recipient, you are hereby notified > that any dissemination, distribution, printing or copying of this e-mail and > any attachments is strictly prohibited. If this e-mail and any attachments > were received in error, please notify the sender by reply e-mail and delete > the original message. -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Certificate verification failures on 'make fetchindex' in /usr/ports
Hi All, I just installed a recent snapshot of 12.1 on a new system and when I run 'make fetchindex' in the /usr/ports directory I get this: bob@han:0 /usr/ports> make fetchindex /usr/bin/env fetch -am -o /usr/ports/INDEX-12.bz2 https://www.FreeBSD.org/ports/INDEX-12.bz2 Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 34370596864:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: fetch: https://www.FreeBSD.org/ports/INDEX-12.bz2: Authentication error Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 34370596864:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: fetch: https://www.FreeBSD.org/ports/INDEX-12.bz2: Authentication error Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 34370596864:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: fetch: https://www.FreeBSD.org/ports/INDEX-12.bz2: Authentication error Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 34370596864:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: fetch: https://www.FreeBSD.org/ports/INDEX-12.bz2: Authentication error Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 34370596864:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: Can anyone tell me how to fix this? Why would I be getting certificate verification failures? What am I missing? This is a brand new install and I have installed very little else (pdksh, ksh93, & bsdrcmds is all). Thanks, Bob -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: USB trouble on Ryzen 3/AsRock mobo.
Well, I replaced the Gigabyte MB with an ASUS PRIME A3201-K and it is so far working fine. No USB_ERR_TIMEOUT spewing. The other MB never did stop spewing the errors (left it on for over 24 hours spewing). Bob On Mon, Feb 10, 2020 at 07:32:27AM +0100, Phil Norman wrote: > Hi. > > I'm afraid the best I could come up with is that the motherboard I was > using is not standards-compliant, and has a broken USB system. This might > explain why they insist you install their special drivers on Windows. > > My solution was to replace the motherboard with one that actually works > properly. > > Cheers, > Phil > > On Sun, 9 Feb 2020 at 18:05, Bob Willcox wrote: > > > Hi Phil, > > > > Did you ever determine the cause and solution to the USB_ERR_TIMEOUT errors > > you were getting? I just installed a recent 12.1 snapshot on a system with > > a > > Gigabyte GA-AB350N Ryzen motherboard and am seeing similar USB_ERR_TIMEOUT > > errors with this MB. > > > > The errors on this system appear to be continuing forever as they have been > > going on for over 30 minutes so far with no end in sight. On this system > > the > > initial dmesg messages for the usb errors looks strikingly similar to > > yours: > > > > Feb 9 18:46:57 han kernel: xhci0: Resetting controller > > Feb 9 18:46:57 han kernel: usb_alloc_device: set address 3 failed > > (USB_ERR_TIMEOUT, ignored) > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han syslogd: last message repeated 1 times > > Feb 9 18:46:57 han kernel: usbd_setup_device_desc: getting device > > descriptor at addr 3 failed, USB_ERR_TIMEOUT > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han kernel: usbd_req_re_enumerate: addr=3, set address > > failed! (USB_ERR_TIMEOUT, ignored) > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han syslogd: last message repeated 1 times > > Feb 9 18:46:57 han kernel: usbd_setup_device_desc: getting device > > descriptor at addr 3 failed, USB_ERR_TIMEOUT > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han kernel: usbd_req_re_enumerate: addr=3, set address > > failed! (USB_ERR_TIMEOUT, ignored) > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han syslogd: last message repeated 1 times > > Feb 9 18:46:57 han kernel: usbd_setup_device_desc: getting device > > descriptor at addr 3 failed, USB_ERR_TIMEOUT > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han kernel: usbd_req_re_enumerate: addr=3, set address > > failed! (USB_ERR_TIMEOUT, ignored) > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han kernel: usbd_setup_device_desc: getting device > > descriptor at addr 3 failed, USB_ERR_TIMEOUT > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han syslogd: last message repeated 1 times > > Feb 9 18:46:57 han kernel: usbd_req_re_enumerate: addr=3, set address > > failed! (USB_ERR_TIMEOUT, ignored) > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > > > Anyone have any advice on what I can do the get this to stop? The system is > > fundamentally unusable as it is. > > > > Thanks, > > Bob > > > > On Tue, Jun 19, 2018 at 09:38:17PM +0200, Phil Norman wrote: > > > Hi. > > > > > > I've recently converted to FreeBSD, fleeing the Windowsification of > > Ubuntu. > > > I've been having some trouble with the USB system, which seems strange as > > > FreeBSD's USB stack is, according to a friend, rock solid. I'd like to > > > narrow down if this is a hardware (CPU or mobo) or software issue. > > > > > > I'm running a Ryzen 3 1200, plugged into a "Fatal1ty X370 Gaming-ITX/ac" > > > motherboard (chosen because it supports ECC RAM and fits in an ITX case). > > > > > > On a cold boot (ie starting by flipping the physical PSU power switch), > > BSD > > > boots up nice and quickly, without errors, and then runs for days > > without a > > > single USB-related error on dmesg. However, any other kind of reboot > > which > > > doesn't interrupt the electricity supply yields a large number of USB > > > errors (USB_ERR_TIMEOUTs every few seconds or so) and frequent resets of > > > the xhci0 controller. > > > > > > On occasion, I also get problems with my keyboard randomly stopping > > working > > > (but then, if the USB subsyste
Re: USB trouble on Ryzen 3/AsRock mobo.
Hi Phil, Thanks for the reply. I too have decided to replace the motherboard. Hopefully the next one will behave better. I'm sure that these manufactures don't test their products with FreeBSD. Bob On Mon, Feb 10, 2020 at 07:32:27AM +0100, Phil Norman wrote: > Hi. > > I'm afraid the best I could come up with is that the motherboard I was > using is not standards-compliant, and has a broken USB system. This might > explain why they insist you install their special drivers on Windows. > > My solution was to replace the motherboard with one that actually works > properly. > > Cheers, > Phil > > On Sun, 9 Feb 2020 at 18:05, Bob Willcox wrote: > > > Hi Phil, > > > > Did you ever determine the cause and solution to the USB_ERR_TIMEOUT errors > > you were getting? I just installed a recent 12.1 snapshot on a system with > > a > > Gigabyte GA-AB350N Ryzen motherboard and am seeing similar USB_ERR_TIMEOUT > > errors with this MB. > > > > The errors on this system appear to be continuing forever as they have been > > going on for over 30 minutes so far with no end in sight. On this system > > the > > initial dmesg messages for the usb errors looks strikingly similar to > > yours: > > > > Feb 9 18:46:57 han kernel: xhci0: Resetting controller > > Feb 9 18:46:57 han kernel: usb_alloc_device: set address 3 failed > > (USB_ERR_TIMEOUT, ignored) > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han syslogd: last message repeated 1 times > > Feb 9 18:46:57 han kernel: usbd_setup_device_desc: getting device > > descriptor at addr 3 failed, USB_ERR_TIMEOUT > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han kernel: usbd_req_re_enumerate: addr=3, set address > > failed! (USB_ERR_TIMEOUT, ignored) > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han syslogd: last message repeated 1 times > > Feb 9 18:46:57 han kernel: usbd_setup_device_desc: getting device > > descriptor at addr 3 failed, USB_ERR_TIMEOUT > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han kernel: usbd_req_re_enumerate: addr=3, set address > > failed! (USB_ERR_TIMEOUT, ignored) > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han syslogd: last message repeated 1 times > > Feb 9 18:46:57 han kernel: usbd_setup_device_desc: getting device > > descriptor at addr 3 failed, USB_ERR_TIMEOUT > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han kernel: usbd_req_re_enumerate: addr=3, set address > > failed! (USB_ERR_TIMEOUT, ignored) > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han kernel: usbd_setup_device_desc: getting device > > descriptor at addr 3 failed, USB_ERR_TIMEOUT > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > Feb 9 18:46:57 han syslogd: last message repeated 1 times > > Feb 9 18:46:57 han kernel: usbd_req_re_enumerate: addr=3, set address > > failed! (USB_ERR_TIMEOUT, ignored) > > Feb 9 18:46:57 han kernel: Root mount waiting for: usbus0 > > > > Anyone have any advice on what I can do the get this to stop? The system is > > fundamentally unusable as it is. > > > > Thanks, > > Bob > > > > On Tue, Jun 19, 2018 at 09:38:17PM +0200, Phil Norman wrote: > > > Hi. > > > > > > I've recently converted to FreeBSD, fleeing the Windowsification of > > Ubuntu. > > > I've been having some trouble with the USB system, which seems strange as > > > FreeBSD's USB stack is, according to a friend, rock solid. I'd like to > > > narrow down if this is a hardware (CPU or mobo) or software issue. > > > > > > I'm running a Ryzen 3 1200, plugged into a "Fatal1ty X370 Gaming-ITX/ac" > > > motherboard (chosen because it supports ECC RAM and fits in an ITX case). > > > > > > On a cold boot (ie starting by flipping the physical PSU power switch), > > BSD > > > boots up nice and quickly, without errors, and then runs for days > > without a > > > single USB-related error on dmesg. However, any other kind of reboot > > which > > > doesn't interrupt the electricity supply yields a large number of USB > > > errors (USB_ERR_TIMEOUTs every few seconds or so) and frequent resets of > > > the xhci0 controller. > > > > > > On occasion, I also get problems with my keyboard randomly stopping > > working > > > (but then, if the USB subsyste
Re: USB trouble on Ryzen 3/AsRock mobo.
> USB_ERR_TIMEOUT > ugen0.2: at usbus0 (disconnected) > uhub_reattach_port: could not allocate new device > uhub1: at usbus0, port 1, addr 1 (disconnected) > uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 > uhub1: 22 ports with 22 removable, self powered > xhci0: Resetting controller > - > > > Here's the start of dmesg: > > - > Copyright (c) 1992-2018 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.2-PRERELEASE #0 r335198: Fri Jun 15 20:55:02 CEST 2018 > phil@bob:/usr/obj/usr/src/sys/BOB amd64 > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM > 6.0.0) > VT(efifb): resolution 1024x768 > CPU: AMD Ryzen 3 1200 Quad-Core Processor(3094.26-MHz K8-class > CPU) > Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 > > Features=0x178bfbff > > Features2=0x7ed8320b > AMD Features=0x2e500800 > AMD > Features2=0x35c233ff > Structured Extended > Features=0x209c01a9 > XSAVE Features=0xf > AMD Extended Feature Extensions ID EBX=0x1007 > SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 > TSC: P-state invariant, performance statistics > real memory = 17179869184 (16384 MB) > avail memory = 16519221248 (15753 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > random: unblocking device. > Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid > Length but zero Address: 0x/0x1 (20171214/tbfadt-796) > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-55 on motherboard > SMP: AP CPU #3 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #1 Launched! > Timecounter "TSC-low" frequency 1547130097 Hz quality 1000 > random: entropy device external interface > kbd0 at kbdmux0 > netmap: loaded module > module_register_init: MOD_LOAD (vesa, 0x80a3bd40, 0) error 19 > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX > platforms 390.59 Wed May 9 21:54:48 PDT 2018 > nexus0 > cryptosoft0: on motherboard > aesni0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 on acpi0 > atrtc0: registered as a time-of-day clock, resolution 1.00s > Event timer "RTC" frequency 32768 Hz quality 0 > hpet0: iomem 0xfed0-0xfed003ff irq 0,8 on > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 450 > Event timer "HPET1" frequency 14318180 Hz quality 450 > Event timer "HPET2" frequency 14318180 Hz quality 450 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pcib0: _OSC returned error 0x10 > pci0: on pcib0 > amdsmn0: on hostb0 > amdtemp0: on hostb0 > pci0: at device 0.2 (no driver attached) > pcib1: at device 1.3 on pci0 > pci1: on pcib1 > xhci0: mem 0xf77a-0xf77a7fff irq 32 > at device 0.0 on pci1 > xhci0: 32 bytes context size, 64-bit DMA > usbus0 on xhci0 > - > > I don't remember if I had similar USB trouble on Linux, but I definitely > did during my brief excursion into NetBSD. If anyone knows whether this is > likely to be a CPU, mother board or software problem, or knows of something > I can try to get more information or try to debug the thing, please let me > know. > > Thanks, > Phil > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Bob Willcox| It's possible that the whole purpose of your life is to b...@immure.com | serve as a warning to others. Austin, TX | ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.0 installworld core dumping on me
On Tue, Apr 23, 2019 at 08:43:34PM +, Lorenzo Salvadore via freebsd-stable wrote: > ? Original Message ? > On Tuesday 23 April 2019 20:36, Bob Willcox wrote: > ... > > I am playing too with CPUTYPE in these days. I think I will soon write a wiki > page > about that. Here is a short description of what I have found out. > > What I suggest you to do, if you still want to play with CPU_TYPE (I do not > recommend it: > I cannot see any real improvement), is to set CPUTYPE?= native. Then look into > /usr/share/mk/bsd.cpu.mk what feature you can enable or disable for your > processor: > avx, sse3 etc. Compare this list with the feature supported by your processor > (run > "dmesg | head -n 25" to get them) and define MACHINE_CPU+= with what you need > (some features probably are already set: check them with "make -V > MACHINE_CPU"). > > Reading /usr/share/mk/bsd.cpu.mk you will see some values you can give to > CPUTYPE > that will set automatically MACHINE_CPU to the right value. However I > discourage you > from using them: in my case, I should set CPU_TYPE?=ivybridge, however > bsd.cpu.mk, > clang and gcc all believe that ivybridge support avx, but this is wrong at > least for my > cpu, thus I get invalid instructions (even if I correct bsd.cpu.mk), while > everything is > fine by setting CPU_TYPE?=native. > If, however, you still want to set your specific model instead of native into > CPU_TYPE, > you can get the supposed right value running > "cc -v -x c -E -march=native /dev/null -o /dev/null" or "llvm-tblgen > -version". > > If you happen to encounter some invalid instructions with some port, > recompile it > with NO_CPU_CFLAGS=yes: this will avoid setting -march= in > your CFLAGS. > I had to do that with ports involving rust. > > Lorenzo Salvadore. Thanks for the info/insight Lorenzo. I think I will simply skip setting it from now on though. I burned/wasted way more time on this than I care to think about already. It sounds like (based on what you have said) there really isn't a big reward for using it anyway. Thanks again, Bob -- Bob Willcox| "Too often we enjoy the comfort of opinion b...@immure.com | without the discomfort of thought." Austin, TX | - John F. Kennedy ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.0 installworld core dumping on me
On Tue, Apr 23, 2019 at 07:51:34AM -0500, Bob Willcox wrote: > I installed the 20190418 12.0-STABLE snapshot and then checking out the > latest 12.0-STABLE source code > and performing a 'make buildworld' when I attempt to do a 'make installworld' > I get this: > > root@darth:3 /usr/src> make installworld > make[1]: "/usr/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1: Using > cached toolchain metadata from build at darth.immure.com on Mon Apr 22 > 19:54:57 CDT 2019 > Illegal instruction (core dumped) > rescue/sh check failed, installation aborted > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src > > This leaves me with a rescue.core file in the /usr/obj/usr/src/amd64.amd64 > directory. > > The toolchain-metadata.mk file contains this: > > .info Using cached toolchain metadata from build at darth.immure.com on Mon > Apr 22 19:54:57 CDT 2019 > _LOADED_TOOLCHAIN_METADATA=t > COMPILER_VERSION=8 > X_COMPILER_VERSION=8 > COMPILER_TYPE=clang > X_COMPILER_TYPE=clang > COMPILER_FEATURES= c++11 retpoline > X_COMPILER_FEATURES= c++11 retpoline > COMPILER_FREEBSD_VERSION=1200018 > X_COMPILER_FREEBSD_VERSION=1200018 > LINKER_VERSION=8 > X_LINKER_VERSION=8 > LINKER_FEATURES= build-id ifunc filter retpoline > X_LINKER_FEATURES= build-id ifunc filter retpoline > LINKER_TYPE=lld > X_LINKER_TYPE=lld > LINKER_FREEBSD_VERSION=356365-127 > X_LINKER_FREEBSD_VERSION=356365-127 > .export COMPILER_VERSION COMPILER_TYPE COMPILER_FEATURES > COMPILER_FREEBSD_VERSION LINKER_VERSION LINKER_FEATURES LINKER_TYPE > LINKER_FREEBSD_VERSION > .export X_COMPILER_VERSION X_COMPILER_TYPE X_COMPILER_FEATURES > X_COMPILER_FREEBSD_VERSION X_LINKER_VERSION X_LINKER_FEATURES X_LINKER_TYPE > X_LINKER_FREEBSD_VERSION > > > Anyone have any idea on what might be the cause or how best to proceed with > debugging this? > > Thanks, > Bob Well, it turns out that the following line that I placed in the system's make.conf file was the culprit: CPUTYPE?= skx Removing it and rebuilding world allowed 'make installworld' to run. I had just tried that on a lark since the CPU is an I7-9700k which is a Coffee Lake processor and is newaer than Skylake so I thought...what the heck, give it a try. Bad idea. The compiler must be generating instructions that aren't compatible with my CPU. Removal of that line in make.conf seems to have gotten me fixed. :) Bob -- Bob Willcox| "Too often we enjoy the comfort of opinion b...@immure.com | without the discomfort of thought." Austin, TX | - John F. Kennedy ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
12.0 installworld core dumping on me
I installed the 20190418 12.0-STABLE snapshot and then checking out the latest 12.0-STABLE source code and performing a 'make buildworld' when I attempt to do a 'make installworld' I get this: root@darth:3 /usr/src> make installworld make[1]: "/usr/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1: Using cached toolchain metadata from build at darth.immure.com on Mon Apr 22 19:54:57 CDT 2019 Illegal instruction (core dumped) rescue/sh check failed, installation aborted *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src This leaves me with a rescue.core file in the /usr/obj/usr/src/amd64.amd64 directory. The toolchain-metadata.mk file contains this: .info Using cached toolchain metadata from build at darth.immure.com on Mon Apr 22 19:54:57 CDT 2019 _LOADED_TOOLCHAIN_METADATA=t COMPILER_VERSION=8 X_COMPILER_VERSION=8 COMPILER_TYPE=clang X_COMPILER_TYPE=clang COMPILER_FEATURES= c++11 retpoline X_COMPILER_FEATURES= c++11 retpoline COMPILER_FREEBSD_VERSION=1200018 X_COMPILER_FREEBSD_VERSION=1200018 LINKER_VERSION=8 X_LINKER_VERSION=8 LINKER_FEATURES= build-id ifunc filter retpoline X_LINKER_FEATURES= build-id ifunc filter retpoline LINKER_TYPE=lld X_LINKER_TYPE=lld LINKER_FREEBSD_VERSION=356365-127 X_LINKER_FREEBSD_VERSION=356365-127 .export COMPILER_VERSION COMPILER_TYPE COMPILER_FEATURES COMPILER_FREEBSD_VERSION LINKER_VERSION LINKER_FEATURES LINKER_TYPE LINKER_FREEBSD_VERSION .export X_COMPILER_VERSION X_COMPILER_TYPE X_COMPILER_FEATURES X_COMPILER_FREEBSD_VERSION X_LINKER_VERSION X_LINKER_FEATURES X_LINKER_TYPE X_LINKER_FREEBSD_VERSION Anyone have any idea on what might be the cause or how best to proceed with debugging this? Thanks, Bob -- Bob Willcox| "Too often we enjoy the comfort of opinion b...@immure.com | without the discomfort of thought." Austin, TX | - John F. Kennedy ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.0-STABLE Getting Signal 4 building src/Stemmer.c
On Mon, Apr 22, 2019 at 04:00:26PM -0500, Bob Willcox wrote: > Hi All, > > My brand new 12.0-STABLE system is failing to build the kernel when it gets to > here during the make: > > ===> Configuring for py36-pystemmer-1.3.0_2 > running config > ===> Building for py36-pystemmer-1.3.0_2 > running build > running build_ext > cythoning src/Stemmer.pyx to src/Stemmer.c > *** Signal 4 > > Stop. > make[9]: stopped in /usr/ports/textproc/py-pystemmer > *** Error code 1 > > I've tried this several times now, always with the same result. Here is my > system's > uname -a output: > > FreeBSD darth.immure.com 12.0-STABLE FreeBSD 12.0-STABLE r346338 GENERIC > amd64 > > > Anyone have any ideas on what would cause this, or, for that matter, why it's > trying > to build Stemmer.c in the first place? Do I even need it? > > Thanks, > Bob > So, I think the reason it was trying to build the py36 stuff was due to it trying to build the nvidia driver as I had this in src.conf: PORTS_MODULES=x11/nvidia-driver Once I installed xort and the nvidia driver first then my kernel build was successful... Bob -- Bob Willcox| "Too often we enjoy the comfort of opinion b...@immure.com | without the discomfort of thought." Austin, TX | - John F. Kennedy ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
12.0-STABLE Getting Signal 4 building src/Stemmer.c
Hi All, My brand new 12.0-STABLE system is failing to build the kernel when it gets to here during the make: ===> Configuring for py36-pystemmer-1.3.0_2 running config ===> Building for py36-pystemmer-1.3.0_2 running build running build_ext cythoning src/Stemmer.pyx to src/Stemmer.c *** Signal 4 Stop. make[9]: stopped in /usr/ports/textproc/py-pystemmer *** Error code 1 I've tried this several times now, always with the same result. Here is my system's uname -a output: FreeBSD darth.immure.com 12.0-STABLE FreeBSD 12.0-STABLE r346338 GENERIC amd64 Anyone have any ideas on what would cause this, or, for that matter, why it's trying to build Stemmer.c in the first place? Do I even need it? Thanks, Bob -- Bob Willcox| "Too often we enjoy the comfort of opinion b...@immure.com | without the discomfort of thought." Austin, TX | - John F. Kennedy ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portupgrade(1) | portmaster(8) -- which is more effective for large upgrade?
On Wed, Jun 26, 2013 at 01:23:32PM -0700, Jeremy Chadwick wrote: On Wed, Jun 26, 2013 at 09:42:43AM -0700, Chris H wrote: Greetings, I haven't upgraded my tree(s) for awhile. My last attempt to rebuild after an updating src ports, resulted in nearly installing the entire ports tree, which is why I've waited so long. Try as I might, I've had great difficulty finding something that will _only_ upgrade what I already have installed, _and_ respect the options used during the original make make install, or those options expressed in make.conf. As portupgrade(1) portmaster(8) appear to be the most used in this scenario, I'm soliciting opinions on which of these works best, or if there is something else to better manage this situation. Is there such a thing as a FreeBSD upgrade easy button? Use portmaster, avoid portupgrade. And no I will not expand on my reasoning -- I urge anyone even mentioning the word portupgrade to spend a few hours of their day reading the horror stories on the mailing lists over the past 10 years or so (including recently). Choose wisely. Well, just to offer a counter-opinion here, I use portupgrade and feel that it has improved significantly over the past year or two and has become quite usable. I run it every two to four weeks on about five systems and haven't had any problems with it in a long time. However, YMMV. I do get ports that won't build from time to time, but I haven't seen any connection between their failures and portupgrade. -- Bob Willcox| The future lies ahead. b...@immure.com | Austin, TX | ___ 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
Problems trying to run X on Intel DH77DF System
Hi All, I have a new Intel DH77DF mini-ITX motherboard with a Core i5 3550 CPU and am having trouble getting X to run. This is on a 9-STABLE system just updated today via cvsup. There appear to be two obvious problems: the first is that X will no longer start (it used to with about a two week older 9-stable build); and the second is that once I attempt to start X I seem to lose the console. I'm left with a blue screen and am unable to switch to any other console (neither Alt-Fx nor Ctl-Alt-Fx do anything). The system is, however, still running as I can login via the network. My 'uname -a' output is this: FreeBSD yoda 9.0-STABLE FreeBSD 9.0-STABLE #4: Fri May 25 20:36:02 CDT 2012 bob@yoda:/usr/obj/usr/src/sys/YODA amd64 I have attached my dmesg output, a copy of my xorg.conf file, and the output of 'pciconf -vl'. Anyone have any idea of what's going wrong, or what I can do to get X to work on this system? Thanks, Bob -- Bob WillcoxThe right half of the brain controls the left half b...@immure.com of the body. This means that only left handed people Austin, TX are in their right mind. Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-STABLE #4: Fri May 25 20:36:02 CDT 2012 bob@yoda:/usr/obj/usr/src/sys/YODA amd64 CPU: Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz (3292.59-MHz K8-class CPU) Origin = GenuineIntel Id = 0x306a9 Family = 6 Model = 3a Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x7fbae3ffSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8144031744 (7766 MB) Event timer LAPIC quality 600 ACPI APIC Table: INTEL A M I FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: INTEL on motherboard acpi0: Power Button (fixed) acpi0: reservation of 67, 1 (4) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 550 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 Event timer HPET3 frequency 14318180 Hz quality 440 Event timer HPET4 frequency 14318180 Hz quality 440 atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0xf000-0xf03f mem 0xf780-0xf7bf,0xe000-0xefff irq 16 at device 2.0 on pci0 xhci0: XHCI (generic) USB 3.0 controller mem 0xf7d2-0xf7d2 irq 16 at device 20.0 on pci0 usbus0: waiting for BIOS to give up control xhci0: 32 byte context size. usbus0 on xhci0 pci0: simple comms at device 22.0 (no driver attached) em0: Intel(R) PRO/1000 Network Connection 7.3.2 port 0xf080-0xf09f mem 0xf7d0-0xf7d1,0xf7d39000-0xf7d39fff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: e8:40:f2:0b:45:53 ehci0: EHCI (generic) USB 2.0 controller mem 0xf7d38000-0xf7d383ff irq 16 at device 26.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 pci0: multimedia, HDA at device 27.0 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 19 at device 28.7 on pci0 pci2: ACPI PCI bus on pcib2 fwohci0: 1394 Open Host Controller Interface port 0xe000-0xe0ff mem 0xf7c0-0xf7c007ff irq 19 at device 0.0 on pci2 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 e0:cb:4e:00:00:0f:c7:bc fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 dcons_crom0: dcons configuration ROM on firewire0 dcons_crom0: bus_addr 0xd9d44000 fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet
Re: Constant rebooting after power loss
On Fri, Apr 01, 2011 at 03:29:39PM +0200, Marko Lerota wrote: George Kontostanos gkontos.m...@gmail.com writes: Not with the same behavior and it depends on what your server is doing at the time of the power interruption. It was in stage of booting after first power loss. but ZFS is not the solution to your problem. ZFS is not designed to replace the needs of a UPS. I'm just asking if this wouldn't happen if I used ZFS. I read that ZFS don't need fsck because the files are always consistent on filesystem regardless of power loses. That the corruption can occur only if disks are damaged. But not when power goes down. I'm not planing to buy UPS for home use. I really don't know much about ZFS, but I do know about disks (I work on SAS device drivers for AIX and deal with lots of disks); and I doubt that any filesystem is going to be immune to sudden power failures when writing to a disk. At least I wouldn't trust them. If you care about the integrity of your data, I would reconsider your plans about the UPS. -- Bob Willcox Trying to explain things to people who already know b...@immure.com everything is like trying to teach a bear to dance; Austin, TX it's useless, and it annoys the bear. ___ 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: sed is broken under freebsd?
On Tue, Jan 11, 2011 at 09:00:09PM -1000, Clifton Royston wrote: On Wed, Jan 12, 2011 at 02:32:52AM +0100, Oliver Pinter wrote: hi all! The freebsd versions of sed contained a bug/regression, when \n char can i subsitue, gsed not affected with this bug: FreeBSD xxx 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 a...@xxx ~ echo axa | sed s/x/\n/g ana a...@xxx ~ echo axa | sed s/x/'\n'/g ana Different than GNU is not a bug. I have 7.3 here. It behaves as the above, which is how the man page says it should work. The following is how the man page specifies you can substitute a newline, by prefacing a quoted actual newline with a backslash: $ echo axa | sed 's/x/\ /g' a a That's how I remember classic sed behaving (Unix v7 or thereabouts.) -- Clifton FWI, AIX 6.1 sed works as the FreeBSD sed does. -- Bob Willcox When the ax entered the forest, the trees said, b...@immure.com The handle is one of us! Austin, TX -- Turkish proverb ___ 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: ipfw natd with recent MFC of firewall_coscripts functionality
On Mon, Mar 01, 2010 at 08:24:54PM +0300, hizel wrote: Hi. Similar problem. Now updated to 7.3-PRERELEASE. rc script natd said he did not know parameter quietstart. Now migrate to use kernel nat. I was able to confirm that simply changing quietstart and quietstop in the /etc/rc.d/ipfw script to start and stop, respectively, fixes the problem. ___ 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 -- Bob Willcox The shifts of Fortune test the reliability of friends. b...@immure.com-- Marcus Tullius Cicero Austin, TX ___ 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
ipfw natd with recent MFC of firewall_coscripts functionality
I just updated my gateway machine to 7.3-PRERELEASE and immediately noticed
that natd no longer started (hard to miss, no outside network access).
It looks like the MFC of the firewall_coscripts function may be the cause
(cvs rev 1.15.2.3 to /usr/src/etc/rc.d/ipfw). These changes add the two lines
(along with other stuff):
...
${_coscript} quietstart
...
${_coscript} quietstop
...
I believe the problem is that neither quietstart or quietstop are
recognized as valid arguments in by /etc/rc.d/natd so natd isn't started.
Further, my hunch is that by removing the quiet prefix it will work (I'm
reluctant to try this at the moment as I am remote).
Bob
--
Bob Willcox The shifts of Fortune test the reliability of friends.
b...@immure.com-- Marcus Tullius Cicero
Austin, TX
___
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: RELENG_7 hangs on boot w/Gigabyte MA78GM-S2H MB - maybe the 8650?
On Sat, Sep 20, 2008 at 01:50:24PM -0500, Bob Willcox wrote: On Sat, Sep 20, 2008 at 08:05:33AM -0700, Jeremy Chadwick wrote: On Sat, Sep 20, 2008 at 09:45:10AM -0500, Bob Willcox wrote: On Sat, Sep 20, 2008 at 07:04:56AM -0700, Jeremy Chadwick wrote: On Sat, Sep 20, 2008 at 08:24:29AM -0500, Bob Willcox wrote: [snip] I have since tried installing the 7.1 BETA on a system with the same CPU (a Phenom 8650 X3) and a different motherboard that I have had success running 7.1-PRELEASE on (the system I'm typing this message on, though it has a Phenom 9850 X4) and it still hangs at appx the same point (after enabling the second third processors). Is there anyone else out there having problems with this CPU on 7.1? Bob -- Bob Willcox All the evidence concerning the universe [EMAIL PROTECTED] has not yet been collected, so there's still hope. Austin, TX ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7 hangs on boot w/Gigabyte MA78GM-S2H MB
On Sat, Sep 20, 2008 at 05:39:14AM -0700, Jeremy Chadwick wrote: On Fri, Sep 19, 2008 at 11:24:18PM -0500, Bob Willcox wrote: Hi All, I'm trying to get the latest RELENG_7 to run on my new Gigabyte MA78GM-S2H motherboard and am experiencing a hang on boot right after it prints the message: Trying to mount root from ufs:/dev/ad4s1a At this point it is hung and doesn't respond to any keyboard input. I originally attempted to install the 7.1 beta system with similar results (prevented me from installing). I then installed 7.0-release and though the install succeeded it never did see the Realtek ethernet controller so I had no network capability. You're describing multiple problems in a single Email. This is liable to get complex. Sorry, that wasn't my intention. I was just trying to document my experience with this particular motherboard (I have a number of others that work fine with FreeBSD 7-stable, this one I'm typing this on is a very similar Gigabyte board in fact). 1) It would be helpful to know if you installed i386 or amd64 FreeBSD, This is amd64 on this particular machine. 2) With regards to the lock-up after mount root, if you press NumLock or CapsLock, do the keyboard LEDs turn on/off? Nope, no keys do anything. You must either push reset or pull the plug. 3) Many others have seen the hanging/lock-up after mount root. I believe one found a workaround by setting ATA_STATIC_ID in their kernel configuration. I realise this is a problem when you can't get the system up to a point of building a kernel; chicken-and-egg problem, Well, I can build a kernel if I run the 7.0-release kernel. That's how I got to 7-stable on the machine in the first place. I used sneaker net to copy it to this one via a CD (as I mentioned, the 7.0 kernel boots but the Realtek ethernet device is not recognized). 4) The Realtek NIC on that motherboard is probably too new to be supported under RELENG_7. Realtek has a history of releasing different sub-revisions of the same NIC/PHY, and the internal changes are severe enough to cause the NIC to not work correctly (under any OS) without full driver support for that specific sub-revision. That's what I suspected. The values displayed when doing a pciconf -lv are similar as for this system I'm using to type this, but now that I look closer and make a direct comparison, the failing device has a rev=0x02 vs. rev=0x01 for the working one. The pciconf -lv output for the failing mb is: [EMAIL PROTECTED]:2:0:0: class=0x02 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet All above said: Can you please try one of the RELENG_7 ISO snapshots at the below site, instead of the official 7.0-RELEASE ISO, and report back if that solves either of your problems? The below site contains ISOs built daily, rather than monthly: I'll be happy to try that, but the kernel I most recently tried was from 7-stable source that I cvsup'd just yesterday. Since both the official 7.1-BETA and very recent 7-stable hang the same way I suspect that all of the newer kernels will experience this hang. Let me know if you still think it's worth trying one of the snapshots. I do plan to try the ATA_STATIC_ID setting that you mentioned above to see if that helps. Let me know if there is anything else I should try. I am able to build kernels so long as I run the 7.0 kernel (and work around the network problem). Thanks for your time response! Bob http://pub.allbsd.org/FreeBSD-snapshots/ -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | -- Bob Willcox All the evidence concerning the universe [EMAIL PROTECTED] has not yet been collected, so there's still hope. Austin, TX ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7 hangs on boot w/Gigabyte MA78GM-S2H MB
On Sat, Sep 20, 2008 at 07:04:56AM -0700, Jeremy Chadwick wrote: On Sat, Sep 20, 2008 at 08:24:29AM -0500, Bob Willcox wrote: 1) It would be helpful to know if you installed i386 or amd64 FreeBSD, This is amd64 on this particular machine. 2) With regards to the lock-up after mount root, if you press NumLock or CapsLock, do the keyboard LEDs turn on/off? Nope, no keys do anything. You must either push reset or pull the plug. Is it possible to get the output when booting in verbose mode? If not, what are the last few lines before the machine locks up when booting verbosely? Yep, just did that. The last things printed right before hang are: ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 6 to local APIC 2 ioapic0: Assigning ISA IRQ 7 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 12 to local APIC 2 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA PCI 16 to local APIC 1 ioapic0: Assigning ISA PCI 17 to local APIC 2 ioapic0: Assigning ISA PCI 18 to local APIC 0 ioapic0: Assigning ISA PCI 19 to local APIC 1 ioapic0: Assigning ISA PCI 22 to local APIC 2 trying to mount root from ufs:/dev/ad4s1a start_init: trying /sbin/init [hung at this point] 3) Many others have seen the hanging/lock-up after mount root. I believe one found a workaround by setting ATA_STATIC_ID in their kernel configuration. I realise this is a problem when you can't get the system up to a point of building a kernel; chicken-and-egg problem, Well, I can build a kernel if I run the 7.0-release kernel. That's how I got to 7-stable on the machine in the first place. I used sneaker net to copy it to this one via a CD (as I mentioned, the 7.0 kernel boots but the Realtek ethernet device is not recognized). So the problem is that 7.0-RELEASE works fine for you, but after upgrading your RELENG_7 source (to what is now 7.1-BETA), the machine hangs after printing the mount root message. Is this correct? Yes, that is pretty much it. The Realtek ethernet isn't working in in 7.0-RELEASE either, but I'm guessing that that is a different (and less serious) problem related to changes in that device. Here's another question: does booting into single-user exhibit the same problem as multi-user? It looks like when I try a single-user mode (and verbose) boot the only difference is that the las line shown above (the start_init line) isn't printed. Otherwise, the hang is the same. 4) The Realtek NIC on that motherboard is probably too new to be supported under RELENG_7. Realtek has a history of releasing different sub-revisions of the same NIC/PHY, and the internal changes are severe enough to cause the NIC to not work correctly (under any OS) without full driver support for that specific sub-revision. That's what I suspected. The values displayed when doing a pciconf -lv are similar as for this system I'm using to type this, but now that I look closer and make a direct comparison, the failing device has a rev=0x02 vs. rev=0x01 for the working one. The pciconf -lv output for the failing mb is: [EMAIL PROTECTED]:2:0:0: class=0x02 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet Regarding the Realtek issue: I've CC'd PYUN Yong-Hyeon (surname in caps), who maintains the re(4) driver for FreeBSD. He might have a patch available for you to try, or help determine how to get this NIC working on FreeBSD. He'll probably need more than just pciconf -lv output, but should be able to work with you. Ok, that'd be great. I must say that I'm close to simply returning this MB and going with something not quite so new that is more likely to work. I was hoping to get this system up and running this weekend. :( Thanks, Bob Thanks! -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | -- Bob Willcox All the evidence concerning the universe [EMAIL PROTECTED] has not yet been collected, so there's still hope. Austin, TX ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7 hangs on boot w/Gigabyte MA78GM-S2H MB
On Sat, Sep 20, 2008 at 08:05:33AM -0700, Jeremy Chadwick wrote: On Sat, Sep 20, 2008 at 09:45:10AM -0500, Bob Willcox wrote: On Sat, Sep 20, 2008 at 07:04:56AM -0700, Jeremy Chadwick wrote: On Sat, Sep 20, 2008 at 08:24:29AM -0500, Bob Willcox wrote: 1) It would be helpful to know if you installed i386 or amd64 FreeBSD, This is amd64 on this particular machine. 2) With regards to the lock-up after mount root, if you press NumLock or CapsLock, do the keyboard LEDs turn on/off? Nope, no keys do anything. You must either push reset or pull the plug. Is it possible to get the output when booting in verbose mode? If not, what are the last few lines before the machine locks up when booting verbosely? Yep, just did that. The last things printed right before hang are: ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 6 to local APIC 2 ioapic0: Assigning ISA IRQ 7 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 12 to local APIC 2 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA PCI 16 to local APIC 1 ioapic0: Assigning ISA PCI 17 to local APIC 2 ioapic0: Assigning ISA PCI 18 to local APIC 0 ioapic0: Assigning ISA PCI 19 to local APIC 1 ioapic0: Assigning ISA PCI 22 to local APIC 2 trying to mount root from ufs:/dev/ad4s1a start_init: trying /sbin/init [hung at this point] 3) Many others have seen the hanging/lock-up after mount root. I believe one found a workaround by setting ATA_STATIC_ID in their kernel configuration. I realise this is a problem when you can't get the system up to a point of building a kernel; chicken-and-egg problem, Well, I can build a kernel if I run the 7.0-release kernel. That's how I got to 7-stable on the machine in the first place. I used sneaker net to copy it to this one via a CD (as I mentioned, the 7.0 kernel boots but the Realtek ethernet device is not recognized). So the problem is that 7.0-RELEASE works fine for you, but after upgrading your RELENG_7 source (to what is now 7.1-BETA), the machine hangs after printing the mount root message. Is this correct? Yes, that is pretty much it. The Realtek ethernet isn't working in in 7.0-RELEASE either, but I'm guessing that that is a different (and less serious) problem related to changes in that device. Here's another question: does booting into single-user exhibit the same problem as multi-user? It looks like when I try a single-user mode (and verbose) boot the only difference is that the las line shown above (the start_init line) isn't printed. Otherwise, the hang is the same. 4) The Realtek NIC on that motherboard is probably too new to be supported under RELENG_7. Realtek has a history of releasing different sub-revisions of the same NIC/PHY, and the internal changes are severe enough to cause the NIC to not work correctly (under any OS) without full driver support for that specific sub-revision. That's what I suspected. The values displayed when doing a pciconf -lv are similar as for this system I'm using to type this, but now that I look closer and make a direct comparison, the failing device has a rev=0x02 vs. rev=0x01 for the working one. The pciconf -lv output for the failing mb is: [EMAIL PROTECTED]:2:0:0: class=0x02 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet Regarding the Realtek issue: I've CC'd PYUN Yong-Hyeon (surname in caps), who maintains the re(4) driver for FreeBSD. He might have a patch available for you to try, or help determine how to get this NIC working on FreeBSD. He'll probably need more than just pciconf -lv output, but should be able to work with you. Ok, that'd be great. I must say that I'm close to simply returning this MB and going with something not quite so new that is more likely to work. I was hoping to get this system up and running this weekend. :( I wish I knew what was causing the lock-up for you. I'm truly baffled, especially given that the system is able to boot + find the kernel + load kernel modules. Debugging this problem is out of field; jhb@ might have some ideas, as I'm not sure what magic happens immediately before the root filesystem is mounted. Those debugging/helping may want disklabel -r -A ad4s1 output. At least you can boot 7.0-RELEASE to get that information. Regarding hardware: I myself purchased an Asus P5Q SE board, with an Intel Q9550 CPU earlier this week. The board was affordable (barely US$100). One of the reasons I went with this board is because it lacks
RELENG_7 hangs on boot w/Gigabyte MA78GM-S2H MB
Hi All, I'm trying to get the latest RELENG_7 to run on my new Gigabyte MA78GM-S2H motherboard and am experiencing a hang on boot right after it prints the message: Trying to mount root from ufs:/dev/ad4s1a At this point it is hung and doesn't respond to any keyboard input. I originally attempted to install the 7.1 beta system with similar results (prevented me from installing). I then installed 7.0-release and though the install succeeded it never did see the Realtek ethernet controller so I had no network capability. Has anyone else seen this behavior. Any ideas/suggestions on what I can do to further track it down. In addition to the motherboard, the system has a Phenom 8650 processor and 4GB of memory. The disk is a 320GB SATA WD Caviar. Thanks, Bob -- Bob Willcox All the evidence concerning the universe [EMAIL PROTECTED] has not yet been collected, so there's still hope. Austin, TX ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SAS Raid - mfi driver
On Wed, Nov 01, 2006 at 12:34:22AM +0100, Fredrik Widlund wrote: Yes, it forces writeback even when the controller has no BBU. Choosing WBack itself will default back to WThru. It's dangerous, but I guess it should be much less dangerous than using for example softupdates. I don't see how it could be *less* dangerous than using softupdates. Any loss of power while writing and it seems to me that you are going to be screwed w/o a BBU. [snip] -- Bob Willcox Possessions increase to fill the space [EMAIL PROTECTED]available for their storage. Austin, TX -- Ryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpu usage
On Mon, Oct 23, 2006 at 08:39:58PM +0200, gareth wrote: [snip] On Mon 2006-10-23 (18:57), Roland Smith wrote: Forgot the thermal paste between the CPU and the fan? Overclocked the CPU? nope ;) i built this machine 3 years ago i think, whenever the 2600+'s came out. it's only been giving trouble in the past few months. I've had machines that have been in service for several years start to overheat due to dust accumulation in the CPU cooler fins. If you haven't already done so, you might want to check for that. Bob -- Bob Willcox Possessions increase to fill the space [EMAIL PROTECTED]available for their storage. Austin, TX -- Ryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LSI/amr driver controller cache problem?
On Fri, Sep 01, 2006 at 11:15:37AM -0600, Scott Long wrote: Patrick M. Hausen wrote: [snip] It is very arguably a bug in the LSI firmware if it is actually dumping its cache when a PCI reset occurs, especially if a battery unit is present. However, I seriously doubt that you will get anyone at LSI to listen to this problem. Do you get any messages on the console at shutdown about the amr driver flushing the cache? Also, check the cache setting on the drives itself. Maybe the drives are loosing power or getting reset while data is in their cache. It's bad practice to enable the write cache on a drive in an RAID array for just this very reason, but some vendors do it anyways in an attempt to cover up poor performance. Is there some way to tell if write caching is turned on or not for the drives in the array? In particular, I have an Areca controller (ARC-1210) with 4 SATA drives attached that I would like to check for this on. Bob -- Bob Willcox Possessions increase to fill the space [EMAIL PROTECTED]available for their storage. Austin, TX -- Ryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: suggestions for SATA RAID cards
On Wed, Aug 23, 2006 at 12:02:47PM +0200, Willem Jan Withagen wrote: Steven Hartland wrote: The Areca cards I can recommend. Highpoint 1820a is surprisingly good for its price and the later cards have better performance still apparently. N.B. Use the min stripe size when creating the array for max performance with this card under FreeBSD. I was more thinking along the lines of a HighPoint 2720, but perhaps a 1820 would also do fine. What device driver would one use with that. [Ahhh, 'man -k highpoint' is your friend] Now what I liked about the 3ware stuff was that there are tools to work the raid from within FreeBSD. So that would require the newers ones... But the hardware list is only showing the 2320 and 2322 with a rr232x(4) driver. Which sort of makes me wonder for all the other stuff and their drivers. The motherboard has both PCI-X and PCI-E so that should not be a connector problem. Now which bus is faster: 64Bit PCI-X at 133 Mhz, or a PCI-E 16x? The x16 PCI-E has considerably faster theoretical speed than 133 PCI-X (appx. 4GBs vs. 1GBs). However, the RAID controllers that I've seen are at most x8 so they are only capable of transfer rates half that fast (2GBs). Personally, I would go with PCI-E since in some performance tests I did with Areca cards last year (both PCI-E and PCI-X) there appeared to be a slight performance advantage to the PCI-E cards (sorry, I don't recall any of the specifics anymore, so please take that for what it's worth). BTW, I've had good experience with the Areca cards in FreeBSD (recent stable). Bob --WjW Willem Jan Withagen wrote: Hi, I've ran into sort of a snag with building a 2T file server. Given all the good press here for 3ware and the talk to the guys at the CeBIT I decided to go for a 9550SX-LP8. With that I bought a ASUS serverboard: K8N-LR with 165 dual core opteron. In itself is this a combo that I thing would do for a long time at my home. ;) However the 3ware controler decided not to play nice with 2 of the PCI-X boards I have here. It gets stuck in the bios disc scan. I've RMA-ed the card, but my guess is that it'll take a too long a time to fix/replace it for my patience. So I'm looking for alternatives with good support under amd64. I've seen that the Adaptecs are supported under aac(4). But what about Promisse or Highpoint RAID controllers? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Bob Willcox Possessions increase to fill the space [EMAIL PROTECTED]available for their storage. Austin, TX -- Ryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: suggestions for SATA RAID cards
On Wed, Aug 23, 2006 at 10:05:18AM -0500, Greg Martin wrote: I find it hard to believe nobody has mentioned 3ware, they are a bit more expensive but you pay for top notch quality, stability... Their newer cards support PCI-X and SATA II /w hotswap. BTW, just as a data point, my Areca controller (ARC-1210) has on several occasions demonstrated it's ability to recover nicely from drive failures. One of my Maxtor disks has this bad habit of periodically hanging. Popping the drive out and putting it back in causes the controller to immediately notice it and begin an automatic background rebuild (its a RAID5 configuration w/four 500GB disks). The rebuild takes about three hours to complete (on an unloaded system). Bob -Greg ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Bob Willcox Possessions increase to fill the space [EMAIL PROTECTED]available for their storage. Austin, TX -- Ryan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 vs amd64 - benchmark results
On Tue, Jul 26, 2005 at 07:57:06PM +0200, Martin wrote: Hi, I've tried two benchmarks to check the speed of my system on two FreeBSD architectures i386 and amd64. I've never seen anyone posting this kind of benchmark, so here is what I found out: here the results of nbench: http://phpfi.com/71540 here is what openssl speed gives me: http://phpfi.com/71545 Sorry for posting it there, but I don't want to send attachments to this list. Please notice the memory speed penalties while the system is running on amd64 kernel. I would like to know what causes this kind of low performance when memory is being accessed. Is this a hardware problem or a problem with FreeBSD? Generally, FreeBSD-amd64 performs slightly better than FreeBSD-i386 and it's stable as expected, but I cannot find any solution to the memory problems that affect memory intensive applications as you can see. Martin As another data point, below is the nbench output from one of my systems. It's an Athlon 64 3800+ w/ venice core running FreeBSD 6.0-BETA1. Motherboard is an ASUS A8V Deluxe (socket 939) with 1GB of DDR400 RAM (2 512MB sticks). BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST: Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* :--:-: NUMERIC SORT:2326 : 59.65 : 19.59 STRING SORT : 202.35 : 90.41 : 13.99 BITFIELD: 5.2938e+08 : 90.81 : 18.97 FP EMULATION: 153.36 : 73.59 : 16.98 FOURIER : 18608 : 21.16 : 11.89 ASSIGNMENT : 27.817 : 105.85 : 27.46 IDEA:3400 : 52.00 : 15.44 HUFFMAN : 1869.4 : 51.84 : 16.55 NEURAL NET : 24.696 : 39.67 : 16.69 LU DECOMPOSITION: 1237.9 : 64.13 : 46.31 ==ORIGINAL BYTEMARK RESULTS== INTEGER INDEX : 72.257 FLOATING-POINT INDEX: 37.759 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==LINUX DATA BELOW=== CPU : L2 Cache: OS : FreeBSD 6.0-BETA1 C compiler : cc libc: /lib/libc.so.6 MEMORY INDEX: 19.388 INTEGER INDEX : 17.076 FLOATING-POINT INDEX: 20.942 Baseline (LINUX): AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder. -- Bob WillcoxReality is nothing but a collective hunch. [EMAIL PROTECTED] -- Lily Tomlin Austin, TX ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: XFree 4.3.0 / Xft font problems
On Tue, Mar 18, 2003 at 02:10:29PM -0500, Jason Andresen wrote:
Bob Willcox wrote:
On Tue, Mar 18, 2003 at 10:27:44AM -0500, Jason Andresen wrote:
Kenneth W Cochran wrote:
[snip]
Oh! It's too small. Why didn't you say so.
You can change the font size in your
.mozilla/username/randomstring/chrome/userChrome.css
Specifically, you can add:
window
{
font-size: 12pt !important;
font-family: helvetica !important;
}
More information is on: http://www.mozilla.org/unix/customizing.html
Unfortunatly I'm away from my FreeBSD machine, so I can't verify that
this works as advertised, but hopefully I've pointed you in the right
direction.
The above URL has gotten me closer but dialog box fonts are still too
small (such as the print box).
Any clue as to what needs to be changed to get the fonts in the dialog
boxes bigger?
Thanks,
Bob
--
\ |_ _|__ __|_ \ __| Jason Andresen[EMAIL PROTECTED]
|\/ | ||/ _| Network and Distributed Systems Engineer
_| _|___| _| _|_\___| Office: 703-883-7755
--
Bob Willcox Patience is a minor form of despair, disguised as virtue.
[EMAIL PROTECTED]-- Ambrose Bierce, on qualifiers
Austin, TX
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: Updated to today's -stable and can no longer connect to the XFree86 server
On Wed, Feb 19, 2003 at 07:24:41AM -0800, Erick Mechler wrote: :: XFree86 does not listen on TCP ports by default. You have to enable :: it if you want this behaviour (see man startx or man xdm). :: :: Well then I am confused. I didn't change XFree86. I only updated the :: system. Why would I suddenly see this new behavior? For example, if you have xdm starting out of /etc/ttys and you blindly update everything mergemaster tells you to, you might overwrite some of your custom configs. Well, I don't use xdm. I always have (for many years now) started the X server using startx, and I do see that startx (which hasn't been changed on my system since last December) does explicitly specify -nolisten tcp if not told otherwise. The thing that is a mystery to me is that before upgrading to Feb 18's -stable my X server was allowing connections. I can't explain why it used to work! :-) Bob Cheers - Erick -- Bob WillcoxWe seem to have forgotten the simple truth that [EMAIL PROTECTED] reason is never perfect. Only non-sense attains Austin, TX perfection. -- Poul Henningsen [1894-1967] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Updated to today's -stable and can no longer connect to the XFree86 server
On Wed, Feb 19, 2003 at 07:41:45AM -0800, Erick Mechler wrote: :: For example, if you have xdm starting out of /etc/ttys and you blindly :: update everything mergemaster tells you to, you might overwrite some of :: your custom configs. :: :: Well, I don't use xdm. I always have (for many years now) started the :: X server using startx, and I do see that startx (which hasn't been :: changed on my system since last December) does explicitly specify :: -nolisten tcp if not told otherwise. Perhaps you had an entry in your .xinitrc to override the command-line settings which isn't there anymore? Eh, just grasping at straws here... I couldn't find anything...besides I haven't changed my .xinitrc in sometime. Bob Cheers - Erick -- Bob WillcoxWe seem to have forgotten the simple truth that [EMAIL PROTECTED] reason is never perfect. Only non-sense attains Austin, TX perfection. -- Poul Henningsen [1894-1967] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Updated to today's -stable and can no longer connect to the XFree86 server
On Wed, Feb 19, 2003 at 09:23:47AM -0800, Nathan Kinkade wrote: This is just another shot in the dark, but I see that you are trying to connect to a machine named 'luke'. Maybe your /etc/hosts file was overwritten and now name resolution isn't happening like it should locally? What happens if you try to connect using the ip address like: $ xterm -display 192.168.1.100:0 I use named (DNS) to resolve all of my host names so my /etc/hosts file is empty. Right now my X server is allowing connections (I restarted it with startx -listen_tcp) so I'm convinced that that was it (still doesn't explain why it used to work). Also, when on the machine named 'luke' what is the output of `xhost`. If you want everyone to be able to connect then it should output something like: $ xhost access control disabled, clients can connect from any host Yep. Also, can you verify 100% that X is actually listening on host 'luke' by browsing the output of `sockstat -l4`? This is what I get right now: bob@luke:pa /home/bob sockstat -l4|grep XFree86 root XFree86 414641 tcp4 *:6000*:* but it's working now also. One more thing: how did you upgrade? Are you certain that you don't have a firewall running on the newly upgraded system? I updated from source. I cvsup the cvs repo and update my /usr/src tree from that with cvs. Good luck, Nathan Thanks for you time and thoughts, Bob -- GPG Public Key ID: 0x4250A04C gpg --keyserver pgp.mit.edu --recv-keys 4250A04C http://63.105.21.156/gpg_nkinkade_4250A04C.asc -- Bob WillcoxWe seem to have forgotten the simple truth that [EMAIL PROTECTED] reason is never perfect. Only non-sense attains Austin, TX perfection. -- Poul Henningsen [1894-1967] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Updated to today's -stable and can no longer connect to the XFree86 server
On Wed, Feb 19, 2003 at 11:37:24AM -0800, Kris Kennaway wrote: On Wed, Feb 19, 2003 at 09:38:07AM -0600, Bob Willcox wrote: Well, I don't use xdm. I always have (for many years now) started the X server using startx, and I do see that startx (which hasn't been changed on my system since last December) does explicitly specify -nolisten tcp if not told otherwise. The thing that is a mystery to me is that before upgrading to Feb 18's -stable my X server was allowing connections. I can't explain why it used to work! :-) The default was changed quite a while ago, so perhaps you just hadn't upgraded X in a long time? That's the mystery. I last updated XFree86 on Dec 23rd, and yet I have rebooted and restarted X several times since then (with connections to the X server working). This happened just yesterday (after upgrading the system and rebooting. Bob Kris -- Bob WillcoxWe seem to have forgotten the simple truth that [EMAIL PROTECTED] reason is never perfect. Only non-sense attains Austin, TX perfection. -- Poul Henningsen [1894-1967] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: sshd_config vs. PAM
On Mon, Oct 07, 2002 at 04:20:51PM -0700, Kris Kennaway wrote: On Mon, Oct 07, 2002 at 04:57:39PM -0600, Samuel Chow wrote: BTW, is there a way to completely disable PAM on a system? I was looking at it a couple months back. There is the NOPAM compiler flag. Unfortunately, telnet and ssh does not obey it. I have some untested patch at home before I got too busy with other non-FreeBSD things. PAM is considered to be an integral part of the system thesedays; as such there's no support for compiling without it. Too bad. I find it to be rather painful to understand and configure, and overkill for most of uses. Bob Kris -- Bob WillcoxWe seem to have forgotten the simple truth that [EMAIL PROTECTED] reason is never perfect. Only non-sense attains Austin, TX perfection. -- Poul Henningsen [1894-1967] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: sshd_config vs. PAM
On Mon, Oct 07, 2002 at 04:56:24PM -0700, Kris Kennaway wrote: On Mon, Oct 07, 2002 at 06:42:48PM -0500, Bob Willcox wrote: On Mon, Oct 07, 2002 at 04:20:51PM -0700, Kris Kennaway wrote: On Mon, Oct 07, 2002 at 04:57:39PM -0600, Samuel Chow wrote: BTW, is there a way to completely disable PAM on a system? I was looking at it a couple months back. There is the NOPAM compiler flag. Unfortunately, telnet and ssh does not obey it. I have some untested patch at home before I got too busy with other non-FreeBSD things. PAM is considered to be an integral part of the system thesedays; as such there's no support for compiling without it. Too bad. I find it to be rather painful to understand and configure, and overkill for most of uses. Well, the point is that the default configuration is supposed to be exactly equivalent to the old non-PAM behaviour, so you shouldn't have to touch *anything* unless you want to change this behaviour (which would have required code changes in the non-PAM case). I have to admit, that recently (last year or so) this seems to be the case. It wasn't always that way, though. As I recall, rlogin didn't work w/o modifying the PAM configuration file for quite some time. I still contend that, for the PAM challenged, the description of the configuration file is a tough read. Bob Kris -- Bob WillcoxWe seem to have forgotten the simple truth that [EMAIL PROTECTED] reason is never perfect. Only non-sense attains Austin, TX perfection. -- Poul Henningsen [1894-1967] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Software raid 1 on root partition?
On Sun, Jul 14, 2002 at 07:15:24AM +0200, Steve O'Hara-Smith wrote: On Sun, 14 Jul 2002 10:12:47 +0930 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: G On Saturday, 13 July 2002 at 22:27:45 +0200, Steve O'Hara-Smith wrote: G It seems to be about RAID on standard non-raid controllers to my G poor eye. It does not mention that they will not work, only that there G are boot restrictions. G G I've been reading the atacontrol man page. It's not very clear, but G you could be right. If so, it's a well-kept secret. There also G appears to be no way to recover such a RAID 1 partition. I've found confirmation - There was a thread in -stable around the 18th of June (subject the new ATA driver vs. vinum) in which Bob Wilcox and Remo Lacho both mentioned running RAID arrays on non RAID controllers using the support in the ATA driver. Having RAID1 without recovery seems less than ideal though. I have been assuming (no confirmation as I haven't tried this yet) that the recovery process is to dump the file systems on the RAID1 configuration, replace the dead disk, reconfigure/newfs the filesystem, and then restore it. Certainly not ideal, but it still beats losing the data I think. The only part of this that I'm uncertain about is access to the array while one of its disks is dead. BTW, I've been running a RAID0+1 (striped and mirrored) configuration of 4 80GB IBM disks on this system for over a month now. Bob -- Bob Willcox Vital papers will demonstrate their vitality by [EMAIL PROTECTED] spontaneously moving from where you left them to where Austin, TX you can't find them. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ATA observations in FreeBSD 4.6-RC
On Tue, May 21, 2002 at 03:18:03PM +0800, Eugene Grosbein wrote: S?ren Schmidt wrote: Of cause it should, and belive me I'm doing all I can to try get this nailed. But I do have a real life as well, and a fulltime job, 3 kids, vife and lots of other important things to care for, so excuse me if I dont work 24 hours a day on this problem... Of course. How about backing out new ATA code and stick with old for the sake of 4.6-RELEASE stability? Not necessarily good for everyone. I have several systems that are now dependent upon the RAID support in ata (that I really can't afford to upgrade to -current). Does the old ata driver support the new driver's RAIDs? Bob -- Bob WillcoxDealing with failure is easy: work hard to improve. [EMAIL PROTECTED] Success is also easy to handle: you've solved the Austin, TX wrong problem. Work hard to improve. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: S2460 problems
On Wed, Dec 19, 2001 at 09:21:42AM -0500, Rick Bischoff wrote: Hello all, Ok, yesterday, I announced my problem-- here is a recap. I have a S2460 Tyan Tiger motherboard, with dual AMD 1700 XP+ processors, 512 MB ecc RAM, a 40 GB western digital ata 100 and a 30 GB western digital ata 100. The video card is an el-cheapo GeForce2 MX and the sound card is a sound blaster live! 5.1. The network card is an Intel EtherPro something or other. This system in its entirity works perfectly under Windows. Both CPUs are functioning properly it seems. However, when I installed FreeBSD onto either drive, the entire system hard locks at random times. What is a hard lock? Well, I can't type anything in, I can't telnet or ssh in and I sure as heck can't figure out why it crashed. I have the same problems using SuSE 7.3 Linux. I tried changing the MP spec in the BIOS from 1.4 to 1.1 compatibility, but it still hard locked. I was able to compile a 4.4 Stable kernel and boot into that, but soon after it hard locked just the same. One fellow suggested flashing the BIOS. Another suggested replacing the power supply-- my question is: Why does it work perfect under Windows if its a hardware problem? If anyone has had any kind of success with this motherboard I would like to know. What rev of the MB and BIOS do you have? The reason I ask this is because I have experienced similar problems with older revs of these boards. I have two systems with these boards in them configured thusly: System 1: Tyan S2460 MB (rev 1.3) 2 1.2GHz MP CPUs 1GB Reg ECC DDR RAM (4 DIMMs, 8 banks, Crucial brand) Generic AGP video card (SiS chipset, I think) IBM 40GB 7200 RPM IDE drive Adaptec 3960 SCSI controller with 9 disks on the two SCSI busses. 64-bit Linksys GigE NIC System 2: Tyan S2460 MB (rev 1.3) 2 1800+ MP CPUs 1GB Reg ECC DDR RAM (4 DIMMs, 8 banks, Crucial brand) Matrox G400 Graphics card IBM 40GB 7200 RPM IDE drive 64-bit Linksys GigE NIC The above configurations have been running solidly now for the past 3 weeks or so. Prior to that, I had older revs of the Tyan MB in the systems (there are visible component differences between the older and newer boards in the regulator area near the power connector and the BIOS flash chip has 1.3 printed on the newer boards) and was experiencing both intermittant and, sometimes, solid failures that appeared to be related to memory problems (random hangs while running the system, boot hangs [some with the beep code for memory errors and some without]). From what I have heard, Tyan is now claiming that these boards don't support more than 6 banks of memory (their user's manual claims that they do, even lists my configuration as typical in one place) and my configurations both have 8 banks. I don't have any idea if this is related to the problem you're having ( 6 banks of memory), but it is something to consider. Also, if you have the older boards I would attempt to switch them for the newer ones if possible. BTW, I had flashed the BIOS on both of the older boards with the latest 1.3 version but that didn't seem to help. At this point I suspect that it's really a hardware problem with either the Tyan MB or AMD chipset; and if I was a betting man, I'd put my money on the MB being at fault. Bob -- Best regards, Rickmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Bob Willcox Boucher's Observation: [EMAIL PROTECTED] He who blows his own horn always plays the music Austin, TX several octaves higher than originally written. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Athlon Thunderbird 700 w. Asus K7M Motherboard vs. FreeBSD 4.2
I can attest to the fact that Slot A thunderbirds do exist. I own 3 of them (one 900 and 2 700 MHz). I guess I was fortunate that my Slot A thuderbirds worked properly (all running FreeBSD) in the MBs (MSI and Abit) that I have, though I have also heard that problems exist with some MBs Bob On Fri, Jan 12, 2001 at 03:39:27PM -0800, Bernhard Beck wrote: According to an article published in c't 14/2000, page 32 (online at http://www.heise.de/ct/00/14/032/default.shtml, use Altavista's Babelfish to translate), Slot A Thunderbirds do exist. In a nutshell among other things AMD slightly changed the bus interface design on the Thunderbirds so that you need chipsets like VIA KT133, KM133 or AMD 760. But under certain conditions the Thunderbird can also work with a KX133 or the Irongate chipset. There is a nice table at the end of the article listing a few Slot A motherboards and if they worked or not with the two sample Slot A Thunderbirds c't had available in their lab at that time. Michael's Asus K7M with Irongate chipset is listed as working with the exact same BIOS version. ... snip ... -- Bob Willcox The reason we come up with new versions is not to [EMAIL PROTECTED]fix bugs. It's absolutely not. Austin, TX -- Bill Gates To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: VIA chip set
On Fri, Jul 07, 2000 at 07:56:24AM -0700, Eric J. Schwertfeger wrote: On Fri, 7 Jul 2000, Bob Willcox wrote: On Wed, Jul 05, 2000 at 05:01:16PM -0700, Eric J. Schwertfeger wrote: On Tue, 4 Jul 2000, Linh Pham wrote: Does anyone know if the boxed AMD processors that they are including the new Thunderbird varieties? Almost definitely not, since the Thunderbird motherboards are a very scarce commodity at the moment. What has changed with the Thunderbird motherboards? They've gone back to a socket instead of a slot-A. Of course, it's socket-A, which is different than anything that has come before it, so no preexisting motherboards will work. Ahh, that change. All of my Athlon MBs and CPUs (including thunderbird) are slot-A. I haven't even seen any socket-A MBs or CPUs yet. FWI, Slot-A thunderbird CPUs are available in the OEM channels (which is what I have), and they work just fine (for me) in Slot-A MBs. Bob -- Bob Willcox Man usually avoids attributing cleverness to somebody else -- [EMAIL PROTECTED]unless it is an enemy. Austin, TX-- A. Einstein To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Host command output changed in bind 8.2.2p5
I have noticed that the host command no longer produces the same output as it did prior to the bind 8.2.2p5 import to 3.4. For machines with an MX record prior to bind 8.2.2p5 I used to get: bob@obiwan-p4 /home/bob host umd1.umd.edu umd1.umd.edu is a nickname for haven.umd.edu haven.umd.edu has address 128.8.10.6 haven.umd.edu mail is handled (pri=4) by haven.umd.edu But now on a recently upgraded 3.4-stable system I get: bob@luke:p6 /home/bob host umd1.umd.edu umd1.umd.edu is a nickname for haven.umd.edu haven.umd.edu has address 128.8.10.6 haven.umd.edu has address 128.8.10.6 The uname -a output from the first system is: FreeBSD obiwan.pmr.com 3.4-RC FreeBSD 3.4-RC #11: Sun Dec 12 17:14:35 CST 1999 [EMAIL PROTECTED]:/usr2/src/sys/compile/OBIWAN i386 and the second: FreeBSD luke.immure.com 3.4-STABLE FreeBSD 3.4-STABLE #19: Thu Dec 30 20:10:23 CST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/LUKE i386 Anybody else noticed this? Thanks, Bob -- Bob Willcox Don't tell me that worry doesn't do any good. [EMAIL PROTECTED] I know better. The things I worry about don't Austin, TX happen. -- Watchman Examiner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
