[9fans] ATA next

[9fans] ATA next

[Lucio De Re]

Forsyth's fixes gave me the #a that I was missing on my auth server.
Now I can run imap4d on the slowest, smallest server in my
office/network :-)  Something tells me either imap4d does not need
to run on an auth server (it _does_ change identity, doesn't it?)
or the auth server needs to be considerably more beefy than used
to be the case a few years ago (don't I recall comments to the
effect it could run on small 386?).

Sadly, the curse of the seeming ATA-originated linefeeds has struck
pretty seriously.  The screen does not take very long to get cleared
of all text.

Even more seriously (in my opinion) the IDE controller (ATA based,
as this host has no PCI at all) is not recognised as DMA capable,
so I get the dreaded:
	disabling dma: not on a busmastering controller
message.

I think jmk knows how to fix this.  To be honest, I don't use the
ATA drive except for /n/9fat, so it doesn't really matter, but it's
annoying and can no doubt be fixed, and it seems to be responsible
for a considerable increase in the rate at which spurious LFs are
fed to the console.  I'll see if I can find the source of those at
the same time.

++L

Re: [9fans] ATA next

[jmk]

On Thu Jan 22 09:24:40 EST 2004, lucio@proxima.alt.za wrote:
> ...
> Even more seriously (in my opinion) the IDE controller (ATA based,
> as this host has no PCI at all) is not recognised as DMA capable,
> so I get the dreaded:
> 	disabling dma: not on a busmastering controller
> message.
>
> I think jmk knows how to fix this.  ...

Remove the lines which enable DMA in whichever rc script is run at
boot, e.g. you might have something like

	for(disk in /dev/sd[C-F]*)
		echo dma on >$disk/ctl

in the cpurc for that system.

The code in sdata.c/atawctl() could perhaps be a little smarter and
not allow dmactl to be set if ctlr->prdt is nil, then at least you'd get
an error when you tried to set dma on, not later when you actually
tried some data transfers. Something like

	if(strcmp(cb->f[0], "dma") == 0){
		if(cb->nf != 2 || drive->dma == 0)
			error(Ebadctl);
		if(strcmp(cb->f[1], "on") == 0){
			ilock(ctlr);
			if(ctlr->prdt)
				drive->dmactl = drive->dma;
			else
				drive->dmactl = 0;
			iunlock(ctlr);
			if(drive->dmactl == 0)
				error("not on a busmastering controller\n");
		}
		else if(strcmp(cb->f[1], "off") == 0)
			drive->dmactl = 0;
		else
			error(Ebadctl);
	}

although I've just jotted this down and not actually tried it.

Re: [9fans] ATA next

[Lucio De Re]

On Thu, Jan 22, 2004 at 10:22:37AM -0500, jmk@plan9.bell-labs.com wrote:
>
> The code in sdata.c/atawctl() could perhaps be a little smarter and
> not allow dmactl to be set if ctlr->prdt is nil, then at least you'd get
> an error when you tried to set dma on, not later when you actually
> tried some data transfers. Something like
>
There didn't use to be a noticeable problem with the kernel dating
back a year or more ago.  I didn't put it to the test, but I always
assumed that DMA was permissible.  It's a recent-ish change that
seems to have (erroneously, I believe) detected that the disk/controller
is not DMA capable.  Is it not just an issue that DMA is (accidentally)
no longer supported on non-PCI systems?  Must I try another old
computer to check?

While on the subject of that particular host, it also seems to have
developed an affinity for (once I enabled the warning message):

	cpu0: spurious interrupt 39, last 0

which immediately precedes each of those annoying blank lines.  Since
the newer kernel these have become very frequent, the previous kernel
would have one or two blank lines in an hour, at a rough guess, now
they occur every few seconds.  The message is in "pc/trap.c".

Never having promoted myself from the 8088 which I knew really well, I
have no idea what would give rise to interrupt 39 (0x27 to save you
working it out), and in a new, extremely frequent number.

I suspect all IDE hosts do it to a greater or lesser degree and DMA
also seems to have a bearing.  But I'm none the wiser as to why.

++L

Re: [9fans] ATA next

[jmk]

On Thu Jan 22 13:20:42 EST 2004, lucio@proxima.alt.za wrote:
> On Thu, Jan 22, 2004 at 10:22:37AM -0500, jmk@plan9.bell-labs.com wrote:
> >
> > The code in sdata.c/atawctl() could perhaps be a little smarter and
> > not allow dmactl to be set if ctlr->prdt is nil, then at least you'd get
> > an error when you tried to set dma on, not later when you actually
> > tried some data transfers. Something like
> >
> There didn't use to be a noticeable problem with the kernel dating
> back a year or more ago.  I didn't put it to the test, but I always
> assumed that DMA was permissible.  It's a recent-ish change that
> seems to have (erroneously, I believe) detected that the disk/controller
> is not DMA capable.  Is it not just an issue that DMA is (accidentally)
> no longer supported on non-PCI systems?  Must I try another old
> computer to check?

You are just confused. The ATA driver has never done non-PCI dma on the PC.
If you looked at the comment in the driver where the 'disabling dma' was coming
from you'd see that it's the drive which is saying it can do DMA, even although
there is no hardware that the driver knows how to use to do it.

>
> While on the subject of that particular host, it also seems to have
> developed an affinity for (once I enabled the warning message):
>
> 	cpu0: spurious interrupt 39, last 0
>
> which immediately precedes each of those annoying blank lines.  Since
> the newer kernel these have become very frequent, the previous kernel
> would have one or two blank lines in an hour, at a rough guess, now
> they occur every few seconds.  The message is in "pc/trap.c".

Again, if you looked at the code you identified in trap.c you'd see that
someone attempted to disable the 'spurious interrupt' messages but left in
the final 'print("\n");'

>
> Never having promoted myself from the 8088 which I knew really well, I
> have no idea what would give rise to interrupt 39 (0x27 to save you
> working it out), and in a new, extremely frequent number.

On a uniprocessor machine using the i8259 interrupt controller, Plan 9
offsets the interrupt vectors by 32 ('VectorPIC' in io.h). So the IRQ (which
is what you are thinking is 39) is 7. For an explanantion I again refer you
to a comment in trap.c, just above the 'spurious interrupt' code.
>
> I suspect all IDE hosts do it to a greater or lesser degree and DMA
> also seems to have a bearing.  But I'm none the wiser as to why.
>
> ++L

Re: [9fans] ATA next

[Lucio De Re]

On Thu, Jan 22, 2004 at 02:13:38PM -0500, jmk@plan9.bell-labs.com wrote:
>
> You are just confused. The ATA driver has never done non-PCI dma on the PC.
> If you looked at the comment in the driver where the 'disabling dma' was coming
> from you'd see that it's the drive which is saying it can do DMA, even although
> there is no hardware that the driver knows how to use to do it.
>
I believe you _and_ the driver.  I had a kernel on the same hardware
that didn't complain about DMA settings (I still have the installation,
so I suppose I could prove it at least to myself) and that would
most likely be the source of the confusion.

