finding out the boot cpu number from userspace
Hi,
assuming cpu 0 is the boot cpu sounds fragile/incorrect, but for irqbalanced I'd like to find out which cpu is the boot cpu, is there a good way of doing so ?
The reason for needing this is that some firmware only likes running on the boot cpu so I need to bind firmware-related irq's to that cpu ideally.
Greetings,
Arjan van de Ven
Quoted 5 lines · Arjan van de Ven
Hi,
assuming cpu 0 is the boot cpu sounds fragile/incorrect, but for irqbalanced I'd like to find out which cpu is the boot cpu, is there a good way of doing so ?
Parsing MP tables ? Don't know how well this holds up in a post-MP ACPI world though. x86info has some code for this already, which I stole from some other program I long since forgot about.
Dave
Quoted 6 lines · Arjan van de Ven
assuming cpu 0 is the boot cpu sounds fragile/incorrect, but for irqbalanced I'd like to find out which cpu is the boot cpu, is there a good way of doing so ?
The reason for needing this is that some firmware only likes running on the boot cpu so I need to bind firmware-related irq's to that cpu ideally.
How about something like mptable which will give you the BSP flag from the MP table? I believe this gropes around /dev/mem.
Quoted 11 lines · Zwane Mwaikambo
Quoted 6 lines · Arjan van de Ven
assuming cpu 0 is the boot cpu sounds fragile/incorrect, but for irqbalanced I'd like to find out which cpu is the boot cpu, is there a good way of doing so ?
The reason for needing this is that some firmware only likes running on the boot cpu so I need to bind firmware-related irq's to that cpu ideally.
How about something like mptable which will give you the BSP flag from the MP table? I believe this gropes around
/dev/mem.
Once CPUs other than 0 are enabled, they take part in the boot process. They don't spin forever so I don't understand the notion of 'boot CPU'.
Also firmware has no clue about what CPU is tickling it. There is no possible way for it to find out, or even care. If some hardware engineer claimed differently, he/she/it is pulling your chain (or needs to learn how busses, CPUs and FPGAs work)! There is a Virtual Wire specification that guarantees that no firmware can possibly care.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.
Quoted 8 lines · Arjan van de Ven
Hi,
assuming cpu 0 is the boot cpu sounds fragile/incorrect, but for irqbalanced I'd like to find out which cpu is the boot cpu, is there a good way of doing so ?
The reason for needing this is that some firmware only likes running on the boot cpu so I need to bind firmware-related irq's to that cpu ideally.
Grab the physical CPU id during boot up and stick it in the /proc/cpuinfo as another information line "Boot device: Yes/no"
Just don't use "Processor" in the string or some glibc's start getting strange ideas about the CPU count.
Quoted 6 lines
assuming cpu 0 is the boot cpu sounds fragile/incorrect, but for irqbalanced I'd like to find out which cpu is the boot cpu, is there a good way of doing so ?
The reason for needing this is that some firmware only likes running on the boot cpu so I need to bind firmware-related irq's to that cpu ideally.
On any sane arch, cpu 0 *IS* always the boot CPU, as we dynamically number CPUs that way ... that doesn't mean that it's apicid 0. I believe that PPC64 screwed this up, but AFAIK, everyone else gets it correct ... ;-)
M.
==> Regarding Re: finding out the boot cpu number from userspace; "Martin J. Bligh" <[email protected]> adds:
Quoted 7 lines
Quoted 7 lines
assuming cpu 0 is the boot cpu sounds fragile/incorrect, but for irqbalanced I'd like to find out which cpu is the boot cpu, is there a good way of doing so ?
The reason for needing this is that some firmware only likes running on the boot cpu so I need to bind firmware-related irq's to that cpu ideally.
mbligh> On any sane arch, cpu 0 *IS* always the boot CPU, as we dynamically mbligh> number CPUs that way ... that doesn't mean that it's apicid 0. I mbligh> believe that PPC64 screwed this up, but AFAIK, everyone else gets mbligh> it correct ... ;-)
Hmm, do we need to do any special handling for this in the kexec case? ISTR having some issues with this when using bootimg years back.
-Jeff
Quoted 10 lines
==> Regarding Re: finding out the boot cpu number from userspace; "Martin J. Bligh" <[email protected]> adds:
Quoted 7 lines
Quoted 7 lines
assuming cpu 0 is the boot cpu sounds fragile/incorrect, but for irqbalanced I'd like to find out which cpu is the boot cpu, is there a good way of doing so ?
The reason for needing this is that some firmware only likes running on the boot cpu so I need to bind firmware-related irq's to that cpu ideally.
Quoted 7 lines
mbligh> On any sane arch, cpu 0 *IS* always the boot CPU, as we dynamically mbligh> number CPUs that way ... that doesn't mean that it's apicid 0. I mbligh> believe that PPC64 screwed this up, but AFAIK, everyone else gets mbligh> it correct ... ;-)
Hmm, do we need to do any special handling for this in the kexec case? ISTR having some issues with this when using bootimg years back.
Eric went to some lengths to migrate us back to the original boot CPU before kexec'ing. I think this is unnecessary - the new kernel should handle booting on any CPU just fine (there was a panic in there at one point if the boot CPU didn't match the BIOS's spec'ed one, but I removed it).
M.
Quoted 5 lines · Martin J. Bligh
Eric went to some lengths to migrate us back to the original boot CPU before kexec'ing. I think this is unnecessary - the new kernel should handle booting on any CPU just fine (there was a panic in there at one point if the boot CPU didn't match the BIOS's spec'ed one, but I removed it).
Several systems have broken SMM or BIOS functionality that requires the *real* boot processor is used. The panic was correct and should be restored. See apm_power_off() for one example.
Quoted 9 lines
Quoted 5 lines
Eric went to some lengths to migrate us back to the original boot CPU before kexec'ing. I think this is unnecessary - the new kernel should handle booting on any CPU just fine (there was a panic in there at one point if the boot CPU didn't match the BIOS's spec'ed one, but I removed it).
Several systems have broken SMM or BIOS functionality that requires the *real* boot processor is used. The panic was correct and should be restored. See
apm_power_off()for one example.
Ah, OK didn't know that ... however, I'm not convinced that panicing is really that useful ... what happens if you proceed? IIRC, this is before console_init as well, so people won't even see the error. At least it should only do that on machines that are borked in such a fashion - 99% of machines will work fine, AFAICS.
M.
Quoted 5 lines · Martin J. Bligh
Ah, OK didn't know that ... however, I'm not convinced that panicing is really that useful ... what happens if you proceed? IIRC, this is before
console_initas well, so people won't even see the error. At least it should only do that on machines that are borked in such a fashion - 99% of machines will work fine, AFAICS.
The APM power off one is actually very common. Another one the ACPI guys are now fighting that we also hit with SMM is E750x systems, where both SMM traps and ACPI appear only to work on the boot CPU.
The panic at least made sure that we didnt end up with random mysterious later problems that would be "fun" to debug.
(Note btw we sometimes care that kexec runs the new boot code on the right processor because the 16bit entry points for some things also use SMM traps on certain bioses in order to get a clean entry/stack/etc)
Alan
Quoted 3 lines · Arjan van de Ven
assuming cpu 0 is the boot cpu sounds fragile/incorrect, but for irqbalanced I'd like to find out which cpu is the boot cpu, is there a good way of doing so ?
cpu numbers are logical not physical, so can't we assume cpu-0 is *always* the boot cpu?