LinuxLists.cc - Linux 2.6.0-test4

[permalink] [raw]

Subject: [PATCH] airo (was: Re: Linux 2.6.0-test4)

On Fri, 22 Aug 2003, Linus Torvalds wrote:
> Javier Achirica:
> o [wireless airo] Fix PCI unregister code

This patch causes a regression: if CONFIG_PCI is not set, it doesn't compile
anymore. Here's a fix. I also killed a dead variable and its corresponding
warning:

--- linux-2.6.0-test4/drivers/net/wireless/airo.c Sun Aug 24 09:49:30 2003
+++ linux-m68k-2.6.0-test4/drivers/net/wireless/airo.c Sun Aug 24 13:03:56 2003
@@ -4156,7 +4156,7 @@

static int __init airo_init_module( void )
{
- int i, rc = 0, have_isa_dev = 0;
+ int i, have_isa_dev = 0;

airo_entry = create_proc_entry("aironet",
S_IFDIR | airo_perm,
@@ -4174,7 +4174,7 @@

#ifdef CONFIG_PCI
printk( KERN_INFO "airo: Probing for PCI adapters\n" );
- rc = pci_module_init(&airo_driver);
+ pci_module_init(&airo_driver);
printk( KERN_INFO "airo: Finished probing for PCI adapters\n" );
#endif

@@ -4197,8 +4197,11 @@
}
remove_proc_entry("aironet", proc_root_driver);

- if (is_pci)
+ if (is_pci) {
+#ifdef CONFIG_PCI
pci_unregister_driver(&airo_driver);
+#endif
+ }
}

#ifdef WIRELESS_EXT

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

2003-08-24 11:51:52

[permalink] [raw]

Subject: [PATCH] macide (was: Re: Linux 2.6.0-test4)

On Fri, 22 Aug 2003, Linus Torvalds wrote:
> Bartlomiej Zolnierkiewicz:
> o ide: disk geometry/capacity cleanups
> o ide: always store disk capacity in u64

You forgot to update the Macintosh IDE driver:

--- linux-2.6.0-test4/drivers/ide/legacy/macide.c Tue Feb 25 10:21:12 2003
+++ linux-m68k-2.6.0-test4/drivers/ide/legacy/macide.c Sun Aug 24 12:37:06 2003
@@ -126,7 +126,7 @@
/* probing the drive which freezes a 190. */

ide_drive_t *drive = &ide_hwifs[index].drives[0];
- drive->capacity = drive->cyl*drive->head*drive->sect;
+ drive->capacity64 = drive->cyl*drive->head*drive->sect;

