freebsd-stable Digest, Vol 154, Issue 7
freebsd-sta...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
or, via email, send a message with subject or body 'help' to
freebsd-sta...@freebsd.org
You can reach the person managing the list at
freebsd-st...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-stable digest..."
Today's Topics:
1. SSH debug messages (Michael Vince)
2. Re: portsnap mirror servers (Benjamin Lutz)
3. Re: SSH debug messages (Michael Vince)
4. powernow0: no match for extended cpuid 780 (Stefan 'Steve' Tell)
5. Re: portsnap mirror servers (Paul Mather)
6. Re: portsnap mirror servers (Colin Percival)
7. RE: Intel EtherExpress Pro ISA card (Matt Smith)
8. Fwd: Prototyping for basejail distribuition (Ricardo A. Reis)
9. iir + Tyan S2460 + SMP problems (Douglas K. Rand)
10. Re: iir + Tyan S2460 + SMP problems (John-Mark Gurney)
11. Re: iir + Tyan S2460 + SMP problems (Douglas K. Rand)
12. Re: iir + Tyan S2460 + SMP problems (John-Mark Gurney)
13. Re: FreeBSD 6.1-PRERELEASE (April 5, 2006) randomly rebooting
on Dell Poweredge 650 (Adriaan Stable)
14. Re: FreeBSD 6.1-PRERELEASE (April 5, 2006) randomly rebooting
on Dell Poweredge 650 (Darren Pilgrim)
15. Re: iir + Tyan S2460 + SMP problems (Scott Long)
16. irq question (Zoran Kolic)
17. 4-STABLE panic, samba related maybe? (Mark Cullen)
----------------------------------------------------------------------
Message: 1
Date: Fri, 21 Apr 2006 22:31:01 +1000
From: Michael Vince <m...@thebeastie.org>
Subject: SSH debug messages
To: sta...@freebsd.org
Message-ID: <4448D085...@thebeastie.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Hey all,
Since using 6-stable for the last few months I keep getting these ssh
client/server? debug messages, I wasn't that annoyed with them at first
I figured it was just something part of 6.1 betas but now its just
getting annoying, and I am still getting them on the latest rc1 build.
Here is a copy and paste of what I get, I get them almost all the time
in programs like 'mc'
"debug2: channel 0: window 31272 sent adjust 34264"
Anyone know how to make these go away?
Cheers,
Mike
------------------------------
Message: 2
Date: Fri, 21 Apr 2006 14:40:25 +0200
From: Benjamin Lutz <ben...@datacomm.ch>
Subject: Re: portsnap mirror servers
To: freebsd...@freebsd.org
Cc: Colin Percival <cper...@freebsd.org>
Message-ID: <200604211440....@datacomm.ch>
Content-Type: text/plain; charset="iso-8859-1"
On Wednesday 19 April 2006 00:44, Colin Percival wrote:
> I have a list of people who have offered mirrors, but so far I haven't
> seen any need for additional mirrors -- the two which already exist are
> showing no signs of slowing down.
Hm, but I see a quite noticeable speed difference between portsnap1 and
portsnap2. The second one is quite a bit faster.
Cheers
Benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060421/b9afdd39/attachment-0001.pgp
------------------------------
Message: 3
Date: Fri, 21 Apr 2006 23:02:43 +1000
From: Michael Vince <m...@thebeastie.org>
Subject: Re: SSH debug messages
To: sta...@freebsd.org
Message-ID: <4448D7F3...@thebeastie.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Michael Vince wrote:
> Hey all,
>
> Since using 6-stable for the last few months I keep getting these ssh
> client/server? debug messages, I wasn't that annoyed with them at
> first I figured it was just something part of 6.1 betas but now its
> just getting annoying, and I am still getting them on the latest rc1
> build.
> Here is a copy and paste of what I get, I get them almost all the time
> in programs like 'mc'
> "debug2: channel 0: window 31272 sent adjust 34264"
>
> Anyone know how to make these go away?
>
> Cheers,
> Mike
OK I know what is now, its because I am putting -v on my ssh command,
silly me.
Thanks for those who emailed me to let me know.
Mike
------------------------------
Message: 4
Date: 21 Apr 2006 16:11:00 +0000
From: steve...@crashmail.de (Stefan 'Steve' Tell)
Subject: powernow0: no match for extended cpuid 780
To: freebsd...@freebsd.org
Message-ID: <9sGmN...@zeus.crashmail.de>
Content-Type: text/plain; charset=US-ASCII
Hi,
I tried to install FreeBSD 6.1-RC1 on my Acer Aspire 1304LC Notebook. That
notebook has a "AMD Athlon XP 1800+" CPU.
The installation process succeeded but I can't get any power management to
work. If I load cpufreq.ko I get:
powernow0: <PowerNow! K7> on cpu0
powernow0: ACPI MAX frequency not found
powernow0: no match for extended cpuid 780
device_attach: powernow0 attach returned 6
"/etc/rc.d/powerd start" brings
powerd: lookup freq: No such file or directory
Are there any chances to get a working cpufreq-mechanism on that machine?
Here you can find the dmesg output:
* <http://daemon.crashmail.de/~stell/paradise_dmesg.txt>
And a complete lists of all sysctls:
* <http://daemon.crashmail.de/~stell/paradise_sysctl.txt>
very litte hw.acpi.*, hum?
Thanks in advance.
------------------------------
Message: 5
Date: Fri, 21 Apr 2006 15:24:20 +0100
From: Paul Mather <pa...@gromit.dlib.vt.edu>
Subject: Re: portsnap mirror servers
To: Benjamin Lutz <ben...@datacomm.ch>
Cc: freebsd...@freebsd.org, Colin Percival <cper...@freebsd.org>
Message-ID: <1145629460.3...@dell8600.dlib.vt.edu>
Content-Type: text/plain
On Fri, 2006-04-21 at 14:40 +0200, Benjamin Lutz wrote:
> On Wednesday 19 April 2006 00:44, Colin Percival wrote:
> > I have a list of people who have offered mirrors, but so far I haven't
> > seen any need for additional mirrors -- the two which already exist are
> > showing no signs of slowing down.
>
> Hm, but I see a quite noticeable speed difference between portsnap1 and
> portsnap2. The second one is quite a bit faster.
I notice that on 4.x portsnap never finds any mirrors because the grep
of the output returned by "host -t srv ..." is not appropriate for 4.x's
version of /usr/bin/host, which produces output different to that of 5.x
onwards (a BIND8 vs BIND9 issue, I guess). So, maybe because of this,
all of the portsnaps running on 4.x machines are hitting the same server
each time instead of randomly choosing a mirror, thereby causing that
mirror to be a bit more loaded?
Cheers,
Paul.
--
e-mail: pa...@gromit.dlib.vt.edu
"Without music to decorate it, time is just a bunch of boring production
deadlines or dates by which bills must be paid."
--- Frank Vincent Zappa
------------------------------
Message: 6
Date: Fri, 21 Apr 2006 10:19:51 -0700
From: Colin Percival <cper...@freebsd.org>
Subject: Re: portsnap mirror servers
To: Paul Mather <pa...@gromit.dlib.vt.edu>
Cc: Benjamin Lutz <ben...@datacomm.ch>, freebsd...@freebsd.org
Message-ID: <44491437...@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
Paul Mather wrote:
> On Fri, 2006-04-21 at 14:40 +0200, Benjamin Lutz wrote:
>> Hm, but I see a quite noticeable speed difference between portsnap1 and
>> portsnap2. The second one is quite a bit faster.
I'll look into this over the summer.
> I notice that on 4.x portsnap never finds any mirrors because the grep
> of the output returned by "host -t srv ..." is not appropriate for 4.x's
> version of /usr/bin/host, which produces output different to that of 5.x
> onwards (a BIND8 vs BIND9 issue, I guess). So, maybe because of this,
> all of the portsnaps running on 4.x machines are hitting the same server
> each time instead of randomly choosing a mirror, thereby causing that
> mirror to be a bit more loaded?
They are hitting the same server, but that server is portsnap2 (which is
also portsnap.daemonology.net, which is the default server for pre-1.0
versions of portsnap from the ports tree). Given that most systems running
portsnap are FreeBSD 6.0 or 6.1, this doesn't cause much differential
loading.
Colin Percival
------------------------------
Message: 7
Date: Fri, 21 Apr 2006 13:20:11 -0400
From: "Matt Smith" <rat...@charter.net>
Subject: RE: Intel EtherExpress Pro ISA card
To: <freebsd...@freebsd.org>
Message-ID: <000001c66567$daafa9a0$0201a8c0@bedroom>
Content-Type: text/plain; charset="us-ascii"
I have this card install in a System but the GENERIC kernel does not pick it
up. Is there a custom driver for this card or a step I'm missing.
Matt
------------------------------
Message: 8
Date: Fri, 21 Apr 2006 08:45:25 -0300
From: "Ricardo A. Reis" <ricar...@yahoo.com.br>
Subject: Fwd: Prototyping for basejail distribuition
To: freebsd...@freebsd.org
Message-ID: <op.s8cv9znwp1tyz6@localhost>
Content-Type: text/plain; charset="iso-8859-1"
------- Forwarded message -------
From: "Ricardo A. Reis" <ricar...@yahoo.com.br>
To: "freebsd-...@freebsd.org" <freebsd-...@freebsd.org>
Cc: "freebsd...@freebsd.org" <freebsd...@freebsd.org>
Subject: Prototyping for basejail distribuition
Date: Thu, 13 Apr 2006 17:21:38 -0300
Hi,
I attach 2 files in this email, the first is a Makefile and the second is
jail.conf.
For demonstre my idea i resolved create one "Pseudo Prototyping", for test
is necessary:
1 - Create dir /usr/local/basejail
2 - Copy Makefile to /usr/local/basejail
3 - Copy jail.conf to /etc
4 - The initial basejail is precompiled is distributed in CD1,
for simular basejail is necessary a installworld structure in
/usr/local/basejail
cd /usr/src ; make installworld DESTDIR=/usr/local/basejail
Now is necessary config jail.conf,
-----
#sample template for create freebsd jail
#
# RC.CONF GLOBAL VARIABLES
#
exec_start="/bin/sh /etc/rc"
exec_stop="/bin/sh /etc/rc.shutdown"
devfs_enable="NO"
fdescfs_enable="NO"
procfs_enable="NO"
mount_enable="NO"
devfs_ruleset="ruleset_name"
flags="-l -U root"
#
# JAIL RC.CONF
#
sendmail_enable="NO"
inetd_flags="-wW -a"
rpcbind_enable="NO"
network_interfaces=""
#
# FILES
#
copy_to_jail="/etc/localtime /etc/resolv.conf /etc/csh.cshrc
/etc/csh.login"
#
# JAILS
#
jail_node01_rootdir="/usr/jail/node01"
jail_node01_hostname="node01.example.com"
jail_node01_ip="127.0.0.1 "
jail_node02_rootdir="/usr/jail/node02"
jail_node02_hostname="node02.example.com"
jail_node02_ip="127.0.0.2 "
-------
In this moment is possible create large numbers of jail, i
implemente in makefile,
[root@daemon:/usr/local/basejail] # make
>>> Sample in /usr/share/examples/etc/jail.conf
jail == create jail
rcconf == create rc.conf for start jails
etcconfig == create rc.conf for jails and copy file
showconfig == show information
Thanks for any comments,
Sorry for my english and poor Makefile.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 5084 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060421/c26ce8d7/Makefile-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jail.conf
Type: application/octet-stream
Size: 686 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060421/c26ce8d7/jail-0001.obj
------------------------------
Message: 9
Date: Fri, 21 Apr 2006 16:59:33 -0500
From: "Douglas K. Rand" <ra...@meridian-enviro.com>
Subject: iir + Tyan S2460 + SMP problems
To: freebsd...@freebsd.org
Message-ID: <874q0mpp2y.wl%ra...@meridian-enviro.com>
Content-Type: text/plain; charset=US-ASCII
We're having problems with FreeBSD 5.4, 6.0, and 6.1 and an ICP Vortex
GDT8546RZ 4 port SATA RAID card in a Tyan S2460 system with dual AMD
Athlon MP 1600+ CPUs. We do not have any problems with this
configuration under FreeBSD 4.11, and we have the same ICP cards in
Tyan based Opterion system (S2882 and S4882) run with out problems
under FreeBSD 5.4 and 6.1.
We can reproduce the problem on two different S2460 based systems, and
have tried 2 seperate ICP GDT8546RZ cards, so we don't believe it is a
hardware problem. (Our success with FreeBSD 4.11 also provides some
evidence that our hardware is OK.)
The problem is that the system seems to stop doing any disk IO through
the ICP card. Processes that don't need to page in work fine. (You can
hit return in a shell, get another login: prompt on other consoles,
and the like.) The system continues to respond to pings, but anything
that attempts to do a disk IO simply stops. Sometimes the kernel emits
messages like this:
swap_pager: indefinite wait buffer: bufobj: 0, blkno: 2, size: 4096
The test we are using to produce this "hang" is a fairly trivial
expansion of a tar ball being fed via nc from another system. We run
on the source system:
tar cf - radar | nc -w 3 10.10.10.229 12345
And on the system being tested we run:
nc -l 12345 | tar xvf -
One iteration of this test is the extraction of a 1.2 GB directory of
2,274 files.
The problem only exists with SMP kernels. While our other tests almost
always failed in the first iteration or two, the longest time to
failure was 5 iterations. With out SMP the test ran with out problems
for 570 iterations over 18 hours.
We've tried a number of different tests. These tests are with a stock
6.1-RC1 kernel from the RC CD's. Unless otherwise specified, all tests
are on a UFS2 filesystem with softupdates enabled and a SMP enabled
GENERIC kernel.
* !SMP: Ran 570 iterations in 18 hours with out a problem, test
terminated by hand.
* Large (190 GB) UFS2 filesystem with soft updates enabled and SMP
kernel: Fails during the first iteration.
* Medium (12 GB) UFS2 filesystem with soft updates enabled and SMP
kernel: Fails during the first iteration.
* !softupdates: fails during first iteration.
* !ACPI: fails during the first iteration.
* UFS1: fails during the first iteration.
* UFS1 + !ADAPTIVE_GIANT: failed during the first iteration.
* !ADAPTIVE_GIANT: failed during the first iteration.
* Cleared motherboard CMOS: failed at the end of the second
iteration.
* FULL_PREEMPTION: failed during the first iteration.
* !PREEMPTION: failed during the first iteration.
* WITNESS + WITNESS_KDB: failed during the second iteration with no
witness related kernel messages and with out entering the kernel
debugger.
* WITNESS + INVARIANTS: failed during the fifth iteration, again w/o
kernel messages.
* Motherboard BIOS "Use PCI Interrupt Entries in MP Table" set to
OFF: failed during first iteration.
* Motherboard BIOS "Multiprocessor Specification" set from 1.4 to
1.1: failed during first iteration.
* MUTEX_WAKE_ALL: failed during first iteration.
I have a serial console and a kernel debugger enabled, so if anybody
has suggestions for probes to do once the system is hung let us know.
Any advice is welcome. Well, except for "dump the Tyan S2460
motherboards" maybe.
Oh, and we're at current BIOS and firmware revs for both the ICP card
and the motherboard.
------------------------------
Message: 10
Date: Fri, 21 Apr 2006 15:26:05 -0700
From: John-Mark Gurney <gurn...@resnet.uoregon.edu>
Subject: Re: iir + Tyan S2460 + SMP problems
To: "Douglas K. Rand" <ra...@meridian-enviro.com>
Cc: freebsd...@freebsd.org
Message-ID: <20060421222...@funkthat.com>
Content-Type: text/plain; charset=us-ascii
Douglas K. Rand wrote this message on Fri, Apr 21, 2006 at 16:59 -0500:
> We're having problems with FreeBSD 5.4, 6.0, and 6.1 and an ICP Vortex
> GDT8546RZ 4 port SATA RAID card in a Tyan S2460 system with dual AMD
> Athlon MP 1600+ CPUs. We do not have any problems with this
> configuration under FreeBSD 4.11, and we have the same ICP cards in
> Tyan based Opterion system (S2882 and S4882) run with out problems
> under FreeBSD 5.4 and 6.1.
>
> We can reproduce the problem on two different S2460 based systems, and
> have tried 2 seperate ICP GDT8546RZ cards, so we don't believe it is a
> hardware problem. (Our success with FreeBSD 4.11 also provides some
> evidence that our hardware is OK.)
[...]
We've had very similar experiences on 4.7-R. The box would hang on
one partition waiting for IO to come back, but direct access to the
disk, or accessing other partitions would pass IO fine. This is with
Intel SRCU31A and SRCU42L cards. With older GDT cards, it would hang
the entire system, since older firmware would completely stop processing
commands...
> Any advice is welcome. Well, except for "dump the Tyan S2460
> motherboards" maybe.
How about drop iir? We had serious issues w/ iir on 4.7-R where the
system would just hang, and Intel/Adaptect/ICP-Vortex has done zero
to help us. Scott Long has done more on his own to help us than the
company that produces the card... Make sure that you are running
rev 1.13.2.1 of src/sys/dev/iir/iir.c which includes some of scottl's
changes to restrict the card to hopefully not hang...
btw, Adaptect/ICP-Vortex the latest version of FreeBSD that they support
their cards on is 5.2... Any releases beyond that are unsupported, so
good luck trying to get them to help you.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
------------------------------
Message: 11
Date: Fri, 21 Apr 2006 17:31:12 -0500
From: "Douglas K. Rand" <ra...@meridian-enviro.com>
Subject: Re: iir + Tyan S2460 + SMP problems
To: "Douglas K. Rand" <ra...@meridian-enviro.com>,
freebsd...@freebsd.org
Message-ID: <873bg6pnm7.wl%ra...@meridian-enviro.com>
Content-Type: text/plain; charset=US-ASCII
Doug> We're having problems with FreeBSD 5.4, 6.0, and 6.1 and an ICP
Doug> Vortex GDT8546RZ 4 port SATA RAID
John-Mark> We've had very similar experiences on 4.7-R. The box would
John-Mark> hang on one partition waiting for IO to come back, but
John-Mark> direct access to the disk, or accessing other partitions
John-Mark> would pass IO fine.
Interesting, the opposite of our problems. It works perfectly for us
on 4.x systems, but not in 5.4 and 6.x.
Doug> Any advice is welcome. Well, except for "dump the Tyan S2460
Doug> motherboards" maybe.
John-Mark> How about drop iir?
While not as expensive as switching motherboards, still a pain. We've
been very happy with our ICP cards. But your suggestion does have
merit, especially as recent PCI-X and PCI-E ICP cards have no FreeBSD
driver in sight.
------------------------------
Message: 12
Date: Fri, 21 Apr 2006 15:38:45 -0700
From: John-Mark Gurney <gurn...@resnet.uoregon.edu>
Subject: Re: iir + Tyan S2460 + SMP problems
To: "Douglas K. Rand" <ra...@meridian-enviro.com>
Cc: freebsd...@freebsd.org
Message-ID: <20060421223...@funkthat.com>
Content-Type: text/plain; charset=us-ascii
Douglas K. Rand wrote this message on Fri, Apr 21, 2006 at 17:31 -0500:
> Doug> We're having problems with FreeBSD 5.4, 6.0, and 6.1 and an ICP
> Doug> Vortex GDT8546RZ 4 port SATA RAID
>
> John-Mark> We've had very similar experiences on 4.7-R. The box would
> John-Mark> hang on one partition waiting for IO to come back, but
> John-Mark> direct access to the disk, or accessing other partitions
> John-Mark> would pass IO fine.
>
> Interesting, the opposite of our problems. It works perfectly for us
> on 4.x systems, but not in 5.4 and 6.x.
So far we haven't hand any issues w/ 6.0 w/ the iir drivers from 6.1
yet.. but we also haven't deployed our product into production... On
5.4-R we got a few months in before we had the hangs and had to ditch
5.4-R...
> Doug> Any advice is welcome. Well, except for "dump the Tyan S2460
> Doug> motherboards" maybe.
>
> John-Mark> How about drop iir?
>
> While not as expensive as switching motherboards, still a pain. We've
> been very happy with our ICP cards. But your suggestion does have
> merit, especially as recent PCI-X and PCI-E ICP cards have no FreeBSD
> driver in sight.
I wouldn't be surprised if the other motherboard could exhibit the
hang too.. since I believe it's a firmware race condition, and the
other motherboard may have different timing characteristics that makes
the hang less likely...
/me has zero trust in iir cards until Adaptec/ICP-Vortex admits there
is a problem and fixes it.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
------------------------------
Message: 13
Date: Sat, 22 Apr 2006 04:20:32 +0200
From: "Adriaan Stable" <fbsd.a...@gmail.com>
Subject: Re: FreeBSD 6.1-PRERELEASE (April 5, 2006) randomly rebooting
on Dell Poweredge 650
To: freebsd...@freebsd.org
Message-ID:
<74c3ddc40604211920ka8...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 4/18/06, Matt Watson <mwa...@becon.org> wrote:
>
> Hello All,
>
> I'm not sure if this is the right place to be sending this or not but I
> figured I'd give it a shot.
>
> The subject line pretty much says it all, I have a Dell Poweredge 650 box
> running 6.1-PRERELEASE which was cvsup'd on April 5, 2006. The box has
> now twice rebooted on its own for no aparant reason. Its a fresh install
> as well, and appears to have been doing this ever since it was installled.
> The first time the box was only up for approximently 2 days and rebooted,
> the 2nd time it was up for approximently 10 days. I have all.log setup to
> log all syslog messages however when the reboot occured there is no
> information in the log which indicates anything going wrong... Here is a
> small cut from the log at the time of the reboot. As can be seen, one
> minute there is an imapd process, the next entry is the system restarting.
>
>
> Apr 16 20:55:34 clearwater imapd: LOGOUT, user=XXXXXX,
> ip=[::ffff:WWW.XXX.YYY.ZZZ], headers=0, body=0, time=0
> Apr 16 20:59:36 clearwater syslogd: restart
> Apr 16 20:59:36 clearwater syslogd: kernel boot file is
> /boot/kernel/kernel
> Apr 16 20:59:36 clearwater kernel: Copyright (c) 1992-2006 The FreeBSD
> Project.
> Apr 16 20:59:36 clearwater kernel: Copyright (c) 1979, 1980, 1983, 1986,
> 1988, 1989, 1991, 1992, 1993, 1994
> Apr 16 20:59:36 clearwater kernel: The Regents of the University of
> California. All rights reserved.
> Apr 16 20:59:36 clearwater kernel: FreeBSD 6.1-PRERELEASE #0: Wed Apr 5
> 20:46:37 EDT 2006
>
> This machine previously had Linux installed on the box and did not display
> the same problems, so I'm going on the assumption that its not a hardware
> failure.
>
> Aside from the reboots the box has been preforming extermely well.
>
> If anybody can provide some insights or suggestions I'd greatly appreciate
> it.
>
> [snip]
>
I experienced similar reboots of 6.1RC on a older Pentium III box. After
disabling ACPI the reboots stopped and the box is very stable
==Adriaan==
------------------------------
Message: 14
Date: Fri, 21 Apr 2006 19:49:11 -0700
From: Darren Pilgrim <darren....@bitfreak.org>
Subject: Re: FreeBSD 6.1-PRERELEASE (April 5, 2006) randomly rebooting
on Dell Poweredge 650
To: Matt Watson <mwa...@becon.org>
Cc: freebsd...@freebsd.org
Message-ID: <444999A7...@bitfreak.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Matt Watson wrote:
> The subject line pretty much says it all, I have a Dell Poweredge 650
> box running 6.1-PRERELEASE which was cvsup'd on April 5, 2006. The box
> has now twice rebooted on its own for no aparant reason.
<...>
[Log indicates no errors, spontaneous reboot.]
<...>
>
> This machine previously had Linux installed on the box and did not
> display the same problems, so I'm going on the assumption that its not a
> hardware failure.
>
> Aside from the reboots the box has been preforming extermely well.
>
> If anybody can provide some insights or suggestions I'd greatly
> appreciate it.
Check your BIOS settings for a hardware watchdog timer. I had this problem
on some brand-new servers (same class of hardware as yours) and disabling
the timer stopped the reboots.
Intel 6300ESB, if anyone's interested.
------------------------------
Message: 15
Date: Fri, 21 Apr 2006 23:20:05 -0600
From: Scott Long <sco...@samsco.org>
Subject: Re: iir + Tyan S2460 + SMP problems
To: "Douglas K. Rand" <ra...@meridian-enviro.com>
Cc: freebsd...@freebsd.org
Message-ID: <4449BD05...@samsco.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Douglas K. Rand wrote:
> Doug> We're having problems with FreeBSD 5.4, 6.0, and 6.1 and an ICP
> Doug> Vortex GDT8546RZ 4 port SATA RAID
>
> John-Mark> We've had very similar experiences on 4.7-R. The box would
> John-Mark> hang on one partition waiting for IO to come back, but
> John-Mark> direct access to the disk, or accessing other partitions
> John-Mark> would pass IO fine.
>
> Interesting, the opposite of our problems. It works perfectly for us
> on 4.x systems, but not in 5.4 and 6.x.
>
> Doug> Any advice is welcome. Well, except for "dump the Tyan S2460
> Doug> motherboards" maybe.
>
> John-Mark> How about drop iir?
>
> While not as expensive as switching motherboards, still a pain. We've
> been very happy with our ICP cards. But your suggestion does have
> merit, especially as recent PCI-X and PCI-E ICP cards have no FreeBSD
> driver in sight.
>
My understanding is that the ICP division is switching over to the
architcture supported by the 'aac' driver. Adaptec provided updates
to this driver last year that include a number of ICP id numbers. If
you have access to one of these cards that you mention, would you mind
trying the aac driver and reported on whether or not it worked?
Scott
------------------------------
Message: 16
Date: Sat, 22 Apr 2006 08:25:54 +0200
From: Zoran Kolic <kol...@EUnet.yu>
Subject: irq question
To: freebsd...@freebsd.org
Message-ID: <2006042206...@faust.net>
Content-Type: text/plain; charset=us-ascii
Dear all!
I've sent this on stable and
amd64; sorry for those who read
it twice.
For next week or two, I'll get
cable net; for nforce3 mobo I
put "rl" card into the last
pci slot. At least I am aware
of some possible irq mess with
that.
Here is information from dmesg:
ehci0 irq 10 at device 2.2 on pci0
atapci1 irq 10 at device 10.0 on pci0
rl0 irq 10 at device 10.0 on pci2
Does it mean that I should wait and
see? Or change the place in advance?
Motherboard has 5 pci slots (asus
k8n).
Amd64 6.0.
I would like to not be told by
service folks to install win to
have the system work properly.
Best regards
Zoran
------------------------------
Message: 17
Date: Fri, 21 Apr 2006 22:05:26 +0100
From: Mark Cullen <mark.r...@gmail.com>
Subject: 4-STABLE panic, samba related maybe?
To: freebsd...@freebsd.org
Message-ID: <44494916...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I know 4.x is outdated and all that, and soon to be unsupported
(probably very much unsupported already) but I thought I'd post anyway.
I'm not ready to move to 5 / 6.
I just got this panic while copying an old website to a new folder via
samba, deleting it again (didn't quite work as expected you see), and
then trying to use 'vi' over ssh to edit apache config file. It seemed
to panic as soon as I hit enter for the vi command.
----
(root@bone)/usr/home/crash# uname -a
FreeBSD bone.bone.servebeer.com 4.11-STABLE FreeBSD 4.11-STABLE #0: Thu
Mar 16 08:35:46 GMT 2006
mr...@bone.bone.servebeer.com:/usr/obj/usr/src/sys/BONE i386
(root@bone)/usr/home/crash# gdb -k /kernel.debug vmcore.3
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read
called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c
line 2627 in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c
line 933 in fill_symbuf
IdlePTD at physical address 0x003df000
initial pcb at physical address 0x00330860
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02a933a
stack pointer = 0x10:0xca51dd34
frame pointer = 0x10:0xca51dd64
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 89353 (sshd)
interrupt mask = tty
trap number = 12
panic: page fault
syncing disks... 50 1
done
Uptime: 35d16h43m46s
dumping to dev #ad/0x20001, offset 725120
dump ata0: resetting devices .. done
157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140
139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122
121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104
103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81
80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57
56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8
7 6 5 4 3 2 1 0
\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^
@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^
@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^
@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^
@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^
@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^
@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@\^@
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc017f008 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
#2 0xc017f43c in poweroff_wait (junk=0xc02f9eac, howto=-1070622289)
at /usr/src/sys/kern/kern_shutdown.c:595
#3 0xc02aab03 in trap_fatal (frame=0xca51dcf4, eva=20)
at /usr/src/sys/i386/i386/trap.c:974
#4 0xc02aa7c5 in trap_pfault (frame=0xca51dcf4, usermode=0, eva=20)
at /usr/src/sys/i386/i386/trap.c:867
#5 0xc02aa37b in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = -1058013168,
tf_edi = -900604532, tf_esi = 20, tf_ebp = -900604572,
tf_isp = -900604640, tf_ebx = 92, tf_edx = 128, tf_ecx = 23,
tf_eax = -900604552, tf_trapno = 12, tf_err = 0, tf_eip =
-1070951622,
tf_cs = 8, tf_eflags = 66070, tf_esp = 0, tf_ss = -1059805096})
at /usr/src/sys/i386/i386/trap.c:466
#6 0xc02a933a in generic_bcopy ()
#7 0xc019966b in ptcread (dev=0xc032f114, uio=0xca51ded4, flag=8323088)
at /usr/src/sys/kern/tty_pty.c:457
#8 0xc01b9bb6 in spec_read (ap=0xca51de68)
at /usr/src/sys/miscfs/specfs/spec_vnops.c:253
#9 0xc0259cb8 in ufsspec_read (ap=0xca51de68)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:1798
#10 0xc025a359 in ufs_vnoperatespec (ap=0xca51de68)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2394
#11 0xc01b5c98 in vn_read (fp=0xc14ca680, uio=0xca51ded4, cred=0xc10d1b80,
flags=0, p=0xca46b3c0) at vnode_if.h:334
#12 0xc018e63b in dofileread (p=0xca46b3c0, fp=0xc14ca680, fd=9,
buf=0xbfbfb3b0, nbyte=16384, offset=-1, flags=0)
at /usr/src/sys/sys/file.h:147
#13 0xc018e4ff in read (p=0xca46b3c0, uap=0xca51df80)
at /usr/src/sys/kern/sys_generic.c:117
#14 0xc02aadbd in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134839056, tf_esi = 134840832, tf_ebp = -1077939280,
tf_isp = -900603948, tf_ebx = 9, tf_edx = 134839056, tf_ecx = 9,
tf_eax = 3, tf_trapno = 7, tf_err = 2, tf_eip = 673732972, tf_cs
= 31,
tf_eflags = 659, tf_esp = -1077955708, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1175
#15 0xc029c0f5 in Xint0x80_syscall ()
#16 0x8069a43 in ?? ()
#17 0x8069e39 in ?? ()
#18 0x8069f2f in ?? ()
#19 0x8053c9b in ?? ()
#20 0x805a386 in ?? ()
#21 0x8056c6b in ?? ()
#22 0x804f13c in ?? ()
#23 0x804c56e in ?? ()
(kgdb) l *0xc02a933a
No source file for address 0xc02a933a.
(kgdb) l *0xc019966b
0xc019966b is in ptcread (/usr/src/sys/kern/tty_pty.c:458).
453 }
454 if (pti->pt_flags & (PF_PKT|PF_UCNTL))
455 error = ureadc(0, uio);
456 while (uio->uio_resid > 0 && error == 0) {
457 cc = q_to_b(&tp->t_outq, buf,
min(uio->uio_resid, BUFSIZ));
458 if (cc <= 0)
459 break;
460 error = uiomove(buf, cc, uio);
461 }
462 ttwwakeup(tp);
(kgdb) l *0xc01b9bb6
0xc01b9bb6 is in spec_read (/usr/src/sys/miscfs/specfs/spec_vnops.c:253).
248
249 if (uio->uio_resid == 0)
250 return (0);
251
252 VOP_UNLOCK(vp, 0, p);
253 error = (*devsw(dev)->d_read) (dev, uio, ap->a_ioflag);
254 vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p);
255 return (error);
256 }
257
(kgdb) l *0xc0259cb8
0xc0259cb8 is in ufsspec_read (/usr/src/sys/ufs/ufs/ufs_vnops.c:1798).
1793 struct inode *ip;
1794 struct uio *uio;
1795
1796 uio = ap->a_uio;
1797 resid = uio->uio_resid;
1798 error = VOCALL(spec_vnodeop_p, VOFFSET(vop_read), ap);
1799 /*
1800 * The inode may have been revoked during the call, so
it must not
1801 * be accessed blindly here or in the other wrapper
functions.
1802 */
(kgdb) l *0xc025a359
0xc025a359 is in ufs_vnoperatespec (/usr/src/sys/ufs/ufs/ufs_vnops.c:2394).
2389 ufs_vnoperatespec(ap)
2390 struct vop_generic_args /* {
2391 struct vnodeop_desc *a_desc;
2392 } */ *ap;
2393 {
2394 return (VOCALL(ufs_specop_p, ap->a_desc->vdesc_offset, ap));
2395 }
(kgdb) l *0xc01b5c98
0xc01b5c98 is in vn_read (vnode_if.h:334).
329 a.a_desc = VDESC(vop_read);
330 a.a_vp = vp;
331 a.a_uio = uio;
332 a.a_ioflag = ioflag;
333 a.a_cred = cred;
334 rc = VCALL(vp, VOFFSET(vop_read), &a);
335 return (rc);
336 }
337 struct vop_write_args {
338 struct vnodeop_desc *a_desc;
(kgdb) l *0xc018e63b
0xc018e63b is in dofileread (/usr/src/sys/sys/file.h:147).
142 int flags;
143 {
144 int error;
145
146 fhold(fp);
147 error = (*fp->f_ops->fo_read)(fp, uio, cred, flags, p);
148 fdrop(fp, p);
149 return (error);
150 }
151
(kgdb) l *0xc018e4ff
0xc018e4ff is in read (/usr/src/sys/kern/sys_generic.c:117).
112 register struct file *fp;
113 int error;
114
115 if ((fp = holdfp(p->p_fd, uap->fd, FREAD)) == NULL)
116 return (EBADF);
117 error = dofileread(p, fp, uap->fd, uap->buf, uap->nbyte,
(off_t)-1, 0);
118 fdrop(fp, p);
119 return(error);
120 }
121
(kgdb) l *0xc02aadbd
0xc02aadbd is in syscall2 (/usr/src/sys/i386/i386/trap.c:1175).
1170 p->p_retval[0] = 0;
1171 p->p_retval[1] = frame.tf_edx;
1172
1173 STOPEVENT(p, S_SCE, narg); /* MP aware */
1174
1175 error = (*callp->sy_call)(p, args);
1176
1177 /*
1178 * MP SAFE (we may or may not have the MP lock at this
point)
1179 */
(kgdb)
---
Is anyone able to help me out?
Also, I have no idea what those \^@ characters are after the dump. I
have had random garbage printed out after dumping on the last two panics
( seems you can't use softupdates on a vinum volume )
[...core #2 garbage example...]
dumping to dev #ad/0x20001, offset 725120
dump ata0: resetting devices .. done
157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140
139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122
121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104
103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81
80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57
56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8
7 6 5 4 3 2 1 0 ions not recoverable if the session fails\^[[m \^[[H
WARNING: R/W mount of /usr denied. Filesystem is not clean - run fsck
WARNING: /usr was not properly dismounted
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb)
Thanks in advance for any assitance. Not well seasoned in the art of
kernel debugging so if you need output of any commands from the
debugging kernel do let me know!
------------------------------
End of freebsd-stable Digest, Vol 154, Issue 7
**********************************************