linuxsh-dev

[linuxsh-dev] Patches for UBC contention (GDB) and cache flush (KGDB)

[Jeremy S. <js...@mv...>]

Hi folks,

If nobody objects, I'd like to add the two attached patches to the into 
our 2.4 tree.

Reason for (1): currently, ptrace(SINGLESTEP) [used by GDB] sets the UBC 
registers, and break_point_trap() clears them.  But the ASID put into the 
UBC can be invalid if ASID rollover happens between the two schedulings of 
the target process; then the SIGTRAP goes to the wrong task.  Probably 
unusual in normal operation, but I still think it's A Bad Thing.  Or, if 
there are multiple GDBs or GDB threads such that a second ptrace() call is 
made before the first target task resumes, the UBC will be overwritten and 
the first trap will never happen.

Anyway, this patch attempts to address the problem by having ptrace() set 
the UBC values in the thread_struct of the task; only in __switch_to(), 
when the task is scheduled [and any new ASID already assigned] will the 
settings be put in the UBC registers; switching to a task w/o UBC settings 
in its thread_struct makes sure the UBC registers are cleared.  The 
thread_struct fields are cleared when the trap is hit or the thread exits.

Trying to minimize the runtime code path in __switch_to(), there's also a 
global counter incremented by ptrace() and decremented by the trap handler 
and exit_thread(); only when this is nonzero -- i.e. when some task is 
using the UBC -- are the other checks made.  Maybe this is overkill?  [My 
only concern with that was where to put the exit_thread() stuff; hope 
that's the right place.  Or is release_thread() better?]

Reason for (2): as it stands, flush_icache_range() clears the entire cache 
(both I and D).  I know a lot of work went into dealing with the cache 
functions so I'm assuming that's the fastest way to do it -- but the 
__flush_dcache_all() function that's used flushes everything _except_ the 
first several K of kernel text memory.  I guess this isn't a problem since 
that wouldn't be in the D-cache (modified!) normally, but it torpedos KGDB 
breakpoints there.  This patch makes kgdb use __flush_purge_region() to 
force the write-back.

Any complaints or suggestions?

Thanks,
   --Jeremy Siegel

Re: [linuxsh-dev] pci

[Paul M. <pau...@ti...>]

On Tue, 2002-11-05 at 10:25, Dave Samuel wrote:
> I'm trying to find the pci address of a pci extension board in my hitachi
> solution engine, so that I can mmap the address and write to the board.
>=20
> How can I find the pci address this extension card has received ?
>=20
The mapped BARs happen at init time, and depending on your board, you
may even need BAR fixups.

If you're attempting to write a driver for this board, I'm quite at a
loss as to why you would want to expose an mmap() interface for the BAR
so you can remap through userspace.

If you want to ioremap() the mem BAR, you can certainly do so. Take a
look at /proc/pci or grab pciutils and take a look at 'lspci -vvv' to
determine where the mem BAR you want to remap is situated.

Linux exposes PCI access routines to do this in the form of
pci_resource_start(pdev, BAR_nr) and pci_resource_len(pdev, BAR_nr),
which you can pass to ioremap()/ioremap_nocache() directly to get a
corresponding cached/uncached virtual address.

Regards,

--=20
Paul Mundt
pau...@ti...
TimeSys Corporation

[linuxsh-dev] pci

[Dave S. <Dav...@vi...>]

Hello,

I'm trying to find the pci address of a pci extension board in my hitachi
solution engine, so that I can mmap the address and write to the board.

How can I find the pci address this extension card has received ?

Regards,

Dave Samuel

[linuxsh-dev] Linux 2.5.45

[M. R. B. <mr...@0x...>]

All Config.[help|in] files were removed, and replaced by the new Kconfig
system.  I haven't tested yet.

M. R.


2002-11-01  M. R. Brown  <mr...@li...>

	* drivers/cdrom/Kconfig, drivers/char/Kconfig,
	drivers/input/joystick/Kconfig, drivers/input/keyboard/Kconfig,
	drivers/net/Kconfig: Add from stock 2.5.45.
	* drivers/cdrom/Config.help, drivers/char/Config.help,
	drivers/input/joystick/Config.help: Remove.

	Linux 2.5.45.

	* AGAINST-2.5.45: New file.
	* AGAINST-2.5.44: Remove.

	* arch/sh/Kconfig: New file.
	* arch/sh/Config.help, drivers/cdrom/Config.help,
	drivers/cdrom/Config.in, drivers/char/Config.help,
	drivers/input/joystick/Config.help, drivers/input/joystick/Config.in,
	drivers/maple/Config.in, drivers/mtd/maps/Config.help,
	drivers/mtd/maps/Config.in, drivers/mtd/Config.help,
	drivers/net/Config.help, drivers/net/Config.in, arch/sh/config.in:
	Remove.

	* Makefile, arch/sh/mm/fault.c, drivers/char/Makefile,
	drivers/net/8139too.c, fs/mpage.c, init/do_mounts.c, kernel/timer.c:
	Merge changes from Linux 2.5.45.

Re: [linuxsh-dev] pread/pwrite fix for SH-4

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

M. R. Brown wrote:
 > Yep.  Sorry.  I assumed it was a glibc problem only.

You don't need to be sorry.  There would be glibc only solution, 
and it would be better, I don't know.  Will code.
-- 

Re: [linuxsh-dev] Merging linux-2_5-restructure into HEAD

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

OK, let's go ahead.  When I'll get the time (perhaps from next week) I
can help you.
-- 

Re: [linuxsh-dev] pread/pwrite fix for SH-4

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Fri, Nov 01, 2002:

> M. R. Brown wrote:
>  > You're confusing pread w/ pread64.
>=20
> Please look the problem at first.  Linux's "pread" API is different
> with POSIX.  We don't have pread64 in Linux.  Please check.  The last
> argument is 64-bit (long-long) in Linux, but GNU C library offers
> POSIX API.
>=20

I've been doing too much 2.5 hacking lately.  I apologize for this, there's
a pread64 in 2.5, not 2.4 (apparently it was renamed).

> I think that your opinion is the Right Thing, basically (handle in
> libc layer rather than in kernel).  In general.
>=20
> But I wonder if you understand this problem, specifically.
>=20

I do now.

> The issue is calling convention of long-long.
>=20
> I think that better way to solve this is implement pread with 6
> arguments with dummy fourth argument, as MIPS implementation.
>=20
> I mean, fix kernel, fix glibc, BOTH.

Yep.  Sorry.  I assumed it was a glibc problem only.

M. R.

Re: [linuxsh-dev] Merging linux-2_5-restructure into HEAD

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Fri, Nov 01, 2002:

>=20
> I think that restructure is good thing, but the migration with broken
> status is violent.
>=20
> Do test and fix the problems in HEAD, then the restructure.
>=20

Current restructure is 2.5.44 HEAD, merged with restructure a few days ago.
After that merge, I did a few cleanups in restructure to make sure it built
and ran properly.  Keep in mind that I had HEAD 2.5.44 booting first,
before I merged w/ restructure.

Also please note that as soon as restructure is merged, HEAD will magically
start working again - that's the point of merging now, rather than wasting
time fixing things in a tree we won't be using for much longer anyway.

> Or else, we just complicate the issue.

Maintaining two divergent trees complicates things.  Please allow me to
merge as soon as possible.

M. R.

[linuxsh-dev] Merging linux-2_5-restructure into HEAD

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

M. R. Brown wrote:
 > Are there any objections?=20

I think that restructure is good thing, but the migration with broken
status is violent.

Do test and fix the problems in HEAD, then the restructure.

Or else, we just complicate the issue.
-- 

Re: [linuxsh-dev] pread/pwrite fix for SH-4

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

M. R. Brown wrote:
 > You're confusing pread w/ pread64.

Please look the problem at first.  Linux's "pread" API is different
with POSIX.  We don't have pread64 in Linux.  Please check.  The last
argument is 64-bit (long-long) in Linux, but GNU C library offers
POSIX API.

I think that your opinion is the Right Thing, basically (handle in
libc layer rather than in kernel).  In general.

But I wonder if you understand this problem, specifically.

The issue is calling convention of long-long.

I think that better way to solve this is implement pread with 6
arguments with dummy fourth argument, as MIPS implementation.

I mean, fix kernel, fix glibc, BOTH.
-- 

[linuxsh-dev] Merging linux-2_5-restructure into HEAD

[M. R. B. <mr...@0x...>]

I'm ready.  HEAD is already broken for 2.5, so merging a semi-working (for
Dreamcast) restructure won't lose anything, and linux-sh 2.5 development is
pretty much dead otherwise.  I'd also like to do this before I sync up with
2.5.45.

Are there any objections?=20

M. R.

Re: [linuxsh-dev] pread/pwrite fix for SH-4

[M. R. B. <mr...@0x...>]

* SUGIOKA Toshinobu <su...@it...> on Fri, Nov 01, 2002:

> Hi, all.
>=20
> Currently, pread/pwrite system call do not work on SH-4.
>=20
> This is caused by mismatch of calling convention.
> (see glibc-2.2.5/sysdeps/unix/sysv/linux/pread.c)
> glibc invokes pread system call with 5 long arguments,
> but sys_pread takes 3 longs and 1 long long. These are
> different on SH-4. (otherwise same on SH-3)
>=20
> I have attached the patch which I'll commit if no one has any objections.
>=20

You're confusing pread w/ pread64.  Please fix glibc, and keep this mess
out of the kernel.

M. R.

[linuxsh-dev] pread/pwrite fix for SH-4

[SUGIOKA T. <su...@it...>]

Hi, all.

Currently, pread/pwrite system call do not work on SH-4.

This is caused by mismatch of calling convention.
(see glibc-2.2.5/sysdeps/unix/sysv/linux/pread.c)
glibc invokes pread system call with 5 long arguments,
but sys_pread takes 3 longs and 1 long long. These are
different on SH-4. (otherwise same on SH-3)

I have attached the patch which I'll commit if no one has any objections.

Index: arch/sh/kernel/entry.S
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/entry.S,v
retrieving revision 1.1.1.1.2.11
diff -u -r1.1.1.1.2.11 entry.S
--- arch/sh/kernel/entry.S	1 Oct 2002 00:43:32 -0000	1.1.1.1.2.11
+++ arch/sh/kernel/entry.S	31 Oct 2002 15:14:18 -0000
@@ -1147,8 +1147,13 @@
 	.long SYMBOL_NAME(sys_rt_sigtimedwait)
 	.long SYMBOL_NAME(sys_rt_sigqueueinfo)
 	.long SYMBOL_NAME(sys_rt_sigsuspend)
+#ifdef __SH4__
+	.long SYMBOL_NAME(sh4_sys_pread)	/* 180 */
+	.long SYMBOL_NAME(sh4_sys_pwrite)
+#else
 	.long SYMBOL_NAME(sys_pread)		/* 180 */
 	.long SYMBOL_NAME(sys_pwrite)
+#endif
 	.long SYMBOL_NAME(sys_chown16)
 	.long SYMBOL_NAME(sys_getcwd)
 	.long SYMBOL_NAME(sys_capget)
Index: arch/sh/kernel/sys_sh.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/sys_sh.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 sys_sh.c
--- arch/sh/kernel/sys_sh.c	15 Oct 2001 20:44:53 -0000	1.1.1.1
+++ arch/sh/kernel/sys_sh.c	31 Oct 2002 15:14:18 -0000
@@ -84,6 +84,30 @@
 			addr = COLOUR_ALIGN(addr);
 	}
 }
+
+asmlinkage ssize_t sh4_sys_pread(unsigned int fd, char * buf,
+			     size_t count, unsigned long pos0, unsigned long pos1)
+{
+extern asmlinkage ssize_t sys_pread(unsigned int fd, char * buf,
+			     size_t count, loff_t pos);
+#ifdef __LITTLE_ENDIAN__
+	return sys_pread(fd, buf, count, (loff_t)pos0 | ((loff_t)pos1 << 32));
+#else
+	return sys_pread(fd, buf, count, (loff_t)pos1 | ((loff_t)pos0 << 32));
+#endif
+}
+
+asmlinkage ssize_t sh4_sys_pwrite(unsigned int fd, const char * buf,
+			      size_t count, unsigned long pos0, unsigned long pos1)
+{
+extern asmlinkage ssize_t sys_pwrite(unsigned int fd, char * buf,
+			     size_t count, loff_t pos);
+#ifdef __LITTLE_ENDIAN__
+	return sys_pwrite(fd, buf, count, (loff_t)pos0 | ((loff_t)pos1 << 32));
+#else
+	return sys_pwrite(fd, buf, count, (loff_t)pos1 | ((loff_t)pos0 << 32));
+#endif
+}
 #endif
 
 static inline long

----
SUGIOKA Toshinobu

Re: [linuxsh-dev] memory problem

[SUGIOKA T. <su...@it...>]

On Wed, 2002-10-30 at 00:52, SUGIOKA Toshinobu wrote:
> On my SH7750S (200MHz, 128MB) board, user land application
> causes segmentation fault and/or unaligned access randomly when
> very high memory load with swap on.

This is my fault. I'm trying Stuart Menefy's new TLB handling, and
my modification of kernel caused this problem. After reverting all,
there is no problem about this. I'm sorry for incorrect message.

By the way, I applied Stuart's TLB patch to 2.4 branch, but it does not work at all.
Missing some other part ? 

At 12:49 02/10/30 -0500, Paul Mundt <pau...@ti...> wrote:
>This looks like more of a problem of flush_page_to_ram() not doing its
>job. If we look at DaveM's cache/tlb flushing docs, we see the
>following:
>
>  flush_page_to_ram(struct page *page)
>
>        The physical page 'page' is about to be place into the
>        user address space of a process.  If it is possible for
>        stores done recently by the kernel into this physical
>        page, to not be visible to an arbitrary mapping in userspace,
>        you must flush this page from the D-cache.
>
>        If the D-cache is writeback in nature, the dirty data (if
>        any) for this physical page must be written back to main
>        memory before the cache lines are invalidated.
>
>This looks pretty straightforward in nature, and for this application, I
>think we'd be better off simply aliasing flush_page_to_ram() to
>flush_dcache_page(). At least it looks like it'll do the Right Thing(tm)
>more often then not that way (with potentially a few extra dcache
>flushes..).
>

This patch causes extra dcache flushes too much.

before 
   374 __copy_user_page                           4.4524
   480 schedule                                   0.4286
   488 net_send_packet                            1.1731
   592 __clear_user_page                         12.3333
   622 __flush_cache_page                         2.1597
  1227 statm_pgd_range                            2.7388
  1750 pss2001_insw                              13.6719
  5709 cpu_idle                                  35.6812
 26515 total                                      0.0214

after
   212 __flush_cache_page                         0.7361
   223 __copy_user_page                           2.6548
   226 __clear_user_page                          4.7083
   316 do_wp_page                                 0.4938
   614 pss2001_insw                               4.7969
   773 do_anonymous_page                          2.6840
  1058 flush_page_to_ram                          4.1328
  2085 filemap_nopage                             2.9616
  2645 do_no_page                                 7.5142
  2830 cpu_idle                                  17.6875
 16878 total                                      0.0136

Regards.

----
SUGIOKA Toshinobu

Re: [linuxsh-dev] memory problem

[Paul M. <pau...@ti...>]

This looks like more of a problem of flush_page_to_ram() not doing its
job. If we look at DaveM's cache/tlb flushing docs, we see the
following:

  flush_page_to_ram(struct page *page)

        The physical page 'page' is about to be place into the
        user address space of a process.  If it is possible for
        stores done recently by the kernel into this physical
        page, to not be visible to an arbitrary mapping in userspace,
        you must flush this page from the D-cache.

        If the D-cache is writeback in nature, the dirty data (if
        any) for this physical page must be written back to main
        memory before the cache lines are invalidated.

This looks pretty straightforward in nature, and for this application, I
think we'd be better off simply aliasing flush_page_to_ram() to
flush_dcache_page(). At least it looks like it'll do the Right Thing(tm)
more often then not that way (with potentially a few extra dcache
flushes..).

I've attached a patch that does this for HEAD and restructure, which
I'll push in if no one has any objections.

On Wed, 2002-10-30 at 00:52, SUGIOKA Toshinobu wrote:
> On my SH7750S (200MHz, 128MB) board, user land application
> causes segmentation fault and/or unaligned access randomly when
> very high memory load with swap on.
>=20
> You could easily reproduce with 'stress' program.
> http://weather.ou.edu/~apw/projects/stress/
>=20
> Following patch fixes this problem, but I'm not sure if this is correct.
> Does anyone else encountered this problem?
>=20
> --- mm/memory.c~      Thu Apr 11 17:57:49 2002
> +++ mm/memory.c       Wed Oct 30 14:30:21 2002
> @@ -1170,6 +1170,7 @@
>                 pte =3D pte_mkdirty(pte_mkwrite(pte));
>         unlock_page(page);
>=20
> +       flush_dcache_page(page);
>         flush_page_to_ram(page);
>         flush_icache_page(vma, page);
>         set_pte(page_table, pte);
>=20

Regards,

--=20
Paul Mundt
pau...@ti...
TimeSys Corporation

2002-10-30  Paul Mundt  <le...@li...>

	* arch/sh/mm/cache-sh4.c (flush_page_to_ram): Added, as an alias
	to flush_dcache_page().
=09
	* include/asm-sh/cacheflush.h (flush_page_to_ram): Moved to an
	extern reference.

Index: arch/sh/mm/cache-sh4.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/linuxsh/linux/arch/sh/mm/cache-sh4.c,v
retrieving revision 1.1.1.1.4.2
diff -u -r1.1.1.1.4.2 cache-sh4.c
--- arch/sh/mm/cache-sh4.c	27 Oct 2002 21:22:50 -0000	1.1.1.1.4.2
+++ arch/sh/mm/cache-sh4.c	30 Oct 2002 16:37:40 -0000
@@ -249,6 +249,9 @@
 	}
 }
=20
+void flush_page_to_ram(struct page *page)
+	__attribute__ ((alias("flush_dcache_page")));
+
 static inline void flush_icache_all(void)
 {
 	unsigned long flags;
Index: include/asm-sh/cacheflush.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/linuxsh/linux/include/asm-sh/cacheflush.h,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 cacheflush.h
--- include/asm-sh/cacheflush.h	27 Oct 2002 20:10:27 -0000	1.1.2.1
+++ include/asm-sh/cacheflush.h	30 Oct 2002 16:37:56 -0000
@@ -44,13 +44,13 @@
 			      unsigned long end);
 extern void flush_cache_page(struct vm_area_struct *vma, unsigned long add=
r);
 extern void flush_dcache_page(struct page *pg);
+extern void flush_page_to_ram(struct page *pg);
 extern void flush_icache_range(unsigned long start, unsigned long end);
 extern void flush_cache_sigtramp(unsigned long addr);
 extern void flush_icache_user_range(struct vm_area_struct *vma,
 				    struct page *page, unsigned long addr,
 				    int len);
=20
-#define flush_page_to_ram(page)			do { } while (0)
 #define flush_icache_page(vma,pg)		do { } while (0)
=20
 /* Initialization of P3 area for copy_user_page */

[linuxsh-dev] memory problem

[SUGIOKA T. <su...@it...>]

Hi, all.

On my SH7750S (200MHz, 128MB) board, user land application
causes segmentation fault and/or unaligned access randomly when
very high memory load with swap on.

You could easily reproduce with 'stress' program.
http://weather.ou.edu/~apw/projects/stress/

Following patch fixes this problem, but I'm not sure if this is correct.
Does anyone else encountered this problem?

--- mm/memory.c~      Thu Apr 11 17:57:49 2002
+++ mm/memory.c       Wed Oct 30 14:30:21 2002
@@ -1170,6 +1170,7 @@
                pte = pte_mkdirty(pte_mkwrite(pte));
        unlock_page(page);

+       flush_dcache_page(page);
        flush_page_to_ram(page);
        flush_icache_page(vma, page);
        set_pte(page_table, pte);

----
SUGIOKA Toshinobu

[linuxsh-dev] Restructure branch status 10/27

[M. R. B. <mr...@0x...>]

I just wanted to give a quick status report of what's going on in the
linux-2_5-restructure branch:

* Updated to Linux 2.5.44 - this was after HEAD was updated, then merged
  into restructure
* Boots w/ serial console on the Dreamcast (this is the only board I have
  to test).  Paul says he will test on his SE7750 later.
* Notable quirks with booted system (NFS root mounted system): system
  doesn't shutdown properly on reboot.

If someone out there wants to give it a shot, keep in mind that any other
consoles other than serial will *not* work, this will be fixed soon.  Also,
take a look at arch/sh/boards/dreamcast/pci.c to see how the new
pcibios_init() works, you'll need to add subsys_initcall(pcibios_init) if
your board uses PCI.

I still have items to tackle in the TODO before restructure is ready for
scrutiny before taking over HEAD.  I'm hoping to have those done by the end
of this week.  I also have an upcoming proposal for splitting up CPU
families (e.g. sh3, sh4, sh5) and CPU subtypes (7709, 7750, 7751, etc.),
more on that later.

Feedback welcome.

M. R.

[linuxsh-dev] TEST - Please ignore

[M. R. B. <mr...@0x...>]

I'm testing to see if whitelist support for list posting works -- looks
like we have to manually add poster e-mail addresses to the whitelist if
this mail goes through without requiring approval.

Please ignore :)

M. R.

P. S.: If anyone knows if the mailman whitelist can support wildcard or
regexps to select a group of addresses, please let me know.

[linuxsh-dev] LinuxSH 2.4.20-pre11

[M. R. B. <mr...@0x...>]

Boots and tested (not extensively) on my Dreamcast.  Same with the previous
2.4.19.  Note Paul Mundt said his 2.4.19 kernel deadlocked on his SE 7750,
but I don't know if he's found the problem yet.  Please let us know if you
have problems with either of these kernels on your boards.

M. R.


2002-10-24  M. R. Brown  <mr...@li...>

	* arch/sh/kernel/pcibios.c (pcibios_enable_device): Change function
	declaration to match include/linux/pci.h.

	* Documentation/Configure.help, drivers/char/shwdt.c,
	drivers/char/tty_io.c, drivers/net/Config.in: Fix merge breakage.

	Linux 2.4.20-pre11

	* AGAINST-2.4.20-pre11: New file.
	* AGAINST-2.4.19: Removed.

	* Documentation/Configure.help, Makefile, arch/sh/config.in,
	arch/sh/kernel/pcibios.c, arch/sh/mm/fault.c, drivers/block/rd.c,
	drivers/Makefile, drivers/char/joystick/Config.in,
	drivers/char/joystick/Makefile, drivers/char/Makefile,
	drivers/char/shwdt.c, drivers/char/tty_io.c,
	drivers/mtd/maps/Config.in, drivers/net/8139too.c,
	drivers/net/Config.in, drivers/pci/pci.ids, fs/nfs/inode.c,
	include/asm-sh/pgtable-2level.h, include/asm-sh/semaphore.h,
	include/asm-sh/socket.h, include/asm-sh/termios.h,
	include/asm-sh/timex.h, include/linux/highmem.h,
	include/linux/input.h, init/do_mounts.c, mm/memory.c: Merge changes
	from Linux 2.4.20-pre11.

Re: [linuxsh-dev] LinuxSH 2.4.19 and minor cleanups

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

>Not everyone, but perhaps people who explicitly requests it.
>I'd venture to guess out of those 140 people, only a dozen
>or so actually post "actively" to the list.

I've added a bunch of regulars which should catch
90% of messages.  I'll send you the list by
private email to see what you think.

>I'd be willing to share the load with you,

Load's not a problem as it's only a few times a week.
It's frequency more than anything.  I'll send you the
password offline.  Any others who want it, please mail
me.

Mitch.

Re: [linuxsh-dev] LinuxSH 2.4.19 and minor cleanups

[M. R. B. <mr...@0x...>]

* mj...@al... <mj...@al...> on Wed, Oct 23, 2002:

>=20
>  - List of members who can post without approval:
>    (Currently empty - should I copy in all 140
>    linuxsh-dev members?  And then how about keeping
>    it up to date?)
>=20

Not everyone, but perhaps people who explicitly requests it.  I'd venture to
guess out of those 140 people, only a dozen or so actually post "actively"
(strong quotes there :P) to the list.  I'd like to be added at least.  You
can probably go back 6 months to see who the most frequent posters are.

Also, and I don't have mailman in front of me so I forget how it's setup,
but for the linuxsh-cvs list at least you can add *@users.sourceforge.net,
since that's the only place e-mails should come in from.  There shouldn't
be any outside posting to that list anyway, so it should ideally be
configured as read-only.

>=20
> Or another idea is that I turn "tell user when
> their msg awaits approval" on, and edit the mail
> they're sent to include the list administrator
> password; if you post, go and approve your own
> posting.
>=20

I'd think this would be a security risk and could open the list to abuse.

> Ideally we could have a solution which required no
> intervention on my part.  Hey guys, what do you think
> we should do?  Anyone want the job?  I'm very open
> to suggestions, and not fussed either way.
>=20

I'd be willing to share the load with you, and hopefully a couple of others
will volunteer.  Just send me the pertinent details off-list, I'd be happy
to assist.

M. R.

Re: [linuxsh-dev] LinuxSH 2.4.19 and minor cleanups

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

> Btw, is there a reason posts take anywhere between a
> few hours and over a day to show up on the dev and cvs 
> mailing lists?

Yeah, messages don't appear until I approve them.  It's
a compromise between having a delay, and having a constant
stream of spam offering to enlarge your manliness, etc.

There are a bunch of mailman admin options which
control this sort of thing:

 - Must posts be approved by an administrator?
   (Currently "Yes".  I've turned this on so I
   can delete spam).

 - Restrict posting privilege to list members? 
   (Currently "No".  I've turned this off so that
   geniune non-members can post to the list, for
   example, Rekha Deshmukh's post last week).

 - List of members who can post without approval:
   (Currently empty - should I copy in all 140
   linuxsh-dev members?  And then how about keeping
   it up to date?)

Ideally SourceForge would set up mailman so it used
SpamAssassin or similar to kill spam.  Then messages
would be instant, and there'd be little to no spam.

Or another idea is that I turn "tell user when
their msg awaits approval" on, and edit the mail
they're sent to include the list administrator
password; if you post, go and approve your own
posting.

Ideally we could have a solution which required no
intervention on my part.  Hey guys, what do you think
we should do?  Anyone want the job?  I'm very open
to suggestions, and not fussed either way.

Mitch.

[linuxsh-dev] LinuxSH 2.4.19 and minor cleanups

[M. R. B. <mr...@0x...>]

I'll get to 2.4.20-pre11 in a few hours.

Btw, is there a reason posts take anywhere between a few hours and over a
day to show up on the dev and cvs mailing lists?

M. R.


2002-10-22  M. R. Brown  <mr...@li...>

	* init/do_mounts.c: Add "gdrom" to the dev_name_struct struct.

	* Documentation/Configure.help, drivers/char/Makefile,
	drivers/char/shwdt.c, drivers/char/sysrq.c, drivers/mtd/mtdpart.c,
	drivers/net/Config.in, fs/nfs/inode.c: Fix merge breakage.

	Linux 2.4.19

	* AGAINST-2.4.19: New file.
	* AGAINST-2.4.18: Removed.

	* init/do_mounts.c: Imported from 2.4.19 in preparation of local
	changes.

	* Documentation/Configure.help, Documentation/cachetlb.txt, Makefile,
	arch/sh/kernel/entry.S, arch/sh/kernel/setup.c,
	arch/sh/kernel/signal.c, arch/sh/mm/init.c, drivers/block/rd.c,
	drivers/Makefile, drivers/char/Makefile, drivers/char/sh-sci.c,
	drivers/char/shwdt.c, drivers/char/sysrq.c, drivers/char/tty_io.c,
	drivers/mtd/maps/Config.in, drivers/mtd/mtdpart.c,
	drivers/net/8139too.c, drivers/net/Config.in, drivers/pci/pci.ids,
	fs/nfs/inode.c, include/asm-sh/ide.h, include/asm-sh/pgtable.h,
	include/asm-sh/siginfo.h, include/asm-sh/unistd.h,
	include/linux/mtd/partitions.h, include/linux/highmem.h,
	include/linux/input.h, init/main.c, kernel/ptrace.c, mm/memory.c:
	Merge changes from Linux 2.4.19.

Re: [linuxsh-dev] Sync from 2.5.43 / Beating the freeze

[Tom R. <tr...@ke...>]

On Sun, Oct 20, 2002 at 01:02:05PM +0900, NIIBE Yutaka wrote:

> I don't think change of the architecture port will be considered as
> "feature" in feature freeze, provided we don't have changes in generic
> part.

And as long as the generic parts consist of new drivers.  I know over
in the PPC32 camp we're hoping Linus still allows the arch maintainers
to do what they need to / want to get done since we've got a few
projects that haven't been started yet as the rest of the kernel hasn't
been quite stable enough. :)

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [linuxsh-dev] Sync from 2.5.43 / Beating the freeze

[Jeremy S. <js...@mv...>]

NIIBE Yutaka wrote:
> I don't think change of the architecture port will be considered as
> "feature" in feature freeze, provided we don't have changes in generic
> part.
> 
> Anyway, it would be good if we have:
> 	(1) Signal handler bug fix (system call restart)
> 	(2) gUSA
> 	(3) Stuart Menefy's fast memcpy
> 	(4) Stuart Menefy's fast TLB-miss handling
> 
> I've tested (1), (2) in 2.4.18 throughout.  I don't test (3) and (4)
> yet.  SH-3 people should read and check (3) and (4), I think.
> 
> (2) would be "feature", I've done it for MIPS, SH, and ARM.  All works
> well.

Niibe,

Do you know if/when use of gUSA will actually be in glibc?  (I thought 
you'd designed it for the atomic operations in glibc, but is there some 
other code out there that takes advantage of it already?)

Thanks,
   --Jeremy