On 06/09/2016 10:20, jenkins-ad...@freebsd.org wrote:
> 305459 by avg:
> MFC r303738: report sector size and number of sectors in lsdev output
> for bios disks
Should be fixed by r305466. Sorry for the breakage.
--
Andriy Gapon
___
freeb
n unlinked from a directory
specified by the attribute.
So, at the moment I do not have any good ideas on how to make this work.
Maybe trying to use the parent attribute and failing when it's inconsistent
would be good enough...
--
Andriy Gapon
which CPU is the BSP on its own.
*/
...
In other words, those "SMP: Added CPU ..." are truly a cosmetic issue.
And it's my guess (just a guess) that BSP LAPIC ID is incorrect in the
problematic configuration.
--
Andriy Gapon
___
On 04/09/2016 18:14, Konstantin Belousov wrote:
> On Sun, Sep 04, 2016 at 11:19:16AM +0300, Andriy Gapon wrote:
>> Kostik, I see one strange thing which is common to both successful and
>> unsuccessful configurations. All "SMP: Added CPU..." lines have "AP"
On 04/09/2016 11:24, Andriy Gapon wrote:
> On 27/08/2016 22:09, Frederic Chardon wrote:
>>> Anybody is able to reproduce this behavior or is it a local problem?
>> Reverting 303970 solves this issue. gcore and adb works again, and I
>> can start the vboxnet service.
>
to be sure.
I can not reproduce this issue here.
Unfortunately, I have no clue how kern.proc.pathname works, so I would
appreciate any hints at what filesystem operations I should look for potential
problems.
--
Andriy Gapon
___
freebsd-stable@freebsd.o
f8078fe81 at cpu_mp_start+0x1b1
> #9 0x805382ca at mp_start+0x3a
> #10 0x80465cd8 at mi_startup+0x118
> #11 0x8028dfac at btext+0x2c
> Uptime: 1s
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On 22/07/2016 16:39, Steven Hartland wrote:
> Yes does indeed sound like what happened to me.
Can you think of any way that we can use to limit the zio_execute
chaining? Like somehow keeping track of the nesting and returning NULL
instead of a queued zio when we reach a limit.
--
Andriy Ga
was my roll-forward to 11.0 its "origin"
> was a clone of 10.2 before the install was done, so that snapshot was
> present in the zfs snapshot list. However, it had been present for
> several days without incident, so I doubt its presence was involved in
> the creation o
his a freshly imported pool? Or a pool that was not written to
since the import until shortly before the crash?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
of zio-s printed,
including the top-most one at 0xf805dcd9d3b8.
Something like:
set print pretty
p *zio
p *zio->io_vd
p *zio->io_vd->vdev_ops
in several frames.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.fr
or io instead of the buffer
> KVA.
I don't have any idea why the thread would be stuck in bwait() and what locks
and threads are involved here. But, as Kostik said, there is a general problem
and I have a patch for ZFS:
https://reviews.freebsd.org/D2790
--
Andriy Gapon
On 09/03/2016 06:54, Morgan Reed wrote:
> I am mounting the third pool under an alternate root, if that has any
> bearing on things.
It does. A pool imported under an alternative root (-R option) is not added to
zpool.cache.
--
Andriy
o easily switch between BEs during boot is a part of the BE
experience. Think of a situation where a new BE gets a kernel panic half way
through the boot process.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mail
On 06/11/2015 07:53, Eugene M. Zheganin wrote:
> Hi.
>
> On 06.11.2015 02:58, Andriy Gapon wrote:
>>
>> It could be that your BIOS is not able to read past 1TB (512 * INT_MAX). That
>> seems to be a rather common problem for consumer motherboards.
>> Here is a
On 06/11/2015 18:00, Alan Somers wrote:
> I notice that my 10.2-RELEASE VM prints the same message about "all
> block copies unavailable" and then continues to boot just fine.
Is that on a system with only one ZFS pool or are there more of them?
g 2,53M 1,05T 2,53M /var/log
> zroot/var/mail 272K 1,05T 272K /var/mail
> zroot/var/run 520K 1,05T 520K /var/run
> zroot/var/tmp 22,7M 1,05T 22,7M /var/tmp
>
>
> ___
[sorry for top-posting *again*]
Just for the records, doing `make make` and then using the resulting make binary
seems to have solved the problems.
On 23/10/2015 13:27, Andriy Gapon wrote:
>
> Oh, hrrm:
>
> --- libbackend.a ---
> building static backend library
> nm:
ng: can't open file: rtl.o: No such file or directory
ar: warning: can't open file: print-rtl.o: No such file or directory
ranlib libbackend.a
That's with -j4 during another attempt to build the same target.
On 23/10/2015 12:46, Andriy Gapon wrote:
>
> $ make kernel-toolchai
_size'
/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:575:
undefined reference to `mode_size'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1
--
Andriy Gapon
___
fr
ey are honored only by zfs(8) utility. Thus, they can not
possibly influence root mounting. Modulo very very very obscure bugs, of
course.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sta
on 15/09/2013 17:16 J David said the following:
> Thanks very much for the info Andriy.
>
> On Fri, Sep 13, 2013 at 9:22 AM, Andriy Gapon wrote:
>> Another piece of information is that neither mountpoint nor canmount property
>> affects ZFS root mounting.
>
> It is m
nt nor canmount property
affects ZFS root mounting. They of course have their usual effect in other
contexts like importing a pool on a different system or when a different
filesystem is selected to be a root filesystem.
So, again, you can set these properties to whatever is most convenient for you.
-
pool imports fine from the 9.2-RC3 live cd. The zpool's
> bootfs is set correctly, the zfs mountpoint of data/root is / . And,
> of course, init is present and health in data/root. The system booted
> fine until updating to 9.2.
I just wish that I could reproduce this probl
LORs but nothing bad happened so far:
>>
>> http://olgeni.olgeni.com/~olgeni/dmesg-2013-09-12
> Out of curiousity, please look up the line for vm_object_terminate+0x1d8.
>
>>
>> If it keeps working this way I hope there's still some time to fit it
>> into a
#x27;t then it's a bug.
--
Andriy Gapon
___
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"
d that I want to
investigate / analyze that first.
--
Andriy Gapon
___
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"
s like it's supposed to be NULL for
> one pair of the two HT CPUs?
>
> Are you taking the whole core into an ACPI idle state if one of two logical
> CPUs
> representing a core is going idle?
--
Andriy Gapon
___
freebsd-stabl
on 02/09/2013 00:58 Adrian Chadd said the following:
> On 1 September 2013 14:35, Andriy Gapon <mailto:a...@freebsd.org>> wrote:
>
>
> Do you have any evidence that there is anybody else besides Mike who has
> this
> problem?
>
>
>
> N
on 01/09/2013 23:40 Adrian Chadd said the following:
> On 31 August 2013 23:41, Andriy Gapon <mailto:a...@freebsd.org>>
> wrote:
>
> >
> > I've tracked this down to a single line, details in
> > http://www.freebsd.org/cgi/query-pr.
vg - can we get this fixed? Or just revert this!
Thank you for trying to be helpful. But let's not jump to conclusions.
BTW, I am following up on the problem in the PR.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://li
on 30/08/2013 13:37 Andriy Gapon said the following:
> on 30/08/2013 00:38 Charles Sprickman said the following:
>> If one is willing to accept that data is lost (like the log device is
>> totally smoked), is there a way to boot knowing that you may have some data
>> loss,
able by a tunable.
--
Andriy Gapon
___
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 29/08/2013 16:03 Toomas Aas said the following:
> Hello!
>
> On Thu, 29 Aug 2013 Jase Thew wrote:
>
>> On 29/08/2013 11:24, Andriy Gapon wrote:
>>> on 29/08/2013 10:47 Andriy Gapon said the following:
>>>> It looks like I should have done more inves
on 29/08/2013 10:47 Andriy Gapon said the following:
> It looks like I should have done more investigation on the state of devfs in
> stable/8 before MFC-ing the change. There are several earlier big commits
> that
> have not been MFC-ed.
> So, now I can either revert the MFC and
rnel (and
perhaps modules). Also, kgdb and libkvm.so from the matching system can be
needed.
Perhaps you could try examining the devfs_rule_run frame to give a start?
Like listing the source code line and examining all local variables.
Thank you.
--
Andriy Gapon
__
then the pool is
inconsistent state without the log device and so it can not be imported.
The cache is not persistent and so there is nothing needed from it upon a boot.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.or
on 28/08/2013 20:29 Jase Thew said the following:
> On 24/08/2013 21:03, Toomas Aas wrote:
>> Hello!
>>
>> On Fri, 23 Aug 2013 Andriy Gapon wrote:
>>
>>>
>>> This change is about to be MFC-ed.
>>>
>>> on 26/07/2013 17:39 And
This change is about to be MFC-ed.
on 26/07/2013 17:39 Andriy Gapon said the following:
>
> I have just committed a significant change to devfs path matching logic
> http://svnweb.freebsd.org/changeset/base/253677
>
> Jaakko Heinonen (jh@) has full credit for the code wh
for a goal you want to achieve?
If yes, are you sure that you want to use idprio 31 specifically?
With sched_ule idprio 31 is equivalent to priority of a completely idle system.
So the scheduler is in its right to run the idle ("do nothing") thread instead
of your
on 18/07/2013 20:44 George Hartzell said the following:
> Andriy Gapon writes:
> > on 17/07/2013 23:47 George Hartzell said the following:
> > > How should I move forward with this?
> >
> > Could you please try to reproduce this problem using a kernel buil
(Output for da3 - da7 are identical to da2.)
Could you please hack gpt_checkhdr() in sys/boot/common/part.c to print all the
relevant values for this check and try bootparttest again?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://
fs.boot.primary_pool
loader variables (if any are set). These can be obtained using 'show' command
at loader prompt. Also, output of lsdev -v.
Also, if you are able to build custom 9.2 zfsloader, then it would be useful to
modify the printf statement (in zfs_fmtdev(), sys/boo
nteresting to see what zfsboottest says about the pool.
Especially interesting it would be to see the error in a debugger.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsub
on 26/07/2013 17:39 Andriy Gapon said the following:
> Please note that nothing changes with respect to matching simple paths like
> /dev/something.
I must add: and thus rules in etc/defaults/devfs.rules should not be affected
except for their unintended side-effects.
--
Andriy
table@ because I currently plan to MFC this change after 1 month
period. If you know a reason why the MFC should not be done, please alert me
to it.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-s
on 17/07/2013 23:47 George Hartzell said the following:
> How should I move forward with this?
Could you please try to reproduce this problem using a kernel built with
INVARIANTS options?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing l
ing the same kind of clean up as done on zfs module
unload would be advantageous.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-
his commit:
commit 9ef2a49ec43e6ebf429e4dae3bf230a09ae106f1
Author: Andriy Gapon
Date: Fri May 18 12:58:13 2012 +0300
[test] mark all locks in printf(9) call tree as no-witness
... to avoid warnings because of complex interactions between printf(9)
being called from arbitrary conte
on 11/07/2013 23:07 Dimitry Andric said the following:
> On Jul 11, 2013, at 19:19, Andriy Gapon wrote:
>> on 11/07/2013 19:43 Andriy Gapon said the following:
>>>
>>> buildword was run as make -j8 buildworld and the it mysteriously failed
>>> like this:
>
on 11/07/2013 19:43 Andriy Gapon said the following:
>
> buildword was run as make -j8 buildworld and the it mysteriously failed like
> this:
>
> sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.80
> /usr/obj/usr/src/tmp/usr/lib
> sh /usr/src/
*** [libraries] Error code 2
I could not find any actual error message in the build log.
/usr/obj was cleaned out before the build.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To
and keep two copies of earlier boot chains.
I am also not shy of live media in the case everything else fails.
Now I wonder how you deal with the same kind of UFS-only environment.
--
Andriy Gapon
___
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"
you are so over-focused on ZFS.
Please stop spreading FUD. Thank you.
--
Andriy Gapon
___
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"
and then restores it back to some (what?) previous value before calling
devfs_fpdrop->devfs_destroy_cdevpriv. In this case the previous value is NULL.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fr
n properly reporting the problem first?
:-)
--
Andriy Gapon
___
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"
ad error'. It would be
>> interesting to see the output of 'lsdev -v' from the loader prompt.
>>
>
> by the way, where I can find a transcript of codes?
In the BIOS Int 13h documentation.
E.g.:
http://stanislavs.org/helppc/int_13-2.html
http://www.bioscentral.
d to provide the following details:
>
> 1. Contents of /etc/rc.conf
> 2. Contents of /etc/sysctl.conf (if modified)
> 3. Contents of /etc/fstab
> 4. ifconfig -a
> 5. OS used by the NFS server, and all configuration details pertaining
> to that system
&
gt; ) at /usr/src/sys/kern/sched_ule.c:1921
> Previous frame inner to this frame (corrupt stack?)
> (kgdb) bt f
> #0 sched_switch (td=0x812228a0, newtd=0xfe00051c8000,
> flags=Variable "flags" is not available.
> ) at /usr/src/sys/kern/sched_ule.c:1927
>
the purpose of debugging the issue.
I also completely agree that "me too"-ing is not very useful (and often
completely
incorrect) for the complex problems like this one.
Thank you.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://
m.oss1 {
> type oss
> device /dev/dsp1
> hint {
> description "Open Sound System"
> }
> }
>
> ctl.oss1 {
> type oss
> device /dev/mixer1
> hint {
> description "Ope
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 i
tand what you meant about stray signatures..
"-- " sequence. Let me show you:
--
There is a stray signature sequence above this line.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/
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 k
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
installed on the SSD.
>
> Any ideas where this could be originating from?
"error 6" is ENXIO, which usually corresponds to a disappearing device or some
such. Do you get anything in logs (or other objective experience) that could
look like that?
--
Andriy Gapon
_
y used hardware, it
goes unnoticed. Then someone notices, reports. From that point, all depends on
that someone and on the developers.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-sta
on 30/01/2013 00:44 Andriy Gapon said the following:
> on 29/01/2013 23:44 Hiroki Sato said the following:
>> http://people.allbsd.org/~hrs/FreeBSD/pool-20130130.txt
>> http://people.allbsd.org/~hrs/FreeBSD/pool-20130130-info.txt
>
[snip]
> See tid 100153 (arc reclai
on 30/01/2013 01:06 Rick Macklem said the following:
> Andriy Gapon wrote:
>> on 29/01/2013 23:44 Hiroki Sato said the following:
>>> http://people.allbsd.org/~hrs/FreeBSD/pool-20130130.txt
>>> http://people.allbsd.org/~hrs/FreeBSD/pool-20130130-info.txt
>&
59 for 8).
See tid 100153 (arc reclaim thread), tid 100105 (pagedaemon) and tid 100639
(nfsd in kmem_back).
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any m
_wait
> rrw_enter zfs_root lookup namei vfs_donmount sys_nmount amd64_syscall
> Xfast_syscall
...
> If it happens again
procstat -kk -a
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fr
on 27/01/2013 19:27 Adrian Chadd said the following:
> On 26 January 2013 02:15, Andriy Gapon wrote:
>> on 23/01/2013 18:20 Adrian Chadd said the following:
>>> It may be a quirk of an older 9.x, which is fixed in -HEAD. It may be
>>> a quirk of the older generation
re feature (or its
absence).
I wonder if your celerons report PBE feature.
--
Andriy Gapon
___
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 25/01/2013 12:26 Marin Atanasov Nikolov said the following:
> Yes, it's a brand new one.
Then no: http://en.wikipedia.org/wiki/Bathtub_curve
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/
If you have ACPI suspend/resume working, if it used to work but stopped working
at some time, if it never worked, but you are still hoping, could you please
test the following patch and report back?
http://svn.freebsd.by/files/acpi-apic-wakeup-final.patch
--
Andriy Gapon
7;s to do
> with whether the counters are reliable or not (and heck, are even in
> lock-step on CPUs.) But extra latency could show up weirdly, hence why
> I was asking for you to try different timer configurations and idle
> loops.
--
Andriy Gapon
--
Andriy Gapon
___
on 22/01/2013 17:05 Oleksii Tsvietnov said the following:
> On 01/22/2013 04:51 PM, Andriy Gapon wrote:
>> That's the average value since boot to now?
>
> Maybe...
> Does iostat's busy always show avarage value since boot?
Use -w option to see current state (sta
on 22/01/2013 16:47 Oleksii Tsvietnov said the following:
>
>> These are values since boot, they do not reflect current system load.
>
> As I could see these values usually change from 0 to 60 .
> Why did they freeze on 7%?
That's the average value since boot to
86.30 26.9 6
> da23 8.6 2.5 797.0 186.30 27.1 6
These are values since boot, they do not reflect current system load.
--
Andriy Gapon
___
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"
ther there is some HW issue or we've got some code that arbitrarily flips bits
in vm_page_array (and perhaps beyond it).
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe,
guys tried to obtain a stack trace of the stuck reboot thread (in ddb)?
Not all hangs in reboot have the same cause...
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubs
On the other hand, the stack trace from kgdb seems to be on
spot.
--
Andriy Gapon
___
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"
16:06:04 chinatsu kernel: devfs_root() at devfs_root+0x4d
> Dec 24 16:06:04 chinatsu kernel: vfs_donmount() at vfs_donmount+0xafa
> Dec 24 16:06:04 chinatsu kernel: sys_nmount() at sys_nmount+0x66
> Dec 24 16:06:04 chinatsu kernel: amd64_syscall() at amd64_syscall+0x30e
> Dec 24 16:06:0
on 25/12/2012 01:04 David Wolfskill said the following:
> On Tue, Dec 25, 2012 at 12:58:00AM +0200, Andriy Gapon wrote:
>> on 25/12/2012 00:39 David Wolfskill said the following:
>>> I had left teh kgdb session active; I also included "p *timehands" just in
>>>
Perhaps you could just add "#define DEBUG" to
sys/cddl/contrib/opensolaris/uts/common/sys/debug.h. I haven't tested this
approach though.
Also, please put vm.memguard.desc="arc_buf_hdr_t" into loader.conf.
Please note that these options will make your syst
on 25/12/2012 00:39 David Wolfskill said the following:
> I had left teh kgdb session active; I also included "p *timehands" just in
> case it might be of use:
Thank you.
Please also print &th0 ... &th9.
--
Andriy Gapon
___
fr
0xc0ad474a : push %edi
> 0xc0ad474b : push %esi
> 0xc0ad474c : sub$0x34,%esp
> 0xc0ad474f : mov0xc112a6c8,%ecx
> 0xc0ad4755 : mov%ecx,0x14(%esp)
> 0xc0ad4759 : mov0x38(%ecx),%ebx
> 0xc0ad475c : mov0x34(%ebx),%eax
Could you please also provide from the same frame
i reg
p &timehands
?
Thank you.
--
Andriy Gapon
___
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"
rc/sys/dev/acpica/acpi_hpet.c:278
> #13 0xc0a99c5c in intr_event_handle (ie=Unhandled dwarf expression opcode 0xa1
> )
> at /usr/src/sys/kern/kern_intr.c:1435
> #14 0xc0e4c552 in intr_execute_handlers (isrc=,
> frame=) at /usr/src/sys/x86/x86/intr_machdep.c:269
> #15 0xc0e4f50d in
on 24/12/2012 00:23 Derek Kulinski said the following:
> Dumping 3701 out of 8072 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
So do you have the crash dump(s)?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
h
on 23/12/2012 14:34 Kimmo Paasiala said the following:
> On Sun, Dec 23, 2012 at 2:28 PM, Andriy Gapon wrote:
>>
>> I have MFCed the following change, so please double-check if you might be
>> affected. Preferably before upgrading :-)
>>
>> on 28/11/2012 20:3
I have MFCed the following change, so please double-check if you might be
affected. Preferably before upgrading :-)
on 28/11/2012 20:35 Andriy Gapon said the following:
>
> Recently some changes were made to how a root pool is opened for root
> filesystem
> mounting. Previously t
uld be able to boot from any pool from which
you can boot now unless you have the condition described in the original
message.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubsc
on 14/12/2012 13:00 Alexey Dokuchaev said the following:
> On Fri, Dec 14, 2012 at 12:40:23PM +0200, Andriy Gapon wrote:
>> uart(4):
>> 0x00080 use this port for remote kernel debugging
>
> Thanks, that did the magic. The problem, however, is that kgdb from i386
> do
a problem.
uart(4):
0x00080 use this port for remote kernel debugging
There's probably a reason why this is not in the default hints, but I don't
know it.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/m
or a live remote debugging.
> It seems I have to debug it the hard way
> (hello printf's).
>
> Is it possible to cross build amd64 10.0 kernels on i386 8.3 machine?
amd64 on i386 - yes, 10 on 8.3 - not so sure...
--
Andriy Gapon
___
f
without
> debug symbols. Glen, since you include kernel debugger in you snapshots,
> do you think you can ship those .symbols as well? :-)
>
> ./danfe
>
> [1] http://193.124.210.26/10.0-acpi.dmesg
>
--
Andriy Gapon
___
fr
wrong. You can read in the links why panic was selected for this
job.
And speaking FreeBSD-centric - I think that our CAM layer would be a perfect
place
to detect such issues in non-ZFS-specific way.
--
Andriy Gapon
___
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"
age level.
Most likely it is a bug in storage controller driver which allowed an I/O
request
to get lost (instead of "errored out" or timed out).
`camcontrol tags -v` can be used to query depth of a queue for each disk
and determine the bad one.
--
Andriy Gapon
_
y head on this system?
This could have been fixed in more recent ACPICA imports. stable/9 seems have
ACPICA from many months ago.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
fixes were already merged to stable/9, as I was told.
> Cc:ed Andrey to confirm it once more.
Yes, a while ago.
--
Andriy Gapon
___
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"
101 - 200 of 952 matches
Mail list logo
