Yes indeed. I added some code to reset the
fields incorrectly containing "nousb" to their
expected value of 0, and the dom0 kernel still fails
to boot. So this is likely just a symptom of broader
memory corruption.
> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Thursday, June 04, 2009 1:34 AM
> To: Dan Magenheimer; Isaku Yamahata
> Cc: Xen-Devel (E-mail)
> Subject: Re: Dom0 crashing when built with c/s 881 (Was: [Xen-devel]
> blktap2: need more than 3 values to unpack)
>
>
> If memory corruption is the issue, c/s 881 could be
> innocently triggering a
> latent bug.
>
> -- Keir
>
> On 04/06/2009 05:49, "Dan Magenheimer"
> <dan.magenheimer@xxxxxxxxxx> wrote:
>
> > I'm quitting for the night now, but I see that
> > the string "nous" is followed by a "b" in the
> > immediately following word. Put this together
> > and you have "nousb" (read as turn off USB).
> >
> > Given that the "Driver 'xxx' needs updating"
> > are for 'usbfs', 'hub', and 'usb', and given
> > that usb is very related to hotplug, the string
> > "nousb" where a pair of function pointers should
> > be is suspicious (though it may also be a complete
> > coincidence).
> >
> > I'll try turning off CONFIG_HOTPLUG_PCI tomorrow.
> >
> > Dan
> >
> >> -----Original Message-----
> >> From: Dan Magenheimer
> >> Sent: Wednesday, June 03, 2009 7:09 PM
> >> To: Keir Fraser; Isaku Yamahata
> >> Cc: Xen-Devel (E-mail)
> >> Subject: RE: Dom0 crashing when built with c/s 881 (Was:
> [Xen-devel]
> >> blktap2: need more than 3 values to unpack)
> >>
> >>
> >>> If that doesn't help, I can go add some printk's where that
> >>> output is happening and see exactly what forces the failure.
> >>
> >> Here's what I am seeing. Looks like the drv->bus structure
> >> is getting overwritten with ASCII.
> >>
> >> Driver 'usbfs' needs updating - please use bus_type methods
> >> drv->bus->probe = 73756f6e (THAT's "nous" I think)
> >> drv->probe = d1069ab0
> >> drv->bus->remove = 00000062
> >> drv->remove = d1069960
> >> drv->bus->shutdown = 00000000
> >> drv->shutdown = 00000000
> >> usbcore: registered new driver usbfs
> >> Driver 'hub' needs updating - please use bus_type methods
> >> drv->bus->probe = 73756f6e
> >> drv->probe = d1069ab0
> >> drv->bus->remove = 00000062
> >> drv->remove = d1069960
> >> drv->bus->shutdown = 00000000
> >> drv->shutdown = 00000000
> >> usbcore: registered new driver hub
> >> Driver 'usb' needs updating - please use bus_type methods
> >> drv->bus->probe = 73756f6e
> >> drv->probe = d1069570
> >>
> >>> -----Original Message-----
> >>> From: Dan Magenheimer
> >>> Sent: Wednesday, June 03, 2009 4:12 PM
> >>> To: Keir Fraser; Isaku Yamahata
> >>> Cc: Xen-Devel (E-mail)
> >>> Subject: RE: Dom0 crashing when built with c/s 881 (Was:
> [Xen-devel]
> >>> blktap2: need more than 3 values to unpack)
> >>>
> >>>
> >>>> Actually I missed that the dependent code is only built if
> >>>> CONFIG_PCI_IOMULTI && CONFIG_HOTPLUG_PCI. You've probably got
> >>>> one or both
> >>>> disabled and hence 882 doesn't break without 881 in your case.
> >>>
> >>> In case it helps, with 889 and 881 reverted, I am using the
> >>> default config which results in CONFIG_PCI_IOMULTI=y and
> >>> CONFIG_HOTPLUG_PCI=m.
> >>>
> >>>> I can't explain that from reading the code. It looks like a
> >>>> no-op to me
> >>>> unless the new function bus_register_notifier() is called.
> >>>
> >>> Looking at my boot output on failure, there are those lines:
> >>>
> >>> "Driver 'xxx' needs updating - please use bus_type methods"
> >>>
> >>> which is printed in linux/drivers/base/driver.c:driver_register()
> >>> if a complex set of circumstances are true. So clearly
> >>> something is different.
> >>>
> >>> If that doesn't help, I can go add some printk's where that
> >>> output is happening and see exactly what forces the failure.
> >>>
> >>> Dan
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> >>>> Sent: Wednesday, June 03, 2009 3:28 PM
> >>>> To: Dan Magenheimer; Isaku Yamahata
> >>>> Cc: Xen-Devel (E-mail)
> >>>> Subject: Re: Dom0 crashing when built with c/s 881 (Was:
> >> [Xen-devel]
> >>>> blktap2: need more than 3 values to unpack)
> >>>>
> >>>>
> >>>> On 03/06/2009 22:17, "Dan Magenheimer"
> >>>> <dan.magenheimer@xxxxxxxxxx> wrote:
> >>>>
> >>>>>> 1. It only adds extra functionality which by default would
> >>>>>> not do anything.
> >>>>>> Just reading the patch I can see it's harmless by itself
> >>>> as it merely
> >>>>>> introduces a new notifier chain which noone registers on.
> >>>>>
> >>>>> I won't pretend to understand the code, but I did
> >>>>> reproduce the problem with 881 by itself and with
> >>>>> 889 with 881 reverted.
> >>>>
> >>>> I can't explain that from reading the code. It looks like a
> >>>> no-op to me
> >>>> unless the new function bus_register_notifier() is called.
> >>>>
> >>>>>> 2. Changeset 882 depends on 881. If you revert just 881 then
> >>>>>> the tree will not build.
> >>>>>
> >>>>> This doesn't appear to be the case for me, though
> >>>>> I'm certainly willing to believe there's something
> >>>>> wrong with my process:
> >>>>
> >>>> Actually I missed that the dependent code is only built if
> >>>> CONFIG_PCI_IOMULTI && CONFIG_HOTPLUG_PCI. You've probably got
> >>>> one or both
> >>>> disabled and hence 882 doesn't break without 881 in your case.
> >>>>
> >>>> -- Keir
> >>>>
> >>>>
> >>>>
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|