Linux MIPS Architecture development
 help / color / mirror / Atom feed
* Re: About the changes in co_timer_ack() function of time.c.
From: Ralf Baechle @ 2007-10-30 12:35 UTC (permalink / raw)
  To: Kevin D. Kissell; +Cc: tnishioka, linux-mips
In-Reply-To: <003801c818c4$1cbe0150$8603a8c0@Ulysses>

On Sat, Oct 27, 2007 at 11:06:34AM -0700, Kevin D. Kissell wrote:

> The difference is that, in the case where we are *way* behind in interrupt
> processing, such that the Count value has gone beyond the to the next tick 
> interrupt value, the 2.6.10 code will only try to catch up by a single inteval,
> which may result in having to wait 4 billion cycles for the Count to wrap.
> The 2.6.23.1 version (a) repeats until the programmed Compare value is
> ahead of Count, and (b)  resamples the count register value each time 
> through the loop, which is important if other interrupts may be enabled
> while c0_timer_ack() is running, [...]

The code upto 2.6.23 uses IRQF_DISABLED (which used to be named SA_INTERRUPT
until July 2006) for the timer interrupt in timer_irqaction which is defined
in the generic time.c.

> [...] I could imagine that making a material difference in the presnece
> of "interrupt storms" from I/O devices.

I don't recall any reports of this sort of behaviour before tnishioka's.
This includes no hang reports about the R4000 read from c0_count ever -
because Linux will happen to just nicely tiptoe around the issue for all
real world configurations.

> If I wanted to be pendantic, I would argue that the 2.6.23 is still vulnerable
> to the Count register passing the Compare target between the "if" and the
> write_c0_compare(), and that it would be more airtight to code it more
> like:
>             expirelo = read_c0_count();
>             do {
>                 expirelo += cycles_per_jiffy;
>                 write_c0_compare(expirelo);
>             } while (((read_c0_count()) - expirelo < 0x7fffffff);
> 
> 
> It may well be that the initial value of expirelo should be derived
> from read_c0_compare() and not read_c0_count().  That would
> preserve synchronization of clock ticks against external wall-clock time,
> though the removal of the "slop" would mean that there would be
> slighly more interrupt service events per unit of real time.

I think it should be based on the last compare value.  This is the only
way to ensure interrupts will use a precise timing.

> But I gave up tilting at these windmills a long, long time ago... ;o)

Your windmill has been fixed for 2.6.24.

Now available at your nearest LMO (TM) GIT Store!

The big change is that the new timer code now has a proper concept of
oneshot interrupt timers.  Which is what the compare interrupt really is
despite the continuously running counter.  So this is how the new event
programming code looks like:

static int mips_next_event(unsigned long delta,
                           struct clock_event_device *evt)
{
	unsigned int cnt;
	int res;

	cnt = read_c0_count();
	cnt += delta;
	write_c0_compare(cnt);

	return ((int)(read_c0_count() - cnt) > 0) ? -ETIME : 0;
}

The called will check for the error return and if so invoke the active
clockevent device's ->set_next_event method again with a new suitable
delta.

Qemu btw. can trigger the -ETIME case fairly easily.

But anyway, I don't object a patch to improve theoretical correctness.

  Ralf

^ permalink raw reply

* Re: 2.4.24-rc1 does not boot on SGI
From: Giuseppe Sacco @ 2007-10-30 11:41 UTC (permalink / raw)
  To: linux-mips
In-Reply-To: <Pine.SGI.4.60.0710300717080.2654@zeus.tetracon-eng.net>

Il giorno mar, 30/10/2007 alle 07.20 -0400, J. Scott Kasten ha scritto:
[...]
> You say the serial line does not work.  I'm running debian's 2.6.18 kernel 
> on my daily use box.  I had an urgent need to communicate with a serial 
> device and tried using my O2.  No dice.  I finally dug the laptop out of 
> the closet and took care of it that way.  It sounds like the generic 
> serial stuff was broken a ways back.

Using 2.6.18 debian kernel I hadn't any problem: the machine used to be
a faxserver with hylafax (using a modem via the serial port).

What kind of problem do you had with 2.6.18?

^ permalink raw reply

* Re: [IDE] Fix build bug
From: Denys Vlasenko @ 2007-10-30 11:34 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz
  Cc: Ralf Baechle, Andrew Morton, linux-kernel, linux-ide, linux-mips,
	Martijn Uffing
In-Reply-To: <200710252341.38902.bzolnier@gmail.com>

On Thursday 25 October 2007 22:41, Bartlomiej Zolnierkiewicz wrote:
> > -static const struct ide_port_info generic_chipsets[] __devinitdata = {
> > +static struct ide_port_info generic_chipsets[] __devinitdata = {
> >  	/*  0 */ DECLARE_GENERIC_PCI_DEV("Unknown",	0),
> >  
> >  	{	/* 1 */
> 
> I would prefer to not remove const from generic_chipsets[] so:
> 
> [PATCH] drivers/ide/pci/generic: fix build for CONFIG_HOTPLUG=n
> 
> It turns out that const and __{dev}initdata cannot be mixed currently
> and that generic IDE PCI host driver is also affected by the same issue:
> 
> On Thursday 25 October 2007, Ralf Baechle wrote:
> >   CC      drivers/ide/pci/generic.o
> > drivers/ide/pci/generic.c:52: error: __setup_str_ide_generic_all_on causes a
> > +section type conflict
> 
> [ Also reported by Martijn Uffing <mp3project@sarijopen.student.utwente.nl>. ]
> 
> This patch workarounds the problem in a bit hackish way but without
> removing const from generic_chipsets[] (it adds const to __setup() so
> __setup_str_ide_generic_all becomes const).

You wouldn't believe how much const data is not marked as const because
we don't have __constinitdata etc. Literally megabytes.
--
vda

^ permalink raw reply

* Re: 2.4.24-rc1 does not boot on SGI
From: J. Scott Kasten @ 2007-10-30 11:20 UTC (permalink / raw)
  To: Giuseppe Sacco; +Cc: Martin Michlmayr, linux-mips
In-Reply-To: <1193733706.7731.15.camel@scarafaggio>



On Tue, 30 Oct 2007, Giuseppe Sacco wrote:

> my config file for 2.6.23.1 from kernel.org is
> http://eppesuigoccas.homedns.org/~giuseppe/debian/sgi-mips-config-2.6.23.1-gs2.bz2
>
> currently open points:
>
> 1. serial line does not work
>

You say the serial line does not work.  I'm running debian's 2.6.18 kernel 
on my daily use box.  I had an urgent need to communicate with a serial 
device and tried using my O2.  No dice.  I finally dug the laptop out of 
the closet and took care of it that way.  It sounds like the generic 
serial stuff was broken a ways back.

-S-

^ permalink raw reply

* Re: 2.4.24-rc1 does not boot on SGI
From: Giuseppe Sacco @ 2007-10-30  9:27 UTC (permalink / raw)
  To: Martin Michlmayr; +Cc: linux-mips
In-Reply-To: <20071030090943.GB17714@deprecation.cyrius.com>

Il giorno mar, 30/10/2007 alle 10.09 +0100, Martin Michlmayr ha scritto:
> * Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org> [2007-10-30 09:41]:
> > 1. serial line does not work
> 
> What exactly is not working?  I see kernel messages but serial doesn't
> work when I reach user land.  Do you see the same?

Yes. I understood that the serial line is correctly setup at startup,
then when the serial8250 device is started, it scan all registered
drivers (including the "platform" one), it tries to assign the two uarts
registered from ip32-platform.c, but here it get lost because the first
line is correctly registered, but the second line overlap the first one.

What happens is that when registering the second uart, the serial device
look for an unused uart and it gets the one used by ttyS0. I think that
the device think the uart is free because our uarts are UPIO_MEM but
mapbase isn't used.

Beside this, there is an error in ip32-platform:uart8250_init() since
the two uart structures are initialised with the same
&mace->isa.serial1. (this has already been pointed out in a previous
message on this list.)

A solution would be to change the initialisation in
ip32-platform:uart8250_init() in order to use mapbase instead of
membase, but I don't know how to translate the two numbers to mapbase.
Infact, if you use mapbase, the serial device know how to translate it
to membase and will correctly find the uart as used.

Bye,
Giuseppe

^ permalink raw reply

* Unknown Synbol:__gp_disp
From: kaka @ 2007-10-30  9:15 UTC (permalink / raw)
  To: linux-mips, uclinux-dev, linux-fbdev-users
In-Reply-To: <eea8a9c90710300200wb39c64fuc0c6718bd7aeec48@mail.gmail.com>

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

Hi All,

While installing the driver by insmod cmd. i am getting the above error,
Unknown Synbol:__gp_disp,
I have added ``-fno-pic -mno-abicalls'' option in the make file as


$(BCM_OBJ_DIR)/%.o: %.c

@echo '$(CC) -c $(notdir $<)'

@$(CC) -fno-pic -mno-abicalls -MMD -c $(CFLAGS) $< -o $@



I tried by adding those symbols in the CFLAGS

CFLAGS += -fno-pic -mno-abicalls.

But it didn't help my cause.

Could anybody plz look in to the error and reply?

Thanks in advance


-- 
Thanks & Regards,
kaka

[-- Attachment #2: Type: text/html, Size: 766 bytes --]

^ permalink raw reply

* Re: 2.4.24-rc1 does not boot on SGI
From: Martin Michlmayr @ 2007-10-30  9:09 UTC (permalink / raw)
  To: Giuseppe Sacco; +Cc: linux-mips
In-Reply-To: <1193733706.7731.15.camel@scarafaggio>

* Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org> [2007-10-30 09:41]:
> 1. serial line does not work

What exactly is not working?  I see kernel messages but serial doesn't
work when I reach user land.  Do you see the same?
-- 
Martin Michlmayr
http://www.cyrius.com/

^ permalink raw reply

* Re: 2.4.24-rc1 does not boot on SGI
From: Martin Michlmayr @ 2007-10-30  9:09 UTC (permalink / raw)
  To: Giuseppe Sacco; +Cc: linux-mips
In-Reply-To: <20071030083106.GA16763@deprecation.cyrius.com>

* Martin Michlmayr <tbm@cyrius.com> [2007-10-30 09:31]:
> Adding 131064k swap on /dev/sda2.  Priority:-1 extents:1 across:131064k
> EXT3 FS on sda1, internal journal
> 
> and later:
> 
> gbefb: wait for vpixen_off timed out
> 
> and then I gave up and went to bed. ;-)

Okay, so I can login via SSH but there's still no "login" prompt on
the serial console.  echo foo > /dev/ttyS0 also doesn't work, but
printk()s are shown on the serial console (e.g. when I load a module).
Any ideas, Ralf?
-- 
Martin Michlmayr
http://www.cyrius.com/

^ permalink raw reply

* Unknown Synbol:__gp_disp
From: kaka @ 2007-10-30  9:00 UTC (permalink / raw)
  To: linux-mips, uclinux-dev, linux-fbdev-users

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

Hi All,

While installing the driver by insmod cmd. i am getting the above error,
Unknown Synbol:__gp_disp,
I have added ``-fno-pic -mno-abicalls'' option in the make file as


$(BCM_OBJ_DIR)/%.o: %.c

@echo '$(CC) -c $(notdir $<)'

@$(CC) -fno-pic -mno-abicalls -MMD -c $(CFLAGS) $< -o $@



I tried by adding those symbols in the CFLAGS

CFLAGS += -fno-pic -mno-abicalls.

But it didn't help my cause.

Could anybody plz look in to the error and reply?

Thanks in advance


-- 
Thanks & Regards,
kaka

[-- Attachment #2: Type: text/html, Size: 746 bytes --]

^ permalink raw reply

* Re: 2.4.24-rc1 does not boot on SGI
From: Giuseppe Sacco @ 2007-10-30  8:41 UTC (permalink / raw)
  To: Martin Michlmayr; +Cc: linux-mips
In-Reply-To: <20071030083106.GA16763@deprecation.cyrius.com>

Il giorno mar, 30/10/2007 alle 09.31 +0100, Martin Michlmayr ha scritto:
> * Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org> [2007-10-27 09:07]:
> > The new kernel once again does not boot on SGI O2. What happens is that
> > arcboot write its messages and nothing more is displayed on the screen.
> > The last message is "Starting ELF64 kernel". The previous running kernel
> > were 2.6.23 from linux-mips.org and 2.6.23.1 from kernel.org.
> 
> I can confirm that currnt git doesn't boot (no message on the serial
> console at all).  However, I'm curious to know whether 2.6.23 is
> working properly for you (and, if so, can you send me your .config).
[...]

my config file for 2.6.23.1 from kernel.org is
http://eppesuigoccas.homedns.org/~giuseppe/debian/sgi-mips-config-2.6.23.1-gs2.bz2

currently open points:

1. serial line does not work
2. cat /proc/self/cmdline ends in kernel oops
3. writing on USB block devices through a PCI-to-PCI does not work
4. XFS kernel module is missing 32bit ioctl and cannot talk with xfsdump
nor xfsrestore

I am currently investigating on 1. and 3.

^ permalink raw reply

* Re: 2.4.24-rc1 does not boot on SGI
From: Martin Michlmayr @ 2007-10-30  8:31 UTC (permalink / raw)
  To: Giuseppe Sacco; +Cc: linux-mips
In-Reply-To: <1193468825.7474.6.camel@scarafaggio>

* Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org> [2007-10-27 09:07]:
> The new kernel once again does not boot on SGI O2. What happens is that
> arcboot write its messages and nothing more is displayed on the screen.
> The last message is "Starting ELF64 kernel". The previous running kernel
> were 2.6.23 from linux-mips.org and 2.6.23.1 from kernel.org.

I can confirm that currnt git doesn't boot (no message on the serial
console at all).  However, I'm curious to know whether 2.6.23 is
working properly for you (and, if so, can you send me your .config).
For me, it stops after printing

Freeing unused kernel memory: 268k freed

but then I can still hear it doing something and after a minute or so
I see:

Adding 131064k swap on /dev/sda2.  Priority:-1 extents:1 across:131064k
EXT3 FS on sda1, internal journal

and later:

gbefb: wait for vpixen_off timed out

and then I gave up and went to bed. ;-)
-- 
Martin Michlmayr
http://www.cyrius.com/

^ permalink raw reply

* Re: [PATCH] IP22: Disable EARLY PRINTK, because it breaks serial console
From: Martin Michlmayr @ 2007-10-30  7:33 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: linux-mips, Thomas Bogendoerfer
In-Reply-To: <20070911104459.GB7624@alpha.franken.de>

* Thomas Bogendoerfer <tsbogend@alpha.franken.de> [2007-09-11 12:44]:
> Disable EARLY PRINTK, because it breaks serial console

Ralf, at the moment IP22 output stops after "Serial: IP22 Zilog driver
(1 chips).".  Can you put this patch in until there's a real fix?

Tested-by: Martin Michlmayr <tbm@cyrius.com>

> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> ---
>  arch/mips/Kconfig |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 3b807b4..1f0502d 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -334,7 +334,6 @@ config SGI_IP22
>  	select SWAP_IO_SPACE
>  	select SYS_HAS_CPU_R4X00
>  	select SYS_HAS_CPU_R5000
> -	select SYS_HAS_EARLY_PRINTK
>  	select SYS_SUPPORTS_32BIT_KERNEL
>  	select SYS_SUPPORTS_64BIT_KERNEL
>  	select SYS_SUPPORTS_BIG_ENDIAN
> -- 
> 1.4.4.4
> 
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessary a
> good idea.                                                [ RFC1925, 2.3 ]

-- 
Martin Michlmayr
http://www.cyrius.com/

^ permalink raw reply

* Re: Question related to Linux Kernel and MIPS
From: Ralf Baechle @ 2007-10-29 20:53 UTC (permalink / raw)
  To: Binod Roay; +Cc: linux-mips
In-Reply-To: <423926.37963.qm@web37907.mail.mud.yahoo.com>

On Sun, Oct 28, 2007 at 08:24:15AM -0700, Binod Roay wrote:

> Could I please know is it possible run the Linux
> Kernel on MIPS from KUSEG ?

You'd have to port UML to MIPS for something like this.

  Ralf

^ permalink raw reply

* Re: [PATCH] fix post-fence error
From: Sergei Shtylyov @ 2007-10-29 20:05 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: Roel Kluin, linux-mips
In-Reply-To: <20071029191807.GA14710@linux-mips.org>

Ralf Baechle wrote:

>>   I'm afraid this new patch is wrong...

> Indeed.  Thanks for proofreading, even if after the fact ...

    You were too quick with commit. :-)
    Could also convert all of this construct to a proper kernel style:

         for (i = 0; i < _IRIX_NSIG_BPW; i++)

