Bug#1065214: iproute2: recent libc6-dev change causes the RPC support to be dropped

[Aurelien Jarno]

Package: iproute2
Version: 6.7.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-gl...@lists.debian.org
Usertags: libtirpc-dev

Dear maintainer,

Starting with glibc 2.31, support for NIS (libnsl library) has been
moved to a separate libnsl2 package. In order to allow a smooth
transition, a libnsl-dev, which depends on libtirpc-dev, has been added
to the libc6-dev package.

The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1
NMU, as part of the 64-bit time_t transition. This causes the RPC
support in iproute2 (from misc/ss.c) to be dropped, I am not sure it is
something to care about.

Therefore please either:
- Add libtirpc-dev as build dependency
- Disable the RPC support explicitly using --without-rpc so that this
  feature does not depend on the packages installed on the system.

Regards
Aurelien

Re: Ability to further support 32bit architectures

[Aurelien Jarno]

On 2024-01-11 18:38, Aurelien Jarno wrote:
> On 2024-01-11 13:24, Adrian Bunk wrote:
> > On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
> > >...
> > > On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > > > Disabling debug symbols, enabling debug symbol zstd compression, using
> > > > split debug symbols (disabled BTF usage) should help here.
> > > 
> > > Okay, maybe more workarounds exist.  But none of them look really
> > > promising.
> > >...
> > 
> > gcc being a memory hog on for C++ code is a hard problem,
> > and debug symbols for C++ code can be a problem since
> > they might be > 1 GB for some binaries.
> > 
> > But gcc needing more than 4 GB for a small C kernel driver is not
> > a problem for the "Ability to further support 32bit architectures",
> > that's a gcc bug that should be reported upstream just like you wouldn't
> > suggest dropping amd64 if gcc would ICE on one kernel driver on that
> > architecture.
> 
> Or maybe just blame the kernel instead:
> https://lore.kernel.org/lkml/CAHk-=whkGHOmpM_1kNgzX1UDAs10+UuALcpeEWN29EE0m-my=w...@mail.gmail.com/

And following the suggestion in that thread, I have just sent a patch fixing 
the issue:
https://lore.kernel.org/lkml/20240113183334.1690740-1-aurel...@aurel32.net/T/#u


-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Re: Ability to further support 32bit architectures

[Aurelien Jarno]

On 2024-01-11 13:24, Adrian Bunk wrote:
> On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
> >...
> > On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > > Disabling debug symbols, enabling debug symbol zstd compression, using
> > > split debug symbols (disabled BTF usage) should help here.
> > 
> > Okay, maybe more workarounds exist.  But none of them look really
> > promising.
> >...
> 
> gcc being a memory hog on for C++ code is a hard problem,
> and debug symbols for C++ code can be a problem since
> they might be > 1 GB for some binaries.
> 
> But gcc needing more than 4 GB for a small C kernel driver is not
> a problem for the "Ability to further support 32bit architectures",
> that's a gcc bug that should be reported upstream just like you wouldn't
> suggest dropping amd64 if gcc would ICE on one kernel driver on that
> architecture.

Or maybe just blame the kernel instead:
https://lore.kernel.org/lkml/CAHk-=whkGHOmpM_1kNgzX1UDAs10+UuALcpeEWN29EE0m-my=w...@mail.gmail.com/

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1035587: linux: broken AHCI controller on MIPS Loongson 3 (regression from 5.10.162-1)

[Aurelien Jarno]

Hi,

On 2023-10-30 09:46, Julien Cristau wrote:
> Hi,
> 
> On Mon, Oct  9, 2023 at 09:08:31 +0100, Jiaxun Yang wrote:
> 
> > 
> > 
> > 在2023年10月8日十月 上午11:11，Aurelien Jarno写道：
> > > On 2023-07-19 16:28, Jiaxun Yang wrote:
> > >> 
> > >> 
> > >> 在 2023/7/8 18:11, Aurelien Jarno 写道:
> > >> [...]
> > >> > Any news about that? We need to be able to run the latest stable kernel
> > >> > on the build daemon.
> > >> 
> > >> Hi all,
> > >> 
> > >> After receiving more reports on that patch I think we shoud workaround 
> > >> it in
> > >> Kernel.
> > >> 
> > >> I had posted a patch to kernel, kernel bug tracker [1].
> > >> 
> > >> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217680
> > >
> > > Any news about that? I haven't spotted any fix for this in Linus' tree
> > > nor in next.
> > 
> > Still waiting for a response from PCI folks.
> > Will resend the patch later.
> > 
> Any news on this?  It's been several months...

Gentle ping about the issue.

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1055021: linux: mips64el loongson3 kernel crashes when running cmake

[Aurelien Jarno]

Source: linux
Version: 5.10.197-1
Severity: grave
Tags: upstream patch
X-Debbugs-Cc: d...@debian.org, debian-m...@lists.debian.org

The loongson3 flavour of the mips64el kernel crash when running cmake:

