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
("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
y have
MMCONFIG 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
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/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: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 conf1
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 itself
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 i
ize 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 em
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/PC
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&m=118809338631160&w=2
>
>
>> It hangs in exactly the same place every time.
>>
>> I am surmising that the write to that BAR is causin
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/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) th
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/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
>> Hyper
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) d
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
>> intensiv
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
> sup
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 wri
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-
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 MSI-c
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
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
it might 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 bas
30 matches
Mail list logo
