maindmidecode - Support: sr #109339, please uncomment PIR decoding in...

 
 

sr #109339: please uncomment PIR decoding in biosdecode.c

Submitter:  None
Submitted:  Fri 23 Jun 2017 05:36:31 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  khali
Originator Email:  -email is unavailable- Open/Closed:  Closed
Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 25 Jul 2017 09:25:44 AM UTC, comment #8: 
Jean Delvare <khali>
Group administrator
Mon 17 Jul 2017 01:50:24 PM UTC, comment #7: 


> * If we're using the I/O APIC, avoid using the PCI IRQ
> * routing table


Yes, I assumed you don't need it for IO-APIC,
but for PIC it should be used. Doesn't seem to
be contradicting to the comments you found in
the sources, but I am not an expert in that
either.

Anonymous
Mon 17 Jul 2017 01:26:52 PM UTC, comment #6: 

I am no expert when it comes to interrupt routing. However I see the following comment in the Linux kernel source:

void __init pcibios_irq_init(void)
{
(...)
/*
* If we're using the I/O APIC, avoid using the PCI IRQ
* routing table
*/
if (io_apic_assign_pci_irqs)
pirq_table = NULL;

and also the following in arch/x86/pci/acpi.c:

printk(KERN_INFO "PCI: Using ACPI for IRQ routing\n");
(...)
pcibios_enable_irq = acpi_pci_irq_enable;
pcibios_disable_irq = acpi_pci_irq_disable;

So I assumed that the pirq_table will only be used on very old systems. But I admit I did not follow all the code paths. I'm fine implementing this in biosdecode anyway.

Jean Delvare <khali>
Group administrator
Mon 17 Jul 2017 01:12:34 PM UTC, comment #5: 

Yes, only implementing a long option is intentional. I don't think short options are that useful for things you don't type on the command line on a daily basis. Chances of conflict as the software evolves are high, and at the end of the day you'll end up looking up the manual page to figure out what the proper option was. Long options are in fact easier to remember, and more straightforward to interpret when sharing command lines with others.

Jean Delvare <khali>
Group administrator
Mon 17 Jul 2017 12:22:15 PM UTC, comment #4: 

There seems to be an oddity that you
didn't add 'P' to optstring, so only
the long format works. But in help
you documented only the long opt too,
so I wonder if this was intentional.

Is PIR completely superseded, or only
for the routing to APIC? I needed to
figure out the routing to legacy PIC,
and biosdecode just looked like the
simplest possibility to do that.

Anonymous
Mon 17 Jul 2017 09:21:17 AM UTC, comment #3: 

Please give a try to the attached patch.

BTW I'm curious why you care so much about the PIR table. As I understand it, it was superseded by ACPI on every modern computer, so interest should be very limited nowadays.

Jean Delvare <khali>
Group administrator
Tue 27 Jun 2017 01:49:10 PM UTC, comment #2: 

Yes, link values may be vendor-specific.

---
A value of 1 through the number of interrupt pins on the Interrupt
Router means the pin is connected to that
PIRQn# pin of
the Interrupt
Router.

A value larger than the number of interrupt pins on the Interrupt
Router means the pin is wire
OR'd together with other
slot interrupt pins, but the group is not connected to any
PIRQn# pin on the Interrupt
Router.

Other  interpretations  of  the  link  values  are  possible.  For  instance,  the  link  value  may  indicate  which  byte  of
Configuration  Space  to  access  for  this  link,  or  which  I/O  Port  to  access  for  the  link.  The  specific  interpretation  of  the  link
value is decided by the manufacturer of the Interrupt
Router and is supported by the driver for that
router.
---

I indeed have a PC with the following output:

---
Slot Entry 14: ID 00:04, on-board
Slot Entry 14
ID: 00:04
Link Value for INTA#: 96
IRQ Bitmap for INTA#: 3 4 5 6 10 11 12 14 15
Link Value for INTB#: 97
IRQ Bitmap for INTB#: 3 4 5 6 10 11 12 14 15
Link Value for INTC#: 98
IRQ Bitmap for INTC#: 3 4 5 6 10 11 12 14 15
Link Value for INTD#: 99
IRQ Bitmap for INTD#: 3 4 5 6 10 11 12 14 15
Slot Number: on-board
---

Obviously link values are vendor-specific
here, but I also have PCs where they are
straight-forward.

Please note also the duplicate strings for
"Slot Entry". If you uncomment the full-dump
code, you also need to disable the code
that prints "Slot Entry" string as then
it will be needlessly duplicated.

Anonymous
Tue 27 Jun 2017 09:02:52 AM UTC, comment #1: 

I admit I can't remember why this code is commented out. As far as I can tell, it was originally added that way, so it was never active. Maybe because it makes the output of biosdecode a lot larger, and makes the $PIR section overweight compared to all other sections. Or maybe I was simply not sure if my code was correct.

We could add a command line parameter (--pir=full) to enable the decoding of the $PIR details, and leave the default output unchanged. The detailed output can also be revisited, as it was written so long ago.

I'm not sure which parts you think are vendor specific? The meaning of the "Link" values?

Jean Delvare <khali>
Group administrator
Fri 23 Jun 2017 05:36:31 PM UTC, original submission:  

Hello.

Currently in biosdecode the code that dumps PIR
is commented out, see biosdecode.c:389 and below.
Uncommenting it works perfectly. Yes, I am aware
that some values there are vendor-specific, but
IMHO this is not a reason to just not dump them.
Would it be possible to get that uncommented?

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #41220:  biosdecode-pir-full.patch added by khali (4KiB - text/x-patch - [PATCH] biosdecode: Add option --pir full)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by khali (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-07-25 khali StatusNeed Info Done
        Open/ClosedOpen Closed
    2017-07-17 khali StatusNone Need Info
    2017-07-17 khali Attached File- Added biosdecode-pir-full.patch, #41220
    2017-06-27 khali Assigned toNone khali

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code