* Re: nfs booting PS3, mount failed.
From: Geoff Levand @ 2009-02-18 0:31 UTC (permalink / raw)
To: gt bradley; +Cc: linuxppc-dev
In-Reply-To: <499B544D.3020704@am.sony.com>
On 02/17/2009 04:20 PM, Geoff Levand wrote:
> Another thing to try is to use a 'rescue' disk/mode to copy the files.
> Most distros have them. Fedora has a rescue mode in their installer:
>
> http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/ppc/iso/Fedora-10-ppc-netinst.iso
>
> Just select 'rescue' instead of 'install', or you can add
> these to the boot options: 'text rescue video=720p'.
I forgot to mention an important point when using a rescue disk.
Most will mount all the runtime directories like /sys, /dev, /proc,
etc. onto the HD file system. Those directories should not be
mounted the when you make the HD root FS copy.
Either choose the rescue option to not mount the HD file system,
and mount it yourself later, or unmount all those directories.
Just use the 'mount' command to see what has been mounted on the
HD's root FS.
-Geoff
^ permalink raw reply
* Re: nfs booting PS3, mount failed.
From: Geoff Levand @ 2009-02-18 0:20 UTC (permalink / raw)
To: gt bradley; +Cc: linuxppc-dev
In-Reply-To: <719599.32884.qm@web56204.mail.re3.yahoo.com>
On 02/16/2009 09:22 PM, gt bradley wrote:
> I'm trying to set up my PS3 to netboot (with an nfsroot).
>
> I'm using instructions at
> http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-howto/ps3-nfs-root-howto.txt
>
> I've passed section 3 (using tftp) to verify network /dhcp etc. (i.e.
> I'm able to tftp-get a file to ps3 from kboot's ash shell (busybox).
>
> i'm trying to mount the nfs server as per section 4. with
>
> ~# mount -t nfs -o nolock 192.168.99.1:/target /mnt/remote
>
> I get the following error message:
> mount: mounting 192.168.99.1:/target on /mnt/remote failed
>
> if I boot the PS3 from the HD, then I am able to mount the nfs directory.
> Using wireshark, I can see the initial dhcp traffic, (and when present the tftp traffic).
> the mount command doesn't open a network connection to the server,
> So I have pretty much ruled out server
> configuration.
>
> running "strings" on the decompressed kboot image yeilds serveral nfs symbols, so it
> appears to still support nfs mounting. (using version kboot-20080609.bld from geoff's dir at kernel.org)
I have sometimes seen nfs problems with kboot. You could you
try petitboot. Get the latest 'experimental' one from here:
http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-petitboot/
Another thing to try is to use a 'rescue' disk/mode to copy the files.
Most distros have them. Fedora has a rescue mode in their installer:
http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/ppc/iso/Fedora-10-ppc-netinst.iso
Just select 'rescue' instead of 'install', or you can add
these to the boot options: 'text rescue video=720p'.
You don't need kboot/petitboot to do nfs. To load the kernel
they just need to do tftp.
-Geoff
^ permalink raw reply
* 答复: [PATCH] fix the interrupt loss problem on powerpc IPIC (2.6.25-2.6.28)
From: dayu @ 2009-02-18 2:12 UTC (permalink / raw)
To: leoli, galak; +Cc: linuxppc-dev, linux-kernel
From: Da Yu <dayu@datangmobile.cn>
Date: Wed, 18 Feb 2009 19:58:20 +0800
Subject: [PATCH] fix the interrupt loss problem on powerpc IPIC =
(2.6.25-2.6.28)
Signed-off-by: Da Yu <dayu@datangmobile.cn>
---
--- a/arch/powerpc/sysdev/ipic.c 2009-02-18 09:47:04.000000000 +0800
+++ b/arch/powerpc/sysdev/ipic.c 2009-02-18 09:46:34.000000000 +0800
@@ -568,8 +568,7 @@ static void ipic_ack_irq(unsigned int vi
spin_lock_irqsave(&ipic_lock, flags);
- temp =3D ipic_read(ipic->regs, ipic_info[src].ack);
- temp |=3D (1 << (31 - ipic_info[src].bit));
+ temp =3D 1 << (31 - ipic_info[src].bit);
ipic_write(ipic->regs, ipic_info[src].ack, temp);
/* mb() can't guarantee that ack is finished. But it does finish
@@ -592,8 +591,7 @@ static void ipic_mask_irq_and_ack(unsign
temp &=3D ~(1 << (31 - ipic_info[src].bit));
ipic_write(ipic->regs, ipic_info[src].mask, temp);
- temp =3D ipic_read(ipic->regs, ipic_info[src].ack);
- temp |=3D (1 << (31 - ipic_info[src].bit));
+ temp =3D 1 << (31 - ipic_info[src].bit);
ipic_write(ipic->regs, ipic_info[src].ack, temp);
/* mb() can't guarantee that ack is finished. But it does finish
=20
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: Li Yang [mailto:leoli@freescale.com]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C217=C8=D5 22:38
=CA=D5=BC=FE=C8=CB: Kumar Gala
=B3=AD=CB=CD: =F3=CE=D3=ED; linux-kernel@vger.kernel.org; =
linuxppc-dev@ozlabs.org
=D6=F7=CC=E2: Re: [PATCH] fix the interrupt loss problem on powerpc IPIC =
(2.6.23)
On Tue, Feb 17, 2009 at 10:12 PM, Kumar Gala <galak@kernel.crashing.org> =
wrote:
>
> On Feb 17, 2009, at 6:44 AM, <dayu@datangmobile.cn>=20
> <dayu@datangmobile.cn>
> wrote:
>
>> From: Da Yu <dayu@datangmobile.cn>
>> Date: Tue, 17 Feb 2009 19:58:20 +0800
>> Subject: [PATCH] fix the interrupt loss problem on powerpc IPIC=20
>> (2.6.23)
>>
>> Signed-off-by: Da Yu <dayu@datangmobile.cn>
>> ---
>
> Please provide a bit more description as to why this fixes the issue.
The pending register is write 1 clear. If there are more than one =
external interrupts pending at the same time, acking the first interrupt =
will also clear other interrupt pending bits. That will cause loss of =
interrupt.
- Leo
^ permalink raw reply
* [PATCH] fix the interrupt loss problem on powerpc IPIC (2.6.25-2.6.28)
From: dayu @ 2009-02-18 2:16 UTC (permalink / raw)
To: leoli, galak; +Cc: linuxppc-dev, linux-kernel
From: Da Yu <dayu@datangmobile.cn>
Date: Wed, 18 Feb 2009 19:58:20 +0800
Subject: [PATCH] fix the interrupt loss problem on powerpc IPIC =
(2.6.25-2.6.28)
Signed-off-by: Da Yu <dayu@datangmobile.cn>
---
--- a/arch/powerpc/sysdev/ipic.c 2009-02-18 09:47:04.000000000 +0800
+++ b/arch/powerpc/sysdev/ipic.c 2009-02-18 09:46:34.000000000 +0800
@@ -568,8 +568,7 @@ static void ipic_ack_irq(unsigned int vi
spin_lock_irqsave(&ipic_lock, flags);
- temp =3D ipic_read(ipic->regs, ipic_info[src].ack);
- temp |=3D (1 << (31 - ipic_info[src].bit));
+ temp =3D 1 << (31 - ipic_info[src].bit);
ipic_write(ipic->regs, ipic_info[src].ack, temp);
/* mb() can't guarantee that ack is finished. But it does finish
@@ -592,8 +591,7 @@ static void ipic_mask_irq_and_ack(unsign
temp &=3D ~(1 << (31 - ipic_info[src].bit));
ipic_write(ipic->regs, ipic_info[src].mask, temp);
- temp =3D ipic_read(ipic->regs, ipic_info[src].ack);
- temp |=3D (1 << (31 - ipic_info[src].bit));
+ temp =3D 1 << (31 - ipic_info[src].bit);
ipic_write(ipic->regs, ipic_info[src].ack, temp);
/* mb() can't guarantee that ack is finished. But it does finish
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: Li Yang [mailto:leoli@freescale.com]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C217=C8=D5 22:38
=CA=D5=BC=FE=C8=CB: Kumar Gala
=B3=AD=CB=CD: =F3=CE=D3=ED; linux-kernel@vger.kernel.org; =
linuxppc-dev@ozlabs.org
=D6=F7=CC=E2: Re: [PATCH] fix the interrupt loss problem on powerpc IPIC =
(2.6.23)
On Tue, Feb 17, 2009 at 10:12 PM, Kumar Gala <galak@kernel.crashing.org> =
wrote:
>
> On Feb 17, 2009, at 6:44 AM, <dayu@datangmobile.cn>=20
> <dayu@datangmobile.cn>
> wrote:
>
>> From: Da Yu <dayu@datangmobile.cn>
>> Date: Tue, 17 Feb 2009 19:58:20 +0800
>> Subject: [PATCH] fix the interrupt loss problem on powerpc IPIC=20
>> (2.6.23)
>>
>> Signed-off-by: Da Yu <dayu@datangmobile.cn>
>> ---
>
> Please provide a bit more description as to why this fixes the issue.
The pending register is write 1 clear. If there are more than one =
external interrupts pending at the same time, acking the first interrupt =
will also clear other interrupt pending bits. That will cause loss of =
interrupt.
- Leo
^ permalink raw reply
* Re: Please pull from 'next' branch
From: Benjamin Herrenschmidt @ 2009-02-18 2:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0902171551460.23647@blarg.am.freescale.net>
> I'd also like the opcode patch to go in since several patches depend on
> that (doorbell, tlbilx). If you want to ack the patch I can put it into
> my next branch for you.
It's already in my test branch, which for some reason I forgot to push
out... Doing some updates now, you'll get it.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] fix the interrupt loss problem on powerpc IPIC (2.6.25-2.6.28)
From: Olof Johansson @ 2009-02-18 2:43 UTC (permalink / raw)
To: dayu; +Cc: linuxppc-dev, leoli, linux-kernel
In-Reply-To: <D728AD1FA2543948B89DE29C5BF4CD0716AC37FD@bjmail1.bj.datangmobile.com>
On Wed, Feb 18, 2009 at 10:16:07AM +0800, dayu@datangmobile.cn wrote:
> From: Da Yu <dayu@datangmobile.cn>
> Date: Wed, 18 Feb 2009 19:58:20 +0800
> Subject: [PATCH] fix the interrupt loss problem on powerpc IPIC (2.6.25-2.6.28)
>
> Signed-off-by: Da Yu <dayu@datangmobile.cn>
Still no proper explanation in the patch.
Also, with this change, is 'temp' really needed, or can you just pass in the
mask by hand?
-Olof
> ---
>
> --- a/arch/powerpc/sysdev/ipic.c 2009-02-18 09:47:04.000000000 +0800
> +++ b/arch/powerpc/sysdev/ipic.c 2009-02-18 09:46:34.000000000 +0800
> @@ -568,8 +568,7 @@ static void ipic_ack_irq(unsigned int vi
>
> spin_lock_irqsave(&ipic_lock, flags);
>
> - temp = ipic_read(ipic->regs, ipic_info[src].ack);
> - temp |= (1 << (31 - ipic_info[src].bit));
> + temp = 1 << (31 - ipic_info[src].bit);
> ipic_write(ipic->regs, ipic_info[src].ack, temp);
>
> /* mb() can't guarantee that ack is finished. But it does finish
^ permalink raw reply
* Re: Please pull from 'next' branch
From: Kumar Gala @ 2009-02-18 3:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1234923772.14060.322.camel@pasglop>
On Feb 17, 2009, at 8:22 PM, Benjamin Herrenschmidt wrote:
>
>> I'd also like the opcode patch to go in since several patches
>> depend on
>> that (doorbell, tlbilx). If you want to ack the patch I can put it
>> into
>> my next branch for you.
>
> It's already in my test branch, which for some reason I forgot to push
> out... Doing some updates now, you'll get it.
ok. I was hoping for that one patch to migrate from test to next ;)
- k
^ permalink raw reply
* Re: Please pull from 'next' branch
From: Benjamin Herrenschmidt @ 2009-02-18 3:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <46F4AA25-B5D1-42C1-B4EE-3EDE35D99782@kernel.crashing.org>
On Tue, 2009-02-17 at 21:04 -0600, Kumar Gala wrote:
> ok. I was hoping for that one patch to migrate from test to next ;)
>
Just pushed out to test, it has some collisions with merge and with
the ftrace stuff that I fixed up. I'll move it to next tomorrow, once
we've sorted out what tree the ftrace stuff is going through.
Ben.
^ permalink raw reply
* [PATCH] Enable hashdist by default on PowerPC
From: Anton Blanchard @ 2009-02-18 5:11 UTC (permalink / raw)
To: linuxppc-dev
On PowerPC we allocate large boot time hashes on node 0. This leads to
an imbalance in the free memory, for example on a 64GB box (4 x 16GB nodes):
Free memory:
Node 0: 97.03%
Node 1: 98.54%
Node 2: 98.42%
Node 3: 98.53%
If we switch to using vmalloc (like ia64 and x86-64) things are more
balanced:
Free memory:
Node 0: 97.53%
Node 1: 98.35%
Node 2: 98.33%
Node 3: 98.33%
For many HPC applications we are limited by the free available memory on
the smallest node, so even though the same amount of memory is used the
better balancing helps.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
index 95837bf..c0c63ee 100644
--- a/include/linux/bootmem.h
+++ b/include/linux/bootmem.h
@@ -145,9 +145,10 @@ extern void *alloc_large_system_hash(const char *tablename,
#define HASH_EARLY 0x00000001 /* Allocating during early boot? */
/* Only NUMA needs hash distribution.
- * IA64 and x86_64 have sufficient vmalloc space.
+ * IA64, x86_64 and PowerPC have sufficient vmalloc space.
*/
-#if defined(CONFIG_NUMA) && (defined(CONFIG_IA64) || defined(CONFIG_X86_64))
+#if defined(CONFIG_NUMA) && (defined(CONFIG_IA64) || defined(CONFIG_X86_64) || \
+ defined(CONFIG_PPC64))
#define HASHDIST_DEFAULT 1
#else
#define HASHDIST_DEFAULT 0
^ permalink raw reply related
* Re: [PATCH] Enable hashdist by default on PowerPC
From: Benjamin Herrenschmidt @ 2009-02-18 5:41 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20090218051112.GA32195@kryten>
> For many HPC applications we are limited by the free available memory on
> the smallest node, so even though the same amount of memory is used the
> better balancing helps.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
You have numbers ? :-) I'm asking mostly because I've been wondering
whether it offsets the 16M pages vs. 4K or 64K pages in term of TLB/ERAT
impact.
Cheers,
Ben.
> diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
> index 95837bf..c0c63ee 100644
> --- a/include/linux/bootmem.h
> +++ b/include/linux/bootmem.h
> @@ -145,9 +145,10 @@ extern void *alloc_large_system_hash(const char *tablename,
> #define HASH_EARLY 0x00000001 /* Allocating during early boot? */
>
> /* Only NUMA needs hash distribution.
> - * IA64 and x86_64 have sufficient vmalloc space.
> + * IA64, x86_64 and PowerPC have sufficient vmalloc space.
> */
> -#if defined(CONFIG_NUMA) && (defined(CONFIG_IA64) || defined(CONFIG_X86_64))
> +#if defined(CONFIG_NUMA) && (defined(CONFIG_IA64) || defined(CONFIG_X86_64) || \
> + defined(CONFIG_PPC64))
> #define HASHDIST_DEFAULT 1
> #else
> #define HASHDIST_DEFAULT 0
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] fix the interrupt loss problem on powerpc IPIC(2.6.25-2.6.28)
From: dayu @ 2009-02-18 5:47 UTC (permalink / raw)
To: olof; +Cc: linuxppc-dev, leoli, linux-kernel
renew description in the patch, with this change the 'temp' is still =
used to make code clear.
___________________________________________
From: Da Yu <dayu@datangmobile.cn>
Date: Wed, 18 Feb 2009 19:58:20 +0800
Subject: [PATCH] fix the interrupt loss problem on powerpc IPIC =
(2.6.25-2.6.28)
Description: The interrupt pending register is write 1 clear. If there =
are more than one external interrupts pending at the same time, acking =
the first interrupt by reading pending register then OR the =
corresponding bit and write back to pending register will also clear =
other interrupt pending bits. That will cause loss of interrupt.
Signed-off-by: Da Yu <dayu@datangmobile.cn>
---
--- a/arch/powerpc/sysdev/ipic.c 2009-02-18 09:47:04.000000000 +0800
+++ b/arch/powerpc/sysdev/ipic.c 2009-02-18 09:46:34.000000000 +0800
@@ -568,8 +568,7 @@ static void ipic_ack_irq(unsigned int vi
spin_lock_irqsave(&ipic_lock, flags);
- temp =3D ipic_read(ipic->regs, ipic_info[src].ack);
- temp |=3D (1 << (31 - ipic_info[src].bit));
+ temp =3D 1 << (31 - ipic_info[src].bit);
ipic_write(ipic->regs, ipic_info[src].ack, temp);
/* mb() can't guarantee that ack is finished. But it does finish
@@ -592,8 +591,7 @@ static void ipic_mask_irq_and_ack(unsign
temp &=3D ~(1 << (31 - ipic_info[src].bit));
ipic_write(ipic->regs, ipic_info[src].mask, temp);
- temp =3D ipic_read(ipic->regs, ipic_info[src].ack);
- temp |=3D (1 << (31 - ipic_info[src].bit));
+ temp =3D 1 << (31 - ipic_info[src].bit);
ipic_write(ipic->regs, ipic_info[src].ack, temp);
/* mb() can't guarantee that ack is finished. But it does finish
=20
=20
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: Olof Johansson [mailto:olof@lixom.net]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA2=D4=C218=C8=D5 10:43
=CA=D5=BC=FE=C8=CB: =F3=CE=D3=ED
=B3=AD=CB=CD: leoli@freescale.com; galak@kernel.crashing.org; =
linuxppc-dev@ozlabs.org; linux-kernel@vger.kernel.org
=D6=F7=CC=E2: Re: [PATCH] fix the interrupt loss problem on powerpc =
IPIC(2.6.25-2.6.28)
On Wed, Feb 18, 2009 at 10:16:07AM +0800, dayu@datangmobile.cn wrote:
> From: Da Yu <dayu@datangmobile.cn>
> Date: Wed, 18 Feb 2009 19:58:20 +0800
> Subject: [PATCH] fix the interrupt loss problem on powerpc IPIC=20
> (2.6.25-2.6.28)
>=20
> Signed-off-by: Da Yu <dayu@datangmobile.cn>
Still no proper explanation in the patch.
Also, with this change, is 'temp' really needed, or can you just pass in =
the mask by hand?
-Olof
> ---
>=20
> --- a/arch/powerpc/sysdev/ipic.c 2009-02-18 09:47:04.000000000 +0800
> +++ b/arch/powerpc/sysdev/ipic.c 2009-02-18 09:46:34.000000000 +0800
> @@ -568,8 +568,7 @@ static void ipic_ack_irq(unsigned int vi
>=20
> spin_lock_irqsave(&ipic_lock, flags);
>=20
> - temp =3D ipic_read(ipic->regs, ipic_info[src].ack);
> - temp |=3D (1 << (31 - ipic_info[src].bit));
> + temp =3D 1 << (31 - ipic_info[src].bit);
> ipic_write(ipic->regs, ipic_info[src].ack, temp);
>=20
> /* mb() can't guarantee that ack is finished. But it does finish
^ permalink raw reply
* Re: setup_64.c:450: warning: format '%lx' expects type 'long unsigned int'
From: Benjamin Herrenschmidt @ 2009-02-18 6:03 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <alpine.LRH.2.00.0902171418050.8852@vixen.sonytel.be>
On Tue, 2009-02-17 at 14:21 +0100, Geert Uytterhoeven wrote:
> and ASM_CONST() appends "UL" to the constant.
>
We probably want to add a ASM_ULL_CONST() for that...
Ben.
^ permalink raw reply
* Re: setup_64.c:450: warning: format '%lx' expects type 'long unsigned int'
From: Stephen Rothwell @ 2009-02-18 6:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Geert Uytterhoeven, Linux/PPC, Development
In-Reply-To: <1234937030.14060.442.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
On Wed, 18 Feb 2009 17:03:50 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Tue, 2009-02-17 at 14:21 +0100, Geert Uytterhoeven wrote:
> > and ASM_CONST() appends "UL" to the constant.
> >
> We probably want to add a ASM_ULL_CONST() for that...
Except physaddr_t is sometimes 32 bits and sometime 64 bits in the 32 bit
kernel ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: setup_64.c:450: warning: format '%lx' expects type 'long unsigned int'
From: Benjamin Herrenschmidt @ 2009-02-18 6:18 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Geert Uytterhoeven, Linux/PPC Development
In-Reply-To: <20090218171657.0cf35552.sfr@canb.auug.org.au>
On Wed, 2009-02-18 at 17:16 +1100, Stephen Rothwell wrote:
> On Wed, 18 Feb 2009 17:03:50 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > On Tue, 2009-02-17 at 14:21 +0100, Geert Uytterhoeven wrote:
> > > and ASM_CONST() appends "UL" to the constant.
> > >
> > We probably want to add a ASM_ULL_CONST() for that...
>
> Except physaddr_t is sometimes 32 bits and sometime 64 bits in the 32 bit
> kernel ...
Oh well, one cast that won't go away then.
Ben.
^ permalink raw reply
* Re: [PATCH] Enable hashdist by default on PowerPC
From: Anton Blanchard @ 2009-02-18 6:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1234935667.14060.440.camel@pasglop>
Hi Ben,
> You have numbers ? :-) I'm asking mostly because I've been wondering
> whether it offsets the 16M pages vs. 4K or 64K pages in term of TLB/ERAT
> impact.
The speedup is application dependent. Things like linpack usually
improve when you throw more memmory at them.
The potential slowdown will be in heavy dcache use (eg fileserving). We
originally added the large boot time hash code when we were benchmarking
SPECsfs (an NFS benchmark).
We can go back to the old behaviour with the hashdist=0 boot option, so
it's mostly a question of what the default should be.
Anton
^ permalink raw reply
* Re: [RFC v1] virtio: add virtio-over-PCI driver
From: Rusty Russell @ 2009-02-18 6:43 UTC (permalink / raw)
To: Ira Snyder
Cc: linuxppc-dev, netdev, linux-kernel, Arnd Bergmann,
Jan-Bernd Themann
In-Reply-To: <20090217222425.GA18801@ovro.caltech.edu>
On Wednesday 18 February 2009 08:54:25 Ira Snyder wrote:
> This adds support to Linux for using virtio between two computers linked by
> a PCI interface. This allows the use of virtio_net to create a familiar,
> fast interface for communication. It should be possible to use other virtio
> devices in the future, but this has not been tested.
Hi Ira,
It's only first glance, but this looks sane. Two things on first note:
don't restrict yourself to 32 feature bits (only PCI does this, and they're
going to have to hack when we reach feature 32).
Secondly:
> +You will notice that the algorithm has no way of handling chains that are
> +not exactly the same on the host and guest system. Without setting any of
> +the fancier virtio_net features, this is the case.
Hmm, I think we can do slightly better than this.
How about prepending a 4 byte length on the host buffers? Allows host to
specify length (for host->guest), and guest writes it to allow truncated
buffers on guest->host.
That won't allow you to transfer *more* than one buffersize to the host, but
you could use a different method (perhaps the 4 bytes indicates the *total*
length?).
Do 4-byte DMA's suck for some reason?
Cheers,
Rusty.
^ permalink raw reply
* [PATCH] cpumask: avoid cast-away-const for deprecated cpu_*_map.
From: Rusty Russell @ 2009-02-18 7:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Mike Travis, James Bottomley, linuxppc-dev,
Ivan Kokshaysky, Ingo Molnar
Impact: fix potential (non-x86) SMP boot failure with some gcc versions
The deprecated cpu_*_map are currently #defined to the new cpu_*_mask,
except without the const. Some versions of gcc seem to dislike this,
and I suspect this will break boot for some archs with the "wrong" gcc
version.
So play it safe and use real vars until we kill them all (replacements
are init_*_map(), set_cpu_*() and cpu_*_mask).
PowerPC and Alpha have reported warnings, and James Bottomley
encountered worse: gcc was simply not changing cpu_possible_map,
causing boot failure (fixed by using init_cpu_possible()).
See also:
Alpha gcc 4.2 warning fix:
ee0c468bb151aad23281660152d2894f1e214238
Voyager bug report:
lkml: [PATCH] voyager: fix cpu bootmaps
Message-Id: <1233340317.3248.39.camel@localhost.localdomain>
(Merged without comments in 92ab78315c638515d0e81b0c70b2082f713582d9)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: linuxppc-dev@ozlabs.org
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: James.Bottomley@HansenPartnership.com
Cc: Mike Travis <travis@sgi.com>
---
include/linux/cpumask.h | 14 +++++++++-----
kernel/cpu.c | 10 ++++++++++
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -487,11 +487,15 @@ extern const struct cpumask *const cpu_p
extern const struct cpumask *const cpu_present_mask;
extern const struct cpumask *const cpu_active_mask;
-/* These strip const, as traditionally they weren't const. */
-#define cpu_possible_map (*(cpumask_t *)cpu_possible_mask)
-#define cpu_online_map (*(cpumask_t *)cpu_online_mask)
-#define cpu_present_map (*(cpumask_t *)cpu_present_mask)
-#define cpu_active_map (*(cpumask_t *)cpu_active_mask)
+/* Deprecated: use cpu_*_mask and set_cpu_*(). */
+#define cpu_possible_map (*_cpu_possible_mask_nonconst)
+#define cpu_online_map (*_cpu_online_mask_nonconst)
+#define cpu_present_map (*_cpu_present_mask_nonconst)
+#define cpu_active_map (*_cpu_active_mask_nonconst)
+extern struct cpumask *_cpu_possible_mask_nonconst;
+extern struct cpumask *_cpu_online_mask_nonconst;
+extern struct cpumask *_cpu_present_mask_nonconst;
+extern struct cpumask *_cpu_active_mask_nonconst;
#if NR_CPUS > 1
#define num_online_cpus() cpumask_weight(cpu_online_mask)
diff --git a/kernel/cpu.c b/kernel/cpu.c
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -565,3 +565,13 @@ void init_cpu_online(const struct cpumas
{
cpumask_copy(to_cpumask(cpu_online_bits), src);
}
+
+/* Deprecated accessors. */
+struct cpumask *_cpu_possible_mask_nonconst = to_cpumask(cpu_possible_bits);
+EXPORT_SYMBOL(_cpu_possible_mask_nonconst);
+struct cpumask *_cpu_online_mask_nonconst = to_cpumask(cpu_online_bits);
+EXPORT_SYMBOL(_cpu_online_mask_nonconst);
+struct cpumask *_cpu_present_mask_nonconst = to_cpumask(cpu_present_bits);
+EXPORT_SYMBOL(_cpu_present_mask_nonconst);
+struct cpumask *_cpu_active_mask_nonconst = to_cpumask(cpu_active_bits);
+EXPORT_SYMBOL(_cpu_active_mask_nonconst);
^ permalink raw reply
* Re: nfs booting PS3, mount failed. (Geoff Levand)
From: gt bradley @ 2009-02-18 7:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <mailman.0.1234918803.22420.linuxppc-dev@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 4974 bytes --]
--- On Tue, 2/17/09, linuxppc-dev-request@ozlabs.org <linuxppc-dev-request@ozlabs.org> wrote:
From: linuxppc-dev-request@ozlabs.org <linuxppc-dev-request@ozlabs.org>
Subject: Linuxppc-dev Digest, Vol 54, Issue 101
To: linuxppc-dev@ozlabs.org
Date: Tuesday, February 17, 2009, 5:00 PM
Send Linuxppc-dev mailing list submissions to
linuxppc-dev@ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-dev
or, via email, send a message with subject or body 'help' to
linuxppc-dev-request@ozlabs.org
You can reach the person managing the list at
linuxppc-dev-owner@ozlabs.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linuxppc-dev digest..."
Today's Topics:
1. NFS-boot on PS3, kboot can't mount nfs-dir.s (gt bradley)
2. Re: nfs booting PS3, mount failed. (Geoff Levand)
3. Re: nfs booting PS3, mount failed. (Geoff Levand)
I'm trying to set up my PS3 to netboot (with an nfsroot).
I'm using instructions at http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-howto/ps3-nfs-root-howto.txt
I've
passed section 3 (using tftp) to verify network /dhcp etc. (i.e. I'm
able to tftp-get a file to ps3 from kboot's ash shell (busybox).
i'm trying to mount the nfs server as per section 4. with
~# mount -t nfs -o nolock 192.168.99.1:/target /mnt/remote
I get the following error message:
mount: mounting 192.168.99.1:/target on /mnt/remote failed
if I boot the PS3 from the HD, then I am able to mount the nfs directory.
Using wireshark, I can see the initial dhcp traffic, (and when present the tftp traffic).
the mount command doesn't open a network connection to the server,
So I have pretty much ruled out server
configuration.
running "strings" on the decompressed kboot image yeilds serveral nfs symbols, so it
appears to still support nfs mounting. (using version kboot-20080609.bld from geoff's dir at kernel.org)
I have tried googling, and searching the various mailing lists, but am stuck.
any help would be
appreciated
GT
On 02/17/2009 04:20 PM, Geoff Levand wrote:
> Another thing to try is to use a 'rescue' disk/mode to copy the
files.
> Most distros have them. Fedora has a rescue mode in their installer:
>
>
http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/ppc/iso/Fedora-10-ppc-netinst.iso
>
> Just select 'rescue' instead of 'install', or you can add
> these to the boot options: 'text rescue video=720p'.
I forgot to mention an important point when using a rescue disk.
Most will mount all the runtime directories like /sys, /dev, /proc,
etc. onto the HD file system. Those directories should not be
mounted the when you make the HD root FS copy.
Either choose the rescue option to not mount the HD file system,
and mount it yourself later, or unmount all those directories.
Just use the 'mount' command to see what has been mounted on the
HD's root FS.
-Geoff
On 02/16/2009 09:22 PM, gt bradley wrote:
> I'm trying to set up my PS3 to netboot (with an nfsroot).
>
> I'm using instructions at
>
http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-howto/ps3-nfs-root-howto.txt
>
> I've passed section 3 (using tftp) to verify network /dhcp etc.
(i.e.
> I'm able to tftp-get a file to ps3 from kboot's ash shell
(busybox).
>
> i'm trying to mount the nfs server as per section 4. with
>
> ~# mount -t nfs -o nolock 192.168.99.1:/target /mnt/remote
>
> I get the following error message:
> mount: mounting 192.168.99.1:/target on /mnt/remote failed
>
> if I boot the PS3 from the HD, then I am able to mount the nfs directory.
> Using wireshark, I can see the initial dhcp traffic, (and when present the
tftp traffic).
> the mount command doesn't open a network connection to the server,
> So I have pretty much ruled out server
> configuration.
>
> running "strings" on the decompressed kboot image yeilds
serveral nfs symbols, so it
> appears to still support nfs mounting. (using version kboot-20080609.bld
from geoff's dir at kernel.org)
I have sometimes seen nfs problems with kboot. You could you
try petitboot. Get the latest 'experimental' one from here:
http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-petitboot/
Another thing to try is to use a 'rescue' disk/mode to copy the files.
Most distros have them. Fedora has a rescue mode in their installer:
http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/ppc/iso/Fedora-10-ppc-netinst.iso
Just select 'rescue' instead of 'install', or you can add
these to the boot options: 'text rescue video=720p'.
You don't need kboot/petitboot to do nfs. To load the kernel
they just need to do tftp.
-Geoff
I'll try this this week-end, and let you know how it goes,
Thank-you for the quick response.
GT
[-- Attachment #2: Type: text/html, Size: 6041 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Check name property to determine partition nodes.
From: Benjamin Krill @ 2009-02-18 7:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, vwool, linux-mtd, David Woodhouse, dwg
In-Reply-To: <1233720542.16867.187.camel@pasglop>
* Benjamin Herrenschmidt | 2009-02-04 15:09:02 [+1100]:
>On Fri, 2009-01-23 at 17:18 +0100, Benjamin Krill wrote:
>> SLOF has a further node which could not be evaluate
>> by the current routine. The current routine returns
>> because the node hasn't the required reg property. As
>> fix this patch adds a check to determine the partition
>> child nodes. If the node is not an partition the number
>> of total partitions will be decreased and loop continue
>> with the next nodes.
>
>Somebody on the MTD list is taking that ? David ? Or should I merge it
>via powerpc ?
Could somebody merge it for the next release?
Ben
^ permalink raw reply
* Re: [PATCH] Enable hashdist by default on PowerPC
From: David Miller @ 2009-02-18 9:19 UTC (permalink / raw)
To: anton; +Cc: linuxppc-dev
In-Reply-To: <20090218051112.GA32195@kryten>
From: Anton Blanchard <anton@samba.org>
Date: Wed, 18 Feb 2009 16:11:12 +1100
> @@ -145,9 +145,10 @@ extern void *alloc_large_system_hash(const char *tablename,
> #define HASH_EARLY 0x00000001 /* Allocating during early boot? */
>
> /* Only NUMA needs hash distribution.
> - * IA64 and x86_64 have sufficient vmalloc space.
> + * IA64, x86_64 and PowerPC have sufficient vmalloc space.
> */
> -#if defined(CONFIG_NUMA) && (defined(CONFIG_IA64) || defined(CONFIG_X86_64))
> +#if defined(CONFIG_NUMA) && (defined(CONFIG_IA64) || defined(CONFIG_X86_64) || \
> + defined(CONFIG_PPC64))
> #define HASHDIST_DEFAULT 1
> #else
> #define HASHDIST_DEFAULT 0
I should probably do this on sparc64 too.
Why don't we just change this thing to CONFIG_64BIT?
^ permalink raw reply
* net_device_ops support in bridging and fec_mpc52xx.c
From: Henk Stegeman @ 2009-02-18 10:41 UTC (permalink / raw)
To: linuxppc-dev, bridge
Hello,
I discovered the hard way that because linux bridging uses
net_device_ops, bridging only works with network drivers that publish
their device operations trough net_device_ops.
In my case running:
brctl addif br0 eth0 (where eth0 fec_mpc52xx.c did not yet support
net_device_ops) gave me a:
Unable to handle kernel paging request...
After changing fec_mpc52xx.c to support net_device_ops the problem was fixed.
If possible some kind of detection in the bridging software is i think
mostly appreciated for early detection of this problem, as it is
pretty hard to relate the error message to a not updated driver.
cheers,
Henk
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index cd8e98b..a2841eb 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -888,6 +888,22 @@ static int mpc52xx_fec_ioctl(struct net_device
*dev, struct ifreq *rq, int cmd)
/* ======================================================================== */
/* OF Driver */
/* ======================================================================== */
+static const struct net_device_ops mpc52xx_fec_netdev_ops = {
+ .ndo_open = mpc52xx_fec_open,
+ .ndo_stop = mpc52xx_fec_close,
+ .ndo_start_xmit = mpc52xx_fec_hard_start_xmit,
+ .ndo_tx_timeout = mpc52xx_fec_tx_timeout,
+ .ndo_get_stats = mpc52xx_fec_get_stats,
+ .ndo_set_multicast_list = mpc52xx_fec_set_multicast_list,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_set_mac_address = mpc52xx_fec_set_mac_address,
+ .ndo_do_ioctl = mpc52xx_fec_ioctl,
+
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = mpc52xx_fec_poll_controller,
+#endif
+};
+
static int __devinit
mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
@@ -929,20 +945,7 @@ mpc52xx_fec_probe(struct of_device *op, const
struct of_device_id *match)
return -EBUSY;
/* Init ether ndev with what we have */
- ndev->open = mpc52xx_fec_open;
- ndev->stop = mpc52xx_fec_close;
- ndev->hard_start_xmit = mpc52xx_fec_hard_start_xmit;
- ndev->do_ioctl = mpc52xx_fec_ioctl;
- ndev->ethtool_ops = &mpc52xx_fec_ethtool_ops;
- ndev->get_stats = mpc52xx_fec_get_stats;
- ndev->set_mac_address = mpc52xx_fec_set_mac_address;
- ndev->set_multicast_list = mpc52xx_fec_set_multicast_list;
- ndev->tx_timeout = mpc52xx_fec_tx_timeout;
- ndev->watchdog_timeo = FEC_WATCHDOG_TIMEOUT;
- ndev->base_addr = mem.start;
-#ifdef CONFIG_NET_POLL_CONTROLLER
- ndev->poll_controller = mpc52xx_fec_poll_controller;
-#endif
+ ndev->netdev_ops = &mpc52xx_fec_netdev_ops;
priv->t_irq = priv->r_irq = ndev->irq = NO_IRQ; /* IRQ are free for now */
^ permalink raw reply related
* Re: Regarding irq_of_parse_and_map
From: Vijay Nikam @ 2009-02-18 12:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
In-Reply-To: <499AF08B.6010702@freescale.com>
I checked and read the
Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt and
booting-without-of.txt. It is different then what I read before from
booting-without-of.txt ... perhaps as it is old and came with BSP. Am
I right ? ? ?
> Don't specify this explicitly. Please base new development off of the
> device tree that is in upstream Linux, not the very old tree in your BSP.
May I know the reason why I should not specify it explicitly ? ? ?
Also what would be the problem if I do in the same way as it is given
in BSP mpc8313erdb.dts ? ? ?
And should I use gpio-controller as a gpio device node ? ? ?
Kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
On 2/17/09, Scott Wood <scottwood@freescale.com> wrote:
> Vijay Nikam wrote:
> > I added the gpio node as follows to mpc8313erdb.dts;
> >
> > gpio@c00 {
> > linux,phandle = <c00>;
> >
>
> Don't specify this explicitly. Please base new development off of the
> device tree that is in upstream Linux, not the very old tree in your BSP.
>
> > device_type = "gpio";
> >
>
> No device_type.
>
> > The only thing I need to know what should I write at 'compatible' tag
> > ? ? ? the compatible tag format is "manufacturer,model" the
> > manufacturer is 'fsl' i.e. I think freescale but the model, as it is
> > the model number where I can find this model ? ? ? Please let me know
> > ... thanks ...
> >
>
> compatible = "fsl,mpc8313-gpio", "fsl,mpc8349-gpio";
>
> > Also I would like to ask if the above device node is written according
> > to bindings ... I think it should be right as I referred
> > 'bootingwithout-of.txt' ... but please correct me if I am worng ? ? ?
> >
>
> See also
> Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt.
>
> Also note that current Linux has a driver in
> arch/powerpc/sysdev/mpc8xxx_gpio.c.
>
> -Scott
>
^ permalink raw reply
* Gianfar tx-babbling-errors
From: Scott Coulter @ 2009-02-18 16:16 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
As a simple stress test for my board with an MPC8572E and an MPC8568E on
it, I setup both processors to boot linux 2.6.27.6 with an NFS root and
then perform repeated native compiles of a linux kernel over NFS. After
running for 4 days straight or so with between 250-300 build cycles per
processor, I stopped the builds and ran ethtool to look for any odd
statistics. Both processors reported non-zero values for
tx-babbling-errors. Both processors reported around 1300
tx-babbling-errors out of about 80,000,000 Tx packets. Should I be
concerned about the tx-babbling-errors? What conditions would cause
these errors to be reported?
Thanks,
Scott
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
=20
Cyclone Microsystems =20
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
^ permalink raw reply
* Re: [RFC v1] virtio: add virtio-over-PCI driver
From: Ira Snyder @ 2009-02-18 16:38 UTC (permalink / raw)
To: Rusty Russell
Cc: linuxppc-dev, netdev, linux-kernel, Arnd Bergmann,
Jan-Bernd Themann
In-Reply-To: <200902181713.03820.rusty@rustcorp.com.au>
On Wed, Feb 18, 2009 at 05:13:03PM +1030, Rusty Russell wrote:
> On Wednesday 18 February 2009 08:54:25 Ira Snyder wrote:
> > This adds support to Linux for using virtio between two computers linked by
> > a PCI interface. This allows the use of virtio_net to create a familiar,
> > fast interface for communication. It should be possible to use other virtio
> > devices in the future, but this has not been tested.
>
> Hi Ira,
>
> It's only first glance, but this looks sane. Two things on first note:
> don't restrict yourself to 32 feature bits (only PCI does this, and they're
> going to have to hack when we reach feature 32).
>
There isn't any problem adding more feature bits. Do you think 128 bits
is enough?
> Secondly:
> > +You will notice that the algorithm has no way of handling chains that are
> > +not exactly the same on the host and guest system. Without setting any of
> > +the fancier virtio_net features, this is the case.
>
> Hmm, I think we can do slightly better than this.
>
I think so too :) I just wasn't able to come up with an algorithm to
make it work. And I wanted input from more experienced people.
> How about prepending a 4 byte length on the host buffers? Allows host to
> specify length (for host->guest), and guest writes it to allow truncated
> buffers on guest->host.
>
> That won't allow you to transfer *more* than one buffersize to the host, but
> you could use a different method (perhaps the 4 bytes indicates the *total*
> length?).
>
I don't understand how this will help.
I looked at virtio_net's implemention with VIRTIO_NET_F_MRG_RXBUF, which
seems like it could really help performance. The problems with that are:
1) virtio_net doesn't write the merged header's num_buffers field
2) virtio_net doesn't actually split packets in xmit
The problem with 1 is that one instance of virtio_net cannot talk to
another, if they're using that feature. The sender never sets the field,
so the receiver doesn't know how many buffers to expect.
I'm using two instances of virtio_net to talk to each other, rather than
a special userspace implementation like lguest and kvm use. Is this a
good approach?
The problem with 2 is that xmit may add the following to the
descriptors: (the network stack doesn't have to split the packet)
idx address len flags next
0 XXXXXXX 12 N 1
1 XXXXXXX 8000 - 2
With VIRTIO_NET_F_MRG_RXBUF, the other side's recv ring will look like
the following:
idx address len flags next
0 YYYYYYY 4096 - 1
1 YYYYYYY 4096 - 2
2 YYYYYYY 4096 - 3
....
So how do we pair up buffers to do DMA? Do I munge the header from
virtio_net to set the num_headers field, and split the 8000 bytes of
data into two parts? (Giving 12 bytes in desc 0, 4096 bytes in desc 1,
and 3904 bytes in desc 2)
The current implementation only handles something like the following,
which would be an ARP:
xmit descriptors:
idx address len flags next
0 XXXXXXX 10 N 1
1 XXXXXXX 42 - 2
recv descriptors:
idx address len flags next
0 YYYYYYY 10 N 1
1 YYYYYYY 1518 - 2
....
Then the algorithm is simple, no munging necessary. All chains are the
same length (2 entries) and the length of each buffer is suffient to
handle the data. The network stack splits the packets into <= 1518 byte
chunks for us (as long as MTU isn't changed).
> Do 4-byte DMA's suck for some reason?
>
I don't think it would hurt much. Some of the fancier features might
offset any overhead that is added.
Thanks, I appreciate the feedback.
Ira
^ permalink raw reply
* Re: [RFC v1] virtio: add virtio-over-PCI driver
From: Kumar Gala @ 2009-02-18 16:47 UTC (permalink / raw)
To: Ira Snyder
Cc: Arnd Bergmann, Jan-Bernd Themann, netdev, Rusty Russell,
linux-kernel, linuxppc-dev
In-Reply-To: <20090217222425.GA18801@ovro.caltech.edu>
On Feb 17, 2009, at 4:24 PM, Ira Snyder wrote:
>
> Documentation/virtio-over-PCI.txt | 61 ++
> arch/powerpc/boot/dts/mpc834x_mds.dts | 7 +
we'll have to review the .dts and expect a documentation update for
the node. But that's pretty minor at this point.
> drivers/virtio/Kconfig | 22 +
> drivers/virtio/Makefile | 2 +
> drivers/virtio/vop.h | 119 ++
> drivers/virtio/vop_fsl.c | 1911 ++++++++++++++++++++++++
> +++++++++
make this vop_fsl_mpc83xx.c or something along those lines.
>
> drivers/virtio/vop_host.c | 1028 ++++++++++++++++++
> drivers/virtio/vop_hw.h | 80 ++
> 8 files changed, 3230 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/virtio-over-PCI.txt
> create mode 100644 drivers/virtio/vop.h
> create mode 100644 drivers/virtio/vop_fsl.c
> create mode 100644 drivers/virtio/vop_host.c
> create mode 100644 drivers/virtio/vop_hw.h
- k
^ 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