Re: CVS Update@oss.sgi.com: linux

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Mon, Feb 21, 2000 at 10:54:45AM +0100, Geert Uytterhoeven wrote:

> > Modified files:
> > 	include/asm-mips: uaccess.h 
> > 	include/asm-mips64: uaccess.h 
> > 
> > Log message:
> > 	Fix copy_from_user() in modules and 64-bit kernel.
> 
> Now the assembler complains with
> 
>     Warning: Used $at without ".set noat"

I just tried to build an Indy kernel and did not get this warning.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Mon, Feb 21, 2000 at 04:46:52PM +0100, Geert Uytterhoeven wrote:

> I guess the problem is the nested .set noat/at construct, where __MODULE_JAL
> does .set at while copy_from_user() assumes we're still in noat mode?

Yep, looking at the assembler code your report immediately made sense.
Fix going to CVS as I write this.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Geert Uytterhoeven]

On Mon, 21 Feb 2000, Ralf Baechle wrote:
> On Mon, Feb 21, 2000 at 10:54:45AM +0100, Geert Uytterhoeven wrote:
> > > Modified files:
> > > 	include/asm-mips: uaccess.h 
> > > 	include/asm-mips64: uaccess.h 
> > > 
> > > Log message:
> > > 	Fix copy_from_user() in modules and 64-bit kernel.
> > 
> > Now the assembler complains with
> > 
> >     Warning: Used $at without ".set noat"
> 
> I just tried to build an Indy kernel and did not get this warning.

I guess it depends on the configuration. From looking at the list of files I
got complaints for, I do believe you didn't get them when building for an Indy.

Can you try to compile the module for the loop block device? The problem
happens near the call to copy_from_user() in loop_set_status(). The generated
code is (warning position indicated with `>>>'):

	    .set    noreorder
	    .set    noat
	    .set    noat
	    la      $1, __copy_user
	    jalr    $1
	    .set    at
>>>	    addu    $1, $13, $7
	    .set    at
	    .set    reorder
	    move    $7, $6
     #NO_APP
    $L1492:
	    .set    noreorder
	    .set    nomacro
	    bne     $7,$0,$L1502
	    li      $2,-14                  # 0xfffffff2
	    .set    macro
	    .set    reorder

I guess the problem is the nested .set noat/at construct, where __MODULE_JAL
does .set at while copy_from_user() assumes we're still in noat mode?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Mon, Mar 27, 2000 at 01:05:04PM -0800, Ulf Carlsson wrote:

> Modified files:
> 	arch/mips64/kernel: head.S 
> 
> Log message:
> 	Use 16 FP registers as default.

Please leave this flag set since 32 fpr is the default for the ABI64
code model.  The right place to set this flag is in
include/asm-mips64/processor.h:start_thread().

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Fri, May 19, 2000 at 08:32:31AM +0000, Florian Lohoff wrote:

> Log message:
> 	Let tty_io.c call init_serial_console (CONFIG_SERIAL vs. CONFIG_SGI_SERIAL)

Which reminds me that sgiserial.c and serial.c have a namespace collison
that's actually relevant in certain configurations.  I'll prepare a fix.

  Ralf

RE: CVS Update@oss.sgi.com: linux

[Harald Koerfgen]

On 23-May-00 Klaus Naumann wrote:
[offset.h problems with my recent CVS changes snipped]

> Well, unfortunately this doesn't fix the problem.
> At least not for me. I get the same error I 
> stated a mail ago - offset.h is generated after 
> the use in main.c .

Ok, trying to fix that I added a fastdep rule to arch/mips/tools/Makefile only to
find myself in a catch 22 situation. offset.c includes asm/ptrace.h which, in
turn, includes asm/offset.h, i.e. you have to have offset.h to create offset.h :-o

Without heavily messing around with several header files, which may have an
impact on non-MIPS platforms as well, I see no easy solution for that. Adding an
empty offset.h, on the other hand, and leaving the .cvsignore in place should at
least partially do what I want. Any objections?

And now for something completly different. Why the hell did I mess around with
that?

Well, if something in the kernel is changed which affects offset.h then
generating a diff against a fresh CVS copy will contain those differences. That
annoyed me because, personally, I find this disturbing when reviewing those diffs.
Nobody really needs that anyway, at least that's what I thought, because offset.h
is generated automatically.

The suggestion I made above would not solve that but at least avoids that those
changes creep into the CVS.

-- 
Regards,
Harald

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Wed, May 24, 2000 at 06:50:09PM +0200, Harald Koerfgen wrote:

> Ok, trying to fix that I added a fastdep rule to arch/mips/tools/Makefile only to
> find myself in a catch 22 situation. offset.c includes asm/ptrace.h which, in
> turn, includes asm/offset.h, i.e. you have to have offset.h to create offset.h :-o
> 
> Without heavily messing around with several header files, which may have an
> impact on non-MIPS platforms as well, I see no easy solution for that. Adding an
> empty offset.h, on the other hand, and leaving the .cvsignore in place should at
> least partially do what I want. Any objections?
> 
> And now for something completly different. Why the hell did I mess around with
> that?
> 
> Well, if something in the kernel is changed which affects offset.h then
> generating a diff against a fresh CVS copy will contain those differences. That
> annoyed me because, personally, I find this disturbing when reviewing those diffs.
> Nobody really needs that anyway, at least that's what I thought, because offset.h
> is generated automatically.
> 
> The suggestion I made above would not solve that but at least avoids that those
> changes creep into the CVS.

A good solution is important now that we have SMP.  Toggling CONFIG_SMP
affects offset.h and not for all variations of make invocations we
actually have the guarantee that offset.h is being rebuilt before using
it.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Harald Koerfgen]

On 24-May-00 Ralf Baechle wrote:
[offset.h]

> A good solution is important now that we have SMP.  Toggling CONFIG_SMP
> affects offset.h and not for all variations of make invocations we
> actually have the guarantee that offset.h is being rebuilt before using
> it.

What about making offset.h to depend on $(TOPDIR)/.config?

This may cause unneccessary rebuilds of objects depending on offset.h after
configuration changes but it forces offset.h to be rebuilt when CONFIG_SMP is
toggled.

For example:
--- Makefile.old        Thu May 25 19:05:08 2000
+++ Makefile    Thu May 25 19:08:48 2000
@@ -18,7 +18,7 @@
 offset.h: offset.s
        sed -n '/^@@@/s///p' $^ >$@
 
-offset.s: offset.c
+offset.s: offset.c $(TOPDIR)/.config
 
 clean:
        rm -f offset.[hs] $(TARGET).new                                         

-- 
Regards,
Harald

Re: CVS Update@oss.sgi.com: linux

[Ulf Carlsson]

On Thu, 25 May 2000, Harald Koerfgen wrote:

> 
> On 24-May-00 Ralf Baechle wrote:
> [offset.h]
> 
> > A good solution is important now that we have SMP.  Toggling CONFIG_SMP
> > affects offset.h and not for all variations of make invocations we
> > actually have the guarantee that offset.h is being rebuilt before using
> > it.
> 
> What about making offset.h to depend on $(TOPDIR)/.config?
> 
> This may cause unneccessary rebuilds of objects depending on offset.h after
> configuration changes but it forces offset.h to be rebuilt when CONFIG_SMP is
> toggled.

Would you mind removing the include/asm-$(ARCH)/offset.h from the CVS
repository, I get conflicts and stuff when I update.  I don't see why we need
to have a dummy file there.

Ulf

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Thu, May 25, 2000 at 10:19:40AM -0700, Ulf Carlsson wrote:

> > On 24-May-00 Ralf Baechle wrote:
> > [offset.h]
> > 
> > > A good solution is important now that we have SMP.  Toggling CONFIG_SMP
> > > affects offset.h and not for all variations of make invocations we
> > > actually have the guarantee that offset.h is being rebuilt before using
> > > it.
> > 
> > What about making offset.h to depend on $(TOPDIR)/.config?
> > 
> > This may cause unneccessary rebuilds of objects depending on offset.h after
> > configuration changes but it forces offset.h to be rebuilt when CONFIG_SMP is
> > toggled.
> 
> Would you mind removing the include/asm-$(ARCH)/offset.h from the CVS
> repository, I get conflicts and stuff when I update.  I don't see why we need
> to have a dummy file there.

Conceptually I don't like that either.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Ulf Carlsson]

> > Would you mind removing the include/asm-$(ARCH)/offset.h from the CVS
> > repository, I get conflicts and stuff when I update.  I don't see why we
> > need to have a dummy file there.
> 
> Conceptually I don't like that either.

I think my solution that I submitted yesterday was pretty good.  If add a rule
that removes include/asm-$(ARCH)/offset.h when you make clean we will be just
fine.  You'll have to make clean when you toggle between SMP and UP, but I
think we can live with that.

Ulf

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Thu, May 25, 2000 at 11:02:52AM -0700, Ulf Carlsson wrote:

> > > Would you mind removing the include/asm-$(ARCH)/offset.h from the CVS
> > > repository, I get conflicts and stuff when I update.  I don't see why we
> > > need to have a dummy file there.
> > 
> > Conceptually I don't like that either.
> 
> I think my solution that I submitted yesterday was pretty good.  If add a rule
> that removes include/asm-$(ARCH)/offset.h when you make clean we will be just
> fine.  You'll have to make clean when you toggle between SMP and UP, but I
> think we can live with that.

The recent change of __SMP__ to CONFIG_SMP almost everywhere in the kernel
was intended to avoid just that.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Tue, Jul 04, 2000 at 07:27:53PM +0200, Harald Koerfgen wrote:

> > Log message:
> >       We have to clobber ``hi'' and ``lo'' in __udelay.  Nasty bug.
> 
> Unfortunately my compilers don't like it.
> 
> mipsel-linux-gcc: egcs-2.90.29 980515 (egcs-1.0.3 release) (rpm from oss):
> 
> timer.c: In function `sys_nanosleep':
> timer.c:848: fixed or forbidden register was spilled.
> This may be due to a compiler bug or to impossible asm
> statements or clauses.

I've commited a fix for this.  It only tackles the __udelay() functions
for mips and mips64 but not the other multu instruction in the
DECstation HZ_TO_STD function.  Can you take a look at this one?

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Harald Koerfgen]

