https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367
Eugene Grosbein changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367
Rene Ladan changed:
What|Removed |Added
CC||r...@freebsd.org
--- Comment #21 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367
Rene Ladan changed:
What|Removed |Added
Assignee|r...@freebsd.org |b...@freebsd.org
--
You are receivi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367
Eugene Grosbein changed:
What|Removed |Added
CC||eu...@freebsd.org
St
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367
Eitan Adler changed:
What|Removed |Added
Status|In Progress |Open
--- Comment #19 from Eitan Adle
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193367
--- Comment #18 from commit-h...@freebsd.org ---
A commit references this bug:
Author: dumbbell
Date: Tue Apr 28 12:37:10 UTC 2015
New revision: 282141
URL: https://svnweb.freebsd.org/changeset/base/282141
Log:
DRM2: fix off-by-one overf
On Mar 21, 2013, at 9:39 PM, Konstantin Belousov wrote:
>
> You should use the r248567 + r248581.
OK thanks. I've upgraded to 9-STABLE and applied your patches.
Will let you know if I experience further crashes.
thanks,
/mich
___
freebsd-stable
On Thu, Mar 21, 2013 at 07:59:25PM +0100, Michael Landin Hostbaek wrote:
>
> On Mar 21, 2013, at 8:58 AM, Konstantin Belousov wrote:
>
> > On Wed, Mar 20, 2013 at 09:14:37PM -0400, Rick Macklem wrote:
> >> Well, read/write sharing of files over NFS is pretty rare, so I suspect
> >> a truncation
On Mar 21, 2013, at 8:58 AM, Konstantin Belousov wrote:
> On Wed, Mar 20, 2013 at 09:14:37PM -0400, Rick Macklem wrote:
>> Well, read/write sharing of files over NFS is pretty rare, so I suspect
>> a truncation of a file by another client (or locally in the NFS server)
>> is a rare event. As suc
On Wed, Mar 20, 2013 at 09:14:37PM -0400, Rick Macklem wrote:
> Well, read/write sharing of files over NFS is pretty rare, so I suspect
> a truncation of a file by another client (or locally in the NFS server)
> is a rare event. As such, not invalidating the buffers here doesn't seem
> like a big i
Konstantin Belousov wrote:
> On Wed, Mar 20, 2013 at 11:37:56AM -0400, Rick Macklem wrote:
> > Konstantin Belousov wrote:
> > > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek
> > > wrote:
> > > >
> > > > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov
> > > > wrote:
> > > > >
Konstantin Belousov wrote:
> On Wed, Mar 20, 2013 at 11:37:56AM -0400, Rick Macklem wrote:
> > Konstantin Belousov wrote:
> > > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek
> > > wrote:
> > > >
> > > > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov
> > > > wrote:
> > > > >
On Wed, Mar 20, 2013 at 08:58:08PM +0200, Konstantin Belousov wrote:
> On Wed, Mar 20, 2013 at 09:43:20AM -0400, John Baldwin wrote:
> > On Wednesday, March 20, 2013 9:22:22 am Konstantin Belousov wrote:
> > > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek wrote:
> > > >
> > > >
On Wed, Mar 20, 2013 at 09:43:20AM -0400, John Baldwin wrote:
> On Wednesday, March 20, 2013 9:22:22 am Konstantin Belousov wrote:
> > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek wrote:
> > >
> > > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov
> wrote:
> > > >
> > > >
On Wednesday, March 20, 2013 9:22:22 am Konstantin Belousov wrote:
> On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek wrote:
> >
> > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov
wrote:
> > >
> > > I do not like it. As I said in the previous response to Andrey,
> > > I thin
On Wed, Mar 20, 2013 at 11:37:56AM -0400, Rick Macklem wrote:
> Konstantin Belousov wrote:
> > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek
> > wrote:
> > >
> > > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov
> > > wrote:
> > > >
> > > > I do not like it. As I said in the
Konstantin Belousov wrote:
> On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek
> wrote:
> >
> > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov
> > wrote:
> > >
> > > I do not like it. As I said in the previous response to Andrey,
> > > I think that moving the vnode_pager_setsize
On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek wrote:
>
> On Mar 20, 2013, at 10:49 AM, Konstantin Belousov wrote:
> >
> > I do not like it. As I said in the previous response to Andrey,
> > I think that moving the vnode_pager_setsize() after the unlock is
> > better, since it
Comments in line .
---
On Mar 19, 2013, at 1:45 PM, Michael Landin Hostbaek wrote:
>
> On Mar 19, 2013, at 6:35 PM, Jeremy Chadwick wrote:
>
>> On Tue, Mar 19, 2013 at 06:18:06PM +0100, Michael Landin Hostbaek wrote:
>> The kernel panic is happening in NFS-related code. Rick Macklem (and/o
On Mar 20, 2013, at 10:49 AM, Konstantin Belousov wrote:
>
> I do not like it. As I said in the previous response to Andrey,
> I think that moving the vnode_pager_setsize() after the unlock is
> better, since it reduces races with other thread seeing half-done
> attribute update or making attrib
#6 0x80818d37 at nfs_getattr+0x287
> > >> #7 0x8098f1c0 at vn_stat+0xb0
> > >> #8 0x809869d9 at kern_statat_vnhook+0xf9
> > >> #9 0x80986b55 at kern_statat+0x15
> > >> #10 0x80986c1a at sys_lstat+0x2a
> > &
On Mar 20, 2013, at 12:37 AM, Rick Macklem wrote:
>>
> Yep, I'd agree to that. The same bug is in the old NFS client and
> the new NFS client cribbed the code from there.
>
> I have attached a simple patch that unlocks the mutex for the
> vnode_pager_setsize() call. Maybe you could test it?
>
kern_statat_vnhook+0xf9
> >> #9 0x80986b55 at kern_statat+0x15
> >> #10 0xffff80986c1a at sys_lstat+0x2a
> >> #11 0x80bd7ae6 at amd64_syscall+0x546
> >> #12 0x80bc3447 at Xfast_syscall+0xf7
> >> panic: sleeping thread
> >> cp
0x809869d9 at kern_statat_vnhook+0xf9
> >> #9 0x80986b55 at kern_statat+0x15
> >> #10 0xffff80986c1a at sys_lstat+0x2a
> >> #11 0x80bd7ae6 at amd64_syscall+0x546
> >> #12 0x80bc3447 at Xfast_syscall+0xf7
> >>
stat+0x2a
>> #11 0xffffffff80bd7ae6 at amd64_syscall+0x546
>> #12 0x80bc3447 at Xfast_syscall+0xf7
>> panic: sleeping thread
>> cpuid = 0
>> KDB: stack backtrace:
>> #0 0x809208a6 at kdb_backtrace+0x66
>> #1 0x808ea8be at panic+0x1ce
On Mar 19, 2013, at 6:35 PM, Jeremy Chadwick wrote:
> On Tue, Mar 19, 2013 at 06:18:06PM +0100, Michael Landin Hostbaek wrote:
> The kernel panic is happening in NFS-related code. Rick Macklem (and/or
> John Baldwin) should be able to help with this; I've CC'd both here.
OK, thanks.
>
> Yo
t; #7 0x8098f1c0 at vn_stat+0xb0
> #8 0x809869d9 at kern_statat_vnhook+0xf9
> #9 0x80986b55 at kern_statat+0x15
> #10 0x80986c1a at sys_lstat+0x2a
> #11 0xffff80bd7ae6 at amd64_syscall+0x546
> #12 0x80bc3447 at Xfast_syscall+0xf7
> panic: sleepin
scall+0x546
#12 0x80bc3447 at Xfast_syscall+0xf7
panic: sleeping thread
cpuid = 0
KDB: stack backtrace:
#0 0x809208a6 at kdb_backtrace+0x66
#1 0x808ea8be at panic+0x1ce
#2 0x8092ed22 at propagate_priority+0x1d2
#3 0x8092fa4e at turnstile_wait+0x1be
#4 0x
On 10/05/2012 05:40 AM, Konstantin Belousov wrote:
> This is the whole difference between stable and HEAD nullfs.
> Retest the HEAD then.
Can't reproduce it with HEAD (FreeBSD freebsd-tower.goebo.site
10.0-CURRENT FreeBSD 10.0-CURRENT #0 r241218: Fri Oct 5 08:26:17 CEST
2012
l...@freebsd-tower.go
On Thu, Oct 04, 2012 at 03:29:31PM +0200, Norbert Aschendorff wrote:
> Nop, the patch doesn't seem to work - the machine crashes again. :|
>
This is the whole difference between stable and HEAD nullfs.
Retest the HEAD then.
pgpCMOX0jlgk4.pgp
Description: PGP signature
Nop, the patch doesn't seem to work - the machine crashes again. :|
Norbert
___
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"
On 10/04/2012 01:53 PM, Rick Macklem wrote:
> Looks like you missed the change to fs/nfs/nfs_var.h, which changes
> the prototypes for nfsv4_strtouid() and nfsv4_strtogid().
I see the problem, but I don't really understand why it failed. I
applied the whole patch...
However, 9.1-PRERELEASE is com
Norbert Aschendorff wrote:
> Does not compile: http://nopaste.info/2bc2c189eb.html (I also
> #define-d
> a constant, but that works)
>
Looks like you missed the change to fs/nfs/nfs_var.h, which changes
the prototypes for nfsv4_strtouid() and nfsv4_strtogid().
Btw, the numeric uid/gid patch is no
On 10/04/2012 12:45 PM, Konstantin Belousov wrote:
> But the errors has nothing to do with my nullfs backport.
You're right; they stem from Rick's patch (from line 207 in
numeric-uidgid.patch on):
-nd->nd_repstat = nfsv4_strtogid(cp,j,&gid,p);
+nd->nd_repstat = nfsv4_strtogid(nd, cp, j, &gid,
+
On Thu, Oct 04, 2012 at 12:29:51PM +0200, Norbert Aschendorff wrote:
> Does not compile: http://nopaste.info/2bc2c189eb.html (I also #define-d
> a constant, but that works)
>
You completely strip off the quotes and attributions, as well as your
To: address is bogus, so I do not know whom did you a
On Thu, Oct 04, 2012 at 09:08:08AM +0200, Norbert Aschendorff wrote:
> On 10/04/2012 08:41 AM, Norbert Aschendorff wrote:
> > I just applied the numeric-uidgid patch to CURRENT (worked so far) and
> > compile the kernel with the patch and try it another time, just to
> > eliminate the possibility o
Does not compile: http://nopaste.info/2bc2c189eb.html (I also #define-d
a constant, but that works)
--Norbert
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-s
Hehe, sure, if you assist me :)
I'm not very experienced with SVN, I'm actually a git user and I think
it's also better if I do /not/ express my opinion on SVN here ;)
The only actions I'm currently able to do in SVN are checkout, update,
commit and view log and status -- so any help is appreciated
On Thu, Oct 04, 2012 at 10:22:37AM +0200, Norbert Aschendorff wrote:
> Hehe, sure, if you assist me :)
> I'm not very experienced with SVN, I'm actually a git user and I think
> it's also better if I do /not/ express my opinion on SVN here ;)
> The only actions I'm currently able to do in SVN are c
On 10/04/2012 08:41 AM, Norbert Aschendorff wrote:
> I just applied the numeric-uidgid patch to CURRENT (worked so far) and
> compile the kernel with the patch and try it another time, just to
> eliminate the possibility of a bug in this patch (the machine never
> crashed before using this patch, b
I exported the NFSv4 shares via nullfs, booted the 10.0-CURRENT kernel
and the machine does not crash. Running 9.1-PRERELEASE, it still crashes
(as it should ;).
I just applied the numeric-uidgid patch to CURRENT (worked so far) and
compile the kernel with the patch and try it another time, just t
On 10/03/2012 07:39 PM, Konstantin Belousov wrote:
> Can you try HEAD kernel ?
Theoretically, yes. But it's a network machine, so... if something goes
wrong, it'd be rather bad :| And I'm afraid of HEAD ;)
I'll try it nevertheless... Fortunately, I even have Screen&Keyboard at
the machine (if som
Konstantin Belousov wrote:
> On Wed, Oct 03, 2012 at 07:26:47PM +0200, Norbert Aschendorff wrote:
> > On 10/03/2012 05:54 PM, Konstantin Belousov wrote:
> > > So do you use nullfs exported mounts ? And stable ?
> > > Can you try to remove nullfs from the set up ?
> >
> > Yes, I am using nullfs for
On Wed, Oct 03, 2012 at 07:26:47PM +0200, Norbert Aschendorff wrote:
> On 10/03/2012 05:54 PM, Konstantin Belousov wrote:
> > So do you use nullfs exported mounts ? And stable ?
> > Can you try to remove nullfs from the set up ?
>
> Yes, I am using nullfs for the exports (mounting the exported
> d
On 10/03/2012 05:54 PM, Konstantin Belousov wrote:
> So do you use nullfs exported mounts ? And stable ?
> Can you try to remove nullfs from the set up ?
Yes, I am using nullfs for the exports (mounting the exported
directories to subdirectories of /srv). In the FreeBSD man pages and the
documenta
On Wed, Oct 03, 2012 at 09:24:11AM -0400, Rick Macklem wrote:
> Norbert Aschendorff wrote:
> > Another logs - even with a /var/crash crash report :)
> >
> > Please note: The /var/crash files stem from another crash than the big
> > syslog does!
> >
> > The syslog file inside the tarball is about
Norbert Aschendorff wrote:
> Another logs - even with a /var/crash crash report :)
>
> Please note: The /var/crash files stem from another crash than the big
> syslog does!
>
> The syslog file inside the tarball is about 4.7 MB; it contains
> everything since the start of the crash.
>
> New /var
Another logs - even with a /var/crash crash report :)
Please note: The /var/crash files stem from another crash than the big
syslog does!
The syslog file inside the tarball is about 4.7 MB; it contains
everything since the start of the crash.
New /var/crash files:
http://lbo.spheniscida.de/Files
On 10/03/2012 09:21 AM, Norbert Aschendorff wrote:
> So I just have to compile a kernel including "option WITNESS_WARN" and
Well, obviously doesn't work, so only WITNESS_SKIPSPIN...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mai
On 10/02/2012 11:15 PM, John Baldwin wrote:
> You could try adding a different WITNESS check (using WITNESS_WARN) to see
> which NFS proc returns with a lock held so you can catch this when it first
> occurs rather than much later after the fact. Do you have the start of the
> log messages?
Yep
John Baldwin wrote:
> On Tuesday, October 02, 2012 2:19:35 pm Norbert Aschendorff wrote:
> > Well...
> >
> > Here the results for a kernel without WITNESS_SKIPSPIN (I'll compile
> > one
> > including that tomorrow, but until then...)
> >
> > Good news is: The kernel crashed with activated WITNESS.
On Tuesday, October 02, 2012 2:19:35 pm Norbert Aschendorff wrote:
> Well...
>
> Here the results for a kernel without WITNESS_SKIPSPIN (I'll compile one
> including that tomorrow, but until then...)
>
> Good news is: The kernel crashed with activated WITNESS.
> Bad news is: I have to turn power
Well...
Here the results for a kernel without WITNESS_SKIPSPIN (I'll compile one
including that tomorrow, but until then...)
Good news is: The kernel crashed with activated WITNESS.
Bad news is: I have to turn power off after the crash with WITNESS. The
crash dump is _not_ written to disk :(
Goo
On Tuesday, October 02, 2012 11:21:06 am Norbert Aschendorff wrote:
> I'll compile a kernel with
>
> options WITNESS
> options WITNESS_KDB
>
> ok? Or should I include WITNESS_SKIPSPIN too?
Yes, you should include WITNESS_SKIPSPIN. We should probably make that the
default.
--
John Baldwin
___
I'll compile a kernel with
options WITNESS
options WITNESS_KDB
ok? Or should I include WITNESS_SKIPSPIN too?
Regards,
Norbert
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any
John Baldwin wrote:
> On Monday, October 01, 2012 8:07:44 am Rick Macklem wrote:
> > Norbert Aschendorff wrote:
> > > Hi,
> > >
> > > my FreeBSD-9/stable machine (FreeBSD freebsd-tower.goebo.site
> > > 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #2 r241044M: Sat Sep 29
> > > 12:52:01
> > > CEST 2012
> >
On 10/01/2012 02:07 PM, Rick Macklem wrote:
> Is the NFS client using Kerberos or AUTH_SYS for the mount? (And if you
> are using Kerberos, have you tried the rsync with an AUTH_SYS mount?)
No, it's not using Kerberos. Only network-based access control or
however it's called (restricted via client
On Monday, October 01, 2012 8:07:44 am Rick Macklem wrote:
> Norbert Aschendorff wrote:
> > Hi,
> >
> > my FreeBSD-9/stable machine (FreeBSD freebsd-tower.goebo.site
> > 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #2 r241044M: Sat Sep 29 12:52:01
> > CEST 2012 l...@freebsd-tower.goebo.site:/usr/obj/usr/
xc0c87f7e at svc_run_internal+0x7ce
#6 0xc0c87706 at svc_run+0xc6
#7 0xc09f24c4 at nfsrvd_nfsd+0x1d4
#8 0xc0a00ad9 at nfssvc_nfsd+0x109
#9 0xc0c70c58 at sys_nfssvc+0x98
#10 0xc0dfd288 at syscall+0x378
#11 0xc0de64b1 at Xint0x80_syscall+0x21
panic: sleeping thread
cpuid = 0
rick
__
On Sat, 13 Mar 2010 09:47:22 -0800
Jeremy Chadwick wrote:
> How do you tune the thresholds for the temperature or fan? If they're
> DIP switches, then chances are SAF-TE or SES-2 aren't involved and it's
> probably just some cheap/generic logic chip that does the work.
There is a switch for the
On Sat, Mar 13, 2010 at 06:32:59PM +0100, Torfinn Ingolfsen wrote:
> On Sat, 13 Mar 2010 08:38:48 -0800
> Jeremy Chadwick wrote:
>
> > That enclosure also doesn't state if it has a SAF-TE or SES-2 chip on
> > it. It's impossible to tell from the photos since the metallic
> > enclosure cover up t
On Sat, 13 Mar 2010 08:38:48 -0800
Jeremy Chadwick wrote:
> That enclosure also doesn't state if it has a SAF-TE or SES-2 chip on
> it. It's impossible to tell from the photos since the metallic
> enclosure cover up the backplane.
Unfortunately, the "manual" is very brief and lacks such technic
On Sat, Mar 13, 2010 at 02:11:13PM +0100, Torfinn Ingolfsen wrote:
> Update:
> Perhaps the problems I have with this machine[1] are related to the
> MB-455SPF[1] hard drive cage I am using. It has three power connectors,
> which distributes power to all five drives. The documentation doesn't
> say
Update:
Perhaps the problems I have with this machine[1] are related to the
MB-455SPF[1] hard drive cage I am using. It has three power connectors,
which distributes power to all five drives. The documentation doesn't
say more about which ports gives power to which drives, but since it is
always dr
On Sat, 06 Mar 2010 14:19:44 +0100
Torfinn Ingolfsen wrote:
> However, the storage pool is not:
> r...@kg-f2# zpool status storage
> pool: storage
> state: UNAVAIL
> status: One or more devices are faulted in response to IO failures.
> action: Make sure the affected devices are connected, then
Ok, a new development in this story.
Note that as of yet, I haven't change SATA cables or done anything else
with the hardware. However, I did upgrade to latest FreeBSD
8.0-stable / amd64 yesterday.
The machine is still up (it iahsn't crashed yet), and today I found this in
/var/log/messages:
Mar
On Fri, 26 Feb 2010 11:03:37 +0100
Torfinn Ingolfsen wrote:
> I will try that now. It might take five days or more to get an answer.
Or not. Another panic. Output from /var/log/messages:
Feb 26 11:10:33 kg-f2 ntpd[942]: kernel time sync status change 2001
Feb 26 11:44:19 kg-f2 kernel: ata5: port
On Fri, Feb 26, 2010 at 11:03:37AM +0100, Torfinn Ingolfsen wrote:
> > What exact disks (e.g. adX) are attached to ata5 and ata6?
>
> r...@kg-f2# dmesg | grep ata5
> ata5: on atapci0
> ata5: [ITHREAD]
> ad10: 953869MB at ata5-master UDMA100 SATA 3Gb/s
> r...@kg-f2# dmesg | grep ata6
> ata6: on
On Sat, 20 Feb 2010 15:35:46 -0800
Jeremy Chadwick wrote:
After five days - a new crash. From /var/log/messages:
Feb 26 00:57:39 kg-f2 ntpd[55453]: kernel time sync status change 6001
Feb 26 01:39:40 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd =
007f
Feb 26 01:39:40 kg-f2 ker
On Sun, Feb 21, 2010 at 4:12 AM, C. P. Ghost wrote:
> On Sun, Feb 21, 2010 at 12:35 AM, Jeremy Chadwick
> wrote:
>>
>> Some Linux users have reported AHCI-related issues with the SB600
>> southbridge, but the core of the problem turned out to be MSI on certain
>> AMD northbridges (specifically R
On Sun, Feb 21, 2010 at 12:35 AM, Jeremy Chadwick
wrote:
> We can safely rule out the Silicon Image controller (otherwise "ataX"
> wouldn't be involved), which leaves the AMD SB700 SATA controller and
> the AMD SB700 PATA controller.
>
> What exact disks (e.g. adX) are attached to ata5 and ata6?
On Sat, Feb 20, 2010 at 10:49:59PM +0100, Torfinn Ingolfsen wrote:
> On Sat, 20 Feb 2010 11:37:18 -0800
> Jeremy Chadwick wrote:
>
> > Can you re-run smartctl -a instead of -H? Some of the SMART attributes
> > may help determine what's going on, or there may be related errors in
> > the SMART er
On Sat, 20 Feb 2010 11:37:18 -0800
Jeremy Chadwick wrote:
> Can you re-run smartctl -a instead of -H? Some of the SMART attributes
> may help determine what's going on, or there may be related errors in
> the SMART error log.
smartctl -a output attached. Test sequence: ad4 - ad12, ada0.
> Othe
On Sat, Feb 20, 2010 at 08:21:08PM +0100, Torfinn Ingolfsen wrote:
> Another day, another crash.
> >From /var/log/messages:
> Feb 20 08:52:26 kg-f2 ntpd[58609]: time reset +1.169751 s
> Feb 20 08:54:57 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd =
> 007f
> Feb 20 08:54:57 kg-f
Another day, another crash.
>From /var/log/messages:
Feb 20 08:52:26 kg-f2 ntpd[58609]: time reset +1.169751 s
Feb 20 08:54:57 kg-f2 kernel: ata5: port is not ready (timeout 1ms) tfd =
007f
Feb 20 08:54:57 kg-f2 kernel: ata5: hardware reset timeout
Feb 20 19:18:51 kg-f2 syslogd: kernel bo
Another crash last night. In /var/log/messages:
Feb 16 23:13:22 kg-f2 ntpd[2826]: time reset +1.780863 s
Feb 16 23:16:42 kg-f2 kernel: ata6: port is not ready (timeout 1ms) tfd =
007f
Feb 16 23:16:42 kg-f2 kernel: ata6: hardware reset timeout
Feb 16 23:20:39 kg-f2 kernel: ata6: port is no
On Sun, 07 Feb 2010 16:36:31 +0100
Torfinn Ingolfsen wrote:
> Well, it was stable for many days, but today it rebooted on its ownb again.
> After the fact, I see this in /var/log/messages:
> Feb 7 11:50:16 kg-f2 ntpd[906]: time reset +2.376096 s
> Feb 7 12:02:21 kg-f2 kernel: ata6: port is not
On Sun, 31 Jan 2010 17:56:39 +0100
Torfinn Ingolfsen wrote:
> On Sun, 31 Jan 2010 14:42:17 +0100
> Torfinn Ingolfsen wrote:
>
> > Hi,
> >
> > One of my machines had a panic or something.
> > The machine was pingable, but I couldn't ssh into it, and there was no
> > response on the console.
>
On Sun, 31 Jan 2010 14:42:17 +0100
Torfinn Ingolfsen wrote:
> Hi,
>
> One of my machines had a panic or something.
> The machine was pingable, but I couldn't ssh into it, and there was no
> response on the console.
>
And it did it again, only a few hours later. I'll try to update to latest
-
Hi,
One of my machines had a panic or something.
The machine was pingable, but I couldn't ssh into it, and there was no response
on the console.
On the console was these lines:
"Sleeping thread (tid 10014, pid 0) owns a non-sleepable lock"
"panic: sleeping thread"
&quo
>Submitter-Id: current-users
>Originator:Eugene Grosbein
>Organization: Svyaz Service
>Confidential: no
>Synopsis: repeatable 6.4-STABLE kernel panic: sleeping thread
>Severity: critical
>Priority: high
>Category: kern
>Class: sw-bug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Thursday, December 14, 2006 09:00:36 -0600 Eric van Gyzen
<[EMAIL PROTECTED]> wrote:
> I saw a recent thread about a "sleeping thread" panic.
> I submitted kern/102654 for one on 6.1-RELEASE-p1:
>
> http://www.freebsd.org/cgi/query-pr.cg
I saw a recent thread about a "sleeping thread" panic.
I submitted kern/102654 for one on 6.1-RELEASE-p1:
http://www.freebsd.org/cgi/query-pr.cgi?pr=102654
I'll gladly help you debug it.
Eric
___
freebsd-stable@freebsd.org mailing list
http://lists
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, December 13, 2006 08:53:32 +0200 Danny Braniss
<[EMAIL PROTECTED]> wrote:
> have you tried enabling ttyd0 in /etc/ttys?
Although I'm willing to try just about anything, to what effect? I don't have
anything attached to any ser
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> - --On Tuesday, December 12, 2006 20:43:07 -0400 "Marc G. Fournier"
> <[EMAIL PROTECTED]> wrote:
>
> > 'k, I'm updating my kernel/world to todays, removed KDB_UNATTENDED and
> > changed BREAK_TO... to ALT_BREAK_TO... to see if its esca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, December 12, 2006 20:43:07 -0400 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
> 'k, I'm updating my kernel/world to todays, removed KDB_UNATTENDED and
> changed BREAK_TO... to ALT_BREAK_TO... to see if its escape sequence will
> s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, December 12, 2006 17:40:17 -0500 John Baldwin <[EMAIL
PROTECTED]>
wrote:
> KDB_UNATTENDED should make it do a coredump and not bother with dropping into
> ddb when it panics.
'k, I'm updating my kernel/world to todays, removed KDB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, December 12, 2006 17:40:17 -0500 John Baldwin <[EMAIL
PROTECTED]>
wrote:
> KDB_UNATTENDED should make it do a coredump and not bother with dropping into
> ddb when it panics.
Would setting this to 1 help me any:
# sysctl -d debug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, December 12, 2006 17:40:17 -0500 John Baldwin <[EMAIL
PROTECTED]>
wrote:
> KDB_UNATTENDED should make it do a coredump and not bother with dropping into
> ddb when it panics.
Its not ... it just prints everything out and then just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, December 12, 2006 23:40:36 +0100 Max Laier <[EMAIL PROTECTED]>
wrote:
> On Tuesday 12 December 2006 22:59, Marc G. Fournier wrote:
>> --On Tuesday, December 12, 2006 17:49:33 -0400 "Marc G. Fournier"
>>
>> <[EMAIL PROTECTED]> wrote:
On Tuesday 12 December 2006 16:59, Marc G. Fournier wrote:
>
> --On Tuesday, December 12, 2006 17:49:33 -0400 "Marc G. Fournier"
> <[EMAIL PROTECTED]> wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> >
> >
> > - --On Tuesday, December 12, 2006 17:40:48 -0400 "Marc G. Fournier"
On Tuesday 12 December 2006 22:59, Marc G. Fournier wrote:
> --On Tuesday, December 12, 2006 17:49:33 -0400 "Marc G. Fournier"
>
> <[EMAIL PROTECTED]> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> >
> >
> > - --On Tuesday, December 12, 2006 17:40:48 -0400 "Marc G. Fournier"
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, December 12, 2006 17:49:33 -0400 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> - --On Tuesday, December 12, 2006 17:40:48 -0400 "Marc G. Fournier"
> <[EMAIL PROTECTED]> wrote
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, December 12, 2006 17:40:48 -0400 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
> I'll try the -e none the next time it crashes, unless someone else has
> another idea for doing it? Actually, I'll try the -e none after its up
> aga
t; unlock_and_deallocate() at unlock_and_deallocate+0x10e
>> vm_fault() at vm_fault+0x1ca0
>> trap_pfault() at trap_pfault+0x127
>> trap() at trap+0x3e6
>> calltrap() at calltrap+0x5
>> --- trap 0xc, rip = 0x8028d9bf7, rsp = 0x7fffe900, rbp =
> 0x7fffe900
tx_trylock() at _mtx_trylock+0x1
> unlock_and_deallocate() at unlock_and_deallocate+0x10e
> vm_fault() at vm_fault+0x1ca0
> trap_pfault() at trap_pfault+0x127
> trap() at trap+0x3e6
> calltrap() at calltrap+0x5
> --- trap 0xc, rip = 0x8028d9bf7, rsp = 0x7fffe900, rbp =
0x7ff
trap_pfault() at trap_pfault+0x127
trap() at trap+0x3e6
calltrap() at calltrap+0x5
- --- trap 0xc, rip = 0x8028d9bf7, rsp = 0x7fffe900, rbp = 0x7fffe900
---
panic: sleeping thread
cpuid = 1
-
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email .
, Marc G. Fournier wrote:
> > >> Without a core dump, does this mean anything to anyone?
> > >>
> > >> Sleeping thread (tid 101251, pid 38200) owns a non-sleepable lock
> > >> panic: sleeping thread
> > >> cpuid = 1
> > &
re dump, does this mean anything to anyone?
> >>
> >> Sleeping thread (tid 101251, pid 38200) owns a non-sleepable lock
> >> panic: sleeping thread
> >> cpuid = 1
> >>
> >> The kernel was last upgraded:
> >>
> >> FreeBSD 6.2-PRERELEASE
;> Sleeping thread (tid 101251, pid 38200) owns a non-sleepable lock
>> panic: sleeping thread
>> cpuid = 1
>>
>> The kernel was last upgraded:
>>
>> FreeBSD 6.2-PRERELEASE #1: Fri Nov 17 23:31:41 AST 2006
>>
>> I'm going to build in DDB stuff
1 - 100 of 103 matches
Mail list logo
