On Wed, Jul 02, 2014 at 10:03:49AM +0300, Dan Aloni wrote:
> On Tue, Jul 01, 2014 at 09:39:43PM -0700, Loic Prylli wrote:
> > A bug was introduced in NETDEV_CHANGE notifier sequence causing the
> > arp table to be sometimes spuriously cleared (including manual arp
> > ent
On Wed, Jul 02, 2014 at 10:03:49AM +0300, Dan Aloni wrote:
On Tue, Jul 01, 2014 at 09:39:43PM -0700, Loic Prylli wrote:
A bug was introduced in NETDEV_CHANGE notifier sequence causing the
arp table to be sometimes spuriously cleared (including manual arp
entries marked permanent), upon
("net: pass changed flags along with NETDEV_CHANGE event")
Fixes: 6c8b4e3ff81b ("arp: flush arp cache on IFF_NOARP change")
Signed-off-by: Loic Prylli
---
net/core/dev.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
in
: pass changed flags along with NETDEV_CHANGE event)
Fixes: 6c8b4e3ff81b (arp: flush arp cache on IFF_NOARP change)
Signed-off-by: Loic Prylli lo...@google.com
---
net/core/dev.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index
G for some of the devices."
Anyway Ivan's patch + Matthew's extensions are handling that non-PC
arch. That combination is advocated by at least:
Ivan Kokshaysky
Matthew Wilcox
Tony Camuso
Loic Prylli
even Arjan's said that while he prefers his patch (saying it's more
conservative), he d
On 1/14/2008 6:04 PM, Adrian Bunk wrote:
I thought so, but due to the way that things are initialised, mmconfig
happens before conf1. conf1 is known to be usable, but hasn't set
raw_pci_ops at this point. Confusing, and not ideal, but fixing this
isn't in scope for 2.6.24.
...
*ahem*
On 1/14/2008 6:04 PM, Adrian Bunk wrote:
I thought so, but due to the way that things are initialised, mmconfig
happens before conf1. conf1 is known to be usable, but hasn't set
raw_pci_ops at this point. Confusing, and not ideal, but fixing this
isn't in scope for 2.6.24.
...
*ahem*
Ivan's patch + Matthew's extensions are handling that non-PC
arch. That combination is advocated by at least:
Ivan Kokshaysky
Matthew Wilcox
Tony Camuso
Loic Prylli
even Arjan's said that while he prefers his patch (saying it's more
conservative), he does not see a existing problem with the Ivan
On 1/13/2008 3:43 PM, Matthew Wilcox wrote:
On Sun, Jan 13, 2008 at 10:41:24AM -0800, Arjan van de Ven wrote:
Note: There is not a 100% overlap between "need" and "will not be used in
the patches that use legacy for < 256". In the other patches posted,
extended config space will be used
On 1/13/2008 1:41 PM, Arjan van de Ven wrote:
On Sun, 13 Jan 2008 13:23:35 -0500
Loic Prylli <[EMAIL PROTECTED]> wrote:
Matthew pointed a patch that basically does what you suggested; only one
comment on your mail left after that:
2) the pci_enable_ext_config() function a
On 1/12/2008 12:45 PM, Arjan van de Ven wrote:
On Sat, 12 Jan 2008 17:40:30 +0300
Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
+ if (reg < 256)
+ return pci_conf1_read(seg,bus,devfn,reg,len,value);
+
btw this is my main objection to your patch; it intertwines the
On 1/12/2008 12:45 PM, Arjan van de Ven wrote:
On Sat, 12 Jan 2008 17:40:30 +0300
Ivan Kokshaysky [EMAIL PROTECTED] wrote:
+ if (reg 256)
+ return pci_conf1_read(seg,bus,devfn,reg,len,value);
+
btw this is my main objection to your patch; it intertwines the conf1
On 1/13/2008 1:41 PM, Arjan van de Ven wrote:
On Sun, 13 Jan 2008 13:23:35 -0500
Loic Prylli [EMAIL PROTECTED] wrote:
Matthew pointed a patch that basically does what you suggested; only one
comment on your mail left after that:
2) the pci_enable_ext_config() function and dev
On 1/13/2008 3:43 PM, Matthew Wilcox wrote:
On Sun, Jan 13, 2008 at 10:41:24AM -0800, Arjan van de Ven wrote:
Note: There is not a 100% overlap between need and will not be used in
the patches that use legacy for 256. In the other patches posted,
extended config space will be used in
On 1/13/2008 1:01 AM, Matthew Wilcox wrote:
On Sat, Dec 29, 2007 at 12:12:19AM +0300, Ivan Kokshaysky wrote:
On Fri, Dec 28, 2007 at 12:40:53PM -0500, Loic Prylli wrote:
One thing that could be changed in pci_cfg_space_size() is to avoid
making a special case for PCI-X 266MHz/533Mhz
On 1/13/2008 1:01 AM, Matthew Wilcox wrote:
On Sat, Dec 29, 2007 at 12:12:19AM +0300, Ivan Kokshaysky wrote:
On Fri, Dec 28, 2007 at 12:40:53PM -0500, Loic Prylli wrote:
One thing that could be changed in pci_cfg_space_size() is to avoid
making a special case for PCI-X 266MHz/533Mhz
On 12/28/2007 1:06 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2007-12-27 at 21:37 -0800, Linus Torvalds wrote:
>
>> On Fri, 28 Dec 2007, Benjamin Herrenschmidt wrote:
>>
>>> I have embedded boards where proper CRS operations is critical since the
>>> kernel brings the PCIe link up
On 12/28/2007 11:38 AM, Ivan Kokshaysky wrote:
> On Fri, Dec 28, 2007 at 08:14:18AM -0800, Arjan van de Ven wrote:
>
>> it removes code by removing quirks / known not working stuff..
>>
>
>
The only quirk I see removed is a bitmap with an arbitrary size (that we
don't really know
On 12/28/2007 11:38 AM, Ivan Kokshaysky wrote:
On Fri, Dec 28, 2007 at 08:14:18AM -0800, Arjan van de Ven wrote:
it removes code by removing quirks / known not working stuff..
The only quirk I see removed is a bitmap with an arbitrary size (that we
don't really know is
On 12/28/2007 1:06 AM, Benjamin Herrenschmidt wrote:
On Thu, 2007-12-27 at 21:37 -0800, Linus Torvalds wrote:
On Fri, 28 Dec 2007, Benjamin Herrenschmidt wrote:
I have embedded boards where proper CRS operations is critical since the
kernel brings the PCIe link up itself, and thus
g size in
ioremap_change_attr() ). The problem is avoided by not using an extra guard
page for VM_IOREMAP allocations (if somebody can think of an easy way to
store the original size across ioremap()/iounmap() calls, that could be
a more elegant solution).
Signed-off-by: Loic Prylli <[EMAIL PROTECTED]>
---
On 12/27/2007 1:58 PM, Linus Torvalds wrote:
>
> There was a thread called "PCI vendor id == 1 regression?" (Kai Ruhnau was
> the main reporter for that one). But looking back, it seems that one
> didn't hit the kernel mailing list, so I guess google cannot pick it up. I
> can forward all the
in
ioremap_change_attr() ). The problem is avoided by not using an extra guard
page for VM_IOREMAP allocations (if somebody can think of an easy way to
store the original size across ioremap()/iounmap() calls, that could be
a more elegant solution).
Signed-off-by: Loic Prylli [EMAIL PROTECTED]
---
mm/vmalloc.c
On 12/27/2007 1:58 PM, Linus Torvalds wrote:
There was a thread called PCI vendor id == 1 regression? (Kai Ruhnau was
the main reporter for that one). But looking back, it seems that one
didn't hit the kernel mailing list, so I guess google cannot pick it up. I
can forward all the emails
On 12/23/2007 3:55 PM, Matthew Wilcox wrote:
> On Sun, Dec 23, 2007 at 03:16:24PM -0500, Loic Prylli wrote:
>
>> I just realized one thing: the bar sizing code in pci_read_bases() (that
>> writes 0x in the bars) does not seem to disable the
>> PCI_COMMAND
On 12/20/2007 1:16 PM, Matthew Wilcox wrote:
> Oh, that's the same bug others (including me) have been complaining
> about.
>
> http://marc.info/?l=linux-kernel=118809338631160=2
>
>
>> It hangs in exactly the same place every time.
>>
>> I am surmising that the write to that BAR is causing a
On 12/23/2007 12:44 AM, Jeff Garzik wrote:
>>
>> By possibly using different implementations for the two ranges you avoid
>> introducing a new API, you avoid taking risks with mmconf when you don't
>> need it. That doesn't preclude using mmconf for everything either if the
>> user requests it or
On 12/23/2007 12:44 AM, Jeff Garzik wrote:
By possibly using different implementations for the two ranges you avoid
introducing a new API, you avoid taking risks with mmconf when you don't
need it. That doesn't preclude using mmconf for everything either if the
user requests it or based on
On 12/20/2007 1:16 PM, Matthew Wilcox wrote:
Oh, that's the same bug others (including me) have been complaining
about.
http://marc.info/?l=linux-kernelm=118809338631160w=2
It hangs in exactly the same place every time.
I am surmising that the write to that BAR is causing a MCE.
On 12/23/2007 3:55 PM, Matthew Wilcox wrote:
On Sun, Dec 23, 2007 at 03:16:24PM -0500, Loic Prylli wrote:
I just realized one thing: the bar sizing code in pci_read_bases() (that
writes 0x in the bars) does not seem to disable the
PCI_COMMAND_MEM/PCI_COMMAND_IO bits in the cmd
On 12/22/2007 11:52 PM, Jeff Garzik wrote:
>
> Absolutely.
>
> But regardless of problems, enabling should be done globally, not per
> device...
The "enabling globally" requirement, i.e. not per-device, neither
depending on reg >= 256 seems a very debatable assumption (IMHO a big
mistake)
On 12/22/2007 11:13 PM, Jeff Garzik wrote:
>
> The facts as they exist today:
>
> 1) Existing 256-byte config space devices have been known put
> capabilities in the high end (>= 0xc8) of config space.
>
> 2) It is legal for PCI-Express to put capabilities anywhere in PCI
> config space, including
On 12/22/2007 11:13 PM, Jeff Garzik wrote:
The facts as they exist today:
1) Existing 256-byte config space devices have been known put
capabilities in the high end (= 0xc8) of config space.
2) It is legal for PCI-Express to put capabilities anywhere in PCI
config space, including extended
On 12/22/2007 11:52 PM, Jeff Garzik wrote:
Absolutely.
But regardless of problems, enabling should be done globally, not per
device...
The enabling globally requirement, i.e. not per-device, neither
depending on reg = 256 seems a very debatable assumption (IMHO a big
mistake) that
On 12/20/2007 9:15 PM, Robert Hancock wrote:
>>
>> Suggested Workaround
>>
>> It is strongly recommended that system designers do not connect the
>> AMD-8132 and devices that use extended
>> configuration space MMIO BARs (ex: HyperTransport-to-PCI Express®
>> bridges) to the same processor
>>
On 12/20/2007 6:21 PM, Tony Camuso wrote:
>
> And the MMCONFIG problem with enterprise systems and workstations, where
> we do control the BIOS (for the most part), is due to known bugs in
> certain versions of certain chipsets, HT1000, AMD8132, among them, not
> the BIOS.
The lack of MMCONFIG
On 12/20/2007 4:00 PM, Matthew Wilcox wrote:
> On Thu, Dec 20, 2007 at 03:56:29PM -0500, Loic Prylli wrote:
>
>> I know the final device is not aware on how the config request was
>> originated. I am just saying platforms built around the Intel 82801
>> chipset (ICH2
On 12/20/2007 3:15 PM, Matthew Wilcox wrote:
> On Thu, Dec 20, 2007 at 03:05:52PM -0500, Loic Prylli wrote:
>
>> I am not familiar with the tg3 driver, just trying to give a 5 minutes
>> look, it seems the typical cases where the pci-conf-space is used
>> inten
On 12/20/2007 2:08 PM, Matthew Wilcox wrote:
> On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote:
>
>> Also, this solution also would allow us to remove the unreachable_devices()
>> routine and bitmap.
>>
>
> Not really ... we probe reading address 0x100 to see if the device
>
On 12/20/2007 1:16 PM, Matthew Wilcox wrote:
>
> Bad deduction. What's happening is that the write to the BAR is causing
> it to overlap the decode for mmconfig space. So the mmconfig write to
> set the BAR back never gets through.
>
> I have a different idea to fix this problem. Instead of
On 12/20/2007 1:16 PM, Matthew Wilcox wrote:
Bad deduction. What's happening is that the write to the BAR is causing
it to overlap the decode for mmconfig space. So the mmconfig write to
set the BAR back never gets through.
I have a different idea to fix this problem. Instead of writing
On 12/20/2007 2:08 PM, Matthew Wilcox wrote:
On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote:
Also, this solution also would allow us to remove the unreachable_devices()
routine and bitmap.
Not really ... we probe reading address 0x100 to see if the device
supports
On 12/20/2007 3:15 PM, Matthew Wilcox wrote:
On Thu, Dec 20, 2007 at 03:05:52PM -0500, Loic Prylli wrote:
I am not familiar with the tg3 driver, just trying to give a 5 minutes
look, it seems the typical cases where the pci-conf-space is used
intensively are with some rev in combination
On 12/20/2007 4:00 PM, Matthew Wilcox wrote:
On Thu, Dec 20, 2007 at 03:56:29PM -0500, Loic Prylli wrote:
I know the final device is not aware on how the config request was
originated. I am just saying platforms built around the Intel 82801
chipset (ICH2) don't support mmconfig at all. I
On 12/20/2007 6:21 PM, Tony Camuso wrote:
And the MMCONFIG problem with enterprise systems and workstations, where
we do control the BIOS (for the most part), is due to known bugs in
certain versions of certain chipsets, HT1000, AMD8132, among them, not
the BIOS.
The lack of MMCONFIG
On 12/20/2007 9:15 PM, Robert Hancock wrote:
Suggested Workaround
It is strongly recommended that system designers do not connect the
AMD-8132 and devices that use extended
configuration space MMIO BARs (ex: HyperTransport-to-PCI Express®
bridges) to the same processor
HyperTransport link.
On 10/3/2007 11:58 PM, Eric W. Biederman wrote:
> Right. And INTx has such a pending bit as well. I guess I figured
> if MSI was enabled transferring it over would be the obvious thing to
> do.
>
The INTx pending and disable bit were only added starting with PCI 2.3,
so in PCI-2.2 and
On 10/3/2007 11:58 PM, Eric W. Biederman wrote:
Right. And INTx has such a pending bit as well. I guess I figured
if MSI was enabled transferring it over would be the obvious thing to
do.
The INTx pending and disable bit were only added starting with PCI 2.3,
so in PCI-2.2 and PCI-X
On 10/3/2007 5:49 PM, Eric W. Biederman wrote:
> Loic Prylli <[EMAIL PROTECTED]> writes:
>
>
>> Hi,
>>
>> We observe a problem with MSI since kernel 2.6.21 where interrupts would
>> randomly stop working. We have tracked it down to the new
>> msi_
Hi,
We observe a problem with MSI since kernel 2.6.21 where interrupts would
randomly stop working. We have tracked it down to the new
msi_set_mask_bit definition in 2.6.21. In the MSI case with a device not
providing a "native" MSI mask, it was a no-op before, and now it
disables MSI in the
Hi,
We observe a problem with MSI since kernel 2.6.21 where interrupts would
randomly stop working. We have tracked it down to the new
msi_set_mask_bit definition in 2.6.21. In the MSI case with a device not
providing a native MSI mask, it was a no-op before, and now it
disables MSI in the
On 10/3/2007 5:49 PM, Eric W. Biederman wrote:
Loic Prylli [EMAIL PROTECTED] writes:
Hi,
We observe a problem with MSI since kernel 2.6.21 where interrupts would
randomly stop working. We have tracked it down to the new
msi_set_mask_bit definition in 2.6.21. In the MSI case
On 8/7/2007 4:30 AM, Andi Kleen wrote:
> On Mon, Aug 06, 2007 at 10:03:15PM -0400, Cédric Augonnet wrote:
>
>> Hi all,
>>
>> For quite a while now, there as been numerous attempt to introduce support
>> for
>> Page Attribute Table (PAT) in the Linux kernel, whereas most other OS already
>>
On 8/7/2007 4:30 AM, Andi Kleen wrote:
On Mon, Aug 06, 2007 at 10:03:15PM -0400, Cédric Augonnet wrote:
Hi all,
For quite a while now, there as been numerous attempt to introduce support
for
Page Attribute Table (PAT) in the Linux kernel, whereas most other OS already
have some support
On 6/25/2007 6:34 PM, Andi Kleen wrote:
> On Tuesday 26 June 2007 00:05:17 Chuck Ebbert wrote:
>
>> On 06/25/2007 05:38 PM, Loic Prylli wrote:
>>
>> [cc: Andi]
>>
>>
>>> Processors synchronization in set_mtrr requires the .gate field
>>>
before the latter is set by set_mtrr() (which
then hangs in a infinite loop with irqs disabled).
Signed-off-by: Loic Prylli <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/mtrr/main.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/i386/kernel/cpu/mtrr/main.c
before the latter is set by set_mtrr() (which
then hangs in a infinite loop with irqs disabled).
Signed-off-by: Loic Prylli [EMAIL PROTECTED]
---
arch/i386/kernel/cpu/mtrr/main.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/i386/kernel/cpu/mtrr/main.c b/arch/i386
On 6/25/2007 6:34 PM, Andi Kleen wrote:
On Tuesday 26 June 2007 00:05:17 Chuck Ebbert wrote:
On 06/25/2007 05:38 PM, Loic Prylli wrote:
[cc: Andi]
Processors synchronization in set_mtrr requires the .gate field
to be set after .count field is properly initialized. Without
ght be better to avoid that systematic
mask/unmask pair. This masking has a small but measurable performance
impact for our device/driver combo.
Would you agree to suppress that masking (sample patch following)? Or
otherwise, is there is a possibility of making it optional on a
per-device basis.
. This masking has a small but measurable performance
impact for our device/driver combo.
Would you agree to suppress that masking (sample patch following)? Or
otherwise, is there is a possibility of making it optional on a
per-device basis.
Thanks for any comment!
Loic Prylli
Myricom, Inc.
[PATCH
60 matches
Mail list logo
