Jump to content
3,411 posts in this topic

Recommended Posts

For everyone asking when will the 4965agn work, and why doesn't the 4965 driver work, and where's the leopard version of the 4965 driver, and why isn't this done already, I'm impatient and demand someone else fix my problems -- you will all have to wait patiently, there has been no progress on the 4965 driver. the 4965 driver as it stands, does not work, it only fools tiger into recognizing you have an airport card, and does not provide wireless functionality.

 

Coding drivers is hard f**ing work, very time consuming, and with little reward. No one is paying these people to write these drivers, they're sacrificing countless hours of their spare time to fixing *other people's problems*.

 

Note that these developers don't even own all these cards, they're doing this solely to help the community.

 

Please stop pestering the developers, if there has been any progress, it will have been posted in this thread. Before posting, please read every single post in this thread.

 

PS: jalavoui, if you have a free mini-pcie slot, I'd be willing to loan you my 4965agn indefinitely, as it's plainly of no use to me right now. PM me with your mailing address.

 

here here!

 

guys, i got nothing for respect for you for doing this

 

and if your english aint that great, that isn't something to appologize for. if we are intellegent and patient enough to sort through all of this and try to install OSX on a PC, then we should be intellegent and patient enough to sort through english that is missing a few proper nouns, lol.

Hi,

 

News:

_The new driver is on the road ... :wacko:

 

To have day per day news ,you can take a look to the iwiDarwin's svn :)

 

Bye

Hmm, does this refer to any driver specifically (such as 3945 :unsure: )? And by "on the road" how far along do you mean?

Mmmmmm... I'm looking at my cristal ball ...

 

Between 2 weeks and 10 years :/

 

I'm kidding ;p , I really don't know . I hope quickly.

 

For the former question , I've got only a 3945 but when this translator will be done, the 4965 will can be ported very quickly.

Jalavoui, can you send me the tool that you are using do develop the driver. My laptop have iwi3945, and I would like to help you.

 

Pls send me a zip with the tool and the project iwi3945abg

 

thanx

the FreeBSD drivers code can help iwi drivers

i've checked it in the past for iwi2200 but didn't find usefull stuf in it

i think we can use portions of it in iwi3945

but the linux port will be more stable

 

I am hoping that the FreeBSD code can help more... afterall, MacOSX has portions based on BSD.

I will pray for your success.

 

Cheers to the team!

It's a problem with the DMG , maybe you should take the zip I posted 2 or 3 days ago ..

 

Can you confirm which files on the google code site are not currently working?

 

Also, is it a requirement have the MAC address defined in Info.plist?

 

Can't glean this information from the forum as it stands currently.

Can you confirm which files on the google code site are not currently working?

 

Also, is it a requirement have the MAC address defined in Info.plist?

 

Can't glean this information from the forum as it stands currently.

 

Actually you can ignore that if you wish, I've tried with the last 5 revisions, the SVN Trunk binary, and compiling from latest source; none work.

 

I have the following card:

 

Intel 2915ABG rev 05

DEV_ID: 8086:4224

 

Running this machine (T43P thinkpad):

root# uname -a

Darwin victor-laptop 8.8.1 Darwin Kernel Version 8.8.1: Sat Dec 9 22:18:27 AZOT 2006; semthex:/nebukadnezar/BUILD/obj/RELEASE_I386 i386 i386

 

Problem: Kext is not automatically loading, and when manually loaded no change to dmesg output, no new adaptor. I've attached the full dmesg output as grep returns nothing in the getlogs.command script.

 

Symptoms: When manually loaded with

root# kextload -t /System/Library/Extensions/iwi2200.kext

kextload: extension /System/Library/Extensions/iwi2200.kext appears to be valid

kextload: extension /System/Library/Extensions/iwi2200.kext is already loaded

When I run networkSelector:

 

root# ./networkSelector

Could not get ID for kernel control. 2

 

When I boot in single user mode I see this line in screen output:

localhost configd[55]: No Airport Driver found

 

I have checked permissions, removed Extensions.* and manually checked timestamps to make sure I wasn't somehow overwriting my iwi2200.kext with some other cached version.

 

Any ideas what is happening here?

 

Is there anything in iwi2200.kext/Contents/Info.plist which would cause the kext to fail to attach to the hardware?

 

I can try out any patches you want.

 

Thanks for the work on the driver port.

dmesg.txt

ioreg.txt

system.txt

kextstat.txt

Hoping for 3945 support soon! :)

 

Me too!!!!! (and I guess a buch of other guys!)

 

I've not been on these forums long, and this may seem a little blunt, but posts like this are a complete waste of everyone's time. When you're trying to find information within 200 pages worth of posts, every little post that basically says "great!", "when?", or "now!" is like a little stab wound in the neck.

 

This has all been said before, there's posts stickied all over the shop telling you not to do it, and yet it continues... :unsure:

Hello,

 

No, the developement isn't stopped.

The new version is for the moment at the same point as the old version.

 

If you want to test this version , you can download it herre:

 

http://zetasam.ath.cx/iwi3945_19_02_2008.zip

 