>   Ralf

WBR, Sergei

^ permalink raw reply

* Re: [PATCH] sb1250-swarm_defconfig: Enable GenBus IDE
From: Ralf Baechle @ 2007-10-29 19:23 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: linux-mips
In-Reply-To: <Pine.LNX.4.64N.0710121641150.21684@blysk.ds.pg.gda.pl>

On Fri, Oct 12, 2007 at 04:46:56PM +0100, Maciej W. Rozycki wrote:

>  Enable the onboard GenBus IDE interface in the default configuration.

Indeed, that's sort of useful ;-)

> Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
> ---
>  I see no reason to keep it disabled; I think the onboard devices deserve 
> some automatic build-time testing -- at least ones for which drivers are 
> known to be in a reasonable shape.

It got disabled when some IDE maintainer went out of control and removed the
driver entirely.

>  As a side note, this configuration template has not been regenerated for 
> a long time and is thus severely outdated.  I am tempted to do this, 
> obviously setting any new options to my liking -- I'll send another patch 
> for it unless somebody objects.

Feel free.

  Ralf

^ permalink raw reply

* Re: [PATCH] fix post-fence error
From: Ralf Baechle @ 2007-10-29 19:18 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: Roel Kluin, linux-mips
In-Reply-To: <4725FDE5.70407@ru.mvista.com>

On Mon, Oct 29, 2007 at 06:36:05PM +0300, Sergei Shtylyov wrote:

>    I'm afraid this new patch is wrong...

Indeed.  Thanks for proofreading, even if after the fact ...

  Ralf

^ permalink raw reply

* Re: [PATCH 3/4] vmlinux.ld.S: correctly indent .data section
From: Ralf Baechle @ 2007-10-29 18:40 UTC (permalink / raw)
  To: Franck Bui-Huu; +Cc: linux-mips, macro
In-Reply-To: <1192741953-7040-4-git-send-email-fbuihuu@gmail.com>

On Thu, Oct 18, 2007 at 11:12:32PM +0200, Franck Bui-Huu wrote:

Thanks, applied.

  Ralf

^ permalink raw reply

* Re: [PATCH] c-r3k: Implement flush_cache_range()
From: Ralf Baechle @ 2007-10-29 18:36 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: linux-mips
In-Reply-To: <Pine.LNX.4.64N.0710171144410.28993@blysk.ds.pg.gda.pl>

On Wed, Oct 17, 2007 at 11:51:39AM +0100, Maciej W. Rozycki wrote:

>  Contrary to the belief of some, the R3000 and related processors did have 
> caches, both a data and an instruction cache.  Here is an implementation 
> of r3k_flush_cache_page(), which is the processor-specific back-end for 
> flush_cache_range(), done according to the spec in 
> Documentation/cachetlb.txt.
> 
>  While at it, remove an unused local function: get_phys_page(), do some 
> trivial formatting fixes and modernise debugging facilities.

