John, I posted some time ago following patches:
[RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
[PATCH 1/2] ssb: Use relative offsets for SPROM
[PATCH 2/2] ssb: Fix order of definitions and some text space indents
while Michael has some doubts about "ssb: Look for SPROM at different
offset on higher rev CC" I explained to him that what he does not like
was fixed in next 2 posted patches.
AFAIR you got some device with this recently-discovered location of
SPROM. Could you test my set if it makes your card working? If so,
could you take that patches to your tree?
--
Rafał
On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
> John, I posted some time ago following patches:
>
> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
> [PATCH 1/2] ssb: Use relative offsets for SPROM
> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>
> while Michael has some doubts about "ssb: Look for SPROM at different
> offset on higher rev CC" I explained to him that what he does not like
> was fixed in next 2 posted patches.
>
> AFAIR you got some device with this recently-discovered location of
> SPROM. Could you test my set if it makes your card working? If so,
> could you take that patches to your tree?
Sorry, been busy w/ other things. FWIW, my implementation based on
the RE work from Larry did not work on the box in question, and my
implementation wasn't substantially different from yours. Anyway,
I'll try to confirm this soon w/ your patches and to collect more
information for Larry.
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Mon, Apr 26, 2010 at 09:49:02PM +0200, Rafał Miłecki wrote:
> 2010/4/26 John W. Linville <[email protected]>:
> > P.S. With those patches, this box (soon to be Larry's) still uses
> > an sprom_offset value of 0x1000.
>
> Hm, so it looks like you device doesn't match our "if (version)"
> condition... It's just a blind guess, but maybe it would be worth to
> *force* other SPROM location on your machine? It seems quite proven
> that reading some incorrect registers (in this case incorrect SPROM
> location) can cause lock up. Of course it's just my guess, assuming
> you have other SPROM location, lock up is caused by reading wrong
> register and that Larry's condition in incorrect/not full. However if
> you're gonna to send whole machine to Larry, it sounds worthy to check
> this trick.
Well I thought I had done that before, but apparently not. I forced
sprom_offset to 0x0800 and ssb and b43 both load and act like they
are working. OTOH, b43 doesn't seem to be passing traffic but I may
just not have the right firmware...?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
2010/4/26 John W. Linville <[email protected]>:
> On Fri, Apr 16, 2010 at 11:22:28AM -0500, Larry Finger wrote:
>> On 04/16/2010 10:51 AM, Rafał Miłecki wrote:
>> > W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
>> > <[email protected]> napisał:
>> >> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
>> >>> John, I posted some time ago following patches:
>> >>>
>> >>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
>> >>> [PATCH 1/2] ssb: Use relative offsets for SPROM
>> >>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>> >>>
>> >>> while Michael has some doubts about "ssb: Look for SPROM at different
>> >>> offset on higher rev CC" I explained to him that what he does not like
>> >>> was fixed in next 2 posted patches.
>> >>>
>> >>> AFAIR you got some device with this recently-discovered location of
>> >>> SPROM. Could you test my set if it makes your card working? If so,
>> >>> could you take that patches to your tree?
>> >>
>> >> Sorry, been busy w/ other things. FWIW, my implementation based on
>> >> the RE work from Larry did not work on the box in question, and my
>> >> implementation wasn't substantially different from yours. Anyway,
>> >> I'll try to confirm this soon w/ your patches and to collect more
>> >> information for Larry.
>> >
>> > Ah, I didn't know you got own implementation. Had to miss it.
>> >
>> > Larry do you have any ideas what else may we do incorrectly?
>>
>> No. AFAICT, we have implemented it correctly. Any additional info would
>> be welcome.
>
> FWIW, this patch series also still results in a hang on my problematic
> netbook. I'm going to merge them anyway, in hopes that they make
> things better for someone (or at least get us closer to it). I'll try
> to pinpoint this hang as well.
Did it actually pick another (newly discovered) offset for SPROM
location in your case? Could you add some single printk to check this?
--
Rafał
W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
<[email protected]> napisał:
> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
>> John, I posted some time ago following patches:
>>
>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
>> [PATCH 1/2] ssb: Use relative offsets for SPROM
>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>>
>> while Michael has some doubts about "ssb: Look for SPROM at different
>> offset on higher rev CC" I explained to him that what he does not like
>> was fixed in next 2 posted patches.
>>
>> AFAIR you got some device with this recently-discovered location of
>> SPROM. Could you test my set if it makes your card working? If so,
>> could you take that patches to your tree?
>
> Sorry, been busy w/ other things. FWIW, my implementation based on
> the RE work from Larry did not work on the box in question, and my
> implementation wasn't substantially different from yours. Anyway,
> I'll try to confirm this soon w/ your patches and to collect more
> information for Larry.
Ah, I didn't know you got own implementation. Had to miss it.
Larry do you have any ideas what else may we do incorrectly?
John: may be worth checking if your card matched this new condition
and if driver actually used "new" offset.
--
Rafał
On 04/16/2010 10:51 AM, Rafał Miłecki wrote:
> W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
> <[email protected]> napisał:
>> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
>>> John, I posted some time ago following patches:
>>>
>>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
>>> [PATCH 1/2] ssb: Use relative offsets for SPROM
>>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>>>
>>> while Michael has some doubts about "ssb: Look for SPROM at different
>>> offset on higher rev CC" I explained to him that what he does not like
>>> was fixed in next 2 posted patches.
>>>
>>> AFAIR you got some device with this recently-discovered location of
>>> SPROM. Could you test my set if it makes your card working? If so,
>>> could you take that patches to your tree?
>>
>> Sorry, been busy w/ other things. FWIW, my implementation based on
>> the RE work from Larry did not work on the box in question, and my
>> implementation wasn't substantially different from yours. Anyway,
>> I'll try to confirm this soon w/ your patches and to collect more
>> information for Larry.
>
> Ah, I didn't know you got own implementation. Had to miss it.
>
> Larry do you have any ideas what else may we do incorrectly?
No. AFAICT, we have implemented it correctly. Any additional info would
be welcome.
Larry
On Fri, Apr 16, 2010 at 11:22:28AM -0500, Larry Finger wrote:
> On 04/16/2010 10:51 AM, Rafał Miłecki wrote:
> > W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
> > <[email protected]> napisał:
> >> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
> >>> John, I posted some time ago following patches:
> >>>
> >>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
> >>> [PATCH 1/2] ssb: Use relative offsets for SPROM
> >>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
> >>>
> >>> while Michael has some doubts about "ssb: Look for SPROM at different
> >>> offset on higher rev CC" I explained to him that what he does not like
> >>> was fixed in next 2 posted patches.
> >>>
> >>> AFAIR you got some device with this recently-discovered location of
> >>> SPROM. Could you test my set if it makes your card working? If so,
> >>> could you take that patches to your tree?
> >>
> >> Sorry, been busy w/ other things. FWIW, my implementation based on
> >> the RE work from Larry did not work on the box in question, and my
> >> implementation wasn't substantially different from yours. Anyway,
> >> I'll try to confirm this soon w/ your patches and to collect more
> >> information for Larry.
> >
> > Ah, I didn't know you got own implementation. Had to miss it.
> >
> > Larry do you have any ideas what else may we do incorrectly?
>
> No. AFAICT, we have implemented it correctly. Any additional info would
> be welcome.
FWIW, this patch series also still results in a hang on my problematic
netbook. I'm going to merge them anyway, in hopes that they make
things better for someone (or at least get us closer to it). I'll try
to pinpoint this hang as well.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Mon, Apr 26, 2010 at 02:04:03PM -0500, Larry Finger wrote:
> On 04/26/2010 01:33 PM, Rafał Miłecki wrote:
> > 2010/4/26 John W. Linville <[email protected]>:
> >> FWIW, this patch series also still results in a hang on my problematic
> >> netbook. I'm going to merge them anyway, in hopes that they make
> >> things better for someone (or at least get us closer to it). I'll try
> >> to pinpoint this hang as well.
> >
> > Did it actually pick another (newly discovered) offset for SPROM
> > location in your case? Could you add some single printk to check this?
>
> My suggestion is that for now we only implement John's patch for no
> SPROM. I am hoping that we try to fix the failures for boxes with the
> SPROM in a normal location. Once we do that, there will be a simpler fix
> for testing at the alternate location. The patch will all be contained
> in sprom_do_read().
Hmmm...well, I just pushed (just to my public trees, not to Dave)
Rafał's trio of patches on top of mine. Should I revert them?
John
P.S. With those patches, this box (soon to be Larry's) still uses
an sprom_offset value of 0x1000.
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
2010/4/26 John W. Linville <[email protected]>:
> On Mon, Apr 26, 2010 at 02:04:03PM -0500, Larry Finger wrote:
>> On 04/26/2010 01:33 PM, Rafał Miłecki wrote:
>> > 2010/4/26 John W. Linville <[email protected]>:
>
>> >> FWIW, this patch series also still results in a hang on my problematic
>> >> netbook. I'm going to merge them anyway, in hopes that they make
>> >> things better for someone (or at least get us closer to it). I'll try
>> >> to pinpoint this hang as well.
>> >
>> > Did it actually pick another (newly discovered) offset for SPROM
>> > location in your case? Could you add some single printk to check this?
>>
>> My suggestion is that for now we only implement John's patch for no
>> SPROM. I am hoping that we try to fix the failures for boxes with the
>> SPROM in a normal location. Once we do that, there will be a simpler fix
>> for testing at the alternate location. The patch will all be contained
>> in sprom_do_read().
>
> Hmmm...well, I just pushed (just to my public trees, not to Dave)
> Rafał's trio of patches on top of mine. Should I revert them?
AFAIU so far we didn't have any confirmation that it actually fixes
anything. Don't know... maybe it would be better to wait for any
successful feedback? I don't 100% know patches rules, let you decide.
In case we decide to implement that letter, it should be easy to
rebase patches.
> P.S. With those patches, this box (soon to be Larry's) still uses
> an sprom_offset value of 0x1000.
Hm, so it looks like you device doesn't match our "if (version)"
condition... It's just a blind guess, but maybe it would be worth to
*force* other SPROM location on your machine? It seems quite proven
that reading some incorrect registers (in this case incorrect SPROM
location) can cause lock up. Of course it's just my guess, assuming
you have other SPROM location, lock up is caused by reading wrong
register and that Larry's condition in incorrect/not full. However if
you're gonna to send whole machine to Larry, it sounds worthy to check
this trick.
--
Rafał
On 04/26/2010 01:33 PM, Rafał Miłecki wrote:
> 2010/4/26 John W. Linville <[email protected]>:
>> On Fri, Apr 16, 2010 at 11:22:28AM -0500, Larry Finger wrote:
>>> On 04/16/2010 10:51 AM, Rafał Miłecki wrote:
>>>> W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
>>>> <[email protected]> napisał:
>>>>> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
>>>>>> John, I posted some time ago following patches:
>>>>>>
>>>>>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
>>>>>> [PATCH 1/2] ssb: Use relative offsets for SPROM
>>>>>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>>>>>>
>>>>>> while Michael has some doubts about "ssb: Look for SPROM at different
>>>>>> offset on higher rev CC" I explained to him that what he does not like
>>>>>> was fixed in next 2 posted patches.
>>>>>>
>>>>>> AFAIR you got some device with this recently-discovered location of
>>>>>> SPROM. Could you test my set if it makes your card working? If so,
>>>>>> could you take that patches to your tree?
>>>>>
>>>>> Sorry, been busy w/ other things. FWIW, my implementation based on
>>>>> the RE work from Larry did not work on the box in question, and my
>>>>> implementation wasn't substantially different from yours. Anyway,
>>>>> I'll try to confirm this soon w/ your patches and to collect more
>>>>> information for Larry.
>>>>
>>>> Ah, I didn't know you got own implementation. Had to miss it.
>>>>
>>>> Larry do you have any ideas what else may we do incorrectly?
>>>
>>> No. AFAICT, we have implemented it correctly. Any additional info would
>>> be welcome.
>>
>> FWIW, this patch series also still results in a hang on my problematic
>> netbook. I'm going to merge them anyway, in hopes that they make
>> things better for someone (or at least get us closer to it). I'll try
>> to pinpoint this hang as well.
>
> Did it actually pick another (newly discovered) offset for SPROM
> location in your case? Could you add some single printk to check this?
My suggestion is that for now we only implement John's patch for no
SPROM. I am hoping that we try to fix the failures for boxes with the
SPROM in a normal location. Once we do that, there will be a simpler fix
for testing at the alternate location. The patch will all be contained
in sprom_do_read().
Larry