On Thu, Apr 10, 2014 at 08:53:46AM +0200, Thomas Petazzoni wrote:
> Dear Jason Gunthorpe,
>
> On Wed, 9 Apr 2014 10:20:40 -0600, Jason Gunthorpe wrote:
>
> > > OK I just got it by adding two printk() in pci-mvebu.c. Both functions
> > > mvebu_pcie_handle_iobase_change() and
Dear Jason Gunthorpe,
On Wed, 9 Apr 2014 10:20:40 -0600, Jason Gunthorpe wrote:
> > OK I just got it by adding two printk() in pci-mvebu.c. Both functions
> > mvebu_pcie_handle_iobase_change() and mvebu_pcie_handle_membase_change()
> > do pass a size which is in fact a mask (size - 1) and not
Hi Jason,
On Wed, Apr 09, 2014 at 10:20:40AM -0600, Jason Gunthorpe wrote:
> On Wed, Apr 09, 2014 at 08:11:29AM +0200, Willy Tarreau wrote:
>
> > OK I just got it by adding two printk() in pci-mvebu.c. Both functions
> > mvebu_pcie_handle_iobase_change() and mvebu_pcie_handle_membase_change()
>
Hi Jason,
On Wed, Apr 09, 2014 at 10:20:40AM -0600, Jason Gunthorpe wrote:
On Wed, Apr 09, 2014 at 08:11:29AM +0200, Willy Tarreau wrote:
OK I just got it by adding two printk() in pci-mvebu.c. Both functions
mvebu_pcie_handle_iobase_change() and mvebu_pcie_handle_membase_change()
do
Dear Jason Gunthorpe,
On Wed, 9 Apr 2014 10:20:40 -0600, Jason Gunthorpe wrote:
OK I just got it by adding two printk() in pci-mvebu.c. Both functions
mvebu_pcie_handle_iobase_change() and mvebu_pcie_handle_membase_change()
do pass a size which is in fact a mask (size - 1) and not the real
On Thu, Apr 10, 2014 at 08:53:46AM +0200, Thomas Petazzoni wrote:
Dear Jason Gunthorpe,
On Wed, 9 Apr 2014 10:20:40 -0600, Jason Gunthorpe wrote:
OK I just got it by adding two printk() in pci-mvebu.c. Both functions
mvebu_pcie_handle_iobase_change() and
On Wed, Apr 09, 2014 at 09:53:50AM +0200, Thomas Petazzoni wrote:
> Maybe this is something that Jason can confirm/infirm. I remember
> having a quick look at the core Linux PCI core to see if it was
> somehow checking whether the bridge BAR has been properly configured,
> but I think I concluded
On Wed, Apr 09, 2014 at 08:11:29AM +0200, Willy Tarreau wrote:
> OK I just got it by adding two printk() in pci-mvebu.c. Both functions
> mvebu_pcie_handle_iobase_change() and mvebu_pcie_handle_membase_change()
> do pass a size which is in fact a mask (size - 1) and not the real size.
> So the
On Wed, Apr 09, 2014 at 09:53:50AM +0200, Thomas Petazzoni wrote:
> Dear Willy Tarreau,
>
> On Wed, 9 Apr 2014 09:47:52 +0200, Willy Tarreau wrote:
>
> > > Yes, the panic is expected: Jason's patch is not *fixing* anything,
> > > it's just telling you *why* it's going to panic.
> >
> > I just
Dear Willy Tarreau,
On Wed, 9 Apr 2014 09:47:52 +0200, Willy Tarreau wrote:
> > Yes, the panic is expected: Jason's patch is not *fixing* anything,
> > it's just telling you *why* it's going to panic.
>
> I just thought that the EINVAL would prevent one from registering
> the device, which
On Wed, Apr 09, 2014 at 09:12:34AM +0200, Thomas Petazzoni wrote:
> Dear Willy Tarreau,
>
> On Wed, 9 Apr 2014 08:11:29 +0200, Willy Tarreau wrote:
>
> > The WARN is correctly emitted for both igb ports here, but unfortunately
> > despite EINVAL, I still get the panic. Also I find it surprizing
Dear Willy Tarreau,
On Wed, 9 Apr 2014 08:11:29 +0200, Willy Tarreau wrote:
> The WARN is correctly emitted for both igb ports here, but unfortunately
> despite EINVAL, I still get the panic. Also I find it surprizing that it
> reports sizes ending in . I read the patch and it looks correct,
Hi Jason,
On Tue, Apr 08, 2014 at 05:44:14PM -0600, Jason Gunthorpe wrote:
> The mbus hardware requires a power of two size, and size aligned base.
> Currently, if a non-power of two is passed in to the low level routines
> they configure the register in a way that results in undefined behaviour.
Hi Jason,
On Tue, Apr 08, 2014 at 05:44:14PM -0600, Jason Gunthorpe wrote:
The mbus hardware requires a power of two size, and size aligned base.
Currently, if a non-power of two is passed in to the low level routines
they configure the register in a way that results in undefined behaviour.
Dear Willy Tarreau,
On Wed, 9 Apr 2014 08:11:29 +0200, Willy Tarreau wrote:
The WARN is correctly emitted for both igb ports here, but unfortunately
despite EINVAL, I still get the panic. Also I find it surprizing that it
reports sizes ending in . I read the patch and it looks correct, so
On Wed, Apr 09, 2014 at 09:12:34AM +0200, Thomas Petazzoni wrote:
Dear Willy Tarreau,
On Wed, 9 Apr 2014 08:11:29 +0200, Willy Tarreau wrote:
The WARN is correctly emitted for both igb ports here, but unfortunately
despite EINVAL, I still get the panic. Also I find it surprizing that it
Dear Willy Tarreau,
On Wed, 9 Apr 2014 09:47:52 +0200, Willy Tarreau wrote:
Yes, the panic is expected: Jason's patch is not *fixing* anything,
it's just telling you *why* it's going to panic.
I just thought that the EINVAL would prevent one from registering
the device, which would be
On Wed, Apr 09, 2014 at 09:53:50AM +0200, Thomas Petazzoni wrote:
Dear Willy Tarreau,
On Wed, 9 Apr 2014 09:47:52 +0200, Willy Tarreau wrote:
Yes, the panic is expected: Jason's patch is not *fixing* anything,
it's just telling you *why* it's going to panic.
I just thought that
On Wed, Apr 09, 2014 at 08:11:29AM +0200, Willy Tarreau wrote:
OK I just got it by adding two printk() in pci-mvebu.c. Both functions
mvebu_pcie_handle_iobase_change() and mvebu_pcie_handle_membase_change()
do pass a size which is in fact a mask (size - 1) and not the real size.
So the mbus
On Wed, Apr 09, 2014 at 09:53:50AM +0200, Thomas Petazzoni wrote:
Maybe this is something that Jason can confirm/infirm. I remember
having a quick look at the core Linux PCI core to see if it was
somehow checking whether the bridge BAR has been properly configured,
but I think I concluded it
The mbus hardware requires a power of two size, and size aligned base.
Currently, if a non-power of two is passed in to the low level routines
they configure the register in a way that results in undefined behaviour.
Call WARN and return EINVAL instead.
Also, update the debugfs routines to show
The mbus hardware requires a power of two size, and size aligned base.
Currently, if a non-power of two is passed in to the low level routines
they configure the register in a way that results in undefined behaviour.
Call WARN and return EINVAL instead.
Also, update the debugfs routines to show
22 matches
Mail list logo
