unsubscribe

unsubscribe

[Hai Zhu]

[-- Attachment #1: Type: text/plain, Size: 20 bytes --]

unsubscribe


      

[-- Attachment #2: Type: text/html, Size: 136 bytes --]

unsubscribe

[Ramon Fried]

unsubscribe

[Ramon Fried]

unsubscribe

[Shyam Saini]

unsubscribe linux-mmc

unsubscribe

[Trevor Gamblin]

unsubscribe

Unsubscribe

[Aditi Ghag]

unsubscribe

[Jane Chu]

Please unsubscribe me.
thanks!
-jane

Re: unsubscribe

[dan.j.williams]

Jane Chu wrote:
> Please unsubscribe me.

Hey Jane, send a mail here:

nvdimm+unsubscribe@lists.linux.dev

...for that.

unsubscribe

[junan]

unsubscribe

unsubscribe

[junan]

unsubscribe

unsubscribe

[René Weber]

unsubscribe

unsubscribe

[Matteo Guglielmi]

unsubscribe

--------
Matteo Guglielmi | DALCO AG | Industriestr. 28 | 8604 Volketswil | Switzerland | T: +41 44 908 38 38 | D: +41 44 908 38 37

unsubscribe

[Jag Raman]

unsubscribe

unsubscribe

[Elias Tsolis]

unsubscribe

[ying fang]

unsubscribe

unsubscribe

[Martin Haass]

"Abuse" of this ML for mail-setup-test

[Benjamin Kiefl]

Hello, I hope this is not completely out of line.

As I've never used a mailing list before, nor mutt, nor can find a purpose lkml
"testing list" for such endeavors as mine, and have witnessed this list being
low-frequency thus far, I hopefully may be exused for using this list to test
out my new setup.

An answer of any length from someone appreciated (to further test mail
reception). If there's any better way to do such a test (for potential future
use or setup fine-tuning) I'd also appreciate a recommendation.

Cheers, looking forward to contributing to Linux,

Benjamin

Re: "Abuse" of this ML for mail-setup-test

[Ryan Matthews]

On Thu, Jul 10, 2025, at 16:46, Benjamin Kiefl wrote:
> Hello, I hope this is not completely out of line.

> Cheers, looking forward to contributing to Linux

I think it's acceptable or encouraged given your purpose.

I sent a couple test patches here a few weeks ago because I arrived at the
same conclusions. Just don't overdo it?

 -- Ryan

Re: "Abuse" of this ML for mail-setup-test

[Ryan Matthews]

On Thu, Jul 10, 2025, at 16:46, Benjamin Kiefl wrote:
> If there's any better way to do such a test (for potential future
> use or setup fine-tuning) I'd also appreciate a recommendation.

Actually, I suggest to experiment and practice with mutt (or any mail
client) by sending emails back and forth to yourself between two email
accounts. Use it to send mail to a friend. etc

When using git send-email, use the --dry-run and --suppress-cc=all options
to make sure you got everything right before actually sending anything.

Then you can practice sending patches to yourself still without bothering
mailing list or other authors.

One day when you're ready to send a message or a patch to a public mailing
list, you can do a similar test by first sending it here (but not CCing
everyone else). Look at lore.kernel.org and see if it worked like you
expected. Make sure it's formatted correctly in plain text, etc. Final
step, send to the real list with all the real CCs and everything.

That way you're not making unnecessary test noises for everyone else.

Hope that helps.

 -- Ryan

Re: "Abuse" of this ML for mail-setup-test

[Benjamin Kiefl]

On Thu, Jul 10, 2025 at 11:13:30PM -0400, Ryan Matthews wrote:
> On Thu, Jul 10, 2025, at 16:46, Benjamin Kiefl wrote:
> > If there's any better way to do such a test (for potential future
> > use or setup fine-tuning) I'd also appreciate a recommendation.
> 
> Actually, I suggest to experiment and practice with mutt (or any mail
> client) by sending emails back and forth to yourself between two email
> accounts. Use it to send mail to a friend. etc

Did this before sending to here of course, more than once, during initial setup
phase, but was unsure as to sending to a mailing list. But there simply seems to
be far less "magic" to it than originally envisioned.

> When using git send-email, use the --dry-run and --suppress-cc=all options
> to make sure you got everything right before actually sending anything.
> 
> Then you can practice sending patches to yourself still without bothering
> mailing list or other authors.

Nice, thanks, mirrors the advice I've read elsewhere, but good to read
confirmation. Thanks for the suggestion.

> One day when you're ready to send a message or a patch to a public mailing
> list, you can do a similar test by first sending it here (but not CCing
> everyone else). Look at lore.kernel.org and see if it worked like you
> expected. Make sure it's formatted correctly in plain text, etc. Final
> step, send to the real list with all the real CCs and everything.
> 
> That way you're not making unnecessary test noises for everyone else.
> 
> Hope that helps.
> 
>  -- Ryan

Yep, that helps, and thanks for responding.

-- Benjamin

Unsubscribe

[Georges Kanaan]

	Unsubscribe

unsubscribe

[joerg]

CONFIG_XXX vs CONFIG_HAVE_XXX ?

[Alexandre Ferrieux]

Hi,

What is the rationale behind having, for some feature XXX, both configuration
macros CONFIG_XXX and CONFIG_HAVE_XXX ?

For example, I'd love to use ftrace's new life-saving feature "funcgraph-retval"
(which instantly shows the root cause of an error returned from a fully graphed
function). Unfortunately, on all recent Debians the config says:

  CONFIG_HAVE_FUNCTION_GRAPH_RETVAL=y
  # CONFIG_FUNCTION_GRAPH_RETVAL is not set

As a result, the feature is not available. Okay, I'll just enable and recompile.
However, I'm wondering why in the first place such a situation is possible: what
is the intention there ? Either we want the feature, or we don't (e.g. because
it may incur some CPU or memory overhead), but why sit halfway in between ?

Thanks in advance,

-Alex

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

संदर्भ: CONFIG_XXX vs CONFIG_HAVE_XXX ?

[Siddh Raman Pant]

Sun, 18 May 2025 23:15:13 +0530 को alexandre.ferrieux@gmail.com ने लिखा :
> What is the rationale behind having, for some feature XXX, both configuration
> macros CONFIG_XXX and CONFIG_HAVE_XXX ?


CONFIG_HAVE_XXX -> XXX is supported.
CONFIG_XXX -> Enable XXX.


XXX may not be available on an arch, for eg.


Thanks,
Siddh


[Sorry for duplicate, pressed reply instead of reply all :P]



_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

unsubscribe

[Mrunal Gawade]

