On Tue, 27 Mar 2007, [EMAIL PROTECTED] wrote:
Here's some more data.
6x ST3400832AS (Seagate 7200.8) 400 GB drives.
3x SiI3232 PCIe SATA controllers
2.2 GHz Athlon 64, 1024k cache (3700+), 2 GB RAM
Linux 2.6.20.4, 64-bit kernel
Tested able to sustain reads at 60 MB/sec/drive simultaneously.
R
On Tue, 27 Mar 2007, [EMAIL PROTECTED] wrote:
From [EMAIL PROTECTED] Tue Mar 27 16:25:58 2007
Date: Tue, 27 Mar 2007 12:25:52 -0400 (EDT)
From: Justin Piszcz <[EMAIL PROTECTED]>
X-X-Sender: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED], lin
On Tue, 27 Mar 2007, [EMAIL PROTECTED] wrote:
I meant you do not allocate the entire disk per raidset, which may alter
performance numbers.
No, that would be silly. It does lower the average performance of the
large RAID-5 area, but I don't know how ext3fs is allocating the blocks
anyway, s
On Thu, 29 Mar 2007, Neil Brown wrote:
On Tuesday March 27, [EMAIL PROTECTED] wrote:
I ran a check on my SW RAID devices this morning. However, when I did so,
I had a few lftp sessions open pulling files. After I executed the check,
the lftp processes entered 'D' state and I could do 'nothi
On Thu, 29 Mar 2007, Henrique de Moraes Holschuh wrote:
On Thu, 29 Mar 2007, Justin Piszcz wrote:
Did you look at "cat /proc/mdstat" ?? What sort of speed was the check
running at?
Around 44MB/s.
I do use the following optimization, perhaps a bad idea if I want other
processe
On Fri, 30 Mar 2007, Neil Brown wrote:
On Thursday March 29, [EMAIL PROTECTED] wrote:
Did you look at "cat /proc/mdstat" ?? What sort of speed was the check
running at?
Around 44MB/s.
I do use the following optimization, perhaps a bad idea if I want other
processes to 'stay alive'?
echo
Adding LKML to cc list.
On Sun, 29 Apr 2007, Justin Piszcz wrote:
From the manpage:
-b Block size options.
This option specifies the fundamental block size of the
filesys-
tem. The valid suboptions are: log=value and size=value;
only
one
On Wed, 2 May 2007, Williams, Dan J wrote:
From: Nick Piggin [mailto:[EMAIL PROTECTED]
I am pleased to release this latest spin of the raid acceleration
patches for merge consideration. This release aims to address all
pending review items including MD bug fixes and async_tx api changes
from
On Wed, 2 May 2007, Williams, Dan J wrote:
From: Justin Piszcz [mailto:[EMAIL PROTECTED]
I have not been following this closely, must you have an
CONFIG_INTEL_IOP_ADMA piece of hardware and/or chipset to use this
feature or can regular desktop users take hold of it as well?
Currently this
On Mon, 19 Mar 2007, Nicolas Boichat wrote:
Rudolf Marek wrote:
Hello all,
I'm CCing all interested parties, if some isn't please tell!
On URL bellow is current version of coretemp driver.
http://ssh.cz/~ruik/patches/
Small glitch in coretemp_init:
printk(KERN_NOTICE DRVNAME ": This
There are various agencies/educational institutions doing testing but was
curious if anyone has 'found' a 10 gigabit card shootout measuring the
performance between 10 gigabit cards on the 2.6 kernel? Most of the
benchmarks are from the vendors themselves Intel/etc-- was wondering if
there wer
Including LKML on this one as it may be a partition size limit? Sdc1 is
not 11TB.
Justin.
On Fri, 28 Sep 2007, Benjamin Carr wrote:
For the second time in two weeks, a system restart has resulted in a
truncated filesystem on my server. The server is running 64bit SuSE with a
fibrechannel con
Kernel: 2.6.23-rc8 (older kernels do this as well)
When running the following command:
/usr/bin/time /usr/sbin/bonnie++ -d /x/test -s 16384 -m p34 -n 16:10:16:64
It hangs unless I increase various parameters md/raid such as the
stripe_cache_size etc..
# ps auxww | grep D
USER PID %C
Package: samba
Version: 3.0.26a-1
Kernel: 2.6.22
samba 3.0.26a-1 performance < 900 KiB/s, but FTP = 30-90 MiB/s
Let me start out by saing this is an oddball problem:
SAMBA:
LINUX -> WINDOWS = < 900 KiB/s (varies between 100 - 900 KiB/s)
WINDOWS -> LINUX = 30-90 MiB/s (always)
FTP:
Either dir
On Sun, 30 Sep 2007, Sinisa Bandin wrote:
Justin Piszcz wrote:
Package: samba
Version: 3.0.26a-1
Kernel: 2.6.22
samba 3.0.26a-1 performance < 900 KiB/s, but FTP = 30-90 MiB/s
Let me start out by saing this is an oddball problem:
SAMBA:
LINUX -> WINDOWS = < 900 KiB/s (varies be
On Tue, 18 Sep 2007, Konstantin Sharlaimov wrote:
I am experiencing the similar problem on my Acer Aspire 5000 laptop -
once in a while a bunch of "APIC error on CPU0: 40(40)" messages are
showing up in dmesg.
After few experiments and a lot of googling, I identified a cause - it
was my built
Including the XFS mailing list in here too because it may be an XFS bug
looking at the call trace.
System: Debian Testing
Kernel: 2.6.20
Config: Attached
I was running apt-get dist-upgrade as I always do to get the latest
packages upgraded and the kernel OOPS'd when it was upgrading 'tzdata' a
On Mon, 17 Sep 2007, Justin Piszcz wrote:
Including the XFS mailing list in here too because it may be an XFS bug
looking at the call trace.
System: Debian Testing
Kernel: 2.6.20
Config: Attached
I was running apt-get dist-upgrade as I always do to get the latest packages
upgraded and the
On Fri, 21 Sep 2007, David Chinner wrote:
On Wed, Sep 19, 2007 at 04:47:38AM -0400, Justin Piszcz wrote:
On Mon, 17 Sep 2007, Justin Piszcz wrote:
Including the XFS mailing list in here too because it may be an XFS bug
looking at the call trace.
System: Debian Testing
Kernel: 2.6.20
Hi,
I run two SSDs in a RAID-1 configuration and I have a swap partition on a
third SSD. Over time, the mismatch_cnt between the two devices grows higher
and higher.
Once a week, I run a check and repair against the md devices to help bring
the mismatch_cnt down. When I run the check and repair
On Mon, Nov 4, 2013 at 5:25 AM, Justin Piszcz wrote:
> Hi,
>
> I run two SSDs in a RAID-1 configuration and I have a swap partition on a
> third SSD. Over time, the mismatch_cnt between the two devices grows higher
> and higher.
>
> Once a week, I run a check and repair agai
> -Original Message-
> From: Bruno Prémont [mailto:bonb...@linux-vserver.org]
> Sent: Tuesday, April 01, 2014 4:22 PM
> To: Justin Piszcz
> Cc: linux-kernel@vger.kernel.org; dri-de...@lists.freedesktop.org
> Subject: Re: X.org doesn't start with 3.14: [KMS] drm r
-Original Message-
From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
Sent: Thursday, November 28, 2013 8:00 AM
To: Justin Piszcz
Cc: open list; linux-e...@vger.kernel.org; linux-s...@vger.kernel.org
Subject: Re: 3.12.0: sda2: WRITE SAME failed. Manually zeroing. with 3w-
-Original Message-
From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
Sent: Thursday, November 28, 2013 8:13 AM
[ .. ]
Martin> http://marc.info/?l=linux-scsi&m=138252394614920&w=2
Justin> Awesome, thank you! This patch is over a month old, do you know
Justin> if is currentl
On Mon, Nov 11, 2013 at 7:39 PM, Brad Campbell
wrote:
> On 11/07/2013 06:54 PM, Justin Piszcz wrote:
>>
>> On Mon, Nov 4, 2013 at 5:25 AM, Justin Piszcz
>> wrote:
>>>
>>> Hi,
>>>
>>> I run two SSDs in a RAID-1 configuration and I
Hello,
Using 3.12.0 and ext4fs with 2 x SSDs in a RAID-1 configuration on a
3ware HW RAID card, no md/dm, I noticed the following recently:
[178339.353565] sda2: WRITE SAME failed. Manually zeroing.
It seems to be similar to this issue here:
http://permalink.gmane.org/gmane.linux.kernel/1494512
Hello,
Do I need some updated ATI firmware (I believe this might have happened in
the past)..?
I booted back to 3.13.6, Xorg starts up fine, but with 3.14 it does not
start.
Thoughts?
3.13.6:
$ ps auxww|grep X
root 4368 5.3 0.0 296648 37364 tty7 Ssl+ 18:23 0:00 /usr/bin/X
:0 vt7 -nol
> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Thursday, November 28, 2013 8:13 AM
>
>
> Martin> http://marc.info/?l=linux-scsi&m=138252394614920&w=2
>
> Justin> Awesome, thank you! This patch is over a month old, do you know
> Justin
> -Original Message-
> From: Tantilov, Emil S [mailto:emil.s.tanti...@intel.com]
> Sent: Monday, February 23, 2015 11:43 AM
[ .. ]
> The reset is a side effect of the Tx hang - the driver is trying to
recover from
> the hang by resetting the interface.
>
> If you could open up a ticke
> -Original Message-
> From: Justin Piszcz [mailto:jpis...@lucidpixels.com]
> Sent: Saturday, February 28, 2015 5:57 PM
> To: linux-kernel@vger.kernel.org
> Subject: RE: 3.19 kernel: BUG: unable to handle kernel NULL pointer
> dereference
>
Removing the card did not
Hello,
Kernel: 3.19.0
Issue: When using robocopy to copy files (from Windows 8/8.1) to
Linux/samba, the 10GbE NIC resets - dmesg [1] below. To get it back working
again, I have to down/up the interface. Jumbo frames are being used (mtu of
9014) on each side. The lspci output is listed below. Ar
On Sun, Feb 22, 2015 at 7:01 AM, Justin Piszcz wrote:
>
> Hello,
>
> Kernel: 3.19.0
> Issue: When using robocopy to copy files (from Windows 8/8.1) to
> Linux/samba, the 10GbE NIC resets - dmesg [1] below. To get it back working
> again, I have to down/up the interface. J
Hello,
With kernel 3.15, I do not recall having any issues, with 3.19, I am getting
a kernel crash when I copy files over NFS from machine A to B.
Is this a known issue?
I suspect it has to do something with this:
Feb 27 09:31:20 remote-host [ 15.745342] dmar: DRHD: handling fault status
reg 2
> -Original Message-
> From: Justin Piszcz [mailto:jpis...@lucidpixels.com]
> Sent: Friday, February 27, 2015 9:54 AM
> To: linux-kernel@vger.kernel.org
> Subject: 3.19 kernel: BUG: unable to handle kernel NULL pointer
dereference
>
> Hello,
>
> With kernel 3
> -Original Message-
> From: Justin Piszcz [mailto:jpis...@lucidpixels.com]
> Sent: Friday, February 27, 2015 10:54 AM
> To: linux-kernel@vger.kernel.org
> Subject: RE: 3.19 kernel: BUG: unable to handle kernel NULL pointer
> dereference
>
>
>
> > --
> -Original Message-
> From: Justin Piszcz [mailto:jpis...@lucidpixels.com]
> Sent: Saturday, February 28, 2015 5:19 PM
> To: linux-kernel@vger.kernel.org
> Subject: RE: 3.19 kernel: BUG: unable to handle kernel NULL pointer
> dereference
>
>
>
> > --
Hello,
Kernel: 5.1 (self-compiled, no modules)
Arch: x86_64
Distro: Debian Testing
Issue: I was performing a dump of ext3 and ext4 filesystems and then
restoring them to a separate volume (testing)-- afterwards I noticed that
khugepaged is stuck at 100% CPU. It is currently still stuck at 100% CP
On Thu, May 9, 2019 at 5:54 AM Justin Piszcz wrote:
>
> Hello,
>
> Kernel: 5.1 (self-compiled, no modules)
> Arch: x86_64
> Distro: Debian Testing
>
> Issue: I was performing a dump of ext3 and ext4 filesystems and then
> restoring them to a separate volume (testing)-
On Mon, May 20, 2019 at 7:56 AM Mel Gorman wrote:
>
> On Sun, May 12, 2019 at 04:27:45AM -0400, Justin Piszcz wrote:
> > Hello,
> >
> > I've turned off zram/zswap and I am still seeing the following during
> > periods of heavy I/O, I am returning to 5.0.xx in
On Mon, May 20, 2019 at 7:56 AM Mel Gorman wrote:
>
> On Sun, May 12, 2019 at 04:27:45AM -0400, Justin Piszcz wrote:
> > Hello,
> >
> > I've turned off zram/zswap and I am still seeing the following during
> > periods of heavy I/O, I am returning to 5.0.xx in
Hello,
I've turned off zram/zswap and I am still seeing the following during
periods of heavy I/O, I am returning to 5.0.xx in the meantime.
Kernel: 5.1.1
Arch: x86_64
Dist: Debian x86_64
[29967.019411] BUG: unable to handle kernel paging request at ea000203
[29967.019414] #PF error: [no
> -Original Message-
> From: Justin Piszcz [mailto:jpis...@lucidpixels.com]
> Sent: Sunday, May 12, 2019 4:28 AM
> To: LKML
> Subject: 5.1 and 5.1.1: BUG: unable to handle kernel paging request at
> ea000203
>
> Hello,
>
> I've turned off z
> -Original Message-
> From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
> Sent: Thursday, May 09, 2019 7:14 AM
> To: Justin Piszcz
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: 5.1 kernel: khugepaged stuck at 100%
>
> On Thu, May 09, 2019 at 05:54:5
Hello,
Going to be turning these options off for now (zswap+zram) under 5.2 and
hopefully this makes the machine stable again-but just wanted to point out
under 5.1.xx never had any issues but with 5.2 the kernel crashes fairly
quickly when performing heavy I/O with these options enabled: (note:
c
Kernel: 5.9.3
Arch: x86_64
These are showing up in dmesg every so often and they are not
associated with any type of message/alert or user associated action.
What is causing this & why are there no details associated with this
message?
[Wed Nov 4 17:05:56 2020] md0:
[Thu Nov 5 08:23:32 2020]
On Tue, May 14, 2019 at 9:16 AM Kirill A. Shutemov wrote:
> Could you check what khugepaged doing?
>
> cat /proc/$(pidof khugepaged)/stack
It is doing it again, 10:12am - 2019-05-16
PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
77 root 39 19 0
On Thu, May 16, 2019 at 10:14 AM Justin Piszcz wrote:
>
> On Tue, May 14, 2019 at 9:16 AM Kirill A. Shutemov
> wrote:
>
> > Could you check what khugepaged doing?
> >
> > cat /proc/$(pidof khugepaged)/stack
>
> It is doing it again, 10:12am - 2019-05-16
>
On Thu, May 16, 2019 at 10:17 AM Justin Piszcz wrote:
>
> On Thu, May 16, 2019 at 10:14 AM Justin Piszcz
> wrote:
> >
> > On Tue, May 14, 2019 at 9:16 AM Kirill A. Shutemov
> > wrote:
> >
> > > Could you check what khugepaged doing?
> > >
&
Hello,
Kernel: 4.11.0
Arch: x86_64
First time I have run into a WARN in a while, .config is attached:
$ cp /proc/config.gz .
Snippet:
[22606.516656] [ cut here ]
[22606.516669] WARNING: CPU: 3 PID: 0 at kernel/cgroup/cgroup.c:441
cgroup_get+0x4b/0x50
[22606.516672] CPU:
> -Original Message-
> From: Cong Wang [mailto:xiyou.wangc...@gmail.com]
> Sent: Thursday, June 29, 2017 9:44 PM
> To: Justin Piszcz
> Cc: LKML
> Subject: Re: WARNING: CPU: 3 PID: 0 at kernel/cgroup/cgroup.c:441
> cgroup_get+0x4b/0x50
>
> On Thu, Jun 29, 2017
Hello,
Kernel: 4.12.0
Arch: x86_64
What causes this issue?
[199141.434449] NETDEV WATCHDOG: eth1 (igb): transmit queue 7 timed out
[199141.434501] [ cut here ]
[199141.434515] WARNING: CPU: 10 PID: 0 at net/sched/sch_generic.c:316
dev_watchdog+0x212/0x220
[199141.434528]
Hello,
kernel 4.8 with ulogd-2.0.5- IPs are no longer logged:
Oct 4 17:51:30 atom INPUT_BLOCK IN=eth1 OUT=
MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
TTL=0 ID=0 PROTO=0 MARK=0
Oct 4 17:51:31 atom INPUT_BLOCK IN=eth1 OUT=
MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LE
On Tue, Oct 4, 2016 at 8:58 PM, Liping Zhang wrote:
> Hi Justin,
>
> 2016-10-05 6:02 GMT+08:00 Justin Piszcz :
>> Hello,
>>
[ .. ]
>
> Which one are you using? iptables or nftables?
# iptables -V
iptables v1.6.0
>
> Could you please paste the related ipt
301 - 353 of 353 matches
Mail list logo
