All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Drake <dsd@gentoo.org>
To: Andrew Morton <akpm@osdl.org>
Cc: LKML <linux-kernel@vger.kernel.org>, linux-parport@lists.infradead.org
Subject: 2.6.16 doesn't boot with CONFIG_TIPAR=y
Date: Sun, 23 Apr 2006 12:06:41 +0100	[thread overview]
Message-ID: <444B5FC1.9090502@gentoo.org> (raw)

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

Hi Andrew,

Your commit titled "[PATCH] tipar fixes" breaks the boot of 2.6.16 and 
newer when CONFIG_TIPAR=y, and the appropriate parallel port driver is 
compiled-in, and the system has at least one parallel port.

The problem is as follows:

drivers/Makefile loads char/tipar.c early during boot (before any 
parport stuff).

tipar_init_module does some stuff and then reaches:
	if (parport_register_driver(&tipar_driver) || tp_count == 0) {
		destroy sysfs class
		return failure
	}

At this point, parport_register_driver() succeeds, but the tipar_attach 
function is *not* called as the parport system hasn't been initialised 
yet. This means that tp_count == 0, so we clean up a bit and return 
failure. Note that we do not unregister from the parport driver, so as 
far as parport is concerned, all is fine.

Later on, drivers/Makefile loads parport/*. parport then calls the 
tipar_attach function which we registered earlier, which then does some 
sysfs stuff. This is a problem because we destroyed the sysfs class 
earlier on.

This is the end result:

tipar: parallel link cable driver, version 1.19
tipar: unable to register with parport
initcall at 0xc03cf1c6: tipar_init_module+0x0/0xa1(): returned with 
error code -5
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
ppdev: user-space parallel port driver
Linux agpgart interface v0.101 (c) Dave Jones
[drm] Initialized drm 1.0.1 20051102
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16450
parport0: PC-style at 0x378 [PCSPP,EPP]
BUG: unable to handle kernel paging request at virtual address 00a0008f
  printing eip:
c0167263
*pde = 00000000
Oops: 0000 [#1]
Modules linked in:
CPU:    0
EIP:    0060:[<c0167263>]    Not tainted VLI
EFLAGS: 00000286   (2.6.17-rc2 #3)
EIP is at create_dir+0x15/0x165
eax: c12cedc8   ebx: c12cedcc   ecx: c12cedcc   edx: 00a00087
esi: 00000000   edi: c12cedcc   ebp: c113deac   esp: c113de8c
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 1, threadinfo=c113c000 task=c1139a10)
Stack: <0>00a00087 c12cedc8 c12cedc8 00000000 c12cedc8 c12768a0 c016740f 
c113deac
        00000000 c12cedc8 c019e611 c12cedc8 c12768b8 c019e7e5 c12cee38 
c12cedc0
        c12cedc8 c021986b ffffffea 00000000 00000000 c12cedc0 fffffff4 
c12768a0
Call Trace:
  <c016740f> sysfs_create_dir+0x4b/0x5d   <c019e611> create_dir+0x10/0x2f
  <c019e7e5> kobject_add+0x90/0xd8   <c021986b> class_device_add+0x9b/0x1dc
  <c0219a32> class_device_create+0x76/0x8c   <c01f562e> 
tipar_register+0x52/0x9e
  <c01f569a> tipar_attach+0x20/0x33   <c02123b5> 
attach_driver_chain+0x21/0x2e
  <c0212751> parport_announce_port+0x72/0x94   <c0216aca> 
parport_pc_probe_port+0x428/0x496
  <c0217475> parport_pc_find_isa_ports+0x3c/0x67   <c03d0004> 
parport_pc_find_ports+0x14/0x37
  <c03d03de> parport_pc_init+0x7f/0x86   <c03be67f> do_initcalls+0x53/0xda
  <c0163422> proc_mkdir_mode+0x37/0x49   <c010027c> init+0x0/0x118
  <c01002ae> init+0x32/0x118   <c0100cbd> kernel_thread_helper+0x5/0xb
Code: 00 00 00 e5 2d c0 31 c0 c3 c7 80 88 00 00 00 40 f7 34 c0 31 c0 c3 
55 57 56 53 53 53 89 cb 8b 6c 24 1c 89 df 89 14 24 89 44 24 04 <8b> 42 
08 83 c0 70 e8 83 16 17 00 31 c0 83 c9 ff f2 ae f7 d1 49
EIP: [<c0167263>] create_dir+0x15/0x165 SS:ESP 0068:c113de8c
  <0>Kernel panic - not syncing: Attempted to kill init!

I've attached a patch to solve this, but I'm not sure if it is correct: 
it reverts part of your patch. From the description it sounds like this 
path may be covered by your changes in tipar_open() so maybe it is OK...

[-- Attachment #2: tipar-boot-oops.patch --]
[-- Type: text/x-patch, Size: 834 bytes --]

[PATCH] Fix tipar/parport boot crash

If compiled into the kernel, parport_register_driver() is called before the
parport driver has been initalised.

This means that it is expected that tp_count is 0 after the
parport_register_driver() call() - tipar's attach function will not be called
until later during bootup.

Signed-off-by: Daniel Drake <dsd@gentoo.org>

--- linux-2.6.17-rc2/drivers/char/tipar.c.orig	2006-04-23 12:03:08.000000000 +0100
+++ linux-2.6.17-rc2/drivers/char/tipar.c	2006-04-23 11:42:30.000000000 +0100
@@ -515,7 +515,7 @@ tipar_init_module(void)
 		err = PTR_ERR(tipar_class);
 		goto out_chrdev;
 	}
-	if (parport_register_driver(&tipar_driver) || tp_count == 0) {
+	if (parport_register_driver(&tipar_driver)) {
 		printk(KERN_ERR "tipar: unable to register with parport\n");
 		err = -EIO;
 		goto out_class;

                 reply	other threads:[~2006-04-23 10:52 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=444B5FC1.9090502@gentoo.org \
    --to=dsd@gentoo.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parport@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.