On Thu, May 24 2007, Badari Pulavarty wrote:
> On Thu, 2007-05-24 at 14:05 +0200, Jens Axboe wrote:
> > On Thu, May 24 2007, Jens Axboe wrote:
> > > > Oops: Kernel access of bad area, sig: 11 [#1]
> > > > SMP NR_CPUS=32 NUMA pSeries
> > > > Modules linked in: qla2xxx scsi_transport_fc
> > > > NIP:
Yes, I'm sure. but the patch in top post of mine works, the diffrence
is using kzalloc and remove the "ni->name[i] = 0;" line.
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
On Fri, 25 May 2007 06:27:51 + "young dave" <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> > 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)
> >
Andrew,
Thanks for your information :-)
Coly
在 2007-05-25五的 16:33 +1000，andrew hendry写道：
> select your whole mail and use pre-format in evolution.
> or change it to pre-format and do insert->text file.
> this should send it with tabs intact, the confusing bit i think is if
> your testing it by
From: Michael Ellerman <[EMAIL PROTECTED]>
Date: Fri, 25 May 2007 15:14:10 +1000
> 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
Hi Markus,
On 5/25/07, Markus F.X.J. Oberhumer <[EMAIL PROTECTED]> wrote:
Please do _not_ rewrite the LZO implementation just for coding style principles.
The current miniLZO implementation is _extrememly_ well tested, pretty
optimized and quite portable.
I agree that the implementation may lo
select your whole mail and use pre-format in evolution.
or change it to pre-format and do insert->text file.
this should send it with tabs intact, the confusing bit i think is if
your testing it by sending it to yourself, then you cant see the tabs
again.
Read it in another mailer, something like
Hi Andrew,
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
On Thu, May 24 2007, Christoph Lameter wrote:
> On Thu, 24 May 2007, Jens Axboe wrote:
>
> > On Wed, May 23 2007, Christoph Lameter wrote:
> > > On Wed, 23 May 2007, Jens Axboe wrote:
> > >
> > > > That works for me with the patch, .config attached.
> > >
> > > H... That means the .config se
Andi Kleen <[EMAIL PROTECTED]> writes:
> 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 v
Hi Richard,
Thanks for these perf. figures!
On 5/25/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
On Thu, 2007-05-24 at 11:50 -0700, Andrew Morton wrote:
> On Thu, 24 May 2007 18:15:17 +0100
> Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
>
> > Attached is a patch which may be desirable for -mm
Hi,
I tested again, it seems Evolution removes the Tabs with blanks.
How to resolve this issue on Evolution ? I am trying :-)
Coly
在 2007-05-25五的 07:52 +0200，Jan Engelhardt写道：
> On May 25 2007 09:30, WANG Cong wrote:
> >>>
> >>>Yes, I found all TABs gone when I received the mail. When I post ne
On Thu, 24 May 2007 15:11:08 -0700,
"Williams, Dan J" <[EMAIL PROTECTED]> wrote:
> --- a/async_tx/async_memcpy.c
> +++ b/async_tx/async_memcpy.c
> @@ -56,6 +56,7 @@ async_memcpy(struct page *dest, struct page *src,
> unsigned int dest_offset,
> int_en) : NULL;
>
> if (tx) {
Michael Ellerman <[EMAIL PROTECTED]> writes:
> 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 n
On Thu, May 24, 2007 at 04:02:07PM -0700, Andrew Morton wrote:
> 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.
...
> Under
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
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 necess
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 h
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
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 o
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
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 imp
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 hav
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 wo
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? T
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 w
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 ne
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 i
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. the
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
reliabl
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
> > > p
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 ta
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
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 prog
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 suspitio
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.
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 Kc
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
> > complexi
> 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
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_
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 pat
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 defi
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] run_lo
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_I
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 mistak
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-
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 list_add_t
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 th
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 th
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 objec
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 virtualizat
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 min
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.
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.
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 m
> 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 permane
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 primary
> > 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 MF
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.
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 twen
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, ther
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
> xte
>-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
> time
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 wri
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
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 c
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 ins
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.2
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 "unsu
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'
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
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 CPU
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 ker
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"
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 thi
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 pag
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
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 21
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]>
> ---
>
> Documentati
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
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 (someth
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_a
1 - 100 of 501 matches
Mail list logo