On 04-Jul-00 Ralf Baechle wrote:
> I've commited a fix for this.  It only tackles the __udelay() functions
> for mips and mips64 but not the other multu instruction in the
> DECstation HZ_TO_STD function.  Can you take a look at this one?

Done.

-- 
Regards,
Harald

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Wed, Aug 23, 2000 at 10:23:50AM -0700, Kanoj Sarcar wrote:

> Log message:
> 	Make prom_printf() functional on IP27s. And prom_printf() is not an
> 	init function, it needs to be around during regular system usage.

On my system after the first TLB flush all PROM functions are no longer
usable since the function pointer point to mapped space.  Similar for
other ARC machines.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Kanoj Sarcar]

> 
> On Wed, Aug 23, 2000 at 10:23:50AM -0700, Kanoj Sarcar wrote:
> 
> > Log message:
> > 	Make prom_printf() functional on IP27s. And prom_printf() is not an
> > 	init function, it needs to be around during regular system usage.
> 
> On my system after the first TLB flush all PROM functions are no longer
> usable since the function pointer point to mapped space.  Similar for
> other ARC machines.
> 
>   Ralf
> 

I can see how the IP27 can have access to prom functions after init.
Not sure how arc behaves on other machines, but I guess if you really
wanted to use arc prom functions after init, you could take steps to
ensure that ...

Kanoj

Re: CVS Update@oss.sgi.com: linux

[Kanoj Sarcar]

> 
> On Wed, Aug 23, 2000 at 10:23:50AM -0700, Kanoj Sarcar wrote:
> 
> > Log message:
> > 	Make prom_printf() functional on IP27s. And prom_printf() is not an
> > 	init function, it needs to be around during regular system usage.
> 
> On my system after the first TLB flush all PROM functions are no longer
> usable since the function pointer point to mapped space.  Similar for
> other ARC machines.
> 
>   Ralf
> 

