Re: Kernel panic on 6.1: init dies under load

[Mike Belopuhov]

Hi Dan,

That's good news, thanks for testing!  I've updated the diff
slightly.  Unfortunately I couldn't figure out what's causing
"boot dump" to crash.  I've exercised coredump, physio and
read-ahead codepaths.  I'll commit the diff next week unless
there's going to be reports of some breakage.

The diff is available from the same location as previously:
http://gir.theapt.org/~mike/xbf.diff

Thanks for testing!

On 27 May 2017 at 03:33, Dan Cross  wrote:

> Thanks for this latest patch; it seems to help. At least, I was able to
> put a fairly significant amount of load on the machine with out a panic.
> I'll try and load it up more and see where we get, but so far this is
> positive.
>
> On Wed, May 24, 2017 at 7:37 PM, Mike Belopuhov 
> wrote:
>
>> On Wed, May 24, 2017 at 12:27 -0400, Dan Cross wrote:
>> > Thanks for the patch; I just got a few minutes today and I applied it,
>> > rebuilt and installed the kernel and rebooted. Sadly, I get a similar
>> > panic. Attached is a screenshot of console output. Note that, 'boot
>> sync'
>> > from ddb hangs forever.
>> >
>> > - Dan C.
>>
>> That's OK. I've discovered more problems related to 64k transfers.
>> The reason why we didn't notice anything bad when aborting sleep
>> was because sleep has a small memory footprint, but if you dump
>> core of a larger (> 64k) program, you'd notice the issue because
>> core dump routine like some other places in the kernel assumes
>> that 64k transfers always work.
>>
>> I've attempted to attack this problem from a different angle:
>> ensure that xbf(4) can handle 64k transfers.  Solutions to this
>> problem are notoriously messy and complicated and so far this
>> one is no exception. Today I got to the point where the system
>> boots multiuser but couldn't test further. I've noticed however
>> that "boot dump" from ddb still crashes so I know it's not 100%
>> right just yet, but since I won't get around doing anything
>> about this until early next week, I'd appreciate a quick test
>> if possible.
>>
>> I'm not attaching the diff since it's rather large:
>>
>> http://gir.theapt.org/~mike/xbf.diff
>>
>> Cheers,
>> Mike
>>
>
>

[patch] macppc/machdep.c: fix typo, no -> not

[Scott Cheloha]

The struggle is very real when you're getting kernel panics, but the
struggle needn't have typos.

--
Scott Cheloha

Index: sys/arch/macppc/macppc/machdep.c
===
RCS file: /cvs/src/sys/arch/macppc/macppc/machdep.c,v
retrieving revision 1.180
diff -u -p -r1.180 machdep.c
--- sys/arch/macppc/macppc/machdep.c30 Apr 2017 16:45:45 -  1.180
+++ sys/arch/macppc/macppc/machdep.c3 Jun 2017 14:20:04 -
@@ -712,7 +712,7 @@ dumpsys()
printf(str, error);
 
 #else
-   printf("dumpsys() - no yet supported\n");
+   printf("dumpsys() - not yet supported\n");

 #endif
delay(500); /* 5 seconds */

Re: a strange set of HUGE bugs

[Stuart Henderson]

On 2017/06/03 11:21, Stefan Sperling wrote:
> On Fri, Jun 02, 2017 at 11:10:29PM -0400, Daniel Russell wrote:
> > on both the amd64 and i386 versions the manual and alot of the config files
> > are missing and noone not even root has root permissions (note that i'm
> > using the flash drive version of both and using the filesets that come with
> > them)
> > 
> > because of the nature of the releases i had to use different machines
> > 
> > amd64: latitude-d630
> > cpu: intel core2 duo cpu t7100 @ 1.80ghz x 2 (gotten from
> > ubuntu)(integrated)
> > (integrated) gpu: intel 965GM x86/MMX/SSE2
> > 
> > i386 (i have much less information about this one)
> > another in the latitude series but this time with a pentium m cpu (and
> > that's the extent of my knowledge)
> > 
> > both had the exact same problem and seemingly had no fix whatsoever because
> > i couldn't run bsd.rd
> 
> Please focus on a single problem per bug report and provide a very clear
> description of the issue. If you don't even bother to include a dmesg
> nobody will take your report seriously.
> See http://www.openbsd.org/report.html for the proper procedure to follow.
> 

yep.

Start with saying *exactly* what you are trying to run.

What is "the flash drive version"?

Re: a strange set of HUGE bugs

[Stefan Sperling]

On Fri, Jun 02, 2017 at 11:10:29PM -0400, Daniel Russell wrote:
> on both the amd64 and i386 versions the manual and alot of the config files
> are missing and noone not even root has root permissions (note that i'm
> using the flash drive version of both and using the filesets that come with
> them)
> 
> because of the nature of the releases i had to use different machines
> 
> amd64: latitude-d630
> cpu: intel core2 duo cpu t7100 @ 1.80ghz x 2 (gotten from
> ubuntu)(integrated)
> (integrated) gpu: intel 965GM x86/MMX/SSE2
> 
> i386 (i have much less information about this one)
> another in the latitude series but this time with a pentium m cpu (and
> that's the extent of my knowledge)
> 
> both had the exact same problem and seemingly had no fix whatsoever because
> i couldn't run bsd.rd

Please focus on a single problem per bug report and provide a very clear
description of the issue. If you don't even bother to include a dmesg
nobody will take your report seriously.
See http://www.openbsd.org/report.html for the proper procedure to follow.