* unsubscribe
@ 2009-01-06 17:59 hb fei
2009-01-07 1:55 ` unsubscribe Tao Xue
0 siblings, 1 reply; 127+ messages in thread
From: hb fei @ 2009-01-06 17:59 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: Type: text/html, Size: 5 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
2009-01-06 17:59 unsubscribe hb fei
@ 2009-01-07 1:55 ` Tao Xue
2009-01-07 6:32 ` unsubscribe AKS
0 siblings, 1 reply; 127+ messages in thread
From: Tao Xue @ 2009-01-07 1:55 UTC (permalink / raw)
To: Linuxppc-dev
Please unsubscribe me,
thanks
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
2009-01-07 1:55 ` unsubscribe Tao Xue
@ 2009-01-07 6:32 ` AKS
2009-01-07 6:38 ` unsubscribe zhou.yutao
2009-01-07 7:42 ` unsubscribe Decherf, Patrick
0 siblings, 2 replies; 127+ messages in thread
From: AKS @ 2009-01-07 6:32 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 31 bytes --]
Please unsubscribe me, thanks!
[-- Attachment #2: Type: text/html, Size: 66 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
2009-01-07 6:32 ` unsubscribe AKS
@ 2009-01-07 6:38 ` zhou.yutao
2009-01-07 7:42 ` unsubscribe Decherf, Patrick
1 sibling, 0 replies; 127+ messages in thread
From: zhou.yutao @ 2009-01-07 6:38 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]
Please unsubscribe me, thanks!
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
深圳中兴力维技术有限公司
地址:深圳市高新区科技南一路W1-A二楼
电话:0755-26525674-8509(办公室)
AKS <aung.aungkyawsoe@gmail.com>
发件人: linuxppc-dev-bounces+zhou.yutao=zte.com.cn@ozlabs.org
2009-01-07 14:32
收件人
Linuxppc-dev@ozlabs.org
抄送
主题
unsubscribe
Please unsubscribe me, thanks!
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
[-- Attachment #2: Type: text/html, Size: 2795 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* RE: unsubscribe
2009-01-07 6:32 ` unsubscribe AKS
2009-01-07 6:38 ` unsubscribe zhou.yutao
@ 2009-01-07 7:42 ` Decherf, Patrick
2009-01-07 7:59 ` unsubscribe Liu Dave
1 sibling, 1 reply; 127+ messages in thread
From: Decherf, Patrick @ 2009-01-07 7:42 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 796 bytes --]
Please unsubscribe me, thanks!
DISCLAIMER:
Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you.
[-- Attachment #2: Type: text/html, Size: 1066 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2024-05-17 13:37 Satay Epic
0 siblings, 0 replies; 127+ messages in thread
From: Satay Epic @ 2024-05-17 13:37 UTC (permalink / raw)
To: kvm
^ permalink raw reply [flat|nested] 127+ messages in thread
* Unsubscribe
@ 2024-05-09 10:10 SP2L Tom
2024-05-09 10:21 ` Unsubscribe Dan Carpenter
0 siblings, 1 reply; 127+ messages in thread
From: SP2L Tom @ 2024-05-09 10:10 UTC (permalink / raw)
To: linux-hams
Unsubscribe
^ permalink raw reply [flat|nested] 127+ messages in thread
* [PATCH v5 00/22] RISC-V SBI v2.0 PMU improvements and Perf sampling in KVM guest
@ 2024-04-03 8:04 Atish Patra
2024-04-03 8:04 ` [PATCH v5 04/22] drivers/perf: riscv: Use BIT macro for shifting operations Atish Patra
0 siblings, 1 reply; 127+ messages in thread
From: Atish Patra @ 2024-04-03 8:04 UTC (permalink / raw)
To: linux-kernel
Cc: Atish Patra, Ajay Kaher, Alexandre Ghiti, Alexey Makhalov,
Andrew Jones, Anup Patel, Conor Dooley, Juergen Gross, kvm-riscv,
kvm, linux-kselftest, linux-riscv, Mark Rutland, Palmer Dabbelt,
Paolo Bonzini, Paul Walmsley, Shuah Khan, virtualization,
VMware PV-Drivers Reviewers, Will Deacon, x86
This series implements SBI PMU improvements done in SBI v2.0[1] i.e. PMU snapshot
and fw_read_hi() functions.
SBI v2.0 introduced PMU snapshot feature which allows the SBI implementation
to provide counter information (i.e. values/overflow status) via a shared
memory between the SBI implementation and supervisor OS. This allows to minimize
the number of traps in when perf being used inside a kvm guest as it relies on
SBI PMU + trap/emulation of the counters.
The current set of ratified RISC-V specification also doesn't allow scountovf
to be trap/emulated by the hypervisor. The SBI PMU snapshot bridges the gap
in ISA as well and enables perf sampling in the guest. However, LCOFI in the
guest only works via IRQ filtering in AIA specification. That's why, AIA
has to be enabled in the hardware (at least the Ssaia extension) in order to
use the sampling support in the perf.
Here are the patch wise implementation details.
PATCH 1,4,7,8,9,10,11,15 : Generic cleanups/improvements.
PATCH 2,3,14 : FW_READ_HI function implementation
PATCH 5-6: Add PMU snapshot feature in sbi pmu driver
PATCH 12-13: KVM implementation for snapshot and sampling in kvm guests
PATCH 16-17: Generic improvements for kvm selftests
PATCH 18-22: KVM selftests for SBI PMU extension
The series is based on v6.9-rc1 and is available at:
https://github.com/atishp04/linux/tree/kvm_pmu_snapshot_v5
The kvmtool patch is also available at:
https://github.com/atishp04/kvmtool/tree/sscofpmf
It also requires Ssaia ISA extension to be present in the hardware in order to
get perf sampling support in the guest. In Qemu virt machine, it can be done
by the following config.
```
-cpu rv64,sscofpmf=true,x-ssaia=true
```
There is no other dependencies on AIA apart from that. Thus, Ssaia must be disabled
for the guest if AIA patches are not available. Here is the example command.
```
./lkvm-static run -m 256 -c2 --console serial -p "console=ttyS0 earlycon" --disable-ssaia -k ./Image --debug
```
The series has been tested only in Qemu.
Here is the snippet of the perf running inside a kvm guest.
===================================================
$ perf record -e cycles -e instructions perf bench sched messaging -g 5
...
$ Running 'sched/messaging' benchmark:
...
[ 45.928723] perf_duration_warn: 2 callbacks suppressed
[ 45.929000] perf: interrupt took too long (484426 > 483186), lowering kernel.perf_event_max_sample_rate to 250
$ 20 sender and receiver processes per group
$ 5 groups == 200 processes run
Total time: 14.220 [sec]
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.117 MB perf.data (1942 samples) ]
$ perf report --stdio
$ To display the perf.data header info, please use --header/--header-only optio>
$
$
$ Total Lost Samples: 0
$
$ Samples: 943 of event 'cycles'
$ Event count (approx.): 5128976844
$
$ Overhead Command Shared Object Symbol >
$ ........ ............... ........................... .....................>
$
7.59% sched-messaging [kernel.kallsyms] [k] memcpy
5.48% sched-messaging [kernel.kallsyms] [k] percpu_counter_ad>
5.24% sched-messaging [kernel.kallsyms] [k] __sbi_rfence_v02_>
4.00% sched-messaging [kernel.kallsyms] [k] _raw_spin_unlock_>
3.79% sched-messaging [kernel.kallsyms] [k] set_pte_range
3.72% sched-messaging [kernel.kallsyms] [k] next_uptodate_fol>
3.46% sched-messaging [kernel.kallsyms] [k] filemap_map_pages
3.31% sched-messaging [kernel.kallsyms] [k] handle_mm_fault
3.20% sched-messaging [kernel.kallsyms] [k] finish_task_switc>
3.16% sched-messaging [kernel.kallsyms] [k] clear_page
3.03% sched-messaging [kernel.kallsyms] [k] mtree_range_walk
2.42% sched-messaging [kernel.kallsyms] [k] flush_icache_pte
===================================================
[1] https://github.com/riscv-non-isa/riscv-sbi-doc
Changes from v4->v5:
1. Moved sbi related definitions to its own header file from processor.h
2. Added few helper functions for selftests.
3. Improved firmware counter read and RV32 start/stop functions.
4. Converted all the shifting operations to use BIT macro
5. Addressed all other comments on v4.
Changes from v3->v4:
1. Added selftests.
2. Fixed an issue to clear the interrupt pending bits.
3. Fixed the counter index in snapshot memory start function.
Changes from v2->v3:
1. Fixed a patchwork warning on patch6.
2. Fixed a comment formatting & nit fix in PATCH 3 & 5.
3. Moved the hvien update and sscofpmf enabling to PATCH 9 from PATCH 8.
Changes from v1->v2:
1. Fixed warning/errors from patchwork CI.
2. Rebased on top of kvm-next.
3. Added Acked-by tags.
Changes from RFC->v1:
1. Addressed all the comments on RFC series.
2. Removed PATCH2 and merged into later patches.
3. Added 2 more patches for minor fixes.
4. Fixed KVM boot issue without Ssaia and made sscofpmf in guest dependent on
Ssaia in the host.
Atish Patra (22):
RISC-V: Fix the typo in Scountovf CSR name
RISC-V: Add FIRMWARE_READ_HI definition
drivers/perf: riscv: Read upper bits of a firmware counter
drivers/perf: riscv: Use BIT macro for shifting operations
RISC-V: Add SBI PMU snapshot definitions
drivers/perf: riscv: Implement SBI PMU snapshot function
drivers/perf: riscv: Fix counter mask iteration for RV32
RISC-V: KVM: Fix the initial sample period value
RISC-V: KVM: Rename the SBI_STA_SHMEM_DISABLE to a generic name
RISC-V: KVM: No need to update the counter value during reset
RISC-V: KVM: No need to exit to the user space if perf event failed
RISC-V: KVM: Implement SBI PMU Snapshot feature
RISC-V: KVM: Add perf sampling support for guests
RISC-V: KVM: Support 64 bit firmware counters on RV32
RISC-V: KVM: Improve firmware counter read function
KVM: riscv: selftests: Move sbi definitions to its own header file
KVM: riscv: selftests: Add helper functions for extension checks
KVM: riscv: selftests: Add Sscofpmf to get-reg-list test
KVM: riscv: selftests: Add SBI PMU extension definitions
KVM: riscv: selftests: Add SBI PMU selftest
KVM: riscv: selftests: Add a test for PMU snapshot functionality
KVM: riscv: selftests: Add a test for counter overflow
arch/riscv/include/asm/csr.h | 5 +-
arch/riscv/include/asm/kvm_vcpu_pmu.h | 16 +-
arch/riscv/include/asm/sbi.h | 34 +-
arch/riscv/include/uapi/asm/kvm.h | 1 +
arch/riscv/kernel/paravirt.c | 6 +-
arch/riscv/kvm/aia.c | 5 +
arch/riscv/kvm/vcpu.c | 15 +-
arch/riscv/kvm/vcpu_onereg.c | 5 +
arch/riscv/kvm/vcpu_pmu.c | 260 +++++++-
arch/riscv/kvm/vcpu_sbi_pmu.c | 17 +-
arch/riscv/kvm/vcpu_sbi_sta.c | 4 +-
drivers/perf/riscv_pmu.c | 1 +
drivers/perf/riscv_pmu_sbi.c | 264 +++++++-
include/linux/perf/riscv_pmu.h | 6 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/include/riscv/processor.h | 49 +-
.../testing/selftests/kvm/include/riscv/sbi.h | 141 +++++
.../selftests/kvm/include/riscv/ucall.h | 1 +
.../selftests/kvm/lib/riscv/processor.c | 12 +
.../testing/selftests/kvm/riscv/arch_timer.c | 2 +-
.../selftests/kvm/riscv/get-reg-list.c | 4 +
.../selftests/kvm/riscv/sbi_pmu_test.c | 581 ++++++++++++++++++
tools/testing/selftests/kvm/steal_time.c | 4 +-
23 files changed, 1322 insertions(+), 112 deletions(-)
create mode 100644 tools/testing/selftests/kvm/include/riscv/sbi.h
create mode 100644 tools/testing/selftests/kvm/riscv/sbi_pmu_test.c
--
2.34.1
^ permalink raw reply [flat|nested] 127+ messages in thread
* [PATCH v5 04/22] drivers/perf: riscv: Use BIT macro for shifting operations
2024-04-03 8:04 [PATCH v5 00/22] RISC-V SBI v2.0 PMU improvements and Perf sampling in KVM guest Atish Patra
@ 2024-04-03 8:04 ` Atish Patra
2024-04-03 15:57 ` unsubscribe jonathan.oleson
0 siblings, 1 reply; 127+ messages in thread
From: Atish Patra @ 2024-04-03 8:04 UTC (permalink / raw)
To: linux-kernel
Cc: Atish Patra, Ajay Kaher, Alexandre Ghiti, Alexey Makhalov,
Andrew Jones, Anup Patel, Conor Dooley, Juergen Gross, kvm-riscv,
kvm, linux-kselftest, linux-riscv, Mark Rutland, Palmer Dabbelt,
Paolo Bonzini, Paul Walmsley, Shuah Khan, virtualization,
VMware PV-Drivers Reviewers, Will Deacon, x86
It is a good practice to use BIT() instead of (1UL << x).
Replace the current usages with BIT().
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
arch/riscv/include/asm/sbi.h | 20 ++++++++++----------
drivers/perf/riscv_pmu_sbi.c | 2 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index ef8311dafb91..4afa2cd01bae 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -233,20 +233,20 @@ enum sbi_pmu_ctr_type {
#define SBI_PMU_EVENT_IDX_INVALID 0xFFFFFFFF
/* Flags defined for config matching function */
-#define SBI_PMU_CFG_FLAG_SKIP_MATCH (1 << 0)
-#define SBI_PMU_CFG_FLAG_CLEAR_VALUE (1 << 1)
-#define SBI_PMU_CFG_FLAG_AUTO_START (1 << 2)
-#define SBI_PMU_CFG_FLAG_SET_VUINH (1 << 3)
-#define SBI_PMU_CFG_FLAG_SET_VSINH (1 << 4)
-#define SBI_PMU_CFG_FLAG_SET_UINH (1 << 5)
-#define SBI_PMU_CFG_FLAG_SET_SINH (1 << 6)
-#define SBI_PMU_CFG_FLAG_SET_MINH (1 << 7)
+#define SBI_PMU_CFG_FLAG_SKIP_MATCH BIT(0)
+#define SBI_PMU_CFG_FLAG_CLEAR_VALUE BIT(1)
+#define SBI_PMU_CFG_FLAG_AUTO_START BIT(2)
+#define SBI_PMU_CFG_FLAG_SET_VUINH BIT(3)
+#define SBI_PMU_CFG_FLAG_SET_VSINH BIT(4)
+#define SBI_PMU_CFG_FLAG_SET_UINH BIT(5)
+#define SBI_PMU_CFG_FLAG_SET_SINH BIT(6)
+#define SBI_PMU_CFG_FLAG_SET_MINH BIT(7)
/* Flags defined for counter start function */
-#define SBI_PMU_START_FLAG_SET_INIT_VALUE (1 << 0)
+#define SBI_PMU_START_FLAG_SET_INIT_VALUE BIT(0)
/* Flags defined for counter stop function */
-#define SBI_PMU_STOP_FLAG_RESET (1 << 0)
+#define SBI_PMU_STOP_FLAG_RESET BIT(0)
enum sbi_ext_dbcn_fid {
SBI_EXT_DBCN_CONSOLE_WRITE = 0,
diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
index babf1b9a4dbe..a83ae82301e3 100644
--- a/drivers/perf/riscv_pmu_sbi.c
+++ b/drivers/perf/riscv_pmu_sbi.c
@@ -386,7 +386,7 @@ static int pmu_sbi_ctr_get_idx(struct perf_event *event)
cmask = 1;
} else if (event->attr.config == PERF_COUNT_HW_INSTRUCTIONS) {
cflags |= SBI_PMU_CFG_FLAG_SKIP_MATCH;
- cmask = 1UL << (CSR_INSTRET - CSR_CYCLE);
+ cmask = BIT(CSR_INSTRET - CSR_CYCLE);
}
}
--
2.34.1
^ permalink raw reply related [flat|nested] 127+ messages in thread
* unsubscribe
2024-04-03 8:04 ` [PATCH v5 04/22] drivers/perf: riscv: Use BIT macro for shifting operations Atish Patra
@ 2024-04-03 15:57 ` jonathan.oleson
0 siblings, 0 replies; 127+ messages in thread
From: jonathan.oleson @ 2024-04-03 15:57 UTC (permalink / raw)
To: linux-kernel
unsubscribe
Jonathan Oleson
Talent Acquisition | Seattle
linkedin.com/in/jonathanoleson/
jonathan.oleson@bytedance.com
-----Original Message-----
From: Atish Patra <atishp@rivosinc.com>
Sent: Wednesday, April 3, 2024 1:05 AM
To: linux-kernel@vger.kernel.org
Cc: Atish Patra <atishp@rivosinc.com>; Ajay Kaher <akaher@vmware.com>;
Alexandre Ghiti <alexghiti@rivosinc.com>; Alexey Makhalov
<amakhalov@vmware.com>; Andrew Jones <ajones@ventanamicro.com>; Anup Patel
<anup@brainfault.org>; Conor Dooley <conor.dooley@microchip.com>; Juergen
Gross <jgross@suse.com>; kvm-riscv@lists.infradead.org; kvm@vger.kernel.org;
linux-kselftest@vger.kernel.org; linux-riscv@lists.infradead.org; Mark
Rutland <mark.rutland@arm.com>; Palmer Dabbelt <palmer@dabbelt.com>; Paolo
Bonzini <pbonzini@redhat.com>; Paul Walmsley <paul.walmsley@sifive.com>;
Shuah Khan <shuah@kernel.org>; virtualization@lists.linux.dev; VMware
PV-Drivers Reviewers <pv-drivers@vmware.com>; Will Deacon <will@kernel.org>;
x86@kernel.org
Subject: [External] [PATCH v5 04/22] drivers/perf: riscv: Use BIT macro for
shifting operations
It is a good practice to use BIT() instead of (1UL << x).
Replace the current usages with BIT().
Signed-off-by: Atish Patra <atishp@rivosinc.com>
---
arch/riscv/include/asm/sbi.h | 20 ++++++++++----------
drivers/perf/riscv_pmu_sbi.c | 2 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index ef8311dafb91..4afa2cd01bae 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -233,20 +233,20 @@ enum sbi_pmu_ctr_type { #define
SBI_PMU_EVENT_IDX_INVALID 0xFFFFFFFF
/* Flags defined for config matching function */
-#define SBI_PMU_CFG_FLAG_SKIP_MATCH (1 << 0)
-#define SBI_PMU_CFG_FLAG_CLEAR_VALUE (1 << 1)
-#define SBI_PMU_CFG_FLAG_AUTO_START (1 << 2)
-#define SBI_PMU_CFG_FLAG_SET_VUINH (1 << 3)
-#define SBI_PMU_CFG_FLAG_SET_VSINH (1 << 4)
-#define SBI_PMU_CFG_FLAG_SET_UINH (1 << 5)
-#define SBI_PMU_CFG_FLAG_SET_SINH (1 << 6)
-#define SBI_PMU_CFG_FLAG_SET_MINH (1 << 7)
+#define SBI_PMU_CFG_FLAG_SKIP_MATCH BIT(0)
+#define SBI_PMU_CFG_FLAG_CLEAR_VALUE BIT(1)
+#define SBI_PMU_CFG_FLAG_AUTO_START BIT(2)
+#define SBI_PMU_CFG_FLAG_SET_VUINH BIT(3)
+#define SBI_PMU_CFG_FLAG_SET_VSINH BIT(4)
+#define SBI_PMU_CFG_FLAG_SET_UINH BIT(5)
+#define SBI_PMU_CFG_FLAG_SET_SINH BIT(6)
+#define SBI_PMU_CFG_FLAG_SET_MINH BIT(7)
/* Flags defined for counter start function */ -#define
SBI_PMU_START_FLAG_SET_INIT_VALUE (1 << 0)
+#define SBI_PMU_START_FLAG_SET_INIT_VALUE BIT(0)
/* Flags defined for counter stop function */ -#define
SBI_PMU_STOP_FLAG_RESET (1 << 0)
+#define SBI_PMU_STOP_FLAG_RESET BIT(0)
enum sbi_ext_dbcn_fid {
SBI_EXT_DBCN_CONSOLE_WRITE = 0,
diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
index babf1b9a4dbe..a83ae82301e3 100644
--- a/drivers/perf/riscv_pmu_sbi.c
+++ b/drivers/perf/riscv_pmu_sbi.c
@@ -386,7 +386,7 @@ static int pmu_sbi_ctr_get_idx(struct perf_event *event)
cmask = 1;
} else if (event->attr.config == PERF_COUNT_HW_INSTRUCTIONS)
{
cflags |= SBI_PMU_CFG_FLAG_SKIP_MATCH;
- cmask = 1UL << (CSR_INSTRET - CSR_CYCLE);
+ cmask = BIT(CSR_INSTRET - CSR_CYCLE);
}
}
--
2.34.1
^ permalink raw reply related [flat|nested] 127+ messages in thread
* unsubscribe
@ 2024-02-14 20:51 Igor Andreev
0 siblings, 0 replies; 127+ messages in thread
From: Igor Andreev @ 2024-02-14 20:51 UTC (permalink / raw)
To: linux-sh
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2024-01-15 8:19 limin yin
0 siblings, 0 replies; 127+ messages in thread
From: limin yin @ 2024-01-15 8:19 UTC (permalink / raw)
To: bpf
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2023-12-13 17:30 Hank Barta
0 siblings, 0 replies; 127+ messages in thread
From: Hank Barta @ 2023-12-13 17:30 UTC (permalink / raw)
To: linux-gpio
unsubscribe
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2023-11-25 16:50 Emmanuel ALLAUD
0 siblings, 0 replies; 127+ messages in thread
From: Emmanuel ALLAUD @ 2023-11-25 16:50 UTC (permalink / raw)
To: linux-media
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2023-06-20 6:46 Yao Yongxian
0 siblings, 0 replies; 127+ messages in thread
From: Yao Yongxian @ 2023-06-20 6:46 UTC (permalink / raw)
To: xenomai
unsubscribe
^ permalink raw reply [flat|nested] 127+ messages in thread
* [XEN][PATCH v6 00/19] dynamic node programming using overlay dtbo
@ 2023-05-02 23:36 Vikram Garhwal
2023-05-02 23:36 ` [XEN][PATCH v6 08/19] xen/device-tree: Add device_tree_find_node_by_path() to find nodes in device tree Vikram Garhwal
0 siblings, 1 reply; 127+ messages in thread
From: Vikram Garhwal @ 2023-05-02 23:36 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, vikram.garhwal, michal.orzel, Julien Grall,
Bertrand Marquis, Volodymyr Babchuk, Andrew Cooper,
George Dunlap, Jan Beulich, Wei Liu, Paul Durrant,
Roger Pau Monné,
Rahul Singh, Anthony PERARD, Juergen Gross
Hi,
This patch series is for introducing dynamic programming i.e. add/remove the
devices during run time. Using "xl dt_overlay" a device can be added/removed
with dtbo.
For adding a node using dynamic programming:
1. flatten device tree overlay node will be added to a fdt
2. Updated fdt will be unflattened to a new dt_host_new
3. Extract the newly added node information from dt_host_new
4. Add the added node under correct parent in original dt_host.
3. Map/Permit interrupt and iomem region as required.
For removing a node:
1. Find the node with given path.
2. Check if the node is used by any of domus. Removes the node only when
it's not used by any domain.
3. Removes IRQ permissions and MMIO access.
5. Find the node in dt_host and delete the device node entry from dt_host.
6. Free the overlay_tracker entry which means free dt_host_new also(created
in adding node step).
The main purpose of this series to address first part of the dynamic programming
i.e. making Xen aware of new device tree node which means updating the dt_host
with overlay node information. Here we are adding/removing node from dt_host,
and checking/set IOMMU and IRQ permission but never mapping them to any domain.
Right now, mapping/Un-mapping will happen only when a new domU is
created/destroyed using "xl create".
To map IOREQ and IOMMU during runtime, there will be another small series after
this one where we will do the actual IOMMU and IRQ mapping to a running domain
and will call unmap_mmio_regions() to remove the mapping.
Change Log:
v5 -> v6:
Add separate patch for memory allocation failure in __unflatten_device_tree().
Move __unflatten_device_tree() function type changes to single patch.
Add error propagation for failures in unflatten_dt_node.
Change CONFIG_OVERLAY_DTB status to "ARM: Tech Preview".
xen/smmu: Add remove_device callback for smmu_iommu ops:
Added check to see if device is currently used.
common/device_tree: Add rwlock for dt_host:
Addressed feedback from Henry to rearrange code.
xen/arm: Implement device tree node removal functionalities:
Changed file name to dash format.
Addressed Michal's comments.
Rectified formatting related errors pointed by Michal.
v4 -> v5:
Split patch 01/16 to two patches. One with function type changes and another
with changes inside unflatten_device_tree().
Change dt_overlay xl command to dt-overlay.
Protect overlay functionality with CONFIG(arm).
Fix rwlock issues.
Move include "device_tree.h" to c file where arch_cpu_init() is called and
forward declare dt_device_node. This was done to avoid circular deps b/w
device_tree.h and rwlock.h
Address Michal's comment on coding style.
v3 -> v4:
Add support for adding node's children.
Add rwlock to dt_host functions.
Corrected fdt size issue when applying overlay into it.
Add memory allocation fail handling for unflatten_device_tree().
Changed xl overlay to xl dt_overlay.
Correct commit messages.
Addressed code issue from v3 review.
v2 -> v3:
Moved overlay functionalities to dt_overlay.c file.
Renamed XEN_SYSCTL_overlay to XEN_SYSCTL_dt_overlay.
Add dt_* prefix to overlay_add/remove_nodes.
Added dtdevs_lock to protect iommu_add_dt_device().
For iommu, moved spin_lock to caller.
Address code issue from v2 review.
v1 -> v2:
Add support for multiple node addition/removal using dtbo.
Replaced fpga-add and fpga-remove with one hypercall overlay_op.
Moved common domain_build.c function to device.c
Add OVERLAY_DTB configuration.
Renamed overlay_get_target() to fdt_overlay_get_target().
Split remove_device patch into two patches.
Moved overlay_add/remove code to sysctl and changed it from domctl to sysctl.
Added all overlay code under CONFIG_OVERLAY_DTB
Renamed all tool domains fpga function to overlay
Addressed code issues from v1 review.
Regards,
Vikram
Vikram Garhwal (19):
xen/arm/device: Remove __init from function type
common/device_tree: handle memory allocation failure in
__unflatten_device_tree()
common/device_tree: change __unflatten_device_tree() type
common/device_tree.c: unflatten_device_tree() propagate errors
xen/arm: Add CONFIG_OVERLAY_DTB
libfdt: Keep fdt functions after init for CONFIG_OVERLAY_DTB.
libfdt: overlay: change overlay_get_target()
xen/device-tree: Add device_tree_find_node_by_path() to find nodes in
device tree
xen/iommu: Move spin_lock from iommu_dt_device_is_assigned to caller
xen/iommu: protect iommu_add_dt_device() with dtdevs_lock
xen/iommu: Introduce iommu_remove_dt_device()
xen/smmu: Add remove_device callback for smmu_iommu ops
asm/smp.h: Fix circular dependency for device_tree.h and rwlock.h
common/device_tree: Add rwlock for dt_host
xen/arm: Implement device tree node removal functionalities
xen/arm: Implement device tree node addition functionalities
tools/libs/ctrl: Implement new xc interfaces for dt overlay
tools/libs/light: Implement new libxl functions for device tree
overlay ops
tools/xl: Add new xl command overlay for device tree overlay support
SUPPORT.md | 6 +
tools/include/libxl.h | 11 +
tools/include/xenctrl.h | 5 +
tools/libs/ctrl/Makefile.common | 1 +
tools/libs/ctrl/xc_dt_overlay.c | 48 ++
tools/libs/light/Makefile | 3 +
tools/libs/light/libxl_dt_overlay.c | 71 ++
tools/xl/xl.h | 1 +
tools/xl/xl_cmdtable.c | 6 +
tools/xl/xl_vmcontrol.c | 52 ++
xen/arch/arm/Kconfig | 5 +
xen/arch/arm/device.c | 144 ++++
xen/arch/arm/domain_build.c | 142 ----
xen/arch/arm/include/asm/domain_build.h | 2 -
xen/arch/arm/include/asm/setup.h | 6 +
xen/arch/arm/include/asm/smp.h | 3 +-
xen/arch/arm/smpboot.c | 1 +
xen/arch/arm/sysctl.c | 16 +-
xen/common/Makefile | 1 +
xen/common/device_tree.c | 50 +-
xen/common/dt-overlay.c | 929 ++++++++++++++++++++++++
xen/common/libfdt/Makefile | 4 +
xen/common/libfdt/fdt_overlay.c | 29 +-
xen/common/libfdt/version.lds | 1 +
xen/drivers/passthrough/arm/smmu.c | 58 ++
xen/drivers/passthrough/device_tree.c | 87 ++-
xen/include/public/sysctl.h | 23 +
xen/include/xen/device_tree.h | 28 +-
xen/include/xen/dt-overlay.h | 58 ++
xen/include/xen/iommu.h | 3 +
xen/include/xen/libfdt/libfdt.h | 18 +
31 files changed, 1623 insertions(+), 189 deletions(-)
create mode 100644 tools/libs/ctrl/xc_dt_overlay.c
create mode 100644 tools/libs/light/libxl_dt_overlay.c
create mode 100644 xen/common/dt-overlay.c
create mode 100644 xen/include/xen/dt-overlay.h
--
2.17.1
^ permalink raw reply [flat|nested] 127+ messages in thread
* [XEN][PATCH v6 08/19] xen/device-tree: Add device_tree_find_node_by_path() to find nodes in device tree
2023-05-02 23:36 [XEN][PATCH v6 00/19] dynamic node programming using overlay dtbo Vikram Garhwal
@ 2023-05-02 23:36 ` Vikram Garhwal
2023-05-04 4:23 ` Henry Wang
0 siblings, 1 reply; 127+ messages in thread
From: Vikram Garhwal @ 2023-05-02 23:36 UTC (permalink / raw)
To: xen-devel; +Cc: sstabellini, vikram.garhwal, michal.orzel, Julien Grall
Add device_tree_find_node_by_path() to find a matching node with path for a
dt_device_node.
Reason behind this function:
Each time overlay nodes are added using .dtbo, a new fdt(memcpy of
device_tree_flattened) is created and updated with overlay nodes. This
updated fdt is further unflattened to a dt_host_new. Next, we need to find
the overlay nodes in dt_host_new, find the overlay node's parent in dt_host
and add the nodes as child under their parent in the dt_host. Thus we need
this function to search for node in different unflattened device trees.
Also, make dt_find_node_by_path() static inline.
Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
---
xen/common/device_tree.c | 5 +++--
xen/include/xen/device_tree.h | 17 +++++++++++++++--
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 47ab2f7940..426a809f42 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -358,11 +358,12 @@ struct dt_device_node *dt_find_node_by_type(struct dt_device_node *from,
return np;
}
-struct dt_device_node *dt_find_node_by_path(const char *path)
+struct dt_device_node *device_tree_find_node_by_path(struct dt_device_node *dt,
+ const char *path)
{
struct dt_device_node *np;
- dt_for_each_device_node(dt_host, np)
+ dt_for_each_device_node(dt, np)
if ( np->full_name && (dt_node_cmp(np->full_name, path) == 0) )
break;
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index eef0335b79..d6366d3dac 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -534,13 +534,26 @@ struct dt_device_node *dt_find_node_by_type(struct dt_device_node *from,
struct dt_device_node *dt_find_node_by_alias(const char *alias);
/**
- * dt_find_node_by_path - Find a node matching a full DT path
+ * device_tree_find_node_by_path - Generic function to find a node matching the
+ * full DT path for any given unflatten device tree
+ * @dt_node: The device tree to search
* @path: The full path to match
*
* Returns a node pointer.
*/
-struct dt_device_node *dt_find_node_by_path(const char *path);
+struct dt_device_node *device_tree_find_node_by_path(struct dt_device_node *dt,
+ const char *path);
+/**
+ * dt_find_node_by_path - Find a node matching a full DT path in dt_host
+ * @path: The full path to match
+ *
+ * Returns a node pointer.
+ */
+static inline struct dt_device_node *dt_find_node_by_path(const char *path)
+{
+ return device_tree_find_node_by_path(dt_host, path);
+}
/**
* dt_find_node_by_gpath - Same as dt_find_node_by_path but retrieve the
--
2.17.1
^ permalink raw reply related [flat|nested] 127+ messages in thread
* RE: [XEN][PATCH v6 08/19] xen/device-tree: Add device_tree_find_node_by_path() to find nodes in device tree
2023-05-02 23:36 ` [XEN][PATCH v6 08/19] xen/device-tree: Add device_tree_find_node_by_path() to find nodes in device tree Vikram Garhwal
@ 2023-05-04 4:23 ` Henry Wang
2023-05-04 5:56 ` unsubscribe Terry Yang
0 siblings, 1 reply; 127+ messages in thread
From: Henry Wang @ 2023-05-04 4:23 UTC (permalink / raw)
To: Vikram Garhwal, xen-devel; +Cc: sstabellini, michal.orzel, Julien Grall
Hi Vikram,
> -----Original Message-----
> Subject: [XEN][PATCH v6 08/19] xen/device-tree: Add
> device_tree_find_node_by_path() to find nodes in device tree
>
> Add device_tree_find_node_by_path() to find a matching node with path for
> a
> dt_device_node.
>
> Reason behind this function:
> Each time overlay nodes are added using .dtbo, a new fdt(memcpy of
> device_tree_flattened) is created and updated with overlay nodes. This
> updated fdt is further unflattened to a dt_host_new. Next, we need to find
> the overlay nodes in dt_host_new, find the overlay node's parent in dt_host
> and add the nodes as child under their parent in the dt_host. Thus we need
> this function to search for node in different unflattened device trees.
>
> Also, make dt_find_node_by_path() static inline.
>
> Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> ---
> xen/common/device_tree.c | 5 +++--
> xen/include/xen/device_tree.h | 17 +++++++++++++++--
> 2 files changed, 18 insertions(+), 4 deletions(-)
>
[...]
> /**
> - * dt_find_node_by_path - Find a node matching a full DT path
> + * device_tree_find_node_by_path - Generic function to find a node
> matching the
> + * full DT path for any given unflatten device tree
> + * @dt_node: The device tree to search
I noticed that you missed Michal's comment here about renaming the
"dt_node" here to "dt" to match below function prototype...
> * @path: The full path to match
> *
> * Returns a node pointer.
> */
> -struct dt_device_node *dt_find_node_by_path(const char *path);
> +struct dt_device_node *device_tree_find_node_by_path(struct
> dt_device_node *dt,
...here. I personally agree with Michal so I think please fix the comment
to keep consistency.
The rest of the patch looks good to me, so as long as you fixed this, you
can have my:
Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Kind regards,
Henry
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
2023-05-04 4:23 ` Henry Wang
@ 2023-05-04 5:56 ` Terry Yang
0 siblings, 0 replies; 127+ messages in thread
From: Terry Yang @ 2023-05-04 5:56 UTC (permalink / raw)
Cc: xen-devel
[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]
Henry Wang <Henry.Wang@arm.com>于2023年5月4日 周四12:23写道:
> Hi Vikram,
>
> > -----Original Message-----
> > Subject: [XEN][PATCH v6 08/19] xen/device-tree: Add
> > device_tree_find_node_by_path() to find nodes in device tree
> >
> > Add device_tree_find_node_by_path() to find a matching node with path for
> > a
> > dt_device_node.
> >
> > Reason behind this function:
> > Each time overlay nodes are added using .dtbo, a new fdt(memcpy of
> > device_tree_flattened) is created and updated with overlay nodes.
> This
> > updated fdt is further unflattened to a dt_host_new. Next, we need
> to find
> > the overlay nodes in dt_host_new, find the overlay node's parent in
> dt_host
> > and add the nodes as child under their parent in the dt_host. Thus
> we need
> > this function to search for node in different unflattened device
> trees.
> >
> > Also, make dt_find_node_by_path() static inline.
> >
> > Signed-off-by: Vikram Garhwal <vikram.garhwal@amd.com>
> > ---
> > xen/common/device_tree.c | 5 +++--
> > xen/include/xen/device_tree.h | 17 +++++++++++++++--
> > 2 files changed, 18 insertions(+), 4 deletions(-)
> >
>
> [...]
>
> > /**
> > - * dt_find_node_by_path - Find a node matching a full DT path
> > + * device_tree_find_node_by_path - Generic function to find a node
> > matching the
> > + * full DT path for any given unflatten device tree
> > + * @dt_node: The device tree to search
>
> I noticed that you missed Michal's comment here about renaming the
> "dt_node" here to "dt" to match below function prototype...
>
> > * @path: The full path to match
> > *
> > * Returns a node pointer.
> > */
> > -struct dt_device_node *dt_find_node_by_path(const char *path);
> > +struct dt_device_node *device_tree_find_node_by_path(struct
> > dt_device_node *dt,
>
> ...here. I personally agree with Michal so I think please fix the comment
> to keep consistency.
>
> The rest of the patch looks good to me, so as long as you fixed this, you
> can have my:
>
> Reviewed-by: Henry Wang <Henry.Wang@arm.com>
>
> Kind regards,
> Henry
>
>
>
[-- Attachment #2: Type: text/html, Size: 2849 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Unsubscribe
@ 2023-03-11 3:39 Aviral Gupta
0 siblings, 0 replies; 127+ messages in thread
From: Aviral Gupta @ 2023-03-11 3:39 UTC (permalink / raw)
To: Linux-kernel-mentees
[-- Attachment #1.1: Type: text/plain, Size: 54 bytes --]
I don't wish to receive any further communication
[-- Attachment #1.2: Type: text/html, Size: 87 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2022-12-01 1:38 Chan Kim
0 siblings, 0 replies; 127+ messages in thread
From: Chan Kim @ 2022-12-01 1:38 UTC (permalink / raw)
To: u-boot
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2022-10-13 10:14 Benjamin Demartin
2022-10-31 16:21 ` unsubscribe Thomas Monjalon
0 siblings, 1 reply; 127+ messages in thread
From: Benjamin Demartin @ 2022-10-13 10:14 UTC (permalink / raw)
To: dev
[-- Attachment #1: Type: text/plain, Size: 58 bytes --]
Hello I would like to unsubscribe but I don’t know how
[-- Attachment #2: Type: text/html, Size: 1285 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2022-06-29 21:00 Alvin Šipraga
2022-06-29 21:10 ` unsubscribe Alvin Šipraga
0 siblings, 1 reply; 127+ messages in thread
From: Alvin Šipraga @ 2022-06-29 21:00 UTC (permalink / raw)
To: iwd
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2021-11-02 6:37 Jacky Wang (王亮)-浪潮数据
0 siblings, 0 replies; 127+ messages in thread
From: Jacky Wang (王亮)-浪潮数据 @ 2021-11-02 6:37 UTC (permalink / raw)
To: nvdimm
[-- Attachment #1: Type: text/plain, Size: 19 bytes --]
unsubscribe nvdimm
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3627 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2021-09-30 21:48 Shoaib Rao
2021-09-30 21:49 ` unsubscribe Shoaib Rao
0 siblings, 1 reply; 127+ messages in thread
From: Shoaib Rao @ 2021-09-30 21:48 UTC (permalink / raw)
To: MPTCP Upstream
unsubscribe
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2020-12-29 8:54 Shawn Landden
0 siblings, 0 replies; 127+ messages in thread
From: Shawn Landden @ 2020-12-29 8:54 UTC (permalink / raw)
To: linuxppc-dev
--
Shawn Landden
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2020-12-21 7:28 Shawn Landden
0 siblings, 0 replies; 127+ messages in thread
From: Shawn Landden @ 2020-12-21 7:28 UTC (permalink / raw)
To: linuxppc-dev
--
Shawn Landden
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2020-10-07 15:34 Thompson, Kent
0 siblings, 0 replies; 127+ messages in thread
From: Thompson, Kent @ 2020-10-07 15:34 UTC (permalink / raw)
To: openbmc
[-- Attachment #1: Type: text/plain, Size: 2 bytes --]
[-- Attachment #2: Type: text/html, Size: 1447 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
[parent not found: <CAGHfRMD3FP0_dAEmOgnkgyodXodWq2YcjaiOzvBwG=J1nqq-8g@mail.gmail.com>]
* Unsubscribe
@ 2019-05-29 15:32 ID - David Torres
0 siblings, 0 replies; 127+ messages in thread
From: ID - David Torres @ 2019-05-29 15:32 UTC (permalink / raw)
To: meta-freescale Mailing List
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
Unsubscribe
De: meta-freescale-bounces@yoctoproject.org <meta-freescale-bounces@yoctoproject.org> En nombre de Vahid Gharaee
Enviado el: sábado, 25 de mayo de 2019 8:01
Para: meta-freescale Mailing List <meta-freescale@yoctoproject.org>
Asunto: [meta-freescale] qt5
Dear all,
How could I add qt5 support in fsl-community-bsp
I added the meta-qt5 but there is no image to bitbake the rootfs.
multimedia image does not include qt5.
Thank you in advanced
Vahid
[-- Attachment #2: Type: text/html, Size: 3088 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: overlayfs vs. fscrypt
@ 2019-03-14 7:34 Miklos Szeredi
2019-03-14 17:15 ` [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required Richard Weinberger
0 siblings, 1 reply; 127+ messages in thread
From: Miklos Szeredi @ 2019-03-14 7:34 UTC (permalink / raw)
To: Richard Weinberger
Cc: Eric Biggers, Amir Goldstein, linux-fsdevel, linux-fscrypt,
overlayfs, linux-kernel, Paul Lawrence
On Wed, Mar 13, 2019 at 11:42 PM Richard Weinberger <richard@nod.at> wrote:
>
> Am Mittwoch, 13. März 2019, 23:26:11 CET schrieb Eric Biggers:
> > What specifically is wrong with supporting the ciphertext "view" of encrypted
> > directories, and why do you want to opt UBIFS out of it specifically but not
> > ext4 and f2fs? (The fscrypt_operations are per-filesystem type, not
> > per-filesystem instance, so I assume that's what you had in mind.) Note that we
> > can't unconditionally remove it because people need it to delete files without
> > the key. We could add a mount option to disable it, but why exactly?
>
> You are right, fscrypt_operations is the wrong structure.
> My plan was having it per filesystem instance. So a mount-option seems like
> a good option. Of course for all filesystems that support fscrypt, not just UBIFS.
Yes, please. Changing filesystem contents based on a mount option is
orders of magnitude more sane than doing so on key insertion/removal.
Thanks,
Miklos
^ permalink raw reply [flat|nested] 127+ messages in thread
* [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required
@ 2019-03-14 17:15 ` Richard Weinberger
2019-03-14 17:49 ` Eric Biggers
0 siblings, 1 reply; 127+ messages in thread
From: Richard Weinberger @ 2019-03-14 17:15 UTC (permalink / raw)
To: linux-mtd
Cc: tytso, miklos, Richard Weinberger, amir73il, linux-unionfs,
linux-kernel, paullawrence, linux-fscrypt, linux-fsdevel,
jaegeuk
Usually fscrypt allows limited access to encrypted files even
if no key is available.
Encrypted filenames are shown and based on this names users
can unlink and move files.
This is not always what people expect. The fscrypt_key_required mount
option disables this feature.
If no key is present all access is denied with the -ENOKEY error code.
The side benefit of this is that we don't need ->d_revalidate().
Not having ->d_revalidate() makes an encrypted ubifs usable
as overlayfs upper directory.
Signed-off-by: Richard Weinberger <richard@nod.at>
---
fs/ubifs/crypto.c | 2 +-
fs/ubifs/dir.c | 29 ++++++++++++++++++++++++++---
fs/ubifs/super.c | 15 +++++++++++++++
fs/ubifs/ubifs.h | 1 +
4 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/fs/ubifs/crypto.c b/fs/ubifs/crypto.c
index 4aaedf2d7f44..a6a48c5dc058 100644
--- a/fs/ubifs/crypto.c
+++ b/fs/ubifs/crypto.c
@@ -76,7 +76,7 @@ int ubifs_decrypt(const struct inode *inode, struct ubifs_data_node *dn,
}
const struct fscrypt_operations ubifs_crypt_operations = {
- .flags = FS_CFLG_OWN_PAGES,
+ .flags = FS_CFLG_OWN_PAGES | FS_CFLG_OWN_D_OPS,
.key_prefix = "ubifs:",
.get_context = ubifs_crypt_get_context,
.set_context = ubifs_crypt_set_context,
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index b0cb913697c5..4d029f08b80d 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -208,6 +208,16 @@ static int dbg_check_name(const struct ubifs_info *c,
return 0;
}
+static void ubifs_set_dentry_ops(struct inode *dir, struct dentry *dentry)
+{
+#ifdef CONFIG_FS_ENCRYPTION
+ struct ubifs_info *c = dir->i_sb->s_fs_info;
+
+ if (IS_ENCRYPTED(dir) && !c->fscrypt_key_required)
+ d_set_d_op(dentry, &fscrypt_d_ops);
+#endif
+}
+
static struct dentry *ubifs_lookup(struct inode *dir, struct dentry *dentry,
unsigned int flags)
{
@@ -224,7 +234,10 @@ static struct dentry *ubifs_lookup(struct inode *dir, struct dentry *dentry,
if (err)
return ERR_PTR(err);
- err = fscrypt_setup_filename(dir, &dentry->d_name, 1, &nm);
+ ubifs_set_dentry_ops(dir, dentry);
+
+ err = fscrypt_setup_filename(dir, &dentry->d_name,
+ !c->fscrypt_key_required, &nm);
if (err)
return ERR_PTR(err);
@@ -240,6 +253,11 @@ static struct dentry *ubifs_lookup(struct inode *dir, struct dentry *dentry,
}
if (nm.hash) {
+ if (c->fscrypt_key_required) {
+ inode = ERR_PTR(-ENOKEY);
+ goto done;
+ }
+
ubifs_assert(c, fname_len(&nm) == 0);
ubifs_assert(c, fname_name(&nm) == NULL);
dent_key_init_hash(c, &key, dir->i_ino, nm.hash);
@@ -529,6 +547,9 @@ static int ubifs_readdir(struct file *file, struct dir_context *ctx)
if (err)
return err;
+ if (c->fscrypt_key_required && !dir->i_crypt_info)
+ return -ENOKEY;
+
err = fscrypt_fname_alloc_buffer(dir, UBIFS_MAX_NLEN, &fstr);
if (err)
return err;
@@ -798,7 +819,8 @@ static int ubifs_unlink(struct inode *dir, struct dentry *dentry)
return err;
}
- err = fscrypt_setup_filename(dir, &dentry->d_name, 1, &nm);
+ err = fscrypt_setup_filename(dir, &dentry->d_name, !c->fscrypt_key_required,
+ &nm);
if (err)
return err;
@@ -908,7 +930,8 @@ static int ubifs_rmdir(struct inode *dir, struct dentry *dentry)
return err;
}
- err = fscrypt_setup_filename(dir, &dentry->d_name, 1, &nm);
+ err = fscrypt_setup_filename(dir, &dentry->d_name,
+ !c->fscrypt_key_required, &nm);
if (err)
return err;
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 8dc2818fdd84..e081b00236b6 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -445,6 +445,9 @@ static int ubifs_show_options(struct seq_file *s, struct dentry *root)
ubifs_compr_name(c, c->mount_opts.compr_type));
}
+ if (c->fscrypt_key_required)
+ seq_puts(s, ",fscrypt_key_required");
+
seq_printf(s, ",assert=%s", ubifs_assert_action_name(c));
seq_printf(s, ",ubi=%d,vol=%d", c->vi.ubi_num, c->vi.vol_id);
@@ -952,6 +955,7 @@ enum {
Opt_assert,
Opt_auth_key,
Opt_auth_hash_name,
+ Opt_fscrypt_key_required,
Opt_ignore,
Opt_err,
};
@@ -969,6 +973,7 @@ static const match_table_t tokens = {
{Opt_ignore, "ubi=%s"},
{Opt_ignore, "vol=%s"},
{Opt_assert, "assert=%s"},
+ {Opt_fscrypt_key_required, "fscrypt_key_required"},
{Opt_err, NULL},
};
@@ -1008,6 +1013,7 @@ static int ubifs_parse_options(struct ubifs_info *c, char *options,
{
char *p;
substring_t args[MAX_OPT_ARGS];
+ unsigned int old_fscrypt_key_required = c->fscrypt_key_required;
if (!options)
return 0;
@@ -1099,6 +1105,15 @@ static int ubifs_parse_options(struct ubifs_info *c, char *options,
if (!c->auth_hash_name)
return -ENOMEM;
break;
+ case Opt_fscrypt_key_required:
+ c->fscrypt_key_required = 1;
+
+ if (is_remount && (old_fscrypt_key_required != c->fscrypt_key_required)) {
+ ubifs_err(c, "fscrypt_key_required cannot changed by remount");
+ return -EINVAL;
+ }
+
+ break;
case Opt_ignore:
break;
default:
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index 1ae12900e01d..71b03a6798ae 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -1304,6 +1304,7 @@ struct ubifs_info {
unsigned int rw_incompat:1;
unsigned int assert_action:2;
unsigned int authenticated:1;
+ unsigned int fscrypt_key_required:1;
struct mutex tnc_mutex;
struct ubifs_zbranch zroot;
--
2.21.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 127+ messages in thread
* Re: [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required
2019-03-14 17:15 ` [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required Richard Weinberger
@ 2019-03-14 17:49 ` Eric Biggers
2019-03-14 20:54 ` Richard Weinberger
0 siblings, 1 reply; 127+ messages in thread
From: Eric Biggers @ 2019-03-14 17:49 UTC (permalink / raw)
To: Richard Weinberger
Cc: linux-mtd, linux-fscrypt, jaegeuk, tytso, linux-unionfs, miklos,
amir73il, linux-fsdevel, linux-kernel, paullawrence
Hi Richard,
On Thu, Mar 14, 2019 at 06:15:59PM +0100, Richard Weinberger wrote:
> Usually fscrypt allows limited access to encrypted files even
> if no key is available.
> Encrypted filenames are shown and based on this names users
> can unlink and move files.
Actually, fscrypt doesn't allow moving files without the key. It would only be
possible for cross-renames, i.e. renames with the RENAME_EXCHANGE flag. So for
consistency with regular renames, fscrypt also forbids cross-renames if the key
for either the source or destination directory is missing.
So the main use case for the ciphertext view is *deleting* files. For example,
deleting a user's home directory after that user has been removed from the
system. Or the system freeing up space by deleting cache files from a user who
isn't currently logged in.
>
> This is not always what people expect. The fscrypt_key_required mount
> option disables this feature.
> If no key is present all access is denied with the -ENOKEY error code.
The problem with this mount option is that it allows users to create undeletable
files. So I'm not really convinced yet this is a good change. And though the
fscrypt_key_required semantics are easier to implement, we'd still have to
support the existing semantics too, thus increasing the maintenance cost.
>
> The side benefit of this is that we don't need ->d_revalidate().
> Not having ->d_revalidate() makes an encrypted ubifs usable
> as overlayfs upper directory.
>
It would be preferable if we could get overlayfs to work without providing a
special mount option.
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
> fs/ubifs/crypto.c | 2 +-
> fs/ubifs/dir.c | 29 ++++++++++++++++++++++++++---
> fs/ubifs/super.c | 15 +++++++++++++++
> fs/ubifs/ubifs.h | 1 +
> 4 files changed, 43 insertions(+), 4 deletions(-)
>
Shouldn't readlink() honor the mount option too?
> diff --git a/fs/ubifs/crypto.c b/fs/ubifs/crypto.c
> index 4aaedf2d7f44..a6a48c5dc058 100644
> --- a/fs/ubifs/crypto.c
> +++ b/fs/ubifs/crypto.c
> @@ -76,7 +76,7 @@ int ubifs_decrypt(const struct inode *inode, struct ubifs_data_node *dn,
> }
>
> const struct fscrypt_operations ubifs_crypt_operations = {
> - .flags = FS_CFLG_OWN_PAGES,
> + .flags = FS_CFLG_OWN_PAGES | FS_CFLG_OWN_D_OPS,
> .key_prefix = "ubifs:",
> .get_context = ubifs_crypt_get_context,
> .set_context = ubifs_crypt_set_context,
> diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
> index b0cb913697c5..4d029f08b80d 100644
> --- a/fs/ubifs/dir.c
> +++ b/fs/ubifs/dir.c
> @@ -208,6 +208,16 @@ static int dbg_check_name(const struct ubifs_info *c,
> return 0;
> }
>
> +static void ubifs_set_dentry_ops(struct inode *dir, struct dentry *dentry)
> +{
> +#ifdef CONFIG_FS_ENCRYPTION
> + struct ubifs_info *c = dir->i_sb->s_fs_info;
> +
> + if (IS_ENCRYPTED(dir) && !c->fscrypt_key_required)
> + d_set_d_op(dentry, &fscrypt_d_ops);
> +#endif
> +}
> +
> static struct dentry *ubifs_lookup(struct inode *dir, struct dentry *dentry,
> unsigned int flags)
> {
> @@ -224,7 +234,10 @@ static struct dentry *ubifs_lookup(struct inode *dir, struct dentry *dentry,
> if (err)
> return ERR_PTR(err);
>
> - err = fscrypt_setup_filename(dir, &dentry->d_name, 1, &nm);
> + ubifs_set_dentry_ops(dir, dentry);
> +
> + err = fscrypt_setup_filename(dir, &dentry->d_name,
> + !c->fscrypt_key_required, &nm);
> if (err)
> return ERR_PTR(err);
>
> @@ -240,6 +253,11 @@ static struct dentry *ubifs_lookup(struct inode *dir, struct dentry *dentry,
> }
>
> if (nm.hash) {
> + if (c->fscrypt_key_required) {
> + inode = ERR_PTR(-ENOKEY);
> + goto done;
> + }
> +
> ubifs_assert(c, fname_len(&nm) == 0);
> ubifs_assert(c, fname_name(&nm) == NULL);
> dent_key_init_hash(c, &key, dir->i_ino, nm.hash);
> @@ -529,6 +547,9 @@ static int ubifs_readdir(struct file *file, struct dir_context *ctx)
> if (err)
> return err;
>
> + if (c->fscrypt_key_required && !dir->i_crypt_info)
> + return -ENOKEY;
> +
How about returning -ENOKEY when trying to open the directory in the first
place, rather than allowing getting to readdir()? That would match the behavior
of regular files.
> err = fscrypt_fname_alloc_buffer(dir, UBIFS_MAX_NLEN, &fstr);
> if (err)
> return err;
> @@ -798,7 +819,8 @@ static int ubifs_unlink(struct inode *dir, struct dentry *dentry)
> return err;
> }
>
> - err = fscrypt_setup_filename(dir, &dentry->d_name, 1, &nm);
> + err = fscrypt_setup_filename(dir, &dentry->d_name, !c->fscrypt_key_required,
> + &nm);
> if (err)
> return err;
>
> @@ -908,7 +930,8 @@ static int ubifs_rmdir(struct inode *dir, struct dentry *dentry)
> return err;
> }
>
> - err = fscrypt_setup_filename(dir, &dentry->d_name, 1, &nm);
> + err = fscrypt_setup_filename(dir, &dentry->d_name,
> + !c->fscrypt_key_required, &nm);
> if (err)
> return err;
>
> diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
> index 8dc2818fdd84..e081b00236b6 100644
> --- a/fs/ubifs/super.c
> +++ b/fs/ubifs/super.c
> @@ -445,6 +445,9 @@ static int ubifs_show_options(struct seq_file *s, struct dentry *root)
> ubifs_compr_name(c, c->mount_opts.compr_type));
> }
>
> + if (c->fscrypt_key_required)
> + seq_puts(s, ",fscrypt_key_required");
> +
> seq_printf(s, ",assert=%s", ubifs_assert_action_name(c));
> seq_printf(s, ",ubi=%d,vol=%d", c->vi.ubi_num, c->vi.vol_id);
>
> @@ -952,6 +955,7 @@ enum {
> Opt_assert,
> Opt_auth_key,
> Opt_auth_hash_name,
> + Opt_fscrypt_key_required,
> Opt_ignore,
> Opt_err,
> };
> @@ -969,6 +973,7 @@ static const match_table_t tokens = {
> {Opt_ignore, "ubi=%s"},
> {Opt_ignore, "vol=%s"},
> {Opt_assert, "assert=%s"},
> + {Opt_fscrypt_key_required, "fscrypt_key_required"},
> {Opt_err, NULL},
> };
>
> @@ -1008,6 +1013,7 @@ static int ubifs_parse_options(struct ubifs_info *c, char *options,
> {
> char *p;
> substring_t args[MAX_OPT_ARGS];
> + unsigned int old_fscrypt_key_required = c->fscrypt_key_required;
>
> if (!options)
> return 0;
> @@ -1099,6 +1105,15 @@ static int ubifs_parse_options(struct ubifs_info *c, char *options,
> if (!c->auth_hash_name)
> return -ENOMEM;
> break;
> + case Opt_fscrypt_key_required:
> + c->fscrypt_key_required = 1;
> +
> + if (is_remount && (old_fscrypt_key_required != c->fscrypt_key_required)) {
> + ubifs_err(c, "fscrypt_key_required cannot changed by remount");
> + return -EINVAL;
> + }
> +
> + break;
> case Opt_ignore:
> break;
> default:
> diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
> index 1ae12900e01d..71b03a6798ae 100644
> --- a/fs/ubifs/ubifs.h
> +++ b/fs/ubifs/ubifs.h
> @@ -1304,6 +1304,7 @@ struct ubifs_info {
> unsigned int rw_incompat:1;
> unsigned int assert_action:2;
> unsigned int authenticated:1;
> + unsigned int fscrypt_key_required:1;
>
> struct mutex tnc_mutex;
> struct ubifs_zbranch zroot;
> --
> 2.21.0
>
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required
2019-03-14 17:49 ` Eric Biggers
@ 2019-03-14 20:54 ` Richard Weinberger
2019-03-14 23:07 ` Theodore Ts'o
0 siblings, 1 reply; 127+ messages in thread
From: Richard Weinberger @ 2019-03-14 20:54 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-mtd, linux-fscrypt, jaegeuk, tytso, linux-unionfs, miklos,
amir73il, linux-fsdevel, linux-kernel, paullawrence
Eric,
Am Donnerstag, 14. März 2019, 18:49:14 CET schrieb Eric Biggers:
> Hi Richard,
>
> On Thu, Mar 14, 2019 at 06:15:59PM +0100, Richard Weinberger wrote:
> > Usually fscrypt allows limited access to encrypted files even
> > if no key is available.
> > Encrypted filenames are shown and based on this names users
> > can unlink and move files.
>
> Actually, fscrypt doesn't allow moving files without the key. It would only be
> possible for cross-renames, i.e. renames with the RENAME_EXCHANGE flag. So for
> consistency with regular renames, fscrypt also forbids cross-renames if the key
> for either the source or destination directory is missing.
>
> So the main use case for the ciphertext view is *deleting* files. For example,
> deleting a user's home directory after that user has been removed from the
> system. Or the system freeing up space by deleting cache files from a user who
> isn't currently logged in.
Right, I somehow thought beside of deleting you can do more.
> >
> > This is not always what people expect. The fscrypt_key_required mount
> > option disables this feature.
> > If no key is present all access is denied with the -ENOKEY error code.
>
> The problem with this mount option is that it allows users to create undeletable
> files. So I'm not really convinced yet this is a good change. And though the
> fscrypt_key_required semantics are easier to implement, we'd still have to
> support the existing semantics too, thus increasing the maintenance cost.
The undeletable-file argument is a good point. Thanks for bringing this up.
To get rid of such files root needs to mount without the new mount parameter. ;-\
> >
> > The side benefit of this is that we don't need ->d_revalidate().
> > Not having ->d_revalidate() makes an encrypted ubifs usable
> > as overlayfs upper directory.
> >
>
> It would be preferable if we could get overlayfs to work without providing a
> special mount option.
Yes, but let's see what Al finds in his review.
> > Signed-off-by: Richard Weinberger <richard@nod.at>
> > ---
> > fs/ubifs/crypto.c | 2 +-
> > fs/ubifs/dir.c | 29 ++++++++++++++++++++++++++---
> > fs/ubifs/super.c | 15 +++++++++++++++
> > fs/ubifs/ubifs.h | 1 +
> > 4 files changed, 43 insertions(+), 4 deletions(-)
> >
>
> Shouldn't readlink() honor the mount option too?
Hmmm, yes. We need to honor it in ->get_link() too.
> > + if (c->fscrypt_key_required && !dir->i_crypt_info)
> > + return -ENOKEY;
> > +
>
> How about returning -ENOKEY when trying to open the directory in the first
> place, rather than allowing getting to readdir()? That would match the behavior
> of regular files.
I'm not sure what the best approach is.
We could also do it in ->permission().
Thanks,
//richard
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required
2019-03-14 20:54 ` Richard Weinberger
@ 2019-03-14 23:07 ` Theodore Ts'o
2019-03-15 0:26 ` Unsubscribe Shane Volpe
0 siblings, 1 reply; 127+ messages in thread
From: Theodore Ts'o @ 2019-03-14 23:07 UTC (permalink / raw)
To: Richard Weinberger
Cc: Eric Biggers, linux-mtd, linux-fscrypt, jaegeuk, linux-unionfs,
miklos, amir73il, linux-fsdevel, linux-kernel, paullawrence
Richard --- stepping back for a moment, in your use case, are you
assuming that the encryption key is always going to be present while
the system is running?
Ubifs can't use dm-crypt, since it doesn't have a block device, but if
you could, is much more like dm-crypt, in that you have the key
*before* the file system is mounted, and you don't really expect the
key to ever be expunged from the system while it is mounted?
If that's true, maybe the real mismatch is in using fscrypt in the
first place --- and in fact, something where you encrypt everything,
including the file system metadata (ala dm-crypt), would actually give
you much better security properties.
- Ted
^ permalink raw reply [flat|nested] 127+ messages in thread
* Unsubscribe
2019-03-14 23:07 ` Theodore Ts'o
@ 2019-03-15 0:26 ` Shane Volpe
0 siblings, 0 replies; 127+ messages in thread
From: Shane Volpe @ 2019-03-15 0:26 UTC (permalink / raw)
To: Theodore Ts'o, Richard Weinberger, Eric Biggers, linux-mtd,
linux-fscrypt, jaegeuk, linux-unionfs, miklos, amir73il,
linux-fsdevel, linux-kernel, paullawrence
[-- Attachment #1: Type: text/plain, Size: 12 bytes --]
Unsubscribe
[-- Attachment #2: Type: text/html, Size: 58 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2019-03-07 14:15 Punky
0 siblings, 0 replies; 127+ messages in thread
From: Punky @ 2019-03-07 14:15 UTC (permalink / raw)
To: openembedded-devel
--
--
Regards,
Kim-man "Punky" Tse
* Open Source Embedded Solutions and Systems
- Voyage Linux (http://linux.voyage.hk)
- Voyage MPD (http://linux.voyage.hk/voyage-mpd)
- Voyage MuBox (http://mubox.voyage.hk)
* Voyage Store (http://store.voyage.hk)
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2019-03-07 14:13 Punky
0 siblings, 0 replies; 127+ messages in thread
From: Punky @ 2019-03-07 14:13 UTC (permalink / raw)
To: openembedded-devel
--
--
Regards,
Kim-man "Punky" Tse
* Open Source Embedded Solutions and Systems
- Voyage Linux (http://linux.voyage.hk)
- Voyage MPD (http://linux.voyage.hk/voyage-mpd)
- Voyage MuBox (http://mubox.voyage.hk)
* Voyage Store (http://store.voyage.hk)
^ permalink raw reply [flat|nested] 127+ messages in thread
* Unsubscribe
@ 2018-05-14 21:14 Eric Brown
0 siblings, 0 replies; 127+ messages in thread
From: Eric Brown @ 2018-05-14 21:14 UTC (permalink / raw)
To: selinux
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: Type: text/html, Size: 23 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
[parent not found: <CGME20180128235454epcms1p6f3b7aa47ba9c5035f9b317421c09a46a@epcms1p6>]
* unsubscribe
@ 2017-06-20 7:57 Gary Thomas
0 siblings, 0 replies; 127+ messages in thread
From: Gary Thomas @ 2017-06-20 7:57 UTC (permalink / raw)
To: linuxppc-dev-request; +Cc: linuxppc-dev
Sadly, after >20 years
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2017-01-19 18:31 Brad Litterell
0 siblings, 0 replies; 127+ messages in thread
From: Brad Litterell @ 2017-01-19 18:31 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 13 bytes --]
unsubscribe
[-- Attachment #2: Type: text/html, Size: 2509 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
[parent not found: <CGME20161205003536epcms1p4c6ce52ccda8bbc5da6eb99d3de8e12a3@epcms1p4>]
* unsubscribe
@ 2016-10-25 18:30 cybin
0 siblings, 0 replies; 127+ messages in thread
From: cybin @ 2016-10-25 18:30 UTC (permalink / raw)
To: PowerPC email list
unsubscribe
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2016-10-05 12:53 고영준
0 siblings, 0 replies; 127+ messages in thread
From: 고영준 @ 2016-10-05 12:53 UTC (permalink / raw)
To: kernelnewbies
unsubscribe
?????ohojang?? ???
????? ??????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161005/31223606/attachment.html
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2016-08-16 6:44 kuangjiou
0 siblings, 0 replies; 127+ messages in thread
From: kuangjiou @ 2016-08-16 6:44 UTC (permalink / raw)
To: Selinux
[-- Attachment #1: Type: text/plain, Size: 13 bytes --]
unsubscribe
[-- Attachment #2: Type: text/html, Size: 1920 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2016-04-18 23:21 cybin
0 siblings, 0 replies; 127+ messages in thread
From: cybin @ 2016-04-18 23:21 UTC (permalink / raw)
To: Linuxppc-dev
^ permalink raw reply [flat|nested] 127+ messages in thread
[parent not found: <CAOLmke5wWrewgemRGCfgMY7vnqsnAQcZHDteVWkLHWOj_kOYbA@mail.gmail.com>]
* unsubscribe
@ 2014-08-11 13:19 Deepak Pandian
0 siblings, 0 replies; 127+ messages in thread
From: Deepak Pandian @ 2014-08-11 13:19 UTC (permalink / raw)
To: linuxppc-dev
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2014-02-01 6:27 animan9
0 siblings, 0 replies; 127+ messages in thread
From: animan9 @ 2014-02-01 6:27 UTC (permalink / raw)
To: alsa-devel
unsubscribe
Sent from Windows Mail
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2013-11-22 19:35 Pow, Christopher (SWCOE)
2013-11-22 19:38 ` unsubscribe Denys Dmytriyenko
0 siblings, 1 reply; 127+ messages in thread
From: Pow, Christopher (SWCOE) @ 2013-11-22 19:35 UTC (permalink / raw)
To: meta-ti
[-- Attachment #1: Type: text/plain, Size: 2 bytes --]
[-- Attachment #2: Type: text/html, Size: 1618 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2013-10-02 15:58 Daniel Kranich
0 siblings, 0 replies; 127+ messages in thread
From: Daniel Kranich @ 2013-10-02 15:58 UTC (permalink / raw)
To: kernelnewbies
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2013-09-15 13:52 GMAIL
0 siblings, 0 replies; 127+ messages in thread
From: GMAIL @ 2013-09-15 13:52 UTC (permalink / raw)
To: kernelnewbies
unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130915/385e6398/attachment.html
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2013-09-11 8:43 GMAIL
0 siblings, 0 replies; 127+ messages in thread
From: GMAIL @ 2013-09-11 8:43 UTC (permalink / raw)
To: kernelnewbies
unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130911/dc13c3c6/attachment.html
^ permalink raw reply [flat|nested] 127+ messages in thread
* Mysterious memory corruption bug
@ 2012-05-01 18:53 Bean
2012-05-01 19:08 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 1 reply; 127+ messages in thread
From: Bean @ 2012-05-01 18:53 UTC (permalink / raw)
To: The development of GRUB 2
[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]
Hi,
Thanks to Vladimir's memory patch, it's actually quite easy to
reproduce mysterious issue.
First, there are two memory leaks in ip.c.
It allocates the rsm but never frees it. free_rsm frees its content,
but not the pointer itself. You can see it in printmem at ip.c:473
rsm = grub_malloc (sizeof (*rsm));
Another problem is at ip.c:594:
return handle_dgram (ret, card, src_hwaddress,
hwaddress, proto, &source, &dest,
ttl);
here, ret is netbuff. grub_netbuff_alloc get a buffer for both data
and header (data go first), so when it frees the data pointer, the
header goes away as well. But here, the header is allocated separately
so that it's not free using , you can see it from printmem at ip.c:580
ret = grub_malloc (sizeof (*ret));
Now here's the tricky part, when i fix both problem, it actually when
you call this: (memdisk size is 19,180, just in case it matters).
testspeed /memdisk
So there must be a memory corruption somewhere. (It will not halt if
you skip the the second leak, but you can see the remaining buffer in
printmem).
BTW, you should add a grub_free_fragment call in testspeed to free the
rsm cache, just to make the printmem output a little cleaner.
These are the modules used to generate grub.efi, just in case it's relevant.
/grub-mkimage -d grub-core -o grub.efi -O x86_64-efi chain boot test
fat ntfs part_msdos normal ls echo efinet tftp http efinet reboot
testspeed printmem
--
Best wishes
Bean
[-- Attachment #2: test.txt --]
[-- Type: text/plain, Size: 3085 bytes --]
=== modified file 'grub-core/net/ip.c'
--- grub-core/net/ip.c 2012-02-09 22:43:43 +0000
+++ grub-core/net/ip.c 2012-05-01 18:28:59 +0000
@@ -240,7 +240,7 @@
FOR_NET_NETWORK_LEVEL_INTERFACES (inf)
if (inf->card == card
&& inf->address.type == GRUB_NET_NETWORK_LEVEL_PROTOCOL_DHCP_RECV
- && grub_net_hwaddr_cmp (&inf->hwaddress, hwaddress) == 0)
+ && inf->hwaddress.type == GRUB_NET_LINK_LEVEL_PROTOCOL_ETHERNET)
{
if (udph->chksum)
{
@@ -257,18 +257,25 @@
"Expected %x, got %x\n",
grub_be_to_cpu16 (expected),
grub_be_to_cpu16 (chk));
- grub_netbuff_free (nb);
- return GRUB_ERR_NONE;
+ break;
}
udph->chksum = chk;
}
err = grub_netbuff_pull (nb, sizeof (*udph));
if (err)
- return err;
- grub_net_process_dhcp (nb, inf->card);
- grub_netbuff_free (nb);
- return GRUB_ERR_NONE;
+ {
+ grub_netbuff_free (nb);
+ return err;
+ }
+ struct grub_net_bootp_packet *dhcp =
+ (struct grub_net_bootp_packet *) nb->data;
+ if (grub_memcmp(inf->hwaddress.mac, &dhcp->mac_addr,
+ sizeof(inf->hwaddress.mac)) == 0)
+ {
+ grub_net_process_dhcp (nb, inf->card);
+ break;
+ }
}
grub_netbuff_free (nb);
return GRUB_ERR_NONE;
@@ -344,19 +351,34 @@
}
grub_free (rsm->asm_buffer);
grub_priority_queue_destroy (rsm->pq);
+ grub_free (rsm);
}
static void
free_old_fragments (void)
{
- struct reassemble *rsm, **prev;
+ struct reassemble *rsm, **prev, *tmp;
grub_uint64_t limit_time = grub_get_time_ms () - 90000;
- for (prev = &reassembles, rsm = *prev; rsm; prev = &rsm->next, rsm = *prev)
+ for (prev = &reassembles, rsm = *prev; rsm;
+ prev = &rsm->next, rsm = *prev, free_rsm (tmp))
if (rsm->last_time < limit_time)
{
*prev = rsm->next;
- free_rsm (rsm);
+ tmp = rsm;
+ }
+}
+
+void
+grub_free_fragments (void)
+{
+ struct reassemble *rsm, **prev, *tmp;
+
+ for (prev = &reassembles, rsm = *prev; rsm;
+ prev = &rsm->next, rsm = *prev, free_rsm (tmp))
+ {
+ *prev = rsm->next;
+ tmp = rsm;
}
}
@@ -570,9 +592,14 @@
dest.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
dest.ipv4 = dst;
- return handle_dgram (ret, card, src_hwaddress,
- hwaddress, proto, &source, &dest,
- ttl);
+ {
+ grub_err_t result;
+ result = handle_dgram (ret, card, src_hwaddress,
+ hwaddress, proto, &source, &dest,
+ ttl);
+ grub_free (ret);
+ return result;
+ }
}
}
=== modified file 'grub-core/net/tftp.c'
--- grub-core/net/tftp.c 2012-02-12 18:11:06 +0000
+++ grub-core/net/tftp.c 2012-05-01 17:22:35 +0000
@@ -320,9 +320,9 @@
rrqlen += grub_strlen ("blksize") + 1;
rrq += grub_strlen ("blksize") + 1;
- grub_strcpy (rrq, "1024");
- rrqlen += grub_strlen ("1024") + 1;
- rrq += grub_strlen ("1024") + 1;
+ grub_strcpy (rrq, "4096");
+ rrqlen += grub_strlen ("4096") + 1;
+ rrq += grub_strlen ("4096") + 1;
grub_strcpy (rrq, "tsize");
rrqlen += grub_strlen ("tsize") + 1;
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Mysterious memory corruption bug
2012-05-01 18:53 Mysterious memory corruption bug Bean
@ 2012-05-01 19:08 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-05-01 19:46 ` Bean
0 siblings, 1 reply; 127+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2012-05-01 19:08 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]
On 01.05.2012 20:53, Bean wrote:
> Hi,
>
> Thanks to Vladimir's memory patch, it's actually quite easy to
> reproduce mysterious issue.
>
> First, there are two memory leaks in ip.c.
>
> It allocates the rsm but never frees it. free_rsm frees its content,
> but not the pointer itself. You can see it in printmem at ip.c:473
> rsm = grub_malloc (sizeof (*rsm));
>
> Another problem is at ip.c:594:
> return handle_dgram (ret, card, src_hwaddress,
> hwaddress, proto, &source, &dest,
> ttl);
> here, ret is netbuff. grub_netbuff_alloc get a buffer for both data
> and header (data go first), so when it frees the data pointer, the
> header goes away as well. But here, the header is allocated separately
> so that it's not free using , you can see it from printmem at ip.c:580
> ret = grub_malloc (sizeof (*ret));
>
> Now here's the tricky part, when i fix both problem, it actually when
> you call this: (memdisk size is 19,180, just in case it matters).
>
> testspeed /memdisk
>
> So there must be a memory corruption somewhere.
You can check for memory corruptions by calling grub_mm_check often
enough in the code.
> (It will not halt if
> you skip the the second leak, but you can see the remaining buffer in
> printmem).
>
> BTW, you should add a grub_free_fragment call in testspeed to free the
> rsm cache, just to make the printmem output a little cleaner.
>
> These are the modules used to generate grub.efi, just in case it's relevant.
>
> /grub-mkimage -d grub-core -o grub.efi -O x86_64-efi chain boot test
> fat ntfs part_msdos normal ls echo efinet tftp http efinet reboot
> testspeed printmem
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Mysterious memory corruption bug
2012-05-01 19:08 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2012-05-01 19:46 ` Bean
2012-05-01 19:52 ` Bean
0 siblings, 1 reply; 127+ messages in thread
From: Bean @ 2012-05-01 19:46 UTC (permalink / raw)
To: The development of GNU GRUB
On Wed, May 2, 2012 at 3:08 AM, Vladimir 'φ-coder/phcoder' Serbinenko
<phcoder@gmail.com> wrote:
> On 01.05.2012 20:53, Bean wrote:
>> Hi,
>>
>> Thanks to Vladimir's memory patch, it's actually quite easy to
>> reproduce mysterious issue.
>>
>> First, there are two memory leaks in ip.c.
>>
>> It allocates the rsm but never frees it. free_rsm frees its content,
>> but not the pointer itself. You can see it in printmem at ip.c:473
>> rsm = grub_malloc (sizeof (*rsm));
>>
>> Another problem is at ip.c:594:
>> return handle_dgram (ret, card, src_hwaddress,
>> hwaddress, proto, &source, &dest,
>> ttl);
>> here, ret is netbuff. grub_netbuff_alloc get a buffer for both data
>> and header (data go first), so when it frees the data pointer, the
>> header goes away as well. But here, the header is allocated separately
>> so that it's not free using , you can see it from printmem at ip.c:580
>> ret = grub_malloc (sizeof (*ret));
>>
>> Now here's the tricky part, when i fix both problem, it actually when
>> you call this: (memdisk size is 19,180, just in case it matters).
>>
>> testspeed /memdisk
>>
>> So there must be a memory corruption somewhere.
> You can check for memory corruptions by calling grub_mm_check often
> enough in the code.
Hi,
Thanks for the tip. But when I add a few grub_mm_check and printf here
and there, it doesn't halt any more. So this could be a memory
overflown issue or even compiler bug, very strange indeed.
--
Best wishes
Bean
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Mysterious memory corruption bug
2012-05-01 19:46 ` Bean
@ 2012-05-01 19:52 ` Bean
2012-05-01 19:56 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 1 reply; 127+ messages in thread
From: Bean @ 2012-05-01 19:52 UTC (permalink / raw)
To: The development of GNU GRUB
On Wed, May 2, 2012 at 3:46 AM, Bean <bean123ch@gmail.com> wrote:
> On Wed, May 2, 2012 at 3:08 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
>> On 01.05.2012 20:53, Bean wrote:
>>> Hi,
>>>
>>> Thanks to Vladimir's memory patch, it's actually quite easy to
>>> reproduce mysterious issue.
>>>
>>> First, there are two memory leaks in ip.c.
>>>
>>> It allocates the rsm but never frees it. free_rsm frees its content,
>>> but not the pointer itself. You can see it in printmem at ip.c:473
>>> rsm = grub_malloc (sizeof (*rsm));
>>>
>>> Another problem is at ip.c:594:
>>> return handle_dgram (ret, card, src_hwaddress,
>>> hwaddress, proto, &source, &dest,
>>> ttl);
>>> here, ret is netbuff. grub_netbuff_alloc get a buffer for both data
>>> and header (data go first), so when it frees the data pointer, the
>>> header goes away as well. But here, the header is allocated separately
>>> so that it's not free using , you can see it from printmem at ip.c:580
>>> ret = grub_malloc (sizeof (*ret));
>>>
>>> Now here's the tricky part, when i fix both problem, it actually when
>>> you call this: (memdisk size is 19,180, just in case it matters).
>>>
>>> testspeed /memdisk
>>>
>>> So there must be a memory corruption somewhere.
>> You can check for memory corruptions by calling grub_mm_check often
>> enough in the code.
>
> Hi,
>
> Thanks for the tip. But when I add a few grub_mm_check and printf here
> and there, it doesn't halt any more. So this could be a memory
> overflown issue or even compiler bug, very strange indeed.
Hi,
Well, actually it does halt with a larger file, so at least the
behavior is predictable.
--
Best wishes
Bean
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Mysterious memory corruption bug
2012-05-01 19:52 ` Bean
@ 2012-05-01 19:56 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-05-01 20:02 ` Bean
0 siblings, 1 reply; 127+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2012-05-01 19:56 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]
On 01.05.2012 21:52, Bean wrote:
> On Wed, May 2, 2012 at 3:46 AM, Bean <bean123ch@gmail.com> wrote:
>> On Wed, May 2, 2012 at 3:08 AM, Vladimir 'φ-coder/phcoder' Serbinenko
>> <phcoder@gmail.com> wrote:
>>> On 01.05.2012 20:53, Bean wrote:
>>>> Hi,
>>>>
>>>> Thanks to Vladimir's memory patch, it's actually quite easy to
>>>> reproduce mysterious issue.
>>>>
>>>> First, there are two memory leaks in ip.c.
>>>>
>>>> It allocates the rsm but never frees it. free_rsm frees its content,
>>>> but not the pointer itself. You can see it in printmem at ip.c:473
>>>> rsm = grub_malloc (sizeof (*rsm));
>>>>
>>>> Another problem is at ip.c:594:
>>>> return handle_dgram (ret, card, src_hwaddress,
>>>> hwaddress, proto, &source, &dest,
>>>> ttl);
>>>> here, ret is netbuff. grub_netbuff_alloc get a buffer for both data
>>>> and header (data go first), so when it frees the data pointer, the
>>>> header goes away as well. But here, the header is allocated separately
>>>> so that it's not free using , you can see it from printmem at ip.c:580
>>>> ret = grub_malloc (sizeof (*ret));
>>>>
>>>> Now here's the tricky part, when i fix both problem, it actually when
>>>> you call this: (memdisk size is 19,180, just in case it matters).
>>>>
>>>> testspeed /memdisk
>>>>
>>>> So there must be a memory corruption somewhere.
>>> You can check for memory corruptions by calling grub_mm_check often
>>> enough in the code.
>> Hi,
>>
>> Thanks for the tip. But when I add a few grub_mm_check and printf here
>> and there, it doesn't halt any more. So this could be a memory
>> overflown issue or even compiler bug, very strange indeed.
> Hi,
>
> Well, actually it does halt with a larger file, so at least the
> behavior is predictable.
Could you try to allocate the buffer for receive/send EFI calls only
once per card? It will result in needless copying but would solve few
DMA issues if network driver is badly coded.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Mysterious memory corruption bug
2012-05-01 19:56 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2012-05-01 20:02 ` Bean
2012-05-01 20:06 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 1 reply; 127+ messages in thread
From: Bean @ 2012-05-01 20:02 UTC (permalink / raw)
To: The development of GNU GRUB
On Wed, May 2, 2012 at 3:56 AM, Vladimir 'φ-coder/phcoder' Serbinenko
<phcoder@gmail.com> wrote:
> On 01.05.2012 21:52, Bean wrote:
>> On Wed, May 2, 2012 at 3:46 AM, Bean <bean123ch@gmail.com> wrote:
>>> On Wed, May 2, 2012 at 3:08 AM, Vladimir 'φ-coder/phcoder' Serbinenko
>>> <phcoder@gmail.com> wrote:
>>>> On 01.05.2012 20:53, Bean wrote:
>>>>> Hi,
>>>>>
>>>>> Thanks to Vladimir's memory patch, it's actually quite easy to
>>>>> reproduce mysterious issue.
>>>>>
>>>>> First, there are two memory leaks in ip.c.
>>>>>
>>>>> It allocates the rsm but never frees it. free_rsm frees its content,
>>>>> but not the pointer itself. You can see it in printmem at ip.c:473
>>>>> rsm = grub_malloc (sizeof (*rsm));
>>>>>
>>>>> Another problem is at ip.c:594:
>>>>> return handle_dgram (ret, card, src_hwaddress,
>>>>> hwaddress, proto, &source, &dest,
>>>>> ttl);
>>>>> here, ret is netbuff. grub_netbuff_alloc get a buffer for both data
>>>>> and header (data go first), so when it frees the data pointer, the
>>>>> header goes away as well. But here, the header is allocated separately
>>>>> so that it's not free using , you can see it from printmem at ip.c:580
>>>>> ret = grub_malloc (sizeof (*ret));
>>>>>
>>>>> Now here's the tricky part, when i fix both problem, it actually when
>>>>> you call this: (memdisk size is 19,180, just in case it matters).
>>>>>
>>>>> testspeed /memdisk
>>>>>
>>>>> So there must be a memory corruption somewhere.
>>>> You can check for memory corruptions by calling grub_mm_check often
>>>> enough in the code.
>>> Hi,
>>>
>>> Thanks for the tip. But when I add a few grub_mm_check and printf here
>>> and there, it doesn't halt any more. So this could be a memory
>>> overflown issue or even compiler bug, very strange indeed.
>> Hi,
>>
>> Well, actually it does halt with a larger file, so at least the
>> behavior is predictable.
> Could you try to allocate the buffer for receive/send EFI calls only
> once per card? It will result in needless copying but would solve few
> DMA issues if network driver is badly coded.
Hi,
Yeah, I have a patch that save the buffer for later use when there is
no data, it can solve the unnecessary alloc/free loop.
--
Best wishes
Bean
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Mysterious memory corruption bug
2012-05-01 20:02 ` Bean
@ 2012-05-01 20:06 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-05-01 20:09 ` Bean
0 siblings, 1 reply; 127+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2012-05-01 20:06 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
On 01.05.2012 22:02, Bean wrote:
> Hi,
>
> Yeah, I have a patch that save the buffer for later use when there is
> no data, it can solve the unnecessary alloc/free loop.
No, what I mean: allocate a buffer once for every card and then do
send/recv with only this buffer and copy to/from it when necessary. This
way if the card DMAs the packet to the same buffer it won't corrupt
anything.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Mysterious memory corruption bug
2012-05-01 20:06 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2012-05-01 20:09 ` Bean
2012-05-01 20:16 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 1 reply; 127+ messages in thread
From: Bean @ 2012-05-01 20:09 UTC (permalink / raw)
To: The development of GNU GRUB
On Wed, May 2, 2012 at 4:06 AM, Vladimir 'φ-coder/phcoder' Serbinenko
<phcoder@gmail.com> wrote:
> On 01.05.2012 22:02, Bean wrote:
>> Hi,
>>
>> Yeah, I have a patch that save the buffer for later use when there is
>> no data, it can solve the unnecessary alloc/free loop.
> No, what I mean: allocate a buffer once for every card and then do
> send/recv with only this buffer and copy to/from it when necessary. This
> way if the card DMAs the packet to the same buffer it won't corrupt
> anything.
Hi,
It's not ok with fragmentation, since there could be multiple ethernet
packet for an ip packet, we need to store the buffer for assembling.
--
Best wishes
Bean
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Mysterious memory corruption bug
2012-05-01 20:09 ` Bean
@ 2012-05-01 20:16 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-05-01 20:34 ` Bean
0 siblings, 1 reply; 127+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2012-05-01 20:16 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
On 01.05.2012 22:09, Bean wrote:
> On Wed, May 2, 2012 at 4:06 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
>> On 01.05.2012 22:02, Bean wrote:
>>> Hi,
>>>
>>> Yeah, I have a patch that save the buffer for later use when there is
>>> no data, it can solve the unnecessary alloc/free loop.
>> No, what I mean: allocate a buffer once for every card and then do
>> send/recv with only this buffer and copy to/from it when necessary. This
>> way if the card DMAs the packet to the same buffer it won't corrupt
>> anything.
> Hi,
>
> It's not ok with fragmentation, since there could be multiple ethernet
> packet for an ip packet, we need to store the buffer for assembling.
We use the buffer I said only for actual calls. It's copied to
newly-allocated packet as soon as the call returns.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Mysterious memory corruption bug
2012-05-01 20:16 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2012-05-01 20:34 ` Bean
2012-05-01 20:35 ` unsubscribe Daniel Senderowicz
0 siblings, 1 reply; 127+ messages in thread
From: Bean @ 2012-05-01 20:34 UTC (permalink / raw)
To: The development of GNU GRUB
On Wed, May 2, 2012 at 4:16 AM, Vladimir 'φ-coder/phcoder' Serbinenko
<phcoder@gmail.com> wrote:
> On 01.05.2012 22:09, Bean wrote:
>> On Wed, May 2, 2012 at 4:06 AM, Vladimir 'φ-coder/phcoder' Serbinenko
>> <phcoder@gmail.com> wrote:
>>> On 01.05.2012 22:02, Bean wrote:
>>>> Hi,
>>>>
>>>> Yeah, I have a patch that save the buffer for later use when there is
>>>> no data, it can solve the unnecessary alloc/free loop.
>>> No, what I mean: allocate a buffer once for every card and then do
>>> send/recv with only this buffer and copy to/from it when necessary. This
>>> way if the card DMAs the packet to the same buffer it won't corrupt
>>> anything.
>> Hi,
>>
>> It's not ok with fragmentation, since there could be multiple ethernet
>> packet for an ip packet, we need to store the buffer for assembling.
> We use the buffer I said only for actual calls. It's copied to
> newly-allocated packet as soon as the call returns.
Hi,
Yeah, after more thought, it's doable. We can use a ring buffer for
current active ip frames, and copy ethernet frame to it. This way we
can get rid of the rsm dynamic queue. It can also get rid of tons of
grub_netbuff_free scattered around in various layers.
--
Best wishes
Bean
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
2012-05-01 20:34 ` Bean
@ 2012-05-01 20:35 ` Daniel Senderowicz
2012-05-01 20:43 ` unsubscribe Gregg Levine
0 siblings, 1 reply; 127+ messages in thread
From: Daniel Senderowicz @ 2012-05-01 20:35 UTC (permalink / raw)
To: grub-devel; +Cc: daniel
[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]
Please unsubscribe
On Wed, 2012-05-02 at 04:34 +0800, Bean wrote:
> On Wed, May 2, 2012 at 4:16 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
> > On 01.05.2012 22:09, Bean wrote:
> >> On Wed, May 2, 2012 at 4:06 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> >> <phcoder@gmail.com> wrote:
> >>> On 01.05.2012 22:02, Bean wrote:
> >>>> Hi,
> >>>>
> >>>> Yeah, I have a patch that save the buffer for later use when there is
> >>>> no data, it can solve the unnecessary alloc/free loop.
> >>> No, what I mean: allocate a buffer once for every card and then do
> >>> send/recv with only this buffer and copy to/from it when necessary. This
> >>> way if the card DMAs the packet to the same buffer it won't corrupt
> >>> anything.
> >> Hi,
> >>
> >> It's not ok with fragmentation, since there could be multiple ethernet
> >> packet for an ip packet, we need to store the buffer for assembling.
> > We use the buffer I said only for actual calls. It's copied to
> > newly-allocated packet as soon as the call returns.
>
> Hi,
>
> Yeah, after more thought, it's doable. We can use a ring buffer for
> current active ip frames, and copy ethernet frame to it. This way we
> can get rid of the rsm dynamic queue. It can also get rid of tons of
> grub_netbuff_free scattered around in various layers.
>
[-- Attachment #2: Type: text/html, Size: 1839 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: unsubscribe
2012-05-01 20:35 ` unsubscribe Daniel Senderowicz
@ 2012-05-01 20:43 ` Gregg Levine
0 siblings, 0 replies; 127+ messages in thread
From: Gregg Levine @ 2012-05-01 20:43 UTC (permalink / raw)
To: The development of GNU GRUB; +Cc: daniel
On Tue, May 1, 2012 at 4:35 PM, Daniel Senderowicz
<daniel@synchrodesign.com> wrote:
> Please unsubscribe
>
> On Wed, 2012-05-02 at 04:34 +0800, Bean wrote:
>
> On Wed, May 2, 2012 at 4:16 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
>> On 01.05.2012 22:09, Bean wrote:
>>> On Wed, May 2, 2012 at 4:06 AM, Vladimir 'φ-coder/phcoder' Serbinenko
>>> <phcoder@gmail.com> wrote:
>>>> On 01.05.2012 22:02, Bean wrote:
>>>>> Hi,
>>>>>
>>>>> Yeah, I have a patch that save the buffer for later use when there is
>>>>> no data, it can solve the unnecessary alloc/free loop.
>>>> No, what I mean: allocate a buffer once for every card and then do
>>>> send/recv with only this buffer and copy to/from it when necessary. This
>>>> way if the card DMAs the packet to the same buffer it won't corrupt
>>>> anything.
>>> Hi,
>>>
>>> It's not ok with fragmentation, since there could be multiple ethernet
>>> packet for an ip packet, we need to store the buffer for assembling.
>> We use the buffer I said only for actual calls. It's copied to
>> newly-allocated packet as soon as the call returns.
>
> Hi,
>
> Yeah, after more thought, it's doable. We can use a ring buffer for
> current active ip frames, and copy ethernet frame to it. This way we
> can get rid of the rsm dynamic queue. It can also get rid of tons of
> grub_netbuff_free scattered around in various layers.
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
Hello!
Daniel should you really want to do this, please do not send such
messages to the list. Please make use of the header. There you will
find methods to leave this wonderful list.
-----
Gregg C Levine gregg.drwho8@gmail.com
"This signature fought the Time Wars, time and again."
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2011-11-14 17:26 Tietz Fabian (AA-DG/PAS-ESD2)
0 siblings, 0 replies; 127+ messages in thread
From: Tietz Fabian (AA-DG/PAS-ESD2) @ 2011-11-14 17:26 UTC (permalink / raw)
To: linuxppc-dev
unsubscribe
^ permalink raw reply [flat|nested] 127+ messages in thread
* Unsubscribe
@ 2011-02-28 2:25 Tomasz Fujak
0 siblings, 0 replies; 127+ messages in thread
From: Tomasz Fujak @ 2011-02-28 2:25 UTC (permalink / raw)
To: linux-arm-kernel
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110228/e9c6dffe/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 201102281125718_QKNMBDIF.gif
Type: image/gif
Size: 9524 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110228/e9c6dffe/attachment.gif>
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2011-01-06 17:42 marduk
0 siblings, 0 replies; 127+ messages in thread
From: marduk @ 2011-01-06 17:42 UTC (permalink / raw)
To: kernelnewbies
unsubscribe kernelnewbies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110106/4fcfedd9/attachment.html
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2010-11-03 8:21 Roberto Mantovani
0 siblings, 0 replies; 127+ messages in thread
From: Roberto Mantovani @ 2010-11-03 8:21 UTC (permalink / raw)
To: linuxppc-dev
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2010-10-19 8:51 Roberto Mantovani
0 siblings, 0 replies; 127+ messages in thread
From: Roberto Mantovani @ 2010-10-19 8:51 UTC (permalink / raw)
To: Linuxppc-dev
--
Roberto Mantovani <rmantovani@automazionelogistica.it>
A&L srl - Automazione e Logistica www.automazionelogistica.it
Via Lidice, 20
40139 Bologna
Cap Sociale € 10.000 I.V.
C.F., P.IVA e registro imprese di Bologna N.02296311208
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2010-07-17 11:30 aiolos.cis90
0 siblings, 0 replies; 127+ messages in thread
From: aiolos.cis90 @ 2010-07-17 11:30 UTC (permalink / raw)
To: linuxppc-dev
unsubscribe
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2010-06-23 14:33 Frederic LEGER
0 siblings, 0 replies; 127+ messages in thread
From: Frederic LEGER @ 2010-06-23 14:33 UTC (permalink / raw)
To: linuxppc-dev
unsubscribe
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-11-27 23:26 Gao Ya'nan
2009-11-28 17:02 ` unsubscribe Thomas Rinder
0 siblings, 1 reply; 127+ messages in thread
From: Gao Ya'nan @ 2009-11-27 23:26 UTC (permalink / raw)
To: linuxppc-dev
unsubscribe
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-02-04 13:48 Bietry, Ray
0 siblings, 0 replies; 127+ messages in thread
From: Bietry, Ray @ 2009-02-04 13:48 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 5 bytes --]
[-- Attachment #2: Type: text/html, Size: 1096 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-02-04 13:19 ravi.rao
0 siblings, 0 replies; 127+ messages in thread
From: ravi.rao @ 2009-02-04 13:19 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
Ravishankar Govindarao
RFL Electronics Inc.
E-mail : Ravi.Rao@rflelect.com
Voice: 973.334.3100 Ext. 233
Fax: 973.334.3863
CONFIDENTIALITY NOTE
This e-mail, including any attachments, may contain confidential and/or
legally privileged information. The Information is intended only for the
use of the individual or entity named on this e-mail . If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or the taking of any action in reliance on the contents of
this transmitted Information is strictly prohibited. Further, if you are
not the intended recipient, please notify us by return e-mail and delete
the Information promptly.
[-- Attachment #2: Type: text/html, Size: 1352 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-02-04 8:11 Usha Rani Konudula
0 siblings, 0 replies; 127+ messages in thread
From: Usha Rani Konudula @ 2009-02-04 8:11 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 5 bytes --]
[-- Attachment #2: Type: text/html, Size: 3952 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-24 21:46 Hai Zhu
0 siblings, 0 replies; 127+ messages in thread
From: Hai Zhu @ 2009-01-24 21:46 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 20 bytes --]
unsubscribe
[-- Attachment #2: Type: text/html, Size: 136 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Unsubscribe
@ 2009-01-13 5:02 shreeram
0 siblings, 0 replies; 127+ messages in thread
From: shreeram @ 2009-01-13 5:02 UTC (permalink / raw)
To: Linuxppc-dev
--
-_-
.
Regards,
R.S.Shree Ram
GDA Technologies Ltd.
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-12 8:29 Kunkel, Ulrich
0 siblings, 0 replies; 127+ messages in thread
From: Kunkel, Ulrich @ 2009-01-12 8:29 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]
I wish to unsubscribe from this list.
Best Regards,
Mit freundlichen Grüßen / Best regards
Ulrich Kunkel
Produktlinie Testing Abteilung T-GE
Hottinger Baldwin Messtechnik GmbH
Fax: +49 6151-803524
E-Mail: ulrich.kunkel@hbm.com <blocked::mailto:v@hbm.com>
Internet: www.hbm.com <blocked::http://www.hbm.com/>
Die in dieser E-Mail enthaltene Information ist vertraulich und lediglich für den Empfänger bestimmt. Sollten Sie nicht der eigentliche Empfänger sein, informieren Sie mich bitte kurz und löschen diese E-Mail.
Hottinger Baldwin Messtechnik GmbH, Im Tiefen See 45, 64293 Darmstadt, Germany | www.hbm.com
Registered as GmbH (German limited liability corporation) in the commercial register at the local court of Darmstadt, HRB 1147
Company domiciled in Darmstadt | CEO: Andreas Huellhorst | Chairman of the board: James Charles Webster
Als Gesellschaft mit beschraenkter Haftung eingetragen im Handelsregister des Amtsgerichts Darmstadt unter HRB 1147
Sitz der Gesellschaft: Darmstadt | Geschaeftsfuehrung: Andreas Huellhorst | Aufsichtsratsvorsitzender: James Charles Webster
The information in this email is confidential. It is intended solely for the addressee. If you are not the intended recipient, please let me know and delete this email.
Die in dieser E-Mail enthaltene Information ist vertraulich und lediglich für den Empfaenger bestimmt. Sollten Sie nicht der eigentliche Empfaenger sein, informieren Sie mich bitte kurz und loeschen diese E-Mail.
[-- Attachment #2: Type: text/html, Size: 4683 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-12 5:49 zhou.yutao
2009-01-12 9:06 ` unsubscribe Geert Uytterhoeven
0 siblings, 1 reply; 127+ messages in thread
From: zhou.yutao @ 2009-01-12 5:49 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 848 bytes --]
深圳中兴力维技术有限公司
地址:深圳市高新区科技南一路W1-A二楼
电话:0755-26525674-8509(办公室)
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
[-- Attachment #2: Type: text/html, Size: 1467 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: unsubscribe
2009-01-12 5:49 unsubscribe zhou.yutao
@ 2009-01-12 9:06 ` Geert Uytterhoeven
0 siblings, 0 replies; 127+ messages in thread
From: Geert Uytterhoeven @ 2009-01-12 9:06 UTC (permalink / raw)
To: zhou.yutao; +Cc: Linuxppc-dev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 1448 bytes --]
On Mon, 12 Jan 2009, zhou.yutao@zte.com.cn wrote:
> ÉîÛÚÖÐÐËÁ¦Î¬¼¼ÊõÓÐÏÞ¹«Ë¾
> µØÖ·£ºÉîÛÚÊиßÐÂÇø¿Æ¼¼ÄÏһ·W1-A¶þÂ¥
> µç»°£º0755-26525674-8509£¨°ì¹«ÊÒ£©
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
Now I understand why people don't read unsubscription info on mailing list.
They don't read their own signatures ;-)
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-11 19:25 rsterling
2009-01-12 4:39 ` unsubscribe sandeep malik
2009-01-12 12:56 ` unsubscribe ravi.rao
0 siblings, 2 replies; 127+ messages in thread
From: rsterling @ 2009-01-11 19:25 UTC (permalink / raw)
To: Linuxppc-dev
unsubscribe
please
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
2009-01-11 19:25 unsubscribe rsterling
@ 2009-01-12 4:39 ` sandeep malik
2009-01-12 12:56 ` unsubscribe ravi.rao
1 sibling, 0 replies; 127+ messages in thread
From: sandeep malik @ 2009-01-12 4:39 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 265 bytes --]
unsubscribe
please
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Check out the all-new Messenger 9.0! Go to http://in.messenger.yahoo.com/
[-- Attachment #2: Type: text/html, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
2009-01-11 19:25 unsubscribe rsterling
2009-01-12 4:39 ` unsubscribe sandeep malik
@ 2009-01-12 12:56 ` ravi.rao
2009-01-12 13:43 ` unsubscribe Rajasekaran Kaliyaperumal, Chennai
1 sibling, 1 reply; 127+ messages in thread
From: ravi.rao @ 2009-01-12 12:56 UTC (permalink / raw)
To: rsterling; +Cc: Linuxppc-dev, linuxppc-dev-bounces+ravi.rao=rflelect.com
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
unsubscribe
please
Ravishankar Govindarao
RFL Electronics Inc.
E-mail : Ravi.Rao@rflelect.com
Voice: 973.334.3100 Ext. 233
Fax: 973.334.3863
CONFIDENTIALITY NOTE
This e-mail, including any attachments, may contain confidential and/or
legally privileged information. The Information is intended only for the
use of the individual or entity named on this e-mail . If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or the taking of any action in reliance on the contents of
this transmitted Information is strictly prohibited. Further, if you are
not the intended recipient, please notify us by return e-mail and delete
the Information promptly.
rsterling@ssl.berkeley.edu
Sent by: linuxppc-dev-bounces+ravi.rao=rflelect.com@ozlabs.org
01/11/2009 02:25 PM
To
Linuxppc-dev@ozlabs.org
cc
Subject
unsubscribe
unsubscribe
please
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 2544 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* RE: unsubscribe
2009-01-12 12:56 ` unsubscribe ravi.rao
@ 2009-01-12 13:43 ` Rajasekaran Kaliyaperumal, Chennai
0 siblings, 0 replies; 127+ messages in thread
From: Rajasekaran Kaliyaperumal, Chennai @ 2009-01-12 13:43 UTC (permalink / raw)
To: ravi.rao, rsterling
Cc: Linuxppc-dev, linuxppc-dev-bounces+ravi.rao=rflelect.com
[-- Attachment #1: Type: text/plain, Size: 2652 bytes --]
unsubscribe
please
________________________________
From: linuxppc-dev-bounces+rajasekaran.k=hcl.in@ozlabs.org
[mailto:linuxppc-dev-bounces+rajasekaran.k=hcl.in@ozlabs.org] On Behalf
Of ravi.rao@rflelect.com
Sent: Monday, January 12, 2009 6:26 PM
To: rsterling@ssl.berkeley.edu
Cc: Linuxppc-dev@ozlabs.org;
linuxppc-dev-bounces+ravi.rao=rflelect.com@ozlabs.org
Subject: unsubscribe
unsubscribe
please
Ravishankar Govindarao
RFL Electronics Inc.
E-mail : Ravi.Rao@rflelect.com <mailto:Ravi.Rao@rflelect.com>
Voice: 973.334.3100 Ext. 233
Fax: 973.334.3863
CONFIDENTIALITY NOTE
This e-mail, including any attachments, may contain confidential and/or
legally privileged information. The Information is intended only for
the use of the individual or entity named on this e-mail . If you are
not the intended recipient, you are hereby notified that any disclosure,
copying, distribution, or the taking of any action in reliance on the
contents of this transmitted Information is strictly prohibited.
Further, if you are not the intended recipient, please notify us by
return e-mail and delete the Information promptly.
rsterling@ssl.berkeley.edu
Sent by: linuxppc-dev-bounces+ravi.rao=rflelect.com@ozlabs.org
01/11/2009 02:25 PM
To
Linuxppc-dev@ozlabs.org
cc
Subject
unsubscribe
unsubscribe
please
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
<https://ozlabs.org/mailman/listinfo/linuxppc-dev>
DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.
-----------------------------------------------------------------------------------------------------------------------
[-- Attachment #2: Type: text/html, Size: 11493 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Unsubscribe
@ 2009-01-11 17:38 Nadav Sharabi
2009-01-12 4:49 ` Unsubscribe Wei Jack
0 siblings, 1 reply; 127+ messages in thread
From: Nadav Sharabi @ 2009-01-11 17:38 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 72 bytes --]
Hi,
I wish to unsubscribe from this list.
Best Regards,
Nadav Sharabi
[-- Attachment #2: Type: text/html, Size: 112 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-11 10:02 Ignacio Vara
2009-01-11 16:13 ` unsubscribe List
0 siblings, 1 reply; 127+ messages in thread
From: Ignacio Vara @ 2009-01-11 10:02 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 13 bytes --]
unsubscribe
[-- Attachment #2: Type: text/html, Size: 1552 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-08 2:45 Yedu Jathavedan
0 siblings, 0 replies; 127+ messages in thread
From: Yedu Jathavedan @ 2009-01-08 2:45 UTC (permalink / raw)
To: Linuxppc-dev
unsubscribe
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-07 17:21 rsterling
0 siblings, 0 replies; 127+ messages in thread
From: rsterling @ 2009-01-07 17:21 UTC (permalink / raw)
To: Linuxppc-dev
unsubscribe
---------------------------------------
Rick Sterling
Space Sciences Laboratory
University of California, Berkeley
510.642.6149
rsterling@ssl.berkeley.edu
---------------------------------------
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-07 17:12 Wei Jack
0 siblings, 0 replies; 127+ messages in thread
From: Wei Jack @ 2009-01-07 17:12 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 159 bytes --]
unsubscribe
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 341 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-07 16:00 neeraj garg
0 siblings, 0 replies; 127+ messages in thread
From: neeraj garg @ 2009-01-07 16:00 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 12 bytes --]
unsubscribe
[-- Attachment #2: Type: text/html, Size: 12 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* mpc5200 ATA DMA
@ 2009-01-07 7:23 Peter Czanik
2009-01-07 7:58 ` Unsubscribe Landau, Bracha
0 siblings, 1 reply; 127+ messages in thread
From: Peter Czanik @ 2009-01-07 7:23 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I did a few tests this morning with the new DMA code on the EFIKA and
got the following results:
- libata.force=udma2
SCSI subsystem
initialized
ata: MPC52xx IDE/ATA libata
driver
scsi0 :
mpc52xx_ata
ata1: PATA max PIO4 ata_regs 0xf0003a00 irq
135
ata1.00: ATA-6: ST980815A, 3.ALD, max
UDMA/100
ata1.00: 156301488 sectors, multi 0:
LBA48
ata1.00: FORCE: xfer_mask set to
udma2
ata1.00: configured for
UDMA/33
scsi 0:0:0:0: Direct-Access ATA ST980815A 3.AL PQ: 0
ANSI: 5
Creating device nodes with
udev
udevd version 128
started
ppc-of-ohci f0001000.usb: OF
OHCI
ppc-of-ohci f0001000.usb: new USB bus registered, assigned bus number
1
ppc-of-ohci f0001000.usb: irq 134, io mem
0xf0001000
usb usb1: configuration #1 chosen from 1
choice
hub 1-0:1.0: USB hub
found
hub 1-0:1.0: 2 ports
detected
usb usb1: New USB device found, idVendor=1d6b,
idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
usb usb1: Product: OF
OHCI
usb usb1: Manufacturer: Linux 2.6.27.7-99.1-genesi
ohci_hcd
usb usb1: SerialNumber: PPC-OF
USB
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors:
(80.0GB/74.5GiB)
sd 0:0:0:0: [sda] Write Protect is
off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors:
(80.0GB/74.5GiB)
sd 0:0:0:0: [sda] Write Protect is
off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda:
After the udevadm settle timeout, the events queue
contains:
304:
/devices/f0000000.builtin/f0003a00.ata/host0/target0:0:0/0:0:0:0
305:
/devices/f0000000.builtin/f0003a00.ata/host0/target0:0:0/0:0:0:0/bsg/0:0:0:0
306:
/devices/f0000000.builtin/f0003a00.ata/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0
427:
/devices/f0000000.builtin/f0003a00.ata/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0
Boot logging started on /dev/ttyPSC0(/dev/console) at Wed Jan 7
06:58:13 2009
<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY
}
ata1: soft resetting
link
ata1.00: revalidation failed
(errno=-2)
ata1: soft resetting
link
ata1.00: revalidation failed
(errno=-2)
ata1: soft resetting
link
ata1.00: revalidation failed
(errno=-2)
ata1.00:
disabled
ata1: soft resetting
link
ata1: EH
complete
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
ldm_validate_partition_table(): Disk read
failed.
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
Dev sda: unable to read RDB block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block 0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 24
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 24
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
unable to read partition table
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
Waiting for device /dev/sda11 to appear:
..............................Could not find /dev/sda11.
Want me to fall back to /dev/sda11? (Y/n)
- libata.force=mwdma2 is just about the same:
scsi0 :
mpc52xx_ata
ata1: PATA max PIO4 ata_regs 0xf0003a00 irq
135
ata1.00: ATA-6: ST980815A, 3.ALD, max
UDMA/100
ata1.00: 156301488 sectors, multi 0:
LBA48
ata1.00: FORCE: xfer_mask set to
mwdma2
ata1.00: configured for
MWDMA2
scsi 0:0:0:0: Direct-Access ATA ST980815A 3.AL PQ: 0
ANSI: 5
Creating device nodes with
udev
udevd version 128
started
ppc-of-ohci f0001000.usb: OF
OHCI
ppc-of-ohci f0001000.usb: new USB bus registered, assigned bus number
1
ppc-of-ohci f0001000.usb: irq 134, io mem
0xf0001000
usb usb1: configuration #1 chosen from 1
choice
hub 1-0:1.0: USB hub
found
hub 1-0:1.0: 2 ports
detected
usb usb1: New USB device found, idVendor=1d6b,
idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
usb usb1: Product: OF
OHCI
usb usb1: Manufacturer: Linux 2.6.27.7-99.1-genesi
ohci_hcd
usb usb1: SerialNumber: PPC-OF
USB
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors:
(80.0GB/74.5GiB)
sd 0:0:0:0: [sda] Write Protect is
off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors:
(80.0GB/74.5GiB)
sd 0:0:0:0: [sda] Write Protect is
off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda:
After the udevadm settle timeout, the events queue
contains:
304:
/devices/f0000000.builtin/f0003a00.ata/host0/target0:0:0/0:0:0:0
305:
/devices/f0000000.builtin/f0003a00.ata/host0/target0:0:0/0:0:0:0/bsg/0:0:0:0
306:
/devices/f0000000.builtin/f0003a00.ata/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0
427:
/devices/f0000000.builtin/f0003a00.ata/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0
Boot logging started on /dev/ttyPSC0(/dev/console) at Wed Jan 7
07:05:50 2009
<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY
}
ata1: soft resetting
link
ata1.00: revalidation failed
(errno=-2)
ata1: soft resetting
link
ata1.00: revalidation failed
(errno=-2)
ata1: soft resetting
link
ata1.00: revalidation failed
(errno=-2)
ata1.00:
disabled
ata1: soft resetting
link
ata1: EH
complete
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
ldm_validate_partition_table(): Disk read
failed.
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
Dev sda: unable to read RDB block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block 0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 24
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 24
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
unable to read partition table
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
Waiting for device /dev/sda11 to appear:
..............................Could not find /dev/sda11.
Want me to fall back to /dev/sda11? (Y/n)
- just as libata.force=mwdma1
SCSI subsystem
initialized
ata: MPC52xx IDE/ATA libata
driver
scsi0 :
mpc52xx_ata
ata1: PATA max PIO4 ata_regs 0xf0003a00 irq
135
ata1.00: ATA-6: ST980815A, 3.ALD, max
UDMA/100
ata1.00: 156301488 sectors, multi 0:
LBA48
ata1.00: FORCE: xfer_mask set to
mwdma1
ata1.00: configured for
MWDMA1
scsi 0:0:0:0: Direct-Access ATA ST980815A 3.AL PQ: 0
ANSI: 5
Creating device nodes with
udev
udevd version 128
started
ppc-of-ohci f0001000.usb: OF
OHCI
ppc-of-ohci f0001000.usb: new USB bus registered, assigned bus number
1
ppc-of-ohci f0001000.usb: irq 134, io mem
0xf0001000
usb usb1: configuration #1 chosen from 1
choice
hub 1-0:1.0: USB hub
found
hub 1-0:1.0: 2 ports
detected
usb usb1: New USB device found, idVendor=1d6b,
idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
usb usb1: Product: OF
OHCI
usb usb1: Manufacturer: Linux 2.6.27.7-99.1-genesi
ohci_hcd
usb usb1: SerialNumber: PPC-OF
USB
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors:
(80.0GB/74.5GiB)
sd 0:0:0:0: [sda] Write Protect is
off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors:
(80.0GB/74.5GiB)
sd 0:0:0:0: [sda] Write Protect is
off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda:
After the udevadm settle timeout, the events queue
contains:
304:
/devices/f0000000.builtin/f0003a00.ata/host0/target0:0:0/0:0:0:0
305:
/devices/f0000000.builtin/f0003a00.ata/host0/target0:0:0/0:0:0:0/bsg/0:0:0:0
306:
/devices/f0000000.builtin/f0003a00.ata/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0
427:
/devices/f0000000.builtin/f0003a00.ata/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0
Boot logging started on /dev/ttyPSC0(/dev/console) at Wed Jan 7
07:09:38 2009
<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096
in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
(timeout)
ata1.00: status: { DRDY
}
ata1: soft resetting
link
ata1.00: revalidation failed
(errno=-2)
ata1: soft resetting
link
ata1.00: revalidation failed
(errno=-2)
ata1: soft resetting
link
ata1.00: revalidation failed
(errno=-2)
ata1.00:
disabled
ata1: soft resetting
link
ata1: EH
complete
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
ldm_validate_partition_table(): Disk read
failed.
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block
0
Dev sda: unable to read RDB block
0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector
0
Buffer I/O error on device sda, logical block 0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 24
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 24
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
unable to read partition table
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 0
Waiting for device /dev/sda11 to appear:
..............................Could not find /dev/sda11.
Want me to fall back to /dev/sda11? (Y/n)
- no kernel parameters: no trouble at all
SCSI subsystem
initialized
ata: MPC52xx IDE/ATA libata
driver
scsi0 :
mpc52xx_ata
ata1: PATA max PIO4 ata_regs 0xf0003a00 irq
135
ata1.00: ATA-6: ST980815A, 3.ALD, max
UDMA/100
ata1.00: 156301488 sectors, multi 0:
LBA48
ata1.00: configured for
PIO4
scsi 0:0:0:0: Direct-Access ATA ST980815A 3.AL PQ: 0
ANSI: 5
Creating device nodes with
udev
udevd version 128
started
ppc-of-ohci f0001000.usb: OF
OHCI
ppc-of-ohci f0001000.usb: new USB bus registered, assigned bus number
1
ppc-of-ohci f0001000.usb: irq 134, io mem
0xf0001000
usb usb1: configuration #1 chosen from 1
choice
hub 1-0:1.0: USB hub
found
hub 1-0:1.0: 2 ports
detected
usb usb1: New USB device found, idVendor=1d6b,
idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
usb usb1: Product: OF
OHCI
usb usb1: Manufacturer: Linux 2.6.27.7-99.1-genesi
ohci_hcd
usb usb1: SerialNumber: PPC-OF
USB
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors:
(80.0GB/74.5GiB)
sd 0:0:0:0: [sda] Write Protect is
off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors:
(80.0GB/74.5GiB)
sd 0:0:0:0: [sda] Write Protect is
off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: RDSK (512) sda1 (LNX^@)(res 2 spb 1) sda2 (SWP^@)(res 2 spb 1)
sda3 (EXT^C)(res 2 spb 1) sda4)
sd 0:0:0:0: [sda] Attached SCSI
disk
Boot logging started on /dev/ttyPSC0(/dev/console) at Wed Jan 7
07:19:21 2009
Waiting for device /dev/sda11 to appear:
ok
fsck 1.41.1
(01-Sep-2008)
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a
/dev/sda11
/dev/sda11: clean, 100696/429088 files, 569041/1714938
blocks
fsck succeeded. Mounting root device
read-write.
Mounting root
/dev/sda11
Bye,
CzP
^ permalink raw reply [flat|nested] 127+ messages in thread
* Unsubscribe
2009-01-07 7:23 mpc5200 ATA DMA Peter Czanik
@ 2009-01-07 7:58 ` Landau, Bracha
0 siblings, 0 replies; 127+ messages in thread
From: Landau, Bracha @ 2009-01-07 7:58 UTC (permalink / raw)
To: linuxppc-dev
This e-mail is confidential, the property of NDS Ltd and intended for the a=
ddressee only. Any dissemination, copying or distribution of this message o=
r any attachments by anyone other than the intended recipient is strictly p=
rohibited. If you have received this message in error, please immediately n=
otify the postmaster@nds.com and destroy the original message. Messages sen=
t to and from NDS may be monitored. NDS cannot guarantee any message delive=
ry method is secure or error-free. Information could be intercepted, corrup=
ted, lost, destroyed, arrive late or incomplete, or contain viruses. We do =
not accept responsibility for any errors or omissions in this message and/o=
r attachment that arise as a result of transmission. You should carry out y=
our own virus checks before opening any attachment. Any views or opinions p=
resented are solely those of the author and do not necessarily represent th=
ose of NDS.
To protect the environment please do not print this e-mail unless necessary=
.
NDS Limited Registered office: One Heathrow Boulevard, 286 Bath Road, West =
Drayton, Middlesex, UB7 0DQ, United Kingdom. A company registered in Englan=
d and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-07 6:37 santhoshunnikrishnan
2009-01-07 7:27 ` unsubscribe Rustagi, Vikas
2009-01-07 15:32 ` unsubscribe Sungjoo Kim
0 siblings, 2 replies; 127+ messages in thread
From: santhoshunnikrishnan @ 2009-01-07 6:37 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 460 bytes --]
Please unsubscribe me, thanks!
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.
[-- Attachment #1.2: Type: text/html, Size: 808 bytes --]
[-- Attachment #2: ATT00043.txt --]
[-- Type: text/plain, Size: 146 bytes --]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 127+ messages in thread
* RE: unsubscribe
2009-01-07 6:37 unsubscribe santhoshunnikrishnan
@ 2009-01-07 7:27 ` Rustagi, Vikas
2009-01-07 15:32 ` unsubscribe Sungjoo Kim
1 sibling, 0 replies; 127+ messages in thread
From: Rustagi, Vikas @ 2009-01-07 7:27 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
Please unsubscribe me...thanks
DISCLAIMER:
Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you.
[-- Attachment #2: Type: text/html, Size: 1117 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: unsubscribe
2009-01-07 6:37 unsubscribe santhoshunnikrishnan
2009-01-07 7:27 ` unsubscribe Rustagi, Vikas
@ 2009-01-07 15:32 ` Sungjoo Kim
1 sibling, 0 replies; 127+ messages in thread
From: Sungjoo Kim @ 2009-01-07 15:32 UTC (permalink / raw)
To: Linuxppc-dev; +Cc: santhoshunnikrishnan
[-- Attachment #1: Type: text/plain, Size: 802 bytes --]
Please unsubscribe me too, thanks!!
santhoshunnikrishnan@tataelxsi.co.in wrote:
>
> Please unsubscribe me, thanks!
>
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately and destroy all copies of this message and any attachments
> contained in it.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 1568 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-07 2:23 pravin
0 siblings, 0 replies; 127+ messages in thread
From: pravin @ 2009-01-07 2:23 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: Type: text/html, Size: 113 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Unsubscribe
@ 2009-01-05 23:48 JeongIn Choi
0 siblings, 0 replies; 127+ messages in thread
From: JeongIn Choi @ 2009-01-05 23:48 UTC (permalink / raw)
Cc: Frank Lautenbach, Linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 2493 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
[parent not found: <43FB4790A017E847A47C1D1FD108904E017B7C12@EXVBE011-1.exch011.int ermedia.net>]
* unsubscribe
@ 2009-01-05 21:58 Iain Shewring
0 siblings, 0 replies; 127+ messages in thread
From: Iain Shewring @ 2009-01-05 21:58 UTC (permalink / raw)
To: Linuxppc-dev
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-05 21:32 Jim Rose
2009-01-05 21:49 ` unsubscribe Nate Jozwiak
0 siblings, 1 reply; 127+ messages in thread
From: Jim Rose @ 2009-01-05 21:32 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2 bytes --]
[-- Attachment #2: Type: text/html, Size: 1096 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-05 18:03 Leonid
2009-01-05 19:06 ` unsubscribe Nitesh Guinde
0 siblings, 1 reply; 127+ messages in thread
From: Leonid @ 2009-01-05 18:03 UTC (permalink / raw)
To: Linuxppc-dev
Please unsubscribe me from this list.
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2009-01-05 13:09 P Jagadeesh Maiya
0 siblings, 0 replies; 127+ messages in thread
From: P Jagadeesh Maiya @ 2009-01-05 13:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: Type: text/html, Size: 289 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* UNSUBSCRIBE
@ 2009-01-05 8:41 Arun Kumar
0 siblings, 0 replies; 127+ messages in thread
From: Arun Kumar @ 2009-01-05 8:41 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 245 bytes --]
>
> kindly unsubscribe me from this mailing list.
>
--
Best Regards,
Arun
" Not in imagined futures
Or in remembered pasts
But only here and only now
Will you find a peace that lasts "
[-- Attachment #2: Type: text/html, Size: 668 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Unsubscribe
@ 2009-01-05 4:32 Narendra KA
2009-01-05 4:33 ` Unsubscribe Steve Iribarne (GMail)
0 siblings, 1 reply; 127+ messages in thread
From: Narendra KA @ 2009-01-05 4:32 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 95 bytes --]
Hi,
can you please unsubscribe me from this mailing list?
Thanks and Regards,
Narendra K.A
[-- Attachment #2: Type: text/html, Size: 448 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Unsubscribe
2009-01-05 4:32 Unsubscribe Narendra KA
@ 2009-01-05 4:33 ` Steve Iribarne (GMail)
2009-01-06 7:39 ` Unsubscribe Tore Martin Hagen
0 siblings, 1 reply; 127+ messages in thread
From: Steve Iribarne (GMail) @ 2009-01-05 4:33 UTC (permalink / raw)
To: Narendra KA; +Cc: Linuxppc-dev
HOLLY CRAP everyone.. please read at the bottom of these emails to
figure out how to unsubscribe. This is ridiculous!
Towards the bottom of the
"https://ozlabs.org/mailman/listinfo/linuxppc-dev" page there is
simple place you put your f'ing email address and hit "Unsubscribe or
edit options".
That's why we put it there... so you could do it and we wouldn't have
to do any of it.
Please quit sending emails asking someone to do something for you.
Sorry for the spam, but I'm hung over from new years and in a bad mood
and this was the email that sent me over the top. No ill will towards
you Narendra.
-stv
On Sun, Jan 4, 2009 at 8:32 PM, Narendra KA <Narendra.KA@lntemsys.com> wrote:
>
>
> Hi,
>
> can you please unsubscribe me from this mailing list?
>
> Thanks and Regards,
> Narendra K.A
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
/*
* Steve Iribarne
* Software Engineer
* (aka Grunt)
*/
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Unsubscribe
2009-01-05 4:33 ` Unsubscribe Steve Iribarne (GMail)
@ 2009-01-06 7:39 ` Tore Martin Hagen
2009-01-08 7:19 ` Unsubscribe Stephen Rothwell
0 siblings, 1 reply; 127+ messages in thread
From: Tore Martin Hagen @ 2009-01-06 7:39 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: Linuxppc-dev, Narendra KA
[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]
There are two problems here.
The first is that a lot of people has unsubscribed to this list a long
time ago, and then when it changed name we where suddenly subscribed for
again.
The second is that the site
https://ozlabs.org/mailman/listinfo/linuxppc-dev has an invalid security
certificate, so we can not really unsubscribe that way.
I suggest that the certificate is updated.
/Tore
Steve Iribarne (GMail) wrote:
> HOLLY CRAP everyone.. please read at the bottom of these emails to
> figure out how to unsubscribe. This is ridiculous!
>
> Towards the bottom of the
> "https://ozlabs.org/mailman/listinfo/linuxppc-dev" page there is
> simple place you put your f'ing email address and hit "Unsubscribe or
> edit options".
>
> That's why we put it there... so you could do it and we wouldn't have
> to do any of it.
>
> Please quit sending emails asking someone to do something for you.
>
> Sorry for the spam, but I'm hung over from new years and in a bad mood
> and this was the email that sent me over the top. No ill will towards
> you Narendra.
>
> -stv
>
> On Sun, Jan 4, 2009 at 8:32 PM, Narendra KA <Narendra.KA@lntemsys.com> wrote:
>
>> Hi,
>>
>> can you please unsubscribe me from this mailing list?
>>
>> Thanks and Regards,
>> Narendra K.A
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>
>
>
>
> --
> /*
> * Steve Iribarne
> * Software Engineer
> * (aka Grunt)
> */
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 2680 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Unsubscribe
2009-01-06 7:39 ` Unsubscribe Tore Martin Hagen
@ 2009-01-08 7:19 ` Stephen Rothwell
0 siblings, 0 replies; 127+ messages in thread
From: Stephen Rothwell @ 2009-01-08 7:19 UTC (permalink / raw)
To: Tore Martin Hagen; +Cc: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 987 bytes --]
Hi Tore,
On Tue, 06 Jan 2009 08:39:31 +0100 Tore Martin Hagen <thagen@slb.com> wrote:
>
> The first is that a lot of people has unsubscribed to this list a long
> time ago, and then when it changed name we where suddenly subscribed for
> again.
I only transferred over people who were currently subscribed to the
linuxppc-embedded list - some of these may have had their mail delivery
from the list *disabled*, but there was no easy way to check that, sorry.
> The second is that the site
> https://ozlabs.org/mailman/listinfo/linuxppc-dev has an invalid security
> certificate, so we can not really unsubscribe that way.
>
> I suggest that the certificate is updated.
We use a certificate issued by cacert.org. Unfortunately, a lot of
browsers do not recognise them as a CA.
You can use http://ozlabs.org/mailman/listinfo/linuxppc-dev instead.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* Unsubscribe
@ 2009-01-04 12:22 Frank Lautenbach
2009-01-04 13:55 ` Unsubscribe Leon Woestenberg
0 siblings, 1 reply; 127+ messages in thread
From: Frank Lautenbach @ 2009-01-04 12:22 UTC (permalink / raw)
To: Linuxppc-dev
Hi,
can you please unsubscribe me from this mailing list?
Thanks!
Greetings,
Frank
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2008-07-09 14:45 Ed Henderson
0 siblings, 0 replies; 127+ messages in thread
From: Ed Henderson @ 2008-07-09 14:45 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3 bytes --]
[-- Attachment #2: Type: text/html, Size: 1619 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2007-06-12 1:14 Alexander Baldeck
0 siblings, 0 replies; 127+ messages in thread
From: Alexander Baldeck @ 2007-06-12 1:14 UTC (permalink / raw)
To: linuxppc-dev
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2007-04-24 18:07 mike
0 siblings, 0 replies; 127+ messages in thread
From: mike @ 2007-04-24 18:07 UTC (permalink / raw)
To: linuxppc-dev
Michael J. Kelly
VP Engineering
Cogent Computer Systems, Inc.
17 Industrial Dr.
Smithfield, RI 02917
tel:401-223-3441 fax:401-223-3442
www.cogcomp.com
alternate email: mkelly6505@hotmail.com
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Is get_property() correct?
@ 2006-10-28 9:08 Michael Ellerman
2006-10-30 2:05 ` unsubscribe Usha Rani Konudula
0 siblings, 1 reply; 127+ messages in thread
From: Michael Ellerman @ 2006-10-28 9:08 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
On Sat, 2006-10-28 at 01:38 -0600, Grant Likely wrote:
> On 10/28/06, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > On Sat, 2006-10-28 at 00:41 -0600, Grant Likely wrote:
> >
> > Well considering that we don't know the type of the property value, the
> > best we can do is return a pointer to it ...
> >
> > The comment might want an update, though it never stroke me as confusing
> > but heh :)
>
> No, it's not confusing. Both the comment and the code are correct. I
> just forgot how to read code. :(
But at least now we're all _sure_ they're correct, some good still
done :)
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2006-10-12 9:56 Usha Rani Konudula
0 siblings, 0 replies; 127+ messages in thread
From: Usha Rani Konudula @ 2006-10-12 9:56 UTC (permalink / raw)
To: linuxppc-dev list
unsubscribe
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2006-07-25 4:32 umesh k
0 siblings, 0 replies; 127+ messages in thread
From: umesh k @ 2006-07-25 4:32 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 105 bytes --]
---------------------------------
Find out what India is talking about on Yahoo! Answers India.
[-- Attachment #2: Type: text/html, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2006-06-09 9:19 rohitash panda
0 siblings, 0 replies; 127+ messages in thread
From: rohitash panda @ 2006-06-09 9:19 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 137 bytes --]
Ability is what you are capable of doing.
Motivation determines what you do.
Attitude determines how well you do it.
[-- Attachment #2: Type: text/html, Size: 537 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2006-02-27 4:10 shrisha.prasad
0 siblings, 0 replies; 127+ messages in thread
From: shrisha.prasad @ 2006-02-27 4:10 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: Type: text/html, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2006-02-13 18:39 Moloko Vellocet
0 siblings, 0 replies; 127+ messages in thread
From: Moloko Vellocet @ 2006-02-13 18:39 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 13 bytes --]
unsubscribe
[-- Attachment #2: Type: text/html, Size: 13 bytes --]
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2005-11-05 10:13 Geert Janssens
0 siblings, 0 replies; 127+ messages in thread
From: Geert Janssens @ 2005-11-05 10:13 UTC (permalink / raw)
To: Linuxppc-dev
^ permalink raw reply [flat|nested] 127+ messages in thread
[parent not found: <D3099360D13C2F4F8F3C12EADC7A346A023C5A7C@srsdmail.pv.com>]
[parent not found: <000c01c4c04a$4f707720$974ffea9@a2i4y5>]
* unsubscribe
@ 2003-06-30 13:30 Fabio Sirna
0 siblings, 0 replies; 127+ messages in thread
From: Fabio Sirna @ 2003-06-30 13:30 UTC (permalink / raw)
To: Acpi-devel
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
^ permalink raw reply [flat|nested] 127+ messages in thread
* Encryption
@ 2003-03-22 23:22 Pierre Abbat
2003-03-23 9:16 ` Snapshots a la NetApp? Heinz-Josef Claes
0 siblings, 1 reply; 127+ messages in thread
From: Pierre Abbat @ 2003-03-22 23:22 UTC (permalink / raw)
To: reiserfs-list
How is filesystem encryption going to work? Or has anyone figured that out
yet?
phma
--
.i toljundi do .ibabo mi'afra tu'a do
.ibabo damba do .ibabo do jinga
.icu'u la ma'atman.
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Snapshots a la NetApp?
@ 2003-03-23 9:16 ` Heinz-Josef Claes
2003-03-24 20:49 ` Hans Reiser
0 siblings, 1 reply; 127+ messages in thread
From: Heinz-Josef Claes @ 2003-03-23 9:16 UTC (permalink / raw)
To: kend; +Cc: reiserfs-list
Am Son, 2003-03-23 um 04.38 schrieb kend@xanoptix.com:
> I'm just wondering if there's any development being done on NetApp-like
> snapshots. (This differs from LVM snapshots in that it's file-by-file,
> instead of volume based.) If not, has anyone given it any consideration?
> It would be a huge win for the RAID-in-a-box folks, and, speaking as a
> sysadmin, is something about which I dream frequently.
>
> Just curious...
>
> Ken D'Ambrosio
> Sr. SysAdmin,
> Xanoptix, Inc.
Hi,
you can look at the URL below. It's a kind of snapshot inspired by
NetApp, but has nothing to do with LVM or the filesystem. It also has a
different behaviour.
--
Heinz-Josef Claes hjclaes@web.de
project: http://sourceforge.net/projects/storebackup
-> snapshot-like backup to another disk
^ permalink raw reply [flat|nested] 127+ messages in thread
* Re: Snapshots a la NetApp?
2003-03-23 9:16 ` Snapshots a la NetApp? Heinz-Josef Claes
@ 2003-03-24 20:49 ` Hans Reiser
2003-03-25 6:15 ` unsubscribe Voicu Liviu
0 siblings, 1 reply; 127+ messages in thread
From: Hans Reiser @ 2003-03-24 20:49 UTC (permalink / raw)
To: Heinz-Josef Claes; +Cc: kend, reiserfs-list
Heinz-Josef Claes wrote:
>Am Son, 2003-03-23 um 04.38 schrieb kend@xanoptix.com:
>
>
>>I'm just wondering if there's any development being done on NetApp-like
>>snapshots. (This differs from LVM snapshots in that it's file-by-file,
>>instead of volume based.) If not, has anyone given it any consideration?
>>It would be a huge win for the RAID-in-a-box folks, and, speaking as a
>>sysadmin, is something about which I dream frequently.
>>
>>Just curious...
>>
>>Ken D'Ambrosio
>>Sr. SysAdmin,
>>Xanoptix, Inc.
>>
>>
>
>Hi,
>you can look at the URL below. It's a kind of snapshot inspired by
>NetApp, but has nothing to do with LVM or the filesystem. It also has a
>different behaviour.
>
>
>
I didn't find the magic click that gave me the design doc for
storebackup, could you post it to the list?
--
Hans
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2002-09-24 9:33 farnis=VGgt2q2+T+FeoWH0uzbU5w@public.gmane.org
0 siblings, 0 replies; 127+ messages in thread
From: farnis=VGgt2q2+T+FeoWH0uzbU5w@public.gmane.org @ 2002-09-24 9:33 UTC (permalink / raw)
To: Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
--
Fabio
^ permalink raw reply [flat|nested] 127+ messages in thread
* Unable to recover from CRC failiure
@ 2002-03-27 10:46 Joakim Tjernlund
2002-03-27 17:00 ` unsubscribe Roy Sherrill
0 siblings, 1 reply; 127+ messages in thread
From: Joakim Tjernlund @ 2002-03-27 10:46 UTC (permalink / raw)
To: linux-mtd
Hi
I got the following on one of our nodes:
-------------- Start log --------------
<snip>
JFFS2: Total scan time: 11.41 sec
Eep. Child "utmp" (ino #1853) of dir ino #130 doesn't exist!
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 52k init 4k openfirmware
jffs2_read_inode() on nonexistent ino 1853
INIT: version 2.78 booting
Fast boot, no file system check
none on /dev/shm type shm (rw)
Cleaning: /etc/network/ifstate.
Enabling packet forwarding: done.
Configuring network interfaces: done.
Cleaning: /tmp /var/lock /var/runfind: ./utmp: Input/output error
/etc/init.d/rcS: /var/run/utmp: Input/output error
Give root password for maintenance
(or type Control-D for normal startup):
bash-2.04# cd /var/run
bash-2.04# ls
exim utmp
bash-2.04# ls -l
ls: utmp: Input/output error
total 0
drwxr-xr-x 1 root root 0 May 24 2001 exim
bash-2.04# rm utmp
rm: cannot remove `utmp': Input/output error
bash-2.04# rm -f utmp
rm: cannot remove `utmp': Input/output error
bash-2.04# ls
exim utmp
bash-2.04# ls -l
ls: utmp: Input/output error
total 0
drwxr-xr-x 1 root root 0 May 24 2001 exim
bash-2.04# cd ..
bash-2.04# pwd
/var
bash-2.04# ls
cache lib local lock log mail opt run spool tmp ucd-snmp
bash-2.04# ls run
exim utmp
bash-2.04# mv run slask
mv: cannot stat `run/utmp': Input/output error
bash-2.04# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/root 63744 44996 18748 71% /
bash-2.04#
-------------- End log -------------
I have no problem with getting a bad CRC on the JFFS2 FS at times, but that I am unable to get rid of
the offending file(utmp).
I am using the latest stable 2.4 branch.
Any ideas?
Jocke
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
2002-03-27 10:46 Unable to recover from CRC failiure Joakim Tjernlund
@ 2002-03-27 17:00 ` Roy Sherrill
0 siblings, 0 replies; 127+ messages in thread
From: Roy Sherrill @ 2002-03-27 17:00 UTC (permalink / raw)
To: linux-mtd
-----Original Message-----
From: linux-mtd-admin@lists.infradead.org
[mailto:linux-mtd-admin@lists.infradead.org]On Behalf Of Joakim
Tjernlund
Sent: Wednesday, March 27, 2002 2:47 AM
To: linux-mtd@lists.infradead.org
Subject: Unable to recover from CRC failiure
Hi
I got the following on one of our nodes:
-------------- Start log --------------
<snip>
JFFS2: Total scan time: 11.41 sec
Eep. Child "utmp" (ino #1853) of dir ino #130 doesn't exist!
VFS: Mounted root (jffs2 filesystem).
Freeing unused kernel memory: 52k init 4k openfirmware
jffs2_read_inode() on nonexistent ino 1853
INIT: version 2.78 booting
Fast boot, no file system check
none on /dev/shm type shm (rw)
Cleaning: /etc/network/ifstate.
Enabling packet forwarding: done.
Configuring network interfaces: done.
Cleaning: /tmp /var/lock /var/runfind: ./utmp: Input/output error
/etc/init.d/rcS: /var/run/utmp: Input/output error
Give root password for maintenance
(or type Control-D for normal startup):
bash-2.04# cd /var/run
bash-2.04# ls
exim utmp
bash-2.04# ls -l
ls: utmp: Input/output error
total 0
drwxr-xr-x 1 root root 0 May 24 2001 exim
bash-2.04# rm utmp
rm: cannot remove `utmp': Input/output error
bash-2.04# rm -f utmp
rm: cannot remove `utmp': Input/output error
bash-2.04# ls
exim utmp
bash-2.04# ls -l
ls: utmp: Input/output error
total 0
drwxr-xr-x 1 root root 0 May 24 2001 exim
bash-2.04# cd ..
bash-2.04# pwd
/var
bash-2.04# ls
cache lib local lock log mail opt run spool tmp ucd-snmp
bash-2.04# ls run
exim utmp
bash-2.04# mv run slask
mv: cannot stat `run/utmp': Input/output error
bash-2.04# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/root 63744 44996 18748 71% /
bash-2.04#
-------------- End log -------------
I have no problem with getting a bad CRC on the JFFS2 FS at times, but that
I am unable to get rid of
the offending file(utmp).
I am using the latest stable 2.4 branch.
Any ideas?
Jocke
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 2000-07-25 10:21 Kasslatter Fritz
0 siblings, 0 replies; 127+ messages in thread
From: Kasslatter Fritz @ 2000-07-25 10:21 UTC (permalink / raw)
To: 'mtd@infradead.org'
unsubscribe
-------------------------------------------------------------------
> SIEMENS Siemens AG Österreich PSE PRO CDA5
> Software
> A-1031 WIEN,
> Erdbergerlaende 26, Zi. C3266
> Tel +43 1 1707 37929
> D.I. Fax +43 1 1707 57911
> Fritz Kasslatter mailto:fritz.kasslatter@siemens.at
> PGP-Key on Request
>
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 1999-07-06 8:37 Torbjorn Gannholm
0 siblings, 0 replies; 127+ messages in thread
From: Torbjorn Gannholm @ 1999-07-06 8:37 UTC (permalink / raw)
To: linux
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 1999-06-11 0:58 Deni Connor
0 siblings, 0 replies; 127+ messages in thread
From: Deni Connor @ 1999-06-11 0:58 UTC (permalink / raw)
To: linux
unsubscribe
Senior Editor
<color><param>0000,0000,ffff</param>Network</color> World
Covering servers and storage
8815 Mountain Path Circle
Austin, Texas 78759
(512) 345-3850
Fax: (512) 345-3860
^ permalink raw reply [flat|nested] 127+ messages in thread
* unsubscribe
@ 1999-04-02 12:37 Carbon Monoxide
1999-04-02 13:06 ` unsubscribe Koundinya.K
0 siblings, 1 reply; 127+ messages in thread
From: Carbon Monoxide @ 1999-04-02 12:37 UTC (permalink / raw)
To: linux
unsubscribe
^ permalink raw reply [flat|nested] 127+ messages in thread
end of thread, other threads:[~2024-05-17 13:37 UTC | newest]
Thread overview: 127+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-01-06 17:59 unsubscribe hb fei
2009-01-07 1:55 ` unsubscribe Tao Xue
2009-01-07 6:32 ` unsubscribe AKS
2009-01-07 6:38 ` unsubscribe zhou.yutao
2009-01-07 7:42 ` unsubscribe Decherf, Patrick
2009-01-07 7:59 ` unsubscribe Liu Dave
2009-01-07 8:10 ` [gmail] unsubscribe Marc Leeman
2009-01-07 18:56 ` Scott Wood
-- strict thread matches above, loose matches on Subject: below --
2024-05-17 13:37 unsubscribe Satay Epic
2024-05-09 10:10 Unsubscribe SP2L Tom
2024-05-09 10:21 ` Unsubscribe Dan Carpenter
2024-04-03 8:04 [PATCH v5 00/22] RISC-V SBI v2.0 PMU improvements and Perf sampling in KVM guest Atish Patra
2024-04-03 8:04 ` [PATCH v5 04/22] drivers/perf: riscv: Use BIT macro for shifting operations Atish Patra
2024-04-03 15:57 ` unsubscribe jonathan.oleson
2024-02-14 20:51 unsubscribe Igor Andreev
2024-01-15 8:19 unsubscribe limin yin
2023-12-13 17:30 unsubscribe Hank Barta
2023-11-25 16:50 unsubscribe Emmanuel ALLAUD
2023-06-20 6:46 unsubscribe Yao Yongxian
2023-05-02 23:36 [XEN][PATCH v6 00/19] dynamic node programming using overlay dtbo Vikram Garhwal
2023-05-02 23:36 ` [XEN][PATCH v6 08/19] xen/device-tree: Add device_tree_find_node_by_path() to find nodes in device tree Vikram Garhwal
2023-05-04 4:23 ` Henry Wang
2023-05-04 5:56 ` unsubscribe Terry Yang
2023-03-11 3:39 Unsubscribe Aviral Gupta
2022-12-01 1:38 unsubscribe Chan Kim
2022-10-13 10:14 unsubscribe Benjamin Demartin
2022-10-31 16:21 ` unsubscribe Thomas Monjalon
2022-06-29 21:00 unsubscribe Alvin Šipraga
2022-06-29 21:10 ` unsubscribe Alvin Šipraga
2021-11-02 6:37 unsubscribe Jacky Wang (王亮)-浪潮数据
2021-09-30 21:48 unsubscribe Shoaib Rao
2021-09-30 21:49 ` unsubscribe Shoaib Rao
2020-12-29 8:54 unsubscribe Shawn Landden
2020-12-21 7:28 unsubscribe Shawn Landden
2020-10-07 15:34 unsubscribe Thompson, Kent
[not found] <CAGHfRMD3FP0_dAEmOgnkgyodXodWq2YcjaiOzvBwG=J1nqq-8g@mail.gmail.com>
2020-07-12 12:22 ` unsubscribe Philip Oakley
2019-05-29 15:32 Unsubscribe ID - David Torres
2019-03-14 7:34 overlayfs vs. fscrypt Miklos Szeredi
2019-03-14 17:15 ` [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required Richard Weinberger
2019-03-14 17:49 ` Eric Biggers
2019-03-14 20:54 ` Richard Weinberger
2019-03-14 23:07 ` Theodore Ts'o
2019-03-15 0:26 ` Unsubscribe Shane Volpe
2019-03-07 14:15 unsubscribe Punky
2019-03-07 14:13 unsubscribe Punky
2018-05-14 21:14 Unsubscribe Eric Brown
[not found] <CGME20180128235454epcms1p6f3b7aa47ba9c5035f9b317421c09a46a@epcms1p6>
2018-01-28 23:54 ` unsubscribe 조동석
2017-06-20 7:57 unsubscribe Gary Thomas
2017-01-19 18:31 unsubscribe Brad Litterell
[not found] <CGME20161205003536epcms1p4c6ce52ccda8bbc5da6eb99d3de8e12a3@epcms1p4>
2016-12-05 0:35 ` unsubscribe 조동석
2016-10-25 18:30 unsubscribe cybin
2016-10-05 12:53 unsubscribe 고영준
2016-08-16 6:44 unsubscribe kuangjiou
2016-04-18 23:21 unsubscribe cybin
[not found] <CAOLmke5wWrewgemRGCfgMY7vnqsnAQcZHDteVWkLHWOj_kOYbA@mail.gmail.com>
2015-03-21 10:39 ` unsubscribe ye tao
2014-08-11 13:19 unsubscribe Deepak Pandian
2014-02-01 6:27 unsubscribe animan9
2013-11-22 19:35 unsubscribe Pow, Christopher (SWCOE)
2013-11-22 19:38 ` unsubscribe Denys Dmytriyenko
2013-10-02 15:58 unsubscribe Daniel Kranich
2013-09-15 13:52 unsubscribe GMAIL
2013-09-11 8:43 unsubscribe GMAIL
2012-05-01 18:53 Mysterious memory corruption bug Bean
2012-05-01 19:08 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-05-01 19:46 ` Bean
2012-05-01 19:52 ` Bean
2012-05-01 19:56 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-05-01 20:02 ` Bean
2012-05-01 20:06 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-05-01 20:09 ` Bean
2012-05-01 20:16 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-05-01 20:34 ` Bean
2012-05-01 20:35 ` unsubscribe Daniel Senderowicz
2012-05-01 20:43 ` unsubscribe Gregg Levine
2011-11-14 17:26 unsubscribe Tietz Fabian (AA-DG/PAS-ESD2)
2011-02-28 2:25 Unsubscribe Tomasz Fujak
2011-01-06 17:42 unsubscribe marduk
2010-11-03 8:21 unsubscribe Roberto Mantovani
2010-10-19 8:51 unsubscribe Roberto Mantovani
2010-07-17 11:30 unsubscribe aiolos.cis90
2010-06-23 14:33 unsubscribe Frederic LEGER
2009-11-27 23:26 unsubscribe Gao Ya'nan
2009-11-28 17:02 ` unsubscribe Thomas Rinder
2009-02-04 13:48 unsubscribe Bietry, Ray
2009-02-04 13:19 unsubscribe ravi.rao
2009-02-04 8:11 unsubscribe Usha Rani Konudula
2009-01-24 21:46 unsubscribe Hai Zhu
2009-01-13 5:02 Unsubscribe shreeram
2009-01-12 8:29 unsubscribe Kunkel, Ulrich
2009-01-12 5:49 unsubscribe zhou.yutao
2009-01-12 9:06 ` unsubscribe Geert Uytterhoeven
2009-01-11 19:25 unsubscribe rsterling
2009-01-12 4:39 ` unsubscribe sandeep malik
2009-01-12 12:56 ` unsubscribe ravi.rao
2009-01-12 13:43 ` unsubscribe Rajasekaran Kaliyaperumal, Chennai
2009-01-11 17:38 Unsubscribe Nadav Sharabi
2009-01-12 4:49 ` Unsubscribe Wei Jack
2009-01-11 10:02 unsubscribe Ignacio Vara
2009-01-11 16:13 ` unsubscribe List
2009-01-08 2:45 unsubscribe Yedu Jathavedan
2009-01-07 17:21 unsubscribe rsterling
2009-01-07 17:12 unsubscribe Wei Jack
2009-01-07 16:00 unsubscribe neeraj garg
2009-01-07 7:23 mpc5200 ATA DMA Peter Czanik
2009-01-07 7:58 ` Unsubscribe Landau, Bracha
2009-01-07 6:37 unsubscribe santhoshunnikrishnan
2009-01-07 7:27 ` unsubscribe Rustagi, Vikas
2009-01-07 15:32 ` unsubscribe Sungjoo Kim
2009-01-07 2:23 unsubscribe pravin
2009-01-05 23:48 Unsubscribe JeongIn Choi
[not found] <43FB4790A017E847A47C1D1FD108904E017B7C12@EXVBE011-1.exch011.int ermedia.net>
[not found] ` <43FB4790A017E847A47C1D1FD108904E017B7C12@EXVBE011-1.exch011.in termedia.net>
2009-01-05 23:46 ` unsubscribe Ian Juang
2009-01-05 21:58 unsubscribe Iain Shewring
2009-01-05 21:32 unsubscribe Jim Rose
2009-01-05 21:49 ` unsubscribe Nate Jozwiak
2009-01-06 5:03 ` unsubscribe vikas.soni
2009-01-06 10:55 ` unsubscribe Paul Eaton
2009-01-05 18:03 unsubscribe Leonid
2009-01-05 19:06 ` unsubscribe Nitesh Guinde
2009-01-05 13:09 unsubscribe P Jagadeesh Maiya
2009-01-05 8:41 UNSUBSCRIBE Arun Kumar
2009-01-05 4:32 Unsubscribe Narendra KA
2009-01-05 4:33 ` Unsubscribe Steve Iribarne (GMail)
2009-01-06 7:39 ` Unsubscribe Tore Martin Hagen
2009-01-08 7:19 ` Unsubscribe Stephen Rothwell
2009-01-04 12:22 Unsubscribe Frank Lautenbach
2009-01-04 13:55 ` Unsubscribe Leon Woestenberg
2008-07-09 14:45 unsubscribe Ed Henderson
2007-06-12 1:14 unsubscribe Alexander Baldeck
2007-04-24 18:07 unsubscribe mike
2006-10-28 9:08 Is get_property() correct? Michael Ellerman
2006-10-30 2:05 ` unsubscribe Usha Rani Konudula
2006-10-12 9:56 unsubscribe Usha Rani Konudula
2006-07-25 4:32 unsubscribe umesh k
2006-06-09 9:19 unsubscribe rohitash panda
2006-02-27 4:10 unsubscribe shrisha.prasad
2006-02-13 18:39 unsubscribe Moloko Vellocet
2005-11-05 10:13 unsubscribe Geert Janssens
[not found] <D3099360D13C2F4F8F3C12EADC7A346A023C5A7C@srsdmail.pv.com>
2005-01-05 21:55 ` UNSUBSCRIBE George Socker
[not found] <000c01c4c04a$4f707720$974ffea9@a2i4y5>
2004-11-01 23:04 ` unsubscribe Jacob
2004-11-02 0:44 ` unsubscribe Lee Revell
2003-06-30 13:30 unsubscribe Fabio Sirna
2003-03-22 23:22 Encryption Pierre Abbat
2003-03-23 9:16 ` Snapshots a la NetApp? Heinz-Josef Claes
2003-03-24 20:49 ` Hans Reiser
2003-03-25 6:15 ` unsubscribe Voicu Liviu
2002-09-24 9:33 unsubscribe farnis=VGgt2q2+T+FeoWH0uzbU5w@public.gmane.org
2002-03-27 10:46 Unable to recover from CRC failiure Joakim Tjernlund
2002-03-27 17:00 ` unsubscribe Roy Sherrill
2000-07-25 10:21 unsubscribe Kasslatter Fritz
1999-07-06 8:37 unsubscribe Torbjorn Gannholm
1999-06-11 0:58 unsubscribe Deni Connor
1999-04-02 12:37 unsubscribe Carbon Monoxide
1999-04-02 13:06 ` unsubscribe Koundinya.K
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.