[PATCH] SunSAB console problems in 2.6.x

[PATCH] SunSAB console problems in 2.6.x

[David S. Miller]

Does this make the garbled (every other char missing) console
problem go away?

It isn't the best fix, and if this hack fix works I'll work on
the real cure.

Thanks.

=== drivers/serial/sunsab.c 1.33 vs edited ==--- 1.33/drivers/serial/sunsab.c	2004-05-30 17:43:04 -07:00
+++ edited/drivers/serial/sunsab.c	2004-08-25 23:14:30 -07:00
@@ -940,6 +940,7 @@
 	writeb(up->interrupt_mask1, &up->regs->w.imr1);
 
 	sunsab_convert_to_sab(up, con->cflag, 0, baud);
+	sunsab_set_mctrl(&up->port, TIOCM_DTR | TIOCM_RTS);
 
 	spin_unlock_irqrestore(&up->port.lock, flags);
 	

Re: [PATCH] SunSAB console problems in 2.6.x

[Ralph Mitchell]

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

Umm, that doesn't seem to fix it for me.  I don't know if it's much use, 
but the edited boot log is attached.

If there's anything else I can do to help pin this down...

This is on an E450 w/ kernel-2.6.7.

Ralph Mitchell


David S. Miller wrote:

>Does this make the garbled (every other char missing) console
>problem go away?
>
>It isn't the best fix, and if this hack fix works I'll work on
>the real cure.
>
>Thanks.
>
>===== drivers/serial/sunsab.c 1.33 vs edited =====
>--- 1.33/drivers/serial/sunsab.c	2004-05-30 17:43:04 -07:00
>+++ edited/drivers/serial/sunsab.c	2004-08-25 23:14:30 -07:00
>@@ -940,6 +940,7 @@
> 	writeb(up->interrupt_mask1, &up->regs->w.imr1);
> 
> 	sunsab_convert_to_sab(up, con->cflag, 0, baud);
>+	sunsab_set_mctrl(&up->port, TIOCM_DTR | TIOCM_RTS);
> 
> 	spin_unlock_irqrestore(&up->port.lock, flags);
> 	
>-
>To unsubscribe from this list: send the line "unsubscribe sparclinux" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  
>