the code is too crapy to commit it in the svn .

 

If you have time , you can take a look to the code and say me what is wrong :)

 

Bye.

 

[EDIT]: I posted the log for developers

LOG.rtf

hey everyone, I just tried to download the current svn from the iwidarwin website and the link in:

 

PROSet/Wireless 3945a/b/g OS X 10.5 IO80211Controller SVN latest

 

does not seem to be working.

 

I think having the device show up as an air port card is the way to go then the native applewirelless items can take over.

 

I will be trying the last download from the post above later tonighth. I have a Lenovo r61 with the 3945 card in it. I will report then.

@Zubi: We know it doesn't work. There are some very talented developers working on the driver at the moment. Read the whole topic before posting!

man, thanks for the driver my wifi 2200 now works!!! I just noticed when i check my desktop with iatkos installed, the airport is installed even though there are no wifi card installed but of course the system knows that there are no available wifi card. Is it possible to copy the files from iatkos and embed it with kalyway for example to show the airport instead of ethernet 2?

Just a quick update: TNW has gotten it so it gets to the point of card initialization. Currently, the card starts responding alright, but once it gets to a certain point (sending POWER_TABLE_CMD in iwl3945_send_power_mode()) the card starts responding with errors. He suspects that it's because the mbufs are getting corrupted due to the fact that mutexes and spinlocks aren't enabled, which I could see.

 

Unfortunately, enabling mutexes causes strange and interesting behavior. More unfortunately I can't determine the exact cause of the error, but I suspect it's either the call to alloc_skb() or pci_map_single() in iwl3945_rx_allocate(). I can't figure out where the error is because:

 

1) I have no wired NIC, so I can't use GDB over the network.

2) I have no serial port, so I can't use DDB.

3) The stack is deeper than DUMPFRAMES, so the darwin_iwi3945 code is lost behind a "Backtrace continues..." message.

 

I've been reading the backtraces to determine where errors are, so I'm not against using the third method. But compiling the kernel is really annoying, especially in an environment with no network access. Is there anyone here who can compile a new kernel and set DUMPFRAMES in osfmk/i386/AT386/model_dep.c:937 to something higher? Like, say, 64?

Just a quick update: TNW has gotten it so it gets to the point of card initialization. Currently, the card starts responding alright, but once it gets to a certain point (sending POWER_TABLE_CMD in iwl3945_send_power_mode()) the card starts responding with errors. He suspects that it's because the mbufs are getting corrupted due to the fact that mutexes and spinlocks aren't enabled, which I could see.

 

Unfortunately, enabling mutexes causes strange and interesting behavior. More unfortunately I can't determine the exact cause of the error, but I suspect it's either the call to alloc_skb() or pci_map_single() in iwl3945_rx_allocate(). I can't figure out where the error is because:

 

1) I have no wired NIC, so I can't use GDB over the network.

2) I have no serial port, so I can't use DDB.

3) The stack is deeper than DUMPFRAMES, so the darwin_iwi3945 code is lost behind a "Backtrace continues..." message.

 

I've been reading the backtraces to determine where errors are, so I'm not against using the third method. But compiling the kernel is really annoying, especially in an environment with no network access. Is there anyone here who can compile a new kernel and set DUMPFRAMES in osfmk/i386/AT386/model_dep.c:937 to something higher? Like, say, 64?

 

hello Symuc,

 

i do not have experience in all this but i have the time and the system you need ... i have Xcode3 ... Leopard 10.5.2 ... A machine withe the integrated 3945 ... and the time to make the tests. What should be the next step? should we try remotely?

 

Cheers

boys,

 

not sure if it'd help .... but it seems I can load the driver a bit further then in the latest TNW's log.

 

please have a look at my log, maybe it will give you some ideas.

 

The sequence is of the following:

 

1. latest TNW's source code (ie http://zetasam.ath.cx/iwi3945_19_02_2008.zip)

 

1a changed spin_lock to spin_lock_saveirq in iwi3945_isr ( don't think it helped since #define for spin_lock_saveirq just calling spin_lock as I found later)

 

2. did load.command (pc crashed - KP)

 

3. rebooted pc (crashed again )

 

4. rebootede pc, did not crash, however produces the same log as in TNW's LOG.rtf (e.i. MAC = 0:0:0:0)

 

5. if I kextload at this stage, it goes much further, printing the right MAC in the log.

 

It looks like after this "second" load I can load & unload driver as much as I pleased, no KP.

 

and I can see correct wireless MAC in the log.

log.txt

Hello baikai,

 

Maybe you should play with the lastest version .

You must disable spinlock for the moment or replace them with mutex due to this problem.

 

This link explains the problem :

http://lists.apple.com/archives/Darwin-ker...n/msg00046.html

 

We have another problem , we need to disable processor's intterupts to make sur that the current thread isn't switched by the kernel's scheduler.

 

But since OS-X we can't do that , maybe can we set an high priority on the current thread?

 

If someone have an idea , that would be great !

 

Bye

Guest
This topic is now closed to further replies.
×
×
  • Create New...