Bug#752701: initramfs-tools: Does not load firmware for in kernel wireless drivers
Wed, 25 Jun 2014 22:43:56 +0200 maximilian attems wrote: We don'T support NFS over wireless there would be no other reason to put it there Another reason is that if wireless firmware is not loaded in the initramfs then it does not get loaded at all. This is a general problem that I have had now with three different wireless drivers. The problem is that the built in wireless driver starts working before the disk file systems have been mounted, and hence the firmware is not available. It is a bug, not a matter of a user setting. Whether the solution adopted lies with the initramfs or somewhere else is something for developers to decide. How can I progress this? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53abe881.7030...@dpets.co.uk
Bug#752701: initramfs-tools: Does not load firmware for in kernel wireless drivers
On Thu, Jun 26, 2014 at 10:31:45AM +0100, John Talbut wrote: Wed, 25 Jun 2014 22:43:56 +0200 maximilian attems wrote: This is a general problem that I have had now with three different wireless drivers. The problem is that the built in wireless driver starts working before the disk file systems have been mounted, and hence the firmware is not available. linux images by Debian have no built in wireless. again this is a user support question, please ask on mailing list not by bug report. best, -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626094343.gd8...@stro.at
Bug#748609: Non-FIXed in Linux Kernel v3.14.8 2014-06-16 Fw: hyperv: Change the receive buffer size for legacy hosts Re: Regression in hyperv network driver in 3.14 Fw: Debian Bug#748609: ( 3.14-0 : H
Hi! == It defines a NETVSC_RECEIVE_BUFFER_SIZE_LEGACY of 15MB instead of 16MB used on newer versions of this Hypervisor. Technically this also affects Jessie when running as guest on Windows Server 2008 R2. == Not id=af9893a3dc790ae0c4d3e68adde12bc3cb9c63fa but id=99d3016de4f2a29635f5382b0e9bd0e5f2151487: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/hyperv?id=99d3016de4f2a29635f5382b0e9bd0e5f2151487 == . . . #define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024*16) /* 16MB */ +#define NETVSC_RECEIVE_BUFFER_SIZE_LEGACY (1024*1024*15) /* 15MB */ . . . + if (net_device-nvsp_version = NVSP_PROTOCOL_VERSION_2) + net_device-recv_buf_size = NETVSC_RECEIVE_BUFFER_SIZE_LEGACY; + else + net_device-recv_buf_size = NETVSC_RECEIVE_BUFFER_SIZE; + ret = netvsc_init_recv_buf(device); cleanup: @@ -898,7 +903,6 @@ int netvsc_device_add(struct hv_device *device, void *additional_info) ndev = net_device-ndev; /* Initialize the NetVSC channel extension */ - net_device-recv_buf_size = NETVSC_RECEIVE_BUFFER_SIZE; . . . == Best regards, Victor Miasnikov Blog: http://vvm.blog.tut.by/ P.S. and see: - Original Message - From: Victor Miasnikov To: linux-ker...@vger.kernel.org; David S. Miller; Greg KH; Haiyang Zhang Cc: . . . Sent: Thursday, June 26, 2014 11:19 AM Subject: Non-FIXed in Linux Kernel v3.14.8 2014-06-16 Fw: hyperv: Change the receive buffer size for legacy hosts Re: Regression in hyperv network driver in 3.14 Fw: Debian Bug#748609: ( 3.14-0 : Hyper-V netvsc no networking) Hi! 2014-03-09 https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/hyperv?id=99d3016de4f2a29635f5382b0e9bd0e5f2151487 hyperv: Change the receive buffer size for legacy hosts + Haiyang Zhang write on May 27, 2014 6:22 PM: I ( Haiyang Zhang) will ask the maintainer ( for backport id=99d3016de4f2a29635f5382b0e9bd0e5f2151487 ), see if it will be in next 3.14 update as well. + Haiyang Zhang on June 25, 2014 19:14 ( UTC+3) : I ( Haiyang Zhang) have requested that patch for stable branch, but . . . ( VVM: skipped by me) V.V.M.: Problem Non-FIXed in Linux Kernel v3.14.8 2014-06-16 :-( Reason? Roadmap? ( Without this patch ( i.e. in kernel v3.14 ) LANCard driver/.ko is simply not start in case VM with OS Linux on Hyper-V host with Win 2008 R2 ( Win 2012 R2 not affected) ) Best regards, Victor Miasnikov Blog: http://vvm.blog.tut.by/ P.S. About rules: IMHO, In fact _all_ patch equal 16-1 = 15 :-) i.e. -#define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024*16) /* 16MB */ +#define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024*15) /* 15MB */ - Original Message - From: Victor Miasnikov To: Haiyang Zhang; Abhishek Gupta (LIS) Cc: KY Srinivasan; Кулешов Андрей Анатольевич; Mathieu Simon; Bernhard Walle Sent: Wednesday, June 25, 2014 1:19 PM Subject: Non-FIXed in Linux Kernel v3.14.8 2014-06-16 Fw: hyperv: Change the receive buffer size for legacy hosts Re: Regression in hyperv network driver in 3.14 Fw: Debian Bug#748609: (linux-image-3.14-0.bpo.1-amd64: Hyper-V netvsc no networking) Hi! Problem Non-FIXed in Linux Kernel v3.14.8 2014-06-16 :-( Reason? Roadmap? . . . == cat /var/log/syslog hv_netvsc vmbus_0_9 (unregistered net_device): Unable to complete receive buffer initialization with NetVsp - status 2 hv_netvsc vmbus_0_9 (unregistered net_device): unable to connect to NetVSP - -22 hv_netvsc vmbus_0_9 (unregistered net_device): unable to add netvsc device (ret -22) hv_vmbus: probe failed for device vmbus_0_9 (-22) hv_netvsc: probe of vmbus_0_9 failed with error -22 == == It defines a NETVSC_RECEIVE_BUFFER_SIZE_LEGACY of 15MB instead of 16MB used on newer versions of this Hypervisor. Technically this also affects Jessie when running as guest on Windows Server 2008 R2. == == Yes, this commit is in stable tree: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/hyperv?id=99d3016de4f2a29635f5382b0e9bd0e5f2151487 hyperv: Change the receive buffer size for legacy hosts I will ask the maintainer, see if it will be in next 3.14 update as well. Thanks, - Haiyang == Best regards, Victor Miasnikov Blog: http://vvm.blog.tut.by/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9f909ecfdd7e4592bae75b4c4f56d...@local.st.by
Re: Bug#752742: udev: fails to boot if CONFIG_UEVENT_HELPER is disabled
Am 26.06.2014 08:43, schrieb Arto Jantunen: Package: udev Version: 204-12 Severity: normal Tags: patch The udev initramfs script is executed with set -e, and attempts to clear out the contents of /sys/kernel/uevent_helper at boot. If CONFIG_UEVENT_HELPER is not set this file doesn't exist, setting it fails and the boot stops. The script should check that the file exists and is writable before trying to write to it. A trivial patch to do that is attached. Makes sense. Additionally udev.init and udev.postinst have checks for the existence of that file which would stop udev from being started under sysvinit if that compatibility option is not set. I'm not entirely sure what should be done about them. Seems reasonable to drop the if [ ! -e /sys/kernel/uevent_helper ]; then echo udev requires hotplug support, not started. return 1 fi checks from postinst and the udev SysV init script. udev has been switched over to use the netlink based interface for communicating with the kernel a long time ago. Marco, at least I don't see a good reason to keep them. Do you agree? The kernel team should possibly be notified about keeping this option enabled for the jessie release to avoid breaking partial upgrades. I don't think they have any plans to change that. But CCed the kernel team just in case. Just curious, was this triggered by [1]. Usually CONFIG_UEVENT_HELPER is set (at least by distros for compat reasons) and contains . Cheers, Michael [1] http://www.spinics.net/linux/lists/kernel/msg1770793.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#752578: WiFi deauthenticated
I believe this snippet of the logs shows the disconnection event: [18516.133492] wlan0: deauthenticated from 28:28:5d:92:bc:c4 (Reason: 15) [18516.253865] cfg80211: Calling CRDA to update world regulatory domain [18516.264247] cfg80211: World regulatory domain updated: [18516.264254] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [18516.264258] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm) [18516.264262] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm) [18516.264265] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm) [18516.264268] cfg80211: (517 KHz - 525 KHz @ 8 KHz), (N/A, 2000 mBm) [18516.264271] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm) [18516.264274] cfg80211: (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 mBm) [18519.779058] wlan0: authenticate with 28:28:5d:92:bc:c4 [18519.796725] wlan0: send auth to 28:28:5d:92:bc:c4 (try 1/3) [18519.980289] wlan0: send auth to 28:28:5d:92:bc:c4 (try 2/3) [18520.157744] wlan0: send auth to 28:28:5d:92:bc:c4 (try 3/3) [18520.376222] wlan0: authentication with 28:28:5d:92:bc:c4 timed out [18523.931169] wlan0: authenticate with 28:28:5d:92:bc:c4 [18523.948551] wlan0: direct probe to 28:28:5d:92:bc:c4 (try 1/3) [18524.150135] wlan0: direct probe to 28:28:5d:92:bc:c4 (try 2/3) [18524.354148] wlan0: direct probe to 28:28:5d:92:bc:c4 (try 3/3) [18524.558129] wlan0: authentication with 28:28:5d:92:bc:c4 timed out [18528.062962] wlan0: authenticate with 28:28:5d:92:bc:c4 [18528.080447] wlan0: direct probe to 28:28:5d:92:bc:c4 (try 1/3) [18528.281984] wlan0: direct probe to 28:28:5d:92:bc:c4 (try 2/3) [18528.485984] wlan0: direct probe to 28:28:5d:92:bc:c4 (try 3/3) [18528.689969] wlan0: authentication with 28:28:5d:92:bc:c4 timed out
Bug#752789: initramfs-tools: mkinitramfs doesn't honor /usr/share/initramfs-tools/modules
Package: initramfs-tools Version: 0.115 Severity: normal Hi, mkinitramfs (the tool that is called from update-initramfs) doesn't honor /usr/share/initramfs-tools/modules, it only honors /etc/initramfs-tools/modules and /usr/share/initramfs-tools/modules.d. This is unfortunate because /usr/share/initramfs-tools/modules explicitly states that the modules listed in that file are included in the initramfs. The file /usr/share/initramfs-tools/modules should therefore be either added to the list of files that are processed or removed altogether. Regards, Lukas -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cacb1aesjvdjpponjcmccegrjqus+wzqx-vy2+zd9uyav0ns...@mail.gmail.com
Processed: Re: initramfs-tools: Shell spawned despite panic=0
Processing control commands: found -1 0.115 Bug #751488 [initramfs-tools] initramfs-tools: Shell spawned despite panic=0 Marked as found in versions initramfs-tools/0.115. -- 751488: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751488 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b751488.140379704825976.transcr...@bugs.debian.org
Bug#751488: initramfs-tools: Shell spawned despite panic=0
Control: found -1 0.115 This bug is still present in the latest available version. Regards, Lukas -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACB1AevZvjWgF1dW9ho-vMS=dfq7faucsw-wok_q_hyeu8k...@mail.gmail.com
Bug#749688: linux: add mips64 and mips64el support
Hi, On Sat, Jun 14, 2014 at 12:36:58AM +0800, Yunqiang Su wrote: New 'add mips64 support': I forgot to add mips64 and mips64el into debian/config/defines I had a look at the patches, and they look fine to me except a few minor things (see the comments below), though I haven't done any test build yet. Once you have updated them, I'll test them and commit them if they are fine. I have seen they are against the experimental branch. That's fine to me (and probably better as so far we have loongson 3 support only there), but note that until it is decided if jessie will be shipped with 3.14 or 3.16, we are not sure your changes will land in sid soon. diff --git a/debian/config/mipsel/defines b/debian/config/mipsel/defines index eea73f0..d968393 100644 --- a/debian/config/mipsel/defines +++ b/debian/config/mipsel/defines @@ -20,32 +20,37 @@ hardware: BCM91250A hardware-long: Broadcom BCM91250A systems (aka SWARM) [sb1-bcm91250a_image] -configs: mips/config.sb1-bcm91250a +configs: kernelarch-mips/config.sb1-bcm91250a [4kc-malta_description] hardware: MIPS Malta hardware-long: MIPS Malta boards [4kc-malta_image] -configs: mips/config.4kc-malta +configs: kernelarch-mips/config.4kc-malta [5kc-malta_description] hardware: MIPS Malta (64-bit) hardware-long: MIPS Malta boards (64-bit) [5kc-malta_image] -configs: mips/config.5kc-malta +configs: kernelarch-mips/config.5kc-malta [loongson-2e_description] hardware: Loongson 2E hardware-long: Lemote Loongson 2E systems +[loongson-2e_image] +configs: kernelarch-mips/config.loongson-2e + [loongson-2f_description] hardware: Loongson 2F hardware-long: Lemote Loongson 2F systems [loongson-2f_image] +initramfs: true recommends: libc6-loongson2f +configs: kernelarch-mips/config.loongson-2f Why adding an initramfs here? I think we should switch to initramfs for all flavors, but we have to think about the transition and do it consistently. In any case this has to be done in a separate patch, the mips64 patches should not change the existing flavours. [loongson-3_description] hardware: Loongson 3A/3B @@ -53,3 +58,4 @@ hardware-long: Loongson 3A or 3B based systems (e.g. from Loongson or Lemote) [loongson-3_image] initramfs: true +configs: kernelarch-mips/config.loongson-3 diff --git a/debian/config/mips64/defines b/debian/config/mips64/defines new file mode 100644 index 000..c42abad --- /dev/null +++ b/debian/config/mips64/defines @@ -0,0 +1,26 @@ +[base] +flavours: + sb1-bcm91250a + octeon +kernel-arch: mips + +[build] +image-file: vmlinux + +[image] +initramfs: true As Ben said, it looks like a good idea to enable initramfs by default. However I think (but I haven't tested) that it is already the default so this line is probably useless +install-stem: vmlinux + +[sb1-bcm91250a_description] +hardware: BCM91250A +hardware-long: Broadcom BCM91250A systems (aka SWARM) + +[sb1-bcm91250a_image] +configs: kernelarch-mips/config.sb1-bcm91250a This platform is a MIPS64 one without the R2 instructions, while the Debian mips64el port is AFAIK a MIPS64R2 only port. +[octeon_description] +hardware: Octeon +hardware-long: Cavium Networks Octeon + +[octeon_image] +configs: kernelarch-mips/config.octeon diff --git a/debian/config/mips64el/defines b/debian/config/mips64el/defines new file mode 100644 index 000..5c9bfb0 --- /dev/null +++ b/debian/config/mips64el/defines @@ -0,0 +1,51 @@ +[base] +flavours: + sb1-bcm91250a + loongson-2e + loongson-2f + loongson-3 + octeon +kernel-arch: mips + +[build] +image-file: vmlinux + +[image] +initramfs: true Same comment as for mips64el. +install-stem: vmlinux + +[sb1-bcm91250a_description] +hardware: BCM91250A +hardware-long: Broadcom BCM91250A systems (aka SWARM) + +[sb1-bcm91250a_image] +configs: kernelarch-mips/config.sb1-bcm91250a + +[loongson-2e_description] +hardware: Loongson 2E +hardware-long: Lemote Loongson 2E systems + +[loongson-2e_image] +configs: kernelarch-mips/config.loongson-2e + +[loongson-2f_description] +hardware: Loongson 2F +hardware-long: Lemote Loongson 2F systems + +[loongson-2f_image] +recommends: libc6-loongson2f +configs: kernelarch-mips/config.loongson-2f Same comment about R2 instruction set. +[loongson-3_description] +hardware: Loongson 3A/3B +hardware-long: Loongson 3A or 3B based systems (e.g. from Loongson or Lemote) + +[loongson-3_image] +configs: kernelarch-mips/config.loongson-3 + +[octeon_description] +hardware: Octeon +hardware-long: Cavium Networks Octeon + +[octeon_image] +configs: kernelarch-mips/config.octeon diff --git a/debian/config/defines b/debian/config/defines index e292cfa..25e1150 100644 diff --git a/debian/installer/mipsel/package-list b/debian/installer/mipsel/package-list index b51e0a5..c94fcfd 100644 --- a/debian/installer/mipsel/package-list +++ b/debian/installer/mipsel/package-list @@ -4,8
Bug#752578: Info received (WiFi deauthenticated)
APT updated to 3.14-1-amd64 and fault still present.
Re: Bug#752742: udev: fails to boot if CONFIG_UEVENT_HELPER is disabled
On Thu, 2014-06-26 at 15:05 +0200, Michael Biebl wrote: Am 26.06.2014 08:43, schrieb Arto Jantunen: Package: udev Version: 204-12 Severity: normal Tags: patch The udev initramfs script is executed with set -e, and attempts to clear out the contents of /sys/kernel/uevent_helper at boot. If CONFIG_UEVENT_HELPER is not set this file doesn't exist, setting it fails and the boot stops. The script should check that the file exists and is writable before trying to write to it. A trivial patch to do that is attached. Makes sense. Additionally udev.init and udev.postinst have checks for the existence of that file which would stop udev from being started under sysvinit if that compatibility option is not set. I'm not entirely sure what should be done about them. Seems reasonable to drop the if [ ! -e /sys/kernel/uevent_helper ]; then echo udev requires hotplug support, not started. return 1 fi checks from postinst and the udev SysV init script. udev has been switched over to use the netlink based interface for communicating with the kernel a long time ago. Marco, at least I don't see a good reason to keep them. Do you agree? The kernel team should possibly be notified about keeping this option enabled for the jessie release to avoid breaking partial upgrades. I don't think they have any plans to change that. But CCed the kernel team just in case. I wasn't aware it could be disabled... indeed it still can't be in released kernel versions, but I see it can be in Linux 3.16. To avoid upgrade problems, I'm happy to keep it enabled for jessie if we use 3.16, but would like to disable it for jessie+1. Ben. Just curious, was this triggered by [1]. Usually CONFIG_UEVENT_HELPER is set (at least by distros for compat reasons) and contains . Cheers, Michael [1] http://www.spinics.net/linux/lists/kernel/msg1770793.html -- Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong. signature.asc Description: This is a digitally signed message part
Bug#749688: linux: add mips64 and mips64el support
On Fri, Jun 27, 2014 at 2:17 AM, Aurelien Jarno aurel...@aurel32.net wrote: Hi, On Sat, Jun 14, 2014 at 12:36:58AM +0800, Yunqiang Su wrote: New 'add mips64 support': I forgot to add mips64 and mips64el into debian/config/defines I had a look at the patches, and they look fine to me except a few minor things (see the comments below), though I haven't done any test build yet. Once you have updated them, I'll test them and commit them if they are fine. I have seen they are against the experimental branch. That's fine to me (and probably better as so far we have loongson 3 support only there), but note that until it is decided if jessie will be shipped with 3.14 or 3.16, we are not sure your changes will land in sid soon. diff --git a/debian/config/mipsel/defines b/debian/config/mipsel/defines index eea73f0..d968393 100644 --- a/debian/config/mipsel/defines +++ b/debian/config/mipsel/defines @@ -20,32 +20,37 @@ hardware: BCM91250A hardware-long: Broadcom BCM91250A systems (aka SWARM) [sb1-bcm91250a_image] -configs: mips/config.sb1-bcm91250a +configs: kernelarch-mips/config.sb1-bcm91250a [4kc-malta_description] hardware: MIPS Malta hardware-long: MIPS Malta boards [4kc-malta_image] -configs: mips/config.4kc-malta +configs: kernelarch-mips/config.4kc-malta [5kc-malta_description] hardware: MIPS Malta (64-bit) hardware-long: MIPS Malta boards (64-bit) [5kc-malta_image] -configs: mips/config.5kc-malta +configs: kernelarch-mips/config.5kc-malta [loongson-2e_description] hardware: Loongson 2E hardware-long: Lemote Loongson 2E systems +[loongson-2e_image] +configs: kernelarch-mips/config.loongson-2e + [loongson-2f_description] hardware: Loongson 2F hardware-long: Lemote Loongson 2F systems [loongson-2f_image] +initramfs: true recommends: libc6-loongson2f +configs: kernelarch-mips/config.loongson-2f Why adding an initramfs here? I think we should switch to initramfs for all flavors, but we have to think about the transition and do it consistently. In any case this has to be done in a separate patch, the mips64 patches should not change the existing flavours. [loongson-3_description] hardware: Loongson 3A/3B @@ -53,3 +58,4 @@ hardware-long: Loongson 3A or 3B based systems (e.g. from Loongson or Lemote) [loongson-3_image] initramfs: true +configs: kernelarch-mips/config.loongson-3 diff --git a/debian/config/mips64/defines b/debian/config/mips64/defines new file mode 100644 index 000..c42abad --- /dev/null +++ b/debian/config/mips64/defines @@ -0,0 +1,26 @@ +[base] +flavours: + sb1-bcm91250a + octeon +kernel-arch: mips + +[build] +image-file: vmlinux + +[image] +initramfs: true As Ben said, it looks like a good idea to enable initramfs by default. However I think (but I haven't tested) that it is already the default so this line is probably useless +install-stem: vmlinux + +[sb1-bcm91250a_description] +hardware: BCM91250A +hardware-long: Broadcom BCM91250A systems (aka SWARM) + +[sb1-bcm91250a_image] +configs: kernelarch-mips/config.sb1-bcm91250a This platform is a MIPS64 one without the R2 instructions, while the Debian mips64el port is AFAIK a MIPS64R2 only port. No, it is not mips64r2 port, it's mips3 port. I pushed all patches for mips3, include gcc-4.8/4.9. I am testing mips64r2 in my private buildd for now. Finally the official port will be mips3. +[octeon_description] +hardware: Octeon +hardware-long: Cavium Networks Octeon + +[octeon_image] +configs: kernelarch-mips/config.octeon diff --git a/debian/config/mips64el/defines b/debian/config/mips64el/defines new file mode 100644 index 000..5c9bfb0 --- /dev/null +++ b/debian/config/mips64el/defines @@ -0,0 +1,51 @@ +[base] +flavours: + sb1-bcm91250a + loongson-2e + loongson-2f + loongson-3 + octeon +kernel-arch: mips + +[build] +image-file: vmlinux + +[image] +initramfs: true Same comment as for mips64el. +install-stem: vmlinux + +[sb1-bcm91250a_description] +hardware: BCM91250A +hardware-long: Broadcom BCM91250A systems (aka SWARM) + +[sb1-bcm91250a_image] +configs: kernelarch-mips/config.sb1-bcm91250a + +[loongson-2e_description] +hardware: Loongson 2E +hardware-long: Lemote Loongson 2E systems + +[loongson-2e_image] +configs: kernelarch-mips/config.loongson-2e + +[loongson-2f_description] +hardware: Loongson 2F +hardware-long: Lemote Loongson 2F systems + +[loongson-2f_image] +recommends: libc6-loongson2f +configs: kernelarch-mips/config.loongson-2f Same comment about R2 instruction set. +[loongson-3_description] +hardware: Loongson 3A/3B +hardware-long: Loongson 3A or 3B based systems (e.g. from Loongson or Lemote) + +[loongson-3_image] +configs: kernelarch-mips/config.loongson-3 + +[octeon_description] +hardware: Octeon +hardware-long: Cavium Networks Octeon + +[octeon_image] +configs: kernelarch-mips/config.octeon diff --git a/debian/config/defines
