Problem Report kern/28418, problems with X in AMD mobos
Hi. I'm having some problems related to XFree86. I think that bug is not dead yet. Any try to make X work, will result in freeze or panic. "XFree86 -configure" results in an immediate system panic, startx results in a blank screen and a reset button press. Fortunately after searching google groups i found a trick that made X's problems stop. Inserting return; between these lines (in line 291+-): u_int cr4save; mrd = sc->mr_desc; so: u_int cr4save; return; mrd = sc->mr_desc; Is there any secondary effects for this ? The weird part, is that X was working 3-4 days before, problably X's problems start after a make world. I installed 4.6.2 and it was working fine, then after 1 or 2 world rebuilds, problems start to appear. I'm running STABLE AMD XP 2000 ASUS A7V333 - BIOS 1007 Abit G4 MX 440 Santos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Fanny Santos wants to connect to you on Yahoo!
http://us.i1.yimg.com/us.yimg.com/i/us/mash/gr/cnt-grd-1px.gif) 0 100% repeat-x;padding-left:3px;padding-top:6px;" valign="top" bgcolor="#F1F1F1" height="48"> http://us.i1.yimg.com/us.yimg.com/i/us/nt/b/ma_01.gif"; alt="Yahoo!" width="147" height="31"> Let's connect on Yahoo! http://profiles.yahoo.com/accept/I.ejmTiYK8zY_ZoGndxQPwReiM.aLUDMi5lGA1ge5t34rjgoWwq1VlVgbJDV?q=0";>http://us.i1.yimg.com/us.yimg.com/i/us/mash/gr/accept_button.png"; border="0" alt="Accept Invitation" width="235" height="33"> Connecting makes it easy to keep up with friends and family • You get automatically updated when I share stuff online - including my photos and reviews • You can see my profile on Yahoo! • You'll get earlier access to http://overview.mail.yahoo.com/whatsnew/smarterinbox";>cool new Yahoo! Mail features And much more coming soon! http://profiles.yahoo.com/accept/I.ejmTiYK8zY_ZoGndxQPwReiM.aLUDMi5lGA1ge5t34rjgoWwq1VlVgbJDV?q=0";>Click here to accept http://us.i1.yimg.com/us.yimg.com/i/us/mash/gr/photo_bg.gif) -6px -2px no-repeat;padding:5px;"> http://profiles.yahoo.com/u/DCEFZAFBVVJVJ5URVNPRIZ2W7Q";>http://l.yimg.com/us.yimg.com/i/identity/nopic_192.gif"; border="0" alt="" width="192" height="192"> http://profiles.yahoo.com/u/DCEFZAFBVVJVJ5URVNPRIZ2W7Q";>Fanny Santos (FannyS) This invitation will expire after 90 days. Want to control which emails you receive about your connections and your profile on Yahoo!? Go to: http://profiles.yahoo.com/settings/notifications";>http://profiles.yahoo.com/settings/notifications ___ 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"
I would like to help in the development and testing of FreeBSD
Hi, my name is Hugo Santos Dias, living in Brazil in Vitoria da Conquista, Bahia, I have great interest in helping in the development and testing of versions of FreeBSD, I use FreeBSD on my desktop and my servers. I am a student of computer science at the UESB - Universidade Estadual do Sudoeste da Bahia (State University of Southwest Bahia), and one of my projects is a path for ipfw, so that it can read data in layer-7 like iptables-layer7. I understand c/c++, shellscripts, perl, a bit of java (needed for the work of Discipline graphics computer - http://www.compenter.com.br/hugo/prova3/ - the link robo.htm). Working in a isp, wiress and via cable, and have deep knowledge of networks and tcp / ip. Please as do I to help in the development and testing of FreeBSD? I would like to help in the development and testing of FreeBSD -- Hugo S. Dias "Unix is user friendly. It's just selective about who its friends are." "Linux is for people who hate Windows. BSD is for people who love UNIX." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
/etc/daily.local and sim. never run
Hi, I just noticed that scripts in /etc/daily.local, /etc/weekly.local, etc, never run. The reason seems to be that the /etc/periodic/daily/999.local and similar scripts use "for script in $daily_local". Because the variable $daily_local is initialized in /etc/defaults/periodic.conf to /etc/daily.local, which actually does not contain a wildcard, the for loop step executes only once with the variable script bound to "/etc/daily.local". There's no iteration over scripts contained in /etc/daily.local. I have no idea when this might have gotten broken. The 999.local scripts date back to 2001. It's curious that no one has noticed. Perhaps most people just use the crontab or put their scripts directly into /etc/periodic/daily, etc. Anyway, scheduling things in crontabs and the like is not very good when the system is not always on. Since UNIX is no longer such a "time sharing system" and many people run desktops and part-time servers, wouldn't it be desirable to have a periodic job scheduling mechanism that would reliably run jobs when a given amount of time (uptime or not) had passed? Greetings, Miguel Ramos Lisboa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: File system is Full
Subject: Re: File system is Full > Thanks for you all. > /tmp & /home are separate slices. However, I noticed that mounting msdosfs > on another HD are sucking much of my FBSD HD. So I commented those on fstab > to free space . It seems that this situation was also connected with the > upgrade of OOo port which sucks much of HD. I would try growfs to add 10G > to my file system. > Thx again > Khaled Moussa Perhaps you could give us the output of the df command to see if there's anything unusual. Anyway, check if you have accounting_enable="YES" on /etc/rc.conf, and whether it might actually be /var which is full. Recently something very strange happened to me: accounting_enable="YES" somehow got into my /etc/rc.conf file and it ended up filling my /var filesystem which happens to be a condition just as serious as filling up /. Although this happened to me already two weeks ago, I take the occasion to ask the list: - Does anyone know of any reason, such as a port installation or a make installworld, that justifies that accounting_enable="YES" misteriously appeared on my /etc/rc.conf ? I know I didn't do it... I hate to admit I let it happen... and I have been blaming myself for having forgotten to disable password authentication on ssh to this machine... but maybe something else is to blame. Miguel Ramos, Lisboa. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make buildworld error
> Anyone else seeing make buildworld stop at usr.bin/netstat/ ? I didn't compile. That file was changed yesterday. But by the looks of it, everybody will be seeing it. The compiler is right because u_quad_t is not unsigned long long on the amd64, but only unsigned long, which although being the same size is a different type. Since I suspect changing the definition of __uint_64_t to unsigned long long on all platforms is probably out of the question (even though it could be argued to be preferrable, because ull is required to be at least 64b) as it would affect a lot of code, probably the author of the change will have to make a local workaround, such as casting the u_quad_t to ull or #ifdef... Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Disk Quota Support for FreeBSD Kernel
> From: "Chaminda Indrajith" <[EMAIL PROTECTED]> > > Warning: Can't find the `6.2-RELEASE-p4' distribution on this FTP > server. You may need to visit a different server for the release you > are trying to fetch or go to the Options menu and to set the release > name to explicitly match what's available on ftp.freebsd.org (or set > to "any"). > > Please help me to install kernel source and rebuild kernel. I think this would work, edit /usr/share/examples/cvsup/stable-supfile, or perhaps edit a copy of it in some directory of your own. Make sure you have edit these lines: *default host=CHANGE_THIS.FreeBSD.org *default release=cvs tag=RELENG_6 changing CHANGE_THIS to cvsup or cvsup4 or something near you, and tag=RELENG_6 to tag=RELENG_6_2. Check if you have the command csup installed, if you do, then do: # csup -L 2 stable-supfile If you don't, install the port cvsup and do: # cvsup -g -L 2 stable-supfile I think this will work. The directory /usr/src must already be created. This is for installing the sources for the full system... If you want only the kernel sources manually fetch using FTP the ssys.* files from the src directory of 6.2-RELEASE. Also fetch the install script, install.sh, on the same directory. Then run it :-) Oh... about building... see the handbook, I'm sure to forget some step. Miguel Ramos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can I do 6.1-RELEASE to 6.2 via cvsup
> From [EMAIL PROTECTED] Tue Oct 16 22:01:02 2007 > > I should just be able to change the TAG in standard-supfile from 6_1 to 6_2, > do a cvsup, and the builds etc to end up with 6.2-RELEASE right? > yes? no? Right. And back, you can change the tag back to 6_1... Or just RELENG_6 for 6-STABLE. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nautilus-cd-burner unable to prepare tracks for burning
Hi, I'm having problems burning CDs with nautilus-cd-burner. atapicam is ok, /etc/devfs.rules is ok, I can burn CDs with cdrecord. I can burn a CD after I have an image file with: nautilus-cd-burner --source-iso=... I can produce an image file by dropping everything into burn:/// and then selecting the image recorder. It's just when these two things are done together, nautilus-cd-burner stops leaving the message "Unable to prepare tracks for burning" in .xsession-errors. I imagine it has mkisofs running and some other process reading mkisofs' stdout. When it stops reporting this error, the image is already 100% done, but nautilus-cd-burner is still writing messages like 12% done, 40% done on .xsession-errors. It is as if it was taking too much time consuming mkisofs output. After it stops like this, I can take the image file which is perfect and burn it. I'm using /var/tmp for the image file, it is a hard disk. The only other place where I've found this error message was on some ubuntu mailing list, but the problem didn't seem to be the same. Did anyone else ever experienced this? What can be wrong? Thanks, Miguel -- .xsession-errors make_iso stderr: 4.18% done, estimate finish Sun Oct 28 00:25:50 2007 make_iso stderr: 5.58% done, estimate finish Sun Oct 28 00:25:50 2007 make_iso stderr: 6.97% done, estimate finish Sun Oct 28 00:26:04 2007 make_iso stderr: 8.36% done, estimate finish Sun Oct 28 00:26:01 2007 make_iso stderr: 9.76% done, estimate finish Sun Oct 28 00:26:00 2007 make_iso stderr: 11.15% done, estimate finish Sun Oct 28 00:25:58 2007 process stdout: EOF make_iso stderr: 12.54% done, estimate finish Sun Oct 28 00:25:57 2007 (nautilus-cd-burner:24967): WARNING **: Unable to prepare tracks for burning -- uname -a: FreeBSD satan.anjos.strangled.net 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #2: Sat Oct 27 23:45:33 WEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SATAN i386 -- dmesg: 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 6.3-PRERELEASE #2: Sat Oct 27 23:45:33 WEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SATAN Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ (2304.82-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60fb1 Stepping = 1 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 real memory = 1877934080 (1790 MB) avail memory = 1823158272 (1738 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi_hpet0: iomem 0xfefff000-0xfefff3ff on acpi0 Timecounter "HPET" frequency 2500 Hz quality 2000 acpi0: Power Button (fixed) acpi0: reservation of fefff000, 1000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 pcib3: at device 4.0 on pci0 pci3: on pcib3 nvidia0: mem 0xfc00-0xfcff,0xd000-0xdfff,0xfb00-0xfbff irq 16 at device 5.0 on pci0 nvidia0: [GIANT-LOCKED] pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 nfsmb0: port 0x4c00-0x4c3f,0x4c40-0x4c7f at device 10.1 on pci0 smbus0: on nfsmb0 smb0: on smbus0 nfsmb1: on nfsmb0 smbus1: on nfsmb1 smb1: on smbus1 pci0: at device 10.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02 at device 11.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 8 ports with 8 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff at device 11.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 8 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 8 ports with 8 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400-0xf40f at device 13.0 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x9f0-0x9f7,0xb
Re: date manupulation strangeness
> From: Holger Kipp <[EMAIL PROTECTED]> > > On Mon, Oct 29, 2007 at 01:35:08AM +0700, Eugene Grosbein wrote: > > On Sun, Oct 28, 2007 at 07:20:11PM +0100, Holger Kipp wrote: > > > > > > # unixtime=1193511599 > > > > # LC_ALL=C TZ=Asia/Krasnoyarsk date -jr $unixtime > > > > Sun Oct 28 02:59:59 KRAT 2007 > > > > Here it shows 'Sun Oct 28 02:59:59 KRAST 2007' really > > (cut-n-paste error, mea culpa). Take a note of zone name, > > KRAST stands for 'KRAsnoyarsk Summer Time' and > > KRAT stands for 'KRAsnoyarsk Time' (winter one). > > ah, I see. I can reproduce it here as well: > > %setenv LC_ALL C > %setenv TZ Asia/Krasnoyarsk > %setenv unixtime 1193511599 > > %date -jr $unixtime > Sun Oct 28 02:59:59 KRAST 2007 > %date -jf $s $unixtime > Sun Oct 28 02:59:59 KRAT 2007 > %date -juf %s $unixtime > Sat Oct 27 18:59:59 UTC 2007 > %date -jur $unixtime > Sat Oct 27 18:59:59 UTC 2007 This is a lot of fun! Bugs like this go unnoticed for years... It is also very exciting finding people at GMT+8. Mind you, we programmers who live at GMT+0 do a lot of timezone errors because we look at a time and often don't know whether it's localtime or gmt. At least I do. Then we only find out when we change to summer time. The problem is of course in src/bin/date.c, line 268. Someone added the following on revision 1.32.2.4: 267:/* Let mktime() decide whether summer time is in effect. */ 268:lt->tm_isdst = -1; Now, who's mktime() to know? This line is erasing the output of strptime(), and strptime() knows better than anyone what the user might have wanted! See my test source code bellow. date first fills up a tm structure using localtime(time(0)) so that the data which the user does not supply is extracted from the current time. Then, it calls strptime to parse the user time using these defaults. It's summarized in function test1() of my test code. Historically, the behaviour was just this (actually, like test2()). The person who added line 268, wanted to solve the problem of setting a date across DST, but the way he/she did it is not, in my opinion, the best. As we have discouvered, it does not work when the user supplies good DST data, because the line tm_isdst = -1 erases it. Now, what should perhaps be erased is the default dst data. So the line tm_isdst = -1 should be moved up to line 191, between localtime() and strptime(). The code would behave like my test3() function. See the test output (using LC_ALL=C and TZ=Asia/Krasnoyarsk): Test1 using %s: case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007 case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007 case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007 Test1 using %Y-%m-%d %H:%M:%S: case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007 case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007 case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007 Test2 using %s: case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007 case b Sun Oct 28 02:59:59 KRAST 2007 == Sun Oct 28 02:59:59 KRAST 2007 case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007 Test2 using %Y-%m-%d %H:%M:%S: case a Sun Oct 28 02:59:59 KRAST 2007 != Sun Oct 28 01:59:59 KRAST 2007 case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007 case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007 Test3 using %s: case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007 case b Sun Oct 28 02:59:59 KRAST 2007 == Sun Oct 28 02:59:59 KRAST 2007 case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007 Test3 using %Y-%m-%d %H:%M:%S: case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007 case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007 case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007 Historical behaviour is test2. It didn't work across DST when the user didn't supply DST data, but it did work fine for %s. The "correction", test1, introduced the error you've spotted, and that would only have been spotted by someone concerned with those two hours of each year... The solution I think its best works always that the user supplies DST data. Of course, it fails to guess dst status for test case b, but that's understandable, it can't guess. > Looks like one of the conversions is getting the > summertime-flag wrong here. > > I have tested this here with 6.2-STABLE from May 20... There's no point in naming the revision... the problematic line was introduced 6 years and 5 months ago by ru... Complete reference: src/bin/date.c Revision 1.32.2.4 Is ru around? Who fills in a pr for this? In summary, I think we should move line 268 to line 191 and erase the comment on line 267 (mktime() is no one to decide, strptime() must have the final word). Miguel Ramos Lisboa, Portugal #include #include #include time_t test1(const char* datestr, const char* form
Re: interface speed support
> From: "David Yeske" <[EMAIL PROTECTED]> > > Is there a way to determine the supported interface speed of a > particular driver? If I have a gigabit ethernet device connected to a > 100baseTX switch, how can I determine the interface supports gigabit > ethernet? I have tried parsing the following. Is there a cleaner way > to do this? > > sysctl -A | grep phy | grep desc I think using that line you're only checking what kind of phy device you have. If it is connected to a 100baseTX switch, it must be using 100baseTX. For controlling and querying the media type that you're actually using, you can use ifconfig media parameter. The actual value that this parameter accepts are device dependent but in practice quite standard like 100baseTX or 1000baseTX. say, ifconfig | grep media: Greetings, Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: date manupulation strangeness
> From: Holger Kipp <[EMAIL PROTECTED]> > > On Mon, Oct 29, 2007 at 01:35:08AM +0700, Eugene Grosbein wrote: > > On Sun, Oct 28, 2007 at 07:20:11PM +0100, Holger Kipp wrote: > > > > > > # unixtime=1193511599 > > > > # LC_ALL=C TZ=Asia/Krasnoyarsk date -jr $unixtime > > > > Sun Oct 28 02:59:59 KRAT 2007 > > > > Here it shows 'Sun Oct 28 02:59:59 KRAST 2007' really > > (cut-n-paste error, mea culpa). Take a note of zone name, > > KRAST stands for 'KRAsnoyarsk Summer Time' and > > KRAT stands for 'KRAsnoyarsk Time' (winter one). > > ah, I see. I can reproduce it here as well: > > %setenv LC_ALL C > %setenv TZ Asia/Krasnoyarsk > %setenv unixtime 1193511599 > > %date -jr $unixtime > Sun Oct 28 02:59:59 KRAST 2007 > %date -jf $s $unixtime > Sun Oct 28 02:59:59 KRAT 2007 > %date -juf %s $unixtime > Sat Oct 27 18:59:59 UTC 2007 > %date -jur $unixtime > Sat Oct 27 18:59:59 UTC 2007 This is a lot of fun! Bugs like this go unnoticed for years... It is also very exciting finding people at GMT+8. Mind you, we programmers who live at GMT+0 do a lot of timezone errors because we look at a time and often don't know whether it's localtime or gmt. At least I do. Then we only find out when we change to summer time. The problem is of course in src/bin/date.c, line 268. Someone added the following on revision 1.32.2.4: 267:/* Let mktime() decide whether summer time is in effect. */ 268:lt->tm_isdst = -1; Now, who's mktime() to know? This line is erasing the output of strptime(), and strptime() knows better than anyone what the user might have wanted! See my test source code bellow. date first fills up a tm structure using localtime(time(0)) so that the data which the user does not supply is extracted from the current time. Then, it calls strptime to parse the user time using these defaults. It's summarized in function test1() of my test code. Historically, the behaviour was just this (actually, like test2()). The person who added line 268, wanted to solve the problem of setting a date across DST, but the way he/she did it is not, in my opinion, the best. As we have discouvered, it does not work when the user supplies good DST data, because the line tm_isdst = -1 erases it. Now, what should perhaps be erased is the default dst data. So the line tm_isdst = -1 should be moved up to line 191, between localtime() and strptime(). The code would behave like my test3() function. See the test output (using LC_ALL=C and TZ=Asia/Krasnoyarsk): Test1 using %s: case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007 case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007 case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007 Test1 using %Y-%m-%d %H:%M:%S: case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007 case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007 case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007 Test2 using %s: case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007 case b Sun Oct 28 02:59:59 KRAST 2007 == Sun Oct 28 02:59:59 KRAST 2007 case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007 Test2 using %Y-%m-%d %H:%M:%S: case a Sun Oct 28 02:59:59 KRAST 2007 != Sun Oct 28 01:59:59 KRAST 2007 case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007 case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007 Test3 using %s: case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007 case b Sun Oct 28 02:59:59 KRAST 2007 == Sun Oct 28 02:59:59 KRAST 2007 case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007 Test3 using %Y-%m-%d %H:%M:%S: case a Sun Oct 28 01:59:59 KRAST 2007 == Sun Oct 28 01:59:59 KRAST 2007 case b Sun Oct 28 02:59:59 KRAT 2007 != Sun Oct 28 02:59:59 KRAST 2007 case c Sun Oct 28 02:59:59 KRAT 2007 == Sun Oct 28 02:59:59 KRAT 2007 Historical behaviour is test2. It didn't work across DST when the user didn't supply DST data, but it did work fine for %s. The "correction", test1, introduced the error you've spotted, and that would only have been spotted by someone concerned with those two hours of each year... The solution I think its best works always that the user supplies DST data. Of course, it fails to guess dst status for test case b, but that's understandable, it can't guess. > Looks like one of the conversions is getting the > summertime-flag wrong here. > > I have tested this here with 6.2-STABLE from May 20... There's no point in naming the revision... the problematic line was introduced 6 years and 5 months ago by ru... Complete reference: src/bin/date.c Revision 1.32.2.4 Is ru around? Who fills in a pr for this? In summary, I think we should move line 268 to line 191 and erase the comment on line 267 (mktime() is no one to decide, strptime() must have the final word). Miguel Ramos Lisboa, Portugal #include #include #include time_t test1(const char* datestr, const char* form
Re: date manupulation strangeness
> From: Mike Pritchard <[EMAIL PROTECTED]> > [...] > DST/CST time changes when setting the time backwards has been at your > own risk for a long time. Yes, but there's really not much reason for it to be so much of a black art. Actually, I think the old behaviour, prior to rev 1.36, although not ideal was quite reasonable: it interpreted the user supplied date in the current time zone, say winter time, even though it refered to a period of summer time. It was that change that introduced a behaviour which IMHO must be regarded as a bug. > Back in 1995/6 when I fixed a lot of utilities to enforce the password > expiration date/time, I found it was off by +/- 1 hour if I was setting > dates and times that would cross DST changes. Not a big deal then, > but I think I got them all to work correctly. Well, the line of code I objected to is not that old. CVS blames someone called ru on revision 1.36 who committed changes submitted by Crist Clark in 2001. > But if I recall correctly, if you wanted to really test those type of > changes by setting the system date/time back, it was better to set > the date/time to a period well before the DST change, verify the system > understood it was in the proper time zone (probably a reboot), > THEN move the clock up to just before the DST time change and let it > roll over. There's not much point in doing that in this case, is there? All that is at stake here is if date translates from user supplied dates into a time_t in a predictable/justifiable manner. If it does/doesn't, rebooting and letting time pass won't do much good. The reason why I think that that must be seen as a bug is that date gave surprising results in a case where the user provided unmistakable input. Allow me to recall Eugene Grosbein / Holger Kipp's test case: > %setenv LC_ALL C > %setenv TZ Asia/Krasnoyarsk > %setenv unixtime 1193511599 > > %date -jr $unixtime > Sun Oct 28 02:59:59 KRAST 2007 > %date -jf %s $unixtime > Sun Oct 28 02:59:59 KRAT 2007 As you can see, the input to date is unmistakable, it is a time_t. The difference is that the second case forces date to use strptime() and the first doesn't. date is not outputing only the timezone wrong, those two dates are one hour appart. That means that in the first date is understanding 1193511599, and that in the second, at one point in its execution, date is understanding 1193615199, one hour latter. Trust me or add a printf to line 273. The line which is the cause for this misinterpretation is line 268. Before that line was introduced, behaviour was justifiable, although not ideal. If the user supplied unmistakable input, either a time_t or a date with explicit timezone, it worked, and when the user supplied date without timezone it always understood the date in the current timezone. This only had the inconvenient of +1/-1 when done across DST, but at least it wouldn't throw away the information supplied by the user. This line also makes date misinterpret full dates with timezone, not only time_ts for that limbo hour. In my opinion, we can have a bugless date for the limbo hour, and still solve the +1/-1 inconvenient simply by not destroying strptime()'s output. All it takes is to move 268 to line 191, as I said before. Of course, I don't think this is a critical or prioritary issue, not at all. It was only fun, because I could look into it in a half hour. But the kludge to solve the +1/-1 inconvenient is there and is ugly. Greetings Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Float problen running i386 inary on amd64
> From: Pete French <[EMAIL PROTECTED]>
>
> Hi, I have a very simple program:
>
>
> int
> main(int argc, char *argv[])
> {
> if(atof("3.2") == atof("3.200"))
> puts("They are equal");
> else
> puts("They are NOT equal!");
> return 0;
> }
>
>
> This works as expected on both i386 and amd64. But if I take the compiled
> binary from the i386 system and run it on the amd64 system thenit says they
> are not equal! I thought this was a library problem, but it even happens if
> I compile to a static binary, which would preseumably mean the same code is
> running on both systems.
>
> I am using 6.3-PRERELEASE here
Unfortunately, I didn't have the luck of having it reproduced here.
Maybe because my i386 is on 7.0, different compiler (although the amd64 is
still on RELENG_6).
Since you've rulled out everything else by building a static binary,
did you try using the new C99 functions in fenv.h related to the
floating-point environment?
Miguel Ramos
Lisboa, Portugal
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ifconfig with rc.conf Broken
> From: James Wyatt <[EMAIL PROTECTED]> > Subject: Re: Ifconfig with rc.conf Broken > > Don't alias interfaces have to be added to the "network_interfaces=" line? > I thought only "real" interfaces were autodetected... I don't think this is the case. It shouldn't be... But MC can test that using ifconfig -l > On Mon, 20 Feb 2006, MC wrote: > > From: MC <[EMAIL PROTECTED]> > > Subject: Ifconfig with rc.conf Broken > > > > Bizarre behavior with configuring the main interface IP with rc.conf: > > > > ifconfig_bge0="inet 10.0.0.15 netmask 0xff00" > > ifconfig_bge0_alias0="inet 10.0.0.16 netmask 0x" # Sample alias > > entry. > > defaultrouter="10.0.0.10" > > > > Doesn't configure the bge0 interface! But: > > > > ifconfig bge0 10.0.0.8 netmask 0x alias > > > > works fine in rc.local. Also configuration from command line in > > multiuser mode works fine, although I notice messages about bge0 going > > down, then another about it coming back up upon adding the main IP > > I apparently have identical behavior from another machine with an fxp0 > > interface, from 6.1-PRERELEASE cvsuped on Sunday I have 6.1-PRERELEASE #3, compiled on Feb 14, and it works for me... I have: ifconfig_fxp0="inet 192.168.0.2 netmask 255.255.255.0" ifconfig_fxp0_alias0="inet 192.168.0.1 netmask 255.255.255.255" try ifconfig -l ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Remote tunefs -n enable
> From [EMAIL PROTECTED] Wed Feb 22 09:33:12 2006 > Date: Tue, 21 Feb 2006 23:07:36 -0800 > From: MC <[EMAIL PROTECTED]> > To: freebsd-stable@freebsd.org > Subject: Remote tunefs -n enable > > Hello again > > I have another issue on the same box. The bloke who installed FreeBSD 6.0onto > the machine is a linux man. He didn't know about softupdates nor apparently > does > he know yet about option 4 [read only singule user mode] on the bootloader. > > Consequently he hasn't set softupdates on the main '/' partition It wasn't his fault. It is the default install option. You see, root is mainly a read file system. Typical writes are a kernel install (not too important to optimize) and updating configuration files (it shouldn't be so often). Therefore there isn't much need to optimize / with softupdates. Furthermore, if one can avoid any risky operation on /, all the better. I think that's why the option for / is using synchronous writes without softupdates (not that softupdates are risky, but really they're not much use). > On Freebsd 4.x from ssh2 I used to: > > mount -fr /dev/ad0s1a / > tunefs -n enable /dev/ad0s1a > mount /dev/ad0s1a / > > but attempting this on FreeBSD 6.x immediately locks up the machines when in > multiuser mode. Locks up? That's weird... Perhaps ssh doesn't like it?... Do you have separate /tmp and /var partitions? > On a workstaion I then tried to sneak tunefs into the first lines of > /etc/rc. Unfortunately it seems that > '/' is read/write mounted before /etc/rc runs, so the tunefs just makes an > error and the box boots up > again without softupdates. My question then is how to go about getting the > tunefs line in a startup > script, before the disk is mounted read/write and with realtime access only > in multiuser mode by telnet/ssh2. > > Or perhaps there is another means, this being BSD? I think the filesystem must be unmounted to enable softupdates. Draw your own conclusions. But don't do that unless you have good reason for it. / is a mainly read filesystem. It won't be under heavy write load. On FreeBSD disks are commonly partitioned according to the usage profile, not so common on Linux default installations. That's why separate / /tmp /var /usr and possibly /usr/local, etc. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rip2 ospf: freebsd 6.0
> From [EMAIL PROTECTED] Fri Feb 24 09:48:08 2006 > Date: Fri, 24 Feb 2006 10:47:18 +0100 > From: [EMAIL PROTECTED] > To: freebsd-stable@freebsd.org > Subject: rip2 ospf: freebsd 6.0 > > hi liste > > I'm looking for a dynamic routing (rip2, ospf) solution under freebsd > 6.0. currently, I've always known zebra which exists in freebsd ports > collection. do have a better idea? If RIPv2 is enough, there's routed in the base distribution. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS locking question
> So, rpc.lockd _is_ needed on the client? > What about the statement in rc.conf(5) then, claiming it was > only started on servers? Yes rpc.lockd and rpc.statd are needed on the client. I suspect it's the statements in rc.conf(5) that are wrong. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
> > 1- Only one client machine of all I have, the only one which is remote > > booted, hangs on startup with rpc.lockd/rpc.statd enabled. > > Just to verify: lockd is enabled on BOTH client AND server? > > Kris Oh yes. If any of the daemons is not enabled on both machines there's no locking, there's no system hang and all that occurs is: can't open or create /var/run/cron.pid: Operation not supported. which is ok, of course, although it's a pitty that it can't work without locking. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
> OK, thanks. Please try to obtain a tcpdump -vvv trace of the broken > operation. > > Kris Will you help me? I've been trying to use tcpdump -vvv on this but I get either a lot of trash or nothing. Which ports should I dump? So far I tried running on the server # tcpdump -vvv 'host and (udp port lockd or udp port sunrpc)' This gets me nothing. When I try nfs ports I get lots of trash, since all filesystems in this client are nfs mounted from this server. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
> OK, thanks. Please try to obtain a tcpdump -vvv trace of the broken > operation. > > Kris I have it. I had just to disable cron startup, which was the only daemon that used pidfile_open and started after statd/lockd, and then start it by hand. Now, perhaps it is better to post it off-list, since it is 69kB for -vvv or 196kB for -X -vvv. Are you willing to look at the dump yourself? Anyone? BTW, cron was left in an unkillable state, it couldn't be killed with SIGKILL. In the meanwhile, I'll try to revert lib/libutil/pidfile.c to Jan 1st, which is my suspect. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
> Can you put it at a URL somewhere? If not, send it privately. > > Kris Ok. There are two versions: http://mega.ist.utl.pt/~mlsr/nfs.dump is the output of tcpdump -vvv host targa and udp port nfs http://mega.ist.utl.pt/~mlsr/nfsx.dump is the output of tcpdump -X -vvv host targa and udp port nfs - targa.anjos.strangled.net is the name of the client which has a single / filesystem (therefore including /var) nfs mounted from the server. - compaq.anjos.strangled.net is the name of the server. Dump begins when I do /etc/rc.d/cron start, after system is fully functional in multiuser mode, lockd and statd running. File locking seems to work in other situations, specifically for instance touch test ; lockf test echo ok. After checking the revision history for lib/libutil/pidfile.c, I'm convinced that it can't be the problem, and the same for usr.sbin/cron/cron.c, even though there was a change at 2006/01/15, and this setup seemed to work before January. Another thing, I didn't start this thread, and I hope I'm not moving attention away from the original post from Jun Kuriyama who was asking for help debugging a documented PR (bin/80389). Miguel Ramos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can't boot into setup to install FreeBSD 6
> From: Benjamin Sher <[EMAIL PROTECTED]> > Subject: Re: Can't boot into setup to install FreeBSD 6 > > Dear Miguel: > > Thank you so very much for trying to help. My answers below: > > > I think this is a bit off-topic on this list, but of course I'd like to > > help. > > I don't think this can be a 'software issue', this must be the BIOS > > (firmware). > > > > 1- Did you change your keyboard, or is your keyboard not well connected? > >I once had a keyboard which had a long reset time and sometimes was not > >detected. Try different keyboards, check the plugs. > > > First, my thanks for explaining that this is a BIOS issue. Does this > mean that it is a HARDWARE issue? The BIOS is a program which is stored in a Read-Only Memory (ROM). It is the Basic Input/Output System that among other things boots your OS. It is often called firmware for being a bit in between software and hardware. Anyway, seems not to be a Windows-related problem. > I did change my keyboard some months ago. I changed my keyboard from a > Belkin ergonomic keyboard to a Microsoft ergonomic keyboard when I > arrived in Knoxville. But I had this problem before in New Orleans with > my old keyboard. The Setup got jammed sometimes last fall for some > inexplicable reason and has never worked right since. Well, trying different keyboards is my best bet on this issue. > > 2- Are you pressing F2 at the right time? Try keeping F2 pressed as soon as > >you power on, keep it pressed. > > > > Believe me, I press F2 the moment boot starts and keep hitting it > throughout the boot process. On the other hand, I can stop the boot > process with F12. Never heard of a key to stop the boot process... Does't that really boot from the CD? Perhaps the CD player is not very good with CD-Rs... and the system boots from the hard disk... > > I don't think removing the CMOS battery can help in this case. Your problem > > seems surreal. There's a chance that removing the CMOS battery for a while and then placing it back again restores your BIOS Setup to its default settings, and then it may boot from the CD. But you should ask someone who is experienced with opening up computers to do that operation. Also, this may be a risky operation, and may be useless. > Thank you again. > > Benjamin I'm really out of ideas. Do try different keyboards, borrow a few. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
> From: Kris Kennaway <[EMAIL PROTECTED]> > Subject: Re: rpc.lockd brokenness (2) > > > Ok. There are two versions: > > http://mega.ist.utl.pt/~mlsr/nfs.dump > > is the output of tcpdump -vvv host targa and udp port nfs > > http://mega.ist.utl.pt/~mlsr/nfsx.dump > > is the output of tcpdump -X -vvv host targa and udp port nfs > > Hmm, looks like you need -s 0 in addition to -X -vvv. There. http://mega.ist.utl.pt/~mlsr/nfsxs.dump I did just cron, instead of /etc/rc.d/cron start. It has much less garbage now. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
> From: Kris Kennaway <[EMAIL PROTECTED]> > Subject: Re: rpc.lockd brokenness (2) > [...] > but there's no evidence in the trace that it ever tries to write. Can > you also obtain a ktrace -i dump from cron? The file remains empty. I really don't know enough about NFS, but isn't that getattr message repeated some seconds latter, and repeated... (even though it always gets an answer) The ktrace is in http://mega.ist.utl.pt/~mlsr/ktrace.txt I'm not sure it's good. I can't see cron.pid there. I had to reboot to end the process, otherwise I couldn't kill cron and the trace didn't grow either. > Also while you're there, could you obtain a binary format tcpdump > (tcpdump -w) instead? This may be parsed with tools like ethereal > which will help with the analysis. The tcpdump -w is in http://mega.ist.utl.pt/~mlsr/nfs.bin Thank you Miguel Ramos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Remote Installworld
> From: "Nick Price" <[EMAIL PROTECTED]> > Subject: RE: Remote Installworld > > >I'm currently administering a machine about 1500mi from me with nobody > >local to the machine to assist me. Anyways, my only access to this > >machine is via SSH, no remote serial console or anything. > >When I try to do a "make installworld" I end up with > >install: rename: /lib/[EMAIL PROTECTED] to /lib/libcrypt.so.3: Operation > > not > >permitted > >very shortly thereafter. I cannot boot into single user mode because > >I am far, far away from the machine. What can I do to finish the > >installworld? > >Thanks > >Nick > > > >VHCS Webmail > > The securelevel wouldn't allow me to change the flag. > > Thanks anyways > Nick Is it really the securelevel? I had a similar problem on a diskless machine, file flags couldn't be changed through NFS, so I had to remove the schg flags on the server. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
> From: Kris Kennaway <[EMAIL PROTECTED]> > Subject: Re: rpc.lockd brokenness (2) > > I wonder if something else is going wrong and it's not rpc.lockd at > all. Oh, it's a locking problem alright. But perhaps not in rpc.lockd... > It looks like this wasn't made using -s 0 - sorry if I wasn't > explicit. You must give all details to rookies... I've changed things a bit, but perhaps there's a test now which is more easily reproducible on other systems. The following tcpdumps were obtaining by booting in single-user mode on the diskless machine and doing the following sequence for initialization: # mount -u / # /etc/rc.d/netif start # /etc/rc.d/rpcbind start # /etc/rc.d/nfsclient start # /etc/rc.d/nfslocking start And then, with /var/run/cron.pid removed, # /etc/rc.d/cron start Starting cron. # /etc/rc.d/cron stop # /etc/rc.d/nfslocking stop # /etc/rc.d/nfsclient stop # /etc/rc.d/rpcbind stop # reboot see http://mega.ist.utl.pt/~mlsr/nfs-nofile.bin Everything seemed to be ok, but /var/run/cron.pid was left locked on the server. Then, with /var/run/cron.pid still locked, # /etc/rc.d/cron start ... cron already running (pid=111).. something like that, which is ok # /etc/rc.d/cron stop # reboot see http://mega.ist.utl.pt/~mlsr/nfs-lockedpass.bin The result of this test is ok, but when booting multiuser, cron still hangs instead of saying it's already running, and, when I checked if /var/run/cron.pid was still locked, for accident on a third machine with # lockf -k -t 1 .../var/run/cron.pid echo ok lockf hung on this third machine, in spite of -t 1 parameter, it remained unkillable. With /var/run/cron.pid still locked, on the first client, single-user, same initialization sequence # lockf -k -t 1 /var/run/cron.pid echo ok Hangs... always. see http://mega.ist.utl.pt/~mlsr/nfs-lockfhang.bin (this tcpdump is quite big, perhaps it included loading the kernel) Now, given this, since the hang also occurs with lockf, I tried another test, on a different machine (the one that's called dual). The tcpdump was done on the server: tcpdump -s 0 -w nfs-other.bin host dual and udp port nfs Now, two vts on the client, in the first, this sequence: # mkdir test # mount compaq:/x1 test # touch test/lock-file ; lockf -k -t 1 test/lock-file sh # On the second vt, # lockf -k -t 1 test/lock-file echo ok it hung. Tried ^C. still hung. On the first vt, # exit On the second vt, lockf had returned to prompt. The tcpdump is on http://mega.ist.utl.pt/~mlsr/nfs-other.bin The output of uname -a on the client (dual) is: FreeBSD dual 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Tue Mar 7 18:03:35 WET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DUAL i386 and on the server (compaq) is: FreeBSD compaq 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #3: Tue Feb 14 13:04:11 WET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COMPAQ i386 Please try also what I did, two vts on a client, trying to lock the same file on the server with lockf. The description of the problem that I have becomes increasingly similar to what is in pr bin/80something. Greetings, Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
> From: Kris Kennaway <[EMAIL PROTECTED]> > Subject: Re: rpc.lockd brokenness (2) > > This is intentional. It's how pidfile_*() tests whether the process > is still running. The intention is that if someone tries to open the > pidfile again while the first process is still running, the lock > acquisition will fail and we'll know the other process is still alive, > and therefore avoid starting a second instance. No, no, you got me wrong. The pidfile is left locked after cron stopped running (with /etc/rc.d/cron stop). This behaviour must be wrong. > Your main problems seems to be that you're mounting the same /var via > NFS from multiple client machines. This is basically a bad idea to > begin with because /var expects to be private to each machine (even if > locking worked as expected, you'd not be able to start cron on more > than one machine because it would fail as above). Even if you solved > this there would be other similar problems. No, it's the whole filesystem tree for a single client, no one else uses those files. The fact that I hung a third machine was an accident, I was testing if cron.pid was still locked and I thought I had a window on the server... My single problem is locking. Actually, it worked well before I upgraded this system to 6-STABLE. It's just for one laptop whose disk I don't want to partition. > In fact the diskless boot infrastructure in /etc will set up and use a > md /var for this purpose. Actually, they don't advise using an md /var, only /etc. Anyway, I don't use that, because it's my only diskless machine. I have a single NFS mounted / and an md /tmp. There's nothing shared with no one else, not even /usr, because it's my only amd64. > There is a (known) lockd bug here though, which you isolated: > So, this really is bin/80389? If so, I can tell Jun Kuriyama that his patch didn't change it. > > With /var/run/cron.pid still locked, on the first client, single-user, sa= > me > > initialization sequence > > # lockf -k -t 1 /var/run/cron.pid echo ok > > Hangs... always. > > which is that lock requests through rpc.lockd cannot be cancelled, so > they'll hang until the operation succeeds or fails. In this case > lockf does a blocking lock request and expects to cancel it with a > signal after the timer expires, but rpc.lockd doesn't know how to back > out lock requests so it just hangs forever or until something else > unlocks the file on the server. > > Kris I am a bit disappointed. First, this problem didn't cause me trouble before I went to 6-STABLE, now I must either disable cron or disable locking (which I can't). And I'm still not completely convinced. That problem, if I understand correctly, existed before January... There are two things... - cron.pid shouldn't be locked after cron terminated. (this interaction was fully saved as http://mega.ist.utl.pt/~mlsr/nfs-nofile.bin) - cron shouldn't hang on startup just because the file is locked, since pidfile_open opens it with O_NONBLOCK (unlike lockf). - cron shouldn't hang in such a way that it is not killable... (and should not also the open system call in lockf be interruptible?) So, I'm led to believe that beyond that issue with rpc.lockd, which, I understand, is an unresolved problem, there is now another problem, perhaps with pidfile.c... Thank you for all your time on this issue. I'm still going to try to chase it, although I only have the knowledge to find it if it is on pidfile.c or in cron. I understand little of the interaction between kernel and the rest of nfs to chase it if it is somewhere else. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
> From: Kris Kennaway <[EMAIL PROTECTED]> > Subject: Re: rpc.lockd brokenness (2) > [...] > OK, I misunderstood. The rc.d script will signal cron to kill it, > which should be closing the file descriptors and causing rpc.lockd to > release the lock. Perhaps this part is broken. OK, I tested this > with daemon -p, and it indeed seems to be broken: > > haessal# daemon -p pid_file sleep 10 > haessal# kill -KILL `cat pid_file` > haessal# ps -p `cat pid_file` > PID TT STAT TIME COMMAND > haessal# lockf -t 0 pid_file echo Yay > lockf: pid_file: already locked Well, your test is quite terse, but perhaps that is more expectable with SIGKILL, but the same thing happens with SIGTERM. On the other hand, what happens there is not so strange, since neither pidfile.c nor daemon.c has any signal handling, and that should probably be expected. Perhaps it's impossible that a lock could be released just because it's owned by a process that dyed, it's the limitations of distributed services... But. cron should have pidfile_remove in it's signal handlers, and it should have a signal handler for SIGTERM for this purpose. I must see the pre-pidfile cron. [...] > > - cron shouldn't hang on startup just because the file is locked, since > > pidfile_open opens it with O_NONBLOCK (unlike lockf). > > I haven't been able to reproduce this, e.g. lockf -t 0 does O_NONBLOCK > locking and works correctly when the file is already locked. Perhaps > it's another locked file (not the pidfile) that was also leaked in the > same way, and is being opened without O_NONBLOCK. > > > - cron shouldn't hang in such a way that it is not killable... (and should > > not also the open system call in lockf be interruptible?) > > This is the bug (really: missing feature) that I described in my > previous mail. Shouldn't even a lock that is opened without O_NONBLOCK be interruptible by a signal? I don't understand why or how are these things unkillable. They did a system call, they're supposed to be inside the kernel, how can rpc.lockd, a user process keep them there... Another thing, I have a question that maybe you can answer. I'm having trouble getting rid of the lock on cron.pid, and, in the end, that's why I can't boot normally. The lock persists even though the file is not "physically" locked on the server. I've tried stopping nfslocking on both sides and removing both /var/db/statd.status. Is there any other persistent storage for this? Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
> From: Kris Kennaway <[EMAIL PROTECTED]> > > The bug is triggered because the file is locked in the parent > (i.e. the daemon process, which creates the pidfile) but unlocked by > the child after the fork (in this case, when the child is killed). On > the server, rpc.lockd compares the svid (=3D pid of process on the > client that is doing the lock call) of the lock and unlock requests, > notices they're different and assumes that the unlock request is > coming from some random process on the client that didn't hold the > lock in the first place. > > In reality, the file descriptor was passed from parent to child by the > fork(), and the child does actually hold the lock. Thank you. That is a very good explanation. > Fixing this is probably hard (also: I can't see how this could have > ever worked with pidfile locking in cron, since it always acquired the > lock before forking, as now. Perhaps something else about your > configuration changed.). Because the lock is somehow persisting through reboots, even though I stop nfslocking, remove /var/db/statd.status and restart it... > Anyway, the workaround for you is probably not to use rpc.lockd on > your NFS mounted /var (e.g. use mount_nfs -L). Since you don't have > multiple machines accessing this filesystem (which wouldn't work > anyway, as noted before), you don't need it anyway. > > Kris Oh yes, I must try that again. I had problems in the past with using the -L option, gnome didn't run. Probably it was because it was a single / filesystem mounted on boot and the option on fstab was ignored, I must try it again. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
> From: Kris Kennaway <[EMAIL PROTECTED]> > Subject: Re: rpc.lockd brokenness (2) > > Yeah, the file is still locked on the server, and will never be > unlocked unless you stop and restart the rpc.lockd on the server > (which releases all the locks it holds). I did that. Lots of times. And I removed /var/db/statd.status too when the daemons where not running. Is there any other file involved? No. There is a problem with rpc.lockd besides the other one. This machine hangs even when I lock files with lockf -t 0 that never existed, with fresh statd/lockd on client AND server (if /var/db/statd.status is the only file involved). > > > Oh yes, I must try that again. I had problems in the past with using the = > -L > > option, gnome didn't run. Probably it was because it was a single / files= > ystem > > mounted on boot and the option on fstab was ignored, I must try it again. > > You can use the -o lockd form in /etc/fstab. The -L option works in fstab, it is just not honored for mount -u /... -o lockd is actually the opposite of -L, if the manpage is correct. But the reason that gnome didn't start back then was because I stopped running lockd, since I used -L, and forgot that the home directory was a different mount through amd. Anyway, this problem is no longer important. I separated /usr and /var, and now the -L option is honored for them. But I will always need a shared home directory for which statd/lockd should be running... and it's not working on this machine... it always hangs now when I acquire some lock (not in single user mode though). I tried for the first time locking a file on a different server and it hung too. These are files that never existed. And this problem happens only on this diskless machine, whereas the other problem, the one that occurs on files that are already locked, happens on all machines. If I keep using a common home directory for all machines, and keep using lockd for that mount on that machine, then my only workaround is still to go back to 6.0-RELEASE. Miguel BTW, thank you for your support. And they talk about technical support on fatly payed operating systems... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
> Can you try to narrow down this problem some more? e.g. look up the > port used by rpc.lockd with rpcinfo on client and server and tcpdump > to see what locking requests are being passed back and forth (you > should see the request from client -> server and the reply granting > the lock; or not if something is going wrong). The ethereal port is > useful for parsing the tcpdump -w -s 0 traces, btw; it decodes the RPC > packets into human-readable form. In the meanwhile, since my last mail, I've had some trouble finding out the port that's used using rpcinfo. Using rpcinfo made me remember a few things about rpc (I used it only once, some 6 years ago). I've found out the right udp port by eliminating other options. I will try to narrow the circumstances of this, if only to file a pr about it. But tomorrow... It's almost 4am here, and almost 11pm there... If you can in the meanwhile send me a message explaining how to find out the right udp port quickly, it will set me up faster tomorrow. > Running rpc.lockd -d100 on the server is also useful for tracking down > what it's doing (look in /var/log/debug.log) Yes, that will be easier. > > If I keep using a common home directory for all machines, and keep using > > lockd for that mount on that machine, then my only workaround is still to > > go back to 6.0-RELEASE. > > I'm not certain 6.0-RELEASE is any different, since I don't see any > changes to rpc.lockd or nfs locking that were made since then. Yes, I had also checked that earlier today. I don't know if I did something that could have caused this... I'm almost sure it worked on 6.0 (although not completely, because I only got this machine working with 6 recently, it had a problem with ehci). There's no doubt it was working with 5-something. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/local/etc/rc.d script problem
> From: victoria <[EMAIL PROTECTED]> > Subject: /usr/local/etc/rc.d script problem > > Hi to everyone! > > Seems i got a small problem with my startup scripts. I have record > in /etc/rc.conf: local_startup="/usr/local/etc/rc.d" You shouldn't need that option, since the default value in /etc/defaults/rc.conf already includes that directory. Unless there is another reason... > And a few scripts in this directory. Normal configuration. On all > servers it works great except one. I don't know where is a problem is, > because it is identical configuration. But seems system is ignoring > these scripts. It doesn't start any script from this directory. > Maybe someone can give me an advice where is a problem is? > > Thanks! > > Victoria The information you're giving is perhaps not enough. Are you sure you have *_enable="YES" in rc.conf for each script you want to run? Check rc.conf, rc.conf.local and the scripts, and if you're unable to find out what's wrong, post them. It may also be useful if you tell us what version of FreeBSD are you running. Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rpc.lockd brokenness (2)
> I did some further testing and it turns out that rpc.lockd is broken > in some cases when operating over NFSv2 (this is the default for nfs > root mounts). > > Tracing the lock traffic I see the client making a request, the server > replying but the client never acting on the reply (or never receiving > it), so it just retransmits every 20 seconds forever. That is what I saw Friday, using the debug log mainly. I was expecting to find some error message, but I only saw the repetition of something that seemed to be ok. I tried vainly to look into rpc.lockd but it's not at all simple. But my greatest frustration was than when I started rpc.lockd with -d on the client, the problem did never occur. It didn't occur to me that the difference between this and other clients was that the diskless mount is NFSv2. I can't be 100% sure that the problem I have is the same you observed, but locking works on this client on other mounts (home directories through amd, NFSv3). It really seems an NFSv2 specific issue. > I'm not yet sure whether this is a regression in 6.x or another case > that was broken forever. I didn't have problems in 5. I just compiled a 6.0-RELEASE kernel, and it is also broken. > Unfortunately there's currently no option to use NFSv3 for nfs root > mounts to work around this (unless you're using bootp), but it should > just be a trivial matter of adding "| NFSMNT_NFSV3" to the flags in > nfsclient/nfs_diskless.c:nfs_setup_diskless(): > > nd->root_args.flags = (NFSMNT_WSIZE | NFSMNT_RSIZE | NFSMNT_RESVPORT); It was only today that I could try your sugestion. But... I get a kernel panic, it can't find init... Looking is nfsclient/bootp_subr.c, it looks like there's a little more to do when mounting via NFSv3. Well, this doesn't work, but thanks to your sugestion, by looking in nfs_diskless.c, I found a loader option to disable lockd, boot.nfsroot.options=lockd. This option is new (it doesn't exist on 6.0). Now I can lock any file not only on /var, but also on /etc, etc. (remember this option in fstab wasn't honored for the root mount) Everything works. Locking in shared home directories also work, because they're NFSv3 mounts (I tried it already...). So, I finally have it working, and all I needed was having this in loader.conf: boot.nfsroot.options=lockd. I'm quite tired of this issue, so, for all I'm concerned, I'm done. Is the NFSv2/rpc.lockd issue reported? Is there any information more that I can provide? I'm available for further information and testing if anyone can't reproduce the bug. I'm glad you could, no daemons on my machine... I failed finding a way to reproduce it on other machines using mount_nfs -2, so aditional assistance may be needed to the developers. If the problem is reported and no further information is needed from me, then I can only thank you and congratulate you for your great effort in understanding what was wrong and pointing a way to work around it. Thank you, Kris, Miguel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
On Tue, Sep 21, 2010 at 8:39 AM, Andriy Gapon wrote: [...] > If you want to shape the future of the project, then participate in the places > where the future is shaped. If you want to know what's coming up in the > future, > then watch the places where the future is shaped. If you don't do either, > you get > what you get. Complaining post factum just doesn't work. (Numerous other > examples and projects also demonstrate that). Stop feeding the troll, please. ___ 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: Audio CD problem on laptop VGN-SZ61MN
On Fri, Aug 8, 2008 at 5:13 AM, Harald Weis <[EMAIL PROTECTED]> wrote: > Is there anyone out there who has installed FreeBSD on the above Sony > laptop ? > > Both ''cat filename > /dev/dsp0.0'' or ''vlc cdda:///dev/[EMAIL PROTECTED] > are OK. > > If I run ''cdcontrol -f /dev/acd0 play'', there is no sound. > But the output of ''cdcontrol -f /dev/acd0 status audio'' is alright. > (same behaviour for cd0 instead of acd0) > > And the output of ''mplayer cdda://1//dev/acd0'' is: > Playing cdda://1//dev/acd0. > ++ WARN: open: Inappropriate ioctl for device > **ERROR: fread (): Invalid argument > > On the other hand, DVD's play fine, for example with > either ''vlc dvd:///dev/[EMAIL PROTECTED]'' or ''mplayer dvd://2'' > > I wonder whether the problem is related to the FAILURE line in dmesg: > acd0: DVDR at ata0-master UDMA33 > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > cd0 at ata0 bus 0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 33.000MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present > > Adding ''device atapicam'' in the kernel doesn't make a difference. > > I found some messages concerning the FAILURE line in the mailing list > archives, but no solution. Same result on my notebook (HP nx6320) and this is not a surprise. The "mixer" command does not show a "cd" input, meaning that there is no input port for the analog audio output of the CD drive (if any). The "status audio" arguments instructs cdcontrol to inquire the drive, not the audio device. NetBSD's "cdplay" supports digital transfer mode since version 4.0. Perhaps this feature could be implemented on cdcontrol. -- If you think things can't get worse it's probably only because you lack sufficient imagination. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Audio CD problem on laptop VGN-SZ61MN
On Sat, Aug 9, 2008 at 11:03 AM, Harald Weis <[EMAIL PROTECTED]> wrote: > On Fri, Aug 08, 2008 at 09:17:40PM -0300, Carlos A. M. dos Santos wrote: >> On Fri, Aug 8, 2008 at 5:13 AM, Harald Weis <[EMAIL PROTECTED]> wrote: > >> > acd0: DVDR at ata0-master UDMA33 >> > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 >> > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 >> > cd0 at ata0 bus 0 target 0 lun 0 >> > cd0: Removable CD-ROM SCSI-0 device >> > cd0: 33.000MB/s transfers >> > cd0: Attempt to query device size failed: NOT READY, Medium not present > >> Same result on my notebook (HP nx6320) and this is not a surprise. The >> "mixer" command does not show a "cd" input, meaning that there is no >> input port for the analog audio output of the CD drive (if any). The >> "status audio" arguments instructs cdcontrol to inquire the drive, not >> the audio device. >> >> NetBSD's "cdplay" supports digital transfer mode since version 4.0. >> Perhaps this feature could be implemented on cdcontrol. > > Yes, that explains what happens on my notebook and corresponds to > what the Handbook says: > If all goes well, you should now have a functioning sound card. If your > CD-ROM or DVD-ROM drive's audio-out pins are properly connected to your > sound card, you can put a CD in the drive and play it with > cdcontrol(1): > % cdcontrol -f /dev/acd0 play 1 > > Indeed, both the 'mixer' command and the (much more comfortable) 'rexima' > port show only 5 mixer devices: > Mixer vol is currently set to 12:12 > Mixer pcm is currently set to 30:30 > Mixer speaker is currently set to 8:8 > Mixer mic is currently set to 0:0 > Mixer rec is currently set to 0:0 > > There is no 'cd' mixer device, and the only mixer device file on > this notebook is '/dev/mixer0'. > > But this does not explain why mplayer, in contrast with vlc, refuses > to play the CD, does it ? No, doesn't. On my notebook I'm able to play audio CDs with mplayer using either your command syntax, "mplayer cdda://1//dev/acd0" and with the simpler one "mplayer cdda://1". The audio is bad, however (has periodic interruptions). This is certainly a problem in mplayer since GXine works fine. > What is the meaning and reason of the above FAILURE lines ? > 2 identical lines with the GENERIC kernel, > 1 single line, if I add 'device atapicam'. I doubt atapican has something to do with your problem but you can check this by booting with GENERIC and issue "kldload atapicam" later. I did it here and had no additional problem with mplayer besides the bumpy audio output. I guess your problem is in the CD drive. I suggest you to do three things: 1. Try to insert the CD and wait until it stops pinning before starting mplayer. Some drives are a bit lazy on media recognition. 2. Run "truss mplayer ..." and look for error messages. 3. Attempt to use a different player. Xine and/or one of its alternate front-ends like GXine or Kaffeine are good choices. -- If you think things can't get worse it's probably only because you lack sufficient imagination. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Inspiron 1525 Hardware
On Thu, Sep 4, 2008 at 3:22 PM, Stephen Montgomery-Smith <[EMAIL PROTECTED]> wrote: > Gavin Atkinson wrote: >> >> On Thu, 2008-09-04 at 11:32 -0600, Dan Allen wrote: >>> >>> On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote: >>> This is supported by the iwn(4) driver in CURRENT, and it should be quite easy to port the driver to 7-STABLE. If you're interested in reinstalling FreeBSD and testing a backported driver, I'm sure this can be sorted. >>> >>> I am interested in doing this. Please advise on how I can get these >>> bits. >> >> I've got hold of a laptop with the 4965 chipset in it, if nobody beats >> me to it I'll have a go at backporting the driver. > > I have a Dell Inspiron 1525 with the intel wireless ethernet. > > The iwn driver in CURRENT works well. > > The http://people.freebsd.org/~yongari/msk/msk.88E8040.patch patch for the > 88E8040 simply doesn't work. It is not because of lack of testing (which I > have performed for Pyun who wrote the patch), but apparently because of lack > of reliable documentation. There is a driver for FreeBSD on the Marvell web > site, which did work for me, but I am told it is unreliable. > > I also have had a hard time getting the sound to work. The oss port does > work, but has a habit of freezing up. Did you try using Alexander Motin's new snd_hda patches? They are available at http://people.freebsd.org/~mav/ -- cd /usr/ports/sysutils/life make clean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Inspiron 1525 Hardware
On Thu, Sep 4, 2008 at 7:31 PM, Stephen Montgomery-Smith <[EMAIL PROTECTED]> wrote: > Carlos A. M. dos Santos wrote: > >> Did you try using Alexander Motin's new snd_hda patches? They are >> available at >> >> http://people.freebsd.org/~mav/ >> > > Thanks. I hadn't tried them. But they didn't work. (I used the Sept 4 > patch on CURRENT.) > > I could provide more diagnostics if anyone wants to work to make it work. Stephen, I'm pretty sure that Alexander would appreciate your help and bug reports. So I suggest you to move this discussion to freebsd-multimedia, the list in which the new driver has been discussed. -- cd /usr/ports/sysutils/life make clean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can't see non-root writes to /dev/console
On Wed, Sep 10, 2008 at 5:34 PM, Jeff Blank <[EMAIL PROTECTED]> wrote: > I just upgraded a RELENG_7 (amd64) box from 20080714 to "latest" > (which seems to be from a few days ago--no changes from Monday > morning's csup to today's) and can no longer see the effect of writing > to /dev/console as non-root. When I log in using xdm, my user owns > /dev/console, mode 0622 (-rw--w--w-), and I start an 'xterm -C'. But > when I, for example, > > echo foo > /dev/console > > I see nothing in the console xterm. No error messages, and echo exits > 0. If I su to root and do the same, I get 'foo' in the same console > xterm. Syslog messages to /dev/console also appear, of course. All > the above applies to xconsole as well, not just xterm. I did > recompile xterm from 20080616 ports, but it didn't fix the issue > (didn't expect it to, as xterm clearly has no trouble attaching and > reading). So my echo is getting lost in the kernel, I guess. > > Known problem? Intentional change? Something else? I have seen this problem since 6.x times and still on 7.x. I also noticed that if I send something to the console after xconsole starts then I can sned messages as an ordinary user. My workaround was modifying the Xsetup_0 script (I used xdm for login), adding a line with (sleep 3; date >> "$dev_console") & just after starting xconsole. I didn't have time to set up a machine with 8-CURRENT yet, so I could not check if the new mp-safe tty implementation fixes this, either intentionally or by a fortunate side effect. -- cd /usr/ports/sysutils/life make clean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can't see non-root writes to /dev/console
On Wed, Sep 10, 2008 at 10:54 PM, Carlos A. M. dos Santos <[EMAIL PROTECTED]> wrote: > On Wed, Sep 10, 2008 at 5:34 PM, Jeff Blank <[EMAIL PROTECTED]> wrote: >> I just upgraded a RELENG_7 (amd64) box from 20080714 to "latest" >> (which seems to be from a few days ago--no changes from Monday >> morning's csup to today's) and can no longer see the effect of writing >> to /dev/console as non-root. When I log in using xdm, my user owns >> /dev/console, mode 0622 (-rw--w--w-), and I start an 'xterm -C'. But >> when I, for example, >> >> echo foo > /dev/console >> >> I see nothing in the console xterm. No error messages, and echo exits >> 0. If I su to root and do the same, I get 'foo' in the same console >> xterm. Syslog messages to /dev/console also appear, of course. All >> the above applies to xconsole as well, not just xterm. I did >> recompile xterm from 20080616 ports, but it didn't fix the issue >> (didn't expect it to, as xterm clearly has no trouble attaching and >> reading). So my echo is getting lost in the kernel, I guess. >> >> Known problem? Intentional change? Something else? > > I have seen this problem since 6.x times and still on 7.x. I also > noticed that if I send something to the console after xconsole starts > then I can sned messages as an ordinary user. My workaround was > modifying the Xsetup_0 script (I used xdm for login), adding a line > with > > (sleep 3; date >> "$dev_console") & > > just after starting xconsole. > > I didn't have time to set up a machine with 8-CURRENT yet, so I could > not check if the new mp-safe tty implementation fixes this, either > intentionally or by a fortunate side effect. > > -- > cd /usr/ports/sysutils/life > make clean What happens if you use xconsole -f /dev/console ? -- cd /usr/ports/sysutils/life make clean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Would anybody port DragonFlyBSD's HAMMER fs to FreeBSD?
On Tue, Sep 30, 2008 at 8:53 PM, lhmwzy <[EMAIL PROTECTED]> wrote: > I think port HAMMER fs to FreeBSD is easier than any other fs like ZFS. > Would anybody do this? > I do not have the skill or I will do this.:) > links: http://www.dragonflybsd.org/hammer/index.shtml > http://www.dragonflybsd.org/hammer/hammer.pdf > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > Do you subscribe freebsd-stable? This has bee discussed recently in this list: http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045506.html -- cd /usr/ports/sysutils/life make clean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can't see non-root writes to /dev/console
On Wed, Sep 10, 2008 at 11:54 PM, Carlos A. M. dos Santos <[EMAIL PROTECTED]> wrote: > On Wed, Sep 10, 2008 at 5:34 PM, Jeff Blank <[EMAIL PROTECTED]> wrote: >> I just upgraded a RELENG_7 (amd64) box from 20080714 to "latest" >> (which seems to be from a few days ago--no changes from Monday >> morning's csup to today's) and can no longer see the effect of writing >> to /dev/console as non-root. When I log in using xdm, my user owns >> /dev/console, mode 0622 (-rw--w--w-), and I start an 'xterm -C'. But >> when I, for example, >> >> echo foo > /dev/console >> >> I see nothing in the console xterm. No error messages, and echo exits >> 0. If I su to root and do the same, I get 'foo' in the same console >> xterm. Syslog messages to /dev/console also appear, of course. All >> the above applies to xconsole as well, not just xterm. I did >> recompile xterm from 20080616 ports, but it didn't fix the issue >> (didn't expect it to, as xterm clearly has no trouble attaching and >> reading). So my echo is getting lost in the kernel, I guess. >> >> Known problem? Intentional change? Something else? > > I have seen this problem since 6.x times and still on 7.x. I also > noticed that if I send something to the console after xconsole starts > then I can sned messages as an ordinary user. My workaround was > modifying the Xsetup_0 script (I used xdm for login), adding a line > with > > (sleep 3; date >> "$dev_console") & > > just after starting xconsole. > > I didn't have time to set up a machine with 8-CURRENT yet, so I could > not check if the new mp-safe tty implementation fixes this, either > intentionally or by a fortunate side effect. I took some time to look at this again. I'm using 8.0-CURRENT now (GENERIC kernel), csup'ed and compiled yesterday. Xconsole is unable to open the console even if my user & group own /dev/console and the permissions are set to 0622. This happens because of the following code in xconsole.c: 289 int on = 1; 290 if (ioctl (tty_fd, TIOCCONS, (char *) &on) != -1) 291 input = fdopen (pty_fd, "r"); The ioctl call fails (EPERM) because only superuser can use TIOCCONS, regardless the ownership of the device. Using xterm with the "-C" argument works because xterm is installed with the setuid flag bit on. So the solution is "chmod +us xconsole". -- cd /usr/ports/sysutils/life make clean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can't see non-root writes to /dev/console
On Mon, Oct 13, 2008 at 3:23 AM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Mon, Oct 13, 2008 at 03:16:37AM -0200, Carlos A. M. dos Santos wrote: >> On Wed, Sep 10, 2008 at 11:54 PM, Carlos A. M. dos Santos >> <[EMAIL PROTECTED]> wrote: >> > On Wed, Sep 10, 2008 at 5:34 PM, Jeff Blank <[EMAIL PROTECTED]> wrote: >> >> I just upgraded a RELENG_7 (amd64) box from 20080714 to "latest" >> >> (which seems to be from a few days ago--no changes from Monday >> >> morning's csup to today's) and can no longer see the effect of writing >> >> to /dev/console as non-root. When I log in using xdm, my user owns >> >> /dev/console, mode 0622 (-rw--w--w-), and I start an 'xterm -C'. But >> >> when I, for example, >> >> >> >> echo foo > /dev/console >> >> >> >> I see nothing in the console xterm. No error messages, and echo exits >> >> 0. If I su to root and do the same, I get 'foo' in the same console >> >> xterm. Syslog messages to /dev/console also appear, of course. All >> >> the above applies to xconsole as well, not just xterm. I did >> >> recompile xterm from 20080616 ports, but it didn't fix the issue >> >> (didn't expect it to, as xterm clearly has no trouble attaching and >> >> reading). So my echo is getting lost in the kernel, I guess. >> >> >> >> Known problem? Intentional change? Something else? >> > >> > I have seen this problem since 6.x times and still on 7.x. I also >> > noticed that if I send something to the console after xconsole starts >> > then I can sned messages as an ordinary user. My workaround was >> > modifying the Xsetup_0 script (I used xdm for login), adding a line >> > with >> > >> > (sleep 3; date >> "$dev_console") & >> > >> > just after starting xconsole. >> > >> > I didn't have time to set up a machine with 8-CURRENT yet, so I could >> > not check if the new mp-safe tty implementation fixes this, either >> > intentionally or by a fortunate side effect. >> >> I took some time to look at this again. I'm using 8.0-CURRENT now >> (GENERIC kernel), csup'ed and compiled yesterday. Xconsole is unable >> to open the console even if my user & group own /dev/console and the >> permissions are set to 0622. This happens because of the following >> code in xconsole.c: >> >> 289 int on = 1; >> 290 if (ioctl (tty_fd, TIOCCONS, (char *) &on) != -1) >> 291 input = fdopen (pty_fd, "r"); >> >> The ioctl call fails (EPERM) because only superuser can use TIOCCONS, >> regardless the ownership of the device. Using xterm with the "-C" >> argument works because xterm is installed with the setuid flag bit on. >> So the solution is "chmod +us xconsole". > > Can someone security audit this program before blindly setuid-root'ing > it? Doing it on my own notebook is not a major concern. The idea of making it a general solution puts me nervous too. Xconsole itself is very simple application but it uses a bunch of X libraries that may have their own security issues. OTOH, xterm uses the same libraries, and even more. -- cd /usr/ports/sysutils/life make clean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can't see non-root writes to /dev/console
On Mon, Oct 13, 2008 at 6:05 PM, Edwin Groothuis <[EMAIL PROTECTED]> wrote: > On Sun, Oct 12, 2008 at 10:23:53PM -0700, Jeremy Chadwick wrote: >> > The ioctl call fails (EPERM) because only superuser can use TIOCCONS, >> > regardless the ownership of the device. Using xterm with the "-C" >> > argument works because xterm is installed with the setuid flag bit on. >> > So the solution is "chmod +us xconsole". >> >> Can someone security audit this program before blindly setuid-root'ing >> it? > > Isn't xconsole not just the same values as /var/log/messages ? > > So information-leaking-wise it isn't a huge deal. Only the program > itself is now the unknown. > > Edwin > -- > Edwin Groothuis Website: http://www.mavetju.org/ > [EMAIL PROTECTED] Weblog: http://www.mavetju.org/weblog/ The OpenBSD folks solved the permission issue along time ago(*) by means of a privilege separation feature. Take a look at http://www.openbsd.org/cgi-bin/cvsweb/xenocara/app/xconsole/ I will see if is possible to update the xconsole port in order to do the same. Is there any standard privilege separation framework on FreeBSD? (*) http://openbsd.monkey.org/tech/200302/msg00064.html -- cd /usr/ports/sysutils/life make clean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7_1: Laptop mouse (psm0) disappeared??!?
On Wed, Nov 26, 2008 at 6:50 AM, Peter Jeremy <[EMAIL PROTECTED]> wrote: > On 2008-Nov-25 12:09:07 -0800, David Wolfskill <[EMAIL PROTECTED]> wrote: >>I was running the recently-tagged RELENG_7_1 on my laptop, doing stuff >>involving switching among a small handful of xterms, when the mouse >>became unresponsive. > ... >> psm0: failed to reset the aux device. >> psm0: the aux device has gone! (reinitialize). > > My son's HP v6107 running 6.4-PRERELEASE/amd64 does this occasionally > as well. I haven't found any solution other than reboot either. I'd suggest you to attempt upgrading the BIOS, if you did not make it before. Version F.3D fixes some touchpad issues. Unfortunately HP only provides winflash updates for this notebook, so you will need Windows to apply it. -- cd /usr/ports/sysutils/life make clean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Should not usbdevs be removed by "make delete-old" on 8-STABLE?
Hi # uname -a FreeBSD avatar 8.0-STABLE FreeBSD 8.0-STABLE #2: Wed Dec 23 13:41:06 BRST 2009 r...@avatar:/usr/obj/usr/src/sys/Compaq_nx6320 amd64 # ls -l /usr/sbin/usbdevs -r-xr-xr-x 1 root wheel 8320 27 Jan 2009 /usr/sbin/usbdevs Is there any reason to keep usbdevs installed now that 8.X uses the new USB stack? ___ 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"
Fwd: bin/119884: Make sysinstall use the new Brazillian ntp servers
Hello, Is there any chance that this fix get comited before the release of 7.0? The Brazilian [correctly spelled now :-)] NTP servers currently used by sysinstall are not reliable. It would be much better to use the new ones that use the atomic clock at the Brazil's National Astronomic Observatory for time reference. -- Forwarded message -- From: <[EMAIL PROTECTED]> Date: Jan 22, 2008 1:50 AM Subject: Re: bin/119884: Make sysinstall use the new Brazillian ntp servers To: "Carlos A. M. dos Santos" <[EMAIL PROTECTED]> Thank you very much for your problem report. It has the internal identification `bin/119884'. The individual assigned to look at your report is: freebsd-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=119884 >Category: bin >Responsible:freebsd-bugs >Synopsis: Make sysinstall use the new Brazillian ntp servers >Arrival-Date: Tue Jan 22 03:50:02 UTC 2008 -- Carlos A. M. dos Santos -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7: interrupt eating whole cpu core
On Feb 6, 2008 5:45 PM, Dominic Fandrey <[EMAIL PROTECTED]> wrote: > Chuck Swiger wrote: > > Hi, Dominic-- > > > > On Feb 6, 2008, at 11:12 AM, Dominic Fandrey wrote: > >>> behaviour has changed. This is an HP 6510b GR695EA#ABD, if anyone > >>> thinks it might be helpful, I can supply you with a dmesg and the > >>> output of pciconf -lv. > >> > >> The problem remains with fresh sources: > >> > >> PID USERNAME THR PRI NICE SIZERES STATE C TIMECPU COMMAND > >> 12 root 1 171 ki31 0K16K RUN0 22:04 97.85% > >> idle: cpu0 > >> 37 root 1 -64- 0K16K CPU1 1 2:35 96.00% > >> irq14: ata0 > >> 11 root 1 171 ki31 0K16K RUN1 19:32 6.40% > >> idle: cpu1 > >> > >> The rip is done by k3b, so the drive is accessed through the cam > >> interface. > > > > What are the values being reported by "sysctl hw.ata"? If you're going > > to be burning CD/DVDs, you really want to make sure hw.ata.atapi_dma is on. > > I cannot believe it was so trivial. The sysctl looks all right. > > # sysctl hw.ata 0 /root > hw.ata.wc: 1 > hw.ata.atapi_dma: 1 > hw.ata.ata_dma: 1 > > But further research revealed: > # atacontrol mode acd0 0 /root > current mode = PIO4 > > # atacontrol mode acd0 udma330 /root > > changed the load dramatically: > PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND >12 root 1 171 ki31 0K16K RUN0 52:54 100.00% idle: > cpu0 >11 root 1 171 ki31 0K16K CPU1 1 23:36 94.29% idle: cpu1 > 1087 kamikaze 3 -80 133M 36168K physrd 1 1:09 3.17% k3b >37 root 1 -64- 0K16K WAIT 1 30:10 0.00% irq14: > ata0 > > > Thank you very much! I used to think that UDMA33 was the default for > CD-/DVD-Rom drives. I suppose I should review the BIOS settings or change > something in the hints file. Wow, now I'm *really* surprised. I used to think that putting hw.ata.ata_dma="1" hw.ata.atapi_dma="1" in /boot/loader.conf would be enough to enable DMA mode. In fact I'm pretty sure it used to be in previous versions of FreeBSD. I created a /etc/rc.local containing #!/bin/sh - atacontrol mode acd0 udma33 Two questions, now: 1. Is this related to using atapicam? 2. Should this be considered a bug? -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7: interrupt eating whole cpu core
On Feb 8, 2008 4:27 AM, Dominic Fandrey <[EMAIL PROTECTED]> wrote: > > Carlos A. M. dos Santos wrote: > > On Feb 6, 2008 5:45 PM, Dominic Fandrey <[EMAIL PROTECTED]> wrote: > >> Chuck Swiger wrote: > >>> Hi, Dominic-- > >>> > >>> On Feb 6, 2008, at 11:12 AM, Dominic Fandrey wrote: > >>>>> behaviour has changed. This is an HP 6510b GR695EA#ABD, if anyone > >>>>> thinks it might be helpful, I can supply you with a dmesg and the > >>>>> output of pciconf -lv. > >>>> The problem remains with fresh sources: > >>>> > >>>> PID USERNAME THR PRI NICE SIZERES STATE C TIMECPU COMMAND > >>>> 12 root 1 171 ki31 0K16K RUN0 22:04 97.85% > >>>> idle: cpu0 > >>>> 37 root 1 -64- 0K16K CPU1 1 2:35 96.00% > >>>> irq14: ata0 > >>>> 11 root 1 171 ki31 0K16K RUN1 19:32 6.40% > >>>> idle: cpu1 > >>>> > >>>> The rip is done by k3b, so the drive is accessed through the cam > >>>> interface. > >>> What are the values being reported by "sysctl hw.ata"? If you're going > >>> to be burning CD/DVDs, you really want to make sure hw.ata.atapi_dma is > >>> on. > >> I cannot believe it was so trivial. The sysctl looks all right. > >> > >> # sysctl hw.ata 0 /root > >> hw.ata.wc: 1 > >> hw.ata.atapi_dma: 1 > >> hw.ata.ata_dma: 1 > >> > >> But further research revealed: > >> # atacontrol mode acd0 0 /root > >> current mode = PIO4 > >> > >> # atacontrol mode acd0 udma330 /root > >> > >> changed the load dramatically: > >> PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND > >>12 root 1 171 ki31 0K16K RUN0 52:54 100.00% idle: > >> cpu0 > >>11 root 1 171 ki31 0K16K CPU1 1 23:36 94.29% idle: > >> cpu1 > >> 1087 kamikaze 3 -80 133M 36168K physrd 1 1:09 3.17% k3b > >>37 root 1 -64- 0K16K WAIT 1 30:10 0.00% irq14: > >> ata0 > >> > >> > >> Thank you very much! I used to think that UDMA33 was the default for > >> CD-/DVD-Rom drives. I suppose I should review the BIOS settings or change > >> something in the hints file. > > > > Wow, now I'm *really* surprised. I used to think that putting > > > > hw.ata.ata_dma="1" > > hw.ata.atapi_dma="1" > > > > in /boot/loader.conf would be enough to enable DMA mode. In fact I'm > > pretty sure it used to be in previous versions of FreeBSD. I created a > > /etc/rc.local containing > > > > #!/bin/sh - > > atacontrol mode acd0 udma33 > > > > Did you check weather you are affected, before you applied your solution? > Only one machine is affected. Yes, it happens in my notebook (HP NX6320). > I put the following into my rc.conf: > # Set mode for CD/DVD drive. > /sbin/atacontrol mode acd0 2>&1 | /usr/bin/grep PIO > /dev/null 2>&1 \ > && /sbin/atacontrol mode acd0 UDMA33 Do not put this in rc.conf. It will be executed again each time a script in /etc/rc.d source rc.conf to obtain the configuration variables. > > Two questions, now: > > > > 1. Is this related to using atapicam? > > Not for me. > > > 2. Should this be considered a bug? > > Yes, but not in FreeBSD. It's a bug in the BIOS of my Notebook. This is a > guess, not certainty. I believe that the kernel must handle this transparently when hw.ata.atapi_dma is set to 1, but I will need to look at the code this to see what is happening. -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA -- erratic behaviour when removing disk
On Feb 16, 2008 7:07 PM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > Is anyone aware of the situation where FreeBSD behaves erratically when > a disk is physically removed without "atacontrol detach ataX" being run > prior to removal (at least on RELENG_7)? Yes, I have seen this since 4.5, IIRC. > Below are my notes from said situation. > > I can provide remote access to this machine (serial-level) to whoever > wants to hack on it. I can be available for disk removal/insertion as > well; just ask. > > Also FWIW: I also tested all this for comparison on Ubuntu Linux earlier > this morning. I was able to yank the disk in the middle of an I/O > operation, resulting in an immediate I/O error from dd. I took no > precautions prior to yanking the disk. Upon reinsertion, the system > found the disk and I could continue I/O operations on it as if it had > never been removed. Only reason I'm pointing this out is that it > confirms the issue isn't hardware or with vendor implementation, but > rather specific to the OS. Congratulations to the Linux folks. Or not, since this looks like a very risky behavior. Who warrants you that the *same* disk was plugged back? Blindly continuing to write could easily corrupt the contents of the second drive. > -- > | Jeremy Chadwickjdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > Hardware: > Supermicro SuperServer 5015M-T+B > Intel ICH7 > AHCI enabled (version 01.10), BIOS-based RAID disabled > ad4: 190782MB at ata2-master SATA150 > ad6: 190782MB at ata3-master SATA150 > > OS installed on /dev/ad4 and OS was booted with verbose logging enabled: > > FreeBSD 7.0-RC2 FreeBSD 7.0-RC2 #0: Fri Feb 8 00:09:57 UTC 2008 [EMAIL > PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 [lengthy contents purposefully removed in the reply message] -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA -- erratic behaviour when removing disk
On Feb 17, 2008 3:19 AM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Sat, Feb 16, 2008 at 09:08:38PM -0200, Carlos A. M. dos Santos wrote: > > On Feb 16, 2008 7:07 PM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > > > Is anyone aware of the situation where FreeBSD behaves erratically when > > > a disk is physically removed without "atacontrol detach ataX" being run > > > prior to removal (at least on RELENG_7)? > > > > Yes, I have seen this since 4.5, IIRC. > > Wonderful. > > > > Also FWIW: I also tested all this for comparison on Ubuntu Linux earlier > > > this morning. I was able to yank the disk in the middle of an I/O > > > operation, resulting in an immediate I/O error from dd. I took no > > > precautions prior to yanking the disk. Upon reinsertion, the system > > > found the disk and I could continue I/O operations on it as if it had > > > never been removed. Only reason I'm pointing this out is that it > > > confirms the issue isn't hardware or with vendor implementation, but > > > rather specific to the OS. > > > > Congratulations to the Linux folks. Or not, since this looks like a > > very risky behavior. Who warrants you that the *same* disk was plugged > > back? Blindly continuing to write could easily corrupt the contents of > > the second drive. > > I'm not sure I understand. There were no filesystems on the drive, and > nothing mounted prior to removal: just like what I did with FreeBSD. > The procedure: > > * Boot Ubuntu CD, get a shell > * dd if=/dev/sdb of=/dev/null bs=8k > * In the middle of I/O, yank the disk > * dd exits with "I/O error" > * System continued to be responsive; no ATA subsystem oddities > * Reinserted disk; kernel saw the disk without any issue > * dd if=/dev/sdb of=/dev/null bs=8k > * I/O still operating as before; no system "oddities" I'm still not convinced that this is a valid use case. > If you'd like, I can try inserting a completely different disk (both in > size and vendor), but I really don't think anything odd will happen. If > there were filesystems mounted or other whatnots, yes, I could see how > there might be concern. [...] This is exctly what I was talking about when I said "risky". > [...] I can try that as well if you're interested. I > am a bit curious to see what Linux does if I pull a disk that has > mounted filesystems which are being accessed at the time. Yes, do it please. I must admit [precious brat mode on] that I'm very curious about what would happen. :-) > This test was done solely to see how FreeBSD behaved when a disk was > removed. The fact that the entire ATA channel goes into some bizarre > non-recoverable state when a disk is removed without detaching first > warrants the need for investigation, especially if this behaviour has > existed since the mid-4.x days. > > -- > > | Jeremy Chadwickjdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA -- erratic behaviour when removing disk
On Feb 17, 2008 4:25 AM, Andrey V. Elsukov <[EMAIL PROTECTED]> wrote: > 17.02.08, 02:08, "Carlos A. M. dos Santos" <[EMAIL PROTECTED]>: > > > > precautions prior to yanking the disk. Upon reinsertion, the system > > > > found the disk and I could continue I/O operations on it as if it had > > > > never been removed. Only reason I'm pointing this out is that it > > > > confirms the issue isn't hardware or with vendor implementation, but > > > > rather specific to the OS. > > > Congratulations to the Linux folks. Or not, since this looks like a > > > very risky behavior. Who warrants you that the *same* disk was plugged > > > back? Blindly continuing to write could easily corrupt the contents of > > > the second drive. > > > > There is no risk. Linux's libata detects it when you inserts a different disk. > > > > You can read some details here: > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg11742.html Quoting the message you pointed out: "You might lose cached and in-flight data of course, and userspace applications may or may not handle the disappearance of their underlying filesystem with grace and aplomb :)" Perhaps you believe that allowing userland applications to lose data is not risky. I strongly disagree. -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Very large kernel
On Sat, Mar 1, 2008 at 4:33 AM, Alex de Kruijff <[EMAIL PROTECTED]> wrote: > I noticed that the kernel directory was very large compaired to 6.1. Is > this for debugging and can I safely remove the symbols files I want to > save some space? You can build a custom kernel, without debug support, if debugging if not useful for you. I use to do this in "production" machines. -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Missing manual pages (e.g. aio_fsync)
Hello, It seems that the manual page of aio_fsync is missing, at least in FreeBSD 7.0-STABLE. I have some questions regarding this: 1. Is there somebody working on a man page for aio_fsync? 2. Is there a list of missing manual pages? 3. What is the current status of POSIX and Unix Specification? Is there any agreement with IEEE or Open Group allowing to cut-and-paste from, say, http://www.opengroup.org/onlinepubs/009695399/functions/aio_fsync.html? -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Texas Instruments Card Reader.
On Sun, Mar 30, 2008 at 3:58 AM, M. Warner Losh <[EMAIL PROTECTED]> wrote: > In message: <[EMAIL PROTECTED]> > Da Rock <[EMAIL PROTECTED]> writes: > : Did anyone end up getting this to work? I'm suffering the same woes... > > Which device is this, specifically? > > Warner It is an SD, MS/Pro, MMC, SM and XD card reader. It is recognized by the Linux "sdhci" driver. There was an email thread some time ago discussing an homonymous driver for FreeBSD: http://lists.freebsd.org/pipermail/freebsd-drivers/2006-September/000243.html http://lists.freebsd.org/pipermail/freebsd-drivers/2006-September/000248.html -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
burncd: ioctl(CDIOCEJECT): Input/output error
Hello, I get "burncd: ioctl(CDIOCEJECT): Input/output error" each time I attempt to blank a CDRW with burncd -f /dev/acd0 blank eject I noticed that this does not happen when I write a data cd with burncd -f /dev/acd0 data cd-image.iso fixate eject I have seen the same bahavior on 4 different computers that have DVD-RW units. Applying the attached patch to /usr/src/usr.sbin/burncd/burncd.c solves the problem. It make burncd attempt to eject the CD five times, sleeping for one second after each unccessful try. I'd like to get some opinions on this before submitting a PR. Thanks in advance. -- Carlos A. M. dos Santos burncd_eject.patch Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Is it possible to create a directory under /dev?
I attempted this: # mkdir /dev/foo mkdir: /dev/foo: Operation not supported Any suggestions (besides creating it elsewhere, of course)? -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is it possible to create a directory under /dev?
On Wed, May 21, 2008 at 11:15 AM, Vivek Khera <[EMAIL PROTECTED]> wrote: > > On May 21, 2008, at 8:44 AM, Carlos A. M. dos Santos wrote: > >> I attempted this: >> >># mkdir /dev/foo >>mkdir: /dev/foo: Operation not supported >> >> Any suggestions (besides creating it elsewhere, of course)? > > Assuming you're using a modern FreeBSD (version number would be useful), > /dev does not live on a file system. It exists as its own file system, > controlled by devfs. Check the man page for devfs for details. I'm using 7.0-STABLE. I've read devfs(8), devfs(5) and did not find an answer there. -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is it possible to create a directory under /dev?
On Wed, May 21, 2008 at 2:06 PM, Oliver Fromme <[EMAIL PROTECTED]> wrote: > Carlos A. M. dos Santos <> wrote: > > I attempted this: > > > > # mkdir /dev/foo > > mkdir: /dev/foo: Operation not supported > > DEVFS is a "virtual" filesystem [...] I already knew that. :-) > > Any suggestions (besides creating it elsewhere, of course)? > > That depends on the purpose. *Why* do you want to create > a subdirectory in /dev? What do you want to do with it? I intended to use it as the mount point for a filesystem. -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Why does sysinstall still limits cylinders to 65535?
Hello, I have been struglling with sysinstall, attempting to make it handle the geometry of some large SATA drives. After a lot of effort I decided to stop suffering and modified the program in order to circumvent the outdated limit of 65535 cylinders (see attached patch). I'm thinking about submitting a PR with a change request but I'd like to get some additional opinions first. I did not test it in "batch" mode, so it would be great if any kind soul did this. Thanks in advance for your comments and/or suggestions. -- Carlos A. M. dos Santos sysinstall-64kcyl.diff Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why does sysinstall still limits cylinders to 65535?
On Mon, May 26, 2008 at 3:24 AM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Sun, May 25, 2008 at 11:52:06PM -0300, Carlos A. M. dos Santos wrote: >> I have been struglling with sysinstall, attempting to make it handle >> the geometry of some large SATA drives. After a lot of effort I >> decided to stop suffering and modified the program in order to >> circumvent the outdated limit of 65535 cylinders (see attached patch). >> I'm thinking about submitting a PR with a change request but I'd like >> to get some additional opinions first. I did not test it in "batch" >> mode, so it would be great if any kind soul did this. > > Carlos, bottom line is to simply ignore the geometry warning you see. > > For others... > > This is just added evidence that the humongous warning spit out during > sysinstall's fdisk is confusing users (many taking it very seriously > when there's really no problem at all). > > I think this is the third time someone's brought this up in the past > couple months... Sorry if I sound annoying but nobody else answered. I still believe that something must be done to fix sysinstall, so I'm asking you (where "you" means the "others" in Jeremy's message) to provide some additional feedback. Please fill-in the dots in one or more of the following options: 1. We can not make such change sysinstall because ... 2. Your patch is not correct/sufficient. I would be better if ... 3. Please submit a PR. It will momentarily be reviewed by ... 4. Give up. Nobody here cares about this issue. Thanks in advance. -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Texas Instruments Card Reader.
On Sat, Jun 14, 2008 at 3:27 AM, M. Warner Losh <[EMAIL PROTECTED]> wrote: > In message: <[EMAIL PROTECTED]> >Da Rock <[EMAIL PROTECTED]> writes: > : > : On Sun, 2008-03-30 at 09:18 -0300, Carlos A. M. dos Santos wrote: > : > On Sun, Mar 30, 2008 at 3:58 AM, M. Warner Losh <[EMAIL PROTECTED]> wrote: > : > > In message: <[EMAIL PROTECTED]> > : > > Da Rock <[EMAIL PROTECTED]> writes: > : > > : Did anyone end up getting this to work? I'm suffering the same > woes... > : > > > : > > Which device is this, specifically? > : > > > : > > Warner > : > > : > It is an SD, MS/Pro, MMC, SM and XD card reader. It is recognized by > : > the Linux "sdhci" driver. There was an email thread some time ago > : > discussing an homonymous driver for FreeBSD: > : > > : > > http://lists.freebsd.org/pipermail/freebsd-drivers/2006-September/000243.html > : > > http://lists.freebsd.org/pipermail/freebsd-drivers/2006-September/000248.html > : > > : > : Thats right- I believe you were working with a ricoh card reader though. > : Is there any update to this project? A todo journal maybe? > > I've a working card reader for ricoh that I've not been able to adapt > to TI so I've never committed from a couple of difference sources... > I should find time to fix that... I have Compaq nx6320 with the TI card reader that can be used for some testing. I also have Compaq 6910p which has a Ricoh card reader. This isthe output of "pciconf -lv": [EMAIL PROTECTED]:2:6:3: class=0x080500 card=0x30be103c chip=0x08221180 rev=0x20 hdr=0x00 vendor = 'Ricoh Company, Ltd.' device = 'R5C832, R5C843 SDA Standard Compliant SD Host Controller' class = base peripheral [EMAIL PROTECTED]:2:6:4: class=0x088000 card=0x30be103c chip=0x08431180 rev=0x10 hdr=0x00 vendor = 'Ricoh Company, Ltd.' device = 'unknown Ricoh MMC Host Controller' class = base peripheral -- If you think things can't get worse it's probably only because you lack sufficient imagination. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Looking for a GPT-aware boot manager
Hello, I'm attempting quad-boot my notebook with STABLE and CURRENT, both i386 and AMD64. I installed them manually by booting from a thumb drive, partitioning the hard disk and extracting the distributions from ISO images that I had stored on an external hard drive. My disk layout is as follows: ad0p1 boot ad0p2 freebsd, partitioned with disklabel for 7.0/AMD64 ad0p2a 7.0 AMD64 root ad0p2d 7.0 AMD64 /var ad0p2f 7.0 AMD64 /usr ad0p3 freebsd, partitioned with disklabel for 7.0/i386 ad0p3a 7.0 i386 root ad0p3d 7.0 i386 /var ad0p3f 7.0 i386 /usr ad0p4 freebsd, partitioned with disklabel for 7.0/AMD64 ad0p4a 8.0 AMD64 root ad0p4d 8.0 AMD64 /var ad0p4f 8.0 AMD64 /usr ad0p5 freebsd, partitioned with disklabel for 7.0/AMD64 ad0p5a 8.0 i386 root ad0p5d 8.0 i386 /var ad0p5f 8.0 i386 /usr ad0p6 freebsd, partitioned with disklabel for all ad0p6b swap ad0p6d /temp ad0p6e /local The problem now is that I don't have a boot manager capable of selecting a partition to boot from. The FreeBSD boot manager (boot0) does not recognize GPT. I atempted to pass "0:ad(0p3)/boot/loader" to gptboot but had no success. I did a lot of googling and even attempted to read the source code of gptboot but could not figure out how to solve the problem, so any help will be appreciated. -- If you think things can't get worse it's probably only because you lack sufficient imagination. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HP Pavilion dv2000 laptop wont boot off install cd
On Mon, Jul 21, 2008 at 9:26 AM, Kevin K <[EMAIL PROTECTED]> wrote: >> On Thu, 17 Jul 2008 08:31:37 -0400 >> Kevin K <[EMAIL PROTECTED]> wrote: >> >> > For 7.0-RELEASE, it >> > seemed to hang at "Trying to mount root from ufs:/dev/md0". >> >> How long did you wait? If you didn't wait 10 or 15 minutes, please do. >> Various tests / probes take a long time to time out on some hardware. >> >> HTH >> -- >> Regards, >> Torfinn Ingolfsen > > > I tried the 7.0-release-amd64 200807 snapshot and it booted (after holding > the spacebar @ /boot/loader.conf). I have seen this on some HP notebooks. It seems that the CD drive does not to stabilize on time before booting, leading to some disk read errors. The trick is to press F9 (or F12, depending on the notebook model) to force the BIOS to show the boot device menu. Then, *after the CD drive stop spinning*, choose the boot from CD/DVD option. > It stopped at Trying to mount root from > ufs:/dev/md0". I waited about 30-45 minutes and it didn't continue from that > point -- the keyboard was also unresponsive. > > Does anyone know if this is a known issue? Try to disable kbdmux before booting. Jump to the loader prompt and type: set hint.kbdmux.0.disabled=1 boot -v -- If you think things can't get worse it's probably only because you lack sufficient imagination. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bin/123693: Workaround for burncd: ioctl(CDIOCEJECT): Input/output error
On Mon, May 26, 2008 at 1:21 AM, Carlos A. M. dos Santos <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 9:27 AM, Carlos A. M. dos Santos > <[EMAIL PROTECTED]> wrote: >> On Sat, May 17, 2008 at 4:28 PM, Volker <[EMAIL PROTECTED]> wrote: >>> Carlos, >>> >>> IMHO it's better to explicitly check for ioctl returning EBUSY and 5 >>> seconds may not fit every situation. >>> >>> Volker >> >> Ok, I will attempt the approach of checking for EBUSY. > > I found that ioctl(fd, CDIOCEJECT) returns EIO, not EBUSY, so it seems > that there is no better solution. I was able to improve the delays, > however (see attachmet). Now they grow exponentially, limited to 31 > seconds (1 + 2 + 4 + 8 + 16). This is better than flooding the CD > drive with one eject request per second. Any update on this issue? I'd suggest you to at least close the PR if the proposed patch is not acceptable. I must admit that it is only a tricky workaround, not a masterpiece, so I will not feel offended. :-) -- If you think things can't get worse it's probably only because you lack sufficient imagination. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Recommended wireless card (or is there a chance to get either iwi or ath fixed)?
On Wed, Feb 25, 2009 at 8:26 AM, Paul B. Mahol wrote: > On 2/24/09, SDH Support wrote: >> >>> I tried using my ath based D-Link DWL G650, which still seems to have >>> some issues in regard to interrupt handling: >> >> >> I've been able to get /most/ wireless cards working with ndiswrapper. > > *BSD doesnt have ndiswrapper. Yes, it does: http://www.freebsd.org/cgi/man.cgi?query=ndis&manpath=FreeBSD+7.1-RELEASE -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. ___ 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 child process die for root
On Thu, Jul 2, 2009 at 1:17 AM, Sagara Wijetunga wrote: > Roland Smith writes: >> It could be a hardware problem. Signal 11 can be a sign of bad memory. >> Can you reproduce the problem on multiple machines? > > I have taken the hard disk out and fixed on different machines, the symptoms > are still the same. So it may not be a hardware error. > Regards > Sagara Try to *rebuild* the system on another machine. Signal 11 is usually associated to bad hardware (RAM) so if you build FreeBSD on faulty hardware the resulting program may be broken. Try to debug the "login" program: (become root) # cd /usr/src/usr.bin/login # make clean # make CFLAGS=-g # gdb /usr/obj/usr/src/usr.bin/login/login (supposing that "sagara" is your user name) #run sagara (fill-in the password name, if requested) If the signal 11 is caught, issue "bt" command in gcc. It will show you where the break happened. -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. ___ 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"
