linuxsh-dev

Re: [linuxsh-dev] Re: Back from the dead

[Stuart M. <Stu...@st...>]

Asano-san

I suddenly remembered I'd forgotten to reply to you.

No, the board we will be working on with the HD64465 is not the Hitachi
board, but a propritary one. With a bit of luck our board designers will
have followed the Hitachi recomendations, and everything should be mapped
at the same addreses as the Hitachi board, so we shouldn't have too many
problems. However there is other stuff on the board such as PCI which
takes up quite a bit of address space, so it may have been moved. We
shall see...

The interrupt and IO changes in the kernel sources should be complete now,
as far as I am concerned (appart from combining isa_port2addr and port2addr
in the machine vector), so now would probably be a good oportunity to get
this sort of change in.

You may want to have a look at the document I added in
  kernel/Documentation/sh/new-machine.txt
for an overview of how the new system works. 

How you integerate this probably depends on how similar the code is to
that for the HD64461. If they are pretty similar, I would be
inclined to make the current HD64461 configuration option more generic,
and only distinguish the two devices when you have to. 

If all else fails, please post your patches, and if nobody else has done
so, I'll have a go at integrating them when I get the hardware.

Which devices are you supporting on the HD64465? In particular are you
supporting USB? This looked kind of tricky when reading through the
manual.

Stuart


On Aug 2, 11:42am, as...@us... wrote:
> Subject: [linuxsh-dev] Re: Back from the dead
> 
> Hello Stuart-san and all.
> 
> On Tue, 1 Aug 2000 18:26:55 +0100
> Stuart Menefy <Stu...@st...> wrote:
> 
> > 
> > I'll probably need to add support for the HD64465 at some point in the
> > next few months, and hope to be able to use the HD64461 code as a
> > starting point, so we'll see what happens then.
> > 
> > Stuart
> > 
> 
> I'm Tomoyoshi ASANO.
> I'm working at Lineo.
> 
> We ported linuxsh cvs code for HSA ASPEN/TAHOE board
> last month.
> 
> The ASPEN board has a SH7750 and the TAHOE board which 
> is the dauther board of ASEPN has a HD64465.
> So we have some codes for HD64465.
> 
> Do you plan to wrok for the same board?
> 
> I want to provide these codes for HSA ASPEN/TAHOE board.
> But I don't know how to marge the code to cvs well.
> Please give me suggestion to do it.
> 
> But the current linuxsh cvs code is changed around I/O and
> interrupt recently, so I have not fixed it yet.
> 
> And I'm busy this week and the next week.
> I hope do it at the last of this month.
> 
> Tom
> --
> 
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxsh-dev
>-- End of excerpt from as...@us...

Re: [linuxsh-dev] Odd problem

[Jesper S. <js...@re...>]

>>>>> "NIIBE" == NIIBE Yutaka <gn...@ch...> writes:

NIIBE> Jesper, thanks for the datapoint.  Could you please use diff
NIIBE> with proper order in future, it's quite confusing for me.

Ah, sorry. It was not actually intended as a fix, just as a
FYI. [pedantically the patch was correct; it's the bits that I had to
leave out of an update to make the kernel work. It was not a patch to
revert a -test6 tree to a working state - but I could have made that
more clear, my apologies]

Jesper

Re: [linuxsh-dev] Odd problem

[NIIBE Y. <gn...@ch...>]

Jesper, thanks for the datapoint.

Could you please use diff with proper order in future, it's quite
confusing for me.

Cache issues is for SH-4.  SH-3 has physically indexed and physically
tagged unified cache which has no alias problem.  SH-4 has virtually
indexed and physically tagged separate cache which has alias problem.
-- 

[linuxsh-dev] Odd problem

[NIIBE Y. <gn...@ch...>]

I've looked through the code of linux/mm, and improve the changes I've
done yesterday.  Here's the patch.

Important point is that when a page is allocated, it may have a stale
data/instruction on cache line of user space.  We need to flush the
cache.  I did "Flushing at 'end of I/O'" yesterday, but it's more than
needed.