> Again, if you looked at the code you identified in trap.c you'd see that
> someone attempted to disable the 'spurious interrupt' messages but left in
> the final 'print("\n");'
>
I did look.  There's a chunk of code in between that wasn't suppressed
and therefore I added a counter to make the NL go away if no
intervening printing took place:

	if(0)print("cpu%d: spurious interrupt %d, last %d",
		m->machno, vno, m->lastintr);
	for(i = 0; i < 32; i++){
		if(!(active.machs & (1<<i)))
			continue;
		mach = MACHP(i);
		if(m->machno == mach->machno)
			continue;
		print(": cpu%d: last %d", mach->machno, mach->lastintr);
		i0++;
	}
	if (i0)
		print("\n");
	m->spuriousintr++;

I couldn't quite convince myself to make the conditional "if (0 && i0)"
to match the "if (0)" at the beginning.

> On a uniprocessor machine using the i8259 interrupt controller, Plan 9
> offsets the interrupt vectors by 32 ('VectorPIC' in io.h). So the IRQ (which
> is what you are thinking is 39) is 7. For an explanantion I again refer you
> to a comment in trap.c, just above the 'spurious interrupt' code.
> >
I ought to have known that, but I didn't put two and two together.
Yes, the dreaded int 7 so many motherboards seem so keen to generate.
A "-32" in the message would go a long way to clarify things, even if
the message is not printed or even compiled in.

Would it not be possible to have a default, empty interceptor that
gets displaced by the real thing if ever required?

> > I suspect all IDE hosts do it to a greater or lesser degree and DMA
> > also seems to have a bearing.  But I'm none the wiser as to why.
> >
It all puts the lie to the above.  I must conclude that something
in the interrupt handling rather than in the ATA DMA code has
changed to cause so many more int 7s to occur.  I'm looking forward
to the day when these idiosyncracies will be nothing more than a
bad memory.  Thanks for the explanations.

