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

Reply via email to