I've found that when swap entry is read asynchronously, the cache
remains.

2000-08-17  NIIBE Yutaka  <gn...@m1...>

	* mm/memory.c (do_anonymous_page): We need to flush I-cache and
	D-cache here, as it's newly allocated page.
	(do_no_page): We need to flush D-cache.
	(do_swap_page): Flush D-cache & I-cache here.  There're cases
	where read_swap_cache is called asynchronously and pages are
	cached.

	* Revert the change for fs/buffer.c (end_buffer_io_async).  It's
	more than needed.  We only need to flush when kernel WRITES to the
	page (from I/O), not READ (to I/O).

	* Revert the changes for mm/memory.c (do_wp_page: case 1): We have
	valid PTE here (it's read-only but works).

Index: fs/buffer.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/fs/buffer.c,v
retrieving revision 1.7
diff -u -r1.7 buffer.c
--- fs/buffer.c	2000/08/16 08:34:05	1.7
+++ fs/buffer.c	2000/08/17 04:08:10
@@ -770,7 +770,6 @@
 	/* OK, the async IO on this page is complete. */
 	spin_unlock_irqrestore(&page_uptodate_lock, flags);
 
-	flush_dcache_page(page);
 	/*
 	 * if none of the buffers had errors then we can set the
 	 * page uptodate:
Index: mm/memory.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/mm/memory.c,v
retrieving revision 1.6
diff -u -r1.6 memory.c
--- mm/memory.c	2000/08/16 08:34:09	1.6
+++ mm/memory.c	2000/08/17 04:08:21
@@ -790,8 +790,8 @@
 		pte_t *page_table)
 {
 	copy_cow_page(old_page,new_page,address);
-	flush_icache_page(vma, new_page);
 	flush_dcache_page(new_page);
+	flush_icache_page(vma, new_page);
 	establish_pte(vma, address, page_table, pte_mkwrite(pte_mkdirty(mk_pte(new_page, vma->vm_page_prot))));
 }
 
@@ -849,7 +849,7 @@
 		UnlockPage(old_page);
 		/* FallThrough */
 	case 1:
-		flush_dcache_page(old_page);
+		flush_cache_page(vma, address);
 		establish_pte(vma, address, page_table, pte_mkyoung(pte_mkdirty(pte_mkwrite(pte))));
 		spin_unlock(&mm->page_table_lock);
 		return 1;	/* Minor fault */
@@ -1059,9 +1059,6 @@
 		unlock_kernel();
 		if (!page)
 			return -1;
-
-		flush_dcache_page(page);
-		flush_icache_page(vma, page);
 	}
 
 	mm->rss++;
@@ -1084,6 +1081,8 @@
 	} else
 		UnlockPage(page);
 
+	flush_dcache_page(page);
+	flush_icache_page(vma, page);
 	set_pte(page_table, pte);
 	/* No need to invalidate - it was non-present before */
 	update_mmu_cache(vma, address, pte);
@@ -1107,7 +1106,8 @@
 		clear_user_highpage(page, addr);
 		entry = pte_mkwrite(pte_mkdirty(mk_pte(page, vma->vm_page_prot)));
 		mm->rss++;
-		flush_page_to_ram(page);
+		flush_dcache_page(page);
+		flush_icache_page(vma, page);
 	}
 	set_pte(page_table, entry);
 	/* No need to invalidate - it was non-present before */
@@ -1156,7 +1156,7 @@
 	 * so we can make it writable and dirty to avoid having to
 	 * handle that later.
 	 */
