Highpoint RocketRAID 3720A not detected (4.19.63)
oid_registry 16384 1 auth_rpcgss nfs_acl16384 1 nfsd nfs 233472 0 lockd 77824 2 nfsd,nfs grace 16384 2 nfsd,lockd sunrpc311296 21 nfsd,auth_rpcgss,lockd,nfs_acl,nfs nfnetlink 16384 0 bridge143360 0 stp16384 1 bridge llc16384 2 bridge,stp it87 57344 0 hwmon_vid 16384 1 it87 dm_crypt 36864 0 dm_mod118784 1 dm_crypt dax20480 1 dm_mod amd64_edac_mod 28672 0 edac_mce_amd 28672 1 amd64_edac_mod kvm_amd73728 0 kvm 593920 1 kvm_amd irqbypass 16384 1 kvm k10temp16384 0 sr_mod 20480 0 cdrom 36864 1 sr_mod sg 32768 0 rtc_cmos 20480 1 r8169 69632 0 realtek20480 0 acpi_cpufreq 16384 0 button 16384 0 raid1 36864 0 md_mod126976 1 raid1 crc32c_intel 24576 0 sata_sil24 20480 0 hrm@amelia:~ $ sudo lshw [...] *-pci:5 description: PCI bridge product: SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0) vendor: Advanced Micro Devices, Inc. [AMD/ATI] physical id: 15 bus info: pci@:00:15.0 version: 00 width: 32 bits clock: 33MHz capabilities: pci pm pciexpress msi ht normal_decode bus_master cap_list configuration: driver=pcieport resources: irq:16 memory:fe60-fe6f ioport:d000(size=2097152) *-raid UNCLAIMED description: RAID bus controller product: HighPoint Technologies, Inc. vendor: HighPoint Technologies, Inc. physical id: 0 bus info: pci@:06:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: raid pm msi msix pciexpress bus_master cap_list configuration: latency=0 resources: memory:d000-d00f memory:d010-d013 memory:fe60-fe61 [...] -- Hugo Mills | Mushrooms on toast: the breakfast of champignons hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 |
Re: [PATCH v5 2/5] lib: Add zstd modules
On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote: > On 08/10/2017 04:30 AM, Eric Biggers wrote: > > > >Theses benchmarks are misleading because they compress the whole file as a > >single stream without resetting the dictionary, which isn't how data will > >typically be compressed in kernel mode. With filesystem compression the data > >has to be divided into small chunks that can each be decompressed > >independently. > >That eliminates one of the primary advantages of Zstandard (support for large > >dictionary sizes). > > I did btrfs benchmarks of kernel trees and other normal data sets as > well. The numbers were in line with what Nick is posting here. > zstd is a big win over both lzo and zlib from a btrfs point of view. > > It's true Nick's patches only support a single compression level in > btrfs, but that's because btrfs doesn't have a way to pass in the > compression ratio. It could easily be a mount option, it was just > outside the scope of Nick's initial work. Could we please not add more mount options? I get that they're easy to implement, but it's a very blunt instrument. What we tend to see (with both nodatacow and compress) is people using the mount options, then asking for exceptions, discovering that they can't do that, and then falling back to doing it with attributes or btrfs properties. Could we just start with btrfs properties this time round, and cut out the mount option part of this cycle. In the long run, it'd be great to see most of the btrfs-specific mount options get deprecated and ultimately removed entirely, in favour of attributes/properties, where feasible. Hugo. -- Hugo Mills | Klytus! Are your men on the right pills? Maybe you hugo@... carfax.org.uk | should execute their trainer! http://carfax.org.uk/ | PGP: E2AB1DE4 | Ming the Merciless, Flash Gordon signature.asc Description: Digital signature
Re: [PATCH v5 2/5] lib: Add zstd modules
On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote: > On 08/10/2017 04:30 AM, Eric Biggers wrote: > > > >Theses benchmarks are misleading because they compress the whole file as a > >single stream without resetting the dictionary, which isn't how data will > >typically be compressed in kernel mode. With filesystem compression the data > >has to be divided into small chunks that can each be decompressed > >independently. > >That eliminates one of the primary advantages of Zstandard (support for large > >dictionary sizes). > > I did btrfs benchmarks of kernel trees and other normal data sets as > well. The numbers were in line with what Nick is posting here. > zstd is a big win over both lzo and zlib from a btrfs point of view. > > It's true Nick's patches only support a single compression level in > btrfs, but that's because btrfs doesn't have a way to pass in the > compression ratio. It could easily be a mount option, it was just > outside the scope of Nick's initial work. Could we please not add more mount options? I get that they're easy to implement, but it's a very blunt instrument. What we tend to see (with both nodatacow and compress) is people using the mount options, then asking for exceptions, discovering that they can't do that, and then falling back to doing it with attributes or btrfs properties. Could we just start with btrfs properties this time round, and cut out the mount option part of this cycle. In the long run, it'd be great to see most of the btrfs-specific mount options get deprecated and ultimately removed entirely, in favour of attributes/properties, where feasible. Hugo. -- Hugo Mills | Klytus! Are your men on the right pills? Maybe you hugo@... carfax.org.uk | should execute their trainer! http://carfax.org.uk/ | PGP: E2AB1DE4 | Ming the Merciless, Flash Gordon signature.asc Description: Digital signature
Re: [PATCH] scatterlist.h: Change CONFIG_DEBUG_SG for ifdef statement in sg_set_bf
On Sun, Aug 03, 2014 at 01:30:44PM -0400, Nick Krause wrote:
> On Sun, Aug 3, 2014 at 8:28 AM, Sergei Shtylyov
> > On 03-08-2014 6:56, Nicholas Krause wrote:
> >
> >> This changes the ifdef statement in sg_set_bg to !CONFIG_DEBUG_SG in
> >> order
> >> to avoid a bug with xhci dequence/enquence functions.
> >
> >
> >dequeue/enqueue?
> >
> >
> >> Signed-off-by: Nicholas Krause
> >> ---
> >> include/linux/scatterlist.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >
> >> diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
> >> index adae88f..62de7b3 100644
> >> --- a/include/linux/scatterlist.h
> >> +++ b/include/linux/scatterlist.h
> >> @@ -111,7 +111,7 @@ static inline struct page *sg_page(struct scatterlist
> >> *sg)
> >> static inline void sg_set_buf(struct scatterlist *sg, const void *buf,
> >> unsigned int buflen)
> >> {
> >> -#ifdef CONFIG_DEBUG_SG
> >> +#ifdef !CONFIG_DEBUG_SG
> >
> >
> >Didn't you mean #ifndef instead? I guess you didn't even try to
> > build-test this.
> >
> >
> >> BUG_ON(!virt_addr_valid(buf));
> >> #endif
> >> sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
> >
> >
> > WBR, Sergei
> >
> I am going to stay around and learn more but am going to check my
> patches better as this is
> my fault.
This is something like the fourth time you've said this, and you
still haven't managed to do it. :(
Compile the code. Every. Single. Time.
Test the code. Every. Single. Time.
Not optional, not negotiable.
Hugo.
> Regards Nick
> --
> 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 http://www.tux.org/lkml/
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- You stay in the theatre because you're afraid of having no ---
money? There's irony...
signature.asc
Description: Digital signature
Re: [PATCH] scatterlist.h: Change CONFIG_DEBUG_SG for ifdef statement in sg_set_bf
mpile, and test thoroughly) is *not* a waste of time. It prevents you wasting everyone else's time, and it ensures that at least you have some assurance that the code you've written works properly. Anything else is just lazy and sloppy, and (quite rightly), nobody wants code by lazy, sloppy programmers in the kernel. > Please stop telling me I can do this due to a few mistakes that you > and the other developers are fucking over doing. It's not "a few mistakes". You've made a cock-up in pretty much every single patch I've seen from you. These are sometimes logical errors like this one -- a few moments thought should have told you that the change wasn't actually fixing anything. More often, you're demonstrating *obviously* that you have absolutely no idea about what the code you've changed should be doing, or what the effect of the change you've made actually is. Many people have tried to tell you, with varying degrees of helpfulness, verbosity and rudeness, where you are going wrong, and what things you need to be doing to make yourself a better developer, and you have pretty much universally ignored them. The reason that you are being told that you should work on some userspace project is because the complexity of the code-base is typically lower, there's less effort involved in understanding the code, and the developers are sometimes less finicky about code quality (so you can make more mistakes without people getting cross about it). This would all make it easier for you to get practice on a large multi-developer project. Note that doing so would still mean that you have to compile and test all your changes before you submit them to the developers. You don't get out of doing that at all. In short, the "work" you are doing here on the kernel is appallingly substandard, and you are giving no indication that you are learning anything from the people trying to help you. This is why people are getting angry. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- You shouldn't anthropomorphise computers. They really --- don't like that. signature.asc Description: Digital signature
Re: [PATCH] scatterlist.h: Change CONFIG_DEBUG_SG for ifdef statement in sg_set_bf
things you need to be doing to make yourself a better developer, and you have pretty much universally ignored them. The reason that you are being told that you should work on some userspace project is because the complexity of the code-base is typically lower, there's less effort involved in understanding the code, and the developers are sometimes less finicky about code quality (so you can make more mistakes without people getting cross about it). This would all make it easier for you to get practice on a large multi-developer project. Note that doing so would still mean that you have to compile and test all your changes before you submit them to the developers. You don't get out of doing that at all. In short, the work you are doing here on the kernel is appallingly substandard, and you are giving no indication that you are learning anything from the people trying to help you. This is why people are getting angry. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- You shouldn't anthropomorphise computers. They really --- don't like that. signature.asc Description: Digital signature
Re: [PATCH] scatterlist.h: Change CONFIG_DEBUG_SG for ifdef statement in sg_set_bf
On Sun, Aug 03, 2014 at 01:30:44PM -0400, Nick Krause wrote:
On Sun, Aug 3, 2014 at 8:28 AM, Sergei Shtylyov
On 03-08-2014 6:56, Nicholas Krause wrote:
This changes the ifdef statement in sg_set_bg to !CONFIG_DEBUG_SG in
order
to avoid a bug with xhci dequence/enquence functions.
dequeue/enqueue?
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
include/linux/scatterlist.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index adae88f..62de7b3 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -111,7 +111,7 @@ static inline struct page *sg_page(struct scatterlist
*sg)
static inline void sg_set_buf(struct scatterlist *sg, const void *buf,
unsigned int buflen)
{
-#ifdef CONFIG_DEBUG_SG
+#ifdef !CONFIG_DEBUG_SG
Didn't you mean #ifndef instead? I guess you didn't even try to
build-test this.
BUG_ON(!virt_addr_valid(buf));
#endif
sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
WBR, Sergei
I am going to stay around and learn more but am going to check my
patches better as this is
my fault.
This is something like the fourth time you've said this, and you
still haven't managed to do it. :(
Compile the code. Every. Single. Time.
Test the code. Every. Single. Time.
Not optional, not negotiable.
Hugo.
Regards Nick
--
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 http://www.tux.org/lkml/
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- You stay in the theatre because you're afraid of having no ---
money? There's irony...
signature.asc
Description: Digital signature
Re: [PATCH] Add support to check for FALLOC_FL_COLLAPSE_RANGE and FALLOC_FL_ZERO_RANGE crap modes
On Thu, Jul 31, 2014 at 09:53:15PM -0400, Nick Krause wrote:
> On Thu, Jul 31, 2014 at 3:09 PM, Hugo Mills wrote:
> > On Thu, Jul 31, 2014 at 01:53:33PM -0400, Nicholas Krause wrote:
> >> This adds checks for the stated modes as if they are crap we will return
> >> error
> >> not supported.
> >
> >You've just enabled two options, but you haven't actually
> > implemented the code behind it. I would tell you *NOT* to do anything
> > else on this work until you can answer the question: What happens if
> > you apply this patch, create a large file called "foo.txt", and then a
> > userspace program executes the following code?
> >
> > int fd = open("foo.txt", O_RDWR);
> > fallocate(fd, FALLOCATE_FL_COLLAPSE_RANGE, 50, 50);
> >
> >Try it on a btrfs filesystem, both with and without your patch.
> > Also try it on an ext4 filesystem.
> >
> >Once you've done all of that, reply to this mail and tell me what
> > the problem is with this patch. You need to make two answers: what are
> > the technical problems with the patch? What errors have you made in
> > the development process?
> >
> >*Only* if you can answer those questions sensibly, should you write
> > any more patches, of any kind.
[snip]
> Calls are there in btrfs , therefore will either kernel panic or
> cause an oops.
That's a guess. I can tell it's a guess, because I've actually read
(some of) the rest of that function, so I've got a good idea of what I
think it will do -- and panic or oops is not the answer. Try again.
You can answer this question two ways: by test (see my suggestion
above), or by reading and understanding the code. Either will work in
this case, but doing neither is not an option for someone who wants to
change the function.
> Need to test this patch as this is very easy to catch bug.
So why didn't you? It's your patch, testing it is your job --
*before* it gets out into the outside world.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- But people have always eaten people, / what else is there to ---
eat? / If the Juju had meant us not to eat people / he
wouldn't have made us of meat.
signature.asc
Description: Digital signature
Re: [PATCH] Add support to check for FALLOC_FL_COLLAPSE_RANGE and FALLOC_FL_ZERO_RANGE crap modes
On Thu, Jul 31, 2014 at 09:53:15PM -0400, Nick Krause wrote: On Thu, Jul 31, 2014 at 3:09 PM, Hugo Mills h...@carfax.org.uk wrote: On Thu, Jul 31, 2014 at 01:53:33PM -0400, Nicholas Krause wrote: This adds checks for the stated modes as if they are crap we will return error not supported. You've just enabled two options, but you haven't actually implemented the code behind it. I would tell you *NOT* to do anything else on this work until you can answer the question: What happens if you apply this patch, create a large file called foo.txt, and then a userspace program executes the following code? int fd = open(foo.txt, O_RDWR); fallocate(fd, FALLOCATE_FL_COLLAPSE_RANGE, 50, 50); Try it on a btrfs filesystem, both with and without your patch. Also try it on an ext4 filesystem. Once you've done all of that, reply to this mail and tell me what the problem is with this patch. You need to make two answers: what are the technical problems with the patch? What errors have you made in the development process? *Only* if you can answer those questions sensibly, should you write any more patches, of any kind. [snip] Calls are there in btrfs , therefore will either kernel panic or cause an oops. That's a guess. I can tell it's a guess, because I've actually read (some of) the rest of that function, so I've got a good idea of what I think it will do -- and panic or oops is not the answer. Try again. You can answer this question two ways: by test (see my suggestion above), or by reading and understanding the code. Either will work in this case, but doing neither is not an option for someone who wants to change the function. Need to test this patch as this is very easy to catch bug. So why didn't you? It's your patch, testing it is your job -- *before* it gets out into the outside world. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- But people have always eaten people, / what else is there to --- eat? / If the Juju had meant us not to eat people / he wouldn't have made us of meat. signature.asc Description: Digital signature
Re: [PATCH] Add support to check for FALLOC_FL_COLLAPSE_RANGE and FALLOC_FL_ZERO_RANGE crap modes
On Thu, Jul 31, 2014 at 01:53:33PM -0400, Nicholas Krause wrote:
> This adds checks for the stated modes as if they are crap we will return error
> not supported.
You've just enabled two options, but you haven't actually
implemented the code behind it. I would tell you *NOT* to do anything
else on this work until you can answer the question: What happens if
you apply this patch, create a large file called "foo.txt", and then a
userspace program executes the following code?
int fd = open("foo.txt", O_RDWR);
fallocate(fd, FALLOCATE_FL_COLLAPSE_RANGE, 50, 50);
Try it on a btrfs filesystem, both with and without your patch.
Also try it on an ext4 filesystem.
Once you've done all of that, reply to this mail and tell me what
the problem is with this patch. You need to make two answers: what are
the technical problems with the patch? What errors have you made in
the development process?
*Only* if you can answer those questions sensibly, should you write
any more patches, of any kind.
Hugo.
> Signed-off-by: Nicholas Krause
> ---
> fs/btrfs/file.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
> index 1f2b99c..599495a 100644
> --- a/fs/btrfs/file.c
> +++ b/fs/btrfs/file.c
> @@ -2490,7 +2490,8 @@ static long btrfs_fallocate(struct file *file, int mode,
> alloc_end = round_up(offset + len, blocksize);
>
> /* Make sure we aren't being give some crap mode */
> - if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
> + if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE|
> + FALLOC_FL_COLLAPSE_RANGE | FALLOC_FL_ZERO_RANGE))
> return -EOPNOTSUPP;
>
> if (mode & FALLOC_FL_PUNCH_HOLE)
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- The glass is neither half-full nor half-empty; it is twice as ---
large as it needs to be.
signature.asc
Description: Digital signature
Re: [PATCH] Remove certain calls for releasing page cache
On Wed, Jul 30, 2014 at 10:05:16PM -0400, Nick Krause wrote: > On Wed, Jul 30, 2014 at 7:30 PM, Dave Airlie wrote: > >> This patch removes the lines for releasing the page cache in certain > >> files as this may aid in perfomance with writes in the compression > >> rountines of btrfs. Please note that this patch has not been tested > >> on my own hardware due to no compression based btrfs volumes of my > >> own. > >> > > > > For all that is sacred, STOP. [snip] > > But if you want to work on the kernel, this isn't the way to do it, and > > nobody will ever take a patch from you seriously if you continue in this > > fashion. > > > > Dave. > Dave , > Seems I need to have tested this code first. You've said this before, having made exactly the same error (not testing a patch). Yet you do it again. You seem to be ignoring all the advice you've been given -- or at least not learning from it, and not learning from your experiences. Could you please, for half an hour or so, stop thinking about the immediate goal of getting a patch into the kernel, and take a short while to think about your process of learning. Look at all the advice you've had (from me, from Ted, from others), actually understand it, and consider all the things you need to do which *aren't* hacking up a lump of C. Actually learn these things -- have them in your mind all the time. I would appreciate it if you could actually engage with someone (doesn't have to be me) about this -- why are you ignoring the advice? Is it because you don't understand it? Is it because you think you can cut corners? Is it because you're concetrating on the code so much that you're forgetting it? The main thing you're doing which is making people angry is not because you're submitting bad patches (although you are). It's because you're not listening to advice, and you're not apparently learning anything from the feedback you're given. Your behaviour is not changing over time, which makes you look like a waste of time to all those people trying to help you. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- That's not rain, that's a lake with slots in it --- signature.asc Description: Digital signature
Re: [PATCH] Remove certain calls for releasing page cache
On Wed, Jul 30, 2014 at 10:05:16PM -0400, Nick Krause wrote: On Wed, Jul 30, 2014 at 7:30 PM, Dave Airlie airl...@gmail.com wrote: This patch removes the lines for releasing the page cache in certain files as this may aid in perfomance with writes in the compression rountines of btrfs. Please note that this patch has not been tested on my own hardware due to no compression based btrfs volumes of my own. For all that is sacred, STOP. [snip] But if you want to work on the kernel, this isn't the way to do it, and nobody will ever take a patch from you seriously if you continue in this fashion. Dave. Dave , Seems I need to have tested this code first. You've said this before, having made exactly the same error (not testing a patch). Yet you do it again. You seem to be ignoring all the advice you've been given -- or at least not learning from it, and not learning from your experiences. Could you please, for half an hour or so, stop thinking about the immediate goal of getting a patch into the kernel, and take a short while to think about your process of learning. Look at all the advice you've had (from me, from Ted, from others), actually understand it, and consider all the things you need to do which *aren't* hacking up a lump of C. Actually learn these things -- have them in your mind all the time. I would appreciate it if you could actually engage with someone (doesn't have to be me) about this -- why are you ignoring the advice? Is it because you don't understand it? Is it because you think you can cut corners? Is it because you're concetrating on the code so much that you're forgetting it? The main thing you're doing which is making people angry is not because you're submitting bad patches (although you are). It's because you're not listening to advice, and you're not apparently learning anything from the feedback you're given. Your behaviour is not changing over time, which makes you look like a waste of time to all those people trying to help you. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- That's not rain, that's a lake with slots in it --- signature.asc Description: Digital signature
Re: [PATCH] Add support to check for FALLOC_FL_COLLAPSE_RANGE and FALLOC_FL_ZERO_RANGE crap modes
On Thu, Jul 31, 2014 at 01:53:33PM -0400, Nicholas Krause wrote: This adds checks for the stated modes as if they are crap we will return error not supported. You've just enabled two options, but you haven't actually implemented the code behind it. I would tell you *NOT* to do anything else on this work until you can answer the question: What happens if you apply this patch, create a large file called foo.txt, and then a userspace program executes the following code? int fd = open(foo.txt, O_RDWR); fallocate(fd, FALLOCATE_FL_COLLAPSE_RANGE, 50, 50); Try it on a btrfs filesystem, both with and without your patch. Also try it on an ext4 filesystem. Once you've done all of that, reply to this mail and tell me what the problem is with this patch. You need to make two answers: what are the technical problems with the patch? What errors have you made in the development process? *Only* if you can answer those questions sensibly, should you write any more patches, of any kind. Hugo. Signed-off-by: Nicholas Krause xerofo...@gmail.com --- fs/btrfs/file.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 1f2b99c..599495a 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -2490,7 +2490,8 @@ static long btrfs_fallocate(struct file *file, int mode, alloc_end = round_up(offset + len, blocksize); /* Make sure we aren't being give some crap mode */ - if (mode ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE)) + if (mode ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE| + FALLOC_FL_COLLAPSE_RANGE | FALLOC_FL_ZERO_RANGE)) return -EOPNOTSUPP; if (mode FALLOC_FL_PUNCH_HOLE) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- The glass is neither half-full nor half-empty; it is twice as --- large as it needs to be. signature.asc Description: Digital signature
Re: Work Queue for btrfs compression writes
On Tue, Jul 29, 2014 at 11:54:20PM -0400, Nick Krause wrote: > Hey Guys , > I am new to reading and writing kernel code.I got interested in > writing code for btrfs as it seems to > need more work then other file systems and this seems other then > drivers, a good use of time on my part. > I interested in helping improving the compression of btrfs by using a > set of threads using work queues like XFS > or reads and keeping the page cache after reading compressed blocks as > these seem to be a great way to improve > on compression performance mostly with large partitions of compressed > data. I am not asking you to write the code > for me but as I am new a little guidance and help would be greatly > appreciated as this seems like too much work for just a newbie. * Documentation/workqueue.txt (in general, grep in Documentation usually throws up something useful) * grep -r alloc_workqueue fs/ shows a lot of uses (including in btrfs), so it should be fairly easy to see how to create and manage a workqueue. I suspect that this may be a medium-sized project, rather than a small one. My gut feeling (based on limited experience) is that the fallocate extensions project would be considerably simpler. I also noticed from the public reply to the private mail (don't do this without getting permission from the other person) that you posted to LKML in this thread (don't switch mailing lists mid-thread) that you anticipated having problems testing with limited disks -- what you will find is that testing new kernel code is something that you don't do on your main development OS installation. Instead, you will need either a scratch machine that you can easily update, or one or more virtual machines. qemu/kvm is good for this, because it has a mode that bypasses the BIOS and bootloader emulation, and just directly runs a kernel from a file on the host machine. This is fast. You can pass large sparse files to the VM to act as scratch disks, plus keep another smaller file for the guest OS (and a copy of it so that you can throw one away and make another one quickly and easily). Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- You've read the project plan. Forget that. We're going to Do --- Stuff and Have Fun doing it. signature.asc Description: Digital signature
Re: Work Queue for btrfs compression writes
On Tue, Jul 29, 2014 at 11:54:20PM -0400, Nick Krause wrote: Hey Guys , I am new to reading and writing kernel code.I got interested in writing code for btrfs as it seems to need more work then other file systems and this seems other then drivers, a good use of time on my part. I interested in helping improving the compression of btrfs by using a set of threads using work queues like XFS or reads and keeping the page cache after reading compressed blocks as these seem to be a great way to improve on compression performance mostly with large partitions of compressed data. I am not asking you to write the code for me but as I am new a little guidance and help would be greatly appreciated as this seems like too much work for just a newbie. * Documentation/workqueue.txt (in general, grep in Documentation usually throws up something useful) * grep -r alloc_workqueue fs/ shows a lot of uses (including in btrfs), so it should be fairly easy to see how to create and manage a workqueue. I suspect that this may be a medium-sized project, rather than a small one. My gut feeling (based on limited experience) is that the fallocate extensions project would be considerably simpler. I also noticed from the public reply to the private mail (don't do this without getting permission from the other person) that you posted to LKML in this thread (don't switch mailing lists mid-thread) that you anticipated having problems testing with limited disks -- what you will find is that testing new kernel code is something that you don't do on your main development OS installation. Instead, you will need either a scratch machine that you can easily update, or one or more virtual machines. qemu/kvm is good for this, because it has a mode that bypasses the BIOS and bootloader emulation, and just directly runs a kernel from a file on the host machine. This is fast. You can pass large sparse files to the VM to act as scratch disks, plus keep another smaller file for the guest OS (and a copy of it so that you can throw one away and make another one quickly and easily). Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- You've read the project plan. Forget that. We're going to Do --- Stuff and Have Fun doing it. signature.asc Description: Digital signature
Re: Help with Brtfs Bugs
On Mon, Jul 28, 2014 at 12:00:03AM -0400, Nick Krause wrote: > Hey Josef, > Seems there are a lot of brtfs bugs open on the kernel Bugzilla. I am > new to the brtfs > side of development so please let me known if you want help cleaning > up some of the > bugs here that are actually valid and still open. Make up your mind... this is the third unrelated idea you've had about working in the area of btrfs. You're bouncing around all over the place like a hyperactive puppy. Pick *one* thing, and just do it. Put in the effort to learn about the subsystem (read my earlier emails for a good approach here). Accept that there are no easy one-liners in the kernel. The path to writing your first kernel patch is *hard*. Don't give up at the first hint that each thing isn't going to be solved in 5 minutes. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- What part of "gestalt" don't you understand? --- signature.asc Description: Digital signature
Re: Multi Core Support for compression in compression.c
On Sun, Jul 27, 2014 at 11:21:53PM -0400, Nick Krause wrote: > On Sun, Jul 27, 2014 at 10:56 PM, Austin S Hemmelgarn > wrote: > > On 07/27/2014 04:47 PM, Nick Krause wrote: > >> This may be a bad idea , but compression in brtfs seems to be only > >> using one core to compress. > >> Depending on the CPU used and the amount of cores in the CPU we can > >> make this much faster > >> with multiple cores. This seems bad by my reading at least I would > >> recommend for writing compression > >> we write a function to use a certain amount of cores based on the load > >> of the system's CPU not using > >> more then 75% of the system's CPU resources as my system when idle has > >> never needed more > >> then one core of my i5 2500k to run when with interrupts for opening > >> eclipse are running. For reading > >> compression on good core seems fine to me as testing other compression > >> software for reads , it's > >> way less CPU intensive. > >> Cheers Nick > > We would probably get a bigger benefit from taking an approach like > > SquashFS has recently added, that is, allowing multi-threaded > > decompression fro reads, and decompressing directly into the pagecache. > > Such an approach would likely make zlib compression much more scalable > > on large systems. > > > > > > Austin, > That seems better then my idea as you seem to be more up to date on > brtfs devolopment. > If you and the other developers of brtfs are interested in adding this > as a feature please let > me known as I would like to help improve brtfs as the file system as > an idea is great just > seems like it needs a lot of work :). Yes, it probably does need a lot of work. This is (at least one reason) why it's not been done yet. If you want to work on doing this, then please do. However, don't expect anyone else to give you a detailed plan of what code to write. Don't expect anyone else to write the code for you. You will have to come up with your own ideas as to how to implement it, and actually do it yourself, including building it, and testing it. That's not to say that you are on your own, though. People will help -- provided that you aren't asking them to do all the work. You are not an empty vessel to be filled with the wisdom of the ancients. This means that *you* have to take action. You have to take yourself as far as you can in learning how things work. When you get stuck, work out what it is that you don't know, and then ask about that one thing. This makes it easier to answer, it shows that you're putting in effort on your side, and it means that you *actually learn things*. Questions like "what function should I be modifying?", or "how do you want me to do this?" show that you haven't put in even the smallest piece of effort, and will be ignored (f you're lucky). Questions like "I'm trying to implement a crumble filter, but in the mix_breadcrumbs function, how does it take account of the prestressed_yoghurt field?" show that you've read and understood at least some of the code, and have thought about what it's doing. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Alert status mauve ocelot: Slight chance of brimstone. Be --- prepared to make a nice cup of tea. signature.asc Description: Digital signature
Re: Multi Core Support for compression in compression.c
On Sun, Jul 27, 2014 at 11:21:53PM -0400, Nick Krause wrote: On Sun, Jul 27, 2014 at 10:56 PM, Austin S Hemmelgarn ahferro...@gmail.com wrote: On 07/27/2014 04:47 PM, Nick Krause wrote: This may be a bad idea , but compression in brtfs seems to be only using one core to compress. Depending on the CPU used and the amount of cores in the CPU we can make this much faster with multiple cores. This seems bad by my reading at least I would recommend for writing compression we write a function to use a certain amount of cores based on the load of the system's CPU not using more then 75% of the system's CPU resources as my system when idle has never needed more then one core of my i5 2500k to run when with interrupts for opening eclipse are running. For reading compression on good core seems fine to me as testing other compression software for reads , it's way less CPU intensive. Cheers Nick We would probably get a bigger benefit from taking an approach like SquashFS has recently added, that is, allowing multi-threaded decompression fro reads, and decompressing directly into the pagecache. Such an approach would likely make zlib compression much more scalable on large systems. Austin, That seems better then my idea as you seem to be more up to date on brtfs devolopment. If you and the other developers of brtfs are interested in adding this as a feature please let me known as I would like to help improve brtfs as the file system as an idea is great just seems like it needs a lot of work :). Yes, it probably does need a lot of work. This is (at least one reason) why it's not been done yet. If you want to work on doing this, then please do. However, don't expect anyone else to give you a detailed plan of what code to write. Don't expect anyone else to write the code for you. You will have to come up with your own ideas as to how to implement it, and actually do it yourself, including building it, and testing it. That's not to say that you are on your own, though. People will help -- provided that you aren't asking them to do all the work. You are not an empty vessel to be filled with the wisdom of the ancients. This means that *you* have to take action. You have to take yourself as far as you can in learning how things work. When you get stuck, work out what it is that you don't know, and then ask about that one thing. This makes it easier to answer, it shows that you're putting in effort on your side, and it means that you *actually learn things*. Questions like what function should I be modifying?, or how do you want me to do this? show that you haven't put in even the smallest piece of effort, and will be ignored (f you're lucky). Questions like I'm trying to implement a crumble filter, but in the mix_breadcrumbs function, how does it take account of the prestressed_yoghurt field? show that you've read and understood at least some of the code, and have thought about what it's doing. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Alert status mauve ocelot: Slight chance of brimstone. Be --- prepared to make a nice cup of tea. signature.asc Description: Digital signature
Re: Help with Brtfs Bugs
On Mon, Jul 28, 2014 at 12:00:03AM -0400, Nick Krause wrote: Hey Josef, Seems there are a lot of brtfs bugs open on the kernel Bugzilla. I am new to the brtfs side of development so please let me known if you want help cleaning up some of the bugs here that are actually valid and still open. Make up your mind... this is the third unrelated idea you've had about working in the area of btrfs. You're bouncing around all over the place like a hyperactive puppy. Pick *one* thing, and just do it. Put in the effort to learn about the subsystem (read my earlier emails for a good approach here). Accept that there are no easy one-liners in the kernel. The path to writing your first kernel patch is *hard*. Don't give up at the first hint that each thing isn't going to be solved in 5 minutes. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- What part of gestalt don't you understand? --- signature.asc Description: Digital signature
Re: btrfs hanging since 3.16-rc3 or so
cc linux-btrfs list On Tue, Jul 15, 2014 at 10:40:46PM +0900, Norbert Preining wrote: > Dear all > > (please keep Cc) > > Since 3.16-rc3 or so I regularly get btrfs hanging in some transations. > > Usually during apt-get upgrade or some other large file operations > (cowbuilder building of packages). > > The log files give me for loads of processes things like: > [ 6236.746546] INFO: task aptitude:22775 blocked for more than 120 seconds. > [ 6236.746547] Tainted: GW O 3.16.0-rc5 #27 > [ 6236.746548] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 6236.746549] aptitudeD 8800b21a3868 0 22775 22709 > 0x > [ 6236.746550] 88003644fd10 0082 81a15500 > 88003644ffd8 > [ 6236.746552] 8800b21a3430 00011c00 880147da9c30 > 880147da9c30 > [ 6236.746553] 88003644fd58 880034b3ed48 880034b3ed38 > 88003644fd20 > [ 6236.746555] Call Trace: > [ 6236.746557] [] schedule+0x64/0x66 > [ 6236.746560] [] btrfs_wait_logged_extents+0xa4/0xdc > [ 6236.746561] [] ? finish_wait+0x5d/0x5d > [ 6236.746564] [] btrfs_sync_log+0x5ef/0x8a2 > [ 6236.746567] [] btrfs_sync_file+0x21b/0x24d > [ 6236.746569] [] ? btrfs_sync_file+0x21b/0x24d > [ 6236.746571] [] vfs_fsync_range+0x1c/0x1e > [ 6236.746574] [] SyS_msync+0x15d/0x1ea > [ 6236.746575] [] system_call_fastpath+0x16/0x1b > > THis is aptitude, but I have all the other tasks accessing the disk > hanging, too. > > This time, issueing a Sysrq-s for emergency syncing did the laptop > out of the hang. > > Hardware: Sonly VAIO Pro 13 > Distribution: Debian/sid > self compiled kernel, config on request. > > Please let me know if there is anything else I can provide. > > Thanks a lot > > Norbert > > > PREINING, Norbert http://www.preining.info > JAIST, Japan TeX Live & Debian Developer > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 > -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Normaliser unix c'est comme pasteuriser le Camembert --- signature.asc Description: Digital signature
Re: btrfs hanging since 3.16-rc3 or so
cc linux-btrfs list On Tue, Jul 15, 2014 at 10:40:46PM +0900, Norbert Preining wrote: Dear all (please keep Cc) Since 3.16-rc3 or so I regularly get btrfs hanging in some transations. Usually during apt-get upgrade or some other large file operations (cowbuilder building of packages). The log files give me for loads of processes things like: [ 6236.746546] INFO: task aptitude:22775 blocked for more than 120 seconds. [ 6236.746547] Tainted: GW O 3.16.0-rc5 #27 [ 6236.746548] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 6236.746549] aptitudeD 8800b21a3868 0 22775 22709 0x [ 6236.746550] 88003644fd10 0082 81a15500 88003644ffd8 [ 6236.746552] 8800b21a3430 00011c00 880147da9c30 880147da9c30 [ 6236.746553] 88003644fd58 880034b3ed48 880034b3ed38 88003644fd20 [ 6236.746555] Call Trace: [ 6236.746557] [81585b4a] schedule+0x64/0x66 [ 6236.746560] [811bb22e] btrfs_wait_logged_extents+0xa4/0xdc [ 6236.746561] [810635c1] ? finish_wait+0x5d/0x5d [ 6236.746564] [811d9489] btrfs_sync_log+0x5ef/0x8a2 [ 6236.746567] [811b43cf] btrfs_sync_file+0x21b/0x24d [ 6236.746569] [811b43cf] ? btrfs_sync_file+0x21b/0x24d [ 6236.746571] [8110db8a] vfs_fsync_range+0x1c/0x1e [ 6236.746574] [810d1681] SyS_msync+0x15d/0x1ea [ 6236.746575] [81588712] system_call_fastpath+0x16/0x1b THis is aptitude, but I have all the other tasks accessing the disk hanging, too. This time, issueing a Sysrq-s for emergency syncing did the laptop out of the hang. Hardware: Sonly VAIO Pro 13 Distribution: Debian/sid self compiled kernel, config on request. Please let me know if there is anything else I can provide. Thanks a lot Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Normaliser unix c'est comme pasteuriser le Camembert --- signature.asc Description: Digital signature
Re: [PATCH v3] lib: add size unit t/p/e to memparse
On Fri, Jun 13, 2014 at 07:54:44AM +0200, Brendan Hide wrote: > On 12/06/14 23:15, Andrew Morton wrote: > >On Wed, 2 Apr 2014 16:54:37 +0800 Gui Hecheng > >wrote: > >>+ * %K (for kibibytes, or 1024 bytes), > >>+ * %M (for mebibytes, or 1048576 bytes), > >>+ * %G (for gibibytes, or 1073741824 bytes), > >>+ * %T (for tebibytes, or 1099511627776 bytes), > >>+ * %P (for pebibytes, or 1125899906842624 bytes), > >>+ * %E (for exbibytes, or 1152921504606846976 bytes). > >I'm afraid I find these names quite idiotic - we all know what the > >traditional terms mean so why go and muck with it. > > > >Also, kibibytes sounds like cat food. > Hi, Andrew > > While I agree it sounds like cat food, it seemed like a good opportunity to > fix a minor issue that is otherwise unlikely to be fixed for a very long > time. Should we feel uncomfortable with the patch, as is, because of > language/correctness friction? Pedantry included, the patch is correct. ;) Last night, I wrote a very grumpy reply to Andrew. I'm glad I didn't send it, because Brendan has managed to cover at least one of my points much more politely than I did. My other comment is that TB vs TiB is a 10% difference in the magnitude of the number, and so the accumulated error is now no longer small enough to be brushed under the carpet as we all did in days past. By Andrew's thinking, a 4 TB disk is 3.638 TB in size. I'd say a 4 TB disk is 3.638 TiB in size, and I can be precise (±1GB in the latter case) with both values. Hugo. PS. Let's just not talk about 1.44 "MB" floppy disks. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- 2 + 2 = 5, for sufficiently large values of 2. --- signature.asc Description: Digital signature
Re: [PATCH v3] lib: add size unit t/p/e to memparse
On Fri, Jun 13, 2014 at 07:54:44AM +0200, Brendan Hide wrote: On 12/06/14 23:15, Andrew Morton wrote: On Wed, 2 Apr 2014 16:54:37 +0800 Gui Hecheng guihc.f...@cn.fujitsu.com wrote: + * %K (for kibibytes, or 1024 bytes), + * %M (for mebibytes, or 1048576 bytes), + * %G (for gibibytes, or 1073741824 bytes), + * %T (for tebibytes, or 1099511627776 bytes), + * %P (for pebibytes, or 1125899906842624 bytes), + * %E (for exbibytes, or 1152921504606846976 bytes). I'm afraid I find these names quite idiotic - we all know what the traditional terms mean so why go and muck with it. Also, kibibytes sounds like cat food. Hi, Andrew While I agree it sounds like cat food, it seemed like a good opportunity to fix a minor issue that is otherwise unlikely to be fixed for a very long time. Should we feel uncomfortable with the patch, as is, because of language/correctness friction? Pedantry included, the patch is correct. ;) Last night, I wrote a very grumpy reply to Andrew. I'm glad I didn't send it, because Brendan has managed to cover at least one of my points much more politely than I did. My other comment is that TB vs TiB is a 10% difference in the magnitude of the number, and so the accumulated error is now no longer small enough to be brushed under the carpet as we all did in days past. By Andrew's thinking, a 4 TB disk is 3.638 TB in size. I'd say a 4 TB disk is 3.638 TiB in size, and I can be precise (±1GB in the latter case) with both values. Hugo. PS. Let's just not talk about 1.44 MB floppy disks. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- 2 + 2 = 5, for sufficiently large values of 2. --- signature.asc Description: Digital signature
Re: btrfs hung tasks
7/0x880 > [ 3120.576888] [] ? _raw_read_unlock+0x11/0x40 > [ 3120.576892] [] ? btrfs_set_lock_blocking_rw+0xd8/0x110 > [ 3120.576895] [] ? btrfs_search_slot+0x3ef/0x900 > [ 3120.576899] [] ? _raw_spin_lock_irqsave+0x18/0x50 > [ 3120.576902] [] ? _raw_spin_unlock_irqrestore+0x13/0x40 > [ 3120.576905] [] schedule+0x24/0x70 > [ 3120.576908] [] wait_current_trans.isra.34+0xb7/0x120 > [ 3120.576911] [] ? start_transaction+0x11c/0x4b0 > [ 3120.576915] [] ? abort_exclusive_wait+0xb0/0xb0 > [ 3120.576918] [] start_transaction+0x2e6/0x4b0 > [ 3120.576922] [] btrfs_start_transaction+0x16/0x20 > [ 3120.576925] [] btrfs_create+0x42/0x210 > [ 3120.576928] [] ? btrfs_permission+0x37/0x70 > [ 3120.576931] [] vfs_create+0x8e/0xf0 > [ 3120.576934] [] do_last+0x8e6/0xd20 > [ 3120.576937] [] ? inode_permission+0x13/0x50 > [ 3120.576941] [] path_openat+0xbd/0x6b0 > [ 3120.576944] [] do_filp_open+0x3e/0xa0 > [ 3120.576947] [] ? _raw_spin_unlock+0x11/0x40 > [ 3120.576951] [] ? __alloc_fd+0xcb/0x120 > [ 3120.576954] [] do_sys_open+0x13c/0x230 > [ 3120.576957] [] SyS_open+0x1d/0x20 > [ 3120.576960] [] system_call_fastpath+0x16/ > -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Jazz is the sort of music where no-one plays anything the --- same way once. signature.asc Description: Digital signature
Re: btrfs hung tasks
] schedule_preempt_disabled+0x13/0x20 [ 3120.576826] [8155f0ec] __mutex_lock_slowpath+0x12c/0x210 [ 3120.576829] [8155e23d] mutex_lock+0x1d/0x40 [ 3120.576832] [8113d6e8] do_last+0x268/0xd20 [ 3120.576835] [8113a773] ? inode_permission+0x13/0x50 [ 3120.576838] [8113accd] ? link_path_walk+0x23d/0x8e0 [ 3120.576841] [8113e25d] path_openat+0xbd/0x6b0 [ 3120.576845] [8113eb8e] do_filp_open+0x3e/0xa0 [ 3120.576848] [81561be1] ? _raw_spin_unlock+0x11/0x40 [ 3120.576852] [8114b31b] ? __alloc_fd+0xcb/0x120 [ 3120.576855] [8112e6ac] do_sys_open+0x13c/0x230 [ 3120.576859] [8112e7bd] SyS_open+0x1d/0x20 [ 3120.576861] [81567b92] system_call_fastpath+0x16/0x1b [ 3120.576864] INFO: task mythpreviewgen:12054 blocked for more than 120 seconds. [ 3120.576866] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 3120.576867] mythpreviewgen D 8801a86c06e0 0 12054 12053 0x0004 [ 3120.576870] 880121141b28 0086 880121141aa8 880121141fd8 [ 3120.576874] 880121141fd8 4000 8801a6cfade0 88000a795bc0 [ 3120.576877] 880121141b58 8125c7c7 880121141a68 81561ca1 [ 3120.576881] Call Trace: [ 3120.576885] [8125c7c7] ? reserve_metadata_bytes+0x177/0x880 [ 3120.576888] [81561ca1] ? _raw_read_unlock+0x11/0x40 [ 3120.576892] [812a6f88] ? btrfs_set_lock_blocking_rw+0xd8/0x110 [ 3120.576895] [81251d6f] ? btrfs_search_slot+0x3ef/0x900 [ 3120.576899] [81561e68] ? _raw_spin_lock_irqsave+0x18/0x50 [ 3120.576902] [81561c23] ? _raw_spin_unlock_irqrestore+0x13/0x40 [ 3120.576905] [81560664] schedule+0x24/0x70 [ 3120.576908] [81272017] wait_current_trans.isra.34+0xb7/0x120 [ 3120.576911] [8127388c] ? start_transaction+0x11c/0x4b0 [ 3120.576915] [81060350] ? abort_exclusive_wait+0xb0/0xb0 [ 3120.576918] [81273a56] start_transaction+0x2e6/0x4b0 [ 3120.576922] [81273f66] btrfs_start_transaction+0x16/0x20 [ 3120.576925] [81280d82] btrfs_create+0x42/0x210 [ 3120.576928] [81275f27] ? btrfs_permission+0x37/0x70 [ 3120.576931] [8113a83e] vfs_create+0x8e/0xf0 [ 3120.576934] [8113dd66] do_last+0x8e6/0xd20 [ 3120.576937] [8113a773] ? inode_permission+0x13/0x50 [ 3120.576941] [8113e25d] path_openat+0xbd/0x6b0 [ 3120.576944] [8113eb8e] do_filp_open+0x3e/0xa0 [ 3120.576947] [81561be1] ? _raw_spin_unlock+0x11/0x40 [ 3120.576951] [8114b31b] ? __alloc_fd+0xcb/0x120 [ 3120.576954] [8112e6ac] do_sys_open+0x13c/0x230 [ 3120.576957] [8112e7bd] SyS_open+0x1d/0x20 [ 3120.576960] [81567b92] system_call_fastpath+0x16/ -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Jazz is the sort of music where no-one plays anything the --- same way once. signature.asc Description: Digital signature
Re: [GIT PULL] Btrfs
On Fri, Sep 13, 2013 at 09:07:36AM -0400, Ric Wheeler wrote: > On 09/12/2013 11:36 AM, Chris Mason wrote: > >Mark Fasheh's offline dedup work is also here. In this case offline > >means the FS is mounted and active, but the dedup work is not done > >inline during file IO. This is a building block where utilities are > >able to ask the FS to dedup a series of extents. The kernel takes > >care of verifying the data involved really is the same. Today this > >involves reading both extents, but we'll continue to evolve the patches. > > Nice feature! > > Just a note, the "offline" label is really confusing. In other > storage products, they typically call this "out of band" since you > are online but not during the actual write in a synchronous way :) I knew there was a specific term for this, but couldn't remember what it was. I've now updated the btrfs website's description(s) of the feature to include "out-of-band" and "in-band". Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Once is happenstance; twice is coincidence; three times --- is enemy action. signature.asc Description: Digital signature
Re: [GIT PULL] Btrfs
On Fri, Sep 13, 2013 at 09:07:36AM -0400, Ric Wheeler wrote: On 09/12/2013 11:36 AM, Chris Mason wrote: Mark Fasheh's offline dedup work is also here. In this case offline means the FS is mounted and active, but the dedup work is not done inline during file IO. This is a building block where utilities are able to ask the FS to dedup a series of extents. The kernel takes care of verifying the data involved really is the same. Today this involves reading both extents, but we'll continue to evolve the patches. Nice feature! Just a note, the offline label is really confusing. In other storage products, they typically call this out of band since you are online but not during the actual write in a synchronous way :) I knew there was a specific term for this, but couldn't remember what it was. I've now updated the btrfs website's description(s) of the feature to include out-of-band and in-band. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Once is happenstance; twice is coincidence; three times --- is enemy action. signature.asc Description: Digital signature
Re: btrfs userspace question - where's the utility to dump/restore?
On Thu, Jan 17, 2013 at 03:05:35PM -0500, Valdis Kletnieks wrote: > So I'm looking at playing with btrfs, and I start looking at the > userspace pieces I'll need. What I can't find is an equivalent > of the ext[34] "dump/restore" package to dump data to an external > backup device. Is 'tar cf --acls --selinux --xattrs /external/fs.dump' > as good as it gets, or is something else recommended? tar doesn't handle reflinks(+), so the above won't quite give you a complete duplicate. In the btrfs tool, there's send/receive, which should(*) be sufficient to deal with reflinks. Hugo. (+) aka CoW copies, or snapshots (*) I regret to say that I've not had the opportunity to play with send/receive myself yet, so I can't advise on the details of making it work yet. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Prisoner unknown: Return to Zenda. --- signature.asc Description: Digital signature
Re: btrfs userspace question - where's the utility to dump/restore?
On Thu, Jan 17, 2013 at 03:05:35PM -0500, Valdis Kletnieks wrote: So I'm looking at playing with btrfs, and I start looking at the userspace pieces I'll need. What I can't find is an equivalent of the ext[34] dump/restore package to dump data to an external backup device. Is 'tar cf --acls --selinux --xattrs /external/fs.dump' as good as it gets, or is something else recommended? tar doesn't handle reflinks(+), so the above won't quite give you a complete duplicate. In the btrfs tool, there's send/receive, which should(*) be sufficient to deal with reflinks. Hugo. (+) aka CoW copies, or snapshots (*) I regret to say that I've not had the opportunity to play with send/receive myself yet, so I can't advise on the details of making it work yet. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Prisoner unknown: Return to Zenda. --- signature.asc Description: Digital signature
Re: Linux 3.7-rc3
On Tue, Oct 30, 2012 at 01:10:32AM +0100, Rafael J. Wysocki wrote: > On Sunday, October 28, 2012 12:59:49 PM Linus Torvalds wrote: > > It's been a week, time for -rc3! > > > > Nothing particularly stands out here. Lots of small fixes, exemplified > > by the series of memory leak fixes in usb serial drivers. Just a lot > > of random stuff.. > > > > Most of it is drivers (all over: drm, wireless, staging, usb, sound), > > but there's a few filesystem updates (nfs, btrfs, ext4), arch updates > > (arm, x86 and m68k) and just random stuff. Shortlog appended. > > Unfortunately, s2disk is broken with this one and previous -rc. In the > majority of cases it just hangs the machine during hibernation, although > sometimes it returns to user space reporting freezing problems, suspicions > RCU usage and similar stuff, pretty much without any useful debug information. > > I'm quite confident that v3.6 was OK (and -stable based on that too), so > it most likely is a recent regression. The in-kernel hibernation > (ie. "echo disk > /sys/power/state") works no problem. So does suspend to > RAM on my test boxes. > > So far I have been able to reproduce this 100% of the time on two machines > with Intel CPUs and graphics driven by i915. I _suspect_ that this may be > related to VT switching, because s2disk does some ugly things in that area > which are not done by the in-kernel code. Dunno. I've had this symptom on my laptop (Thinkpad Edge 13, Intel graphics & CPU; I can get details when I get back home in about 8 hours), but only with 3.7-rc2. It was definitely working in 3.6, and seems to be OK in 3.7-rc3, although I've only tried two cycles of that last night. When I did suspend to disk, I get a blank screen (but clearly with backlight still on), and a blinking text-mode cursor in the top left. I left it for half an hour once, and nothing changed, so I'm fairly sure it was properly hung. I've not seen it return to user space with errors at all -- just the hang. > Anyway, it looks like nothing short of bisection is going to help debug this, > but I'm afraid I won't have the time to bisect within the next two weeks, so > if > anyone can reproduce this issue and will be able to bisect it, please help > (openSUSE/Tumbleweed users anyone?). I can try to bisect the 3.6 -> 3.7-rc2 failure, if that helps? But as I said, I've got it working on -rc3, so I may not have the same problem. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- UNIX: Spanish manufacturer of fire extinguishers. --- signature.asc Description: Digital signature
Re: Linux 3.7-rc3
On Tue, Oct 30, 2012 at 01:10:32AM +0100, Rafael J. Wysocki wrote: On Sunday, October 28, 2012 12:59:49 PM Linus Torvalds wrote: It's been a week, time for -rc3! Nothing particularly stands out here. Lots of small fixes, exemplified by the series of memory leak fixes in usb serial drivers. Just a lot of random stuff.. Most of it is drivers (all over: drm, wireless, staging, usb, sound), but there's a few filesystem updates (nfs, btrfs, ext4), arch updates (arm, x86 and m68k) and just random stuff. Shortlog appended. Unfortunately, s2disk is broken with this one and previous -rc. In the majority of cases it just hangs the machine during hibernation, although sometimes it returns to user space reporting freezing problems, suspicions RCU usage and similar stuff, pretty much without any useful debug information. I'm quite confident that v3.6 was OK (and -stable based on that too), so it most likely is a recent regression. The in-kernel hibernation (ie. echo disk /sys/power/state) works no problem. So does suspend to RAM on my test boxes. So far I have been able to reproduce this 100% of the time on two machines with Intel CPUs and graphics driven by i915. I _suspect_ that this may be related to VT switching, because s2disk does some ugly things in that area which are not done by the in-kernel code. Dunno. I've had this symptom on my laptop (Thinkpad Edge 13, Intel graphics CPU; I can get details when I get back home in about 8 hours), but only with 3.7-rc2. It was definitely working in 3.6, and seems to be OK in 3.7-rc3, although I've only tried two cycles of that last night. When I did suspend to disk, I get a blank screen (but clearly with backlight still on), and a blinking text-mode cursor in the top left. I left it for half an hour once, and nothing changed, so I'm fairly sure it was properly hung. I've not seen it return to user space with errors at all -- just the hang. Anyway, it looks like nothing short of bisection is going to help debug this, but I'm afraid I won't have the time to bisect within the next two weeks, so if anyone can reproduce this issue and will be able to bisect it, please help (openSUSE/Tumbleweed users anyone?). I can try to bisect the 3.6 - 3.7-rc2 failure, if that helps? But as I said, I've got it working on -rc3, so I may not have the same problem. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- UNIX: Spanish manufacturer of fire extinguishers. --- signature.asc Description: Digital signature
Re: i915 problems with suspend to disk
On Thu, Oct 04, 2012 at 09:31:39PM +0200, Daniel Vetter wrote: > On Thu, Oct 04, 2012 at 08:20:17PM +0100, Hugo Mills wrote: > >On 3.6, I've got a problem with my video driver after resuming from > > suspend-to-disk: the lower part of the display flickers, rapidly but > > irregularly (think of a neon sign in a bad film noir), flicking > > between the correct display and... something else, it's hard to see > > what. > > > >Shutting the lid of the machine (to trigger a suspend-to-ram) and > > waking it up again fixes the flicker. > > > >In syslogs, I have nothing obvious on suspend, and this warning on > > resume: [snip] > >Hardware is a Lenovo Thinkpad Edge13, lspci says: > > > > 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series > > Chipset Integrated Graphics Controller (rev 07) > > > > aka > > > > 00:02.0 0300: 8086:2a42 (rev 07) > > > >Let me know if you need more information. I can probably manage a > > bisect if necessary -- it's easily repeatable as a bug. > > Before you do a bisect, can you try the drm-intel-fixes branch from > http://cgit.freedesktop.org/~danvet/drm-intel or a bit more risky, latest > upstream git? That contains a completely rewritten modeset code, which > might fix this already. To fix the breakage on 3.6 I guess we need a > bisect - at least I don't have any idea off-hand what could have gone > wrong here. Thank you for the quick response. The drm-intel-fixes branch seems to have done the trick. No more flickering. I think we can call this one fixed. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- I always felt that as a C programmer, I --- was becoming typecast. signature.asc Description: Digital signature
i915 problems with suspend to disk
Hi, On 3.6, I've got a problem with my video driver after resuming from suspend-to-disk: the lower part of the display flickers, rapidly but irregularly (think of a neon sign in a bad film noir), flicking between the correct display and... something else, it's hard to see what. Shutting the lid of the machine (to trigger a suspend-to-ram) and waking it up again fixes the flicker. In syslogs, I have nothing obvious on suspend, and this warning on resume: Oct 4 19:53:04 ruth kernel: [ 2892.184086] [ cut here ] Oct 4 19:53:04 ruth kernel: [ 2892.184114] WARNING: at drivers/gpu/drm/i915/intel_display.c:1225 intel_crtc_disable+0x52/0x86 [i915]() Oct 4 19:53:04 ruth kernel: [ 2892.184115] Hardware name: 0196CTO Oct 4 19:53:04 ruth kernel: [ 2892.184117] pipe B assertion failure (expected off, current on) Oct 4 19:53:04 ruth kernel: [ 2892.184188] Modules linked in: cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative rfcomm bnep binfmt_misc uinput nfsd auth_rpcgss nfs_acl nfs lockd fscache sunrpc ext4 jbd2 mbcache loop arc4 iwldvm mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant coretemp i915 snd_hda_intel snd_hda_codec drm_kms_helper iwlwifi snd_hwdep snd_pcm snd_page_alloc joydev snd_seq snd_seq_device snd_timer kvm_intel drm i2c_algo_bit thinkpad_acpi acpi_cpufreq nvram btusb bluetooth kvm crc16 cfg80211 microcode psmouse evdev i2c_i801 video rfkill wmi mperf i2c_core snd battery ac processor soundcore button btrfs crc32c libcrc32c zlib_deflate sha256_generic ablk_helper cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod sd_mod crc_t10dif ums_realtek usb_storage uas thermal thermal_sys ahci libahci libata uhci_hcd scsi_mod ehci_hcd r8169 mii usbcore usb_common Oct 4 19:53:04 ruth kernel: [ 2892.184198] Pid: 4117, comm: kworker/u:3 Not tainted 3.6.0 #14 Oct 4 19:53:04 ruth kernel: [ 2892.184199] Call Trace: Oct 4 19:53:04 ruth kernel: [ 2892.184207] [] ? warn_slowpath_common+0x78/0x8c Oct 4 19:53:04 ruth kernel: [ 2892.184213] [] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184216] [] ? warn_slowpath_fmt+0x45/0x4a Oct 4 19:53:04 ruth kernel: [ 2892.184221] [] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184238] [] ? intel_crtc_disable+0x52/0x86 [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184245] [] ? drm_helper_disable_unused_functions+0xd0/0xfb [drm_kms_helper] Oct 4 19:53:04 ruth kernel: [ 2892.184250] [] ? drm_helper_resume_force_mode+0xf1/0xff [drm_kms_helper] Oct 4 19:53:04 ruth kernel: [ 2892.184254] [] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184264] [] ? i915_drm_thaw+0xd4/0x10b [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184274] [] ? i915_resume+0x3b/0x50 [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184279] [] ? pci_legacy_resume+0x39/0x39 Oct 4 19:53:04 ruth kernel: [ 2892.184284] [] ? dpm_run_callback.isra.5+0x26/0x54 Oct 4 19:53:04 ruth kernel: [ 2892.184289] [] ? device_resume+0xd0/0x110 Oct 4 19:53:04 ruth kernel: [ 2892.184292] [] ? async_resume+0x14/0x38 Oct 4 19:53:04 ruth kernel: [ 2892.184296] [] ? async_run_entry_fn+0x9d/0x175 Oct 4 19:53:04 ruth kernel: [ 2892.184300] [] ? process_one_work+0x184/0x2a3 Oct 4 19:53:04 ruth kernel: [ 2892.184304] [] ? worker_thread+0x1fe/0x29f Oct 4 19:53:04 ruth kernel: [ 2892.184307] [] ? manage_workers+0x223/0x223 Oct 4 19:53:04 ruth kernel: [ 2892.184310] [] ? manage_workers+0x223/0x223 Oct 4 19:53:04 ruth kernel: [ 2892.184315] [] ? kthread+0x67/0x6f Oct 4 19:53:04 ruth kernel: [ 2892.184319] [] ? kernel_thread_helper+0x4/0x10 Oct 4 19:53:04 ruth kernel: [ 2892.184324] [] ? kthread_freezable_should_stop+0x3c/0x3c Oct 4 19:53:04 ruth kernel: [ 2892.184327] [] ? gs_change+0xb/0xb Oct 4 19:53:04 ruth kernel: [ 2892.184328] ---[ end trace 4e63ed9ed8ebc493 ]--- Hardware is a Lenovo Thinkpad Edge13, lspci says: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) aka 00:02.0 0300: 8086:2a42 (rev 07) Let me know if you need more information. I can probably manage a bisect if necessary -- it's easily repeatable as a bug. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Ceci n'est pas une pipe: | --- signature.asc Description: Digital signature
i915 problems with suspend to disk
Hi, On 3.6, I've got a problem with my video driver after resuming from suspend-to-disk: the lower part of the display flickers, rapidly but irregularly (think of a neon sign in a bad film noir), flicking between the correct display and... something else, it's hard to see what. Shutting the lid of the machine (to trigger a suspend-to-ram) and waking it up again fixes the flicker. In syslogs, I have nothing obvious on suspend, and this warning on resume: Oct 4 19:53:04 ruth kernel: [ 2892.184086] [ cut here ] Oct 4 19:53:04 ruth kernel: [ 2892.184114] WARNING: at drivers/gpu/drm/i915/intel_display.c:1225 intel_crtc_disable+0x52/0x86 [i915]() Oct 4 19:53:04 ruth kernel: [ 2892.184115] Hardware name: 0196CTO Oct 4 19:53:04 ruth kernel: [ 2892.184117] pipe B assertion failure (expected off, current on) Oct 4 19:53:04 ruth kernel: [ 2892.184188] Modules linked in: cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative rfcomm bnep binfmt_misc uinput nfsd auth_rpcgss nfs_acl nfs lockd fscache sunrpc ext4 jbd2 mbcache loop arc4 iwldvm mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant coretemp i915 snd_hda_intel snd_hda_codec drm_kms_helper iwlwifi snd_hwdep snd_pcm snd_page_alloc joydev snd_seq snd_seq_device snd_timer kvm_intel drm i2c_algo_bit thinkpad_acpi acpi_cpufreq nvram btusb bluetooth kvm crc16 cfg80211 microcode psmouse evdev i2c_i801 video rfkill wmi mperf i2c_core snd battery ac processor soundcore button btrfs crc32c libcrc32c zlib_deflate sha256_generic ablk_helper cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod sd_mod crc_t10dif ums_realtek usb_storage uas thermal thermal_sys ahci libahci libata uhci_hcd scsi_mod ehci_hcd r8169 mii usbcore usb_common Oct 4 19:53:04 ruth kernel: [ 2892.184198] Pid: 4117, comm: kworker/u:3 Not tainted 3.6.0 #14 Oct 4 19:53:04 ruth kernel: [ 2892.184199] Call Trace: Oct 4 19:53:04 ruth kernel: [ 2892.184207] [8102bdc5] ? warn_slowpath_common+0x78/0x8c Oct 4 19:53:04 ruth kernel: [ 2892.184213] [8104afd3] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184216] [8102be71] ? warn_slowpath_fmt+0x45/0x4a Oct 4 19:53:04 ruth kernel: [ 2892.184221] [8104afd3] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184238] [a03fdae0] ? intel_crtc_disable+0x52/0x86 [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184245] [a0273e47] ? drm_helper_disable_unused_functions+0xd0/0xfb [drm_kms_helper] Oct 4 19:53:04 ruth kernel: [ 2892.184250] [a027461e] ? drm_helper_resume_force_mode+0xf1/0xff [drm_kms_helper] Oct 4 19:53:04 ruth kernel: [ 2892.184254] [8104afd3] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184264] [a03dc17f] ? i915_drm_thaw+0xd4/0x10b [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184274] [a03dc4fc] ? i915_resume+0x3b/0x50 [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184279] [81193f21] ? pci_legacy_resume+0x39/0x39 Oct 4 19:53:04 ruth kernel: [ 2892.184284] [812196f7] ? dpm_run_callback.isra.5+0x26/0x54 Oct 4 19:53:04 ruth kernel: [ 2892.184289] [81219fe1] ? device_resume+0xd0/0x110 Oct 4 19:53:04 ruth kernel: [ 2892.184292] [8121a035] ? async_resume+0x14/0x38 Oct 4 19:53:04 ruth kernel: [ 2892.184296] [8104b070] ? async_run_entry_fn+0x9d/0x175 Oct 4 19:53:04 ruth kernel: [ 2892.184300] [81041a1a] ? process_one_work+0x184/0x2a3 Oct 4 19:53:04 ruth kernel: [ 2892.184304] [810426f1] ? worker_thread+0x1fe/0x29f Oct 4 19:53:04 ruth kernel: [ 2892.184307] [810424f3] ? manage_workers+0x223/0x223 Oct 4 19:53:04 ruth kernel: [ 2892.184310] [810424f3] ? manage_workers+0x223/0x223 Oct 4 19:53:04 ruth kernel: [ 2892.184315] [81045adf] ? kthread+0x67/0x6f Oct 4 19:53:04 ruth kernel: [ 2892.184319] [812fe774] ? kernel_thread_helper+0x4/0x10 Oct 4 19:53:04 ruth kernel: [ 2892.184324] [81045a78] ? kthread_freezable_should_stop+0x3c/0x3c Oct 4 19:53:04 ruth kernel: [ 2892.184327] [812fe770] ? gs_change+0xb/0xb Oct 4 19:53:04 ruth kernel: [ 2892.184328] ---[ end trace 4e63ed9ed8ebc493 ]--- Hardware is a Lenovo Thinkpad Edge13, lspci says: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) aka 00:02.0 0300: 8086:2a42 (rev 07) Let me know if you need more information. I can probably manage a bisect if necessary -- it's easily repeatable as a bug. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Ceci n'est pas une pipe: | --- signature.asc Description: Digital signature
Re: i915 problems with suspend to disk
On Thu, Oct 04, 2012 at 09:31:39PM +0200, Daniel Vetter wrote: On Thu, Oct 04, 2012 at 08:20:17PM +0100, Hugo Mills wrote: On 3.6, I've got a problem with my video driver after resuming from suspend-to-disk: the lower part of the display flickers, rapidly but irregularly (think of a neon sign in a bad film noir), flicking between the correct display and... something else, it's hard to see what. Shutting the lid of the machine (to trigger a suspend-to-ram) and waking it up again fixes the flicker. In syslogs, I have nothing obvious on suspend, and this warning on resume: [snip] Hardware is a Lenovo Thinkpad Edge13, lspci says: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) aka 00:02.0 0300: 8086:2a42 (rev 07) Let me know if you need more information. I can probably manage a bisect if necessary -- it's easily repeatable as a bug. Before you do a bisect, can you try the drm-intel-fixes branch from http://cgit.freedesktop.org/~danvet/drm-intel or a bit more risky, latest upstream git? That contains a completely rewritten modeset code, which might fix this already. To fix the breakage on 3.6 I guess we need a bisect - at least I don't have any idea off-hand what could have gone wrong here. Thank you for the quick response. The drm-intel-fixes branch seems to have done the trick. No more flickering. I think we can call this one fixed. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- I always felt that as a C programmer, I --- was becoming typecast. signature.asc Description: Digital signature
Re: Spurious completions during NCQ
On Fri, Feb 15, 2008 at 10:00:00AM -0500, Calvin Walton wrote: > On Fri, 2008-02-15 at 13:46 +0000, Hugo Mills wrote: > > I'm getting these on my Dell Latitude D830: > > > > Feb 15 13:06:00 willow kernel: ata1.00: exception Emask 0x2 SAct 0x4 SErr > > 0x0 action 0x2 frozen > > Feb 15 13:06:00 willow kernel: ata1.00: spurious completions during NCQ > > issue=0x0 SAct=0x4 FIS=004040a1:0002 > > >In some cases, there are several cmd/res lines listed. It's > > happening about once an hour or so (not correlated with any other > > event that I can see). It doesn't seem to be affecting operation of > > the machine, but it's making me nervous. > > > >Can anyone set my mind at rest? (Or suggest a fix?) > > You didn't mention which SATA chipset your laptop has, but some quick > googling says that it's AHCI. Until 2.6.24, the AHCI driver has a > problem where it'll report superious NCQ completions due to a bug in the > driver logic. > > > uname -a reports: > > Linux willow 2.6.23.1-hrt3 #1 SMP Sun Nov 4 14:51:20 GMT 2007 x86_64 > > GNU/Linux > > The fix is simple, upgrade your kernel to 2.6.24 :) Excellent. Thank you for clearing this up for me. I'll head off and do the upgrade now. Hugo. -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- All mushrooms are edible, but some are only edible once. --- signature.asc Description: Digital signature
Spurious completions during NCQ
I'm getting these on my Dell Latitude D830:
Feb 15 13:06:00 willow kernel: ata1.00: exception Emask 0x2 SAct 0x4 SErr 0x0
action 0x2 frozen
Feb 15 13:06:00 willow kernel: ata1.00: spurious completions during NCQ
issue=0x0 SAct=0x4 FIS=004040a1:0002
Feb 15 13:06:00 willow kernel: ata1.00: cmd 61/10:10:26:fb:c4/00:00:02:00:00/40
tag 2 cdb 0x0 data 8192 out
Feb 15 13:06:00 willow kernel: res 40/00:10:26:fb:c4/00:00:02:00:00/40
Emask 0x2 (HSM violation)
Feb 15 13:06:00 willow kernel: ata1: soft resetting port
Feb 15 13:06:00 willow kernel: ata1: SATA link up 3.0 Gbps (SStatus 123
SControl 300)
Feb 15 13:06:00 willow kernel: ata1.00: configured for UDMA/133
Feb 15 13:06:00 willow kernel: ata1: EH complete
Feb 15 13:06:00 willow kernel: sd 0:0:0:0: [sda] 312581808 512-byte hardware
sectors (160042 MB)
Feb 15 13:06:00 willow kernel: sd 0:0:0:0: [sda] Write Protect is off
Feb 15 13:06:00 willow kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Feb 15 13:06:00 willow kernel: sd 0:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
In some cases, there are several cmd/res lines listed. It's
happening about once an hour or so (not correlated with any other
event that I can see). It doesn't seem to be affecting operation of
the machine, but it's making me nervous.
Can anyone set my mind at rest? (Or suggest a fix?)
uname -a reports:
Linux willow 2.6.23.1-hrt3 #1 SMP Sun Nov 4 14:51:20 GMT 2007 x86_64 GNU/Linux
It's a kernel.org kernel with the patch for tickless operation on
amd64.
hdparm -i reports:
/dev/sda:
Model=ST9160823AS , FwRev=3.ADC , SerialNo=
5NK0C448
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?8?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
* signifies the current active mode
Hugo.
--
=== Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk
===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- w.w.w. : England's batting scorecard ---
signature.asc
Description: Digital signature
Spurious completions during NCQ
I'm getting these on my Dell Latitude D830:
Feb 15 13:06:00 willow kernel: ata1.00: exception Emask 0x2 SAct 0x4 SErr 0x0
action 0x2 frozen
Feb 15 13:06:00 willow kernel: ata1.00: spurious completions during NCQ
issue=0x0 SAct=0x4 FIS=004040a1:0002
Feb 15 13:06:00 willow kernel: ata1.00: cmd 61/10:10:26:fb:c4/00:00:02:00:00/40
tag 2 cdb 0x0 data 8192 out
Feb 15 13:06:00 willow kernel: res 40/00:10:26:fb:c4/00:00:02:00:00/40
Emask 0x2 (HSM violation)
Feb 15 13:06:00 willow kernel: ata1: soft resetting port
Feb 15 13:06:00 willow kernel: ata1: SATA link up 3.0 Gbps (SStatus 123
SControl 300)
Feb 15 13:06:00 willow kernel: ata1.00: configured for UDMA/133
Feb 15 13:06:00 willow kernel: ata1: EH complete
Feb 15 13:06:00 willow kernel: sd 0:0:0:0: [sda] 312581808 512-byte hardware
sectors (160042 MB)
Feb 15 13:06:00 willow kernel: sd 0:0:0:0: [sda] Write Protect is off
Feb 15 13:06:00 willow kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Feb 15 13:06:00 willow kernel: sd 0:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
In some cases, there are several cmd/res lines listed. It's
happening about once an hour or so (not correlated with any other
event that I can see). It doesn't seem to be affecting operation of
the machine, but it's making me nervous.
Can anyone set my mind at rest? (Or suggest a fix?)
uname -a reports:
Linux willow 2.6.23.1-hrt3 #1 SMP Sun Nov 4 14:51:20 GMT 2007 x86_64 GNU/Linux
It's a kernel.org kernel with the patch for tickless operation on
amd64.
hdparm -i reports:
/dev/sda:
Model=ST9160823AS , FwRev=3.ADC , SerialNo=
5NK0C448
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs RotSpdTol.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?8?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
* signifies the current active mode
Hugo.
--
=== Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk
===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- w.w.w. : England's batting scorecard ---
signature.asc
Description: Digital signature
Re: Spurious completions during NCQ
On Fri, Feb 15, 2008 at 10:00:00AM -0500, Calvin Walton wrote: On Fri, 2008-02-15 at 13:46 +, Hugo Mills wrote: I'm getting these on my Dell Latitude D830: Feb 15 13:06:00 willow kernel: ata1.00: exception Emask 0x2 SAct 0x4 SErr 0x0 action 0x2 frozen Feb 15 13:06:00 willow kernel: ata1.00: spurious completions during NCQ issue=0x0 SAct=0x4 FIS=004040a1:0002 In some cases, there are several cmd/res lines listed. It's happening about once an hour or so (not correlated with any other event that I can see). It doesn't seem to be affecting operation of the machine, but it's making me nervous. Can anyone set my mind at rest? (Or suggest a fix?) You didn't mention which SATA chipset your laptop has, but some quick googling says that it's AHCI. Until 2.6.24, the AHCI driver has a problem where it'll report superious NCQ completions due to a bug in the driver logic. uname -a reports: Linux willow 2.6.23.1-hrt3 #1 SMP Sun Nov 4 14:51:20 GMT 2007 x86_64 GNU/Linux The fix is simple, upgrade your kernel to 2.6.24 :) Excellent. Thank you for clearing this up for me. I'll head off and do the upgrade now. Hugo. -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- All mushrooms are edible, but some are only edible once. --- signature.asc Description: Digital signature
Re: [Patch] Support UTF-8 scripts
On Sat, Aug 13, 2005 at 02:42:52PM -0400, Lee Revell wrote: > On Sat, 2005-08-13 at 09:35 -0700, Stephen Pollei wrote: > > Thats great for the perl6 people. > > http://dev.perl.org/perl6/doc/design/syn/S03.html says they are going > > to be using « and » as operators... > > Is Larry smoking crack? That's one of the worst ideas I've heard in a > long time. There's no easy way to enter those at the keyboard! I have "setxkbmap -symbols 'en_US(pc102)+gb'" in my ~/.xsession, and « and » are available as AltGr-z and AltGr-x respectively. Hugo. -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Anyone who claims their cryptographic protocol is secure is --- either a genius or a fool. Given the genius/fool ratio for our species, the odds aren't good. signature.asc Description: Digital signature
Re: [Patch] Support UTF-8 scripts
On Sat, Aug 13, 2005 at 02:42:52PM -0400, Lee Revell wrote: On Sat, 2005-08-13 at 09:35 -0700, Stephen Pollei wrote: Thats great for the perl6 people. http://dev.perl.org/perl6/doc/design/syn/S03.html says they are going to be using « and » as operators... Is Larry smoking crack? That's one of the worst ideas I've heard in a long time. There's no easy way to enter those at the keyboard! I have setxkbmap -symbols 'en_US(pc102)+gb' in my ~/.xsession, and « and » are available as AltGr-z and AltGr-x respectively. Hugo. -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Anyone who claims their cryptographic protocol is secure is --- either a genius or a fool. Given the genius/fool ratio for our species, the odds aren't good. signature.asc Description: Digital signature
Re: Logitech Quickcam Express USB Address Aquisition Issues
On Mon, Aug 08, 2005 at 11:38:01AM +0900, Chris White wrote: > > Sorry, I didn't even check the link. Try the driver from: > > > > http://www.saillard.org/linux/pwc/ > > > > Which seems to work better. > > Err, mine's a logitech camera, why is everyone recommending philips > drivers :P? Because many of the Logitech cameras are based on the Philips chipset. Hugo. -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- All hope abandon, Ye who press Enter here. --- signature.asc Description: Digital signature
Re: Logitech Quickcam Express USB Address Aquisition Issues
On Mon, Aug 08, 2005 at 11:38:01AM +0900, Chris White wrote: Sorry, I didn't even check the link. Try the driver from: http://www.saillard.org/linux/pwc/ Which seems to work better. Err, mine's a logitech camera, why is everyone recommending philips drivers :P? Because many of the Logitech cameras are based on the Philips chipset. Hugo. -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- All hope abandon, Ye who press Enter here. --- signature.asc Description: Digital signature
2.6.11 cpufreq: Device or resource busy
IFS_STATS is not set # CONFIG_CIFS_XATTR is not set # CONFIG_CIFS_EXPERIMENTAL is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf-8" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ASCII is not set # CONFIG_NLS_ISO8859_1 is not set CONFIG_NLS_ISO8859_2=m # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set CONFIG_NLS_ISO8859_5=m # CONFIG_NLS_ISO8859_6 is not set CONFIG_NLS_ISO8859_7=m # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_FS is not set # CONFIG_FRAME_POINTER is not set CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_KPROBES is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_4KSTACKS is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m # CONFIG_CRYPTO_WP512 is not set CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES_586=m # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_TEA is not set CONFIG_CRYPTO_ARC4=m # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_ANUBIS is not set CONFIG_CRYPTO_DEFLATE=m # CONFIG_CRYPTO_MICHAEL_MIC is not set CONFIG_CRYPTO_CRC32C=m # CONFIG_CRYPTO_TEST is not set # # Hardware crypto devices # # CONFIG_CRYPTO_DEV_PADLOCK is not set # # Library routines # CONFIG_CRC_CCITT=m CONFIG_CRC32=m CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Python is executable pseudocode; perl --- is executable line-noise. signature.asc Description: Digital signature
2.6.11 cpufreq: Device or resource busy
is not set # CONFIG_CIFS_EXPERIMENTAL is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT=utf-8 # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ASCII is not set # CONFIG_NLS_ISO8859_1 is not set CONFIG_NLS_ISO8859_2=m # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set CONFIG_NLS_ISO8859_5=m # CONFIG_NLS_ISO8859_6 is not set CONFIG_NLS_ISO8859_7=m # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_FS is not set # CONFIG_FRAME_POINTER is not set CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_KPROBES is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_4KSTACKS is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m # CONFIG_CRYPTO_WP512 is not set CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES_586=m # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_TEA is not set CONFIG_CRYPTO_ARC4=m # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_ANUBIS is not set CONFIG_CRYPTO_DEFLATE=m # CONFIG_CRYPTO_MICHAEL_MIC is not set CONFIG_CRYPTO_CRC32C=m # CONFIG_CRYPTO_TEST is not set # # Hardware crypto devices # # CONFIG_CRYPTO_DEV_PADLOCK is not set # # Library routines # CONFIG_CRC_CCITT=m CONFIG_CRC32=m CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Python is executable pseudocode; perl --- is executable line-noise. signature.asc Description: Digital signature
