Re: Policy on static linking ?
On 1/15/2011 5:11 AM, Jean-Yves Avenard wrote: > If I compile openldap-client against openssl from ports, then it > creates massive problems elsewhere. [snip problems] > I dislike this method, because should openldap gets upgraded again and > be linked against openssl port, I will lock myself out of the machine > again due to sshd crashing. Just like what happened today :( Problems like that are why I do my package compiling in a jail, or a VM, and not on a live system. Jails are simple to setup these days and it's handy to be able to just blow away the jail and recreate it if things go wonky with dependencies when experimenting with package builds. (Or snapshot a VM before trying) I've taken a stab or two at compiling ports static in the past and also came up empty. It would be really nice to be able to build a single tbz package that would run once installed and that didn't have to pull down every other dependency individually. There are a number of ways that dependency tracking with packages can go sideways, and it isn't fun when trying to ensure that said packages install OK when transplanting them to other machines... Jim ___ 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: IPv6 and CARP crashes boxes
On 5/31/2012 5:31 PM, Damien Fleuriot wrote: > On 31 May 2012, at 22:31, Adrian Chadd wrote: >> On 31 May 2012 06:42, Damien Fleuriot wrote: >>> Hey list, >>> >>> The thread about "Why Are You Using FreeBSD", listing the pros and cons >>> of FBSD, has brought back a topic to mind. >>> >>> Recently (read, < 3 months ago) I was experimenting with IPv6 and CARP >>> on 8.x boxes and that crashed them both. >>> >>> I posted a thread on -net and, sadly, never got a single reply. >> >> Did you file a PR? Chances are bz (IPv6 maintainer) has just been very busy. >> :-) >> > > I was actually trying to get some feedback on -net and see if anyone had > encountered the problem before filling a PR. > > I guess I'll reproduce the problem, fill a PR, then post here so we can > discuss it and make things move forward. We (pfSense) patch things here and there, especially when it comes to CARP, but we haven't seen any crashes with CARP+IPv6 on pfSense 2.1-DEVELOPMENT (now BETA0) since we moved to a base OS of FreeBSD 8.3-RELEASE. It was fairly trivial to crash/hang 8.1 with v6 in general even without CARP. There are several CARP+IPv6 clusters running pfSense 2.1 in the wild handling production traffic like champs.[1] You might have a look at this IPv6 status sheet we try to keep updated: https://docs.google.com/spreadsheet/ccc?key=0AojFUXcbH0ROdHlKV2F5SENULWk2NTVvQTBtQ2M0dEE Our patches might also be of interest: https://github.com/bsdperimeter/pfsense-tools/blob/master/builder_scripts/patches.RELENG_8_3 https://github.com/bsdperimeter/pfsense-tools/tree/master/patches/RELENG_8_3 Jim [1] With a static setup, some work is still happening to make CARP RA work for automatic configuration. ___ 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: Freebsd 8.1 + xorg + radeonhd hang
On 9/16/2010 12:20 PM, Eivind E wrote: > On Wed, 15 Sep 2010, Warren Block wrote: > >> On Wed, 15 Sep 2010, Eivind E wrote: >>> (WW) RADEONHD(0): !!! Option HPD is set !!! >>> This shall only be used to work around broken connector tables. >>> Please report your findings to radeo...@opensuse.org >> >> radeon doesn't have this option at all. >>> (II) RADEONHD(0): Output VGA_1 using monitor section Skjerm >> >> Odd. Later on on it looks like it's using DVI-I_1/analog. See my >> xorg.conf for an example of tying monitors to specific outputs in the >> Device section. > > I tried your configuration file so both of these should be fine, > however, I'm not quite sure what's correct for the Monitor-DVI-X > when using the adaptor to vga which came with the card. The monitor > is an old crt one. Not meaning to resurrect a month-old thread but I'm a bit behind on my list mail. I just thought I'd pass long that I had problems in the past with my older Radeon when using a VGA to DVI connector. Using either a normal VGA port, or a DVI cable on the DVI port worked fine. http://lists.freebsd.org/pipermail/freebsd-x11/2007-September/005251.html Jim ___ 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: FreeBSD 7.1 Content
Wesley Shields wrote: > On Wed, Sep 03, 2008 at 06:28:44PM -0600, Dan Allen wrote: >> Hey, these great comments bring up a different solution, which may be >> the way to go. >> >> It is simple: have a few of the common apps that are net-centric (like >> firefox) be simply calls to pkg_add -r in the installer. No ports >> databases, no packages on the discs. A few packages may be useful >> (like perl) to someone without net access, but many need the net to be >> useful. > > No thanks. This means you have to have a working connection to install > firefox via this method. Since not everyone will have that it is still > necessary to bundle the firefox package on the media, bringing us right > back to the very issue you are trying to solve. Could this not also be resolved another way? Most desktops these days have DVD drives. If someone wants a bootable desktop-targeted release with X, Firefox and such, why not make that a DVD instead of trying to shoehorn all of this into a CD? Most of the older machines with aging CD-ROM drives or without a DVD drive may not have the horsepower to run a live CD with X anyhow. My servers only have CD-ROM drives, but then again they wouldn't be using a desktop-oriented live CD with X either. :-) Sure, the download would be (much?) larger, but you would have a lot more room to work with. The CD installs are great for me, and have worked well for years. Personally, I install, update to -STABLE from a local cvsup mirror, then use an updated ports tree or install packages remotely. The packages on CD are out of date practically from the moment they are placed there, so I rarely use them. The only package I regularly used was cvsup-without-gui, which has been replaced by csup in the base system. Also, is not Ubuntu a "downstream" release of Debian, much like FreeSBIE and PC-BSD are "downstream" of FreeBSD? If you want to compare apples to apples, you might investigate those choices a little closer. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.1 Content
Dan Allen wrote: > On 4 Sep 2008, at 8:22 AM, Jim Pingle wrote: > Okay, so how about for packages on the base CD: > > * cvsup-without-gui (I also always use this) > * rsync > * perl As others have mentioned, there are plenty of uses for packages, even if I do not use them "out of the box" there are lots of people who do so, and need them because their networks are completely isolated, or the computers will not be networked and do not have an urgent need for security updates or the latest & greatest versions. > Then, since packages are always out-of-date, why not just skip the DVD > and use the internet with a couple of check boxes at the end of the > install, the way ports is treated now, that are just calls to pkg_add -r > for: > > * KDE > * GNOME > * Firefox > * ... whatever else are the most popular add-ons > > Fewer bits to be delivered via CD/DVD, and things are always up-to-date. My memory may be failing me, but there used to be a port called "instant workstaion" that accomplished quite a bit, and the installer would drop in X but asked for KDE or Gnome, but I don't recall when those choices went away. It appears the workstation port went away because it was broken and had no maintainer[1]. I have no idea what it might take to gather support for someone to resurrect the port and keep it updated. I would not mind having such an option again for desktops, but I would use it very rarely (only two, maybe three of my FreeBSD systems see desktop-type use). >> Also, is not Ubuntu a "downstream" release of Debian, much like >> FreeSBIE and >> PC-BSD are "downstream" of FreeBSD? If you want to compare apples to >> apples, >> you might investigate those choices a little closer. > > Touche. I had forgotten this. Perhaps this is why I was able to crash > Ubuntu so quickly yesterday... ;-) Perhaps. I use Ubuntu on a couple systems and it is pretty solid. I used it mainly because it was easy to turn on the eye candy bits in X to show people what other OS choices are out there. (Average Joes are really impressed with the wobbly windows and the way the cube switches multiple desktops) > I hope everyone realizes that I am not trying to "de-server" FreeBSD. I > just remember how daunting it was for me to get X setup when all I > wanted to use was a web browser when I was new to it all. Really? It's been easy for me lately, but I don't run on new hardware very often. On older systems it's been a matter of installing the packages/ports and running startx. The hard part was waiting for all the packages to install. I have had a few systems where I needed to tweak Xorg's config, but not too much. In my experience, it runs much better these days with default choices than it did in years past. I know others have had just the opposite experience, so apparently there is still work to be done. > The early BSD releases had a simple check box to add X support and it > all just worked. That was COOL. That is what I am hoping to get back > into BSD. See above, re: instant workstation port. I don't know if it was the same in the installer or not, but I seem to recall it having a similar effect. I also thought I remembered FreeBSD themes for KDE and Gnome that were used by default. There is a beasie theme for Gnome (x11-themes/beastie) but I have not used it so I don't know what it looks like. > I do not want to spill onto DVDs, remove the sources, get rid of command > prompts, or force systems to have X.org on them... I don't think spilling onto a DVD is a bad thing, as a choice. Then again, even Ubuntu has separate install CDs for desktop and server. You might want to talk to the developer of finstall[2], it might be in line with what you are envisioning. Jim 1: http://lists.freebsd.org/pipermail/freebsd-questions/2008-April/173383.html 2: http://wiki.freebsd.org/finstall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: system hangup - I'm lost
Jeremy Chadwick wrote: > P.S. -- You're the 2nd person I've encountered in under a week who's > using 440BX/GX-based hardware in present day. I would not be > surprised if the board is simply going bad/failing due to age. :-) I still have quite a few of these in active use. They are good workhorses. Sure, they don't have the raw computing power of newer servers, but for most of our tasks they get the job done. I also have a couple stacks of these in 2U cases sitting unused for spare parts and testing. They make great FreeBSD boxes, and handle low-moderate loads pretty well. We use them for all kinds of things: firewalls, personal/testing servers, SVN repos, monitoring and traffic graphing, name servers, you name it. To bring this back on topic, they might be old, but I have yet to encounter one single motherboard from that series that has failed on me in any way. (*knock on wood*) However, mine are all Intel L440GX boards with dual PIII CPUs in the 600-800MHz range. We try to squeeze every last bit of value out of the hardware we have. :-) Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible regression in ifconfig under7.0 - removes validdefault route
Jeremy Chadwick wrote: > Summary: confirmed. Above two tests show that even if changing the IP > to something else within the same network block, the default route is > removed and not put back. > > This is pretty major, if you ask me. I've encountered similar issues before, and typically just added "; /etc/rc.d/routing restart" or "&& /etc/rc.d/routing restart" after the ifconfig statement just to be safe. Typically I had adjusted rc.conf, then used "/etc/rc.d/netif restart; /etc/rc.d/routing restart" Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: System borked: loader stack overflow.
Andrew Thompson wrote: > Also an entry in UPDATING that a config error that was once harmless now > renders the system unbootable (without intervention). Would this also be something that mergemaster could check for and warn against? Jim ___ 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: 8.0-rc2 dropped hardsupport
Marten Vijn wrote: > Support for the following devices seems not to be continued in 8.0 (and > 7.2 and higher): > > - WRAP 1C > - WRAP 2E (EOL) > - ALIX 1C > > Both devices stopped booting as described in several postings and pr's. > > My question/suggestion to announce this in the >> 7.2 and 8.0 release notes. (or better to fix the issues) Sorry for the late reply, but I may have a lead on some of these issues. NanoBSD is used for the embedded versions of pfSense now, and so we've had a lot of users of ALIX/WRAP/etc giving it a workout. Take a look at some of the articles I've written so far based on information myself and others have collected. http://doc.pfsense.org/index.php/NanoBSD_on_WRAP http://doc.pfsense.org/index.php/ALIX_BIOS_Update_Procedure http://doc.pfsense.org/index.php/Boot_Troubleshooting (First few items) It seems on the ALIX boards with VGA, you need to set a BIOS option for power management to APM, which gets it past the freeze at devd. Also, we've been running kernels with the geode.c rev 1.11 mentioned elsewhere in this thread for months patched against 7.2-RELEASE and it works great for most ALIX models, but according to our users it does not seem to offer any additional support for the models with a VGA BIOS (LEDs and such still are not usable). Apparently they use an Award BIOS and not TinyBIOS. Hope this helps, Jim ___ 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: PCengines ALIX boot0sio serial input failes
On 12/9/2009 11:13 AM, Daniel Braniss wrote: > hi, > FreeBSD-8 works great on these boards, but there are some > gotchas, the boot and the serial: output works fine, but input > is 'problematic'. the pxeboot serial handling is ok, the boot menu > is ok, but booting off the CF (using boot0sio), the input 'screwy' > at the selection of partition it is ignored, at the OK: prompt > from the boot (i had no kernel in the slice), the input is usually > doubled: > sshooww instead of show > which is probably similar to what is happening with boot0sio but it > only echoes # (the current bell). > > Once the kernel is up, the serial works fine. The development version of pfSense (2.0) is running on FreeBSD 8.0 using NanoBSD and its serial input/output works pretty well on ALIX, the 2d3.2d13 version at least (and others, but those are the only two I have used personally). My test ALIX is at home unplugged at the moment, but based on what I see in the image file there are a few things that were done: /boot/device.hints contains: hint.uart.0.at="isa" hint.uart.0.port="0x3F8" hint.uart.0.flags="0x10" hint.uart.0.irq="4" /boot.config contains: -h The initial boot0cfg on an image is done with: boot0cfg -B -b /path/to/boot/boot0sio -o packet -s 1 -m 3 Here is what shows up when I mount an md device from a CF image: # boot0cfg -v /dev/md0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5444: 15:63 63 448497 2 0x00445: 1: 1 0xa5889: 15:63 448623 448497 3 0x00890: 0: 1 0xa5991: 15:63 897120 102816 version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID 9090-9090 default_selection=F1 (Slice 1) Seems to work pretty well there. If you want the details, you can check out the pfSense tools git repository which contains the build scripts that generate the images. Jim ___ 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: PCengines ALIX boot0sio serial input failes
On 12/10/2009 2:32 AM, Daniel Braniss wrote: >> Which ALIX board exactly? There are some differences (even various BIOSes). >> Any chance you have vga driver in kernel? TinyBIOS emulates VGA a bit, >> redirects output to serial port. If at the beginning you are trying both VGA >> and serial port, output is doubled. Similar behavior is observed on older >> WRAP boards, too. > > I have tried ALIX-1 and 2 > here is an example: > > PC Engines ALIX.3 v0.99h > 640 KB Base Memory > 261120 KB Extended Memory > Waiting for HDD ... > > 01F0 Master 848A SanDisk SDCFH2-002G > Phys C/H/S 3970/16/63 Log C/H/S 992/64/63 > > 1 FreeBSD > 2 FreeBSD > 3 FreeBSD > > 6 PXE > Boot: 1 > > any key I hit, it echoes as # and is ignored. > at this point the kernel is not yet involved, so having vga+kb support > is not the reason, though I will try out the alix-3, which has vga support, > and > a different BIOS soon. A lot of users have seen that happen, but typically it has been cleared up by using ALIX BIOS v0.99h, which that box already appears to have, and setting the BIOS for CHS mode. I haven't tried any of the ALIX models with VGA, but I have heard they are working as long as you set the BIOS for APM power management. (See the previous -STABLE thread titled "8.0-rc2 dropped hardsupport". Jim ___ 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: PCengines ALIX boot0sio serial input failes
On 12/10/2009 2:28 AM, Daniel Braniss wrote: >> On 12/9/2009 11:13 AM, Daniel Braniss wrote: >>> hi, >>> FreeBSD-8 works great on these boards, but there are some >>> gotchas, the boot and the serial: output works fine, but input >>> is 'problematic'. the pxeboot serial handling is ok, the boot menu >>> is ok, but booting off the CF (using boot0sio), the input 'screwy' >>> at the selection of partition it is ignored, at the OK: prompt >>> from the boot (i had no kernel in the slice), the input is usually >>> doubled: >>> sshooww instead of show >>> which is probably similar to what is happening with boot0sio but it >>> only echoes # (the current bell). >>> >>> Once the kernel is up, the serial works fine. >> >> The development version of pfSense (2.0) is running on FreeBSD 8.0 using >> NanoBSD and its serial input/output works pretty well on ALIX, the >> 2d3.2d13 version at least (and others, but those are the only two I have >> used personally). >> >> My test ALIX is at home unplugged at the moment, but based on what I see >> in the image file there are a few things that were done: >> >> /boot/device.hints contains: >> hint.uart.0.at="isa" >> hint.uart.0.port="0x3F8" >> hint.uart.0.flags="0x10" >> hint.uart.0.irq="4" >> >> /boot.config contains: >> -h >> >> The initial boot0cfg on an image is done with: >> boot0cfg -B -b /path/to/boot/boot0sio -o packet -s 1 -m 3 >> >> Here is what shows up when I mount an md device from a CF image: >> # boot0cfg -v /dev/md0 >> # flag start chs type end chs offset size >> 1 0x80 0: 1: 1 0xa5444: 15:63 63 448497 >> 2 0x00445: 1: 1 0xa5889: 15:63 448623 448497 >> 3 0x00890: 0: 1 0xa5991: 15:63 897120 102816 >> >> version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) >> options=packet,update,nosetdrv >> volume serial ID 9090-9090 >> default_selection=F1 (Slice 1) >> >> Seems to work pretty well there. If you want the details, you can check >> out the pfSense tools git repository which contains the build scripts >> that generate the images. > > I have the same /boot/device.hints. > can you confirm that > 1) when booting from CF, the boot0sio accepts input > 2) the /boot/boot accepts input from the serial? I can give serial input at any stage of booting, from the 1/2 boot slice choice, the loader (I can get an OK prompt), etc. I overlooked the "#" character you were getting when replying to this message before, that typically means it cannot read the partition for some reason, not that it isn't accepting input. If this were a WRAP I'd say it might also be packet vs nopacket mode when booting, but every ALIX I've had my hands on will boot pfSense images with packet mode on the most current BIOS (0.99h). You might try using a pfSense 2.0/FreeBSD 8 snapshot on a CF to see if it exhibits the same behavior as your CF image. They should be available from http://snapshots.pfsense.org/ There are also images for pfSense 1.2.3/FreeBSD 7.2 available on the normal download mirrors from http://pfsense.org if you want to try those out. Just grab an image sized for your CF (or smaller). Jim ___ 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: FreeBSD-8.0 802.11n support with ath/mwl
On 2/27/2010 9:09 PM, Rui Paulo wrote: > On 27 Feb 2010, at 20:29, Robert Watson wrote: > Progress on supporting 11n with atheros cards is on going. There's much more > to it than adapting the rate control algorithm. Please stay tuned. Are you aware if similar work ongoing for the mwl(4) based 802.11n cards? I picked up a couple cheap this past week and have them working with hostapd but, as with the OP in the thread, only with G rates. The ifconfig[1] output suggests that it is using 40MHz wide ht channels but devices only associate at 54Mbps[2]. Jim [1] ifconfig mwl0_wlan1 mwl0_wlan1: flags=8843 metric 0 mtu 1500 ether 00:01:36:17:96:0e inet6 fe80::201:36ff:fe17:960e%mwl0_wlan1 prefixlen 64 scopeid 0x9 inet 192.168.15.1 netmask 0xff00 broadcast 192.168.15.255 nd6 options=3 media: IEEE 802.11 Wireless Ethernet autoselect mode 11na status: running ssid WatchTower channel 100 (5500 MHz 11a ht/40+) bssid 00:01:36:17:96:0e regdomain DEBUG indoor authmode WPA2/802.11i privacy MIXED deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 14 scanvalid 60 ampdulimit 64k ampdudensity 4 shortgi smps burst dtimperiod 1 [2] ifconfig mwl0_wlan1 list sta (w/addr removed) AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 1 120 54M 33.00 1537 25952 EP A RSN (rssi 68:20:20 nf 0:0:0) ___ 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: FreeBSD-8.0 802.11n support with ath/mwl
On 2/28/2010 7:54 AM, Rui Paulo wrote: > On 28 Feb 2010, at 03:22, Jim Pingle wrote: >> >> Are you aware if similar work ongoing for the mwl(4) based 802.11n >> cards? I picked up a couple cheap this past week and have them working >> with hostapd but, as with the OP in the thread, only with G rates. >> >> The ifconfig[1] output suggests that it is using 40MHz wide ht channels >> but devices only associate at 54Mbps[2]. >> >> Jim >> >> [1] ifconfig mwl0_wlan1 >> mwl0_wlan1: flags=8843 metric 0 >> mtu 1500 >> ether 00:01:36:17:96:0e >> inet6 fe80::201:36ff:fe17:960e%mwl0_wlan1 prefixlen 64 scopeid 0x9 >> inet 192.168.15.1 netmask 0xff00 broadcast 192.168.15.255 >> nd6 options=3 >> media: IEEE 802.11 Wireless Ethernet autoselect mode 11na >> status: running >> ssid WatchTower channel 100 (5500 MHz 11a ht/40+) bssid 00:01:36:17:96:0e >> regdomain DEBUG indoor authmode WPA2/802.11i privacy MIXED deftxkey 3 >> AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 14 scanvalid 60 >> ampdulimit 64k ampdudensity 4 shortgi smps burst dtimperiod 1 >> >> >> [2] ifconfig mwl0_wlan1 list sta (w/addr removed) >> AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG >> 1 120 54M 33.00 1537 25952 EP A RSN (rssi 68:20:20 nf >> 0:0:0) > > mwl supports HT rates, but it looks like your AP is not sending HT rates to > you. Thanks for the quick clarification, that's very encouraging to find out! In this case, the mwl card is the AP. The client line is from an associated Windows 7 laptop with an Intel 5100abgn card which does show the AP as 802.11n in the AP list. I'm connected and sending this message through it right now, actually. Are there some other bits that need set in order to have clients associate with HT rates? Or some other prerequisite conditions such as number of attached antennae? I do only have one antenna attached as I didn't have a second pigtail for this test unit's case. The card actually has three connectors. I didn't see hints in the mwl(4), wlan(4), hostapd(8), hostapd.conf(5), or ifconfig(8) man pages about troubleshooting rates. I see plenty of talk in ifconfig(8) about use and control of HT rates, but given what I'm seeing in ifconfig, it should be set to use them. I've tried several combinations of channels and standards (e.g. 11ng, 11na) but always end up with a 54Mbps link. I'd appreciate any more pointers that you (or anyone else reading) may have. I'd like to write up something on the topic once I get it fully operational. Thanks, Jim ___ 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: FreeBSD-8.0 802.11n support with ath/mwl
On 2/28/2010 2:29 PM, Bernhard Schmidt wrote: > On Sun, Feb 28, 2010 at 12:38:19PM -0500, Jim Pingle wrote: [snip] >> In this case, the mwl card is the AP. The client line is from an >> associated Windows 7 laptop with an Intel 5100abgn card which does show >> the AP as 802.11n in the AP list. I'm connected and sending this message >> through it right now, actually. >> >> Are there some other bits that need set in order to have clients >> associate with HT rates? Or some other prerequisite conditions such as >> number of attached antennae? I do only have one antenna attached as I >> didn't have a second pigtail for this test unit's case. The card >> actually has three connectors. >> >> I didn't see hints in the mwl(4), wlan(4), hostapd(8), hostapd.conf(5), >> or ifconfig(8) man pages about troubleshooting rates. I see plenty of >> talk in ifconfig(8) about use and control of HT rates, but given what >> I'm seeing in ifconfig, it should be set to use them. I've tried several >> combinations of channels and standards (e.g. 11ng, 11na) but always end >> up with a 54Mbps link. >> >> I'd appreciate any more pointers that you (or anyone else reading) may >> have. I'd like to write up something on the topic once I get it fully >> operational. > > Did you measure the actual bandwidth you get? Changes are high that you > are actually using HT rates, the rate information is just no accurate. I did some tests and the throughput was quite slow. Enough to make me wonder about the antenna situation again. I'll have to dig up more pigtails and try again. Thanks for the idea. Jim ___ 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: FreeBSD-8.0 802.11n support with ath/mwl
On 2/28/2010 7:03 PM, Rui Paulo wrote: > On 28 Feb 2010, at 17:38, Jim Pingle wrote: >> Are there some other bits that need set in order to have clients >> associate with HT rates? Or some other prerequisite conditions such as >> number of attached antennae? I do only have one antenna attached as I >> didn't have a second pigtail for this test unit's case. The card >> actually has three connectors. > > Having only 1 antenna connected will likely impact your connection. I'll hook up two more and try again when I get a chance, I just need to pull them from a working unit that isn't using its wifi currently. >> I didn't see hints in the mwl(4), wlan(4), hostapd(8), hostapd.conf(5), >> or ifconfig(8) man pages about troubleshooting rates. I see plenty of >> talk in ifconfig(8) about use and control of HT rates, but given what >> I'm seeing in ifconfig, it should be set to use them. I've tried several >> combinations of channels and standards (e.g. 11ng, 11na) but always end >> up with a 54Mbps link. >> >> I'd appreciate any more pointers that you (or anyone else reading) may >> have. I'd like to write up something on the topic once I get it fully >> operational. > > I don't know what's happening, but I guess your Windows 7 laptop isn't > sending the necessary HT rates in the association. Try using wlandebug to see > what's happening. Ah, I wasn't aware of wlandebug(8). However, it doesn't seem to operate on this mwl(4) card. It sets the value of the sysctl net.wlan.0.debug and that doesn't show up on my system. Another system with a ral(4) card does have that sysctl. Judging by the information in the wlandebug(8) man page it appears as though this may be a side effect of mwl doing much of the work in firmware. I appreciate the information though, thanks for taking the time to reply. I'll continue to work on this again once I relocate some pigtails from another box. Jim ___ 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: FreeBSD-8.0 802.11n support with ath/mwl
On 2/28/2010 9:41 PM, Rui Paulo wrote: > On 1 Mar 2010, at 02:26, Jim Pingle wrote: >> Ah, I wasn't aware of wlandebug(8). However, it doesn't seem to operate >> on this mwl(4) card. It sets the value of the sysctl net.wlan.0.debug >> and that doesn't show up on my system. Another system with a ral(4) card >> does have that sysctl. Judging by the information in the wlandebug(8) >> man page it appears as though this may be a side effect of mwl doing >> much of the work in firmware. > > wlandebug takes an -i argument. I seem to recall you created your wlan > interface named "mwl_wlan0", so you need to type wlandebug -i mwl_wlan0. I saw that, but that is hardcoded to expect wlan (wlan0, wlan1, etc) for an interface name. Having seen that, I recompiled wlandebug without the hardcoded interface name check and it didn't work either, but it did toss an error for the sysctl it was trying to tweak. That made me look deeper at the code and see it was really just setting the debug sysctl based on flags that wlandebug was aware of. Handy, but the same thing could be done by hand with sysctl and some bitwise math in a pinch, assuming the interface has the right oids. (Which mine doesn't, for some reason...) Jim ___ 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: FreeBSD-8.0 802.11n support with ath/mwl
On 2/28/2010 10:16 PM, Rui Paulo wrote: > On 1 Mar 2010, at 03:05, Jim Pingle wrote: > >> On 2/28/2010 9:41 PM, Rui Paulo wrote: >>> On 1 Mar 2010, at 02:26, Jim Pingle wrote: >>>> Ah, I wasn't aware of wlandebug(8). However, it doesn't seem to operate >>>> on this mwl(4) card. It sets the value of the sysctl net.wlan.0.debug >>>> and that doesn't show up on my system. Another system with a ral(4) card >>>> does have that sysctl. Judging by the information in the wlandebug(8) >>>> man page it appears as though this may be a side effect of mwl doing >>>> much of the work in firmware. >>> >>> wlandebug takes an -i argument. I seem to recall you created your wlan >>> interface named "mwl_wlan0", so you need to type wlandebug -i mwl_wlan0. >> >> I saw that, but that is hardcoded to expect wlan (wlan0, wlan1, etc) >> for an interface name. Having seen that, I recompiled wlandebug without >> the hardcoded interface name check and it didn't work either, but it did >> toss an error for the sysctl it was trying to tweak. > > The whole system was designed for the interfaces to start with "wlan" and be > named "wlan". It does certainly seem to lean that way. Personally I prefer to keep the hardware name in there, but I wasn't aware that would cause other issues. Especially when VAPs come into play, I'd rather have, for example, mwl0_wlan1, mwl0_wlan2, ath0_wlan0, etc, so I can better tie what goes where. But that's more of a bikeshed of personal preference. :-) > >> That made me look deeper at the code and see it was really just setting >> the debug sysctl based on flags that wlandebug was aware of. Handy, but >> the same thing could be done by hand with sysctl and some bitwise math >> in a pinch, assuming the interface has the right oids. (Which mine >> doesn't, for some reason...) > > The purpose of wlandebug is to not do any math by hand. Indeed, You're 110% right on that. I was just trying to work around the other issues I was seeing to get to the root of the issue, which seems to be the missing sysctl oid. I need to run some more tests and straighten my antenna issues out, but I'll report what I find back to the list in a few days. Thanks again for the information, Jim ___ 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: FreeBSD-8.0 802.11n support with ath/mwl
On 3/7/2010 3:34 PM, Sam Leffler wrote: > Not following the wlanX naming convention will cause confusion for > things like rc config files (I believe). Definitely any tool I touched > expects vap's to be named wlanX. Duly noted. I wasn't aware of just how many issues would arise from straying from that convention. > sysctl net.wlan.X.%parent gives the parent ifnet of a vap; I've > considered many times including this in the ifconfig status. Feel free > to offer a patch that does this. That may be handy in the future. My C skills are a bit rusty but if I decide to go down that road I'll surely share any patches I might come up with. > mwl 11n support broke sometime near the last firmware update and I never > fixed it. I know in particular there are issues with AMPDU and seq#'s > but possible other things too. The fw is rather finicky in how state is > managed and it's likely the host is not in sync causing problems w/ the > ampdu support and rate control algorithm that both operate in the fw. > You should be able to get >100 Mb/s througput on an HT40 channel but I > think I was seeing more like 35-40. Turning off ampdu is usually > helpful to stabilize operation. I'll have to try that next chance I get. I did manage to get more antenna pigtails and now have a total of three attached, but it didn't make a difference. A colleague was able to get an N rate association on his mwl card (108Mbps) with similar settings to mine, but with a different client card. It would seem that the problem may lie in the client card in my case, so I'm also investigating options there at the moment. It's an Intel ABGN 5100 card, in case anyone wonders. I also found the mwlstats and mwldebug programs which are in the src tree but not built with the system. A simple "cd /usr/src/tools/tools/mwl; make all install" built them, but mwldebug didn't seem to work for me. Looking at the code I just need to build a kernel or module while having MWL_DEBUG defined to get the sysctls to show up, but I have not yet tried that as I've had a fairly busy week. I'll see if changing the ampdu settings make any difference and report back, and hopefully the rebuild with MWL_DEBUG might also help me get a lead if tweaking ampdu doesn't help. Thanks for the reply, Sam. I appreciate the insight. Jim ___ 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: /usr/bin/objformat is missing
Chris H. wrote: [snip] While it didn't fix my seeming php5 module number limitation. I was able, after trial and error, to discover that the recode module was the module causing Apache to dump core. Simply removing it from the list cured it. :) Further investigation reveals that there are some issues with with recode versions greater than 3.5. PHP recommends using 3.5. But, as I already use iconv, and mbstring, using recode is kind of overkill anyway. So forget it. :) [snip] I've had my fair share of trouble regarding PHP4 and PHP5 crashing Apache with certain extensions, as documented here: http://www.pingle.org/2006/10/18/php-crashes-extensions/ Here: http://www.pingle.org/2007/05/13/php-crashes-extensions-2/ and here: http://www.pingle.org/2007/09/22/php-crashes-extensions-workaround/ It happens with PHP4, PHP5, Apache 1.x and Apache 2.x. My workaround is a hackish script that reorders the problematic extensions to the end of extension.ini, and in a specific order. It Works For Me, but YMMV. I'm glad you were able to get around the problem by simply disabling an extension, but some of us aren't so lucky :) Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Rebuilding World Problems
Gavin Spomer wrote: Kevin Oberman <[EMAIL PROTECTED]> 02/12/08 7:01 PM >>> make buildkernel KERNCONF=YOUR_KERNEL_HERE make installkernel KERNCONF=YOUR_KERNEL_HERE If you put KERNCONF into make.conf, you can simplify it to: make kernel Just to be clear, if I add the appropriate KERNCONF line in /etc/make.conf, "make kernel" will take care of both "make buildkernel" AND "make installkernel"? (w/o the KERNCONF= part) [snip] Last I heard, the better way to define KERNCONF in make.conf is as follows: KERNCONF?=MYKERNEL Then you can use "make kernel" as you say, but should you need to compile a kernel using an alternate configuration, you can still issue the "make kernel KERNCONF=MYOTHERKERNEL" on the command line. Similarly, if you choose to set CPUTYPE in make.conf, use a line such as: CPUTYPE?=p4 That way it can be overridden if necessary by other commands, but will default to your choice. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
7.0-PRERELEASE Fatal Trap 12 with sysctl and acpi
I'm having some trouble with a SuperMicro SuperServer 6022L-6 that
previously ran 7.0-BETA4 without problems. Today, I updated this machine to
7.0-PRERELEASE and now it will not fully boot unless I disable ACPI. A quick
search of the PR database didn't turn up anything similar with sysctl and ACPI.
I can boot to single user mode, but if I issue sysctl -a while there, it
also crashes.
I have two vmcore files, one where I booted to single user mode and issued
sysctl -a, the other when it was attempting to boot normally.
When running sysctl -a in single user mode, the last three lines before the
crash are (transcribed by hand, no serial console available):
dev.pcib.3.%location: handle=\_SB_.PCI3
dev.pcib.3.%pnpinfo: _HID=PNP0A03 UID=3
dev.pcib.3.%parent: acpi0
=
Kernel config is GENERIC, with ULE scheduler and "options ASR_COMPAT"
=
[EMAIL PROTECTED] /usr/obj/usr/src/sys/TEST]# uname -a
FreeBSD test1.hpcisp.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #1: Thu Feb
14 14:08:02 EST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TEST i386
=
[EMAIL PROTECTED] /usr/obj/usr/src/sys/TEST]# kgdb kernel.debug
/var/crash/vmcore.1
Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address = 0x2043455c
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0743036
stack pointer = 0x28:0xe8cb3a0c
frame pointer = 0x28:0xe8cb3a38
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 67 (sysctl)
trap number = 12
panic: page fault
cpuid = 3
Uptime: 6s
Physical memory: 2035 MB
Dumping 65 MB: 50 34 18 2
#0 doadump () at pcpu.h:195
195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:195
#1 0xc073aa38 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc073acf1 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3 0xc0a1fd00 in trap_fatal (frame=0xe8cb39cc, eva=541279580) at
/usr/src/sys/i386/i386/trap.c:899
#4 0xc0a1ff70 in trap_pfault (frame=0xe8cb39cc, usermode=0,
eva=541279580) at /usr/src/sys/i386/i386/trap.c:812
#5 0xc0a208ed in trap (frame=0xe8cb39cc) at
/usr/src/sys/i386/i386/trap.c:490
#6 0xc0a07bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc0743036 in sysctl_sysctl_next_ls (lsp=Variable "lsp" is not
available.
) at /usr/src/sys/kern/kern_sysctl.c:630
#8 0xc07430f6 in sysctl_sysctl_next_ls (lsp=Variable "lsp" is not
available.
) at /usr/src/sys/kern/kern_sysctl.c:618
#9 0xc0743133 in sysctl_sysctl_next_ls (lsp=Variable "lsp" is not
available.
) at /usr/src/sys/kern/kern_sysctl.c:630
#10 0xc0743133 in sysctl_sysctl_next_ls (lsp=Variable "lsp" is not
available.
) at /usr/src/sys/kern/kern_sysctl.c:630
#11 0xc0743196 in sysctl_sysctl_next (oidp=0xc0b53280, arg1=0xe8cb3c1c,
arg2=4, req=0xe8cb3ba4)
at /usr/src/sys/kern/kern_sysctl.c:651
#12 0xc0743aa2 in sysctl_root (oidp=Variable "oidp" is not available.
) at /usr/src/sys/kern/kern_sysctl.c:1306
#13 0xc0743bde in userland_sysctl (td=0xc5479660, name=0xe8cb3c14,
namelen=6, old=0xbfbfe4e8, oldlenp=0xbfbfe598, inkernel=0,
new=0x0, newlen=0, retval=0xe8cb3c10, flags=0) at
/usr/src/sys/kern/kern_sysctl.c:1401
#14 0xc0744812 in __sysctl (td=0xc5479660, uap=0xe8cb3cfc) at
/usr/src/sys/kern/kern_sysctl.c:1336
#15 0xc0a202b8 in syscall (frame=0xe8cb3d38) at
/usr/src/sys/i386/i386/trap.c:1035
#16 0xc0a07c40 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:196
#17 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
=
dmesg is attached, but it is from a non-acpi boot.
=
Anyone have any ideas on what might be the cause or a possible fix?
I'll keep the crash dumps around. This is a test box that I'm researching
7.0 on for possible production use on similar hardware. There is no planned
usage yet, and no other plans for this box, so anything goes in terms of
possible debugging.
If I get some time next week I might try a binary search of commits between
BETA4 and now, to pinpoint where it stopped working.
Thanks,
Jim
Copyright (c) 1992-2008 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 7.0-PRERELEASE #1: Thu Feb 14 14:08:02 EST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TEST
Timecounter "i8254"
Re: 7.0-PRERELEASE Fatal Trap 12 with sysctl and acpi
Jim Pingle wrote: I'm having some trouble with a SuperMicro SuperServer 6022L-6 that previously ran 7.0-BETA4 without problems. Today, I updated this machine to 7.0-PRERELEASE and now it will not fully boot unless I disable ACPI. A quick search of the PR database didn't turn up anything similar with sysctl and ACPI. [snip] When running sysctl -a in single user mode, the last three lines before the crash are (transcribed by hand, no serial console available): dev.pcib.3.%location: handle=\_SB_.PCI3 dev.pcib.3.%pnpinfo: _HID=PNP0A03 UID=3 dev.pcib.3.%parent: acpi0 With a working system/kernel the lines immediately following this are: dev.pcib.4.%desc: ACPI Host-PCI bridge dev.pcib.4.%driver: pcib dev.pcib.4.%location: handle=\_SB_.PCI4 dev.pcib.4.%pnpinfo: _HID=PNP0A03 _UID=4 dev.pcib.4.%parent: acpi0 = Kernel config is GENERIC, with ULE scheduler and "options ASR_COMPAT" = Here is the entire kernel config: ident TEST include GENERIC options ASR_COMPAT nooption SCHED_4BSD options SCHED_ULE = dmesg is attached, but it is from a non-acpi boot. = Attached to this message is a dmesg from a working world/kernel on the same box. If I get some time next week I might try a binary search of commits between BETA4 and now, to pinpoint where it stopped working. As a buildworld/buildkernel takes about an hour and a half on this hardware (2x2GHz Xeon), I haven't fully narrowed this down yet. It is somewhere between 12/15/2007 (works) and 12/25/2007 (crashes). I glanced at the archives between those points but I didn't see any similar complaints. The only ACPI references I saw in the archives were referring to thermal zone problems, and a commit relating to those. I'll return to this early next week to see if I can narrow this down more precisely. Jim Copyright (c) 1992-2007 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 7.0-BETA4 #4: Fri Feb 15 16:23:57 EST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TEST Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) XEON(TM) CPU 2.00GHz (1999.94-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff Logical CPUs per core: 2 real memory = 2147418112 (2047 MB) avail memory = 2091872256 (1994 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length:0 0/8 [20070320] MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard ACPI Warning (dswload-0794): Type override - [DEB_] had invalid type (Integer) for Scope operator, changed to (Scope) [20070320] ACPI Warning (dswload-0794): Type override - [MLIB] had invalid type (Integer) for Scope operator, changed to (Scope) [20070320] ACPI Warning (dswload-0794): Type override - [IO__] had invalid type (Integer) for Scope operator, changed to (Scope) [20070320] ACPI Warning (dswload-0794): Type override - [DATA] had invalid type (String) for Scope operator, changed to (Scope) [20070320] ACPI Warning (dswload-0794): Type override - [SIO_] had invalid type (String) for Scope operator, changed to (Scope) [20070320] ACPI Warning (dswload-0794): Type override - [SB__] had invalid type (String) for Scope operator, changed to (Scope) [20070320] ACPI Warning (dswload-0794): Type override - [PM__] had invalid type (String) for Scope operator, changed to (Scope) [20070320] ACPI Warning (dswload-0794): Type override - [ICNT] had invalid type (String) for Scope operator, changed to (Scope) [20070320] ACPI Warning (dswload-0794): Type override - [ACPI] had invalid type (String) for Scope operator, changed to (Scope) [20070320] ACPI Warning (dswload-0794): Type override - [IORG] had invalid type (String) for Scope operator, changed to (Scope) [20070320] ACPI Warning (dswload-0794): Type override - [SB__] had invalid type (String) for Scope operator, changed to (Scope) [20070320] ACPI Warning (dswload-0794): Type override - [PM__] had invalid type (String) for Scope operator, changed to (Scope) [20070320] ACPI Warning (dswload-0794): Type override - [SIO_] had invalid type (String) for Scope o
Re: 7.0-PRERELEASE Fatal Trap 12 with sysctl and acpi
Jim Pingle wrote: Jim Pingle wrote: I'm having some trouble with a SuperMicro SuperServer 6022L-6 that previously ran 7.0-BETA4 without problems. Today, I updated this machine to 7.0-PRERELEASE and now it will not fully boot unless I disable ACPI. A quick search of the PR database didn't turn up anything similar with sysctl and ACPI. I wiped the machine, installed from the RC3 CD, and it did not crash. If I update to RELENG_7, the crash comes back. If I go back to RELENG_7_0, there is no crash. Kernel config is GENERIC, with ULE scheduler and "options ASR_COMPAT" This happens with GENERIC, with no extra options, as well as with my custom kernel. If I get some time next week I might try a binary search of commits between BETA4 and now, to pinpoint where it stopped working. As a buildworld/buildkernel takes about an hour and a half on this hardware (2x2GHz Xeon), I haven't fully narrowed this down yet. It is somewhere between 12/15/2007 (works) and 12/25/2007 (crashes). I glanced at the archives between those points but I didn't see any similar complaints. The only ACPI references I saw in the archives were referring to thermal zone problems, and a commit relating to those. I'll return to this early next week to see if I can narrow this down more precisely. I tried a binary search of the source tree to narrow down the crash. I found that one vector for the crash was introduced between 2007/12/19 20:00:00 and 2007/12/19 23:59:00, which left me with only a handful of files to test. By process of elimination, I found that if I backed some changes out in machdep.c, the crash stopped. machdep.c v1.658 2007/08/09 njl - Boots OK machdep.c v1.658.2.1 2007/12/19 rpaulo - Crashes The confusing part (to me) is that my next step was to update all the way to RELENG_7 as of yesterday, then back out those same changes, but the crash still happened. So either I misidentified the cause of the crash -- which is quite possible -- or it was reintroduced in some other change (or both!). I have a debug kernel built now, and I can generate vmcore files at will. Does anyone have any ideas? Is there some more information that I can gather that will help find the cause? Now that I have some more solid information, I'll open a PR. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jerky mouse still in 7.0-RELEASE
Kris Kennaway wrote: Teemu Korhonen wrote: Did anyone find a solution to the "jerky mouse" -problem? It still exists in 7.0-RELEASE. I have pretty much exact same symptoms as in this post: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039599.html Part of the problem here is that these "symptoms" are far too generic for diagnosis and have a variety of known and unknown causes. Some of the "known" causes include: * Overloading the system transiently (e.g. if your KDE launches 30 processes at once, the system is going to be a bit sluggish for a few seconds) * Running powerd, which has poor interaction with interrupt delivery on at least one user's system (might be an ACPI issue or hardware-specific). * Performing lots of I/O to a non-mpsafe filesystem like msdosfs. The other causes have so far resisted understanding. I have a little more insight into the problem, at least in my case. Short version: it is a KVM/mouse detection issue. I have one system that is experiencing a mouse problem, but as you said later in this thread it might be interrupt-related. The system in question is a 2xPIII-800 SMP system, running 7-STABLE from yesterday with the ULE scheduler. This happens to be my only 7-x box running X (so far), with a mouse that gets used. The mouse hesitates at the console and in X. It will move for a half second or so, then stop for just as long. If I monitor processes with top or vmstat, it shows that moving the mouse causes the system to use ~50% CPU in interrupts. In X, the result is the same regardless of whether I use sysmouse or psm0 directly. This system is hooked into a KVM. I found that if I booted with the system active on the KVM, the mouse worked fine. Also, while the mouse in a working state, the interrupts from the mouse never go above 3% CPU. If I boot with another system active on the KVM instead, the mouse reverts to being jerky and in a state where it generates abnormally high levels of interrupts and hesitats. The only difference in dmesg between the two boots is the model of the mouse as detected by the system: # grep psm0 dmesg.iffymouse psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model VersaPad, device ID 0 # grep psm0 dmesg.goodmouse psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model NetMouse/NetScroll Optical, device ID 0 Note that in both cases, the model is incorrect compared to the actual mouse. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php5 and postgresql 8.2/8.3
Claus Guttesen wrote: I have installed php5 with support for postgresql (php5-pgsql). If I install postgresql-client ver. 8.2.7 or 8.3.x apache (httpd) core-dumps. If I install postgresql-client 8.1.11 or 8.2.6 apache does not core-dump. I have confirmed that it's postgresql which makes apache core dump by commenting out pgsql.so in /usr/local/etc/php/extensions.ini. This - off-course - prevents me from connecting to my db. :-/ Apache is ver. 1.3.41 from ports with no changes to the default-values during portinstall. PHP is ver. 5.2.5_1. Replying to myself (and others :-) ). When compiling php5 statically with postgresql-support apache no longer core dumps. I added CONFIGURE_ARGS+=--with-pgsql to /usr/ports/lang/php5/Makefile. Not sure if this would make much of a difference in your case, but have you tried moving the line for pgsql.so up higher in extensions.ini? I haven't had any trouble with PostgreSQL's PHP extension, but I have with plenty of others (MySQL, recode, imap, sockets, and pspell) when the extensions were not in a specific order. I've documented the issue here: http://www.pingle.org/2006/10/18/php-crashes-extensions http://www.pingle.org/2007/09/22/php-crashes-extensions-workaround More info can be found in the archives as well. If that does alleviate your problem, let me know and I'll add notes for pgsql.so to my workaround. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
Daniel O'Connor wrote: On Thu, 12 Jun 2008, Jeremy Chadwick wrote: I myself haven't ever run into extension ordering issues like those described (and we've done hosting for years), but I don't doubt those who have experienced such. I am currently experiencing this :( In the past I shuffled the order until it worked but that's not a real solution. [snip] I've mentioned this on the lists a couple times, but I have a shell script I worked out that puts the extensions into a known-working order. http://www.pingle.org/2007/09/22/php-crashes-extensions-workaround It's based on things I've come across with respect to this issue over the last couple years. It's not a new problem by a long shot. It's been happening to me for years with PHP4 and PHP5, Apache 1.3.x and 2.x. See also my previous posts on my site: http://www.pingle.org/2006/10/18/php-crashes-extensions http://www.pingle.org/2007/05/13/php-crashes-extensions-2 And some previous threads on the topic: http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/030951.html http://lists.freebsd.org/mailman/htdig/freebsd-ports/2006-November/036849.html (I thought there were more but I can't find them at the moment...) I need to see if I can improve the script any (suggestions are most welcome) then open a PR to see if it -- or logic like it -- can be included in the php-extensions meta port. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
Daniel O'Connor wrote: On Thu, 12 Jun 2008, Jim Pingle wrote: I need to see if I can improve the script any (suggestions are most welcome) then open a PR to see if it -- or logic like it -- can be included in the php-extensions meta port. Adding the script to the port seems like the way to go (baring an upstream fix but it seems like a difficult problem to solve). Unfortunately it doesn't help me :( If I disable everything except either pgsql or mhash (either separately or together) Apache crashes with.. #0 0x28ad6d40 in ?? () #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 #2 0x2819fa0c in puts () from /lib/libc.so.7 #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 #4 0x08069a12 in ap_get_local_host () #5 0x08068b9c in ap_fini_vhost_config () #6 0x0805639c in ap_read_config () #7 0x0805f133 in standalone_main () #8 0x08060c1f in main () I don't understand why gethostbyname() would call puts() - and why that would then crash! Seems like some threading related wrinkle though as pgsql & mhash are the only extensions I have that are linked to libthr.so I'm afraid I wouldn't be much help with this one in that case. I have a vague recollection of gethostbyname() crashing for someone else, though. I thought it had something to do with the ServerName directive and/or an entry in /etc/hosts -- but unfortunately I don't recall the specifics and my Google-fu seems to be failing me this morning. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 9.1-RC1 Available...
On 8/23/2012 11:43 AM, Ian Lepore wrote: > On Thu, 2012-08-23 at 11:17 -0400, Ken Menzel wrote: >> >> I found two good primers: >> http://mebsd.com/configure-freebsd-servers/update-freebsd-source-tree-using-subversion-svn.html >> http://www.freebsd.org/doc/en/articles/committers-guide/article.html#SUBVERSION-PRIMER >> >> The second primer in the committer handbook seems to indicate that it >> is difficult to run an SVN mirror. This appears to me to be the >> biggest drawback. I have been using CVS and perforce for years, but >> subversion is new to me. > > It may be difficult to run an svn mirror that allows you to commit > locally and get those changes back to the project, but running a > read-only mirror is trivial. The script I run nightly from cron to sync > my local mirror is: > > #!/bin/sh > # > # svnsync to pull in changes from FreeBSD to my local mirror. > # > svnsync sync file:///local/vc/svn/base > > I can't remember how I initially created and populated the mirror, but > it's likely I grabbed a snapshot of the mirror at work and brought it > home on a thumb drive (just to avoid initial network DL time). I spent a little time today setting up an SVN mirror after reading this thread and wrote up a how-to for those looking to do the same. http://www.pingle.org/2012/08/24/freebsd-svn-mirror Comments/Flames/Corrections welcome... Jim ___ 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: FreeBSD 9.1-RC1 Available...
On 8/30/2012 9:53 AM, Stas Verberkt wrote: >> I spent a little time today setting up an SVN mirror after reading this >> thread and wrote up a how-to for those looking to do the same. >> >> http://www.pingle.org/2012/08/24/freebsd-svn-mirror >> >> Comments/Flames/Corrections welcome... >> > Just wondering: do you really need DAV if you are not going to allow > writing? > I serve my read-only GIT repositories using HTTP without WebDAV. I'm not 100% sure on that part - previously I had setup a read+write SVN repo over HTTPS (at $oldjob) so I went with the directions I had for that, just adjusted for read-only. Some Googling suggests that DAV is required. The official Subversion book lists DAV as a requirement[1]. Wikipedia seems to suggest it's required as well "Apache HTTP Server as network server, WebDAV/Delta-V for protocol. There is also an independent server process called svnserve that uses a custom protocol over TCP/IP." If someone knows a trick to serve it up over HTTP without DAV that would be good to know. Jim P.S. Realized I sent this directly, resending to the list, with an edit. [1] http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html ___ 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: Ipsec VPN tunnel from a Win/7 box?
On 2/15/2013 10:45 AM, Karl Denninger wrote: > On 2/15/2013 9:37 AM, Kurt Lidl wrote: >> >> Hmm. >> >> I've got IPSEC tunnels from Windows XP and Windows 7 working >> to a FreeBSD 8.3 host, using NAT/T. >> >> I'm using the Shrewsoft client: http://www.shrew.net/software >> >> -Kurt >> _ > > The goal is to do it using only the native Win/7 VPN support. > > So far I've failed for IPSEC :-) > A little late, but you might find this helpful/interesting: http://forum.pfsense.org/index.php?topic=55754.0 Seems to take a little work on the Windows side, but pfSense uses racoon (ipsec-tools) on FreeBSD so it should be possible to replicate on a plain FreeBSD install, the poster even gives the racoon.conf and spd entries. Jim ___ 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: upgrade 6.2 to xorg 7.2
Stephen Clark wrote: > There is a deadly embrace. > > The /usr/src/UPDATING says I am going to miss out if I > don't have the meta port installed (which I currently don't), but when I > try to install > the meta port it tells me I should use portupgrade to upgrade Xorg, but > the /usr/src/UPDATING > which talks about using portupgrade says I am going to miss out if I > don't have the meta > port installed (which I currently don't), but when I try to install the > meta port it tells me I > should use portupgrade to upgrade Xorg, but ad infinitum! > > Steve > It would appear you are skipping over the relevant portion of UPDATING. The message you are seeing appears when your environment does not have XORG_UPGRADE=yes set in its environment. This is necessary even after you have completed the instructions, and for future updates. The exact reasoning and such was discussed on the ports list and can be found in the archives. I believe someone (Kris?) said that this will be necessary for the time being, but not at some yet-to-be-determined point in the future. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: long pause in startup
Charles Sprickman wrote: > Any ideas on this one? This machine (one of those ancient VALinux 2U > boxes, Intel L440GX+ board, dual PIII) hangs for a very long time > between the second processor launching and geom_mirror kicking in. It > does always boot, but the hang is more than a minute - just enough to > make one nervous when rebooting remotely... > > Is this just the mirror taking a really long time to initialize, or > something more sinister? [snip] > Any info is appreciated, this is just something I wanted to check out > before bringing this into production (secondary ns, mx w/pfspamd). I've got a bunch of these and they all do it. It seems to be something with the floppy controller. During the hang it's accessing the floppy drive (light is on) and if the floppy is disabled, there is no hang. IIRC if you have a floppy in the drive it also does not hang. That's the short version, anyhow. It's been discussed on the list before so you might check the archives for a better/more complete answer. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A little story of failed raid5 (3ware 8000 series)
Artem Kuchin wrote: > A day ago at 11 am i have turn off the server, > pull out the old driver, installed a new one, turned of the server > and started rebuild in an hour from remote location via web interface. > After about 5 minuted the machine became unresponsive. Tried rebooting > - nothing. I went to the machine and fingure out, that rebuild failed (0%) > and some data cannot be read because of bad sectors. We had a similar failure a few years ago, in fact every drive in the array had bad sectors, but one failed completely. Rebuild would not work no matter what we did. Yet another reason to be sure your RAID disks come from different manufacturing batches! > - i cannot make it ignore read errors > - i cannot figure out which driver has bad sectors > (maybe someone know it?) We recovered from that situation like so: 1. Power off the server 2. Pull each drive, attach to another box w/o RAID adapter and use diagnostic tools to run a surface scan/remap on each disk. (These were SCSI disks, not sure if the same applies to PATA/SATA) 3. Put all drives back, including a replacement for the truly failed drive 4. Let the array rebuild Many crossed fingers/toes/eyes later, it came back to life. We replaced the whole box shortly thereafter. The downside was the entire server was offline for the duration of the process, instead of being online during a normal rebuild. > So, no raid5 or even raid 6 for me any more. Never! If it's done properly, with hot spares and other failsafe measures, it isn't too bad. Sometimes it's the best available option due to budget/hardware/etc constraints, especially on older systems. RAID can be a tough beast, though. We had one server that ran fine for nearly 5 years on a single PATA disk. Two months after I rebuild it with a proper SCSI RAID setup, it has a multi-drive failure and bombs. Sometimes all the safety measures in the world can't make up for what passes for hardware quality these days... Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Also seeing 2 x quad-core system slower that 2 x dual core
Pete French wrote: >> Have you checked that your dir hash isn't suffering due to lack of memory >> this can have a marked impact on seemingly trivial things like this as >> could silly things like the RAID card being installed in a different slot. > > RAID card is onboard on these things - how would I check the dir hash ? The > slower server has 16 gig of RAM, the faster one has 4 gig. Both were > installed the same way in the same order, so should have the same disc layout > more or less. This may be a silly question, but have you tried reducing the RAM on the quad core machine to 4GB so the machines match in that respect as well? I seem to recall a thread a while back about someone who had slowdowns in a certain situation with large amounts of RAM (>4GB). Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 7.2-RC boot problem
subbsd wrote: > Hello, i've got some problem with my SATA Optiarc DVD RW: > message output on the screen in not stopped, but repeating with incremental > delay: > ... > acd0: DVDR at ata3-master UDMA33 > HEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install Did you retype this? Or did it really say "HEOM"? If that's not a typo, you may want to check for RAM errors. > run_interrupt_driven hooks: still waiting after 60 seconds for xpt_config > run_interrupt_driven hooks: still waiting after 120 seconds for xpt_config > run_interrupt_driven hooks: still waiting after 180 seconds for xpt_config > run_interrupt_driven hooks: still waiting after 240 seconds for xpt_config > run_interrupt_driven hooks: still waiting after 300 seconds for xpt_config I spoke with someone the other day who had that exact same message, and it was due to either a Firewire controller in the BIOS, or a USB card reader. They disabled both at the same time, and the message went away. That appears to be the CAM subsystem probing for root-capable devices, from what I found via Google the other day. Jim ___ 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"
11.2 dhclient MTU behavior is broken
The DHCP client, dhclient, in 11.2 was changed to support server-side MTU ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206721 ), but this MTU feature being enabled by default causes an unexpected change in behavior on upgrade, which to me is a POLA violation. My ISP sends a bogus MTU of 576, and I've seen reports of others that do the same. Previously this was ignored since the client didn't support processing the MTU, but now it's respected and breaks connectivity since the MTU should really be 1500. There doesn't appear to be any way to override the client behavior either. Using a request line that doesn't include interface-mtu doesn't help since if the server always sends it, it is still read and respected. Any supersede value in dhclient.conf appears to be ignored in favor of the server-supplied value. The link bounces when the MTU is set as well, at least on e1000. I see dhclient was changed to help cope with that but it also affects other things that key off link up/down events and can lead to a loop depending on what those scripts do. Can this feature be changed so that it's optional and disabled by default? Either a command-line option or a dhclient.conf directive would work. As-is, it's making the stock dhclient unusable here without patching out that feature. I can see people wanting to use that, but it shouldn't be on for everyone out of the box. Jim P. ___ 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: 11.2-RC3 regression - networking igb driver
On 6/23/2018 1:27 PM, David Samms wrote: > There is a regression in 11.2-RC3 that effects the igb driver for Intels > C2000 SoC I354 Quad GbE Controller > > Supermicro A1SRi-2558F > http://www.supermicro.com/products/motherboard/Atom/X10/A1SRi-2558F.cfm > > This server has run 10.x and 11.x fine up till 11.2-RC3. > > PROBLEM: > with 11.2-RC3 the server boots and gets a network connection to the > cable modem, but the interface (igb0) resets every 4-8 second. The reset > time appears to be related to network load, but reset withing 10s with > next to no traffic. I did try swapping cables, but with no effect. With > each reset the interface successfully obtains an IP address via DHCP, > works for a few seconds and resets. > > Restoring the server to 11.1-RELEASE-p10 resolves the problem. > > Any suggestions? Does your DHCP server send you an MTU, perhaps? Before the interface resets, what does its MTU show? You might try creating a dhclient.conf that sets "supersede interface-mtu 0;" and see if that helps. The MTU from DHCP feature is new (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206721 ) and e1000 interfaces will reset when applying the MTU. Jim P. ___ 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: php in free(): error: junk pointer, too high to make sense
Dominik Zalewski wrote: > I'm using FreeBSD 6.1 release on i386. I have a problem with pear and apache. > Here is what I'm getting: > > [EMAIL PROTECTED] ~]# pear list > Installed packages, channel pear.php.net: > = > PackageVersion State > Archive_Tar1.3.1 stable > Console_Getopt 1.2 stable > DB 1.7.6 stable > Date 1.4.7 stable > Log1.9.9 stable > PEAR 1.4.11 stable > XML_RPC1.5.0 stable > php in free(): error: junk pointer, too high to make sense > Abort trap: 6 (core dumped) > > apache 2.2.3 and php-4.4.4_1 is working fine but everytime I restart it > throws > core dump. > > Any ideas? I have seen this with PHP for a long time, with PHP 4.x-5.x. While it isn't the exact same context in which you're getting the error, the source may be the same. After I rebuild PHP extensions and restart Apache (1.3 or 2.2, doesn't matter which) or invoke PHP from the command line, PHP crashes and/or takes Apache down with it. Here are the errors that tend to show up for me: * exited on signal 11 (core dumped) * exited on signal 6 (core dumped) * seg fault or similar nasty error detected in the parent process * httpd in free(): error: junk pointer, too high to make sense I'm not sure if it's a problem inherent to how the ports system builds and installs the extensions or if it's just a problem in general. I had read somewhere that rebuilding extensions in a certain order would fix it. However, after some experimenting I found that rebuilding the extensions doesn't really matter, but the order of the extensions being loaded does. Rebuilding fixed it because when a php extension port is rebuilt, it gets placed at the end of extensions.ini. I solved the problem by editing /usr/local/etc/php/extensions.ini and placing the lines for mysql, imap, and sockets at the end and in that order: ... extension=mysql.so extension=imap.so extension=sockets.so I'm not sure if the conflict is only with those three, or with others as well, but that fixes it on my servers. I tried it on three different setups, and before the change they all crashed and after the change they're all running OK. I was never sure if I should file a PR about it because it could easily be a PHP problem and have nothing to do with FreeBSD or the ports system specifically. I haven't had time to research it any more to get enough information to figure out where the problem lies and with whom the bug report should be filed (i.e. try building directly and not from ports, install Fedora and try there, etc) Hope this helps! If not, it will at least be in the archives for future searches. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: asr / raidutil not available for 6.x either ... ? :(
Marc G. Fournier wrote: > > Installed it from ports, and it installed the compat4x stuff, but although it > runs with no args, as soon as I try to access the controller: > > > # raidutil -d 1 -L physical > osdIOrequest : File /dev/rdptr17 Could Not Be Opened > Engine connect failed: COMPATILITY number > > > so I take it that like the storcon stuff, one is out of luck running FreeBSD > 6.x? :( I have a bunch of these and using raidutil works great, however you need to rebuild your kernel with: options ASR_COMPAT That is in addition to having compat4x_enable="YES" in rc.conf Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Adaptec 2100, asr driver
Willem Jan Withagen wrote: > So the 1000$ question: is there any chance of getting at least the state > of the RAID and its disk out into the open? It shure would give me a > much better feeling, knowing that at least serious trouble would be > detected by me. Instead of getting this call from a NOC. It works fine here. I use this on systems with 2100s, and with 2010s. cd /usr/ports/sysutils/asr-utils; make install clean Make sure it installs compat4x, it should as it is listed as a dependency. Add this to /etc/rc.conf: compat4x_enable="YES" add "options ASR_COMPAT" to your kernel and rebuild the kernel Reboot. That's it. You can use "raidutil -A off" to silence the alarm once it is active. As well as checking the drives with "raidutil -L all". You can get more/less detail, just check the command line options. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Loosing spam fight
Roland Smith wrote: > Most spammers do not bother to return if they get a resend request. > That's the whole point of doing this. So practically it doesn't increase > bandwidth consumption. This conversation is getting rather OT for -stable, but I felt the need to ask a question: To defeat this, wouldn't a spammer just have to send out the same spam twice in a row from the same machines, spaced apart by a little time? Bonus for the spammer: accounts on servers without greylisting would get two copies of the spam. Greylisting is a decent idea, but it seems to me that it's just another tool in the ongoing arms race against spammers. It may work for a while, but eventually they'll catch on and it will only cause unnecessary delays for legitimate mail. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 6.1 and Palm Tungsten C
Viktorija wrote: > I have following problem. I have Palm Tungsten C and FreeBSD 6.1 on my > laptop. I'm trying to synhronize my palm with freebsd, but without any > success. What i did: > in kernel added devices: > ucom and uvisor. > in usbd.conf: > device "Palm Handheld" > devname "ucom[0-9]+" > vendor 0x0830 > product 0x0060 > release 0x0100 > attach "ln -fs /dev/ucom0 /dev/pilot; chmod 666 /dev/ucom0" > > When i press sync button on palm, i see in messages: > Feb 19 02:50:29 blue kernel: ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, > addr 2 > > And in /dev directory i get cuaU0 and ttyU0, but not ucom0. > Ok, i saw in one message, that now ttyU0 should be used instead of ucom0, but > when i'm trying: > pilot-xfer -p /dev/ttyU0 -i palm/softs/Tube/Tube2.prc > nothing happens... > > What i'm doing wrong? > Why ucom0 doesn't exist? > Maybe someone got similar problems? I have successfully been using my Tungsten C with 6.1-PRERELEASE, I have my sync software talk directly to /dev/cuaU0 and it just works, once I got the permissions straightened out. I have used pilot-xfer as well as KPilot/Kontact. I did not add any entries in usbd.conf, but I did experiment with devfs.rules for setting the permissions. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: long timeout on boot
Antony Mawer wrote: > On 3/06/2006 2:43 AM, Jack Vogel wrote: >> On 6/2/06, Gavin Atkinson <[EMAIL PROTECTED]> wrote: >>> On Thu, 2006-06-01 at 15:30 -0700, Jack Vogel wrote: >>> > Both on my own machine, and on systems in our test group's lab, we >>> > notice these long (like 2min maybe?) delays near the end of boot. It >>> > seems to be ATA/SATA related. It has just announced the one disk >>> > it discovered, then shows the CPUs launched, and then it just sits >>> > printing nothing for, like I said, maybe a minute or two. Finally >>> it will >>> > complete boot and all seems to be fine. >>> >>> Can you put a verbose dmesg up with debug.fdc.debugflags=255 set from >>> the loader? >>> >>> I suspect you'll find it's floppy-related. Try setting >>> hint.fdc.0.disabled="1" from the loader and seeing if it goes away. >> >> YUP, I hadnt looked before, but during the whole timeout the floppy >> access light is on. There were some messages during boot from the >> controller as well. > > I've seen this on a number of 6.0 production systems with exactly the > same symptoms. Disabling the floppy controller removes the long delay. > > I've skimmed the change log for the fdc driver: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fdc/ > > ... but there have been a huge number of commits over the recent few > years. Any number of those sounds like potential candidates for > introducing the problem, but it will need someone with a large degree of > patience to try and identify where the problem started occurring. > > I might add that it seems very hardware dependent: unfortunately none of > my test machines on-hand exhibit the problem or I might be able to do > some testing myself... > > -Antony I posted about this problem previously, when I had (very incorrectly) thought it had something to do with the RAID controller. I have a large number of servers that exhibit this behavior and have done so since 6.0-RELEASE. I have 5.4 on one of them but I don't recall if it did the same thing or not. The servers I have which do this tend to be Intel chipset systems, most of them are VA Linux boxes: Dual pIII-800s on L440GX+ Boards, if memory serves. fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 I have one or two of these setup I could do some testing with, but I'm not sure what dates to start with, seeing as the problem has existed since 6.0-RELEASE on these (and with most of them that's the first release I've used on them.) I can check some more on Monday to see at least if the 5.x box is doing this. It's a testing server that's not currently in use. I'd check right now but it'd be almost impossible to diagnose remotely (no serial console.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why use 60 sec on da0 during boot?
Lukas Ertl wrote: > On 11/9/05, Ingeborg Hellemo <[EMAIL PROTECTED]> wrote: > >>Fresh new ProLiant dl380 2 CPU/dual core >>Fresh new FreeBSD 6.0-RELEASE >> >> >>During boot I arrive at >> >>da0 at ciss0 bus 0 target 0 lun 0 >>da0: Fixed Direct Access SCSI-0 device >>da0: 135.168MB/s transfers >>da0: 34727MB (71122560 512 byte sectors: 255H 32S/T 8716C) >> >>then nothing happens for about 60 seconds and then everything proceedes as >>usual (starting daemons, mounting NFS-disks etc.) > > > I see this behaviour on my DL380s, too. I don't have a fix, but a > workaround: disable the floppy drive in the BIOS. I also see this behavior, though I see it on a few systems which are all Dual CPU PIII 800MHz. They each have different SCSI or RAID controllers (one has an amr card, one has an mlx controller, and one I believe just had an ahc controller. The motherboards all have Intel serverworks chipsets. These are all fresh installs of FreeBSD 6.0 (and updated to -STABLE). It happens with GENERIC and with a lightly modified custom kernel (remove unused cpu types, add smp) In each case, during this pause the floppy light is on solid, so I'm not sure it has anything to do with the SCSI controller(s). For me, it goes like so: ... Waiting 5 seconds for SCSI devices to settle amrd0: on amr0 amrd0: 17364MB (35561472 sectors) RAID 0 (optimal) amrd1: on amr0 amrd1: 34728MB (71122944 sectors) RAID 0 (optimal) sa0 at ahc0 bus 0 target 0 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) SMP: AP CPU #1 Launched! [long pause] Trying to mount root from ufs:/dev/amrd0s1a ... I haven't tried to time the pause, but I believe it was a different duration on each system. (Particularly long with a higher end Mylex card) For me it's just a minor annoyance, everything works fine otherwise. If anyone wants more information I can try to gather some next week when I'm back in the office. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [5.4-p6] Trouble with swap_pager: indefinite wait buffer on LSI(PERC4)-RAID on Dell PE6650
Raphael H. Becker wrote: > Hi *, > > swap_pager: indefinite wait buffer: device amrd1s1d, blkno 77 > > Any access to the RAID is impossible (e.g. login on console, shutdown, > ... ), have to powercycle it. > > What is the meaning of this message? I have encountered this error once before, and it meant that it timed out trying to access the disk/partition where swap was. It also coincided with a network card (fxp0) timeout, but I'm not sure that was related. The system was unresponsive from the console or remotely until it was completely power cycled, the reset button wasn't enough. > What is the causation for this error? Probably a disk/controller/SCSI timeout of some sort > amr0: mem 0xfce0-0xfce0 irq 21 at device 1.0 > on pci3 Mine also happened to be on an LSI/amr based card, but not a Dell. It's an older dual CPU PIII-800. > Is there anything I can do? > Any switches? sysctl? > Is 6.0-RELEASE or will 6.1-RELEASE be a solution for that? > Any patches in 5-STABLE? In my case, after some hair pulling, it turned out to be a bad SCSI cable. You might check your cabling and termination, and perhaps swap the cable even if it looks good -- mine looked better than the cable I replaced it with. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