[-- Attachment #2: serial_fix.cap --]
[-- Type: text/plain, Size: 1774 bytes --]

 * Bringing br0 down... *   Releasing DHCP lease for br0
  [ ok ]
 *   Stopping br0
  [ ok ]
 * Bringing lo down...  [ ok ]
 * Stopping devfsd...  [ ok ]
 * Deactivating swap...  [ ok ]
 * Unmounting filesystems...  [ ok ]
 * Shutting down the Logical Volume Manager...  [ ok ]
 * Remounting remaining filesystems readonly...  [ ok ]
m:sopn l ddvcs
d d wthdt edol oe
Rsatn ytm
Resetting ... 


Can't open input device.
screen not found.
Can't open input device.
Keyboard not present.  Using ttya for input and output.
Keyboard not present.  Using ttya for input and output.


Sun Enterprise 450 (4 X UltraSPARC-II 400MHz), No Keyboard
OpenBoot 3.16, 4096 MB memory installed, Serial #12871523.
Ethernet address 8:0:20:c4:67:63, Host ID: 80c46763.



Initializing Memory \/|\-/|\
Rebooting with command: boot
Boot device: /pci@6,4000/scsi@3/disk@1,0  File and args: 
SILO Version 1.4.8
boot: linux-2.6.7.new
Allocated 8 Megs of memory at 0x40000000 for kernel
\|/-\|/-......  Loaded kernel version 2.6.7

Remapping the kernel... done.
Booting Linux...
POLB u EEBo rm31. 000/11:2
iu eso .. ro@bn0)(c eso .. 0463(etoLnx334)# M h u 60:01 D 04
RH U4
tentades 80:0c:76
nnd  oapgs 264
 M oe 264pgs IObth8
 omlzn:0pgs IObth1
 ihe oe  ae,LF ac:
ul  oeit
enlcmadln:ro=dvsb
I ahtbeetis 06(re 2 53 ye)
osl:clu um eie8x5
eoy 152kaalbe(40 enlcd,96 aa 6kii)[ff8000000000fe80]
airtn ea op. 9.7BgMP

[snip...]

[snip...]

m:AtdtcigRI ras
d uou .
d . uou OE
koradsatn. o
version 2.85 booting

Gentoo Linux; http://www.gentoo.org/
 Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL

 * Mounting proc at /proc...  [ ok ]
 * Mounting sysfs at /sys...  [ ok ]
 * Mounting devpts at /dev/pts...  [ ok ]
 * Starting devfsd...Started device management daemon v1.3.25 for /dev

Re: [PATCH] SunSAB console problems in 2.6.x

[Ben Collins]

>  * Bringing br0 down... *   Releasing DHCP lease for br0
>   [ ok ]
>  *   Stopping br0
>   [ ok ]
>  * Bringing lo down...  [ ok ]
>  * Stopping devfsd...  [ ok ]
>  * Deactivating swap...  [ ok ]
>  * Unmounting filesystems...  [ ok ]
>  * Shutting down the Logical Volume Manager...  [ ok ]
>  * Remounting remaining filesystems readonly...  [ ok ]
> m:sopn l ddvcs
> d d wthdt edol oe
> Rsatn ytm
> Resetting ... 

So your serial console works for userspace, but is broken from the
kernel? That last "Resetting..." is from the OBP I think.


> Remapping the kernel... done.
> Booting Linux...
> POLB u EEBo rm31. 000/11:2
> iu eso .. ro@bn0)(c eso .. 0463(etoLnx334)# M h u 60:01 D 04

That "Booting Linux..." is from the kernel too, but it's a prom_printf,
not a console (iow, sunsab) call.

> m:AtdtcigRI ras
> d uou .
> d . uou OE
> koradsatn. o
> version 2.85 booting
> 
> Gentoo Linux; http://www.gentoo.org/
>  Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL

And then userspace is ok again.

Dave, what's the difference between userspace going through the tty, and
kernel printk calls going into the console callbacks?

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: [PATCH] SunSAB console problems in 2.6.x

[Ben Collins]

> I'm supposed to be asleep right now, and I won't be back in front of the 
> E450 until about midnight Central Time.  I'll boot 2.6.6 then and post 
> the results.  Would it help to try any of the 2.6.7 release candidates?  
> It grinds out kernels fairly fast...:)

Yeah, if you can narrow down when this problem started, that would be
the easiest way to pinpoint the problem.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: [PATCH] SunSAB console problems in 2.6.x

[Ralph Mitchell]

Ben Collins wrote:

>> * Bringing br0 down... *   Releasing DHCP lease for br0
>>  [ ok ]
>> *   Stopping br0
>>  [ ok ]
>> * Bringing lo down...  [ ok ]
>> * Stopping devfsd...  [ ok ]
>> * Deactivating swap...  [ ok ]
>> * Unmounting filesystems...  [ ok ]
>> * Shutting down the Logical Volume Manager...  [ ok ]
>> * Remounting remaining filesystems readonly...  [ ok ]
>>m:sopn l ddvcs
>>d d wthdt edol oe
>>Rsatn ytm
>>Resetting ... 
>>    
>>
>
>So your serial console works for userspace, but is broken from the
>kernel? That last "Resetting..." is from the OBP I think.
>
>  
>

Ah, yep...  That's exactly how it is.  Sorry, I thought the same was 
happening to other folks as well, or I would have emphasized that oddity.

If it makes any difference, my serial port is:

    ttyS0 at MMIO 0x1fff1400000 (irq = 7969824) is a SAB82532 V3.2

E450, 4x400MHz, kernel 2.6.7.  IIRC this little problem crept in with 
2.6.7.  I have older kernels on the system, but I'm not in a position to 
boot it to check.

I'm supposed to be asleep right now, and I won't be back in front of the 
E450 until about midnight Central Time.  I'll boot 2.6.6 then and post 
the results.  Would it help to try any of the 2.6.7 release candidates?  
It grinds out kernels fairly fast...:)

Oh, BTW, this is absolutely *not* mission-critical for me, so if you 
guys have anything more urgent to deal with, don't let me interrupt.

Thanks,


Ralph Mitchell

Re: [PATCH] SunSAB console problems in 2.6.x

[David S. Miller]

On Thu, 26 Aug 2004 13:01:36 -0400
Ben Collins <bcollins@debian.org> wrote:

