Re: [PATCH v2] Staging: gasket: Use temporaries to reduce line length.

[Sandro Volery LKML]

Wow... I checked, compiled and still sent the wrong thing again. I'm gonna have 
to give this up soon if i can't get it right.

Sandro V

> On 10 Sep 2019, at 07:06, Sandro Volery  wrote:
> 
> Using temporaries for gasket_page_table entries to remove scnprintf()
> statements and reduce line length, as suggested by Joe Perches. Thanks!
> 
> Signed-off-by: Sandro Volery 
> ---
> drivers/staging/gasket/apex_driver.c | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/staging/gasket/apex_driver.c 
> b/drivers/staging/gasket/apex_driver.c
> index 2973bb920a26..16ac4329d65f 100644
> --- a/drivers/staging/gasket/apex_driver.c
> +++ b/drivers/staging/gasket/apex_driver.c
> @@ -509,6 +509,8 @@ static ssize_t sysfs_show(struct device *device, struct 
> device_attribute *attr,
>struct gasket_dev *gasket_dev;
>struct gasket_sysfs_attribute *gasket_attr;
>enum sysfs_attribute_type type;
> +struct gasket_page_table *gpt;
> +uint val;
> 
>gasket_dev = gasket_sysfs_get_device_data(device);
>if (!gasket_dev) {
> @@ -524,29 +526,25 @@ static ssize_t sysfs_show(struct device *device, struct 
> device_attribute *attr,
>}
> 
>type = (enum sysfs_attribute_type)gasket_attr->data.attr_type;
> +gpt = gasket_dev->page_table[0];
>switch (type) {
>case ATTR_KERNEL_HIB_PAGE_TABLE_SIZE:
> -ret = scnprintf(buf, PAGE_SIZE, "%u\n",
> -gasket_page_table_num_entries(
> -gasket_dev->page_table[0]));
> +val = gasket_page_table_num_simple_entries(gpt);
>break;
>case ATTR_KERNEL_HIB_SIMPLE_PAGE_TABLE_SIZE:
> -ret = scnprintf(buf, PAGE_SIZE, "%u\n",
> -gasket_page_table_num_simple_entries(
> -gasket_dev->page_table[0]));
> +val = gasket_page_table_num_simple_entries(gpt);
>break;
>case ATTR_KERNEL_HIB_NUM_ACTIVE_PAGES:
> -ret = scnprintf(buf, PAGE_SIZE, "%u\n",
> -gasket_page_table_num_active_pages(
> -gasket_dev->page_table[0]));
> +val = gasket_page_table_num_active_pages(gpt);
>break;
>default:
>dev_dbg(gasket_dev->dev, "Unknown attribute: %s\n",
>attr->attr.name);
>ret = 0;
> -break;
> +goto exit;
>}
> -
> +ret = scnprintf(buf, PAGE_SIZE, "%u\n", val);
> +exit:
>gasket_sysfs_put_attr(device, gasket_attr);
>gasket_sysfs_put_device_data(device, gasket_dev);
>return ret;
> -- 
> 2.23.0
> 

Re: [PATCH] Fixed most indent issues in tty_io.c

[Sandro Volery LKML]

Sandro V

> On 7 Sep 2019, at 20:03, Greg KH  wrote:
> 
> On Sat, Sep 07, 2019 at 07:49:43PM +0200, Sandro Volery wrote:
>> 
>> 
>> 
>> 
 On 7 Sep 2019, at 19:42, Greg KH  wrote:
>>> 
>>> On Sat, Sep 07, 2019 at 07:35:42PM +0200, Sandro Volery wrote:
 
 
 On 7 Sep 2019, at 19:29, Greg KH  wrote:
>>> On Sat, Sep 07, 2019 at 07:23:59PM +0200, Sandro Volery wrote:
>>> Dear Greg,
>>> I am pretty sure the issue was, that I did too many things at once. 
>>> However, all the things I did are related to spaces / tabs, maybe that 
>>> still works?
> 
> 
> 
> For some reason you sent this only to me, which is a bit rude to
> everyone else on the mailing list.  I'll be glad to respond if you
> resend it to everyone.
 
 I'm sorry, newbie here. I thought it'd be better to not annoy everyone 
 with responses but learning things everyday I guess :)
>>> 
>>> No problem, but you should also line-wrap your emails :)
>> 
>> I've just been told that before, I'll try to change 
>> those settings asap.
>> 
>>> 
 I am pretty sure the issue with my patch was that there was too many 
 changes, however all of them were spaces and tabs related, so I think this 
 could be fine?
>>> 
>>> As the bot said, break it out into "one patch per logical change", and
>>> "fix all whitespace issues" is not "one logical change".
>> 
>> So a logical change would be if I make one patch
>> to replace all spaces with tabs and a separate
>> patch to add a space before the : ?
> 
> Yes, that would be good.  Make it a patch series please.

Thanks!

Any suggestion on how I should do the line wrapping
when I want to send emails from my phone?
Since I don't always have my laptop handy.

Sandro V.

[PATCH] PCI: Do not use bus number zero from EA capability

[sundeep . lkml]

From: Subbaraya Sundeep 

As per the spec, "Enhanced Allocation (EA) for Memory
and I/O Resources" ECN, approved 23 October 2014,
sec 6.9.1.2, fixed bus numbers of a bridge can be zero
when no function that uses EA is located behind it.
Hence assign bus numbers sequentially when fixed bus
numbers are zero.

Fixes: 2dbce590117981196fe355efc0569bc6f949ae9b

Signed-off-by: Subbaraya Sundeep 
---
 drivers/pci/probe.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index a3c7338..c06ca4c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1095,27 +1095,28 @@ static unsigned int pci_scan_child_bus_extend(struct 
pci_bus *bus,
  * @sub: updated with subordinate bus number from EA
  *
  * If @dev is a bridge with EA capability, update @sec and @sub with
- * fixed bus numbers from the capability and return true.  Otherwise,
- * return false.
+ * fixed bus numbers from the capability. Otherwise @sec and @sub
+ * will be zeroed.
  */
-static bool pci_ea_fixed_busnrs(struct pci_dev *dev, u8 *sec, u8 *sub)
+static void pci_ea_fixed_busnrs(struct pci_dev *dev, u8 *sec, u8 *sub)
 {
int ea, offset;
u32 dw;
 
+   *sec = *sub = 0;
+
if (dev->hdr_type != PCI_HEADER_TYPE_BRIDGE)
-   return false;
+   return;
 
/* find PCI EA capability in list */
ea = pci_find_capability(dev, PCI_CAP_ID_EA);
if (!ea)
-   return false;
+   return;
 
offset = ea + PCI_EA_FIRST_ENT;
pci_read_config_dword(dev, offset, &dw);
*sec =  dw & PCI_EA_SEC_BUS_MASK;
*sub = (dw & PCI_EA_SUB_BUS_MASK) >> PCI_EA_SUB_BUS_SHIFT;
-   return true;
 }
 
 /*
@@ -1151,7 +1152,6 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, 
struct pci_dev *dev,
u16 bctl;
u8 primary, secondary, subordinate;
int broken = 0;
-   bool fixed_buses;
u8 fixed_sec, fixed_sub;
int next_busnr;
 
@@ -1254,11 +1254,12 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, 
struct pci_dev *dev,
pci_write_config_word(dev, PCI_STATUS, 0x);
 
/* Read bus numbers from EA Capability (if present) */
-   fixed_buses = pci_ea_fixed_busnrs(dev, &fixed_sec, &fixed_sub);
-   if (fixed_buses)
+   pci_ea_fixed_busnrs(dev, &fixed_sec, &fixed_sub);
+
+   next_busnr = max + 1;
+   /* Use secondary bus number in EA */
+   if (fixed_sec)
next_busnr = fixed_sec;
-   else
-   next_busnr = max + 1;
 
/*
 * Prevent assigning a bus number that already exists.
@@ -1336,7 +1337,7 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, 
struct pci_dev *dev,
 * If fixed subordinate bus number exists from EA
 * capability then use it.
 */
-   if (fixed_buses)
+   if (fixed_sub)
max = fixed_sub;
pci_bus_update_busn_res_end(child, max);
pci_write_config_byte(dev, PCI_SUBORDINATE_BUS, max);
-- 
2.7.4

Re: [PATCH 1/5] lib/sort: Make swap functions more generic

[lkml]

Thnk you for the feedback!

Andy Shevchenko wrote:
> On Thu, Feb 21, 2019 at 06:30:28AM +, George Spelvin wrote:
>> +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> 
> Why #ifdef is better than if (IS_ENABLED()) ?

Because CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is bool and not
tristate.  IS_ENABLED tests for 'y' or 'm' but we don't need it
for something that's only on or off.

Looking through the kernel, I see both, but #ifdef or #if defined()
are definitely in the majority:

lib/lzo/lzo1x_compress.c:#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && 
defined(LZO_USE_CTZ64)
lib/siphash.c:#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
lib/string.c:#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
lib/strncpy_from_user.c:#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
lib/zlib_inflate/inffast.c:#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS

I see a few IS_ENABLED uses in include/crypto/ and kernel/bpf/.

It makes no real difference; #ifdef is simpler to me.

>> +(void)base;
> 
> I understand the possible weirdness of the case, but 0 pointer is also good, 
> no?

I don't quite understand the question.  A NULL pointer is aligned
as far as alignment_ok is concerned.  In other words, word accesses to
*NULL will (not) work just as well as byte accesses.

None of this matters because the callers never pass in NULL pointers.

>> +#else
>> +lsbits |= (unsigned int)(size_t)base;
> 
> Perhaps you meant simple (uintptr_t) here and maybe above as well.

No, I meant to truncate it to the same type as "align".  We only
care about the low few bits; I could have used (unsigned char) just
as well.

My reason or choosing unsigned int rather than unsigned char was
that both x86 and ARM are a tiny bit more efficient at 32-bit
operations (x86 avoids a REX prefix; ARM gates off the high half
of the ALU to save power), but only x86 does byte operations
natively.

Still, compilers know how to promote to word operations, so
maybe using unsigned char would make it clearer to the
reader that "yes, I meant to do that!".

I've changed it to:

static bool __attribute_const__
is_aligned(const void *base, size_t size, unsigned char align)
{
unsigned char lsbits = (unsigned char)size;
#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
(void)base;
#else
lsbits |= (unsigned char)(uintptr_t)base;
#endif
return (lsbits & (align - 1)) == 0;
}

Although I'm thinking of:

static bool __attribute_const__
is_aligned(const void *base, size_t size, unsigned char align)
{
unsigned char lsbits = (unsigned char)size;

(void)base;
#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
lsbits |= (unsigned char)(uintptr_t)base;
#endif
return (lsbits & (align - 1)) == 0;
}

Any preference?

>> +#endif
>> +lsbits &= align - 1;
>> +return lsbits == 0;
> 
> and this can be one return operation.

It was just to avoid some annoying parentheses because C's precendence
rules and GCC's warnings are fighting me here.  If others prefer
"return (lsbits & (align - 1)) == 0;" I'm happy to change.

>>  static void u32_swap(void *a, void *b, int size)
> 
> For such primitives that operates on top of an arrays we usually append 's' to
> the name. Currently the name is misleading.
> 
> Perhaps u32s_swap().

I don't worry much about the naming of static helper functions.
If they were exported, it would be a whole lot more important!

I find "u32s" confusing; I keep reading the "s" as "signed" rather
than a plural.

How about one of:
swap_bytes / swap_ints / swap_longs
swap_1 / swap_4 / swap_8

> Shouldn't simple memcpy cover these case for both 32- and 64-bit 
> architectures?

This isn't a memcpy, it's a memory *swap*.  To do it with memcpy
requires:
memcpy(temp_buffer, a, size);
memcpy(a, b, size);
memcpy(b, temp_buffer, size);

This is 1.5x as much memory access, and you have to find a large
enough temp_buffer.  (I didn't think a variable-length array on
the stack would make people happy.)

Also, although it is a predictable branch, memcpy() has to check the
alignment of its inputs each call.  The reason for these helpers is
to factor that out.

[v3 PATCH 1/2] PCI: read fixed bus numbers in EA for type 1 functions

[sundeep . lkml]

From: Subbaraya Sundeep 

As per the spec - ECN_Enhanced_Allocation_23_Oct_2014_Final
and section 6.9.1.2, EA capability contains fixed secondary
and subordinate bus numbers for type 1 functions.
This patch adds support to read the fixed bus numbers
from EA capability for bridge.

Signed-off-by: Subbaraya Sundeep 
---
v3:
  As per Bjorn's suggestion placed EA stuff in pci_ea_init and
  captured bus numbers in pci_dev
v2:
  None just added Sean

 drivers/pci/pci.c | 10 --
 include/linux/pci.h   |  4 
 include/uapi/linux/pci_regs.h |  4 
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index c25acac..484b63e 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2909,6 +2909,7 @@ void pci_ea_init(struct pci_dev *dev)
u8 num_ent;
int offset;
int i;
+   u32 dw;
 
/* find PCI EA capability in list */
ea = pci_find_capability(dev, PCI_CAP_ID_EA);
@@ -2922,9 +2923,14 @@ void pci_ea_init(struct pci_dev *dev)
 
offset = ea + PCI_EA_FIRST_ENT;
 
-   /* Skip DWORD 2 for type 1 functions */
-   if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE)
+   /* Note fixed bus numbers for type 1 functions */
+   if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+   pci_read_config_dword(dev, offset, &dw);
+   dev->fixed_sec_busnr = dw & PCI_EA_FIXED_SEC_BUS;
+   dev->fixed_sub_busnr = (dw & PCI_EA_FIXED_SUB_BUS) >>
+   PCI_EA_FIXED_SUB_SHIFT;
offset += 4;
+   }
 
/* parse each EA entry */
for (i = 0; i < num_ent; ++i)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 65f1d8c..3e9a3ae 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -459,6 +459,10 @@ struct pci_dev {
char*driver_override; /* Driver name to force a match */
 
unsigned long   priv_flags; /* Private flags for the PCI driver */
+
+   /* bus numbers from EA capability if this device is a bridge */
+   u8 fixed_sec_busnr; /* Fixed Secondary Bus number */
+   u8 fixed_sub_busnr; /* Fixed Subordinate Bus number */
 };
 
 static inline struct pci_dev *pci_physfn(struct pci_dev *dev)
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index e1e9888..51e9ac0 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -372,6 +372,10 @@
 #define PCI_EA_FIRST_ENT_BRIDGE8   /* First EA Entry for Bridges */
 #define  PCI_EA_ES 0x0007 /* Entry Size */
 #define  PCI_EA_BEI0x00f0 /* BAR Equivalent Indicator */
+/* Fixed Secondary and Subordinate bus numbers in EA for Bridge */
+#define   PCI_EA_FIXED_SEC_BUS 0xff
+#define   PCI_EA_FIXED_SUB_BUS 0xff00
+#define   PCI_EA_FIXED_SUB_SHIFT   8
 /* 0-5 map to BARs 0-5 respectively */
 #define   PCI_EA_BEI_BAR0  0
 #define   PCI_EA_BEI_BAR5  5
-- 
1.8.3.1

[v3 PATCH 2/2] PCI: assign bus numbers present in EA capability for bridges

[sundeep . lkml]

From: Subbaraya Sundeep 

As per the spec - ECN_Enhanced_Allocation_23_Oct_2014_Final
and section 6.9.1.2, bridges with EA capability work with fixed
secondary and subordinate bus numbers. Hence consider assigning
bus numbers to bridges from EA if the capability exists during
the scan.

Signed-off-by: Subbaraya Sundeep 
---
v3:
  removed function for reading fixed bus numbers
  instead those were captured in pci_ea_init
v2:
  None just added Sean

 drivers/pci/probe.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 257b9f6..9215e2e 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1064,6 +1064,7 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, 
struct pci_dev *dev,
u16 bctl;
u8 primary, secondary, subordinate;
int broken = 0;
+   int next_busnr;
 
/*
 * Make sure the bridge is powered on to be able to access config
@@ -1163,17 +1164,21 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, 
struct pci_dev *dev,
/* Clear errors */
pci_write_config_word(dev, PCI_STATUS, 0x);
 
+   next_busnr = max + 1;
+   /* Fixed secondary bus number from EA capability */
+   if (dev->fixed_sec_busnr)
+   next_busnr = dev->fixed_sec_busnr;
/*
 * Prevent assigning a bus number that already exists.
 * This can happen when a bridge is hot-plugged, so in this
 * case we only re-scan this bus.
 */
-   child = pci_find_bus(pci_domain_nr(bus), max+1);
+   child = pci_find_bus(pci_domain_nr(bus), next_busnr);
if (!child) {
-   child = pci_add_new_bus(bus, dev, max+1);
+   child = pci_add_new_bus(bus, dev, next_busnr);
if (!child)
goto out;
-   pci_bus_insert_busn_res(child, max+1,
+   pci_bus_insert_busn_res(child, next_busnr,
bus->busn_res.end);
}
max++;
@@ -1234,7 +1239,13 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, 
struct pci_dev *dev,
max += i;
}
 
-   /* Set subordinate bus number to its real value */
+   /*
+* Set subordinate bus number to its real value.
+* If fixed subordinate bus number exists from EA
+* capability then use it.
+*/
+   if (dev->fixed_sub_busnr)
+   max = dev->fixed_sub_busnr;
pci_bus_update_busn_res_end(child, max);
pci_write_config_byte(dev, PCI_SUBORDINATE_BUS, max);
}
-- 
1.8.3.1

[PATCH v2] PCI: assign bus numbers present in EA capability for bridges

[sundeep . lkml]

From: Subbaraya Sundeep 

As per the spec, bridges with EA capability work
with fixed secondary and subordinate bus numbers.
Hence assign bus numbers to bridges from EA if the
capability exists.

Signed-off-by: Subbaraya Sundeep 
---
Changes for v2:
No changes just added Sean Stalley who did EA support for BARs.

 drivers/pci/probe.c   | 58 ---
 include/uapi/linux/pci_regs.h |  6 +
 2 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b1c05b5..f41d2e6 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1030,6 +1030,40 @@ static void pci_enable_crs(struct pci_dev *pdev)
 
 static unsigned int pci_scan_child_bus_extend(struct pci_bus *bus,
  unsigned int available_buses);
+/*
+ * pci_ea_fixed_busnrs() - Read fixed Secondary and Subordinate bus
+ * numbers from EA capability.
+ * @dev: Bridge with EA
+ * @secondary: updated with secondary bus number in EA
+ * @subordinate: updated with subordinate bus number in EA
+ *
+ * If it is a bridge with EA capability then fixed bus numbers are
+ * read from EA capability list and secondary, subordinate reference
+ * variables will be updated. Otherwise secondary and subordinate reference
+ * variables will be zeroed.
+ */
+static void pci_ea_fixed_busnrs(struct pci_dev *dev, u8 *secondary,
+   u8 *subordinate)
+{
+   int ea;
+   int offset;
+   u32 dw;
+
+   *secondary = *subordinate = 0;
+
+   if (dev->hdr_type != PCI_HEADER_TYPE_BRIDGE)
+   return;
+
+   /* find PCI EA capability in list */
+   ea = pci_find_capability(dev, PCI_CAP_ID_EA);
+   if (!ea)
+   return;
+
+   offset = ea + PCI_EA_FIRST_ENT;
+   pci_read_config_dword(dev, offset, &dw);
+   *secondary =  dw & PCI_EA_SEC_BUS_MASK;
+   *subordinate = (dw & PCI_EA_SUB_BUS_MASK) >> PCI_EA_SUB_BUS_SHIFT;
+}
 
 /*
  * pci_scan_bridge_extend() - Scan buses behind a bridge
@@ -1064,6 +1098,8 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, 
struct pci_dev *dev,
u16 bctl;
u8 primary, secondary, subordinate;
int broken = 0;
+   u8 fixed_sec, fixed_sub;
+   int next_busnr;
 
/*
 * Make sure the bridge is powered on to be able to access config
@@ -1163,17 +1199,25 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, 
struct pci_dev *dev,
/* Clear errors */
pci_write_config_word(dev, PCI_STATUS, 0x);
 
+   /* read bus numbers from EA */
+   pci_ea_fixed_busnrs(dev, &fixed_sec, &fixed_sub);
+
+   next_busnr = max + 1;
+   /* Use secondary bus number in EA */
+   if (fixed_sec)
+   next_busnr = fixed_sec;
+
/*
 * Prevent assigning a bus number that already exists.
 * This can happen when a bridge is hot-plugged, so in this
 * case we only re-scan this bus.
 */
-   child = pci_find_bus(pci_domain_nr(bus), max+1);
+   child = pci_find_bus(pci_domain_nr(bus), next_busnr);
if (!child) {
-   child = pci_add_new_bus(bus, dev, max+1);
+   child = pci_add_new_bus(bus, dev, next_busnr);
if (!child)
goto out;
-   pci_bus_insert_busn_res(child, max+1,
+   pci_bus_insert_busn_res(child, next_busnr,
bus->busn_res.end);
}
max++;
@@ -1234,7 +1278,13 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, 
struct pci_dev *dev,
max += i;
}
 
-   /* Set subordinate bus number to its real value */
+   /*
+* Set subordinate bus number to its real value.
+* If fixed subordinate bus number exists from EA
+* capability then use it.
+*/
+   if (fixed_sub)
+   max = fixed_sub;
pci_bus_update_busn_res_end(child, max);
pci_write_config_byte(dev, PCI_SUBORDINATE_BUS, max);
}
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index e1e9888..c3d0904 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -372,6 +372,12 @@
 #define PCI_EA_FIRST_ENT_BRIDGE8   /* First EA Entry for Bridges */
 #define  PCI_EA_ES 0x0007 /* Entry Size */
 #define  PCI_EA_BEI0x00f0 /* BAR Equivalent Indicator */
+
+/* EA fixed Secondary and Subordinate bus numbers for Bridge */
+#define PCI_EA_SEC_BUS_MASK0xff
+#define PCI_EA_SUB_BUS_MASK0xff00
+#define PCI_EA_SUB_BUS_SHIFT   8
+
 /* 0-5 map to BARs 0-5

[PATCH] PCI: assign bus numbers present in EA capability for bridges

[sundeep . lkml]

From: Subbaraya Sundeep 

As per the spec, bridges with EA capability work
with fixed secondary and subordinate bus numbers.
Hence assign bus numbers to bridges from EA if the
capability exists.

Signed-off-by: Subbaraya Sundeep 
---
 drivers/pci/probe.c   | 58 ---
 include/uapi/linux/pci_regs.h |  6 +
 2 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b1c05b5..f41d2e6 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1030,6 +1030,40 @@ static void pci_enable_crs(struct pci_dev *pdev)
 
 static unsigned int pci_scan_child_bus_extend(struct pci_bus *bus,
  unsigned int available_buses);
+/*
+ * pci_ea_fixed_busnrs() - Read fixed Secondary and Subordinate bus
+ * numbers from EA capability.
+ * @dev: Bridge with EA
+ * @secondary: updated with secondary bus number in EA
+ * @subordinate: updated with subordinate bus number in EA
+ *
+ * If it is a bridge with EA capability then fixed bus numbers are
+ * read from EA capability list and secondary, subordinate reference
+ * variables will be updated. Otherwise secondary and subordinate reference
+ * variables will be zeroed.
+ */
+static void pci_ea_fixed_busnrs(struct pci_dev *dev, u8 *secondary,
+   u8 *subordinate)
+{
+   int ea;
+   int offset;
+   u32 dw;
+
+   *secondary = *subordinate = 0;
+
+   if (dev->hdr_type != PCI_HEADER_TYPE_BRIDGE)
+   return;
+
+   /* find PCI EA capability in list */
+   ea = pci_find_capability(dev, PCI_CAP_ID_EA);
+   if (!ea)
+   return;
+
+   offset = ea + PCI_EA_FIRST_ENT;
+   pci_read_config_dword(dev, offset, &dw);
+   *secondary =  dw & PCI_EA_SEC_BUS_MASK;
+   *subordinate = (dw & PCI_EA_SUB_BUS_MASK) >> PCI_EA_SUB_BUS_SHIFT;
+}
 
 /*
  * pci_scan_bridge_extend() - Scan buses behind a bridge
@@ -1064,6 +1098,8 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, 
struct pci_dev *dev,
u16 bctl;
u8 primary, secondary, subordinate;
int broken = 0;
+   u8 fixed_sec, fixed_sub;
+   int next_busnr;
 
/*
 * Make sure the bridge is powered on to be able to access config
@@ -1163,17 +1199,25 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, 
struct pci_dev *dev,
/* Clear errors */
pci_write_config_word(dev, PCI_STATUS, 0x);
 
+   /* read bus numbers from EA */
+   pci_ea_fixed_busnrs(dev, &fixed_sec, &fixed_sub);
+
+   next_busnr = max + 1;
+   /* Use secondary bus number in EA */
+   if (fixed_sec)
+   next_busnr = fixed_sec;
+
/*
 * Prevent assigning a bus number that already exists.
 * This can happen when a bridge is hot-plugged, so in this
 * case we only re-scan this bus.
 */
-   child = pci_find_bus(pci_domain_nr(bus), max+1);
+   child = pci_find_bus(pci_domain_nr(bus), next_busnr);
if (!child) {
-   child = pci_add_new_bus(bus, dev, max+1);
+   child = pci_add_new_bus(bus, dev, next_busnr);
if (!child)
goto out;
-   pci_bus_insert_busn_res(child, max+1,
+   pci_bus_insert_busn_res(child, next_busnr,
bus->busn_res.end);
}
max++;
@@ -1234,7 +1278,13 @@ static int pci_scan_bridge_extend(struct pci_bus *bus, 
struct pci_dev *dev,
max += i;
}
 
-   /* Set subordinate bus number to its real value */
+   /*
+* Set subordinate bus number to its real value.
+* If fixed subordinate bus number exists from EA
+* capability then use it.
+*/
+   if (fixed_sub)
+   max = fixed_sub;
pci_bus_update_busn_res_end(child, max);
pci_write_config_byte(dev, PCI_SUBORDINATE_BUS, max);
}
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index e1e9888..c3d0904 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -372,6 +372,12 @@
 #define PCI_EA_FIRST_ENT_BRIDGE8   /* First EA Entry for Bridges */
 #define  PCI_EA_ES 0x0007 /* Entry Size */
 #define  PCI_EA_BEI0x00f0 /* BAR Equivalent Indicator */
+
+/* EA fixed Secondary and Subordinate bus numbers for Bridge */
+#define PCI_EA_SEC_BUS_MASK0xff
+#define PCI_EA_SUB_BUS_MASK0xff00
+#define PCI_EA_SUB_BUS_SHIFT   8
+
 /* 0-5 map to BARs 0-5 respectively */
 #define   PCI_EA_BEI_BAR0  0
 #define   PCI_EA_BEI_BAR5

Re: [PATCH v2] lib/extable.c: use bsearch() library function in search_extable()

[LKML]

With kind regards
Thomas

