thr3ads.net - Xen devel - [Xen-devel] EXPORT SYMBOL in evtchn.c breaks 2.4.26-xen0 [Aug 2004]

If this information is useful, please help other people find it:
Share via:

Sven Kretzschmar

2004-Aug-06 11:48 UTC

[Xen-devel] EXPORT SYMBOL in evtchn.c breaks 2.4.26-xen0

With the latest bk pull, I pulled in a patch of ../arch/xen/kernel/evtchn.c
which added an EXPORT_SYMBOL(evtchn_do_upcall) macro.
While this is necessary and works in 2.6.7, it breaks the 2.4.26-xen0 
compile (try make world or make clean linux-xen0).
Perhaps an #if (KERNEL_VERSION....) would be helpfull, or splitting the 
file (../arch/xen/kernel/evtchn.c) between 2.4.26 and 2.6.7 trees, because
currently it''s used by both trees via symlinks...

Regards,
  Sven




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Keir Fraser

2004-Aug-06 12:04 UTC

head link

Re: [Xen-devel] EXPORT SYMBOL in evtchn.c breaks 2.4.26-xen0

Hopefully fixed now?

 -- Keir
> 
> With the latest bk pull, I pulled in a patch of ../arch/xen/kernel/evtchn.c
> which added an EXPORT_SYMBOL(evtchn_do_upcall) macro.
> While this is necessary and works in 2.6.7, it breaks the 2.4.26-xen0 
> compile (try make world or make clean linux-xen0).
> Perhaps an #if (KERNEL_VERSION....) would be helpfull, or splitting the 
> file (../arch/xen/kernel/evtchn.c) between 2.4.26 and 2.6.7 trees, because
> currently it''s used by both trees via symlinks...
> 
> Regards,
>   Sven
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel -=- MIME -=- 

With the latest bk pull, I pulled in a patch of ../arch/xen/kernel/evtchn.c
which added an EXPORT_SYMBOL(evtchn_do_upcall) macro.
While this is necessary and works in 2.6.7, it breaks the 2.4.26-xen0 
compile (try make world or make clean linux-xen0).
Perhaps an #if (KERNEL_VERSION....) would be helpfull, or splitting the 
file (../arch/xen/kernel/evtchn.c) between 2.4.26 and 2.6.7 trees, because
currently it''s used by both trees via symlinks...

Regards,
  Sven




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Sven Kretzschmar

2004-Aug-06 14:00 UTC

head link

[Xen-devel] Problem exporting enbd device from Dom0 to DomU

I have got enbd to work in Dom0 (kernel 2.6.7).
This means I can access a remote block device on another
physical server from Dom0.
I have put a file system on it, copied around, etc. Works.
So far so good....
When I try to export the enbd device ("dev/nda") from Dom0
to another unprivileged domain (with kernel 2.4.26) then it does not work.
The interesting part of my xmdefaults file looks like that:

disk = [''phy:nda,sdb,w'',''phy:hda3,sda1,w]
...
root = "/dev/sda1 ro"

I am using sda1 as root device and wanted to use sdb as an
additonal device to play with.

I am starting the xen-U domain like this:

xm create cpu=-1 ip=192.168.1.75

and the xend log shows:

[2004-08-06 16:35:52 xend] DEBUG (__init__:988) init_domain> Created domain=3
name=ExampleDomain1 memory=256
[2004-08-06 16:35:52 xend] INFO (__init__:988) Created console id=13 domain=3
port=9603
[2004-08-06 16:35:52 xend] DEBUG (__init__:988) Creating vbd dom=3 uname=phy:nda
dev=sdb
[2004-08-06 16:35:52 xend] DEBUG (__init__:988) Creating vbd dom=3
uname=phy:hda3 dev=sda1
[2004-08-06 16:35:52 xend] DEBUG (__init__:988) Creating vif dom=3 vif=0
mac=aa:00:00:49:eb:59
[2004-08-06 16:35:52 xend] DEBUG (__init__:988) Error: Adding extent to vbd
failed! (device 2b00)
[2004-08-06 16:35:52 xend] DEBUG (__init__:988) Connecting blkif to event
channel dom=3 ports=14:4

