* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Benjamin Herrenschmidt @ 2006-04-20 22:39 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <20060420211321.GB25755@gate.ebshome.net>
On Thu, 2006-04-20 at 14:13 -0700, Eugene Surovegin wrote:
> On Fri, Apr 21, 2006 at 07:06:13AM +1000, Benjamin Herrenschmidt wrote:
> > Unfortunately, he has to do things a bit differently. He can't afford to
> > have the kernel BAT mapping cover his non-cacheable pages. Thus he needs
> > a reserved pool. Last I looked at our coherent code, it didn't reserve
> > memory at all, just address space, thus assuming the CPU can handle
> > having both a caheable and a non-cacheable mapping of the same pages...
> > (On 6xx this is deadly even if you don't access those cacheable pages
> > because the CPU prefetch may do it for you).
>
> Ben, is this _real_ problem on 6xx or just a theory? Does 6xx actually
> prefetch beyond page boundary?
>
> So far, all "prefetching" I saw which broke non-coherent DMA was not
> due to the CPU doing prefetching, but _software_ prefetching being
> too aggressive.
Not 100% certain... we definitely have a bug with AGP on macs currently
for that reason though I yet have to isolate a crash caused by it ;)
(That is, we map AGP pages non-cacheable but they stay in the linear
mapping).
On POWER4, 970 and later, the chip guys confirmed that the problem is
real though. Not only bcs of prefetch but also speculative execution
which can cause the chip to do a load that will never actually be
executed. Imagine for example a loop walking an array, the chip might
speculatively load elements beyond the array by speculatively executing
beyond the branch that ends the loop.
Ben.
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Benjamin Herrenschmidt @ 2006-04-20 22:40 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <20060420211908.GC25755@gate.ebshome.net>
On Thu, 2006-04-20 at 14:19 -0700, Eugene Surovegin wrote:
> On Thu, Apr 20, 2006 at 02:13:21PM -0700, Eugene Surovegin wrote:
> > On Fri, Apr 21, 2006 at 07:06:13AM +1000, Benjamin Herrenschmidt wrote:
> > > Unfortunately, he has to do things a bit differently. He can't afford to
> > > have the kernel BAT mapping cover his non-cacheable pages. Thus he needs
> > > a reserved pool. Last I looked at our coherent code, it didn't reserve
> > > memory at all, just address space, thus assuming the CPU can handle
> > > having both a caheable and a non-cacheable mapping of the same pages...
> > > (On 6xx this is deadly even if you don't access those cacheable pages
> > > because the CPU prefetch may do it for you).
> >
> > Ben, is this _real_ problem on 6xx or just a theory? Does 6xx actually
> > prefetch beyond page boundary?
> >
> > So far, all "prefetching" I saw which broke non-coherent DMA was not
> > due to the CPU doing prefetching, but _software_ prefetching being
> > too aggressive.
>
> Even if this "prefetching" problem is real, instead of implementing
> separate pool for allocations which will be quite rare at best, just
> allocate guard space before your consistent memory and stop worrying
> about it.
Won't necessarily help with the speculative execution problem and in
fact, how do you do that in practice ?
Ben.
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Benjamin Herrenschmidt @ 2006-04-20 22:41 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <20060420213316.GD25755@gate.ebshome.net>
On Thu, 2006-04-20 at 14:33 -0700, Eugene Surovegin wrote:
> On Fri, Apr 21, 2006 at 07:06:13AM +1000, Benjamin Herrenschmidt wrote:
> > (On 6xx this is deadly even if you don't access those cacheable pages
> > because the CPU prefetch may do it for you).
>
> Here is another thought if this "prefetch" theory is correct.
>
> You guys seems to focus on
> dma_alloc_coherent()/pci_alloc_consistent(), but forgeting about so
> called "streaming" mappings.
>
> You cannot just flush/invalidate cache any more, because "CPU can
> prefetch this data back". So, to be completely correct (if you insist
> on "6xx can prefetch"-theory), you have to actually _copy_ data to
> your consistent memory on dma_map_single(). You can imagine
> performance implications. I suspect even 440 will be faster in this
> case than G4 :).
Yes.
Ben.
^ permalink raw reply
* Re: [patch] powerpc: move PAGE_SIZE outside #ifdef __KERNEL__
From: Paul Mackerras @ 2006-04-20 23:07 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev
In-Reply-To: <4447C3BA.6050709@am.sony.com>
Geoff Levand writes:
> The procps package needs PAGE_SIZE, defined in asm-powerpc/page.h,
Ummm... why? If procps is assuming that the page size of the kernel
it's running on is the same as the page size of the kernel it was
compiled on, it's broken. It should be using sysconf(PAGE_SIZE) at
runtime.
Paul.
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Gabriel Paubert @ 2006-04-20 23:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <1145572770.4517.8.camel@localhost.localdomain>
On Fri, Apr 21, 2006 at 08:39:29AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2006-04-20 at 14:13 -0700, Eugene Surovegin wrote:
> > On Fri, Apr 21, 2006 at 07:06:13AM +1000, Benjamin Herrenschmidt wrote:
> > > Unfortunately, he has to do things a bit differently. He can't afford to
> > > have the kernel BAT mapping cover his non-cacheable pages. Thus he needs
> > > a reserved pool. Last I looked at our coherent code, it didn't reserve
> > > memory at all, just address space, thus assuming the CPU can handle
> > > having both a caheable and a non-cacheable mapping of the same pages...
> > > (On 6xx this is deadly even if you don't access those cacheable pages
> > > because the CPU prefetch may do it for you).
> >
> > Ben, is this _real_ problem on 6xx or just a theory? Does 6xx actually
> > prefetch beyond page boundary?
> >
> > So far, all "prefetching" I saw which broke non-coherent DMA was not
> > due to the CPU doing prefetching, but _software_ prefetching being
> > too aggressive.
>
> Not 100% certain... we definitely have a bug with AGP on macs currently
> for that reason though I yet have to isolate a crash caused by it ;)
> (That is, we map AGP pages non-cacheable but they stay in the linear
> mapping).
In this case the problem is double mapping with inconsistent attributes
(through BAT and page tables I assume).
>
> On POWER4, 970 and later, the chip guys confirmed that the problem is
> real though. Not only bcs of prefetch but also speculative execution
> which can cause the chip to do a load that will never actually be
> executed. Imagine for example a loop walking an array, the chip might
> speculatively load elements beyond the array by speculatively executing
> beyond the branch that ends the loop.
Even if the page has the guarded bit set?
Gabriel
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Benjamin Herrenschmidt @ 2006-04-21 0:09 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <20060420234640.GA20059@iram.es>
> In this case the problem is double mapping with inconsistent attributes
> (through BAT and page tables I assume).
Yes.
> > On POWER4, 970 and later, the chip guys confirmed that the problem is
> > real though. Not only bcs of prefetch but also speculative execution
> > which can cause the chip to do a load that will never actually be
> > executed. Imagine for example a loop walking an array, the chip might
> > speculatively load elements beyond the array by speculatively executing
> > beyond the branch that ends the loop.
>
> Even if the page has the guarded bit set?
The BAT mapping doesn't have G set.
Ben.
^ permalink raw reply
* [PATCH] powerpc/pseries: avoid crash in PCI code if mem system not up.
From: Linas Vepstas @ 2006-04-21 0:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
Paul,
Please apply and forward upstream. And a question: once
upon a time, the arch PCI subsystem was inited after mem init
was done; currently, it seems to be happening before mem init.
Is this intentional?
--linas
[PATCH] powerpc/pseries: avoid crash in PCI code if mem system not up.
The powerpc code is currently performing PCI setup before
memory initialization. PCI setup touches PCI config space
registers. If the PCI card is bad, this will evoke an error,
which currrently can't be handled, as the PCI error recovery
code expects kmalloc() to be functional. This patch will
cause the system to punt instead of crashing with
cpu 0x0: Vector: 300 (Data Access) at [c0000000004434d0]
pc: c0000000000c06b4: .kmem_cache_alloc+0x8c/0xf4
lr: c00000000004ad6c: .eeh_send_failure_event+0x48/0xfc
This patch Will also print name of the offending pci device.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh_event.c | 9 +++++++++
1 files changed, 9 insertions(+)
Index: linux-2.6.17-rc1/arch/powerpc/platforms/pseries/eeh_event.c
===================================================================
--- linux-2.6.17-rc1.orig/arch/powerpc/platforms/pseries/eeh_event.c 2006-04-05 09:56:38.000000000 -0500
+++ linux-2.6.17-rc1/arch/powerpc/platforms/pseries/eeh_event.c 2006-04-20 19:29:48.000000000 -0500
@@ -124,7 +124,16 @@ int eeh_send_failure_event (struct devic
{
unsigned long flags;
struct eeh_event *event;
+ char *location;
+ if (!mem_init_done)
+ {
+ printk(KERN_ERR "EEH: event during early boot not handled\n");
+ location = (char *) get_property(dn, "ibm,loc-code", NULL);
+ printk(KERN_ERR "EEH: device node = %s\n", dn->full_name);
+ printk(KERN_ERR "EEH: PCI location = %s\n", location);
+ return 1;
+ }
event = kmalloc(sizeof(*event), GFP_ATOMIC);
if (event == NULL) {
printk (KERN_ERR "EEH: out of memory, event not handled\n");
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: Tolunay Orkun @ 2006-04-21 4:10 UTC (permalink / raw)
To: Antonio Di Bacco; +Cc: White, linuxppc-embedded
In-Reply-To: <200604202303.21680.antonio.dibacco@aruba.it>
If your bootloader is U-Boot and you are using standard bootm command to
boot, U-Boot decompresses the initrd image to RAM before passing the
file system to Linux. So, you are not working with flash copy and
updating the flash copy is not a problem at all. This applies to ext2,
cramfs or squashfs based initrd.
You can keep working as long as you like until it is time to reboot.
Antonio Di Bacco wrote:
> Yes, I also thought this too. Anything important should stay already in RAM
> but there is a chance that something bad could happen. Probably the best
> thing is what you suggested as second option but I have not so much ram. My
> CGI writes the downloaded new software in RAM and then I should directly jump
> to u-boot without leaving Linux the chance to mix things up and then u-boot
> should copy the RAM to the flash. It seems a strange procedure but what else
> could be done with 4MB flash and 16 MB ram?
>
> Bye,
> Antonio.
>
> On Thursday 20 April 2006 22:18, White wrote:
>> make it easy: if you start an application which do the flash and after
>> this a reset.. nothing should happen. I do it that way.
>> the application resist completly in RAM .. and all important libs are
>> in RAm or in Filesystem Cache.
>> It's only important that you pretend any Application from accessing
>> Datafiles or start of new application ...
>>
>> Alternativly, you can put it in a reserved RAM Area ( mark it not
>> usable by Linux) and put a Flash Code in your Bootloader (U-boot?)
>> after a reset....
>>
>> But overwrite a cramfs works for me on >100 times without problems.
>>
>> Am Thu, 20 Apr 2006 21:54:45 +0200 schrieb Antonio Di Bacco
>>
>> <antonio.dibacco@aruba.it> :
>>> Yes you are right, it is not a good idea to overwrite working cramfs
>>> filesystem. But what happens if I download the new cramfs plus kernel in
>>> RAM, do a checksum and then, completely in kernel mode, disabling all the
>>> interrupts, I write to flash? No process could complain that I am
>>> overwriting because no one is executing.
>>>
>>> Bye,
>>> Antonio.
>>>
>>> On Wednesday 19 April 2006 09:42, Wojciech Kromer wrote:
>>>> Dnia 2006-04-06 22:38, Użytkownik Antonio Di Bacco napisał:
>>>>> Hi,
>>>>>
>>>>> how could I upgrade my cramfs rootfs? I have a CGI in the rootfs that
>>>>> receives the new rootfs from a web interface and then tries to write
>>>>> it in the flash. While overwriting the old cramfs, the CGI will
>>>>> continue to work? something weird could happen?
>>>> Generally it's not a good idea to override working filesystem ( I've
>>>> tried to do it once).
>>>>
>>>> You can have two separate copies of filesystem, one to work with, and
>>>> another to overwrite, it requires more flash.
>>>> Another way is working in initrd, it requires more RAM.
>>>> You can also use jffs2 or jffs3 (experimental) to have read-write
>>>> filesystem, and change applications only, not whole filesystem (be
>>>> carefull with changing busybox or libraries!)
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Benjamin Herrenschmidt @ 2006-04-21 4:38 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <20060420215514.GE25755@gate.ebshome.net>
On Thu, 2006-04-20 at 14:55 -0700, Eugene Surovegin wrote:
> On Thu, Apr 20, 2006 at 11:10:55PM +0200, Gerhard Pircher wrote:
> > Well, Freescale's PPC programming environment manual clearly states that
> > this will not work on G4 CPUs (74xx). Also Benjamin Herrenschmidt told me,
> > that this implementation will not work for the reasons I mentioned before.
> > The approach I'm trying to implement was his idea, so I have to trust in
> > him.
>
> Well, you aren't the first person who tries to run G4 with
> CONFIG_NOT_COHERENT_CACHE. This was done before and I don't remember
> that those people had to implement anything as complex as you are
> trying to do.
>
> You can try asking on #mklinux. It always better to ask people who
> actually _did_ this :).
>
> In fact, I just grepped 2.6 and found
> #ifdef(CONFIG_NOT_COHERENT_CACHE) in syslib/mv64x60.c. Guess what
> systems usually have this type of bridge? Not 4xx/8xx, that's for sure.
I think some folks tried ... and failed.
Ben.
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: antonio.dibacco @ 2006-04-21 5:51 UTC (permalink / raw)
To: Tolunay Orkun; +Cc: White, linuxppc-embedded
In-Reply-To: <44485B3F.8080308@orkun.us>
No, I have a cramfs on flash and the kernel uses it directly from flash,
extracting what it needs to execute. I'm not using initrd then, I have to
update in situ, while running.
Bye,
Antonio.
Tolunay Orkun Scrive:
> If your bootloader is U-Boot and you are using standard bootm command to
> boot, U-Boot decompresses the initrd image to RAM before passing the file
> system to Linux. So, you are not working with flash copy and updating the
> flash copy is not a problem at all. This applies to ext2, cramfs or
> squashfs based initrd.
>
> You can keep working as long as you like until it is time to reboot.
>
> Antonio Di Bacco wrote:
>> Yes, I also thought this too. Anything important should stay already in
>> RAM but there is a chance that something bad could happen. Probably the
>> best thing is what you suggested as second option but I have not so much
>> ram. My CGI writes the downloaded new software in RAM and then I should
>> directly jump to u-boot without leaving Linux the chance to mix things up
>> and then u-boot should copy the RAM to the flash. It seems a strange
>> procedure but what else could be done with 4MB flash and 16 MB ram?
>>
>> Bye,
>> Antonio.
>>
>> On Thursday 20 April 2006 22:18, White wrote:
>>> make it easy: if you start an application which do the flash and after
>>> this a reset.. nothing should happen. I do it that way.
>>> the application resist completly in RAM .. and all important libs are
>>> in RAm or in Filesystem Cache.
>>> It's only important that you pretend any Application from accessing
>>> Datafiles or start of new application ...
>>>
>>> Alternativly, you can put it in a reserved RAM Area ( mark it not
>>> usable by Linux) and put a Flash Code in your Bootloader (U-boot?)
>>> after a reset....
>>>
>>> But overwrite a cramfs works for me on >100 times without problems.
>>>
>>> Am Thu, 20 Apr 2006 21:54:45 +0200 schrieb Antonio Di Bacco
>>>
>>> <antonio.dibacco@aruba.it> :
>>>> Yes you are right, it is not a good idea to overwrite working cramfs
>>>> filesystem. But what happens if I download the new cramfs plus kernel
>>>> in
>>>> RAM, do a checksum and then, completely in kernel mode, disabling all
>>>> the
>>>> interrupts, I write to flash? No process could complain that I am
>>>> overwriting because no one is executing.
>>>>
>>>> Bye,
>>>> Antonio.
>>>>
>>>> On Wednesday 19 April 2006 09:42, Wojciech Kromer wrote:
>>>>> Dnia 2006-04-06 22:38, Użytkownik Antonio Di Bacco napisał:
>>>>>> Hi,
>>>>>>
>>>>>> how could I upgrade my cramfs rootfs? I have a CGI in the rootfs that
>>>>>> receives the new rootfs from a web interface and then tries to write
>>>>>> it in the flash. While overwriting the old cramfs, the CGI will
>>>>>> continue to work? something weird could happen?
>>>>> Generally it's not a good idea to override working filesystem ( I've
>>>>> tried to do it once).
>>>>>
>>>>> You can have two separate copies of filesystem, one to work with, and
>>>>> another to overwrite, it requires more flash.
>>>>> Another way is working in initrd, it requires more RAM.
>>>>> You can also use jffs2 or jffs3 (experimental) to have read-write
>>>>> filesystem, and change applications only, not whole filesystem (be
>>>>> carefull with changing busybox or libraries!)
>>>> _______________________________________________
>>>> Linuxppc-embedded mailing list
>>>> Linuxppc-embedded@ozlabs.org
>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: powermac S900 6 slot PCI broken in 2.6.16
From: Benjamin Herrenschmidt @ 2006-04-21 6:21 UTC (permalink / raw)
To: Robert Brose; +Cc: linuxppc-dev
In-Reply-To: <20060420152250.17407.qmail@kunk.qbjnet.com>
On Thu, 2006-04-20 at 15:22 +0000, Robert Brose wrote:
> The s900 has a 6 slot PCI bus. It works fine in 2.6.15. In 2.6.16 it
> appears the interrupts are being assigned in an incorrect way, I get
> an interrupt assignment failure on the device on the 21052 bridge.
> (notice in the interrupt assignment at the end that the stuff on the
> bridge is on irq 25 when it works in 2.6.15 and irq 1 when it doesn't
> work in 2.6.16).
can you send me a tarball of /proc/device-tree along with a complete
dmesg output and lspci -vv log as root for both 2.6.15 and .16 ? Thanks.
Ben.
^ permalink raw reply
* Re: Upgrading cramfs root file system
From: Wojciech Kromer @ 2006-04-21 6:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060420221801.55331e15@White64>
Dnia 2006-04-20 22:18, Użytkownik White napisał:
> make it easy: if you start an application which do the flash and after
> this a reset.. nothing should happen. I do it that way.
> the application resist completly in RAM .. and all important libs are
> in RAm or in Filesystem Cache.
> It's only important that you pretend any Application from accessing
> Datafiles or start of new application ...
>
> Alternativly, you can put it in a reserved RAM Area ( mark it not
> usable by Linux) and put a Flash Code in your Bootloader (U-boot?)
> after a reset....
>
> But overwrite a cramfs works for me on >100 times without problems.
>
>
Problems with changing cramfs and reboot may vary depending on changes
made to filesystem.
You can't even call reboot, bacause it's not in the prevoius location
after changing flash.
> Am Thu, 20 Apr 2006 21:54:45 +0200 schrieb Antonio Di Bacco
> <antonio.dibacco@aruba.it> :
>
>
>> Yes you are right, it is not a good idea to overwrite working cramfs
>> filesystem. But what happens if I download the new cramfs plus kernel in RAM,
>> do a checksum and then, completely in kernel mode, disabling all the
>> interrupts, I write to flash? No process could complain that I am overwriting
>> because no one is executing.
>>
>>
Maybe such feature should be added to MTD code.
But disabling interrupts may cause watchdog reset in most embedded
platforms.
^ permalink raw reply
* Re: Upgrading cramfs root file system while running (DENX wrote that is not possible)
From: David Jander @ 2006-04-21 6:53 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200604202303.21680.antonio.dibacco@aruba.it>
Hi,
On Thursday 20 April 2006 23:03, Antonio Di Bacco wrote:
> Yes, I also thought this too. Anything important should stay already in RAM
> but there is a chance that something bad could happen. Probably the best
What do you mean with "something bad could happen"?
The only thing I can think of is pulling the power plug while flash is being
erased or written. What else could go wrong?
We do the following: system running from read-only jffs2 partition. Sometimes
that partition is remounted read-write and single files are replaced, but in
some occasions we need to upgrade the whole fs. In that case a CGI lodas the
image into a ramdisk, and the upgrade process is started. For upgrade,
'eraseall' and 'dd' (from busybox) are needed. First, all unnecessary
processes are killed (the webserver stays alive to be able to report the
status when finished), then "dd" is called for a dummy operation (to have it
cached). After that the upgrade tool calls "eraseall" on the rootfs
partition, and then "dd" again to copy the image. At that point no critical
flash-read access should be requested since dd is already in cache (it's
busybox, so it's almost always in RAM anyway). When dd is finished, the only
other thing that's needed is to either be able to send some last html strings
to the web-server to complete the progress page and tell the user, that it's
ok to pull the plug, or reset the system, we don't care if the rest of the
system goes belly-up, since the fs was mounted read-only anyway, and the
upgrade is finished.
Of course this isn't failsafe, so there should always be a way to recover if
the rootfs gets trashed, but most of the time it's acceptable that service
personel is required in that situation. Until now, it has never been required
though.
> thing is what you suggested as second option but I have not so much ram. My
> CGI writes the downloaded new software in RAM and then I should directly
> jump to u-boot without leaving Linux the chance to mix things up and then
> u-boot should copy the RAM to the flash. It seems a strange procedure but
> what else could be done with 4MB flash and 16 MB ram?
Run from initrd? Maybe an uncomressed filesystem on a ramdisk to be able to do
XIP (execute in place)?
Greetings,
--
David Jander
^ permalink raw reply
* Fedora 5 on POWER5
From: Josef Mádl @ 2006-04-21 6:21 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 492 bytes --]
Hello to all,
I am trying to install fedora 5 on IBM i5 system. Instalation start, all seems to good to partitioning disk.
Fedora see two disks /dev/sda (real disk - virtual disk prepared with CRTNWSSTG) and /dev/sdb (booting disk of instalation - Prep).
I choise /dev/sda for creating linux partitions, fedora show me how it will be parted but try to write to /dev/sdb - it ends with error.
Do anybody know how solved this problem ?
I can send detail error from anaconda.
Josef
[-- Attachment #2: Type: text/html, Size: 1261 bytes --]
^ permalink raw reply
* Re: 2.6.16 backtrace at boot (Ibook G4) (related to "PowerBook5,4 -- no sound?")
From: Michael Schmitz @ 2006-04-21 7:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: [ATR]Dj-Death, linuxppc-dev, debian-powerpc, Paul Mackerras
In-Reply-To: <1145566085.17087.70.camel@localhost.localdomain>
> > Commenting out the -ENODEV return gives me working sound; didn't I mention
> > that?
>
> There is a proper patch in paulus tree.. it's basically the patch I
> posted with an extern declaration at the beginning of the macro before
> the EXPORT_SYMBOL.
Yep, I got that right; just wanted to report that this is the only problem
with sound I have in 2.6.17 (well, sound dies after changing the volume
with gtkpbbuttons while playing something in VLC, but that's not
necessarily 2.6.17 specific. Need to try 2.6.16 with that).
> Patch isn't in yet it seems.
No sweat - seems I'll need a bigger disk anyway before pulling another
update :-)
Michael
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Gerhard Pircher @ 2006-04-21 8:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1145594285.28014.12.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Eugene Surovegin <ebs@ebshome.net>
> Kopie: Gerhard Pircher <gerhard_pircher@gmx.net>,
> linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
> Datum: Fri, 21 Apr 2006 14:38:05 +1000
>
> > In fact, I just grepped 2.6 and found
> > #ifdef(CONFIG_NOT_COHERENT_CACHE) in syslib/mv64x60.c. Guess what
> > systems usually have this type of bridge? Not 4xx/8xx, that's for sure.
>
> I think some folks tried ... and failed.
That doesn't sound encouraging. ;)
Gerhard
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
^ permalink raw reply
* Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
From: Gerhard Pircher @ 2006-04-21 8:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1145572869.4517.12.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Eugene Surovegin <ebs@ebshome.net>
> Kopie: Gerhard Pircher <gerhard_pircher@gmx.net>,
> linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: Not coherent cache DMA for G3/G4 CPUs: clarification needed
> Datum: Fri, 21 Apr 2006 08:41:09 +1000
>
> On Thu, 2006-04-20 at 14:33 -0700, Eugene Surovegin wrote:
> > On Fri, Apr 21, 2006 at 07:06:13AM +1000, Benjamin Herrenschmidt wrote:
> > > (On 6xx this is deadly even if you don't access those cacheable pages
> > > because the CPU prefetch may do it for you).
> >
> > Here is another thought if this "prefetch" theory is correct.
> >
> > You guys seems to focus on
> > dma_alloc_coherent()/pci_alloc_consistent(), but forgeting about so
> > called "streaming" mappings.
> >
> > You cannot just flush/invalidate cache any more, because "CPU can
> > prefetch this data back". So, to be completely correct (if you insist
> > on "6xx can prefetch"-theory), you have to actually _copy_ data to
> > your consistent memory on dma_map_single(). You can imagine
> > performance implications. I suspect even 440 will be faster in this
> > case than G4 :).
>
> Yes.
I'm not sure, if I can follow you here. Would that mean I have to allocate
two consistent buffers of the same size? I guess the first buffer would be
used for the actual DMA transfer and is read only and the second one by the
CPU for further data processing (after the CPU has copied the data from the
first one to the second one)?
Hmm, doesn't sound feasible for me.. ?)
Gerhard
--
Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* RE: Watchdog on MPC82xx [SOLVED]
From: Bastos Fernandez Alexandre @ 2006-04-21 10:33 UTC (permalink / raw)
To: linuxppc-embedded list
In-Reply-To: <1145528816.444761f0a9962@webmail.televes.com:443>
Hi,
As suggested by Rune, problem was concerning to the RTC on time_init().
As I don't have a RTC on the board, the solution for me was setting
the ppc_md.get_rtc_time to NULL, which prevents time_init() from
doing the loop which tries to set the next second boundary. So
void __init
m82xx_board_setup(void)
{
[...]
ppc_md.get_rtc_time = NULL;
ppc_md.set_rtc_time = NULL;
}
Thanks to all.
Alex BASTOS
> Rune,
>
> > On our 8265/8280 board, the max timeout of the watchdog timer was ~1.3
> > seconds, so it kept resetting before the heartbeat function got called
> > on boot.
> >
> > I had to add a watchdog reset to time_init() because it woud pause there
> > for about 2 secondfs trying to see if there was a realtime clock.
> >
>
> I think that you are OK. Using the while(1) test suggested by Paul Bilke,
> I could verify that time_init() is the cause for the reset. In fact, I have
> no RTC on my board (so I suppose the delay looking for it will be maximum).
>
> Thanks
>
> Alex Bastos
^ permalink raw reply
* fix oops due to i2c-keylarge -> i2c-powermac rename
From: Guido Guenther @ 2006-04-21 8:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Hi,
the i2c-keywest module has been renamed to i2c-powermac during the
2.6.16 development cycle. This fixes the corresponding request_module
calls so the module gets loaded again and we don't oops on i2c accesses.
Patch applies against current Linus git. Please apply:
Singend-Off-By: Guido Guenther <agx@sigxcpu.org>
--- orig/linux-2.6.16.7/sound/ppc/tumbler.c 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16.7/sound/ppc/tumbler.c 2006-04-19 23:15:20.000000000 +0200
@@ -1314,7 +1314,7 @@
#ifdef CONFIG_KMOD
if (current->fs->root)
- request_module("i2c-keywest");
+ request_module("i2c-powermac");
#endif /* CONFIG_KMOD */
mix = kmalloc(sizeof(*mix), GFP_KERNEL);
--- orig/linux-2.6.16.7/sound/ppc/daca.c 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16.7/sound/ppc/daca.c 2006-04-19 23:14:33.000000000 +0200
@@ -256,7 +256,7 @@
#ifdef CONFIG_KMOD
if (current->fs->root)
- request_module("i2c-keywest");
+ request_module("i2c-powermac");
#endif /* CONFIG_KMOD */
mix = kmalloc(sizeof(*mix), GFP_KERNEL);
--- orig/linux-2.6.16.7/sound/oss/dmasound/tas_common.c 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16.7/sound/oss/dmasound/tas_common.c 2006-04-20 20:46:55.000000000 +0200
@@ -195,8 +195,8 @@
printk(KERN_INFO "tas driver [%s])\n", driver_name);
-#ifndef CONFIG_I2C_KEYWEST
- request_module("i2c-keywest");
+#ifndef CONFIG_I2C_POWERMAC
+ request_module("i2c-powermac");
#endif
tas_node = find_devices("deq");
if (tas_node == NULL)
--- orig/linux-2.6.16.7/drivers/macintosh/therm_adt746x.c 2006-03-20 06:53:29.000000000 +0100
+++ linux-2.6.16.7/drivers/macintosh/therm_adt746x.c 2006-04-20 20:45:32.000000000 +0200
@@ -627,8 +627,8 @@
if(therm_type == ADT7460)
device_create_file(&of_dev->dev, &dev_attr_sensor2_fan_speed);
-#ifndef CONFIG_I2C_KEYWEST
- request_module("i2c-keywest");
+#ifndef CONFIG_I2C_POWERMAC
+ request_module("i2c-powermac");
#endif
return i2c_add_driver(&thermostat_driver);
Cheers,
-- Guido
^ permalink raw reply
* Re: [PATCH] sys_vmsplice
From: Arnd Bergmann @ 2006-04-21 10:41 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, Jens Axboe, linuxppc-dev, torvalds, Paul Mackerras,
davem
In-Reply-To: <20060421022555.2d460805.akpm@osdl.org>
On Friday 21 April 2006 11:25, Andrew Morton wrote:
> It might be better to just stick the new entry into the spufs table, make
> sure that the powerpc guys see it go in. That way, ppc64 people (Linus,
> maybe you?) can test it.
>
> I guess mapping it onto sys_ni_syscall would be safest.
>
> (It's been broken since sys_tee went in, btw).
The BUILD_BUG_ON in there was just overkill. How about if we just add a
small comment to the systbl on powerpc to remind people about the fact
that there is another file to edit? Patch follows.
Arnd <><
^ permalink raw reply
* [PATCH] fix spu_callbacks BUILD_BUG_ON
From: Arnd Bergmann @ 2006-04-21 10:45 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, Jens Axboe, linuxppc-dev, torvalds, Paul Mackerras,
davem
In-Reply-To: <200604211241.36596.arnd@arndb.de>
Every time a new syscall gets added, a BUILD_BUG_ON in
arch/powerpc/platforms/cell/spu_callbacks.c gets triggered.
Since the addition of a new syscall is rather harmless,
the error should just be removed.
While we're here, add sys_tee to the list and add a comment
to systbl.S to remind people that there is another list
on powerpc.
Signed-of-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
--- linus-2.6.orig/arch/powerpc/platforms/cell/spu_callbacks.c
+++ linus-2.6/arch/powerpc/platforms/cell/spu_callbacks.c
@@ -317,17 +317,16 @@ void *spu_syscall_table[] = {
[__NR_ppoll] sys_ni_syscall, /* sys_ppoll */
[__NR_unshare] sys_unshare,
[__NR_splice] sys_splice,
+ [__NR_tee] sys_tee,
};
long spu_sys_callback(struct spu_syscall_block *s)
{
long (*syscall)(u64 a1, u64 a2, u64 a3, u64 a4, u64 a5, u64 a6);
- BUILD_BUG_ON(ARRAY_SIZE(spu_syscall_table) != __NR_syscalls);
-
syscall = spu_syscall_table[s->nr_ret];
- if (s->nr_ret >= __NR_syscalls) {
+ if (s->nr_ret >= ARRAY_SIZE(spu_syscall_table)) {
pr_debug("%s: invalid syscall #%ld", __FUNCTION__, s->nr_ret);
return -ENOSYS;
}
Index: linus-2.6/arch/powerpc/kernel/systbl.S
===================================================================
--- linus-2.6.orig/arch/powerpc/kernel/systbl.S
+++ linus-2.6/arch/powerpc/kernel/systbl.S
@@ -324,3 +324,8 @@ COMPAT_SYS(ppoll)
SYSCALL(unshare)
SYSCALL(splice)
SYSCALL(tee)
+
+/*
+ * please add new calls to arch/powerpc/platforms/cell/spu_callbacks.c
+ * as well when appropriate.
+ */
^ permalink raw reply
* Re: [PATCH 1/2] tickless idle cpus: core patch - v2
From: Paul Mackerras @ 2006-04-21 10:49 UTC (permalink / raw)
To: vatsa; +Cc: linuxppc-dev
In-Reply-To: <20060410121847.GB5564@in.ibm.com>
Srivatsa Vaddagiri writes:
> This is the v2 of the core patch to skip ticks when a CPU is idle.
...
> +/* Returns 1 if this CPU was set in the mask */
> +static inline int clear_hzless_mask(void)
> +{
> + int cpu = smp_processor_id();
> + int rc = 0;
> +
> + if (unlikely(cpu_isset(cpu, nohz_cpu_mask))) {
> + cpu_clear(cpu, nohz_cpu_mask);
Is the nohz_cpu_mask accessed by other cpus? I wonder if using a
1-byte per-cpu variable for this, or even a bit in the thread_info
struct, might be better because it would reduce the number of atomic
bit set/clear operations we have to do.
> +#define MAX_DEC_COUNT UINT_MAX /* Decrementer is 32-bit */
The decrementer value should be restricted to INT_MAX. I think some
implementations will take a decrementer interrupt if you set the
decrementer to a negative value.
> +static void account_ticks(struct pt_regs *regs)
> +{
> + int next_dec;
> + int cpu = smp_processor_id();
> + unsigned long ticks;
> +
> while ((ticks = tb_ticks_since(per_cpu(last_jiffy, cpu)))
> >= tb_ticks_per_jiffy) {
> /* Update last_jiffy */
This is just the loop body from timer_interrupt, right? Why do we
have to loop around N times after we skipped N ticks? What we're
doing inside the loop is:
- account_process_time, but we know we were in the idle task, so the
time is just idle time. If we have the accurate accounting stuff
turned on the first call to account_process_time will account all
the idle time anyway.
- we're not skipping ticks on the boot cpu (yet), so we won't do the
do_timer and timer_recalc_offset calls.
I think we could probably rearrange this code to eliminate the need
for the regs argument - all it's used for is telling whether we were
in user mode, and we know we weren't since we were in the idle task.
That would mean that we maybe could call start_hz_timer from the idle
task body instead of inside do_IRQ etc. The only thing we'd have to
watch out for is updating the decrementer if some interrupt handler
called add_timer/mod_timer etc.
Assuming we make the changes we have discussed to reduce the skewing
of the decrementer interrupts quite small, and allow any cpu to call
do_timer, then how where you thinking that xtime and the NTP stuff
would get updated, in the situation where all cpus are skipping ticks?
By doing N calls to do_timer in a row? Or by adding N-1 to jiffies_64
and then calling do_timer once?
> +#ifdef CONFIG_NO_IDLE_HZ
> + max_skip = __USE_RTC() ? HZ : MAX_DEC_COUNT / tb_ticks_per_jiffy;
> +#endif
If we allow the boot cpu to skip ticks, then we will have to make sure
that at least one cpu wakes up in time to do the updating in
recalc_timer_offset.
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Paul Mackerras @ 2006-04-21 11:17 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <644FB6AC-3702-41D0-A9E2-6FDEC52B819D@freescale.com>
Andy Fleming writes:
> So no one chimed in on this. Clearly, 1275 states that it's supposed
> to be local-mac-address or mac-address. We use "address". But I'm
> pretty sure we copied our ethernet node from somewhere else, so which
> one should it be?
It shouldn't be "address". That would normally be the physical
address of the device's registers, if anything.
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: avoid crash in PCI code if mem system not up.
From: Paul Mackerras @ 2006-04-21 12:02 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060421004042.GC7242@austin.ibm.com>
Linas Vepstas writes:
> Please apply and forward upstream. And a question: once
> upon a time, the arch PCI subsystem was inited after mem init
> was done; currently, it seems to be happening before mem init.
> Is this intentional?
No, and it is bogus if it is. Do you have the full backtrace from the
crash?
Paul.
^ permalink raw reply
* USB-Hostcontroller-Support for MPC875
From: Josef Angermeier @ 2006-04-21 12:57 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I'd like to make use of the MP875 internal USB-Hostcontroller on my
custome board. Such support is not included in official kernel releases,
but theres exists a usbhost-for-mpc8xx patch from brad parker for the
2.4 kernel series. Did ever someone use that one with an MPC875 ?
thanks for every help,
best regards,
Josef
^ 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