> Am 04.06.2017 um 00:38 schrieb Thomas Meyer :
> 
> Signed-off-by: Thomas Meyer 
> ---
>  include/linux/extable.h |  3 ++-
>  kernel/extable.c|  2 +-
>  kernel/module.c |  2 +-
>  lib/extable.c   | 38 +++---
>  4 files changed, 23 insertions(+), 22 deletions(-)
> 
> diff --git a/include/linux/extable.h b/include/linux/extable.h
> index 7effea4..b575bb9 100644
> --- a/include/linux/extable.h
> +++ b/include/linux/extable.h
> @@ -2,13 +2,14 @@
>  #define _LINUX_EXTABLE_H
>  
>  #include /* for NULL */
> +#include 
>  
>  struct module;
>  struct exception_table_entry;
>  
>  const struct exception_table_entry *
>  search_extable(const struct exception_table_entry *first,
> -   const struct exception_table_entry *last,
> +   const size_t num,
> unsigned long value);
>  void sort_extable(struct exception_table_entry *start,
>struct exception_table_entry *finish);
> diff --git a/kernel/extable.c b/kernel/extable.c
> index 2676d7f..0c25b75 100644
> --- a/kernel/extable.c
> +++ b/kernel/extable.c
> @@ -55,7 +55,7 @@ const struct exception_table_entry 
> *search_exception_tables(unsigned long addr)
>  {
>  const struct exception_table_entry *e;
>  
> -e = search_extable(__start___ex_table, __stop___ex_table-1, addr);
> +e = search_extable(__start___ex_table, __stop___ex_table - 
> __start___ex_table, addr);
>  if (!e)
>  e = search_module_extables(addr);
>  return e;
> diff --git a/kernel/module.c b/kernel/module.c
> index 4a3665f..22faf11 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -4201,7 +4201,7 @@ const struct exception_table_entry 
> *search_module_extables(unsigned long addr)
>  goto out;
>  
>  e = search_extable(mod->extable,
> -   mod->extable + mod->num_exentries - 1,
> +   mod->num_exentries,
> addr);
>  out:
>  preempt_enable();
> diff --git a/lib/extable.c b/lib/extable.c
> index 62968da..d4d3929 100644
> --- a/lib/extable.c
> +++ b/lib/extable.c
> @@ -9,6 +9,7 @@
>   * 2 of the License, or (at your option) any later version.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -51,7 +52,7 @@ static void swap_ex(void *a, void *b, int size)
>   * This is used both for the kernel exception table and for
>   * the exception tables of modules that get loaded.
>   */
> -static int cmp_ex(const void *a, const void *b)
> +static int cmp_ex_sort(const void *a, const void *b)
>  {
>  const struct exception_table_entry *x = a, *y = b;
>  
> @@ -67,7 +68,7 @@ void sort_extable(struct exception_table_entry *start,
>struct exception_table_entry *finish)
>  {
>  sort(start, finish - start, sizeof(struct exception_table_entry),
> - cmp_ex, swap_ex);
> + cmp_ex_sort, swap_ex);
>  }
>  
>  #ifdef CONFIG_MODULES
> @@ -93,6 +94,20 @@ void trim_init_extable(struct module *m)
>  #endif /* !ARCH_HAS_SORT_EXTABLE */
>  
>  #ifndef ARCH_HAS_SEARCH_EXTABLE
> +
> +static int cmp_ex_search(const void *key, const void *elt)
> +{
> +const struct exception_table_entry * _elt = elt;
> +unsigned long k = *(unsigned long*) key;
> +
> +/* avoid overflow */
> +if (k > ex_to_insn(_elt))
> +return 1;
> +if (k < ex_to_insn(_elt))
> +return -1;
> +return 0;
> +}
> +
>  /*
>   * Search one exception table for an entry corresponding to the
>   * given instruction address, and return the address of the entry,
> @@ -102,24 +117,9 @@ void trim_init_extable(struct module *m)
>   */
>  const struct exception_table_entry *
>  search_extable(const struct exception_table_entry *first,
> -   const struct exception_table_entry *last,
> +   const size_t num, 
> unsigned long value)
>  {
> -while (first <= last) {
> -const struct exception_table_entry *mid;
> -
> -mid = ((last - first) >> 1) + first;
> -/*
> - * careful, the distance between value and insn
> - * can be larger than MAX_LONG:
> - */
> -if (ex_to_insn(mid) < value)
> -first = mid + 1;
> -else if (ex_to_insn(mid) > value)
> -last = mid - 1;
> -else
> -return mid;
> -}
> -return NULL;
> +return bsearch(&value, first, num, sizeof(struct exception_table_entry), 
> cmp_ex_search);
>  }
>  #endif

Re: [BUG nohz]: wrong user and system time accounting

[lkml]

On Thu, Mar 23, 2017 at 08:56:02PM -0400, Rik van Riel wrote:
> On Thu, 2017-03-23 at 16:55 -0400, Luiz Capitulino wrote:
> > When there are two or more tasks executing in user-space and
> > taking 100% of a nohz_full CPU, top reports 70% system time
> > and 30% user time utilization. Sometimes I'm even able to get
> > 100% system time and 0% user time.
> > 
> > This was reproduced with latest Linus tree (093b995), but I
> > don't believe it's a regression (at least not a recent one)
> > as I can reproduce it with older kernels. Also, I have
> > CONFIG_IRQ_TIME_ACCOUNTING=y and haven't tried to reproduce
> > without it yet.
> > 
> > Below you'll find the steps to reproduce and some initial
> > analysis.
> > 
> > Steps to reproduce
> > --
> > 
> > 1. Set up a CPU for nohz_full with isolcpus= nohz_full=
> > 
> > 2. Pin two tasks that hog the CPU 100% of the time to that CPU
> > 
> > 3. Run top -d1 and check system time
> > 
> > NOTE: When there's only one task hogging a nohz_full CPU, top
> >   shows 100% user-time, as expected
> > 
> > Initial analysis
> > 
> > 
> > When tracing vtime accounting functions and the user-space/kernel
> > transitions when the issue is taking place, I see several of the
> > following:
> > 
> > hog-10552 [015]  1132.711104:
> > function: enter_from_user_mode <-- apic_timer_interrupt
> > hog-10552 [015]  1132.711105:
> > function: __context_tracking_exit <--
> > enter_from_user_mode
> > hog-10552 [015]  1132.711105:
> > bprint:   __context_tracking_exit.part.4: new state=1 cur
> > state=1 active=1
> > hog-10552 [015]  1132.711105:
> > function: vtime_account_user <--
> > __context_tracking_exit.part.4
> > hog-10552 [015]  1132.711105:
> > function: smp_apic_timer_interrupt <--
> > apic_timer_interrupt
> > hog-10552 [015]  1132.711106: function: irq_enter <--
> > smp_apic_timer_interrupt
> > hog-10552 [015]  1132.711106: function: tick_sched_timer
> > <-- __hrtimer_run_queues
> > hog-10552 [015]  1132.711108: function: irq_exit <--
> > smp_apic_timer_interrupt
> > hog-10552 [015]  1132.711108:
> > function: __context_tracking_enter <--
> > prepare_exit_to_usermode
> > hog-10552 [015]  1132.711108:
> > bprint:   __context_tracking_enter.part.2: new state=1
> > cur state=0 active=1
> > hog-10552 [015]  1132.711109: function: vtime_user_enter
> > <-- __context_tracking_enter.part.2
> > hog-10552 [015]  1132.711109:
> > function: __vtime_account_system <-- vtime_user_enter
> > hog-10552 [015]  1132.711109:
> > function: account_system_time <-- __vtime_account_system
> > 
> > On entering the kernel due to a timer interrupt, vtime_account_user()
> > skips user-time accounting. Then later on when returning to user-
> > space,
> > vtime_user_enter() is probably accounting the whole time (ie. user-
> > space
> > plus kernel-space) to system time.
> > 
> > Now, when does vtime_account_user() skips accounting? Well, when the
> > time delta is less then one jiffie. This would imply that
> > vtime_account_user()
> > is being called less than one jiffie since the last accounting, but I
> > haven't
> > confirmed any of this yet.
> 
> Jiffies should be advanced by the timer interrupt, on the
> housekeeping CPU, which is not doing context tracking.
> 
> Why is the isolated/nohz_full CPU receiving timer interrupts
> at all?
> 
> I thought it would not, but obviously I am wrong. What is
> going on here?

This thread sounds awful familiar to me.

With CONFIG_NO_HZ_FULL=y && CONFIG_VIRT_CPU_ACCOUNTING_GEN=y I observed process
accounting anomalies with user CPU time being misaccounted as system time all
the way back to 4.6.0.

After switching to CONFIG_NO_HZ_IDLE=y && CONFIG_VIRT_CPU_ACCOUNTING_GEN=n the
issues went away.

The lkml thread I had seen at that time which compelled me to suspect these
settings was this:
http://lkml.iu.edu/hypermail/linux/kernel/1608.2/05860.html

It sounds like this issue is finally beginning to be understood though, good
work!

Regards,
Vito Caputo

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

[lkml]

On Thu, Mar 23, 2017 at 11:57:22AM -0500, Rob Herring wrote:
> On Thu, Mar 23, 2017 at 08:46:03AM -0500, Rob Herring wrote:
> > On Thu, Mar 23, 2017 at 12:30:18AM -0700, l...@pengaru.com wrote:
> > > On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote:
> > > > On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote:
> > > > > Hello list,
> > > > > 
> > > > > After approximately one day day of running 4.11.0-rc3 with 7e54d9d 
> > > > > reverted to
> > > > > enable regular use, this happened upon destroying an xterm:
> > > > > 
> 
> [...]
> 
> > > > 
> > > > Added Rob Herring, author of c3485ee to CC list.
> > > > 
> > > 
> > > I suspect this part was a mistake:
> > > 
> > >  -   tty = READ_ONCE(port->itty);
> > >  -   if (tty == NULL)
> > >  -   return;
> > > 
> > > Note release_tty() tty->port->itty is assigned NULL before calling
> > > tty_buffer_cancel_work():
> > 
> > The READ_ONCE should still handle that.
> > 
> > Anyway, the changes were purely to try to remove the need for a ldisc in 
> > the serdev case and avoid referencing it. In fact we still have an 
> > ldisc, it's just not used. So we can restore the original ordering.
> > 
> > Can you try this patch:
> > 
> 
> Please try this one instead. It passes the tty struct around instead of 
> the ldisc.
> 

Happy to test the fix, except reproducing the bug without changing anything
at all has proven elusive.  AFAIK we just have my single experience
described in the report, I'm unconfident in my ability to validate any
fixes for this specific bug.

If you think you understand the root cause, maybe you can conceive of a
more reliable reproducer than me just using my machine?  It appears I may
have just been very (un)lucky.

Thanks,
Vito Caputo


> 8<-
> >From 4d727a92267541aeba172ee52d9b771d7176297c Mon Sep 17 00:00:00 2001
> From: Rob Herring 
> Date: Thu, 23 Mar 2017 08:50:10 -0500
> Subject: [PATCH] tty: fix regression in flush_to_ldisc
> 
> Commit c3485ee0d560 ("tty_port: Add port client functions") rearranged
> getting the reference to the ldisc. Vito Caputo reports:
> 
> "This happened upon destroying an xterm:
> 
> [80817.525112] BUG: unable to handle kernel paging request at 2260
> [80817.525239] IP: n_tty_receive_buf_common+0x68/0xab0
> [80817.525312] PGD 0
> 
> [80817.525387] Oops:  [#1] PREEMPT SMP
> [80817.525452] CPU: 0 PID: 9532 Comm: kworker/u4:3 Not tainted 
> 4.11.0-rc3-1-gc56a355 #53
> [80817.525564] Hardware name: LENOVO 7668CTO/7668CTO, BIOS 7NETC2WW (2.22 ) 
> 03/22/2011
> [80817.525673] Workqueue: events_unbound flush_to_ldisc
> [80817.525752] task: 967d91d8 task.stack: 9add81f4
> [80817.525839] RIP: 0010:n_tty_receive_buf_common+0x68/0xab0
> [80817.525917] RSP: 0018:9add81f43d38 EFLAGS: 00010297
> [80817.525992] RAX:  RBX: 967d91c98c00 RCX: 
> 0001
> [80817.526035] RDX: 967e73bba58d RSI: 967e73bba48d RDI: 
> 967d91c98cc0
> [80817.526035] RBP: 9add81f43dd0 R08: 0001 R09: 
> 
> [80817.526035] R10: 4980cbe001e0 R11:  R12: 
> 967d87aacf20
> [80817.526035] R13: 967e73bba58d R14: 0001 R15: 
> 967e74aa8008
> [80817.526035] FS:  () GS:967e7bc0() 
> knlGS:
> [80817.526035] CS:  0010 DS:  ES:  CR0: 80050033
> [80817.526035] CR2: 2260 CR3: 99009000 CR4: 
> 06f0
> [80817.526035] Call Trace:
> [80817.526035]  ? update_curr+0xbb/0x1a0
> [80817.526035]  n_tty_receive_buf2+0xf/0x20
> [80817.526035]  tty_ldisc_receive_buf+0x1d/0x50
> [80817.526035]  tty_port_default_receive_buf+0x40/0x60
> [80817.526035]  flush_to_ldisc+0x94/0xa0
> [80817.526035]  process_one_work+0x13b/0x3e0
> [80817.526035]  worker_thread+0x64/0x4a0
> [80817.526035]  kthread+0x10f/0x150
> [80817.526035]  ? process_one_work+0x3e0/0x3e0
> [80817.526035]  ? __kthread_create_on_node+0x150/0x150
> [80817.526035]  ret_from_fork+0x29/0x40
> [80817.526035] Code: 85 70 ff ff ff e8 59 75 57 00 48 8d 83 00 02 00 00 c7 45 
> c8 00 00 00 00 48 89 45 98 48 8d 83 00 02 00 00 48 89 45 90 48 8b 45 b8 <48> 
> 8b b0 60 22 00 00 48 8b 08 89 f0 29 c8 f6 83 10 01 00 00 08
> [80817.526035] RIP: n_tty_receive_buf_common+0x68/0xab0 RSP: 9add81f43d38
> [80817.526035] CR2: 2260
> [80817.526035] ---[ end trace 640aec4765d350f2 ]---
> 
> That xterm process is stuck, and I am unable to start any new xterms,
> switching to virtual consoles proves useless, presumably there's an
> important lock held."
> 
> Revert the changes in flush_to_ldisc so that we take a ref to the ldisc
> in the beginning. This requires the tty struct to be passed to the
> receive_buf client functions instead of ideally using the tty_port as we
> can't reliably retrieve the struct tty from the tty_port. However, since
> we do hold a reference to the ldisc, we c

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

[lkml]

On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote:
> Hello list,
> 
> After approximately one day day of running 4.11.0-rc3 with 7e54d9d reverted to
> enable regular use, this happened upon destroying an xterm:
> 
> [80817.525112] BUG: unable to handle kernel paging request at 2260
> [80817.525239] IP: n_tty_receive_buf_common+0x68/0xab0
> [80817.525312] PGD 0 
> 
> [80817.525387] Oops:  [#1] PREEMPT SMP
> [80817.525452] CPU: 0 PID: 9532 Comm: kworker/u4:3 Not tainted 
> 4.11.0-rc3-1-gc56a355 #53
> [80817.525564] Hardware name: LENOVO 7668CTO/7668CTO, BIOS 7NETC2WW (2.22 ) 
> 03/22/2011
> [80817.525673] Workqueue: events_unbound flush_to_ldisc
> [80817.525752] task: 967d91d8 task.stack: 9add81f4
> [80817.525839] RIP: 0010:n_tty_receive_buf_common+0x68/0xab0
> [80817.525917] RSP: 0018:9add81f43d38 EFLAGS: 00010297
> [80817.525992] RAX:  RBX: 967d91c98c00 RCX: 
> 0001
> [80817.526035] RDX: 967e73bba58d RSI: 967e73bba48d RDI: 
> 967d91c98cc0
> [80817.526035] RBP: 9add81f43dd0 R08: 0001 R09: 
> 
> [80817.526035] R10: 4980cbe001e0 R11:  R12: 
> 967d87aacf20
> [80817.526035] R13: 967e73bba58d R14: 0001 R15: 
> 967e74aa8008
> [80817.526035] FS:  () GS:967e7bc0() 
> knlGS:
> [80817.526035] CS:  0010 DS:  ES:  CR0: 80050033
> [80817.526035] CR2: 2260 CR3: 99009000 CR4: 
> 06f0
> [80817.526035] Call Trace:
> [80817.526035]  ? update_curr+0xbb/0x1a0
> [80817.526035]  n_tty_receive_buf2+0xf/0x20
> [80817.526035]  tty_ldisc_receive_buf+0x1d/0x50
> [80817.526035]  tty_port_default_receive_buf+0x40/0x60
> [80817.526035]  flush_to_ldisc+0x94/0xa0
> [80817.526035]  process_one_work+0x13b/0x3e0
> [80817.526035]  worker_thread+0x64/0x4a0
> [80817.526035]  kthread+0x10f/0x150
> [80817.526035]  ? process_one_work+0x3e0/0x3e0
> [80817.526035]  ? __kthread_create_on_node+0x150/0x150
> [80817.526035]  ret_from_fork+0x29/0x40
> [80817.526035] Code: 85 70 ff ff ff e8 59 75 57 00 48 8d 83 00 02 00 00 c7 45 
> c8 00 00 00 00 48 89 45 98 48 8d 83 28 02 00 00 48 89 45 90 48 8b 45 b8 <48> 
> 8b b0 60 22 00 00 48 8b 08 89 f0 29 c8 f6 83 10 01 00 00 08 
> [80817.526035] RIP: n_tty_receive_buf_common+0x68/0xab0 RSP: 9add81f43d38
> [80817.526035] CR2: 2260
> [80817.526035] ---[ end trace 640aec4765d350f2 ]---
> 
> 
> That xterm process is stuck, and I am unable to start any new xterms, 
> switching to virtual consoles proves useless, presumably there's an important 
> lock held.
> 


At a casual glance of the v4.10..v4.11-rc3 changes affecting drivers/tty, the
commit c3485e looks suspicious to me, these hunks in particular:

@@ -465,16 +465,6 @@ static void flush_to_ldisc(struct work_struct *work)
 {
struct tty_port *port = container_of(work, struct tty_port, buf.work);
struct tty_bufhead *buf = &port->buf;
-   struct tty_struct *tty;
-   struct tty_ldisc *disc;
-
-   tty = READ_ONCE(port->itty);
-   if (tty == NULL)
-   return;
-
-   disc = tty_ldisc_ref(tty);
-   if (disc == NULL)
-   return;
 
mutex_lock(&buf->lock);
 
@@ -504,7 +494,7 @@ static void flush_to_ldisc(struct work_struct *work)
continue;
}
 
-   count = receive_buf(disc, head, count);
+   count = receive_buf(port, head, count);
if (!count)
break;
head->read += count;
@@ -512,7 +502,6 @@ static void flush_to_ldisc(struct work_struct *work)
 
mutex_unlock(&buf->lock);
 
-   tty_ldisc_deref(disc);
 }
 
 /**



I'm not familiar with this code at all, but port->buf is part of port, and if
the port is destroyed as part of the tty, then perhaps port->buf (and
port->buf->lock) may become invalid on us without these:

-   tty = READ_ONCE(port->itty);
-   if (tty == NULL)
-   return;
-
-   disc = tty_ldisc_ref(tty);
-   if (disc == NULL)
-   return;

Added Rob Herring, author of c3485ee to CC list.

Regards,
Vito Caputo

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

[lkml]

On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote:
> On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote:
> > Hello list,
> > 
> > After approximately one day day of running 4.11.0-rc3 with 7e54d9d reverted 
> > to
> > enable regular use, this happened upon destroying an xterm:
> > 
> > [80817.525112] BUG: unable to handle kernel paging request at 
> > 2260
> > [80817.525239] IP: n_tty_receive_buf_common+0x68/0xab0
> > [80817.525312] PGD 0 
> > 
> > [80817.525387] Oops:  [#1] PREEMPT SMP
> > [80817.525452] CPU: 0 PID: 9532 Comm: kworker/u4:3 Not tainted 
> > 4.11.0-rc3-1-gc56a355 #53
> > [80817.525564] Hardware name: LENOVO 7668CTO/7668CTO, BIOS 7NETC2WW (2.22 ) 
> > 03/22/2011
> > [80817.525673] Workqueue: events_unbound flush_to_ldisc
> > [80817.525752] task: 967d91d8 task.stack: 9add81f4
> > [80817.525839] RIP: 0010:n_tty_receive_buf_common+0x68/0xab0
> > [80817.525917] RSP: 0018:9add81f43d38 EFLAGS: 00010297
> > [80817.525992] RAX:  RBX: 967d91c98c00 RCX: 
> > 0001
> > [80817.526035] RDX: 967e73bba58d RSI: 967e73bba48d RDI: 
> > 967d91c98cc0
> > [80817.526035] RBP: 9add81f43dd0 R08: 0001 R09: 
> > 
> > [80817.526035] R10: 4980cbe001e0 R11:  R12: 
> > 967d87aacf20
> > [80817.526035] R13: 967e73bba58d R14: 0001 R15: 
> > 967e74aa8008
> > [80817.526035] FS:  () GS:967e7bc0() 
> > knlGS:
> > [80817.526035] CS:  0010 DS:  ES:  CR0: 80050033
> > [80817.526035] CR2: 2260 CR3: 99009000 CR4: 
> > 06f0
> > [80817.526035] Call Trace:
> > [80817.526035]  ? update_curr+0xbb/0x1a0
> > [80817.526035]  n_tty_receive_buf2+0xf/0x20
> > [80817.526035]  tty_ldisc_receive_buf+0x1d/0x50
> > [80817.526035]  tty_port_default_receive_buf+0x40/0x60
> > [80817.526035]  flush_to_ldisc+0x94/0xa0
> > [80817.526035]  process_one_work+0x13b/0x3e0
> > [80817.526035]  worker_thread+0x64/0x4a0
> > [80817.526035]  kthread+0x10f/0x150
> > [80817.526035]  ? process_one_work+0x3e0/0x3e0
> > [80817.526035]  ? __kthread_create_on_node+0x150/0x150
> > [80817.526035]  ret_from_fork+0x29/0x40
> > [80817.526035] Code: 85 70 ff ff ff e8 59 75 57 00 48 8d 83 00 02 00 00 c7 
> > 45 c8 00 00 00 00 48 89 45 98 48 8d 83 28 02 00 00 48 89 45 90 48 8b 45 b8 
> > <48> 8b b0 60 22 00 00 48 8b 08 89 f0 29 c8 f6 83 10 01 00 00 08 
> > [80817.526035] RIP: n_tty_receive_buf_common+0x68/0xab0 RSP: 
> > 9add81f43d38
> > [80817.526035] CR2: 2260
> > [80817.526035] ---[ end trace 640aec4765d350f2 ]---
> > 
> > 
> > That xterm process is stuck, and I am unable to start any new xterms, 
> > switching to virtual consoles proves useless, presumably there's an 
> > important lock held.
> > 
> 
> 
> At a casual glance of the v4.10..v4.11-rc3 changes affecting drivers/tty, the
> commit c3485e looks suspicious to me, these hunks in particular:
> 
> @@ -465,16 +465,6 @@ static void flush_to_ldisc(struct work_struct *work)
>  {
> struct tty_port *port = container_of(work, struct tty_port, buf.work);
> struct tty_bufhead *buf = &port->buf;
> -   struct tty_struct *tty;
> -   struct tty_ldisc *disc;
> -
> -   tty = READ_ONCE(port->itty);
> -   if (tty == NULL)
> -   return;
> -
> -   disc = tty_ldisc_ref(tty);
> -   if (disc == NULL)
> -   return;
>  
> mutex_lock(&buf->lock);
>  
> @@ -504,7 +494,7 @@ static void flush_to_ldisc(struct work_struct *work)
> continue;
> }
>  
> -   count = receive_buf(disc, head, count);
> +   count = receive_buf(port, head, count);
> if (!count)
> break;
> head->read += count;
> @@ -512,7 +502,6 @@ static void flush_to_ldisc(struct work_struct *work)
>  
> mutex_unlock(&buf->lock);
>  
> -   tty_ldisc_deref(disc);
>  }
>  
>  /**
> 
> 
> 
> I'm not familiar with this code at all, but port->buf is part of port, and if
> the port is destroyed as part of the tty, then perhaps port->buf (and
> port->buf->lock) may become invalid on us without these:
> 
> -   tty = READ_ONCE(port->itty);
> -   if (tty == NULL)
> -   return;
> -
> -   disc = tty_ldisc_ref(tty);
> -   if (disc == NULL)
> -   return;
> 
> Added Rob Herring, author of c3485ee to CC list.
> 

I suspect this part was a mistake:

 -   tty = READ_ONCE(port->itty);
 -   if (tty == NULL)
 -   return;

Note release_tty() tty->port->itty is assigned NULL before calling
tty_buffer_cancel_work():

static void release_tty(struct tty_struct *tty, int idx)
{
/* This should always be true but check for the moment */
WARN_ON(tty->index != idx);
WARN_ON(!mutex_is_locked(&tty_mutex));
if (tty->ops->shutdown)
 

[BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

[lkml]

Hello list,

After approximately one day day of running 4.11.0-rc3 with 7e54d9d reverted to
enable regular use, this happened upon destroying an xterm:

[80817.525112] BUG: unable to handle kernel paging request at 2260
[80817.525239] IP: n_tty_receive_buf_common+0x68/0xab0
[80817.525312] PGD 0 

[80817.525387] Oops:  [#1] PREEMPT SMP
[80817.525452] CPU: 0 PID: 9532 Comm: kworker/u4:3 Not tainted 
4.11.0-rc3-1-gc56a355 #53
[80817.525564] Hardware name: LENOVO 7668CTO/7668CTO, BIOS 7NETC2WW (2.22 ) 
03/22/2011
[80817.525673] Workqueue: events_unbound flush_to_ldisc
[80817.525752] task: 967d91d8 task.stack: 9add81f4
[80817.525839] RIP: 0010:n_tty_receive_buf_common+0x68/0xab0
[80817.525917] RSP: 0018:9add81f43d38 EFLAGS: 00010297
[80817.525992] RAX:  RBX: 967d91c98c00 RCX: 0001
[80817.526035] RDX: 967e73bba58d RSI: 967e73bba48d RDI: 967d91c98cc0
[80817.526035] RBP: 9add81f43dd0 R08: 0001 R09: 
[80817.526035] R10: 4980cbe001e0 R11:  R12: 967d87aacf20
[80817.526035] R13: 967e73bba58d R14: 0001 R15: 967e74aa8008
[80817.526035] FS:  () GS:967e7bc0() 
knlGS:
[80817.526035] CS:  0010 DS:  ES:  CR0: 80050033
[80817.526035] CR2: 2260 CR3: 99009000 CR4: 06f0
[80817.526035] Call Trace:
[80817.526035]  ? update_curr+0xbb/0x1a0
[80817.526035]  n_tty_receive_buf2+0xf/0x20
[80817.526035]  tty_ldisc_receive_buf+0x1d/0x50
[80817.526035]  tty_port_default_receive_buf+0x40/0x60
[80817.526035]  flush_to_ldisc+0x94/0xa0
[80817.526035]  process_one_work+0x13b/0x3e0
[80817.526035]  worker_thread+0x64/0x4a0
[80817.526035]  kthread+0x10f/0x150
[80817.526035]  ? process_one_work+0x3e0/0x3e0
[80817.526035]  ? __kthread_create_on_node+0x150/0x150
[80817.526035]  ret_from_fork+0x29/0x40
[80817.526035] Code: 85 70 ff ff ff e8 59 75 57 00 48 8d 83 00 02 00 00 c7 45 
c8 00 00 00 00 48 89 45 98 48 8d 83 28 02 00 00 48 89 45 90 48 8b 45 b8 <48> 8b 
b0 60 22 00 00 48 8b 08 89 f0 29 c8 f6 83 10 01 00 00 08 
[80817.526035] RIP: n_tty_receive_buf_common+0x68/0xab0 RSP: 9add81f43d38
[80817.526035] CR2: 2260
[80817.526035] ---[ end trace 640aec4765d350f2 ]---


That xterm process is stuck, and I am unable to start any new xterms, switching 
to virtual consoles proves useless, presumably there's an important lock held.

Here's a sysrq dump of blocked tasks as of now:


[81474.721981] sysrq: SysRq : Show Blocked State
[81474.721995]   taskPC stack   pid father
[81474.722002] systemd D0 1  0 0x
[81474.722136] Call Trace:
[81474.722152]  __schedule+0x348/0x8c0
[81474.722161]  schedule+0x38/0x90
[81474.722168]  rwsem_down_write_failed+0x110/0x250
[81474.722178]  call_rwsem_down_write_failed+0x17/0x30
[81474.722184]  down_write+0x1f/0x30
[81474.722192]  tty_unthrottle+0x19/0x60
[81474.722199]  n_tty_open+0xba/0xd0
[81474.722206]  tty_ldisc_open.isra.5+0x2d/0x60
[81474.722211]  tty_ldisc_setup+0x18/0x60
[81474.722218]  tty_init_dev+0x7a/0x1a0
[81474.74]  tty_open+0x4f0/0x540
[81474.722232]  chrdev_open+0x76/0x160
[81474.722239]  ? exact_lock+0x20/0x20
[81474.722247]  do_dentry_open.isra.18+0x1b9/0x2c0
[81474.722254]  vfs_open+0x43/0x60
[81474.722260]  path_openat+0x547/0x1240
[81474.722268]  ? umount_tree+0xb0/0x290
[81474.722274]  do_filp_open+0x79/0xd0
[81474.722281]  ? __alloc_fd+0xa9/0x160
[81474.722288]  do_sys_open+0x115/0x1e0
[81474.722294]  SyS_open+0x19/0x20
[81474.722301]  entry_SYSCALL_64_fastpath+0x13/0x94
[81474.722308] RIP: 0033:0x7fa8508d8190
[81474.722313] RSP: 002b:7fff58dd1f88 EFLAGS: 0246 ORIG_RAX: 
0002
[81474.722321] RAX: ffda RBX: 5600f5eddf68 RCX: 7fa8508d8190
[81474.722327] RDX:  RSI: 00080102 RDI: 5600f5ee8020
[81474.722332] RBP:  R08: 7fa850684775 R09: 7fff58dd1af0
[81474.722337] R10: 5600f5e4c5e0 R11: 0246 R12: 
[81474.722342] R13: 0001 R14: 5600f5eae710 R15: 25de
[81474.722379] screen  D0   764763 0x
[81474.722387] Call Trace:
[81474.722395]  __schedule+0x348/0x8c0
[81474.722403]  schedule+0x38/0x90
[81474.722410]  schedule_preempt_disabled+0x10/0x20
[81474.722416]  __mutex_lock.isra.7+0x1fa/0x540
[81474.722423]  __mutex_lock_slowpath+0xe/0x10
[81474.722428]  mutex_lock+0x1e/0x20
[81474.722435]  ptmx_open+0x96/0x180
[81474.722442]  chrdev_open+0x76/0x160
[81474.722448]  ? exact_lock+0x20/0x20
[81474.722456]  do_dentry_open.isra.18+0x1b9/0x2c0
[81474.722462]  vfs_open+0x43/0x60
[81474.722468]  path_openat+0x547/0x1240
[81474.722474]  ? putname+0x4e/0x60
[81474.722480]  ? filename_lookup+0xd5/0x150
[81474.722487]  do_filp_open+0x79/0xd0
[81474.722493]  ? __alloc_fd+0xa9/0x160
[81474.722500]  do_sys_open+0x115/0x1e0
[81474.722507]  Sy

Re: [Intel-wired-lan] [BUG] 4.11.0-rc1 panic on shutdown X61s

[lkml]

On Tue, Mar 21, 2017 at 07:04:45PM -0700, l...@pengaru.com wrote:
> On Thu, Mar 16, 2017 at 08:13:40PM +, Bowers, AndrewX wrote:
> > Tested this on a Thinkpad T420i, after verifying it also has an e1000e NIC, 
> > unable to  reproduce. Might be limited to that particular model/firmware 
> > version you're using, which I was not able to track down here although 
> > there is another person I could ask, might be able to come up with one yet.
> > 
> > 
> > > -Original Message-
> > > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> > > Behalf Of l...@pengaru.com
> > > Sent: Monday, March 13, 2017 7:41 PM
> > > To: Brown, Aaron F 
> > > Cc: vcap...@pengaru.com; linux-...@vger.kernel.org; David Singleton
> > > ; linux-kernel ;
> > > khalidm ; Andy Shevchenko
> > > ; Borislav Petkov ; intel-
> > > wired-...@lists.osuosl.org; Bjørn Mork 
> > > Subject: Re: [Intel-wired-lan] [BUG] 4.11.0-rc1 panic on shutdown X61s
> > > 
> > > On Tue, Mar 14, 2017 at 01:20:27AM +, Brown, Aaron F wrote:
> > > > > Borislav Petkov  writes:
> > > > > > On Sun, Mar 12, 2017 at 03:55:08PM +0200, Andy Shevchenko wrote:
> > > > > >
> > > > > >> The only change that IMHO matters happened between v4.10 and
> > > > > >> v4.11-
> > > > > rc1 is this:
> > > > > >>
> > > > > >> @@ -6276,8 +6274,8 @@ static int e1000e_pm_freeze(struct device
> > > *dev)
> > > > > >> /* Quiesce the device without resetting the 
> > > > > >> hardware */
> > > > > >> e1000e_down(adapter, false);
> > > > > >> e1000_free_irq(adapter);
> > > > > >> +   e1000e_reset_interrupt_capability(adapter);
> > > > > >> }
> > > > > >> -   e1000e_reset_interrupt_capability(adapter);
> > > > > >>
> > > > > >> So, it apparently misses something for the other case, like
> > > > > >> pci_disable_msi() call or so.
> > > > > >
> > > > > > Well, lemme add the people from
> > > > > >
> > > > > >   7e54d9d063fa ("e1000e: driver trying to free already-free irq")
> > > > > >
> > > > > > to CC then. :-)
> > > > >
> > > > > Already did that a week ago:
> > > > > https://www.spinics.net/lists/netdev/msg423379.html
> > > > >
> > > > > Haven't heard anything back yet.  Wondering if they are waiting for
> > > > > someone else to submit the pretty obvious revert?  Don't understand
> > > > > why that should take more than a minute to figure out.  It's not
> > > > > like they are testing these changes anyway...
> > > >
> > > 
> > > >
> > > > What exact part (or parts) are we looking at (lspci|grep -i eth) that 
> > > > trigger
> > > this?  Could it be a difference in .config files?  The trace says it is 
> > > falling back
> > > to legacy interrupts, does the system continue to work and does the
> > > network continue to function in that mode?  In case it's related to user 
> > > space
> > > what is the base distro?  Any other information you think can help me
> > > reproduce the issue would be appreciated.
> > > >
> > > 
> > > Config attached, the machine is a Thinkpad X61s 1.8Ghz with no onboard
> > > wireless devices (rtl8192cu usb wifi is used).
> > > 
> > > # lspci| grep -i eth
> > > 00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network
> > > Connection (rev 03)
> > > 
> > > Debian jessie amd64 is the distro.
> > > 
> > > I'll have to get back to you on if the e1000e continues functioning, the
> > > machine continues to function until the shutdown panic.
> > > 
> > > There were however some occurrences of subsequent suspend/resume
> > > cycles hanging the machine hard leaving the display off, which prompted me
> > > to resume using
> > > 4.10 before digging any further as it's my only system right now.
> > > 
> > > Will try get around to testing 4.11 with 7e54d9d063fa reverted soon.
> > > 
> > > Regards,
> > > Vito Caputo
> 
> 
> This is still broken as of 4.11.0-rc3 FYI.
> 
> Upon resume:
> [   45.828344] [ cut here ]
> [   45.828352] WARNING: CPU: 0 PID: 807 at drivers/pci/msi.c:1052 
> __pci_enable_msi_range+0x39c/0x3f0
> [   45.828355] CPU: 0 PID: 807 Comm: kworker/u4:29 Not tainted 4.11.0-rc3 #52
> [   45.828356] Hardware name: LENOVO 7668CTO/7668CTO, BIOS 7NETC2WW (2.22 ) 
> 03/22/2011
> [   45.828360] Workqueue: events_unbound async_run_entry_fn
> [   45.828362] Call Trace:
> [   45.828366]  dump_stack+0x4d/0x72
> [   45.828369]  __warn+0xc7/0xf0
> [   45.828371]  warn_slowpath_null+0x18/0x20
> [   45.828372]  __pci_enable_msi_range+0x39c/0x3f0
> [   45.828375]  ? e1000e_get_phy_info_igp+0x1c/0xf0
> [   45.828377]  pci_enable_msi+0x15/0x30
> [   45.828379]  e1000e_set_interrupt_capability+0xe0/0x130
> [   45.828381]  e1000e_pm_thaw+0x1d/0x50
> [   45.828383]  e1000e_pm_resume+0x20/0x30
> [   45.828386]  pci_pm_resume+0x5f/0x90
> [   45.828389]  dpm_run_callback+0x44/0x170
> [   45.828391]  ? pci_pm_thaw+0x90/0x90
> [   45.828393]  device_resume+0xce/0x1e0
> [   45.828395]  async_resume+0x18/0x40
> [   45.828396]  async_run_entry_fn+0x3

Re: [Intel-wired-lan] [BUG] 4.11.0-rc1 panic on shutdown X61s

[lkml]

On Thu, Mar 16, 2017 at 08:13:40PM +, Bowers, AndrewX wrote:
> Tested this on a Thinkpad T420i, after verifying it also has an e1000e NIC, 
> unable to  reproduce. Might be limited to that particular model/firmware 
> version you're using, which I was not able to track down here although there 
> is another person I could ask, might be able to come up with one yet.
> 
> 
> > -Original Message-
> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> > Behalf Of l...@pengaru.com
> > Sent: Monday, March 13, 2017 7:41 PM
> > To: Brown, Aaron F 
> > Cc: vcap...@pengaru.com; linux-...@vger.kernel.org; David Singleton
> > ; linux-kernel ;
> > khalidm ; Andy Shevchenko
> > ; Borislav Petkov ; intel-
> > wired-...@lists.osuosl.org; Bjørn Mork 
> > Subject: Re: [Intel-wired-lan] [BUG] 4.11.0-rc1 panic on shutdown X61s
> > 
> > On Tue, Mar 14, 2017 at 01:20:27AM +, Brown, Aaron F wrote:
> > > > Borislav Petkov  writes:
> > > > > On Sun, Mar 12, 2017 at 03:55:08PM +0200, Andy Shevchenko wrote:
> > > > >
> > > > >> The only change that IMHO matters happened between v4.10 and
> > > > >> v4.11-
> > > > rc1 is this:
> > > > >>
> > > > >> @@ -6276,8 +6274,8 @@ static int e1000e_pm_freeze(struct device
> > *dev)
> > > > >> /* Quiesce the device without resetting the hardware 
> > > > >> */
> > > > >> e1000e_down(adapter, false);
> > > > >> e1000_free_irq(adapter);
> > > > >> +   e1000e_reset_interrupt_capability(adapter);
> > > > >> }
> > > > >> -   e1000e_reset_interrupt_capability(adapter);
> > > > >>
> > > > >> So, it apparently misses something for the other case, like
> > > > >> pci_disable_msi() call or so.
> > > > >
> > > > > Well, lemme add the people from
> > > > >
> > > > >   7e54d9d063fa ("e1000e: driver trying to free already-free irq")
> > > > >
> > > > > to CC then. :-)
> > > >
> > > > Already did that a week ago:
> > > > https://www.spinics.net/lists/netdev/msg423379.html
> > > >
> > > > Haven't heard anything back yet.  Wondering if they are waiting for
> > > > someone else to submit the pretty obvious revert?  Don't understand
> > > > why that should take more than a minute to figure out.  It's not
> > > > like they are testing these changes anyway...
> > >
> > 
> > >
> > > What exact part (or parts) are we looking at (lspci|grep -i eth) that 
> > > trigger
> > this?  Could it be a difference in .config files?  The trace says it is 
> > falling back
> > to legacy interrupts, does the system continue to work and does the
> > network continue to function in that mode?  In case it's related to user 
> > space
> > what is the base distro?  Any other information you think can help me
> > reproduce the issue would be appreciated.
> > >
> > 
> > Config attached, the machine is a Thinkpad X61s 1.8Ghz with no onboard
> > wireless devices (rtl8192cu usb wifi is used).
> > 
> > # lspci| grep -i eth
> > 00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network
> > Connection (rev 03)
> > 
> > Debian jessie amd64 is the distro.
> > 
> > I'll have to get back to you on if the e1000e continues functioning, the
> > machine continues to function until the shutdown panic.
> > 
> > There were however some occurrences of subsequent suspend/resume
> > cycles hanging the machine hard leaving the display off, which prompted me
> > to resume using
> > 4.10 before digging any further as it's my only system right now.
> > 
> > Will try get around to testing 4.11 with 7e54d9d063fa reverted soon.
> > 
> > Regards,
> > Vito Caputo


This is still broken as of 4.11.0-rc3 FYI.

Upon resume:
[   45.828344] [ cut here ]
[   45.828352] WARNING: CPU: 0 PID: 807 at drivers/pci/msi.c:1052 
__pci_enable_msi_range+0x39c/0x3f0
[   45.828355] CPU: 0 PID: 807 Comm: kworker/u4:29 Not tainted 4.11.0-rc3 #52
[   45.828356] Hardware name: LENOVO 7668CTO/7668CTO, BIOS 7NETC2WW (2.22 ) 
03/22/2011
[   45.828360] Workqueue: events_unbound async_run_entry_fn
[   45.828362] Call Trace:
[   45.828366]  dump_stack+0x4d/0x72
[   45.828369]  __warn+0xc7/0xf0
[   45.828371]  warn_slowpath_null+0x18/0x20
[   45.828372]  __pci_enable_msi_range+0x39c/0x3f0
[   45.828375]  ? e1000e_get_phy_info_igp+0x1c/0xf0
[   45.828377]  pci_enable_msi+0x15/0x30
[   45.828379]  e1000e_set_interrupt_capability+0xe0/0x130
[   45.828381]  e1000e_pm_thaw+0x1d/0x50
[   45.828383]  e1000e_pm_resume+0x20/0x30
[   45.828386]  pci_pm_resume+0x5f/0x90
[   45.828389]  dpm_run_callback+0x44/0x170
[   45.828391]  ? pci_pm_thaw+0x90/0x90
[   45.828393]  device_resume+0xce/0x1e0
[   45.828395]  async_resume+0x18/0x40
[   45.828396]  async_run_entry_fn+0x32/0xe0
[   45.828399]  process_one_work+0x13b/0x3e0
[   45.828400]  worker_thread+0x64/0x4a0
[   45.828402]  kthread+0x10f/0x150
[   45.828404]  ? process_one_work+0x3e0/0x3e0
[   45.828406]  ? __kthread_create_on_node+0x150/0x150
[   45.828409]  ret_from_fork+0x29/0x40
[   45.828411] ---[ end tra

Re: Still OOM problems with 4.9er/4.10er kernels

[lkml]

On Thu, Mar 16, 2017 at 10:08:44AM +0100, Michal Hocko wrote:
> On Thu 16-03-17 01:47:33, l...@pengaru.com wrote:
> [...]
> > While on the topic of understanding allocation stalls, Philip Freeman 
> > recently
> > mailed linux-kernel with a similar report, and in his case there are plenty 
> > of
> > page cache pages.  It was also a GFP_HIGHUSER_MOVABLE 0-order allocation.
> 
> care to point me to the report?

http://lkml.iu.edu/hypermail/linux/kernel/1703.1/06360.html

>  
> > I'm no MM expert, but it appears a bit broken for such a low-order 
> > allocation
> > to stall on the order of 10 seconds when there's plenty of reclaimable 
> > pages,
> > in addition to mostly unused and abundant swap space on SSD.
> 
> yes this might indeed signal a problem.

Well maybe I missed something obvious that a better informed eye will catch.

Regards,
Vito Caputo

Re: Still OOM problems with 4.9er/4.10er kernels

[lkml]

On Thu, Mar 16, 2017 at 09:27:14AM +0100, Michal Hocko wrote:
> On Thu 16-03-17 07:38:08, Gerhard Wiesinger wrote:
> [...]
> > The following commit is included in that version:
> > commit 710531320af876192d76b2c1f68190a1df941b02
> > Author: Michal Hocko 
> > Date:   Wed Feb 22 15:45:58 2017 -0800
> > 
> > mm, vmscan: cleanup lru size claculations
> > 
> > commit fd538803731e50367b7c59ce4ad3454426a3d671 upstream.
> 
> This patch shouldn't make any difference. It is a cleanup patch.
> I guess you meant 71ab6cfe88dc ("mm, vmscan: consider eligible zones in
> get_scan_count") but even that one shouldn't make any difference for 64b
> systems.
> 
> > But still OOMs:
> > [157048.030760] clamscan: page allocation stalls for 19405ms, order:0, 
> > mode:0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null)
> 
> This is not OOM it is an allocation stall. The allocation request cannot
> simply make forward progress for more than 10s. This alone is bad but
> considering this is GFP_HIGHUSER_MOVABLE which has the full reclaim
> capabilities I would suspect your workload overcommits the available
> memory too much. You only have ~380MB of RAM with ~160MB sitting in the
> anonymous memory, almost nothing in the page cache so I am not wondering
> that you see a constant swap activity. There seems to be only 40M in the
> slab so we are still missing ~180MB which is neither on the LRU lists
> nor allocated by slab. This means that some kernel subsystem allocates
> from the page allocator directly.
> 
> That being said, I believe that what you are seeing is not a bug in the
> MM subsystem but rather some susbsytem using more memory than it used to
> before so your workload doesn't fit into the amount of memory you have
> anymore.
> 

While on the topic of understanding allocation stalls, Philip Freeman recently
mailed linux-kernel with a similar report, and in his case there are plenty of
page cache pages.  It was also a GFP_HIGHUSER_MOVABLE 0-order allocation.

I'm no MM expert, but it appears a bit broken for such a low-order allocation
to stall on the order of 10 seconds when there's plenty of reclaimable pages,
in addition to mostly unused and abundant swap space on SSD.

Regards,
Vito Caputo

Re: [BUG] 4.11.0-rc1 panic on shutdown X61s

[lkml]

On Tue, Mar 14, 2017 at 01:20:27AM +, Brown, Aaron F wrote:
> > Borislav Petkov  writes:
> > > On Sun, Mar 12, 2017 at 03:55:08PM +0200, Andy Shevchenko wrote:
> > >
> > >> The only change that IMHO matters happened between v4.10 and v4.11-
> > rc1 is this:
> > >>
> > >> @@ -6276,8 +6274,8 @@ static int e1000e_pm_freeze(struct device *dev)
> > >> /* Quiesce the device without resetting the hardware */
> > >> e1000e_down(adapter, false);
> > >> e1000_free_irq(adapter);
> > >> +   e1000e_reset_interrupt_capability(adapter);
> > >> }
> > >> -   e1000e_reset_interrupt_capability(adapter);
> > >>
> > >> So, it apparently misses something for the other case, like
> > >> pci_disable_msi() call or so.
> > >
> > > Well, lemme add the people from
> > >
> > >   7e54d9d063fa ("e1000e: driver trying to free already-free irq")
> > >
> > > to CC then. :-)
> > 
> > Already did that a week ago:
> > https://www.spinics.net/lists/netdev/msg423379.html
> > 
> > Haven't heard anything back yet.  Wondering if they are waiting for
> > someone else to submit the pretty obvious revert?  Don't understand why
> > that should take more than a minute to figure out.  It's not like they
> > are testing these changes anyway...
> 

> 
> What exact part (or parts) are we looking at (lspci|grep -i eth) that trigger 
> this?  Could it be a difference in .config files?  The trace says it is 
> falling back to legacy interrupts, does the system continue to work and does 
> the network continue to function in that mode?  In case it's related to user 
> space what is the base distro?  Any other information you think can help me 
> reproduce the issue would be appreciated.
> 

Config attached, the machine is a Thinkpad X61s 1.8Ghz with no onboard wireless
devices (rtl8192cu usb wifi is used).

# lspci| grep -i eth
00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network 
Connection (rev 03)

Debian jessie amd64 is the distro.

I'll have to get back to you on if the e1000e continues functioning, the
machine continues to function until the shutdown panic.

There were however some occurrences of subsequent suspend/resume cycles hanging
the machine hard leaving the display off, which prompted me to resume using
4.10 before digging any further as it's my only system right now.

Will try get around to testing 4.11 with 7e54d9d063fa reverted soon.

Regards,
Vito Caputo
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.11.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOC

Re: [BUG] 4.11.0-rc1 panic on shutdown X61s

[lkml]

On Sun, Mar 12, 2017 at 01:26:21PM +0100, Borislav Petkov wrote:
> On Sun, Mar 12, 2017 at 12:57:03PM +0100, Borislav Petkov wrote:
> > On Sat, Mar 11, 2017 at 09:37:23PM -0800, l...@pengaru.com wrote:
> > > Hello list,
> > > 
> > > Here's a photo of the panic, on imgur to be kind to vger:
> > > http://imgur.com/a/wZI32
> > > 
> > > I'm out on a sailboat so can't really do much, but had a chance with 
> > > internet
> > 
> > So you didn't bring another box with you on the sailboat to connect it to 
> > the
> > laptop over netconsole to catch full dmesg, did you?
> 
> Hahah, you're so in luck: I just sent this mail and hibernated my laptop
> and got the same BUG. What's the chance of that happening?! Apparently
> big enough.
> 
> But I was able to catch the warning before it too. So the question is,
> do you have an e1000e eth controller in that machine too?
> 
> Because the symptoms below are consistent with the observed behavior:
> e1000e fails to initialize MSI interrupts for whatever reason and falls
> back to legacy interrupts.
> 
> Then, PCI core shuts down and BUGs because the msi_list is empty.
> 
> Anyway, lemme add e1000e people too to the fun thread.
> 


Hihgly likely apparently, this machine does have e1000e and after a single
suspend+resume cycle this appears in dmesg:

[28539.220131] [ cut here ]
[28539.220131] WARNING: CPU: 1 PID: 1432 at drivers/pci/msi.c:1052 
__pci_enable_msi_range+0x39c/0x3f0
[28539.220131] CPU: 1 PID: 1432 Comm: kworker/u4:40 Not tainted 4.11.0-rc1 #51
[28539.220131] Hardware name: LENOVO 7668CTO/7668CTO, BIOS 7NETC2WW (2.22 ) 
03/22/2011
[28539.220131] Workqueue: events_unbound async_run_entry_fn
[28539.220131] Call Trace:
[28539.220131]  dump_stack+0x4d/0x72
[28539.220131]  __warn+0xc7/0xf0
[28539.220131]  warn_slowpath_null+0x18/0x20
[28539.220131]  __pci_enable_msi_range+0x39c/0x3f0
[28539.220131]  ? e1000e_get_phy_info_igp+0x1c/0xf0
[28539.220131]  pci_enable_msi+0x15/0x30
[28539.220131]  e1000e_set_interrupt_capability+0xe0/0x130
[28539.220131]  e1000e_pm_thaw+0x1d/0x50
[28539.220131]  e1000e_pm_resume+0x20/0x30
[28539.220131]  pci_pm_resume+0x5f/0x90
[28539.220131]  dpm_run_callback+0x44/0x170
[28539.220131]  ? pci_pm_thaw+0x90/0x90
[28539.220131]  device_resume+0xce/0x1e0
[28539.220131]  async_resume+0x18/0x40
[28539.220131]  async_run_entry_fn+0x32/0xe0
[28539.220131]  process_one_work+0x13b/0x3e0
[28539.220131]  worker_thread+0x64/0x4a0
[28539.220131]  kthread+0x10f/0x150
[28539.220131]  ? process_one_work+0x3e0/0x3e0
[28539.220131]  ? __kthread_create_on_node+0x150/0x150
[28539.220131]  ret_from_fork+0x29/0x40
[28539.220131] ---[ end trace e7beefda13ba724f ]---
[28539.220131] e1000e :00:19.0 eth3: Failed to initialize MSI interrupts.  
Falling back to legacy interrupts.

Regards,
Vito Caputo

[BUG] 4.11.0-rc1 panic on shutdown X61s

[lkml]

Hello list,

Here's a photo of the panic, on imgur to be kind to vger:
http://imgur.com/a/wZI32

I'm out on a sailboat so can't really do much, but had a chance with internet
to send this FYI.  I don't even know if this happens always or not yet.

Never seen this before, up to and including 4.10.0.

Regards,
Vito Caputo

Re: [BUG] 4.10-rc8 - ping spinning?

[lkml]

On Thu, Feb 16, 2017 at 10:52:19AM -0500, Soheil Hassas Yeganeh wrote:
> On Thu, Feb 16, 2017 at 10:50 AM, Soheil Hassas Yeganeh
>  wrote:
> > Thank you Vito for the report.
> >
> > The patch you cited actually resolves a similar backward compatibility
> > problem for traceroute.
> >
> > I suspect the problem here is that there's a local error queued on the
> > error queue after an ICMP message. ping apparently expect the
> > sk->sk_err to be set for the local errors as well, and hence the
> > error. Ideally, ping should read the error queue if there an EPOLLERR,
> > because local errors never sk->sk_err on their own. That is, if we
> > have
> 
> [oops] That is, if we have only one local error on the error queue, we
> cannot rely on having an error on recvmsg (i.e., sk->sk_err being set)
> even in 4.9.
> 
> 

Hi Soheil,

This doesn't appear to be trivially reproducible here by just running ping
as it were originally discovered.  I'll see if I can reliably cause the
malfunction somehow, but until then I can't meaningfully test patches.

Perhaps a form of fault injection would make more sense if there's a
reasonable idea of what this is stemming from?

I've opened an issue with iputils on github in the event that this is found
to be a ping bug.  Your input might be helpful there as well:
https://github.com/iputils/iputils/issues/74

Thanks,
Vito Caputo

Re: [BUG] 4.10-rc8 - ping spinning?

[lkml]

Hello netdev,

Please see the forwarded message below.  This was sent to linux-kernel but
after digging a little I suspect it's specific to the network stack.

Perusing the net/ changes between 4.9 and 4.10-rc8 this sounded awful related
to what I'm observing:

commit 83a1a1a70e87f676fbb6086b26b6ac7f7fdd107d
Author: Soheil Hassas Yeganeh 
Date:   Wed Nov 30 14:01:08 2016 -0500

sock: reset sk_err for ICMP packets read from error queue

Only when ICMP packets are enqueued onto the error queue,
sk_err is also set. Before f5f99309fa74 (sock: do not set sk_err
in sock_dequeue_err_skb), a subsequent error queue read
would set sk_err to the next error on the queue, or 0 if empty.
As no error types other than ICMP set this field, sk_err should
not be modified upon dequeuing them.

Only for ICMP errors, reset the (racy) sk_err. Some applications,
like traceroute, rely on it and go into a futile busy POLLERR
loop otherwise.

In principle, sk_err has to be set while an ICMP error is queued.
Testing is_icmp_err_skb(skb_next) approximates this without
requiring a full queue walk. Applications that receive both ICMP
and other errors cannot rely on this legacy behavior, as other
errors do not set sk_err in the first place.

Fixes: f5f99309fa74 (sock: do not set sk_err in sock_dequeue_err_skb)
Signed-off-by: Soheil Hassas Yeganeh 
Signed-off-by: Willem de Bruijn 
Acked-by: Eric Dumazet 
Acked-by: Maciej Żenczykowski 
Signed-off-by: David S. Miller 

Cheers,
Vito Caputo


- Forwarded message from l...@pengaru.com -

Date: Thu, 16 Feb 2017 03:17:49 -0800
From: l...@pengaru.com
To: linux-kernel@vger.kernel.org
Subject: Re: [BUG] 4.10-rc8 - ping spinning?
User-Agent: Mutt/1.5.23 (2014-03-12)

