On Tue 28-08-18 10:07:34, Michal Hocko wrote:
> On Tue 28-08-18 09:32:11, Michal Hocko wrote:
> > [my previous email to the mailing list got stuck waiting for moderator
> > so I am changing my From to suse.cz]
> >
> > On Tue 28-08-18 08:52:58, Stefan Priebe - Profihost AG wrote:
> > > Hi,
> > >
> > > Am 28.08.2018 um 08:25 schrieb Michal Hocko:
> > > > On Sat 25-08-18 09:54:34, Stefan Priebe - Profihost AG wrote:
> > > >> Hello,
> > > >>
> > > >> not sure if related but since upgrading from Kernel 4.4 to 4.12 based
> > > >> SLES15 kernel i had two times the following traces while the system was
> > > >> nearly unusable:
> > > >> [245513.362669] kvm: page allocation stalls for 194572ms, order:9,
> > > >> mode:0x4740ca(__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE|__GFP_MOVABLE|__GFP_DIRECT_RECLAIM),
> > > >> nodemask=(null)
> > > >
> > > > This is an THP allocation and from __GFP_DIRECT_RECLAIM I assume it is
> > > > within MADV_HUGEPAGE mapping. What is your defrag setting?
> > > > cat /sys/kernel/mm/transparent_hugepage/defrag
> > > >
> > > > spending 194s reclaiming/compacting is definitely way too much for THP.
> > > > This looks like an issue reported by Andrea recently
> > > > http://lkml.kernel.org/r/20180820032204.9591-1-aarcange@redhat.com
> > > >
> > > > We do not have a proper solution for these pathological cases yet
> > > > though.
> > >
> > > Yes this sounds pretty much exactly the issue i'm seeing on multiple kvm
> > > hosts. So this is a regression in SLES15?
> >
> > Well, spending so much time in the allocation is clearly undesirable.
> > >
> > > # cat /sys/kernel/mm/transparent_hugepage/defrag
> > > always defer defer+madvise [madvise] never
> >
> > OK, so the immediate workaround would be to weaken the defrag mode to
> > defer. You will likely not get as many THP but stalls should be gone.
> >
> > If you are brave enough and willing to play a bit then you can try to
> > apply the patch I was proposing https://marc.info/?l=linux-mm&m=153493606221018.
> > I guess we will end up with a different solution in the end but seeing
> > how this behaves if you have a workload which triggers the bad behavior
> > would be valuable.
>
> Hold on. I was thinking about this some more and will have a better
> patch for you yo play with.
Moved to the upstream discussion http://lkml.kernel.org/r/20180828081837.GG10223@dhcp22.suse.cz
--
Michal Hocko
SUSE Labs
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Hi,
Am 28.08.2018 um 08:25 schrieb Michal Hocko:
> On Sat 25-08-18 09:54:34, Stefan Priebe - Profihost AG wrote:
>> Hello,
>>
>> not sure if related but since upgrading from Kernel 4.4 to 4.12 based
>> SLES15 kernel i had two times the following traces while the system was
>> nearly unusable:
>> [245513.362669] kvm: page allocation stalls for 194572ms, order:9,
>> mode:0x4740ca(__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE|__GFP_MOVABLE|__GFP_DIRECT_RECLAIM),
>> nodemask=(null)
>
> This is an THP allocation and from __GFP_DIRECT_RECLAIM I assume it is
> within MADV_HUGEPAGE mapping. What is your defrag setting?
> cat /sys/kernel/mm/transparent_hugepage/defrag
>
> spending 194s reclaiming/compacting is definitely way too much for THP.
> This looks like an issue reported by Andrea recently
> http://lkml.kernel.org/r/20180820032204.9591-1-aarcange@redhat.com
>
> We do not have a proper solution for these pathological cases yet
> though.
Yes this sounds pretty much exactly the issue i'm seeing on multiple kvm
hosts. So this is a regression in SLES15?
# cat /sys/kernel/mm/transparent_hugepage/defrag
always defer defer+madvise [madvise] never
Greets,
Stefan
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Hey
Anyone compiled and booted successfully a device tree for PI3 arm64?
I cloned https://github.com/openSUSE/kernel.git
and branched out from 4.14-rc3 , compiled and booted a kernel and
modules. The original kernel of this PI3
is 4.14.0-3-arm64.
Now, I try to replace the device tree bcm2837-rpi-3-b.dtb with this
one I compiled, but
the pi refuses to boot.
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Hi,
in an attempt to provide exfat-nofuse kmp for a number of our kernels[1][2], I
noticed, that the signature deliberately of blockdev_direct_IO() changed
between v4.4 and v4.4.140:
4.4:
static inline ssize_t blockdev_direct_IO(struct kiocb *iocb,
struct inode *inode,
struct iov_iter *iter, loff_t offset,
get_block_t get_block)
4.4.140:
static inline ssize_t blockdev_direct_IO(struct kiocb *iocb,
struct inode *inode,
struct iov_iter *iter,
get_block_t get_block)
You might notice, 4.4.140 lost the offset argument. Apart from being hard to
imagine, how this argument became obsolete, and given, that it reappeared for
v4.5, that reveals 2 questions:
* Doesn't this violate the rules of kernel sublevel updates?
* How can I investigate, at which point this version got lost?
In other words, is there a git tree, that happens to carry *all* sublevel
updates (Greg's tree?), where I can git blame include/linux/fs.h and is this
something to be expected?
Thanks for your patience.
Cheers,
Pete
[1] https://build.opensuse.org/package/show/home:frispete:kernel/exfat-nofuse
[2] https://github.com/frispete/exfat-nofuse
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Hi,
could some kind soul briefly elaborate, what's the business of referencing
bnc#1012628 everywhere in Kernel:stable changelogs.
E.g.:
-------------------------------------------------------------------
Thu Aug 9 14:44:18 CEST 2018 - jslaby(a)suse.cz
- Linux 4.17.14 (bnc#1012628).
- jfs: Fix inconsistency between memory allocation and
ea_buf->max_size (bnc#1012628).
- xfs: validate cached inodes are free when allocated
(bnc#1012628).
- xfs: don't call xfs_da_shrink_inode with NULL bp (bnc#1012628).
- Partially revert "block: fail op_is_write() requests to
read-only partitions" (bnc#1012628).
- Btrfs: fix file data corruption after cloning a range and fsync
(bnc#1012628).
- i2c: imx: Fix reinit_completion() use (bnc#1012628).
- ring_buffer: tracing: Inherit the tracing setting to next ring
buffer (bnc#1012628).
- netlink: Don't shift on 64 for ngroups (bnc#1012628).
- nohz: Fix missing tick reprogram when interrupting an inline
softirq (bnc#1012628).
- nohz: Fix local_timer_softirq_pending() (bnc#1012628).
- perf/x86/intel/uncore: Fix hardcoded index of Broadwell extra
PCI devices (bnc#1012628).
- genirq: Make force irq threading setup more robust
(bnc#1012628).
- jfs: Fix usercopy whitelist for inline inode data (bnc#1012628).
- scsi: qla2xxx: Return error when TMF returns (bnc#1012628).
- scsi: qla2xxx: Fix ISP recovery on unload (bnc#1012628).
- scsi: qla2xxx: Fix driver unload by shutting down chip
(bnc#1012628).
- scsi: qla2xxx: Fix NPIV deletion by calling
wait_for_sess_deletion (bnc#1012628).
- scsi: qla2xxx: Fix unintialized List head crash (bnc#1012628).
- commit dc49b43
Sure, bnc#1012628 should track any tw kernel changes, but was closed in
10/2017 with no tracking ever got there..
Cheers,
Pete
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org
Hi,
I have my kid's laptop (Asus W202N) where I have installed leap 15.0
Everything works except the SD card reader.
When I insert a sd card I got this output in the journal:
Aug 09 20:23:36 star kernel: usb 2-6: new SuperSpeed USB device number 7 using xhci_hcd
Aug 09 20:23:36 star kernel: usb 2-6: New USB device found, idVendor=05e3, idProduct=0747
Aug 09 20:23:36 star kernel: usb 2-6: New USB device strings: Mfr=3, Product=4, SerialNumber=5
Aug 09 20:23:36 star kernel: usb 2-6: Product: USB Storage
Aug 09 20:23:36 star kernel: usb 2-6: Manufacturer: Generic
Aug 09 20:23:36 star kernel: usb 2-6: SerialNumber: 000000000819
Aug 09 20:23:36 star kernel: usb-storage 2-6:1.0: USB Mass Storage device detected
Aug 09 20:23:36 star kernel: scsi host1: usb-storage 2-6:1.0
Aug 09 20:23:36 star mtp-probe[5135]: checking bus 2, device 7: "/sys/devices/pci0000:00/0000:00:15.0/usb2/2-6"
Aug 09 20:23:36 star mtp-probe[5135]: bus: 2, device: 7 was not an MTP device
Aug 09 20:23:37 star kernel: scsi 1:0:0:0: Direct-Access Generic STORAGE DEVICE 0819 PQ: 0 ANSI: 6
Aug 09 20:23:37 star kernel: sd 1:0:0:0: Attached scsi generic sg0 type 0
Aug 09 20:23:57 star kernel: sd 1:0:0:0: [sda] Spinning up disk...
Aug 09 20:24:04 star kernel: .
Aug 09 20:24:04 star kernel: sd 1:0:0:0: [sda] Attached SCSI removable disk
But the partitions on the card are not recognized and cannot be accessed.
The issue exists with the 4.12 kernel but also with kernel 4.17 and 4.18-rc8.
This could be a kernel/driver problem, but (I hope) it can also be a module problem.
In the past I had a sd card issue with an Acer Aspire R11
(bug 998440) for which the solution was to add a module in the initrd.
Can anyone point me in the right direction about how to fix my problem?
Here are more details about the hardware:
lspci -n -n :
00:00.0 Host bridge [0600]: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Host Bridge [8086:5af0] (rev 0b)
00:00.1 Signal processing controller [1180]: Intel Corporation Device [8086:5a8c] (rev 0b)
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:5a85] (rev 0b)
00:0e.0 Audio device [0403]: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster [8086:5a98] (rev 0b)
00:0f.0 Communication controller [0780]: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Trusted Execution Engine [8086:5a9a] (rev 0b)
00:12.0 SATA controller [0106]: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SATA AHCI Controller [8086:5ae3] (rev 0b)
00:13.0 PCI bridge [0604]: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #2 [8086:5ad9] (rev fb)
00:15.0 USB controller [0c03]: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series USB xHCI [8086:5aa8] (rev 0b)
00:17.0 Signal processing controller [1180]: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series I2C Controller #5 [8086:5ab4] (rev 0b)
00:1c.0 SD Host controller [0805]: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series eMMC Controller [8086:5acc] (rev 0b)
00:1f.0 ISA bridge [0601]: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Low Pin Count Interface [8086:5ae8] (rev 0b)
00:1f.1 SMBus [0c05]: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SMBus Controller [8086:5ad4] (rev 0b)
01:00.0 Network controller [0280]: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter [168c:0042] (rev 31)
ls /sys/bus/acpi/devices | grep INT
INT33A1:00
INT3400:00
INT3403:00
INT3403:01
INT3403:02
INT3403:03
INT3403:04
INT3403:05
INT3404:00
INT3406:00
INT3407:00
INT3409:00
INT3409:01
INT3409:02
INT3452:00
INT3452:01
INT3452:02
INT3452:03
INT34D7:00
Attached you can find the dmesg output.
Thank you for your help.
Giacomo