slow write performance with software RAID on nvme storage

2019-03-29 Thread Rick Warner
choices and tuning but haven't seen any significant improvements. What is the bottleneck here? If it's not known, what should I do to determine it? I've done a variety of other tests with this system and am happy to elaborate further if any other information is needed. Thanks, Rick Warner

Re: [bisected] rcu_sched detected stalls - 4.15 or newer kernel with some Xeon skylake CPUs and extended APIC

2018-05-17 Thread Rick Warner
Success! This resolved the issue.  Thanks Thomas! Rick On 05/17/18 08:36, Thomas Gleixner wrote: > Rick, > > On Wed, 16 May 2018, Rick Warner wrote: > >> I've attached the dmesg output with the kernel parameter and supplied patch. > Thanks for providing the data. I thin

Re: [bisected] rcu_sched detected stalls - 4.15 or newer kernel with some Xeon skylake CPUs and extended APIC

2018-05-17 Thread Rick Warner
Success! This resolved the issue.  Thanks Thomas! Rick On 05/17/18 08:36, Thomas Gleixner wrote: > Rick, > > On Wed, 16 May 2018, Rick Warner wrote: > >> I've attached the dmesg output with the kernel parameter and supplied patch. > Thanks for providing the data. I thin

Re: [bisected] rcu_sched detected stalls - 4.15 or newer kernel with some Xeon skylake CPUs and extended APIC

2018-05-16 Thread Rick Warner
Thanks Thomas! I've attached the dmesg output with the kernel parameter and supplied patch. Here is the excerpt of the ftrace dump: Dumping ftrace buffer: - swapper/-1   0d... 463331us : __x2apic_send_IPI_mask: To: swapper/-1   0d... 46us :

Re: [bisected] rcu_sched detected stalls - 4.15 or newer kernel with some Xeon skylake CPUs and extended APIC

2018-05-16 Thread Rick Warner
Thanks Thomas! I've attached the dmesg output with the kernel parameter and supplied patch. Here is the excerpt of the ftrace dump: Dumping ftrace buffer: - swapper/-1   0d... 463331us : __x2apic_send_IPI_mask: To: swapper/-1   0d... 46us :

[bisected] rcu_sched detected stalls - 4.15 or newer kernel with some Xeon skylake CPUs and extended APIC

2018-05-15 Thread Rick Warner
Hi All, Does anyone have ideas on this?  Is there any other data I can provide to help debug this? Thanks, Rick On 05/01/2018 12:37 PM, Rick Warner wrote: Hi All, I've discovered that some new Supermicro skylake systems will hang/stall while booting the 4.15 kernel when extended APIC

[bisected] rcu_sched detected stalls - 4.15 or newer kernel with some Xeon skylake CPUs and extended APIC

2018-05-15 Thread Rick Warner
Hi All, Does anyone have ideas on this?  Is there any other data I can provide to help debug this? Thanks, Rick On 05/01/2018 12:37 PM, Rick Warner wrote: Hi All, I've discovered that some new Supermicro skylake systems will hang/stall while booting the 4.15 kernel when extended APIC

stall/hang on 4.15 kernel with some Xeon skylake CPUs and extended APIC

2018-05-01 Thread Rick Warner
Hi All, I've discovered that some new Supermicro skylake systems will hang/stall while booting the 4.15 kernel when extended APIC (x2apic) is enabled in the BIOS. The issue happens on specific CPUs only and follows the CPUs. We had (4) quad socket systems with Xeon 6134 CPUs; 2 out of 4 were

stall/hang on 4.15 kernel with some Xeon skylake CPUs and extended APIC

2018-05-01 Thread Rick Warner
Hi All, I've discovered that some new Supermicro skylake systems will hang/stall while booting the 4.15 kernel when extended APIC (x2apic) is enabled in the BIOS. The issue happens on specific CPUs only and follows the CPUs. We had (4) quad socket systems with Xeon 6134 CPUs; 2 out of 4 were

Re: serial port regression caused by "Char: tty_ioctl, use wait_event_interruptible_timeout" patch

2008-02-05 Thread Rick Warner
This modification solved my problem. Will this change go into mainline, or will we need to maintain our own branch of the kernel to keep this working? Thanks, Rick On Tuesday 05 February 2008, Paul Fulghum wrote: > Paul Fulghum wrote: > > Instead of reverting the patch can you try modifying >

serial port regression caused by "Char: tty_ioctl, use wait_event_interruptible_timeout" patch

2008-02-05 Thread Rick Warner
Hello all, My company uses a proprietary hardware monitoring solution that utilizes communication over the serial port. A RS232-RS485 converter is plugged into the serial port of the master of a cluster, and cat5 cables are daisy chained between the cards to handle out of band hardware

serial port regression caused by Char: tty_ioctl, use wait_event_interruptible_timeout patch

2008-02-05 Thread Rick Warner
Hello all, My company uses a proprietary hardware monitoring solution that utilizes communication over the serial port. A RS232-RS485 converter is plugged into the serial port of the master of a cluster, and cat5 cables are daisy chained between the cards to handle out of band hardware

Re: serial port regression caused by Char: tty_ioctl, use wait_event_interruptible_timeout patch

2008-02-05 Thread Rick Warner
This modification solved my problem. Will this change go into mainline, or will we need to maintain our own branch of the kernel to keep this working? Thanks, Rick On Tuesday 05 February 2008, Paul Fulghum wrote: Paul Fulghum wrote: Instead of reverting the patch can you try modifying

Re: latency doubled on tg3 device from 2.6.11 to 2.6.12

2005-09-02 Thread Rick Warner
On Thursday 01 September 2005 05:46 pm, Eric Dumazet wrote: > Rick Warner a écrit : > > Hello, > > We have been testing latency and bandwidth using our proprietary MPI > > link checker tool (http://www.microway.com/mpilinkchecker.html) and have > > found that the l

Re: latency doubled on tg3 device from 2.6.11 to 2.6.12

2005-09-02 Thread Rick Warner
On Thursday 01 September 2005 05:46 pm, Eric Dumazet wrote: Rick Warner a écrit : Hello, We have been testing latency and bandwidth using our proprietary MPI link checker tool (http://www.microway.com/mpilinkchecker.html) and have found that the latency increased from ~25ms to ~45ms

latency doubled on tg3 device from 2.6.11 to 2.6.12

2005-09-01 Thread Rick Warner
Hello, We have been testing latency and bandwidth using our proprietary MPI link checker tool (http://www.microway.com/mpilinkchecker.html) and have found that the latency increased from ~25ms to ~45ms going from 2.6.11 to 2.6.12. 2.6.13 has the same result. We also tried the latest bcm5700

latency doubled on tg3 device from 2.6.11 to 2.6.12

2005-09-01 Thread Rick Warner
Hello, We have been testing latency and bandwidth using our proprietary MPI link checker tool (http://www.microway.com/mpilinkchecker.html) and have found that the latency increased from ~25ms to ~45ms going from 2.6.11 to 2.6.12. 2.6.13 has the same result. We also tried the latest bcm5700