Changeset 881 is "pcie io space multiplex: backport of bus event
notification patch", right? I don't believe that you are reverting just that
patch, for two reasons:
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.
2. Changeset 882 depends on 881. If you revert just 881 then the tree will
not build.
-- Keir
On 03/06/2009 21:15, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:
>>> Is it better to have the new option added by
>>> c/s(CONFIG_PCI_IOMULTI) default 'n' ?
>
> Turning off that option doesn't stop my dom0 from crashing.
> Reverting 881 DOES stop my dom0 from crashing. Attached are
> the boot output for fail and success (the only difference
> between the two dom0's is the success has 881 reverted).
>
> Of note, the fail log has three lines of the type:
>
> "Driver 'xxx' needs updating - please use bus_type methods"
>
> (xxx = usbfs, hub, usb) and the success log has a line that says:
>
> "PCI IO multiplexer device installed"
>
> which is missing in the fail log.
>
>> -----Original Message-----
>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>> Sent: Wednesday, June 03, 2009 12:45 PM
>> To: Dulloor
>> Cc: Isaku Yamahata; Dan Magenheimer; 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)
>>
>>
>> Depends on the feature's impact when unused.
>>
>> -- Keir
>>
>> On 03/06/2009 18:57, "Dulloor" <dulloor@xxxxxxxxx> wrote:
>>
>>> Is it better to have the new option added by
>> c/s(CONFIG_PCI_IOMULTI) default
>>> 'n' ?
>>>
>>> -dulloor
>>>
>>> On Wed, Jun 3, 2009 at 1:48 PM, Keir Fraser
>> <keir.fraser@xxxxxxxxxxxxx> wrote:
>>>> Perhaps post a diff of boot output with c/s 880 vs c/s
>> 881. I've cc'ed
>>>> Isaku, who submitted the patch that's causing your problem.
>>>>
>>>> -- Keir
>>>>
>>>> On 03/06/2009 18:35, "Dan Magenheimer"
>> <dan.magenheimer@xxxxxxxxxx> wrote:
>>>>
>>>>> OK, it appears that linux-2.6.18-xen.hg c/s 881 is causing
>>>>> my dom0 to crash. Dom0 boots successfully at 880 and fails
>>>>> with 881 or anything after.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Dan Magenheimer
>>>>>> Sent: Tuesday, June 02, 2009 10:45 PM
>>>>>> To: Dan Magenheimer; Keir Fraser; Dutch Meyer; Xen-Devel (E-mail)
>>>>>> Subject: RE: [Xen-devel] blktap2: need more than 3
>> values to unpack
>>>>>>
>>>>>>
>>>>>> Followup: my dom0 boots failed with 888, boots fine with 876,
>>>>>> then to ensure no pilot error, I rebuilt 888 again and it
>>>>>> failed again.
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Dan Magenheimer
>>>>>>> Sent: Tuesday, June 02, 2009 5:50 PM
>>>>>>> To: Keir Fraser; Dutch Meyer; Xen-Devel (E-mail)
>>>>>>> Subject: RE: [Xen-devel] blktap2: need more than 3
>> values to unpack
>>>>>>>
>>>>>>>
>>>>>>> Thanks. It is indeed a pilot error on my part but a bit
>>>>>>> more bizarre. I apparently have a linux-2.6-xen.hg directory
>>>>>>> as both a sister and a child to xen-unstable.hg. In this
>>>>>>> case the build apparently chooses the child. I was
>>>>>>> looking at and modifying the un-updated child so
>>>>>>> blktap2 wasn't even present yet. Removing the child
>>>>>>> causes the sibling to build. BUT! Now dom0 is
>>>>>>> crashing early on during boot. (This is an Intel
>>>>>>> Weybridge box.) I'll look into this further tomorrow.
>>>>>>>
>>>>>>> ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>>>>>> ata2.00: ATAPI, max UDMA/100
>>>>>>> ata2.00: configured for UDMA/100
>>>>>>> scsi2 : ahci
>>>>>>> ata3: SATA link down (SStatus 0 SControl 300)
>>>>>>> scsi3 : ahci
>>>>>>> ata4: SATA link down (SStatus 0 SControl 300)
>>>>>>> Vendor: ATA Model: ST3320620AS Rev: 3.AA
>>>>>>> Type: Direct-Access ANSI SCSI
>> revision: 05
>>>>>>> ata1: EH pending after completion, repeating EH (cnt=4)
>>>>>>> Vendor: LITE-ON Model: DVDRW LH-20A1S Rev: 9L03
>>>>>>> Type: CD-ROM ANSI SCSI
>> revision: 05
>>>>>>> (XEN) PCI add device 00:1f.5
>>>>>>> ata_piix 0000:00:1f.5: MAP [ P0 P2 P1 P3 ]
>>>>>>> ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 19 (level,
>> low) -> IRQ 16
>>>>>>> ata5: SATA max UDMA/133 cmd 0x0 ctl 0x2 bmdma 0x0 irq 16
>>>>>>> ata6: SATA max UDMA/133 cmd 0x0 ctl 0x2 bmdma 0x0 irq 16
>>>>>>> scsi4 : ata_piix
>>>>>>> scsi5 : ata_piix
>>>>>>> device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised:
>>>>>>> dm-devel@xxxxxxxxxx
>>>>>>> Kernel panic - not syncing: Attempted to kill init!
>>>>>>> (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>>>>>>>> Sent: Tuesday, June 02, 2009 4:45 PM
>>>>>>>> To: Dan Magenheimer; Dutch Meyer; Xen-Devel (E-mail)
>>>>>>>> Subject: Re: [Xen-devel] blktap2: need more than 3 values
>>>>>> to unpack
>>>>>>>>
>>>>>>>>
>>>>>>>> Probably you had an old .config hanging around in your build
>>>>>>>> tree somewhere.
>>>>>>>> c/s 889 should fix this for a fresh build.
>>>>>>>>
>>>>>>>> -- Keir
>>>>>>>>
>>>>>>>> On 02/06/2009 18:33, "Dan Magenheimer"
>>>>>>>> <dan.magenheimer@xxxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>> Thanks. Looks like a partial configuration patch got checked
>>>>>>>>> in for blktap2 (cs 886)? CONFIG_XEN_BLKDEV_TAP2 must be
>>>>>>> configured
>>>>>>>>> but afaict is not turned on by default (yet?). So a fresh
>>>>>>>>> xen-unstable tip doesn't build the blktap2 driver. See:
>>>>>>>>>
>>>>>>>>>
>>>>>> http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/3e01555dd227
>>>>>>>>>
>>>>>>>>> (I'm guessing since this was submitted by Isaku that blktap2
>>>>>>>>> shouldn't be the default on ia64?)
>>>>>>>>>
>>>>>>>>> Should CONFIG_XEN_BLKDEV_TAP2 be turned on by default, instead
>>>>>>>>> of CONFIG_XEN_BLKDEV_TAP, at least on x86?
>>>>>>>>>
>>>>>>>>> I tried modifying
>>>>>>>>>
>>>>>>>>> linux-2.6.18-xen.hg/buildconfigs/linux-defconfig_xen0_x86_32
>>>>>>>>>
>>>>>>>>> (and also
>>>>>>>>>
>>>>>>>>> linux-2.6.18-xen.hg/buildconfigs/linux-defconfig_xen_x86_32)
>>>>>>>>>
>>>>>>>>> followed by:
>>>>>>>>>
>>>>>>>>> KERNELS=linux-2.6-xen0 make linux-2.6-xen-config
>>>>>>>> CONFIGMODE=oldconfig
>>>>>>>>>
>>>>>>>>> (I don't need or want to go through a manual config process)
>>>>>>>>>
>>>>>>>>> but BLKDEV_TAP is always selected, not BLKDEV_TAP2.
>>>>>>>>>
>>>>>>>>> Finally, I resorted to manually changing
>>>>>>>>>
>>>>>>>>> linux-2.6.18-xen.hg/drivers/xen/Kconfig
>>>>>>>>>
>>>>>>>>> and this succeeds in turning it on, but it just reverses the
>>>>>>>>> above checked-in patch, so I suspect that's not the right
>>>>>>>>> answer either.
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Dutch Meyer [mailto:dmeyer@xxxxxxxxx]
>>>>>>>>>> Sent: Tuesday, June 02, 2009 9:05 AM
>>>>>>>>>> To: Dan Magenheimer
>>>>>>>>>> Subject: RE: [Xen-devel] blktap2: need more than 3
>>>>>>> values to unpack
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think that you don't have the blktap2 driver loaded in
>>>>>>>>>> dom0. A clean
>>>>>>>>>> build/install of the dom0 kernel image should sort
>> you out. If
>>>>>>>>>> drivers/xen/blktap2 is compiled in it should be setting up
>>>>>>>>>> these paths.
>>>>>>>>>>
>>>>>>>>>> Let me know if that fixes things and I'll make python
>>>>>>> spit out more
>>>>>>>>>> meaningful errors, otherwise we can try to figure out the
>>>>>>>>>> blktap2 kernel
>>>>>>>>>> code isn't working.
>>>>>>>>>>
>>>>>>>>>> --Dutch
>>>>>>>>>>
>>>>>>>>>> On Tue, 2 Jun 2009, Dan Magenheimer wrote:
>>>>>>>>>>
>>>>>>>>>>> It replies with "didn't find blktap-control in /proc/misc"
>>>>>>>>>>>
>>>>>>>>>>> If that fails, perhaps the path doesn't exist, but I looked
>>>>>>>>>>> and /sys/class/blktap2 doesn't exist.
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Dutch Meyer [mailto:dmeyer@xxxxxxxxx]
>>>>>>>>>>>> Sent: Monday, June 01, 2009 10:37 PM
>>>>>>>>>>>> To: Dan Magenheimer
>>>>>>>>>>>> Subject: RE: [Xen-devel] blktap2: need more than 3
>>>>>>>> values to unpack
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Can you try this from the command line:
>>>>>>>>>>>>
>>>>>>>>>>>> tapdisk2 -n aio:/pathto/file.img
>>>>>>>>>>>>
>>>>>>>>>>>> If successful, this will create your aio device and print a
>>>>>>>>>>>> /dev device
>>>>>>>>>>>> associated with it.
>>>>>>>>>>>>
>>>>>>>>>>>> In that case you'll then be able to remove it with:
>>>>>>>>>>>>
>>>>>>>>>>>> echo 1 > /sys/class/blktap2/<disk>/remove
>>>>>>>>>>>>
>>>>>>>>>>>> Where <disk> will be obvious from the output of the
>>>>>>>>>> tapdisk2 command.
>>>>>>>>>>>>
>>>>>>>>>>>> However, I expect that this will fail.
>>>>>>>>>>>>
>>>>>>>>>>>> --Dutch
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, 1 Jun 2009, Dan Magenheimer wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Then I might be able to help, but I'm not sure how to
>>>>>>>>>>>> reproduce it. If
>>>>>>>>>>>> you send a log file and config for this latter error I'll
>>>>>>>>>>>> take a look.
>>>>>>>>>>>>
>>>>>>>>>>>> Here ya go.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Dan
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Dutch Meyer [mailto:dmeyer@xxxxxxxxx]
>>>>>>>>>>>> Sent: Monday, June 01, 2009 8:32 PM
>>>>>>>>>>>> To: Dan Magenheimer
>>>>>>>>>>>> Cc: Xen-Devel (E-mail)
>>>>>>>>>>>> Subject: Re: [Xen-devel] blktap2: need more than 3
>>>>>>>>>> values to unpack
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The tap:aio:/pathto/file.img syntax that you're
>>>>>> using in your
>>>>>>>>>>>> config was
>>>>>>>>>>>> changed before blktap2 was introduced.
>>>>>>>>>>>> tap:tapdisk:aio:/pathto/file.img is
>>>>>>>>>>>> apparently the correct syntax now, though the
>> README didn't
>>>>>>>>>>>> get updated to
>>>>>>>>>>>> reflect this. Our blktap2 documentation is no better -
>>>>>>>>>> I'll try to
>>>>>>>>>>>> remedy that this week.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> If you're still seeing this error:
>>>>>>>>>>>> "Error: 'file' object has no attribute 'find'"
>>>>>>>>>>>>
>>>>>>>>>>>> Then I might be able to help, but I'm not sure how to
>>>>>>>>>>>> reproduce it. If
>>>>>>>>>>>> you send a log file and config for this latter error I'll
>>>>>>>>>>>> take a look.
>>>>>>>>>>>> Yang seems to be reporting the same thing in
>>>>>> another thread.
>>>>>>>>>>>>
>>>>>>>>>>>> --Dutch
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, 1 Jun 2009, Dan Magenheimer wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hmmm... trying blktap2 for the first time, using 19682.
>>>>>>>>>>>> I had thought that the syntax hadn't changed, but I am
>>>>>>>>>>>> getting what appears to be a parsing error on
>> my vbd line.
>>>>>>>>>>>>
>>>>>>>>>>>> "ValueError: need more than 3 values to unpack"
>>>>>>>>>>>>
>>>>>>>>>>>> Thinking maybe that "w!" was the culprit, I changed
>>>>>>>>>>>> it to "w" with no change in result.
>>>>>>>>>>>>
>>>>>>>>>>>> Looking at the python code that generated the error,
>>>>>>>>>>>> I tried to figure out the syntax by experimentation
>>>>>>>>>>>> but without luck. I tried:
>>>>>>>>>>>>
>>>>>>>>>>>> tap:tapdisk:aio:/pathto/file.img
>>>>>>>>>>>>
>>>>>>>>>>>> but got "Error: 'file' object has no attribute 'find'"
>>>>>>>>>>>>
>>>>>>>>>>>> To see if I could use the old blktap, I tried
>>>>>>>>>>>>
>>>>>>>>>>>> tap:tapdisk:ioemu:/pathto/file.img
>>>>>>>>>>>>
>>>>>>>>>>>> but got the dreaded "Error: Device 768 (tap)
>> could not be
>>>>>>>>>>>> connected. Hotplug scripts not working"
>>>>>>>>>>>>
>>>>>>>>>>>> Am I missing something in the syntax for blktap2?
>>>>>>>>>>>> Is there a how-to or readme I didn't find? Or
>>>>>>>>>>>> is there some required dependency I don't know about
>>>>>>>>>>>> that is missing?
>>>>>>>>>>>>
>>>>>>>>>>>> I thought maybe I had a bad install, so rebuilt and
>>>>>>>>>>>> reinstalled with the same result.
>>>>>>>>>>>>
>>>>>>>>>>>> xend.log and config file attached.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Dan
>>>>>>>>>>>>
>>>>>>>>>>>> P.S. I am trying blktap2 because both blktap and
>>>>>>>>>>>> file-backed fail. Blktap sometimes reads garbage
>>>>>>>>>>>> from the file and
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Xen-devel mailing list
>>>>>>>>>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Xen-devel mailing list
>>>>>>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xen-devel mailing list
>>>>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home