|
Armin Steinhoff
|
pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/10/2013 5:50 AM
post101289
|
pci_attach_problem on bus 7
pci_attach_problem on bus 7
This is the PCI bus tree of an ASUS P7P55D motherboard:
-[0000:00]-+-00.0 Intel Corporation Core Processor DMI
+-03.0-[01]----00.0 nVidia Corporation G96 [GeForce 9500 GT]
+-08.0 Intel Corporation Core Processor System Management Registers
+-08.1 Intel Corporation Core Processor Semaphore and Scratchpad Registers
+-08.2 Intel Corporation Core Processor System Control and Status Registers
+-08.3 Intel Corporation Core Processor Miscellaneous Registers
+-10.0 Intel Corporation Core Processor QPI Link
+-10.1 Intel Corporation Core Processor QPI Routing and Protocol Registers
+-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller
+-1b.0 Intel Corporation 5 Series/3400 Series Chipset High Definition Audio
+-1c.0-[06]--
+-1c.4-[05]--
+-1c.5-[04]--
+-1c.6-[03]--
+-1c.7-[02]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller
+-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller
+-1e.0-[07]--+-01.0 Siemens Nixdorf AG Device 4036 ###############################################
| \-02.0 Intel Corporation 82540EM Gigabit Ethernet Controller
+-1f.0 Intel Corporation 5 Series Chipset LPC Interface Controller
+-1f.2 Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller
\-1f.3 Intel Corporation 5 Series/3400 Series Chipset SMBus Controller
Why is "pci_attach_device" not able to attach the device on bus 7 (marked with ####...) ???
Regards
--Armin
|
|
|
|
|
|
Hugh Brown
|
Re: pci_attach_problem on bus 7
|
|
Hugh Brown
05/10/2013 7:26 AM
post101291
|
Re: pci_attach_problem on bus 7
Please supply the output from 'pci -vv' so that I can see all the
information.
On 2013-05-10 5:50 AM, "Armin Steinhoff" <community-noreply@qnx.com> wrote:
>pci_attach_problem on bus 7
>
>This is the PCI bus tree of an ASUS P7P55D motherboard:
>
>-[0000:00]-+-00.0 Intel Corporation Core Processor DMI
> +-03.0-[01]----00.0 nVidia Corporation G96 [GeForce 9500 GT]
> +-08.0 Intel Corporation Core Processor System Management
>Registers
> +-08.1 Intel Corporation Core Processor Semaphore and
>Scratchpad Registers
> +-08.2 Intel Corporation Core Processor System Control and
>Status Registers
> +-08.3 Intel Corporation Core Processor Miscellaneous
>Registers
> +-10.0 Intel Corporation Core Processor QPI Link
> +-10.1 Intel Corporation Core Processor QPI Routing and
>Protocol Registers
> +-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2
>Enhanced Host Controller
> +-1b.0 Intel Corporation 5 Series/3400 Series Chipset High
>Definition Audio
> +-1c.0-[06]--
> +-1c.4-[05]--
> +-1c.5-[04]--
> +-1c.6-[03]--
> +-1c.7-[02]----00.0 Realtek Semiconductor Co., Ltd.
>RTL8111/8168B PCI Express Gigabit Ethernet controller
> +-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB2
>Enhanced Host Controller
> +-1e.0-[07]--+-01.0 Siemens Nixdorf AG Device 4036
>###############################################
> | \-02.0 Intel Corporation 82540EM Gigabit
>Ethernet Controller
> +-1f.0 Intel Corporation 5 Series Chipset LPC Interface
>Controller
> +-1f.2 Intel Corporation 5 Series/3400 Series Chipset 6 port
>SATA AHCI Controller
> \-1f.3 Intel Corporation 5 Series/3400 Series Chipset SMBus
>Controller
>
>Why is "pci_attach_device" not able to attach the device on bus 7 (marked
>with ####...) ???
>
>Regards
>
>--Armin
>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post101289
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Armin Steinhoff
|
Re: pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/10/2013 8:36 AM
post101293
|
Re: pci_attach_problem on bus 7
Hugh,
here is the output of "pci -vv" :
Class = Network (Ethernet)
Vendor ID = 110ah, Siemens Nixdorf AG
Device ID = 4036h, Unknown Unknown
PCI index = 0h
Class Codes = 020000h
Revision ID = 1h
Bus number = 7
Device number = 1
Function num = 0
Status Reg = 210h
Command Reg = 107h
I/O space access enabled
Memory space access enabled
Bus Master enabled
Special Cycle operations ignored
Memory Write and Invalidate disabled
Palette Snooping disabled
Parity Error Response disabled
Data/Address stepping disabled
SERR# driver enabled
Fast back-to-back transactions to different agents disabled
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 40h
Cache Line Size= 0h
PCI Mem Address = f7ff0000h 32bit length 65536 enabled
PCI Mem Address = f0ff0000h prefetchable 32bit length 65536 enabled
PCI Mem Address = f0000000h prefetchable 32bit length 8388608 enabled
PCI Mem Address = f6000000h 32bit length 16777216 enabled
PCI Mem Address = ee000000h prefetchable 32bit length 33554432 enabled
Subsystem Vendor ID = 1h
Subsystem ID = 1h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 10
CPU Interrupt = ah
Capabilities Pointer = 48h
Capability ID = 1h - Power Management
Capabilities = 7e0ah - 0h
Device Dependent Registers:
0x040: 0a11 3640 0100 0100 0100 0a7e 0000 0000
0x050: 0000 0000 0000 ffff 0800 ffff 0800 80ff
0x060: 0000 00ff 0800 00fe 0000 0000 0000 0040
0x070: 0000 0060 0000 0010 0000 0030 0000 0020
0x080: 0000 0000 0001 0000 0000 0a7e 0100 0002
0x090: 0100 0080 0000 0000 0800 00c0 0800 00d0
0x0a0: 0000 0000 0100 ffbf 0700 003f 0800 00f0
0x0b0: 0800 00f0 0000 0000 0000 0000 0000 0000
0x0c0: 0000 0000 0000 0010 0000 0020 0200 0000
0x0d0: 0f0f 0f0f 0000 0000 00f9 3f00 0000 0000
0x0e0: 0000 0000 0000 0000 0000 0000 0000 0000
0x0f0: 0100 0000 0100 0000 0100 0000 0100 0000
Hugh Brown wrote:
> Please supply the output from 'pci -vv' so that I can see all the
> information.
>
>
>
> On 2013-05-10 5:50 AM, "Armin Steinhoff" <community-noreply@qnx.com> wrote:
>
>> pci_attach_problem on bus 7
>>
>> This is the PCI bus tree of an ASUS P7P55D motherboard:
>>
>> -[0000:00]-+-00.0 Intel Corporation Core Processor DMI
>> +-03.0-[01]----00.0 nVidia Corporation G96 [GeForce 9500 GT]
>> +-08.0 Intel Corporation Core Processor System Management
>> Registers
>> +-08.1 Intel Corporation Core Processor Semaphore and
>> Scratchpad Registers
>> +-08.2 Intel Corporation Core Processor System Control and
>> Status Registers
>> +-08.3 Intel Corporation Core Processor Miscellaneous
>> Registers
>> +-10.0 Intel Corporation Core Processor QPI Link
>> +-10.1 Intel Corporation Core Processor QPI Routing and
>> Protocol Registers
>> +-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2
>> Enhanced Host Controller
>> +-1b.0 Intel Corporation 5 Series/3400 Series Chipset High
>> Definition Audio
>> +-1c.0-[06]--
>> +-1c.4-[05]--
>> +-1c.5-[04]--
>> +-1c.6-[03]--
>> +-1c.7-[02]----00.0 Realtek Semiconductor Co., Ltd.
>> RTL8111/8168B PCI Express Gigabit Ethernet controller
>> +-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB2
>> Enhanced Host Controller
>> +-1e.0-[07]--+-01.0 Siemens Nixdorf AG Device 4036
>> ###############################################
>> | \-02.0 Intel Corporation 82540EM Gigabit
>> Ethernet...
View Full Message
|
|
|
|
|
|
Hugh Brown
|
Re: pci_attach_problem on bus 7
|
|
Hugh Brown
05/10/2013 8:47 AM
post101294
|
Re: pci_attach_problem on bus 7
Armin,
I don't see any reason why the pci_attach_device should fail. Please can
you run the attached program as 'pci_att 0x110a 0x4036' and send me the
output.
Thanks, Hugh.
On 2013-05-10 8:36 AM, "Armin Steinhoff" <community-noreply@qnx.com> wrote:
>Hugh,
>
>here is the output of "pci -vv" :
>
>Class = Network (Ethernet)
>Vendor ID = 110ah, Siemens Nixdorf AG
>Device ID = 4036h, Unknown Unknown
>PCI index = 0h
>Class Codes = 020000h
>Revision ID = 1h
>Bus number = 7
>Device number = 1
>Function num = 0
>Status Reg = 210h
>Command Reg = 107h
> I/O space access enabled
> Memory space access enabled
> Bus Master enabled
> Special Cycle operations ignored
> Memory Write and Invalidate disabled
> Palette Snooping disabled
> Parity Error Response disabled
> Data/Address stepping disabled
> SERR# driver enabled
> Fast back-to-back transactions to different agents disabled
>Header type = 0h Single-function
>BIST = 0h Build-in-self-test not supported
>Latency Timer = 40h
>Cache Line Size= 0h
>PCI Mem Address = f7ff0000h 32bit length 65536 enabled
>PCI Mem Address = f0ff0000h prefetchable 32bit length 65536 enabled
>PCI Mem Address = f0000000h prefetchable 32bit length 8388608 enabled
>PCI Mem Address = f6000000h 32bit length 16777216 enabled
>PCI Mem Address = ee000000h prefetchable 32bit length 33554432 enabled
>Subsystem Vendor ID = 1h
>Subsystem ID = 1h
>Max Lat = 0ns
>Min Gnt = 0ns
>PCI Int Pin = INT A
>Interrupt line = 10
>CPU Interrupt = ah
>Capabilities Pointer = 48h
>Capability ID = 1h - Power Management
>Capabilities = 7e0ah - 0h
>Device Dependent Registers:
>0x040: 0a11 3640 0100 0100 0100 0a7e 0000 0000
>0x050: 0000 0000 0000 ffff 0800 ffff 0800 80ff
>0x060: 0000 00ff 0800 00fe 0000 0000 0000 0040
>0x070: 0000 0060 0000 0010 0000 0030 0000 0020
>0x080: 0000 0000 0001 0000 0000 0a7e 0100 0002
>0x090: 0100 0080 0000 0000 0800 00c0 0800 00d0
>0x0a0: 0000 0000 0100 ffbf 0700 003f 0800 00f0
>0x0b0: 0800 00f0 0000 0000 0000 0000 0000 0000
>0x0c0: 0000 0000 0000 0010 0000 0020 0200 0000
>0x0d0: 0f0f 0f0f 0000 0000 00f9 3f00 0000 0000
>0x0e0: 0000 0000 0000 0000 0000 0000 0000 0000
>0x0f0: 0100 0000 0100 0000 0100 0000 0100 0000
>
>
>
>Hugh Brown wrote:
>> Please supply the output from 'pci -vv' so that I can see all the
>> information.
>>
>>
>>
>> On 2013-05-10 5:50 AM, "Armin Steinhoff" <community-noreply@qnx.com>
>>wrote:
>>
>>> pci_attach_problem on bus 7
>>>
>>> This is the PCI bus tree of an ASUS P7P55D motherboard:
>>>
>>> -[0000:00]-+-00.0 Intel Corporation Core Processor DMI
>>> +-03.0-[01]----00.0 nVidia Corporation G96 [GeForce 9500 GT]
>>> +-08.0 Intel Corporation Core Processor System Management
>>> Registers
>>> +-08.1 Intel Corporation Core Processor Semaphore and
>>> Scratchpad Registers
>>> +-08.2 Intel Corporation Core Processor System Control and
>>> Status Registers
>>> +-08.3 Intel Corporation Core Processor Miscellaneous
>>> Registers
>>> +-10.0 Intel Corporation Core Processor QPI Link
>>> +-10.1 Intel Corporation Core Processor QPI Routing and
>>> Protocol Registers
>>> +-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2
>>> Enhanced Host Controller
>>> +-1b.0 Intel Corporation 5 Series/3400 Series Chipset...
View Full Message
|
|
|
|
|
|
Armin Steinhoff
|
Re: pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/14/2013 3:09 PM
post101410
|
Re: pci_attach_problem on bus 7
Hugh,
"pci_att" finds the PCI board ... so pci_attach_device is OK. The real problem is a little bit strange:
our resource manager has to look for three different PCI boards. The actual board must be found in the second trail.
When I start "PCI_tst" within a terminal window ... the PCI board isn't recognized by the second "pci_attach_device".
But when I execute the code step by step by the debugger -> the board is recognized !
Source code and binaries are attached
Regards
--Armin
|
|
|
|
|
|
Armin Steinhoff
|
Re: pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/14/2013 3:11 PM
post101412
|
Re: pci_attach_problem on bus 7
> Hugh,
here is the binary!
>
> "pci_att" finds the PCI board ... so pci_attach_device is OK. The real problem
> is a little bit strange:
> our resource manager has to look for three different PCI boards. The actual
> board must be found in the second trail.
>
> When I start "PCI_tst" within a terminal window ... the PCI board isn't
> recognized by the second "pci_attach_device".
> But when I execute the code step by step by the debugger -> the board is
> recognized !
>
> Source code and binaries are attached
>
> Regards
>
> --Armin
|
|
|
|
|
|
Mario Charest
|
RE: pci_attach_problem on bus 7
|
|
Mario Charest
05/14/2013 3:38 PM
post101415
|
RE: pci_attach_problem on bus 7
> -----Message d'origine-----
> De : Armin Steinhoff [mailto:community-noreply@qnx.com]
> Envoyé : 14 mai 2013 15:10
> À : drivers-networking
> Objet : Re: pci_attach_problem on bus 7
>
> Hugh,
>
> "pci_att" finds the PCI board ... so pci_attach_device is OK. The real problem
> is a little bit strange:
> our resource manager has to look for three different PCI boards. The actual
> board must be found in the second trail.
>
> When I start "PCI_tst" within a terminal window ... the PCI board isn't
> recognized by the second "pci_attach_device".
> But when I execute the code step by step by the debugger -> the board is
> recognized !
Maybe I`m confusing it with something else ( gns) but could it be related to a protection against rogue program doing
too many calls to fast?
>
> Source code and binaries are attached
>
> Regards
>
> --Armin
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post101410
> To cancel your subscription to this discussion, please e-mail drivers-
> networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Armin Steinhoff
|
Re: pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/15/2013 3:40 AM
post101429
|
Re: pci_attach_problem on bus 7
Mario,
what is a "rogue program doing too many calls to fast" ??
Do you believe it is not allowed to search a PCI interface by subsequent
usage of "pci_attach_device" calls??
--Armin
PS: the example program is an uncommented and small extract of the
original resource manager
Mario Charest wrote:
>
>> -----Message d'origine-----
>> De : Armin Steinhoff [mailto:community-noreply@qnx.com]
>> Envoyé : 14 mai 2013 15:10
>> À : drivers-networking
>> Objet : Re: pci_attach_problem on bus 7
>>
>> Hugh,
>>
>> "pci_att" finds the PCI board ... so pci_attach_device is OK. The real problem
>> is a little bit strange:
>> our resource manager has to look for three different PCI boards. The actual
>> board must be found in the second trail.
>>
>> When I start "PCI_tst" within a terminal window ... the PCI board isn't
>> recognized by the second "pci_attach_device".
>> But when I execute the code step by step by the debugger -> the board is
>> recognized !
> Maybe I`m confusing it with something else ( gns) but could it be related to a protection against rogue program doing
too many calls to fast?
>
>> Source code and binaries are attached
>>
>> Regards
>>
>> --Armin
>>
>>
>>
>>
>> _______________________________________________
>>
>> Networking Drivers
>> http://community.qnx.com/sf/go/post101410
>> To cancel your subscription to this discussion, please e-mail drivers-
>> networking-unsubscribe@community.qnx.com
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post101415
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Mario Charest
|
RE: pci_attach_problem on bus 7
|
|
Mario Charest
05/15/2013 8:13 AM
post101436
|
RE: pci_attach_problem on bus 7
> -----Message d'origine-----
> De : Armin Steinhoff [mailto:community-noreply@qnx.com]
> Envoyé : 15 mai 2013 03:40
> À : drivers-networking@community.qnx.com
> Cc : Mario Charest; Mario Charest
> Objet : Re: pci_attach_problem on bus 7
>
> Mario,
>
> what is a "rogue program doing too many calls to fast" ??
> Do you believe it is not allowed to search a PCI interface by subsequent
> usage of "pci_attach_device" calls??
Not at all, I was just trying to give pointers.
>
> --Armin
>
> PS: the example program is an uncommented and small extract of the
> original resource manager
>
> Mario Charest wrote:
> >
> >> -----Message d'origine-----
> >> De : Armin Steinhoff [mailto:community-noreply@qnx.com]
> >> Envoyé : 14 mai 2013 15:10
> >> À : drivers-networking
> >> Objet : Re: pci_attach_problem on bus 7
> >>
> >> Hugh,
> >>
> >> "pci_att" finds the PCI board ... so pci_attach_device is OK. The
> >> real problem is a little bit strange:
> >> our resource manager has to look for three different PCI boards. The
> >> actual board must be found in the second trail.
> >>
> >> When I start "PCI_tst" within a terminal window ... the PCI board
> >> isn't recognized by the second "pci_attach_device".
> >> But when I execute the code step by step by the debugger -> the board
> >> is recognized !
> > Maybe I`m confusing it with something else ( gns) but could it be related to
> a protection against rogue program doing too many calls to fast?
> >
> >> Source code and binaries are attached
> >>
> >> Regards
> >>
> >> --Armin
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> Networking Drivers
> >> http://community.qnx.com/sf/go/post101410
> >> To cancel your subscription to this discussion, please e-mail
> >> drivers- networking-unsubscribe@community.qnx.com
> >
> >
> >
> > _______________________________________________
> >
> > Networking Drivers
> > http://community.qnx.com/sf/go/post101415
> > To cancel your subscription to this discussion, please e-mail
> > drivers-networking-unsubscribe@community.qnx.com
>
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post101429
> To cancel your subscription to this discussion, please e-mail drivers-
> networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Hugh Brown
|
Re: pci_attach_problem on bus 7
|
|
Hugh Brown
05/15/2013 7:33 AM
post101435
|
Re: pci_attach_problem on bus 7
Armin,
You should always clear the pci_dev_info buffer before inserting the
vendor and device as the buffer will contain information from the previous
attach and could cause confusion in the PCI server. You could also use the
pci_find_device() function instead of the pci_attach_device function.
Hugh.
--
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931
On 2013-05-14 3:09 PM, "Armin Steinhoff" <community-noreply@qnx.com> wrote:
>Hugh,
>
>"pci_att" finds the PCI board ... so pci_attach_device is OK. The real
>problem is a little bit strange:
>our resource manager has to look for three different PCI boards. The
>actual board must be found in the second trail.
>
>When I start "PCI_tst" within a terminal window ... the PCI board isn't
>recognized by the second "pci_attach_device".
>But when I execute the code step by step by the debugger -> the board is
>recognized !
>
>Source code and binaries are attached
>
>Regards
>
>--Armin
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post101410
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Armin Steinhoff
|
Re: pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/15/2013 10:34 AM
post101451
|
Re: pci_attach_problem on bus 7
Hugh,
I have checked with the debugger the status of the "pci_dev_buffer"
after the first unsucessfull "pci_attach_device" call ... the buffer
remains unchanged.
OK ... I will switch to "pci_find_device" ...
Thanks
--Armin
Hugh Brown wrote:
> Armin,
>
> You should always clear the pci_dev_info buffer before inserting the
> vendor and device as the buffer will contain information from the previous
> attach and could cause confusion in the PCI server. You could also use the
> pci_find_device() function instead of the pci_attach_device function.
>
> Hugh.
>
|
|
|
|
|
|
Armin Steinhoff
|
Re: pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/15/2013 11:11 AM
post101452
|
Re: pci_attach_problem on bus 7
Hugh,
Hugh Brown wrote:
> Armin,
>
> You should always clear the pci_dev_info buffer before inserting the
> vendor and device as the buffer will contain information from the previous
> attach and could cause confusion in the PCI server.
After resetting the buffer to all zero and a new initialization .. the
PCI server remains confused :)
Regards
--Armin
|
|
|
|
|
|
Hugh Brown
|
Re: pci_attach_problem on bus 7
|
|
Hugh Brown
05/15/2013 11:14 AM
post101455
|
Re: pci_attach_problem on bus 7
Armin,
Please make sure that you have a large slog buffer (slogger -s256k) and
then run the pci server with -vvv and send me the sloginfo output after
you have run your program.
Thanks, Hugh.
--
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931
On 2013-05-15 11:11 AM, "Armin Steinhoff" <community-noreply@qnx.com>
wrote:
>Hugh,
>
>Hugh Brown wrote:
>> Armin,
>>
>> You should always clear the pci_dev_info buffer before inserting the
>> vendor and device as the buffer will contain information from the
>>previous
>> attach and could cause confusion in the PCI server.
>
>After resetting the buffer to all zero and a new initialization .. the
>PCI server remains confused :)
>
>Regards
>
>--Armin
>
>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post101452
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Armin Steinhoff
|
Re: pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/15/2013 4:42 PM
post101464
|
Re: pci_attach_problem on bus 7
Hugh,
I have attached slog.info.
The messages from PCI_tst are below:
# PCI_tst
cp16xx_init: begin
cp16xx_os_pci_probe: begin
Add 205 8 Put: 806434c, beg : 8064018 end: 80a4018
cp16xx_os_pci_probe: can't find device .. end
Add 213 7 Put: 806436c, beg : 8064018 end: 80a4018
cp16xx_os_pci_probe: begin
Add 220 8 Put: 8064388, beg : 8064018 end: 80a4018
Add 228 11 Put: 80643a8, beg : 8064018 end: 80a4018
cp16xx_init: end
Add 239 7 Put: 80643d4, beg : 8064018 end: 80a4018
The messages including "Add .." are from pci-bios or slogger ?
Regards
--Armin
Hugh Brown wrote:
> Armin,
>
> Please make sure that you have a large slog buffer (slogger -s256k) and
> then run the pci server with -vvv and send me the sloginfo output after
> you have run your program.
>
> Thanks, Hugh.
>
|
|
|
|
|
|
Hugh Brown
|
Re: pci_attach_problem on bus 7
|
|
Hugh Brown
05/16/2013 7:54 AM
post101469
|
Re: pci_attach_problem on bus 7
I have no idea where the "Add" messages are coming from, as they are not
from the PCI server. Looking at the sloginfo output, there are no errors
displayed either. What version of the PCI server are you running (use -i)?
--
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931
On 2013-05-15 4:41 PM, "Armin Steinhoff" <community-noreply@qnx.com> wrote:
>Hugh,
>
>I have attached slog.info.
>The messages from PCI_tst are below:
>
># PCI_tst
>cp16xx_init: begin
>cp16xx_os_pci_probe: begin
>Add 205 8 Put: 806434c, beg : 8064018 end: 80a4018
>cp16xx_os_pci_probe: can't find device .. end
>Add 213 7 Put: 806436c, beg : 8064018 end: 80a4018
>cp16xx_os_pci_probe: begin
>Add 220 8 Put: 8064388, beg : 8064018 end: 80a4018
>Add 228 11 Put: 80643a8, beg : 8064018 end: 80a4018
>cp16xx_init: end
>Add 239 7 Put: 80643d4, beg : 8064018 end: 80a4018
>
>The messages including "Add .." are from pci-bios or slogger ?
>
>Regards
>
>--Armin
>
>Hugh Brown wrote:
>> Armin,
>>
>> Please make sure that you have a large slog buffer (slogger -s256k) and
>> then run the pci server with -vvv and send me the sloginfo output after
>> you have run your program.
>>
>> Thanks, Hugh.
>>
>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post101464
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Armin Steinhoff
|
Re: pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/16/2013 8:26 AM
post101470
|
Re: pci_attach_problem on bus 7
Hugh,
this is the version of pci-bios:
# use -i pci-bios
NAME=pci-bios
DESCRIPTION=BIOS PCI server
DATE=2009/05/20-17:12:26-EDT
STATE=stable
HOST=cctrunk
USER=builder
VERSION=6.4.1
TAGID=166
The "Add" messages are not from the application ...
Best Regards
--Armin
Hugh Brown wrote:
> I have no idea where the "Add" messages are coming from, as they are not
> from the PCI server. Looking at the sloginfo output, there are no errors
> displayed either. What version of the PCI server are you running (use -i)?
>
|
|
|
|
|
|
Hugh Brown
|
Re: pci_attach_problem on bus 7
|
|
Hugh Brown
05/16/2013 10:04 AM
post101481
|
Re: pci_attach_problem on bus 7
Armin,
I have run your code on a 6.4.1 machine with the same version of the PCI
server and everything works fine. I just had to change the device IDs in
the PCI_tst.c code. I didn't get the "Add" messages, so I'm wondering if
there is something strange on your system. Can you boot it with a minimal
O/S and run your program again?
Hugh.
--
Hugh Brown
QNX Software Systems Limited
1001 Farrar Rd.,
Ottawa. ON. K2K 0B3.
Telephone: 613-591-0931
On 2013-05-16 8:26 AM, "Armin Steinhoff" <community-noreply@qnx.com> wrote:
>Hugh,
>
>this is the version of pci-bios:
>
># use -i pci-bios
>NAME=pci-bios
>DESCRIPTION=BIOS PCI server
>DATE=2009/05/20-17:12:26-EDT
>STATE=stable
>HOST=cctrunk
>USER=builder
>VERSION=6.4.1
>TAGID=166
>
>The "Add" messages are not from the application ...
>
>Best Regards
>
>--Armin
>
>Hugh Brown wrote:
>> I have no idea where the "Add" messages are coming from, as they are not
>> from the PCI server. Looking at the sloginfo output, there are no errors
>> displayed either. What version of the PCI server are you running (use
>>-i)?
>>
>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post101470
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Armin Steinhoff
|
Re: pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/16/2013 12:09 PM
post101491
|
Re: pci_attach_problem on bus 7
Hugh,
I have tested after booting from a distribution CD of QNX6.4.1 and
observed the same wrong behavior of "pci_attach_device"!
It happens also at customer site with a fresh installation of QNX 6.4.1 .
There is simply a bug. Please have a look to the kernel trace I have
sent with a recent mail.
Regards
--Armin
Hugh Brown wrote:
> Armin,
>
> I have run your code on a 6.4.1 machine with the same version of the PCI
> server and everything works fine. I just had to change the device IDs in
> the PCI_tst.c code. I didn't get the "Add" messages, so I'm wondering if
> there is something strange on your system. Can you boot it with a minimal
> O/S and run your program again?
>
> Hugh.
>
|
|
|
|
|
|
Armin Steinhoff
|
Re: pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/16/2013 1:29 PM
post101498
|
Re: pci_attach_problem on bus 7
Hugh,
I have done a fresh installation on a new disk in order to exclude any
side effects from a corrupted installation of QNX 6.4.1.
After recompiling and linking ... I see the same wrong behavior !!
Regards
--Armin
Hugh Brown wrote:
> Armin,
>
> I have run your code on a 6.4.1 machine with the same version of the PCI
> server and everything works fine. I just had to change the device IDs in
> the PCI_tst.c code. I didn't get the "Add" messages, so I'm wondering if
> there is something strange on your system. Can you boot it with a minimal
> O/S and run your program again?
>
> Hugh.
>
|
|
|
|
|
|
Hugh Brown
|
Re: pci_attach_problem on bus 7
|
|
Hugh Brown
05/17/2013 8:07 AM
post101513
|
Re: pci_attach_problem on bus 7
Armin,
Please modify your build file to start the attached pci-bios with '-vvv',
then boot your machine and make sure that you have a large enough slog
buffer (256k). Then run your program and send me the FULL sloginfo output.
After the procmgr_symlink line in the build file, add the following:
seedres
slogger -s256k
pci-bios -vvv
waitfor /dev/pci
Thanks, Hugh.
On 2013-05-16 1:29 PM, "Armin Steinhoff" <community-noreply@qnx.com> wrote:
>Hugh,
>
>I have done a fresh installation on a new disk in order to exclude any
>side effects from a corrupted installation of QNX 6.4.1.
>
>After recompiling and linking ... I see the same wrong behavior !!
>
>Regards
>
>--Armin
>
>Hugh Brown wrote:
>> Armin,
>>
>> I have run your code on a 6.4.1 machine with the same version of the PCI
>> server and everything works fine. I just had to change the device IDs in
>> the PCI_tst.c code. I didn't get the "Add" messages, so I'm wondering if
>> there is something strange on your system. Can you boot it with a
>>minimal
>> O/S and run your program again?
>>
>> Hugh.
>>
>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post101498
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Armin Steinhoff
|
Re: pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/20/2013 8:45 AM
post101559
|
Re: pci_attach_problem on bus 7
Hugh,
I have placed the requested options for slogger and pci-bios into the
diskboot call.
In the attachment are the log for two executions of PCI_tst
Regards
--Armin
Hugh Brown wrote:
> Armin,
>
> Please modify your build file to start the attached pci-bios with '-vvv',
> then boot your machine and make sure that you have a large enough slog
> buffer (256k). Then run your program and send me the FULL sloginfo output.
>
> After the procmgr_symlink line in the build file, add the following:
>
> seedres
> slogger -s256k
> pci-bios -vvv
> waitfor /dev/pci
>
> Thanks, Hugh.
>
>
>
>
> On 2013-05-16 1:29 PM, "Armin Steinhoff" <community-noreply@qnx.com> wrote:
>
>> Hugh,
>>
>> I have done a fresh installation on a new disk in order to exclude any
>> side effects from a corrupted installation of QNX 6.4.1.
>>
>> After recompiling and linking ... I see the same wrong behavior !!
>>
>> Regards
>>
>> --Armin
>>
>> Hugh Brown wrote:
>>> Armin,
>>>
>>> I have run your code on a 6.4.1 machine with the same version of the PCI
>>> server and everything works fine. I just had to change the device IDs in
>>> the PCI_tst.c code. I didn't get the "Add" messages, so I'm wondering if
>>> there is something strange on your system. Can you boot it with a
>>> minimal
>>> O/S and run your program again?
>>>
>>> Hugh.
>>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Networking Drivers
>> http://community.qnx.com/sf/go/post101498
>> To cancel your subscription to this discussion, please e-mail
>> drivers-networking-unsubscribe@community.qnx.com
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post101513
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Hugh Brown
|
Re: pci_attach_problem on bus 7
|
|
Hugh Brown
05/27/2013 7:48 AM
post101710
|
Re: pci_attach_problem on bus 7
Armin,
From the output that you sent me, I can see that the attach succeeded for
device ID 0x4036 twice and failed for device ID 0x4026. Otherwise I can't
see anything wrong. Do you have a device ID 0x4026 in the machine?
Hugh.
On 2013-05-20 8:45 AM, "Armin Steinhoff" <community-noreply@qnx.com> wrote:
>
>Hugh,
>
>I have placed the requested options for slogger and pci-bios into the
>diskboot call.
>In the attachment are the log for two executions of PCI_tst
>
>Regards
>
>--Armin
>
>Hugh Brown wrote:
>> Armin,
>>
>> Please modify your build file to start the attached pci-bios with
>>'-vvv',
>> then boot your machine and make sure that you have a large enough slog
>> buffer (256k). Then run your program and send me the FULL sloginfo
>>output.
>>
>> After the procmgr_symlink line in the build file, add the following:
>>
>> seedres
>> slogger -s256k
>> pci-bios -vvv
>> waitfor /dev/pci
>>
>> Thanks, Hugh.
>>
>>
>>
>>
>> On 2013-05-16 1:29 PM, "Armin Steinhoff" <community-noreply@qnx.com>
>>wrote:
>>
>>> Hugh,
>>>
>>> I have done a fresh installation on a new disk in order to exclude any
>>> side effects from a corrupted installation of QNX 6.4.1.
>>>
>>> After recompiling and linking ... I see the same wrong behavior !!
>>>
>>> Regards
>>>
>>> --Armin
>>>
>>> Hugh Brown wrote:
>>>> Armin,
>>>>
>>>> I have run your code on a 6.4.1 machine with the same version of the
>>>>PCI
>>>> server and everything works fine. I just had to change the device IDs
>>>>in
>>>> the PCI_tst.c code. I didn't get the "Add" messages, so I'm wondering
>>>>if
>>>> there is something strange on your system. Can you boot it with a
>>>> minimal
>>>> O/S and run your program again?
>>>>
>>>> Hugh.
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> Networking Drivers
>>> http://community.qnx.com/sf/go/post101498
>>> To cancel your subscription to this discussion, please e-mail
>>> drivers-networking-unsubscribe@community.qnx.com
>>
>>
>>
>>
>> _______________________________________________
>>
>> Networking Drivers
>> http://community.qnx.com/sf/go/post101513
>> To cancel your subscription to this discussion, please e-mail
>>drivers-networking-unsubscribe@community.qnx.com
>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post101559
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Armin Steinhoff
|
Re: pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/27/2013 11:25 AM
post101718
|
Re: pci_attach_problem on bus 7
Hugh,
the actual device is the device 0x4036. Device 0x4026 isn't installed.
Why returns "pci_attach_device" is negative result ?
Regards
--Armin
Hugh Brown wrote:
> Armin,
>
> >From the output that you sent me, I can see that the attach succeeded for
> device ID 0x4036 twice and failed for device ID 0x4026. Otherwise I can't
> see anything wrong. Do you have a device ID 0x4026 in the machine?
>
> Hugh.
>
>
>
>
> On 2013-05-20 8:45 AM, "Armin Steinhoff" <community-noreply@qnx.com> wrote:
>
>> Hugh,
>>
>> I have placed the requested options for slogger and pci-bios into the
>> diskboot call.
>> In the attachment are the log for two executions of PCI_tst
>>
>> Regards
>>
>> --Armin
>>
>> Hugh Brown wrote:
>>> Armin,
>>>
>>> Please modify your build file to start the attached pci-bios with
>>> '-vvv',
>>> then boot your machine and make sure that you have a large enough slog
>>> buffer (256k). Then run your program and send me the FULL sloginfo
>>> output.
>>>
>>> After the procmgr_symlink line in the build file, add the following:
>>>
>>> seedres
>>> slogger -s256k
>>> pci-bios -vvv
>>> waitfor /dev/pci
>>>
>>> Thanks, Hugh.
>>>
>>>
>>>
>>>
>>> On 2013-05-16 1:29 PM, "Armin Steinhoff" <community-noreply@qnx.com>
>>> wrote:
>>>
>>>> Hugh,
>>>>
>>>> I have done a fresh installation on a new disk in order to exclude any
>>>> side effects from a corrupted installation of QNX 6.4.1.
>>>>
>>>> After recompiling and linking ... I see the same wrong behavior !!
>>>>
>>>> Regards
>>>>
>>>> --Armin
>>>>
>>>> Hugh Brown wrote:
>>>>> Armin,
>>>>>
>>>>> I have run your code on a 6.4.1 machine with the same version of the
>>>>> PCI
>>>>> server and everything works fine. I just had to change the device IDs
>>>>> in
>>>>> the PCI_tst.c code. I didn't get the "Add" messages, so I'm wondering
>>>>> if
>>>>> there is something strange on your system. Can you boot it with a
>>>>> minimal
>>>>> O/S and run your program again?
>>>>>
>>>>> Hugh.
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> Networking Drivers
>>>> http://community.qnx.com/sf/go/post101498
>>>> To cancel your subscription to this discussion, please e-mail
>>>> drivers-networking-unsubscribe@community.qnx.com
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> Networking Drivers
>>> http://community.qnx.com/sf/go/post101513
>>> To cancel your subscription to this discussion, please e-mail
>>> drivers-networking-unsubscribe@community.qnx.com
>>
>>
>>
>>
>> _______________________________________________
>>
>> Networking Drivers
>> http://community.qnx.com/sf/go/post101559
>> To cancel your subscription to this discussion, please e-mail
>> drivers-networking-unsubscribe@community.qnx.com
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post101710
> To cancel your subscription to this discussion, please...
|
|
|
|
|
|
Hugh Brown
|
Re: pci_attach_problem on bus 7
|
|
Hugh Brown
05/27/2013 11:53 AM
post101722
|
Re: pci_attach_problem on bus 7
Try a pci_detach_device after a successful pci_attach_device, before
performing the next pci_attach_device.
On 2013-05-27 11:24 AM, "Armin Steinhoff" <community-noreply@qnx.com>
wrote:
>Hugh,
>
>the actual device is the device 0x4036. Device 0x4026 isn't installed.
>
>Why returns "pci_attach_device" is negative result ?
>
>Regards
>
>--Armin
>
>Hugh Brown wrote:
>> Armin,
>>
>> >From the output that you sent me, I can see that the attach succeeded
>>for
>> device ID 0x4036 twice and failed for device ID 0x4026. Otherwise I
>>can't
>> see anything wrong. Do you have a device ID 0x4026 in the machine?
>>
>> Hugh.
>>
>>
>>
>>
>> On 2013-05-20 8:45 AM, "Armin Steinhoff" <community-noreply@qnx.com>
>>wrote:
>>
>>> Hugh,
>>>
>>> I have placed the requested options for slogger and pci-bios into the
>>> diskboot call.
>>> In the attachment are the log for two executions of PCI_tst
>>>
>>> Regards
>>>
>>> --Armin
>>>
>>> Hugh Brown wrote:
>>>> Armin,
>>>>
>>>> Please modify your build file to start the attached pci-bios with
>>>> '-vvv',
>>>> then boot your machine and make sure that you have a large enough slog
>>>> buffer (256k). Then run your program and send me the FULL sloginfo
>>>> output.
>>>>
>>>> After the procmgr_symlink line in the build file, add the following:
>>>>
>>>> seedres
>>>> slogger -s256k
>>>> pci-bios -vvv
>>>> waitfor /dev/pci
>>>>
>>>> Thanks, Hugh.
>>>>
>>>>
>>>>
>>>>
>>>> On 2013-05-16 1:29 PM, "Armin Steinhoff" <community-noreply@qnx.com>
>>>> wrote:
>>>>
>>>>> Hugh,
>>>>>
>>>>> I have done a fresh installation on a new disk in order to exclude
>>>>>any
>>>>> side effects from a corrupted installation of QNX 6.4.1.
>>>>>
>>>>> After recompiling and linking ... I see the same wrong behavior !!
>>>>>
>>>>> Regards
>>>>>
>>>>> --Armin
>>>>>
>>>>> Hugh Brown wrote:
>>>>>> Armin,
>>>>>>
>>>>>> I have run your code on a 6.4.1 machine with the same version of the
>>>>>> PCI
>>>>>> server and everything works fine. I just had to change the device
>>>>>>IDs
>>>>>> in
>>>>>> the PCI_tst.c code. I didn't get the "Add" messages, so I'm
>>>>>>wondering
>>>>>> if
>>>>>> there is something strange on your system. Can you boot it with a
>>>>>> minimal
>>>>>> O/S and run your program again?
>>>>>>
>>>>>> Hugh.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Networking Drivers
>>>>> http://community.qnx.com/sf/go/post101498
>>>>> To cancel your subscription to this discussion, please e-mail
>>>>> drivers-networking-unsubscribe@community.qnx.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> Networking Drivers
>>>>...
|
|
|
|
|
|
Armin Steinhoff
|
Re: pci_attach_problem on bus 7
|
|
Armin Steinhoff
05/27/2013 6:37 PM
post101735
|
Re: pci_attach_problem on bus 7
Hugh Brown wrote:
> Try a pci_detach_device after a successful pci_attach_device, before
> performing the next pci_attach_device.
Why should I do this ??
You know the example code and all traces and debug infos are produced by
that code !
--Armin
>
>
>
>
> On 2013-05-27 11:24 AM, "Armin Steinhoff" <community-noreply@qnx.com>
> wrote:
>
>> Hugh,
>>
>> the actual device is the device 0x4036. Device 0x4026 isn't installed.
>>
>> Why returns "pci_attach_device" is negative result ?
>>
>> Regards
>>
>> --Armin
>>
>> Hugh Brown wrote:
>>> Armin,
>>>
>>> >From the output that you sent me, I can see that the attach succeeded
>>> for
>>> device ID 0x4036 twice and failed for device ID 0x4026. Otherwise I
>>> can't
>>> see anything wrong. Do you have a device ID 0x4026 in the machine?
>>>
>>> Hugh.
>>>
>>>
>>>
>>>
>>> On 2013-05-20 8:45 AM, "Armin Steinhoff" <community-noreply@qnx.com>
>>> wrote:
>>>
>>>> Hugh,
>>>>
>>>> I have placed the requested options for slogger and pci-bios into the
>>>> diskboot call.
>>>> In the attachment are the log for two executions of PCI_tst
>>>>
>>>> Regards
>>>>
>>>> --Armin
>>>>
>>>> Hugh Brown wrote:
>>>>> Armin,
>>>>>
>>>>> Please modify your build file to start the attached pci-bios with
>>>>> '-vvv',
>>>>> then boot your machine and make sure that you have a large enough slog
>>>>> buffer (256k). Then run your program and send me the FULL sloginfo
>>>>> output.
>>>>>
>>>>> After the procmgr_symlink line in the build file, add the following:
>>>>>
>>>>> seedres
>>>>> slogger -s256k
>>>>> pci-bios -vvv
>>>>> waitfor /dev/pci
>>>>>
>>>>> Thanks, Hugh.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2013-05-16 1:29 PM, "Armin Steinhoff" <community-noreply@qnx.com>
>>>>> wrote:
>>>>>
>>>>>> Hugh,
>>>>>>
>>>>>> I have done a fresh installation on a new disk in order to exclude
>>>>>> any
>>>>>> side effects from a corrupted installation of QNX 6.4.1.
>>>>>>
>>>>>> After recompiling and linking ... I see the same wrong behavior !!
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> --Armin
>>>>>>
>>>>>> Hugh Brown wrote:
>>>>>>> Armin,
>>>>>>>
>>>>>>> I have run your code on a 6.4.1 machine with the same version of the
>>>>>>> PCI
>>>>>>> server and everything works fine. I just had to change the device
>>>>>>> IDs
>>>>>>> in
>>>>>>> the PCI_tst.c code. I didn't get the "Add" messages, so I'm
>>>>>>> wondering
>>>>>>> if
>>>>>>> there is something strange on your system. Can you boot it with a
>>>>>>> minimal
>>>>>>> O/S and run your program again?
>>>>>>>
>>>>>>>...
View Full Message
|
|
|
|
|
|
