Re: [PATCH 1/2] msi: Invert the sense of the MSI enables.
Greg KH <[EMAIL PROTECTED]> writes: > On Thu, May 24, 2007 at 10:19:09PM -0600, Eric W. Biederman wrote: >> >> Currently we blacklist known bad msi configurations which means we >> keep getting MSI enabled on chipsets that either do not support MSI, >> or MSI is implemented improperly. Since the normal IRQ routing >> mechanism seems to works even when MSI does not, this is a bad default >> and causes non-functioning systems for no good reason. >> >> So this patch inverts the sense of the MSI bus flag to only enable >> MSI on known good systems. I am seeding that list with the set of >> chipsets with an enabled hypertransport MSI mapping capability. Which >> is as close as I can come to an generic MSI enable. So for actually >> using MSI this patch is a regression, but for just having MSI enabled >> in the kernel by default things should just work with this patch >> applied. >> >> People can still enable MSI on a per bus level for testing by writing >> to sysfs so discovering chipsets that actually work (assuming we are >> using modular drivers) should be pretty straight forward. > > Originally I would have thought this would be a good idea, but now that > Vista is out, which supports MSI, I don't think we are going to need > this in the future. All new chipsets should support MSI fine and this > table will only grow in the future, while the blacklist should not need > to have many new entries added to it. > > So I don't think this is a good idea, sorry. For me seeing is believing. I don't see that yet. What I see is myself pointed at a growing pile of bug reports of chipsets where MSI does not work. What I see is a steadily growing black list that looks like it should include every non-Intel x86 pci-express chipset. Despite the fact the fact it requires skill to show a chipset does not support MSI properly, and to generate the patch, and that MSI I/O devices are still fairly rare. Meanwhile I have written in a day something that does the nearly the equivalent of our current black list. A white list looks much easier to maintain. Further if we want to invert the list for a given vendor that we trust I don't think it would be hard to write an inverse quirk that enables MSI on chipsets that are new enough for some version of new enough. In particular it probably makes sense to do that for Intel pci-express chipsets. In part I have a problem with the current black list because a number of the entries appear to be flat out hacks. When you add to this the fact that MSI can be implemented on simple pci devices and those pci devices can potentially be plugged into old machines. (Say someone buys a new pci cards as an upgrade). I don't see how we can successfully setup a black list of every historical chipset that supports pci. Further there are a number of outstanding bugs that are there simply because msi is currently enabled by default on chipsets that don't support it. So I see the current situation as a maintenance disaster. People are not stepping up to the plate fast enough to grow the black list to the set of chipsets and motherboards that don't implement MSI, don't implement MSI correctly, or only sometimes implement MSI correctly. So Greg if you want to volunteer to comb through all of the existing pci express chipsets and figure out what is needed to test to see if the are setup correctly and to black list them if they are not setup correctly, and to unconditionally black list them if we don't support MSI more power to you. Right now I want code that works, and this is the best path I can see to that. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] Add the device IDs f or AMD/ATI SB700
Hi Jeff,
Thanks for your kindly help, I will fix the email next time.
Do you mean all the device IDs for ATI SB700 are added to the corresponding
files?
because I split this patch and resent four patches according to your last
suggestion,
if this patch is applied, another patches are not necessary now.
Thanks
Henry
-Original Message-
From: Jeff Garzik [mailto:[EMAIL PROTECTED]
Sent: Friday, May 25, 2007 11:00 AM
To: Henry Su
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [patch] Add the device IDs for AMD/ATI SB700
Henry Su wrote:
> --- linux-2.6.21.1.orig/drivers/ata/pata_atiixp.c 2007-05-10
> 06:30:14.0 폍
> linux-2.6.21.1/drivers/ata/pata_atiixp.c 2007-05-10 07:17:07.0 폍
> @@ -283,6 ,7 @@ static const struct pci_device_id atiixp
> { PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP300_IDE), },
> { PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP400_IDE), },
> { PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP600_IDE), },
> { PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP700_IDE), },
Patch applied manually.
Your patches are all technically correct -- but you really need to fix
your email so that we can receive and apply your patches via scripts.
This is a basic step that every kernel contributor needs to take.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/5] inode reservation v0.1 (ext4 kernel patch)
On May 25 2007 09:30, WANG Cong wrote: >>> >>>Yes, I found all TABs gone when I received the mail. When I post next >>>version of the patch, I will test to send to me first :-) >>> >>>Thanks for your information. >> >>Blame Gmail. > >I am using gmail too. That's not gmail's fault, Then it is one of these: - gmail's default settings for web input sucks or - the web browser reformats it (not so much - pastebin.ca suffers from something similar, but *not the same*; in that it translates all tabs into spaces, but at least it keeps the width.) or - you are using your own client, and directly SMTPing gmail servers, in which case unwanted reformatting by broken MTAs can be bypassed. >I think your email client sucks. >So which email client are you using, coly? I recommend mutt to you. ;) X-Mailer:Evolution 2.6.0 Hm, this looks like another of these "Thunderbird" cases. (Means, Thunderbird users also get their patches wrapped and twangled unless they set some option that is not on by default.) Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] msi: Invert the sense of the MSI enables.
> Do we have a feel for how much performace we're losing on those > systems which _could_ do MSI, but which will end up defaulting > to not using it? At least on 10GB ethernet it is a significant difference; you usually cannot go anywhere near line speed without MSI I suspect it is visible on high performance / multiple GB NICs too. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2-mm1 NTFS & SLUB related fix
On Fri, 25 May 2007 05:22:50 + "young dave" <[EMAIL PROTECTED]> wrote: > Hi, > > > Is this ntfs_init_locked_inode? > > Yes, it is. > > > > Bytes b4 0xc2959e28: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a > > >Object 0xc2959e38: 24 00 51 00 00 00 6b a5 > > > Redzone 0xc2959e40: 00 00 cc cc > > > > First two bytes after the object overwritten. The allocation for this > > object should have been two bytes longer. > > > > > Last alloc: ntfs_init_locked_inode+0x9e/0x110 jiffies_ago=5140 cpu=0 > > > pid=1604 > > > > This is the function that allocated a too short object. > > > > Only the last one byte of the string is zeroed, but It malloced 2 > more byte appended the string because size of thentfschar type is 2 > bytes , is this the reason? But why? > Thing is, ntfs_inode.name[] is an array of le16's. But local variable `i' in there is a byte index, not an le16 index. We end up writing that 0x at twice the intended offset. So I think this was meant: --- a/fs/ntfs/inode.c~a +++ a/fs/ntfs/inode.c @@ -140,7 +140,7 @@ static int ntfs_init_locked_inode(struct if (!ni->name) return -ENOMEM; memcpy(ni->name, na->name, i); - ni->name[i] = 0; + ni->name[na->name_len] = 0; } return 0; } _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] msi: Invert the sense of the MSI enables.
On Thu, May 24, 2007 at 09:31:57PM -0700, Andrew Morton wrote: > On Thu, 24 May 2007 22:19:09 -0600 [EMAIL PROTECTED] (Eric W. Biederman) > wrote: > > > Currently we blacklist known bad msi configurations which means we > > keep getting MSI enabled on chipsets that either do not support MSI, > > or MSI is implemented improperly. Since the normal IRQ routing > > mechanism seems to works even when MSI does not, this is a bad default > > and causes non-functioning systems for no good reason. ... > Yup. > > Do we have a feel for how much performace we're losing on those > systems which _could_ do MSI, but which will end up defaulting > to not using it? Rick Jones (HP, aka Mr Netperf.org) just recently posted some data that happened to compare. I've clipped out thw two relevant lines below: http://lists.openfabrics.org/pipermail/general/2007-May/035709.html Bulk Transfer "Latency" UnidirBidir Card Mbit/s SDx SDr Mbit/s SDx SDr Tran/s SDx SDr --- Myri10G IP 9k 9320 0.862 0.949 10950 1.00 0.86 19260 19.67 16.18 * Myri10G IP 9k msi 9320 0.449 0.672 10840 0.63 0.62 19430 11.68 11.56 original posting explains the fields. SDx (Service Demand on Transmit) is 2x more with MSI disabled. SDr (Service Demand on RX) is ~50% higher with MSI disabled. Ditto for latency metrics. ISTR to remember seeing ~5-10% difference on tg3 NICs and ~20% with PCI-X infiniband (all on HP ZX1 chip, bottleneck was PCI-X bus). When I posted a tg3 patch to linux-net (which got rejected because of tg3 HW bugs), I did NOT include any performance numbers like I thought I did. :( hth, grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] msi: Add support for the Intel chipsets that support MSI.
On Friday 25 May 2007 06:26:50 Eric W. Biederman wrote: > > This patch is the result of a quick survey of the Intel chipset > documents. I took a quick look in the document to see if the chipset > supported MSI and if so I looked through to find the vendor and device > id of device 0 function 0 of the chipset and added a quirk for that > device id if I it was not a duplicate. It would be better to look for any PCI bridge. Sometimes there are different PCI bridges around (e.g. external PCI-X bridges on HT systems) which might need own quirks Also in the x86 world Microsoft defined a FADT ACPI flag that MSI doesn't work for Vista. It might make sense to do if (dmi year >= 2007 && FADT.msi_disable not set) assume it works > This patch should be safe. The anecdotal evidence is that when dealing > with MSI the Intel chipsets just work. If we find some buggy ones > changing the list won't be hard. The FADT bit should be probably checked anyways. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
Casey Schaufler <[EMAIL PROTECTED]> writes: > On Fedora zcat, gzip and gunzip are all links to the same file. > I can imagine (although it is a bit of a stretch) allowing a set > of users access to gunzip but not gzip (or the other way around). > There are probably more sophisticated programs that have different > behavior based on the name they're invoked by that would provide > a more compelling arguement, assuming of course that you buy into > the behavior-based-on-name scheme. What I think I'm suggesting is > that AppArmor might be useful in addressing the fact that a file > with multiple hard links is necessarily constrained to have the > same access control on each of those names. That assumes one > believes that such behavior is flawwed, and I'm not going to try > to argue that. The question was about an example, and there is one. This doesn't work. The behavior depends on argv[0], which is not necessarily the same as the name of the file. -- Jeremy Maitin-Shepard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] msi: Invert the sense of the MSI enables.
Andrew Morton <[EMAIL PROTECTED]> writes: > On Thu, 24 May 2007 22:19:09 -0600 [EMAIL PROTECTED] (Eric W. Biederman) > wrote: > >> Currently we blacklist known bad msi configurations which means we >> keep getting MSI enabled on chipsets that either do not support MSI, >> or MSI is implemented improperly. Since the normal IRQ routing >> mechanism seems to works even when MSI does not, this is a bad default >> and causes non-functioning systems for no good reason. >> >> So this patch inverts the sense of the MSI bus flag to only enable >> MSI on known good systems. I am seeding that list with the set of >> chipsets with an enabled hypertransport MSI mapping capability. Which >> is as close as I can come to an generic MSI enable. So for actually >> using MSI this patch is a regression, but for just having MSI enabled >> in the kernel by default things should just work with this patch >> applied. >> >> People can still enable MSI on a per bus level for testing by writing >> to sysfs so discovering chipsets that actually work (assuming we are >> using modular drivers) should be pretty straight forward. > > Yup. > > Do we have a feel for how much performace we're losing on those > systems which _could_ do MSI, but which will end up defaulting > to not using it? I don't have any good numbers, although it is enough that you can measure the difference. I think Roland Drier and the other IB guys have actually made the measurements. For low-end hardware I expect the performance difference is currently in the noise. However because MSI irqs are not shared a lot of things are simplified. In particular it means that you should be able to have an irq fastpath that does not read the hardware at all, and hardware register reads can be comparatively very slow. Further because all MSI irq are not shared and edge triggered we don't have a danger of screaming irqs or drivers not handling a shared irq properly. The big performance win is most likely to be for fast I/O devices where the multiple IRQs per card will allow the irqs for different flows of data to be directed to different cpus. So for the short term I don't think there is much downside in having MSI disabled. For the long term I think MSI will be quite useful. Further my gut feel is that my two patches together will enable MSI on most of the x86 chipsets where it currently works. Because most chipsets are either from Intel or are hypertransport based. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2-mm1 NTFS & SLUB related fix
Hi, Is this ntfs_init_locked_inode? Yes, it is. > Bytes b4 0xc2959e28: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a >Object 0xc2959e38: 24 00 51 00 00 00 6b a5 > Redzone 0xc2959e40: 00 00 cc cc First two bytes after the object overwritten. The allocation for this object should have been two bytes longer. > Last alloc: ntfs_init_locked_inode+0x9e/0x110 jiffies_ago=5140 cpu=0 pid=1604 This is the function that allocated a too short object. Only the last one byte of the string is zeroed, but It malloced 2 more byte appended the string because size of thentfschar type is 2 bytes , is this the reason? But why? Regards dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] msi: Invert the sense of the MSI enables.
On Thu, May 24, 2007 at 10:19:09PM -0600, Eric W. Biederman wrote: > > Currently we blacklist known bad msi configurations which means we > keep getting MSI enabled on chipsets that either do not support MSI, > or MSI is implemented improperly. Since the normal IRQ routing > mechanism seems to works even when MSI does not, this is a bad default > and causes non-functioning systems for no good reason. > > So this patch inverts the sense of the MSI bus flag to only enable > MSI on known good systems. I am seeding that list with the set of > chipsets with an enabled hypertransport MSI mapping capability. Which > is as close as I can come to an generic MSI enable. So for actually > using MSI this patch is a regression, but for just having MSI enabled > in the kernel by default things should just work with this patch > applied. > > People can still enable MSI on a per bus level for testing by writing > to sysfs so discovering chipsets that actually work (assuming we are > using modular drivers) should be pretty straight forward. Originally I would have thought this would be a good idea, but now that Vista is out, which supports MSI, I don't think we are going to need this in the future. All new chipsets should support MSI fine and this table will only grow in the future, while the blacklist should not need to have many new entries added to it. So I don't think this is a good idea, sorry. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
Hi. On Thu, 2007-05-24 at 21:49 -0700, Linus Torvalds wrote: > > On Fri, 25 May 2007, Nigel Cunningham wrote: > > > > Does that mean you never ever power off your laptop (assuming you have > > one), and the battery never runs out? Surely you must power it off > > completely sometimes? > > So? The bootup isn't that much worse than a disk suspend/resume, and it's > reliable. > > And actually, I don't use laptops much. I use mostly desktops, and STR > works fine on at least some of them. In contrast, doing some > suspend-to-disk thing would just be insane and idiotic. If I have to wait > for half a minute and have a slow system even after that because my git > trees aren't in the cache, I really might as well just shut them off. > > In contrast, STR means they are quiet and don't waste energy when I don't > use them, but they're instantly available when I care. HUGE difference. > > I really think suspend-to-disk is just a total waste of my time. Ah. That's because you're using [u]swsusp. If you used Suspend2, your git trees would be in the cache, your system wouldn't be slow and you'd still be back up in that half a minute or so - probably less time. Give it a try for a week, and then go back to rebooting. After that, tell me rebooting is better and I've wasted the last 5 or 6 years improving the code. Regards, Nigel signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/2] msi: Invert the sense of the MSI enables.
On Thu, 2007-05-24 at 22:19 -0600, Eric W. Biederman wrote: > Currently we blacklist known bad msi configurations which means we > keep getting MSI enabled on chipsets that either do not support MSI, > or MSI is implemented improperly. Since the normal IRQ routing > mechanism seems to works even when MSI does not, this is a bad default > and causes non-functioning systems for no good reason. > > So this patch inverts the sense of the MSI bus flag to only enable > MSI on known good systems. I am seeding that list with the set of > chipsets with an enabled hypertransport MSI mapping capability. Which > is as close as I can come to an generic MSI enable. So for actually > using MSI this patch is a regression, but for just having MSI enabled > in the kernel by default things should just work with this patch > applied. I guess this is a good idea for random x86 machines. On powerpc I think we'll just turn it on for every bus, and let the existing per-platform logic decide. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)
On Thu, May 24, 2007 at 02:21:26PM -0700, Andrew Morton wrote: > > It's not a matter of when it's evaluated. The user is supposed to be > able to set EXTRA_CFLAGS on the command-line, yes? If they do that then > the "=" in there will rub out their efforts. The makefiles should be > appending new things to EXTRA_CFLAGS, rather than doing a replacement? There is no way to specify additional CFLAGS on the commandline today. For sparse we took the shorthand CF so you can do: make C=2 CF=-warn-bitwise But we have no such thing for CFLAGS. If there is a real need I can cook up something. But frankly I have alway edited top-level Makefile and be doen with it. I will fix it so Kbuild do not barf out if you set EXTRA_* on the commandline but silently ignore it instead. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] LZO de/compression support - take 3
On 5/25/07, Bret Towe <[EMAIL PROTECTED]> wrote: On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote: > On 5/23/07, Bret Towe <[EMAIL PROTECTED]> wrote: > > On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote: > > > > For now, tested on x86 only. > > > > If you have a program to test this I can run it on an amd64 and a g4 ppc > > > > Attached is the kernel module (compress-test) to test this LZO code. > Just compile this module against 2.6.22-rc2 with this LZO patch. Then > testing can be done as: > 1- Mount DebugFS somewhere e.g: > mkdir /debug; mount -t debugfs debugfs /debug > 2- Load the module and do: > cat /path/to/some_file > /debug/compress_test/compress > (/var/log/messages should show that compression was successful) > 3- Then decompress this file as: > cat /debug/compress_test/decompress > /tmp/t > (/var/log/messages should show that decompression was successful) > 4- For extra verification do: > diff /tmp/t /path/to/some_file -- O/P must be empty > > the test worked fine on amd64 from dmesg: LZO compress successful: orig_size=17448, comp_size=8183 LZO decompress successful: decomp_size=17448 and input and output files I gave it: sha1sum test-input output 2221c586e3eb869af7f4333d4f56b441b9aa8414 test-input 2221c586e3eb869af7f4333d4f56b441b9aa8414 output Good to know it worked correctly on 64-bit system too. I will also add exporting benchmarking figures soon. (will be giving the ppc box the same file to test btw when I get to it) and I don't know if it matters much but I tried feeding it a 260k file and it didn't like it cat /usr/bin/yelp > /debug/compress_test/compress cat: write error: No space left on device Ah! I forgot to mention that max file size to feed is 256K (this was just for simplicity of compress-test module implementation). Thanks for your testing. - Nitin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2-mm1 NTFS & SLUB related fix
On Fri, 25 May 2007, young dave wrote: > I can't call it oops, right? Yes sure. This is a problem in the NTFS layer. It writes 2 bytes after the allocated size. > I navagated the ntfs inode.c, and found a possible bug, replaced > kmalloc with kzalloc, > because the ntfschar size is 2. then the kernel doesn't warning > again. and the slub debug info also disappeared. The kzalloc does not increase the size. So I suspect that the bug did not trigger again after the change. > > This patch works for me: > > diff -udr linux/fs/ntfs/inode.c linux.new/fs/ntfs/inode.c > --- linux/fs/ntfs/inode.c 2007-05-25 12:46:27.0 + > +++ linux.new/fs/ntfs/inode.c 2007-05-25 12:45:31.0 + > @@ -136,11 +136,10 @@ > > BUG_ON(!na->name); > i = na->name_len * sizeof(ntfschar); > - ni->name = kmalloc(i + sizeof(ntfschar), GFP_ATOMIC); > + ni->name = kzalloc(i + sizeof(ntfschar), GFP_ATOMIC); Is this ntfs_init_locked_inode? > Bytes b4 0xc2959e28: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a >Object 0xc2959e38: 24 00 51 00 00 00 6b a5 > Redzone 0xc2959e40: 00 00 cc cc First two bytes after the object overwritten. The allocation for this object should have been two bytes longer. > Last alloc: ntfs_init_locked_inode+0x9e/0x110 jiffies_ago=5140 cpu=0 pid=1604 This is the function that allocated a too short object. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc2-mm1 NTFS & SLUB related fix
Hi, As I umount a ntfs partition, the kernel report some trace infomation, I can't call it oops, right? Andrew, could you tell me who is the right person should I send to? I navagated the ntfs inode.c, and found a possible bug, replaced kmalloc with kzalloc, because the ntfschar size is 2. then the kernel doesn't warning again. and the slub debug info also disappeared. This patch works for me: diff -udr linux/fs/ntfs/inode.c linux.new/fs/ntfs/inode.c --- linux/fs/ntfs/inode.c 2007-05-25 12:46:27.0 + +++ linux.new/fs/ntfs/inode.c 2007-05-25 12:45:31.0 + @@ -136,11 +136,10 @@ BUG_ON(!na->name); i = na->name_len * sizeof(ntfschar); - ni->name = kmalloc(i + sizeof(ntfschar), GFP_ATOMIC); + ni->name = kzalloc(i + sizeof(ntfschar), GFP_ATOMIC); if (!ni->name) return -ENOMEM; memcpy(ni->name, na->name, i); - ni->name[i] = 0; } return 0; } And please look the failed kernel message: *** SLUB kmalloc-8: Redzone [EMAIL PROTECTED] slab 0xc1052b20 offset=3640 flags=0x40c2 inuse=73 freelist=0x Bytes b4 0xc2959e28: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a Object 0xc2959e38: 24 00 51 00 00 00 6b a5 $.Q...k¥ Redzone 0xc2959e40: 00 00 cc cc ..ÌÌ FreePointer 0xc2959e44 -> 0x Last alloc: ntfs_init_locked_inode+0x9e/0x110 jiffies_ago=5140 cpu=0 pid=1604 Last free : __vunmap+0xb2/0xe0 jiffies_ago=30727 cpu=0 pid=1491 Filler 0xc2959e68: 5a 5a 5a 5a 5a 5a 5a 5a [] check_object+0x71/0x250 [] preempt_schedule+0x50/0x70 [] free_debug_processing+0xc1/0x1a0 [] vprintk+0x227/0x250 [] __slab_free+0x79/0xe0 [] __ntfs_clear_inode+0x11a/0x1b0 [] kfree+0x63/0x70 [] __ntfs_clear_inode+0x11a/0x1b0 [] __ntfs_clear_inode+0x11a/0x1b0 [] ntfs_clear_big_inode+0x59/0x120 [] dquot_drop+0x0/0x50 [] clear_inode+0xc1/0x150 [] generic_forget_inode+0x107/0x180 [] iput+0x53/0x60 [] ntfs_put_super+0x6c5/0x8e0 [] generic_shutdown_super+0xea/0x100 [] kill_block_super+0xc/0x20 [] deactivate_super+0x4e/0xa0 [] sys_umount+0x35/0x80 [] do_page_fault+0x434/0x5c0 [] sys_oldumount+0x15/0x20 [] syscall_call+0x7/0xb === @@@ SLUB kmalloc-8: Restoring redzone (0xcc) from 0xc2959e40-0xc2959e43 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
On Fri, 25 May 2007, Nigel Cunningham wrote: > > Does that mean you never ever power off your laptop (assuming you have > one), and the battery never runs out? Surely you must power it off > completely sometimes? So? The bootup isn't that much worse than a disk suspend/resume, and it's reliable. And actually, I don't use laptops much. I use mostly desktops, and STR works fine on at least some of them. In contrast, doing some suspend-to-disk thing would just be insane and idiotic. If I have to wait for half a minute and have a slow system even after that because my git trees aren't in the cache, I really might as well just shut them off. In contrast, STR means they are quiet and don't waste energy when I don't use them, but they're instantly available when I care. HUGE difference. I really think suspend-to-disk is just a total waste of my time. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] msi: Invert the sense of the MSI enables.
On Thu, 24 May 2007 22:19:09 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote: > Currently we blacklist known bad msi configurations which means we > keep getting MSI enabled on chipsets that either do not support MSI, > or MSI is implemented improperly. Since the normal IRQ routing > mechanism seems to works even when MSI does not, this is a bad default > and causes non-functioning systems for no good reason. > > So this patch inverts the sense of the MSI bus flag to only enable > MSI on known good systems. I am seeding that list with the set of > chipsets with an enabled hypertransport MSI mapping capability. Which > is as close as I can come to an generic MSI enable. So for actually > using MSI this patch is a regression, but for just having MSI enabled > in the kernel by default things should just work with this patch > applied. > > People can still enable MSI on a per bus level for testing by writing > to sysfs so discovering chipsets that actually work (assuming we are > using modular drivers) should be pretty straight forward. Yup. Do we have a feel for how much performace we're losing on those systems which _could_ do MSI, but which will end up defaulting to not using it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
Howdy. On Thu, 2007-05-24 at 20:31 -0700, Linus Torvalds wrote: > > On Fri, 25 May 2007, Nigel Cunningham wrote: > > > > > > That said, I think freezing is crap even for > > > snapshotting/suspend-to-disk, > > > but the point of the above rant is to show how insane it is to think that > > > problems and complexity in one area should translate into problems and > > > complexity in another area. > > > > Does that imply that you'd prefer to see filesystem checkpointing code, > > that you think freezing can be done better, or do you have some other > > solution that hasn't occurred to me? > > I actually don't think that processes should be frozen really at all. > > I agree that filesystems have to be frozen (and I think that checkpointing > of the filesystem or block device is "too clever"), but I just don't think > that has anything to do with freezing processes. > > So I'd actually much prefer to freeze at the VFS (and socket layers, etc), > and make sure that anybody who tries to write or do something else that we > cannot do until resuming, will just be blocked (or perhaps just buffered)! > > See? I actually think that this process-based thing is barking up the > wrong tree. After all, it's really not the case that we need to stop > processes, and stopping processes really does have some problems. It's > simpler in some ways, but I think a more directed solution would actually > be better. That does sound doable. I'm sorry to say it, but dropping process freezing still seems to me like the better way though. I prefer it because of the reliability aspect. With the current code, having frozen processes, I can look at the state of memory, calculate how much I'll need for this or that and know that I'll have sufficient memory for the atomic copy and for doing the I/O (making assumptions about how much memory drivers will allocate) before I start to do either. If we stop freezing processes, that predictability will go away. There'll always be a possibility that some process will get memory hungry and stop me from being able to get the image on disk, and I'll have to either abort or give up and try again and again until I can complete writing the image, the battery runs out or whatever... > >bviously we _do_ want to actually try to quiesce normal user processes. > >But by "normal user", I'd be willing to limit it to non-uid-zero things, > >for example. Exactly because it does turn out that the kernel kind of > >depends on user-land things for stuff like network filesystem connection > >setup etc (ie we tend to do things like the mount encryption stuff in > >userland!). Not sure who you're quoting here, but it's not me. Pavel maybe? I was unsub'd for a couple of weeks, so guess it's from during that period. > But I really don't care that deeply per se, exactly because I don't use it > myself. I think people are going down the wrong rabbit-hole, but it > wouldn't _irritate_ me that much except for the fact that it now also > impacts suspend-to-RAM. Does that mean you never ever power off your laptop (assuming you have one), and the battery never runs out? Surely you must power it off completely sometimes? If you do, doesn't that ever happen at a time when you're part way through something and you'd like to be able to pick up your merge or whatever later without having to say "Now, where was I up to?" *shrug* Maybe you're just exceptional :) (Yeah, we know you are in other ways, but this way?...) Regards, Nigel signature.asc Description: This is a digitally signed message part
Re: [PATCH] Make prepare_namespace() wait for devices
Andrew Morton wrote: > Whatever. I think you can work it out ;) > > Bare with me, I just woke up ;) > while (driver_probe_done() || (ROOT_DEV = name_to_dev_t(...)) == 0) > > perhaps? > > The loop-which-sleeps within a loop-which-sleeps seems poorly thought out? > I'd say a matter of taste. I'm not a big fan och cramming things into the while() clause. The idea with the double loops was to keep this thread asleep when we could detect meaningful work elsewhere in the kernel. You could just remove the inner-most loop if it offends you. :) Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] msi: Add support for the Intel chipsets that support MSI.
This patch is the result of a quick survey of the Intel chipset
documents. I took a quick look in the document to see if the chipset
supported MSI and if so I looked through to find the vendor and device
id of device 0 function 0 of the chipset and added a quirk for that
device id if I it was not a duplicate.
I happen to have one of the systems on the list so the patch is
tested, and seems to work fine.
This patch should be safe. The anecdotal evidence is that when dealing
with MSI the Intel chipsets just work. If we find some buggy ones
changing the list won't be hard.
This patch should also serve as an example of how simple it is to
enable MSI on a chipset or platform configuration where it is known
to work.
This patch does not use the defines from pci_ids.h because there are
so many defines and so many duplicate host-bridge device id duplicates
in Intels documentation I could not keep any of it straight without
using the raw device ids. Which allowed me to order the fixups and
quickly detect duplicates. Unfortunately the good names were
a confusing layer of abstraction. I have still updated pci_ids.h
so that it is possible to track the numbers back to their chipset.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
drivers/pci/quirks.c| 27 +++
include/linux/pci_ids.h | 10 ++
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index f60c6c6..40fb499 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1661,5 +1661,32 @@ static void __devinit quirk_msi_ht_cap(struct pci_dev
*dev)
}
DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_msi_ht_cap);
+static void __devinit quirk_msi_chipset(struct pci_dev *dev)
+{
+ dev->bus->bus_flags |= PCI_BUS_FLAGS_MSI;
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x254C, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2550, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2558, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2560, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2570, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2578, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2580, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2581, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2588, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2590, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x25C8, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x25D0, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x25D4, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2600, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2770, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2774, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2778, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x277C, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x27A0, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2990, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2A00, quirk_msi_chipset);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x359E, quirk_msi_chipset);
+
#endif /* CONFIG_PCI_MSI */
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 62b3e00..71df8c0 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2232,11 +2232,20 @@
#define PCI_DEVICE_ID_INTEL_82865_IG 0x2572
#define PCI_DEVICE_ID_INTEL_82875_HB 0x2578
#define PCI_DEVICE_ID_INTEL_82915G_HB 0x2580
+#define PCI_DEVICE_ID_INTEL_82915_HB 0x2581
#define PCI_DEVICE_ID_INTEL_82915G_IG 0x2582
+#define PCI_DEVICE_ID_INTEL_E7221_HB 0x2588
#define PCI_DEVICE_ID_INTEL_82915GM_HB 0x2590
#define PCI_DEVICE_ID_INTEL_82915GM_IG 0x2592
+#define PCI_DEVICE_ID_INTEL_5000P_HB 0x25C8
+#define PCI_DEVICE_ID_INTEL_5000Z_HB 0x25D0
+#define PCI_DEVICE_ID_INTEL_5000V_HB 0x25D4
+#define PCI_DEVICE_ID_INTEL_E8500_HB 0x2600
#define PCI_DEVICE_ID_INTEL_82945G_HB 0x2770
#define PCI_DEVICE_ID_INTEL_82945G_IG 0x2772
+#define PCI_DEVICE_ID_INTEL_82955X_HB 0x2774
+#define PCI_DEVICE_ID_INTEL_3000_HB0x2778
+#define PCI_DEVICE_ID_INTEL_82975X_HB 0x277C
#define PCI_DEVICE_ID_INTEL_82945GM_HB 0x27A0
#define PCI_DEVICE_ID_INTEL_82945GM_IG 0x27A2
#define PCI_DEVICE_ID_INTEL_ICH6_0 0x2640
@@ -2272,6 +2281,7 @@
#define PCI_DEVICE_ID_INTEL_ICH9_4 0x2914
#define PCI_DEVICE_ID_INTEL_ICH9_5 0x2915
#define PCI_DEVICE_ID_INTEL_ICH9_6 0x2930
+#define PCI_DEVICE_ID_INTEL_82946_HB 0x2990
#define PCI_DEVICE_ID_INTEL_82855PM_HB 0x3340
#define PCI_DEVICE_ID_INTEL_82830_HB 0x3575
#define PCI_DEVICE_ID_INTEL_82830_CGC 0x3577
--
1.5.1.1.181.g2de0
-
To unsubscribe
[PATCH 1/2] msi: Invert the sense of the MSI enables.
Currently we blacklist known bad msi configurations which means we keep getting MSI enabled on chipsets that either do not support MSI, or MSI is implemented improperly. Since the normal IRQ routing mechanism seems to works even when MSI does not, this is a bad default and causes non-functioning systems for no good reason. So this patch inverts the sense of the MSI bus flag to only enable MSI on known good systems. I am seeding that list with the set of chipsets with an enabled hypertransport MSI mapping capability. Which is as close as I can come to an generic MSI enable. So for actually using MSI this patch is a regression, but for just having MSI enabled in the kernel by default things should just work with this patch applied. People can still enable MSI on a per bus level for testing by writing to sysfs so discovering chipsets that actually work (assuming we are using modular drivers) should be pretty straight forward. Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> --- Documentation/MSI-HOWTO.txt | 30 +-- drivers/pci/msi.c | 19 drivers/pci/pci-sysfs.c |6 ++-- drivers/pci/quirks.c| 66 --- include/linux/pci.h |2 +- 5 files changed, 42 insertions(+), 81 deletions(-) diff --git a/Documentation/MSI-HOWTO.txt b/Documentation/MSI-HOWTO.txt index 0d82407..81f4e18 100644 --- a/Documentation/MSI-HOWTO.txt +++ b/Documentation/MSI-HOWTO.txt @@ -485,21 +485,31 @@ single device. This may be achieved by either not calling pci_enable_msi() or all, or setting the pci_dev->no_msi flag before (most of the time in a quirk). -6.2. Disabling MSI below a bridge - -The vast majority of MSI quirks are required by PCI bridges not -being able to route MSI between busses. In this case, MSI have to be -disabled on all devices behind this bridge. It is achieves by setting -the PCI_BUS_FLAGS_NO_MSI flag in the pci_bus->bus_flags of the bridge +6.2. Enabling MSI below a bridge + +Despite being standard, mandated by the pci-express spec, supported +by plugin cards, and less hassle to deal with then irq routing tables +not all hardware, and not all chipsets enable MSI, and not all +motherboards enable MSI support in MSI supporting hardware. So until +a hardware specific test is implemted to test if MSI is supported and +enabled on a piece of hardware we disable MSI support by default. +This at least ensures users will have a working system using older +mechanisms. + +So to enable MSI support on a particular chipset we need a MSI quirk +that recognizes the chipset and test to see if MSI is enabled. In +this case, MSI has to be enabled on all bridges that are capable of +transform MSI messages into irqs. It is achieved by setting +the PCI_BUS_FLAGS_MSI flag in the pci_bus->bus_flags of the bridge subordinate bus. There is no need to set the same flag on bridges that -are below the broken bridge. When pci_enable_msi() is called to enable -MSI on a device, pci_msi_supported() takes care of checking the NO_MSI -flag in all parent busses of the device. +are below the working bridge. When pci_enable_msi() is called to enable +MSI on a device, pci_msi_supported() takes care of checking to ensure +at least one parent buss supports MSI. Some bridges actually support dynamic MSI support enabling/disabling by changing some bits in their PCI configuration space (especially the Hypertransport chipsets such as the nVidia nForce and Serverworks -HT2000). It may then be required to update the NO_MSI flag on the +HT2000). It may then be required to update the MSI flag on the corresponding devices in the sysfs hierarchy. To enable MSI support on device ":00:0e", do: diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index d9cbd58..000c9ae 100644 --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -467,15 +467,20 @@ static int pci_msi_check_device(struct pci_dev* dev, int nvec, int type) if (nvec < 1) return -ERANGE; - /* Any bridge which does NOT route MSI transactions from it's -* secondary bus to it's primary bus must set NO_MSI flag on -* the secondary pci_bus. -* We expect only arch-specific PCI host bus controller driver -* or quirks for specific PCI bridges to be setting NO_MSI. + /* For pure pci bridges routing MSI traffic is just another +* example of routing a small DMA transaction so it should be +* no problem. However getting MSI traffic from PCI to the +* the non PCI part of the chipset is a problem. So this +* code checks to see if we have an upstream bus where +* MSI is known to work. +* +* Only non pci to pci bridges are expected to set this flag. */ for (bus = dev->bus; bus; bus = bus->parent) - if (bus->bus_flags & PCI_BUS_FLAGS_NO_MSI) - return -EINVAL; + if (bus->bus_flags &
Re: [PATCH] Make prepare_namespace() wait for devices
On Fri, 25 May 2007 06:03:54 +0200 Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Thu, 24 May 2007 14:21:35 +0200
> > Pierre Ossman <[EMAIL PROTECTED]> wrote:
> >
> >
> >> + /* wait for any asynchronous scanning to complete */
> >> + if ((ROOT_DEV == 0) && root_wait) {
> >> + printk(KERN_INFO "Waiting for root device %s...\n",
> >> + saved_root_name);
> >> + do {
> >> + while (driver_probe_done() != 0)
> >> + msleep(100);
> >> + ROOT_DEV = name_to_dev_t(saved_root_name);
> >> + if (ROOT_DEV == 0)
> >> + msleep(100);
> >> + } while (ROOT_DEV == 0);
> >> + }
> >>
> >
> > This seems overly complex. Can't we simply do
> >
> >
> > while (driver_probe_done() || ROOT_DEV == 0)
> > msleep(100);
> >
> > ?
> >
>
> How would ROOT_DEV get updated in that loop?
>
Whatever. I think you can work it out ;)
while (driver_probe_done() || (ROOT_DEV = name_to_dev_t(...)) == 0)
perhaps?
The loop-which-sleeps within a loop-which-sleeps seems poorly thought out?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On Thursday 24 May 2007 20:58, Casey Schaufler wrote: > On Fedora zcat, gzip and gunzip are all links to the same file. > I can imagine (although it is a bit of a stretch) allowing a set > of users access to gunzip but not gzip (or the other way around). > There are probably more sophisticated programs that have different > behavior based on the name they're invoked by that would provide > a more compelling arguement, assuming of course that you buy into > the behavior-based-on-name scheme. What I think I'm suggesting is > that AppArmor might be useful in addressing the fact that a file > with multiple hard links is necessarily constrained to have the > same access control on each of those names. That assumes one > believes that such behavior is flawwed, and I'm not going to try > to argue that. The question was about an example, and there is one. Different policy for different names of the same binary makes more obvious sense with chroot environments. That's slightly different from having different permissions for the same file within a single profile though. Thanks, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in dentry_iput with 2.6.22-rc2 on AMD64
On Tue, May 22, 2007 at 11:57:11AM +0200, Jan Kara wrote: > > I was running a multithreaded perl application that leaks some memory > > so it gets to eat up a significant chunk of my 2 GB and even push a > > bit into swap. I left it running before going out for a walk. > Hmm, what seems suspitious is, that in R12 (which probably contains > the address dereferenced later) is address 9100... while all other > addresses start with 8100. So it seems to me it could be a 1-bit > flip. Care to check your memory with memtest? I let it run overnight: 8 passes and no surprises. This is a system that has been quite stable for a year and a half, except finding the occasional kernel bug ;) > Also this is a code all other people use all the time so I guess we > would see more reports if this was some general bug... Haven't got any more oopses like that, either. Thanks, florin -- Bruce Schneier expects the Spanish Inquisition. http://geekz.co.uk/schneierfacts/fact/163 signature.asc Description: Digital signature
Re: how to allow board writers to customize driver behavior (watchdog here)
On Thu, May 24, 2007 at 01:32:30PM -0400, Robin Getz wrote: > On Thu 24 May 2007 11:23, Paul Mundt pondered: > > > > Calling it a periodic timer when its in periodic timer mode makes sense. > > No disagreements - but I don't think that a watchdog that doesn't cause a > reset is a periodic timer. > I'm not sure what else you think it is? On most platforms, when it's not in reset mode, it works as a free-running timer with an IRQ generated on overflow. I've certainly used the watchdog as a system timer before on boards where all of the timer channels are tied up for other uses. > > Why you would want to interface that with a userspace watchdog daemon is > > beyond me, they're conceptually unrelated. > > Agreed again - periodic timers have nothing to do with watchdogs. This is > where I am confused about why you are saying that the only event a watchdog > can have is a hard reset. > No, what I said was that the only event that _matters_ to CONFIG_WATCHDOG is a hard reset. So far no one has suggested anything outside of hard reset, periodic timer, or softlockup detection that would be useful to extend CONFIG_WATCHDOG for. If you're talking about specific events, clockevents are still a much better way to go than trying to hammer something in to CONFIG_WATCHDOG that it was never designed for. If you have some 'special' events for your watchdog that would be of use to others, tying these in as additional flags for clockevents would be far more beneficial anyways. > > I'm not advocating hiding a clocksource somewhere in the depths of > > CONFIG_WATCHDOG, they're completely unrelated. > > I (and many others) consider a "watchdog" a clock sink - something that needs > to be poked within certain limits (too fast can indicate a failures just as > too slow is a failure). > Currently there's nothing in the kernel that cares about clearing 'too fast'. I can't imagine why this _should_ be treated as a failure, but feel free to code up a solution if you feel it will be useful. > The event or how something is notified of the failure of the watchdog to be > serviced shouldn't determine what the name is. > If all you want is a timer that you occasionally have to poke and then take some notification when it expires, you can just use a regular one-shot timer anyways and bank off of the system timer, the 'watchdog' is certainly not doing anything useful at this point. So far the only example anyone has provided outside of periodic timers or hardware reset has been dumping the stack when something gets stuck. Softlockup does this already today, using a timer. If your system is completely dead, you won't have any way to trigger or see the stack dump anyways, so the watchdog doesn't buy you anything there, either. What many watchdogs do today is simply to have split timer for userspace and the actual hardware (where userspace has to poke the timer every now and then, or the kernel will allow the overflow). This is pretty common for watchdogs with very fast overflow periods. There's certainly nothing wrong with having a timer that runs out and kicks a notifier chain if there's something special you want to do, but tying up the watchdog hardware for that is silly. There are many other things one has to use the watchdog hardware for anyways (reset, periodic timing, frequency scaling -- waiting for PLL stabilization, etc.). Tying down a hardware block where a struct timer_list will do the same work makes no sense. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make prepare_namespace() wait for devices
Andrew Morton wrote:
> On Thu, 24 May 2007 14:21:35 +0200
> Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
>
>> +/* wait for any asynchronous scanning to complete */
>> +if ((ROOT_DEV == 0) && root_wait) {
>> +printk(KERN_INFO "Waiting for root device %s...\n",
>> +saved_root_name);
>> +do {
>> +while (driver_probe_done() != 0)
>> +msleep(100);
>> +ROOT_DEV = name_to_dev_t(saved_root_name);
>> +if (ROOT_DEV == 0)
>> +msleep(100);
>> +} while (ROOT_DEV == 0);
>> +}
>>
>
> This seems overly complex. Can't we simply do
>
>
> while (driver_probe_done() || ROOT_DEV == 0)
> msleep(100);
>
> ?
>
How would ROOT_DEV get updated in that loop?
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Add select PHYLIB to the UCC_GETH Kconfig option
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jeff Garzik > Sent: Friday, May 25, 2007 5:48 AM > To: Jan Altenberg > Cc: Phillips Kim-R1AAHA; linux-kernel@vger.kernel.org; [EMAIL PROTECTED] > Subject: Re: [PATCH] Add select PHYLIB to the UCC_GETH Kconfig option > > Jan Altenberg wrote: > > ucc_geth has been migrated to use the common phylib code. So lets add a > > 'select PHYLIB' to the UCC_GETH Kconfig entry. > > > > Signed-off-by: Jan Altenberg <[EMAIL PROTECTED]> > > > > --- > > drivers/net/Kconfig |1 + > > 1 file changed, 1 insertion(+) > > > > Index: linux-2.6/drivers/net/Kconfig > > === > > --- linux-2.6.orig/drivers/net/Kconfig > > +++ linux-2.6/drivers/net/Kconfig > > @@ -2280,6 +2280,7 @@ config GFAR_NAPI > > config UCC_GETH > > tristate "Freescale QE Gigabit Ethernet" > > depends on QUICC_ENGINE > > + select PHYLIB > > select UCC_FAST > > Please fix the Kconfig warnings first. > I will follow up this. > Also, I ask again: WHO IS THE MAINTAINER OF THIS DRIVER? > > I am tired of five independent people patching the same driver. Sorry for the trouble, I will post a patch to the MAINTAINER file and help to maintain ucc_geth related patches. - Leo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
On Fri, 25 May 2007, Nigel Cunningham wrote: > > > > That said, I think freezing is crap even for snapshotting/suspend-to-disk, > > but the point of the above rant is to show how insane it is to think that > > problems and complexity in one area should translate into problems and > > complexity in another area. > > Does that imply that you'd prefer to see filesystem checkpointing code, > that you think freezing can be done better, or do you have some other > solution that hasn't occurred to me? I actually don't think that processes should be frozen really at all. I agree that filesystems have to be frozen (and I think that checkpointing of the filesystem or block device is "too clever"), but I just don't think that has anything to do with freezing processes. So I'd actually much prefer to freeze at the VFS (and socket layers, etc), and make sure that anybody who tries to write or do something else that we cannot do until resuming, will just be blocked (or perhaps just buffered)! See? I actually think that this process-based thing is barking up the wrong tree. After all, it's really not the case that we need to stop processes, and stopping processes really does have some problems. It's simpler in some ways, but I think a more directed solution would actually be better. >bviously we _do_ want to actually try to quiesce normal user processes. >But by "normal user", I'd be willing to limit it to non-uid-zero things, >for example. Exactly because it does turn out that the kernel kind of >depends on user-land things for stuff like network filesystem connection >setup etc (ie we tend to do things like the mount encryption stuff in >userland!). But I really don't care that deeply per se, exactly because I don't use it myself. I think people are going down the wrong rabbit-hole, but it wouldn't _irritate_ me that much except for the fact that it now also impacts suspend-to-RAM. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCIE
> I am now wondering whether the usage of MSI would help in this case and > that i should be using enable_msi before request_irq ? MSI interrupts are never shared. So if pci_enable_msi() succeeds, you can be sure that the interrupts you get with that IRQ number are coming from your device. But using MSI does not work on all systems, so your driver needs to work with standard (possibly shared) INTx interrupts too. And you should probably provide at least a module flag to disable the use of MSI, to avoid problems on buggy systems. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.6.21 hang in cancel_rearming_delayed_workqueue()
There is a problem with the calling cancel_rearming_delayed_work if the
timer was not yet active.
I see this problem when netpoll_cleanup() is called without having done
any work because it had not processed any packets yet. The problem
appears to be a result of the loop check
while(!cancel_delayed_work(dwork)).This endlessly loops because
del_timer_sync() can return 0 or 1 for success which is passed back as a
result to the final invariant check for the loop. In this particular
case zero will always be returned because the timer is not active.
It is possible that the problem exists else where, but I thought I would
ask if this is expected?
#0 del_timer_sync (timer=0xc7ed90f8) at kernel/timer.c:530
#1 0xc012f08e in cancel_rearming_delayed_workqueue (wq=0xc7fee800,
dwork=0xc7ed90e8) at include/linux/workqueue.h:201
#2 0xc012f0af in cancel_rearming_delayed_work (dwork=0x20)
at kernel/workqueue.c:680
#3 0xc0312f78 in netpoll_cleanup (np=0xc880bf40) at net/core/netpoll.c:784
Possible fix.
Signed-off-by: Jason Wessel <[EMAIL PROTECTED]>
Index: linux-2.6.21/kernel/workqueue.c
===
--- linux-2.6.21.orig/kernel/workqueue.c
+++ linux-2.6.21/kernel/workqueue.c
@@ -666,7 +666,7 @@ EXPORT_SYMBOL(flush_scheduled_work);
void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq,
struct delayed_work *dwork)
{
- while (!cancel_delayed_work(dwork))
+ while (cancel_delayed_work(dwork) > 0)
flush_workqueue(wq);
}
EXPORT_SYMBOL(cancel_rearming_delayed_workqueue);
Thanks,
Jason.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] msi: mask the msix vector before we unmap it.
With these two lines in the reverse order the drives/block/ccis.c was
oopsing in msi_free_irqs. Silly us calling writel on an area after
we unmap it.
BUG: unable to handle kernel paging request at virtual address f8b2200c
printing eip:
c01e9cc7
*pdpt = 3001
*pde = 37e48067
*pte =
Oops: 0002 [#1]
SMP
Modules linked in: cciss ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core
sunrpc loop dm_multipath button battery asus_acpi ac tg3 floppy sg dm_snapshot
dm_zero dm_mirror ext3 jbd dm_mod ata_piix libata mptsas scsi_transport_sas
mptspi scsi_transport_spi mptscsih mptbase sd_mod scsi_mod
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.22-rc2-gd2579053 #1)
EIP is at msi_free_irqs+0x81/0xbe
eax: f8b22000 ebx: f71f3180 ecx: f7fff280 edx: c1886eb8
esi: f7c4e800 edi: f7c4ec48 ebp: 0002 esp: f5a0dec8
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process rmmod (pid: 5286, ti=f5a0d000 task=c47d2550 task.ti=f5a0d000)
Stack: 0002 f8b72294 0400 f8b69ca7 f8b6bc6c 0002
f5a997f4 f8b69d61 f7c5a4b0 f7c4e848 f7c4e848
f7c4e800 f7c4e800 f8b72294 f7c4e848 f8b72294 c01e3cdf f7c4e848 c024c469
Call Trace:
[] cciss_shutdown+0xae/0xc3 [cciss]
[] cciss_remove_one+0xa5/0x178 [cciss]
[] pci_device_remove+0x16/0x35
[] __device_release_driver+0x71/0x8e
[] driver_detach+0xa0/0xde
[] bus_remove_driver+0x27/0x41
[] pci_unregister_driver+0xb/0x13
[] cciss_cleanup+0xf/0x51 [cciss]
[] sys_delete_module+0x110/0x135
[] sysenter_past_esp+0x5f/0x85
Here's a patch that just reverses the 2 lines of code as Eric suggests. Please
consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
Signed-off-by: Chase Maupin <[EMAIL PROTECTED]>
Signed-off-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
---
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index e01380b..6632150 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -558,12 +558,12 @@ static int msi_free_irqs(struct pci_dev* dev)
list_for_each_entry_safe(entry, tmp, >msi_list, list) {
if (entry->msi_attrib.type == PCI_CAP_ID_MSIX) {
- if (list_is_last(>list, >msi_list))
- iounmap(entry->mask_base);
-
writel(1, entry->mask_base + entry->msi_attrib.entry_nr
* PCI_MSIX_ENTRY_SIZE
+ PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
+
+ if (list_is_last(>list, >msi_list))
+ iounmap(entry->mask_base);
}
list_del(>list);
kfree(entry);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/7] libata: check for AN support
Kristen Carlson Accardi wrote: Check to see if an ATAPI device supports Asynchronous Notification. If so, enable it. Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]> --- Andrew, I cleaned up the function header to properly comply with kernel doc requirements. Other than that, this patch is the same. I would ask for a simple revision: update ata_dev_set_AN() such that it takes a second argument 'enable'. This boolean indicates to the function whether SETFEATURES_SATA_ENABLE or SETFEATURES_SATA_DISABLE should be passed to the device. Otherwise than that, it's ready to merge I would say. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/7] Asynchronous Notification for ATAPI devices (resend)
Kristen Carlson Accardi wrote: Hi Jeff, Here are the AN patches again, they have not changed with the exception of patch #1, which does set the host flag in board_ahci and board_ahci_pi now (thanks Tejun). This patch series implements Asynchronous Notification (AN) for SATA ATAPI devices as defined in SATA 2.5 and AHCI 1.1 and higher. Drives which support this feature will send a notification when new media is inserted and removed, preventing the need for user space to poll for new media. This support is exposed to user space via a flag that will be set in /sys/block/sr*/capability_flags. If the flag is set, user space can disable polling for the new media, and the genhd driver will send a KOBJ_CHANGE event with the envp set to MEDIA_CHANGE_EVENT=1. Note that this patch only implements support for directly attached drives - AN with drives attached to a port multiplier requires additional changes. Patches look OK to me... it will take some coordination for the non-libata bits. I think Andrew mentioned some of this. And if the SCSI bits get stuck in the SCSI maintainer's bit bucket, let me know. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [INPUT] i8042 not detecting AUX port
On Thursday 24 May 2007 16:50, Emmanuel Fusté wrote: > This bios is full of bugs, a real plague. Will try to quirk > this register at boot time. > There isn't an updated BIOS, is there? -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel crash in timer interrupt handler
The kernel crashed inside timer handler. Anyone has ideas? The Linux I'm using is 2.6.19. Thanks in advance! BUG: soft lockup detected on CPU#0! Call Trace: [C0395EA0] [C000C308] show_stack+0x58/0x180 (unreliable) [C0395ED0] [C0043A18] softlockup_tick+0xac/0xc8 [C0395EF0] [C00223C4] run_local_timers+0x18/0x28 [C0395F00] [C0022414] update_process_times+0x40/0x7c [C0395F10] [C0005800] timer_interrupt+0x70/0x208 [C0395F40] [C0004874] ret_from_except+0x0/0x14 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Add the device IDs for AMD/ATI SB700
Henry Su wrote:
> --- linux-2.6.21.1.orig/drivers/ata/pata_atiixp.c 2007-05-10
> 06:30:14.0 폍
> linux-2.6.21.1/drivers/ata/pata_atiixp.c 2007-05-10 07:17:07.0 폍
> @@ -283,6 ,7 @@ static const struct pci_device_id atiixp
> { PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP300_IDE), },
> { PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP400_IDE), },
> { PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP600_IDE), },
> + { PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP700_IDE), },
Patch applied manually.
Your patches are all technically correct -- but you really need to fix
your email so that we can receive and apply your patches via scripts.
This is a basic step that every kernel contributor needs to take.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
Hi.
On Thu, 2007-05-24 at 19:41 -0700, Linus Torvalds wrote:
>
> On Fri, 25 May 2007, Nigel Cunningham wrote:
> >
> > To answer the question, I guess the answer is that although they're
> > different creatures, they have similarities. This is one of them, which
> > is why I could make the mistake I did. Nothing in the issue being
> > discussed was unique to suspend-to-ram. Perhaps we (or at least I) focus
> > too much on the similarities, but that doesn't mean they're not there.
>
> I agree that the current bug is not unique to STR. In fact, I think Romano
> tested both STD and STR, and both had the same bug with the 60s timeout.
>
> But what irritates me is that STR really shouldn't have _had_ that bug at
> all. The only reason STR had the same bug as STD was exactly the fact that
> the two features are too closely inter-twined in the kernel.
>
> That irritates me hugely. We had a bug we should never had had! We had a
> bug because people are sharing code that shouldn't be shared! We had a bug
> because of code that makes no sense in the first place!
>
> I agree that disk snapshotting is much harder. If we had a bug just in
> that part, I wouldn't mind it so much. Getting hard problems wrong isn't
> something you should be ashamed of. What I mind is that the _easier_
> problem got infected by all the bugs from the _harder_ issue. That just
> makes me really really angry and frustrated.
>
> Look at it this way: if you designed a CPU, and you made the integer
> code-path share everything with the floating point side, because "addition
> is addition", and as a result the latency for the simple arithmetic and
> logical ops in integer ALU was four cycles, what would you be?
>
> You'd be a moron, that's what.
>
> And that is _exactly_ what the current STD/STR code does. It says "suspend
> is suspend" and tries to share the same pipeline, even though the two
> operations are totally different, and share nothing but the name people
> use for it (and even the name is really pretty weak, and I've tried to
> get people to use some other name for STD).
I think I get what you're trying to say, but I also think you're either
overstating your case ("...totally different and share nothing but the
name...") or underestimating the similiarity - they both need (albeit
for different reasons) to do the cpu hotplugging, driver suspending
(yeah, there are similarities and differences there) and irq disabling.
That's _some_ similarity. Apart from that, yeah - they are totally
different.
Re the name, we discussed changing the name of Suspend2 on IRC a night
or two ago. We came to the conclusion that, for better or for worse,
it's too well known now. I can see your logic in wanting to
differentiate them, but I seem to be a bit stuck :\. Push some more.
Maybe we'll get there anyway :) Maybe you can get rid of that horrible,
unpronounceable 'swsusp' name while you're at it? :)
> So yes,the two things _do_ share the problem, but they really really
> shouldn't. There's no reason to think that they should. And it drives me
> absolutely bonkers that people seem to have such a hard time seeing that.
>
> That said, I think freezing is crap even for snapshotting/suspend-to-disk,
> but the point of the above rant is to show how insane it is to think that
> problems and complexity in one area should translate into problems and
> complexity in another area.
Does that imply that you'd prefer to see filesystem checkpointing code,
that you think freezing can be done better, or do you have some other
solution that hasn't occurred to me?
> And if the snapshot people want to screw up their snapshots with freezing,
> I don't actually care that much. I'd much rather have working STR. As it
> is now, they're now _both_ broken.
Fair enough :).
Nigel
signature.asc
Description: This is a digitally signed message part
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
On Fri, 25 May 2007, Nigel Cunningham wrote: > > To answer the question, I guess the answer is that although they're > different creatures, they have similarities. This is one of them, which > is why I could make the mistake I did. Nothing in the issue being > discussed was unique to suspend-to-ram. Perhaps we (or at least I) focus > too much on the similarities, but that doesn't mean they're not there. I agree that the current bug is not unique to STR. In fact, I think Romano tested both STD and STR, and both had the same bug with the 60s timeout. But what irritates me is that STR really shouldn't have _had_ that bug at all. The only reason STR had the same bug as STD was exactly the fact that the two features are too closely inter-twined in the kernel. That irritates me hugely. We had a bug we should never had had! We had a bug because people are sharing code that shouldn't be shared! We had a bug because of code that makes no sense in the first place! I agree that disk snapshotting is much harder. If we had a bug just in that part, I wouldn't mind it so much. Getting hard problems wrong isn't something you should be ashamed of. What I mind is that the _easier_ problem got infected by all the bugs from the _harder_ issue. That just makes me really really angry and frustrated. Look at it this way: if you designed a CPU, and you made the integer code-path share everything with the floating point side, because "addition is addition", and as a result the latency for the simple arithmetic and logical ops in integer ALU was four cycles, what would you be? You'd be a moron, that's what. And that is _exactly_ what the current STD/STR code does. It says "suspend is suspend" and tries to share the same pipeline, even though the two operations are totally different, and share nothing but the name people use for it (and even the name is really pretty weak, and I've tried to get people to use some other name for STD). So yes,the two things _do_ share the problem, but they really really shouldn't. There's no reason to think that they should. And it drives me absolutely bonkers that people seem to have such a hard time seeing that. That said, I think freezing is crap even for snapshotting/suspend-to-disk, but the point of the above rant is to show how insane it is to think that problems and complexity in one area should translate into problems and complexity in another area. And if the snapshot people want to screw up their snapshots with freezing, I don't actually care that much. I'd much rather have working STR. As it is now, they're now _both_ broken. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] LZO de/compression support - take 3
On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote: On 5/23/07, Bret Towe <[EMAIL PROTECTED]> wrote: > On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote: > > For now, tested on x86 only. > > If you have a program to test this I can run it on an amd64 and a g4 ppc > Attached is the kernel module (compress-test) to test this LZO code. Just compile this module against 2.6.22-rc2 with this LZO patch. Then testing can be done as: 1- Mount DebugFS somewhere e.g: mkdir /debug; mount -t debugfs debugfs /debug 2- Load the module and do: cat /path/to/some_file > /debug/compress_test/compress (/var/log/messages should show that compression was successful) 3- Then decompress this file as: cat /debug/compress_test/decompress > /tmp/t (/var/log/messages should show that decompression was successful) 4- For extra verification do: diff /tmp/t /path/to/some_file -- O/P must be empty Thanks! Nitin the test worked fine on amd64 from dmesg: LZO compress successful: orig_size=17448, comp_size=8183 LZO decompress successful: decomp_size=17448 and input and output files I gave it: sha1sum test-input output 2221c586e3eb869af7f4333d4f56b441b9aa8414 test-input 2221c586e3eb869af7f4333d4f56b441b9aa8414 output (will be giving the ppc box the same file to test btw when I get to it) and I don't know if it matters much but I tried feeding it a 260k file and it didn't like it cat /usr/bin/yelp > /debug/compress_test/compress cat: write error: No space left on device - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] msi: Fix the ordering of msix irqs.
On Thu, 2007-05-24 at 15:08 -0600, Eric W. Biederman wrote: > Yours looks more complete then my test patch so: > > From: "Mike Miller (OS Dev)" <[EMAIL PROTECTED]> writes: > > Found what seems the problem with our vectors being listed backward. In > drivers/pci/msi.c we should be using list_add_tail rather than list_add to > preserve the ordering across various kernels. Please consider this for > inclusion. > > Signed-off-by: "Eric W. Biederman" <[EMAIL PROTECTED]> Screwed-up-by: Michael Ellerman <[EMAIL PROTECTED]> The sad part is my earlier patches did use list_add_tail(), doh. :( Thanks for debugging it. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
Hi Linus. On Thu, 2007-05-24 at 19:10 -0700, Linus Torvalds wrote: > > On Fri, 25 May 2007, Nigel Cunningham wrote: > > > > First, let me agree with you that for the atomic copy itself, the > > freezer is unnecessary. Disabling irqs and so on is enough to ensure the > > atomic copy is atomic. I don't think any of us are arguing with you > > there. > > First off, realize that the problem actually happens during > suspend-to-ram. > > Think about that for a second. > > In fact, think about it for a _loong_ time. Because dammit, people seem to > have a really hard time even realizing this. > > There is no "atomic copy". > > There is no "checkpointing". > > There is no "spoon". > > > Hope this helps. > > Hope _the_above_ helps. Why is it so hard for people to accept that > suspend-to-ram shouldn't break because of some IDIOTIC issues with disk > snapshots? > > And why do you people _always_ keep mixing the two up? It does. Sorry. I didn't read enough of the context. To answer the question, I guess the answer is that although they're different creatures, they have similarities. This is one of them, which is why I could make the mistake I did. Nothing in the issue being discussed was unique to suspend-to-ram. Perhaps we (or at least I) focus too much on the similarities, but that doesn't mean they're not there. Regards, Nigel signature.asc Description: This is a digitally signed message part
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
On Fri, 25 May 2007, Nigel Cunningham wrote: > > First, let me agree with you that for the atomic copy itself, the > freezer is unnecessary. Disabling irqs and so on is enough to ensure the > atomic copy is atomic. I don't think any of us are arguing with you > there. First off, realize that the problem actually happens during suspend-to-ram. Think about that for a second. In fact, think about it for a _loong_ time. Because dammit, people seem to have a really hard time even realizing this. There is no "atomic copy". There is no "checkpointing". There is no "spoon". > Hope this helps. Hope _the_above_ helps. Why is it so hard for people to accept that suspend-to-ram shouldn't break because of some IDIOTIC issues with disk snapshots? And why do you people _always_ keep mixing the two up? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
Hi Linus. On Thu, 2007-05-24 at 17:37 -0700, Linus Torvalds wrote: > > On Fri, 25 May 2007, Pavel Machek wrote: > > > > 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO > > PEOPLE FOR FIVE YEARS NOW. > > And people aren't listening. Have you thought about _why_? > > The thing is, it should just work. Even without pre-loading. > > > Imageine we killed freezer. Also imagine Romano has IDE card his > > PCMCIA slot. Kaboom, we solved nothing. > > Don't be silly. We solved it. The firmware has to be loadable from > somewhere else, since otherwise his IDE card wouldn't have been accessible > in the first place! > > So all your arguments are just bogus crap. Let me see if I can help. I'll probably fail miserably, but I can only try :) First, let me agree with you that for the atomic copy itself, the freezer is unnecessary. Disabling irqs and so on is enough to ensure the atomic copy is atomic. I don't think any of us are arguing with you there. Where we see the problem is with what happens after the atomic copy is made. The problem is that the atomic copy includes struct inodes, dnodes and such like - an in memory representation of the state of mounted filesystems. Imagine that, post atomic copy, we don't have the freezer. Processes can then make on-disk changes to these mounted filesystems in the time before we complete saving the image and powering down. If, at resume time, we then restore the atomic copy, we have a mismatch between what the in-memory data structures say and what the on-disk data says. This leads to corruption. How to avoid? Well, there are only two options as far as I can see. We either stop those changes occurring in the first place, or we make them undoable. Freezing processes, and/or filesystems would be the first path, checkpointing the second. So, as far as I can see, we're stuck with freezing processes at least until checkpointing is implemented. I have to admit though, that even if checkpointing was implemented, I'd like to see freezing processes remain. The image gets written faster if we don't have to compete for cpu and i/o. It also allows us to do a fuller image of memory than is otherwise possible (Yes, I know some people don't care for full images, but others of us have usage patterns that make the system far more useable if a full image is kept, or simply prefer to have our machines as if the power had never gone away). Without processes freezing, I'd have to work a lot harder to find a way to do that full image. The simplest way would probably be to carry the freezer code myself. (Yeah, I'm reconciled to the idea of never getting Suspend2 merged. I'd like it to happen, but won't hold my breath. Someone needs to break your suspend-to-ram or battery so you see the use for hibernation :>). Hope this helps. Nigel signature.asc Description: This is a digitally signed message part
Re: [RFC 2/5] inode reservation v0.1 (ext4 kernel patch)
On Thu, May 24, 2007 at 06:26:26PM +0200, Jan Engelhardt wrote: > >On May 24 2007 22:47, coly wrote: >> >>Dave, >> >>Yes, I found all TABs gone when I received the mail. When I post next >>version of the patch, I will test to send to me first :-) >> >>Thanks for your information. > >Blame Gmail. > > > Jan I am using gmail too. That's not gmail's fault, I think your email client sucks. So which email client are you using, coly? I recommend mutt to you. ;) Have fun! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2-mm1 SLUB oops
On Fri, 25 May 2007, young dave wrote: > > Reboot with slub_debug as a kernel parameter please. > > Yes, I will enable slub_debug as boot parameter, but it doesn't occur > definitely. > > I will report the info if it arrive again ASAP. Thank you. This looks like something overwrote a slab object after it was freed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] KVM: Suspend and cpu hotplug fixes
On Thu, 2007-05-24 at 20:10 +0800, Avi Kivity wrote: > The following patchset makes kvm more robust wrt cpu hotunplug, and > makes suspend-to-ram actually work. Suspend-to-disk benefits from > the cpu hotunplug improvements as well. > > The major issue is that KVM wants to disable the virtualization > extensions at a point in time when no user processes are schedulable > on the victim cpu. No current notifier exists, so a new one, > CPU_DYING, > is added for the purpose. > > Should there be no objections, I will submit this patchset for > inclusion > in 2.6.22, and backport it to 2.6.21.stable. Is it possible disabling kvm can be done at the begining of play_dead? take_cpu_done is designed to run fast. Thanks, Shaohua - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1: IDE compile error
Alan Cox wrote: >> The question I'm asking is: do you think it's better to remove this from >> hd.c, or do you think it's better to add it back boot code BIOS >> detection (and take the risk of poking an ST-506 disk with legacy data >> with parameters which may belong to another disk -- keep in mind this >> can permanently damage an ST-506 disk)? > > To set it up the user will have to know the parameters and have typed > them into the BIOS (if it even has an option for it). I see no problem Sorry, see no problem which way? My concern here is with getting incorrect data, not getting no data. The BIOS probe amounts to pulling data out of two tables (INT 0x41/0x46, corresponding to BIOS drives 0x80 and 0x81 -- the EDD 1.1 spec is quite specific that if implemented they follow the BIOS drive numbers, not the ATA port addresses), and hoping that they actually match the drives that hd.c uses. That scares me, since we're talking about old legacy data here. I'm not concerned with what's easy, I'm concerned with what's the right thing to do. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git patches] libata fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c |1 +
drivers/ata/libata-core.c |4 +-
drivers/ata/pata_hpt3x2n.c |4 +-
drivers/ata/pata_sis.c | 46 ++--
drivers/ata/pata_via.c | 29 +++
5 files changed, 57 insertions(+), 27 deletions(-)
Alan Cox (3):
hpt3x2n: Correct revision boundary
pata_sis: Fix and clean up some timing setups
pata_via: Handle laptops via DMI
Tejun Heo (3):
ata_piix: add short 40c quirk for Acer Aspire 2030, take #2
libata: don't consider 0xff as port empty if SStatus is available
libata: -ENODEV during prereset isn't an error
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 0458811..9c07b88 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -578,6 +578,7 @@ static const struct ich_laptop ich_laptop[] = {
{ 0x27DF, 0x0005, 0x0280 }, /* ICH7 on Acer 5602WLMi */
{ 0x27DF, 0x1025, 0x0110 }, /* ICH7 on Acer 3682WLMi */
{ 0x27DF, 0x1043, 0x1267 }, /* ICH7 on Asus W5F */
+ { 0x24CA, 0x1025, 0x0061 }, /* ICH4 on ACER Aspire 2023WLMi */
/* end marker */
{ 0, }
};
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index a6de57e..3ca9c61 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3022,7 +3022,7 @@ int ata_wait_ready(struct ata_port *ap, unsigned long
deadline)
if (!(status & ATA_BUSY))
return 0;
- if (status == 0xff)
+ if (!ata_port_online(ap) && status == 0xff)
return -ENODEV;
if (time_after(now, deadline))
return -EBUSY;
@@ -3368,7 +3368,7 @@ int ata_std_prereset(struct ata_port *ap, unsigned long
deadline)
*/
if (!(ap->flags & ATA_FLAG_SKIP_D2H_BSY) && !ata_port_offline(ap)) {
rc = ata_wait_ready(ap, deadline);
- if (rc) {
+ if (rc && rc != -ENODEV) {
ata_port_printk(ap, KERN_WARNING, "device not ready "
"(errno=%d), forcing hardreset\n", rc);
ehc->i.action |= ATA_EH_HARDRESET;
diff --git a/drivers/ata/pata_hpt3x2n.c b/drivers/ata/pata_hpt3x2n.c
index f25154a..e947433 100644
--- a/drivers/ata/pata_hpt3x2n.c
+++ b/drivers/ata/pata_hpt3x2n.c
@@ -521,8 +521,8 @@ static int hpt3x2n_init_one(struct pci_dev *dev, const
struct pci_device_id *id)
/* 371N if rev > 1 */
break;
case PCI_DEVICE_ID_TTI_HPT372:
- /* 372N if rev >= 1*/
- if (class_rev == 0)
+ /* 372N if rev >= 2*/
+ if (class_rev < 2)
return -ENODEV;
break;
case PCI_DEVICE_ID_TTI_HPT302:
diff --git a/drivers/ata/pata_sis.c b/drivers/ata/pata_sis.c
index f223126..ec3ae93 100644
--- a/drivers/ata/pata_sis.c
+++ b/drivers/ata/pata_sis.c
@@ -73,14 +73,14 @@ static int sis_short_ata40(struct pci_dev *dev)
}
/**
- * sis_port_base - return PCI configuration base for dev
+ * sis_old_port_base - return PCI configuration base
for dev
* @adev: device
*
* Returns the base of the PCI configuration registers for this port
* number.
*/
-static int sis_port_base(struct ata_device *adev)
+static int sis_old_port_base(struct ata_device *adev)
{
return 0x40 + (4 * adev->ap->port_no) + (2 * adev->devno);
}
@@ -211,7 +211,7 @@ static void sis_set_fifo(struct ata_port *ap, struct
ata_device *adev)
static void sis_old_set_piomode (struct ata_port *ap, struct ata_device *adev)
{
struct pci_dev *pdev= to_pci_dev(ap->host->dev);
- int port = sis_port_base(adev);
+ int port = sis_old_port_base(adev);
u8 t1, t2;
int speed = adev->pio_mode - XFER_PIO_0;
@@ -248,7 +248,7 @@ static void sis_old_set_piomode (struct ata_port *ap,
struct ata_device *adev)
static void sis_100_set_piomode (struct ata_port *ap, struct ata_device *adev)
{
struct pci_dev *pdev= to_pci_dev(ap->host->dev);
- int port = sis_port_base(adev);
+ int port = sis_old_port_base(adev);
int speed = adev->pio_mode - XFER_PIO_0;
const u8 actrec[] = { 0x00, 0x67, 0x44, 0x33, 0x31 };
@@ -328,7 +328,7 @@ static void sis_old_set_dmamode (struct ata_port *ap,
struct ata_device *adev)
{
struct pci_dev *pdev= to_pci_dev(ap->host->dev);
int speed = adev->dma_mode - XFER_MW_DMA_0;
- int drive_pci = sis_port_base(adev);
+ int drive_pci = sis_old_port_base(adev);
u16 timing;
const u16
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
On Fri, 25 May 2007, Pavel Machek wrote: > > 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO > PEOPLE FOR FIVE YEARS NOW. And people aren't listening. Have you thought about _why_? The thing is, it should just work. Even without pre-loading. > Imageine we killed freezer. Also imagine Romano has IDE card his > PCMCIA slot. Kaboom, we solved nothing. Don't be silly. We solved it. The firmware has to be loadable from somewhere else, since otherwise his IDE card wouldn't have been accessible in the first place! So all your arguments are just bogus crap. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2-mm1 SLUB oops
Hi, Reboot with slub_debug as a kernel parameter please. Yes, I will enable slub_debug as boot parameter, but it doesn't occur definitely. I will report the info if it arrive again ASAP. Regards dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1: IDE compile error
> The question I'm asking is: do you think it's better to remove this from > hd.c, or do you think it's better to add it back boot code BIOS > detection (and take the risk of poking an ST-506 disk with legacy data > with parameters which may belong to another disk -- keep in mind this > can permanently damage an ST-506 disk)? To set it up the user will have to know the parameters and have typed them into the BIOS (if it even has an option for it). I see no problem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI device problem - MMCONFIG, cannot allocate resource region, resource collisions
Ivan Kokshaysky wrote:
Actually, it should be something like this (also untested).
Ivan.
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1690,6 +1690,14 @@ static void __devinit quirk_p64h2_1k_io(struct pci_dev
*dev)
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1460,
quirk_p64h2_1k_io);
+/* Give unknown D-Link network adapters a proper class */
+static void __devinit quirk_dlink_unknown(struct pci_dev *dev)
+{
+ if ((dev->class >> 8) == PCI_CLASS_NOT_DEFINED)
+ dev->class = PCI_CLASS_NETWORK_ETHERNET << 8;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_DLINK, 0x4901, quirk_dlink_unknown);
Ivan,
I tried a couple variations of the patch above. It got me further,
but I still wasn't getting the base address assigned properly. I
suspected a bad card, so I tried another one I have here. It is likely
that I have been fighting with bad hardware all this time. The other
card has a known device ID, a proper class code, and does not give
resource allocation errors. I have an e-mail into D-Link to inquire
about the buggy card.
I appreciate both yours and Jesse's help to troubleshoot this problem.
Best Regards,
Wayne Sherman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1: IDE compile error
Alan Cox wrote: > I believe the technical description for the comment is "bullshit" 8) > > Almost all MFM controllers and RLL controllers will only run at the > standard primary and secondary ATA address. Yes, but that doesn't (necessarily) apply to the controller that is likely to be the primary controller in a modern system. The whole point is that what the BIOS considers primary isn't necessarily tied to the standard ATA addresses anymore, with SATA controllers being primary. The question I'm asking is: do you think it's better to remove this from hd.c, or do you think it's better to add it back boot code BIOS detection (and take the risk of poking an ST-506 disk with legacy data with parameters which may belong to another disk -- keep in mind this can permanently damage an ST-506 disk)? > Given the intended use of the driver today I don't see a big problem in > requiring "hd=" although you have to question the point of this boot code > rewrite when it seems primarily to be removing features I've been trying to remove features that are obsolete and/or broken. I don't have access to this particular ancient hardware, nor any system that can even host them. It's very easy to add the stuff back in the boot code; it's a much more tricky/annoying question if one *should* do so. That's part of a rewrite/cleanup. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1: IDE compile error
> > It thus needs fixing not removing. > > > > Opinions, anyone (especially Alan): > > http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=commitdiff;h=369f16fdd423d79640c4390915e6ab71189cb497 I believe the technical description for the comment is "bullshit" 8) Almost all MFM controllers and RLL controllers will only run at the standard primary and secondary ATA address. Given the intended use of the driver today I don't see a big problem in requiring "hd=" although you have to question the point of this boot code rewrite when it seems primarily to be removing features Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] use printk.time option, drop time/notime
From: Randy Dunlap <[EMAIL PROTECTED]>
Andrew, please drop add-notime-boot-option.patch
and use this patch instead...
Allow printk_time to be enabled or disabled at boot time.
Previously it could be enabled only, but not disabled.
Change printk_time from an int to a bool since that's what it is.
Make its logical (exposed) name just be "time" (was "printk_time").
Note: Changes kernel boot option syntax from "time" to "printk.time=value".
Since printk_time is declared as a module_param, it can also be
changed at run-time by modifying
/sys/module/printk/parameters/time
to a value of 1/Y/y to enabled it or 0/N/n to disable it.
Since printk_time is declared as a module_param, its value can also
be set at boot-time by using
linux printk.time=
Drop the "time" boot option and its __setup() functions.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |5 +++--
kernel/printk.c | 12 +---
2 files changed, 4 insertions(+), 13 deletions(-)
--- linux-2622-rc2g5.orig/Documentation/kernel-parameters.txt
+++ linux-2622-rc2g5/Documentation/kernel-parameters.txt
@@ -1406,6 +1406,9 @@ and is between 256 and 4096 characters.
autoconfiguration.
Ranges are in pairs (memory base and size).
+ printk.time=Show timing data prefixed to each printk message line
+ Format: (1/Y/y=enable, 0/N/n=disable)
+
profile=[KNL] Enable kernel profiling via /proc/profile
Format: [schedule,]
Param: "schedule" - profile schedule points.
@@ -1805,8 +1808,6 @@ and is between 256 and 4096 characters.
thash_entries= [KNL,NET]
Set number of hash buckets for TCP connection
- timeShow timing data prefixed to each printk message line
-
clocksource=[GENERIC_TIME] Override the default clocksource
Override the default clocksource and use the clocksource
with the name specified.
--- linux-2622-rc2g5.orig/kernel/printk.c
+++ linux-2622-rc2g5/kernel/printk.c
@@ -449,17 +449,7 @@ static int printk_time = 1;
#else
static int printk_time = 0;
#endif
-module_param(printk_time, int, S_IRUGO | S_IWUSR);
-
-static int __init printk_time_setup(char *str)
-{
- if (*str)
- return 0;
- printk_time = 1;
- return 1;
-}
-
-__setup("time", printk_time_setup);
+module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
__attribute__((weak)) unsigned long long printk_clock(void)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1: IDE compile error
Alan Cox wrote: > > hd.c can drive MFM and RLL disks and drivers/ide cannot. Although it > really wants burying further down the config tree the ability to read MFM > and RLL disks when recovering ancient data is useful and people do > actually use this driver now and then rescuing stuff like twenty year old > datasets. > > It thus needs fixing not removing. > Opinions, anyone (especially Alan): http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=commitdiff;h=369f16fdd423d79640c4390915e6ab71189cb497 -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make prepare_namespace() wait for devices
On Thu, 24 May 2007 14:21:35 +0200
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> + /* wait for any asynchronous scanning to complete */
> + if ((ROOT_DEV == 0) && root_wait) {
> + printk(KERN_INFO "Waiting for root device %s...\n",
> + saved_root_name);
> + do {
> + while (driver_probe_done() != 0)
> + msleep(100);
> + ROOT_DEV = name_to_dev_t(saved_root_name);
> + if (ROOT_DEV == 0)
> + msleep(100);
> + } while (ROOT_DEV == 0);
> + }
This seems overly complex. Can't we simply do
while (driver_probe_done() || ROOT_DEV == 0)
msleep(100);
?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Display Intel Dynamic Acceleration feature in /proc/cpuinfo
Pallipadi, Venkatesh wrote: > The way new Intel features are being exposed in CPUID is kind of > changing. Changing is a VERY BAD THING when it comes to something like CPUID. > Now we have different CPUID leafs for different kind of features with > each of them growing much slowly. > I mean, there is > monitor-mwait related features in CPUID 5 > powermanagement features in CPUID 6 EAX, ECX > Perfmon features in CPUID 10 Again, this is bad. > This does not fit well with the way we use the feature words in Linux. No, it doesn't... nor for anyone else who wants a compact representation of this kind of information. If they grow slowly from the bottom, I guess we could simply allocate space in the vector byte by byte instead. Either way, it means more work whenever anything has to change. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sky2/pci issues on Gigabyte
On Thu, 24 May 2007 16:04:40 -0700 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > -00: 86 80 47 28 07 00 10 00 02 00 04 06 08 00 81 00 > > +00: 86 80 47 28 07 04 10 00 02 00 04 06 08 00 81 00 > ^--- INTX disable bit > Vista isn't enabling MSI, Linux is. > Try "nomsi"? I had noticed that Vista wasn't using MSI for any devices and I tried booting with pci=nomsi in addition to building the kernel without MSI enabled (just in case there might somehow be a difference). I see I should have mentioned it, but it had no effect on the problem. The device gets IRQ 16 in Linux without MSI and it still croaks with the same messages. Mike Houston - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] m68k: Enable arbitary speed tty support
On Thu, 24 May 2007 13:40:15 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > Alan, I'm all dazed and confused about these patches: > > arm-enable-arbitary-speed-tty-ioctls-and-split.patch > arm26-enable-arbitary-speed-tty-ioctls-and-split.patch > ia64-arbitary-speed-tty-ioctl-support.patch > xtensa-enable-arbitary-tty-speed-setting-ioctls.patch > h8300-enable-arbitary-speed-tty-port-setup.patch > m32r-enable-arbitary-speed-tty-rate-setting.patch > etrax-enable-arbitary-speed-setting-on-tty-ports.patch > v850-enable-arbitary-speed-tty-ioctls.patch > lots-of-architectures-enable-arbitary-speed-tty-support.patch > > are there any interdependencies here, or can the various patches > go into the various trees in random order without ill effects? The only ordering requirement is that the patch which adds all the termios2 structures goes first. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Display Intel Dynamic Acceleration feature in /proc/cpuinfo
>-Original Message- >From: H. Peter Anvin [mailto:[EMAIL PROTECTED] >Sent: Thursday, May 24, 2007 4:23 PM >To: Pallipadi, Venkatesh >Cc: Andi Kleen; Dave Jones; Andrew Morton; Brown, Len; linux-kernel >Subject: Re: [PATCH] Display Intel Dynamic Acceleration >feature in /proc/cpuinfo > >Pallipadi, Venkatesh wrote: >> >> Yes. But it only has 3 features defined right now. 2 in EAX >and one in >> ECX. Should I use 2 new words for these bits or just use the software >> defined bits as in my earlier patch? >> > >Oh for heaven's sake. Could you please do the world a favour and shoot >your CPUID architect? > >The real answer depends on how you expect it to grow in the future. >Intel has a piss-poor record at being consistent in this matter, which >speaks for a more ad hoc approach, but if there really is a sane growth >path going forward, then go ahead and define two new words. > The way new Intel features are being exposed in CPUID is kind of changing. Now we have different CPUID leafs for different kind of features with each of them growing much slowly. I mean, there is monitor-mwait related features in CPUID 5 powermanagement features in CPUID 6 EAX, ECX Perfmon features in CPUID 10 This does not fit well with the way we use the feature words in Linux. Probably it is better to have one new word for new Intel features and add bits from all CPUIDs as they come. I will take a look at all the other fields and try for a better solution than adding new words for different CPUIDs like above. Thanks, Venki - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH netdev] "wrong timeout value" in sk_wait_data() v2
From: Vasily Averin <[EMAIL PROTECTED]> Date: Thu, 24 May 2007 09:23:14 +0400 > sys_setsockopt() do not check properly timeout values for > SO_RCVTIMEO/SO_SNDTIMEO, for example it's possible to set negative timeout > values. POSIX do not defines behaviour for sys_setsockopt in case negative > timeouts, but requires that setsockopt() shall fail with -EDOM if the send and > receive timeout values are too big to fit into the timeout fields in the > socket > structure. > In current implementation negative timeout can lead to error messages like > "schedule_timeout: wrong timeout value". > > Proposed patch: > - checks tv_usec and returns -EDOM if it is wrong > - do not allows to set negative timeout values (sets 0 instead) and outputs > ratelimited information message about such attempts. > > Signed-Off-By:Vasily Averin <[EMAIL PROTECTED]> Thank you for this bug fix, patch applied. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] AFS: Add a function to excise a rejected write from the pagecache
On Fri, 2007-05-25 at 00:18 +0100, David Howells wrote: > Trond Myklebust <[EMAIL PROTECTED]> wrote: > > > No. If the write fails, then NFS will mark the mapping as invalid and > > attempt to call invalidate_inode_pages2() at the earliest possible > > moment. > > Will it erase *all* unwritten writes? Or is that what launder_page() is for? Yes. launder_page() will flush out any writes that may have raced with the call to invalidate_inode_pages2() (you're supposed to attempt to flush them out before you call the latter). > How do you deal with pages that were in the process of being written out when > that particular write was rejected? Do you just summarily clear PG_writeback > and hope no-one else looks at the page until invalidate_inode_pages2() gets > around to excising it? Or do you have a better way? All I do is to protect new calls to read() and write() with a call to check if the page cache needs invalidating. As I said earlier, you cannot avoid the race. At best you can reduce the window of opportunity, and so I'd argue that if you can't do that cheaply, then it isn't worth it. > > I'm adding in a patch to defer marking the page as uptodate until the > > write is successful in cases where NFS is writing a pristine page. > > That sounds reasonable, though it doesn't help in the case I'm looking at. Do > you also munge i_size if the write fails? I just mark the inode as needing revalidation so that we update the size on the next read()/write()/getattr(). That won't stop any existing append writes from punching ugly holes into the file, but trying to recover from that sort of thing would be _really_ painful! > > As for pages that are already marked as uptodate, well you already have > > a race: you have deferred the page write, and so other processes may > > already have read the rejected data before you tried to write it out. > > Yeah, I know, and that's very difficult to deal with without some formal > transaction rollback mechanism. I think that the best I can do is to discard > the dodgy data that I've got lurking in the pagecache, but I still have to > deal with writes made by other users to that file after the rejected write. > > There isn't a perfect way of dealing with it, given the circumstances. Agreed. Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Display Intel Dynamic Acceleration feature in /proc/cpuinfo
Alan Cox wrote:
>
> The older AMD docs (CPU rev guide) list bit 31 of both 0x8001 and
> 0x0001 as 3dnow
>
> All their example code/docs say to use 0x8001
>
I don't have access to any AM2 systems, but the bit is definitely set on
socket 939 Athlon X2 ("model 43").
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Display Intel Dynamic Acceleration feature in /proc/cpuinfo
On Thu, 24 May 2007 18:41:54 -0400 Dave Jones <[EMAIL PROTECTED]> wrote: > On Thu, May 24, 2007 at 03:14:39PM -0700, H. Peter Anvin wrote: > > > pbe collides with abuse by at least two vendors (AMD and > > Cyrix/Centaur/VIA) of this bit for 3DNow. > > Unless I'm mistaken, > > pbe comes from cpuid level 1 > > 3dnow comes from cpuid level 0x8001 > though I did notice that amd have it in edx, whilst via have it in ecx > curiously. The older AMD docs (CPU rev guide) list bit 31 of both 0x8001 and 0x0001 as 3dnow All their example code/docs say to use 0x8001 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] AFS: Add a function to excise a rejected write from the pagecache
Andrew Morton <[EMAIL PROTECTED]> wrote: > But we already covered that? Your exciser can do an unconditional > end_page_writeback(), because it is this thread of control which did the > set_page_writeback(). So we end up with: Ah, I misunderstood what you meant. I assumed you meant to wait insted of ending. Of course, if we've decided to excise this page, it really oughtn't to get PG_writeback set again. I'll have to think about that. > Well someone needs to be taught all about this case. Question is, should > it be the VFS, or should it just be the address_space(s) which brought > this state about, and which care about it? For the most part, I think that this only applies to netfs's, and possibly not all of those, so making it fully general might be overkill. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HPT366 not enabled by kernel 2.6.21.2
Hello again! > The fix from Sergei (queued for 2.6.21.3) is here: > > http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=queue-2.6.21/hpt366-don-t-check-enablebits-for-hpt36x.patch;h=0833e0a37e23ed103a18ca93684201e1cb94a0a9 > > [ it has already been merged into 2.6.22 tree ] Thank you. The patch works for me. HPT366: IDE controller at PCI slot :02:0a.0 ACPI: PCI Interrupt :02:0a.0[A] -> GSI 18 (level, low) -> IRQ 18 HPT366: chipset revision 1 HPT366: using 33 MHz PCI clock HPT366: 100% native mode on irq 18 ide2: BM-DMA at 0xd300-0xd307, BIOS settings: hde:pio, hdf:pio ACPI: PCI Interrupt :02:0a.1[A] -> GSI 18 (level, low) -> IRQ 18 HPT366: using 33 MHz PCI clock ide3: BM-DMA at 0xd600-0xd607, BIOS settings: hdg:pio, hdh:pio Probing IDE interface ide2... hde: TOSHIBA THNCF1G02MG, CFA DISK drive ide2 at 0xd100-0xd107,0xd202 on irq 18 -- Ciao, Pascal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove a few UMSDOS leftovers
Jesper Juhl wrote: > Ok, that makes sense. How about this version : Could you document which numbers were actually used by umsdos, instead of reserving a full block of 256? Since it's dead, it's not going to eat any more numbers. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove a few UMSDOS leftovers
On 25/05/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Jesper Juhl wrote: > Ok, that makes sense. How about this version : Could you document which numbers were actually used by umsdos, instead of reserving a full block of 256? Since it's dead, it's not going to eat any more numbers. Sure, I'll dig out that information and prepare a new patch tomorrow (need to catch some sleep right now). -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] AFS: Add a function to excise a rejected write from the pagecache
On Fri, 25 May 2007 00:08:43 +0100 David Howells <[EMAIL PROTECTED]> wrote: > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > hm. I don't see why that race window would be a problem in practice: the > > page-exciser does a lock_page();wait_on_page_writeback() as normal, then > > proceeds with its business? > > No. The page-exciser ends (cancels) PG_writeback, not waits for it (something > has to clear the flag). The problem is that the truncation routines may be > sat there holding a lock on the page whilst waiting for PG_writeback to go > away - so we have to clear PG_writeback before we can think about getting > PG_lock:-( But we already covered that? Your exciser can do an unconditional end_page_writeback(), because it is this thread of control which did the set_page_writeback(). So we end up with: end_page_writeback(page); lock_page(page); wait_on_page_writeback(page); > > But given that this doesn't work right for some reason, can we use PG_error > > and then handle that appropriately in the filesystem's ->prepare_write() and > > ->page_mkwrite()? > > Possibly, though I'd rather they didn't see such a page. Well someone needs to be taught all about this case. Question is, should it be the VFS, or should it just be the address_space(s) which brought this state about, and which care about it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Display Intel Dynamic Acceleration feature in /proc/cpuinfo
Pallipadi, Venkatesh wrote: > > Yes. But it only has 3 features defined right now. 2 in EAX and one in > ECX. Should I use 2 new words for these bits or just use the software > defined bits as in my earlier patch? > Oh for heaven's sake. Could you please do the world a favour and shoot your CPUID architect? The real answer depends on how you expect it to grow in the future. Intel has a piss-poor record at being consistent in this matter, which speaks for a more ad hoc approach, but if there really is a sane growth path going forward, then go ahead and define two new words. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] CFS scheduler, -v12
Siddha, Suresh B wrote: On Thu, May 24, 2007 at 12:43:58AM -0700, Peter Williams wrote: Peter Williams wrote: The relevant code, find_busiest_group() and find_busiest_queue(), has a lot of code that is ifdefed by CONFIG_SCHED_MC and CONFIG_SCHED_SMT and, as these macros were defined in the kernels I was testing with, I built a kernel with these macros undefined and reran my tests. The problems/anomalies were not present in 10 consecutive tests on this new kernel. Even better on the few occasions that a 3/1 split did occur it was quickly corrected to 2/2 and top was reporting approx 49% of CPU for all spinners throughout each of the ten tests. So all that is required now is an analysis of the code inside the ifdefs to see why it is causing a problem. Further testing indicates that CONFIG_SCHED_MC is not implicated and it's CONFIG_SCHED_SMT that's causing the problem. This rules out the code in find_busiest_group() as it is common to both macros. I think this makes the scheduling domain parameter values the most likely cause of the problem. I'm not very familiar with this code so I've added those who've modified this code in the last year or so to the address of this e-mail. What platform is this? I remember you mentioned its a 2 cpu box. Is it dual core or dual package or one with HT? It's a single CPU HT box i.e. 2 virtual CPUs. "cat /proc/cpuinfo" produces: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 3 model name : Intel(R) Pentium(R) 4 CPU 3.20GHz stepping: 4 cpu MHz : 3201.145 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pni monitor ds_cpl cid xtpr bogomips: 6403.97 clflush size: 64 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 3 model name : Intel(R) Pentium(R) 4 CPU 3.20GHz stepping: 4 cpu MHz : 3201.145 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pni monitor ds_cpl cid xtpr bogomips: 6400.92 clflush size: 64 Peter -- Peter Williams [EMAIL PROTECTED] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
On Thu 2007-05-24 20:16:38, Henrique de Moraes Holschuh wrote: > On Fri, 25 May 2007, Pavel Machek wrote: > > My proposed solution is "fix pcmcia to load firmware before suspend > > even starts" > > s/pcmcia/all drivers that load firmware/ if you are going to go that way. I'm not "going that way". It always was that way. If driver tries to load firmware during suspend, it will deadlock. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
Hi! > > > Why the HELL cannot you realize that kernel threads are different? > > > > Ugh? We are talking about request_firmware() here, right? That's > > calling userland helper to load the firmware...? Looks like USER > > thread to me. > > Right. And if we had had the nice old /sbin/hotplug thing, it would all > have worked fine - because it would just have done an execve(), and things > would be happy. > > But people screwed that up too, and now udevd is an undebuggable user > thread. Shit happens. See my other email about why even user threads can > probably not be frozen, and the whole freezer thing is misdesigned. I'm not ready to redesign udevd :-(. Your other mail proves that either 1) we can stop freezing udevd, and pray udevd does not become confused by "half hardware not available" while system is being suspended _or_ 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO PEOPLE FOR FIVE YEARS NOW. > And I repeat: PowerPC had working and stable suspend five _years_ ago, > without any of that freezing crud. We should rip it out. Imageine we killed freezer. Also imagine Romano has IDE card his PCMCIA slot. Kaboom, we solved nothing. We'll either deadlock or do something very nasty to the filesystem on the IDE card ... because we'll have udevd running, but fs on IDE card not available. That does not work. "Not freezing udevd" only makes problems hard to trigger, see? Now... "should we rip freezer out of suspend" is a different story. It does not help _here_. We still need to load the firmware during _suspend_. [Can you ack this point and we can have nice flamewar about ripping out freezer?] But I'd actually like to get rid of freezer for suspend (I believe it is needed for hibernation) -- we'll need to do similar that for runtime suspending of devices, anyway. But "just rip it out" will cause some hard to debug breakage, we need to somehow audit the drivers, or ask driver writers to audit them or something. ... and yes, ripping freezer out _will_ make drivers more complex. Your video capture card will now have to deal with "ouch, I was already told to suspend, and now someone is calling my ioctls() ?!". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] AFS: Add a function to excise a rejected write from the pagecache
Trond Myklebust <[EMAIL PROTECTED]> wrote: > No. If the write fails, then NFS will mark the mapping as invalid and > attempt to call invalidate_inode_pages2() at the earliest possible > moment. Will it erase *all* unwritten writes? Or is that what launder_page() is for? How do you deal with pages that were in the process of being written out when that particular write was rejected? Do you just summarily clear PG_writeback and hope no-one else looks at the page until invalidate_inode_pages2() gets around to excising it? Or do you have a better way? > I'm adding in a patch to defer marking the page as uptodate until the > write is successful in cases where NFS is writing a pristine page. That sounds reasonable, though it doesn't help in the case I'm looking at. Do you also munge i_size if the write fails? > As for pages that are already marked as uptodate, well you already have > a race: you have deferred the page write, and so other processes may > already have read the rejected data before you tried to write it out. Yeah, I know, and that's very difficult to deal with without some formal transaction rollback mechanism. I think that the best I can do is to discard the dodgy data that I've got lurking in the pagecache, but I still have to deal with writes made by other users to that file after the rejected write. There isn't a perfect way of dealing with it, given the circumstances. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove a few UMSDOS leftovers
On Friday 25 May 2007 01:07:17 H. Peter Anvin wrote:
> Jesper Juhl wrote:
> > The UMSDOS filesystem was removed back in 2.6.11, but some tiny bits
> > stuck around. This patch removes the few leftovers.
> > The only things left behind after this are the entries in the CREDITS file.
> >
> > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
> > ---
[snip]
> > --- a/Documentation/ioctl-number.txt
> > +++ b/Documentation/ioctl-number.txt
> > @@ -67,7 +67,6 @@ Code Seq#Include FileComments
> > 0x00 00-1F linux/wavefront.h conflict!
> > 0x02 all linux/fd.h
> > 0x03 all linux/hdreg.h
> > -0x04 all linux/umsdos_fs.h
> > 0x06 all linux/lp.h
> > 0x09 all linux/md.h
> > 0x12 all linux/fs.h
>
> NAK!
>
> We should at least document which ioctl numbers have been burned, since
> they SHOULD NOT be reused.
>
Ok, that makes sense. How about this version :
The UMSDOS filesystem was removed back in 2.6.11, but some tiny bits
stuck around. This patch removes the few leftovers.
The only things left behind after this are the entries in the CREDITS file
and the ioctl number in Documentation/ioctl-number.txt as documentation.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
Documentation/ioctl-number.txt |2 +-
arch/arm26/defconfig |1 -
arch/cris/arch-v10/defconfig |1 -
arch/um/config.release |1 -
include/linux/ncp_fs.h |2 --
5 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
index 3de7d37..4413866 100644
--- a/Documentation/ioctl-number.txt
+++ b/Documentation/ioctl-number.txt
@@ -67,7 +67,7 @@ Code Seq#Include FileComments
0x00 00-1F linux/wavefront.h conflict!
0x02 all linux/fd.h
0x03 all linux/hdreg.h
-0x04 all linux/umsdos_fs.h
+0x04 all linux/umsdos_fs.h Dead, but don't reuse this ioctl number.
0x06 all linux/lp.h
0x09 all linux/md.h
0x12 all linux/fs.h
diff --git a/arch/arm26/defconfig b/arch/arm26/defconfig
index c4a8970..2b7d44b 100644
--- a/arch/arm26/defconfig
+++ b/arch/arm26/defconfig
@@ -248,7 +248,6 @@ CONFIG_I2C_CHARDEV=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_FAT_FS is not set
# CONFIG_MSDOS_FS is not set
-# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
diff --git a/arch/cris/arch-v10/defconfig b/arch/cris/arch-v10/defconfig
index 2a3411e..710c20b 100644
--- a/arch/cris/arch-v10/defconfig
+++ b/arch/cris/arch-v10/defconfig
@@ -429,7 +429,6 @@ CONFIG_NET_ETHERNET=y
# CONFIG_BFS_FS is not set
# CONFIG_FAT_FS is not set
# CONFIG_MSDOS_FS is not set
-# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
diff --git a/arch/um/config.release b/arch/um/config.release
index fc68bcb..aba42f8 100644
--- a/arch/um/config.release
+++ b/arch/um/config.release
@@ -200,7 +200,6 @@ CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
-CONFIG_UMSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_EFS_FS=m
# CONFIG_JFFS_FS is not set
diff --git a/include/linux/ncp_fs.h b/include/linux/ncp_fs.h
index 83e39eb..88766e4 100644
--- a/include/linux/ncp_fs.h
+++ b/include/linux/ncp_fs.h
@@ -148,8 +148,6 @@ struct ncp_nls_ioctl
#include
#include
-/* undef because public define in umsdos_fs.h (ncp_fs.h isn't public) */
-#undef PRINTK
/* define because it is easy to change PRINTK to {*}PRINTK */
#define PRINTK(format, args...) printk(KERN_DEBUG format , ## args)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
On Fri, 25 May 2007, Pavel Machek wrote: > My proposed solution is "fix pcmcia to load firmware before suspend > even starts" s/pcmcia/all drivers that load firmware/ if you are going to go that way. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Display Intel Dynamic Acceleration feature in /proc/cpuinfo
>-Original Message- >From: H. Peter Anvin [mailto:[EMAIL PROTECTED] >Sent: Thursday, May 24, 2007 4:04 PM >To: Pallipadi, Venkatesh >Cc: Andi Kleen; Dave Jones; Andrew Morton; Brown, Len; linux-kernel >Subject: Re: [PATCH] Display Intel Dynamic Acceleration >feature in /proc/cpuinfo > >Venki Pallipadi wrote: >> >> I can do it in intel setup function. But, the feature may >not be activated >> unless the driver is loaded. Going by the hardware capability point >> of view, we can do it in setup function. >> >> The feature appears in CPUID 6 (called Power Management >Leaf) instead of >> regular CPUID 1 features. >> > >This sounds like it should be a new CPUID word? > Yes. But it only has 3 features defined right now. 2 in EAX and one in ECX. Should I use 2 new words for these bits or just use the software defined bits as in my earlier patch? Thanks, Venki - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Display Intel Dynamic Acceleration feature in /proc/cpuinfo
Dave Jones wrote: > On Thu, May 24, 2007 at 03:51:31PM -0700, H. Peter Anvin wrote: > > What you're describing is correct for later-level AMD/Cyrix chips, > > however, when 3DNow! was first introduced they foolishly squatted on the > > Intel-assigned CPUID flags. > > Hmm, the 3dnow spec (doc 21928e) has it in the right place, and I don't see > anything in the errata docs I have. > > Do you have more info on this? If its true, I'd like to make x86info > aware of it. I don't have exact details, but I have sent off a query to someone I know that probably *does* know the exact details. Linux does the right thing, as it will turn off bit 31 if it seems AMD, Cyrix or Centaur as the vendor ID (VIA still uses the Centaur VID apparently.) -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove a few UMSDOS leftovers
Jesper Juhl wrote: > The UMSDOS filesystem was removed back in 2.6.11, but some tiny bits > stuck around. This patch removes the few leftovers. > The only things left behind after this are the entries in the CREDITS file. > > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> > --- > > Documentation/ioctl-number.txt |1 - > arch/arm26/defconfig |1 - > arch/cris/arch-v10/defconfig |1 - > arch/um/config.release |1 - > include/linux/ncp_fs.h |2 -- > 5 files changed, 0 insertions(+), 6 deletions(-) > > diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt > index 3de7d37..f9f15bf 100644 > --- a/Documentation/ioctl-number.txt > +++ b/Documentation/ioctl-number.txt > @@ -67,7 +67,6 @@ CodeSeq#Include FileComments > 0x00 00-1F linux/wavefront.h conflict! > 0x02 all linux/fd.h > 0x03 all linux/hdreg.h > -0x04 all linux/umsdos_fs.h > 0x06 all linux/lp.h > 0x09 all linux/md.h > 0x12 all linux/fs.h NAK! We should at least document which ioctl numbers have been burned, since they SHOULD NOT be reused. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sky2/pci issues on Gigabyte
On Thu, 24 May 2007 15:48:23 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 24 May 2007, Stephen Hemminger wrote:
> >
> > Looking at the 88e8056 PCI config values:
>
> I think you're looking at the wrong device.
I didn't expect it to work, just heading for the easy to hit difference first.
>
> The ones that matter are likely the PCI-X bridge, not the device. The
> device cannot reasonably screw up DMA (unless it's really scrogged, but
> then it wouldn't work under Vista either).
PCI-E
>
> So it's much more likely to be about device 00:1c.4, which is the bridge
> to PCI bus #4:
>
> 00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
> Port 5
> Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
>
>
>
> Which I _think_ is (I tried to be careful, but..):
> So I'd look at its config space instead ("-" is Vista, "+" is Linux):
> -00: 86 80 47 28 07 00 10 00 02 00 04 06 08 00 81 00
> +00: 86 80 47 28 07 04 10 00 02 00 04 06 08 00 81 00
^--- INTX disable bit
Vista isn't enabling MSI, Linux is.
Try "nomsi"?
>
>10: 00 00 00 00 00 00 00 00 00 04 04 00 b0 b0 00 00
>
> -20: 00 f7 f0 f8 f1 ff 01 00 00 00 00 00 00 00 00 00
> +20: 00 f7 f0 f8 01 80 01 80 00 00 00 00 00 00 00 00
24: BAR5 differnence ?
>
> -30: 00 00 00 00 40 00 00 00 00 00 00 00 10 01 04 00
> +30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 04 00
3c: Assigned IRQ value
> -40: 10 80 41 01 c0 8f 00 00 00 00 10 00 11 24 11 05
> +40: 10 80 41 01 c0 8f 00 00 0f 00 11 00 11 24 11 05
48: PCI Express device control
Vista:
Linux: 000f = advanced error reports enabled
4c: PCI Express device status
Vista: 0010
Linux: 0011 = correctable error detected
Driver doesn't clear error during boot, you can do it with
setpci but it doesn't fix problem. (I do have fix bug it is
not important for this discussion).
>50: 40 00 11 30 60 05 a0 00 00 00 48 01 00 00 00 00
>60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> -80: 05 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> +80: 05 90 01 00 0c 10 e0 fe d1 41 00 00 00 00 00 00
These are the MSI setup registers which Vista isn't using.
>90: 0d a0 00 00 58 14 01 50 00 00 00 00 00 00 00 00
>a0: 01 00 02 c8 00 00 00 00 00 00 00 00 00 00 00 00
>b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
So only difference I see is MSI, and advanced error reporting
bits.
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] AFS: Add a function to excise a rejected write from the pagecache
Andrew Morton <[EMAIL PROTECTED]> wrote: > hm. I don't see why that race window would be a problem in practice: the > page-exciser does a lock_page();wait_on_page_writeback() as normal, then > proceeds with its business? No. The page-exciser ends (cancels) PG_writeback, not waits for it (something has to clear the flag). The problem is that the truncation routines may be sat there holding a lock on the page whilst waiting for PG_writeback to go away - so we have to clear PG_writeback before we can think about getting PG_lock:-( > But given that this doesn't work right for some reason, can we use PG_error > and then handle that appropriately in the filesystem's ->prepare_write() and > ->page_mkwrite()? Possibly, though I'd rather they didn't see such a page. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On 5/24/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
Hi Jiri,
On 5/24/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Well, no objections on v4l list, try to merge it. Any further comments will
> be
> appreciated.
>
> --
>
> stk11xx, add a new webcam driver
[...]
> +static int stk1125_camera_asleep(struct stk11xx *dev)
> +{
> + int value;
> +
> + stk11xx_read_registry(dev, 0x0104, );
> + stk11xx_read_registry(dev, 0x0105, );
> + stk11xx_read_registry(dev, 0x0106, );
> +
why do you read these values (this is also something in the ongoing
code I see, the read value just gets overwritten all the time)?
Well, as I tested, reads are neccesary, otherwise it doesn't work. And
when they are needed, you need to read the value to some place in
memory -- the
thanks,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Display Intel Dynamic Acceleration feature in /proc/cpuinfo
On Thu, May 24, 2007 at 03:51:31PM -0700, H. Peter Anvin wrote: > What you're describing is correct for later-level AMD/Cyrix chips, > however, when 3DNow! was first introduced they foolishly squatted on the > Intel-assigned CPUID flags. Hmm, the 3dnow spec (doc 21928e) has it in the right place, and I don't see anything in the errata docs I have. Do you have more info on this? If its true, I'd like to make x86info aware of it. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Display Intel Dynamic Acceleration feature in /proc/cpuinfo
Venki Pallipadi wrote: > > I can do it in intel setup function. But, the feature may not be activated > unless the driver is loaded. Going by the hardware capability point > of view, we can do it in setup function. > > The feature appears in CPUID 6 (called Power Management Leaf) instead of > regular CPUID 1 features. > This sounds like it should be a new CPUID word? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] LZO de/compression support - take 3
On Thu, 2007-05-24 at 15:54 -0700, Andrew Morton wrote: > On Thu, 24 May 2007 23:41:22 +0100 > Richard Purdie <[EMAIL PROTECTED]> wrote: > > > I'll not send a "rename to unsafe" patch for the LZO core until Andrew > > decides whether to drop the unsafe version entirely or not as per your > > patch. If he doesn't due to the potential use by the compressed cache > > people, I will send that patch. > > I'd have thought that a 3% performance difference isn't worth worrying > about. Especially when reclaiming that 3% costs an additional 500 lines > of pretty yukky code. 7% since the 3% applied to code that was over twice as slow in the first place! Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] smpboot: cachesize comparison fix in smp_tune_scheduling()
On Thu, 24 May 2007 12:33:23 +0200
Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> smpboot: cachesize comparison fix in smp_tune_scheduling()
>
> boot_cpu_data.x86_cache_size is signed int and can be < 0 too.
>
> PS: this function is removed from current -mm.
>
>
> Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
>
> ---
>
> diff -Nurp 2.6.22-rc2-git5-/arch/i386/kernel/smpboot.c
> 2.6.22-rc2-git5/arch/i386/kernel/smpboot.c
> --- 2.6.22-rc2-git5-/arch/i386/kernel/smpboot.c 2007-05-24
> 09:37:11.0 +0200
> +++ 2.6.22-rc2-git5/arch/i386/kernel/smpboot.c2007-05-24
> 11:48:03.0 +0200
> @@ -948,7 +948,7 @@ static void smp_tune_scheduling(void)
> if (cpu_khz) {
> cachesize = boot_cpu_data.x86_cache_size;
>
> - if (cachesize > 0)
> + if ((long)cachesize > 0)
> max_cache_size = cachesize * 1024;
> }
> }
Under what conditions can boot_cpu_data.x86_cache_size be negative?
Have negative values of boot_cpu_data.x86_cache_size been observed in
practice?
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2 and libata/shutdown
On Thu, 24 May 2007, Damien Wyart wrote: > After trying 2.6.22-rc2, I noticed the warning message from libata about > upgrading shutdown(8). First, I have two SATA disks, and get the warning for > only one of them. Second, I double-checked the source of shutdown for my > distro (Debian unstable), and do not see anything related to issueing > STANDBYNOW. It is done inside the halt binary. You can disable that STANDBYNOW by editing /etc/init.d/halt and removing the -h the initscript passes to halt. Look for a line that has something like hddown="-h". But if you do, make sure the kernel is configured to shutdown all SCSI and SATA disks first! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Remove a few UMSDOS leftovers
The UMSDOS filesystem was removed back in 2.6.11, but some tiny bits
stuck around. This patch removes the few leftovers.
The only things left behind after this are the entries in the CREDITS file.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
Documentation/ioctl-number.txt |1 -
arch/arm26/defconfig |1 -
arch/cris/arch-v10/defconfig |1 -
arch/um/config.release |1 -
include/linux/ncp_fs.h |2 --
5 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
index 3de7d37..f9f15bf 100644
--- a/Documentation/ioctl-number.txt
+++ b/Documentation/ioctl-number.txt
@@ -67,7 +67,6 @@ Code Seq#Include FileComments
0x00 00-1F linux/wavefront.h conflict!
0x02 all linux/fd.h
0x03 all linux/hdreg.h
-0x04 all linux/umsdos_fs.h
0x06 all linux/lp.h
0x09 all linux/md.h
0x12 all linux/fs.h
diff --git a/arch/arm26/defconfig b/arch/arm26/defconfig
index c4a8970..2b7d44b 100644
--- a/arch/arm26/defconfig
+++ b/arch/arm26/defconfig
@@ -248,7 +248,6 @@ CONFIG_I2C_CHARDEV=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_FAT_FS is not set
# CONFIG_MSDOS_FS is not set
-# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
diff --git a/arch/cris/arch-v10/defconfig b/arch/cris/arch-v10/defconfig
index 2a3411e..710c20b 100644
--- a/arch/cris/arch-v10/defconfig
+++ b/arch/cris/arch-v10/defconfig
@@ -429,7 +429,6 @@ CONFIG_NET_ETHERNET=y
# CONFIG_BFS_FS is not set
# CONFIG_FAT_FS is not set
# CONFIG_MSDOS_FS is not set
-# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
diff --git a/arch/um/config.release b/arch/um/config.release
index fc68bcb..aba42f8 100644
--- a/arch/um/config.release
+++ b/arch/um/config.release
@@ -200,7 +200,6 @@ CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
-CONFIG_UMSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_EFS_FS=m
# CONFIG_JFFS_FS is not set
diff --git a/include/linux/ncp_fs.h b/include/linux/ncp_fs.h
index 83e39eb..88766e4 100644
--- a/include/linux/ncp_fs.h
+++ b/include/linux/ncp_fs.h
@@ -148,8 +148,6 @@ struct ncp_nls_ioctl
#include
#include
-/* undef because public define in umsdos_fs.h (ncp_fs.h isn't public) */
-#undef PRINTK
/* define because it is easy to change PRINTK to {*}PRINTK */
#define PRINTK(format, args...) printk(KERN_DEBUG format , ## args)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
On Fri, 25 May 2007, Pavel Machek wrote: > > > > Why the HELL cannot you realize that kernel threads are different? > > Ugh? We are talking about request_firmware() here, right? That's > calling userland helper to load the firmware...? Looks like USER > thread to me. Right. And if we had had the nice old /sbin/hotplug thing, it would all have worked fine - because it would just have done an execve(), and things would be happy. But people screwed that up too, and now udevd is an undebuggable user thread. Shit happens. See my other email about why even user threads can probably not be frozen, and the whole freezer thing is misdesigned. And I repeat: PowerPC had working and stable suspend five _years_ ago, without any of that freezing crud. We should rip it out. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] LZO de/compression support - take 3
On Thu, 24 May 2007 23:41:22 +0100 Richard Purdie <[EMAIL PROTECTED]> wrote: > I'll not send a "rename to unsafe" patch for the LZO core until Andrew > decides whether to drop the unsafe version entirely or not as per your > patch. If he doesn't due to the potential use by the compressed cache > people, I will send that patch. I'd have thought that a 3% performance difference isn't worth worrying about. Especially when reclaiming that 3% costs an additional 500 lines of pretty yukky code. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2-mm1
On Thu, 24 May 2007 15:35:45 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > This is pretty-printing. and creature-feep.
> > But lib/hexdump.c can probably do this if we add a "prefix/tag" string
> > parameter to it.
> >
> > Hugh D. wants it to print 32-bit quantities, not just bytes.
> > Yet another parameter.
> >
> > I'll look into these unless Christoph et al does so first.
>
> I'd appreciate if you could do this. I just added a call to the function
> in hexdump.c and got this ugly output. I think we need
>
> 1. byte output
yup. Obviously a suitable implementation would then permit
1-byte,2-byte,3-byte,etc
output.
> 2. A way to specify the width of the description.
Maybe not. The caller could just ensure that the preamble strings are
all of the same length:
hexdump("Bytes ", ...);
hexdump("Object ", ...);
hexdump("Redzone ", ...);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm] reiser4: remove lzo compression security hole
Switch reiser4 to use lzo1x_decompress_safe instead of lzo1x_decompress
as otherwise it presents a security hole (lzo1x_decompress doesn't
perform bounds checking on the decompressed data).
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
---
fs/reiser4/plugin/compress/compress.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.21/fs/reiser4/plugin/compress/compress.c
===
--- linux-2.6.21.orig/fs/reiser4/plugin/compress/compress.c 2007-05-16
20:47:45.0 +0100
+++ linux-2.6.21/fs/reiser4/plugin/compress/compress.c 2007-05-24
23:43:28.0 +0100
@@ -319,7 +319,7 @@ lzo1_decompress(coa_t coa, __u8 * src_fi
assert("edward-851", coa == NULL);
assert("edward-852", src_len != 0);
- result = lzo1x_decompress(src_first, src_len, dst_first, , NULL);
+ result = lzo1x_decompress_safe(src_first, src_len, dst_first, ,
NULL);
if (result != LZO_E_OK)
warning("edward-853", "lzo1x_1_decompress failed\n");
*dst_len = dstlen;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Display Intel Dynamic Acceleration feature in /proc/cpuinfo
Dave Jones wrote: > On Thu, May 24, 2007 at 03:14:39PM -0700, H. Peter Anvin wrote: > > > pbe collides with abuse by at least two vendors (AMD and > > Cyrix/Centaur/VIA) of this bit for 3DNow. > > Unless I'm mistaken, > > pbe comes from cpuid level 1 > > 3dnow comes from cpuid level 0x8001 > though I did notice that amd have it in edx, whilst via have it in ecx > curiously. edx is correct. What you're describing is correct for later-level AMD/Cyrix chips, however, when 3DNow! was first introduced they foolishly squatted on the Intel-assigned CPUID flags. However, I have audited all the vendor initialization paths, and we kill off that CPUID bit in all the places that matter. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 fails to suspend/resume to disk (sort of)
On Thu, 2007-05-24 at 21:27 +0200, Rafael J. Wysocki wrote: > On Thursday, 24 May 2007 07:20, Romano Giannetti wrote: > > On Wed, 2007-05-23 at 18:57 +0200, Rafael J. Wysocki wrote: > > > On Wednesday, 23 May 2007 11:57, Romano Giannetti wrote: > > > > On Wed, 2007-05-23 at 11:05 +0200, Rafael J. Wysocki wrote: > > > > > Hi, > > > > > > > > > > On Wednesday, 23 May 2007 09:25, Romano Giannetti wrote: > > > > > > http://lkml.org/lkml/2007/5/23/38 > > > > > > > > > > Please see http://bugzilla.kernel.org/show_bug.cgi?id=8456 > > > > > That seems to resemble the symptoms you describe. > > > > > > > > > > > > > No, I don't think. The delay I observe is on resume (suspend is very > > > > fast). Moreover, I have no SATA. It seems that my problem came from > > > > pcmcia. > > > > > > Hmm, there also is this patch: http://lkml.org/lkml/2007/5/22/434 > > > > > Neither this is related. My report was for a delay of 60 seconds on > > resume, not an infinite delay. And I have no bluetooth here. > > > > I will try to add some data to the bug and then will open a bugzilla > > report. > > OK, please add my address to the bugzilla entry's CC list. > Good news. I tried it in 2.6.21.2, vanilla, without the pcmcia 3COM card (see the other thread) and it works. With the default platform config. Thanks. Romano - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Long delay in resume from RAM (Was Re: [patch 00/69]-stablereview)
On Fri, 25 May 2007, Romano Giannetti wrote: > > Another naive doubt I have is: in 2.6.17.13, with additional patches > http://zeus2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d834c16516d1ebec4766fc58c059bf01311e6045 > http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=f755c48254ce743a3d4c1fd6b136366c018ee5b2 > http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=e6248ff596dd15bce0be4d780c60f173389b11c3 > > (now in the mainline), it works. And it used the cis file too. It really would be nice of you to just "git bisect" this, to see where it started having that 60-second delay.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] AFS: Add a function to excise a rejected write from the pagecache
On Thu, 24 May 2007 23:34:33 +0100 David Howells <[EMAIL PROTECTED]> wrote: > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > So my reason for asking the above is to try to find a way to make all these > > new PG-error games just go away. > > Yeah. However, there needs to be something to cover the gap between releasing > PG_writeback and getting PG_lock. They have to be done in that order to avoid > deadlocking against truncate and other stuff, but that leaves a window in > which > the page appears to be in a good state - one in which prepare_write() or > page_mkwrite() can potentially leak through. hm. I don't see why that race window would be a problem in practice: the page-exciser does a lock_page();wait_on_page_writeback() as normal, then proceeds with its business? But given that this doesn't work right for some reason, can we use PG_error and then handle that appropriately in the filesystem's ->prepare_write() and ->page_mkwrite()? > Nick Piggin talked about using an extra lock, but as far as I can tell, that > just compounds the deadlock problems. > > I suppose I could leave something in page->private that indicated that the > page was defunct, but that'd have to be done by the filesystem, probably > before calling cancel_rejected_write(). Well, using PG_error is OK and appropriate for that if it's localised to the fs. But I'd be a bit worried about requiring that the VFS maintain some special protocol for it, partly because it would be such a rarely-tested thing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sky2/pci issues on Gigabyte
On Thu, 24 May 2007, Stephen Hemminger wrote:
>
> Looking at the 88e8056 PCI config values:
I think you're looking at the wrong device.
The ones that matter are likely the PCI-X bridge, not the device. The
device cannot reasonably screw up DMA (unless it's really scrogged, but
then it wouldn't work under Vista either).
So it's much more likely to be about device 00:1c.4, which is the bridge
to PCI bus #4:
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express
Port 5
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
So I'd look at its config space instead ("-" is Vista, "+" is Linux):
-00: 86 80 47 28 07 00 10 00 02 00 04 06 08 00 81 00
+00: 86 80 47 28 07 04 10 00 02 00 04 06 08 00 81 00
10: 00 00 00 00 00 00 00 00 00 04 04 00 b0 b0 00 00
-20: 00 f7 f0 f8 f1 ff 01 00 00 00 00 00 00 00 00 00
+20: 00 f7 f0 f8 01 80 01 80 00 00 00 00 00 00 00 00
-30: 00 00 00 00 40 00 00 00 00 00 00 00 10 01 04 00
+30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 04 00
-40: 10 80 41 01 c0 8f 00 00 00 00 10 00 11 24 11 05
+40: 10 80 41 01 c0 8f 00 00 0f 00 11 00 11 24 11 05
50: 40 00 11 30 60 05 a0 00 00 00 48 01 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-80: 05 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+80: 05 90 01 00 0c 10 e0 fe d1 41 00 00 00 00 00 00
90: 0d a0 00 00 58 14 01 50 00 00 00 00 00 00 00 00
a0: 01 00 02 c8 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Which I _think_ is (I tried to be careful, but..):
Vista Linux
04: 0x0017 0x00100407
24: 0x0001fff1 0x08018001
3c: 0x00040110 0x0004010b
48: 0x0010 0x0011000f
80: 0x9005 0x00019005
84: 0x 0xfee0100c
88: 0x 0x41d1
but I have not looked at what the _meaning_ of those register
differences are.
The host bridge itself could be the problem, but that one is identical
in the PCI config space. I guess it could also be this one:
00:01.0 PCI bridge: Intel Corporation 82P965/G965 PCI Express Root Port
(rev 02) (prog-if 00 [Normal decode])
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
but I don't know how "port 5" (which is the bus that the ethernet
controller is behind) is related to that "root port" (which is reported
to bridge only subordinate bus 01). The "root port" thing makes me
suspect that device 00:01.0 is somehow related to 00:1c.4 despite the
apparent lack of relationship in the bus topology itself (and the root
port does _not_ decode the IO/MEM resources that lead to the ethernet
chip).
There _are_ differences in that root port device too, but I haven't done
the diff of them yet.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
