Write to Port 0Cf8H Fails with Segfault

Write to port 0cf8h fails with segfault

Linux does not, by default, allow userland code to write to I/O ports. (Doing so can be quite dangerous from a security perspective.) If you’d like Linux to give your process access to the I/O ports, you have two options:

1. You can use the ioperm system call. However, ioperm has been deprecated for some time, and Josh Triplett recently pushed a patch that allows users to remove it from the kernel. Avoid ioperm if you want your code to continue working for the forseeable future.

2. You can read from and write to /dev/port. See mem(4). Your process will, obviously, need read and write permissions for /dev/mem; on Wheezy, that means it needs to run as root, unless you change the permissions on the device.

PCI configuration space registers - write values

The "interrupt line" field (at offset 0x03C in PCI configuration space) literally does nothing.

The Full Story

PCI cards could use up to 4 "PCI IRQs" at the PCI slot; and use them in order (so if you have ten PCI cards that all have one IRQ, then they'll all use the first PCI IRQ at the slot).

There's a tricky "barber pole" arrangement to connect "PCI IRQ at the slot" to "PCI IRQ at the host controller" that is designed to reduce IRQ sharing. If you have ten PCI cards that all have one IRQ, then they'll all use the first PCI IRQ at the slot, but the first IRQ at each PCI slot will be connected to a different PCI IRQ at the host controller. All of this is hard-wired and can not be changed by software.

To complicate things more; to connect PCI IRQs (from the PCI host controller) to the legacy PIC chips, a special "PCI IRQ router" was added. In theory the configuration of the "PCI IRQ router" can be changed by software (if you can find the documentation that describes a table that describes the location, capabilities and restrictions of the "PCI IRQ router").

Without the firmware's help it'd be impossible for an OS to figure out which PIC chip input a PCI device actually uses. For that reason, the firmware figures it out during boot and then stores "PIC chip input number" somewhere for the OS to find. That is what the "interrupt line" register is - it's just an 8-bit register that can store anything you like (that the BIOS/firmware uses to store "PIC chip input number").

PowerPC MPC8245 JTAG

It appears that it is a limitation of JTAG to read memory with MEMGO bit low.

It appears that the BDI2000 JTAG device requires that the MPC8245 memory controller be active in order to read from ROM or RAM, even though the documentation would lead one to think that MEMGO bit is for SDRAM only and not ROM.

If a configuration for the BDI2000 is created with no [INIT] section, the default value of the MEMGO bit is low on power up, the BDI2000 cannot read ROM. All zeros are read.

Thus any time the MEMGO bit is low, the JTAG device cannot be used to single step or read memory.

How do I login and download a file from a https web page from Java?

I agree with Alnitak that the problem is likely storing and returning cookies.

Another good option I have used is HttpClient from Jakarta Commons.

It's worth noting, as an aside, that if this is a server you control, you should be aware that sending the username and password as querystrings is not secure (even if you're using HTTPS). HttpClient supports sending parameters using POST, which you should consider.

How do I raise an http error/exception from a python CGI script?

It seems like that's the way to do it. As long as you're correctly following the header format.

Here's someone else who asked the same question, more or less.

Returning http status codes in Python CGI

Are you following HTTP specs when you print the status code? Can you try printing just the status code and not its description?

Maybe like...

print '''Status:501
Content-type: text/html

'''

Or it should be like...

print '''HTTP/1.1 501 Not Implemented
Content-type: text/html

'''

Could you test with your setup to verify?

Returning status from CGI:

http://oreilly.com/openbook/cgi/ch03_07.html

I guess "Status: 501 Not Implemented" like you had it originally is the way to go. I don't know why it's not working. Are you printing any non-header content before printing the status code?

Yet another source that confirms you're doing it right (look in section 6.3.3.):

http://www.ietf.org/rfc/rfc3875

EDIT 1,2,3: extended answer

---

Related Topics