Re: 2.4.17 & kbdrate

[Reinhard N. <rn...@gm...>]

Hi,

Geert Uytterhoeven wrote:
> 
> On Thu, 21 Mar 2002, Reinhard Nissl wrote:
> > Geert Uytterhoeven wrote:
> > > On Sun, 17 Mar 2002, Reinhard Nissl wrote:
> > > > has anyone an idea, why "kbdrate" crashes?
> > > >
> > > > My config:
> > > > SuSE Linux PPC 7.1
> > > > 2.4.17 (cvs) kernel
> > > >
> > > > BTW: "kbdrate" doesn't crash with a good old 2.2.10 kernel.
> > >
> > > > Oops: kernel access of bad area, sig: 11
> > > > NIP: C00989F0 XER: 00000000 LR: C0035E7C SP: C2DFFF20 REGS: c2dffe70 TRAP: 0300    Not tainted
> > >        ^^^^^^^^
> >
> > read_port
> 
> APUS doesn't have the I/O ports of the PC keyboard controller.

But it's possible to open /dev/port. Would it be ok to disable this device on
APUS, m68k, etc.?

On the other hand: what's wrong in seeking beyond EOF?
 
> > > > MSR: 00009072 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> > > > DAR: 00000064, DSISR: 40000000
> > > > TASK = c2dfe000[66] 'kbdrate' Last syscall: 3
> > > > last math c2dfe000 last altivec 00000000
> > > > GPR00: 0000FFFF C2DFFF20 C2DFE000 7FFFFD28 7FFFFD28 00000000 C01DBE40 00000000
> > > > GPR08: 00000064 00000000 C0035DB4 00000064 40000022 01819210 00000000 00000000
> > > > GPR16: 00000000 00000000 00000000 00000000 00009072 0ADFFF40 00000000 C00040B4
> > > > GPR24: C0003E20 01800E90 30028FCC 017EA65C 7FFFFD28 00000001 FFFFFFEA C01DBE20
> > > > Call backtrace:
> > > > C0035C60 C0003E7C 01800B2C 016DBA08 00000000
> > >   ^^^^^^^^ ^^^^^^^^ ^^^^^^^^ ^^^^^^^^
> >
> > sys_lseek, ret_from_syscall_1
> >
> > > Not without you looking up the marked addresses using your System.map.
> >
> > I've successfully looked up 3 of the 5 addresses. The remaining 2 seem to be
> > "user land" (kbdrate).
> >
> > It seems, that one (e. g. the first) of the lseek() calls in kbdrate.c
> > (attached) trigger the problem.
> 
> Kbdrate should use the ioctls on m68k and APUS, because Amigas don't have PC
> keyboard controllers.
> 
> Probably the ioctls are disabled in the kernel, or in the kbdrate.c program.

The same kbdrate binary works properly with a 2.2.10 kernel, so it must be a
kernel issue. drivers/char/vt.c contains a case statement with the constant
KDKBDREP, that kbdrate.c uses too, but I don't see any #ifdef/#endif
statements, that would exclude this case statement.

I'll try some printk's soon.

Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rn...@gm...