Re: sed and comma-delimited file
On Thu, Sep 21, 2006, Freddie Cash wrote:
On Tue, September 19, 2006 4:49 pm, Matt Emmerton wrote:
On Tue, September 19, 2006 9:26 am, SigmaX asdf wrote:
I have a series of comma-delimited text files with fourteen
columns of data and several hundred rows. I want to use a short
shell script to strip them of the last 9 columns, leaving the same
file but with just five of its columns. I can do it in C++, but
that seems like overkill. How would I go about doing it with sed
or a similar utility?
cat file | awk -F, '{ printf %s,%s,%s,%s,%s\n,$1,$2,$3,$4,$5
}' newfile
What's wrong with this?
cat file | cut -f-5 -c';' newfile
[shrug] It uses cut, which I've never used or even heard of??? :)
I strongly recommend getting a copy of the book ``Unix Text
Processing'' by Dougherty and O'Reilly which is far and away the
best I've seen for using UNIX tools. I think it's out of print,
and hard copies are probably found at http://www.bookfinder.com/
There's also a free PDF version available from O'Reilly.
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Systems, Inc.
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/
When I hear a man applauded by the mob I always feel a pang of pity
for him. All he has to do to be hissed is to live long enough.
-- H.L. Mencken, ``Minority Report''
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sed and comma-delimited file
Hi, all!
On Tue, Sep 19, 2006 at 07:49:42PM -0400, Matt Emmerton wrote:
cat file | awk -F, '{ printf %s,%s,%s,%s,%s\n,$1,$2,$3,$4,$5 }'
newfile
What's wrong with this?
cat file | cut -f-5 -c';' newfile
Both commands suffer badly from useless use of cat(1) ;-))
See
http://sial.org/howto/shell/useless-cat/
for one of the dozens of explanations on the web.
SCNR,
Patrick
--
punkt.de GmbH Internet - Dienstleistungen - Beratung
Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100
76137 Karlsruhe http://punkt.de
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Dovecot 1.0 rc7 on FreeBSD 6.1-RELEASE/i386 with kqueue eats much CPU
I have a problem with dovecot eating sometimes up to 90% CPU. While making such high cpu load, dovecot calls gettimeofday() more than 2 times per second: mail2# cat k.dov.l.txt | grep CALL | grep gettimeofday | wc -l 1195552 mail2# head -n 1 k.dov.l.txt 20910 imap 0.00 CALL gettimeofday(0x80c2c60,0x80c2c68) mail2# tail -n 1 k.dov.l.txt 20910 imap 51.826065 RET gettimeofday 0 Here is my kdump: http://www.elantech.ru/kdump-dovecot.txt.gz top shows high system load (~50%) and small user load (~0-5%). We discussed this problem in dovecot@ mailing list ( http://www.dovecot.org/list/dovecot/2006-September/016096.html ), and people from dovecot@ recomended me to send this problem also to freebsd-stable@ and [EMAIL PROTECTED] Thanks for help in advance! -- С уважением, Савчук Тарас ООО Элантек : Аутсорсинг ИТ, WEB-разработка http://www.elantech.ru +7 (495) 589 68 81 +7 (926) 575 22 11 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Skype on freebsd 6.2-prerelease.
Hello, After updating to freebsd-6.2-prerelease (3 days old now) I have weird problems with Skype. When I start skype everything else stop to work normally like my PC is running fork bomb or something else like this. The weird thing is that the CPU becomes 100% idle and even login to the sistem takes few minutes. I run ktrace on skype pids and what I saw was thousands of lines with: 4306 skype_bin RET getdomainname 0 4306 skype_bin CALL getdomainname(0xbfbfd540,0) 4306 skype_bin RET getdomainname 0 4306 skype_bin CALL getdomainname(0xbfbfd540,0) 4306 skype_bin RET getdomainname 0 4306 skype_bin CALL getdomainname(0xbfbfd540,0) 4306 skype_bin RET getdomainname 0 4306 skype_bin CALL getdomainname(0xbfbfd540,0) From this point I cannot start anything that need network (and may be not only network), and the only way to bring back system is to kill -9 all skype processes which move their state to: 4305 p3 IN 0:00.00 /bin/sh /usr/X11R6/bin/skype 4306 p3 DE 0:02.43 skype_bin 4332 p3 D 0:00.11 skype_bin 4342 p3 D 0:00.00 skype_bin (after sending kill on skype, kdump shows : 4306 skype_bin RET getdomainname -1 errno -4 Unknown error: -4 ) From here the only way to stop skype is to restart X(org). I'll update to the latest src today again, but I have the bad feeling that this will not change a thing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dovecot 1.0 rc7 on FreeBSD 6.1-RELEASE/i386 with kqueue eats much CPU
I have a problem with dovecot eating sometimes up to 90% CPU. Are you using kqueue support ? I also had this problem and the solution for me was to recompile it without kqueue support. Now it runs fine. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dovecot 1.0 rc7 on FreeBSD 6.1-RELEASE/i386 with kqueue eats much CPU
Pete French пишет: I have a problem with dovecot eating sometimes up to 90% CPU. Are you using kqueue support ? I also had this problem and the solution for me was to recompile it without kqueue support. Now it runs fine. -pete. Yes, I'm using kqueue support. -- С уважением, Савчук Тарас ООО Элантек : Аутсорсинг ИТ, WEB-разработка http://www.elantech.ru +7 (495) 589 68 81 +7 (926) 575 22 11 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dovecot 1.0 rc7 on FreeBSD 6.1-RELEASE/i386 with kqueue eats much CPU
Yes, I'm using kqueue support. Try taking it out and the problem should go away. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Dovecot 1.0 rc7 on FreeBSD 6.1-RELEASE/i386 with kqueue eats much CPU
Hello Pete, Friday, September 22, 2006, 12:15:29 PM, you wrote: Yes, I'm using kqueue support. Try taking it out and the problem should go away. this is indeed a nice workaround (at least if it helps :-)), but somebody(tm) should have a look why the kqueue support is broken there in the first place. -pete. -- Best regards, Danielmailto:[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: Dovecot 1.0 rc7 on FreeBSD 6.1-RELEASE/i386 with kqueue eats much CPU
Daniel Gerzo пишет: Hello Pete, Friday, September 22, 2006, 12:15:29 PM, you wrote: Yes, I'm using kqueue support. Try taking it out and the problem should go away. this is indeed a nice workaround (at least if it helps :-)), but somebody(tm) should have a look why the kqueue support is broken there in the first place. -pete. I agree with you absolutely! Disabling kqueue on freebsd is not progressive way. -- С уважением, Савчук Тарас ООО Элантек : Аутсорсинг ИТ, WEB-разработка http://www.elantech.ru +7 (495) 589 68 81 +7 (926) 575 22 11 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: Dovecot 1.0 rc7 on FreeBSD 6.1-RELEASE/i386 with kqueue eats much CPU
this is indeed a nice workaround (at least if it helps :-)), but somebody(tm) should have a look why the kqueue support is broken there in the first place. I think it's a problem in Dovecot, not FreeBSD - there are a number of messages regarding this on the Dovecot lists, including a nunmber of attempts to fix the problem. OpenBSD also disables kqueue on their port of Dovecot due to it not working properly. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dovecot 1.0 rc7 on FreeBSD 6.1-RELEASE/i386 with kqueue eats much CPU
Pete French пишет: this is indeed a nice workaround (at least if it helps :-)), but somebody(tm) should have a look why the kqueue support is broken there in the first place. I think it's a problem in Dovecot, not FreeBSD - there are a number of messages regarding this on the Dovecot lists, including a nunmber of attempts to fix the problem. OpenBSD also disables kqueue on their port of Dovecot due to it not working properly. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] I can make additional tests of dovecot with kqueue if somebody gives me some tips what to do. -- С уважением, Савчук Тарас ООО Элантек : Аутсорсинг ИТ, WEB-разработка http://www.elantech.ru +7 (495) 589 68 81 +7 (926) 575 22 11 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Dovecot 1.0 rc7 on FreeBSD 6.1-RELEASE/i386 with kqueue eats much CPU
Hello Taras, Friday, September 22, 2006, 12:59:24 PM, you wrote: Pete French пишет: this is indeed a nice workaround (at least if it helps :-)), but somebody(tm) should have a look why the kqueue support is broken there in the first place. I think it's a problem in Dovecot, not FreeBSD - there are a number of messages regarding this on the Dovecot lists, including a nunmber of attempts to fix the problem. OpenBSD also disables kqueue on their port of Dovecot due to it not working properly. -pete. I can make additional tests of dovecot with kqueue if somebody gives me some tips what to do. if this is really a dovecot issue, I think that this topic should be moved to the dovecot's mailing list. -- Best regards, Danielmailto:[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: watchdogd_flags followed by panic watchdog timeout, after reboot my rc.conf disappear
Hello! On Sat, 2 Sep 2006, Daniel Dvo??k wrote: I saved my rc.conf without any doubt. I believe you, really ;) Answear: Because rc.conf had 0 Bytes !!! -rw-r--r-- 1 root wheel 6174 Sep 1 XX:XX rc.conf , I do not remember time of last modification of file. So the content of rc.conf was completly gone !!! Yes, because by default / is mounted in the following fashion: noasync Metadata I/O should be done synchronously, while data I/O should be done asynchronously. This is the default. - So yes, /etc/rc.conf will become empty if you're just edited it, and then, e.g., power disappears. It's a dangerous situation, because box becomes unreachable via network. To guard against it, you can just mount / using synchronous mode: syncAll I/O to the file system should be done synchronously. I've just modified my test machine's configuration in this way: /dev/ad0s3a / ufs rw,sync 1 1 and done several times edit /etc/rc.conf - power off/on sequence (no RESET key on box). The rc.conf is intact (while w/o sync it became empty after my second attempt). Note that this will further decrease FS performance for / (I always follow old good RELENG_4 advise NOT to turn softupdates on for / also). That's why /tmp and /var are separate partiotions (or just symlinks to SU-enabled /usr) in my typical setup. And please explain me somebody, how I lost the content of rc.conf file. :-O I hope I've just managed to do that ;) P.S.: I am not currently subscribed in the freebsd-stable mailling list, so use my e-mail address. I am ok with freebsd-current mailling list. I think my recipe would be more useful in -stable list (which IMHO is a must for reading by the production machines admins), that's why I'm sending to the -stable also. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: [EMAIL PROTECTED] nic-hdl: LYNX-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems with OpenVPN+routing and creating tun0 interface
Hi, I want to set up OpenVPN to create and configure tun0 interface and connect to OpenVPN server. The main obstacle seems to be my inability to configure either OpenVPN or FreeBSD to actually create that tun0 interface. If I try to create it manually I get this: $ ifconfig -v tun create inet 192.168.23.203 192.168.23.1 ifconfig: SIOCIFCREATE: Invalid argument The kernel config has the device tun line and there are tun[0-3] in /dev. So what am I doing wrong? -- Vaclav Haisman signature.asc Description: OpenPGP digital signature
Synaptics touchpad recognized as IntelliMouse
Hi I recently installed FreeBSD 6.1-RELEASE on my Compaq Presario 2656AU. It has a synaptics touchpad, but the mouse gets recognised as an IntelliMouse. http://www.studentergaarden.dk/~tim/FreeBSD/dmesg.txt It works, but the scroll area is way to wide, and button 6 and 7 gets activated if i scroll fast vertically. I tried commenting out all the IntelliMouse stuff in psm.c and rebuild. This resulted in the mouse being correctly recognised as a synaptics. Setting hw.psm.synaptics_support=1 and installing the synaptics X driver from ports in addition made the touchpad works perfectly. Tim Dettloff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
reboot on power button?
I'm setting up a PC-class machine to be used in an appliance-like setting. The people using it are far more likely to hit the power button then ctl-alt-del when they think it needs a restart (not often, but it may still happen). How do I tell ACPI to reboot when the power button is hit? Right now, I'm getting the expected sleep effect (S1 and S5 both work, suspending and shutting down respectively). I thought of installing a devd.conf entry, but it seems the event is intercepted beforehand. I need something like acpi_ibm's dev.acpi_ibm.0.events to pass the event over. Other approaches are also welcome. -- Dan Pelleg ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with OpenVPN+routing and creating tun0 interface
Václav Haisman wrote: Hi, I want to set up OpenVPN to create and configure tun0 interface and connect to OpenVPN server. The main obstacle seems to be my inability to configure either OpenVPN or FreeBSD to actually create that tun0 interface. If I try to create it manually I get this: $ ifconfig -v tun create inet 192.168.23.203 192.168.23.1 ifconfig: SIOCIFCREATE: Invalid argument The kernel config has the device tun line and there are tun[0-3] in /dev. So what am I doing wrong? -- Vaclav Haisman I always let OpenVPN create them for me. Just starting the openvpn process seems to do the magic. What happens when you try and do that? Thanks, Dominic ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installation of mico failed
On Fri, 22 Sep 2006, KAYVEN RIESE wrote: kayve# is root prompt kayve# uname -a FreeBSD kayve.domain_not_set.invalid 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:32:43 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 kayve# On Fri, 22 Sep 2006, KAYVEN RIESE wrote: here is a link i am asking help http://www.experts-exchange.com/Operating_Systems/FreeBSD/Q_21997654.html tried kayve# ./configure --with-qt=/usr/local/qt mico_config.log (kayve# is the root prompt) tried advice # cd /usr/ports/devel/mico # make install clean (# is the root prompt) got error === An older version of devel/glib12 is already installed (glib-1.2.10_11) You may wish to ``make deinstall'' and install this port again by ``make reinstall'' to upgrade it properly. If you really wish to overwrite the old port of devel/glib12 without deleting it first, set the variable FORCE_PKG_REGISTER in your environment or the make install command line. *** Error code 1 Stop in /usr/ports/devel/glib12. *** Error code 1 Stop in /usr/ports/devel/mico. *** Error code 1 Stop in /usr/ports/devel/mico. kayve# tried ^C kayve# make deinstall === Deinstalling for devel/mico === mico not installed, skipping kayve# make reinstall wait. (kayve# is the root prompt) tried kayve# cd /usr/ports/devel/glib12 kayve# make deinstall === Deinstalling for devel/glib12 === Deinstalling glib-1.2.10_11 pkg_delete: package 'glib-1.2.10_11' is required by these other packages and may not be deinstalled (but I'll delete it anyway): gtk-1.2.10_12 ORBit-0.5.17_2 openoffice-1.1.4_2 imlib-1.9.15_2 eboard-0.9.5_1 gtk-1.2.10_15 pkg_delete: '/usr/local/bin/glib-config' fails original MD5 checksum - deleted a nyway. pkg_delete: '/usr/local/libdata/pkgconfig/glib.pc' fails original MD5 checksum - deleted anyway. pkg_delete: '/usr/local/libdata/pkgconfig/gmodule.pc' fails original MD5 checksu m - deleted anyway. pkg_delete: '/usr/local/libdata/pkgconfig/gthread.pc' fails original MD5 checksu m - deleted anyway. === Deinstalling glib-1.2.10_12 pkg_delete: package 'glib-1.2.10_12' is required by these other packages and may not be deinstalled (but I'll delete it anyway): gtk-1.2.10_15 pkg_delete: file '/usr/local/man/man1/glib-config.1.gz' doesn't exist pkg_delete: file '/usr/local/bin/glib-config' doesn't exist pkg_delete: file '/usr/local/bin/glib12-config' doesn't exist pkg_delete: file '/usr/local/include/glib12/glib.h' doesn't exist pkg_delete: file '/usr/local/include/glib12/glibconfig.h' doesn't exist pkg_delete: file '/usr/local/include/glib12/gmodule.h' doesn't exist pkg_delete: file '/usr/local/libdata/pkgconfig/glib.pc' doesn't exist pkg_delete: file '/usr/local/libdata/pkgconfig/gmodule.pc' doesn't exist pkg_delete: file '/usr/local/libdata/pkgconfig/gthread.pc' doesn't exist pkg_delete: file '/usr/local/share/aclocal/glib.m4' doesn't exist pkg_delete: file '/usr/local/include/glib12' doesn't exist pkg_delete: unable to completely remove directory '/usr/local/include/glib12' install-info: warning: no entries found for `/usr/local/info/glib.info'; nothing deleted pkg_delete: file '/usr/local/info/glib.info' doesn't exist pkg_delete: couldn't entirely delete package (perhaps the packing list is incorrectly specified?) kayve# rectly specified?) kayve# pwd /usr/ports/devel/glib12 kayve# cd ../mico kayve# make install clean === Building for mico-2.3.11_3 for i in admin include; do gmake -C $i adm || exit 1; done gmake[1]: Entering directory `/usr/ports/devel/mico/work/mico/admin' gmake[1]: Nothing to be done for `adm'. gmake[1]: Leaving directory `/usr/ports/devel/mico/work/mico/admin' gmake[1]: Entering directory `/usr/ports/devel/mico/work/mico/include' gmake[1]: Nothing to be done for `adm'. gmake[1]: Leaving directory `/usr/ports/devel/mico/work/mico/include' for i in orb ir idl auxdir coss ccm; do gmake -C $i lib || exit 1; done gmake[1]: Entering directory `/usr/ports/devel/mico/work/mico/orb' gmake[1]: Nothing to be done for `lib'. gmake[1]: Leaving directory `/usr/ports/devel/mico/work/mico/orb' gmake[1]: Entering directory `/usr/ports/devel/mico/work/mico/ir' gmake[1]: Nothing to be done for `lib'. gmake[1]: Leaving directory `/usr/ports/devel/mico/work/mico/ir' gmake[1]: Entering directory `/usr/ports/devel/mico/work/mico/idl' gmake[1]: Nothing to be done for `lib'. gmake[1]: Leaving directory `/usr/ports/devel/mico/work/mico/idl' gmake[1]: Entering directory `/usr/ports/devel/mico/work/mico/auxdir' gmake[1]: *** No rule to make target `/usr/local/include/glib12/glib.h', needed by `gtkmico.o'. Stop. gmake[1]: Leaving directory `/usr/ports/devel/mico/work/mico/auxdir' gmake: *** [system] Error 1 *** Error code 2 Stop in /usr/ports/devel/mico. kayve# failture ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with OpenVPN+routing and creating tun0 interface
Václav Haisman wrote: Hi, I want to set up OpenVPN to create and configure tun0 interface and connect to OpenVPN server. The main obstacle seems to be my inability to configure either OpenVPN or FreeBSD to actually create that tun0 interface. If I try to create it manually I get this: $ ifconfig -v tun create inet 192.168.23.203 192.168.23.1 ifconfig: SIOCIFCREATE: Invalid argument The kernel config has the device tun line and there are tun[0-3] in /dev. So what am I doing wrong? -- Vaclav Haisman I had the same problem in 6.0 but not anymore in 6.1. If I remember correctly how I fixed it in 6.0, I just echoed null to /dev/tun0. But if you already have those devices I'm not sure anymore. Are you specifying the device in openvpn.con as dev tun or dev tun[n]? In 6.1 releng I have only dev tun and it creates the device by itself. But in OpenBSD I have to specify the device number also, even if there was just one of them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with OpenVPN+routing and creating tun0 interface
Václav Haisman wrote, On 22.9.2006 14:41: Hi, I want to set up OpenVPN to create and configure tun0 interface and connect to OpenVPN server. The main obstacle seems to be my inability to configure either OpenVPN or FreeBSD to actually create that tun0 interface. If I try to create it manually I get this: $ ifconfig -v tun create inet 192.168.23.203 192.168.23.1 ifconfig: SIOCIFCREATE: Invalid argument The kernel config has the device tun line and there are tun[0-3] in /dev. So what am I doing wrong? -- Vaclav Haisman The problme was on the server, it had my address restricted in firewall. I managed to make the tunnel. And I could ping the 192.168.23.1 address from mine 192.168.23.4. I had to restart the serivce because I did some changes to the OpenVPN client configuraton. Now I cannot ping again. But according to tcpdump the connection is there. And I cannot even ping mine 192.168.23.4. Missing routes or someting, after I restarted the serice? -- VH signature.asc Description: OpenPGP digital signature
bug on BTX
hello guys, sorry if i send email to wrong address. i have tested 6.2-BETA and the same problem still appear when i want to install it into compaq evo desktop; BTX HALTED. like previous version, it stucks when booting from cd on the first installation. i have follow so many discussion around the internet, and they are blaming compaq BIOS, some of them give solution such as change hdd mode from extended DMA to max PIO, but it won't work. and for your information, this machine had no problem when installed with windows or linux. please guys, i hope there will be a fixed on 6.2 so that it will load, installed, and run on my compaq evo desktop thank you cybersans ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
CyberSans AirBort wrote: hello guys, sorry if i send email to wrong address. i have tested 6.2-BETA and the same problem still appear when i want to install it into compaq evo desktop; BTX HALTED. like previous version, it stucks when booting from cd on the first installation. i have follow so many discussion around the internet, and they are blaming compaq BIOS, some of them give solution such as change hdd mode from extended DMA to max PIO, but it won't work. and for your information, this machine had no problem when installed with windows or linux. please guys, i hope there will be a fixed on 6.2 so that it will load, installed, and run on my compaq evo desktop Go into the BIOS, disable BIOS DMA transfers **. After that it will boot normally. I have about 20 EVOs, which this change they run fine. This is true of all versions of FreeBSD I have ever tried. ** I can't remember the exact name of the option, but it is something along those lines. Enjoy, Dominic thank you cybersans ___ 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: Problems with OpenVPN+routing and creating tun0 interface
At 10:22 AM 9/22/2006, Václav Haisman wrote: The problme was on the server, it had my address restricted in firewall. I managed to make the tunnel. And I could ping the 192.168.23.1 address from mine 192.168.23.4. I had to restart the serivce because I did some changes to the OpenVPN client configuraton. Now I cannot ping again. But according to tcpdump the connection is there. And I cannot even ping mine 192.168.23.4. Missing routes or someting, after I restarted the serice? Perhaps a better question to ask on the openvpn mailling list. But provide more details as to your config. One FreeBSD tip with openvpn that I find helpful is to specify which tun device to use-- especially if you have other tun users like ppp or pppoe, is to create a specific interface and tell openvpn to use it. On my boxes I do the following prior to starting up openvpn cat /dev/null /dev/tun101 and in openvpn, I tell it to use dev tun101 ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Problems with OpenVPN+routing and creating tun0 interface
Václav Haisman wrote: Hi, I want to set up OpenVPN to create and configure tun0 interface and connect to OpenVPN server. The main obstacle seems to be my inability to configure either OpenVPN or FreeBSD to actually create that tun0 interface. If I try to create it manually I get this: $ ifconfig -v tun create inet 192.168.23.203 192.168.23.1 ifconfig: SIOCIFCREATE: Invalid argument The kernel config has the device tun line and there are tun[0-3] in /dev. So what am I doing wrong? -- Vaclav Haisman I set up a new OpenVPN instance last week on FreeBSD 5.4-stable. The tun0 device was auto-created by OpenVPN when I ran the init script. (Of course it was in my kernel config first.) I just have 'dev tun' in my OpenVPN configuration file. To me, the funny thing is that I am running it on an older FreeBSD box because the Red Hat Enterprise 4 server I was given would not create a tun device whatever I did. Just like you I could not create it by hand or have OpenVPN do it. The OpenVPN server instance on the other side is a RHE4, and it worked automagically with no effort. I used the same software to install it on both RHE instances, so it is all a bit fishy. - Marius M. Rex Sr. System Admin Community Connect Inc. [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI issue with RELENG_6
Hi! With a recent RELENG_6 I've experienced what I suspect to be an ACPI issue. When powering down the system using `halt -p' I'm seeing a message like 'power off using ACPI' after the system has been shut down but the system does not power off. I've seen this yesterday with a csup'ed system as of yesterday and also today (csup'ed last night). I haven't had issues like that on this system before (using RELEASE-anything or an older RELENG_6 ACPI power off did work on that hardware). Following is my dmesg. If you need to see something more (like ACPI tables) please advise. Greetings, Volker Copyright (c) 1992-2006 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 6.2-PRERELEASE #11: Fri Sep 22 01:31:31 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BELLONA WARNING: debug.mpsafenet forced to 0 as i4b_ipr requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. ACPI APIC Table: AMIINT VIA_K7 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2400+ (1998.05-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x681 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc0400800SYSCALL,MMX+,3DNow+,3DNow real memory = 536805376 (511 MB) avail memory = 515727360 (491 MB) ioapic0 Version 0.3 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: AMIINT VIA_K7 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 8377 (Apollo KT400/KT400A/KT600) host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) ath0: Atheros 5212 mem 0xdffe-0xdffe irq 18 at device 10.0 on pci0 ath0: [GIANT-LOCKED] ath0: Ethernet address: 00:09:5b:89:7d:1f ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 ifpi0: AVM Fritz!Card PCI port 0xd400-0xd41f mem 0xdfffbfe0-0xdfffbfff irq 19 at device 11.0 on pci0 ifpi0: [GIANT-LOCKED] ifpi0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) ifpi0: passive stack unit 0 ahc0: Adaptec 29160N Ultra160 SCSI adapter port 0xd000-0xd0ff mem 0xdfffa000-0xdfffafff irq 16 at device 12.0 on pci0 ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs cbb0: RF5C475 PCI-CardBus Bridge at device 13.0 on pci0 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 atapci0: VIA 6420 SATA150 controller port 0xec00-0xec07,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc0f,0xd800-0xd8ff irq 20 at device 15.0 on pci0 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 atapci1: VIA 8237 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: ATA channel 0 on atapci1 ata1: ATA channel 1 on atapci1 uhci0: VIA 83C572 USB controller port 0xc000-0xc01f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xc400-0xc41f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: VIA 83C572 USB controller port 0xc800-0xc81f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: VIA 83C572 USB controller on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: VIA 83C572 USB controller port 0xcc00-0xcc1f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] usb3: VIA 83C572 USB controller on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: VIA VT6202 USB 2.0 controller mem 0xdfffbd00-0xdfffbdff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: VIA VT6202 USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered isab0: PCI-ISA bridge at device 17.0 on pci0 isa0: ISA bus on isab0 pci0: multimedia, audio at device 17.5 (no driver attached) vr0: VIA VT6102 Rhine II 10/100BaseTX port 0xb800-0xb8ff mem 0xdfffbc00-0xdfffbcff irq 23 at device 18.0 on
Re: bug on BTX
On 22 Sep Dominic Marks wrote: CyberSans AirBort wrote: i have tested 6.2-BETA and the same problem still appear when i want to install it into compaq evo desktop; BTX HALTED. Go into the BIOS, disable BIOS DMA transfers **. After that it will boot normally. I have about 20 EVOs, which this change they run fine. This is true of all versions of FreeBSD I have ever tried. Still remains the question on why FreeBSD is not able to boot when bios DMA transfers are set set to on, while XP and linux just do what they're supposed to. It should not be necessary i.m.h.o. -- dick -- http://nagual.nl/ -- PGP/GnuPG key: F86289CE ++ Running FreeBSD 6.1 +++ Solaris 10 6/06 ++ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
dick hoogendijk wrote: On 22 Sep Dominic Marks wrote: CyberSans AirBort wrote: i have tested 6.2-BETA and the same problem still appear when i want to install it into compaq evo desktop; BTX HALTED. Go into the BIOS, disable BIOS DMA transfers **. After that it will boot normally. I have about 20 EVOs, which this change they run fine. This is true of all versions of FreeBSD I have ever tried. Still remains the question on why FreeBSD is not able to boot when bios DMA transfers are set set to on, while XP and linux just do what they're supposed to. It should not be necessary i.m.h.o. Agreed. A very low priority however since it is so easy to work around. Dominic ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6 does not compile
I was a recent reporter of this, and after I started replaciing hardware to test, it turned out that I had a memory chip problem. 1 stick of ram removed, buildworld now works. brian On Thu, 21 Sep 2006, Kris Kennaway wrote: On Fri, Sep 22, 2006 at 02:59:53AM +0200, martinko wrote: Kris Kennaway wrote: On Fri, Sep 22, 2006 at 02:40:24AM +0200, martinko wrote: Kris Kennaway wrote: That doesn't provide any information since you used -j4. When posting errors from buildworld, you need to run without -j, or log the entire buildworld output and then figure out where the actual error occurred (may be thousands of lines from the end). Kris here it is again (without -j) : echo libssl.so.4: /usr/obj/usr/src/tmp/usr/lib/libcrypto.a .depend cc -O2 -fno-strict-aliasing -pipe -march=pentium-m -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libssl/../../../crypto/openssl -I/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libssl -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/bio_ssl.c cc -O2 -fno-strict-aliasing -pipe -march=pentium-m -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libssl/../../../crypto/openssl -I/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libssl -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c: In function `ssl23_connect': /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c:216: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Chances are you have failing hardware. Kris you must be kidding! :-o no, really, this is a laptop and i hope it's not going to die or something. :-/ well, it would actually be better now before the warranty is over. ;-) anyway, how did you come to your conclusion pls ?? Such errors are almost always the fault of failing hardware components; a functioning system does not cause sporadic software failure. This comes up about once a week so please search the archives or google for extensive discussion. Kris ___ 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: bug on BTX
On Fri, 22 Sep 2006 17:46:49 +0200 dick hoogendijk [EMAIL PROTECTED] wrote: Still remains the question on why FreeBSD is not able to boot when bios DMA transfers are set set to on, while XP and linux just do what they're supposed to. It should not be necessary i.m.h.o. What about filing a PR http://www.freebsd.org/send-pr.html, so the problem gets documented and eventually fixed? -- Ricardo Nabinger Sanchez [EMAIL PROTECTED],wait4.org} Powered by FreeBSD Left to themselves, things tend to go from bad to worse. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sed and comma-delimited file
On Fri, Sep 22, 2006 at 08:59:15AM +0200, Patrick M. Hausen wrote:
Hi, all!
On Tue, Sep 19, 2006 at 07:49:42PM -0400, Matt Emmerton wrote:
cat file | awk -F, '{ printf %s,%s,%s,%s,%s\n,$1,$2,$3,$4,$5 }'
newfile
What's wrong with this?
cat file | cut -f-5 -c';' newfile
Both commands suffer badly from useless use of cat(1) ;-))
See
http://sial.org/howto/shell/useless-cat/
for one of the dozens of explanations on the web.
I think the entire group of *nix users would benefit from
having a list of these kind of links. bRief tutorials
(that I have long since lost, BTW) on awk and sed, along
with things-related.
much else.
I'm saving all URL's, thanks ;-)
gary
SCNR,
Patrick
--
punkt.de GmbH Internet - Dienstleistungen - Beratung
Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100
76137 Karlsruhe http://punkt.de
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: Re: getopt_long and POSIXLY_CORRECT
Could a committer with interest in -stable, please, see to it, that Andrey's recent change to getopt_long makes it into 6.2-RELEASE? The change makes our implementation of getopt_long closer to GNULIB's and will make it easier to avoid code-duplication in some ports. Thanks! -mi -- Переслане повідомлення -- Subject: Re: getopt_long and POSIXLY_CORRECT Date: п'ятниця 22 вересень 2006 13:19 From: Andrey Chernov [EMAIL PROTECTED] To: Mikhail Teterin [EMAIL PROTECTED] Cc: bug-m4@gnu.org, bug-gnulib bug-gnulib@gnu.org, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] On Fri, Sep 22, 2006 at 01:10:51PM -0400, Mikhail Teterin wrote: п'ятниця 22 вересень 2006 13:04, Andrey Chernov написав: On Fri, Sep 22, 2006 at 01:22:42AM -0400, Mikhail Teterin wrote: The GNULIB folks are calling BSD's getopt_long implementation broken, because -- unlike theirs -- it respects the POSIXLY_CORRECT environment variable, when working with an opstring containing :: (signifying an optional value for a particular flag). Fixed in getopt_long.c v1.13 Thanks, Andrey. Please, make sure, the change gets into upcoming FreeBSD-6.2 too. I don't have any -stable machine conveniently available for testing. Feel free to MFC it after testing or ask someone else. -- http://ache.pp.ru/ --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Patch: sym(4) VTOBUS FAILED panics on amd64, amd64/89550
Scott Long schrieb: Jan Mikkelsen wrote: Hi, Doug White wrote: On Fri, 22 Sep 2006, Jan Mikkelsen wrote: Quick summary: sym(4) assumes on amd64 that virtual addresses provided by bus_dmamem_alloc() have the same alignment as the physical addresses (in this case, 2*PAGE_SIZE). They don't, and stuff breaks. This patch works around that. Why is this? busdma supports alignment constraints; why not just set the alignment to what you need it set at? I realize sym has its own hand rolled DMA management craziness but alignment is something busdma can take care of easily. sym has the alignment requirement on the virtual address because of the buddy memory allocation algorithm; changing how sym allocates memory internally would remove the requirement. The buddy algorithm with 2^13 bytes aligned on a 2^12 byte (but not a 2^13 byte) boundary can provide two chunks of 2^12 bytes but nothing greater than 2^12 bytes. The VTOBUS failure is caused by the buddy implementation making alignment assumptions which aren't true, and then getting the virtual addresses wrong. Perhaps I'm just doing something wrong with bus_dma. I believe I set the alignment requirements to be 2*PAGE_SIZE, and this is what I see for the physical address. However the virtual address seems to only be page aligned. I can't see any mention of virtual address alignment in the bus_dma man page. Can it take care of virtual address alignment? If so, how? busdma makes no guarantees on virtual addresses. Sigh, sorry I never got this fixed. The custom memory allocator made me unhappy, and I never had time to dig into it. Do real docs on sym exist somewhere? I'm not against sitting down and re-writing the physical memory handling to both work and conform to the FreeBSD APIs. I've been the co-author of the ncr SCSI driver, on which sym is based (though not that particular code fragment). Since I know the structure and principals of the driver (and since I have and know the docs up to the 53c875, possibly also the 53c895), I'd probably be in a position to work on this with the least effort to get started. Only problem is that I do not have an amd64 system for testing ... I changed the private allocator in the sym driver to use contigmalloc, some time ago, but now I understand that there are stricter alignment requirements. For a start, a work-around could be committed, IMHO (even if it is ugly). The better approach is of course an extension of busdma to support aligned physical chunks as required by the driver. But I could also try to find a clean fix for the affected driver code. Is the Symbios SCSI controller still used that much that the effort required for a clean fix is well spent? Regards, STefan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Patch: sym(4) VTOBUS FAILED panics on amd64, amd64/89550
Stefan Esser wrote: Scott Long schrieb: Jan Mikkelsen wrote: Hi, Doug White wrote: On Fri, 22 Sep 2006, Jan Mikkelsen wrote: Quick summary: sym(4) assumes on amd64 that virtual addresses provided by bus_dmamem_alloc() have the same alignment as the physical addresses (in this case, 2*PAGE_SIZE). They don't, and stuff breaks. This patch works around that. Why is this? busdma supports alignment constraints; why not just set the alignment to what you need it set at? I realize sym has its own hand rolled DMA management craziness but alignment is something busdma can take care of easily. sym has the alignment requirement on the virtual address because of the buddy memory allocation algorithm; changing how sym allocates memory internally would remove the requirement. The buddy algorithm with 2^13 bytes aligned on a 2^12 byte (but not a 2^13 byte) boundary can provide two chunks of 2^12 bytes but nothing greater than 2^12 bytes. The VTOBUS failure is caused by the buddy implementation making alignment assumptions which aren't true, and then getting the virtual addresses wrong. Perhaps I'm just doing something wrong with bus_dma. I believe I set the alignment requirements to be 2*PAGE_SIZE, and this is what I see for the physical address. However the virtual address seems to only be page aligned. I can't see any mention of virtual address alignment in the bus_dma man page. Can it take care of virtual address alignment? If so, how? busdma makes no guarantees on virtual addresses. Sigh, sorry I never got this fixed. The custom memory allocator made me unhappy, and I never had time to dig into it. Do real docs on sym exist somewhere? I'm not against sitting down and re-writing the physical memory handling to both work and conform to the FreeBSD APIs. I've been the co-author of the ncr SCSI driver, on which sym is based (though not that particular code fragment). Since I know the structure and principals of the driver (and since I have and know the docs up to the 53c875, possibly also the 53c895), I'd probably be in a position to work on this with the least effort to get started. Only problem is that I do not have an amd64 system for testing ... I changed the private allocator in the sym driver to use contigmalloc, some time ago, but now I understand that there are stricter alignment requirements. For a start, a work-around could be committed, IMHO (even if it is ugly). The better approach is of course an extension of busdma to support aligned physical chunks as required by the driver. But I could also try to find a clean fix for the affected driver code. Is the Symbios SCSI controller still used that much that the effort required for a clean fix is well spent? Regards, STefan What does the driver need that busdma doesn't provide now? bus_dmamem_alloc() is just a wrapper around contigmalloc. All alignment and exclusion arguments that you can give contigmalloc are honored by busdma. I guess that's what frustrated me when I looked at this driver; I couldn't figure out why all the effort had been made to have a custom allocator based on contigmalloc (which should be an interface hidden from most drivers and available only to the MD portion of the kernel, btw) when busdma works fine for nearly every other driver out there. I'm not being critical here, it's just that I couldn't figure out if there was some subtle detail that I was missing. If there are facilities that busdma doesn't provide but that you need, I'd be very happy to work with you on developing them. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ffs snapshot lockup
Yesterday we upgraded an amd64 system from 6.1 to 6.2-PRE from a cvsup of September 20 evening. The overnight nightly dump to tape went off normally. This afternoon when the sysadmin was performing the level0 backup, the ffs_mksnap program locked up the entire system. It wasn't the expected short hiccup that mksnap sometimes causes -- it was started just prior to lunchtime and when we got back everyone had wedged login sessions and IMAP sessions, and ffs_mksnap was in D state according to ps and idle for about 90 minutes. The only way out was to reboot the system. I know this is very un-useful as a bug report, but I'm putting this out in case anyone else has noticed this. It has never happened to us before when we were running 5.4 and then 6.1 on this box. Nothing else changed on the system during this time. The disk in question is on an adaptec RAID controller with the aac driver.
Re: ffs snapshot lockup
On Fri, Sep 22, 2006 at 02:55:34PM -0400, Vivek Khera wrote: Yesterday we upgraded an amd64 system from 6.1 to 6.2-PRE from a cvsup of September 20 evening. The overnight nightly dump to tape went off normally. This afternoon when the sysadmin was performing the level0 backup, the ffs_mksnap program locked up the entire system. It wasn't the expected short hiccup that mksnap sometimes causes -- it was started just prior to lunchtime and when we got back everyone had wedged login sessions and IMAP sessions, and ffs_mksnap was in D state according to ps and idle for about 90 minutes. The only way out was to reboot the system. I know this is very un-useful as a bug report, but I'm putting this out in case anyone else has noticed this. It has never happened to us before when we were running 5.4 and then 6.1 on this box. Nothing else changed on the system during this time. Yep, we'd need additional debugging to proceed. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6 does not compile
On Thursday 21 September 2006 18:20, Joerg Pernfuss wrote: On Fri, 22 Sep 2006 02:59:53 +0200 martinko [EMAIL PROTECTED] wrote: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Chances are you have failing hardware. Kris you must be kidding! :-o no, really, this is a laptop and i hope it's not going to die or something. :-/ well, it would actually be better now before the warranty is over. ;-) anyway, how did you come to your conclusion pls ?? SegFault 11 is normally a strong indicator of dying RAM. But in a laptop it could be related to heat such as a clogged heatsink or the equivalent. In one of my AMD desktop, I blew the dust out of the heat sink and the cpu temp dropped 5oC. There is a list of causes in the FAQ and they can all be the cause. Kent Joerg -- Kent Stewart Richland, WA http://www.soyandina.com/ I am Andean project. http://users.owt.com/kstewart/index.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ffs snapshot lockup
On Sep 22, 2006, at 3:03 PM, Kris Kennaway wrote: I know this is very un-useful as a bug report, but I'm putting this out in case anyone else has noticed this. It has never happened to us before when we were running 5.4 and then 6.1 on this box. Nothing else changed on the system during this time. Yep, we'd need additional debugging to proceed. How does one debug a system where the disk sub-system is frozen? I have serial console with DDB/KDB built into the kernel and debugging symbols too. Is that the only option here? We're gonna try the full level 0 backup again monday and if it locks up I'll try to figure it out, but could use some hints as to where to poke in the kernel.
Re: ffs snapshot lockup
On Fri, Sep 22, 2006 at 04:24:41PM -0400, Vivek Khera wrote: On Sep 22, 2006, at 3:03 PM, Kris Kennaway wrote: I know this is very un-useful as a bug report, but I'm putting this out in case anyone else has noticed this. It has never happened to us before when we were running 5.4 and then 6.1 on this box. Nothing else changed on the system during this time. Yep, we'd need additional debugging to proceed. How does one debug a system where the disk sub-system is frozen? I have serial console with DDB/KDB built into the kernel and debugging symbols too. Is that the only option here? Perhaps, but you can probably also take a dump still. It's a filesystem deadlock, not a disk device problem. We're gonna try the full level 0 backup again monday and if it locks up I'll try to figure it out, but could use some hints as to where to poke in the kernel. Start by enabling INVARIANTS, INVARIANT_SUPPORT, DEBUG_LOCKS and DEBUG_VFS_LOCKS, then run 'show lockedvnods' and 'alltrace' in DDB (spammy, need that serial console), or at least trace the running processes (show allpcpu) and those listed in lockedvnods. Then call doadump and save the core+kernel.debug when you reboot. Kris pgpxnqTnkvGrb.pgp Description: PGP signature
System Crash - Panic Page Fault
Good morning,
I was hoping someone may be able to help me debug my system. I'm currently
running FreeBSD 6.1 RELEASE.
Below is a partial kernel debug log of the crash.
Thanks for any assistance!
- Clayton
server1# kgdb kernel.debug /var/crash/vmcore.10
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x58
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc06e9e5b
stack pointer = 0x28:0xdf32cb18
frame pointer = 0x28:0xdf32cb34
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 = 99398 (ircd)
trap number = 12
panic: page fault
Uptime: 24d15h35m13s
Dumping 510 MB (2 chunks)
chunk 0: 1MB (160 pages) ... ok
chunk 1: 510MB (130544 pages) 494 478 462 446 430 414 398 382 366 350 334
318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc064dee1 in boot (howto=260) at ../../../kern/kern_shutdown.c:402
#2 0xc064e178 in panic (fmt=0xc088d24a %s) at
../../../kern/kern_shutdown.c:558
#3 0xc08424d4 in trap_fatal (frame=0xdf32cad8, eva=88) at
../../../i386/i386/trap.c:836
#4 0xc084223b in trap_pfault (frame=0xdf32cad8, usermode=0, eva=88) at
../../../i386/i386/trap.c:744
#5 0xc0841e79 in trap (frame=
{tf_fs = -1003880440, tf_es = -974913496, tf_ds = 40, tf_edi = 0,
tf_esi = 0, tf_ebp = -550319308, tf_isp = -550319356, tf_ebx = -550318960,
tf_edx = -550318704, tf_ecx = 0, tf_eax = 16, tf_trapno = 12, tf_err = 2,
tf_eip = -1066492325, tf_cs = 32, tf_eflags = 66183, tf_esp = -550319028,
tf_ss = 16})
at ../../../i386/i386/trap.c:434
#6 0xc08313da in calltrap () at ../../../i386/i386/exception.s:139
#7 0xc06e9e5b in ip_ctloutput (so=0x10, sopt=0xdf32cc90) at
../../../netinet/ip_output.c:1210
#8 0xc06f9e4f in tcp_ctloutput (so=0xc42a0590, sopt=0xdf32cc90) at
../../../netinet/tcp_usrreq.c:1038
#9 0xc06878ac in sosetopt (so=0xc42a0590, sopt=0xdf32cc90) at
../../../kern/uipc_socket.c:1560
#10 0xc068cb3d in kern_setsockopt (td=0xc4678300, s=528, level=16, name=16,
val=0xdf32cd90, valseg=UIO_USERSPACE, valsize=0)
at ../../../kern/uipc_syscalls.c:1351
#11 0xc068ca6e in setsockopt (td=0xc4678300, uap=0x10) at
../../../kern/uipc_syscalls.c:1307
#12 0xc08427eb in syscall (frame=
{tf_fs = 705036347, tf_es = 59, tf_ds = -1078001605, tf_edi =
141443072, tf_esi = -1077941380, tf_ebp = -1077941368, tf_isp = -550318748,
tf_ebx = 528, tf_edx = -1077941324, tf_ecx = 141344960, tf_eax = 105,
tf_trapno = 0, tf_err = 2, tf_eip = 673642671, tf_cs = 51, tf_eflags = 642,
tf_esp = -1077941428, tf_ss = 59}) at ../../../i386/i386/trap.c:981
#13 0xc083142f in Xint0x80_syscall () at ../../../i386/i386/exception.s:200
#14 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6 does not compile
On 9/21/06, martinko [EMAIL PROTECTED] wrote: Ruslan Ermilov wrote: On Thu, Sep 21, 2006 at 08:00:40PM +0200, martinko wrote: hello list, i've just pulled the releng_6 sources and run make -j4 buildworld as usual and this i've got: [...] I'm generally interested in fixing -jX build failures. I'd need at least the following info: - the contents of /etc/make.conf - exact make command - full output (combined stdout + stderr) available somewhere for download in a compressed form Cheers, ruslan, it seems to me it's not -jX fault this time. otherwise i could provide you the info you asked. pls see my latest post on this issue. In my admittedly limited experience: -j rarely breaks anything itself, but in most cases it makes posting the last few lines useless, as it can interpose hundreds (or thousands) of lines of output from concurrent compilations. -j may be slightly more likely to expose hardware problems. -- -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
