Bug#956868: Use Realtek's r8101 driver
El 2020-05-08 a las 07:37 +0200, Heiner Kallweit escribió: > On 07.05.2020 16:14, Camaleón wrote: > > On Thu, 7 May 2020 12:20:54 +0200, Heiner Kallweit wrote: > > > > Hello, > > > >> RTL8401 (XID 240) was never supported by r8169. > >> Having said that nothing was dropped from the driver. > >> And most likely you don't have to compile r8101 yourself, > >> most distro's have a pre-compiled package. > > > > How that can be? This computer perfectly detected the ethernet card > > years ago (2013), using kernel 3.9.0-rc2 (Debian nomenclature) and r8169 > > driver: > > > > (dmesg excerpt) > > > > [0.00] Linux version 3.9.0-rc2 (root@stt300) (gcc version 4.7.2 > > (Debian 4.7.2-5) ) #1 SMP Sun Mar 17 22:49:53 CET 2013 > > > > [0.00] DMI: Hewlett-Packard Compaq Mini CQ10-500 /148A, BIOS F.15 > > 01/14/2011 > > > > [6.558651] [drm] Initialized drm 1.1.0 20060810 > > [6.573693] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded > > [6.574014] r8169 :01:00.0 (unregistered net_device): unknown MAC, > > using family default > > This is the key. There has never been native support for the RTL8401. In > earlier times (until > end of 2018) we had a fallback to a default chip version for unknown chip > versions. > This was removed because each chip version requires it's own specific > initialization and quirks. So we had «some kind of support» in kernel that now is gone ;-) > It's quite fortunate that your RTL8401 works properly if treated as RTL8101e. > What we can do is adding this as explicit assignment. Yes... please! :-) This NIC chipset is installed in very common netbooks (I'm at least aware of 2 more cases like mine). Ethernet cards are a must for business environments. Should you need additonal hardware information, kindly ask. Greetings, -- Camaleón
Bug#956868: Use Realtek's r8101 driver
On 07.05.2020 16:14, Camaleón wrote: > On Thu, 7 May 2020 12:20:54 +0200, Heiner Kallweit wrote: > > Hello, > >> RTL8401 (XID 240) was never supported by r8169. >> Having said that nothing was dropped from the driver. >> And most likely you don't have to compile r8101 yourself, >> most distro's have a pre-compiled package. > > How that can be? This computer perfectly detected the ethernet card > years ago (2013), using kernel 3.9.0-rc2 (Debian nomenclature) and r8169 > driver: > > (dmesg excerpt) > > [0.00] Linux version 3.9.0-rc2 (root@stt300) (gcc version 4.7.2 > (Debian 4.7.2-5) ) #1 SMP Sun Mar 17 22:49:53 CET 2013 > > [0.00] DMI: Hewlett-Packard Compaq Mini CQ10-500 /148A, BIOS F.15 > 01/14/2011 > > [6.558651] [drm] Initialized drm 1.1.0 20060810 > [6.573693] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded > [6.574014] r8169 :01:00.0 (unregistered net_device): unknown MAC, > using family default This is the key. There has never been native support for the RTL8401. In earlier times (until end of 2018) we had a fallback to a default chip version for unknown chip versions. This was removed because each chip version requires it's own specific initialization and quirks. It's quite fortunate that your RTL8401 works properly if treated as RTL8101e. What we can do is adding this as explicit assignment. > [6.574358] r8169 :01:00.0: irq 43 for MSI/MSI-X > [6.575005] r8169 :01:00.0 eth0: RTL8101e at 0xf8268000, > 68:b5:99:d3:c1:d8, XID 0400 IRQ 43: > > (pci devices excerpt) > > 01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. > RTL8101E/RTL8102E PCI Express Fast Ethernet controller [10ec:8136] (rev 04) > Subsystem: Hewlett-Packard Company Device [103c:148a] > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 43 > Region 0: I/O ports at 2000 [size=256] > Region 2: Memory at 90004000 (64-bit, prefetchable) [size=4K] > Region 4: Memory at 9000 (64-bit, prefetchable) [size=16K] > Capabilities: > Kernel driver in use: r8169 > > Greetings, >
Bug#908712: Still present in stable
Hi Martin, Arnaud,
On Mon, May 04, 2020 at 04:49:36PM +0800, Martin Michlmayr wrote:
> The fix got accepted upstream a long time ago and made it into
> unstable.
>
> Unfortunately, even though Arnaud submitted it to the -stable tree and
> even though maintainer Andrew Lunn acked it, it never made it into
> the 4.19 stable series (despite several pings from Arnaud).
I see it was acked here
https://lore.kernel.org/netdev/2019080353.ga29...@lunn.ch/ and
applied to stable due to
https://lore.kernel.org/netdev/20190805.133134.1233042381014184856.da...@davemloft.net/
but usually Dave does only take backports for the last two stable
releases.
I have looked up the stable list but did not found any followup
specific with the 4.19 backport.
Might it be worth doing one last timme a request explicitly for a
backport to 4.19 including your patch, sending it to stable list, and
as required Cc'ed again to Andrew Lunn, Dave and the netdev list and
other required people?
The upstream commit d934423ac26e
("drivers/net/ethernet/marvell/mvmdio.c: Fix non OF case") does not
seem to apply cleanly to linux-4.19.y so the request should include
explicitly as well the backported version.
Does this helps?
Regards,
Salvatore
Uitverkoop software - achteraf betalen: Microsoft Office en Windows - Adobe Mastercollection - Coreldraw - Autocad
Software kopen - achteraf betalen Office Professional Plus 2019 uitzonderlijk aan 8,5� Beste Klant, Voor onze thuiswerkers hebben wij een gigantisch mooie promo uitgewerkt. Op die manier kan iedereen over de laatste nieuwe software beschikken. Bestaande uit: Microsoft Publisher 2019 Microsoft Access 2019 Microsoft Outlook 2019 Microsoft Word 2019 Microsoft Excel 2019 Microsoft Powerpoint 2019 Microsoft OneNote Microsoft Lync. Office Professional Plus 2019: 8,5� Office Home and Business voor MAC 2019: 8,5� Bestel je Office 2019 licentie(s) hier -Enkel via mail- Klik hier! * Adobe Master Collection CC 2019 * We hebben er zeer lang op moeten wachten maar eindelijk kunnen we onze klanten terug de Adobe Master Collection CC 2019 aanbieden. Het gaat hier om permanente versies dus geen abonnementen. We zijn zeer fier dat we dit kunnen aanbieden. Let wel de voorraad is vrij beperkt.- Enkel beperkt voor Windows gebruikers Adobe Master Collection CC 2019 Permanente versie Enkel voor Windows gebruikers Prijs: 59� (normale prijs: 699�) Opgelet: Beperkte voorraad Volume licentie 2 toestellen: 109� Volumelicentie 3 toestellen: 129� Volumelicentie 5 toestellen: 139� Adobe Master Collection CC bestellen - Enkel via mail ***Topaanbieding Microsoft Professional 2016*** We kunnen jullie Office Professional 2016 plus aanbieden aan de knalprijs van 7,5� per licentie. Bestaande uit: Microsoft Publisher 2016 Microsoft Access 2016 Microsoft Outlook 2016 Microsoft Word 2016 Microsoft Excel 2016 Microsoft Powerpoint 2016 Microsoft OneNote Microsoft Onedrive Prijs:7,5� Opgelet: Beperkte voorraad Office 2016 bestellen - Enkel via mail *** NEW NEW NEW NEW *** *** Visual Studio Enterprise 2019 *** *** Dagdeal: geldig tot 6/5 23h59 of zolang de voorraad strekt*** Nieuw en direct met een knalaanbieding Microsoft Visual Studio Enterprise aan 39�. Met de ontwikkelomgeving Visual Studio 2019 Enterprise kunnen complexe bedrijfstoepassingen worden gemaakt. De Enterprise-versie van de end-to-end-oplossing is speciaal geschikt voor grotere bedrijven en programmeerteams. De software biedt een grote keus aan hulpmiddelen voor het ontwerpen en testen van programma's. Visual Studio is bovendien te koppelen aan verschillende diensten en abonnementen, zodat elk bedrijf die ontwikkelomgeving kan samenstellen die nodig is. De aanschaf van Visual Studio 2019 Enterprise betekent de keus voor een geïntegreerde oplossing, die ook op het gebied van kwaliteit en schaalbaarheid aan hoge vereisten voldoet. *** Superactie prijszetting *** Visual Studio Enterprise 2019: 39� Licenties enkel te bestellen via mail. OP=OP OPGELET: REGISTRATIE OP NAAM Visual Studio enterprise bestellen - enkel via mail *** Eenmalige actie*** *** Knaller Microsoft Windows Server Standard 2019:*** Schitterende actie, Server 2019 Standard uitzonderlijk beschikbaar aan 29� per licentie. In totaal hebben we 250 licenties voorzien voor deze actie. Microsoft Server 2019 Standard Prijs: 29� Prijs incl 50 call's (user of remotedesktop: 65� Geldig zolang de voorraad strekt Server 2019 standard bestellen- enkel via mail *** Microsoft Visio en Project 2019 aan knalprijszetting *** We hebben voor jullie de Visio en Project Professional 2019 van Microsoft in knalaanbieding staan. Prijszetting: Visio 2019: 9� Project 2019: 9� Bundel Visio/Project: 14� Tijdelijke actie, OP=OP Visio/Project 2019 bestellen - enkel via mail *** NEW NEW NEW NEW *** * Coreldraw Graphics Suite 2020 * We hebben er een tijdje op moeten wachten maar de eerste licenties uit falingen zijn beschikbaar. Slecht de creatieve grenzen met CorelDRAWî Graphics Suite 2020, de onmisbare grafisch-ontwerpsoftware voor professionele vectorillustratie, lay-out, fotobewerking en meer - op Windows, Mac en het web. Profiteer van een gestroomlijnde ontwerpervaring met eenkliks-beeldverbeteringen die gebruikmaken van de nieuwste ontwikkelingen in machine learning, en ervaar de AI-ondersteuning van PowerTRACE�, waardoor het overtrekken van bitmaps naar vectoren een ongeëvenaarde ervaring wordt. Laat uw tekst echt spreken met de geavanceerde ondersteuning voor variabele lettertypen en de verbeteringen in de tools voor lettertypen. Ga in recordtijd van concept naar eindproduct met tot 10x snellere prestaties vergeleken met de vorige versie en profiteer van de verbeteringen in uw favoriete functies. U kunt de klus klaren dankzij ongekende productiviteit en grenzeloze creativiteit, met CorelDRAW Graphics Suite 2020 Coreldraw Graphics Suite 2020 Permanente versie Enkel voor Windows gebruikers Prijs: 59� (normale prijs: 699�) Opgelet: Beperkte voorraad Volume licentie 2 toestellen: 109� Volumelicentie 3 toestellen: 129� Volumelicentie 5 toestellen: 139� Coreldraw Graphics Suite 2020 bestellen- Enkel via mail *** NEW NEW
CPUs which work with the stable version of Debian Buster
Hi. I wish to have a desktop built which will have the latest stable version of Buster - Debian 10.3 - as the operating system. I understand that Buster was frozen on 12th January 2019. Does this mean I should use a CPU that was on the market before the freeze date to ensure the CPU works okay with the operating system ? I do not wish to use back ported versions of Buster, but only the latest standard version I.e Debian 10.3. My knowledge of Linux is very limited, so I do not understand the literature which accompanies updates, backports, etc. I would be very grateful if someone could help me in this matter.
Please enable applespi driver
Dear all Our users need support for newer MacBook keyboards and touchpads. Starting with Linux kernel v5.3 this driver is included upstream. After integrating the current Linux kernel from Debian backports, the MacBook keyboards and touchpads of our users are still not working. After some research we found out that the reason is that CONFIG_KEYBOARD_APPLESPI=m is not enabled in the Debian kernel packages. This was already reported in October (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943337). Because of the omnipresence of secure boot and kernel lockdown mechanisms we already lost the freedom to simply build and distribute our own kernel and modules but are dependent on working upstream distribution kernels. So, because we simply can't fix this ourselfs, could you please fix this issue? Thank you very much for your hard work! Best regards Ronny
Bug#956868: Use Realtek's r8101 driver
On Thu, 7 May 2020 12:20:54 +0200, Heiner Kallweit wrote: Hello, > RTL8401 (XID 240) was never supported by r8169. > Having said that nothing was dropped from the driver. > And most likely you don't have to compile r8101 yourself, > most distro's have a pre-compiled package. How that can be? This computer perfectly detected the ethernet card years ago (2013), using kernel 3.9.0-rc2 (Debian nomenclature) and r8169 driver: (dmesg excerpt) [0.00] Linux version 3.9.0-rc2 (root@stt300) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Sun Mar 17 22:49:53 CET 2013 [0.00] DMI: Hewlett-Packard Compaq Mini CQ10-500 /148A, BIOS F.15 01/14/2011 [6.558651] [drm] Initialized drm 1.1.0 20060810 [6.573693] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [6.574014] r8169 :01:00.0 (unregistered net_device): unknown MAC, using family default [6.574358] r8169 :01:00.0: irq 43 for MSI/MSI-X [6.575005] r8169 :01:00.0 eth0: RTL8101e at 0xf8268000, 68:b5:99:d3:c1:d8, XID 0400 IRQ 43: (pci devices excerpt) 01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller [10ec:8136] (rev 04) Subsystem: Hewlett-Packard Company Device [103c:148a] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: r8169 Greetings, -- Camaleón
Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4
On 2020.05.07 13:45, Ben Hutchings wrote: Also, there would be no point in enabling this driver in 4.19, only to have people find on upgrade to the next version on Debian that we didn't enable it there. That's why we're concerned with both versions. Yes, I did consider that, but I feel that this is an issue that should have been tracked separately (especially as, like we have seen, this polluted this issue with unrelated queries), as it doesn't have the same level of severity. Vanilla breakage vs optional breakage should not be grouped together IMO. But of course, you're free to do what you want. [...] I would also greatly appreciate if this could actually be treated with the level of urgency it requires on account of the following. All "missing hardware support" bugs have severity "important". And I will assert that bugs should be evaluated in terms of potential users that are going to be impacted. Support for a NIC that's used in niche hardware should not have the same level of severity as support for a NIC that is used on hardware that sold a quarter of a million units in less than a year. [...] - The required patch to *SOLVE* the issue has been provided, so it's not [...] I acknowledge that you have provided a patch, which I appreciate, and I'm sorry you haven't had a specific response to that yet. Generally we want patches that correspond closely to upstream commits. For 5.5 I had to backport these 6 commits: ce69e2162f15 mdio_bus: Add generic mdio_find_bus() 480ded265205 net: bcmgenet: refactor phy mode configuration 6ef31c8bee5b net: bcmgenet: enable automatic phy discovery 99c6b06a37d4 net: bcmgenet: Initial bcmgenet ACPI support 26bd9cc64faf net: bcmgenet: Fetch MAC address from the adapter ae200c26b32b net: bcmgenet: reduce severity of missing clock warnings Can you please provide separate backports of these, instead of a single patch where it's hard to see what changed? Sigh. I specifically designed the patch I submitted for easy review and integration, because there are missing elements from 4.x that are present in 5.x, that we have to compensate for. I would rather not have to split it, especially as I believe it should be included as a matter of priority and we're simply adding delays. If Debian 11 was planning to continue to use a 4.x kernel, I could see some point in splitting the patch and ensuring, so that it *might* be easier to maintain for many years to come. But, from what I gather, Debian 11 will bump kernel major, so any work being done making the 4.x backport (which is not that complex, sorry, especially as I made sure to already group the code changes in a manner that makes it easier to handle) easier to maintain in the long run seems like a waste of time, even if 10.x may see long time support for a few more years... If you had made that point a few months ago, I would have been more inclined to do it, but at this stage, considering that it's too late for 10.4 anyway, and considering that I feel like I've wasted more than enough time trying to push for this change to be included to help RPi4 Debian users, and that 2 releases have gone by without any progress, I will respectfully decline to provide alterations to the submission unless it has to do with something that effectively prevents its integration, sorry. Regards, /Pete
Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4
Pete Batard wrote: > I would really like to get an update on this, because I really can't > understand what the holdup is, or why non related issues seem to be be > shoved into this bug, with the apparent end result of completely > distracting from the matter at hand. [...] > It is *NOT* about tracking whether the 5.x kernel packages have Genet > support. And it is *NOT* about troubleshooting network issues with the > 5.x kernel. The Debian bug tracking system is quite capable of recording *which* versions an issue is found and fixed in. So it's fine that this bug is marked fixed in 5.x; we still know that it's unfixed in 4.19. Also, there would be no point in enabling this driver in 4.19, only to have people find on upgrade to the next version on Debian that we didn't enable it there. That's why we're concerned with both versions. [...] > I would also greatly appreciate if this could actually be treated with > the level of urgency it requires on account of the following. All "missing hardware support" bugs have severity "important". [...] > - The required patch to *SOLVE* the issue has been provided, so it's not [...] I acknowledge that you have provided a patch, which I appreciate, and I'm sorry you haven't had a specific response to that yet. Generally we want patches that correspond closely to upstream commits. For 5.5 I had to backport these 6 commits: ce69e2162f15 mdio_bus: Add generic mdio_find_bus() 480ded265205 net: bcmgenet: refactor phy mode configuration 6ef31c8bee5b net: bcmgenet: enable automatic phy discovery 99c6b06a37d4 net: bcmgenet: Initial bcmgenet ACPI support 26bd9cc64faf net: bcmgenet: Fetch MAC address from the adapter ae200c26b32b net: bcmgenet: reduce severity of missing clock warnings Can you please provide separate backports of these, instead of a single patch where it's hard to see what changed? Ben. -- Ben Hutchings - Debian developer, member of kernel, installer and LTS teams signature.asc Description: This is a digitally signed message part
Bug#959936: mt7601u: WARNING: CPU: 2 PID: 0 at drivers/net/wireless/mediatek/mt7601u/mac.c
Package: src:linux Version: 4.19.98-1+deb10u1 Severity: important File: mt7601u Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- Package-specific info: ** Version: Linux version 4.19.0-8-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1+deb10u1 (2020-04-27) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-8-amd64 root=UUID=8789ded0-11fa-41db-a2fb-a9d396977fbe ro quiet ** Tainted: W (512) * Taint on warning. ** Kernel log: [ 2060.253001] RSP: 0018:9e781ba83e68 EFLAGS: 00010246 [ 2060.253002] RAX: 0024 RBX: 9e7818806600 RCX: [ 2060.253002] RDX: RSI: 9e781ba966b8 RDI: 9e781ba966b8 [ 2060.253003] RBP: ffc9 R08: 27ac R09: 0004 [ 2060.253003] R10: R11: 0001 R12: 000a [ 2060.253004] R13: 9e7815228004 R14: 9e7815228020 R15: 9e7819d8f540 [ 2060.253005] FS: () GS:9e781ba8() knlGS: [ 2060.253005] CS: 0010 DS: ES: CR0: 80050033 [ 2060.253005] CR2: 7fff40f11b2c CR3: 000116f92000 CR4: 06e0 [ 2060.253007] Call Trace: [ 2060.253009] [ 2060.253013] mt7601u_rx_tasklet+0x22a/0x570 [mt7601u] [ 2060.253017] tasklet_action_common.isra.21+0x5a/0x100 [ 2060.253020] __do_softirq+0xde/0x2d8 [ 2060.253022] irq_exit+0xba/0xc0 [ 2060.253022] do_IRQ+0x7f/0xe0 [ 2060.253025] common_interrupt+0xf/0xf [ 2060.253025] [ 2060.253026] RIP: 0010:native_safe_halt+0xe/0x10 [ 2060.253027] Code: ff ff 7f c3 65 48 8b 04 25 40 5c 01 00 f0 80 48 02 20 48 8b 00 a8 08 75 c4 eb 80 90 e9 07 00 00 00 0f 00 2d 46 c7 4d 00 fb f4 90 e9 07 00 00 00 0f 00 2d 36 c7 4d 00 f4 c3 90 90 0f 1f 44 00 [ 2060.253027] RSP: 0018:ab6c806a7ea8 EFLAGS: 00010246 ORIG_RAX: ffdd [ 2060.253028] RAX: a412b290 RBX: 0002 RCX: a4a4f390 [ 2060.253028] RDX: 00554bfe RSI: a4a4aff8 RDI: 01dfaf62d7d0 [ 2060.253029] RBP: 0002 R08: 0363b07a610b R09: [ 2060.253029] R10: 9e781346dda8 R11: R12: [ 2060.253030] R13: R14: R15: [ 2060.253031] ? __sched_text_end+0x7/0x7 [ 2060.253032] default_idle+0x1c/0x140 [ 2060.253034] do_idle+0x1e3/0x270 [ 2060.253035] cpu_startup_entry+0x6f/0x80 [ 2060.253037] start_secondary+0x1a4/0x1f0 [ 2060.253039] secondary_startup_64+0xa4/0xb0 [ 2060.253040] ---[ end trace 2ef85b11182a4cbd ]--- [ 2061.317482] [ cut here ] [ 2061.317551] WARNING: CPU: 2 PID: 22 at drivers/net/wireless/mediatek/mt7601u/mac.c:411 mt76_mac_process_rx.cold.3+0x2a/0x36 [mt7601u] [ 2061.317552] Modules linked in: arc4 vmwgfx mt7601u ttm drm_kms_helper mac80211 cfg80211 drm sg rfkill evdev vboxguest pcspkr video joydev serio_raw button ac ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb crypto_simd cryptd glue_helper aes_x86_64 hid_generic usbhid hid sr_mod cdrom sd_mod ata_generic ohci_pci ehci_pci ahci ata_piix ohci_hcd libahci ehci_hcd libata usbcore crc32c_intel psmouse scsi_mod i2c_piix4 e1000 usb_common [ 2061.317573] CPU: 2 PID: 22 Comm: ksoftirqd/2 Tainted: GW 4.19.0-8-amd64 #1 Debian 4.19.98-1+deb10u1 [ 2061.317574] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 2061.317576] RIP: 0010:mt76_mac_process_rx.cold.3+0x2a/0x36 [mt7601u] [ 2061.317577] Code: 48 c7 c7 10 ed 40 c0 89 14 24 e8 18 56 6d e3 0f 0b 31 c0 8b 14 24 e9 de eb ff ff 48 c7 c7 10 ed 40 c0 89 14 24 e8 fd 55 6d e3 <0f> 0b 31 c0 8b 14 24 e9 ca ec ff ff 48 c7 c7 d8 ed 40 c0 e8 e5 55 [ 2061.317578] RSP: 0018:ab6c80707d90 EFLAGS: 00010246 [ 2061.317579] RAX: 0024 RBX: 9e7818806600 RCX: [ 2061.317579] RDX: RSI: 9e781ba966b8 RDI: 9e781ba966b8 [ 2061.317580] RBP: ffc9 R08: 27d4 R09: 0004 [ 2061.317580] R10: R11: 0001 R12: 000a [ 2061.317581] R13: 9e7815228004 R14: 9e7815228020 R15: 9e7819d8f540 [ 2061.317582] FS: () GS:9e781ba8() knlGS: [ 2061.317582] CS: 0010 DS: ES: CR0: 80050033 [ 2061.317583] CR2: 7ffddc8d5ff8 CR3: 00010be0a000 CR4: 06e0 [ 2061.317584] Call Trace: [ 2061.317590] mt7601u_rx_tasklet+0x22a/0x570 [mt7601u] [ 2061.317594] tasklet_action_common.isra.21+0x5a/0x100 [ 2061.317597] __do_softirq+0xde/0x2d8 [ 2061.317599] ? sort_range+0x20/0x20 [ 2061.317600] run_ks
Bug#956868: Use Realtek's r8101 driver
RTL8401 (XID 240) was never supported by r8169. Having said that nothing was dropped from the driver. And most likely you don't have to compile r8101 yourself, most distro's have a pre-compiled package.
Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4
I would really like to get an update on this, because I really can't understand what the holdup is, or why non related issues seem to be be shoved into this bug, with the apparent end result of completely distracting from the matter at hand. This bug is about one thing and one thing only: Enabling Raspberry Pi 4 users to perform a netinstall using the next official aarch64 ISO of Debian 10.x. Therefore it is only about backporting the Genet ACPI driver into the 4.19 kernel, for which an effective backport patch was actually submitted. It is *NOT* about tracking whether the 5.x kernel packages have Genet support. And it is *NOT* about troubleshooting network issues with the 5.x kernel. The sole focus for the bug, as it was opened by the submitter (myself) is to add Genet support to the kernel that is used by the Debian ISO installer, and, seeing that no progress appears to have been made on that front, despite the fact that a patch to *SOLVE* the reported issue has been submitted along with the bug report, I would greatly appreciate if we could reframe the problem and drop all references to 5.x genet support as being linked to this bug, as it looks to me like this is hindering the resolution of the one and only issue that prompted the creation of this bug. I would also greatly appreciate if this could actually be treated with the level of urgency it requires on account of the following. - As of March 2020, the Raspberry Pi Foundation announced that it had sold 640 000 Raspberry Pi 4 units, and one can reasonably expect that 1 million units will have been sold by year's end, which clearly makes the platform one of the most popular ARM64 targets, if not the most popular, and therefore, one can reasonably expect many of its users to want to install Debian 10.x on it. By not applying the proposed patch and enabling netinst from official Debian 10.x ISOs as a matter of urgency, Debian maintainers will be doing a major disservice to their users. - The required patch to *SOLVE* the issue has been provided, so it's not like Debian maintainers have to invest time to create the backport themselves. And for the record, I did work with Jeremy Linton, the person who upstreamed the main patch for 5.x kernels, and used the code that he was in the process of submitting at that time to create the backport (which is actually tailored for easy review by Debian maintainers), so the attached patch was not produced in isolation. - Though it may look that way at first glance, this patch is not being requested because we are using a custom/toy bootloader. On the contrary, the very reason why we can use the official aarch64 ISO is because we are following industry standards pretty much to the letter. We are using both ACPI and UEFI in a very official manner, and as a matter of fact, the UEFI firmware that is meant to be used with the official ISOs is fully integrated with the EDK2 [1]. So this is not a "it would be nice if Debian could do this so that it would work with our custom bootloader" but really a "If Debian is to follow industry standards for the Raspberry Pi 4 and other UEFI platforms that use a Broadcom Genet NIC, then it should provide the functionality requested above, for which we have conveniently provided a patch". So, if the integration of the proposed patch into the kernel used by the next Debian ISO release is going to be delayed further, I would really like the Debian maintainers to explain why that is the case. We have been *EXCEEDINGLY* patient about this and waited in the hope that Debian maintainers would understand the urgency, but, seeing that Debian 10.4, which is planned to be released in 2 days, does not appear to integrate the patch we proposed (either that or this bug tracker was not updated as it should), I feel that we might as well tell the thousands of Raspberry Pi 4 users who we are seeing downloading the UEFI firmware in the hope of using it to install GNU/Linux, that they should just forget about Debian, because it seems Debian maintainers have either very little interest in ensuring that their OS can be installed on what is, by far, be the most popular ARM64 platforms out there, or have failed to grasp the implications of not applying the patch that can solve this very important issue and which was proposed *MONTHS* ago... Regards, /Pete [1] https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4
Bug#956868: Use Realtek's r8101 driver
Hello, Thanks for confirming the new kernel has dropped support for this ethernet controller. This arises some questions, tough: 1. The chipset is not that old (?). It comes embedded on a Compaq Mini CQ10-520ES (netbook), bought circa mid' 2011. 2. As many users are not able to manually compile the driver, could you please reconsider your decision of dropping this chipset? Having an ethernet link available for a first Debian install (or whatever distribution) is a must under some restricted environments. 3. Can you please pinpoint the latest kernel version where this chipset was last supported? Thanks, -- Camaleón
