asdf

asdf

[Jonathan]

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

asdf

asdf

[임준수(Junesoo Im) 수석 두산로보틱스]

hello. I am a Linux Application Developer.


Application uses Xenomai 3.1x.
The machine environment is 64bit and kernel 5.4.255.

Repeat machine reboot at 55 second intervals.
Most of the time it works fine, but sometimes the system freezes.
The mouse doesn't move and the keyboard doesn't work.
The screen also freezes.
There are no special messages in the kernel log.
The same goes for syslog.



So I'm running some tests.
If you test without running the application, there is no problem with the system.
Problems occur when the application runs.
However, I don't see any special messages in the application log.


I haven't found the cause of Freezing yet.
I am currently viewing the “https://v3.xenomai.org/troubleshooting/” site.
I would like to test some of the things mentioned on this site.
If possible, I would like you to look at this site together.


This site is talking about Kernel configuration that needs to be removed.
"CONFIG_KGDB"
This option is currently enabled, so I removed it and tested it.
But Freezing occurred.
A problem has occurred, but should this option be removed?


This site talks about "Freeze or machine lockup".
1. “Stack space overflow issue now biting sim real-time kernel thread?”
2. “Spurious delay/timeout values computed by the application (specifically: too short)”
3. “A case of freeze is a system call called in a loop which fails without its return value being properly checked.”


There are three explanations: I have a question about the first one.
How many threads can the xenomai program create?
What is the maximum stack size per thread in the xenomai program?
Our program has at least 22 xenomai threads.
The stack size is different for each thread. It may have a maximum of 8 MB and a minimum of 2 MB.



The question is complicated and long, but I desperately need help.
Please, reply.
Thank you.

asdf

[Christian Brauner]

Hey Konstantin,

Can't be said enough: thanks for b4!

I have two inquiries about b4 send:

(1) Currently the message id that is generated for each patch sent by b4
    has the format:

    [date] - [branch name] - [version] - [patch number] - [random] @ kernel.org

    where [date] is fixed and is taken from the change-id of the series
    as you mentioned in a fediverse thread.

    It would be nice if we could - potentially opt-in via a config opt -
    set [date] to the date when the patch series was sent.

(2) I couldn't find an option to tell b4 send to set In-Reply-To: to one
    or more messages. That comes in handy when e.g., generating a patch
    in reply to syzbot report.

Maybe that's something worth adding.

Thanks!
Christian

Re: asdf

[Konstantin Ryabitsev]

On Fri, Mar 31, 2023 at 12:04:14PM +0200, Christian Brauner wrote:
> Can't be said enough: thanks for b4!

Glad to see so many people start to use it.

> I have two inquiries about b4 send:
> 
> (1) Currently the message id that is generated for each patch sent by b4
>     has the format:
> 
>     [date] - [branch name] - [version] - [patch number] - [random] @ kernel.org
> 
>     where [date] is fixed and is taken from the change-id of the series
>     as you mentioned in a fediverse thread.
> 
>     It would be nice if we could - potentially opt-in via a config opt -
>     set [date] to the date when the patch series was sent.

Sounds reasonable.
bugbot on

> (2) I couldn't find an option to tell b4 send to set In-Reply-To: to one
>     or more messages. That comes in handy when e.g., generating a patch
>     in reply to syzbot report.
> 
> Maybe that's something worth adding.

I worry that this can create really weird thread interactions. E.g. if you
have a bot report and it results in two different series being proposed:

original bot report
 \ 
  -- [PATCH] fixes one issue from the report
  \
 | -- [PATCH v2] fixes one issue from the report
 |
  -- [PATCH] fixes a different issue from the report
  \
   -- [PATCH v2] fixes a different issue from the report

This will confuse absolutely everyone, not just b4. :)
It's best to just use Link:, I think.

-K

Re: asdf

[Kernel.org Bugbot]

Hello:

This conversation is now tracked by Kernel.org Bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=217359

There is no need to do anything else, just keep talking.
-- 
Deet-doot-dot, I am a bot.
Kernel.org Bugzilla (peebz 0.1)

asdf

[Dan Carpenter]

There is a new gcc warning in this function:

