Re: recovering from the 6.3 xorg mess
On Mon, 17 Mar 2008, peter stern wrote: > The initial install was done by sysinstall under the predefined > xdeveloper selection. I tried reinstalling xorg from ports by running > make deinstall and make reinstall but with no change in behavior. Where is your dmesg, /var/log/Xorg.0.log, and X config file? A listing of /var/db/pkg would be helpful to show what X ports you have installed. > My hardware has no problems running Slackware 12 or Openbsd 4.2. > Under those OSs, X11 works fine and configures without problems. > > What has happened to quality control in the FreeBSD release? Well *I* didn't have any problem running X on 6.3 release. Maybe you should have contributed by downloading an RC and testing it? G550's are very old cards, I don't think it's unreasonable to expect that someone doing RC testing would have one installed. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: recovering from the 6.3 xorg mess
Hi! > I'd appreciate suggestions on how to get a working xorg from the mess 6.3 > shipped with. I've been using FreeBSD since 2.2 and have never had much > trouble with it until the 6 branch was released. My hardware is pretty > generic Intel brand D865 motherboard, matrox g550 video. I don't customize > the kernel. I do clean installs not upgrades. Basically, the problem is with the matrox board. Due to the very same reasons I had to upgrade my workstation (good excuse 8-) Matrox provides a mga_hal binary to support the relevant resolution and other gimmicks of that board. This binary works with xorg-6.x, but not with xorg-7.x, because there were changes in the interfaces to the low-level things. As far as I can see, there is no driver from mga for 7.x available as of now. -- [EMAIL PROTECTED]+49 171 310137212 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
recovering from the 6.3 xorg mess
I'd appreciate suggestions on how to get a working xorg from the mess 6.3 shipped with. I've been using FreeBSD since 2.2 and have never had much trouble with it until the 6 branch was released. My hardware is pretty generic Intel brand D865 motherboard, matrox g550 video. I don't customize the kernel. I do clean installs not upgrades. The xorg in 6.3 doesn't install much in the way of required drivers. I got the mouse and keyboard drivers installed and also the mga driver. I have run xorgconfig to create what seems like a working xorg.conf. Startx brings up twm but only in 640x480. I cannot change modes. And yes, I have mode lines defined. If I put the correct horizontal and vertical scan rates in for my Viewsonic PT810 monitor, I get a screen display with lines precessing through it. xdm gives the same result. I have tried the other suggestions on configuring X in the FreeBSD handbook, including creating a basic xorg.conf. It tests okay but only in 640x480 and it has no modelines in the .conf. Adding modelines doesn't fix the problem. The initial install was done by sysinstall under the predefined xdeveloper selection. I tried reinstalling xorg from ports by running make deinstall and make reinstall but with no change in behavior. My hardware has no problems running Slackware 12 or Openbsd 4.2. Under those OSs, X11 works fine and configures without problems. What has happened to quality control in the FreeBSD release? peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet
On Sun, Mar 16, 2008 at 10:16:20PM +, ian j hart wrote: > Keyboard LEDs are broken for me on 6.3 amd64 (kbdmux). > I'd double check they work before you rely on this as a diagnostic tool. > > -- > ian j hart Well, that was the most basic test. I should have mentioned that, during the lockup: (a) Before I removed the "saver" line in rc.conf, hitting a key wouldn't turn the screensaver off. I removed it in case the kernel was writing *something* to the console, so I could get a glimpse. (b) Console switching no longer worked. Hope this helps Alex -- "Computer science is no more about computers than astronomy is about telescopes" -- E. W. Dijkstra ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet
On Sunday 16 March 2008 21:16:16 Alex Popa wrote: > This is a mixed reply to both the previous mails, bear with me please. > > On Sat, Mar 15, 2008 at 10:16:54PM +0100, Max Laier wrote: > > On Saturday 15 March 2008, Robert Watson wrote: > > > On Fri, 14 Mar 2008, Alex Popa wrote: > > > > [snip] > > > > The LOR messages from dmesg of 7.0-STABLE are as follows: > > > > > > > > lock order reversal: > > > > 1st 0xb19e0680 pf task mtx (pf task mtx) @ > > > > /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6729 2nd > > > > 0xff00042ea0f0 radix node head (radix node head) @ > > > > /usr/src/sys/net/route.c:147 > > > > I haven't seen this one before, can you obtain the trace for this, > > please? You might need KDB & DDB for that - not sure. > > I'll do my best (see below for my questions about getting a trace). > > > > > lock order reversal: > > > > 1st 0x80938508 PFil hook read/write mutex (PFil hook > > > > read/write mutex) @ /usr/src/sys/net/pfil.c:73 2nd 0x80938c48 > > > > tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:400 > > > > This one is most certainly harmless and can be ignored. It is caused by > > user/group rules, but a LOR with the read instance of a rwlock will not > > lead to a deadlock. > > I'm not using uid/gid/jail rules as far as I remember. I'll add another > reply with pf.conf and the script I use to generate and reload the ipfw > rules (but I'll anonymize them). > > > > Dear Alex, > > > > > > Thanks for this report, and sorry about the problem. It could well be > > > that the lock order warning from WITNESS is related to the hang, and > > > might reflect a recursion-related bug in the pf policy routing code. > > > I'm not sure to what extent you can tolerate further downtime, but it > > > would be useful to gather some more information about the hang itself > > > to try and confirm the involvement of lock order. In particular, if > > > it's feasible, it would be very helpful if you could boot back to the > > > 7-STABLE kernel (keeping the 6.2-STABLE userspace should be fine, I > > > > you'll need at least a new pfctl, because the ioctl interface to /dev/pf > > has changed. > > Switching between 6.2-RELEASE-p7 (not STABLE, because as I said 6.3 > exhibited the lockups too) and 7-STABLE isn't that much of a problem. > The upgrade path was "buy a new hard drive, set up everything and then > adapt the old config files"... actually we bought 2 harddrives, and I > set them up one with amd64 and another with i386. I think /etc and > /usr/local/etc are perfectly identical on these 2 (I adapted the configs > from 6.2 to 7.0, but I just copied them from amd64 to i386). > > So, actions needed to switch: Backup the database on 6.2 (with IP/MAC > mappings and a bit more), put in the 7.0 hard drive, boot off 7.0, > restore DB, let it run. Total downtime should be around 7 minutes tops. > > > > think), and when the hang occurs, use the console debuggger (ideally > > > hooked up to serial or firewire) to run the following debugging > > > commands: > > > > > >show pcpu > > >show allpcpu > > >trace > > >alltrace > > >show allocks > > >show witness > > >show lockedvnods > > >show uma > > >show malloc > > This is where things get a bit tricky, and I need advice. > > As I said, my observation is that the keyboard seems to stop working > when the lockup occurs, that is, pressing Num Lock won't toggle the > state of the LED. Thus I have some doubts that trying the good-old > Control-Alt-ESC would have the desired effect (dropping me into the > debugger). However, I'm not that familiar with the FreeBSD > architecture, and wouldn't be surprised if the LED toggling would be in > another thread and the macine will actually respond to the keyboard > interrupt and drop me into ddb. Also, judging by the lack of NumLock > activity (it works fine when the system's up), would serial console or > firewire be functional during the lockup? Keyboard LEDs are broken for me on 6.3 amd64 (kbdmux). I'd double check they work before you rely on this as a diagnostic tool. > > Also, a bit of explanations: > > Why I'm asking the above: The current motherboard has a serial port > (and it works, we've used it), but not a firewire port. The other > motherboard we tried has firewire, but no serial. As a console > workstation, I can get a few with serials, but not so easy with > firewire. The null modem cable might be a problem too, depending on > length. > > Also, since the lockup isn't easily reproducible, I'll probably need to > spend some hours on location and if I'm going to do that, I'd like a > degree of hope that either keyboard, serial console or firewire will > work. Also, firewire will require me to switch motherboards, but that > can be done together with the hard drive swapping, during the night. > > After a bit of studying NOTES, I was wondering if a combination of > serial console (or just plain console) with "options WITNESS_KDB" would > help
Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet (extra extra details - config files)
Attached are pf.conf and ipfw.txt. The former is loaded by the standard means, and the latter is loaded via ipfw -q /path/to/ipfw.txt Some comments: I've anonymized the files. Address in the 10.0.0.0/8 range stand for "internal" IP addresses, meaning one /27 and three /24 networks, and address in the 192.168.0.0/16 range stand for addresses on the directly connected "external" networks, meaning the 2 fibers to the ISP. Also I've junked all but the last byte of MAC addresses in ipfw. I know the ipfw setup looks scary, but worst case a layer2 packet (I should say frame) gets checked against 38 rules (39 if it's dropped). I could probably optimize a few more rules out of this, but I'm not sure it's worth the effort. For layer3 I haven't counted, but I doubt it's more than 10 rules (more likely 6-7). Tables "metro" and "special" in pf are contolled by OpenBGPD. They are synced to ipfw tables 1 and 2 respectively, by cron jobs that run every 3 minutes and only make the necessary changes. ipfw rules below the "DO NOT EDIT" line are automatically generated from a database of IP/MAC mappings. This can change asynchronously and can cause the script to be regenerated and run. The classification is supposed to speed things up a little, by not comparing a MAC address against all hosts in its subnet, but only against sqrt(hosts) other IPs and another sqrt(hosts) IP/MAC pairs. [and it's not exactly sqrt, but about half of the bits in the host part of the IP address] Have fun Alex -- "Computer science is no more about computers than astronomy is about telescopes" -- E. W. Dijkstra set move 0 to 1 set disable 0 # scary stuff, allow arp add 10 allow mac-type 0x0806 # filter MAC on input add 10 skipto 100 in recv em0 layer2 add 11 allow out xmit em0 layer2 add 12 allow in layer2 add 13 allow out layer2 # em0 - internal add 20 skipto 22000 in recv em0 add 25 allowout xmit em0 # em1 - external 1 - shape on 2 (in) / 20500 (out) add 30 skipto 2 in recv em1 add 35 skipto 20500 out xmit em1 # bge0 - extern 2 - shape on 21000 (in) / 21500 (out) add 40 skipto 21000 in recv bge0 add 45 skipto 21500 out xmit bge0 add 90 allow ip from any to any via lo0 add 95 allow ip from any to any -f zero # # TABLES # # 1 - metro # 2 - special # 10 - internal (all) # 11 - internal - routing external 1 (em1) # 12 - internal - routing external 2 (bge0) # 100 bandwidth A # 101 bandwidth B # 120, 121, 122 : this server: All IPs, IP bw A, IP bw B # NOTE: tables 1 and 2 are synchronized to pf tables named # "metro" and "special" by a script which runs every 3 minutes table 10 flush table 10 add 10.0.10.0/27 table 10 add 10.0.20.0/24 table 10 add 10.0.30.0/24 table 10 add 10.0.40.0/24 table 10 add 192.168.11.11 table 10 add 192.168.22.22 table 11 flush table 11 add 10.0.20.0/24 table 11 add 10.0.40.0/24 table 11 add 192.168.11.11 table 11 add 192.168.22.22 table 12 flush table 12 add 10.0.10.0/27 table 12 add 10.0.30.0/24 table 100 flush table 100 add 10.0.20.0/24 table 100 add 10.0.30.0/24 table 100 add 10.0.40.0/24 table 100 add 192.168.11.11 table 101 flush table 101 add 10.0.10.0/27 table 101 add 192.168.22.22 table 120 flush table 120 add 10.0.10.1 table 120 add 10.0.20.1 table 120 add 10.0.30.1 table 120 add 192.168.33.33 table 120 add 192.168.11.11 table 120 add 192.168.22.22 table 121 flush table 121 add 10.0.20.1 table 121 add 10.0.30.1 table 121 add 10.0.40.1 table 121 add 192.168.11.11 table 122 flush table 122 add 10.0.10.1 table 122 add 192.168.33.33 table 122 add 192.168.22.22 # # PIPES and QUEUES # -f pipe flush # bw A - in 1/out 2 pipe 1 config bw 4500kbits/s queue 1 config pipe 1 weight 10 mask dst-ip 0x pipe 2 config bw 200kbits/s mask src-ip 0x # bw B - in 3/out 4 pipe 3 config bw 1000kbits/s queue 3 config pipe 3 weight 10 mask dst-ip 0x pipe 4 config bw 1000kbits/s queue 4 config pipe 4 weight 10 mask src-ip 0x # external interface 1 (em1) - 11 in/12 out pipe 11 config bw 95Mbits/squeue 100 queue 11 config pipe 11 weight 10 mask dst-ip 0xqueue 100 pipe 12 config bw 95Mbits/squeue 100 queue 12 config pipe 12 weight 10 mask src-ip 0xqueue 100 # external interface 2 (bge0) - 21 in/22 out pipe 21 config bw 95Mbits/squeue 100 queue 21 config pipe 21 weight 10 mask dst-ip 0xqueue 100 pipe 22 config bw 95Mbits/squeue 100 queue 22 config pipe 22 weight 10 mask src-ip 0xqueue 100 ### # # Shaping - check order: Metro / Special / A / B (3 in, 3 out) # ### # em1 - ext 1 shaping - 2/20500 add 2 queue 11 ip from table(1) toany add 20005 queue 11 ip from table(2) toany add 20010 queue 1 ip from any to table(100) add 20010 queue 3 ip from any to table(101) add 20499 allowip from
Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet
This is a mixed reply to both the previous mails, bear with me please. On Sat, Mar 15, 2008 at 10:16:54PM +0100, Max Laier wrote: > On Saturday 15 March 2008, Robert Watson wrote: > > On Fri, 14 Mar 2008, Alex Popa wrote: > > > [snip] > > > The LOR messages from dmesg of 7.0-STABLE are as follows: > > > > > > lock order reversal: > > > 1st 0xb19e0680 pf task mtx (pf task mtx) @ > > > /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6729 2nd > > > 0xff00042ea0f0 radix node head (radix node head) @ > > > /usr/src/sys/net/route.c:147 > > I haven't seen this one before, can you obtain the trace for this, please? > You might need KDB & DDB for that - not sure. I'll do my best (see below for my questions about getting a trace). > > > lock order reversal: > > > 1st 0x80938508 PFil hook read/write mutex (PFil hook > > > read/write mutex) @ /usr/src/sys/net/pfil.c:73 2nd 0x80938c48 > > > tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:400 > > This one is most certainly harmless and can be ignored. It is caused by > user/group rules, but a LOR with the read instance of a rwlock will not > lead to a deadlock. I'm not using uid/gid/jail rules as far as I remember. I'll add another reply with pf.conf and the script I use to generate and reload the ipfw rules (but I'll anonymize them). > > Dear Alex, > > > > Thanks for this report, and sorry about the problem. It could well be > > that the lock order warning from WITNESS is related to the hang, and > > might reflect a recursion-related bug in the pf policy routing code. > > I'm not sure to what extent you can tolerate further downtime, but it > > would be useful to gather some more information about the hang itself > > to try and confirm the involvement of lock order. In particular, if > > it's feasible, it would be very helpful if you could boot back to the > > 7-STABLE kernel (keeping the 6.2-STABLE userspace should be fine, I > > you'll need at least a new pfctl, because the ioctl interface to /dev/pf > has changed. Switching between 6.2-RELEASE-p7 (not STABLE, because as I said 6.3 exhibited the lockups too) and 7-STABLE isn't that much of a problem. The upgrade path was "buy a new hard drive, set up everything and then adapt the old config files"... actually we bought 2 harddrives, and I set them up one with amd64 and another with i386. I think /etc and /usr/local/etc are perfectly identical on these 2 (I adapted the configs from 6.2 to 7.0, but I just copied them from amd64 to i386). So, actions needed to switch: Backup the database on 6.2 (with IP/MAC mappings and a bit more), put in the 7.0 hard drive, boot off 7.0, restore DB, let it run. Total downtime should be around 7 minutes tops. > > think), and when the hang occurs, use the console debuggger (ideally > > hooked up to serial or firewire) to run the following debugging > > commands: > > > >show pcpu > >show allpcpu > >trace > >alltrace > >show allocks > >show witness > >show lockedvnods > >show uma > >show malloc This is where things get a bit tricky, and I need advice. As I said, my observation is that the keyboard seems to stop working when the lockup occurs, that is, pressing Num Lock won't toggle the state of the LED. Thus I have some doubts that trying the good-old Control-Alt-ESC would have the desired effect (dropping me into the debugger). However, I'm not that familiar with the FreeBSD architecture, and wouldn't be surprised if the LED toggling would be in another thread and the macine will actually respond to the keyboard interrupt and drop me into ddb. Also, judging by the lack of NumLock activity (it works fine when the system's up), would serial console or firewire be functional during the lockup? Also, a bit of explanations: Why I'm asking the above: The current motherboard has a serial port (and it works, we've used it), but not a firewire port. The other motherboard we tried has firewire, but no serial. As a console workstation, I can get a few with serials, but not so easy with firewire. The null modem cable might be a problem too, depending on length. Also, since the lockup isn't easily reproducible, I'll probably need to spend some hours on location and if I'm going to do that, I'd like a degree of hope that either keyboard, serial console or firewire will work. Also, firewire will require me to switch motherboards, but that can be done together with the hard drive swapping, during the night. After a bit of studying NOTES, I was wondering if a combination of serial console (or just plain console) with "options WITNESS_KDB" would help get a "good enough" trace. The upside of this is that both LORs usually occur early (not much later than the login prompt, usually earlier) as opposed to after 12...18 hours, and I can either force a panic after each and get 2 core dumps, or run the debug commands suggested (either as debug LOR1 / continue / debug LOR2, or debug LOR1 / reboot / "continue" LO
Re: RELENG_7 /src/UPDATING out od date?
Abdullah Ibn Hamad Al-Marri wrote: Hey, http://www.freebsd.org/cgi/cvsweb.cgi/src/UPDATING?rev=1.507;only_with_tag=RELENG_7 NOTE TO PEOPLE WHO THINK THAT FreeBSD 7.x IS SLOW: FreeBSD 7.x has many debugging features turned on, in both the kernel and userland. These features attempt to detect incorrect use of system primitives, and encourage loud failure through extra sanity checking and fail stop semantics. They also substantially impact system performance. If you want to do performance measurement, benchmarking, and optimization, you'll want to turn them off. This includes various WITNESS- related kernel options, INVARIANTS, malloc debugging flags in userland, and various verbose features in the kernel. Many developers choose to disable these features on build machines to maximize performance. Could someone please nuke this? It is a problem with cvsweb - see http://www.freebsd.org/cgi/query-pr.cgi?pr=120185 Henri Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: segmentation faults on RELENG_6
Andreas Killaitis wrote: Hi list, I have some problems with one of my FreeBSD installations. I am not shure if this the correct list, but I hope so. The scenario: I am running three virtual machines (VMware Fusion 1.1 on a Mac Pro). All of them use exactly the same hardware playground. Each of the machines is running with a different FreeBSD installation: RELENG_5, RELENG_6 and RELENG_7. There is another virtual machine with 8-CURRENT with a slightly different setup, but all of the VMs are using two virtual processors, 512 MB RAM and a 100 GB harddisk. The RELENG_5, RELENG_7 and the CURRENT machine are working like a charm, but the RELENG_6 maching is causing trouble. Sometimes some sort of processes abort with a segmentation fault: Mar 15 23:49:30 beastie6 kernel: pid 77039 (sed), uid 0: exited on signal 11 (core dumped) Mar 16 00:12:47 beastie6 kernel: pid 35211 (conftest), uid 0: exited on signal 12 (core dumped) Mar 16 00:15:50 beastie6 kernel: pid 61400 (tr), uid 0: exited on signal 11 (core dumped) Mar 16 01:37:13 beastie6 kernel: pid 62336 (cc1), uid 0: exited on signal 11 (core dumped) Mar 16 01:51:06 beastie6 kernel: pid 41313 (sed), uid 0: exited on signal 11 (core dumped) Mar 16 02:03:10 beastie6 kernel: pid 3826 (cc1plus), uid 0: exited on signal 11 (core dumped) Mar 16 09:40:33 beastie6 kernel: pid 6094 (sed), uid 0: exited on signal 11 (core dumped) Mar 16 11:19:56 beastie6 kernel: pid 94667 (xargs), uid 0: exited on signal 11 (core dumped) Mar 16 11:20:12 beastie6 kernel: pid 97386 (sed), uid 0: exited on signal 11 (core dumped) Mar 16 11:27:49 beastie6 kernel: pid 22796 (pkg_info), uid 0: exited on signal 11 (core dumped) Mar 16 11:48:09 beastie6 kernel: pid 97969 (cat), uid 0: exited on signal 11 (core dumped) Mar 16 12:05:44 beastie6 kernel: pid 16624 (bdftopcf), uid 0: exited on signal 11 (core dumped) Mar 16 13:15:04 beastie6 kernel: pid 49750 (sed), uid 0: exited on signal 11 (core dumped) All those segmentatiopn faults occurred building some ports. None of my FreeBSD boxes uses special CFLAG settings for buildworld or ports, they just use the default settings, with the exception of CPUTYPE?=pentiumpro Initially I tried CPUTYPE?=prescott, reverting it to pentium4, pentium3 and now even to pentiumpro, but even pentiumpro doesn't solve the problem. The whone world is built using those very conservative settings. My last idea is to remove even this last "tuning" parameter CPUTYPE, but I dislike this, for it would mean to run a plain 386 box. :-( Any ideas? btw: the kernel is build using the SMP flag as the only modification. The SCHED_4BSD is used. The source tree is RELENG_6 from yesterday. I'm having some problems with sh segfaulting on one machine, but the hardware is so different from yours that this idea may be irrelevant to your situation: Starting on 2006/08/27 RELENG_6 updated gcc from 3.4.4 to 3.4.6, and I have a hunch that my problem may be related to that. Unfortunately, my old machine is so slow it takes 3 days to build world/kernel -- and it's my firewall, too, so I haven't tried both compilers yet. Sounds like your machine is a wee bit faster, so maybe you could try checking out sources for RELENG_6 -D2006/08/26 and try a couple of world/kernel cycles and see if it helps? I'd be interested to see. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RELENG_7 /src/UPDATING out od date?
Hey, http://www.freebsd.org/cgi/cvsweb.cgi/src/UPDATING?rev=1.507;only_with_tag=RELENG_7 NOTE TO PEOPLE WHO THINK THAT FreeBSD 7.x IS SLOW: FreeBSD 7.x has many debugging features turned on, in both the kernel and userland. These features attempt to detect incorrect use of system primitives, and encourage loud failure through extra sanity checking and fail stop semantics. They also substantially impact system performance. If you want to do performance measurement, benchmarking, and optimization, you'll want to turn them off. This includes various WITNESS- related kernel options, INVARIANTS, malloc debugging flags in userland, and various verbose features in the kernel. Many developers choose to disable these features on build machines to maximize performance. Could someone please nuke this? Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
segmentation faults on RELENG_6
Hi list, I have some problems with one of my FreeBSD installations. I am not shure if this the correct list, but I hope so. The scenario: I am running three virtual machines (VMware Fusion 1.1 on a Mac Pro). All of them use exactly the same hardware playground. Each of the machines is running with a different FreeBSD installation: RELENG_5, RELENG_6 and RELENG_7. There is another virtual machine with 8-CURRENT with a slightly different setup, but all of the VMs are using two virtual processors, 512 MB RAM and a 100 GB harddisk. The RELENG_5, RELENG_7 and the CURRENT machine are working like a charm, but the RELENG_6 maching is causing trouble. Sometimes some sort of processes abort with a segmentation fault: Mar 15 23:49:30 beastie6 kernel: pid 77039 (sed), uid 0: exited on signal 11 (core dumped) Mar 16 00:12:47 beastie6 kernel: pid 35211 (conftest), uid 0: exited on signal 12 (core dumped) Mar 16 00:15:50 beastie6 kernel: pid 61400 (tr), uid 0: exited on signal 11 (core dumped) Mar 16 01:37:13 beastie6 kernel: pid 62336 (cc1), uid 0: exited on signal 11 (core dumped) Mar 16 01:51:06 beastie6 kernel: pid 41313 (sed), uid 0: exited on signal 11 (core dumped) Mar 16 02:03:10 beastie6 kernel: pid 3826 (cc1plus), uid 0: exited on signal 11 (core dumped) Mar 16 09:40:33 beastie6 kernel: pid 6094 (sed), uid 0: exited on signal 11 (core dumped) Mar 16 11:19:56 beastie6 kernel: pid 94667 (xargs), uid 0: exited on signal 11 (core dumped) Mar 16 11:20:12 beastie6 kernel: pid 97386 (sed), uid 0: exited on signal 11 (core dumped) Mar 16 11:27:49 beastie6 kernel: pid 22796 (pkg_info), uid 0: exited on signal 11 (core dumped) Mar 16 11:48:09 beastie6 kernel: pid 97969 (cat), uid 0: exited on signal 11 (core dumped) Mar 16 12:05:44 beastie6 kernel: pid 16624 (bdftopcf), uid 0: exited on signal 11 (core dumped) Mar 16 13:15:04 beastie6 kernel: pid 49750 (sed), uid 0: exited on signal 11 (core dumped) All those segmentatiopn faults occurred building some ports. None of my FreeBSD boxes uses special CFLAG settings for buildworld or ports, they just use the default settings, with the exception of CPUTYPE?=pentiumpro Initially I tried CPUTYPE?=prescott, reverting it to pentium4, pentium3 and now even to pentiumpro, but even pentiumpro doesn't solve the problem. The whone world is built using those very conservative settings. My last idea is to remove even this last "tuning" parameter CPUTYPE, but I dislike this, for it would mean to run a plain 386 box. :-( Any ideas? btw: the kernel is build using the SMP flag as the only modification. The SCHED_4BSD is used. The source tree is RELENG_6 from yesterday. Regards, Andreas Killaitis ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HP ProLiant DL360 G5 success stories?
On Thu, Mar 13, 2008 at 12:24:27AM +0100, Johan Str?m wrote: > On Mar 12, 2008, at 11:37 PM, Joe Koberg wrote: > > >The iLO is a completely separate management processor with its own > >network port. It runs its own OS and has its own IP address. It runs > >an SSL webserver for access. The iLO is accessible over the network > >any time the machine is plugged into power. I am not sure about > >IPMI access to it. > > Okay, kind of what I "expected" (havent read up very much on it yet). > > > > > > >The "normal" iLO option will give you exact textual console screen > >output and keyboard control from the moment of power-on. It will > >also let you toggle power and hit the reset button. I believe it > >uses a java applet in the browser. > > > >The "advanced" iLO option, which is license-key-unlocked, also > >provides graphical remote console, and virtual media. You can upload > >a CD or floppy image and then boot the server from it. I suspect > >the compatibility issue appears here - the virtual media probably > >emulates USB mass storage, and the OS must be able to boot from it. > > I see... So for a box that is going to run fbsd in console mode, and > hopefully never need to boot from CD after install, it sounds like the > normal mode will work splendid. > > But.. > http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf > > seems to tell me that in basic mode I can only access BIOS (pre-OS) using > the Remote Console feature, and that after POST I have to have the > advanced licensed option? > > "iLO 2 displays this information through the remote console applet > while in the server pre-operating system > state, enabling a non-licensed iLO 2 to observe and interact with the > server during POST activities. A non- > licensed iLO 2 cannot use remote console access after the server > completes POST and begins to load the > operating system. The iLO 2 Advanced License enables access to the > remote console at all times." > > So.. Then what? I have to configure FreeBSD to use a serial console > and continue with using serial console instead? Later in the same doc: > > ? iLO 2 Standard (unlicensed:) > NOTE: The features annotated with an asterisk (*) are not supported > on all systems. > > o Virtual Power and Reset control > o Remote serial console through POST only > ... > o Serial access* > > > Am i missing something here or will I only be able to access the > console during post, unless i configure the box to use a serial > console? Hope you can shed some light here :) > > > > > > >It has full reporting of hardware state and management log details, > >and the "home page" is a big summary with any faults outlined in red. > > Yes, that was what I expected. But can i retreive the data some other > way? IPMI, SNMP or something? Would like to gather the stats to a > central management site. Further investigation in the manual seems to > indicate that no SNMP access is available, but there is some XML > "RIBCL" interface I can use (yes this is in standard mode too :)) > > Thank you! iLO also allows you to access a virtual serial line, which can be connected to via ssh. We are running about 200 HP servers (mostly Linsux unfortunatly) but we use the serial console on some specific servers where kernel modules could fence the box and if that happens nothing will be still written to the syslog (local or remote). So we use serial console and conserver to log such things. -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HP ProLiant DL360 G5 success stories?
On Thu, Mar 13, 2008 at 12:41:53AM +0100, Johan Str?m wrote: > On Mar 13, 2008, at 12:40 AM, Joe Koberg wrote: > > >Johan Str?m wrote: > >>But.. > >>http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf > >> > >> seems to tell me that in basic mode I can only access BIOS (pre- OS) > >>using the Remote Console feature, and that after POST I have to have the > >>advanced licensed option? > >> > > > >I don't do the purchasing and we get all Advanced iLO, so I will > >take your word for it. The older generations supported text console > >(i have a 360G2 that does so). We use the HP Management agents > >under Windows for all SNMP reporting so I can't comment on the > >reporting method under other OS's. > > > > I see. Can anyone else maybe shed some light here? > iLO can send SNMP alerts when hardware issues come up, such as power supply failure, memory, fan, etc. The CISS driver will also alert in syslog/console about problems with drives. -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HP ProLiant DL360 G5 success stories?
On Wed, Mar 12, 2008 at 06:40:49PM -0500, Joe Koberg wrote: > Johan Str?m wrote: > >But.. > >http://bizsupport.austin.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf > > seems > >to tell me that in basic mode I can only access BIOS (pre-OS) using the > >Remote Console feature, and that after POST I have to have the advanced > >licensed option? > > > > I don't do the purchasing and we get all Advanced iLO, so I will take > your word for it. The older generations supported text console (i have > a 360G2 that does so). We use the HP Management agents under Windows > for all SNMP reporting so I can't comment on the reporting method under > other OS's. iLO2 ActiveX based remote console (Integrated KVM) can still do text only console without license but it doesn't work too well IMHO. The Java based console is the same, text will work out license but graphics mode and that includes certain VESA text modes. Standard iLO gives the graphical console and virtual media. On Blade servers the graphical access and virtual media is included. And the Advanced license gives extra stuff like integration into AD for authentication afik. I have been running, at least until I had to roll out Linsux, FreeBSD on all our HP and haven't had issues. Our servers include: DL360 g3, g4, g4p, g5 DL380 g3, g4, g5 BL460c g1 BL480c g1 Latest edition: CPU: Intel(R) Xeon(R) CPUE5450 @ 3.00GHz (3000.12-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd> AMD Features=0x2800 AMD Features2=0x1 Cores per package: 4 usable memory = 34345119744 (32754 MB) avail memory = 33302040576 (31759 MB) Too bad it will run EL4 x86_64. -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
