Menu
▾
▴
linuxsh-shmedia-dev — Linux kernel development for the SHmedia architecture
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(11) |
Jul
(5) |
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
(18) |
Apr
(7) |
May
(8) |
Jun
(19) |
Jul
(16) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
|
Jul
(2) |
Aug
(1) |
Sep
(7) |
Oct
|
Nov
|
Dec
(2) |
| 2005 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
(10) |
Jun
|
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
(4) |
Dec
(1) |
| 2006 |
Jan
(41) |
Feb
(41) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
|
From: Mr.Adam U. <ada...@ho...> - 2003-06-30 22:44:48
|
Dear Friend=2E As you read this=2C I don't want you to feel sorry for me=2C because=2C I believe everyone will die someday=2E My name is Adam Ugo=2C a merchant inNigeria=2C in the south africa have been diagnosed with Esophageal cancer which was discovered very late=2C due to my laxity in carrying for my health=2E It has defiled all forms of medicine=2C and right now I have only about a few months to live=2C according to medical experts=2E I have not particularly lived my life so well=2C as I never really cared for anyone not even myself but my business=2E Though I am very rich=2C I was never generous=2C I was always hostile to people and only focus on my business as that was the only thing I cared for=2E But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world=2E I believe when God gives me a second chance to come to this world I would live my life a different way from how I have lived it=2E Now that God ! has called me=2C I have willed and given most of my properties and assets to my immediate and extended family members and as well as a few close friends=2E I want God to be merciful to me and accept my soul and so=2C I have decided to give alms to charity organizations=2C as I want this to be one of the last good deeds I do on earth=2E So far=2C I have distributed money to some charity organizations in the U=2EA=2EE=2C Algeria and Malaysia=2E Now that my health has deteriorated so badly=2C I cannot do this my self any more=2E I once asked members of my family to close one of my accounts and distribute the money which I have there to charity organization in Bulgaria and Pakistan=2C they refused and kept the money to themselves=2E Hence=2C I do not trust them anymore=2C as they seem not to be contended with what I have left for them=2E The last of my money which no one knows of is the huge cash deposit of twenty four million dollars that I have with a security and finance limited in Amsterdam=2E I will want you to help me collect this deposit and dispatched it to charity organizations=2Eemail me at this address =28adamugo1=40zwallet=2Ecom=29 with your telephone and fax Numbers=2Cso that i can contact you=2E I have set aside 30% for you for your time and patience=2E God be with you=2E Adam Ugo=09 |
|
From: Paul M. <le...@li...> - 2003-06-30 21:41:23
|
On Mon, Jun 30, 2003 at 06:31:50PM +0100, Richard Curnow wrote:
> The wierd behaviour is gone. I'm trying a larger test now, but I need
> to go home ASAP so will probably need to finish it in the morning.
>=20
> Anyway, it's looking like cache coherency around PCI DMA that might be
> the problem?
>=20
I see one potential user that might be a problem.. looking at the driver
itself, in __sync_scsi_data(), it wraps to pci_dma_sync_sg() and
pci_dma_sync_single() .. we're covered for the first one, but not the latte=
r.
Try this patch out, see if it helps any:
--- shmedia-2.4.test/include/asm-sh64/pci.h Mon Jun 30 17:30:50 2003
+++ shmedia-2.4/include/asm-sh64/pci.h Mon Jun 30 17:33:20 2003
@@ -210,7 +210,10 @@
dma_addr_t dma_handle,
size_t size,int direction)
{
- /* Nothing to do */
+ if (direction =3D=3D PCI_DMA_NONE)
+ BUG();
+=09
+ dma_cache_wback_inv(bus_to_virt(dma_handle), size);
}
=20
Once these issues are worked out, we can optimize the flush itself based off
of the dma direction .. though it makes sense to have things working first
prior to trying to optimize the corner cases.
|
|
From: Richard C. <Ric...@su...> - 2003-06-30 17:32:00
|
* Paul Mundt <le...@li...> [2003-06-30]: > What about if you boot with the caches disabled? Does the same corruption > persist? I was starting to wonder about cache coherency myself. Anyway following your suggestion I've configured out the D$. And here we have a smoking gun. Based on a very simple test 1. mke2fs 2. e2fsck 3. mount 4. cp file to partition 5. sync 6. umount 7. dumpe2fs (shows clean) 8. e2fsck -f The wierd behaviour is gone. I'm trying a larger test now, but I need to go home ASAP so will probably need to finish it in the morning. Anyway, it's looking like cache coherency around PCI DMA that might be the problem? -- Richard \\\ SuperH Core+Debug Architect /// .. At home .. P. /// ric...@su... /// rc...@rc... Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk |
|
From: Paul M. <le...@li...> - 2003-06-30 16:37:14
|
On Mon, Jun 30, 2003 at 05:17:10PM +0100, Richard Curnow wrote: > So overall it's close, but nowhere near good enough to be a production > filesystem. I've no idea if the remaining problems I'm seeing are > hardware or software related. Some behaviour looks like it could be > coherency related, either between cache and memory, or between memory > and disc. >=20 What about if you boot with the caches disabled? Does the same corruption persist? |
|
From: Richard C. <Ric...@su...> - 2003-06-30 16:17:18
|
Following the breakthrough on Friday of apparently getting swap to work to a SCSI disk, today I've been experimenting with filesystems: * used fdisk to create 4 primary partitions (3 big, 1 small to be used for swap) : seemed to work OK * created 2x ext3 filesystems * use rsync to mirror NFS filesystems onto the SCSI ones : kernel locked up eventually, PC inside journal_commit_transaction So for now, just using ext2. * similar on ext2, found I was getting NETDEV watchdog firing, + lots of PCI Interrupts with PCI INT=0x200, CIR=0x400000[67f]. Note : not arb interrupts this time. Once the NETDEV watchdog fired, the machine was effectively stuck. * after moving SCSI card to a 5V slot, the PCI interrupts went away. * several attempts at rsync'ing the NFS filesystem onto an ext2 on the SCSI, using find|md5sum on the NFS server to generate a golden reference, and using md5sum -c on the Cayman to check the copy. Sometimes a very small number of files are unreadable. A number of files (typically about 100 in 15000) have failed checksums. The failing files vary from one 'md5sum -c' run to another. * trying to boot with the SCSI ext2 filesystem as the root doesn't work - there are lots of console messages like 08:01: rw=0, want=1614831682, limit=2458608 attempt to access beyond end of device * if I run e2fsck on the partition right after booting, but before it's been mounted, the partition appears clean. If I try after doing 'mount;umount' there is always some corruption. If I keep doing e2fsck, there is new corruption every time. If I halt & reboot, the filesystem appears uncorrupted again. * Also, umount doesn't make the filesystem state 'clean' as it should. * Currently I've got flush_page_to_ram calling flush_dcache_page and the multiple read stuff in the SCSI driver commented out, to see if these improve things. Not sure one way or the other yet. So overall it's close, but nowhere near good enough to be a production filesystem. I've no idea if the remaining problems I'm seeing are hardware or software related. Some behaviour looks like it could be coherency related, either between cache and memory, or between memory and disc. Anybody seen anything like this before, or have experiments that would be useful to try out? Cheers Richard -- Richard \\\ SuperH Core+Debug Architect /// .. At home .. P. /// ric...@su... /// rc...@rc... Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk |
|
From: Paul M. <le...@li...> - 2003-06-27 18:36:34
|
On Fri, Jun 27, 2003 at 06:32:29PM +0100, Richard Curnow wrote: > Good news! After applying Paul's scatter-gather patch, with one tiny > fix to get it to compile, I've now got the Cayman swapping mostly > successfully onto a SCSI disc. I say "mostly" because I'm getting > occasional PCI interrupts still (not ARB this time though) and some > corruption as a result. Perhaps this will go away if I move the SCSI > card to a 5V slot as Steve suggested. >=20 I suppose another thing we need to look at is coming up with a consistency interface so PCI DMA and the DMA mapping API and anything else requiring consistency can just wrap to this to do the Right Thing(tm). Notably, we can still optimize a lot of the DMA cache flushing semantics based off of the DMA direction.. instead of implicitly doing a full write-back and invalidate each time. I'll probably hack together a patch for this after knocking some more things off of my SH todo list and finishing off the DMAC stuff.. As an added nuisance, I'm managing to hit another corruption issue which goes away once flush_page_to_ram() is wrapped to flush_dcache_page(). Guess there's a few other places that aren't getting flushing right. Back to hunting those down.. |
|
From: Richard C. <Ric...@su...> - 2003-06-27 17:36:26
|
* Richard Curnow <Ric...@su...> [2003-06-27]: > Fingers crossed... Good news! After applying Paul's scatter-gather patch, with one tiny fix to get it to compile, I've now got the Cayman swapping mostly successfully onto a SCSI disc. I say "mostly" because I'm getting occasional PCI interrupts still (not ARB this time though) and some corruption as a result. Perhaps this will go away if I move the SCSI card to a 5V slot as Steve suggested. I'm pushing the change out right now, in case anyone else can benefit. -- Richard \\\ SuperH Core+Debug Architect /// .. At home .. P. /// ric...@su... /// rc...@rc... Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk |
|
From: Richard C. <Ric...@su...> - 2003-06-27 16:47:27
|
* Paul Mundt <le...@li...> [2003-06-27]: > > I've been syncing my tree every day (although our internal site tree > > that the others use is now 100's of changesets out of date.) I need to > > push my changes back out sometime, though. > > > Indeed. Getting things synced up would be nice. For better or worse, I've just pushed the changes we've had committed inside SuperH but not previously pushed externally. The Cayman saga thickens - the 'new' one earlier this afternoon, it turned out, wouldn't even run a compiler reliably once I logged into it; a panic PC inside do_fast_page_fault come up on the LEDs. So I'm onto the 3rd Cayman of the day. Looking good so far : SCSI card comes up (drive not attached yet though as I haven't fixed the scatter-gather yet), compilers going fine, and it's got a 19.* MHz xtal so the CPU speed is now 314MHz instead of the previous 256. Fingers crossed... -- Richard \\\ SuperH Core+Debug Architect /// .. At home .. P. /// ric...@su... /// rc...@rc... Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk |
|
From: Steve W. <sc...@wa...> - 2003-06-27 16:35:44
|
On Fri, 27 Jun 2003, Richard Curnow wrote: > Actually today, to start debugging the Tekram SCSI card support, I've > got hold of a 2nd Cayman. The boot gets much further on this wrt the > SCSI than in the old one. So perhaps it's just that the older Cayman > has a defective PCI. In my experience porting NetBSD, there is a batch of Caymans which have flaky 3v PCI slots. Any attempt to use bus-mastering PCI cards in them results in tons of PCI ARB interrupts, and eventual crashes. The 5v slots work fine (which is interesting, since they're subordinates of the 3v bus). Anyway, I put the problem down to some obscure bug or two lurking in my Cayman PCIbus driver, but when a colleague got a Cayman and tried the 3v slots, they worked fine. In the end, I swapped my Cayman for another and have had no PCI problems of any kind. Sorry I can't help with the other cache-related issues; I'm not familiar with the Linux port. Cheers, Steve -- Wasabi Systems Inc. - The NetBSD Company - http://www.wasabisystems.com/ |
|
From: Paul M. <le...@li...> - 2003-06-27 16:09:55
|
On Fri, Jun 27, 2003 at 04:26:05PM +0100, Richard Curnow wrote:
> I've now got stuck because I got lost trying to follow the call chain
> back far enough to locate where the scatter-gather buffers are getting
> allocated and hence why the addresses in the table passed to pci_map_sg
> are all zero. I suspect there's something in asm-sh64 or arch/sh64
> that's missing a real implementation, but I've no idea what.
>=20
> Is anybody au fait with this area of the code and able to give me any
> pointers where to look next?
>=20
There's absolutely nothing wrong with getting a NULL address in this case,
the existing code just doesn't deal with it properly.
Drivers have two options for dealing with this, they can either set
->address or they can set ->page and ->offset, the latter of which is the
preferred method, and is the only thing that works for highmem systems.
Try out this patch (I haven't tried compiling it yet, but its a proof of
concept .. you may also have to adjust some of the flushing), and see if
it works for you..
--- shmedia-2.4/include/asm-sh64/scatterlist.h Tue May 13 15:08:57 2003
+++ shmedia-2.4.test/include/asm-sh64/scatterlist.h Fri Jun 27 11:58:22 2003
@@ -23,12 +23,13 @@
#define _ASM_SH64_SCATTERLIST_H
=20
struct scatterlist {
- char *address; /* Location data is to be transferred to */
- char *alt_address; /* Location of actual if address is a */
- /* dma indirect buffer. NULL otherwise */
- struct page *page; /* Location for highmem page, if any */
- unsigned int offset; /* for highmem, page offset */
- unsigned int length;
+ char *address; /* Location data is to be transferred to, NULL
+ for highmem page */
+ struct page *page; /* Location for highmem page, if any */
+ unsigned int offset; /* for highmem, page offset */
+
+ dma_addr_t dma_address;
+ unsigned int length;
};
=20
#define ISA_DMA_THRESHOLD (0xffffffff)
--- shmedia-2.4/include/asm-sh64/pci.h Fri Jun 20 18:44:48 2003
+++ shmedia-2.4.test/include/asm-sh64/pci.h Fri Jun 27 12:05:26 2003
@@ -141,8 +141,18 @@
int nents,int direction)
{
int i;
- for (i=3D0; i<nents; i++)
- dma_cache_wback_inv((unsigned long)sg[i].address, sg[i].length);=20
+
+ for (i =3D 0; i < nents; i++) {
+ if (sg[i].address) {
+ dma_cache_wback_inv((unsigned long)sg[i].address,
+ sg[i].length);
+ sg[i].dma_address =3D virt_to_bus(sg[i].address);
+ } else {
+ sg[i].dma_address =3D page_to_bus(sg[i].page) +
+ sg[i].offset;
+ }
+ }
+
return nents;
}
=20
@@ -155,7 +165,17 @@
static inline void pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist =
*sg,
int nents,int direction)
{
- /* Nothing to do */
+ int i;
+
+ if (direction =3D=3D PCI_DMA_TODEVICE)
+ return;
+=09
+ for (i =3D 0; i < nents; i++) {
+ if (!sg[i].address)
+ continue;
+
+ dma_cache_wback_inv((unsigned long)sg[i].address, sg[i].length);
+ }
}
=20
=20
@@ -188,7 +208,10 @@
struct scatterlist *sg,
int nelems,int direction)
{
- /* Nothing to do */
+ int i;
+
+ for (i =3D 0; i < nelems; i++)
+ dma_cache_wback_inv((unsigned long)sg[i].address, sg[i].length);
}
=20
=20
@@ -219,7 +242,7 @@
** returns, or alternatively stop on the first sg_dma_len(sg) which
** is 0.
*/
-#define sg_dma_address(sg) (virt_to_bus((sg)->address))
+#define sg_dma_address(sg) ((sg)->dma_address)
#define sg_dma_len(sg) ((sg)->length)
=20
#define PCI_DMA_BUS_IS_PHYS (1)
|
|
From: Richard C. <Ric...@su...> - 2003-06-27 15:42:35
|
I've started another round of trying to get this card working with the
Cayman. First off, I've found that with the card in a different Cayman
I'm getting a lot further than before.
I'm configuring in the sym53c8xx_2 scsi driver, and selecting 0 for the
DMA mode (i.e. 32 bit always).
I had to fix memcpy_toio and memcpy_fromio (arch/sh64/lib/io.c) to make
them have the same semantics as sh. This helped get it further still.
(Not bk-push'able yet though because they've got diagnostics in still.)
However, I'm now hitting a problem with the scatter-gather stuff. I've
got pci_map_sg annotated thusly
static inline int pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
int nents,int direction)
{
int i;
for (i=0; i<nents; i++) {
if (sg[i].address == 0) {
printk("pci_map_sg, sg[%d]==0 (length=%d, nents=%d)\n", i, sg[i].length, nents);
} else {
printk("pci_map_sg, sg[%d]=0x%08lx, length=%d\n", i, (unsigned long) sg[i].address, sg[i].length);
dma_cache_wback_inv((unsigned long)sg[i].address, sg[i].length);
}
}
return nents;
}
and my console messages now look like this:
SCSI subsystem driver Revision: 1.00
sym.0.2.0: setting PCI_COMMAND_PARITY...
sym.0.2.0: setting PCI_COMMAND_INVALIDATE.
sym.0.2.1: setting PCI_COMMAND_PARITY...
sym.0.2.1: setting PCI_COMMAND_INVALIDATE.
sym0: <1010-33> rev 0x1 on pci bus 0 device 2 function 0 irq 6
pci_alloc_consistent returns a07c4000, phys 0x807c4000, mapped to f0002000
sym0: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: open drain IRQ line driver, using on-chip SRAM
sym0: using LOAD/STORE-based firmware.
sym0: handling phase mismatch from SCRIPTS.
pci_alloc_consistent returns a07c3000, phys 0x807c3000, mapped to f0009000
pci_alloc_consistent returns a07c2000, phys 0x807c2000, mapped to f000b000
pci_alloc_consistent returns a07c1000, phys 0x807c1000, mapped to f000d000
pci_alloc_consistent returns a07c0000, phys 0x807c0000, mapped to f000f000
OUTRAM_OFF/memcpy_to_io f0007000 f000f000 0000052c
memcpy_toio called f0007000 f000f000 0000052c
OUTRAM_OFF/memcpy_to_io f0006000 f000d000 00000bd0
memcpy_toio called f0006000 f000d000 00000bd0
sym0: SCSI BUS has been reset.
sym1: <1010-33> rev 0x1 on pci bus 0 device 2 function 1 irq 6
pci_alloc_consistent returns a07be000, phys 0x807be000, mapped to f0011000
sym1: Symbios NVRAM, ID 7, Fast-80, SE, parity checking
sym1: open drain IRQ line driver, using on-chip SRAM
sym1: using LOAD/STORE-based firmware.
sym1: handling phase mismatch from SCRIPTS.
pci_alloc_consistent returns a07bd000, phys 0x807bd000, mapped to f0018000
pci_alloc_consistent returns a07bc000, phys 0x807bc000, mapped to f001a000
pci_alloc_consistent returns a07bb000, phys 0x807bb000, mapped to f001c000
pci_alloc_consistent returns a07ba000, phys 0x807ba000, mapped to f001e000
OUTRAM_OFF/memcpy_to_io f0016000 f001e000 0000052c
memcpy_toio called f0016000 f001e000 0000052c
OUTRAM_OFF/memcpy_to_io f0015000 f001c000 00000bd0
memcpy_toio called f0015000 f001c000 00000bd0
sym1: SCSI BUS has been reset.
sym1: SCSI BUS mode change from SE to SE.
OUTRAM_OFF/memcpy_to_io f0016000 f001e000 0000052c
memcpy_toio called f0016000 f001e000 0000052c
OUTRAM_OFF/memcpy_to_io f0015000 f001c000 00000bd0
memcpy_toio called f0015000 f001c000 00000bd0
sym1: SCSI BUS has been reset.
scsi0 : sym-2.1.17a
scsi1 : sym-2.1.17a
blk: queue a07ce174, I/O limit 4095Mb (mask 0xffffffff)
Vendor: IBM Model: DDYS-T09170N Rev: S96H
Type: Direct-Access ANSI SCSI revision: 03
blk: queue a07ce274, I/O limit 4095Mb (mask 0xffffffff)
sym1:6:0: tagged command queuing enabled, command queue depth 16.
Attached scsi disk sda at scsi1, channel 0, id 6, lun 0
sym1:6:0:M_REJECT to send for : 1-6-4-c-0-3e-1-0.
sym1:6: FAST-20 WIDE SCSI 40.0 MB/s ST (50.0 ns, offset 31)
SCSI device sda: 17916240 512-byte hdwr sectors (9173 MB)
Partition check:
sda:pci_map_sg, sg[0]==0 (length=1024, nents=4)
pci_map_sg, sg[1]==0 (length=1024, nents=4)
pci_map_sg, sg[2]==0 (length=1024, nents=4)
pci_map_sg, sg[3]==0 (length=1024, nents=4)
PCI ARB INTERRUPT!
PCI AINT -> 0x4
PCI AIR -> 0xe0000000
PCI CIR -> 0x8000000f
sym1:6: ERROR (20:0) (1-21-0) (1f/38/0) @ (scripta 7d8:110003d8).
sym1: script cmd = 11000000
sym1: regdump: da 10 c0 38 47 1f 06 0e 0e 01 86 21 80 01 01 01 00 ec 7b 80 08 00 00 00.
sym1: PCI STATUS = 0x2000
sym1: SCSI BUS reset detected.
OUTRAM_OFF/memcpy_to_io f0016000 f001e000 0000052c
memcpy_toio called f0016000 f001e000 0000052c
OUTRAM_OFF/memcpy_to_io f0015000 f001c000 00000bd0
memcpy_toio called f0015000 f001c000 00000bd0
sym1: SCSI BUS has been reset.
pci_map_sg, sg[0]==0 (length=1024, nents=4)
pci_map_sg, sg[1]==0 (length=1024, nents=4)
pci_map_sg, sg[2]==0 (length=1024, nents=4)
pci_map_sg, sg[3]==0 (length=1024, nents=4)
pci_map_sg, sg[0]==0 (length=1024, nents=4)
[etc]
(The OUTRAM_OFF/memcpy_to_io messages are other debug I've added.) So
the card is booting, it's even detecting the drive correctly now (yup,
IBM Ultrastar 9.1Gb is right). However, it's clear that the addresses
in the scatter-gather list are all zeroes. I guess this leads onto the
PCI ARB interrupt because the Tekram is going to attempt a DMA to a
bogus physical address.
I've now got stuck because I got lost trying to follow the call chain
back far enough to locate where the scatter-gather buffers are getting
allocated and hence why the addresses in the table passed to pci_map_sg
are all zero. I suspect there's something in asm-sh64 or arch/sh64
that's missing a real implementation, but I've no idea what.
Is anybody au fait with this area of the code and able to give me any
pointers where to look next?
Cheers
Richard
--
Richard \\\ SuperH Core+Debug Architect /// .. At home ..
P. /// ric...@su... /// rc...@rc...
Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk
|
|
From: Richard C. <Ric...@su...> - 2003-06-27 15:15:43
|
Hi Paul, * Paul Mundt <le...@li...> [2003-06-27]: > > > * a problem in fs/nfs/nfs3proc.c (nfs3_proc_unlink_setup) where two > > allocations are done with one kmalloc and the 2nd ends up with > > insufficient alignment. This was discussed on lkml with Trond and > > seemed to be acceptable, although I botched the patch twice and need > > to clean it up and resubmit it formally. It's not been fixed > > externally yet (according to bk revtool). > > > It would be good to get this in sooner then later, particularly with 2.4.22 > looming not far off. OK, I'll look at getting this patch kicked off. > > I had a gkrellm running at the time of the crash, and the swap bar has > > frozen right at the top. So I wonder if there's a problem with the USB > > path to the disc when it's driven into very high load. > > > If you only do relatively light swapping, or pull back on some of the load > once the swap bar gets higher, does it still work without triggering the > interrupt? I'm pretty sure it correlates with swap load, but I can't be 100% sure. Actually today, to start debugging the Tekram SCSI card support, I've got hold of a 2nd Cayman. The boot gets much further on this wrt the SCSI than in the old one. So perhaps it's just that the older Cayman has a defective PCI. -- Richard \\\ SuperH Core+Debug Architect /// .. At home .. P. /// ric...@su... /// rc...@rc... Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk |
|
From: Paul M. <le...@li...> - 2003-06-27 12:31:59
|
Hi Richard, On Fri, Jun 27, 2003 at 12:02:49PM +0100, Richard Curnow wrote: > [for those on linux-shmedia-dev : this started off as a private thread > between Paul and me about work we're doing to fix swapping, but it's > probably of general interest too now - if anyone wants to pick up the > rest of the thread give us a shout] >=20 There's also other related threads in the linuxsh-shmedia-bk archives, for anyone that's interested. > Well quite :-) Unfortunately, it's the only option I have at the > moment, as due to lack of working IDE, SCSI or USB2. >=20 That's not entirely true, if you swith the fb off you can still somewhat reliably use the kyro for swap. If you're getting nailed by PCI ARB interru= pts though, doing so might just increase the frequency of which you get these triggered. > On a general note, maybe soon we should diff the generic parts of our > tree against a vanilla Marcelo tree, and find where we've made changes > in generic to fix things. Before we can merge sh64 into the mainline, > we either need to workaround these in arch, or get Marcelo to accept the > changes. Personally I know of 3 now : >=20 There's also driver-specific hacks, including the sh-sci changes. > * a problem in fs/nfs/nfs3proc.c (nfs3_proc_unlink_setup) where two > allocations are done with one kmalloc and the 2nd ends up with > insufficient alignment. This was discussed on lkml with Trond and > seemed to be acceptable, although I botched the patch twice and need > to clean it up and resubmit it formally. It's not been fixed > externally yet (according to bk revtool). >=20 It would be good to get this in sooner then later, particularly with 2.4.22 looming not far off. > * The change you've just made to mm/memory.c >=20 The obvious workaround for this is to simply go back to wrapping the flush_page_to_ram() to flush_dcache_page() in arch/sh64/mm/cache.c This then also raises the issue if we want to back out the _other_ performa= nce hacks, ie, flush_cache_page(), flush_icache_page(), and so forth. I think in the general case that's not really that interesting, so it's probably more sensible to just fixup flush_page_to_ram() in stock 2.4, and keep performance hacks like this in the BK tree. > I had a gkrellm running at the time of the crash, and the swap bar has > frozen right at the top. So I wonder if there's a problem with the USB > path to the disc when it's driven into very high load. >=20 If you only do relatively light swapping, or pull back on some of the load once the swap bar gets higher, does it still work without triggering the interrupt? > I saw you committed a change the other day to do with cache coherency > for PCI DMAs - is that related to any of this stuff? >=20 Not directly, that's more of a sanity thing. For things using the PCI DMA API, there's otherwise the chance of them getting handed stale memory. > I've been syncing my tree every day (although our internal site tree > that the others use is now 100's of changesets out of date.) I need to > push my changes back out sometime, though. >=20 Indeed. Getting things synced up would be nice. |
|
From: Richard C. <Ric...@su...> - 2003-06-27 11:03:01
|
[for those on linux-shmedia-dev : this started off as a private thread between Paul and me about work we're doing to fix swapping, but it's probably of general interest too now - if anyone wants to pick up the rest of the thread give us a shout] Hi Paul * Paul Mundt <le...@li...> [2003-06-26]: > Indeed. Lack of anything resembling what could potentially be concieved as > performance would be a sheer indicator that USB1.1 isn't much of a viable swap > option. Well quite :-) Unfortunately, it's the only option I have at the moment, as due to lack of working IDE, SCSI or USB2. > > I still think we should continue the push to check each caller to > > flush_page_to_ram and find which one is the culprit. If we can engineer > > just that one to use the flush_dcache_page mechanism instead, we should > > see a performance boost. > > > Agreed. Though this leaves us with a few potential problems. Namely, we'll > likely have to have flush_page_to_ram() wrapping to flush_dcache_page() in > stock 2.4 (once Marcelo takes it), as we likely won't be able to get those > flushes wrapped in stock 2.4 (this will have to be something that we keep > isolated to the linux-shmedia tree, obviously). On a general note, maybe soon we should diff the generic parts of our tree against a vanilla Marcelo tree, and find where we've made changes in generic to fix things. Before we can merge sh64 into the mainline, we either need to workaround these in arch, or get Marcelo to accept the changes. Personally I know of 3 now : * a usb-ehci compile fix (missing include) - I've already got this in through Greg-KH (went in right after 2.4.21) * a problem in fs/nfs/nfs3proc.c (nfs3_proc_unlink_setup) where two allocations are done with one kmalloc and the 2nd ends up with insufficient alignment. This was discussed on lkml with Trond and seemed to be acceptable, although I botched the patch twice and need to clean it up and resubmit it formally. It's not been fixed externally yet (according to bk revtool). * The change you've just made to mm/memory.c > If it's generally harmless, it may be useful to just remove the printk() > altogether. I can't imagine a customer being pleased with being flooded > by invalid pte warnings. (At my last job, rather, when I still had one, we had > to hack all of the module tainting stuff out since customers kept getting > scared by it) -- I can't imagine invalid pte warnings being recieved any > better. I've removed it in my tree and committed it. > > > My runs are always getting killed by PCI ARB interrupts, after which the > > external disc access light is stuck on and everything in D-state is > > deadlocked. This happens with both the external Maxtor 120G HDD (USB2) > > and the ZIP (USB1.1), though it seems like swapping to the ZIP lasts for > > longer. > > > Odd. It might be useful to hook up a PCI bus analyzer and see what it has to > say about it. I've just had a run going with a load av of >12, typically 30-40Mb into swap, which lasted 30 minutes, before it died with another of these. Maybe there's a corner case with this USB1 card. But I'm quite pleased with this because it looks like the swapping is generally reliable now. I had a gkrellm running at the time of the crash, and the swap bar has frozen right at the top. So I wonder if there's a problem with the USB path to the disc when it's driven into very high load. I saw you committed a change the other day to do with cache coherency for PCI DMAs - is that related to any of this stuff? > You may wish to do a pull as well if you haven't recently, since you may > end up getting fairly out of sync otherwise. I've been syncing my tree every day (although our internal site tree that the others use is now 100's of changesets out of date.) I need to push my changes back out sometime, though. -- Richard \\\ SuperH Core+Debug Architect /// .. At home .. P. /// ric...@su... /// rc...@rc... Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk |
|
From: Jubril M. <jma...@o2...> - 2003-06-25 18:59:45
|
CENTRAL BANK OF NIGERIA=2E TINUBU SQUARE LAGOS=2C NIGERIA=2E Mailto=3Ajubrilmartin=40indiatimes=2Ecom Dear It's my pleasure to send you this mail which I hope you will treat as highly confidential=2E I am Mr Jubril Martin=2CA 53 years old man and the Deputy Treasury Officer with the Central Bank of Nigeria lagos=2EDuring the Military regime of Late General Sani Abacha=2C contracts runing into several millions of dollars were awarded to friends and cronies fronting for the late despotic ruler=2Cbut unfortunately before such payments could go through=2C he died mysteriously in power=2E I am writing you for assistance in transfering the sum of US$36=2E8 million dollars into your account=2EThis amount represents just a payment due to one of his friends for a contract awarded to him but was not actually executed=2Che is afraid to come forward to claim the money for fear of being prosecuted=2E This money is lying dormant in the vaults of the Central Bank of Nigeria and I use this opportunity to crave your indulgience in transfering this money intoyour account=2C this business is totally risk free=2Cit is only myself that is aware of this floating money=2EFor your assistance=2CI am willing to give you 30% of the total sum=2Cwhile you will assist me in investing my share in viable businesses in your country pending when I eventually resign my appointment and join you=2EPlease if you know you can assist me=2Cendeavour to get in touch with me as soon as possible so i can give you the necessary details so as to conclude the transfer within 7 working days=2E I am waiting for your urgent messages with respect to this proposal=2EThrough my private Email=3Cjubrilmartin=40indiatimes=2Ecom=3E Regards=2C Mr=2EJubril Martin |
|
From: Richard C. <Ric...@su...> - 2003-06-16 12:00:28
|
Hi,
Has anyone got any experiences with this card? I've got one plugged
into my Cayman but I'm not having much luck getting it to work.
I've enabled the "SYM53C8XX Version 2 SCSI support" driver, which claims
to support the chipset on the card (lspci reports the card like this:)
00:02.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3=
SCSI Adapter (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParEr=
r- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=3Dmedium >TAbort=
- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (4250ns min, 4500ns max), cache line size 08
Interrupt: pin A routed to IRQ 6
Region 0: I/O ports at 3400 [size=3D256]
Region 1: Memory at 46144400 (64-bit, non-prefetchable) [size=3D1=
K]
Region 3: Memory at 46140000 (64-bit, non-prefetchable) [size=3D8=
K]
Expansion ROM at 46120000 [disabled] [size=3D64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=3D0mA PME(D0-,D1-,=
D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=3D0 DScale=3D0 PME-
00:02.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3=
SCSI Adapter (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParEr=
r- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=3Dmedium >TAbort=
- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (4250ns min, 4500ns max), cache line size 08
Interrupt: pin A routed to IRQ 6
Region 0: I/O ports at 3800 [size=3D256]
Region 1: Memory at 46144800 (64-bit, non-prefetchable) [size=3D1=
K]
Region 3: Memory at 46142000 (64-bit, non-prefetchable) [size=3D8=
K]
Expansion ROM at 46130000 [disabled] [size=3D64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=3D0mA PME(D0-,D1-,=
D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=3D0 DScale=3D0 PME-
Currently I haven't got a HDD plugged into the card. I've tried both
3.3 and 5V slots. Every time, my bootup gets stuck like this:
SCSI subsystem driver Revision: 1.00
sym.2.0.0: setting PCI_COMMAND_PARITY...
sym.2.0.0: setting PCI_COMMAND_INVALIDATE.
sym.2.0.1: setting PCI_COMMAND_PARITY...
sym.2.0.1: setting PCI_COMMAND_INVALIDATE.
sym0: <1010-33> rev 0x1 on pci bus 2 device 0 function 0 irq 88
pci_alloc_consistent returns a07c0000, phys 0x807c0000, mapped to f408400=
0
sym0: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: open drain IRQ line driver, using on-chip SRAM
sym0: using LOAD/STORE-based firmware.
sym0: handling phase mismatch from SCRIPTS.
pci_alloc_consistent returns a07bf000, phys 0x807bf000, mapped to f408b00=
0
pci_alloc_consistent returns a07be000, phys 0x807be000, mapped to f408d00=
0
pci_alloc_consistent returns a07bd000, phys 0x807bd000, mapped to f408f00=
0
pci_alloc_consistent returns a07bc000, phys 0x807bc000, mapped to f409100=
0
sym0: SCSI BUS has been reset.
sym1: <1010-33> rev 0x1 on pci bus 2 device 0 function 1 irq 88
pci_alloc_consistent returns a07bb000, phys 0x807bb000, mapped to f409300=
0
sym1: Symbios NVRAM, ID 7, Fast-80, SE, parity checking
sym1: open drain IRQ line driver, using on-chip SRAM
sym1: using LOAD/STORE-based firmware.
sym1: handling phase mismatch from SCRIPTS.
pci_alloc_consistent returns a07ba000, phys 0x807ba000, mapped to f409a00=
0
pci_alloc_consistent returns a07b9000, phys 0x807b9000, mapped to f409c00=
0
pci_alloc_consistent returns a07b8000, phys 0x807b8000, mapped to f409e00=
0
pci_alloc_consistent returns a07b7000, phys 0x807b7000, mapped to f40a000=
0
sym1: SCSI BUS has been reset.
sym0:0: ERROR (0:8) (0-0-0) (0/0/0) @ (scriptb 8:6f388af5).
sym0: script cmd =3D 80080000
sym0: regdump: ca 00 00 00 47 00 00 0f 00 08 00 00 80 00 00 0a 00 00 7c 8=
0 20 00 00 00.
sym1: SCSI BUS mode change from SE to SE.
sym1: SCSI BUS has been reset.
sym0: SCSI BUS reset detected.
sym0: SCSI BUS has been reset.
sym1:0: ERROR (0:8) (0-0-0) (0/0/0) @ (scriptb 8:ea220d65).
sym1: script cmd =3D 80080000
sym1: regdump: ca 00 00 00 47 00 00 0f 00 08 00 00 80 00 08 0a 00 b0 7b 8=
0 20 00 00 00.
sym0:0: ERROR (0:8) (0-0-0) (0/0/0) @ (scriptb 8:6f388af5).
sym0: script cmd =3D 80080000
sym0: regdump: ca 00 00 00 47 00 00 0f 00 08 00 00 80 00 00 0a 00 00 7c 8=
0 20 00 00 00.
sym1: SCSI BUS reset detected.
sym1: SCSI BUS has been reset.
sym0: SCSI BUS reset detected.
sym0: SCSI BUS has been reset.
sym1:0: ERROR (0:8) (0-0-0) (0/0/0) @ (scriptb 8:ea220d65).
sym1: script cmd =3D 80080000
sym1: regdump: ca 00 00 00 47 00 00 0f 00 08 00 00 80 00 08 0a 00 b0 7b 8=
0 20 00 00 00.
which just keeps going on and on until I reset the board. Being a
non-SCSI-expert who was na=EFvely hoping this would work OOB, I'm pretty
stuck.
Any ideas? e.g. has this card ever been got working on SH-4 and if so
what was the trick (if any)?
Cheers
Richard
--=20
Richard \\\ SuperH Core+Debug Architect /// .. At home ..
P. /// ric...@su... /// rc...@rc...
Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk
|
|
From: kaz K. <kk...@rr...> - 2003-06-15 01:16:19
|
Richard Earnshaw <rea...@ar...> wrote: >> The gcc.dg/compat/scalar-return-4 c_compat_x_tst.o compile failure >> is yet another of these little bugs that can be easily solved with >> another constraint - but there are more problems like this, the SH >> port is already very low on free constraint letters, and the existing >> constraint letters are also somewhat haphazard. For instance, the >> 'Z' constraint really belongs into the CONST_OK_FOR_CONSTRAINT space, >> but it didn't fit there because all the letters had been used up. >> Thus, I think it is time to reshuffle some constraints to get some >> more order in the existing constraints and make room for new ones. >> This will affect assembler templates that use any of the renamed >> constraints. I have attached an outline of the existing usage of >> uppercase constraint letters (lowercase letters that are not defined >> in a machine-independent way are used for register classes on the SH), >> what constraints I want to change, and list of the uppercase constraints >> after the reshuffle. >> > > Doesn't this break any constraints in asm statements that use the > constraint letters you are changing? I've grepped asm constraints in sh/shmedia libc and linux kernel and found no [A-Z] constrains. Of course user applications could use them, but it seems to me a rare case and would be fixed easily. Perhaps it would be better the compiler can detect the old style constraints and make them error. Since in the proposal, the only remapped constraint which is also valid as an original constraint is "Z", changing it to "Zam" or something like that makes such detection easy. Regards, kaz |
|
From: Richard E. <rea...@ar...> - 2003-06-14 13:12:31
|
> The gcc.dg/compat/scalar-return-4 c_compat_x_tst.o compile failure > is yet another of these little bugs that can be easily solved with > another constraint - but there are more problems like this, the SH > port is already very low on free constraint letters, and the existing > constraint letters are also somewhat haphazard. For instance, the > 'Z' constraint really belongs into the CONST_OK_FOR_CONSTRAINT space, > but it didn't fit there because all the letters had been used up. > Thus, I think it is time to reshuffle some constraints to get some > more order in the existing constraints and make room for new ones. > This will affect assembler templates that use any of the renamed > constraints. I have attached an outline of the existing usage of > uppercase constraint letters (lowercase letters that are not defined > in a machine-independent way are used for register classes on the SH), > what constraints I want to change, and list of the uppercase constraints > after the reshuffle. > Doesn't this break any constraints in asm statements that use the constraint letters you are changing? R. |
|
From: Joern R. <joe...@su...> - 2003-06-13 17:44:34
|
The gcc.dg/compat/scalar-return-4 c_compat_x_tst.o compile failure is yet another of these little bugs that can be easily solved with another constraint - but there are more problems like this, the SH port is already very low on free constraint letters, and the existing constraint letters are also somewhat haphazard. For instance, the 'Z' constraint really belongs into the CONST_OK_FOR_CONSTRAINT space, but it didn't fit there because all the letters had been used up. Thus, I think it is time to reshuffle some constraints to get some more order in the existing constraints and make room for new ones. This will affect assembler templates that use any of the renamed constraints. I have attached an outline of the existing usage of uppercase constraint letters (lowercase letters that are not defined in a machine-independent way are used for register classes on the SH), what constraints I want to change, and list of the uppercase constraints after the reshuffle. -- -------------------------- SuperH (UK) Ltd. 2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX T:+44 1454 465658 |
|
From: kaz K. <kk...@rr...> - 2003-05-31 10:15:15
|
> and many tests compiling from bytecode failed with same error: > > internal compiler error: in expand_expr, at expr.c:6853 > > Though I have no workaround for the latter issue, with changes in > <URL:http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/gcc-sh-20030529.diff.bz2>, I've found a workround for this problem and updated the above patch. Now the result of libjava testsuite seems to be fairly good! Regards, kaz -- Test Run By kkojima on Sat May 31 09:03:08 2003 Target is sh64-unknown-linux-gnu Host is sh64-unknown-linux-gnu Build is i686-pc-linux-gnu === libjava tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/config/default.exp as tool-and-target-specific interface file. WARNING: Assuming target board is the local machine (which is probably wrong). You may need to set your DEJAGNU environment variable. Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.cni/cni.exp ... Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.compile/compile.exp ... Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.jacks/jacks.exp ... Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.jni/jni.ex p ... Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.lang/lang.exp ... FAIL: Divide_1 execution - source compiled test FAIL: Divide_1 output - gij test FAIL: Divide_1 execution - bytecode->native test FAIL: Divide_1 -O execution - source compiled test FAIL: Divide_1 output - gij test FAIL: Divide_1 -O execution - bytecode->native test FAIL: negzero execution - gij test FAIL: negzero execution - gij test FAIL: pr6388 output - gij test FAIL: pr6388 output - gij test Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.loader/loader.exp ... Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.mauve/mauve.exp ... === libjava Summary === # of expected passes 2808 # of unexpected failures 10 # of expected failures 16 # of untested testcases 138 |
|
From: kaz K. <kk...@rr...> - 2003-05-30 00:26:32
|
Hi, I wrote a libffi library for SHmedia: <URL:http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02321.html>. I'm a very novice SHmedia assembler writer, so it'd be not so good. Anyway, I'm trying to build libjava for sh64-unknown-linux-gnu on FSF gcc mainline using this libffi implementation. Unfortunately, dwarf EH mechanism didn't work yet, so I tried sjlj (exception handler using setjmp/longjmp). It seems that many gij (java interpreter) tests failed with the same reason as sjlj configured sh4 case <URL:http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7620> and many tests compiling from bytecode failed with same error: internal compiler error: in expand_expr, at expr.c:6853 Though I have no workaround for the latter issue, with changes in <URL:http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/gcc-sh-20030529.diff.bz2>, I've got the attached result. I used cross build and remote execution setting, so some tests are skipped. As you see, if the ICE for bytecode compilation can be solved, the result will become pretty good. Regards, kaz -- Test Run By kkojima on Thu May 29 14:23:06 2003 Target is sh64-unknown-linux-gnu Host is sh64-unknown-linux-gnu Build is i686-pc-linux-gnu === libjava tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/config/default.exp as tool-and-target-specific interface file. WARNING: Assuming target board is the local machine (which is probably wrong). You may need to set your DEJAGNU environment variable. Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.cni/cni.exp ... Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.compile/compile.exp ... FAIL: T20020529 compilation from bytecode FAIL: T20020529 -O compilation from bytecode Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.jacks/jacks.exp ... Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.jni/jni.exp ... Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.lang/lang.exp ... FAIL: ArrayStore2 compilation from bytecode FAIL: ArrayStore2 -O compilation from bytecode FAIL: Array_1 compilation from bytecode FAIL: Array_1 -O compilation from bytecode FAIL: Divide_1 execution - source compiled test FAIL: Divide_1 output - gij test FAIL: Divide_1 execution - bytecode->native test FAIL: Divide_1 -O execution - source compiled test FAIL: Divide_1 output - gij test FAIL: Divide_1 -O compilation from bytecode FAIL: FileHandleGcTest compilation from bytecode FAIL: FileHandleGcTest -O compilation from bytecode FAIL: Float_1 compilation from bytecode FAIL: Float_1 -O compilation from bytecode FAIL: G19990310_01 compilation from bytecode FAIL: G19990310_01 -O compilation from bytecode FAIL: InterfaceDispatch compilation from bytecode FAIL: InterfaceDispatch -O compilation from bytecode FAIL: Matrix4f compilation from bytecode FAIL: Matrix4f -O compilation from bytecode FAIL: N19990310_02 compilation from bytecode FAIL: N19990310_02 -O compilation from bytecode FAIL: N19990310_3 compilation from bytecode FAIL: N19990310_3 -O compilation from bytecode FAIL: PR160 compilation from bytecode FAIL: PR160 -O compilation from bytecode FAIL: PR3096 compilation from bytecode FAIL: PR3096 -O compilation from bytecode FAIL: PR56 compilation from bytecode FAIL: PR56 -O compilation from bytecode FAIL: PR6729 compilation from bytecode FAIL: PR6729 -O compilation from bytecode FAIL: SyncTest compilation from bytecode FAIL: SyncTest -O compilation from bytecode FAIL: TLtest compilation from bytecode FAIL: TLtest -O compilation from bytecode FAIL: Thread_Interrupt compilation from bytecode FAIL: Thread_Interrupt -O compilation from bytecode FAIL: Thread_Monitor compilation from bytecode FAIL: Thread_Monitor -O compilation from bytecode FAIL: Thread_Wait_2 compilation from bytecode FAIL: Thread_Wait_2 -O compilation from bytecode FAIL: Thread_Wait_Interrupt compilation from bytecode FAIL: Thread_Wait_Interrupt -O compilation from bytecode FAIL: anon4 compilation from bytecode FAIL: anon4 -O compilation from bytecode FAIL: anonarray compilation from bytecode FAIL: anonarray -O compilation from bytecode FAIL: anonarray2 compilation from bytecode FAIL: anonarray2 -O compilation from bytecode FAIL: err1 compilation from bytecode FAIL: err1 -O compilation from bytecode FAIL: err10 compilation from bytecode FAIL: err10 -O compilation from bytecode FAIL: err12 compilation from bytecode FAIL: err12 -O compilation from bytecode FAIL: err2 compilation from bytecode FAIL: err2 -O compilation from bytecode FAIL: err3 compilation from bytecode FAIL: err3 -O compilation from bytecode FAIL: err4 compilation from bytecode FAIL: err4 -O compilation from bytecode FAIL: err5 compilation from bytecode FAIL: err5 -O compilation from bytecode FAIL: err9 compilation from bytecode FAIL: err9 -O compilation from bytecode FAIL: indirect compilation from bytecode FAIL: indirect -O compilation from bytecode FAIL: inner_array compilation from bytecode FAIL: inner_array -O compilation from bytecode FAIL: invoke_from_inner compilation from bytecode FAIL: invoke_from_inner -O compilation from bytecode FAIL: negzero execution - gij test FAIL: negzero execution - gij test FAIL: pr133 compilation from bytecode FAIL: pr133 -O compilation from bytecode FAIL: pr6388 output - gij test FAIL: pr6388 output - gij test FAIL: private_direct_read compilation from bytecode FAIL: private_direct_read -O compilation from bytecode FAIL: search_outer compilation from bytecode FAIL: search_outer -O compilation from bytecode FAIL: stub compilation from bytecode FAIL: stub -O compilation from bytecode FAIL: tp compilation from bytecode FAIL: tp -O compilation from bytecode FAIL: utilTest compilation from bytecode FAIL: utilTest -O compilation from bytecode FAIL: verify compilation from bytecode FAIL: verify -O compilation from bytecode Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.loader/loader.exp ... Running /ext3/suzaku/home/kkojima/LOCAL/gcc/libjava/testsuite/libjava.mauve/mauve.exp ... === libjava Summary === # of expected passes 2589 # of unexpected failures 92 # of expected failures 16 # of untested testcases 275 |
|
From: Richard C. <Ric...@su...> - 2003-05-19 09:20:09
|
* h.z <zh...@ya...> [2003-05-17]:
> When I repot a x86 problem , I get some segment
> error. I test the following codes, it can work at
> x86, but not sh5.
>
> /* test.c */
>
> char str[ ]={
> 'a','b','c'
> };
>
> int main(void)
> {
> char *ptr;
> short i;
>
> ptr=str+1;
> i=*(short *) ptr; /* here error. I can't convert an
> odd pointer to short */
>
> return 0;
> }
>
> The codes are well in x86, but will get segment error
> in sh5.
> To coross compile the codes, I use the following
> commands:
>
> sh64-superh-linux-gnu-gcc -O2 -o test test.c
>
> When I port a x86 program to sh5, what I should pay
> more attention to ?
The underlying problem is that the SH-5 requires pointers to be aligned
to the size of the corresponding datatype. (This is true of lots of
other RISC processors also.) So, for example, pointers of type (short
*) must be 2-byte aligned when you try to dereference them, otherwise
you will get an address error exception.
I expect that in your program, the char array 'str' is placed at an even
address (i.e. 2-byte aligned), therefore 'ptr' is not 2-byte aligned,
therefore you can't dereference it successfully as a (short *).
I believe the x86 has support for dereferencing pointers with arbitrary
alignments (although with a performance penalty if the pointer isn't
correctly aligned), which explains why your example works on x86.
Note that for SH-5, the behaviour I described is true of the 'normal'
multi-byte load/store instructions : ld.w, ldx.w, ld.uw, ldx.uw, ld.l,
ldx.l, ld.q, ldx.q & the equivalent stores. These are the instructions
which compilers would typically generate.
There are also specialised instructions called ldlo.l, ldhi.l, ldlo.q,
ldhi.q (+ corresponding stores) which can achieve loads and stores to
misaligned multi-byte pointers, at a cost of needing 3 instructions for
a load or 2 for a store, instead of 1 instruction in the aligned case.
Since present-day compilers don't target these intruction (to my
knowledge), you would need to use assembler inserts, intrinsic functions
or hand-coded assembler functions to access them.
Hope that helps!
Richard
--
Richard \\\ SuperH Core+Debug Architect /// .. At home ..
P. /// ric...@su... /// rc...@rc...
Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk
|
|
From: <zh...@ya...> - 2003-05-17 08:09:14
|
Hi,
When I repot a x86 problem , I get some segment
error. I test the following codes, it can work at
x86, but not sh5.
/* test.c */
char str[ ]={
'a','b','c'
};
int main(void)
{
char *ptr;
short i;
ptr=str+1;
i=*(short *) ptr; /* here error. I can't convert an
odd pointer to short */
return 0;
}
The codes are well in x86, but will get segment error
in sh5.
To coross compile the codes, I use the following
commands:
sh64-superh-linux-gnu-gcc -O2 -o test test.c
When I port a x86 program to sh5, what I should pay
more attention to ?
Thanks,
Hui
_________________________________________________________
Do You Yahoo!?
相见不如聊天!不出门一样面对面！网络摄像头对对派送中~赶快用你的雅虎电邮帐号参与吧……
http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.messenger.yahoo.com/
|
|
From: Paul M. <le...@li...> - 2003-05-15 22:17:33
|
On Thu, May 15, 2003 at 04:57:02PM +0100, Sean McGoogan wrote: > There are 3 repositories in the linux-shmedia project. I am > wondering if we can tidy things up a bit. > > The 'linux-2.4' tree is the main development tree, so no > problems here. > > The 'linux' tree seems to be obsolete. It appears to be version > 2.4.0-test4, and has not been modified for the last 11 months (last > mod 24th June 2002). I propose to delete it - are there any problems or > issues in doing this ? > I don't see any problems here, though this tree still builds and boots with a little help (at least with Madrid 0.6). If there are no functional changes lost, then there's no problem in removing it. Anything else needs to be resynced into the linux-2.4 tree anyways. > The 'linux-2.5' tree was last modified over 1 year ago (28th > April 2002), and claims to be of the 2.5.11 vintage. I assume that when > we want to put 2.5 for SH-5 into BitKeeper, we will start from a more > recent baseline. Again, I propose to delete it - are there any problems > or issues in doing this ? > I wouldn't bother deleting it, its trivial to push outstanding changesets into this to get it synced up with current 2.5. I have quite a few changes pending in my local tree for sh64 on 2.5, so I'd like to get the linux-2.4 stuff reintegrated into the linux-2.5 tree and start pushing my local changes as soon as possible (of course there's no gaurantee that the tree will be in a functional state, but it will provide a location other then my home directory for people to monitor 2.5 developments for sh64). > Also, now that the main arch tree has been renamed from 'shmedia' > to 'sh64', what should we do about the BitKeeper project - should we > rename 'linux-shmedia.bkbits.net' to 'linux-sh64.bkbits.net' ? > If so, how do we do this, create a new project, clone from old, and > delete old project - I assume one can not rename a project. > I don't particularly see much reason to rename the project, but if that's want you want to do, you'll have to take that up with bkbits administrators. The hosted projects section on the BK site lists su...@bi... as the contact. |
|
From: stephen c. <ste...@st...> - 2003-05-15 16:43:34
|
ben...@su... wrote: > > hi, Hi Ben, > i am currently porting modutils-2.4.2 to sh64 Linux and have a question > concerning the handling of relocations of instructions that are the > destination of an shmedia branch. > > the problem i am having is how to determine when the relocation is to be > included in an instruction that is an shmedia branch destination. if one > looks at the code in dl-machine.h it calculates the value of the > variable lsb, to be 1 or 0, by anding STO_SH5_ISA32 with the field > st_other in the symbol structure (Elf32_Sym) being relocated and this > result is then ored into the resulting value during the calculation the > of relocation. > > --- it is a little strange that we are using the st_other field as this > seems to be for symbol visibility! Only bits 0 and 1 of st_other are used for visibility, STO_SH5_ISA32 is bit 2. STO_SH5_ISA32 indicates that the symbol marks SHmedia code, so if you want to branch to that symbol, you must make sure to set bit 0 of the target address. > unfortunately unlike binutils and bfd the modutils does not use the bfd > library, instead choosing to implement its own symbol structure > (obj_symbol in obj.h) which does not contain a mapping to the symbol > visibility. > > does any one have any ideas of what might be the best approach to > solving this problem? I don't know what modutils does so I can't help much. If you are trying to resolve relocations, then somehow you need to know the ISA at the symbol that marks the branch destination, i.e. is the branch destination SHmedia code or SHcompact code. The only place this information exists in ELF objects is in the st_other field. The same problem occurs with arm/thumb and mips/mips16 (mips also uses the st_other field to represent the ISA of a symbol, but arm uses a different field). Maybe you could look at what is done for those targets? (BTW, you also need to worry about the destination of SHcompact branches, if you have SHcompact code branching to SHmedia code.) Steve. |
1 message has been excluded from this view by a project administrator.