I think the line starting with "Error:..." is the important one. What
does device 2b00 mean ?

Btw: I am only trying to create exactly one (unpriv.) Domain.

When I try to access /dev/sdb in the created Domain, I receive an "is not a
valid block device" error, exactly like
with any other unassigned device.

Are there any known problems with enbd devices and xen ?
Did I made a configuration mistake ?
Has anybody else tried to get enbd to work with xen (with 2.6.7 Dom0 and 2.4.36
DomU) ?

TIA + Regards,
  Sven




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Ian Pratt

2004-Aug-06 14:31 UTC

head link

Re: [Xen-devel] Problem exporting enbd device from Dom0 to DomU

> When I try to export the enbd device ("dev/nda") from Dom0
> to another unprivileged domain (with kernel 2.4.26) then it does not work.
> The interesting part of my xmdefaults file looks like that:
> 
> disk = [''phy:nda,sdb,w'',''phy:hda3,sda1,w]
> [2004-08-06 16:35:52 xend] DEBUG (__init__:988) Error: Adding extent to vbd
failed! (device 2b00)
> [2004-08-06 16:35:52 xend] DEBUG (__init__:988) Connecting blkif to event
channel dom=3 ports=14:4
> 
> I think the line starting with "Error:..." is the important one.
What does device 2b00 mean ?
Please can you post the output of dmesg from dom0, also ''ls -l
/dev/nda''
''sfdisk -s /dev/nda''.


Ian


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Sven Kretzschmar

2004-Aug-06 14:53 UTC

head link

Re: [Xen-devel] Problem exporting enbd device from Dom0 to DomU

Here are the requested outputs.
HTH ?!  ;-)

 Sven

[root@testy1 root]# sfdisk -s /dev/nda
9775520

[root@testy1 root]# ls -al /dev/nda
brw-r--r--  1 root root 43, 0 Aug  1 13:15 /dev/nda

[root@testy1 root]# dmesg
Linux version 2.6.7-xen0 (root@testy1.local) (gcc version 3.3.3 20040412 (Red
Hat Linux 3.3.3-7)) #7 Fri Aug 6 15:06:44 CEST 2004
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 0000000008000000 (usable)
128MB LOWMEM available.
On node 0 totalpages: 32768
  DMA zone: 0 pages, LIFO batch:1
  Normal zone: 32768 pages, LIFO batch:8
  HighMem zone: 0 pages, LIFO batch:1
