for the tip!
Seems, this problem (non-working shutdown in EFI environment) is a POLA
violation in 13.0.
A.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "fr
tside of a virtual machine
... one day!
> EFI
> support in VirtualBox is experimental and is available for OSes unable
> to boot without EFI. FreeBSD is perfectly able to boot in virtualbox
> without EFI so no need for it.
>
I am aware.
> > Now on shutdown, "shutdown
away without EFI.
Also can you try installing another FreeBSD VM and verify the problem
happens for that one too? This could help understand if the problem is
with virtualization or specific to the VM.
Now on shutdown, "shutdown -p now" (in single user mode, after manually
unmountin
Hi there,
I had updated FreeBSD, in VirtualBox 5.22 on Windows with EFI, from
12-STABLE
to 13-STABLE; upgraded the ZFS pools & the EFI boot loader. Currently
testing with 13 GENERIC kernel.
Now on shutdown, "shutdown -p now" (in single user mode, after manually
unmounting
ZFS dat
On 12.09.2013 19:21, Florent Peterschmitt wrote:
> Le 12/09/2013 19:19, David Demelier a écrit :
>> Hello folks,
>>
>> I have a panic at shutdown related to FUSE.
>> #16 0x81af623b in fuse_unmount () from /usr/local/modules/fuse.ko
>
> Yes, then, did you r
Hello folks,
I have a panic at shutdown related to FUSE.
#0 doadump (textdump=) at pcpu.h:234
234 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt full
#0 doadump (textdump=) at pcpu.h:234
No locals.
#1 0x8090d9a6 in kern_reboot (howto=260) at
/usr/src/sys/kern
Le 12/09/2013 19:19, David Demelier a écrit :
> Hello folks,
>
> I have a panic at shutdown related to FUSE.
> #16 0x81af623b in fuse_unmount () from /usr/local/modules/fuse.ko
Yes, then, did you rebuilt the kernel module after an upgrade?
--
Florent Peterschmitt
On Thursday, September 12, 2013 1:29:40 am Marko Cupać wrote:
> On Wed, 11 Sep 2013 11:11:24 -0400
> John Baldwin wrote:
>
> > Is this reproducible?
>
> It happened a few times before (maybe 3-4 times this year), but I can't
> reproduce it intentionally.
Hmm, I'm tempted to chalk this up to a h
On Wed, 11 Sep 2013 11:11:24 -0400
John Baldwin wrote:
> Is this reproducible?
It happened a few times before (maybe 3-4 times this year), but I can't
reproduce it intentionally.
--
Marko Cupać
___
freebsd-stable@freebsd.org mailing list
http://lists
On Tuesday, September 10, 2013 10:50:55 am Marko Cupać wrote:
> My 9.2-PRERELEASE #0 r254557 amd64 just dumped core on shutdown. I
> updated src to Last Changed Rev: 255395 two days ago but did not get
> to rebuild world&kernel. Also I did not rebuild any ports since.
> Virtualbox
memory stick as cache device with the command:
# zpool add tank0 cache /dev/da0
But when I shutdown the laptop the process will halt with this
screen
shot:
http://www.dump-it.fr/freebsd-screen-shot/2f9169f18c7c77e52e873580f9c2d4bf.jpg.html
and I need to press the power button for more than
command:
# zpool add tank0 cache /dev/da0
But when I shutdown the laptop the process will halt with this screen
shot:
http://www.dump-it.fr/freebsd-screen-shot/2f9169f18c7c77e52e873580f9c2d4bf.jpg.html
and I need to press the power button for more than 4 seconds to
switch off the laptop.
The
-PRERELEASE FreeBSD 9.2-PRERELEASE #0: Tue Jul 16
16:32:39 CEST 2013 root@presario:/usr/obj/usr/src/sys/GENERIC amd64
For speed up the compilation I have added to the pool, tank0, a
SanDisk memory stick as cache device with the command:
# zpool add tank0 cache /dev/da0
But when I shutdown the
pilation I have added to the pool, tank0, a
> >> SanDisk memory stick as cache device with the command:
> >>
> >>
> >> # zpool add tank0 cache /dev/da0
> >>
> >>
> >> But when I shutdown the laptop the process will halt with this screen
on 17/07/2013 12:50 Ronald Klop said the following:
> Does sysctl hw.usb.no_shutdown_wait=1 help?
I believe that the root cause of the issue is that ZFS does not perform full
clean up on shutdown and thus does not release its devices. But perhaps I am
mistaken.
In any case, I think that do
@presario:/usr/obj/usr/src/sys/GENERIC amd64
For speed up the compilation I have added to the pool, tank0, a
SanDisk memory stick as cache device with the command:
# zpool add tank0 cache /dev/da0
But when I shutdown the laptop the process will halt with this screen
shot:
http://www.dump
- Original Message -
From: "Ronald Klop"
Does sysctl hw.usb.no_shutdown_wait=1 help?
That will just prevent the wait it won't stop the
shutdown from happening.
Regards
Steve
This e.mail is private and confi
amd64
For speed up the compilation I have added to the pool, tank0, a SanDisk
memory stick as cache device with the command:
# zpool add tank0 cache /dev/da0
But when I shutdown the laptop the process will halt with this screen
shot:
http://www.dump-it.fr/freebsd-screen-shot
I think this is expected as your screenshot shows the USB has being
disconnected, so you actually lost the cache device on the shutdown.
Maybe you should implement a shutdown script that removes the USB cache from
the pool before the shutdown command is issued :)
Best regards,
Ivailo Tanusheff
, tank0, a SanDisk
memory stick as cache device with the command:
# zpool add tank0 cache /dev/da0
But when I shutdown the laptop the process will halt with this screen shot:
http://www.dump-it.fr/freebsd-screen-shot/2f9169f18c7c77e52e873580f9c2d4bf.jpg.html
and I need to press the power button
Konstantin Belousov wrote:
> On Mon, Jul 08, 2013 at 12:26:43AM +0200, Andreas Longwitz wrote:
>> The deadlock can be explained now: pid 1 (init) sleeps on "mount drain"
>> because mp->mnt_lockref was 1. This setting was done by pid 18 (gjournal
>> switcher) by calling vfs_busy(). pid 18 now sleeps
On Mon, Jul 08, 2013 at 12:26:43AM +0200, Andreas Longwitz wrote:
> The deadlock can be explained now: pid 1 (init) sleeps on "mount drain"
> because mp->mnt_lockref was 1. This setting was done by pid 18 (gjournal
> switcher) by calling vfs_busy(). pid 18 now sleeps on "suspwt" because
> mp->mnt_w
The problem occurs after an update of 8-stable from r248120 to r252111.
Sometimes shutdown hangs:
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `synce
Op 23 jun. 2013 om 03:15 heeft Jeremy Chadwick het volgende
geschreven:
> On Sun, Jun 23, 2013 at 02:41:27AM +0200, Willem Jan Withagen wrote:
>> On 19-6-2013 17:04, Jeremy Chadwick wrote:
>>> - Adam runs 9.1-RELEASE because of business needs pertaining to
>>> freebsd-update and binary update
ame issue -- it isn't. There are multiple things that
have historically (and/or presently) have caused this issue.
Here's the list I composed only a few days ago, and it is far from
thorough:
http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073863.html
My point is that the "shutd
On 19-6-2013 17:04, Jeremy Chadwick wrote:
- Adam runs 9.1-RELEASE because of business needs pertaining to
freebsd-update and binary updates. (I ask more about this for
benefits of readers below, however -- because this situation comes
up a lot and I want to know what real-world admins
On 19-6-2013 15:41, Steven Hartland wrote:
- Original Message - From: "Ronald Klop"
On Wed, 19 Jun 2013 14:53:19 +0200, Adam Strohl
wrote:
On 6/19/2013 19:21, Jeremy Chadwick wrote:
On Wed, Jun 19, 2013 at 06:35:57PM +0700, Adam Strohl wrote:
Hello -STABLE@,
So I've seen this si
because the
> >> > stock X server
> >> > with Intel driver has some issues that make it unusable for me.
> >> >
> >> > The new X server and Intel driver works extremely well, so kudos
> >> > to whoever made
> >> > this poss
issues that make it unusable for me.
>> >
>> > The new X server and Intel driver works extremely well, so kudos
>> > to whoever made
>> > this possible.
>> >
>> > Unfortunately, I am now experiencing random hangs on shutdown. On
>>
y (ie; not a production/client server).
No matter what I do:
reboot
shutdown -p
shutdown -r
This specific server will stop at "All buffers synced" and not actually
power down or reboot. KB input seems to be ignored. This server is a
ZFS NAS (with GMIRROR for boot blocks) but the other b
system is already in a "shutting down" state where usability
>> and accessibility becomes bare minimal, and you're kind of at your
>> wits end.
>>
>> Booting verbose can help -- there are other messages printed to the VGA
>> (and/or serial) console d
dy in a "shutting down" state where usability
and accessibility becomes bare minimal, and you're kind of at your
wits end.
Booting verbose can help -- there are other messages printed to the VGA
(and/or serial) console during the shutdown phase when verbose.
All you can hope for is
est).
To recap for readers/mailing list:
- Adam seems the same behaviour on systems on bare metal, as well as
FreeBSD guests running under VMware ESXi 5.0 hypervisor. However,
as I stated on the list just yesterday about "lock-ups on shutdown",
every situation may be diff
On Sun, 16 Jun 2013, Ian Lepore wrote:
On Sun, 2013-06-16 at 09:07 -0700, Jeremy Chadwick wrote:
On Sun, Jun 16, 2013 at 06:01:49PM +0200, Michiel Boland wrote:
On 06/16/2013 17:55, Jeremy Chadwick wrote:
[...]
Are you running moused(8)? Actually, I can see quite clearly that you
are in you
On Wed, Jun 19, 2013 at 09:52:00AM -0700 I heard the voice of
Jeremy Chadwick, and lo! it spake thus:
>
> Justified in your environment, but not in mine -- where most of my
> systems (at home) are extremely quiet (1000-1200rpm fans, lots of
> noise dampening material, etc.). A 10C increase *durin
On Wed, Jun 19, 2013 at 11:34:39AM -0500, Matthew D. Fuller wrote:
> On Wed, Jun 19, 2013 at 09:16:35AM -0700 I heard the voice of
> Jeremy Chadwick, and lo! it spake thus:
> >
> > The above CDB + subcommand disables APM entirely. There is a lot
> > more to APM than just parking heads (and in all
On Wed, Jun 19, 2013 at 09:16:35AM -0700 I heard the voice of
Jeremy Chadwick, and lo! it spake thus:
>
> The above CDB + subcommand disables APM entirely. There is a lot
> more to APM than just parking heads (and in all honesty, APM should
> have nothing to do with parking heads). Disabling APM
On Wed, Jun 19, 2013 at 10:53:46AM -0500, Matthew D. Fuller wrote:
> On Wed, Jun 19, 2013 at 08:04:14AM -0700 I heard the voice of
> Jeremy Chadwick, and lo! it spake thus:
> >
> >
> > Readers: if any of you have a ST[123]000DM001 drive running the CC24
> > firmware, and can confirm high head par
On Wed, Jun 19, 2013 at 08:04:14AM -0700 I heard the voice of
Jeremy Chadwick, and lo! it spake thus:
>
>
> Readers: if any of you have a ST[123]000DM001 drive running the CC24
> firmware, and can confirm high head parking counts (SMART attribute
> 193), and are willing to upgrade your drive firm
- Adam seems the same behaviour on systems on bare metal, as well as
FreeBSD guests running under VMware ESXi 5.0 hypervisor. However,
as I stated on the list just yesterday about "lock-ups on shutdown",
every situation may be different and there is a well-established
history of t
- Original Message -
From: "Adam Strohl"
To: "Steven Hartland"
Cc: "Jeremy Chadwick" ;
Sent: Wednesday, June 19, 2013 3:29 PM
Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly
dismount
On 6/19/2013 21:21, Steven Hartlan
On 6/19/2013 21:21, Steven Hartland wrote:
You still need to test if stable/9 fixes your issue though as otherwise
you don't know if the issue your seeing has already been fixed, and if
its the old know ZFS vfs hang on shutdown, it has.
Thanks Steve, understood but probably not going to h
- Original Message -
From: "Adam Strohl"
To: "Jeremy Chadwick"
Cc:
Sent: Wednesday, June 19, 2013 3:15 PM
Subject: Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly
dismount
On 6/19/2013 20:35, Jeremy Chadwick wrote:
Nope, I see
ow many are made here (and
can't buy). Smartd screams about them possibly needing a firmware
update (they don't according to Seagate). Had no issues aside from a
failure a month or so again (it's an HD ... it happens).
AFAIK this isn't one of the
controllers that was know
- Original Message -
From: "Ronald Klop"
On Wed, 19 Jun 2013 14:53:19 +0200, Adam Strohl
wrote:
On 6/19/2013 19:21, Jeremy Chadwick wrote:
On Wed, Jun 19, 2013 at 06:35:57PM +0700, Adam Strohl wrote:
Hello -STABLE@,
So I've seen this situation seemingly randomly on a number of
er of both
> >>physical 9.1 boxes as well as VMs for I would say 6-9 months at
> >>least. I finally have a physical box here that reproduces it
> >>consistently that I can reboot easily (ie; not a production/client
> >>server).
> >>
> >>No matte
follow 9-STABLE and the
problem is gone for a while now.
Ronald.
No matter what I do:
reboot
shutdown -p
shutdown -r
This specific server will stop at "All buffers synced" and not
actually power down or reboot. KB input seems to be ignored. This
server is a ZFS NAS (with GMIRROR
On 6/19/2013 19:53, Adam Strohl wrote:
sync(8) does not do what you think it does. Please read (not skim) this
entire thread starting here:
http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/thread.html#16982
http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/016982.html
Groking
here that reproduces it
consistently that I can reboot easily (ie; not a production/client
server).
No matter what I do:
reboot
shutdown -p
shutdown -r
This specific server will stop at "All buffers synced" and not
actually power down or reboot. KB input seems to be ignored. This
serv
OS version?
- Original Message -
From: "Adam Strohl"
To:
Sent: Wednesday, June 19, 2013 12:35 PM
Subject: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount
Hello -STABLE@,
So I've seen this situation seemingly randomly on a number of both
es it
> consistently that I can reboot easily (ie; not a production/client
> server).
>
> No matter what I do:
>
> reboot
> shutdown -p
> shutdown -r
>
> This specific server will stop at "All buffers synced" and not
> actually power down or reboot.
No matter what I do:
reboot
shutdown -p
shutdown -r
This specific server will stop at "All buffers synced" and not actually
power down or reboot. KB input seems to be ignored. This server is a
ZFS NAS (with GMIRROR for boot blocks) but the other boxes which show
this are using GM
bility
and accessibility becomes bare minimal, and you're kind of at your
wits end.
Booting verbose can help -- there are other messages printed to the VGA
(and/or serial) console during the shutdown phase when verbose.
All you can hope for is that the kernel is still alive and Ctrl-Alt-Esc
t
I've read the posts again. Although the issue looks same as Michiel
Boland (first link) but I'm not sure if the root of the issue is same
as Michiel's too (second link). Anyway, it should be discussed in
another thread as you said.
> Second, the patch is not mine -- it's Konstantin's. I did not w
ct to the issue.
> >
> > --
> > | Jeremy Chadwick j...@koitsu.org |
> > | UNIX Systems Administratorhttp://jdc.koitsu.org/ |
> > | Making life hard for others since 1977. PGP 4BD6C0CB |
> >
>
>
...@koitsu.org |
> | UNIX Systems Administratorhttp://jdc.koitsu.org/ |
> | Making life hard for others since 1977. PGP 4BD6C0CB |
>
Many thanks for the detailed answer. I've applied your patch and then
rebuilt the world and kernel. To be honest, I tried to
ource is)
> patch -p0 < sysmouse_vsync.diff
>
> Assuming use of svn, you can revert this patch by doing:
>
> cd /usr/src (or wherever your source is)
> svn revert sys/dev/drm2/i915/intel_fb.c
> svn revert sys/dev/syscons/scvgarndr.c
> rm sys/dev/drm2/i915/intel_fb
On Tue, Jun 18, 2013 at 07:00:30PM +0430, Javad Kouhi wrote:
> Thanks for the reply, seems that our source trees are not same, I got this:
>
> % patch -p1 < /path/to/patch
> Hmm... Looks like a unified diff to me...
> The text leading up to this was:
> --
> |diff --git a/s
Thanks for the reply, seems that our source trees are not same, I got this:
% patch -p1 < /path/to/patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/sys/dev/drm2/i915/intel_fb.c b/sys/dev/drm2/i915/intel_fb.c
|index 3cb3b78..
On 06/18/2013 13:28, Javad Kouhi wrote:
Hi,
I have exactly the same problem. I've tried to apply the above patch
but it refused. I've checked out the last revision (251934) of
-STABLE branch using Subversion.
% git apply --check patch
error: patch failed: sys/dev/drm2/i915/intel_fb.c:207
error
Hi,
I have exactly the same problem. I've tried to apply the above patch
but it refused. I've checked out the last revision (251934) of
-STABLE branch using Subversion.
% git apply --check patch
error: patch failed: sys/dev/drm2/i915/intel_fb.c:207
error: sys/dev/drm2/i915/intel_fb.c: patch does
t;
> > The new X server and Intel driver works extremely well, so kudos to whoever
> > made
> > this possible.
> >
> > Unfortunately, I am now experiencing random hangs on shutdown. On shutdown
> > the
> > system randomly freezes after
> >
> > [..
.
Unfortunately, I am now experiencing random hangs on shutdown. On shutdown the
system randomly freezes after
[...] syslogd: exiting on signal 15
I would then expect to see 'Waiting (max 60 seconds) for system process 'XXX' to
stop messages, but these never arrive.
So it turns out that ini
So apparently the value of 'rebooting' is 0 at the time of the hang...
db> x rebooting
rebooting: 0
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stab
not see anything related to i915 in the core.txt you provided.
> >>>
> >>> Next time the machine hangs, start with the output of ps command from
> >>> ddb and 'show allpcpu', together with 'alltrace'.
> >>>
> >>
> >&g
On Sun, 2013-06-16 at 09:07 -0700, Jeremy Chadwick wrote:
> On Sun, Jun 16, 2013 at 06:01:49PM +0200, Michiel Boland wrote:
> > On 06/16/2013 17:55, Jeremy Chadwick wrote:
> > [...]
> >
> > >Are you running moused(8)? Actually, I can see quite clearly that you
> > >are in your core.txt:
> > >
> >
On 06/16/2013 20:06, Michiel Boland wrote:
FWIW - the saved core from the ddb-induced panic has
(kgdb) print rebooting
$1 = 1
I realised instantly after I sent my message that this is meaningless - so
please ignore that.
___
freebsd-stable@freebs
command from
ddb and 'show allpcpu', together with 'alltrace'.
Ok, I captured 'ps', 'show allpcpu' and 'alltrace' from a stuck shutdown. I've
appended it to my core.txt. (See previous e-mail.) (Note that the ddb commands
are from a different
gt; > ddb and 'show allpcpu', together with 'alltrace'.
> >
>
> Ok, I captured 'ps', 'show allpcpu' and 'alltrace' from a stuck shutdown.
> I've
> appended it to my core.txt. (See previous e-mail.) (Note that the dd
, 'show allpcpu' and 'alltrace' from a stuck shutdown. I've
appended it to my core.txt. (See previous e-mail.) (Note that the ddb commands
are from a different session - so the ddb output may not match with the kgdb
output.)
_
- Original Message -
From: "Michiel Boland"
To: "FreeBSD Stable"
Sent: Sunday, June 16, 2013 4:11 PM
Subject: system sporadically hangs on shutdown after switching to WITH_NEW_XORG
Hi. Recently I switched to WITH_NEW_XORG, primarily because the stock X server
w
On Sun, Jun 16, 2013 at 06:01:49PM +0200, Michiel Boland wrote:
> On 06/16/2013 17:55, Jeremy Chadwick wrote:
> [...]
>
> >Are you running moused(8)? Actually, I can see quite clearly that you
> >are in your core.txt:
> >
> >Starting ums0 moused.
> >
> >Try turning that off. Don't ask me how, be
On 06/16/2013 17:55, Jeremy Chadwick wrote:
[...]
Are you running moused(8)? Actually, I can see quite clearly that you
are in your core.txt:
Starting ums0 moused.
Try turning that off. Don't ask me how, because devd(8) / devd.conf(5)
might be involved.
The moused is started by devd - I d
r
> >>with Intel driver has some issues that make it unusable for me.
> >>
> >>The new X server and Intel driver works extremely well, so kudos to whoever
> >>made
> >>this possible.
> >>
> >>Unfortunately, I am now exp
extremely well, so kudos to whoever made
this possible.
Unfortunately, I am now experiencing random hangs on shutdown. On shutdown the
system randomly freezes after
[...] syslogd: exiting on signal 15
I would then expect to see 'Waiting (max 60 seconds) for system process 'XXX' t
udos to whoever
> made
> this possible.
>
> Unfortunately, I am now experiencing random hangs on shutdown. On shutdown
> the
> system randomly freezes after
>
> [...] syslogd: exiting on signal 15
>
> I would then expect to see 'Waiting (max 60 seconds) fo
shutdown. On shutdown the
system randomly freezes after
[...] syslogd: exiting on signal 15
I would then expect to see 'Waiting (max 60 seconds) for system process 'XXX' to
stop messages, but these never arrive.
I paniced the machine in ddb, so I have a crash dump if someone
On Sun, 24 Feb 2013 13:04:52 +0100, David Demelier
wrote:
Le mardi 12 février 2013 21:42:01 Ronald Klop a écrit :
On Tue, 12 Feb 2013 19:44:49 +0100, David Demelier
wrote:
> Le mardi 12 février 2013 10:01:10 Andriy Gapon a écrit :
>> on 12/02/2013 09:57 David Demelier said the following:
>
Le mardi 12 février 2013 21:42:01 Ronald Klop a écrit :
> On Tue, 12 Feb 2013 19:44:49 +0100, David Demelier
>
> wrote:
> > Le mardi 12 février 2013 10:01:10 Andriy Gapon a écrit :
> >> on 12/02/2013 09:57 David Demelier said the following:
> >> > Yes I have added debugging option in my kernel. I
2013/2/14 David Demelier
> Le mardi 12 février 2013 21:42:01 Ronald Klop a écrit :
> > On Tue, 12 Feb 2013 19:44:49 +0100, David Demelier
> >
> > wrote:
> > > Le mardi 12 février 2013 10:01:10 Andriy Gapon a écrit :
> > >> on 12/02/2013 09:57 David Demelier said the following:
> > >> > Yes I hav
Le mardi 12 février 2013 21:42:01 Ronald Klop a écrit :
> On Tue, 12 Feb 2013 19:44:49 +0100, David Demelier
>
> wrote:
> > Le mardi 12 février 2013 10:01:10 Andriy Gapon a écrit :
> >> on 12/02/2013 09:57 David Demelier said the following:
> >> > Yes I have added debugging option in my kernel. I
On Tue, 12 Feb 2013 19:44:49 +0100, David Demelier
wrote:
Le mardi 12 février 2013 10:01:10 Andriy Gapon a écrit :
on 12/02/2013 09:57 David Demelier said the following:
> Yes I have added debugging option in my kernel. I have makeoptions
> DEBUG=-g in my config. Do I need more ?
.symbols?
Okay I will update everything and use GENERIC config, if I get more info
I'll tell you :-),
Cheers and thanks for your answers
2013/2/12 Andriy Gapon
> on 12/02/2013 20:44 David Demelier said the following:
> > Le mardi 12 février 2013 10:01:10 Andriy Gapon a écrit :
> >> on 12/02/2013 09:57 D
on 12/02/2013 20:44 David Demelier said the following:
> Le mardi 12 février 2013 10:01:10 Andriy Gapon a écrit :
>> on 12/02/2013 09:57 David Demelier said the following:
>>> Yes I have added debugging option in my kernel. I have makeoptions
>>> DEBUG=-g in my config. Do I need more ?
>>
>> .symbo
Le mardi 12 février 2013 10:01:10 Andriy Gapon a écrit :
> on 12/02/2013 09:57 David Demelier said the following:
> > Yes I have added debugging option in my kernel. I have makeoptions
> > DEBUG=-g in my config. Do I need more ?
>
> .symbols?
I don't understand what you are saying, I have /boot/k
on 12/02/2013 09:57 David Demelier said the following:
> Yes I have added debugging option in my kernel. I have makeoptions DEBUG=-g in
> my config. Do I need more ?
.symbols?
I don't know how else to explain consistently broken / useless stack traces.
> I'm not sure to understand what you meant
Yes I have added debugging option in my kernel. I have makeoptions DEBUG=-g
in my config. Do I need more ?
I'm not sure to understand what you meant about stray signatures..
--
Demelier David
___
freebsd-stable@freebsd.org mailing list
http://lists.fre
on 11/02/2013 22:33 David Demelier said the following:
> Le jeudi 7 février 2013 10:55:09 Andriy Gapon a écrit :
>> Without so much as a stack trace there is nothing to chew on.
>> A useable vmcore would be better.
>>
>> Did you perhaps use kgdb with a mismatching kernel?
Please don't leave stray
Le jeudi 7 février 2013 10:55:09 Andriy Gapon a écrit :
> Without so much as a stack trace there is nothing to chew on.
> A useable vmcore would be better.
>
> Did you perhaps use kgdb with a mismatching kernel?
--
I still have panic, and recompiled kernel, the stack info is not better but I
ha
On 07/02/2013 09:55, Andriy Gapon wrote:
>
> Without so much as a stack trace there is nothing to chew on.
> A useable vmcore would be better.
>
> Did you perhaps use kgdb with a mismatching kernel?
>
I don't remember, I just rebuild a new kernel and will provide more info
if panic occurs again
Without so much as a stack trace there is nothing to chew on.
A useable vmcore would be better.
Did you perhaps use kgdb with a mismatching kernel?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/f
On 06/02/2013 16:31, David Demelier wrote:
> Hello there,
>
> I recently had a panic at shutdown in 9.1-STABLE, there's the backtrace:
>
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General P
Hello there,
I recently had a panic at shutdown in 9.1-STABLE, there's the backtrace:
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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
Andriy Gapon wrote:
> on 23/10/2012 21:38 Per olof Ljungmark said the following:
>> On 2012-10-23 19:41, jb wrote:
>>> Per olof Ljungmark intersonic.se> writes:
>>>
...
Setting sysctl hw.usb.no_shutdown_wait=1 does NOT fix the problem as
described in
http://www.freebsd.org/cgi
On 10/23/12 21:44, Andriy Gapon wrote:
> on 23/10/2012 21:38 Per olof Ljungmark said the following:
>> On 2012-10-23 19:41, jb wrote:
>>> Per olof Ljungmark intersonic.se> writes:
>>>
...
Setting sysctl hw.usb.no_shutdown_wait=1 does NOT fix the problem as
described in
http://
on 23/10/2012 21:38 Per olof Ljungmark said the following:
> On 2012-10-23 19:41, jb wrote:
>> Per olof Ljungmark intersonic.se> writes:
>>
>>> ...
>>> Setting sysctl hw.usb.no_shutdown_wait=1 does NOT fix the problem as
>>> described in
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167685
On 2012-10-23 19:41, jb wrote:
> Per olof Ljungmark intersonic.se> writes:
>
>> ...
>> Setting sysctl hw.usb.no_shutdown_wait=1 does NOT fix the problem as
>> described in
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167685
>> ...
>
> There is another one:
> http://www.freebsd.org/cgi/que
Per olof Ljungmark intersonic.se> writes:
> ...
> Setting sysctl hw.usb.no_shutdown_wait=1 does NOT fix the problem as
> described in
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/167685
> ...
There is another one:
http://www.freebsd.org/cgi/query-pr.cgi?pr=172952&cat=
jb
___
the file system.
"shutdown -r now" or "halt -p" will stop after "Syncing discs" forever.
It is seen here on various HP boxes, DL360 G4, G5, XW6600 are examples.
Issuing a "shutdown -n -o -r now" works however and I assume this is not
too harmful with ZFS?
On 2012-08-28 22:51, Matt Smith wrote:
On 2012-08-27 21:35, Warren Block wrote:
On Mon, 27 Aug 2012, Matt Smith wrote:
Thank you for your help anyway, and your wonkity site, which I also
once used for converting my procmail to maildrop. And thanks also to
Erich and Stefan for your help. When I
1 - 100 of 374 matches
Mail list logo