Applied.

  Ralf

^ permalink raw reply

* Re: [PATCH] store sign-extend register values for PTRACE_GETREGS
From: Ralf Baechle @ 2007-10-29 18:31 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Atsushi Nemoto, linux-mips
In-Reply-To: <20071028195211.GA29200@caradoc.them.org>

On Sun, Oct 28, 2007 at 03:52:11PM -0400, Daniel Jacobowitz wrote:

> On Sun, Oct 28, 2007 at 07:34:21PM +0000, Ralf Baechle wrote:
> > On Fri, Oct 26, 2007 at 12:53:02AM +0900, Atsushi Nemoto wrote:
> > 
> > Daniel, do you see any debugger compatibility issues with this patch?
> 
> I don't think so; I'm pretty sure I wrote the code at fault here,
> and I can't remember any reason I would have deliberately made the
> registers unsigned.  Looking at the fix I think I just guessed
> wrong about the type used by __put_user.

Good.  So I just applied it.

  Ralf

^ permalink raw reply

* Re: [PATCH] cleanup tx39/tx49 setup code
From: Ralf Baechle @ 2007-10-29 18:21 UTC (permalink / raw)
  To: Atsushi Nemoto; +Cc: linux-mips
In-Reply-To: <20071024.231656.72707756.anemo@mba.ocn.ne.jp>

