* On 4/16/21 7:40 AM, Masahiro Yamada wrote:
> Applied to linux-kbuild. Thanks.
Thank you for your review and input. :)
Mihai
the
starting point was n while searching down, which also lead to an
infinite loop.
OTOH, this code is now essentially all his work.
Amazingly, nobody seems to have been hit by this for 11 years - or at
the very least nobody bothered to debug and fix this.
Signed-off-by: Mihai Moldovan
---
v2: swap
* On 4/10/21 7:47 AM, Masahiro Yamada wrote:
> On Sun, Mar 28, 2021 at 6:52 PM Mihai Moldovan wrote:
>> + if ((index == -1) && (index == match_start))
>> + return -1;
>
> We know 'index' is -1 in the second comparison.
least nobody bothered to debug and fix this.
Signed-off-by: Mihai Moldovan
---
v2: swap constant in comparison to right side, as requested by
Randy Dunlap
scripts/kconfig/nconf.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
* On 3/27/21 11:26 PM, Randy Dunlap wrote:
> There is a test for it in checkpatch.pl but I also used checkpatch.pl
> without it complaining, so I don't know what it takes to make the script
> complain.
>
> if ($lead !~ /(?:$Operators|\.)\s*$/ &&
>
* On 3/27/21 4:58 PM, Randy Dunlap wrote:
> On 3/27/21 5:01 AM, Mihai Moldovan wrote:
>> +if ((-1 == index) && (index == match_start))
>
> checkpatch doesn't complain about this (and I wonder how it's missed), but
> kernel style is (mostly) "c
least nobody bothered to debug and fix this.
Signed-off-by: Mihai Moldovan
---
scripts/kconfig/nconf.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
index e0f965529166..92a5403d8afa 100644
--- a/scripts/kconfig/nconf.c
+++ b
* On 5/30/19 9:51 PM, Jon Maloy wrote:
> Make sure the following three commits are present in TIPC *after* the
> offending commit:
>
> commit 532b0f7ece4c "tipc: fix modprobe tipc failed after switch order of
> device registration"
This *is* the offending commit, as far as I understand. Merely
Hi
I've had a few issues lately (mainly bad RAM only, hopefully, which should be
fixed now) and generally upgraded everything.
With 5.1.5, though, some programs exhibited very weird behavior: Chromium
crashed while starting up due to not being able to launch a new zygote process,
albeit started
Actually, may I be seeing just another incarnation of
http://www.spinics.net/lists/netfilter-devel/msg31134.html?
If so, applying https://lkml.org/lkml/2014/3/27/294 seems appropriate.
Could anybody please confirm this?
Mihai
smime.p7s
Description: S/MIME Cryptographic Signature
Hi
earlier today, I experienced a kernel panic due to a NULL pointer dereference
somewhere in the netfilter subsystem.
Full kernel output (may contain typos):
[360412.114033] BUG: unable to handle kernel NULL pointer dereference at
0010
[360412.115643] IP: []
Hi
earlier today, I experienced a kernel panic due to a NULL pointer dereference
somewhere in the netfilter subsystem.
Full kernel output (may contain typos):
[360412.114033] BUG: unable to handle kernel NULL pointer dereference at
0010
[360412.115643] IP: [81865efe]
Actually, may I be seeing just another incarnation of
http://www.spinics.net/lists/netfilter-devel/msg31134.html?
If so, applying https://lkml.org/lkml/2014/3/27/294 seems appropriate.
Could anybody please confirm this?
Mihai
smime.p7s
Description: S/MIME Cryptographic Signature
* On 15.07.2013 01:54 AM, Mihai Moldovan wrote:
> This is obviously happening while booting and udev is loading *some* module,
> but
> I have no idea which module is affected as such.
Quick correction: actually, at that time udev hasn't even started. udev is being
started by my init
Hi all,
I'm seeing following oopses when booting up my kernel:
[3.173479] BUG: unable to handle kernel NULL pointer dereference
at (null)
[3.173602] IP: [] futex_wake+0x74/0x130
[3.173679] PGD 231d65067 PUD 231d64067 PMD 0
[3.173783] Oops: [#1] SMP
[3.173870]
Hi all,
I'm seeing following oopses when booting up my kernel:
[3.173479] BUG: unable to handle kernel NULL pointer dereference
at (null)
[3.173602] IP: [810d2f54] futex_wake+0x74/0x130
[3.173679] PGD 231d65067 PUD 231d64067 PMD 0
[3.173783] Oops: [#1] SMP
* On 15.07.2013 01:54 AM, Mihai Moldovan wrote:
This is obviously happening while booting and udev is loading *some* module,
but
I have no idea which module is affected as such.
Quick correction: actually, at that time udev hasn't even started. udev is being
started by my initramfs one good
* On 03.02.2013 03:48 PM, Ben Hutchings wrote:
> [...]
> +static void quirk_iommu_g4x_gfx(struct pci_dev *dev)
> +{
Shouldn't __devinit be used here too, like for quirk_iommu_rwbf?
It probably doesn't matter too much. especially on platforms with Intel IOMMU,
but... it makes the code coherent.
* On 03.02.2013 03:48 PM, Ben Hutchings wrote:
[...]
+static void quirk_iommu_g4x_gfx(struct pci_dev *dev)
+{
Shouldn't __devinit be used here too, like for quirk_iommu_rwbf?
It probably doesn't matter too much. especially on platforms with Intel IOMMU,
but... it makes the code coherent.
Best
Hi,
I've found yet another problem with (at least) 3.7.4 and 3.8-rc4.
When terminating hostapd via SIGINT, this bug and panic came up:
BUG: unable to handle kernel paging request at
Hi,
I've found yet another problem with (at least) 3.7.4 and 3.8-rc4.
When terminating hostapd via SIGINT, this bug and panic came up:
BUG: unable to handle kernel paging request at
* On 21.01.2013 07:11 PM, Mihai Moldovan wrote:
> I'm also currently testing a kernel without the Intel IOMMU feature
> [CONFIG_INTEL_IOMMU=n, but CONFIG_IOMMU_SUPPORT=y]. [...] At least
> not seeing USB and PCI(e) issues. I'll leave the box running for some
> more [time] [...]
* On 21.01.2013 07:11 PM, Mihai Moldovan wrote:
I'm also currently testing a kernel without the Intel IOMMU feature
[CONFIG_INTEL_IOMMU=n, but CONFIG_IOMMU_SUPPORT=y]. [...] At least
not seeing USB and PCI(e) issues. I'll leave the box running for some
more [time] [...]
No freezes for 22h
* On 20.01.2013 11:49 PM, Daniel Vetter wrote:
> Thanks for testing, I've just submitted the patch for review. It
> should included in a -fixes tree soon and the get backported to
> stable kernels.
Thanks. :)
> Please let me know when this works solidly for you, so that I can
> put it into a
* On 20.01.2013 11:49 PM, Daniel Vetter wrote:
Thanks for testing, I've just submitted the patch for review. It
should included in a -fixes tree soon and the get backported to
stable kernels.
Thanks. :)
Please let me know when this works solidly for you, so that I can
put it into a real
Hi Daniel,
the patch does work, i.e., it turns off DMAR for the graphics card and
alleviates the freezes when loading i915/kms.
However, still seeing random machine freezes with it (being consistent with the
behavior I've experienced with intel_iommu=igfx_off).
The patch + forcing RWBF is
Hi Daniel,
the patch does work, i.e., it turns off DMAR for the graphics card and
alleviates the freezes when loading i915/kms.
However, still seeing random machine freezes with it (being consistent with the
behavior I've experienced with intel_iommu=igfx_off).
The patch + forcing RWBF is
* On 19.01.2013 05:13 PM, Mihai Moldovan wrote:
> * On 19.01.2013 02:27 PM, Daniel Vetter wrote:
>> You have a gen4.5 chipset which is known to be utterly broken for
>> IOMMU+intel gpu.
> Nice description for what I'm seeing. ;)
>
> After some more hours of up
* On 19.01.2013 02:27 PM, Daniel Vetter wrote:
> You have a gen4.5 chipset which is known to be utterly broken for
> IOMMU+intel gpu.
Nice description for what I'm seeing. ;)
After some more hours of uptime I'm inclined to say, that "intel_iommu=off
iommu=off" fixes my random freezes as well.
* On 19.01.2013 02:27 PM, Daniel Vetter wrote:
You have a gen4.5 chipset which is known to be utterly broken for
IOMMU+intel gpu.
Nice description for what I'm seeing. ;)
After some more hours of uptime I'm inclined to say, that intel_iommu=off
iommu=off fixes my random freezes as well.
Alas,
* On 19.01.2013 05:13 PM, Mihai Moldovan wrote:
* On 19.01.2013 02:27 PM, Daniel Vetter wrote:
You have a gen4.5 chipset which is known to be utterly broken for
IOMMU+intel gpu.
Nice description for what I'm seeing. ;)
After some more hours of uptime I'm inclined to say, that intel_iommu=off
* On 19.01.2013 12:48 AM, Mihai Moldovan wrote:
> Testing further, I rebooted using iommu=off and intel_iommu=off. So far, I had
> no random crashes, but the system uptime of REPLACEME minutes is too
> small to draw conclusions yet.
And by "REPLACEME", I meant 5
* On 19.01.2013 12:48 AM, Mihai Moldovan wrote:
Testing further, I rebooted using iommu=off and intel_iommu=off. So far, I had
no random crashes, but the system uptime of REPLACEME minutes is too
small to draw conclusions yet.
And by REPLACEME, I meant 50 (minutes). That's
Had another look at the code and would like to apologize for the confusion...
* On 13.08.2012 05:27 PM, Mihai Moldovan wrote:
> Uhm, no, quite on the contrary. gmbus starts at 0 (with idx 0 being labeled
> "disabled" and idx ((GMBUS_NUM_PORTS == 6) + 1) being labeled &quo
* On 13.08.2012 05:09 PM, Daniel Vetter wrote:
> On Mon, Aug 13, 2012 at 05:03:24PM +0200, Mihai Moldovan wrote:
>> Hi Jani,
>>
>> The reason sounds sane to me, but while looking through the code, I have
>> seen a
>> few other problems, too.
>>
>
Hi Jani,
* On 13.08.2012 04:33 PM, Jani Nikula wrote:
> Hi Mihai, could you test the following patch to see if it fixes the problem,
> please?
>
> BR,
> Jani.
>
>
> Jani Nikula (1):
> drm/i915: ensure i2c adapter is all set before adding it
>
> drivers/gpu/drm/i915/intel_i2c.c |7 ---
>
Hi Jani,
* On 13.08.2012 04:33 PM, Jani Nikula wrote:
Hi Mihai, could you test the following patch to see if it fixes the problem,
please?
BR,
Jani.
Jani Nikula (1):
drm/i915: ensure i2c adapter is all set before adding it
drivers/gpu/drm/i915/intel_i2c.c |7 ---
1 file
* On 13.08.2012 05:09 PM, Daniel Vetter wrote:
On Mon, Aug 13, 2012 at 05:03:24PM +0200, Mihai Moldovan wrote:
Hi Jani,
The reason sounds sane to me, but while looking through the code, I have
seen a
few other problems, too.
To my understanding, we should use port for dev_priv-gmbus
Had another look at the code and would like to apologize for the confusion...
* On 13.08.2012 05:27 PM, Mihai Moldovan wrote:
Uhm, no, quite on the contrary. gmbus starts at 0 (with idx 0 being labeled
disabled and idx ((GMBUS_NUM_PORTS == 6) + 1) being labeled reserved,
which
neither should
* On 10.08.2012 07:44 PM, Mihai Moldovan wrote:
> Hm, OK.
>
> Well, I'm done now.
>
> bisect log:
>
> git bisect start
> # good: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
> git bisect good 805a6af8dba5dfdd35ec35dc52ec0122400b2610
> # bad: [28a33cbc24e4256c1
* On 10.08.2012 06:39 PM, Daniel Vetter wrote:
> On Fri, Aug 10, 2012 at 6:05 PM, Mihai Moldovan wrote:
>> * On 10.08.2012 12:10 PM, Daniel Vetter wrote:
>>> On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan wrote:
>>>> Hi Daniel, hi list
>>>>
>>
* On 10.08.2012 12:10 PM, Daniel Vetter wrote:
> On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan wrote:
>> Hi Daniel, hi list
>>
>> ever since version 3.2.0 (maybe even earlier, but 3.0.2 is still working
>> fine),
>> my box is crashing when loading the
* On 10.08.2012 12:10 PM, Daniel Vetter wrote:
On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan io...@ionic.de wrote:
Hi Daniel, hi list
ever since version 3.2.0 (maybe even earlier, but 3.0.2 is still working
fine),
my box is crashing when loading the i915 driver (mode-setting enabled
* On 10.08.2012 06:39 PM, Daniel Vetter wrote:
On Fri, Aug 10, 2012 at 6:05 PM, Mihai Moldovan io...@ionic.de wrote:
* On 10.08.2012 12:10 PM, Daniel Vetter wrote:
On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan io...@ionic.de wrote:
Hi Daniel, hi list
ever since version 3.2.0 (maybe even
* On 10.08.2012 07:44 PM, Mihai Moldovan wrote:
Hm, OK.
Well, I'm done now.
bisect log:
git bisect start
# good: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
git bisect good 805a6af8dba5dfdd35ec35dc52ec0122400b2610
# bad: [28a33cbc24e4256c143dce96c7d93bf423229f92] Linux 3.5
git
Hi Daniel, hi list
ever since version 3.2.0 (maybe even earlier, but 3.0.2 is still working fine),
my box is crashing when loading the i915 driver (mode-setting enabled.)
The current version I'm testing with is 3.5.0.
I was able to get the BUG output (please forgive any errors/flips in the
Hi Daniel, hi list
ever since version 3.2.0 (maybe even earlier, but 3.0.2 is still working fine),
my box is crashing when loading the i915 driver (mode-setting enabled.)
The current version I'm testing with is 3.5.0.
I was able to get the BUG output (please forgive any errors/flips in the
47 matches
Mail list logo