I can see how the IP27 can have access to prom functions after init.
Not sure how arc behaves on other machines, but I guess if you really
wanted to use arc prom functions after init, you could take steps to
ensure that ...

Kanoj

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Wed, Sep 06, 2000 at 04:36:29PM -0700, Kanoj Sarcar wrote:

> 	Compile fix: flush only L2 cache.

That's wrong, sysmips(FLUSH_CACHE) is supposed to flush all caches.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Kanoj Sarcar]

> 
> On Wed, Sep 06, 2000 at 04:36:29PM -0700, Kanoj Sarcar wrote:
> 
> > 	Compile fix: flush only L2 cache.
> 
> That's wrong, sysmips(FLUSH_CACHE) is supposed to flush all caches.
> 
>   Ralf
> 

The act of flushing the L2 cache, should include flushing the L1
cache, whether done by software or processor provided primitives, 
to guarantee the inclusion principle.

Notwithstanding, feel free to add in a call to flush_cache_l1()
(and I don't know whether you want to flush the i and d caches
both, or just one), making sure there are no compile breakages.
(the breakage that I fixed was due to the fact that there is no
__flush_cache_all for mips64).

Kanoj

Re: CVS Update@oss.sgi.com: linux

[Kanoj Sarcar]

> 
> On Wed, Sep 06, 2000 at 04:36:29PM -0700, Kanoj Sarcar wrote:
> 
> > 	Compile fix: flush only L2 cache.
> 
> That's wrong, sysmips(FLUSH_CACHE) is supposed to flush all caches.
> 
>   Ralf
> 

The act of flushing the L2 cache, should include flushing the L1
cache, whether done by software or processor provided primitives, 
to guarantee the inclusion principle.

Notwithstanding, feel free to add in a call to flush_cache_l1()
(and I don't know whether you want to flush the i and d caches
both, or just one), making sure there are no compile breakages.
(the breakage that I fixed was due to the fact that there is no
__flush_cache_all for mips64).

Kanoj

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Wed, Sep 06, 2000 at 04:51:19PM -0700, Kanoj Sarcar wrote:

> The act of flushing the L2 cache, should include flushing the L1
> cache, whether done by software or processor provided primitives, 
> to guarantee the inclusion principle.

The inclusion principle is not true for all processor types.

> Notwithstanding, feel free to add in a call to flush_cache_l1()
> (and I don't know whether you want to flush the i and d caches
> both, or just one), making sure there are no compile breakages.
> (the breakage that I fixed was due to the fact that there is no
> __flush_cache_all for mips64).

Sorry, that line leaked in from my private tree.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Kanoj Sarcar]

> 
> On Wed, Sep 06, 2000 at 04:51:19PM -0700, Kanoj Sarcar wrote:
> 
> > The act of flushing the L2 cache, should include flushing the L1
> > cache, whether done by software or processor provided primitives, 
> > to guarantee the inclusion principle.
> 
> The inclusion principle is not true for all processor types.

Which processor is supported out of the mips64 tree that does
not obey the inclusion principle?

Kanoj

Re: CVS Update@oss.sgi.com: linux

[Kanoj Sarcar]

> 
> On Wed, Sep 06, 2000 at 04:51:19PM -0700, Kanoj Sarcar wrote:
> 
> > The act of flushing the L2 cache, should include flushing the L1
> > cache, whether done by software or processor provided primitives, 
> > to guarantee the inclusion principle.
> 
> The inclusion principle is not true for all processor types.

Which processor is supported out of the mips64 tree that does
not obey the inclusion principle?

Kanoj

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Wed, Sep 06, 2000 at 05:05:18PM -0700, Kanoj Sarcar wrote:

> > On Wed, Sep 06, 2000 at 04:51:19PM -0700, Kanoj Sarcar wrote:
> > 
> > > The act of flushing the L2 cache, should include flushing the L1
> > > cache, whether done by software or processor provided primitives, 
> > > to guarantee the inclusion principle.
> > 
> > The inclusion principle is not true for all processor types.
> 
> Which processor is supported out of the mips64 tree that does
> not obey the inclusion principle?

The R4600SC and R5000SC IP22.  RM7000 (patches pending) and probably most
future MIPS CPUs.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Sat, Nov 18, 2000 at 06:06:39PM +0100, Harald Koerfgen wrote:

> On 18-Nov-00 Ralf Baechle wrote:
> > CVSROOT:      /home/pub/cvs
> > Module name:  linux
> > Changes by:   ralf@oss.sgi.com        00/11/18 05:22:32
> > 
> > Modified files:
> >       Documentation  : Configure.help 
> >       arch/mips      : config.in 
> >       arch/mips/mm   : r4xx0.c 
> > 
> > Log message:
> >       New configuration option CONFIG_MIPS_UNCACHED.  Not yet selectable due
> >       to the manuals documenting ll/sc operation as undefined for uncached
> >       memory.
> 
> Wouldn't it make sense then to disable CONFIG_CPU_HAS_LLSC as well?

I'm waiting for authoritative answer from silicon guys before I deciede.
In the past I ran kernel entirely uncached and they seemed to work even
though the documentation made me assume the opposite.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Justin Carlson]

On Sat, 18 Nov 2000, Ralf Baechle wrote:
> > Log message:
> >       New configuration option CONFIG_MIPS_UNCACHED.  Not yet selectable due
> >       to the manuals documenting ll/sc operation as undefined for uncached
> >       memory.
> 
> > Wouldn't it make sense then to disable CONFIG_CPU_HAS_LLSC as well?
> 
> I'm waiting for authoritative answer from silicon guys before I deciede.
> In the past I ran kernel entirely uncached and they seemed to work even
> though the documentation made me assume the opposite.
> 

I'd be very, VERY surprised if ll-sc were guaranteed to work in uncached space,
for any implementation.  It certainly wouldn't in the SB1.