> > I'm supposed to be asleep right now, and I won't be back in front of the 
> > E450 until about midnight Central Time.  I'll boot 2.6.6 then and post 
> > the results.  Would it help to try any of the 2.6.7 release candidates?  
> > It grinds out kernels fairly fast...:)
> 
> Yeah, if you can narrow down when this problem started, that would be
> the easiest way to pinpoint the problem.

I was under the impression that this sunsab kernel log output
problem had always been present.  Anyways, if you can find
a 2.6.x where it worked, that would be great :)

Ben, to answer your question, the difference in output for
the console vs. userland is mainly in the setup of the chip.
In particular the initialization of the line.

The big clue is that once userland starts up, and thus opens
the serial line, the output gets sane.  My theory was therefore
that chip init had everything to do with the garbled output.
The actual console character writing code is identical between
2.4.x and 2.6.x in the SAB driver so I really do not think
that is to blame.

Instead, I noticed that hw flow control settings were not being
made in the SAB chip for console init, whereas in 2.4.x they were.
Then I also noticed a hack added to the SunZILOG 2.6.x driver
console code which explicitly set the RTS/DTR properly, and thus
I added it to sunsab.c too in hopes that was the problem.

To wit, two questions for people seeing this problem:

1) Did it work find in some previous 2.6.x version, and if so
   which one?

2) Once userland starts up, the userland messages print out fine
   but are kernel messages still garbled?

Thanks.

Re: [PATCH] SunSAB console problems in 2.6.x

[Joshua Kwan]

David S. Miller wrote:
> 2) Once userland starts up, the userland messages print out fine
>    but are kernel messages still garbled?

Right now I can say yes to this.

-- 
Joshua Kwan

Re: [PATCH] SunSAB console problems in 2.6.x

[David S. Miller]

On Thu, 26 Aug 2004 17:43:01 -0700
Joshua Kwan <joshk@triplehelix.org> wrote:

> David S. Miller wrote:
> > 2) Once userland starts up, the userland messages print out fine
> >    but are kernel messages still garbled?
> 
> Right now I can say yes to this.

Hmmm, does this fix things?

=== drivers/serial/sunsab.c 1.35 vs edited ==--- 1.35/drivers/serial/sunsab.c	2004-08-26 15:38:22 -07:00
+++ edited/drivers/serial/sunsab.c	2004-08-26 17:54:26 -07:00
@@ -83,7 +83,7 @@
 
 static __inline__ void sunsab_tec_wait(struct uart_sunsab_port *up)
 {
-	int timeout = up->tec_timeout;
+	int timeout = SAB82532_MAX_TEC_TIMEOUT /*up->tec_timeout*/;
 
 	while ((readb(&up->regs->r.star) & SAB82532_STAR_TEC) && --timeout)
 		udelay(1);

Re: [PATCH] SunSAB console problems in 2.6.x

[Ralph Mitchell]

Excellent!  That works for me too.

For the record, I found that 2.6.7-rc1 didn't drop every other 
character, while 2.6.7-rc2 and above do.

However, fixing this has exposed something else that I hadn't noticed 
due to it being garbled.  I'm getting this when booting 2.6.7:

    [ snip ]
    Brought up 4 CPUs
    Total of 4 processors activated (3186.68 BogoMIPS).
    SMP: Calibrating ecache flush... Using heuristic of 2295594 cycles, 
5 ticks.
    NET: Registered protocol family 16
    PCI: Probing for controllers.
    PCI: Found PSYCHO, control regs at 000001fe00000000
    PSYCHO: Shared PCI config space at 000001fe01000000
    PCI: Found PSYCHO, control regs at 000001c800000000
    PSYCHO: Shared PCI config space at 000001c801000000
    PCI: Found PSYCHO, control regs at 000001cc00000000
    PSYCHO: Shared PCI config space at 000001cc01000000
    bad: scheduling while atomic!
    Call Trace:
     [0000000000464b14] call_usermodehelper+0xb4/0xe0
     [000000000053e4c0] kset_hotplug+0x1e0/0x280
     [000000000053e71c] kobject_add+0x7c/0x100
     [000000000058ca10] class_device_add+0x50/0x140
     [0000000000562c68] pci_scan_bus_parented+0xe8/0x180
     [0000000000769a08] pbm_scan_bus+0x48/0xe0
     [0000000000769ad4] psycho_scan_bus+0x34/0x60
     [00000000007668e0] pci_scan_each_controller_bus+0x40/0xa0
     [00000000007669fc] pcibios_init+0x1c/0x80
     [00000000007608bc] do_initcalls+0x3c/0xe0
     [0000000000414304] init+0x84/0x240
     [0000000000419530] kernel_thread+0x30/0x60
     [0000000000414190] rest_init+0x10/0x80

The call trace occurs a bunch of times, with an occasional:

    PCI0(PBMB): Bus running at 33MHz

message in between, for various PCIx.  After the last call trace it 
drops through this:

    PCI0(PBMA): Bus running at 66MHz
    ebus0: [auxio] [power] [SUNW,pll] [sc] [se] [su] [su] [ecpp] 
[fdthree] [eeprom] [flashprom] [SUNW,envctrl]

and continues to boot as if everything was peachy keen.

It's entirely possible that I have a stupid combination of kernel config 
options - I've been carrying my .config over from one kernel to the 
next, doing a "make oldconfig" and mostly saying no to any new options.

The above call traces are absent in 2.6.6, occur first in 2.6.7-rc1 and 
also thereafter.  To complete the picture, I'm seeing the same in 
vanilla 2.6.8.

Thanks,

Ralph Mitchell


Joshua Kwan wrote:

>David S. Miller wrote:
>  
>
>>Hmmm, does this fix things?
>>    
>>
>
>Absolutely perfect. You are a god among men.
>
>N.B. the last memcpy patch you sent worked fine as well,
>      as well as the syslog fix. Now we can bootstrap
>      Debian using a 2.6 kernel on sparc64!
>
>Thank you!
>
>  
>

Re: [PATCH] SunSAB console problems in 2.6.x

[David S. Miller]

On Fri, 27 Aug 2004 05:30:42 -0500
Ralph Mitchell <rmitchell@eds.com> wrote:

> However, fixing this has exposed something else that I hadn't noticed 
> due to it being garbled.  I'm getting this when booting 2.6.7:

Turn off PREEMPT people...

Re: [PATCH] SunSAB console problems in 2.6.x

[David S. Miller]

On Fri, 27 Aug 2004 05:30:42 -0500
Ralph Mitchell <rmitchell@eds.com> wrote:

> For the record, I found that 2.6.7-rc1 didn't drop every other 
> character, while 2.6.7-rc2 and above do.

Good clue.

Are all of you guys seeing this problem on uniprocessor?
Ralph, Joshua?

Re: [PATCH] SunSAB console problems in 2.6.x

[Joshua Kwan]

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

David S. Miller wrote:
> Are all of you guys seeing this problem on uniprocessor?
> Ralph, Joshua?

Yeah. Although I thought you'd already fixed it with that patch? Or was 
it just a hack?

-- 
Joshua Kwan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 894 bytes --]

Re: [PATCH] SunSAB console problems in 2.6.x

[David S. Miller]

Delete that SunSAB hack fix, and try this, it is the real bug.

The clue was when Ralph mentioned that 2.6.7-rc1 to rc2 broke
things, and that is when I moved HZ to be 1000 instead of 100
on sparc64.

This mucked up udelay() handling for slower cpu speeds.

Please, when you test this, make absolutely sure you undid the
sunsab.c fixes.  Specifically the first line of the function
sunsab_tec_wait() should read:

	int timeout = up->tec_timeout;

Let me know how it goes.

=== arch/sparc64/kernel/sparc64_ksyms.c 1.80 vs edited ==--- 1.80/arch/sparc64/kernel/sparc64_ksyms.c	2004-08-23 14:36:04 -07:00
+++ edited/arch/sparc64/kernel/sparc64_ksyms.c	2004-08-27 15:41:51 -07:00
@@ -372,6 +372,12 @@
 EXPORT_SYMBOL_NOVERS(memmove);
 EXPORT_SYMBOL_NOVERS(strncmp);
 
+/* Delay routines. */
+EXPORT_SYMBOL(__udelay);
+EXPORT_SYMBOL(__ndelay);
+EXPORT_SYMBOL(__const_udelay);
+EXPORT_SYMBOL(__delay);
+
 void VISenter(void);
 /* RAID code needs this */
 EXPORT_SYMBOL_NOVERS(VISenter);
=== arch/sparc64/lib/Makefile 1.19 vs edited ==--- 1.19/arch/sparc64/lib/Makefile	2004-08-23 14:33:04 -07:00
+++ edited/arch/sparc64/lib/Makefile	2004-08-27 15:25:45 -07:00
@@ -12,7 +12,7 @@
 	 U1memcpy.o U1copy_from_user.o U1copy_to_user.o \
 	 U3memcpy.o U3copy_from_user.o U3copy_to_user.o U3patch.o \
 	 copy_in_user.o user_fixup.o memmove.o \
-	 mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o
+	 mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o delay.o
 
 lib-$(CONFIG_DEBUG_SPINLOCK) += debuglocks.o
 lib-$(CONFIG_HAVE_DEC_LOCK) += dec_and_lock.o
=== include/asm-sparc64/delay.h 1.8 vs edited ==--- 1.8/include/asm-sparc64/delay.h	2003-09-12 20:59:46 -07:00
+++ edited/include/asm-sparc64/delay.h	2004-08-27 15:43:12 -07:00
@@ -1,7 +1,11 @@
-/* $Id: delay.h,v 1.13 2002/02/02 03:33:48 kanoj Exp $
- * delay.h: Linux delay routines on the V9.
+/* delay.h: Linux delay routines on sparc64.
  *
- * Copyright (C) 1996 David S. Miller (davem@caip.rutgers.edu).
+ * Copyright (C) 1996, 2004 David S. Miller (davem@davemloft.net).
+ *
+ * Based heavily upon x86 variant which is:
+ * Copyright (C) 1993 Linus Torvalds
+ *
+ * Delay routines calling functions in arch/sparc64/lib/delay.c
  */
 
 #ifndef __SPARC64_DELAY_H
@@ -13,50 +17,21 @@
 
 #ifndef __ASSEMBLY__
 
-static __inline__ void __delay(unsigned long loops)
-{
-	__asm__ __volatile__(
-"	b,pt	%%xcc, 1f\n"
-"	 cmp	%0, 0\n"
-"	.align	32\n"
-"1:\n"
-"	bne,pt	%%xcc, 1b\n"
-"	 subcc	%0, 1, %0\n"
-	: "=&r" (loops)
-	: "0" (loops)
-	: "cc");
-}
-
-static __inline__ void __udelay(unsigned long usecs, unsigned long lps)
-{
-	usecs *= 0x00000000000010c6UL;		/* 2**32 / 1000000 */
-
-	__asm__ __volatile__(
-"	mulx	%1, %2, %0\n"
-"	srlx	%0, 32, %0\n"
-	: "=r" (usecs)
-	: "r" (usecs), "r" (lps));
-
-	__delay(usecs * HZ);
-}
-
-extern __inline__ void __ndelay(unsigned long usecs, unsigned long lps)
-{
-	usecs *= 0x0000000000000005UL;		/* 2**32 / 10000 */
-
-	__asm__ __volatile__(
-"	mulx	%1, %2, %0\n"
-"	srlx	%0, 32, %0\n"
-	: "=r" (usecs)
-	: "r" (usecs), "r" (lps));
-
-	__delay(usecs * HZ);
-}
-
-#define __udelay_val cpu_data(smp_processor_id()).udelay_val
+extern void __bad_udelay(void);
+extern void __bad_ndelay(void);
 
-#define udelay(usecs) __udelay((usecs),__udelay_val)
-#define ndelay(usecs) __ndelay((usecs),__udelay_val)
+extern void __udelay(unsigned long usecs);
+extern void __ndelay(unsigned long nsecs);
+extern void __const_udelay(unsigned long usecs);
+extern void __delay(unsigned long loops);
+
+#define udelay(n) (__builtin_constant_p(n) ? \
+	((n) > 20000 ? __bad_udelay() : __const_udelay((n) * 0x10c7ul)) : \
+	__udelay(n))
+	
+#define ndelay(n) (__builtin_constant_p(n) ? \
+	((n) > 20000 ? __bad_ndelay() : __const_udelay((n) * 5ul)) : \
+	__ndelay(n))
 
 #endif /* !__ASSEMBLY__ */
 

Re: [PATCH] SunSAB console problems in 2.6.x

[David S. Miller]

On Fri, 27 Aug 2004 16:24:13 -0700
Joshua Kwan <joshk@triplehelix.org> wrote:

> David S. Miller wrote:
> > Are all of you guys seeing this problem on uniprocessor?
> > Ralph, Joshua?
> 
> Yeah. Although I thought you'd already fixed it with that patch? Or was 
> it just a hack?

Just a hack.

See the email I just sent out, it has the correct fix.

Re: [PATCH] SunSAB console problems in 2.6.x

[C.Newport]

On Friday 27 August 2004 11:29 pm, David S. Miller wrote:
> On Fri, 27 Aug 2004 05:30:42 -0500
>
> Ralph Mitchell <rmitchell@eds.com> wrote:
> > For the record, I found that 2.6.7-rc1 didn't drop every other
> > character, while 2.6.7-rc2 and above do.
>
> Good clue.
>
> Are all of you guys seeing this problem on uniprocessor?
> Ralph, Joshua?

FWIW, I saw this problem in a completely different non-linux context
a while ago. It is possible, if the code is tight enough, for modern fast
processors to overwrite the character in a USART transmit register
before the USART has moved it down the internal buffer. 
Introducing a suitable delay fixed it.

Re: [PATCH] SunSAB console problems in 2.6.x

[David S. Miller]

On Sat, 28 Aug 2004 00:34:12 +0100
"C.Newport" <crn@netunix.com> wrote:

> FWIW, I saw this problem in a completely different non-linux context
> a while ago. It is possible, if the code is tight enough, for modern fast
> processors to overwrite the character in a USART transmit register
> before the USART has moved it down the internal buffer. 
> Introducing a suitable delay fixed it.

We protect this by spinning on the sunsab control register waiting
for it to say "character sent and FIFO empty, ready for next char".

It's busted udelay() on sparc64 which is causing this problem.

Re: [PATCH] SunSAB console problems in 2.6.x

[Joshua Kwan]

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

David S. Miller wrote:
> ===== arch/sparc64/lib/Makefile 1.19 vs edited =====
> --- 1.19/arch/sparc64/lib/Makefile	2004-08-23 14:33:04 -07:00
> +++ edited/arch/sparc64/lib/Makefile	2004-08-27 15:25:45 -07:00
> @@ -12,7 +12,7 @@
>  	 U1memcpy.o U1copy_from_user.o U1copy_to_user.o \
>  	 U3memcpy.o U3copy_from_user.o U3copy_to_user.o U3patch.o \
>  	 copy_in_user.o user_fixup.o memmove.o \
> -	 mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o
> +	 mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o delay.o
>  
>  lib-$(CONFIG_DEBUG_SPINLOCK) += debuglocks.o
>  lib-$(CONFIG_HAVE_DEC_LOCK) += dec_and_lock.o

You forgot delay.c.

-- 
Joshua Kwan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 894 bytes --]

Re: [PATCH] SunSAB console problems in 2.6.x

[David S. Miller]

On Fri, 27 Aug 2004 17:01:01 -0700
Joshua Kwan <joshk@triplehelix.org> wrote:

> > -	 mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o
> > +	 mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o delay.o
> >  
> >  lib-$(CONFIG_DEBUG_SPINLOCK) += debuglocks.o
> >  lib-$(CONFIG_HAVE_DEC_LOCK) += dec_and_lock.o
> 
> You forgot delay.c.

Sorry, I'm a retard.

This patch should be better.

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/08/27 16:12:23-07:00 davem@nuts.davemloft.net 
#   [SPARC64]: Fix delay with HZ=1000.
#   
#   When I moved sparc64 over to HZ=1000 this added some
#   problems to the udelay() handling.  Specifically, with
#   slower cpus we could now get underflows to zero for
#   things like udelay(1) due to the order of multiplies
#   and shifts.
#   
#   Fix this, and move it out to arch/sparc64/lib/delay.c
#   so it is easier to tinker with this in the future and
#   also to optimize away one of the multiplies for the
#   constant delay case just like other platforms do.
#   
#   Signed-off-by: David S. Miller <davem@davemloft.net>
# 
# include/asm-sparc64/delay.h
#   2004/08/27 16:10:13-07:00 davem@nuts.davemloft.net +21 -46
#   [SPARC64]: Fix delay with HZ=1000.
# 
# arch/sparc64/lib/Makefile
#   2004/08/27 16:10:13-07:00 davem@nuts.davemloft.net +1 -1
#   [SPARC64]: Fix delay with HZ=1000.
# 
# arch/sparc64/kernel/sparc64_ksyms.c
#   2004/08/27 16:10:13-07:00 davem@nuts.davemloft.net +6 -0
#   [SPARC64]: Fix delay with HZ=1000.
# 
# arch/sparc64/lib/delay.c
#   2004/08/27 16:10:01-07:00 davem@nuts.davemloft.net +49 -0
#   [SPARC64]: Fix delay with HZ=1000.
# 
# arch/sparc64/lib/delay.c
#   2004/08/27 16:10:01-07:00 davem@nuts.davemloft.net +0 -0
#   BitKeeper file /disk1/BK/sparc-2.6/arch/sparc64/lib/delay.c
# 
diff -Nru a/arch/sparc64/kernel/sparc64_ksyms.c b/arch/sparc64/kernel/sparc64_ksyms.c
--- a/arch/sparc64/kernel/sparc64_ksyms.c	2004-08-27 16:48:00 -07:00
+++ b/arch/sparc64/kernel/sparc64_ksyms.c	2004-08-27 16:48:00 -07:00
@@ -372,6 +372,12 @@
 EXPORT_SYMBOL_NOVERS(memmove);
 EXPORT_SYMBOL_NOVERS(strncmp);
 
