Hi,
The following patch does, indeed, fix the ide_release_lock imbalance. No more
warnings.
--- drivers/ide/ide-io.c.orig 2008-06-27 20:11:42.000000000 +1200
+++ drivers/ide/ide-io.c 2008-06-27 20:32:50.000000000 +1200
@@ -1075,14 +1075,13 @@
Tested on 2.6.26-rc8 (of June 29 vintage), on the actual hardware, no
trouble. The kernel was built using atari_defconfig (and I haven't
actually finished installing all of the 167MB of modules ...).
multi_defconfig is too large to fit on a floppy, sorry.
Due to my quirky hardware, I still need a patch to atari_keyb_init to
prevent a crash there that I do not fully understand. I'd appreciate any
input on this:
To illustrate, this is the relevant objdump section for the crashing
function:
924a: 4fef 0014 lea %sp@(20),%sp
924e: 0238 ffbf fa09 andib #-65,fffffa09 <CC6_ENABLE_D+0x7ffffa09>
9254: 11fc ffbf fa0d moveb #-65,fffffa0d <CC6_ENABLE_D+0x7ffffa0d>
925a: 7401 moveq #1,%d2
925c: c4b9 0023 11c0 andl 2311c0 <atari_switches>,%d2
9262: 4281 clrl %d1
9264: 11fc 0040 fc00 moveb #64,fffffc00 <CC6_ENABLE_D+0x7ffffc00>
926a: 1038 fc00 moveb fffffc00 <CC6_ENABLE_D+0x7ffffc00>,%d0
926e: 1038 fc02 moveb fffffc02 <CC6_ENABLE_D+0x7ffffc02>,%d0
9272: 11fc 0040 fc04 moveb #64,fffffc04 <CC6_ENABLE_D+0x7ffffc04>
9278: 1038 fc04 moveb fffffc04 <CC6_ENABLE_D+0x7ffffc04>,%d0
927c: 1038 fc06 moveb fffffc06 <CC6_ENABLE_D+0x7ffffc06>,%d0
9280: 70d6 moveq #-42,%d0
9282: 4a82 tstl %d2
9284: 6602 bnes 9288 <atari_keyb_init+0x72>
9286: 7096 moveq #-106,%d0
9288: 11c0 fc00 moveb %d0,fffffc00 <CC6_ENABLE_D+0x7ffffc00>
928c: 11fc 0040 fc04 moveb #64,fffffc04 <CC6_ENABLE_D+0x7ffffc04>
9292: 1038 fa01 moveb fffffa01 <CC6_ENABLE_D+0x7ffffa01>,%d0
9296: 1200 moveb %d0,%d1
9298: 7010 moveq #16,%d0
929a: c081 andl %d1,%d0
The crash happens at 0x9288, and it is claimed to be a null pointer:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
Oops: 00000000
Modules linked in:
PC: [<00009288>] atari_keyb_init+0x72/0x11e
SR: 2308 SP: 00c19f24 a2: 00c17a80
d0: ffffff96 d1: 00000000 d2: 00000000 d3: 00000000
d4: 00000005 d5: 00000000 a0: 00000002 a1: 0021b830
Process swapper (pid: 1, task=00c17a80)
Frame format=4 fault addr=fffffc00 fslw=00a50010
even though the fault address is reported to be fffffc00 (key_ctrl, the
keyboard ACIA port).
When I explicitly avoid setting either ACIA_RHTID (2<<5) or ACIA_RLTID
(0<<5) bits on keyboard reset, in particular:
acia.key_ctrl = (ACIA_DIV64|ACIA_D8N1S|ACIA_RIE);
instead of
acia.key_ctrl = (ACIA_DIV64|ACIA_D8N1S|ACIA_RIE) |
((atari_switches & ATARI_SWITCH_IKBD) ?
ACIA_RHTID : ACIA_RLTID);
(atari_switches should be zero)
I get the following code which works fine:
9248: 4fef 0014 lea %sp@(20),%sp
924c: 0238 ffbf fa09 andib #-65,fffffa09 <CC6_ENABLE_D+0x7ffffa09>
9252: 11fc ffbf fa0d moveb #-65,fffffa0d <CC6_ENABLE_D+0x7ffffa0d>
9258: 4281 clrl %d1
925a: 11fc 0003 fc00 moveb #3,fffffc00 <CC6_ENABLE_D+0x7ffffc00>
9260: 1038 fc00 moveb fffffc00 <CC6_ENABLE_D+0x7ffffc00>,%d0
9264: 1038 fc02 moveb fffffc02 <CC6_ENABLE_D+0x7ffffc02>,%d0
9268: 11fc 0003 fc04 moveb #3,fffffc04 <CC6_ENABLE_D+0x7ffffc04>
926e: 1038 fc04 moveb fffffc04 <CC6_ENABLE_D+0x7ffffc04>,%d0
9272: 1038 fc06 moveb fffffc06 <CC6_ENABLE_D+0x7ffffc06>,%d0
9276: 11fc ff96 fc00 moveb #-106,fffffc00 <CC6_ENABLE_D+0x7ffffc00>
927c: 11fc 0015 fc04 moveb #21,fffffc04 <CC6_ENABLE_D+0x7ffffc04>
9282: 1038 fa01 moveb fffffa01 <CC6_ENABLE_D+0x7ffffa01>,%d0
9286: 1200 moveb %d0,%d1
9288: 7010 moveq #16,%d0
928a: c081 andl %d1,%d0
The same moveb #-106,fffffc00 at 0x9276 seems harmless now.
I am a bit confused about the
9264: 11fc 0040 fc00 moveb #64,fffffc00 <CC6_ENABLE_D+0x7ffffc00>
vs.
925a: 11fc 0003 fc00 moveb #3,fffffc00 <CC6_ENABLE_D+0x7ffffc00>
difference here as well - it appears gcc evaluates
acia.key_ctrl = ACIA_RESET |
(atari_switches & ATARI_SWITCH_IKBD) ? ACIA_RHTID : 0;
so (atari_switches & ATARI_SWITCH_IKBD) is always true?
Indeed, using
acia.key_ctrl = ACIA_RESET |
((atari_switches & ATARI_SWITCH_IKBD) ? ACIA_RHTID : 0);
I get either #3 or #67 as constants which seems much more sensible. Did C
operator precedences change recently? The code in question has been
unchanged since before 2.2, so why has it ever worked before?
Puzzled,
Michael
(and sure, I'll post a patch as soon as I've verified the corrected
operator precedence fixes my problem ...)
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
