Re: Ability to further support 32bit architectures
rhys 于2024年1月13日周六 11:27写道： > > Let me try again, following up on the previous thread, but removing most of > the irrelevant history. > > If I have a 32-bit Intel system that is currently supported on bookworm > (currently running bullseye, but I can upgrade it), is that of use to anyone > as a native build platform for 32-bit binary packages for Debian? > You are yet another person who is confused by the name "i386" vs "amd64". AMD64 is just the named due to that X86 is extended to X86-64 by AMD *first*. It means that "Intel 64" or "EM64T" is almost same with "AMD64". So, you, the Intel CPU user, should use "AMD64", if you don't clearly know that your Intel CPU is 32bit only. For more clear, for Debian, "AMD64" is equal to X86-64. https://en.wikipedia.org/wiki/X86-64 -- YunQiang Su
Re: Ability to further support 32bit architectures
于2024年1月12日周五 23:59写道： > > Keeping in mind that I am new to this arena... > > I have some Intel systems - both 64-bit and 32-bit - that I might be able to > use as build platforms. > I guess all of your hardwares are 64bit. You setup different OS on them. > What does the Debian team need from me to be able to use these systems? > It's not about performance of hardware. It is about some limitation of 32bit. 2 examples for it: 1. if we use 32bit value for time, it will overflow in 2038, then your time will be shown as 1900. https://en.wikipedia.org/wiki/Year_2038_problem 2. A single process (or maybe APP, not precisely), can only use UP to 4GiB RAM. In fact on most system the value is less than 4GiB: on intel32, it is 3GiB on mips32, it is 2GiB But currently, it is not enough, for example, when we build a big APP, it will need much more RAM. The RAM does install in your Rack, but you can NOT use it. https://en.wikipedia.org/wiki/3_GB_barrier > I can't guarantee they'll be FAST, but I'll do what I can to make them > EFFECTIVE. > If you are really need 32bit system. Maybe you can say out why you *REALLY* need it. For most users, the suggestion is: upgrade to 64bit. > --J >
Bug#1043274: kernel handbook: mention dpkg-architecture
Package: debian-kernel-handbook Version: 1.0.21 In 4.5.5. Building packages for one flavour It should mention that we can use dpkg-architecture to support cross-building: For example we can: dpkg-architecture -a mips64el -c \ make -f debian/rules.gen \ binary-arch_mips64el_none_loongson-3 -- YunQiang Su
Bug#1035587: linux: broken AHCI controller on MIPS Loongson 3 (regression from 5.10.162-1)
Aurelien Jarno 于2023年5月6日周六 04:30写道：
>
> Source: linux
> Version: 5.10.178-3
> Severity: important
> X-Debbugs-Cc: d...@debian.org, debian-m...@lists.debian.org, s...@debian.org
>
> Following the point release, the buildd mipsel-osuosl-03.d.o does not
> boot anymore, with errors in the AHCI controller:
>
> [ 35.912147] ata4.00: exception Emask 0x0 SAct 0x2000 SErr 0x0 action
> 0x6 frozen
> [ 35.919769] ata4.00: failed command: WRITE FPDMA QUEUED
> [ 35.924968] ata4.00: cmd 61/20:e8:00:f0:e1/00:00:00:00:00/40 tag 29 ncq
> dma 16384 out
> [ 35.924968] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
> (timeout)
> [ 35.940097] ata4.00: status: { DRDY }
> [ 35.943743] ata4: hard resetting link
>
> While that initially looks like a hardware issue, it appears that
> reverting the kernel to 5.10.162-1 (from 5.10.178-3) fixes the issue.
> Strangely mipsel.osuosl-05.d.o, which seems to be similar hardware (CPU,
> motherboard and SATA drive), does not exhibit the same issue.
>
Maybe the different firmwares are used for them...
CCed Huacai and Jiaxun.
> You'll find attached the output of /proc/cpuinfo, lspci and the full
> boot log.
--
YunQiang Su
Bug#995773: linux-image-5.10.0-8-amd64: NMI panic on HP ProLiant DL380G6 and DL360G7
On Wed, 6 Oct 2021 08:11:05 +0200 Claudio Kuenzler wrote: > I've seen this too and documented my findings here: > https://www.claudiokuenzler.com/blog/1125/debian-11-bullseye-boot-freeze-kernel-panic-hp-proliant-dl380 > > (reason is the hpwdt module) > > This bug is most likely a duplicate of > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898336 where the same > NMI's are reported with Kernel 4.16 but with Kernel 5.10 the boot > issues/crashes seem to be even worse. > > Maintainers, please consider disabling (blacklisting) the hpwdt module by > default (same as Ubuntu). If anyone REALLY needs it, it can be manually > enabled. My HPE ProLiant BL460c Gen9 has the same problem. And with some debug, I find the problem is due to CONFIG_INTEL_IOMMU_DEFAULT_ON=y So, as a workaround, we can use intel_iommu=off kernel option.
Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9
YunQiang Su 于2021年10月22日周五 下午10:36写道： > > Claudio Kuenzler 于2021年10月22日周五 下午2:03写道： > > > > The fact that a later Kernel versions work fine _could_ be because of a > > hpwdt commit after 5.10: > > https://github.com/torvalds/linux/commit/acc195bd2cc48445ea35d00036d8c0afcc4fcc9c#diff-994ee4b010b5c6222ad7a20e160f733401f46894b36fa3e1fb6ffbb48bedb817 > > I have not tested sid or a newer Kernel on our HP machines though. > > If you've compiled your own Kernel and this one works (did your do a > > multiple reboot test?), maybe there's a difference in the Kernel "config"? > > > > What happens if you disable the hpwdt module as mentioned in the other bug > > reports? Does Bullseye with 5.10 and experimental with 5.14 work in this > > case? > > I test upstream linux and debian-linux with the same config. > All of the upstream config works fine, while debian-linux has this problem. > I guess it is due to one patch by Debian. > I find the real problem: it is due to intel_iommu by default. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934309 > -- > YunQiang Su -- YunQiang Su
Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9
Claudio Kuenzler 于2021年10月22日周五 下午2:03写道： > > The fact that a later Kernel versions work fine _could_ be because of a hpwdt > commit after 5.10: > https://github.com/torvalds/linux/commit/acc195bd2cc48445ea35d00036d8c0afcc4fcc9c#diff-994ee4b010b5c6222ad7a20e160f733401f46894b36fa3e1fb6ffbb48bedb817 > I have not tested sid or a newer Kernel on our HP machines though. > If you've compiled your own Kernel and this one works (did your do a multiple > reboot test?), maybe there's a difference in the Kernel "config"? > > What happens if you disable the hpwdt module as mentioned in the other bug > reports? Does Bullseye with 5.10 and experimental with 5.14 work in this case? I test upstream linux and debian-linux with the same config. All of the upstream config works fine, while debian-linux has this problem. I guess it is due to one patch by Debian. -- YunQiang Su
Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9
Claudio Kuenzler 于2021年10月22日周五 下午1:18写道： > > Also look at the following links and compare. Might be related or even the > same as you are seeing: > > https://www.claudiokuenzler.com/blog/1125/debian-11-bullseye-boot-freeze-kernel-panic-hp-proliant-dl380 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898336 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995773 > I built kernel by myself (5.14.12), same version as the current debian sid one. in fact 5.14.14 is also tested. It won't trigger this problem. And I make sure that hpwdt module is loaded. No idea why Debian's kernel cannot work. > > On Thu, Oct 21, 2021 at 10:42 AM Yunqiang Su wrote: >> >> On Fri, 10 Sep 2021 09:40:41 +0800 YunQiang Su wrote: >> > Yunqiang Su 于2021年9月9日周四 上午11:11写道： >> > > >> > > >> > > On Wed, 8 Sep 2021 20:53:27 +0800 YunQiang Su wrote: >> > > > Package: src:linux >> > > > Version: 5.10 >> > > > >> > > > After upgrade to bullseyes' kernel, the system always hang after about >> > > > 10 min >> > > > with an error from IML log >> > > > >> > > > An Unrecoverable System Error (NMI) has occurred (Service Information: >> > > > 0x0008, 0x8948) >> > > > >> > > > Kernel 5.14 from experimental also has this problem. >> > > > Kernel 4.19 works fine. >> > > > Fedora 34 seems to be working well. >> > > >> > > This is the output of dmesg and lspci from both Fedora 34 and Debian >> > > bullseye. >> > > Wish they are useful. >> > > >> > >> > Finally, we find the problem: >> > >> > https://github.com/torvalds/linux/commit/8343b1f8b97ac016150c8303f95b63b20b98edf8 >> > https://github.com/torvalds/linux/commit/65161c35554f7135e6656b3df1ce2c500ca0bdcf >> > >> > In the first patch: >> >They thought `err' is not used at all, and removed it. >> > In the second patch: >> >They add it back and a wrong value "-EINVAL" is given. >> > >> > Better KPI got. >> > >> >> The NICs can be detected now, while the machine continue to hang… >> 4.19.y works fine, while 5.10, 5.14 cannot. >> >> I think that we need more dig. >> >> > > > >> > > > -- >> > > > YunQiang Su >> > > > >> > > > >> > >> > >> > >> > -- >> > YunQiang Su >> > >> > >> -- YunQiang Su
Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9
On Fri, 10 Sep 2021 09:40:41 +0800 YunQiang Su wrote: > Yunqiang Su 于2021年9月9日周四 上午11:11写道： > > > > > > On Wed, 8 Sep 2021 20:53:27 +0800 YunQiang Su wrote: > > > Package: src:linux > > > Version: 5.10 > > > > > > After upgrade to bullseyes' kernel, the system always hang after about 10 > > > min > > > with an error from IML log > > > > > > An Unrecoverable System Error (NMI) has occurred (Service Information: > > > 0x0008, 0x8948) > > > > > > Kernel 5.14 from experimental also has this problem. > > > Kernel 4.19 works fine. > > > Fedora 34 seems to be working well. > > > > This is the output of dmesg and lspci from both Fedora 34 and Debian > > bullseye. > > Wish they are useful. > > > > Finally, we find the problem: > > https://github.com/torvalds/linux/commit/8343b1f8b97ac016150c8303f95b63b20b98edf8 > https://github.com/torvalds/linux/commit/65161c35554f7135e6656b3df1ce2c500ca0bdcf > > In the first patch: >They thought `err' is not used at all, and removed it. > In the second patch: >They add it back and a wrong value "-EINVAL" is given. > > Better KPI got. > The NICs can be detected now, while the machine continue to hang… 4.19.y works fine, while 5.10, 5.14 cannot. I think that we need more dig. > > > > > > -- > > > YunQiang Su > > > > > > > > > > -- > YunQiang Su > >
Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9
Yunqiang Su 于2021年9月9日周四 上午11:11写道： > > > On Wed, 8 Sep 2021 20:53:27 +0800 YunQiang Su wrote: > > Package: src:linux > > Version: 5.10 > > > > After upgrade to bullseyes' kernel, the system always hang after about 10 > > min > > with an error from IML log > > > > An Unrecoverable System Error (NMI) has occurred (Service Information: > > 0x0008, 0x8948) > > > > Kernel 5.14 from experimental also has this problem. > > Kernel 4.19 works fine. > > Fedora 34 seems to be working well. > > This is the output of dmesg and lspci from both Fedora 34 and Debian bullseye. > Wish they are useful. > Finally, we find the problem: https://github.com/torvalds/linux/commit/8343b1f8b97ac016150c8303f95b63b20b98edf8 https://github.com/torvalds/linux/commit/65161c35554f7135e6656b3df1ce2c500ca0bdcf In the first patch: They thought `err' is not used at all, and removed it. In the second patch: They add it back and a wrong value "-EINVAL" is given. Better KPI got. > > > > -- > > YunQiang Su > > > > -- YunQiang Su
Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9
dmesg.debian.xz Description: application/xz dmesg.fedora.xz Description: application/xz lspci.debian.xz Description: application/xz lspci.fedora.xz Description: application/xz On Wed, 8 Sep 2021 20:53:27 +0800 YunQiang Su wrote: > Package: src:linux > Version: 5.10 > > After upgrade to bullseyes' kernel, the system always hang after about 10 min > with an error from IML log > > An Unrecoverable System Error (NMI) has occurred (Service Information: > 0x0008, 0x8948) > > Kernel 5.14 from experimental also has this problem. > Kernel 4.19 works fine. > Fedora 34 seems to be working well. This is the output of dmesg and lspci from both Fedora 34 and Debian bullseye. Wish they are useful. > > -- > YunQiang Su > >
Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9
Package: src:linux Version: 5.10 After upgrade to bullseyes' kernel, the system always hang after about 10 min with an error from IML log An Unrecoverable System Error (NMI) has occurred (Service Information: 0x0008, 0x8948) Kernel 5.14 from experimental also has this problem. Kernel 4.19 works fine. Fedora 34 seems to be working well. -- YunQiang Su
Bug#962485: Bug#983583: FTBFS on mips64el and mipsel
YunQiang Su 于2021年3月29日周一 下午4:56写道：
>
> YunQiang Su 于2021年3月29日周一 下午1:31写道：
> >
> > YunQiang Su 于2021年3月29日周一 下午1:06写道：
> > >
> > > YunQiang Su 于2021年3月29日周一 上午11:45写道：
> > > >
> > > > Shengjing Zhu 于2021年3月29日周一 上午11:40写道：
> > > > >
> > > > > On Mon, Mar 29, 2021 at 09:22:29AM +0800, YunQiang Su wrote:
> > > > > > Shengjing Zhu 于2021年3月28日周日 上午12:12写道：
> > > > > > >
> > > > > > > Control: reopen -1
> > > > > > > Control: severity -1 important
> > > > > > >
> > > > > > > On Sat, Mar 27, 2021 at 11:46 PM Adrian Bunk
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Sat, Feb 27, 2021 at 02:33:38AM +0800, Shengjing Zhu wrote:
> > > > > > > > > Source: golang-github-sylabs-sif
> > > > > > > > > Version: 1.0.9-2
> > > > > > > > > Severity: serious
> > > > > > > > > X-Debbugs-Cc: z...@debian.org
> > > > > > > > >
> > > > > > > > > Tried 3 times on buildd and failed at same test.
> > > > > > > > >
> > > > > > > > > === RUN TestAddDelObject
> > > > > > > > > unexpected fault address 0xffc8a0c000
> > > > > > > > > fatal error: fault
> > > > > > > > > [signal SIGSEGV: segmentation violation code=0x2
> > > > > > > > > addr=0xffc8a0c000 pc=0x12007ebe4]
> > > > > > > > >
> > > > > > > > > goroutine 22 [running]:
> > > > > > > > > runtime.throw(0x1201b74ed, 0x5)
> > > > > > > > > /usr/lib/go-1.15/src/runtime/panic.go:1116 +0x6c
> > > > > > > > > fp=0xce3430 sp=0xce3408 pc=0x120040afc
> > > > > > > > > runtime.sigpanic()
> > > > > > > > >
> > > > > > > > > Since it has been built on mipsx before, the failure will
> > > > > > > > > cause it impossible
> > > > > > > > > to fix issue later on these arch.
> > > > > > > > >
> > > > > > > > > It should either be removed from these arch or get fixed.
> > > > > > > >
> > > > > > > > This appears to be fixed now:
> > > > > > > > https://buildd.debian.org/status/package.php?p=golang-github-sylabs-sif
> > > > > > >
> > > > > > > The difference between these builds, seems to be a 5.10 kernel and
> > > > > > > 4.19 kernel on buildd.
> > > > > > >
> > > > > > > I'll reopen this but downgrade the severity, and loop
> > > > > > > debian-mips@ to
> > > > > > > see if it's regression on the kernel side.
> > > > > > >
> > > > > >
> > > > > > And the CPUs are different: Cavium for good and Loongson3A3000 is
> > > > > > bad.
> > > > > >
> > > > >
> > > > > On
> > > > > https://buildd.debian.org/status/logs.php?pkg=golang-github-sylabs-sif=1.0.9-2%2Bb2=mips64el
> > > > >
> > > > > The failed buildd are: mipsel-manda-04, succeeded one are
> > > > > mipsel-aql-01.
> > > > > From the build log,
> > > > >
> > > > > mipsel-manda-04: Kernel: Linux 5.10.0-0.bpo.3-loongson-3
> > > > > mipsel-aql-01: Kernel: Linux 4.19.0-16-loongson-3
> > > > >
> > > >
> > > > Ohh, my mistake: mips-aql-01 vs mipsel-aql-01 ;)
> > > >
> > >
> > > WIth some test.
> > >
> > > This problem is also about O32_FP64 support option.
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962485
> > >
> > > It is quite strange this option may effect mips64el.
> > > Anyway, lets revert it.
> > >
> > > I will continue to dig the real problem.
> > >
> >
> > E, the problem is about Loongson 3A 1000 vs Loongson 3A2000/3000.
> > I test it on
> >
> > 3B1500 + O32_FP64-> workable
> > 3B1500 + nO32_FP64-> workable
> > 3A2000 + O32_FP64-> fail
> > 3A2000 + nO32_FP64-> fail
> >
>
> Sorry, it is not about O32_FP64, it is about memory region.
> Loongson 3A2000+ supports RI/XI, which stop the access of some memory region.
>
> The problem is about Go itself: why it map the datafile writeonly.
>2
I figure out a patch, with which it can build now:
--- golang-github-sylabs-sif-1.0.9/pkg/sif/load.go 2019-12-19
19:58:23.0 +
+++ golang-github-sylabs-sif-1.0.9-patched/pkg/sif/load.go
2021-03-29 09:49:44.789742245 +
@@ -92,7 +92,8 @@
flags := syscall.MAP_PRIVATE
if !rdonly {
- prot = syscall.PROT_WRITE
+ prot = syscall.PROT_WRITE | syscall.PROT_READ
+ // prot = syscall.PROT_WRITE
flags = syscall.MAP_SHARED
}
mmap(2) says that
On some hardware architectures (e.g., i386), PROT_WRITE implies
PROT_READ. It is architecture dependent whether PROT_READ
implies PROT_EXEC or not. Portable programs should always set
PROT_EXEC if they intend to execute code in the new mapping.
So, I guess it is due to architecture differences.
> > >
> > > > > It doesn't seem to have Cavium CPU here.
> > > > >
> > > >
> > > >
> > > > --
> > > > YunQiang Su
> > >
> > >
> > >
> > > --
> > > YunQiang Su
> >
> >
> >
> > --
> > YunQiang Su
>
>
>
> --
> YunQiang Su
--
YunQiang Su
Bug#962485: Bug#983583: FTBFS on mips64el and mipsel
YunQiang Su 于2021年3月29日周一 下午1:31写道： > > YunQiang Su 于2021年3月29日周一 下午1:06写道： > > > > YunQiang Su 于2021年3月29日周一 上午11:45写道： > > > > > > Shengjing Zhu 于2021年3月29日周一 上午11:40写道： > > > > > > > > On Mon, Mar 29, 2021 at 09:22:29AM +0800, YunQiang Su wrote: > > > > > Shengjing Zhu 于2021年3月28日周日 上午12:12写道： > > > > > > > > > > > > Control: reopen -1 > > > > > > Control: severity -1 important > > > > > > > > > > > > On Sat, Mar 27, 2021 at 11:46 PM Adrian Bunk > > > > > > wrote: > > > > > > > > > > > > > > On Sat, Feb 27, 2021 at 02:33:38AM +0800, Shengjing Zhu wrote: > > > > > > > > Source: golang-github-sylabs-sif > > > > > > > > Version: 1.0.9-2 > > > > > > > > Severity: serious > > > > > > > > X-Debbugs-Cc: z...@debian.org > > > > > > > > > > > > > > > > Tried 3 times on buildd and failed at same test. > > > > > > > > > > > > > > > > === RUN TestAddDelObject > > > > > > > > unexpected fault address 0xffc8a0c000 > > > > > > > > fatal error: fault > > > > > > > > [signal SIGSEGV: segmentation violation code=0x2 > > > > > > > > addr=0xffc8a0c000 pc=0x12007ebe4] > > > > > > > > > > > > > > > > goroutine 22 [running]: > > > > > > > > runtime.throw(0x1201b74ed, 0x5) > > > > > > > > /usr/lib/go-1.15/src/runtime/panic.go:1116 +0x6c > > > > > > > > fp=0xce3430 sp=0xce3408 pc=0x120040afc > > > > > > > > runtime.sigpanic() > > > > > > > > > > > > > > > > Since it has been built on mipsx before, the failure will cause > > > > > > > > it impossible > > > > > > > > to fix issue later on these arch. > > > > > > > > > > > > > > > > It should either be removed from these arch or get fixed. > > > > > > > > > > > > > > This appears to be fixed now: > > > > > > > https://buildd.debian.org/status/package.php?p=golang-github-sylabs-sif > > > > > > > > > > > > The difference between these builds, seems to be a 5.10 kernel and > > > > > > 4.19 kernel on buildd. > > > > > > > > > > > > I'll reopen this but downgrade the severity, and loop debian-mips@ > > > > > > to > > > > > > see if it's regression on the kernel side. > > > > > > > > > > > > > > > > And the CPUs are different: Cavium for good and Loongson3A3000 is bad. > > > > > > > > > > > > > On > > > > https://buildd.debian.org/status/logs.php?pkg=golang-github-sylabs-sif=1.0.9-2%2Bb2=mips64el > > > > > > > > The failed buildd are: mipsel-manda-04, succeeded one are mipsel-aql-01. > > > > From the build log, > > > > > > > > mipsel-manda-04: Kernel: Linux 5.10.0-0.bpo.3-loongson-3 > > > > mipsel-aql-01: Kernel: Linux 4.19.0-16-loongson-3 > > > > > > > > > > Ohh, my mistake: mips-aql-01 vs mipsel-aql-01 ;) > > > > > > > WIth some test. > > > > This problem is also about O32_FP64 support option. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962485 > > > > It is quite strange this option may effect mips64el. > > Anyway, lets revert it. > > > > I will continue to dig the real problem. > > > > E, the problem is about Loongson 3A 1000 vs Loongson 3A2000/3000. > I test it on > > 3B1500 + O32_FP64-> workable > 3B1500 + nO32_FP64-> workable > 3A2000 + O32_FP64-> fail > 3A2000 + nO32_FP64-> fail > Sorry, it is not about O32_FP64, it is about memory region. Loongson 3A2000+ supports RI/XI, which stop the access of some memory region. The problem is about Go itself: why it map the datafile writeonly. > > > > > > It doesn't seem to have Cavium CPU here. > > > > > > > > > > > > > -- > > > YunQiang Su > > > > > > > > -- > > YunQiang Su > > > > -- > YunQiang Su -- YunQiang Su
Bug#962485: Bug#983583: FTBFS on mips64el and mipsel
YunQiang Su 于2021年3月29日周一 下午1:06写道： > > YunQiang Su 于2021年3月29日周一 上午11:45写道： > > > > Shengjing Zhu 于2021年3月29日周一 上午11:40写道： > > > > > > On Mon, Mar 29, 2021 at 09:22:29AM +0800, YunQiang Su wrote: > > > > Shengjing Zhu 于2021年3月28日周日 上午12:12写道： > > > > > > > > > > Control: reopen -1 > > > > > Control: severity -1 important > > > > > > > > > > On Sat, Mar 27, 2021 at 11:46 PM Adrian Bunk wrote: > > > > > > > > > > > > On Sat, Feb 27, 2021 at 02:33:38AM +0800, Shengjing Zhu wrote: > > > > > > > Source: golang-github-sylabs-sif > > > > > > > Version: 1.0.9-2 > > > > > > > Severity: serious > > > > > > > X-Debbugs-Cc: z...@debian.org > > > > > > > > > > > > > > Tried 3 times on buildd and failed at same test. > > > > > > > > > > > > > > === RUN TestAddDelObject > > > > > > > unexpected fault address 0xffc8a0c000 > > > > > > > fatal error: fault > > > > > > > [signal SIGSEGV: segmentation violation code=0x2 > > > > > > > addr=0xffc8a0c000 pc=0x12007ebe4] > > > > > > > > > > > > > > goroutine 22 [running]: > > > > > > > runtime.throw(0x1201b74ed, 0x5) > > > > > > > /usr/lib/go-1.15/src/runtime/panic.go:1116 +0x6c > > > > > > > fp=0xce3430 sp=0xce3408 pc=0x120040afc > > > > > > > runtime.sigpanic() > > > > > > > > > > > > > > Since it has been built on mipsx before, the failure will cause > > > > > > > it impossible > > > > > > > to fix issue later on these arch. > > > > > > > > > > > > > > It should either be removed from these arch or get fixed. > > > > > > > > > > > > This appears to be fixed now: > > > > > > https://buildd.debian.org/status/package.php?p=golang-github-sylabs-sif > > > > > > > > > > The difference between these builds, seems to be a 5.10 kernel and > > > > > 4.19 kernel on buildd. > > > > > > > > > > I'll reopen this but downgrade the severity, and loop debian-mips@ to > > > > > see if it's regression on the kernel side. > > > > > > > > > > > > > And the CPUs are different: Cavium for good and Loongson3A3000 is bad. > > > > > > > > > > On > > > https://buildd.debian.org/status/logs.php?pkg=golang-github-sylabs-sif=1.0.9-2%2Bb2=mips64el > > > > > > The failed buildd are: mipsel-manda-04, succeeded one are mipsel-aql-01. > > > From the build log, > > > > > > mipsel-manda-04: Kernel: Linux 5.10.0-0.bpo.3-loongson-3 > > > mipsel-aql-01: Kernel: Linux 4.19.0-16-loongson-3 > > > > > > > Ohh, my mistake: mips-aql-01 vs mipsel-aql-01 ;) > > > > WIth some test. > > This problem is also about O32_FP64 support option. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962485 > > It is quite strange this option may effect mips64el. > Anyway, lets revert it. > > I will continue to dig the real problem. > E, the problem is about Loongson 3A 1000 vs Loongson 3A2000/3000. I test it on 3B1500 + O32_FP64-> workable 3B1500 + nO32_FP64-> workable 3A2000 + O32_FP64-> fail 3A2000 + nO32_FP64-> fail > > > > It doesn't seem to have Cavium CPU here. > > > > > > > > > -- > > YunQiang Su > > > > -- > YunQiang Su -- YunQiang Su
Bug#962485: Bug#983583: FTBFS on mips64el and mipsel
YunQiang Su 于2021年3月29日周一 上午11:45写道： > > Shengjing Zhu 于2021年3月29日周一 上午11:40写道： > > > > On Mon, Mar 29, 2021 at 09:22:29AM +0800, YunQiang Su wrote: > > > Shengjing Zhu 于2021年3月28日周日 上午12:12写道： > > > > > > > > Control: reopen -1 > > > > Control: severity -1 important > > > > > > > > On Sat, Mar 27, 2021 at 11:46 PM Adrian Bunk wrote: > > > > > > > > > > On Sat, Feb 27, 2021 at 02:33:38AM +0800, Shengjing Zhu wrote: > > > > > > Source: golang-github-sylabs-sif > > > > > > Version: 1.0.9-2 > > > > > > Severity: serious > > > > > > X-Debbugs-Cc: z...@debian.org > > > > > > > > > > > > Tried 3 times on buildd and failed at same test. > > > > > > > > > > > > === RUN TestAddDelObject > > > > > > unexpected fault address 0xffc8a0c000 > > > > > > fatal error: fault > > > > > > [signal SIGSEGV: segmentation violation code=0x2 addr=0xffc8a0c000 > > > > > > pc=0x12007ebe4] > > > > > > > > > > > > goroutine 22 [running]: > > > > > > runtime.throw(0x1201b74ed, 0x5) > > > > > > /usr/lib/go-1.15/src/runtime/panic.go:1116 +0x6c > > > > > > fp=0xce3430 sp=0xce3408 pc=0x120040afc > > > > > > runtime.sigpanic() > > > > > > > > > > > > Since it has been built on mipsx before, the failure will cause it > > > > > > impossible > > > > > > to fix issue later on these arch. > > > > > > > > > > > > It should either be removed from these arch or get fixed. > > > > > > > > > > This appears to be fixed now: > > > > > https://buildd.debian.org/status/package.php?p=golang-github-sylabs-sif > > > > > > > > The difference between these builds, seems to be a 5.10 kernel and > > > > 4.19 kernel on buildd. > > > > > > > > I'll reopen this but downgrade the severity, and loop debian-mips@ to > > > > see if it's regression on the kernel side. > > > > > > > > > > And the CPUs are different: Cavium for good and Loongson3A3000 is bad. > > > > > > > On > > https://buildd.debian.org/status/logs.php?pkg=golang-github-sylabs-sif=1.0.9-2%2Bb2=mips64el > > > > The failed buildd are: mipsel-manda-04, succeeded one are mipsel-aql-01. > > From the build log, > > > > mipsel-manda-04: Kernel: Linux 5.10.0-0.bpo.3-loongson-3 > > mipsel-aql-01: Kernel: Linux 4.19.0-16-loongson-3 > > > > Ohh, my mistake: mips-aql-01 vs mipsel-aql-01 ;) > WIth some test. This problem is also about O32_FP64 support option. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962485 It is quite strange this option may effect mips64el. Anyway, lets revert it. I will continue to dig the real problem. > > It doesn't seem to have Cavium CPU here. > > > > > -- > YunQiang Su -- YunQiang Su
Re: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
YunQiang Su 于2021年2月20日周六 下午2:19写道： > > https://lore.kernel.org/linux-mips/20210220061635.9976-1-yunqiang...@cipunited.com/T/#u > This patch for kernel can fix this problem. > > Let's wait for the reply of kernel upstream community. > the newest version of this patch: https://patchwork.kernel.org/project/linux-mips/patch/20210322015902.18451-1-yunqiang...@cipunited.com/ Is it possible for Debian's kernel to apply this patch? > Bastian Blank 于2021年2月11日周四 下午2:57写道： > > > > Moin > > > > On Thu, Feb 11, 2021 at 10:15:02AM +0800, YunQiang Su wrote: > > > > Could the mips porters comment on this? Given that we're close to the > > > > release > > > > of bullseye, I'm not convinced it's a good idea to change this now. > > > > This option is also a dependency of several types of CPU support. So it > > might not be feasable to disable. > > > > > Yes. It will be a problem to run with buster's golang program on > > > bullseys's kernel. > > > Let's have another way to get this problem sloved without revert this > > > changes. > > > > Sure, by discontinuing support for go on mips for example. > > > > > Maybe detect the golang applications and run them in FP32 mode? > > > > The kernel already does. But it seems go decided to set the FPXX marker > > on it's objects. See https://github.com/golang/go/issues/39435 > > > > Bastian > > > > -- > > Captain's Log, star date 21:34.5... > >
Bug#983371: linux: backport binfmt_misc: pass binfmt_misc flags to the interpreter
Package: src:linux Version: 5.10.13-1 https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20210222=2347961b11d4079deace3c81dceed460c08a8fc1 This patch is for qemu to be aware whether P flag is set. -- YunQiang Su
Re: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
https://lore.kernel.org/linux-mips/20210220061635.9976-1-yunqiang...@cipunited.com/T/#u This patch for kernel can fix this problem. Let's wait for the reply of kernel upstream community. Bastian Blank 于2021年2月11日周四 下午2:57写道： > > Moin > > On Thu, Feb 11, 2021 at 10:15:02AM +0800, YunQiang Su wrote: > > > Could the mips porters comment on this? Given that we're close to the > > > release > > > of bullseye, I'm not convinced it's a good idea to change this now. > > This option is also a dependency of several types of CPU support. So it > might not be feasable to disable. > > > Yes. It will be a problem to run with buster's golang program on > > bullseys's kernel. > > Let's have another way to get this problem sloved without revert this > > changes. > > Sure, by discontinuing support for go on mips for example. > > > Maybe detect the golang applications and run them in FP32 mode? > > The kernel already does. But it seems go decided to set the FPXX marker > on it's objects. See https://github.com/golang/go/issues/39435 > > Bastian > > -- > Captain's Log, star date 21:34.5... >
Re: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
Ivo De Decker 于2021年2月9日周二 下午9:45写道： > > Hi, > > On Mon, Jun 08, 2020 at 08:15:38PM +0300, Adrian Bunk wrote: > > On Fri, May 29, 2020 at 11:03:14PM +0200, Aurelien Jarno wrote: > > > On 2020-05-28 09:04, YunQiang Su wrote: > > > > Adrian Bunk 于2020年5月21日周四 下午3:40写道： > > > > > On Thu, May 21, 2020 at 06:41:34AM +0800, YunQiang Su wrote: > > > > > > Adrian Bunk 于2020年5月21日周四 上午4:44写道： > > > > > > > On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote: > > > > > > > > > > > > > > > > FTR, after giving back golang-1.14 mipsel several times, it's > > > > > > > > finally > > > > > > > > built, by a longson builder. > > > > > > > > So I guess it only occurs on octeon. Since the porterbox eller > > > > > > > > is also > > > > > > > > octeon, it also can't build any go program. > > > > > > > > > > > > > > On eller golang-1.14 fails to build both in sid and buster > > > > > > > chroots. > > > > > > > > > > > > > > golang-1.11 also fails to build in a buster chroot with floating > > > > > > > point > > > > > > > test errors. > > > > > > > > > > > > > > golang-1.14 gets unbroken by GOMIPS=softfloat. > > > > > > > > > > > > > > The only kernel configuration change on eller in the buster point > > > > > > > release is CONFIG_MIPS_O32_FP64_SUPPORT=y, everything observed > > > > > > > would > > > > > > > make sense if the problem is that golang-1.11 and golang-1.14 are > > > > > > > not compatible with CONFIG_MIPS_O32_FP64_SUPPORT. > > > > > > > > > > > > It is just support O32_FP64. I don't expect it will have any effect. > > > > > > Since currently, the toolchain/libraries are all FPXX. > > > > > > > > > > Only the gcc/binutils toolchain/libraries or also the Go toolchain? > > > > > > > > you are right. the current golang still output FP32 object... > > > > So, we think that it is buggy. > > > > > > > > Since Loongson CPU has some strange behaviour, it even can work... > > > > Let's try to patch golang to support FPXX or FP64. > > > > > > > > https://github.com/golang/go/issues/39289 > > > > > > That's probably a solution for bullseye/sid, however we can't backport > > > such changes and rebuild the go world in buster. I therefore think that > > > for buster the kernel change has to be reverted. > > > > What is clear at this point is that the kernel change should be reverted > > in buster since it causes a regression (including build failures on > > buildds). I am cloning this bug for a revert in the kernel of > > https://salsa.debian.org/kernel-team/linux/-/commit/947fbc66183d022fe3de7871dfb262d2b87af826 > > > > I am marking the version in bullseye as found since we might run into > > the same problem again when buster DSAs will be built on machines > > running the bullseye kernel after the release of bullseye. It might be > > possible to mitigate this problem (e.g. in the kernel or by keeping some > > buildd running with the buster kernel), but without an open bug this > > issue might get forgotten and then resurface after the bullseye release. > > Could the mips porters comment on this? Given that we're close to the release > of bullseye, I'm not convinced it's a good idea to change this now. Yes. It will be a problem to run with buster's golang program on bullseys's kernel. Let's have another way to get this problem sloved without revert this changes. Maybe detect the golang applications and run them in FP32 mode? > > Cheers, > > Ivo > >
Bug#961328: src:linux enable OF and SERIAL_OF_PLATFORM for Loongson-3
Package: src:linux Version: 5.6 Recently, the Loongson64, aka loongson-3 switch to device-tree, and the console cannot accept input anymore due to SERIAL_OF_PLATFORM is not enabled. While SERIAL_OF_PLATFORM depends on OF, we need to enable it at the same time. Don't backport this modification to 4.19, since the switch is after 4.19. -- YunQiang Su
Re: Future of Octeon MIPS hardware support
YunQiang Su 于2020年3月4日周三 上午9:54写道： > > Ben Hutchings 于2020年3月4日周三 上午9:24写道： > > > > The main Ethernet driver for all Octeon MIPS SoCs has been disabled > > upstream in Linux 5.5, and will be removed in 5.6. The driver has been > > in "staging" (i.e. it didn't meet the usual standards for kernel code) > > ever since it was added in 2009. It recently stopped building, and > > didn't have a regular maintainer who could fix it. (There is a > > separate Ethernet driver for the management port, which seems to be > > still maintained.) > > > > The USB host driver for Octeon CN3xxx and CN5xxx SoCs will also be > > removed for similar reasons. > > > > * DSA: The removal of the Ethernet driver will affect the EdgeRouter > > Pro used for the Debian mips porterbox and some buildds. These do not > > seem to have any expansion slots useful for alternate network > > interfaces, so they will likely need to be replaced before buster EOL. > > https://patchwork.kernel.org/cover/11365607/ > > There is a patchset for it. > Greg said that he will help to merge, while it has not really happen. > Let's ask for him whether he need some more info or anything. This patchset has been in linux-next now. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=next-20200304=author=Chris+Packham > > > > > * MIPS porters: Given that these SoCs are designed primarily for > > networking and we will no longer support the on-board network > > interfaces, does it make sense to continue building kernel packages for > > them? > > > > Ben. > > > > -- > > Ben Hutchings > > No political challenge can be met by shopping. - George Monbiot > > > > > > > -- > YunQiang Su -- YunQiang Su
Re: Future of Octeon MIPS hardware support
Ben Hutchings 于2020年3月4日周三 上午9:24写道： > > The main Ethernet driver for all Octeon MIPS SoCs has been disabled > upstream in Linux 5.5, and will be removed in 5.6. The driver has been > in "staging" (i.e. it didn't meet the usual standards for kernel code) > ever since it was added in 2009. It recently stopped building, and > didn't have a regular maintainer who could fix it. (There is a > separate Ethernet driver for the management port, which seems to be > still maintained.) > > The USB host driver for Octeon CN3xxx and CN5xxx SoCs will also be > removed for similar reasons. > > * DSA: The removal of the Ethernet driver will affect the EdgeRouter > Pro used for the Debian mips porterbox and some buildds. These do not > seem to have any expansion slots useful for alternate network > interfaces, so they will likely need to be replaced before buster EOL. https://patchwork.kernel.org/cover/11365607/ There is a patchset for it. Greg said that he will help to merge, while it has not really happen. Let's ask for him whether he need some more info or anything. > > * MIPS porters: Given that these SoCs are designed primarily for > networking and we will no longer support the on-board network > interfaces, does it make sense to continue building kernel packages for > them? > > Ben. > > -- > Ben Hutchings > No political challenge can be met by shopping. - George Monbiot > > -- YunQiang Su
[kernel/mips*] enable O32_FP64 support on Buster
In Jessie and Buster cycles, we finished the process from FP32 to FPXX. And I test the whole Buster archive, and be sure that all packages are built with FPXX now. Since FPXX uses only even FPRs, then wastes other 16 FPRs. And another problem of FPXX is that it may need help of RAM for some operation. FP64 also has better co-operation with MIPS SIMD Architecture (MSA). The CONFIG_MIPS_O32_FP64_SUPPORT has just enabled in master branch of kernel-team/linux[2]. Is it possible to enable this config for buster? So we can start the migration to FP64 now, and release it with bullseye. Otherwise we will have to start this work after bullseye released. [1]. https://web.archive.org/web/20180828210612/https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking [2]. https://salsa.debian.org/kernel-team/linux/commit/b1d08a0cffbe181cbb94e3fc72a91c2e8a8a38e7
Bug#929366: linux-image-4.19.0-5-octeon: usercopy: Kernel memory overwrite attempt detected (in systemd-timedated)
Paul Burton 于2019年5月26日周日 上午7:22写道：
>
> Hi YunQiang,
>
> Could you try the following kernel patch & let me know if it works for
> you?
>
> My theory is that this is fallout from commit 517e1fbeb65f
> ("mm/usercopy: Drop extra is_vmalloc_or_module() check") which went into
> Linux v4.12. I guess this shows our test systems don't have hardened
> usercopy enabled - I'll go change that!
>
> Thanks,
> Paul
>
> ---
> diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
> index 2f616ebeb7e0..01b2eadd28bd 100644
> --- a/arch/mips/mm/mmap.c
> +++ b/arch/mips/mm/mmap.c
> @@ -203,6 +203,11 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
>
> int __virt_addr_valid(const volatile void *kaddr)
> {
> + unsigned long vaddr = (unsigned long)vaddr;
> +
> + if ((vaddr < PAGE_OFFSET) || (vaddr >= MAP_BASE))
> + return false;
> +
> return pfn_valid(PFN_DOWN(virt_to_phys(kaddr)));
> }
> EXPORT_SYMBOL_GPL(__virt_addr_valid);
It works well at least on my Loongson 3 laptop.
I tried to reinstall all packages with gz'ed mannual pages.
No of this problem happens again.
--
YunQiang Su
Bug#929366: linux-image-4.19.0-5-octeon: usercopy: Kernel memory overwrite attempt detected (in systemd-timedated)
2a30784 0ef08000 417135fb8ce5871c > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: > 000b55d29698 000b55de72f0 55d29698 417135fb8ce5871c > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: > 55dea4c0 55de72f0 77d5a7c8 77d5a73c > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: > 77d3 77d57098 82943b0c > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: > 0001 0fa0 0001 > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: > ... > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: Call > Trace: > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: > [] usercopy_abort+0x94/0xa0 > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: > [] __check_heap_object+0x170/0x188 > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: > [] __check_object_size+0x11c/0x238 > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: > [] bpf_prog_create_from_user+0x94/0x1d8 > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: > [] do_seccomp+0x2a4/0x7a0 > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: > [] syscall_common+0x18/0x3c > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: Code: > 00404025 0ca715c4 6484a3c0 <000c000d> 67bdfff0 > ffbf0008 ffb0 > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: ---[ end > trace aad06c7e2b036639 ]--- > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 systemd[1]: > systemd-timedated.service: Main process exited, code=killed, status=11/SEGV > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 systemd[1]: > systemd-timedated.service: Failed with result 'signal'. > May 22 11:57:53 mips-sil-01/mips-sil-01/:::86.59.118.146 systemd[1]: > Failed to start Time & Date Service. > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 > dbus-daemon[542]: [system] Activating via systemd: service > name='org.freedesktop.timedate1' > unit='dbus-org.freedesktop.timedate1.service' requested by ':1.12566' > (uid=115 pid=1749 comm="timedatectl show ") > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: > usercopy: Kernel memory overwrite attempt detected to SLUB object > 'buffer_head' (offset 8, size 296)! > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: Kernel > bug detected[#2]: > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: CPU: 3 > PID: 1 Comm: systemd Tainted: G D 4.19.0-5-octeon #1 Debian > 4.19.37-3 > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: $ 0 : > 82a78f48 0065 417135fb8ce5871c > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: $ 4 : > 417135fb8ce5871c 8000240b3678 8000240bc080 835b > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: $ 8 : > 0129 80020e9a4018 286f73657420 835b > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: $12 : > 05f5e100 835b 83590b58 > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: $16 : > c2402038 0128 c2402160 > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: $20 : > 0128 55df5a50 c2402038 55661000 > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: $24 : > 82dcc9a0 > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: $28 : > 80020fdb8000 80020fdbbc30 82b71874 > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: Hi: > 00ef31cb > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: Lo: > 645a1cac094d320b > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: epc : > 82b71874 usercopy_abort+0x94/0xa0 > May 22 11:59:53 mips-sil-01/mips-sil-01/::ffff:86.59.118.146 kernel: ra: > 82b71874 usercopy_abort+0x94/0xa0 > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: Status: > 10109ce3 KX SX UX KERNEL EXL IE > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: Cause : > 00800024 (ExcCode 09) > May 22 11:59:53 mips-sil-01/mips-sil-01/:::86.59.118.146 kernel: PrId : > 000d9602 (Cavium Octeon III) > > After that the machine seems to have rebooted. > > Cheers, > Julien > -- YunQiang Su
Bug#898525: linux: add MIPS CI20 support
Package: src:linux Version: 4.17~rc3-1~exp1 MIPS CI20 /JZ4780 support has been added upstream. for 0002-add-ci20.patch, we add basic support, without MMC and DRM support, so we have to use UBI to boot it. 0003-support-jz4780-mmc is patches that are in linux-next now, and will be released with 4.18. DRM is not supported yet. -- YunQiang Su From 9717c8b9d2b5e4c5744dc491cc1d7f4e23ccc939 Mon Sep 17 00:00:00 2001 From: YunQiang Su <s...@debian.org> Date: Wed, 9 May 2018 11:06:01 +0800 Subject: [PATCH 2/5] add ci20 --- debian/config/kernelarch-mips/config.ci20 | 238 ++ debian/config/mipsel/defines | 12 ++ 2 files changed, 250 insertions(+) create mode 100644 debian/config/kernelarch-mips/config.ci20 diff --git a/debian/config/kernelarch-mips/config.ci20 b/debian/config/kernelarch-mips/config.ci20 new file mode 100644 index 000..88fe850 --- /dev/null +++ b/debian/config/kernelarch-mips/config.ci20 @@ -0,0 +1,238 @@ +## +## file: arch/mips/Kconfig +## +## choice: System type +CONFIG_MACH_INGENIC=y +## end choice +CONFIG_HIGHMEM=y + +## +## file: arch/mips/Kconfig.debug +## +## We set CMDLINE here to pin the console output to the same TTL socket with UBOOT. +CONFIG_CMDLINE_BOOL=y +CONFIG_CMDLINE="earlycon console=ttyS4,115200 clk_ignore_unused" +# CONFIG_CMDLINE_OVERRIDE is not set + +## +## file: arch/mips/jz4740/Kconfig +## +CONFIG_JZ4780_CI20=y + +## +## file: init/Kconfig +## +CONFIG_EMBEDDED=y +CONFIG_CC_OPTIMIZE_FOR_SIZE=y + +## +## file: mm/Kconfig +## +CONFIG_CMA=y + +## +## file: block/partitions/Kconfig +## +# CONFIG_PARTITION_ADVANCED is not set + +## +## file: block/partitions/Kconfig +## +CONFIG_MTD=y +CONFIG_MTD_NAND_ECC=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_JZ4780=y +CONFIG_MTD_UBI=y +CONFIG_MTD_UBI_FASTMAP=y +# CONFIG_MTD_UBI_BLOCK is not set +# CONFIG_MTD_LPDDR is not set +# CONFIG_MTD_SPI_NOR is not set + +## +## file: drivers/base/Kconfig +## +CONFIG_DMA_CMA=y + +## +## file: drivers/block/Kconfig +## +CONFIG_BLK_DEV_INITRD=y + +## +## file: net/Kconfig +## +# CONFIG_WIRELESS is not set + +## +## file: net/wimax/Kconfig +## +# CONFIG_WIMAX is not set + +## +## file: drivers/atm/Kconfig +## +# CONFIG_ATM_DRIVERS is not set + +## +## file: drivers/net/ethernet/*/Kconfig +## +CONFIG_DM9000=y +# CONFIG_NET_CADENCE is not set +# CONFIG_NET_VENDOR_BROADCOM is not set +# CONFIG_NET_VENDOR_QUALCOMM is not set +# CONFIG_NET_VENDOR_INTEL is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MICREL is not set +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_ROCKER is not set +# CONFIG_NET_VENDOR_SAMSUNG is not set +# CONFIG_NET_VENDOR_SMSC is not set +# CONFIG_NET_VENDOR_STMICRO is not set +# CONFIG_NET_VENDOR_VIA is not set +# CONFIG_NET_VENDOR_WIZNET is not set +# CONFIG_NET_VENDOR_ALACRITECH is not set +# CONFIG_NET_VENDOR_AMAZON is not set +# CONFIG_NET_VENDOR_AQUANTIA is not set +# CONFIG_NET_VENDOR_CORTINA is not set +# CONFIG_NET_VENDOR_EZCHIP is not set +# CONFIG_NET_VENDOR_HUAWEI is not set +# CONFIG_NET_VENDOR_MELLANOX is not set +# CONFIG_NET_VENDOR_NETRONOME is not set +# CONFIG_NET_VENDOR_RENESAS is not set +# CONFIG_NET_VENDOR_SOLARFLARE is not set +# CONFIG_NET_VENDOR_SOCIONEXT is not set +# CONFIG_NET_VENDOR_XILINX is not set +# CONFIG_NET_VENDOR_SYNOPSYS is not set + +## +## file: drivers/net/ieee802154/Kconfig +## +# CONFIG_IEEE802154_DRIVERS is not set + +## +## file: drivers/lightnvm/Kconfig +## +# CONFIG_NVM is not set + +## +## file: drivers/input/serio/Kconfig +## +# CONFIG_SERIO is not set +# CONFIG_ARCH_MIGHT_HAVE_PC_SERIO is not set + +## +## file: drivers/tty/serial/8250/Kconfig +## +CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y +CONFIG_SERIAL_8250_NR_UARTS=5 +CONFIG_SERIAL_8250_RUNTIME_UARTS=5 +CONFIG_SERIAL_8250_INGENIC=y +CONFIG_SERIAL_OF_PLATFORM=y + +## +## file: drivers/i2c/Kconfig +## +CONFIG_I2C=y +# CONFIG_I2C_CHARDEV is not set +# CONFIG_I2C_MUX is not set +CONFIG_I2C_JZ4780=y +# CONFIG_I2C_OCORES is not set +# CONFIG_I2C_PCA_PLATFORM is not set +# CONFIG_I2C_SIMTEC is not set +# CONFIG_I2C_TAOS_EVM is not set + +## +## file: kernel/power/Kconfig +## +# CONFIG_PM is not set +# CONFIG_PM_DEVFREQ is not set +# CONFIG_SUSPEND is not set +# CONFIG_HIBERNATION is not set +# CONFIG_POWER_RESET is not set +# CONFIG_POWER_SUPPLY is not set +CONFIG_CPU_PM=y + +## +## file: drivers/cpuidle/Kconfig +## +CONFIG_CPU_IDLE=y + +## +## file: fs/*/Kconfig +## +## CI20 has a bad initrd support, so we set some major FS to Y +CONFIG_EXT4_FS=y +CONFIG_BTRFS_FS=y +CONFIG_XFS_FS=y +CONFIG_UBIFS_FS=y +CONFIG_FAT_FS=y + +## +## file: drivers/spi/Kconfig +## +# CONFIG_SPI is not set + +## +## file: drivers/pps/Kconfig +## +# CONFIG_PPS is not set + +## +## file: drivers/gpio/Kconfig +## +CONFIG_GPIO_INGENIC=y + +## +## file: drivers/w1/Kconfig +## +# CONFIG_W1 is not set + +## +## file: drivers/ssb/Kconfig +## +# CONFIG_SSB_POSSIBLE is not set +# CONFIG_SSB is not set + +## +## file: dri
Bug#898523: linux: use boston instead of malta for mips r6
Package: src:linux
Version: 4.17~rc3-1~exp1
We should use Boston instead of Malta to support mips r6,
as only Boston is used for MIPS r6, while Malta is never used for r6.
Due to this, we have to increase RELOCATION_TABLE_SIZE.
The patch mips-boston-disable-its.patch is used to stop uboot Image
generation, as it asks for u-boot-tools installed.
--
YunQiang Su
From a9be091e3ffdf8dee8e7114c9b7f9710e9d199d8 Mon Sep 17 00:00:00 2001
From: root <root@zfs-01>
Date: Sat, 12 May 2018 14:04:37 +
Subject: [PATCH 5/5] fix mips r6
---
debian/config/kernelarch-mips/config.boston | 10 ++
debian/config/mips64r6/defines | 8
debian/config/mips64r6el/defines | 8
debian/config/mipsr6/defines | 16
debian/config/mipsr6el/defines | 16
debian/installer/mips64r6/kernel-versions| 2 +-
.../modules/{mips64r6 => mips64r6-boston-64r6eb} | 0
debian/installer/mips64r6el/kernel-versions | 2 +-
.../modules/{mips64r6 => mips64r6el-boston-64r6el} | 0
debian/installer/mipsr6/kernel-versions | 2 +-
.../mipsr6/modules/{mips32r6 => mipsr6-boston-32r6eb}| 0
debian/installer/mipsr6el/kernel-versions| 2 +-
.../modules/{mips32r6 => mipsr6el-boston-32r6el} | 0
debian/patches/debian/mips-boston-disable-its.patch | 13 +
debian/patches/series| 1 +
15 files changed, 52 insertions(+), 28 deletions(-)
create mode 100644 debian/config/kernelarch-mips/config.boston
rename debian/installer/mips64r6/modules/{mips64r6 => mips64r6-boston-64r6eb} (100%)
rename debian/installer/mips64r6el/modules/{mips64r6 => mips64r6el-boston-64r6el} (100%)
rename debian/installer/mipsr6/modules/{mips32r6 => mipsr6-boston-32r6eb} (100%)
rename debian/installer/mipsr6el/modules/{mips32r6 => mipsr6el-boston-32r6el} (100%)
create mode 100644 debian/patches/debian/mips-boston-disable-its.patch
diff --git a/debian/config/kernelarch-mips/config.boston b/debian/config/kernelarch-mips/config.boston
new file mode 100644
index 000..66713de
--- /dev/null
+++ b/debian/config/kernelarch-mips/config.boston
@@ -0,0 +1,10 @@
+##
+## file: arch/mips/Kconfig
+##
+## choice: System type
+CONFIG_MIPS_GENERIC=y
+## end choice
+##
+## Common Clock Framework
+##
+CONFIG_COMMON_CLK_BOSTON=y
diff --git a/debian/config/mips64r6/defines b/debian/config/mips64r6/defines
index 1952e15..132a7db 100644
--- a/debian/config/mips64r6/defines
+++ b/debian/config/mips64r6/defines
@@ -1,6 +1,6 @@
[base]
flavours:
- mips64r6
+ boston-64r6eb
kernel-arch: mips
[build]
@@ -9,12 +9,12 @@ image-file: vmlinux
[image]
install-stem: vmlinux
-[mips64r6_description]
+[boston-64r6eb_description]
hardware: MIPS R6 (64 bit, big endian)
hardware-long: MIPS R6 (64 bit, big endian)
-[mips64r6_image]
+[boston-64r6eb_image]
configs:
- kernelarch-mips/config.malta
+ kernelarch-mips/config.boston
kernelarch-mips/config.mips64r6
diff --git a/debian/config/mips64r6el/defines b/debian/config/mips64r6el/defines
index ac92b9b..3e7123e 100644
--- a/debian/config/mips64r6el/defines
+++ b/debian/config/mips64r6el/defines
@@ -1,6 +1,6 @@
[base]
flavours:
- mips64r6el
+ boston-64r6el
kernel-arch: mips
[build]
@@ -9,12 +9,12 @@ image-file: vmlinux
[image]
install-stem: vmlinux
-[mips64r6el_description]
+[boston-64r6el_description]
hardware: MIPS R6 (64 bit, little endian)
hardware-long: MIPS R6 (64 bit, little endian)
-[mips64r6el_image]
+[boston-64r6el_image]
configs:
- kernelarch-mips/config.malta
+ kernelarch-mips/config.boston
kernelarch-mips/config.mips64r6
diff --git a/debian/config/mipsr6/defines b/debian/config/mipsr6/defines
index 9f5a11d..52d3bde 100644
--- a/debian/config/mipsr6/defines
+++ b/debian/config/mipsr6/defines
@@ -1,7 +1,7 @@
[base]
flavours:
- mips32r6
- mips64r6
+ boston-32r6eb
+ boston-64r6eb
kernel-arch: mips
[build]
@@ -10,21 +10,21 @@ image-file: vmlinux
[image]
install-stem: vmlinux
-[mips32r6_description]
+[boston-32r6eb_description]
hardware: MIPS R6 (32 bit, big endian)
hardware-long: MIPS R6 (32 bit, big endian)
-[mips32r6_image]
+[boston-32r6eb_image]
configs:
- kernelarch-mips/config.malta
+ kernelarch-mips/config.boston
kernelarch-mips/config.mips32r6
-[mips64r6_description]
+[boston-64r6eb_description]
hardware: MIPS R6 (64 bit, big endian)
hardware-long: MIPS R6 (64 bit, big endian)
-[mips64r6_image]
+[boston-64r6eb_image]
configs:
- kernelarch-mips/config.malta
+ kernelarch-mips/config.boston
kernelarch-mips/config.mips64r6
diff --git a/debian/config/mipsr6el/defines b/debian/config/mipsr6el/defines
index 257bc06..caded55 100644
--- a/debian/config/mipsr6el/defines
+++ b/debian/config/mipsr6el/defines
@@ -1,7 +1,7 @@
[base]
flavours:
- mips32r6e
Bug#898521: linux: loongson-3 enable NUMA/CPU_PM/IDLE/HPET/REGULATOR
Package: src:linux Version: 4.17~rc3-1-exp1 Loongson-3 support these options, while we didn't enable them before. -- YunQiang Su From bbef2f566766d79dd0675764b5bde1fe63206f93 Mon Sep 17 00:00:00 2001 From: YunQiang Su <s...@debian.org> Date: Sat, 14 Apr 2018 12:33:14 +0800 Subject: [PATCH 1/5] add NUMA/CPU_PM/CPU_IDLE/RS780_HPET/REGULATOR to loongson-3 --- debian/config/kernelarch-mips/config.loongson-3 | 17 + 1 file changed, 17 insertions(+) diff --git a/debian/config/kernelarch-mips/config.loongson-3 b/debian/config/kernelarch-mips/config.loongson-3 index 9574411..ffcc8cb 100644 --- a/debian/config/kernelarch-mips/config.loongson-3 +++ b/debian/config/kernelarch-mips/config.loongson-3 @@ -11,15 +11,27 @@ CONFIG_64BIT=y CONFIG_SMP=y CONFIG_HOTPLUG_CPU=y CONFIG_NR_CPUS=16 +CONFIG_NUMA=y + +## +## file: kernel/power/Kconfig +## +CONFIG_CPU_PM=y ## ## file: arch/mips/loongson64/Kconfig ## ## choice: Machine Type CONFIG_LOONGSON_MACH3X=y +CONFIG_RS780_HPET=y ## end choice ## +## file: drivers/cpuidle/Kconfig +## +CONFIG_CPU_IDLE=y + +## ## file: drivers/ata/Kconfig ## CONFIG_SATA_AHCI=y @@ -67,6 +79,11 @@ CONFIG_8139TOO=m CONFIG_RTC_DRV_CMOS=y ## +## file: drivers/regulator/Kconfig +## +CONFIG_REGULATOR=y + +## ## file: drivers/tty/serial/8250/Kconfig ## # CONFIG_SERIAL_8250_EXTENDED is not set -- 2.11.0
Bug#871701: linux 4.9: backport patches for new Loongson CPU
On Sun, Aug 20, 2017 at 7:15 PM, Aurelien Jarno <aurel...@aurel32.net> wrote: > On 2017-08-11 02:39, YunQiang Su wrote: >> Package: linux >> Version: 4.9.30-2+deb9u2 >> >> The support Loongson 3A/B 2000 and 3000 has been merged into upstream. >> I test the patchset with linux 4.9.30-2+deb9u2 for stretch. >> > > In the past, backporting support for newer CPUs broke the support for > older boards. Have you check it works both for lemote 3a-itx-a1101 and > loongson ls3a-rs780e-1w boards? Yes. I tested it on a Lemote 6100 and a Loongson dev board, aka, lm6100 and thor. > > Thanks, > Aurelien > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net -- YunQiang Su
Bug#871701: linux 4.9: backport patches for new Loongson CPU
Package: linux Version: 4.9.30-2+deb9u2 The support Loongson 3A/B 2000 and 3000 has been merged into upstream. I test the patchset with linux 4.9.30-2+deb9u2 for stretch. It works well on both Loongson 3A 1000 and 3A 3000 CPU. The patchset merged on June 28-29. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=v4.13-rc4=grep=Huacai+Chen 0a00024d7a779b283db2a02130ffa46f47634d0c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.13-rc4=0a00024d7a779b283db2a02130ffa46f47634d0c b392ee07999aa1f19b3a845fad47ec4275341f71 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.13-rc4=b392ee07999aa1f19b3a845fad47ec4275341f71 99b0b5a3a1e994247e7533de0fd7e4d13ead0ddd https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.13-rc4=99b0b5a3a1e994247e7533de0fd7e4d13ead0ddd e1b88ca8d72193e48bac026b19b8c686cc7fea25 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.13-rc4=e1b88ca8d72193e48bac026b19b8c686cc7fea25 ecc38a0968ec3e0605079e49d276d9a4186abdb7 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.13-rc4=ecc38a0968ec3e0605079e49d276d9a4186abdb7 b9c4dc2cf9af62bc0d2d8504c15175aeac49ad53 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.13-rc4=b9c4dc2cf9af62bc0d2d8504c15175aeac49ad53 -- YunQiang Su
Re: Bug#858405: xmlto: intermittent Segmentation fault when building manpages for libreswan on mips64el
the moment, I'll rebuild libreswan again and hope a good buildd is >>> picked. >> >> i see 5 mips64el rebuilds now at >> https://buildd.debian.org/status/logs.php?pkg=libreswan=3.20-6=sid, >> but none of them have succeded yet :/ >> >> 3 of the builds are from mipsel-manda-02, 1 is from eberlin, and one >> additional new "bad" builder is: >> >> mipsel-aql-01 > > There are 3 non-Loongson buildds: mipsel-aql-03, mipsel-manda-03 and > mipsel-sil-01. I expect libreswan will only build on one of those > buildds at the moment. > > Thanks, > James > -- YunQiang Su
Bug#827790: linux: please drop support to Loongson 2e/2f
Package: src:linux We are working on migrate mips/mipsel to mips32r2, and then, Loongson 2E/2F won't be support any more. So please drop the flavors for 2E and 2F, as they are not useful anymore. -- YunQiang Su
Re: linux_4.6-1~exp2_multi.changes REJECTED
On Tue, May 31, 2016 at 2:13 AM, Ben Hutchings <b...@decadent.org.uk> wrote:
> On Mon, 2016-05-30 at 16:26 +, Debian FTP Masters wrote:
>>
>> Processing raised an exception: mipsr6 is not a valid architecture name or
>> wildcard.
>> Traceback (most recent call last):
>> File "/srv/ftp-master.debian.org/dak/dak/daklib/archive.py", line 968, in
>> check
>> final_suites = self._final_suites()
>> File "/srv/ftp-master.debian.org/dak/dak/daklib/archive.py", line 857, in
>> _final_suites
>> if self._check_new(suite, overridesuite):
>> File "/srv/ftp-master.debian.org/dak/dak/daklib/archive.py", line 822, in
>> _check_new
>> if self._check_new_binary_overrides(suite, overridesuite):
>> File "/srv/ftp-master.debian.org/dak/dak/daklib/archive.py", line 786, in
>> _check_new_binary_overrides
>> packages = source.package_list.packages_for_suite(suite)
>> File "/srv/ftp-master.debian.org/dak/dak/daklib/packagelist.py", line 128,
>> in packages_for_suite
>> built = entry.built_in_suite(suite)
>> File "/srv/ftp-master.debian.org/dak/dak/daklib/packagelist.py", line 58,
>> in built_in_suite
>> built_on_arch = self.built_on_architecture(arch.arch_string)
>> File "/srv/ftp-master.debian.org/dak/dak/daklib/packagelist.py", line 49,
>> in built_on_architecture
>> if match_architecture(architecture, arch):
>> File "/srv/ftp-master.debian.org/dak/dak/daklib/architecture.py", line 94,
>> in match_architecture
>> raise InvalidArchitecture('{0} is not a valid architecture name or
>> wildcard'.format(wildcard))
>> InvalidArchitecture: mipsr6 is not a valid architecture name or wildcard
I'd guess that the `dpkg' should upgrade on dak machine?
>
> OK, what's the story here? This had better get fixed quickly,
> otherwise I'm going to have to revert the package changes.
>
> Ben.
>
> --
> Ben Hutchings
> Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
--
YunQiang Su
Bug#825024: linux: add MIPS r6 and N32 support
On Mon, May 23, 2016 at 8:21 PM, Ben Hutchings <b...@decadent.org.uk> wrote: > On Mon, 2016-05-23 at 20:16 +0800, YunQiang Su wrote: >> On Mon, May 23, 2016 at 8:11 PM, Ben Hutchings <b...@decadent.org.uk> wrote: >> > >> > On Mon, 2016-05-23 at 19:32 +0800, YunQiang Su wrote: >> > > >> > > On Mon, May 23, 2016 at 7:24 PM, Ben Hutchings wrote: >> > > > >> > > > >> > > > Control: tag -1 - moreinfo >> > > > >> > > > On Mon, 2016-05-23 at 11:14 +0800, YunQiang Su wrote: >> > > > > >> > > > > >> > > > > On Mon, May 23, 2016 at 2:30 AM, Ben Hutchings wrote: >> > > > > > >> > > > > > >> > > > > > >> > > > > > Control: tag -1 moreinfo >> > > > > > >> > > > > > On Sun, 2016-05-22 at 22:52 +0800, YunQiang Su wrote: >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > Package: src:linux >> > > > > > > Version: 4.5 - 4.6 >> > > > > > > >> > > > > > > Hi, this patch add mipsn32 and mipsn32el support and also add >> > > > > > > 6 MIPS r6 architectures. >> > > > > > > >> > > > > > > mipsn32 and mipsn32el have same flavors with mips64 and mips64el. >> > > > > > Since we have multiarch it is not necessary to duplicate kernel >> > > > > > packages with identical configurations in multiple Debian >> > > > > > architectures. All the N32 architectures should be used in >> > > > > > multiarch >> > > > > > configurations together with the corresponding 64-bit >> > > > > > architectures. >> > > > > > (The same should be true for O32 architectures, but that won't >> > > > > > happen >> > > > > > until the corresponding 64-bit architectures are in the main >> > > > > > archive.) >> > > > > I won't push N32 architecture to the main Debian archive. >> > > > > I just wish the code in the upstream, so I will not have to maintain >> > > > > another >> > > > > git repo, and merge patches again and again. >> > > > > >> > > > > In fact, I may build a standalone N32 private archive in future. >> > > > I will still insist that N32 architectures do not have their own >> > > > kernels, only userland packages (linux-libc-dev, linux-kbuild, linux- >> > > > perf, etc.) >> > > Yes, so mipsn32/mipsn32el architectures has the same flavors with >> > > mips64/mips64el. >> > > >> > > N32 here is about 2 new architectures named mipsn32/mipsn32el. >> > > To make these architectures installable, they must have their own >> > > kernel packages, like >> > > linux-image-4.6.0-1-loongson-3_$(THE_VERSION).mipsn32el.deb. >> > > >> > > This package has the same content with: >> > > >> > > linux-image-4.6.0-1-loongson-3_$(THE_VERSION).mips64el.deb. >> > [...] >> > >> > No. They must be used in a multiarch configuration, same as x32. >> in debian/config/x32/defines, there is a line: >> # empty; x32 must be part of a multiarch installation with an amd64 kernel >> >> I know that n32 is quite same as x32, while I cannot understand why >> both of them have to be 'in a multiarch configuration', >> and cannot be a standalone architecture? > > Because they really are in a multiarch configuration. They rely on a > 64-bit kernel. Labelling it as belonging to the same architecture as > 32-bit userland is a hack, which we no longer need to use. If you think standalone n32/x32 port is not useful at all, can you help to modified the 4 N32 port to the same way with x32? > > Ben. > > -- > Ben Hutchings > You can't have everything. Where would you put it? -- YunQiang Su
Bug#825024: linux: add MIPS r6 and N32 support
On Mon, May 23, 2016 at 8:11 PM, Ben Hutchings <b...@decadent.org.uk> wrote: > On Mon, 2016-05-23 at 19:32 +0800, YunQiang Su wrote: >> On Mon, May 23, 2016 at 7:24 PM, Ben Hutchings <b...@decadent.org.uk> wrote: >> > >> > Control: tag -1 - moreinfo >> > >> > On Mon, 2016-05-23 at 11:14 +0800, YunQiang Su wrote: >> > > >> > > On Mon, May 23, 2016 at 2:30 AM, Ben Hutchings wrote: >> > > > >> > > > >> > > > Control: tag -1 moreinfo >> > > > >> > > > On Sun, 2016-05-22 at 22:52 +0800, YunQiang Su wrote: >> > > > > >> > > > > >> > > > > Package: src:linux >> > > > > Version: 4.5 - 4.6 >> > > > > >> > > > > Hi, this patch add mipsn32 and mipsn32el support and also add >> > > > > 6 MIPS r6 architectures. >> > > > > >> > > > > mipsn32 and mipsn32el have same flavors with mips64 and mips64el. >> > > > Since we have multiarch it is not necessary to duplicate kernel >> > > > packages with identical configurations in multiple Debian >> > > > architectures. All the N32 architectures should be used in multiarch >> > > > configurations together with the corresponding 64-bit architectures. >> > > > (The same should be true for O32 architectures, but that won't happen >> > > > until the corresponding 64-bit architectures are in the main archive.) >> > > I won't push N32 architecture to the main Debian archive. >> > > I just wish the code in the upstream, so I will not have to maintain >> > > another >> > > git repo, and merge patches again and again. >> > > >> > > In fact, I may build a standalone N32 private archive in future. >> > I will still insist that N32 architectures do not have their own >> > kernels, only userland packages (linux-libc-dev, linux-kbuild, linux- >> > perf, etc.) >> Yes, so mipsn32/mipsn32el architectures has the same flavors with >> mips64/mips64el. >> >> N32 here is about 2 new architectures named mipsn32/mipsn32el. >> To make these architectures installable, they must have their own >> kernel packages, like >> linux-image-4.6.0-1-loongson-3_$(THE_VERSION).mipsn32el.deb. >> >> This package has the same content with: >> >> linux-image-4.6.0-1-loongson-3_$(THE_VERSION).mips64el.deb. > [...] > > No. They must be used in a multiarch configuration, same as x32. in debian/config/x32/defines, there is a line: # empty; x32 must be part of a multiarch installation with an amd64 kernel I know that n32 is quite same as x32, while I cannot understand why both of them have to be 'in a multiarch configuration', and cannot be a standalone architecture? > > Ben. > > -- > Ben Hutchings > You can't have everything. Where would you put it? -- YunQiang Su
Bug#825024: linux: add MIPS r6 and N32 support
On Mon, May 23, 2016 at 7:24 PM, Ben Hutchings <b...@decadent.org.uk> wrote: > Control: tag -1 - moreinfo > > On Mon, 2016-05-23 at 11:14 +0800, YunQiang Su wrote: >> On Mon, May 23, 2016 at 2:30 AM, Ben Hutchings <b...@decadent.org.uk> wrote: >> > >> > Control: tag -1 moreinfo >> > >> > On Sun, 2016-05-22 at 22:52 +0800, YunQiang Su wrote: >> > > >> > > Package: src:linux >> > > Version: 4.5 - 4.6 >> > > >> > > Hi, this patch add mipsn32 and mipsn32el support and also add >> > > 6 MIPS r6 architectures. >> > > >> > > mipsn32 and mipsn32el have same flavors with mips64 and mips64el. >> > Since we have multiarch it is not necessary to duplicate kernel >> > packages with identical configurations in multiple Debian >> > architectures. All the N32 architectures should be used in multiarch >> > configurations together with the corresponding 64-bit architectures. >> > (The same should be true for O32 architectures, but that won't happen >> > until the corresponding 64-bit architectures are in the main archive.) >> I won't push N32 architecture to the main Debian archive. >> I just wish the code in the upstream, so I will not have to maintain another >> git repo, and merge patches again and again. >> >> In fact, I may build a standalone N32 private archive in future. > > I will still insist that N32 architectures do not have their own > kernels, only userland packages (linux-libc-dev, linux-kbuild, linux- > perf, etc.) Yes, so mipsn32/mipsn32el architectures has the same flavors with mips64/mips64el. N32 here is about 2 new architectures named mipsn32/mipsn32el. To make these architectures installable, they must have their own kernel packages, like linux-image-4.6.0-1-loongson-3_$(THE_VERSION).mipsn32el.deb. This package has the same content with: linux-image-4.6.0-1-loongson-3_$(THE_VERSION).mips64el.deb. > >> > [...] >> > > >> > > --- a/debian/config/defines >> > > +++ b/debian/config/defines >> > > @@ -13,8 +13,16 @@ arches: >> > > m68k >> > > mips >> > > mipsel >> > > + mipsn32 >> > > + mipsn32el >> > > mips64 >> > > mips64el >> > > + mipsr6 >> > > + mipsr6el >> > > + mipsn32r6 >> > > + mipsn32r6el >> > > + mips64r6 >> > > + mips64r6el >> > [...] >> > >> > This is ridiculous. 12 different Debian architectures for MIPS?! If >> > you want to make ARM look like a better choice, this sort of >> > fragmentation of binary compatibility is a good way to do it. >> > >> > Why are there new Debian architectures specifically for R6, given that >> > Debian architectures correspond to ABIs and not specific CPU >> > requirements (e.g.. i386's CPU requirements have graudally moved up >> > from 386 to 686-class)? >> Please see the talk on >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807340 >> >> MIPS R6 is a new release of MIPS32 and MIPS64. >> R6 is not fully compatible with R5-, >> as it adds and *removes* some instructions, and add emulation >> of the removed instructions in kernel, >> so old binaries can still run on new R6 CPUs. > > That's quite amazing. But it's even worse that that - the architecture > reference you linked to says some of the removed instructions' > encodings have been reassigned to new instructions. This seems to make > emulation impossible. > >> While for the new CPUs, we still wish they can have their own architectures. > > I suppose they will have to. > > Ben. > >> In future, we may add them to the official Debian archive, >> while now, it is just a prepare. > > > -- > Ben Hutchings > You can't have everything. Where would you put it? -- YunQiang Su
Bug#825024: linux: add MIPS r6 and N32 support
On Mon, May 23, 2016 at 2:30 AM, Ben Hutchings <b...@decadent.org.uk> wrote: > Control: tag -1 moreinfo > > On Sun, 2016-05-22 at 22:52 +0800, YunQiang Su wrote: >> Package: src:linux >> Version: 4.5 - 4.6 >> >> Hi, this patch add mipsn32 and mipsn32el support and also add >> 6 MIPS r6 architectures. >> >> mipsn32 and mipsn32el have same flavors with mips64 and mips64el. > > Since we have multiarch it is not necessary to duplicate kernel > packages with identical configurations in multiple Debian > architectures. All the N32 architectures should be used in multiarch > configurations together with the corresponding 64-bit architectures. > (The same should be true for O32 architectures, but that won't happen > until the corresponding 64-bit architectures are in the main archive.) I won't push N32 architecture to the main Debian archive. I just wish the code in the upstream, so I will not have to maintain another git repo, and merge patches again and again. In fact, I may build a standalone N32 private archive in future. > > [...] >> --- a/debian/config/defines >> +++ b/debian/config/defines >> @@ -13,8 +13,16 @@ arches: >> m68k >> mips >> mipsel >> + mipsn32 >> + mipsn32el >> mips64 >> mips64el >> + mipsr6 >> + mipsr6el >> + mipsn32r6 >> + mipsn32r6el >> + mips64r6 >> + mips64r6el > [...] > > This is ridiculous. 12 different Debian architectures for MIPS?! If > you want to make ARM look like a better choice, this sort of > fragmentation of binary compatibility is a good way to do it. > > Why are there new Debian architectures specifically for R6, given that > Debian architectures correspond to ABIs and not specific CPU > requirements (e.g.. i386's CPU requirements have graudally moved up > from 386 to 686-class)? Please see the talk on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807340 MIPS R6 is a new release of MIPS32 and MIPS64. R6 is not fully compatible with R5-, as it adds and *removes* some instructions, and add emulation of the removed instructions in kernel, so old binaries can still run on new R6 CPUs. While for the new CPUs, we still wish they can have their own architectures. In future, we may add them to the official Debian archive, while now, it is just a prepare. > > Ben. > > -- > Ben Hutchings > friends: People who know you well, but like you anyway. -- YunQiang Su
Bug#825024: linux: add MIPS r6 and N32 support
Package: src:linux Version: 4.5 - 4.6 Hi, this patch add mipsn32 and mipsn32el support and also add 6 MIPS r6 architectures. mipsn32 and mipsn32el have same flavors with mips64 and mips64el. MIPSr6/N64/N32 architectures only have one flavor, and O32 has 2 flavors. -- YunQiang Su diff --git a/debian/config/defines b/debian/config/defines index 412966a..9597897 100644 --- a/debian/config/defines +++ b/debian/config/defines @@ -13,8 +13,16 @@ arches: m68k mips mipsel + mipsn32 + mipsn32el mips64 mips64el + mipsr6 + mipsr6el + mipsn32r6 + mipsn32r6el + mips64r6 + mips64r6el or1k powerpc powerpcspe diff --git a/debian/config/kernelarch-mips/config.r6-32 b/debian/config/kernelarch-mips/config.r6-32 new file mode 100644 index 000..4b51d60 --- /dev/null +++ b/debian/config/kernelarch-mips/config.r6-32 @@ -0,0 +1,570 @@ +## +## file: arch/mips/Kconfig +## +## choice: System type +CONFIG_MIPS_MALTA=y +## end choice +## choice: CPU type +CONFIG_CPU_MIPS32_R6=y +## end choice +## choice: Kernel code model +CONFIG_32BIT=y +## end choice +## choice: Kernel page size +CONFIG_PAGE_SIZE_4KB=y +## end choice +CONFIG_PCI=y + +## +## file: drivers/ata/Kconfig +## +CONFIG_ATA=y +CONFIG_SATA_AHCI=y +CONFIG_SATA_SIL24=y +CONFIG_SATA_SX4=y +CONFIG_ATA_PIIX=y +CONFIG_SATA_MV=y +CONFIG_SATA_PROMISE=y +CONFIG_SATA_SIL=y +CONFIG_PATA_CMD64X=y +CONFIG_PATA_HPT366=y +CONFIG_PATA_NETCELL=y +CONFIG_PATA_OLDPIIX=y +CONFIG_PATA_PDC2027X=y +CONFIG_PATA_PDC_OLD=y +CONFIG_PATA_SIL680=y +CONFIG_PATA_MPIIX=y +CONFIG_PATA_NS87410=y +CONFIG_ATA_GENERIC=y + +## +## file: drivers/block/Kconfig +## +CONFIG_BLK_DEV_FD=m +CONFIG_BLK_CPQ_CISS_DA=m +CONFIG_CISS_SCSI_TAPE=y +CONFIG_BLK_DEV_DAC960=m +CONFIG_BLK_DEV_UMEM=m +CONFIG_BLK_DEV_SX8=m +CONFIG_CDROM_PKTCDVD=m + +## +## file: drivers/bluetooth/Kconfig +## +CONFIG_BT_HCIUART=m +CONFIG_BT_HCIUART_H4=y +CONFIG_BT_HCIUART_BCSP=y +CONFIG_BT_HCIBCM203X=m +CONFIG_BT_HCIBPA10X=m +CONFIG_BT_HCIBFUSB=m +CONFIG_BT_HCIVHCI=m + +## +## file: drivers/char/Kconfig +## +CONFIG_PRINTER=m +CONFIG_PPDEV=m + +## +## file: drivers/char/ipmi/Kconfig +## +CONFIG_IPMI_HANDLER=m +CONFIG_IPMI_SI=m +CONFIG_IPMI_WATCHDOG=m +CONFIG_IPMI_POWEROFF=m + +## +## file: drivers/gpu/drm/Kconfig +## +CONFIG_DRM=m +CONFIG_DRM_TDFX=m +CONFIG_DRM_R128=m +CONFIG_DRM_RADEON=m +CONFIG_DRM_MGA=m + +## +## file: drivers/hwmon/Kconfig +## +CONFIG_SENSORS_ADM1021=m +CONFIG_SENSORS_ADM1025=m +CONFIG_SENSORS_ADM1026=m +CONFIG_SENSORS_ADM1031=m +CONFIG_SENSORS_DS1621=m +CONFIG_SENSORS_MAX1619=m +CONFIG_SENSORS_LM63=m +CONFIG_SENSORS_LM75=m +CONFIG_SENSORS_LM77=m +CONFIG_SENSORS_LM78=m +CONFIG_SENSORS_LM80=m +CONFIG_SENSORS_LM83=m +CONFIG_SENSORS_LM85=m +CONFIG_SENSORS_LM87=m +CONFIG_SENSORS_LM90=m +CONFIG_SENSORS_LM92=m +CONFIG_SENSORS_PCF8591=m + +## +## file: drivers/i2c/Kconfig +## +CONFIG_I2C=m +CONFIG_I2C_CHARDEV=m + +## +## file: drivers/i2c/busses/Kconfig +## +CONFIG_I2C_PIIX4=m +CONFIG_I2C_PARPORT=m +CONFIG_I2C_PARPORT_LIGHT=m + +## +## file: drivers/input/gameport/Kconfig +## +CONFIG_GAMEPORT=m +CONFIG_GAMEPORT_EMU10K1=m +CONFIG_GAMEPORT_FM801=m + +## +## file: drivers/input/joystick/Kconfig +## +CONFIG_INPUT_JOYSTICK=y + +## +## file: drivers/input/keyboard/Kconfig +## +CONFIG_KEYBOARD_NEWTON=m +CONFIG_KEYBOARD_SUNKBD=m + +## +## file: drivers/input/mouse/Kconfig +## +CONFIG_INPUT_MOUSE=y +CONFIG_MOUSE_PS2=m +CONFIG_MOUSE_SERIAL=m +CONFIG_MOUSE_APPLETOUCH=m +CONFIG_MOUSE_VSXXXAA=m + +## +## file: drivers/input/serio/Kconfig +## +CONFIG_SERIO=y +CONFIG_SERIO_I8042=y +CONFIG_SERIO_SERPORT=m +CONFIG_SERIO_PARKBD=m +CONFIG_SERIO_PCIPS2=y +CONFIG_SERIO_LIBPS2=y +CONFIG_SERIO_RAW=m + +## +## file: drivers/input/touchscreen/Kconfig +## +CONFIG_INPUT_TOUCHSCREEN=y + +## +## file: drivers/mfd/Kconfig +## +CONFIG_MFD_SM501=m + +## +## file: drivers/mmc/Kconfig +## +CONFIG_MMC=m + +## +## file: drivers/mmc/card/Kconfig +## +CONFIG_MMC_BLOCK=m + +## +## file: drivers/mtd/Kconfig +## +CONFIG_MTD_REDBOOT_PARTS=y +CONFIG_FTL=m +CONFIG_NFTL=m +CONFIG_NFTL_RW=y +CONFIG_INFTL=m + +## +## file: drivers/mtd/chips/Kconfig +## +CONFIG_MTD_CFI=m +CONFIG_MTD_JEDECPROBE=m +CONFIG_MTD_CFI_INTELEXT=m +CONFIG_MTD_CFI_AMDSTD=m +CONFIG_MTD_CFI_STAA=m +CONFIG_MTD_RAM=m +CONFIG_MTD_ROM=m +CONFIG_MTD_ABSENT=m + +## +## file: drivers/mtd/devices/Kconfig +## +CONFIG_MTD_PMC551=m +CONFIG_MTD_SLRAM=m +CONFIG_MTD_PHRAM=m +CONFIG_MTD_MTDRAM=m +CONFIG_MTD_BLOCK2MTD=m + +## +## file: drivers/mtd/maps/Kconfig +## +CONFIG_MTD_COMPLEX_MAPPINGS=y +CONFIG_MTD_PHYSMAP=m +CONFIG_MTD_PCI=m + +## +## file: drivers/mtd/nand/Kconfig +## +CONFIG_MTD_NAND=m +CONFIG_MTD_NAND_DISKONCHIP=m + +## +## file: drivers/net/Kconfig +## +CONFIG_NET_FC=y + +## +## file: drivers/net/ethernet/Kconfig +## +CONFIG_FEALNX=m + +## +## file: drivers/net/ethernet/3com/Kconfig +## +CONFIG_NET_VENDOR_3COM=y +CONFIG_VORTEX=m +CONFIG_TYPHOON=m + +## +## file: drivers/net/ethernet/8390/Kconfig +## +CONFIG_NE2K_PCI=m + +## +## file: drivers/net/ethernet/amd/Kconfig +## +CONFIG_AMD8111_ETH=m
Bug#798333: linux: remove loongson 2E/2F support and add octeon to mipsel
Package: src:linux Version: 4.2-1~exp1 We are planning to migrate mips/mipsel to MIPS32R2 from MIPS II. So loongson 2E/2F won't supported any more. So please remove these 2 flavors. On the other hand, please add octeon support to mipsel, as it has been in mips64el now. -- YunQiang Su 0001-remove-Loongson-2E-F-support.patch Description: Binary data 0002-add-octeon-support-to-mipsel.patch Description: Binary data
Bug#776274: linux: add fb-modules for loongson 3
On Mon, 26 Jan 2015 13:45:23 +0800 YunQiang Su wzss...@gmail.com wrote: Package: linux Version: 3.18.3-2~exp1 loongson 3 needs radeon driver, so please add fb-modules for loongson 3. Any consideration of this bug report? -- YunQiang Su
Bug#784945: linux-source: add `debian' directory
Package: src:linux Version: 4.0-1~exp1 Please consider include `debian' directory in linux-source-VERSION package, for example, put `debian' directory as /usr/src/linux-debian-VERSION. This will make something esay, such as build linux-libc-dev for cross. -- YunQiang Su -- 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/cakcpw6vnyxnzloqudqafkgao3av7nphkfgm9mdckxggt7e8...@mail.gmail.com
Bug#761275: Remove 5kc-malta loongson-2e/f and octeon from flavor list of mips64el
Package: src:linux Version: 3.16.2-2 After talking on Debconf14, we are planning switch mips64el back to mips64r2 ISA. So 5kc-malta, and loongson-2e/f don't support mips64r2 ISA, and octeon need patch for little endian. In this patch, we also fix a ftbfs problem, due to lacking of a newline at end of defines file. -- YunQiang Su diff --git a/debian/config/mips64/defines b/debian/config/mips64/defines index 6558f0d..5ff622c 100644 --- a/debian/config/mips64/defines +++ b/debian/config/mips64/defines @@ -30,3 +30,4 @@ hardware-long: Cavium Networks Octeon [octeon_image] configs: kernelarch-mips/config.octeon + diff --git a/debian/config/mips64el/defines b/debian/config/mips64el/defines index 41bc336..0911e9e 100644 --- a/debian/config/mips64el/defines +++ b/debian/config/mips64el/defines @@ -1,10 +1,7 @@ [base] flavours: sb1-bcm91250a - loongson-2e - loongson-2f loongson-3 - octeon kernel-arch: mips [build] @@ -20,28 +17,6 @@ hardware-long: Broadcom BCM91250A systems (aka SWARM) [sb1-bcm91250a_image] configs: kernelarch-mips/config.sb1-bcm91250a -[5kc-malta_description] -hardware: MIPS Malta -hardware-long: MIPS Malta boards - -[5kc-malta_image] -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] -recommends: libc6-loongson2f -configs: kernelarch-mips/config.loongson-2f - [loongson-3_description] hardware: Loongson 3A/3B hardware-long: Loongson 3A or 3B based systems (e.g. from Loongson or Lemote) @@ -49,9 +24,3 @@ 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/installer/mips64el/kernel-versions b/debian/installer/mips64el/kernel-versions index 0759981..d0e38a8 100644 --- a/debian/installer/mips64el/kernel-versions +++ b/debian/installer/mips64el/kernel-versions @@ -1,7 +1,3 @@ # arch version flavour installedname suffix build-depends mips64el - sb1-bcm91250a - y - -mips64el - 5kc-malta - y - -mips64el - loongson-2e - y - -mips64el - loongson-2f - y - mips64el - loongson-3- y - -mips64el - octeon- y - diff --git a/debian/installer/mips64el/modules/mips64el-5kc-malta b/debian/installer/mips64el/modules/mips64el-5kc-malta deleted file mode 12 index 84b512e..000 --- a/debian/installer/mips64el/modules/mips64el-5kc-malta +++ /dev/null @@ -1 +0,0 @@ -../../mips/modules/mips-4kc-malta \ No newline at end of file diff --git a/debian/installer/mips64el/modules/mips64el-loongson-2e b/debian/installer/mips64el/modules/mips64el-loongson-2e deleted file mode 12 index b62930d..000 --- a/debian/installer/mips64el/modules/mips64el-loongson-2e +++ /dev/null @@ -1 +0,0 @@ -../../mipsel/modules/mipsel-loongson-2e \ No newline at end of file diff --git a/debian/installer/mips64el/modules/mips64el-loongson-2f b/debian/installer/mips64el/modules/mips64el-loongson-2f deleted file mode 12 index 58388bb..000 --- a/debian/installer/mips64el/modules/mips64el-loongson-2f +++ /dev/null @@ -1 +0,0 @@ -../../mipsel/modules/mipsel-loongson-2f \ No newline at end of file diff --git a/debian/installer/mips64el/modules/mips64el-octeon b/debian/installer/mips64el/modules/mips64el-octeon deleted file mode 12 index da584c6..000 --- a/debian/installer/mips64el/modules/mips64el-octeon +++ /dev/null @@ -1 +0,0 @@ -../../mips/modules/mips-octeon \ No newline at end of file
Bug#761275: Remove 5kc-malta loongson-2e/f and octeon from flavor list of mips64el
On Sat, Sep 13, 2014 at 12:14 AM, Ben Hutchings b...@decadent.org.uk wrote: On Fri, 2014-09-12 at 18:26 +0800, YunQiang Su wrote: Package: src:linux Version: 3.16.2-2 After talking on Debconf14, we are planning switch mips64el back to mips64r2 ISA. So 5kc-malta, and loongson-2e/f don't support mips64r2 ISA, and octeon need patch for little endian. In this patch, we also fix a ftbfs problem, due to lacking of a newline at end of defines file. No, the 'missing newline' messages in the diff refer to the symlinks. This is normal as the text of a symlink should be a path with no added newline. On IRC, you pointed to the build log: http://mips64el.debian.net/debian/buildlog/l/linux_3.16.2-2/linux_3.16.2-2_mips64el-20140909-1906.build The fatal error is: could not find kernel image at /usr/share/kernel-wedge/commands/install-files line 101, KVERS line 3. Line 3 of debian/installer/mips64el/kernel-versions is for 5kc-malta, which is *not* listed in debian/config/mips64el/defines, i.e. we weren't actually building a kernel with that configuration. That's why removing the rest of its configuration fixes this failure. Yes. Thank you for fixing this problem. In the second build log you pointed to, after you removed these flavours, I found: kernel-wedge install-files 3.16-1 install -D -m 644 debian/linux-image-3.16-1-sb1-bcm91250a/boot/vmlinux-3.16-1-sb1-bcm91250a debian/kernel-image-3.16-1-sb1-bcm91250a-di/boot/vmlinux-3.16-1-sb1-bcm91250a install -d debian/kernel-image-3.16-1-sb1-bcm91250a-di/lib/modules/3.16-1-sb1-bcm91250a install -m 644 debian/linux-image-3.16-1-sb1-bcm91250a/lib/modules/3.16-1-sb1-bcm91250a/modules.builtin debian/linux-image-3.16-1-sb1-bcm91250a/lib/modules/3.16-1-sb1-bcm91250a/modules.order debian/kernel-image-3.16-1-sb1-bcm91250a-di/lib/modules/3.16-1-sb1-bcm91250a/ install -D -m 644 debian/linux-image-3.16-1-sb1-bcm91250a/boot/System.map-3.16-1-sb1-bcm91250a debian/kernel-image-3.16-1-sb1-bcm91250a-di/boot/System.map-3.16-1-sb1-bcm91250a kernel-wedge copy-modules 3.16-1 sb1-bcm91250a 3.16-1-sb1-bcm91250a cannot read /tmp/linux/linux-3.16.2/debian/installer/mips64el/modules/mips64el-sb1-bcm91250a/mips64el-sb1-bcm91250a kernel-wedge find-dups 3.16-1-sb1-bcm91250a kernel-wedge find-unpackaged 3.16-1-sb1-bcm91250a 3.16-1-sb1-bcm91250a These modules from 3.16-1-sb1-bcm91250a are unpackaged: [...] kernel-wedge strip-modules 3.16-1-sb1-bcm91250a install -D -m 644 debian/linux-image-3.16-1-loongson-3/boot/vmlinux-3.16-1-loongson-3 debian/kernel-image-3.16-1-loongson-3-di/boot/vmlinux-3.16-1-loongson-3 install -d debian/kernel-image-3.16-1-loongson-3-di/lib/modules/3.16-1-loongson-3 install -m 644 debian/linux-image-3.16-1-loongson-3/lib/modules/3.16-1-loongson-3/modules.builtin debian/linux-image-3.16-1-loongson-3/lib/modules/3.16-1-loongson-3/modules.order debian/kernel-image-3.16-1-loongson-3-di/lib/modules/3.16-1-loongson-3/ install -D -m 644 debian/linux-image-3.16-1-loongson-3/boot/System.map-3.16-1-loongson-3 debian/kernel-image-3.16-1-loongson-3-di/boot/System.map-3.16-1-loongson-3 kernel-wedge copy-modules 3.16-1 loongson-3 3.16-1-loongson-3 cannot read /tmp/linux/linux-3.16.2/debian/installer/mips64el/modules/mips64el-loongson-3/mips64el-loongson-3 kernel-wedge find-dups 3.16-1-loongson-3 kernel-wedge find-unpackaged 3.16-1-loongson-3 3.16-1-loongson-3 These modules from 3.16-1-loongson-3 are unpackaged: [...] kernel/drivers/staging/speakup/speakup.ko kernel/drivers/staging/speakup/speakup_acntpc.ko kernel/drivers/staging/speakup/speakup_acntsa.ko kernel/drivers/staging/speakup/speakup_apollo.ko kernel/drivers/staging/speakup/speakup_audptr.ko kernel/drivers/staging/speakup/speakup_bns.ko kernel/drivers/staging/speakup/speakup_decext.ko kernel/drivers/staging/speakup/speakup_dectlk.ko kernel/drivers/staging/speakup/speakup_dtlk.ko kernel/drivers/staging/speakup/speakup_dummy.ko kernel/drivers/staging/speakup/speakup_keypc.ko kernel/drivers/staging/speakup/speakup_ltlk.ko kernel/drivers/staging/speakup/speakup_soft.ko kernel/drivers/staging/speakup/speakup_spkout.ko kernel/drivers/staging/speakup/speakup_txprt.ko [...] kernel-wedge strip-modules 3.16-1-loongson-3 kernel-wedge check kernel-image-3.16-1-sb1-bcm91250a-di nic-modules-3.16-1-sb1-bcm91250a-di nic-wireless-modules-3.16-1-sb1-bcm91250a-di nic-shared-modules-3.16-1-sb1-bcm91250a-di usb-serial-modules-3.16-1-sb1-bcm91250a-di ppp-modules-3.16-1-sb1-bcm91250a-di pata-modules-3.16-1-sb1-bcm91250a-di cdrom-core-modules-3.16-1-sb1-bcm91250a-di scsi
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 b
Bug#749688: linux: add mips64 and mips64el support
New 'add mips64 support': I forgot to add mips64 and mips64el into debian/config/defines On Sat, Jun 7, 2014 at 9:00 AM, Yunqiang Su wzss...@gmail.com wrote: On Fri, Jun 6, 2014 at 10:47 AM, Ben Hutchings b...@decadent.org.uk wrote: On Thu, 2014-06-05 at 17:31 +0800, Yunqiang Su wrote: On Mon, Jun 2, 2014 at 7:57 PM, Ben Hutchings b...@decadent.org.uk wrote: [...] diff -Nru linux-3.15~rc7/debian/config/mips64/defines linux-3.15~rc7/debian/config/mips64/defines --- linux-3.15~rc7/debian/config/mips64/defines 1970-01-01 00:00:00.0 + +++ linux-3.15~rc7/debian/config/mips64/defines 2014-05-29 00:26:03.0 + @@ -0,0 +1,50 @@ +[base] +flavours: + r4k-ip22 + r5k-ip32 + sb1-bcm91250a + 5kc-malta + octeon I don't think we should build such a large number of flavours for a new architecture. Most of those machines are obsolete by now. Which one do you think to be kept? sb1-bcm91250a and octeon ? That seems sensible - those would cover all of Debian's own MIPS hardware that can run big-endian. For mips64(eb), only these 2 flavors are kept. [...] diff -Nru linux-3.15~rc7/debian/config/mipsel/defines linux-3.15~rc7/debian/config/mipsel/defines --- linux-3.15~rc7/debian/config/mipsel/defines 2014-05-06 09:37:03.0 + +++ linux-3.15~rc7/debian/config/mipsel/defines 2014-05-29 00:27:04.0 + This patch does a little more than the subject says! @@ -6,6 +6,7 @@ loongson-2e loongson-2f loongson-3 + octeon Is it useful to run Octeon on little-endian mode? I have not very clear for mipsel while we have mips64el only now. Maybe we should keep octeon in mips64el while not in mipsel OK. [...] diff -Nru linux-3.15~rc7/debian/installer/mips64/modules/mips64/btrfs-modules linux-3.15~rc7/debian/installer/mips64/modules/mips64/btrfs-modules --- linux-3.15~rc7/debian/installer/mips64/modules/mips64/btrfs-modules 1970-01-01 00:00:00.0 + +++ linux-3.15~rc7/debian/installer/mips64/modules/mips64/btrfs-modules 2014-05-29 02:20:50.0 + @@ -0,0 +1 @@ +#include btrfs-modules [...] All the installer modules configuration files should be copied *by reference* from mips or mipsel, either using a relative #include or a directory symlink. OK, I will link them, while diff (debdiff) treats them as normal file. That's true, but if you check out the source using svn or git-svn you can make a diff that shows symlinks. git-svn would be best, as you could then split your changes up into multiple patches: 1. Move common MIPS kernel config files to kernelarch-mips 2. Add kernel config files for mips64/mips64el 3. Add installer config files to mips64/mips64el the dsc file is here: http://mips.wicp.net:9998/mips2/temp/ Looking at the new patch: --- linux-3.15~rc8/debian/config/defines2014-05-14 15:41:05.0 + +++ linux-3.15~rc8/debian/config/defines2014-06-05 06:23:54.0 + @@ -14,6 +14,8 @@ m68k mips mipsel + mips64 + mips64el or1k powerpc powerpcspe @@ -25,7 +27,7 @@ sparc sparc64 x32 -compiler: gcc-4.8 +compiler: gcc-4.9 featuresets: none rt This is the default setting for all architectures; you must not change it but instead override it in debian/config/mips64/defines and debian/config/mips64el/defines. [...] diff -Nru linux-3.15~rc8/debian/config/mips/defines linux-3.15~rc8/debian/config/mips/defines --- linux-3.15~rc8/debian/config/mips/defines 2014-05-06 09:37:03.0 + +++ linux-3.15~rc8/debian/config/mips/defines 2014-06-05 05:43:07.0 + @@ -12,29 +12,47 @@ image-file: vmlinux [image] -initramfs: false +initramfs: true install-stem: vmlinux [r4k-ip22_description] I don't think you can simply change this, as some of the boot loaders used on old MIPS systems don't support an initramfs. If it was that simple, we would have done it already! I changed them back now. [...] --- linux-3.15~rc8/debian/installer/mips64el/package-list 1970-01-01 00:00:00.0 + +++ linux-3.15~rc8/debian/installer/mips64el/package-list 2014-06-05 05:59:58.0 + @@ -0,0 +1,11 @@ +# This file is used to build up the control file. The kernel version and +# -di are appended to the package names. Section can be left out. So can +# architecture, which is derived from the files in the modules directory. +# It overwrites specifications from /usr/share/kernel-wedge/package-list. +# +Package: kernel-image +Provides_sb1-bcm91250a: ata-modules, ext2-modules, ext3-modules, ext4-modules, rtc-modules +Provides_5kc-malta: ata-modules, ext2-modules, ext3-modules, ext4-modules, rtc-modules +Provides_loongson-2e: ata-modules, ext2-modules, ext3-modules, ext4-modules, rtc-modules +Provides_loongson-2f: ata-modules, ext2-modules, ext3-modules, ext4-modules, rtc-modules
Bug#723475: linux link with -L/usr/lib
sorry for this mistake bug report On Tue, Sep 17, 2013 at 6:48 PM, YunQiang Su wzss...@gmail.com wrote: Package: linux Version: 3.10.7-1 X-Debbugs-CC: wzss...@gmail.com This package has one or more -L/usr/lib in its build system, which will make it ftbfs if there is libraries under /usr/lib, while is not the default architecture, mips* for example. On mips* systems, /usr/lib is defined as place to hold O32 libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. Beside the way, on the multiarch system like Debian, user may install libraries under /usr/lib by hand. Please use the default search path if you can, and please consider fix this. I will try to fix this bug, while if you can help to fix it, It will be very appreciative. The attachement is the buildlog of this package on mips64el platform. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKcpw6Uh=T+=yupyyqepthg0dzk3m-gt3pyqc2uvdflb3ub...@mail.gmail.com
Bug#723475: linux link with -L/usr/lib
Package: linux Version: 3.10.7-1 X-Debbugs-CC: wzss...@gmail.com This package has one or more -L/usr/lib in its build system, which will make it ftbfs if there is libraries under /usr/lib, while is not the default architecture, mips* for example. On mips* systems, /usr/lib is defined as place to hold O32 libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. Beside the way, on the multiarch system like Debian, user may install libraries under /usr/lib by hand. Please use the default search path if you can, and please consider fix this. I will try to fix this bug, while if you can help to fix it, It will be very appreciative. The attachement is the buildlog of this package on mips64el platform. linux_3.10.7-1_mips64el.build.xz Description: Binary data
Bug#723476: linux-latest link with -L/usr/lib
Package: linux-latest Version: 51 X-Debbugs-CC: wzss...@gmail.com This package has one or more -L/usr/lib in its build system, which will make it ftbfs if there is libraries under /usr/lib, while is not the default architecture, mips* for example. On mips* systems, /usr/lib is defined as place to hold O32 libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. Beside the way, on the multiarch system like Debian, user may install libraries under /usr/lib by hand. Please use the default search path if you can, and please consider fix this. I will try to fix this bug, while if you can help to fix it, It will be very appreciative. The attachement is the buildlog of this package on mips64el platform. linux-latest_51_mips64el.build.xz Description: Binary data
Bug#723476: linux-latest link with -L/usr/lib
sorry for this mistake bug report On Tue, Sep 17, 2013 at 6:48 PM, YunQiang Su wzss...@gmail.com wrote: Package: linux-latest Version: 51 X-Debbugs-CC: wzss...@gmail.com This package has one or more -L/usr/lib in its build system, which will make it ftbfs if there is libraries under /usr/lib, while is not the default architecture, mips* for example. On mips* systems, /usr/lib is defined as place to hold O32 libraries, and /usr/lib32 for N32, and /usr/lib64 is for N64. Beside the way, on the multiarch system like Debian, user may install libraries under /usr/lib by hand. Please use the default search path if you can, and please consider fix this. I will try to fix this bug, while if you can help to fix it, It will be very appreciative. The attachement is the buildlog of this package on mips64el platform. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakcpw6uh5ef7wkz4b0raw+39hsy+hklcu3kd--eaxvlcmv3...@mail.gmail.com
Bug#702245: Thinkpad T410s cannot detect link
Package: linux Version: 3.8-1~experimental.1 After upgrade to 3.8-1~experimental.1, my Thinkpad T410s cannot detect cable link now. While it works well on 3.2, 3.5, 3.6 and 3.7 kernel. lspci shows 00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network Connection (rev 06) -- YunQiang Su -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKcpw6VtbQ++UbY_Kbrnt-woFyjmG=zz=jbq_kc4v_czuq_...@mail.gmail.com
Bug#702245: Thinkpad T410s cannot detect link
On Mon, Mar 4, 2013 at 9:47 PM, Ben Hutchings b...@decadent.org.uk wrote:
Control: tag -1 upstream
Control: forwarded -1 e1000-de...@lists.sourceforge.net
On Mon, 2013-03-04 at 20:58 +0800, YunQiang Su wrote:
Package: linux
Version: 3.8-1~experimental.1
After upgrade to 3.8-1~experimental.1, my Thinkpad T410s cannot detect
cable link now.
While it works well on 3.2, 3.5, 3.6 and 3.7 kernel.
lspci shows
00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network
Connection (rev 06)
I'm forwarding this to the Intel network driver developers.
You will probably need to provide some additional information:
- All boot messages relating to this device
('grep 00:19.0 /var/log/dmesg' should show you them)
syq@syq-t410s sudo grep 00:19.0 /var/log/dmesg
~
[0.739973] pci :00:19.0: [8086:10ea] type 00 class 0x02
[0.740016] pci :00:19.0: reg 10: [mem 0xf250-0xf251]
[0.740037] pci :00:19.0: reg 14: [mem 0xf2525000-0xf2525fff]
[0.740058] pci :00:19.0: reg 18: [io 0x1820-0x183f]
[0.740203] pci :00:19.0: PME# supported from D0 D3hot D3cold
[1.547804] e1000e :00:19.0: setting latency timer to 64
[1.547977] e1000e :00:19.0: Interrupt Throttling Rate
(ints/sec) set to dynamic conservative mode
[1.548068] e1000e :00:19.0: irq 40 for MSI/MSI-X
[1.730393] e1000e :00:19.0 eth0: (PCI Express:2.5GT/s:Width
x1) 5c:ff:35:04:9b:22
[1.730402] e1000e :00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[1.730484] e1000e :00:19.0 eth0: MAC: 9, PHY: 10, PBA No: A002FF-0FF
- Output of 'ethtool eth0' (or whatever the interface name is)
This is run when no cable plugged in.
Settings for eth0:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available
Ben.
--
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.
--
YunQiang Su
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cakcpw6vaw5k7_adwvj-tgeahazzbiquhnuq5hv43zzsxxvq...@mail.gmail.com
Bug#684441: [PATCH v2] [media] rc: ite-cir: Initialise ite_dev::rdev earlier
I see, it only once a day, and now it failed every time and cannot boot at all. I have not idea whether it caused by another changes. On Sun, Sep 16, 2012 at 1:15 PM, Ben Hutchings b...@decadent.org.uk wrote: On Sun, 2012-09-16 at 12:56 +0800, YunQiang Su wrote: I upgrade my system yesterday, and this morning, it panic always, even I boot another system first and reboot. Both the kernel in testing and experimental have this problem. [...] I haven't uploaded a fixed package yet. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKcpw6WiGvbycePghgM3sSaQVJydMmO_Vb7R=lrma3cyeqp...@mail.gmail.com
Bug#684441: [PATCH v2] [media] rc: ite-cir: Initialise ite_dev::rdev earlier
I upgrade my system yesterday, and this morning, it panic always, even I boot another system first and reboot. Both the kernel in testing and experimental have this problem. On Wed, Aug 29, 2012 at 4:48 AM, Luis Henriques luis.henriq...@canonical.com wrote: On Tue, Aug 28, 2012 at 10:09:55AM -0700, Ben Hutchings wrote: On Tue, 2012-08-28 at 12:44 +0100, Luis Henriques wrote: On Mon, Aug 20, 2012 at 12:32:27AM +0100, Ben Hutchings wrote: ite_dev::rdev is currently initialised in ite_probe() after rc_register_device() returns. If a newly registered device is opened quickly enough, we may enable interrupts and try to use ite_dev::rdev before it has been initialised. Move it up to the earliest point we can, right after calling rc_allocate_device(). I believe this is the same bug: https://bugzilla.kernel.org/show_bug.cgi?id=46391 And the bug is present in other IR devices as well. I've sent a proposed fix: http://marc.info/?l=linux-kernelm=134590803109050w=2 It might be a worthwhile fix. But it doesn't fix this bug - after that patch, the driver will still enable its IRQ before initialising ite_dev::rdev. You're absolutely right, sorry for the noise. I should have taken a closer look at your patch. Cheers, -- Luis Ben. Cheers, -- Luis References: http://bugs.debian.org/684441 Reported-and-tested-by: YunQiang Su wzss...@gmail.com Signed-off-by: Ben Hutchings b...@decadent.org.uk Cc: sta...@vger.kernel.org --- Unlike the previous version, this will apply cleanly to the media staging/for_v3.6 branch. Ben. drivers/media/rc/ite-cir.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c index 36fe5a3..24c77a4 100644 --- a/drivers/media/rc/ite-cir.c +++ b/drivers/media/rc/ite-cir.c @@ -1473,6 +1473,7 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id rdev = rc_allocate_device(); if (!rdev) goto failure; + itdev-rdev = rdev; ret = -ENODEV; @@ -1604,7 +1605,6 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id if (ret) goto failure3; - itdev-rdev = rdev; ite_pr(KERN_NOTICE, driver has been successfully loaded\n); return 0; -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein -- YunQiang Su -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakcpw6wvcm99-vzqoofyib7ggknp57corb6e5f3ep2218c1...@mail.gmail.com
Bug#684441: Kernel panic nearly all of the first boot on everyday's morning
For 2 days, it didn't panic. It seems working well. On Mon, Aug 13, 2012 at 5:56 AM, Ben Hutchings b...@decadent.org.uk wrote: On Fri, 2012-08-10 at 10:47 +0800, YunQiang Su wrote: Package: linux Version: 3.2.23-1 Nearly every morning when I boot my laptop, it will kernel panic, then press button to halt, and power on again. It seems that the kernel never panic when the second, third, forth ... boot: only the first time. The attachment is the screenshot and the output of lshw . Both the kernel 3.2 in testing and 3.5 in experimental have the problem. Please test the attached patch, following instructions at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. -- YunQiang Su -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKcpw6U1rDrCN=e8meqobrix4zhv6nl-5buv27fybbf+p7e...@mail.gmail.com