DMI not present.
Built 1 zonelists
Kernel command line: /boot/vmlinuz-2.6.7-xen0 root=/dev/hda1 ro console=vga
Unknown boot option `/boot/vmlinuz-2.6.7-xen0'': ignoring
Initializing CPU#0
PID hash table entries: 1024 (order 10: 8192 bytes)
Xen reported: 2792.137 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Memory: 126528k/131072k available (1879k kernel code, 4352k reserved, 571k data,
340k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 5570.56 BogoMIPS
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU:     After generic identify, caps: bfebfbff 00000000 00000000 00000000
CPU:     After vendor identify, caps: bfebfbff 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU:     After all inits, caps: bfebfbff 00000000 00000000 00000080
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking ''hlt'' instruction... disabled
NET: Registered protocol family 16
PCI: Using configuration type Xen
SCSI subsystem initialized
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Probing PCI hardware (bus 01)
PCI: Probing PCI hardware
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
NTFS driver 2.1.14 [Flags: R/O].
udf: registering filesystem
Real Time Clock Driver v1.12
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Obtained IRQ 16 for device 0000:00:1f.1
ICH4: chipset revision 1
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:DMA
hda: Maxtor 6Y060L0, ATA DISK drive
Using anticipatory io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdd: CD-RW 48X16, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 120103200 sectors (61492 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
 hda: hda1 hda2 hda3 hda4 < hda5 >
hdd: ATAPI 48X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
mice: PS/2 mouse device common for all mice
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard on isa0060/serio0
Xen virtual console successfully installed as ttyS
Event-channel device installed.
Initialising Xen netif backend
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 340k freed
Warning: unable to open an initial console.
EXT3 FS on hda1, internal journal
Adding 1024120k swap on /dev/hda2.  Priority:-1 extents:1
e100: Intel(R) PRO/100 Network Driver, 3.0.18
e100: Copyright(c) 1999-2004 Intel Corporation
PCI: Obtained IRQ 22 for device 0000:01:0a.0
e100: eth0: e100_probe: addr 0xe8080000, irq 22, MAC addr 00:30:1B:AE:F0:D1
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
e1000: Ignoring new-style parameters in presence of obsolete ones
Intel(R) PRO/1000 Network Driver - version 5.2.52-k4
Copyright (c) 1999-2004 Intel Corporation.
PCI: Obtained IRQ 21 for device 0000:01:09.0
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: eth1: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
e1000: eth1: e1000_watchdog: NIC Link is Down
e1000: eth1: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
ENBD #5150[0]: enbd_init Network Block Device originally by pavel@elf.mj.gts.cz
ENBD #5151[0]: enbd_init Network Block Device port to 2.0 by ptb@it.uc3m.es
ENBD #5153[0]: enbd_init Network Block Device move networking to user space by
amarin@it.uc3m.es
ENBD #5155[0]: enbd_init Enhanced Network Block Device 2.4.30 $Date: 2002/09/17
16:33:22 $ by ptb@it.uc3m.es
ENBD #5195[0]: enbd_init registered device at major 43
warning: process `enbd-client'' used the obsolete bdflush system call
Fix your initscripts?
warning: process `enbd-client'' used the obsolete bdflush system call
Fix your initscripts?
warning: process `enbd-client'' used the obsolete bdflush system call
Fix your initscripts?
ENBD #3754[0]: fixup_slot failed to find slot for pid 1541 ioctl 4004ab10 arg
bfffe120 (74736574)
ENBD #2738[0]: enbd_set_sock increased socket count to 2
ENBD #2533[0]: enbd_enable set VALID on nda
ENBD #823[0]: enbd_open DISK CHECK wanted in open on device nda
ENBD #4398[0]: enbd_media_changed MEDIA CHANGED called
ENBD #4454[0]: enbd_media_changed REMOTE CHECK still has REMOTE VALID on nda
ENBD #823[1]: enbd_open DISK CHECK wanted in open on device nda
ENBD #4398[1]: enbd_media_changed MEDIA CHANGED called
ENBD #4454[1]: enbd_media_changed REMOTE CHECK still has REMOTE VALID on nda
ENBD #2738[1]: enbd_set_sock increased socket count to 4
ENBD #823[2]: enbd_open DISK CHECK wanted in open on device nda
ENBD #4398[2]: enbd_media_changed MEDIA CHANGED called
ENBD #4454[2]: enbd_media_changed REMOTE CHECK still has REMOTE VALID on nda
ENBD #823[3]: enbd_open DISK CHECK wanted in open on device nda
ENBD #4398[3]: enbd_media_changed MEDIA CHANGED called
ENBD #4454[3]: enbd_media_changed REMOTE CHECK still has REMOTE VALID on nda
ENBD #823[4]: enbd_open DISK CHECK wanted in open on device nda
ENBD #4398[4]: enbd_media_changed MEDIA CHANGED called
ENBD #4454[4]: enbd_media_changed REMOTE CHECK still has REMOTE VALID on nda



*********** REPLY SEPARATOR  ***********