On Wed, Oct 24, 2007 at 11:16:56PM +0900, Atsushi Nemoto wrote:

> Remove some unnecessary codes, includes and files.

Queued for 2.6.25.  Thanks,

  Ralf

^ permalink raw reply

* Re: [PATCH][MIPS] remove unused mips_machtype
From: Ralf Baechle @ 2007-10-29 18:16 UTC (permalink / raw)
  To: Yoichi Yuasa; +Cc: linux-mips
In-Reply-To: <200710282311.l9SNBZ7S005135@po-mbox302.po.2iij.net>

On Mon, Oct 29, 2007 at 08:11:35AM +0900, Yoichi Yuasa wrote:

> > > Removed unused mips_machtype.
> > > These are only set though are not used.
> > 
> > I'm getting a large number of rejects on this patch.
> 
> Really? I have no problem to applly it on current git.

Hmm...  Guess my patch-o-matic jammed.  Just retried and applies perfectly.
Sorry.

Patch queued for 2.6.25 & thanks,

  Ralf

^ permalink raw reply

* Re: [PATCH] [MTX1 try 2] Register platform devices
From: Ralf Baechle @ 2007-10-29 18:08 UTC (permalink / raw)
  To: Florian Fainelli; +Cc: linux-mips
In-Reply-To: <200710231855.55605.florian.fainelli@telecomint.eu>

On Tue, Oct 23, 2007 at 06:55:55PM +0200, Florian Fainelli wrote:

> This patch separates the platform devices registration
> for the MTX-1 specific devices : GPIO leds and watchdog.

Thanks, applied.

  Ralf

^ permalink raw reply

* Re: [PATCH] MIPS: Add len and addr validation for MAP_FIXED mappings.
From: Ralf Baechle @ 2007-10-29 17:51 UTC (permalink / raw)
  To: David Daney; +Cc: linux-mips
In-Reply-To: <472427CC.4000406@avtrex.com>

On Sat, Oct 27, 2007 at 11:10:20PM -0700, David Daney wrote:

> mmap with MAP_FIXED was not validating the addr and len parameters.
> This leads to the failure of GCC's gcc.c-torture/execute/loop-2[fg].c
> testcases when using the o32 ABI on a 64 bit kernel.
> 
> These testcases try to mmap 65536 bytes at 0x7fff8000 and then access
> all the memory.  In 2.6.18 and 2.6.23.1 (and likely other versions as
> well) the kernel maps the requested memory, but since half of it is
> above 0x80000000 a SIGBUS is generated when it is accessed.
> 
> This patch moves the len validation above the MAP_FIXED processing so
> that it is always validated.  It also adds validation to the addr
> parameter for MAP_FIXED mappings.

