* Re: PCI resource unavailable on mips
From: Jon Dufresne @ 2007-12-14 21:12 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-kernel, linux-mips
In-Reply-To: <20071214093945.GA25186@linux-mips.org>
> Odd. I knew the resource allocation stuff has it's issues for some
> non-trivial configuration but that one is a new one. Which makes me
> wonder if your platform runs the PCI code in probe-only mode where it
> will not actually assign resources but only inherit the whole PCI setup
> except interrupt routing from the firmware.
Hmm, I found more strange behavior with the bars that may or may not be
related. I wrote a function that does another sanity check. It does an
ioremap on one of the working bars, then reads one address for
correctness. This is just to confirm that iomem is working. This is what
the function looks like:
> void dump_mmio(struct pci_dev *dev)
> {
> unsigned long phys, size;
> struct resource *mem_region;
> void __iomem *mmio;
> u32 dword;
>
> phys = pci_resource_start(dev, 1);
> size = pci_resource_len(dev, 1);
>
> mem_region = request_mem_region(phys, size, MODULENAME);
> BUG_ON(!mem_region);
> mmio = ioremap_nocache(phys, size);
> BUG_ON(!mmio);
>
> printk("******************MMIO*************************************\n");
> printk("mmio=0x%p phys=0x%08lx size=0x%08lx\n", mmio, phys, size);
> dword = ioread32(mmio + PCI_MMIO_BASE + 0x40);
> printk("dword=%x\n", dword);
> printk("***********************************************************\n");
>
> iounmap(mmio);
> release_mem_region(phys, size);
> }
on x86 this prints out what I would expect with the correct value which
is:
> ******************MMIO*************************************
> mmio=0xf8e80000 phys=0xefa00000 size=0x00200000
> dword=54061131
> ***********************************************************
on mips however this crashes the kernel with a "Data bus error" the
exact output is below:
> ******************MMIO*************************************
> mmio=0xc0300000 phys=0x24000000 size=0x00200000
> Data bus error, epc == c0279a00, ra == c02799f4
> Oops[#1]:
> Cpu 0
> $ 0 : 00000000 10008400 c0340040 802e031c
> $ 4 : 802e031c 802e0000 00000001 8019f924
> $ 8 : 802e0000 0000020b 80320000 80320000
> $12 : 80320000 00000001 83031be6 8031c960
> $16 : 80086994 c0300000 24000000 00200000
> $20 : 802e0000 802e1ae4 c025a000 8008cde4
> $24 : 00000006 00000000
> $28 : 83030000 83031d20 c0288aec c02799f4
> Hi : 00000051
> Lo : eb851f00
> epc : c0279a00 Tainted: P
> ra : c02799f4 Status: 10008403 KERNEL EXL IE
> Cause : 1080001c
> PrId : 00061200
> Modules linked in: tmman1700(P) mousedev usbhid usb_storage phStbFB(P) phStbFBRead(P) phStbVideoRenderer(P) phStbVe
> Process insmod (pid: 785, threadinfo=83030000, task=8109f8e8)
> Stack : c0288b28 c0300000 24000000 00200000 810b9c54 00000003 c0290000 810b9c00
> c0288b28 c0279ae4 83031d48 00000002 00000000 00000000 810b9c00 c0288510
> 00000000 80373480 80177520 801774e4 810b9d1c c0288544 80177574 829f6066
> 810b9d1c 810b9c48 c0288544 801a3d40 810b9d1c 801a4538 81091c00 8011fc70
> 810b9d1c 810b9c48 c0288544 c0288544 801a475c 801a475c 801a2810 80168e08
> ...
> Call Trace:[<c0279ae4>][<80177520>][<801774e4>][<80177574>][<801a3d40>][<801a4538>][<8011fc70>][<801a475c>][<801a4]
>
> Code: 3c020004 34420040 02221021 <8c450000> 3c04c028 0200f809 24845164 3c04c028 0200f809
> Segmentation fault
The data bus error occurs whenever I do a ioreadX on the ioremapped area. Any idea why this doesn't work on the mips?
Thanks,
Jon
^ permalink raw reply
* Slow transfer for loopback
From: Ratin Rahman (mratin) @ 2007-12-14 20:23 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <e6480a290706142014jedbe846g5594f2b546d88796@mail.gmail.com>
Hello All, I am using Mipsel linux 2.6.10 kernel on IDT 79RC32H434 chip
which has integrated Ethernet MAC (100mbps). I am transfering UDP/RTP
data (30 kbyte for an I frame, 2/3 kb for a p frame, splitted into
1480 bytes of RTP packets) over the loopback address from one
application to another application.
I am seeing accumulated delay in receiving the data. Anybody else
experienced similar problem?
Ratin
^ permalink raw reply
* Slow transfer for loopback
From: Ratin Rahman (mratin) @ 2007-12-14 20:23 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <e6480a290706142014jedbe846g5594f2b546d88796@mail.gmail.com>
Hello All, I am using Mipsel linux 2.6.10 kernel on IDT 79RC32H434 chip
which has integrated Ethernet MAC (100mbps). I am transfering UDP/RTP
data (30 kbyte for an I frame, 2/3 kb for a p frame, splitted into
1480 bytes of RTP packets) over the loopback address from one
application to another application.
I am seeing accumulated delay in receiving the data. Anybody else
experienced similar problem?
Ratin
^ permalink raw reply
* Re: PCI resource unavailable on mips
From: Jon Dufresne @ 2007-12-14 18:32 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-kernel, linux-mips
In-Reply-To: <20071214093945.GA25186@linux-mips.org>
>
> Odd. I knew the resource allocation stuff has it's issues for some
> non-trivial configuration but that one is a new one. Which makes me
> wonder if your platform runs the PCI code in probe-only mode where it
> will not actually assign resources but only inherit the whole PCI setup
> except interrupt routing from the firmware.
>
> What MIPS platform do you use? I'd like to take a look at its PCI setup
> code.
>
I am using the MDS 810 STB as provided by MDS
(http://www.mds.com/products/product.asp?prod=MDS-810). The kernel and
entire environment (except my driver) was set up by MDS. uname output is
as follows.
# uname -a
Linux 10.41.13.87 2.6.19PNX8550 #1 Wed Nov 21 14:55:52 EST 2007 mips
unknown
If I can provide additional information for you I'd be happy to help.
Thanks,
Jon
^ permalink raw reply
* Re: GCC 3.4.5 and mftc0
From: Ralf Baechle @ 2007-12-14 16:26 UTC (permalink / raw)
To: Mikael Starvik; +Cc: linux-mips
In-Reply-To: <BFECAF9E178F144FAEF2BF4CE739C6680557B0DB@exmail1.se.axis.com>
On Fri, Dec 14, 2007 at 10:49:40AM +0100, Mikael Starvik wrote:
> mftc0() is implemented as
>
> .word ...
> move %0, $1
>
> With at least gcc 3.4.5 the move is implemented as an addu %0, $1, $0.
> But in the MIPS sumulator this fails and %0 gets the value 0xffffffff.
> Implementing this as a or %0, $1, $0 instead gives the expected result.
I wonder what "sumulator" you're using ...
Addu is a perfectly fine implementation of move for 32-bit code. It's not
for 64-bit code but that's beside the point here. The or method is also
correct but historically the add instruction has been prefered, also
because some processor - the R4300 afair - processes arithmetic instructions
(add, sub that is not mul / div) faster than logic operations.
> Any suggestions where the problem is and what the correct solution is?
Fix the sumulator.
> After fixing this my next problem is that IPIs doesn't reach all TCs
> correctly (it seams like the code doesn't detect IXMT status correctly,
> but I am still investigating). It is likely that it is caused by
> something similar to the problem above.
The code certainly works on real silicon, so the cause must be something
local to your environment.
Cheers,
Ralf
^ permalink raw reply
* Re: [PATCH] RBTX4927: linux-2.6.24-rc4 hang on boot
From: Ralf Baechle @ 2007-12-14 0:03 UTC (permalink / raw)
To: Frank Rowand; +Cc: linux-mips
In-Reply-To: <1197386187.5610.18.camel@localhost.localdomain>
On Tue, Dec 11, 2007 at 10:16:27AM -0500, Frank Rowand wrote:
> In linux-2.6.24-rc4 the Toshiba RBTX4927 hangs on boot.
>
> The cause is that plat_time_init() from arch/mips/tx4927/common/tx4927_setup.c
> does not override the __weak plat_time_init() from arch/mips/kernel/time.c.
> This is due to a compiler bug in gcc 4.1.1. The bug is reported to not exist
> in earlier versions of gcc, and to be fixed in 4.1.2. The problem is that
> the __weak plat_time_init() is empty and thus gets optimized out of
> existence (thus the linker is never given the option to replace the
> __weak function).
You meant the call to plat_time_init() from time_init() gets optimized away.
> For more info on the gcc bug see
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
>
> The attached patch is one workaround. Another possible workaround
> would be to change the __weak plat_time_init() to be a non-empty
> function.
The __weak definition of plat_time_init was only ever meant to be a
migration helper to keep platforms that don't have a plat_time_init
compiling. A few greps says that all platforms now supply their own
plat_time_init() so the weak definition is no longer needed. So I
instead delete it.
Ralf
^ permalink raw reply
* Re: [PATCH][MIPS] move vr41xx_calculate_clock_frequency() to plat_time_init()
From: Ralf Baechle @ 2007-12-14 1:06 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: linux-mips
In-Reply-To: <20071212221109.e0448c18.yoichi_yuasa@tripeaks.co.jp>
On Wed, Dec 12, 2007 at 10:11:09PM +0900, Yoichi Yuasa wrote:
> Moved vr41xx_calculate_clock_frequency() to plat_time_init().
> This function relates to the timer function.
>
> Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Queued for 2.6.25.
Thanks,
Ralf.
^ permalink raw reply
* Re: [PATCH][1/2][MIPS] remove unneeded button check for reset
From: Ralf Baechle @ 2007-12-14 1:07 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: linux-mips
In-Reply-To: <20071212222019.9ab7b2ed.yoichi_yuasa@tripeaks.co.jp>
On Wed, Dec 12, 2007 at 10:20:19PM +0900, Yoichi Yuasa wrote:
> Removed unneeded button check for reset.
> Because, the Cobalt has power switch.
Queued for 2.6.25 with the printk removed. If anywhere such notifications
should go to userspace.
Thanks,
Ralf.
^ permalink raw reply
* Re: [PATCH][MIPS] move the eXcite local config to excitedirectory
From: Ralf Baechle @ 2007-12-14 1:07 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: linux-mips
In-Reply-To: <20071212223954.44e12672.yoichi_yuasa@tripeaks.co.jp>
On Wed, Dec 12, 2007 at 10:39:54PM +0900, Yoichi Yuasa wrote:
> Moved the eXcite local config to excite directory.
Queued for 2.6.25 - though a file for a single statement doesn't make
verribly much sense.
Thanks,
Ralf.
^ permalink raw reply
* Re: [PATCH][2/2][MIPS] add cpu_wait() to machine_halt()
From: Ralf Baechle @ 2007-12-14 1:07 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: linux-mips
In-Reply-To: <20071212222313.92e69c16.yoichi_yuasa@tripeaks.co.jp>
On Wed, Dec 12, 2007 at 10:23:13PM +0900, Yoichi Yuasa wrote:
>
> Added cpu_wait() to machine_halt().
> For the power reduction in halt.
Queued for 2.6.25.
Thanks,
Ralf.
^ permalink raw reply
* Re: PCI resource unavailable on mips
From: Ralf Baechle @ 2007-12-14 9:39 UTC (permalink / raw)
To: Jon Dufresne; +Cc: linux-kernel, linux-mips
In-Reply-To: <1197557806.3370.7.camel@microwave.infinitevideocorporation.com>
On Thu, Dec 13, 2007 at 09:56:46AM -0500, Jon Dufresne wrote:
> I've done a bit of linux driver development on x86 in the past.
> Currently I am working on my first ever linux driver for a mips box. I
> started by testing the device in an x86 box and got it reasonable stable
> and am now testing it in the mips box. There appears to be a major
> problem, one unlike I have ever seen before.
>
> My PCI device has three BARS. This can be confirmed by the Technical
> documentation and the x86 code. When the pci device is first probed, I
> run a loop to printk out the bar information, this is just as a sanity
> check. Here is the output on the x86:
>
> Bar0:PHYS=e0000000 LEN=04000000
> Bar1:PHYS=efa00000 LEN=00200000
> Bar2:PHYS=e8000000 LEN=04000000
>
> but here is the output on the mips:
> Bar0:PHYS=20000000 LEN=04000000
> Bar1:PHYS=24000000 LEN=00200000
> Bar2:PHYS=00000000 LEN=00000000
>
> notice, BAR2 has no valid information on the mips. I tried to run
> "pci_enable_device" before printing this information, as suggested by
> LDD but it did not help.
Resources are assigned on bootup by MIPS, not yet by pci_enable_device,
so that was expected.
> Has anyone seen a problem like this before and any idea how I can get
> BAR2 a proper address?
>
> If I examine the config space directly there is an address in BAR2's
> register, however it isn't in the 0x20000000 range like the other two,
> instead it is 0x1c000000. Also if I do a ``cat /proc/iomem'' I correctly
> see BAR0 and BAR1 in the output, but not BAR2.
Odd. I knew the resource allocation stuff has it's issues for some
non-trivial configuration but that one is a new one. Which makes me
wonder if your platform runs the PCI code in probe-only mode where it
will not actually assign resources but only inherit the whole PCI setup
except interrupt routing from the firmware.
What MIPS platform do you use? I'd like to take a look at its PCI setup
code.
Ralf
^ permalink raw reply
* GCC 3.4.5 and mftc0
From: Mikael Starvik @ 2007-12-14 9:49 UTC (permalink / raw)
To: linux-mips
mftc0() is implemented as
.word ...
move %0, $1
With at least gcc 3.4.5 the move is implemented as an addu %0, $1, $0.
But in the MIPS sumulator this fails and %0 gets the value 0xffffffff.
Implementing this as a or %0, $1, $0 instead gives the expected result.
Any suggestions where the problem is and what the correct solution is?
After fixing this my next problem is that IPIs doesn't reach all TCs
correctly (it seams like the code doesn't detect IXMT status correctly,
but I am still investigating). It is likely that it is caused by
something similar to the problem above.
Regards
/Mikael
^ permalink raw reply
* GCC 3.4.5 and mftc0
From: Mikael Starvik @ 2007-12-14 9:49 UTC (permalink / raw)
To: linux-mips
mftc0() is implemented as
.word ...
move %0, $1
With at least gcc 3.4.5 the move is implemented as an addu %0, $1, $0.
But in the MIPS sumulator this fails and %0 gets the value 0xffffffff.
Implementing this as a or %0, $1, $0 instead gives the expected result.
Any suggestions where the problem is and what the correct solution is?
After fixing this my next problem is that IPIs doesn't reach all TCs
correctly (it seams like the code doesn't detect IXMT status correctly,
but I am still investigating). It is likely that it is caused by
something similar to the problem above.
Regards
/Mikael
^ permalink raw reply
* Re: Inter processor synchronization
From: Kevin D. Kissell @ 2007-12-14 9:26 UTC (permalink / raw)
To: Nilanjan Roychowdhury, Ralf Baechle; +Cc: linux-mips
In-Reply-To: <9D98C51005D80D43A19A3DF329A61D690106A297@INDEXCH2003.gmi.domain>
> >> I have a scenario where two images of the same Linux kernel are
> >> running on two MIPS cores. One is 24K and another is 4KEC. What is
> >> the best way to achieve inter processor synchronization between them?
> >>
> >> I guess the locks for LL/SC are local to a particular core and can
> >> not be extended across a multi core system.
Just to be clear, LL/SC are indeed local to a particular core *but*,
in a cache coherent multiprocessor system, they provide multiprocessor
synchronization - the fact that another core has referenced the coherent
location will clear the link bit so that the SC will fail locally.
> > 4K and 24K cores don't support cache coherency. So SMP is out of
> > question.
> > This is a _total_ showstopper for SMP, don't waste your time thinking
> > on possible workarounds.
> >
> > The you could do is some sort of clusting, running two OS images, one
> > on the 4K and one on the 24K which would communicate through a
> > carefully cache managed or even uncached shared memory region.
>
> I guess I am left with only this option. Can you please throw some more
> lights On the IPC you are mentioning?
Unless one has special-purpose hardware that implements atomic operations
(e.g. a hardware semaphore device), one must use algorithms that do not
require atomic read-modify-write. Most classically, one uses mailboxes
where each memory location has a single reader and a single writer. There
are other, more general but less efficient algorithms (e.g. Decker's algorithm)
out there as well. If one is doing this in cacheable memory, one needs
to take care that (a) an explicit forced cache writeback operation is done
to complete each update to the shared memory array, and (b) the "ownership"
is at a granularity of a cache line, and not a memory word. If the memory
is mapped uncached, and one has a message queue "next" pointer that
is written by CPU A and a "last-read" pointer that is written by B, those two
pointers can be in consecutive memory locations. But if the memory is cached,
they must be in separate cache lines to avoid the writebacks of one CPU
destroying the writebacks of another.
Regards,
Kevin K.
^ permalink raw reply
* Re: Inter processor synchronization
From: Kevin D. Kissell @ 2007-12-14 9:26 UTC (permalink / raw)
To: Nilanjan Roychowdhury, Ralf Baechle; +Cc: linux-mips
In-Reply-To: <9D98C51005D80D43A19A3DF329A61D690106A297@INDEXCH2003.gmi.domain>
> >> I have a scenario where two images of the same Linux kernel are
> >> running on two MIPS cores. One is 24K and another is 4KEC. What is
> >> the best way to achieve inter processor synchronization between them?
> >>
> >> I guess the locks for LL/SC are local to a particular core and can
> >> not be extended across a multi core system.
Just to be clear, LL/SC are indeed local to a particular core *but*,
in a cache coherent multiprocessor system, they provide multiprocessor
synchronization - the fact that another core has referenced the coherent
location will clear the link bit so that the SC will fail locally.
> > 4K and 24K cores don't support cache coherency. So SMP is out of
> > question.
> > This is a _total_ showstopper for SMP, don't waste your time thinking
> > on possible workarounds.
> >
> > The you could do is some sort of clusting, running two OS images, one
> > on the 4K and one on the 24K which would communicate through a
> > carefully cache managed or even uncached shared memory region.
>
> I guess I am left with only this option. Can you please throw some more
> lights On the IPC you are mentioning?
Unless one has special-purpose hardware that implements atomic operations
(e.g. a hardware semaphore device), one must use algorithms that do not
require atomic read-modify-write. Most classically, one uses mailboxes
where each memory location has a single reader and a single writer. There
are other, more general but less efficient algorithms (e.g. Decker's algorithm)
out there as well. If one is doing this in cacheable memory, one needs
to take care that (a) an explicit forced cache writeback operation is done
to complete each update to the shared memory array, and (b) the "ownership"
is at a granularity of a cache line, and not a memory word. If the memory
is mapped uncached, and one has a message queue "next" pointer that
is written by CPU A and a "last-read" pointer that is written by B, those two
pointers can be in consecutive memory locations. But if the memory is cached,
they must be in separate cache lines to avoid the writebacks of one CPU
destroying the writebacks of another.
Regards,
Kevin K.
^ permalink raw reply
* RE: Inter processor synchronization
From: Nilanjan Roychowdhury @ 2007-12-14 4:21 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071213125847.GA1352@linux-mips.org>
on Thursday, December 13, 2007 6:29 PM:, Ralf Baechle wrote:
> On Thu, Dec 13, 2007 at 09:07:20AM +0530, Nilanjan Roychowdhury wrote:
>
>> I have a scenario where two images of the same Linux kernel are
>> running on two MIPS cores. One is 24K and another is 4KEC. What is
>> the best way to achieve inter processor synchronization between them?
>>
>> I guess the locks for LL/SC are local to a particular core and can
>> not be extended across a multi core system.
> 4K and 24K cores don't support cache coherency. So SMP is out of
> question.
> This is a _total_ showstopper for SMP, don't waste your time thinking
> on possible workarounds.
>
> The you could do is some sort of clusting, running two OS images, one
> on the 4K and one on the 24K which would communicate through a
> carefully cache managed or even uncached shared memory region.
I guess I am left with only this option. Can you please throw some more
lights
On the IPC you are mentioning?
>> Will it be easier for me if both of them becomes same core ( like
>> both 24k) and I run the SMP version of Linux.
>
>
> Within limits Linux supports mixing different CPU types such as
> R4000MC / R4400MC and R10000 / R12000 / R14000 mixes because those
> processors are similar enough
>
> Ralf
Thanks,
Nilanjan
^ permalink raw reply
* RE: Inter processor synchronization
From: Nilanjan Roychowdhury @ 2007-12-14 4:21 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071213125847.GA1352@linux-mips.org>
on Thursday, December 13, 2007 6:29 PM:, Ralf Baechle wrote:
> On Thu, Dec 13, 2007 at 09:07:20AM +0530, Nilanjan Roychowdhury wrote:
>
>> I have a scenario where two images of the same Linux kernel are
>> running on two MIPS cores. One is 24K and another is 4KEC. What is
>> the best way to achieve inter processor synchronization between them?
>>
>> I guess the locks for LL/SC are local to a particular core and can
>> not be extended across a multi core system.
> 4K and 24K cores don't support cache coherency. So SMP is out of
> question.
> This is a _total_ showstopper for SMP, don't waste your time thinking
> on possible workarounds.
>
> The you could do is some sort of clusting, running two OS images, one
> on the 4K and one on the 24K which would communicate through a
> carefully cache managed or even uncached shared memory region.
I guess I am left with only this option. Can you please throw some more
lights
On the IPC you are mentioning?
>> Will it be easier for me if both of them becomes same core ( like
>> both 24k) and I run the SMP version of Linux.
>
>
> Within limits Linux supports mixing different CPU types such as
> R4000MC / R4400MC and R10000 / R12000 / R14000 mixes because those
> processors are similar enough
>
> Ralf
Thanks,
Nilanjan
^ permalink raw reply
* GCC bug affecting MIPS (was Re: SiByte 1480 & Branch Likely instructions?)
From: Kaz Kylheku @ 2007-12-14 3:05 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C5590D6B@exchange.ZeugmaSystems.local>
"Kaz Kylheku" <kaz@zeugmasystems.com> wrote on December 07, 2007:
> Kaz wrote:
>> Hi All,
>>
>> Not really a kernel-related question. I've discovered that GCC 4.1.1
>> (which I'm not using for kernel compiling, but user space) generates
>> branch likely instructions by default, even though the documentation
>> says that their use is off by default for MIPS32 and MIPS64, because
>
> That's because the compiler is not configured correctly. The default CPU
> string "from-abi" ends up being used, and so the target ISA is MIPS III.
I managed to root-cause the original problem, and moments ago filed this bug
report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34456
GCC can screw up when doing branch delay slot filling, because in computing
register liveness, it makes an incorrectly computed assumption about what
registers are clobbered by a CALL_INSN. By unfortunate coincidence, it's
possible for an instruction which restores the caller's GP to be wrongly
moved into a non-annulled delay slot, wreaking havoc on the fall-through
path where GP is in fact used. Jumps and data accesses are then attempted
using what is possibly the wrong global offset table.
^ permalink raw reply
* GCC bug affecting MIPS (was Re: SiByte 1480 & Branch Likely instructions?)
From: Kaz Kylheku @ 2007-12-14 3:05 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C5590D6B@exchange.ZeugmaSystems.local>
"Kaz Kylheku" <kaz@zeugmasystems.com> wrote on December 07, 2007:
> Kaz wrote:
>> Hi All,
>>
>> Not really a kernel-related question. I've discovered that GCC 4.1.1
>> (which I'm not using for kernel compiling, but user space) generates
>> branch likely instructions by default, even though the documentation
>> says that their use is off by default for MIPS32 and MIPS64, because
>
> That's because the compiler is not configured correctly. The default CPU
> string "from-abi" ends up being used, and so the target ISA is MIPS III.
I managed to root-cause the original problem, and moments ago filed this bug
report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34456
GCC can screw up when doing branch delay slot filling, because in computing
register liveness, it makes an incorrectly computed assumption about what
registers are clobbered by a CALL_INSN. By unfortunate coincidence, it's
possible for an instruction which restores the caller's GP to be wrongly
moved into a non-annulled delay slot, wreaking havoc on the fall-through
path where GP is in fact used. Jumps and data accesses are then attempted
using what is possibly the wrong global offset table.
^ permalink raw reply
* [PATCH][MIPS] kernel build fails if CONFIG_KGDB=y and CONFIG_SMP=n
From: Frank Rowand @ 2007-12-13 22:57 UTC (permalink / raw)
To: linux-mips
The kernel build fails if CONFIG_KGDB=y and CONFIG_SMP=n.
kgdb_wait() is defined but unused, resulting in a warning.
The warning is converted to an error by the
"EXTRA_CFLAGS += -Werror" in arch/mips/kernel/Makefile.
Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
---
arch/mips/kernel/gdb-stub.c | 2 2 + 0 - 0 !
1 files changed, 2 insertions(+)
Index: linux-2.6.24-rc4/arch/mips/kernel/gdb-stub.c
===================================================================
--- linux-2.6.24-rc4.orig/arch/mips/kernel/gdb-stub.c
+++ linux-2.6.24-rc4/arch/mips/kernel/gdb-stub.c
@@ -656,6 +656,7 @@ void set_async_breakpoint(unsigned long
*epc = (unsigned long)async_breakpoint;
}
+#ifdef CONFIG_SMP
static void kgdb_wait(void *arg)
{
unsigned flags;
@@ -668,6 +669,7 @@ static void kgdb_wait(void *arg)
local_irq_restore(flags);
}
+#endif
/*
* GDB stub needs to call kgdb_wait on all processor with interrupts
^ permalink raw reply
* Re: questions on struct sigcontext
From: Daniel Jacobowitz @ 2007-12-13 15:36 UTC (permalink / raw)
To: Chris Friesen; +Cc: linux-mips, ralf
In-Reply-To: <47607327.5090709@nortel.com>
On Wed, Dec 12, 2007 at 05:47:51PM -0600, Chris Friesen wrote:
> If the cause/badvaddr entries in struct sigcontext were filled in by the
> exception handler in the kernel, wouldn't the values in that struct be
> completely valid even if the registers themselves were changed before
> userspace could handle the signal?
Yeah, my reply didn't make much sense. Trust Ralf's instead.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply
* Re: Inter processor synchronization
From: Ralf Baechle @ 2007-12-13 12:58 UTC (permalink / raw)
To: Nilanjan Roychowdhury; +Cc: linux-mips
In-Reply-To: <9D98C51005D80D43A19A3DF329A61D690106A282@INDEXCH2003.gmi.domain>
On Thu, Dec 13, 2007 at 09:07:20AM +0530, Nilanjan Roychowdhury wrote:
> I have a scenario where two images of the same Linux kernel are running
> on two MIPS cores. One is 24K and another is 4KEC. What is the best way
> to achieve inter processor synchronization between them?
>
> I guess the locks for LL/SC are local to a particular core and can not
> be extended across a multi core system.
4K and 24K cores don't support cache coherency. So SMP is out of question.
This is a _total_ showstopper for SMP, don't waste your time thinking on
possible workarounds.
The you could do is some sort of clusting, running two OS images, one
on the 4K and one on the 24K which would communicate through a carefully
cache managed or even uncached shared memory region.
> Will it be easier for me if both of them becomes same core ( like both
> 24k) and I run the SMP version of Linux.
Within limits Linux supports mixing different CPU types such as R4000MC /
R4400MC and R10000 / R12000 / R14000 mixes because those processors are
similar enough
Ralf
^ permalink raw reply
* Inter processor synchronization
From: Nilanjan Roychowdhury @ 2007-12-13 3:37 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 516 bytes --]
Hi,
I have a scenario where two images of the same Linux kernel are running
on two MIPS cores. One is 24K and another is 4KEC. What is the best way
to achieve inter processor synchronization between them?
I guess the locks for LL/SC are local to a particular core and can not
be extended across a multi core system.
Will it be easier for me if both of them becomes same core ( like both
24k) and I run the SMP version of Linux.
Please throw some light.
Thanks,
Nilanjan
[-- Attachment #2: Type: text/html, Size: 3026 bytes --]
^ permalink raw reply
* Inter processor synchronization
From: Nilanjan Roychowdhury @ 2007-12-13 3:37 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 516 bytes --]
Hi,
I have a scenario where two images of the same Linux kernel are running
on two MIPS cores. One is 24K and another is 4KEC. What is the best way
to achieve inter processor synchronization between them?
I guess the locks for LL/SC are local to a particular core and can not
be extended across a multi core system.
Will it be easier for me if both of them becomes same core ( like both
24k) and I run the SMP version of Linux.
Please throw some light.
Thanks,
Nilanjan
[-- Attachment #2: Type: text/html, Size: 3026 bytes --]
^ permalink raw reply
* Re: questions on struct sigcontext
From: David Daney @ 2007-12-13 0:06 UTC (permalink / raw)
To: Chris Friesen; +Cc: Daniel Jacobowitz, linux-mips, ralf
In-Reply-To: <47607327.5090709@nortel.com>
Chris Friesen wrote:
> Daniel Jacobowitz wrote:
>
>> There used to be slots for badvaddr and cause. You'll have to ask
>> Ralf why he decided to clobber them for DSP state, I don't remember
>> :-) I suspect they may never have held useful information for you;
>> we don't context switch them for userspace, so an intervening fault
>> in kernel space or in another thread could change them.
>
> I'm a bit confused as to how they would never have held useful
> information--did you mean the registers themselves, or the entries in
> struct sigcontext?
The entries in the sigcontext. As Ralf said, they never held valid values.
>
> If the cause/badvaddr entries in struct sigcontext were filled in by the
> exception handler in the kernel,
It would appear that they are not.
> wouldn't the values in that struct be
> completely valid even if the registers themselves were changed before
> userspace could handle the signal?
>
> If this is not the case then it seems like si_addr/si_code wouldn't be
> trustworthy either.
This I am not sure about :(, However knowing the values of all registers
(and perhaps /proc/self/maps) and $pc you can easily derive what happened.
David Daney
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox