Re: [PATCH] change acquire/release_console_sem() to console_lock/unlock()
On Thu, Jan 20, 2011 at 21:35, Andrew Morton a...@linux-foundation.org wrote:
On Thu, 20 Jan 2011 17:55:02 +0100
torbenh torb...@gmx.de wrote:
On Thu, Jan 20, 2011 at 08:34:48AM -0800, Greg KH wrote:
On Thu, Jan 20, 2011 at 04:58:13PM +0100, Torben Hohn wrote:
the -rt patches change the console_semaphore to console_mutex.
so a quite large chunk of the patches changes all
acquire/release_console_sem() to acquire/release_console_mutex()
Why not just change the functionality of the existing function to be a
mutex in the rt patches, instead of having to rename it everywhere?
i hope that Thomas already did this in his upcoming -rt series.
this commit makes things use more neutral function names
which dont make implications about the underlying lock.
the only real change is the return value of console_trylock
which is inverted from try_acquire_console_sem()
Signed-off-by: Torben Hohn torb...@gmx.de
CC: Thomas Gleixner t...@tglx.de
I don't mind this rename, but is it really going to help anything out?
What's the odds of the -rt portion of this patch ever making it to
mainline?
the -rt portion only changes the semaphore to a mutex.
since the console_sem is used with mutex semantics, i dont see any
reason, not to merge that portion too.
i am just trying to shrink the -rt patch to make it more maintanable :)
Yeah, I think it's a better name and if we can indeed switch that
semaphore to a mutex then that's a good thing to do.
include/linux/mutex.h:
/*
* NOTE: mutex_trylock() follows the spin_trylock() convention,
* not the down_trylock() convention!
*
* Returns 1 if the mutex has been acquired successfully, and 0 on contention.
*/
extern int mutex_trylock(struct mutex *lock);
So that's why the return value was inverted (when treating it as a boolean).
I can understand that.
However:
+/**
+ * console_trylock - try to lock the console system for exclusive use.
+ *
+ * Tried to acquire a lock which guarantees that the caller has
+ * exclusive access to the console system and the console_drivers list.
+ *
+ * returns -1 on success, and 0 on failure to acquire the lock.
+ */
+int console_trylock(void)
So this one returns -1 on success, not 1? Why?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] change acquire/release_console_sem() to console_lock/unlock()
On Fri, 21 Jan 2011 09:10:06 +0100 Geert Uytterhoeven ge...@linux-m68k.org
wrote:
include/linux/mutex.h:
/*
* NOTE: mutex_trylock() follows the spin_trylock() convention,
* not the down_trylock() convention!
*
* Returns 1 if the mutex has been acquired successfully, and 0 on contention.
*/
extern int mutex_trylock(struct mutex *lock);
So that's why the return value was inverted (when treating it as a boolean).
I can understand that.
However:
+/**
+ * console_trylock - try to lock the console system for exclusive use.
+ *
+ * Tried to acquire a lock which guarantees that the caller has
+ * exclusive access to the console system and the console_drivers list.
+ *
+ * returns -1 on success, and 0 on failure to acquire the lock.
+ */
+int console_trylock(void)
So this one returns -1 on success, not 1? Why?
Yup. All callers just test for non-zero, so...
---
a/kernel/printk.c~change-acquire-release_console_sem-to-console_lock-unlock-fix-2
+++ a/kernel/printk.c
@@ -1058,7 +1058,7 @@ EXPORT_SYMBOL(console_lock);
* Tried to acquire a lock which guarantees that the caller has
* exclusive access to the console system and the console_drivers list.
*
- * returns -1 on success, and 0 on failure to acquire the lock.
+ * returns 1 on success, and 0 on failure to acquire the lock.
*/
int console_trylock(void)
{
@@ -1070,7 +1070,7 @@ int console_trylock(void)
}
console_locked = 1;
console_may_schedule = 0;
- return -1;
+ return 1;
}
EXPORT_SYMBOL(console_trylock);
_
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix some 6xx/7xxx CPU setup functions
Benjamin Herrenschmidt b...@kernel.crashing.org writes: In absence of good testing I would appreciate a close inspection of the patch by different pairs of eyes :-) Looks good to me. That broke apparently in 400d221 (ppc32: make cur_cpu_spec a single pointer instead of an array), which changed the calling convention in call_setup_cpu. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Pass the right cpu_spec to -setup_cpu() on 64-bit
You may also want to remove the misleading sentence about PTRRELOC in the preceding comment, since both s and t were already passed through it anyway. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix some 6xx/7xxx CPU setup functions
On Fri, 2011-01-21 at 10:48 +0100, Andreas Schwab wrote: Benjamin Herrenschmidt b...@kernel.crashing.org writes: In absence of good testing I would appreciate a close inspection of the patch by different pairs of eyes :-) Looks good to me. That broke apparently in 400d221 (ppc32: make cur_cpu_spec a single pointer instead of an array), which changed the calling convention in call_setup_cpu. Nice, 5 years ago and it's not even my fault :-) Thanks for the review ! Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[patch 1/2] powerpc: Use ARCH_IRQ_INIT_FLAGS
Define the ARCH_IRQ_INIT_FLAGS instead of fixing it up in a loop.
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
arch/powerpc/include/asm/hw_irq.h |2 ++
arch/powerpc/kernel/irq.c | 15 ---
2 files changed, 2 insertions(+), 15 deletions(-)
Index: linux-2.6-tip/arch/powerpc/include/asm/hw_irq.h
===
--- linux-2.6-tip.orig/arch/powerpc/include/asm/hw_irq.h
+++ linux-2.6-tip/arch/powerpc/include/asm/hw_irq.h
@@ -141,6 +141,8 @@ static inline bool arch_irqs_disabled(vo
#endif /* CONFIG_PPC64 */
+#define ARCH_IRQ_INIT_FLAGSIRQ_NOREQUEST
+
/*
* interrupt-retrigger: should we handle this via lost interrupts and IPIs
* or should we not care like we do now ? --BenH.
Index: linux-2.6-tip/arch/powerpc/kernel/irq.c
===
--- linux-2.6-tip.orig/arch/powerpc/kernel/irq.c
+++ linux-2.6-tip/arch/powerpc/kernel/irq.c
@@ -1074,21 +1074,6 @@ void irq_free_virt(unsigned int virq, un
int arch_early_irq_init(void)
{
- struct irq_desc *desc;
- int i;
-
- for (i = 0; i NR_IRQS; i++) {
- desc = irq_to_desc(i);
- if (desc)
- desc-status |= IRQ_NOREQUEST;
- }
-
- return 0;
-}
-
-int arch_init_chip_data(struct irq_desc *desc, int node)
-{
- desc-status |= IRQ_NOREQUEST;
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[patch 0/2] Sparse irq cleanup - Resend
The following series cleans up the left overs of the old sparse irq code. Thanks, tglx ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[patch 2/2] powerpc: Use new irq allocator
Use the new functions and free the descriptor when the virq is
destroyed.
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
arch/powerpc/kernel/irq.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
Index: linux-2.6-tip/arch/powerpc/kernel/irq.c
===
--- linux-2.6-tip.orig/arch/powerpc/kernel/irq.c
+++ linux-2.6-tip/arch/powerpc/kernel/irq.c
@@ -678,16 +678,15 @@ void irq_set_virq_count(unsigned int cou
static int irq_setup_virq(struct irq_host *host, unsigned int virq,
irq_hw_number_t hwirq)
{
- struct irq_desc *desc;
+ int res;
- desc = irq_to_desc_alloc_node(virq, 0);
- if (!desc) {
+ res = irq_alloc_desc_at(virq, 0);
+ if (res != virq) {
pr_debug(irq: - allocating desc failed\n);
goto error;
}
- /* Clear IRQ_NOREQUEST flag */
- desc-status = ~IRQ_NOREQUEST;
+ irq_clear_status_flags(virq, IRQ_NOREQUEST);
/* map it */
smp_wmb();
@@ -696,11 +695,13 @@ static int irq_setup_virq(struct irq_hos
if (host-ops-map(host, virq, hwirq)) {
pr_debug(irq: - mapping failed, freeing\n);
- goto error;
+ goto errdesc;
}
return 0;
+errdesc:
+ irq_free_descs(virq, 1);
error:
irq_free_virt(virq, 1);
return -1;
@@ -879,9 +880,9 @@ void irq_dispose_mapping(unsigned int vi
smp_mb();
irq_map[virq].hwirq = host-inval_irq;
- /* Set some flags */
- irq_to_desc(virq)-status |= IRQ_NOREQUEST;
+ irq_set_status_flags(virq, IRQ_NOREQUEST);
+ irq_free_descs(virq, 1);
/* Free it */
irq_free_virt(virq, 1);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Globally s/struct irq_host/struct irq_domain/
For this to make sense, it really needs to also rename irq_host_ops structure, the IRQ_HOST_MAP* #defines, and the irq_*_host functions. It also /should/ adjust the users of irq_domain to rename function local variables and structure members. Otherwise there will be an even worse mismatch in naming. Happy to do so, but last time we talked about this, we decided not to do *that* aspect of the rename with this patch, and that we'd get to it later with follow on patches once this step was done. Your call; just let me know. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Globally s/struct irq_host/struct irq_domain/
On Fri, Jan 21, 2011 at 10:19 AM, Jon Loeliger j...@jdl.com wrote: For this to make sense, it really needs to also rename irq_host_ops structure, the IRQ_HOST_MAP* #defines, and the irq_*_host functions. It also /should/ adjust the users of irq_domain to rename function local variables and structure members. Otherwise there will be an even worse mismatch in naming. Happy to do so, but last time we talked about this, we decided not to do *that* aspect of the rename with this patch, and that we'd get to it later with follow on patches once this step was done. I always reserve the right to change my mind. }:- Sorry about that, but I actually applied the patch this morning with the thought that I'd get Linus to pick it up late to avoid collisions in linux-next. However, when I actually looked at the result I realized that at the very least, the irq_host_ops, the #defines, and the irq_*_host functions absolutely have to be renamed at the same time. Not necessarily in the same patch, but definitely at the same time. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Globally s/struct irq_host/struct irq_domain/
I always reserve the right to change my mind. }:- Naturally! Sorry about that, No problem. The thought back then was that we'd hit the global piece and then we'd buy the time to hit the local pieces as we could. but I actually applied the patch this morning with the thought that I'd get Linus to pick it up late to avoid collisions in linux-next. Makes sense. However, when I actually looked at the result I realized that at the very least, the irq_host_ops, the #defines, and the irq_*_host functions absolutely have to be renamed at the same time. Not necessarily in the same patch, but definitely at the same time. Will do! jdl ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix some 6xx/7xxx CPU setup functions
On Fri, Jan 21, 2011 at 12:35 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Some of those functions try to adjust the CPU features, for example to remove NAP support on some revisions. However, they seem to use r5 as an index into the CPU table entry, which might have been right a long time ago but no longer is. r4 is the right register to use. Can you quantify 'a long time ago'? Is this compiler dependent? This probably caused some off behaviours on some PowerMac variants using 750cx or 7455 processor revisions. what about a 750gx? Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- Can somebody with one of these PowerMacs test this ? I only managed to find a 7448 which not directly affected... I have a GigE (PowerMac 3,4?) with an upgrade card that has a pair of 7455s on it and an 8600 with a 750GX cpu card. I can probably test this on the GigE. It is running 2.6.36. Is that recent enough? The 8600 is not cooperating. The GigE is running 2.6.36 compiled with 4.3.5 built from sources. It seems to run fine. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
BootX
Hi, Anyone familiar with BootX? Could my problems with the 8600 be related to some interaction with BootX? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix some 6xx/7xxx CPU setup functions
On Fri, 2011-01-21 at 12:15 -0600, kevin diggs wrote: I have a GigE (PowerMac 3,4?) with an upgrade card that has a pair of 7455s on it and an 8600 with a 750GX cpu card. I can probably test this on the GigE. It is running 2.6.36. Is that recent enough? The 8600 is not cooperating. The GigE is running 2.6.36 compiled with 4.3.5 built from sources. It seems to run fine. The bug would have caused the kernel to allow enabling of nap mode when idle on machines where this is buggy and can cause loss of cache coherency among others. I really don't remember off hand which specific machines may or may not have been affected. But I'd like at least people to verify that my patches to fix that aren't causing a regression for people like you who don't seem to have problems :-) The bug was introduced a while back in 2005. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote: Hi, Anyone familiar with BootX? Could my problems with the 8600 be related to some interaction with BootX? It's possible. Have you tried using OF booting instead ? The 8600 should be cable to boot off SCSI or netboot COFF images. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Setting GPIO to trigger interrupt on mpc85xx
Hi, I am working on the fsl P1020rdb kit with the 2.6.32 linux kernel that came with the kit and I am trying to get an GPIO to trigger an interrupt. I am fairly new and have been stumbling for quite a bit with no success so I am hoping some of you experts out there can give me some pointers. **What I have tried so far**: I am implementing the interrupt setup on my custom GPIO module during its init. I started following the information available in Linux Device Drivers, Third Edition but it turns out to be out of date or incompatible with the ppc platform. (The device tree, the hwirq to virq mapping... even though the number turns out to be the same for GPIO, etc.) Initially I was only calling request_irq but I got ENOSYS. That was solved by calling irq_create_mapping but then the module init was stuck at the request_irq (with the isr continuously being called.) That was resolved when I ended up using the device tree by calling irq_of_parse_and_map and using set_irq_handler before calling request_irq. Now the module successfully init and I can see the isr entry in /proc/interrupt but when I physically toggle my GPIO pin, the handler set by set_irq_handler was being called continuously (and then crash) while the isr set by request_irq was never called. Another thing I don't understand is that the /proc/interrupt entry say the gpio interrupt is OpenPIC Level when the GPIO interrupt is suppose to be edge only (either falling only or both.) My dts interrupt entry for the GPIO is 47 2, which should indicates edge trigger right? **My questions**: What are the relationship between set_irq_handler, set_irq_type and request_irq? Are the first two supposed to be a replacement of the 3rd or are they suppose to be used concurrently? What are the differences between the handler set by set_irq_handler and the isr set by request_irq? Which one is called first? Or should only one of them get set at all time? (I was reading http://www.kernel.org/pub/linux/kernel/people/tglx/armirq/DocBook/index. html but I am still very confused.) Which signals are those IRQ type referring to? Are they referring to the triggering signal (GPIO in my case) or the PIC signal to the cpu core? What are the things I need to do in the IRQ handler/isr to terminate an interrupt? I know I need to clear the event register (which is GPIER in my case) which I have done but that didn't stop the handler from getting call again. Must I also disable the interrupt? For the isr set by request_irq, I also return IRQ_HANDLED... is that sufficient? For the handler set by set_irq_handler, do I need to call other handler? I noticed there are generic_handle_irq and handle_(level/edge, etc)_irq... am I suppose to call those to terminate an interrupt? I also noticed there are eoi() and end() in desc-chip. (I assume those are for the PIC)... am I suppose to call those as well? As you can see... I am very much confused and have lots of questions. Any help from you folks is much appreciated. Regards, Kenny Ho ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
elf section .text.unlikely
Hi, I am trying to get a PowerMac 8600 to boot past 2.6.28. I can boot 2.6.28 compiled with either 3.3.3 or 3.4.6. I can't get 2.6.28 to boot using 4.3.5. The 4.3.5 vmlinux has a section '.text.unlikely' that the 3.4.6 version does not. Anyone know what this might be? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Hi, This would require quik, right? I went to penguinppc.org and tried to get the latest BootX and quik but the links are dead. Do you know where the latest versions are? kevin On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote: Hi, Anyone familiar with BootX? Could my problems with the 8600 be related to some interaction with BootX? It's possible. Have you tried using OF booting instead ? The 8600 should be cable to boot off SCSI or netboot COFF images. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
On Fri, 2011-01-21 at 19:48 -0600, kevin diggs wrote: Hi, This would require quik, right? I went to penguinppc.org and tried to get the latest BootX and quik but the links are dead. Do you know where the latest versions are? That link still works: kevin On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote: Hi, Anyone familiar with BootX? Could my problems with the 8600 be related to some interaction with BootX? It's possible. Have you tried using OF booting instead ? The 8600 should be cable to boot off SCSI or netboot COFF images. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
On Fri, 2011-01-21 at 19:48 -0600, kevin diggs wrote: Hi, This would require quik, right? I went to penguinppc.org and tried to get the latest BootX and quik but the links are dead. Do you know where the latest versions are? That link still works: Oops... typing FAIL :-) I meant: http://penguinppc.org/bootloaders/quik/ However, it's possible that distros like debian have done more changes to it. Another option is to netboot a zImage directly, which works if it's not too big. Cheers, Ben. kevin On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote: Hi, Anyone familiar with BootX? Could my problems with the 8600 be related to some interaction with BootX? It's possible. Have you tried using OF booting instead ? The 8600 should be cable to boot off SCSI or netboot COFF images. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Hi, The link: http://www.shiner.info/?files/Yellow%20Dog%20Linux%204/quik to download the latest source does not seem to have anything useful??? kevin On Fri, Jan 21, 2011 at 7:50 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2011-01-21 at 19:48 -0600, kevin diggs wrote: Hi, This would require quik, right? I went to penguinppc.org and tried to get the latest BootX and quik but the links are dead. Do you know where the latest versions are? That link still works: Oops... typing FAIL :-) I meant: http://penguinppc.org/bootloaders/quik/ However, it's possible that distros like debian have done more changes to it. Another option is to netboot a zImage directly, which works if it's not too big. Cheers, Ben. kevin On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote: Hi, Anyone familiar with BootX? Could my problems with the 8600 be related to some interaction with BootX? It's possible. Have you tried using OF booting instead ? The 8600 should be cable to boot off SCSI or netboot COFF images. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: elf section .text.unlikely
For what it is worth, this section contains dump_stack, panic, and printk Thanks! kevin On Fri, Jan 21, 2011 at 7:40 PM, kevin diggs diggskevi...@gmail.com wrote: Hi, I am trying to get a PowerMac 8600 to boot past 2.6.28. I can boot 2.6.28 compiled with either 3.3.3 or 3.4.6. I can't get 2.6.28 to boot using 4.3.5. The 4.3.5 vmlinux has a section '.text.unlikely' that the 3.4.6 version does not. Anyone know what this might be? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
On Fri, 2011-01-21 at 20:03 -0600, kevin diggs wrote: Hi, The link: http://www.shiner.info/?files/Yellow%20Dog%20Linux%204/quik to download the latest source does not seem to have anything useful??? Ah right. 2.0e is still there tho. Try to have a look at what's in distros like debian or genpoo.. Cheers, Ben. kevin On Fri, Jan 21, 2011 at 7:50 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2011-01-21 at 19:48 -0600, kevin diggs wrote: Hi, This would require quik, right? I went to penguinppc.org and tried to get the latest BootX and quik but the links are dead. Do you know where the latest versions are? That link still works: Oops... typing FAIL :-) I meant: http://penguinppc.org/bootloaders/quik/ However, it's possible that distros like debian have done more changes to it. Another option is to netboot a zImage directly, which works if it's not too big. Cheers, Ben. kevin On Fri, Jan 21, 2011 at 3:21 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2011-01-21 at 13:26 -0600, kevin diggs wrote: Hi, Anyone familiar with BootX? Could my problems with the 8600 be related to some interaction with BootX? It's possible. Have you tried using OF booting instead ? The 8600 should be cable to boot off SCSI or netboot COFF images. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: elf section .text.unlikely
Hi, One more thing: The last message printed is: Driver 'sd' needs updating - please us bus_type methods The mesh SCSI controller seems to successfully scan the bus. The next message that a 3.4.6 compiled kernel prints are details about disk sda (from SCSI disk driver?). 4.3.5 keyboard is dead. Jog any thoughts? Thanks! kevin On Fri, Jan 21, 2011 at 8:31 PM, kevin diggs diggskevi...@gmail.com wrote: For what it is worth, this section contains dump_stack, panic, and printk Thanks! kevin On Fri, Jan 21, 2011 at 7:40 PM, kevin diggs diggskevi...@gmail.com wrote: Hi, I am trying to get a PowerMac 8600 to boot past 2.6.28. I can boot 2.6.28 compiled with either 3.3.3 or 3.4.6. I can't get 2.6.28 to boot using 4.3.5. The 4.3.5 vmlinux has a section '.text.unlikely' that the 3.4.6 version does not. Anyone know what this might be? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