The easiest way to implement the ops on a cache-coherent system is to keep track
of whether or not you've lost a line in the cache between  the ll and the sc. 
Then, in the sc, you convert the line to dirty (if necessary), do the write,
and go on your merry way.  Or, if you've lost the line at some point between the
ll and the sc, you fail the sc.

I've never heard of anyone implementing it in a significantly different manner,
on MIPS or on Alpha.  To keep track of who's written what in an uncached space
would be nightmarish at best, in hardware. 

Doesn't mean someone hasn't done it, but it would certainly be news to me.

-Justin

Re: CVS Update@oss.sgi.com: linux

[Kevin D. Kissell]

> > > Log message:
> > >       New configuration option CONFIG_MIPS_UNCACHED.  Not yet
selectable due
> > >       to the manuals documenting ll/sc operation as undefined for
uncached
> > >       memory.
> >
> > Wouldn't it make sense then to disable CONFIG_CPU_HAS_LLSC as well?
>
> I'm waiting for authoritative answer from silicon guys before I deciede.
> In the past I ran kernel entirely uncached and they seemed to work even
> though the documentation made me assume the opposite.

We've been discussing this at MIPS, and it's a bit tricky.
LL/SC is almost guaranteed not to work uncached in a
multiprocessor configuration.  In the uniprocessor case,
it's not documented to work, but probably would in most
"natural" implementations.

The whole operation hinges on an invisible flip-flop which
is set by an LL and cleared by one of a set of events,
which include cache interventions by other CPUs,
memory ops by the same CPU, ERETs, etc.  So long
as the LL flop is set by the LL even uncached, and cleared
on ERET regardless of caching, the desired behaviour will
be obtained in an uncached uniprocessor.  But that's outside
the scope of the ISA spec and any MIPS ISA validation suites,
and a legal MIPS II/III/IV/V implementation could do otherwise.

            Regards,

            Kevin K.

Re: CVS Update@oss.sgi.com: linux

[Kevin D. Kissell]

> > > Log message:
> > >       New configuration option CONFIG_MIPS_UNCACHED.  Not yet
selectable due
> > >       to the manuals documenting ll/sc operation as undefined for
uncached
> > >       memory.
> >
> > Wouldn't it make sense then to disable CONFIG_CPU_HAS_LLSC as well?
>
> I'm waiting for authoritative answer from silicon guys before I deciede.
> In the past I ran kernel entirely uncached and they seemed to work even
> though the documentation made me assume the opposite.

We've been discussing this at MIPS, and it's a bit tricky.
LL/SC is almost guaranteed not to work uncached in a
multiprocessor configuration.  In the uniprocessor case,
it's not documented to work, but probably would in most
"natural" implementations.

The whole operation hinges on an invisible flip-flop which
is set by an LL and cleared by one of a set of events,
which include cache interventions by other CPUs,
memory ops by the same CPU, ERETs, etc.  So long
as the LL flop is set by the LL even uncached, and cleared
on ERET regardless of caching, the desired behaviour will
be obtained in an uncached uniprocessor.  But that's outside
the scope of the ISA spec and any MIPS ISA validation suites,
and a legal MIPS II/III/IV/V implementation could do otherwise.

            Regards,

            Kevin K.

Re: CVS Update@oss.sgi.com: linux

[Dominic Sweetman]

Ralf Baechle (ralf@oss.sgi.com) writes:

> > >       New configuration option CONFIG_MIPS_UNCACHED.  Not yet
> > >       selectable due to the manuals documenting ll/sc operation
> > >       as undefined for uncached memory.
> > 
> > Wouldn't it make sense then to disable CONFIG_CPU_HAS_LLSC as well?
> 
> I'm waiting for authoritative answer from silicon guys before I
> deciede.  In the past I ran kernel entirely uncached and they seemed
> to work even though the documentation made me assume the opposite.

ll/sc between CPUs certainly won't work for uncached accesses, since
they rely on the cache coherency protocols.

On a uniprocessor CPU the ll/sc link is typically broken on any
exception.  You'd have to try very hard to design the CPU so that it
would work any differently for cached and uncached accesses.

-- 
Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706200 / fax: +44 1223 706250 / home: +44 20 7226 0032
http://www.algor.co.uk

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Sun, Nov 19, 2000 at 03:16:33PM +0000, Dominic Sweetman wrote:

> ll/sc between CPUs certainly won't work for uncached accesses, since
> they rely on the cache coherency protocols.
> 
> On a uniprocessor CPU the ll/sc link is typically broken on any
> exception.  You'd have to try very hard to design the CPU so that it
> would work any differently for cached and uncached accesses.

Ok, so now CONFIG_MIPS_UNCACHED is only selectable for UP kernels.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Tue, Apr 10, 2001 at 03:42:48PM -0700, Kanoj Sarcar wrote:

> CVSROOT:	/home/pub/cvs
> Module name:	linux
> Changes by:	kanoj@oss.sgi.com	01/04/10 15:42:47
> 
> Modified files:
> 	drivers/char   : serial.c 
> 
> Log message:
> 	Fix the IP27 serial driver after the 2.4.3 merge. This is what you
> 	need in /etc/inittab: "7:2345:respawn:/sbin/getty ttyS0 DT9600".
> 	mingetty can also probably be made to work.

Mingetty starts ok but it's impossible to enter something.  This is caused
by CREAD being cleared on the tty.  I don't know why this happens; it
started in 2.4.3.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Kanoj Sarcar]

> 
> On Tue, Apr 10, 2001 at 03:42:48PM -0700, Kanoj Sarcar wrote:
> 
> > CVSROOT:	/home/pub/cvs
> > Module name:	linux
> > Changes by:	kanoj@oss.sgi.com	01/04/10 15:42:47
> > 
> > Modified files:
> > 	drivers/char   : serial.c 
> > 
> > Log message:
> > 	Fix the IP27 serial driver after the 2.4.3 merge. This is what you
> > 	need in /etc/inittab: "7:2345:respawn:/sbin/getty ttyS0 DT9600".
> > 	mingetty can also probably be made to work.
> 
> Mingetty starts ok but it's impossible to enter something.  This is caused
> by CREAD being cleared on the tty.  I don't know why this happens; it
> started in 2.4.3.
> 
>   Ralf
> 

