Hi,
I notice a regression report on Bugzilla [1]. Quoting from it:
> The following patch broke support of 3 more Zaurus models: SL-5600, A300 and C700
>
> [16adf5d07987d93675945f3cecf0e33706566005] usbnet: Remove over-broad module alias from zaurus
>
> dmesg and lsusb output attached.
Because the description above was vague, I asked the clarification.
The reporter replied:
> The problem is that networking to SL-5600 / A300 / C700 devices does not
> work. I cannot ping the devices.
>
> The error is occurring in zaurus.c. dmesg is missing the following line:
>
> zaurus 2-2:1.0 usb0: register 'zaurus' at usb-0000:00:1d.0-2,
> pseudo-MDLM (BLAN) device, 2a:01:39:93:bc:1a
>
> A patch was created in 2022 to fix the same problem with the SL-6000:
>
> USB: zaurus: support another broken Zaurus -
> [6605cc67ca18b9d583eb96e18a20f5f4e726103c]
>
> Could you please create another patch for the 3 devices: SL-5600 / A300
> / C700?
See Bugzilla for the full thread and attached dmesg and lsusb.
Dave: The reporter asked to write the quirk for affected devices.
Would you like to create it?
Anyway, I'm adding this to regzbot:
#regzbot introduced: 16adf5d07987d9 https://bugzilla.kernel.org/show_bug.cgi?id=217632
#regzbot title: Removing zaurus overbroad aliases breaks 3 Zaurus devices
Thanks.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217632
--
An old man doll... just what I always wanted! - Clara
On 7/5/23 09:09, Bagas Sanjaya wrote:
> Hi,
>
> I notice a regression report on Bugzilla [1]. Quoting from it:
>
>> The following patch broke support of 3 more Zaurus models: SL-5600, A300 and C700
>>
>> [16adf5d07987d93675945f3cecf0e33706566005] usbnet: Remove over-broad module alias from zaurus
>>
>> dmesg and lsusb output attached.
>
> Because the description above was vague, I asked the clarification.
> The reporter replied:
>
>> The problem is that networking to SL-5600 / A300 / C700 devices does not
>> work. I cannot ping the devices.
>>
>> The error is occurring in zaurus.c. dmesg is missing the following line:
>>
>> zaurus 2-2:1.0 usb0: register 'zaurus' at usb-0000:00:1d.0-2,
>> pseudo-MDLM (BLAN) device, 2a:01:39:93:bc:1a
>>
>> A patch was created in 2022 to fix the same problem with the SL-6000:
>>
>> USB: zaurus: support another broken Zaurus -
>> [6605cc67ca18b9d583eb96e18a20f5f4e726103c]
>>
>> Could you please create another patch for the 3 devices: SL-5600 / A300
>> / C700?
>
> See Bugzilla for the full thread and attached dmesg and lsusb.
>
> Dave: The reporter asked to write the quirk for affected devices.
> Would you like to create it?
>
Thorsten: Email to the culprit author (Dave) bounced. What can
I do in this case? Should I start adding get_maintainer.pl output?
--
An old man doll... just what I always wanted! - Clara
On 06.07.23 05:08, Bagas Sanjaya wrote:
> On 7/5/23 09:09, Bagas Sanjaya wrote:
>>
>> I notice a regression report on Bugzilla [1]. Quoting from it:
>>
>>> The following patch broke support of 3 more Zaurus models: SL-5600, A300 and C700
>>>
>>> [16adf5d07987d93675945f3cecf0e33706566005] usbnet: Remove over-broad module alias from zaurus
Side note: I wonder if the time spend on tracking and fighting
regressions from v3.0 would better be spend elsewhere. But whatever,
let's at least try.
>>> dmesg and lsusb output attached.
>>
>> Because the description above was vague, I asked the clarification.
>> The reporter replied:
>>
>>> The problem is that networking to SL-5600 / A300 / C700 devices does not
>>> work. I cannot ping the devices.
>>>
>>> The error is occurring in zaurus.c. dmesg is missing the following line:
>>>
>>> zaurus 2-2:1.0 usb0: register 'zaurus' at usb-0000:00:1d.0-2,
>>> pseudo-MDLM (BLAN) device, 2a:01:39:93:bc:1a
>>>
>>> A patch was created in 2022 to fix the same problem with the SL-6000:
>>>
>>> USB: zaurus: support another broken Zaurus -
>>> [6605cc67ca18b9d583eb96e18a20f5f4e726103c]
>>>
>>> Could you please create another patch for the 3 devices: SL-5600 / A300
>>> / C700?
>>
>> See Bugzilla for the full thread and attached dmesg and lsusb.
>>
>> Dave: The reporter asked to write the quirk for affected devices.
>> Would you like to create it?
>
> Thorsten: Email to the culprit author (Dave) bounced.
He sometimes shows up on Linux kernel lists, but I doubt he cares about
that change after all these years. And I would not blame him at all.
Yes, we have the "no regressions" rule, but contributing a change to the
kernel OTOH should not mean that you are responsible for all regressions
it causes for your whole life. :-)
> What can
> I do in this case? Should I start adding get_maintainer.pl output?
Yeah, that's not much helpful here afaics, as most of those that would
care are CCed already.
I'm CCing Oliver, he sent the fix mentioned above for the SL-6000. Maybe
he cares.
If not I guess this won't be fixed, unless we find somebody else to care
enough to submit a patch.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
On Thu, Jul 06, 2023 at 01:45:57PM +0200, Thorsten Leemhuis wrote:
> On 06.07.23 05:08, Bagas Sanjaya wrote:
> >>
> >> I notice a regression report on Bugzilla [1]. Quoting from it:
> >>
> >>> The following patch broke support of 3 more Zaurus models: SL-5600, A300 and C700
> >>>
> >>> [16adf5d07987d93675945f3cecf0e33706566005] usbnet: Remove over-broad module alias from zaurus
>
> ...
> He sometimes shows up on Linux kernel lists, but I doubt he cares about
> that change after all these years. And I would not blame him at all.
That's about the size of it. This is pretty near the bottom of my ever-shrinking
list of kernel drivers I care about.
> Yes, we have the "no regressions" rule, but contributing a change to the
> kernel OTOH should not mean that you are responsible for all regressions
> it causes for your whole life. :-)
That said, 12 years later, 16adf5d07987d93675945f3cecf0e33706566005
is still the right thing to do. Adding actual matches for the devices
rather than matching by class will prevent this getting loaded where it
doesn't need to be.
If someone actually cares to get this working, cargo-culting Oliver's
change to add the extra id is likely the way forward.
Dave
Hi,
I am not a kernel developer, but I think the attached patch would work.
Ross
On 7/7/23 2:41 am, Dave Jones wrote:
> On Thu, Jul 06, 2023 at 01:45:57PM +0200, Thorsten Leemhuis wrote:
> > On 06.07.23 05:08, Bagas Sanjaya wrote:
> > >>
> > >> I notice a regression report on Bugzilla [1]. Quoting from it:
> > >>
> > >>> The following patch broke support of 3 more Zaurus models: SL-5600, A300 and C700
> > >>>
> > >>> [16adf5d07987d93675945f3cecf0e33706566005] usbnet: Remove over-broad module alias from zaurus
> >
> > ...
> > He sometimes shows up on Linux kernel lists, but I doubt he cares about
> > that change after all these years. And I would not blame him at all.
>
> That's about the size of it. This is pretty near the bottom of my ever-shrinking
> list of kernel drivers I care about.
>
> > Yes, we have the "no regressions" rule, but contributing a change to the
> > kernel OTOH should not mean that you are responsible for all regressions
> > it causes for your whole life. :-)
>
> That said, 12 years later, 16adf5d07987d93675945f3cecf0e33706566005
> is still the right thing to do. Adding actual matches for the devices
> rather than matching by class will prevent this getting loaded where it
> doesn't need to be.
>
> If someone actually cares to get this working, cargo-culting Oliver's
> change to add the extra id is likely the way forward.
>
> Dave
>
I applied my patch then recompiled the kernel, and the 3 devices can now
connect via USB:
[ 268.872485] usb 3-2: New USB device found, idVendor=04dd,
idProduct=8005, bcdDevice= 0.00
[ 268.872498] usb 3-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 268.872502] usb 3-2: Product: SL-A300
[ 268.872505] usb 3-2: Manufacturer: Sharp
[ 268.876526] zaurus 3-2:1.0 usb0: register 'zaurus' at
usb-0000:00:14.0-2, pseudo-MDLM (BLAN) device, fa:0f:0f:08:2b:59
[ 595.541549] usb 3-2: New USB device found, idVendor=04dd,
idProduct=8006, bcdDevice= 0.00
[ 595.541562] usb 3-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 595.541566] usb 3-2: Product: SL-5600
[ 595.541569] usb 3-2: Manufacturer: Sharp
[ 595.545148] zaurus 3-2:1.0 usb0: register 'zaurus' at
usb-0000:00:14.0-2, pseudo-MDLM (BLAN) device, fa:0f:0f:08:2b:59
[ 446.954583] usb 3-2: New USB device found, idVendor=04dd,
idProduct=8007, bcdDevice= 0.00
[ 446.954596] usb 3-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 446.954600] usb 3-2: Product: SL-C700
[ 446.954603] usb 3-2: Manufacturer: Sharp
[ 446.957871] zaurus 3-2:1.0 usb0: register 'zaurus' at
usb-0000:00:14.0-2, pseudo-MDLM (BLAN) device, fa:0f:0f:08:2b:59
Could someone please submit the patch for me?
Thanks.
Ross
On 7/7/23 10:28 pm, Ross Maynard wrote:
> Hi,
>
> I am not a kernel developer, but I think the attached patch would work.
>
> Ross
>
> On 7/7/23 2:41 am, Dave Jones wrote:
>> On Thu, Jul 06, 2023 at 01:45:57PM +0200, Thorsten Leemhuis wrote:
>> > On 06.07.23 05:08, Bagas Sanjaya wrote:
>> > >>
>> > >> I notice a regression report on Bugzilla [1]. Quoting from it:
>> > >>
>> > >>> The following patch broke support of 3 more Zaurus models:
>> SL-5600, A300 and C700
>> > >>>
>> > >>> [16adf5d07987d93675945f3cecf0e33706566005] usbnet: Remove
>> over-broad module alias from zaurus
>> >
>> > ...
>> > He sometimes shows up on Linux kernel lists, but I doubt he cares
>> about
>> > that change after all these years. And I would not blame him at all.
>>
>> That's about the size of it. This is pretty near the bottom of my
>> ever-shrinking
>> list of kernel drivers I care about.
>>
>> > Yes, we have the "no regressions" rule, but contributing a change
>> to the
>> > kernel OTOH should not mean that you are responsible for all
>> regressions
>> > it causes for your whole life. :-)
>>
>> That said, 12 years later, 16adf5d07987d93675945f3cecf0e33706566005
>> is still the right thing to do. Adding actual matches for the devices
>> rather than matching by class will prevent this getting loaded where it
>> doesn't need to be.
>>
>> If someone actually cares to get this working, cargo-culting Oliver's
>> change to add the extra id is likely the way forward.
>>
>> Dave
>>
> Could someone please submit the patch for me?
You are not far from it yourself.
I've not followed the history here. Did it never work, or has it
worked in the past, and then at some point broke?
If it never worked, this would be classed as new development, and so
the patch should be for net-next. If it did work, but at some point in
time it stopped working, then it is for net.
Take a read of:
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
And produce a patch based on net, or net-next.
Also read:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html
Please ask questions if anything is not clear.
Andrew
On 08.07.23 22:49, Andrew Lunn wrote:
>> Could someone please submit the patch for me?
>
> You are not far from it yourself.
>
> I've not followed the history here. Did it never work, or has it
> worked in the past, and then at some point broke?
>
> If it never worked, this would be classed as new development, and so
> the patch should be for net-next. If it did work, but at some point in
> time it stopped working, then it is for net.
> [...]
To chime in here: I most agree, but FWIW, it broke more than a decade
ago in v3.0, so maybe this is better suited for net-next. But of course
that up to the -net maintainers.
Ciao, Thorsten
On Sun, 9 Jul 2023 06:36:32 +0200 Linux regression tracking (Thorsten
Leemhuis) wrote:
> To chime in here: I most agree, but FWIW, it broke more than a decade
> ago in v3.0, so maybe this is better suited for net-next. But of course
> that up to the -net maintainers.
I'm surprised to see you suggest -next for a fix to a user reported bug.
IMO it's very firmly net material.
On 10.07.23 18:55, Jakub Kicinski wrote:
> On Sun, 9 Jul 2023 06:36:32 +0200 Linux regression tracking (Thorsten
> Leemhuis) wrote:
>> To chime in here: I most agree, but FWIW, it broke more than a decade
>> ago in v3.0, so maybe this is better suited for net-next. But of course
>> that up to the -net maintainers.
>
> I'm surprised to see you suggest -next for a fix to a user reported bug.
> IMO it's very firmly net material.
Yes, yes, normally it would argue the other way around. :-D
But Linus a few times in one way or another argued that time is a factor
when it comes to regressions. Here for example:
https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/
But there are no "semantic changes that now mean that fixing the
regression could cause a _new_ regression" here I guess. And what he was
talking about there is quite different from this case as well (I vaguely
remember a better example, but I can't find it; whatever).
In the end this is one of issue where I don't care much. :-D
Ciao, Thorsten