Re: Inbox driver
Thanks for the reply. Emulex's OCE driver is present in Freebsd-8.3 http://svn.freebsd.org/base/release/8.3.0/sys/dev/ but it is not present in http://svn.freebsd.org/base/release/9.0.0/sys/dev/, is there a way to get this driver into 9.0.0 branch? And the same driver is present in 9.1-RC1 so can I assume that it is going to be part of 9.1-RELEASE? Please clarify. On Wed, Aug 29, 2012 at 7:01 PM, Lowell Gilbert freebsd-questions-lo...@be-well.ilk.org wrote: Venkat Duvvuru venkatduvvuru...@gmail.com writes: If a driver module misses the deadline to make it inbox , I think that it's gonna be part of the next Freebsd release. The sources show up in the svn repository, probably this is one confirmation that it's gonna be part of the next release..Is my understanding correct? Please clarify. I don't know what you mean about inbox, but basically you're right. It's a bit more complicated, though, because the svn repository has several branches -- and a feature introduced to 10.x, for example, may or not show up in 9.x. If a feature is introduced into HEAD, you can be pretty sure it will make it into some release eventually. Does that help? I tried to keep it brief... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: PR 161548
On 24/09/2012 22:29, Jerry wrote: Is there any specific reason that this PR: 161548 is still marked as open? o 2011/10/13 bin/161548 [patch] getent(1) inconsistent treatment of IPv6 host data It simply hasn't attracted the attention of anyone with a src commit bit. Yet. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: PR 161548
On Tue, 25 Sep 2012 07:03:57 +0100 Matthew Seaman articulated: On 24/09/2012 22:29, Jerry wrote: Is there any specific reason that this PR: 161548 is still marked as open? o 2011/10/13 bin/161548 [patch] getent(1) inconsistent treatment of IPv6 host data It simply hasn't attracted the attention of anyone with a src commit bit. Yet. This deficiency was mentioned on the Postfix forum http://news.gmane.org/gmane.mail.postfix.user/cutoff=232317 recently. The PR was filed nearly a year ago. I would have thought that by now someone would have given some thought to committing it BEFORE they continue to pump out new versions of FreeBSD. Just my take on the matter. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Forbes Thought Of The Day “When a man tells you he got rich through hard work, ask him: Whose?” — Don Marquis signature.asc Description: PGP signature
Re: Change in /etc/rc.d/namend script
[ Olivier Nicole wrote on Tue 25.Sep'12 at 11:39:37 +0700 ]
Hi,
Yesterday I upgraded my DNS server from 7.2 to 8.3 and has the
unpleasant suprise to find that named would not restart after the
upgrade.
I think I traced it back to the new /etc/rc.d/named script.
I am runing in named in a chrooted environment and it seems that with
the new script the configuration file must exist in /etc/namedb as
well as in /chroot/etc/namedb.
Having to duplicate the configuration files to the not chrooted
environment is something new. With the /etc/rc.d/named script
1.22.2.3.4.1 2008/10/02 that was not needed, and I don't see why it
would be needed now.
Is there a way to run the new startup script without duplicating (not
even symlinking) the configuration?
In you /etc/namedb/named.conf have you specified your zone files using full
path names, such as:
zone kode5.net {
type master;
file /etc/namedb/master/kode5.net.db;
};
Using relative paths for your zone files will not work any more. Perhaps this
could help?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Problems with xhci driver
Greetings, I seem to have encountered a problem with the xhci driver on my new computer (FreeBSD 9.0). I noticed that I had a 15% interrupt cpu usage when the machine wasn't doing anything so I looked into it and it turns out that the xhci driver is going nuts on me. A vmstat -i shows me this: interrupt total rate irq16: xhci0 16747312710 101948 I tried setting hw.usb.xhci.debug to 1 and then I got repeated logs saying xhci_set_hw_power:. Any help on how to track the issue behind this down would be greatly appreciated. Since reboot I have had a usb disk plugged in and removed again. I also unplugged the keyboard for a while. Regards, Andréas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
/var overflow and named pipes?
Hi all, After running for a whopping 10 days or so, during which the use of my /var as shown by df stayed at 62%, my system hung in X. I was able to exit to a vty using ctlaltfn At that point I killed X using kill -SIGHUP I then attempted to restart X. It came up, but in a clobbered condition with some icons under xfwm4 not showing, and some of the top menu bar text hosed (showing the square box char which usually indicates bad character data). I was able to shut it down by exiting the controlling xterm. Somewhere in there I'm pretty sure I saw a message something like Too many named pipes When trying to start X again, there were a boatload of messages: Fatal IO Error 35 (Resource temporarily unavailable) on X server :0.0 Messages showed up for programs being started in the startx script (xfwm4, xterm) and some spawned by those (thunar...) Then the message: XIO: Fatal IO error 35 (...) after 518 requests (388 known processed) with 0 events remaining At that point, /var was at 109% Examining /var, there was one huge file, Xorg.0.log. Neither head nor tail nor the portions of the interior I've looked at of that file shows anything particularly interesting; however, what is interesting is it seems to contain a never-ending repeat of reinitialization of the graphics card for monitor configuration. I copied the offending Xorg.0.log file to save it in a place with more space so I could examine it later, then deleted it. Portion appended below. However, when I restarted X I was still getting the fatal io errors, so I shutdown the system and rebooted. Also, since I was editing several (small) text files using vi, upon rebooting I got the usual messages about recovery. One of those files, when I attempted recovery, indicated it was huge. The file itself was small, ~180 lines, and had been saved already so the huge recovery file was somehow corrupt. I interrupted the recovery attempt (^C, took a *long* time to respond), checked /var size with du, and it was still only 62% so I may have averted another overflow there. /var/log/messages shows nothing for 16 hrs and then: Sep 24 16:22:01 breakaway kernel: pid 59110 (dd), uid 2 inumber 113248 on /var: filesystem full Sep 24 16:33:00 breakaway kernel: pid 79946 (dd), uid 2 inumber 113453 on /var: filesystem full Sep 24 17:33:00 breakaway last message repeated 501 times etc... I *think* all of the above is true; unfortunately, I didn't write notes until some things had passed and some notes were incomplete as to where in the process they occurred. Questions: 1. Can anyone shed light on the too many named pipes message? Is this likely caused by xfwm4 / thunar ipc? 2. Is the XIO error 35 (Resource temporarily unavailable) probably referring to the unavailability of named pipes? Or the unavailability of space in the Xorg.0.log file? Or does a pipe require space on /var and therefore when /var fills, no pipes are available? Are the X log files supposed to cycle the way system logs do? 3. Is there a way to see which processes have named pipes opened? After killing X and restarting, /usr/local/libexec/gam_server was still running and showing a runtime of 6472:54.82, very large compared to everything else. It's my understanding gam_server is used to detect changes in a file or directory; and might be using pipes for this purpose. Is this likely holding onto pipes? Is there an easy way to cause it to exit when X exits? 4. I've noticed the growing Xorg.0.log file in the past, but since /var was staying small it seemed like I had plenty of room. Then it seemed to suddenly explode when the system hung. Is this a known issue with resetting the graphics card? (In this case an unsupported Visiontek 900331 which used Radeon HD 5550) There is a redhat bug which may be relevant: https://bugzilla.redhat.com/show_bug.cgi?id=820731 Would getting a different graphics card likely solve this issue? 5. This *feels* like a sudden runaway condition. Shouldn't I normally get mail indicating /var is full before reaching 109%? There's 10 min between the first two full messages, and I didn't get *any* file sys full messages. Minor Issue: /var/tmp contains a number of empty directories with names virtual-[user].xx and gvfs-[user]-xx cleanvar_enable is set in /etc/defaults/rc.conf, I have not overridden it; but these dirs are obviously not being removed. Do I need to specifically turn on daily_clean_tmps_enable daily_clean_disks_enable Are there any reasons *not* to turn these on? In particular, if things are still running using some files in those places which were created early enough to be candidates for deletion? Thanks for any insights, Gary Xorg.0.log repeated sequence = (II) RADEON(0): Monitor name: LCD1970NX (II) RADEON(0): Serial No: 57302818YA (II) RADEON(0): EDID (in hex): (II) RADEON(0):
