Intel Wireless 2100, 2200bg, 2915bg, 3945abg, 4965agn

[jalavoui]

manual load with kextload -> this way you get driver starttup lines

what's wrong with your guys today? forgot how to post logs?

 

i have no idea why iwi3945 hangs there

[Ruud]

oke logs after manualy kextload of iwi 4965 rel 831

 

 

are these logs better?

dmesg.txt

system.txt

[austinsnyc]

here are my logs yesterday i got a complete scan and posted everything and the MODS deleted it nice right!! i am not getting scans with this build here are my logs

Yesterday_logs_complete_scan.rtf

Logs.rtf

log.rtf

[drago1]

jalavoui

wher to get the last svn ? whet is the address

[kazzi]

Here's 3945, rev 831 manually load (I previously thought it didn't help, sorry)

 

system.txt

[austinsnyc]

jalavoui

wher to get the last svn ? whet is the address

 

 

read up like 4 posts and you will see!!!!

 

my new logs from the latest build no scanning like yesterday

logs.rtf

[pa28cr]

Could someone post iwi3945 rev 831 kext??

[mlazy]

830=immediate KP. I don't get logs:

 

Apr 25 11:36:53 Sony sudo[540]: super : TTY=ttys000 ; PWD=/Users/super/Desktop/iwi3945/830/build/Debug ; USER=root ; COMMAND=/sbin/kextload -t iwi3945.kext

 

On screen it shows iwi3945 Enable() as the last line, just after the kextload.

 

to others: when it panics like this toy need to open a terminal window before the kextload, and then tail -f your system.log to see what's happening. The panic happens before the log can be written sometimes.

 

My workflow:

 

1. boot with -x

2. open a terminal window (#1). cd to the kext.

3. open another terminal window. (#2) type "cd /var/log" hit enter, then type "tail -f system.log"

4. click on terminal #1. type "sudo kextload -t iwi3945.kext"

5. watch terminal #2 for ouptput.

6. if you can, take a pic, or write down what terminal #2 says behind the kp icon.

[Doctadre]

I get quite a few errors in this new 831 build for 3945. Attached is the 3945.dmg for those looking for the latest kext. and my sys log

systemlog831.txt

iwi3945.dmg

[jalavoui]

both cards as problems finish the ucode starttup sequence

search for this line in xcode:

ret = UCODE_READY_TIMEOUT*100;

and try other delay values - default value is ret = UCODE_READY_TIMEOUT;

this is very easy to test - report if you make it run without errors

use kextload to see inital drive log lines - this will show the errors

 

there are other ways to hack this: try

IOSleep(x); //replace x for 500, 1000 (=1second) 2000, etc

ret = UCODE_READY_TIMEOUT;

 

this is the main reason for the drivers fail to work - if it fails here everithing else don't work

 

iwi3945 rel 832

iwi4965 rel 833

test this releases first before hacking the code

happy hacking

 

if you search for this:

static int iwl3945_param_debug = 0xffffffff

this var controls the debug messages you get -> change it and you'll get less/more debug output

this can help filter messages to see if the hack works

[kazzi]

Log with 3945, rev 833, manual kext load

 

system.txt

[Ruud]

oke i got kp after manual kextload rel 833, using a tail, il up a pic in 15 minutes, have to eat first...

 

oke cans up the pic: this is the last line before kp

 

iwl4965: U iwl4965_rx_scan_start_notif Scan start: 120 [802.11a] (TSF: 0X00000000:0015D8C4) - (beacon timer 54527804)

 

before thate ar blocks of the same log lines with ending with the above line, looks like a loop

[jalavoui]

stop posting logs

i can't fix this without the card

go back read what is need to do and report a solution if you find it

this is for iwi3945 and iwi4965

[deek]

Hey all,

 

Well I got my HackinTablet back to a working state. Most of the fixes I have done (audio, tablet stuff, etc.) have been well documented. Can anyone of the more senior posters show me their testing work flow, including how to get the test versions, so I can help give feedback and get a better idea of whats going on? If not I can go digging again and see if anything comes up this time around.

 

My card is the iwi3945

[revolt_team]

both cards as problems finish the ucode starttup sequence

search for this line in xcode:

ret = UCODE_READY_TIMEOUT*100;

and try other delay values - default value is ret = UCODE_READY_TIMEOUT;

this is very easy to test - report if you make it run without errors

use kextload to see inital drive log lines - this will show the errors

 

there are other ways to hack this: try

IOSleep(x); //replace x for 500, 1000 (=1second) 2000, etc

ret = UCODE_READY_TIMEOUT;

 

this is the main reason for the drivers fail to work - if it fails here everithing else don't work

 

iwi3945 rel 832

iwi4965 rel 833

test this releases first before hacking the code

happy hacking

 

if you search for this:

static int iwl3945_param_debug = 0xffffffff

this var controls the debug messages you get -> change it and you'll get less/more debug output

this can help filter messages to see if the hack works

 

 

i cant find that line jalavo ... where is it ? which file or in what function i need to try these values ... i'll test

[rulli]

Found it! It's in iwl4965-base.c

I'll search a stable value

[Ruud]

oke i got kp after manual kextload rel 833, using a tail, il up a pic in 15 minutes, have to eat first...

 

oke cans up the pic: this is the last line before kp

 

iwl4965: U iwl4965_rx_scan_start_notif Scan start: 120 [802.11a] (TSF: 0X00000000:0015D8C4) - (beacon timer 54527804)

 

before thate ar blocks of the same log lines with ending with the above line, looks like a loop

 

 

oke it doesnt matter what value i use, i keep having a kp, so i cant help.

[jalavoui]

search for this

local->ops->hw_scan(local_to_hw(local),(u8*)"<hidden>", sizeof("<hidden>"));

and put

//local->ops->hw_scan(local_to_hw(local),(u8*)"<hidden>", sizeof("<hidden>"));

this is the kp

there's no point in startting a scan if the driver is unstable

 

Ruud,

you probably have found a good value already

 

Cxddev,

can you help? both drivers as this bug

[Ruud]

search for this

local->ops->hw_scan(local_to_hw(local),(u8*)"<hidden>", sizeof("<hidden>"));

and put

//local->ops->hw_scan(local_to_hw(local),(u8*)"<hidden>", sizeof("<hidden>"));

this is the kp

there's no point in startting a scan if the driver is unstable

 

Ruud,

you probably have found a good value already

 

Cxddev,

can you help? both drivers as this bug

 

 

ok thanks, no kps now, but i don't get errors in the log, ill look into the scan function. To bad i always hated pointers etc.

[jalavoui]

i have a nice hack to test

i'll upload to svn

wait...

 

iwi3945 rel 834

iwi4965 rel 835

 

maybe a very nice hack

[Ruud]

i have a nice hack to test

i'll upload to svn

wait...

 

iwi3945 rel 834

iwi4965 rel 835

 

maybe a very nice hack

 

 

this is my tail log for 835

system.txt

[pmorcos]

I'm sure you're probably still in the process of uploading this but I noticed that the svn latest available for download from iwidarin is iwi3945r748. Is there a better place to get the latest or are you simply using a different revision terminology for the installs?

Anyway, your efforts will be rewarded by me for sure and I'm sure many others!

 

i have a nice hack to test

i'll upload to svn

wait...

 

iwi3945 rel 834

iwi4965 rel 835

 

maybe a very nice hack

[jalavoui]

Ruud,

this log misses first load lines

but

i found a easy to fix bug

 

i'll upload a new version to svn

 

ok - lol version

 

iwi3945 rel 836

iwi4965 rel 837

 

try to get initial driver log lines (use kextload). i think sometimes the driver wants to work so fast that it loses the first lines - maybe in console -> system.log?

 

when i post a release here it's available in the svn tree - read some posts back to learn howto get it

[Ruud]

Ruud,

this log misses first load lines

but

i found a easy to fix bug

 

i'll upload a new version to svn

 

 

well in one console im doing tail -f systemlog and in an other console kextload iwi4965.kext so what should i do to get those lines? i thought they should be in there when doing it this way.

[Raman148]

can someone tell me where can i get the latest svn for 4965?

 

i think i can help you guys out.