On 06.08.2004 at 15:31 Ian Pratt wrote:
>> When I try to export the enbd device ("dev/nda") from Dom0
>> to another unprivileged domain (with kernel 2.4.26) then it does not
>work.
>> The interesting part of my xmdefaults file looks like that:
>> 
>> disk = [''phy:nda,sdb,w'',''phy:hda3,sda1,w]
>
>> [2004-08-06 16:35:52 xend] DEBUG (__init__:988) Error: Adding extent to
>vbd failed! (device 2b00)
>> [2004-08-06 16:35:52 xend] DEBUG (__init__:988) Connecting blkif to
>event channel dom=3 ports=14:4
>> 
>> I think the line starting with "Error:..." is the important
one. What
>does device 2b00 mean ?
>
>Please can you post the output of dmesg from dom0, also ''ls -l
/dev/nda''
>''sfdisk -s /dev/nda''.
>
>
>Ian




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Sven Kretzschmar

2004-Aug-06 23:12 UTC

head link

[Xen-devel] Newer Changesets broke Dom0 boot with 2.6.7

It seems that newer changesets broke booting a Dom0 with kernel 2.6.7.
At least with Fedora Core 2, which I am using.
CSet 1.1153 was the last one working correctly for me.
CSet 1.1154 introduced segfaults during bootprocess with kudzu and hwclock,
but the kernel was still able to finish the bootprocess.
(I did not test any CSets between 1.1153 and 1.1154).
Cset 1.1156: Like 1.1154
CSet 1.1158 Additonal segfaults during Dom0 boot with
/sbin/devlabel, initlog and mounting file systems.
The kernel is no longer able to boot Dom0; the boot process
freezes.

I have only tested this with booting a Dom0 with kernel 2.6.7 so I
don''t
know (yet) if the new CSets also broke some things with 2.4.26.

Sven





-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Ian Pratt

2004-Aug-06 23:22 UTC

head link

Re: [Xen-devel] Newer Changesets broke Dom0 boot with 2.6.7

> 
> It seems that newer changesets broke booting a Dom0 with kernel 2.6.7.
> At least with Fedora Core 2, which I am using.
> CSet 1.1153 was the last one working correctly for me.
> CSet 1.1154 introduced segfaults during bootprocess with kudzu and hwclock,
> but the kernel was still able to finish the bootprocess.
> (I did not test any CSets between 1.1153 and 1.1154).
> Cset 1.1156: Like 1.1154
> CSet 1.1158 Additonal segfaults during Dom0 boot with
> /sbin/devlabel, initlog and mounting file systems.
> The kernel is no longer able to boot Dom0; the boot process
> freezes.
Thanks for the report.

Please can you try ''mv /lib/tls /lib/tlsXXX''.  If that helps,
please can you put it back and try adding ''nosegfixup'' on the
kernel command line.

Thanks,
Ian


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Sven Kretzschmar

2004-Aug-07 00:30 UTC

head link

Fwd: Re: [Xen-devel] Problem exporting enbd device from Dom0 to DomU

OK, with the new patch (CSet 1.1164) in the bitkeeper repository
export of enbd devices from Dom0 to DomU is working now. Thx :-)

Sven