-	flush_page_to_ram(new_page);
+	flush_dcache_page(new_page);
 	flush_icache_page(vma, new_page);
 	entry = mk_pte(new_page, vma->vm_page_prot);
 	if (write_access) {

[linuxsh-dev] GDB configuration?

[Bryan R. <br...@ix...>]

Hello linuxsh-dev,

The following is a copy of a post I made this morning to linux-sh.
However, I believe this list is probably more appropriate. Since writing
it I have messed with gdb some more but I really think I have it
misconfigured, since there is no code in sh-boot to respond to the
packets it's sending the board on startup. Anyway:

---

I have been lurking on this list for a couple days while experimenting
with as much of the LinuxSH project sources as possible, trying to get
Linux up on a custom (basically bare) SH4 board. I successfully built
all the cross development tools, and have the sh-ipl/sh-boot stub
running on the system, and talking to my x86 linux workstation over the
serial port (38400bps). I can go in with a terminal program and get the
warranty, the license, etc... but what I really want is to get the
kernel running. However, for some reason, the GDB on my workstation just
does not want to talk to the embedded board. I have experimented with as
many versions of the boot/stub as I could find, including the one on
sourceforge CVS (which has some rather broken code in places), as well
as both gdb-sh-stub-2000-07-09.tar.gz and  sh-ipl+g-2000-08-11.tar.gz
from ftp://ftp.m17n.org/pub/super-h/ Since I have tried so much on the
embedded side, I now believe the problem is now with the GDB on the
workstation (which is fortunate, because it's much easier to debug). The
documentation on http://linuxsh.sourceforge.net/ is great, but says
nothing about GDB... however, http://www.m17n.org/linux-sh/dist/HOWTO
mentions that a patch is needed against GDB to get it talking to an
embedded board. So, I guess what I need to know is, is that patch still
needed against the gdb on linuxsh sourceforge CVS, and if so, where can
I get it? I would greatly appreciate an updated walkthrough of how to
get GDB compiled and talking to sh-boot/sh+ipl, as well as advice on
what version of the stub I should be working with, since it looks like
there are three forks of the same code (CVS sh-boot, gdb-sh-stub, and
sh-ipl+g).

I am assuming it is possible to load a kernel into an arbitrary memory
location (over the serial port) once GDB and the SH4 stub are talking?

Thanks to everyone for the great progress that has been made on LinuxSH.
I look forward to working with you in the future.

Regards,

Bryan Rittmeyer
mailto:br...@ix...

Re: [linuxsh-dev] Odd problem

[Jesper S. <js...@re...>]

>>>>> "NIIBE" == NIIBE Yutaka <gn...@ch...> writes:

NIIBE> Stuart Menefy wrote:
>> I've been looking at an odd problem for the last few days, and not
>> getting anywhere fast, so I was just wondering if anybody else has
>> seen something similar.

NIIBE> I don't see IDE problem.  I've been tracking cache problem
NIIBE> these days.  I don't know if it's related or not.

After updating to the -test6 changes, I also see a couple of
interesting problems. Your cache patches do not seem to make a change.

I haven't looked at the changes in detail to figure out what is
wrong. I've spent most of the day tracking the bad code. So this is
basically a FYI to avoid others losing time over this. I may get
around to look at the problems tomorrow, but I may have to just leave
out the code if there's other things to do.

The problems appear when running pppd under the new kernel. Two
separate problems:

1) pppd hangs. Never outputs anything on the serial line.
   This problem is due to the arch/sh/mm/fault.c TLB changes. Have
   anybody tested those on SH3?

2) pppd doesn't work properly. It seems to resend some of the
   compression headers multiple times, confusing the pppd at the other
   end which eventually drops the connection. This seems cache
   related in one form or another.

   This problem stems from these changes in mm/page_alloc.c:

diff -urN --exclude-from=/home/jskov/lib/diff-excludes -P /opt/RH-linuxsh/devo/linux/linux-sh/mm/page_alloc.c ./mm/page_alloc.c
--- /opt/RH-linuxsh/devo/linux/linux-sh/mm/page_alloc.c	Wed Aug 16 10:55:09 2000
+++ ./mm/page_alloc.c	Mon Aug 14 11:36:58 2000
@@ -29,7 +29,7 @@
 pg_data_t *pgdat_list;
 
 static char *zone_names[MAX_NR_ZONES] = { "DMA", "Normal", "HighMem" };
-static int zone_balance_ratio[MAX_NR_ZONES] = { 128, 128, 128, };
+static int zone_balance_ratio[MAX_NR_ZONES] = { 32, 128, 128, };
 static int zone_balance_min[MAX_NR_ZONES] = { 10 , 10, 10, };
 static int zone_balance_max[MAX_NR_ZONES] = { 255 , 255, 255, };
 
@@ -385,7 +385,7 @@
 	zone_t *zone;
 	int i;
 
-	sum = nr_lru_pages;
+	sum = nr_lru_pages / 3;
 	for (i = 0; i < NUMNODES; i++)
 		for (zone = NODE_DATA(i)->node_zones; zone <= NODE_DATA(i)->node_zones+ZONE_NORMAL; zone++)
 			sum += zone->free_pages;


Jesper

Re: [linuxsh-dev] Ptrace

[David M. <Dav...@st...>]

On Aug 16,  2:01am, mj...@al... wrote:
> Subject: Re: [linuxsh-dev] Ptrace
>
> David Mckay wrote:
> >
> > Hi,
> >
> > Is anybody doing any work on ptrace and strace?
>
> Hi David,
>
> Just a heads-up, Greg is working on the strace usermode
> program at the moment.  It's quite funny - as he goes
> through the existing source code, he groans and mutters.
> It's pretty bad code, I think it could be used to frighten
> small children.

He is obviously a lot braver than me. I started looking at that stuff and
rapidly put it on my list marked "Things I hope somebody else does before
I have to" :-)

As an aside, we now have an engineer working full time on producing a
distribution. It will be based on Montavista's distribution, and we will
be making it available as SRPMS on sourceforge. The guy who is doing it is
a Linux novice, so it may take some time for him to get up to speed. Hopefully
this will result in less duplication and prevent lots of people trying to get
the same programs to work.

Just out of curiosity, how many other people on the list are actually paid to
work full time on Linux for SuperH? We now have 3 here at ST.

Cheers!




-- 
Dave McKay 
Software Engineer STMicroelectronics
Email: dav...@st...

[linuxsh-dev] Odd problem

[NIIBE Y. <gn...@ch...>]

Stuart Menefy wrote:
 > I've been looking at an odd problem for the last few days, and not
 > getting anywhere fast, so I was just wondering if anybody else has seen
 > something similar.

I don't see IDE problem.  I've been tracking cache problem these days.
I don't know if it's related or not.

Patch is attached.  With the patch, it stabilize for me.

(1) When page is released, its cache (I-cache and D-cache) is not
flushed.  So, when using newly allocated page, we need to flush the
caches.

(2) When kernel writes to the page, we need to flush the cache.  If
not, when alias occurs, user space may read stale cached data.

People, could you please test the kernel with fewer memory (I'm using
mem=4M option) and swap enabled?


2000-08-16  NIIBE Yutaka  <gn...@m1...>

	* fs/buffer.c (end_buffer_io_async): Bug fix. Flush D-cache.  When
	kernel writes to the page, we should flush USER cache so that USER
	doesn't read stale data.

	* mm/memory.c (break_cow): Bug fix.  We need to flush D-cache.
	For newly allocated page, D-cache may contain stale USER data.
	flush_cache_page is not good for physically tagged architecture.
	(Note that flushing routine is called before setting PTE.)
	(do_wp_page: case 1): Likewise.
	(do_swap_page): Likewise.

2000-08-13  NIIBE Yutaka  <gn...@m1...>

	* mm/memory.c (break_cow): Bug fix.  We need to flush I-cache.
	For newly allocated page, I-cache may contain stale USER data.

	* arch/sh/mm/init.c (mem_init): Flush empty_zero_page.

Index: arch/sh/mm/init.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/init.c,v
retrieving revision 1.5
diff -u -r1.5 init.c
--- arch/sh/mm/init.c	2000/08/09 11:47:49	1.5
+++ arch/sh/mm/init.c	2000/08/16 08:11:41
@@ -241,6 +241,7 @@
 
 	/* clear the zero-page */
 	memset(empty_zero_page, 0, PAGE_SIZE);