Thanks, applied.

  Ralf

^ permalink raw reply

* Re: [PATCH] fix post-fence error
From: Sergei Shtylyov @ 2007-10-29 15:36 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: Roel Kluin, linux-mips
In-Reply-To: <20071029150233.GA4165@linux-mips.org>

Hello.

Ralf Baechle wrote:

>>Sergei Shtylyov wrote:

>>>   Could also add spaces between the operands and operators (like
>>>above/below), while at it...

>>like this?

> Thanks. I didn't like the magic numbers in the code so I went for below
> patch instead.

> Cheers,

>   Ralf

> From: Ralf Baechle <ralf@linux-mips.org>

> [MIPS] IRIX: Fix off-by-one error in signal compat code.

> Based on original patch by Roel Kluin <12o3l@tiscali.nl>.

> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

    I'm afraid this new patch is wrong...

> diff --git a/arch/mips/kernel/irixsig.c b/arch/mips/kernel/irixsig.c
> index a0a9105..5052f47 100644
> --- a/arch/mips/kernel/irixsig.c
> +++ b/arch/mips/kernel/irixsig.c
> @@ -24,8 +24,12 @@
>  
>  #define _BLOCKABLE (~(_S(SIGKILL) | _S(SIGSTOP)))
>  
> +#define _IRIX_NSIG		128
> +#define _IRIX_NSIG_BPW		BITS_PER_LONG
> +#define _IRIX_NSIG_WORDS	(_IRIX_NSIG / _IRIX_NSIG_BPW)
> +
>  typedef struct {
> -	unsigned long sig[4];
> +	unsigned long sig[_IRIX_NSIG_WORDS];
>  } irix_sigset_t;
>  
>  struct sigctx_irix5 {
> @@ -527,7 +531,7 @@ asmlinkage int irix_sigpoll_sys(unsigned long __user *set,
>  
>  		expire = schedule_timeout_interruptible(expire);
>  
> -		for (i=0; i<=4; i++)
> +		for (i=0; i < _IRIX_NSIG_BPW; i++)

    Did you mean _IRIX_NSIG_WORDS? :-/

>  			tmp |= (current->pending.signal.sig[i] & kset.sig[i]);
>  
>  		if (tmp)

WBR, Sergei

^ permalink raw reply

* Re: [PATCH] serial: fix au1xxx UART0 irq setup
From: Ralf Baechle @ 2007-10-29 15:28 UTC (permalink / raw)
  To: Jan Nikitenko; +Cc: linux-mips, linux-serial
In-Reply-To: <4720A11E.5060101@gmail.com>

On Thu, Oct 25, 2007 at 03:58:54PM +0200, Jan Nikitenko wrote:

> UART0 on Alchemy mips platforms (au1xxx) does not use real uart's hw
> irq, causing 'ttyS0: 1 input overrun(s)' kernel message with data loss,
> when more characters than uart's fifo size were to be received by the uart.
> 
> This problem can be experienced for example when uart0 is used as a
> serial console on au1550 and more than 16 characters are pasted from
> clipboard to the console.
> 
> The is_real_interrupt(irq) macro is defined in drivers/serial/8250.c as
> a check, if the irq number is other than zero.
> Because UART0 on au1xxx platforms uses irq number 0, the
> is_real_interrupt() check fails and serial8250_backup_timeout() is used
> instead of uart's hw irq.
> 
> The patch redefines the is_real_interrupt(irq) macro, as suggested in
> the comment above the macro definition in 8250.c, in the
> asm-mips/serial.h to be always true for CONFIG_SERIAL_8250_AU1X00.
> This allows the irq number 0 to be used as hw irq for the alchemy uart0
> and fixes the overrun problem.
> 
> Signed-off-by: Jan Nikitenko <jan.nikitenko@gmail.com>

So applied to all of lmo's -stable branches.

  Ralf

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox