Jump to content
751 posts in this topic

Recommended Posts

Hi guys

 

After the wake I see this:

Jul 30 12:13:19 Francescos-iMac kernel[0]: System Sleep
Jul 30 12:13:41 Francescos-iMac kernel[0]: Wake reason = PWRB
Jul 30 12:13:41 Francescos-iMac kernel[0]: System Wake
Jul 30 12:13:41 Francescos-iMac kernel[0]: Previous Sleep Cause: 0
Jul 30 12:14:47 Francescos-iMac kernel[0]: AppleIntelE1000e(Err): Hardware Error

 

What's the reason?

The bigger mtu gets, the more memory allocated, and it may cause panic more frequently.

Does the same system work fine with NICs other than 82574 ? I am wondering about the sanity of the system components, as I never had the kind of problem with none of my NICs/systems.

 

 

I tested the jumbo frame between Apple's driver and mine, and I successfully transferred files.

The problem might be 82574 specific. I will read the model specific flow of the source, though I cannot do any testing.

Are there any 82574 users having ( or not having ) the same problem ?

Can the problem be related to other kexts/dsdt or you think it's really card specific?

Do you know any PCI-Express card that works perfect with mtu 9000 and performs the same/better?

Can the problem be related to other kexts/dsdt or you think it's really card specific?

Do you know any PCI-Express card that works perfect with mtu 9000 and performs the same/better?

If you install clean system on another drive ( possibly, USB ) and still have the same problem, it is card specific. If the newly installed system works, there must be something wrong with the current system components.

As you have a working system, installation is easy. Mount Mac OS X DVD ( or image ) and just type:

open open /Volumes/Mac\ OS\ X\ Install\ DVD/System/Installation/Packages/OSInstall.mpkg

then, install boot (assuming you use Chameleon ) and Extra folder. You can select the new drive from current boot menu, or you may want to install stage0/stage1 loaders.

 

Is your card EXPI9301CT? Actually, I am using the same one with no problem.

 

Marvell Yukon 88e8053-based cards work fine with Apple's driver and support mtu=9000.

Intel EXPI9400PT also works with my driver.

As I have never compared throughput of the cards, i cannot tell performance.

If you install clean system on another drive ( possibly, USB ) and still have the same problem, it is card specific. If the newly installed system works, there must be something wrong with the current system components.

As you have a working system, installation is easy. Mount Mac OS X DVD ( or image ) and just type:

open open /Volumes/Mac\ OS\ X\ Install\ DVD/System/Installation/Packages/OSInstall.mpkg

then, install boot (assuming you use Chameleon ) and Extra folder. You can select the new drive from current boot menu, or you may want to install stage0/stage1 loaders.

 

Is your card EXPI9301CT? Actually, I am using the same one with no problem.

 

Marvell Yukon 88e8053-based cards work fine with Apple's driver and support mtu=9000.

Intel EXPI9400PT also works with my driver.

As I have never compared throughput of the cards, i cannot tell performance.

Thanks, yes it's EXPI9301CT and I actually have also EXPI9400PT but I'm using it in my nas currently.

I think I'll be installing Lion in a week or so. Do you know if the card works with it?

Thanks, yes it's EXPI9301CT and I actually have also EXPI9400PT but I'm using it in my nas currently.

I think I'll be installing Lion in a week or so. Do you know if the card works with it?

It works with Lion - I am using it every day.

About upgrade from Snow to Lion, I recommend migrating account data only after clean installation. I had problems when I tried to migrate system files. I followed the guide for creating USB installation stick, though I used a hard drive partition.

It works with Lion - I am using it every day.

About upgrade from Snow to Lion, I recommend migrating account data only after clean installation. I had problems when I tried to migrate system files. I followed the guide for creating USB installation stick, though I used a hard drive partition.

 

Can I install from my current Snow Leopard installation to a new hard disk, then install chameleon? I have done that to install SL.

I'm planning to buy a SSD so that's the right time I guess to move to Lion and clean installation.

Can I install from my current Snow Leopard installation to a new hard disk, then install chameleon? I have done that to install SL.

I'm planning to buy a SSD so that's the right time I guess to move to Lion and clean installation.

I created a new partition (10 gb), then followed USB stick installation guide of the "OSx86 Installation > OSx86 10.7 (Lion)" forum to copy the Lion install dmg and extra files onto it. Basically:

. recover image using Disk Utility

. copy packages folder

. copy Lion mach_kernel ( found in the topic )

. copy boot and /Extra as required to your hardware.

 

After that, Chameleon ( I use Chimera 1.4.1 ) boot menu should show the installation partition. At this point, you can boot into the Lion installer and install a clean Lion system onto a new drive. You still need to manually install boot-related files there before you can boot Lion.

  • 3 weeks later...

Actually, I'm having some trouble getting the Intel 82574 (0x10d3) to work under Lion. I've been trying the 1.3.17 version of the kext from this thread, which I've placed in /System/Library/Extensions. I verified the driver is loaded by doing a 'kextstat | grep IntelE', which shows the 1.3.17 version loaded, and it seems as though I'm looking at the correct card because en0 goes away in ifconfig when I physically remove the Ethernet card from the system. The card shows up correctly in the network preferences pane and in ifconfig, but it seems unable to pass any traffic.

 

(No DHCP, no response to pings after manual IP config, arp -a is empty, tcpdump -n arp on another host shows no Ethernet frames are actually being sent.). Attempts to set ethernet hardware settings manually (i.e., 1000Mbps, fdx, 1500mtu, several others) appear ineffective as well. The LEDs on the back of the card, however, consistently show a good connection.

 

Curiously, the driver will generate an entry detecting the cable is plugged in, with the correct 1000/fdx, but does not generate an entry when the cable is removed. ifconfig still shows it as active.

 

I have the exact same card working fine in a Snow Leopard install, using driver version 1.2.10. Using that version on this (fresh) Lion install gives no success either. I am using x86_64, but it appears to have the same problem in i386 mode as well.

 

I'm unsure of where to go from here, or how to troubleshoot further. Any advice?

 

Update: I built a debug version of the driver from the latest SVN sources, using XCode 4.1, a Macbook Pro with Lion, and changing the target to 10.7. No effect. The debug messages are here: http://pastebin.com/YUnBug8a

What does "Network Utility" say about sent/received/error packets ?

 

Sent Packets: 0

Send Errors: 0

Recv Packets: 0

Recv Errors: 0

Collisions: 0

 

Also, I should mention that I am running a dual-cpu board, the EVGA Classified SR-2. However, the other machine on which we're using this card/driver successfully on Snow Leopard is also a dual-socket (SuperMicro X8DAH) board, and I have already (unsuccessfully) tried various BIOS options such as disabling NUMA or VT-d support.

Sent Packets: 0

Send Errors: 0

Recv Packets: 0

Recv Errors: 0

Collisions: 0

 

Also, I should mention that I am running a dual-cpu board, the EVGA Classified SR-2. However, the other machine on which we're using this card/driver successfully on Snow Leopard is also a dual-socket (SuperMicro X8DAH) board, and I have already (unsuccessfully) tried various BIOS options such as disabling NUMA or VT-d support.

 

OMG weird! So... it's working now. Sorta.

 

I've been installing a few other things- audio drivers and a few kexts from [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url]. But apparently what makes the difference is waking from sleep. I was rather shocked when the adapter picked up an address from DHCP, and the network looked to be working correctly. Upon reboot, however, I had a CMOS corruption message (I thought I installed a kext from [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] which was supposed to prevent that...), so I reset the standard things (enabled HPET, AHCI for SATA, etc...) and booted back into OSX.

 

Where the network went back to its previous non-working state. Until I forced the machine to sleep, and then woke it up. Now I'm posting this message from it. WEIRD. So, I'm taking a wild guess that it has something to do with init routines, or lack thereof, which are different coming out of sleep.

 

So... I don't think I would call it "fixed," but at least I have a workaround for now that doesn't involve a Bluetooth PAN. :)

System invokes "disable" upon sleep and "enable" upon wakeup.

As far as I remember , I put off hardware initialization as much as possible later than "enable" to make sleep work, so that wakeup sequence becomes simliar to initialization.

If you take a look at the code of init/startup ( they are the only significant entries called before enable ), you will find they do very little things about actual hardware initialization.

I suspect it has something to do with the warming-up time of the hardware.

 

What happens if doing kextunload/kextload instead of sleep/wakeup ?

System invokes "disable" upon sleep and "enable" upon wakeup.

As far as I remember , I put off hardware initialization as much as possible later than "enable" to make sleep work, so that wakeup sequence becomes simliar to initialization.

If you take a look at the code of init/startup ( they are the only significant entries called before enable ), you will find they do very little things about actual hardware initialization.

I suspect it has something to do with the warming-up time of the hardware.

 

What happens if doing kextunload/kextload instead of sleep/wakeup ?

 

It has no effect on the problem, but then a subsequent sleep/wake cycle failed to correct the problem as before. However, the sleep/wake trick was again effective after a reboot.

It has no effect on the problem, but then a subsequent sleep/wake cycle failed to correct the problem as before. However, the sleep/wake trick was again effective after a reboot.

I am quite sure that disable/enable are the only entries invoked during sleep/wakeup, at least as the time of porting.

Disable/Enable in System Preference > Network may have the same effect as sleep/wakeup. If it does not work, it can be related to internal hardware status that changes during power off.

 

As I cannot reproduce the problem in any of my machines, it is almost impossible to fix it on my side.

OSX driver is a port of Linux driver and simplified in some parts, such as WOL and ASPM which I ignored.

If you have programming experience, compare netdev.c ( included in the project for reference only ) and AppleIntelE1000e.cpp which should have basically the same logic and build your own driver. Other files are exactly the same as Linux, except e1000.c, which I needed to separate from the main file to include constructs not supported by cpp.

I am quite sure that disable/enable are the only entries invoked during sleep/wakeup, at least as the time of porting.

Disable/Enable in System Preference > Network may have the same effect as sleep/wakeup. If it does not work, it can be related to internal hardware status that changes during power off.

 

As I cannot reproduce the problem in any of my machines, it is almost impossible to fix it on my side.

OSX driver is a port of Linux driver and simplified in some parts, such as WOL and ASPM which I ignored.

If you have programming experience, compare netdev.c ( included in the project for reference only ) and AppleIntelE1000e.cpp which should have basically the same logic and build your own driver. Other files are exactly the same as Linux, except e1000.c, which I needed to separate from the main file to include constructs not supported by cpp.

 

I spent quite a bit of time messing around with the driver this evening, but no joy. ;) In addition to enable, wakeup invokes setPowerState(1), though it doesn't look like that function touches the hardware, and setMulticastMode(1), which is called three times (w/ args 1, 0, 1). I also tried commenting out some of the things in setup() that would touch hardware, e.g., resets. Sadly, none of these had any effect.

 

Anyway, I'll probably just get a different card and see if I get luckier there. :censored2: Thanks for your help though!

Have you tried 1.3.10 ?

 

No, I don't think so... I tried a version from the current [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] (v?), an older version from another (known working under Snow Leopard) machine, and the latest SVN head. I'll give 1.3.10 a go sometime tomorrow though and let me know what I find. I assume I should just use the 1.3.10a2 link at the top of this thread? Or, if there's a source version somewhere I could enable debug support and get a few traces if that's more valuable than a yes/no.

No, I don't think so... I tried a version from the current [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] (v?), an older version from another (known working under Snow Leopard) machine, and the latest SVN head. I'll give 1.3.10 a go sometime tomorrow though and let me know what I find. I assume I should just use the 1.3.10a2 link at the top of this thread? Or, if there's a source version somewhere I could enable debug support and get a few traces if that's more valuable than a yes/no.

Yes, the binary is downloadable from the link. If you need the source, you will have to use subversion to extract r19.

If 1.3.10 works, I will investigate the timing issues.

Yes, the binary is downloadable from the link. If you need the source, you will have to use subversion to extract r19.

If 1.3.10 works, I will investigate the timing issues.

 

I built and tested SVN r19 last night. Unfortunately, at least for those with my specific likely hardware-related issues, it did not behave differently. It still did not receive DHCP or any packets upon first boot, but began working properly after resuming from sleep. In related news, I now have a new $18 Marvell based card, and a spare Intel card for a different machine. ;)

 

On the bright side, hopefully this means that any recent changes in the driver only solved old problems and did not create new ones.

 

Even if it didn't work out for me, I (and I'm sure many others) appreciate your port as well as your engagement on the forums. Thanks!

About my kernel panic, that was a weird issue if you recall. Anyway could it be a conflict with USB?

I actually tried to remove my usb keyboard when booting at it was booting fine! When it was connected instead I had the panic again at first boot.

Now I moved it on another port and no panics so far

About my kernel panic, that was a weird issue if you recall. Anyway could it be a conflict with USB?

I actually tried to remove my usb keyboard when booting at it was booting fine! When it was connected instead I had the panic again at first boot.

Now I moved it on another port and no panics so far

IRQ conflict ? Though I doubt changing USB port causes IRQ assignment to USB.

An IOKit driver doesn't request explicit IRQ mapping but lets the system do it.

 

It's good that your problems has been solved, anyway.

Is anyone able to get the Intel 82579V (VEN: 8086 DEV: 1503) working under Lion?

 

I get no IP through DHCP but the LEDs are active at the Laptop (HP ProBook 6460b).

 

Thanks Stephan

It is used in my system (dh67cf) and working.

×
×
  • Create New...