> I think the incorrect grammar and lack of proper capitalization and
> puntuation in the kernel messages and our changelog entries is totally
> embarassing for a professional software project.
But I guess correct grammar and spelling in our mailing list
communication is not important to you
On Thu, 2007-12-20 at 13:51 -0800, David Miller wrote:
> > The kernel printk messages are sentences. English language sentences end
> > with a full stop. They are messages printed up for normal human beings to
> > read and they should therefore be properly written.
> I totally agree.
> I think the
Ingo Molnar wrote:
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
>
>>> found a couple of bugs.
>>>
>>> firstly, 64-bit wasnt so lucky, you broke
>>> iounmap()/change_page_attr()
>>> :-)
>>>
>> Crap. Worked for me. I'll look into it.
>>
>
> well, there's an easy solution
> Documentation/Coding Style
>
> Chapter 13: Printing kernel messages
>
> Kernel messages do not have to be terminated with a period.
This piece of the document is wrong. It should also be changed. I've no
idea how such a ludicrous statement ever got into the Coding Style but I
On Thu, 20 Dec 2007 13:27:00 -0800 Greg KH wrote:
> On Wed, Dec 19, 2007 at 10:32:06PM -0800, Randy Dunlap wrote:
> > On Wed, 19 Dec 2007 16:30:31 -0800 Greg KH wrote:
> >
> > ...
> > > - A ktype is the type of object that embeds a kobject. Every structure
> > >that embeds a kobject needs a
On Sat, Dec 15, 2007 at 04:19:16PM +0100, Kay Sievers wrote:
> On Sat, 2007-12-15 at 16:34 +0300, Alexey Dobriyan wrote:
> > On Fri, Dec 14, 2007 at 01:48:23PM -0800, Greg KH wrote:
> > > On Mon, Dec 03, 2007 at 01:25:51PM -0800, Greg KH wrote:
> > > > On Tue, Dec 04, 2007 at 12:09:59AM +0300,
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 11:40:31 -0800
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
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
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 11:30:28 -0800
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
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
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 11:40:37 -0800
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
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
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 11:40:34 -0800
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
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
On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote:
>
> On Thu, 20 Dec 2007, Sam Ravnborg wrote:
>
> >>
> >> It never gets to the printk(). You were right about the
> >> compilation. Somebody changed the kernel to compile with
> >> parameter passing in REGISTERS! This means
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 11:40:35 -0800
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
Applied, 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
On Thu, 20 Dec 2007, Greg KH wrote:
> How about:
> - A ktype is the type of object that embeds a kobject.
if i were reading the above for the first time, i would have no idea
what was being embedded where. "embeds a kobject" where? what's
being embedded in what? that sentence doesn't
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 11:40:36 -0800
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
Applied, 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
Devices like the HP Integrated Remote Console Virtual Mouse, which are
standard equipment on all Proliant and Integrity servers, produce
absolute coordinates instead of relative coordinates. This is done to
synchronize the position of the mouse cursor on the client desktop
with the mouse cursor
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 11:40:29 -0800
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
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
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 11:40:32 -0800
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
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
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 11:40:33 -0800
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
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
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 11:40:30 -0800
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
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
On Thu, Dec 20, 2007 at 01:25:57PM -0500, Tony Camuso wrote:
> Appended below is a code snippet embedded in the RHEL version of
> mmconfig.c,
> for both i386 and x86_64. It does not encompass all the systems that have
> (or will have) problems with mmconf. Only HP platforms are listed, but I
>
On Thu, Dec 20, 2007 at 01:08:55PM -0500, Tony Camuso wrote:
> Greg KH wrote:
>
>> But you never answered my questions about _who_ would be responding to
>> those log messages about reporting things...
>> thanks,
>> greg k-h
>
> I did.
>
> I said I would remove that string, because I don't want
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 11:40:25 -0800
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
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
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 11:30:21 -0800
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
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
On 12/20/2007 4:00 PM, Matthew Wilcox wrote:
> On Thu, Dec 20, 2007 at 03:56:29PM -0500, Loic Prylli wrote:
>
>> I know the final device is not aware on how the config request was
>> originated. I am just saying platforms built around the Intel 82801
>> chipset (ICH2) don't support mmconfig at
From: Joe Perches <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 11:30:22 -0800
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
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
On 16/12/2007, Paul Mundt <[EMAIL PROTECTED]> wrote:
>
> Also, __devinit/__devexit annotations?
>
Is there any difference between __init and __devint? I am using
__init/__exit already
> > +static struct platform_driver gdrom_driver = {
> > + .probe = probe_gdrom,
> > + .remove =
On Tue, Dec 18, 2007 at 05:38:58PM -0800, Linus Torvalds wrote:
> That
>
> PCI: Cannot allocate resource region 9 of bridge :00:01.0
> PCI: Cannot allocate resource region 1 of device :01:00.0
>
> thing is really starting to bug me.
>
> I bet that is the real problem here,
On Wed, Dec 19, 2007 at 11:26:19PM -0500, Alan Stern wrote:
> On Wed, 19 Dec 2007, Greg KH wrote:
> > - A ktype is the type of object that embeds a kobject. Every structure
> >that embeds a kobject needs a corresponding ktype. The ktype controls
>
> I think the wording here is a little
On Thu, Dec 20, 2007 at 10:04:26AM +0100, Jan Engelhardt wrote:
>
> On Dec 19 2007 16:30, Greg KH wrote:
> >See the example module, samples/kobject/kobject-example.c for an
> >implementation of a simple kobject and attributes.
>
> Should mention here that if simple types are enough and a
On Wed, Dec 19, 2007 at 10:32:06PM -0800, Randy Dunlap wrote:
> On Wed, 19 Dec 2007 16:30:31 -0800 Greg KH wrote:
>
> > Everything you never wanted to know about kobjects, ksets, and ktypes
> >
> > Greg Kroah-Hartman <[EMAIL PROTECTED]>
> >
> > Based on an original article by Jon Corbet for
From: Alan Cox <[EMAIL PROTECTED]>
Date: Thu, 20 Dec 2007 21:07:41 +
> The kernel printk messages are sentences. English language sentences end
> with a full stop. They are messages printed up for normal human beings to
> read and they should therefore be properly written.
I totally agree.
On Thu, 2007-12-20 at 15:02 -0600, Steve Wise wrote:
> Benjamin Herrenschmidt wrote:
> > Adding A few more people to the discussion. You may well be right and we
> > would have to provide the same alignment, though that sucks a bit as one
> > of the reason we switched to 4K for the IOMMU is that
On Thu, 20 Dec 2007 14:48:45 +
"Will Newton" <[EMAIL PROTECTED]> wrote:
> This patch allows the private_data field to be specified in
> platform_data for the standard 8250/16550 UART. This field is used by
> DW APB type UARTs and without this patch it's only possible to set
> this field when
Hi,
On Dec 20, 2007 4:38 PM, David Newall <[EMAIL PROTECTED]> wrote:
> >>> and another one, this time tainted with the nvidia module:
> >>> 5194.130985] Unable to handle kernel paging request at 0300
> >>> RIP:
>
> Numbers like that don't suggest hardware faults. All those zeros:
On Thu, 2007-12-20 at 21:07 +, Alan Cox wrote:
> > I missed the context on this one. So this is checking for periods at
> > the end of messages for printk's. We would need something a little
> > cleverer to ensure we are only checking the contents of the string. But
> > eminently doable.
>
> It doesn't seem to be something in .config. Do you know how to
> reconfigure to get parameter passing put back like it was? Our
> production applications have lots of assembly-language files
> and I'm sure we are not going to be able to change all those!
32-bit x86 uses regparm=3 by default
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > found a couple of bugs.
> >
> > firstly, 64-bit wasnt so lucky, you broke
> > iounmap()/change_page_attr()
> > :-)
>
> Crap. Worked for me. I'll look into it.
well, there's an easy solution for unification patches: the resulting
object
> I missed the context on this one. So this is checking for periods at
> the end of messages for printk's. We would need something a little
> cleverer to ensure we are only checking the contents of the string. But
> eminently doable.
>
> /me plays
>
> Ok, yes this seems ok. Have added it for
On Thu, 20 Dec 2007 21:17:10 +0100
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> David Newall wrote:
> > Hi Arjan,
> >
> > I've not been able to find this file, "drivers/bluetooth/hci_tty.c", but
> > anyway, This seems to be what happens: Hci_uart_close() flushes using
> > hci_uart_flush().
Stephen Hemminger wrote:
> On Thu, 20 Dec 2007 15:36:13 -0500
> "Parag Warudkar" <[EMAIL PROTECTED]> wrote:
>
>> On Dec 20, 2007 3:04 PM, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
I think it is reasonable for Network driver watchdogs to use a
deferrable timer - if the machine is 100%
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> > > make[1]: *** No rule to make target
> > > `arch/x86/kernel/paravirt_patch_32.o', needed by
> > > `arch/x86/kernel/built-in.o'. Stop.
> >
> > if it's just that single missing file then please send me a patch that
> > adds that file
On Thu, 20 Dec 2007, Lennart Sorensen wrote:
> On Thu, Dec 20, 2007 at 11:13:19AM -0500, linux-os (Dick Johnson) wrote:
>> It never gets to the printk(). You were right about the
>> compilation. Somebody changed the kernel to compile with
>> parameter passing in REGISTERS! This means that
On Thu, 20 Dec 2007, Sam Ravnborg wrote:
>>
>> It never gets to the printk(). You were right about the
>> compilation. Somebody changed the kernel to compile with
>> parameter passing in REGISTERS! This means that EVERYTHING
>> needs to be compiled the same way, 'C' calling conventions
>> were
Glauber de Oliveira Costa wrote:
x86_read_per_cpu() and its writeish sister are not present in x86_64. So in
this patch, we replace them with __get_cpu_var(), which is present in both
Eventually we'd like to use something closer to the i386 code for
x86_64, obviously...
-hpa
--
To
On Thu, 20 Dec 2007 15:57:45 -0500
Rik van Riel <[EMAIL PROTECTED]> wrote:
> 2.6.24-rc5-mm1 seems to have a hang related to the SCSI or block
> device probing code.
>
> This is on a dual quad-core x86-64 system with megaraid_sas controller.
>
> scsi 0:2:0:0: Direct-Access DELL PERC 5/i
Another turd is pci_scan_device() which can't cope with 64 bits BARs on
32 bits platforms even when they have 64 bits resources. I'll send a fix
for that.
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Dec 20, 2007 6:33 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > this patch adds the paravirt_patch_32.o:
> >
> > > -obj-$(CONFIG_PARAVIRT) += paravirt.o
> > > +obj-$(CONFIG_PARAVIRT) += paravirt.o paravirt_patch_32.o
> >
>
Benjamin Herrenschmidt wrote:
On Thu, 2007-12-20 at 13:29 -0600, Steve Wise wrote:
Or based on the alignment of vaddr actually...
The later wouldn't be realistic. What I think might be necessay, though
it would definitely cause us problems with running out of iommu space
(which is the reason
On Thu, 20 Dec 2007 15:36:13 -0500
"Parag Warudkar" <[EMAIL PROTECTED]> wrote:
> On Dec 20, 2007 3:04 PM, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > > I think it is reasonable for Network driver watchdogs to use a
> > > deferrable timer - if the machine is 100% IDLE there is no one needing
>
> That won't work, because PCI_BASE_ADDRESS_MEM_TYPE_64 controls how
> many bits need to be written back to the BAR. If we changed that
> to PCI_BASE_ADDRESS_MEM_TYPE_32, we wouldn't clear the high 32-bits
> of the BAR.
>
> > ... and that would be an X server issue!).
>
> Of course, fixing the
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>
>>> Here's another round of the pagetable unification patches. I've
>>> done a few dozen rounds of randconfig builds on both 32- and 64-bit,
>>> so I hope that will prevent compile problems in your test
>>> environment.
>>>
On Thu, 20 Dec 2007, James Nichols wrote:
> > You'd probably should also investigate the Linux kernel,
> > especially the size and locks of the components of the Sack data
> > structures and what happens to those data structures after Sack is
> > disabled (presumably the Sack data structure is in
Eduardo Habkost wrote:
> On Wed, Dec 19, 2007 at 02:35:36PM -0800, Jeremy Fitzhardinge wrote:
>
>> +static inline pte_t pte_mkclean(pte_t pte) { set_pte(,
>> __pte(pte_val(pte) & ~_PAGE_DIRTY)); return pte; }
>> +static inline pte_t pte_mkold(pte_t pte){ set_pte(,
>> __pte(pte_val(pte) &
Ingo Molnar wrote:
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
>
>> Here's another round of the pagetable unification patches. I've done
>> a few dozen rounds of randconfig builds on both 32- and 64-bit, so I
>> hope that will prevent compile problems in your test environment.
>>
>>
On Thu, Dec 20, 2007 at 03:56:29PM -0500, Loic Prylli wrote:
> I know the final device is not aware on how the config request was
> originated. I am just saying platforms built around the Intel 82801
> chipset (ICH2) don't support mmconfig at all. I would also not be
> surprised if the platforms
Benjamin Herrenschmidt wrote:
Adding A few more people to the discussion. You may well be right and we
would have to provide the same alignment, though that sucks a bit as one
of the reason we switched to 4K for the IOMMU is that the iommu space
available on pSeries is very small and we were
On Thu, 13 Dec 2007 02:40:50 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
2.6.24-rc5-mm1 seems to have a hang related to the SCSI or block
device probing code.
This is on a dual quad-core x86-64 system with megaraid_sas controller.
scsi 0:2:0:0: Direct-Access DELL PERC 5/i
On Tue, 2007-12-18 at 12:07 -0800, [EMAIL PROTECTED] wrote:
> On Tue, Dec 18, 2007 at 05:50:42PM +0100, Stefan Richter wrote:
>
> > Do I understand correctly?: A device and the CPUs communicate via two
> > separate memory areas: A data buffer and a status FIFO. The NUMA
> > interconnect may
On Wed, 19 Dec 2007 11:04:26 -0500
Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-12-19 at 08:45 -0500, Rik van Riel wrote:
> > On Wed, 19 Dec 2007 11:56:48 +1100
> > Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > Hmm, I still don't know (or forgot) why you don't just use the
> > > old
James Nichols wrote
> > I still dont understand.
> >
> > "tcpdump -p -n -s 1600 -c 1" doesnt reveal User data at all.
> >
> > Without any exact data from you, I am afraid nobody can help.
>
> Oh, I didn't see that you specified specific options. I'll still have
> to anonymize 2000+ IP
On 12/20/2007 3:15 PM, Matthew Wilcox wrote:
> On Thu, Dec 20, 2007 at 03:05:52PM -0500, Loic Prylli wrote:
>
>> I am not familiar with the tg3 driver, just trying to give a 5 minutes
>> look, it seems the typical cases where the pci-conf-space is used
>> intensively are with some rev in
On Wed, 19 Dec 2007, Al Viro wrote:
> On Wed, Dec 19, 2007 at 02:43:26PM +0100, Bodo Eggert wrote:
> > Since nobody knows about this "security boundary" and everybody knows about
> > the annoying "can't link across bind-mountpoints bug",
>
> ... how about teaching people to RTFM? Starting,
On Thu, 20 Dec 2007, James Nichols wrote:
> > I still dont understand.
> >
> > "tcpdump -p -n -s 1600 -c 1" doesnt reveal User data at all.
> >
> > Without any exact data from you, I am afraid nobody can help.
>
> Oh, I didn't see that you specified specific options. I'll still have
> to
* David Miller <[EMAIL PROTECTED]>, [2007-12-20 0:40 -0800]:
> The problem is that I created indirection that was totally unused, the
> operation vectors members for these cases thus didn't get filled in,
> and we OOPS trying to call NULL pointers as functions :-)
>
> This should fix the
On Wed, Dec 19, 2007 at 11:18:54PM -0500, Andrew Lutomirski wrote:
> I understand that there's no way that /dev/random can provide good
> output if there's insufficient entropy. But it still shouldn't leak
> arbitrary bits of user data that were never meant to be put into the
> pool at all.
On Dec 20, 2007 3:04 PM, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > I think it is reasonable for Network driver watchdogs to use a
> > deferrable timer - if the machine is 100% IDLE there is no one needing
> > the network to be up. If there is something running even on the other
> > CPU -
David Newall wrote:
Hi Arjan,
I've not been able to find this file, "drivers/bluetooth/hci_tty.c", but
anyway, This seems to be what happens: Hci_uart_close() flushes using
hci_uart_flush(). Subsequently, in hci_dev_do_close(), (one step in
hci_unregister_dev()), hci_uart_flush() is called
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> The core patching code for paravirt is sufficiently different
> among i386 and x86_64, and we move them to specific files.
this patch adds the paravirt_patch_32.o:
> -obj-$(CONFIG_PARAVIRT) += paravirt.o
>
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> this patch adds the paravirt_patch_32.o:
>
> > -obj-$(CONFIG_PARAVIRT) += paravirt.o
> > +obj-$(CONFIG_PARAVIRT) += paravirt.o paravirt_patch_32.o
>
> but does not add that file nor any other rule to build that target, so
> it
On Donnerstag, 20. Dezember 2007, Ingo Molnar wrote:
> * Hemmann, Volker Armin <[EMAIL PROTECTED]> wrote:
> > On Donnerstag, 20. Dezember 2007, you wrote:
> > > Hemmann, Volker Armin wrote:
> > > > [ 5194.131014] Pid: 22490, comm: sleep Tainted: P
> > > > 2.6.23.11reiser4 #4
> > >
> > > The
Bartlomiej Zolnierkiewicz wrote:
Hi,
This patch series is a major rework of the ide-cd driver.
Hi, in the future could you please post big patchbombs like this as
replies to the first one so they fold nicely into one thread? IIRC,
git-send-email does this by default now.
--
To
Ivan Kokshaysky wrote:
Use type 1 just for the first 64 bytes and tg3 will be happy. All we need
is to avoid touching BARs with mmconfig.
Ivan.
Re-thinking this ...
The problem I see with this approach is that it does not help devices
that are mmconfig-unfriendly and will not work above the
On Thu, 2007-12-20 at 13:29 -0600, Steve Wise wrote:
> Or based on the alignment of vaddr actually...
The later wouldn't be realistic. What I think might be necessay, though
it would definitely cause us problems with running out of iommu space
(which is the reason we did the switch down to 4K),
On Thu, 20 Dec 2007, Parag Warudkar wrote:
On Dec 20, 2007 2:22 PM, Kok, Auke <[EMAIL PROTECTED]> wrote:
ok, that's just bad and if there's no user-defineable limit to the deferral I
definately don't like this change.
Can I safely assume that any irq will cause all deferred timers to run?
Adding A few more people to the discussion. You may well be right and we
would have to provide the same alignment, though that sucks a bit as one
of the reason we switched to 4K for the IOMMU is that the iommu space
available on pSeries is very small and we were running out of it with
64K pages
Andrew Lutomirski wrote:
I understand that there's no way that /dev/random can provide good
output if there's insufficient entropy. But it still shouldn't leak
arbitrary bits of user data that were never meant to be put into the
pool at all.
It doesn't leak it though, it consumes it, and it
Ivan Kokshaysky wrote:
On Thu, Dec 20, 2007 at 12:08:33PM -0700, Matthew Wilcox wrote:
On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote:
Does anybody see a down side to this?
It'll be slower than it would be if we used mmconfig directly. Now yes,
nobody should be using pci config
On Thu, 2007-12-20 at 12:06 -0800, Andrew Morton wrote:
> On Thu, 20 Dec 2007 11:32:25 -0800 Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-12-18 at 19:04 -0800, Geoff Levand wrote:
> >
> > > Unfortunately there wasn't enough context in the patch to see
> > > that there is a down()
Matthew Wilcox wrote:
Here's how BARs work ... when you write 0x to the BAR, it
ignores all the set bits that are less than the size of the BAR. So,
assuming this is a 256MB BAR (like my G33 is), what ends up written to
this BAR is 0xf000. Now, because this is graphics, apparently
On Thu, Dec 20, 2007 at 03:05:52PM -0500, Loic Prylli wrote:
> I am not familiar with the tg3 driver, just trying to give a 5 minutes
> look, it seems the typical cases where the pci-conf-space is used
> intensively are with some rev in combination with the 82801
> (TG3_FLG2_ICH_WORKAROUND) which
x86_read_per_cpu() and its writeish sister are not present in x86_64. So in
this patch, we replace them with __get_cpu_var(), which is present in both
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/paravirt.c | 10 +-
1 files changed, 5 insertions(+),
Parag Warudkar wrote:
On Dec 20, 2007 2:22 PM, Kok, Auke <[EMAIL PROTECTED]> wrote:
ok, that's just bad and if there's no user-defineable limit to the deferral I
definately don't like this change.
Can I safely assume that any irq will cause all deferred timers to run?
I think even other
The core patching code for paravirt is sufficiently different
among i386 and x86_64, and we move them to specific files.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/Makefile_32 |2 +-
arch/x86/kernel/paravirt.c | 50
Like i386, x86_64 also need to include its own patching function.
(Well, if you're not in a hurry, and don't care about speed, you don't
really _need_ ;-))
So here they are. Not much different in essence from i386
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
x86_64 needs a potentially larger clobber list than i386, due to its calling
convention. So we add more CLBR_ defines for it.
Note that CLBR_ANY is different for each of the architectures, since it
comprises
the notion of "All call clobbers in this architecture"
Signed-off-by: Glauber de
The assembly code in entry_64.S issues a bunch of privileged instructions,
like cli, sti, swapgs, and others. Paravirt guests are forbidden to do so,
and we then replace them with macros that will do the right thing.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
This patch adds paravirt hook for swapgs operation, which is a privileged
operation in x86_64.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/paravirt.c |1 +
include/asm-x86/paravirt.h |9 +
include/asm-x86/processor.h |8
3 files
Since the advent of ticket locking, CLI_STRING, STI_STRING, and friends
are not used anymore. They can now be safely deleted.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/spinlock.h |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
Index:
i386 has a macro GET_CR0_INTO_EAX, used in early trap handling code.
x86_64 has similar needs, only it needs to put cr2 into rcx. We provide
a macro for such task, in the same way
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/paravirt.h |6 ++
1 files
This patch changes the irq handling function definitions
in paravirt.h (like raw_local_irq_disable) to accomodate for x86_64.
The differences are in the calling convention.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/paravirt.h | 43
To account for differences in x86_64, we change the macros that
create raw instances of the paravirt_patch_site struct.
We need to align 64-pointers to 64-bit boundaries, so we add an alignment
directive. Also, we need to make room for a word-sized pointer,
instead of a fixed 32-bit one
This patch adjust the paravirt macros used in assembly code
to accomodate for x86_64 as well.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/paravirt.h | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
Index:
write_tsc() does not need to be enclosed in any paravirt closure,
as it uses wrmsr(). So we rip off the duplicate in msr.h
and the definition from paravirt.h
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/msr.h |2 --
include/asm-x86/paravirt.h |2
This patch adds a field in pv_cpu_ops for a paravirtualized hook
for rdtscp, needed for x86_64.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/paravirt.c |1 +
include/asm-x86/paravirt.h | 22 ++
2 files changed, 23 insertions(+), 0
This patch adjust the PVOP_VCALL and PVOP_CALL macros to
work with x86_64. It has a different calling convention, and
we use auxiliary macros to account for both calling conventions
as cleanly as possible
Comments are adjusted accordingly.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL
This patch changes paravirt_32.c to paravirt.c. The goal
is to have paravirt support in x86_64, so we do it in a common file
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/kernel/Makefile_32 |2 +-
arch/x86/kernel/paravirt.c| 475
Hi folks,
With this series, the bulk of the work of pvops64 is done.
Here, I integrate most of the paravirt.c and paravirt.h files, making
them applicable to both architectures.
CONFIG_PARAVIRT is _not_ present yet. Basically, this code is missing page
table integration (patches currently being
On Thu, 20 Dec 2007 11:32:25 -0800 Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-12-18 at 19:04 -0800, Geoff Levand wrote:
>
> > Unfortunately there wasn't enough context in the patch to see
> > that there is a down() earlier in the routine, and that the patch
> > does indeed remove an
On 12/20/2007 2:08 PM, Matthew Wilcox wrote:
> On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote:
>
>> Also, this solution also would allow us to remove the unreachable_devices()
>> routine and bitmap.
>>
>
> Not really ... we probe reading address 0x100 to see if the device
>
Kok, Auke wrote:
ok, that's just bad and if there's no user-defineable limit to the deferral I
definately don't like this change.
Can I safely assume that any irq will cause all deferred timers to run?
*on that cpu*. Timers are per cpu, as are interrupts. Just not per se the same
one ...
201 - 300 of 1372 matches
Mail list logo
