All of lore.kernel.org
 help / color / mirror / Atom feed
* asdf
@ 2007-02-02  7:22 Tejun Heo
  2007-02-02  7:22 ` [PATCH 2/5] libata: improve probe failure handling Tejun Heo
                   ` (6 more replies)
  0 siblings, 7 replies; 24+ messages in thread
From: Tejun Heo @ 2007-02-02  7:22 UTC (permalink / raw)
  To: jeff, alan, ric, edmudama, linux-ide, htejun

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?



^ permalink raw reply	[flat|nested] 24+ messages in thread
* asdf
@ 2024-04-15  0:39 임준수(Junesoo Im) 수석 두산로보틱스
  0 siblings, 0 replies; 24+ messages in thread
From: 임준수(Junesoo Im) 수석 두산로보틱스 @ 2024-04-15  0:39 UTC (permalink / raw)
  To: xenomai@lists.linux.dev
  Cc: 박경훈(Kyunghoon Park) 팀장 두산로보틱스

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.

^ permalink raw reply	[flat|nested] 24+ messages in thread
* asdf
@ 2023-03-31 10:04 Christian Brauner
  2023-04-21 18:52 ` asdf Konstantin Ryabitsev
  2023-04-21 18:58 ` asdf Kernel.org Bugbot
  0 siblings, 2 replies; 24+ messages in thread
From: Christian Brauner @ 2023-03-31 10:04 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: Tools

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

^ permalink raw reply	[flat|nested] 24+ messages in thread
* asdf
@ 2011-12-06  8:08 Dan Carpenter
  2011-12-06  8:48 ` asdf Kyungmin Park
  0 siblings, 1 reply; 24+ messages in thread
From: Dan Carpenter @ 2011-12-06  8:08 UTC (permalink / raw)
  To: Kyungmin Park, Adrian Hunter; +Cc: linux-mmc

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

^ permalink raw reply	[flat|nested] 24+ messages in thread
* asdf
@ 2011-04-28 12:20 Alexander Simon
  0 siblings, 0 replies; 24+ messages in thread
From: Alexander Simon @ 2011-04-28 12:20 UTC (permalink / raw)
  To: linux-wireless

subscribe linux-wireless


^ permalink raw reply	[flat|nested] 24+ messages in thread
* asdf
@ 2006-07-06 10:15 Horms
  0 siblings, 0 replies; 24+ messages in thread
From: Horms @ 2006-07-06 10:15 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Paul Mackerras, Anton Blanchard

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

^ permalink raw reply related	[flat|nested] 24+ messages in thread
* asdf
@ 2004-03-02 21:48 Jonathan
  0 siblings, 0 replies; 24+ messages in thread
From: Jonathan @ 2004-03-02 21:48 UTC (permalink / raw)
  To: linux-kernel

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

asdf

^ permalink raw reply	[flat|nested] 24+ messages in thread
* asdf
@ 2004-03-02 19:15 Jonathan
  0 siblings, 0 replies; 24+ messages in thread
From: Jonathan @ 2004-03-02 19:15 UTC (permalink / raw)
  To: linux-kernel

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

asdf

^ permalink raw reply	[flat|nested] 24+ messages in thread
* asdf
@ 2001-10-11 10:53 thunder7
  0 siblings, 0 replies; 24+ messages in thread
From: thunder7 @ 2001-10-11 10:53 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2024-04-15  0:39 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-02-02  7:22 asdf Tejun Heo
2007-02-02  7:22 ` [PATCH 2/5] libata: improve probe failure handling Tejun Heo
2007-02-02  7:22 ` [PATCH 1/5] libata: improve ata_down_xfermask_limit() Tejun Heo
2007-02-20 15:46   ` Jeff Garzik
2007-02-02  7:22 ` [PATCH 4/5] libata: kill ATA_DNXFER_ANY Tejun Heo
2007-02-02  7:22 ` [PATCH 5/5] ahci: consider SDB FIS containing spurious NCQ completions HSM violation Tejun Heo
2007-02-20 15:46   ` Jeff Garzik
2007-02-21  7:34     ` [PATCH 5/5] ahci: consider SDB FIS containing spurious NCQ completions HSM violation (regenerated) Tejun Heo
2007-02-23 10:37       ` Jeff Garzik
2007-02-02  7:22 ` [PATCH 3/5] libata: put some intelligence into EH speed down sequence Tejun Heo
2007-02-02  7:24 ` Subject is [PATCH,RESEND] libata: put some intelligence into " Tejun Heo
2007-02-02 16:59 ` asdf Ric Wheeler
2007-02-03  4:07   ` asdf Tejun Heo
  -- strict thread matches above, loose matches on Subject: below --
2024-04-15  0:39 asdf 임준수(Junesoo Im) 수석 두산로보틱스
2023-03-31 10:04 asdf Christian Brauner
2023-04-21 18:52 ` asdf Konstantin Ryabitsev
2023-04-21 18:58 ` asdf Kernel.org Bugbot
2011-12-06  8:08 asdf Dan Carpenter
2011-12-06  8:48 ` asdf Kyungmin Park
2011-04-28 12:20 asdf Alexander Simon
2006-07-06 10:15 asdf Horms
2004-03-02 21:48 asdf Jonathan
2004-03-02 19:15 asdf Jonathan
2001-10-11 10:53 asdf thunder7

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.