Re: [PATCH v2 0/6] virtiofs: fix the warning for ITER_KVEC dio

On 4/22/24 22:06, Michael S. Tsirkin wrote: > On Tue, Apr 09, 2024 at 09:48:08AM +0800, Hou Tao wrote: >> Hi, >> >> On 4/8/2024 3:45 PM, Michael S. Tsirkin wrote: >>> On Wed, Feb 28, 2024 at 10:41:20PM +0800, Hou Tao wrote: From: Hou Tao Hi, The patch set aims to fix

Re: [PATCH v2 1/6] fuse: limit the length of ITER_KVEC dio by max_pages

On 3/9/24 05:26, Hou Tao wrote: > Hi, > > On 3/1/2024 9:42 PM, Miklos Szeredi wrote: >> On Wed, 28 Feb 2024 at 15:40, Hou Tao wrote: >> >>> So instead of limiting both the values of max_read and max_write in >>> kernel, capping the maximal length of kvec iter IO by using max_pages in >>>

Re: [PATCH] virtiofs: limit the length of ITER_KVEC dio by max_nopage_rw

On 1/10/24 02:16, Hou Tao wrote: Hi, On 1/9/2024 9:11 PM, Bernd Schubert wrote: On 1/3/24 11:59, Hou Tao wrote: From: Hou Tao When trying to insert a 10MB kernel module kept in a virtiofs with cache disabled, the following warning was reported:    [ cut here

Re: [PATCH] virtiofs: limit the length of ITER_KVEC dio by max_nopage_rw

On 1/3/24 11:59, Hou Tao wrote: From: Hou Tao When trying to insert a 10MB kernel module kept in a virtiofs with cache disabled, the following warning was reported: [ cut here ] WARNING: CPU: 2 PID: 439 at mm/page_alloc.c:4544 .. Modules linked in:

Re: md: Combine two kmalloc() calls into one in sb_equal()

On 09.12.2016 22:58, SF Markus Elfring wrote: Irrelevant, the variable is not used before checking it. * Will it be more appropriate to attempt another memory allocation only if the previous one succeeded already? * Can it be a bit more efficient to duplicate only the required data in a

Re: md: Combine two kmalloc() calls into one in sb_equal()

On 09.12.2016 22:58, SF Markus Elfring wrote: Irrelevant, the variable is not used before checking it. * Will it be more appropriate to attempt another memory allocation only if the previous one succeeded already? * Can it be a bit more efficient to duplicate only the required data in a

Re: md: Combine two kmalloc() calls into one in sb_equal()

On 09.12.2016 20:54, SF Markus Elfring wrote: So where did you get the idea from that it is not checked immediately? Is another variable assignment performed so far before the return value is checked from a previous function call? Irrelevant, the variable is not used before checking it.

Re: md: Combine two kmalloc() calls into one in sb_equal()

On 09.12.2016 20:54, SF Markus Elfring wrote: So where did you get the idea from that it is not checked immediately? Is another variable assignment performed so far before the return value is checked from a previous function call? Irrelevant, the variable is not used before checking it.

Re: [PATCH] md: Combine two kmalloc() calls into one in sb_equal()

On 09.12.2016 19:30, SF Markus Elfring wrote: From: Markus Elfring Date: Fri, 9 Dec 2016 19:09:13 +0100 The function "kmalloc" was called in one case by the function "sb_equal" without checking immediately if it failed. Err, your patch actually *replaces* the

Re: [PATCH] md: Combine two kmalloc() calls into one in sb_equal()

On 09.12.2016 19:30, SF Markus Elfring wrote: From: Markus Elfring Date: Fri, 9 Dec 2016 19:09:13 +0100 The function "kmalloc" was called in one case by the function "sb_equal" without checking immediately if it failed. Err, your patch actually *replaces* the check. So where did you get

Re: [PATCH v4] fuse: Add support for passthrough read/write

On 01/21/2016 01:16 AM, Nikhilesh Reddy wrote: > Add support for filesystem passthrough read/write of files > when enabled in userspace through the option FUSE_PASSTHROUGH. > > There are many FUSE based filesystems that perform checks or > enforce policy or perform some kind of decision making

Re: [PATCH v4] fuse: Add support for passthrough read/write

On 01/21/2016 01:16 AM, Nikhilesh Reddy wrote: > Add support for filesystem passthrough read/write of files > when enabled in userspace through the option FUSE_PASSTHROUGH. > > There are many FUSE based filesystems that perform checks or > enforce policy or perform some kind of decision making

Re: [PATCH] sysctl: Add a feature to drop caches selectively

On 06/27/2014 04:55 AM, Dave Chinner wrote: On Thu, Jun 26, 2014 at 02:10:28PM +0200, Bernd Schubert wrote: On 06/26/2014 01:57 PM, Lukáš Czerner wrote: On Thu, 26 Jun 2014, Artem Bityutskiy wrote: On Thu, 2014-06-26 at 12:36 +0200, Bernd Schubert wrote: On 06/26/2014 08:13 AM, Artem

Re: [PATCH] sysctl: Add a feature to drop caches selectively

On 06/27/2014 04:55 AM, Dave Chinner wrote: On Thu, Jun 26, 2014 at 02:10:28PM +0200, Bernd Schubert wrote: On 06/26/2014 01:57 PM, Lukáš Czerner wrote: On Thu, 26 Jun 2014, Artem Bityutskiy wrote: On Thu, 2014-06-26 at 12:36 +0200, Bernd Schubert wrote: On 06/26/2014 08:13 AM, Artem

Re: [PATCH] sysctl: Add a feature to drop caches selectively

On 06/26/2014 01:57 PM, Lukáš Czerner wrote: On Thu, 26 Jun 2014, Artem Bityutskiy wrote: On Thu, 2014-06-26 at 12:36 +0200, Bernd Schubert wrote: On 06/26/2014 08:13 AM, Artem Bityutskiy wrote: On Thu, 2014-06-26 at 11:06 +1000, Dave Chinner wrote: Your particular use case can be handled

Re: [PATCH] sysctl: Add a feature to drop caches selectively

On 06/26/2014 08:13 AM, Artem Bityutskiy wrote: On Thu, 2014-06-26 at 11:06 +1000, Dave Chinner wrote: Your particular use case can be handled by directing your benchmark at a filesystem mount point and unmounting the filesystem in between benchmark runs. There is no ned to adding kernel

Re: [PATCH] sysctl: Add a feature to drop caches selectively

On 06/26/2014 08:13 AM, Artem Bityutskiy wrote: On Thu, 2014-06-26 at 11:06 +1000, Dave Chinner wrote: Your particular use case can be handled by directing your benchmark at a filesystem mount point and unmounting the filesystem in between benchmark runs. There is no ned to adding kernel

Re: [PATCH] sysctl: Add a feature to drop caches selectively

On 06/26/2014 01:57 PM, Lukáš Czerner wrote: On Thu, 26 Jun 2014, Artem Bityutskiy wrote: On Thu, 2014-06-26 at 12:36 +0200, Bernd Schubert wrote: On 06/26/2014 08:13 AM, Artem Bityutskiy wrote: On Thu, 2014-06-26 at 11:06 +1000, Dave Chinner wrote: Your particular use case can be handled

Re: [PATCH 02/11][SCSI]mpt2sas: Added new driver module Parameter disable_eedp to Disable EEDP Support

u8 scsi_io_cb_idx; diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c b/drivers/scsi/mpt2sas/mpt2sas_scsih.c index 7f0af4f..d502728 100644 --- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c +++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c @@ -127,6 +127,11 @@ static int disable_discovery =

Re: [PATCH 02/11][SCSI]mpt2sas: Added new driver module Parameter disable_eedp to Disable EEDP Support

u8 scsi_io_cb_idx; diff --git a/drivers/scsi/mpt2sas/mpt2sas_scsih.c b/drivers/scsi/mpt2sas/mpt2sas_scsih.c index 7f0af4f..d502728 100644 --- a/drivers/scsi/mpt2sas/mpt2sas_scsih.c +++ b/drivers/scsi/mpt2sas/mpt2sas_scsih.c @@ -127,6 +127,11 @@ static int disable_discovery =

kmemleak or crc32_le bug?

I'm frequently getting UG: unable to handle kernel paging request at 880f87550dc0 IP: [] crc32_le+0x30/0x110 called from kmemleak, see bottom of the message. schubert@wheezy@fsdevel2 linux-stable>addr2line -e vmlinux -i -a 813016d0 0x813016d0

kmemleak or crc32_le bug?

I'm frequently getting UG: unable to handle kernel paging request at 880f87550dc0 IP: [813016d0] crc32_le+0x30/0x110 called from kmemleak, see bottom of the message. schubert@wheezy@fsdevel2 linux-stableaddr2line -e vmlinux -i -a 813016d0 0x813016d0

Re: Subject: [v3.8][v3.11][Regression] [SCSI] sd: Update WRITE SAME heuristics

Hello Joseph, On 10/29/2013 08:21 PM, Joseph Salisbury wrote: Hi Martin, A bug was opened against the Ubuntu kernel[0]. After a kernel bisect, it was found that reverting the following commit resolved this bug: commit 66c28f97120e8a621afd5aa7a31c4b85c547d33d Author: Martin K. Petersen Date:

Re: Subject: [v3.8][v3.11][Regression] [SCSI] sd: Update WRITE SAME heuristics

Hello Joseph, On 10/29/2013 08:21 PM, Joseph Salisbury wrote: Hi Martin, A bug was opened against the Ubuntu kernel[0]. After a kernel bisect, it was found that reverting the following commit resolved this bug: commit 66c28f97120e8a621afd5aa7a31c4b85c547d33d Author: Martin K. Petersen

Re: [RFC] extending splice for copy offloading

On 09/30/2013 09:34 PM, Myklebust, Trond wrote: On Mon, 2013-09-30 at 20:49 +0200, Bernd Schubert wrote: On 09/30/2013 08:02 PM, Myklebust, Trond wrote: On Mon, 2013-09-30 at 19:48 +0200, Bernd Schubert wrote: On 09/30/2013 07:44 PM, Myklebust, Trond wrote: On Mon, 2013-09-30 at 19:17 +0200

Re: [RFC] extending splice for copy offloading

On 09/30/2013 08:02 PM, Myklebust, Trond wrote: On Mon, 2013-09-30 at 19:48 +0200, Bernd Schubert wrote: On 09/30/2013 07:44 PM, Myklebust, Trond wrote: On Mon, 2013-09-30 at 19:17 +0200, Bernd Schubert wrote: It would be nice if there would be way if the file system would get a hint

Re: [RFC] extending splice for copy offloading

On 09/30/2013 07:44 PM, Myklebust, Trond wrote: On Mon, 2013-09-30 at 19:17 +0200, Bernd Schubert wrote: It would be nice if there would be way if the file system would get a hint that the target file is supposed to be copy of another file. That way distributed file systems could also create

Re: [RFC] extending splice for copy offloading

On 09/30/2013 06:31 PM, Miklos Szeredi wrote: Here's an example "cp" app using direct splice (and without fallback to non-splice, which is obviously required unless the kernel is known to support direct splice). Untested, but trivial enough... The important part is, I think, that the app must

Re: [RFC] extending splice for copy offloading

On 09/30/2013 06:31 PM, Miklos Szeredi wrote: Here's an example cp app using direct splice (and without fallback to non-splice, which is obviously required unless the kernel is known to support direct splice). Untested, but trivial enough... The important part is, I think, that the app must

Re: [RFC] extending splice for copy offloading

On 09/30/2013 07:44 PM, Myklebust, Trond wrote: On Mon, 2013-09-30 at 19:17 +0200, Bernd Schubert wrote: It would be nice if there would be way if the file system would get a hint that the target file is supposed to be copy of another file. That way distributed file systems could also create

Re: [RFC] extending splice for copy offloading

On 09/30/2013 08:02 PM, Myklebust, Trond wrote: On Mon, 2013-09-30 at 19:48 +0200, Bernd Schubert wrote: On 09/30/2013 07:44 PM, Myklebust, Trond wrote: On Mon, 2013-09-30 at 19:17 +0200, Bernd Schubert wrote: It would be nice if there would be way if the file system would get a hint

Re: [RFC] extending splice for copy offloading

On 09/30/2013 09:34 PM, Myklebust, Trond wrote: On Mon, 2013-09-30 at 20:49 +0200, Bernd Schubert wrote: On 09/30/2013 08:02 PM, Myklebust, Trond wrote: On Mon, 2013-09-30 at 19:48 +0200, Bernd Schubert wrote: On 09/30/2013 07:44 PM, Myklebust, Trond wrote: On Mon, 2013-09-30 at 19:17 +0200

Re: Drivers: scsi: FLUSH timeout

On 09/24/2013 02:35 PM, KY Srinivasan wrote: -Original Message- From: Jack Wang [mailto:xjtu...@gmail.com] Sent: Tuesday, September 24, 2013 5:08 AM To: KY Srinivasan Cc: Greg KH; linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com;

Re: Drivers: scsi: FLUSH timeout

On 09/24/2013 02:35 PM, KY Srinivasan wrote: -Original Message- From: Jack Wang [mailto:xjtu...@gmail.com] Sent: Tuesday, September 24, 2013 5:08 AM To: KY Srinivasan Cc: Greg KH; linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com;

Re: [PATCH] scsi disk: Use its own buffer for the vpd request

On 08/31/2013 09:48 PM, Nix wrote: > On 31 Aug 2013, Greg KH said: >> On Fri, Aug 30, 2013 at 11:01:56AM +0100, Nix wrote: >>> On 1 Aug 2013, Bernd Schubert said: >>> >>>> Once I noticed that scsi_get_vpd_page() works fine from other function >>>

Re: [PATCH] scsi disk: Use its own buffer for the vpd request

On 08/31/2013 09:48 PM, Nix wrote: On 31 Aug 2013, Greg KH said: On Fri, Aug 30, 2013 at 11:01:56AM +0100, Nix wrote: On 1 Aug 2013, Bernd Schubert said: Once I noticed that scsi_get_vpd_page() works fine from other function calls and that it is not 0x89, but already 0x0 that fails fixing

Re: [PATCH] scsi disk: Use its own buffer for the vpd request

Martin, sorry for my late reply, I entirely lost track of this (customer issues, vacation, lots of main work, ...). On 08/02/2013 05:00 AM, Martin K. Petersen wrote: >>>>>> "Bernd" == Bernd Schubert writes: > > Bernd, > > Bernd> Once I noticed tha

Re: [PATCH] scsi disk: Use its own buffer for the vpd request

Martin, sorry for my late reply, I entirely lost track of this (customer issues, vacation, lots of main work, ...). On 08/02/2013 05:00 AM, Martin K. Petersen wrote: Bernd == Bernd Schubert bernd.schub...@fastmail.fm writes: Bernd, Bernd Once I noticed that scsi_get_vpd_page() works fine

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 08/01/2013 06:04 PM, Nix wrote: On 1 Aug 2013, Bernd Schubert verbalised: On 07/30/2013 11:20 PM, Nix wrote: On 30 Jul 2013, Bernd Schubert told this: On 07/30/2013 02:56 AM, Nix wrote: On 30 Jul 2013, Douglas Gilbert outgrape: Please supply the information that Martin Petersen asked

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 07/30/2013 11:20 PM, Nix wrote: On 30 Jul 2013, Bernd Schubert told this: On 07/30/2013 02:56 AM, Nix wrote: On 30 Jul 2013, Douglas Gilbert outgrape: Please supply the information that Martin Petersen asked for. Did it in private IRC (the advantage of working for the same division

Re: [PATCH] scsi disk: Use its own buffer for the vpd request

Whoops, the title is wrong, it should have been: [PATCH] scsi disk: Limit get_vpd_page buf size On 08/01/2013 04:34 PM, Bernd Schubert wrote: Once I noticed that scsi_get_vpd_page() works fine from other function calls and that it is not 0x89, but already 0x0 that fails fixing it became easy

[PATCH] scsi disk: Use its own buffer for the vpd request

Once I noticed that scsi_get_vpd_page() works fine from other function calls and that it is not 0x89, but already 0x0 that fails fixing it became easy. Nix, any chance you could verify it also works for you? From: Bernd Schubert Somehow older areca firmware versions have issues

[PATCH] scsi disk: Use its own buffer for the vpd request

Once I noticed that scsi_get_vpd_page() works fine from other function calls and that it is not 0x89, but already 0x0 that fails fixing it became easy. Nix, any chance you could verify it also works for you? From: Bernd Schubert bernd.schub...@itwm.fraunhofer.de Somehow older areca firmware

Re: [PATCH] scsi disk: Use its own buffer for the vpd request

Whoops, the title is wrong, it should have been: [PATCH] scsi disk: Limit get_vpd_page buf size On 08/01/2013 04:34 PM, Bernd Schubert wrote: Once I noticed that scsi_get_vpd_page() works fine from other function calls and that it is not 0x89, but already 0x0 that fails fixing it became easy

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 07/30/2013 11:20 PM, Nix wrote: On 30 Jul 2013, Bernd Schubert told this: On 07/30/2013 02:56 AM, Nix wrote: On 30 Jul 2013, Douglas Gilbert outgrape: Please supply the information that Martin Petersen asked for. Did it in private IRC (the advantage of working for the same division

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 08/01/2013 06:04 PM, Nix wrote: On 1 Aug 2013, Bernd Schubert verbalised: On 07/30/2013 11:20 PM, Nix wrote: On 30 Jul 2013, Bernd Schubert told this: On 07/30/2013 02:56 AM, Nix wrote: On 30 Jul 2013, Douglas Gilbert outgrape: Please supply the information that Martin Petersen asked

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 07/31/2013 05:15 AM, Martin K. Petersen wrote: >>>>>> "Bernd" == Bernd Schubert writes: > > Bernd, > >>> Product revision level: R001 > > It's clearly not verbatim passthrough... > > Bernd> Besides the firmware, the difference

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 07/31/2013 05:15 AM, Martin K. Petersen wrote: Bernd == Bernd Schubert bernd.schub...@fastmail.fm writes: Bernd, Product revision level: R001 It's clearly not verbatim passthrough... Bernd Besides the firmware, the difference might be that I'm exporting Bernd single disks without

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 07/30/2013 02:56 AM, Nix wrote: On 30 Jul 2013, Douglas Gilbert outgrape: Please supply the information that Martin Petersen asked for. Did it in private IRC (the advantage of working for the same division of the same company!) I didn't realise the original fix was actually implemented

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 07/30/2013 01:34 AM, Martin K. Petersen wrote: "Nix" == Nix writes: Bernd, Nix> I can now confirm that reverting this commit causes this problem to Nix> go away, and my machine boots fine again. Can you please send me the output of sq_inq with your 1.49 firmware? I made a tweak that

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 07/30/2013 01:34 AM, Martin K. Petersen wrote: Nix == Nix n...@esperi.org.uk writes: Bernd, Nix I can now confirm that reverting this commit causes this problem to Nix go away, and my machine boots fine again. Can you please send me the output of sq_inq with your 1.49 firmware? I made a

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 07/30/2013 02:56 AM, Nix wrote: On 30 Jul 2013, Douglas Gilbert outgrape: Please supply the information that Martin Petersen asked for. Did it in private IRC (the advantage of working for the same division of the same company!) I didn't realise the original fix was actually implemented

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 07/29/2013 03:05 PM, Nix wrote: On 29 Jul 2013, Bernd Schubert said: Hi Nick, On 07/29/2013 12:10 PM, Nick Alcock wrote: arcmsr0: abort device command of scsi id = 0 lun = 1 arcmsr0: abort device command of scsi id = 0 lun = 0 arcmsr: executing bus reset eh.num_resets=0, num_

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

Hi Nick, On 07/29/2013 12:10 PM, Nick Alcock wrote: My server's ARC-1210 has been working fine for years, but when I upgraded from 3.10.1, it started failing: Instead of [0.784044] Areca RAID Controller0: F/W V1.46 2009-01-06 & Model ARC-1210 [0.804028] scsi0 : Areca SATA Host Adapter

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

Hi Nick, On 07/29/2013 12:10 PM, Nick Alcock wrote: My server's ARC-1210 has been working fine for years, but when I upgraded from 3.10.1, it started failing: Instead of [0.784044] Areca RAID Controller0: F/W V1.46 2009-01-06 Model ARC-1210 [0.804028] scsi0 : Areca SATA Host Adapter

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 07/29/2013 03:05 PM, Nix wrote: On 29 Jul 2013, Bernd Schubert said: Hi Nick, On 07/29/2013 12:10 PM, Nick Alcock wrote: arcmsr0: abort device command of scsi id = 0 lun = 1 arcmsr0: abort device command of scsi id = 0 lun = 0 arcmsr: executing bus reset eh.num_resets=0, num_

Re: [PATCH 1/2] coccicheck: Allow the user to give a VERBOSE= argument

Hello Nicolas, thanks for your review! Cheers, Bernd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at

Re: [PATCH 1/2] coccicheck: Allow the user to give a VERBOSE= argument

Hello Nicolas, thanks for your review! Cheers, Bernd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at

[PATCH 2 2/2] coccicheck: Allow to show the executed command line

On my system one of the tests failed with "Fatal error: exception Failure("No OCaml compiler found! Install either ocamlopt or ocamlopt.opt")". Investigating such issues is easier if the executed command line is being shown. Signed-off-by: Bernd Schubert CC: Julia Lawall C

[PATCH 2 1/2] coccicheck: Allow the user to give a V= (verbose) argument

Do not run with verbosity on/off depending on the ONLINE variable, which gets set with C=1 or C=2, but allow the user to set the verbosity using kernel default make V= paramemter. Verbosity is off by default now. Signed-off-by: Bernd Schubert CC: Julia Lawall CC: Nicolas Palix CC: co

[PATCH 2 1/2] coccicheck: Allow the user to give a V= (verbose) argument

Do not run with verbosity on/off depending on the ONLINE variable, which gets set with C=1 or C=2, but allow the user to set the verbosity using kernel default make V= paramemter. Verbosity is off by default now. Signed-off-by: Bernd Schubert bernd.schub...@itwm.fraunhofer.de CC: Julia Lawall

[PATCH 2 2/2] coccicheck: Allow to show the executed command line

On my system one of the tests failed with Fatal error: exception Failure(No OCaml compiler found! Install either ocamlopt or ocamlopt.opt). Investigating such issues is easier if the executed command line is being shown. Signed-off-by: Bernd Schubert bernd.schub...@itwm.fraunhofer.de CC: Julia

Re: [PATCH 1/2] coccicheck: Allow the user to give a VERBOSE= argument

? Hmm, I probably should have told in the patch description that verbosity defaults to 0 now. Shall I revert or make an extra patch for that? With the current patch and ONLINE != 0 nothing will change. Cheers, Bernd Regards, On Tue, Jan 22, 2013 at 2:34 PM, Bernd Schubert wrote: Simply

[PATCH 2/2] coccicheck: Allow to show the executed command line

On my system one of the tests failed with "Fatal error: exception Failure("No OCaml compiler found! Install either ocamlopt or ocamlopt.opt")". Investigating such issues is easier if the executed command line is being shown. Signed-off-by: Bernd Schubert CC: Julia Lawall C

[PATCH 1/2] coccicheck: Allow the user to give a VERBOSE= argument

Simply running "make coccicheck" returns very verbose output and warnings might not be noticed. Allow the user to set the verbosity level. Signed-off-by: Bernd Schubert CC: Julia Lawall CC: Nicolas Palix CC: co...@systeme.lip6.fr --- scripts/coccicheck |8 +++- 1 file

[PATCH 1/2] coccicheck: Allow the user to give a VERBOSE= argument

Simply running make coccicheck returns very verbose output and warnings might not be noticed. Allow the user to set the verbosity level. Signed-off-by: Bernd Schubert bernd.schub...@itwm.fraunhofer.de CC: Julia Lawall julia.law...@lip6.fr CC: Nicolas Palix nicolas.pa...@imag.fr CC: co

[PATCH 2/2] coccicheck: Allow to show the executed command line

On my system one of the tests failed with Fatal error: exception Failure(No OCaml compiler found! Install either ocamlopt or ocamlopt.opt). Investigating such issues is easier if the executed command line is being shown. Signed-off-by: Bernd Schubert bernd.schub...@itwm.fraunhofer.de CC: Julia

Re: [PATCH 1/2] coccicheck: Allow the user to give a VERBOSE= argument

? Hmm, I probably should have told in the patch description that verbosity defaults to 0 now. Shall I revert or make an extra patch for that? With the current patch and ONLINE != 0 nothing will change. Cheers, Bernd Regards, On Tue, Jan 22, 2013 at 2:34 PM, Bernd Schubert bernd.schub

Re: [regression] 3.7 ends in APIC panic

On 12/17/2012 11:00 AM, Borislav Petkov wrote: + Suresh. On Mon, Dec 17, 2012 at 10:34:46AM +0100, Bernd Schubert wrote: On 12/16/2012 09:39 PM, Borislav Petkov wrote: On Sun, Dec 16, 2012 at 08:46:06PM +0100, Bernd Schubert wrote: Hmm, I read it the other way around - x2apic depends

Re: [regression] 3.7 ends in APIC panic

On 12/16/2012 09:39 PM, Borislav Petkov wrote: On Sun, Dec 16, 2012 at 08:46:06PM +0100, Bernd Schubert wrote: Hmm, I read it the other way around - x2apic depends on interrupt remapping, but interrupt remapping can be used without x2apic. Ok, you're right. X2APIC should depend on IRQ_REMAP

Re: [regression] 3.7 ends in APIC panic

On 12/16/2012 07:07 PM, Yinghai Lu wrote: On Sun, Dec 16, 2012 at 10:01 AM, Bernd Schubert wrote: can you post your .config for v3.7 ? wonder if you have x2apic in .config Which setting is it? Config is attached. your config does not have CONFIG_X86_X2APIC=y set. please enable

Re: [regression] 3.7 ends in APIC panic

On 12/16/2012 07:07 PM, Yinghai Lu wrote: On Sun, Dec 16, 2012 at 10:01 AM, Bernd Schubert bernd.schub...@itwm.fraunhofer.de wrote: can you post your .config for v3.7 ? wonder if you have x2apic in .config Which setting is it? Config is attached. your config does not have

Re: [regression] 3.7 ends in APIC panic

On 12/16/2012 09:39 PM, Borislav Petkov wrote: On Sun, Dec 16, 2012 at 08:46:06PM +0100, Bernd Schubert wrote: Hmm, I read it the other way around - x2apic depends on interrupt remapping, but interrupt remapping can be used without x2apic. Ok, you're right. X2APIC should depend on IRQ_REMAP

Re: [regression] 3.7 ends in APIC panic

On 12/17/2012 11:00 AM, Borislav Petkov wrote: + Suresh. On Mon, Dec 17, 2012 at 10:34:46AM +0100, Bernd Schubert wrote: On 12/16/2012 09:39 PM, Borislav Petkov wrote: On Sun, Dec 16, 2012 at 08:46:06PM +0100, Bernd Schubert wrote: Hmm, I read it the other way around - x2apic depends

Re: [regression] 3.7 ends in APIC panic

On 12/16/2012 08:13 PM, Borislav Petkov wrote: > On Sun, Dec 16, 2012 at 07:28:59PM +0100, Bernd Schubert wrote: >> CONFIG_X86_X2APIC depends on CONFIG_IRQ_REMAP, which I disabled as it >> is marked as experimental... > > You shouldn't pay too much attention to CONFIG

Re: [regression] 3.7 ends in APIC panic

On 12/16/2012 07:07 PM, Yinghai Lu wrote: > On Sun, Dec 16, 2012 at 10:01 AM, Bernd Schubert > wrote: >>> can you post your .config for v3.7 ? >>> >>> wonder if you have x2apic in .config >> >> Which setting is it? Config is attached. > >

Re: [regression] 3.7 ends in APIC panic

On 12/16/2012 12:35 PM, Ingo Molnar wrote: > > * Bernd Schubert wrote: > >> On 12/13/2012 01:16 PM, Bernd Schubert wrote: >>> Hello, >>> >>> I just tried to boot 3.7 and it ends in an APIC panic. I >>> tried to use the recommended &

Re: [regression] 3.7 ends in APIC panic

On 12/16/2012 12:35 PM, Ingo Molnar wrote: * Bernd Schubert bernd.schub...@itwm.fraunhofer.de wrote: On 12/13/2012 01:16 PM, Bernd Schubert wrote: Hello, I just tried to boot 3.7 and it ends in an APIC panic. I tried to use the recommended apic=debug, but that does not change anything

Re: [regression] 3.7 ends in APIC panic

On 12/16/2012 07:07 PM, Yinghai Lu wrote: On Sun, Dec 16, 2012 at 10:01 AM, Bernd Schubert bernd.schub...@itwm.fraunhofer.de wrote: can you post your .config for v3.7 ? wonder if you have x2apic in .config Which setting is it? Config is attached. your config does not have

Re: [regression] 3.7 ends in APIC panic

On 12/16/2012 08:13 PM, Borislav Petkov wrote: On Sun, Dec 16, 2012 at 07:28:59PM +0100, Bernd Schubert wrote: CONFIG_X86_X2APIC depends on CONFIG_IRQ_REMAP, which I disabled as it is marked as experimental... You shouldn't pay too much attention to CONFIG_EXPERIMENTAL because it is on its

Re: [regression] 3.7 ends in APIC panic

On 12/13/2012 01:16 PM, Bernd Schubert wrote: Hello, I just tried to boot 3.7 and it ends in an APIC panic. I tried to use the recommended "apic=debug", but that does not change anything in the output, at least not in the visible part. The last known kernel to boot was 3.5. If it mat

Re: [regression] 3.7 ends in APIC panic

On 12/13/2012 01:16 PM, Bernd Schubert wrote: Hello, I just tried to boot 3.7 and it ends in an APIC panic. I tried to use the recommended apic=debug, but that does not change anything in the output, at least not in the visible part. The last known kernel to boot was 3.5. If it matters I can

memory allocation: smap large "Size", but unused

Hello, I'm just investigating why a user space program has a rather large VmSize, but small VmRSS size. Looking into /proc/$pid/smaps I notice several areas with an size of about 64MB, but otherwise that area is unused. So far I did not find a way how to reproduce that with malloc() calls.

memory allocation: smap large Size, but unused

Hello, I'm just investigating why a user space program has a rather large VmSize, but small VmRSS size. Looking into /proc/$pid/smaps I notice several areas with an size of about 64MB, but otherwise that area is unused. So far I did not find a way how to reproduce that with malloc() calls.

Re: [PATCH]:dir.c patch

On 08/25/2012 10:37 PM, Christopher Sacchi wrote: > Here is a non-style issue dir.c-patch, and as far as I can see from > the lines of code, the compilation errors weren't about what I put in. > This patch fixes a "break" statement inside an "if" statement, as > obviously not correct. Why should

Re: [PATCH]:dir.c patch

On 08/25/2012 10:37 PM, Christopher Sacchi wrote: Here is a non-style issue dir.c-patch, and as far as I can see from the lines of code, the compilation errors weren't about what I put in. This patch fixes a break statement inside an if statement, as obviously not correct. Why should that not

Re: Performance problems with 3ware 9500S-4LP and 2.6.25-rc3

ng. Even Nagios complains > about the machine being down while rsync is running. do you have the write-back cache of the controller enabled for your disks? When you disable this cache, the controller will also disable the disks, cause a write-performance between 3 to 8MB/s per disks. Cheer

Re: Performance problems with 3ware 9500S-4LP and 2.6.25-rc3

being down while rsync is running. do you have the write-back cache of the controller enabled for your disks? When you disable this cache, the controller will also disable the disks, cause a write-performance between 3 to 8MB/s per disks. Cheers, Bernd -- Bernd Schubert Q-Leap Networks GmbH

Re: sleep before boot panic

Hello Ingo, On Sunday 06 January 2008, Ingo Oeser wrote: > Hi Bernd, > > On Sunday 06 January 2008, you wrote: > > Index: zd1211rw.git.beno/init/do_mounts.c > > === > > --- zd1211rw.git.beno.orig/init/do_mounts.c 2008-01-06

sleep before boot panic

was missing. Signed-off-by: Bernd Schubert <[EMAIL PROTECTED]> Index: zd1211rw.git.beno/init/do_mounts.c === --- zd1211rw.git.beno.orig/init/do_mounts.c 2008-01-06 18:44:23.0 +0100 +++ zd1211rw.git.beno/init/do_mounts.c

sleep before boot panic

was missing. Signed-off-by: Bernd Schubert [EMAIL PROTECTED] Index: zd1211rw.git.beno/init/do_mounts.c === --- zd1211rw.git.beno.orig/init/do_mounts.c 2008-01-06 18:44:23.0 +0100 +++ zd1211rw.git.beno/init/do_mounts.c 2008-01

Re: everything in wait_for_completion, what is my system doing?

Hello Andrew, thanks for your help! On Friday 07 December 2007 02:09:11 Andrew Morton wrote: > On Wed, 5 Dec 2007 21:44:54 +0100 > > Bernd Schubert <[EMAIL PROTECTED]> wrote: > > after scsi-recovery a system here went into some kind lock-up, everything > > seems t

Re: everything in wait_for_completion, what is my system doing?

Hello Andrew, thanks for your help! On Friday 07 December 2007 02:09:11 Andrew Morton wrote: On Wed, 5 Dec 2007 21:44:54 +0100 Bernd Schubert [EMAIL PROTECTED] wrote: after scsi-recovery a system here went into some kind lock-up, everything seems to be in wait_for_completion(). Please see

Re: [PATCH 3/3] faster workaround

hatever I could do, it would be best to do it shortly after the scheduled reboot. Actually I now would have attempted to port your mod15 patch (http://home-tj.org/wiki/index.php/Sil_m15w#Patches) to 2.6.23, hoping it would solve Soerens problem and ours as well (ours magically already wen

Re: [PATCH 3/3] faster workaround

it would solve Soerens problem and ours as well (ours magically already went away using the mod15 fix). Well, maybe I port it anyway to 2.6.23 to see if it also solves our problem. Thanks, Bernd -- Bernd Schubert Q-Leap Networks GmbH - To unsubscribe from this list: send the line unsubscribe

Re: sata sil3114 vs. certain seagate drives results in filesystem corruptions

ll every 1-2 GB a couple of > bytes are corrupted). Are you getting similiarly many in the 50G - 230G > region? I never tested what is corrupted. Well, a diff over 250GB would take quite a lot of time... -- Bernd Schubert Q-Leap Networks GmbH - To unsubscribe from this list: send the

Re: sata sil3114 vs. certain seagate drives results in filesystem corruptions

On Monday 22 October 2007 12:36:32 Soeren Sonnenburg wrote: > On Mon, 2007-10-22 at 11:48 +0200, Bernd Schubert wrote: > > Hello, > > > > On Monday 22 October 2007 04:12:44 Tejun Heo wrote: > > > Helo, > > > [...] > > > > > > >

Re: sata sil3114 vs. certain seagate drives results in filesystem corruptions

ystem will report errors somewhere between 50GB and 230GB (disk size is 250GB). > > Thanks. I'll try to reproduce the problem here. What's your motherboard? All tested S2882 boards here. Cheers, Bernd -- Bernd Schubert Q-Leap Networks GmbH - To unsubscribe from this list: send

Re: sata sil3114 vs. certain seagate drives results in filesystem corruptions

, but as much as it fits onto the disk. On reading back this file, the filesystem will report errors somewhere between 50GB and 230GB (disk size is 250GB). Thanks. I'll try to reproduce the problem here. What's your motherboard? All tested S2882 boards here. Cheers, Bernd -- Bernd Schubert

Re: sata sil3114 vs. certain seagate drives results in filesystem corruptions

On Monday 22 October 2007 12:36:32 Soeren Sonnenburg wrote: On Mon, 2007-10-22 at 11:48 +0200, Bernd Schubert wrote: Hello, On Monday 22 October 2007 04:12:44 Tejun Heo wrote: Helo, [...] Now when I write large files of zeros to root(sdasdb) and read the file back

  1   2   >