Distribution: SuSE Linux Hardware Environment: PowerMac 7200, 2 pmac serial lines, no 8250/16550 lines Software Environment: gcc3.2.3 Problem Description: ppc32 has a socalled common config which includes drivers for PC style hardware, used on PReP and CHRP systems, and drivers for Macintosh (CONFIG_ALL_PPC in 2.4). this includes also drivers for serial console. CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_SERIAL_PMACZILOG_CONSOLE=y This config fails to open /dev/console in init/main.c, call trace is: sys_open -> filp_open -> dentry_open -> chrdev_open -> tty_open -> init_dev driver->ttys contains NULL. The struct tty_driver passed to init_dev() is allocated in the 8250 driver: ... Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled uart_register_driver: c0322d58 alloc_tty_driver: d c470de00 uart_register_driver: c0324388 alloc_tty_driver: d c470dc00 Using anticipatory io scheduler ... VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory:<7>IN from bad port 3f9 at c0160600 184k init<7>IN from bad port 3f9 at c0160600 4k chrp<7>IN from bad port 3f9 at c0160600 36k prep<7>IN from bad port 3f9 at c0160600 kobj_lookup: owner 00000000 data c04166e4 probe c006822c init_dev: d c470dc00 i 0 Serial port locked ON by debugger ! vector: 301 at pc = c0148254, lr = c0148250 msr = 9030, sp = c47b1dc0 [c47b1d10] dar = 0, dsisr = 40000000 current = c47af740, pid = 1, comm = swapper ... The 2.4 kernel has some workaround to shift the minor numbers for the 8250 driver: drivers/char/serial.c:#define SERIAL_DEV_OFFSET ((_machine == _MACH_prep || _machine == _MACH_chrp) ? 0 : 2) Maybe something similar is required also for 2.6? I fail to see how to apply the SERIAL_DEV_OFFSET scheme to 2.6. One thing to note, all these "<7>IN from bad port 3f9 at c0160600" may indicate that the 8250 probing is not yet done. Steps to reproduce: compile a kernel with the config above and boot it on an oldworld powermac. it will die while opening /dev/console
this looks like a valid workaround. --- linuxppc-2.5_2.6.0-test9-bk/drivers/serial/8250.c 2003-10-23 00:25:21.000000000 +0200 +++ ./drivers/serial/8250.c 2003-11-28 23:50:22.000000000 +0100 @@ -45,6 +45,10 @@ #include <linux/serial_core.h> #include "8250.h" +#ifdef CONFIG_PPC_MULTIPLATFORM +#include <asm/processor.h> +#endif + /* * Configuration: * share_irqs - whether we pass SA_SHIRQ to request_irq(). This option @@ -2008,6 +2044,12 @@ static struct console serial8250_console static int __init serial8250_console_init(void) { +#ifdef CONFIG_PPC_MULTIPLATFORM + if(_machine == _MACH_Pmac) { + printk("%s: nothing to do on PowerMac\n",__FUNCTION__); + return -ENODEV; + } +#endif serial8250_isa_init_ports(); register_console(&serial8250_console); return 0;
Is this still a bug in, say, 2.6.12 or 2.6.13-rc3? Thanks, Nish
yes, reason is the tty layer, one can not request a specific name and major/minor pair.
Russell, Any comments on this patch? Is it acceptable for mainline? Thanks, Nish
I have no interest in bastardising the serial driver to cope with drivers which want to re-use a validly assigned major/minor and name. Why? Because if we start allowing this, other folk want to do the same. Then SERIAL_DEV_OFFSET becomes a horrible mess of "if this machine then 2 else if that machine then 3 else if some other machine then 4 else 0." It's also completely wrong to mislead the user into thinking that console=ttyS2 will attach the console to their 8250-based port with this solution. It won't. Also, preventing the console initialising in 8250.c won't stop it being registered. The serial core registers the 8250 console when the correct port is added. And no, why the fsck should we bastardise the serial core layer as well to cope with this? All round, this is _not_ workable or maintainable. Why not just do as everyone else does and get a proper major/minor/name allocated for the pmac driver? Or, if you do want to re-use the 8250 drivers regions, maybe spend some time sorting out the char+tty layer so we can dynamically allocate ttys without having to have prior knowledge of the number of minor numbers we require. Currently, to do that means we have to register one tty_drver per tty device. Which is obviously not scalable. It is rather unfortunate that pmac was allowed to ever introduce this disgusting hack.
Olaf, Do you have any response to Russell? Or can I go ahead and reject the bug? Maybe this discussion should be happening on LKML, not Bugzilla? or linux-serial? Thanks, Nish
This is a valid bugreport. I will work on it as time permits. Having a dynamic major/minor assignment for such setups, or in general, seems to be the correct way.
David suggested a rename of the kernel device name. http://lkml.org/lkml/2007/4/3/316
Any update on this, was it materialized? (I should probably look in the git...but it's getting late) Sorry, maybe quick update Olaf? Thanks.
Maybe David can respin his device rename patch.
http://lkml.org/lkml/2007/4/4/211 should do it just fine, although I believe Paulus would like it rephrased to not use the word 'abuse'.
See commit e4533b243e5e0c3a26287a902a1ed0f8f5b1cec0 in Linus' tree.