at
>>>>>> without it,
>>>>>> we may also not get the PCIe error messages.
>>>>>
>>>>> Sure, for bridges.
>>>>>
>>>>> I'll get a stack trace later today, but what I suspect is happening
>>
t; Sure, for bridges.
>>>>
>>>> I'll get a stack trace later today, but what I suspect is happening
>>>> is that this multi-function card is being treated by the PCI layers
>>>> as a "bridge" for purposes of the multiple virtual functions it imple
; is that this multi-function card is being treated by the PCI layers
>>> as a "bridge" for purposes of the multiple virtual functions it implements.
>>>
>>> We will probably need to distinguish this kind of device from real bridges
>>> here.
>>
>> Here's the c
;
>> We will probably need to distinguish this kind of device from real bridges
>> here.
>
> Here's the call trace, all the way back to k7_probe(),
> the driver's PCI "probe" function, and beyond:
>
> [ 30.481454] k7: loading driver version 0.80
>
this multi-function card is being treated by the PCI layers
> as a "bridge" for purposes of the multiple virtual functions it implements.
>
> We will probably need to distinguish this kind of device from real bridges
> here.
Here's the call trace, all the way back to k7_
On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote:
>>> I assume you're talking about the one added by cf3e1feba7f9 ("PCI:
>>> Workaround missing pci_set_master in pci drivers"), but as far as I
>>> can tell, it only calls pci_set_master() for
On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote:
On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote:
I assume you're talking about the one added by cf3e1feba7f9 (PCI:
Workaround missing pci_set_master in pci drivers), but as far as I
can tell, it only calls pci_set_master() for *bridge*
to k7_probe(),
the driver's PCI probe function, and beyond:
[ 30.481454] k7: loading driver version 0.80
[ 30.485561] pcieport :00:1c.0: driver skip pci_set_master, fix it!
[ 30.485580] CPU: 2 PID: 4401 Comm: insmod Tainted: G O 3.12.14 #3
[ 30.485583] Hardware name: Supermicro
the call trace, all the way back to k7_probe(),
the driver's PCI probe function, and beyond:
[ 30.481454] k7: loading driver version 0.80
[ 30.485561] pcieport :00:1c.0: driver skip pci_set_master, fix it!
[ 30.485580] CPU: 2 PID: 4401 Comm: insmod Tainted: G O 3.12.14 #3
to distinguish this kind of device from real bridges
here.
Here's the call trace, all the way back to k7_probe(),
the driver's PCI probe function, and beyond:
[ 30.481454] k7: loading driver version 0.80
[ 30.485561] pcieport :00:1c.0: driver skip pci_set_master, fix it!
This message
and the tree view:
pcieport :00:1c.4: driver skip pci_set_master, fix it!
pcieport :00:1c.5: driver skip pci_set_master, fix it!
pcieport :00:1c.0: driver skip pci_set_master, fix it!
lspci -t
-[:00]-+-00.0
+-01.0-[01]--+-00.0
|\-00.1
: loading driver version 0.80
[ 30.485561] pcieport :00:1c.0: driver skip pci_set_master, fix it!
This message says we're enabling bus mastering for a PCIe Root Port,
which I think is the expected behavior and shouldn't cause trouble for
your device (correct me if I'm wrong).
I don't know
On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote:
> > I assume you're talking about the one added by cf3e1feba7f9 ("PCI:
> > Workaround missing pci_set_master in pci drivers"), but as far as I
> > can tell, it only calls pci_set_master() for *bridge* devices. What
> > am I missing? Is
On 14-04-08 02:27 PM, Bjorn Helgaas wrote:
> [+cc Ben, linux-pci]
>
> On Tue, Apr 8, 2014 at 10:34 AM, Mark Lord wrote:
>> I am working a couple of drivers for chips that perform extensive
>> bus-mastering ops.
>> These including full SRIOV support, and allow assigning virtual functions to
>>
[+cc Ben, linux-pci]
On Tue, Apr 8, 2014 at 10:34 AM, Mark Lord wrote:
> I am working a couple of drivers for chips that perform extensive
> bus-mastering ops.
> These including full SRIOV support, and allow assigning virtual functions to
> virtual machines, etc.
>
> One thing the driver
I am working a couple of drivers for chips that perform extensive bus-mastering
ops.
These including full SRIOV support, and allow assigning virtual functions to
virtual machines, etc.
One thing the driver (still in development) does for safety,
is defer the call to pci_set_master() until
I am working a couple of drivers for chips that perform extensive bus-mastering
ops.
These including full SRIOV support, and allow assigning virtual functions to
virtual machines, etc.
One thing the driver (still in development) does for safety,
is defer the call to pci_set_master() until
[+cc Ben, linux-pci]
On Tue, Apr 8, 2014 at 10:34 AM, Mark Lord ml...@pobox.com wrote:
I am working a couple of drivers for chips that perform extensive
bus-mastering ops.
These including full SRIOV support, and allow assigning virtual functions to
virtual machines, etc.
One thing the
On 14-04-08 02:27 PM, Bjorn Helgaas wrote:
[+cc Ben, linux-pci]
On Tue, Apr 8, 2014 at 10:34 AM, Mark Lord ml...@pobox.com wrote:
I am working a couple of drivers for chips that perform extensive
bus-mastering ops.
These including full SRIOV support, and allow assigning virtual functions
On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote:
I assume you're talking about the one added by cf3e1feba7f9 (PCI:
Workaround missing pci_set_master in pci drivers), but as far as I
can tell, it only calls pci_set_master() for *bridge* devices. What
am I missing? Is pci_set_master()
20 matches
Mail list logo
