Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection

2018-02-05 Thread Matthew Thode 
On 18-02-05 15:08:25, Andy Shevchenko wrote:
> On Mon, Feb 5, 2018 at 1:34 PM, Henrique de Moraes Holschuh
> <h...@hmh.eng.br> wrote:
> >> > I'm fine with a signed-off-by or tested-by or suggested-by.  There is a
> >> > spelling mistake though, 'hoveres' should be hovers.
> >>
> >> Is there anything else I can do here?  I'm not sure any of us have the
> >> ability to find out what lenovo actualy wants this for.
> >
> > I have already acked the patch, so Darren or Andy should pick it up
> > sooner or later for merging into the subsystem tree...
> >
> > But if you wouldn't mind doing so, you could send a V2 with all acks,
> > tested-by/suggested-by/whatever added, as well as that minor spelling
> > mistake correction...  I am not sure this is necessary, though.
> >
> 
> > Andy, Daren?
> 
> The following one already in for-next, meaning it's about to be upstream soon
> 587d8628fb71 platform/x86: thinkpad_acpi: suppress warning about palm 
> detection
> 

Thanks, if there's nothing left for me to do I'll just leave it then.

-- 
Matthew Thode


signature.asc
Description: PGP signature

Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection

2018-02-05 Thread Matthew Thode 
On 18-02-05 15:08:25, Andy Shevchenko wrote:
> On Mon, Feb 5, 2018 at 1:34 PM, Henrique de Moraes Holschuh
>  wrote:
> >> > I'm fine with a signed-off-by or tested-by or suggested-by.  There is a
> >> > spelling mistake though, 'hoveres' should be hovers.
> >>
> >> Is there anything else I can do here?  I'm not sure any of us have the
> >> ability to find out what lenovo actualy wants this for.
> >
> > I have already acked the patch, so Darren or Andy should pick it up
> > sooner or later for merging into the subsystem tree...
> >
> > But if you wouldn't mind doing so, you could send a V2 with all acks,
> > tested-by/suggested-by/whatever added, as well as that minor spelling
> > mistake correction...  I am not sure this is necessary, though.
> >
> 
> > Andy, Daren?
> 
> The following one already in for-next, meaning it's about to be upstream soon
> 587d8628fb71 platform/x86: thinkpad_acpi: suppress warning about palm 
> detection
> 

Thanks, if there's nothing left for me to do I'll just leave it then.

-- 
Matthew Thode


signature.asc
Description: PGP signature

Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection

2018-02-04 Thread Matthew Thode 
On 18-01-13 00:33:09, Matthew Thode wrote:
> On 18-01-12 15:07:12, David Herrmann wrote:
> > Hi Andy
> > 
> > On Fri, Jan 12, 2018 at 2:50 PM, Andy Shevchenko
> > <andy.shevche...@gmail.com> wrote:
> > > On Fri, Jan 12, 2018 at 1:04 PM, David Herrmann <dh.herrm...@gmail.com> 
> > > wrote:
> > >> Cc: Matthew Thode <mth...@mthode.org>
> > >
> > > Shouldn't be Suggested-by or even Signed-off-by?
> > 
> > The patch is different (Matthew originally suppressed the ACPI event),
> > so I did not copy the sign-off. Please add Suggested-by, if that is an
> > acceptable tag.
> > 
> > >> Signed-off-by: David Herrmann <dh.herrm...@gmail.com>
> > >
> > >
> > >> +   case TP_HKEY_EV_PALM_DETECTED:
> > >> +   case TP_HKEY_EV_PALM_UNDETECTED:
> > >
> > >> +   /* palm detected hovering the keyboard, forward to 
> > >> user-space
> > >> +* via netlink for consumption */
> > >
> > > Comment style is
> > > /*
> > >  * Multi line comment.
> > >  * This is an example.
> > >  */
> > 
> > All other 6 comments in this function follow the style I used here, so
> > I tried to be consistent. But feel free to amend this change.
> > 
> 
> I'm fine with a signed-off-by or tested-by or suggested-by.  There is a
> spelling mistake though, 'hoveres' should be hovers.
> 

Is there anything else I can do here?  I'm not sure any of us have the
ability to find out what lenovo actualy wants this for.

Sorry for the double reply, dmarc can be hell.

-- 
Matthew Thode


signature.asc
Description: PGP signature

Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection

2018-02-04 Thread Matthew Thode 
On 18-01-13 00:33:09, Matthew Thode wrote:
> On 18-01-12 15:07:12, David Herrmann wrote:
> > Hi Andy
> > 
> > On Fri, Jan 12, 2018 at 2:50 PM, Andy Shevchenko
> >  wrote:
> > > On Fri, Jan 12, 2018 at 1:04 PM, David Herrmann  
> > > wrote:
> > >> Cc: Matthew Thode 
> > >
> > > Shouldn't be Suggested-by or even Signed-off-by?
> > 
> > The patch is different (Matthew originally suppressed the ACPI event),
> > so I did not copy the sign-off. Please add Suggested-by, if that is an
> > acceptable tag.
> > 
> > >> Signed-off-by: David Herrmann 
> > >
> > >
> > >> +   case TP_HKEY_EV_PALM_DETECTED:
> > >> +   case TP_HKEY_EV_PALM_UNDETECTED:
> > >
> > >> +   /* palm detected hovering the keyboard, forward to 
> > >> user-space
> > >> +* via netlink for consumption */
> > >
> > > Comment style is
> > > /*
> > >  * Multi line comment.
> > >  * This is an example.
> > >  */
> > 
> > All other 6 comments in this function follow the style I used here, so
> > I tried to be consistent. But feel free to amend this change.
> > 
> 
> I'm fine with a signed-off-by or tested-by or suggested-by.  There is a
> spelling mistake though, 'hoveres' should be hovers.
> 

Is there anything else I can do here?  I'm not sure any of us have the
ability to find out what lenovo actualy wants this for.

Sorry for the double reply, dmarc can be hell.

-- 
Matthew Thode


signature.asc
Description: PGP signature

Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection

2018-02-04 Thread Matthew Thode 
On 18-01-13 00:33:09, Matthew Thode wrote:
> On 18-01-12 15:07:12, David Herrmann wrote:
> > Hi Andy
> > 
> > On Fri, Jan 12, 2018 at 2:50 PM, Andy Shevchenko
> > <andy.shevche...@gmail.com> wrote:
> > > On Fri, Jan 12, 2018 at 1:04 PM, David Herrmann <dh.herrm...@gmail.com> 
> > > wrote:
> > >> Cc: Matthew Thode <mth...@mthode.org>
> > >
> > > Shouldn't be Suggested-by or even Signed-off-by?
> > 
> > The patch is different (Matthew originally suppressed the ACPI event),
> > so I did not copy the sign-off. Please add Suggested-by, if that is an
> > acceptable tag.
> > 
> > >> Signed-off-by: David Herrmann <dh.herrm...@gmail.com>
> > >
> > >
> > >> +   case TP_HKEY_EV_PALM_DETECTED:
> > >> +   case TP_HKEY_EV_PALM_UNDETECTED:
> > >
> > >> +   /* palm detected hovering the keyboard, forward to 
> > >> user-space
> > >> +* via netlink for consumption */
> > >
> > > Comment style is
> > > /*
> > >  * Multi line comment.
> > >  * This is an example.
> > >  */
> > 
> > All other 6 comments in this function follow the style I used here, so
> > I tried to be consistent. But feel free to amend this change.
> > 
> 
> I'm fine with a signed-off-by or tested-by or suggested-by.  There is a
> spelling mistake though, 'hoveres' should be hovers.
> 

Is there anything else I can do here?  I'm not sure any of us have the
ability to find out what lenovo actually wants this for.

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature

Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection

2018-02-04 Thread Matthew Thode 
On 18-01-13 00:33:09, Matthew Thode wrote:
> On 18-01-12 15:07:12, David Herrmann wrote:
> > Hi Andy
> > 
> > On Fri, Jan 12, 2018 at 2:50 PM, Andy Shevchenko
> >  wrote:
> > > On Fri, Jan 12, 2018 at 1:04 PM, David Herrmann  
> > > wrote:
> > >> Cc: Matthew Thode 
> > >
> > > Shouldn't be Suggested-by or even Signed-off-by?
> > 
> > The patch is different (Matthew originally suppressed the ACPI event),
> > so I did not copy the sign-off. Please add Suggested-by, if that is an
> > acceptable tag.
> > 
> > >> Signed-off-by: David Herrmann 
> > >
> > >
> > >> +   case TP_HKEY_EV_PALM_DETECTED:
> > >> +   case TP_HKEY_EV_PALM_UNDETECTED:
> > >
> > >> +   /* palm detected hovering the keyboard, forward to 
> > >> user-space
> > >> +* via netlink for consumption */
> > >
> > > Comment style is
> > > /*
> > >  * Multi line comment.
> > >  * This is an example.
> > >  */
> > 
> > All other 6 comments in this function follow the style I used here, so
> > I tried to be consistent. But feel free to amend this change.
> > 
> 
> I'm fine with a signed-off-by or tested-by or suggested-by.  There is a
> spelling mistake though, 'hoveres' should be hovers.
> 

Is there anything else I can do here?  I'm not sure any of us have the
ability to find out what lenovo actually wants this for.

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature

Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection

2018-01-12 Thread Matthew Thode 
On 18-01-12 15:07:12, David Herrmann wrote:
> Hi Andy
> 
> On Fri, Jan 12, 2018 at 2:50 PM, Andy Shevchenko
> <andy.shevche...@gmail.com> wrote:
> > On Fri, Jan 12, 2018 at 1:04 PM, David Herrmann <dh.herrm...@gmail.com> 
> > wrote:
> >> Cc: Matthew Thode <mth...@mthode.org>
> >
> > Shouldn't be Suggested-by or even Signed-off-by?
> 
> The patch is different (Matthew originally suppressed the ACPI event),
> so I did not copy the sign-off. Please add Suggested-by, if that is an
> acceptable tag.
> 
> >> Signed-off-by: David Herrmann <dh.herrm...@gmail.com>
> >
> >
> >> +   case TP_HKEY_EV_PALM_DETECTED:
> >> +   case TP_HKEY_EV_PALM_UNDETECTED:
> >
> >> +   /* palm detected hovering the keyboard, forward to 
> >> user-space
> >> +* via netlink for consumption */
> >
> > Comment style is
> > /*
> >  * Multi line comment.
> >  * This is an example.
> >  */
> 
> All other 6 comments in this function follow the style I used here, so
> I tried to be consistent. But feel free to amend this change.
> 

I'm fine with a signed-off-by or tested-by or suggested-by.  There is a
spelling mistake though, 'hoveres' should be hovers.

-- 
Matthew Thode


signature.asc
Description: PGP signature

Re: [PATCH] platform/x86: thinkpad_acpi: suppress warning about palm detection