drivers/mmc/card/block.c:836:18: warning: ‘arg’ may be used uninitialized in this function [-Wuninitialized]

   810          /* The sanitize operation is supported at v4.5 only */
   811          if (mmc_can_sanitize(card)) {
   812                  err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
   813                                  EXT_CSD_SANITIZE_START, 1, 0);

1) arg is uninitialized here.  mmc_switch() can return -EIO.

   814                  goto out;
   815          }
   816  
   817          from = blk_rq_pos(req);
   818          nr = blk_rq_sectors(req);
   819  
   820          if (mmc_can_trim(card) && !mmc_erase_group_aligned(card, from, nr))
   821                  arg = MMC_SECURE_TRIM1_ARG;
   822          else
   823                  arg = MMC_SECURE_ERASE_ARG;
   824  retry:
   825          if (card->quirks & MMC_QUIRK_INAND_CMD38) {
   826                  err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
   827                                   INAND_CMD38_ARG_EXT_CSD,
   828                                   arg == MMC_SECURE_TRIM1_ARG ?
                                         ^^^

3) uninitialized.

   829                                   INAND_CMD38_ARG_SECTRIM1 :
   830                                   INAND_CMD38_ARG_SECERASE,
   831                                   0);
   832                  if (err)
   833                          goto out;
   834          }
   835          err = mmc_erase(card, from, nr, arg);
   836          if (!err && arg == MMC_SECURE_TRIM1_ARG) {
   837                  if (card->quirks & MMC_QUIRK_INAND_CMD38) {
   838                          err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
   839                                           INAND_CMD38_ARG_EXT_CSD,
   840                                           INAND_CMD38_ARG_SECTRIM2,
   841                                           0);
   842                          if (err)
   843                                  goto out;
   844                  }
   845                  err = mmc_erase(card, from, nr, MMC_SECURE_TRIM2_ARG);
   846          }
   847  out:
   848          if (err == -EIO && !mmc_blk_reset(md, card->host, type))
   849                  goto retry;

2) We could maybe hit the goto retry here if the reset works.

regards,
dan carpenter

Re: asdf

[Kyungmin Park]

Hi

Yes possible scenario, it should be changed like this.

out:
        if (err == -EIO) {
                int ret = !mmc_blk_reset(md, card->host, type);
                if (ret && !mmc_can_sanitize(card))
                        goto retry;
        }

anyway, I will find the more fancy way.

Thank you for pointing out.

BR,
Kyungmin Park

On 12/6/11, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> There is a new gcc warning in this function:
>
> drivers/mmc/card/block.c:836:18: warning: ‘arg’ may be used uninitialized in
> this function [-Wuninitialized]
>
>    810          /* The sanitize operation is supported at v4.5 only */
>    811          if (mmc_can_sanitize(card)) {
>    812                  err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>    813                                  EXT_CSD_SANITIZE_START, 1, 0);
>
> 1) arg is uninitialized here.  mmc_switch() can return -EIO.
>
>    814                  goto out;
>    815          }
>    816
>    817          from = blk_rq_pos(req);
>    818          nr = blk_rq_sectors(req);
>    819
>    820          if (mmc_can_trim(card) && !mmc_erase_group_aligned(card,
> from, nr))
>    821                  arg = MMC_SECURE_TRIM1_ARG;
>    822          else
>    823                  arg = MMC_SECURE_ERASE_ARG;
>    824  retry:
>    825          if (card->quirks & MMC_QUIRK_INAND_CMD38) {
>    826                  err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>    827                                   INAND_CMD38_ARG_EXT_CSD,
>    828                                   arg == MMC_SECURE_TRIM1_ARG ?
>                                          ^^^
>
> 3) uninitialized.
>
>    829                                   INAND_CMD38_ARG_SECTRIM1 :
>    830                                   INAND_CMD38_ARG_SECERASE,
>    831                                   0);
>    832                  if (err)
>    833                          goto out;
>    834          }
>    835          err = mmc_erase(card, from, nr, arg);
>    836          if (!err && arg == MMC_SECURE_TRIM1_ARG) {
>    837                  if (card->quirks & MMC_QUIRK_INAND_CMD38) {
>    838                          err = mmc_switch(card,
> EXT_CSD_CMD_SET_NORMAL,
>    839                                           INAND_CMD38_ARG_EXT_CSD,
>    840                                           INAND_CMD38_ARG_SECTRIM2,
>    841                                           0);
>    842                          if (err)
>    843                                  goto out;
>    844                  }
>    845                  err = mmc_erase(card, from, nr,
> MMC_SECURE_TRIM2_ARG);
>    846          }
>    847  out:
>    848          if (err == -EIO && !mmc_blk_reset(md, card->host, type))
>    849                  goto retry;
>
> 2) We could maybe hit the goto retry here if the reset works.
>
> regards,
> dan carpenter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