#ifdef CONFIG_BLK_DEV_MAC_MEDIABAY
request_irq(IRQ_BABOON_2, macide_mediabay_interrupt,

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

2003-08-24 12:21:01

by Christoph Hellwig

[permalink] [raw]

Subject: Re: [PATCH] macide (was: Re: Linux 2.6.0-test4)

On Sun, Aug 24, 2003 at 01:51:20PM +0200, Geert Uytterhoeven wrote:
> On Fri, 22 Aug 2003, Linus Torvalds wrote:
> > Bartlomiej Zolnierkiewicz:
> > o ide: disk geometry/capacity cleanups
> > o ide: always store disk capacity in u64
>
> You forgot to update the Macintosh IDE driver:

Btw, what's the state of mac68k (and the other m68k subarches) on
2.6?

2003-08-24 12:03:54

[permalink] [raw]

Subject: [PATCH] vmlinux-*.lds (was: Re: Linux 2.6.0-test4)

On Fri, 22 Aug 2003, Linus Torvalds wrote:
> Kai Germaschewski:
> o kbuild: Move generation of vmlinux.lds.s into arch/.../kernel

You forgot to move two files:

mv arch/m68k/vmlinux-std.lds arch/m68k/kernel
mv arch/m68k/vmlinux-sun3.lds arch/m68k/kernel

Or apply this patch:

--- linux-2.6.0-test4/arch/m68k/vmlinux-std.lds Sun Jun 15 09:37:32 2003
+++ linux-m68k-2.6.0-test4/arch/m68k/vmlinux-std.lds Tue Jun 24 14:30:53 2003
@@ -1,97 +0,0 @@
-/* ld script to make m68k Linux kernel */
-
-#include <asm-generic/vmlinux.lds.h>
-
-OUTPUT_FORMAT("elf32-m68k", "elf32-m68k", "elf32-m68k")
-OUTPUT_ARCH(m68k)
-ENTRY(_start)
-jiffies = jiffies_64 + 4;
-SECTIONS
-{
- . = 0x1000;
- _text = .; /* Text and read-only data */
- .text : {
- *(.text)
- *(.fixup)
- *(.gnu.warning)
- } = 0x4e75
-
- . = ALIGN(16); /* Exception table */
- __start___ex_table = .;
- __ex_table : { *(__ex_table) }
- __stop___ex_table = .;
-
- RODATA
-
- _etext = .; /* End of text section */
-
- .data : { /* Data */
- *(.data)
- CONSTRUCTORS
- }
-
- .bss : { *(.bss) } /* BSS */
-
- . = ALIGN(16);
- .data.cacheline_aligned : { *(.data.cacheline_aligned) }
-
- _edata = .; /* End of data section */
-
- /* will be freed after init */
- . = ALIGN(4096); /* Init code and data */
- __init_begin = .;
- .init.text : {
- _sinittext = .;
- *(.init.text)
- _einittext = .;
- }
- .init.data : { *(.init.data) }
- . = ALIGN(16);
- __setup_start = .;
- .init.setup : { *(.init.setup) }
- __setup_end = .;
- __start___param = .;
- __param : { *(__param) }
- __stop___param = .;
- __initcall_start = .;
- .initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
- }
- __initcall_end = .;
- __con_initcall_start = .;
- .con_initcall.init : { *(.con_initcall.init) }
- __con_initcall_end = .;
- SECURITY_INIT
- . = ALIGN(8192);
- __initramfs_start = .;
- .init.ramfs : { *(.init.ramfs) }
- __initramfs_end = .;
- . = ALIGN(8192);
- __init_end = .;
-
- .data.init_task : { *(.data.init_task) } /* The initial task and kernel stack */
-
- _end = . ;
-
- /* Sections to be discarded */
- /DISCARD/ : {
- *(.exit.text)
- *(.exit.data)
- *(.exitcall.exit)
- }
-
- /* Stabs debugging sections. */
- .stab 0 : { *(.stab) }
- .stabstr 0 : { *(.stabstr) }
- .stab.excl 0 : { *(.stab.excl) }
- .stab.exclstr 0 : { *(.stab.exclstr) }
- .stab.index 0 : { *(.stab.index) }
- .stab.indexstr 0 : { *(.stab.indexstr) }
- .comment 0 : { *(.comment) }
-}
--- linux-2.6.0-test4/arch/m68k/vmlinux-sun3.lds Sun Jun 15 09:37:32 2003
+++ linux-m68k-2.6.0-test4/arch/m68k/vmlinux-sun3.lds Tue Jun 24 14:30:53 2003
@@ -1,97 +0,0 @@
-/* ld script to make m68k Linux kernel */
-
-#include <asm-generic/vmlinux.lds.h>
-
-OUTPUT_FORMAT("elf32-m68k", "elf32-m68k", "elf32-m68k")
-OUTPUT_ARCH(m68k)
-ENTRY(_start)
-jiffies = jiffies_64 + 4;
-SECTIONS
-{
- . = 0xE004000;
- _text = .; /* Text and read-only data */
- .text : {
- *(.head)
- *(.text)
- *(.fixup)
- *(.gnu.warning)
- } = 0x4e75
- RODATA
-
- _etext = .; /* End of text section */
-
- .data : { /* Data */
- *(.data)
- CONSTRUCTORS
- . = ALIGN(16); /* Exception table */
- __start___ex_table = .;
- *(__ex_table)
- __stop___ex_table = .;
- }
- /* End of data goes *here* so that freeing init code works properly. */
- _edata = .;
-
- /* will be freed after init */
- . = ALIGN(8192); /* Init code and data */
-__init_begin = .;
- .init.text : {
- _sinittext = .;
- *(.init.text)
- _einittext = .;
- }
- .init.data : { *(.init.data) }
- . = ALIGN(16);
- __setup_start = .;
- .init.setup : { *(.init.setup) }
- __setup_end = .;
- __start___param = .;
- __param : { *(__param) }
- __stop___param = .;
- __initcall_start = .;
- .initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
- }
- __initcall_end = .;
- __con_initcall_start = .;
- .con_initcall.init : { *(.con_initcall.init) }
- __con_initcall_end = .;
- SECURITY_INIT
- . = ALIGN(8192);
- __initramfs_start = .;
- .init.ramfs : { *(.init.ramfs) }
- __initramfs_end = .;
- . = ALIGN(8192);
- __init_end = .;
- .init.task : { *(init_task) }
-
-
- .bss : { *(.bss) } /* BSS */
-
- _end = . ;
-
- /* Sections to be discarded */
- /DISCARD/ : {
- *(.exit.text)
- *(.exit.data)
- *(.exitcall.exit)
- }
-
- .crap : {
- /* Stabs debugging sections. */
- *(.stab)
- *(.stabstr)
- *(.stab.excl)
- *(.stab.exclstr)
- *(.stab.index)
- *(.stab.indexstr)
- *(.comment)
- *(.note)
- }
-
-}
--- linux-2.6.0-test4/arch/m68k/kernel/vmlinux-std.lds Tue Jun 24 14:30:53 2003
+++ linux-m68k-2.6.0-test4/arch/m68k/kernel/vmlinux-std.lds Sun Jun 15 10:46:43 2003
@@ -0,0 +1,97 @@
+/* ld script to make m68k Linux kernel */
+
+#include <asm-generic/vmlinux.lds.h>
+
+OUTPUT_FORMAT("elf32-m68k", "elf32-m68k", "elf32-m68k")
+OUTPUT_ARCH(m68k)
+ENTRY(_start)
+jiffies = jiffies_64 + 4;
+SECTIONS
+{
+ . = 0x1000;
+ _text = .; /* Text and read-only data */
+ .text : {
+ *(.text)
+ *(.fixup)
+ *(.gnu.warning)
+ } = 0x4e75
+
+ . = ALIGN(16); /* Exception table */
+ __start___ex_table = .;
+ __ex_table : { *(__ex_table) }
+ __stop___ex_table = .;
+
+ RODATA
+
+ _etext = .; /* End of text section */
+
+ .data : { /* Data */
+ *(.data)
+ CONSTRUCTORS
+ }
+
+ .bss : { *(.bss) } /* BSS */
+
+ . = ALIGN(16);
+ .data.cacheline_aligned : { *(.data.cacheline_aligned) }
+
+ _edata = .; /* End of data section */
+
+ /* will be freed after init */
+ . = ALIGN(4096); /* Init code and data */
+ __init_begin = .;
+ .init.text : {
+ _sinittext = .;
+ *(.init.text)
+ _einittext = .;
+ }
+ .init.data : { *(.init.data) }
+ . = ALIGN(16);
+ __setup_start = .;
+ .init.setup : { *(.init.setup) }
+ __setup_end = .;
+ __start___param = .;
+ __param : { *(__param) }
+ __stop___param = .;
+ __initcall_start = .;
+ .initcall.init : {
+ *(.initcall1.init)
+ *(.initcall2.init)
+ *(.initcall3.init)
+ *(.initcall4.init)
+ *(.initcall5.init)
+ *(.initcall6.init)
+ *(.initcall7.init)
+ }
+ __initcall_end = .;
+ __con_initcall_start = .;
+ .con_initcall.init : { *(.con_initcall.init) }
+ __con_initcall_end = .;
+ SECURITY_INIT
+ . = ALIGN(8192);
+ __initramfs_start = .;
+ .init.ramfs : { *(.init.ramfs) }
+ __initramfs_end = .;
+ . = ALIGN(8192);
+ __init_end = .;
+
+ .data.init_task : { *(.data.init_task) } /* The initial task and kernel stack */
+
+ _end = . ;
+
+ /* Sections to be discarded */
+ /DISCARD/ : {
+ *(.exit.text)
+ *(.exit.data)
+ *(.exitcall.exit)
+ }
+
+ /* Stabs debugging sections. */
+ .stab 0 : { *(.stab) }
+ .stabstr 0 : { *(.stabstr) }
+ .stab.excl 0 : { *(.stab.excl) }
+ .stab.exclstr 0 : { *(.stab.exclstr) }
+ .stab.index 0 : { *(.stab.index) }
+ .stab.indexstr 0 : { *(.stab.indexstr) }
+ .comment 0 : { *(.comment) }
+}
--- linux-2.6.0-test4/arch/m68k/kernel/vmlinux-sun3.lds Tue Jun 24 14:30:53 2003
+++ linux-m68k-2.6.0-test4/arch/m68k/kernel/vmlinux-sun3.lds Sun Jun 15 10:46:43 2003
@@ -0,0 +1,97 @@
+/* ld script to make m68k Linux kernel */
+
+#include <asm-generic/vmlinux.lds.h>
+
+OUTPUT_FORMAT("elf32-m68k", "elf32-m68k", "elf32-m68k")
+OUTPUT_ARCH(m68k)
+ENTRY(_start)
+jiffies = jiffies_64 + 4;
+SECTIONS
+{
+ . = 0xE004000;
+ _text = .; /* Text and read-only data */
+ .text : {
+ *(.head)
+ *(.text)
+ *(.fixup)
+ *(.gnu.warning)
+ } = 0x4e75
+ RODATA
+
+ _etext = .; /* End of text section */
+
+ .data : { /* Data */
+ *(.data)
+ CONSTRUCTORS
+ . = ALIGN(16); /* Exception table */
+ __start___ex_table = .;
+ *(__ex_table)
+ __stop___ex_table = .;
+ }
+ /* End of data goes *here* so that freeing init code works properly. */
+ _edata = .;
+
+ /* will be freed after init */
+ . = ALIGN(8192); /* Init code and data */
+__init_begin = .;
+ .init.text : {
+ _sinittext = .;
+ *(.init.text)
+ _einittext = .;
+ }
+ .init.data : { *(.init.data) }
+ . = ALIGN(16);
+ __setup_start = .;
+ .init.setup : { *(.init.setup) }
+ __setup_end = .;
+ __start___param = .;
+ __param : { *(__param) }
+ __stop___param = .;
+ __initcall_start = .;
+ .initcall.init : {
+ *(.initcall1.init)
+ *(.initcall2.init)
+ *(.initcall3.init)
+ *(.initcall4.init)
+ *(.initcall5.init)
+ *(.initcall6.init)
+ *(.initcall7.init)
+ }
+ __initcall_end = .;
+ __con_initcall_start = .;
+ .con_initcall.init : { *(.con_initcall.init) }
+ __con_initcall_end = .;
+ SECURITY_INIT
+ . = ALIGN(8192);
+ __initramfs_start = .;
+ .init.ramfs : { *(.init.ramfs) }
+ __initramfs_end = .;
+ . = ALIGN(8192);
+ __init_end = .;
+ .init.task : { *(init_task) }
+
+
+ .bss : { *(.bss) } /* BSS */
+
+ _end = . ;
+
+ /* Sections to be discarded */
+ /DISCARD/ : {
+ *(.exit.text)
+ *(.exit.data)
+ *(.exitcall.exit)
+ }
+
+ .crap : {
+ /* Stabs debugging sections. */
+ *(.stab)
+ *(.stabstr)
+ *(.stab.excl)
+ *(.stab.exclstr)
+ *(.stab.index)
+ *(.stab.indexstr)
+ *(.comment)
+ *(.note)
+ }
+
+}

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

2003-08-24 12:30:16

[permalink] [raw]

Subject: Re: [PATCH] macide (was: Re: Linux 2.6.0-test4)

On Sun, 24 Aug 2003, Christoph Hellwig wrote:
> On Sun, Aug 24, 2003 at 01:51:20PM +0200, Geert Uytterhoeven wrote:
> > On Fri, 22 Aug 2003, Linus Torvalds wrote:
> > > Bartlomiej Zolnierkiewicz:
> > > o ide: disk geometry/capacity cleanups
> > > o ide: always store disk capacity in u64
> >
> > You forgot to update the Macintosh IDE driver:
>
> Btw, what's the state of mac68k (and the other m68k subarches) on
> 2.6?

Amiga, Sun-3/3x and probably Q40/Q60 are working, except for some SCSI drivers.
Other subarches are in a worse shape.

In general, 2.6.0-test4 on m68k isn't that far from 2.4.22-rc3, except for some
SCSI breakage.

You can check out the status at http://linux-m68k-cvs.apia.dhs.org/~geert/.
The patch pages are usually up-to-date, the feature status pages aren't (e.g.
basic m68k support got fixed a few weeks ago).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

2003-08-24 21:01:24

by Javier Achirica

[permalink] [raw]

Subject: Re: [PATCH] airo (was: Re: Linux 2.6.0-test4)

Thank you. There's also another small PCI bug. I'll submit a patch to
Jeff.

Javier Achirica

On Sun, 24 Aug 2003, Geert Uytterhoeven wrote:

> On Fri, 22 Aug 2003, Linus Torvalds wrote:
> > Javier Achirica:
> > o [wireless airo] Fix PCI unregister code
>
> This patch causes a regression: if CONFIG_PCI is not set, it doesn't compile
> anymore. Here's a fix. I also killed a dead variable and its corresponding
> warning:
>
> --- linux-2.6.0-test4/drivers/net/wireless/airo.c Sun Aug 24 09:49:30 2003
> +++ linux-m68k-2.6.0-test4/drivers/net/wireless/airo.c Sun Aug 24 13:03:56 2003
> @@ -4156,7 +4156,7 @@
>
> static int __init airo_init_module( void )
> {
> - int i, rc = 0, have_isa_dev = 0;
> + int i, have_isa_dev = 0;
>
> airo_entry = create_proc_entry("aironet",
> S_IFDIR | airo_perm,
> @@ -4174,7 +4174,7 @@
>
> #ifdef CONFIG_PCI
> printk( KERN_INFO "airo: Probing for PCI adapters\n" );
> - rc = pci_module_init(&airo_driver);
> + pci_module_init(&airo_driver);
> printk( KERN_INFO "airo: Finished probing for PCI adapters\n" );
> #endif
>
> @@ -4197,8 +4197,11 @@
> }
> remove_proc_entry("aironet", proc_root_driver);
>
> - if (is_pci)
> + if (is_pci) {
> +#ifdef CONFIG_PCI
> pci_unregister_driver(&airo_driver);
> +#endif
> + }
> }
>
> #ifdef WIRELESS_EXT
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
>
> 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
>
>
>
>

2003-08-25 05:44:11

by William Scott Lockwood III

[permalink] [raw]

Subject: RE: Linux 2.6.0-test4

As a follow up to this, I downloaded and installed modutils and module init
tools, the latest versions available on kernel.org, did:

./configure
make all install

And I still get the same error as I was getting before. Is there somewhere
else I'm supposed to be looking, or did I miss a step building modutils and
module init tools?

Scott

--

-----Original Message-----
From: Jeff Garzik [mailto:[email protected]]
Sent: Saturday, August 23, 2003 10:32 AM
To: [email protected]
Cc: 'Linus Torvalds'; 'Kernel Mailing List'
Subject: Re: Linux 2.6.0-test4

On Sat, Aug 23, 2003 at 07:26:45AM -0500, [email protected] wrote:
> Getting this compile problem during modules_install, will paste in .config
> after the depmod errors:

Looks like you need new modutils...

Jeff

2003-08-25 21:00:28

by Adrian Bunk

[permalink] [raw]

Subject: [patch] 2.6.0-test4: sis190 doesn't compile with gcc 2.95

On Fri, Aug 22, 2003 at 05:48:56PM -0700, Linus Torvalds wrote:
>...
> Summary of changes from v2.6.0-test3 to v2.6.0-test4
> ============================================
>...
> Jeff Garzik:
>...
> o [netdrvr] add sis190 gigabit ethernet driver (note: needs work)
>...

The following is needed to fix the compilation of sis190 with gcc 2.95:

--- linux-2.6.0-test4-mm1/drivers/net/sis190.c.old 2003-08-25 20:03:04.000000000 +0200
+++ linux-2.6.0-test4-mm1/drivers/net/sis190.c 2003-08-25 20:03:45.000000000 +0200
@@ -536,6 +536,7 @@
static int printed_version = 0;
int i, rc;
u16 reg31;
+ int val;

assert(pdev != NULL);
assert(ent != NULL);
@@ -620,7 +621,7 @@
dev->dev_addr[2], dev->dev_addr[3],
dev->dev_addr[4], dev->dev_addr[5], dev->irq);

- int val = smdio_read(ioaddr, PHY_AUTO_NEGO_REG);
+ val = smdio_read(ioaddr, PHY_AUTO_NEGO_REG);

printk(KERN_INFO "%s: Auto-negotiation Enabled.\n", dev->name);

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2003-08-25 21:20:32

by insecure

[permalink] [raw]

Subject: Re: Linux 2.6.0-test4

> o [arcnet com90io] replace check_region with temporary
> request_region, in probe phase.

check_region() is deprecated because it is racy.
Replacing it with request_region in probe:

int probe() {
if(!request_region(...))
return 0;
/* probe */
release_region(...);
}

int init() {
request_region(...);
}

only removes 'deprecated' warning. Race remains.
--
vda

2003-08-25 21:26:58

by insecure

[permalink] [raw]

Subject: [PATCH] raceless request_region() fix (was Re: Linux 2.6.0-test4)

On Tuesday 26 August 2003 00:20, insecure wrote:
> > o [arcnet com90io] replace check_region with temporary
> > request_region, in probe phase.
>
> check_region() is deprecated because it is racy.
> Replacing it with request_region in probe:
>
> int probe() {
> if(!request_region(...))
> return 0;
> /* probe */
> release_region(...);
> }
>
> int init() {
> request_region(...);
> }
>
> only removes 'deprecated' warning. Race remains.

Corrected com90io.c patch is below.
--
vda

--- linux-2.6.0-test4/drivers/net/arcnet/com90io.c.orig Sat Aug 23 02:53:52 2003
+++ linux-2.6.0-test4/drivers/net/arcnet/com90io.c Tue Aug 26 00:22:51 2003
@@ -158,7 +158,7 @@
"must specify the base address!\n");
return -ENODEV;
}
- if (!request_region(ioaddr, ARCNET_TOTAL_SIZE, "com90io probe")) {
+ if (!request_region(ioaddr, ARCNET_TOTAL_SIZE, "arcnet (COM90xx-IO)")) {
BUGMSG(D_INIT_REASONS, "IO check_region %x-%x failed.\n",
ioaddr, ioaddr + ARCNET_TOTAL_SIZE - 1);
return -ENXIO;
@@ -218,7 +218,6 @@
goto err_out;
}
}
- release_region(ioaddr, ARCNET_TOTAL_SIZE); /* end of probing */
return com90io_found(dev);

err_out:
@@ -237,13 +236,9 @@

/* Reserve the irq */
if (request_irq(dev->irq, &arcnet_interrupt, 0, "arcnet (COM90xx-IO)", dev)) {
+ release_region(dev->base_addr, ARCNET_TOTAL_SIZE);
BUGMSG(D_NORMAL, "Can't get IRQ %d!\n", dev->irq);
return -ENODEV;
- }
- /* Reserve the I/O region - guaranteed to work by check_region */
- if (!request_region(dev->base_addr, ARCNET_TOTAL_SIZE, "arcnet (COM90xx-IO)")) {
- free_irq(dev->irq, dev);
- return -EBUSY;
}

/* Initialize the rest of the device structure. */

2003-08-25 21:59:45

by Jeff Garzik

[permalink] [raw]

Subject: Re: [PATCH] raceless request_region() fix (was Re: Linux 2.6.0-test4)

Is it a race if noone cares? :)

The code does

if (!request_region(...))
fail
touch hardware
release_region
if (!request_region(...))
fail

If the HIGHLY UNLIKELY event of another ISA driver claiming this region
occurs, the system continues working just fine.

At the time, I was thinking that any further touching of the code should
be converting it to a more pnp-like structure.

Jeff

2003-08-25 22:56:55

by John Cherry

[permalink] [raw]

Subject: Re: Linux 2.6.0-test4 (compile statistics)

Compile statistics: 2.6.0-test4
Compiler: gcc 3.2.2
Script: http://developer.osdl.org/~cherry/compile/compregress.sh

bzImage bzImage modules
(defconfig) (allmodconfig) (allmodconfig)

2.6.0-test4 0 warnings 3 warnings 1016 warnings
0 errors 0 errors 34 errors

2.6.0-test3 0 warnings 7 warnings 984 warnings
0 errors 9 errors 42 errors

2.6.0-test2 0 warnings 7 warnings 1201 warnings
0 errors 9 errors 43 errors

2.6.0-test1 0 warnings 8 warnings 1319 warnings
0 errors 9 errors 38 errors

Compile statistics for 2.5 kernels and 2.6 kernels are at:
http://developer.osdl.org/~cherry/compile/

Failure summary:

drivers/block: 2 warnings, 1 errors
drivers/isdn: 257 warnings, 6 errors
drivers/media: 5 warnings, 5 errors
drivers/mtd: 25 warnings, 1 errors
drivers/net: 208 warnings, 8 errors
drivers/net: 36 warnings, 8 errors
drivers/scsi/aic7xxx: 0 warnings, 3 errors
drivers/scsi: 97 warnings, 7 errors
drivers/video: 8 warnings, 3 errors
sound/oss: 49 warnings, 1 errors
sound/pcmcia: 0 warnings, 2 errors
sound: 0 warnings, 3 errors

Warning summary:

drivers/atm: 12 warnings, 0 errors
drivers/cdrom: 26 warnings, 0 errors
drivers/char: 244 warnings, 0 errors
drivers/i2c: 3 warnings, 0 errors
drivers/ide: 30 warnings, 0 errors
drivers/md: 2 warnings, 0 errors
drivers/message: 1 warnings, 0 errors
drivers/pcmcia: 3 warnings, 0 errors
drivers/scsi/pcmcia: 4 warnings, 0 errors
drivers/scsi/sym53c8xx_2: 2 warnings, 0 errors
drivers/serial: 1 warnings, 0 errors
drivers/telephony: 5 warnings, 0 errors
drivers/usb: 5 warnings, 0 errors
drivers/video/aty: 3 warnings, 0 errors
drivers/video/console: 2 warnings, 0 errors
drivers/video/matrox: 5 warnings, 0 errors
drivers/video/sis: 1 warnings, 0 errors
fs/afs: 2 warnings, 0 errors
fs/intermezzo: 1 warnings, 0 errors
fs/smbfs: 2 warnings, 0 errors
net: 13 warnings, 0 errors
sound/isa: 3 warnings, 0 errors

John

2003-08-26 05:21:15

by insecure

[permalink] [raw]

Subject: Re: [PATCH] raceless request_region() fix (was Re: Linux 2.6.0-test4)

[de-cc'ing Linus]

On Tuesday 26 August 2003 00:59, Jeff Garzik wrote:
> Is it a race if noone cares? :)
>
> The code does
>
> if (!request_region(...))
> fail
> touch hardware
> release_region
> if (!request_region(...))
> fail
>
> If the HIGHLY UNLIKELY event of another ISA driver claiming this region
> occurs, the system continues working just fine.

Yes, this particular driver is fine. My patch just eliminate back-to-back
release_region(...)
if (!request_region(...)) fail;
pair.

I just have a feeling that if I am going to replace check_region with
request_region, I can close race window altogether.

BTW, it all started when I tried to get rid of check_region in de4x5.c.
That's a bit worse. For example:
barrier();
request_region(iobase, (lp->bus == PCI ? DE4X5_PCI_TOTAL_SIZE :
DE4X5_EISA_TOTAL_SIZE),
lp->adapter_name);
lp->rxRingSize = NUM_RX_DESC;
--
vda

2003-08-26 17:44:28

by Jeff Garzik

[permalink] [raw]

Subject: Re: [patch] 2.6.0-test4: sis190 doesn't compile with gcc 2.95

thanks, applied

2003-08-30 09:04:27

[permalink] [raw]

Subject: Re: Linux 2.6.0-test4

* Linus Torvalds <[email protected]>:
>
> There should be a lot of compile fixes here, along with updates for ia64,
> and the (painful) move of the 'name' entry out of the "struct device" that
> helps avoid unnecessary memory waste.
>
> It's a lot of small stuff all over: nothing really stands out in diffstat,
> except the big update of the Zoran video capture driver, and the blkmtd
> driver - both updated from their respective development trees (and the ips
> scsi driver, but that was due to massive whitespace fixing).
>
> Normal merges with Andrew and arch maintainers (x86-64, ia64, sparc64,
> arm), and AGP updates (notably the merging of the ATI IGP). And network
> driver updates, ACPI and power management infrastructure.

This one is actually usable on my laptop (Sattelite Pro 6100 by
Toshiba). ACPI works, ALSA work, and it seems to work in general.

I still have issues with the keyboard -- sometimes when typing in the
frambuffer console I get an "unknown scancode" and after that the CTRL
key is stuck forever, which forces me to reboot.

--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
AIM: ralfpostfix

2003-08-30 14:16:34

by ク

[permalink] [raw]

Subject: Re:Re: Linux 2.6.0-test4

> I still have issues with the keyboard -- sometimes when typing in the
> frambuffer console I get an "unknown scancode" and after that the CTRL
> key is stuck forever, which forces me to reboot.

Please post the full error message. Does the error message always
contain the same scancode?

My guess is you can get out of that without a reboot. Next time it
happens, try this:
1. Press and release each Ctrl key. (This makes sure the key_down
array is correct.)
2. Switch to another console and back again. (This executes the
compute_shiftstate function, which recalculates the shift
state from the key_down array.)

Chris

2003-08-30 14:59:06

[permalink] [raw]

Subject: Re: Re:Re: Linux 2.6.0-test4

* Chris Heath <[email protected]>:
> > I still have issues with the keyboard -- sometimes when typing in the
> > frambuffer console I get an "unknown scancode" and after that the CTRL
> > key is stuck forever, which forces me to reboot.
>
> Please post the full error message. Does the error message always
> contain the same scancode?

I'll do that.

Aug 27 18:53:41 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
Aug 27 19:15:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
Aug 27 19:42:50 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
Aug 28 10:14:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.

Basically, CTRL was stuck. Even when I switched to X11.

> My guess is you can get out of that without a reboot. Next time it
> happens, try this:
> 1. Press and release each Ctrl key. (This makes sure the key_down
> array is correct.)
> 2. Switch to another console and back again. (This executes the
> compute_shiftstate function, which recalculates the shift
> state from the key_down array.)

Ah, good idea.

--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
AIM: ralfpostfix

2003-08-31 16:22:54

by ク

[permalink] [raw]

Subject: Re: Re:Re: Linux 2.6.0-test4

> Aug 27 18:53:41 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Aug 27 19:15:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> Aug 27 19:42:50 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Aug 28 10:14:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
>
> Basically, CTRL was stuck. Even when I switched to X11.

Well, this completely baffles me. I thought X11 maintains its own
keydown array.

Anyway, I've included a patch that should hopefully give us better
debugging information. When you get an unknown key error, it will also
dump the last 16 bytes that were sent from the keyboard. Be careful
with this one. If you post any errors to the list, make sure it doesn't
contain any sensitive passwords. :-)

Chris

--- a/drivers/input/serio/i8042.c 2003-08-09 11:58:10.000000000 -0400
+++ b/drivers/input/serio/i8042.c 2003-08-31 10:16:55.000000000 -0400
@@ -62,6 +62,7 @@
static unsigned char i8042_last_release;
static unsigned char i8042_mux_open;
struct timer_list i8042_timer;
+unsigned char i8042_history[16];

/*
* Shared IRQ's require a device pointer, but this driver doesn't support
@@ -334,6 +335,14 @@
static char i8042_mux_short[4][16];
static char i8042_mux_phys[4][32];

+void dump_i8042_history(void) {
+ int i;
+ printk(KERN_WARNING "i8042 history: ");
+ for (i=0; i<sizeof(i8042_history); i++)
+ printk("%02x ", i8042_history[i]);
+ printk("\n");
+}
+
/*
* i8042_interrupt() is the most important function in this driver -
* it handles the interrupts from the i8042, and sends incoming bytes
@@ -405,6 +414,8 @@
continue;
}

+ memmove(i8042_history, &i8042_history[1], sizeof(i8042_history)-1);
+ i8042_history[sizeof(i8042_history)-1] = data;
if (data > 0x7f) {
unsigned char index = (data & 0x7f) | (i8042_last_e0 << 7);
/* work around hardware that doubles key releases */
--- a/drivers/input/keyboard/atkbd.c 2003-06-22 18:45:06.000000000 -0400
+++ b/drivers/input/keyboard/atkbd.c 2003-08-31 10:11:51.000000000 -0400
@@ -131,6 +131,7 @@
* atkbd_interrupt(). Here takes place processing of data received from
* the keyboard into events.
*/
+void dump_i8042_history(void);

static irqreturn_t atkbd_interrupt(struct serio *serio, unsigned char data,
unsigned int flags, struct pt_regs *regs)
@@ -193,6 +194,7 @@
case ATKBD_KEY_UNKNOWN:
printk(KERN_WARNING "atkbd.c: Unknown key (set %d, scancode %#x, on %s) %s.\n",
atkbd->set, code, serio->phys, atkbd->release ? "released" : "pressed");
+ dump_i8042_history();
break;
default:
input_regs(&atkbd->dev, regs);

2003-09-01 16:15:41

[permalink] [raw]

Subject: Re: Re:Re: Linux 2.6.0-test4

2003-09-02 00:16:53

[permalink] [raw]

Subject: [PATCH] keyboard - was: Re: Linux 2.6.0-test4

[I changed the subject to be slightly more indicative of contents.]

On Mon, Sep 01, 2003 at 06:01:25PM +0200, Ralf Hildebrandt wrote:
> * Chris Heath <[email protected]>:
> > > Aug 27 18:53:41 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > > Aug 27 19:15:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> > > Aug 27 19:42:50 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > > Aug 28 10:14:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > >
> > > Basically, CTRL was stuck. Even when I switched to X11.
> >
> > Well, this completely baffles me. I thought X11 maintains its own
> > keydown array.

It can do that only when it gets uncontaminated data.

> I applied your patch, and alas:
>
> Sep 1 16:12:19 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> Sep 1 16:12:19 hummus2 kernel: i8042 history: ae 9d e0 48 e0 c8 e0 38 56 d6 e0 b8 e0 b8 39 b9

I don't know why you say "alas". I read (two key releases, then)
press UpArrow, release UpArrow, RAlt, some key, release some key, release RAlt,
funny: again release RAlt, press space bar, release space bar.

So, nothing "Unknown" about this 0xb9 key - it is the spacebar release.

But i8042.c will do an unxlate when it thinks the key is down, so it
did not think so. But we saw the key down a moment ago. Apparently
the line

set_bit(data | (i8042_last_e0 << 7), i8042_unxlate_seen);

did not set i8042_unxlate_seen for data = 0x39. And it is clear why:
The sequence e0 b8 e0 b8 is a repetition, the second e0 sets i8042_last_e0,
but after the second b8 we bail out without clearing i8042_last_e0 again.
*BUG*.

Conclusion: in the skipped double release case we must clear i8042_last_e0.

Andries

Vojtech: Note: 1 line should be added in i8042.c:i8042_interrupt().
[A stopgap - in fact all this i8042_unxlate_seen stuff should be ripped out.]

--- serio/i8042.c~ Sat Aug 9 22:16:42 2003
+++ serio/i8042.c Tue Sep 2 03:09:12 2003
@@ -410,6 +410,7 @@
/* work around hardware that doubles key releases */
if (index == i8042_last_release) {
dbg("i8042 skipped double release (%d)\n", index);
+ i8042_last_e0 = 0;
continue;
}
if (index == 0xaa || index == 0xb6)

2003-09-02 05:39:11

[permalink] [raw]

Subject: Re: [PATCH] keyboard - was: Re: Linux 2.6.0-test4

* Andries Brouwer <[email protected]>:

> > * Chris Heath <[email protected]>:
> > > > Aug 27 18:53:41 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > > > Aug 27 19:15:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> > > > Aug 27 19:42:50 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > > > Aug 28 10:14:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > > >
> > > > Basically, CTRL was stuck. Even when I switched to X11.
> > >
> > > Well, this completely baffles me. I thought X11 maintains its own
> > > keydown array.
>
> It can do that only when it gets uncontaminated data.
>
> > I applied your patch, and alas:
> >
> > Sep 1 16:12:19 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> > Sep 1 16:12:19 hummus2 kernel: i8042 history: ae 9d e0 48 e0 c8 e0 38 56 d6 e0 b8 e0 b8 39 b9
>
> I don't know why you say "alas". I read (two key releases, then)
> press UpArrow, release UpArrow, RAlt, some key, release some key, release RAlt,
> funny: again release RAlt, press space bar, release space bar.

This must a known bug of this particular keyboard.

> So, nothing "Unknown" about this 0xb9 key - it is the spacebar release.
>
> But i8042.c will do an unxlate when it thinks the key is down, so it
> did not think so. But we saw the key down a moment ago. Apparently
> the line
>
> set_bit(data | (i8042_last_e0 << 7), i8042_unxlate_seen);
>
> did not set i8042_unxlate_seen for data = 0x39. And it is clear why:
> The sequence e0 b8 e0 b8 is a repetition, the second e0 sets i8042_last_e0,
> but after the second b8 we bail out without clearing i8042_last_e0 again.
> *BUG*.
>
> Conclusion: in the skipped double release case we must clear i8042_last_e0.
>
> Andries
>
> Vojtech: Note: 1 line should be added in i8042.c:i8042_interrupt().
> [A stopgap - in fact all this i8042_unxlate_seen stuff should be ripped out.]
>
> --- serio/i8042.c~ Sat Aug 9 22:16:42 2003
> +++ serio/i8042.c Tue Sep 2 03:09:12 2003
> @@ -410,6 +410,7 @@
> /* work around hardware that doubles key releases */
> if (index == i8042_last_release) {
> dbg("i8042 skipped double release (%d)\n", index);
> + i8042_last_e0 = 0;
> continue;
> }
> if (index == 0xaa || index == 0xb6)