[-- Attachment #1.1: Type: text/plain, Size: 725 bytes --]

On Sun, May 18, 2025 at 8:25 PM Siddh Raman Pant <sanganaka@siddh.me> wrote:

> Sun, 18 May 2025 23:15:13 +0530 को alexandre.ferrieux@gmail.com ने लिखा :
> > What is the rationale behind having, for some feature XXX, both
> configuration
> > macros CONFIG_XXX and CONFIG_HAVE_XXX ?
>
>
> CONFIG_HAVE_XXX -> XXX is supported.
> CONFIG_XXX -> Enable XXX.
>
>
> XXX may not be available on an arch, for eg.
>
>
> Thanks,
> Siddh
>
>
> [Sorry for duplicate, pressed reply instead of reply all :P]
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

[-- Attachment #1.2: Type: text/html, Size: 1360 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

unsubscribe

[Mrunal Gawade]

[-- Attachment #1.1: Type: text/plain, Size: 725 bytes --]

On Sun, May 18, 2025 at 8:25 PM Siddh Raman Pant <sanganaka@siddh.me> wrote:

> Sun, 18 May 2025 23:15:13 +0530 को alexandre.ferrieux@gmail.com ने लिखा :
> > What is the rationale behind having, for some feature XXX, both
> configuration
> > macros CONFIG_XXX and CONFIG_HAVE_XXX ?
>
>
> CONFIG_HAVE_XXX -> XXX is supported.
> CONFIG_XXX -> Enable XXX.
>
>
> XXX may not be available on an arch, for eg.
>
>
> Thanks,
> Siddh
>
>
> [Sorry for duplicate, pressed reply instead of reply all :P]
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

[-- Attachment #1.2: Type: text/html, Size: 1360 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Unsubscribe

[Andrew Taylor]

Andrew

Sent from a mobile device

[ANNOUNCE] Call for Contributors: ASIOS – AI‑Native OS (Kernel Work)

[Vikram R]

ASIOS is a new AI‑native OS (Ubuntu 24.04 LTS base) bringing
deterministic scheduling, NUMA‑GPU optimizations, zero‑copy I/O, and
eBPF telemetry into the Linux kernel.

Key directions—
— Deterministic CPU scheduling for reproducible AI runs
— NUMA‑aware memory placement tuned for GPU DMA
— Zero‑copy GPU I/O via GPUDirect RDMA/Storage
— eBPF‑based telemetry hooks

**Call for contributors:** scheduler/MM, GPU/accelerator integration,
eBPF instrumentation.

Project links—
GitHub: <https://github.com/asi-os>
Discord: <https://discord.gg/rWuU7cWU4E>
Roadmap: <https://github.com/asi-os/asios-docs/blob/main/docs/ARCHITECTURE.md>

Please reply on‑list with questions or join us on Discord to dive into
the design.

Vikram Karlex R
KarLex AI, Inc. | <https://asios.ai> | <https://karlex.ai>

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [ANNOUNCE] Call for Contributors: ASIOS – AI‑Native OS (Kernel Work)

[Vikram R]

ASIOS – Envisioned to Host and Sustain Cognition & Synthetic Intelligence
The world’s first AI-native operating system.

ASIOS is a new class of OS built on Ubuntu 24.04 LTS, designed from
first principles for AI workloads. We’re creating the foundational
infrastructure layer to support ever-more sophisticated
intelligence—from today’s deep-learning models to tomorrow’s advanced
cognitive and quantum-ready AI.

Building on our May 3 thread, we’ve landed a resilient config-overlay
and build script for ASIOS on both x86_64 and aarch64. Key artifacts:

asios-config-overlay.sh: idempotent Kconfig overlay that tolerates
missing symbols
build-asios-kernel.sh: automated clone to config to compile workflow
test-asios-config.sh: verifies .config flags post build
Initial perf on Ubuntu 24.04 HWE 6.11:
x86_64: mbw=7.3 GB/s, hackbench=53 ms, fio=1.6 GB/s
arm64: mbw=27.4 GB/s, hackbench=4.8 ms, fio=3.2 GB/s

GitHub (scripts and tests): https://github.com/asi-os/asios-core/
Discord: https://discord.gg/rWuU7cWU4E

Areas for review and test:
1. Overlay logic: skipping versus failing on absent Kconfig symbols
2. Build-matrix logic: host-only versus cross-build
3. Test completeness: missing flags
4. Scripting style and robustness

Any pointers or suggestions are highly appreciated before we push to a
formal RFC series.

—
Vikram R
Founder & CEO, KarLex AI, Inc.
https://asios.ai


On Sat, May 3, 2025 at 12:22 PM Vikram R <vikram@karlexai.com> wrote:
>
> ASIOS is a new AI‑native OS (Ubuntu 24.04 LTS base) bringing
> deterministic scheduling, NUMA‑GPU optimizations, zero‑copy I/O, and
> eBPF telemetry into the Linux kernel.
>
> Key directions—
> — Deterministic CPU scheduling for reproducible AI runs
> — NUMA‑aware memory placement tuned for GPU DMA
> — Zero‑copy GPU I/O via GPUDirect RDMA/Storage
> — eBPF‑based telemetry hooks
>
> **Call for contributors:** scheduler/MM, GPU/accelerator integration,
> eBPF instrumentation.
>
> Project links—
> GitHub: <https://github.com/asi-os>
> Discord: <https://discord.gg/rWuU7cWU4E>
> Roadmap: <https://github.com/asi-os/asios-docs/blob/main/docs/ARCHITECTURE.md>
>
> Please reply on‑list with questions or join us on Discord to dive into
> the design.
>
> Vikram Karlex R
> KarLex AI, Inc. | <https://asios.ai> | <https://karlex.ai>

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

unsubscribe

[Mrunal Gawade]

[-- Attachment #1.1: Type: text/plain, Size: 2779 bytes --]

On Mon, May 19, 2025 at 9:27 PM Vikram R <vikram@karlexai.com> wrote:

> ASIOS – Envisioned to Host and Sustain Cognition & Synthetic Intelligence
> The world’s first AI-native operating system.
>
> ASIOS is a new class of OS built on Ubuntu 24.04 LTS, designed from
> first principles for AI workloads. We’re creating the foundational
> infrastructure layer to support ever-more sophisticated
> intelligence—from today’s deep-learning models to tomorrow’s advanced
> cognitive and quantum-ready AI.
>
> Building on our May 3 thread, we’ve landed a resilient config-overlay
> and build script for ASIOS on both x86_64 and aarch64. Key artifacts:
>
> asios-config-overlay.sh: idempotent Kconfig overlay that tolerates
> missing symbols
> build-asios-kernel.sh: automated clone to config to compile workflow
> test-asios-config.sh: verifies .config flags post build
> Initial perf on Ubuntu 24.04 HWE 6.11:
> x86_64: mbw=7.3 GB/s, hackbench=53 ms, fio=1.6 GB/s
> arm64: mbw=27.4 GB/s, hackbench=4.8 ms, fio=3.2 GB/s
>
> GitHub (scripts and tests): https://github.com/asi-os/asios-core/
> Discord: https://discord.gg/rWuU7cWU4E
>
> Areas for review and test:
> 1. Overlay logic: skipping versus failing on absent Kconfig symbols
> 2. Build-matrix logic: host-only versus cross-build
> 3. Test completeness: missing flags
> 4. Scripting style and robustness
>
> Any pointers or suggestions are highly appreciated before we push to a
> formal RFC series.
>
> —
> Vikram R
> Founder & CEO, KarLex AI, Inc.
> https://asios.ai
>
>
> On Sat, May 3, 2025 at 12:22 PM Vikram R <vikram@karlexai.com> wrote:
> >
> > ASIOS is a new AI‑native OS (Ubuntu 24.04 LTS base) bringing
> > deterministic scheduling, NUMA‑GPU optimizations, zero‑copy I/O, and
> > eBPF telemetry into the Linux kernel.
> >
> > Key directions—
> > — Deterministic CPU scheduling for reproducible AI runs
> > — NUMA‑aware memory placement tuned for GPU DMA
> > — Zero‑copy GPU I/O via GPUDirect RDMA/Storage
> > — eBPF‑based telemetry hooks
> >
> > **Call for contributors:** scheduler/MM, GPU/accelerator integration,
> > eBPF instrumentation.
> >
> > Project links—
> > GitHub: <https://github.com/asi-os>
> > Discord: <https://discord.gg/rWuU7cWU4E>
> > Roadmap: <
> https://github.com/asi-os/asios-docs/blob/main/docs/ARCHITECTURE.md>
> >
> > Please reply on‑list with questions or join us on Discord to dive into
> > the design.
> >
> > Vikram Karlex R
> > KarLex AI, Inc. | <https://asios.ai> | <https://karlex.ai>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

[-- Attachment #1.2: Type: text/html, Size: 4216 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[ANNOUNCE] nftables 1.1.3 release

[Pablo Neira Ayuso]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

Hi!

The Netfilter project proudly presents:

        nftables 1.1.3

This release contains a few fixes:

- Incorrect bytecode for vlan pcp mangling from netdev family chains
  such as ingress/egress:

     ... vlan pcp set 6 counter

- Bogus element in large concatenated set ranges, leading to:

      16777216 . 00:11:22:33:44:55 . 10.1.2.3 comment "123456789012345678901234567890"

  instead of:

     "lo" . 00:11:22:33:44:55 . 10.1.2.3 comment "123456789012345678901234567890"

- Restore set auto-merge feature with timeouts, disabled in the
  previous v1.1.2 release.

See changelog for more details (attached to this email).

You can download this new release from:

https://www.netfilter.org/projects/nftables/downloads.html
https://www.netfilter.org/pub/nftables/

[ NOTE: We have switched to .tar.xz files for releases. ]

To build the code, libnftnl >= 1.2.9 and libmnl >= 1.0.4 are required:

* https://netfilter.org/projects/libnftnl/index.html
* https://netfilter.org/projects/libmnl/index.html

Visit our wikipage for user documentation at:

* https://wiki.nftables.org

For the manpage reference, check man(8) nft.

In case of bugs and feature requests, file them via:

* https://bugzilla.netfilter.org

Happy firewalling.

[-- Attachment #2: changes-nftables-1.1.3.txt --]
[-- Type: text/plain, Size: 270 bytes --]

Florian Westphal (1):
      evalute: make vlan pcp updates work

Pablo Neira Ayuso (3):
      Revert "intervals: do not merge intervals with different timeout"
      netlink: bogus concatenated set ranges with netlink message overrun
      build: Bump version to 1.1.3

UNSUBSCRIBE

[Vink, Ronald]

UNSUBSCRIBE
________________________________


This e-mail is intended exclusively for the addressee(s). This e-mail, including attachments, contains confidential information and/or privileged and/or proprietary information. If you receive this e-mail in error, please notify the sender immediately and remove the e-mail from your systems without reading, copying, distributing or otherwise using its content in any form whatsoever. The unauthorized use, publication, reproduction or distribution of this e-mail is prohibited.

unsubscribe

[Karthik Ayyar]

unsubscribe

[Maksim Tarelov]

Unsubscribe

[Matt Cassell]

unsubscribe

Re: [RFC] Feature proposal to speed up the kernel.

[Vitalii]

You mean asking the desktop environment / window manager devs if they
want to implement this?

Unsubscribe

[Georges Kanaan]

Unsubscribe

UNSUBSCRIBE

[A bughunter]

[-- Attachment #1.1: Type: text/plain, Size: 11 bytes --]

UNSUBSCRIBE

[-- Attachment #1.2: publickey - A_bughunter@proton.me - 0x66540805.asc --]
[-- Type: application/pgp-keys, Size: 705 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 322 bytes --]

UNSUBSCRIBE

[A bughunter]

[-- Attachment #1.1: Type: text/plain, Size: 11 bytes --]

UNSUBSCRIBE

[-- Attachment #1.2: publickey - A_bughunter@proton.me - 0x66540805.asc --]
[-- Type: application/pgp-keys, Size: 705 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 322 bytes --]

Unsubscribe

[Glenn Golden]

unsubscribe

[Gonzalo A. de la Vega]

unsubscribe

Kernel NBD client waits on wrong cookie, aborts connection

[Kevin Wolf]

Hi all,

the other day I was running some benchmarks to compare different QEMU
block exports, and one of the scenarios I was interested in was
exporting NBD from qemu-storage-daemon over a unix socket and attaching
it as a block device using the kernel NBD client. I would then run a VM
on top of it and fio inside of it.

Unfortunately, I couldn't get any numbers because the connection always
aborted with messages like "Double reply on req ..." or "Unexpected
reply ..." in the host kernel log.

Yesterday I found some time to have a closer look why this is happening,
and I think I have a rough understanding of what's going on now. Look at
these trace events:

        qemu-img-51025   [005] ..... 19503.285423: nbd_header_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005a
[...]
        qemu-img-51025   [008] ..... 19503.285500: nbd_payload_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005d
[...]
   kworker/u49:1-47350   [004] ..... 19503.285514: nbd_header_received: nbd transport event: request 00000000b79e7443, handle 0x0000150c0000005a

This is the same request, but the handle has changed between
nbd_header_sent and nbd_payload_sent! I think this means that we hit one
of the cases where the request is requeued, and then the next time it
is executed with a different blk-mq tag, which is something the nbd
driver doesn't seem to expect.

Of course, since the cookie is transmitted in the header, the server
replies with the original handle that contains the tag from the first
call, while the kernel is only waiting for a handle with the new tag and
is confused by the server response.

I'm not sure yet which of the following options should be considered the
real problem here, so I'm only describing the situation without trying
to provide a patch:

1. Is it that blk-mq should always re-run the request with the same tag?
   I don't expect so, though in practice I was surprised to see that it
   happens quite often after nbd requeues a request that it actually
   does end up with the same cookie again.

2. Is it that nbd should use cookies that don't depend on the tag?
   Maybe, but then we lose an easy way to identify the request from the
   server response.

3. Is it that it should never requeue requests after already starting to
   send data for them? This sounds most likely to me, but also like the
   biggest change to make in nbd.

4. Or something else entirely?

I tested this with the 6.10.12 kernel from Fedora 40, but a quick git
diff on nbd.c doesn't suggest that anything related has changed since
then. This is how I reproduced it for debugging (without a VM):

$ qemu-storage-daemon --blockdev null-co,size=$((16*(1024**3))),node-name=data --nbd-server addr.type=unix,addr.path=/tmp/nbd.sock --export nbd,id=exp0,node-name=data,writable=on
# nbd-client -unix -N data /tmp/nbd.sock /dev/nbd0
# qemu-img bench -f host_device -w -s 4k -c 1000000 -t none -i io_uring /dev/nbd0

I couldn't trigger the problem with TCP or without the io_uring backend
(i.e. using Linux AIO or the thread pool) for 'qemu-img bench'.

Kevin

Re: Kernel NBD client waits on wrong cookie, aborts connection

[Ming Lei]

On Tue, Oct 15, 2024 at 6:22 PM Kevin Wolf <kwolf@redhat.com> wrote:
>
> Hi all,
>
> the other day I was running some benchmarks to compare different QEMU
> block exports, and one of the scenarios I was interested in was
> exporting NBD from qemu-storage-daemon over a unix socket and attaching
> it as a block device using the kernel NBD client. I would then run a VM
> on top of it and fio inside of it.
>
> Unfortunately, I couldn't get any numbers because the connection always
> aborted with messages like "Double reply on req ..." or "Unexpected
> reply ..." in the host kernel log.
>
> Yesterday I found some time to have a closer look why this is happening,
> and I think I have a rough understanding of what's going on now. Look at
> these trace events:
>
>         qemu-img-51025   [005] ..... 19503.285423: nbd_header_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005a
> [...]
>         qemu-img-51025   [008] ..... 19503.285500: nbd_payload_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005d
> [...]
>    kworker/u49:1-47350   [004] ..... 19503.285514: nbd_header_received: nbd transport event: request 00000000b79e7443, handle 0x0000150c0000005a
>
> This is the same request, but the handle has changed between
> nbd_header_sent and nbd_payload_sent! I think this means that we hit one
> of the cases where the request is requeued, and then the next time it
> is executed with a different blk-mq tag, which is something the nbd
> driver doesn't seem to expect.
>
> Of course, since the cookie is transmitted in the header, the server
> replies with the original handle that contains the tag from the first
> call, while the kernel is only waiting for a handle with the new tag and
> is confused by the server response.
>
> I'm not sure yet which of the following options should be considered the
> real problem here, so I'm only describing the situation without trying
> to provide a patch:
>
> 1. Is it that blk-mq should always re-run the request with the same tag?
>    I don't expect so, though in practice I was surprised to see that it
>    happens quite often after nbd requeues a request that it actually
>    does end up with the same cookie again.

No.

request->tag will change, but we may take ->internal_tag(sched) or
->tag(none), which won't change.

I guess was_interrupted() in nbd_send_cmd() is triggered, then the payload
is sent with a different tag.

I will try to cook one patch soon.

Thanks,
Ming

Re: Kernel NBD client waits on wrong cookie, aborts connection

[Ming Lei]

On Tue, Oct 15, 2024 at 08:01:43PM +0800, Ming Lei wrote:
> On Tue, Oct 15, 2024 at 6:22 PM Kevin Wolf <kwolf@redhat.com> wrote:
> >
> > Hi all,
> >
> > the other day I was running some benchmarks to compare different QEMU
> > block exports, and one of the scenarios I was interested in was
> > exporting NBD from qemu-storage-daemon over a unix socket and attaching
> > it as a block device using the kernel NBD client. I would then run a VM
> > on top of it and fio inside of it.
> >
> > Unfortunately, I couldn't get any numbers because the connection always
> > aborted with messages like "Double reply on req ..." or "Unexpected
> > reply ..." in the host kernel log.
> >
> > Yesterday I found some time to have a closer look why this is happening,
> > and I think I have a rough understanding of what's going on now. Look at
> > these trace events:
> >
> >         qemu-img-51025   [005] ..... 19503.285423: nbd_header_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005a
> > [...]
> >         qemu-img-51025   [008] ..... 19503.285500: nbd_payload_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005d
> > [...]
> >    kworker/u49:1-47350   [004] ..... 19503.285514: nbd_header_received: nbd transport event: request 00000000b79e7443, handle 0x0000150c0000005a
> >
> > This is the same request, but the handle has changed between
> > nbd_header_sent and nbd_payload_sent! I think this means that we hit one
> > of the cases where the request is requeued, and then the next time it
> > is executed with a different blk-mq tag, which is something the nbd
> > driver doesn't seem to expect.
> >
> > Of course, since the cookie is transmitted in the header, the server
> > replies with the original handle that contains the tag from the first
> > call, while the kernel is only waiting for a handle with the new tag and
> > is confused by the server response.
> >
> > I'm not sure yet which of the following options should be considered the
> > real problem here, so I'm only describing the situation without trying
> > to provide a patch:
> >
> > 1. Is it that blk-mq should always re-run the request with the same tag?
> >    I don't expect so, though in practice I was surprised to see that it
> >    happens quite often after nbd requeues a request that it actually
> >    does end up with the same cookie again.
> 
> No.
> 
> request->tag will change, but we may take ->internal_tag(sched) or
> ->tag(none), which won't change.
> 
> I guess was_interrupted() in nbd_send_cmd() is triggered, then the payload
> is sent with a different tag.
> 
> I will try to cook one patch soon.

Please try the following patch:


diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 2cafcf11ee8b..e3eb31c3ee75 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -682,3 +682,16 @@ u32 blk_mq_unique_tag(struct request *rq)
 		(rq->tag & BLK_MQ_UNIQUE_TAG_MASK);
 }
 EXPORT_SYMBOL(blk_mq_unique_tag);
+
+/*
+ * Same with blk_mq_unique_tag, but one persistent tag is included in
+ * the request lifetime.
+ */
+u32 blk_mq_unique_static_tag(struct request *rq)
+{
+	u32 tag = rq->q->elevator ? rq->internal_tag : rq->tag;
+
+	return (rq->mq_hctx->queue_num << BLK_MQ_UNIQUE_TAG_BITS) |
+		(tag & BLK_MQ_UNIQUE_TAG_MASK);
+}
+EXPORT_SYMBOL(blk_mq_unique_static_tag);
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index b852050d8a96..cc522a2cb9fb 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -201,7 +201,7 @@ static void nbd_requeue_cmd(struct nbd_cmd *cmd)
 static u64 nbd_cmd_handle(struct nbd_cmd *cmd)
 {
 	struct request *req = blk_mq_rq_from_pdu(cmd);
-	u32 tag = blk_mq_unique_tag(req);
+	u32 tag = blk_mq_unique_static_tag(req);
 	u64 cookie = cmd->cmd_cookie;
 
 	return (cookie << NBD_COOKIE_BITS) | tag;
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 4fecf46ef681..d6266759d62d 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -793,6 +793,7 @@ enum {
 };
 
 u32 blk_mq_unique_tag(struct request *rq);
+u32 blk_mq_unique_static_tag(struct request *rq);
 
 static inline u16 blk_mq_unique_tag_to_hwq(u32 unique_tag)
 {

-- 
Ming

Re: Kernel NBD client waits on wrong cookie, aborts connection

[Ming Lei]

On Tue, Oct 15, 2024 at 8:11 PM Ming Lei <ming.lei@redhat.com> wrote:
>
> On Tue, Oct 15, 2024 at 08:01:43PM +0800, Ming Lei wrote:
> > On Tue, Oct 15, 2024 at 6:22 PM Kevin Wolf <kwolf@redhat.com> wrote:
> > >
> > > Hi all,
> > >
> > > the other day I was running some benchmarks to compare different QEMU
> > > block exports, and one of the scenarios I was interested in was
> > > exporting NBD from qemu-storage-daemon over a unix socket and attaching
> > > it as a block device using the kernel NBD client. I would then run a VM
> > > on top of it and fio inside of it.
> > >
> > > Unfortunately, I couldn't get any numbers because the connection always
> > > aborted with messages like "Double reply on req ..." or "Unexpected
> > > reply ..." in the host kernel log.
> > >
> > > Yesterday I found some time to have a closer look why this is happening,
> > > and I think I have a rough understanding of what's going on now. Look at
> > > these trace events:
> > >
> > >         qemu-img-51025   [005] ..... 19503.285423: nbd_header_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005a
> > > [...]
> > >         qemu-img-51025   [008] ..... 19503.285500: nbd_payload_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005d
> > > [...]
> > >    kworker/u49:1-47350   [004] ..... 19503.285514: nbd_header_received: nbd transport event: request 00000000b79e7443, handle 0x0000150c0000005a
> > >
> > > This is the same request, but the handle has changed between
> > > nbd_header_sent and nbd_payload_sent! I think this means that we hit one
> > > of the cases where the request is requeued, and then the next time it
> > > is executed with a different blk-mq tag, which is something the nbd
> > > driver doesn't seem to expect.
> > >
> > > Of course, since the cookie is transmitted in the header, the server
> > > replies with the original handle that contains the tag from the first
> > > call, while the kernel is only waiting for a handle with the new tag and
> > > is confused by the server response.
> > >
> > > I'm not sure yet which of the following options should be considered the
> > > real problem here, so I'm only describing the situation without trying
> > > to provide a patch:
> > >
> > > 1. Is it that blk-mq should always re-run the request with the same tag?
> > >    I don't expect so, though in practice I was surprised to see that it
> > >    happens quite often after nbd requeues a request that it actually
> > >    does end up with the same cookie again.
> >
> > No.
> >
> > request->tag will change, but we may take ->internal_tag(sched) or
> > ->tag(none), which won't change.
> >
> > I guess was_interrupted() in nbd_send_cmd() is triggered, then the payload
> > is sent with a different tag.
> >
> > I will try to cook one patch soon.
>
> Please try the following patch:

Oops, please ignore the patch, it can't work since
nbd_handle_reply() doesn't know static tag.

Thanks,

Re: Kernel NBD client waits on wrong cookie, aborts connection

[Ming Lei]

On Tue, Oct 15, 2024 at 08:15:17PM +0800, Ming Lei wrote:
> On Tue, Oct 15, 2024 at 8:11 PM Ming Lei <ming.lei@redhat.com> wrote:
> >
> > On Tue, Oct 15, 2024 at 08:01:43PM +0800, Ming Lei wrote:
> > > On Tue, Oct 15, 2024 at 6:22 PM Kevin Wolf <kwolf@redhat.com> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > the other day I was running some benchmarks to compare different QEMU
> > > > block exports, and one of the scenarios I was interested in was
> > > > exporting NBD from qemu-storage-daemon over a unix socket and attaching
> > > > it as a block device using the kernel NBD client. I would then run a VM
> > > > on top of it and fio inside of it.
> > > >
> > > > Unfortunately, I couldn't get any numbers because the connection always
> > > > aborted with messages like "Double reply on req ..." or "Unexpected
> > > > reply ..." in the host kernel log.
> > > >
> > > > Yesterday I found some time to have a closer look why this is happening,
> > > > and I think I have a rough understanding of what's going on now. Look at
> > > > these trace events:
> > > >
> > > >         qemu-img-51025   [005] ..... 19503.285423: nbd_header_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005a
> > > > [...]
> > > >         qemu-img-51025   [008] ..... 19503.285500: nbd_payload_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005d
> > > > [...]
> > > >    kworker/u49:1-47350   [004] ..... 19503.285514: nbd_header_received: nbd transport event: request 00000000b79e7443, handle 0x0000150c0000005a
> > > >
> > > > This is the same request, but the handle has changed between
> > > > nbd_header_sent and nbd_payload_sent! I think this means that we hit one
> > > > of the cases where the request is requeued, and then the next time it
> > > > is executed with a different blk-mq tag, which is something the nbd
> > > > driver doesn't seem to expect.
> > > >
> > > > Of course, since the cookie is transmitted in the header, the server
> > > > replies with the original handle that contains the tag from the first
> > > > call, while the kernel is only waiting for a handle with the new tag and
> > > > is confused by the server response.
> > > >
> > > > I'm not sure yet which of the following options should be considered the
> > > > real problem here, so I'm only describing the situation without trying
> > > > to provide a patch:
> > > >
> > > > 1. Is it that blk-mq should always re-run the request with the same tag?
> > > >    I don't expect so, though in practice I was surprised to see that it
> > > >    happens quite often after nbd requeues a request that it actually
> > > >    does end up with the same cookie again.
> > >
> > > No.
> > >
> > > request->tag will change, but we may take ->internal_tag(sched) or
> > > ->tag(none), which won't change.
> > >
> > > I guess was_interrupted() in nbd_send_cmd() is triggered, then the payload
> > > is sent with a different tag.
> > >
> > > I will try to cook one patch soon.
> >
> > Please try the following patch:
> 
> Oops, please ignore the patch, it can't work since
> nbd_handle_reply() doesn't know static tag.

Please try the v2:


diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 2cafcf11ee8b..8bad4030b2e4 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -682,3 +682,31 @@ u32 blk_mq_unique_tag(struct request *rq)
 		(rq->tag & BLK_MQ_UNIQUE_TAG_MASK);
 }
 EXPORT_SYMBOL(blk_mq_unique_tag);
+
+/*
+ * Same with blk_mq_unique_tag, but one persistent tag is included in
+ * the request lifetime.
+ */
+u32 blk_mq_unique_static_tag(struct request *rq)
+{
+	u32 tag = rq->q->elevator ? rq->internal_tag : rq->tag;
+
+	return (rq->mq_hctx->queue_num << BLK_MQ_UNIQUE_TAG_BITS) |
+		(tag & BLK_MQ_UNIQUE_TAG_MASK);
+}
+EXPORT_SYMBOL(blk_mq_unique_static_tag);
+
+struct request *blk_mq_static_tag_to_req(struct request_queue *q, u32 uniq_tag)
+{
+	unsigned long hwq = blk_mq_unique_tag_to_hwq(uniq_tag);
+	u32 tag = blk_mq_unique_tag_to_tag(uniq_tag);
+	const struct blk_mq_hw_ctx *hctx= xa_load(&q->hctx_table, hwq);
+
+	if (!hctx)
+		return NULL;
+
+	if (q->elevator)
+		return hctx->sched_tags->static_rqs[tag];
+	return hctx->tags->static_rqs[tag];
+}
+EXPORT_SYMBOL(blk_mq_static_tag_to_req);
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index b852050d8a96..5be324233c9f 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -201,7 +201,7 @@ static void nbd_requeue_cmd(struct nbd_cmd *cmd)
 static u64 nbd_cmd_handle(struct nbd_cmd *cmd)
 {
 	struct request *req = blk_mq_rq_from_pdu(cmd);
-	u32 tag = blk_mq_unique_tag(req);
+	u32 tag = blk_mq_unique_static_tag(req);
 	u64 cookie = cmd->cmd_cookie;
 
 	return (cookie << NBD_COOKIE_BITS) | tag;
@@ -818,10 +818,7 @@ static struct nbd_cmd *nbd_handle_reply(struct nbd_device *nbd, int index,
 
 	handle = be64_to_cpu(reply->cookie);
 	tag = nbd_handle_to_tag(handle);
-	hwq = blk_mq_unique_tag_to_hwq(tag);
-	if (hwq < nbd->tag_set.nr_hw_queues)
-		req = blk_mq_tag_to_rq(nbd->tag_set.tags[hwq],
-				       blk_mq_unique_tag_to_tag(tag));
+	req = blk_mq_static_tag_to_req(nbd->disk->queue, tag);
 	if (!req || !blk_mq_request_started(req)) {
 		dev_err(disk_to_dev(nbd->disk), "Unexpected reply (%d) %p\n",
 			tag, req);
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 4fecf46ef681..9c4ef3f16a77 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -793,6 +793,8 @@ enum {
 };
 
 u32 blk_mq_unique_tag(struct request *rq);
+u32 blk_mq_unique_static_tag(struct request *rq);
+struct request *blk_mq_static_tag_to_req(struct request_queue *q, u32 tag);
 
 static inline u16 blk_mq_unique_tag_to_hwq(u32 unique_tag)
 {

-- 
Ming

Re: Kernel NBD client waits on wrong cookie, aborts connection

[Kevin Wolf]

Am 15.10.2024 um 14:59 hat Ming Lei geschrieben:
> On Tue, Oct 15, 2024 at 08:15:17PM +0800, Ming Lei wrote:
> > On Tue, Oct 15, 2024 at 8:11 PM Ming Lei <ming.lei@redhat.com> wrote:
> > >
> > > On Tue, Oct 15, 2024 at 08:01:43PM +0800, Ming Lei wrote:
> > > > On Tue, Oct 15, 2024 at 6:22 PM Kevin Wolf <kwolf@redhat.com> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > the other day I was running some benchmarks to compare different QEMU
> > > > > block exports, and one of the scenarios I was interested in was
> > > > > exporting NBD from qemu-storage-daemon over a unix socket and attaching
> > > > > it as a block device using the kernel NBD client. I would then run a VM
> > > > > on top of it and fio inside of it.
> > > > >
> > > > > Unfortunately, I couldn't get any numbers because the connection always
> > > > > aborted with messages like "Double reply on req ..." or "Unexpected
> > > > > reply ..." in the host kernel log.
> > > > >
> > > > > Yesterday I found some time to have a closer look why this is happening,
> > > > > and I think I have a rough understanding of what's going on now. Look at
> > > > > these trace events:
> > > > >
> > > > >         qemu-img-51025   [005] ..... 19503.285423: nbd_header_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005a
> > > > > [...]
> > > > >         qemu-img-51025   [008] ..... 19503.285500: nbd_payload_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005d
> > > > > [...]
> > > > >    kworker/u49:1-47350   [004] ..... 19503.285514: nbd_header_received: nbd transport event: request 00000000b79e7443, handle 0x0000150c0000005a
> > > > >
> > > > > This is the same request, but the handle has changed between
> > > > > nbd_header_sent and nbd_payload_sent! I think this means that we hit one
> > > > > of the cases where the request is requeued, and then the next time it
> > > > > is executed with a different blk-mq tag, which is something the nbd
> > > > > driver doesn't seem to expect.
> > > > >
> > > > > Of course, since the cookie is transmitted in the header, the server
> > > > > replies with the original handle that contains the tag from the first
> > > > > call, while the kernel is only waiting for a handle with the new tag and
> > > > > is confused by the server response.
> > > > >
> > > > > I'm not sure yet which of the following options should be considered the
> > > > > real problem here, so I'm only describing the situation without trying
> > > > > to provide a patch:
> > > > >
> > > > > 1. Is it that blk-mq should always re-run the request with the same tag?
> > > > >    I don't expect so, though in practice I was surprised to see that it
> > > > >    happens quite often after nbd requeues a request that it actually
> > > > >    does end up with the same cookie again.
> > > >
> > > > No.
> > > >
> > > > request->tag will change, but we may take ->internal_tag(sched) or
> > > > ->tag(none), which won't change.
> > > >
> > > > I guess was_interrupted() in nbd_send_cmd() is triggered, then the payload
> > > > is sent with a different tag.
> > > >
> > > > I will try to cook one patch soon.
> > >
> > > Please try the following patch:
> > 
> > Oops, please ignore the patch, it can't work since
> > nbd_handle_reply() doesn't know static tag.
> 
> Please try the v2:

It doesn't fully work, though it replaced the bug with a different one.
Now I get "Unexpected request" for the final flush request.

Anyway, before talking about specific patches, would this even be the
right solution or would it only paper over a bigger issue?

Is getting a different tag the only thing that can go wrong if you
handle a request partially and then requeue it?

Kevin

Re: Kernel NBD client waits on wrong cookie, aborts connection

[Ming Lei]

[-- Attachment #1: Type: text/plain, Size: 4608 bytes --]

On Tue, Oct 15, 2024 at 06:06:01PM +0200, Kevin Wolf wrote:
> Am 15.10.2024 um 14:59 hat Ming Lei geschrieben:
> > On Tue, Oct 15, 2024 at 08:15:17PM +0800, Ming Lei wrote:
> > > On Tue, Oct 15, 2024 at 8:11 PM Ming Lei <ming.lei@redhat.com> wrote:
> > > >
> > > > On Tue, Oct 15, 2024 at 08:01:43PM +0800, Ming Lei wrote:
> > > > > On Tue, Oct 15, 2024 at 6:22 PM Kevin Wolf <kwolf@redhat.com> wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > the other day I was running some benchmarks to compare different QEMU
> > > > > > block exports, and one of the scenarios I was interested in was
> > > > > > exporting NBD from qemu-storage-daemon over a unix socket and attaching
> > > > > > it as a block device using the kernel NBD client. I would then run a VM
> > > > > > on top of it and fio inside of it.
> > > > > >
> > > > > > Unfortunately, I couldn't get any numbers because the connection always
> > > > > > aborted with messages like "Double reply on req ..." or "Unexpected
> > > > > > reply ..." in the host kernel log.
> > > > > >
> > > > > > Yesterday I found some time to have a closer look why this is happening,
> > > > > > and I think I have a rough understanding of what's going on now. Look at
> > > > > > these trace events:
> > > > > >
> > > > > >         qemu-img-51025   [005] ..... 19503.285423: nbd_header_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005a
> > > > > > [...]
> > > > > >         qemu-img-51025   [008] ..... 19503.285500: nbd_payload_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005d
> > > > > > [...]
> > > > > >    kworker/u49:1-47350   [004] ..... 19503.285514: nbd_header_received: nbd transport event: request 00000000b79e7443, handle 0x0000150c0000005a
> > > > > >
> > > > > > This is the same request, but the handle has changed between
> > > > > > nbd_header_sent and nbd_payload_sent! I think this means that we hit one
> > > > > > of the cases where the request is requeued, and then the next time it
> > > > > > is executed with a different blk-mq tag, which is something the nbd
> > > > > > driver doesn't seem to expect.
> > > > > >
> > > > > > Of course, since the cookie is transmitted in the header, the server
> > > > > > replies with the original handle that contains the tag from the first
> > > > > > call, while the kernel is only waiting for a handle with the new tag and
> > > > > > is confused by the server response.
> > > > > >
> > > > > > I'm not sure yet which of the following options should be considered the
> > > > > > real problem here, so I'm only describing the situation without trying
> > > > > > to provide a patch:
> > > > > >
> > > > > > 1. Is it that blk-mq should always re-run the request with the same tag?
> > > > > >    I don't expect so, though in practice I was surprised to see that it
> > > > > >    happens quite often after nbd requeues a request that it actually
> > > > > >    does end up with the same cookie again.
> > > > >
> > > > > No.
> > > > >
> > > > > request->tag will change, but we may take ->internal_tag(sched) or
> > > > > ->tag(none), which won't change.
> > > > >
> > > > > I guess was_interrupted() in nbd_send_cmd() is triggered, then the payload
> > > > > is sent with a different tag.
> > > > >
> > > > > I will try to cook one patch soon.
> > > >
> > > > Please try the following patch:
> > > 
> > > Oops, please ignore the patch, it can't work since
> > > nbd_handle_reply() doesn't know static tag.
> > 
> > Please try the v2:
> 
> It doesn't fully work, though it replaced the bug with a different one.
> Now I get "Unexpected request" for the final flush request.

That just shows the approach is working.

Flush request doesn't have static tag, that is why it is failed.
It shouldn't be hard to cover it, please try the attached & revised
patch.

Another solution is to add per-nbd-device map for retrieving nbd_cmd
by the stored `index` in cookie, and the cost is one such array for
each device.

> 
> Anyway, before talking about specific patches, would this even be the
> right solution or would it only paper over a bigger issue?
> 
> Is getting a different tag the only thing that can go wrong if you
> handle a request partially and then requeue it?

Strictly speaking it is BLK_STS_RESOURCE.

Not like userspace implementation, kernel nbd call one sock_sendmsg()
for sending either request header, or each single data bvec, so partial xmit
can't be avoided. This kind of handling is fine, given TCP is just
byte stream, nothing difference is observed from nbd server side if
data is correct.


Thanks,
Ming

[-- Attachment #2: static-tag.patch --]
[-- Type: text/plain, Size: 3010 bytes --]

diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 2cafcf11ee8b..3cc14fc76546 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -682,3 +682,51 @@ u32 blk_mq_unique_tag(struct request *rq)
 		(rq->tag & BLK_MQ_UNIQUE_TAG_MASK);
 }
 EXPORT_SYMBOL(blk_mq_unique_tag);
+
+/* Same with blk_mq_unique_tag, but one persistent tag is included */
+u32 blk_mq_unique_static_tag(struct request *rq)
+{
+	bool use_sched = rq->q->elevator;
+	u32 tag;
+
+	if (rq == rq->mq_hctx->fq->flush_rq) {
+		if (use_sched)
+			tag = rq->mq_hctx->sched_tags->nr_tags;
+		else
+			tag = rq->mq_hctx->tags->nr_tags;
+	} else {
+		tag = use_sched ? rq->internal_tag : rq->tag;
+	}
+
+	return (rq->mq_hctx->queue_num << BLK_MQ_UNIQUE_TAG_BITS) |
+		(tag & BLK_MQ_UNIQUE_TAG_MASK);
+}
+EXPORT_SYMBOL(blk_mq_unique_static_tag);
+
+static struct request *
+__blk_mq_static_tag_to_rq(const struct blk_mq_hw_ctx *hctx,
+		const struct blk_mq_tags *tags, u32 tag)
+{
+	if (tag < tags->nr_tags)
+		return tags->static_rqs[tag];
+	else if (tag == tags->nr_tags)
+		return hctx->fq->flush_rq;
+	else
+		return NULL;
+}
+
+struct request *blk_mq_static_tag_to_req(struct request_queue *q, u32 uniq_tag)
+{
+	unsigned long hwq = blk_mq_unique_tag_to_hwq(uniq_tag);
+	u32 tag = blk_mq_unique_tag_to_tag(uniq_tag);
+	const struct blk_mq_hw_ctx *hctx= xa_load(&q->hctx_table, hwq);
+
+	if (!hctx)
+		return NULL;
+
+	if (q->elevator)
+		return __blk_mq_static_tag_to_rq(hctx, hctx->sched_tags, tag);
+
+	return __blk_mq_static_tag_to_rq(hctx, hctx->tags, tag);
+}
+EXPORT_SYMBOL(blk_mq_static_tag_to_req);
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index b852050d8a96..5be324233c9f 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -201,7 +201,7 @@ static void nbd_requeue_cmd(struct nbd_cmd *cmd)
 static u64 nbd_cmd_handle(struct nbd_cmd *cmd)
 {
 	struct request *req = blk_mq_rq_from_pdu(cmd);
-	u32 tag = blk_mq_unique_tag(req);
+	u32 tag = blk_mq_unique_static_tag(req);
 	u64 cookie = cmd->cmd_cookie;
 
 	return (cookie << NBD_COOKIE_BITS) | tag;
@@ -818,10 +818,7 @@ static struct nbd_cmd *nbd_handle_reply(struct nbd_device *nbd, int index,
 
 	handle = be64_to_cpu(reply->cookie);
 	tag = nbd_handle_to_tag(handle);
-	hwq = blk_mq_unique_tag_to_hwq(tag);
-	if (hwq < nbd->tag_set.nr_hw_queues)
-		req = blk_mq_tag_to_rq(nbd->tag_set.tags[hwq],
-				       blk_mq_unique_tag_to_tag(tag));
+	req = blk_mq_static_tag_to_req(nbd->disk->queue, tag);
 	if (!req || !blk_mq_request_started(req)) {
 		dev_err(disk_to_dev(nbd->disk), "Unexpected reply (%d) %p\n",
 			tag, req);
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 4fecf46ef681..9c4ef3f16a77 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -793,6 +793,8 @@ enum {
 };
 
 u32 blk_mq_unique_tag(struct request *rq);
+u32 blk_mq_unique_static_tag(struct request *rq);
+struct request *blk_mq_static_tag_to_req(struct request_queue *q, u32 tag);
 
 static inline u16 blk_mq_unique_tag_to_hwq(u32 unique_tag)
 {

UNSUBSCRIBE

[Simon Fernandez]

> On 16 Oct 2024, at 03:20, Ming Lei <ming.lei@redhat.com> wrote:
> 
> On Tue, Oct 15, 2024 at 06:06:01PM +0200, Kevin Wolf wrote:
>> Am 15.10.2024 um 14:59 hat Ming Lei geschrieben:
>>> On Tue, Oct 15, 2024 at 08:15:17PM +0800, Ming Lei wrote:
>>>> On Tue, Oct 15, 2024 at 8:11 PM Ming Lei <ming.lei@redhat.com> wrote:
>>>>> 
>>>>> On Tue, Oct 15, 2024 at 08:01:43PM +0800, Ming Lei wrote:
>>>>>> On Tue, Oct 15, 2024 at 6:22 PM Kevin Wolf <kwolf@redhat.com> wrote:
>>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> the other day I was running some benchmarks to compare different QEMU
>>>>>>> block exports, and one of the scenarios I was interested in was
>>>>>>> exporting NBD from qemu-storage-daemon over a unix socket and attaching
>>>>>>> it as a block device using the kernel NBD client. I would then run a VM
>>>>>>> on top of it and fio inside of it.
>>>>>>> 
>>>>>>> Unfortunately, I couldn't get any numbers because the connection always
>>>>>>> aborted with messages like "Double reply on req ..." or "Unexpected
>>>>>>> reply ..." in the host kernel log.
>>>>>>> 
>>>>>>> Yesterday I found some time to have a closer look why this is happening,
>>>>>>> and I think I have a rough understanding of what's going on now. Look at
>>>>>>> these trace events:
>>>>>>> 
>>>>>>>        qemu-img-51025   [005] ..... 19503.285423: nbd_header_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005a
>>>>>>> [...]
>>>>>>>        qemu-img-51025   [008] ..... 19503.285500: nbd_payload_sent: nbd transport event: request 000000002df03708, handle 0x0000150c0000005d
>>>>>>> [...]
>>>>>>>   kworker/u49:1-47350   [004] ..... 19503.285514: nbd_header_received: nbd transport event: request 00000000b79e7443, handle 0x0000150c0000005a
>>>>>>> 
>>>>>>> This is the same request, but the handle has changed between
>>>>>>> nbd_header_sent and nbd_payload_sent! I think this means that we hit one
>>>>>>> of the cases where the request is requeued, and then the next time it
>>>>>>> is executed with a different blk-mq tag, which is something the nbd
>>>>>>> driver doesn't seem to expect.
>>>>>>> 
>>>>>>> Of course, since the cookie is transmitted in the header, the server
>>>>>>> replies with the original handle that contains the tag from the first
>>>>>>> call, while the kernel is only waiting for a handle with the new tag and
>>>>>>> is confused by the server response.
>>>>>>> 
>>>>>>> I'm not sure yet which of the following options should be considered the
>>>>>>> real problem here, so I'm only describing the situation without trying
>>>>>>> to provide a patch:
>>>>>>> 
>>>>>>> 1. Is it that blk-mq should always re-run the request with the same tag?
>>>>>>>   I don't expect so, though in practice I was surprised to see that it
>>>>>>>   happens quite often after nbd requeues a request that it actually
>>>>>>>   does end up with the same cookie again.
>>>>>> 
>>>>>> No.
>>>>>> 
>>>>>> request->tag will change, but we may take ->internal_tag(sched) or
>>>>>> ->tag(none), which won't change.
>>>>>> 
>>>>>> I guess was_interrupted() in nbd_send_cmd() is triggered, then the payload
>>>>>> is sent with a different tag.
>>>>>> 
>>>>>> I will try to cook one patch soon.
>>>>> 
>>>>> Please try the following patch:
>>>> 
>>>> Oops, please ignore the patch, it can't work since
>>>> nbd_handle_reply() doesn't know static tag.
>>> 
>>> Please try the v2:
>> 
>> It doesn't fully work, though it replaced the bug with a different one.
>> Now I get "Unexpected request" for the final flush request.
> 
> That just shows the approach is working.
> 
> Flush request doesn't have static tag, that is why it is failed.
> It shouldn't be hard to cover it, please try the attached & revised
> patch.
> 
> Another solution is to add per-nbd-device map for retrieving nbd_cmd
> by the stored `index` in cookie, and the cost is one such array for
> each device.
> 
>> 
>> Anyway, before talking about specific patches, would this even be the
>> right solution or would it only paper over a bigger issue?
>> 
>> Is getting a different tag the only thing that can go wrong if you
>> handle a request partially and then requeue it?
> 
> Strictly speaking it is BLK_STS_RESOURCE.
> 
> Not like userspace implementation, kernel nbd call one sock_sendmsg()
> for sending either request header, or each single data bvec, so partial xmit
> can't be avoided. This kind of handling is fine, given TCP is just
> byte stream, nothing difference is observed from nbd server side if
> data is correct.
> 
> 
> Thanks,
> Ming
> <static-tag.patch>

Unsubscribe

[Ed Reel]

-- 
"God gave us two ears and one mouth to remind us we should listen
twice as much as we talk."

unsubscribe

[michael.steinmann]

Unsubscribe

[michael.steinmann]

unsubscribe

[Dirk Wallenstein]

Unsubscribe from all and everything. Please.

-- 
Mit freundlichen Grüßen, Dirk Wallenstein

unsubscribe

[Delyan Raychev]

unsubscribe

lvm2 deadlock

[Jaco Kroon]

Hi,

Possible lvm2 command deadlock scenario:

crowsnest [12:15:47] /run/lvm # fuser //run/lock/lvm/*
/run/lock/lvm/P_global: 17231
/run/lock/lvm/V_lvm: 16087 17231

crowsnest [12:15:54] /run/lvm # ps axf | grep -E '16087|17231'
24437 pts/1    S+     0:00  |       \_ grep --colour=auto -E 16087|17231
16087 ?        S      0:00  |       |       \_ /sbin/lvcreate -kn -An -s 
-n fsck_cerberus /dev/lvm/backup_cerberus
17231 ?        S      0:00  |           \_ /sbin/lvs --noheadings 
--nameprefixes

crowsnest [12:17:40] /run/lvm # dmsetup udevcookies
Cookie       Semid      Value      Last semop time           Last change 
time
0xd4d2051    10         1          Thu May 30 02:34:05 2024  Thu May 30 
02:32:22 2024

This was almost 10 hours ago.

crowsnest [12:17:44] /run/lvm # dmsetup udevcomplete 0xd4d2051
DM_COOKIE_COMPLETED=0xd4d2051
crowsnest [12:18:43] /run/lvm # ps axf | grep -E '16087|17231'
27252 pts/1    S+     0:00  |       \_ grep --colour=auto -E 16087|17231
crowsnest [12:18:45] /run/lvm #

Allows progress again.

I do not know how to troubleshoot this.

Kernel version 6.4.12 (in process of upgrading to 6.9.3).

crowsnest [12:19:47] /run/lvm # udevadm --version
254

aka systemd-utils-254.10

lvm2-2.03.22

Kind regards,
Jaco

Re: lvm2 deadlock

[Zdenek Kabelac]

Dne 30. 05. 24 v 12:21 Jaco Kroon napsal(a):
> Hi,
> 
> Possible lvm2 command deadlock scenario:
> 
> crowsnest [12:15:47] /run/lvm # fuser //run/lock/lvm/*
> /run/lock/lvm/P_global: 17231
> /run/lock/lvm/V_lvm: 16087 17231
> 
> crowsnest [12:15:54] /run/lvm # ps axf | grep -E '16087|17231'
> 24437 pts/1    S+     0:00  |       \_ grep --colour=auto -E 16087|17231
> 16087 ?        S      0:00  |       |       \_ /sbin/lvcreate -kn -An -s -n 
> fsck_cerberus /dev/lvm/backup_cerberus
> 17231 ?        S      0:00  |           \_ /sbin/lvs --noheadings --nameprefixes
> 
> crowsnest [12:17:40] /run/lvm # dmsetup udevcookies
> Cookie       Semid      Value      Last semop time           Last change time
> 0xd4d2051    10         1          Thu May 30 02:34:05 2024  Thu May 30 
> 02:32:22 2024
> 
> This was almost 10 hours ago.
> 
> crowsnest [12:17:44] /run/lvm # dmsetup udevcomplete 0xd4d2051
> DM_COOKIE_COMPLETED=0xd4d2051
> crowsnest [12:18:43] /run/lvm # ps axf | grep -E '16087|17231'
> 27252 pts/1    S+     0:00  |       \_ grep --colour=auto -E 16087|17231
> crowsnest [12:18:45] /run/lvm #
> 
> Allows progress again.

Hi

I'm kind of missing here to see your 'deadlock' scenario from this description.

Lvm2 takes the VG lock - creates LV - waits for udev till it's finished with 
its job and confirms all the udev work with dmsetup udevcomplete.

If something 'kills'  your udev worker  (which may eventually happen on some 
'very very very' busy system - you may need to set up longer timeout for 
systemd to kill udev worker (I believe it's just 30seconds by default).

If it happens your cookies blocks your lvm2 command - you can 'unblock' them 
with  'dmsetup udevcomplete_all'  -  but that's a sign your system is already 
in very bad state.

It's also unclear which OS are you using - Debian, Fedora, ???
Version of your packages ?

Regards

Zdenek

Re: lvm2 deadlock

[Jaco Kroon]

Hi,

Thanks for the insight.  Please refer below.

On 2024/05/31 14:34, Zdenek Kabelac wrote:
> Dne 30. 05. 24 v 12:21 Jaco Kroon napsal(a):
>> Hi,
>>
>> Possible lvm2 command deadlock scenario:
>>
>> crowsnest [12:15:47] /run/lvm # fuser //run/lock/lvm/*
>> /run/lock/lvm/P_global: 17231
>> /run/lock/lvm/V_lvm: 16087 17231
>>
>> crowsnest [12:15:54] /run/lvm # ps axf | grep -E '16087|17231'
>> 24437 pts/1    S+     0:00  |       \_ grep --colour=auto -E 16087|17231
>> 16087 ?        S      0:00  |       |       \_ /sbin/lvcreate -kn -An 
>> -s -n fsck_cerberus /dev/lvm/backup_cerberus
>> 17231 ?        S      0:00  |           \_ /sbin/lvs --noheadings 
>> --nameprefixes
>>
>> crowsnest [12:17:40] /run/lvm # dmsetup udevcookies
>> Cookie       Semid      Value      Last semop time Last change time
>> 0xd4d2051    10         1          Thu May 30 02:34:05 2024  Thu May 
>> 30 02:32:22 2024
>>
>> This was almost 10 hours ago.
>>
>> crowsnest [12:17:44] /run/lvm # dmsetup udevcomplete 0xd4d2051
>> DM_COOKIE_COMPLETED=0xd4d2051
>> crowsnest [12:18:43] /run/lvm # ps axf | grep -E '16087|17231'
>> 27252 pts/1    S+     0:00  |       \_ grep --colour=auto -E 16087|17231
>> crowsnest [12:18:45] /run/lvm #
>>
>> Allows progress again.
>
> Hi
>
> I'm kind of missing here to see your 'deadlock' scenario from this 
> description.
Well, stuff blocks, until the cookie is released by using the dmset 
udevcomplete command, so wrong wording perhaps?
>
> Lvm2 takes the VG lock - creates LV - waits for udev till it's 
> finished with its job and confirms all the udev work with dmsetup 
> udevcomplete.

So what I understand from this is that udevcomplete ends up never 
executing?  Is there some way of confirming this?

>
> If something 'kills'  your udev worker  (which may eventually happen 
> on some 'very very very' busy system - you may need to set up longer 
> timeout for systemd to kill udev worker (I believe it's just 30seconds 
> by default).

Well, I guess upwards of 1GB/s of IO at times qualify.  No systemd, so 
more likely the udev configuration.  When this happens we see load 
averages upwards of 50 ... so based on that I'd say busy is probably a 
reasonable assessment.  Normally doesn't exceed load average values 
10-15 at most.

Even so ... event_timeout = 180 should be a VERY, VERY long time in 
terms of udev event processing.

I'm not seeing anything for udev in /var/log/messages (which is 
explicitly configured to log everything logged to syslog).  But it may 
also be a case of "not logging because LVM isn't processing any IO (/var 
is stored on it's own LV).

>
> If it happens your cookies blocks your lvm2 command - you can 
> 'unblock' them with  'dmsetup udevcomplete_all'  -  but that's a sign 
> your system is already in very bad state.
>
> It's also unclear which OS are you using - Debian, Fedora, ???

Gentoo.

> Version of your packages ?

I thought I did provide this:

Kernel version was 6.4.12 when this hapened, is now 6.9.3.

crowsnest [12:19:47] /run/lvm # udevadm --version
254

aka systemd-utils-254.10

lvm2-2.03.22

Thanks for the feedback, what you say makes perfect sense, and the 
implication is that there are only a few options:

1.  Something is resulting in the udev trigger to take longer than three 
minutes, and the dmsetup udevcomplete never being executed.
2.  Something goes horribly wrong during the udev trigger (which invokes 
dmsetup a few times) processing and the process crashes, never executing 
dmsetup udevcomplete.

This could potentially be due to extremely heavy disk IO, or LVM itself 
freezing IO.

Given the rulesets the only way I see this happening is if dmsetup 
command takes very long to load - and even in the degraded (most 
filesystems blocked) state it was fast to execute.

Or if udevd itself has problems accessing /sys - which I find extremely 
unlikely.

I don't see the default value for udev_log from the config. Explicitly 
set to debug now, but still not seeing anything logged to syslog.  
Running with udevd --debug, which logs to a ramdisk on /run.  Hopefully 
(if/when this happens again) that may shed some light.  There is 256GB 
of RAM available, so as long as the log doesn't grow too quickly should 
be fine.

Kind regards,
Jaco

Re: lvm2 deadlock

[Zdenek Kabelac]

Dne 03. 06. 24 v 14:56 Jaco Kroon napsal(a):
> Hi,
> 
> Thanks for the insight.  Please refer below.
> 
> On 2024/05/31 14:34, Zdenek Kabelac wrote:
>> Dne 30. 05. 24 v 12:21 Jaco Kroon napsal(a):
>>> Hi,
>>>
>> I'm kind of missing here to see your 'deadlock' scenario from this description.
> Well, stuff blocks, until the cookie is released by using the dmset 
> udevcomplete command, so wrong wording perhaps?
>>
>> Lvm2 takes the VG lock - creates LV - waits for udev till it's finished with 
>> its job and confirms all the udev work with dmsetup udevcomplete.
> 
> So what I understand from this is that udevcomplete ends up never executing?  
> Is there some way of confirming this?

udevcomplete needs  someone to create 'semaphore' for completion in the first 
place.


>>
>> It's also unclear which OS are you using - Debian, Fedora, ???
> 
> Gentoo.
> 
>> Version of your packages ?
> 
> I thought I did provide this:
> 
> Kernel version was 6.4.12 when this hapened, is now 6.9.3.
> 
> crowsnest [12:19:47] /run/lvm # udevadm --version
> 254
> 
> aka systemd-utils-254.10
> 
> lvm2-2.03.22

Since this is most likely your personal build - please provide full output of
'lvm version'  command.

For the 'udev' synchronization, there needs to be '--enable-udev_sync' 
configure option. So let's check which configure/build option were used here.
And also preferably upstream udev rules.

> 
> Thanks for the feedback, what you say makes perfect sense, and the implication 
> is that there are only a few options:
> 
> 1.  Something is resulting in the udev trigger to take longer than three 
> minutes, and the dmsetup udevcomplete never being executed.

systemd simply kills udev worker if takes too long.

However on properly running system, it would be very very unusual to hit these 
timeouts  - you would need to work with thousands of devices....

> 
> This could potentially be due to extremely heavy disk IO, or LVM itself 
> freezing IO.

well reducing the percentage of '/proc/sys/vm/dirty_ration' may possibly help
when your disk system is too slow and you create a very lengthy 'sync' io 
queues...

> I don't see the default value for udev_log from the config. Explicitly set to 
> debug now, but still not seeing anything logged to syslog. Running with udevd 
> --debug, which logs to a ramdisk on /run.  Hopefully (if/when this happens 
> again) that may shed some light.  There is 256GB of RAM available, so as long 
> as the log doesn't grow too quickly should be fine.

A lot of RAM may possibly create a huge amount of dirty pages...

Regards

Zdenek

Re: lvm2 deadlock

[Jaco Kroon]

Hi,

Please refer below.

On 2024/06/03 21:25, Zdenek Kabelac wrote:
> Dne 03. 06. 24 v 14:56 Jaco Kroon napsal(a):
>> Hi,
>>
>> Thanks for the insight.  Please refer below.
>>
>> On 2024/05/31 14:34, Zdenek Kabelac wrote:
>>> Dne 30. 05. 24 v 12:21 Jaco Kroon napsal(a):
>>>> Hi,
>>>>
>>> I'm kind of missing here to see your 'deadlock' scenario from this 
>>> description.
>> Well, stuff blocks, until the cookie is released by using the dmset 
>> udevcomplete command, so wrong wording perhaps?
>>>
>>> Lvm2 takes the VG lock - creates LV - waits for udev till it's 
>>> finished with its job and confirms all the udev work with dmsetup 
>>> udevcomplete.
>>
>> So what I understand from this is that udevcomplete ends up never 
>> executing?  Is there some way of confirming this?
>
> udevcomplete needs  someone to create 'semaphore' for completion in 
> the first place.


I'm not familiar with the LVM internals and the flows of different 
processes, even though you can probably safely consider me a "semi power 
user".  I do have compsci background, so do understand most of the 
principles of locking etc, but how they are applied in the LVM 
environment I'm clueless.

>
>
>>>
>>> It's also unclear which OS are you using - Debian, Fedora, ???
>>
>> Gentoo.
>>
>>> Version of your packages ?
>>
>> I thought I did provide this:
>>
>> Kernel version was 6.4.12 when this hapened, is now 6.9.3.
>>
>> crowsnest [12:19:47] /run/lvm # udevadm --version
>> 254
>>
>> aka systemd-utils-254.10
>>
>> lvm2-2.03.22
>
> Since this is most likely your personal build - please provide full 
> output of
> 'lvm version'  command.


crowsnest [09:46:04] ~ # lvm version
   LVM version:     2.03.22(2) (2023-08-02)
   Library version: 1.02.196 (2023-08-02)
   Driver version:  4.48.0
   Configuration:   ./configure --prefix=/usr 
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu 
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share 
--sysconfdir=/etc --localstatedir=/var/lib --datarootdir=/usr/share 
--disable-dependency-tracking --disable-silent-rules 
--docdir=/usr/share/doc/lvm2-2.03.22-r5 
--htmldir=/usr/share/doc/lvm2-2.03.22-r5/html --enable-dmfilemapd 
--enable-dmeventd --enable-cmdlib --enable-fsadm --enable-lvmpolld 
--with-mirrors=internal --with-snapshots=internal --with-thin=internal 
--with-cache=internal --with-thin-check=/usr/sbin/thin_check 
--with-cache-check=/usr/sbin/cache_check 
--with-thin-dump=/usr/sbin/thin_dump 
--with-cache-dump=/usr/sbin/cache_dump 
--with-thin-repair=/usr/sbin/thin_repair 
--with-cache-repair=/usr/sbin/cache_repair 
--with-thin-restore=/usr/sbin/thin_restore 
--with-cache-restore=/usr/sbin/cache_restore --with-symvers=gnu 
--enable-readline --disable-selinux --enable-pkgconfig 
--with-confdir=/etc --exec-prefix= --sbindir=/sbin 
--with-staticdir=/sbin --libdir=/lib64 --with-usrlibdir=/usr/lib64 
--with-default-dm-run-dir=/run --with-default-run-dir=/run/lvm 
--with-default-locking-dir=/run/lock/lvm --with-default-pid-dir=/run 
--enable-udev_rules --enable-udev_sync --with-udevdir=/lib/udev/rules.d 
--disable-lvmlockd-sanlock --disable-notify-dbus --disable-app-machineid 
--disable-systemd-journal --without-systemd-run --disable-valgrind-pool 
--with-systemdsystemunitdir=/lib/systemd/system CLDFLAGS=-Wl,-O1 
-Wl,--as-needed


>
> For the 'udev' synchronization, there needs to be '--enable-udev_sync' 
> configure option. So let's check which configure/build option were 
> used here.
> And also preferably upstream udev rules.


--enable-udev_sync all there.

To the best of my knowledge the udev rules are stock, certainly neither 
myself nor any of my colleagues modified them.  They would generally 
defer to me, and I won't touch that unless I understand the 
implications, which in this case I just don't.

>
>>
>> Thanks for the feedback, what you say makes perfect sense, and the 
>> implication is that there are only a few options:
>>
>> 1.  Something is resulting in the udev trigger to take longer than 
>> three minutes, and the dmsetup udevcomplete never being executed.
>
> systemd simply kills udev worker if takes too long.
>
> However on properly running system, it would be very very unusual to 
> hit these timeouts  - you would need to work with thousands of 
> devices....


32 physical NL-SAS drives, combined into 3 RAID6 arrays using mdadm.

These three md devices serve as PVs for LVM, single VG.

73 LVs, just over half of which are mounted.  Most of those are thin 
volumes inside:

crowsnest [09:54:04] ~ # lvdisplay /dev/lvm/thin_pool
   --- Logical volume ---
   LV Name                thin_pool
   VG Name                lvm
   LV UUID                twLSE1-3ckG-WRSO-5eHc-G3fY-YS2v-as4ABC
   LV Write Access        read/write (activated read only)
   LV Creation host, time crowsnest, 2020-02-19 12:26:00 +0200
   LV Pool metadata       thin_pool_tmeta
   LV Pool data           thin_pool_tdata
   LV Status              available
   # open                 0
   LV Size                125.00 TiB
   Allocated pool data    73.57%
   Allocated metadata     9.05%
   Current LE             32768000
   Segments               1
   Allocation             inherit
   Read ahead sectors     auto
   - currently set to     1024
   Block device           253:11

The rest are snapshots of the LVs that are mounted so that we have a 
roll-back destination in case of filesystem corruption (these snaps are 
made in multiple steps, first a snap of the origin is made, this is then 
fsck'ed, if that's successful it's fstrim'ed before being renamed into 
the final "save" location - any previously saved copy is first lvremove'd).

I'd describe that as a few tens of devices, not a few hundred and 
certainly not thousands of devices.


>
>>
>> This could potentially be due to extremely heavy disk IO, or LVM 
>> itself freezing IO.
>
> well reducing the percentage of '/proc/sys/vm/dirty_ration' may 
> possibly help
> when your disk system is too slow and you create a very lengthy 'sync' 
> io queues...


crowsnest [09:52:21] /proc/sys/vm # cat dirty_ratio
20

Happy to lower that even more if it would help.

Internet (Redhat) states:

Starts active writeback of dirty data at this percentage of total memory 
for the generator of dirty data, via pdflush. The default value is |40|.

I'm assuming the default is 20 though, not 40, since I can't find that 
I've reconfigured this value.

Should probably remain higher than dirty_background_ratio (which is 
currently 10), dirty_background_bytes is 0.


>
>> I don't see the default value for udev_log from the config. 
>> Explicitly set to debug now, but still not seeing anything logged to 
>> syslog. Running with udevd --debug, which logs to a ramdisk on /run.  
>> Hopefully (if/when this happens again) that may shed some light.  
>> There is 256GB of RAM available, so as long as the log doesn't grow 
>> too quickly should be fine.
>
> A lot of RAM may possibly create a huge amount of dirty pages...


May I safely interpret this as "lower the dirty_ratio even further"?

Given a value of 10 and 20 I'm assuming that pdflush will start flushing 
out in the background when >~26GB of in-memory data is dirty, or if the 
data has been dirty for more than 5 seconds (dirty_writeback_centisecs = 
500).

Don't mind lowering the dirty_background ratio as low as 1 even? But 
won't the primary dirty_ratio start blocking processes from writing if 
 >40% of the caches/buffers are considered dirty?

Kind regards,
Jaco

Re: lvm2 deadlock

[Roger Heflin]

On Tue, Jun 4, 2024 at 4:06 AM Jaco Kroon <jaco@uls.co.za> wrote:
>
> Hi,
>
> Please refer below.
>
> >>
> >> This could potentially be due to extremely heavy disk IO, or LVM
> >> itself freezing IO.
> >
> > well reducing the percentage of '/proc/sys/vm/dirty_ration' may
> > possibly help
> > when your disk system is too slow and you create a very lengthy 'sync'
> > io queues...
>
>
> crowsnest [09:52:21] /proc/sys/vm # cat dirty_ratio
> 20
>
> Happy to lower that even more if it would help.
>
> Internet (Redhat) states:
>
> Starts active writeback of dirty data at this percentage of total memory
> for the generator of dirty data, via pdflush. The default value is |40|.
>
> I'm assuming the default is 20 though, not 40, since I can't find that
> I've reconfigured this value.
>
> Should probably remain higher than dirty_background_ratio (which is
> currently 10), dirty_background_bytes is 0.
>
>
> >
> >> I don't see the default value for udev_log from the config.
> >> Explicitly set to debug now, but still not seeing anything logged to
> >> syslog. Running with udevd --debug, which logs to a ramdisk on /run.
> >> Hopefully (if/when this happens again) that may shed some light.
> >> There is 256GB of RAM available, so as long as the log doesn't grow
> >> too quickly should be fine.
> >
> > A lot of RAM may possibly create a huge amount of dirty pages...
>
>
> May I safely interpret this as "lower the dirty_ratio even further"?
>
> Given a value of 10 and 20 I'm assuming that pdflush will start flushing
> out in the background when >~26GB of in-memory data is dirty, or if the
> data has been dirty for more than 5 seconds (dirty_writeback_centisecs =
> 500).
>
> Don't mind lowering the dirty_background ratio as low as 1 even? But
> won't the primary dirty_ratio start blocking processes from writing if
>  >40% of the caches/buffers are considered dirty?
>
> Kind regards,
> Jaco
>
>

Use the *_bytes values.  If they are non-zero then they are used and
that allows setting even below 1% (quite large on anything with a lot
of ram).

I have been using this for quite a while:
vm.dirty_background_bytes = 3000000
vm.dirty_bytes = 5000000

ie 5M and 3M such that I should never have a huge amount of writes outstanding.

And you can go lower.

Re: lvm2 deadlock

[Jaco Kroon]

Hi,

On 2024/06/04 12:48, Roger Heflin wrote:

> Use the *_bytes values.  If they are non-zero then they are used and
> that allows setting even below 1% (quite large on anything with a lot
> of ram).
>
> I have been using this for quite a while:
> vm.dirty_background_bytes = 3000000
> vm.dirty_bytes = 5000000


crowsnest [13:32:48] ~ # sysctl vm.dirty_background_bytes=3000000
vm.dirty_background_bytes = 3000000
crowsnest [13:32:59] ~ # sysctl vm.dirty_bytes=500000000
vm.dirty_bytes = 500000000

And persisted via /etc/sysctl.conf

Thank you.  Must be noted this host doesn't do much else other than disk 
IO, so I'm hoping the 500MB value will be OK, this is just so IO won't 
block CPU heavy-at-the-time tasks.

The purpose of 256GB RAM was so that we could have ~250GB worth of disk 
cache (obviously we don't want all of that to be dirty, OS and "used" 
used to be below 4GB, now generally around 8-12GB, currently it's in 
"quiet" time, so a bit lower, just busy running some background 
compression).  As per iostat:

avg-cpu:  %user   %nice %system %iowait %steal   %idle
            7.73   18.43   18.96   37.86    0.00   17.01

Device             tps    MB_read/s    MB_wrtn/s    MB_dscd/s MB_read    
MB_wrtn    MB_dscd
md2             392.13        10.00         5.11         0.00 4244888    
2167644          0
md3            2270.12        43.88        56.82         0.00 18626309   
24120982          0
md4            1406.06        30.47        16.83         0.00 
12934654    7143330          0

That's total 35805851 MB (34.1B) read and 33431956 MB (31.9TB) written 
in just under 5 days.

What I am noticing immediately is that the "free" value as per "free -m" 
is definitely much higher, which to me is indicative that we're not 
caching as aggressively as can be done.  Will monitor this for the time 
being:

crowsnest [13:50:09] ~ # free -m
                total        used        free      shared buff/cache   
available
Mem:          257661        6911      105313           7 145436      248246
Swap:              0           0           0

The Total DISK WRITE and Current DISK Write values in in iotop seems to 
have a tighter correlation now (no longer seeing constant Total DISK 
WRITE with spikes in current, seems to be more even now).

Kind regards,
Jaco

Re: lvm2 deadlock

[Zdenek Kabelac]

Dne 04. 06. 24 v 13:52 Jaco Kroon napsal(a):
> Hi,
> 
> On 2024/06/04 12:48, Roger Heflin wrote:
> 
>> Use the *_bytes values.  If they are non-zero then they are used and
>> that allows setting even below 1% (quite large on anything with a lot
>> of ram).
>>
>> I have been using this for quite a while:
>> vm.dirty_background_bytes = 3000000
>> vm.dirty_bytes = 5000000
> 
> 
> What I am noticing immediately is that the "free" value as per "free -m" is 
> definitely much higher, which to me is indicative that we're not caching as 
> aggressively as can be done.  Will monitor this for the time being:
> 
> crowsnest [13:50:09] ~ # free -m
>                 total        used        free      shared buff/cache available
> Mem:          257661        6911      105313           7 145436      248246
> Swap:              0           0           0
> 
> The Total DISK WRITE and Current DISK Write values in in iotop seems to have a 
> tighter correlation now (no longer seeing constant Total DISK WRITE with 
> spikes in current, seems to be more even now).

Hi

So now while we are solving various system setting - there are more things to 
think through.

The big 'range' of unwritten data may put them in risk for the 'power' failure.
On the other hand large  'dirty pages'  allows system to 'optimize'  and even 
bypass storing them on disk if they are frequently changed - so in this case 
'lower' dirty ration may cause significant performance impact - so please 
check whats the typical workload and what is result...

It's worth to mention lvm2 support  writecache target to kind of offload dirty 
pages to fast storage...

Last but not least -  disk scheduling policies also do have impact - to i.e. 
ensure better fairness - at the prices of lower throughput...

So now let's get back to lvm2  'possible' deadlock - which I'm still not fully 
certain we deciphered in this thread yet.

So if you happen to 'spot' stuck  commands -  do you notice anything strange 
in systemd journal -  usually when  systemd  decides to kill udevd worker task 
- it's briefly stated in journal - with this check we would kind of know that 
reason of your problems was killed worked that was not able to 'finalize' lvm 
command which is waiting for confirmation from udev (currently without any 
timeout limits).

To unstuck such command  'udevcomplete_all' is a cure - but as said - the 
system is already kind of 'damaged' since udev is failing and has 'invalid' 
information about devices...

So maybe you could check whether your journal around date&time of problem has 
some 'interesting'  'killing action' record ?

Regards

Zdenek

Re: lvm2 deadlock

[Jaco Kroon]

Hi,

On 2024/06/04 18:07, Zdenek Kabelac wrote:
> Dne 04. 06. 24 v 13:52 Jaco Kroon napsal(a):
>> Hi,
>>
>> On 2024/06/04 12:48, Roger Heflin wrote:
>>
>>> Use the *_bytes values.  If they are non-zero then they are used and
>>> that allows setting even below 1% (quite large on anything with a lot
>>> of ram).
>>>
>>> I have been using this for quite a while:
>>> vm.dirty_background_bytes = 3000000
>>> vm.dirty_bytes = 5000000
>>
>>
>> What I am noticing immediately is that the "free" value as per "free 
>> -m" is definitely much higher, which to me is indicative that we're 
>> not caching as aggressively as can be done.  Will monitor this for 
>> the time being:
>>
>> crowsnest [13:50:09] ~ # free -m
>>                 total        used        free      shared buff/cache 
>> available
>> Mem:          257661        6911      105313           7 145436      
>> 248246
>> Swap:              0           0           0
>>
>> The Total DISK WRITE and Current DISK Write values in in iotop seems 
>> to have a tighter correlation now (no longer seeing constant Total 
>> DISK WRITE with spikes in current, seems to be more even now).
The free value how now dropped drastically anyway.  So looks like the 
increase of free was a temporary situation.
>
> Hi
>
> So now while we are solving various system setting - there are more 
> things to think through.
Yea.  Realised we derailed, but given that the theory is that "stuff" is 
blocking the complete (probably due to backlogged IO?), it's not 
completely unrelated is it?
>
> The big 'range' of unwritten data may put them in risk for the 'power' 
> failure.

I'd be more worried about host crash in this case to be honest (dual PSU 
and in several years we've not had a single phase or PDU failure).

> On the other hand large  'dirty pages'  allows system to 'optimize'  
> and even bypass storing them on disk if they are frequently changed - 
> so in this case 'lower' dirty ration may cause significant performance 
> impact - so please check whats the typical workload and what is result...

Based on observations from task timings last night I reckon workloads 
are around 25% faster on average.  Tasks that used to run just shy of 20 
hours (would still have been busy right now) completed last night in 
just under 15 .  This would need to be monitored over time though, as a 
single run is definitely not authoritative.  This was with the _bytes 
settings as suggested by Roger.

For the specific use-case I doubt "frequently changed" applies, and it's 
probably best to get the data persisted as soon as possible, allowing 
for improved "future IO capacity" (hope my wording makes sense).

>
> It's worth to mention lvm2 support  writecache target to kind of 
> offload dirty pages to fast storage...
We normally use raid controller battery backup for this in other 
environments, not relevant in this specific case though, we are using 
dm-cache in other environments mostly for a read-cache (ie, 
write-through strategy) on NVMe though because the raid controller 
whilst buffering writes really sucks at serving reads, which given the 
nature of spinning drives makes perfect sense, and given the amount of 
READ on those two hosts the NVMe setup more than quadrupled throughput 
there.
>
> Last but not least -  disk scheduling policies also do have impact - 
> to i.e. ensure better fairness - at the prices of lower throughput...
We normally use mq-deadline, in this setup I notice this has been 
updated to "none", the plan was to revert, this was done in 
collaboration with a discussion with Bart van Assche.  Happy to revert 
this to be honest. 
https://lore.kernel.org/all/07d8b189-9379-560b-3291-3feb66d98e5c@acm.org/ 
relates.
>
> So now let's get back to lvm2  'possible' deadlock - which I'm still 
> not fully certain we deciphered in this thread yet.
>
> So if you happen to 'spot' stuck  commands -  do you notice anything 
> strange in systemd journal -  usually when  systemd decides to kill 
> udevd worker task - it's briefly stated in journal - with this check 
> we would kind of know that reason of your problems was killed worked 
> that was not able to 'finalize' lvm command which is waiting for 
> confirmation from udev (currently without any timeout limits).

Not using systemd, but udev does come from the systemd package. Nothing 
in the logs at all for udev, as mentioned previously. Don't seem to be 
able to get normal logs working, but I have set up the debuglog now.  
This does log very detailed, except there are no timestamps.  So *if* 
this happens again hopefully we'll be able to look for some working that 
was killed rather than merely exited.  What I can see is that it looks 
like a single forked worker can perform multiple tasks and execute 
multiple other calls, so I believe that the three minute timeout is 
*overall*, not on just a single RUN command, which implies that the 
theory that udevcomplete is never signalled is very much valid.

>
> To unstuck such command  'udevcomplete_all' is a cure - but as said - 
> the system is already kind of 'damaged' since udev is failing and has 
> 'invalid' information about devices...
Agreed.  It gets things going again, which really just allows for a 
cleaner reboot rather than echo b > /proc/sysrq-trigger or remotely 
yanking the power (which is where we normally end up at if we don't 
catch it early enough).
>
> So maybe you could check whether your journal around date&time of 
> problem has some 'interesting'  'killing action' record ?

If we can get normal udev logging working correctly that would be great, 
but this is not your responsibility, so let me figure out how I can get 
udevd to log tot syslog (if that is even possible given the way things 
seems to be moving with systemd).

Kind regards,
Jaco

Re: lvm2 deadlock

[Zdenek Kabelac]

Dne 05. 06. 24 v 10:59 Jaco Kroon napsal(a):
> Hi,
> 
> On 2024/06/04 18:07, Zdenek Kabelac wrote:
>> Dne 04. 06. 24 v 13:52 Jaco Kroon napsal(a):
>> Last but not least -  disk scheduling policies also do have impact - to i.e. 
>> ensure better fairness - at the prices of lower throughput...
> We normally use mq-deadline, in this setup I notice this has been updated to 
> "none", the plan was to revert, this was done in collaboration with a 
> discussion with Bart van Assche.  Happy to revert this to be honest. 
> https://lore.kernel.org/all/07d8b189-9379-560b-3291-3feb66d98e5c@acm.org/ 
> relates.

Hi

So I guess we can tell the store like this -

When you've created your 'snapshot' of a thin-volume - this enforces full 
flush (& fsfreeze) of a thin volume - so any dirty pages need to written in 
thin pool before snapshot could be taken (and thin pool should not run out of 
space) - this CAN potentially hold your system running for a long time 
(depending on performance of your storage) and may cause various lock-ups 
states of your system if you are using this 'snapshoted' volume for anything 
else - as the volume is suspended - so it blocks further operations on this 
device  - eventually causing full system circular deadlock  (catch 22) - this 
is hard to analyze without whole picture of the system.

We may eventually think whether we can somehow minimize the amount of holding
vglock and suspending with flush & fsfreeze -  but it's about some future 
possible enhancement and flush disk upfront to minimize dirty size.

For now reducing dirty page queue to minize the blocking time associated with 
snapshoting is a right choice  (although 500M is probably unnecessarily low...)


Regards

Zdenek

Re: lvm2 deadlock

[Zdenek Kabelac]

Dne 07. 06. 24 v 0:14 Zdenek Kabelac napsal(a):
> Dne 05. 06. 24 v 10:59 Jaco Kroon napsal(a):
>> Hi,
>>
>> On 2024/06/04 18:07, Zdenek Kabelac wrote:
>>> Dne 04. 06. 24 v 13:52 Jaco Kroon napsal(a):
>>> Last but not least -  disk scheduling policies also do have impact - to 
>>> i.e. ensure better fairness - at the prices of lower throughput...
>> We normally use mq-deadline, in this setup I notice this has been updated to 
>> "none", the plan was to revert, this was done in collaboration with a 
>> discussion with Bart van Assche.  Happy to revert this to be honest. 
>> https://lore.kernel.org/all/07d8b189-9379-560b-3291-3feb66d98e5c@acm.org/ 
>> relates.
> 
> Hi
> 
> So I guess we can tell the store like this -
> 
> When you've created your 'snapshot' of a thin-volume - this enforces full 
> flush (& fsfreeze) of a thin volume - so any dirty pages need to written in 
> thin pool before snapshot could be taken (and thin pool should not run out of 
> space) - this CAN potentially hold your system running for a long time 
> (depending on performance of your storage) and may cause various lock-ups 
> states of your system if you are using this 'snapshoted' volume for anything 
> else - as the volume is suspended - so it blocks further operations on this 
> device  - eventually causing full system circular deadlock  (catch 22) - this 
> is hard to analyze without whole picture of the system.
> 
> We may eventually think whether we can somehow minimize the amount of holding
> vglock and suspending with flush & fsfreeze -  but it's about some future 
> possible enhancement and flush disk upfront to minimize dirty size.

I've forget to mention that a 'simplest' way is just to run  'sync' before 
running 'lvcreate -s...' command...

Regards

Zdenek

Re: lvm2 deadlock

[Jaco Kroon]

Hi,

On 2024/06/07 00:17, Zdenek Kabelac wrote:
> Dne 07. 06. 24 v 0:14 Zdenek Kabelac napsal(a):
>> Dne 05. 06. 24 v 10:59 Jaco Kroon napsal(a):
>>> Hi,
>>>
>>> On 2024/06/04 18:07, Zdenek Kabelac wrote:
>>>> Dne 04. 06. 24 v 13:52 Jaco Kroon napsal(a):
>>>> Last but not least -  disk scheduling policies also do have impact 
>>>> - to i.e. ensure better fairness - at the prices of lower 
>>>> throughput...
>>> We normally use mq-deadline, in this setup I notice this has been 
>>> updated to "none", the plan was to revert, this was done in 
>>> collaboration with a discussion with Bart van Assche. Happy to 
>>> revert this to be honest. 
>>> https://lore.kernel.org/all/07d8b189-9379-560b-3291-3feb66d98e5c@acm.org/ 
>>> relates.
>>
>> Hi
>>
>> So I guess we can tell the store like this -
>>
>> When you've created your 'snapshot' of a thin-volume - this enforces 
>> full flush (& fsfreeze) of a thin volume - so any dirty pages need to 
>> written in thin pool before snapshot could be taken (and thin pool 
>> should not run out of space) - this CAN potentially hold your system 
>> running for a long time (depending on performance of your storage) 
>> and may cause various lock-ups states of your system if you are using 
>> this 'snapshoted' volume for anything else - as the volume is 
>> suspended - so it blocks further operations on this device  - 
>> eventually causing full system circular deadlock  (catch 22) - this 
>> is hard to analyze without whole picture of the system.
>>
>> We may eventually think whether we can somehow minimize the amount of 
>> holding
>> vglock and suspending with flush & fsfreeze -  but it's about some 
>> future possible enhancement and flush disk upfront to minimize dirty 
>> size.
>
> I've forget to mention that a 'simplest' way is just to run 'sync' 
> before running 'lvcreate -s...' command...

Thanks.  I think all in all everything mentioned here makes a lot of 
sense, and (in my opinion at least) explains the symptoms we've been seeing.

Overall the system does "feel" more responsive with the lower dirty 
buffers, and most likely it helps with data persistence (as has been 
mentioned) in case of system crashes and/or loss of power.

The tasks during peak usage also does seem to run faster on average, I 
suspect this is because of the use-case for this host:

1.  Data is seldomly overwritten (this was touched on).  Pretty much 
everything is WORM-type access (Write-Once, Read-Many).
2.  Caches are mostly needed to avoid read-bandwidth from consuming 
capacity for writing.
3.  It's thus beneficial to get writes out of the way as soon as 
possible, rather than at a later stage having to block getting many 
writes done for a flush() or sync() or lvcreate (snapshot).

Is 500MB needlessly low?  Probably.  But given the above I think this is 
acceptable.  Rather keep the disk writing *now* in order to free up 
*future* capacity.

I'm guessing your "simple way" is workable for the generic case as well, 
towards that end, is a relatively simple change to the lvm2 tools not 
perhaps to add an syncfs() call to lvcreate *just prior* to freezing?  
The hard part is probably to figure out if the LV is mounted somewhere, 
and if it is, to open() that path in order to have a file-descriptor to 
pass to syncfs()?  Obviously if the LV isn't mounted none of this is a 
concern and we can just proceed.

What would be more interesting is if cluster-lvm is in play and the 
origin LV is active/open on an alternative node?  But that's well beyond 
the scope of our requirements (for now).

Kind regards,
Jaco

Re: lvm2 deadlock

[Zdenek Kabelac]

Dne 07. 06. 24 v 11:03 Jaco Kroon napsal(a):
> Hi,
> 
> On 2024/06/07 00:17, Zdenek Kabelac wrote:
>> Dne 07. 06. 24 v 0:14 Zdenek Kabelac napsal(a):
>>> Dne 05. 06. 24 v 10:59 Jaco Kroon napsal(a):
>>>> Hi,
>>>
>> 
> I'm guessing your "simple way" is workable for the generic case as well, 
> towards that end, is a relatively simple change to the lvm2 tools not perhaps 
> to add an syncfs() call to lvcreate *just prior* to freezing? The hard part is 
> probably to figure out if the LV is mounted somewhere, and if it is, to open() 
> that path in order to have a file-descriptor to pass to syncfs()?  Obviously 
> if the LV isn't mounted none of this is a concern and we can just proceed.
>


Hi

There is no simple answer here -

a) 'sync' flushes all io for all disk in the system - user can play with tools 
like hdparm -F /dev/xxxx  - so still everything in range of 'admin's hand'...

b) it's about the definition of the 'snapshot' moment - do you want to take 
snapshot as of 'now'  or after possibly X minutes where everything has been 
flushed and meanwhile new data flown-in ??

c) lvm2 needs some 'multi LV' atomic snapshot support...

d) with thin-pool and out-of-space potential it gets more tricky....


> What would be more interesting is if cluster-lvm is in play and the origin LV 
> is active/open on an alternative node?  But that's well beyond the scope of 
> our requirements (for now).

Clearly in the cluster case user can use multi-node active LV only in the case 
there is something that is able to 'manage' this storage - i.g. gfs2.   Surely 
use of ext4/xfs this way is out of question...

Regards

Zdenek

Re: lvm2 deadlock

[Jaco Kroon]

Hi,

On 2024/06/07 11:26, Zdenek Kabelac wrote:
> Dne 07. 06. 24 v 11:03 Jaco Kroon napsal(a):
>> Hi,
>>
>> On 2024/06/07 00:17, Zdenek Kabelac wrote:
>>> Dne 07. 06. 24 v 0:14 Zdenek Kabelac napsal(a):
>>>> Dne 05. 06. 24 v 10:59 Jaco Kroon napsal(a):
>>>>> Hi,
>>>>
>>>
>> I'm guessing your "simple way" is workable for the generic case as 
>> well, towards that end, is a relatively simple change to the lvm2 
>> tools not perhaps to add an syncfs() call to lvcreate *just prior* to 
>> freezing? The hard part is probably to figure out if the LV is 
>> mounted somewhere, and if it is, to open() that path in order to have 
>> a file-descriptor to pass to syncfs()? Obviously if the LV isn't 
>> mounted none of this is a concern and we can just proceed.
>>
>
>
> Hi
>
> There is no simple answer here -
>
> a) 'sync' flushes all io for all disk in the system - user can play 
> with tools like hdparm -F /dev/xxxx  - so still everything in range of 
> 'admin's hand'...
Fair.  Or sync -f /path/to/mountpoint.
>
> b) it's about the definition of the 'snapshot' moment - do you want to 
> take snapshot as of 'now'  or after possibly X minutes where 
> everything has been flushed and meanwhile new data flown-in ??
Oh yea, that's very valid, so instead of just lvcreate the sysadmin 
should sync -f /path/to/mountpoint *before* issuing lvcreate in the case 
where "possibly X minutes from now" is acceptable.  Guessing this can be 
a --pre-sync argument for lvcreate but obviously the sysadmin is 
perfectly capable (if he's aware of this caveat) just run sync -f 
/path/to/mountpoint just before lvcreate.
>
> c) lvm2 needs some 'multi LV' atomic snapshot support...
>
> d) with thin-pool and out-of-space potential it gets more tricky....
>
>
>> What would be more interesting is if cluster-lvm is in play and the 
>> origin LV is active/open on an alternative node?  But that's well 
>> beyond the scope of our requirements (for now).
>
> Clearly in the cluster case user can use multi-node active LV only in 
> the case there is something that is able to 'manage' this storage - 
> i.g. gfs2.   Surely use of ext4/xfs this way is out of question...

Was referring to the case where an LV is only active on *one* node at a 
time, but it's on shared physical storage.  Not even sure if a thin pool 
can be active on more than one node at a time in such a case.  This is 
research I've not yet done.  We tried gfs2 a few years back and the 
sheer number of unresolvable failure scenarios at the time just had us 
switch to glusterfs instead.

I think this can be considered closed now.

Thanks again for all the help and insight, I thoroughly enjoyed the 
discussion too, it was most insightful and I learned a lot from it.

Kind regards,
Jaco

Unsubscribe

[box, listen]

Unsubscribe
-- 

unsubscribe

[Reiner / Tania Hagn]

unsubscribe

Re: unsubscribe

[Dan Carpenter]

On Tue, May 21, 2024 at 07:04:28PM +0200, Reiner / Tania Hagn wrote:
> unsubscribe
> 

Send an email to linux-hams+unsubscribe@vger.kernel.org to unsubscribe.

regards,
dan carpenter

unsubscribe

[Satay Epic]

Unsubscribe

[SP2L Tom]

Unsubscribe

Re: Unsubscribe

[Dan Carpenter]

On Thu, May 09, 2024 at 12:10:01PM +0200, SP2L Tom wrote:
> Unsubscribe
> 

You need to send an email to "linux-hams+unsubscribe@vger.kernel.org" to
unsubscribe.

regards,
dan carpenter

unsubscribe

[Igor Andreev]

unsubscribe

[limin yin]

unsubscribe

[Hank Barta]

unsubscribe

unsubscribe

[Emmanuel ALLAUD]

unsubscribe

[Yao Yongxian]

unsubscribe

[XEN][PATCH v6 00/19] dynamic node programming using overlay dtbo

[Vikram Garhwal]

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

[XEN][PATCH v6 08/19] xen/device-tree: Add device_tree_find_node_by_path() to find nodes in device tree

[Vikram Garhwal]

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

RE: [XEN][PATCH v6 08/19] xen/device-tree: Add device_tree_find_node_by_path() to find nodes in device tree

[Henry Wang]

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

unsubscribe

[Terry Yang]

[-- 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 --]

Unsubscribe

[Aviral Gupta]

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

unsubscribe

[Benjamin Demartin]

[-- 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 --]

Re: unsubscribe

[Thomas Monjalon]

13/10/2022 12:14, Benjamin Demartin:
> Hello I would like to unsubscribe but I don’t know how

This is the link to do it yourself:
	https://mails.dpdk.org/listinfo/dev

I've unsubscribed you from dev list.

unsubscribe

[Alvin Šipraga]

Re: unsubscribe

[Alvin Šipraga]

Woops, sorry about that.

For people clueless like me, the actual unsubscribe address is:

iwd+unsubscribe@lists.linux.dev

Now that the list has moved, it's possible to read via lore/lei,
which is great. Thanks!

unsubscribe

[Jacky Wang (王亮)-浪潮数据]

[-- Attachment #1: Type: text/plain, Size: 19 bytes --]

unsubscribe nvdimm

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3627 bytes --]

unsubscribe

[Shoaib Rao]

unsubscribe

Re: unsubscribe

[Shoaib Rao]

On 9/30/21 2:48 PM, Shoaib Rao wrote:
> unsubscribe
>
>

unsubscribe

[Shawn Landden]

-- 
Shawn Landden

unsubscribe

[Shawn Landden]

-- 
Shawn Landden

unsubscribe

[Thompson, Kent]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: Type: text/html, Size: 1447 bytes --]

Re: unsubscribe

[Philip Oakley]

On 10/07/2020 18:52, Enji Cooper wrote:
> unsubscribe
Enji,
you need to send the message to the 'majordomo', and say which list
(i.e. 'git')  see the 'unsubscribe' link at
http://vger.kernel.org/vger-lists.html#git

Philip

Unsubscribe

[ID - David Torres]

[-- 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 --]

Re: overlayfs vs. fscrypt

[Miklos Szeredi]

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

[PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required

[Richard Weinberger]

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

Re: [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required

[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.

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

Re: [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required

[Richard Weinberger]

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

Re: [PATCH 4/4] ubifs: Implement new mount option, fscrypt_key_required

[Theodore Ts'o]

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

Unsubscribe

[Shane Volpe]

[-- Attachment #1: Type: text/plain, Size: 12 bytes --]

Unsubscribe

[-- Attachment #2: Type: text/html, Size: 58 bytes --]

unsubscribe

[Punky]

-- 
-- 

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)

unsubscribe

[Punky]

-- 
-- 

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)

Unsubscribe

[Eric Brown]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Type: text/html, Size: 23 bytes --]

unsubscribe

[조동석]

An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180128/2b24fa0e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 13402 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180128/2b24fa0e/attachment.gif>

unsubscribe

[Gary Thomas]

Sadly, after >20 years

unsubscribe

[Brad Litterell]

[-- Attachment #1: Type: text/plain, Size: 13 bytes --]

unsubscribe

[-- Attachment #2: Type: text/html, Size: 2509 bytes --]

unsubscribe

[조동석]

An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161205/bb7ead76/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 13402 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161205/bb7ead76/attachment-0001.gif 

unsubscribe

[cybin]

unsubscribe

unsubscribe

[고영준]

unsubscribe
 
?????ohojang?? ???
????? ??????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161005/31223606/attachment.html 

unsubscribe

[kuangjiou]

[-- Attachment #1: Type: text/plain, Size: 13 bytes --]

unsubscribe

[-- Attachment #2: Type: text/html, Size: 1920 bytes --]

unsubscribe

[cybin]

Re: unsubscribe

[ye tao]

unsubscribe kvm

On Sat, Mar 21, 2015 at 6:36 PM, ye tao <yetao0715@gmail.com> wrote:
> unsubscribe kvm

unsubscribe

[Deepak Pandian]

unsubscribe

[animan9]

unsubscribe






Sent from Windows Mail

unsubscribe

[Pow, Christopher (SWCOE)]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: Type: text/html, Size: 1618 bytes --]

Re: unsubscribe

[Denys Dmytriyenko]

On Fri, Nov 22, 2013 at 07:35:47PM +0000, Pow, Christopher (SWCOE) wrote:

Sorry to see you go. To unsubscribe from the list, please use:
https://lists.yoctoproject.org/listinfo/meta-ti

-- 
Denys

unsubscribe

[Daniel Kranich]

unsubscribe

[GMAIL]

unsubscribe

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130915/385e6398/attachment.html 

unsubscribe

[GMAIL]

unsubscribe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130911/dc13c3c6/attachment.html 

Mysterious memory corruption bug

[Bean]

[-- 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;

Re: Mysterious memory corruption bug

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- 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 --]

Re: Mysterious memory corruption bug

[Bean]

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

Re: Mysterious memory corruption bug

[Bean]

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

Re: Mysterious memory corruption bug

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- 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 --]

Re: Mysterious memory corruption bug

[Bean]

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

Re: Mysterious memory corruption bug

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- 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 --]

Re: Mysterious memory corruption bug

[Bean]

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

Re: Mysterious memory corruption bug

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- 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 --]

Re: Mysterious memory corruption bug

[Bean]

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

unsubscribe

[Daniel Senderowicz]

[-- 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 --]

Re: unsubscribe

[Gregg Levine]

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."

unsubscribe

[Tietz Fabian (AA-DG/PAS-ESD2)]

unsubscribe

Unsubscribe

[Tomasz Fujak]

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>

unsubscribe

[marduk]

unsubscribe kernelnewbies

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110106/4fcfedd9/attachment.html 

unsubscribe

[Roberto Mantovani]

unsubscribe

[Roberto Mantovani]

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

unsubscribe

[aiolos.cis90]

unsubscribe 

unsubscribe

[Frederic LEGER]

unsubscribe
 

unsubscribe

[Gao Ya'nan]

unsubscribe

unsubscribe

[Thomas Rinder]

unsubscribe 

unsubscribe

[Bietry, Ray]

[-- Attachment #1: Type: text/plain, Size: 5 bytes --]

 


[-- Attachment #2: Type: text/html, Size: 1096 bytes --]

unsubscribe

[ravi.rao]

[-- 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 --]

unsubscribe

[Usha Rani Konudula]

[-- Attachment #1: Type: text/plain, Size: 5 bytes --]

 


[-- Attachment #2: Type: text/html, Size: 3952 bytes --]

Unsubscribe

[shreeram]

-- 

-_-
 .

Regards,
R.S.Shree Ram
GDA Technologies Ltd.

unsubscribe

[Kunkel, Ulrich]

[-- 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 --]

unsubscribe

[zhou.yutao]

[-- 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 --]

Re: unsubscribe

[Geert Uytterhoeven]

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

unsubscribe

[rsterling]

unsubscribe

please

unsubscribe

[sandeep malik]

[-- 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 --]

unsubscribe

[ravi.rao]

[-- 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 --]

RE: unsubscribe

[Rajasekaran Kaliyaperumal, Chennai]

[-- 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 --]

Unsubscribe

[Nadav Sharabi]

[-- 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 --]

Re: Unsubscribe

[Wei Jack]

[-- Attachment #1: Type: text/plain, Size: 53 bytes --]

I wish to unsubscribe from this list.

Best Regards,

[-- Attachment #2: Type: text/html, Size: 67 bytes --]

unsubscribe

[Ignacio Vara]

[-- Attachment #1: Type: text/plain, Size: 13 bytes --]

unsubscribe


[-- Attachment #2: Type: text/html, Size: 1552 bytes --]

unsubscribe

[List]

[-- Attachment #1: Type: text/plain, Size: 15 bytes --]

unsubscribe 

 

[-- Attachment #2: Type: text/html, Size: 1958 bytes --]

unsubscribe

[Yedu Jathavedan]

unsubscribe

unsubscribe

[rsterling]

unsubscribe

---------------------------------------
Rick Sterling
Space Sciences Laboratory
University of California, Berkeley
510.642.6149
rsterling@ssl.berkeley.edu
---------------------------------------

unsubscribe

[Wei Jack]

[-- 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 --]

unsubscribe

[neeraj garg]

[-- Attachment #1: Type: text/plain, Size: 12 bytes --]

unsubscribe

[-- Attachment #2: Type: text/html, Size: 12 bytes --]

mpc5200 ATA DMA

[Peter Czanik]

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

Unsubscribe

[Landau, Bracha]

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

unsubscribe

[santhoshunnikrishnan]

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

RE: unsubscribe

[Rustagi, Vikas]

[-- 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 --]

Re: unsubscribe

[Sungjoo Kim]

[-- 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 --]

unsubscribe

[pravin]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: Type: text/html, Size: 113 bytes --]

unsubscribe

[hb fei]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Type: text/html, Size: 5 bytes --]

unsubscribe

[Tao Xue]

Please unsubscribe me,

thanks

unsubscribe

[AKS]

[-- Attachment #1: Type: text/plain, Size: 31 bytes --]

Please unsubscribe me, thanks!

[-- Attachment #2: Type: text/html, Size: 66 bytes --]

unsubscribe

[zhou.yutao]

[-- 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 --]

RE: unsubscribe

[Decherf, Patrick]

[-- 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 --]

RE: unsubscribe

[Liu Dave]

They seem like worm virus. or
The linuxppc-dev really doesn't have love?

Unsubscribe

[JeongIn Choi]

[-- Attachment #1: Type: text/html, Size: 2493 bytes --]

Re: unsubscribe

[Ian Juang]

Please unsubscribe me from this list.


>
> -------- Original Message --------
> Subject: unsubscribe
> From: Leonid <Leonid@a-k-a.net>
> To: Linuxppc-dev@ozlabs.org
> Date: 2009年1月6日 上午 02:03:55
>
>
>
> Please unsubscribe me from this list.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>   

unsubscribe

[Iain Shewring]

unsubscribe

[Jim Rose]

[-- Attachment #1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #2: Type: text/html, Size: 1096 bytes --]

unsubscribe

[Nate Jozwiak]

[-- Attachment #1: Type: text/plain, Size: 19 bytes --]

unsubscribe

 

 


[-- Attachment #2: Type: text/html, Size: 1481 bytes --]

Re: unsubscribe

[vikas.soni]

unsubscibe me ......

thanks

> unsubscribe
>
>
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: unsubscribe

[Paul Eaton]

Unsubscribe me please

-----Original Message-----
From: linuxppc-dev-bounces+pauleaton=earthlink.net@ozlabs.org
[mailto:linuxppc-dev-bounces+pauleaton=earthlink.net@ozlabs.org] On Behalf
Of vikas.soni@gdatech.co.in
Sent: Tuesday, January 06, 2009 12:04 AM
To: Nate Jozwiak
Cc: linuxppc-dev@ozlabs.org
Subject: Re: unsubscribe

unsubscibe me ......

thanks

> unsubscribe
>
>
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

unsubscribe

[Leonid]

Please unsubscribe me from this list.

unsubscribe

[Nitesh Guinde]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Type: text/html, Size: 5 bytes --]

unsubscribe

[P Jagadeesh Maiya]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: Type: text/html, Size: 289 bytes --]

UNSUBSCRIBE

[Arun Kumar]

[-- 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 --]

Unsubscribe

[Narendra KA]

[-- 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 --]

Re: Unsubscribe

[Steve Iribarne (GMail)]

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

Re: Unsubscribe

[Tore Martin Hagen]

[-- 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 --]

Re: Unsubscribe

[Stephen Rothwell]

[-- 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 --]

Unsubscribe

[Frank Lautenbach]

Hi,

can you please unsubscribe me from this mailing list?

Thanks!


Greetings,

Frank

Re: Unsubscribe

[Leon Woestenberg]

Hello Frank,

On Sun, Jan 4, 2009 at 1:22 PM, Frank Lautenbach
<frank.lautenbach@gmx.de> wrote:
> can you please unsubscribe me from this mailing list?
> Frank

Every email from the list comes with this footer:

> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
Visit that URL and use the unsubscribe feature.

Regards,
-- 
Leon

unsubscribe

[Ed Henderson]

[-- Attachment #1: Type: text/plain, Size: 3 bytes --]

 


[-- Attachment #2: Type: text/html, Size: 1619 bytes --]

unsubscribe

[Alexander Baldeck]

unsubscribe

[mike]

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

Re: Is get_property() correct?

[Michael Ellerman]

[-- 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 --]

unsubscribe

[Usha Rani Konudula]

unsubscribe

unsubscribe

[Usha Rani Konudula]

unsubscribe

unsubscribe

[umesh k]

[-- 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 --]

unsubscribe

[rohitash panda]

[-- 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 --]

unsubscribe

[shrisha.prasad]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: Type: text/html, Size: 0 bytes --]

unsubscribe

[Moloko Vellocet]

[-- Attachment #1: Type: text/plain, Size: 13 bytes --]

unsubscribe

[-- Attachment #2: Type: text/html, Size: 13 bytes --]

unsubscribe

[Geert Janssens]

Re: UNSUBSCRIBE

[George Socker]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

On Wednesday, January 05 2005 04:31 pm, a Nimesh Chanchani wrote:

>
> Send Alsa-devel mailing list submissions to
>  alsa-devel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>  https://lists.sourceforge.net/lists/listinfo/alsa-devel
> or, via email, send a message with subject or body 'help' to
>  alsa-devel-request@lists.sourceforge.net
 ^^^^^^^^^^^^^^^^^
Please read this. You are sending the unsubscribe request to the wrong 
address.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: unsubscribe

[Jacob]

Been trying for months to get off the list.  Let me know if you find out
how

On Mon, 2004-11-01 at 20:37 +0100, Jaap van Geffen wrote:
> lp m
-- 
Jacob <zero@purdue.edu>



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: unsubscribe

[Lee Revell]

On Mon, 2004-11-01 at 18:04 -0500, Jacob wrote:
> Been trying for months to get off the list.  Let me know if you find out
> how
> 
> On Mon, 2004-11-01 at 20:37 +0100, Jaap van Geffen wrote:
> > lp m

Did you try the URL that is at the bottom of every list message?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

unsubscribe

[Fabio Sirna]

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

Encryption

[Pierre Abbat]

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.

Re: Snapshots a la NetApp?

[Heinz-Josef Claes]

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

Re: Snapshots a la NetApp?

[Hans Reiser]

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

Re: unsubscribe

[Voicu Liviu]

unsubscribe

unsubscribe

[farnis=VGgt2q2+T+FeoWH0uzbU5w@public.gmane.org]

--
Fabio

Unable to recover from CRC failiure

[Joakim Tjernlund]

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
 

unsubscribe

[Roy Sherrill]

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

unsubscribe

[Kasslatter Fritz]

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

unsubscribe

[Torbjorn Gannholm]

unsubscribe

[Deni Connor]

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

unsubscribe

[Carbon Monoxide]

unsubscribe

Re: unsubscribe

[Koundinya.K]

please refer to the list policy to unsubscribe. You are not doing it right 
by sending a mail to this id...Doing so is considered bad.

You can use

linux-request@relay.engr.sgi.com
Majordomo@relay.engr.sgi.com

Koundinya