Aha. If the destination of a microop is the high byte version of a register, I was using the value in the low byte when computing condition codes because I was just going off of the size. Apparently that's not something that's relied on very often.
Gabe Gabe Black wrote: > If I add printks to it it starts working, so it must be an instruction > bug. Thanks for the help thus far. > > Gabe > > Ali Saidi wrote: > >> It prints all output, regardless of the loglevel (KERN_INFO, >> KERN_DEBUG, ....). >> >> Perhaps you should also define DEBUG in >> http://lxr.linux.no/linux+v2.6.22.9/arch/i386/pci/pci.h >> . Might get some more helpful messages from that as well. >> >> Perhaps also printing out the various variables in that if statement >> would help trace the problem as well. >> >> Ali >> >> On Dec 17, 2008, at 11:21 PM, Gabe Black wrote: >> >> >> >>> That's entirely possible. What does setting that variable do? >>> >>> http://lxr.linux.no/linux+v2.6.22.9/arch/i386/pci/i386.c#L158 >>> >>> Ali Saidi wrote: >>> >>> >>>> I think you're confused by the output. The line, "debug: ignoring >>>> loglevel setting." means that the ignore_loglevel=1 worked. Do you >>>> know where those Cannot allocate resource statements are coming from? >>>> Searching the code I can't find any x86 code that is printing them. >>>> >>>> Ali >>>> >>>> >>>> >>>> On Dec 17, 2008, at 11:20 PM, Gabe Black wrote: >>>> >>>> >>>> >>>> >>>>> Here's the console output. It ignored the ignore_loglevel=1 >>>>> apparently. >>>>> 0:0:0 is the host/PCI bridge and 0:4:0 is the IDE controller. The >>>>> parts >>>>> that it can't configure are the legacy IO BARs (I think) and one of >>>>> the >>>>> BARs on the bridge. I don't know if the bridge normally has an >>>>> active >>>>> BAR, but the fact that it's there at all is to try to get this to >>>>> work. >>>>> >>>>> Gabe >>>>> >>>>> ==== m5 slave terminal: Terminal 0 ==== >>>>> Linux version 2.6.22.9 (blac...@nacho) (gcc version 4.1.2 (Gentoo >>>>> 4.1.2)) #2 Mon Oct 8 13:13:00 PDT 2007 >>>>> Command line: earlyprintk=ttyS0 console=ttyS0 lpj=9608015 >>>>> ide1=noprobe >>>>> ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe >>>>> ignore_loglevel=1 >>>>> BIOS-provided physical RAM map: >>>>> BIOS-e820: 0000000000000000 - 0000000000100000 (reserved) >>>>> BIOS-e820: 0000000000100000 - 0000000007fffffe (usable) >>>>> end_pfn_map = 32767 >>>>> kernel direct mapping tables up to 7fff000 @ 100000-102000 >>>>> DMI 2.5 present. >>>>> Zone PFN ranges: >>>>> DMA 256 -> 4096 >>>>> DMA32 4096 -> 1048576 >>>>> Normal 1048576 -> 1048576 >>>>> early_node_map[1] active PFN ranges >>>>> 0: 256 -> 32767 >>>>> Intel MultiProcessor Specification v1.4 >>>>> MPTABLE: OEM ID: MPTABLE: Product ID: MPTABLE: APIC at: 0xFEE00000 >>>>> Processor #0 (Bootup-CPU) >>>>> I/O APIC #1 at 0xFEC00000. >>>>> Setting APIC routing to flat >>>>> Processors: 1 >>>>> Allocating PCI resources starting at 10000000 (gap: >>>>> 7fffffe:f8000002) >>>>> Built 1 zonelists. Total pages: 30458 >>>>> Kernel command line: earlyprintk=ttyS0 console=ttyS0 lpj=9608015 >>>>> ide1=noprobe ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe >>>>> ignore_loglevel=1 >>>>> ide_setup: ide1=noprobe >>>>> ide_setup: ide2=noprobe >>>>> ide_setup: ide3=noprobe >>>>> ide_setup: ide4=noprobe >>>>> ide_setup: ide5=noprobe >>>>> debug: ignoring loglevel setting. >>>>> Initializing CPU#0 >>>>> PID hash table entries: 512 (order: 9, 4096 bytes) >>>>> time.c: Detected 1999.998 MHz processor. >>>>> Console: colour dummy device 80x25 >>>>> console handover: boot [earlyser0] -> real [ttyS0] >>>>> Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) >>>>> Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) >>>>> Checking aperture... >>>>> Memory: 121440k/131068k available (3742k kernel code, 8456k >>>>> reserved, >>>>> 1874k data, 232k init) >>>>> Calibrating delay loop (skipped)... 4804.00 BogoMIPS preset >>>>> Mount-cache hash table entries: 256 >>>>> CPU: Hammer stepping 01 >>>>> ACPI: Core revision 20070126 >>>>> ACPI Exception (tbxface-0618): AE_NO_ACPI_TABLES, While loading >>>>> namespace from ACPI tables [20070126] >>>>> ACPI: Unable to load the System Description Tables >>>>> Using local APIC timer interrupts. >>>>> result 488279 >>>>> Detected 0.488 MHz APIC timer. >>>>> NET: Registered protocol family 16 >>>>> PCI: Using configuration type 1 >>>>> ACPI: Interpreter disabled. >>>>> Linux Plug and Play Support v0.97 (c) Adam Belay >>>>> pnp: PnP ACPI: disabled >>>>> SCSI subsystem initialized >>>>> libata version 2.21 loaded. >>>>> usbcore: registered new interface driver usbfs >>>>> usbcore: registered new interface driver hub >>>>> usbcore: registered new device driver usb >>>>> PCI: Probing PCI hardware >>>>> PCI: Probing PCI hardware (bus 00) >>>>> PCI: Cannot allocate resource region 3 of device 0000:00:00.0 >>>>> PCI: Cannot allocate resource region 0 of device 0000:00:04.0 >>>>> PCI: Cannot allocate resource region 1 of device 0000:00:04.0 >>>>> PCI: Cannot allocate resource region 2 of device 0000:00:04.0 >>>>> PCI: Cannot allocate resource region 3 of device 0000:00:04.0 >>>>> PCI-GART: No AMD northbridge found. >>>>> NET: Registered protocol family 2 >>>>> >>>>> Ali Saidi wrote: >>>>> >>>>> >>>>> >>>>>> Could you post the most current set of kernel messages at boot? >>>>>> Preferable if you've got kernel parameters working with >>>>>> ignore_loglevel=1 or just hardcoding ignore_loglevel = 1 in kernel/ >>>>>> printk.c. That should give us some information about what PCI is >>>>>> seeing and what it's not and might help pinpoint the problem. >>>>>> >>>>>> Ali >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Dec 17, 2008, at 1:28 AM, Gabe Black wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Anything? >>>>>>> >>>>>>> Gabe >>>>>>> >>>>>>> Ali Saidi wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> At least in Alpha configuring the root bus wasn't required. This >>>>>>>> could >>>>>>>> be different in x86 since alpha just had a fixed mapping in >>>>>>>> memory >>>>>>>> space, and x86 might not (but since there is so much space in 64 >>>>>>>> bit >>>>>>>> linux it seems like it would). I can't look at the minute, but >>>>>>>> I'll >>>>>>>> poke around later today and see if I un-earth anything that might >>>>>>>> be >>>>>>>> helpful. >>>>>>>> >>>>>>>> ali >>>>>>>> >>>>>>>> On Dec 16, 2008, at 2:55 AM, Gabe Black wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Hi everybody. I'm currently trying to twist Linux's arm into >>>>>>>>> recognizing and configuring the PCI IDE controller, and the >>>>>>>>> thing >>>>>>>>> I'm >>>>>>>>> stuck on right now is I can't figure out how the IO resources of >>>>>>>>> the >>>>>>>>> root bus are assigned. I found a function for child busses which >>>>>>>>> is >>>>>>>>> bases off of the IO base and IO limit registers in the bridge, >>>>>>>>> something >>>>>>>>> I hoped would be true of the root bus as well. It looks like >>>>>>>>> something >>>>>>>>> somewhere is supposed to extend the kernel's tree of "resource" >>>>>>>>> objects >>>>>>>>> to allocate the space the PCI bus responds to, but either that's >>>>>>>>> never >>>>>>>>> happening or for some reason the kernel is losing track of it. >>>>>>>>> One >>>>>>>>> thing >>>>>>>>> which may have something to do with it is that the kernel is >>>>>>>>> trying to >>>>>>>>> configure the host bridges config registers as a device rather >>>>>>>>> than a >>>>>>>>> bus. It might always do that, but I really don't know. There >>>>>>>>> are a >>>>>>>>> number of tables that end up in memory that may have something >>>>>>>>> to do >>>>>>>>> with it, but I've poked at one of those, the Intel MP table, >>>>>>>>> with no >>>>>>>>> success. There's still the DMI table and the ACPI tables, but >>>>>>>>> I'd >>>>>>>>> hesitate to assume that's the problem. Any help would be >>>>>>>>> appreciated >>>>>>>>> since grepping for "resource" isn't getting me too far. >>>>>>>>> >>>>>>>>> Gabe >>>>>>>>> _______________________________________________ >>>>>>>>> m5-dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://m5sim.org/mailman/listinfo/m5-dev >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> m5-dev mailing list >>>>>>>> [email protected] >>>>>>>> http://m5sim.org/mailman/listinfo/m5-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> m5-dev mailing list >>>>>>> [email protected] >>>>>>> http://m5sim.org/mailman/listinfo/m5-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> m5-dev mailing list >>>>>> [email protected] >>>>>> http://m5sim.org/mailman/listinfo/m5-dev >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> m5-dev mailing list >>>>> [email protected] >>>>> http://m5sim.org/mailman/listinfo/m5-dev >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> m5-dev mailing list >>>> [email protected] >>>> http://m5sim.org/mailman/listinfo/m5-dev >>>> >>>> >>>> >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> >>> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