2018-01-12 Thread Matthew Thode 
On 18-01-12 15:07:12, David Herrmann wrote:
> Hi Andy
> 
> On Fri, Jan 12, 2018 at 2:50 PM, Andy Shevchenko
>  wrote:
> > On Fri, Jan 12, 2018 at 1:04 PM, David Herrmann  
> > wrote:
> >> Cc: Matthew Thode 
> >
> > Shouldn't be Suggested-by or even Signed-off-by?
> 
> The patch is different (Matthew originally suppressed the ACPI event),
> so I did not copy the sign-off. Please add Suggested-by, if that is an
> acceptable tag.
> 
> >> Signed-off-by: David Herrmann 
> >
> >
> >> +   case TP_HKEY_EV_PALM_DETECTED:
> >> +   case TP_HKEY_EV_PALM_UNDETECTED:
> >
> >> +   /* palm detected hovering the keyboard, forward to 
> >> user-space
> >> +* via netlink for consumption */
> >
> > Comment style is
> > /*
> >  * Multi line comment.
> >  * This is an example.
> >  */
> 
> All other 6 comments in this function follow the style I used here, so
> I tried to be consistent. But feel free to amend this change.
> 

I'm fine with a signed-off-by or tested-by or suggested-by.  There is a
spelling mistake though, 'hoveres' should be hovers.

-- 
Matthew Thode


signature.asc
Description: PGP signature

Re: [PATCH] colons are invalid characters in netdev names

2015-02-17 Thread Matthew Thode 
On 02/17/2015 07:28 PM, Stephen Hemminger wrote:
> On Tue, 17 Feb 2015 17:15:42 -0600
> Matthew Thode  wrote:
> 
>> colons are used as a separator in netdev device lookup in dev_ioctl.c
>>
>> Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME
>>
>> Signed-off-by: Matthew Thode 
> 
> What is the exact sequence that causes the problem?
> SIOCSIFNAME already strips of colon.
> 
> 
It strips the name one access, not creation.  You can create a dummy
device and not access it, escaping doesn't seem to help.

ip link add name foo:asdasd type dummy
ip link del dev foo:asdasd  # will not be deleted

-- 
Matthew Thode



signature.asc
Description: OpenPGP digital signature

[PATCH] reject creation of netdev names with colons

2015-02-17 Thread Matthew Thode 
colons are used as a separator in netdev device lookup in dev_ioctl.c

Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME

Signed-off-by: Matthew Thode 
---
 net/core/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index d030575..efbad386 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -946,7 +946,7 @@ bool dev_valid_name(const char *name)
return false;
 
while (*name) {
-   if (*name == '/' || isspace(*name))
+   if (*name == '/' || *name == ':' || isspace(*name))
return false;
name++;
}
-- 
2.0.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] colons are invalid characters in netdev names

2015-02-17 Thread Matthew Thode 
On 02/17/2015 05:46 PM, Lino Sanfilippo wrote:
> On 18.02.2015 00:15, Matthew Thode wrote:
>> colons are used as a separator in netdev device lookup in dev_ioctl.c
>>
>> Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME
>>
>> Signed-off-by: Matthew Thode 
>> ---
>>  net/core/dev.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index d030575..e9b6d5a 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -942,7 +942,7 @@ bool dev_valid_name(const char *name)
>>  return false;
>>  if (strlen(name) >= IFNAMSIZ)
>>  return false;
>> -if (!strcmp(name, ".") || !strcmp(name, ".."))
>> +if (!strcmp(name, ".") || !strcmp(name, "..") || !strcmp(name, ":"))
>>  return false;
>>  
>>  while (*name) {
>>
> 
> Hi,
> 
> that check should be done in the loop below, shouldn't it?
> 
> Regards,
> Lino
> 
You are correct,  should I resend a patch.  Not really sure the
procedure of updating a patchset sent to the ML.

-- 
Matthew Thode



signature.asc
Description: OpenPGP digital signature

[PATCH] colons are invalid characters in netdev names

2015-02-17 Thread Matthew Thode 
colons are used as a separator in netdev device lookup in dev_ioctl.c

Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME

Signed-off-by: Matthew Thode 
---
 net/core/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index d030575..e9b6d5a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -942,7 +942,7 @@ bool dev_valid_name(const char *name)
return false;
if (strlen(name) >= IFNAMSIZ)
return false;
-   if (!strcmp(name, ".") || !strcmp(name, ".."))
+   if (!strcmp(name, ".") || !strcmp(name, "..") || !strcmp(name, ":"))
return false;
 
while (*name) {
-- 
2.0.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] reject creation of netdev names with colons

2015-02-17 Thread Matthew Thode 
colons are used as a separator in netdev device lookup in dev_ioctl.c

Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME

Signed-off-by: Matthew Thode mth...@mthode.org
---
 net/core/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index d030575..efbad386 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -946,7 +946,7 @@ bool dev_valid_name(const char *name)
return false;
 
while (*name) {
-   if (*name == '/' || isspace(*name))
+   if (*name == '/' || *name == ':' || isspace(*name))
return false;
name++;
}
-- 
2.0.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] colons are invalid characters in netdev names

2015-02-17 Thread Matthew Thode 
On 02/17/2015 07:28 PM, Stephen Hemminger wrote:
 On Tue, 17 Feb 2015 17:15:42 -0600
 Matthew Thode mth...@mthode.org wrote:
 
 colons are used as a separator in netdev device lookup in dev_ioctl.c

 Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME

 Signed-off-by: Matthew Thode mth...@mthode.org
 
 What is the exact sequence that causes the problem?
 SIOCSIFNAME already strips of colon.
 
 
It strips the name one access, not creation.  You can create a dummy
device and not access it, escaping doesn't seem to help.

ip link add name foo:asdasd type dummy
ip link del dev foo:asdasd  # will not be deleted

-- 
Matthew Thode



signature.asc
Description: OpenPGP digital signature

[PATCH] colons are invalid characters in netdev names

2015-02-17 Thread Matthew Thode 
colons are used as a separator in netdev device lookup in dev_ioctl.c

Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME

Signed-off-by: Matthew Thode mth...@mthode.org
---
 net/core/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index d030575..e9b6d5a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -942,7 +942,7 @@ bool dev_valid_name(const char *name)
return false;
if (strlen(name) = IFNAMSIZ)
return false;
-   if (!strcmp(name, .) || !strcmp(name, ..))
+   if (!strcmp(name, .) || !strcmp(name, ..) || !strcmp(name, :))
return false;
 
while (*name) {
-- 
2.0.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] colons are invalid characters in netdev names

2015-02-17 Thread Matthew Thode 
On 02/17/2015 05:46 PM, Lino Sanfilippo wrote:
 On 18.02.2015 00:15, Matthew Thode wrote:
 colons are used as a separator in netdev device lookup in dev_ioctl.c

 Specific functions are SIOCGIFTXQLEN SIOCETHTOOL SIOCSIFNAME

 Signed-off-by: Matthew Thode mth...@mthode.org
 ---
  net/core/dev.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/net/core/dev.c b/net/core/dev.c
 index d030575..e9b6d5a 100644
 --- a/net/core/dev.c
 +++ b/net/core/dev.c
 @@ -942,7 +942,7 @@ bool dev_valid_name(const char *name)
  return false;
  if (strlen(name) = IFNAMSIZ)
  return false;
 -if (!strcmp(name, .) || !strcmp(name, ..))
 +if (!strcmp(name, .) || !strcmp(name, ..) || !strcmp(name, :))
  return false;
  
  while (*name) {

 
 Hi,
 
 that check should be done in the loop below, shouldn't it?
 
 Regards,
 Lino
 
You are correct,  should I resend a patch.  Not really sure the
procedure of updating a patchset sent to the ML.

-- 
Matthew Thode



signature.asc
Description: OpenPGP digital signature

Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-07-16 Thread Matthew Thode 
On 07/04/2013 03:53 AM, Yves-Alexis Perez wrote:
> On jeu., 2013-07-04 at 10:37 +0200, Yves-Alexis Perez wrote:
>> On jeu., 2013-07-04 at 07:53 +0200, Luca Barbato wrote:
>>> On 07/01/2013 03:07 PM, Luca Barbato wrote:
>>>> Hopefully I will carve some time next weekend to play the restricted
>>>> bisect game.
>>>
>>> Release 3.10 apparently doesn't show the problem, I guess problem solved
>>> for me =)
>>>
>>> lu
>>>
>> I've just tried 3.10.0 with CONFIG_EFI=y and I still can't boot with
>> mem=300M.
> And to be a little more specific, and with a bit of fun, I've tryied
> “bisecting” the amount of ram needed to make a successful boot. Platform
> is a Lenovo Thinkpad x230 with 4G of ram.
> 
> mem=300M bad
> mem=4000M good
> mem=2000M bad
> mem=3000M bad
> mem=3500M good
> mem=3250M bad
> mem=3375M bad
> mem=3437M good
> mem=3406M bad
> mem=3421M bad
> mem=3429M bad
> mem=3433M good
> mem=3431M bad
> mem=3432M bad
> 
> So I'm not sure what happens at the 3433M boundary, but there's
> definitely something fishy. And 3.5G ram doesn't look like a very
> specific machine (although I can't test without artificially setting the
> memory limit (I only have one 4096M sodimm).
> 
> I'll try to git bisect between 3.8 and 3.10 and using mem=3432M when I
> have more time.
> 
> Regards,
> 
I tested with a single 2G dimm at pipacs's request. Here is what I found.

mem=unset: booted
mem=1930M: booted
mem=1929M: failed

Booted with memblock=debug and found the following :D

It looks like the uefi regions are simply higher then what the kernel
allows.  Here's a grep'd dmesg and /proc/iomem.  Maybe the kernel
shouldn't allow you to set mem= to lower then the mem that uefi actually
uses?


-- 
-- Matthew Thode (prometheanfire)
[0.00] efi: EFI v2.00 by Lenovo
[0.00] efi:  ACPI=0x78ffe000  ACPI 2.0=0x78ffe014  SMBIOS=0x78e9e000 
[0.00] efi: mem00: type=3, attr=0xf, 
range=[0x-0x1000) (0MB)
[0.00] efi: mem01: type=7, attr=0xf, 
range=[0x1000-0x0004e000) (0MB)
[0.00] efi: mem02: type=3, attr=0xf, 
range=[0x0004e000-0x00058000) (0MB)
[0.00] efi: mem03: type=10, attr=0xf, 
range=[0x00058000-0x00059000) (0MB)
[0.00] efi: mem04: type=7, attr=0xf, 
range=[0x00059000-0x0005e000) (0MB)
[0.00] efi: mem05: type=4, attr=0xf, 
range=[0x0005e000-0x0005f000) (0MB)
[0.00] efi: mem06: type=3, attr=0xf, 
range=[0x0005f000-0x000a) (0MB)
[0.00] efi: mem07: type=2, attr=0xf, 
range=[0x0010-0x01d0) (28MB)
[0.00] efi: mem08: type=7, attr=0xf, 
range=[0x01d0-0x0200) (3MB)
[0.00] efi: mem09: type=2, attr=0xf, 
range=[0x0200-0x03c0) (28MB)
[0.00] efi: mem10: type=7, attr=0xf, 
range=[0x03c0-0x2000) (452MB)
[0.00] efi: mem11: type=0, attr=0xf, 
range=[0x2000-0x2020) (2MB)
[0.00] efi: mem12: type=7, attr=0xf, 
range=[0x2020-0x2eb38000) (233MB)
[0.00] efi: mem13: type=4, attr=0xf, 
range=[0x2eb38000-0x2eb58000) (0MB)
[0.00] efi: mem14: type=7, attr=0xf, 
range=[0x2eb58000-0x30d9a000) (34MB)
[0.00] efi: mem15: type=0, attr=0xf, 
range=[0x30d9a000-0x30f9a000) (2MB)
[0.00] efi: mem16: type=4, attr=0xf, 
range=[0x30f9a000-0x31b28000) (11MB)
[0.00] efi: mem17: type=7, attr=0xf, 
range=[0x31b28000-0x57a2f000) (607MB)
[0.00] efi: mem18: type=2, attr=0xf, 
range=[0x57a2f000-0x74d99000) (467MB)
[0.00] efi: mem19: type=7, attr=0xf, 
range=[0x74d99000-0x74f82000) (1MB)
[0.00] efi: mem20: type=1, attr=0xf, 
range=[0x74f82000-0x74f9f000) (0MB)
[0.00] efi: mem21: type=7, attr=0xf, 
range=[0x74f9f000-0x75b79000) (11MB)
[0.00] efi: mem22: type=4, attr=0xf, 
range=[0x75b79000-0x77f9f000) (36MB)
[0.00] efi: mem23: type=7, attr=0xf, 
range=[0x77f9f000-0x7822d000) (2MB)
[0.00] efi: mem24: type=2, attr=0xf, 
range=[0x7822d000-0x78236000) (0MB)
[0.00] efi: mem25: type=3, attr=0xf, 
range=[0x78236000-0x7899f000) (7MB)
[0.00] efi: mem26: type=5, attr=0x800f, 
range=[0x7899f000-0x78ac) (1MB)
[0.00] efi: mem27: type=5, attr=0x800f, 
range=[0x78ac-0x78b9f000) (0MB)
[0.00] efi: mem28: type=6, attr=0x800f, 
range=[0x78b9f000-0x78cb1000) (1MB)
[0.00] efi: mem29: type=6, attr=0x8

Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-07-16 Thread Matthew Thode 
On 07/04/2013 03:53 AM, Yves-Alexis Perez wrote:
 On jeu., 2013-07-04 at 10:37 +0200, Yves-Alexis Perez wrote:
 On jeu., 2013-07-04 at 07:53 +0200, Luca Barbato wrote:
 On 07/01/2013 03:07 PM, Luca Barbato wrote:
 Hopefully I will carve some time next weekend to play the restricted
 bisect game.

 Release 3.10 apparently doesn't show the problem, I guess problem solved
 for me =)

 lu

 I've just tried 3.10.0 with CONFIG_EFI=y and I still can't boot with
 mem=300M.
 And to be a little more specific, and with a bit of fun, I've tryied
 “bisecting” the amount of ram needed to make a successful boot. Platform
 is a Lenovo Thinkpad x230 with 4G of ram.
 
 mem=300M bad
 mem=4000M good
 mem=2000M bad
 mem=3000M bad
 mem=3500M good
 mem=3250M bad
 mem=3375M bad
 mem=3437M good
 mem=3406M bad
 mem=3421M bad
 mem=3429M bad
 mem=3433M good
 mem=3431M bad
 mem=3432M bad
 
 So I'm not sure what happens at the 3433M boundary, but there's
 definitely something fishy. And 3.5G ram doesn't look like a very
 specific machine (although I can't test without artificially setting the
 memory limit (I only have one 4096M sodimm).
 
 I'll try to git bisect between 3.8 and 3.10 and using mem=3432M when I
 have more time.
 
 Regards,
 
I tested with a single 2G dimm at pipacs's request. Here is what I found.

mem=unset: booted
mem=1930M: booted
mem=1929M: failed

Booted with memblock=debug and found the following :D

It looks like the uefi regions are simply higher then what the kernel
allows.  Here's a grep'd dmesg and /proc/iomem.  Maybe the kernel
shouldn't allow you to set mem= to lower then the mem that uefi actually
uses?


-- 
-- Matthew Thode (prometheanfire)
[0.00] efi: EFI v2.00 by Lenovo
[0.00] efi:  ACPI=0x78ffe000  ACPI 2.0=0x78ffe014  SMBIOS=0x78e9e000 
[0.00] efi: mem00: type=3, attr=0xf, 
range=[0x-0x1000) (0MB)
[0.00] efi: mem01: type=7, attr=0xf, 
range=[0x1000-0x0004e000) (0MB)
[0.00] efi: mem02: type=3, attr=0xf, 
range=[0x0004e000-0x00058000) (0MB)
[0.00] efi: mem03: type=10, attr=0xf, 
range=[0x00058000-0x00059000) (0MB)
[0.00] efi: mem04: type=7, attr=0xf, 
range=[0x00059000-0x0005e000) (0MB)
[0.00] efi: mem05: type=4, attr=0xf, 
range=[0x0005e000-0x0005f000) (0MB)
[0.00] efi: mem06: type=3, attr=0xf, 
range=[0x0005f000-0x000a) (0MB)
[0.00] efi: mem07: type=2, attr=0xf, 
range=[0x0010-0x01d0) (28MB)
[0.00] efi: mem08: type=7, attr=0xf, 
range=[0x01d0-0x0200) (3MB)
[0.00] efi: mem09: type=2, attr=0xf, 
range=[0x0200-0x03c0) (28MB)
[0.00] efi: mem10: type=7, attr=0xf, 
range=[0x03c0-0x2000) (452MB)
[0.00] efi: mem11: type=0, attr=0xf, 
range=[0x2000-0x2020) (2MB)
[0.00] efi: mem12: type=7, attr=0xf, 
range=[0x2020-0x2eb38000) (233MB)
[0.00] efi: mem13: type=4, attr=0xf, 
range=[0x2eb38000-0x2eb58000) (0MB)
[0.00] efi: mem14: type=7, attr=0xf, 
range=[0x2eb58000-0x30d9a000) (34MB)
[0.00] efi: mem15: type=0, attr=0xf, 
range=[0x30d9a000-0x30f9a000) (2MB)
[0.00] efi: mem16: type=4, attr=0xf, 
range=[0x30f9a000-0x31b28000) (11MB)
[0.00] efi: mem17: type=7, attr=0xf, 
range=[0x31b28000-0x57a2f000) (607MB)
[0.00] efi: mem18: type=2, attr=0xf, 
range=[0x57a2f000-0x74d99000) (467MB)
[0.00] efi: mem19: type=7, attr=0xf, 
range=[0x74d99000-0x74f82000) (1MB)
[0.00] efi: mem20: type=1, attr=0xf, 
range=[0x74f82000-0x74f9f000) (0MB)
[0.00] efi: mem21: type=7, attr=0xf, 
range=[0x74f9f000-0x75b79000) (11MB)
[0.00] efi: mem22: type=4, attr=0xf, 
range=[0x75b79000-0x77f9f000) (36MB)
[0.00] efi: mem23: type=7, attr=0xf, 
range=[0x77f9f000-0x7822d000) (2MB)
[0.00] efi: mem24: type=2, attr=0xf, 
range=[0x7822d000-0x78236000) (0MB)
[0.00] efi: mem25: type=3, attr=0xf, 
range=[0x78236000-0x7899f000) (7MB)
[0.00] efi: mem26: type=5, attr=0x800f, 
range=[0x7899f000-0x78ac) (1MB)
[0.00] efi: mem27: type=5, attr=0x800f, 
range=[0x78ac-0x78b9f000) (0MB)
[0.00] efi: mem28: type=6, attr=0x800f, 
range=[0x78b9f000-0x78cb1000) (1MB)
[0.00] efi: mem29: type=6, attr=0x800f, 
range=[0x78cb1000-0x78d9f000) (0MB)
[0.00] efi: mem30: type=0, attr=0xf, 
range=[0x78d9f000-0x78e1f000) (0MB)
[0.00] efi: mem31: type=0, attr=0xf, 
range=[0x78e1f000-0x78e9b000) (0MB

Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-07-01 Thread Matthew Thode 
On 07/01/2013 01:25 AM, Matthew Garrett wrote:
> On Mon, Jul 01, 2013 at 07:22:32AM +0200, Luca Barbato wrote:
> 
>> MacBookPro8,2 with efi-stub, loading directly from the efi shell w/out
>> any memory restriction.
> 
> How do you know this is the same issue?
> 
Same behavior?  Can't really know until it's solved I think.
Unfortunately this bug seems to cause a lack of info.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-07-01 Thread Matthew Thode 
On 07/01/2013 01:25 AM, Matthew Garrett wrote:
 On Mon, Jul 01, 2013 at 07:22:32AM +0200, Luca Barbato wrote:
 
 MacBookPro8,2 with efi-stub, loading directly from the efi shell w/out
 any memory restriction.
 
 How do you know this is the same issue?
 
Same behavior?  Can't really know until it's solved I think.
Unfortunately this bug seems to cause a lack of info.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-06-30 Thread Matthew Thode 
On 06/30/2013 11:41 PM, Luca Barbato wrote:
> On 07/01/2013 06:30 AM, Matthew Thode wrote:
> 
>> You had the problem where it was blank on boot (right after grub, no
>> kernel messages at all)?  Sounds like this might not be limited to just
>> Lenovo then.
> 
> no grub, efi-stub directly from the efi shell.
> 
>> mjg59, is there anything I can do to help move this bug forward?  I've
>> done all I can think of (even tried a serial expresscard slot for logging).
> 
> If you feel like bisecting seems the only option =_=
> 
> lu
> 
I was hoping to avoid that, was thinking of bisecting 3.8->3.9 for only
the uefi stuff though, should help keep the traffic down.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-06-30 Thread Matthew Thode 
On 06/27/2013 01:17 PM, Luca Barbato wrote:
> On 06/27/2013 06:47 PM, Matthew Thode wrote:
>> There is an early boot failure with linux-3.[9,10].??? when booting
>> using uefi on low memory systems.
>>
>> This seems like it might be hardware specific, I am running on a Lenovo
>> T520, running bios version 1.42, firmware rev 1.36.
>>
> 
> Had the same problem with linux 3.10-rc1 and a stock mac book pro, I
> hadn't investigated much further though.
> 
> lu
> 
You had the problem where it was blank on boot (right after grub, no
kernel messages at all)?  Sounds like this might not be limited to just
Lenovo then.

mjg59, is there anything I can do to help move this bug forward?  I've
done all I can think of (even tried a serial expresscard slot for logging).

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-06-30 Thread Matthew Thode 
On 06/27/2013 01:17 PM, Luca Barbato wrote:
 On 06/27/2013 06:47 PM, Matthew Thode wrote:
 There is an early boot failure with linux-3.[9,10].??? when booting
 using uefi on low memory systems.

 This seems like it might be hardware specific, I am running on a Lenovo
 T520, running bios version 1.42, firmware rev 1.36.

 
 Had the same problem with linux 3.10-rc1 and a stock mac book pro, I
 hadn't investigated much further though.
 
 lu
 
You had the problem where it was blank on boot (right after grub, no
kernel messages at all)?  Sounds like this might not be limited to just
Lenovo then.

mjg59, is there anything I can do to help move this bug forward?  I've
done all I can think of (even tried a serial expresscard slot for logging).

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-06-30 Thread Matthew Thode 
On 06/30/2013 11:41 PM, Luca Barbato wrote:
 On 07/01/2013 06:30 AM, Matthew Thode wrote:
 
 You had the problem where it was blank on boot (right after grub, no
 kernel messages at all)?  Sounds like this might not be limited to just
 Lenovo then.
 
 no grub, efi-stub directly from the efi shell.
 
 mjg59, is there anything I can do to help move this bug forward?  I've
 done all I can think of (even tried a serial expresscard slot for logging).
 
 If you feel like bisecting seems the only option =_=
 
 lu
 
I was hoping to avoid that, was thinking of bisecting 3.8-3.9 for only
the uefi stuff though, should help keep the traffic down.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-06-27 Thread Matthew Thode 
On 06/27/2013 12:43 PM, Matthew Garrett wrote:
> On Thu, Jun 27, 2013 at 12:39:14PM -0500, Matthew Thode wrote:
>> On 06/27/2013 12:27 PM, Matthew Garrett wrote:
>>> On Thu, Jun 27, 2013 at 11:47:42AM -0500, Matthew Thode wrote:
>>>> There is an early boot failure with linux-3.[9,10].??? when booting
>>>> using uefi on low memory systems.
>>>
>>> Does it happen on systems that genuinely have small amounts of memory, 
>>> or only on systems where you're passing mem=?
>>>
>> I don't have a system (or even memory to place in this one) that has
>> that small amount of memory.  Do they even make ddr3 sodimms that small?
> 
> I've no idea. If a bug can't be triggered on any hardware that actually 
> exists, it doesn't seem like a high priority.
> 
Dunno, I've asked in the bug for more testing from others that have hit
the problem.  I'll let you know what I find.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-06-27 Thread Matthew Thode 
On 06/27/2013 12:27 PM, Matthew Garrett wrote:
> On Thu, Jun 27, 2013 at 11:47:42AM -0500, Matthew Thode wrote:
>> There is an early boot failure with linux-3.[9,10].??? when booting
>> using uefi on low memory systems.
> 
> Does it happen on systems that genuinely have small amounts of memory, 
> or only on systems where you're passing mem=?
> 
I don't have a system (or even memory to place in this one) that has
that small amount of memory.  Do they even make ddr3 sodimms that small?

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-06-27 Thread Matthew Thode 
There is an early boot failure with linux-3.[9,10].??? when booting
using uefi on low memory systems.

This seems like it might be hardware specific, I am running on a Lenovo
T520, running bios version 1.42, firmware rev 1.36.

This seems to be limited to x86_64, as i386 does boot.

I build my initram into the kernel image, the following boot line
triggers the issue.  The issue causes no kernel messages to be printed
to screen (looks like the kernel isn't loading at all to my untrained eyes).

linux   /kernel-3.9.7 mem=300M

the following link contains kernel images and vmlinux for both amd64 and
the referenced kernel versions
http://dev.gentoo.org/~prometheanfire/bugs/471626/

we are tracking the bug here (keep in mind, this is NOT a pax bug)
https://bugs.gentoo.org/show_bug.cgi?id=471626

I have tested the following combinations.
amd64 - 300M - 3.9.7-bug hit
amd64 - 300M - 3.10-rc7 -big hit
amd64 - 16G  - 3.9.7-bug not hit
amd64 - 16G  - 3.10-rc7 -bug not hit
i386  - 300M - 3.9.7-bug not hit
i386  - 300M - 3.10-rc7 -other bug possibly hit
i386  - 16G  - 3.9.7-bug not hit
i386  - 16G  - 3.10-rc7 -other bug possibly hit

the pictures taken for the other possible bug hit are located at
http://goo.gl/741ub


-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-06-27 Thread Matthew Thode 
There is an early boot failure with linux-3.[9,10].??? when booting
using uefi on low memory systems.

This seems like it might be hardware specific, I am running on a Lenovo
T520, running bios version 1.42, firmware rev 1.36.

This seems to be limited to x86_64, as i386 does boot.

I build my initram into the kernel image, the following boot line
triggers the issue.  The issue causes no kernel messages to be printed
to screen (looks like the kernel isn't loading at all to my untrained eyes).

linux   /kernel-3.9.7 mem=300M

the following link contains kernel images and vmlinux for both amd64 and
the referenced kernel versions
http://dev.gentoo.org/~prometheanfire/bugs/471626/

we are tracking the bug here (keep in mind, this is NOT a pax bug)
https://bugs.gentoo.org/show_bug.cgi?id=471626

I have tested the following combinations.
amd64 - 300M - 3.9.7-bug hit
amd64 - 300M - 3.10-rc7 -big hit
amd64 - 16G  - 3.9.7-bug not hit
amd64 - 16G  - 3.10-rc7 -bug not hit
i386  - 300M - 3.9.7-bug not hit
i386  - 300M - 3.10-rc7 -other bug possibly hit
i386  - 16G  - 3.9.7-bug not hit
i386  - 16G  - 3.10-rc7 -other bug possibly hit

the pictures taken for the other possible bug hit are located at
http://goo.gl/741ub


-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-06-27 Thread Matthew Thode 
On 06/27/2013 12:27 PM, Matthew Garrett wrote:
 On Thu, Jun 27, 2013 at 11:47:42AM -0500, Matthew Thode wrote:
 There is an early boot failure with linux-3.[9,10].??? when booting
 using uefi on low memory systems.
 
 Does it happen on systems that genuinely have small amounts of memory, 
 or only on systems where you're passing mem=?
 
I don't have a system (or even memory to place in this one) that has
that small amount of memory.  Do they even make ddr3 sodimms that small?

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: 3.9.7, 3.10-rc7 - UEFI stalls at boot (nothing displayed), when booting with mem=300M

2013-06-27 Thread Matthew Thode 
On 06/27/2013 12:43 PM, Matthew Garrett wrote:
 On Thu, Jun 27, 2013 at 12:39:14PM -0500, Matthew Thode wrote:
 On 06/27/2013 12:27 PM, Matthew Garrett wrote:
 On Thu, Jun 27, 2013 at 11:47:42AM -0500, Matthew Thode wrote:
 There is an early boot failure with linux-3.[9,10].??? when booting
 using uefi on low memory systems.

 Does it happen on systems that genuinely have small amounts of memory, 
 or only on systems where you're passing mem=?

 I don't have a system (or even memory to place in this one) that has
 that small amount of memory.  Do they even make ddr3 sodimms that small?
 
 I've no idea. If a bug can't be triggered on any hardware that actually 
 exists, it doesn't seem like a high priority.
 
Dunno, I've asked in the bug for more testing from others that have hit
the problem.  I'll let you know what I find.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

setting the kernel log console at runtime

2013-06-17 Thread Matthew Thode 
I have a server I wish to debug, but wish to set the console at runtime
(I boot with it set, but it gets reset somehow).

I boot with the following on the cmdline
console=ttyS1 console=ttyS0 console=ttyS2 console=tty0

But end up with the following in /proc/consoles (I need to log to ttyS0
in particular).
tty0 -WU (EC p  )4:1
netcon0  -W- (E )
ttyS1-W- (E  p a)4:65

Here's my printk just in case you ask as well :D
8   4   1   7

How would I go about setting the kernel log console without a reboot?

-- 
-- Matthew Thode



signature.asc
Description: OpenPGP digital signature

setting the kernel log console at runtime

2013-06-17 Thread Matthew Thode 
I have a server I wish to debug, but wish to set the console at runtime
(I boot with it set, but it gets reset somehow).

I boot with the following on the cmdline
console=ttyS1 console=ttyS0 console=ttyS2 console=tty0

But end up with the following in /proc/consoles (I need to log to ttyS0
in particular).
tty0 -WU (EC p  )4:1
netcon0  -W- (E )
ttyS1-W- (E  p a)4:65

Here's my printk just in case you ask as well :D
8   4   1   7

How would I go about setting the kernel log console without a reboot?

-- 
-- Matthew Thode



signature.asc
Description: OpenPGP digital signature

Re: [BUG 3.7-rc5] NULL pointer deref when using a pcie-pci bridged pci device and intel-iommu

2012-11-13 Thread Matthew Thode 
On 11/13/2012 01:10 PM, Alex Williamson wrote:
> On Tue, 2012-11-13 at 14:05 -0500, Don Dutile wrote:
>> On 11/13/2012 10:38 AM, Alex Williamson wrote:
>>> On Mon, 2012-11-12 at 15:05 -0600, Matthew Thode wrote:
>>>> On 11/12/2012 01:57 PM, Don Dutile wrote:
>>>>> On 11/12/2012 04:26 AM, Doug Goldstein wrote:
>>>>>> On Sun, Nov 11, 2012 at 5:19 PM, Matthew Thode
>>>>>>wrote:
>>>>>>> System boots with vt-d disabled in bios. Otherwise I get the errors in
>>>>>>> the attached log.  I can do whatever testing you need as this system is
>>>>>>> not in production yet.  gonna paste the important part here.  Let me
>>>>>>> know if you want anything else.
>>>>>>>
>>>>>>> Please CC me directly as I am not subscribed to the LKML.
>>>>>>>
>>>>>>>
>>>>>>> Trying to unpack rootfs image as initramfs...
>>>>>>> Freeing initrd memory: 5124k freed
>>>>>>> IOMMU 0 0xfbffe000: using Queued invalidation
>>>>>>> IOMMU: Setting RMRR:
>>>>>>> IOMMU: Setting identity map for device :00:1d.0 [0xbf7ec000 -
>>>>>>> 0xbf7f]
>>>>>>> IOMMU: Setting identity map for device :00:1d.1 [0xbf7ec000 -
>>>>>>> 0xbf7f]
>>>>>>> IOMMU: Setting identity map for device :00:1d.2 [0xbf7ec000 -
>>>>>>> 0xbf7f]
>>>>>>> IOMMU: Setting identity map for device :00:1d.7 [0xbf7ec000 -
>>>>>>> 0xbf7f]
>>>>>>> IOMMU: Setting identity map for device :00:1a.0 [0xbf7ec000 -
>>>>>>> 0xbf7f]
>>>>>>> IOMMU: Setting identity map for device :00:1a.1 [0xbf7ec000 -
>>>>>>> 0xbf7f]
>>>>>>> IOMMU: Setting identity map for device :00:1a.2 [0xbf7ec000 -
>>>>>>> 0xbf7f]
>>>>>>> IOMMU: Setting identity map for device :00:1a.7 [0xbf7ec000 -
>>>>>>> 0xbf7f]
>>>>>>> IOMMU: Setting identity map for device :00:1d.0 [0xec000 - 0xe]
>>>>>>> IOMMU: Setting identity map for device :00:1d.1 [0xec000 - 0xe]
>>>>>>> IOMMU: Setting identity map for device :00:1d.2 [0xec000 - 0xe]
>>>>>>> IOMMU: Setting identity map for device :00:1d.7 [0xec000 - 0xe]
>>>>>>> IOMMU: Setting identity map for device :00:1a.0 [0xec000 - 0xe]
>>>>>>> IOMMU: Setting identity map for device :00:1a.1 [0xec000 - 0xe]
>>>>>>> IOMMU: Setting identity map for device :00:1a.2 [0xec000 - 0xe]
>>>>>>> IOMMU: Setting identity map for device :00:1a.7 [0xec000 - 0xe]
>>>>>>> IOMMU: Prepare 0-16MiB unity mapping for LPC
>>>>>>> IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0xff]
>>>>>>> PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
>>>>>>> BUG: unable to handle kernel NULL pointer dereference at
>>>>>>> 003c
>>>>>>> IP: [] pci_get_dma_source+0xf/0x41
>>>>>>> PGD 0
>>>>>>> Oops:  [#1] SMP
>>>>>>> Modules linked in:
>>>>>>> CPU 7
>>>>>>> Pid: 1, comm: swapper/0 Not tainted 3.7.0-rc5 #1 Penguin Computing
>>>>>>> Relion 1751/X8DTU
>>>>>>> RIP: 0010:[]  []
>>>>>>> pci_get_dma_source+0xf/0x41
>>>>>>> RSP: :8806264d1d88  EFLAGS: 00010282
>>>>>>> RAX: 813bd3a8 RBX: 8806261d1000 RCX: e8221180
>>>>>>> RDX: 818624f0 RSI: 88062635b0c0 RDI: 
>>>>>>> RBP: 8806264d1d88 R08: 8806263d6000 R09: 
>>>>>>> R10: 8806264d1ca8 R11: 0005 R12: 
>>>>>>> R13: 8806261d1098 R14:  R15: 
>>>>>>> FS:  () GS:88063f2e()
>>>>>>> knlGS:
>>>>>>> CS:  0010 DS:  ES:  CR0: 8005003b
>>>>>>> CR2: 003c CR3: 01c0b000 CR4: 07e0
>>>>>>> DR0:  DR1:  DR2: 
>>

Re: [PATCH] intel-iommu: Fix lookup in add device

2012-11-13 Thread Matthew Thode 
On 11/13/2012 11:22 AM, Alex Williamson wrote:
> We can't assume this device exists, fall back to the bridge itself.
> 
> Signed-off-by: Alex Williamson 
> Tested-by: Matthew Thode 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/iommu/intel-iommu.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index d4a4cd4..0badfa4 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -4108,7 +4108,7 @@ static void swap_pci_ref(struct pci_dev **from, struct 
> pci_dev *to)
>  static int intel_iommu_add_device(struct device *dev)
>  {
>   struct pci_dev *pdev = to_pci_dev(dev);
> - struct pci_dev *bridge, *dma_pdev;
> + struct pci_dev *bridge, *dma_pdev = NULL;
>   struct iommu_group *group;
>   int ret;
>  
> @@ -4122,7 +4122,7 @@ static int intel_iommu_add_device(struct device *dev)
>   dma_pdev = pci_get_domain_bus_and_slot(
>   pci_domain_nr(pdev->bus),
>   bridge->subordinate->number, 0);
> - else
> + if (!dma_pdev)
>   dma_pdev = pci_dev_get(bridge);
>   } else
>   dma_pdev = pci_dev_get(pdev);
> 

I've tested this and it works just fine.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: [BUG 3.7-rc5] NULL pointer deref when using a pcie-pci bridged pci device and intel-iommu

2012-11-13 Thread Matthew Thode 
On 11/13/2012 09:38 AM, Alex Williamson wrote:
> On Mon, 2012-11-12 at 15:05 -0600, Matthew Thode wrote:
>> On 11/12/2012 01:57 PM, Don Dutile wrote:
>>> On 11/12/2012 04:26 AM, Doug Goldstein wrote:
>>>> On Sun, Nov 11, 2012 at 5:19 PM, Matthew Thode
>>>>   wrote:
>>>>> System boots with vt-d disabled in bios. Otherwise I get the errors in
>>>>> the attached log.  I can do whatever testing you need as this system is
>>>>> not in production yet.  gonna paste the important part here.  Let me
>>>>> know if you want anything else.
>>>>>
>>>>> Please CC me directly as I am not subscribed to the LKML.
>>>>>
>>>>>
>>>>> Trying to unpack rootfs image as initramfs...
>>>>> Freeing initrd memory: 5124k freed
>>>>> IOMMU 0 0xfbffe000: using Queued invalidation
>>>>> IOMMU: Setting RMRR:
>>>>> IOMMU: Setting identity map for device :00:1d.0 [0xbf7ec000 -
>>>>> 0xbf7f]
>>>>> IOMMU: Setting identity map for device :00:1d.1 [0xbf7ec000 -
>>>>> 0xbf7f]
>>>>> IOMMU: Setting identity map for device :00:1d.2 [0xbf7ec000 -
>>>>> 0xbf7f]
>>>>> IOMMU: Setting identity map for device :00:1d.7 [0xbf7ec000 -
>>>>> 0xbf7f]
>>>>> IOMMU: Setting identity map for device :00:1a.0 [0xbf7ec000 -
>>>>> 0xbf7f]
>>>>> IOMMU: Setting identity map for device :00:1a.1 [0xbf7ec000 -
>>>>> 0xbf7f]
>>>>> IOMMU: Setting identity map for device :00:1a.2 [0xbf7ec000 -
>>>>> 0xbf7f]
>>>>> IOMMU: Setting identity map for device :00:1a.7 [0xbf7ec000 -
>>>>> 0xbf7f]
>>>>> IOMMU: Setting identity map for device :00:1d.0 [0xec000 - 0xe]
>>>>> IOMMU: Setting identity map for device :00:1d.1 [0xec000 - 0xe]
>>>>> IOMMU: Setting identity map for device :00:1d.2 [0xec000 - 0xe]
>>>>> IOMMU: Setting identity map for device :00:1d.7 [0xec000 - 0xe]
>>>>> IOMMU: Setting identity map for device :00:1a.0 [0xec000 - 0xe]
>>>>> IOMMU: Setting identity map for device :00:1a.1 [0xec000 - 0xe]
>>>>> IOMMU: Setting identity map for device :00:1a.2 [0xec000 - 0xe]
>>>>> IOMMU: Setting identity map for device :00:1a.7 [0xec000 - 0xe]
>>>>> IOMMU: Prepare 0-16MiB unity mapping for LPC
>>>>> IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0xff]
>>>>> PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
>>>>> BUG: unable to handle kernel NULL pointer dereference at
>>>>> 003c
>>>>> IP: [] pci_get_dma_source+0xf/0x41
>>>>> PGD 0
>>>>> Oops:  [#1] SMP
>>>>> Modules linked in:
>>>>> CPU 7
>>>>> Pid: 1, comm: swapper/0 Not tainted 3.7.0-rc5 #1 Penguin Computing
>>>>> Relion 1751/X8DTU
>>>>> RIP: 0010:[]  []
>>>>> pci_get_dma_source+0xf/0x41
>>>>> RSP: :8806264d1d88  EFLAGS: 00010282
>>>>> RAX: 813bd3a8 RBX: 8806261d1000 RCX: e8221180
>>>>> RDX: 818624f0 RSI: 88062635b0c0 RDI: 
>>>>> RBP: 8806264d1d88 R08: 8806263d6000 R09: 
>>>>> R10: 8806264d1ca8 R11: 0005 R12: 
>>>>> R13: 8806261d1098 R14:  R15: 
>>>>> FS:  () GS:88063f2e()
>>>>> knlGS:
>>>>> CS:  0010 DS:  ES:  CR0: 8005003b
>>>>> CR2: 003c CR3: 01c0b000 CR4: 07e0
>>>>> DR0:  DR1:  DR2: 
>>>>> DR3:  DR6: 0ff0 DR7: 0400
>>>>> Process swapper/0 (pid: 1, threadinfo 8806264d, task
>>>>> 8806264cf910)
>>>>> Stack:
>>>>>   8806264d1dc8 815d02c9  8806
>>>>>   8806264d1dd8 81c64b00 8806261d1098 8806264d1df8
>>>>>   8806264d1de8 815cd5a4 81c64b00 815cd56a
>>>>> Call Trace:
>>>>>   [] intel_iommu_add_device+0x95/0x167
>>>>>   [] add_iommu_group+0x3a/0x41

Re: [BUG 3.7-rc5] NULL pointer deref when using a pcie-pci bridged pci device and intel-iommu

2012-11-13 Thread Matthew Thode 
On 11/13/2012 09:38 AM, Alex Williamson wrote:
 On Mon, 2012-11-12 at 15:05 -0600, Matthew Thode wrote:
 On 11/12/2012 01:57 PM, Don Dutile wrote:
 On 11/12/2012 04:26 AM, Doug Goldstein wrote:
 On Sun, Nov 11, 2012 at 5:19 PM, Matthew Thode
 prometheanf...@gentoo.org  wrote:
 System boots with vt-d disabled in bios. Otherwise I get the errors in
 the attached log.  I can do whatever testing you need as this system is
 not in production yet.  gonna paste the important part here.  Let me
 know if you want anything else.

 Please CC me directly as I am not subscribed to the LKML.


 Trying to unpack rootfs image as initramfs...
 Freeing initrd memory: 5124k freed
 IOMMU 0 0xfbffe000: using Queued invalidation
 IOMMU: Setting RMRR:
 IOMMU: Setting identity map for device :00:1d.0 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1d.1 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1d.2 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1d.7 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1a.0 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1a.1 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1a.2 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1a.7 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1d.0 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1d.1 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1d.2 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1d.7 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1a.0 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1a.1 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1a.2 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1a.7 [0xec000 - 0xe]
 IOMMU: Prepare 0-16MiB unity mapping for LPC
 IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0xff]
 PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
 BUG: unable to handle kernel NULL pointer dereference at
 003c
 IP: [813bd796] pci_get_dma_source+0xf/0x41
 PGD 0
 Oops:  [#1] SMP
 Modules linked in:
 CPU 7
 Pid: 1, comm: swapper/0 Not tainted 3.7.0-rc5 #1 Penguin Computing
 Relion 1751/X8DTU
 RIP: 0010:[813bd796]  [813bd796]
 pci_get_dma_source+0xf/0x41
 RSP: :8806264d1d88  EFLAGS: 00010282
 RAX: 813bd3a8 RBX: 8806261d1000 RCX: e8221180
 RDX: 818624f0 RSI: 88062635b0c0 RDI: 
 RBP: 8806264d1d88 R08: 8806263d6000 R09: 
 R10: 8806264d1ca8 R11: 0005 R12: 
 R13: 8806261d1098 R14:  R15: 
 FS:  () GS:88063f2e()
 knlGS:
 CS:  0010 DS:  ES:  CR0: 8005003b
 CR2: 003c CR3: 01c0b000 CR4: 07e0
 DR0:  DR1:  DR2: 
 DR3:  DR6: 0ff0 DR7: 0400
 Process swapper/0 (pid: 1, threadinfo 8806264d, task
 8806264cf910)
 Stack:
   8806264d1dc8 815d02c9  8806
   8806264d1dd8 81c64b00 8806261d1098 8806264d1df8
   8806264d1de8 815cd5a4 81c64b00 815cd56a
 Call Trace:
   [815d02c9] intel_iommu_add_device+0x95/0x167
   [815cd5a4] add_iommu_group+0x3a/0x41
   [815cd56a] ? bus_set_iommu+0x44/0x44
   [8145eca1] bus_for_each_dev+0x54/0x81
   [815cd563] bus_set_iommu+0x3d/0x44
   [81cd3fa3] intel_iommu_init+0xae5/0xb5e
   [81ca0277] ? free_initrd+0x9e/0x9e
   [81ca4248] ? memblock_find_dma_reserve+0x13f/0x13f
   [81ca425e] pci_iommu_init+0x16/0x41
   [81cc4140] ? pci_proc_init+0x6b/0x6b
   [81000231] do_one_initcall+0x7a/0x129
   [816dac14] kernel_init+0x139/0x2a2
   [81c9d4c7] ? loglevel+0x31/0x31
   [816daadb] ? rest_init+0x6f/0x6f
   [816f66ac] ret_from_fork+0x7c/0xb0
   [816daadb] ? rest_init+0x6f/0x6f
 Code: ff c1 75 04 ff d0 eb 12 48 83 c2 10 48 8b 42 08 48 85 c0 75 d3 b8
 e7 ff ff ff c9 c3 55 48 c7 c2 f0 24 86 81 48 89 e5 eb 24 8b 0a66  3b
 4f 3c 74 05 66 ff c1 75 13 66 8b 4a 02 66 3b 4f 3e 74 05
 RIP  [813bd796] pci_get_dma_source+0xf/0x41
   RSP8806264d1d88
 CR2: 003c
 ---[ end trace 5c5a2ceca067e0ec ]---
 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009

 [ cut here ]
 WARNING: at arch/x86/kernel/smp.c:123
 native_smp_send_reschedule+0x25/0x51()
 Hardware name: Relion 1751
 Modules linked in:
 Pid: 1, comm: swapper/0 Tainted: G  D  3.7.0-rc5 #1
 Call Trace:
   IRQ   [810968ee] warn_slowpath_common+0x80

Re: [PATCH] intel-iommu: Fix lookup in add device

2012-11-13 Thread Matthew Thode 
On 11/13/2012 11:22 AM, Alex Williamson wrote:
 We can't assume this device exists, fall back to the bridge itself.
 
 Signed-off-by: Alex Williamson alex.william...@redhat.com
 Tested-by: Matthew Thode prometheanf...@gentoo.org
 Cc: sta...@vger.kernel.org
 ---
  drivers/iommu/intel-iommu.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
 index d4a4cd4..0badfa4 100644
 --- a/drivers/iommu/intel-iommu.c
 +++ b/drivers/iommu/intel-iommu.c
 @@ -4108,7 +4108,7 @@ static void swap_pci_ref(struct pci_dev **from, struct 
 pci_dev *to)
  static int intel_iommu_add_device(struct device *dev)
  {
   struct pci_dev *pdev = to_pci_dev(dev);
 - struct pci_dev *bridge, *dma_pdev;
 + struct pci_dev *bridge, *dma_pdev = NULL;
   struct iommu_group *group;
   int ret;
  
 @@ -4122,7 +4122,7 @@ static int intel_iommu_add_device(struct device *dev)
   dma_pdev = pci_get_domain_bus_and_slot(
   pci_domain_nr(pdev-bus),
   bridge-subordinate-number, 0);
 - else
 + if (!dma_pdev)
   dma_pdev = pci_dev_get(bridge);
   } else
   dma_pdev = pci_dev_get(pdev);
 

I've tested this and it works just fine.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

Re: [BUG 3.7-rc5] NULL pointer deref when using a pcie-pci bridged pci device and intel-iommu

2012-11-13 Thread Matthew Thode 
On 11/13/2012 01:10 PM, Alex Williamson wrote:
 On Tue, 2012-11-13 at 14:05 -0500, Don Dutile wrote:
 On 11/13/2012 10:38 AM, Alex Williamson wrote:
 On Mon, 2012-11-12 at 15:05 -0600, Matthew Thode wrote:
 On 11/12/2012 01:57 PM, Don Dutile wrote:
 On 11/12/2012 04:26 AM, Doug Goldstein wrote:
 On Sun, Nov 11, 2012 at 5:19 PM, Matthew Thode
 prometheanf...@gentoo.org   wrote:
 System boots with vt-d disabled in bios. Otherwise I get the errors in
 the attached log.  I can do whatever testing you need as this system is
 not in production yet.  gonna paste the important part here.  Let me
 know if you want anything else.

 Please CC me directly as I am not subscribed to the LKML.


 Trying to unpack rootfs image as initramfs...
 Freeing initrd memory: 5124k freed
 IOMMU 0 0xfbffe000: using Queued invalidation
 IOMMU: Setting RMRR:
 IOMMU: Setting identity map for device :00:1d.0 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1d.1 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1d.2 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1d.7 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1a.0 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1a.1 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1a.2 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1a.7 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1d.0 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1d.1 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1d.2 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1d.7 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1a.0 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1a.1 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1a.2 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1a.7 [0xec000 - 0xe]
 IOMMU: Prepare 0-16MiB unity mapping for LPC
 IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0xff]
 PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
 BUG: unable to handle kernel NULL pointer dereference at
 003c
 IP: [813bd796] pci_get_dma_source+0xf/0x41
 PGD 0
 Oops:  [#1] SMP
 Modules linked in:
 CPU 7
 Pid: 1, comm: swapper/0 Not tainted 3.7.0-rc5 #1 Penguin Computing
 Relion 1751/X8DTU
 RIP: 0010:[813bd796]  [813bd796]
 pci_get_dma_source+0xf/0x41
 RSP: :8806264d1d88  EFLAGS: 00010282
 RAX: 813bd3a8 RBX: 8806261d1000 RCX: e8221180
 RDX: 818624f0 RSI: 88062635b0c0 RDI: 
 RBP: 8806264d1d88 R08: 8806263d6000 R09: 
 R10: 8806264d1ca8 R11: 0005 R12: 
 R13: 8806261d1098 R14:  R15: 
 FS:  () GS:88063f2e()
 knlGS:
 CS:  0010 DS:  ES:  CR0: 8005003b
 CR2: 003c CR3: 01c0b000 CR4: 07e0
 DR0:  DR1:  DR2: 
 DR3:  DR6: 0ff0 DR7: 0400
 Process swapper/0 (pid: 1, threadinfo 8806264d, task
 8806264cf910)
 Stack:
8806264d1dc8 815d02c9  8806
8806264d1dd8 81c64b00 8806261d1098 8806264d1df8
8806264d1de8 815cd5a4 81c64b00 815cd56a
 Call Trace:
[815d02c9] intel_iommu_add_device+0x95/0x167
[815cd5a4] add_iommu_group+0x3a/0x41
[815cd56a] ? bus_set_iommu+0x44/0x44
[8145eca1] bus_for_each_dev+0x54/0x81
[815cd563] bus_set_iommu+0x3d/0x44
[81cd3fa3] intel_iommu_init+0xae5/0xb5e
[81ca0277] ? free_initrd+0x9e/0x9e
[81ca4248] ? memblock_find_dma_reserve+0x13f/0x13f
[81ca425e] pci_iommu_init+0x16/0x41
[81cc4140] ? pci_proc_init+0x6b/0x6b
[81000231] do_one_initcall+0x7a/0x129
[816dac14] kernel_init+0x139/0x2a2
[81c9d4c7] ? loglevel+0x31/0x31
[816daadb] ? rest_init+0x6f/0x6f
[816f66ac] ret_from_fork+0x7c/0xb0
[816daadb] ? rest_init+0x6f/0x6f
 Code: ff c1 75 04 ff d0 eb 12 48 83 c2 10 48 8b 42 08 48 85 c0 75 d3 b8
 e7 ff ff ff c9 c3 55 48 c7 c2 f0 24 86 81 48 89 e5 eb 24 8b 0a66   3b
 4f 3c 74 05 66 ff c1 75 13 66 8b 4a 02 66 3b 4f 3e 74 05
 RIP  [813bd796] pci_get_dma_source+0xf/0x41
RSP8806264d1d88
 CR2: 003c
 ---[ end trace 5c5a2ceca067e0ec ]---
 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009

 [ cut here ]
 WARNING: at arch/x86/kernel/smp.c:123
 native_smp_send_reschedule+0x25/0x51()
 Hardware name: Relion 1751
 Modules linked in:
 Pid: 1

Re: [BUG 3.7-rc5] NULL pointer deref when using a pcie-pci bridged pci device and intel-iommu

2012-11-12 Thread Matthew Thode 
On 11/12/2012 01:57 PM, Don Dutile wrote:
> On 11/12/2012 04:26 AM, Doug Goldstein wrote:
>> On Sun, Nov 11, 2012 at 5:19 PM, Matthew Thode
>>   wrote:
>>> System boots with vt-d disabled in bios. Otherwise I get the errors in
>>> the attached log.  I can do whatever testing you need as this system is
>>> not in production yet.  gonna paste the important part here.  Let me
>>> know if you want anything else.
>>>
>>> Please CC me directly as I am not subscribed to the LKML.
>>>
>>>
>>> Trying to unpack rootfs image as initramfs...
>>> Freeing initrd memory: 5124k freed
>>> IOMMU 0 0xfbffe000: using Queued invalidation
>>> IOMMU: Setting RMRR:
>>> IOMMU: Setting identity map for device :00:1d.0 [0xbf7ec000 -
>>> 0xbf7f]
>>> IOMMU: Setting identity map for device :00:1d.1 [0xbf7ec000 -
>>> 0xbf7f]
>>> IOMMU: Setting identity map for device :00:1d.2 [0xbf7ec000 -
>>> 0xbf7f]
>>> IOMMU: Setting identity map for device :00:1d.7 [0xbf7ec000 -
>>> 0xbf7f]
>>> IOMMU: Setting identity map for device :00:1a.0 [0xbf7ec000 -
>>> 0xbf7f]
>>> IOMMU: Setting identity map for device :00:1a.1 [0xbf7ec000 -
>>> 0xbf7f]
>>> IOMMU: Setting identity map for device :00:1a.2 [0xbf7ec000 -
>>> 0xbf7f]
>>> IOMMU: Setting identity map for device :00:1a.7 [0xbf7ec000 -
>>> 0xbf7f]
>>> IOMMU: Setting identity map for device :00:1d.0 [0xec000 - 0xe]
>>> IOMMU: Setting identity map for device :00:1d.1 [0xec000 - 0xe]
>>> IOMMU: Setting identity map for device :00:1d.2 [0xec000 - 0xe]
>>> IOMMU: Setting identity map for device :00:1d.7 [0xec000 - 0xe]
>>> IOMMU: Setting identity map for device :00:1a.0 [0xec000 - 0xe]
>>> IOMMU: Setting identity map for device :00:1a.1 [0xec000 - 0xe]
>>> IOMMU: Setting identity map for device :00:1a.2 [0xec000 - 0xe]
>>> IOMMU: Setting identity map for device :00:1a.7 [0xec000 - 0xe]
>>> IOMMU: Prepare 0-16MiB unity mapping for LPC
>>> IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0xff]
>>> PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
>>> BUG: unable to handle kernel NULL pointer dereference at
>>> 003c
>>> IP: [] pci_get_dma_source+0xf/0x41
>>> PGD 0
>>> Oops:  [#1] SMP
>>> Modules linked in:
>>> CPU 7
>>> Pid: 1, comm: swapper/0 Not tainted 3.7.0-rc5 #1 Penguin Computing
>>> Relion 1751/X8DTU
>>> RIP: 0010:[]  []
>>> pci_get_dma_source+0xf/0x41
>>> RSP: :8806264d1d88  EFLAGS: 00010282
>>> RAX: 813bd3a8 RBX: 8806261d1000 RCX: e8221180
>>> RDX: 818624f0 RSI: 88062635b0c0 RDI: 
>>> RBP: 8806264d1d88 R08: 8806263d6000 R09: 
>>> R10: 8806264d1ca8 R11: 0005 R12: 
>>> R13: 8806261d1098 R14:  R15: 
>>> FS:  () GS:88063f2e()
>>> knlGS:
>>> CS:  0010 DS:  ES:  CR0: 8005003b
>>> CR2: 003c CR3: 01c0b000 CR4: 07e0
>>> DR0:  DR1:  DR2: 
>>> DR3:  DR6: 0ff0 DR7: 0400
>>> Process swapper/0 (pid: 1, threadinfo 8806264d, task
>>> 8806264cf910)
>>> Stack:
>>>   8806264d1dc8 815d02c9  8806
>>>   8806264d1dd8 81c64b00 8806261d1098 8806264d1df8
>>>   8806264d1de8 815cd5a4 81c64b00 815cd56a
>>> Call Trace:
>>>   [] intel_iommu_add_device+0x95/0x167
>>>   [] add_iommu_group+0x3a/0x41
>>>   [] ? bus_set_iommu+0x44/0x44
>>>   [] bus_for_each_dev+0x54/0x81
>>>   [] bus_set_iommu+0x3d/0x44
>>>   [] intel_iommu_init+0xae5/0xb5e
>>>   [] ? free_initrd+0x9e/0x9e
>>>   [] ? memblock_find_dma_reserve+0x13f/0x13f
>>>   [] pci_iommu_init+0x16/0x41
>>>   [] ? pci_proc_init+0x6b/0x6b
>>>   [] do_one_initcall+0x7a/0x129
>>>   [] kernel_init+0x139/0x2a2
>>>   [] ? loglevel+0x31/0x31
>>>   [] ? rest_init+0x6f/0x6f
>>>   [] ret_from_fork+0x7c/0xb0
>>>   [] ? rest_init+0x6f/0x6f
>>> Code: ff c1 75 04 ff d0 eb 12 48 83 c2 10 48 8b 42 08 48 85 c0 75 d3 b8
>&g

Re: [BUG 3.7-rc5] NULL pointer deref when using a pcie-pci bridged pci device and intel-iommu

2012-11-12 Thread Matthew Thode 
On 11/12/2012 01:57 PM, Don Dutile wrote:
 On 11/12/2012 04:26 AM, Doug Goldstein wrote:
 On Sun, Nov 11, 2012 at 5:19 PM, Matthew Thode
 prometheanf...@gentoo.org  wrote:
 System boots with vt-d disabled in bios. Otherwise I get the errors in
 the attached log.  I can do whatever testing you need as this system is
 not in production yet.  gonna paste the important part here.  Let me
 know if you want anything else.

 Please CC me directly as I am not subscribed to the LKML.


 Trying to unpack rootfs image as initramfs...
 Freeing initrd memory: 5124k freed
 IOMMU 0 0xfbffe000: using Queued invalidation
 IOMMU: Setting RMRR:
 IOMMU: Setting identity map for device :00:1d.0 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1d.1 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1d.2 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1d.7 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1a.0 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1a.1 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1a.2 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1a.7 [0xbf7ec000 -
 0xbf7f]
 IOMMU: Setting identity map for device :00:1d.0 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1d.1 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1d.2 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1d.7 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1a.0 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1a.1 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1a.2 [0xec000 - 0xe]
 IOMMU: Setting identity map for device :00:1a.7 [0xec000 - 0xe]
 IOMMU: Prepare 0-16MiB unity mapping for LPC
 IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0xff]
 PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
 BUG: unable to handle kernel NULL pointer dereference at
 003c
 IP: [813bd796] pci_get_dma_source+0xf/0x41
 PGD 0
 Oops:  [#1] SMP
 Modules linked in:
 CPU 7
 Pid: 1, comm: swapper/0 Not tainted 3.7.0-rc5 #1 Penguin Computing
 Relion 1751/X8DTU
 RIP: 0010:[813bd796]  [813bd796]
 pci_get_dma_source+0xf/0x41
 RSP: :8806264d1d88  EFLAGS: 00010282
 RAX: 813bd3a8 RBX: 8806261d1000 RCX: e8221180
 RDX: 818624f0 RSI: 88062635b0c0 RDI: 
 RBP: 8806264d1d88 R08: 8806263d6000 R09: 
 R10: 8806264d1ca8 R11: 0005 R12: 
 R13: 8806261d1098 R14:  R15: 
 FS:  () GS:88063f2e()
 knlGS:
 CS:  0010 DS:  ES:  CR0: 8005003b
 CR2: 003c CR3: 01c0b000 CR4: 07e0
 DR0:  DR1:  DR2: 
 DR3:  DR6: 0ff0 DR7: 0400
 Process swapper/0 (pid: 1, threadinfo 8806264d, task
 8806264cf910)
 Stack:
   8806264d1dc8 815d02c9  8806
   8806264d1dd8 81c64b00 8806261d1098 8806264d1df8
   8806264d1de8 815cd5a4 81c64b00 815cd56a
 Call Trace:
   [815d02c9] intel_iommu_add_device+0x95/0x167
   [815cd5a4] add_iommu_group+0x3a/0x41
   [815cd56a] ? bus_set_iommu+0x44/0x44
   [8145eca1] bus_for_each_dev+0x54/0x81
   [815cd563] bus_set_iommu+0x3d/0x44
   [81cd3fa3] intel_iommu_init+0xae5/0xb5e
   [81ca0277] ? free_initrd+0x9e/0x9e
   [81ca4248] ? memblock_find_dma_reserve+0x13f/0x13f
   [81ca425e] pci_iommu_init+0x16/0x41
   [81cc4140] ? pci_proc_init+0x6b/0x6b
   [81000231] do_one_initcall+0x7a/0x129
   [816dac14] kernel_init+0x139/0x2a2
   [81c9d4c7] ? loglevel+0x31/0x31
   [816daadb] ? rest_init+0x6f/0x6f
   [816f66ac] ret_from_fork+0x7c/0xb0
   [816daadb] ? rest_init+0x6f/0x6f
 Code: ff c1 75 04 ff d0 eb 12 48 83 c2 10 48 8b 42 08 48 85 c0 75 d3 b8
 e7 ff ff ff c9 c3 55 48 c7 c2 f0 24 86 81 48 89 e5 eb 24 8b 0a66  3b
 4f 3c 74 05 66 ff c1 75 13 66 8b 4a 02 66 3b 4f 3e 74 05
 RIP  [813bd796] pci_get_dma_source+0xf/0x41
   RSP8806264d1d88
 CR2: 003c
 ---[ end trace 5c5a2ceca067e0ec ]---
 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009

 [ cut here ]
 WARNING: at arch/x86/kernel/smp.c:123
 native_smp_send_reschedule+0x25/0x51()
 Hardware name: Relion 1751
 Modules linked in:
 Pid: 1, comm: swapper/0 Tainted: G  D  3.7.0-rc5 #1
 Call Trace:
   IRQ   [810968ee] warn_slowpath_common+0x80/0x98
   [8109691b] warn_slowpath_null+0x15/0x17
   [8104e1a3] native_smp_send_reschedule

[BUG 3.7-rc5] NULL pointer deref when using a pcie-pci bridged pci device and intel-iommu

2012-11-11 Thread Matthew Thode 
x9/0xb
 [] ? klist_put+0x4c/0x70
 [] ? klist_next+0x30/0xb6
 [] ? pci_do_find_bus+0x49/0x49
 [] do_page_fault+0x9/0xb
 [] page_fault+0x22/0x30
 [] ? nv_msi_ht_cap_quirk_all+0x10/0x10
 [] ? pci_get_dma_source+0xf/0x41
 [] intel_iommu_add_device+0x95/0x167
 [] add_iommu_group+0x3a/0x41
 [] ? bus_set_iommu+0x44/0x44
 [] bus_for_each_dev+0x54/0x81
 [] bus_set_iommu+0x3d/0x44
 [] intel_iommu_init+0xae5/0xb5e
 [] ? free_initrd+0x9e/0x9e
 [] ? memblock_find_dma_reserve+0x13f/0x13f
 [] pci_iommu_init+0x16/0x41
 [] ? pci_proc_init+0x6b/0x6b
 [] do_one_initcall+0x7a/0x129
 [] kernel_init+0x139/0x2a2
 [] ? loglevel+0x31/0x31
 [] ? rest_init+0x6f/0x6f
 [] ret_from_fork+0x7c/0xb0
 [] ? rest_init+0x6f/0x6f
---[ end trace 5c5a2ceca067e0ed ]---

-- 
-- Matthew Thode (prometheanfire)
Initializing cgroup subsys cpuset
Linux version 3.7.0-rc5 (root@vm-master-01) (gcc version 4.5.4 (Gentoo Hardened 
4.5.4 p1.0, pie-0.4.7) ) #1 SMP Sun Nov 11 13:51:19 CST 2012
Command line: rootfstype=ext4 real_root=/dev/mapper/vg-rootfs 
real_rootflags=noatime,nodev,acl,user_xattr 
crypt_root=UUID=4b11f604-66b2-4673-a50d-d88e5fc9a8b3 domdadm dolvm 
netconsole=@10.10.2.2/eth0,@10.10.2.1/4e:9c:bc:82:6d:d6;netconsole=@10.10.2.2/eth1,@10.10.2.1/4e:9c:bc:82:6d:d6;netconsole=@10.10.2.2/eth2,@10.10.2.1/4e:9c:bc:82:6d:d6
 console=ttyS0,115200n8 ro
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x00097bff] usable
BIOS-e820: [mem 0x00097c00-0x0009] reserved
BIOS-e820: [mem 0x000e-0x000f] reserved
BIOS-e820: [mem 0x0010-0xbf77] usable
BIOS-e820: [mem 0xbf78e000-0xbf78] type 9
BIOS-e820: [mem 0xbf79-0xbf79dfff] ACPI data
BIOS-e820: [mem 0xbf79e000-0xbf7c] ACPI NVS
BIOS-e820: [mem 0xbf7d-0xbf7d] reserved
BIOS-e820: [mem 0xbf7ec000-0xbfff] reserved
BIOS-e820: [mem 0xe000-0xefff] reserved
BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
BIOS-e820: [mem 0xffc0-0x] reserved
BIOS-e820: [mem 0x0001-0x00063fff] usable
NX (Execute Disable) protection: active
DMI present.
No AGP bridge found
e820: last_pfn = 0x64 max_arch_pfn = 0x4
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
e820: last_pfn = 0xbf780 max_arch_pfn = 0x4
found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [880ff780]
init_memory_mapping: [mem 0x-0xbf77]
init_memory_mapping: [mem 0x1-0x63fff]
RAMDISK: [mem 0x37aef000-0x37fe]
ACPI: RSDP 000face0 00024 (v02 ACPIAM)
ACPI: XSDT bf790100 00084 (v01 SMCI20120803 MSFT 0097)
ACPI: FACP bf790290 000F4 (v04 080312 FACP1521 20120803 MSFT 0097)
ACPI: DSDT bf7906a0 06580 (v02  10600 1060  INTL 20051117)
ACPI: FACS bf79e000 00040
ACPI: APIC bf790390 0011E (v02 080312 APIC1521 20120803 MSFT 0097)
ACPI: MCFG bf7904b0 0003C (v01 080312 OEMMCFG  20120803 MSFT 0097)
ACPI: SLIT bf7904f0 00030 (v01 080312 OEMSLIT  20120803 MSFT 0097)
ACPI: OEMB bf79e040 00086 (v01 080312 OEMB1521 20120803 MSFT 0097)
ACPI: HPET bf79a6a0 00038 (v01 080312 OEMHPET  20120803 MSFT 0097)
ACPI: DMAR bf79e0d0 00130 (v01AMI  OEMDMAR 0001 MSFT 0097)
ACPI: SSDT bf79fe40 00363 (v01 DpgPmmCpuPm 0012 INTL 20051117)
ACPI: EINJ bf79a6e0 00130 (v01  AMIER AMI_EINJ 20120803 MSFT 0097)
ACPI: BERT bf79a870 00030 (v01  AMIER AMI_BERT 20120803 MSFT 0097)
ACPI: ERST bf79a8a0 001B0 (v01  AMIER AMI_ERST 20120803 MSFT 0097)
ACPI: HEST bf79aa50 000A8 (v01  AMIER ABC_HEST 20120803 MSFT 0097)
NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10
No NUMA configuration found
Faking a node at [mem 0x-0x00063fff]
Initmem setup node 0 [mem 0x-0x63fff]
  NODE_DATA [mem 0x63fffc000-0x63fff]
Zone ranges:
  DMA  [mem 0x0001-0x00ff]
  DMA32[mem 0x0100-0x]
  Normal   [mem 0x1-0x63fff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0001-0x00096fff]
  node   0: [mem 0x0010-0xbf77]
  node   0: [mem 0x1-0x63fff]
ACPI: PM-Timer IO Port: 0x808
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
ACPI: LAPIC (acpi_id[0x09] lapic_id[0x88] disabled)
ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x89] disabled)
ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x8a] disabled

