>>
> Look for callers of bus_find_device. Unless I am missing something, only pci
> and scsi code call it with non-NULL 'start' argument, and the scsi use is
> limited to a walk through scsi devices for a proc file.
>
> Makes me wonder if the start argument should go away, and if pci and scsi
>
Look for callers of bus_find_device. Unless I am missing something, only pci
and scsi code call it with non-NULL 'start' argument, and the scsi use is
limited to a walk through scsi devices for a proc file.
Makes me wonder if the start argument should go away, and if pci and scsi
should use
On Tue, Jun 03, 2014 at 04:21:00PM -0700, Greg KH wrote:
> On Tue, Jun 03, 2014 at 03:55:02PM -0700, Francesco Ruggeri wrote:
> > In-Reply-To: <20140523023141.gc13...@kroah.com>
> >
> >
> > Hi Guenter,
> > I got back to looking into this crash.
> > Just as an example, the attached diffs also fix
On Tue, Jun 03, 2014 at 03:55:02PM -0700, Francesco Ruggeri wrote:
> @@ -719,6 +719,11 @@ struct pci_dev *pci_get_device(unsigned
> struct pci_dev *pci_get_subsys(unsigned int vendor, unsigned int device,
> unsigned int ss_vendor, unsigned int ss_device,
>
On Tue, Jun 03, 2014 at 03:55:02PM -0700, Francesco Ruggeri wrote:
> In-Reply-To: <20140523023141.gc13...@kroah.com>
>
>
> Hi Guenter,
> I got back to looking into this crash.
> Just as an example, the attached diffs also fix my bus_find_device problem for
> traversals that start from the head
In-Reply-To: <20140523023141.gc13...@kroah.com>
Hi Guenter,
I got back to looking into this crash.
Just as an example, the attached diffs also fix my bus_find_device problem for
traversals that start from the head of the list and traverse it completely.
They are very specific to the case of
In-Reply-To: 20140523023141.gc13...@kroah.com
Hi Guenter,
I got back to looking into this crash.
Just as an example, the attached diffs also fix my bus_find_device problem for
traversals that start from the head of the list and traverse it completely.
They are very specific to the case of
On Tue, Jun 03, 2014 at 03:55:02PM -0700, Francesco Ruggeri wrote:
In-Reply-To: 20140523023141.gc13...@kroah.com
Hi Guenter,
I got back to looking into this crash.
Just as an example, the attached diffs also fix my bus_find_device problem for
traversals that start from the head of the
On Tue, Jun 03, 2014 at 03:55:02PM -0700, Francesco Ruggeri wrote:
@@ -719,6 +719,11 @@ struct pci_dev *pci_get_device(unsigned
struct pci_dev *pci_get_subsys(unsigned int vendor, unsigned int device,
unsigned int ss_vendor, unsigned int ss_device,
On Tue, Jun 03, 2014 at 04:21:00PM -0700, Greg KH wrote:
On Tue, Jun 03, 2014 at 03:55:02PM -0700, Francesco Ruggeri wrote:
In-Reply-To: 20140523023141.gc13...@kroah.com
Hi Guenter,
I got back to looking into this crash.
Just as an example, the attached diffs also fix my
On Thu, May 22, 2014 at 12:22:40AM -0700, Guenter Roeck wrote:
> On 05/22/2014 12:14 AM, Greg Kroah-Hartmann wrote:
> > On Wed, May 21, 2014 at 03:59:58PM -0700, Guenter Roeck wrote:
> >> On Wed, May 21, 2014 at 01:04:04PM -0700, Francesco Ruggeri wrote:
> >>> I have been using an x86 platform.
>
On Thu, May 22, 2014 at 09:19:40AM -0700, Francesco Ruggeri wrote:
> Aborting a search does not sound like a correct solution.
> How does a higher level user (eg for_each_pci_dev) know that a search
> was aborted and decide whether it should try again, assuming it would
> be ok repeating the
Aborting a search does not sound like a correct solution.
How does a higher level user (eg for_each_pci_dev) know that a search
was aborted and decide whether it should try again, assuming it would
be ok repeating the action on the devices visited the first time?
Francesco
On Thu, May 22, 2014
On 05/22/2014 12:14 AM, Greg Kroah-Hartmann wrote:
On Wed, May 21, 2014 at 03:59:58PM -0700, Guenter Roeck wrote:
On Wed, May 21, 2014 at 01:04:04PM -0700, Francesco Ruggeri wrote:
I have been using an x86 platform.
When I started working on it I got early crashes until I added the
check for p
On Wed, May 21, 2014 at 03:59:58PM -0700, Guenter Roeck wrote:
> On Wed, May 21, 2014 at 01:04:04PM -0700, Francesco Ruggeri wrote:
> > I have been using an x86 platform.
> > When I started working on it I got early crashes until I added the
> > check for p not NULL in
> >
> > +void
On Wed, May 21, 2014 at 03:59:58PM -0700, Guenter Roeck wrote:
On Wed, May 21, 2014 at 01:04:04PM -0700, Francesco Ruggeri wrote:
I have been using an x86 platform.
When I started working on it I got early crashes until I added the
check for p not NULL in
+void
On 05/22/2014 12:14 AM, Greg Kroah-Hartmann wrote:
On Wed, May 21, 2014 at 03:59:58PM -0700, Guenter Roeck wrote:
On Wed, May 21, 2014 at 01:04:04PM -0700, Francesco Ruggeri wrote:
I have been using an x86 platform.
When I started working on it I got early crashes until I added the
check for p
Aborting a search does not sound like a correct solution.
How does a higher level user (eg for_each_pci_dev) know that a search
was aborted and decide whether it should try again, assuming it would
be ok repeating the action on the devices visited the first time?
Francesco
On Thu, May 22, 2014
On Thu, May 22, 2014 at 09:19:40AM -0700, Francesco Ruggeri wrote:
Aborting a search does not sound like a correct solution.
How does a higher level user (eg for_each_pci_dev) know that a search
was aborted and decide whether it should try again, assuming it would
be ok repeating the action on
On Thu, May 22, 2014 at 12:22:40AM -0700, Guenter Roeck wrote:
On 05/22/2014 12:14 AM, Greg Kroah-Hartmann wrote:
On Wed, May 21, 2014 at 03:59:58PM -0700, Guenter Roeck wrote:
On Wed, May 21, 2014 at 01:04:04PM -0700, Francesco Ruggeri wrote:
I have been using an x86 platform.
When I
On Wed, May 21, 2014 at 01:04:04PM -0700, Francesco Ruggeri wrote:
> I have been using an x86 platform.
> When I started working on it I got early crashes until I added the
> check for p not NULL in
>
> +void bus_release_device(struct device *dev)
> +{
> + struct device_private *p = dev->p;
> +
>
On Tue, May 20, 2014 at 03:35:15PM -0700, Francesco Ruggeri wrote:
> Hi Guenter,
> thank you for your reply. I will check out the changes that you pointed to.
> The problem we are seeing is a race condition between for_each_pci_dev
> (or similar) and device_unregisters. I am not sure if use of the
On Tue, May 20, 2014 at 03:35:15PM -0700, Francesco Ruggeri wrote:
Hi Guenter,
thank you for your reply. I will check out the changes that you pointed to.
The problem we are seeing is a race condition between for_each_pci_dev
(or similar) and device_unregisters. I am not sure if use of the new
On Wed, May 21, 2014 at 01:04:04PM -0700, Francesco Ruggeri wrote:
I have been using an x86 platform.
When I started working on it I got early crashes until I added the
check for p not NULL in
+void bus_release_device(struct device *dev)
+{
+ struct device_private *p = dev-p;
+
+ if (p
On Tue, May 20, 2014 at 03:35:15PM -0700, Francesco Ruggeri wrote:
> Hi Guenter,
> thank you for your reply. I will check out the changes that you pointed to.
> The problem we are seeing is a race condition between for_each_pci_dev
> (or similar) and device_unregisters. I am not sure if use of the
Hi Guenter,
thank you for your reply. I will check out the changes that you pointed to.
The problem we are seeing is a race condition between for_each_pci_dev
(or similar) and device_unregisters. I am not sure if use of the new
lock should be extended to all code using for_each_pci_dev as well.
On Tue, May 20, 2014 at 12:17:57PM -0700, Francesco Ruggeri wrote:
> I posted this about a week ago but I did not get any replies.
> Re-trying.
>
> While traversing devices on pci_bus_type I ran into the crash below.
> The immediate cause of the crash is that bus_find_device is trying to resume
>
I posted this about a week ago but I did not get any replies.
Re-trying.
While traversing devices on pci_bus_type I ran into the crash below.
The immediate cause of the crash is that bus_find_device is trying to resume
a scan starting from a device that has been unregistered (and whose knode_bus
I posted this about a week ago but I did not get any replies.
Re-trying.
While traversing devices on pci_bus_type I ran into the crash below.
The immediate cause of the crash is that bus_find_device is trying to resume
a scan starting from a device that has been unregistered (and whose knode_bus
On Tue, May 20, 2014 at 12:17:57PM -0700, Francesco Ruggeri wrote:
I posted this about a week ago but I did not get any replies.
Re-trying.
While traversing devices on pci_bus_type I ran into the crash below.
The immediate cause of the crash is that bus_find_device is trying to resume
a
Hi Guenter,
thank you for your reply. I will check out the changes that you pointed to.
The problem we are seeing is a race condition between for_each_pci_dev
(or similar) and device_unregisters. I am not sure if use of the new
lock should be extended to all code using for_each_pci_dev as well.
On Tue, May 20, 2014 at 03:35:15PM -0700, Francesco Ruggeri wrote:
Hi Guenter,
thank you for your reply. I will check out the changes that you pointed to.
The problem we are seeing is a race condition between for_each_pci_dev
(or similar) and device_unregisters. I am not sure if use of the new
32 matches
Mail list logo
