Searched hist:174283 (Results 1 - 3 of 3) sorted by relevance
| /freebsd-10.2-release/sys/net80211/ | ||
| H A D | ieee80211_superg.h | diff 244051 Sun Dec 09 19:32:15 MST 2012 adrian Atheros SuperG bug fixes, as part of hunting down kern/174283. The stageqdepth (global, over all staging queues) was being kept incorrectly. It was being incremented whenever things were added, but only decremented during a flush. During active fast frames activity it wasn't being decremented, resulting in it always having a non-zero value during normal fast-frames operation. It was only used when checking if the aging queue should be checked; we may as well just defer to each of those staging queue counters (which look correct, thankfully.) Whilst I'm here, add locking assertions in the staging queue add/remove functions. The current crash shows that the staging queue has one frame, but only has a tail pointer set (the head pointer being set to NULL.) I'd like to grab a few more crashes where these locking assertions are in place so I can narrow down the issue between "somehow locking is messed up and things are racy" and "the stage queue head/tail pointer manipulation logic is subtly wrong." Tested: * AR5416 STA, AR5413 AP; with FastFrames enabled in the AR5416 HAL. PR: kern/174283 diff 244051 Sun Dec 09 19:32:15 MST 2012 adrian Atheros SuperG bug fixes, as part of hunting down kern/174283. The stageqdepth (global, over all staging queues) was being kept incorrectly. It was being incremented whenever things were added, but only decremented during a flush. During active fast frames activity it wasn't being decremented, resulting in it always having a non-zero value during normal fast-frames operation. It was only used when checking if the aging queue should be checked; we may as well just defer to each of those staging queue counters (which look correct, thankfully.) Whilst I'm here, add locking assertions in the staging queue add/remove functions. The current crash shows that the staging queue has one frame, but only has a tail pointer set (the head pointer being set to NULL.) I'd like to grab a few more crashes where these locking assertions are in place so I can narrow down the issue between "somehow locking is messed up and things are racy" and "the stage queue head/tail pointer manipulation logic is subtly wrong." Tested: * AR5416 STA, AR5413 AP; with FastFrames enabled in the AR5416 HAL. PR: kern/174283 diff 244044 Sun Dec 09 01:15:14 MST 2012 adrian Don't panic if the stageq here is empty; just fall through with NULL pointers and leave the stage queue flush routine to just do nothing (since both head and tail here will be NULL.) This should quieten the "stageq empty" panic where the stageq itself is empty, but it won't fix the second KASSERT() here "staging queue empty" as that's likely a different underlying problem. PR: kern/174283 |
| H A D | ieee80211_superg.c | diff 244051 Sun Dec 09 19:32:15 MST 2012 adrian Atheros SuperG bug fixes, as part of hunting down kern/174283. The stageqdepth (global, over all staging queues) was being kept incorrectly. It was being incremented whenever things were added, but only decremented during a flush. During active fast frames activity it wasn't being decremented, resulting in it always having a non-zero value during normal fast-frames operation. It was only used when checking if the aging queue should be checked; we may as well just defer to each of those staging queue counters (which look correct, thankfully.) Whilst I'm here, add locking assertions in the staging queue add/remove functions. The current crash shows that the staging queue has one frame, but only has a tail pointer set (the head pointer being set to NULL.) I'd like to grab a few more crashes where these locking assertions are in place so I can narrow down the issue between "somehow locking is messed up and things are racy" and "the stage queue head/tail pointer manipulation logic is subtly wrong." Tested: * AR5416 STA, AR5413 AP; with FastFrames enabled in the AR5416 HAL. PR: kern/174283 diff 244051 Sun Dec 09 19:32:15 MST 2012 adrian Atheros SuperG bug fixes, as part of hunting down kern/174283. The stageqdepth (global, over all staging queues) was being kept incorrectly. It was being incremented whenever things were added, but only decremented during a flush. During active fast frames activity it wasn't being decremented, resulting in it always having a non-zero value during normal fast-frames operation. It was only used when checking if the aging queue should be checked; we may as well just defer to each of those staging queue counters (which look correct, thankfully.) Whilst I'm here, add locking assertions in the staging queue add/remove functions. The current crash shows that the staging queue has one frame, but only has a tail pointer set (the head pointer being set to NULL.) I'd like to grab a few more crashes where these locking assertions are in place so I can narrow down the issue between "somehow locking is messed up and things are racy" and "the stage queue head/tail pointer manipulation logic is subtly wrong." Tested: * AR5416 STA, AR5413 AP; with FastFrames enabled in the AR5416 HAL. PR: kern/174283 diff 244044 Sun Dec 09 01:15:14 MST 2012 adrian Don't panic if the stageq here is empty; just fall through with NULL pointers and leave the stage queue flush routine to just do nothing (since both head and tail here will be NULL.) This should quieten the "stageq empty" panic where the stageq itself is empty, but it won't fix the second KASSERT() here "staging queue empty" as that's likely a different underlying problem. PR: kern/174283 |
| /freebsd-10.2-release/sys/dev/sio/ | ||
| H A D | sio.c | diff 174283 Wed Dec 05 05:16:56 MST 2007 julian Stop serial console and gdb serial port from getting all screwed up. PR: 65278 MFC in: 3 days Submitted by: ups@ |
Completed in 65 milliseconds