--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
AIM: ralfpostfix

2003-09-02 08:07:51

[permalink] [raw]

Subject: Re: Re:Re: Linux 2.6.0-test4

* Chris Heath <[email protected]>:
> > Aug 27 18:53:41 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > Aug 27 19:15:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> > Aug 27 19:42:50 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > Aug 28 10:14:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> >
> > Basically, CTRL was stuck. Even when I switched to X11.
>
> Well, this completely baffles me. I thought X11 maintains its own
> keydown array.
>
> Anyway, I've included a patch that should hopefully give us better
> debugging information. When you get an unknown key error, it will also
> dump the last 16 bytes that were sent from the keyboard. Be careful
> with this one. If you post any errors to the list, make sure it doesn't
> contain any sensitive passwords. :-)

I got some more events, and today I even was able to reproduc the
"CTRL-is-stuck" problem.

I was able to get the key unstuck by switching back and forth between
dirrerent FB consoles and by pushing and releaseing CTRL in them...

Sep 2 09:10:01 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
Sep 2 09:10:01 hummus2 kernel: i8042 history: e0 d0 1c 9c 2e ae 10 90 e0 50 e0 d0 e0 d0 1c 9c

Sep 2 09:10:06 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xa0, on isa0060/serio0) pressed.
Sep 2 09:10:06 hummus2 kernel: i8042 history: 1c 9c 1c 9c e0 50 e0 d0 e0 50 e0 d0 e0 d0 20 a0

Sep 2 09:14:54 hummus2 kernel: input: AT Set 2 keyboard on isa0060/serio0

Sep 2 09:25:44 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
Sep 2 09:25:44 hummus2 kernel: i8042 history: e0 50 e0 d0 e0 50 e0 d0 e0 d0 1d 2d ad 1f 9f 9d

Sep 2 09:30:34 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
Sep 2 09:30:34 hummus2 kernel: i8042 history: e0 48 e0 c8 39 b9 e0 38 56 d6 e0 b8 e0 b8 39 b9

Sep 2 09:35:51 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
Sep 2 09:35:51 hummus2 kernel: i8042 history: a0 20 a0 9d e0 4d e0 cd e0 4d e0 cd e0 cd 39 b9

--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
AIM: ralfpostfix

2003-09-02 10:50:33

[permalink] [raw]

Subject: keyboard - was: Re: Linux 2.6.0-test4

On Tue, Sep 02, 2003 at 10:07:33AM +0200, Ralf Hildebrandt wrote:

> I got some more events, and today I even was able to reproduc the
> "CTRL-is-stuck" problem.
>
> I was able to get the key unstuck by switching back and forth between
> dirrerent FB consoles and by pushing and releaseing CTRL in them...

Yesterday's data sufficed, and I suppose the patch I gave solves
this problem. Now that you send this, we can verify that each time
there is a problem we have had a double release just before, and
that release was an e0 xx combination.

> atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
> i8042 history: e0 d0 1c 9c 2e ae 10 90 e0 50 e0 d0 e0 d0 1c 9c
>
> atkbd.c: Unknown key (set 2, scancode 0xa0, on isa0060/serio0) pressed.
> i8042 history: 1c 9c 1c 9c e0 50 e0 d0 e0 50 e0 d0 e0 d0 20 a0
>
> atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> i8042 history: e0 50 e0 d0 e0 50 e0 d0 e0 d0 1d 2d ad 1f 9f 9d
>
> atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> i8042 history: e0 48 e0 c8 39 b9 e0 38 56 d6 e0 b8 e0 b8 39 b9
>
> atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> i8042 history: a0 20 a0 9d e0 4d e0 cd e0 4d e0 cd e0 cd 39 b9

And indeed, we see e0 d0 e0 d0, e0 b8 e0 b8, e0 cd e0 cd.

This bug is understood.

2003-09-02 12:34:48

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

* Andries Brouwer <[email protected]>:

> Yesterday's data sufficed, and I suppose the patch I gave solves
> this problem.

Nope. I applied the patch and rebuilt the kernel and rebooted.

Linux version 2.6.0-test4-bk2 (root@hummus2) (gcc version 3.2.3 (Debian)) #1 Tue Sep 2 11:45:23 CEST 2003
shows that the kernel I build this moring is actually running.

Right now, my CTRL key is totally "stuck" on the fbconsole. I can't
release it, not even by switching between the consoles and/or X11.

But now I don't get any messages like the one below (yes, the special
code generating this output is still active...)

> > atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
> > i8042 history: e0 d0 1c 9c 2e ae 10 90 e0 50 e0 d0 e0 d0 1c 9c

--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
AIM: ralfpostfix

2003-09-02 11:19:35

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

* Andries Brouwer <[email protected]>:
> On Tue, Sep 02, 2003 at 10:07:33AM +0200, Ralf Hildebrandt wrote:
>
> > I got some more events, and today I even was able to reproduc the
> > "CTRL-is-stuck" problem.
> >
> > I was able to get the key unstuck by switching back and forth between
> > dirrerent FB consoles and by pushing and releaseing CTRL in them...
>
> Yesterday's data sufficed, and I suppose the patch I gave solves
> this problem. Now that you send this, we can verify that each time
> there is a problem we have had a double release just before, and
> that release was an e0 xx combination.

Excellent. I rebuild my kernel including your patch; I shall reboot
soon :)

> This bug is understood.

I'll get back to you once I verify that the problem doesn't occur
anymore.

--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
AIM: ralfpostfix

2003-09-02 21:41:45

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

On Tue, Sep 02, 2003 at 02:32:52PM +0200, Ralf Hildebrandt wrote:

> > Yesterday's data sufficed, and I suppose the patch I gave solves
> > this problem.
>
> Nope. I applied the patch and rebuilt the kernel and rebooted.
>
> Right now, my CTRL key is totally "stuck" on the fbconsole. I can't
> release it, not even by switching between the consoles and/or X11.
>
> But now I don't get any messages like the one below (yes, the special
> code generating this output is still active...)
>
> > > atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
> > > i8042 history: e0 d0 1c 9c 2e ae 10 90 e0 50 e0 d0 e0 d0 1c 9c

Well, that shows that this particular problem was solved, but there are
more problems. No doubt we'll understand everything eventually.

(Unless we remove this i8042_unxlate_seen before understanding all problems.
It is really very ugly to have two different arrays that both keep the
"key down" status of the keys, and that can get out of sync.)

Again, of course, I would like to see the past few dozen scancodes, like you
gave before, up to the moment the problem arises.
(If you cannot think of something better, just log every incoming scancode.)

Andries

2003-09-03 07:45:55

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

* Andries Brouwer <[email protected]>:

> > > > atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
> > > > i8042 history: e0 d0 1c 9c 2e ae 10 90 e0 50 e0 d0 e0 d0 1c 9c
>
> Well, that shows that this particular problem was solved, but there are
> more problems. No doubt we'll understand everything eventually.

Thanks. And I'm happy to apply your patches to my shitty laptop :)

> (Unless we remove this i8042_unxlate_seen before understanding all problems.
> It is really very ugly to have two different arrays that both keep the
> "key down" status of the keys, and that can get out of sync.)
>
> Again, of course, I would like to see the past few dozen scancodes, like you
> gave before, up to the moment the problem arises.
> (If you cannot think of something better, just log every incoming scancode.)

Right now I keep running the laptop with your patch and the keycode
history patch.

Anything in particular that I should do?

--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
AIM: ralfpostfix

2003-09-03 13:26:25

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

* Andries Brouwer <[email protected]>:

> Well, that shows that this particular problem was solved, but there are
> more problems. No doubt we'll understand everything eventually.
>
> (Unless we remove this i8042_unxlate_seen before understanding all problems.
> It is really very ugly to have two different arrays that both keep the
> "key down" status of the keys, and that can get out of sync.)
>
> Again, of course, I would like to see the past few dozen scancodes, like you
> gave before, up to the moment the problem arises.
> (If you cannot think of something better, just log every incoming scancode.)

Right now I'm building 2.6.0-test4-bk5 (which has "the patch" in it)
and added the keycode history patch. I'll let you know how it goes.

--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
AIM: ralfpostfix

2003-09-04 04:10:42

by ク

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

> > Right now, my CTRL key is totally "stuck" on the fbconsole. I can't
> > release it, not even by switching between the consoles and/or X11.
> >
> > > > atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
> > > > i8042 history: e0 d0 1c 9c 2e ae 10 90 e0 50 e0 d0 e0 d0 1c 9c
>
> Well, that shows that this particular problem was solved, but there are
> more problems. No doubt we'll understand everything eventually.

Quite right. When we get a repeated key release, say e0 d0 e0 d0, we
were ignoring the last d0, whereas actually we should have ignored the
second e0 too. As you can imagine, this caused stuck CTRL keys among
other things.

> > But now I don't get any messages like the one below (yes, the special
> > code generating this output is still active...)

Since then, Ralf has reported to me in a private email that he got the
following (rather troubling) error:

Sep 2 14:43:51 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb2, on isa0060/serio0) pressed.
Sep 2 14:43:51 hummus2 kernel: i8042 history: e0 48 e0 c8 22 a2 13 93 93 17 97 32 31 b2 b1 b2

So it seems it is occasionally possible to have a repeated key release
(b2) with another key release (b1) in between. Ouch!

The patch below is supposed to solve both these problems. It makes some
assumptions, which I have listed below. (It probably wouldn't be hard to
remove any of these assumptions, but I don't feel like hacking this
code any more than I have to.)

1. I assume it is OK to defer processing the code e0 until the following
byte arrives. Are there any keyboards out there with e0 in the keyboard
ID? This could break the atkbd probe for such keyboards. (The
alternative would be to pass the repeated key releases through to atkbd,
and let that layer remove the duplicates.)

2. The event that appears between two repeated key releases is always a
key release and not a key press.

3. There will only be at most one key event in between two repeated key
releases.

Chris

--- linux-2.6.0-test4-bk5/drivers/input/serio/i8042.c 2003-08-09 11:58:10.000000000 -0400
+++ linux-2.6.0-test4-cdh1/drivers/input/serio/i8042.c 2003-09-03 22:30:52.000000000 -0400
@@ -59,7 +59,7 @@
static unsigned char i8042_initial_ctr;
static unsigned char i8042_ctr;
static unsigned char i8042_last_e0;
-static unsigned char i8042_last_release;
+static unsigned char i8042_last_release[2];
static unsigned char i8042_mux_open;
struct timer_list i8042_timer;

@@ -343,7 +343,7 @@
static irqreturn_t i8042_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
unsigned long flags;
- unsigned char str, data;
+ unsigned char str, data, index;
unsigned int dfl;
struct {
int data;
@@ -405,30 +405,39 @@
continue;
}

+ index = (data & 0x7f) | (i8042_last_e0 << 7);
+
+ /* work around hardware that doubles key releases */
+ if (data > 0x7f && (index == i8042_last_release[0]
+ || index == i8042_last_release[1])) {
+ dbg("i8042 skipped double release (%d)\n", index);
+ i8042_last_e0 = 0;
+ continue;
+ }
+
+ if (i8042_last_e0)
+ serio_interrupt(&i8042_kbd_port, 0xe0, dfl, regs);
if (data > 0x7f) {
- unsigned char index = (data & 0x7f) | (i8042_last_e0 << 7);
- /* work around hardware that doubles key releases */
- if (index == i8042_last_release) {
- dbg("i8042 skipped double release (%d)\n", index);
- i8042_last_e0 = 0;
- continue;
- }
if (index == 0xaa || index == 0xb6)
set_bit(index, i8042_unxlate_seen);
if (test_and_clear_bit(index, i8042_unxlate_seen)) {
serio_interrupt(&i8042_kbd_port, 0xf0, dfl, regs);
data = i8042_unxlate_table[data & 0x7f];
- i8042_last_release = index;
+ i8042_last_release[1] = i8042_last_release[0];
+ i8042_last_release[0] = index;
}
} else {
- set_bit(data | (i8042_last_e0 << 7), i8042_unxlate_seen);
+ set_bit(index, i8042_unxlate_seen);
data = i8042_unxlate_table[data];
- i8042_last_release = 0;
+ i8042_last_release[1] = 0;
+ i8042_last_release[0] = 0;
}

i8042_last_e0 = (data == 0xe0);

- serio_interrupt(&i8042_kbd_port, data, dfl, regs);
+ /* defer sending e0 in case it's part of a double key release */
+ if (!i8042_last_e0)
+ serio_interrupt(&i8042_kbd_port, data, dfl, regs);
}

/* FIXME - was it really ours? */

2003-09-04 20:48:34

by Jamie Lokier

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

Chris Heath wrote:
> 1. I assume it is OK to defer processing the code e0 until the following
> byte arrives. Are there any keyboards out there with e0 in the keyboard
> ID? This could break the atkbd probe for such keyboards. (The
> alternative would be to pass the repeated key releases through to atkbd,
> and let that layer remove the duplicates.)
>
> 2. The event that appears between two repeated key releases is always a
> key release and not a key press.
>
> 3. There will only be at most one key event in between two repeated key
> releases.

Why so many complicated assumptions? Just maintain a bitmap if key
up/down states (initialised to up), and if you receive a release event
when the key is in the up state, ignore the event.

-- Jamie

2003-09-04 22:36:08

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

On Thu, Sep 04, 2003 at 09:48:16PM +0100, Jamie Lokier wrote:

> Why so many complicated assumptions? Just maintain a bitmap if key
> up/down states (initialised to up), and if you receive a release event
> when the key is in the up state, ignore the event.

Ha! We maintain two such bitmaps. And they get out of sync too.

You talk too easily. "If you receive a release event".
But one does not receive release events, one receives bytes.
The interpretation of those bytes belongs to the keyboard driver.

But i8042.c needs to know whether scancodes are releases
in order to do its massaging of the scancodes before giving
them to the keyboard driver.

I regard i8042.c as fundamentally broken.
On the other hand, it almost works.

Andries

2003-09-04 23:01:09

by Jamie Lokier

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

Andries Brouwer wrote:
> Ha! We maintain two such bitmaps. And they get out of sync too.
>
> You talk too easily. "If you receive a release event".
> But one does not receive release events, one receives bytes.
> The interpretation of those bytes belongs to the keyboard driver.
>
> But i8042.c needs to know whether scancodes are releases
> in order to do its massaging of the scancodes before giving
> them to the keyboard driver.

Are you saying that it isn't possible for i8042.c to simply pass all
events (including duplicates) to the keyboard driver to sanitise?

-- Jamie

2003-09-05 00:19:58

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

On Fri, Sep 05, 2003 at 12:00:55AM +0100, Jamie Lokier wrote:

> Are you saying that it isn't possible for i8042.c to simply pass all
> events (including duplicates) to the keyboard driver to sanitise?

I am saying that I would like nothing better than that.
But it is a fundamental change of setup.

2003-09-05 03:52:27

by ク

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

> > Are you saying that it isn't possible for i8042.c to simply pass all
> > events (including duplicates) to the keyboard driver to sanitise?
>
> I am saying that I would like nothing better than that.
> But it is a fundamental change of setup.