receive_chars() was updated to look at ignore_mask ... if CREAD is not
set, around the time of opening via ioctls etc, it will not take inputs.
I haven't figured the details out, but I believe it is more of a *getty
config issue than anything else. 

Kanoj

Re: CVS Update@oss.sgi.com: linux

[Kanoj Sarcar]

> 
> On Tue, Apr 10, 2001 at 03:42:48PM -0700, Kanoj Sarcar wrote:
> 
> > CVSROOT:	/home/pub/cvs
> > Module name:	linux
> > Changes by:	kanoj@oss.sgi.com	01/04/10 15:42:47
> > 
> > Modified files:
> > 	drivers/char   : serial.c 
> > 
> > Log message:
> > 	Fix the IP27 serial driver after the 2.4.3 merge. This is what you
> > 	need in /etc/inittab: "7:2345:respawn:/sbin/getty ttyS0 DT9600".
> > 	mingetty can also probably be made to work.
> 
> Mingetty starts ok but it's impossible to enter something.  This is caused
> by CREAD being cleared on the tty.  I don't know why this happens; it
> started in 2.4.3.
> 
>   Ralf
> 

receive_chars() was updated to look at ignore_mask ... if CREAD is not
set, around the time of opening via ioctls etc, it will not take inputs.
I haven't figured the details out, but I believe it is more of a *getty
config issue than anything else. 

Kanoj

Re: CVS Update@oss.sgi.com: linux

[Quinn Jensen]

> 
> receive_chars() was updated to look at ignore_mask ... if CREAD is not
> set, around the time of opening via ioctls etc, it will not take inputs.
> I haven't figured the details out, but I believe it is more of a *getty
> config issue than anything else. 
> 
> Kanoj

Same thing happens when I bring up 2.4.3 straight
to a shell w/out any getty, as well.

Quinn

Re: CVS Update@oss.sgi.com: linux

[Quinn Jensen]

> 
> receive_chars() was updated to look at ignore_mask ... if CREAD is not
> set, around the time of opening via ioctls etc, it will not take inputs.
> I haven't figured the details out, but I believe it is more of a *getty
> config issue than anything else. 
> 
> Kanoj

Same thing happens when I bring up 2.4.3 straight
to a shell w/out any getty, as well.

Quinn

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Mon, Apr 16, 2001 at 11:43:44AM -0600, Quinn Jensen wrote:

> > receive_chars() was updated to look at ignore_mask ... if CREAD is not
> > set, around the time of opening via ioctls etc, it will not take inputs.
> > I haven't figured the details out, but I believe it is more of a *getty
> > config issue than anything else. 

> Same thing happens when I bring up 2.4.3 straight
> to a shell w/out any getty, as well.

Known problem on other architectures also.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Wed, Oct 03, 2001 at 01:02:56PM +0200, Maciej W. Rozycki wrote:

> > Modified files:
> > 	arch/mips/kernel: scall_o32.S sysmips.c 
> > 
> > Log message:
> > 	Barf.
> 
>  The new mips_atomic_set() doesn't mask interrupts in the non-ll/sc case. 
> Thus it may fail to keep coherency.  Is it intentional? 

Yes.  Assuming do_page_fault did it's job successfully the address which
has been passed as argument to sysmips() is now writable and thus we
won't take any pagefaults.

There are two remaining failure scenarios which probably are't very
interesting for practical usage.  It's when an interrupt is accessing
the same address.  This could be fixed by disabling interrupts.
The other case is missaligned words.

>  Also the bad_stack exit point for the ll/sc case looks suspicient to me.

Indeed, the symbol deserves a better name.  Cut'n'paste happens ;-)

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Jun Sun]

Ralf Baechle wrote:
> 
> On Wed, Oct 03, 2001 at 01:02:56PM +0200, Maciej W. Rozycki wrote:
> 
> > > Modified files:
> > >     arch/mips/kernel: scall_o32.S sysmips.c
> > >
> > > Log message:
> > >     Barf.
> >
> >  The new mips_atomic_set() doesn't mask interrupts in the non-ll/sc case.
> > Thus it may fail to keep coherency.  Is it intentional?
> 
> Yes.  Assuming do_page_fault did it's job successfully the address which
> has been passed as argument to sysmips() is now writable and thus we
> won't take any pagefaults.
> 
> There are two remaining failure scenarios which probably are't very
> interesting for practical usage.  It's when an interrupt is accessing
> the same address.  This could be fixed by disabling interrupts.
> The other case is missaligned words.
> 

And a third one - when you enable kernel preemption with the preemptable
kernel patch. :-)


Jun

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Wed, Oct 03, 2001 at 02:13:30PM -0700, Jun Sun wrote:

> And a third one - when you enable kernel preemption with the preemptable
> kernel patch. :-)

Other people's problem.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Florian Lohoff]

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

On Mon, Nov 05, 2001 at 04:55:33PM -0800, Ralf Baechle wrote:
> CVSROOT:	/home/pub/cvs
> Module name:	linux
> Changes by:	ralf@oss.sgi.com	01/11/05 16:55:33
[...]
> Log message:
> 	Merge with Linux 2.1.13.
 
I felt we are going back to stone age ;9

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Sun, Nov 18, 2001 at 11:10:52AM +0100, Kevin D. Kissell wrote:

> > Did I miss something?
> 
> Like the possibility that there are more MIPS-based
> Laserjets than MIPS-based workstations in the world?
> 
> Interesting platform, though.  Consider the possibilities
> of a hardcopy-only X display...  ;-)

Don't forget the possibilities of recycling your laserjet with network card
and serial interface as a dialup router and firewall with a manipulation-
proof logging device ;-)

  Ralf

RE: CVS Update@oss.sgi.com: linux

[Matthew Dharm]

Hrm... I wonder if you could make the fuser overheat to the point
where the paper "log" burst into flames, thereby destroying it.... :)

Matt

--
Matthew D. Dharm                            Senior Software Designer
Momentum Computer Inc.                      1815 Aston Ave.  Suite 107
(760) 431-8663 X-115                        Carlsbad, CA 92008-7310
Momentum Works For You                      www.momenco.com

> -----Original Message-----
> From: owner-linux-mips@oss.sgi.com
> [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Ralf Baechle
> Sent: Wednesday, November 21, 2001 3:25 PM
> To: Kevin D. Kissell
> Cc: Jan-Benedict Glaw; linux-mips@oss.sgi.com
> Subject: Re: CVS Update@oss.sgi.com: linux
>
>
> On Sun, Nov 18, 2001 at 11:10:52AM +0100, Kevin D. Kissell wrote:
>
> > > Did I miss something?
> >
> > Like the possibility that there are more MIPS-based
> > Laserjets than MIPS-based workstations in the world?
> >
> > Interesting platform, though.  Consider the possibilities
> > of a hardcopy-only X display...  ;-)
>
> Don't forget the possibilities of recycling your laserjet
> with network card
> and serial interface as a dialup router and firewall with a
> manipulation-
> proof logging device ;-)
>
>   Ralf
>

RE: CVS Update@oss.sgi.com: linux

[Matthew Dharm]

Hrm... I wonder if you could make the fuser overheat to the point
where the paper "log" burst into flames, thereby destroying it.... :)

Matt

--
Matthew D. Dharm                            Senior Software Designer
Momentum Computer Inc.                      1815 Aston Ave.  Suite 107
(760) 431-8663 X-115                        Carlsbad, CA 92008-7310
Momentum Works For You                      www.momenco.com

> -----Original Message-----
> From: owner-linux-mips@oss.sgi.com
> [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Ralf Baechle
> Sent: Wednesday, November 21, 2001 3:25 PM
> To: Kevin D. Kissell
> Cc: Jan-Benedict Glaw; linux-mips@oss.sgi.com
> Subject: Re: CVS Update@oss.sgi.com: linux
>
>
> On Sun, Nov 18, 2001 at 11:10:52AM +0100, Kevin D. Kissell wrote:
>
> > > Did I miss something?
> >
> > Like the possibility that there are more MIPS-based
> > Laserjets than MIPS-based workstations in the world?
> >
> > Interesting platform, though.  Consider the possibilities
> > of a hardcopy-only X display...  ;-)
>
> Don't forget the possibilities of recycling your laserjet
> with network card
> and serial interface as a dialup router and firewall with a
> manipulation-
> proof logging device ;-)
>
>   Ralf
>

Re: CVS Update@oss.sgi.com: linux

[Jan-Benedict Glaw]

On Thu, 2001-11-22 10:25:11 +1100, Ralf Baechle <ralf@oss.sgi.com>
wrote in message <20011122102511.B24183@dea.linux-mips.net>:
> On Sun, Nov 18, 2001 at 11:10:52AM +0100, Kevin D. Kissell wrote:
> 
> > > Did I miss something?
> > 
> > Like the possibility that there are more MIPS-based
> > Laserjets than MIPS-based workstations in the world?
> > 
> > Interesting platform, though.  Consider the possibilities
> > of a hardcopy-only X display...  ;-)
> 
> Don't forget the possibilities of recycling your laserjet with network card
> and serial interface as a dialup router and firewall with a manipulation-
> proof logging device ;-)

Well, here is a LP LJ 4+ (7 jears old...) flyin' around, and it
doesn't seem to contain a MIPS CPU. Only a i960 and a custom HP
processor is inside...

Well, which models actually *are* fine to run Linux on them, and
last question - do they keep printing while running linux? I don't
think so...

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	http://lug-owl.de/~jbglaw/software/snapshot2cvs/

Re: CVS Update@oss.sgi.com: linux

[Geert Uytterhoeven]

On Thu, 22 Nov 2001, Jan-Benedict Glaw wrote:
> On Thu, 2001-11-22 10:25:11 +1100, Ralf Baechle <ralf@oss.sgi.com>
> wrote in message <20011122102511.B24183@dea.linux-mips.net>:
> > On Sun, Nov 18, 2001 at 11:10:52AM +0100, Kevin D. Kissell wrote:
> > 
> > > > Did I miss something?
> > > 
> > > Like the possibility that there are more MIPS-based
> > > Laserjets than MIPS-based workstations in the world?
> > > 
> > > Interesting platform, though.  Consider the possibilities
> > > of a hardcopy-only X display...  ;-)
> > 
> > Don't forget the possibilities of recycling your laserjet with network card
> > and serial interface as a dialup router and firewall with a manipulation-
> > proof logging device ;-)
> 
> Well, here is a LP LJ 4+ (7 jears old...) flyin' around, and it
> doesn't seem to contain a MIPS CPU. Only a i960 and a custom HP
> processor is inside...

uClinux runs on various i960 incarnations.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Tue, Dec 18, 2001 at 11:23:32AM +0100, Geert Uytterhoeven wrote:

> > Log message:
> > 	Rewrite ffz().  Now compiles into code without any branches.
> 
> Depending on your compiler. Gcc seems to be smarter than GreenHills here :-)

I'd rather call this piece of code to be written around the compiler.
Credits for this nice piece of code btw go to Carsten of MIPS who used
this in the Atlas code where I discovered it two days ago.

The old variant of this routine came from the Origin code and produces
60% longer code with ~ 5 branches.  Probably wrapped around the SGI
compiler.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Sun, Feb 03, 2002 at 07:18:01PM +0100, Maciej W. Rozycki wrote:

> > Log message:
> > 	i8259.c assumes that i8259 are interrupt 0 to 15.  Change DDB5476
> > 	code accordingly.
> 
>  Hmm, the assumption might be justifiable for the i386 only?  Shouldn't
> i8259.c be fixed instead? 

These are the ISA interrupts; many drivers make assumptions about the
interrupts numbers, so we can't really change the numbers anyway.  For
any non-ISA interrupt it's number can be choosen freely.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On Sun, 3 Feb 2002, Ralf Baechle wrote:

> >  Hmm, the assumption might be justifiable for the i386 only?  Shouldn't
> > i8259.c be fixed instead? 
> 
> These are the ISA interrupts; many drivers make assumptions about the
> interrupts numbers, so we can't really change the numbers anyway.  For
> any non-ISA interrupt it's number can be choosen freely.

 I don't think such assumptions are sane even for the i386 -- an I/O APIC
system is free to route ISA interrupts to whichever I/O APIC inputs are
available, not necessarily the low 16.  The Intel MP Spec explicitly
allows such a setup -- ISA interrupts are only tied in default
configurations, which are rarely used (probably not at all these days). 

 Anyway, only the drivers that read an IRQ number from jumpers or Flash
memory need to be checked, and these are a minority (3Com Ethernet cards
and possibly very few others).  These that do probing (with probe_irq) or
simply take the number from an option will work automatically. 

 While I agree for 2.4 it might be not the best idea to do such changes,
for 2.5 it's worth considering, isn't it?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@oss.sgi.com: linux

[Jun Sun]

"Maciej W. Rozycki" wrote:
> 
> On Sun, 3 Feb 2002, Ralf Baechle wrote:
> 
> > >  Hmm, the assumption might be justifiable for the i386 only?  Shouldn't
> > > i8259.c be fixed instead?
> >
> > These are the ISA interrupts; many drivers make assumptions about the
> > interrupts numbers, so we can't really change the numbers anyway.  For
> > any non-ISA interrupt it's number can be choosen freely.
> 
>  I don't think such assumptions are sane even for the i386 -- an I/O APIC
> system is free to route ISA interrupts to whichever I/O APIC inputs are
> available, not necessarily the low 16.  The Intel MP Spec explicitly
> allows such a setup -- ISA interrupts are only tied in default
> configurations, which are rarely used (probably not at all these days).
> 
>  Anyway, only the drivers that read an IRQ number from jumpers or Flash
> memory need to be checked, and these are a minority (3Com Ethernet cards
> and possibly very few others).  These that do probing (with probe_irq) or
> simply take the number from an option will work automatically.
> 
>  While I agree for 2.4 it might be not the best idea to do such changes,
> for 2.5 it's worth considering, isn't it?
> 

This patch is from me.  It merely reflects a change of the irq base mapping
from 0x20 to 0x0.  I think someone did this change for Malta board.

A better solution is to have init_i8259_irqs() take an argument that is the
base IRQ number, like many other irq controller code do.  This way it is a
board level decision as what block of IRQs i8259 should use.

Jun

Re: CVS Update@oss.sgi.com: linux

[Guido Guenther]

On Sun, Jun 30, 2002 at 04:57:53AM -0700, Ralf Baechle wrote:
> CVSROOT:	/home/pub/cvs
> Module name:	linux
> Changes by:	ralf@oss.sgi.com	02/06/30 04:57:53
> 
> Modified files:
> 	drivers/char   : Tag: linux_2_4 Config.in 
> 
> Log message:
> 	Delete duplicate and braindead code for CONFIG_INDYDOG.
You killed the wrong one:
 http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.2/1209.html
 -- Guido

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Thu, Aug 15, 2002 at 09:33:40PM +0200, Jan-Benedict Glaw wrote:

> > 	arch/mips/boot : Tag: linux_2_4 elf2ecoff.c 
> > 
> > Log message:
> > 	Run through indent.  Convert from K&R C to ANSI.  Further crapectomy.
> 
> Only a notice: is by now known what elf2ecoff broke? As an effect, I see
> that modern (TM) elf2ecoffs fail to produce an loadable kernel for my
> indy (which boots fine with ELF, too).
> 
> However, it could also be a problem with changes addresses or so
> somewhere else (eg. ./linux/arch/mips/Makefile)...

Could you try older versions of the elf2ecoff utility from CVS to see
if that is making a difference?

  Ralf

PS: Please obey the reply-to header of linux-cvs postings.  This is not
    a discussion list and I plan to configure the list to send anything
    that isn't a CVS notification to /dev/null in the future.

Re: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On Thu, 15 Aug 2002, Ralf Baechle wrote:

> PS: Please obey the reply-to header of linux-cvs postings.  This is not
>     a discussion list and I plan to configure the list to send anything
>     that isn't a CVS notification to /dev/null in the future.

 Well, a bounce would likely be a friendlier choice... 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On Mon, 12 Aug 2002, Ralf Baechle wrote:

> Modified files:
> 	arch/mips      : config-shared.in defconfig defconfig-decstation 
> 	                 defconfig-ip22 defconfig-nino defconfig-osprey 
> 	                 defconfig-sb1250-swarm defconfig-sead 
> 	arch/mips64    : defconfig-ip22 defconfig-sb1250-swarm 
> 	                 defconfig-sead 
> 
> Log message:
> 	Make CONFIG_IDE selectable independant of the bus type.

 Hmm, what's the intent of the change?  IDE, or more properly ATA, was
originally an ISA-only device and is still only available as ISA-style
implementations, AFAIK.  I'd prefer it to be available only if any of
CONFIG_ISA, CONFIG_EISA, CONFIG_PCI (unsure about CONFIG_MCA) is set.

 That said, the place for such decisions seems to be inappropriate
currently.  It'd be much more elegant just to source all relevant drivers,
net, etc. Config.in scripts unconditionally and make global enable/disable
decisions at the top of the relevant script, like e.g. 
drivers/message/i2o/Config.in already does. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@oss.sgi.com: linux

[Alan Cox]

On Mon, 2002-08-19 at 13:35, Maciej W. Rozycki wrote:
>  Hmm, what's the intent of the change?  IDE, or more properly ATA, was
> originally an ISA-only device and is still only available as ISA-style
> implementations, AFAIK.  I'd prefer it to be available only if any of
> CONFIG_ISA, CONFIG_EISA, CONFIG_PCI (unsure about CONFIG_MCA) is set.

