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"
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"
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"
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: 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]"
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: 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 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: 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 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: 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: 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: 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: 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: 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: 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: 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]"
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: 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]"
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]"
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: 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]"
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]"
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]"
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]"
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]"
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: 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]"
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: 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: 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: 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]"
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]"