Well... I think the overall design is the right one. The atkbd driver
expects to be talking to an AT keyboard, usually using Set 2.

However, the bytes that come from the i8042 are a mixture of Set 1 and
Set 2. Set 1 because the key releases have their 8th bits set, and Set
2 because we get the non-XT keys escaped with E0. I guess the keyboard
is sending Set 2 and the BIOS is translating the set 2 codes to set 1
for "compatibility with XT software".

So the i8042 layer is IMHO the right place to untranslate this mess back
into normal Set 2. The problem is that the BIOS translation is not
invertible, so we have to hack the untranslation as best we can. The
current algorithm is to untranslate all bytes 0x00-0x7f, and to
untranslate the others only if there was a previous key press. This
means the i8042 layer has to know about scancodes, knowledge which
probably only belongs in the atkbd layer.

Probably, now that I think about it, the sanitization of duplicate key
releases should rightfully be part of the atkbd layer, because those
codes are actually being sent from the keyboard.

But either way, the problem remains to find a good untranslate
hack^Walgorithm. Because we are getting duplicate key releases, we have
to make sure they they are either untranslated or removed. Sending them
through unchanged, as we were in -test1 causes lots of grief to the
atkbd layer.

At this late stage, I don't think it is a good idea to completely
rewrite the untranslate algorithm. So we continue to hack it and hack
it until it works. :-/

Chris

2003-09-05 13:48:40

by Norman Diamond

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

Although I don't have time to keep up with the list, I saw this posting from
"Chris Heath" <[email protected]>. Reordered by importance:

> At this late stage, I don't think it is a good idea to completely
> rewrite the untranslate algorithm. So we continue to hack it and hack
> it until it works. :-/

Surely not. Some keyboards which worked since 2.0 and probably 1.something
are broken in 2.6. Other keyboards which worked before 2.2.something
(without USB drivers but with BIOS emulation) and resumed working since
2.4.something (with fixed USB dirvers) are broken in 2.6. Haven't some
lessons been learned from a 2.4.something-dontuse and a few other
2.4.somethings which also should have been -dontuse? If 2.6.0-dontuse gets
released, Linux will really be as bad as some other famous operating
systems. Surely it is better to rewrite the untranslate algorithm.

Of course there's some power management and other problems which are in the
same situation. The keyboard is not the only reason why it would be foolish
to release 2.6.0 before it starts working.

> However, the bytes that come from the i8042 are a mixture of Set 1 and
> Set 2. Set 1 because the key releases have their 8th bits set, and Set
> 2 because we get the non-XT keys escaped with E0.

I wonder if it's really that simple. Though today I experimented on a
desktop machine which might have a real i8042 maybe. Under a combination of
2.6.0-test4 and X11, showkey -s produced the same results which showkey -s
used to produce under 2.4.something on a plain text console. Maybe this
proves that X11 still accesses the keyboard at a sufficiently low level that
it doesn't suffer from the breakage that was added in 2.6.0-test4 keyboard
drivers.

> I guess the keyboard is sending Set 2 and the BIOS is translating the set
> 2 codes to set 1 for "compatibility with XT software".

I'm pretty sure that this isn't that simple. The BIOS fails to translate
some keys. I hacked grub enough to make it possible to type from a Japanese
keyboard into grub. Fortunately grub doesn't use every key that the BIOS
understands, so I was able to swap some scan codes in grub's interrupt
handler, let the BIOS translate the ones it likes, and then translate the
results again in grub's higher-level translator.

(Now why does such ugly stuff make people want to puke on their keyboards
when it's really the BIOS's fault :-?)

2003-09-05 14:45:58

by John Bradford

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

> > At this late stage, I don't think it is a good idea to completely
> > rewrite the untranslate algorithm. So we continue to hack it and hack
> > it until it works. :-/
>
> Surely not. Some keyboards which worked since 2.0 and probably 1.something
> are broken in 2.6.

Aren't we over-complicating this?

The vast majority of keyboards are usable with translated Set 2, and
no workarounds. Some workarounds may break other keyboards, possibly
ones we don't even know about yet.

There are advantages to using untranslated Set 2, and Set 3, and some
keyboards need to be used in those modes them to work correctly.

So, why not:

* Default to translated Set 2 with no work arounds, unless the
keyboard is known to work fine in Set 3.

Either:

1. It works perfectly.
2. It doesn't.

In case 1, if the user is happy with translated Set 2, there is no
problem. If they are interested in seeing whether the technically
neater untranslated Set 2, or Set 3 work for them they can test them
and see.

In case 2, the user can boot with a kernel parameter enabling
workarounds for broken keyboards. Conflicting workarounds can be
moved in to different sets, I.E. boot with inputworkarounds=1 for the
most common ones, and inputworkarounds=2 for the less common ones.

This should get almost all keyboards working by default. Most of
those that don't work due to critical errors such as keys bouncing and
excessive auto-repeat, and those that don't work fully, should work
fully with workarounds enabled.

My keyboard which requires Set 3 to operate fully sends a distinctive
ID, so can be identified, and set to Set 3 automatically.

John.

2003-09-05 15:43:22

[permalink] [raw]

Subject: Re: keyboard - was: Re: Linux 2.6.0-test4

On Thu, Sep 04, 2003 at 11:41:38PM -0400, Chris Heath wrote:

> Well... I think the overall design is the right one. The atkbd driver
> expects to be talking to an AT keyboard, usually using Set 2.

Always be precise: there are six modes, namely
translated/untranslated Set 1/2/3.

By default every recent keyboard comes up in translated Set 2.
atkbd.c is broken, because it expects what the keyboard does not send,
namely untranslated Set 2.

{and here "send" is not defined as what bits are on some cable,
that is invisible for the programmer and varies between systems,
but as what bits get read by the kernel}

> However, the bytes that come from the i8042 are a mixture of Set 1 and
> Set 2. Set 1 because the key releases have their 8th bits set, and Set
> 2 because we get the non-XT keys escaped with E0. I guess the keyboard
> is sending Set 2 and the BIOS is translating the set 2 codes to set 1
> for "compatibility with XT software".

There are several misunderstandings in this paragraph.
No, the BIOS is not involved - Linux does not use the BIOS,
except possibly at boot time.
Both translated and untranslated Set 2 use E0 prefixes,
and E0 is translated to E0.

The translation is done by the keyboard controller.
On many laptops the strange construction of a keyboard that sends
the wrong codes, which then are translated by a separate microprocessor,
is thrown out, and the keyboard directly produces the desired codes,
namely translated Set 2, and no translation happens.
Also the compatibility mode of USB only knows about translated Set 2.

> So the i8042 layer is IMHO the right place to untranslate this mess back
> into normal Set 2.

There is nothing normal about this untranslated Set 2.
It is a figment of the imagination.
Laptop hardware doesnt know anything about it.

> The problem is that the translation is not invertible

Yes, indeed, so we introduce some small bugs by doing this silly
untranslation.

> The current algorithm is to untranslate all bytes 0x00-0x7f, and to
> untranslate the others only if there was a previous key press. This
> means the i8042 layer has to know about scancodes, knowledge which
> probably only belongs in the atkbd layer.

Yes, precisely.

> Probably, now that I think about it, the sanitization of duplicate key
> releases should rightfully be part of the atkbd layer, because those
> codes are actually being sent from the keyboard.

Yes, precisely.
And indeed, no sanitization is needed at all.

> But either way, the problem remains to find a good untranslate
> hack^Walgorithm. Because we are getting duplicate key releases, we have
> to make sure they they are either untranslated or removed. Sending them
> through unchanged, as we were in -test1 causes lots of grief to the
> atkbd layer.

But that is a bug in atkbd.

Andries

2003-09-05 23:45:22