+/* Delay routines. */
+EXPORT_SYMBOL(__udelay);
+EXPORT_SYMBOL(__ndelay);
+EXPORT_SYMBOL(__const_udelay);
+EXPORT_SYMBOL(__delay);
+
 void VISenter(void);
 /* RAID code needs this */
 EXPORT_SYMBOL_NOVERS(VISenter);
diff -Nru a/arch/sparc64/lib/Makefile b/arch/sparc64/lib/Makefile
--- a/arch/sparc64/lib/Makefile	2004-08-27 16:48:00 -07:00
+++ b/arch/sparc64/lib/Makefile	2004-08-27 16:48:00 -07:00
@@ -12,7 +12,7 @@
 	 U1memcpy.o U1copy_from_user.o U1copy_to_user.o \
 	 U3memcpy.o U3copy_from_user.o U3copy_to_user.o U3patch.o \
 	 copy_in_user.o user_fixup.o memmove.o \
-	 mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o
+	 mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o delay.o
 
 lib-$(CONFIG_DEBUG_SPINLOCK) += debuglocks.o
 lib-$(CONFIG_HAVE_DEC_LOCK) += dec_and_lock.o
diff -Nru a/arch/sparc64/lib/delay.c b/arch/sparc64/lib/delay.c
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/arch/sparc64/lib/delay.c	2004-08-27 16:48:00 -07:00
@@ -0,0 +1,49 @@
+/* delay.c: Delay loops for sparc64
+ *
+ * Copyright (C) 2004 David S. Miller <davem@redhat.com>
+ *
+ * Based heavily upon x86 variant which is:
+ *	Copyright (C) 1993 Linus Torvalds
+ *	Copyright (C) 1997 Martin Mares <mj@atrey.karlin.mff.cuni.cz>
+ */
+
+#include <linux/delay.h>
+
+void __delay(unsigned long loops)
+{
+	__asm__ __volatile__(
+"	b,pt	%%xcc, 1f\n"
+"	 cmp	%0, 0\n"
+"	.align	32\n"
+"1:\n"
+"	bne,pt	%%xcc, 1b\n"
+"	 subcc	%0, 1, %0\n"
+	: "=&r" (loops)
+	: "0" (loops)
+	: "cc");
+}
+
+/* We used to multiply by HZ after shifting down by 32 bits
+ * but that runs into problems for higher values of HZ and
+ * slow cpus.
+ */
+void __const_udelay(unsigned long n)
+{
+	n *= 4;
+
+	n *= (cpu_data(smp_processor_id()).udelay_val * (HZ/4));
+	n >>= 32;
+
+	__delay(n + 1);
+}
+
+void __udelay(unsigned long n)
+{
+	__const_udelay(n * 0x10c7UL);
+}
+
+
+void __ndelay(unsigned long n)
+{
+	__const_udelay(n * 0x5UL);
+}
diff -Nru a/include/asm-sparc64/delay.h b/include/asm-sparc64/delay.h
--- a/include/asm-sparc64/delay.h	2004-08-27 16:48:00 -07:00
+++ b/include/asm-sparc64/delay.h	2004-08-27 16:48:00 -07:00
@@ -1,7 +1,11 @@
-/* $Id: delay.h,v 1.13 2002/02/02 03:33:48 kanoj Exp $
- * delay.h: Linux delay routines on the V9.
+/* delay.h: Linux delay routines on sparc64.
  *
- * Copyright (C) 1996 David S. Miller (davem@caip.rutgers.edu).
+ * Copyright (C) 1996, 2004 David S. Miller (davem@davemloft.net).
+ *
+ * Based heavily upon x86 variant which is:
+ * Copyright (C) 1993 Linus Torvalds
+ *
+ * Delay routines calling functions in arch/sparc64/lib/delay.c
  */
 
 #ifndef __SPARC64_DELAY_H
