From mmarek@suse.com Tue Apr 4 09:21:03 2017 From: Michal Marek To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] kernel repository over rsync not updated Date: Tue, 04 Apr 2017 11:21:02 +0200 Message-ID: <5d4c40d4-b7b2-762f-5556-d7c1303e7d6f@suse.com> In-Reply-To: <20170320154756.GA11520@monopoli.naic.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0547313493782694499==" --===============0547313493782694499== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2017-03-20 16:47, Giacomo Comes wrote: > I'm not sure were to report this issue, so i'm doing it here. > Please forward it to the appropriate place. >=20 > If I run: > wget -q -O - http://download.opensuse.org/repositories/Kernel:/HEAD/stand= ard/noarch/ | grep kernel-source-4 > I get: > 3D"[ kernel-source-4.11.rc2-2.1.g01218d4.noarch.rpm= 17-Mar-2017 08:55 91M Details >=20 > which is ok. But if I run: > rsync rsync.opensuse.org::buildservice-repos-main/Kernel:/HEAD/standard/n= oarch/ | grep kernel-source-4 > I get: > -rw-r--r-- 93971273 2017/02/21 04:01:01 kernel-source-4.10.0-1.1.g12a7= a6d.noarch.rpm >=20 > The kernel (and also kernel-stable) repository accessible with rsync is not= getting updated. I can confirm this, but this is unlikely related to the kernel packages. I suggest to contact the address given in the rsync motd: -----8<----- This is rsync.opensuse.org, public rsync server of openSUSE.org, limited to 50 connections. If you run a public mirror, please get in contact so we can give you access to the stage rsync server. You'll find conditions for access and further information at http://en.opensuse.org/Mirror_Infrastructure Thanks! admin(a)opensuse.org ----->8----- Michal --=20 To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============0547313493782694499==-- From bruno@ioda-net.ch Tue Apr 4 13:33:03 2017 From: Bruno Friedmann To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] kernel repository over rsync not updated Date: Tue, 04 Apr 2017 15:33:00 +0200 Message-ID: <2700283.nhCni2p49P@qt-kt.labaroche.ioda.net> In-Reply-To: <5d4c40d4-b7b2-762f-5556-d7c1303e7d6f@suse.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1404366066094403661==" --===============1404366066094403661== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On mardi, 4 avril 2017 11.21:02 h CEST Michal Marek wrote: > On 2017-03-20 16:47, Giacomo Comes wrote: > > I'm not sure were to report this issue, so i'm doing it here. > > Please forward it to the appropriate place. > > > > If I run: > > wget -q -O - > > http://download.opensuse.org/repositories/Kernel:/HEAD/standard/noarch/ > > | grep kernel-source-4> > > I get: > > [ ] > href="kernel-source-4.11.rc2-2.1.g01218d4.noarch.rpm">kernel-source-4.1 > > 1.rc2-2.1.g01218d4.noarch.rpm 17-Mar-2017 08:55 91M > href="kernel-source-4.11.rc2-2.1.g01218d4.noarch.rpm.mirrorlist">Detail > > s> > > which is ok. But if I run: > > rsync > > rsync.opensuse.org::buildservice-repos-main/Kernel:/HEAD/standard/noarc > > h/ | grep kernel-source-4> > > I get: > > -rw-r--r-- 93971273 2017/02/21 04:01:01 > > kernel-source-4.10.0-1.1.g12a7a6d.noarch.rpm> > > The kernel (and also kernel-stable) repository accessible with rsync is > > not getting updated. > I can confirm this, but this is unlikely related to the kernel packages. > I suggest to contact the address given in the rsync motd: > > -----8<----- > This is rsync.opensuse.org, public rsync server of openSUSE.org, > limited to 50 connections. > > If you run a public mirror, please get in contact so we can give you > access to the stage rsync server. > You'll find conditions for access and further information at > http://en.opensuse.org/Mirror_Infrastructure > > Thanks! > admin(a)opensuse.org > ----->8----- > > Michal Giacomo, you can also check in the wiki mirror list, a number of them also propose rsync, and most of the time they are up to date quick quickly. Unfortunately there's no mirrorbrain equivalent for rsync server ;-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============1404366066094403661==-- From pgnet.dev@gmail.com Tue Apr 4 13:34:46 2017 From: PGNet Dev To: kernel@lists.opensuse.org Subject: [opensuse-kernel] 4.10.8 OOPS - BUG: unable to handle kernel NULL pointer dereference; IP: _raw_spin_lock+0x13/0x30 Date: Tue, 04 Apr 2017 06:34:40 -0700 Message-ID: <41cadb4c-ae1d-e8d0-df3e-168400f25f08@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7997960963257325332==" --===============7997960963257325332== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit For now, just an fyi to upstream-reported bug Bug 195229 - 4.10.8 OOPS - BUG: unable to handle kernel NULL pointer dereference; IP: _raw_spin_lock+0x13/0x30 https://bugzilla.kernel.org/show_bug.cgi?id=195229 as it *is* an Opensuse repo kernel ... noone's bounced it back here yet, but wouldn't be the first time. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============7997960963257325332==-- From 6gtm2egnbd@snkmail.com Thu Apr 6 07:02:51 2017 From: Uwe Geuder <6gtm2egnbd@snkmail.com> To: kernel@lists.opensuse.org Subject: [opensuse-kernel] Any complaints about 4.4.57-18.3-default stability? Date: Wed, 05 Apr 2017 23:58:19 +0300 Message-ID: <87mvbutvv8.fsf@linux.suse> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8039692070105269934==" --===============8039692070105269934== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi! On my OpenSUSE 42.2 I updated the kernel on Monday Linux linux.suse 4.4.57-18.3-default #1 SMP Thu Mar 30 06:39:47 UTC 2017 (39= c8557) x86_64 x86_64 x86_64 GNU/Linux On Tuesday after ~5 hours light interactive usage the machine hung with all L= EDs blinking. Some machine check? On Wednesday ~10 usage hours and 1 suspend to disk later I got an xfs internal error (during some heavy file operations). Apr 04 11:17:32 linux kernel: Linux version 4.4.57-18.3-default (geeko(a)buil= dhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Thu Mar 30 06:39:47 UTC 2017 = (39c8557) ... Apr 05 16:42:10 linux.suse nm-dispatcher[11697]: Dispatching action 'dhcp4-ch= ange' for eth0 Apr 05 16:42:30 linux.suse kernel: XFS (dm-4): Internal error XFS_WANT_CORRUP= TED_GOTO at line 3156 of file ../fs/xfs/libxfs/xfs_btree.c. Caller xfs_free_= ag_extent+0x3ce/0x820 [xfs] Apr 05 16:42:30 linux.suse kernel: CPU: 2 PID: 11736 Comm: git Tainted: G = O 4.4.57-18.3-default #1 Apr 05 16:42:30 linux.suse kernel: Hardware name: Dell Inc. Latitude E6510/0N= 5KHN, BIOS A16 12/05/2013 Apr 05 16:42:30 linux.suse kernel: 0000000000000000 ffffffff81328787 ffff880= 0bb8ceb78 ffff8800c932bc60 Apr 05 16:42:30 linux.suse kernel: ffffffffa0ad4bcc ffff8800c930d000 0000000= 0cb19a540 00000000ffffffff Apr 05 16:42:30 linux.suse kernel: 0000000000000000 0400000000c32000 ffff880= 108319400 ffffffffa0abb3e6 Apr 05 16:42:30 linux.suse kernel: Call Trace: Apr 05 16:42:30 linux.suse kernel: [] dump_trace+0x59/0x320 Apr 05 16:42:30 linux.suse kernel: [] show_stack_log_lvl+0= xfa/0x180 Apr 05 16:42:30 linux.suse kernel: [] show_stack+0x21/0x40 Apr 05 16:42:30 linux.suse kernel: [] dump_stack+0x5c/0x85 Apr 05 16:42:30 linux.suse kernel: [] xfs_btree_insert+0x1= 7c/0x190 [xfs] Apr 05 16:42:30 linux.suse kernel: [] xfs_free_ag_extent+0= x3ce/0x820 [xfs] Apr 05 16:42:30 linux.suse kernel: [] xfs_free_extent+0xd1= /0x100 [xfs] Apr 05 16:42:30 linux.suse kernel: [] xfs_trans_free_exten= t+0x21/0x50 [xfs] Apr 05 16:42:30 linux.suse kernel: [] xfs_bmap_finish+0xf8= /0x120 [xfs] Apr 05 16:42:30 linux.suse kernel: [] xfs_itruncate_extent= s+0x11a/0x260 [xfs] Apr 05 16:42:30 linux.suse kernel: [] xfs_inactive_truncat= e+0x81/0xe0 [xfs] Apr 05 16:42:30 linux.suse kernel: [] xfs_inactive+0x13f/0= x160 [xfs] Apr 05 16:42:30 linux.suse kernel: [] evict+0xc1/0x1a0 Apr 05 16:42:30 linux.suse kernel: [] do_unlinkat+0x18f/0x= 2b0 Apr 05 16:42:30 linux.suse kernel: [] entry_SYSCALL_64_fas= tpath+0x16/0x71 Apr 05 16:42:30 linux.suse kernel: DWARF2 unwinder stuck at entry_SYSCALL_64_= fastpath+0x16/0x71 Apr 05 16:42:30 linux.suse kernel:=20 Apr 05 16:42:30 linux.suse kernel: Leftover inexact backtrace: Apr 05 16:42:30 linux.suse kernel: XFS (dm-4): Internal error xfs_trans_cance= l at line 990 of file ../fs/xfs/xfs_trans.c. Caller xfs_inactive_truncate+0x= b1/0xe0 [xfs] Apr 05 16:42:31 linux.suse kernel: CPU: 2 PID: 11736 Comm: git Tainted: G = O 4.4.57-18.3-default #1 Apr 05 16:42:31 linux.suse kernel: Hardware name: Dell Inc. Latitude E6510/0N= 5KHN, BIOS A16 12/05/2013 Apr 05 16:42:31 linux.suse kernel: 0000000000000000 ffffffff81328787 ffff880= 0bf6ec880 0000000000000001 Apr 05 16:42:31 linux.suse kernel: ffffffffa0b15ced Apr 05 16:42:31 linux.suse kernel: ffff880025ae3400 00000000ffffff8b fffffff= fa0b36640 Apr 05 16:42:31 linux.suse kernel: ffffffffa0b0b2b1 ffff8800bf6ec880 ffff880= 025ae3400 0000000000000001 Apr 05 16:42:31 linux.suse kernel: Call Trace: Apr 05 16:42:31 linux.suse kernel: [] dump_trace+0x59/0x320 Apr 05 16:42:31 linux.suse kernel: [] show_stack_log_lvl+0= xfa/0x180 Apr 05 16:42:31 linux.suse kernel: [] show_stack+0x21/0x40 Apr 05 16:42:31 linux.suse kernel: [] dump_stack+0x5c/0x85 Apr 05 16:42:31 linux.suse kernel: [] xfs_trans_cancel+0xa= d/0xd0 [xfs] Apr 05 16:42:31 linux.suse kernel: [] xfs_inactive_truncat= e+0xb1/0xe0 [xfs] Apr 05 16:42:31 linux.suse kernel: [] xfs_inactive+0x13f/0= x160 [xfs] Apr 05 16:42:31 linux.suse kernel: [] evict+0xc1/0x1a0 Apr 05 16:42:31 linux.suse kernel: [] do_unlinkat+0x18f/0x= 2b0 Apr 05 16:42:31 linux.suse kernel: [] entry_SYSCALL_64_fas= tpath+0x16/0x71 Apr 05 16:42:31 linux.suse kernel: DWARF2 unwinder stuck at entry_SYSCALL_64_= fastpath+0x16/0x71 Apr 05 16:42:31 linux.suse kernel:=20 Apr 05 16:42:31 linux.suse kernel: Leftover inexact backtrace: Apr 05 16:42:31 linux.suse kernel: XFS (dm-4): xfs_do_force_shutdown(0x8) cal= led from line 991 of file ../fs/xfs/xfs_trans.c. Return address =3D 0xffffff= ffa0b15d06 Apr 05 16:42:31 linux.suse kernel: XFS (dm-4): Corruption of in-memory data d= etected. Shutting down filesystem Apr 05 16:42:31 linux.suse kernel: XFS (dm-4): Please umount the filesystem a= nd rectify the problem(s) Apr 05 16:42:33 linux.suse kernel: XFS (dm-4): xfs_log_force: error -5 return= ed. Apr 05 16:43:03 linux.suse kernel: XFS (dm-4): xfs_log_force: error -5 return= ed. Apr 05 16:43:33 linux.suse kernel: XFS (dm-4): xfs_log_force: error -5 return= ed. Apr 05 16:44:03 linux.suse kernel: XFS (dm-4): xfs_log_force: error -5 return= ed. Apr 05 16:44:34 linux.suse kernel: XFS (dm-4): xfs_log_force: error -5 return= ed. (xfs_repair with dropping logs was required to recover) There is 1 xfs change in the changelog. No idea whether it even theoretically could cause this problem. But I guess many kinds of memory corruption caused by any other change could also cause an XFS corruption. Yes, the machine is old and it might break some day. S.M.A.R.T selftest passes, haven't had time to run memtest yet. However, that the problems occured just hours after a kernel update makes me a bit suspicious. Earlier I had ~1 crash per year on this machine. Any other observations of instability with the new kernel? (No answer also is an answer in this case.) Regards, Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gXuder(a)nomovok.com (bot check: correct 1 obvious spelling error) --=20 To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============8039692070105269934==-- From jack@suse.cz Thu Apr 6 11:43:11 2017 From: Jan Kara To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] Any complaints about 4.4.57-18.3-default stability? Date: Thu, 06 Apr 2017 13:43:07 +0200 Message-ID: <20170406114307.GA8963@quack2.suse.cz> In-Reply-To: <87mvbutvv8.fsf@linux.suse> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8833605288309753862==" --===============8833605288309753862== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, On Wed 05-04-17 23:58:19, Uwe Geuder wrote: > On my OpenSUSE 42.2 I updated the kernel on Monday >=20 > Linux linux.suse 4.4.57-18.3-default #1 SMP Thu Mar 30 06:39:47 UTC 2017 (= 39c8557) x86_64 x86_64 x86_64 GNU/Linux >=20 > On Tuesday after ~5 hours light interactive usage the machine hung with > all LEDs blinking. Some machine check? May be just hard kernel panic... But without more info it is impossible to debug. > On Wednesday ~10 usage hours and 1 suspend to disk later I got an xfs > internal error (during some heavy file operations). Please file a bug for this. Thanks! Honza =20 > Apr 04 11:17:32 linux kernel: Linux version 4.4.57-18.3-default (geeko(a)bu= ildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Thu Mar 30 06:39:47 UTC 201= 7 (39c8557) > ... > Apr 05 16:42:10 linux.suse nm-dispatcher[11697]: Dispatching action 'dhcp4-= change' for eth0 > Apr 05 16:42:30 linux.suse kernel: XFS (dm-4): Internal error XFS_WANT_CORR= UPTED_GOTO at line 3156 of file ../fs/xfs/libxfs/xfs_btree.c. Caller xfs_fre= e_ag_extent+0x3ce/0x820 [xfs] > Apr 05 16:42:30 linux.suse kernel: CPU: 2 PID: 11736 Comm: git Tainted: G = O 4.4.57-18.3-default #1 > Apr 05 16:42:30 linux.suse kernel: Hardware name: Dell Inc. Latitude E6510/= 0N5KHN, BIOS A16 12/05/2013 > Apr 05 16:42:30 linux.suse kernel: 0000000000000000 ffffffff81328787 ffff8= 800bb8ceb78 ffff8800c932bc60 > Apr 05 16:42:30 linux.suse kernel: ffffffffa0ad4bcc ffff8800c930d000 00000= 000cb19a540 00000000ffffffff > Apr 05 16:42:30 linux.suse kernel: 0000000000000000 0400000000c32000 ffff8= 80108319400 ffffffffa0abb3e6 > Apr 05 16:42:30 linux.suse kernel: Call Trace: > Apr 05 16:42:30 linux.suse kernel: [] dump_trace+0x59/0x= 320 > Apr 05 16:42:30 linux.suse kernel: [] show_stack_log_lvl= +0xfa/0x180 > Apr 05 16:42:30 linux.suse kernel: [] show_stack+0x21/0x= 40 > Apr 05 16:42:30 linux.suse kernel: [] dump_stack+0x5c/0x= 85 > Apr 05 16:42:30 linux.suse kernel: [] xfs_btree_insert+0= x17c/0x190 [xfs] > Apr 05 16:42:30 linux.suse kernel: [] xfs_free_ag_extent= +0x3ce/0x820 [xfs] > Apr 05 16:42:30 linux.suse kernel: [] xfs_free_extent+0x= d1/0x100 [xfs] > Apr 05 16:42:30 linux.suse kernel: [] xfs_trans_free_ext= ent+0x21/0x50 [xfs] > Apr 05 16:42:30 linux.suse kernel: [] xfs_bmap_finish+0x= f8/0x120 [xfs] > Apr 05 16:42:30 linux.suse kernel: [] xfs_itruncate_exte= nts+0x11a/0x260 [xfs] > Apr 05 16:42:30 linux.suse kernel: [] xfs_inactive_trunc= ate+0x81/0xe0 [xfs] > Apr 05 16:42:30 linux.suse kernel: [] xfs_inactive+0x13f= /0x160 [xfs] > Apr 05 16:42:30 linux.suse kernel: [] evict+0xc1/0x1a0 > Apr 05 16:42:30 linux.suse kernel: [] do_unlinkat+0x18f/= 0x2b0 > Apr 05 16:42:30 linux.suse kernel: [] entry_SYSCALL_64_f= astpath+0x16/0x71 > Apr 05 16:42:30 linux.suse kernel: DWARF2 unwinder stuck at entry_SYSCALL_6= 4_fastpath+0x16/0x71 > Apr 05 16:42:30 linux.suse kernel:=20 > Apr 05 16:42:30 linux.suse kernel: Leftover inexact backtrace: > Apr 05 16:42:30 linux.suse kernel: XFS (dm-4): Internal error xfs_trans_can= cel at line 990 of file ../fs/xfs/xfs_trans.c. Caller xfs_inactive_truncate+= 0xb1/0xe0 [xfs] > Apr 05 16:42:31 linux.suse kernel: CPU: 2 PID: 11736 Comm: git Tainted: G = O 4.4.57-18.3-default #1 > Apr 05 16:42:31 linux.suse kernel: Hardware name: Dell Inc. Latitude E6510/= 0N5KHN, BIOS A16 12/05/2013 > Apr 05 16:42:31 linux.suse kernel: 0000000000000000 ffffffff81328787 ffff8= 800bf6ec880 0000000000000001 > Apr 05 16:42:31 linux.suse kernel: ffffffffa0b15ced > Apr 05 16:42:31 linux.suse kernel: ffff880025ae3400 00000000ffffff8b fffff= fffa0b36640 > Apr 05 16:42:31 linux.suse kernel: ffffffffa0b0b2b1 ffff8800bf6ec880 ffff8= 80025ae3400 0000000000000001 > Apr 05 16:42:31 linux.suse kernel: Call Trace: > Apr 05 16:42:31 linux.suse kernel: [] dump_trace+0x59/0x= 320 > Apr 05 16:42:31 linux.suse kernel: [] show_stack_log_lvl= +0xfa/0x180 > Apr 05 16:42:31 linux.suse kernel: [] show_stack+0x21/0x= 40 > Apr 05 16:42:31 linux.suse kernel: [] dump_stack+0x5c/0x= 85 > Apr 05 16:42:31 linux.suse kernel: [] xfs_trans_cancel+0= xad/0xd0 [xfs] > Apr 05 16:42:31 linux.suse kernel: [] xfs_inactive_trunc= ate+0xb1/0xe0 [xfs] > Apr 05 16:42:31 linux.suse kernel: [] xfs_inactive+0x13f= /0x160 [xfs] > Apr 05 16:42:31 linux.suse kernel: [] evict+0xc1/0x1a0 > Apr 05 16:42:31 linux.suse kernel: [] do_unlinkat+0x18f/= 0x2b0 > Apr 05 16:42:31 linux.suse kernel: [] entry_SYSCALL_64_f= astpath+0x16/0x71 > Apr 05 16:42:31 linux.suse kernel: DWARF2 unwinder stuck at entry_SYSCALL_6= 4_fastpath+0x16/0x71 > Apr 05 16:42:31 linux.suse kernel:=20 > Apr 05 16:42:31 linux.suse kernel: Leftover inexact backtrace: > Apr 05 16:42:31 linux.suse kernel: XFS (dm-4): xfs_do_force_shutdown(0x8) c= alled from line 991 of file ../fs/xfs/xfs_trans.c. Return address =3D 0xffff= ffffa0b15d06 > Apr 05 16:42:31 linux.suse kernel: XFS (dm-4): Corruption of in-memory data= detected. Shutting down filesystem > Apr 05 16:42:31 linux.suse kernel: XFS (dm-4): Please umount the filesystem= and rectify the problem(s) > Apr 05 16:42:33 linux.suse kernel: XFS (dm-4): xfs_log_force: error -5 retu= rned. > Apr 05 16:43:03 linux.suse kernel: XFS (dm-4): xfs_log_force: error -5 retu= rned. > Apr 05 16:43:33 linux.suse kernel: XFS (dm-4): xfs_log_force: error -5 retu= rned. > Apr 05 16:44:03 linux.suse kernel: XFS (dm-4): xfs_log_force: error -5 retu= rned. > Apr 05 16:44:34 linux.suse kernel: XFS (dm-4): xfs_log_force: error -5 retu= rned. >=20 > (xfs_repair with dropping logs was required to recover) >=20 > There is 1 xfs change in the changelog. No idea whether it even > theoretically could cause this problem. But I guess many kinds of memory > corruption caused by any other change could also cause an XFS corruption. >=20 > Yes, the machine is old and it might break some day. S.M.A.R.T selftest > passes, haven't had time to run memtest yet. >=20 > However, that the problems occured just hours after a kernel update > makes me a bit suspicious. Earlier I had ~1 crash per year on this > machine. Any other observations of instability with the new kernel? (No > answer also is an answer in this case.) >=20 > Regards, >=20 > Uwe Geuder > Nomovok Ltd. > Tampere, Finland > uwe.gXuder(a)nomovok.com (bot check: correct 1 obvious spelling error) > --=20 > To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org >=20 --=20 Jan Kara SUSE Labs, CR --=20 To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============8833605288309753862==-- From suse@tlinx.org Thu Apr 6 22:18:52 2017 From: L A Walsh To: kernel@lists.opensuse.org Subject: [opensuse-kernel] Re: Any complaints about 4.4.57-18.3-default stability? Date: Thu, 06 Apr 2017 15:18:45 -0700 Message-ID: <58E6BEC5.8010600@tlinx.org> In-Reply-To: <87mvbutvv8.fsf@linux.suse> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3042143807023678503==" --===============3042143807023678503== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Someone else posted problems on the opensuse list about the new crc option, a few days ago on Leap 42.2, but they didn't give enough detail to tell if it was the same bug. -linda -------- Original Message -------- Subject: XFS and CRC on Leap 42.2 Date: Sun, 2 Apr 2017 15:56:05 -0400 From: Ciro Iriarte To: OpenSuse List Hi!, can anyone comment on XFS stability on Leap 42.2 using crc=1?. I've read that crc=1 should be the new default. I created a XFS filesystem with explicit crc=1. Everything was working fine until I used that filesystem as a NFS repository for ESXi, tried to move some VMs to it and had a complete hang, hours later the filesystem went to read only mode. Trying to repair the FS I get CRC errors on the pending changelog. I can purge the log, as the entries reference the directories of the VMs I tried to move but I'm a little worried about keeping it like that. I've just moved from BTRFS trying to avoid this issues :/ Regards, -- Ciro Iriarte http://iriarte.it -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============3042143807023678503==-- From stefan.bruens@rwth-aachen.de Fri Apr 7 01:05:46 2017 From: Stefan =?utf-8?q?Br=C3=BCns?= To: kernel@lists.opensuse.org Subject: [opensuse-kernel] [PATCH] config: armv7hl/arm64: Enable TI INA2xx current/voltage sensors Date: Fri, 07 Apr 2017 03:05:25 +0200 Message-ID: <9ac4a543af67449193ba281f4206c844@rwthex-w2-b.rwth-ad.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6394626473355028879==" --===============6394626473355028879== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Signed-off-by: Stefan Brüns --- The I2C connected TI INA219 can be found on a lot of small breakout boards, e.g. from Adafruit and would be nice to have supported. config/arm64/default | 2 +- config/armv7hl/default | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/config/arm64/default b/config/arm64/default index b56082ebb8..35c7e6ae69 100644 --- a/config/arm64/default +++ b/config/arm64/default @@ -7024,7 +7024,7 @@ CONFIG_ENVELOPE_DETECTOR=m # CONFIG_EXYNOS_ADC is not set CONFIG_HI8435=m CONFIG_HX711=m -# CONFIG_INA2XX_ADC is not set +CONFIG_INA2XX_ADC=m CONFIG_LTC2485=m # CONFIG_MAX1027 is not set CONFIG_MAX11100=m diff --git a/config/armv7hl/default b/config/armv7hl/default index fa6a252063..287a37b11d 100644 --- a/config/armv7hl/default +++ b/config/armv7hl/default @@ -7747,7 +7747,7 @@ CONFIG_DA9150_GPADC=m CONFIG_ENVELOPE_DETECTOR=m CONFIG_EXYNOS_ADC=m CONFIG_HI8435=m -# CONFIG_INA2XX_ADC is not set +CONFIG_INA2XX_ADC=m # CONFIG_IMX7D_ADC is not set CONFIG_LP8788_ADC=m CONFIG_LTC2485=m -- 2.12.0 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============6394626473355028879==-- From mmarek@suse.com Fri Apr 7 08:38:22 2017 From: Michal Marek To: kernel@lists.opensuse.org Subject: [opensuse-kernel] Use fragment configs for -debug and i386/default? Date: Fri, 07 Apr 2017 10:38:21 +0200 Message-ID: <5cddb8ef-1299-2202-4f85-f9346181d45e@suse.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4290563580973524311==" --===============4290563580973524311== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi, some time ago, we switched the vanilla configs and subsequenly a few other special flavors to only contain the diff agains the -default kernel. I think it's a good idea to finish this conversion and only have a single base config per architecture. After doing sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default scripts/sequence-patch.sh --fast cd tmp/current ./run_oldconfig.sh I get this $ wc -l config/*/* 15 config/arm64/64kb 8480 config/arm64/default 4 config/arm64/vanilla 6846 config/armv6hl/default 3 config/armv6hl/vanilla 9160 config/armv7hl/default 8795 config/armv7hl/lpae 3 config/armv7hl/vanilla 216 config/i386/debug 341 config/i386/default 8332 config/i386/pae 6 config/i386/vanilla 48 config/ppc64/debug 6804 config/ppc64/default 3 config/ppc64/vanilla 46 config/ppc64le/debug 6654 config/ppc64le/default 3 config/ppc64le/vanilla 3366 config/s390x/default 3 config/s390x/vanilla 77 config/x86_64/debug 8363 config/x86_64/default 43 config/x86_64/syzkaller 6 config/x86_64/vanilla 67617 total config/armv7hl/lpae is still not converted, because armv6 and armv7 are currently disabled. config/i386/debug is larger than the other debug flavors, because it enables some drivers that pae does not (e.g. CONFIG_ISA). Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============4290563580973524311==-- From tiwai@suse.de Sat Apr 8 09:31:28 2017 From: Takashi Iwai To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] Use fragment configs for -debug and i386/default? Date: Sat, 08 Apr 2017 11:31:28 +0200 Message-ID: In-Reply-To: <5cddb8ef-1299-2202-4f85-f9346181d45e@suse.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4483063920461515277==" --===============4483063920461515277== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 07 Apr 2017 10:38:21 +0200, Michal Marek wrote: > > Hi, > > some time ago, we switched the vanilla configs and subsequenly a few > other special flavors to only contain the diff agains the -default > kernel. I think it's a good idea to finish this conversion and only have > a single base config per architecture. After doing > > sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default > scripts/sequence-patch.sh --fast > cd tmp/current > ./run_oldconfig.sh > > I get this > > $ wc -l config/*/* > 15 config/arm64/64kb > 8480 config/arm64/default > 4 config/arm64/vanilla > 6846 config/armv6hl/default > 3 config/armv6hl/vanilla > 9160 config/armv7hl/default > 8795 config/armv7hl/lpae > 3 config/armv7hl/vanilla > 216 config/i386/debug > 341 config/i386/default > 8332 config/i386/pae > 6 config/i386/vanilla > 48 config/ppc64/debug > 6804 config/ppc64/default > 3 config/ppc64/vanilla > 46 config/ppc64le/debug > 6654 config/ppc64le/default > 3 config/ppc64le/vanilla > 3366 config/s390x/default > 3 config/s390x/vanilla > 77 config/x86_64/debug > 8363 config/x86_64/default > 43 config/x86_64/syzkaller > 6 config/x86_64/vanilla > 67617 total > > config/armv7hl/lpae is still not converted, because armv6 and armv7 are > currently disabled. config/i386/debug is larger than the other debug > flavors, because it enables some drivers that pae does not (e.g. > CONFIG_ISA). This looks promising, thanks for doing this! I had the same idea, but you stepped in more quickly :) Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============4483063920461515277==-- From tiwai@suse.de Sat Apr 8 09:32:37 2017 From: Takashi Iwai To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] [PATCH] config: armv7hl/arm64: Enable TI INA2xx current/voltage sensors Date: Sat, 08 Apr 2017 11:32:36 +0200 Message-ID: In-Reply-To: <9ac4a543af67449193ba281f4206c844@rwthex-w2-b.rwth-ad.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7332717454274505025==" --===============7332717454274505025== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, 07 Apr 2017 03:05:25 +0200, Stefan Brüns wrote: > > Signed-off-by: Stefan Brüns > --- > The I2C connected TI INA219 can be found on a lot of small breakout boards, > e.g. from Adafruit and would be nice to have supported. In general, it's better to make clear which kernel is targeted to. thanks, Takashi > > config/arm64/default | 2 +- > config/armv7hl/default | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/config/arm64/default b/config/arm64/default > index b56082ebb8..35c7e6ae69 100644 > --- a/config/arm64/default > +++ b/config/arm64/default > @@ -7024,7 +7024,7 @@ CONFIG_ENVELOPE_DETECTOR=m > # CONFIG_EXYNOS_ADC is not set > CONFIG_HI8435=m > CONFIG_HX711=m > -# CONFIG_INA2XX_ADC is not set > +CONFIG_INA2XX_ADC=m > CONFIG_LTC2485=m > # CONFIG_MAX1027 is not set > CONFIG_MAX11100=m > diff --git a/config/armv7hl/default b/config/armv7hl/default > index fa6a252063..287a37b11d 100644 > --- a/config/armv7hl/default > +++ b/config/armv7hl/default > @@ -7747,7 +7747,7 @@ CONFIG_DA9150_GPADC=m > CONFIG_ENVELOPE_DETECTOR=m > CONFIG_EXYNOS_ADC=m > CONFIG_HI8435=m > -# CONFIG_INA2XX_ADC is not set > +CONFIG_INA2XX_ADC=m > # CONFIG_IMX7D_ADC is not set > CONFIG_LP8788_ADC=m > CONFIG_LTC2485=m > -- > 2.12.0 > > -- > To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org > -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============7332717454274505025==-- From tiwai@suse.de Sat Apr 8 09:36:00 2017 From: Takashi Iwai To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] Re: Any complaints about 4.4.57-18.3-default stability? Date: Sat, 08 Apr 2017 11:35:59 +0200 Message-ID: In-Reply-To: <58E6BEC5.8010600@tlinx.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8091639329049061733==" --===============8091639329049061733== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 07 Apr 2017 00:18:45 +0200, L A Walsh wrote: > > > > Someone else posted problems on the opensuse list > about the new crc option, a few days ago on Leap 42.2, > but they didn't give enough detail to tell if it was the same bug. If anyone has a problem with the last update kernel, please try KOTD available in OBS Kernel:openSUSE-42.2 repo, which is the build from the latest git snapshot. http://download.opensuse.org/repositories/Kernel:/openSUSE-42.2/ And, don't hesitate to report to openSUSE bugzilla. (But the test with KOTD will be asked in anyway there :) If the reported problem is serious, we can re-submit the newer update kernel quickly, just submitting from the working KOTD. thanks, Takashi > -linda > > > > -------- Original Message -------- > Subject: XFS and CRC on Leap 42.2 > Date: Sun, 2 Apr 2017 15:56:05 -0400 > From: Ciro Iriarte > To: OpenSuse List > > > > Hi!, can anyone comment on XFS stability on Leap 42.2 using crc=1?. > I've read that crc=1 should be the new default. I created a XFS > filesystem with explicit crc=1. > > Everything was working fine until I used that filesystem as a NFS > repository for ESXi, tried to move some VMs to it and had a complete > hang, hours later the filesystem went to read only mode. > > Trying to repair the FS I get CRC errors on the pending changelog. I > can purge the log, as the entries reference the directories of the VMs > I tried to move but I'm a little worried about keeping it like that. > I've just moved from BTRFS trying to avoid this issues :/ > > Regards, > > -- > Ciro Iriarte > http://iriarte.it > > > > -- > To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org > -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============8091639329049061733==-- From mmarek@suse.com Sat Apr 8 10:38:43 2017 From: Michal Marek To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] Use fragment configs for -debug and i386/default? Date: Sat, 08 Apr 2017 12:38:42 +0200 Message-ID: <17951cf5-39d7-df72-97b0-f031b3415680@suse.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5527927609633755626==" --===============5527927609633755626== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dne 8.4.2017 v 11:31 Takashi Iwai napsal(a): > On Fri, 07 Apr 2017 10:38:21 +0200, > Michal Marek wrote: >> >> Hi, >> >> some time ago, we switched the vanilla configs and subsequenly a few >> other special flavors to only contain the diff agains the -default >> kernel. I think it's a good idea to finish this conversion and only have >> a single base config per architecture. After doing >> >> sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default >> scripts/sequence-patch.sh --fast >> cd tmp/current >> ./run_oldconfig.sh >> >> I get this >> >> $ wc -l config/*/* >> 15 config/arm64/64kb >> 8480 config/arm64/default >> 4 config/arm64/vanilla >> 6846 config/armv6hl/default >> 3 config/armv6hl/vanilla >> 9160 config/armv7hl/default >> 8795 config/armv7hl/lpae >> 3 config/armv7hl/vanilla >> 216 config/i386/debug >> 341 config/i386/default >> 8332 config/i386/pae >> 6 config/i386/vanilla >> 48 config/ppc64/debug >> 6804 config/ppc64/default >> 3 config/ppc64/vanilla >> 46 config/ppc64le/debug >> 6654 config/ppc64le/default >> 3 config/ppc64le/vanilla >> 3366 config/s390x/default >> 3 config/s390x/vanilla >> 77 config/x86_64/debug >> 8363 config/x86_64/default >> 43 config/x86_64/syzkaller >> 6 config/x86_64/vanilla >> 67617 total >> >> config/armv7hl/lpae is still not converted, because armv6 and armv7 are >> currently disabled. config/i386/debug is larger than the other debug >> flavors, because it enables some drivers that pae does not (e.g. >> CONFIG_ISA). > > This looks promising, thanks for doing this! I had the same idea, but > you stepped in more quickly :) OK, pushed. The change required a fix for scripts/config-diff to handle the lowercase 'x' in CONFIG_CS89x0_PLATFORM. Now config/{x86_64,i386}/debug are identical and 77 lines long. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============5527927609633755626==-- From afaerber@suse.de Sat Apr 8 19:59:23 2017 From: Andreas =?utf-8?q?F=C3=A4rber?= To: kernel@lists.opensuse.org Subject: [opensuse-kernel] Use fragment config for armv7hl/lpae? (was: Use fragment configs for -debug and i386/default?) Date: Sat, 08 Apr 2017 21:59:21 +0200 Message-ID: In-Reply-To: <5cddb8ef-1299-2202-4f85-f9346181d45e@suse.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8593016491409439326==" --===============8593016491409439326== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michal, Am 07.04.2017 um 10:38 schrieb Michal Marek: > some time ago, we switched the vanilla configs and subsequenly a few > other special flavors to only contain the diff agains the -default > kernel. I think it's a good idea to finish this conversion and only have > a single base config per architecture. After doing >=20 > sed -i '/CONFIG_MMU=3Dy/d' config/*/debug config/i386/default > scripts/sequence-patch.sh --fast > cd tmp/current > ./run_oldconfig.sh >=20 > I get this >=20 > $ wc -l config/*/* [...] > 9160 config/armv7hl/default > 8795 config/armv7hl/lpae > 3 config/armv7hl/vanilla [...] > 67617 total >=20 > config/armv7hl/lpae is still not converted, because armv6 and armv7 are > currently disabled. "still not converted"??? It's not like we ever discussed a conversion! (Did you maybe mean s/still not/not yet/?) On the contrary, I already explained the default vs. lpae issue to you back when integrating dtb-armv7l into kernel packaging. How do you expect I maintain the lpae config as a fragment? By hand?! Saying "m" a few times more seems way easier to me. lpae is highly different from the 64kb flavor that just tweaks one or two options - the size difference above should make that obvious: The lpae flavor excludes support for old Cortex-A8/-A9/-A5 based platforms and enables a few platforms that depend on LPAE (e.g., LSI Axxia) as well as features that depend on LPAE (e.g., KVM). So please understand that the lpae flavor is not just the equivalent to pae flavor on i386, despite similar naming! vanilla is already a fragment config, based on default. Being based on default means we have no linux-next config for LPAE. So far no one has asked for one. I would claim that the lpae flavor is more important than default, because it supports the newer-generation hardware. So if you absolutely must force fragments onto us (which so far mostly affects myself and the CC'ed contributors, since during my recent absences your ARM engineers didn't even help update arm64!), I would much rather run oldconfig for lpae as a real config and risk having a default fragment break than the other way around. Switching the naming would cause problems for our JeOS images and cause even more confusion for users. Finally, on the topic of updating ARM configs, I am still annoyed about the new merge process: As someone not working on ARM kernels for his job, I need the weekend for testing new kernels on my boards at home. Previously I could commit ARM config changes to master branch myself on Friday, get them transferred to OBS Kernel:HEAD via your cron job on Saturday morning and when back home in the evening (or on Sunday) I could start testing the new packages. These days, despite my IRC pings, Jeff merges pending branches I push only after his next -rc update on Mondays, which then usually delays my testing until the next weekend. Also we don't seem to have any process in place that would notify me or let me review any ARM config changes from others, unless they're posted here as a patch, such as Stefan's that I just noticed. The new process simply doesn't work well for delegation of ARM configs to people outside your branch maintainers, i.e. no sub-maintainer model. In summary, there are delays getting updated configs submitted to your team by myself or community members, and then there are delays getting the submitted config updates merged by your team and thereby into OBS. During that timespan there are no kernels available from Kernel:HEAD ARM repo - Andreas Schwab had complained about that before, to no effect. https://build.opensuse.org/package/binaries/Kernel:HEAD/kernel-default?reposi= tory=3DARM (Currently this only shows aarch64 binaries, no armv6l or armv7l.) And I doubt you added any checks to stop yourselves from submitting a kernel with non-updated ARM configs to Kernel:stable, should it not get done within sufficient weeks. We had that happen for armv6l before I stepped in, I recall. Why are no alarm bells raised when, say, -rc3 still has "-!needs_updating"? Should be easy to grep for. So the kernel team clearly does not care about the master ARM configs (I was told to monitor an internal-only mailing list to get notified about -rc1 updates disabling the configs, for external contributors that still requires to poll the Git repository - no emails to opensuse-kernel or opensuse-arm for instance), and now you propose yet another change that seems to make the ARM updating process even harder for those that do care. Thank you very much... also for not CC'ing at least me on this proposal/complaint. Subject said nothing about ARM, and we don't have any -debug flavor there, so it would seem rather unrelated. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Felix Imend=C3=B6rffer, Jane Smithard, Graham Norton HRB 21284 (AG N=C3=BCrnberg) --=20 To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============8593016491409439326==-- From mmarek@suse.com Sat Apr 8 21:55:42 2017 From: Michal Marek To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] Use fragment config for armv7hl/lpae? Date: Sat, 08 Apr 2017 23:55:41 +0200 Message-ID: <5f2a2d75-01b1-3194-366d-6edfaf55b11f@suse.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3020789891223084640==" --===============3020789891223084640== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Dne 8.4.2017 v 21:59 Andreas Färber napsal(a): > Hi Michal, > > Am 07.04.2017 um 10:38 schrieb Michal Marek: >> some time ago, we switched the vanilla configs and subsequenly a few >> other special flavors to only contain the diff agains the -default >> kernel. I think it's a good idea to finish this conversion and only have >> a single base config per architecture. After doing >> >> sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default >> scripts/sequence-patch.sh --fast >> cd tmp/current >> ./run_oldconfig.sh >> >> I get this >> >> $ wc -l config/*/* > [...] >> 9160 config/armv7hl/default >> 8795 config/armv7hl/lpae >> 3 config/armv7hl/vanilla > [...] >> 67617 total >> >> config/armv7hl/lpae is still not converted, because armv6 and armv7 are >> currently disabled. > > "still not converted"??? It's not like we ever discussed a conversion! > (Did you maybe mean s/still not/not yet/?) > On the contrary, I already explained the default vs. lpae issue to you > back when integrating dtb-armv7l into kernel packaging. I meant to simply say "lpae is not converted." > How do you expect I maintain the lpae config as a fragment? By hand?! > Saying "m" a few times more seems way easier to me. In that case, just continue maintaining it this way. > vanilla is already a fragment config, based on default. Being based on > default means we have no linux-next config for LPAE. So far no one has > asked for one. > > I would claim that the lpae flavor is more important than default, > because it supports the newer-generation hardware. So if you absolutely > must force fragments onto us (which so far mostly affects myself and the I'm not forcing this model on anyone. I think it's a good idea to do it for -debug, because the diff to default is minimal. i386/default is also largely similar it i386/pae. Let's see how it will work in practice. Regarding linux-next for lpae, it can be done. It just needs to be switched in 4 different places, so please let me know upfront. > Finally, on the topic of updating ARM configs, I am still annoyed about > the new merge process: As someone not working on ARM kernels for his > job, I need the weekend for testing new kernels on my boards at home. > Previously I could commit ARM config changes to master branch myself on > Friday, get them transferred to OBS Kernel:HEAD via your cron job on > Saturday morning and when back home in the evening (or on Sunday) I > could start testing the new packages. These days, despite my IRC pings, > Jeff merges pending branches I push only after his next -rc update on > Mondays, which then usually delays my testing until the next weekend. Do you only test packages, or images built with the Kernel:HEAD packages? If it's the former, then simply do scripts/tar-up.sh && scripts/osc_wrapper upload home:a_faerber:... and have the packages built in your home project while waiting for Jeff to merge your changes. > Also we don't seem to have any process in place that would notify me or > let me review any ARM config changes from others, unless they're posted > here as a patch, such as Stefan's that I just noticed. The new process > simply doesn't work well for delegation of ARM configs to people outside > your branch maintainers, i.e. no sub-maintainer model. There is no sub-maintainer model and to be honest, I do not think we have a scalability problem to require a formal solution like this. Having multiple maintainers per branch with a verbal agreement about the areas of responsibility should work as well, shouldn't it? I can't speak for Jeff, of course. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============3020789891223084640==-- From afaerber@suse.de Sun Apr 9 00:48:03 2017 From: Andreas =?utf-8?q?F=C3=A4rber?= To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] [PATCH] config: armv7hl/arm64: Enable TI INA2xx current/voltage sensors Date: Sun, 09 Apr 2017 02:48:02 +0200 Message-ID: <3732421c-a76c-3902-d7fa-a257987ee83d@suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6421683673928195457==" --===============6421683673928195457== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Am 08.04.2017 um 11:32 schrieb Takashi Iwai: > On Fri, 07 Apr 2017 03:05:25 +0200, > Stefan Brüns wrote: >> >> Signed-off-by: Stefan Brüns >> --- >> The I2C connected TI INA219 can be found on a lot of small breakout boards, >> e.g. from Adafruit and would be nice to have supported. > > In general, it's better to make clear which kernel is targeted to. It was based on the half-updated master branch. I've rebased it onto my updates. >> config/arm64/default | 2 +- >> config/armv7hl/default | 2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) armv7hl lpae and armv6hl were missing - added. >> diff --git a/config/arm64/default b/config/arm64/default >> index b56082ebb8..35c7e6ae69 100644 >> --- a/config/arm64/default >> +++ b/config/arm64/default >> @@ -7024,7 +7024,7 @@ CONFIG_ENVELOPE_DETECTOR=m >> # CONFIG_EXYNOS_ADC is not set >> CONFIG_HI8435=m >> CONFIG_HX711=m >> -# CONFIG_INA2XX_ADC is not set >> +CONFIG_INA2XX_ADC=m INA2XX_ADC is documented to be exclusive with SENSORS_INA2XX, so I've disabled the latter (also for armv6hl), which now differs from the other architectures. At least the ARM configs are consistent now. >> CONFIG_LTC2485=m >> # CONFIG_MAX1027 is not set >> CONFIG_MAX11100=m [snip] Patch queued along with the remaining 4.11 updates. Thanks! I usually enable all new I2C/SPI sensors as modules, but I noticed there's more armv7hl ADC IIO drivers missing. Patch queued for IMX7D_ADC. Further cleanup patches appreciated. Another issue I need to look into is that linux-tools has a build regression for Kernel:HEAD due to some IIO_GRAVITY constant: https://build.opensuse.org/package/show/devel:tools/linux-tools In addition to iio-tools I had packaged libiio and just enabled ARM builds: https://build.opensuse.org/package/show/hardware/libiio Neither package is included in Factory at this time. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============6421683673928195457==-- From matwey.kornilov@gmail.com Sun Apr 9 15:57:48 2017 From: "Matwey V. Kornilov" To: kernel@lists.opensuse.org Subject: [opensuse-kernel] Re: Use fragment config for armv7hl/lpae? Date: Sun, 09 Apr 2017 18:57:31 +0300 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6880303414033772261==" --===============6880303414033772261== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 08.04.2017 22:59, Andreas F=C3=A4rber =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Hi Michal, >=20 > Am 07.04.2017 um 10:38 schrieb Michal Marek: >> some time ago, we switched the vanilla configs and subsequenly a few >> other special flavors to only contain the diff agains the -default >> kernel. I think it's a good idea to finish this conversion and only have >> a single base config per architecture. After doing >> >> sed -i '/CONFIG_MMU=3Dy/d' config/*/debug config/i386/default >> scripts/sequence-patch.sh --fast >> cd tmp/current >> ./run_oldconfig.sh >> >> I get this >> >> $ wc -l config/*/* > [...] >> 9160 config/armv7hl/default >> 8795 config/armv7hl/lpae >> 3 config/armv7hl/vanilla > [...] >> 67617 total >> >> config/armv7hl/lpae is still not converted, because armv6 and armv7 are >> currently disabled. >=20 > "still not converted"??? It's not like we ever discussed a conversion! > (Did you maybe mean s/still not/not yet/?) > On the contrary, I already explained the default vs. lpae issue to you > back when integrating dtb-armv7l into kernel packaging. >=20 > How do you expect I maintain the lpae config as a fragment? By hand?! > Saying "m" a few times more seems way easier to me. >=20 > lpae is highly different from the 64kb flavor that just tweaks one or > two options - the size difference above should make that obvious: The > lpae flavor excludes support for old Cortex-A8/-A9/-A5 based platforms > and enables a few platforms that depend on LPAE (e.g., LSI Axxia) as > well as features that depend on LPAE (e.g., KVM). So please understand > that the lpae flavor is not just the equivalent to pae flavor on i386, > despite similar naming! >=20 > vanilla is already a fragment config, based on default. Being based on > default means we have no linux-next config for LPAE. So far no one has > asked for one. >=20 > I would claim that the lpae flavor is more important than default, > because it supports the newer-generation hardware. So if you absolutely > must force fragments onto us (which so far mostly affects myself and the > CC'ed contributors, since during my recent absences your ARM engineers > didn't even help update arm64!), I would much rather run oldconfig for > lpae as a real config and risk having a default fragment break than the > other way around. Switching the naming would cause problems for our JeOS > images and cause even more confusion for users. Dear All, Year or two ago I regularly submitted here config-update patches for arm. Unfortunately, I don't have much time to track new kernel releases now. But, I would like to say from my experience that I think that kernel configs might be managed better than now. Frankly speaking, the first thing I did when I needed to update ARM config was cherry-picking last arch-independent changes from x86_64 config. There are things like filesystems and network protocols. It In my personal opinion, to split out arch-independent config options would be more useful than default/lpae diffing. That would simplify ARM config maintenance at least. >=20 >=20 > Finally, on the topic of updating ARM configs, I am still annoyed about > the new merge process: As someone not working on ARM kernels for his > job, I need the weekend for testing new kernels on my boards at home. > Previously I could commit ARM config changes to master branch myself on > Friday, get them transferred to OBS Kernel:HEAD via your cron job on > Saturday morning and when back home in the evening (or on Sunday) I > could start testing the new packages. These days, despite my IRC pings, > Jeff merges pending branches I push only after his next -rc update on > Mondays, which then usually delays my testing until the next weekend. >=20 > Also we don't seem to have any process in place that would notify me or > let me review any ARM config changes from others, unless they're posted > here as a patch, such as Stefan's that I just noticed. The new process > simply doesn't work well for delegation of ARM configs to people outside > your branch maintainers, i.e. no sub-maintainer model. >=20 > In summary, there are delays getting updated configs submitted to your > team by myself or community members, and then there are delays getting > the submitted config updates merged by your team and thereby into OBS. > During that timespan there are no kernels available from Kernel:HEAD ARM > repo - Andreas Schwab had complained about that before, to no effect. >=20 > https://build.opensuse.org/package/binaries/Kernel:HEAD/kernel-default?repo= sitory=3DARM >=20 > (Currently this only shows aarch64 binaries, no armv6l or armv7l.) >=20 > And I doubt you added any checks to stop yourselves from submitting a > kernel with non-updated ARM configs to Kernel:stable, should it not get > done within sufficient weeks. We had that happen for armv6l before I > stepped in, I recall. Why are no alarm bells raised when, say, -rc3 > still has "-!needs_updating"? Should be easy to grep for. >=20 > So the kernel team clearly does not care about the master ARM configs (I > was told to monitor an internal-only mailing list to get notified about > -rc1 updates disabling the configs, for external contributors that still > requires to poll the Git repository - no emails to opensuse-kernel or > opensuse-arm for instance), and now you propose yet another change that > seems to make the ARM updating process even harder for those that do > care. Thank you very much... also for not CC'ing at least me on this > proposal/complaint. Subject said nothing about ARM, and we don't have > any -debug flavor there, so it would seem rather unrelated. >=20 > Regards, > Andreas >=20 --=20 To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============6880303414033772261==-- From afaerber@suse.de Sun Apr 9 20:18:40 2017 From: Andreas =?utf-8?q?F=C3=A4rber?= To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] Use fragment config for armv7hl/lpae? Date: Sun, 09 Apr 2017 22:18:39 +0200 Message-ID: In-Reply-To: <5f2a2d75-01b1-3194-366d-6edfaf55b11f@suse.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0900088688743310879==" --===============0900088688743310879== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Am 08.04.2017 um 23:55 schrieb Michal Marek: > Dne 8.4.2017 v 21:59 Andreas Färber napsal(a): >> Hi Michal, >> >> Am 07.04.2017 um 10:38 schrieb Michal Marek: >>> some time ago, we switched the vanilla configs and subsequenly a few >>> other special flavors to only contain the diff agains the -default >>> kernel. I think it's a good idea to finish this conversion and only have >>> a single base config per architecture. After doing >>> >>> sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default >>> scripts/sequence-patch.sh --fast >>> cd tmp/current >>> ./run_oldconfig.sh >>> >>> I get this >>> >>> $ wc -l config/*/* >> [...] >>> 9160 config/armv7hl/default >>> 8795 config/armv7hl/lpae >>> 3 config/armv7hl/vanilla >> [...] >>> 67617 total >>> >>> config/armv7hl/lpae is still not converted, because armv6 and armv7 are >>> currently disabled. >> >> "still not converted"??? It's not like we ever discussed a conversion! >> (Did you maybe mean s/still not/not yet/?) >> On the contrary, I already explained the default vs. lpae issue to you >> back when integrating dtb-armv7l into kernel packaging. > > I meant to simply say "lpae is not converted." Okay, it sounded very pushy to me before. >> vanilla is already a fragment config, based on default. Being based on >> default means we have no linux-next config for LPAE. So far no one has >> asked for one. >> >> I would claim that the lpae flavor is more important than default, >> because it supports the newer-generation hardware. So if you absolutely >> must force fragments onto us (which so far mostly affects myself and the > > I'm not forcing this model on anyone. I think it's a good idea to do it > for -debug, because the diff to default is minimal. i386/default is also > largely similar it i386/pae. Let's see how it will work in practice. Don't get me wrong, I am commenting solely on lpae here. vanilla and 64kb being fragments is a very helpful feature, thank you very much! Having lpae not be a fragment obviously contradicts your "only have a single base config per architecture" paradigm, which sounded like you wanted to enforce that in your scripts. > Regarding linux-next for lpae, it can be done. It just needs to be > switched in 4 different places, so please let me know upfront. Thanks for that offer. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============0900088688743310879==-- From jdelvare@suse.de Mon Apr 10 15:29:14 2017 From: Jean Delvare To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] Use fragment configs for -debug and i386/default? Date: Mon, 10 Apr 2017 17:29:13 +0200 Message-ID: <1491838153.32002.31.camel@suse.de> In-Reply-To: <17951cf5-39d7-df72-97b0-f031b3415680@suse.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0815441318296555096==" --===============0815441318296555096== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On sam., 2017-04-08 at 12:38 +0200, Michal Marek wrote: > Dne 8.4.2017 v 11:31 Takashi Iwai napsal(a): > > > > On Fri, 07 Apr 2017 10:38:21 +0200, > > Michal Marek wrote: > > > > > > > > > Hi, > > > > > > some time ago, we switched the vanilla configs and subsequenly a few > > > other special flavors to only contain the diff agains the -default > > > kernel. I think it's a good idea to finish this conversion and only have > > > a single base config per architecture. After doing > > > > > > sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default > > > scripts/sequence-patch.sh --fast > > > cd tmp/current > > > ./run_oldconfig.sh > > > > > > I get this > > > > > > $ wc -l config/*/* > > > 15 config/arm64/64kb > > > 8480 config/arm64/default > > > 4 config/arm64/vanilla > > > 6846 config/armv6hl/default > > > 3 config/armv6hl/vanilla > > > 9160 config/armv7hl/default > > > 8795 config/armv7hl/lpae > > > 3 config/armv7hl/vanilla > > > 216 config/i386/debug > > > 341 config/i386/default > > > 8332 config/i386/pae > > > 6 config/i386/vanilla > > > 48 config/ppc64/debug > > > 6804 config/ppc64/default > > > 3 config/ppc64/vanilla > > > 46 config/ppc64le/debug > > > 6654 config/ppc64le/default > > > 3 config/ppc64le/vanilla > > > 3366 config/s390x/default > > > 3 config/s390x/vanilla > > > 77 config/x86_64/debug > > > 8363 config/x86_64/default > > > 43 config/x86_64/syzkaller > > > 6 config/x86_64/vanilla > > > 67617 total > > > > > > config/armv7hl/lpae is still not converted, because armv6 and armv7 are > > > currently disabled. config/i386/debug is larger than the other debug > > > flavors, because it enables some drivers that pae does not (e.g. > > > CONFIG_ISA). > > > > This looks promising, thanks for doing this! I had the same idea, but > > you stepped in more quickly :) > > OK, pushed. The change required a fix for scripts/config-diff to handle > the lowercase 'x' in CONFIG_CS89x0_PLATFORM. Now > config/{x86_64,i386}/debug are identical and 77 lines long. This is an excellent idea, thanks Michal for making it happen :-) -- Jean Delvare SUSE L3 Support -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============0815441318296555096==-- From afaerber@suse.de Mon Apr 10 17:34:16 2017 From: Andreas =?utf-8?q?F=C3=A4rber?= To: kernel@lists.opensuse.org Subject: [opensuse-kernel] Maintaining ARM configs (was: Use fragment config for armv7hl/lpae?) Date: Mon, 10 Apr 2017 19:34:15 +0200 Message-ID: In-Reply-To: <5f2a2d75-01b1-3194-366d-6edfaf55b11f@suse.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0813638762308381553==" --===============0813638762308381553== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Am 08.04.2017 um 23:55 schrieb Michal Marek: > Dne 8.4.2017 v 21:59 Andreas Färber napsal(a): >> Am 07.04.2017 um 10:38 schrieb Michal Marek: >>> config/armv7hl/lpae is [...] not converted, because armv6 and armv7 are >>> currently disabled. [...] >> Finally, on the topic of updating ARM configs, I am still annoyed about >> the new merge process: As someone not working on ARM kernels for his >> job, I need the weekend for testing new kernels on my boards at home. >> Previously I could commit ARM config changes to master branch myself on >> Friday, get them transferred to OBS Kernel:HEAD via your cron job on >> Saturday morning and when back home in the evening (or on Sunday) I >> could start testing the new packages. These days, despite my IRC pings, >> Jeff merges pending branches I push only after his next -rc update on >> Mondays, which then usually delays my testing until the next weekend. > > Do you only test packages, or images built with the Kernel:HEAD > packages? Both. Packages on boards that already run openSUSE, and a few branched JeOS images that build against Kernel:HEAD for unfinished boards. We also have a public devel:ARM:Factory:Contrib:HEAD project building against Kernel:HEAD. (Apart from JeOS-efi image, other images were usually temporary there, favoring manual addition of Kernel:HEAD for build power reasons.) > If it's the former, then simply do > > scripts/tar-up.sh && scripts/osc_wrapper upload home:a_faerber:... > > and have the packages built in your home project while waiting for Jeff > to merge your changes. Thanks for that tip! That was much faster than trying to build locally in tmp/current/ (takes all weekend), and OBS makes installation easier. >> Also we don't seem to have any process in place that would notify me or >> let me review any ARM config changes from others, unless they're posted >> here as a patch, such as Stefan's that I just noticed. The new process >> simply doesn't work well for delegation of ARM configs to people outside >> your branch maintainers, i.e. no sub-maintainer model. > > There is no sub-maintainer model and to be honest, I do not think we > have a scalability problem to require a formal solution like this. > Having multiple maintainers per branch with a verbal agreement about the > areas of responsibility should work as well, shouldn't it? I can't speak > for Jeff, of course. I'm not worried about scalability, just about review and coordination. Unlike the upstream kernel workflow with scripts/get_maintainer.pl CC'ing sub-maintainers about certain changes, I don't get notified if anyone else touches config/arm*/*. Takashi, Jean and others doing cross-architecture cleanups have been so kind to ask on this list first before performing config changes. However if someone were to push a for-next branch with updated ARM configs in my absence, I wouldn't get any automatic email, because the "... is ready to be merged" mails only go to Jeff (and an internal list with quite some traffic), and there is no diffstat or other indication (apart from voluntary commit message conventions for ARM-only changes) to indicate that it is something for me to be aware of. With help from Jeff I've managed to set up email filters so that I now see when -rc1 has arrived in master. But by the time I get such update notifications it would be too late to object to any particular ARM-side change, only reverts or fix-ups would be possible at that point - for example, Dirk once simply disabled all Renesas options without any discussion or notification - thus it remained that way. (And as seen, email filters don't guarantee I read it immediately or can react to it when on travels - thanks to Stefan who ping'ed me on IRC.) kernel.opensuse.org only shows merged commits, not pending branches, so Matwey didn't see either when I had partial updates queued already and spent time on patches at some point. Master branch shouldn't contain any embargoed patches, so making branch existence or contents visible externally would seem thinkable. Wouldn't it be possible to extend your branch-checking scripts to address these issues in some form or another? Also, nobody seemed to notice that a while ago there was a dtb packaging pull request on GitHub - I only learned via pings on #opensuse-arm (after I had declined an SR against the old dtb-source). So it seems that each branch maintainer/reviewer needs to set the GitHub "watch" settings for that repository to get notified of pulls that affect them? No automatic mirroring from GitHub into SUSE, no kbuild notifications? Overall it just feels like the assumption still is that everything is handled by the SUSE kernel team, with little provisions for the openSUSE community to participate, myself being somewhere in between. Patches on opensuse-kernel have been working best so far, so should I simply integrate some git-send-email --to=opensuse-kernel(a)opensuse.org or maybe better opensuse-arm(a)opensuse.org into my git-push scripts, to lead by example? Absence of emails would then likely mean no update done yet. Might cause some list "spam" though. Ideas welcome. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============0813638762308381553==-- From afaerber@suse.de Wed Apr 19 19:14:45 2017 From: Andreas =?utf-8?q?F=C3=A4rber?= To: kernel@lists.opensuse.org Subject: [opensuse-kernel] Kernel:HEAD armv7l kernel-lpae OOM Date: Wed, 19 Apr 2017 21:14:44 +0200 Message-ID: <52299f8f-4c3f-e5ee-4d9e-46c1f5dce25a@suse.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8474232010526906959==" --===============8474232010526906959== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi, kernel-lpae 4.11.rc7 failed to build for armv7hl: [33246s] calling /usr/lib/rpm/brp-suse.d/brp-99-pesign [33246s] Using signing certificate /home/abuild/rpmbuild/SOURCES/_projectcert.crt [33247s] Creating /home/abuild/rpmbuild/OTHER/kernel-lpae.cpio.rsasign [33282s] [33220.985937] Out of memory: Kill process 1408 (rpmbuild) score 2 or sacrifice child [33282s] [33220.988302] Killed process 25612 (bash) total-vm:3516kB, anon-rss:160kB, file-rss:1980kB, shmem-rss:0kB [33282s] error: Bad exit status from /var/tmp/rpm-tmp.2fR0OE (%install) [33282s] [33282s] [33282s] RPM build errors: [33282s] Bad exit status from /var/tmp/rpm-tmp.2fR0OE (%install) [33285s] [33285s] armbuild17 failed "build kernel-lpae.spec" at Wed Apr 19 15:28:44 UTC 2017. Do we need to tweak rpm/constaints.in? If I'm reading correctly, it has a constraint of 2 GB RAM for binary packages, with no override for ARM. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============8474232010526906959==-- From mmarek@suse.cz Wed Apr 19 20:13:21 2017 From: Michal Marek To: kernel@lists.opensuse.org Subject: [opensuse-kernel] Re: Kernel:HEAD armv7l kernel-lpae OOM Date: Wed, 19 Apr 2017 22:13:20 +0200 Message-ID: <50530765-94f0-f772-7a21-2c42e1552648@suse.cz> In-Reply-To: <52299f8f-4c3f-e5ee-4d9e-46c1f5dce25a@suse.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8896673892011121051==" --===============8896673892011121051== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Dne 19.4.2017 v 21:14 Andreas Färber napsal(a): > Hi, > > kernel-lpae 4.11.rc7 failed to build for armv7hl: > > [33246s] calling /usr/lib/rpm/brp-suse.d/brp-99-pesign > [33246s] Using signing certificate > /home/abuild/rpmbuild/SOURCES/_projectcert.crt > [33247s] Creating /home/abuild/rpmbuild/OTHER/kernel-lpae.cpio.rsasign > [33282s] [33220.985937] Out of memory: Kill process 1408 (rpmbuild) > score 2 or sacrifice child > [33282s] [33220.988302] Killed process 25612 (bash) total-vm:3516kB, > anon-rss:160kB, file-rss:1980kB, shmem-rss:0kB > [33282s] error: Bad exit status from /var/tmp/rpm-tmp.2fR0OE (%install) > [33282s] > [33282s] > [33282s] RPM build errors: > [33282s] Bad exit status from /var/tmp/rpm-tmp.2fR0OE (%install) > [33285s] > [33285s] armbuild17 failed "build kernel-lpae.spec" at Wed Apr 19 > 15:28:44 UTC 2017. > > Do we need to tweak rpm/constaints.in? If I'm reading correctly, it has > a constraint of 2 GB RAM for binary packages, with no override for ARM. I agree that 2GB is too little, but the scheduler does not fulfill this request even: $ osc rbl --last Kernel:HEAD kernel-default standard x86_64 | grep /qemu- | grep -o ' -m [0-9]*' -m 1500 -m 1500 $ osc rbl --last Kernel:HEAD kernel-lpae ARM armv7l | grep /qemu- | grep -o ' -m [0-9]*' -m 1020 Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============8896673892011121051==-- From mmarek@suse.cz Wed Apr 19 21:23:55 2017 From: Michal Marek To: kernel@lists.opensuse.org Subject: [opensuse-kernel] Re: Kernel:HEAD armv7l kernel-lpae OOM Date: Wed, 19 Apr 2017 23:23:55 +0200 Message-ID: In-Reply-To: <47E30843-56AA-49A5-9A7B-5E30C8C9AD26@suse.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5360132079922017742==" --===============5360132079922017742== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Dne 19.4.2017 v 23:08 Dirk Müller napsal(a): > HI, > >>> [33246s] calling /usr/lib/rpm/brp-suse.d/brp-99-pesign [33246s] >>> Using signing certificate >>> /home/abuild/rpmbuild/SOURCES/_projectcert.crt > > we're using pesign on armv7 nowadays? why? God question. >>> Do we need to tweak rpm/constaints.in? If I'm reading correctly, >>> it has a constraint of 2 GB RAM for binary packages, with no >>> override for ARM. >> I agree that 2GB is too little > > what changed? why was it not a problem in the past? For a single-cpu build on armv7 it's probably OK, if we get rid of pesig. I was surprised to see the x86_64 build using 1.5GB. But then the scheduler ignores the constraint as well and uses a worker with 4 CPUs, so we fit into the RAM fine... > we do have a few workers with 3 and 4 GB of RAM for armv7, but > they're not many and always busy (we have a ton of forks of So is the _constraints file actually used on build.opensuse.org? > libreoffice and ceph that are basically building all the time on > those).. I would prefer to be able to run the jobs with less memory, > is there a way to achieve that? if it is really pesign, why are we > using that on armv7 and why is it eating that much memory? Yeah, this particular failure is due to pesign, which should only run if CONFIG_MODULE_SIG=y. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============5360132079922017742==-- From afaerber@suse.de Wed Apr 19 21:38:40 2017 From: Andreas =?utf-8?q?F=C3=A4rber?= To: kernel@lists.opensuse.org Subject: [opensuse-kernel] Re: Kernel:HEAD armv7l kernel-lpae OOM Date: Wed, 19 Apr 2017 23:38:39 +0200 Message-ID: In-Reply-To: <47E30843-56AA-49A5-9A7B-5E30C8C9AD26@suse.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6698352351795417159==" --===============6698352351795417159== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Dirk, Am 19.04.2017 um 23:08 schrieb Dirk M=C3=BCller: >>> Do we need to tweak rpm/constaints.in? If I'm reading correctly, it has >>> a constraint of 2 GB RAM for binary packages, with no override for ARM. >> I agree that 2GB is too little >=20 > what changed? why was it not a problem in the past? The last successful build was for -rc6 (2nd revision, with serdev), so the tarball changed but no armv7hl Kconfig options for -rc7: http://kernel.opensuse.org/cgit/kernel-source/commit/?id=3D6e80a142558610d351= 5deb5c6bedd45fb9c0c394 In general of course the number of modules (and of built-in options) grows over time. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Felix Imend=C3=B6rffer, Jane Smithard, Graham Norton HRB 21284 (AG N=C3=BCrnberg) --=20 To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============6698352351795417159==-- From mmarek@suse.cz Wed Apr 19 22:22:00 2017 From: Michal Marek To: kernel@lists.opensuse.org Subject: [opensuse-kernel] Re: Kernel:HEAD armv7l kernel-lpae OOM Date: Thu, 20 Apr 2017 00:21:59 +0200 Message-ID: <32d3a9cb-7202-903d-50d5-a7f00d1d28b1@suse.cz> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2569781355894826095==" --===============2569781355894826095== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Dne 19.4.2017 v 23:56 Dirk Müller napsal(a): >>> we're using pesign on armv7 nowadays? why? >> God question. > > hmm, ok, so it is worth investigating that part then if there is no > good reason for that. I fixed it now as bsc#1035053. >>> we do have a few workers with 3 and 4 GB of RAM for armv7, but >>> they're not many and always busy (we have a ton of forks of >> So is the _constraints file actually used on build.opensuse.org? > > yeah, but your constraint specifies (which is > physicalmemory+swap). The workers with 1GB of physical RAM still have > 2 (4?) G of swap, so they are elligible choices. the oom killer might > kill this sooner though. OK. > is this maybe another OOM regression? the other variable that could > have changed is kernel-obs-build's oom behavior. The only mm changes after v4.12-rc6 were some THP fixes, so that's rather unlikely. It's possible that we were just unlucky this time. I triggered a rebuild of Kernel:HEAD/kernel-lpae with the original spec file, let's see if it fails again or not. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============2569781355894826095==-- From dmueller@suse.com Thu Apr 20 06:42:44 2017 From: Dirk =?utf-8?q?M=C3=BCller?= To: kernel@lists.opensuse.org Subject: [opensuse-kernel] Re: Kernel:HEAD armv7l kernel-lpae OOM Date: Wed, 19 Apr 2017 23:08:23 +0200 Message-ID: <47E30843-56AA-49A5-9A7B-5E30C8C9AD26@suse.com> In-Reply-To: <50530765-94f0-f772-7a21-2c42e1552648@suse.cz> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6695271322846984330==" --===============6695271322846984330== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable HI, >> [33246s] calling /usr/lib/rpm/brp-suse.d/brp-99-pesign >> [33246s] Using signing certificate >> /home/abuild/rpmbuild/SOURCES/_projectcert.crt we're using pesign on armv7 nowadays? why? >> Do we need to tweak rpm/constaints.in? If I'm reading correctly, it has >> a constraint of 2 GB RAM for binary packages, with no override for ARM. > I agree that 2GB is too little what changed? why was it not a problem in the past? > , but the scheduler does not fulfill this > request even: >=20 > $ osc rbl --last Kernel:HEAD kernel-default standard x86_64 | grep > /qemu- | grep -o ' -m [0-9]*' > -m 1500 > -m 1500 > $ osc rbl --last Kernel:HEAD kernel-lpae ARM armv7l | grep /qemu- | grep > -o ' -m [0-9]*' > -m 1020 we do have a few workers with 3 and 4 GB of RAM for armv7, but they're not ma= ny and always busy (we have a ton of forks of libreoffice and ceph that are b= asically building all the time on those).. I would prefer to be able to run t= he jobs with less memory, is there a way to achieve that? if it is really pes= ign, why are we using that on armv7 and why is it eating that much memory? Thanks, Dirk --=20 To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============6695271322846984330==-- From dmueller@suse.com Thu Apr 20 06:42:49 2017 From: Dirk =?utf-8?q?M=C3=BCller?= To: kernel@lists.opensuse.org Subject: [opensuse-kernel] Re: Kernel:HEAD armv7l kernel-lpae OOM Date: Wed, 19 Apr 2017 23:56:06 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6428449540848291257==" --===============6428449540848291257== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> we're using pesign on armv7 nowadays? why? > God question. hmm, ok, so it is worth investigating that part then if there is no good reas= on for that.=20 >> we do have a few workers with 3 and 4 GB of RAM for armv7, but >> they're not many and always busy (we have a ton of forks of > So is the _constraints file actually used on build.opensuse.org? yeah, but your constraint specifies (which is physicalmemory+swap). = The workers with 1GB of physical RAM still have 2 (4?) G of swap, so they are= elligible choices. the oom killer might kill this sooner though.=20 is this maybe another OOM regression? the other variable that could have chan= ged is kernel-obs-build's oom behavior. Thanks, Dirk--=20 To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============6428449540848291257==-- From ludwig.nussel@suse.de Thu Apr 20 07:29:00 2017 From: Ludwig Nussel To: kernel@lists.opensuse.org Subject: [opensuse-kernel] excessive kernel .changes files Date: Thu, 20 Apr 2017 09:28:59 +0200 Message-ID: <79aaf815-2a19-8036-e930-bc09ca8d708c@suse.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6847151273857213293==" --===============6847151273857213293== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi, Looking at https://build.opensuse.org/request/show/488903 I wonder whether there is actually any value in having each and every git commit mentioned in the .changes files? Would it make sense to e.g. only list the range of commits that was added, plus any bug, fate, cve etc entries fixed in that range? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============6847151273857213293==-- From tiwai@suse.de Thu Apr 20 08:35:25 2017 From: Takashi Iwai To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] excessive kernel .changes files Date: Thu, 20 Apr 2017 10:35:25 +0200 Message-ID: In-Reply-To: <79aaf815-2a19-8036-e930-bc09ca8d708c@suse.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7338829246662418645==" --===============7338829246662418645== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 20 Apr 2017 09:28:59 +0200, Ludwig Nussel wrote: > > Hi, > > Looking at https://build.opensuse.org/request/show/488903 I wonder > whether there is actually any value in having each and every git > commit mentioned in the .changes files? > Would it make sense to e.g. only list the range of commits that was > added, plus any bug, fate, cve etc entries fixed in that range? Well, I understand your surprise, but it's really the result of our own changes. SLE/Leap kernel takes our patches, thus each of these changes should be recorded. Actually, the upstream stable change is a single, relatively small changelog entry. All the rest are about our own backports and fixes. These own changes are just so big. You can see the difference by comparing with TW kernel changelog. TW kernel mostly follows the upstream with far less own patches, thus the changelog is much smaller. OTOH, for SLE/Leap, we are responsible for each of our own changes. And customers often require to take a look through the changes without git accesses. Thus, not only bug#/CVE#, but each detailed change is good to have as a changelog record. Last but not least, the kernel package is constantly updated. So we can't group the git commits in the changelog -- as changelog is supposed to be incremental. Of course, if you have a better idea to shorten the log, please let us know. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============7338829246662418645==-- From mmarek@suse.com Thu Apr 20 08:41:30 2017 From: Michal Marek To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] excessive kernel .changes files Date: Thu, 20 Apr 2017 10:41:22 +0200 Message-ID: <9a411724-d31b-2040-a17b-e8058c7052b9@suse.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6548361084082320438==" --===============6548361084082320438== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2017-04-20 10:35, Takashi Iwai wrote: > On Thu, 20 Apr 2017 09:28:59 +0200, > Ludwig Nussel wrote: >> >> Hi, >> >> Looking at https://build.opensuse.org/request/show/488903 I wonder >> whether there is actually any value in having each and every git >> commit mentioned in the .changes files? >> Would it make sense to e.g. only list the range of commits that was >> added, plus any bug, fate, cve etc entries fixed in that range? > > Well, I understand your surprise, but it's really the result of our > own changes. SLE/Leap kernel takes our patches, thus each of these > changes should be recorded. Actually, the upstream stable change is a > single, relatively small changelog entry. All the rest are about our > own backports and fixes. These own changes are just so big. Right. > Of course, if you have a better idea to shorten the log, please let us > know. One thing that we can and should do in Tumbleweed is to cut off old changelog entries. Right now, we are preserving the rpm changelog from 2008 (kernel 2.6.24). I hope this is doable with the checkin scripts. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============6548361084082320438==-- From tiwai@suse.de Mon Apr 24 15:45:00 2017 From: Takashi Iwai To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] Use fragment configs for -debug and i386/default? Date: Mon, 24 Apr 2017 17:44:59 +0200 Message-ID: In-Reply-To: <5cddb8ef-1299-2202-4f85-f9346181d45e@suse.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3695909886382156065==" --===============3695909886382156065== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 07 Apr 2017 10:38:21 +0200, Michal Marek wrote: > > Hi, > > some time ago, we switched the vanilla configs and subsequenly a few > other special flavors to only contain the diff agains the -default > kernel. I think it's a good idea to finish this conversion and only have > a single base config per architecture. After doing > > sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default > scripts/sequence-patch.sh --fast > cd tmp/current > ./run_oldconfig.sh > > I get this > > $ wc -l config/*/* > 15 config/arm64/64kb > 8480 config/arm64/default > 4 config/arm64/vanilla > 6846 config/armv6hl/default > 3 config/armv6hl/vanilla > 9160 config/armv7hl/default > 8795 config/armv7hl/lpae > 3 config/armv7hl/vanilla > 216 config/i386/debug > 341 config/i386/default > 8332 config/i386/pae > 6 config/i386/vanilla > 48 config/ppc64/debug > 6804 config/ppc64/default > 3 config/ppc64/vanilla > 46 config/ppc64le/debug > 6654 config/ppc64le/default > 3 config/ppc64le/vanilla > 3366 config/s390x/default > 3 config/s390x/vanilla > 77 config/x86_64/debug > 8363 config/x86_64/default > 43 config/x86_64/syzkaller > 6 config/x86_64/vanilla > 67617 total > > config/armv7hl/lpae is still not converted, because armv6 and armv7 are > currently disabled. config/i386/debug is larger than the other debug > flavors, because it enables some drivers that pae does not (e.g. > CONFIG_ISA). BTW, recently I noticed that config/i386/default varies unstably after running run_oldconfig.sh. Some configs are turned on once, and turned off at the next update, or so. Any side-effect by this change...? Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============3695909886382156065==-- From mmarek@suse.com Mon Apr 24 19:51:26 2017 From: Michal Marek To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] Use fragment configs for -debug and i386/default? Date: Mon, 24 Apr 2017 21:51:25 +0200 Message-ID: <1d204785-fb2f-8133-4efa-032afefae892@suse.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2271640145044191567==" --===============2271640145044191567== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dne 24.4.2017 v 17:44 Takashi Iwai napsal(a): > BTW, recently I noticed that config/i386/default varies unstably > after running run_oldconfig.sh. Some configs are turned on once, and > turned off at the next update, or so. Any side-effect by this > change...? Do you remember what command you used to change the configs in 9add1483339d ("Enable CONFIG_KXCJK1013 for Cherrytrail devices (boo#1034809).") The logic for run_oldconfig.sh -nco-{y,m,n} is as follows: # do not change trimmed configs unless requested if test -z "$set_flavor" && ! \ grep -q '^CONFIG_MMU=' "${prefix}config/$config"; then continue fi Which means that if you explicitly specify the flavor, it will change even fragmented configs. This makes perfect sense for --flavor vanilla, but --flavor default is probably not explicit enough. That the option disappeared when Jeff ran run_oldconfig.sh is correct, because it was redundant. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============2271640145044191567==-- From tiwai@suse.de Mon Apr 24 20:21:16 2017 From: Takashi Iwai To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] Use fragment configs for -debug and i386/default? Date: Mon, 24 Apr 2017 22:21:15 +0200 Message-ID: In-Reply-To: <1d204785-fb2f-8133-4efa-032afefae892@suse.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8480299839066893306==" --===============8480299839066893306== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 24 Apr 2017 21:51:25 +0200, Michal Marek wrote: > > Dne 24.4.2017 v 17:44 Takashi Iwai napsal(a): > > BTW, recently I noticed that config/i386/default varies unstably > > after running run_oldconfig.sh. Some configs are turned on once, and > > turned off at the next update, or so. Any side-effect by this > > change...? > > Do you remember what command you used to change the configs in > > 9add1483339d ("Enable CONFIG_KXCJK1013 for Cherrytrail devices > (boo#1034809).") IIRC, I just ran the usual patches/script/run_oldconfig.sh on the tree expanded by sequence-patch. > The logic for run_oldconfig.sh -nco-{y,m,n} is as follows: > > # do not change trimmed configs unless requested > if test -z "$set_flavor" && ! \ > grep -q '^CONFIG_MMU=' "${prefix}config/$config"; then > continue > fi > > Which means that if you explicitly specify the flavor, it will change > even fragmented configs. This makes perfect sense for --flavor vanilla, > but --flavor default is probably not explicit enough. That the option > disappeared when Jeff ran run_oldconfig.sh is correct, because it was > redundant. I didn't specify the flavor. Or maybe I ran run_oldconfig.sh multiple times. That makes any difference? Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============8480299839066893306==-- From mmarek@suse.com Tue Apr 25 08:20:12 2017 From: Michal Marek To: kernel@lists.opensuse.org Subject: Re: [opensuse-kernel] Use fragment configs for -debug and i386/default? Date: Tue, 25 Apr 2017 10:20:11 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2202145927253053840==" --===============2202145927253053840== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2017-04-24 22:21, Takashi Iwai wrote: > On Mon, 24 Apr 2017 21:51:25 +0200, > Michal Marek wrote: >> >> Dne 24.4.2017 v 17:44 Takashi Iwai napsal(a): >>> BTW, recently I noticed that config/i386/default varies unstably >>> after running run_oldconfig.sh. Some configs are turned on once, and >>> turned off at the next update, or so. Any side-effect by this >>> change...? >> >> Do you remember what command you used to change the configs in >> >> 9add1483339d ("Enable CONFIG_KXCJK1013 for Cherrytrail devices >> (boo#1034809).") > > IIRC, I just ran the usual patches/script/run_oldconfig.sh on the tree > expanded by sequence-patch. > >> The logic for run_oldconfig.sh -nco-{y,m,n} is as follows: >> >> # do not change trimmed configs unless requested >> if test -z "$set_flavor" && ! \ >> grep -q '^CONFIG_MMU=' "${prefix}config/$config"; then >> continue >> fi >> >> Which means that if you explicitly specify the flavor, it will change >> even fragmented configs. This makes perfect sense for --flavor vanilla, >> but --flavor default is probably not explicit enough. That the option >> disappeared when Jeff ran run_oldconfig.sh is correct, because it was >> redundant. > > I didn't specify the flavor. Or maybe I ran run_oldconfig.sh multiple > times. That makes any difference? Running it multiple times should not make any difference. Can you check next time you do a config update if config/i386/default changed? It should not change unless you are explicitly adding a difference from pae or if there is a version update removing options. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org --===============2202145927253053840==--