* IP22 doesn't shutdown properly
@ 2006-02-17 22:58 Martin Michlmayr
2006-02-18 1:19 ` Kumba
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Martin Michlmayr @ 2006-02-17 22:58 UTC (permalink / raw)
To: linux-mips; +Cc: jblache
When you try to shutdown or reboot an IP22 with 2.6.15 or 2.6.16-rc2,
you see that the TERM signal is sent but then nothing happens. At the
beginning, the light on the Indy is green but after about 20 seconds
it turns red. Nothing happens on the console and the machine doesn't
turn off. Seen on Indy and Indigo2.
Anyone got a fix?
sgi:~# shutdown -r now
Broadcast message from root (ttyS0) (Fri Feb 17 22:52:47 2006):
The system is going down for reboot NOW!
INIT: Sending processes the TERM signal
INIT: Sending proces
[and nothing more]
Or, according to an Indigo2 users, "The machine hangs on shutdown -r
now after init sends the TERM signal; the LED stays green for a few
seconds, then turns orange which definitely isn't good."
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: IP22 doesn't shutdown properly 2006-02-17 22:58 IP22 doesn't shutdown properly Martin Michlmayr @ 2006-02-18 1:19 ` Kumba 2006-02-18 1:27 ` Martin Michlmayr 2006-02-19 16:52 ` Ralf Baechle 2006-02-23 22:13 ` Martin Michlmayr 2 siblings, 1 reply; 26+ messages in thread From: Kumba @ 2006-02-18 1:19 UTC (permalink / raw) To: linux-mips; +Cc: jblache Martin Michlmayr wrote: > When you try to shutdown or reboot an IP22 with 2.6.15 or 2.6.16-rc2, > you see that the TERM signal is sent but then nothing happens. At the > beginning, the light on the Indy is green but after about 20 seconds > it turns red. Nothing happens on the console and the machine doesn't > turn off. Seen on Indy and Indigo2. > > Anyone got a fix? > > > sgi:~# shutdown -r now > > Broadcast message from root (ttyS0) (Fri Feb 17 22:52:47 2006): > > The system is going down for reboot NOW! > INIT: Sending processes the TERM signal > INIT: Sending proces > > [and nothing more] > > Or, according to an Indigo2 users, "The machine hangs on shutdown -r > now after init sends the TERM signal; the LED stays green for a few > seconds, then turns orange which definitely isn't good." Turns red/orange and stays that color, or starts flashing? --Kumba -- Gentoo/MIPS Team Lead Gentoo Foundation Board of Trustees "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-18 1:19 ` Kumba @ 2006-02-18 1:27 ` Martin Michlmayr 2006-02-18 10:36 ` Julien BLACHE 0 siblings, 1 reply; 26+ messages in thread From: Martin Michlmayr @ 2006-02-18 1:27 UTC (permalink / raw) To: Kumba; +Cc: linux-mips, jblache * Kumba <kumba@gentoo.org> [2006-02-17 20:19]: > >now after init sends the TERM signal; the LED stays green for a few > >seconds, then turns orange which definitely isn't good." > > Turns red/orange and stays that color, or starts flashing? Stays the same colour. By the way, Stephen Becker mentioned on IRC that he sees the same - but *only* when he uses serial console, not fb (sounds a bit odd to me, but maybe someone can make sense of this). -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-18 1:27 ` Martin Michlmayr @ 2006-02-18 10:36 ` Julien BLACHE 0 siblings, 0 replies; 26+ messages in thread From: Julien BLACHE @ 2006-02-18 10:36 UTC (permalink / raw) To: Martin Michlmayr; +Cc: Kumba, linux-mips Martin Michlmayr <tbm@cyrius.com> wrote: Hi, > By the way, Stephen Becker mentioned on IRC that he sees the same - > but *only* when he uses serial console, not fb (sounds a bit odd to > me, but maybe someone can make sense of this). Same for me on my I2, hangs on serial console, works fine on fb (shutdown, reboot not tested in this configuration). JB. -- Julien BLACHE <jblache@debian.org> | Debian, because code matters more Debian & GNU/Linux Developer | <http://www.debian.org> Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-17 22:58 IP22 doesn't shutdown properly Martin Michlmayr 2006-02-18 1:19 ` Kumba @ 2006-02-19 16:52 ` Ralf Baechle 2006-02-20 18:12 ` Martin Michlmayr 2006-02-23 22:13 ` Martin Michlmayr 2 siblings, 1 reply; 26+ messages in thread From: Ralf Baechle @ 2006-02-19 16:52 UTC (permalink / raw) To: Martin Michlmayr; +Cc: linux-mips, jblache On Fri, Feb 17, 2006 at 10:58:24PM +0000, Martin Michlmayr wrote: > When you try to shutdown or reboot an IP22 with 2.6.15 or 2.6.16-rc2, > you see that the TERM signal is sent but then nothing happens. At the > beginning, the light on the Indy is green but after about 20 seconds > it turns red. Nothing happens on the console and the machine doesn't > turn off. Seen on Indy and Indigo2. > > Anyone got a fix? No. Do you know when this problems started? Ralf ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-19 16:52 ` Ralf Baechle @ 2006-02-20 18:12 ` Martin Michlmayr 2006-02-20 21:55 ` Ralf Baechle 2006-02-21 13:59 ` Thiemo Seufer 0 siblings, 2 replies; 26+ messages in thread From: Martin Michlmayr @ 2006-02-20 18:12 UTC (permalink / raw) To: Ralf Baechle; +Cc: linux-mips, jblache * Ralf Baechle <ralf@linux-mips.org> [2006-02-19 16:52]: > > beginning, the light on the Indy is green but after about 20 seconds > > it turns red. Nothing happens on the console and the machine doesn't > > turn off. Seen on Indy and Indigo2. > > Anyone got a fix? > No. Do you know when this problems started? A long time ago, it seems. I can trace it back to 2.6.9; unfortunately I don't get any older kernel to run/compile, possibily because my toolchain isn't old enough (I even installed the SDE that's based on 3.3). Here's what I got: 2.6.15 - broken 2.6.14 - broken 2.6.13 - broken 2.6.10 - broken 2.6.9 - broken 2.6.8 - hangs after download (SDE) 2.6.6 - hangs after download (SDE) 2.6.5 - hangs after download (SDE) 2.6.4 - hangs after download (SDE) 2.6.3 - fails to load with: Text start 0x8000000, size 0x25e998 doesn't fit in a FreeMemory area. 2.6.1 - doesn't compile -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-20 18:12 ` Martin Michlmayr @ 2006-02-20 21:55 ` Ralf Baechle 2006-02-21 13:59 ` Thiemo Seufer 1 sibling, 0 replies; 26+ messages in thread From: Ralf Baechle @ 2006-02-20 21:55 UTC (permalink / raw) To: Martin Michlmayr; +Cc: linux-mips, jblache On Mon, Feb 20, 2006 at 06:12:27PM +0000, Martin Michlmayr wrote: > Date: Mon, 20 Feb 2006 18:12:27 +0000 > From: Martin Michlmayr <tbm@cyrius.com> > To: Ralf Baechle <ralf@linux-mips.org> > Cc: linux-mips@linux-mips.org, jblache@debian.org > Subject: Re: IP22 doesn't shutdown properly > Content-Type: text/plain; charset=us-ascii > > * Ralf Baechle <ralf@linux-mips.org> [2006-02-19 16:52]: > > > beginning, the light on the Indy is green but after about 20 seconds > > > it turns red. Nothing happens on the console and the machine doesn't > > > turn off. Seen on Indy and Indigo2. > > > Anyone got a fix? > > No. Do you know when this problems started? > > A long time ago, it seems. I can trace it back to 2.6.9; > unfortunately I don't get any older kernel to run/compile, possibily > because my toolchain isn't old enough (I even installed the SDE that's > based on 3.3). > > Here's what I got: > > 2.6.15 - broken > 2.6.14 - broken > 2.6.13 - broken > 2.6.10 - broken > 2.6.9 - broken > 2.6.8 - hangs after download (SDE) > 2.6.6 - hangs after download (SDE) > 2.6.5 - hangs after download (SDE) > 2.6.4 - hangs after download (SDE) > 2.6.3 - fails to load with: Text start 0x8000000, size 0x25e998 doesn't > fit in a FreeMemory area. Somehow this all sounds suspicious. I ran at least a few of those kernels on my own Indy. > 2.6.1 - doesn't compile Okay, I had to try this one. Clear case of bitrot. Don't use fancy new compilers with that kernel, it doesn't like them. Ralf ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-20 18:12 ` Martin Michlmayr 2006-02-20 21:55 ` Ralf Baechle @ 2006-02-21 13:59 ` Thiemo Seufer 2006-02-21 14:23 ` Stephen P. Becker 1 sibling, 1 reply; 26+ messages in thread From: Thiemo Seufer @ 2006-02-21 13:59 UTC (permalink / raw) To: Martin Michlmayr; +Cc: Ralf Baechle, linux-mips, jblache On Mon, Feb 20, 2006 at 06:12:27PM +0000, Martin Michlmayr wrote: > * Ralf Baechle <ralf@linux-mips.org> [2006-02-19 16:52]: > > > beginning, the light on the Indy is green but after about 20 seconds > > > it turns red. Nothing happens on the console and the machine doesn't > > > turn off. Seen on Indy and Indigo2. > > > Anyone got a fix? > > No. Do you know when this problems started? > > A long time ago, it seems. I can trace it back to 2.6.9; > unfortunately I don't get any older kernel to run/compile, possibily > because my toolchain isn't old enough (I even installed the SDE that's > based on 3.3). ISTR my 2.6.12 works for Indy shutdown (That's with gcc-4.0). Thiemo ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-21 13:59 ` Thiemo Seufer @ 2006-02-21 14:23 ` Stephen P. Becker 2006-02-21 14:31 ` Thiemo Seufer 0 siblings, 1 reply; 26+ messages in thread From: Stephen P. Becker @ 2006-02-21 14:23 UTC (permalink / raw) To: Thiemo Seufer; +Cc: Martin Michlmayr, Ralf Baechle, linux-mips, jblache Thiemo Seufer wrote: > On Mon, Feb 20, 2006 at 06:12:27PM +0000, Martin Michlmayr wrote: >> * Ralf Baechle <ralf@linux-mips.org> [2006-02-19 16:52]: >>>> beginning, the light on the Indy is green but after about 20 seconds >>>> it turns red. Nothing happens on the console and the machine doesn't >>>> turn off. Seen on Indy and Indigo2. >>>> Anyone got a fix? >>> No. Do you know when this problems started? >> A long time ago, it seems. I can trace it back to 2.6.9; >> unfortunately I don't get any older kernel to run/compile, possibily >> because my toolchain isn't old enough (I even installed the SDE that's >> based on 3.3). > > ISTR my 2.6.12 works for Indy shutdown (That's with gcc-4.0). Now is that with newport or serial console? I was only able to reproduce this when using serial console...and even that is hit or miss. The last time I pulled out my r4400 indy to do some kernel testing, this was a major pain in my ass. Basically, I could log into serial console, do some stuff, enter the reboot command from there, and everything would be just fine. However, if I had a serial connection and a ssh connection at the same time, and I issued the reboot command from my ssh connection, the machine would hang exactly in the way which has been described (sits there for about 20 seconds doing nothing, and then the red light comes on). Hmm...now that I think about it some more, I want to say that rebooting the machine would hang as long as there was a getty process running on a serial port, whether or not I had ever logged in over serial. For what it's worth, I also use gcc-4 to build my kernels. -Steve ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-21 14:23 ` Stephen P. Becker @ 2006-02-21 14:31 ` Thiemo Seufer 2006-02-23 21:14 ` Martin Michlmayr 0 siblings, 1 reply; 26+ messages in thread From: Thiemo Seufer @ 2006-02-21 14:31 UTC (permalink / raw) To: Stephen P. Becker; +Cc: Martin Michlmayr, Ralf Baechle, linux-mips, jblache On Tue, Feb 21, 2006 at 09:23:14AM -0500, Stephen P. Becker wrote: > Thiemo Seufer wrote: > >On Mon, Feb 20, 2006 at 06:12:27PM +0000, Martin Michlmayr wrote: > >>* Ralf Baechle <ralf@linux-mips.org> [2006-02-19 16:52]: > >>>>beginning, the light on the Indy is green but after about 20 seconds > >>>>it turns red. Nothing happens on the console and the machine doesn't > >>>>turn off. Seen on Indy and Indigo2. > >>>>Anyone got a fix? > >>>No. Do you know when this problems started? > >>A long time ago, it seems. I can trace it back to 2.6.9; > >>unfortunately I don't get any older kernel to run/compile, possibily > >>because my toolchain isn't old enough (I even installed the SDE that's > >>based on 3.3). > > > >ISTR my 2.6.12 works for Indy shutdown (That's with gcc-4.0). > > Now is that with newport or serial console? I was only able to > reproduce this when using serial console...and even that is hit or miss. > The last time I pulled out my r4400 indy to do some kernel testing, > this was a major pain in my ass. ISTR I tried both R4400 with newport and R4600 with serial. Thiemo ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-21 14:31 ` Thiemo Seufer @ 2006-02-23 21:14 ` Martin Michlmayr 0 siblings, 0 replies; 26+ messages in thread From: Martin Michlmayr @ 2006-02-23 21:14 UTC (permalink / raw) To: Thiemo Seufer; +Cc: linux-mips * Thiemo Seufer <ths@networkno.de> [2006-02-21 14:31]: > ISTR I tried both R4400 with newport and R4600 with serial. Interestingly enough, it powers down properly with your package, even when I recompile it. But when I apply your patches again 2.6.12 git, it still doesn't work. There's still a large chunk of differences between the Debian tree and git (2.6.12) and I don't have time right now to look more closely. Going to FOSDEM tomorrow. -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-17 22:58 IP22 doesn't shutdown properly Martin Michlmayr 2006-02-18 1:19 ` Kumba 2006-02-19 16:52 ` Ralf Baechle @ 2006-02-23 22:13 ` Martin Michlmayr 2006-02-23 22:43 ` Russell King 2006-02-24 19:05 ` Christoph Hellwig 2 siblings, 2 replies; 26+ messages in thread From: Martin Michlmayr @ 2006-02-23 22:13 UTC (permalink / raw) To: linux-mips; +Cc: jblache, rmk+serial * Martin Michlmayr <tbm@cyrius.com> [2006-02-17 22:58]: > When you try to shutdown or reboot an IP22 with 2.6.15 or 2.6.16-rc2, > you see that the TERM signal is sent but then nothing happens. At the > beginning, the light on the Indy is green but after about 20 seconds > it turns red. Nothing happens on the console and the machine doesn't > turn off. Seen on Indy and Indigo2. [and, as mentioned later, this only happens on serial, not when using the bf] I've tracked down now while the old 2.6.12 Debian package shut down correctly while no recent git does. The following simple change to the serial driver makes the difference for me: --- a/drivers/serial/serial_core.c~ 2006-02-23 21:58:51.000000000 +0000 +++ b/drivers/serial/serial_core.c 2006-02-23 21:59:14.000000000 +0000 @@ -108,7 +108,8 @@ static void uart_tasklet_action(unsigned long data) { struct uart_state *state = (struct uart_state *)data; - tty_wakeup(state->info->tty); + if (state->info->tty) + tty_wakeup(state->info->tty); } static inline void I cannot easily check why this change was in Debian's 2.6.12 package nor why it's not in Linus' git. Russell, can you say whether this change looks obviously good to you? If not, I can dig some more and see why this change was in our 2.6.12 package. In any case, with this patch applied, the SGI Indy in serial mode powers down correctly. Without the patch, it stops as in the example below and never turns off: > sgi:~# shutdown -r now > > Broadcast message from root (ttyS0) (Fri Feb 17 22:52:47 2006): > > The system is going down for reboot NOW! > INIT: Sending processes the TERM signal > INIT: Sending proces This is with: CONFIG_SERIAL_IP22_ZILOG=y CONFIG_SERIAL_IP22_ZILOG_CONSOLE=y CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-23 22:13 ` Martin Michlmayr @ 2006-02-23 22:43 ` Russell King 2006-02-24 0:39 ` Martin Michlmayr 2006-02-24 19:05 ` Christoph Hellwig 1 sibling, 1 reply; 26+ messages in thread From: Russell King @ 2006-02-23 22:43 UTC (permalink / raw) To: Martin Michlmayr; +Cc: linux-mips, jblache On Thu, Feb 23, 2006 at 10:13:50PM +0000, Martin Michlmayr wrote: > I've tracked down now while the old 2.6.12 Debian package shut down > correctly while no recent git does. The following simple change to > the serial driver makes the difference for me: > > --- a/drivers/serial/serial_core.c~ 2006-02-23 21:58:51.000000000 +0000 > +++ b/drivers/serial/serial_core.c 2006-02-23 21:59:14.000000000 +0000 > @@ -108,7 +108,8 @@ > static void uart_tasklet_action(unsigned long data) > { > struct uart_state *state = (struct uart_state *)data; > - tty_wakeup(state->info->tty); > + if (state->info->tty) > + tty_wakeup(state->info->tty); > } > > static inline void > > I cannot easily check why this change was in Debian's 2.6.12 package > nor why it's not in Linus' git. Russell, can you say whether this > change looks obviously good to you? If not, I can dig some more and > see why this change was in our 2.6.12 package. This looks like a case of a fix to work around some bad behaviour in a driver. When serial_core calls the drivers shutdown() method, it expects that will shut the driver up completely - no further interrupts from that point in, no further calls from the driver into the tty or serial_core subsystems for this port. Once the drivers shutdown() method has returned, we ensure there are no pending interrupts, and then kill off the tasklet. Sometime later, we NULL state->info->tty. Hence, if you're seeing a call into uart_tasklet_action() with a NULL tty, that means some driver called uart_write_wakeup() _after_ its shutdown method completed. That's a driver bug, not a serial_core bug - as I say above, the above patch is a workaround for a buggy driver. Looking at the ip22 driver, it seems that if shutdown() is called for the console port, the driver does _nothing_. That's the bug - it will still call (eg) uart_write_wakeup() after shutdown(), which is a violation of the assumptions (set out above). I would not be surprised therefore if you got an oops. What I might consider is a patch to add BUG_ON(!info->tty) in uart_write_wakeup() to catch these cases earlier and to provide folk with a better hint that the bug is _not_ in the core serial driver. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-23 22:43 ` Russell King @ 2006-02-24 0:39 ` Martin Michlmayr 2006-02-24 1:30 ` Kumba 2006-02-24 8:31 ` Russell King 0 siblings, 2 replies; 26+ messages in thread From: Martin Michlmayr @ 2006-02-24 0:39 UTC (permalink / raw) To: Russell King; +Cc: linux-mips, jblache * Russell King <rmk@arm.linux.org.uk> [2006-02-23 22:43]: > Looking at the ip22 driver, it seems that if shutdown() is called for > the console port, the driver does _nothing_. sunzilog.c does the same, and it's based on a comment by you (quoted right before shutdown()). Anyway, I don't quite understand the comment but maybe Ralf (or you) can write a patch. -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-24 0:39 ` Martin Michlmayr @ 2006-02-24 1:30 ` Kumba 2006-02-24 8:31 ` Russell King 1 sibling, 0 replies; 26+ messages in thread From: Kumba @ 2006-02-24 1:30 UTC (permalink / raw) To: linux-mips; +Cc: jblache Martin Michlmayr wrote: > * Russell King <rmk@arm.linux.org.uk> [2006-02-23 22:43]: >> Looking at the ip22 driver, it seems that if shutdown() is called for >> the console port, the driver does _nothing_. > > sunzilog.c does the same, and it's based on a comment by you (quoted > right before shutdown()). Anyway, I don't quite understand the > comment but maybe Ralf (or you) can write a patch. iirc, ip22zilog was based heavily off of sunzilog in the early days of the 2.6.x port. So I wouldn't be surprised if both contain similar sets of bugs. Probably be interesting to see if the Sparc people found any more and fixed that might still exist in ip22zilog. --Kumba -- Gentoo/MIPS Team Lead Gentoo Foundation Board of Trustees "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-24 0:39 ` Martin Michlmayr 2006-02-24 1:30 ` Kumba @ 2006-02-24 8:31 ` Russell King 2006-02-27 10:54 ` Martin Michlmayr 1 sibling, 1 reply; 26+ messages in thread From: Russell King @ 2006-02-24 8:31 UTC (permalink / raw) To: Martin Michlmayr; +Cc: linux-mips, jblache On Fri, Feb 24, 2006 at 12:39:47AM +0000, Martin Michlmayr wrote: > * Russell King <rmk@arm.linux.org.uk> [2006-02-23 22:43]: > > Looking at the ip22 driver, it seems that if shutdown() is called for > > the console port, the driver does _nothing_. > > sunzilog.c does the same, and it's based on a comment by you (quoted > right before shutdown()). Anyway, I don't quite understand the > comment but maybe Ralf (or you) can write a patch. Not quite - I didn't say "do absolutely nothing" - I did explicitly say that something should happen on the software side, and gave the example that the IRQ should be freed. The intention of that comment was to satisfy the requirement I mentioned in my previous mail in this thread. At a guess, for the console port, you want to disable the receiver, leave the transmitter enabled, and disable all interrupts originating from the port. How other drivers do it is that they do a normal shutdown in every case, but the console code explicitly re-enables the transmitter. I don't understand why these two drivers can't do it the same way. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-24 8:31 ` Russell King @ 2006-02-27 10:54 ` Martin Michlmayr 0 siblings, 0 replies; 26+ messages in thread From: Martin Michlmayr @ 2006-02-27 10:54 UTC (permalink / raw) To: Russell King; +Cc: linux-mips, jblache * Russell King <rmk@arm.linux.org.uk> [2006-02-24 08:31]: > Not quite - I didn't say "do absolutely nothing" - I did explicitly say ... > At a guess, for the console port, you want to disable the receiver, leave > the transmitter enabled, and disable all interrupts originating from the > port. I tried to implement this suggestion but it still fails. Note that I'm a complete kernel newbie so maybe I just did something wrong. In any case, the other fix I just sent (taken from sunzilog) works. For the record, what I initially tried (but which doesn't work) was: diff --git a/drivers/serial/ip22zilog.c b/drivers/serial/ip22zilog.c index 419dd3c..2bda770 100644 --- a/drivers/serial/ip22zilog.c +++ b/drivers/serial/ip22zilog.c @@ -747,20 +747,23 @@ static void ip22zilog_shutdown(struct ua struct zilog_channel *channel; unsigned long flags; - if (ZS_IS_CONS(up)) - return; - spin_lock_irqsave(&port->lock, flags); channel = ZILOG_CHANNEL_FROM_PORT(port); - /* Disable receiver and transmitter. */ + /* Disable receiver. */ up->curregs[R3] &= ~RxENAB; - up->curregs[R5] &= ~TxENAB; - - /* Disable all interrupts and BRK assertion. */ + /* Disable all interrupts. */ up->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK); - up->curregs[R5] &= ~SND_BRK; + /* For the console port, we want to disable the receiver, leave + * the transmitter enabled, and disable all interrupts originating + * from the port. */ + if (!ZS_IS_CONS(up)) { + /* Disable transmitter. */ + up->curregs[R5] &= ~TxENAB; + /* Disable BRK assertion. */ + up->curregs[R5] &= ~SND_BRK; + } ip22zilog_maybe_update_regs(up, channel); spin_unlock_irqrestore(&port->lock, flags); diff --git a/drivers/serial/sunzilog.c b/drivers/serial/sunzilog.c index 5cc4d4c..63cdf9d 100644 --- a/drivers/serial/sunzilog.c +++ b/drivers/serial/sunzilog.c @@ -834,20 +834,23 @@ static void sunzilog_shutdown(struct uar struct zilog_channel __iomem *channel; unsigned long flags; - if (ZS_IS_CONS(up)) - return; - spin_lock_irqsave(&port->lock, flags); channel = ZILOG_CHANNEL_FROM_PORT(port); - /* Disable receiver and transmitter. */ + /* Disable receiver. */ up->curregs[R3] &= ~RxENAB; - up->curregs[R5] &= ~TxENAB; - - /* Disable all interrupts and BRK assertion. */ + /* Disable all interrupts. */ up->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK); - up->curregs[R5] &= ~SND_BRK; + /* For the console port, we want to disable the receiver, leave + * the transmitter enabled, and disable all interrupts originating + * from the port. */ + if (!ZS_IS_CONS(up)) { + /* Disable transmitter. */ + up->curregs[R5] &= ~TxENAB; + /* Disable BRK assertion. */ + up->curregs[R5] &= ~SND_BRK; + } sunzilog_maybe_update_regs(up, channel); spin_unlock_irqrestore(&port->lock, flags); -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-23 22:13 ` Martin Michlmayr 2006-02-23 22:43 ` Russell King @ 2006-02-24 19:05 ` Christoph Hellwig 2006-02-27 10:51 ` Martin Michlmayr 2006-02-27 10:52 ` Martin Michlmayr 1 sibling, 2 replies; 26+ messages in thread From: Christoph Hellwig @ 2006-02-24 19:05 UTC (permalink / raw) To: Martin Michlmayr; +Cc: linux-mips, jblache, rmk+serial On Thu, Feb 23, 2006 at 10:13:50PM +0000, Martin Michlmayr wrote: > * Martin Michlmayr <tbm@cyrius.com> [2006-02-17 22:58]: > > When you try to shutdown or reboot an IP22 with 2.6.15 or 2.6.16-rc2, > > you see that the TERM signal is sent but then nothing happens. At the > > beginning, the light on the Indy is green but after about 20 seconds > > it turns red. Nothing happens on the console and the machine doesn't > > turn off. Seen on Indy and Indigo2. > [and, as mentioned later, this only happens on serial, not when using > the bf] > > I've tracked down now while the old 2.6.12 Debian package shut down > correctly while no recent git does. The following simple change to > the serial driver makes the difference for me: > > --- a/drivers/serial/serial_core.c~ 2006-02-23 21:58:51.000000000 +0000 > +++ b/drivers/serial/serial_core.c 2006-02-23 21:59:14.000000000 +0000 > @@ -108,7 +108,8 @@ > static void uart_tasklet_action(unsigned long data) > { > struct uart_state *state = (struct uart_state *)data; > - tty_wakeup(state->info->tty); > + if (state->info->tty) > + tty_wakeup(state->info->tty); > } > > static inline void > > I cannot easily check why this change was in Debian's 2.6.12 package > nor why it's not in Linus' git. Russell, can you say whether this > change looks obviously good to you? If not, I can dig some more and > see why this change was in our 2.6.12 package. This patch was dropped when a real fix went into one of the sun serial drivers with which this issue was seen before. Please look through the drivers/serial/sun* changelogs and see what fix needs to be ported to the ip22zilog driver. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-24 19:05 ` Christoph Hellwig @ 2006-02-27 10:51 ` Martin Michlmayr 2006-02-27 10:52 ` Martin Michlmayr 1 sibling, 0 replies; 26+ messages in thread From: Martin Michlmayr @ 2006-02-27 10:51 UTC (permalink / raw) To: linux-mips, jblache, rmk+serial * Christoph Hellwig <hch@lst.de> [2006-02-24 20:05]: > This patch was dropped when a real fix went into one of the sun serial > drivers with which this issue was seen before. Please look through > the drivers/serial/sun* changelogs and see what fix needs to be > ported to the ip22zilog driver. Thanks for the hint, Christoph. Russell, please apply the following patch for 2.6.16. Tested on IP22 (Indy). [serial] ip22zilog: Fix oops on runlevel change with serial console Incorrect uart_write_wakeup() calls cause reference to a NULL tty pointer. This has been fixed in the sunsab and sunzilog serial drivers in October 2005. Update the ip22zilog, which is based on sunzilog, accordingly. Signed-off-by: Martin Michlmayr <tbm@cyrius.com> --- a/drivers/serial/ip22zilog.c 2006-02-23 22:05:49.000000000 +0000 +++ b/drivers/serial/ip22zilog.c 2006-02-27 09:51:38.000000000 +0000 @@ -420,10 +420,8 @@ if (up->port.info == NULL) goto ack_tx_int; xmit = &up->port.info->xmit; - if (uart_circ_empty(xmit)) { - uart_write_wakeup(&up->port); + if (uart_circ_empty(xmit)) goto ack_tx_int; - } if (uart_tx_stopped(&up->port)) goto ack_tx_int; -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-24 19:05 ` Christoph Hellwig 2006-02-27 10:51 ` Martin Michlmayr @ 2006-02-27 10:52 ` Martin Michlmayr 2006-02-27 11:22 ` Geert Uytterhoeven 2006-03-25 17:34 ` Russell King 1 sibling, 2 replies; 26+ messages in thread From: Martin Michlmayr @ 2006-02-27 10:52 UTC (permalink / raw) To: linux-mips, jblache, rmk+serial * Christoph Hellwig <hch@lst.de> [2006-02-24 20:05]: > This patch was dropped when a real fix went into one of the sun serial > drivers with which this issue was seen before. Please look through > the drivers/serial/sun* changelogs and see what fix needs to be > ported to the ip22zilog driver. Ralf suggested to see what other changes have been made to the sunzilog driver recently and update the ip22zilog driver accordingly. Russell, please queue the following patch for 2.6.17. [PATCH] Sync ip22zilog with latest sunzilog driver ip22zilog is based on the sunzilog driver, but there hasn't been a sync since 2.6.0-test7. Sync the relevant changes that have been made since then. Signed-off-by: Martin Michlmayr <tbm@cyrius.com> --- a/drivers/serial/ip22zilog.c +++ b/drivers/serial/ip22zilog.c @@ -2,7 +2,7 @@ * Driver for Zilog serial chips found on SGI workstations and * servers. This driver could actually be made more generic. * - * This is based on the drivers/serial/sunzilog.c code as of 2.6.0-test7 and the + * This is based on the drivers/serial/sunzilog.c code as of 2.6.16-rc5 and the * old drivers/sgi/char/sgiserial.c code which itself is based of the original * drivers/sbus/char/zs.c code. A lot of code has been simply moved over * directly from there but much has been rewritten. Credits therefore go out @@ -86,15 +86,11 @@ struct uart_ip22zilog_port { unsigned int cflag; - /* L1-A keyboard break state. */ - int kbd_id; - int l1_down; - unsigned char parity_mask; unsigned char prev_status; }; -#define ZILOG_CHANNEL_FROM_PORT(PORT) ((struct zilog_channel *)((PORT)->membase)) +#define ZILOG_CHANNEL_FROM_PORT(PORT) ((struct zilog_channel __iomem *)((PORT)->membase)) #define UART_ZILOG(PORT) ((struct uart_ip22zilog_port *)(PORT)) #define IP22ZILOG_GET_CURR_REG(PORT, REGNUM) \ (UART_ZILOG(PORT)->curregs[REGNUM]) @@ -116,7 +112,7 @@ struct uart_ip22zilog_port { * The port lock must be held and local IRQs must be disabled * when {read,write}_zsreg is invoked. */ -static unsigned char read_zsreg(struct zilog_channel *channel, +static unsigned char read_zsreg(struct zilog_channel __iomem *channel, unsigned char reg) { unsigned char retval; @@ -129,7 +125,7 @@ static unsigned char read_zsreg(struct z return retval; } -static void write_zsreg(struct zilog_channel *channel, +static void write_zsreg(struct zilog_channel __iomem *channel, unsigned char reg, unsigned char value) { writeb(reg, &channel->control); @@ -138,7 +134,7 @@ static void write_zsreg(struct zilog_cha ZSDELAY(); } -static void ip22zilog_clear_fifo(struct zilog_channel *channel) +static void ip22zilog_clear_fifo(struct zilog_channel __iomem *channel) { int i; @@ -165,7 +161,7 @@ static void ip22zilog_clear_fifo(struct /* This function must only be called when the TX is not busy. The UART * port lock must be held and local interrupts disabled. */ -static void __load_zsregs(struct zilog_channel *channel, unsigned char *regs) +static void __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs) { int i; @@ -241,7 +237,7 @@ static void __load_zsregs(struct zilog_c * The UART port lock must be held and local interrupts disabled. */ static void ip22zilog_maybe_update_regs(struct uart_ip22zilog_port *up, - struct zilog_channel *channel) + struct zilog_channel __iomem *channel) { if (!ZS_REGS_HELD(up)) { if (ZS_TX_ACTIVE(up)) { @@ -252,14 +248,20 @@ static void ip22zilog_maybe_update_regs( } } -static void ip22zilog_receive_chars(struct uart_ip22zilog_port *up, - struct zilog_channel *channel, - struct pt_regs *regs) -{ - struct tty_struct *tty = up->port.info->tty; /* XXX info==NULL? */ +static struct tty_struct * +ip22zilog_receive_chars(struct uart_ip22zilog_port *up, + struct zilog_channel __iomem *channel, + struct pt_regs *regs) +{ + struct tty_struct *tty; + unsigned char ch, r1, flag; + + tty = NULL; + if (up->port.info != NULL && /* Unopened serial console */ + up->port.info->tty != NULL) /* Keyboard || mouse */ + tty = up->port.info->tty; while (1) { - unsigned char ch, r1, flag; r1 = read_zsreg(channel, R1); if (r1 & (PAR_ERR | Rx_OVR | CRC_ERR)) { @@ -277,23 +279,17 @@ static void ip22zilog_receive_chars(stru if (ch & BRK_ABRT) r1 |= BRK_ABRT; + if (!(ch & Rx_CH_AV)) + break; + ch = readb(&channel->data); ZSDELAY(); ch &= up->parity_mask; - if (ZS_IS_CONS(up) && (r1 & BRK_ABRT)) { - /* Wait for BREAK to deassert to avoid potentially - * confusing the PROM. - */ - while (1) { - ch = readb(&channel->control); - ZSDELAY(); - if (!(ch & BRK_ABRT)) - break; - } - ip22_do_break(); - return; + if (tty == NULL) { + uart_handle_sysrq_char(&up->port, ch, regs); + continue; } /* A real serial line, record the character and status. */ @@ -304,7 +300,7 @@ static void ip22zilog_receive_chars(stru r1 &= ~(PAR_ERR | CRC_ERR); up->port.icount.brk++; if (uart_handle_break(&up->port)) - goto next_char; + continue; } else if (r1 & PAR_ERR) up->port.icount.parity++; @@ -321,7 +317,7 @@ static void ip22zilog_receive_chars(stru flag = TTY_FRAME; } if (uart_handle_sysrq_char(&up->port, ch, regs)) - goto next_char; + continue; if (up->port.ignore_status_mask == 0xff || (r1 & up->port.ignore_status_mask) == 0) @@ -329,18 +325,13 @@ static void ip22zilog_receive_chars(stru if (r1 & Rx_OVR) tty_insert_flip_char(tty, 0, TTY_OVERRUN); - next_char: - ch = readb(&channel->control); - ZSDELAY(); - if (!(ch & Rx_CH_AV)) - break; } - tty_flip_buffer_push(tty); + return tty; } static void ip22zilog_status_handle(struct uart_ip22zilog_port *up, - struct zilog_channel *channel, + struct zilog_channel __iomem *channel, struct pt_regs *regs) { unsigned char status; @@ -352,6 +343,22 @@ static void ip22zilog_status_handle(stru ZSDELAY(); ZS_WSYNC(channel); + if (status & BRK_ABRT) { + if (ZS_IS_CONS(up)) { + /* Wait for BREAK to deassert to avoid potentially + * confusing the PROM. + */ + while (1) { + status = readb(&channel->control); + ZSDELAY(); + if (!(status & BRK_ABRT)) + break; + } + ip22_do_break(); + return; + } + } + if (ZS_WANTS_MODEM_STATUS(up)) { if (status & SYNC) up->port.icount.dsr++; @@ -360,10 +367,10 @@ static void ip22zilog_status_handle(stru * But it does not tell us which bit has changed, we have to keep * track of this ourselves. */ - if ((status & DCD) ^ up->prev_status) + if ((status ^ up->prev_status) ^ DCD) uart_handle_dcd_change(&up->port, (status & DCD)); - if ((status & CTS) ^ up->prev_status) + if ((status ^ up->prev_status) ^ CTS) uart_handle_cts_change(&up->port, (status & CTS)); @@ -374,7 +381,7 @@ static void ip22zilog_status_handle(stru } static void ip22zilog_transmit_chars(struct uart_ip22zilog_port *up, - struct zilog_channel *channel) + struct zilog_channel __iomem *channel) { struct circ_buf *xmit; @@ -451,21 +458,23 @@ static irqreturn_t ip22zilog_interrupt(i struct uart_ip22zilog_port *up = dev_id; while (up) { - struct zilog_channel *channel + struct zilog_channel __iomem *channel = ZILOG_CHANNEL_FROM_PORT(&up->port); + struct tty_struct *tty; unsigned char r3; spin_lock(&up->port.lock); r3 = read_zsreg(channel, R3); /* Channel A */ + tty = NULL; if (r3 & (CHAEXT | CHATxIP | CHARxIP)) { writeb(RES_H_IUS, &channel->control); ZSDELAY(); ZS_WSYNC(channel); if (r3 & CHARxIP) - ip22zilog_receive_chars(up, channel, regs); + tty = ip22zilog_receive_chars(up, channel, regs); if (r3 & CHAEXT) ip22zilog_status_handle(up, channel, regs); if (r3 & CHATxIP) @@ -473,18 +482,22 @@ static irqreturn_t ip22zilog_interrupt(i } spin_unlock(&up->port.lock); + if (tty) + tty_flip_buffer_push(tty); + /* Channel B */ up = up->next; channel = ZILOG_CHANNEL_FROM_PORT(&up->port); spin_lock(&up->port.lock); + tty = NULL; if (r3 & (CHBEXT | CHBTxIP | CHBRxIP)) { writeb(RES_H_IUS, &channel->control); ZSDELAY(); ZS_WSYNC(channel); if (r3 & CHBRxIP) - ip22zilog_receive_chars(up, channel, regs); + tty = ip22zilog_receive_chars(up, channel, regs); if (r3 & CHBEXT) ip22zilog_status_handle(up, channel, regs); if (r3 & CHBTxIP) @@ -492,6 +505,9 @@ static irqreturn_t ip22zilog_interrupt(i } spin_unlock(&up->port.lock); + if (tty) + tty_flip_buffer_push(tty); + up = up->next; } @@ -503,7 +519,7 @@ static irqreturn_t ip22zilog_interrupt(i */ static __inline__ unsigned char ip22zilog_read_channel_status(struct uart_port *port) { - struct zilog_channel *channel; + struct zilog_channel __iomem *channel; unsigned char status; channel = ZILOG_CHANNEL_FROM_PORT(port); @@ -557,7 +573,7 @@ static unsigned int ip22zilog_get_mctrl( static void ip22zilog_set_mctrl(struct uart_port *port, unsigned int mctrl) { struct uart_ip22zilog_port *up = (struct uart_ip22zilog_port *) port; - struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(port); + struct zilog_channel __iomem *channel = ZILOG_CHANNEL_FROM_PORT(port); unsigned char set_bits, clear_bits; set_bits = clear_bits = 0; @@ -589,7 +605,7 @@ static void ip22zilog_stop_tx(struct uar static void ip22zilog_start_tx(struct uart_port *port) { struct uart_ip22zilog_port *up = (struct uart_ip22zilog_port *) port; - struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(port); + struct zilog_channel __iomem *channel = ZILOG_CHANNEL_FROM_PORT(port); unsigned char status; up->flags |= IP22ZILOG_FLAG_TX_ACTIVE; @@ -631,7 +647,7 @@ static void ip22zilog_start_tx(struct ua static void ip22zilog_stop_rx(struct uart_port *port) { struct uart_ip22zilog_port *up = UART_ZILOG(port); - struct zilog_channel *channel; + struct zilog_channel __iomem *channel; if (ZS_IS_CONS(up)) return; @@ -647,7 +663,7 @@ static void ip22zilog_stop_rx(struct uar static void ip22zilog_enable_ms(struct uart_port *port) { struct uart_ip22zilog_port *up = (struct uart_ip22zilog_port *) port; - struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(port); + struct zilog_channel __iomem *channel = ZILOG_CHANNEL_FROM_PORT(port); unsigned char new_reg; new_reg = up->curregs[R15] | (DCDIE | SYNCIE | CTSIE); @@ -663,7 +679,7 @@ static void ip22zilog_enable_ms(struct u static void ip22zilog_break_ctl(struct uart_port *port, int break_state) { struct uart_ip22zilog_port *up = (struct uart_ip22zilog_port *) port; - struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(port); + struct zilog_channel __iomem *channel = ZILOG_CHANNEL_FROM_PORT(port); unsigned char set_bits, clear_bits, new_reg; unsigned long flags; @@ -689,7 +705,7 @@ static void ip22zilog_break_ctl(struct u static void __ip22zilog_startup(struct uart_ip22zilog_port *up) { - struct zilog_channel *channel; + struct zilog_channel __iomem *channel; channel = ZILOG_CHANNEL_FROM_PORT(&up->port); up->prev_status = readb(&channel->control); @@ -744,7 +760,7 @@ static int ip22zilog_startup(struct uart static void ip22zilog_shutdown(struct uart_port *port) { struct uart_ip22zilog_port *up = UART_ZILOG(port); - struct zilog_channel *channel; + struct zilog_channel __iomem *channel; unsigned long flags; if (ZS_IS_CONS(up)) @@ -868,6 +884,7 @@ ip22zilog_set_termios(struct uart_port * up->cflag = termios->c_cflag; ip22zilog_maybe_update_regs(up, ZILOG_CHANNEL_FROM_PORT(port)); + uart_update_timeout(port, termios->c_cflag, baud); spin_unlock_irqrestore(&up->port.lock, flags); @@ -921,7 +938,7 @@ static struct uart_ops ip22zilog_pops = }; static struct uart_ip22zilog_port *ip22zilog_port_table; -static struct zilog_layout **ip22zilog_chip_regs; +static struct zilog_layout __iomem **ip22zilog_chip_regs; static struct uart_ip22zilog_port *ip22zilog_irq_chain; static int zilog_irq = -1; @@ -939,10 +956,10 @@ static void * __init alloc_one_table(uns static void __init ip22zilog_alloc_tables(void) { - ip22zilog_port_table = (struct uart_ip22zilog_port *) + ip22zilog_port_table = alloc_one_table(NUM_CHANNELS * sizeof(struct uart_ip22zilog_port)); - ip22zilog_chip_regs = (struct zilog_layout **) - alloc_one_table(NUM_IP22ZILOG * sizeof(struct zilog_layout *)); + ip22zilog_chip_regs = + alloc_one_table(NUM_IP22ZILOG * sizeof(struct zilog_layout __iomem *)); if (ip22zilog_port_table == NULL || ip22zilog_chip_regs == NULL) { panic("IP22-Zilog: Cannot allocate IP22-Zilog tables."); @@ -950,7 +967,7 @@ static void __init ip22zilog_alloc_table } /* Get the address of the registers for IP22-Zilog instance CHIP. */ -static struct zilog_layout * __init get_zs(int chip) +static struct zilog_layout __iomem * __init get_zs(int chip) { unsigned long base; @@ -964,13 +981,13 @@ static struct zilog_layout * __init get_ zilog_irq = SGI_SERIAL_IRQ; request_mem_region(base, 8, "IP22-Zilog"); - return (struct zilog_layout *) base; + return (struct zilog_layout __iomem *) base; } #define ZS_PUT_CHAR_MAX_DELAY 2000 /* 10 ms */ #ifdef CONFIG_SERIAL_IP22_ZILOG_CONSOLE -static void ip22zilog_put_char(struct zilog_channel *channel, unsigned char ch) +static void ip22zilog_put_char(struct zilog_channel __iomem *channel, unsigned char ch) { int loops = ZS_PUT_CHAR_MAX_DELAY; @@ -1108,7 +1125,7 @@ static struct uart_driver ip22zilog_reg static void __init ip22zilog_prepare(void) { struct uart_ip22zilog_port *up; - struct zilog_layout *rp; + struct zilog_layout __iomem *rp; int channel, chip; /* @@ -1127,8 +1144,8 @@ static void __init ip22zilog_prepare(voi if (!ip22zilog_chip_regs[chip]) { ip22zilog_chip_regs[chip] = rp = get_zs(chip); - up[(chip * 2) + 0].port.membase = (char *) &rp->channelB; - up[(chip * 2) + 1].port.membase = (char *) &rp->channelA; + up[(chip * 2) + 0].port.membase = (void __iomem *) &rp->channelB; + up[(chip * 2) + 1].port.membase = (void __iomem *) &rp->channelA; /* In theory mapbase is the physical address ... */ up[(chip * 2) + 0].port.mapbase = @@ -1167,7 +1184,7 @@ static void __init ip22zilog_init_hw(voi for (i = 0; i < NUM_CHANNELS; i++) { struct uart_ip22zilog_port *up = &ip22zilog_port_table[i]; - struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(&up->port); + struct zilog_channel __iomem *channel = ZILOG_CHANNEL_FROM_PORT(&up->port); unsigned long flags; int baud, brg; -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-27 10:52 ` Martin Michlmayr @ 2006-02-27 11:22 ` Geert Uytterhoeven 2006-02-27 11:25 ` Martin Michlmayr ` (2 more replies) 2006-03-25 17:34 ` Russell King 1 sibling, 3 replies; 26+ messages in thread From: Geert Uytterhoeven @ 2006-02-27 11:22 UTC (permalink / raw) To: Martin Michlmayr; +Cc: Linux/MIPS Development, jblache, rmk+serial On Mon, 27 Feb 2006, Martin Michlmayr wrote: > * Christoph Hellwig <hch@lst.de> [2006-02-24 20:05]: > > This patch was dropped when a real fix went into one of the sun serial > > drivers with which this issue was seen before. Please look through > > the drivers/serial/sun* changelogs and see what fix needs to be > > ported to the ip22zilog driver. > > Ralf suggested to see what other changes have been made to the > sunzilog driver recently and update the ip22zilog driver accordingly. > Russell, please queue the following patch for 2.6.17. Any chance they can be merged, to avoid such missed updates in the future? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-27 11:22 ` Geert Uytterhoeven @ 2006-02-27 11:25 ` Martin Michlmayr 2006-02-27 12:53 ` Ralf Baechle 2006-02-27 18:30 ` Martin Michlmayr 2 siblings, 0 replies; 26+ messages in thread From: Martin Michlmayr @ 2006-02-27 11:25 UTC (permalink / raw) To: Linux/MIPS Development, jblache, rmk+serial * Geert Uytterhoeven <geert@linux-m68k.org> [2006-02-27 12:22]: > > Ralf suggested to see what other changes have been made to the > > sunzilog driver recently and update the ip22zilog driver accordingly. > > Russell, please queue the following patch for 2.6.17. > Any chance they can be merged, to avoid such missed updates in the future? I don't have the knowledge to do it but maybe someone else can. -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-27 11:22 ` Geert Uytterhoeven 2006-02-27 11:25 ` Martin Michlmayr @ 2006-02-27 12:53 ` Ralf Baechle 2006-02-27 18:30 ` Martin Michlmayr 2 siblings, 0 replies; 26+ messages in thread From: Ralf Baechle @ 2006-02-27 12:53 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Martin Michlmayr, Linux/MIPS Development, jblache, rmk+serial On Mon, Feb 27, 2006 at 12:22:57PM +0100, Geert Uytterhoeven wrote: > On Mon, 27 Feb 2006, Martin Michlmayr wrote: > > * Christoph Hellwig <hch@lst.de> [2006-02-24 20:05]: > > > This patch was dropped when a real fix went into one of the sun serial > > > drivers with which this issue was seen before. Please look through > > > the drivers/serial/sun* changelogs and see what fix needs to be > > > ported to the ip22zilog driver. > > > > Ralf suggested to see what other changes have been made to the > > sunzilog driver recently and update the ip22zilog driver accordingly. > > Russell, please queue the following patch for 2.6.17. > > Any chance they can be merged, to avoid such missed updates in the future? I'm somewhat pessimistic on mergin. I don't have a Sparc to test this and in the past it didn't happen either - instead the kernel was living with a bucketload of Zilog UART drivers. Yet it's something that really should be done. Ralf ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-27 11:22 ` Geert Uytterhoeven 2006-02-27 11:25 ` Martin Michlmayr 2006-02-27 12:53 ` Ralf Baechle @ 2006-02-27 18:30 ` Martin Michlmayr 2 siblings, 0 replies; 26+ messages in thread From: Martin Michlmayr @ 2006-02-27 18:30 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: Linux/MIPS Development, jblache, rmk+serial * Geert Uytterhoeven <geert@linux-m68k.org> [2006-02-27 12:22]: > > Ralf suggested to see what other changes have been made to the > > sunzilog driver recently and update the ip22zilog driver accordingly. > > Russell, please queue the following patch for 2.6.17. > Any chance they can be merged, to avoid such missed updates in the future? Ladislav Michl mentioned on IRC that he made some progress towards a unified driver a few months ago; but it seems that he currently doesn't have time to finish it (nor can he test it on sparc). Maybe someone can do some work based on that patch. ftp://ftp.linux-mips.org/pub/linux/mips/people/ladis/generic_zilog_driver.mbox -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-02-27 10:52 ` Martin Michlmayr 2006-02-27 11:22 ` Geert Uytterhoeven @ 2006-03-25 17:34 ` Russell King 2006-04-07 16:21 ` Martin Michlmayr 1 sibling, 1 reply; 26+ messages in thread From: Russell King @ 2006-03-25 17:34 UTC (permalink / raw) To: Martin Michlmayr; +Cc: linux-mips, jblache On Mon, Feb 27, 2006 at 10:52:36AM +0000, Martin Michlmayr wrote: > @@ -360,10 +367,10 @@ static void ip22zilog_status_handle(stru > * But it does not tell us which bit has changed, we have to keep > * track of this ourselves. > */ > - if ((status & DCD) ^ up->prev_status) > + if ((status ^ up->prev_status) ^ DCD) Shouldn't this be (status ^ up->prev_status) & DCD ? > uart_handle_dcd_change(&up->port, > (status & DCD)); > - if ((status & CTS) ^ up->prev_status) > + if ((status ^ up->prev_status) ^ CTS) Shouldn't this be (status ^ up->prev_status) & CTS ? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: IP22 doesn't shutdown properly 2006-03-25 17:34 ` Russell King @ 2006-04-07 16:21 ` Martin Michlmayr 0 siblings, 0 replies; 26+ messages in thread From: Martin Michlmayr @ 2006-04-07 16:21 UTC (permalink / raw) To: Russell King; +Cc: linux-mips * Russell King <rmk@arm.linux.org.uk> [2006-03-25 17:34]: > > - if ((status & DCD) ^ up->prev_status) > > + if ((status ^ up->prev_status) ^ DCD) > Shouldn't this be (status ^ up->prev_status) & DCD ? > > > - if ((status & CTS) ^ up->prev_status) > > + if ((status ^ up->prev_status) ^ CTS) > Shouldn't this be (status ^ up->prev_status) & CTS ? Thanks for catching this! I obviously copied too much from sunzilog.c without thinking. Below is a new version which has this fix and which has been updated so it apples to 2.6.17-rc1. [PATCH] Sync ip22zilog with latest sunzilog driver ip22zilog is based on the sunzilog driver, but there hasn't been a sync since 2.6.0-test7. Sync the relevant changes that have been made since then. Signed-off-by: Martin Michlmayr <tbm@cyrius.com> --- a/drivers/serial/ip22zilog.c +++ b/drivers/serial/ip22zilog.c @@ -2,7 +2,7 @@ * Driver for Zilog serial chips found on SGI workstations and * servers. This driver could actually be made more generic. * - * This is based on the drivers/serial/sunzilog.c code as of 2.6.0-test7 and the + * This is based on the drivers/serial/sunzilog.c code as of 2.6.17-rc1 and the * old drivers/sgi/char/sgiserial.c code which itself is based of the original * drivers/sbus/char/zs.c code. A lot of code has been simply moved over * directly from there but much has been rewritten. Credits therefore go out @@ -86,15 +86,11 @@ struct uart_ip22zilog_port { unsigned int cflag; - /* L1-A keyboard break state. */ - int kbd_id; - int l1_down; - unsigned char parity_mask; unsigned char prev_status; }; -#define ZILOG_CHANNEL_FROM_PORT(PORT) ((struct zilog_channel *)((PORT)->membase)) +#define ZILOG_CHANNEL_FROM_PORT(PORT) ((struct zilog_channel __iomem *)((PORT)->membase)) #define UART_ZILOG(PORT) ((struct uart_ip22zilog_port *)(PORT)) #define IP22ZILOG_GET_CURR_REG(PORT, REGNUM) \ (UART_ZILOG(PORT)->curregs[REGNUM]) @@ -116,7 +112,7 @@ struct uart_ip22zilog_port { * The port lock must be held and local IRQs must be disabled * when {read,write}_zsreg is invoked. */ -static unsigned char read_zsreg(struct zilog_channel *channel, +static unsigned char read_zsreg(struct zilog_channel __iomem *channel, unsigned char reg) { unsigned char retval; @@ -129,7 +125,7 @@ static unsigned char read_zsreg(struct z return retval; } -static void write_zsreg(struct zilog_channel *channel, +static void write_zsreg(struct zilog_channel __iomem *channel, unsigned char reg, unsigned char value) { writeb(reg, &channel->control); @@ -138,7 +134,7 @@ static void write_zsreg(struct zilog_cha ZSDELAY(); } -static void ip22zilog_clear_fifo(struct zilog_channel *channel) +static void ip22zilog_clear_fifo(struct zilog_channel __iomem *channel) { int i; @@ -165,7 +161,7 @@ static void ip22zilog_clear_fifo(struct /* This function must only be called when the TX is not busy. The UART * port lock must be held and local interrupts disabled. */ -static void __load_zsregs(struct zilog_channel *channel, unsigned char *regs) +static void __load_zsregs(struct zilog_channel __iomem *channel, unsigned char *regs) { int i; @@ -241,7 +237,7 @@ static void __load_zsregs(struct zilog_c * The UART port lock must be held and local interrupts disabled. */ static void ip22zilog_maybe_update_regs(struct uart_ip22zilog_port *up, - struct zilog_channel *channel) + struct zilog_channel __iomem *channel) { if (!ZS_REGS_HELD(up)) { if (ZS_TX_ACTIVE(up)) { @@ -252,14 +248,20 @@ static void ip22zilog_maybe_update_regs( } } -static void ip22zilog_receive_chars(struct uart_ip22zilog_port *up, - struct zilog_channel *channel, - struct pt_regs *regs) -{ - struct tty_struct *tty = up->port.info->tty; /* XXX info==NULL? */ +static struct tty_struct * +ip22zilog_receive_chars(struct uart_ip22zilog_port *up, + struct zilog_channel __iomem *channel, + struct pt_regs *regs) +{ + struct tty_struct *tty; + unsigned char ch, r1, flag; + + tty = NULL; + if (up->port.info != NULL && /* Unopened serial console */ + up->port.info->tty != NULL) /* Keyboard || mouse */ + tty = up->port.info->tty; while (1) { - unsigned char ch, r1, flag; r1 = read_zsreg(channel, R1); if (r1 & (PAR_ERR | Rx_OVR | CRC_ERR)) { @@ -277,23 +279,17 @@ static void ip22zilog_receive_chars(stru if (ch & BRK_ABRT) r1 |= BRK_ABRT; + if (!(ch & Rx_CH_AV)) + break; + ch = readb(&channel->data); ZSDELAY(); ch &= up->parity_mask; - if (ZS_IS_CONS(up) && (r1 & BRK_ABRT)) { - /* Wait for BREAK to deassert to avoid potentially - * confusing the PROM. - */ - while (1) { - ch = readb(&channel->control); - ZSDELAY(); - if (!(ch & BRK_ABRT)) - break; - } - ip22_do_break(); - return; + if (tty == NULL) { + uart_handle_sysrq_char(&up->port, ch, regs); + continue; } /* A real serial line, record the character and status. */ @@ -304,7 +300,7 @@ static void ip22zilog_receive_chars(stru r1 &= ~(PAR_ERR | CRC_ERR); up->port.icount.brk++; if (uart_handle_break(&up->port)) - goto next_char; + continue; } else if (r1 & PAR_ERR) up->port.icount.parity++; @@ -321,7 +317,7 @@ static void ip22zilog_receive_chars(stru flag = TTY_FRAME; } if (uart_handle_sysrq_char(&up->port, ch, regs)) - goto next_char; + continue; if (up->port.ignore_status_mask == 0xff || (r1 & up->port.ignore_status_mask) == 0) @@ -329,18 +325,13 @@ static void ip22zilog_receive_chars(stru if (r1 & Rx_OVR) tty_insert_flip_char(tty, 0, TTY_OVERRUN); - next_char: - ch = readb(&channel->control); - ZSDELAY(); - if (!(ch & Rx_CH_AV)) - break; } - tty_flip_buffer_push(tty); + return tty; } static void ip22zilog_status_handle(struct uart_ip22zilog_port *up, - struct zilog_channel *channel, + struct zilog_channel __iomem *channel, struct pt_regs *regs) { unsigned char status; @@ -352,6 +343,22 @@ static void ip22zilog_status_handle(stru ZSDELAY(); ZS_WSYNC(channel); + if (status & BRK_ABRT) { + if (ZS_IS_CONS(up)) { + /* Wait for BREAK to deassert to avoid potentially + * confusing the PROM. + */ + while (1) { + status = readb(&channel->control); + ZSDELAY(); + if (!(status & BRK_ABRT)) + break; + } + ip22_do_break(); + return; + } + } + if (ZS_WANTS_MODEM_STATUS(up)) { if (status & SYNC) up->port.icount.dsr++; @@ -360,10 +367,10 @@ static void ip22zilog_status_handle(stru * But it does not tell us which bit has changed, we have to keep * track of this ourselves. */ - if ((status & DCD) ^ up->prev_status) + if ((status ^ up->prev_status) & DCD) uart_handle_dcd_change(&up->port, (status & DCD)); - if ((status & CTS) ^ up->prev_status) + if ((status ^ up->prev_status) & CTS) uart_handle_cts_change(&up->port, (status & CTS)); @@ -374,7 +381,7 @@ static void ip22zilog_status_handle(stru } static void ip22zilog_transmit_chars(struct uart_ip22zilog_port *up, - struct zilog_channel *channel) + struct zilog_channel __iomem *channel) { struct circ_buf *xmit; @@ -449,21 +456,23 @@ static irqreturn_t ip22zilog_interrupt(i struct uart_ip22zilog_port *up = dev_id; while (up) { - struct zilog_channel *channel + struct zilog_channel __iomem *channel = ZILOG_CHANNEL_FROM_PORT(&up->port); + struct tty_struct *tty; unsigned char r3; spin_lock(&up->port.lock); r3 = read_zsreg(channel, R3); /* Channel A */ + tty = NULL; if (r3 & (CHAEXT | CHATxIP | CHARxIP)) { writeb(RES_H_IUS, &channel->control); ZSDELAY(); ZS_WSYNC(channel); if (r3 & CHARxIP) - ip22zilog_receive_chars(up, channel, regs); + tty = ip22zilog_receive_chars(up, channel, regs); if (r3 & CHAEXT) ip22zilog_status_handle(up, channel, regs); if (r3 & CHATxIP) @@ -471,18 +480,22 @@ static irqreturn_t ip22zilog_interrupt(i } spin_unlock(&up->port.lock); + if (tty) + tty_flip_buffer_push(tty); + /* Channel B */ up = up->next; channel = ZILOG_CHANNEL_FROM_PORT(&up->port); spin_lock(&up->port.lock); + tty = NULL; if (r3 & (CHBEXT | CHBTxIP | CHBRxIP)) { writeb(RES_H_IUS, &channel->control); ZSDELAY(); ZS_WSYNC(channel); if (r3 & CHBRxIP) - ip22zilog_receive_chars(up, channel, regs); + tty = ip22zilog_receive_chars(up, channel, regs); if (r3 & CHBEXT) ip22zilog_status_handle(up, channel, regs); if (r3 & CHBTxIP) @@ -490,6 +503,9 @@ static irqreturn_t ip22zilog_interrupt(i } spin_unlock(&up->port.lock); + if (tty) + tty_flip_buffer_push(tty); + up = up->next; } @@ -501,7 +517,7 @@ static irqreturn_t ip22zilog_interrupt(i */ static __inline__ unsigned char ip22zilog_read_channel_status(struct uart_port *port) { - struct zilog_channel *channel; + struct zilog_channel __iomem *channel; unsigned char status; channel = ZILOG_CHANNEL_FROM_PORT(port); @@ -555,7 +571,7 @@ static unsigned int ip22zilog_get_mctrl( static void ip22zilog_set_mctrl(struct uart_port *port, unsigned int mctrl) { struct uart_ip22zilog_port *up = (struct uart_ip22zilog_port *) port; - struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(port); + struct zilog_channel __iomem *channel = ZILOG_CHANNEL_FROM_PORT(port); unsigned char set_bits, clear_bits; set_bits = clear_bits = 0; @@ -587,7 +603,7 @@ static void ip22zilog_stop_tx(struct uar static void ip22zilog_start_tx(struct uart_port *port) { struct uart_ip22zilog_port *up = (struct uart_ip22zilog_port *) port; - struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(port); + struct zilog_channel __iomem *channel = ZILOG_CHANNEL_FROM_PORT(port); unsigned char status; up->flags |= IP22ZILOG_FLAG_TX_ACTIVE; @@ -629,7 +645,7 @@ static void ip22zilog_start_tx(struct ua static void ip22zilog_stop_rx(struct uart_port *port) { struct uart_ip22zilog_port *up = UART_ZILOG(port); - struct zilog_channel *channel; + struct zilog_channel __iomem *channel; if (ZS_IS_CONS(up)) return; @@ -645,7 +661,7 @@ static void ip22zilog_stop_rx(struct uar static void ip22zilog_enable_ms(struct uart_port *port) { struct uart_ip22zilog_port *up = (struct uart_ip22zilog_port *) port; - struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(port); + struct zilog_channel __iomem *channel = ZILOG_CHANNEL_FROM_PORT(port); unsigned char new_reg; new_reg = up->curregs[R15] | (DCDIE | SYNCIE | CTSIE); @@ -661,7 +677,7 @@ static void ip22zilog_enable_ms(struct u static void ip22zilog_break_ctl(struct uart_port *port, int break_state) { struct uart_ip22zilog_port *up = (struct uart_ip22zilog_port *) port; - struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(port); + struct zilog_channel __iomem *channel = ZILOG_CHANNEL_FROM_PORT(port); unsigned char set_bits, clear_bits, new_reg; unsigned long flags; @@ -687,7 +703,7 @@ static void ip22zilog_break_ctl(struct u static void __ip22zilog_startup(struct uart_ip22zilog_port *up) { - struct zilog_channel *channel; + struct zilog_channel __iomem *channel; channel = ZILOG_CHANNEL_FROM_PORT(&up->port); up->prev_status = readb(&channel->control); @@ -742,7 +758,7 @@ static int ip22zilog_startup(struct uart static void ip22zilog_shutdown(struct uart_port *port) { struct uart_ip22zilog_port *up = UART_ZILOG(port); - struct zilog_channel *channel; + struct zilog_channel __iomem *channel; unsigned long flags; if (ZS_IS_CONS(up)) @@ -918,7 +934,7 @@ static struct uart_ops ip22zilog_pops = }; static struct uart_ip22zilog_port *ip22zilog_port_table; -static struct zilog_layout **ip22zilog_chip_regs; +static struct zilog_layout __iomem **ip22zilog_chip_regs; static struct uart_ip22zilog_port *ip22zilog_irq_chain; static int zilog_irq = -1; @@ -936,10 +952,10 @@ static void * __init alloc_one_table(uns static void __init ip22zilog_alloc_tables(void) { - ip22zilog_port_table = (struct uart_ip22zilog_port *) + ip22zilog_port_table = alloc_one_table(NUM_CHANNELS * sizeof(struct uart_ip22zilog_port)); - ip22zilog_chip_regs = (struct zilog_layout **) - alloc_one_table(NUM_IP22ZILOG * sizeof(struct zilog_layout *)); + ip22zilog_chip_regs = + alloc_one_table(NUM_IP22ZILOG * sizeof(struct zilog_layout __iomem *)); if (ip22zilog_port_table == NULL || ip22zilog_chip_regs == NULL) { panic("IP22-Zilog: Cannot allocate IP22-Zilog tables."); @@ -947,7 +963,7 @@ static void __init ip22zilog_alloc_table } /* Get the address of the registers for IP22-Zilog instance CHIP. */ -static struct zilog_layout * __init get_zs(int chip) +static struct zilog_layout __iomem * __init get_zs(int chip) { unsigned long base; @@ -961,13 +977,13 @@ static struct zilog_layout * __init get_ zilog_irq = SGI_SERIAL_IRQ; request_mem_region(base, 8, "IP22-Zilog"); - return (struct zilog_layout *) base; + return (struct zilog_layout __iomem *) base; } #define ZS_PUT_CHAR_MAX_DELAY 2000 /* 10 ms */ #ifdef CONFIG_SERIAL_IP22_ZILOG_CONSOLE -static void ip22zilog_put_char(struct uart_port *port, int ch) +static void ip22zilog_putchar(struct uart_port *port, int ch) { struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(port); int loops = ZS_PUT_CHAR_MAX_DELAY; @@ -996,7 +1012,7 @@ ip22zilog_console_write(struct console * unsigned long flags; spin_lock_irqsave(&up->port.lock, flags); - uart_console_write(&up->port, s, count, ip22zilog_put_char); + uart_console_write(&up->port, s, count, ip22zilog_putchar); udelay(2); spin_unlock_irqrestore(&up->port.lock, flags); } @@ -1098,7 +1114,7 @@ static struct uart_driver ip22zilog_reg static void __init ip22zilog_prepare(void) { struct uart_ip22zilog_port *up; - struct zilog_layout *rp; + struct zilog_layout __iomem *rp; int channel, chip; /* @@ -1117,8 +1133,8 @@ static void __init ip22zilog_prepare(voi if (!ip22zilog_chip_regs[chip]) { ip22zilog_chip_regs[chip] = rp = get_zs(chip); - up[(chip * 2) + 0].port.membase = (char *) &rp->channelB; - up[(chip * 2) + 1].port.membase = (char *) &rp->channelA; + up[(chip * 2) + 0].port.membase = (void __iomem *) &rp->channelB; + up[(chip * 2) + 1].port.membase = (void __iomem *) &rp->channelA; /* In theory mapbase is the physical address ... */ up[(chip * 2) + 0].port.mapbase = @@ -1157,7 +1173,7 @@ static void __init ip22zilog_init_hw(voi for (i = 0; i < NUM_CHANNELS; i++) { struct uart_ip22zilog_port *up = &ip22zilog_port_table[i]; - struct zilog_channel *channel = ZILOG_CHANNEL_FROM_PORT(&up->port); + struct zilog_channel __iomem *channel = ZILOG_CHANNEL_FROM_PORT(&up->port); unsigned long flags; int baud, brg; -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2006-04-07 16:11 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-02-17 22:58 IP22 doesn't shutdown properly Martin Michlmayr 2006-02-18 1:19 ` Kumba 2006-02-18 1:27 ` Martin Michlmayr 2006-02-18 10:36 ` Julien BLACHE 2006-02-19 16:52 ` Ralf Baechle 2006-02-20 18:12 ` Martin Michlmayr 2006-02-20 21:55 ` Ralf Baechle 2006-02-21 13:59 ` Thiemo Seufer 2006-02-21 14:23 ` Stephen P. Becker 2006-02-21 14:31 ` Thiemo Seufer 2006-02-23 21:14 ` Martin Michlmayr 2006-02-23 22:13 ` Martin Michlmayr 2006-02-23 22:43 ` Russell King 2006-02-24 0:39 ` Martin Michlmayr 2006-02-24 1:30 ` Kumba 2006-02-24 8:31 ` Russell King 2006-02-27 10:54 ` Martin Michlmayr 2006-02-24 19:05 ` Christoph Hellwig 2006-02-27 10:51 ` Martin Michlmayr 2006-02-27 10:52 ` Martin Michlmayr 2006-02-27 11:22 ` Geert Uytterhoeven 2006-02-27 11:25 ` Martin Michlmayr 2006-02-27 12:53 ` Ralf Baechle 2006-02-27 18:30 ` Martin Michlmayr 2006-03-25 17:34 ` Russell King 2006-04-07 16:21 ` Martin Michlmayr
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.