On Thu, Feb 16, 2017 at 03:03:03AM -0800, l...@pengaru.com wrote:
> Hello list,
> 
> Some rtl8192cu bugs of old got me in the habit of running ping in a shelved   
>   (i.e. forgotten) xterm, a harmless practice which seemed to prevent the 
> rtl8192cu device from dying.
> 
> This evening the system started getting very slow and to my surprise I found
> this in `top`:
>  5115 swivel30  10   14772   1928   1756 R  90.9  0.0   1351:41 ping
>  9005 swivel30  10   14772   1892   1724 R  90.9  0.0   1354:26 ping
> 
> This is a dual core machine (X61s, core2duo 1.8Ghz), those processes are
> burning all the free CPU in the system context.  They're identical commands,
> just plain `ping domain.com`, to the same host.  It appears I accidentally
> (fortuitously?) had two running, which made this event more interesting.
> 
> I can assert that these did not begin spinning simultaneously - as you can see
> by the cumulative time in `top` there's a small delta.  I also use a window
> manager with builtin continuous process monitoring, and when I noticed this 
> was
> happening I was able to see that one of the processes had only recently begun
> spinning, the other was spinning long enough to have its start fall off the
> chart (at least ~17 minutes ago).
> 
> This hasn't occurred before AFAIK, but I haven't spent much time in 4.10 yet.
> I'm pretty confident this didn't happen in 4.9 which I ran for quite a while.
> 
> `strace` of one of the aforementioned processes:
> 
> 1487241315.073568 poll([{fd=3, events=POLLIN|POLLERR}], 1, 927) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.22>
> 1487241315.073665 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.20>
> 1487241315.073747 gettimeofday({1487241315, 73774}, NULL) = 0 <0.21>
> 1487241315.073829 poll([{fd=3, events=POLLIN|POLLERR}], 1, 927) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.25>
> 1487241315.073927 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.20>
> 1487241315.074024 gettimeofday({1487241315, 74050}, NULL) = 0 <0.000256>
> 1487241315.074352 poll([{fd=3, events=POLLIN|POLLERR}], 1, 927) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.26>
> 1487241315.076241 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.22>
> 1487241315.076337 gettimeofday({1487241315, 76366}, NULL) = 0 <0.20>
> 1487241315.076422 poll([{fd=3, events=POLLIN|POLLERR}], 1, 924) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.25>
> 1487241315.076523 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.25>
> 1487241315.079770 gettimeofday({1487241315, 79799}, NULL) = 0 <0.19>
> 1487241315.079855 poll([{fd=3, events=POLLIN|POLLERR}], 1, 921) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.24>
> 1487241315.079956 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.21>
> 1487241315.080057 gettimeofday({1487241315, 80084}, NULL) = 0 <0.20>
> 1487241315.080140 poll([{fd=3, events=POLLIN|POLLERR}], 1, 921) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.24>
> 1487241315.080238 recvmsg(3, 0

Re: [BUG] 4.10-rc8 - ping spinning?

[lkml]

On Thu, Feb 16, 2017 at 03:03:03AM -0800, l...@pengaru.com wrote:
> Hello list,
> 
> Some rtl8192cu bugs of old got me in the habit of running ping in a shelved   
>   (i.e. forgotten) xterm, a harmless practice which seemed to prevent the 
> rtl8192cu device from dying.
> 
> This evening the system started getting very slow and to my surprise I found
> this in `top`:
>  5115 swivel30  10   14772   1928   1756 R  90.9  0.0   1351:41 ping
>  9005 swivel30  10   14772   1892   1724 R  90.9  0.0   1354:26 ping
> 
> This is a dual core machine (X61s, core2duo 1.8Ghz), those processes are
> burning all the free CPU in the system context.  They're identical commands,
> just plain `ping domain.com`, to the same host.  It appears I accidentally
> (fortuitously?) had two running, which made this event more interesting.
> 
> I can assert that these did not begin spinning simultaneously - as you can see
> by the cumulative time in `top` there's a small delta.  I also use a window
> manager with builtin continuous process monitoring, and when I noticed this 
> was
> happening I was able to see that one of the processes had only recently begun
> spinning, the other was spinning long enough to have its start fall off the
> chart (at least ~17 minutes ago).
> 
> This hasn't occurred before AFAIK, but I haven't spent much time in 4.10 yet.
> I'm pretty confident this didn't happen in 4.9 which I ran for quite a while.
> 
> `strace` of one of the aforementioned processes:
> 
> 1487241315.073568 poll([{fd=3, events=POLLIN|POLLERR}], 1, 927) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.22>
> 1487241315.073665 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.20>
> 1487241315.073747 gettimeofday({1487241315, 73774}, NULL) = 0 <0.21>
> 1487241315.073829 poll([{fd=3, events=POLLIN|POLLERR}], 1, 927) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.25>
> 1487241315.073927 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.20>
> 1487241315.074024 gettimeofday({1487241315, 74050}, NULL) = 0 <0.000256>
> 1487241315.074352 poll([{fd=3, events=POLLIN|POLLERR}], 1, 927) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.26>
> 1487241315.076241 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.22>
> 1487241315.076337 gettimeofday({1487241315, 76366}, NULL) = 0 <0.20>
> 1487241315.076422 poll([{fd=3, events=POLLIN|POLLERR}], 1, 924) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.25>
> 1487241315.076523 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.25>
> 1487241315.079770 gettimeofday({1487241315, 79799}, NULL) = 0 <0.19>
> 1487241315.079855 poll([{fd=3, events=POLLIN|POLLERR}], 1, 921) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.24>
> 1487241315.079956 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.21>
> 1487241315.080057 gettimeofday({1487241315, 80084}, NULL) = 0 <0.20>
> 1487241315.080140 poll([{fd=3, events=POLLIN|POLLERR}], 1, 921) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.24>
> 1487241315.080238 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.21>
> 1487241315.080322 gettimeofday({1487241315, 80350}, NULL) = 0 <0.20>
> 1487241315.080406 poll([{fd=3, events=POLLIN|POLLERR}], 1, 920) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.23>
> 1487241315.080502 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.19>
> 1487241315.080583 gettimeofday({1487241315, 80610}, NULL) = 0 <0.18>
> 1487241315.080663 poll([{fd=3, events=POLLIN|POLLERR}], 1, 920) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.24>
> 1487241315.080761 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.20>
> 1487241315.080843 gettimeofday({1487241315, 80870}, NULL) = 0 <0.20>
> 1487241315.080925 poll([{fd=3, events=POLLIN|POLLERR}], 1, 920) = 1 ([{fd=3, 
> revents=POLLERR}]) <0.37>
> 1487241315.081037 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
> (Resource temporarily unavailable) <0.20>
> 1487241315.081119 gettimeofday({1487241315, 81147}, NULL) = 0 <0.20>
> 

It's worth noting that ping is still otherwise functioning correctly, despite
the POLLERR:

1487242826.169502 sendmsg(3, {msg_name(16)={sa_family=AF_INET, 
sin_port=htons(0), sin_addr=inet_addr("xx.xxx.xxx.xxx")}, 
msg_iov(1)=[{"\10\0\245G\23\373\243uJ\206\245X\0\0\0\0\352\225\2\0\0\0\0\0\20\21\22\23\24\25\26\27"...,
 64}], msg_controllen=0, msg_flags=0}, MSG_CONFIRM) = 64 <0.000133>
1487242826.169757 recvmsg(3, {msg_name(16)={sa_family=AF_INET, 
sin_port=htons(0), sin_addr=inet_addr("66.240.222.126")}, msg_iov(1)=[{"E 
\0T\345\364\0\0002\1w\23B\360\336~\n\0\0\23\0\0\255G\23\373\243uJ\206\245X"..., 
192}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d 
/* SCM_??? */, ...}, msg_flag

[BUG] 4.10-rc8 - ping spinning?

[lkml]

Hello list,

Some rtl8192cu bugs of old got me in the habit of running ping in a shelved 
(i.e. forgotten) xterm, a harmless practice which seemed to prevent the 
rtl8192cu device from dying.

This evening the system started getting very slow and to my surprise I found
this in `top`:
 5115 swivel30  10   14772   1928   1756 R  90.9  0.0   1351:41 ping
 9005 swivel30  10   14772   1892   1724 R  90.9  0.0   1354:26 ping

This is a dual core machine (X61s, core2duo 1.8Ghz), those processes are
burning all the free CPU in the system context.  They're identical commands,
just plain `ping domain.com`, to the same host.  It appears I accidentally
(fortuitously?) had two running, which made this event more interesting.

I can assert that these did not begin spinning simultaneously - as you can see
by the cumulative time in `top` there's a small delta.  I also use a window
manager with builtin continuous process monitoring, and when I noticed this was
happening I was able to see that one of the processes had only recently begun
spinning, the other was spinning long enough to have its start fall off the
chart (at least ~17 minutes ago).

This hasn't occurred before AFAIK, but I haven't spent much time in 4.10 yet.
I'm pretty confident this didn't happen in 4.9 which I ran for quite a while.

`strace` of one of the aforementioned processes:

1487241315.073568 poll([{fd=3, events=POLLIN|POLLERR}], 1, 927) = 1 ([{fd=3, 
revents=POLLERR}]) <0.22>
1487241315.073665 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
(Resource temporarily unavailable) <0.20>
1487241315.073747 gettimeofday({1487241315, 73774}, NULL) = 0 <0.21>
1487241315.073829 poll([{fd=3, events=POLLIN|POLLERR}], 1, 927) = 1 ([{fd=3, 
revents=POLLERR}]) <0.25>
1487241315.073927 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
(Resource temporarily unavailable) <0.20>
1487241315.074024 gettimeofday({1487241315, 74050}, NULL) = 0 <0.000256>
1487241315.074352 poll([{fd=3, events=POLLIN|POLLERR}], 1, 927) = 1 ([{fd=3, 
revents=POLLERR}]) <0.26>
1487241315.076241 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
(Resource temporarily unavailable) <0.22>
1487241315.076337 gettimeofday({1487241315, 76366}, NULL) = 0 <0.20>
1487241315.076422 poll([{fd=3, events=POLLIN|POLLERR}], 1, 924) = 1 ([{fd=3, 
revents=POLLERR}]) <0.25>
1487241315.076523 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
(Resource temporarily unavailable) <0.25>
1487241315.079770 gettimeofday({1487241315, 79799}, NULL) = 0 <0.19>
1487241315.079855 poll([{fd=3, events=POLLIN|POLLERR}], 1, 921) = 1 ([{fd=3, 
revents=POLLERR}]) <0.24>
1487241315.079956 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
(Resource temporarily unavailable) <0.21>
1487241315.080057 gettimeofday({1487241315, 80084}, NULL) = 0 <0.20>
1487241315.080140 poll([{fd=3, events=POLLIN|POLLERR}], 1, 921) = 1 ([{fd=3, 
revents=POLLERR}]) <0.24>
1487241315.080238 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
(Resource temporarily unavailable) <0.21>
1487241315.080322 gettimeofday({1487241315, 80350}, NULL) = 0 <0.20>
1487241315.080406 poll([{fd=3, events=POLLIN|POLLERR}], 1, 920) = 1 ([{fd=3, 
revents=POLLERR}]) <0.23>
1487241315.080502 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
(Resource temporarily unavailable) <0.19>
1487241315.080583 gettimeofday({1487241315, 80610}, NULL) = 0 <0.18>
1487241315.080663 poll([{fd=3, events=POLLIN|POLLERR}], 1, 920) = 1 ([{fd=3, 
revents=POLLERR}]) <0.24>
1487241315.080761 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
(Resource temporarily unavailable) <0.20>
1487241315.080843 gettimeofday({1487241315, 80870}, NULL) = 0 <0.20>
1487241315.080925 poll([{fd=3, events=POLLIN|POLLERR}], 1, 920) = 1 ([{fd=3, 
revents=POLLERR}]) <0.37>
1487241315.081037 recvmsg(3, 0x7ffc8e05e260, MSG_DONTWAIT) = -1 EAGAIN 
(Resource temporarily unavailable) <0.20>
1487241315.081119 gettimeofday({1487241315, 81147}, NULL) = 0 <0.20>


Additionally, while writing this email I just experienced on an unrelated
machine just upgraded to rc8 the `vim` used to write this email entering
seemingly endless loop of select() returning 1 followed by a dozen brk() calls.
That may or may not be related, if it is related it's worth noting that machine
is a uniprocessor box running a non-SMP kernel, an old dedicated server.

I don't know how reproducible this is... if there's anything in particular
anyone wants me to do, let me know!  Not sure how long I can tolerate these
spinning processes, the X61s tends to overheat.

Regards,
Vito Caputo

Re: 4.10-rc1: thinkpad x60: who ate my cpu?

[lkml]

On Mon, Feb 13, 2017 at 12:25:28PM +0100, Thomas Gleixner wrote:
> On Mon, 13 Feb 2017, l...@pengaru.com wrote:
> 
> > On Mon, Feb 13, 2017 at 10:42:36AM +0100, Pavel Machek wrote:
> > > Hi!
> > > 
> > > On Mon 2017-02-13 09:48:41, Thomas Gleixner wrote:
> > > > On Mon, 13 Feb 2017, Pavel Machek wrote:
> > > > > cd /sys/devices/system/cpu/cpu1
> > > > > while true; do echo 0 > online; echo 1 > online; done
> > > > > 
> > > > > ...crashes x60 with 4.10-rc in few minutes. [Which is bad -- it should
> > > > > not die, but also good -- this is easier to reproduce then running 100
> > > > > suspend cycles.]
> > > > 
> > > > Can you tell where it crashes?
> > > 
> > > I did not expect a crash, so I was in X... I have a feeling that this
> > > will be reproducible on a lot of hardware, but let me try.
> > 
> > FYI: Lockup reproduced with 4.10.0-rc7 with an X61s.
> > 
> > Caught a glimpse of something about an RCU stall timeout before the system 
> > shut
> > off.  Prior to that, during the loop execution, a bunch of systemd processes
> > were experiencing watchdog timeouts, and procps `top` would start but
> > never refresh, leaving the CPU column all "nan".
> 
> Does the machine use intel_idle by chance?
> 

Config actually attached this time!

Regards,
Vito Caputo


config.gz
Description: Binary data

Re: 4.10-rc1: thinkpad x60: who ate my cpu?

[lkml]

On Mon, Feb 13, 2017 at 12:25:28PM +0100, Thomas Gleixner wrote:
> On Mon, 13 Feb 2017, l...@pengaru.com wrote:
> 
> > On Mon, Feb 13, 2017 at 10:42:36AM +0100, Pavel Machek wrote:
> > > Hi!
> > > 
> > > On Mon 2017-02-13 09:48:41, Thomas Gleixner wrote:
> > > > On Mon, 13 Feb 2017, Pavel Machek wrote:
> > > > > cd /sys/devices/system/cpu/cpu1
> > > > > while true; do echo 0 > online; echo 1 > online; done
> > > > > 
> > > > > ...crashes x60 with 4.10-rc in few minutes. [Which is bad -- it should
> > > > > not die, but also good -- this is easier to reproduce then running 100
> > > > > suspend cycles.]
> > > > 
> > > > Can you tell where it crashes?
> > > 
> > > I did not expect a crash, so I was in X... I have a feeling that this
> > > will be reproducible on a lot of hardware, but let me try.
> > 
> > FYI: Lockup reproduced with 4.10.0-rc7 with an X61s.
> > 
> > Caught a glimpse of something about an RCU stall timeout before the system 
> > shut
> > off.  Prior to that, during the loop execution, a bunch of systemd processes
> > were experiencing watchdog timeouts, and procps `top` would start but
> > never refresh, leaving the CPU column all "nan".
> 
> Does the machine use intel_idle by chance?
> 

It's not enabled in my kernel, /proc/config.gz attached FWIW.

Regards,
Vito Caputo

Re: 4.10-rc1: thinkpad x60: who ate my cpu?

[lkml]

On Mon, Feb 13, 2017 at 10:42:36AM +0100, Pavel Machek wrote:
> Hi!
> 
> On Mon 2017-02-13 09:48:41, Thomas Gleixner wrote:
> > On Mon, 13 Feb 2017, Pavel Machek wrote:
> > > cd /sys/devices/system/cpu/cpu1
> > > while true; do echo 0 > online; echo 1 > online; done
> > > 
> > > ...crashes x60 with 4.10-rc in few minutes. [Which is bad -- it should
> > > not die, but also good -- this is easier to reproduce then running 100
> > > suspend cycles.]
> > 
> > Can you tell where it crashes?
> 
> I did not expect a crash, so I was in X... I have a feeling that this
> will be reproducible on a lot of hardware, but let me try.

FYI: Lockup reproduced with 4.10.0-rc7 with an X61s.

Caught a glimpse of something about an RCU stall timeout before the system shut
off.  Prior to that, during the loop execution, a bunch of systemd processes
were experiencing watchdog timeouts, and procps `top` would start but
never refresh, leaving the CPU column all "nan".

Regards,
Vito Caputo

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

[lkml]

On Mon, Feb 06, 2017 at 07:18:16AM -0800, James Bottomley wrote:
> On Mon, 2017-02-06 at 09:50 -0500, Theodore Ts'o wrote:
> > On Sun, Feb 05, 2017 at 10:46:23PM -0800, James Bottomley wrote:
> > > Yes, I know the problem.  However, I believe most current linux
> > > filesystems no longer guarantee stable, for the lifetime of the 
> > > file, inode numbers.  The usual docker container root is overlayfs,
> > > which, similarly doesn't support stable inode numbers.  I see the 
> > > odd complaint about docker with overlayfs having unstable inode
> > > numbers, but none seems to have any serious repercussions.
> > 
> > Um, no.  Most current linux file systems *do* guarantee stable inode
> > numbers.  For one thing, NFS would break horribly if you didn't have
> > stable inode numbers.  Never mind applications which depend on POSIX
> > semantics.  And you wouldn't be able to save games in rogue or
> > nethack, either.  :-)
> 
> I believe that's why we have the superblock export operations to
> manufacture unique filehandles in the absence of inode number
> stability.  The generic one uses inode numbers, but it doesn't have to.
>  I thought reiserfs (if we can go back that far) was the first
> generally used filesystem that didn't guarantee stable inode numbers,
> so we have a lot of historical precedence.
> 
> Thanks to reiserfs, I thought we also iterated to weak stability
> guarantees for inode numbers which mean no inconsistencies in
> applications that use inode numbers for caching?  It's still not POSIX,
> but I thought it was good enough for most use cases.
> 

Even plain tar extraction is sensitive to directory inode stability:
http://git.savannah.gnu.org/cgit/tar.git/tree/src/extract.c?h=release_1_29#n867

This caused errors on overlayfs if the extraction churned through enough
of the dentry cache to evict the relevant directory (can be forced to
reproduce reliably via drop_caches).

Regards,
Vito Caputo

Re: BUG: 4.10 i915 drm display noise regression - bisected to a6a7cc4b7

[lkml]

On Mon, Jan 09, 2017 at 12:32:40AM -0600, l...@pengaru.com wrote:
> Hello all,
> 
> I'm experiencing display noise in the form of 8x1 pixel bars spuriously
> appearing in random locations.  This doesn't happen on 4.9, the machine
> is an X61s, a Core2Duo 1.8Ghz w/XGA via LVDS.
> 
> I was able to bisect the issue to a6a7cc4b7:
> 
> commit a6a7cc4b7db6deaeca11cdd38844ea147a354c7a
> Author: Chris Wilson 
> Date:   Fri Nov 18 21:17:46 2016 +
> 
> drm/i915: Always flush the dirty CPU cache when pinning the scanout
> 
> Currently we only clflush the scanout if it is in the CPU domain. Also
> flush if we have a pending CPU clflush. We also want to treat the
> dirtyfb path similar, and flush any pending writes there as well.
> 
> v2: Only send the fb flush message if flushing the dirt on flip
> v3: Make flush-for-flip and dirtyfb look more alike since they serve
> similar roles as end-of-frame marker.
> 
> Reproduction is simple, just run this native drm eye candy program:
> https://github.com/vcaputo/rototiller
> 

This regression still remains as of 4.10.0-rc6.

Chris Wilson had posted a fix:
https://www.spinics.net/lists/kernel/msg2420777.html

But it seems to have been ignored so far.  How do we get this fixed in
4.10 before it ships?

Regards,
Vito Caputo

Re: [PATCH v2] drm/i915: Flush untouched framebuffers before display on !llc

[lkml]

On Thu, Jan 12, 2017 at 09:17:06PM +, Chris Wilson wrote:
> On Mon, Jan 09, 2017 at 11:19:32AM +, Chris Wilson wrote:
> > On a non-llc system, the objects are created with .cache_level =
> > CACHE_NONE and so the transition to uncached for scanout is a no-op.
> > However, if the object was never written to, it will still be in the CPU
> > domain (having been zeroed out by shmemfs). Those cachelines need to be
> > flushed prior to display.
> > 
> > Reported-by: Vito Caputo
> > Fixes: a6a7cc4b7db6 ("drm/i915: Always flush the dirty CPU cache when 
> > pinning the scanout")
> > Signed-off-by: Chris Wilson 
> > Cc:  # v4.10-rc1+
> 
> Ping?

This patch fixes the problem for me, in case that's what the ping's for.

Out of curiosity the bug I reported described here be getting fixed in 4.10?
https://lists.freedesktop.org/archives/dri-devel/2017-January/128405.html

Thanks.

> 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 76689b59fc90..bdb113ef8cfe 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3514,7 +3514,7 @@ i915_gem_object_pin_to_display_plane(struct 
> > drm_i915_gem_object *obj,
> > vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
> >  
> > /* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() */
> > -   if (obj->cache_dirty) {
> > +   if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU) {
> > i915_gem_clflush_object(obj, true);
> > intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
> > }
> > -- 
> > 2.11.0
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 4.9 003/116] rtlwifi: Fix enter/exit power_save

[lkml]

On Tue, Jan 10, 2017 at 09:40:24PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 10, 2017 at 08:40:28PM +0300, Dmitry Osipenko wrote:
> > Hello, this patch causes a kernel panic with the rtl8192cu driver.
> 
> Ick, not good!  Does this cause a problem in Linus's tree as well?
> 

http://lkml.iu.edu/hypermail/linux/kernel/1701.1/00228.html

BUG: 4.10 i915 drm display noise regression - bisected to a6a7cc4b7

[lkml]

Hello all,

I'm experiencing display noise in the form of 8x1 pixel bars spuriously
appearing in random locations.  This doesn't happen on 4.9, the machine
is an X61s, a Core2Duo 1.8Ghz w/XGA via LVDS.

I was able to bisect the issue to a6a7cc4b7:

commit a6a7cc4b7db6deaeca11cdd38844ea147a354c7a
Author: Chris Wilson 
Date:   Fri Nov 18 21:17:46 2016 +

drm/i915: Always flush the dirty CPU cache when pinning the scanout

Currently we only clflush the scanout if it is in the CPU domain. Also
flush if we have a pending CPU clflush. We also want to treat the
dirtyfb path similar, and flush any pending writes there as well.

v2: Only send the fb flush message if flushing the dirt on flip
v3: Make flush-for-flip and dirtyfb look more alike since they serve
similar roles as end-of-frame marker.

Reproduction is simple, just run this native drm eye candy program:
https://github.com/vcaputo/rototiller

Thanks,
Vito Caputo

Re: BUG: 4.10 rtlwifi regression - NULL pointer dereference

[lkml]

On Sun, Jan 08, 2017 at 08:03:18PM -0600, Larry Finger wrote:
> On 01/08/2017 07:41 PM, l...@pengaru.com wrote:
> > Hello list,
> > 
> > Gave 4.10-rc2 a shot today using the attached config.  The kernel panics
> > with a NULL pointer dereference upon starting dhclient after
> > wpa_supplicant.
> > 
> > The network device is a USB dongle:
> > Bus 002 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 
> > 802.11n Wireless Adapter [Realtek RTL8188CUS]
> > 
> > Reverting 'ba9f93f rtlwifi: Fix enter/exit power_save' prevents the
> > crash.
> > 
> > Sorry I don't have a verbatim capture of the panic, but I was able to
> > catch the relevant parts and rtl_lps_leave() is dereferencing a NULL hw,
> > below setup_arp_tx() and rtl_is_special_data().  That's what led me to
> > reverting ba9f93f since it clearly plays with that stuff.
> > 
> > FWIW machine is a plain X61s thinkpad, 1.8Ghz.
> > 
> 
> You need the patch from
> http://marc.info/?l=linux-wireless&m=148234081512703&w=2. It was pushed with
> the notation that it needed to be included in 4.10; however, it has not yet
> percolated through the system.
> 

Thanks for the quick response Larry, on a Sunday even!

Cheers,
Vito Caputo

BUG: 4.10 rtlwifi regression - NULL pointer dereference

[lkml]

Hello list,

Gave 4.10-rc2 a shot today using the attached config.  The kernel panics
with a NULL pointer dereference upon starting dhclient after
wpa_supplicant.

The network device is a USB dongle:
Bus 002 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n 
Wireless Adapter [Realtek RTL8188CUS]

Reverting 'ba9f93f rtlwifi: Fix enter/exit power_save' prevents the
crash.

Sorry I don't have a verbatim capture of the panic, but I was able to
catch the relevant parts and rtl_lps_leave() is dereferencing a NULL hw,
below setup_arp_tx() and rtl_is_special_data().  That's what led me to
reverting ba9f93f since it clearly plays with that stuff.

FWIW machine is a plain X61s thinkpad, 1.8Ghz.

Regards,
Vito Caputo
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.10.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_NMI_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_CGROUPS=y
# CONFIG_MEMCG is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_CGROUP_PIDS is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_HUGETLB is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CGROUP_CPUACCT=y
# CONF

Re: [PATCH 4.1 125/159] net: call rcu_read_lock early in process_backlog

[Andre Tomt (LKML)]

On 26. sep. 2015 22:56, Greg Kroah-Hartman wrote:

4.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Julian Anastasov 

[ Upstream commit 2c17d27c36dcce2b6bf689f41a46b9e909877c21 ]

Incoming packet should be either in backlog queue or
in RCU read-side section. Otherwise, the final sequence of
flush_backlog() and synchronize_net() may miss packets
that can run without device reference:



Several of our 4.1.9-rc1 running systems are experiencing hangs 
requiring hardware/sysrq reset with this patch applied. Reverting it 
fixes the hangs completely.


4.2 includes this patch as well but I have no such problems there. 
4.2.2-rc1 works fine as well.


For now I think this patch should be reverted in 4.1.9.

The hangs have occured so far on Xen PV and KVM x86_64 virtual machines, 
they will hang completely within minutes or hours depending on the type 
of workload. The workloads are all fairly light, one running low traffic 
email/antispam, another running monitoring and metrics of ~5 hosts and 
one running a single terminal IRC client. All but the IRC one will hang 
within a few minutes of booting.


When they lock up they only respond to sysrq, with ttyS0/hvc0 not 
echoing anything typed in back, and are completely dead on the network. 
One system managed to report rcu stalls but no backtraces (I'll look 
over the debug config, if there is any interest).


My bare metal desktop has yet to be able to hit it, but it might be 
entirely down to a different type of workload.


Something missing in 4.1?

--
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 4.1 000/159] 4.1.9-stable review

[Andre Tomt (LKML)]

On 26. sep. 2015 22:54, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.1.9 release.
There are 159 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Mon Sep 28 20:51:39 UTC 2015.
Anything received after that time might be too late.


Hi Greg,

4.1.9 seems to hang after a while on several of my systems (KVM and Xen 
PV). Seems network related. Did not occur in 4.1.8. Investigating..


Got some suspects and will chime back in in a bit.

--
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] sysfs.txt: mention that store method buffers are null-terminated

[ulfalizer . lkml]

From: Ulf Magnusson 

Without knowing this, the use of sysfs_streq() becomes puzzling.

The termination happens in kernfs_fop_write().

Signed-off-by: Ulf Magnusson 
---
 Documentation/filesystems/sysfs.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/filesystems/sysfs.txt 
b/Documentation/filesystems/sysfs.txt
index 9494afb..575e997 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -198,6 +198,9 @@ implementations:
   entire file, modify the values it wishes to change, then write the
   entire buffer back. 
 
+  A terminating null is added after the data on stores. This makes
+  functions like sysfs_streq() safe to use.
+
   Attribute method implementations should operate on an identical
   buffer when reading and writing values. 
 
-- 
2.1.4

--
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] debugfs: document that debugfs_remove*() accepts NULL and error values

[ulfalizer . lkml]

From: Ulf Magnusson 

According to commit a59d6293e537 ("debugfs: change parameter check in
debugfs_remove() functions"), this is meant to make cleanup easier for
callers. In that case it ought to be documented.

Signed-off-by: Ulf Magnusson 
---
 fs/debugfs/inode.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index c711be8..5d8f35f 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -533,7 +533,8 @@ static int __debugfs_remove(struct dentry *dentry, struct 
dentry *parent)
 /**
  * debugfs_remove - removes a file or directory from the debugfs filesystem
  * @dentry: a pointer to a the dentry of the file or directory to be
- *  removed.
+ *  removed.  If this parameter is NULL or an error value, nothing
+ *  will be done.
  *
  * This function removes a file or directory in debugfs that was previously
  * created with a call to another debugfs function (like
@@ -565,7 +566,8 @@ EXPORT_SYMBOL_GPL(debugfs_remove);
 
 /**
  * debugfs_remove_recursive - recursively removes a directory
- * @dentry: a pointer to a the dentry of the directory to be removed.
+ * @dentry: a pointer to a the dentry of the directory to be removed.  If this
+ *  parameter is NULL or an error value, nothing will be done.
  *
  * This function recursively removes a directory tree in debugfs that
  * was previously created with a call to another debugfs function
-- 
2.1.4

--
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] debugfs: document that debugfs_remove*() accepts NULL and error values

[ulfalizer . lkml]

From: Ulf Magnusson 

According to commit a59d6293e537 ("debugfs: change parameter check in
debugfs_remove() functions"), this is meant to make cleanup easier for
callers. In that case it ought to be documented.

Signed-off-by: Ulf Magnusson 
---
 fs/debugfs/inode.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index c711be8..5d8f35f 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -533,7 +533,8 @@ static int __debugfs_remove(struct dentry *dentry, struct 
dentry *parent)
 /**
  * debugfs_remove - removes a file or directory from the debugfs filesystem
  * @dentry: a pointer to a the dentry of the file or directory to be
- *  removed.
+ *  removed.  If this parameter is NULL or an error value, nothing
+ *  will be done.
  *
  * This function removes a file or directory in debugfs that was previously
  * created with a call to another debugfs function (like
@@ -565,7 +566,8 @@ EXPORT_SYMBOL_GPL(debugfs_remove);
 
 /**
  * debugfs_remove_recursive - recursively removes a directory
- * @dentry: a pointer to a the dentry of the directory to be removed.
+ * @dentry: a pointer to a the dentry of the directory to be removed.  If this
+ *  parameter is NULL or an error value, nothing will be done.
  *
  * This function recursively removes a directory tree in debugfs that
  * was previously created with a call to another debugfs function
-- 
2.1.4

--
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] kobject: explain what kobject's sd field is

[ulfalizer . lkml]

From: Ulf Magnusson 

(More) unclear, especially name-wise, after sysfs_dirent became
kernfs_node.

Signed-off-by: Ulf Magnusson 
---
 include/linux/kobject.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index 637f670..e628459 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -66,7 +66,7 @@ struct kobject {
struct kobject  *parent;
struct kset *kset;
struct kobj_type*ktype;
-   struct kernfs_node  *sd;
+   struct kernfs_node  *sd; /* sysfs directory entry */
struct kref kref;
 #ifdef CONFIG_DEBUG_KOBJECT_RELEASE
struct delayed_work release;
-- 
2.1.4

--
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] Makefile: .PHONY is not a variable, but PHONY is

[ulfalizer . lkml]

From: Ulf Magnusson 

.PHONY is a target, not a variable.

Signed-off-by: Ulf Magnusson 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 24c9e3d..4835d24 100644
--- a/Makefile
+++ b/Makefile
@@ -1609,6 +1609,6 @@ endif # skip-makefile
 PHONY += FORCE
 FORCE:
 
-# Declare the contents of the .PHONY variable as phony.  We keep that
+# Declare the contents of the PHONY variable as phony.  We keep that
 # information in a variable so we can use it in if_changed and friends.
 .PHONY: $(PHONY)
-- 
2.1.4

--
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 1/3] sysfs.txt: fix pre-kernfs sysfs_dirent reference

[ulfalizer . lkml]

From: Ulf Magnusson 

sysfs_dirent went away when kernfs was extracted from sysfs. The reference
to the kobject now lives in a kernfs_node (in the 'priv' member).

See commit 324a56e16e44 ("kernfs: s/sysfs_dirent/kernfs_node/ and rename
its friends accordingly").

Signed-off-by: Ulf Magnusson 
---
 Documentation/filesystems/sysfs.txt   | 2 +-
 Documentation/zh_CN/filesystems/sysfs.txt | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/filesystems/sysfs.txt 
b/Documentation/filesystems/sysfs.txt
index 9494afb..78170ed 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -40,7 +40,7 @@ ancestors of object hierarchies; i.e. the subsystems the 
objects
 belong to. 
 
 Sysfs internally stores a pointer to the kobject that implements a
-directory in the sysfs_dirent object associated with the directory. In
+directory in the kernfs_node object associated with the directory. In
 the past this kobject pointer has been used by sysfs to do reference
 counting directly on the kobject whenever the file is opened or closed.
 With the current sysfs implementation the kobject reference count is
diff --git a/Documentation/zh_CN/filesystems/sysfs.txt 
b/Documentation/zh_CN/filesystems/sysfs.txt
index e230eaa..7d3b05e 100644
--- a/Documentation/zh_CN/filesystems/sysfs.txt
+++ b/Documentation/zh_CN/filesystems/sysfs.txt
@@ -61,7 +61,7 @@ Documentation/kobject.txt 文档以获得更多关于 kobject 接口的
 内核的对象层次到用户空间。sysfs 中的顶层目录代表着内核对象层次的
 共同祖先；例如：某些对象属于某个子系统。
 
-Sysfs 在与其目录关联的 sysfs_dirent 对象中内部保存一个指向实现
+Sysfs 在与其目录关联的 kernfs_node 对象中内部保存一个指向实现
 目录的 kobject 的指针。以前，这个 kobject 指针被 sysfs 直接用于
 kobject 文件打开和关闭的引用计数。而现在的 sysfs 实现中，kobject
 引用计数只能通过 sysfs_schedule_callback() 函数直接修改。
-- 
2.1.4

--
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 3/3] configfs: fix pre-kernfs sysfs_dirent reference

[ulfalizer . lkml]

From: Ulf Magnusson 

sysfs_dirent was renamed in 324a56e16e44 ("kernfs:
s/sysfs_dirent/kernfs_node/ and rename its friends accordingly").

Do s/sysfs_dirent/configfs_dirent/ - possibly a copy-paste error to
begin with. Clean up the language a bit too.

Signed-off-by: Ulf Magnusson 
---
 fs/configfs/inode.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/fs/configfs/inode.c b/fs/configfs/inode.c
index eae8757..e076661 100644
--- a/fs/configfs/inode.c
+++ b/fs/configfs/inode.c
@@ -133,13 +133,14 @@ struct inode *configfs_new_inode(umode_t mode, struct 
configfs_dirent *sd,
inode->i_mapping->a_ops = &configfs_aops;
inode->i_op = &configfs_inode_operations;
 
-   if (sd->s_iattr) {
-   /* sysfs_dirent has non-default attributes
-* get them for the new inode from persistent copy
-* in sysfs_dirent
+   if (sd->s_iattr)
+   /*
+* configfs_dirent has non-default attributes. Set them
+* on the new inode from the persistent copy in
+* configfs_dirent.
 */
set_inode_attr(inode, sd->s_iattr);
-   } else
+   else
set_default_inode_attr(inode, mode);
}
return inode;
-- 
2.1.4

--
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 0/3] Fix some outdated pre-kernfs doc references

[ulfalizer . lkml]

From: Ulf Magnusson 

sysfs-tagging.txt contains more outdated references (e.g., to various
kobj_ns_*() functions that no longer exist), but hopefully it should be in
a better shape than before. I'm new to sysfs internals in general.

The configfs change is a guess that seemed reasonable.

Ulf Magnusson (3):
  sysfs.txt: fix pre-kernfs sysfs_dirent reference
  sysfs-tagging.txt: fix pre-kernfs references
  configfs: fix pre-kernfs sysfs_dirent reference

 Documentation/filesystems/sysfs-tagging.txt | 14 +++---
 Documentation/filesystems/sysfs.txt |  2 +-
 Documentation/zh_CN/filesystems/sysfs.txt   |  2 +-
 fs/configfs/inode.c | 11 ++-
 4 files changed, 15 insertions(+), 14 deletions(-)

-- 
2.1.4

--
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 2/3] sysfs-tagging.txt: fix pre-kernfs references

[ulfalizer . lkml]

From: Ulf Magnusson 

 - sysfs_dirent is now kernfs_node - see commit 324a56e16e44 ("kernfs:
   s/sysfs_dirent/kernfs_node/ and rename its friends accordingly")

 - sysfs_super_info is now kernfs_super_info - see commit c525aaddc366
   ("kernfs: s/sysfs/kernfs/ in various data structures")

 - the 's_' prefix was dropped from various fields - see
   commit adc5e8b58f48 ("kernfs: drop s_ prefix from kernfs_node members")

Signed-off-by: Ulf Magnusson 
---
 Documentation/filesystems/sysfs-tagging.txt | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/filesystems/sysfs-tagging.txt 
b/Documentation/filesystems/sysfs-tagging.txt
index eb843e4..c7c8e64 100644
--- a/Documentation/filesystems/sysfs-tagging.txt
+++ b/Documentation/filesystems/sysfs-tagging.txt
@@ -17,13 +17,13 @@ the sysfs directory entries we ensure that we don't have 
conflicts
 in the directories and applications only see a limited set of
 the network devices.
 
-Each sysfs directory entry may be tagged with zero or one
-namespaces.  A sysfs_dirent is augmented with a void *s_ns.  If a
-directory entry is tagged, then sysfs_dirent->s_flags will have a
-flag between KOBJ_NS_TYPE_NONE and KOBJ_NS_TYPES, and s_ns will
-point to the namespace to which it belongs.
+Each sysfs directory entry may be tagged with a namespace via the
+void *ns member of its kernfs_node.  If a directory entry is tagged,
+then kernfs_node->flags will have a flag between KOBJ_NS_TYPE_NONE
+and KOBJ_NS_TYPES, and ns will point to the namespace to which it
+belongs.
 
-Each sysfs superblock's sysfs_super_info contains an array void
+Each sysfs superblock's kernfs_super_info contains an array void
 *ns[KOBJ_NS_TYPES].  When a task in a tagging namespace
 kobj_nstype first mounts sysfs, a new superblock is created.  It
 will be differentiated from other sysfs mounts by having its
@@ -31,7 +31,7 @@ s_fs_info->ns[kobj_nstype] set to the new namespace.  Note 
that
 through bind mounting and mounts propagation, a task can easily view
 the contents of other namespaces' sysfs mounts.  Therefore, when a
 namespace exits, it will call kobj_ns_exit() to invalidate any
-sysfs_dirent->s_ns pointers pointing to it.
+kernfs_node->ns pointers pointing to it.
 
 Users of this interface:
 - define a type in the kobj_ns_type enumeration.
-- 
2.1.4

--
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 4.1 099/123] perf hists browser: Take the --comm, --dsos, etc filters into account

[Andre Tomt (LKML)]

On 09. aug. 2015 00:09, Greg Kroah-Hartman wrote:

4.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnaldo Carvalho de Melo 

commit 9c0fa8dd3d58de8b688fda758eea1719949c7f0a upstream.


This commit needs upstream commit 
0bc2f2f7d080561cc484d2d0a162a9396bed3383 as well to fix the following 
build error



  CC   ui/browsers/hists.o
ui/browsers/hists.c: In function 'hist_browser__has_filter':
ui/browsers/hists.c:48:68: error: 'struct symbol_conf' has no member 
named 'has_filter'
  return hists__has_filter(hb->hists) || hb->min_pcnt || 
symbol_conf.has_filter;

^
ui/browsers/hists.c:49:1: error: control reaches end of non-void 
function [-Werror=return-type]

 }
 ^
cc1: all warnings being treated as errors
/disks/build/data/linux-4.1.5-rc1/tools/build/Makefile.build:68: recipe 
for target 'ui/browsers/hists.o' failed

make[4]: *** [ui/browsers/hists.o] Error 1
/disks/build/data/linux-4.1.5-rc1/tools/build/Makefile.build:107: recipe 
for target 'browsers' failed

make[3]: *** [browsers] Error 2
/disks/build/data/linux-4.1.5-rc1/tools/build/Makefile.build:107: recipe 
for target 'ui' failed

make[2]: *** [ui] Error 2
Makefile.perf:366: recipe for target 'libperf-in.o' failed
make[1]: *** [libperf-in.o] Error 2
Makefile:68: recipe for target 'all' failed
make: *** [all] Error 2


--
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: snd_hda_intel headphone output disabling upon complete insertion of plug

[lkml]

On Tue, Oct 08, 2013 at 02:34:33PM -0700, Mark Knecht wrote:
> On Tue, Oct 8, 2013 at 2:07 PM,   wrote:
> > Hello list,
> >
> > Somewhere between 3.11.0-rc7-gfa8218d and 3.12.0-rc4-g8b5ede6 this
> > broke.
> >
> > The machine is an x61s thinkpad, with the headphone output unmuted and
> > headphones partially inserted sound is audible.  If the output is muted,
> > the output shuts off.  With the output unmuted, upon inserting the
> > headphone plug fully the output shuts off following a blink of a delay.
> > If I slowly remove the headphone plug returning it to a partially inserted
> > state, the audio returns after another delay.
> >
> > It seems like a bug in the headphone amplifier power management, as if
> > it's doing the inverse of what it needs to do.  I'll try find time to
> > bisect, just wanted to get this out there though in case any of you
> > recognize the problem and know what might have caused it.
> >
> > Regards,
> > Vito Caputo
> 
> Sometimes across kernel revisions I've had problems like this.
> (Although not that specific one!) It seems that the asound.state file
> format changes and alsa renumbers their internal controls. You might
> try saving the existing file elsewhere and then setting up alsa again
> from scratch. That solved my last problem of that type.
> 

NAK, has no effect.  Looking at the diff between the revisions under
sound/pci/hda there appears to be quite a bit of activity.  Hopefully I
can get around to bisecting this weekend.  Leaving the headphones 90%
inserted is workable for now.

Regards,
Vito Caputo
--
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/

snd_hda_intel headphone output disabling upon complete insertion of plug

[lkml]

Hello list,

Somewhere between 3.11.0-rc7-gfa8218d and 3.12.0-rc4-g8b5ede6 this
broke.

The machine is an x61s thinkpad, with the headphone output unmuted and
headphones partially inserted sound is audible.  If the output is muted,
the output shuts off.  With the output unmuted, upon inserting the
headphone plug fully the output shuts off following a blink of a delay.
If I slowly remove the headphone plug returning it to a partially inserted
state, the audio returns after another delay.

It seems like a bug in the headphone amplifier power management, as if
it's doing the inverse of what it needs to do.  I'll try find time to
bisect, just wanted to get this out there though in case any of you
recognize the problem and know what might have caused it.

Regards,
Vito Caputo
--
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/

Commence Industrial Crm Profiled By simply Manufacturing Correspondent Thomas R. Cutler

[lkml]

Reported by Thomas UR. Cutler, Manufacturing Journalist in the recent issue of 
Alternative Focus, "The foundation of any quality revenue organization starts 
with all the implementation in addition to management of an sales 
process.Thomas sabo rea These is also the steps required by the sales 
representative to move the prospect from the initial introduction stage to the 
closing step.

Few industrial CRM models provide manufacturers which has a structured 
established sales method or technique for considering and handling each stage 
of the sales bike. A pro-active way of managing the sales procedure allows this 
sales manager to monitor and supply guidance through cycle, in addition to help 
gross sales representatives consentrate on the most effective opportunities. " 
This article can be read in its entirety  thomas sabo sverige.

Caretsky, noted within the feature posting that "CEOs worth mentioning 
companies usually share exactly how their innovative enterprise resource 
planning (ERP) program provides them whatever they want, but are not able to 
recognize that ERP programs provide information following a sale, not ahead of 
or in the sales process. Thomas sabo smycken ERP programs provide absolutely no 
value with regard to improving this efficiency of how to sell in addition to 
service buyers. This will be one cause that outlook reports tend to be always 
incorrect. "

Commence presents industrial organizations complete "Freedom Connected with 
Choice" purchase the solutions and program that ideal meets this company 
requirements regarding manufacturers in addition to distributors. The 
comprehensive CRM Alternative application suite can be purchased for work with 
on game play or on- demand as being a hosted service. Thomas sabo berlocker 
Industrial leaders often construct departmental CRM solutions while using award 
successful Commence Commercial CRM Platform. These alternatives are why so many 
industrial organizations choose Commence as the solution pertaining to managing 
shopper relationships. Almost all Commence Alternative solutions support mobile 
and also wireless connectivity in addition to integration for you to 
back-office accounting in addition to ERP models.

Datacraft Alternatives specializes in providing their particular clients 
considering the tools they need to rapidly replace outdated guide systems 
together with technology which speeds method flow and improves precision. 
Thomas Sabo Halsband Datacraft's highest regarded product, Signum continues to 
be developed throughout the Kanban notion of replenishment, and provides a 
pivotal tool pertaining to manufacturing organizations to watch process stream, 
lower administrative transaction expenditures, and improve decision-making 
power.

---
posted at http://www.serverphorums.com
http://www.serverphorums.com/read.php?12,743669,743669#msg-743669
--
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/

Selling Creative With Nike

[lkml]

Time that we have the ad and even slogan suitable dull detect, just 
"advertised", so whereby consumers can not be tempted, in all probability to 
crash. At length of time, advertising creative instead of a typical literary 
plus artistic growth, it might only screen advertising themes or templates or 
themes, advertising procedures by marketplace environment and also the 
constraints, the pursuit is a most economical nike schuhe bestellen in 
improvement to concise approach, promote the store's corporate vendor and item 
personality, to take full advantage of communication in addition to affect 
shoppers.

This image isn't just beautiful, appeals into the imagination, in addition to 
meaningful, especially to view them association up additional. Image facts 
behind the exact group marked the fresh face of Nike: Nike brand has already 
been not only for youth but additionally for seniors, not just for men but 
additionally for young ladies, not simply for the the planet's leading 
champions with the unknown road movement. Nike passed another kind of image 
connected with any voice. nike schuhe deutschland did definitely not directly 
claim "revolution" although announced every "revolution", and these can be a 
popular but not limited to the service for a few brands.

In the new field hockey game, you will discover 40 debut with Nike weather max 
2009 basketball shoes and boots and " booties ", which contains nike air max 
bestellen. The clean game initiated seeing participants obtain basketball shoes 
will be wide and also varied, the ball player doesn't need 80 points or maybe 
more, or catch greater than 22 rebounds to becoming a pair regarding footwear 
trapeze, the important is will depend on your participate in time. Select the 
sneakers following the golfer who could possibly get precise tips, such seeing 
that its meaning, history, and Jordan following the initial evaluation to 
discover the shoes etc.