We support ATA devices attached to arbitary busses. The newest ATA code
supports arbitary mmio/pio addressing mechanisms. You don't need ISA or
an ISA like bus.

Re: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On 19 Aug 2002, Alan Cox wrote:

> We support ATA devices attached to arbitary busses. The newest ATA code
> supports arbitary mmio/pio addressing mechanisms. You don't need ISA or
> an ISA like bus.

 Hmm, does such hardware already exist?  I don't think it's reasonable to
make some code available to a user in a configuration that will never make
use of it.  E.g. a plain TURBOchannel box (or one with no I/O bus) won't
ever see a native ATA device (SCSI to ATA bridges obviously don't count). 
I'll check if the code builds at all. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Mon, Aug 19, 2002 at 02:35:19PM +0200, Maciej W. Rozycki wrote:

> > Modified files:
> > 	arch/mips      : config-shared.in defconfig defconfig-decstation 
> > 	                 defconfig-ip22 defconfig-nino defconfig-osprey 
> > 	                 defconfig-sb1250-swarm defconfig-sead 
> > 	arch/mips64    : defconfig-ip22 defconfig-sb1250-swarm 
> > 	                 defconfig-sead 
> > 
> > Log message:
> > 	Make CONFIG_IDE selectable independant of the bus type.
> 
>  Hmm, what's the intent of the change?  IDE, or more properly ATA, was
> originally an ISA-only device and is still only available as ISA-style
> implementations, AFAIK.  I'd prefer it to be available only if any of
> CONFIG_ISA, CONFIG_EISA, CONFIG_PCI (unsure about CONFIG_MCA) is set.
> 
>  That said, the place for such decisions seems to be inappropriate
> currently.  It'd be much more elegant just to source all relevant drivers,
> net, etc. Config.in scripts unconditionally and make global enable/disable
> decisions at the top of the relevant script, like e.g. 
> drivers/message/i2o/Config.in already does. 

Even before the changes Alan mentioned we had a bunch of machines like the
SWARM which had PCI but it's PIO IDE adapter wasn't living on the PCI bus.
So disabling PCI on that machine would disable IDE also.  Other machines
had IDE on PCMCIA with the PCMCIA bridge not hanging off an (E)ISA or PCI
bridge.  Basically I could have changed that if statement into an
increasingly obscure and braindamagedly complex if statement.

  Ralf

Re: CVS Update@oss.sgi.com: linux

[Alan Cox]

On Mon, 2002-08-19 at 14:22, Maciej W. Rozycki wrote:
>  Hmm, does such hardware already exist?  I don't think it's reasonable to
> make some code available to a user in a configuration that will never make
> use of it.  E.g. a plain TURBOchannel box (or one with no I/O bus) won't
> ever see a native ATA device (SCSI to ATA bridges obviously don't count). 
> I'll check if the code builds at all. 

Sure. There are embedded devices with onboard IDE controller logic. I
don't know about in mipsdom but certainly elsewhere.

I'm not aware of turdochannel IDE but there is a homebrew QBUS IDE
project

Re: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On Mon, 19 Aug 2002, Ralf Baechle wrote:

> So disabling PCI on that machine would disable IDE also.  Other machines
> had IDE on PCMCIA with the PCMCIA bridge not hanging off an (E)ISA or PCI
> bridge.  Basically I could have changed that if statement into an
> increasingly obscure and braindamagedly complex if statement.

 Well, that would be of questional benefit, indeed.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@oss.sgi.com: linux

[Jan-Benedict Glaw]

On Fri, 2002-08-23 02:50:00 -0700, Maciej W. Rozycki <macro@oss.sgi.com>
wrote in message <200208230950.g7N9o0fq016617@oss.sgi.com>:
> CVSROOT:	/oss/CVS/cvs
> Module name:	linux
> Changes by:	macro@oss.sgi.com	02/08/23 02:50:00
> 
> Modified files:
> 	drivers/scsi   : Tag: linux_2_4 dec_esp.c 
> 	include/asm-mips: Tag: linux_2_4 scatterlist.h 
> 	include/asm-mips64: Tag: linux_2_4 scatterlist.h 
> 
> Log message:
> 	More mmu_sglist and dec_esp.c fixes, sigh...

Cool. Fixed now. I had send a similar patch around about a week or two
ago on whitch Karsten and I had worked on. Nobody responded, nobody
checked it in... Not to talk about the R4600 issues...

MfG, JBG

-- 
Jan-Benedict Glaw   .   jbglaw@lug-owl.de   .   +49-172-7608481
	 -- New APT-Proxy written in shell script --
	   http://lug-owl.de/~jbglaw/software/ap2/

-- Attached file included as plaintext by Ecartis --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9Zgq2Hb1edYOZ4bsRAhoEAKCRs8dxZSlradXTi2RPodBabHr9ewCgi/7Q
7N6mgModfQ78u+ljaRk52Bs=
=JA+S
-----END PGP SIGNATURE-----

Re: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On Fri, 23 Aug 2002, Jan-Benedict Glaw wrote:

> > Modified files:
> > 	drivers/scsi   : Tag: linux_2_4 dec_esp.c 
> > 	include/asm-mips: Tag: linux_2_4 scatterlist.h 
> > 	include/asm-mips64: Tag: linux_2_4 scatterlist.h 
> > 
> > Log message:
> > 	More mmu_sglist and dec_esp.c fixes, sigh...
> 
> Cool. Fixed now. I had send a similar patch around about a week or two
> ago on whitch Karsten and I had worked on. Nobody responded, nobody

 I've seen the report.  Since changes involved trivial string
substitutions and your patch worked for you I have considered it obvious
enough not to add any comments.  I apologize if you have found this
annoying. 

 I've done the changes a bit differently to keep the obsolete mmu_sglist
interface unchanged -- it was my fault it got changed by an accident. 

> checked it in... Not to talk about the R4600 issues...

 Hmm, haven't you got my suggestions?  I hope they were clear, at least
nobody complained.  If you'd like to test an ll/sc variant, I may try to
provide you some aid if needed.  Also, have you contacted IDT? 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +