drm change breaks old ATI?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seems that the new drm schema requires an interrupt to attach. "dmesg" returns: pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x9000-0x90ff mem 0xd100-0xd1ff,0xd010-0xd0100fff at device 0.0 on pci1 drm0: <3D Rage Pro AGP 1X/2X> on vgapci0 device_attach: drm0 attach returned 2 ^ .. which corresponds to ENOENT and "lspci -vvv" gives: 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 5c) (prog-if 00 [VGA controller]) Subsystem: ATI Technologies Inc Rage Pro Turbo AGP 2X Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Interrupt: pin ? routed to IRQ 255 Region 0: Memory at d100 (32-bit, non-prefetchable) Region 1: I/O ports at 9000 Region 2: Memory at d010 (32-bit, non-prefetchable) Capabilities: [50] AGP version 1.0 Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate= Didn't this used to work? Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknAV+gACgkQQv9rrgRC1JIiAwCdEmwDBPcTjd97vV3q3kz5kO8R qA0An3RjPS/ra7CVRd6KfeuOuQoARaVm =h2qo -END PGP SIGNATURE- ___ 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"
vmstat memory: avm vs fre
I'm getting a really odd condition on one of my servers (and I suspect its happening on one of my other servers as well) ... after a period of time (<3 days), the server hangs solid ... Running vmstat in an xterm, the one thing I'm noticing is that when it hangs, my avm == 12455M and fre == 22M ... when I start the system, it looks like: avm == 246M vs fre == 197M ... I'm suspecting that the lock up is that fre hit 0 at some point, but I'm at a loss as to why, or where to look, for this ... top in another xterm when it hangs shows it appears to have more then enough VM: last pid: 87005; load averages: 8.57, 7.29, 4.46up 0+17:25:13 20:45:00 1140 processes:317 running, 774 sleeping, 10 zombie, 39 lock CPU: 23.3% user, 0.0% nice, 11.1% system, 0.4% interrupt, 65.1% idle Mem: 4610M Active, 440M Inact, 489M Wired, 13M Cache, 214M Buf, 9624K Free Swap: 8192M Total, 1055M Used, 7137M Free, 12% Inuse, 564K In, 272K Out kvm_open: cannot open /proc/90106/mem PID JID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 30625 0 root1 960 588M 166M RUN0 14:54 0.10% /usr/local/bin/qemu-system-x86_64 -m 512M -net nic,macadd 86866 20 1200 1 960 60888K 1140K RUN0 0:00 0.15% postgres: autovacuum worker process(postgres) 86844 1 root1 960 15080K 1028K RUN1 0:00 0.05% sshd: [accepted] (sshd) 45533 20 root1 960 15044K 456K RUN1 0:00 0.05% /usr/sbin/sshd 86895 0 root1 960 15092K 428K RUN0 0:00 0.05% /usr/sbin/sshd 15131 15 root1 960 19692K 376K RUN1 0:00 0.15% /usr/sbin/sshd 95911 4 www 1 40 106M 0K accept 0 0:01 0.00% /usr/local/sbin/httpd () Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scra...@hub.org MSN . scra...@hub.org Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ 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: rndc: connect failed: 127.0.0.1#953: connection refused
Yes that is exactly the point. RNDC is supposed to run on 953 and the name
service itself is on 53. Think about it, if tcp/53 is used for real DNS
(jumbo RR) traffic, how can rndc be listening for commands on the same
channel?
On 2009-03-17 06:10:44PM -0600, Squirrel wrote:
> I realized that default for RNDC was 953, and forced it to 53, but was still
> getting the same error.
>
> As you recommended, I used the '-g' and noticed only unusual thing was:
>
>/etc/namedb/named.conf:23: couldn't add command channel 127.0.0.1#53:
> address in use
>
> So I took out the port 53 out of the named.conf and let it use the default.
> But left port 53 on rdnc.conf. When I restarted with '-g', that message
> above is gone and all looks good. Strangely, two doesn't make sense are:
>
>listening on IPv4 interface rl0, 66.187.80.4#53
>command channel listening on 127.0.0.1#953
>
> By default is #53, and in rndc.conf forced to port #53, but the named
> displays port #953 for command channel. Is the RNDC supposed run on port 953
> in addition to named running on 53? I can't seem to get rndc to run on #53.
> I've also tried removoing port to default on rndc.conf.
>
> And reboot still won't load named. And manual rndc load still errors with
> original message.
>
> Below are the current messages:
>
> r...@ns2# named -4 -S 1024 -c /etc/namedb/named.conf -g
> 17-Mar-2009 19:04:50.001 starting BIND 9.6.0-P1 -4 -S 1024 -c
> /etc/namedb/named.conf -g
> 17-Mar-2009 19:04:50.001 built with '--localstatedir=/var'
> '--disable-linux-caps' '--with-randomdev=/dev/random'
> '--with-openssl=/usr/local' '--with-libxml2=/usr/local' '--without-idn'
> 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--disable-threads'
> '--sysconfdir=/etc/namedb' '--prefix=/usr' '--mandir=/usr/share/man'
> '--infodir=/usr/share/info/' '--build=i386-portbld-freebsd6.2'
> 'build_alias=i386-portbld-freebsd6.2' 'CC=cc' 'CFLAGS=-O2
> -fno-strict-aliasing -pipe' 'LDFLAGS= -rpath=/usr/local/lib' 'CXX=c++'
> 'CXXFLAGS=-O2 -fno-strict-aliasing -pipe'
> 17-Mar-2009 19:04:50.001 using up to 1024 sockets
> 17-Mar-2009 19:04:50.068 loading configuration from '/etc/namedb/named.conf'
> 17-Mar-2009 19:04:50.124 using default UDP/IPv4 port range: [49152, 65535]
> 17-Mar-2009 19:04:50.124 using default UDP/IPv6 port range: [49152, 65535]
> 17-Mar-2009 19:04:50.127 no IPv6 interfaces found
> 17-Mar-2009 19:04:50.127 listening on IPv4 interface rl0, aa.bb.cc.4#53
> 17-Mar-2009 19:04:50.128 listening on IPv4 interface rl0, aa.bb.cc.10#53
> 17-Mar-2009 19:04:50.128 listening on IPv4 interface lo0, 127.0.0.1#53
> 17-Mar-2009 19:04:50.143 automatic empty zone: 0.IN-ADDR.ARPA
> 17-Mar-2009 19:04:50.143 automatic empty zone: 127.IN-ADDR.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: 254.169.IN-ADDR.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: 2.0.192.IN-ADDR.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone:
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: D.F.IP6.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: 8.E.F.IP6.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: 9.E.F.IP6.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: A.E.F.IP6.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: B.E.F.IP6.ARPA
> 17-Mar-2009 19:04:50.146 command channel listening on 127.0.0.1#953
> 17-Mar-2009 19:04:50.147 ignoring config file logging statement due to -g
> option
> 17-Mar-2009 19:04:50.168 zone 0.0.127.IN-ADDR.ARPA/IN: loaded serial 20060213
>
>
>
> -Original message-
> From: Mark Andrews mark_andr...@isc.org
> Date: Wed, 18 Mar 2009 00:21:52 -0600
> To: Squirrel squir...@mail.isot.com
> Subject: Re: rndc: connect failed: 127.0.0.1#953: connection refused
>
> >
> > In message , Squirrel
> > writes:
> > > My BIND9.6.0 on FreeBSD 6.2 works fine when I manually start with:
> > >
> > >r...@ns2# named -4 -S 1024 -c /etc/namedb/named.conf
> > >
> > > But it won't start on boot and no error messages or log. And it won't
> > > start
> > > using rndc, it cause error message. Why does the error shows port 953
> > > when I
> > > specified for port 53 in the config?
> >
> > Port 53 is for DNS.
> > Port 952 is the default port for RNDC.
> >
> > >rndc: connect failed: 127.0.0.1#953: connection refused
> >
> > Run "named -4 -S 1024 -c /etc/namedb/named.conf -g" and read the
> > messages.
> >
> > > Below are parts of my configs:
> > >
> > > /etc/rc.conf:
> > >named_enable="YES"
> > >named_flags="-4 -S 1024 -c /etc/namedb/named.conf"
> > >
> > >
> > > /etc/rndc.key:
> > >key "rndc-key" {
> > > algorithm hmac-md5;
> > > secret "y9eca/WZydNfi...";
> > >};
> > >
> > > /etc/namedb/rndc.conf:
> > >include "/etc/namedb/rndc.key";
> > >options {
> > > default-server
Re: rndc: connect failed: 127.0.0.1#953: connection refused
I realized that default for RNDC was 953, and forced it to 53, but was still
getting the same error.
As you recommended, I used the '-g' and noticed only unusual thing was:
/etc/namedb/named.conf:23: couldn't add command channel 127.0.0.1#53:
address in use
So I took out the port 53 out of the named.conf and let it use the default.
But left port 53 on rdnc.conf. When I restarted with '-g', that message above
is gone and all looks good. Strangely, two doesn't make sense are:
listening on IPv4 interface rl0, 66.187.80.4#53
command channel listening on 127.0.0.1#953
By default is #53, and in rndc.conf forced to port #53, but the named displays
port #953 for command channel. Is the RNDC supposed run on port 953 in
addition to named running on 53? I can't seem to get rndc to run on #53.
I've also tried removoing port to default on rndc.conf.
And reboot still won't load named. And manual rndc load still errors with
original message.
Below are the current messages:
r...@ns2# named -4 -S 1024 -c /etc/namedb/named.conf -g
17-Mar-2009 19:04:50.001 starting BIND 9.6.0-P1 -4 -S 1024 -c
/etc/namedb/named.conf -g
17-Mar-2009 19:04:50.001 built with '--localstatedir=/var'
'--disable-linux-caps' '--with-randomdev=/dev/random'
'--with-openssl=/usr/local' '--with-libxml2=/usr/local' '--without-idn'
'STD_CDEFINES=-DDIG_SIGCHASE=1' '--disable-threads' '--sysconfdir=/etc/namedb'
'--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info/'
'--build=i386-portbld-freebsd6.2' 'build_alias=i386-portbld-freebsd6.2' 'CC=cc'
'CFLAGS=-O2 -fno-strict-aliasing -pipe' 'LDFLAGS= -rpath=/usr/local/lib'
'CXX=c++' 'CXXFLAGS=-O2 -fno-strict-aliasing -pipe'
17-Mar-2009 19:04:50.001 using up to 1024 sockets
17-Mar-2009 19:04:50.068 loading configuration from '/etc/namedb/named.conf'
17-Mar-2009 19:04:50.124 using default UDP/IPv4 port range: [49152, 65535]
17-Mar-2009 19:04:50.124 using default UDP/IPv6 port range: [49152, 65535]
17-Mar-2009 19:04:50.127 no IPv6 interfaces found
17-Mar-2009 19:04:50.127 listening on IPv4 interface rl0, aa.bb.cc.4#53
17-Mar-2009 19:04:50.128 listening on IPv4 interface rl0, aa.bb.cc.10#53
17-Mar-2009 19:04:50.128 listening on IPv4 interface lo0, 127.0.0.1#53
17-Mar-2009 19:04:50.143 automatic empty zone: 0.IN-ADDR.ARPA
17-Mar-2009 19:04:50.143 automatic empty zone: 127.IN-ADDR.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: 254.169.IN-ADDR.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: 2.0.192.IN-ADDR.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: D.F.IP6.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: 8.E.F.IP6.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: 9.E.F.IP6.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: A.E.F.IP6.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: B.E.F.IP6.ARPA
17-Mar-2009 19:04:50.146 command channel listening on 127.0.0.1#953
17-Mar-2009 19:04:50.147 ignoring config file logging statement due to -g option
17-Mar-2009 19:04:50.168 zone 0.0.127.IN-ADDR.ARPA/IN: loaded serial 20060213
-Original message-
From: Mark Andrews mark_andr...@isc.org
Date: Wed, 18 Mar 2009 00:21:52 -0600
To: Squirrel squir...@mail.isot.com
Subject: Re: rndc: connect failed: 127.0.0.1#953: connection refused
>
> In message , Squirrel writes:
> > My BIND9.6.0 on FreeBSD 6.2 works fine when I manually start with:
> >
> >r...@ns2# named -4 -S 1024 -c /etc/namedb/named.conf
> >
> > But it won't start on boot and no error messages or log. And it won't
> > start
> > using rndc, it cause error message. Why does the error shows port 953 when
> > I
> > specified for port 53 in the config?
>
> Port 53 is for DNS.
> Port 952 is the default port for RNDC.
>
> >rndc: connect failed: 127.0.0.1#953: connection refused
>
> Run "named -4 -S 1024 -c /etc/namedb/named.conf -g" and read the
> messages.
>
> > Below are parts of my configs:
> >
> > /etc/rc.conf:
> >named_enable="YES"
> >named_flags="-4 -S 1024 -c /etc/namedb/named.conf"
> >
> >
> > /etc/rndc.key:
> >key "rndc-key" {
> > algorithm hmac-md5;
> > secret "y9eca/WZydNfi...";
> >};
> >
> > /etc/namedb/rndc.conf:
> >include "/etc/namedb/rndc.key";
> >options {
> > default-server localhost;
> > default-key "rndc-key";
> >};
> >server localhost {
> > key "rndc-key";
> >};
> >...
> >
> > /etc/namedb/named.conf:
> >include "/etc/namedb/rndc.key";
> >acl internals {
> >aa.bb.cc.0/20;
> >192.168.1.0/24;
> >127.0.0.0/8;
> >};
> >controls {
> > inet 127.0.0.1 port 53 allow { 127.0.0.1; } keys { rndc-key; };
> >};
> >options {
> > pid-f
Re: Radeon r6/7xx support merged to -STABLE
On Sun, 15 Mar 2009 19:49:12 +0100, Robert Noland wrote: I went ahead and merged the Radeon R6/7xx code to -STABLE a while ago. The current xorg drivers will not enable it by default on R600+ chips. You will need to be using xf86-video-ati-6.12.0, xf86-video-radeonhd-devel or possibly even better git master of either. You will need to add the following to the Device section of your xorg.conf to enable it. If you are experiencing issues, commenting these two options out, will prevent Xorg from auto-loading the kernel module. Options "DRI" Options "AccelMethod" "EXA" robert. Thanks. I currently have EXA accel on my system with xf86-video-ati-6.12.0, which makes KDE 4 a lot better already. drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading RV610 CP Microcode info: [drm] Loading RV610 PFP Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] Cheers, Ronald. ___ 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: [HEADS UP] drm merged to -STABLE
On Tue, 17 Mar 2009, Robert Noland wrote: On Tue, 2009-03-17 at 12:20 -0500, Greg Rivers wrote: On Sat, 10 Jan 2009, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a "garbled" screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I have a workstation with a [Radeon X600 (PCIE)] card. The X display has been garbled since these DRM updates went in in January, and remains garbled with 7.1-STABLE as of yesterday. As a work-around, I'm running the up-to-date 7.1-STABLE system (both world and ports) with a 7.1-RELEASE-p2 kernel. The display is fine with the old kernel and X works great; I even see dramatically improved performance with the new Xorg and EXA acceleration. Your work is much appreciated. But the garbled display with the recent DRM still plagues me. [snip] Could you try the attached patch. Unfortunately, there is no noticeable difference with this patch. Also, I'm guessing that this is a PCI based card, right? Also, it isn't an integrated model? Yes, this is a PCIEx16 card in a HP Compaq dc7600 desktop PC, not a motherboard integrated adapter. Thanks for your help. I'm willing to spend some time debugging this; please let me know if there's more information I can provide or other tests or patches I can try. -- Greg RiversIndex: drm_bufs.c === --- drm_bufs.c (revision 189907) +++ drm_bufs.c (revision 189908) @@ -1106,7 +1106,7 @@ if (size == 0) return 0; - order = ffsl(size) - 1; + order = flsl(size) - 1; if (size & ~(1ul << order)) ++order; ___ 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: rndc: connect failed: 127.0.0.1#953: connection refused
In message , Squirrel writes:
> My BIND9.6.0 on FreeBSD 6.2 works fine when I manually start with:
>
>r...@ns2# named -4 -S 1024 -c /etc/namedb/named.conf
>
> But it won't start on boot and no error messages or log. And it won't start
> using rndc, it cause error message. Why does the error shows port 953 when I
> specified for port 53 in the config?
Port 53 is for DNS.
Port 952 is the default port for RNDC.
>rndc: connect failed: 127.0.0.1#953: connection refused
Run "named -4 -S 1024 -c /etc/namedb/named.conf -g" and read the
messages.
> Below are parts of my configs:
>
> /etc/rc.conf:
>named_enable="YES"
>named_flags="-4 -S 1024 -c /etc/namedb/named.conf"
>
>
> /etc/rndc.key:
>key "rndc-key" {
> algorithm hmac-md5;
> secret "y9eca/WZydNfi...";
>};
>
> /etc/namedb/rndc.conf:
>include "/etc/namedb/rndc.key";
>options {
> default-server localhost;
> default-key "rndc-key";
>};
>server localhost {
> key "rndc-key";
>};
>...
>
> /etc/namedb/named.conf:
>include "/etc/namedb/rndc.key";
>acl internals {
>aa.bb.cc.0/20;
>192.168.1.0/24;
>127.0.0.0/8;
>};
>controls {
> inet 127.0.0.1 port 53 allow { 127.0.0.1; } keys { rndc-key; };
>};
>options {
> pid-file "/var/run/named.pid";
> directory "/etc/namedb";
> statistics-file "/var/log/named/named.stats";
> dump-file "/var/log/named/named.dump";
> zone-statistics yes;
> allow-query { 127.0.0.1; 66.187.80.0/20; };
>};
>logging {
> category "default" { simple_log; };
> channel simple_log {
> file "/var/log/named/named.log" versions 5 size 20m;
> severity warning;
> print-time yes;
> print-category yes;
> print-severity yes;
>};
>...
>
>
> ---
> PCShare.Com
>
> ___
> 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"
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
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: rndc: connect failed: 127.0.0.1#953: connection refused
Will, just for heck of it, I've changed the default ports to 953 on both
named.conf and rndc.conf, but still same error.
-Original message-
From: Squirrel squir...@mail.isot.com
Date: Tue, 17 Mar 2009 22:41:26 -0600
To: freebsd-stable freebsd-stable@freebsd.org
Subject: rndc: connect failed: 127.0.0.1#953: connection refused
> My BIND9.6.0 on FreeBSD 6.2 works fine when I manually start with:
>
>r...@ns2# named -4 -S 1024 -c /etc/namedb/named.conf
>
> But it won't start on boot and no error messages or log. And it won't start
> using rndc, it cause error message. Why does the error shows port 953 when I
> specified for port 53 in the config?
>
>rndc: connect failed: 127.0.0.1#953: connection refused
>
>
> Below are parts of my configs:
>
> /etc/rc.conf:
>named_enable="YES"
>named_flags="-4 -S 1024 -c /etc/namedb/named.conf"
>
>
> /etc/rndc.key:
>key "rndc-key" {
> algorithm hmac-md5;
> secret "y9eca/WZydNfi...";
>};
>
> /etc/namedb/rndc.conf:
>include "/etc/namedb/rndc.key";
>options {
> default-server localhost;
> default-key "rndc-key";
>};
>server localhost {
> key "rndc-key";
>};
>...
>
> /etc/namedb/named.conf:
>include "/etc/namedb/rndc.key";
>acl internals {
>aa.bb.cc.0/20;
>192.168.1.0/24;
>127.0.0.0/8;
>};
>controls {
> inet 127.0.0.1 port 53 allow { 127.0.0.1; } keys { rndc-key; };
>};
>options {
> pid-file "/var/run/named.pid";
> directory "/etc/namedb";
> statistics-file "/var/log/named/named.stats";
> dump-file "/var/log/named/named.dump";
> zone-statistics yes;
> allow-query { 127.0.0.1; 66.187.80.0/20; };
>};
>logging {
> category "default" { simple_log; };
> channel simple_log {
> file "/var/log/named/named.log" versions 5 size 20m;
> severity warning;
> print-time yes;
> print-category yes;
> print-severity yes;
>};
>...
>
>
> ---
> PCShare.Com
>
> ___
> 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"
>
___
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"
rndc: connect failed: 127.0.0.1#953: connection refused
My BIND9.6.0 on FreeBSD 6.2 works fine when I manually start with:
r...@ns2# named -4 -S 1024 -c /etc/namedb/named.conf
But it won't start on boot and no error messages or log. And it won't start
using rndc, it cause error message. Why does the error shows port 953 when I
specified for port 53 in the config?
rndc: connect failed: 127.0.0.1#953: connection refused
Below are parts of my configs:
/etc/rc.conf:
named_enable="YES"
named_flags="-4 -S 1024 -c /etc/namedb/named.conf"
/etc/rndc.key:
key "rndc-key" {
algorithm hmac-md5;
secret "y9eca/WZydNfi...";
};
/etc/namedb/rndc.conf:
include "/etc/namedb/rndc.key";
options {
default-server localhost;
default-key "rndc-key";
};
server localhost {
key "rndc-key";
};
...
/etc/namedb/named.conf:
include "/etc/namedb/rndc.key";
acl internals {
aa.bb.cc.0/20;
192.168.1.0/24;
127.0.0.0/8;
};
controls {
inet 127.0.0.1 port 53 allow { 127.0.0.1; } keys { rndc-key; };
};
options {
pid-file "/var/run/named.pid";
directory "/etc/namedb";
statistics-file "/var/log/named/named.stats";
dump-file "/var/log/named/named.dump";
zone-statistics yes;
allow-query { 127.0.0.1; 66.187.80.0/20; };
};
logging {
category "default" { simple_log; };
channel simple_log {
file "/var/log/named/named.log" versions 5 size 20m;
severity warning;
print-time yes;
print-category yes;
print-severity yes;
};
...
---
PCShare.Com
___
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"
KLD cbb.ko: depends on exca - not available
Hi. FreeBSD 7-STABLE. Subj message appears when I try to kldload cbb.ko and kernel cannot find exca due to its non-existence. The pccbb(4) manpage doesn't mention exca. make install exca helps with kldload, now: cbb0: at device 1.0 on pci1 cbb0: [ITHREAD] Would it be correct to add a new entry to the pccbb synopsis? --- src/share/man/man4/pccbb.4.orig2009-03-18 00:22:09.0 +0300 +++ src/share/man/man4/pccbb.4 2009-03-18 00:22:42.0 +0300 @@ -34,6 +34,7 @@ .Cd device cbb .Cd device pccard .Cd device cardbus +.Cd device exca .Sh DESCRIPTION The .Nm -- wbr, pluknet ___ 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: general: warning: max open files (3636) is smaller than maxsockets (4096)
Nice!!! Thank you. --- PCShare.Com -Original message- From: David Kelly dke...@hiwaay.net Date: Tue, 17 Mar 2009 20:32:10 -0600 To: Squirrel squir...@mail.isot.com Subject: Re: general: warning: max open files (3636) is smaller than maxsockets (4096) > On Tue, Mar 17, 2009 at 12:31:43PM -0600, Squirrel wrote: > > This happend since I've upgraded bind 9.21 to 9.6.0. I've increased > > the max open files to 4096: > > > >sysctl -w kern.maxfiles=4096 > > > > which shows it resized from 4040->4096 > > > > But I guess it's different for bind? I've googled and found several > > references to this warning message, but everyone states it's not a > > problem and shouldn't be concerned. Some real advice would be > > appreciated. > > Depends a lot as to how busy your name server is, I guess. > > Mine is a lightly loaded in internal office use. When my PII 450 MHz > 192MB machine issued similar complaint on upgrade of bind I was tricked > into rebooting a machine with over 800 days uptime only to get the exact > same message again. > > So I limited the number of sockets named would ask for using this in > /etc/rc.conf: > > named_flags="-4 -S 1024" > > -- > David Kelly N4HHE, dke...@hiwaay.net > > Whom computers would destroy, they must first drive mad. > ___ > 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" > ___ 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: [HEADS UP] drm merged to -STABLE
On Tue, 2009-03-17 at 12:20 -0500, Greg Rivers wrote: > On Sat, 10 Jan 2009, Robert Noland wrote: > > > I just merged drm (Direct Rendering) from HEAD. > > > >- Support for latest Intel chips > >- Support and fixes for many AMD/ATI chips r500 and below > >- Support AMD/ATI IGP based chips (rs690/rs485) > >- Lots of code cleanups > >- Lots of other fixes and changes since the existing drm > > is 2+ years old > > > > If you are experiencing a "garbled" screen with certain pci/pci-e based > > radeons, I have another patch in HEAD that isn't included yet. > > > > I have a workstation with a [Radeon X600 (PCIE)] card. The X display has > been garbled since these DRM updates went in in January, and remains > garbled with 7.1-STABLE as of yesterday. As a work-around, I'm running > the up-to-date 7.1-STABLE system (both world and ports) with a > 7.1-RELEASE-p2 kernel. The display is fine with the old kernel and X > works great; I even see dramatically improved performance with the new > Xorg and EXA acceleration. Your work is much appreciated. > > But the garbled display with the recent DRM still plagues me. > > Here's how pciconf identifies the card: > vgap...@pci0:1:0:0: class=0x03 card=0x06021002 chip=0x5b621002 rev=0x00 > hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'RV380 RADEON X600 Series 265MB' > class = display > subclass = VGA > vgap...@pci0:1:0:1: class=0x038000 card=0x06031002 chip=0x5b721002 rev=0x00 > hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Radeon X600 Series - Secondary' > class = display > > The old DRM probe: > vgapci0: port 0x2000-0x20ff mem > 0xe000-0xe7ff,0xe850-0xe850 irq 16 at device 0.0 on pci1 > drm0: on vgapci0 > info: [drm] Initialized radeon 1.25.0 20060524 > vgapci1: mem 0xe851-0xe851 at device 0.1 on > pci1 > ... > vgapci0: Reserved 0x1 bytes for rid 0x18 type 3 at 0xe850 > vgapci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xe000 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading R300 Microcode > info: [drm] writeback test succeeded in 1 usecs > ioapic0: Assigning PCI IRQ 16 to local APIC 0 > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 60 > drm0: [MPSAFE] > > The new DRM probe: > vgapci0: port 0x2000-0x20ff mem > 0xe000-0xe7ff,0xe850-0xe850 irq 16 at device 0.0 on pci1 > drm0: on vgapci0 > vgapci0: Reserved 0x1 bytes for rid 0x18 type 3 at 0xe850 > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] Initialized radeon 1.29.0 20080528 > vgapci1: mem 0xe851-0xe851 at device 0.1 on > pci1 > ... > vgapci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xe000 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading R300 Microcode > info: [drm] Num pipes: 1 > info: [drm] writeback test succeeded in 1 usecs > ioapic0: Assigning PCI IRQ 16 to local APIC 0 > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 59 > drm0: [MPSAFE] > drm0: [ITHREAD] > info: [drm] Num pipes: 1 > > Difference between the Xorg logs when it's working and when it's not: > --- ok/Xorg.0.log 2009-03-16 14:39:40.0 -0500 > +++ garbled/Xorg.0.log2009-03-16 14:46:13.0 -0500 > @@ -6 +6 @@ > -Current Operating System: FreeBSD xxx.xxx.x.xxx 7.1-RELEASE-p2 FreeBSD > 7.1-RELEASE-p2 #0: Fri Jan 16 18:00:35 CST 2009 > r...@xxx.xxx.x.xxx:/usr/obj/usr/src/sys/SMALL-SMP i386 > +Current Operating System: FreeBSD xxx.xxx.x.xxx 7.1-STABLE FreeBSD > 7.1-STABLE #0: Mon Mar 16 11:42:42 CDT 2009 > r...@xxx.xxx.x.xxx:/usr/obj/usr/src/sys/SMALL-SMP i386 > @@ -14 +14 @@ > -(==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 16 14:39:34 2009 > +(==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 16 14:22:00 2009 > @@ -407 +407 @@ > -(II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module > version 1.25.0 > +(II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module > version 1.29.0 > @@ -774,5 +774,5 @@ > -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xc56d4000 > -(II) RADEON(0): [pci] ring handle = 0xc56d4000 > -(II) RADEON(0): [pci] Ring mapped at 0x90a0 > -(II) RADEON(0): [pci] Ring contents 0x > -(II) RADEON(0): [pci] ring read ptr handle = 0xc57d5000 > +(II) RADEON(0): [pci] 32768 kB allocated with handle 0xe7732000 > +(II) RADEON(0): [pci] ring handle = 0xe7732000 > +(II) RADEON(0): [pci] Ring mapped at 0x88a0 > +(II) RADEON(0): [pci] Ring contents 0xff7d8c94 > +(II) RADEON(0): [pci] ring read ptr handle = 0xe7833000 > @@ -780,6 +780,6 @@ > -(II) RADEON(0): [pci] Ring read ptr contents 0x > -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xc57d6000 > -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x90b01000 > -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x > -(II) R
Re: FreeBSD 7.2 Release process starting...
On Tue, Mar 17, 2009 at 10:19:11AM -0400, Ken Smith wrote: > > We're starting the release process for FreeBSD 7.2-RELEASE. The major > highlights of the schedule are: Is there a chance the latest ZFS bugfixes from CURRENT will make it into 7.2-RELEASE? Regards, Holger ___ 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: general: warning: max open files (3636) is smaller than max sockets (4096)
On Tue, Mar 17, 2009 at 12:31:43PM -0600, Squirrel wrote: > This happend since I've upgraded bind 9.21 to 9.6.0. I've increased > the max open files to 4096: > >sysctl -w kern.maxfiles=4096 > > which shows it resized from 4040->4096 > > But I guess it's different for bind? I've googled and found several > references to this warning message, but everyone states it's not a > problem and shouldn't be concerned. Some real advice would be > appreciated. Depends a lot as to how busy your name server is, I guess. Mine is a lightly loaded in internal office use. When my PII 450 MHz 192MB machine issued similar complaint on upgrade of bind I was tricked into rebooting a machine with over 800 days uptime only to get the exact same message again. So I limited the number of sockets named would ask for using this in /etc/rc.conf: named_flags="-4 -S 1024" -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ 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"
general: warning: max open files (3636) is smaller than max sockets (4096)
This happend since I've upgraded bind 9.21 to 9.6.0. I've increased the max open files to 4096: sysctl -w kern.maxfiles=4096 which shows it resized from 4040->4096 But I guess it's different for bind? I've googled and found several references to this warning message, but everyone states it's not a problem and shouldn't be concerned. Some real advice would be appreciated. ___ 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: GCC build causes panic: page already inserted
On Mon, 16 Mar 2009 17:23:09 -0600 Dan Allen wrote: > It turns out that one must have a debug kernel around. I use STABLE > as a production system. There is no "kernel.debug" on my system. I > guess I therefore cannot provide a stack trace. Have you disbled building of the kernel.debug then? It is enabled as default on -STABLE. r...@kg-work2# uname -a FreeBSD kg-work2.kg4.no 7.1-STABLE FreeBSD 7.1-STABLE #4: Sun Feb 8 20:56:08 CET 2009 r...@kg-work2.kg4.no:/usr/obj/usr/src/sys/SX270 i386 r...@kg-work2# locate kernel.debug /usr/obj/usr/src/sys/GENERIC/kernel.debug /usr/obj/usr/src/sys/SX270/kernel.debug HTH -- Regards, Torfinn Ingolfsen ___ 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: [HEADS UP] drm merged to -STABLE
On Sat, 10 Jan 2009, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a "garbled" screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I have a workstation with a [Radeon X600 (PCIE)] card. The X display has been garbled since these DRM updates went in in January, and remains garbled with 7.1-STABLE as of yesterday. As a work-around, I'm running the up-to-date 7.1-STABLE system (both world and ports) with a 7.1-RELEASE-p2 kernel. The display is fine with the old kernel and X works great; I even see dramatically improved performance with the new Xorg and EXA acceleration. Your work is much appreciated. But the garbled display with the recent DRM still plagues me. Here's how pciconf identifies the card: vgap...@pci0:1:0:0: class=0x03 card=0x06021002 chip=0x5b621002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'RV380 RADEON X600 Series 265MB' class = display subclass = VGA vgap...@pci0:1:0:1: class=0x038000 card=0x06031002 chip=0x5b721002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon X600 Series - Secondary' class = display The old DRM probe: vgapci0: port 0x2000-0x20ff mem 0xe000-0xe7ff,0xe850-0xe850 irq 16 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] Initialized radeon 1.25.0 20060524 vgapci1: mem 0xe851-0xe851 at device 0.1 on pci1 ... vgapci0: Reserved 0x1 bytes for rid 0x18 type 3 at 0xe850 vgapci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xe000 info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] writeback test succeeded in 1 usecs ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 60 drm0: [MPSAFE] The new DRM probe: vgapci0: port 0x2000-0x20ff mem 0xe000-0xe7ff,0xe850-0xe850 irq 16 at device 0.0 on pci1 drm0: on vgapci0 vgapci0: Reserved 0x1 bytes for rid 0x18 type 3 at 0xe850 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 vgapci1: mem 0xe851-0xe851 at device 0.1 on pci1 ... vgapci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xe000 info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 59 drm0: [MPSAFE] drm0: [ITHREAD] info: [drm] Num pipes: 1 Difference between the Xorg logs when it's working and when it's not: --- ok/Xorg.0.log 2009-03-16 14:39:40.0 -0500 +++ garbled/Xorg.0.log 2009-03-16 14:46:13.0 -0500 @@ -6 +6 @@ -Current Operating System: FreeBSD xxx.xxx.x.xxx 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Fri Jan 16 18:00:35 CST 2009 r...@xxx.xxx.x.xxx:/usr/obj/usr/src/sys/SMALL-SMP i386 +Current Operating System: FreeBSD xxx.xxx.x.xxx 7.1-STABLE FreeBSD 7.1-STABLE #0: Mon Mar 16 11:42:42 CDT 2009 r...@xxx.xxx.x.xxx:/usr/obj/usr/src/sys/SMALL-SMP i386 @@ -14 +14 @@ -(==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 16 14:39:34 2009 +(==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 16 14:22:00 2009 @@ -407 +407 @@ -(II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.25.0 +(II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.29.0 @@ -774,5 +774,5 @@ -(II) RADEON(0): [pci] 32768 kB allocated with handle 0xc56d4000 -(II) RADEON(0): [pci] ring handle = 0xc56d4000 -(II) RADEON(0): [pci] Ring mapped at 0x90a0 -(II) RADEON(0): [pci] Ring contents 0x -(II) RADEON(0): [pci] ring read ptr handle = 0xc57d5000 +(II) RADEON(0): [pci] 32768 kB allocated with handle 0xe7732000 +(II) RADEON(0): [pci] ring handle = 0xe7732000 +(II) RADEON(0): [pci] Ring mapped at 0x88a0 +(II) RADEON(0): [pci] Ring contents 0xff7d8c94 +(II) RADEON(0): [pci] ring read ptr handle = 0xe7833000 @@ -780,6 +780,6 @@ -(II) RADEON(0): [pci] Ring read ptr contents 0x -(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xc57d6000 -(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x90b01000 -(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x -(II) RADEON(0): [pci] GART texture map handle = 0xc59d6000 -(II) RADEON(0): [pci] GART Texture map mapped at 0x90d01000 +(II) RADEON(0): [pci] Ring read ptr contents 0xff18 +(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xe7834000 +(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x90c
Re: Crazy "interrupt storm detected" on atapci0
Nicolais wrote: Also - this was extracted from kenv: smbios.system.maker="MICRO-STAR INTERANTIONAL CO.,LTD" smbios.system.product="MS-7368" as I supposed in previous message your MB is MicroStar product. So I insist that you read thread [1] in freebsd-stable named 'Interrupt storm' started by Dan Langille [1] http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047645.html -- SY, Marat ___ 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: Crazy "interrupt storm detected" on atapic0
Nicolai wrote: Hi all, I have had this problem since day 1 on my new server. It has run since November 15th 2008, and serve approx. 10 GB worth of web traffic per month for the main site and then some 40 domains with mail and small web pages. (hence - it's NOT that busy yet) I started with 7.1-RELEASE-pX since I didn't have problems straight off - but it didn't last long. After a few days of running, the interrupt storm on atapci0 starts to show. It slowly builds up and continues. When it reaches 150-200k/sec. I reboot just to be on the safe side. I have also upgraded to 7.1-STABLE to get all the ATA driver changes S.O.S. have been including. Still no visible change. To give you an impression of its impact, I will let the numbers speak for thmeselves: $ uname -v FreeBSD 7.1-STABLE #1: Thu Mar 12 14:22:49 CET 2009 $ uname -m amd64 $ uptime 2:36PM up 4 days, 22:12, 5 users, load averages: 0.28, 0.40, 0.19 $ tail -10 messages Mar 17 13:42:37 box last message repeated 600 times Mar 17 13:52:37 box last message repeated 600 times Mar 17 14:02:37 box last message repeated 600 times Mar 17 14:12:37 box last message repeated 600 times Mar 17 14:22:37 box last message repeated 600 times Mar 17 14:32:22 box last message repeated 585 times Mar 17 14:32:23 box kernel: pid 78195 (try), uid 0: exited on signal 10 (core dumped) Mar 17 14:32:23 box kernel: interrupt storm detected on "irq22:"; throttling interrupt source Mar 17 14:32:54 box last message repeated 31 times Mar 17 14:34:55 box last message repeated 121 times $ vmstat -i interrupt total rate irq1: atkbd0 3 0 irq9: acpi0 1 0 irq16: ohci0 1 0 irq17: ohci1 ohci3 1 0 irq18: ohci2 ohci4 1 0 irq22: atapci0 57317362717 134713 cpu0: timer 850996016 2000 cpu1: timer 850995703 2000 Total 59019354443 138713 [r...@box /etc]# atacontrol mode ad4 current mode = SATA300 [r...@box /etc]# atacontrol mode ad6 current mode = SATA300 Some relevant lines from dmesg: atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] And a few lines from pciconf: atap...@pci0:0:18:0: class=0x01018f card=0x73271462 chip=0x43801002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'IXP SB600 Serial ATA Controller' class = mass storage subclass = ATA ...so - this is where I'm at. Interrupt storm raises through the roof in just 3 days, and continues to raise. Just for kicks I tried disabling AHCI with nextboot, but that made the box not boot. Also - I'm 1000 KM. away from the box - so I'm a little limited to testing fancy boot options - apart from things that can go in nextboot.conf. If anyone have any hints on how to proceed, I would be grateful. Thank you in advance - Nicolai ___ 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" take a look of our 'interrupt storm issue' in January, I "resolved" similar case by installing KDB/DDB enabled kernel i suppose that MB is Microstar? -- SY, Marat ___ 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: Crazy "interrupt storm detected" on atapci0
Also - this was extracted from kenv: LINES="24" acpi_load="YES" bootfile="kernel" comconsole_speed="9600" console="vidconsole" currdev="disk0s1a:" hint.acpi.0.oem="ACPIAM" hint.acpi.0.revision="1" hint.acpi.0.rsdp="0xf98a0" hint.acpi.0.rsdt="0x7dfd" hint.atkbd.0.at="atkbdc" hint.atkbd.0.irq="1" hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x060" hint.fd.0.at="fdc0" hint.fd.0.drive="0" hint.fd.1.at="fdc0" hint.fd.1.drive="1" hint.fdc.0.at="isa" hint.fdc.0.drq="2" hint.fdc.0.irq="6" hint.fdc.0.port="0x3F0" hint.ppc.0.at="isa" hint.ppc.0.irq="7" hint.psm.0.at="atkbdc" hint.psm.0.irq="12" hint.sc.0.at="isa" hint.sc.0.flags="0x100" hint.sio.0.at="isa" hint.sio.0.flags="0x10" hint.sio.0.irq="4" hint.sio.0.port="0x3F8" hint.sio.1.at="isa" hint.sio.1.irq="3" hint.sio.1.port="0x2F8" hint.sio.2.at="isa" hint.sio.2.disabled="1" hint.sio.2.irq="5" hint.sio.2.port="0x3E8" hint.sio.3.at="isa" hint.sio.3.disabled="1" hint.sio.3.irq="9" hint.sio.3.port="0x2E8" hint.vga.0.at="isa" interpret="OK" kernel="kernel" kernel_options="" kernelname="/boot/kernel/kernel" loaddev="disk0s1a:" mac_ifoff="NO" module_path="/boot/kernel;/boot/modules" smbios.bios.reldate="10/31/2007" smbios.bios.vendor="American Megatrends Inc." smbios.bios.version="V1.5B2" smbios.chassis.maker="To Be Filled By O.E.M." smbios.chassis.serial="To Be Filled By O.E.M." smbios.chassis.tag="To Be Filled By O.E.M." smbios.chassis.version="To Be Filled By O.E.M." smbios.planar.maker="MICRO-STAR INTERANTIONAL CO.,LTD" smbios.planar.product="MS-7368" smbios.planar.serial="To be filled by O.E.M." smbios.planar.version="1.0" smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="MICRO-STAR INTERANTIONAL CO.,LTD" smbios.system.product="MS-7368" smbios.system.serial="To Be Filled By O.E.M." smbios.system.version="1.0" vfs.root.mountfrom="ufs:/dev/mirror/gm0s1a" (sorry for spelling error in subject s/atapic/atapci/) -- View this message in context: http://www.nabble.com/Crazy-%22interrupt-storm-detected%22-on-atapic0-tp22560101p22561413.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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"
FreeBSD 7.2 Release process starting...
We're starting the release process for FreeBSD 7.2-RELEASE. The major highlights of the schedule are: Code Freeze:March 23rd BETA1 March 30th Branch April 10th RC1 April 13th RC2 April 20th Release:May 4th The full schedule is here: http://www.freebsd.org/releases/7.2R/schedule.html though most of "the other events" haven't been given specific dates yet. Since it's often the case that developers process quite a few outstanding MFCs during the last couple days before a code freeze starts I have changed RELENG_7 to say it is 7.2-PRERELEASE now as a bit of a heads-up that the release cycle is imminent. You might need to be a tiny bit more careful using RELENG_7 right now because the odds of you getting a snapshot of the tree taken part way through someone doing something that required multiple commits goes up during this phase of a release. Thanks. -- Ken Smith - From there to here, from here to | kensm...@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Crazy "interrupt storm detected" on atapic0
Hi all, I have had this problem since day 1 on my new server. It has run since November 15th 2008, and serve approx. 10 GB worth of web traffic per month for the main site and then some 40 domains with mail and small web pages. (hence - it's NOT that busy yet) I started with 7.1-RELEASE-pX since I didn't have problems straight off - but it didn't last long. After a few days of running, the interrupt storm on atapci0 starts to show. It slowly builds up and continues. When it reaches 150-200k/sec. I reboot just to be on the safe side. I have also upgraded to 7.1-STABLE to get all the ATA driver changes S.O.S. have been including. Still no visible change. To give you an impression of its impact, I will let the numbers speak for thmeselves: $ uname -v FreeBSD 7.1-STABLE #1: Thu Mar 12 14:22:49 CET 2009 $ uname -m amd64 $ uptime 2:36PM up 4 days, 22:12, 5 users, load averages: 0.28, 0.40, 0.19 $ tail -10 messages Mar 17 13:42:37 box last message repeated 600 times Mar 17 13:52:37 box last message repeated 600 times Mar 17 14:02:37 box last message repeated 600 times Mar 17 14:12:37 box last message repeated 600 times Mar 17 14:22:37 box last message repeated 600 times Mar 17 14:32:22 box last message repeated 585 times Mar 17 14:32:23 box kernel: pid 78195 (try), uid 0: exited on signal 10 (core dumped) Mar 17 14:32:23 box kernel: interrupt storm detected on "irq22:"; throttling interrupt source Mar 17 14:32:54 box last message repeated 31 times Mar 17 14:34:55 box last message repeated 121 times $ vmstat -i interrupt total rate irq1: atkbd0 3 0 irq9: acpi0 1 0 irq16: ohci0 1 0 irq17: ohci1 ohci3 1 0 irq18: ohci2 ohci4 1 0 irq22: atapci0 57317362717 134713 cpu0: timer 850996016 2000 cpu1: timer 850995703 2000 Total 59019354443 138713 [r...@box /etc]# atacontrol mode ad4 current mode = SATA300 [r...@box /etc]# atacontrol mode ad6 current mode = SATA300 Some relevant lines from dmesg: atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] And a few lines from pciconf: atap...@pci0:0:18:0: class=0x01018f card=0x73271462 chip=0x43801002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'IXP SB600 Serial ATA Controller' class = mass storage subclass = ATA ...so - this is where I'm at. Interrupt storm raises through the roof in just 3 days, and continues to raise. Just for kicks I tried disabling AHCI with nextboot, but that made the box not boot. Also - I'm 1000 KM. away from the box - so I'm a little limited to testing fancy boot options - apart from things that can go in nextboot.conf. If anyone have any hints on how to proceed, I would be grateful. Thank you in advance - Nicolai ___ 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: GCC build causes panic: page already inserted
On Mon, Mar 16, 2009 at 5:47 PM, Dan Allen wrote: > > On 16 Mar 2009, at 1:01 PM, Alan Cox wrote: > >> For now, can you just provide the stack trace? > > As I mentioned, I am unable to do so - I have no kernel.debug. > > However, I am trying to reproduce the bug again. (It takes a while.) > Although it has not yet crashed, I noticed another unusual behavior: > > Normally during my gcc builds the 1 GB of swap space is never touched. My > main 1 GB of RAM is sufficient and there is always at least 100 MB of free > memory. > > Today I saw a STATE listed when running top that I have never seen, called > "wdrain". This happened when I saw my free memory plummet down to only 20 > MB free (out of 1 GB). This state appears to be set in > /usr/src/sys/kern/vfs_bio.c in a routine called waitrunningbufspace(). This > file also was modified March 1st. I do not know if there is a connection... > > The last time I built gcc-4.4 was probably just before this. (I build gcc > whenever there is a new version, within a couple of days of it being added > to ports. There was about two weeks with no new versions this first half of > March so it has been a couple of weeks...) > > I am tempted to go back to about Feb 28th kernel-wise and try the gcc build > again and see if it works or panics. > > Any suggestions as to how I can help narrow this down? - Which platform are you using: i386 or amd64? - Is there a particular file that it tries to compile when it runs out of memory? - What are your CFLAGS in make.conf? Thanks, -Garrett ___ 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"
RELENG_7/i386: ZFS panic on reboot
while rebooting: (kgdb) bt #0 doadump () at pcpu.h:196 #1 0x80514298 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0x80514575 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0x806a74d4 in trap_fatal (frame=0xbf5b9a24, eva=12) at /usr/src/sys/i386/i386/trap.c:939 #4 0x806a771d in trap_pfault (frame=0xbf5b9a24, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:852 #5 0x806a808a in trap (frame=0xbf5b9a24) at /usr/src/sys/i386/i386/trap.c:530 #6 0x8069016b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0x80806610 in gfs_dir_create (struct_size=132, pvp=0x87b388a0, vfsp=0x87a93b40, ops=0x808817a0, entries=0x0, inode_cb=0, maxlen=256, readdir_cb=0x808636c6 , lookup_cb=0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c:420 #8 0x80863420 in zfsctl_mknode_snapdir (pvp=0x87b388a0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:783 #9 0x808069e9 in gfs_dir_lookup (dvp=0x87b388a0, nm=0x8087dfae "snapshot", vpp=0xbf5b9b60) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c:630 #10 0x808630bc in zfsctl_root_lookup (dvp=0x87b388a0, nm=0x8087dfae "snapshot", vpp=0xbf5b9b60, pnp=0x0, flags=0, rdir=0x0, cr=0x85e84000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:396 #11 0x808638fa in zfsctl_umount_snapshots (vfsp=0x87a93b40, fflags=524288, cr=0x85e84000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:1063 #12 0x8086b1dc in zfs_umount (vfsp=0x87a93b40, fflag=524288, td=0x85e8ecc0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:692 #13 0x80586ea4 in dounmount (mp=0x87a93b40, flags=524288, td=0x85e8ecc0) at /usr/src/sys/kern/vfs_mount.c:1293 #14 0x8058a4e8 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2944 #15 0x80514005 in boot (howto=16392) at /usr/src/sys/kern/kern_shutdown.c:400 #16 0x8051445d in reboot (td=0x85e8ecc0, uap=0xbf5b9cfc) at /usr/src/sys/kern/kern_shutdown.c:172 #17 0x806a7a60 in syscall (frame=0xbf5b9d38) at /usr/src/sys/i386/i386/trap.c:1090 #18 0x806901d0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #19 0x0033 in ?? () Any additional info needed? Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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"
Appeal for active bug reports relating to TCP, UDP, routing locking in 7-STABLE
Dear all: With 7.2 approaching, I wanted to review the set of known network bug reports (especially panics, hangs, lock order reversals) relating to TCP, UDP, sockets, and routing in 7-STABLE. If you are aware of problems along these that you can confirm definitely occur with 7-STABLE checked out no earlier than 17 March, 2009, please drop me a private e-mail with a pointer to the thread, PR, or a reminder that you've sent me the details already. If you don't have a PR open on the problem, opening one and forwarding me the receipt so I can grab ownership would be most welcome. I don't promise I can get them fixed by the release, but doing a review and prioritizing the bugs that are known is a useful step in that direction. I am specifically not interested in device driver-related problems, not because they shouldn't be fixed, but because there's only so much time in the day and it appears folks like Pyun have it well in hand :-). Robert N M Watson Computer Laboratory University of Cambridge ___ 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: Page fault panic in scioctl and console-kit-daemon
I switched to xfce myself and did not reinstall consolekit… don't know how armfull it could be though… Le 17 mars 09 à 10:31, Arrigo Marchiori a écrit : Hello, On Fri, Mar 13, 2009 at 01:24:57PM +0100, Arrigo Marchiori wrote: On Mon, Mar 09, 2009 at 12:15:15PM +0100, spara wrote: [...] Any other fix ? It seems to me that no package has been depending on consolekit, since a couple of days. At least, portupgrade is not showing any more "stale dependencies" when I try to "portupgrade -aR" without having consolekit installed. So I'm living happily without it. :-) I answer to myself: after upgrading to hal-0.5.11_21 consolekit is required again. This problem has returned. :-( -- rigo http://rigo.altervista.org ___ 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: Page fault panic in scioctl and console-kit-daemon
Hello, On Fri, Mar 13, 2009 at 01:24:57PM +0100, Arrigo Marchiori wrote: > On Mon, Mar 09, 2009 at 12:15:15PM +0100, spara wrote: [...] > > Any other fix ? > > It seems to me that no package has been depending on consolekit, since > a couple of days. At least, portupgrade is not showing any more "stale > dependencies" when I try to "portupgrade -aR" without having > consolekit installed. So I'm living happily without it. :-) I answer to myself: after upgrading to hal-0.5.11_21 consolekit is required again. This problem has returned. :-( -- rigo http://rigo.altervista.org ___ 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"