@@ -13,50 +17,21 @@
 
 #ifndef __ASSEMBLY__
 
-static __inline__ void __delay(unsigned long loops)
-{
-	__asm__ __volatile__(
-"	b,pt	%%xcc, 1f\n"
-"	 cmp	%0, 0\n"
-"	.align	32\n"
-"1:\n"
-"	bne,pt	%%xcc, 1b\n"
-"	 subcc	%0, 1, %0\n"
-	: "=&r" (loops)
-	: "0" (loops)
-	: "cc");
-}
-
-static __inline__ void __udelay(unsigned long usecs, unsigned long lps)
-{
-	usecs *= 0x00000000000010c6UL;		/* 2**32 / 1000000 */
-
-	__asm__ __volatile__(
-"	mulx	%1, %2, %0\n"
-"	srlx	%0, 32, %0\n"
-	: "=r" (usecs)
-	: "r" (usecs), "r" (lps));
-
-	__delay(usecs * HZ);
-}
-
-extern __inline__ void __ndelay(unsigned long usecs, unsigned long lps)
-{
-	usecs *= 0x0000000000000005UL;		/* 2**32 / 10000 */
-
-	__asm__ __volatile__(
-"	mulx	%1, %2, %0\n"
-"	srlx	%0, 32, %0\n"
-	: "=r" (usecs)
-	: "r" (usecs), "r" (lps));
-
-	__delay(usecs * HZ);
-}
-
-#define __udelay_val cpu_data(smp_processor_id()).udelay_val
+extern void __bad_udelay(void);
+extern void __bad_ndelay(void);
 
-#define udelay(usecs) __udelay((usecs),__udelay_val)
-#define ndelay(usecs) __ndelay((usecs),__udelay_val)
+extern void __udelay(unsigned long usecs);
+extern void __ndelay(unsigned long nsecs);
+extern void __const_udelay(unsigned long usecs);
+extern void __delay(unsigned long loops);
+
+#define udelay(n) (__builtin_constant_p(n) ? \
+	((n) > 20000 ? __bad_udelay() : __const_udelay((n) * 0x10c7ul)) : \
+	__udelay(n))
+	
+#define ndelay(n) (__builtin_constant_p(n) ? \
+	((n) > 20000 ? __bad_ndelay() : __const_udelay((n) * 5ul)) : \
+	__ndelay(n))
 
 #endif /* !__ASSEMBLY__ */
 

Re: [PATCH] SunSAB console problems in 2.6.x

[Ralph Mitchell]

Works just fine.  Thanks!  Took me a minute to realise it was a patch 
against 2.6.9-rc1, though.  Are there any stability issues with this 
RC?  If not, I'll leave it running, otherwise I'll go back to 2.6.8.

Works even better with PREEMPT off.  Thought I probably had something 
stupid in the .config  :)

Thanks,

Ralph Mitchell


David S. Miller wrote:

>On Fri, 27 Aug 2004 17:01:01 -0700
>Joshua Kwan <joshk@triplehelix.org> wrote:
>
>  
>
>>>-	 mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o
>>>+	 mcount.o ipcsum.o rwsem.o xor.o splock.o find_bit.o delay.o
>>> 
>>> lib-$(CONFIG_DEBUG_SPINLOCK) += debuglocks.o
>>> lib-$(CONFIG_HAVE_DEC_LOCK) += dec_and_lock.o
>>>      
>>>
>>You forgot delay.c.
>>    
>>
>
>Sorry, I'm a retard.
>
>This patch should be better.
>
># This is a BitKeeper generated diff -Nru style patch.
>#
># ChangeSet
>#   2004/08/27 16:12:23-07:00 davem@nuts.davemloft.net 
>#   [SPARC64]: Fix delay with HZ=1000.
>  
>