The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] 211bsd kermit working
@ 2020-08-09 21:05 Will Senn
  2020-08-09 21:12 ` Clem Cole
  2020-08-09 23:21 ` Warner Losh
  0 siblings, 2 replies; 8+ messages in thread
From: Will Senn @ 2020-08-09 21:05 UTC (permalink / raw)
  To: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

I'm running 211bsd pl 431 in SimH on FreeBSD. I've got networking 
working on a tap interface both inbound and outbound. I still have a few 
issues hanging around that are bugging me, but I'll eventually get to 
them. One that is of concern at the moment is kermit. It is in the 
system under /usr/new/kermit. When I call it, I get:

kermit
Bad system call - core dumped

I don't see core anywhere and if I did, I'd need to figure out what to 
do with it anyway (mabye adb), but I'm wondering if anyone's used kermit 
successfully who is on pl 431 or knows what's going on?

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF


[-- Attachment #2: Type: text/html, Size: 1039 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [TUHS] 211bsd kermit working
  2020-08-09 21:05 [TUHS] 211bsd kermit working Will Senn
@ 2020-08-09 21:12 ` Clem Cole
  2020-08-09 21:31   ` Will Senn
  2020-08-09 23:21 ` Warner Losh
  1 sibling, 1 reply; 8+ messages in thread
From: Clem Cole @ 2020-08-09 21:12 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

try this: adb /usr/new/kermit
Then run it and let it crash.  You'll get an adb prompt, look at the stack
and see what system call number was pushed.

I suspect it a versioning issue that Warner has been discussing as 2.X
changed over time.

That said, it might just be easier to try to recompile c-kermit.

Clem

On Sun, Aug 9, 2020 at 5:06 PM Will Senn <will.senn@gmail.com> wrote:

> I'm running 211bsd pl 431 in SimH on FreeBSD. I've got networking working
> on a tap interface both inbound and outbound. I still have a few issues
> hanging around that are bugging me, but I'll eventually get to them. One
> that is of concern at the moment is kermit. It is in the system under
> /usr/new/kermit. When I call it, I get:
>
> kermit
> Bad system call - core dumped
>
> I don't see core anywhere and if I did, I'd need to figure out what to do
> with it anyway (mabye adb), but I'm wondering if anyone's used kermit
> successfully who is on pl 431 or knows what's going on?
>
> Thanks,
>
> Will
>
> --
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>

[-- Attachment #2: Type: text/html, Size: 2319 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [TUHS] 211bsd kermit working
  2020-08-09 21:12 ` Clem Cole
@ 2020-08-09 21:31   ` Will Senn
  2020-08-10  0:53     ` Dave Horsfall
  0 siblings, 1 reply; 8+ messages in thread
From: Will Senn @ 2020-08-09 21:31 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

Well, that sure sounds easy. I found the core file and figured out that:

adb /usr/new/kermit kermit.core

was the incantation to load stuff into adb. $c is the stack trace:
$c
0177520: ~signal(016,01) from ~sysinit+034
0177542: ~sysinit() from ~main+010
0177560: _main() from start+0104
adb> ^D

If this means it got signal 16... or 1 from the sysinit call (called 
from main), then according to man signal 16's urgent condition present 
on socket, and 01's just hangup. 's all greek to me at this point. I'm 
super new to adb. I tried your approach adb /usr/new/kermit and it 
brought up the adb prompt, so I gather it works that way too, but I 
couldn't figure out how to run it from there. A quick perusal of the adb 
man page didn't really help. I'm off to finish reading the ADB tutorial 
that I bailed on last week in v7 after I hit the there's no fcreat in v7 
issue  :).

Will


On 8/9/20 4:12 PM, Clem Cole wrote:
> try this: adb /usr/new/kermit
> Then run it and let it crash.  You'll get an adb prompt, look at the 
> stack and see what system call number was pushed.
>
> I suspect it a versioning issue that Warner has been discussing as 2.X 
> changed over time.
>
> That said, it might just be easier to try to recompile c-kermit.
>
> Clem
>
> On Sun, Aug 9, 2020 at 5:06 PM Will Senn <will.senn@gmail.com 
> <mailto:will.senn@gmail.com>> wrote:
>
>     I'm running 211bsd pl 431 in SimH on FreeBSD. I've got networking
>     working on a tap interface both inbound and outbound. I still have
>     a few issues hanging around that are bugging me, but I'll
>     eventually get to them. One that is of concern at the moment is
>     kermit. It is in the system under /usr/new/kermit. When I call it,
>     I get:
>
>     kermit
>     Bad system call - core dumped
>
>     I don't see core anywhere and if I did, I'd need to figure out
>     what to do with it anyway (mabye adb), but I'm wondering if
>     anyone's used kermit successfully who is on pl 431 or knows what's
>     going on?
>
>     Thanks,
>
>     Will
>
>     -- 
>     GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>


-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF


[-- Attachment #2: Type: text/html, Size: 4442 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [TUHS] 211bsd kermit working
  2020-08-09 21:05 [TUHS] 211bsd kermit working Will Senn
  2020-08-09 21:12 ` Clem Cole
@ 2020-08-09 23:21 ` Warner Losh
  1 sibling, 0 replies; 8+ messages in thread
From: Warner Losh @ 2020-08-09 23:21 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

Maybe rebuild kermit? A crapton of compat stuff was removed over time.
Maybe the binary is stale?

Warner

On Sun, Aug 9, 2020, 3:06 PM Will Senn <will.senn@gmail.com> wrote:

> I'm running 211bsd pl 431 in SimH on FreeBSD. I've got networking working
> on a tap interface both inbound and outbound. I still have a few issues
> hanging around that are bugging me, but I'll eventually get to them. One
> that is of concern at the moment is kermit. It is in the system under
> /usr/new/kermit. When I call it, I get:
>
> kermit
> Bad system call - core dumped
>
> I don't see core anywhere and if I did, I'd need to figure out what to do
> with it anyway (mabye adb), but I'm wondering if anyone's used kermit
> successfully who is on pl 431 or knows what's going on?
>
> Thanks,
>
> Will
>
> --
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>

[-- Attachment #2: Type: text/html, Size: 1469 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [TUHS] 211bsd kermit working
  2020-08-09 21:31   ` Will Senn
@ 2020-08-10  0:53     ` Dave Horsfall
  2020-08-10  1:42       ` Will Senn
  0 siblings, 1 reply; 8+ messages in thread
From: Dave Horsfall @ 2020-08-10  0:53 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Sun, 9 Aug 2020, Will Senn wrote:

> Well, that sure sounds easy. I found the core file and figured out that:
> 
> adb /usr/new/kermit kermit.core
> 
> was the incantation to load stuff into adb. $c is the stack trace:
> $c
> 0177520: ~signal(016,01) from ~sysinit+034
> 0177542: ~sysinit() from ~main+010
> 0177560: _main() from start+0104
> adb> ^D
> 
> If this means it got signal 16... or 1 from the sysinit call (called 
> from main), then according to man signal 16's urgent condition present 
> on socket, and 01's just hangup. [...]

Is not "016" octal i.e. 14 i.e. SIGTERM in older versions of *x?

-- Dave

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [TUHS] 211bsd kermit working
  2020-08-10  0:53     ` Dave Horsfall
@ 2020-08-10  1:42       ` Will Senn
  0 siblings, 0 replies; 8+ messages in thread
From: Will Senn @ 2020-08-10  1:42 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

On 8/9/20 7:53 PM, Dave Horsfall wrote:
> On Sun, 9 Aug 2020, Will Senn wrote:
>
>> Well, that sure sounds easy. I found the core file and figured out that:
>>
>> adb /usr/new/kermit kermit.core
>>
>> was the incantation to load stuff into adb. $c is the stack trace:
>> $c
>> 0177520: ~signal(016,01) from ~sysinit+034
>> 0177542: ~sysinit() from ~main+010
>> 0177560: _main() from start+0104
>> adb> ^D
>>
>> If this means it got signal 16... or 1 from the sysinit call (called 
>> from main), then according to man signal 16's urgent condition 
>> present on socket, and 01's just hangup. [...]
>
> Is not "016" octal i.e. 14 i.e. SIGTERM in older versions of *x?
>
> -- Dave
Good catch on the octal, but here's the list from man signal:

SIGALRM   14   alarm clock
SIGTERM   15   software termination signal
SIGURG    16@  urgent condition present on socket

So, SIGALRM? Hmm.. I'm prolly gonna try to rebuild as Warner suggests... 
if I can locate the src.

Will




-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF


[-- Attachment #2: Type: text/html, Size: 1919 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [TUHS] 211bsd kermit working
  2020-08-10 13:12 Noel Chiappa
@ 2020-08-10 13:24 ` Will Senn
  0 siblings, 0 replies; 8+ messages in thread
From: Will Senn @ 2020-08-10 13:24 UTC (permalink / raw)
  To: Noel Chiappa, tuhs

On 8/10/20 8:12 AM, Noel Chiappa wrote:
>      > From: Will Senn
>
>      > $c
>      > 0177520: ~signal(016,01) from ~sysinit+034
>      > 0177542: ~sysinit() from ~main+010
>      > 0177560: _main() from start+0104
>
>      > If this means it got signal 16... or 1 from the sysinit call (called
>      > from main)
>
> I'm not sure that interpretation is correct. I think that trace shows signal()
> being called from sysinit().
>
> On V6, signal() was a system call which one could use to set the handlers for
> signals (or set them to be ignored, or back to the default action). In. 2.11
> it seems to be a shim layer which provides the same interface, but uses
> the Berserkly signal system interface underneath:
>
>    https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/include/signal.h
>    https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/man/cat3/signal.0
>
> So maybe the old binary for kermit is still trying to use the (perhaps
> now-removed) signal system call?
>
> 	     Noel
>

Noel,

That makes a lot more sense. I'm still trying to locate source.

Thanks,

Will


-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [TUHS] 211bsd kermit working
@ 2020-08-10 13:12 Noel Chiappa
  2020-08-10 13:24 ` Will Senn
  0 siblings, 1 reply; 8+ messages in thread
From: Noel Chiappa @ 2020-08-10 13:12 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Will Senn

    > $c
    > 0177520: ~signal(016,01) from ~sysinit+034
    > 0177542: ~sysinit() from ~main+010
    > 0177560: _main() from start+0104

    > If this means it got signal 16... or 1 from the sysinit call (called
    > from main)

I'm not sure that interpretation is correct. I think that trace shows signal()
being called from sysinit().

On V6, signal() was a system call which one could use to set the handlers for
signals (or set them to be ignored, or back to the default action). In. 2.11
it seems to be a shim layer which provides the same interface, but uses
the Berserkly signal system interface underneath:

  https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/include/signal.h
  https://www.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/man/cat3/signal.0

So maybe the old binary for kermit is still trying to use the (perhaps
now-removed) signal system call?

	     Noel


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2020-08-10 13:25 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-09 21:05 [TUHS] 211bsd kermit working Will Senn
2020-08-09 21:12 ` Clem Cole
2020-08-09 21:31   ` Will Senn
2020-08-10  0:53     ` Dave Horsfall
2020-08-10  1:42       ` Will Senn
2020-08-09 23:21 ` Warner Losh
2020-08-10 13:12 Noel Chiappa
2020-08-10 13:24 ` Will Senn

The Unix Heritage Society mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/tuhs

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 tuhs tuhs/ http://inbox.vuxu.org/tuhs \
		tuhs@minnie.tuhs.org
	public-inbox-index tuhs

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git