Replying to myself again, I again doubled the bio_transient_maxcnt:
original value 160, failed doubling 360, new value 720; and the machine was
able to successfully "for i in jot 10; do make -j4 buildkernel; done" ...
But doesn't this mean that we still have a resource exhaustion to worry
about?
Since there weren't any more ideas here, I tried turning off
hyper-threading. This is an old pentium-D type CPU --- that is: one core
with HT. I'm wondering if the HT nature is helping this resource
exhaustion, so I turned off HT (basically making this a single-threaded
CPU) and it seems to have
The first one (kern.geom.transient_map_retries) causes the system to wedge.
The second one (default is 180, I doubled to 360) causes the system to
crash but not dump.
So... neither fixes the problem.
On Sat, Aug 31, 2013 at 5:27 AM, Edward Tomasz Napierała
wrote:
> Wiadomość napisana przez Zap
Wiadomość napisana przez Zaphod Beeblebrox w dniu 31 sie
2013, o godz. 00:49:
> Because someone said that there would be no logging of unerlying ATA errors
> without verbose, I rebooted with verbose and tried the same make -j4 again...
> and here is the relatively similar core.txt.5
>
> https:
Because someone said that there would be no logging of unerlying ATA errors
without verbose, I rebooted with verbose and tried the same make -j4
again... and here is the relatively similar core.txt.5
https://uk.eicat.ca/owncloud/public.php?service=files&t=d99648ef5876b91c5957148445e60c87
Looking
My bad. New link for the core.txt.4:
https://uk.eicat.ca/owncloud/public.php?service=files&t=f471e5afae483342cd20dc390e9c2dd7
On Fri, Aug 30, 2013 at 4:51 PM, Ian Lepore wrote:
> On Fri, 2013-08-30 at 21:50 +0200, Edward Tomasz Napierała wrote:
> > Wiadomość napisana przez Zaphod Beeblebrox
On Fri, 2013-08-30 at 21:50 +0200, Edward Tomasz Napierała wrote:
> Wiadomość napisana przez Zaphod Beeblebrox w dniu 29 sie
> 2013, o godz. 23:35:
> > So I have a system running:
> >
> > FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 03:02:55
> > EDT 2013 r...@walk.dclg.
Wiadomość napisana przez Zaphod Beeblebrox w dniu 29 sie
2013, o godz. 23:35:
> So I have a system running:
>
> FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 03:02:55
> EDT 2013 r...@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386
>
> and it has two 2T SATA disks. To ke
I was going to mention that I ran fsck _twice_, but I forgot. Then when
that didn't fix it, I dumped the filesystem, newfs'd it and restored it.
Then I fsck'd it for good measure.
This particular crash immediately follows that treatment.
I can do this in a loop:
boot -> make -j4 buildkernel ->
On Thu, Aug 29, 2013 at 4:35 PM, Zaphod Beeblebrox wrote:
> So I have a system running:
>
> FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28
> 03:02:55
> EDT 2013 r...@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386
>
> and it has two 2T SATA disks. To keep this post short, t
So I have a system running:
FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 03:02:55
EDT 2013 r...@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE i386
and it has two 2T SATA disks. To keep this post short, the crash.txt is
here.
https://uk.eicat.ca/owncloud/public.php?service=
11 matches
Mail list logo