| [ 4390.501529] do_cpu invoked from kernel context![#1]:
| [ 4390.506483] CPU: 3 PID: 24061 Comm: iou-sqp-22284 Not tainted 
5.10.0-26-loongson-3 #1 Debian 5.10.197-1
| [ 4390.515820] Hardware name: Loongson 
Lemote-3A4000-7A-1w-V1.00-A1901/Lemote-3A4000-7A-1w-V1.00-A1901, BIOS 
Loongson-PMON-V3.3-20201222 12/22/2020
| [ 4390.528699] $ 0 :  80bf9030 0001 
98020f844000
| [ 4390.536669] $ 4 : 9801017bb2c0 80dbc0b8 0008 
02008200
| [ 4390.544634] $ 8 : 0001 0001  
02e27c19
| [ 4390.552600] $12 : 5400cce0 80199c00 01ea 
01ea
| [ 4390.560565] $16 : 980100253700 80ecc740  
9800023cb8c0
| [ 4390.568530] $20 : 80ecdce0 9801017bb2c0 9801017bb8e0 

| [ 4390.576495] $24 : 0028 98020f847e58
| [ 4390.584461] $28 : 98020f844000 98020f847d40 9800023cb8c0 
80bf925c
| [ 4390.592426] Hi : 00de
| [ 4390.595974] Lo : d70a40ec
| [ 4390.599532] epc : 802177c0 _save_fp+0x10/0xa0
| [ 4390.604727] ra : 80bf925c __schedule+0x804/0xe08
| [ 4390.610263] Status: 5400cce2 KX SX UX KERNEL EXL
| [ 4390.614949] Cause : 102c (ExcCode 0b)
| [ 4390.618930] PrId : 0014c004 (ICT Loongson-3)
| [ 4390.623257] Modules linked in: asix usbnet mii sg ip6t_REJECT 
nf_reject_ipv6 ip6table_filter ip6_tables nfnetlink_log nfnetlink xt_hashlimit 
ipt_REJECT nf_reject_ipv4 xt_NFLOG xt_multiport xt_tcpudp xt_state xt_conntrack 
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter sch_fq 
tcp_bbr fuse drm drm_panel_orientation_quirks configfs ip_tables x_tables 
autofs4 ext4 crc16 mbcache jbd2 crc32c_generic ohci_pci dm_mod r8169 realtek 
mdio_devres ohci_hcd ehci_pci of_mdio xhci_pci xhci_hcd ehci_hcd fixed_phy 
libphy usbcore usb_common
| [ 4390.671116] Process iou-sqp-22284 (pid: 24061, 
threadinfo=743a6e5b, task=63cca72a, tls=00fff0de98e0)
| [ 4390.681930] Stack : 80ed  80ed 
98020f6e8c40
| [ 4390.689897] 98020004 d37c8307c148dccb 9801017bb2c0 

| [ 4390.697863]  0001 90
| [ 4390.721759] 980104957480 98020f6e8c00  
80ed
| [ 4390.729724] 98020f6e8c40 98020f6e8c08  

| [ 4390.737689]  9801017bb2c0 802c61f8 
98020f6e8c48
| [ 4390.745655] 98020f6e8c48 2d7071732d756f69 003438323232 
d37c8307c148dccb
| [ 4390.753621] 807106e0 98020f6e8c00 9801097e90c8 
7400cce0
| [ 4390.761588] ...
| [ 4390.764017] Call Trace:
| [ 4390.766453] [] _save_fp+0x10/0xa0
| [ 4390.771306] [] __schedule+0x804/0xe08
| [ 4390.776497] [] schedule+0x58/0x150
| [ 4390.781432] [] io_sq_thread+0x550/0x578
| [ 4390.786798] [] ret_from_kernel_thread+0x14/0x1c
| [ 4390.792856]
| [ 4390.794330] Code: 000c6940 05a10011   f4830b10 f4850b30 
f4870b50 f4890b70 f48b0b90
| [ 4390.804038]
| [ 4411.502993] rcu: INFO: rcu_preempt self-detected stall on CPU
| [ 4411.508728] rcu: 1-...!: (5250 ticks this GP) 
idle=2c6/1/0x4002 softirq=1149627/1149627 fqs=4
| [ 4411.518413] (t=5254 jiffies g=735145 q=4914963)
| [ 4411.522999] rcu: rcu_preempt kthread starved for 5248 jiffies! g735145 
f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=2
| [ 4411.533458] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM 
is now expected behavior.
| [ 4411.542535] rcu: RCU grace-period kthread stack dump:
| [ 4411.547552] task:rcu_preempt state:R stack: 0 pid: 13 ppid: 2 
flags:0x0010
| [ 4411.555860] Stack : 80ed 80bff978 80ed 
8031bbd4
| [ 4411.563826] 0004 d37c8307c148dccb 98010025 
00208040
| [ 4411.571791] 80ed 9801002c7c98 80ed 
80f62ce0
| [ 4411.579756]  0006 0001 
80bf98b8
| [ 4411.587721]  0001000f9aa0  
80bfdb98
| [ 4411.595686] 8030bbc8 5400cce1 80ed 

| [ 4411.603651] 98000236cc78 0001000f9aa0 80319968 
0842
| [ 4411.611617] 98010025 d37c8307c148dccb 80f62a80 

| [ 4411.619582] 80ed 80ed 80ecdce0 
8030b40c
| [ 4411.627548] 80ef11f0 80ed 811f 
80f6
| [ 4411.635515] ...
| [ 4411.637947] Call Trace:
| [ 4411.640384] [] __schedule+0x50c/0xe08
| [ 4411.645586] [] schedule+0x58/0x150
| [ 4411.650527] [] schedule_timeout+0x98/0x1e8
| [ 4411.656156] 

Bug#1035587: linux: broken AHCI controller on MIPS Loongson 3 (regression from 5.10.162-1)

[Aurelien Jarno]

On 2023-07-19 16:28, Jiaxun Yang wrote:
> 
> 
> 在 2023/7/8 18:11, Aurelien Jarno 写道:
> [...]
> > Any news about that? We need to be able to run the latest stable kernel
> > on the build daemon.
> 
> Hi all,
> 
> After receiving more reports on that patch I think we shoud workaround it in
> Kernel.
> 
> I had posted a patch to kernel, kernel bug tracker [1].
> 
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217680

Any news about that? I haven't spotted any fix for this in Linus' tree
nor in next.

Thanks
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1050587: linux: cpufreq-dt requires manually loading cpufreq-dt-platdev (6.5 regression)

[Aurelien Jarno]

Source: linux
Version: 6.5~rc7-1~exp1
Severity: normal
Tags: upstream

Starting with kernel 6.5, the cpufreq-dt-platdev driver can be built as
module [1]. This is done through the CPUFREQ_DT_PLATDEV config, which is
selected by CPUFREQ_DT. However the cpufreq-dt-platdev is not
autoloaded.

On the configs enabling the CPUFREQ_DT module, that is armel/rpi, armhf
and arm64, this means that CPUFREQ_DT_PLATDEV is changed from built-in
in 6.4 to module in 6.5. In turns this means that cpufreq is not
supported anymore unless the cpufreq-dt-platdev is manually loaded.
Tested on a RK3568 based ODROID-M1 board.

We should probably force CPUFREQ_DT_PLATDEV=y on the configs where
CPUFREQ_DT=m.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.5-rc7=3b062a086984d35a3c6d3a1c7841d0aa73aa76af

Bug#1035587: linux: broken AHCI controller on MIPS Loongson 3 (regression from 5.10.162-1)

[Aurelien Jarno]

Hi,

On 2023-06-24 11:46, Aurelien Jarno wrote:
> Hi,
> 
> On 2023-06-19 09:37, Huacai Chen wrote:
> > On Sun, Jun 18, 2023 at 5:24 PM Aurelien Jarno  wrote:
> > >
> > > Hi,
> > >
> > > On 2023-05-07 19:22, Jiaxun Yang wrote:
> > > >
> > > >
> > > > > 2023年5月6日 01:58，YunQiang Su  写道：
> > > > >
> > > > > 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.
> > > >
> > > > I’m unable to reproduce on my side. Perhaps different hardware.
> > > > Is it possible to bisect Kernel on that machine to see of reverting 
> > > > that two commits do help?
> > >
> > > I have bisected the issue and I confirm the intuition from Cyril. The
> > > first bad commit is 654ae539254d10042869fdc77ad04c09e7eff1fd. Reverting
> > > both commits (they are linked) indeed fixes the issue.
> > Seems a firmware bug, latest firmware should configure a suitable MRRS.
> 
> Ok, thanks for the feedback. Given it's not a kernel bug, I am closing
> it.
> 
> That said, can someone please send us the procedure to upgrade the
> firmware on this machine, so that we can continue using it as a buildd?

Any news about that? We need to be able to run the latest stable kernel
on the build daemon.

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1035587: linux: broken AHCI controller on MIPS Loongson 3 (regression from 5.10.162-1)

[Aurelien Jarno]

Hi,

On 2023-05-07 19:22, Jiaxun Yang wrote:
> 
> 
> > 2023年5月6日 01:58，YunQiang Su  写道：
> > 
> > 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.
> 
> I’m unable to reproduce on my side. Perhaps different hardware.
> Is it possible to bisect Kernel on that machine to see of reverting that two 
> commits do help?

I have bisected the issue and I confirm the intuition from Cyril. The
first bad commit is 654ae539254d10042869fdc77ad04c09e7eff1fd. Reverting
both commits (they are linked) indeed fixes the issue.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1035587: linux: broken AHCI controller on MIPS Loongson 3 (regression from 5.10.162-1)

[Aurelien Jarno]

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.

You'll find attached the output of /proc/cpuinfo, lspci and the full
boot log.
PMON2000 MIPS Initializing. Standby...

node 0 N Voltage  write :
v ctrl err

node 0 N Voltage  read :
00080760uV 

node 0 P Voltage write :

0xbfe00190  : 5282a9b7b7a7
CPU CLK SEL : 0002
MEM CLK SEL : 0014
HT CLK SEL : 0014
Disable HT0 clock
Change the scale of HT1 clock
Change the scale of LS132 clock

BBGEN start  :
BBGEN config value  :00ff6431
Soft CLK SEL adjust begin
CORE & NODE:
Miku MAGIC Mismtach
04110c85
MEM   :0909017b
fdcoefficient  :0004
HT:
SYS_LOOPC:0012

DDR_LOOPC:0024
NO TLB cache init ...
Jump to 9fc
32 bit PCI space translate to 64 bit HT space

Check HT bus up.
01110020
set LS7A MISC and confbus base address done.
3A HT in soft freq cfg mode...ok
7A HT in soft freq cfg mode...ok

PLL check success.
Wait HT bus up.01110020>
01110020
Set 7A side HT:
Set width
0020
Set Freq
82251060
Set soft config
008a810a
Set Gen3 mode
81237008
Set retry mode
0081
Enable scrambling
0078
set buffer num
0fff
Set CPU side HT:
Set width
0020
Set Freq
82250060
Set soft config
0087c10a
Set GEN3 mode
81237008
Set retry mode
0081
Enable scrambling
0078
Reset Node 0 HT1-lo bus
0040
Wait HT bus down.>
0010

Dereset Node 0 HT1 bus

Wait HT bus up.>
0020

After reconnect, PLL check success.
Checking Node 0 HT1 CRC error.>
Checking Bridge HT CRC error bit.>
LS3A-7A linkup.
Disable ht regs.

Start Init Memory, wait a while..
NODE 0 MEMORY CONFIG BEGIN

Lock Scache
Lock Scache Done.

Probing DDR MC0 SLOT: 
Slot 0: s1 = 0x00114008__c3004000

Slot 1: s1 = 0x__

 T5 s1 = 00114008__c3005f00

 t0 = 0x__

Enable register space of MEMORY

init start
908:000f0f0300e1e1c1
 begin Reset MC 
init start
908:000f0f0300e1e1c1
 begin Reset MC 
init start
908:000f200300e1e1c1
 begin Reset MC 
init start
908:0016050a00e1e1c1
 begin Reset MC 
init start
908:001e0ce1e1c1
 begin Reset MC 
init start
908:001b0a0f00e1e1c1
 begin Reset MC 
init start
908:000f0f0200e1e1c1
 begin Reset MC 
init start
908:00200f1400e1e1c1
 begin Reset MC 
init start
908:0007070c00e1e1c1
 begin Reset MC 
init start
908:000f200300e1e1c1
 begin Reset MC 
init start
908:00200f0200e1e1c1
 begin Reset MC 
init start
908:0016160a00e1e1c1
 begin Reset MC 
init start
908:000c0c1100e1e1c1
 begin Reset MC 
init start
908:000f200200e1e1c1
 begin Reset MC 
init start
908:000c0ce1e1c1
 begin Reset MC 
init start
908:000f0f1300e1e1c1
 begin Reset MC 
init start
908:000c1e0100e1e1c1
 begin Reset MC 
init start
908:000c0ce1e1c1
 begin Reset MC 
init start
908:000a0a0f00e1e1c1
 begin Reset MC 
init start
908:0005050a00e1e1c1
init done
Start Hard Leveling...
Enable register space of MEMORY

start training of tPHY_WR

tPHY_WRLAT training successThe MC param after leveling is:
PHY:
:  0011
0008:  0037
0010:  0103
0018:  
0020:  0001
0028:  
0030:  0052010100040510
0038:  0144
0040:  0008002a
0048:  02041c3801010100
0050:  0008002a
0058:  02041c38
0060:  0008002a
0068:  02041c38
0070:  0008002a
0078:  03041c3800010100
0080:  0008002a
0088:  02041c38
0090:  0008002a
0098:  02041c38
00a0:  0008002a
00a8:  02041c38
00b0:  0008002a
00b8:  03041c3800010100
00c0:  0008002a
00c8:  02041c38
00d0:  0008002a
00d8:  02041c38
00e0:  0001ff000f00
00e8:  0001ff000f00
00f0:  0001ff000f00
00f8:  0001ff000f00
0100:  16002016
0108:  001c1918
0110:  820400880080
0118:  00140003
0120:  
0128:  
0130:  
0138:  
0140:  
0148:  
0150:  

Re: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

[Aurelien Jarno]

control: reassign -1 pahole/1.24-4
control: retitle -1 pahole: BTF deduplication issues causing arm64 kernel size 
increase
control: tag -1 + fixed-upstream
control: tag -1 + patch
control: affects -1 u-boot-rpi src:linux

Hi,

On 2023-03-21 23:11, Aurelien Jarno wrote:
> Source: linux
> Version: 6.1.15-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: vagr...@debian.org
> Control: affects -1 + u-boot-rpi
> 
> Hi,
> 
> Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
> Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
> to boot with:
> 
> | 40175552 bytes read in 1695 ms (23 MiB/s)
> | 43794863 bytes read in 1817 ms (23 MiB/s)
> | Moving Image from 0x8 to 0x20, end=299
> | ERROR: RD image overlaps OS image (OS=0x20..0x299)
> 
> I tracked the issue to a significant increase of the kernel size between
> version 6.1.12-1 and 6.15-1:
> 
> | 31492   /boot/vmlinuz-6.1.0-5-arm64
> | 39236   /boot/vmlinuz-6.1.0-6-arm64
> 
> This is more than the 36MB that is allowed by u-boot with the default
> load addresses. A workaround is to shift the load addresses at the
> u-boot level as in the attached patch.
> 
> I have tracked issue on the upstream kernel side to the following commit
> on the stable tree:
> 
> | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
> | Author: Masahiro Yamada 
> | Date:   Thu Oct 13 08:35:00 2022 +0900
> | 
> | arm64: remove special treatment for the link order of head.o
> | 
> | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
> | 
> | In the previous discussion (see the Link tag), Ard pointed out that
> | arm/arm64/kernel/head.o does not need any special treatment - the only
> | piece that must appear right at the start of the binary image is the
> | image header which is emitted into .head.text.
> | 
> | The linker script does the right thing to do. The build system does
> | not need to manipulate the link order of head.o.
> | 
> | Link: 
> https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
> | Suggested-by: Ard Biesheuvel 
> | Signed-off-by: Masahiro Yamada 
> | Reviewed-by: Nicolas Schier 
> | Link: 
> https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
> | Signed-off-by: Will Deacon 
> | Signed-off-by: Tom Saeger 
> | Signed-off-by: Greg Kroah-Hartman 
> 
> The problem is still reproducible on Linus' master.
> 
> I am reporting the bug to the linux package as I believed there is no
> real reason for such an increase in the kernel size. In case I missed
> something and this is actually wanted, the bug can be reassigned to the
> u-boot package.

This has been discussed upstream, and it appears that the issue is not
reproducible with pahole 1.25. Looking at the part that needs to be
backported to the Debian package, I have found that the issue is caused
by the following patch backported in version 1.24-4:

02-encode-DW_TAG_unspecified_type-returning-routines-as-void.patch

This patch has an issue, and memory is not initialized after allocation,
so garbage values are used instead. A one-liner fix has been committed
upstream not so long after the initial patch:

https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=b72f5188856df0abf45e1a707856bb4e4e86153c

I am therefore reassigning the bug to pahole where the bug should be
fixed. Even if Bookworm is now fully frozen, I personally believe this
bug should still be fixed before the release. That said, this has to be
discussed with the release team, and as pahole is a key package you need
a pre-approval *before* the upload to sid. 

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

[Aurelien Jarno]

On 2023-03-24 13:58, Vagrant Cascadian wrote:
> Adding u-boot maintainers for rpi (Matthias Brugger, Peter Robinson)
> platforms and u-boot list to CC.
> 
> On 2023-03-22, Salvatore Bonaccorso wrote:
> > Thanks for tracking this down. I would like to loop in Masahiro and
> > upstream to see if something can/should be done on upstream side.
> >
> > Masahiro, in short, upstream change 994b7ac1697b ("arm64: remove
> > special treatment for the link order of head.o") (which got backported
> > as well to 6.1.14) caused the vmlinuz size to icrease significantly,
> > causing boot failures on Raspberry Pi 3 Model B Plus with u-boot
> > parameters previously working. Full quoting the Debian report below
> 
> In general it would be nice to not have the kernel grow nearly 25% in
> size from a single commit; was that an expected outcome from the above
> upstream change? Was the "special treament" originally done to keep the
> kernel size down?

This is currently being tracked [1], but the issue seems to be linked to
the version of the tools used in Debian, and the fact that we build our
kernels with BTF support, so the issue is likely to be difficult to find.

[1] https://lore.kernel.org/linux-arm-kernel/zbovcrmxjk7np...@aurel32.net/

> As for u-boot, It seems u-boot might need to update the various load
> addresses for the kernel, device tree and ramdisk at some point
> regardless of weather this particular issue gets fixed in the kernel, as
> the kernel will likely continue to grow a bit over time...

Yes that's probably a sane thing to do, at least in Debian.

> Aurelien Jarno included a patch referenced below which bumps the
> tolerances in u-boot from 36MB to 42MB.
> 
> 
> > On Tue, Mar 21, 2023 at 11:11:13PM +0100, Aurelien Jarno wrote:
> >> Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
> >> Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
> >> to boot with:
> >> 
> >> | 40175552 bytes read in 1695 ms (23 MiB/s)
> >> | 43794863 bytes read in 1817 ms (23 MiB/s)
> >> | Moving Image from 0x8 to 0x20, end=299
> >> | ERROR: RD image overlaps OS image (OS=0x20..0x299)
> >> 
> >> I tracked the issue to a significant increase of the kernel size between
> >> version 6.1.12-1 and 6.15-1:
> >> 
> >> | 31492   /boot/vmlinuz-6.1.0-5-arm64
> >> | 39236   /boot/vmlinuz-6.1.0-6-arm64
> >> 
> >> This is more than the 36MB that is allowed by u-boot with the default
> >> load addresses. A workaround is to shift the load addresses at the
> >> u-boot level as in the attached patch.
> >> 
> >> I have tracked issue on the upstream kernel side to the following commit
> >> on the stable tree:
> >> 
> >> | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
> >> | Author: Masahiro Yamada 
> >> | Date:   Thu Oct 13 08:35:00 2022 +0900
> >> | 
> >> | arm64: remove special treatment for the link order of head.o
> >> | 
> >> | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
> >> | 
> >> | In the previous discussion (see the Link tag), Ard pointed out that
> >> | arm/arm64/kernel/head.o does not need any special treatment - the 
> >> only
> >> | piece that must appear right at the start of the binary image is the
> >> | image header which is emitted into .head.text.
> >> | 
> >> | The linker script does the right thing to do. The build system does
> >> | not need to manipulate the link order of head.o.
> >> | 
> >> | Link: 
> >> https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
> >> | Suggested-by: Ard Biesheuvel 
> >> | Signed-off-by: Masahiro Yamada 
> >> | Reviewed-by: Nicolas Schier 
> >> | Link: 
> >> https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
> >> | Signed-off-by: Will Deacon 
> >> | Signed-off-by: Tom Saeger 
> >> | Signed-off-by: Greg Kroah-Hartman 
> >> 
> >> The problem is still reproducible on Linus' master.
> >> 
> >> I am reporting the bug to the linux package as I believed there is no
> >> real reason for such an increase in the kernel size. In case I missed
> >> something and this is actually wanted, the bug can be reassigned to the
> >> u-boot package.
> >> 
> >> Regards
> >> Aurelien
> >
> >> --- u-boot-2023.01+dfsg.orig/include/configs/rpi.h

Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

[Aurelien Jarno]

Source: linux
Version: 6.1.15-1
Severity: important
Tags: upstream
X-Debbugs-Cc: vagr...@debian.org
Control: affects -1 + u-boot-rpi

Hi,

Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
to boot with:

| 40175552 bytes read in 1695 ms (23 MiB/s)
| 43794863 bytes read in 1817 ms (23 MiB/s)
| Moving Image from 0x8 to 0x20, end=299
| ERROR: RD image overlaps OS image (OS=0x20..0x299)

I tracked the issue to a significant increase of the kernel size between
version 6.1.12-1 and 6.15-1:

| 31492   /boot/vmlinuz-6.1.0-5-arm64
| 39236   /boot/vmlinuz-6.1.0-6-arm64

This is more than the 36MB that is allowed by u-boot with the default
load addresses. A workaround is to shift the load addresses at the
u-boot level as in the attached patch.

I have tracked issue on the upstream kernel side to the following commit
on the stable tree:

| commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
| Author: Masahiro Yamada 
| Date:   Thu Oct 13 08:35:00 2022 +0900
| 
| arm64: remove special treatment for the link order of head.o
| 
| commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
| 
| In the previous discussion (see the Link tag), Ard pointed out that
| arm/arm64/kernel/head.o does not need any special treatment - the only
| piece that must appear right at the start of the binary image is the
| image header which is emitted into .head.text.
| 
| The linker script does the right thing to do. The build system does
| not need to manipulate the link order of head.o.
| 
| Link: 
https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
| Suggested-by: Ard Biesheuvel 
| Signed-off-by: Masahiro Yamada 
| Reviewed-by: Nicolas Schier 
| Link: 
https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
| Signed-off-by: Will Deacon 
| Signed-off-by: Tom Saeger 
| Signed-off-by: Greg Kroah-Hartman 

The problem is still reproducible on Linus' master.

I am reporting the bug to the linux package as I believed there is no
real reason for such an increase in the kernel size. In case I missed
something and this is actually wanted, the bug can be reassigned to the
u-boot package.

Regards
Aurelien
--- u-boot-2023.01+dfsg.orig/include/configs/rpi.h
+++ u-boot-2023.01+dfsg/include/configs/rpi.h
@@ -95,32 +95,32 @@
  *   text_offset bytes (specified in the header of the Image) into a 2MB
  *   boundary. The 'booti' command relocates the image if necessary. Linux uses
  *   a default text_offset of 0x8.  In summary, loading at 0x8
- *   satisfies all these constraints and reserving memory up to 0x0240
- *   permits fairly large (roughly 36M) kernels.
+ *   satisfies all these constraints and reserving memory up to 0x02a0
+ *   permits fairly large (roughly 42M) kernels.
  *
  * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
  * conflict with something else. Reserving 1M for each of them at
- * 0x0240-0x0250 and 0x0250-0x0260 should be plenty.
+ * 0x02a0-0x02b0 and 0x02c0-0x02d0 should be plenty.
  *
  * On ARM, both the DTB and any possible initrd must be loaded such that they
  * fit inside the lowmem mapping in Linux. In practice, this usually means not
  * more than ~700M away from the start of the kernel image but this number can
  * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
  * parameter given to the kernel. So reserving memory from low to high
- * satisfies this constraint again. Reserving 1M at 0x0260-0x0270 for
- * the DTB leaves rest of the free RAM to the initrd starting at 0x0270.
+ * satisfies this constraint again. Reserving 1M at 0x02c0-0x02d0 for
+ * the DTB leaves rest of the free RAM to the initrd starting at 0x02d0.
  * Even with the smallest possible CPU-GPU memory split of the CPU getting
- * only 64M, the remaining 25M starting at 0x0270 should allow quite
+ * only 64M, the remaining 19M starting at 0x02d0 should allow quite
  * large initrds before they start colliding with U-Boot.
  */
 #define ENV_MEM_LAYOUT_SETTINGS \
"fdt_high=" FDT_HIGH "\0" \
"initrd_high=" INITRD_HIGH "\0" \
"kernel_addr_r=0x0008\0" \
-   "scriptaddr=0x0240\0" \
-   "pxefile_addr_r=0x0250\0" \
-   "fdt_addr_r=0x0260\0" \
-   "ramdisk_addr_r=0x0270\0"
+   "scriptaddr=0x02a0\0" \
+   "pxefile_addr_r=0x02b0\0" \
+   "fdt_addr_r=0x02c0\0" \
+   "ramdisk_addr_r=0x02d0\0"
 
 #if CONFIG_IS_ENABLED(CMD_MMC)
#define BOOT_TARGET_MMC(func) \

Re: Bug#1003223: buildd.debian.org: exFAT do no work on internal hard drives.

[Aurelien Jarno]

control: reassign -1 src:linux

On 2022-01-06 16:07, Mats Lundström wrote:
> Package: buildd.debian.org

exfat support is provided by the kernel and has nothing to do with
buildd.debian.org. Reassigning the bug there.

> Severity: important
> X-Debbugs-Cc: t...@digitronics.se
>
> Dear Maintainer,
> 
> 
>* What led up to the situation?
> 
> I am trying to migrate from Windows to Linux due to security, performance and 
> hardware compatibility issues. Some of the software that I use, are available 
> both in 
> Linux and Windows, so I have been doing some performance tests. Fastest is 
> Linux (tried Lubuntu, Ubuntu and Debian and it don't matter which one), just 
> followed by
> Windows 7. Windows 10 is way behind, due to constant external communication 
> with unknown source (have seen this clearly at my work) and sometimes forced 
> reboots due
> to forced system updates (this can't be tured off in Windows 10 ...) The 
> latter is a problem, when running software 24/7 that can't resume properly at 
> reboot without
> manual interaction. If this happen when at work or during the night, the 
> computer will idle. Windows 7 (SP1) is in many ways better than Windows 10, 
> but have issues
> when trying to install it on newer systems. (Systems with i5/i7/i9 and 
> chipset Z490/Z590 blocks any Windows 7 installation ...) With 35.5 years of 
> [prof.] hardware
> and software experience, I am still convinced that Windows 7 is the best 
> Windows version, despite some would say that it lacks security. By own 
> experience, Windows
> 10 isn't actually any better though, but rather worse.
> 
> 
>* What exactly did you do (or not do) that was effective (or ineffective)?
> 
> I do stuff, including professional work related, that still are only possible 
> on Windows computers. Therefore I intend to create a dual boot system and 
> need a hard
> drive with data, that can be read properly by both Linux and Windows. A hard 
> drive that uses NTFS have issues in Linux and a hard drive that uses ext4 is 
> basically
> ignored in Windows (it detects all the partitions though). Using the hard 
> drive with exFAT via USB works, but have stability, mechanical and formost 
> performance
> issues - no go.
> 
> 
>* What was the outcome of this action?
> 
> A complete 'read only' status, that can not be changed what so ever, even 
> logged in as root. Owner of the drive is 'root' and can not be changed 
> either. Have tried
> to fix the problem with a number of HDD utilities, but none of them can do 
> much at all. (Installing a Debian based OS has not been easy, because of 
> reports of assumed
> PCIe [8086: - lost this specific address, unfortunally ...] and MMIO 
> errors with the i9/Z590 system. OS's like Windows, CentOS/Red Hat, OpenSUSE 
> do not detect
> this at all ... OpenSUSE have severe issues with Nvidia drivers ...) Files 
> can be copied to the system drive and edited there, but can only be copied 
> back as a
> duplicate copy. Soon the hard drive will be filled with a number of copies 
> ... (The fastest way to fix this, is to clean up in Windows ...) Have tried 
> to transfer
> the data to new hard drive, to exclude any issues with the hard drive itself, 
> but no difference.
> 
> 
>* What outcome did you expect instead?
> 
> A 'read/write' status. This is somewhat surprising that exFAT has not been 
> included earlier, as the standard has existed since 2006. A hard drive that 
> only can be
> used as 'read only' makes no sense.
> 
> 
> Regards
> 
> Mats Lundström

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#889817: linux: kernel does not always provide a heap [alpha arm64 mips64el ppc64el ppc64 s390x sparc64]

[Aurelien Jarno]

control: fixed 889817 5.2.6-1
control: fixed 889817 4.19.87-1

Hi Salvatore,

On 2021-05-24 08:31, Salvatore Bonaccorso wrote:
> Source: linux
> Source-Version: 5.10.38-1
> 
> Hi,
> 
> On Wed, Feb 07, 2018 at 12:37:44PM +0100, Aurelien Jarno wrote:
> > Source: linux
> > Version: 4.14.13-1
> > Severity: normal
> > Tags: upstream
> > 
> > When ASLR is enabled (which is the default), the Linux kernel on at
> > least alpha, arm64, mips64el, ppc64el, ppc64, s390x and sparc64 might
> > not provide a heap to the program. This is the case for example when
> > the program is run through the program interpreter ld.so. This happens
> > with different probability depending on the architecture. This causes
> > issues with GLIBC tunables support, which needs to be able to reserve
> > a few hundred bytes of memory through brk. This is reproducible with
> > at least kernel 4.9 and 4.15, and it's likely that the issue has always
> > been there.
> > 
> > The following script, based on one from James Cowgill, shows the issue:
> > 
> > #!/bin/bash
> > export LC_ALL=C
> > 
> > interp=$(readelf --headers /bin/cat | grep 'Requesting program interpreter' 
> > | sed -e 's/.*: //' -e 's/]//')
> > 
> > for i in {1..1}
> > do
> > OUT=$($interp /bin/cat /proc/self/maps)
> > if [[ $OUT != *heap* ]]
> > then
> > echo -n F
> > echo "$OUT"
> > else
> > echo -n .
> > fi
> > done
> > 
> > A workaround is to set /proc/sys/kernel/randomize_va_space to 1.
> 
> As discussed on IRC, I was not able to trigger this behaviour with
> 4.19.181-1 on amdahl (arm64), zelenka (s390x) or plummer (ppc64el). So
> guess the issue has been fixed in meanwhile somewhere.
> 
> Not sure it is worth trying to bisect and finding the fixing
> commit(s).

I have found that the problem has been fixed in that upstream commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bbdc6076d2e5d07db44e74c11b01a3e27ab90b32

This commit went into kernel 5.2, and was later backported in kernel
4.19.75.

> But for now closing with all recent versions in supported branches.

This mail should update the version in the BTS to the corresponding
Debian version.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#960152: linux-image-5.6.0-1-arm64: Enable compressed modules

[Aurelien Jarno]

On 2020-05-09 16:09, Vagrant Cascadian wrote:
> Package: src:linux
> Version: 5.6.7-1
> Severity: wishlist
> 
> The on-disk kernel modules take up a significant amount of the package
> installation size, and most modules aren't actively used on any given
> system. In debian-installer, the "on-disk" modules take up space in ram
> during the installation.
> 
> From the linux Makefile:
> 
>   # CONFIG_MODULE_COMPRESS, if defined, will cause module to be compressed
>   # after they are installed in agreement with CONFIG_MODULE_COMPRESS_GZIP
>   # or CONFIG_MODULE_COMPRESS_XZ.
> 
> I'm not sure how to enable it; I don't see it mentioned in any Kconfig
> files. It does appear possible to manually compress the individual .ko
> files as an alternative method, if that is somehow more flexible.
> 
> 
> The kmod utility supports xz compressed modules since version 25-1 (26-1
> is present in buster, the current debian stable release). Unfortunately,

Note that this is not true for the kmod udeb. For that a liblzma5-udeb
package has to be created first.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Re: Bug#948584: libc6: Mounting nfsv4-export from my NAS there is a segfault in libc

[Aurelien Jarno]

control: reassign -1 nfs-utils
control: retitle -1 nfs-utils: unquoted paths in configuration file cause 
crashes

On 2020-01-11 13:35, Bernhard Übelacker wrote:
> Dear Maintainer,
> I could reproduce the crash now in an minimal unstable VM with the
> given config and the command line from the coredumpctl output.
> 
> It seems that the function conf_parse_line is not prepared
> for missing quotation marks for the argument in the section head [1].
> 
> Therefore, if quotes are ommitted, the variable arg gets not filled,
> and therefore the cb->arg contains then a null pointer [2], that leads
> given to strcasecmp to the crash.
> 
> @Miriam: I guess the crash should go away if change the config like following?
> - [ Server mirunas.mirulan.net ]
> - [ MountPoint /media/MiruNAS/Medienwerkstatt ]
> + [ Server "mirunas.mirulan.net" ]
> + [ MountPoint "/media/MiruNAS/Medienwerkstatt" ]
> 

Thanks for the diagnosis. This shows this is not a libc6 issue, but
rather a nfs-utils issue. I am therefore reassigning the bug.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils

[Aurelien Jarno]

On 2019-12-11 09:33, Justin Forbes wrote:
> On Tue, Dec 10, 2019 at 4:26 PM Thadeu Lima de Souza Cascardo
>  wrote:
> >
> > On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote:
> > > On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann  
> > > wrote:
> > > >
> > > > On Mon, Dec 02, 2019 at 04:53:26PM +1100, Michael Ellerman wrote:
> > > > > Aurelien Jarno  writes:
> > > > > > On powerpc with recent versions of binutils, readelf outputs an 
> > > > > > extra
> > > > > > field when dumping the symbols of an object file. For example:
> > > > > >
> > > > > > 35: 083896 FUNCLOCAL  DEFAULT 
> > > > > > [: 8] 1 btf_is_struct
> > > > > >
> > > > > > The extra "[: 8]" prevents the GLOBAL_SYM_COUNT 
> > > > > > variable to
> > > > > > be computed correctly and causes the checkabi target to fail.
> > > > > >
> > > > > > Fix that by looking for the symbol name in the last field instead 
> > > > > > of the
> > > > > > 8th one. This way it should also cope with future extra fields.
> > > > > >
> > > > > > Signed-off-by: Aurelien Jarno 
> > > > > > ---
> > > > > >  tools/lib/bpf/Makefile | 4 ++--
> > > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > > > Thanks for fixing that, it's been on my very long list of test 
> > > > > failures
> > > > > for a while.
> > > > >
> > > > > Tested-by: Michael Ellerman 
> > > >
> > > > Looks good & also continues to work on x86. Applied, thanks!
> > >
> > > This actually seems to break horribly on PPC64le with binutils 2.33.1
> > > resulting in:
> > > Warning: Num of global symbols in sharedobjs/libbpf-in.o (32) does NOT
> > > match with num of versioned symbols in libbpf.so (184). Please make
> > > sure all LIBBPF_API symbols are versioned in libbpf.map.
> > >
> > > This is the only arch that fails, with x86/arm/aarch64/s390 all
> > > building fine.  Reverting this patch allows successful build across
> > > all arches.
> > >
> > > Justin
> >
> > Well, I ended up debugging this same issue and had the same fix as Jarno's 
> > when
> > I noticed his fix was already applied.
> >
> > I just installed a system with the latest binutils, 2.33.1, and it still 
> > breaks
> > without such fix. Can you tell what is the output of the following command 
> > on
> > your system?
> >
> > readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@" -f1 | 
> > sed 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ && !/UND/ 
> > {print $0}'
> >
> 
> readelf -s --wide tools/lib/bpf/sharedobjs/libbpf-in.o | cut -d "@"
> -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | awk '/GLOBAL/ && /DEFAULT/ &&
> !/UND/ {print $0}'
>373: 000141bc  1376 FUNCGLOBAL DEFAULT1 
> libbpf_num_possible_cpus [: 8]
>375: 0001869c   176 FUNCGLOBAL DEFAULT1 btf__free 
> [: 8]

It seems that in your case the localentry part is added after the symbol
name. That doesn't match what is done in upstream binutils:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=binutils/readelf.c;hb=refs/heads/master#l11485

Which version of binutils are you using? It looks like your version has
been modified to workaround this exact issue.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#945879: linux: slab memory leak around 30MB/hour causing OOM on OVH VPS

[Aurelien Jarno]

control: reassign -1 openssh/1:7.9p1-10+deb10u1
control: retitle -1 openssh-server: cgroup leftovers with socket activation 
when key exchange fails

On 2019-11-30 13:52, Aurelien Jarno wrote:
> Package: src:linux
> Version: 4.19.67-2+deb10u2
> Severity: important
> 
> Dear Maintainer,
> 
> Since the latest Debian stable release, I observe a slab memory leak of
> about 30MB/hour when running the kernel 4.19.67-2+deb10u2 on an OVH VPS,
> which causes an all applications to slowly move to swap after a few days,
> and eventually an OOM. You'll find a typical munin memory plot attached
> to the bug report.

[...]

> The problem has been introduced in Debian in kernel 4.19.67-1. I have
> found that the problem has been introduced upstream in the 4.19.66
> release.

It happens that the original problem is due to SSH, just that this new
kernel version makes things way more visible.

When using systemd socket activation the OpenSSH daemon sometimes does
not remove the cgroup created for the connection after the key exchange
algorithm has failed. This usually happens relatively rarely, less than
1% of the time. However on a single CPU system (e.g. VM with a single
vCPU), the problem happens 100% of the time.

To reproduce the problem using a VM:
- Reduce the number of vCPU to 1
- Switch the OpenSSH daemon to systemd socket activation using systemctl
  enable ssh.socket followed by a reboot
- Try to connect to the system with a key exchange algorithm not
  supported on buster. For example
  ssh -o KexAlgorithms=diffie-hellman-group-exchange-sha1 host
- Look at /sys/fs/cgroup/memory/system.slice/system-ssh.slice. Each
  connection leaves an entry in that directory. Each entry takes some
  kernel memory.
- Depending on the available memory and available swap, after a few
  thousands connections the OOM killer kills all the processes making
  the system unusable.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

[PATCH] libbpf: fix readelf output parsing on powerpc with recent binutils

[Aurelien Jarno]

On powerpc with recent versions of binutils, readelf outputs an extra
field when dumping the symbols of an object file. For example:

35: 083896 FUNCLOCAL  DEFAULT [: 8] 1 
btf_is_struct

The extra "[: 8]" prevents the GLOBAL_SYM_COUNT variable to
be computed correctly and causes the checkabi target to fail.

Fix that by looking for the symbol name in the last field instead of the
8th one. This way it should also cope with future extra fields.

Signed-off-by: Aurelien Jarno 
---
 tools/lib/bpf/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 99425d0be6ff..333900cf3f4f 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -147,7 +147,7 @@ TAGS_PROG := $(if $(shell which etags 
2>/dev/null),etags,ctags)
 
 GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN_SHARED) | \
   cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
-  awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}' | \
+  awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$NF}' | 
\
   sort -u | wc -l)
 VERSIONED_SYM_COUNT = $(shell readelf -s --wide $(OUTPUT)libbpf.so | \
  grep -Eo '[^ ]+@LIBBPF_' | cut -d@ -f1 | sort -u 
| wc -l)
@@ -216,7 +216,7 @@ check_abi: $(OUTPUT)libbpf.so
 "versioned in $(VERSION_SCRIPT)." >&2;  \
readelf -s --wide $(OUTPUT)libbpf-in.o | \
cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' |   \
-   awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}'|   \
+   awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$NF}'|  \
sort -u > $(OUTPUT)libbpf_global_syms.tmp;   \
readelf -s --wide $(OUTPUT)libbpf.so |   \
grep -Eo '[^ ]+@LIBBPF_' | cut -d@ -f1 | \
-- 
2.24.0

Bug#904385: arm64: sigaltstack fails with MINSIGSTKSZ for 32-bit processes

[Aurelien Jarno]

control: notfixed -1 linux/4.18.20-1
control: found -1 4.19.37-6

On 2018-09-26 11:41, Steve McIntyre wrote:
> On Wed, Jul 25, 2018 at 04:25:03PM +0100, Steve McIntyre wrote:
> >On Mon, Jul 23, 2018 at 09:40:33PM +0200, Aurelien Jarno wrote:
> >>control: affects -1 glibc
> >>control: found linux/4.17.6-2
> >>
> >>On 2018-07-23 21:31, Aurelien Jarno wrote:
> >>> Package: src:linux
> >>> Version: 4.9.110-1
> >>> Severity: normal
> >>> 
> >>> Dear Maintainer,
> >>> 
> >>> The arm64 kernel allows one to run aarch32 processes on an aarch64
> >>> processor (if it has support for it), using the standard 32/64-bit
> >>> syscall compatibility. However this compat layer does not correctly
> >>> validate the arguments of the sigaltstack syscall.
> >>> 
> >>
> >>I forgot to say that the problem is reproducible with kernel 4.17.6.
> >
> >Fix proposed in https://lkml.org/lkml/2018/7/25/409 
> 
> At Will's suggestion, I've just tested that patchset locally and it
> definitely fixes this problem so I've added a Tested-by: for him.
> 

The fix is composed of two patches, and only the first one went to the
stable releases. Therefore both our oldstable and stable kernels used on
the build daemons are still buggy.

The following one is still missing in at least 4.9 and 4.19:

| commit 24951465cbd279f60b1fdc2421b3694405bcff42
| Author: Will Deacon 
| Date:   Wed Sep 5 15:34:43 2018 +0100
| 
| arm64: compat: Provide definition for COMPAT_SIGMINSTKSZ
| 
| arch/arm/ defines a SIGMINSTKSZ of 2k, so we should use the same value
| for compat tasks.
| 
| Cc: Arnd Bergmann 
| Cc: Dominik Brodowski 
| Cc: "Eric W. Biederman" 
| Cc: Andrew Morton 
| Cc: Al Viro 
| Cc: Oleg Nesterov 
| Reviewed-by: Dave Martin 
| Reported-by: Steve McIntyre 
| Tested-by: Steve McIntyre <93...@debian.org>
| Signed-off-by: Will Deacon 
| Signed-off-by: Catalin Marinas 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#929359: linux: instability on arm64 MP30-AR1 servers

[Aurelien Jarno]

On 2019-05-23 16:52, Julien Cristau wrote:
> Control: found -1 4.19.28-2
> 
> On Wed, May 22, 2019 at 11:58:15 +0200, Julien Cristau wrote:
> 
> > Source: linux
> > Version: 4.9.168-1
> > Severity: important
> > X-Debbugs-Cc: debian-...@lists.debian.org, debian-ad...@lists.debian.org
> > User: debian-ad...@lists.debian.org
> > Usertags: needed-by-DSA-Team
> > 
> > Hi,
> > 
> > ever since the 9.9 point release conova-node01.debian.org and
> > conova-node02.debian.org have been unstable.  They run for an hour or
> > three, and then things go bad.  Rebooting back to 4.9.144-3.1 makes them
> > stable again.
> > 
> Still happening after upgrading to the stretch-backports kernel:
> 

The problem is somehow related to openvswitch. After switching the
ganeti cluster from openvswitch to bridge mode, both machines run stable
again.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#927825: arm: mvneta driver used on Armada XP GP boards does not receive packets (regression from 4.9)

[Aurelien Jarno]

Hi,

On 2019-05-01 00:04, Aurelien Jarno wrote:
> On 2019-04-30 10:12, Uwe Kleine-König wrote:
> > > > More precisely the board is a "Marvell Armada XP Development Board
> > > > DB-MV784MP-GP"
> > > > 
> > > > > anymore. Using tcpdump on both the buildd and a remote host, it 
> > > > > appears
> > > > > that the packets correctly leave the board and that the reception side
> > > > > fails.
> > 
> > If you can send to a remote host at least ARP (or ND) must be working,
> > so some reception still works, right?
> 
> I have to try again, but what i have seen is the ARP requests from
> hartmann arriving to the other hosts on the subnet. Steve McIntyre
> (added in Cc:) confirmed me on IRC being able to reproduce the issue on
> another board.

I confirm that. Basically on the other hosts of the same subnet, I can
see the ARP requests:

18:23:45.979860 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46
18:23:47.002990 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46
18:23:48.027262 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46
18:23:52.004248 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46
18:23:53.019252 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46
18:23:54.043276 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46
18:23:58.027937 ARP, Request who-has 172.28.17.1 tell 172.28.17.18, length 46

172.28.17.1 is the gateway, 172.28.17.18 is hartmann.d.o. 

> > Is it possible to test a few things on hartmann? I'd suggest:
> > 
> >  - try (vanilla) 5.1-rc6 with MVNETA=y

I have tried 5.1-rc7 with:

CONFIG_MVNETA_BM_ENABLE=y
CONFIG_MVNETA=y
CONFIG_MVNETA_BM=y

and also with

CONFIG_MVNETA_BM_ENABLE=m
CONFIG_MVNETA=m
CONFIG_MVNETA_BM=m

And the mvneta network driver is not able to receive data in both cases.

Best regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#927825: arm: mvneta driver used on Armada XP GP boards does not receive packets (regression from 4.9)

[Aurelien Jarno]

On 2019-04-30 10:12, Uwe Kleine-König wrote:
> [Adding the mvebu guys and netdev to Cc]
> 
> Hello,
> 
> On Thu, Apr 25, 2019 at 09:17:32PM +0200, Aurelien Jarno wrote:
> > On 2019-04-25 14:50, Aurelien Jarno wrote:
> > > On 2019-04-23 22:16, Aurelien Jarno wrote:
> > > > Source: linux
> > > > Version: 4.19.28-2
> > > > Severity: important
> > > > 
> > > > After upgrading hartmann.debian.org (an armhf buildd using an Armada XP
> > > > GP board) from buster to stretch, the ethernet device is not working
> 
> "upgrading from buster to stretch" doesn't make sense. I think you meant
> from stretch to buster.

You're correct. To be more precise the kernel is there the issue, so
that should even be upgrading from the stretch kernel to the buster
kernel.

> > > More precisely the board is a "Marvell Armada XP Development Board
> > > DB-MV784MP-GP"
> > > 
> > > > anymore. Using tcpdump on both the buildd and a remote host, it appears
> > > > that the packets correctly leave the board and that the reception side
> > > > fails.
> 
> If you can send to a remote host at least ARP (or ND) must be working,
> so some reception still works, right?

I have to try again, but what i have seen is the ARP requests from
hartmann arriving to the other hosts on the subnet. Steve McIntyre
(added in Cc:) confirmed me on IRC being able to reproduce the issue on
another board.