[BUG 3.7-rc5] NULL pointer deref when using a pcie-pci bridged pci device and intel-iommu

2012-11-11 Thread Matthew Thode 
+0xc7/0x1ac
 [8104ef01] smp_apic_timer_interrupt+0x81/0x94
 [816f71ca] apic_timer_interrupt+0x6a/0x70
 EOI  [81097ffc] ? console_unlock+0x2c2/0x2ed
 [816f32fc] ? panic+0x189/0x1c5
 [816f3261] ? panic+0xee/0x1c5
 [8109ab6b] do_exit+0x357/0x7b2
 [810371b8] oops_end+0xb2/0xba
 [8105841d] no_context+0x266/0x275
 [810585e7] __bad_area_nosemaphore+0x1bb/0x1db
 [8118de46] ? sysfs_addrm_finish+0x2f/0xa6
 [81058615] bad_area_nosemaphore+0xe/0x10
 [81058bdb] __do_page_fault+0x360/0x39f
 [81394afa] ? ida_get_new_above+0xf9/0x19e
 [8112a077] ? slab_node+0x59/0xa2
 [816f3ffd] ? mutex_unlock+0x9/0xb
 [816da653] ? klist_put+0x4c/0x70
 [816da581] ? klist_next+0x30/0xb6
 [813b8cf9] ? pci_do_find_bus+0x49/0x49
 [81058c42] do_page_fault+0x9/0xb
 [816f6232] page_fault+0x22/0x30
 [813bd3a8] ? nv_msi_ht_cap_quirk_all+0x10/0x10
 [813bd796] ? pci_get_dma_source+0xf/0x41
 [815d02c9] intel_iommu_add_device+0x95/0x167
 [815cd5a4] add_iommu_group+0x3a/0x41
 [815cd56a] ? bus_set_iommu+0x44/0x44
 [8145eca1] bus_for_each_dev+0x54/0x81
 [815cd563] bus_set_iommu+0x3d/0x44
 [81cd3fa3] intel_iommu_init+0xae5/0xb5e
 [81ca0277] ? free_initrd+0x9e/0x9e
 [81ca4248] ? memblock_find_dma_reserve+0x13f/0x13f
 [81ca425e] pci_iommu_init+0x16/0x41
 [81cc4140] ? pci_proc_init+0x6b/0x6b
 [81000231] do_one_initcall+0x7a/0x129
 [816dac14] kernel_init+0x139/0x2a2
 [81c9d4c7] ? loglevel+0x31/0x31
 [816daadb] ? rest_init+0x6f/0x6f
 [816f66ac] ret_from_fork+0x7c/0xb0
 [816daadb] ? rest_init+0x6f/0x6f
---[ end trace 5c5a2ceca067e0ed ]---

-- 
-- Matthew Thode (prometheanfire)
Initializing cgroup subsys cpuset
Linux version 3.7.0-rc5 (root@vm-master-01) (gcc version 4.5.4 (Gentoo Hardened 
4.5.4 p1.0, pie-0.4.7) ) #1 SMP Sun Nov 11 13:51:19 CST 2012
Command line: rootfstype=ext4 real_root=/dev/mapper/vg-rootfs 
real_rootflags=noatime,nodev,acl,user_xattr 
crypt_root=UUID=4b11f604-66b2-4673-a50d-d88e5fc9a8b3 domdadm dolvm 
netconsole=@10.10.2.2/eth0,@10.10.2.1/4e:9c:bc:82:6d:d6;netconsole=@10.10.2.2/eth1,@10.10.2.1/4e:9c:bc:82:6d:d6;netconsole=@10.10.2.2/eth2,@10.10.2.1/4e:9c:bc:82:6d:d6
 console=ttyS0,115200n8 ro
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x00097bff] usable
BIOS-e820: [mem 0x00097c00-0x0009] reserved
BIOS-e820: [mem 0x000e-0x000f] reserved
BIOS-e820: [mem 0x0010-0xbf77] usable
BIOS-e820: [mem 0xbf78e000-0xbf78] type 9
BIOS-e820: [mem 0xbf79-0xbf79dfff] ACPI data
BIOS-e820: [mem 0xbf79e000-0xbf7c] ACPI NVS
BIOS-e820: [mem 0xbf7d-0xbf7d] reserved
BIOS-e820: [mem 0xbf7ec000-0xbfff] reserved
BIOS-e820: [mem 0xe000-0xefff] reserved
BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
BIOS-e820: [mem 0xffc0-0x] reserved
BIOS-e820: [mem 0x0001-0x00063fff] usable
NX (Execute Disable) protection: active
DMI present.
No AGP bridge found
e820: last_pfn = 0x64 max_arch_pfn = 0x4
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
e820: last_pfn = 0xbf780 max_arch_pfn = 0x4
found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [880ff780]
init_memory_mapping: [mem 0x-0xbf77]
init_memory_mapping: [mem 0x1-0x63fff]
RAMDISK: [mem 0x37aef000-0x37fe]
ACPI: RSDP 000face0 00024 (v02 ACPIAM)
ACPI: XSDT bf790100 00084 (v01 SMCI20120803 MSFT 0097)
ACPI: FACP bf790290 000F4 (v04 080312 FACP1521 20120803 MSFT 0097)
ACPI: DSDT bf7906a0 06580 (v02  10600 1060  INTL 20051117)
ACPI: FACS bf79e000 00040
ACPI: APIC bf790390 0011E (v02 080312 APIC1521 20120803 MSFT 0097)
ACPI: MCFG bf7904b0 0003C (v01 080312 OEMMCFG  20120803 MSFT 0097)
ACPI: SLIT bf7904f0 00030 (v01 080312 OEMSLIT  20120803 MSFT 0097)
ACPI: OEMB bf79e040 00086 (v01 080312 OEMB1521 20120803 MSFT 0097)
ACPI: HPET bf79a6a0 00038 (v01 080312 OEMHPET  20120803 MSFT 0097)
ACPI: DMAR bf79e0d0 00130 (v01AMI  OEMDMAR 0001 MSFT 0097)
ACPI: SSDT bf79fe40 00363 (v01 DpgPmmCpuPm 0012 INTL 20051117)
ACPI: EINJ bf79a6e0 00130 (v01  AMIER AMI_EINJ 20120803 MSFT 0097)
ACPI: BERT bf79a870 00030 (v01  AMIER AMI_BERT 20120803 MSFT 0097)
ACPI: ERST bf79a8a0 001B0 (v01  AMIER AMI_ERST 20120803 MSFT 0097)
ACPI: HEST bf79aa50 000A8 (v01  AMIER ABC_HEST 20120803 MSFT 0097)
NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10