++L

Re: [9fans] ATA next

[Charles Forsyth]

>>It all puts the lie to the above.  I must conclude that something
>>in the interrupt handling rather than in the ATA DMA code has
>>changed to cause so many more int 7s to occur.  I'm looking forward

i thought IRQ7 was generated when a device requested an interrupt
then incorrectly removed that irq signal before the cpu acknowledged it.
a quick google search seems to confirm that.
see http://www.geocrawler.com/archives/3/171/2000/5/0/3704984/
(ie, it's not the driver code as such that causes it, but the hardware.)

i wonder, though, whether it can happen if an interrupt
is configured as level-triggered in the controller or system
but is actually edge-triggered.  i didn't think there were level-triggered interrupts
on a system without PCI, but perhaps there are.
you might check your system's BIOS settings

Re: [9fans] ATA next

[Lucio De Re]

On Fri, Jan 23, 2004 at 09:11:31AM +0000, Charles Forsyth wrote:
>
> i thought IRQ7 was generated when a device requested an interrupt
> then incorrectly removed that irq signal before the cpu acknowledged it.
> a quick google search seems to confirm that.
> see http://www.geocrawler.com/archives/3/171/2000/5/0/3704984/
> (ie, it's not the driver code as such that causes it, but the hardware.)
>
Perfectly likely, I'll have a look at your suggested reading in a
moment.  Still, something must have triggered the increased frequency,
and only the kernel has changed.  I'm merely suggesting that there has
been some change in the interrupt handling.  I'm not curious enough to
run a different OS, what I ought to do, instead, would be to configure
PRN in the kernel. In fact, that may have been the case on the old
kernel.  But then I still wouldn't know why I was getting blank lines,
much more rarely, with the old kernel.  Since I patched trap.c, there
have been none.

> i wonder, though, whether it can happen if an interrupt
> is configured as level-triggered in the controller or system
> but is actually edge-triggered.  i didn't think there were level-triggered interrupts
> on a system without PCI, but perhaps there are.
> you might check your system's BIOS settings

I could :-)  It's a shame that some things are just too much bother to
pursue.  But if I get to reboot the machine, I certainly will remember
to do it.

++L

Re: [9fans] ATA next

[jmk]

On Fri Jan 23 04:12:42 EST 2004, forsyth@terzarima.net wrote:
> >>It all puts the lie to the above.  I must conclude that something
> >>in the interrupt handling rather than in the ATA DMA code has
> >>changed to cause so many more int 7s to occur.  I'm looking forward
>
> i thought IRQ7 was generated when a device requested an interrupt
> then incorrectly removed that irq signal before the cpu acknowledged it.
> a quick google search seems to confirm that.
> see http://www.geocrawler.com/archives/3/171/2000/5/0/3704984/
> (ie, it's not the driver code as such that causes it, but the hardware.)
>
> i wonder, though, whether it can happen if an interrupt
> is configured as level-triggered in the controller or system
> but is actually edge-triggered.  i didn't think there were level-triggered interrupts
> on a system without PCI, but perhaps there are.
> you might check your system's BIOS settings

if the driver has a loop in the interrupt routine:

	while(device has something new for me to do)
		do it

then, in the case of edge-triggered interrupts, the interrupt
routine can cause the reason for a 2nd interrupt to go away after
it has been received by the i8259. in this case the 8259 will
immediately interrupt the cpu again after the first interrupt has
returned, only to find it hasn't got the info about where the
interrupt came from. so it jumps up and says '7' (or '15' if it's
the 2nd i8259).

that's what i understood.
sometimes the interrupt routine can/should be rewritten to make
the problem go away, but edge-triggered interrupts just gulp buckets.

Re: [9fans] ATA next

[C H Forsyth]

yes, i see.

Re: [9fans] ATA next

[David Presotto]

On Thu Jan 22 09:24:50 EST 2004, lucio@proxima.alt.za wrote:
> Now I can run imap4d on the slowest, smallest server in my
> office/network :-)  Something tells me either imap4d does not need
> to run on an auth server (it _does_ change identity, doesn't it?)
> or the auth server needs to be considerably more beefy than used
> to be the case a few years ago (don't I recall comments to the
> effect it could run on small 386?).

There's no reason why imapd should run on an auth server.
Lots of services change id (cpu, rx, ssh, ...).

Our auth server has gotten a lot bigger though it doesn't have to be;
we just had some 700 MH zeon's lying around when we needed a bigger
machine..

We use the same machine as an auth server, console server,
and dhcp/bootp/tftp server.  Its basicly the stand alone server that
we use to get the rest of the system up after power failures or
file server reboots.

Re: [9fans] ATA next

[Lucio De Re]

On Thu, Jan 22, 2004 at 10:53:26AM -0500, David Presotto wrote:
>
> There's no reason why imapd should run on an auth server.
> Lots of services change id (cpu, rx, ssh, ...).
>
Please pardon me, I'm being lazy, now.  What I could probably figure
out by reading enough man pages and code is (a) why then the TLS
imap4d service is in /rc/bin/service.auth, implying that as a
trusted service it ought to run only on an auth service (there's
a clear indication that that is expected in the cpurc text) and
(b) does imap4d not need to be able to "speak for" the new user,
which is easiest achieved on an auth server?

Assume I still don't quite grasp all the complexities of Plan 9
authentication, it is just too subtle.  I have checked what I
thought was pertinent, but I kept missing something indefinite.

Lastly, and again I assume I could figure this by myself, but a
superficial search led me to believe that there's someone out there
who can explain it a little better, what are the preconditions for
imap4d to operate correctly under TLS?  According to the documentation
the certificate is generated on the fly by /rc/bin/service.auth/tcp993,
but I'm not altogether convinced :-(  The directory /sys/lib/ssl
in which a cert may be stored certainly did not exist before I
created it.  It has remained empty since :-(

Thanks to anyone who can shed some light on this.

++L

Re: [9fans] ATA next

[David Presotto]

> Please pardon me, I'm being lazy, now.  What I could probably figure
> out by reading enough man pages and code is (a) why then the TLS
> imap4d service is in /rc/bin/service.auth, implying that as a
> trusted service it ought to run only on an auth service (there's
> a clear indication that that is expected in the cpurc text) and

Looks like sources doesn't reflect what we do here.  We moved that
cruft out of /rc/bin/service.auth a while ago.

It used to be in service.auth because it needed to get at the TLS
private key.  We fixed that.

I'll fix sources.

> (b) does imap4d not need to be able to "speak for" the new user,
> which is easiest achieved on an auth server?

It's easiest achieved by the user login in which just goes via
factotum.  Factotum talks to the auth server but it doesn't matter
whether the auth server is local or remote.

Re: [9fans] imap4d operation (Was: ATA next)

[Lucio De Re]

On Thu, Jan 22, 2004 at 02:53:15PM -0500, David Presotto wrote:
>
> I'll fix sources.
>
Thank you.  There doesn't seem to be a short circuit to figuring
these things out other than study and questioning, unfortunately.

> > (b) does imap4d not need to be able to "speak for" the new user,
> > which is easiest achieved on an auth server?
>
> It's easiest achieved by the user login in which just goes via
> factotum.  Factotum talks to the auth server but it doesn't matter
> whether the auth server is local or remote.

Factotum has certainly made a huge difference.  I'm going to have
to think this one through, because the picture that's beginning to
form in my head will no doubt need some touching up :-)

Just as a data point, "cron" would not be able to do the same
without at least some major adjustments, would it?

I do note that one tends to think of factotum conversing with the
authenticator, whereas the conversation in fact takes place _through_
the client or server.

++L

Re: [9fans] imap4d operation (Was: ATA next)

[David Presotto]

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

cron does exactly the same thing.  it no longer has to run on the auth
server.  it just has to run on a cpu server whose host owner can
speak for anyone.  That's the relation that's in /lib/ndb/auth
on the auth server.

[-- Attachment #2: Type: message/rfc822, Size: 3466 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] imap4d operation (Was: ATA next)
Date: Fri, 23 Jan 2004 07:55:35 +0200
Message-ID: <20040123075534.H28365@cackle.proxima.alt.za>

On Thu, Jan 22, 2004 at 02:53:15PM -0500, David Presotto wrote:
>
> I'll fix sources.
>
Thank you.  There doesn't seem to be a short circuit to figuring
these things out other than study and questioning, unfortunately.

> > (b) does imap4d not need to be able to "speak for" the new user,
> > which is easiest achieved on an auth server?
>
> It's easiest achieved by the user login in which just goes via
> factotum.  Factotum talks to the auth server but it doesn't matter
> whether the auth server is local or remote.

Factotum has certainly made a huge difference.  I'm going to have
to think this one through, because the picture that's beginning to
form in my head will no doubt need some touching up :-)

Just as a data point, "cron" would not be able to do the same
without at least some major adjustments, would it?

I do note that one tends to think of factotum conversing with the
authenticator, whereas the conversation in fact takes place _through_
the client or server.

++L

Re: [9fans] ATA next

[David Presotto]

> Lastly, and again I assume I could figure this by myself, but a
> superficial search led me to believe that there's someone out there
> who can explain it a little better, what are the preconditions for
> imap4d to operate correctly under TLS?  According to the documentation
> the certificate is generated on the fly by /rc/bin/service.auth/tcp993,
> but I'm not altogether convinced :-(  The directory /sys/lib/ssl
> in which a cert may be stored certainly did not exist before I
> created it.  It has remained empty since :-(

This is assuming you are going to use TLS imap4d.

(1) The factotum that the imap4d runs on needs the private/public key that
TLS will use.  For example, ours is:

key proto=rsa service=tls owner=* size=1024 ek=10001 n=E4D13B3CF62A29157E816E05E5BC42DB4A93DBAB9AB1D77564A2EB2382503C0F2EB3B217E21FF91A258A4F6A9E4A44A9D2B6A344D8CB7049A0F95D501E3FC826F3D3161D6987AEA5028ECD6ED15268B94E358696092E540560C5978C5B49349DF521A4148D023EE67BCA7319F550A18B510EEC12ADE97ED2132134E5A264EA7D !dk? !p? !q? !kp? !k

We just store it in our secstore and get it whenever we boot.  Look at the
example at the end of rsa(8).  It tells you how to generate it.

(2) That machine must also have access to the certificate that goes with that key. For
example.  /rc/bin/service/tcp993 expects to find that in /sys/lib/ssl/cert.pem.

Once again rsa(8) tells you how to do it.

(3) Any user that wants to use imap4d needs to have an apop secret.  Its
not just for apop...  You can create them by running auth/changeuser on
the auth server:

auth/changeuser presotto
assign new password? [y/n]: n
assign Inferno/POP secret? (y/n) y
Secret(0 to 256 characters):
Confirm:
...

(4) Each of these users needs a mailbox.  You can create a mailbox by logging on
and running 'mail -c':

(5) The machine running imap4d needs to know where an auth server is running.  This
can be done by getting that on boot via dhcpd, by pugging it into your
plan9.ini ...

Re: [9fans] ATA next

[Lucio De Re]

On Thu, Jan 22, 2004 at 03:10:16PM -0500, David Presotto wrote:
>
> We just store it in our secstore and get it whenever we boot.  Look at the
> example at the end of rsa(8).  It tells you how to generate it.
>
How do you get to it?  Or, putting it another way, how do you
specify to the secstore what password to use to access it?  Specially
on a CPU server?  Is there a bypass from nvram to secstore?  There
has to be one from nvram to factotum which I wish I understood
better, so perhaps I must just search a little harder.

I think I have a good grip on the rest, thank you.

++L

Re: [9fans] ATA next

[Lucio De Re]

On Fri, Jan 23, 2004 at 09:11:36AM +0200, Lucio De Re wrote:
>
> I think I have a good grip on the rest, thank you.
           ^ now

++L

Re: [9fans] ATA next

[David Presotto]

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

The cpu server prompts you for a secstore password when it comes up if
you haven't stored one in the nvram-like disk or floppy partition.
It will store it in that partition after you specify it.

[-- Attachment #2: Type: message/rfc822, Size: 3027 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ATA next
Date: Fri, 23 Jan 2004 09:11:36 +0200
Message-ID: <20040123091135.I28365@cackle.proxima.alt.za>

On Thu, Jan 22, 2004 at 03:10:16PM -0500, David Presotto wrote:
>
> We just store it in our secstore and get it whenever we boot.  Look at the
> example at the end of rsa(8).  It tells you how to generate it.
>
How do you get to it?  Or, putting it another way, how do you
specify to the secstore what password to use to access it?  Specially
on a CPU server?  Is there a bypass from nvram to secstore?  There
has to be one from nvram to factotum which I wish I understood
better, so perhaps I must just search a little harder.

I think I have a good grip on the rest, thank you.

++L