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
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
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
> 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
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:
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,
> >
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
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
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
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
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
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?
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
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
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
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
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.
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
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
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
> > >
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
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
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
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)
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
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
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
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",
>> +
> -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
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
> >
> 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.
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
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
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
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
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
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]
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,
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
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
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
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
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
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
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
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.
>
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
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
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
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 +-
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
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
> 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
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,
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
> > 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
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
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
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);
> +
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,
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.
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
>
>-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
>
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
>
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
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
-
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
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
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
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
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,
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
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
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
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
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
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
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.
> >
> >
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
>-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
>
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
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]>
> ---
>
>
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
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
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
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
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
>
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
> >
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
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),
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 -
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
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
>
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
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
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
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.
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
>
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
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
1 - 100 of 988 matches
Mail list logo