asdf

[Alexander Simon]

subscribe linux-wireless

asdf

[Tejun Heo]

Hello,

The current EH speed down code is more of a feature demonstration and
goes through rdiculously many meaningless steps when condition is met.
This patchset tries to put some intelligence into speed down sequence.
The goal is to achieve reasonable number of speed down steps
reasonably spaced from one another and consider NCQ, cable type and
the current protocol when determining speed down steps, while not
bloating the code too much with nitty gritty details.

Roughly, the rules are...

1. If NCQ and protocol/timeout/unknown dev errors occur, turn off NCQ

2. If excessive transfer errors occur, speed down within the current
   transfer mode (UDMA/MWDMA/PIO).  If UDMA, it's first adjusted down
   a step, if error conditions persist, 40c limit is applied.  Speed
   down is done only twice.

3. If PATA && used up all DMA speed down steps && a LOT of
   transmission/unknown errors occur, switch to PIO.  So, we never
   automatically step down to PIO on SATA.  This is intended.  Some
   SATA hdd even seems to have problem with PIO data transfer
   commands.

The last patch makes ahci report HSM violation error on spurious
completion of NCQ commands, thus causing NCQ off after several such
incidents.  These drives should be blacklisted for DMA eventually.

This patchset is against...

  upstream (eb0e63cca36a3389f0ccab4584f6d479b983fad5)
+ [1] pata_platform-fix-devres-conversion
+ [2] libata-convert-to-iomap

Ric, I guess this resolves the to-do item from you which has been
sitting in my mailbox for way too long.  What do you think about the
rules?

Thanks.

--
tejun

[1] http://article.gmane.org/gmane.linux.kernel/488509
[2] hmm.. can't find it any archive.  Might have been ignored due to
    size.  Jeff, did you receive it?

Re: asdf

[Ric Wheeler]

Tejun Heo wrote:
> Hello,
>
> The current EH speed down code is more of a feature demonstration and
> goes through rdiculously many meaningless steps when condition is met.
> This patchset tries to put some intelligence into speed down sequence.
> The goal is to achieve reasonable number of speed down steps
> reasonably spaced from one another and consider NCQ, cable type and
> the current protocol when determining speed down steps, while not
> bloating the code too much with nitty gritty details.
>
> Roughly, the rules are...
>
> 1. If NCQ and protocol/timeout/unknown dev errors occur, turn off NCQ
>
> 2. If excessive transfer errors occur, speed down within the current
>    transfer mode (UDMA/MWDMA/PIO).  If UDMA, it's first adjusted down
>    a step, if error conditions persist, 40c limit is applied.  Speed
>    down is done only twice.
>
> 3. If PATA && used up all DMA speed down steps && a LOT of
>    transmission/unknown errors occur, switch to PIO.  So, we never
>    automatically step down to PIO on SATA.  This is intended.  Some
>    SATA hdd even seems to have problem with PIO data transfer
>    commands.
>
> The last patch makes ahci report HSM violation error on spurious
> completion of NCQ commands, thus causing NCQ off after several such
> incidents.  These drives should be blacklisted for DMA eventually.
>
> This patchset is against...
>
>   upstream (eb0e63cca36a3389f0ccab4584f6d479b983fad5)
> + [1] pata_platform-fix-devres-conversion
> + [2] libata-convert-to-iomap
>
> Ric, I guess this resolves the to-do item from you which has been
> sitting in my mailbox for way too long.  What do you think about the
> rules?
>
> Thanks.
>
>
>   
Thanks, this looks great!

