Menu
▾
▴
linuxsh-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(82) |
Jun
(72) |
Jul
(39) |
Aug
(104) |
Sep
(61) |
Oct
(55) |
Nov
(101) |
Dec
(48) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(52) |
Feb
(67) |
Mar
(18) |
Apr
(16) |
May
(33) |
Jun
(12) |
Jul
(102) |
Aug
(168) |
Sep
(65) |
Oct
(60) |
Nov
(43) |
Dec
(121) |
| 2002 |
Jan
(69) |
Feb
(32) |
Mar
(90) |
Apr
(59) |
May
(45) |
Jun
(43) |
Jul
(33) |
Aug
(21) |
Sep
(11) |
Oct
(20) |
Nov
(26) |
Dec
(3) |
| 2003 |
Jan
(12) |
Feb
(18) |
Mar
(11) |
Apr
(11) |
May
(41) |
Jun
(76) |
Jul
(77) |
Aug
(15) |
Sep
(38) |
Oct
(56) |
Nov
(19) |
Dec
(39) |
| 2004 |
Jan
(17) |
Feb
(52) |
Mar
(36) |
Apr
(34) |
May
(48) |
Jun
(85) |
Jul
(38) |
Aug
(42) |
Sep
(41) |
Oct
(77) |
Nov
(27) |
Dec
(19) |
| 2005 |
Jan
(32) |
Feb
(35) |
Mar
(29) |
Apr
(8) |
May
(7) |
Jun
(31) |
Jul
(46) |
Aug
(93) |
Sep
(65) |
Oct
(85) |
Nov
(219) |
Dec
(47) |
| 2006 |
Jan
(170) |
Feb
(103) |
Mar
(49) |
Apr
(43) |
May
(45) |
Jun
(29) |
Jul
(77) |
Aug
(82) |
Sep
(43) |
Oct
(45) |
Nov
(26) |
Dec
(85) |
| 2007 |
Jan
(42) |
Feb
(48) |
Mar
(64) |
Apr
(31) |
May
(88) |
Jun
(53) |
Jul
(175) |
Aug
(212) |
Sep
(91) |
Oct
(103) |
Nov
(110) |
Dec
(5) |
| 2008 |
Jan
(20) |
Feb
(11) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(5) |
Sep
(3) |
Oct
(12) |
Nov
|
Dec
|
|
From: kaz K. <kk...@rr...> - 2001-08-17 03:59:26
|
"Bao C. Ha" <ba...@se...> wrote: > It still crashed when $fpscr was set to 0x80004 > > (gdb) p/x $fpscr=0x80004 > $2 = 0x80004 > (gdb) p/x $fpscr > $3 = 0x80004 > (gdb) c > Continuing. > > status=%x [snip] Hmm... I have no idea for the real problem at this point. Anyway, 0x3f737871 is very broken if gdb works correctly and it seems that some bad things occur in shared library. Perhaps, rebuilding libc with gcc -O may be not so bad idea. kaz |
|
From: Bao C. H. <ba...@se...> - 2001-08-17 02:41:50
|
It still crashed when $fpscr was set to 0x80004
(gdb) p/x $fpscr=0x80004
$2 = 0x80004
(gdb) p/x $fpscr
$3 = 0x80004
(gdb) c
Continuing.
status=%x
dum=%f
|AGNUyyyyyyyy?AU@o@@0@L@h@"@U.Y?
A@o@H@ `@
1
?AT@o@
?yyoO@yyyo?yyo?@GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU)
2.97 2
0001120 (experimental)GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
200
01120 (experimental)GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
20001
120 (experimental)?@""-main?@?@test.c/scratch/hotspare/home/baoGNU C 2.97
200011
20 (experimental)?quot?#rem?long long inN__valM?#AAunsigned intint
__sched_paramE__sched_priorityFN# M_pthread_fastlock
> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> kaz Kojima
> Sent: Thursday, August 16, 2001 5:48 PM
> To: lin...@li...
> Subject: [linuxsh-dev] Re: Floating point problem
>
>
> "Bao C. Ha" <ba...@se...> wrote:
> > (gdb) n
> > 14 printf("\n status=%x\n", (int)status);
> > (gdb) set archi sh4
> > The target architecture is assumed to be sh4
> > (gdb) p/x $fpscr
> > $2 = 0x3f737871
> > (gdb) n
> >
> > status=%x
> >
> > dum=%f
> > ......
> > CRASHED!!!
> >
> > So it is the wrong FPU mode. How do we fix it?
>
> Before going ahead, please try
> (gdb) p/x $fpscr=0x80004
> (gdb) c
> instead of p/x $fpscr to confirm the problem. If it works,
> the problem must be caused by $fpscr. If this is the case,
> I think that the real problem is the __fpscr_values table
> in your shared libraries.
>
> The $fpscr value problem is a long standing problem. As you
> know, SH-4 FPU has no individual instructions to handle float
> and double, but a mode flags in $fpscr. So the mixture of
> the float and double arithmetic needs the wierd switching of
> $fpscr value. So, an easiest and only one easy workaround is
> to use double only :-)
>
> GCC uses __fpscr_values for this switching. This table is
> the array of 32-bit words and __fpscr_values[0] is the value
> for float and __fpscr_values[1] is for double. The switchig
> is done by the load from these values to $fpscr. There are
> versions of compiler have problems in this switching, though
> this is not the case in current problem since there is no
> problem with static linking.
> This __fpscr_values table is in libgcc.a and defined as .comm
> symbol originally. But this is not suitable for the shared
> library. The __fpscr_values table is writable to set rounding
> and floating exception mode, so it must be the unique entity.
> The Right Thing is to put it in the shared libgcc like as
> we've done it in our gcc-3.0 patch. So the 2nd workaround is
> to use gcc-3.0 + our SH patch and rebuild all libraries using
> it. But it isn't so easy and will cause another problems.
>
> kaz
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>
|
|
From: NIIBE Y. <gn...@m1...> - 2001-08-17 01:05:37
|
> After that, I'll post some changes to follow the mainline.
Here it is:
* include/asm-sh/keyboard.h (kbd_rate): New function.
* include/asm-sh/io.h (page_to_bus): New macro.
* include/asm-sh/mmzone.h (page_to_phys): Defined.
Index: include/asm-sh/io.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/io.h,v
retrieving revision 1.30
diff -u -r1.30 io.h
--- include/asm-sh/io.h 2001/08/11 01:23:28 1.30
+++ include/asm-sh/io.h 2001/08/17 01:01:10
@@ -405,6 +405,7 @@
#define virt_to_bus virt_to_phys
#define bus_to_virt phys_to_virt
+#define page_to_bus page_to_phys
/*
* readX/writeX() are used to access memory mapped devices. On some
Index: include/asm-sh/keyboard.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/keyboard.h,v
retrieving revision 1.10
diff -u -r1.10 keyboard.h
--- include/asm-sh/keyboard.h 2001/08/08 14:54:58 1.10
+++ include/asm-sh/keyboard.h 2001/08/17 01:01:10
@@ -4,6 +4,7 @@
* $Id: keyboard.h,v 1.10 2001/08/08 14:54:58 yaegashi Exp $
*/
+#include <linux/kd.h>
#include <linux/config.h>
#include <asm/machvec.h>
@@ -39,6 +40,10 @@
}
static __inline__ void kbd_leds(unsigned char leds)
+{
+}
+
+static __inline__ void kbd_rate(struct kbd_repeat *rep)
{
}
Index: include/asm-sh/mmzone.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/mmzone.h,v
retrieving revision 1.3
diff -u -r1.3 mmzone.h
--- include/asm-sh/mmzone.h 2001/08/09 23:52:16 1.3
+++ include/asm-sh/mmzone.h 2001/08/17 01:01:11
@@ -55,5 +55,7 @@
}
#define VALID_PAGE(page) is_valid_page(page)
+#define page_to_phys(page) PHYSADDR(page_address(page))
+
#endif /* CONFIG_DISCONTIGMEM */
#endif
Index: include/asm-sh/page.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/page.h,v
retrieving revision 1.12
diff -u -r1.12 page.h
--- include/asm-sh/page.h 2001/07/27 06:09:47 1.12
+++ include/asm-sh/page.h 2001/08/17 01:01:11
@@ -82,6 +82,7 @@
#ifndef CONFIG_DISCONTIGMEM
#define phys_to_page(phys) (mem_map + (((phys)-__MEMORY_START) >> PAGE_SHIFT))
#define VALID_PAGE(page) ((page - mem_map) < max_mapnr)
+#define page_to_phys(page) (((page - mem_map) << PAGE_SHIFT) + __MEMORY_START)
#endif
#define virt_to_page(kaddr) phys_to_page(__pa(kaddr))
--
|
|
From: kaz K. <kk...@rr...> - 2001-08-17 00:42:36
|
"Bao C. Ha" <ba...@se...> wrote:
> (gdb) n
> 14 printf("\n status=%x\n", (int)status);
> (gdb) set archi sh4
> The target architecture is assumed to be sh4
> (gdb) p/x $fpscr
> $2 = 0x3f737871
> (gdb) n
>
> status=%x
>
> dum=%f
> ......
> CRASHED!!!
>
> So it is the wrong FPU mode. How do we fix it?
Before going ahead, please try
(gdb) p/x $fpscr=0x80004
(gdb) c
instead of p/x $fpscr to confirm the problem. If it works,
the problem must be caused by $fpscr. If this is the case,
I think that the real problem is the __fpscr_values table
in your shared libraries.
The $fpscr value problem is a long standing problem. As you
know, SH-4 FPU has no individual instructions to handle float
and double, but a mode flags in $fpscr. So the mixture of
the float and double arithmetic needs the wierd switching of
$fpscr value. So, an easiest and only one easy workaround is
to use double only :-)
GCC uses __fpscr_values for this switching. This table is
the array of 32-bit words and __fpscr_values[0] is the value
for float and __fpscr_values[1] is for double. The switchig
is done by the load from these values to $fpscr. There are
versions of compiler have problems in this switching, though
this is not the case in current problem since there is no
problem with static linking.
This __fpscr_values table is in libgcc.a and defined as .comm
symbol originally. But this is not suitable for the shared
library. The __fpscr_values table is writable to set rounding
and floating exception mode, so it must be the unique entity.
The Right Thing is to put it in the shared libgcc like as
we've done it in our gcc-3.0 patch. So the 2nd workaround is
to use gcc-3.0 + our SH patch and rebuild all libraries using
it. But it isn't so easy and will cause another problems.
kaz
|
|
From: NIIBE Y. <gn...@m1...> - 2001-08-17 00:26:16
|
Will be installed. After that, I'll post some changes to follow the mainline. -- |
|
From: Bao C. H. <ba...@se...> - 2001-08-16 16:59:47
|
(gdb) n
14 printf("\n status=%x\n", (int)status);
(gdb) set archi sh4
The target architecture is assumed to be sh4
(gdb) p/x $fpscr
$2 = 0x3f737871
(gdb) n
status=%x
dum=%f
......
CRASHED!!!
So it is the wrong FPU mode. How do we fix it?
Thanks.
Bao
> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> kaz Kojima
> Sent: Wednesday, August 15, 2001 8:04 PM
> To: lin...@li...
> Subject: [linuxsh-dev] Re: Floating point problem
>
>
> "Bao C. Ha" <ba...@se...> wrote:
> > -static works
> > -O2 does not work (crash!)
> >
> > Following is a gdb session when it crashes. Note the
> > "correct" values of dum = -0.95105654 and status = 1!
> >
> > Breakpoint 1, main () at test.c:13
> > 13 status = fscanf(fptr,"%f", &dum);
> > (gdb) n
> > 14 printf("\n status=%x\n", (int)status);
> > (gdb) print dum
> > $3 = -0.95105654
> > (gdb) print status
> > $4 = 1
>
> Can you please check the result of the following gdb commands at this
> point?
>
> (gdb) set archi sh4
> (gdb) p/x $fpscr
>
> If you don't get 0x8xxxx as the value of fpscr register, the cause of
> the crash will be the wrong mode of FPU.
>
> kaz
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>
|
|
From: kaz K. <kk...@rr...> - 2001-08-16 03:04:02
|
"Bao C. Ha" <ba...@se...> wrote:
> -static works
> -O2 does not work (crash!)
>
> Following is a gdb session when it crashes. Note the
> "correct" values of dum = -0.95105654 and status = 1!
>
> Breakpoint 1, main () at test.c:13
> 13 status = fscanf(fptr,"%f", &dum);
> (gdb) n
> 14 printf("\n status=%x\n", (int)status);
> (gdb) print dum
> $3 = -0.95105654
> (gdb) print status
> $4 = 1
Can you please check the result of the following gdb commands at this
point?
(gdb) set archi sh4
(gdb) p/x $fpscr
If you don't get 0x8xxxx as the value of fpscr register, the cause of
the crash will be the wrong mode of FPU.
kaz
|
|
From: Bao C. H. <ba...@se...> - 2001-08-16 01:04:28
|
-static works
-O2 does not work (crash!)
Following is a gdb session when it crashes. Note the
"correct" values of dum = -0.95105654 and status = 1!
Breakpoint 1, main () at test.c:13
13 status = fscanf(fptr,"%f", &dum);
(gdb) n
14 printf("\n status=%x\n", (int)status);
(gdb) print dum
$3 = -0.95105654
(gdb) print status
$4 = 1
(gdb) n
status=%x
dum=%f
|AGNUyyyyyyyy?AU@o@@0@L@h@"@U.Y?
A@o@H@ `@
1
?AT@o@
?yyoO@yyyo?yyo?@GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU)
2.97 2
0001120 (experimental)GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
200
01120 (experimental)GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
20001
120 (experimental)?@""-main?@?@test.c/scratch/hotspare/home/baoGNU C 2.97
200011
20 (experimental)?quot?#rem?long long inN__valM?#AAunsigned intint
__sched_paramE__sched_priorityFN# M_pthread_fastlock
I am actually glad that somebody else besides us also sees the
problem.
Thanks.
Bao
> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> kaz Kojima
> Sent: Wednesday, August 15, 2001 6:17 AM
> To: lin...@li...
> Subject: [linuxsh-dev] Re: Floating point problem
>
>
> Stuart Menefy <Stu...@st...> wrote:
> > Yep, I see the same problem here.
> >
> > This is using the RPMS from SourceForge:
> > gcc 2.97 (20001120 + patches)
> > glibc 2.2.2
> > kernel 2.4.7-pre6
> > basically the same set.
> >
> > One other oddity, the garbage which is printed at the end
> doesn't occur
> > when output is redirected to a file, however the floating
> point values
> > print as 0.00000 rather than the negative number.
> >
> > Strange
>
> Indeed.
>
> One possibility is the problem on changing double/float mode of SH-4
> FPU. Is the result same with the option -O2 or -static? I suspect that
> the wrong FPU mode gives such curious behavior.
>
> kaz
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>
|
|
From: kaz K. <kk...@rr...> - 2001-08-15 13:12:16
|
Stuart Menefy <Stu...@st...> wrote: > Yep, I see the same problem here. > > This is using the RPMS from SourceForge: > gcc 2.97 (20001120 + patches) > glibc 2.2.2 > kernel 2.4.7-pre6 > basically the same set. > > One other oddity, the garbage which is printed at the end doesn't occur > when output is redirected to a file, however the floating point values > print as 0.00000 rather than the negative number. > > Strange Indeed. One possibility is the problem on changing double/float mode of SH-4 FPU. Is the result same with the option -O2 or -static? I suspect that the wrong FPU mode gives such curious behavior. kaz |
|
From: David W. <dw...@in...> - 2001-08-15 10:49:34
|
dw...@in... said: + * drivers/net/via-rhine.c: Make some attempt to actually + deal with cache coherency issues rather than just inserting + a couple of wmb() calls. I'm not committing this - it's bogus. The ranges it was trying to flush were uncached anyway, and for some reason the delays introduced by walking the cache entries looking for nonexistent matches were what was making it work. -- dwmw2 |
|
From: Stuart M. <Stu...@st...> - 2001-08-14 23:05:25
|
Yep, I see the same problem here. This is using the RPMS from SourceForge: gcc 2.97 (20001120 + patches) glibc 2.2.2 kernel 2.4.7-pre6 basically the same set. One other oddity, the garbage which is printed at the end doesn't occur when output is redirected to a file, however the floating point values print as 0.00000 rather than the negative number. Strange Stuart On Aug 14, 11:38am, kk...@rr... wrote: > Subject: [linuxsh-dev] Re: Floating point problem > "Bao C. Ha" <ba...@se...> wrote: > > gcc-2.97 > > libc-2.2.2.so > > kernel 2.4.5 > > Hmm... It looks like the standard set. Does anyone see the same > problem? > > kaz > > _______________________________________________ > linuxsh-dev mailing list > lin...@li... > http://lists.sourceforge.net/lists/listinfo/linuxsh-dev > > >-- End of excerpt from kk...@rr... |
|
From: David W. <dw...@in...> - 2001-08-14 14:49:19
|
Dav...@st... said: > I agree. Calling flush_cache_all() was simply done for expediency, I > just never had the time to do it properly. I think it should be faster > doing it this way, as you don't need to flush the icache. OK, committed. Next I need to clean up some broken drivers... Index: ChangeLog =================================================================== RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v retrieving revision 1.328 diff -u -r1.328 ChangeLog --- ChangeLog 2001/08/14 14:44:58 1.328 +++ ChangeLog 2001/08/14 14:48:09 @@ -1,5 +1,8 @@ 2001-08-14 David Woodhouse <dw...@in...> + * drivers/net/via-rhine.c: Make some attempt to actually + deal with cache coherency issues rather than just inserting + a couple of wmb() calls. * arch/sh/kernel/pci-dma.c: Use dma_cache_wback_inv() in pci_alloc_consistent instead of flush_cache_all(), which is a nop on SH3. If the size is so large that it's quicker just Index: drivers/net/via-rhine.c =================================================================== RCS file: /cvsroot/linuxsh/kernel/drivers/net/via-rhine.c,v retrieving revision 1.9 diff -u -r1.9 via-rhine.c --- drivers/net/via-rhine.c 2001/07/18 02:54:27 1.9 +++ drivers/net/via-rhine.c 2001/08/14 14:48:09 @@ -69,6 +69,9 @@ - Manfred Spraul: use "singlecopy" for unaligned buffers don't allocate bounce buffers for !ReqTxAlign cards + LK1.1.11: + - David Woodhouse: PCI DMA cache coherency fixes. + */ @@ -151,7 +154,7 @@ /* These identify the driver base version and may not be removed. */ static char version[] __devinitdata = -KERN_INFO "via-rhine.c:v1.10-LK1.1.10 07/12/2001 Written by Donald Becker\n" +KERN_INFO "via-rhine.c:v1.10-LK1.1.11 14/08/2001 Written by Donald Becker\n" KERN_INFO " http://www.scyld.com/network/via-rhine.html\n"; static char shortname[] __devinitdata = "via-rhine"; @@ -758,8 +761,9 @@ TX_RING_SIZE * sizeof(struct tx_desc), np->rx_ring, np->rx_ring_dma); - pci_free_consistent(np->pdev, PKT_BUF_SZ * TX_RING_SIZE, - np->tx_bufs, np->tx_bufs_dma); + if(np->tx_bufs) + pci_free_consistent(np->pdev, PKT_BUF_SZ * TX_RING_SIZE, + np->tx_bufs, np->tx_bufs_dma); } @@ -801,6 +805,8 @@ np->rx_ring[i].addr = cpu_to_le32(np->rx_skbuff_dma[i]); np->rx_ring[i].rx_status = cpu_to_le32(DescOwn); } + pci_dma_sync_single(np->pdev, np->rx_ring_dma, + RX_RING_SIZE * sizeof(struct rx_desc), PCI_DMA_TODEVICE); np->dirty_rx = (unsigned int)(i - RX_RING_SIZE); } @@ -821,6 +827,8 @@ } np->rx_skbuff[i] = 0; } + pci_dma_sync_single(np->pdev, np->rx_ring_dma, + RX_RING_SIZE * sizeof(struct rx_desc), PCI_DMA_TODEVICE); } static void alloc_tbufs(struct net_device* dev) @@ -841,6 +849,9 @@ } np->tx_ring[i-1].next_desc = cpu_to_le32(np->tx_ring_dma); + pci_dma_sync_single(np->pdev, np->tx_ring_dma, + TX_RING_SIZE * sizeof(struct tx_desc), PCI_DMA_TODEVICE); + } static void free_tbufs(struct net_device* dev) @@ -863,6 +874,8 @@ np->tx_skbuff[i] = 0; np->tx_buf[i] = 0; } + pci_dma_sync_single(np->pdev, np->tx_ring_dma, + TX_RING_SIZE * sizeof(struct tx_desc), PCI_DMA_TODEVICE); } static void init_registers(struct net_device *dev) @@ -1124,6 +1137,8 @@ return 0; } skb_copy_and_csum_dev(skb, np->tx_buf[entry]); + pci_dma_sync_single(np->pdev, np->tx_bufs_dma + entry*PKT_BUF_SZ, + PKT_BUF_SZ, PCI_DMA_TODEVICE); np->tx_skbuff_dma[entry] = 0; np->tx_ring[entry].addr = cpu_to_le32(np->tx_bufs_dma + (np->tx_buf[entry] - np->tx_bufs)); @@ -1136,16 +1151,17 @@ np->tx_ring[entry].desc_length = cpu_to_le32(0x00E08000 | (skb->len >= ETH_ZLEN ? skb->len : ETH_ZLEN)); + pci_dma_sync_single(np->pdev, np->tx_ring_dma * entry * sizeof(struct tx_desc), sizeof(struct tx_desc), PCI_DMA_TODEVICE); + /* lock eth irq */ spin_lock_irq (&np->lock); - wmb(); + np->tx_ring[entry].tx_status = cpu_to_le32(DescOwn); - wmb(); + pci_dma_sync_single(np->pdev, np->tx_ring_dma * entry * sizeof(struct tx_desc), sizeof(struct tx_desc), PCI_DMA_TODEVICE); + np->cur_tx++; - /* Non-x86 Todo: explicitly flush cache lines here. */ - /* Wake the potentially-idle transmit channel. */ writew(CmdTxDemand | np->chip_cmd, dev->base_addr + ChipCmd); @@ -1215,6 +1231,9 @@ struct netdev_private *np = dev->priv; int txstatus = 0, entry = np->dirty_tx % TX_RING_SIZE; + pci_dma_sync_single(np->pdev, np->tx_ring_dma, + TX_RING_SIZE * sizeof(struct tx_desc), PCI_DMA_FROMDEVICE); + spin_lock (&np->lock); /* find and cleanup dirty tx descriptors */ @@ -1264,6 +1283,8 @@ struct netdev_private *np = dev->priv; int entry = np->cur_rx % RX_RING_SIZE; int boguscnt = np->dirty_rx + RX_RING_SIZE - np->cur_rx; + + pci_dma_sync_single(np->pdev, np->rx_ring_dma, RX_RING_SIZE * sizeof(struct rx_desc), PCI_DMA_FROMDEVICE); if (debug > 4) { printk(KERN_DEBUG " In via_rhine_rx(), entry %d status %8.8x.\n", @@ -1368,6 +1389,8 @@ } np->rx_ring[entry].rx_status = cpu_to_le32(DescOwn); } + + pci_dma_sync_single(np->pdev, np->rx_ring_dma, RX_RING_SIZE * sizeof(struct rx_desc), PCI_DMA_TODEVICE); /* Pre-emptively restart Rx engine. */ writew(CmdRxDemand | np->chip_cmd, dev->base_addr + ChipCmd); -- dwmw2 |
|
From: David M. <Dav...@st...> - 2001-08-14 14:39:27
|
On Aug 14, 3:26pm, dw...@in... wrote: > Subject: [linuxsh-dev] Small fix for PCI DMA code. > > If we really care about it being faster to flush the whole cache instead of > looping over a large virtual address range, then the arch-specific cache > code should make that call, depending on the size of the cache actually > present on the current CPU, etc. It doesn't belong in the generic > pci_alloc_consistent(), imo. > > OK? I agree. Calling flush_cache_all() was simply done for expediency, I just never had the time to do it properly. I think it should be faster doing it this way, as you don't need to flush the icache. Yet another thing gone from my TODO list! Cheers! -- Dave McKay Software Engineer STMicroelectronics Email: dav...@st... |
|
From: David W. <dw...@in...> - 2001-08-14 14:26:45
|
If we really care about it being faster to flush the whole cache instead of looping over a large virtual address range, then the arch-specific cache code should make that call, depending on the size of the cache actually present on the current CPU, etc. It doesn't belong in the generic pci_alloc_consistent(), imo. OK? Index: ChangeLog =================================================================== RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v retrieving revision 1.327 diff -u -r1.327 ChangeLog --- ChangeLog 2001/08/11 10:18:29 1.327 +++ ChangeLog 2001/08/14 14:23:25 @@ -1,3 +1,11 @@ +2001-08-14 David Woodhouse <dw...@in...> + + * arch/sh/kernel/pci-dma.c: Use dma_cache_wback_inv() in + pci_alloc_consistent instead of flush_cache_all(), which is + a nop on SH3. If the size is so large that it's quicker just + to flush the whole cache, that's a decision for the + arch-specific cache management code to make. + 2001-08-11 David Woodhouse <dw...@in...> * arch/sh/config.in: New CONFIG_SH_PCIDMA_NONCOHERENT option Index: arch/sh/kernel/pci-dma.c =================================================================== RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/pci-dma.c,v retrieving revision 1.1 diff -u -r1.1 pci-dma.c --- arch/sh/kernel/pci-dma.c 2001/05/09 07:40:23 1.1 +++ arch/sh/kernel/pci-dma.c 2001/08/14 14:23:25 @@ -29,7 +29,7 @@ *dma_handle = virt_to_bus(ret); } /* We must flush the cache before we pass it on to the device */ - flush_cache_all(); + dma_cache_wback_inv(ret, size); return P2SEGADDR(ret); } -- dwmw2 |
|
From: M. R. B. <mr...@0x...> - 2001-08-14 03:15:44
|
* kaz Kojima <kk...@rr...> on Tue, Aug 14, 2001: > > I'd like to report again about the status of gcc. > GCC-3.0 seems to be fairly stable and almost essential compiler patches > are sent to the GCC mailing list. Some of them are reviewed already > and some patches waiting to review. You can see our 3.0 patch is still > big. Almost of them are the configury patches for the non-multilib > configurations such sh3-unknown-linux-gnu. Niibe-san sent it to the GCC > mailing list already. This part was the target of arguments, repeatedly. > We tried first to fix config.sub which is the root of such configury, > but many people usually think that four (i.e. sh[34](eb)) is "too many". > The change of config.sub is approved and the argument is continued about > the configury problem in GCC mailing list. > Well, I've been working on my own solution to this problem, but I'm afraid I agree with the others for sh-unknown-linux-gnu, and the removal of multilib for the Linux target. My fix consists of some new config.sub targets, but not of the "eb,el" variety since that wouldn't allow you to do sh3e* as it would conflict with sh3el or sh3eb. Also, I've made some changes to sh.h to try to enable the "sh[1-4][bl]e" to work on all sh targets, not just Linux. I'll try to clean up what I have and send it here for review. Nahh, I don't think that's too many, have you seen the entries for ARM and MIPS (not to mention ix86)? Ugh. > There are some ad hoc ones in our 3.0 patch, which will be never sent > main stream. They are not the Right Thing or solved by the complete > other way in 3.1. The former cases are wired. For example, some correct > SH specific part added in 3.0 are reverted. This is totally wrong, but > if not to do so, gcc-3.0 stage 3 compiler will die. Such part is correct > itself but reveals the another dark problem. Unfortunately, I couldn't > even make an appropriate testcase. > Anyways, I don't think gcc-3.0 is more stable than 20001120 version or > Abe-san's version. > Yes, gcc-3.x has many attractive features, but don't forget it isn't so > stable even for x86. > Wow, thanks for the info, I've been using the patches on your page for awhile, but never really knew the reasons/motivation for them. M. R. |
|
From: kaz K. <kk...@rr...> - 2001-08-14 02:33:09
|
"Bao C. Ha" <ba...@se...> wrote: > gcc-2.97 > libc-2.2.2.so > kernel 2.4.5 Hmm... It looks like the standard set. Does anyone see the same problem? kaz |
|
From: kaz K. <kk...@rr...> - 2001-08-14 02:17:06
|
"M. R. Brown" <mr...@0x...> wrote: >> I can't reproduce your problem on my platforms. It works with >> gcc-2.97(20001120), gcc-3.0 and even broken gcc-3.1, though >> my environment will differ from yours in libraries. >> Which version of glibc are you using? If it was compiled by >> yourself, which gcc was used for? >> > > Hmm, you got broken gcc-3.1 to build? How? Mine bricks when building > libgcc (internal compiler error in flow.c). I'll put the patch for current cvs http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/gcc-cvs-010814.diff http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/gcc-cvs-010515-2add.tar.gz though it's really broken. The regression test by make check for stage1 compiler reports only 3 non essential FAILs, but gcc doesn't bootstrap. The stage2 compiler can't compile any program. It seems that there is a weird bug which happens only for big funtions, at least, in SH. This is too bad. So the patch is only for reference. Never use it for the real work. I'd like to report again about the status of gcc. GCC-3.0 seems to be fairly stable and almost essential compiler patches are sent to the GCC mailing list. Some of them are reviewed already and some patches waiting to review. You can see our 3.0 patch is still big. Almost of them are the configury patches for the non-multilib configurations such sh3-unknown-linux-gnu. Niibe-san sent it to the GCC mailing list already. This part was the target of arguments, repeatedly. We tried first to fix config.sub which is the root of such configury, but many people usually think that four (i.e. sh[34](eb)) is "too many". The change of config.sub is approved and the argument is continued about the configury problem in GCC mailing list. There are some ad hoc ones in our 3.0 patch, which will be never sent main stream. They are not the Right Thing or solved by the complete other way in 3.1. The former cases are wired. For example, some correct SH specific part added in 3.0 are reverted. This is totally wrong, but if not to do so, gcc-3.0 stage 3 compiler will die. Such part is correct itself but reveals the another dark problem. Unfortunately, I couldn't even make an appropriate testcase. Anyways, I don't think gcc-3.0 is more stable than 20001120 version or Abe-san's version. Yes, gcc-3.x has many attractive features, but don't forget it isn't so stable even for x86. kaz |
|
From: Bao C. H. <ba...@se...> - 2001-08-14 01:08:55
|
gcc-2.97 libc-2.2.2.so kernel 2.4.5 Thanks. Bao > -----Original Message----- > From: lin...@li... > [mailto:lin...@li...]On Behalf Of > kaz Kojima > Sent: Monday, August 13, 2001 4:41 PM > To: lin...@li... > Subject: [linuxsh-dev] Re: Floating point problem > > > "Bao C. Ha" <ba...@se...> wrote: > > I am having problems with the following code. It works fine > > in an x86 system. The problem is at the minus sign of the > > datum. The scanf is doing something weird. Changing "%f" > > to "%lf" in the scanf statement makes it work again. > > I can't reproduce your problem on my platforms. It works with > gcc-2.97(20001120), gcc-3.0 and even broken gcc-3.1, though > my environment will differ from yours in libraries. > Which version of glibc are you using? If it was compiled by > yourself, which gcc was used for? > > kaz > > _______________________________________________ > linuxsh-dev mailing list > lin...@li... > http://lists.sourceforge.net/lists/listinfo/linuxsh-dev > |
|
From: M. R. B. <mr...@0x...> - 2001-08-13 23:55:47
|
* kaz Kojima <kk...@rr...> on Tue, Aug 14, 2001: > > I can't reproduce your problem on my platforms. It works with > gcc-2.97(20001120), gcc-3.0 and even broken gcc-3.1, though > my environment will differ from yours in libraries. > Which version of glibc are you using? If it was compiled by > yourself, which gcc was used for? > Hmm, you got broken gcc-3.1 to build? How? Mine bricks when building libgcc (internal compiler error in flow.c). M. R. |
|
From: kaz K. <kk...@rr...> - 2001-08-13 23:36:10
|
"Bao C. Ha" <ba...@se...> wrote: > I am having problems with the following code. It works fine > in an x86 system. The problem is at the minus sign of the > datum. The scanf is doing something weird. Changing "%f" > to "%lf" in the scanf statement makes it work again. I can't reproduce your problem on my platforms. It works with gcc-2.97(20001120), gcc-3.0 and even broken gcc-3.1, though my environment will differ from yours in libraries. Which version of glibc are you using? If it was compiled by yourself, which gcc was used for? kaz |
|
From: Bao C. H. <ba...@se...> - 2001-08-13 18:33:50
|
I am having problems with the following code. It works fine
in an x86 system. The problem is at the minus sign of the
datum. The scanf is doing something weird. Changing "%f"
to "%lf" in the scanf statement makes it work again.
==== test.c =====
[bao@build bao]$ cat test.c
#include <inttypes.h>
#include <stdio.h>
#include <stdlib.h>
int main()
{
FILE *fptr;
float dum;
int status;
fptr=fopen("./DATA", "r");
while (!feof(fptr)){
status = fscanf(fptr,"%f", &dum);
printf("\n status=%x\n", (int)status);
if (status)
printf("\n dum=%f\n", dum);
}
}
[bao@build bao]$ sh4-linux-gcc test.c -o test
=== Output of test ===
[root@mgatebao /root]# ./test
status=1
dum=0.000000
status=1
dum=0.951057
status=1
dum=0.587785
status=%x
dum=%f
|AGNUÿÿÿÿÿÿÿÿ¨A¼@Ø@ô@@,@H@d@M¬
À@ä@D@ @@
±
ATÔ@þÿÿo´@ÿÿÿoðÿÿo @GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
200
01120 (experimental)GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
20001
120 (experimental)GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
2000112
0
(experimental).symtab.strtab.shstrtab.interp.hash.dynsym.dynstr.gnu.version.
gn
u.version_r.rela.plt.init.plt.text.fini.rodata.data.note.ABI-tag.ctors.dtors
.got
.dynamic.sbss.bss.commentô<)
D@D 1ä@ä»9ÿÿÿo @ Fþÿÿo´@´ UÔ@ÔT
_@@@V
e@àj@@
@LÀ@À6 v0§ô@D@ä@ @´@Ô@@@xA A@¨A¨®AA¹öF Âð
À@
ø@
PApAxAA¨AAAñÿAñÿñÿñÿñÿñÿñÿÊ°@
Segmentation fault
=== Input: DATA ===
[root@mgatebao /root]# cat DATA
0.0000000e+000
9.5105652e-001
+5.8778525e-001
-9.5105652e-001
==================
Appreciate any suggestions/comments.
Thanks.
Bao
|
|
From: NIIBE Y. <gn...@m1...> - 2001-08-11 07:15:56
|
Will be installed. Nothing SuperH related. -- |
|
From: David W. <dw...@in...> - 2001-08-10 17:20:19
|
dw...@in... said:
> Next, of course, I'll need to make the PCI DMA code actually use
> these functions as appropriate.
Done. The new config option CONFIG_SH_PCIDMA_NONCOHERENT is hard-coded off
for now, because there's no code yet for the boards which actually need it.
Unless anybody objects, I'll commit this soon.
Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.324
diff -u -r1.324 ChangeLog
--- ChangeLog 2001/08/10 14:13:13 1.324
+++ ChangeLog 2001/08/10 17:02:40
@@ -1,3 +1,10 @@
+2001-08-10 David Woodhouse <dw...@in...>
+
+ * arch/sh/config.in: New CONFIG_SH_PCIDMA_NONCOHERENT option
+ * include/asm-sh/pci.h: Include cache management calls for the
+ case where the above option is set.
+ * arch/sh/kernel/sh_ksyms.c: include linux/pci.h not asm/pci.h
+
2001-08-10 NIIBE Yutaka <gn...@m1...>
* arch/sh/mm/cache-sh4.c (__flush_wback_region,
Index: arch/sh/config.in
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/config.in,v
retrieving revision 1.55
diff -u -r1.55 config.in
--- arch/sh/config.in 2001/07/30 13:02:58 1.55
+++ arch/sh/config.in 2001/08/10 17:02:40
@@ -174,6 +174,7 @@
if [ "$CONFIG_PCI_GODIRECT" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
define_bool CONFIG_PCI_DIRECT y
fi
+ define_bool CONFIG_SH_PCIDMA_NONCOHERENT n
fi
source drivers/pci/Config.in
Index: include/asm-sh/pci.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/pci.h,v
retrieving revision 1.12
diff -u -r1.12 pci.h
--- include/asm-sh/pci.h 2001/07/27 06:09:47 1.12
+++ include/asm-sh/pci.h 2001/08/10 17:02:40
@@ -3,6 +3,8 @@
#ifdef __KERNEL__
+#include <linux/config.h>
+
/* Can be used to override the logic in pci_scan_bus for skipping
already-configured bus numbers - to be used for buggy BIOSes
or architectures with incomplete PCI setup by the loader */
@@ -76,9 +78,14 @@
* until either pci_unmap_single or pci_dma_sync_single is performed.
*/
static inline dma_addr_t pci_map_single(struct pci_dev *hwdev, void *ptr,
- size_t size,int directoin)
+ size_t size, int direction)
{
- flush_cache_all();
+ if (direction == PCI_DMA_NONE)
+ BUG();
+
+#ifdef CONFIG_SH_PCIDMA_NONCOHERENT
+ dma_cache_wback_inv(ptr, size);
+#endif
return virt_to_bus(ptr);
}
@@ -111,9 +118,17 @@
* the same here.
*/
static inline int pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
- int nents,int direction)
+ int nents, int direction)
{
- flush_cache_all();
+#ifdef CONFIG_SH_PCIDMA_NONCOHERENT
+ int i;
+
+ for (i=0; i<nents; i++)
+ dma_cache_wback_inv(sg[i].address, sg[i].length);
+#endif
+ if (direction == PCI_DMA_NONE)
+ BUG();
+
return nents;
}
@@ -122,7 +137,7 @@
* pci_unmap_single() above.
*/
static inline void pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg,
- int nents,int direction)
+ int nents, int direction)
{
/* Nothing to do */
}
@@ -138,9 +153,15 @@
*/
static inline void pci_dma_sync_single(struct pci_dev *hwdev,
dma_addr_t dma_handle,
- size_t size,int direction)
+ size_t size, int direction)
{
- /* Nothing to do */
+ if (direction == PCI_DMA_NONE)
+ BUG();
+
+#ifdef CONFIG_SH_PCIDMA_NONCOHERENT
+ dma_cache_wback_inv(bus_to_virt(dma_handle), size);
+#endif
+
}
/* Make physical memory consistent for a set of streaming
@@ -151,9 +172,17 @@
*/
static inline void pci_dma_sync_sg(struct pci_dev *hwdev,
struct scatterlist *sg,
- int nelems,int direction)
+ int nelems, int direction)
{
- /* Nothing to do */
+ if (direction == PCI_DMA_NONE)
+ BUG();
+
+#ifdef CONFIG_SH_PCIDMA_NONCOHERENT
+ int i;
+
+ for (i=0; i<nelems; i++)
+ dma_cache_wback_inv(sg[i].address, sg[i].length);
+#endif
}
Index: arch/sh/kernel/sh_ksyms.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/sh_ksyms.c,v
retrieving revision 1.18
diff -u -r1.18 sh_ksyms.c
--- arch/sh/kernel/sh_ksyms.c 2001/05/28 10:34:17 1.18
+++ arch/sh/kernel/sh_ksyms.c 2001/08/10 17:02:40
@@ -9,6 +9,7 @@
#include <linux/interrupt.h>
#include <linux/smp_lock.h>
#include <linux/vmalloc.h>
+#include <linux/pci.h>
#include <asm/semaphore.h>
#include <asm/processor.h>
@@ -18,7 +19,6 @@
#include <asm/hardirq.h>
#include <asm/delay.h>
#include <asm/pgalloc.h>
-#include <asm/pci.h>
#include <linux/irq.h>
extern void dump_thread(struct pt_regs *, struct user *);
--
dwmw2
|
|
From: NIIBE Y. <gn...@m1...> - 2001-08-10 14:03:30
|
2001-08-10 NIIBE Yutaka <gn...@m1...>
* arch/sh/mm/cache-sh4.c (__flush_wback_region,
__flush_purge_region): Comment fix for the arguments.
* arch/sh/mm/cache-sh3.c (__flush_wback_region,
__flush_purge_region): Likewise.
Index: arch/sh/mm/cache-sh3.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/cache-sh3.c,v
retrieving revision 1.3
diff -u -r1.3 cache-sh3.c
--- arch/sh/mm/cache-sh3.c 2001/08/10 13:58:55 1.3
+++ arch/sh/mm/cache-sh3.c 2001/08/10 14:01:05
@@ -148,7 +148,8 @@
* Is this really worth it, or should we just alias this routine
* to __flush_purge_region too?
*
- * START, END: Virtual Address (U0, P1, or P3)
+ * START: Virtual Address (U0, P1, or P3)
+ * SIZE: Size of the region.
*/
void __flush_wback_region(void *start, int size)
@@ -180,7 +181,8 @@
/*
* Write back the dirty D-caches and invalidate them.
*
- * START, END: Virtual Address (U0, P1, or P3)
+ * START: Virtual Address (U0, P1, or P3)
+ * SIZE: Size of the region.
*/
void __flush_purge_region(void *start, int size)
{
Index: arch/sh/mm/cache-sh4.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/cache-sh4.c,v
retrieving revision 1.14
diff -u -r1.14 cache-sh4.c
--- arch/sh/mm/cache-sh4.c 2001/08/09 00:27:04 1.14
+++ arch/sh/mm/cache-sh4.c 2001/08/10 14:01:05
@@ -107,7 +107,8 @@
/*
* Write back the dirty D-caches, but not invalidate them.
*
- * START, END: Virtual Address (U0, P1, or P3)
+ * START: Virtual Address (U0, P1, or P3)
+ * SIZE: Size of the region.
*/
void __flush_wback_region(void *start, int size)
{
@@ -127,7 +128,8 @@
/*
* Write back the dirty D-caches and invalidate them.
*
- * START, END: Virtual Address (U0, P1, or P3)
+ * START: Virtual Address (U0, P1, or P3)
+ * SIZE: Size of the region.
*/
void __flush_purge_region(void *start, int size)
{
--
|
|
From: NIIBE Y. <gn...@m1...> - 2001-08-10 13:52:14
|
Looks good. One note: the comments about argument END are wrong (that's my falut). I'll fix cache-sh4.c as well. David Woodhouse wrote: > Next, of course, I'll need to make the PCI DMA code actually use these > functions as appropriate. OK, do you have account on SourceForge? If you have, I'll add you as developper so that you can commit the changes by yourself. Let me know. -- |
25 messages has been excluded from this view by a project administrator.
