Hi,
If i enable "High Resolution Timer Support", my machine stops here at boot:
Clocksource tsc unstable (delta = -297340790165 ns)
Time: hpet clocksource has been installed.
If i disable HPET, it boots fine.
I attach my .config (with hpet enable) and my bootable dmesg.
Thanks.
--
Sorry, i put the wrong option in the last mail.
The options that freeze my machine at boot is "HPET Timer Support".
Thanks.
--
Guilherme M. Schroeder
Network Administrator
Central de Vendas Informatica LTDA
Tel.: (11) 3665-2000 Ramal: 2008
http://www.centralinf.com.br
-
To unsubscribe
7e8dec2db4f9052ed5e M include
:04 04 dfca91fe8a0b3ee7de842b4dd3451220634516f1
4c2ec00e90009d296f44f3e0b89c50e43336c6bc M kernel
[EMAIL PROTECTED]:/usr/src/linux-2.6#
Thanks.
Guilherme M. Schroeder
Network Administrator
Central de Vendas Informatica LTDA
Tel.: (11) 3665-2000 Ramal
to resolve this problem?
Thanks,
Guilherme
//io-stress.cpp
#include
#include
#include
using namespace std;
int main()
{
int i = 0;
string roller( "|/-\\" );
string sample( "*", 1024 );
ofstream ofs( "io-stress.txt" );
related to Linux?
Thanks in advance.
Guilherme
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the kernel.
Thanks in advance,
Guilherme
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
appraise mode clearly in
'enforce' mode while namespaces can set their appraise modes separatedly.
Signed-off-by: Guilherme Magalhaes
---
security/integrity/ima/ima.h | 6 +-
security/integrity/ima/ima_appraise.c | 11 +++
security/integrity/ima/ima_fs.c
completely namespace IMA. For instance,
EVM and templates per namespace are not yet covered.
Guilherme Magalhaes (11):
ima: qualify pathname in audit info record
ima: qualify pathname in audit measurement record
ima: qualify pathname in measurement file
ima: add support to namespace securityfs
() functions.
Signed-off-by: Guilherme Magalhaes
---
security/integrity/ima/ima.h | 17 +++---
security/integrity/ima/ima_api.c | 6 +-
security/integrity/ima/ima_appraise.c | 21 +--
security/integrity/ima/ima_fs.c | 26 ++---
security/integrity/ima/ima_init.c
and later reused by a different namespace.
Signed-off-by: Guilherme Magalhaes
---
security/integrity/integrity_audit.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/security/integrity/integrity_audit.c
b/security/integrity/integrity_audit.c
index 90987d1..e675e42 100644
--- a/security
: Guilherme Magalhaes
---
security/integrity/ima/Kconfig| 8
security/integrity/ima/ima.h | 12 ++
security/integrity/ima/ima_template.c | 10 -
security/integrity/ima/ima_template_lib.c | 70 +++
security/integrity/ima
different namespace.
Signed-off-by: Guilherme Magalhaes
---
security/integrity/ima/ima_api.c | 8
1 file changed, 8 insertions(+)
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index c2edba8..b05c1fd 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security
When policy file is written and write-once is enabled, the policy file
must be deleted. Select the namespace policy structure to get the correct
policy file descriptor.
Signed-off-by: Guilherme Magalhaes
---
security/integrity/ima/ima_fs.c | 27 +--
1 file changed, 25
this interface, there is no need to give visibility for the securityfs
inside mount namespaces or containers in userspace.
Signed-off-by: Guilherme Magalhaes
---
security/integrity/ima/ima.h| 4 +
security/integrity/ima/ima_fs.c | 183
2 files
id from the current context.
Signed-off-by: Guilherme Magalhaes
---
security/integrity/ima/ima.h| 37 +
security/integrity/ima/ima_fs.c | 79 ++---
security/integrity/ima/ima_init.c | 2 +
security/integrity/ima/ima_policy.c | 29
The initial namespace policy is set through the existent interface
in the ima/policy securityfs file. Block the initial namespace
id when it is written to the ima/namespace securityfs file.
Signed-off-by: Guilherme Magalhaes
---
security/integrity/ima/ima_fs.c | 18 ++
1 file
Release all namespace IMA policy resources when the mount namespace is
released.
This is the suggested mechanism to release namespace policy resources,
but we still can discuss other methods to avoid cross-component changes.
Signed-off-by: Guilherme Magalhaes
---
fs/namespace.c
ima_initial_namespace_policy.
If the given namespace has not yet defined a private IMA policy, the IMA
policy for that namespace falls back to the initial IMA policy by using
ima_initial_namespace_policy.
Signed-off-by: Guilherme Magalhaes
---
security/integrity/ima/ima.h| 6 ++
security
On Fri, Oct 12, 2018 at 12:57 PM Dmitry Safonov wrote:
>
> Hi Guilherme,
>
> Just to let you know - I've done with more urgent issues now,
> so I'll be back on this patch on Monday, installing qemu-system-hppa
> and debugging the root case.
>
> Thanks,
> D
On Wed, Jul 17, 2024 at 12:31:47PM -0400, Steven Rostedt wrote:
> On Wed, 17 Jul 2024 09:27:58 -0700
> Namhyung Kim wrote:
>
> > Hello,
> >
> > On Fri, Jul 12, 2024 at 12:45 PM Guilherme Amadio wrote:
> > >
> > > Hi Namhyung, Arnaldo,
> > &
No problem. In a previous patch I had one for each item, but I thought
it could be packed in a single one - and avoid '[PATCH n/m]'.
Thanks.
On 3/12/19, Dan Carpenter wrote:
> On Tue, Mar 12, 2019 at 11:39:13AM -0300, Guilherme T Maeoka wrote:
>> From: Guilherme T Maeoka
>
Thanks a lot Bjorn! I confess except for PPC64 Server machines, I
never saw other "domains" or segments. Is it common in x86 to have
that? The early_quirks() are restricted to the first segment, no
matter how many host bridges we have in segment ?
Thanks again!
Thank you Vincent, much appreciated! I'll respond in the patch thread,
hopefully we can get that included in 5.4.y .
Cheers,
Guilherme
;ing your approach totally, but I think a bit more consideration is
needed in the ranges, at least accounting the number of devices of the
machine or something like that.
Cheers,
Guilherme
[0] https://salsa.debian.org/debian/makedumpfile/-/merge_requests/7
[1] Minimal as having a reduced initrd + "shrinking" parameters (like
nr_cpus=1).
Hi Ashish, non-technical comment: in the subject, you might want to
s/SWIOTBL/SWIOTLB .
cheers,
Guilherme
Thank you for the clarification Bjorn! I was on vacation..sorry for my delay.
Closing the loop here, I understand we're not getting this patch
merged (due to its restriction to domain 0) and there was a suggestion
in the thread of trying to block MSIs from the IOMMU init code (which
also have the
reason it failed with ftrace_size.
Apologies for the inconvenience!
Cheers,
Guilherme
Hi Dave and Kairui, thanks for your responses! OK, if that makes sense
to you I'm fine with it. I'd just recommend to test recent kernels in
multiple distros with the minimum "range" to see if 64M is enough for
crashkernel, maybe we'd need to bump that.
Cheers,
Guilherme
tem.
Even in initrd-only approaches, we could have sysctl.conf being copied
to initramfs, and hugepages end-up getting set.
Also, I don't think the "nohugepages" is useful only for kdump - I
found odd we cannot prevent the creation of hugepages at all when
using sysfs writes.
Cheers,
Guilherme
kdump, so I don't think we should rely
on "rootfs kdump is wrong" to refuse this patch's idea. If so, we
should then formalize the right way of kdumping.
Of course, this is only my opinion, let's see what people think about it!
Thanks,
Guilherme
On Mon, Oct 1, 2018 at 12:50 PM Arnd Bergmann wrote:
>
> Hi Guilherme,
>
> I think what happened is that nobody felt responsible for picking
> it up. The patch was sent 'to: linux-kernel@vger.kernel.org'
> with a number of people in Cc but nobody listed as a rec
> > > for the tag - I couldn't find it in LKML heheh
> > >
> > > Oh, if you can CC me in future spins of this patch (in case there
> > > any),
> > > I'd really be glad.
>
> Sure, will enlarge Cc list ;)
>
Thanks again!
Cheers,
Guilherme
Great catch Colin, thanks!
Feel free to add my:
Reviewed-by: Guilherme G. Piccoli
P.S. Not sure if it's only me, but the diff is soo much easier to
read when git is set to use patience diff algorithm:
https://termbin.com/f8ig
iggered is interesting, at least for some users. What if
we add that as a per-node stat in zoneinfo?
Cheers,
Guilherme
[0] lore.kernel.org/kvm/20200427141816.16703-1-eespo...@redhat.com
thing? I'm saying
that because kernel mm subsystem statistics seem pretty.."comfortable"
the way they are, in files like vmstat, zoneinfo, etc. Let me know
your thoughts on this, if I could work on that or should wait statsfs.
Thanks,
Guilherme
On Mon, Aug 17, 2020 at 2:05 PM Greg KH wrote:
>
> On Mon, Aug 17, 2020 at 01:59:00PM -0300, Guilherme G. Piccoli wrote:
> > On 17/08/2020 13:49, Greg KH wrote:
> > > [...]
> > >> I'm sorry, I hoped the subject + thread would suffice heh
> > >
>
r your case? No. The APIC cannot be protected against rogue MSIs. The
> only cure is to disable interrupts or disable MSIs on all PCI[E] devices
> early on. Disabling interrupts is not so much of an option obviously :)
Great to know that, we imagined if it would be possible to have a more
"
ump, that eventually was narrowed to a buggy NIC FW
flooding IRQs in kdump kernel, and no messages showed (although kernel
changed a lot since that time, today we might have better IRQ
handling/warning). We tried an early-boot fix, by disabling MSIs (as
per PCI spec) early in x86 boot, bu
On Mon, Oct 26, 2020 at 4:59 PM Thomas Gleixner wrote:
>
> On Mon, Oct 26 2020 at 12:06, Guilherme Piccoli wrote:
> > On Sun, Oct 25, 2020 at 8:12 AM Pingfan Liu wrote:
> >
> > Some time ago (2 years) we faced a similar issue in x86-64, a hard to
> > debug problem
On Mon, Nov 16, 2020 at 6:45 PM Eric W. Biederman wrote:
> The way to do that would be to collect the set of pci devices when the
> kexec on panic kernel is loaded, not during crash_kexec. If someone
> performs a device hotplug they would need to reload the kexec on panic
> kernel.
>
> I am not n
cer machine we
had 3 parents in the PCI tree (as per lspci -t), :00, :ff and
:80 - are those all under "segment 0" as per your verbiage? In our
case the troublemaker was under :80, and the early_quirks() shut
the device up successfully.
Thanks,
Guilherme
Thanks Vlastimil! I agree with you..it's a good new behavior to report
that case, I guess.
Cheers,
Guilherme
On Tue, Jun 16, 2020 at 5:02 AM Vlastimil Babka wrote:
>
> On 6/16/20 9:38 AM, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed the follo
case here) ?
Cheers,
Guilherme
On Mon, May 18, 2020 at 9:54 AM Enderborg, Peter
wrote:
> Usually change existing causes confusion. It should not be a problem but it
> happen.
>
I am sorry, but I really didn't understand your statement, can you be
more specific?
Thanks again!
John,
Boot ok with clocksource=acpi_pm and HPET enabled.
Any clue?
john stultz wrote:
On 4/19/07, guilherme <[EMAIL PROTECTED]> wrote:
Hi,
If i enable "High Resolution Timer Support", my machine stops here at
boot:
Clocksource tsc unstable (delta = -297340790165 ns)
Time:
so
I've added a DMI blacklist against his system so the HPET is not used.
Many thanks to Guilherme for the slow and laborious testing that finally
narrowed down this issue.
Before going to hard to maintain DMI black lists we should first check
if it's a more general problem and can't it
John,
Just a doubt, you want me to test the patch with dynticks disabled?
Guilherme M. Schroeder
Network Administrator
Central de Vendas Informatica LTDA
Tel.: (11) 3665-2000 Ramal: 2008
http://www.centralinf.com.br
john stultz wrote:
On Mon, 2007-04-23 at 15:30 -0700, john stultz wrote:
On
John,
The dynticks doesn't affect HPET here at all. The machine freeze with or
w/o dynticks.
Gonna try the patch and i tell you.
Guilherme M. Schroeder
Network Administrator
Central de Vendas Informatica LTDA
Tel.: (11) 3665-2000 Ramal: 2008
http://www.centralinf.com.br
john stultz
John,
Removing the three lines doesn't help too. It just boot ok with
clocksource=acpi_pm.
Guilherme M. Schroeder
Network Administrator
Central de Vendas Informatica LTDA
Tel.: (11) 3665-2000 Ramal: 2008
http://www.centralinf.com.br
john stultz wrote:
On Mon, 2007-04-23 at 15:30
-device basis. The patch
> proposed will PERST top level PHBs which will propagate as hot reset
> down switches, not 100% PERST but still useful.
>
Exactly, this reset happens on early arch stage of PCI initialization,
not trivial to drivers perform it.
Anyway, let me know if you want a V2 with improvements or to drop it..I
still see use cases for this.
Thanks,
Guilherme
> Cheers,
> Ben.
>
V2 just sent to linuxppc-dev[0] list, with some simplifications.
This one is then officially dropped!
Thanks,
Guilherme
[0] http://patchwork.ozlabs.org/patch/830320
hanks for the fixes Gimcuan!
For the entire series:
Acked-by: Guilherme G. Piccoli
Hi, thanks Dmitry for the re-spin - hopefully now the pa-risc issues
are fixed.
BTW, any news on the pa-risc testing? We're just waiting on this to get
the patchset merged?
Thanks in advance,
Guilherme
efully this time the series gets merged
in Linus tree and we have the fix for this long-standing issue.
Cheers,
Guilherme
Thanks Steve, re-tested in my VM and it's working fine.
Just a minor below...
On 13/06/2024 12:55, Steven Rostedt wrote:
> [...]
> + D. Using a region of memory reserved via ``reserve_mem`` command line
> +parameter. The address and size will be defined by the ``reserve_mem``
> +parameter
On 13/06/2024 15:42, Steven Rostedt wrote:
> On Thu, 13 Jun 2024 15:19:50 -0300
> "Guilherme G. Piccoli" wrote:
>
>>> +
>>> + reserver_mem=2M:4096:oops ramoops.mem_name=oops
>>> +
>>
>> Likely this could be fixed on merge, to avoi
From: Guilherme T Maeoka
Fix coding style errors and warns complained by checkpatck.pl. To list:
- remove braces for single statements blocks,
- add space required around operators,
- replace spaces with tabs to indent,
- add blank line after declarations
From: Guilherme T Maeoka
Change 'if (a)' to 'if (!a)' and return. Otherwise, continue with
the previouly wrapped block of control. This reduces the indentation
level by 2 and 1.
I'm not if this commit contributes to the coding style.
Signed-off-by: Guilherme T Mae
I'm afraid in suggesting such backport to 5.4
and introduce complex-to-debug issues.
Let me know your thoughts Vincent (and all CCed), thanks in advance.
Cheers,
Guilherme
P.S. For those that deleted this thread from the email client, here's a
link:
https://lore.kernel.org/lkml/20200513
On 19/11/2020 05:36, Vincent Guittot wrote:
> On Thu, 19 Nov 2020 at 01:36, Tao Zhou wrote:
>>
>> On Thu, Nov 19, 2020 at 07:50:15AM +0800, Tao Zhou wrote:
>>> On Wed, Nov 18, 2020 at 07:56:38PM -0300, Guilherme G. Piccoli wrote:
>>>> Hi Vincent (and all
hereby proposed
ended-up being implemented in another patch, I appreciate a lot.
Thanks in advance! Below, some references to lore archives.
Cheers,
Guilherme
References:
This V7 link:
https://lore.kernel.org/linux-pci/546d346644654915877365b19ea534378db0894d.1602788209.git.sathyanarayanan.k
Any guidance you can provide me is much appreciated.
Thanks in advance,
Guilherme
On 04/30/2016 07:13 AM, Minfei Huang wrote:
Ping.
Any comment is appreciate.
Hi Minfei, I guess a good idea would be to resend the patch with the
typo fixed, as a v2 patch. What do you think?
Cheers,
Guilherme
Thanks
Minfei
On 04/25/16 at 11:13P, Minfei Huang wrote:
It's
l.error) {
> + ret = vfla->hdl.error;
> + goto err_free_vfla;
> + }
> +
> + /* Initialize ved and sd */
> + ret = vimc_ent_sd_register(&vfla->ved, &vfla->sd, v4l2_dev,
> + vcfg_name,
> + MEDIA_ENT_F_FLASH, 0, NULL,
> + NULL, &vimc_fla_ops);
> + if (ret)
> + goto err_free_hdl;
> +
> + /* Initialize standard values */
> + vfla->indicator_intensity = 0;
> + vfla->torch_intensity = 0;
> + vfla->flash_intensity = 0;
> + vfla->is_strobe = false;
> + vfla->timeout = 0;
> + vfla->last_strobe = 0;
> + vfla->led_mode = V4L2_FLASH_LED_MODE_NONE;
> +
> + return &vfla->ved;
> +
> +err_free_hdl:
> + v4l2_ctrl_handler_free(&vfla->hdl);
> +err_free_vfla:
> + kfree(vfla);
> +
> + return NULL;
> +}
> +
> +void vimc_fla_rm(struct vimc_device *vimc, struct vimc_ent_device *ved)
> +{
> + struct vimc_fla_device *vfla;
> +
> + if (!ved)
> + return;
> +
> + vfla = container_of(ved, struct vimc_fla_device, ved);
> + vimc_ent_sd_unregister(ved, &vfla->sd);
> +}
> --
> 2.23.0
>
>
> ___
> Lkcamp mailing list
> lkc...@lists.libreplanetbr.org
> https://lists.libreplanetbr.org/mailman/listinfo/lkcamp
Regards,
Guilherme
at. We can
even have kdump scripts removing the kernel command-line options to
set hugepages, but it's not straightforward to prevent sysctl/sysfs
configuration, given it happens in later boot or anytime when the
system is running.
Signed-off-by: Guilherme G. Piccoli
---
About some decision
t/useful not only for kdump - it
is a legitimate way of disabling hugepages, something we don't currently
have on kernel. I'll submit a V2, for Ubuntu kdump specially this is
quite helpful!
Cheers,
Guilherme
at. We can
even have kdump scripts removing the kernel command-line options to
set hugepages, but it's not straightforward to prevent sysctl/sysfs
configuration, given it happens in later boot or anytime when the
system is running.
Signed-off-by: Guilherme G. Piccoli
---
.../admin-guide/k
n that say it's wrong to do this way -
although I agree initrd-only approach is more safe. But since Ubuntu
kdump rely on rootfs mount, we couldn't find a way to effectively
prevent the creation of hugepages completely, hence we tried to
introduce one.
Cheers,
Guilherme
On 10/15/19 11:05 AM, Michal Hocko wrote:
On Tue 15-10-19 10:58:36, Guilherme G. Piccoli wrote:
On 10/15/19 9:18 AM, Michal Hocko wrote:
I do agree with Qian Cai here. Kdump kernel requires a very tailored
environment considering it is running in a very restricted
configuration. The hugetlb
Fix some space required coding style.
Signed-off-by: Guilherme Tadashi Maeoka
---
drivers/staging/mt7621-pci/pci-mt7621.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 31310b6fb7db
Hi David, was there any respin for this patch? I couldn't find it upstream.
This message shows a lot in the xfstests against cifs.
Thanks in advance,
Guilherme
Place a constant on the right side of the test.
Signed-off-by: Guilherme Tadashi Maeoka
---
drivers/staging/rtl8723bs/os_dep/osdep_service.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/osdep_service.c
b/drivers/staging/rtl8723bs
Fix multiple space required coding style.
Signed-off-by: Guilherme Tadashi Maeoka
---
.../staging/rtl8723bs/os_dep/osdep_service.c | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/osdep_service.c
b/drivers/staging
Fix space around operators, pointer definition, constant on the right
side, assignment outside of if condition and else to follow close brace
at staging: rtl8723bs: os_dep.
Guilherme Tadashi Maeoka (5):
Staging: rtl8723bs: os_dep: Fix assignment in if condition
Staging: rtl8723bs: os_dep: Fix
Fix an assignment in if condition.
Signed-off-by: Guilherme Tadashi Maeoka
---
drivers/staging/rtl8723bs/os_dep/osdep_service.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/osdep_service.c
b/drivers/staging/rtl8723bs/os_dep
Fix else not following close brace '}'.
Signed-off-by: Guilherme Tadashi Maeoka
---
drivers/staging/rtl8723bs/os_dep/osdep_service.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/osdep_service.c
b/drivers/staging/rtl872
Pointer definition "foo * bar" should be "foo *bar".
Signed-off-by: Guilherme Tadashi Maeoka
---
drivers/staging/rtl8723bs/os_dep/osdep_service.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/osdep_service.c
b/drive
Thank you for the review Joe. I'll have that in mind in the next patch.
On 3/9/19, Joe Perches wrote:
> On Sat, 2019-03-09 at 15:30 -0300, Guilherme Tadashi Maeoka wrote:
>> Fix an assignment in if condition.
>>
>> Signed-off-by: Guilherme Tadashi Maeoka
>> -
On 05/02/2018 11:13, Guilherme G. Piccoli wrote:
> On 05/02/2018 11:10, Mauro S. M. Rodrigues wrote:
>> Guilherme is no longer available to maintain the driver. I'll assume his
>> position for now on.
>>
>> Signed-off-by: Mauro S. M. Rodrigues
>
> Thanks a
On 01/10/2018 15:32, Guilherme G. Piccoli wrote:
> Hi Dmitry, thanks for the patch. It's very promising, we have some
> reports of this issue and I'm building a kernel with this patch in
> order the reporter can test it. But based in the previous feedback,
> this seems to
e have 128 online cpus, 8 per core (meaning 16 cores) and
64 vecs, I guess would be ideal to distribute 4 vecs _per core_, leaving
4 CPUs in each core without vecs.
Makes sense for you?
Thanks,
Guilherme
+int irq_create_affinity_mask(struct cpumask **affinity_mask,
+ unsigned
Thanks for the responses Bart and Christoph.
On 06/15/2016 07:10 AM, Christoph Hellwig wrote:
On Tue, Jun 14, 2016 at 06:54:22PM -0300, Guilherme G. Piccoli wrote:
On 06/14/2016 04:58 PM, Christoph Hellwig wrote:
This is lifted from the blk-mq code and adopted to use the affinity mask
leted 4096 of 4096 bytes
> [...] sd 0:0:0:0: [sda] tag#0 8 sectors total, 3072 bytes done.
> [...] sd 0:0:0:0: [sda] tag#0 checking 3072 bytes for alignment
> (sector size 4096, remainder 3072, resid 1024)
> [...] sd 0:0:0:0: [sda] tag#0 sd_done: completed
ve _more_ nodes than vectors.
Fixes: 34c3d9819fda ("genirq/affinity: Provide smarter irq spreading
infrastructure")
Reported-by: Gabriel Krisman Bertazi
Signed-off-by: Guilherme G. Piccoli
Cc: sta...@vger.kernel.org # v4.9+
Cc: Christoph Hellwig
Cc: linuxppc-...@lists.ozlabs.org
brackets is outright wrong. See:
> https://marc.info/?l=linux-kernel&m=147351236615103
>
> I'll fix that up when applying the patch.
>
> Thanks,
>
> tglx
>
Thanks you all very much for the reviews and comments - lesson learned
about the brackets in multi-line if/for statements!
Thanks for fixing it Thomas.
Cheers,
Guilherme
Patch is fine - minor typo: interrut => interrupt
Feel free to add my:
Tested-by: Guilherme G. Piccoli
Thanks,
Guilherme
> ---
> arch/powerpc/xmon/xmon.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmo
>
> I don't think this is right.
>
> xmon_off is only true if you boot with xmon=off on the command line.
>
> So if you boot with CONFIG_XMON_DEFAULT=n, and nothing on the command
> line, then enter xmon via sysrq, then exit, xmon will still be enabled.
>
Agreed, noticed it after some work in V2 of my patch. I'm addressing it
there, so maybe no harm in keeping this way here..
Thanks,
Guilherme
> cheers
>
ot, which we do not
>> want to do.
>>
> Although it is not often that kernel got stucked during boot. Yes, the
> behavior changed anyway. Will fix that in v3.
Pan/Michael, I'm working my patches on top of Pan's. So, I sent his V2
on my series, as patch #1.
Guess the workflow is better/easier if we can work the patches on the
series exclusively, since each time Pan's patch is changed, I need to
refactor my patches.
Pan, if possible send your V3 to me, I'll refactor my series on top of
it and send again on the list. Or if you or Michael have better
suggestions of workflow, let me know.
Thanks,
Guilherme
>
>> cheers
>>
>
Hi Jan and all involved here, I'd like to know if there was any news on
this patch - seems users are still facing this issue on AMD systems.
Thanks in advance,
Guilherme
On 17/08/2020 13:21, Greg KH wrote:
> On Mon, Aug 17, 2020 at 12:36:25PM -0300, Guilherme G. Piccoli wrote:
>> Hi Greg / Thomas and all involved here. First, apologies for
>> necro-bumping this thread, but I'm working a backport of this patch to
>> kernel 4.15 (Ubuntu)
On 17/08/2020 13:49, Greg KH wrote:
> [...]
>> I'm sorry, I hoped the subject + thread would suffice heh
>
> There is no thread here :(
>
Wow, that's odd. I've sent with In-Reply-To, I'd expect it'd get
threaded with the original message. Looking in lore archive [1], it
seems my first message wa
we have a special reason to not have it on long-term stables, like 4.9
or 4.14. It's a subtle portion of arch code, so I'm afraid I didn't see
something that prevents its backport for previous versions.
Thanks in advance,
Guilherme
;sti' executes, without relying in
early_quirks(). ACPI maybe? As per Bjorn comment when explaining the
limitations of early_quirks(), this problem seems not to be trivial.
I'm a bit against doing that in crash_kexec() for the reasons mentioned
in the thread, specially by Thomas and Eric - but if there's no other
way...maybe this is the way to go.
Cheers,
Guilherme
P.S. Fixed Gavin's bouncing address, sorry for that.
On 23/10/2018 14:03, Bjorn Helgaas wrote:
> On Mon, Oct 22, 2018 at 05:35:06PM -0300, Guilherme G. Piccoli wrote:
>> On 18/10/2018 19:15, Bjorn Helgaas wrote:
>>> On Thu, Oct 18, 2018 at 03:37:19PM -0300, Guilherme G. Piccoli wrote:
>>> [...]
>> I understan
On Tue, Sep 22, 2020 at 11:53 AM wrote:
>
>
> On 9/22/20 6:58 AM, Philipp Rudo wrote:
> >
> > AFAIK pstore requires UEFI to work. So what's the point to enable it on
> > non-UEFI
> > systems?
>
>
> I don't think UEFI is required, ERST can specify its own backend. And that,
> in fact, can be quit
ously converted hung_task_panic
(see the patch series [0]) and put the alias table in alphabetical order.
[0] lore.kernel.org/lkml/20200427180433.7029-1-vba...@suse.cz
Signed-off-by: Guilherme G. Piccoli
---
This patch is based on linux-next/akpm branch, at d0f3f6070c3a. Thanks
in advance for re
aches.
Signed-off-by: Guilherme G. Piccoli
---
This patch was based on linux-next/akpm branch, at d0f3f6070c3a.
Thanks in advance for reviews!
Cheers,
Guilherme
mm/compaction.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
the problem we are trying to solve was more
like...admin forgot if they triggered or not the compaction hehe
So, counting on the user to keep track of it is what I'd like to
avoid. And thinking about drop_caches (that have an indication when
triggered) makes me think this indeed does make sense for compaction
too.
Cheers,
Guilherme
nty of sysctls, but not all of them have identical/duplicate
boot params, so I went with the obvious ones, that I use more.
Cheers,
Guilherme
Gabriel won't maintain this driver anymore. So, I'll maintain it
with Frank.
Thanks Gabriel for all your work on genwqe.
Signed-off-by: Guilherme G. Piccoli
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f7
1 - 100 of 121 matches
Mail list logo
