Raghavendra K T writes:
> On 02/18/2014 03:19 PM, Jan Kara wrote:
>> On Tue 18-02-14 12:55:38, Raghavendra K T wrote:
>>> Currently max_sane_readahead() returns zero on the cpu having no local
>>> memory node
>>> which leads to readahead failure. Fix the readahead failure by returning
>>>
Raghavendra K T raghavendra...@linux.vnet.ibm.com writes:
On 02/18/2014 03:19 PM, Jan Kara wrote:
On Tue 18-02-14 12:55:38, Raghavendra K T wrote:
Currently max_sane_readahead() returns zero on the cpu having no local
memory node
which leads to readahead failure. Fix the readahead failure
Howdy all,
Meet following warning and call trace:
[307001.720980] [ cut here ]
[307001.720994] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491
add_dma_entry+0x127/0x130()
[307001.720996] DMA-API: exceeded 7 overlapping mappings of pfn 1932f8
[307001.720998] Modules linked
Howdy all,
Meet following warning and call trace:
[307001.720980] [ cut here ]
[307001.720994] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491
add_dma_entry+0x127/0x130()
[307001.720996] DMA-API: exceeded 7 overlapping mappings of pfn 1932f8
[307001.720998] Modules linked
m...@console-pimps.org writes:
> On Wed, 12 Feb, at 09:15:03AM, Toshi Kani wrote:
>>
>> Hi Matt,
>>
>> Yes, I agree that the table size should be 0x38. However, ACPI spec
>> states that bit0 of status indicates if the boot image graphic is valid.
>> This bit is set to 0 (invalid) on the
m...@console-pimps.org writes:
On Wed, 12 Feb, at 09:15:03AM, Toshi Kani wrote:
Hi Matt,
Yes, I agree that the table size should be 0x38. However, ACPI spec
states that bit0 of status indicates if the boot image graphic is valid.
This bit is set to 0 (invalid) on the system. Can you
m...@console-pimps.org writes:
> On Mon, 10 Feb, at 03:23:33PM, Madper Xie wrote:
>> Howdy,
>>
>> With old kernel (from 3.10 to 3.14-rc1), my hp box shows following
>> outputs:
>> ~~~
>> [0.009166] Freeing SMP alternatives memory: 20K (
m...@console-pimps.org writes:
On Mon, 10 Feb, at 03:23:33PM, Madper Xie wrote:
Howdy,
With old kernel (from 3.10 to 3.14-rc1), my hp box shows following
outputs:
~~~
[0.009166] Freeing SMP alternatives memory: 20K (82234000 -
82239000)
[0.010302] ioremap
Howdy,
With old kernel (from 3.10 to 3.14-rc1), my hp box shows following
outputs:
~~~
[0.009166] Freeing SMP alternatives memory: 20K (82234000 -
82239000)
[0.010302] ioremap: invalid physical address 1376e0180001
[0.010303] [ cut here ]
[
Howdy,
With old kernel (from 3.10 to 3.14-rc1), my hp box shows following
outputs:
~~~
[0.009166] Freeing SMP alternatives memory: 20K (82234000 -
82239000)
[0.010302] ioremap: invalid physical address 1376e0180001
[0.010303] [ cut here ]
[
Howdy all,
I meet following panic when I booting my HP Compad Elite 8300 Elite SFF
desktop.
[call trace here:]
[0.569993] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
[0.578269] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW3.13.0-rc8
#1
[
Howdy all,
I meet following panic when I booting my HP Compad Elite 8300 Elite SFF
desktop.
[call trace here:]
[0.569993] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
[0.578269] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW3.13.0-rc8
#1
[
Howdy Folks,
Happy new yeah, happy new bug!
With a uefi system, I meet following panic when reboot after I adding
`reboot=efi,warm`
[call trace]:
<0>[ 698.736637] reboot: Restarting system
<5>[ 698.737407] reboot: machine restart
<1>[ 698.738399] BUG: unable to handle kernel paging
Howdy Folks,
Happy new yeah, happy new bug!
With a uefi system, I meet following panic when reboot after I adding
`reboot=efi,warm`
[call trace]:
0[ 698.736637] reboot: Restarting system
5[ 698.737407] reboot: machine restart
1[ 698.738399] BUG: unable to handle kernel paging request at
m...@console-pimps.org writes:
> On Sat, 23 Nov, at 07:55:37PM, Madper Xie wrote:
>>
>> Pstore fs expects that backends provide a uniqued id which could avoid
>> pstore making entries as duplication or denominating entries the same
>> name. So I combine the timest
m...@console-pimps.org writes:
On Sat, 23 Nov, at 07:55:37PM, Madper Xie wrote:
Pstore fs expects that backends provide a uniqued id which could avoid
pstore making entries as duplication or denominating entries the same
name. So I combine the timestamp, part and count into id.
Signed
Pstore fs expects that backends provide a uniqued id which could avoid
pstore making entries as duplication or denominating entries the same
name. So I combine the timestamp, part and count into id.
Signed-off-by: Madper Xie
---
drivers/firmware/efi/efi-pstore.c | 19 +--
1
Pstore fs expects that backends provide a uniqued id which could avoid
pstore making entries as duplication or denominating entries the same
name. So I combine the timestamp, part and count into id.
Signed-off-by: Madper Xie c...@redhat.com
---
drivers/firmware/efi/efi-pstore.c | 19
rich...@nod.at writes:
> Am 01.11.2013 20:22, schrieb Seiji Aguchi:
>>>
>>> Agreed. I liked your ((timestamp * 100 + part) * 100 + count function much
>>> more than this.
>>
>> I was worried that the part and count could be more than 100.
>> If it happens, the id may not be unique...
>>
>>
rich...@nod.at writes:
Am 01.11.2013 20:22, schrieb Seiji Aguchi:
Agreed. I liked your ((timestamp * 100 + part) * 100 + count function much
more than this.
I was worried that the part and count could be more than 100.
If it happens, the id may not be unique...
But, currently, size
isimatu.yasu...@jp.fujitsu.com writes:
> Hi Matt,
>
> Sorry for late the reply.
>
>
> (2013/11/11 19:54), Matt Fleming wrote:
>> On Mon, 11 Nov, at 05:52:59PM, Yasuaki Ishimatsu wrote:
>>> Hi Matt,
>>>
>>> I uses FUJITSU's x86 box.
>>> This does not become bricked even if I use all efi variable
isimatu.yasu...@jp.fujitsu.com writes:
Hi Matt,
Sorry for late the reply.
(2013/11/11 19:54), Matt Fleming wrote:
On Mon, 11 Nov, at 05:52:59PM, Yasuaki Ishimatsu wrote:
Hi Matt,
I uses FUJITSU's x86 box.
This does not become bricked even if I use all efi variable storage.
Thus I
m...@console-pimps.org writes:
> On Mon, 11 Nov, at 08:38:31PM, Madper Xie wrote:
>>
>> m...@console-pimps.org writes:
>>
>> > On Mon, 11 Nov, at 02:15:22PM, Madper Xie wrote:
>> >> Howdy all,
>> >> For now we ensure at least ~5kb fr
m...@console-pimps.org writes:
On Mon, 11 Nov, at 08:38:31PM, Madper Xie wrote:
m...@console-pimps.org writes:
On Mon, 11 Nov, at 02:15:22PM, Madper Xie wrote:
Howdy all,
For now we ensure at least ~5kb free space. But my dell xps still
become a brick after I add too many
; I will read it.
>>
>> Out of curiosity, what hardware are you using?
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/ma
...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best,
Madper Xie.
--
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
Howdy all,
For now we ensure at least ~5kb free space. But my dell xps still
become a brick after I add too many entries to my nvram. So maybe 5kb
is not safe enough. and 5kb is just aginst Samsung's laptop.
So should we enlarge EFI_MIN_RESERVE?
--
Best,
Madper Xie.
--
To unsubscribe from
For now we only ensure about 5kb free space for avoiding our board
refusing boot. But the comment lies that we retain 50% space.
Signed-off-by: Madper Xie
---
arch/x86/platform/efi/efi.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/x86/platform/efi
For now we only ensure about 5kb free space for avoiding our board
refusing boot. But the comment lies that we retain 50% space.
Signed-off-by: Madper Xie c...@redhat.com
---
arch/x86/platform/efi/efi.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/x86
Howdy all,
For now we ensure at least ~5kb free space. But my dell xps still
become a brick after I add too many entries to my nvram. So maybe 5kb
is not safe enough. and 5kb is just aginst Samsung's laptop.
So should we enlarge EFI_MIN_RESERVE?
--
Best,
Madper Xie.
--
To unsubscribe from
ors will more careful in their next generation of products... But
it's painful for everyone, both customers and vendors.
> Thanks,
> //richard
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majord...@vger.kernel.org
>
for everyone, both customers and vendors.
Thanks,
//richard
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best,
Madper Xie.
--
To unsubscribe
a non-cryptographic
> hash function?
> Using this way you get a cheap unique id.
>
> Thanks,
> //richard
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo inf
Pstore fs expects that backends provide a uniqued id which could avoid
pstore making entries as duplication or denominating entries the same
name. So I combine the timestamp, part and count into id.
Signed-off-by: Madper Xie
---
drivers/firmware/efi/efi-pstore.c | 22 ++
1
Pstore fs expects that backends provide a uniqued id which could avoid
pstore making entries as duplication or denominating entries the same
name. So I combine the timestamp, part and count into id.
Signed-off-by: Madper Xie c...@redhat.com
---
drivers/firmware/efi/efi-pstore.c | 22
,
Madper Xie.
--
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/
20
> [1.158207] [] vfs_kern_mount+0x63/0xf0
> [1.158207] [] do_mount+0x23e/0xa20
> [1.158207] [] ? strndup_user+0x4b/0xf0
> [1.158207] [] SyS_mount+0x83/0xc0
> [1.158207] [] system_call_fastpath+0x16/0x1b
> [1.158207] ---[ end trace 61981bc62de9f6f4 ]---
>
] ---[ end trace 61981bc62de9f6f4 ]---
Signed-off-by: Seiji Aguchi seiji.agu...@hds.com
After applied this patch, I can't see the warning again when I mounting
pstore fs and deleting pstore entries.
Tested-by: Madper Xie c...@redhat.com
---
drivers/firmware/efi/efi-pstore.c | 143
iple numbers visible to the file name.
>>
>>> -r--r--r-- 1 root root 17499 Oct 30 13:41
>>> dmesg-erst-5940651313304961029--2129078373-1383165669
>
> after I added the "count = 0" initialization the filename gets a tiny bit less
> scary:
>
> -r--r--
seiji.agu...@hds.com writes:
>> -Original Message-
>> From: Madper Xie [mailto:c...@redhat.com]
>> Sent: Wednesday, October 30, 2013 5:45 AM
>> To: tony.l...@intel.com; keesc...@chromium.org; ccr...@android.com;
>> an...@enomsg.org; Seiji Aguchi
>>
1. checking type, id, psi, count and timespec when finding duplicate entries.
2. adding count and timestamp for differentiating.
Madper Xie (2):
pstore: avoid incorrectly mark entry as duplicate
pstore: Differentiating names by adding count and timestamp
fs/pstore/inode.c | 35
From: Madper Xie
pstore denominates dumped file as type-psname-id. it makes many file have
the same name if there are many entries in backend have the same id.
So adding count and timestamp to file name for differentiating.
Signed-off-by: Madper Xie
---
fs/pstore/inode.c | 29
From: Madper Xie
pstore try to find duplicate entries by check both ID, type and psi.
They are not really enough for efi backend. dumped vars always have
the same type, psi and ID. like follows:
dump-type0-9-1-1382511508-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-9-1-1382515661-C-cfc8fc79
From: Madper Xie bbbo...@gmail.com
pstore try to find duplicate entries by check both ID, type and psi.
They are not really enough for efi backend. dumped vars always have
the same type, psi and ID. like follows:
dump-type0-9-1-1382511508-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-9-1
From: Madper Xie bbbo...@gmail.com
pstore denominates dumped file as type-psname-id. it makes many file have
the same name if there are many entries in backend have the same id.
So adding count and timestamp to file name for differentiating.
Signed-off-by: Madper Xie c...@redhat.com
---
fs
1. checking type, id, psi, count and timespec when finding duplicate entries.
2. adding count and timestamp for differentiating.
Madper Xie (2):
pstore: avoid incorrectly mark entry as duplicate
pstore: Differentiating names by adding count and timestamp
fs/pstore/inode.c | 35
seiji.agu...@hds.com writes:
-Original Message-
From: Madper Xie [mailto:c...@redhat.com]
Sent: Wednesday, October 30, 2013 5:45 AM
To: tony.l...@intel.com; keesc...@chromium.org; ccr...@android.com;
an...@enomsg.org; Seiji Aguchi
Cc: linux-...@vger.kernel.org; linux-kernel
-5940651313304961029--2129078373-1383165669
after I added the count = 0 initialization the filename gets a tiny bit less
scary:
-r--r--r-- 1 root root 17499 Oct 30 13:41
dmesg-erst-5940651313304961029-0-1383165669
-Tony
--
Best,
Madper Xie.
--
To unsubscribe from this list: send the line unsubscribe
Howdy Tony,
Does this patch still need some rework?
c...@redhat.com writes:
> tony.l...@gmail.com writes:
>
>> On Wed, Oct 23, 2013 at 7:55 AM, Madper Xie wrote:
>>> The "duplicate" entries won't appear in pstorefs. And a complain will be
>>> pri
pstore denominate dumped file as type-psname-id. it makes many file have
the same name if there are many entries in backend have the same id.
So adding a timestamp to file name.
Signed-off-by: Madper Xie
---
fs/pstore/inode.c | 26 --
1 file changed, 16 insertions
pstore denominate dumped file as type-psname-id. it makes many file have
the same name if there are many entries in backend have the same id.
So adding a timestamp to file name.
Signed-off-by: Madper Xie c...@redhat.com
---
fs/pstore/inode.c | 26 --
1 file changed, 16
Howdy Tony,
Does this patch still need some rework?
c...@redhat.com writes:
tony.l...@gmail.com writes:
On Wed, Oct 23, 2013 at 7:55 AM, Madper Xie c...@redhat.com wrote:
The duplicate entries won't appear in pstorefs. And a complain will be
print -- pstore: failed to load 76 record(s
tony.l...@gmail.com writes:
> On Wed, Oct 23, 2013 at 7:55 AM, Madper Xie wrote:
>> The "duplicate" entries won't appear in pstorefs. And a complain will be
>> print -- pstore: failed to load 76 record(s) from 'efi'
>
> Maybe I don't quite get this - but it s
richard.weinber...@gmail.com writes:
> On Wed, Oct 23, 2013 at 4:55 PM, Madper Xie wrote:
>> pstore try to find duplicate entries by check both ID, type and psi.
>> They are not really enough for efi backend. dumped vars always have
>> the same type, psi and ID. like follo
-9f98bfe298a0
The "duplicate" entries won't appear in pstorefs. And a complain will be
print -- pstore: failed to load 76 record(s) from 'efi'
So I add one more check: timespec.
Signed-off-by: Madper Xie
---
fs/pstore/inode.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
test-12341234-1234-1234-1234-123412341234
> test2-12341234-1234-2134-1234-123412341234
> test3-12341234-1234-1234-1234-123412341234
> test4-12341234-1234-1234-1234-123412341234
> test5-12341234-1234-1234-1234-123412341234
> test6-12341234-1234-1234-1234-123412341234
> Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
> UsbHandOnOffEntry-0a602c5b-05a0-40c4-9181-edcd891d0018
> UsbMassDevNum-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
> UsbMassDevValid-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
> USB_POINT-8be4df61-93ca-11d2-aa0d-00e098032b8c
> UsbSupport-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
> WdtPersistentData-78ce2354-cfbc-4643-aeba-07a27fa892bf
--
Best,
Madper Xie.
--
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/
-00e098032b8c
UsbSupport-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
WdtPersistentData-78ce2354-cfbc-4643-aeba-07a27fa892bf
--
Best,
Madper Xie.
--
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
-9f98bfe298a0
The duplicate entries won't appear in pstorefs. And a complain will be
print -- pstore: failed to load 76 record(s) from 'efi'
So I add one more check: timespec.
Signed-off-by: Madper Xie c...@redhat.com
---
fs/pstore/inode.c | 5 -
1 file changed, 4 insertions(+), 1 deletion
richard.weinber...@gmail.com writes:
On Wed, Oct 23, 2013 at 4:55 PM, Madper Xie c...@redhat.com wrote:
pstore try to find duplicate entries by check both ID, type and psi.
They are not really enough for efi backend. dumped vars always have
the same type, psi and ID. like follows:
dump
tony.l...@gmail.com writes:
On Wed, Oct 23, 2013 at 7:55 AM, Madper Xie c...@redhat.com wrote:
The duplicate entries won't appear in pstorefs. And a complain will be
print -- pstore: failed to load 76 record(s) from 'efi'
Maybe I don't quite get this - but it sounds like you have a whole
181-edcd891d0018
UsbMassDevNum-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
UsbMassDevValid-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
USB_POINT-8be4df61-93ca-11d2-aa0d-00e098032b8c
UsbSupport-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
WdtPersistentData-78ce2354-cfbc-4643-aeba-07a27fa892bf
--
Best,
Madper
-edcd891d0018
UsbMassDevNum-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
UsbMassDevValid-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
USB_POINT-8be4df61-93ca-11d2-aa0d-00e098032b8c
UsbSupport-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
WdtPersistentData-78ce2354-cfbc-4643-aeba-07a27fa892bf
--
Best,
Madper Xie
Hi folks,
I tested it on my DELL XPS desktop. And it won't show any warnings
when I mounting pstore and deleting pstore items after this patch
applied.
Tested-by: Madper Xie
c...@redhat.com writes:
> Oops, It seems my mu4e(a email client for emacs)'s auto-indent breaks the
>
;> -Original Message-
>> From: Madper Xie [mailto:c...@redhat.com]
>> Sent: Thursday, October 17, 2013 1:54 AM
>> To: Seiji Aguchi
>> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
>> matt.flem...@intel.com; tony.l...@intel.com; Tomoki Sekiyama; dle-
&
efi_variable var;
struct list_head list;
struct kobject kobj;
+ bool scanning;
+ bool deleting;
};
extern struct list_head efivar_sysfs_list;
--
Best,
Madper Xie.
--
Best,
Madper Xie.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hi folks,
I tested it on my DELL XPS desktop. And it won't show any warnings
when I mounting pstore and deleting pstore items after this patch
applied.
Tested-by: Madper Xie
c...@redhat.com writes:
Oops, It seems my mu4e(a email client for emacs)'s auto-indent breaks the
patch... I
rmware/efi/vars.c b/drivers/firmware/efi/vars.c
> index 391c67b..b22659c 100644
> --- a/drivers/firmware/efi/vars.c
> +++ b/drivers/firmware/efi/vars.c
> @@ -683,8 +683,16 @@ struct efivar_entry *efivar_entry_find(efi_char16_t
> *name, efi_guid_t guid,
> if (!found)
> return NULL;
>
> - if (remove)
> - list_del(>list);
> + if (remove) {
> + if (entry->scanning) {
> + /*
> + * The entry will be deleted
> + * after scanning is completed.
> + */
> + entry->deleting = true;
> + } else
> + list_del(>list);
> + }
>
> return entry;
> }
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 5f8f176..04088fb 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -782,6 +782,8 @@ struct efivar_entry {
> struct efi_variable var;
> struct list_head list;
> struct kobject kobj;
> + bool scanning;
> + bool deleting;
> };
>
> extern struct list_head efivar_sysfs_list;
--
Best,
Madper Xie.
--
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/
;
struct list_head list;
struct kobject kobj;
+ bool scanning;
+ bool deleting;
};
extern struct list_head efivar_sysfs_list;
--
Best,
Madper Xie.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
[ 15.906392] r8169 :02:00.0 p3p1: link up
> [ 15.906416] IPv6: ADDRCONF(NETDEV_CHANGE): p3p1: link becomes ready
> [ 17.121989] systemd-udevd (334) used greatest stack depth: 3352 bytes left
>
> I'm working on finding which version bring this bug in.
--
Best,
Madper Xie.
--
becomes ready
[ 17.121989] systemd-udevd (334) used greatest stack depth: 3352 bytes left
I'm working on finding which version bring this bug in.
--
Best,
Madper Xie.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
: ADDRCONF(NETDEV_CHANGE): p3p1: link becomes ready
[ 17.121989] systemd-udevd (334) used greatest stack depth: 3352 bytes left
I'm working on finding which version bring this bug in.
--
Best,
Madper Xie.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
] IPv6: ADDRCONF(NETDEV_CHANGE): p3p1: link becomes ready
[ 17.121989] systemd-udevd (334) used greatest stack depth: 3352 bytes left
I'm working on finding which version bring this bug in.
--
Best,
Madper Xie.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
72 matches
Mail list logo
