Probleme mit eHD in einem xen-domU-vdr

livefields · 12. Februar 2010

Hallo zusammen,

passend zu den Olympischen Winterspielen habe ich mich entschlossen auf nen HD-VDR aufzurüsten. Nach umfangreicher Recherche im Forum habe ich mir eine Reel eHD zugelegt und versuche nun diese in meinem vdr - der als eigene domU (also virtuelle Maschine) innerhalb XEN konfiguriert ist - zum laufen zu bringen.

Aus den verschiedensten Anleitungen habe ich mir die nötigen Informationen zusammen gepickt und denke, dass mein Vorgehen eigentlich passen sollte. Aktuell bin ich jetzt bei dem Punkt "gebaute eHD Treibermodule laden" angelangt. Dieser schlägt jedoch leider mit folgender Meldung fehl:

Code

vdr:/usr/local/src/eHD/hdshm3/x86/driver# modprobe hdshm


Message from syslogd@vdr at Feb 12 21:43:47 ...
 kernel:[  416.738178] Oops: 0002 [#1] SMP     


Message from syslogd@vdr at Feb 12 21:43:47 ...
 kernel:[  416.738252] Process modprobe (pid: 1402, ti=df370000 task=deaa6280 task.ti=df370000)
Speicherzugriffsfehler
vdr:/usr/local/src/eHD/hdshm3/x86/driver#
Message from syslogd@vdr at Feb 12 21:43:47 ...
 kernel:[  416.738258] Stack: e13c0920 cb000000 00000000 00000000 e13c1780 e104b006 e13c1780 c013aaa4


Message from syslogd@vdr at Feb 12 21:43:47 ...
 kernel:[  416.738271]        00002994 ded8fec8 00690674 c16ce100 dea9f000 00000200 00e76000 e13c1780


Message from syslogd@vdr at Feb 12 21:43:47 ...
 kernel:[  416.738284]        deab07b0 00000000 00000003 00000000 00000000 00000000 00000000 00000000


Message from syslogd@vdr at Feb 12 21:43:47 ...
 kernel:[  416.738296] Call Trace:


Message from syslogd@vdr at Feb 12 21:43:47 ...
 kernel:[  416.738302]  [<e104b006>] hdshm_init+0x6/0x5b [hdshm]


Message from syslogd@vdr at Feb 12 21:43:47 ...
 kernel:[  416.738309]  [<c013aaa4>] sys_init_module+0x187a/0x19ea


Message from syslogd@vdr at Feb 12 21:43:47 ...
 kernel:[  416.738323]  [<c012d713>] param_get_int+0x0/0x14


Message from syslogd@vdr at Feb 12 21:43:47 ...
 kernel:[  416.738334]  [<c01042d4>] ia32pv_cstar_target+0x6c/0x8a


Message from syslogd@vdr at Feb 12 21:43:47 ...
 kernel:[  416.738343]  =======================


Message from syslogd@vdr at Feb 12 21:43:47 ...
 kernel:[  416.738347] Code: 3c e1 b9 00 00 0c 00 c7 05 08 1d 3c e1 08 1d 3c e1 c7 05 04 1d 3c e1 01 00 00 00 c7 05 00 1d 3c e1 00 00 00 00 89 3d f4 1c 3c e1 <f3> ab a1 f4 1c 3c e1 31 d2 83 c4 10 c7 40 18 00 00 00 00 5f 89


Message from syslogd@vdr at Feb 12 21:43:47 ...
 kernel:[  416.738406] EIP: [<e13c0059>] hdshm_init_struct_host+0xb8/0xcf [hdshm] SS:ESP 0069:df371e6c
vdr:/usr/local/src/eHD/hdshm3/x86/driver

Alles anzeigen

Was bisher geklappt hat:
- eHD Karte in meine vdr-domU durchreichen:

Code

vdr:/# lspci -v
00:00.0 Multimedia controller: Micronas USA, Inc. Device 8100
        Subsystem: Micronas USA, Inc. Device 8100
        Flags: medium devsel, IRQ 17
        Memory at d7fff000 (32-bit, non-prefetchable) [disabled] [size=4K]
        Memory at c8000000 (32-bit, non-prefetchable) [disabled] [size=128M]
        Capabilities: [40] Power Management version 2


00:01.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
        Subsystem: Technotrend Systemtechnik GmbH S2-3200
        Flags: bus master, medium devsel, latency 32, IRQ 18
        Memory at d7ffe000 (32-bit, non-prefetchable) [size=512]
        Kernel driver in use: budget_ci dvb
        Kernel modules: budget-ci

Alles anzeigen

- Revision 13931 der Reelbox Installpakete auschecken
- Treibermodule bauen, nach Anpassung der hdshm.c gemäß Wiki, obwohl dies ja eigentlich aktuell nicht mehr nötig sein sollte. Ich vermute jedoch, dass mein an XEN angepasster Kernel 2.6.26-2-xen-686 die Änderungen für 2.6.27 ebenfalls benötigt. Ohne diese hat das Bauen jedenfalls nicht funktioniert.
- TFTPD-Server einrichten

Ich hoffe einer der Experten wie IG88, C-3PO, Stalker, frodo, real_schorsch,... erbarmt sich meiner und hilft mir den Fehler zu finden

Vielen Dank im Voraus
Grüße livefields

EDIT:

Ach so, hier vielleicht noch die dmesg Ausgabe (ich habe vor dem modprobe hdshm noch ein modprobe tun gemacht):

Code

[  356.167752] tun: Universal TUN/TAP device driver, 1.6
[  356.167752] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[  416.738122] hdshm_init_struct: Phys start cb000000, start 00000000, nc-start 00000000
[  416.738147] BUG: unable to handle kernel NULL pointer dereference at 00000000
[  416.738154] IP: [<e13c0059>] :hdshm:hdshm_init_struct_host+0xb8/0xcf
[  416.738170] *pdpt = 0000000004f72027 *pde = 0000000000000000
[  416.738178] Oops: 0002 [#1] SMP
[  416.738184] Modules linked in: hdshm(+) tun ipv6 nfs lockd nfs_acl sunrpc evdev lnbp21 stb6100 stb0899 budget_ci ir_common firmware_class budget_core dvb_core saa7146 ttpci_eeprom ir_core i2c_core ext3 jbd mbcache thermal_sys
[  416.738215]
[  416.738219] Pid: 1402, comm: modprobe Not tainted (2.6.26-2-xen-686 #1)
[  416.738225] EIP: 0061:[<e13c0059>] EFLAGS: 00010246 CPU: 0
[  416.738232] EIP is at hdshm_init_struct_host+0xb8/0xcf [hdshm]
[  416.738237] EAX: 00000000 EBX: e13c1780 ECX: 000c0000 EDX: f5656000
[  416.738242] ESI: ded8fec0 EDI: 00000000 EBP: e13c1780 ESP: df371e6c
[  416.738247]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
[  416.738252] Process modprobe (pid: 1402, ti=df370000 task=deaa6280 task.ti=df370000)
[  416.738258] Stack: e13c0920 cb000000 00000000 00000000 e13c1780 e104b006 e13c1780 c013aaa4
[  416.738271]        00002994 ded8fec8 00690674 c16ce100 dea9f000 00000200 00e76000 e13c1780
[  416.738284]        deab07b0 00000000 00000003 00000000 00000000 00000000 00000000 00000000
[  416.738296] Call Trace:
[  416.738302]  [<e104b006>] hdshm_init+0x6/0x5b [hdshm]
[  416.738309]  [<c013aaa4>] sys_init_module+0x187a/0x19ea
[  416.738323]  [<c012d713>] param_get_int+0x0/0x14
[  416.738334]  [<c01042d4>] ia32pv_cstar_target+0x6c/0x8a
[  416.738343]  =======================
[  416.738347] Code: 3c e1 b9 00 00 0c 00 c7 05 08 1d 3c e1 08 1d 3c e1 c7 05 04 1d 3c e1 01 00 00 00 c7 05 00 1d 3c e1 00 00 00 00 89 3d f4 1c 3c e1 <f3> ab a1 f4 1c 3c e1 31 d2 83 c4 10 c7 40 18 00 00 00 00 5f 89
[  416.738406] EIP: [<e13c0059>] hdshm_init_struct_host+0xb8/0xcf [hdshm] SS:ESP 0069:df371e6c
[  416.738419] ---[ end trace 8ab63826bdd21e0d ]---

Alles anzeigen

sk8ter · 12. Februar 2010

Hast du die pciback.hide Kernel Option gesetzt?

livefields · 12. Februar 2010

sk8ter: Ja, klar. Hatte ja bisher schon nen domU-vdr laufen, da wurde ne FF-Karte und ne Budget durchgereicht. Diese zwei Karten hab ich jetzt raus und dafür die eHD rein und ne TT S2-3200 - gleiche Steckplätze, dadurch passt auch das pciback.hide in der Dom0 noch.

Auszug aus lspci -v in der Dom0:

Code

01:07.0 Multimedia controller: Micronas USA, Inc. Device 8100
        Subsystem: Micronas USA, Inc. Device 8100
        Flags: medium devsel, IRQ 17
        Memory at d7fff000 (32-bit, non-prefetchable) [disabled] [size=4K]
        Memory at c8000000 (32-bit, non-prefetchable) [disabled] [size=128M]
        Capabilities: [40] Power Management version 2
        Kernel driver in use: pciback


01:08.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
        Subsystem: Technotrend Systemtechnik GmbH S2-3200
        Flags: medium devsel, IRQ 18
        Memory at d7ffe000 (32-bit, non-prefetchable) [disabled] [size=512]
        Kernel driver in use: pciback

Alles anzeigen

sk8ter · 12. Februar 2010

Dann weiss ich leider nicht weiter, weil keine Kenntnisse der eHD. Ausser vielleicht nochmals überprüfen ob wirklich alle PCI Adressen durchgereicht sind. Mann weiss ja nie.

livefields · 12. Februar 2010

Hm, mir fällt gerade auf, wenn ich die Ausgabe von lscpi -v im Wiki nehme und mit meiner vergleiche, steht bei mir hinter den zwei "Memory"-Zeilen jeweils ein [disabled]?! Das ist bei der beispielhaften Ausgabe im vdr-wiki nicht so:

Code

lspci -v
01:08.0 Multimedia controller: Micronas USA, Inc. Device 8100
   Subsystem: Micronas USA, Inc. Device 8100
   Flags: bus master, medium devsel, latency 32, IRQ 5
   Memory at e7fff000 (32-bit, non-prefetchable) [size=4K]
   Memory at d8000000 (32-bit, non-prefetchable) [size=128M]
   Capabilities: [40] Power Management version 2

Meinst Du, es könnte vielleicht damit was zu tun haben? In meiner Fehlermeldung steht ja auch was von Speicherzugriffsfehler... Muss man den Speicher in der Dom0 separat "reservieren"?

sk8ter · 12. Februar 2010

Ich habe in meiner menu.lst noch die Kerneloptionen "pci=noacpi noirqdebug" drinn, weiss aber nicht mehr warum. Ich haeb schon länger nichts mehr mit VDR auf XEN gemacht. Damals hatte ich zwei DVB-C Karten durchgereicht. Und irgend etwas war glaub mal mit reserved memory irgendwas, daran kannich mich aber auch nicht mehr errinnern.

Hoffe das hilft Dir weiter.

Gruss
Sk8ter

:Edit
Die Memory Sache hatte mit DMA Puffer zu tun. Das ging aber um die DVB Karten. Vielleicht hilft es dir ja trotzdem weiter.

livefields · 12. Februar 2010

Habe eben diesen hochinteressanten Thread gefunden, den ich jetzt mal Stück für Stück durcharbeiten werde. Es scheint ein spezielles Problem der eHD unter XEN in einer DomU zu sein. Ich hoffe ich werde genau so erfolgreich sein wie jimmy.

jimmy · 15. Februar 2010

Ich bin mittlerweile vom Ubuntu (nein danke, nie wieder!) auch auf Debian Lenny mit 2.6.26-2-xen-amd64 (allerdings älteres Xen 3.2-1) umgestiegen.

Der wichtigste Post im genannten Thread ist mein letzter. Der io_remap_pfn_range Bug war einige Wochen/Monate später, als ich nochmal ein Update gemacht habe, nicht im SVN korrigiert worden und ich vermute, er ist es immer noch nicht.

Falls es damit nicht funktionieren sollte, melde dich nochmal.

livefields · 16. Februar 2010

Hey jimmy, erst mal danke, dass Du Dich hier einklinkst

Hab nochmal den Sourcecode angeschaut, den io_remap_pfn_range hatte ich schon nach Deiner Anleitung angepasst. Leider hat dies nichts an meinem Fehler beim Laden des Moduls geändert

War es bei Dir eigentlich so, dass das Modul sich noch per modprobe laden lies und es erst einen Schritt später beim hdboot krachte? Ich bekomme die Fehler nämlich ja bereits nach dem modprobe-Aufruf. Hast Du noch nen anderen Tipp für mich?

Welche Revision der Reelbox-Installs benutzt Du?

livefields · 16. Februar 2010

So, um die XEN-Problematik erst mal außen vor zu lassen, habe ich versucht, die eHD in der Dom0 (also im Prinzip einem Standard Lenny-System) zum spielen zu bekommen. Der TFTP-Server läuft und funktioniert. Als Treiber habe ich wieder Revision 13931 von Reelbox gezogen und folgende Änderungen (der XEN-Kernel 2.6.26-2-xen-amd64 erfordert auch schon die Änderungen die normalerweise erst ab 2.6.27 nötig sind) an der hdshm.c vorgenommen

Code

# diff hdshm.c_original hdshm.c
121c121
<         hd_pci=pci_get_device_reverse(0x1905,0x8100,NULL);
---
>       hd_pci=pci_get_device(0x1905,0x8100,NULL);
128a129
>       pci_enable_device(hd_pci);
648c649
<         remap_pfn_range(vma, vma->vm_start, phys_start>>PAGE_SHIFT, length, vma->vm_page_prot);
---
>         io_remap_pfn_range(vma, vma->vm_start, phys_start>>PAGE_SHIFT, length, vma->vm_page_prot);
704,705c705,706
<       class_device_create(hdshm_class, NULL, MKDEV(HDSHM_MAJOR, 0),
<                           NULL, "hdshm");
---
>       device_create(hdshm_class, NULL, MKDEV(HDSHM_MAJOR, 0),
>                            NULL, "hdshm");
740c741
<       class_device_destroy(hdshm_class, MKDEV(HDSHM_MAJOR, 0));
---
>       device_destroy(hdshm_class, MKDEV(HDSHM_MAJOR, 0));

Alles anzeigen

und anschließend übersetzt. modprobe tun und dann modprobe hdshm schlägt dies mit folgender Meldung in dmesg fehl:

Code

[  750.483955] tun: Universal TUN/TAP device driver, 1.6
[  750.483955] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[  754.574671] ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
[  754.574688] ACPI: PCI Interrupt 0000:01:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17
[  754.575410] hdshm_init_struct: Phys start 00000000cb000000, start ffffc20000680000, nc-start ffffc20000a00000
[  754.858951] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
[  754.859136] IP: [<ffffffff80312d84>] vsnprintf+0x575/0x5b1
[  754.859260] PGD f06ae067 PUD f077f067 PMD 0
[  754.859487] Oops: 0000 [1] SMP
[  754.859655] CPU 0
[  754.859769] Modules linked in: hdshm(+) tun nf_conntrack_ipv4 xt_state nf_conntrack xt_physdev iptable_filter ip_tables x_tables iscsi_trgt
 crc32c libcrc32c lirc_serial lirc_dev nfsd auth_rpcgss exportfs nfs lockd nfs_acl sunrpc bridge xenblktap loop pcspkr k8temp snd_hda_intel sn
d_pcm snd_timer snd soundcore snd_page_alloc wmi button evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid10 raid456 async_xor as
ync_memcpy async_tx xor raid1 raid0 multipath linear md_mod sd_mod ide_cd_mod cdrom ata_generic ahci libata scsi_mod dock 3c59x amd74xx via_rh
ine mii ide_pci_generic ide_core thermal processor fan thermal_sys
[  754.863720] Pid: 4281, comm: modprobe Not tainted 2.6.26-2-xen-amd64 #1
[  754.863720] RIP: e030:[<ffffffff80312d84>]  [<ffffffff80312d84>] vsnprintf+0x575/0x5b1
[  754.863720] RSP: e02b:ffff8800f0745b58  EFLAGS: 00010206
[  754.863720] RAX: 0000000000000000 RBX: ffff8800f0487c00 RCX: ffff8800f0745d18
[  754.863720] RDX: 0000000000000000 RSI: 0000000000000014 RDI: ffff8800f0487d38
[  754.863720] RBP: ffff8800f0745d18 R08: 0000000000000000 R09: ffff8800f0745d18
[  754.863720] R10: ffff8800f0745ba8 R11: ffff8800f053a140 R12: ffff8800f0487d38
[  754.863720] R13: 000000000f600000 R14: 0000000000000000 R15: ffff8800f0487d4c
[  754.863720] FS:  00007f329e9e46e0(0000) GS:ffffffff80539000(0000) knlGS:0000000000000000
[  754.863720] CS:  e033 DS: 0000 ES: 0000
[  754.863720] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  754.863720] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  754.863720] Process modprobe (pid: 4281, threadinfo ffff8800f0744000, task ffff8800f3686b00)
[  754.863720] Stack:  ffff88008167d000 ffffffff8037d30f ffff880000000005 ffffffff80221a4e
[  754.863720]  0000000000000001 0000000000000014 ffff8800f0487d38 0000000000000000
[  754.863720]  0000000000000001 ffff8800f0745bf8 0000000000000001 ffffffff80224d38
[  754.863720] Call Trace:
[  754.863720]  [<ffffffff8037d30f>] ? notify_remote_via_irq+0x26/0x2b
[  754.863720]  [<ffffffff80221a4e>] ? enqueue_task+0x56/0x61
[  754.863720]  [<ffffffff80224d38>] ? try_to_wake_up+0x118/0x129
[  754.863720]  [<ffffffff80221616>] ? __wake_up_common+0x41/0x74
[  754.863720]  [<ffffffff80223904>] ? __wake_up+0x38/0x4f
[  754.863720]  [<ffffffff803dccb9>] ? netlink_broadcast+0x2ce/0x317
[  754.863720]  [<ffffffff803773c8>] ? device_create_vargs+0x92/0xc6
[  754.863720]  [<ffffffff80377440>] ? device_create+0x44/0x4c
[  754.863720]  [<ffffffff8030e9b7>] ? kobject_get+0x12/0x17
[  754.863720]  [<ffffffff803796b4>] ? class_register+0xf0/0x11e
[  754.863720]  [<ffffffff8037972a>] ? class_create+0x48/0x65
[  754.863720]  [<ffffffffa005305a>] ? :hdshm:hdshm_init+0x5a/0x68
[  754.863720]  [<ffffffff8024c5a2>] ? sys_init_module+0x191b/0x1ab1
[  754.863720]  [<ffffffff8023dd49>] ? param_get_int+0x0/0x14
[  754.863720]  [<ffffffff8020b528>] ? system_call+0x68/0x6d
[  754.863720]  [<ffffffff8020b4c0>] ? system_call+0x0/0x6d
[  754.863720]
[  754.863720]
[  754.863720] Code: c6 02 48 63 c2 48 0f 45 d0 45 89 c1 4c 89 fe 45 89 e8 4c 89 e7 44 89 34 24 e8 64 f1 ff ff 49 89 c4 48 ff 44 24 38 48 8b 44 24 38 <8a> 00 84 c0 0f 85 01 fb ff ff 48 83 7c 24 28 00 74 11 4d 39 fc
[  754.867056] RIP  [<ffffffff80312d84>] vsnprintf+0x575/0x5b1
[  754.867056]  RSP <ffff8800f0745b58>
[  754.867056] CR2: 0000000000000000
[  754.871713] ---[ end trace 64232bed856395a4 ]---

Alles anzeigen

Auf der Console bekomme ich den Output:

Code

# modprobe hdshm


Message from syslogd@tambu at Feb 16 23:06:49 ...
 kernel:[  754.859487] Oops: 0000 [1] SMP        


Message from syslogd@tambu at Feb 16 23:06:49 ...
 kernel:[  754.863720] Code: c6 02 48 63 c2 48 0f 45 d0 45 89 c1 4c 89 fe 45 89 e8 4c 89 e7 44 89 34 24 e8 64 f1 ff ff 49 89 c4 48 ff 44 24 38 48 8b 44 24 38 <8a> 00 84 c0 0f 85 01 fb ff ff 48 83 7c 24 28 00 74 11 4d 39 fc                                                              


Message from syslogd@tambu at Feb 16 23:06:49 ...
 kernel:[  754.867056] CR2: 0000000000000000
Getötet

Alles anzeigen

Hat mir jemand nen Tipp, wo hier das Problem liegen könnte? Wie gesagt, es laufen keine virtuellen XEN-Maschinen, die Karte soll testweise erst mal ganz normal unter dem Host-System betrieben werden.

jimmy · 17. Februar 2010

Ich benutze die SVN Version 9302, versuche es mal damit. Ich habe hier auch noch Version 12352, aber irgendwie gab es damit Probleme, kann mich nicht mehr genau erinnern.
Vieleicht wage ich irgendwann nochmal einen Updateversuch, aber momentan fehlt mir leider die Zeit zum Debuggen.

livefields · 21. Februar 2010

Ich geb's auf. Bekomme das Teil einfach nicht zum spielen. Wer die Karte haben will, PN an mich.

Frodo · 22. Februar 2010

Ich hatte bei mir ähnliche Probleme die aber vom BIOS des Mainboardes herrührten (ASUS M3A-HDMI). Die eHD funktionierte bei mir nur mit einem alten BIOS erst ab den 1200er Versioenen gingen auch die neuen.

Die eHD kommuniziert mit ihrem Linux direkt mit dem vom hdshm Module reservierten Speicher und hier scheint dein Problem zu liegen Xen lässt den Zugriff wohl nicht zu bzw kommt mit der Art und weise wie dies umgesetzt wurde nicht zurecht.

Unter OpenSuse oder Ubuntu hatte ich aber bisher fast keine Probleme die eHD zum Laufen zu bewegen, Debian habe ich nicht probiert. Ich habe aber auch nicht herum experimentiert mit Xen oder 64 Bit.

Bei OpenSuse musste ich zwingend den Default Kernel verwenden, sonst gab es auch hier Probleme beim Speicherzugriff.

Probleme mit eHD in einem xen-domU-vdr

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema