* [PATCH] powerpc: correct 2nd pci controller interrupt value in mpc834x_mds dts
From: Kim Phillips @ 2008-01-31 18:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: peter.vanackeren
according to the 8349EA ref man, pci2 IRQ is 67. Thanks to Peter
Van Ackeren for finding this.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/boot/dts/mpc834x_mds.dts | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc834x_mds.dts b/arch/powerpc/boot/dts/mpc834x_mds.dts
index 7480eda..0199c5c 100644
--- a/arch/powerpc/boot/dts/mpc834x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc834x_mds.dts
@@ -332,7 +332,7 @@
0xc000 0x0 0x0 0x3 &ipic 23 0x8
0xc000 0x0 0x0 0x4 &ipic 20 0x8>;
interrupt-parent = <&ipic>;
- interrupts = <66 0x8>;
+ interrupts = <67 0x8>;
bus-range = <0 0>;
ranges = <0x02000000 0x0 0xb0000000 0xb0000000 0x0 0x10000000
0x42000000 0x0 0xa0000000 0xa0000000 0x0 0x10000000
--
1.5.2.2
^ permalink raw reply related
* Re: build fails for adder875 for new pulls of powerpc.git
From: Jochen Friedrich @ 2008-01-31 18:20 UTC (permalink / raw)
To: Rognlien Dag Kristian; +Cc: linuxppc-dev
In-Reply-To: <39417DF3286A66428FA558987839F44F0356C232@SINTEFXCH01.sintef.no>
Hi Rognlien,
> The latest commits to powerpc.git removes commproc.h files used by arch/powerpc/platforms/8xx/adder875.c
>
> The kernel fails to build for the adder configs.
This should fix it:
diff --git a/arch/powerpc/platforms/8xx/adder875.c b/arch/powerpc/platforms/8xx/adder875.c
index c6bc078..b49d62a 100644
--- a/arch/powerpc/platforms/8xx/adder875.c
+++ b/arch/powerpc/platforms/8xx/adder875.c
@@ -15,12 +15,12 @@
#include <asm/time.h>
#include <asm/machdep.h>
-#include <asm/commproc.h>
+#include <asm/cpm1.h>
#include <asm/fs_pd.h>
#include <asm/udbg.h>
#include <asm/prom.h>
-#include <sysdev/commproc.h>
+#include "mpc8xx.h"
struct cpm_pin {
int port, pin, flags;
Thanks,
Jochen
^ permalink raw reply related
* Re: build fails for adder875 for new pulls of powerpc.git
From: Kumar Gala @ 2008-01-31 19:13 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Scott Wood, linuxppc-dev list, Rognlien Dag Kristian
In-Reply-To: <47A2118B.2060808@scram.de>
On Jan 31, 2008, at 12:20 PM, Jochen Friedrich wrote:
> Hi Rognlien,
>
>> The latest commits to powerpc.git removes commproc.h files used by
>> arch/powerpc/platforms/8xx/adder875.c
>>
>> The kernel fails to build for the adder configs.
>
> This should fix it:
>
> diff --git a/arch/powerpc/platforms/8xx/adder875.c b/arch/powerpc/
> platforms/8xx/adder875.c
> index c6bc078..b49d62a 100644
> --- a/arch/powerpc/platforms/8xx/adder875.c
> +++ b/arch/powerpc/platforms/8xx/adder875.c
> @@ -15,12 +15,12 @@
>
> #include <asm/time.h>
> #include <asm/machdep.h>
> -#include <asm/commproc.h>
> +#include <asm/cpm1.h>
> #include <asm/fs_pd.h>
> #include <asm/udbg.h>
> #include <asm/prom.h>
>
> -#include <sysdev/commproc.h>
> +#include "mpc8xx.h"
>
> struct cpm_pin {
> int port, pin, flags;
>
> Thanks,
> Jochen
I'll take scott's version as its more complete and fixes another board.
- k
^ permalink raw reply
* Re: Kernel oops while duming user core.
From: Kumar Gala @ 2008-01-31 19:15 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03EE47A4@ismail.innsys.innovsys.com>
> }
> (gdb) list *0xc000f0a0
> No source file for address 0xc000f0a0.
> (gdb) disassemble 0xc000f0a0
> Dump of assembler code for function __flush_dcache_icache:
> 0xc000f08c <__flush_dcache_icache+0>: dec %esi
> 0xc000f08d <__flush_dcache_icache+1>: addb $0x20,(%eax)
> 0xc000f090 <__flush_dcache_icache+4>: push %esp
> 0xc000f091 <__flush_dcache_icache+5>: arpl %ax,(%eax)
> 0xc000f093 <__flush_dcache_icache+7>: cmp %al,%es:
> 0x897c8000(%eax)
> 0xc000f09a <__flush_dcache_icache+14>: add 0x781b667c(%esi),%esp
> 0xc000f0a0 <__flush_dcache_icache+20>: jl 0xc000f0a2
> <__flush_dcache_icache+22>
> 0xc000f0a2 <__flush_dcache_icache+22>: sbb %ch,0x63(%eax,%edi,1)
> 0xc000f0a6 <__flush_dcache_icache+26>: add %ah,(%eax)
> 0xc000f0a8 <__flush_dcache_icache+28>: inc %edx
> 0xc000f0a9 <__flush_dcache_icache+29>: add %bh,%bh
> 0xc000f0ab <__flush_dcache_icache+31>: clc
> 0xc000f0ac <__flush_dcache_icache+32>: jl 0xc000f0ae
> <__flush_dcache_icache+34>
> 0xc000f0ae <__flush_dcache_icache+34>: add $0xac,%al
> 0xc000f0b0 <__flush_dcache_icache+36>: jl 0xc000f03b
> <flush_dcache_range+15>
> 0xc000f0b2 <__flush_dcache_icache+38>: add 0xac37007c(%esi),%esp
> 0xc000f0b8 <__flush_dcache_icache+44>: cmp %al,%dh
> 0xc000f0ba <__flush_dcache_icache+46>: add %ah,(%eax)
> 0xc000f0bc <__flush_dcache_icache+48>: inc %edx
> 0xc000f0bd <__flush_dcache_icache+49>: add %bh,%bh
> 0xc000f0bf <__flush_dcache_icache+51>: clc
> 0xc000f0c0 <__flush_dcache_icache+52>: jl 0xc000f0c2
> <__flush_dcache_icache+54>
> 0xc000f0c2 <__flush_dcache_icache+54>: add $0xac,%al
> 0xc000f0c4 <__flush_dcache_icache+56>: dec %esp
> 0xc000f0c5 <__flush_dcache_icache+57>: add %al,(%ecx)
> 0xc000f0c7 <__flush_dcache_icache+59>: sub $0x4e,%al
> 0xc000f0c9 <__flush_dcache_icache+61>: addb $0x20,(%eax)
> End of assembler dump.
This doesn't look like ppc disasm to me :)
- k
^ permalink raw reply
* Re: Kernel oops while duming user core.
From: Kumar Gala @ 2008-01-31 19:15 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03EE46B8@ismail.innsys.innovsys.com>
On Jan 31, 2008, at 10:26 AM, Rune Torgersen wrote:
> Nathan Lynch wrote:
>> Hmm, this is the second report of 2.6.24 crashing in
>> __flush_dcache_icache during a core dump; see:
>> http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048662.html
>>
>> Is this easily recreatable?
>
> Yes. I have a binary that will do this every time it is started (on
> this
> particular system),
> only takes about 10 seconds before it dumps.
>
> I was going to test HEAD of powerpc.git to see if it is still there.
> I cannot test any earlier versions as our board port was done on
> 2.6.24.
>
> Our older kernel port is 2.6.18 on arch/ppc, and it works just fine.
>
>
> One potential clue:
>> Unable to handle kernel paging request for data at address 0x48024000
>
> this adddress is beyond our physical memory. We have 1GB of mem
> (CONFIG_HIGH_MEM enabled) so 0x3fff_ffff is the last valid address.
> 0x4000_0000 to 0x7fff_ffff are unused, 0x8000_0000 to 0x9fff_ffff is
> used by PCI.
Can you git-bisect to narrow this down further.
- k
^ permalink raw reply
* RE: Kernel oops while duming user core.
From: Rune Torgersen @ 2008-01-31 19:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <FAC79874-50F8-4C14-AE9B-A17BC51E8E87@kernel.crashing.org>
Kumar Gala wrote:
> This doesn't look like ppc disasm to me :)
>=20
Helps if i use the cross-compiler gdb instead of the x86 native one...
here is the disasembly dump for NIP
(gdb) disassemble 0xc000f0a0
Dump of assembler code for function __flush_dcache_icache:
0xc000f08c <__flush_dcache_icache+0>: blr
0xc000f090 <__flush_dcache_icache+4>: rlwinm r3,r3,0,0,19
0xc000f094 <__flush_dcache_icache+8>: li r4,128
0xc000f098 <__flush_dcache_icache+12>: mtctr r4
0xc000f09c <__flush_dcache_icache+16>: mr r6,r3
0xc000f0a0 <__flush_dcache_icache+20>: dcbst r0,r3
0xc000f0a4 <__flush_dcache_icache+24>: addi r3,r3,32
0xc000f0a8 <__flush_dcache_icache+28>: bdnz+ 0xc000f0a0
<__flush_dcache_icache+20>
0xc000f0ac <__flush_dcache_icache+32>: sync
0xc000f0b0 <__flush_dcache_icache+36>: mtctr r4
0xc000f0b4 <__flush_dcache_icache+40>: icbi r0,r6
0xc000f0b8 <__flush_dcache_icache+44>: addi r6,r6,32
0xc000f0bc <__flush_dcache_icache+48>: bdnz+ 0xc000f0b4
<__flush_dcache_icache+40>
0xc000f0c0 <__flush_dcache_icache+52>: sync
0xc000f0c4 <__flush_dcache_icache+56>: isync
0xc000f0c8 <__flush_dcache_icache+60>: blr
End of assembler dump.
(gdb) =20
registers were:
NIP: c000f0a0 LR: c0011fec CTR: 00000080
REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test)
MSR: 00009032 <EE,ME,IR,DR> CR: 24004442 XER: 00000000
DAR: 48024000, DSISR: 20000000
TASK =3D eeba9780[2554] 'armd_crash' THREAD: eebe8000
GPR00: eea44d00 eebe9c20 eeba9780 48024000 00000080 37a56181 48024000
00000000
GPR08: 37a56181 eea44d00 00000000 c2000000 44004422 10100f38 ef336600
bfffffff
GPR16: eeff0300 00000030 eea44d00 00000000 eebe9cdc 00000011 eebe9cd8
eebca480
GPR24: eea44d00 37a56181 48024000 eebad580 eebad580 37a56181 48024000
c26f4ac0
^ permalink raw reply
* RE: Kernel oops while duming user core.
From: Rune Torgersen @ 2008-01-31 19:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <504DF4A9-6ED5-4208-84B4-FECC3FC90C0D@kernel.crashing.org>
Kumar Gala wrote:
> Can you git-bisect to narrow this down further.
Not easilly, as the board port to arch/powerpc was done on 2.6.24-rc7
and up.
Is there an somewhat esy way in git to apply the differences from master
branch to our board branch to a branch created by bisect?
And I don't even know where this started to happen.
Would trying arch/ppc help any? I have our arch/ppc port in a
semiworking state for kernels up to 2.6.23
^ permalink raw reply
* Re: build fails for adder875 for new pulls of powerpc.git
From: Jochen Friedrich @ 2008-01-31 18:36 UTC (permalink / raw)
To: Rognlien Dag Kristian; +Cc: linuxppc-dev
In-Reply-To: <47A2118B.2060808@scram.de>
Hi Rognlien,
> Hi Rognlien,
>
>> The latest commits to powerpc.git removes commproc.h files used by arch/powerpc/platforms/8xx/adder875.c
>>
>> The kernel fails to build for the adder configs.
>
> This should fix it:
>
> diff --git a/arch/powerpc/platforms/8xx/adder875.c b/arch/powerpc/platforms/8xx/adder875.c
> index c6bc078..b49d62a 100644
> --- a/arch/powerpc/platforms/8xx/adder875.c
> +++ b/arch/powerpc/platforms/8xx/adder875.c
> @@ -15,12 +15,12 @@
>
> #include <asm/time.h>
> #include <asm/machdep.h>
> -#include <asm/commproc.h>
> +#include <asm/cpm1.h>
> #include <asm/fs_pd.h>
> #include <asm/udbg.h>
> #include <asm/prom.h>
>
> -#include <sysdev/commproc.h>
> +#include "mpc8xx.h"
>
> struct cpm_pin {
> int port, pin, flags;
sorry, this fix was incomplete. Scott Wood just posted a correct fix.
Thanks,
Jochen
^ permalink raw reply
* Kernel oops in MPC8568MDS BSP
From: mike zheng @ 2008-01-31 19:28 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I am using MPC8568MDS BSP on my board, which has same memory map with
MPC8568MDS board. However I have kernel Ooop at
free_bootmem_with_active_regions() within do_init_bootmem(). Any idea
on this issue?
Thanks,
Mike
bootm 0x1000000 0x2000000 0x400000
## Booting image at 01000000 ...
Image Name: Linux-2.6.23
Created: 2008-01-31 18:52:45 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1370100 Bytes = 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 02000000 ...
Image Name: uboot ext2 ramdisk rootfs
Created: 2007-11-26 2:28:38 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 4001113 Bytes = 3.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using flat device tree at 0x400000
Loading Ramdisk to 1fb6e000, end 1ff3ed59 ... OK
Using MPC85xx MDS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.23 () (gcc version 4.1.2) #3 Thu Jan 31 13:52:40 EST 2008
Found initrd at 0xdfb6e000:0xdff3ed59
console [udbg0] enabled
Kernel BUG at c0296a68 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
MPC85xx MDS
Modules linked in:
NIP: c0296a68 LR: c0298100 CTR: 00001c00
REGS: c02c7ec0 TRAP: 0700 Not tainted (2.6.23)
MSR: 00021000 <ME> CR: 24002028 XER: 20000000
TASK = c02ac5e0[0] 'swapper' THREAD: c02c6000
GPR00: 00000001 c02c7f70 c02ac5e0 c02daa2c 0001e401 20000000 00000000
00000356
GPR08: 00000001 00000000 25e90000 25e90000 24002022 60000000 1ffbd400
007fff00
GPR16: 00000000 1ffb9824 00000004 1fffc830 00800000 00000000 007ffeb0
003d0d59
GPR24: 00000000 1ff3fe50 00001140 c02b0000 00000000 c02a5320 00020000
00000000
Call Trace:
[c02c7f90] [c0291144]
[c02c7fb0] [c028f250]
[c02c7fc0] [c028681c]
[c02c7ff0] [c0000388]
Instruction dump:
5489e8fa 7d000030 7d295a14 7d604828 7d6a0078 7d40492d 40a2fff4
7c095839
38840001 4182000c 4200ffd0 4e800020 <0fe00000> 48000000 3d20c02b
7c601b78
Kernel panic - not syncing: Attempted to kill the idle task!
^ permalink raw reply
* Kernel oops in MPC8568MDS BSP
From: mike zheng @ 2008-01-31 19:29 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am using MPC8568MDS BSP on my board, which has same memory map as
MPC8568MDS board has. However I have kernel oops at
free_bootmem_with_active_regions() within do_init_bootmem(). Any idea
on this issue?
Thanks,
Mike
bootm 0x1000000 0x2000000 0x400000
## Booting image at 01000000 ...
Image Name: Linux-2.6.23
Created: 2008-01-31 18:52:45 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1370100 Bytes = 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 02000000 ...
Image Name: uboot ext2 ramdisk rootfs
Created: 2007-11-26 2:28:38 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 4001113 Bytes = 3.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using flat device tree at 0x400000
Loading Ramdisk to 1fb6e000, end 1ff3ed59 ... OK
Using MPC85xx MDS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.23 () (gcc version 4.1.2) #3 Thu Jan 31 13:52:40 EST 2008
Found initrd at 0xdfb6e000:0xdff3ed59
console [udbg0] enabled
Kernel BUG at c0296a68 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
MPC85xx MDS
Modules linked in:
NIP: c0296a68 LR: c0298100 CTR: 00001c00
REGS: c02c7ec0 TRAP: 0700 Not tainted (2.6.23)
MSR: 00021000 <ME> CR: 24002028 XER: 20000000
TASK = c02ac5e0[0] 'swapper' THREAD: c02c6000
GPR00: 00000001 c02c7f70 c02ac5e0 c02daa2c 0001e401 20000000 00000000
00000356
GPR08: 00000001 00000000 25e90000 25e90000 24002022 60000000 1ffbd400
007fff00
GPR16: 00000000 1ffb9824 00000004 1fffc830 00800000 00000000 007ffeb0
003d0d59
GPR24: 00000000 1ff3fe50 00001140 c02b0000 00000000 c02a5320 00020000
00000000
Call Trace:
[c02c7f90] [c0291144]
[c02c7fb0] [c028f250]
[c02c7fc0] [c028681c]
[c02c7ff0] [c0000388]
Instruction dump:
5489e8fa 7d000030 7d295a14 7d604828 7d6a0078 7d40492d 40a2fff4
7c095839
38840001 4182000c 4200ffd0 4e800020 <0fe00000> 48000000 3d20c02b
7c601b78
Kernel panic - not syncing: Attempted to kill the idle task!
^ permalink raw reply
* Re: Kernel oops while duming user core.
From: Nathan Lynch @ 2008-01-31 19:54 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03EE4869@ismail.innsys.innovsys.com>
Rune Torgersen wrote:
> Kumar Gala wrote:
> > Can you git-bisect to narrow this down further.
>
> Not easilly, as the board port to arch/powerpc was done on 2.6.24-rc7
> and up.
> Is there an somewhat esy way in git to apply the differences from master
> branch to our board branch to a branch created by bisect?
>
> And I don't even know where this started to happen.
> Would trying arch/ppc help any? I have our arch/ppc port in a
> semiworking state for kernels up to 2.6.23
Well, we know this happens on other 32-bit powerpc machines (pmac at
least)... perhaps someone could arrange to bisect on a machine that
works with older powerpc kernels (assuming they have a good repro
case).
^ permalink raw reply
* Re: [PATCH] [POWERPC] Xilinx: hwicap driver
From: Grant Likely @ 2008-01-31 19:58 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080131184722.B5E1C1A600C4@mail138-dub.bigfish.com>
On 1/31/08, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> This includes code for new fifo-based xps_hwicap in addition to the
> older opb_hwicap, which has a significantly different interface. The
> common code between the two drivers is largely shared.
>
> Significant differences exists between this driver and what is
> supported in the EDK drivers. In particular, most of the
> architecture-specific code for reconfiguring individual FPGA resources
> has been removed. This functionality is likely better provided in a
> user-space support library. In addition, read and write access is
> supported. In addition, although the xps_hwicap cores support
> interrupt-driver mode, this driver only supports polled operation, in
> order to make the code simpler, and since the interrupt processing
> overhead is likely to slow down the throughput under Linux.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Comments below...
Also, I'm not sure if drivers/char/xilinx_hwicap is the best place for
this driver. drivers/misc/ might be better (but I'm not sure; poll
other people on this)
Finally, buffer_icap and fifo_icap are not huge blocks of code. Will
they be used by any other drivers? Can they be rolled into the
xilinx_hwicap.c file?
> +static int buffer_icap_device_read(struct hwicap_drvdata *drvdata,
> + u32 offset, u32 count)
> +{
> +
> + s32 retries = 0;
> + void __iomem *base_address = drvdata->base_address;
> +
> + if (buffer_icap_busy(base_address))
> + return -EBUSY;
> +
> + if ((offset + count) <= XHI_MAX_BUFFER_INTS) {
> + /* setSize count*4 to get bytes. */
> + buffer_icap_set_size(base_address, (count << 2));
> + buffer_icap_set_offset(base_address, offset);
> + buffer_icap_set_rnc(base_address, XHI_READBACK);
> +
> + while (buffer_icap_busy(base_address)) {
> + retries++;
> + if (retries > XHI_MAX_RETRIES)
> + return -EBUSY;
> + }
> + } else {
> + return -EINVAL;
> + }
Style comment: reverse the condition and bail with return -EINVAL at
the test point. It will simplify the code and better match with
common practice in the kernel.
> + return 0;
> +
> +};
> +
> +/**
> + * buffer_icap_device_write: Transfer bytes from ICAP to the storage buffer.
> + * @parameter drvdata: a pointer to the drvdata.
> + * @parameter offset: The storage buffer start address.
> + * @parameter count: The number of words (32 bit) to read from the
> + * device (ICAP).
> + **/
> +static int buffer_icap_device_write(struct hwicap_drvdata *drvdata,
> + u32 offset, u32 count)
> +{
> +
> + s32 retries = 0;
> + void __iomem *base_address = drvdata->base_address;
> +
> + if (buffer_icap_busy(base_address))
> + return -EBUSY;
> +
> + if ((offset + count) <= XHI_MAX_BUFFER_INTS) {
> + /* setSize count*4 to get bytes. */
> + buffer_icap_set_size(base_address, count << 2);
> + buffer_icap_set_offset(base_address, offset);
> + buffer_icap_set_rnc(base_address, XHI_CONFIGURE);
> +
> + while (buffer_icap_busy(base_address)) {
> + retries++;
> + if (retries > XHI_MAX_RETRIES)
> + return -EBUSY;
> + }
> + } else {
> + return -EINVAL;
> + }
Ditto
> +/**
> + * buffer_icap_set_configuration: Load a partial bitstream from system memory.
> + * @parameter drvdata: a pointer to the drvdata.
> + * @parameter data: Kernel address of the partial bitstream.
> + * @parameter size: the size of the partial bitstream in 32 bit words.
> + **/
> +int buffer_icap_set_configuration(struct hwicap_drvdata *drvdata, u32 *data,
> + u32 size)
> +{
> + int status;
> + s32 buffer_count = 0;
> + s32 num_writes = 0;
> + bool dirty = 0;
> + u32 i;
> + void __iomem *base_address = drvdata->base_address;
> +
> + /* Loop through all the data */
> + for (i = 0, buffer_count = 0; i < size; i++) {
> +
> + /* Copy data to bram */
> + buffer_icap_set_bram(base_address, buffer_count, data[i]);
> + dirty = 1;
> +
> + if (buffer_count == XHI_MAX_BUFFER_INTS - 1) {
> + /* Write data to ICAP */
> + status = buffer_icap_device_write(
> + drvdata,
> + XHI_BUFFER_START,
> + XHI_MAX_BUFFER_INTS);
> + if (status != 0) {
> + /* abort. */
> + buffer_icap_reset(drvdata);
> + return status;
> + }
> +
> + buffer_count = 0;
> + num_writes++;
> + dirty = 0;
> + } else {
> + buffer_count++;
> + }
Nit: Consider reversing the test condition and using 'buffer_count++; continue'
> +static ssize_t
> +hwicap_read(struct file *file, char *buf, size_t count, loff_t *ppos)
> +{
> + struct hwicap_drvdata *drvdata = file->private_data;
> + ssize_t bytes_to_read = 0;
> + u32 *kbuf;
> + u32 words;
> + u32 bytes_remaining;
> + int status;
> +
> + if (drvdata->is_accessing)
> + return -EBUSY;
> +
> + drvdata->is_accessing = 1;
Race condition, you need to use a semaphore. Otherwise it is possible
to get two processes (or even two threads of the same process) in the
read() hook.
> +static int hwicap_open(struct inode *inode, struct file *file)
> +{
> + struct hwicap_drvdata *drvdata;
> + int status;
> +
> + drvdata = container_of(inode->i_cdev, struct hwicap_drvdata, cdev);
> + if (drvdata->is_open)
> + return -EBUSY;
> +
> + drvdata->is_open = 1;
Also a race condition. Use a semaphore.
Also, this isn't sufficient to prevent 2 processes from having the
device open. If a process has already opened it and then calls
fork(), then *both* processes will have it opened even though the open
fop was only called once. (It might not matter for this particular
driver as the use case is limited; but it is something you should be
aware of.)
> +static int __devinit hwicap_setup(struct device *dev, int id,
> + const struct resource *regs_res,
> + const struct hwicap_driver_config *config,
> + const struct config_registers *config_regs)
> +{
> + dev_t devt;
> + struct hwicap_drvdata *drvdata = NULL;
> + int retval = 0;
> +
> + dev_info(dev, "Xilinx icap port driver\n");
> +
> + if (id < 0) {
> + for (id = 0; id < HWICAP_DEVICES; id++)
> + if (!probed_devices[id])
> + break;
> + }
> + if (id < 0 || id >= HWICAP_DEVICES) {
> + dev_err(dev, "%s%i too large\n", DRIVER_NAME, id);
> + return -EINVAL;
> + }
> + if (probed_devices[id]) {
> + dev_err(dev, "cannot assign to %s%i; it is already in use\n",
> + DRIVER_NAME, id);
> + return -EBUSY;
> + }
> +
> + probed_devices[id] = 1;
Hmmm, I'm not thrilled with the fixed array of HWICAP devices. That
sort of thing just ends up causing headaches down the road. Can the
driver just allocate a new structure and the next available ID at
probe time? (I hold my nose every time I write something like the
above because I know I'm going to regret it later). sysfs/udev can
provide details about which one is which.
> +
> +static int __devexit hwicap_remove(struct device *dev)
> +{
> + struct hwicap_drvdata *drvdata;
> +
> + drvdata = (struct hwicap_drvdata *)dev_get_drvdata(dev);
> +
> + if (drvdata) {
if (!drvdata)
return 0;
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Kernel oops while duming user core.
From: Scott Wood @ 2008-01-31 20:16 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03EE47A4@ismail.innsys.innovsys.com>
On Thu, Jan 31, 2008 at 11:40:04AM -0600, Rune Torgersen wrote:
> Unable to handle kernel paging request for data at address 0x48024000
> Faulting instruction address: 0xc000f0a0
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT Innovative Systems ApMax
Does it happen without preempt?
> Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7
> drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P)
> NIP: c000f0a0 LR: c0011fec CTR: 00000080
> REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test)
Does it happen without the modules?
> MSR: 00009032 <EE,ME,IR,DR> CR: 24004442 XER: 00000000
> DAR: 48024000, DSISR: 20000000
Hmm, this doesn't look like a valid DSISR, so I'm guessing this was a TLB
miss that got redirected to DataAccess (or is there something that causes
DSRISR[2] to be set on 8280? I didn't see anything in the manual...).
However, SRR1 in that case seems to indicate a store, which dcbst shouldn't
generate (except on 8xx, according to the comment in update_mmu_cache).
Do you have a simple test case that we could try to reproduce? I tried a
simple core dump on an 8280, and it worked.
Failing that, I'd add code to the page fault handler to dump what is (or
isn't) supposed to be mapped at the faulting address, and something to track
which (if any) TLB miss exception it came through.
-Scott
^ permalink raw reply
* RE: Kernel oops while duming user core.
From: Rune Torgersen @ 2008-01-31 20:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <20080131201601.GA10501@loki.buserror.net>
Scott Wood wrote:
> Does it happen without preempt?
Will try shortly, just updated my git to HEAD of Linus's tree
>=20
>> Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7
>> drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P)
>> NIP: c000f0a0 LR: c0011fec CTR: 00000080
>> REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test)
>=20
> Does it happen without the modules?
Cannot test without most of them.
> Do you have a simple test case that we could try to
> reproduce? I tried a
> simple core dump on an 8280, and it worked.
I do not have a testcase, except a app for our board that does this
reliably after about 10 seconds.
> Failing that, I'd add code to the page fault handler to dump what is
> (or isn't) supposed to be mapped at the faulting address, and
> something to track which (if any) TLB miss exception it came through.
I can test code.
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Brian Waite @ 2008-01-31 20:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <E83C3B2F-0FC4-4248-B718-0C45B56E969A@kernel.crashing.org>
On Friday 25 January 2008, Kumar Gala wrote:
> Just a reminder that the plan is to remove arch/ppc this summer (June
> 2008). The following boards still existing over in arch/ppc. Some of
> them have been ported over to arch/powerpc. If you care about one of
> these boards and its not ported speak up (it helps if you have access
> to the board). Also, if you know a given board is free to die of
> bitrot let us know so we know not to worry about it:
>
> PREP
> PQ2ADS
> TQM8260
> CPCI690
> EV64260
> CHESTNUT
> LOPEC
> KATANA
> HDPU
HDPU can die. The company is not maintaining the platform anymore.
Thanks
Brian
^ permalink raw reply
* RE: Kernel oops while duming user core.
From: Rune Torgersen @ 2008-01-31 20:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <20080131201601.GA10501@loki.buserror.net>
Scott Wood wrote:
> Does it happen without preempt?
Yes
^ permalink raw reply
* Re: Kernel oops while duming user core.
From: Nathan Lynch @ 2008-01-31 20:41 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080131201601.GA10501@loki.buserror.net>
Scott Wood wrote:
> On Thu, Jan 31, 2008 at 11:40:04AM -0600, Rune Torgersen wrote:
> > Unable to handle kernel paging request for data at address 0x48024000
> > Faulting instruction address: 0xc000f0a0
> > Oops: Kernel access of bad area, sig: 11 [#1]
> > PREEMPT Innovative Systems ApMax
>
> Does it happen without preempt?
>
> > Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7
> > drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P)
> > NIP: c000f0a0 LR: c0011fec CTR: 00000080
> > REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test)
>
> Does it happen without the modules?
I doubt the modules are the problem; there was a practically identical
report from someone with an untainted 2.6.24-rc kernel a few weeks ago
(see my first reply to Rune).
>
> > MSR: 00009032 <EE,ME,IR,DR> CR: 24004442 XER: 00000000
> > DAR: 48024000, DSISR: 20000000
>
> Hmm, this doesn't look like a valid DSISR, so I'm guessing this was a TLB
> miss that got redirected to DataAccess (or is there something that causes
> DSRISR[2] to be set on 8280? I didn't see anything in the manual...).
> However, SRR1 in that case seems to indicate a store, which dcbst shouldn't
> generate (except on 8xx, according to the comment in update_mmu_cache).
>
> Do you have a simple test case that we could try to reproduce? I tried a
> simple core dump on an 8280, and it worked.
Is the crashing program multithreaded? The first report had firefox
triggering the oops.
^ permalink raw reply
* RE: Kernel oops while duming user core.
From: Rune Torgersen @ 2008-01-31 20:45 UTC (permalink / raw)
To: Nathan Lynch, Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080131204158.GV14201@localdomain>
Nathan Lynch wrote:
> Scott Wood wrote:
>> Do you have a simple test case that we could try to reproduce? I
>> tried a simple core dump on an 8280, and it worked.
>=20
> Is the crashing program multithreaded? The first report had firefox
> triggering the oops.
The crashing program has 10 threads. (NPTL pthreads, glibc-2.5, gcc
4.1.2)
^ permalink raw reply
* Re: Kernel oops while duming user core.
From: Scott Wood @ 2008-01-31 20:55 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20080131204158.GV14201@localdomain>
Nathan Lynch wrote:
> I doubt the modules are the problem; there was a practically identical
> report from someone with an untainted 2.6.24-rc kernel a few weeks ago
> (see my first reply to Rune).
I didn't think they were; I was just trying to eliminate the low hanging
fruit and get a simpler testcase. :-)
>> Do you have a simple test case that we could try to reproduce? I tried a
>> simple core dump on an 8280, and it worked.
>
> Is the crashing program multithreaded? The first report had firefox
> triggering the oops.
OK, I've got a test program that triggers it now. I'll see if I can
figure out what's going on.
-Scott
^ permalink raw reply
* [PATCH] [POWERPC] Remove dead code at KernelAltiVec
From: Dale Farnsworth @ 2008-01-31 21:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
This code doesn't seem to be referenced anywhere.
arch/powerpc/kernel/head_32.S | 17 -----------------
arch/ppc/kernel/head.S | 17 -----------------
2 files changed, 0 insertions(+), 34 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 0f4fac5..c16d135 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -763,23 +763,6 @@ load_up_altivec:
b fast_exception_return
/*
- * AltiVec unavailable trap from kernel - print a message, but let
- * the task use AltiVec in the kernel until it returns to user mode.
- */
-KernelAltiVec:
- lwz r3,_MSR(r1)
- oris r3,r3,MSR_VEC@h
- stw r3,_MSR(r1) /* enable use of AltiVec after return */
- lis r3,87f@h
- ori r3,r3,87f@l
- mr r4,r2 /* current */
- lwz r5,_NIP(r1)
- bl printk
- b ret_from_except
-87: .string "AltiVec used in kernel (task=%p, pc=%x) \n"
- .align 4,0
-
-/*
* giveup_altivec(tsk)
* Disable AltiVec for the task given as the argument,
* and save the AltiVec registers in its thread_struct.
diff --git a/arch/ppc/kernel/head.S b/arch/ppc/kernel/head.S
index 1b0ec72..e7e642b 100644
--- a/arch/ppc/kernel/head.S
+++ b/arch/ppc/kernel/head.S
@@ -701,23 +701,6 @@ load_up_altivec:
b fast_exception_return
/*
- * AltiVec unavailable trap from kernel - print a message, but let
- * the task use AltiVec in the kernel until it returns to user mode.
- */
-KernelAltiVec:
- lwz r3,_MSR(r1)
- oris r3,r3,MSR_VEC@h
- stw r3,_MSR(r1) /* enable use of AltiVec after return */
- lis r3,87f@h
- ori r3,r3,87f@l
- mr r4,r2 /* current */
- lwz r5,_NIP(r1)
- bl printk
- b ret_from_except
-87: .string "AltiVec used in kernel (task=%p, pc=%x) \n"
- .align 4,0
-
-/*
* giveup_altivec(tsk)
* Disable AltiVec for the task given as the argument,
* and save the AltiVec registers in its thread_struct.
^ permalink raw reply related
* Re: [RFC] [POWERPC] bootwrapper: build multiple cuImages
From: Geoff Levand @ 2008-01-31 21:12 UTC (permalink / raw)
To: Grant Likely; +Cc: scottwood, linuxppc-dev
In-Reply-To: <20080131003347.5779.96112.stgit@trillian.secretlab.ca>
On 01/30/2008 04:34 PM, Grant Likely wrote:
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
...
> $(obj)/zImage.ps3: vmlinux $(wrapper) $(wrapperbits) $(srctree)/$(src)/dts/ps3.dts
Seems like this could use $(dtstree).
> $(STRIP) -s -R .comment $< -o vmlinux.strip
> - $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,)
> + $(call cmd,wrap,ps3,$(dtstree)/ps3.dts,,)
>
> $(obj)/zImage.initrd.ps3: vmlinux $(wrapper) $(wrapperbits) $(srctree)/$(src)/dts/ps3.dts $(obj)/ramdisk.image.gz
Same here.
> - $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,$(obj)/ramdisk.image.gz)
> + $(call cmd,wrap,ps3,$(dtstree)/ps3.dts,,$(obj)/ramdisk.image.gz)
^ permalink raw reply
* Re: Kernel oops while duming user core.
From: Scott Wood @ 2008-01-31 21:58 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <47A235AD.9050107@freescale.com>
Scott Wood wrote:
> Nathan Lynch wrote:
>> Is the crashing program multithreaded? The first report had firefox
>> triggering the oops.
>
> OK, I've got a test program that triggers it now. I'll see if I can
> figure out what's going on.
The problem seems to be that update_mmu_cache() is called on a guard
page with no access rights.
Changing update_mmu_cache() to always call flush_dcache_icache_page()
fixes it, though a better performing fix would probably be to add an
exception table entry for the dcbst.
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] Add RapidIO node into MPC8641HPCN dts file
From: Jon Loeliger @ 2008-01-31 16:28 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev
In-Reply-To: <12017656032841-git-send-email-wei.zhang@freescale.com>
Zhang Wei wrote:
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> index 556a9ca..1a0fce5 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -25,6 +25,7 @@
> serial1 = &serial1;
> pci0 = &pci0;
> pci1 = &pci1;
> + rapidio0 = &rapidio0;
> };
>
> cpus {
> @@ -499,4 +500,16 @@
> 0 00100000>;
> };
> };
> +
> + rapidio0: rapidio@f80c0000 {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + compatible = "fsl,rapidio-delta";
> + reg = <f80c0000 20000>;
> + ranges = <0 0 c0000000 0 20000000>;
> + interrupt-parent = <&mpic>;
> + /* err_irq bell_outb_irq bell_inb_irq
> + msg1_tx_irq msg1_rx_irq msg2_tx_irq msg2_rx_irq */
> + interrupts = <30 2 31 2 32 2 35 2 36 2 37 2 38 2>;
> + };
> };
The 8641 DTS file has been converted to /dts-v1/ format now.
Please rewrite this patch with explicit hex numbers for
addresses, even if 0x0, and decimal for IRQs.
Thanks,
jdl
^ permalink raw reply
* RE: Kernel oops while duming user core.
From: Rune Torgersen @ 2008-01-31 22:10 UTC (permalink / raw)
To: Scott Wood, Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <47A24480.8060103@freescale.com>
Scott Wood wrote:
> Scott Wood wrote:
>> Nathan Lynch wrote:
>>> Is the crashing program multithreaded? The first report had firefox
>>> triggering the oops.
>>=20
>> OK, I've got a test program that triggers it now. I'll see if I can
>> figure out what's going on.
>=20
> The problem seems to be that update_mmu_cache() is called on a guard
> page with no access rights.=20
>=20
> Changing update_mmu_cache() to always call flush_dcache_icache_page()
> fixes it, though a better performing fix would probably be to add an
> exception table entry for the dcbst.
I can confirm that this seems to fix it.
^ permalink raw reply
* RE: [PATCH] [POWERPC] Xilinx: hwicap driver
From: Stephen Neuendorffer @ 2008-01-31 22:39 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801311158u470981e9o6862767dea881f4b@mail.gmail.com>
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
> Sent: Thursday, January 31, 2008 11:59 AM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org; jacmet@sunsite.dk
> Subject: Re: [PATCH] [POWERPC] Xilinx: hwicap driver
>=20
> On 1/31/08, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
wrote:
> > This includes code for new fifo-based xps_hwicap in addition to the
> > older opb_hwicap, which has a significantly different interface.
The
> > common code between the two drivers is largely shared.
> >
> > Significant differences exists between this driver and what is
> > supported in the EDK drivers. In particular, most of the
> > architecture-specific code for reconfiguring individual FPGA
resources
> > has been removed. This functionality is likely better provided in a
> > user-space support library. In addition, read and write access is
> > supported. In addition, although the xps_hwicap cores support
> > interrupt-driver mode, this driver only supports polled operation,
in
> > order to make the code simpler, and since the interrupt processing
> > overhead is likely to slow down the throughput under Linux.
> >
> > Signed-off-by: Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com>
>=20
> Comments below...
>=20
> Also, I'm not sure if drivers/char/xilinx_hwicap is the best place for
> this driver. drivers/misc/ might be better (but I'm not sure; poll
> other people on this)
I don't have strong opinions on this... If someone wants to say it
should be in drivers/misc, I'm more than happy to move it. However, it
doesn't seem like there is anything else that is a pure character device
there.
> Finally, buffer_icap and fifo_icap are not huge blocks of code. Will
> they be used by any other drivers? Can they be rolled into the
> xilinx_hwicap.c file?
They're not huge, but they are really independent from eachother.
Furthermore, I expect that future cores will have DMA capability to
increase bandwidth, which would result in a dma_icap file.
> Style comment: reverse the condition and bail with return -EINVAL at
> the test point. It will simplify the code and better match with
> common practice in the kernel.
good point, I'll fix them all.
> > +static ssize_t
> > +hwicap_read(struct file *file, char *buf, size_t count, loff_t
*ppos)
> > +{
> > + struct hwicap_drvdata *drvdata =3D file->private_data;
> > + ssize_t bytes_to_read =3D 0;
> > + u32 *kbuf;
> > + u32 words;
> > + u32 bytes_remaining;
> > + int status;
> > +
> > + if (drvdata->is_accessing)
> > + return -EBUSY;
> > +
> > + drvdata->is_accessing =3D 1;
>=20
> Race condition, you need to use a semaphore. Otherwise it is possible
> to get two processes (or even two threads of the same process) in the
> read() hook.
good point. On thinking about this more, does the whole function need
to be in a semaphore to protect against PREEMPT kernels?
> > +static int hwicap_open(struct inode *inode, struct file *file)
> > +{
> > + struct hwicap_drvdata *drvdata;
> > + int status;
> > +
> > + drvdata =3D container_of(inode->i_cdev, struct =
hwicap_drvdata,
cdev);
> > + if (drvdata->is_open)
> > + return -EBUSY;
> > +
> > + drvdata->is_open =3D 1;
>=20
> Also a race condition. Use a semaphore.
>=20
> Also, this isn't sufficient to prevent 2 processes from having the
> device open. If a process has already opened it and then calls
> fork(), then *both* processes will have it opened even though the open
> fop was only called once. (It might not matter for this particular
> driver as the use case is limited; but it is something you should be
> aware of.)
The fork I'm somewhat less concerned about, I think. If someone calls
fork(), then it's up to them to synchronize their code correctly and
only call close() once. The only reason to block the open is that it's
the simplest way to keep track of the state between reads and writes.
> > +static int __devinit hwicap_setup(struct device *dev, int id,
> > + const struct resource *regs_res,
> > + const struct hwicap_driver_config *config,
> > + const struct config_registers *config_regs)
> > +{
> > + dev_t devt;
> > + struct hwicap_drvdata *drvdata =3D NULL;
> > + int retval =3D 0;
> > +
> > + dev_info(dev, "Xilinx icap port driver\n");
> > +
> > + if (id < 0) {
> > + for (id =3D 0; id < HWICAP_DEVICES; id++)
> > + if (!probed_devices[id])
> > + break;
> > + }
> > + if (id < 0 || id >=3D HWICAP_DEVICES) {
> > + dev_err(dev, "%s%i too large\n", DRIVER_NAME, id);
> > + return -EINVAL;
> > + }
> > + if (probed_devices[id]) {
> > + dev_err(dev, "cannot assign to %s%i; it is already
in use\n",
> > + DRIVER_NAME, id);
> > + return -EBUSY;
> > + }
> > +
> > + probed_devices[id] =3D 1;
>=20
> Hmmm, I'm not thrilled with the fixed array of HWICAP devices. That
> sort of thing just ends up causing headaches down the road. Can the
> driver just allocate a new structure and the next available ID at
> probe time? (I hold my nose every time I write something like the
> above because I know I'm going to regret it later). sysfs/udev can
> provide details about which one is which.
Can you suggest a good driver to crib?
> Cheers,
> g.
Thanks!
^ 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