linux-apus-devel

Re: 2.4.18 running and interrupt Q

[Roman Z. <zi...@li...>]

Hi,

Ken Tyler wrote:

> I have a kludgey addition to amiga7xx to flush outstanding interrupts
> before the driver is initialized, can this go now ?

What patch? Did you try without it?

bye, Roman

2.4.18 running and interrupt Q

[Ken T. <ke...@we...>]

hello,

Thanks for doing the 2.4.18 update.

Compiled (with a few warnings) and running here.

The announcement of 2.4.18 update mentioned delaying interrupt enabling.

The amiga7xx / 53c7xx A4091 SCSI driver occasionally stops the boot
process due to outstanding interrupts from the card.

I have a kludgey addition to amiga7xx to flush outstanding interrupts
before the driver is initialized, can this go now ?

(it was a part of the APUS cvs once but got lost somewhere)

Ken.

Re: 2.4.18

[Roman Z. <zi...@li...>]

Hi,

Ondrej Zima wrote:

> > Please test it, a precompiled kernel can be found at
> > http://linux-apus.sf.net/snapshots/.
> 
> I try this kernel, but anly i get a

Damn, could you try this kernel:
http://linux-apus.sf.net/snapshots/vmlinux-2.4.18-dbg.gz
It adds quite a lot of debug output, could you send me the output
(privately)?
Thanks.

bye, Roman

Re: 2.4.18

[<du...@ds...>]

On Tue, 26 Mar 2002, Ondrej Zima wrote:

> On Sat, 23 Mar 2002, Roman Zippel wrote:
>
> > Hi,
> >
> > I finally updated cvs to 2.4.18. I also committed a patch which should
> > fix the boot problems. It's only a workaround, but it should avoid the
> > deadly situations.
> > Please test it, a precompiled kernel can be found at
> > http://linux-apus.sf.net/snapshots/.
>
> I try this kernel, but anly i get a
>
> last_ipl[2] alredy set to 2f, now 2d!
> 4796: 2 -2 2 -2 2 -2 2 -2 2 -2 2 -2 2 3 -3 2
> last_ipl[2] alredy set to 2f, now 2d!
> 4799: -2 2 -2 2 -2 2 -2 2 -2 2 3 -3 2 3 -3 2
>
> after IDE initializing... :(

I have the same message, but after few seconds
kernel continues booting and all is ok :)

dus

Re: 2.4.17 & kbdrate

[Geert U. <ge...@li...>]

On Tue, 26 Mar 2002, Reinhard Nissl wrote:
> Reinhard Nissl wrote:
> > I'm confused now, after doing some tests.
> > 
> > The kbdrate binary from the distribution works with 2.2.10 und crashes with
> > 2.4.18 while accessing /dev/ports.
> 
> I've investigated this further with strace. kbdrate does an ioctl() call. In
> 2.2.10, the call returns 0 and kbdrate exits. In 2.4.18, the call returns
> EINVAL and kbdrate tries to set the rate via /dev/ports, with fails on APUS.
> 
> Looking at drivers/char/vt.c, I found that the ioctl() handler for KDKBDREP
> calls kbd_rate(). kbd_rate is a function pointer which initially points to
> _kbd_rate() and this is an empty implementation which simply returns EINVAL.
> 
> Digging around further, I found a function amiga_kbdrate(), which has the same
> declaration as _kbd_rate(). There is also a function pointer mach_kbdrate that
> is similar to kbd_rate, and amiga_kbdrate gets assigned to it in
> arch/ppc/amiga/config.c. But I didn't find any location, that calls
> mach_kbdrate().
> 
> To make kbdrate work, I assume kbd_rate should be assigned the value of
> mach_kbdrate. (Where would an appropriate locaten be for this assignment?)
> 
> A different solution would be, to drop mach_kbdrate and substitute it with
> kbd_rate. This would then be similar to kd_mksound.
> 
> kd_mksound is also a function pointer, that is assigned a dummy implementation
> in drivers/char/vt.c. In arch/ppc/amiga/config.c, kd_mksound is overwritten
> with amiga_mksound.
> 
> I would like to substitute mach_kbdrate with kdb_rate for all the archs that
> use it. What are your comments about doing so?

I think the best solution is to kill mach_kbdrate and initialize _kbd_rate to
amiga_kbdrate in amiga_keyb_init(), cfr. pc_keyb.c.

The same is true for atari_kbdrate, bvme6000_kbdrate, hp300_kbdrate,
mvme147_kbdrate, mvme16x_kbdrate, and sun3x_kbdrate. And dn_dummy_kbdrate() can
die as well.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: 2.4.17 & kbdrate

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

Hi,

Reinhard Nissl wrote:
> 
> Hi,
> 
> I'm confused now, after doing some tests.
> 
> The kbdrate binary from the distribution works with 2.2.10 und crashes with
> 2.4.18 while accessing /dev/ports.

I've investigated this further with strace. kbdrate does an ioctl() call. In
2.2.10, the call returns 0 and kbdrate exits. In 2.4.18, the call returns
EINVAL and kbdrate tries to set the rate via /dev/ports, with fails on APUS.

Looking at drivers/char/vt.c, I found that the ioctl() handler for KDKBDREP
calls kbd_rate(). kbd_rate is a function pointer which initially points to
_kbd_rate() and this is an empty implementation which simply returns EINVAL.

Digging around further, I found a function amiga_kbdrate(), which has the same
declaration as _kbd_rate(). There is also a function pointer mach_kbdrate that
is similar to kbd_rate, and amiga_kbdrate gets assigned to it in
arch/ppc/amiga/config.c. But I didn't find any location, that calls
mach_kbdrate().

To make kbdrate work, I assume kbd_rate should be assigned the value of
mach_kbdrate. (Where would an appropriate locaten be for this assignment?)

A different solution would be, to drop mach_kbdrate and substitute it with
kbd_rate. This would then be similar to kd_mksound.

kd_mksound is also a function pointer, that is assigned a dummy implementation
in drivers/char/vt.c. In arch/ppc/amiga/config.c, kd_mksound is overwritten
with amiga_mksound.

I would like to substitute mach_kbdrate with kdb_rate for all the archs that
use it. What are your comments about doing so?

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

Re: 2.4.18

[Ondrej Z. <oz...@ch...>]

On Sat, 23 Mar 2002, Roman Zippel wrote:

> Hi,
>
> I finally updated cvs to 2.4.18. I also committed a patch which should
> fix the boot problems. It's only a workaround, but it should avoid the
> deadly situations.
> Please test it, a precompiled kernel can be found at
> http://linux-apus.sf.net/snapshots/.

I try this kernel, but anly i get a

last_ipl[2] alredy set to 2f, now 2d!
4796: 2 -2 2 -2 2 -2 2 -2 2 -2 2 -2 2 3 -3 2
last_ipl[2] alredy set to 2f, now 2d!
4799: -2 2 -2 2 -2 2 -2 2 -2 2 3 -3 2 3 -3 2

after IDE initializing... :(

-- 
   Ondrej "AndreW" Zima
   Memeber of Czech ATO
http://ato.vapor.com/czech

Re: 2.4.17 & kbdrate

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

Hi,

Geert Uytterhoeven wrote:
> 
> On Fri, 22 Mar 2002, Reinhard Nissl wrote:
> > Geert Uytterhoeven wrote:
> > > On Fri, 22 Mar 2002, Reinhard Nissl wrote:
> > > > Geert Uytterhoeven wrote:
> > > > > On Fri, 22 Mar 2002, Reinhard Nissl wrote:
> > > > > > On the other hand: what's wrong in seeking beyond EOF?
> > > > >
> > > > > Sorry, I don't understand what you mean here.
> > > >
> > > >       fd = open( "/dev/port", O_RDWR )
> > > >       lseek( fd, 0x64, 0 );
> > > >
> > > > The call to open() succeeds, as there exists /dev/port. Why doesn't lseek()
> > > > simply return an error value instead of causing a signal 11?
> > >
> > > I don't think it causes signal 11 in the lseek, but in the read/write phase.
> >
> > Going back some mails ago, there is:
> >
> > > > > Call backtrace:
> > > > > C0035C60 C0003E7C 01800B2C 016DBA08 00000000
> > > >   ^^^^^^^^ ^^^^^^^^ ^^^^^^^^ ^^^^^^^^
> > >
> > > sys_lseek, ret_from_syscall_1
> >
> > So, sys_lseek calls read_port and causes a signal 11.
> 
> Strange, from looking at the sources, I don't see how sys_lseek() can cause
> read_port() to be called.

You are right, strace comes to the same conclusion. sys_lseek() is ok,
read_port() fails.

How is it, that the "call backtrace" shows the last call?

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

2.4.18 & XF4.2.0

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

Hi,

my system isn't very stable, when X is running. Especially after going to XF
4.2.0, the system is almost dead, when switching VTs or stopping the X server.

I assume, that I've misconfigured something, maybe trying to much
expermimental stuff.

Would someone please send me a kernel config file and a XF86Config file of its
stable running system that uses a CSPPC and CVPPC?

Thanks in advance.

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

Re: 2.4.17 & kbdrate

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

Hi,

I'm confused now, after doing some tests.

The kbdrate binary from the distribution works with 2.2.10 und crashes with
2.4.18 while accessing /dev/ports.

My binary, built from the distribution sources, crashes with 2.4.18 while
doing the ioctl() call for m68k like systems (KDKBDREP). (Haven't tried 2.2.10
with my binary so far).

Is there an easy way to get more information then just "segmentation fault"?

I'll run it with gdb soon.

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

Re: 2.4.17 & kbdrate

[Geert U. <ge...@li...>]

On Fri, 22 Mar 2002, Reinhard Nissl wrote:
> Geert Uytterhoeven wrote:
> > On Fri, 22 Mar 2002, Reinhard Nissl wrote:
> > > Geert Uytterhoeven wrote:
> > > > On Fri, 22 Mar 2002, Reinhard Nissl wrote:
> > > > > On the other hand: what's wrong in seeking beyond EOF?
> > > >
> > > > Sorry, I don't understand what you mean here.
> > >
> > >       fd = open( "/dev/port", O_RDWR )
> > >       lseek( fd, 0x64, 0 );
> > >
> > > The call to open() succeeds, as there exists /dev/port. Why doesn't lseek()
> > > simply return an error value instead of causing a signal 11?
> > 
> > I don't think it causes signal 11 in the lseek, but in the read/write phase.
> 
> Going back some mails ago, there is:
> 
> > > > Call backtrace:
> > > > C0035C60 C0003E7C 01800B2C 016DBA08 00000000
> > >   ^^^^^^^^ ^^^^^^^^ ^^^^^^^^ ^^^^^^^^
> > 
> > sys_lseek, ret_from_syscall_1
> 
> So, sys_lseek calls read_port and causes a signal 11.

Strange, from looking at the sources, I don't see how sys_lseek() can cause
read_port() to be called.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

2.4.18

[Roman Z. <zi...@li...>]

Hi,

I finally updated cvs to 2.4.18. I also committed a patch which should
fix the boot problems. It's only a workaround, but it should avoid the
deadly situations.
Please test it, a precompiled kernel can be found at
http://linux-apus.sf.net/snapshots/.

bye, Roman

CVS Update: 2.3 (branch: trunk)

[Roman Z. <zi...@us...>]

CVSROOT:	/cvsroot/linux-apus
Module name:	2.3
Repository:	2.3/arch/ppc/amiga/
Changes by:	zippel@usw-pr-cvs1.	02/03/22 17:48:49

Log message:
  disable interrupts in the custom chip to avoid early spurious interrupts

Modified files:
      2.3/arch/ppc/amiga/:
        amiints.c cia.c 
  
  Revision      Changes    Path
  1.9           +45 -43    2.3/arch/ppc/amiga/amiints.c
  1.5           +5 -0      2.3/arch/ppc/amiga/cia.c

CVS Update: 2.3 (branch: trunk)

[Roman Z. <zi...@us...>]

CVSROOT:	/cvsroot/linux-apus
Module name:	2.3
Repository:	2.3/arch/ppc/
Changes by:	zippel@usw-pr-cvs1.	02/03/22 17:32:47

Log message:
  update defconfig

Modified files:
      2.3/arch/ppc/configs/:
        apus_defconfig 
      2.3/arch/ppc/:
        defconfig 
  
  Revision      Changes    Path
  1.17          +21 -137   2.3/arch/ppc/configs/apus_defconfig
  1.22          +17 -132   2.3/arch/ppc/defconfig

CVS Update: 2.3 (branch: trunk)

[Roman Z. <zi...@us...>]

CVSROOT:	/cvsroot/linux-apus
Module name:	2.3
Repository:	2.3/mm/
Changes by:	zippel@usw-pr-cvs1.	02/03/22 13:31:37

Log message:
  conflict fixes from import bitkeeper (2.4.18)

Modified files:
      ./:
        Makefile 
      2.3/Documentation/:
        Configure.help 
      2.3/arch/ppc/:
        config.in 
      2.3/arch/ppc/kernel/:
        head.S irq.c ppc_ksyms.c setup.c time.c 
      2.3/arch/ppc/mm/:
        init.c mmu_decl.h pgtable.c ppc_mmu.c 
      2.3/drivers/char/:
        Config.in Makefile 
      2.3/drivers/net/:
        Makefile 
      2.3/drivers/parport/:
        share.c 
      2.3/drivers/scsi/:
        Makefile 
      2.3/drivers/video/:
        Config.in fbmem.c 
      2.3/include/asm-ppc/:
        pgtable.h 
      2.3/mm/:
        page_alloc.c 
Removed files:
      2.3/arch/ppc/boot/common/:
        no_initrd.c 
      2.3/arch/ppc/boot/mbx/:
        Makefile embed_config.c gzimage.c head.S head_8260.S 
        iic.c m8260_tty.c m8xx_tty.c misc.c pci.c qspan_pci.c 
        rdimage.c 
      2.3/arch/ppc/boot/pmac/:
        dummy.c ld.script 
      2.3/arch/ppc/boot/tree/:
        Makefile irSect.c irSect.h ld.script main.c misc.S 
      2.3/arch/ppc/boot/utils/:
        mkevimg mkirimg mksimage.c offset piggyback.c sioffset 
        sisize size 
      2.3/drivers/sound/cs4281/:
        cs4281_wrapper-24.c 
      2.3/include/asm-s390/:
        s390-gdbregs.h 
      2.3/include/asm-s390x/:
        s390-gdbregs.h 
  
  Revision      Changes    Path
  1.33          +13 -10    2.3/Makefile
  1.23          +242 -94   2.3/Documentation/Configure.help
  1.32          +5 -1      2.3/arch/ppc/config.in
  1.27          +1 -1      2.3/arch/ppc/kernel/head.S
  1.15          +1 -1      2.3/arch/ppc/kernel/irq.c
  1.31          +2 -1      2.3/arch/ppc/kernel/ppc_ksyms.c
  1.24          +3 -3      2.3/arch/ppc/kernel/setup.c
  1.18          +1 -3      2.3/arch/ppc/kernel/time.c
  1.26          +5 -14     2.3/arch/ppc/mm/init.c
  1.4           +2 -1      2.3/arch/ppc/mm/mmu_decl.h
  1.5           +73 -5     2.3/arch/ppc/mm/pgtable.c
  1.4           +6 -27     2.3/arch/ppc/mm/ppc_mmu.c
  1.7           +12 -1     2.3/drivers/char/Config.in
  1.20          +3 -2      2.3/drivers/char/Makefile
  1.13          +12 -12    2.3/drivers/net/Makefile
  1.5           +6 -2      2.3/drivers/parport/share.c
  1.9           +1 -1      2.3/drivers/scsi/Makefile
  1.8           +3 -2      2.3/drivers/video/Config.in
  1.14          +6 -0      2.3/drivers/video/fbmem.c
  1.15          +2 -11     2.3/include/asm-ppc/pgtable.h
  1.22          +6 -9      2.3/mm/page_alloc.c

CVS Update: 2.3 (branch: )

[Roman Z. <zi...@us...>]

CVSROOT:	/cvsroot/linux-apus
Module name:	2.3
Repository:	./
Changes by:	zippel@usw-pr-cvs1.	02/03/22 12:43:00

2.3

In directory usw-pr-cvs1:/tmp/cvs-serv20874

Log Message:
import bitkeeper (2.4.18)

Status:

Vendor Tag:	torvalds
Release Tags:	bk_20020225
		
C 2.3/Makefile
C 2.3/arch/ppc/config.in
N 2.3/arch/ppc/boot/ld.script
N 2.3/arch/ppc/boot/simple/embed_config.c
N 2.3/arch/ppc/boot/simple/m8xx_tty.c
N 2.3/arch/ppc/boot/simple/Makefile
N 2.3/arch/ppc/boot/simple/m8260_tty.c
N 2.3/arch/ppc/boot/simple/legacy.S
N 2.3/arch/ppc/boot/simple/iic.c
N 2.3/arch/ppc/boot/simple/misc-embedded.c
N 2.3/arch/ppc/boot/simple/head.S
N 2.3/arch/ppc/boot/simple/direct.S
N 2.3/arch/ppc/boot/utils/mktree.c
N 2.3/arch/ppc/boot/utils/mkimage.wrapper
N 2.3/arch/ppc/boot/common/util.S
N 2.3/arch/ppc/boot/common/dummy.c
N 2.3/arch/ppc/boot/common/relocate.S
C 2.3/arch/ppc/kernel/time.c
C 2.3/arch/ppc/kernel/setup.c
C 2.3/arch/ppc/kernel/irq.c
C 2.3/arch/ppc/kernel/ppc_ksyms.c
C 2.3/arch/ppc/kernel/head.S
C 2.3/arch/ppc/mm/mmu_decl.h
C 2.3/arch/ppc/mm/init.c
C 2.3/arch/ppc/mm/ppc_mmu.c
C 2.3/arch/ppc/mm/pgtable.c
N 2.3/drivers/sound/cs4281/cs4281pm-24.h
N 2.3/drivers/sound/cs4281/cs4281_wrapper.h
C 2.3/drivers/sound/dmasound/dmasound_core.c
N 2.3/drivers/usb/stv680.h
N 2.3/drivers/usb/vicam.c
N 2.3/drivers/usb/stv680.c
N 2.3/drivers/usb/vicamurbs.h
N 2.3/drivers/usb/vicam.h
N 2.3/drivers/usb/serial/ipaq.h
N 2.3/drivers/usb/serial/ipaq.c
N 2.3/drivers/usb/serial/kl5kusb105.c
N 2.3/drivers/usb/serial/kl5kusb105.h
C 2.3/drivers/net/Makefile
N 2.3/drivers/net/mii.c
C 2.3/drivers/char/Config.in
C 2.3/drivers/char/Makefile
N 2.3/drivers/char/drm-4.0/i810_drm.h
N 2.3/drivers/char/drm-4.0/tdfx_drv.h
N 2.3/drivers/char/drm-4.0/auth.c
N 2.3/drivers/char/drm-4.0/mga_state.c
N 2.3/drivers/char/drm-4.0/mga_context.c
N 2.3/drivers/char/drm-4.0/i810_dma.c
N 2.3/drivers/char/drm-4.0/radeon_bufs.c
N 2.3/drivers/char/drm-4.0/mga_dma.c
N 2.3/drivers/char/drm-4.0/ioctl.c
N 2.3/drivers/char/drm-4.0/i810_context.c
N 2.3/drivers/char/drm-4.0/dma.c
N 2.3/drivers/char/drm-4.0/mga_drm.h
N 2.3/drivers/char/drm-4.0/proc.c
N 2.3/drivers/char/drm-4.0/Makefile
N 2.3/drivers/char/drm-4.0/README.drm
N 2.3/drivers/char/drm-4.0/ffb_drv.c
N 2.3/drivers/char/drm-4.0/gamma_drv.c
N 2.3/drivers/char/drm-4.0/r128_state.c
N 2.3/drivers/char/drm-4.0/fops.c
N 2.3/drivers/char/drm-4.0/r128_drv.h
N 2.3/drivers/char/drm-4.0/radeon_drv.c
N 2.3/drivers/char/drm-4.0/tdfx_drv.c
N 2.3/drivers/char/drm-4.0/ffb_drv.h
N 2.3/drivers/char/drm-4.0/gamma_dma.c
N 2.3/drivers/char/drm-4.0/mga_bufs.c
N 2.3/drivers/char/drm-4.0/r128_cce.c
N 2.3/drivers/char/drm-4.0/agpsupport.c
N 2.3/drivers/char/drm-4.0/vm.c
N 2.3/drivers/char/drm-4.0/memory.c
N 2.3/drivers/char/drm-4.0/radeon_cp.c
N 2.3/drivers/char/drm-4.0/bufs.c
N 2.3/drivers/char/drm-4.0/lock.c
N 2.3/drivers/char/drm-4.0/radeon_context.c
N 2.3/drivers/char/drm-4.0/r128_drm.h
N 2.3/drivers/char/drm-4.0/i810_bufs.c
N 2.3/drivers/char/drm-4.0/i810_drv.h
N 2.3/drivers/char/drm-4.0/radeon_drm.h
N 2.3/drivers/char/drm-4.0/Config.in
N 2.3/drivers/char/drm-4.0/mga_drv.h
N 2.3/drivers/char/drm-4.0/r128_context.c
N 2.3/drivers/char/drm-4.0/ctxbitmap.c
N 2.3/drivers/char/drm-4.0/r128_drv.c
N 2.3/drivers/char/drm-4.0/radeon_state.c
N 2.3/drivers/char/drm-4.0/drmP.h
N 2.3/drivers/char/drm-4.0/gamma_drv.h
N 2.3/drivers/char/drm-4.0/drm.h
N 2.3/drivers/char/drm-4.0/r128_bufs.c
N 2.3/drivers/char/drm-4.0/context.c
N 2.3/drivers/char/drm-4.0/mga_drv.c
N 2.3/drivers/char/drm-4.0/lists.c
N 2.3/drivers/char/drm-4.0/radeon_drv.h
N 2.3/drivers/char/drm-4.0/i810_drv.c
N 2.3/drivers/char/drm-4.0/tdfx_context.c
N 2.3/drivers/char/drm-4.0/ffb_context.c
N 2.3/drivers/char/drm-4.0/drawable.c
N 2.3/drivers/char/drm-4.0/init.c
N 2.3/drivers/video/tridentfb.h
C 2.3/drivers/video/Config.in
N 2.3/drivers/video/tridentfb.c
C 2.3/drivers/video/fbmem.c
N 2.3/drivers/s390/sysinfo.c
C 2.3/drivers/scsi/Makefile
C 2.3/drivers/parport/share.c
N 2.3/net/ipv4/netfilter/ipt_ah.c
N 2.3/net/ipv4/netfilter/ipt_esp.c
N 2.3/net/ipv4/netfilter/ipt_ULOG.c
N 2.3/net/ipv6/netfilter/ip6_queue.c
N 2.3/fs/nls/nls_cp1250.c
N 2.3/fs/freevxfs/vxfs_kcompat.h
C 2.3/Documentation/Configure.help
N 2.3/Documentation/usb/stv680.txt
N 2.3/Documentation/fb/tridentfb.txt
N 2.3/include/linux/stringify.h
N 2.3/include/linux/netfilter_ipv4/ipt_esp.h
N 2.3/include/linux/netfilter_ipv4/ipt_ULOG.h
N 2.3/include/linux/netfilter_ipv4/ipt_ah.h
C 2.3/include/asm-ppc/pgtable.h
N 2.3/include/asm-cris/ethernet.h
C 2.3/mm/page_alloc.c

22 conflicts created by this import.

	cvs checkout -jtorvalds:yesterday -jtorvalds 2.3

Re: 2.4.17 & kbdrate

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

Hi,

Geert Uytterhoeven wrote:
> 
> On Fri, 22 Mar 2002, Reinhard Nissl wrote:
> > Geert Uytterhoeven wrote:
> > > On Fri, 22 Mar 2002, Reinhard Nissl wrote:
> > > > 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 m68k it's disabled, except if CONFIG_ISA=y.
> > > On APUS, it's valid if you have a PCI bridge, though.
> > >
> > > > On the other hand: what's wrong in seeking beyond EOF?
> > >
> > > Sorry, I don't understand what you mean here.
> >
> >       fd = open( "/dev/port", O_RDWR )
> >       lseek( fd, 0x64, 0 );
> >
> > The call to open() succeeds, as there exists /dev/port. Why doesn't lseek()
> > simply return an error value instead of causing a signal 11?
> 
> I don't think it causes signal 11 in the lseek, but in the read/write phase.

Going back some mails ago, there is:

> > > Call backtrace:
> > > C0035C60 C0003E7C 01800B2C 016DBA08 00000000
> >   ^^^^^^^^ ^^^^^^^^ ^^^^^^^^ ^^^^^^^^
> 
> sys_lseek, ret_from_syscall_1

So, sys_lseek calls read_port and causes a signal 11.

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

Re: 2.4.17 & kbdrate

[Geert U. <ge...@li...>]

On Fri, 22 Mar 2002, Reinhard Nissl wrote:
> Geert Uytterhoeven wrote:
> > On Fri, 22 Mar 2002, Reinhard Nissl wrote:
> > > 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 m68k it's disabled, except if CONFIG_ISA=y.
> > On APUS, it's valid if you have a PCI bridge, though.
> > 
> > > On the other hand: what's wrong in seeking beyond EOF?
> > 
> > Sorry, I don't understand what you mean here.
> 
> 	fd = open( "/dev/port", O_RDWR )
> 	lseek( fd, 0x64, 0 );
>  
> The call to open() succeeds, as there exists /dev/port. Why doesn't lseek()
> simply return an error value instead of causing a signal 11?

I don't think it causes signal 11 in the lseek, but in the read/write phase.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: 2.4.17 & kbdrate

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

Hi,

Geert Uytterhoeven wrote:
> 
> On Fri, 22 Mar 2002, Reinhard Nissl wrote:
> > 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 m68k it's disabled, except if CONFIG_ISA=y.
> On APUS, it's valid if you have a PCI bridge, though.
> 
> > On the other hand: what's wrong in seeking beyond EOF?
> 
> Sorry, I don't understand what you mean here.

	fd = open( "/dev/port", O_RDWR )
	lseek( fd, 0x64, 0 );
 
The call to open() succeeds, as there exists /dev/port. Why doesn't lseek()
simply return an error value instead of causing a signal 11?

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

Re: 2.4.17 & kbdrate

[Geert U. <ge...@li...>]

On Fri, 22 Mar 2002, Reinhard Nissl wrote:
> 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 m68k it's disabled, except if CONFIG_ISA=y.
On APUS, it's valid if you have a PCI bridge, though.

> On the other hand: what's wrong in seeking beyond EOF?

Sorry, I don't understand what you mean here.

> > > 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.

OK.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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...

Re: 2.4.17 & kbdrate

[Geert U. <ge...@li...>]

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.

> > > 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.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: 2.4.17 & kbdrate

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

Hi,

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

> > 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.

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

Re: GVP IO-Extender

[Ken T. <ke...@we...>]

On Thu, 21 Mar 2002, Geert Uytterhoeven wrote:

> On Thu, 21 Mar 2002, Ken Tyler wrote:

> Do not allow the module to be unloaded?

OK, I'll look at that but read on...
 
> BTW, how does AmigaOS handle this? Or are you always out-of-luck if you ever
> used the IO-Ext parport under AmigaOS and booted into Linux afterwards?

Booting into linux is OK for a one piece kernel as any interrupt will be
handled. A modular kernel dies if an interrupt occurs before the module is
loaded (or after it is unloaded).  

The 16c552 chip on the IO Extender has seperate interrupt enables for the
parallel and two serial ports. The 16c552 also has an interrupt mode
control input (GVP_IRQ_ENA in the 2.2 includes) which turns PC/AT mode on
and off, pretty sure this only affects the parallel port.

Turning off the the chip parallel port interrupt enable looks like it
causes continuous interrupts. This is what the 2.2.n comments suggest.

The safe way to use the Extender is not to use it as a module.

Or if it is a module the parallel port interrupt (GVP_IRQ_ENA) needs to be
shut up when linux boots.

Ken.

Re: GVP IO-Extender

[Geert U. <ge...@li...>]

On Thu, 21 Mar 2002, Ken Tyler wrote:
> I have a GVP IO-Extender parport driver working but with a problem. It
> hangs linux if the printer is turned off and on after the module has been
> unloaded.  The cause is an interrupt without a handler, once interrupts
> from the chip are enabled they can't be disabled, well they can but then
> continuous interrupts are generated. There are comments in the 2.2.n code
> that say the same thing.
> 
> What's the way to handle this situation ?

Do not allow the module to be unloaded?

BTW, how does AmigaOS handle this? Or are you always out-of-luck if you ever
used the IO-Ext parport under AmigaOS and booted into Linux afterwards?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds