Re: 2.6.13-rc3-mm3
> - There's a pretty large x86_64 update here which naughty maintainer wants > in 2.6.13. Extra testing, please. Is still regressed as of 2.6.12 for me, at least. Crashes in TSC sync. Talked to Andi about it at OLS, but then drank too much to remember the conclusion ... however, it's still broken ;-) Matrix is here (see left hand column). http://test.kernel.org/ Example boot log is here: http://test.kernel.org/9447/debug/console.log - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
Michael Krufky <[EMAIL PROTECTED]> wrote: > > Sadly, I must report that yes, the problem still intermittently occurs > in 2.6.13-rc4 :-( I'm the one that tested on the Shuttle FT61 > Motherboard. Never has a problem in windows and never in 2.6.11 and > earlier. > > I first noticed this problem sometime during 2.6.12-rc series. Sigh. I think it would help if you could generate a new report, please. We need a super-easy way for people to do bisection searching. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Time Flies (Twice as Fast)
Kurt Did you try with the "no_timer_check" boot option? HTH Olivier. On Thu, 2005-07-28 at 22:03 -0400, Kurt Wall wrote: > Hola, > > I have an eMachines T6212 Opteron system on which the system clock > seems to run at ~twice the speed of the wall clock. The main board > is an ASUS K8 of some description with at ATI SB400 southbridge and > an ATI RS480 northbridge. Kernel version is 2.6.12.3. > > If I disable ACPI, the clock slows down to what seems to be the proper > speed, but then my NIC doesn't work, presumably because it shares > an interrupt with something else. > > I've tried booting with clock=tsc and clock=pit to no effect. Based > on my review of the list archives, there appears to be issues with > the chipset, but I haven't been able to sort out what the real problem > is and the appropriate solution. > > There's an ACPI error that seems potentially troublesome: > > ACPI: Subsystem revision 20050309 > ACPI-0352: *** Error: Looking up [\_SB_.PCI0.LPC0.LNK0] in namespace, > AE_NOT_FOUND > search_node 81001fec9440 start_node 81001fec9440 return_node > > > I also see this message from the PCI subsystem: > > PCI: Ignoring BAR0-3 of IDE controller :00:14.1 > > As a starting point, I've attached lspci output and the boot log. I'm > willing to provide more information and try patches and such. > > Thanks. > > Kurt > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
Andrew Morton wrote: Michael Krufky <[EMAIL PROTECTED]> wrote: I am cc'ing your message to Vojtech Pavlik, the INPUT DRIVERS kernel maintainer. Vojtech, I figured these should be sent to you. If I am wrong, please redirect them to the correct person / list and let us know. Thank you. Frank Peters wrote: On Fri, 24 Jun 2005 12:10:18 -0400 Michael Krufky <[EMAIL PROTECTED]> wrote: I am having the same problem with my Shuttle FT61 motherboard, although I have not tried to disable ACPI... Until now I thought I just had a faulty keyboard, as my method to fix this was to unplug the keyboard and plug it back in after bootup. When this happens, I see this in dmesg as the last line: input: AT Translated Set 2 keyboard on isa0060/serio0 I am also having problems with my AUX mouse, as seen in message Subject: 2.6.12-rc5-mm1 breaks serio: i8042 AUX port Frank, are you having problems with your ps/2 mouse port as well? I am so glad that you asked this. I have not been able to get my ps/2 mouse to function with any 2.6.x or 2.4.x kernel (same ASUS MB). The problem is already so long standing that I have completely given up on it and use a serial mouse exclusively and no longer bother with ps/2. (I also hate to report that since I dual boot with MS Windows, the ps/2 mouse functions properly under the same conditions with MS Windows 2K. The hardware cannot be at fault.) As a clarification, I have been having these keyboard problems intermittently, regardless of whether I'm using -mm or mainline kernel. I was NOT having this problem in 2.6.11 I wasn't having the psaux mouse problems in 2.6.11 either I unplugged my psaux mouse from that machine before 2.6.12-mainline was released, so I don't know if those symptoms are still present. Actually, my keyboard problems began with kernel-2.6.11, but were quickly resolved when I used the following parameter in my lilo.conf file: i8042.nomux When I use this parameter, or any other i8042 specific parameter, with kernel-2.6.12, there is no effect. The keyboard still occasionally comes up dead. Thanks for the information on unplugging and re-plugging the keyboard. I'll give that a try soon. Guys, are these problems fixed in 2.6.13-rc4? If not, please cc linux-kernel on the reply, thanks. Sadly, I must report that yes, the problem still intermittently occurs in 2.6.13-rc4 :-( I'm the one that tested on the Shuttle FT61 Motherboard. Never has a problem in windows and never in 2.6.11 and earlier. I first noticed this problem sometime during 2.6.12-rc series. -- Michael Krufky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NLS for HFS and "mount" tool.
I've got no reply so i resend this letter. Roman, i'd like to finish the work and would like to ask you what is wrong with your version of the NLS support for MacHFS. I expected it to appear in v 2.6.12 but there's no it. I would like to proceed basing on it if you insist. Also i would like to ask someone who is responsible for "mount" tool. I'd suggest to modify it in order to support several lines in fstab with the same device and mount points but different filesystems and options. For example: /dev/cdrom /mnt/cdrom udf,iso9660 user,noauto,iocharset=koi8-r 0 0 /dev/cdrom /mnt/cdrom hfsplus user,noauto,nls=koi8-r 0 0 /dev/cdrom /mnt/cdrom hfs user,noauto,iocharset=koi8-r,codepage=10007 0 0 Currently mount will stop at the first line and produce an error if the filesystem is not udf or iso (in the example). It will ignore the following lines. This would greatly improve handling of removable devices. Is there something (standards for example) which could prevent from this implementation? -- Kind regards, Pavel Fedin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NMI watch dog notify patch
Keith Owens <[EMAIL PROTECTED]> wrote:
>
> >I had though that too, but it does not allow recovery (i.e. lets reset
> >the watchdog and try again).
>
> die_nmi() returns to nmi_watchdog_tick(), nmi_watchdog_tick does the
> reset and continues. Patch below.
>
> >Hmm.. just looked at traps.c. Seems die_nmi is NOT called from the nmi
> >trap, only from the watchdog. Also, there is a notify in the path to
> >the other nmi stuff.
>
> I was looking at unknown_nmi_panic_callback(), which also calls
> die_nmi().
>
> traps.c already has several notify_die() calls, nmi.c has none. It is
> cleaner to keep all the notification in traps.c, with this small change
> to nmi.c to cope with die_nmi() returning.
>
> Index: linux/arch/i386/kernel/nmi.c
> ===
> --- linux.orig/arch/i386/kernel/nmi.c2005-07-28 17:22:06.735038510
> +1000
> +++ linux/arch/i386/kernel/nmi.c 2005-07-29 15:19:00.371196596 +1000
> @@ -494,8 +494,10 @@ void nmi_watchdog_tick (struct pt_regs *
>* wait a few IRQs (5 seconds) before doing the oops ...
>*/
> alert_counter[cpu]++;
> -if (alert_counter[cpu] == 5*nmi_hz)
> +if (alert_counter[cpu] == 5*nmi_hz) {
> die_nmi(regs, "NMI Watchdog detected LOCKUP");
> +alert_counter[cpu] = 0;
> +}
> } else {
> last_irq_sums[cpu] = sum;
> alert_counter[cpu] = 0;
That all makes sense - let's go that way?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12 hangs on boot
"Alexander Y. Fomichev" <[EMAIL PROTECTED]> wrote:
>
> G' day
>
> I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8 GHz
> [ MoBo: Intel E7520, intel 82801 ]
> but kernel hangs on boot right after records:
>
> Booting processor 2/1 rip 6000 rsp 8100023dbf58
> Initializing CPU#2
>
> ( below is a link to full boot trace, actually -git3 but no differences)
> http://sysadminday.org.ru/2.6.12-hang-on-boot/2.6.12-git3-hang
>
> An attempt to enable debug:
> +CONFIG_ACPI_DEBUG=y
> +CONFIG_DEBUG_SLAB=y
> +CONFIG_DEBUG_PREEMPT=y
> +CONFIG_DEBUG_SPINLOCK=y
> +CONFIG_DEBUG_SPINLOCK_SLEEP=y
> +CONFIG_DEBUG_KOBJECT=y
> +CONFIG_DEBUG_INFO=y
> +CONFIG_INIT_DEBUG=y
> gives rather strange result, kernel boots successfully ( with a lot of
> debuging messages of course but i couldn't find something suspicious )
> http://sysadminday.org.ru/2.6.12-hang-on-boot/2.6.12-git3-debug
>
> config for 2.6.12 have been taken from previous one, only
> 'make oldconfig' has been made.
> http://sysadminday.org.ru/2.6.12-hang-on-boot/2.6.12-git3.config
>
> Hang 100% reproducible on at least two of my EM64T hosts.
> ( actualy the same configuration as of MoBo/CPU )
Is this still happening in 2.6.13-rc4?
If so, could you please test 2.6.13-rc4 plus the below fix?
Thanks.
From: [EMAIL PROTECTED] (Eric W. Biederman)
sync_tsc was using smp_call_function to ask the boot processor to report
it's tsc value. smp_call_function performs an IPI_send_allbutself which is
a broadcast ipi. There is a window during processor startup during which
the target cpu has started and before it has initialized it's interrupt
vectors so it can properly process an interrupt. Receveing an interrupt
during that window will triple fault the cpu and do other nasty things.
Why cli does not protect us from that is beyond me.
The simple fix is to match ia64 and provide a smp_call_function_single.
Which avoids the broadcast and is more efficient.
This certainly fixes the problem of getting stuck on boot which was very
easy to trigger on my SMP Hyperthreaded Xeon, and I think it fixes it for
the right reasons.
I believe this patch suffers from apicid versus logical cpu number
confusion. I copied the basic logic from smp_send_reschedule and I can't
find where that translates from the logical cpuid to apicid. So it isn't
quite correct yet. It should be close enough that it shouldn't be too hard
to finish it up.
More bug fixes after I have slept but I figured I needed to get this
one out for review.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/smp.c | 65 +++
arch/x86_64/kernel/smpboot.c | 18 +++
include/asm-x86_64/smp.h |2 +
3 files changed, 79 insertions(+), 6 deletions(-)
diff -puN
arch/x86_64/kernel/smpboot.c~x86_64-sync_tsc-fix-the-race-so-we-can-boot
arch/x86_64/kernel/smpboot.c
---
devel/arch/x86_64/kernel/smpboot.c~x86_64-sync_tsc-fix-the-race-so-we-can-boot
2005-07-28 22:07:55.0 -0700
+++ devel-akpm/arch/x86_64/kernel/smpboot.c 2005-07-28 22:07:55.0
-0700
@@ -280,7 +280,7 @@ get_delta(long *rt, long *master)
return tcenter - best_tm;
}
-static __cpuinit void sync_tsc(void)
+static __cpuinit void sync_tsc(unsigned int master)
{
int i, done = 0;
long delta, adj, adjust_latency = 0;
@@ -294,9 +294,17 @@ static __cpuinit void sync_tsc(void)
} t[NUM_ROUNDS] __cpuinitdata;
#endif
+ printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n",
+ smp_processor_id(), master);
+
go[MASTER] = 1;
- smp_call_function(sync_master, NULL, 1, 0);
+ /* It is dangerous to broadcast IPI as cpus are coming up,
+* as they may not be ready to accept them. So since
+* we only need to send the ipi to the boot cpu direct
+* the message, and avoid the race.
+*/
+ smp_call_function_single(master, sync_master, NULL, 1, 0);
while (go[MASTER]) /* wait for master to be ready */
no_cpu_relax();
@@ -340,16 +348,14 @@ static __cpuinit void sync_tsc(void)
printk(KERN_INFO
"CPU %d: synchronized TSC with CPU %u (last diff %ld cycles, "
"maxerr %lu cycles)\n",
- smp_processor_id(), boot_cpu_id, delta, rt);
+ smp_processor_id(), master, delta, rt);
}
static void __cpuinit tsc_sync_wait(void)
{
if (notscsync || !cpu_has_tsc)
return;
- printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n", smp_processor_id(),
- boot_cpu_id);
- sync_tsc();
+ sync_tsc(boot_cpu_id);
}
static __init int notscsync_setup(char *s)
diff -puN arch/x86_64/kernel/smp.c~x86_64-sync_tsc-fix-the-race-so-we-can-boot
arch/x86_64/kernel/smp.c
--- devel/arch/x86_64/kernel/smp.c~x86_64-sync_tsc-fix-the-race-so-we-can-boot
2005-07-28
Re: [PATCH] NMI watch dog notify patch
On Thu, 28 Jul 2005 21:16:56 -0700,
George Anzinger wrote:
>Keith Owens wrote:
>> On Thu, 28 Jul 2005 13:31:58 -0700,
>> George Anzinger wrote:
>>
>>>I have been doing some work on kgdb to pull a few of it "fingers" out of
>>>various places in the kernel. This is the final location where we have
>>>a kgdb intercept not covered by a notify.
>>
>>
>> I like the idea, but the hook should be in die_nmi(), not in the
>> watchdog, using the reason that is already passed into die_nmi.
>> die_nmi() is also called for a real NMI.
>>
>I had though that too, but it does not allow recovery (i.e. lets reset
>the watchdog and try again).
die_nmi() returns to nmi_watchdog_tick(), nmi_watchdog_tick does the
reset and continues. Patch below.
>Hmm.. just looked at traps.c. Seems die_nmi is NOT called from the nmi
>trap, only from the watchdog. Also, there is a notify in the path to
>the other nmi stuff.
I was looking at unknown_nmi_panic_callback(), which also calls
die_nmi().
traps.c already has several notify_die() calls, nmi.c has none. It is
cleaner to keep all the notification in traps.c, with this small change
to nmi.c to cope with die_nmi() returning.
Index: linux/arch/i386/kernel/nmi.c
===
--- linux.orig/arch/i386/kernel/nmi.c 2005-07-28 17:22:06.735038510 +1000
+++ linux/arch/i386/kernel/nmi.c2005-07-29 15:19:00.371196596 +1000
@@ -494,8 +494,10 @@ void nmi_watchdog_tick (struct pt_regs *
* wait a few IRQs (5 seconds) before doing the oops ...
*/
alert_counter[cpu]++;
- if (alert_counter[cpu] == 5*nmi_hz)
+ if (alert_counter[cpu] == 5*nmi_hz) {
die_nmi(regs, "NMI Watchdog detected LOCKUP");
+ alert_counter[cpu] = 0;
+ }
} else {
last_irq_sums[cpu] = sum;
alert_counter[cpu] = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] libata ATAPI alignment
So, one thing that's terribly ugly about SATA ATAPI is that we need to
pad DMA transfers to the next 32-bit boundary, if the length is not
evenly divisible by 4.
Messing with the scatterlist to accomplish this is terribly ugly
no matter how you slice it. One way would be to create my own
scatterlist, via memcpy and then manual labor. Another way would be
to special case a pad buffer, appending it onto the end of various
scatterlist code.
Complicating matters, we currently must support two methods of data
buffer submission: a single kernel virtual address, or a struct
scatterlist.
Review is requested by any and all parties, as well as suggestions for
a prettier approach.
This is one of the last steps needed to get ATAPI going.
diff --git a/drivers/scsi/ahci.c b/drivers/scsi/ahci.c
--- a/drivers/scsi/ahci.c
+++ b/drivers/scsi/ahci.c
@@ -44,7 +44,7 @@
enum {
AHCI_PCI_BAR= 5,
- AHCI_MAX_SG = 168, /* hardware max is 64K */
+ AHCI_MAX_SG = 300, /* hardware max is 64K */
AHCI_DMA_BOUNDARY = 0x,
AHCI_USE_CLUSTERING = 0,
AHCI_CMD_SLOT_SZ= 32 * 32,
@@ -197,7 +197,7 @@ static Scsi_Host_Template ahci_sht = {
.eh_strategy_handler= ata_scsi_error,
.can_queue = ATA_DEF_QUEUE,
.this_id= ATA_SHT_THIS_ID,
- .sg_tablesize = AHCI_MAX_SG,
+ .sg_tablesize = AHCI_MAX_SG - 1,
.max_sectors= ATA_MAX_SECTORS,
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
@@ -313,8 +313,15 @@ static int ahci_port_start(struct ata_po
return -ENOMEM;
memset(pp, 0, sizeof(*pp));
+ ap->pad = dma_alloc_coherent(dev, ATA_DMA_PAD_BUF_SZ, >pad_dma,
GFP_KERNEL);
+ if (!ap->pad) {
+ kfree(pp);
+ return -ENOMEM;
+ }
+
mem = dma_alloc_coherent(dev, AHCI_PORT_PRIV_DMA_SZ, _dma,
GFP_KERNEL);
if (!mem) {
+ dma_free_coherent(dev, ATA_DMA_PAD_BUF_SZ, ap->pad,
ap->pad_dma);
kfree(pp);
return -ENOMEM;
}
@@ -390,6 +397,7 @@ static void ahci_port_stop(struct ata_po
ap->private_data = NULL;
dma_free_coherent(dev, AHCI_PORT_PRIV_DMA_SZ,
pp->cmd_slot, pp->cmd_slot_dma);
+ dma_free_coherent(dev, ATA_DMA_PAD_BUF_SZ, ap->pad, ap->pad_dma);
kfree(pp);
}
@@ -474,7 +482,8 @@ static void ahci_tf_read(struct ata_port
static void ahci_fill_sg(struct ata_queued_cmd *qc)
{
- struct ahci_port_priv *pp = qc->ap->private_data;
+ struct ata_port *ap = qc->ap;
+ struct ahci_port_priv *pp = ap->private_data;
unsigned int i;
VPRINTK("ENTER\n");
@@ -493,6 +502,24 @@ static void ahci_fill_sg(struct ata_queu
pp->cmd_tbl_sg[i].addr_hi = cpu_to_le32((addr >> 16) >> 16);
pp->cmd_tbl_sg[i].flags_size = cpu_to_le32(sg_len - 1);
}
+
+ /* if we added a small buffer, to pad xfer to next 32-bit bound,
+* add it to the s/g list here
+*/
+ if (qc->flags & ATA_QCFLAG_PADDED) {
+ dma_addr_t pad_addr = ap->pad_dma + (qc->tag * ATA_DMA_PAD_SZ);
+ u32 len;
+
+ /* fixup last s/g entry */
+ len = le32_to_cpu(pp->cmd_tbl_sg[i - 1].flags_size);
+ pp->cmd_tbl_sg[i - 1].flags_size =
+ cpu_to_le32(len - qc->pad_len);
+
+ /* append pad buffer to s/g list */
+ pp->cmd_tbl_sg[i].addr = cpu_to_le32(pad_addr & 0x);
+ pp->cmd_tbl_sg[i].addr_hi = cpu_to_le32((pad_addr >> 16) >> 16);
+ pp->cmd_tbl_sg[i].flags_size = cpu_to_le32(ATA_DMA_PAD_SZ - 1);
+ }
}
static void ahci_qc_prep(struct ata_queued_cmd *qc)
@@ -501,13 +528,16 @@ static void ahci_qc_prep(struct ata_queu
struct ahci_port_priv *pp = ap->private_data;
u32 opts;
const u32 cmd_fis_len = 5; /* five dwords */
+ unsigned int n_elem = qc->n_elem;
/*
* Fill in command slot information (currently only one slot,
* slot 0, is currently since we don't do queueing)
*/
- opts = (qc->n_elem << 16) | cmd_fis_len;
+ if (qc->flags & ATA_QCFLAG_PADDED)
+ n_elem++;
+ opts = (n_elem << 16) | cmd_fis_len;
if (qc->tf.flags & ATA_TFLAG_WRITE)
opts |= AHCI_CMD_WRITE;
if (is_atapi_taskfile(>tf))
diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -2144,6 +2144,8 @@ static void ata_sg_clean(struct ata_queu
struct ata_port *ap = qc->ap;
struct scatterlist *sg = qc->sg;
int dir = qc->dma_dir;
+ unsigned int copy_pad = 0;
+ void *pad_buf = NULL;
assert(qc->flags &
Re: 2.6.12-rc6-mm1
Dominik Karall <[EMAIL PROTECTED]> wrote:
>
> On Tuesday 07 June 2005 13:29, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc6/2.
> >6.12-rc6-mm1/
>
> After looking in my dmesg output today, I saw following error with
> 2.6.12-rc6-mm1, maybe it's usefull to you. I don't know when it exactly
> happens, cause I never used mono last time, I just did an emerge mono on my
> gentoo system, maybe this forced the failure.
>
> note: mono[26736] exited with preempt_count 1
> scheduling while atomic: mono/0x1001/26736
>
> Call Trace:{schedule+122} {vprintk+635}
>{cond_resched+56} {unmap_vmas+1587}
>{exit_mmap+128} {mmput+31}
>{do_exit+438}
> {__dequeue_signal+501}
>{do_group_exit+280}
> {get_signal_to_deliver+1575}
>{do_signal+162}
> {default_wake_function+0}
>{sys_rt_sigreturn+577}
> {sysret_signal+28}
>{ptregscall_common+103}
>
A couple of people reported this, but all seems to have gone quiet. Is it
fixed in later -mm's? Is 2.6.13-rc4 running OK?
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: include-linux-blkdevh-extern-inline-static-inline.patch added to -mm tree
On 7/29/05, Coywolf Qi Hunt <[EMAIL PROTECTED]> wrote: > On 7/29/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > The patch titled > > > > include/linux/blkdev.h: "extern inline" -> "static inline" > > > > has been added to the -mm tree. Its filename is > > > > include-linux-blkdevh-extern-inline-static-inline.patch > > > > ... > > > > > > > From: Adrian Bunk <[EMAIL PROTECTED]> > > > > "extern inline" doesn't make much sense. > > "extern inline" does make sense, and it does make sense here. please > backout this patch. Hint: the address of block_size() is referenced. > Sorry, I mistook put_int(arg, block_size(bdev)); as address reference. -- Coywolf Qi Hunt http://ahbl.org/~coywolf/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
Cal Peake <[EMAIL PROTECTED]> wrote: > > Hi, > > Getting this nastiness when probing snd-cs46xx: > > Unable to handle kernel paging request at virtual address 000a75a8 > ... > EIP is at sub_alloc+0x42/0x170 > ... > [] idr_get_new_above_int+0x78/0x120 > [] idr_get_new+0x1f/0x50 > [] get_inode_number+0x39/0x60 > [] proc_register+0x17/0xb0 > [] create_proc_entry+0x85/0xd0 > [] snd_create_proc_entry+0x20/0x30 [snd] > [] snd_info_register+0x44/0xb0 [snd] > [] snd_pcm_lib_preallocate_pages1+0x92/0xd0 [snd_pcm] > [] snd_pcm_lib_preallocate_pages_for_all+0x44/0x70 [snd_pcm] > [] snd_cs46xx_pcm_rear+0xe0/0x100 [snd_cs46xx] > [] snd_card_cs46xx_probe+0xf9/0x250 [snd_cs46xx] > [] pci_match_device+0x1d/0xb0 > [] __pci_device_probe+0x58/0x70 > [] pci_device_probe+0x2f/0x50 > [] driver_probe_device+0x38/0xb0 > [] __driver_attach+0x0/0x50 > [] __driver_attach+0x4c/0x50 > [] bus_for_each_dev+0x69/0x80 > [] driver_attach+0x26/0x30 > [] __driver_attach+0x0/0x50 > [] bus_add_driver+0x83/0xe0 > [] pci_register_driver+0x6d/0x90 > [] alsa_card_cs46xx_init+0xf/0x13 [snd_cs46xx] > [] sys_init_module+0x141/0x1d0 > [] syscall_call+0x7/0xb > > > 2.6.13-rc3-git9 is OK. I'll try poking around at the ALSA changes, see if > I can figure out which one is the culprit. The procfs inode IDR tree is scrogged. I'd be suspecting a random memory scribble. I'd suggest that you enable CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_everything_else and retest. If that doesn't show anything, try eliminating stuff from your kernel config. If it _is_ a scribble then there's a good chance that changing the config will simply make it disappear, or will make it manifest in different ways. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3: swsusp works (TP 600X)
> Perhaps the patch from Daniel Ritz to free the yenta IRQ on suspend > (attached) will help? Alas, when I went to apply it, patch said it was already there, and sure enough 2.6.13-rc3-mm2 does have it. One approach is to find out why PCMCIA cannot remove the socket power when using cardctl eject (assuming that the error is related to the swsusp failing). The error is puzzling because physically ejecting the card doesn't produce the message. I'll try to chase that one down, and welcome any hints on where to look or what debugging to turn on. I've looked in drivers/pcmcia/cs.c, which is where the error is printed, but no enlightenment dawned, and will try setting pcmcia debugging. -Sanjoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.8 -> 2.6.11 (+ata-dev patch) -- HDD is always on
Yaroslav Halchenko wrote: I've been running debian stable with 2.6.8 kernel but due to recent failure of the SATA harddrive I've decided to upgrade to 2.6.11 + libata patch (2.6.11-libata-dev1.patch.gz) and recent smartmontools After everything worked out and I decided to rest in piece but I've found that HDD LED light nomater what. It seems to turn off during BIOS checks and then kicks in 1-2 secs after kernel starts booting. No prominent harddrive activity noise can be heard but this drive is quite silent so it is hard to say. Does this happen in unpatched 2.6.12.3 or 2.6.13-rc4? QUESTION: LED constantly ON - does it signal about a problem or may be just that some status bit is hanging? Should I worry and try differen kernel version? YIKES: ran hddtemp /dev/sda and whole box hanged... SysRq keys - no effect... heh heh... reboot -> nothing in logs P.S. was ata-dev patch incorporated in recent kernel versions so I could use SMART with vanilla kernel? This is one of the reasons why SMART support is not yet in the mainline kernel! Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NMI watch dog notify patch
Keith Owens wrote: On Thu, 28 Jul 2005 13:31:58 -0700, George Anzinger wrote: I have been doing some work on kgdb to pull a few of it "fingers" out of various places in the kernel. This is the final location where we have a kgdb intercept not covered by a notify. I like the idea, but the hook should be in die_nmi(), not in the watchdog, using the reason that is already passed into die_nmi. die_nmi() is also called for a real NMI. I had though that too, but it does not allow recovery (i.e. lets reset the watchdog and try again). Hmm.. just looked at traps.c. Seems die_nmi is NOT called from the nmi trap, only from the watchdog. Also, there is a notify in the path to the other nmi stuff. -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Syncing single filesystem (slow USB writing)
On Friday 29 July 2005 07:50, Andrew Morton wrote: > Andrey Borzenkov <[EMAIL PROTECTED]> wrote: > > Mandrake always mounted USB sticks with sync option; it was effectively > > noop except for a patch that implemented limited dsync semantic. > > > > Now, when full sync support for FATis in kernel, moutning with sync > > became real pain. Writing speed dropped from 3MB/s to 30KB/s in my case > > (and I am not alone). > > Unfortunately I think we're just going to have to live with that. It is > right that fatfs behaves as it does, and unfortunate that some distros will > operate slowly. > Well, I was not going to suggest killing sync support in FAT :) > For reference: how does mandrake implement this? Just in /etc/fstab? How > should we tell other people to fix this? > Yes, just fstab option. It has been "fixed" a couple of days ago by removing sync but I am going to test effect of dsync; it should behave more or less as before and provide at least some level of fs consistency. > > One idea how to improve situation - continue to mount with dsync (having > > basically old case) and do frequent sync of filesystem (this culd be > > started as HAL callout or whatever). Unfortunately, I could not find a > > way to request a sync (flush) of single mount point or block device. Have > > I missed something? > > It's trivial to do in-kernel but no, I'm afraid there isn't a userspace > interface for this. Oh well, let's do it in kernel to check if it is worth hassle. Thanks pgprYEUsfbKsH.pgp Description: PGP signature
2.6.8 -> 2.6.11 (+ata-dev patch) -- HDD is always on
I've been running debian stable with 2.6.8 kernel but due to recent failure of the SATA harddrive I've decided to upgrade to 2.6.11 + libata patch (2.6.11-libata-dev1.patch.gz) and recent smartmontools After everything worked out and I decided to rest in piece but I've found that HDD LED light nomater what. It seems to turn off during BIOS checks and then kicks in 1-2 secs after kernel starts booting. No prominent harddrive activity noise can be heard but this drive is quite silent so it is hard to say. SATA drivers were compiled in the kernel to don't mess with initrd. QUESTION: LED constantly ON - does it signal about a problem or may be just that some status bit is hanging? Should I worry and try differen kernel version? YIKES: ran hddtemp /dev/sda and whole box hanged... SysRq keys - no effect... heh heh... reboot -> nothing in logs Detailed information on the system and drives (outputs of smartctl -a) can be found http://www.onerussian.com/Linux/bugs/ata/ Thank you in advance for ideas P.S. was ata-dev patch incorporated in recent kernel versions so I could use SMART with vanilla kernel? -- Yaroslav Halchenko Graduate Student CS Dept. UNM, ABQ Linux User 17 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc4 (snd-cs46xx)
Hi, Getting this nastiness when probing snd-cs46xx: Unable to handle kernel paging request at virtual address 000a75a8 printing eip: c01afe52 *pde = Oops: [#1] Modules linked in: snd_cs46xx gameport snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page_alloc ipt_state ipt_REJECT ipt_LOG ip_conntrack iptable_filter ip_tables nfs lockd sunrpc cifs smbfs hfsplus udf isofs zlib_inflate ntfs msdos vfat fat nls_utf8 nls_iso8859_1 nls_cp437 nls_base e100 mii usb_storage sd_mod scsi_mod usbhid ohci_hcd ehci_hcd usbcore parport_pc parport psmouse pcspkr ide_cd cdrom floppy loop radeon drm nvidia_agp agpgart thermal processor fan button ac CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010246 (2.6.13-rc4) EIP is at sub_alloc+0x42/0x170 eax: 0440 ebx: 0022 ecx: edx: f7c3cd5c esi: 0440 edi: 000a75a8 ebp: esp: f7c3cd44 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 762, threadinfo=f7c3c000 task=f7df4550) Stack: f7c3cd5c 0020 0440 0440 c1cdf26c c1ceaf54 c1cdf260 00d0 f7736018 c1cdf26c 0002 f7733f60 c1ceaf54 c0335a74 c01afff8 c0335a74 f7c3cda0 Call Trace: [] idr_get_new_above_int+0x78/0x120 [] idr_get_new+0x1f/0x50 [] get_inode_number+0x39/0x60 [] proc_register+0x17/0xb0 [] create_proc_entry+0x85/0xd0 [] snd_create_proc_entry+0x20/0x30 [snd] [] snd_info_register+0x44/0xb0 [snd] [] snd_pcm_lib_preallocate_pages1+0x92/0xd0 [snd_pcm] [] snd_pcm_lib_preallocate_pages_for_all+0x44/0x70 [snd_pcm] [] snd_cs46xx_pcm_rear+0xe0/0x100 [snd_cs46xx] [] snd_card_cs46xx_probe+0xf9/0x250 [snd_cs46xx] [] pci_match_device+0x1d/0xb0 [] __pci_device_probe+0x58/0x70 [] pci_device_probe+0x2f/0x50 [] driver_probe_device+0x38/0xb0 [] __driver_attach+0x0/0x50 [] __driver_attach+0x4c/0x50 [] bus_for_each_dev+0x69/0x80 [] driver_attach+0x26/0x30 [] __driver_attach+0x0/0x50 [] bus_add_driver+0x83/0xe0 [] pci_register_driver+0x6d/0x90 [] alsa_card_cs46xx_init+0xf/0x13 [snd_cs46xx] [] sys_init_module+0x141/0x1d0 [] syscall_call+0x7/0xb Code: 08 8b 3a c7 44 8c 1c 00 00 00 00 49 89 4c 24 14 8d 2c 89 8d b6 00 00 00 00 8b 44 24 10 89 e9 8d 54 24 18 d3 f8 89 44 24 0c 89 c6 <8b> 07 83 e6 1f c7 44 24 04 20 00 00 00 89 14 24 89 74 24 08 f7 2.6.13-rc3-git9 is OK. I'll try poking around at the ALSA changes, see if I can figure out which one is the culprit. thx, -cp -- "Democracy can learn some things from Communism; for example, when a Communist politician is through, he is through." -- Unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Syncing single filesystem (slow USB writing)
Andrey Borzenkov <[EMAIL PROTECTED]> wrote: > > Mandrake always mounted USB sticks with sync option; it was effectively noop > except for a patch that implemented limited dsync semantic. > > Now, when full sync support for FATis in kernel, moutning with sync became > real pain. Writing speed dropped from 3MB/s to 30KB/s in my case (and I am > not alone). Unfortunately I think we're just going to have to live with that. It is right that fatfs behaves as it does, and unfortunate that some distros will operate slowly. For reference: how does mandrake implement this? Just in /etc/fstab? How should we tell other people to fix this? > One idea how to improve situation - continue to mount with dsync (having > basically old case) and do frequent sync of filesystem (this culd be started > as HAL callout or whatever). Unfortunately, I could not find a way to request > a sync (flush) of single mount point or block device. Have I missed > something? It's trivial to do in-kernel but no, I'm afraid there isn't a userspace interface for this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3: swsusp works (TP 600X)
> So, in short, problem is that if you leave prism54 card in, even > with module removed, swsusp hangs, right? Right, in some circumstances. To narrow them down I spent many hours rebooting into combinations of runlevels and loaded modules. It is reproducible even in single-user mode. The various permutations, all from booting single user with almost no modules loaded (cmdline: idebus=66 apm=off acpi=force pci=noacpi single) card: prism54 card/xircom Ethernet+modem card/no card cardctl eject: done before the hibernate/ not done before the hibernate The one combination that always breaks is to have the prism54 card in, then do 'cardctl eject', which always produces: [4295438.17] PCMCIA: socket e233c02c: *** DANGER *** unable to remove socket power If I then use a simple hibernate script (basically just unload prism54, then echo disk > /sys/power/state), swsusp doesn't write the pages. These are the only modules loaded before the swsusp begins: pcmcia 34276 0 crc32 3808 1 pcmcia intel_agp 20188 1 firmware_class 7936 1 pcmcia yenta_socket 23244 3 rsrc_nonstatic 11776 1 yenta_socket pcmcia_core39508 3 pcmcia,yenta_socket,rsrc_nonstatic agpgart29800 1 intel_agp If I don't do 'cardctl eject', or do 'cardctl eject' and 'cardctl insert', then run the hibernate script (which unloads prism54), it hibernates fine. With no card in the slot, all is well. With the xircom card in the slot, hibernation works fine if I don't do 'cardctl eject' first. If I do 'cardctl eject' that produces the same DANGER message as with the prism54 card. But hibernation still works, although it seems a bit suspect: As it is hibernating, messages appear about it enabling eth0. Here's the lspci for the xircom card: :06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) :06:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) (prog-if 02 [16550]) And lspci -vv for the prism54: :06:00.0 Network controller: Intersil Corporation Intersil ISL3890 [Prism GT/Prism Duette] (rev 01) Subsystem: Intersil Corporation: Unknown device Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [nosave pfn 0x3b2]<3>[4296242.039000] irq 9: nobody cared (try booting with the "irqpoll" option) [4296242.039000] [] __report_bad_irq+0x2a/0xa0 [4296242.039000] [] handle_IRQ_event+0x30/0x70 [4296242.039000] [] note_interrupt+0x80/0xf0 [4296242.039000] [] __do_IRQ+0x134/0x140 [4296242.039000] [] do_IRQ+0x23/0x40 [4296242.039000] [] common_interrupt+0x1a/0x20 [4296242.039000] [] __do_softirq+0x43/0xb0 [4296242.039000] [] do_softirq+0x2d/0x30 [4296242.039000] [] irq_exit+0x37/0x40 [4296242.039000] [] do_IRQ+0x28/0x40 [4296242.039000] [] common_interrupt+0x1a/0x20 [4296242.039000] [] swsusp_suspend+0x50/0xc0 [4296242.039000] [] pm_suspend_disk+0x61/0xd0 [4296242.039000] [] enter_state+0xa6/0xb0 [4296242.039000] [] state_store+0x92/0x9e [4296242.039000] [] subsys_attr_store+0x3d/0x50 [4296242.039000] [] flush_write_buffer+0x3e/0x50 [4296242.039000] [] sysfs_write_file+0x54/0x80 [4296242.039000] [] vfs_write+0xb6/0x180 [4296242.039000] [] sys_write+0x51/0x80 [4296242.039000] [] syscall_call+0x7/0xb [4296242.039000] handlers: [4296242.039000] [] (acpi_irq+0x0/0x16) [4296242.039000] Disabling IRQ #9 The lspci -vv has this, so somebody should care about irq 9! :00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03) Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Perhaps the patch from Daniel Ritz to free the yenta IRQ on suspend > (attached) will help? I will try that next. -Sanjoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Syncing single filesystem (slow USB writing)
Mandrake always mounted USB sticks with sync option; it was effectively noop except for a patch that implemented limited dsync semantic. Now, when full sync support for FATis in kernel, moutning with sync became real pain. Writing speed dropped from 3MB/s to 30KB/s in my case (and I am not alone). One idea how to improve situation - continue to mount with dsync (having basically old case) and do frequent sync of filesystem (this culd be started as HAL callout or whatever). Unfortunately, I could not find a way to request a sync (flush) of single mount point or block device. Have I missed something? TIA -andrey pgpaWCl4Bj7BM.pgp Description: PGP signature
Re: [2.6 patch] net: Spelling mistakes threshoulds -> thresholds
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Fri, 29 Jul 2005 00:04:10 +0200 > Just simple spelling mistake fixes. > > From: aruch Even <[EMAIL PROTECTED]> > > Signed-Off-By: Baruch Even <[EMAIL PROTECTED]> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> The include/net/tcp.h part of this patch no longer applies cleanly. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kdump: Save parameter segment in protected mode (x86)
Ack. This is a simple fix to a very practical problem, for using the kernel from a reserved area of memory. Vivek Goyal <[EMAIL PROTECTED]> writes: > o With introduction of kexec as boot-loader, the assumption that parameter > segment will always be loaded at lower address than kernel and will be > addressable by early bootup page tables is no longer valid. In kexec on > panic case parameter segment might well be loaded beyond kernel image and > might not be addressable by early boot page tables. > o This case might hit in the scenario where user has reserved a chunk of > memory for second kernel, for example 16MB to 64MB, and has also built > second kernel for physical memory location 16MB. In this case kexec has no > choice but to load the parameter segment at a higher address than new > kernel > image at safe location where new kernel does not stomp it. > o Though problem should automatically go away once relocatable kernel for > i386 > is in place and kexec can determine the location of new kernel at run time > and load parameter segment at lower address than kernel image. But till then > this patch can go in (assuming it does not break something else). > o This patch moves up the boot parameter saving code. Now boot parameters > are copied out in protected mode before page tables are initialized. This > will ensure that parameter segment is always addressable irrespective of > its physical location. > > > Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/23] reboot-fixes
Pavel Machek <[EMAIL PROTECTED]> writes: > I always thought that device_shutdown is different phase -- the one > with interrupts disabled... At the end of device_shutdown interrupts are disabled because we shutdown the interrupt controllers. I don't think we have a phase where the interrupts are disabled, except for the code that runs after device_shutdown, and the bootup code that happens before interrupts are enabled. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/23] reboot-fixes
Pavel Machek <[EMAIL PROTECTED]> writes: > Hi! > >> So unless you are really ambitious I'd like to take >> device_suspend(PMSG_FREEZE) out of the reboot path for >> 2.6.13, put in -mm where people can bang on it for a bit >> and see that it is coming and delay the merge with the stable >> branch until the bugs with common hardware have been sorted out. > > Works for me. I may feel ambitious, but I don't feel like debugging > every reboot problem or every strange architecture for 2.6.13 :-). Curses. Foiled again! I have failed to pass the buck. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Interbench v0.24
Interbench is a Linux Kernel Interactivity Benchmark. Direct download: http://ck.kolivas.org/apps/interbench/interbench-0.24.tar.bz2 Web: http://interbench.kolivas.org Changes: 3 new loads were added: Gaming benchmark: This simulates an unlocked frame rate cpu intensive 3d gaming environment. It measures the latencies mean/sd/max and desired cpu percentage only. These should give a marker of frame rate stability (latencies), and maximum frame rates under different loads (desired cpu percentage). As this simulates an unlocked frame rate the deadlines met is meaningless. This does not accurately emulate a 3d game which is gpu bound, only a cpu bound one. Hackbench: Taken from Rusty's hackbench code as suggested by Ingo Molnar, this will run 'hackbench 50' repeatedly in the background when benchmarking real time performance. Custom: Based on the periodic scheduling used for audio/video, custom will allow you to specify a cpu percentage and frame rate of a custom workload, and this can be used to benchmark this workload's performance under normal scheduling, real time scheduling or it can be used as a background load. Bugfixes: Numerous floating point and overflow errors were tracked down and fixed. These are responsible for results like 'nan' and 4294... which is basically 2^32. Unfortunately the standard deviation reported in previous versions appears to have been bogus, but fortunately little value was placed on this result. Error handling was made _much_ more robust - for example it was found that contrary to 'man sem_wait' but consistent with SUSv3, sem_wait can return -1 with -EINTR. Lots of little tweaks. Cheers, Con pgpqt0vyhpkc3.pgp Description: PGP signature
Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)
yhlu <[EMAIL PROTECTED]> writes: > I have some problem with this patch. > > YH > > On 7/28/05, yhlu <[EMAIL PROTECTED]> wrote: >> Do you mean solve the timing problem for 2 way dual core or 4 way >> single core above? As best as I can determine the problem is possible any time you have more than 2 cpus (from the kernels perspective), but you have ti hit a fairly narrow window in cpu start up. What problem do you have with this patch. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: include-linux-blkdevh-extern-inline-static-inline.patch added to -mm tree
On 7/29/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> The patch titled
>
> include/linux/blkdev.h: "extern inline" -> "static inline"
>
> has been added to the -mm tree. Its filename is
>
> include-linux-blkdevh-extern-inline-static-inline.patch
>
...
>
>
> From: Adrian Bunk <[EMAIL PROTECTED]>
>
> "extern inline" doesn't make much sense.
"extern inline" does make sense, and it does make sense here. please
backout this patch. Hint: the address of block_size() is referenced.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
>
> include/linux/blkdev.h |2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN
> include/linux/blkdev.h~include-linux-blkdevh-extern-inline-static-inline
> include/linux/blkdev.h
> ---
> devel/include/linux/blkdev.h~include-linux-blkdevh-extern-inline-static-inline
> 2005-07-28 19:28:05.0 -0700
> +++ devel-akpm/include/linux/blkdev.h 2005-07-28 19:28:05.0 -0700
> @@ -727,7 +727,7 @@ static inline unsigned int blksize_bits(
> return bits;
> }
>
> -extern inline unsigned int block_size(struct block_device *bdev)
> +static inline unsigned int block_size(struct block_device *bdev)
> {
> return bdev->bd_block_size;
> }
--
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Not boot with kernel 2.6.13-rc4 in emachines
Hi all: Im try the tests with kernel 2.6.13-rc4, compile ok, boot when reboot the system not boot, try disable vga, acpi=off, etc, both not boot any more. Use FC4, with kernel all series 2.6.12.xxx working and boot OK. Any idea? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3 acpi compile problems
Florian Engelhardt <[EMAIL PROTECTED]> wrote:
>
> i get this warnings when compiling:
>
>CC drivers/acpi/utilities/utalloc.o
> drivers/acpi/utilities/utalloc.c: In function `acpi_ut_create_caches':
> drivers/acpi/utilities/utalloc.c:107: warning: passing arg 3 of
> `acpi_ut_create_list' from incompatible pointer type
Something like this?
diff -puN drivers/acpi/utilities/utdebug.c~acpi-trace-warning-fixes
drivers/acpi/utilities/utdebug.c
--- devel/drivers/acpi/utilities/utdebug.c~acpi-trace-warning-fixes
2005-07-28 19:14:46.0 -0700
+++ devel-akpm/drivers/acpi/utilities/utdebug.c 2005-07-28 19:14:46.0
-0700
@@ -133,7 +133,7 @@ void ACPI_INTERNAL_VAR_XFACE
acpi_ut_debug_print (
u32 requested_debug_level,
u32 line_number,
- char*function_name,
+ const char *function_name,
char*module_name,
u32 component_id,
char*format,
@@ -208,7 +208,7 @@ void ACPI_INTERNAL_VAR_XFACE
acpi_ut_debug_print_raw (
u32 requested_debug_level,
u32 line_number,
- char*function_name,
+ const char *function_name,
char*module_name,
u32 component_id,
char*format,
@@ -247,7 +247,7 @@ EXPORT_SYMBOL(acpi_ut_debug_print_raw);
void
acpi_ut_trace (
u32 line_number,
- char*function_name,
+ const char *function_name,
char*module_name,
u32 component_id)
{
@@ -282,7 +282,7 @@ EXPORT_SYMBOL(acpi_ut_trace);
void
acpi_ut_trace_ptr (
u32 line_number,
- char*function_name,
+ const char *function_name,
char*module_name,
u32 component_id,
void*pointer)
@@ -316,7 +316,7 @@ acpi_ut_trace_ptr (
void
acpi_ut_trace_str (
u32 line_number,
- char*function_name,
+ const char *function_name,
char*module_name,
u32 component_id,
char*string)
@@ -351,7 +351,7 @@ acpi_ut_trace_str (
void
acpi_ut_trace_u32 (
u32 line_number,
- char*function_name,
+ const char *function_name,
char*module_name,
u32 component_id,
u32 integer)
@@ -385,7 +385,7 @@ acpi_ut_trace_u32 (
void
acpi_ut_exit (
u32 line_number,
- char*function_name,
+ const char *function_name,
char*module_name,
u32 component_id)
{
@@ -419,7 +419,7 @@ EXPORT_SYMBOL(acpi_ut_exit);
void
acpi_ut_status_exit (
u32 line_number,
- char*function_name,
+ const char *function_name,
char*module_name,
u32 component_id,
acpi_status status)
@@ -463,7 +463,7 @@ EXPORT_SYMBOL(acpi_ut_status_exit);
void
acpi_ut_value_exit (
u32 line_number,
- char*function_name,
+ const char *function_name,
char*module_name,
u32 component_id,
acpi_integervalue)
@@ -499,7 +499,7 @@ EXPORT_SYMBOL(acpi_ut_value_exit);
void
acpi_ut_ptr_exit (
u32 line_number,
- char*function_name,
+ const char *function_name,
char*module_name,
u32 component_id,
u8 *ptr)
diff -puN include/acpi/acmacros.h~acpi-trace-warning-fixes
include/acpi/acmacros.h
diff -puN include/acpi/acutils.h~acpi-trace-warning-fixes include/acpi/acutils.h
--- devel/include/acpi/acutils.h~acpi-trace-warning-fixes 2005-07-28
19:14:46.0 -0700
+++ devel-akpm/include/acpi/acutils.h 2005-07-28 19:14:46.0 -0700
@@
Re: [ALSA PATCH] 1.0.9b+
Alistair John Strachan <[EMAIL PROTECTED]> wrote: > > On Thursday 28 Jul 2005 18:25, Andrew Morton wrote: > > Jaroslav Kysela <[EMAIL PROTECTED]> wrote: > > > Linus, please do an update from: > > > > > >rsync://rsync.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git > > > > > > ... > > > 65 files changed, 5059 insertions(+), 1122 deletions(-) > > > > The git-alsa.patch in -mm which I obtain from > > master.kernel.org:/pub/scm/linux/kernel/git/perex/alsa-current.git is > > empty. So we're now wanting to merge 4,000 lines of unreviewed code which > > hasn't been tested in -mm at approximately the -rc4 stage. > > ~2800 lines of which is a new driver. > > It'd be nice if ALSA's release schedule for "stable" versus "rc" could match > the kernel's. For example, 2.6.12 shipped with 1.0.9rc2. > > Maybe "rc" ALSA should only be accepted in rc1, by rc4 you hope they can wrap > things up and give you a stable version number? Okay, generally in-tree > version numbers don't count for much, but I think ALSA is a big exception > because it's maintained pretty much out of tree. > > Not so much of an issue this time around, but I don't think new drivers or > rewrites (even if they are reasonably separate) should be going in a late -rc > kernel. > Independent of all that, there remains the problem that I was not obtaining all this new code from master.kernel.org:/pub/scm/linux/kernel/git/perex/alsa-current.git. Is there some different tree which I should be pulling from? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] remove i386 dynamic ticks ifdefs
Hi Tony
I assume you're maintaining the dyn tick patches for i386 posted on the muru
website as your email is listed there. I thought you might be interested in
this patch for dyn-ticks which removes most of the #ifdefs out of common code
paths as per linux kernel style and moves more code into dyn-tick.c. Most of
it is straight forward code reorganisation, but to keep do_timer_interrupt
inlined I'd have to move it's code around somewhat. That may be a better
option but I've tried to fiddle with the mainline code as little as possible.
Patch applies to 2.6.12 with patch-dynamic-tick-2.6.12-rc6-050610-1 applied
cc'ed lkml just for public record of the patch.
Cheers,
Con
Move most of the dynamic ticks code that is #ifdef'd out of code paths and
put it into dyn-tick.c
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
arch/i386/kernel/Makefile |2
arch/i386/kernel/apic.c | 36 --
arch/i386/kernel/dyn-tick.c | 146
arch/i386/kernel/irq.c |5 -
arch/i386/kernel/time.c | 72 -
include/asm/dyn-tick.h |4 -
include/linux/dyn-tick.h| 12 +++
7 files changed, 165 insertions(+), 112 deletions(-)
Index: linux-2.6.12-dt/arch/i386/kernel/apic.c
===
--- linux-2.6.12-dt.orig/arch/i386/kernel/apic.c 2005-07-29 01:43:15.0 +1000
+++ linux-2.6.12-dt/arch/i386/kernel/apic.c 2005-07-29 01:49:05.0 +1000
@@ -932,11 +932,8 @@ static void __setup_APIC_LVTT(unsigned i
apic_timer_val = clocks/APIC_DIVISOR;
-#ifdef CONFIG_NO_IDLE_HZ
- /* Local APIC timer is 24-bit */
if (apic_timer_val)
- dyn_tick->max_skip = 0xff / apic_timer_val;
-#endif
+ set_dyn_tick_max_skip(apic_timer_val);
apic_write_around(APIC_TMICT, apic_timer_val);
}
@@ -1051,12 +1048,7 @@ void __init setup_boot_APIC_clock(void)
*/
setup_APIC_timer(calibration_result);
-#ifdef CONFIG_NO_IDLE_HZ
- if (calibration_result)
- dyn_tick->state |= DYN_TICK_USE_APIC;
- else
- printk(KERN_INFO "dyn-tick: Cannot use local APIC\n");
-#endif
+ setup_dyn_tick_use_apic(calibration_result);
local_irq_enable();
}
@@ -1086,18 +1078,6 @@ void enable_APIC_timer(void)
}
}
-#if defined(CONFIG_NO_IDLE_HZ)
-void reprogram_apic_timer(unsigned int count)
-{
- unsigned long flags;
-
- count *= apic_timer_val;
- local_irq_save(flags);
- apic_write_around(APIC_TMICT, count);
- local_irq_restore(flags);
-}
-#endif
-
/*
* the frequency of the profiling timer can be changed
* by writing a multiplier value into /proc/profile.
@@ -1210,21 +1190,11 @@ fastcall void smp_apic_timer_interrupt(s
*/
irq_enter();
-#ifdef CONFIG_NO_IDLE_HZ
/*
* Check if we need to wake up PIT interrupt handler.
* Otherwise just wake up local APIC timer.
*/
- do {
- seq = read_seqbegin(_lock);
- if (dyn_tick->state & (DYN_TICK_ENABLED | DYN_TICK_SKIPPING)) {
- if (dyn_tick->skip_cpu == cpu && dyn_tick->skip > DYN_TICK_MIN_SKIP)
-dyn_tick->interrupt(99, NULL, regs);
- else
-reprogram_apic_timer(1);
- }
- } while (read_seqretry(_lock, seq));
-#endif
+ wakeup_pit_or_apic(seq, cpu, );
smp_local_timer_interrupt(regs);
irq_exit();
Index: linux-2.6.12-dt/arch/i386/kernel/dyn-tick.c
===
--- linux-2.6.12-dt.orig/arch/i386/kernel/dyn-tick.c 2005-07-29 01:43:15.0 +1000
+++ linux-2.6.12-dt/arch/i386/kernel/dyn-tick.c 2005-07-29 11:46:48.0 +1000
@@ -17,6 +17,7 @@
#include
#include
+#ifdef CONFIG_NO_IDLE_HZ
void arch_reprogram_timer(void)
{
if (cpu_has_local_apic()) {
@@ -43,3 +44,148 @@ int __init dyn_tick_init(void)
return 0;
}
arch_initcall(dyn_tick_init);
+
+static unsigned long long last_tick;
+
+/*
+ * This interrupt handler updates the time based on number of jiffies skipped
+ * It would be somewhat more optimized to have a customa handler in each timer
+ * using hardware ticks instead of nanoseconds. Note that CONFIG_NO_IDLE_HZ
+ * currently disables timer fallback on skipped jiffies.
+ */
+irqreturn_t dyn_tick_timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+{
+ unsigned long flags;
+ volatile unsigned long long now;
+ unsigned int skipped = 0;
+
+ write_seqlock_irqsave(_lock, flags);
+ now = cur_timer->monotonic_clock();
+ while (now - last_tick >= NS_TICK_LEN) {
+ last_tick += NS_TICK_LEN;
+ cur_timer->mark_offset();
+ do_timer_interrupt(irq, NULL, regs);
+ skipped++;
+ }
+ if (dyn_tick->state & (DYN_TICK_ENABLED | DYN_TICK_SKIPPING)) {
+ dyn_tick->skip = 1;
+ if (cpu_has_local_apic())
+ reprogram_apic_timer(dyn_tick->skip);
+ reprogram_pit_timer(dyn_tick->skip);
+ dyn_tick->state |= DYN_TICK_ENABLED;
+ dyn_tick->state &= ~DYN_TICK_SKIPPING;
+ }
+ write_sequnlock_irqrestore(_lock, flags);
+
+ return IRQ_HANDLED;
+}
+
+int __init dyn_tick_arch_init(void)
+{
+ unsigned long flags;
+
+ write_seqlock_irqsave(_lock, flags);
+ last_tick =
Time Flies (Twice as Fast)
Hola, I have an eMachines T6212 Opteron system on which the system clock seems to run at ~twice the speed of the wall clock. The main board is an ASUS K8 of some description with at ATI SB400 southbridge and an ATI RS480 northbridge. Kernel version is 2.6.12.3. If I disable ACPI, the clock slows down to what seems to be the proper speed, but then my NIC doesn't work, presumably because it shares an interrupt with something else. I've tried booting with clock=tsc and clock=pit to no effect. Based on my review of the list archives, there appears to be issues with the chipset, but I haven't been able to sort out what the real problem is and the appropriate solution. There's an ACPI error that seems potentially troublesome: ACPI: Subsystem revision 20050309 ACPI-0352: *** Error: Looking up [\_SB_.PCI0.LPC0.LNK0] in namespace, AE_NOT_FOUND search_node 81001fec9440 start_node 81001fec9440 return_node I also see this message from the PCI subsystem: PCI: Ignoring BAR0-3 of IDE controller :00:14.1 As a starting point, I've attached lspci output and the boot log. I'm willing to provide more information and try patches and such. Thanks. Kurt -- Westheimer's Discovery: A couple of months in the laboratory can frequently save a couple of hours in the library. 00:00.0 Host bridge: ATI Technologies Inc: Unknown device 5950 Subsystem: Micro-Star International Co., Ltd.: Unknown device 7141 Flags: bus master, 66Mhz, medium devsel, latency 64 I/O ports at 4100 [disabled] [size=32] Memory at (64-bit, non-prefetchable) [size=512M] 00:11.0 IDE interface: ATI Technologies Inc: Unknown device 437a (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7141 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 10 I/O ports at fe00 [size=8] I/O ports at fd00 [size=4] I/O ports at fc00 [size=8] I/O ports at fb00 [size=4] I/O ports at fa00 [size=16] Memory at fe02f000 (32-bit, non-prefetchable) [size=512] Expansion ROM at [disabled] [size=512K] Capabilities: [60] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- 00:12.0 IDE interface: ATI Technologies Inc: Unknown device 4379 (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7141 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11 I/O ports at f900 [size=8] I/O ports at f800 [size=4] I/O ports at f700 [size=8] I/O ports at f600 [size=4] I/O ports at f500 [size=16] Memory at fe02e000 (32-bit, non-prefetchable) [size=512] Expansion ROM at [disabled] [size=512K] Capabilities: [60] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- 00:13.0 USB Controller: ATI Technologies Inc: Unknown device 4374 (prog-if 10 [OHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7141 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 185 Memory at fe02d000 (32-bit, non-prefetchable) [size=4K] Capabilities: [d0] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- 00:13.1 USB Controller: ATI Technologies Inc: Unknown device 4375 (prog-if 10 [OHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7141 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 185 Memory at fe02c000 (32-bit, non-prefetchable) [size=4K] Capabilities: [d0] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- 00:13.2 USB Controller: ATI Technologies Inc: Unknown device 4373 (prog-if 20 [EHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7141 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 185 Memory at fe02b000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 Capabilities: [d0] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- 00:14.0 SMBus: ATI Technologies Inc: Unknown device 4372 (rev 04) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7141 Flags: 66Mhz, medium devsel I/O ports at 0400 [size=16] Memory at fe02a000 (32-bit, non-prefetchable) [size=1K] Capabilities: [b0] #08 [a802] 00:14.1 IDE interface: ATI Technologies Inc: Unknown device 4376 (prog-if 8a [Master SecP PriP]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7141 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 177 I/O ports at I/O ports at I/O ports at I/O ports at I/O ports at f300 [size=16] Capabilities: [70] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- 00:14.3 ISA bridge: ATI Technologies Inc: Unknown device
Re: Delete scheduler SD_WAKE_AFFINE and SD_WAKE_BALANCE flags
Chen, Kenneth W wrote: Nick Piggin wrote on Thursday, July 28, 2005 6:46 PM I'd like to try making them less aggressive first if possible. Well, that's exactly what I'm trying to do: make them not aggressive at all by not performing any load balance :-) The workload gets maximum benefit with zero aggressiveness. Unfortunately we can't forget about other workloads, and we're trying to stay away from runtime tunables in the scheduler. If we can get performance to within a couple of tenths of a percent of the zero balancing case, then that would be preferable I think. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Delete scheduler SD_WAKE_AFFINE and SD_WAKE_BALANCE flags
Nick Piggin wrote on Thursday, July 28, 2005 6:46 PM > I'd like to try making them less aggressive first if possible. Well, that's exactly what I'm trying to do: make them not aggressive at all by not performing any load balance :-) The workload gets maximum benefit with zero aggressiveness. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
FW: [RFC] A more general timeout specification
Hi John
Couple of months ago Joe Korty sent the attached proposal for a new
interface and I was wondering if you could comment on it.
The main user of this new inteface is to allow system calls to get
time specified in an absolute form (as most of POSIX states) and thus
avoid extra time conversion work.
There was a short thread about it, available at google groups
(grepping for the subject).
http://groups-beta.google.com/groups?q=a+more+general+timeout+specification
Thanks!
[ for comment only ]
The fusyn (robust mutexes) project proposes the creation
of a more general data structure, 'struct timeout', for the
specification of timeouts in new services. In this structure,
the user specifies:
a time, in timespec format.
the clock the time is specified against (eg, CLOCK_MONOTONIC).
whether the time is absolute, or relative to 'now'.
That is, all combinations of useful timeout attributes become
possible.
Also proposed are two new kernel routines for the manipulation
of timeouts:
timeout_validate()
timeout_sleep()
timeout_validate() error-checks the syntax of a timeout
argument and returns either zero or -EINVAL. By breaking
timeout_validate() out from timeout_sleep(), it becomes possible
to error check the timeout 'far away' from the places in the
code where we would actually do the timeout, as well as being
able to perform such checks only at those places we know the
timeout specification is coming from an unsafe source.
timeout_sleep() puts the caller to sleep until the
specified end time is in the past, as measured against
the given clock, or until the caller is awakened by other
means (such as wake_up_process()). Like schedule_timeout(),
TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE must be set ahead
of time; if TASK_INTERRUPTIBLE is set then signals will also
break the caller out of the sleep.
timeout_sleep() returns either 0 (returned early) or -ETIMEDOUT
(returned due to timeout). It is up to the caller to resolve,
in the "returned early" case, why it returned early.
Timeout_sleep has a return argument, endtime, which is also in
'struct timeout' format. If the input time was relative, then
it is converted to absolute and returned through this argument.
This can be used when an early-terminated service must be
restarted and side effects of the early termination-n-restart
(such as end time drift) are to be avoided.
Joe
"Money can buy bandwidth, but latency is forever" -- John Mashey
2.6.12-rc4-jak/include/linux/time.h|6 +
2.6.12-rc4-jak/include/linux/timeout.h | 48
2.6.12-rc4-jak/kernel/posix-timers.c |7 +
2.6.12-rc4-jak/kernel/timer.c | 184 +
4 files changed, 245 insertions(+)
diff -puNa include/linux/time.h~a.more.flexible.timeout.approach
include/linux/time.h
--- 2.6.12-rc4/include/linux/time.h~a.more.flexible.timeout.approach
2005-05-18 13:53:14.204417169 -0400
+++ 2.6.12-rc4-jak/include/linux/time.h 2005-05-18 13:53:14.212416002 -0400
@@ -25,6 +25,8 @@ struct timezone {
int tz_dsttime; /* type of dst correction */
};
+#include
+
#ifdef __KERNEL__
/* Parameters used to convert the timespec values */
@@ -103,6 +105,10 @@ struct itimerval;
extern int do_setitimer(int which, struct itimerval *value, struct itimerval
*ovalue);
extern int do_getitimer(int which, struct itimerval *value);
extern void getnstimeofday (struct timespec *tv);
+extern long clock_gettime(int which, struct timespec *tp);
+
+extern int FASTCALL(abs_timespec_to_abs_jiffies (clockid_t clock, const struct
timespec *tp, unsigned long *jp));
+extern int FASTCALL(rel_to_abs_timespec(clockid_t clock, const struct timespec
*tsrel, struct timespec *tsabs));
extern struct timespec timespec_trunc(struct timespec t, unsigned gran);
diff -puNa /dev/null include/linux/timeout.h
--- /dev/null 2004-06-24 14:04:38.0 -0400
+++ 2.6.12-rc4-jak/include/linux/timeout.h 2005-05-18 13:53:14.212416002
-0400
@@ -0,0 +1,48 @@
+/*
+ * Extended timeout specification
+ *
+ * (C) 2002-2005 Intel Corp
+ * Inaky Perez-Gonzalez <[EMAIL PROTECTED]>.
+ *
+ * Licensed under the FSF's GNU Public License v2 or later.
+ *
+ * Generic extended timeout specification. Broken out by Joe Korty
+ * <[EMAIL PROTECTED]> from linux/time.h so that it can be included
+ * by userspace applications in conjunction with #include "time.h".
+ */
+
+#ifndef _LINUX_TIMEOUT_H
+#define _LINUX_TIMEOUT_H
+
+/* 'struct timeout' flag values. OR these into clock_id along with
+ * a clock specification such as CLOCK_REALTIME or CLOCK_MONOTONIC.
+ */
+enum {
+ TIMEOUT_RELATIVE = 0x1000,/* relative timeout */
+
+ TIMEOUT_FLAGS_MASK = 0xf000,/* flags mask for clock_id */
+ TIMEOUT_CLOCK_MASK = 0x0fff,/* clock mask for clock_id */
+};
+
+/* Magic values a 'struct timeout' pointer can have */
+
+#define TIMEOUT_MAX((struct timeout *) ~0UL) /* never time out */
Re: [PATCH] NMI watch dog notify patch
On Thu, 28 Jul 2005 13:31:58 -0700, George Anzinger wrote: >I have been doing some work on kgdb to pull a few of it "fingers" out of >various places in the kernel. This is the final location where we have >a kgdb intercept not covered by a notify. I like the idea, but the hook should be in die_nmi(), not in the watchdog, using the reason that is already passed into die_nmi. die_nmi() is also called for a real NMI. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Delete scheduler SD_WAKE_AFFINE and SD_WAKE_BALANCE flags
Chen, Kenneth W wrote: Nick Piggin wrote on Thursday, July 28, 2005 6:25 PM Well pipes are just an example. It could be any type of communication. What's more, even the synchronous wakeup uses the wake balancing path (although that could be modified to only do wake balancing for synch wakeups, I'd have to be convinced we should special case pipes and not eg. semaphores or AF_UNIX sockets). Why is the normal load balance path not enough (or not be able to do the right thing)? The reblance_tick and idle_balance ought be enough to take care of the imbalance. What makes load balancing in wake up path so special? Well the normal load balancing path treats all tasks the same, while the wake path knows if a CPU is waking a remote task and can attempt to maximise the number of local wakeups. Oh, I'd like to hear your opinion on what to do with these two flags, make them runtime configurable? (I'm of the opinion to delete them altogether) I'd like to try making them less aggressive first if possible. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Delete scheduler SD_WAKE_AFFINE and SD_WAKE_BALANCE flags
Nick Piggin wrote on Thursday, July 28, 2005 6:25 PM > Well pipes are just an example. It could be any type of communication. > What's more, even the synchronous wakeup uses the wake balancing path > (although that could be modified to only do wake balancing for synch > wakeups, I'd have to be convinced we should special case pipes and not > eg. semaphores or AF_UNIX sockets). Why is the normal load balance path not enough (or not be able to do the right thing)? The reblance_tick and idle_balance ought be enough to take care of the imbalance. What makes load balancing in wake up path so special? Oh, I'd like to hear your opinion on what to do with these two flags, make them runtime configurable? (I'm of the opinion to delete them altogether) - Ken - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Delete scheduler SD_WAKE_AFFINE and SD_WAKE_BALANCE flags
Chen, Kenneth W wrote: Nick Piggin wrote on Thursday, July 28, 2005 4:35 PM Wake balancing provides an opportunity to provide some input bias into the load balancer. For example, if you started 100 pairs of tasks which communicate through a pipe. On a 2 CPU system without wake balancing, probably half of the pairs will be on different CPUs. With wake balancing, it should be much better. Shouldn't the pipe code use synchronous wakeup? Well pipes are just an example. It could be any type of communication. What's more, even the synchronous wakeup uses the wake balancing path (although that could be modified to only do wake balancing for synch wakeups, I'd have to be convinced we should special case pipes and not eg. semaphores or AF_UNIX sockets). I hear you might be having problems with recent 2.6.13 kernels? If so, it would be really good to have a look that before 2.6.13 goes out the door. Yes I do :-(, apparently bumping up cache_hot_time won't give us the performance boost we used to see. OK there are probably a number of things we can explore depending on what are the symptoms (eg. excessive idle time, bad cache performance). Unfortunately it is kind of difficult to tune 2.6.13 on the basis of 2.6.12 results - although that's not to say it won't indicate a good avenue to investigate. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROPOSTA PARA DIVULGAÇÃO DE EMPRESA
DIVULGAÇÃO DE EMPRESAS CONTATO: FONE: 5812-3295 SEGUE PROPOSTA EM ANEXO. EMAIL: [EMAIL PROTECTED] LIGUE E SE ENFORME ATNECIOSAMENTE. PROPOSTA via e-mail.doc Description: Binary data
Re: Re: Problem while inserting pciehp (PCI Express Hot-plug) driver
On Thu, Jul 28, 2005 at 07:45:49PM +0900, Rajat Jain wrote: > > Okay. I'm sorry but I'm not very clear with this. I'm just putting > down here my understanding. So basically we have two mutually > EXCLUSIVE hotplug drivers I can use for PCI Express: > A hotplug slot can be controlled only by a single hotplug technology - pcie shpc or acpiphp. However, different parts of the I/O hierarchy can be controlled by different technologies. For example, a host bridge I/O complex can be hotplugged using acpiphp, but end devices under this IO complex may be hotpplugged using pcie or shpc hotplug. > 1) "pciehp.ko" : We use this PCIE HP driver when our BIOS supports > Native Hot-plug for PCI Express (which means that hot-plug will be > handled by OS single handedly). > > 2) "acpiphp.ko" : We use this "generic" ACPI HP driver when BIOS > allows only ITSELF to handle hot-plug events. > No, acpi hotplug is not handled by BIOS only. Both acpi and pcie hotplug need firmware support as well as hardware support. Hardware in many (but not all) systems support both types of hotplug and its up to the BIOS to decide which type to support. If the platform supports pcie hotplug, you see an _OSC & _SUN methods in the ACPI namespace and the pciehp driver controls hotplug slots. If the system supports acpi hotplug, you see _ADR and _EJ0 methods in the ACPI namespace and the acpiphp driver controls the corresponding hotplug slots. Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: io scheduler silly question perhaps..
Try benchmarking Anticipatory or Deadline against Noop, preferably with your actual workload. Noop is probably what you want, since there is not much use in avoiding large "seeks". It could be though that request merging, which the non-noop schedulers all perform, willl cause Noop to lose. I haven't tried any I/O scheduler benchmarks with flash, but perhaps we need a simple "merge only" scheduler for this sort of thing. Let me know what the results are. NATE On 7/28/05, Dave Airlie <[EMAIL PROTECTED]> wrote: > > I have an embedded system which has two read-only flash devices (one a > PIO ATA flash disk, and one MDMA capable flash) > > As I'm doing no writing in this system and most of my reads are sequential > (streaming movies or images) would my choice of io scheduler be very > important? > > Regards, > Dave. > > -- > David Airlie, Software Engineer > http://www.skynet.ie/~airlied / airlied at skynet.ie > Linux kernel - DRI, VAX / pam_smb / ILUG > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3 question
On Thu, 28 Jul 2005 22:42:38 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > I'm surprised that you are that much concerned about compile errors when > using a kernel that might regularly exchange the contents of /dev/hda > and /dev/null . > These bugs don't happen too often in reality. Just please don't be malicious and add this kind of code deliberately. :) Every build breaker wastes my precious time to fix it. That's compulsive/obsessive in some way. ;) On the contrary, my "just break it" desktop is destined to have it's HDD contents overwritten once in a time. That's what these spare disks/computers are for, aren't they? All the data on that computer is volatile, all (not too frequent) backup is mostly made through the network and checked from the stable computer. If I really needed it very stable, I wouldn't test Reiser4 on it, less so a development kernel. That's why my stable machine uses latest release kernel, and only after it's broken in by at least a week. -- AstralStorm GPG Key ID = 0xD1F10BA2 GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2 Please encrypt if you can. pgpexWeWujlaI.pgp Description: PGP signature
Re: [PATCH] disk quotas fail when /etc/mtab is symlinked to /proc/mounts
Mark Bellon wrote: Andrew Morton wrote: Mark Bellon <[EMAIL PROTECTED]> wrote: If /etc/mtab is a regular file all of the mount options (of a file system) are written to /etc/mtab by the mount command. The quota tools look there for the quota strings for their operation. If, however, /etc/mtab is a symlink to /proc/mounts (a "good thing" in some environments) the tools don't write anything - they assume the kernel will take care of things. While the quota options are sent down to the kernel via the mount system call and the file system codes handle them properly unfortunately there is no code to echo the quota strings into /proc/mounts and the quota tools fail in the symlink case. hm. Perhaps others with operational experience in that area can comment. OK. The attached patchs modify the EXT[2|3] and [X|J]FS codes to add the necessary hooks. The show_options function of each file system in these patches currently deal with only those things that seemed related to quotas; especially in the EXT3 case more can be done (later?). It seems sad to do it in each filesystem. Is there no way in which we can do this for all filesystems, in a single place in the VFS? Each file system must be able to echo it's own FS specific options, hence the show_options hook (XFS is a good example). EXT3 has it's own form of journalled quota file options, hence the need for the specific hook. The "older style" (e.g. "usrquota", "grpquota", "quota") could be done generically but a FS might want any number of quota options. The few lines of code in each file system didn't seem so bad especially if the show_function start echoing more. Followup comment/through... If we want /proc/mounts to really replace /etc/mtab in the general case, always using it as a symlink, the file system codes will all need the show_options hook - they will need to echo all of their private options duplicating, as closely as possible, what would have been written to the /etc/mtab regular file. mark mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.32-pre2
On Thu, Jul 28, 2005, Marcelo Tosatti <[EMAIL PROTECTED]> wrote: > diff --git a/drivers/usb/host/uhci.c b/drivers/usb/host/uhci.c > --- a/drivers/usb/host/uhci.c > +++ b/drivers/usb/host/uhci.c > @@ -2924,7 +2924,7 @@ static int alloc_uhci(struct pci_dev *de > } > > /* Only place we don't use the frame list routines */ > - uhci->fl->frame[i] = uhci->skeltd[irq]->dma_handle; > + uhci->fl->frame[i] = uhci->skeltd[irq]->dma_handle | > UHCI_PTR_QH; > } > > start_hc(uhci); Am I missing something here? We're certainly adding TDs to the schedule, so why is this patch setting the QH bit? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm2/mm1 breaks DRI
> > > > > >Hmm no idea what could have broken it, I'm at OLS and don't have any > > >DRI capable machine here yet.. so it'll be a while before I get to > > >take a look at it .. I wouldn't be terribly surprised if some of the > > >new mapping code might have some issues.. > > > > Still happens with mm2. > > And mm3 too. Please let me know if there is anything you would like me to > try. Hi Ed, Is this all on a 64-bit system, is it a pure 64-bit or are you running a 32-bit userspace or something like that... I don't have any 64-bit systems so tracking the issues on them is a nightmare... I've got a patch from Egbert Eich that I need to drop into -mm that might fix it but I'm snowed under with real work at the moment (taking a week off for OLS didn't help :-) Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.32-pre2
On Thu, 28 Jul 2005 07:22:25 -0300, Marcelo Tosatti <[EMAIL PROTECTED]> wrote: >> >> Breaks Toshiba laptop: hard lockup --> what is on screen is same as >> working dmesg up to point: "host/uhci.c: detected 2 port" >> >> Same .config as for 2.4.31-hf3 or 2.4.32-pre1 >> http://scatter.mine.nu/test/linux-2.4/tosh/ > >Please try to revert the attached? Yes, that fixed it :o) a USB mouse works. dmesg: ... host/uhci.c: detected 2 ports <<== previous lockup after this usb.c: kmalloc IF c12f36e0, numif 1 usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1 usb.c: USB device number 1 default language ID 0x0 Product: USB UHCI-alt Root Hub SerialNumber: ff80 ... And the other USB driver (usb-uhci) didn't lockup. Thanks, Grant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm2/mm1 breaks DRI
On Wednesday 27 July 2005 17:58, Ed Tomlinson wrote: > >> >> > >> >> I also use 2.6.13-rc3-mm1. Â Will try with a previous version an report > >> >> to lkml if > >> >> it works. > >> >> > >> > > >> > I just tried 13-rc2-mm1 and dri is working again. Its reported to also > >> > work > >> > with 13-rc3. > >> > > > >Hmm no idea what could have broken it, I'm at OLS and don't have any > >DRI capable machine here yet.. so it'll be a while before I get to > >take a look at it .. I wouldn't be terribly surprised if some of the > >new mapping code might have some issues.. > > Still happens with mm2. And mm3 too. Please let me know if there is anything you would like me to try. Thanks Ed Tomlinson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
io scheduler silly question perhaps..
I have an embedded system which has two read-only flash devices (one a PIO ATA flash disk, and one MDMA capable flash) As I'm doing no writing in this system and most of my reads are sequential (streaming movies or images) would my choice of io scheduler be very important? Regards, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] disk quotas fail when /etc/mtab is symlinked to /proc/mounts
Andrew Morton wrote: Mark Bellon <[EMAIL PROTECTED]> wrote: If /etc/mtab is a regular file all of the mount options (of a file system) are written to /etc/mtab by the mount command. The quota tools look there for the quota strings for their operation. If, however, /etc/mtab is a symlink to /proc/mounts (a "good thing" in some environments) the tools don't write anything - they assume the kernel will take care of things. While the quota options are sent down to the kernel via the mount system call and the file system codes handle them properly unfortunately there is no code to echo the quota strings into /proc/mounts and the quota tools fail in the symlink case. hm. Perhaps others with operational experience in that area can comment. OK. The attached patchs modify the EXT[2|3] and [X|J]FS codes to add the necessary hooks. The show_options function of each file system in these patches currently deal with only those things that seemed related to quotas; especially in the EXT3 case more can be done (later?). It seems sad to do it in each filesystem. Is there no way in which we can do this for all filesystems, in a single place in the VFS? Each file system must be able to echo it's own FS specific options, hence the show_options hook (XFS is a good example). EXT3 has it's own form of journalled quota file options, hence the need for the specific hook. The "older style" (e.g. "usrquota", "grpquota", "quota") could be done generically but a FS might want any number of quota options. The few lines of code in each file system didn't seem so bad especially if the show_function start echoing more. mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] disk quotas fail when /etc/mtab is symlinked to /proc/mounts
Mark Bellon <[EMAIL PROTECTED]> wrote: > > If /etc/mtab is a regular file all of the mount options (of a file > system) are written to /etc/mtab by the mount command. The quota tools > look there for the quota strings for their operation. If, however, > /etc/mtab is a symlink to /proc/mounts (a "good thing" in some > environments) the tools don't write anything - they assume the kernel > will take care of things. > > While the quota options are sent down to the kernel via the mount system > call and the file system codes handle them properly unfortunately there > is no code to echo the quota strings into /proc/mounts and the quota > tools fail in the symlink case. hm. Perhaps others with operational experience in that area can comment. > The attached patchs modify the EXT[2|3] and [X|J]FS codes to add the > necessary hooks. The show_options function of each file system in these > patches currently deal with only those things that seemed related to > quotas; especially in the EXT3 case more can be done (later?). It seems sad to do it in each filesystem. Is there no way in which we can do this for all filesystems, in a single place in the VFS? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
On Thu, 28 Jul 2005, Andrew Morton wrote: > Well if you want to go this way I can just drop the TIF_FREEZE stuff and > use the patches-relative-to-mainline. I would appreciate that.\ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] disk quotas fail when /etc/mtab is symlinked to /proc/mounts
If /etc/mtab is a regular file all of the mount options (of a file system) are written to /etc/mtab by the mount command. The quota tools look there for the quota strings for their operation. If, however, /etc/mtab is a symlink to /proc/mounts (a "good thing" in some environments) the tools don't write anything - they assume the kernel will take care of things. While the quota options are sent down to the kernel via the mount system call and the file system codes handle them properly unfortunately there is no code to echo the quota strings into /proc/mounts and the quota tools fail in the symlink case. The attached patchs modify the EXT[2|3] and JFS codes to add the necessary hooks. The show_options function of each file system in these patches currently deal with only those things that seemed related to quotas; especially in the EXT3 case more can be done (later?). The original XFS change has been dropped as per Nathan Scott <[EMAIL PROTECTED]>. The functionality had already been added. The EXT3 has added error checking and has two minor changes: The "quota" option is considered part of the older style quotas Journalled quotas and older style quotas are mutually exclusive. - both discussable topics mark Signed-off-by: Mark Bellon <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] disk quotas fail when /etc/mtab is symlinked to /proc/mounts
Nathan Scott wrote:
On Thu, Jul 28, 2005 at 05:03:02PM -0700, Mark Bellon wrote:
The attached patchs modify the EXT[2|3] and [X|J]FS codes to add the
The XFS component is incorrect, we're already doing this elsewhere
(over in fs/xfs/quota/xfs_qm_bhv.c), so please drop this last part
from your patch...
No problem! New patch coming up.
mark
diff -Naur linux-2.6.13-rc3-git9-orig/fs/xfs/xfs_vfsops.c
linux-2.6.13-rc3-git9/fs/xfs/xfs_vfsops.c
...
+ { XFS_UQUOTA_ACTIVE,"," "usrquota" },
+ { XFS_GQUOTA_ACTIVE,"," "grpquota" },
thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] disk quotas fail when /etc/mtab is symlinked to /proc/mounts
On Thu, Jul 28, 2005 at 05:03:02PM -0700, Mark Bellon wrote:
> The attached patchs modify the EXT[2|3] and [X|J]FS codes to add the
The XFS component is incorrect, we're already doing this elsewhere
(over in fs/xfs/quota/xfs_qm_bhv.c), so please drop this last part
from your patch...
> diff -Naur linux-2.6.13-rc3-git9-orig/fs/xfs/xfs_vfsops.c
> linux-2.6.13-rc3-git9/fs/xfs/xfs_vfsops.c
> ...
> + { XFS_UQUOTA_ACTIVE,"," "usrquota" },
> + { XFS_GQUOTA_ACTIVE,"," "grpquota" },
thanks.
--
Nathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NMI watch dog notify patch
George Anzinger wrote: > > Andrew Morton wrote: > > George Anzinger wrote: > > > >>This patch adds a notify to the nmi watchdog to notify that > >>the system is about to be taken down by the watchdog. If the > >>notify is handled with a NOTIFY_STOP return, the system is > >>given a new lease on life. > > > > > > It looks sensible, but as there aren't actually any in-kernel uses for this > > I'd have thought it would be better for it to live out-of-tree? > > I should just bundle it with the kgdb patch then? I spose so, for now. If kdb and/or nlkd could benefit from it then it might simplify life to merge it into mainline. Perhaps you could ping Keith Owens <[EMAIL PROTECTED]> and [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] disk quotas fail when /etc/mtab is symlinked to /proc/mounts
If /etc/mtab is a regular file all of the mount options (of a file
system) are written to /etc/mtab by the mount command. The quota tools
look there for the quota strings for their operation. If, however,
/etc/mtab is a symlink to /proc/mounts (a "good thing" in some
environments) the tools don't write anything - they assume the kernel
will take care of things.
While the quota options are sent down to the kernel via the mount system
call and the file system codes handle them properly unfortunately there
is no code to echo the quota strings into /proc/mounts and the quota
tools fail in the symlink case.
The attached patchs modify the EXT[2|3] and [X|J]FS codes to add the
necessary hooks. The show_options function of each file system in these
patches currently deal with only those things that seemed related to
quotas; especially in the EXT3 case more can be done (later?).
The EXT3 has added error checking and has two minor changes:
The "quota" option is considered part of the older style quotas
Journalled quotas and older style quotas are mutually exclusive.
- both discussable topics
mark
Signed-off-by: Mark Bellon <[EMAIL PROTECTED]>
diff -Naur linux-2.6.13-rc3-git9-orig/include/linux/ext3_fs.h
linux-2.6.13-rc3-git9/include/linux/ext3_fs.h
--- linux-2.6.13-rc3-git9-orig/include/linux/ext3_fs.h 2005-07-28
15:12:52.0 -0700
+++ linux-2.6.13-rc3-git9/include/linux/ext3_fs.h 2005-07-28
16:18:24.0 -0700
@@ -373,6 +373,8 @@
#define EXT3_MOUNT_BARRIER 0x2 /* Use block barriers */
#define EXT3_MOUNT_NOBH0x4 /* No bufferheads */
#define EXT3_MOUNT_QUOTA 0x8 /* Some quota option set */
+#define EXT3_MOUNT_USRQUOTA0x10 /* "old" user quota */
+#define EXT3_MOUNT_GRPQUOTA0x20 /* "old" group quota */
/* Compatibility, for having both ext2_fs.h and ext3_fs.h included at once */
#ifndef _LINUX_EXT2_FS_H
diff -Naur linux-2.6.13-rc3-git9-orig/fs/ext3/super.c
linux-2.6.13-rc3-git9/fs/ext3/super.c
--- linux-2.6.13-rc3-git9-orig/fs/ext3/super.c 2005-07-28 15:12:51.0
-0700
+++ linux-2.6.13-rc3-git9/fs/ext3/super.c 2005-07-28 16:01:15.0
-0700
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include "xattr.h"
#include "acl.h"
@@ -510,6 +511,37 @@
}
#ifdef CONFIG_QUOTA
+static int ext3_show_options(struct seq_file *seq, struct vfsmount *vfs)
+{
+ struct ext3_sb_info *sbi = EXT3_SB(vfs->mnt_sb);
+
+ if (sbi->s_mount_opt & EXT3_MOUNT_JOURNAL_DATA)
+ seq_puts(seq, ",data=journal");
+
+ if (sbi->s_mount_opt & EXT3_MOUNT_ORDERED_DATA)
+ seq_puts(seq, ",data=ordered");
+
+ if (sbi->s_mount_opt & EXT3_MOUNT_WRITEBACK_DATA)
+ seq_puts(seq, ",data=writeback");
+
+ if (sbi->s_jquota_fmt)
+ seq_printf(seq, ",jqfmt=%s",
+ (sbi->s_jquota_fmt == QFMT_VFS_OLD) ? "vfsold": "vfsv0");
+
+ if (sbi->s_qf_names[USRQUOTA])
+ seq_printf(seq, ",usrjquota=%s", sbi->s_qf_names[USRQUOTA]);
+
+ if (sbi->s_qf_names[GRPQUOTA])
+ seq_printf(seq, ",grpjquota=%s", sbi->s_qf_names[GRPQUOTA]);
+
+ if (sbi->s_mount_opt & EXT3_MOUNT_USRQUOTA)
+ seq_puts(seq, ",usrquota");
+
+ if (sbi->s_mount_opt & EXT3_MOUNT_GRPQUOTA)
+ seq_puts(seq, ",grpquota");
+
+ return 0;
+}
#define QTYPE2NAME(t) ((t)==USRQUOTA?"user":"group")
#define QTYPE2MOPT(on, t) ((t)==USRQUOTA?((on)##USRJQUOTA):((on)##GRPJQUOTA))
@@ -572,6 +604,7 @@
#ifdef CONFIG_QUOTA
.quota_read = ext3_quota_read,
.quota_write= ext3_quota_write,
+ .show_options = ext3_show_options,
#endif
};
@@ -590,7 +623,8 @@
Opt_abort, Opt_data_journal, Opt_data_ordered, Opt_data_writeback,
Opt_usrjquota, Opt_grpjquota, Opt_offusrjquota, Opt_offgrpjquota,
Opt_jqfmt_vfsold, Opt_jqfmt_vfsv0, Opt_quota, Opt_noquota,
- Opt_ignore, Opt_barrier, Opt_err, Opt_resize,
+ Opt_ignore, Opt_barrier, Opt_err, Opt_resize, Opt_usrquota,
+ Opt_grpquota
};
static match_table_t tokens = {
@@ -634,10 +668,10 @@
{Opt_grpjquota, "grpjquota=%s"},
{Opt_jqfmt_vfsold, "jqfmt=vfsold"},
{Opt_jqfmt_vfsv0, "jqfmt=vfsv0"},
- {Opt_quota, "grpquota"},
+ {Opt_grpquota, "grpquota"},
{Opt_noquota, "noquota"},
{Opt_quota, "quota"},
- {Opt_quota, "usrquota"},
+ {Opt_usrquota, "usrquota"},
{Opt_barrier, "barrier=%u"},
{Opt_err, NULL},
{Opt_resize, "resize"},
@@ -902,8 +936,18 @@
case Opt_jqfmt_vfsv0:
sbi->s_jquota_fmt = QFMT_VFS_V0;
break;
+ case Opt_usrquota:
+ set_opt(sbi->s_mount_opt, QUOTA);
+ set_opt(sbi->s_mount_opt, USRQUOTA);
+ break;
+ case
Re: [PATCH] NMI watch dog notify patch
Andrew Morton wrote: George Anzinger wrote: This patch adds a notify to the nmi watchdog to notify that the system is about to be taken down by the watchdog. If the notify is handled with a NOTIFY_STOP return, the system is given a new lease on life. It looks sensible, but as there aren't actually any in-kernel uses for this I'd have thought it would be better for it to live out-of-tree? I should just bundle it with the kgdb patch then? -- George Anzinger george@mvista.com HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v850, which gcc and binutils version?
Hi Jan, Jan Dittmer wrote: Greg Ungerer wrote: If you care to try applying the uClinux patches, they should be available from (fill in "$ver" with "2.6.12-uc0" and "$maj_ver" with "2.6"): http://www.uclinux.org/pub/uClinux/uClinux-$maj_ver.x/linux-$ver.patch.gz Greg, do you have any status on merging the current uClinux patch set? I sent a bunch of the 2.6.12-uc0 changes to Linus earlier this week (the critical fixes), but according to his GIT log he didn't merge them. I am going to resend tomorrow. Greg you might consider adding the attached patch to update the defconfig for m68nommu, especially +# +# Console display driver support +# +# CONFIG_VGA_CONSOLE is not set +CONFIG_DUMMY_CONSOLE=y which allows the m68knommu defconfig to be buildable without further invention. Patch is against 2.6.12-uc0 Done. I'll add it to my list of patches to send. Regards Greg -- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] SnapGear -- a CyberGuard CompanyPHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Delete scheduler SD_WAKE_AFFINE and SD_WAKE_BALANCE flags
Nick Piggin wrote on Thursday, July 28, 2005 4:35 PM > Wake balancing provides an opportunity to provide some input bias > into the load balancer. > > For example, if you started 100 pairs of tasks which communicate > through a pipe. On a 2 CPU system without wake balancing, probably > half of the pairs will be on different CPUs. With wake balancing, > it should be much better. Shouldn't the pipe code use synchronous wakeup? > I hear you might be having problems with recent 2.6.13 kernels? If so, > it would be really good to have a look that before 2.6.13 goes out the > door. Yes I do :-(, apparently bumping up cache_hot_time won't give us the performance boost we used to see. - Ken - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
Michael Thonke <[EMAIL PROTECTED]> wrote: > > here again I have two problems. With 2.6.13-rc3-mm3 I have problems > using my SATA drives on Intel ICH6. > The kernel can't route there IRQs or can't discover them. the option > irqpoll got them to work now. > The problem is new because 2.6.13-rc3[-mm1,mm2] work without any problems. OK. Please generate the full dmesg output for -mm2 and for -mm3 and run `diff -u dmesg.mm2 dmesg.mm3' and send it? And keep those files because we may end up needing to add them to an acpi bugzilla entry ;) > The SATA drives are Samsung HD160JJ SATAII. The mainboard I use is a > ASUS P4GPL-X. > > Second one is about Intel HD-Codec (snd-hda-intel) on modprobe when > loading the module it gives me > > ---> snip > hda_codec: Unknown model for ALC880, trying auto-probe from BIOS... Does -mm2 print that `unknown model' message? > Unable to handle kernel NULL pointer dereference at virtual address > printing eip: > f88713f4 > *pde = > Oops: 0002 [#1] > PREEMPT > last sysfs file: > Modules linked in: snd_hda_intel snd_hda_codec nvidia > CPU:0 > EIP:0060:[]Tainted: P VLI Please verify that it happens without the nvidia module loaded. > EFLAGS: 00010293 (2.6.13-rc3-mm3pm) > eax: fffe ebx: f3b33548 ecx: edx: > esi: f3b33400 edi: ebp: 0006 esp: f0371ddc > ds: 007b es: 007b ss: 0068 > Process modprobe (pid: 7398, threadinfo=f037 task=f4183560) > Stack: f3b33400 f3b33548 f0f1d000 > f8871933 > f3b33400 f0f1d000 f8871bbd f8875478 f88748f6 0001 f886d77e > 0f00 > 0005 f0f1d000 f54d04c0 f886d984 0f00 > 0002 > Call Trace: > [] > [] Odd trace. Do you have CONFIG_KALLSYMS enabled? If not, please turn it on. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Delete scheduler SD_WAKE_AFFINE and SD_WAKE_BALANCE flags
Chen, Kenneth W wrote: What sort of workload needs SD_WAKE_AFFINE and SD_WAKE_BALANCE? SD_WAKE_AFFINE are not useful in conjunction with interrupt binding. In fact, it creates more harm than usefulness, causing detrimental process migration and destroy process cache affinity etc. Also SD_WAKE_BALANCE is giving us performance grief with our industry standard OLTP workload. The periodic load balancer basically makes completely undirected, random choices when picking which tasks to move where. Wake balancing provides an opportunity to provide some input bias into the load balancer. For example, if you started 100 pairs of tasks which communicate through a pipe. On a 2 CPU system without wake balancing, probably half of the pairs will be on different CPUs. With wake balancing, it should be much better. I've also been told that it impoves IO efficiency significantly - obviously that depends on the system and workload. To demonstrate the problem, we turned off these two flags in the cpu sd domain and measured a stunning 2.15% performance gain! And deleting all the code in the try_to_wake_up() pertain to load balancing gives us another 0.2% gain. The wake up patch should be made simple, just put the waking task on the previously ran cpu runqueue. Simple and elegant. I'm proposing we either delete these two flags or make them run time configurable. There have been lots of changes since 2.6.12. Including less aggressive wake balancing. I hear you might be having problems with recent 2.6.13 kernels? If so, it would be really good to have a look that before 2.6.13 goes out the door. I appreciate all the effort you're putting into this! Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.13-rc4
Hey everybody, as many of you are aware, we were talking (not enough) about the release process at LKS this year. This ain't it. This is just the regular old release "process", with some LKS backlog put in for good measure. But the good news is, that I'll try the new release process after 2.6.13 is out, which is hopefully not too far away. Which means that we should try to let people know about the fact that if they want to merge stuff, they should do so in the first two weeks after the 2.6.13 release, and no later (also, no earlier either, by now). So if you have a favourite kernel developer, please wake him up with a friendly kick to the head and explain this concept to him in small easy-to-understand words, and tell him that we're in the freeze process for 2.6.13 now, and that he should be gathering up the patches, and make sure they get to me _after_ 2.6.13 is out, but at that point do it in a timely manner. Ok? In the meantime, here's the 2.6.13-rc4 update, with a diffstat so horribly ugly that I won't even show it (the kernel list would eat it as too big anyway), and I'll have to go fix my code that generates it. Oh, and in case you wonder, it's ugly because a cris architecture update with long filenames that really causes git-apply to output som rather nasty-looking diffstats ;) ALSA, IB, NTFS, SCSI (qla2xxx) and the cris architecture update. Linus Adrian Bunk: VIDEO_SAA7134 must depend on SOUND drivers/media/video/tveeprom.c: possible cleanups Documentation/Changes: document the required udev version m32r: add missing Kconfig help text i386: add missing Kconfig help text drivers/pnp/pnpbios/rsparser.c: fix compile error with PCI=n [NETFILTER]: Fix ip_conntrack_put() prototype. [SPARC]: Remvoe APM_RTC_IS_GMT from config. [NET]: NETCONSOLE must depend on INET [NET]: BRIDGE_EBT_ARPREPLY must depend on INET [IPV4]: fix IP_FIB_HASH kconfig warning Alan Stern: scsi_scan: check return code from scsi_sysfs_add_sdev Alexander Schulz: ARM: 2816/1: Shark: boot kernel images bigger than 1 MB ARM: 2815/1: Shark: new defconfig, fixes with __io and serial ports Alexey Dobriyan: drm: via: fix sparse warnings Really __nocast-annotate kmalloc_node() visws: reexport pm_power_off Andi Kleen: Undo mempolicy shared policy rbtree microoptimization x86_64: fix SMP boot lockup on some machines Andreas Gruenbacher: reiserfs doesn't use mbcache mbcache: Remove unused mb_cache_shrink parameter Andreas Steinmetz: Fix RLIMIT_RTPRIO breakage Andrew Morton: bio_clone fix Avoid device suspend on reboot ppc64: tpm_infineon build fix ppc64: genrtc build fix statically link halfmd4 check_user_page_readable() deadlock fix user_mode_vm() build fix x86_64 fsnotify build fix softdog build fix eurotechwdt build fix qla2xxx: Kconfig dependency fix qla: remove anonymous union inotify: fix oops fix [SCSI] dpt_i2o warning fix [SCSI] aic79xx: ahd_linux_dev_reset() cleanup Andrew Vasquez: More qla2xxx configuration fixes [SCSI] qla2xxx: Cleanup FC remote port registration. [SCSI] qla2xxx: Consolidate ISP24xx chip reset logic. [SCSI] qla2xxx: Add firmware version number to qla24xx_fw_version_str(). [SCSI] qla2xxx: Update version number to 8.01.00b5-k. [SCSI] qla2xxx: Correct maximum supported lun and target-id definitions. [SCSI] qla2xxx: Update copyright banner. [SCSI] qla2xxx: Firmware updates. [SCSI] qla2xxx: Code scrubbing. [SCSI] qla2xxx: NVRAM id-list updates. [SCSI] qla2xxx: Add OS initialization codes for ISP24xx recognition. [SCSI] qla2xxx: Add ISP24xx initialization routines. [SCSI] qla2xxx: Add ISP24xx ISR routines. [SCSI] qla2xxx: Add ISP24xx IOCB manipulation routines. [SCSI] qla2xxx: Add ISP24xx flash-manipulation routines. [SCSI] qla2xxx: Add MBX command routines for ISP24xx support. [SCSI] qla2xxx: Generalize SNS generic-services routines. [SCSI] qla2xxx: Add ISP24xx diagnostic routines. [SCSI] qla2xxx: Add ISP24xx definitions. [SCSI] qla2xxx: Add pci ids for new ISP types. [SCSI] qla2xxx: Factor-out ISP specific functions to method-based call tables. Andrey Panin: consolidate CONFIG_WATCHDOG_NOWAYOUT handling Serial: Add support for SIIG Quartet serial card Andy Whitcroft: Remove bogus warning in page_alloc.c Anton Altaparmakov: Automatic merge with /usr/src/ntfs-2.6.git. Fix soft lockup due to NTFS: VFS part and explanation Automatic merge with /usr/src/ntfs-2.6.git. Automerge with /usr/src/ntfs-2.6.git. Automatic merge with /usr/src/ntfs-2.6.git. NTFS: Fix a nasty deadlock that appeared in recent kernels. NTFS: Prepare for 2.1.23 release: Update documentation and bump version. NTFS: Change ntfs_map_runlist_nolock() to only decompress the mapping pairs NTFS: Add an extra parameter @last_vcn to ntfs_get_size_for_mapping_pairs() NTFS: Change the runlist terminator of the newly allocated cluster(s) to NTFS: Fix several occurences of
Re: 2.6.13-rc3-mm3
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > Could you please tell me how I can figure out the order in which the > individual > patches in -mm have been applied? It's all in the series file: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/patch-series The simplest way to do a binary search is to grab ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/2.6.13-rc3-mm3-broken-out.tar.bz2 and to place all the patches in ./patches/, place the series file in ./series, download and install https://savannah.nongnu.org/projects/quilt/ and do the binary search with `quilt push' and `quilt pop'. It's pretty simple - it'll take ten minutes to get the hang of it. You need to create a separate copy of the series file and edit it to record where you're up to in the search. From experience ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Christoph Lameter <[EMAIL PROTECTED]> wrote: > > On Fri, 29 Jul 2005, Pavel Machek wrote: > > > > Dont fix it up. Remove the ealier patch. > > > > Oops. Do you happen to have patch relative to -mm or something? I'd > > prefer not to mess it up second time... > > Ok. I will make a patch against mm tomorrow. Well if you want to go this way I can just drop the TIF_FREEZE stuff and use the patches-relative-to-mainline. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: [PATCH] fbdev: colormap fixes
Geert Uytterhoeven wrote: On Thu, 28 Jul 2005, Antonino A. Daplas wrote: Jon Smirl wrote: On 7/28/05, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: On Wed, 27 Jul 2005, Linux Kernel Mailing List wrote: There are a couple of ways to fix this. 1) Add a check to limit use of the sysfs attributes to 256 entries. If you want more you have to use /dev/fb0 and the ioctl. More is an uncommon case. 2) Switch this to a binary parameter. Now you have to use tools like hexdump instead of cat to work with the data. It was nice to be able to use cat to see the current map. Does anyone have preferences for which way to fix it? Or... 3) Add another file in sysfs which specifies at what index and how many entries will be read or written from or to the cmap. With this additional sysfs file, it should be able to handle any reasonable cmap length, but it will take more than one reading of the color_map file. Another advantage is that the entire color map need not be read or written if only one field needs to be changed. I've attached a test patch. Let me know what you think. I like it! ... But, a disadvantages is that it needs to store state between two non-atomic operations. E.g. imagine two processes doing this at the same time. We can add a check that if the incoming buffer index start and length does not match the current start and len (as set by cmap_range), then exit with and empty buffer. Conversely, users can always check if the output read from color_map matches the value it entered in cmap_range. As a side note: The rest of the fbsysfs attributes suffer from the same thing, especially since the value of each attribute depends on each other. What if one process reads the virtual_size, while another one changes the bits_per_pixel? I'm pretty sure that setting bits_per_pixel to a higher value will almost always change the virtual_size. Currently, the only way to guarantee atomicity is to use the ioctls. The main reason why we change the video mode, framebuffer format, color format, etc in one go with fb_set_var() is precisely this. 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NMI watch dog notify patch
George Anzinger wrote: > > This patch adds a notify to the nmi watchdog to notify that > the system is about to be taken down by the watchdog. If the > notify is handled with a NOTIFY_STOP return, the system is > given a new lease on life. It looks sensible, but as there aren't actually any in-kernel uses for this I'd have thought it would be better for it to live out-of-tree? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Delete scheduler SD_WAKE_AFFINE and SD_WAKE_BALANCE flags
What sort of workload needs SD_WAKE_AFFINE and SD_WAKE_BALANCE? SD_WAKE_AFFINE are not useful in conjunction with interrupt binding. In fact, it creates more harm than usefulness, causing detrimental process migration and destroy process cache affinity etc. Also SD_WAKE_BALANCE is giving us performance grief with our industry standard OLTP workload. To demonstrate the problem, we turned off these two flags in the cpu sd domain and measured a stunning 2.15% performance gain! And deleting all the code in the try_to_wake_up() pertain to load balancing gives us another 0.2% gain. The wake up patch should be made simple, just put the waking task on the previously ran cpu runqueue. Simple and elegant. I'm proposing we either delete these two flags or make them run time configurable. - Ken --- linux-2.6.12/include/linux/topology.h.orig 2005-07-28 15:54:05.007399685 -0700 +++ linux-2.6.12/include/linux/topology.h 2005-07-28 15:54:39.29215 -0700 @@ -118,9 +118,7 @@ .flags = SD_LOAD_BALANCE \ | SD_BALANCE_NEWIDLE\ | SD_BALANCE_EXEC \ - | SD_WAKE_AFFINE\ - | SD_WAKE_IDLE \ - | SD_WAKE_BALANCE, \ + | SD_WAKE_IDLE, \ .last_balance = jiffies, \ .balance_interval = 1,\ .nr_balance_failed = 0,\ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
On Fri, 29 Jul 2005, Pavel Machek wrote: > > Dont fix it up. Remove the ealier patch. > > Oops. Do you happen to have patch relative to -mm or something? I'd > prefer not to mess it up second time... Ok. I will make a patch against mm tomorrow. Patches are typically against Linus latest and if you test against mm then you may see breakage from other patches. Plus there will be dependencies with other patches in mm. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Where's the list of needed hardware for donating?
Hi! > Does a list exist describing the hardware needed or wished for to > extend coverage for kernel development? I saw such a list at openbsd > and thought it was a good idea. Heh, second zaurus for testing would certainly help ;-). Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1 (ckrm)
Thanks for your well worded response, Shailabh. Others will have to make further comments and decisions here. You have understood what I had to say, and responded well. I have nothing to add at this point that would help further. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
unmounting a filesystem mounted by /init (initramfs)
I am trying to build a system that uses a unionfs as root. The init script is based on the one used by gentoo and uses initramfs. The problem is how to remount the unionfs constituents read only during halt. cat /proc/mounts displays /dev/hda1 (ext2) mounted rw in /memory. The problem is that /memory is no longer visible after the init script did a chroot and a mount -o remount,ro /dev/hda1 says that /dev/hda1 is not mounted! does any anyone has an idea? Thanks, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA PCI routing problem
Brown, Len wrote: Fix two systems, break another... Nick, can you open a bugzilla on this and put your lspci -vv and dmesg into it. Apparently the quirk is good for some machines and not as good for others and we need to get smarter about when to apply it. OK, done. I put it under ACPI though I'm not sure whether that's the right place for it. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ALSA PATCH] 1.0.9b+
On Thursday 28 Jul 2005 18:25, Andrew Morton wrote: > Jaroslav Kysela <[EMAIL PROTECTED]> wrote: > > Linus, please do an update from: > > > >rsync://rsync.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git > > > > ... > > 65 files changed, 5059 insertions(+), 1122 deletions(-) > > The git-alsa.patch in -mm which I obtain from > master.kernel.org:/pub/scm/linux/kernel/git/perex/alsa-current.git is > empty. So we're now wanting to merge 4,000 lines of unreviewed code which > hasn't been tested in -mm at approximately the -rc4 stage. ~2800 lines of which is a new driver. It'd be nice if ALSA's release schedule for "stable" versus "rc" could match the kernel's. For example, 2.6.12 shipped with 1.0.9rc2. Maybe "rc" ALSA should only be accepted in rc1, by rc4 you hope they can wrap things up and give you a stable version number? Okay, generally in-tree version numbers don't count for much, but I think ALSA is a big exception because it's maintained pretty much out of tree. Not so much of an issue this time around, but I don't think new drivers or rewrites (even if they are reasonably separate) should be going in a late -rc kernel. Just my two pence. -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] random : prefetch the whole pool, not 1/4 of it
On Fri, Jul 29, 2005 at 12:26:11AM +0200, Eric Dumazet wrote: > Hi Matt > > Could you check this patch and apply it ? > > Thank you > > Eric > > [RANDOM] : prefetch the whole pool, not 1/4 of it, >(pool contains u32 words, not bytes) You probably want r->poolinfo->poolwords as wordmask is off by one? Please use "x * 4" rather than "x*4" too. > --- linux-2.6.13-rc3/drivers/char/random.c2005-07-13 06:46:46.0 > +0200 > +++ linux-2.6.13-rc3-ed/drivers/char/random.c 2005-07-29 00:11:24.0 > +0200 > @@ -469,7 +469,7 @@ > next_w = *in++; > > spin_lock_irqsave(>lock, flags); > - prefetch_range(r->pool, wordmask); > + prefetch_range(r->pool, wordmask*4); > input_rotate = r->input_rotate; > add_ptr = r->add_ptr; > -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA PCI routing problem
Bjorn Helgaas wrote: Can you try this: [...] If that doesn't help, remove it and see if this does: [...] Can you also include "lspci" output? Neither worked. I'll open a bugzilla and include lspci and dmesg there. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] random : prefetch the whole pool, not 1/4 of it
Hi Matt Could you check this patch and apply it ? Thank you Eric [RANDOM] : prefetch the whole pool, not 1/4 of it, (pool contains u32 words, not bytes) Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> --- linux-2.6.13-rc3/drivers/char/random.c 2005-07-13 06:46:46.0 +0200 +++ linux-2.6.13-rc3-ed/drivers/char/random.c 2005-07-29 00:11:24.0 +0200 @@ -469,7 +469,7 @@ next_w = *in++; spin_lock_irqsave(>lock, flags); - prefetch_range(r->pool, wordmask); + prefetch_range(r->pool, wordmask*4); input_rotate = r->input_rotate; add_ptr = r->add_ptr;
Re: [Linux-fbdev-devel] Re: [PATCH] fbdev: colormap fixes
Jon Smirl wrote:
On 7/28/05, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
On Thu, 28 Jul 2005, Jon Smirl wrote:
I've verified now that all ATI R300+ chips have 10bit cmaps. These are
pretty common so I'd be in favor of making this into a binary
attribute where I can get/set the whole table at once. Given that
OpenGL is already supporting 12 and 16 bits these tables are only
going to get much larger.
1024 entries * 5 fields * 2 bytes = 10KB -- too big for a text attribute.
65536 entries * 5 fields * 2 bytes = 655KB -- way too big for a text attribute.
The bits_per_pixel sysfs attribute is an easy way to tell how many
entries you need. You can just set it at 4, 8, 10, etc until you get
an error. Now you know the max. 2^n and you know how many entries.
No, bits_per_pixel can be (much) larger than the color map size. E.g. a simple
ARGB directcolor mode has bits_per_pixel = 32 and color map size = 256.
So I have the bits_per_pixel attribute wrong in sysfs. It needs to be
bits_per_color and then let the driver sort it out. Otherwise there
is no way to set ARGB versus ARGB2101010. With bits per color you
would set 8 or 10.
No, you have to add another attribute for {transp|red|green|blue}.{len,offset}
and another attribute for the pixelformat. Then using those, one can
easily deduce the cmap size.
If that isn't good enough I can switch the attribute to take strings
like ARGB.
Please no.
What do you think, should I just switch to fbconfig names and a binary
cmap attribute?
Does a binary attribute not have the same buffer size limitation as
the text attribute? I really don't know, just asking.
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.32-pre2
On Thu, Jul 28, 2005 at 07:02:30PM +1000, Grant Coady wrote:
> On Wed, 27 Jul 2005 05:05:12 -0300, Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
> >
> >Here goes another -pre, after a long period.
>
> Breaks Toshiba laptop: hard lockup --> what is on screen is same as
> working dmesg up to point: "host/uhci.c: detected 2 port"
>
> Same .config as for 2.4.31-hf3 or 2.4.32-pre1
> http://scatter.mine.nu/test/linux-2.4/tosh/
Please try to revert the attached?
[PATCH] file_storage and UHCI bugfixes
The patch below (as547) corrects two minor errors, one in the
file_storage gadget driver (need to send a length-zero packet if a
control response is short) and one in the alternate UHCI driver (need
to set the QH bit in the frame list). Both of these are back-ports of
things that have been in 2.6 for several releases.
diff --git a/drivers/usb/gadget/file_storage.c
b/drivers/usb/gadget/file_storage.c
--- a/drivers/usb/gadget/file_storage.c
+++ b/drivers/usb/gadget/file_storage.c
@@ -1454,6 +1454,7 @@ static int fsg_setup(struct usb_gadget *
/* Respond with data/status or defer until later? */
if (rc >= 0 && rc != DELAYED_STATUS) {
fsg->ep0req->length = rc;
+ fsg->ep0req->zero = (rc < ctrl->wLength);
fsg->ep0req_name = (ctrl->bRequestType & USB_DIR_IN ?
"ep0-in" : "ep0-out");
rc = ep0_queue(fsg);
diff --git a/drivers/usb/host/uhci.c b/drivers/usb/host/uhci.c
--- a/drivers/usb/host/uhci.c
+++ b/drivers/usb/host/uhci.c
@@ -2924,7 +2924,7 @@ static int alloc_uhci(struct pci_dev *de
}
/* Only place we don't use the frame list routines */
- uhci->fl->frame[i] = uhci->skeltd[irq]->dma_handle;
+ uhci->fl->frame[i] = uhci->skeltd[irq]->dma_handle |
UHCI_PTR_QH;
}
start_hc(uhci);
Re: 2.6.12: no sound on SPDIF with emu10k1
On Thu, 2005-07-28 at 03:13 -0700, Avuton Olrich wrote: > After upgrading to 1.0.9, I thought my emu10k1 board was broken until > I toggled 'IEC958 Optical Raw' to Off. Many thanks, that did the trick! I have now tried to only load the emu10k1 driver modules and found that 2.6.12's ALSA is VERY different from all previous versions in that it does not mute all channels by default any more. Tom -- T h o m a s Z e h e t b a u e r ( TZ251 ) PGP encrypted mail preferred - KeyID 96FFCB89 finger [EMAIL PROTECTED] for key -BEGIN GEEK CODE BLOCK- GS/IT d-- s: a-- C UL P+>$ L++>$ E--- W+ N+ o? !K w++$ O M- V? PS+++ PE++ Y+ PGP+++ t+ 5 X R- tv b- DI(+) D+ G>++ e h! !r y+ --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part
quick question; did usb hid change from .12 to .13-rc3 on x86_64?
I've a quick question before I start digging through patches between .12 and .13-rc3, /dev/input/mice (usb mice) stopped yielding data. dmesg indicates removal/re-insertion of the device but no driver registers and nothing comes from /dev/input/mice. I have rc-3 on other machines and the mouse is working fine, so it's got to be something specific to this machine. It's an AMD64 machine. :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 I/O ports at b400 [size=32] Capabilities: [80] Power Management version 2 :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 I/O ports at b800 [size=32] Capabilities: [80] Power Management version 2 :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 I/O ports at c000 [size=32] Capabilities: [80] Power Management version 2 :00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 I/O ports at c400 [size=32] Capabilities: [80] Power Management version 2 :00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 201 Memory at fdf0 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 Scott ~ # zcat /proc/config.gz|egrep -i "^CON.*(_hid|mouse)" CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y CONFIG_USB_HIDDEV=y CONFIG_USB_IDMOUSE=y 2.6.12: usb 3-2: USB disconnect, address 2 usb 3-2: new low speed USB device using uhci_hcd and address 3 midi: probe of 3-2:1.0 failed with error -5 input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-:00:10.1-2 2.6.13-rc3 usb 3-2: USB disconnect, address 2 usb 3-2: new low speed USB device using uhci_hcd and address 3 midi: probe of 3-2:1.0 failed with error -5 david - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix gconfig crash
From: Joachim Nilsson <[EMAIL PROTECTED]>
I ran glade-2 on the glade file, fixed two missing stock icons and
cleaned up the C code that inserts the single/split/full modes. The
rest of the patch is minor cleanups only. I refrained from using all
the included xpm icons in images.c (like qconf.cc does) in favour of
using the stock Gtk+ icons instead. Oh, yes there was a "back" bug
in split mode that I also removed, oh well...
It has been tested with success by several people, including
Jesper Juhl, Randy Dunlap and myself.
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
diff --git a/scripts/kconfig/gconf.c b/scripts/kconfig/gconf.c
--- a/scripts/kconfig/gconf.c
+++ b/scripts/kconfig/gconf.c
@@ -178,17 +178,31 @@ const char *dbg_print_ptype(int val)
}
-/* Main Window Initialization */
+void replace_button_icon(GladeXML * xml, GdkDrawable * window,
+GtkStyle * style, gchar * btn_name, gchar ** xpm)
+{
+ GdkPixmap *pixmap;
+ GdkBitmap *mask;
+ GtkToolButton *button;
+ GtkWidget *image;
+ pixmap = gdk_pixmap_create_from_xpm_d(window, ,
+ >bg[GTK_STATE_NORMAL],
+ xpm);
+
+ button = GTK_TOOL_BUTTON(glade_xml_get_widget(xml, btn_name));
+ image = gtk_image_new_from_pixmap(pixmap, mask);
+ gtk_widget_show(image);
+ gtk_tool_button_set_icon_widget(button, image);
+}
+/* Main Window Initialization */
void init_main_window(const gchar * glade_file)
{
GladeXML *xml;
GtkWidget *widget;
GtkTextBuffer *txtbuf;
char title[256];
- GdkPixmap *pixmap;
- GdkBitmap *mask;
GtkStyle *style;
xml = glade_xml_new(glade_file, "window1", NULL);
@@ -221,36 +235,22 @@ void init_main_window(const gchar * glad
style = gtk_widget_get_style(main_wnd);
widget = glade_xml_get_widget(xml, "toolbar1");
- pixmap = gdk_pixmap_create_from_xpm_d(main_wnd->window, ,
- >bg[GTK_STATE_NORMAL],
- (gchar **) xpm_single_view);
- gtk_image_set_from_pixmap(GTK_IMAGE
- (((GtkToolbarChild
-*) (g_list_nth(GTK_TOOLBAR(widget)->
- children,
- 5)->data))->icon),
- pixmap, mask);
- pixmap =
- gdk_pixmap_create_from_xpm_d(main_wnd->window, ,
->bg[GTK_STATE_NORMAL],
-(gchar **) xpm_split_view);
- gtk_image_set_from_pixmap(GTK_IMAGE
- (((GtkToolbarChild
-*) (g_list_nth(GTK_TOOLBAR(widget)->
- children,
- 6)->data))->icon),
- pixmap, mask);
- pixmap =
- gdk_pixmap_create_from_xpm_d(main_wnd->window, ,
->bg[GTK_STATE_NORMAL],
-(gchar **) xpm_tree_view);
- gtk_image_set_from_pixmap(GTK_IMAGE
- (((GtkToolbarChild
-*) (g_list_nth(GTK_TOOLBAR(widget)->
- children,
- 7)->data))->icon),
- pixmap, mask);
+#if 0 /* Use stock Gtk icons instead */
+ replace_button_icon(xml, main_wnd->window, style,
+ "button1", (gchar **) xpm_back);
+ replace_button_icon(xml, main_wnd->window, style,
+ "button2", (gchar **) xpm_load);
+ replace_button_icon(xml, main_wnd->window, style,
+ "button3", (gchar **) xpm_save);
+#endif
+ replace_button_icon(xml, main_wnd->window, style,
+ "button4", (gchar **) xpm_single_view);
+ replace_button_icon(xml, main_wnd->window, style,
+ "button5", (gchar **) xpm_split_view);
+ replace_button_icon(xml, main_wnd->window, style,
+ "button6", (gchar **) xpm_tree_view);
+#if 0
switch (view_mode) {
case SINGLE_VIEW:
widget = glade_xml_get_widget(xml, "button4");
@@ -265,7 +265,7 @@ void init_main_window(const gchar * glad
g_signal_emit_by_name(widget, "clicked");
break;
}
-
+#endif
txtbuf = gtk_text_view_get_buffer(GTK_TEXT_VIEW(text_w));
tag1 = gtk_text_buffer_create_tag(txtbuf, "mytag1",
"foreground", "red",
@@ -322,7 +322,7 @@ void init_left_tree(void)
gtk_tree_view_set_model(view,
Re: [Linux-fbdev-devel] Re: [PATCH] fbdev: colormap fixes
Jon Smirl wrote: Can you review this fix for the issues below? I fixed things to automatically adjust the number of entries to whatever fits in PAGE_SIZE. diff --git a/drivers/video/fbsysfs.c b/drivers/video/fbsysfs.c --- a/drivers/video/fbsysfs.c +++ b/drivers/video/fbsysfs.c @@ -244,15 +244,15 @@ static ssize_t show_virtual(struct class /* Format for cmap is "%02x%c%4x%4x%4x\n" */ Why is the alpha channel not given the same weight as the RGB? Wouldn't it be correct to also give it 4 bytes (16 bits) Also, what would happen if you exceed 256 entries, you've only alloted a maximum of 256 for the index? This will also be a problem because you cannot access cmap entries past 255. So, 4 bytes per channel + 4 bytes for the index will be needed per entry, 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.13-rc3] sis190 driver
Single file patch: http://www.zoreil.com/~romieu/sis190/20050728-2.6.13-rc3-sis190-test.patch Patch-kit: http://www.zoreil.com/~romieu/sis190/20050728-2.6.13-rc3/patches Tarball: http://www.zoreil.com/~romieu/sis190/20050728-2.6.13-rc3.tar.bz2 Changes from previous version (20050722) o Add endian annotations (Alexey Dobriyan). o Hopefully fixed the build of the patch. o Minor round of mii/phy related changes. May crash. Testing reports/review/patches are always appreciated. Ok, now back to washing. -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Hi! > > > > Introduce a todo notifier in the task_struct so that a task can be told > > > > to do > > > > certain things. Abuse the suspend hooks try_to_freeze, freezing and > > > > refrigerator > > > > to establish checkpoints where the todo list is processed. This will > > > > break software > > > > suspend (next patch fixes and cleans up software suspend). > > > > > > Ugh, this conflicts with stuff in -mm tree rather badly... In part > > > thanks to patch by you that was already applied. > > > > > > I fixed up rejects manually (but probably lost fix or two in > > > progress), and will test. > > Dont fix it up. Remove the ealier patch. Oops. Do you happen to have patch relative to -mm or something? I'd prefer not to mess it up second time... > > > You are doing rather intrusive changes. Is testing them too much to > > > ask? I'm pretty sure you can get i386 machine to test swsusp on... > > > > (And yes, I did apply the whole series. It would be nice if next > > series was relative to -mm, it already contains some of your changes). > > mm contains the TIF_FREEZE changes that need to be undone. And yes I > tested it on a i386 with suspend to disk and it worked fine. Sorry. Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] drivers/net/wireless/hostap/hostap.c: EXPORT_SYMTAB does nothing
There's no need to define something if it doesn't has any effect. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch was already sent on: - 10 Jul 2005 --- linux-2.6.13-rc2-mm1-full/drivers/net/wireless/hostap/hostap.c.old 2005-07-10 17:31:01.0 +0200 +++ linux-2.6.13-rc2-mm1-full/drivers/net/wireless/hostap/hostap.c 2005-07-10 17:33:01.0 +0200 @@ -12,10 +12,6 @@ * more details. */ -#ifndef EXPORT_SYMTAB -#define EXPORT_SYMTAB -#endif - #include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] net: Spelling mistakes threshoulds -> thresholds
Just simple spelling mistake fixes.
From: aruch Even <[EMAIL PROTECTED]>
Signed-Off-By: Baruch Even <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 12 Jul 2005
This patch was sent by Baruch Even on:
- 05 Apr 2005
--- 2.6.11.orig/include/net/tcp.h 2005-03-16 00:09:00.0 +
+++ 2.6.11/include/net/tcp.h2005-04-05 14:33:13.473828484 +0100
@@ -1351,7 +1351,7 @@ static inline void tcp_cwnd_validate(str
}
}
-/* Set slow start threshould and cwnd not falling to slow start */
+/* Set slow start threshold and cwnd not falling to slow start */
static inline void __tcp_enter_cwr(struct tcp_sock *tp)
{
tp->undo_marker = 0;
diff -Nurp -X dontdiff 2.6.11.orig/net/ipv4/ipmr.c 2.6.11/net/ipv4/ipmr.c
--- 2.6.11.orig/net/ipv4/ipmr.c 2005-03-16 00:09:06.0 +
+++ 2.6.11/net/ipv4/ipmr.c 2005-04-05 14:33:13.541817170 +0100
@@ -359,7 +359,7 @@ out:
/* Fill oifs list. It is called under write locked mrt_lock. */
-static void ipmr_update_threshoulds(struct mfc_cache *cache, unsigned char
*ttls)
+static void ipmr_update_thresholds(struct mfc_cache *cache, unsigned char
*ttls)
{
int vifi;
@@ -721,7 +721,7 @@ static int ipmr_mfc_add(struct mfcctl *m
if (c != NULL) {
write_lock_bh(_lock);
c->mfc_parent = mfc->mfcc_parent;
- ipmr_update_threshoulds(c, mfc->mfcc_ttls);
+ ipmr_update_thresholds(c, mfc->mfcc_ttls);
if (!mrtsock)
c->mfc_flags |= MFC_STATIC;
write_unlock_bh(_lock);
@@ -738,7 +738,7 @@ static int ipmr_mfc_add(struct mfcctl *m
c->mfc_origin=mfc->mfcc_origin.s_addr;
c->mfc_mcastgrp=mfc->mfcc_mcastgrp.s_addr;
c->mfc_parent=mfc->mfcc_parent;
- ipmr_update_threshoulds(c, mfc->mfcc_ttls);
+ ipmr_update_thresholds(c, mfc->mfcc_ttls);
if (!mrtsock)
c->mfc_flags |= MFC_STATIC;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] include/linux/blkdev.h: "extern inline" -> "static inline"
"extern inline" doesn't make much sense.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.13-rc3-mm3-full/include/linux/blkdev.h.old2005-07-28
16:07:30.0 +0200
+++ linux-2.6.13-rc3-mm3-full/include/linux/blkdev.h2005-07-28
16:08:12.0 +0200
@@ -727,7 +727,7 @@
return bits;
}
-extern inline unsigned int block_size(struct block_device *bdev)
+static inline unsigned int block_size(struct block_device *bdev)
{
return bdev->bd_block_size;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
Michael Thonke wrote: > Hello Andrew, > > here again I have two problems. With 2.6.13-rc3-mm3 I have problems > using my SATA drives on Intel ICH6. > The kernel can't route there IRQs or can't discover them. the option > irqpoll got them to work now. > The problem is new because 2.6.13-rc3[-mm1,mm2] work without any > problems. > > The SATA drives are Samsung HD160JJ SATAII. The mainboard I use is a > ASUS P4GPL-X. > > Second one is about Intel HD-Codec (snd-hda-intel) on modprobe when > loading the module it gives me > > ---> snip > hda_codec: Unknown model for ALC880, trying auto-probe from BIOS... > Unable to handle kernel NULL pointer dereference at virtual address > Hi! Sorry for interfering but I have the Asus P5RD1-VD with the Realtek ALC861 (10b9:5461) and with 2.6.13.3 I've got the problem that he doesn't find /dev/mixer or anything after modprobe snd-hda-intel... After I attached http://dlsvr01.asus.com/pub/ASUS/mb/socket775/P5RD1-V/Audio_Linux.zip (which doesn't work) to a mail in alsa-devel they told me... "[...] It tries to access the ALi controller in the same way as the Intel controller. It may be possible that the ALi chip was designed to be compatible with Intel's, but that they got some detail wrong. Or that the driver gets some detail wrong. There's no way to know without docs[...]" (not in the archive, yet...) Dirk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
On Thu, 28 Jul 2005, Pavel Machek wrote: > Hi! > > > > Introduce a todo notifier in the task_struct so that a task can be told > > > to do > > > certain things. Abuse the suspend hooks try_to_freeze, freezing and > > > refrigerator > > > to establish checkpoints where the todo list is processed. This will > > > break software > > > suspend (next patch fixes and cleans up software suspend). > > > > Ugh, this conflicts with stuff in -mm tree rather badly... In part > > thanks to patch by you that was already applied. > > > > I fixed up rejects manually (but probably lost fix or two in > > progress), and will test. Dont fix it up. Remove the ealier patch. > > > > You are doing rather intrusive changes. Is testing them too much to > > ask? I'm pretty sure you can get i386 machine to test swsusp on... > > (And yes, I did apply the whole series. It would be nice if next > series was relative to -mm, it already contains some of your changes). mm contains the TIF_FREEZE changes that need to be undone. And yes I tested it on a i386 with suspend to disk and it worked fine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3: swsusp works (TP 600X)
On Thursday, 28 of July 2005 23:36, Pavel Machek wrote:
> Hi!
>
> > >>If I don't eject the pcmcia card (usually a prism54 wireless card),
> > >>swsusp begins the process of hibernation, but never gets to the
> > >>writing pages part.
> >
> > > Well, it really may be the firmware loading. Add some printks to
> > > confirm it, then fix it.
> >
> > I did more tests, this time with 2.6.13-rc3-mm2 (machine is a TP 600X),
> > and I don't think the problem is related to firmware loading. If I
> > first physically eject the card (an Intersil wireless card), swsusp
> > prints
> >
> ..
> >
> > then it writes pages to swap and all is well. Well, almost 100%; the
> > one glitch is that sometimes X comes back blank and I have to
> > ctrl-alt-F7 to bring back the display; or X comes back with the keyboard
> > acting strange ( shifts the display left by a few hundred
> > pixels), and again ctrl-alt-F7 fixes it. This is with XFree86
> > 4.3.0.dfsg.1-14, and maybe after I upgrade (?) to the xorg server, that
> > glitch will go away. Anyway, it's easy to work around.
>
> So, in short, problem is that if you leave prism54 card in, even with
> module removed, swsusp hangs, right?
>
> Okay then, start looking into pcmcia layer ;-).
Perhaps the patch from Daniel Ritz to free the yenta IRQ on suspend (attached)
will help?
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
--- linux-2.6.13-rc3-git5/drivers/pcmcia/yenta_socket.c 2005-07-23 19:26:30.0 +0200
+++ patched/drivers/pcmcia/yenta_socket.c 2005-07-24 11:44:04.0 +0200
@@ -1107,6 +1107,8 @@ static int yenta_dev_suspend (struct pci
pci_read_config_dword(dev, 17*4, >saved_state[1]);
pci_disable_device(dev);
+ free_irq(dev->irq, socket);
+
/*
* Some laptops (IBM T22) do not like us putting the Cardbus
* bridge into D3. At a guess, some other laptop will
@@ -1132,6 +1134,13 @@ static int yenta_dev_resume (struct pci_
pci_enable_device(dev);
pci_set_master(dev);
+ if (socket->cb_irq)
+ if (request_irq(socket->cb_irq, yenta_interrupt,
+ SA_SHIRQ, "yenta", socket)) {
+printk(KERN_WARNING "Yenta: request_irq() failed on resume!\n");
+socket->cb_irq = 0;
+ }
+
if (socket->type && socket->type->restore_state)
socket->type->restore_state(socket);
}
Re: [Linux-fbdev-devel] Re: [PATCH] fbdev: colormap fixes
On 7/28/05, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: > On Thu, 28 Jul 2005, Jon Smirl wrote: > > I've verified now that all ATI R300+ chips have 10bit cmaps. These are > > pretty common so I'd be in favor of making this into a binary > > attribute where I can get/set the whole table at once. Given that > > OpenGL is already supporting 12 and 16 bits these tables are only > > going to get much larger. > > > > 1024 entries * 5 fields * 2 bytes = 10KB -- too big for a text attribute. > > > > 65536 entries * 5 fields * 2 bytes = 655KB -- way too big for a text > > attribute. > > > > The bits_per_pixel sysfs attribute is an easy way to tell how many > > entries you need. You can just set it at 4, 8, 10, etc until you get > > an error. Now you know the max. 2^n and you know how many entries. > > No, bits_per_pixel can be (much) larger than the color map size. E.g. a simple > ARGB directcolor mode has bits_per_pixel = 32 and color map size = 256. So I have the bits_per_pixel attribute wrong in sysfs. It needs to be bits_per_color and then let the driver sort it out. Otherwise there is no way to set ARGB versus ARGB2101010. With bits per color you would set 8 or 10. If that isn't good enough I can switch the attribute to take strings like ARGB. What do you think, should I just switch to fbconfig names and a binary cmap attribute? -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch 2.6.13-rc3-mm3]fs/reiser4/plugin/item/static_stat.c fix -Wundef errors in two files
This fixes -Wundef errors in:
fs/reiser4/plugin/item/static_stat.c
Nick Sillik
[EMAIL PROTECTED]
Signed-off-by: Nick Sillik <[EMAIL PROTECTED]>
diff -urN a/fs/reiser4/plugin/item/static_stat.c
b/fs/reiser4/plugin/item/static_stat.c
--- a/fs/reiser4/plugin/item/static_stat.c 2005-07-28 17:36:09.0
-0400
+++ b/fs/reiser4/plugin/item/static_stat.c 2005-07-28 17:39:43.0
-0400
@@ -36,7 +36,7 @@
assert("nikita-617", *length >= 0);
}
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
/* ->print() method of static sd item. Prints human readable information about
sd at @coord */
reiser4_internal void
@@ -415,7 +415,7 @@
return 0;
}
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
static void
print_lw_sd(const char *prefix, char **area /* position in stat-data */ ,
int *len /* remaining length */ )
@@ -505,7 +505,7 @@
return 0;
}
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
static void
print_unix_sd(const char *prefix, char **area /* position in stat-data */ ,
int *len /* remaining length */ )
@@ -569,7 +569,7 @@
return 0;
}
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
static void
print_large_times_sd(const char *prefix, char **area /* position in stat-data
*/,
int *len /* remaining length */ )
@@ -674,7 +674,7 @@
return result;
}
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
static void
print_symlink_sd(const char *prefix, char **area /* position in stat-data */ ,
int *len /* remaining length */ )
@@ -1049,7 +1049,7 @@
return result;
}
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
static void
print_crypto_sd(const char *prefix, char **area /* position in stat-data */ ,
int *len /* remaining length */ )
@@ -1082,7 +1082,7 @@
.absent = NULL,
.save_len = save_len_lw_sd,
.save = save_lw_sd,
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
.print = print_lw_sd,
#endif
.alignment = 8
@@ -1100,7 +1100,7 @@
.absent = absent_unix_sd,
.save_len = save_len_unix_sd,
.save = save_unix_sd,
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
.print = print_unix_sd,
#endif
.alignment = 8
@@ -1118,7 +1118,7 @@
.absent = NULL,
.save_len = save_len_large_times_sd,
.save = save_large_times_sd,
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
.print = print_large_times_sd,
#endif
.alignment = 8
@@ -1137,7 +1137,7 @@
.absent = NULL,
.save_len = save_len_symlink_sd,
.save = save_symlink_sd,
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
.print = print_symlink_sd,
#endif
.alignment = 8
@@ -1155,7 +1155,7 @@
.absent = absent_plugin_sd,
.save_len = save_len_plugin_sd,
.save = save_plugin_sd,
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
.print = NULL,
#endif
.alignment = 8
@@ -1173,7 +1173,7 @@
.absent = NULL,
.save_len = save_len_flags_sd,
.save = save_flags_sd,
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
.print = NULL,
#endif
.alignment = 8
@@ -1191,7 +1191,7 @@
.absent = NULL,
.save_len = save_len_flags_sd,
.save = save_flags_sd,
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
.print = NULL,
#endif
.alignment = 8
@@ -1210,7 +1210,7 @@
/* return IO_ERROR if smthng is wrong */
.save_len = save_len_crypto_sd,
.save = save_crypto_sd,
-#if REISER4_DEBUG_OUTPUT
+#ifdef REISER4_DEBUG_OUTPUT
.print = print_crypto_sd,
#endif
.alignment = 8
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Hi! > Introduce a todo notifier in the task_struct so that a task can be told to do > certain things. Abuse the suspend hooks try_to_freeze, freezing and > refrigerator > to establish checkpoints where the todo list is processed. This will break > software > suspend (next patch fixes and cleans up software suspend). Ugh, this conflicts with stuff in -mm tree rather badly... In part thanks to patch by you that was already applied. I fixed up rejects manually (but probably lost fix or two in progress), and will test. Uff, and then it breaks suspend completely: Jul 28 23:21:12 amd kernel: Stopping tasks: =Restarting tasks...khpsbpkt: received unexpected signal?! Jul 28 23:21:12 amd kernel: NodeMgr: received unexpected signal?! Jul 28 23:21:22 amd kernel: done Jul 28 23:21:32 amd pam_limits[1547]: wrong limit value 'unlimited' (Left me with basically all kernel threads going crazy:) top - 23:22:34 up 3 min, 4 users, load average: 5.10, 1.90, 0.69 Tasks: 48 total, 2 running, 46 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0% us, 100.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 2064480k total, 155664k used, 1908816k free,10280k buffers Swap: 2136448k total,0k used, 2136448k free, 114624k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 273 root 25 0 000 S 21.1 0.0 0:11.24 kswapd0 938 root 25 0 000 S 21.1 0.0 0:11.24 pccardd 940 root 25 0 000 S 21.1 0.0 0:11.30 pccardd 1060 root 25 0 000 R 21.1 0.0 0:21.34 kjournald 1409 root 25 0 000 S 17.3 0.0 0:19.71 kjournald You are doing rather intrusive changes. Is testing them too much to ask? I'm pretty sure you can get i386 machine to test swsusp on... Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: [PATCH] fbdev: colormap fixes
On Thu, 28 Jul 2005, Jon Smirl wrote:
> I've verified now that all ATI R300+ chips have 10bit cmaps. These are
> pretty common so I'd be in favor of making this into a binary
> attribute where I can get/set the whole table at once. Given that
> OpenGL is already supporting 12 and 16 bits these tables are only
> going to get much larger.
>
> 1024 entries * 5 fields * 2 bytes = 10KB -- too big for a text attribute.
>
> 65536 entries * 5 fields * 2 bytes = 655KB -- way too big for a text
> attribute.
>
> The bits_per_pixel sysfs attribute is an easy way to tell how many
> entries you need. You can just set it at 4, 8, 10, etc until you get
> an error. Now you know the max. 2^n and you know how many entries.
No, bits_per_pixel can be (much) larger than the color map size. E.g. a simple
ARGB directcolor mode has bits_per_pixel = 32 and color map size = 256.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
On Thursday, 28 of July 2005 21:16, Andrew Morton wrote: > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > There are two problems with the compilation of arch/x86_64/kernel/nmi.c. > > Thanks. > > > --- linux-2.6.13-rc3-mm3/arch/x86_64/kernel/nmi.c 2005-07-28 > > 21:05:53.0 +0200 > > +++ patched/arch/x86_64/kernel/nmi.c 2005-07-28 18:58:02.0 > > +0200 > > @@ -152,8 +152,10 @@ int __init check_nmi_watchdog (void) > > > > printk(KERN_INFO "testing NMI watchdog ... "); > > > > +#ifdef CONFIG_SMP > > if (nmi_watchdog == NMI_LOCAL_APIC) > > smp_call_function(nmi_cpu_busy, (void *), 0, 0); > > +#endif > > > > for (cpu = 0; cpu < NR_CPUS; cpu++) > > counts[cpu] = cpu_pda[cpu].__nmi_count; > > This bit is no longer needed, since > alpha-fix-statement-with-no-effect-warnings.patch got dropped. OK BTW, -mm3 works fine for me on two AMD64 boxes except for one thing: On Asus L5D, if I resume the box from disk on battery power (ie the box is started on battery power and resumes from disk), it hangs solid right after copying the image (100% of the time). If it is resumed on AC power, everything is fine. Well, -mm1[1-2] did the same thing so I think I'll create a Bugzilla entry and start a binary search. :-( The -git[5-9] kernels are not affected by this issue. Greets, Rafael PS Could you please tell me how I can figure out the order in which the individual patches in -mm have been applied? -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3: swsusp works (TP 600X)
Hi! > >>If I don't eject the pcmcia card (usually a prism54 wireless card), > >>swsusp begins the process of hibernation, but never gets to the > >>writing pages part. > > > Well, it really may be the firmware loading. Add some printks to > > confirm it, then fix it. > > I did more tests, this time with 2.6.13-rc3-mm2 (machine is a TP 600X), > and I don't think the problem is related to firmware loading. If I > first physically eject the card (an Intersil wireless card), swsusp > prints > ... > > then it writes pages to swap and all is well. Well, almost 100%; the > one glitch is that sometimes X comes back blank and I have to > ctrl-alt-F7 to bring back the display; or X comes back with the keyboard > acting strange ( shifts the display left by a few hundred > pixels), and again ctrl-alt-F7 fixes it. This is with XFree86 > 4.3.0.dfsg.1-14, and maybe after I upgrade (?) to the xorg server, that > glitch will go away. Anyway, it's easy to work around. So, in short, problem is that if you leave prism54 card in, even with module removed, swsusp hangs, right? Okay then, start looking into pcmcia layer ;-). Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Task notifier: Implement todo list in task_struct
Hi! > > Introduce a todo notifier in the task_struct so that a task can be told to > > do > > certain things. Abuse the suspend hooks try_to_freeze, freezing and > > refrigerator > > to establish checkpoints where the todo list is processed. This will break > > software > > suspend (next patch fixes and cleans up software suspend). > > Ugh, this conflicts with stuff in -mm tree rather badly... In part > thanks to patch by you that was already applied. > > I fixed up rejects manually (but probably lost fix or two in > progress), and will test. > > Uff, and then it breaks suspend completely: > > Jul 28 23:21:12 amd kernel: Stopping tasks: > =Restarting tasks...khpsbpkt: > received unexpected signal?! > Jul 28 23:21:12 amd kernel: NodeMgr: received unexpected signal?! > Jul 28 23:21:22 amd kernel: done > Jul 28 23:21:32 amd pam_limits[1547]: wrong limit value 'unlimited' > > (Left me with basically all kernel threads going crazy:) > > top - 23:22:34 up 3 min, 4 users, load average: 5.10, 1.90, 0.69 > Tasks: 48 total, 2 running, 46 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.0% us, 100.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, > 0.0% si > Mem: 2064480k total, 155664k used, 1908816k free,10280k > buffers > Swap: 2136448k total,0k used, 2136448k free, 114624k > cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 273 root 25 0 000 S 21.1 0.0 0:11.24 kswapd0 > 938 root 25 0 000 S 21.1 0.0 0:11.24 pccardd > 940 root 25 0 000 S 21.1 0.0 0:11.30 pccardd > 1060 root 25 0 000 R 21.1 0.0 0:21.34 kjournald > 1409 root 25 0 000 S 17.3 0.0 0:19.71 kjournald > > You are doing rather intrusive changes. Is testing them too much to > ask? I'm pretty sure you can get i386 machine to test swsusp on... (And yes, I did apply the whole series. It would be nice if next series was relative to -mm, it already contains some of your changes). Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm3
Hello Andrew, here again I have two problems. With 2.6.13-rc3-mm3 I have problems using my SATA drives on Intel ICH6. The kernel can't route there IRQs or can't discover them. the option irqpoll got them to work now. The problem is new because 2.6.13-rc3[-mm1,mm2] work without any problems. The SATA drives are Samsung HD160JJ SATAII. The mainboard I use is a ASUS P4GPL-X. Second one is about Intel HD-Codec (snd-hda-intel) on modprobe when loading the module it gives me ---> snip hda_codec: Unknown model for ALC880, trying auto-probe from BIOS... Unable to handle kernel NULL pointer dereference at virtual address printing eip: f88713f4 *pde = Oops: 0002 [#1] PREEMPT last sysfs file: Modules linked in: snd_hda_intel snd_hda_codec nvidia CPU:0 EIP:0060:[]Tainted: P VLI EFLAGS: 00010293 (2.6.13-rc3-mm3pm) eax: fffe ebx: f3b33548 ecx: edx: esi: f3b33400 edi: ebp: 0006 esp: f0371ddc ds: 007b es: 007b ss: 0068 Process modprobe (pid: 7398, threadinfo=f037 task=f4183560) Stack: f3b33400 f3b33548 f0f1d000 f8871933 f3b33400 f0f1d000 f8871bbd f8875478 f88748f6 0001 f886d77e 0f00 0005 f0f1d000 f54d04c0 f886d984 0f00 0002 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 31 c0 53 83 ec 10 89 d3 89 e7 f3 ab 8b 12 31 ff 83 fa 00 7e 45 89 f6 0f b7 44 7b 04 8d 48 ec 66 83 f9 03 77 13 8b 56 3c 83 e8 16 <66> 89 04 7a 8b 13 c7 04 8c 01 00 00 00 47 39 fa 7f da 31 ff 83 --> snip I also attached the kernel-config and the lspci -vv output. Thanks again for the patience and the help. Best regards Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