> > > > The module used for the ethernet device is mvneta. The corresponding DT
> > > > compatible entry is "marvell,armada-xp-neta".
> > > >
> > > 
> > > I have started a "bisection" with the kernels from snapshot. This is
> > > what I have found so far:
> > > 
> > > This one works:
> > > - linux-image-4.19.0-rc6-armmp-lpae_4.19~rc6-1~exp1_armhf.deb 
> > > 
> > > The following ones don't:
> > > - linux-image-4.19.0-rc7-armmp-lpae_4.19~rc7-1~exp1_armhf.deb
> > > - linux-image-5.0.0-trunk-armmp_5.0.2-1~exp1_armhf.deb
> > > 
> > > My guess (I don't have time to try more now) is that the issue is caused
> > > by the following change:
> > > 
> > > |  [ Uwe Kleine-König ]
> > > |  * [armhf] enable MVNETA_BM_ENABLE and CAN_FLEXCAN as a module
> > > 
> > 
> > I confirm this is the issue. Disabling MVNETA_BM_ENABLE on kernel 
> > 4.19.28-2 fixes the issue. Note that it breaks the ABI.
> 
> A colleague happens to work with an XP based machine with a (nearly)
> vanilla kernel based on 5.1.0-rc6 and there enabling MVNETA_BM_ENABLE
> doesn't render networking nonfunctional.
> 
> Looking through the changes to drivers/net/ethernet/marvell/mvneta*
> between 5.0 and 5.1-rc6 there isn't something that would explain a fix
> though. There doesn't seem to be a good explanation in the debian
> specific patches either.
> 
> So this problem is either machine specific or it works with the mvneta
> driver builtin. (I didn't double check, but guess that my colleague uses
> =y and the Debian kernel =m). Well, or I missed something.

Yes the debian kernel uses:
CONFIG_MVNETA_BM_ENABLE=m
CONFIG_MVNETA=m
CONFIG_MVNETA_BM=m

> Is it possible to test a few things on hartmann? I'd suggest:
> 
>  - try (vanilla) 5.1-rc6 with MVNETA=y
>  - try an older kernel (maybe 4.6 as the buffer manager stuff was
>introduced in dc35a10f68d3 ("net: mvneta: bm: add support for
>hardware buffer management") which made it into 4.6-rc1) with
>MVNETA_BM_ENABLE=[ym].

Ok, I'll try that in the next days. I just do not have remote power,
only serial console, I hope the kernels will boot enough to be able to
roll back to another kernel.

Best regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#927825: arm: mvneta driver used on Armada XP GP boards does not receive packets (regression from 4.9)

[Aurelien Jarno]

On 2019-04-25 14:50, Aurelien Jarno wrote:
> On 2019-04-23 22:16, Aurelien Jarno wrote:
> > Source: linux
> > Version: 4.19.28-2
> > Severity: important
> > 
> > After upgrading hartmann.debian.org (an armhf buildd using an Armada XP
> > GP board) from buster to stretch, the ethernet device is not working
> 
> More precisely the board is a "Marvell Armada XP Development Board
> DB-MV784MP-GP"
> 
> > anymore. Using tcpdump on both the buildd and a remote host, it appears
> > that the packets correctly leave the board and that the reception side
> > fails.
> > 
> > The module used for the ethernet device is mvneta. The corresponding DT
> > compatible entry is "marvell,armada-xp-neta".
> >
> 
> I have started a "bisection" with the kernels from snapshot. This is
> what I have found so far:
> 
> This one works:
> - linux-image-4.19.0-rc6-armmp-lpae_4.19~rc6-1~exp1_armhf.deb 
> 
> The following ones don't:
> - linux-image-4.19.0-rc7-armmp-lpae_4.19~rc7-1~exp1_armhf.deb
> - linux-image-5.0.0-trunk-armmp_5.0.2-1~exp1_armhf.deb
> 
> My guess (I don't have time to try more now) is that the issue is caused
> by the following change:
> 
> |  [ Uwe Kleine-König ]
> |  * [armhf] enable MVNETA_BM_ENABLE and CAN_FLEXCAN as a module
> 

I confirm this is the issue. Disabling MVNETA_BM_ENABLE on kernel 
4.19.28-2 fixes the issue. Note that it breaks the ABI.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#927825: arm: mvneta driver used on Armada XP GP boards does not receive packets (regression from 4.9)

[Aurelien Jarno]

On 2019-04-23 22:16, Aurelien Jarno wrote:
> Source: linux
> Version: 4.19.28-2
> Severity: important
> 
> After upgrading hartmann.debian.org (an armhf buildd using an Armada XP
> GP board) from buster to stretch, the ethernet device is not working

More precisely the board is a "Marvell Armada XP Development Board
DB-MV784MP-GP"

> anymore. Using tcpdump on both the buildd and a remote host, it appears
> that the packets correctly leave the board and that the reception side
> fails.
> 
> The module used for the ethernet device is mvneta. The corresponding DT
> compatible entry is "marvell,armada-xp-neta".
>

I have started a "bisection" with the kernels from snapshot. This is
what I have found so far:

This one works:
- linux-image-4.19.0-rc6-armmp-lpae_4.19~rc6-1~exp1_armhf.deb 

The following ones don't:
- linux-image-4.19.0-rc7-armmp-lpae_4.19~rc7-1~exp1_armhf.deb
- linux-image-5.0.0-trunk-armmp_5.0.2-1~exp1_armhf.deb

My guess (I don't have time to try more now) is that the issue is caused
by the following change:

|  [ Uwe Kleine-König ]
|  * [armhf] enable MVNETA_BM_ENABLE and CAN_FLEXCAN as a module

Add Uwe as Cc: so that he can comment on the change.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#927825: arm: mvneta driver used on Armada XP GP boards does not receive packets (regression from 4.9)

[Aurelien Jarno]

Source: linux
Version: 4.19.28-2
Severity: important

After upgrading hartmann.debian.org (an armhf buildd using an Armada XP
GP board) from buster to stretch, the ethernet device is not working
anymore. Using tcpdump on both the buildd and a remote host, it appears
that the packets correctly leave the board and that the reception side
fails.

The module used for the ethernet device is mvneta. The corresponding DT
compatible entry is "marvell,armada-xp-neta".

Bug#919049: posix-cpu-timers: Unbreak timer rearming (regression)

[Aurelien Jarno]

On 2019-01-12 11:01, Salvatore Bonaccorso wrote:
> Source: linux
> Version: 4.19.13-1
> Severity: serious
> Tags: upstream patch
> Justification: Regression / Causes FTBFS on glibc (testfailures)
> Control: affects -1 src:glibc
> Control: found -1 4.20-1~exp1
> Control: forwarded -1 https://lkml.org/lkml/2018/12/30/169
> 
> Upstream fix 0e334db6bb4b ("posix-timers: Fix division by zero bug")
> in 4.20 and backported to 4.19.13 causes for instance glibc testsuite
> to fail.
> 
> References:
> https://lkml.org/lkml/2018/12/30/169
> https://bugzilla.redhat.com/show_bug.cgi?id=1662602
> https://bugzilla.kernel.org/show_bug.cgi?id=202123
> 
> https://lore.kernel.org/lkml/2019033500.840117...@linutronix.de/

I confirm the patch above fixes the glibc issues.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#904385: arm64: sigaltstack fails with MINSIGSTKSZ for 32-bit processes

[Aurelien Jarno]

control: affects -1 glibc
control: found linux/4.17.6-2

On 2018-07-23 21:31, Aurelien Jarno wrote:
> Package: src:linux
> Version: 4.9.110-1
> Severity: normal
> 
> Dear Maintainer,
> 
> The arm64 kernel allows one to run aarch32 processes on an aarch64
> processor (if it has support for it), using the standard 32/64-bit
> syscall compatibility. However this compat layer does not correctly
> validate the arguments of the sigaltstack syscall.
> 

I forgot to say that the problem is reproducible with kernel 4.17.6.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#904385: arm64: sigaltstack fails with MINSIGSTKSZ for 32-bit processes

[Aurelien Jarno]

Package: src:linux
Version: 4.9.110-1
Severity: normal

Dear Maintainer,

The arm64 kernel allows one to run aarch32 processes on an aarch64
processor (if it has support for it), using the standard 32/64-bit
syscall compatibility. However this compat layer does not correctly
validate the arguments of the sigaltstack syscall.

arch/arm64/include/uapi/asm/signal.h defines SIGSTKSZ and MINSIGSTKSZ
as follow:
| #define MINSIGSTKSZ 5120
| #define SIGSTKSZ16384

arch/arm/include/uapi/asm/signal.h defines SIGSTKSZ and MINSIGSTKSZ as
follow:
| #define MINSIGSTKSZ 2048
| #define SIGSTKSZ8192

It seems to be the only 32/64-bit architecture for which those constants
differ. The do_compat_sigaltstack function in kernel/signal.c passes
ss.ss_size to do_sigaltstack unchanged, and the latter validates it
against the native MINSIGSTKSZ.

This causes the glibc test nptl/tst-signal6 to fail, but I guess it can
also affects other packages at runtime. This is also reproducible with
the following simple testcase:

| #include 
| #include 
| #include 
| 
| int main(int argc, char *argv[])
| {
| stack_t ss;
| 
| ss.ss_sp = malloc(MINSIGSTKSZ);
| if (ss.ss_sp == NULL) {
| perror("malloc");
| exit(EXIT_FAILURE);
| }
| 
| ss.ss_size = MINSIGSTKSZ;
| ss.ss_flags = 0;
| if (sigaltstack(, NULL)) {
| perror("sigaltstack");
| exit(EXIT_FAILURE);
| }
| 
| return 0;
| }

| $ ./sigaltstack 
| sigaltstack: Cannot allocate memory

| $ strace ./sigaltstack
| execve("./sigaltstack", ["./sigaltstack"], [/* 23 vars */]) = 0
| strace: [ Process PID=694 runs in 32 bit mode. ]
| uname({sysname="Linux", nodename="arm64", ...}) = 0
| brk(NULL)   = 0x35d000
| brk(0x35dd00)   = 0x35dd00
| set_tls(0x35d4c0, 0x78f7c, 0, 0x24, 0x78f6c) = 0
| readlink("/proc/self/exe", "/home/aurel32/sigaltstack", 4096) = 25
| brk(0x37ed00)   = 0x37ed00
| brk(0x37f000)   = 0x37f000
| access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
| sigaltstack({ss_sp=0x35e8b0, ss_flags=0x800 /* SS_??? */, ss_size=67191}, 
NULL) = -1 ENOMEM (Cannot allocate memory)
| dup(2)  = 3
| fcntl64(3, F_GETFL) = 0x20002 (flags O_RDWR|0x2)
| fstat64(3, 0xff96bf28)  = 0
| write(3, "sigaltstack: Cannot allocate mem"..., 36sigaltstack: Cannot 
allocate memory
| ) = 36
| close(3)= 0
| exit_group(1)   = ?
| +++ exited with 1 +++

-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 4.9.0-7-arm64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Re: linux/unstable failing to build on mips

[Aurelien Jarno]

On 2018-06-29 21:29, Ben Hutchings wrote:
> The latest upload of linux to unstable has failed to build on mips
> several times, with the failure mode being an apparent hang near the
> end of the build process.  (Only one of these failed builds is visible
> on buildd.debian.org now, but I think there were two previous
> attempts.)

That's correct.

> Has there been any attempt to diagnose the hang?  If so, does it seem
> to be due to memory exhaustion and extreme swapping, or a software bug,
> or some other cause?  Why hasn't it happened when building earlier
> versions?

Yes, attempted has been made, but it's something difficult to diagnose,
the machine becoming unresponsive. make seems to leave many processes
hanging, causing extreme swapping, which doesn't work well on the
Octeons which swap over NFS. It seems to work fine on the Octeons which
swap over NFS.

mips being one of the few architectures with a buggy version of make, I
wonder if it's related to #890430 or #890309. I guess it's time to
revert to the make version in testing, which would also greatly improve,
or rather restore, the build time.

> If it's memory exhaustion, are linux and other large packages being
> blacklisted for these build hosts?

In the meantime, I have blacklisted linux on the Octeons swapping over
NFS. It should therefore build fine.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Accepted linux 4.9.82-1+deb9u3 (source) into proposed-updates->stable-new, proposed-updates

[Aurelien Jarno]

-sh7751r linux-image-4.9.0-6-sh7751r-dbg 
linux-image-4.9.0-6-sh7785lcr linux-headers-4.9.0-6-sh7785lcr 
linux-image-4.9.0-6-sh7785lcr-dbg linux-headers-4.9.0-6-all-sparc64 
kernel-image-4.9.0-6-sparc64-di nic-modules-4.9.0-6-sparc64-di 
ppp-modules-4.9.0-6-sparc64-di pata-modules-4.9.0-6-sparc64-di 
cdrom-core-modules-4.9.0-6-sparc64-di scsi-core-modules-4.9.0-6-sparc64-di 
scsi-modules-4.9.0-6-sparc64-di btrfs-modules-4.9.0-6-sparc64-di 
ext4-modules-4.9.0-6-sparc64-di isofs-modules-4.9.0-6-sparc64-di 
jfs-modules-4.9.0-6-sparc64-di ufs-modules-4.9.0-6-sparc64-di 
xfs-modules-4.9.0-6-sparc64-di
 fat-modules-4.9.0-6-sparc64-di md-modules-4.9.0-6-sparc64-di 
multipath-modules-4.9.0-6-sparc64-di usb-modules-4.9.0-6-sparc64-di 
usb-storage-modules-4.9.0-6-sparc64-di input-modules-4.9.0-6-sparc64-di 
sata-modules-4.9.0-6-sparc64-di crc-modules-4.9.0-6-sparc64-di 
crypto-modules-4.9.0-6-sparc64-di crypto-dm-modules-4.9.0-6-sparc64-di 
ata-modules-4.9.0-6-sparc64-di nbd-modules-4.9.0-6-sparc64-di 
squashfs-modules-4.9.0-6-sparc64-di virtio-modules-4.9.0-6-sparc64-di 
zlib-modules-4.9.0-6-sparc64-di udf-modules-4.9.0-6-sparc64-di 
fuse-modules-4.9.0-6-sparc64-di linux-image-4.9.0-6-sparc64 
linux-headers-4.9.0-6-sparc64 linux-image-4.9.0-6-sparc64-dbg 
linux-image-4.9.0-6-sparc64-smp linux-headers-4.9.0-6-sparc64-smp 
linux-image-4.9.0-6-sparc64-smp-dbg linux-compiler-gcc-6-arm 
linux-compiler-gcc-6-s390
 linux-compiler-gcc-6-x86
Architecture: source
Version: 4.9.82-1+deb9u3
Distribution: stretch-security
Urgency: medium
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Changed-By: Aurelien Jarno <aure...@debian.org>
Description:
 acpi-modules-4.9.0-6-686-di - ACPI support modules (udeb)
 acpi-modules-4.9.0-6-686-pae-di - ACPI support modules (udeb)
 acpi-modules-4.9.0-6-amd64-di - ACPI support modules (udeb)
 affs-modules-4.9.0-6-4kc-malta-di - Amiga filesystem support (udeb)
 affs-modules-4.9.0-6-5kc-malta-di - Amiga filesystem support (udeb)
 affs-modules-4.9.0-6-loongson-3-di - Amiga filesystem support (udeb)
 affs-modules-4.9.0-6-octeon-di - Amiga filesystem support (udeb)
 affs-modules-4.9.0-6-powerpc-di - Amiga filesystem support (udeb)
 affs-modules-4.9.0-6-powerpc64-di - Amiga filesystem support (udeb)
 ata-modules-4.9.0-6-4kc-malta-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-5kc-malta-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-686-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-686-pae-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-alpha-generic-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-amd64-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-arm64-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-armmp-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-loongson-3-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-parisc-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-parisc64-smp-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-powerpc-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-powerpc64-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-powerpc64le-di - ATA disk modules (udeb)
 ata-modules-4.9.0-6-sparc64-di - ATA disk modules (udeb)
 btrfs-modules-4.9.0-6-4kc-malta-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-5kc-malta-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-686-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-686-pae-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-alpha-generic-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-amd64-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-arm64-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-armmp-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-loongson-3-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-m68k-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-marvell-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-octeon-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-parisc-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-parisc64-smp-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-powerpc-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-powerpc64-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-powerpc64le-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-s390x-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-sh7751r-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-sh7785lcr-di - BTRFS filesystem support (udeb)
 btrfs-modules-4.9.0-6-sparc64-di - BTRFS filesystem support (udeb)
 cdrom-core-modules-4.9.0-6-4kc-malta-di - CDROM support (udeb)
 cdrom-core-modules-4.9.0-6-5kc-malta-di - CDROM support (udeb)
 cdrom-core-modules-4.9.0-6-686-di - CDROM support (udeb)
 cdrom-core-modules-4.9.0-6-686-pae-di - CDROM support (udeb)
 cdrom-core-modules-4.9.0-6-alpha-generic-di - CDROM support (udeb)
 cdrom-core-modules-4.9.0-6-amd64-di - CDROM support (udeb)
 cdrom-core-modules-4.9.0-6-arm6

Bug#891249: linux: unstable kernel/data corruption on ppc64el

[Aurelien Jarno]

tag 891249 + fixed-upstream
thanks

On 2018-02-26 11:01, Breno Leitao wrote:
> Hi,
> 
> On 02/23/2018 03:52 PM, Aurelien Jarno wrote:
> 
> > DSA has installed the latest security kernel (4.9.82-1+deb9u2) on the
> > Debian POWER8 machines running ppc64el. While they boot correctly, then
> > programs segfault randomly (apt, sbuild, systemd, etc...). Passing
> > no_rfi_flush to the command line does not change anything. Looking more
> > in details, things looks scarying as some code actually get wrongly
> > executed. Here are some build logs examples:
> > - 
> > https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519399908=0
> > - 
> > https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519396907=0
> > - 
> > https://buildd.debian.org/status/fetch.php?pkg=tk8.5=ppc64el=8.5.19-3=1519362938=0
> > 
> > While in the above case the packages fail to build from source, I guess
> > there are also some cases of undetected corruptions.
> > 
> > I'll try to run the 4.9.80-2 kernel at some point to narrow down the
> > issue.
> 
> I talked to the powerpc maintainer about this problem, and in fact this is a 
> knew
> problem, since the 4.4 patches were 'backported' to 4.9 without success.
> 
> This is already fixed and in the stable tree already:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/arch/powerpc?h=linux-4.9.y
> 
> I understand that the commit ids are:
>  * 3146a32b39cd78722869bca6e839b3c59155e012
>  * efe8bc07c47fff196bbc0822e249a27ae0574d24
>  * ec0084d082137b73460303b39f4089970a213ad7
> 
> But I suppose that Debian will do a full merge with the stable tree, then, I 
> expect
> that the next release will just work.

Thanks for the quick answer. I confirm that these commit are indeed in
the 4.9.84 stable release, which has been released yesterday. I guess
3146a32b39cd78722869bca6e839b3c59155e012 is the one which fixes the data
corruption.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#891249: linux: unstable kernel/data corruption on ppc64el

[Aurelien Jarno]

Source: linux
Version: 4.9.82-1+deb9u2
Severity: critical
Justification: causes serious data corruption

DSA has installed the latest security kernel (4.9.82-1+deb9u2) on the
Debian POWER8 machines running ppc64el. While they boot correctly, then
programs segfault randomly (apt, sbuild, systemd, etc...). Passing
no_rfi_flush to the command line does not change anything. Looking more
in details, things looks scarying as some code actually get wrongly
executed. Here are some build logs examples:
- 
https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519399908=0
- 
https://buildd.debian.org/status/fetch.php?pkg=python-msgpack=ppc64el=0.5.1-1=1519396907=0
- 
https://buildd.debian.org/status/fetch.php?pkg=tk8.5=ppc64el=8.5.19-3=1519362938=0

While in the above case the packages fail to build from source, I guess
there are also some cases of undetected corruptions.

I'll try to run the 4.9.80-2 kernel at some point to narrow down the
issue.

Bug#889817: linux: kernel does not always provide a heap [alpha arm64 mips64el ppc64el ppc64 s390x sparc64]

[Aurelien Jarno]

Source: linux
Version: 4.14.13-1
Severity: normal
Tags: upstream

When ASLR is enabled (which is the default), the Linux kernel on at
least alpha, arm64, mips64el, ppc64el, ppc64, s390x and sparc64 might
not provide a heap to the program. This is the case for example when
the program is run through the program interpreter ld.so. This happens
with different probability depending on the architecture. This causes
issues with GLIBC tunables support, which needs to be able to reserve
a few hundred bytes of memory through brk. This is reproducible with
at least kernel 4.9 and 4.15, and it's likely that the issue has always
been there.

The following script, based on one from James Cowgill, shows the issue:

#!/bin/bash
export LC_ALL=C

interp=$(readelf --headers /bin/cat | grep 'Requesting program interpreter' | 
sed -e 's/.*: //' -e 's/]//')

for i in {1..1}
do
OUT=$($interp /bin/cat /proc/self/maps)
if [[ $OUT != *heap* ]]
then
echo -n F
echo "$OUT"
else
echo -n .
fi
done

A workaround is to set /proc/sys/kernel/randomize_va_space to 1.

Bug#871701: linux 4.9: backport patches for new Loongson CPU

[Aurelien Jarno]

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?

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: Bug#869658: Debian 9.1 stretch: command 'sensors' freeze temporarily the whole system

[Aurelien Jarno]

control: tag -1 - moreinfo
control: tag -1 + upstream
control: reassign -1 src:linux
control: retitle -1 linux: system freezes when dell-smm-hwmon reads fan speed

Hi,

On 2017-07-26 10:34, Carmelo C wrote:
> Hi Aurelien,
> 
> I removed the code line "radeon.hw_i2c=1" but the freeze persists. Then I
> ran "strace -o strace_sensors_output -tt sensors", attached the output...

Indeed, the strace shows that the freeze is not related to the radeon
module, but rather to the dell-smm-hwmon module. You can try to unload
it, the issue should then disappear.

[ snip ]

> 10:18:08.029849 write(1, "dell_smm-virtual-0\n", 19) = 19
> 10:18:08.029908 write(1, "Adapter: Virtual device\n", 24) = 24

[ snip ]

> 10:18:08.049666 open("/sys/class/hwmon/hwmon2/fan1_label", O_RDONLY) = 3
> 10:18:08.049718 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:08.049759 read(3, "Processor Fan\n", 4096) = 14
> 10:18:08.049801 read(3, "", 4096)   = 0
> 10:18:08.049838 close(3)= 0
> 10:18:08.049882 open("/sys/class/hwmon/hwmon2/fan1_input", O_RDONLY) = 3
> 10:18:08.049937 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:08.049978 read(3, "2844\n", 4096) = 5
> 10:18:09.956833 close(3)= 0
> 10:18:09.956891 write(1, "Processor Fan: 2844 RPM\n", 24) = 24

Here you can see that reading the fan speed almost take 2 seconds.

> 10:18:09.956950 open("/sys/class/hwmon/hwmon2/fan2_label", O_RDONLY) = 3
> 10:18:09.957009 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:09.957052 read(3, 0xbfdec67c, 4096) = -1 EINVAL (Invalid argument)
> 10:18:09.957093 close(3)= 0
> 10:18:09.957138 open("/sys/class/hwmon/hwmon2/fan2_input", O_RDONLY) = 3
> 10:18:09.957191 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:09.957250 read(3, "2844\n", 4096) = 5
> 10:18:11.860890 close(3)= 0
> 10:18:11.860939 write(1, "fan2:  2844 RPM\n", 24) = 24

Same here.

> 10:18:11.860990 open("/sys/class/hwmon/hwmon2/fan3_label", O_RDONLY) = 3
> 10:18:11.861046 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:11.861088 read(3, 0xbfdec67c, 4096) = -1 EINVAL (Invalid argument)
> 10:18:11.861128 close(3)= 0
> 10:18:11.861172 open("/sys/class/hwmon/hwmon2/fan3_input", O_RDONLY) = 3
> 10:18:11.861237 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:11.861278 read(3, "2840\n", 4096) = 5
> 10:18:13.779559 close(3)= 0
> 10:18:13.779666 write(1, "fan3:  2840 RPM\n", 24) = 24

Same here.

> 10:18:13.779738 open("/sys/class/hwmon/hwmon2/temp1_label", O_RDONLY) = 3
> 10:18:13.779947 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:13.780021 read(3, "CPU\n", 4096)  = 4
> 10:18:13.789029 read(3, "", 4096)   = 0
> 10:18:13.789087 close(3)= 0
> 10:18:13.789148 open("/sys/class/hwmon/hwmon2/temp1_input", O_RDONLY) = 3
> 10:18:13.789228 fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> 10:18:13.789280 read(3, "37000\n", 4096) = 6
> 10:18:13.799076 close(3)= 0

While reading a temperature is done in less than 1 millisecond.


The problem you observe is similar to the following one:
  
  https://bugzilla.kernel.org/show_bug.cgi?id=112021

As it the root of the problem is a BIOS issue, I would first suggest to
upgrade it. If it doesn't work the next step is probably to use the 
blacklist implemented in the dell-smm-hwmon module to disable the fans
when running on a Dell system similar to yours.

In anycase this is definitely a kernel related issue, so I am
reassigning the bug.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#863550: linux: NFSv4 callback processes fills process table

[Aurelien Jarno]

Source: linux
Version: 4.9.25-1
Severity: important
User: debian-ad...@lists.debian.org
Usertags: needed-by-DSA-Team

Hi,

DSA uses NFS through autofs, and machines using the Stretch kernel are
affected by the following bug:

  https://bugzilla.redhat.com/show_bug.cgi?id=1427493

Basically each time a NFS filesystem is unmounted and remounted, a few
NFSv4 callback processes are leaked. After one week, a few hundred of
processes are there:

|  aurel32@lindsay:~$ uptime
|   12:10:15 up 8 days, 15:14,  2 users,  load average: 0,00, 0,03, 0,04
|  aurel32@lindsay:~$ ps aux | grep -c "NFSv4 callback"
|  693


It seems the issues is fixed since 4.12-rc1 by the following set of
commts:

|  commit ed6473ddc704a2005b9900ca08e236ebb2d8540a
|  Author: Trond Myklebust 
|  Date:   Wed Apr 26 11:55:27 2017 -0400
|  
|  NFSv4: Fix callback server shutdown
|  
|  We want to use kthread_stop() in order to ensure the threads are
|  shut down before we tear down the nfs_callback_info in nfs_callback_down.
|  
|  Tested-and-reviewed-by: Kinglong Mee 
|  Reported-by: Kinglong Mee 
|  Fixes: bb6aeba736ba9 ("NFSv4.x: Switch to using 
svc_set_num_threads()...")
|  Signed-off-by: Trond Myklebust 
|  Signed-off-by: J. Bruce Fields 
|  
|  commit 9e0d87680d689f1758185851c3da6eafb16e71e1
|  Author: Trond Myklebust 
|  Date:   Wed Apr 26 11:55:26 2017 -0400
|  
|  SUNRPC: Refactor svc_set_num_threads()
|  
|  Refactor to separate out the functions of starting and stopping threads
|  so that they can be used in other helpers.
|  
|  Signed-off-by: Trond Myklebust 
|  Tested-and-reviewed-by: Kinglong Mee 
|  Signed-off-by: J. Bruce Fields 
|  
|  commit df807fffaabde625fa9adb82e3e5b88cdaa5709a
|  Author: Kinglong Mee 
|  Date:   Thu Apr 27 11:13:38 2017 +0800
|  
|  NFSv4.x/callback: Create the callback service through svc_create_pooled
|  
|  As the comments for svc_set_num_threads() said,
|  " Destroying threads relies on the service threads filling in
|  rqstp->rq_task, which only the nfs ones do.  Assumes the serv
|  has been created using svc_create_pooled()."
|  
|  If creating service through svc_create(), the svc_pool_map_put()
|  will be called in svc_destroy(), but the pool map isn't used.
|  So that, the reference of pool map will be drop, the next using
|  of pool map will get a zero npools.

That said I haven't tried to backport them and sta...@vger.kernel.org
hasn't been Cc:ed.

Aurelien

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#860013: Bug#824442: and conflict needs to be resolved

[Aurelien Jarno]

On 2017-04-11 03:35, Ben Hutchings wrote:
> Control: tag -1 moreinfo
> 
> On Mon, 10 Apr 2017 10:48:45 +0200 Aurelien Jarno <aurel...@aurel32.net> 
> wrote:
> [...] 
> > Unfortunately I have been pointed on the libc-alpha mailing list that
> > it doesn't work if another file which includes 
> > (e.g. ) is included before . The problem is
> > that the __UAPI_DEF_IF_* constants are set to 1 in 
> > even if  is not included.
> [...]
> 
> Does this affect any real programs, or is this just theoretical (and
> therefore should be downgraded)?

It depends what do you mean by real program. I doubt it still affect
debian packages. The change has been introduced by kernel 4.5, and I
guess by now all the FTBFS have been fixed. At least for stretch, they
might be a few left in sid.

Now some of the fixes might not have reached upstream yet.

If we consider that acceptable, we can lower the severity of the bugs on
both the kernel and the glibc side.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#845422: [PATCH] Please add BCM2835 MMC driver for Raspberry Pi 3

[Aurelien Jarno]

On 2016-11-23 09:43, Michael Stapelberg wrote:
> Source: linux
> Severity: wishlist
> Tags: patch
> 
> Thank you for your work on maintaining the Linux kernel in Debian, I really
> appreciate it!
> 
> I am interested in running Debian on the Raspberry Pi 3.
> 
> As per https://github.com/anholt/linux/wiki/Raspberry-Pi-3, the mainline Linux
> kernel in version 4.8 includes support for the Raspberry Pi 3, so we are in
> pretty good shape already.
> 
> However, when trying to boot linux-image-4.8.0-1-arm64 version 4.8.5-1, I
> noticed that the kernel can’t find any block devices (and hence no root file
> system). This is because the bcm2835-sdhost MMC driver has not actually made 
> it
> into Linux 4.8; it is still under review:
> https://www.spinics.net/lists/arm-kernel/msg513433.html

While this is correct, please note that the BCM2835 has two sdhost
controller, one that can be used for the wireless card and one for the
sdcard. The 4.8 kernel already has support for the other sdhost
controller, namely the iProc one. You can use this one for your root
filesystem as it is built in the Debian kernel.

I guess you have a problem somewhere, maybe in the device tree that
causes the wrong SD controller to be used. I use the device tree that is
provided by the kernel:

|sdhci: sdhci@7e30 {
|compatible = "brcm,bcm2835-sdhci";
|reg = <0x7e30 0x100>;
|interrupts = <2 30>;
|clocks = < BCM2835_CLOCK_EMMC>;
|status = "disabled";
|};

This work since at least kernel 4.8.4-1~exp1.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#841240: linux: x32 preadv/pwritev syscalls broken in kernel 4.7

[Aurelien Jarno]

Source: linux
Version: 4.7.6-1
Severity: normal

The x32 preadv/pwritev syscalls have been broken in kernel 4.7-rc1 by
this commit:

| commit 482dd2ef124484601adea82e5e806e81e2bc5521
| Author: Christoph Hellwig 
| Date:   Thu Apr 7 22:43:59 2016 +0200
|
| x86/syscalls: Wire up compat readv2/writev2 syscalls
|
| Reported-by: David Smith 
| Tested-by: David Smith 
| Signed-off-by: Christoph Hellwig 
| Cc: Andy Lutomirski 
| Cc: Borislav Petkov 
| Cc: Brian Gerst 
| Cc: Denys Vlasenko 
| Cc: H. Peter Anvin 
| Cc: Linus Torvalds 
| Cc: Peter Zijlstra 
| Cc: Thomas Gleixner 
| Link: http://lkml.kernel.org/r/20160407204359.ga3...@lst.de
| Signed-off-by: Ingo Molnar 

It causes the glibc testsuite to fail on x32 when running a 4.7 kernel,
and more precisely the misc/tst-preadvwritev and misc/tst-preadvwritev64
tests.

The syscalls have been fixed in kernel 4.8-rc1 by this commit, even if
neither the commit nor the mail it refers too talk about a breakage:

| commit 3ebfd81f7fb3e81a754e37283b7f38c62244641a
| Author: H.J. Lu 
| Date:   Thu Jul 14 12:31:53 2016 -0700
|
| x86/syscalls: Add compat_sys_preadv64v2/compat_sys_pwritev64v2
| 
| Don't use the same syscall numbers for 2 different syscalls:
| 
|  534x32 preadv  compat_sys_preadv64
|  535x32 pwritev compat_sys_pwritev64
|  534x32 preadv2 compat_sys_preadv2
|  535x32 pwritev2compat_sys_pwritev2
| 
| Add compat_sys_preadv64v2() and compat_sys_pwritev64v2() so that 64-bit 
offset
| is passed in one 64-bit register on x32, similar to compat_sys_preadv64()
| and compat_sys_pwritev64().
| 
| Signed-off-by: H.J. Lu 
|
| x86/syscalls: Add compat_sys_preadv64v2/compat_sys_pwritev64v2
| 
| Don't use the same syscall numbers for 2 different syscalls:
| 
|  534x32 preadv  compat_sys_preadv64
|  535x32 pwritev compat_sys_pwritev64
|  534x32 preadv2 compat_sys_preadv2
|  535x32 pwritev2compat_sys_pwritev2
| 
| Add compat_sys_preadv64v2() and compat_sys_pwritev64v2() so that 64-bit 
offset
| is passed in one 64-bit register on x32, similar to compat_sys_preadv64()
| and compat_sys_pwritev64().
| 
| Signed-off-by: H.J. Lu 
| Cc: Andy Lutomirski 
| Cc: Borislav Petkov 
| Cc: Brian Gerst 
| Cc: Christoph Hellwig 
| Cc: Denys Vlasenko 
| Cc: H. Peter Anvin 
| Cc: Josh Poimboeuf 
| Cc: Linus Torvalds 
| Cc: Peter Zijlstra 
| Cc: Thomas Gleixner 
| Link: 
http://lkml.kernel.org/r/came9roovcmf-rqfx_n1u_tu_dx1bykjtfr%3dq4-_pfvsj9bc...@mail.gmail.com
| Signed-off-by: Ingo Molnar 

Unfortunately this commit is not easily backportable as it completely
breaks the ABI. Nevertheless it should not be a big deal as we'll go to
kernel 4.8 soon. Given it is already available in experimental, I am
just going to close this bug in a few minutes. I just wanted to make
sure the issue is documented somewhere so that someone else do not spend
hours before finding the issue.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#838660: linux/jessie: missing KVM fix causes migration issues on guests without rdtscp

[Aurelien Jarno]

Source: linux
Version: 3.16.36-1+deb8u1
Severity: normal
Tags: patch
User: debian-ad...@lists.debian.org
Usertags: needed-by-DSA-Team

Dear Maintainer,

The following fix went to kernel 3.16.7-ckt25-1, as it was Cc:ed to
sta...@vger.kernel.org:

| commit 9dbe6cf941a6fe82933aef565e4095fb10f65023
| Author: Paolo Bonzini 
| Date:   Thu Nov 12 14:49:17 2015 +0100
| 
| KVM: x86: expose MSR_TSC_AUX to userspace
| 
| If we do not do this, it is not properly saved and restored across
| migration.  Windows notices due to its self-protection mechanisms,
| and is very upset about it (blue screen of death).
| 
| Cc: Radim Krcmar 
| Cc: sta...@vger.kernel.org
| Signed-off-by: Paolo Bonzini 

However it has been followed a bit later by the following fix, which has
not been Cc:ed to sta...@vger.kernel.org and thus not backported:

| commit 81b1b9ca6d5ca5f3ce91c0095402def657cf5db3
| Author: Haozhong Zhang 
| Date:   Mon Dec 14 23:13:38 2015 +0800
| 
| KVM: VMX: Fix host initiated access to guest MSR_TSC_AUX
| 
| The current handling of accesses to guest MSR_TSC_AUX returns error if
| vcpu does not support rdtscp, though those accesses are initiated by
| host. This can result in the reboot failure of some versions of
| QEMU. This patch fixes this issue by passing those host initiated
| accesses for further handling instead.
| 
| Signed-off-by: Haozhong Zhang 
| Signed-off-by: Paolo Bonzini 

This causes guest migrations issues when the host supports the rdtscp
instruction, but it is not exposed to the guest. The migration itself
works fine, but then the guest is frozen on the target host.

This patch does not apply cleanly to the 3.16 kernel, but can be
backported relatively easily. It has already been backported in
v4.2.8-ckt5 already, so the patch can be taken from there directly.

Thanks,
Aurelien

Bug#825423: supermin + sbuild + linux-image = broken chroot

[Aurelien Jarno]

On 2016-05-26 22:50, Ben Hutchings wrote:
> I'm inclined to add a check to linux-image prerm scripts that skips the
> question when DEBIAN_FRONTEND=noninteractive.
> 
> Aside from that, I might add the check for a chroot or container, if
> there's a simple way to do that.

You can use the command ischroot from the debianutils package.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#790694: PPC64: 64kb kernel pagesizes and nouveau

[Aurelien Jarno]

On 2016-03-30 16:45, Ben Hutchings wrote:
> On Wed, 2016-03-30 at 16:49 +0200, Mathieu Malaterre wrote:
> > Ben,
> > 
> > > 
> > > I saw that bug report as well.  I'm not sure what to do about it -
> > > other distributions were also using 64K pages for 64-bit PowerPC the
> > > last time I looked, and there may be good reasons to do that.
> > Would it be possible for you to dig that for us ? It appears that
> > making nouveau work with 64K page is non-trivial:
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=94757#c3
> > 
> > Which in turns means most of the userbase with PPC64 (G5 PowerMac)
> > wont be able to use X.
> 
> I am not a powerpc porter; Aurelien Jarno is the kernel maintainer
> responsible for it.

That's correct for ppc64el, but I never signed up for the powerpc port.

> I don't know about the user base, but I think most of the *development*
> effort and sponsorship of the powerpc ports now comes from IBM, and
> unfortunately they don't care about PowerMacs.

IBM doesn't really care about the powerpc port either, they do about the
ppc64el port. That said I have tracked the change to 64kB pages to the
following commit:

| commit aed63a56b189d771116f2d4b8fe10bbec528e6a2
| Author: Bastian Blank <wa...@debian.org>
| Date:   Sat Aug 9 19:42:11 2014 +
|
| * debian/changelog: Update
| * debian/config/kernelarch-powerpc/config-arch-64: Set PPC_64K_PAGES.
| * debian/config/kernelarch-powerpc/config-arch-64-le: Remove overriden 
option.
|
| svn path=/dists/trunk/linux/; revision=21721

I don't really know what it has been done, so I have Cced Bastian so
that he can comment on that. It's something that can be reverted if
needed I guess.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#811368: Illegal instriction on MIPS

[Aurelien Jarno]

On 2016-03-18 18:15, Ben Hutchings wrote:
> On Fri, 2016-03-18 at 10:59 +0100, Ole Streicher wrote:
> > Hi,
> > 
> > what is the status of this bug? It is now in "pending" since almost
> > two
> > months, but nothing happened since then.
> > 
> > This bug causes FTBFS for some important packages on the MIPS buildd,
> > which therefore cannot migrate to testing.
> 
> I think this was fixed by "[mips*] Backport math emulation fix from
> 4.5." in 3.16.7-ckt25-1 and in 4.3.5-1.
> 
> Aurelien, please can you confirm or correct this.

Yes, this is correct. This will be deployed on the build daemons in the
next release of jessie.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#808246: Stretch fails to install on OpenPOWER systems

[Aurelien Jarno]

On 2015-12-17 11:51, Timothy Pearson wrote:
> Package: linux-image-4.2.0-1-powerpc64le
> Version: 4.2.6-3
> Severity: grave
> 
> Using the latest debian-installer netboot kernel to install on an
> OpenPOWER server; install proceeds normally until disk detection when it
> fails stating no disks can be found.  dmesg shows a slew of errors similar
> to the following:
> 
> fat: no symbol version for TOC.
> fat: Unknown symbol TOC. (err -22)
> ext4: no symbol version for TOC.
> ext4: Unknown symbol TOC. (err -22)
> ahci: no symbol version for TOC.
> ahci: Unknown symbol TOC. (err -22)
> 
> Forcibly loading the modules (modprobe --force ext4, etc.) and resuming
> the installer allows the system to install normally, however the same
> issue shows up on reboot.  This causes a boot failure that cannot be
> overridden as the modprobe version in the initramfs does not support the
> force parameter.
> 
> Jessie installs normally on the same system.

The problem is that recent binutils versions strip undefined symbols from
vmlinux. Normally a ppc64el kernel has the following undefined symbols:

| 44809:  0 NOTYPE  WEAK   DEFAULT  UND mach_powermac
| 52870:  0 NOTYPE  WEAK   DEFAULT  UND mach_chrp
| 62021:  0 NOTYPE  WEAK   DEFAULT  UND mach_cell
| 62383:  0 NOTYPE  WEAK   DEFAULT  UND __crc_TOC.

However this is not the case anymore. This is due to the following
change on the binutils side:

| commit d983c8c5503d680c6d4955ceb610a9beebc64460
| Author: Alan Modra <amo...@gmail.com>
| Date:   Wed Feb 18 17:02:39 2015 +1030
| 
| Strip undefined symbols from .symtab
| 
| bfd/
| PR ld/4317
| * elflink.c (elf_link_input_bfd): Drop undefined local syms.
| (elf_link_output_extsym): Drop local and global undefined syms.
| Tidy.  Expand comment.
| ld/testsuite/
| PR ld/4317
| * ld-aarch64/gc-tls-relocs.d, * ld-cris/locref2.d,
| * ld-elf/ehdr_start-weak.d, * ld-elf/group1.d,
| * ld-i386/compressed1.d, * ld-ia64/error1.d, * ld-ia64/error2.d,
| * ld-ia64/error3.d, * ld-mips-elf/pic-and-nonpic-1.nd,
| * ld-mmix/undef-3.d, * ld-powerpc/tlsexe.r, * ld-powerpc/tlsexetoc.r,
| * ld-powerpc/tlsso.r, * ld-powerpc/tlstocso.r,
| * ld-x86-64/compressed1.d, * ld-x86-64/pie1.d: Update.

I am not sure the powerpc and ppc64el are actually due to the same bug
in binutils.

Aurelien


-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [PATCH 6/6] MIPS: net: BPF: Introduce BPF ASM helpers

[Aurelien Jarno]

On 2015-06-04 11:56, Markos Chandras wrote:
 This commit introduces BPF ASM helpers for MIPS and MIPS64 kernels.
 The purpose of this patch is to twofold:
 
 1) We are now able to handle negative offsets instead of either
 falling back to the interpreter or to simply not do anything and
 bail out.
 
 2) Optimize reads from the packet header instead of calling the C
 helpers
 
 Because of this patch, we are now able to get rid of quite a bit of
 code in the JIT generation process by using MIPS optimized assembly
 code. The new assembly code makes the test_bpf testsuite happy with
 all 60 test passing successfully compared to the previous
 implementation where 2 tests were failing.
 Doing some basic analysis in the results between the old
 implementation and the new one we can obtain the following
 summary running current mainline on an ER8 board (+/- 30us delta is
 ignored to prevent noise from kernel scheduling or IRQ latencies):
 
 Summary: 22 tests are faster, 7 are slower and 47 saw no improvement
 
 with the most notable improvement being the tcpdump tests. The 7 tests
 that seem to be a bit slower is because they all follow the slow path
 (bpf_internal_load_pointer_neg_helper) which is meant to be slow so
 that's not a problem.
 
 Cc: net...@vger.kernel.org
 Cc: David S. Miller da...@davemloft.net
 Cc: Alexei Starovoitov a...@plumgrid.com
 Cc: Daniel Borkmann dbork...@redhat.com
 Cc: Hannes Frederic Sowa han...@stressinduktion.org
 Cc: linux-ker...@vger.kernel.org
 Signed-off-by: Markos Chandras markos.chand...@imgtec.com
 ---
 I have uploaded the script and the bpf result files in my LMO webspace
 in case you want to have a look. I didn't paste them in here because they
 are nearly 200 lines. Simply download all 3 files and run './bpf_analysis.py'

This patch relies on R2 instructions, and thus the Linux kernel fails to
build when targetting non-R2 CPUs. See for example:

https://buildd.debian.org/status/fetch.php?pkg=linuxarch=mipselver=4.2%7Erc6-1%7Eexp1stamp=143948

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#785065: vdso32 fails to built on ppc64el

[Aurelien Jarno]

On 2015-05-12 15:55, Matthias Klose wrote:
 that should be fixed on the kernel side by removing this code. there never 
 was a
 powerpcle userland support. If this is not possible in the short term, then we
 can re-enable this for unstable for some time.
 

This also seems to break grub2 on ppc64el [1]. I think it's a legitimate
use case.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=grub2arch=ppc64elver=2.02~beta2-23stamp=1431706310

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20150515214654.ga2...@aurel32.net

Re: Bug#784337: usb: [29493.628253] hub 1-0:1.0: unable to enumerate USB device on port 6

[Aurelien Jarno]

control: reassign -1 linux

On 2015-05-05 16:22, Clemens Haupt Hohentrenk wrote:
 Package: usbutils
 Version: 1:007-2
 Severity: important
 File: usb
 
 Dear Maintainer,
 
 *** Reporter, please consider answering these questions, where appropriate ***
 
* What led up to the situation?
 Connecting Sandisk Ultra 32GB micro
* What exactly did you do (or not do) that was effective (or
  ineffective)?
 Just connectiog via usb
* What was the outcome of this action?
 [29493.440259] hub 1-0:1.0: unable to enumerate USB device on port 6 
 very often, nothing else can be seen

This kind of problem usually happens when there is an issue at the
plug/cable level. Are you using a USB extension cord? Have you tried the
device on another USB port or on another machine? Have you tried to
connect another device on this USB port?

* What outcome did you expect instead?
 mounting on /media/usb0
 *** End of the template - remove these template lines ***
 
 
 -- System Information:
 Debian Release: 8.0
   APT prefers testing
   APT policy: (650, 'testing'), (600, 'unstable'), (500, 
 'oldstable-updates'), (500, 'oldstable')
 Architecture: i386 (i686)
 
 Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)

Your kernel seems to be the wheezy one, while you run a jessie
installation. Have you tried with the jessie kernel?

Anyway I really doubt the problem the problem is in usbutils (a set of
programs to display USB devices properties), so I am reassigning the bug
to the linux package with this mail.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20150505190631.ga11...@aurel32.net

Bug#764223: [PATCH V3 4/8] MIPS: Add NUMA support for Loongson-3

[Aurelien Jarno]

 active_file:26512kB inactive_file:30384kB 
unevictable:0kB isolated(an
| on):0kB isolated(file):0kB present:638960kB managed:478096kB mlocked:0kB 
dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:5040kB 
slab_unreclaimable:3056kB kerne
| l_stack:352kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB 
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
| [5.064000] lowmem_reserve[]: 0 0 0
| [5.068000] DMA: 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 
0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 0kB
| [5.08] Normal: 5*16kB (EM) 5*32kB (UEM) 2*64kB (EM) 3*128kB (EM) 
6*256kB (UEM) 3*512kB (EM) 2*1024kB (M) 6*2048kB (EM) 2*4096kB (UM) 3*8192kB 
(EM) 2*16384kB (EM) 10*
| 32768kB (MR) = 411376kB
| [5.10] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 
hugepages_size=32768kB
| [5.108000] 3559 total pagecache pages
| [5.112000] 0 pages in swap cache
| [5.116000] Swap cache stats: add 0, delete 0, find 0/0
| [5.12] Free swap  = 0kB
| [5.124000] Total swap = 0kB
| [5.128000] 40959 pages RAM
| [5.132000] 0 pages HighMem/MovableOnly
| [5.136000] 10054 pages reserved
| [5.14] pata_via :00:05.1: failed to start port 0 (errno=-12)
| [5.144000] pata_via: probe of :00:05.1 failed with error -12

Does anyone has an idea of the problem, or have experienced the issue
with other MIPS platforms?

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20141020152709.gd19...@hall.aurel32.net

Bug#751238: Reopen bug report for switching hwclock-set to use hctosys

[Aurelien Jarno]

On Tue, Oct 07, 2014 at 08:21:51PM +0200, Michael Biebl wrote:
 Am 07.10.2014 um 19:14 schrieb Andreas Henriksson:
  Control: reopen -1
  Control: found -1 2.25.1-4
  
  Hello!
  
  I'm reopening this bug report regarding using --hctosys in the util-linux
  hwclock-set script. The change was proposed for the benefit of arm
  systems where RTC drivers are built as modules and when they get loaded
  the previous scheme didn't work.
  
  Unfortunately it was reported that the new scheme breaks systems which
  (AIUI) the hardware clock is set to local time (and using the new
  initramfs-tools 0.118 scheme where time set set up in the initramfs).
  
  As I overheard discussions about building the RTC drivers on ARM into
  the kernel I'm going to revert this change in hwclock-set as well.
  This should unbreak all versions for now. 

Yes, the next upload of the kernel will have the RTC drivers built-in.
If we keep this policy I think this change is fine.

  I'm thus reopening this bug and hope for feedback on how we best handle
  this in the future or if it's just ok to have a requirement on RTC drivers
  needing to be built-in.
 
 Fwiw, it was me, how experiences this issue.
 After the switch from systz to hctosys in /lib/udev/hwclock-set, my
 hardware clock is no longer properly set under systemd.
 
 Afaics, this is because systemd set's the clock internally and doesn't
 care for the flag file that is created by hwclock-set.
 Under sysvinit, I don't encounter this problem.
 
 When switching hwclock-set back to systz, it works properly for both
 systemd and sysvinit.

I don't really see how it can happen, this file is not supposed to be
run under systemd, due to the following code at the beginning:

| if [ -e /run/systemd/system ] ; then
|exit 0
| fi

Therefore it should not be run on systemd. It was actually one of the
problem I reported on IRC before we switched all the RTC drivers to
built-in.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20141007183728.gd24...@hall.aurel32.net

Bug#751238: Reopen bug report for switching hwclock-set to use hctosys

[Aurelien Jarno]

On Tue, Oct 07, 2014 at 08:40:26PM +0200, Michael Biebl wrote:
 Am 07.10.2014 um 20:37 schrieb Aurelien Jarno:
  On Tue, Oct 07, 2014 at 08:21:51PM +0200, Michael Biebl wrote:
  Fwiw, it was me, how experiences this issue.
  After the switch from systz to hctosys in /lib/udev/hwclock-set, my
  hardware clock is no longer properly set under systemd.
 
  Afaics, this is because systemd set's the clock internally and doesn't
  care for the flag file that is created by hwclock-set.
  Under sysvinit, I don't encounter this problem.
 
  When switching hwclock-set back to systz, it works properly for both
  systemd and sysvinit.
  
  I don't really see how it can happen, this file is not supposed to be
  run under systemd, due to the following code at the beginning:
  
  | if [ -e /run/systemd/system ] ; then
  |exit 0
  | fi
  
  Therefore it should not be run on systemd. It was actually one of the
  problem I reported on IRC before we switched all the RTC drivers to
  built-in.
 
 Keep in mind, that /run/systemd/system does not exist in the initramfs
 as we don't use systemd in the initramfs (yet).
 So afaics what happens is, that we run hwclock twice under systemd:
 once in the initramfs, a second time by systemd itself.
 

Oh running hwclock from the initramfs is something new then. At the time
I reported the bug this was not the case. I still don't get why it
doesn't work though. Running hwclock --hctosys in the initramfs should
not be different than what the kernel does for built-in modules.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20141007184456.gf24...@hall.aurel32.net

Bug#762066: CONFIG_OCTEON_USB=y

[Aurelien Jarno]

On Thu, Sep 18, 2014 at 07:25:09AM +0200, Heinrich Schuchardt wrote:
 Package: linux-image-octeon
 Version: 3.16+60
 Severity: important
 
 Booting from the internal USB drive of an Ubiquity EdgeRouter Lite requires
 CONFIG_OCTEON_USB=y
 
 Please, add this to the kernel config file of Octeon Linux images.
 
 At least as of Kernel 3.17-rc4 the driver works without problems.

Why do you need it defined as built-in? Couldn't it be defined as a
module instead and then loaded though by initramfs?

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140918171504.ga10...@hall.aurel32.net

Bug#762066: CONFIG_OCTEON_USB=y

[Aurelien Jarno]

On Thu, Sep 18, 2014 at 08:48:35PM +0200, Heinrich Schuchardt wrote:
 
 
 Am 18.09.14 um 19:15 schrieb Aurelien Jarno
 
  On Thu, Sep 18, 2014 at 07:25:09AM +0200, Heinrich Schuchardt wrote:
  
   Package: linux-image-octeon
  
   Version: 3.16+60
  
   Severity: important
  
   
  
   Booting from the internal USB drive of an Ubiquity EdgeRouter Lite 
   requires
  
   CONFIG_OCTEON_USB=y
  
   
  
   Please, add this to the kernel config file of Octeon Linux images.
  
   
  
   At least as of Kernel 3.17-rc4 the driver works without problems.
  
  
  
  Why do you need it defined as built-in? Couldn't it be defined as a
  
  module instead and then loaded though by initramfs?
  
 
 If using initramfs this would be on the same partition of the USB device as 
 vmlinux.

True

 U-boot loads vmlinux. How can vmlinux read initramfs from USB without built 
 in USB
 support? Which package will generate initramfs?

vmlinux doesn't load the initramfs, it's the responsibility of U-boot to
do so. The initramfs should be created automatically with a recent
Debian kernel (= 3.14).

In your case we still need to activate CONFIG_OCTEON_USB. That could be
done easily as a module, we don't want it as built-in.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140918194102.ga14...@hall.aurel32.net

Bug#762066: CONFIG_OCTEON_USB=y

[Aurelien Jarno]

On Thu, Sep 18, 2014 at 10:09:57PM +0200, Heinrich Schuchardt wrote:
 
 
 Am 18.09.14 um 21:41 schrieb Aurelien Jarno
 
  On Thu, Sep 18, 2014 at 08:48:35PM +0200, Heinrich Schuchardt wrote:
  
   
  
   
  
   Am 18.09.14 um 19:15 schrieb Aurelien Jarno
  
   
  
On Thu, Sep 18, 2014 at 07:25:09AM +0200, Heinrich Schuchardt wrote:
  

  
 Package: linux-image-octeon
  

  
 Version: 3.16+60
  

  
 Severity: important
  

  
 
  

  
 Booting from the internal USB drive of an Ubiquity EdgeRouter Lite 
 requires
  

  
 CONFIG_OCTEON_USB=y
  

  
 
  

  
 Please, add this to the kernel config file of Octeon Linux images.
  

  
 
  

  
 At least as of Kernel 3.17-rc4 the driver works without problems.
  

  

  

  
Why do you need it defined as built-in? Couldn't it be defined as a
  

  
module instead and then loaded though by initramfs?
  

  
   
  
   If using initramfs this would be on the same partition of the USB device 
   as vmlinux.
  
  
  
  True
  
  
  
   U-boot loads vmlinux. How can vmlinux read initramfs from USB without 
   built in USB
  
   support? Which package will generate initramfs?
  
  
  
  vmlinux doesn't load the initramfs, it's the responsibility of U-boot to
  
  do so. The initramfs should be created automatically with a recent
  
  Debian kernel (= 3.14).
  
  
  
  In your case we still need to activate CONFIG_OCTEON_USB. That could be
  
  done easily as a module, we don't want it as built-in.
  
  
 How do we ensure that the octeon USB driver module ends up in initramfs? Is 
 some modprobe configuration file entry needed? Will this entry be part of 
 package linux-image-octeon?

It's something configurable in /etc/initramfs-tools/initramfs.conf, but
by default most modules will end-up in the initramfs.

Aurelien


-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140918205806.gb14...@hall.aurel32.net

Bug#761656: linux: 3.16.2-3 misses some patches for hypervisor enablement

[Aurelien Jarno]

On Mon, Sep 15, 2014 at 03:34:15PM +0200, Frederic Bonnard wrote:
 Package: src:linux
 Version: 3.16.2-3
 Severity: normal
 Tags: patch
 User: debian-powe...@lists.debian.org
 Usertags: ppc64el

Hi,

 Dear Maintainer,
 the current KVM patches added for powerpc are missing a few ones to be able 
 to run
 qemu guests.
 It needs : 
 1287cb3fa85c KVM: PPC: Book3S: Move vcore definition to end of kvm_arch
 c77dcacb3975 KVM: Move more code under CONFIG_HAVE_KVM_IRQFD
 
 and also some config :
 CONFIG_KVM_BOOK3S_64=m
 CONFIG_KVM_BOOK3S_64_HV=m
 CONFIG_KVM_BOOK3S_64_PR=m
 CONFIG_KVM_XICS=y
 
 I rebuilt the deban kernel with those and could run a VM.

Thanks a lot for testing that, I have stupidly forgotten to enable KVM
when backporting the patches, my bad. Unfortunately enabling it changes
the ABI, so it's not possible to change it now and will have to wait for
the next ABI bump. I have therefore committed the two patches you
mentioned and enable all options except CONFIG_KVM_BOOK3S_64. I'll do it
in the next ABI bump.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140916073128.gp28...@hall.aurel32.net

Bug#761874: linux: ABI bump to 3.16-2

[Aurelien Jarno]

Source: linux
Version: 3.16.2-3
Severity: normal

control: block 760702 by -1
control: block 761656 by -1

Some changes in the linux kernel need an ABI bump to 3.16-2. This bug is
there to track which changes will benefit from this ABI bump so they are
not forgotten when it happens.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
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/20140916125034.2425.60311.report...@volta.rr44.fr

Bug#759389: linux: ppc64el: do NOT switch to vmlinu*z*

[Aurelien Jarno]

On Tue, Sep 02, 2014 at 10:31:29AM -0300, Mauricio Faria de Oliveira wrote:
 Hi Aurelien,
 
 On 08/29/2014 06:49 PM, Aurelien Jarno wrote:
 On Fri, Aug 29, 2014 at 10:15:47AM -0300, Mauricio Faria de Oliveira wrote:
 I have to ask you to please revert the vmlinu*z* patch.
 
 Some of the ppc64el target platforms can only boot vmlinu*x*
 (no support for compressed kernels).
 
 Really sorry for taking your time.
 No problem, I have just reverted this.
 
 Thanks for reverting it.
 
 (If it's not too much too ask, now that the revert-panic [for me] ended)
 
 We can drop the patch 'ppc64el-disable-zImage.patch' now that the zImage
 targets (i.e., zImage.pseries) don't cause build errors anymore.
 
 The attached debdiff does that.
 
 It was actually part of the previous patch.. so I probably should have
 asked you to just revert the 'defines' changes previously.. apologies;
 but I couldn't let go another thing like this w/out re-testing it. :/
 
 I have successfully built linux-3.16-1~exp1 with it, and booted on that
 platform I mentioned (just to /triple/-check the vmlinux file had no
 sign of vmlinuz compression whatsoever.. even knowing this is dumb :).

Thanks, I have just committed your patch.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140902215527.ge15...@hall.aurel32.net

Bug#759389: linux: ppc64el: do NOT switch to vmlinu*z*

[Aurelien Jarno]

On Fri, Aug 29, 2014 at 10:15:47AM -0300, Mauricio Faria de Oliveira wrote:
 Hi Aurelien,
 
 On 08/27/2014 04:42 AM, Aurelien Jarno wrote:
  Thanks, I have just committed this patch, it will be in the next upload.
 
 I have to ask you to please revert the vmlinu*z* patch.
 
 Some of the ppc64el target platforms can only boot vmlinu*x*
 (no support for compressed kernels).
 
 Really sorry for taking your time.

No problem, I have just reverted this.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140829214908.gj5...@ohm.rr44.fr

Bug#759389: linux: ppc64el: switch to vmlinuz (from vmlinux)

[Aurelien Jarno]

On Tue, Aug 26, 2014 at 07:35:22PM -0300, Mauricio Faria de Oliveira wrote:
 Package: src:linux
 Version: 3.16-1~exp1
 Tags: patch
 User: debian-powe...@lists.debian.org
 Usertags: ppc64el
 
 Hi maintainers,
 
 This patch switches the kernel type/image filename on ppc64el
 to vmlinuz (from vmlinux), and drops a workaround patch.
 
   $ dpkg-deb -c
 linux-image-3.16-trunk-powerpc64le_3.16-1~exp1ppc64el1_ppc64el.deb |
 fgrep vmlinu
   -rw-r--r-- root/root   4306765 2014-08-21 20:20
 ./boot/vmlinuz-3.16-trunk-powerpc64le
 
   $ dpkg-deb -c 
 kernel-image-3.16-trunk-powerpc64le-di_3.16-1~exp1ppc64el1_ppc64el.udeb
 | fgrep vmlinu
   -rw-r--r-- root/root   4306765 2014-08-21 20:22 ./boot/vmlinuz
 
 The zImage build is available starting with linux 3.16, with the
 introduction of the '64bit little endian wrapper' patch-set.
 (FYI, this is also happening in Ubuntu LP #1358920 [1])
 
 The necessary changes for d-i will be submitted shortly (on #754093).
 
 May you please consider it for an upload?
 

Thanks, I have just committed this patch, it will be in the next upload.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140827074230.gb13...@hall.aurel32.net

Bug#758620: linux-image-3.2.0-4-powerpc64: please enable CONFIG_VSX in the powerpc64 flavours

[Aurelien Jarno]

On Tue, Aug 19, 2014 at 01:23:48PM +0300, Konstantinos Margaritis wrote:
 Package: linux
 Version: 3.2.0-4
 Severity: minor
 
 Hi,
 
 I was trying to test some VSX code in the partch.debian.org
 powerpc/powerpc64 porterbox and while VSX support was enabled in the
 compiler, it was not enabled in the kernel. Since it's
 required/recommended to use official kernels in Debian porterboxes, I
 was advised to send a bug report to the kernel package to have VSX
 enabled in the stable (but also the unstable) PowerPC64 kernel as well.
 For that matter, the ppc64el porterbox, pastel.debian.net does have VSX
 enabled, but I would like to test both big and little endian VSX code.

Setting CONFIG_VSX=y on the wheezy kernel triggers an ABI change
affecting almost all symbols, so I think this change is unlikely to
happen. If VSX needs to be activated on a wheezy machine, the bpo kernel
would do it. And this problem will be fixed for jessie as the 3.14
kernel already has CONFIG_VSX=y.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140819194016.ga13...@hall.aurel32.net

Re: Uploading linux (3.14.13-2)

[Aurelien Jarno]

I intend to upload linux version 3.14.13-2 to unstable tonight Zulu
time. This should fix the FTBFS on mipsel and fix a security issue on
s390x.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140724072034.gb18...@hall.aurel32.net

Re: Kernel version for jessie

[Aurelien Jarno]

On Fri, Jul 18, 2014 at 05:43:06PM +0100, Ben Hutchings wrote:
 On Thu, 2014-05-01 at 17:29 +0100, Ben Hutchings wrote:
 [...]
  The earlier we freeze the kernel, the more work will be required to
  backport fixes and hardware enablement during the jessie support period.
  So I think that 3.16 would be the best fit.
  
  It is also very unlikely that a PREEMPT_RT patchset will be available
  for 3.15 or 3.17, but there probably will be one for 3.16.
 
  I won't have time to take on maintenance of another longterm stable
  branch besides 3.2, so I think it is important that the version we use
  can be based on a longterm stable branch maintained by someone else.  On
  that basis, I would like to propose to Greg K-H that his next longterm
  branch be based on 3.16.
 [...]
 
 I did talk to Greg about this, but as you probably all know by now, he
 selected 3.14 as there are other major users with earlier freeze dates
 than us.
 
 Ubuntu 14.10 is planned to use Linux 3.16, in which case Ubuntu will
 maintain a 3.16-stable branch (not blessed by kernel.org, but still
 following the same rules).
 
 So we have a choice between:
 
 Linux 3.14-stable
 - Supported by Greg for about 2 years after release (March 2014)
 - As an official kernel.org branch, it is likely to get some more
   testing and review, and more backports from upstream maintainers
 
 Linux 3.16-stable
 - Supported by Ubuntu kernel team for about 15-18 months after distro
   release (October 2014)
 - Will support more current hardware and need fewer driver backports
 
 Both of these will be supported until about the same time that wheezy
 reaches EOL, which is when I intend to stop maintaining 3.2-stable.  At
 that point, I would be prepared to take over maintainership of either of
 the newer branches.
 
 There's not an obvious winner out of these two options, but we should
 choose fairly soon.  Please speak up with arguments either way.

I have a slight preference to 3.16 as it gets better MIPS hardware
support (Loongson 3A, newer Octeon boards, etc.). That said it's not
a really strong argument, as I will take advantage of the planned ABI
break to backport these changes.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140719080943.ga12...@hall.aurel32.net

Re: New debconf template for the linux package

[Aurelien Jarno]

On Wed, Jul 16, 2014 at 07:22:45AM +0200, Christian PERRIER wrote:
 Quoting Aurelien Jarno (aurel...@aurel32.net):
 
  +Template: 
  linux-image-@abiname@@localversion@/postinst/mips-initrd-@abiname@@localversion@
  +Type: note
  +_Description: Boot loader configuration must be updated to load initramfs
  + This kernel package will build an initramfs file
  + (/boot/initrd.img-@abiname@) for the boot loader to use in
  + addition to the kernel itself. This method, formerly unsupported
  + on MIPS, enables a more flexible boot process, and future kernel
  + versions may require a corresponding initrd.img to boot.
  + .
  + The currently running kernel has been booted without an initramfs.
  + You should reconfigure your boot loader to load the initramfs for
  + Linux version @abiname@ and for each later version. To achieve that
  + you might use the initrd.img symlink created by this kernel.
 
 
 The only remark I have would be suggesting top replace your boot
 laoder by the boot loader or the system's boot loader

Agreed, I will use the system's boot loader.

 Ah, and maybe replace symlink by symbolic link in our
 dejargonization efforts...:-)

Indeed, thanks for the suggestion.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140716130737.ga22...@hall.aurel32.net

Re: New debconf template for the linux package

[Aurelien Jarno]

On Wed, Jul 16, 2014 at 09:47:05AM +0100, Justin B Rye wrote:
 victory wrote:
  +Template: 
  linux-image-@abiname@@localversion@/postinst/mips-initrd-@abiname@@localversion@
  +Type: note
  +_Description: Boot loader configuration must be updated to load initramfs
  + This kernel package will build an initramfs file
  + (/boot/initrd.img-@abiname@) for the boot loader to use in
  + addition to the kernel itself. This method, formerly unsupported
  + on MIPS, enables a more flexible boot process, and future kernel
  + versions may require a corresponding initrd.img to boot.
  + .
  + The currently running kernel has been booted without an initramfs.
  + You should reconfigure your boot loader to load the initramfs for
  + Linux version @abiname@ and for each later version. To achieve that
  + you might use the initrd.img symlink created by this kernel.
  ^^
 It isn't strictly the kernel that creates the symbolic link, is it?

You are correct. by this kernel package would probably be better.

 I know nothing about the MIPS boot loader (u-boot?), but if it is
 already likely to be pointing at the kernel by way of a symlink,
 maybe:

The bootloader varies from system to system, it could be sibyl, arcboot,
pmon, u-boot or grub.

 The currently running kernel was booted without an initramfs. You
 should reconfigure the boot loader to load the initramfs for Linux
 version @abiname@, and for each later version. This is probably
 most easily accomplished by using the /initrd.img symbolic link
 maintained by the kernel package.

That looks indeed better that way, thanks.

 (Or if the links might be elsewhere, drop the leading /?)

Yes, we should drop the leading /, as it depends on the bootloader, and
sometimes depending on how the partitions are configured. Basically it
should be done the same way than the kernel.
 
 Alternatively, if until now the bootloader has probably been pointing
 directly at /boot/vmlinuz-*, maybe:
 
 The currently running kernel was booted without an initramfs. You
 should reconfigure the boot loader to load the initramfs for Linux
 version @abiname@, and for each later version. (This maintenance
 can be simplified by using the /vmlinuz and /initrd.img symbolic
 links maintained by the kernel package.)

Nothing has changed for the vmlinuz symlink, so we probably don't want
to talk about it, so that people do not mix things.

 Except that wait, does u-boot use /vmlinuz or a special uimage?  Is it
 even u-boot I should be googling?  Oops, I'd better resend this CCing
 the people who might be able to answer...

To answer your question, on cavium octeons machines u-boot can directly
use the kernel in vmlinuz format.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140716131631.gb22...@hall.aurel32.net

Re: New debconf template for the linux package

[Aurelien Jarno]

On Mon, Jul 07, 2014 at 09:38:25PM +0200, Aurelien Jarno wrote:
 On Mon, Jul 07, 2014 at 10:03:04AM +0100, Justin B Rye wrote:
  Ben Hutchings wrote:
   I would write something like:
   
   Boot loader configuration must be updated to load initramfs
This kernel package will build an 'initramfs' file
(/boot/initrd.img-@abiname@) that should be loaded by the boot loader
in addition to the kernel itself.  The initramfs enables a more
flexible boot process, and it is likely that future kernel versions
will not boot without an initramfs.
.
The currently running kernel has been booted without an initramfs.
You should reconfigure your boot loader to load the initramfs for
Linux version @abiname@ and for each later version.
   
   But I think that still needs improvement, for example to say clearly
   that each kernel version needs its own initramfs.
  
  Also putting the word MIPS back in to reassure users this really is
  aimed at them:
  
  
Boot loader configuration must be updated to load initramfs
 This kernel package will build an initramfs file
 (/boot/initrd.img-@abiname@) for the boot loader to use in
 addition to the kernel itself. This method, formerly unsupported
 on MIPS, enables a more flexible boot process, and future kernel
 versions may require a corresponding initrd.img to boot.
 .
 The currently running kernel has been booted without an initramfs.
 You should reconfigure your boot loader to load the initramfs for
 Linux version @abiname@ and for each later version.
  
 
 Thanks a lot Ben and Justin for this new version. I only have a comment
 on the latest part. In most cases, the bootloaders use the symlinks
 provided by the linux-image packages. I am not sure it would be clear
 to the user in that case. Can we maybe add a sentence at the end like
 This might be done by pointing to the initrd.img symlink created by
 this kernel package.
 

So what about this new version?

Index: linux/debian/templates/image.plain.templates.in
===
--- linux/debian/templates/image.plain.templates.in (révision 21550)
+++ linux/debian/templates/image.plain.templates.in (copie de travail)
@@ -36,3 +36,17 @@
  .
  It is highly recommended to abort the kernel removal unless you are
  prepared to fix the system after removal.
+
+Template: 
linux-image-@abiname@@localversion@/postinst/mips-initrd-@abiname@@localversion@
+Type: note
+_Description: Boot loader configuration must be updated to load initramfs
+ This kernel package will build an initramfs file
+ (/boot/initrd.img-@abiname@) for the boot loader to use in
+ addition to the kernel itself. This method, formerly unsupported
+ on MIPS, enables a more flexible boot process, and future kernel
+ versions may require a corresponding initrd.img to boot.
+ .
+ The currently running kernel has been booted without an initramfs.
+ You should reconfigure your boot loader to load the initramfs for
+ Linux version @abiname@ and for each later version. To achieve that
+ you might use the initrd.img symlink created by this kernel.


-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140715180751.gb25...@hall.aurel32.net

Re: New debconf template for the linux package

[Aurelien Jarno]

On Mon, Jul 07, 2014 at 10:03:04AM +0100, Justin B Rye wrote:
 Ben Hutchings wrote:
  I would write something like:
  
  Boot loader configuration must be updated to load initramfs
   This kernel package will build an 'initramfs' file
   (/boot/initrd.img-@abiname@) that should be loaded by the boot loader
   in addition to the kernel itself.  The initramfs enables a more
   flexible boot process, and it is likely that future kernel versions
   will not boot without an initramfs.
   .
   The currently running kernel has been booted without an initramfs.
   You should reconfigure your boot loader to load the initramfs for
   Linux version @abiname@ and for each later version.
  
  But I think that still needs improvement, for example to say clearly
  that each kernel version needs its own initramfs.
 
 Also putting the word MIPS back in to reassure users this really is
 aimed at them:
 
 
   Boot loader configuration must be updated to load initramfs
This kernel package will build an initramfs file
(/boot/initrd.img-@abiname@) for the boot loader to use in
addition to the kernel itself. This method, formerly unsupported
on MIPS, enables a more flexible boot process, and future kernel
versions may require a corresponding initrd.img to boot.
.
The currently running kernel has been booted without an initramfs.
You should reconfigure your boot loader to load the initramfs for
Linux version @abiname@ and for each later version.
 

Thanks a lot Ben and Justin for this new version. I only have a comment
on the latest part. In most cases, the bootloaders use the symlinks
provided by the linux-image packages. I am not sure it would be clear
to the user in that case. Can we maybe add a sentence at the end like
This might be done by pointing to the initrd.img symlink created by
this kernel package.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140707193824.ga3...@hall.aurel32.net

Bug#749688: linux: add mips64 and mips64el support

[Aurelien Jarno]

 +4,4 @@
  # 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_4kc-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
 -Provides_loongson-3: ata-modules, ext2-modules, ext3-modules, ext4-modules, 
 rtc-modules
 +Provides: ata-modules, ext2-modules, ext3-modules, ext4-modules, rtc-modules

I am not sure if we should do that, as for example loongson-3 already
has initramfs support, and at some point we might start building some
features as modules. Worst case we can probably revert that part if
needed.

 diff --git a/debian/installer/mips64el/kernel-versions 
 b/debian/installer/mips64el/kernel-versions
 new file mode 100644
 index 000..9392add
 --- /dev/null
 +++ b/debian/installer/mips64el/kernel-versions
 @@ -0,0 +1,6 @@
 +# arch version flavour   installedname suffix build-depends
 +mips64el -   sb1-bcm91250a - y  -
 +mips64el -   loongson-2e   - y  -
 +mips64el -   loongson-2f   - y  -
 +mips64el -   loongson-3- y  -
 +mips64   -   octeon- y  -

That should be mips64el, not mips64.


 diff --git a/debian/installer/mips64el/package-list 
 b/debian/installer/mips64el/package-list
 new file mode 100644
 index 000..49a4ddb
 --- /dev/null
 +++ b/debian/installer/mips64el/package-list
 @@ -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
 +Provides_loongson-3: ata-modules, ext2-modules, ext3-modules, ext4-modules, 
 rtc-modules

I am not sure if it is better to group this defines or not, but at least
I think it should be consistent among all mips* architectures.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140626181738.ga2...@hall.aurel32.net

Bug#728705: gdb fails on s390x with Couldn't write registers: Invalid argument

[Aurelien Jarno]

reassign 728705 src:linux 3.2.35-1
affects 728705 gdb
thanks

On Mon, Nov 04, 2013 at 02:35:39PM +0100, Thibaut Paumard wrote:
 Package: gdb
 Version: 7.6.1-1
 Severity: important
 X-Debbugs-CC: debian-s...@lists.debian.org
 
 Dear Maintainer,
 
 gdb seems to be completely useless on s390x. I tried running it against
 various executables (both buggy and sane). gdb seems to launch the
 executable, however the subprocess doesn't seem to be doing anything.
 gdb just gives a message, but it does not even seem to consider the
 situation fatal and just seats there, apparently considering that the
 subprocess is running faultlessly. Example session on echo foo, notice
 how foo is not echoed:
 
  GDB SESSION ___
 
 (sid_s390x-dchroot)thibaut@zelenka:~$ gdb --args echo foo
 GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1)
 Copyright (C) 2013 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as s390x-linux-gnu.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/...
 Reading symbols from /bin/echo...(no debugging symbols found)...done.
 (gdb) run
 Starting program: /bin/echo foo
 Couldn't write registers: Invalid argument.
 (gdb) bt
 Target is executing.
 (gdb) quit
 A debugging session is active.
 
   Inferior 1 [process 18228] will be killed.
 
 Quit anyway? (y or n) y
 (sid_s390x-dchroot)thibaut@zelenka:~$

This is actually a kernel issue, affecting only a few stable branches, due
to the following patch being backported without a few other related patches:

| commit fa968ee215c0ca91e4a9c3a69ac2405aae6e5d2f
| Author: Martin Schwidefsky schwidef...@de.ibm.com
| Date:   Wed Nov 7 10:44:08 2012 +0100
| 
| s390/signal: set correct address space control
| 
| If user space is running in primary mode it can switch to secondary
| or access register mode, this is used e.g. in the clock_gettime code
| of the vdso. If a signal is delivered to the user space process while
| it has been running in access register mode the signal handler is
| executed in access register mode as well which will result in a crash
| most of the time.
| 
| Set the address space control bits in the PSW to the default for the
| execution of the signal handler and make sure that the previous
| address space control is restored on signal return. Take care
| that user space can not switch to the kernel address space by
| modifying the registers in the signal frame.
| 
| Cc: sta...@vger.kernel.org
| Signed-off-by: Martin Schwidefsky schwidef...@de.ibm.com

For the 3.2 branch, it has been introduced in version 3.2.35. I have
contacted the author of the patch to ask him what is the best option to
fix the issue.

In the meantime, I am reassigning the bug to the linux package.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140620195022.ga31...@volta.rr44.fr

Bug#751238: util-linux/linux: ignores RTC when the RTC driver is a module

[Aurelien Jarno]

Package: util-linux,linux
Severity: important
Tags: patch

With the new armmp kernel, RTC drivers are built as modules, and thus
the kernel doesn't set the system clock from the hardware clock when
the module is loaded, as explained in the RTC_HCTOSYS_DEVICE KConfig
option:

| The driver for this RTC device must be loaded before late_initcall
| functions run, so it must usually be statically linked.

In that case, util-linux should set the system clock from the RTC
itself. This is correctly done through /etc/init.d/hwclock.sh when udev
is not used. When using udev, the rule 85-hwclock.rules call
hwclock-set, which assumes that the system clock has already been set
earlier by the kernel and that the only remaining thing to do is the
correct it to the local timezone (--systz). While this was true with
the wheezy kernels, it's not longer true with the jessie one, and the
--systohc option has to be used instead.

This is the purpose of the patch below:

--- util-linux-2.20.1/debian/hwclock-set
+++ util-linux-2.20.1/debian/hwclock-set
@@ -24,5 +24,5 @@
 if [ yes = $BADYEAR ] ; then
-/sbin/hwclock --rtc=$dev --systz --badyear
+/sbin/hwclock --rtc=$dev --hctosys --badyear
 else
-/sbin/hwclock --rtc=$dev --systz
+/sbin/hwclock --rtc=$dev --hctosys
 fi
--- util-linux-2.20.1/debian/hwclock.rules
+++ util-linux-2.20.1/debian/hwclock.rules
@@ -1,4 +1,4 @@
-# Reset the System Clock to UTC if the hardware clock from which it was
-# copied by the kernel was in localtime.
+# Set the System Time from the Hardware Clock and set the kernel's timezone
+# value to the local timezone when the kernel clock module is loaded.
 
 KERNEL==rtc0, RUN+=/lib/udev/hwclock-set $root/$name

-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 3.13-0.bpo.1-armmp (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
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/20140611071626.6660.71912.report...@armhf.rr44.fr

Bug#751143: initramfs-tools: please add support for virtio-mmio

[Aurelien Jarno]

Package: initramfs-tools
Version: 0.115
Severity: normal
Tags: patch

Hi,

On most virtual machines it is possible to use the virtio interface
through the PCI bus to export for example block or net devices. On some
architectures the emulated machine does not have a PCI bus, and thus the
transport goes through an MMIO interface.

Currently initramfs-tools correctly handle the PCI case, but not the
MMIO on. In case of a virtio based root device, the virtio_mmio module
is not available in the initramfs causing the boot to fail. The patch
below adds the virtio_mmio module if virtio is used (in dep mode), or by
default (in most mode). Could you please apply it in the next upload?

Thanks,
Aurelien


--- a/hook-functions
+++ b/hook-functions
@@ -399,7 +399,7 @@
fi
 
if [ -e /sys/bus/virtio ] ; then
-   modules=$modules virtio_pci
+   modules=$modules virtio_pci virtio_mmio
fi
 
if [ -e /sys/bus/i2o/devices/ ]; then
@@ -437,7 +437,8 @@
modules=$modules btrfs ext2 ext3 ext4 ext4dev 
modules=$modules isofs jfs reiserfs udf xfs
modules=$modules nfs nfsv2 nfsv3 nfsv4
-   modules=$modules af_packet atkbd i8042 virtio_pci
+   modules=$modules af_packet atkbd i8042
+   modules=$modules virtio_pci virtio_mmio
 
# Include all HID drivers unless we're sure they
# don't support keyboards.  hid-*ff covers various


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 5.3M Jun 10 20:14 /boot/initrd.img-3.14-1-arm64
-- /proc/cmdline
root=/dev/vda1 console=ttyAMA0

-- /proc/filesystems
ext3
ext2
ext4

-- lsmod
Module  Size  Used by
virtio_rng  2400  0 
rtc_pl031   4112  0 
ext4  454832  1 
crc16   1314  1 ext4
mbcache 5984  1 ext4
jbd2   79674  1 ext4
virtio_net 19090  0 
virtio_blk  7329  3 
virtio_mmio 4334  0 
virtio_ring 7645  4 virtio_blk,virtio_net,virtio_rng,virtio_mmio
virtio  4224  4 virtio_blk,virtio_net,virtio_rng,virtio_mmio

-- /etc/initramfs-tools/modules
pl031

-- /etc/kernel-img.conf
# Kernel Image management overrides
# See kernel-img.conf(5) for details
do_symlinks = Yes

-- /etc/initramfs-tools/initramfs.conf
MODULES=most
BUSYBOX=y
KEYMAP=n
COMPRESS=gzip
DEVICE=
NFSROOT=auto

-- /etc/initramfs-tools/update-initramfs.conf
update_initramfs=yes
backup_initramfs=no

-- mkinitramfs hooks
/etc/initramfs-tools/hooks/:

/usr/share/initramfs-tools/hooks:
busybox
keymap
klibc
kmod
resume
thermal
udev


-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 3.14-1-arm64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages initramfs-tools depends on:
ii  cpio   2.11+dfsg-2
ii  klibc-utils2.0.3-1
ii  kmod   17-2
ii  module-init-tools  17-2
ii  udev   204-10

Versions of packages initramfs-tools recommends:
pn  busybox | busybox-initramfs | busybox-static  none

Versions of packages initramfs-tools suggests:
pn  bash-completion  none

-- no debconf information


-- 
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/20140610182603.15879.63018.report...@arm64.rr44.fr

Bug#742512: linux: kernel 3.13 breaks fan cooling on HP 6830S laptop fine

[Aurelien Jarno]

reassign 742512 linux
retitle 742512 linux: kernel 3.13 breaks fan cooling on HP 6830S laptop
found 742512 linux/3.13.4-1
forwarded 742512 https://bugzilla.kernel.org/show_bug.cgi?id=717
thanks

On Fri, Mar 28, 2014 at 04:21:15PM +0100, MERLIN Philippe wrote:
 Le mardi 25 mars 2014, 23:55:44 Aurelien Jarno a écrit :
  On Mon, Mar 24, 2014 at 05:30:56PM +0100, merlin wrote:
   Package: lm-sensors
   Version: 1:3.3.4-2
   Severity: important
   
   Dear Maintainer,
   
   
   When  i move to  linux 3.13-1 i remark that the fan of my computer HP
   6830S
   work by in blow  and when i observe the temperature given by sensors the
   temperature are very high so it's must be critical for the computer.
  
   sensors :
  lm-sensors doesn't control the fan, it only display the temperatures
  returned by the sensors. Have you configured fancontrol to control the
  fan or did you leave the BIOS of you computer handling that (which is
  fine if it worked with 3.12)?
 Thanks for your answer.
 For the Bios i can't answer at your question, I do'nt see in the Bios HP 
 anything about leaving kernel control the fan.
 fancontrol was never configured because pwmconfig does not work, so 
 fancontrol 
 is installed but not configured. At start there is a message saying that 
 fancontrol is not started because not configured.
 I observe in 3.12 the fan works smoothly and in an continuous way, in 3.13  
 by 
 in blow.
 in 3.12 the temp6 indicator given by sensors evolves during the session and 
 the speed of the fan also.
 in 3.13 the temp6 indicator doe's not evolve during the session and kept the 
 value of start low if the computer is cold and high if the computer is hot at 
 start and then the fan works continuously.
 With these observation i think that the temp6 indicator is very important for 
 the speed of the fan.
 Do you think i must remove fancontrol ?

If you don't use fancontrol and that just switch from kernel 3.12 to
3.13 causes this issue, it is definitely a kernel issue. It is very
likely to be the following upstream bug: 
https://bugzilla.kernel.org/show_bug.cgi?id=71711

I am therefore reassigning the bug to the linux package.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20140406173348.gw23...@hall.aurel32.net

Bug#725492: linux-source: deb file contains data.tar.gz instead of data.tar

[Aurelien Jarno]

Package: linux-source-3.10
Version: 3.10.11-1
Severity: important

linux-source-3.10_3.10.11-1_all.deb contains a data.tar.gz file, but
this file should also be named data.tar as it is not compressed:
|  $ file data.tar.gz 
|  data.tar.gz: POSIX tar archive (GNU)

This causes gunzip to fails:
| $ gunzip data.tar.gz 
|
| gzip: data.tar.gz: not in gzip format

Which breaks at least apt-ftparchive, and probably more tools:
| E: Sub-process gzip received signal 2.
| E: Errors apply to file 
'/srv/mini-dak/ftp/debian/pool/main/l/linux/linux-source-3.10_3.10.11-1_all.deb'

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


-- 
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/20131006142710.6607.61774.report...@volta.rr44.fr

Bug#719993: linux-image-3.2.0-4-s390x: hangs hard after a few hours

[Aurelien Jarno]

 entries: 256 (order: 1, 8192 bytes)
[1.207542] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[1.209936] NET: Registered protocol family 1
[1.210824] Unpacking initramfs...
[5.169733] Freeing initrd memory: 5018k freed
[5.178775] audit: initializing netlink socket (disabled)
[5.178967] type=2000 audit(1376605775.711:1): initialized
[5.182711] HugeTLB registered 1 MB page size, pre-allocated 0 pages
[5.187510] VFS: Disk quotas dquot_6.5.2
[5.188676] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[5.190118] msgmni has been set to 991
[5.193904] alg: No test for stdrng (krng)
[5.194487] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 
254)
[5.194629] io scheduler noop registered
[5.194726] io scheduler deadline registered
[5.195212] io scheduler cfq registered (default)
[5.196621] hvc_iucv: The z/VM IUCV HVC device driver cannot be used without 
z/VM
[5.199129] cio: Channel measurement facility initialized using format basic 
(mode autodetected)
[5.214599] TCP cubic registered
[5.215539] NET: Registered protocol family 10
[5.226815] Mobile IPv6
[5.226890] NET: Registered protocol family 17
[5.227002] Registering the dns_resolver key type
[5.229837] PM: Hibernation image not present or could not be loaded.
[5.229945] registered taskstats version 1
[5.236092] Initializing network drop monitor service
[5.237241] Freeing unused kernel memory: 228k freed
[5.512379] udevd[51]: starting version 175
[5.756319] dasd-eckd 0.0.0120: New DASD 3390/0C (CU 3990/02) with 32760 
cylinders, 15 heads, 224 sectors
[5.903605] dasd-eckd 0.0.0120: DASD with 4 KB/block, 23587200 KB total 
size, 48 KB/track, compatible disk layout
[5.905962]  dasda:VOL1/  LIN120: dasda1 dasda2
[6.621367] EXT4-fs (dasda1): mounted filesystem with ordered data mode. 
Opts: (null)
[   10.717869] udevd[224]: starting version 175
[   11.568157] ctcm: CTCM driver initialized
[   11.613125] lcs: Loading LCS driver
[   12.259099] net ctc0: setup OK : r/w = ch-0.0.0a00/ch-0.0.0a01, protocol : 0
[   15.378358] ioctl32(fgconsole:468): Unknown cmd fd(3) 
cmd(5603){t:'V';sz:0} arg(7faf814e) on /dev/console
[   16.186473] Adding 1219148k swap on /dev/dasda2.  Priority:-1 extents:1 
across:1219148k 
[   16.573775] EXT4-fs (dasda1): re-mounted. Opts: (null)
[   17.891993] EXT4-fs (dasda1): re-mounted. Opts: errors=remount-ro
[   33.554168] net ctc0: Connected with remote side
[   34.643037] IPv6 over IPv4 tunneling driver
[   39.261122] ioctl32(fgconsole:1625): Unknown cmd fd(3) 
cmd(5603){t:'V';sz:0} arg(7fdd0d0e) on /dev/console
[ 1951.060067] hrtimer: interrupt took 10545003 ns

** Model information
processor 0: version = 00,  identification = 002623,  machine = 3090
processor 1: version = 00,  identification = 102623,  machine = 3090

** Loaded modules:
sit
tunnel4
lcs
ctcm
ccwgroup
fsm
ext4
crc16
jbd2
mbcache
dasd_eckd_mod
dasd_mod

** PCI devices:
not available

** USB devices:
not available


-- System Information:
Debian Release: 7.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: s390 (s390x)

Kernel: Linux 3.2.0-4-s390x (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages linux-image-3.2.0-4-s390x depends on:
ii  debconf [debconf-2.0]   1.5.49
ii  initramfs-tools [linux-initramfs-tool]  0.109.1
ii  kmod9-3
ii  linux-base  3.5
ii  module-init-tools   9-3

Versions of packages linux-image-3.2.0-4-s390x recommends:
pn  firmware-linux-free  none

Versions of packages linux-image-3.2.0-4-s390x suggests:
pn  debian-kernel-handbook  none
pn  linux-doc-3.2   none
ii  s390-tools  1.16.0-2

Versions of packages linux-image-3.2.0-4-s390x is related to:
pn  firmware-atherosnone
pn  firmware-bnx2   none
pn  firmware-bnx2x  none
pn  firmware-brcm80211  none
pn  firmware-intelwimax none
pn  firmware-ipw2x00none
pn  firmware-ivtv   none
pn  firmware-iwlwifinone
pn  firmware-libertas   none
pn  firmware-linux  none
pn  firmware-linux-nonfree  none
pn  firmware-myricomnone
pn  firmware-netxen none
pn  firmware-qlogic none
pn  firmware-ralink none
pn  firmware-realteknone
pn  xen-hypervisor  none

-- debconf information excluded
From: Aurelien Jarno aurel...@aurel32.net
Date: Fri Aug 16 07:01:50 2013 +0200
Subject: Revert s390: Use direct ktime path for s390 clockevent device
Forwarded: no (upstream is working on a real fix)

This reverts commit 4f37a68cdaf6dea833cfdded2a3e0c47c0f006da.

---
 arch/s390/kernel/time.c |   19 ---
  1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/arch/s390/kernel/time.c b/arch/s390

Re: Bug#705118: debian-installer: FTBFS on armhf: Unable to locate package nic-modules-3.2.0-4-mx5-di

[Aurelien Jarno]

On Mon, Apr 15, 2013 at 01:47:28AM +0100, Ben Hutchings wrote:
 On Sun, 2013-04-14 at 23:41 +0200, Aurelien Jarno wrote:
 [...]
  Sorry to answer late, I only have been able to test it now.
  Unfortunately the vexpress image is now broken, due to this change:
  
  |  * Replace nic-modules with nic-{usb,wireless}-modules in armhf netboot
  |images (Closes: #705118)
  
  nic-modules is still needed on vexpress as it provides the module for
  the on-board NIC. 
 
 Since any system with external USB ports should be able to work with
 arbitrary USB Ethernet controllers, I added nic-{usb,wireless}-modules
 packages and removed the USB modules you originally specified in
 nic-modules.  In the case of mx5 this left nic-modules empty, and I
 removed it, but for vexpress there was that one module left, smsc911x.
 
 Unfortunately I then removed nic-modules from the installer for *both*
 flavours instead of just mx5.
 
 I just tried adding smsc91xx back into the current daily netboot initrd
 and it seems to work in QEMU (up to the point where the installer finds
 I didn't attach a disk).

Yes, I have committed such a change, and I have been able to do a full
installation that way. The daily image that will be generated in a few
hours should have the fix, I will test it when available.

 By the way, given that the majority of users for the vexpress flavour
 will be running it in QEMU rather than a real Motherboard Express
 (they're expensive!), is it possible to support an alternate model like
 virtio_net that may be emulated more efficiently?

Unfortunately the vexpress board doesn't have PCI/PCIE support so the
standard virtio doesn't work there. People are working on virtio-mmio,
but it seems to be something difficult to get working correctly.

Aurelien

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20130415083403.gb32...@ohm.aurel32.net

Re: Bug#705118: debian-installer: FTBFS on armhf: Unable to locate package nic-modules-3.2.0-4-mx5-di

[Aurelien Jarno]

On Mon, Apr 15, 2013 at 10:34:03AM +0200, Aurelien Jarno wrote:
 On Mon, Apr 15, 2013 at 01:47:28AM +0100, Ben Hutchings wrote:
  On Sun, 2013-04-14 at 23:41 +0200, Aurelien Jarno wrote:
  [...]
   Sorry to answer late, I only have been able to test it now.
   Unfortunately the vexpress image is now broken, due to this change:
   
   |  * Replace nic-modules with nic-{usb,wireless}-modules in armhf netboot
   |images (Closes: #705118)
   
   nic-modules is still needed on vexpress as it provides the module for
   the on-board NIC. 
  
  Since any system with external USB ports should be able to work with
  arbitrary USB Ethernet controllers, I added nic-{usb,wireless}-modules
  packages and removed the USB modules you originally specified in
  nic-modules.  In the case of mx5 this left nic-modules empty, and I
  removed it, but for vexpress there was that one module left, smsc911x.
  
  Unfortunately I then removed nic-modules from the installer for *both*
  flavours instead of just mx5.
  
  I just tried adding smsc91xx back into the current daily netboot initrd
  and it seems to work in QEMU (up to the point where the installer finds
  I didn't attach a disk).
 
 Yes, I have committed such a change, and I have been able to do a full
 installation that way. The daily image that will be generated in a few
 hours should have the fix, I will test it when available.
 

I have just done a test of the daily image from this morning, and the
installation was successful.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20130415190743.gq6...@hall.aurel32.net

Re: Bug#705118: debian-installer: FTBFS on armhf: Unable to locate package nic-modules-3.2.0-4-mx5-di

[Aurelien Jarno]

On Thu, Apr 11, 2013 at 10:53:12AM +0200, Cyril Brulebois wrote:
 Control: tag -1 patch moreinfo
 
 Cyril Brulebois k...@debian.org (10/04/2013):
  Patches (preferably tested ;)) against src:debian-installer to update
  package lists for armhf/{mx5,vexpress} are more than welcome. Also,
  (I know I'm asking a lot), “fast is good”.
 
 Ben Hutchings kindly sent some patches:
   http://lists.debian.org/debian-boot/2013/04/msg00220.html
   http://lists.debian.org/debian-boot/2013/04/msg00221.html
   http://lists.debian.org/debian-boot/2013/04/msg00222.html
 
 They appear to be sufficient to get debian-installer built on armhf
 again (checked in harris' sid chroot). Unfortunately, I have no idea
 how to test the generated images, so actual testing would be
 appreciated.
 
 I've uploaded the generated images on people.debian.org:
   http://people.debian.org/~kibi/wheezy-di-rc2/
 
 It contains (excluding directories):
 | (sid-armhf-dchroot)kibi@harris:~$ tar tf 
 debian-installer-images_2013_armhf.tar.gz |grep -v /$|sort
 | ./installer-armhf/2013/images/MANIFEST
 | ./installer-armhf/2013/images/MANIFEST.udebs
 | ./installer-armhf/2013/images/MD5SUMS
 | ./installer-armhf/2013/images/SHA256SUMS
 | ./installer-armhf/2013/images/mx5/netboot/efikamx/boot.scr
 | ./installer-armhf/2013/images/mx5/netboot/efikamx/bootscript
 | ./installer-armhf/2013/images/mx5/netboot/efikamx/uImage
 | ./installer-armhf/2013/images/mx5/netboot/efikamx/uInitrd
 | ./installer-armhf/2013/images/mx5/netboot/gtk/efikamx/boot.scr
 | ./installer-armhf/2013/images/mx5/netboot/gtk/efikamx/bootscript
 | ./installer-armhf/2013/images/mx5/netboot/gtk/efikamx/uImage
 | ./installer-armhf/2013/images/mx5/netboot/gtk/efikamx/uInitrd
 | ./installer-armhf/2013/images/mx5/network-console/efikamx/boot.scr
 | ./installer-armhf/2013/images/mx5/network-console/efikamx/bootscript
 | ./installer-armhf/2013/images/mx5/network-console/efikamx/uImage
 | ./installer-armhf/2013/images/mx5/network-console/efikamx/uInitrd
 | ./installer-armhf/2013/images/udeb.list
 | ./installer-armhf/2013/images/vexpress/netboot/initrd.gz
 | ./installer-armhf/2013/images/vexpress/netboot/vmlinuz-3.2.0-4-vexpress
 | ./installer-armhf/current
 
 This seems consistent with the previous upload:
   
 https://buildd.debian.org/status/fetch.php?pkg=debian-installerarch=armhfver=20130211stamp=1360628633
 
 and with Aurélien's addition:
 | [ Aurelien Jarno ]
 | * Build a vexpress image on armhf.
 
 (I think I'll clarify in the changelog it's a netboot image.)
 
 
 → Please test and report back! Thanks already!

Sorry to answer late, I only have been able to test it now.
Unfortunately the vexpress image is now broken, due to this change:

|  * Replace nic-modules with nic-{usb,wireless}-modules in armhf netboot
|images (Closes: #705118)

nic-modules is still needed on vexpress as it provides the module for
the on-board NIC. 

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20130414214125.go6...@hall.aurel32.net

Re: Bug#705118: debian-installer: FTBFS on armhf: Unable to locate package nic-modules-3.2.0-4-mx5-di

[Aurelien Jarno]

On Sun, Apr 14, 2013 at 11:41:25PM +0200, Aurelien Jarno wrote:
 On Thu, Apr 11, 2013 at 10:53:12AM +0200, Cyril Brulebois wrote:
  Control: tag -1 patch moreinfo
  
  Cyril Brulebois k...@debian.org (10/04/2013):
   Patches (preferably tested ;)) against src:debian-installer to update
   package lists for armhf/{mx5,vexpress} are more than welcome. Also,
   (I know I'm asking a lot), “fast is good”.
  
  Ben Hutchings kindly sent some patches:
http://lists.debian.org/debian-boot/2013/04/msg00220.html
http://lists.debian.org/debian-boot/2013/04/msg00221.html
http://lists.debian.org/debian-boot/2013/04/msg00222.html
  
  They appear to be sufficient to get debian-installer built on armhf
  again (checked in harris' sid chroot). Unfortunately, I have no idea
  how to test the generated images, so actual testing would be
  appreciated.
  
  I've uploaded the generated images on people.debian.org:
http://people.debian.org/~kibi/wheezy-di-rc2/
  
  It contains (excluding directories):
  | (sid-armhf-dchroot)kibi@harris:~$ tar tf 
  debian-installer-images_2013_armhf.tar.gz |grep -v /$|sort
  | ./installer-armhf/2013/images/MANIFEST
  | ./installer-armhf/2013/images/MANIFEST.udebs
  | ./installer-armhf/2013/images/MD5SUMS
  | ./installer-armhf/2013/images/SHA256SUMS
  | ./installer-armhf/2013/images/mx5/netboot/efikamx/boot.scr
  | ./installer-armhf/2013/images/mx5/netboot/efikamx/bootscript
  | ./installer-armhf/2013/images/mx5/netboot/efikamx/uImage
  | ./installer-armhf/2013/images/mx5/netboot/efikamx/uInitrd
  | ./installer-armhf/2013/images/mx5/netboot/gtk/efikamx/boot.scr
  | ./installer-armhf/2013/images/mx5/netboot/gtk/efikamx/bootscript
  | ./installer-armhf/2013/images/mx5/netboot/gtk/efikamx/uImage
  | ./installer-armhf/2013/images/mx5/netboot/gtk/efikamx/uInitrd
  | ./installer-armhf/2013/images/mx5/network-console/efikamx/boot.scr
  | ./installer-armhf/2013/images/mx5/network-console/efikamx/bootscript
  | ./installer-armhf/2013/images/mx5/network-console/efikamx/uImage
  | ./installer-armhf/2013/images/mx5/network-console/efikamx/uInitrd
  | ./installer-armhf/2013/images/udeb.list
  | ./installer-armhf/2013/images/vexpress/netboot/initrd.gz
  | 
  ./installer-armhf/2013/images/vexpress/netboot/vmlinuz-3.2.0-4-vexpress
  | ./installer-armhf/current
  
  This seems consistent with the previous upload:

  https://buildd.debian.org/status/fetch.php?pkg=debian-installerarch=armhfver=20130211stamp=1360628633
  
  and with Aurélien's addition:
  | [ Aurelien Jarno ]
  | * Build a vexpress image on armhf.
  
  (I think I'll clarify in the changelog it's a netboot image.)
  
  
  → Please test and report back! Thanks already!
 
 Sorry to answer late, I only have been able to test it now.
 Unfortunately the vexpress image is now broken, due to this change:
 
 |  * Replace nic-modules with nic-{usb,wireless}-modules in armhf netboot
 |images (Closes: #705118)
 
 nic-modules is still needed on vexpress as it provides the module for
 the on-board NIC. 

I have just committed a fix.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20130414235046.gp6...@hall.aurel32.net

Re: Adding armhf vexpress udebs

[Aurelien Jarno]

On Wed, Jan 02, 2013 at 08:56:45PM +0100, Cyril Brulebois wrote:
 Cyril Brulebois k...@debian.org (24/11/2012):
  From a d-i point of view, this is more than welcome. I haven't
  reviewed the patch itself yet, but you can commit it right now,
  as d-i wheezy beta 4 has just been released. Just remember to
  keep us posted if some issues are detected in the upcoming days,
  so that we don't release d-i wheezy rc1 with a buggy vexpress
  support. ;-)
 
 Aurélien, ping?

Sorry about doing that late and also for the late answer. The changes
have been committed to the linux SVN on December 31st.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20130107232858.gb4...@ohm.aurel32.net

Adding armhf vexpress udebs

[Aurelien Jarno]

===
--- installer/armhf/modules/armhf-vexpress/reiserfs-modules
+++ installer/armhf/modules/armhf-vexpress/reiserfs-modules
@@ -0,0 +1 @@
+#include reiserfs-modules
Index: installer/armhf/modules/armhf-vexpress/ext3-modules
===
--- installer/armhf/modules/armhf-vexpress/ext3-modules
+++ installer/armhf/modules/armhf-vexpress/ext3-modules
@@ -0,0 +1 @@
+#include ext3-modules
Index: installer/armhf/modules/armhf-vexpress/isofs-modules
===
--- installer/armhf/modules/armhf-vexpress/isofs-modules
+++ installer/armhf/modules/armhf-vexpress/isofs-modules
@@ -0,0 +1 @@
+#include isofs-modules
Index: installer/armhf/modules/armhf-vexpress/ext4-modules
===
--- installer/armhf/modules/armhf-vexpress/ext4-modules
+++ installer/armhf/modules/armhf-vexpress/ext4-modules
@@ -0,0 +1 @@
+#include ext4-modules
Index: installer/armhf/modules/armhf-vexpress/uinput-modules
===
--- installer/armhf/modules/armhf-vexpress/uinput-modules
+++ installer/armhf/modules/armhf-vexpress/uinput-modules
@@ -0,0 +1 @@
+#include uinput-modules
Index: installer/armhf/modules/armhf-vexpress/ipv6-modules
===
--- installer/armhf/modules/armhf-vexpress/ipv6-modules
+++ installer/armhf/modules/armhf-vexpress/ipv6-modules
@@ -0,0 +1 @@
+#include ipv6-modules
Index: installer/armhf/modules/armhf-vexpress/kernel-image
===
--- installer/armhf/modules/armhf-vexpress/kernel-image
+++ installer/armhf/modules/armhf-vexpress/kernel-image
@@ -0,0 +1 @@
+# empty
Index: installer/armhf/modules/armhf-vexpress/input-modules
===
--- installer/armhf/modules/armhf-vexpress/input-modules
+++ installer/armhf/modules/armhf-vexpress/input-modules
@@ -0,0 +1 @@
+#include input-modules
Index: installer/armhf/modules/armhf-vexpress/md-modules
===
--- installer/armhf/modules/armhf-vexpress/md-modules
+++ installer/armhf/modules/armhf-vexpress/md-modules
@@ -0,0 +1 @@
+#include md-modules
Index: installer/armhf/modules/armhf-vexpress/nic-modules
===
--- installer/armhf/modules/armhf-vexpress/nic-modules
+++ installer/armhf/modules/armhf-vexpress/nic-modules
@@ -0,0 +1 @@
+smsc911x
Index: installer/armhf/modules/armhf-vexpress/fat-modules
===
--- installer/armhf/modules/armhf-vexpress/fat-modules
+++ installer/armhf/modules/armhf-vexpress/fat-modules
@@ -0,0 +1 @@
+#include fat-modules
Index: installer/armhf/modules/armhf-vexpress/mmc-modules
===
--- installer/armhf/modules/armhf-vexpress/mmc-modules
+++ installer/armhf/modules/armhf-vexpress/mmc-modules
@@ -0,0 +1,2 @@
+#include mmc-modules
+tifm_sd -
Index: installer/armhf/modules/armhf-vexpress/btrfs-modules
===
--- installer/armhf/modules/armhf-vexpress/btrfs-modules
+++ installer/armhf/modules/armhf-vexpress/btrfs-modules
@@ -0,0 +1 @@
+#include btrfs-modules
Index: installer/armhf/modules/armhf-vexpress/minix-modules
===
--- installer/armhf/modules/armhf-vexpress/minix-modules
+++ installer/armhf/modules/armhf-vexpress/minix-modules
@@ -0,0 +1 @@
+#include minix-modules
Index: installer/armhf/modules/armhf-vexpress/scsi-core-modules
===
--- installer/armhf/modules/armhf-vexpress/scsi-core-modules
+++ installer/armhf/modules/armhf-vexpress/scsi-core-modules
@@ -0,0 +1,3 @@
+#include scsi-core-modules
+scsi_mod -
+sd_mod -
Index: installer/armhf/modules/armhf-vexpress/core-modules
===
--- installer/armhf/modules/armhf-vexpress/core-modules
+++ installer/armhf/modules/armhf-vexpress/core-modules
@@ -0,0 +1,2 @@
+#include core-modules
+mbcache

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: Digital signature

Bug#637089: linux-2.6: tmpfs doesn't allow reserving blocks to the super user

[Aurelien Jarno]

Package: linux-2.6
Severity: wishlist

More and more people are using a tmpfs filesystem for /tmp, and it is
even something supported by the init scripts we ship. Contrary to most 
other filesystems, there is no space reserved to the superuser. Given 
any user can write to /tmp, and thus fully fill it. This breaks plenty
of things like upgrade of packages using debconf, so tmpfs should
definitely support having some blocks reserved to the super user.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
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/20110808131022.27908.74467.report...@volta.aurel32.net

commit r17868: linux-libc-dev: Multi-arch support

[Aurelien Jarno]

Hi,

Commit r17868 moved the headers into a multiarch directory, but this
patch seems wrong in two aspect:
- It moves the headers to the cross-compile directory, ie
  /usr/$(triplet)/include instead of the multiarch directory, ie
  /usr/include/$(triplet)
- It uses DEB_HOST_GNU_TYPE to find the triplet, which is wrong on some
  architectures. For example on i386, the multiarch triplet is
  i386-linux-gnu instead of i486-linux-gnu.

Please find a patch below to fix theses issue. Note that I have some
issues building certain biarch packages with this patch, that said
Ubuntu is using that for some times, and they don't seems to have any
problem, so it might be a local issue.

Cheers,
Aurelien


Index: rules.real
===
--- rules.real  (révision 17885)
+++ rules.real  (copie de travail)
@@ -8,6 +8,7 @@
 SHELL  := bash -e
 DEB_HOST_ARCH := $(shell dpkg-architecture -a'$(ARCH)' -qDEB_HOST_ARCH)
 DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -a'$(ARCH)' -qDEB_HOST_GNU_TYPE)
+DEB_HOST_MULTIARCH:= $(shell dpkg-architecture -a'$(ARCH)' 
-qDEB_HOST_MULTIARCH)
 DEB_BUILD_ARCH:= $(shell dpkg-architecture -a'$(ARCH)' -qDEB_BUILD_ARCH)
 UPLOADER  := $(shell dpkg-parsechangelog | sed -ne 's,^Maintainer: 
.[^]*\([^]*\),\1,p')
 
@@ -310,8 +311,8 @@
find $(OUT_DIR)/include \( -name .install -o -name ..install.cmd \) 
-execdir rm {} +
 
# Move include/asm to arch-specific directory
-   mkdir -p $(OUT_DIR)/$(DEB_HOST_GNU_TYPE)/include
-   mv $(OUT_DIR)/include/asm $(OUT_DIR)/$(DEB_HOST_GNU_TYPE)/include/
+   mkdir -p $(OUT_DIR)/include/$(DEB_HOST_MULTIARCH)
+   mv $(OUT_DIR)/include/asm $(OUT_DIR)/include/$(DEB_HOST_MULTIARCH)/

+$(MAKE_SELF) install-base
 

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20110805060449.ga5...@volta.aurel32.net

Bug#597658: Wouldn't it be better solved the /etc/modprobe.d/blacklist.conf?

[Aurelien Jarno]

On Mon, Oct 25, 2010 at 06:59:50PM +0100, Ben Hutchings wrote:
 On Fri, Oct 22, 2010 at 02:41:50PM +0200, Klaus Umbach wrote:
  Wouldn't it be better, to put the module in /etc/modprobe.d/blacklist.conf,
  instead of disabling it completely? So those who are able to use it, can
  still load it and do not have to build their own kernel.
 
 blacklist.conf applies to every installed kernel version, and is actually
 owned by udev.  For this reason we never blacklist modules in that way. 
 
  This module lowers the CPU usage of kcryptd from 90% to 25% on my machine,
  when writing to disk. So it would be great to have it.
 
 What we can do is to disable auto-loading by removing the device table
 from the module.  The user can then force loading at boot time by editing
 /etc/modules or /etc/initramfs-tools/modules (depending on how early the
 module should be loaded).
 

What about re-enabling this feature in experimental? This way we can see
if the problem is still present on recent kernel versions, and it's less
problematic in case the problem is still present than doing that in
squeeze.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
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/20110131114819.ga28...@volta.aurel32.net

Re: MIPS boot drivers

[Aurelien Jarno]

On Tue, Jun 08, 2010 at 03:51:33AM +0100, Ben Hutchings wrote:
 Martin, Aurelien,
 
 When switching from IDE to libata drivers I updated all per-architecture
 configuration files but I failed to cover per-flavour configuration
 files.  These configuration files currently enable some IDE drivers and
 the associated flavours may be broken due to the partial conversion:
 
 debian/config/armel/config.iop32x
 debian/config/m68k/config.amiga
 debian/config/m68k/config.atari
 debian/config/m68k/config.mac
 debian/config/m68k/config.q40
 debian/config/mips/config.4kc-malta (known broken; see #584784)
 debian/config/mips/config.5kc-malta
 debian/config/mips/config.r4k-ip22
 debian/config/mips/config.r5k-ip32
 debian/config/mips/config.sb1a-bcm91480b
 debian/config/mips/config.sb1-bcm91250a
 debian/config/mipsel/config.r5k-cobalt
 debian/config/sh4/config.sh7751r
 debian/config/sh4/config.sh7785lcr
 
 Ignoring m68k and sh4 as not release architectures, this leaves mostly
 MIPS platforms.  Since I know approximately nothing about these and I'm
 not sure exactly which boot methods are supposed to be supported, I'll
 have to ask you to review the configurations.  I've attached a patch
 which was my best guess at the necessary changes.
 

sh4 has always used libata.

MIPS SB1 BCM812501 has been switched to libata some times ago.

For the remaining MIPS flavors, I'll look at that later today, as it 
might include some tests.

Aurelien

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20100608053143.gl30...@hall.aurel32.net

Bug#580652: linux-libc-dev 2.6.32-12 breaks KVM and QEMU

[Aurelien Jarno]

Package: linux-libc-dev
Version: 2.6.32-12
Severity: important

linux-libc-dev version 2.6.32-12 has a backport of KVM: x86: Add
KVM_GET/SET_VCPU_EVENTS, without the corresponding KVM: x86: Extend
KVM_SET_VCPU_EVENTS with selective updates backport. This breaks KVM
and KVM support in QEMU.

It should either be reverted or the second should also be backported.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
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/20100507140544.19262.23115.report...@volta.aurel32.net

Re: Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails

[Aurelien Jarno]

On Tue, Jan 26, 2010 at 04:06:32PM -0600, Jonathan Nieder wrote:
 Bastian Blank wrote:
 
  The following program shows the cause:
  
  | #include sys/stat.h
  | #include sys/mman.h
  | #include fcntl.h
  | 
  | int main(int argc, const char * const argv[])
  | { 
  |   struct stat st;
  |   lstat(argv[1], st);
  | 
  |   int fd = open(argv[1], O_RDONLY);
  |   void *data = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
  |   void *t = memchr(data, 0, st.st_size);
  |   printf(ptr: %p, ret: %p, len: 0x%zx\n, data, t, st.st_size);
  |   return 0;
  | }
  
  Example output:
  | % ./test /etc/passwd
  | ptr: 0x2005, ret: 0x2005040e, len: 0x40e
  
  The found location is already after the buffer. memchr is AFAIK expanded
  by gcc.
 
 FYI: http://sourceware.org/bugzilla/show_bug.cgi?id=10162
 Maybe glibc 2.11.1 (which includes a cherry-pick of commit 6622141)
 will fix this.
 

This patch is already included in the Debian libc6 package. It actually
may be the cause of the problem you reported.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#563313: lm-sensors: sensors not working after suspend

[Aurelien Jarno]

On Tue, Jan 12, 2010 at 11:43:46PM +0100, Michał wrote:
 On 12.01.2010 23:16, Aurelien Jarno wrote:
 reassign 563313 linux-2.6
 thanks

 On Tue, Jan 12, 2010 at 10:44:52PM +0100, Michał wrote:

 On 12.01.2010 21:27, Aurelien Jarno wrote:
  
 On Tue, Jan 12, 2010 at 06:55:27PM +0100, Michał wrote:


 On 06.01.2010 23:52, Aurelien Jarno wrote:

  
 On Sat, Jan 02, 2010 at 12:10:41AM +0100, Aurelien Jarno wrote:



 On Fri, Jan 01, 2010 at 10:22:43PM +0100, Michał wrote:


  
 Package: lm-sensors
 Version: 1:3.1.1-4
 Severity: normal

 I have dell studio 1555 after suspend sensors don't show temperature 
 of some devces. As a result after some time devises reach top 
 temperature and system turns off, because of overheat(fans don't 
 working). Full shut down is needed I am not shure if it is problem of 
 this package but problem is serious.




 lm-sensors only read values provided by the kernel, so it is not a
 problem of this package. I see you are using a custom kernel, so can you
 please try with a Debian kernel to see if the problem is the same?



  
 Any news on that?




 When I run Debian kernel my laptop doesn't suspend at all.


  
 Ok, so we don't know if the Debian kernel has the bug or not... Do you
 have any patches related to sensors in your kernel? If not, I'll
 reassign the bug to linux-2.6, as the bug is also probably there.



 I am not shure hiw exactly is sidux kernel build. I may enlose config or
 something. More here
 http://svn.berlios.de/svnroot/repos/fullstory/linux-sidux-2.6/trunk/debian/changelog
 But I have recently found
 https://bugzilla.redhat.com/show_bug.cgi?id=532161
 So I assume that is kernel problem. Not only Debian.

  
 It is for sure a kernel problem. For now I am reassigning the bug to the
 linux-2.6 package as the problem may also be present there, but the bug
 might be closed as you are not using a Debian kernel.

 The best is probably to report the bug to the person providing the sidux
 kernel.


 Well maby better is another bug with can't suspend on dell studio 1555??


Yes, opening a bug for that is probably a good idea, as this issue is
different than the originally reported one.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#404951: sb1-bcm91250a kernel does not boot

[Aurelien Jarno]

On Tue, Dec 08, 2009 at 11:36:07PM +0100, Moritz Muehlenhoff wrote:
 On Fri, Sep 11, 2009 at 02:16:06PM +0200, Aurelien Jarno wrote:
  Martin Michlmayr a écrit :
   * Moritz Muehlenhoff j...@inutil.org [2009-09-09 21:26]:
   What's the status? Is is still broken?
   
   2.6.30 in unstable should work fine now.  Aurelien, can you confirm?
  
  It doesn't work. There are some changes needed to make it working:
  - There are missing patches in Linus' tree, linux-mips.org tree should
  be used instead.
  - The IDE controller is replaced with the PATA controller which changes
  the name of the drive.
  - A patch is needed to make the IDE controller working wrt to CPU caches.
  
  In short it's not very easy to get it working within the debian package.
 
 Does it work with 2.6.32?
 

The patch is still needed. Modules support in 2.6.31 was also broken, I
haven't found time to check how it behaves in 2.6.32.

There is still a lot of work to get the support for bcm91250a in the
debian kernel packages, but I'll try to work on that.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#552422: linux-2.6 2.6.31-1 FTBFS on mipsel

[Aurelien Jarno]

On Mon, Oct 26, 2009 at 09:04:32PM +0100, Aurelien Jarno wrote:
 On Mon, Oct 26, 2009 at 12:58:25PM -0600, dann frazier wrote:
  On Mon, Oct 26, 2009 at 11:03:27AM +0100, Aurelien Jarno wrote:
   Martin Michlmayr a écrit :
* Andreas Barth a...@not.so.argh.org [2009-10-26 07:22]:
Package: linux-2.6
Version: 2.6.31-1
Severity: serious

this package FTBFS on mipsel:
  MODPOST vmlinux.o
  GEN .version
  CHK include/linux/compile.h
  UPD include/linux/compile.h
  CC  init/version.o
  LD  init/built-in.o
  LD  .tmp_vmlinux1
ld:arch/mips/kernel/vmlinux.lds:168: syntax error

Aurelien, can you take a look at this?
   
   I'll try to have a look, but I don't know when. There are plenty of RC
   bugs on eglibc to fix first.
  
  Could it be this? I don't have hardware to test.
 
 It will most probably fix the problem. I have started a build.

Good catch, I confirm it fixes the problem.


  commit d71789b6fa37c21ce5eb588d279f57904a62e7e2
  Author: Manuel Lauss manuel.la...@gmail.com
  Date:   Thu Sep 24 21:44:24 2009 +0200
  
  mips: fix build of vmlinux.lds
  
  Commit 51b563fc93c8cb5bff1d67a0a71c374e4a4ea049 (arm, cris, mips,
  sparc, powerpc, um, xtensa: fix build with bash 4.0) removed a few
  CPPFLAGS with vital include paths necessary to build vmlinux.lds
  on MIPS, and moved the calculation of the 'jiffies' symbol
  directly to vmlinux.lds.S but forgot to change make ifdef/... to
  cpp macros.
  
  Signed-off-by: Manuel Lauss manuel.la...@gmail.com
  [sam: moved assignment of CPPFLAGS arch/mips/kernel/Makefile]
  Signed-off-by: Sam Ravnborg s...@ravnborg.org
  Acked-by: Dmitri Vorobiev dmitri.vorob...@movial.com
  
  diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
  index e961221..eecd2a9 100644
  --- a/arch/mips/kernel/Makefile
  +++ b/arch/mips/kernel/Makefile
  @@ -2,6 +2,8 @@
   # Makefile for the Linux/MIPS kernel.
   #
   
  +CPPFLAGS_vmlinux.lds := $(KBUILD_CFLAGS)
  +
   extra-y:= head.o init_task.o vmlinux.lds
   
   obj-y  += cpu-probe.o branch.o entry.o genex.o irq.o process.o 
  \
  diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
  index 9bf0e3d..162b299 100644
  --- a/arch/mips/kernel/vmlinux.lds.S
  +++ b/arch/mips/kernel/vmlinux.lds.S
  @@ -11,15 +11,15 @@ PHDRS {
  note PT_NOTE FLAGS(4);  /* R__ */
   }
   
  -ifdef CONFIG_32BIT
  -   ifdef CONFIG_CPU_LITTLE_ENDIAN
  +#ifdef CONFIG_32BIT
  +   #ifdef CONFIG_CPU_LITTLE_ENDIAN
  jiffies  = jiffies_64;
  -   else
  +   #else
  jiffies  = jiffies_64 + 4;
  -   endif
  -else
  +   #endif
  +#else
  jiffies  = jiffies_64;
  -endif
  +#endif
   
   SECTIONS
   {
  
  
  
  -- 
  dann frazier
  
  
 
 -- 
 Aurelien Jarno  GPG: 1024D/F1BCDB73
 aurel...@aurel32.net http://www.aurel32.net

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#552422: linux-2.6 2.6.31-1 FTBFS on mipsel

[Aurelien Jarno]

Martin Michlmayr a écrit :
 * Andreas Barth a...@not.so.argh.org [2009-10-26 07:22]:
 Package: linux-2.6
 Version: 2.6.31-1
 Severity: serious
 
 this package FTBFS on mipsel:
   MODPOST vmlinux.o
   GEN .version
   CHK include/linux/compile.h
   UPD include/linux/compile.h
   CC  init/version.o
   LD  init/built-in.o
   LD  .tmp_vmlinux1
 ld:arch/mips/kernel/vmlinux.lds:168: syntax error
 
 Aurelien, can you take a look at this?

I'll try to have a look, but I don't know when. There are plenty of RC
bugs on eglibc to fix first.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#552422: linux-2.6 2.6.31-1 FTBFS on mipsel

[Aurelien Jarno]

On Mon, Oct 26, 2009 at 12:58:25PM -0600, dann frazier wrote:
 On Mon, Oct 26, 2009 at 11:03:27AM +0100, Aurelien Jarno wrote:
  Martin Michlmayr a écrit :
   * Andreas Barth a...@not.so.argh.org [2009-10-26 07:22]:
   Package: linux-2.6
   Version: 2.6.31-1
   Severity: serious
   
   this package FTBFS on mipsel:
 MODPOST vmlinux.o
 GEN .version
 CHK include/linux/compile.h
 UPD include/linux/compile.h
 CC  init/version.o
 LD  init/built-in.o
 LD  .tmp_vmlinux1
   ld:arch/mips/kernel/vmlinux.lds:168: syntax error
   
   Aurelien, can you take a look at this?
  
  I'll try to have a look, but I don't know when. There are plenty of RC
  bugs on eglibc to fix first.
 
 Could it be this? I don't have hardware to test.

It will most probably fix the problem. I have started a build.

 commit d71789b6fa37c21ce5eb588d279f57904a62e7e2
 Author: Manuel Lauss manuel.la...@gmail.com
 Date:   Thu Sep 24 21:44:24 2009 +0200
 
 mips: fix build of vmlinux.lds
 
 Commit 51b563fc93c8cb5bff1d67a0a71c374e4a4ea049 (arm, cris, mips,
 sparc, powerpc, um, xtensa: fix build with bash 4.0) removed a few
 CPPFLAGS with vital include paths necessary to build vmlinux.lds
 on MIPS, and moved the calculation of the 'jiffies' symbol
 directly to vmlinux.lds.S but forgot to change make ifdef/... to
 cpp macros.
 
 Signed-off-by: Manuel Lauss manuel.la...@gmail.com
 [sam: moved assignment of CPPFLAGS arch/mips/kernel/Makefile]
 Signed-off-by: Sam Ravnborg s...@ravnborg.org
 Acked-by: Dmitri Vorobiev dmitri.vorob...@movial.com
 
 diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
 index e961221..eecd2a9 100644
 --- a/arch/mips/kernel/Makefile
 +++ b/arch/mips/kernel/Makefile
 @@ -2,6 +2,8 @@
  # Makefile for the Linux/MIPS kernel.
  #
  
 +CPPFLAGS_vmlinux.lds := $(KBUILD_CFLAGS)
 +
  extra-y  := head.o init_task.o vmlinux.lds
  
  obj-y+= cpu-probe.o branch.o entry.o genex.o irq.o process.o 
 \
 diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
 index 9bf0e3d..162b299 100644
 --- a/arch/mips/kernel/vmlinux.lds.S
 +++ b/arch/mips/kernel/vmlinux.lds.S
 @@ -11,15 +11,15 @@ PHDRS {
   note PT_NOTE FLAGS(4);  /* R__ */
  }
  
 -ifdef CONFIG_32BIT
 - ifdef CONFIG_CPU_LITTLE_ENDIAN
 +#ifdef CONFIG_32BIT
 + #ifdef CONFIG_CPU_LITTLE_ENDIAN
   jiffies  = jiffies_64;
 - else
 + #else
   jiffies  = jiffies_64 + 4;
 - endif
 -else
 + #endif
 +#else
   jiffies  = jiffies_64;
 -endif
 +#endif
  
  SECTIONS
  {
 
 
 
 -- 
 dann frazier
 
 

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#466977: Bug#404951: sb1-bcm91250a kernel does not boot

[Aurelien Jarno]

Martin Michlmayr a écrit :
 * Moritz Muehlenhoff j...@inutil.org [2009-09-09 21:26]:
 What's the status? Is is still broken?
 
 2.6.30 in unstable should work fine now.  Aurelien, can you confirm?
 

It doesn't work. There are some changes needed to make it working:
- There are missing patches in Linus' tree, linux-mips.org tree should
be used instead.
- The IDE controller is replaced with the PATA controller which changes
the name of the drive.
- A patch is needed to make the IDE controller working wrt to CPU caches.

In short it's not very easy to get it working within the debian package.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532562: linux-image-2.6.26-2-versatile: Kernel panics randomly while using apt-get

[Aurelien Jarno]

 e59f06fc ea2f (e5963358)
 [0.00] Kernel panic - not syncing: Fatal exception in interrupt

 
 Qemu also outputs this on the terminal:
 lsi_scsi: error: Reselect with pending DMA

This looks like the disk emulation is not fast enough for the kernel.
Which kind of hard drive are you using (2.5 or 3.5)? On which kind of
partition are the images? Encrypted one?

In that case you can try to run qemu with -drive
file=your_image,cache=writeback instead of -hda. You will lose on the
data integrity side in case of crash of the host, but you will get a
higher throughput.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#404951: linux-2.6: sb1-bcm91250a kernel does not boot

[Aurelien Jarno]

On Fri, Dec 29, 2006 at 04:26:27PM +0100, Karsten Merker wrote:
 Package: installation-reports
 Severity: grave
 
 Boot method: netboot
 Image version: daily build 2006-12-27,
 http://people.debian.org/~ths/d-i/mips/images/daily/sb1-bcm91250a/netboot/
 
 Date: 2006-12-29
 
 Machine: Broadcom BCM91250a SWARM, mips/big-endian mode,
  256MB RAM, serial console, IDE disk
 
 Base System Installation Checklist:
 [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
 
 Initial boot:   [E]
 Detect network card:[ ]
 Configure network:  [ ]
 Detect CD:  [ ]
 Load installer modules: [ ]
 Detect hard drives: [ ]
 Partition hard drives:  [ ]
 Install base system:[ ]
 Clock/timezone setup:   [ ]
 User/password setup:[ ]
 Install tasks:  [ ]
 Install boot loader:[ ]
 Overall install:[ ]
 
 
 Comments/Problems:
 ==
 
 Sibyl (the bootloader) starts, loads the kernel and the initrd,
 jumps into the kernel and the system freezes.
 
 
 Boot log:
 =
 
 CFE boot -tftp 192.168.2.14:/tftpboot/swarm-daily/sibyl
 Loader:raw Filesys:tftp Dev:eth0
 File:192.168.2.14:/tftpboot/swarm-daily/sibyl Options:(null)
 Loading: ... 130116 bytes read
 Entry at 0x2000
 Closing network.
 Starting program at 0x2000
 SiByte Loader, version 2.4.2
 Built on Oct  4 2005
 Network device 'eth0' configured
 Getting configuration file
 tftp:192.168.2.14:/tftpboot/swarm-daily/sibyl.conf...
 Config file retrieved.
 Available configurations:
   install
   rescue
 Boot which configuration [install]:
 Loading kernel (ELF64):
 4391...@0x8010
 done
 Loading ramdisk at 0x8057e000...3622876 bytes loaded
 Set up command line arguments to: root=/dev/ram console=duart0
  ^^

The problem partially comes from here. Starting with version 2.6.18-4,
the console name has been changed to ttyS0, as shown in the changelog
entry below:

|- bugfix/mips/sb1-duart-tts.patch, replaces mips-sb1-duart-tts.patch,
|  use standard Linux names for SB-1 consoles.


-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532562: linux-image-2.6.26-2-versatile: Kernel panics randomly while using apt-get

[Aurelien Jarno]

On Mon, Jun 15, 2009 at 07:55:16PM -0300, Axel Allende Lira wrote:


 Aurelien Jarno wrote:
 This looks like the disk emulation is not fast enough for the kernel.
 Which kind of hard drive are you using (2.5 or 3.5)? On which kind of
 partition are the images? Encrypted one?

 3,5 SataI, non-encrypted (I guess...) ext3.

 In that case you can try to run qemu with -drive
 file=your_image,cache=writeback instead of -hda. You will lose on the
 data integrity side in case of crash of the host, but you will get a
 higher throughput.

 Running qemu with that option didn't help...
 In htat case, should I - or whoever - file a bug report against qemu?


If you are using the package from Debian yes. It contains numerous
patches, and I am personally unable to reproduce the problem you
describe.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532562: linux-image-2.6.26-2-versatile: Kernel panics randomly while using apt-get

[Aurelien Jarno]

On Wed, Jun 10, 2009 at 02:52:14PM +0200, Martin Michlmayr wrote:
 Aurelien, can you take a look at this bug report?
 
 * Axel Allende Lira axell...@gmail.com [2009-06-10 04:14]:
  bootstrap inside loop mounted hd image, and then booting it with a third  
  party
  kernel. I installed linux-image-2.6.26-2-versatile after the  
  bootstrapping was
  complete so I could have the cdrom and mouse drivers. The problem is:  

Does it means that version 2.6.26-1-versatile works correctly?

  when ins-
  talling anything using apt-get, the kernel will panic after downloading  
  the fi-
  les, at configuration time. This caused corruption of many files in  
  /var/lib/
  dpkg, making dpkg unusable. I solved this issue by rebuilding the system  
  on an
  ext3 partition. Even though, the problem is still there. The last lines  
  of the
  panic output are as follow (sorry, couldn`t get anything prior to that,  
  since I
  can't scroll up and all...):

The trace is to incomplete to be useful.

You should try to boot the system on the serial port to catch more
messages. You should add console=ttyAMA0 to the kernel arguments, and
add -nographic to the QEMU arguments.

  [   0.00] [bf000480] (scsi_finish_command+0x0/0xcc [scsi_mod]) from 
  [bf0
  07808] (scsi_softirq_done+0x10c/0x128 [scsi_mod])
  [   0.00]  r6:cec694c0 r5:0005 r4:0bb8
  [   0.00] [bf0076fc] (scsi_softirq_done+0x0/0x128 [scsi_mod]) from  
  [c010
  bafc] (blk_done_softirq+0x78/0x9c)
  [   0.00] [c010ba84] (blk_done_softirq+0x0/0xd4) from [c0047680]  
  (__do_
  softirq+0x60/0xd4)
  [   0.00] [c0047284] (__do_softirq+0x0/0xd4) from [c0047680]  
  (irq_exit+
  0x44/0x4c)
  [   0.00]  r6: r5:c0289f78 r4:001b
  [   0.00] [c004763c] (irq_exit+0x0/0x4c) from [c002404c]  
  (__exception_t
  ext_start+0x4c/0x64)
  [   0.00] [c0024000] (__exception_text_start+0x0/0x64) from  
  [c00248a4]
  (__irq_usr+0x44/0xa0)
  [   0.00] Exception stack(0xcf561fb0 to 0xcf561ff8)
  [   0.00] 1fa0   0008 
  0
  02e 0035
  [   0.00] 1fc0: beeb3362 0005781d 0001 0016 00059f70 beeb336d 
  00059
  a40 0005aa18
  [   0.00] ife0: 0006ffd6 beeb27d0 00023890 00024968 6010 
 
  [   0.00]  r6:001 r5:f114 r4:
  [   0.00] Code: e1a01000 e5932000 e59f06fc ea2f (e5963358)
  [   0.00] Kernel panic - not syncing: Fatal exception in interrupt
 
  In order to get this, I ran the system with:
  qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.26-2-versatile -initrd
  initrd.img-2.6.26-2-versatile [1] -hda hda.img -hdb swap.img [2] -cdrom
  debian-501-armel-DVD-1.iso [3] -m 256M -append root=/dev/sda rw mem=256M
 

Installing the system directly on the emulated hard-drive without any
partitions looks strange. I doubt it will make any change, but it may
worth trying an installation using partitions.

What worries me more is the mem=256M argument. Why have you adding it
here? Could you try without it?

Also which version of QEMU are you using?

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532562: linux-image-2.6.26-2-versatile: Kernel panics randomly while using apt-get

[Aurelien Jarno]

On Wed, Jun 10, 2009 at 01:55:21PM -0300, Axel Allende Lira wrote:


 Aurelien Jarno escreveu:
 On Wed, Jun 10, 2009 at 02:52:14PM +0200, Martin Michlmayr wrote:
 Aurelien, can you take a look at this bug report?

 * Axel Allende Lira axell...@gmail.com [2009-06-10 04:14]:
 bootstrap inside loop mounted hd image, and then booting it with a 
 third  party
 kernel. I installed linux-image-2.6.26-2-versatile after the   
 bootstrapping was
 complete so I could have the cdrom and mouse drivers. The problem 
 is:  

 Does it means that version 2.6.26-1-versatile works correctly?

 I didn't try 2.6.26-1-versatile. Revision 2 was already out when I started.

Ok, so then I guess you use another kernel before? Was it working
correctly?

 when ins-
 talling anything using apt-get, the kernel will panic after 
 downloading  the fi-
 les, at configuration time. This caused corruption of many files in 
  /var/lib/
 dpkg, making dpkg unusable. I solved this issue by rebuilding the 
 system  on an
 ext3 partition. Even though, the problem is still there. The last 
 lines  of the
 panic output are as follow (sorry, couldn`t get anything prior to 
 that,  since I
 can't scroll up and all...):

 The trace is to incomplete to be useful.

 You should try to boot the system on the serial port to catch more
 messages. You should add console=ttyAMA0 to the kernel arguments, and
 add -nographic to the QEMU arguments.

 [   0.00] [bf000480] (scsi_finish_command+0x0/0xcc 
 [scsi_mod]) from [bf0
 07808] (scsi_softirq_done+0x10c/0x128 [scsi_mod])
 [   0.00]  r6:cec694c0 r5:0005 r4:0bb8
 [   0.00] [bf0076fc] (scsi_softirq_done+0x0/0x128 [scsi_mod]) 
 from  [c010
 bafc] (blk_done_softirq+0x78/0x9c)
 [   0.00] [c010ba84] (blk_done_softirq+0x0/0xd4) from 
 [c0047680]  (__do_
 softirq+0x60/0xd4)
 [   0.00] [c0047284] (__do_softirq+0x0/0xd4) from 
 [c0047680]  (irq_exit+
 0x44/0x4c)
 [   0.00]  r6: r5:c0289f78 r4:001b
 [   0.00] [c004763c] (irq_exit+0x0/0x4c) from [c002404c]   
 (__exception_t
 ext_start+0x4c/0x64)
 [   0.00] [c0024000] (__exception_text_start+0x0/0x64) from   
 [c00248a4]
 (__irq_usr+0x44/0xa0)
 [   0.00] Exception stack(0xcf561fb0 to 0xcf561ff8)
 [   0.00] 1fa0   
 0008 0
 02e 0035
 [   0.00] 1fc0: beeb3362 0005781d 0001 0016 00059f70 
 beeb336d 00059
 a40 0005aa18
 [   0.00] ife0: 0006ffd6 beeb27d0 00023890 00024968 6010 

 [   0.00]  r6:001 r5:f114 r4:
 [   0.00] Code: e1a01000 e5932000 e59f06fc ea2f (e5963358)
 [   0.00] Kernel panic - not syncing: Fatal exception in interrupt

 In order to get this, I ran the system with:
 qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.26-2-versatile -initrd
 initrd.img-2.6.26-2-versatile [1] -hda hda.img -hdb swap.img [2] -cdrom
 debian-501-armel-DVD-1.iso [3] -m 256M -append root=/dev/sda rw mem=256M


 Installing the system directly on the emulated hard-drive without any
 partitions looks strange. I doubt it will make any change, but it may
 worth trying an installation using partitions.

 I DO use a partition. As I said, the system is on an ext3 partition, and  
 there's a complementar swap image. I made them using mke2fs -j on  
 hda.img, and mkswap on swap.img.

If you are using partitions, then you should specify a different root
to the kernel, probably root=/dev/sda1.

 What worries me more is the mem=256M argument. Why have you adding it
 here? Could you try without it?

 I'm using this emulated hardware as a test bed for making a rootfs for  
 my pda. I'm testing graphical applications, so I thought it would be  
 useful to have more memory. I tried without it, and got the same result.

Yes, you should pass the value to qemu with the -m argument. The kernel
should autodetect the right value, which might be a few kB/MB smaller
than the one you specifiy. There is no need to force a memory size with
a mem= argument.

 Also which version of QEMU are you using?

 0.10.3, compiled from source.


Which file format are you using for the images? You should clearly not
use qcow2 with this version of QEMU. And it is strongly recommended to
upgrade to 0.10.5 even if you are not using the qcow2 format.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532562: linux-image-2.6.26-2-versatile: Kernel panics randomly while using apt-get

[Aurelien Jarno]

On Wed, Jun 10, 2009 at 04:07:36PM -0300, Axel Allende Lira wrote:

 If you are using partitions, then you should specify a different root
 to the kernel, probably root=/dev/sda1.

 For some reason, the partition number isn't shown in the emulated /dev  
 folder. Just /dev/sda for the rootfs and /dev/sdb for the swap. Go 
 figure...

Because you do not use a partition table...

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

reassign 523121 to linux-libc-dev

[Aurelien Jarno]

reassign 523121 linux-libc-dev 


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524586: linux-2.6_2.6.29-3(mips/unstable): FTBFS on mips. Patch fails.

[Aurelien Jarno]

reassign 524586 buildd.debian.org
reassign 524589 buildd.debian.org
forcemerge 524586 524589
retitle 524586 mayr's kernel should be upgraded
thanks

On Sat, Apr 18, 2009 at 12:09:57PM +0200, Martin Michlmayr wrote:
 * Peter De Schrijver p...@debian.org [2009-04-18 12:45]:
 File 
   /build/buildd/linux-2.6-2.6.29/debian/lib/python/debian_linux/patches.py,
line 44, in patch_push
   self._call(dir, '--fuzz=1')
 File 
   /build/buildd/linux-2.6-2.6.29/debian/lib/python/debian_linux/patches.py,
line 38, in _call
   f = os.popen(cmdline, 'wb')
   OSError: [Errno -89] Unknown error 4294967207
   make[2]: *** [debian/stamps/source] Error 1
 
 That looks more like an error with the build machine; another FTBFS
 you just filed (#524589) has the same problem.
 

As discussed on #debian-buildd, this is a known kernel problem, see bug
#520034. Installing a more recent kernel should fix the problem.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org