>
>Here are the requested outputs.
>HTH ?!  ;-)
>
> Sven
>
>[root@testy1 root]# sfdisk -s /dev/nda
>9775520
>
>[root@testy1 root]# ls -al /dev/nda
>brw-r--r--  1 root root 43, 0 Aug  1 13:15 /dev/nda
>
>[root@testy1 root]# dmesg
>Linux version 2.6.7-xen0 (root@testy1.local) (gcc version 3.3.3 20040412
>(Red Hat Linux 3.3.3-7)) #7 Fri Aug 6 15:06:44 CEST 2004
>BIOS-provided physical RAM map:
> Xen: 0000000000000000 - 0000000008000000 (usable)
[....]>ENBD #5150[0]: enbd_init Network Block Device originally by
>pavel@elf.mj.gts.cz
>ENBD #5151[0]: enbd_init Network Block Device port to 2.0 by ptb@it.uc3m.es
>ENBD #5153[0]: enbd_init Network Block Device move networking to user
>space by amarin@it.uc3m.es
>ENBD #5155[0]: enbd_init Enhanced Network Block Device 2.4.30 $Date:
>2002/09/17 16:33:22 $ by ptb@it.uc3m.es
>ENBD #5195[0]: enbd_init registered device at major 43
>warning: process `enbd-client'' used the obsolete bdflush system
call
>Fix your initscripts?
>warning: process `enbd-client'' used the obsolete bdflush system
call
>Fix your initscripts?
>warning: process `enbd-client'' used the obsolete bdflush system
call
>Fix your initscripts?
>ENBD #3754[0]: fixup_slot failed to find slot for pid 1541 ioctl 4004ab10
>arg bfffe120 (74736574)
>ENBD #2738[0]: enbd_set_sock increased socket count to 2
>ENBD #2533[0]: enbd_enable set VALID on nda
>ENBD #823[0]: enbd_open DISK CHECK wanted in open on device nda
>ENBD #4398[0]: enbd_media_changed MEDIA CHANGED called
>ENBD #4454[0]: enbd_media_changed REMOTE CHECK still has REMOTE VALID on
>nda
>ENBD #823[1]: enbd_open DISK CHECK wanted in open on device nda
>ENBD #4398[1]: enbd_media_changed MEDIA CHANGED called
>ENBD #4454[1]: enbd_media_changed REMOTE CHECK still has REMOTE VALID on
>nda
>ENBD #2738[1]: enbd_set_sock increased socket count to 4
>ENBD #823[2]: enbd_open DISK CHECK wanted in open on device nda
>ENBD #4398[2]: enbd_media_changed MEDIA CHANGED called
>ENBD #4454[2]: enbd_media_changed REMOTE CHECK still has REMOTE VALID on
>nda
>ENBD #823[3]: enbd_open DISK CHECK wanted in open on device nda
>ENBD #4398[3]: enbd_media_changed MEDIA CHANGED called
>ENBD #4454[3]: enbd_media_changed REMOTE CHECK still has REMOTE VALID on
>nda
>ENBD #823[4]: enbd_open DISK CHECK wanted in open on device nda
>ENBD #4398[4]: enbd_media_changed MEDIA CHANGED called
>ENBD #4454[4]: enbd_media_changed REMOTE CHECK still has REMOTE VALID on
>nda
>
>
>
>*********** REPLY SEPARATOR  ***********
>
>On 06.08.2004 at 15:31 Ian Pratt wrote:
>
>>> When I try to export the enbd device ("dev/nda") from
Dom0
>>> to another unprivileged domain (with kernel 2.4.26) then it does
not
>>work.
>>> The interesting part of my xmdefaults file looks like that:
>>> 
>>> disk =
[''phy:nda,sdb,w'',''phy:hda3,sda1,w]
>>
>>> [2004-08-06 16:35:52 xend] DEBUG (__init__:988) Error: Adding
extent to
>>vbd failed! (device 2b00)
>>> [2004-08-06 16:35:52 xend] DEBUG (__init__:988) Connecting blkif to
>>event channel dom=3 ports=14:4
>>> 
>>> I think the line starting with "Error:..." is the
important one. What
>>does device 2b00 mean ?
>>
>>Please can you post the output of dmesg from dom0, also ''ls -l
/dev/nda''
>>''sfdisk -s /dev/nda''.
>>
>>
>>Ian
>
>
*********** END FORWARDED MESSAGE  ***********



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Sven Kretzschmar

2004-Aug-07 09:54 UTC

head link

Re: [Xen-devel] Newer Changesets broke Dom0 boot with 2.6.7

I tried your proposals, but it helped only to solve a
part of the problems:

By either adding "nosegfixup" to the kernel command line
and/or renaming /lib/tls, I could get rid of the segfaults which
totally prevented the 2.6.7 kernel from booting in Dom0 (Csets 1.1158+).
So, in this case, it helped a lot ;-)

However, it did not remove the segfaults generated by
kudzu and hwclock, which were introduced around
CSet 1.1154.
It seems that something was changed concerning how
you directly access hardware in xen(-linux) starting
around CSet 1.1154, because both kudzu and hwclock
directly address hardware (..?).

If you need any further debugging for both issues (I assume
"nosegfixup" is only a workaround and not a real bugfix) 
from me, just drop me an email and tell me what debug
options I have to activate ;-)

Thx + have a nice weekend to all,
  Sven...switching over from computer live to real live....

*********** REPLY SEPARATOR  ***********

On 07.08.2004 at 00:22 Ian Pratt wrote:
>> 
>> It seems that newer changesets broke booting a Dom0 with kernel 2.6.7.
>> At least with Fedora Core 2, which I am using.
>> CSet 1.1153 was the last one working correctly for me.
>> CSet 1.1154 introduced segfaults during bootprocess with kudzu and
>hwclock,
>> but the kernel was still able to finish the bootprocess.
>> (I did not test any CSets between 1.1153 and 1.1154).
>> Cset 1.1156: Like 1.1154
>> CSet 1.1158 Additonal segfaults during Dom0 boot with
>> /sbin/devlabel, initlog and mounting file systems.
>> The kernel is no longer able to boot Dom0; the boot process
>> freezes.
>
>Thanks for the report.
>
>Please can you try ''mv /lib/tls /lib/tlsXXX''.  If that
helps,
>please can you put it back and try adding ''nosegfixup'' on
the
>kernel command line.
>
>Thanks,
>Ian

-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Ian Pratt

2004-Aug-07 10:21 UTC

head link

Re: [Xen-devel] Newer Changesets broke Dom0 boot with 2.6.7

> I tried your proposals, but it helped only to solve a
> part of the problems:
> 
> By either adding "nosegfixup" to the kernel command line
> and/or renaming /lib/tls, I could get rid of the segfaults which
> totally prevented the 2.6.7 kernel from booting in Dom0 (Csets 1.1158+).
> So, in this case, it helped a lot ;-)
Ok, Keir''s new binary rewriting patch obviously has problems with
the libc shipped with FC2. 

I suspect we''ll have to setup FC2 here to be able to debug this,
which is a pain.
 > However, it did not remove the segfaults generated by
> kudzu and hwclock, which were introduced around
> CSet 1.1154.
> It seems that something was changed concerning how
> you directly access hardware in xen(-linux) starting
> around CSet 1.1154, because both kudzu and hwclock
> directly address hardware (..?).
Please can you try a ''cset -x1.1162'' which changed some of the
iopl
handling.
> If you need any further debugging for both issues (I assume
> "nosegfixup" is only a workaround and not a real bugfix) 
> from me, just drop me an email and tell me what debug
> options I have to activate ;-)
I hope the failure with FC2 is just a bug in the new binary
rewriting code rather than a violation of one of the assumptions,
which will cause us to have to disable it (in which case, we''d
have to recommend moving /lib/tls out the way as the only decent
workaround).

If you could make a tar ball of your /lib/tls directory available
that may save us from having to do a full FC2 install.


Ian



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Keir Fraser

2004-Aug-08 17:56 UTC

head link

Re: [Xen-devel] Newer Changesets broke Dom0 boot with 2.6.7

I am unable to reproduce any of these problems booting vanilla RedHat
9 as DOM0. This is odd as I might expect to at least see the
hwclock/kudzu problem...

I''ll install vanilla FC2 tomorrow and see what happens.

 -- Keir
> 
> I tried your proposals, but it helped only to solve a
> part of the problems:
> 
> By either adding "nosegfixup" to the kernel command line
> and/or renaming /lib/tls, I could get rid of the segfaults which
> totally prevented the 2.6.7 kernel from booting in Dom0 (Csets 1.1158+).
> So, in this case, it helped a lot ;-)
> 
> However, it did not remove the segfaults generated by
> kudzu and hwclock, which were introduced around
> CSet 1.1154.
> It seems that something was changed concerning how
> you directly access hardware in xen(-linux) starting
> around CSet 1.1154, because both kudzu and hwclock
> directly address hardware (..?).
> 
> If you need any further debugging for both issues (I assume
> "nosegfixup" is only a workaround and not a real bugfix) 
> from me, just drop me an email and tell me what debug
> options I have to activate ;-)
> 
> Thx + have a nice weekend to all,
>   Sven...switching over from computer live to real live....
> 
> *********** REPLY SEPARATOR  ***********
> 
> On 07.08.2004 at 00:22 Ian Pratt wrote:
> 
> >> 
> >> It seems that newer changesets broke booting a Dom0 with kernel
2.6.7.
> >> At least with Fedora Core 2, which I am using.
> >> CSet 1.1153 was the last one working correctly for me.
> >> CSet 1.1154 introduced segfaults during bootprocess with kudzu and
> >hwclock,
> >> but the kernel was still able to finish the bootprocess.
> >> (I did not test any CSets between 1.1153 and 1.1154).
> >> Cset 1.1156: Like 1.1154
> >> CSet 1.1158 Additonal segfaults during Dom0 boot with
> >> /sbin/devlabel, initlog and mounting file systems.
> >> The kernel is no longer able to boot Dom0; the boot process
> >> freezes.
> >
> >Thanks for the report.
> >
> >Please can you try ''mv /lib/tls /lib/tlsXXX''.  If
that helps,
> >please can you put it back and try adding
''nosegfixup'' on the
> >kernel command line.
> >
> >Thanks,
> >Ian
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Sven Kretzschmar

2004-Aug-08 23:19 UTC

head link

Re: [Xen-devel] Newer Changesets broke Dom0 boot with 2.6.7 and FC2

There seems to be some strange things going on...
Normally, the first thing I do after cloning a new xeno-unstable
distribution is to change the drivers for my ethercards from
non-module to module config (Because when I boot a
normal, non-xen kernel on the same machine, it always
orders my cards differently than the xen kernel. With
modules and modprobe.conf, I can assign it always to
eth0, eth1, etc. like I want it to be).

If I just do (in an empty dir):
1.) bk clone
2.) make world
3.) make linux26
4.) make install   (it seems that this step repeats compiling the 2.4. kernels,
why ?)
and reboot, I can _not_ see any problems with kudzu and hwclock during boot
process,
even with the newest changesets (and "nosegfixup" boot option is set
!).
Only when shutting down the machine (via "halt"), I can see a
"syncing hardware
clock to system time  [failed]", but no (visible) segfault.
However, if I don''t set the "nosegfixup" boot option, the
boot process will freeze
with segfaults of devlabel, initlog and mounting filesystems, but even in this
case
no segfaults occur with kudzu and hwclock (they get called earlier in the boot
process
before booting freezes).

Then I do the following to configure my ethercard drivers (100/1000 MBits)
as modules:
1.) cd linux-2.6.7-xen0
2.) make menuconfig ARCH=xen
3.) change the needed ethercard drivers from [*] to [M]   (and really nothing
else)
4.) save the new config when asked when I exit
5.) make clean ARCH=xen
6.) make ARCH=xen
7.) make modules_install ARCH=xen
8.) make install ARCH=xen
9.) reboot
After rebooting now I see all errors I have reported before:
segfaults with kudzu and hwclock (even with "nosegfixup" boot option
set)
and if I dont set the "nosegfixup" boot option, the boot process does
not finish
and freezes like before.
So after changing the ethercard drivers from compiled in to module, 
hwclock and kudzu don''t work correctly any more ??
I also think, the Dom0 2.6.7 kenrnel is normally using no modules at all ?

Am I doing something wrong here ? Does the top directory Makefile
use another config (not the .config in the kernel source directory) ?

If my procedure of changing the kernel configs is wrong, what is
the correct one ?

TIA,
  Sven

*********** REPLY SEPARATOR  ***********

On 08.08.2004 at 18:56 Keir Fraser wrote:
>I am unable to reproduce any of these problems booting vanilla RedHat
>9 as DOM0. This is odd as I might expect to at least see the
>hwclock/kudzu problem...
>
>I''ll install vanilla FC2 tomorrow and see what happens.
>
> -- Keir
>
>> 
>> I tried your proposals, but it helped only to solve a
>> part of the problems:
>> 
>> By either adding "nosegfixup" to the kernel command line
>> and/or renaming /lib/tls, I could get rid of the segfaults which
>> totally prevented the 2.6.7 kernel from booting in Dom0 (Csets
1.1158+).
>> So, in this case, it helped a lot ;-)
>> 
>> However, it did not remove the segfaults generated by
>> kudzu and hwclock, which were introduced around
>> CSet 1.1154.
>> It seems that something was changed concerning how
>> you directly access hardware in xen(-linux) starting
>> around CSet 1.1154, because both kudzu and hwclock
>> directly address hardware (..?).
>> 
>> If you need any further debugging for both issues (I assume
>> "nosegfixup" is only a workaround and not a real bugfix) 
>> from me, just drop me an email and tell me what debug
>> options I have to activate ;-)
>> 
>> Thx + have a nice weekend to all,
>>   Sven...switching over from computer live to real live....
>> 
>> *********** REPLY SEPARATOR  ***********
>> 
>> On 07.08.2004 at 00:22 Ian Pratt wrote:
>> 
>> >> 
>> >> It seems that newer changesets broke booting a Dom0 with
kernel 2.6.7.
>> >> At least with Fedora Core 2, which I am using.
>> >> CSet 1.1153 was the last one working correctly for me.
>> >> CSet 1.1154 introduced segfaults during bootprocess with kudzu
and
>> >hwclock,
>> >> but the kernel was still able to finish the bootprocess.
>> >> (I did not test any CSets between 1.1153 and 1.1154).
>> >> Cset 1.1156: Like 1.1154
>> >> CSet 1.1158 Additonal segfaults during Dom0 boot with
>> >> /sbin/devlabel, initlog and mounting file systems.
>> >> The kernel is no longer able to boot Dom0; the boot process
>> >> freezes.
>> >
>> >Thanks for the report.
>> >
>> >Please can you try ''mv /lib/tls /lib/tlsXXX''.  If
that helps,
>> >please can you put it back and try adding
''nosegfixup'' on the
>> >kernel command line.
>> >
>> >Thanks,
>> >Ian
>> 
>> 
>> 
>> 
>> 
>> -------------------------------------------------------
>> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
>> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
>> one more big change to announce. We are now OSTG- Open Source
Technology
>> Group. Come see the changes on the new OSTG site. www.ostg.com
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/xen-devel

-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Xen devel - Aug 2004 - EXPORT SYMBOL in evtchn.c breaks 2.4.26-xen0

[Xen-devel] EXPORT SYMBOL in evtchn.c breaks 2.4.26-xen0

Re: [Xen-devel] EXPORT SYMBOL in evtchn.c breaks 2.4.26-xen0

[Xen-devel] Problem exporting enbd device from Dom0 to DomU

Re: [Xen-devel] Problem exporting enbd device from Dom0 to DomU

Re: [Xen-devel] Problem exporting enbd device from Dom0 to DomU

[Xen-devel] Newer Changesets broke Dom0 boot with 2.6.7

Re: [Xen-devel] Newer Changesets broke Dom0 boot with 2.6.7

Fwd: Re: [Xen-devel] Problem exporting enbd device from Dom0 to DomU

Re: [Xen-devel] Newer Changesets broke Dom0 boot with 2.6.7

Re: [Xen-devel] Newer Changesets broke Dom0 boot with 2.6.7

Re: [Xen-devel] Newer Changesets broke Dom0 boot with 2.6.7

Re: [Xen-devel] Newer Changesets broke Dom0 boot with 2.6.7 and FC2