[GIOCO] World Of Warcraft su WINE & ATI

[twister]

Io sono su Hakkar lato ally.
Il main si chiama Frada, l'alt Twistr (maledetti avevano già preso il mio nick )

[DanBadJar]

Testato con kernel 2.6.34.1 e wine 1.1.44 e 1.2.
Ho provato anche a usare il d3d e a cancellare la directory WFT.
Ancora niente da fare

[Ansa89]

Probabilmente dico un'ovvietà, ma hai patchato il kernel con la patch di appdb?

[DanBadJar]

Cavolo no!
Ma la patch non è per il 2.6.33? Mi piacerebbe sapere se quelli che usano il 2.6.34.1 l'hanno patchato, così provvedo!

[Ansa89]

Ma la patch non è per il 2.6.33?

Non lo so, io non uso WoW.
Comunque per provare puoi prendere l'ultimo kernel vanilla, applicare la patch e guardare gli eventuali hunk che falliscono.

EDIT: l'ho fatto io:
- patch presa da qui:

Codice: Seleziona tutto

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 142d70c..725ef4d 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -526,6 +526,7 @@ asmlinkage __kprobes struct pt_regs *sync_regs(struct pt_regs *eregs)
 dotraplinkage void __kprobes do_debug(struct pt_regs *regs, long error_code)
 {
 	struct task_struct *tsk = current;
+	int user_icebp = 0;
 	unsigned long dr6;
 	int si_code;
 
@@ -534,6 +535,14 @@ dotraplinkage void __kprobes do_debug(struct pt_regs *regs, long error_code)
 	/* Filter out all the reserved bits which are preset to 1 */
 	dr6 &= ~DR6_RESERVED;
 
+	/*
+	 * If dr6 has no reason to give us about the origin of this trap,
+	 * then it's very likely the result of an icebp/int01 trap.
+	 * User wants a sigtrap for that.
+	 */
+	if (!dr6 && user_mode(regs))
+		user_icebp = 1;
+
 	/* Catch kmemcheck conditions first of all! */
 	if ((dr6 & DR_STEP) && kmemcheck_trap(regs))
 		return;
@@ -575,7 +584,7 @@ dotraplinkage void __kprobes do_debug(struct pt_regs *regs, long error_code)
 		regs->flags &= ~X86_EFLAGS_TF;
 	}
 	si_code = get_si_code(tsk->thread.debugreg6);
-	if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS))
+	if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS) || user_icebp)
 		send_sigtrap(tsk, regs, error_code, si_code);
 	preempt_conditional_cli(regs);

- Kernel 2.6.34.1 vanilla (senza patch Con Kolivas)
- Risultato: due hunk risolti con successo, quindi la patch è utilizzabile:

Codice: Seleziona tutto

#patch -p1 -i ../patch-wow3.3.5
patching file arch/x86/kernel/traps.c
Hunk #1 succeeded at 529 (offset 3 lines).
Hunk #3 succeeded at 587 (offset 3 lines).

EDIT2: ho corretto la patch per il 2.6.34.1:

Codice: Seleziona tutto

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 142d70c..725ef4d 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -529,6 +529,7 @@ asmlinkage __kprobes struct pt_regs *sync_regs(struct pt_regs *eregs)
 dotraplinkage void __kprobes do_debug(struct pt_regs *regs, long error_code)
 {
        struct task_struct *tsk = current;
+       int user_icebp = 0;
        unsigned long dr6;
        int si_code;
 
@@ -537,6 +538,14 @@ dotraplinkage void __kprobes do_debug(struct pt_regs *regs, long error_code)
        /* Filter out all the reserved bits which are preset to 1 */
        dr6 &= ~DR6_RESERVED;
 
+       /*
+        * If dr6 has no reason to give us about the origin of this trap,
+        * then it's very likely the result of an icebp/int01 trap.
+        * User wants a sigtrap for that.
+        */
+       if (!dr6 && user_mode(regs))
+               user_icebp = 1;
+
        /* Catch kmemcheck conditions first of all! */
        if ((dr6 & DR_STEP) && kmemcheck_trap(regs))
                return;
@@ -578,7 +587,7 @@ dotraplinkage void __kprobes do_debug(struct pt_regs *regs, long error_code)
                regs->flags &= ~X86_EFLAGS_TF;
        }
        si_code = get_si_code(tsk->thread.debugreg6);
-       if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS))
+       if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS) || user_icebp)
                send_sigtrap(tsk, regs, error_code, si_code);
        preempt_conditional_cli(regs);

[NikyBiasion]

Mai patchato il kernel per dover far funzionare WoW... neanche con il 2.6.33.
Riesci a postare l'output di wine quando crasha?

Lo schedtool serve se hai la patch dello scheduler di kolivas, se fai una veloce ricerca su google trovi sicuramente una spiegazione del funzionamento e in che situazioni deve essere usato.

[Ansa89]

Ho fatto altri test, concludendo che la patch per WoW 3.3.5 può essere usata insieme alla patch di Con Kolivas:

Codice: Seleziona tutto

#patch -p1 -i ../patch-2.6.34-ck1
...
#patch -p1 -i ../patch-wow3.3.5
patching file arch/x86/kernel/traps.c

Piccola curiosità: la patch di cui stiamo parlando non è per WoW, ma per wine (o meglio: le applicazioni Windows lanciate con wine), quindi mi chiedo se l'amico Torvalds non abbia provveduto a correggere questa regressione del codice (magari nel 2.6.35) .
Capisco che a quelli del team di sviluppo del kernel non interessi molto la compatibilità con wine e le applicazioni di Windows, però mi chiedo come mai abbiano tolto l'invio della sigtrap da parte dell'istruzione icebp.

Inoltre la patch che corregge l'errore è parecchio diversa dalla patch proposta inizialmente. Sono un po' confuso .

[Ansa89]

Lo schedtool serve se hai la patch dello scheduler di kolivas, se fai una veloce ricerca su google trovi sicuramente una spiegazione del funzionamento e in che situazioni deve essere usato.

Nessuno ha parlato di schedtool (credo) .

[DanBadJar]

Allora aspetto il nuovo kernel, oppure appena torno dalle vacanze vedrò di patcharlo, ma da quanto mi dite non ce n'è stato bisogno!
Vi aggiornerò! Grazie per ora!

[DanBadJar]

Linux 2.6.34.2
Wine 1.2

E finalmente funziona!