On Mon, 07 Jan 2008 16:06:20 +0530, Kamalesh Babulal wrote:
> The defconfig make fails on x86_64 (AMD box) with following error
>
> CHK include/linux/utsrelease.h
> CALLscripts/checksyscalls.sh
> CHK include/linux/compile.h
> GEN .version
> CHK
On Tuesday 08 January 2008 16:44, H. Peter Anvin wrote:
> Nick Piggin wrote:
> > On Tuesday 08 January 2008 13:43, Yinghai Lu wrote:
> >> wonder why free_pages_check mm/page_alloc.c is using bit OR than logical
> >> OR
> >>
> >> @@ -450,9 +450,9 @@ static inline void __free_one_page(struc
> >>
>
On 08-01-2008 06:59, Al Viro wrote:
> On Mon, Jan 07, 2008 at 07:26:12PM -0800, Linus Torvalds wrote:
>
>> I usually just compile a small program like
>>
>> const char array[]="\xnn\xnn\xnn...";
>>
>> int main(int argc, char **argv)
>> {
>> printf("%p\n", array);
>>
At Mon, 07 Jan 2008 20:53:33 +0100,
Harald Dunkel wrote:
>
> Hi folks,
>
> Upgrading from 2.6.24-rc6 to rc7 Alsa stopped working for me. I still
> can access /dev/dsp, change the volume and so on, but the speakers
> are quiet. Moving back to rc6 there is no such problem.
>
> Of course the
From: Björn Steinbrink <[EMAIL PROTECTED]>
Date: Mon, 7 Jan 2008 02:46:38 +0100
> On 2008.01.06 19:49:49 -0200, Adolfo R. Brandes wrote:
> > I have this forcedeth MAC address reversal problem when suspending
> > on 2 distinct boxes. I can confirm Steinbrink's patch fixes the
> > problem on only
On Tue, Jan 08, 2008 at 08:48:35AM +0200, Thanasis wrote:
> Is there a kernel driver that would make a NIC's port work as a RS232
> port, using the serial cables that are RJ45 on one side and DB9 or DB25
> on the other? Maybe null modem cables of that type ? Or for example
> those used by cisco as
* Huang, Ying <[EMAIL PROTECTED]> wrote:
> This patch export the boot parameters via debugfs for debugging.
>
> The files added are as follow:
>
> boot_params/data: binary file for struct boot_params
> boot_params/version : boot protocol version
>
> This patch is based on 2.6.24-rc5-mm1
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> x86 32 bit already has this feature: This patch uses the stack frames
> with frame pointer into an exact stack trace, by following the frame
> pointer. This only affects kernels built with the CONFIG_FRAME_POINTER
> config option enabled, and
Forget my previous question, as I understand now that I gave it a more
serious though, that it is not a matter of driver, but an
incompatibility between the two in the layer/media carrier level.
I was dreaming :-)
Original Message
Subject:NIC as RS232
Date: Tue, 08 Jan
on 01/08/2008 08:48 AM Thanasis wrote the following:
> Is there a kernel driver that would make a NIC's port work as a RS232
> port, using the serial cables that are RJ45 on one side and DB9 or DB25
> on the other? Maybe null modem cables of that type ? Or for example
> those used by cisco as
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> Subject: Turn 64 bit x86 HANDLE_STACK into print_context_stack like 32 bit has
> From: Arjan van de Ven <[EMAIL PROTECTED]>
>
> This patch turns the x86 64 bit HANDLE_STACK macro in the backtrace
> code into a function, just like 32 bit has. This
On Jan 8, 2008 1:20 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 07, 2008 at 06:13:37PM +0100, Stefan Richter wrote:
> > It's already in the driver core to the most part. It remains to be seen
> > what is less complicated in the end: Transparent mutex-protected list
> > accesses provided
Subject: ACPI: fix processor limit set error
From: Yi Yang <[EMAIL PROTECTED]>
when echo some invalid values to /proc/acpi/processor/CPU*/limit,
it doesn't return any error info, on the contrary, it successes
and sets some other values, for example:
[EMAIL PROTECTED] /]# echo "0:0A"
Is there a kernel driver that would make a NIC's port work as a RS232
port, using the serial cables that are RJ45 on one side and DB9 or DB25
on the other? Maybe null modem cables of that type ? Or for example
those used by cisco as console port cables?
(or may be I'm dreaming ;-)
<>
Hi,
> A lot of google searches reflect that, the latest kernel supporting
> Huawei EC321 CDMA PCCARD is 2.6.17. My version (2.6.22-14 on Ubuntu)
> doesn't work.
>
This is probably because ...
> [ 3804.14]
> /build/buildd/linux-source-2.6.22-2.6.22/drivers/usb/serial/usb-serial.c: USB
>
Ingo Oeser wrote:
On Monday 07 January 2008, Andi Kleen wrote:
Bernd Schubert <[EMAIL PROTECTED]> writes:
Hi,
I just switched to libata (pata) on my laptop and the immediate panic made it
impossible to figure out why my boot partition wasn't available.
After applying this little patch I
On Mon, Jan 07, 2008 at 03:28:15PM -0800, Andrew Morton wrote:
> On Mon, 7 Jan 2008 21:44:26 +0100
> Marcin Slusarz <[EMAIL PROTECTED]> wrote:
>
> > > There's some overly long lines here and some odd style, this should look
> > > more like:
> > These long lines were split later in "[PATCH 1/7]
On Saturday January 5, [EMAIL PROTECTED] wrote:
> @@ -357,7 +375,18 @@ lockd_down(void)
> goto out;
> }
> warned = 0;
> - kthread_stop(nlmsvc_task);
> + if (atomic_sub_return(1, _ref) != 0)
> + printk(KERN_WARNING "lockd_down: lockd is waiting for "
>
From: Julia Lawall <[EMAIL PROTECTED]>
Date: Sun, 6 Jan 2008 16:51:45 +0100 (CET)
> The function sockfd_lookup uses fget on the value that is stored in the
> file field of the returned structure, so fput should ultimately be applied
> to this value. This can be done directly, but it seems better
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 8 Jan 2008 17:15:16 +1100
> On Thu, Jan 03, 2008 at 08:05:50PM +0800, WANG Cong wrote:
> >
> > Since __xfrm_policy_destroy is used to destory the resources
> > allocated by xfrm_policy_alloc. So using the name
> > __xfrm_policy_destroy is not
From: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
Here is a quick and naive smoke test for kprobes. This is intended to
just verify if some unrelated change broke the *probes subsystem. It is
self contained, architecture agnostic and isn't of any great use by itself.
This needs to be built in
handle_sysrq can be called from interrupt context. sysrq_timer_list_show
eventually starts poking at module symbols which take the module mutex.
so instead, let's just kick off a workqueue.
[ doesn't happen on my laptop with the keyboard, but does when
triggered from /proc/sysrq-trigger ]
On Saturday January 5, [EMAIL PROTECTED] wrote:
> Have lockd_up start lockd using kthread_run. With this change,
> lockd_down now blocks until lockd actually exits, so there's no longer
> need for the waitqueue code at the end of lockd_down. This also means
> that only one lockd can be running at
On Monday 07 January 2008, Andi Kleen wrote:
> Bernd Schubert <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > I just switched to libata (pata) on my laptop and the immediate panic made
> > it
> > impossible to figure out why my boot partition wasn't available.
> > After applying this little patch
On Thu, Jan 03, 2008 at 08:05:50PM +0800, WANG Cong wrote:
>
> Since __xfrm_policy_destroy is used to destory the resources
> allocated by xfrm_policy_alloc. So using the name
> __xfrm_policy_destroy is not correspond with xfrm_policy_alloc.
> Rename it to xfrm_policy_destroy.
>
> And along with
From: Brice Goglin <[EMAIL PROTECTED]>
Date: Mon, 07 Jan 2008 14:33:32 +0100
> [PATCH][LRO] Fix lro_mgr->features checks
>
> lro_mgr->features contains a bitmask of LRO_F_* values which are
> defined as power of two, not as bit indexes.
> They must be checked with x_F_FOO, not with
On Mon, Jan 07, 2008 at 07:26:12PM -0800, Linus Torvalds wrote:
> I usually just compile a small program like
>
> const char array[]="\xnn\xnn\xnn...";
>
> int main(int argc, char **argv)
> {
> printf("%p\n", array);
> *(int *)0=0;
> }
Heh.
On Saturday January 5, [EMAIL PROTECTED] wrote:
> Move the initialzation in __svc_create_thread that happens prior to
> thread creation to a new function. Export the function to allow
> services to have better control over the svc_rqst structs.
>
> Signed-off-by: Jeff Layton <[EMAIL PROTECTED]>
>
Nick Piggin wrote:
On Tuesday 08 January 2008 13:43, Yinghai Lu wrote:
wonder why free_pages_check mm/page_alloc.c is using bit OR than logical OR
@@ -450,9 +450,9 @@ static inline void __free_one_page(struc
static inline int free_pages_check(struct page *page)
{
- if
On Mon, 7 Jan 2008, Yinghai Lu wrote:
> try to kexec 2.6.23 from RHEL 5.1, will get
> Your BIOS doesn't leave a aperture memory hole
> Please enable the IOMMU option in the BIOS setup
> This costs you 64 MB of RAM ==> reboot
>
> but 2.6.24-rc7 kexec 2.6.24-rc7 is ok.
BUG in 2.6.23 kexec?
This patch export the boot parameters via debugfs for debugging.
The files added are as follow:
boot_params/data: binary file for struct boot_params
boot_params/version : boot protocol version
This patch is based on 2.6.24-rc5-mm1 and has been tested on i386 and
x86_64 platform.
This
On Mon, 7 Jan 2008 23:25:42 -0600 Michael Halcrow <[EMAIL PROTECTED]> wrote:
> --- a/fs/ecryptfs/inode.c
> +++ b/fs/ecryptfs/inode.c
> @@ -120,22 +120,9 @@ ecryptfs_do_create(struct inode *directory_inode,
> rc = ecryptfs_create_underlying_file(lower_dir_dentry->d_inode,
>
On Mon, Jan 07, 2008 at 09:02:53PM -0800, H. Peter Anvin wrote:
> The boot protocol has until now required that the initrd be located in
> lowmem, which makes the lowmem/highmem boundary visible to the boot
> loader. This was exported to the bootloader via a compile-time
> field. Unfortunately,
On Mon, Jan 07, 2008 at 12:24:46PM -0800, Harvey Harrison wrote:
> Use a central is_kprobe_fault() inline in kprobes.h to remove all
> of the arch-dependant, practically identical implementations in
> avr32, ia64, powerpc, s390, sparc64, and x86.
>
> avr32 was the only arch without the
This patch corrects some erroneous dentry handling in eCryptfs.
If there is a problem creating the lower file, then there is nothing
that the persistent lower file can do to really help us. This patch
makes a vfs_create() failure in the lower filesystem always lead to an
unconditional do_create
On Mon, 7 Jan 2008, Arjan van de Ven wrote:
> sounds like a bad idea; a compile time failure is of course nicer than
> a runtime failure for the cases we can find the bug at compile-time already.
>
There is not much chance of a runtime failure these days since kmalloc now
supports up to 4MB
Subject: Use the stack frames to get exact stack-traces for CONFIG_FRAMEPOINTER
on x86-64
From: Arjan van de Ven <[EMAIL PROTECTED]>
x86 32 bit already has this feature: This patch uses the stack frames with
frame pointer into an exact stack trace, by following the frame pointer.
This only
Subject: Turn 64 bit x86 HANDLE_STACK into print_context_stack like 32 bit has
From: Arjan van de Ven <[EMAIL PROTECTED]>
This patch turns the x86 64 bit HANDLE_STACK macro in the backtrace code into
a function, just like 32 bit has. This is needed pre work in order to get exact
backtraces for
The boot protocol has until now required that the initrd be located in
lowmem, which makes the lowmem/highmem boundary visible to the boot
loader. This was exported to the bootloader via a compile-time
field. Unfortunately, the vmalloc= command-line option breaks this
part of the protocol;
On Mon, Jan 07, 2008 at 10:20:23PM -0500, Tony Camuso wrote:
> Greg,
>
> Have you given this patch-set any more consideration?
Which patch-set, there have been a number of them :)
> I've submitted the changes you requested.
Care to respin them all so I'm not confused?
thanks,
greg k-h
--
To
On Mon, Jan 07, 2008 at 12:04:06PM -0800, Christoph Lameter wrote:
> Here is the cleaned version of the patch. Dhaval is testing it.
>
>
> quicklists: Only consider memory that can be used with GFP_KERNEL
>
> Quicklists calculates the size of the quicklists based on the number
> of free pages.
On Mon, 7 Jan 2008 10:31:53 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> We could replace the __you_cannot_kmalloc_that_much() with a BUG()
> statement so we have the same effect in SLAB?
>
sounds like a bad idea; a compile time failure is of course nicer than
a runtime failure
> And sloppy of me to not catch it. Anyway:
>
> Acked-by: Olof Johansson <[EMAIL PROTECTED]>
>
> I wonder how long until there's a device that has some other < PAGE_SIZE
> alignment bug^Wrequirement that we'll need to meet too. :(
Yeah, it's a worry...
Ben.
--
To unsubscribe from this list:
From: Dmitri Vorobiev <[EMAIL PROTECTED]>
I noticed that the commit f197465384bf7ef1af184c2ed1a4e268911a91e3
(MIPS Tech: Get rid of volatile in core code) broke the software
reset functionality for MIPS Malta boards in big-endian mode.
According to the MIPS Malta board user's manual, writing the
On Thu, 2007-12-20 at 22:50 +0300, 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.
I've tried Ivan's suggestion, and it works.
The patch is appended below.
My question is, do we want to
On Tue, Jan 08, 2008 at 10:34:22AM +1100, Benjamin Herrenschmidt wrote:
> powerpc: Workaround for iommu page alignment
>
> Our iommu page size is currently always 4K. That means with our current
> code, drivers may do a dma_map_sg() of a 64K page and obtain a dma_addr_t
> that is only 4K aligned.
On Tuesday 08 January 2008 13:43, Yinghai Lu wrote:
> wonder why free_pages_check mm/page_alloc.c is using bit OR than logical OR
>
> @@ -450,9 +450,9 @@ static inline void __free_one_page(struc
>
> static inline int free_pages_check(struct page *page)
> {
> - if
On Mon, Jan 07, 2008 at 09:27:24PM -0500, Steven Rostedt wrote:
>
> Sometimes cpu_idle_wait gets stuck because it might miss CPUS that are
> already in idle, have no tasks waiting to run and have no interrupts
> going to them. This is common on bootup when switching cpu idle
> governors.
I must
On Mon, 7 Jan 2008, Kevin Winchester wrote:
> J. Bruce Fields wrote:
> >
> > Is there any good basic documentation on this to point people at?
>
> I would second this question. I see people "decode" oops on lkml often
> enough, but I've never been entirely sure how its done. Is it
Greg,
Have you given this patch-set any more consideration?
I've submitted the changes you requested.
Regards,
Tony
--
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 Tuesday 08 January 2008 02:48:23 James Bottomley wrote:
> We're always open to new APIs (or more powerful and expanded old ones).
> The way we've been doing the sg_chain conversion is to slide API layers
> into the drivers so sg_chain becomes a simple API flip when we turn it
> on.
On Monday 07 January 2008 21:05:26 Peter Zijlstra wrote:
> On Sun, 2008-01-06 at 14:11 -0500, Erez Zadok wrote:
> > > Ingo, Peter, does either of you actually care about this problem? In
> > > the last round when I debugged this problem there was a notable lack of
> > > reaction from either of
On Mon, 07 Jan 2008 20:38:09 +0100
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> Christer Weinigel <[EMAIL PROTECTED]> wrote:
>
> > How do you find out the speed of the ISA bus? AFAIK there is no
> > standardized way to do that. On the Geode SC2200 the ISA bus speed
> > is usually the PCI clock
On Mon, 7 Jan 2008 18:43:46 -0800 "Yinghai Lu" <[EMAIL PROTECTED]> wrote:
> wonder why free_pages_check mm/page_alloc.c is using bit OR than logical OR
>
> @@ -450,9 +450,9 @@ static inline void __free_one_page(struc
>
> static inline int free_pages_check(struct page *page)
> {
> - if
On Fri, 2007-12-28 at 08:25 +0800, Robert Hancock wrote:
> Rafael J. Wysocki wrote:
> >> Also, as was pointed out, pre-Vista versions of Windows follow ACPI
> 1.0
> >> and Vista follows 3.0, so 2.0 doesn't really matter since BIOS
> people
> >> won't test against it. 1.0 specifies that _PTS is
On Tuesday 08 January 2008 00:09, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > No. I mean call the bit PG_private2. That way non-pagecache and
> > filesystems that don't use fscache can use it.
>
> The bit is called PG_owner_priv_2, and then 'subclassed' to PG_fscache,
> much
wonder why free_pages_check mm/page_alloc.c is using bit OR than logical OR
@@ -450,9 +450,9 @@ static inline void __free_one_page(struc
static inline int free_pages_check(struct page *page)
{
- if (unlikely(page_mapcount(page) |
- (page->mapping != NULL) |
-
Allow dma "attributes" to be passed to dma_map_*/dma_unmap_*
implementations on x86_64.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
arch/x86/kernel/pci-calgary_64.c | 13 -
arch/x86/kernel/pci-gart_64.c| 27 +--
just found that when kexec 2.6.24-rc7 from RHEL 5.1 kernel got
Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 2000
Bad page state in process 'swapper'
page:e2000418
Allow dma "attributes" to be used by dma_map_*/dma_unmap_*
implementations on the ia64/sn2 architecture. (This one also
includes some changes to lib/swiotlb.c which aren't specific
to ia64/sn2.)
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
arch/ia64/sn/pci/pci_dma.c | 45
Place the definition of enum dma_data_direction in its own
include file, and add the definition of enum dma_data_attr
and some simple routines for manipulating the direction and
attributes.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
dma-direction.h | 53
The following patchset allows additional "attributes" to be
passed to dma_map_*/dma_unmap_* implementations. (The reason
why this is useful/necessary has been mentioned several times,
most recently here:
http://marc.info/?l=linux-kernel=119258541412724=2.)
This is incomplete in that only ia64
!Congratulations! You have won.
Contact Dr.F.Drenthe.
Tel/Fax no:+31 847 549 511.
Email: [EMAIL PROTECTED]
For your prize fund of $1,000,000,00 USD(your e-mail ID won in a random computer
ballot program for Internet users.
Yours Sincerely,
Mrs. Kate Veldhuizen,
www.lotto.nl
Your Winning
Sometimes cpu_idle_wait gets stuck because it might miss CPUS that are
already in idle, have no tasks waiting to run and have no interrupts
going to them. This is common on bootup when switching cpu idle
governors.
This patch accounts for CPUs already in idle.
Background:
---
I notice
V1->V2:
- Special consideration for IA64: Add the ability to specify
arch specific per cpu flags
V2->V3:
- remove .data.percpu attribute from DEFINE_PER_CPU for non-smp case.
The arch definitions are all the same. So move them into linux/percpu.h.
We cannot move DECLARE_PER_CPU since some
This patchset simplifies the code that arches need to maintain to support
per cpu functionality. Most of the code is moved into arch independent
code. Only a minimal set of definitions is kept for each arch.
The patch also unifies the x86 arch so that there is only a single
asm-x86/percpu.h
x86_32 only provides a special way to obtain the local per cpu area offset
via x86_read_percpu. Otherwise it can fully use the generic handling.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis
V2->V3:
- use generic percpy_modcopy()
Sparc64 has a way of providing the base address for the per cpu area of the
currently executing processor in a global register.
Sparc64 also provides a way to calculate the address of a per cpu area
from a base address instead of performing an array lookup.
V1->V2:
- add support for PER_CPU_ATTRIBUTES
V2->V3:
- fix generic smp percpu_modcopy to use per_cpu_offset() macro.
Add the ability to use generic/percpu even if the arch needs to override
several aspects of its operations. This will enable the use of generic
percpu.h for all arches.
An arch
x86_64 provides an optimized way to determine the local per cpu area
offset through the pda and determines the base by accessing a remote
pda.
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter
V1->V2:
- Merge fixes
- Remove transitional check for PER_CPU_ATTRIBUTES from linux/percpu.h
V2-.V3:
- use generic percpy_modcopy()
ia64 has a special processor specific mapping that can be used to locate the
offset for the current per cpu area.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Form a single percpu.h from percpu_32.h and percpu_64.h. Both are now pretty
small so this is simply adding them together.
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL
V1->V2:
- Use def_bool as suggested by Randy.
The use of the __GENERIC_PERCPU is a bit problematic since arches
may want to run their own percpu setup while using the generic
percpu definitions. Replace it through a kconfig variable.
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL
V2->V3:
On Thu, 29 Nov 2007, Martin Schwidefsky wrote:
> On Wed, 2007-11-28 at 13:09 -0800, Christoph Lameter wrote:
> > s390 has a special way to determine the pointer to a per cpu area
> > plus there is a way to access the base of the per cpu area of the
> > currently executing processor.
> >
V1->V2:
- add missing #endif
V2->V3:
- use generic percpy_modcopy()
Powerpc has a way to determine the address of the per cpu area of the
currently executing processor via the paca and the array of per cpu
offsets is avoided by looking up the per cpu area from the remote
paca's (copying x86_64).
> The PIT usage for calibrating the delay loop can be moderated, if need
> by, by using the PC BIOS which by definition uses the PIT correctly it
> its int 15 function 83 call.. Just do it before coming up in a state
> where the PC BIOS int 15h calls no longer work. I gave code to do this
>
On Mon, Jan 07, 2008 at 03:25:00AM -0700, Eric W. Biederman wrote:
> I think someone failed to notice that using /proc/sys slowed to a crawl
> in that event, and now that I am doing a lookup on register it seems to
> showing up in the benchmarks.
The directory that is problematic rarely gets
On Mon, 2008-01-07 at 10:19 -0800, Kok, Auke wrote:
> Shaohua Li wrote:
> > On Thu, 2008-01-03 at 11:33 -0800, Kok, Auke wrote:
> >> Shaohua Li wrote:
> >>> PCI Express ASPM defines a protocol for PCI Express components in the D0
> >>> state to reduce Link power by placing their Links into a low
H. Peter Anvin wrote:
And shoot the designer of this particular microcontroller firmware.
Well, some days I want to shoot the "designer" of the entire Wintel
architecture... it's not exactly "designed" by anybody of course, and
today it's created largely by a collection of Taiwanese and
On Tue, 2008-01-08 at 09:02 +1100, Michael Ellerman wrote:
> On Thu, 2008-01-03 at 14:15 +0800, Shaohua Li wrote:
> > PCI Express ASPM defines a protocol for PCI Express components in the D0
> > state to reduce Link power by placing their Links into a low power state
> > and instructing the other
native_read_tsc is needed by modules, so it should be exported.
make -C /home/jeremy/hg/xen/paravirt/linux O=/home/jeremy/hg/xen/paravirt/linux-x86_64
Using /home/jeremy/hg/xen/paravirt/linux as source for kernel
GEN /home/jeremy/hg/xen/paravirt/linux-x86_64/Makefile
CHK
J. Bruce Fields wrote:
> On Sat, Jan 05, 2008 at 09:39:35PM +, Al Viro wrote:
>> On Sat, Jan 05, 2008 at 01:06:17PM -0800, Arjan van de Ven wrote:
>>> The http://www.kerneloops.org website collects kernel oops and
>>> warning reports from various mailing lists and bugzillas as well
>>> as
Dear all
A lot of google searches reflect that, the latest kernel supporting
Huawei EC321 CDMA PCCARD is 2.6.17. My version (2.6.22-14 on Ubuntu)
doesn't work.
I am not sure if I should file a bug somewhere or how to contact the
right person. I see another version of this card (Huawei E220) was
Andi Kleen wrote:
THREAD_ORDER should be used on 32bit too.
32bit also has the equivalent of irq stacks (quite similar)
and exception stacks (somewhat different). Currently they use
other defines, but they could use the same. Also i386 has varying
irqstack orders disabling them with 8k
from Vince Fuller <[EMAIL PROTECTED]>
This set of diffs modify the 2.6.20 kernel to enable use of the 240/4
(aka "class-E") address space as consistent with the Internet Draft
draft-fuller-240space-00.txt.
Signed-off-by: Vince Fuller <[EMAIL PROTECTED]>
---
--- include/linux/in.h.orig
On Mon, 7 January 2008 15:23:00 -0800, Andrew Morton wrote:
> On Sun, 6 Jan 2008 14:56:01 +0100
> J__rn Engel <[EMAIL PROTECTED]> wrote:
You found a new one! That make a round dozen, I believe.
http://logfs.org/logfs/joern
> > - * Copyright (C) 2004-2006 Jörn Engel <[EMAIL PROTECTED]>
> > + *
[EMAIL PROTECTED] wrote:
> I am running 2.6.23 kernel on a DUAL core and QUAD core i386 boxes and
> after everyboot, when the ethernet traffic starts i get this warning.
>
> All the ports in the system are e1000 and i am using the kernel e1000
> driver.
[added netdev to the Cc:]
can you repro
Andi Kleen wrote:
On Mon, Jan 07, 2008 at 05:31:58PM -0600, Robert Hancock wrote:
Jesse Barnes wrote:
Hmm -- I didn't see Jesse's mail?
I believe that such a change is in Greg KH's tree. So -mm (with both
trees) would probably work.
Yes 2.6.24-rc6-mm1 works, but plain git-x86 does not:
It's possible that the values used in and returned from jiffies_to_usecs() are
incorrect because of truncation when variables of type u64 are involved. So a
function specific to that type is used instead.
Updated from previous submission with feedback from Peter Anvin.
Diff'd against:
On Mon, Jan 07, 2008 at 05:31:58PM -0600, Robert Hancock wrote:
> Jesse Barnes wrote:
Hmm -- I didn't see Jesse's mail?
> I believe that such a change is in Greg KH's tree. So -mm (with both
> trees) would probably work.
Yes 2.6.24-rc6-mm1 works, but plain git-x86 does not:
PCI: MCFG
Hi,
I am running 2.6.23 kernel on a DUAL core and QUAD core i386 boxes and
after everyboot, when the ethernet traffic starts i get this warning.
All the ports in the system are e1000 and i am using the kernel e1000
driver.
Jan 7 22:31:00 localhost [warning] WARNING: at kernel/softirq.c:139
HI all...
On Sun, 6 Jan 2008 14:19:16 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
> It's been two weeks since rc6, but let's face it, with xmas and new years
> (and birthdays) in between, there hasn't actually been a lot of working
> days, and the incremental patch from -rc6 is
On Jan 7, 2008 6:54 PM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> Well, now you're saying 2.6.23.12 is also affected, so this doesn't seem to
> be a recent regression in fact?
>
I have run 2.6.23 series before but my usage pattern seems to have not
triggered the bug before.
But yes, this is
On Monday, 7 of January 2008, Rafael J. Wysocki wrote:
> On Monday, 7 of January 2008, Pavel Machek wrote:
> > Unify arch/x86/kernel/acpi/sleep*.c
> >
> > Pretty trivial unification; when two functions differed, it was
> > usually in error handling, and better of the two was picked up.
> >
> >
Laurès wrote:
Hello,
Dear kernel developers, my dmesg asked me to report this, so here I go ;)
Here is what I found in my dmesg: "anticipatory: forced dispatching is
broken (nr_sorted=1), please report this".
- First, let's talk about the machine: it's quite pushed so maybe the
cause is me
On Monday, 7 of January 2008, Alan Stern wrote:
> On Mon, 7 Jan 2008, Rafael J. Wysocki wrote:
[--snip--]
>
> > Okay, well, now I'm leaning towards the asynchronous approach.
> >
> > I'll prepare a new patch and send it later today.
>
> Okay.
Appended is what I managed to put together today.
On Mon, 2008-01-07 at 15:10 -0800, Andrew Morton wrote:
> On Sun, 06 Jan 2008 14:46:14 +0100
> Philipp Zabel <[EMAIL PROTECTED]> wrote:
>
> > The DS1WM driver incorrectly infers the IAS bit (1-wire interrupt active
> > high) from IRQ settings. There are devices that have IAS=0 but still need
> >
David P. Reed wrote:
And actually, if I had looked at the /sys/bus/pnp definitions, rather
than /proc/ioports, I would have noticed that port 80 was part of a
PNP0C02 resource set. That means exactly one thing: ACPI says that
port 80 is NOT free to be used, for delays or anything else.
On another topic. I have indeed determined what device uses port 80 on
Quanta AMD64 laptops from HP.
I had lunch with Jim Gettys of OLPC a week ago; he's an old friend since
he worked on the original X windows system. After telling him my story
about port 80, he mentioned that the OLPC XO
Allen Martin wrote:
Dunno about the NVidia version.
Theirs works rather differently - the GO bit is there, but there's
another append register which is used to tell the controller
that a new
tag has been added to the CPB list.
The only thing we currently use the GO bit for is to switch
1 - 100 of 826 matches
Mail list logo