+	flush_page_to_ram(virt_to_page(empty_zero_page));
 
 	/* this will put all low memory onto the freelists */
 	totalram_pages += free_all_bootmem();
Index: fs/buffer.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/fs/buffer.c,v
retrieving revision 1.6
diff -u -r1.6 buffer.c
--- fs/buffer.c	2000/08/08 08:03:51	1.6
+++ fs/buffer.c	2000/08/16 08:11:51
@@ -770,6 +770,7 @@
 	/* OK, the async IO on this page is complete. */
 	spin_unlock_irqrestore(&page_uptodate_lock, flags);
 
+	flush_dcache_page(page);
 	/*
 	 * if none of the buffers had errors then we can set the
 	 * page uptodate:
Index: mm/memory.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/mm/memory.c,v
retrieving revision 1.5
diff -u -r1.5 memory.c
--- mm/memory.c	2000/08/09 12:51:01	1.5
+++ mm/memory.c	2000/08/16 08:12:01
@@ -790,8 +790,8 @@
 		pte_t *page_table)
 {
 	copy_cow_page(old_page,new_page,address);
-	flush_page_to_ram(new_page);
-	flush_cache_page(vma, address);
+	flush_icache_page(vma, new_page);
+	flush_dcache_page(new_page);
 	establish_pte(vma, address, page_table, pte_mkwrite(pte_mkdirty(mk_pte(new_page, vma->vm_page_prot))));
 }
 
@@ -849,7 +849,7 @@
 		UnlockPage(old_page);
 		/* FallThrough */
 	case 1:
-		flush_cache_page(vma, address);
+		flush_dcache_page(old_page);
 		establish_pte(vma, address, page_table, pte_mkyoung(pte_mkdirty(pte_mkwrite(pte))));
 		spin_unlock(&mm->page_table_lock);
 		return 1;	/* Minor fault */
@@ -1060,7 +1060,7 @@
 		if (!page)
 			return -1;
 
-		flush_page_to_ram(page);
+		flush_dcache_page(page);
 		flush_icache_page(vma, page);
 	}
 

Re: [linuxsh-dev] Debianized packages of GNU tool chain

[Mitch D. <mj...@al...>]

YAEGASHI Takeshi wrote:
> 
> It seemed that we could not build glibc-2.1.3 with the newest
> gcc-core from CVS yet.  I've built glibc with older
> gcc(2.95.2.000228).  This might not the problem of binutils, but
> that of gcc-core.

Dear Takeshi-san,

Do you still have this problem?  If so, we need to find and fix
it.

We are able to build the .a version of glibc, but we can't
build it so a hello_world can link to the .so.  I seem to
remember that there was a complaint about some of the symbols
in libgcc.a or something.  I've been meaning to try it out again.

Regards,

Mitch.
--
mailto:mj...@al... | Certified Linux Evangelist!

Re: [linuxsh-dev] Ptrace

[Mitch D. <mj...@al...>]

David Mckay wrote:
> 
> Hi,
> 
> Is anybody doing any work on ptrace and strace?

Hi David,

Just a heads-up, Greg is working on the strace usermode
program at the moment.  It's quite funny - as he goes
through the existing source code, he groans and mutters.
It's pretty bad code, I think it could be used to frighten
small children.

Regards,

Mitch.
--
mailto:mj...@al... | Certified Linux Evangelist!

[linuxsh-dev] Odd problem

[Stuart M. <Stu...@st...>]

Folks

I've been looking at an odd problem for the last few days, and not
getting anywhere fast, so I was just wondering if anybody else has seen
something similar.

I have an IDE disk attached via a PCI card, which used to work fine.
However recently (unfortunatly I don't really know when) I started
seeing a problem:
  hda: lost interrupt
followed by some more debugging information which would appear to
indicate that the command was a disk write. The problem appears to be
unique to writes (mounting the file system read only, everything is fine).

However there are some odd features. For example turning off CPU
caches appears to also fix the problem, and whether disk is the root
file system, or mounted off a root filesystem on a ramdisk also
has an effect, but not conclusivly.

This is using the 'lastest' kernel from SourceForge (updating this
afternoon), but has also been seen in a 2.4.0-test5 system from a few
weeks ago.

Any suggestions welcome (please!)?

Stuart

[linuxsh-dev] Our day/Chiyonofuji problems

[Mitch D. <mj...@al...>]

Hello,

Greg and I are now working full-time on Linux on SuperH.
For the edification of all, and in the spirit of Alan Cox, 
we'll be posting a daily log for others to read.
We hope by reading this, you'll be able to benefit from
the things we find.

For today's entry, please look here:

  http://www.advogato.org/person/mjd/

(Advogato provides public diary services for people working
on Open Source software)

In particular, today's log talks about lots of problems
we are having with network services when using Niibe-san's
really useful "Chiyonofuji" distribution.  So as well as
hearing our story, it's an informal report of bugs and things
to look out for.

If you have any questions, please mail me.

Regards,

Mitch.
--
mailto:mj...@al... | Certified Linux Evangelist!

Re: [linuxsh-dev] problem in linuxsh-dev mailing list

[Jaswinder S. <jas...@ya...>]

hello Mitch,

how are you .

Thanks for your help and reply .

I am not able to work with linux-sh as well as
linuxsh-dev group , i am sorry for that , as i told
you about ELKS , right now i am very busy with ELKS
for 7709 , 7709A and 7750 .

i want to join you people very soon . 

Thanks.

Best Regards ,

Jaswinder.

--- Mitch Davis <mj...@al...> wrote:
> Hi Jaswinder,
> 
> It's not a problem on your side, but it's not a
> problem I
> can fix either.
> 
> Our mailing list is hosted by SourceForge, and they
> use
> GeoCrawler to archive mailing lists.  It appears
> from the
> "--gx73bnnz6l"'s at the end that GeoCrawler do not
> always
> save attachments, which is a pain.
> 
> One solution is for the author of a mailing list
> article to
> submit their patch to the patch manager on the
> LinuxSH
> development page (go to
> http://linuxsh.sourceforge.net then
> click on "Development" then "Patch Manager").  The
> article
> can then include the URL of this patch.
> (See
>
http://www.geocrawler.com/archives/3/3076/2000/7/0/4046894/
> for an example).
> 
> Unfortunately that doesn't help you with your
> problem!  I
> would suggest you write to Jesper Skov and ask him
> to
> mail you the patches.
> 
> Regards,
> 
> Mitch.
> --


__________________________________________________
Do You Yahoo!?
Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

Re: [linuxsh-dev] problem in linuxsh-dev mailing list

[Jaswinder S. <jas...@ya...>]

hello Mitch & Jesper,

Thanks for your help and reply .

Best Regards,
Jaswinder.


--- Jesper Skov <js...@re...> wrote:
> >>>>> "Mitch" == Mitch Davis <mj...@al...>
> writes:
> 
> Mitch> One solution is for the author of a mailing
> list article to
> Mitch> submit their patch to the patch manager on
> the LinuxSH
> Mitch> development page (go to
> http://linuxsh.sourceforge.net then
> Mitch> click on "Development" then "Patch Manager").
>  The article can
> Mitch> then include the URL of this patch.  (See
> Mitch>
>
http://www.geocrawler.com/archives/3/3076/2000/7/0/4046894/
> for
> Mitch> an example).
> 
> I have uploaded it to the patch manager now.
> 
> Jesper


__________________________________________________
Do You Yahoo!?
Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

Re: [linuxsh-dev] problem in linuxsh-dev mailing list

[Jesper S. <js...@re...>]

>>>>> "Mitch" == Mitch Davis <mj...@al...> writes:

Mitch> One solution is for the author of a mailing list article to
Mitch> submit their patch to the patch manager on the LinuxSH
Mitch> development page (go to http://linuxsh.sourceforge.net then
Mitch> click on "Development" then "Patch Manager").  The article can
Mitch> then include the URL of this patch.  (See
Mitch> http://www.geocrawler.com/archives/3/3076/2000/7/0/4046894/ for
Mitch> an example).

I have uploaded it to the patch manager now.

Jesper

Re: [linuxsh-dev] PCMCIA driver for SH3 PCC module (partial)

[Jesper S. <js...@re...>]

Jesper> I've written a (partial) driver for the PCC PCMCIA module in
Jesper> some of the SH3 CPUs (I have a SH7707 board).

This mail has been registered with the patch manager as well since the
archive doesn't keep attachments.

Jesper

Re: [linuxsh-dev] problem in linuxsh-dev mailing list

[Mitch D. <mj...@al...>]

Jaswinder Singh wrote:
> 
> I am facing one problem , regarding linuxsh-dev
> mailing list . I don't able to download :-
> 
> 1. pcmcia.diff
> 2. asm.diff
> 3. kernel.diff
> 
> from :-
> 
> http://www.geocrawler.com/archives/3/3076/2000/8/0/4158985/
> 
> is this my Browser fault , Or you don't provide the
> feature of downloading from linuxsh-dev mailing list.

Hi Jaswinder,

It's not a problem on your side, but it's not a problem I
can fix either.

Our mailing list is hosted by SourceForge, and they use
GeoCrawler to archive mailing lists.  It appears from the
"--gx73bnnz6l"'s at the end that GeoCrawler do not always
save attachments, which is a pain.

One solution is for the author of a mailing list article to
submit their patch to the patch manager on the LinuxSH
development page (go to http://linuxsh.sourceforge.net then
click on "Development" then "Patch Manager").  The article
can then include the URL of this patch.
(See http://www.geocrawler.com/archives/3/3076/2000/7/0/4046894/
for an example).

Unfortunately that doesn't help you with your problem!  I
would suggest you write to Jesper Skov and ask him to
mail you the patches.

Regards,

Mitch.
--
mailto:mj...@al... | Certified Linux Evangelist!

[linuxsh-dev] problem in linuxsh-dev mailing list

[Jaswinder S. <jas...@ya...>]

hello linuxsh-dev group,

I am facing one problem , regarding linuxsh-dev
mailing list . I don't able to download :-

1. pcmcia.diff 
2. asm.diff 
3. kernel.diff 

from :-

http://www.geocrawler.com/archives/3/3076/2000/8/0/4158985/

is this my Browser fault , Or you don't provide the
feature of downloading from linuxsh-dev mailing list.

thanks for your help .

Best Regards,

Jaswinder.


__________________________________________________
Do You Yahoo!?
Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

Re: [linuxsh-dev] Compile fix - CONFIG_GDB_STUB_VBR

[Greg B. <gn...@al...>]

>
>  Garrgh, stupid webmail beast lost my attachment, 
>I'll try again.
>

  No, this time for sure...how about I actually
post the right patch, the one that compiles....sigh.
http://www.alphalink.com.au/

Re: [linuxsh-dev] Compile fix - CONFIG_GDB_STUB_VBR

[Greg B. <gn...@al...>]

>Greg Banks wrote:
> >   Sorry, I was going to do this Monday but instead I spent all day
> > trying to track down an NFS problem.  Maybe tonight.
>
>You don't need to feel sorry.  It's not large change, you could
>postpone it.

  Or I could just stop whining and do it ;-)  Here's
the patch. It works fine on Mitch's SESH4, I'll be
interested to know how it goes on the Dreamcast.

  Garrgh, stupid webmail beast lost my attachment, 
I'll try again.
http://www.alphalink.com.au/

Re: [linuxsh-dev] Compile fix - CONFIG_GDB_STUB_VBR

[Greg B. <gn...@al...>]

>Greg Banks wrote:
> >   Sorry, I was going to do this Monday but instead I spent all day
> > trying to track down an NFS problem.  Maybe tonight.
>
>You don't need to feel sorry.  It's not large change, you could
>postpone it.

  Or I could just stop whining and do it ;-)  Here's
the patch. It works fine on Mitch's SESH4, I'll be
interested to know how it goes on the Dreamcast.


>			*	*	*
>
>I've been chasing cache issue (I guess) of SH-4.  I'm sure there's
>some problem around swap code.  I don't know if it's in generic code
>or in SuperH specific code yet.
>
>With swap, process occasionaly segfaults or aborts on SH-4.  You can
>reproduce it with setting the memory, say, 16MB.  When I disable
>operand cache ("data cache" in terms of SuperH), it works fine (quite
>slow though).  On SH-3, it works fine.
>
>So far, I couldn't find the bug yet.

  Arrgh, I hate those kind of bugs.


http://www.alphalink.com.au/

Re: [linuxsh-dev] Compile fix - CONFIG_GDB_STUB_VBR

[NIIBE Y. <gn...@ch...>]

Greg Banks wrote:
 >   Sorry, I was going to do this Monday but instead I spent all day
 > trying to track down an NFS problem.  Maybe tonight.

You don't need to feel sorry.  It's not large change, you could
postpone it.

			*	*	*

I've been chasing cache issue (I guess) of SH-4.  I'm sure there's
some problem around swap code.  I don't know if it's in generic code
or in SuperH specific code yet.

With swap, process occasionaly segfaults or aborts on SH-4.  You can
reproduce it with setting the memory, say, 16MB.  When I disable
operand cache ("data cache" in terms of SuperH), it works fine (quite
slow though).  On SH-3, it works fine.

So far, I couldn't find the bug yet.
-- 

Re: [linuxsh-dev] Compile fix - CONFIG_GDB_STUB_VBR

[Greg B. <gn...@al...>]

NIIBE Yutaka wrote:
> 
> Greg Banks wrote:
>  >   Hmm.  Perhaps a better solution than a config variable would be
>  > to record the old value of the VBR register in trap_init() and
>  > use that for stub trap delegation?  This should work on any system
>  > and not need the user to figure out where his system's gdb VBR
>  > table is loaded.  I can work up a patch for this tomorrow.
> 
> Agreed.  It's good idea.

  Sorry, I was going to do this Monday but instead I spent all day
trying to track down an NFS problem.  Maybe tonight.

Greg.
-- 
Fight spam http://www.caube.org.au/
If it's a choice between being a paranoid, hyper-suspicious global
village
idiot, or a gullible, mega-trusting sheep, I don't look good in mint
sauce. 
 - jd, slashdot, 11Feb2000.

Re: [linuxsh-dev] Compile fix - CONFIG_GDB_STUB_VBR

[NIIBE Y. <gn...@ch...>]

Greg Banks wrote:
 >   Hmm.  Perhaps a better solution than a config variable would be
 > to record the old value of the VBR register in trap_init() and
 > use that for stub trap delegation?  This should work on any system
 > and not need the user to figure out where his system's gdb VBR
 > table is loaded.  I can work up a patch for this tomorrow.

Agreed.  It's good idea.
-- 

[linuxsh-dev] printf and SCIF

[Studencki (e. P. <Paw...@er...>]

Hello,

Could somebody explain me a problem with "printf" ?

I'm using 2.3.99 Kernel with SCIF. (earlier was that SCI and it has worked
without troubles)
I can see kernel boot messages, but "printf" function in 'hello world'
programm doesn't work. (with SCI it has worked)

According to Niibe San mail [linux-sh:00790] with printk and printf
functions flow, I've added in init/main.c
line:

fd=sys_open("/dev/console", O_RDWR, 0);
sys_write(fd,"Hello world",11);

it works fine.

is the serial console at 'system_call' reconfigured or a problem with my
'hello world' program?

thanks for help in advance

Pawel