The key here is making sure that we get a really good classification of 
error types and don't go down the step down path when the error does not 
indicate that the drive got the command and just correctly failed it.  
(That behavior, which we hit with one specific issues earlier & you have 
already fixed, reminds me of the American tourist abroad syndrome. If 
someone does not understand what you asked in English, just say it again 
slower and louder until they get it ;-)).

We might still want/need to be able to "lock" specific drives so that 
they do not drop out of DMA mode, not as the default but as a system 
tuning issue. What we see in the set of ATA drives that we have in the 
field  is that dropping out of DMA mode is basically useless (for us at 
least) since it is so slow and we always have other drives to fall back 
on. Clearly not the case for typical end users, but a common case in the 
storage space where we pack as many disk drives into each box as we can.

On that other thread, I mentioned that we need to get some good testing 
done with this kind of thing.  With Mark's error injection fixes (or the 
new ATA spec'ed ability to inject errors that Doug mentioned), along 
with our population of real world flaky drives, I hope to be able to 
beat on this in a realistic way in our labs,

ric

Re: asdf

[Tejun Heo]

Ric Wheeler wrote:
[--snip--]
> We might still want/need to be able to "lock" specific drives so that
> they do not drop out of DMA mode, not as the default but as a system
> tuning issue. What we see in the set of ATA drives that we have in the
> field  is that dropping out of DMA mode is basically useless (for us at
> least) since it is so slow and we always have other drives to fall back
> on. Clearly not the case for typical end users, but a common case in the
> storage space where we pack as many disk drives into each box as we can.

I agree that some tuning knobs can be useful.  SATA drives now never
drops to PIO mode due to errors.  Even PATA drives should be failing
really hard to get degraded into PIO mode.

> On that other thread, I mentioned that we need to get some good testing
> done with this kind of thing.  With Mark's error injection fixes (or the
> new ATA spec'ed ability to inject errors that Doug mentioned), along
> with our population of real world flaky drives, I hope to be able to
> beat on this in a realistic way in our labs,

Yeap, really.  Things are pretty easy to adjust.  With all the posted
patches applied...

* Errors are categorized by ata_eh_categorize_error() considering
whether the failed request was regular IO operation and the err_mask.

* ata_eh_speed_down_verdict() scans error history and determines
verdicts (or'd bitmask of ATA_EH_SPDN_* flags).

* ata_eh_speed_down() tries to apply the verdict.  It always prefers the
least severe verdict and once a verdict is applied all others are
ignored and error history is cleared.

So, the basic tuning point is ata_eh_speed_down_verdict().  It's a very
short and easy-to-tune function which determines for how far back the
error history is scanned and which categories of errors trigger which
verdict.

Experimenting in realistic setup and reporting how the current setting
works and how better can it be adjusted will be a huge help.

Thanks.

-- 
tejun

asdf

[Horms]

I have been looking at unifying the way that panic_on_oops logs
what it is doing between the different architectures that implement it.
The first cab off the rank is the patch below which removes a seemingly
silly difference between the behaviour on 32 and 64 bit powerpc.

I have not been able to test this as I do not have a ppc64 machine
at my disposal. However I did test that it compiles thanks to
the wonders of crosstool.

Signed-Off-By: Horms <horms@verge.net.au>

 arch/powerpc/kernel/traps.c |    2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 52f5659..908231a 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -157,10 +157,8 @@ #endif
 		panic("Fatal exception in interrupt");
 
 	if (panic_on_oops) {
-#ifdef CONFIG_PPC64
 		printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
 		ssleep(5);
-#endif
 		panic("Fatal exception");
 	}
 	do_exit(err);

asdf

[Jonathan]

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

asdf

asdf

[thunder7]

While compiling 2.4.10-ac11 + keyboard fix for my alpha, I noted that
this is still printed very often:

/usr/src/linux-2.4.10ac11/include/linux/interrupt.h:77: warning: `__cpu_raise_softirq' redefined
/usr/src/linux-2.4.10ac11/include/asm/softirq.h:35: warning: this is the location of the previous definition

Good luck,
Jurriaan
-- 
You do understand that in my culture what you have just said would
constitute deliberate and possibly dangerous insult?
	Michelle West - Sea of Sorrows
GNU/Linux 2.4.10-ac10 SMP/ReiserFS 2x1402 bogomips load av: 0.00 0.10 0.07