David Miller wrote: > The sunzilog change, hmmm... :) > > This code works on my SBUS sparc64 machines using zilog serial, > so I wonder what's going wrong. > > The sunzilog_alloc_tables() sets up the global list > sunzilog_irq_chain. > > All the zilogs hang off of a single interrupt, and therefore > we need that interrupt to process all zilogs in the system. > That's why we pass sunzilog_irq_chain to request_irq(). > > I double checked the prtconf for a typical SS20 machine, > and both zilog devices have an identical IRQ specification. > > This is identical to the behavior of the driver before I made > any changes, for example in 2.6.17. > > What could be happening is that the interrupt hits before the > start of the UART struct and device are fully setup. Perhaps > more of the uart_sunzilog_port initialization should be moved > into sunzilog_alloc_tables(), but there are critical things > we cannot initialize there because we don't have the of_device > object handy yet. > > Ok, I think I see what's happening. We register sunzilog_interrupt > before things like up->port.membase are fully setup. We init > the first port, by calling sunzilog_init_hw() and that makes > the chip interrupt, I guess. If that happens, the interrupt > handler will try to read the channel registers of the other > port as well, the pointer to which is still NULL. > > Bob, can you confirm this is what is happening by putting some > NULL checks in sunzilog_interrupt or similar? I was debugging with a serial console, so maybe that caused it to fail easier. It triggered an interrupt before initializing the 2nd chip and ZILOG_CHANNEL_FROM_PORT() was getting a NULL pointer in the interrupt routine when it looped to the 2nd chip. Bob - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