Nike Jordan following introduced any generation for you to sign should the red 
along with black sneakers or boots, NBA objectives are yet wearing the majority 
the fairly old-fashioned ebony and Nike Air Max sale deutschland. Jordan to 
understand the shoes which could not wear, but still place on the early morning 
after long run. The NBA is not allowed, each carrying around a Jordan Jordan is 
certain to get a great result, Nike Jordan paid out all fines, Nike ambiance 
max 24-7, along with become well-known.

Right now, the Nike Air Max Damen scientific suggestions embodied in the 
creative and also advertising activities of every session. Scientific in 
addition to artistic resourcefulness in advertising may be a contradiction from 
the unity, discussed penetration, together play a role. Make innovative 
scientific a lot more rational, additional artistic sense is therefore 
creative. That wonderful ingenuity, science in addition to art need to be 
perfect unity on the crystal.

---
posted at http://www.serverphorums.com
http://www.serverphorums.com/read.php?12,743667,743667#msg-743667
--
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/

Nike Jordan compensated all fines

[lkml]

Should the ad or even slogan in to a dull note, just "advertised", so in which 
consumers cannot be tempted, likely to don't succeed. At the same time frame, 
advertising creative rather than a normal literary and artistic design, it 
might only demonstrate advertising subjects, advertising methods by current 
market environment and the constraints, the pursuit could be the most 
economical  nike schuhe bestellen 90 and concise means, promote your corporate 
manufacturer and merchandise personality, to maximise communication and also 
affect people.

This image is not only beautiful, appeals towards imagination, and also 
meaningful, especially to see them website link up all the more. Image info 
behind the particular group marked the modern face connected with Nike: Nike 
brand is now not only for youth but in addition for older people, not only for 
men but also for adult females, not only for the globe's leading champions with 
the unknown roadway movement. Nike passed some other image on the voice. nike 
schuhe deutschland did possibly not directly say "revolution" yet announced any 
"revolution", which may be a popular although not limited towards the service 
just the summer brands.

Within the new field hockey game, there are actually 40 debut with Nike air max 
2010 basketball footwear, which contains nike air max bestellen. The new game 
how players acquire basketball shoes fluctuate, the player would not need to 
get 80 points or maybe more, or catch in excess of 22 rebounds to obtain a pair 
associated with shoes trapeze, the key is depends on your have fun with time. 
Mouse click on the shoes following your player who will get detailed 
information, which include its importance, history, and Jordan following your 
first evaluation to see the shoes and so on.

Nike Jordan subsequently introduced some sort of generation in order to sign 
should the red along with black " booties ", NBA participants are even now 
wearing a lot of the relatively old-fashioned charcoal and Nike Air Max sale 
deutschland. Jordan to discover the shoes that could not have on, but still 
apply to the day time after tomorrow. The NBA will not be allowed, each 
sporting a Michael Jordan are certain to get a very good result, Nike Jordan 
compensated all fines, Nike air flow max 24-7, who has become renowned.

Today, the Nike Air Max Damen scientific principles embodied within the 
creative and advertising activities of every session. Scientific as well as 
artistic creativity in advertising may be a contradiction on the unity, mutual 
penetration, together are likely involved. Make inspiring scientific plus much 
more rational, much more artistic feeling is consequently creative. The 
excellent creativity, science as well as art must be perfect unity on the 
crystal.

---
posted at http://www.serverphorums.com
http://www.serverphorums.com/read.php?12,743668,743668#msg-743668
--
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/

Replica Soccer paidat jalkapallon ystäville

[lkml]

Nauti jalkapallo kausi ja näyttää rakkautta suosikki joukkue replica jalkapallo 
pelipaidat. Ne voivat olla apt että jalkapallofanit, jotka rakastavat kaiken 
peliin ja kävellä ulos oikea tapa edustaa villitys suhteen jalkapallo 
pelipaidat halvalla suosikki joukkue. Ostot jäljennöksiä osoittaa, että sinun 
ei tarvitse viettää paljon ympäri pelipaidat, jotka mahdollistavat sen silti 
ilmaista ex tyttöystävä että peli.

Erilaisia ​​Replica Soccer paidat ovat myynnissä ostajia, jotka löytävät ne 
helposti nyt. Salaisuus menestykseen on kuitenkin oltava pelipaita, että ei ole 
pelkästään hyvä kopio, mutta on hyödyllisin laatua samanaikaisesti. Useat 
valmistaa jotka tarjoavat käyttäen jäljennöksiä usein vaarantaa ympäri 
huippuosaamista tuotteen vähentämiseksi kirjataan ostohinnan ja ansaita enemmän 
voittoa. Tämäntyyppinen pelipaita voi etsiä halpoja, joka mahdollistaa sen jopa 
tulla epämiellyttävä.

Kiva valmistajat taata, että ne käyttävät parasta laatua ainetta valmistaakseen 
pelipaidat. He käyttävät puuvillaa,jalkapallo pelipaidat painatus jotta ne, 
jotka eivät yksinkertaisesti näyttää hyvältä, mutta on varsin mukava käyttää. 
Tällaiset Replica jalkapallo pelipaidat ovat omiaan henkilöille, jotka ei ole 
varaa saada kalliita alkuperäisiin. Ne laittaa ne näyttävät muodikas myös tukea 
heidän paras joukkue.

Nykyään jalkapallofaneja voisi myös odottaa saada Custom pelipaidat, jotka 
kantavat yhteistä pelaajat nimen ja numeron. On monia valmistajia, jotka 
pystyvät esitellä teille tämän palvelun ja voit helposti saada oikea pelipaita. 
Tässä tapauksessa sinun kannattaa tehdä tilauksen etukäteen ja kertoa heille, 
mitä nimen tai numeron mitä tarvitset Custom pelipaidat.

Custom pelipaidat eivät yleensä ole helposti saatavilla kaikki nykyiset 
myymälät ja näin voit etsiä online-valmistaja, joka voi tarjota samaa. 
Tällainen valmistaja auttaa sinua saamaan Replica Soccer paitoja eri joukkueet 
ja voit helposti valita yksi, joka edustaa paras joukkue. Web-pohjainen 
myymälöissä ylläpitää kokoelma kodin jersey ja menossa pois pelipaidat, jotka 
ovat saatavilla eri kokoja.

---
posted at http://www.serverphorums.com
http://www.serverphorums.com/read.php?12,742844,742844#msg-742844
--
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/

Bluez with uclibc

[lkml]

Hi,

Today, I need to cross compile Bluez for arm with uclibc library into Buildroot 
environment. 
However, I meet some dependencies between bluez-utils package and MMU 
deactivation due to dBus.

Do you know a way to use Bluez with uclibc library?

Thanks in advance

Regards

---
posted at http://www.serverphorums.com
http://www.serverphorums.com/read.php?12,739510,739510#msg-739510
--
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 v5 0/7] eCryptfs: added support for the encrypted key type

[lkml]

Hi there, 


Either this is completely braindead, or I'm missing something very obvious. 
Why mess up encrypted keys with various "format" fixes. 
I hope this doesn't start a trend. 

The right (and disturbingly simpler) approach to fixing the auth_token vs. 
raw key material issue would be to put the fix in eCryptfs. 

In fact, all the relevant bits for filling the token from the key_desc/sig 
should be moved 
from security/keys/encrypted/ecryptfs_format.c to 
fs/ecryptfs/ecryptfs_kernel.h, 
and all the format cruft in encrypted-keys reverted. 
Then pretty much any "default" encrypted key could be used for ecryptfs… 

What am I missing? 


--@;

---
posted at http://www.serverphorums.com
http://www.serverphorums.com/read.php?12,341340,618745#msg-618745
--
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: WANTED: kernel projects for CS students

[Doug Whitesell (LKML)]

On Oct 14, 2007, at 4:01 PM, Rik van Riel wrote:


The kernel newbies community often gets inquiries from CS students who
need a project for their studies and would like to do something with
the Linux kernel, but would also like their code to be useful to the
community afterwards.

In order to make it easier for them, I am trying to put together a
page with projects that:
- Are self contained enough that the students can implement the
  project by themselves, since that is often a university requirement.
- Are self contained enough that Linux could merge the code (maybe
  with additional changes) after the student has been working on it
  for a few months.
- Are large enough to qualify as a student project, luckily there is
  flexibility here since we get inquiries for anything from 6 week
  projects to 6 month projects.

If you have ideas on what projects would be useful, please add them
to this page (or email me):

http://kernelnewbies.org/KernelProjects


I'm also quite interested in what compsci students can do for the  
kernel project. I'm currently doing a little embedded development and  
research at school, but I and a few others would jump at the chance  
to work on the kernel (besides finding duplicate problems that the  
x86 merge is already taking care of, of course. ;)


Also (as an aside), we're looking at redoing our operating systems  
curriculum out here at school...anyone aware of (relatively good) OS  
curricula? (time scope: one semester.)


regards/thanks,
--
Doug Whitesell
CSU Channel Islands - Computer Science
"Unprecedented performance: nothing we had has ever worked like this  
before..."

-
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/

Re: PROBLEM: kernel panic

[Doug Whitesell (LKML)]

On Oct 14, 2007, at 1:44 PM, Scott Petler wrote:


Trond,

I'm not exactly sure how to go back to not using the nvidia driver  
and select the xorg one.  I do know that I wasn't able to use both  
monitors with the xorg driver, but I'm willing to try that to  
isolate the problem.


If memory serves, you change your xorg.conf's "Device" section's  
"Driver" entry to read:

"nv"
instead of
"nvidia",

although I would consult the xorg documentation/your distribution's  
documentation (and back up your working xorg.conf) for specific  
details. (Your boot sequence may also automatically load the nvidia  
module, again, consult your distribution's documentation for details.)


Cheers/hope this helps,
dcw
-
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/

[PATCH] Include asm/vsyscall.h in arch/x86/kernel/alternative.c.

[Doug Whitesell (LKML)]

The VSYSCALL_START and VSYSCALL_END symbols are referenced in
apply_alternatives(), but vsyscall.h is not always included when
building on x86-64 with random configurations. Including asm/vsyscall.h
guarantees availability of the symbols, and is otherwise harmless.

Signed-off-by: Doug Whitesell <[EMAIL PROTECTED]>
---
arch/x86/kernel/alternative.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/ 
alternative.c

index bd72d94..cdb3e25 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -10,7 +10,7 @@
#include 
#include 
#include 
-
+#include 
#define MAX_PATCH_LEN (255-1)
#ifdef CONFIG_HOTPLUG_CPU
--
1.5.2.5

-
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/

Re: PCI Quirk / Hidden Bus Report

[pat-lkml]

Thanks for the bump.  Any additional information needed?

Pat Erley

Adrian Bunk wrote:

Bernhard?

cu
Adrian


On Wed, Jul 18, 2007 at 11:33:55PM -0400, pat-lkml wrote:

I received:

PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try
'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently

in my dmesg in 2.6.22, and am reporting it.  Context of message follows.
 Full dmesg output available on request.  This is a Clevo d900t laptop
motherboard, and everything works perfectly on it.

Pat Erley

--

ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Brought up 2 CPUs
migration_cost=22
NET: Registered protocol family 16
EISA bus registered
ACPI: bus type pci registered
PCI: BIOS Bug: MCFG area at e000 is not E820-reserved
PCI: Not using MMCONFIG.
PCI: PCI BIOS revision 2.10 entry at 0xfd951, last bus=10
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 1180-11bf claimed by ICH6 GPIO
PCI: Transparent bridge - :00:1e.0
PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try
'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEG_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 10) *11
ACPI: PCI Interrupt Link [LNKB] (IRQs 11) *10
ACPI: PCI Interrupt Link [LNKC] (IRQs 10) *5
ACPI: PCI Interrupt Link [LNKD] (IRQs 11) *10
ACPI: PCI Interrupt Link [LNKE] (IRQs *10)
ACPI: PCI Interrupt Link [LNKF] (IRQs *11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 10) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs *11)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
SCSI subsystem initialized
libata version 2.21 loaded.
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a
report
Time: tsc clocksource has been installed.

-
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/


-
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/

PCI Quirk / Hidden Bus Report

[pat-lkml]

I received:

PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try
'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently

in my dmesg in 2.6.22, and am reporting it.  Context of message follows.
 Full dmesg output available on request.  This is a Clevo d900t laptop
motherboard, and everything works perfectly on it.

Pat Erley

--

ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Brought up 2 CPUs
migration_cost=22
NET: Registered protocol family 16
EISA bus registered
ACPI: bus type pci registered
PCI: BIOS Bug: MCFG area at e000 is not E820-reserved
PCI: Not using MMCONFIG.
PCI: PCI BIOS revision 2.10 entry at 0xfd951, last bus=10
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 1180-11bf claimed by ICH6 GPIO
PCI: Transparent bridge - :00:1e.0
PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try
'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEG_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 10) *11
ACPI: PCI Interrupt Link [LNKB] (IRQs 11) *10
ACPI: PCI Interrupt Link [LNKC] (IRQs 10) *5
ACPI: PCI Interrupt Link [LNKD] (IRQs 11) *10
ACPI: PCI Interrupt Link [LNKE] (IRQs *10)
ACPI: PCI Interrupt Link [LNKF] (IRQs *11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 10) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs *11)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
SCSI subsystem initialized
libata version 2.21 loaded.
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a
report
Time: tsc clocksource has been installed.
-
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/

Re: radeon breaks with clocksource_jiffies

[john stultz-lkml]

On 2/23/07, David Miller <[EMAIL PROTECTED]> wrote:

> While probeing PLL information via radeon_get_pllinfo(), it does a
> "gettimeofday(); do_something(); gettimeofday();" type sequence
> explicitly with interrupts disabled, so ends up with a zero
> measurement which then results in a bunch of divisions by zero.
>
> We should decide whether gettimeofday() can be expected to advance with
> interrupts disabled, or that clocksource_jiffies is simply invalid because
> of this behavior.

Actually, with clocksource based gettimeofday(), radeon built-in cannot
work at all.

The reason is that the clocksource code will not jump over to a
clock source other than clocksource_jiffies until the late initcalls
are run, because of this code:


Check out the patch I sent out yesterday. It should resolve this problem.

thanks
-john
-
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/

Re: Still cant boot 2.6.20

[lkml]

On Sat, Feb 10, 2007 at 11:12:34PM -0800, Randy Dunlap wrote:
> On Sun, 11 Feb 2007 01:02:47 -0600 [EMAIL PROTECTED] wrote:
> 
> > I don't see CONFIG_BLK_DEV_INITRD=y
> > 
> > Regards,
> > Vito Caputo
> > 
> > BTW, this isnt the appropriate place for asking this type of question...
> 
> Please explain why not.
> 
> And please delete large parts of email that are not needed in replies
> (like the .config).
> Thanks.
> 

I was under the impression that lkml is for kernel development, not basic help
with configuring your kernel.

>From the FAQ at http://www.tux.org/lkml/#s3-8

 "Remember that this is a list for the discussion of kernel development."

Regards,
Vito Caputo
-
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/

Re: OT: snow tux

[lkml]

I have to ask why the yellow snow appears to have run, bad aim?


On Mon, Jan 22, 2007 at 02:21:54PM -0600, David Nicol wrote:
> http://www.cymor.com/gallery/SnowPenguin/aah
> -
> 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/
-
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/

[RFC 2.6.19 1/1] fbdev,mm: hecuba/E-Ink fbdev driver v2

[jayakumar . lkml]

  ret = -ENOMEM;
+
+   if (ret) {
+   platform_device_put(hecubafb_device);
+   platform_driver_unregister(&hecubafb_driver);
+   }
+   }
+   return ret;
+
+}
+
+static void __exit hecubafb_exit(void)
+{
+   platform_device_unregister(hecubafb_device);
+   platform_driver_unregister(&hecubafb_driver);
+}
+
+module_param(nosplash, uint, 0);
+MODULE_PARM_DESC(nosplash, "Disable doing the splash screen");
+module_param(hecubafb_enable, uint, 0);
+MODULE_PARM_DESC(hecubafb_enable, "Enable communication with Hecuba board");
+module_param(dio_addr, ulong, 0);
+MODULE_PARM_DESC(dio_addr, "IO address for data, eg: 0x480");
+module_param(cio_addr, ulong, 0);
+MODULE_PARM_DESC(cio_addr, "IO address for control, eg: 0x400");
+module_param(c2io_addr, ulong, 0);
+MODULE_PARM_DESC(c2io_addr, "IO address for secondary control, eg: 0x408");
+module_param(splashval, ulong, 0);
+MODULE_PARM_DESC(splashval, "Splash pattern: 0x00 is black, 0x01 is white");
+module_param(irq, uint, 0);
+MODULE_PARM_DESC(irq, "IRQ for the Hecuba board");
+
+module_init(hecubafb_init);
+module_exit(hecubafb_exit);
+
+MODULE_DESCRIPTION("fbdev driver for Hecuba board");
+MODULE_AUTHOR("Jaya Kumar");
+MODULE_LICENSE("GPL");
diff -X linux-2.6.19/Documentation/dontdiff -uprN 
linux-2.6.19-vanilla/drivers/video/Kconfig linux-2.6.19/drivers/video/Kconfig
--- linux-2.6.19-vanilla/drivers/video/Kconfig  2006-12-10 13:37:44.0 
+0800
+++ linux-2.6.19/drivers/video/Kconfig  2006-12-11 18:38:40.0 +0800
@@ -566,6 +566,19 @@ config FB_IMAC
help
  This is the frame buffer device driver for the Intel-based Macintosh
 
+config FB_HECUBA
+   tristate "Hecuba board support"
+   depends on FB && X86 && MMU
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   help
+ This enables support for the Hecuba board. This driver was tested 
+ with an E-Ink 800x600 display and x86 SBCs through a 16 bit GPIO
+ interface (8 bit data, 4 bit control). If you anticpate using
+ this driver, say Y or M; otherwise say N. You must specify the
+ GPIO IO address to be used for setting control and data.
+
 config FB_HGA
tristate "Hercules mono graphics support"
depends on FB && X86
diff -X linux-2.6.19/Documentation/dontdiff -uprN 
linux-2.6.19-vanilla/drivers/video/Makefile linux-2.6.19/drivers/video/Makefile
--- linux-2.6.19-vanilla/drivers/video/Makefile 2006-12-10 13:37:44.0 
+0800
+++ linux-2.6.19/drivers/video/Makefile 2006-12-10 13:45:47.0 +0800
@@ -67,6 +67,7 @@ obj-$(CONFIG_FB_SGIVW)+= sgi
 obj-$(CONFIG_FB_ACORN)+= acornfb.o
 obj-$(CONFIG_FB_ATARI)+= atafb.o
 obj-$(CONFIG_FB_MAC)  += macfb.o
+obj-$(CONFIG_FB_HECUBA)   += hecubafb.o
 obj-$(CONFIG_FB_HGA)  += hgafb.o
 obj-$(CONFIG_FB_IGA)  += igafb.o
 obj-$(CONFIG_FB_APOLLO)   += dnfb.o
diff -X linux-2.6.19/Documentation/dontdiff -uprN 
linux-2.6.19-vanilla/mm/filemap.c linux-2.6.19/mm/filemap.c
--- linux-2.6.19-vanilla/mm/filemap.c   2006-12-10 13:37:41.0 +0800
+++ linux-2.6.19/mm/filemap.c   2006-12-11 17:45:33.0 +0800
@@ -583,6 +583,7 @@ void fastcall __lock_page_nosync(struct 
__wait_on_bit_lock(page_waitqueue(page), &wait, __sleep_on_page_lock,
TASK_UNINTERRUPTIBLE);
 }
+EXPORT_SYMBOL_GPL(__lock_page_nosync);
 
 /**
  * find_get_page - find and get a page reference
diff -X linux-2.6.19/Documentation/dontdiff -uprN 
linux-2.6.19-vanilla/mm/rmap.c linux-2.6.19/mm/rmap.c
--- linux-2.6.19-vanilla/mm/rmap.c  2006-12-10 13:37:41.0 +0800
+++ linux-2.6.19/mm/rmap.c  2006-12-11 17:45:22.0 +0800
@@ -492,6 +492,7 @@ int page_mkclean(struct page *page)
 
return ret;
 }
+EXPORT_SYMBOL_GPL(page_mkclean);
 
 /**
  * page_set_anon_rmap - setup new anonymous rmap
-
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/

Forgotten patch to fs/locks.c

[lkml]

Am I mistaken or did this patch never make it into the kernel?

http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0902.html

I had to apply that patch a short while ago to 2.6.12.4 to fix kernel
crashes with some web servers at my previous place of employment.

Just now getting around to following up on why it seemed to be left
behind.

Regards,
Vito Caputo
-
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/

[PATCH] Make ide-cs work for hardware with 8-bit CF-Interface

[Thomas Kleffel (LKML)]

Hello,

it is technically possible to access a CF-Card with an 8-bit width bus.

The problem with the current code is that the IDE code does a 16 (or 32) 
bit read on the IDE data register. If the bus interface for a 8-bit bus 
would then do two reads to offsets 0 and 1.


The second read (to offset 1) then reads the error register instead of 
the data register's odd byte.


To fix this problem I've changed the ide-cs code to use the duplicated 
data registers at offset 8 and 9 which are not overlapped with anything.


According to the specs, those registers should be there in every CF 
card. I've tested this with a couple of CFs, including SanDisk, 
Microdrive and several NoNames.


The specific architechture I'm using this on is a AT91RM9200 with kernel 
2.6.13 and the patches from http://maxim.org.za/AT91RM9200/2.6/.


For more information on the overlapped / non-overlapped registers see 
http://www.compactflash.org/cfspc3_0.pdf - page 96


The following patch is against vanilla 2.6.13.

ldiff -uprN a/drivers/ide/legacy/ide-cs.c b/drivers/ide/legacy/ide-cs.c
--- a/drivers/ide/legacy/ide-cs.c   2005-08-08 15:30:35.0 +0200
+++ b/drivers/ide/legacy/ide-cs.c   2005-09-05 02:09:47.0 +0200
@@ -186,7 +186,8 @@ static int idecs_register(unsigned long
 {
 hw_regs_t hw;
 memset(&hw, 0, sizeof(hw));
-ide_init_hwif_ports(&hw, io, ctl, NULL);
+ide_std_init_ports(&hw, io, ctl);
+hw.io_ports[IDE_DATA_OFFSET] = io + 0x08;
 hw.irq = irq;
 hw.chipset = ide_pci;
 return ide_register_hw_with_fixup(&hw, NULL, ide_undecoded_slave);


Signed-off-by: Thomas Kleffel <[EMAIL PROTECTED]>


Best regards,

Thomas
-
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/

PROBLEM: Buffer I/O error on device hdg1, system freeze.

[lkml]

One line summary of the problem:
Buffer I/O error on device hdg1, system freeze.


Full description of the problem/report:
 the following error showed up in dmesg today:

 hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
 hdg: dma_intr: error=0x40 { UncorrectableError }, LBAsect=262311, high=0, 
low=262311, sector=262311
 ide: failed opcode was: unknown
 end_request: I/O error, dev hdg, sector 262311
 Buffer I/O error on device hdg1, logical block 131124

  fscking this disk freezes the entire system.

 The disk was remounted ro afterwards.
 Disk itself is ok. Is a new one.

 Remark: average temperature of the system raised during the last 5 day
 from 21 deg C to 23 deg C as spring is approaching.

 Last summer there have been a lot of problems with the pdc at even
 higher temperatures using kernel 2.4.26 to 2.4.xx. 


Keywords (i.e., modules, networking, kernel):
PDC20269: IDE controller, CONFIG_BLK_DEV_PDC202XX_OLD=y, 
CONFIG_BLK_DEV_PDC202XX_NEW=y



/proc/version:
--

Linux version 2.6.11serviceservice ([EMAIL PROTECTED]) (gcc version 2.95.4 
20011002 (Debian prerelease)) #1 Sat Mar 5 16:31:18 CET 2005


Output of Oops.. message:
see above.


A small shell script or example program which triggers the problem:


/usr/src/linux/scripts/ver_linux:
-

If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux service 2.6.11serviceservice #1 Sat Mar 5 16:31:18 CET 2005 i686 GNU/Linux
 
Gnu C  2.95.4
Gnu make   3.79.1
binutils   2.12.90.0.1
util-linux 2.11n
mount  2.12a
module-init-tools  3.1
e2fsprogs  1.35
reiserfsprogs  reiserfsck:
reiser4progs   fsck.reiser4:
quota-tools3.04.
PPP2.4.1
isdn4k-utils   3.5
Linux C Library2.3.2
Dynamic linker (ldd)   2.3.2
Procps 3.2.4
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.2.1
Modules Loaded usbcore 8250 serial_core parport_pc lp parport bridge 
dm_mod hisax_isac hisax isdn 8139too 3c59x mii


/proc/cpuinfo:
--

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 7
model name  : Pentium III (Katmai)
stepping: 3
cpu MHz : 551.398
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat 
pse36 mmx fxsr sse
bogomips: 1089.53



/proc/modules:
--

usbcore 114504 0 - Live 0xd098f000
8250 23200 2 - Live 0xd0933000
serial_core 21664 1 8250, Live 0xd092c000
parport_pc 39072 1 - Live 0xd08cd000
lp 12032 0 - Live 0xd0899000
parport 35776 2 parport_pc,lp, Live 0xd08fc000
bridge 50900 0 - Live 0xd091e000
dm_mod 57728 0 - Live 0xd090e000
hisax_isac 12372 0 - Live 0xd08c8000
hisax 198272 1 hisax_isac, Live 0xd093a000
isdn 135872 1 hisax, Live 0xd08d9000
8139too 25376 0 - Live 0xd08a8000
3c59x 40392 0 - Live 0xd089d000
mii 4992 2 8139too,3c59x, Live 0xd088c000


/proc/ioports:
--

-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0290-0297 : pnp 00:0f
02f8-02ff : serial
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0778-077a : parport0
0cf8-0cff : PCI conf1
9400-9403 : :00:0e.0
9800-987f : :00:0e.0
a000-a0ff : :00:0b.0
  a000-a0ff : 8139too
a400-a40f : :00:0a.0
  a400-a407 : ide2
  a408-a40f : ide3
a800-a803 : :00:0a.0
  a802-a802 : ide3
b000-b007 : :00:0a.0
  b000-b007 : ide3
b400-b403 : :00:0a.0
b800-b807 : :00:0a.0
d000-d0ff : :00:09.0
  d000-d0ff : 8139too
d400-d41f : :00:04.2
d800-d80f : :00:04.1
  d800-d807 : ide0
  d808-d80f : ide1
e400-e43f : :00:04.3
  e400-e43f : motherboard
e400-e403 : PM1a_EVT_BLK
e404-e405 : PM1a_CNT_BLK
e408-e40b : PM_TMR
e40c-e40f : GPE0_BLK
e800-e81f : :00:04.3
  e800-e80f : motherboard


/proc/iomem:


-0009e7ff : System RAM
0009e800-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000cc000-000ce7ff : Adapter ROM
000f-000f : System ROM
0010-0fffbfff : System RAM
  0010-0035ecd9 : Kernel code
  0035ecda-004df71f : Kernel data
0fffc000-0fffefff : ACPI Tables
0000-0fff : ACPI Non-volatile Storage
e280-e280007f : :00:0e.0
e300-e3ff : :00:0c.0
e400-e4ff : :00:0b.0
  e400-e4ff : 8139too
e480-e4803fff : :00:0a.0
e500-e5ff : :00:09.0
  e500-e5ff : 813

PROBLEM: CompactFlash mount Oops

[lkml]

  Hi, 


One line summary of the problem:CompactFlash mount results in Oops

Full description of the problem/report:
When mounting a CF card, the error occurs resulting in pretty unusable system.

Keywords (i.e., modules, networking, kernel):
ide_cs.ko
compact flash card
mount
Oops


/proc/version:
--

Linux version 2.6.11tf ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 
1:3.3.5-5)) #1 Sat Mar 5 16:46:41 CET 2005


Output of Oops.. message: via dmesg

Probing IDE interface ide2...
hde: TOSHIBA THNCF512MMA, CFA DISK drive
ide2 at 0x100-0x107,0x10e on irq 3
hde: max request size: 128KiB
hde: 1000944 sectors (512 MB) w/2KiB Cache, CHS=993/16/63
hde: cache flushes not supported
 /dev/ide/host2/bus0/target0/lun0: p1
ide-cs: hde: Vcc = 3.3, Vpp = 0.0
 /dev/ide/host2/bus0/target0/lun0: p1
smbfs: Unrecognized mount option noexec
cs: pcmcia_socket0: voltage interrogation timed out.
Probing IDE interface ide2...
hde: TOSHIBA THNCF512MMA, CFA DISK drive
hdf: no response (status = 0xff), resetting drive
hdf: no response (status = 0xff)
ide2 at 0x100-0x107,0x10e on irq 3
hde: max request size: 128KiB
hde: 1000944 sectors (512 MB) w/2KiB Cache, CHS=993/16/63
hde: cache flushes not supported
 /dev/ide/host2/bus0/target0/lun0:hde: status timeout: status=0xff { Busy }

ide: failed opcode was: unknown
hde: drive not ready for command
ide2: reset timed-out, status=0xff
hde: status timeout: status=0xff { Busy }

ide: failed opcode was: unknown
hde: drive not ready for command
ide2: reset timed-out, status=0xff
end_request: I/O error, dev hde, sector 0
Buffer I/O error on device hde, logical block 0
end_request: I/O error, dev hde, sector 0
Buffer I/O error on device hde, logical block 0
ldm_validate_partition_table(): Disk read failed.
end_request: I/O error, dev hde, sector 0
Buffer I/O error on device hde, logical block 0
 unable to read partition table
ide-cs: hde: Vcc = 3.3, Vpp = 0.0
[ cut here ]
kernel BUG at drivers/ide/legacy/ide-cs.c:477!
invalid operand:  [#1]
PREEMPT 
Modules linked in: ide_cs orinoco_pci orinoco hermes snd_seq_oss 
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss 
snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd ipv6 pcmcia 
yenta_socket rsrc_nonstatic pcmcia_core iptable_mangle ipt_LOG ipt_esp 
ipt_state ip_conntrack iptable_filter ip_tables eepro100 ehci_hcd radeon drm 
agpgart uhci_hcd usbcore
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010282   (2.6.11tf) 
EIP is at exit_ide_cs+0x1a/0x24 [ide_cs]
eax: c626f580   ebx: f099da80   ecx: f0a212cc   edx: c031f8e0
esi: 0080   edi:    ebp: dca24000   esp: dca25f5c
ds: 007b   es: 007b   ss: 0068
Process modprobe (pid: 11749, threadinfo=dca24000 task=ef3aaa20)
Stack: f099d9ec c0138c25 f099da80 0080 dca25f70  5f656469 b7007363 
   c0155e6d ddc90580 cf001c24 ea0fe284 b7fe8000 b7fe9000 ea0fe284 ddc90580 
   ddc905ac  dca24000 c0155ef4 00c90580 b7fe8000 08057a50  
Call Trace:
 [] sys_delete_module+0x175/0x1b0
 [] do_munmap+0x13d/0x180
 [] sys_munmap+0x44/0x70
 [] syscall_call+0x7/0xb
Code: 24 e8 1b 22 07 00 e9 66 ff ff ff 90 90 00 00 00 00 83 ec 04 c7 04 24 e0 
d9 99 f0 e8 f1 e6 07 00 a1 80 dc 99 f0 85 c0 75 02 59 c3 <0f> 0b dd 01 d6 ca 99 
f0 eb f4 03 16 21 22 38 39 68 64 25 63 00 
 <4>2.6. kernels use pcmciamtd instead of memory_cs.c and do not require special
MTD handling any more.


A small shell script or example program which triggers the problem:
mount /dev/hde1 /mnt/mem


/usr/src/linux/scripts/ver_linux:
-

If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux tadpole 2.6.11tf #1 Sat Mar 5 16:46:41 CET 2005 i686 GNU/Linux
 
Gnu C  3.3.5
Gnu make   3.80
binutils   2.15
util-linux 2.12
mount  2.12
module-init-tools  3.1
e2fsprogs  1.28
reiserfsprogs  line
reiser4progs   line
pcmcia-cs  3.2.5
quota-tools3.07.
PPP2.4.1
Linux C Library2.3.2
Dynamic linker (ldd)   2.3.2
Procps 3.2.4
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.2.1
Modules Loaded snd_pcm_oss ipv6 pcmcia yenta_socket rsrc_nonstatic 
pcmcia_core snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd 
snd_page_alloc iptable_mangle ipt_LOG ipt_esp ipt_state ip_conntrack 
iptable_filter ip_tables eepro100 ehci_hcd radeon drm agpgart uhci_hcd usbcore


/proc/cpuinfo:
--

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 2
model name  : Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz
stepping: 4
cpu MHz : 1599.172
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_excepti

Unable to re-enable DMA after DMA timeout (why?)

[James Turinsky (LKML)]

Here is what happens after several days running with either the kernel
activating DMA or activating it manually (hdparm -d1 /dev/hda) in at
least
2.4.2 through 2.4.5-ac5:

hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x80 { Busy }
hda: DMA disabled
ide0: reset: success

Issuing hdparm -d1 /dev/hda at this point causes a short period of
system unresponsiveness which ends with the following:

hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x50 { DriveReady SeekComplete }
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x50 { DriveReady SeekComplete }
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x50 { DriveReady SeekComplete }
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x50 { DriveReady SeekComplete }
hda: DMA disabled
ide0: reset: success

Here is the drive info:

hdparm -iI /dev/hda

/dev/hda:

 Model=IBM-DTTA-371010, FwRev=T77OA73A, SerialNo=WL0WLF36394
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34
 BuffType=DualPortCache, BuffSize=465kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=19746720
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
 AdvancedPM=no
 Drive Supports : ATA/ATAPI-4 T13 1153D revision 17 : ATA-1 ATA-2 ATA-3
ATA-4


 Model=BI-MTDAT3-1710 0, FwRev=7TO77AA3,
SerialNo=
  W 0LLW3F3649
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34
 BuffType=DualPortCache, BuffSize=465kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=19746720
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 *mdma2 udma0 udma1 udma2
 AdvancedPM=no
 Drive Supports : ATA/ATAPI-4 T13 1153D revision 17 : ATA-1 ATA-2 ATA-3
ATA-4

Here is the controller info:

00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20262
(rev 01)
Subsystem: Promise Technology, Inc.: Unknown device 4d33
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR-  [disabled] [size=64K]
Capabilities: [58] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

I also see this on the onboard controller

00:00.0 Host bridge: Intel Corporation 430VX - 82437VX TVX [Triton VX]
(rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PANIC] [UPDATED] USB Zip 250 hangs 2.4.3, panics 2.4.3-ac2,-ac9

[James Turinsky (LKML)]

- Original Message -
From: "James Turinsky (LKML)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, April 20, 2001 4:34 PM
Subject: USB Zip 250 hangs 2.4.3, panics 2.4.3-ac2,-ac9


> [not subbed to [EMAIL PROTECTED], please mail me
> directly]
>
> Hi all,
>
> I'm having MAJOR problems with using a USB Zip 250 with Linux 2.4.3.
>
> First thing I saw, is under 2.4.3-ac9, I have hotplug support and
> /sbin/hotplug installed, and I plugged it in and it found the drive
> (yay!).  Then I mounted the disk in the drive ( -t vfat -o sync IIRC)
> and tried to copy a chunk of an ISO image sized just under the max of
> the zip disk. BLAMMO! Oops, process: swapper, Kernel panic: Aiee,
> killing interrupt handler! In interrupt handler - not syncing
> (I have the output -- but in pen and ink form and I'm not fit to type
it
> and run it through ksymoops yet.)  This was repeatable at least three
> times.

Here is that ksymoops output, if it's weird, it's because the oops I
fed it was typed manually

ksymoops 2.4.1 on i586 2.4.3-ac9.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.3-ac9/ (default)
 -m /boot/System.map-2.4.3-ac9 (specified)

c01c5f1c
Oops: 
CPU: 0
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010006
eax: c0253f34 ebx: c1237de8 ecx: 0002 edx: 
esi: c64807e0 edi: c1237d60 ebp: c1237de8 esp: c0253f1c
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c0253000)
stack: c12a0340 c01c5ebc  c0253fa4 0282 c12a0340 c0253f34
c0253f34
c011a8a2 c12a0340  c028c5a0  c0253fa4 c010b8af c0253f8c
c023a3b4 c011787f  c01177b7  0001 c028c5c0 000e
call trace: [] [] [] []
[]
[] []
[] [] [] [] []
[] []
Code: f6 42 24 01 74 1e a1 48 54 2a c0 83 c0 fb 2b 42 2c 78 11 56

>>EIP; c01c5f1c<=
Trace; c01c5ebc 
Trace; c011a8a2 
Trace; c010b8af 
Trace; c011787f 
Trace; c01177b7 
Trace; c01176c0 
Trace; c0107e72 
Trace; c0105120 
Trace; c0106b10 
Trace; c0105120 
Trace; c0105143 
Trace; c01051a7 
Trace; c0105000 
Trace; c0100191 
Code;  c01c5f1c 
 <_EIP>:
Code;  c01c5f1c<=
   0:   f6 42 24 01   testb  $0x1,0x24(%edx)   <=
Code;  c01c5f20 
   4:   74 1e je 24 <_EIP+0x24> c01c5f40

Code;  c01c5f22 
   6:   a1 48 54 2a c0mov0xc02a5448,%eax
Code;  c01c5f27 
   b:   83 c0 fb  add$0xfffb,%eax
Code;  c01c5f2a 
   e:   2b 42 2c  sub0x2c(%edx),%eax
Code;  c01c5f2d 
  11:   78 11 js 24 <_EIP+0x24> c01c5f40

Code;  c01c5f2f 
  13:   56push   %esi

<0>Kernel panic: Aiee, killing interrupt handler!



> Then I booted 2.4.3-ac2 and repeated the behaviour.
>
> [note: -ac2 changelog contains "o Fix shm locking, races on swapping,
> accounting and swapout of already mapped pages (Stephen Tweedie)",
maybe
> that touched something which changed the behaviour between 2.4.3
and -ac
> series?]
>
> I booted 2.4.3 stock and tried the same thing.  Running ls -la on the
> zip mountpoint showed that it did indeed copy part of the file but
> stopped.  cp was in D state and I could not shutdown/halt the system
nor
> umount/eject the disk (and dammit, yanking the power/USB cable just
> dawned on me).  This behaviour was repeatable and the point at which
the
> file ended varied.
>
> I did manage to get a 13MB file copied to a Zip disk by mounting
without
> the '-o sync' and then issuing sync manually after the copy (which
then
> wrote it to disk).
>
> I will type in the Oops output and run it through ksymoops as soon as
> possible.
>
> I won't get access to the machine until Monday but if anyone has
> suggestions on things to try or instructions on how to help debug
this,
> please let me know
>
> Below is the of course standard info/debugging aid. If you want
anything
> else please tell me.
>
> --JT
> Sair LCA, LPIC-1 [I am a certification whore]
>
> Linux version 2.4.3-ac9 (foo) (gcc version 2.95.3 19991030
(prerelease))
> #1 Wed Apr 18 10:53:33 GMT 2001
> BIOS-provided physical RAM map:
>  BIOS-e820:  - 0009e800 (usable)
>  BIOS-e820: 0009fc00 - 000a (reserved)
>  BIOS-e820: 000f820a - 0010 (reserved)
>  BIOS-e820: 0010 - 0800 (usable)
>  BIOS-e820: 820a - 0001 (reserved)
> On node 0 totalpages: 32768
> zone(0): 4096 pages.
> zone(1): 28672 pages.
> zone(2): 0 pages.
> No local APIC present or hardware disabled
> Kernel command line: BOOT_IMAGE=linux ro ide=reverse
> ide_setup: id

USB Zip 250 hangs 2.4.3, panics 2.4.3-ac2,-ac9

[James Turinsky (LKML)]

ot; 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/

IDE DMA Problem? (or at least behavior change) 2.2/2.4

[James Turinsky (LKML)]

a2 mdma0 mdma1 mdma2 udma0 udma1 *udma2

 Model=BI-MTDAT3-1710 0, FwRev=7TO77AA3,
SerialNo=W 0LLW3F3649
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34
 BuffType=DualPortCache, BuffSize=465kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=19746720
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 *mdma2 udma0 udma1 udma2

lspci -vv:

00:00.0 Host bridge: Intel Corporation 430VX - 82437VX TVX [Triton VX]
(rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR-  [disabled] [size=64K]

00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20262
(rev 01)
Subsystem: Promise Technology, Inc.: Unknown device 4d33
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR-  [disabled] [size=64K]
Capabilities: [58] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:13.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR-  [disabled] [size=128K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

/proc/ide/pdc202xx:

PDC20262 Chipset.
--- General
Status -
Burst Mode   : enabled
Host Mode: Normal
Bus Clocking : 33 PCI Internal
IO pad select: 4 mA
Status Polling Period: 6
Interrupt Check Status Polling Delay : 12
--- Primary Channel  Secondary
Channel -
enabled  enabled
66 Clocking disabled disabled
   Mode PCI Mode PCI
FIFO Empty   FIFO Empty
--- drive0 - drive1  drive0 --
drive1 --
DMA enabled:no   yes yes   no
DMA Mode:   UDMA 4   NOTSET  NOTSET
NOTSET
PIO Mode:   PIO 4NOTSET   NOTSET
NOTSET

/proc/ide/piix:
Intel PIIX3 Chipset.
--- Primary Channel  Secondary
Channel -
 enabled  enabled
--- drive0 - drive1  drive0 --
drive1 --
DMA enabled:no   no  nono
UDMA enabled:   no   no  nono
UDMA enabled:   XX   X X
UDMA
DMA
PIO

-
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/

Re: compiling kernel and modules issues

[lkml recipient]

On Tue, 3 Oct 2000, Tom Cheung wrote:

> Would anyone tell me how can I update the kernel and modules
> simultaneously without losing previous installed modules.Thanks a lot !!

Hi. Let me first say that although I'm subscribed to lkml, I'm really only
an aspiring kernel hacker, not in any way a guru at this point in
time. However, I have found a solution to your last question that Works
For Me(tm).

The kernel modules are stored in /lib/modules//. The
version number that the kernel will report (to 'uname -r', for example) is
set in the top-level makefile, in three variables. What I do is I just
append a string, usually -b#, which indicates which build this is from the
source tree. For example, the first time I compiled a kernel from my
2.4.0-test9-pre7 tree, I appended '-b0' to the $EXTRAVERSION variable in
the makefile, and the modules I compiled for that kernel were placed in
/lib/modules/2.4.0-test9-pre7/. When that didn't work for me quite right,
I edited the makefile again, changing '-b0' to '-b1', changed my
configuration a little, and re-compiled. This time, make modules_install
put the new modules in /lib/modules/2.4.0-test9-pre7-b1/. When I booted
with the new kernel, it looked there for its modules.

As I said, I'm really no guru, and as a result there may be some reason
why this solution won't work for other people, and I just don't know about
that reason yet. I do hope it helps you, though. The issue of overwriting
all my modules when I re-compiled a kernel used to be a real annoyance to
me, too, when I had one that pretty much worked but I just wanted to try
another configuration.

-Andrew C. Dingman
[EMAIL PROTECTED]


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/