config fails: Parallels 2.2 on Fedora 7 with 2.6.22 kernel

Hi Folks,

I see in another forum thread that somebody already mentioned this: Parallels 2.2 doesn't compile under the 2.6.22 kernel. The response that was given was that the users should roll back to the 2.6.21 kernels until an update is available.

To recap:

The recent kernel update for Fedora breaks Parallels 2.2 in line 233 of /usr/lib/parallels/drivers/drv_main/mm/manager.c.

pmm->stat.ownerPid = current->pid;

I've been looking at the code and can't figure out what the programmer was intending in the first place as there is no reference whatsoever to the name current in the file.

It seems to me that you guys must have a bug tracking system somewhere that I can log into, review and make posts to (ie: Bugzilla at Redhat.) I would like to be able to see what has been written about this bug so far. Also, I'd like to hear from the programmer who is responsible for the problem code. The programmer should reply to this issue with a note explaining the meaning of the code. This would allow people like me to come up with a work-around that can be used between now and the day that the update is released.

Please let me know if you have a bug tracking system and how to view issues and post new ones.

Please also ask the programmer who is responsible for this file to explain what the code means and possibly suggest a way to work-around the problem until a patch is available.

Thanks,
Take Care,
Sam.

 

Partial solution

To get the manager.c file to compile, edit the top of the file where it says:

#include <linux/list.h>
#include <linux/mm.h>
#include <asm/semaphore.h>
#include <asm/uaccess.h>

to include sched.h, like this:

#include <linux/list.h>
#include <linux/mm.h>
#include <linux/sched.h>
#include <asm/semaphore.h>
#include <asm/uaccess.h>

This provides the definition that was missing.

(There is now another module that fails to compile...)

HTH,
--Sam.

 

changes to prlnet.c

The problems with this file are all related to some relatively simple changes made to the kernel sk_buff structure. Unfortunately, I am not qualified to make the necessary changes with great confidence - I wonder if everything I did was done properly (and I don't look forward to finding out the hard way that I did something wrong.)

In case it helps, I've pasted the diffs below. Note that the original file is the one downloaded from these forums - not the one that ships with the parallels product rpm.

HTH,
--Sam.

---

[root@dev3 linux]# diff prlnet.c.saved prlnet.c
727,728c727,728
< skb->mac.raw = skb->data;
< skb->nh.raw = skb->data + sizeof(skb->mac);
---
> skb->mac_header = skb->data;
> skb->network_header = skb->data + sizeof(skb->mac_header);
785c785
< eth = (eth_header_t *)skbout->mac.raw;
---
> eth = (eth_header_t *)skbout->mac_header;
894c894
< int len = skb->data - skb->mac.raw + skb->len;
---
> int len = skb->data - skb->mac_header + skb->len;
900c900
< int hoff = sizeof(struct ethhdr) + skb->nh.iph->ihl * 4;
---
> int hoff = sizeof(struct ethhdr) + ((struct iphdr *)skb->network_header)->ihl * 4;
903c903
< skb->mac.raw - skb->data, buf + 2, hoff);
---
> skb->mac_header - skb->data, buf + 2, hoff);
909c909
< skb->mac.raw + hoff - skb->data,
---
> skb->mac_header + hoff - skb->data,
914c914
< skb->mac.raw - skb->data, buf + 2, len);
---
> skb->mac_header - skb->data, buf + 2, len);
929c929
< hw_recv(hw, skb->mac.raw, skb->data - skb->mac.raw + skb->len);
---
> hw_recv(hw, skb->mac_header, skb->data - skb->mac_header + skb->len);

 

Installed and running - but is it safe?

Hello again,

Well, my Parallels installation is now running under the 2.6.22 kernel - but I'm not very comfortable with this situation. Please do point me to a bug tracking system and please ask the programmer responsible for this code to verify the changes that I've made. A code review might show that everything is fine - or it might show that everything looks fine but data corruption is in progress...

Thanks,
Take Care,
Sam.

 

post in wrong place

(I see this post is under MAC instead of Linux - sorry. --Sam. p.s. please move it if possible.)

 

USB Connect fails

(no data loss yet... --Sam.)

 

Hi!
Thank you for your interest in Parallels.
I see you doing well on your own Currently we exploring this issue. We need few days to find and check the solution. Thus probably on Monday I'll publish patch to fix this bug.

 

