lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 11 Jun 2013 09:24:28 +0200
From:	Rojhalat Ibrahim <imr@...chenk.de>
To:	Scott Wood <scottwood@...escale.com>,
	Michael Guntsche <michael.guntsche@...loops.com>
Cc:	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG] PCI related panic on powerpc based board with 3.10-rcX

On Monday 10 June 2013 17:52:33 Scott Wood wrote:
> On 06/10/2013 12:07:43 PM, Michael Guntsche wrote:
> > Good evening,
> > 
> > On Mon, Jun 10, 2013 at 1:41 PM, Rojhalat Ibrahim <imr@...chenk.de>
> > 
> > wrote:
> > > Hi Mike,
> > > 
> > > could you please try this patch:
> > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-May/106624.html
> > > http://patchwork.ozlabs.org/patch/244515/
> > > 
> > >    Rojhalat
> > > 
> > > On Saturday 08 June 2013 21:39:37 Michael Guntsche wrote:
> > >> After bisecting I found the responsible commit.
> > >> 
> > >> 50d8f87d2b3: powerpc/fsl-pci Make PCIe hotplug work with Freescale
> > >> PCIe controllers
> > >> 
> > >> Reverting this commit allowed my board to boot again.
> > >> 
> > >> @Rojhalat: Please have a look at
> > >> http://marc.info/?l=linux-kernel&m=137071294204858&w=2
> > >> for my initial bugreport.
> > >> 
> > >> What I do not understand at all is why this is affecting my
> > 
> > platform.
> > 
> > >> AFAIK there is no PCIe hardware on it AND I completely disabled
> > 
> > PCIe
> > 
> > >> support in config.
> > >> 
> > >> Kind regards,
> > >> Mike
> > 
> > This patch does not fix the problem, during boot the kernel still
> > panics. I had a closer look at the commit and the following patch
> > fixes it for me....
> > 
> > diff --git a/arch/powerpc/sysdev/fsl_pci.c
> > b/arch/powerpc/sysdev/fsl_pci.c
> > index 028ac1f..21b687f 100644
> > --- a/arch/powerpc/sysdev/fsl_pci.c
> > +++ b/arch/powerpc/sysdev/fsl_pci.c
> > @@ -814,7 +814,7 @@ int __init mpc83xx_add_bridge(struct device_node
> > *dev)
> > 
> >                 if (ret)
> >                 
> >                         goto err0;
> >         
> >         } else {
> > 
> > -               fsl_setup_indirect_pci(hose, rsrc_cfg.start,
> > +               setup_indirect_pci(hose, rsrc_cfg.start,
> > 
> >                                        rsrc_cfg.start + 4, 0);
> >         
> >         }
> 
> The only difference here is that you're not setting hose->ops to
> fsl_indirect_pci_ops.  Do you know why that is helping, and what
> hose->ops is set to instead?
> 
> -Scott

The difference is only the read function in hose->ops, which is set to 
indirect_read_config instead of fsl_indirect_read_config.

fsl_indirect_read_config calls fsl_pcie_check_link, which is where the Oops 
occurs. 

Mike, can you find out where exactly in fsl_pcie_check_link the bad access 
happens? Enabling CONFIG_DEBUG_BUGVERBOSE might help.

   Rojhalat


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