Yes, you're right in kernel 2.6.22 header file `linux/mm.h' does not include `linux/sched.h'.
For details see commit e8edc6e03a5c8562dc70a6d969f732bdb by Alexey Dobriyan

Thus your fix was correct.

 

Thanks!

Thanks for looking into this.

Please don't forget the prlnet.c file - that one will be more difficult to verify. I'm not sure but I think the USB interface was broken by my changes so there may be some serious problems in there even though it compiles.

Also, please don't forget about access to a bug tracking system - threads such as this belong in a more structured database.

Thanks again,
Take Care,
Sam.

 

Yes, yes. Let me make my tea and i'll get to the meter of business

 

Yep, my cup of tea is full and I'm ready to rock

So, you were pretty right about changes of `prlnet.c'. But lets start with the beginning.
In Linux kernel 2.6.22 new version of structure sk_buff (defined in `linux/skbuff.h') was introduces. Here are two major commits:

• introduce ip_hdr(), remove skb->nh.iph
• unions of just one member don't get anything done, kill them

This changes affected compilation of `prlnet.c'

To make a long story short all you need to do is to substitute following entries:

• skb->mac.raw with skb->mac_header
• skb->nh with skb->network_header

But Linux kernel 2.6.x was created with object oriented approach in mind, hence it's better to use operations (methods) for accessing those attributes (structure entries).
Following is more advanced way of substitution:

• skb->mac.raw must be substitute with skb_mac_header(skb)
• skb->nh must be substitute with skb_network_header(skb)
• skb->mac.raw = skb->data can be substitute with skb_reset_mac_header(skb)
• skb->nh.raw = skb->data + sizeof(skb->mac) can be substitute with skb_set_network_header(skb, sizeof(skb->mac_header))
• skb->nh.iph->ihl * 4 can be substitute with ip_hdrlen(skb)

I've also included some wrappers for compatibility with Linux kernels less than 2.6.22 (see attachment).


md5: fe5e6ef3f40767b441ddfbfdf2b9112f parallels-2.2.2112-linux-2.6.22.patch.zip

 

Thanks again!

Hi aak,

I've installed your patches - thank you! I'm confident now that the installation should be stable.

I now have two remaining problems: (1) USB and (2) PAE / >4gb memory support.

I found a feature for reporting bugs in the HELP menu - but this is not very useful to me - please point me to a bug tracking system.

(Do you actually do what you've been doing here often? Do you use these forums as a kind of bug tracking system?)

The fedora people have released several updates recently. Parallels is no longer crashing when I try to connect a USB device - but it still doesn't work. I've fiddled with /etc/fstab and permissions as per the instructions and also by Brute Force (I set the permissions for each and every device in /dev and /sys to 0777) but continue to get the Can't Connect message.

Any pointers would be much appreciated.

Thanks again for solving the 2.6.22 kernel issues,
All the best,
Take Care,
Sam.

 

Hi, Sam!

Well, actually we need to test it. It think it'll take less than a week.
I'll notify you on test results.

1. We going to investigate USB issues
2. Actually Parallels Workstation 2.2.2112 does not support PAE and +4GB of RAM
But I must reassure you that support of PAE will be added to the upcoming Parallels 4.0

Actually we have no publicly available bug tracking system.
Solutions to common issues can be acquired and published on Parallels Knowledge Base. We think of it like a user friendly bug tracking system.

We'll publish this solution on Parallels Knowledge Base as soon as all test will pass.

I haven't yet explored this issue, but IMHO it has nothing to do with access mode. As you know setting 0777 permissions to all devices will compromise you system, hence I propose you to roll back those changes.
IMHO it has something to do with latest kernel changes. But, as they say, there is only one way to find out

 

SOLUTION: config fails: Parallels 2.2 on Fedora 7 with 2.6.22 kernel

Network tests are ok.

I've been asked to post instructions on how-to apply patch.
Well it's simple as 1-2-3 (and 4):
1. Download archive attached to this post
2. Unzip attachment by running following command in terminal:
$ unzip <path_to_attachment>
3. Gain root access
4. Change directory to /usr/lib/parallels and run patch:
# cd /usr/lib/parallels
# patch -p0 < <path_to_patch>

NOTE: that this patch intended only to be used against Parallels 2.2.2112


This is it!

md5 sum: bfc63190435f053c3c92ee85dc9f1b88 parallels-2.2.2112-linux-2.6.22.patch.zip

 

Hi, Sam!
This solution was published on Parallels Knowledge Base:
Installing Parallels Workstation 2.2 on Linux with 2.6.22 kernel or newer

Thank you for pinpointing this problem and for providing solution!

 

NOT working!

Am I missing something here? Running Fedora 7 64-bit with the latest and greatest updates as of this date. The patch just hangs and waiting. Any suggestions, please?

 

Thanks again, aak!

I've applied to be on your next beta - hope to see you there.

All the best,
Take Care,
Sam.

 

Unfortunately the current version of Parallels Workstation doesn't support 64-bit OSes. This feature is in scope of the future updates.

 

(Please also add PAE support. Thanks, --Sam.)

 

I should learn reading the manual

Thank you for your quick reply.