Re: 2.6.9 & 2.6.10 unresponsive to keyboard upon bootup

[Dmitry Torokhov]

On Saturday 12 February 2005 12:50, Roey Katz wrote:
> Hello again Dmitry,
> 
> is there anything new about this issue? any fixes in the kernel?
> If you want, I can continue doing the test/debug cycle as before.
> 

Hi Roey,

I have been looking over your logs one more time and it looks like
there is a small change in i8042 init sequence that I have overlooked
before.

Could you please tell me if booting with i8042.nomux option helps your
keyboard?

Thanks!

-- 
Dmitry
-
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: [RFC][PATCH] swsusp: do not use higher order allocations on resume [update 2]

[hugang]

On Sun, Feb 13, 2005 at 01:04:56PM +0706, [EMAIL PROTECTED] wrote:
> On Wed, Feb 09, 2005 at 12:22:52AM +0100, Rafael J. Wysocki wrote:
> > On Tuesday, 8 of February 2005 23:42, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > +static inline void eat_page(void *page) {
> > > 
> > > Please put { on new line.
> > 
> > Oh, I still tend to forget about this.  Corrected in the patch that is
> > available on the web
> > (http://www.sisk.pl/kernel/patches/2.6.11-rc3-mm1/swsusp-use-list-resume-v4.patch).
> > 
> > 
> > > Okay, as you can see, I could find very little wrong with this
> > > patch. That hopefully means it is okay ;-). I should still check error
> > > handling, but I guess I'll do it when it is applied because it is hard
> > > to do on a diff. I guess it should go into -mm just after 2.6.11 is
> > > released...
> > 
> > That would be great!
> > 
> > Greets,
> > Rafael
> 
> Here is powerpc port support for that.  Thanks for greate patch.
> 

Sorry I forgot this one. 

--- 2.6.11-rc3-mm2-use-list-resume-v4/arch/ppc/kernel/asm-offsets.c 
2004-12-30 14:55:39.0 +0800
+++ 2.6.11-rc3-mm2-use-list-resume-v4-ppc/arch/ppc/kernel/asm-offsets.c 
2005-02-13 12:30:59.0 +0800
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -136,6 +137,10 @@ main(void)
DEFINE(TI_CPU, offsetof(struct thread_info, cpu));
DEFINE(TI_PREEMPT, offsetof(struct thread_info, preempt_count));
 
+   DEFINE(pbe_address, offsetof(struct pbe, address));
+   DEFINE(pbe_orig_address, offsetof(struct pbe, orig_address));
+   DEFINE(pbe_next, offsetof(struct pbe, next));
+
DEFINE(NUM_USER_SEGMENTS, TASK_SIZE>>28);
return 0;
 }

-- 
Hu Gang   .-.
  /v\
 // \\ 
Linux User  /(   )\  [204016]
GPG Key ID   ^^-^^   http://soulinfo.com/~hugang/hugang.asc
-
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/

Oops with oprofile + RT preempt 2.6.11-rc2-RT-V0.7.37-01

[Lee Revell]

Are there any known incompatibilities with oprofile and the RT preempt patch?

Lee

Oops:  [#1]
PREEMPT 
Modules linked in: realtime commoncap af_packet via_rhine mii crc32 ehci_hcd 
usbhid uhci_hcd usbcore via_
agp agpgart evdev snd_rtctimer snd_emu10k1_synth snd_emu10k1 snd_ac97_codec 
snd_pcm_oss snd_mixer_oss snd_pcm snd_emux_synth snd_seq_virmidi s
nd_seq_midi_emul snd_seq_midi snd_rawmidi snd_seq_oss snd_seq_midi_event 
snd_seq snd_timer snd_seq_device snd_hwdep snd_util_mem snd snd_page_
alloc
CPU:0
EIP:0060:[oprofilefs_str_to_user+21/64]Not tainted VLI
EFLAGS: 00010246   (2.6.11-rc2-RT-V0.7.37-01) 
EIP is at oprofilefs_str_to_user+0x15/0x40
eax:    ebx:    ecx:    edx: 
esi: d593b6a0   edi:    ebp: cb966f6c   esp: cb966f68
ds: 007b   es: 007b   ss: 0068   preempt: 0001
Process cat (pid: 3290, threadinfo=cb966000 task=d083ce10)
Stack: cb966fa8 cb966f90 c01529ec  0804d038 1000 cb966fa8 d593b6a0 
   fff7 0804d038 cb966fbc c0152cc1 d593b6a0 0804d038 1000 cb966fa8 
      0003 1000 cb966000 c01026a4 0003 
Call Trace:
  [show_stack+133/160] show_stack+0x85/0xa0 (32)
  [show_registers+299/400] show_registers+0x12b/0x190 (40)
  [die+219/384] die+0xdb/0x180 (52)
  [do_page_fault+824/1629] do_page_fault+0x338/0x65d (212)
  [error_code+43/48] error_code+0x2b/0x30 (64)
  [vfs_read+188/320] vfs_read+0xbc/0x140 (36)
  [sys_read+65/112] sys_read+0x41/0x70 (44)
  [syscall_call+7/11] syscall_call+0x7/0xb (-4028)
---
| preempt count: 0002 ]
| 2-level deep critical section nesting:

.. [die+56/384]  die+0x38/0x180
.[do_page_fault+824/1629] ..   ( <= do_page_fault+0x338/0x65d)
.. [print_traces+19/80]  print_traces+0x13/0x50
.[show_stack+133/160] ..   ( <= show_stack+0x85/0xa0)

Code: 89 43 44 89 53 48 89 d8 8b 5d fc 89 ec 5d c3 8d b4 26 00 00 00 00 55 89 
e5 57 e8 ab 49 ee ff 8b 55 
08 31 c0 b9 ff ff ff ff 89 d7  ae f7 d1 49 51 52 8b 45 14 8b 7d 10 50 57 8b 
4d 0c 51 e8 73 
  <1>BUG: Unable to handle kernel NULL pointer dereference at virtual address 

  printing eip:
c02284a5
*pde = 

-
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: [RFC][PATCH] swsusp: do not use higher order allocations on resume [update 2]

[hugang]

On Wed, Feb 09, 2005 at 12:22:52AM +0100, Rafael J. Wysocki wrote:
> On Tuesday, 8 of February 2005 23:42, Pavel Machek wrote:
> > Hi!
> > 
> > > +static inline void eat_page(void *page) {
> > 
> > Please put { on new line.
> 
> Oh, I still tend to forget about this.  Corrected in the patch that is
> available on the web
> (http://www.sisk.pl/kernel/patches/2.6.11-rc3-mm1/swsusp-use-list-resume-v4.patch).
> 
> 
> > Okay, as you can see, I could find very little wrong with this
> > patch. That hopefully means it is okay ;-). I should still check error
> > handling, but I guess I'll do it when it is applied because it is hard
> > to do on a diff. I guess it should go into -mm just after 2.6.11 is
> > released...
> 
> That would be great!
> 
> Greets,
> Rafael

Here is powerpc port support for that.  Thanks for greate patch.

--- 2.6.11-rc3-mm2-use-list-resume-v4/arch/ppc/Kconfig  2005-02-13 
12:13:31.0 +0800
+++ 2.6.11-rc3-mm2-use-list-resume-v4-ppc/arch/ppc/Kconfig  2005-02-13 
12:22:32.0 +0800
@@ -1068,6 +1068,8 @@ config PROC_HARDWARE
 
 source "drivers/zorro/Kconfig"
 
+source kernel/power/Kconfig
+
 endmenu
 
 menu "Bus options"
--- 2.6.11-rc3-mm2-use-list-resume-v4/arch/ppc/kernel/Makefile  2005-02-13 
12:13:31.0 +0800
+++ 2.6.11-rc3-mm2-use-list-resume-v4-ppc/arch/ppc/kernel/Makefile  
2005-02-13 12:22:06.0 +0800
@@ -16,6 +16,7 @@ obj-y := entry.o traps.o irq.o idle.o
semaphore.o syscalls.o setup.o \
cputable.o ppc_htab.o perfmon.o
 obj-$(CONFIG_6xx)  += l2cr.o cpu_setup_6xx.o
+obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o
 obj-$(CONFIG_POWER4)   += cpu_setup_power4.o
 obj-$(CONFIG_MODULES)  += module.o ppc_ksyms.o
 obj-$(CONFIG_NOT_COHERENT_CACHE)   += dma-mapping.o
--- 2.6.11-rc3-mm2-use-list-resume-v4/arch/ppc/kernel/signal.c  2005-02-13 
12:11:50.0 +0800
+++ 2.6.11-rc3-mm2-use-list-resume-v4-ppc/arch/ppc/kernel/signal.c  
2005-02-13 12:22:06.0 +0800
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -704,6 +705,14 @@ int do_signal(sigset_t *oldset, struct p
unsigned long frame, newsp;
int signr, ret;
 
+   if (current->flags & PF_FREEZE) {
+   refrigerator(PF_FREEZE);
+   signr = 0;
+   ret = regs->gpr[3];
+   if (!signal_pending(current))
+   goto no_signal;
+   }
+
if (!oldset)
oldset = >blocked;
 
@@ -726,6 +735,7 @@ int do_signal(sigset_t *oldset, struct p
regs->gpr[3] = EINTR;
/* note that the cr0.SO bit is already set */
} else {
+no_signal:
regs->nip -= 4; /* Back up & retry system call */
regs->result = 0;
regs->trap = 0;
--- /dev/null   2004-06-07 18:45:47.0 +0800
+++ 2.6.11-rc3-mm2-use-list-resume-v4-ppc/arch/ppc/kernel/swsusp.S  
1904-01-01 00:05:22.0 +0706
@@ -0,0 +1,349 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+/*
+ * Structure for storing CPU registers on the save area.
+ */
+#define SL_SP  0
+#define SL_PC  4
+#define SL_MSR 8
+#define SL_SDR10xc
+#define SL_SPRG0   0x10/* 4 sprg's */
+#define SL_DBAT0   0x20
+#define SL_IBAT0   0x28
+#define SL_DBAT1   0x30
+#define SL_IBAT1   0x38
+#define SL_DBAT2   0x40
+#define SL_IBAT2   0x48
+#define SL_DBAT3   0x50
+#define SL_IBAT3   0x58
+#define SL_TB  0x60
+#define SL_R2  0x68
+#define SL_CR  0x6c
+#define SL_LR  0x70
+#define SL_R12 0x74/* r12 to r31 */
+#define SL_SIZE(SL_R12 + 80)
+
+   .section .data
+   .align  5
+
+_GLOBAL(swsusp_save_area)
+   .space  SL_SIZE
+
+
+   .section .text
+   .align  5
+
+_GLOBAL(swsusp_arch_suspend)
+
+   lis r11,[EMAIL PROTECTED]
+   ori r11,r11,[EMAIL PROTECTED]
+
+   mflrr0
+   stw r0,SL_LR(r11)
+   mfcrr0
+   stw r0,SL_CR(r11)
+   stw r1,SL_SP(r11)
+   stw r2,SL_R2(r11)
+   stmwr12,SL_R12(r11)
+
+   /* Save MSR & SDR1 */
+   mfmsr   r4
+   stw r4,SL_MSR(r11)
+   mfsdr1  r4
+   stw r4,SL_SDR1(r11)
+
+   /* Get a stable timebase and save it */
+1: mftbu   r4
+   stw r4,SL_TB(r11)
+   mftbr5
+   stw r5,SL_TB+4(r11)
+   mftbu   r3
+   cmpwr3,r4
+   bne 1b
+
+   /* Save SPRGs */
+   mfsprg  r4,0
+   stw r4,SL_SPRG0(r11)
+   mfsprg  r4,1
+   stw r4,SL_SPRG0+4(r11)
+   mfsprg  r4,2
+   stw r4,SL_SPRG0+8(r11)
+   mfsprg  r4,3
+   stw r4,SL_SPRG0+12(r11)
+
+   /* Save BATs */
+   mfdbatu 

Re: memset argument order misuses

[Andrew Morton]

Joe Korty <[EMAIL PROTECTED]> wrote:
>
> Hi Andrew,
> A simple 'grep memset.*\<0);' shows argument order errors in several uses
> of memset.
> 
> This grep was inspired by Al Viro's recent patch, megaraid_mbox fix,
> which fixed this problem in the megaraid driver.
> 

heh.  Lsydexic s/390 developers.  Thanks, I guess we should scoot this into
2.6.11.


> 
> Regards,
> Joe
> --
> "Money can buy bandwidth, but latency is forever" -- John Mashey
> 
> 
> 
> diff -Nura base/drivers/s390/block/dasd_genhd.c 
> new/drivers/s390/block/dasd_genhd.c
> --- base/drivers/s390/block/dasd_genhd.c  2004-12-24 16:35:24.0 
> -0500
> +++ new/drivers/s390/block/dasd_genhd.c   2005-02-12 21:55:48.546192009 
> -0500
> @@ -149,8 +149,8 @@
>* Can't call delete_partitions directly. Use ioctl.
>* The ioctl also does locking and invalidation.
>*/
> - memset(, sizeof(struct blkpg_partition), 0);
> - memset(, sizeof(struct blkpg_ioctl_arg), 0);
> + memset(, 0, sizeof(struct blkpg_partition));
> + memset(, 0, sizeof(struct blkpg_ioctl_arg));
>   barg.data = 
>   barg.op = BLKPG_DEL_PARTITION;
>   for (bpart.pno = device->gdp->minors - 1; bpart.pno > 0; bpart.pno--)
> diff -Nura base/drivers/s390/cio/cmf.c new/drivers/s390/cio/cmf.c
> --- base/drivers/s390/cio/cmf.c   2004-12-24 16:33:48.0 -0500
> +++ new/drivers/s390/cio/cmf.c2005-02-12 21:56:08.430256458 -0500
> @@ -526,7 +526,7 @@
>   time = get_clock() - cdev->private->cmb_start_time;
>   spin_unlock_irqrestore(cdev->ccwlock, flags);
>  
> - memset(data, sizeof(struct cmbdata), 0);
> + memset(data, 0, sizeof(struct cmbdata));
>  
>   /* we only know values before device_busy_time */
>   data->size = offsetof(struct cmbdata, device_busy_time);
> @@ -736,7 +736,7 @@
>   time = get_clock() - cdev->private->cmb_start_time;
>   spin_unlock_irqrestore(cdev->ccwlock, flags);
>  
> - memset (data, sizeof(struct cmbdata), 0);
> + memset (data, 0, sizeof(struct cmbdata));
>  
>   /* we only know values before device_busy_time */
>   data->size = offsetof(struct cmbdata, device_busy_time);
> diff -Nura base/drivers/s390/cio/css.c new/drivers/s390/cio/css.c
> --- base/drivers/s390/cio/css.c   2005-02-12 21:51:28.0 -0500
> +++ new/drivers/s390/cio/css.c2005-02-12 21:56:20.066538550 -0500
> @@ -527,7 +527,7 @@
>   new_slow_sch = kmalloc(sizeof(struct slow_subchannel), GFP_ATOMIC);
>   if (!new_slow_sch)
>   return -ENOMEM;
> - memset(new_slow_sch, sizeof(struct slow_subchannel), 0);
> + memset(new_slow_sch, 0, sizeof(struct slow_subchannel));
>   new_slow_sch->schid = schid;
>   spin_lock_irqsave(_subchannel_lock, flags);
>   list_add_tail(_slow_sch->slow_list, _subchannels_head);
-
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/

HIGHMEM slows down 2.6.11-rc3-bk7 machine

[Martin MOKREJŠ]

Hi Marcello and other gurus!
 I have just bough 4GB of RAM into my machine. Immediately, I have noticed
the machine is terribly slow on bootup. After inspecting all BIOS related
possibilities I found that the problem goes off with highmem=off. I should
note I don't see this slowdown when I have only 2 or 3GB RAM while using the
same kernel.
 The MB is ASUS P4C800-E-Deluxe with i875P chipset and ICH5R. It should
support fully 4GB, but docs say ICH5R controller might allocate something
for itself, so one should expect "less". :(
Hmm, at the best I get 3557MB of RAM when almost everything is
disabled in BIOS, mainly USB/NET/FIREWIRE/SATA stuff. Grrr.
I tested latest beta and release of bios too, but no luck.
root=/dev/sdb2 ide=reverse agp=try_unsupported console=ttyS0,57600n8 
console=tty0 vga=792 idebus=66 highmem=off
$ cat /proc/mtrr
reg00: base=0x (   0MB), size=2048MB: write-back, count=1
reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xd000 (3328MB), size= 128MB: write-back, count=1
reg04: base=0xd800 (3456MB), size=  64MB: write-back, count=1
reg05: base=0xdc00 (3520MB), size=  32MB: write-back, count=1
reg06: base=0xf000 (3840MB), size= 128MB: write-combining, count=2
reg07: base=0xfe80 (4072MB), size=   4MB: write-combining, count=1
$
$ cat /mtrr-with-highmem 
reg00: base=0x (   0MB), size=2048MB: write-back, count=1
reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xd000 (3328MB), size= 128MB: write-back, count=1
reg04: base=0xd800 (3456MB), size=  64MB: write-back, count=1
reg05: base=0xdc00 (3520MB), size=  32MB: write-back, count=1
reg06: base=0xf000 (3840MB), size= 128MB: write-combining, count=2
reg07: base=0xfe80 (4072MB), size=   4MB: write-combining, count=1
$

Please not that at the moment, BIOS says only 3555MB are available, so am
a bit surprised linux sees anything above 3456MB (expect that to be somehow 
used by the ICH5R beast).
see attached dmesg 2.6.11-rc3-bk7 for the cases when no highmem was/wasn't 
enabled
Here is the diff of both:
--- /dm 2005-02-13 05:27:12.328500335 +0100
+++ /dm-with-highmem2005-02-13 05:44:13.106978275 +0100
@@ -8,13 +8,13 @@
 BIOS-e820: de24 - de2f (ACPI NVS)
 BIOS-e820: de2f - de30 (reserved)
 BIOS-e820: ffb8 - 0001 (reserved)
-0MB HIGHMEM available.
+2658MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000ff780
-On node 0 totalpages: 229376
+On node 0 totalpages: 909872
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 225280 pages, LIFO batch:16
-  HighMem zone: 0 pages, LIFO batch:1
+  HighMem zone: 680496 pages, LIFO batch:16
DMI 2.3 present.
ACPI: RSDP (v002 ACPIAM) @ 0x000f9e30
ACPI: XSDT (v001 A M I  OEMXSDT  0x1426 MSFT 0x0097) @ 0xde230100
@@ -37,19 +37,19 @@
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Built 1 zonelists
-Kernel command line: root=/dev/sda2 ide=reverse agp=try_unsupported 
console=ttyS0,57600n8 console=tty0 vga=792 idebus=66 highmem=off
+Kernel command line: root=/dev/sda2 ide=reverse agp=try_unsupported 
console=ttyS0,57600n8 console=tty0 vga=792 idebus=66
ide_setup: ide=reverse : Enabled support for IDE inverse scan order.
ide_setup: idebus=66
mapped APIC to d000 (fee0)
mapped IOAPIC to c000 (fec0)
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
-Detected 3075.740 MHz processor.
+Detected 3075.443 MHz processor.
Using pmtmr for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
-Memory: 902348k/917504k available (3380k kernel code, 14644k reserved, 1649k 
data, 224k init, 0k highmem)
+Memory: 3602700k/3639488k available (3380k kernel code, 35972k reserved, 1649k 
data, 224k init, 2721984k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 6094.84 BogoMIPS (lpj=3047424)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
@@ -130,6 +130,7 @@
pnp: 00:07: ioport range 0x290-0x297 has been reserved
Machine check exception polling timer started.
IA-32 Microcode Update Driver: v1.14 <[EMAIL PROTECTED]>
+highmem bounce pool size: 64 pages
devfs: 2004-01-31 Richard Gooch ([EMAIL PROTECTED])
devfs: boot_options: 0x1
SGI XFS with no debug enabled
@@ -257,15 +258,15 @@
ACPI: PCI interrupt :00:1f.5[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device :00:1f.5 to 64
AC'97 0 analog subsections not ready
-intel8x0_measure_ac97_clock: measured 49507 usecs
+intel8x0_measure_ac97_clock: measured 50508 usecs
intel8x0: clocking to 48000
ALSA device list:
  

Re: [RFC UPDATE PATCH] add wait_event_*_lock() functions and comments

[Nish Aravamudan]

On Sun, 13 Feb 2005 03:41:01 +0100, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> On Sünnavend 12 Februar 2005 14:28, Sergey Vlasov wrote:
> > On Sat, 12 Feb 2005 12:38:26 +0100 Arnd Bergmann wrote:
> > > #define __wait_event_lock(wq, condition, lock, flags)  \
> > > do {   \
> > >DEFINE_WAIT(__wait);\
> > >\
> > >for (;;) {  \
> > >prepare_to_wait(, &__wait, TASK_UNINTERRUPTIBLE);\
> > >spin_lock_irqsave(lock, flags); \
> > >if (condition)  \
> > >break;  \
> > >spin_unlock_irqrestore(lock, flags);\
> > >schedule(); \
> > >}   \
> > >spin_unlock_irqrestore(lock, flags);\
> > >finish_wait(, &__wait);  \
> > > } while (0)
> >
> > But in this case the result of testing the condition becomes useless
> > after spin_unlock_irqrestore - someone might grab the lock and change
> > things.   Therefore the calling code would need to add a loop around
> > wait_event_lock - and the wait_event_* macros were added precisely to
> > encapsulate such a loop and avoid the need to code it manually.
> 
> Ok, i understand now what the patch really wants to achieve. However,
> I'm not convinced it's a good idea. In the usb/gadget/serial.c driver,
> this appears to work only because an unconventional locking scheme is
> used, i.e. there is an extra flag (port->port_in_use) that is set to
> tell other functions about the state of the lock in case the lock holder
> wants to sleep.
> 
> Is there any place in the kernel that would benefit of the
> wait_event_lock() macro family while using locks without such
> special magic?

Sorry for replying from a different account, but it's the best I can
do right now. I know while I was scanning the whole kernel for other
wait_event*() replacements, I thought at least a handful of times,
"ugh, I could replace this whole block of code, except for that lock!"
I will try to get you a more concrete example on Monday. Thanks for
the feedback & patience!

-Nish
-
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] radeonfb: typos fixes

[Benjamin Herrenschmidt]

Hi !

The dynamic clock code in radeonfb comes almost as-is from X.org (where
it was contributed by ATI). It has a few typos (wrong register access
macros) that this patch fixes.

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

Index: linux-work/drivers/video/aty/radeon_pm.c
===
--- linux-work.orig/drivers/video/aty/radeon_pm.c   2005-02-13 
23:18:52.0 +1100
+++ linux-work/drivers/video/aty/radeon_pm.c2005-02-13 15:01:11.005138528 
+1100
@@ -180,7 +180,7 @@
tmp = INPLL(pllMCLK_CNTL);
tmp &= ~(MCLK_CNTL__FORCE_MCLKA |
 MCLK_CNTL__FORCE_YCLKA);
-   OUTREG(pllMCLK_CNTL, tmp);
+   OUTPLL(pllMCLK_CNTL, tmp);
radeon_msleep(16);
}
/* Hrm... same shit, X doesn't do that but I have to */
@@ -404,7 +404,7 @@
((INREG(CONFIG_CNTL) & CFG_ATI_REV_ID_MASK) < CFG_ATI_REV_A13)) {
tmp = INPLL(pllPLL_PWRMGT_CNTL);
tmp |= PLL_PWRMGT_CNTL__TCL_BYPASS_DISABLE;
-   OUTREG(pllPLL_PWRMGT_CNTL, tmp);
+   OUTPLL(pllPLL_PWRMGT_CNTL, tmp);
radeon_msleep(15);
}
 



-
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/

Strange /dev/mem behaviour on IA32, PPC64, (others?)

[Ryan Lortie]

There are a couple of problems that I have encountered with /dev/mem on
the 2.6.10 kernel.

The first problem is that lseek()/read() results in different data than
mmap() and reading from the mapped memory area.  I've written a small
program to demonstrate the problem.  I am fairly sure it is correct (a
few others haved looked over it).  The program produces unexpected
output when I run it on both IA32 and PPC64.  You need to have at least
1GB of RAM to run it, but it is easy to modify if you have less.

In short, lseek()/read() returns what I believe to be the correct
values.  Reading from the mmap() region gives the correct values for the
first few reads but after that it starts giving zeros.

In testing this program on IA32 I ran into an additional problem.  If
you lseek() to the (very suspicious) 896MB mark and read() then read
gives EFAULT (Bad address).

I have high memory support enabled and the 'free' command reports:

 total
Mem:   1036172

so seeking should be OK all the way up to 1GB.

Any information about these problems (including "you're wrong
because") is appreciated.  I'm not on the list, so please Cc:
replies.

Cheers.
#include 
#include 
#include 
#include 
#include 

int main( void )
{
  char *ptr;
  int fd;
  long i;
  char z;

  fd = open( "/dev/mem", O_RDONLY, 0666 );

  if( fd < 0 )
  {
perror( "open /dev/mem" );
exit( 1 );
  }

  /* map in 1G worth of physical RAM */
  ptr = mmap( NULL, 0x4000L, PROT_READ, MAP_SHARED, fd, 0 );

  if( ptr == (void *) -1 )
  {
perror( "mmap" );
exit( 1 );
  }

  /* print out memory at 8 meg intervals.  8M * 128 = 1024M */
  for( i = 0; i < 128; i++ )
  {
/* -> for mmap */
printf( "%02lx -> %x\n", i, ptr[8 * 1024 * 1024 * i] );

/* => for lseek/read */
if( lseek( fd, 8 * 1024 * 1024 * i, SEEK_SET ) < 0 )
{
  perror( "lseek" );
  exit( 1 );
}

if( read( fd, , 1 ) != 1 )
{
  perror( "read" );
  exit( 1 );
}

printf( "%02lx => %x\n", i, z );
  }

  return 0;
}

Linux 2.6.11-rc4

[Linus Torvalds]

Hi there everybody,
 this is hopefully the last -rc kernel before the real 2.6.11, so please 
give it a whirl, and complain loudly about anything broken.

As can be seen from the shortlog, most of the changes are pretty trivial. 
I think the biggest change is the radeon updates, and some of the NLS 
codepage things caused big diffs even if the changes themselves are pretty 
trivial (oh, and moving the ia64 "shubio.h" file accounts for about seven 
thousand lines of diffs, but no real changes ;)

In short: some driver updates, some arm/uml/sparc updates, and various 
random (mostly) one-liners all over. The most noticeable of the one-liners 
is hopefully that raid5/6 should work again.

Linus


Summary of changes from v2.6.11-rc3 to v2.6.11-rc4


Adrian Bunk:
  o [ide] remove WAIT_READY dependency on APM
  o [ide] possible cleanups
  o [CRYPTO]: Make some code static in i386 crypto AES
  o [XFRM]: Kill xfrm_export.c
  o mark the mcd cdrom driver as BROKEN

Alan Cox:
  o more fixes for the Moxa driver

Alan Stern:
  o USB: Fix EHCI boot oops on AMD
  o USB: unusual_devs.h update

Alasdair G. Kergon:
  o device-mapper: stripe_width should be sector_t
  o device-mapper: Fixes for 64-bit sector_t

Albert Lee:
  o [libata] SCSI-to-ATA translation fixes

Alex Yustasov:
  o Add missing configure calls to intel agp resume code

Alexander Viro:
  o sparc64: fix compile with strict mm types
  o via82cxxx: fix ppc32 multiplatform config test
  o [ide] fix ide_dump_atapi_status()
  o [SPARC32]: Fix UP build with spinlock debugging enabled
  o [SPARC]: Trivial annotations in sparc signal.c / svr4.h
  o [SPARC]: NULL noise removal from sparc floppy.h
  o [SPARC64]: Fix prototype of check_signature() - it already gets a
pointer
  o [SPARC64]: fbio.h __user annotations
  o [SPARC]: __user annotations around sparc{32,64} ptrace
...succ_return...()
  o [SPARC]: __user annotations in sparc checksum.h
  o [SPARC]: No iBCS2 on sparc, TYVM
  o [SPARC]: Fix I/O accessor routines
  o [SPARC]: __user annotations in ELF_CORE_COPY_REGS
  o [SPARC64]: NULL noise removal in arch/sparc64/prom/memory.c
  o [SPARC]: sunlance iomem annotations
  o portability problem in dm-stripe.c
  o i2c compat ioctl breakage
  o megaraid_mbox fix

Andi Kleen:
  o x86-64: CONFIG_PM=n build fix
  o Fix compat shmget overflow
  o Force read implies exec for all 32bit processes in x86-64
  o Fix small vmalloc per allocation limit

Andreas Gruenbacher:
  o Long-standing xattr sharing bug

Andreas Herrmann:
  o zfcp: bugfixes (without kfree) for -bk

Andrei Konovalov:
  o ppc32: fix typos in cpm_uart_cpm2.c

Andres Salomon:
  o cpufreq_resume() fix

Andrew Chew:
  o sata_nv: enable generic class support for future NVIDIA SATA

Andrew Morton:
  o pnpacpi build fix
  o nfsd needs exportfs

Andrew Vasquez:
  o qlogic nonatomic warning fix
  o qla2xxx: fix BUG's for smp_processor_id() on interrupt

Andries E. Brouwer:
  o nls_cp936.c is not synchronized with M$'s translation table

Anton Blanchard:
  o Use MM_VM_SIZE in exit_mmap

Arjan van de Ven:
  o [ide] unexport atapi_*_bytes() and ide_read_24()

Armin Schindler:
  o Eicon driver: convert to pci_register_driver
  o Eicon driver: code cleanups
  o Eicon driver: remove ^M characters from xdi_vers.h

Arnd Bergmann:
  o SERIAL_TXX9 fix

Art Haas:
  o [SPARC32]: Fix SPIN_LOCK_UNLOCKED define

Ashok Raj:
  o [IA64] mca.c: make cpu hot add work again

Aurelien Jarno:
  o I2C: Fix DS1621 detection

Bartlomiej Zolnierkiewicz:
  o [ide] fix it8172 build for real
  o [ide] fix printk in ide_allocate_dma_engine()
  o [ide pci generic] remove dead unknown_chipset[] table from
generic.h
  o [ide pci generic] remove dummy init_chipset_generic()
  o [ide hpt366] remove dead fifty_base_hpt374[] table
  o [ide piix] remove useless comment

Ben Dooks:
  o [ARM PATCH] 2462/1: IXP2000 - fixes for warnings from io.h
  o [ARM PATCH] 2454/1: cleanup shark_defconfig
  o [ARM PATCH] 2455/1: shark: fix uninitialised variable in head
  o [ARM PATCH] 2468/1: S3C2440 - GPIOJ12 register fix
  o [ARM PATCH] 2471/1: S3C2440 - fix S3C2440_CAMDIVN register address

Benjamin Herrenschmidt:
  o Add try_acquire_console_sem
  o update aty128fb sleep/wakeup code for new powermac changes
  o radeonfb update

Bob Breuer:
  o [SPARC]: Fix crashing of cg14 driver when serial console and vsimm
installed
  o [CG3]: FB mmap .voff and .poff were reversed

Bodo Stroesser:
  o uml: disallow stack access below $esp like i386 / x86_64
  o uml: use PTRACE_OLDSETOPTIONS instead of PTRACE_SETOPTIONS

Brett Russ:
  o [libata scsi] verify cmd bug fixes/support

Brian King:
  o pci: Add Citrine quirk

Chas Williams:
  o [ATM]: [horizon] replace interruptible_sleep_on() with
wait_event_interruptible()
  o [ATM]: [iphase] remove sleep_on*() usage
  o [ATM]: [zatm] replace sleep_on() with wait_event()

Christian Bornträger:
  o s390: core changes
  o s390: cpcmd interface

Christoph 

memset argument order misuses

[Joe Korty]

Hi Andrew,
A simple 'grep memset.*\<0);' shows argument order errors in several uses
of memset.

This grep was inspired by Al Viro's recent patch, megaraid_mbox fix,
which fixed this problem in the megaraid driver.

Completely untested.

Regards,
Joe
--
"Money can buy bandwidth, but latency is forever" -- John Mashey



diff -Nura base/drivers/s390/block/dasd_genhd.c 
new/drivers/s390/block/dasd_genhd.c
--- base/drivers/s390/block/dasd_genhd.c2004-12-24 16:35:24.0 
-0500
+++ new/drivers/s390/block/dasd_genhd.c 2005-02-12 21:55:48.546192009 -0500
@@ -149,8 +149,8 @@
 * Can't call delete_partitions directly. Use ioctl.
 * The ioctl also does locking and invalidation.
 */
-   memset(, sizeof(struct blkpg_partition), 0);
-   memset(, sizeof(struct blkpg_ioctl_arg), 0);
+   memset(, 0, sizeof(struct blkpg_partition));
+   memset(, 0, sizeof(struct blkpg_ioctl_arg));
barg.data = 
barg.op = BLKPG_DEL_PARTITION;
for (bpart.pno = device->gdp->minors - 1; bpart.pno > 0; bpart.pno--)
diff -Nura base/drivers/s390/cio/cmf.c new/drivers/s390/cio/cmf.c
--- base/drivers/s390/cio/cmf.c 2004-12-24 16:33:48.0 -0500
+++ new/drivers/s390/cio/cmf.c  2005-02-12 21:56:08.430256458 -0500
@@ -526,7 +526,7 @@
time = get_clock() - cdev->private->cmb_start_time;
spin_unlock_irqrestore(cdev->ccwlock, flags);
 
-   memset(data, sizeof(struct cmbdata), 0);
+   memset(data, 0, sizeof(struct cmbdata));
 
/* we only know values before device_busy_time */
data->size = offsetof(struct cmbdata, device_busy_time);
@@ -736,7 +736,7 @@
time = get_clock() - cdev->private->cmb_start_time;
spin_unlock_irqrestore(cdev->ccwlock, flags);
 
-   memset (data, sizeof(struct cmbdata), 0);
+   memset (data, 0, sizeof(struct cmbdata));
 
/* we only know values before device_busy_time */
data->size = offsetof(struct cmbdata, device_busy_time);
diff -Nura base/drivers/s390/cio/css.c new/drivers/s390/cio/css.c
--- base/drivers/s390/cio/css.c 2005-02-12 21:51:28.0 -0500
+++ new/drivers/s390/cio/css.c  2005-02-12 21:56:20.066538550 -0500
@@ -527,7 +527,7 @@
new_slow_sch = kmalloc(sizeof(struct slow_subchannel), GFP_ATOMIC);
if (!new_slow_sch)
return -ENOMEM;
-   memset(new_slow_sch, sizeof(struct slow_subchannel), 0);
+   memset(new_slow_sch, 0, sizeof(struct slow_subchannel));
new_slow_sch->schid = schid;
spin_lock_irqsave(_subchannel_lock, flags);
list_add_tail(_slow_sch->slow_list, _subchannels_head);
-
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] correctly name the Shell sort

[Daniel Dickman]

As per http://www.nist.gov/dads/HTML/shellsort.html, this should be referred to
as a Shell sort. Shell-Metzner is a misnomer.

Signed-off-by: Daniel Dickman <[EMAIL PROTECTED]>

--- linux-2.6.11-rc3-bk9/kernel/sys.c   2005-02-12 22:17:26.801294776 -0500
+++ linux/kernel/sys.c  2005-02-12 17:53:15.0 -0500
@@ -1192,7 +1192,7 @@
return 0;
 }

-/* a simple shell-metzner sort */
+/* a simple Shell sort */
 static void groups_sort(struct group_info *group_info)
 {
int base, max, stride;

-
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: [RFC UPDATE PATCH] add wait_event_*_lock() functions and comments

[Arnd Bergmann]

On Sünnavend 12 Februar 2005 14:28, Sergey Vlasov wrote:
> On Sat, 12 Feb 2005 12:38:26 +0100 Arnd Bergmann wrote:
> > #define __wait_event_lock(wq, condition, lock, flags)  \
> > do {   \
> >DEFINE_WAIT(__wait);\
> >\
> >for (;;) {  \
> >prepare_to_wait(, &__wait, TASK_UNINTERRUPTIBLE);\
> >spin_lock_irqsave(lock, flags); \
> >if (condition)  \
> >break;  \
> >spin_unlock_irqrestore(lock, flags);\
> >schedule(); \
> >}   \
> >spin_unlock_irqrestore(lock, flags);\
> >finish_wait(, &__wait);  \
> > } while (0)
> 
> But in this case the result of testing the condition becomes useless
> after spin_unlock_irqrestore - someone might grab the lock and change
> things.   Therefore the calling code would need to add a loop around
> wait_event_lock - and the wait_event_* macros were added precisely to
> encapsulate such a loop and avoid the need to code it manually.

Ok, i understand now what the patch really wants to achieve. However,
I'm not convinced it's a good idea. In the usb/gadget/serial.c driver,
this appears to work only because an unconventional locking scheme is
used, i.e. there is an extra flag (port->port_in_use) that is set to
tell other functions about the state of the lock in case the lock holder
wants to sleep.

Is there any place in the kernel that would benefit of the 
wait_event_lock() macro family while using locks without such
special magic?

Arnd <><


pgpmu9Llaz14L.pgp
Description: signature

Re: how to make a contribution

[Lee Revell]

On Sat, 2005-02-12 at 22:49 +0100, sylvanino b wrote:
> I would like to share this tool if somebody is interested, but I dont
> know how to proceed, I mean how to make a contribution an efficient
> way. Any help/idea/information is welcome.
> 

Put the patch on the web somewhere and post the URL to LKML.

If anyone criticizes you who clearly doesn't understand the issues at
hand, ignore them: if you have a patch that solves a real problem you
will eventually be vindicated.

Lee

-
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: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

[William Park]

On Sat, Feb 12, 2005 at 09:50:43PM -0200, Rog?rio Brito wrote:
> On Feb 12 2005, William Park wrote:
> > This looks awefully like 'acpi' is on.  If 'acpi=noirq' does not work,
> > then try 'pci=noacpi'.
> 
> Hi, Willian.
> 
> First of all, thank you very much for both your attention and help.
> 
> Unfortunately, I have already tried booting the 2.6.11-rc3-mm2 that I just
> compiled and I tried using many boot parameters like "acpi=noirq",
> "irqpoll", "pci=noacpi", "acpi=off" and setting the BIOS of my motherboard
> to "Plug'n'Play OS = Yes" (instead of "Off", which is my default).
> 
> To prevent the matters of loosing track of what is being done, I only
> changed one option at a time. I put the dmesg logs of all my attempts at
> .
> 
> Please let me know if I can provide any other useful information.

Your 'dmesg' says
Warning: Secondary channel requires an 80-pin cable for operation.
I assume it is.

Do you have MSI on by any chance?  (CONFIG_PCI_MSI)  If so, try kernel
without it.  My motherboard exhibits runaway IRQ with it.

-- 
William Park <[EMAIL PROTECTED]>, Toronto, Canada
Slackware Linux -- because I can type.
-
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] OpenBSD Networking-related randomization port

[linux]

linux> It's easy to make a smaller hash by just thowing bits away,
linux> but a block cipher is a permutation, and has to be
linux> invertible.

linux> For example, if I take a k-bit counter and encrypt it with
linux> a k-bit block cipher, the output is guaranteed not to
linux> repeat in less than 2^k steps, but the value after a given
linux> value is hard to predict.

> Huh?  What if my cipher consists of XOR-ing with a k-bit pattern?
> That's a permutation on the set of k-bit blocks but it happens to
> decompose as a product of (non-overlapping) swaps.
> 
> In general for more realistic block ciphers like DES it seems
> extremely unlikely that the cipher has only a single orbit when viewed
> as a permutation.  I would expect a real block cipher to behave more
> like a random permutation, which means that the expected number of
> orbits for a k-bit cipher should be about ln(2^k) or roughly .7 * k.

I think you misunderstand; your comments don't seem to make sense unless
I assume you're imagining output feedback mode:

x[0] = encrypt(IV)
x[1] = encrypt(x[0])
x[2] = encrypt(x[1])
etc.

Obviously, this pattern will repeat after some unpredictable interval.
(However, owing to the invertibility of encryption, looping can
be easily detected by noticing that x[i] = IV.)

But I was talking about counter mode:

x[0] = encrypt(0)
x[1] = encrypt(1)
x[2] = encrypt(2)
etc.

It should be obvious that this will not repeat until the counter
overflows k bits and you try to compute encrypt(2^k) = encrypt(0).

One easy way to generate unpredictable 16-bit port numbers that don't
repeat too fast is:

highbit = 0;
for (;;) {
generate_random_encryption_key(key);
for (i = 0; i < 2; i++)
use(highbit | encrypt15(i, key));
highbit ^= 0x8000;
}

Note that this does NOT use all 32K values before switching to another
key; if that were the case, an attacker who kept a big bitmap of reviously
seen values could preduct the last few values based on knowing what
hadn't been seen already.


Of course, you can always wrap a layer of Knuth's Algorithm B
(randomization by shuffling) around anything:

#include "basic_rng.h"

#define SHUFFLE_SIZE 32 /* Power of 2 is more efficient */

struct better_rng_state {
struct basic_rng_state basic;
unsigned y;
unsigned z[SHUFFLE_SIZE];
};

void
better_rng_seed(struct better_rng_state *state, unsigned seed)
{
unsigned i;
basic_rng_seed(>basic, seed);

for (i = 0; i < SHUFFLE_SIZE; i++)
state->z[i] = basic_rng(>basic);
state->y = basic_rng(>basic) % SHUFFLE_SIZE;
}

unsigned
better_rng(struct better_rng_state *state)
{
unsigned x = state->z[state->y];
state->y = (state->z = basic_rng(>basic)) % SHUFFLE_SIZE;
return x;
}

(You can reduce code size by reducing modulo SHUFFLE_SIZE when you use
state->y rather than when storing into it, but I have done it the other
way to make clear exactly how much "effective" state is stored.  You can
also just initialize state->y to a fixed value.)
-
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.11-rc3-bk9 (radeon) hangs hard my laptop

[Benjamin Herrenschmidt]

On Sun, 2005-02-13 at 02:05 +0100, Alessandro Suardi wrote:

> Commenting out pllCLK_PWRMGT_CNTL alone -> still hangs
> Commenting out pllCLK_PIN_CNTL in addition -> works
>  
> Do you want me to build a kernel with only the pllCLK_PIN_CNTL
>  instruction commented out or is this enough info ?

You mean you commented out the OUTPLL call ? Ok, what if
you only change pllCLK_PIN_CNTL? Also, try not changing it, but
commenting out some other bits ? (I'm especially the bits that touch
SCLK_CNTL). Sorry for all those tests, but I need to point more
precisely where the problem comes from...

Ben.


-
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-mm] kgdb documentation fix

[Matthias Urlichs]

Hi,

Please apply.

--- 

Update Documentation/i386/kgdb/gdbinit-modules to conform
to the current kernel's module data structure.

Signed-Off-By: Matthias Urlichs <[EMAIL PROTECTED]>

--- 

= Documentation/i386/kgdb/gdbinit-modules 1.1 vs edited =
--- 1.1/Documentation/i386/kgdb/gdbinit-modules 2005-02-12 12:44:54 +01:00
+++ edited/Documentation/i386/kgdb/gdbinit-modules  2005-02-12 20:12:45 
+01:00
@@ -60,87 +60,90 @@
 # $mod is set to NULL.  This ensure to not add symbols for a wrong
 # address.
 #
+# 
+# Sat Feb 12 20:05:47 CET 2005
+#
+# Adapted to the 2.6.* module data structure.
+# (Getting miffed at gdb for not having "offsetof" in the process :-/ )
+# 
+# Autogenerate add-symbol-file statements from the module list instead
+# of relying on a no-longer-working loadmodule.sh program.
+# 
+#   Matthias Urlichs <[EMAIL PROTECTED]>
+#
+#
 # Have a nice hacking day !
 #
 #
 define mod-list
-set $mod = (struct module*)module_list
-# the last module is the kernel, ignore it
-while $mod != _module
-   printf "%p\t%s\n", (long)$mod, ($mod)->name
-   set $mod = $mod->next
+set $lmod = modules->next
+# This is a circular data structure
+while $lmod != 
+   set $mod = (struct module *)(((char *)$lmod) - ((int)&(((struct 
module *)0) -> list)))
+printf "%p\t%s\n", $mod, $mod->name
+   set $lmod = $lmod->next
 end
 end
 document mod-list
+mod-list
 List all modules in the form:  
 Use the  as the argument for the other
 mod-commands: mod-print-symbols, mod-add-symbols.
 end
 
+define mod-list-syms
+set $lmod = modules->next
+# This is a circular data structure
+while $lmod != 
+   set $mod = (struct module *)(((char *)$lmod) - ((int)&(((struct 
module *)0) -> list)))
+printf "add-symbol-file %s.ko %p\n", $mod->name, $mod->module_core
+   set $lmod = $lmod->next
+end
+end
+document mod-list-syms
+mod-list-syms
+List all modules in the form: add-symbol-file  
+for adding modules' symbol tables without loadmodule.sh.
+end
+
 define mod-validate
-set $mod = (struct module*)module_list
-while ($mod != $arg0) && ($mod != _module)
-   set $mod = $mod->next
+set $lmod = modules->next
+   set $mod = (struct module *)(((char *)$lmod) - ((int)&(((struct module 
*)0) -> list)))
+while ($lmod != ) && ($mod != $arg0)
+set $lmod = $lmod->next
+   set $mod = (struct module *)(((char *)$lmod) - ((int)&(((struct 
module *)0) -> list)))
 end
-if $mod == _module
-   set $mod = 0
-   printf "%p is not a module\n", $arg0
+if $lmod == 
+   set $mod = 0
+printf "%p is not a module\n", $arg0
 end
 end
 document mod-validate
 mod-validate 
 Internal user-command used to validate the module parameter.
-If  is a real loaded module, set $mod to it otherwise set $mod to 0.
+If  is a real loaded module, set $mod to it, otherwise set $mod
+to 0.
 end
 
-
 define mod-print-symbols
 mod-validate $arg0
 if $mod != 0
-   set $i = 0
-   while $i < $mod->nsyms
-   set $sym = $mod->syms[$i]
-   printf "%p\t%s\n", $sym->value, $sym->name
-   set $i = $i + 1
-   end
+   set $i = 0
+   while $i < $mod->num_syms
+   set $sym = $mod->syms[$i]
+   printf "%p\t%s\n", $sym->value, $sym->name
+   set $i = $i + 1
+   end
+   set $i = 0
+   while $i < $mod->num_gpl_syms
+   set $sym = $mod->gpl_syms[$i]
+   printf "%p\t%s\n", $sym->value, $sym->name
+   set $i = $i + 1
+   end
 end
 end
 document mod-print-symbols
 mod-print-symbols 
-Print all exported symbols of the module.  see mod-list
-end
-
-
-define mod-add-symbols-align
-mod-validate $arg0
-if $mod != 0
-   set $mod_base = ($mod->size_of_struct + (long)$mod)
-   if ($arg2 != 0) && (($mod_base & ($arg2 - 1)) != 0)
-   set $mod_base = ($mod_base | ($arg2 - 1)) + 1
-   end
-   add-symbol-file $arg1 $mod_base
-end
-end
-document mod-add-symbols-align
-mod-add-symbols-align   
-Load the symbols table of the module from the object file where
-first section aligment is .
-To retreive alignment, use `objdump -h '.
+Print all exported symbols of the module.  See mod-list
 end
 
-define mod-add-symbols
-mod-add-symbols-align $arg0 $arg1 sizeof(long)
-end
-document mod-add-symbols
-mod-add-symbols  
-Load the symbols table of the module from the object file.
-Default alignment is 4.  See mod-add-symbols-align.
-end
-
-define mod-add-lis
-mod-add-symbols-align $arg0 /usr/src/LiS/streams.o 16
-end
-document mod-add-lis
-mod-add-lis 
-Does mod-add-symbols  /usr/src/LiS/streams.o
-end

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]


signature.asc
Description: Digital 

Re: 2.6.11-rc3-bk9 (radeon) hangs hard my laptop

[Alessandro Suardi]

On Sun, 13 Feb 2005 22:12:26 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> On Sun, 2005-02-13 at 01:09 +0100, Alessandro Suardi wrote:
> > On Sun, 13 Feb 2005 21:52:55 +1100, Benjamin Herrenschmidt
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > > It's definitely the new radeon changes - replacing
> > > >  drivers/video/aty/* and include/video/radeon.h in the
> > > >  -bk9 tree with the ones from -bk8 causes the hang to
> > > >  not reproduce anymore. CC'd Ben and edited subject
> > > >  to more accurately reflect the issue.
> > >
> > > Grrr...
> > >
> > > Can you try booting with radeonfb.default_dynclk=-1 and if it doesn't
> > > help, radeonfb.default_dynclk=0 on the kernel command line ?
> >
> > I'm currently booted with -bk9 with default_dynclk = -1 :)
> 
> Excellent. You can help me track it down then. Can you look at
> radeon_pm.c, function
> 
> radeon_pm_enable_dynamic_mode()
> 
> The code for your chip is after the comment "/* Others */" (the M7 is an
> RV200 chip). Can you comment out the various bits in there and see if
> you can locate which one is causing your problem ?

Commenting out pllCLK_PWRMGT_CNTL alone -> still hangs
Commenting out pllCLK_PIN_CNTL in addition -> works
 
Do you want me to build a kernel with only the pllCLK_PIN_CNTL
 instruction commented out or is this enough info ?

Thanks,

--alessandro

  "There is no distance that I don't see
  I do have a will - No limit to my reach"
  
(Wallflowers, "Empire In My Mind")
-
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: drivers/input/power.c is never built

[Adrian Bunk]

In 2.6, drivers/input/power.c would only have been built if 
CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable 
this option.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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] OpenBSD Networking-related randomization port

[Roland Dreier]

linux> It's easy to make a smaller hash by just thowing bits away,
linux> but a block cipher is a permutation, and has to be
linux> invertible.

linux> For example, if I take a k-bit counter and encrypt it with
linux> a k-bit block cipher, the output is guaranteed not to
linux> repeat in less than 2^k steps, but the value after a given
linux> value is hard to predict.

Huh?  What if my cipher consists of XOR-ing with a k-bit pattern?
That's a permutation on the set of k-bit blocks but it happens to
decompose as a product of (non-overlapping) swaps.

In general for more realistic block ciphers like DES it seems
extremely unlikely that the cipher has only a single orbit when viewed
as a permutation.  I would expect a real block cipher to behave more
like a random permutation, which means that the expected number of
orbits for a k-bit cipher should be about ln(2^k) or roughly .7 * k.

 - R.
-
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: i8042 access timings

[Bill Rugolsky Jr.]

On Thu, Jan 27, 2005 at 05:37:14PM +0100, Vojtech Pavlik wrote:
> On Thu, Jan 27, 2005 at 11:34:31AM -0500, Bill Rugolsky Jr. wrote:
> > I have a Digital HiNote collecting dust which had this keyboard problem
> > with the RH 6.x 2.2.x boot disk kernels, IIRC.  I can test if you like,
> > but I won't be able to get to it until the weekend.
>  
> That'd be very nice indeed.
 
Sorry for the long delay in replying; the HiNote needed some effort to get
the thing up and running again.  [Various bits of hardware are broken;
the power switch, floppy, and CD-ROM are busted/flakey.]  I've now got
Fedora Core 3 running on it. I was pleasantly surprised that the 2.6.9
i83265 PCMCIA module loads, and the internal Xircom CEM56 network/modem works.
[Broken with 2.6.10+ though; the fix is probably trivial.]

I wasn't sure exactly what to test.  I applied the following patch
to 2.6.11-rc3-bk9, and booted with i8042_debug=1.  So far, it works
as expected, and there is nothing of interest in the kernel log.
[Also worked with the FC3 2.6.9 kernel and this patch+DEBUG.]

Now that things are up and running, I will apply any patches that you
would like tested.

Bill Rugolsky

--- linux/drivers/input/serio/i8042.c.udelay-backout2005-02-12 
16:22:48.647851998 -0500
+++ linux/drivers/input/serio/i8042.c   2005-02-12 16:23:39.963997609 -0500
@@ -131,9 +131,10 @@
 {
int i = 0;
while ((~i8042_read_status() & I8042_STR_OBF) && (i < 
I8042_CTL_TIMEOUT)) {
-   udelay(50);
+   udelay(I8042_STR_DELAY);
i++;
}
+   if (i > 0) dbg("i8042_wait_read: looped %d times",i);
return -(i == I8042_CTL_TIMEOUT);
 }
 
@@ -141,9 +142,10 @@
 {
int i = 0;
while ((i8042_read_status() & I8042_STR_IBF) && (i < 
I8042_CTL_TIMEOUT)) {
-   udelay(50);
+   udelay(I8042_STR_DELAY);
i++;
}
+   if (i > 0) dbg("i8042_wait_write: looped %d times",i);
return -(i == I8042_CTL_TIMEOUT);
 }
 
@@ -161,7 +163,6 @@
spin_lock_irqsave(_lock, flags);
 
while ((i8042_read_status() & I8042_STR_OBF) && (i++ < 
I8042_BUFFER_SIZE)) {
-   udelay(50);
data = i8042_read_data();
dbg("%02x <- i8042 (flush, %s)", data,
i8042_read_status() & I8042_STR_AUXDATA ? "aux" : 
"kbd");
--- linux/drivers/input/serio/i8042.h.udelay-backout2005-02-12 
16:22:48.647851998 -0500
+++ linux/drivers/input/serio/i8042.h   2005-02-12 16:23:39.964997456 -0500
@@ -30,12 +30,18 @@
 #endif
 
 /*
- * This is in 50us units, the time we wait for the i8042 to react. This
+ * The time (in us) that we wait for the i8042 to react.
+ */
+
+#define I8042_STR_DELAY20
+
+/*
+ * This is in units of the time we wait for the i8042 to react. This
  * has to be long enough for the i8042 itself to timeout on sending a byte
  * to a non-existent mouse.
  */
 
-#define I8042_CTL_TIMEOUT  1
+#define I8042_CTL_TIMEOUT  25000
 
 /*
  * When the device isn't opened and it's interrupts aren't used, we poll it at
-
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.11-rc3-bk9 (radeon) hangs hard my laptop

[Benjamin Herrenschmidt]

On Sun, 2005-02-13 at 01:09 +0100, Alessandro Suardi wrote:
> On Sun, 13 Feb 2005 21:52:55 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > 
> > > It's definitely the new radeon changes - replacing
> > >  drivers/video/aty/* and include/video/radeon.h in the
> > >  -bk9 tree with the ones from -bk8 causes the hang to
> > >  not reproduce anymore. CC'd Ben and edited subject
> > >  to more accurately reflect the issue.
> > 
> > Grrr...
> > 
> > Can you try booting with radeonfb.default_dynclk=-1 and if it doesn't
> > help, radeonfb.default_dynclk=0 on the kernel command line ?
> 
> I'm currently booted with -bk9 with default_dynclk = -1 :)

Excellent. You can help me track it down then. Can you look at
radeon_pm.c, function

radeon_pm_enable_dynamic_mode()

The code for your chip is after the comment "/* Others */" (the M7 is an
RV200 chip). Can you comment out the various bits in there and see if
you can locate which one is causing your problem ?

Thanks in advance !

Ben.


-
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.11-rc3-bk9 (radeon) hangs hard my laptop

[Alessandro Suardi]

On Sun, 13 Feb 2005 21:52:55 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> 
> > It's definitely the new radeon changes - replacing
> >  drivers/video/aty/* and include/video/radeon.h in the
> >  -bk9 tree with the ones from -bk8 causes the hang to
> >  not reproduce anymore. CC'd Ben and edited subject
> >  to more accurately reflect the issue.
> 
> Grrr...
> 
> Can you try booting with radeonfb.default_dynclk=-1 and if it doesn't
> help, radeonfb.default_dynclk=0 on the kernel command line ?

I'm currently booted with -bk9 with default_dynclk = -1 :)

> Also, what is the exact revision of the chip ? (send me an lspci -vv
> dump).

Here you go:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon
Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA])
Subsystem: Dell Computer Corporation Latitude C640
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop+
ParErr- Stepping+ SERR+ FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- SERR-  Finally, what X version are you using ?

Latest FC2 RPM - xorg-x11-6.7.0-11.

--alessandro

  "There is no distance that I don't see
  I do have a will - No limit to my reach"
  
(Wallflowers, "Empire In My Mind")
-
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.11-rc3-bk9 (radeon) hangs hard my laptop

[Benjamin Herrenschmidt]

> It's definitely the new radeon changes - replacing
>  drivers/video/aty/* and include/video/radeon.h in the
>  -bk9 tree with the ones from -bk8 causes the hang to
>  not reproduce anymore. CC'd Ben and edited subject
>  to more accurately reflect the issue.

Grrr... 

Can you try booting with radeonfb.default_dynclk=-1 and if it doesn't
help, radeonfb.default_dynclk=0 on the kernel command line ?

Also, what is the exact revision of the chip ? (send me an lspci -vv
dump).

Finally, what X version are you using ?

Ben.


-
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: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

[Rogério Brito]

On Feb 12 2005, William Park wrote:
> This looks awefully like 'acpi' is on.  If 'acpi=noirq' does not work,
> then try 'pci=noacpi'.

Hi, Willian.

First of all, thank you very much for both your attention and help.

Unfortunately, I have already tried booting the 2.6.11-rc3-mm2 that I just
compiled and I tried using many boot parameters like "acpi=noirq",
"irqpoll", "pci=noacpi", "acpi=off" and setting the BIOS of my motherboard
to "Plug'n'Play OS = Yes" (instead of "Off", which is my default).

To prevent the matters of loosing track of what is being done, I only
changed one option at a time. I put the dmesg logs of all my attempts at
.

Please let me know if I can provide any other useful information.


Thank you very much again for any help, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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] OpenBSD Networking-related randomization port

[linux]

> [EMAIL PROTECTED] writes:
>> (The homebrew 15-bit block cipher in this code does show how much the
>> world needs a small block cipher for some of these applications.)
>
> Doesn't TEA fill this niche? It's certainly used for this in the Linux
> kernel, e.g. in reiserfs (although I have my doubts it is really useful
> there) 

Sorry; ambiguous parsing.  I meant "(small block) cipher", not "small
(block cipher)".  TEA is intended for the latter niche.  What I meant
was a cipher that could encrypt blocks smaller than 64 bits.

It's easy to make a smaller hash by just thowing bits away, but a block
cipher is a permutation, and has to be invertible.

For example, if I take a k-bit counter and encrypt it with a k-bit
block cipher, the output is guaranteed not to repeat in less than 2^k
steps, but the value after a given value is hard to predict.

There is a well-known technique for reducing the block size of a cipher
by a small factor, such as from a power of 2 to a prime number
slightly lower.  That is:

unsigned
encrypt_mod_n(unsigned x, unsigned n)
{
assert(x < n);
do {
x = encrypt(x);
} while (x >= n);
return x;
}

It takes a bit of thinking to realize why this creates an bijection from
[0..n-1] -> [0..n-1], but it's kind of a neat "aha!" when it does.

Remember, encrypt() is a bijection from [0..N-1] -> [0..N-1] for some
N >= n.  Typically N = 2^k for some k.

However, this technique requires N/n calls to encrypt().  I.e.
n calls to encrypt_mod_n() will cause N calls to encrypt().

It's generally considered practical up to N/n = 2, so we can encrypt
modulo any modulus n if we have encrypt() functions for any N = 2^k a
power of 2.  I.e. a k-bit block cipher.

For example, suppose we want to encrypt 7-digit North American telephone
numbers.  These are of the form NXX-, where N is a digit other than
0 or 1, and X is any digit.  there are 8e6 possibilities.  Using this
scheme and a 23-bit block cipher, we can encrypt them to different valid
7-digit telephone numbers.

Likewise, 10-digit number with area codes, +1 NXX NXX- (but not
starting with N11) are also possible.  There are 792 area codes and
8e6 numbers for a total of 777600 < 2^33 combinations.

This sort of thing is very useful for adding encryption to protocols and
file formats not designed for it.


However, the standard literature is notably lacking in block ciphers
in funny block sizes.  There was one AES submission (The Hasty Pudding
Cipher, http://www.cs.arizona.edu/~rcs/hpc/) that supported variable
block sizes, but it was eliminated fairly early.


To start with, consider very small blocks: 1, 2 or 3 bits.
There are only two possible things encrypt() can do with a 1-bit value:
either invert it or leave it alone.

There are 4! = 24 possible 2-bit encryption operations.  Ideally, the
key should specify them all with equal probability, but 24 does not
evenly divide the (power of 2 sized) keyspace.  It is interesting to
look at how iniformly the possibilities are covered.

It's fun to consider a Feistel network, dividing the plaintext into 1-bit
L and R values, and alternating L ^= f(R), R ^= f(L) for (not nexessarily
invertible) round functions f.  Since there are only 4 possible 1-bit
functions (1, 0, x and !x), you can consider each round to have an
independent 2-bit round subkey and see how the cipher's uniformity
develops as you increase the number of rounds and the key length to go
with it.

There are 8! = 40320 3-bit encryption operations.  Again, all should be
covered uniformly.  An odd number of bits makes a Feistel design more
challenging.  But if you don't allow odd numbers of bits, you have to push
the shrinking technique it to N/n = 4, which starts to get unpleasant.
-
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: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

[William Park]

On Sat, Feb 12, 2005 at 08:47:15PM -0200, Rog?rio Brito wrote:
> On Feb 12 2005, William Park wrote:
> > On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote:
> > > For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
> > > some -mm trees and also -ac) I have been getting the message "irq 10:
> > > nobody cared!".
> > 
> > Try 'acpi=noirq'.
> 
> Unfortunately, I have already tried that and I still get stack traces
> like this one (this time, booted without any acpi-related option):
...
> ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
> PCI: setting IRQ 10 as level-triggered
> ACPI: PCI interrupt :00:11.0[A] -> GSI 10 (level, low) -> IRQ 10

This looks awefully like 'acpi' is on.  If 'acpi=noirq' does not work,
then try 'pci=noacpi'.

-- 
William Park <[EMAIL PROTECTED]>, Toronto, Canada
Slackware Linux -- because I can type.
-
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: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

[Rogério Brito]

On Feb 12 2005, William Park wrote:
> On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote:
> > For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
> > some -mm trees and also -ac) I have been getting the message "irq 10:
> > nobody cared!".
> 
> Try 'acpi=noirq'.

Unfortunately, I have already tried that and I still get stack traces like
this one (this time, booted without any acpi-related option):

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Probing IDE interface ide1...
hdc: Hewlett-Packard CD-Writer Plus 9100, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
PDC20265: IDE controller at PCI slot :00:11.0
PCI: :00:11.0 has unsupported PM cap regs version (1)
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI interrupt :00:11.0[A] -> GSI 10 (level, low) -> IRQ 10
PDC20265: chipset revision 2
PDC20265: 100% native mode on irq 10
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive
ide2 at 0x8800-0x8807,0x8402 on irq 10
Probing IDE interface ide3...
hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive
irq 10: nobody cared (try booting with the "irqpoll" option.
 [] __report_bad_irq+0x31/0x77
 [] note_interrupt+0x75/0x99
 [] __do_IRQ+0x95/0xc1
 [] do_IRQ+0x19/0x24
 [] common_interrupt+0x1a/0x20
 [] __do_softirq+0x2c/0x7d
 [] do_softirq+0x22/0x26
 [] do_IRQ+0x1e/0x24
 [] common_interrupt+0x1a/0x20
 [] enable_irq+0x88/0x8d
 [] probe_hwif+0x2f7/0x383
 [] ata_attach+0xa3/0xbd
 [] probe_hwif_init_with_fixup+0x10/0x74
 [] ide_setup_pci_device+0x72/0x7f
 [] pdc202xx_init_one+0x15/0x18
 [] ide_scan_pcidev+0x34/0x59
 [] ide_scan_pcibus+0x1c/0x92
 [] probe_for_hwifs+0xb/0xd
 [] ide_init+0x44/0x59
 [] do_initcalls+0x4b/0x99
 [] init+0x0/0xce
 [] init+0x27/0xce
 [] kernel_thread_helper+0x5/0xb
handlers:
[] (ide_intr+0x0/0xee)
Disabling IRQ #10
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I can provide any information that is necessary about my system to fix the
problem.

I just finished compiling kernel 2.6.11-rc3-mm2 and I will report back if
there is any difference.


Thank you very much for any help, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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.11-rc3-mm2

[Olaf Dietsche]

Christoph Hellwig <[EMAIL PROTECTED]> writes:

> On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
>> 
>> - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
>>   It seems that nothing else is going to come along and this is completely
>>   encapsulated.
>
> Even if we accept a module that grants capabilities to groups this isn't fine
> yet because it only supports two specific capabilities (and even those two in
> different ways!) instead of adding generic support to bind capabilities to
> groups.

Unless I misunderstood the code, this one is available for
quite some time: 
or a newer, self-contained version 

Or you could use a real solution - filesystem capabilities:
 and if you don't like
this one :-), there's also an alternative existing here:


Regards, Olaf.
-
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] OpenBSD Networking-related randomization port

[Andi Kleen]

[EMAIL PROTECTED] writes:
>
> (The homebrew 15-bit block cipher in this code does show how much the
> world needs a small block cipher for some of these applications.)

Doesn't TEA fill this niche? It's certainly used for this in the Linux
kernel, e.g. in reiserfs (although I have my doubts it is really useful
there) 

-Andi
-
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: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

[William Park]

On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote:
> Dear developers,
> 
> For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
> some -mm trees and also -ac) I have been getting the message "irq 10:
> nobody cared!".
> 
> The message says that I should pass the irqpoll option to the kernel and
> even if I do, I still get the stack trace and the "irq 10: nobody cared!"
> message. :-(
> 
> The message seems to be related to the Promise PDC20265 driver and it
> appeared right after I moved my HDs from my motherboard's VIA controllers
> to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a
> controllers and 2 Promise PDC20265 controllers.
> 
> I already tried enabling and disabling ACPI, but it seems that the problem
> just doesn't go away. :-(
> 
> I am including the dmesg log of my system with this message. I am CC'ing
> the linux-ide list, but I'm only subscribed to linux-kernel. I would
> appreciate CC's, if possible.
> 
> 
> Thank you very much for any help, Rog?rio.
> 
> P.S.: I am, right now, re-compiling 2.6.11-rc3-mm1 with the extra pass of
> kallsyms to see if the problem persists with this release.

Try 'acpi=noirq'.

-- 
William Park <[EMAIL PROTECTED]>, Toronto, Canada
Slackware Linux -- because I can type.
-
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] device-mapper: multipath hardware handler for EMC

[Mike Christie]

Christoph Hellwig wrote:
+/* Code borrowed from dm-lsi-rdac by Mike Christie */

Any reason that module isn't submitted?
I do not have access to their HW specs, and have been busy with
some iscsi things so I did not have time to finish things up.
I was also hoping LSI would soon figure out that they should be
using dm (I have seen some of them pop up now and then only)
and take over the work.
-
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.11-rc3-bk9 (radeon) hangs hard my laptop

[Alessandro Suardi]

On Sat, 12 Feb 2005 16:59:20 +0100, Alessandro Suardi
<[EMAIL PROTECTED]> wrote:
> On Sat, 12 Feb 2005 15:49:05 +0100, Alessandro Suardi
> <[EMAIL PROTECTED]> wrote:
> > Dell Latitude C640, PIV @1.8Ghz, 1GB RAM, uptodate FC2
> >
> > -bk7 (which I currently rebooted in) is okay.
> > -bk9 at first try got me to the login prompt, logged in, ran startx...
> >  frozen with the black background before seeing anything.
> >
> > Second try hung well before, at the point where it switches the
> >  radeonfb on.
> >
> > Only cure is to keep the power button pressed for 10".
> >
> > Will try building -bk8 (which is currently running on my
> >  old desktop K7-800) and report...
> 
> -bk8 which I'm now booted in is also OK, so something
>  broke between -bk8 and -bk9... attached .config and
>  /var/log/messages from the boot in -bk8 and the one
>  in -bk9 which succeeded before hanging on startx.

It's definitely the new radeon changes - replacing
 drivers/video/aty/* and include/video/radeon.h in the
 -bk9 tree with the ones from -bk8 causes the hang to
 not reproduce anymore. CC'd Ben and edited subject
 to more accurately reflect the issue.

Thanks,

--alessandro

  "There is no distance that I don't see
  I do have a will - No limit to my reach"
  
(Wallflowers, "Empire In My Mind")
-
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/

how to make a contribution

[sylvanino b]

Hi,

I am writing to get some advice and general information.

I wrote a kernel tool for my personnal usage which goal is to keep a
record of recent task preemptions and interruptions that appears under
linux. Although the record is short (a few minutes only), It can help
to analyse scheduling algorithm efficiency and also driver timing
issues. The user can access data from user-space, through proc
filesystem and analyze it with a graphics tool.  Then, since it's alsa
availlable within KDB, it can give clues and help for debugging.

So far, the tool is not a big deal, but not trivial either. When It is
running, the tool doesn't overload the system. And when it is not
running, it's just transparent.

I would like to share this tool if somebody is interested, but I dont
know how to proceed, I mean how to make a contribution an efficient
way. Any help/idea/information is welcome.
Thanks,

Sylvanino
-
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: [RFC 2.6.11-rc2-mm2 7/7] mm: manual page migration -- sys_page_migrate

[Paul Jackson]

Dave wrote:
> Might it be useful to use nodemasks instead of those arrays?

I don't think he can.  A nodemask represents an unorderd set of nodes. 
He needs (or wants) to pass a  map, mapping the node that each
page might be on, to the node to which it should migrate.  A bitmask
doesn't contain enough information to specify that.

Perhaps instead he could pass two node arguments, old and new, with the
migration routines understanding that they were to migrate only pages
found on the old node, to the new node, ignoring other pages.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
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/

spontaneous rebuilds on prom console tables

[Meelis Roos]

When I run "make" on 2.6 sparc32 macine several times it remakes prom 
console files each time and so links a new kernel.

  CNMKHSH drivers/video/console/promcon_tbl.c
  CC  drivers/video/console/promcon_tbl.o
  LD  drivers/video/console/built-in.o
  LD  drivers/video/built-in.o
  LD  drivers/built-in.o
...
--
Meelis Roos ([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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview

[Andi Kleen]

On Sat, Feb 12, 2005 at 01:54:26PM -0200, Marcelo Tosatti wrote:
> On Sat, Feb 12, 2005 at 12:17:25PM +0100, Andi Kleen wrote:
> > Ray Bryant <[EMAIL PROTECTED]> writes:
> > > set of pages associated with a particular process need to be moved.
> > > The kernel interface that we are proposing is the following:
> > >
> > > page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
> > 
> > [Only commenting on the interface, haven't read your patches at all]
> > 
> > This is basically mbind() with MPOL_F_STRICT, except that it has a pid 
> > argument. I assume that's for the benefit of your batch scheduler.
> 
> As far as I understand mbind() is used to set policies to given memory 
> regions, not move memory regions?

There is a MPOL_F_STRICT flag. Currently it fails when the memory
is not on the right node(s) and the flag is set, but it could as well move. 

In fact Steve Longerbeam already did a patch to move in this case,
but it hasn't been merged yet for some reasons.


> > mmap in parallel. The only way I can think of to do this would be to
> > check for changes in maps after a full move and loop, but then you risk
> > livelock.
> 
> True. 
> 
> There is no problem, however, if all threads beloging to the process are 
> stopped, 
> as Ray mentions. 
> 
> So, there wont be memory mapping changes happening at the same time. 

Ok. But it's still quite ugly to read /proc/*/maps for this.

> 
> > And you cannot also just specify va_start=0, va_end=~0UL because that
> > would make the node arrays grow infinitely. 
> > 
> > Also is there a good use case why the batch scheduler should only
> > move individual areas in a process around, not the full process?
> 
> Quoting him:
> 
> "In addition to its use by batch schedulers, we also envision that
> this facility could be used by a program to re-arrange the allocation
> of its own pages on various nodes of the NUMA system, most likely
> to optimize performance of the application during different phases
> of its computation."
> 
> Seems doable. 

That is what mbind() already supports, just someone needs to hook up
the page moving code with MPOL_F_STRICT.
 
> Are there any good xamples of optimizations that could be made by 
> moving pages around except for NUMA?

It's all fundamentally a NUMA thing.

There was some talk to define fake nodes as fall back pools
to get low latency multimedia allocation, with that it may be useful
too at some point.

-Andi
-
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: bttv: tuner: i2c i/o error: rc == -121 (should be 4)

[Margus Eha]

Thanks for the notification.

Margus


On Sat, 12 Feb 2005 21:22:17 +0100, Jindrich Makovicka
<[EMAIL PROTECTED]> wrote:
> Margus Eha wrote:
> > Tv card works but i can't change channel. Something goes wrong in tuner.c
> > when tvtime program tries to change frequency. In /var/log/messages i can 
> > find
> > tuner: i2c i/o error: rc == -121 (should be 4).
> >
> > Las working version i tried was 2.6.11-rc2
> > Both 2.6.11-rc3-mm1 and Both 2.6.11-rc3-mm2 are not working.
> >
> > If kernel conf is needed i can send.
> 
> http://bugme.osdl.org/show_bug.cgi?id=4171
> 
> --
> JM
> 
> -
> 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: [RFC 2.6.11-rc2-mm2 7/7] mm: manual page migration -- sys_page_migrate

[Dave Hansen]

On Fri, 2005-02-11 at 19:26 -0800, Ray Bryant wrote:
> This patch introduces the sys_page_migrate() system call:
> 
> sys_page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
> 
> Its intent is to cause the pages in the range given that are found on
> old_nodes[i] to be moved to new_nodes[i].  Count is the the number of
> entries in these two arrays of short.

Might it be useful to use nodemasks instead of those arrays?  That's
already the interface that the mbind() interfaces use, and it probably
pays to be consistent with all of the numa syscalls.

There also probably needs to be a bit more coordination between the
other NUMA API and this one.  I noticed that, for now, the migration
loop only makes a limited number of passes.  It appears that either you
don't require that, once the syscall returns, that *all* pages have been
migrated (there could have been allocations done behind the loop) or you
have some way of keeping the process from doing any more allocations.

There might also be some use to making sure that the NUMA binding API
and the migration code agree what is in the affected VMA.  Otherwise,
there might be some interesting situations where kswapd is swapping
pages out behind a migration call, and the NUMA API is refilling those
pages with ones that the migration call doesn't agree with.

That's one reason I was looking at the loop to make sure it's only one
pass.  I think doing passes until all pages are migrated gives you a
livelock, so the limited number obviously makes sense. 

Will you need other APIs to tell how successful the migration request
was?  Simply returning how many pages were migrated back from the
syscall doesn't really tell you anything concrete because there could be
kswapd activity or other migration calls that could be messing up the
work from the previous call.  Are all of these VMAs meant to be
mlock()ed?

-- 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/

reboot hangs on Toshiba Satellite 1800 laptop

[Meelis Roos]

This seems to be an old problem (google tells it was the same in 2.2 
kernels) but now it troubles me. I have a laptop, Toshiba Satellite 1800 
(Celeron 1.1 GHz, ALi chipset). It works fine but rebooting from linux 
always hangs the machine hard. The last thing seen is "Rebooting", after 
thatt the screen goes black, fan turns on and nothing more happens. I 
can press and hold the power button for 5 seconds and the it powers off 
and I can power it on and work as usual.

I'm running 2.6.11-rc3+BK.
Tried booting with acpi=off, noapic, noapic+nolapic, lapic - no go.
This laptop has local APIC turned off by BIOS so I tried the following 
kernel boot options with both lapic and without lapic: reboot=w, 
reboot=c, reboot=b, reboot=h. Still hangs.

There is a hint in google tyhat turning off APIC cures it but it does 
not seem to work for me.

Any ideas?
--
Meelis Roos ([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: Problem on SATA-disk with Promise SATAII 150 TX4 ("DriveReady SeekComplete Error")

[Joerg Sommrey]

Jeff Garzik wrote::
>Johannes Resch wrote:
>> Hi,
>> 
>> [please CC me on replies]
>> 
>> I've got a box running 2.6.10 (with the patch[0] needed to support the 
>> Promise SATAII 150 TX4 controller).
>> This box has three software raid1 partitions mirrored on a SATA disk on 
>> the Promise controller and a disk on the mainboard IDE controller (VIA 
>> vt8235).
>> 
>> Within 4 days running the raid1, I got those three errors pasted below, 
>> each marking the SATA-raidmember as faulty. After "raidhotremove" and 
>> "raidhotadd" the SATA-raidmember syncs again fine and works at least a 
>> day until it is marked as faulty again.
>> 
>> Any pointers where I could look at to resolve this problem?
>> The SATA drive is a new Seagate ST3250823AS.

>I would change out your cables, and also make sure you are running 
>2.6.11-rc3-bk-latest, which includes all the SATAII patches and other fixes.

I don't believe it has anything to do with cabling.  2.6.10-ac9 introduced
some sata patches.  I didn't check -ac9 and -ac10, but -ac11 and -ac12 are
not usable on my box with exactly the same symptoms.

-jo
-- 
-rw-r--r--  1 jo users 63 2005-02-12 18:43 /home/jo/.signature
-
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: [RFC 2.6.11-rc2-mm2 7/7] mm: manual page migration -- sys_page_migrate

[Paul Jackson]

Andi wrote:
> They're already exposed through mbind/set_mempolicy/get_mempolicy and sysfs
> of course.

And soon I hope through cpusets ;).

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
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/

Re: How to disable slow agpgart in kernel config?

[Dave Jones]

On Sat, Feb 12, 2005 at 08:36:13PM +0100, Marcus Hartig wrote:
 > Arjan van de Ven wrote:
 > 
 > >hmm I wonder.. .could you collect lspci -vxxx settings for the AGP
 > >device (lspci -vxxx gives you lots of devices, but only one is relevant)
 > >in both cases, maybe the difference between the two shows something
 > >useful...
 > 
 > Hmmm...only the latency at the VGA card.

Was there any differnces in the devices at 00:00.0 and 00:01.0 ?
(host & pci bridges)

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: bttv: tuner: i2c i/o error: rc == -121 (should be 4)

[Jindrich Makovicka]

Margus Eha wrote:
Tv card works but i can't change channel. Something goes wrong in tuner.c
when tvtime program tries to change frequency. In /var/log/messages i can find
tuner: i2c i/o error: rc == -121 (should be 4). 

Las working version i tried was 2.6.11-rc2
Both 2.6.11-rc3-mm1 and Both 2.6.11-rc3-mm2 are not working.
If kernel conf is needed i can send.
http://bugme.osdl.org/show_bug.cgi?id=4171
--
JM
-
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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview

[Marcelo Tosatti]

On Sat, Feb 12, 2005 at 01:54:26PM -0200, Marcelo Tosatti wrote:
> On Sat, Feb 12, 2005 at 12:17:25PM +0100, Andi Kleen wrote:
> > Ray Bryant <[EMAIL PROTECTED]> writes:
> > > set of pages associated with a particular process need to be moved.
> > > The kernel interface that we are proposing is the following:
> > >
> > > page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
> > 
> > [Only commenting on the interface, haven't read your patches at all]
> > 
> > This is basically mbind() with MPOL_F_STRICT, except that it has a pid 
> > argument. I assume that's for the benefit of your batch scheduler.
> 
> As far as I understand mbind() is used to set policies to given memory 
> regions, not move memory regions?
> 
> > But it's not clear to me how and why the batch scheduler should know about
> > virtual addresses of different processes anyways. Walking
> > /proc/pid/maps? That's all inherently racy when the process is doing
> > mmap in parallel. The only way I can think of to do this would be to
> > check for changes in maps after a full move and loop, but then you risk
> > livelock.
> 
> True. 
> 
> There is no problem, however, if all threads beloging to the process are 
> stopped, 
> as Ray mentions. 
> 
> So, there wont be memory mapping changes happening at the same time. 
> 
> Note that the memory migration code which sys_page_migrate() uses moves
> running processes to other memory zones, handling truncate, etc.
> 
> > And you cannot also just specify va_start=0, va_end=~0UL because that
> > would make the node arrays grow infinitely. 
> > 
> > Also is there a good use case why the batch scheduler should only
> > move individual areas in a process around, not the full process?
> 
> Quoting him:
> 
> "In addition to its use by batch schedulers, we also envision that
> this facility could be used by a program to re-arrange the allocation
> of its own pages on various nodes of the NUMA system, most likely
> to optimize performance of the application during different phases
> of its computation."
> 
> Seems doable. 
> 
> Are there any good xamples of optimizations that could be made by 
> moving pages around except for NUMA?

If you have virtually indexed caches moving pages around can optimize cache 
behaviour 
if program access pattern is well known? That is not a thing common thing 
to do - and is architecture dependant anyway.
-
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: once more w/feeling

[shogunx]

On Sat, 12 Feb 2005, Gil Lapidus wrote:

That would be lack of ide adapter support in your kernel.  common with
k-6's.  try just the generic ide support.


> Greetings,
>
> On a K6-2 500MHz box.
>
> kernel 2.4.28 boots _fine_.
>
> kernel 2.6.9 displays "Loading " then PC resets.
>
> Here's the .config filtered through grep ^C:
>
> CONFIG_X86=y
> CONFIG_MMU=y
> CONFIG_UID16=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_IOMAP=y
> CONFIG_EXPERIMENTAL=y
> CONFIG_CLEAN_COMPILE=y
> CONFIG_BROKEN_ON_SMP=y
> CONFIG_LOCALVERSION=""
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_POSIX_MQUEUE=y
> CONFIG_SYSCTL=y
> CONFIG_AUDIT=y
> CONFIG_AUDITSYSCALL=y
> CONFIG_LOG_BUF_SHIFT=14
> CONFIG_HOTPLUG=y
> CONFIG_EMBEDDED=y
> CONFIG_KALLSYMS=y
> CONFIG_FUTEX=y
> CONFIG_EPOLL=y
> CONFIG_IOSCHED_NOOP=y
> CONFIG_IOSCHED_AS=y
> CONFIG_IOSCHED_DEADLINE=y
> CONFIG_IOSCHED_CFQ=y
> CONFIG_SHMEM=y
> CONFIG_MODULES=y
> CONFIG_MODULE_UNLOAD=y
> CONFIG_MODULE_FORCE_UNLOAD=y
> CONFIG_OBSOLETE_MODPARM=y
> CONFIG_MODVERSIONS=y
> CONFIG_KMOD=y
> CONFIG_X86_PC=y
> CONFIG_MK6=y
> CONFIG_X86_GENERIC=y
> CONFIG_X86_CMPXCHG=y
> CONFIG_X86_XADD=y
> CONFIG_X86_L1_CACHE_SHIFT=7
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_X86_WP_WORKS_OK=y
> CONFIG_X86_INVLPG=y
> CONFIG_X86_BSWAP=y
> CONFIG_X86_POPAD_OK=y
> CONFIG_X86_ALIGNMENT_16=y
> CONFIG_X86_INTEL_USERCOPY=y
> CONFIG_X86_USE_PPRO_CHECKSUM=y
> CONFIG_HPET_TIMER=y
> CONFIG_PREEMPT=y
> CONFIG_X86_UP_APIC=y
> CONFIG_X86_LOCAL_APIC=y
> CONFIG_X86_TSC=y
> CONFIG_X86_MCE=y
> CONFIG_X86_MCE_NONFATAL=m
> CONFIG_TOSHIBA=m
> CONFIG_I8K=m
> CONFIG_MICROCODE=m
> CONFIG_X86_MSR=m
> CONFIG_X86_CPUID=m
> CONFIG_EDD=m
> CONFIG_NOHIGHMEM=y
> CONFIG_MTRR=y
> CONFIG_HAVE_DEC_LOCK=y
> CONFIG_PM=y
> CONFIG_SOFTWARE_SUSPEND=y
> CONFIG_PM_STD_PARTITION=""
> CONFIG_ACPI=y
> CONFIG_ACPI_BOOT=y
> CONFIG_ACPI_INTERPRETER=y
> CONFIG_ACPI_SLEEP=y
> CONFIG_ACPI_SLEEP_PROC_FS=y
> CONFIG_ACPI_AC=m
> CONFIG_ACPI_BATTERY=m
> CONFIG_ACPI_BUTTON=m
> CONFIG_ACPI_FAN=m
> CONFIG_ACPI_PROCESSOR=m
> CONFIG_ACPI_THERMAL=m
> CONFIG_ACPI_TOSHIBA=m
> CONFIG_ACPI_BLACKLIST_YEAR=0
> CONFIG_ACPI_BUS=y
> CONFIG_ACPI_EC=y
> CONFIG_ACPI_POWER=y
> CONFIG_ACPI_PCI=y
> CONFIG_ACPI_SYSTEM=y
> CONFIG_X86_PM_TIMER=y
> CONFIG_PCI=y
> CONFIG_PCI_GOANY=y
> CONFIG_PCI_BIOS=y
> CONFIG_PCI_DIRECT=y
> CONFIG_PCI_MMCONFIG=y
> CONFIG_PCI_LEGACY_PROC=y
> CONFIG_PCI_NAMES=y
> CONFIG_ISA=y
> CONFIG_PCMCIA=m
> CONFIG_PCMCIA_DEBUG=y
> CONFIG_YENTA=m
> CONFIG_CARDBUS=y
> CONFIG_PD6729=m
> CONFIG_I82092=m
> CONFIG_I82365=m
> CONFIG_TCIC=m
> CONFIG_PCMCIA_PROBE=y
> CONFIG_BINFMT_ELF=y
> CONFIG_BINFMT_AOUT=m
> CONFIG_BINFMT_MISC=m
> CONFIG_STANDALONE=y
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> CONFIG_FW_LOADER=m
> CONFIG_PARPORT=m
> CONFIG_PARPORT_PC=m
> CONFIG_PARPORT_PC_CML1=m
> CONFIG_PARPORT_1284=y
> CONFIG_PNP=y
> CONFIG_ISAPNP=y
> CONFIG_PNPBIOS=y
> CONFIG_BLK_DEV_FD=y
> CONFIG_BLK_DEV_LOOP=m
> CONFIG_BLK_DEV_RAM=m
> CONFIG_BLK_DEV_RAM_SIZE=4096
> CONFIG_IDE=y
> CONFIG_BLK_DEV_IDE=y
> CONFIG_BLK_DEV_IDEDISK=y
> CONFIG_IDEDISK_MULTI_MODE=y
> CONFIG_BLK_DEV_IDECD=y
> CONFIG_IDE_TASKFILE_IO=y
> CONFIG_IDE_GENERIC=y
> CONFIG_BLK_DEV_CMD640=y
> CONFIG_BLK_DEV_CMD640_ENHANCED=y
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_IDEPCI_SHARE_IRQ=y
> CONFIG_BLK_DEV_GENERIC=y
> CONFIG_BLK_DEV_OPTI621=m
> CONFIG_BLK_DEV_RZ1000=y
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> CONFIG_IDEDMA_PCI_AUTO=y
> CONFIG_BLK_DEV_AEC62XX=y
> CONFIG_BLK_DEV_ALI15X3=y
> CONFIG_BLK_DEV_AMD74XX=y
> CONFIG_BLK_DEV_ATIIXP=y
> CONFIG_BLK_DEV_CMD64X=y
> CONFIG_BLK_DEV_CY82C693=y
> CONFIG_BLK_DEV_HPT34X=y
> CONFIG_BLK_DEV_HPT366=y
> CONFIG_BLK_DEV_PIIX=y
> CONFIG_BLK_DEV_NS87415=y
> CONFIG_BLK_DEV_SIS5513=y
> CONFIG_BLK_DEV_SLC90E66=y
> CONFIG_BLK_DEV_TRM290=y
> CONFIG_BLK_DEV_VIA82CXXX=y
> CONFIG_IDE_CHIPSETS=y
> CONFIG_BLK_DEV_IDEDMA=y
> CONFIG_IDEDMA_AUTO=y
> CONFIG_SCSI=y
> CONFIG_SCSI_DPT_I2O=m
> CONFIG_SCSI_SATA=y
> CONFIG_SCSI_ATA_PIIX=y
> CONFIG_SCSI_SATA_SX4=m
> CONFIG_SCSI_SATA_SIS=m
> CONFIG_SCSI_IPR=m
> CONFIG_SCSI_QLA2XXX=y
> CONFIG_IEEE1394=y
> CONFIG_IEEE1394_OHCI1394=y
> CONFIG_IEEE1394_RAWIO=y
> CONFIG_NET=y
> CONFIG_PACKET=y
> CONFIG_UNIX=y
> CONFIG_INET=y
> CONFIG_IP_MULTICAST=y
> CONFIG_NETFILTER=y
> CONFIG_IP_NF_CONNTRACK=y
> CONFIG_IP_NF_QUEUE=y
> CONFIG_IP_NF_IPTABLES=y
> CONFIG_IP_NF_MATCH_LIMIT=y
> CONFIG_IP_NF_MATCH_IPRANGE=y
> CONFIG_IP_NF_MATCH_MAC=y
> CONFIG_IP_NF_MATCH_PKTTYPE=y
> CONFIG_IP_NF_MATCH_MARK=y
> CONFIG_IP_NF_MATCH_MULTIPORT=y
> CONFIG_IP_NF_MATCH_TOS=y
> CONFIG_IP_NF_MATCH_RECENT=y
> CONFIG_IP_NF_MATCH_ECN=y
> CONFIG_IP_NF_MATCH_DSCP=y
> CONFIG_IP_NF_MATCH_AH_ESP=y
> CONFIG_IP_NF_MATCH_LENGTH=y
> CONFIG_IP_NF_MATCH_TTL=y
> CONFIG_IP_NF_MATCH_TCPMSS=y
> CONFIG_IP_NF_MATCH_HELPER=y
> CONFIG_IP_NF_MATCH_STATE=y
> CONFIG_IP_NF_MATCH_CONNTRACK=y
> CONFIG_IP_NF_MATCH_OWNER=y
> CONFIG_IP_NF_FILTER=y
> CONFIG_IP_NF_TARGET_REJECT=y
> CONFIG_IP_NF_TARGET_LOG=y
> CONFIG_IP_NF_TARGET_ULOG=y
> CONFIG_IP_NF_TARGET_TCPMSS=y
> CONFIG_IP_NF_NAT=y
> CONFIG_IP_NF_NAT_NEEDED=y
> 

Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview

[Marcelo Tosatti]

On Sat, Feb 12, 2005 at 12:17:25PM +0100, Andi Kleen wrote:
> Ray Bryant <[EMAIL PROTECTED]> writes:
> > set of pages associated with a particular process need to be moved.
> > The kernel interface that we are proposing is the following:
> >
> > page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
> 
> [Only commenting on the interface, haven't read your patches at all]
> 
> This is basically mbind() with MPOL_F_STRICT, except that it has a pid 
> argument. I assume that's for the benefit of your batch scheduler.

As far as I understand mbind() is used to set policies to given memory 
regions, not move memory regions?

> But it's not clear to me how and why the batch scheduler should know about
> virtual addresses of different processes anyways. Walking
> /proc/pid/maps? That's all inherently racy when the process is doing
> mmap in parallel. The only way I can think of to do this would be to
> check for changes in maps after a full move and loop, but then you risk
> livelock.

True. 

There is no problem, however, if all threads beloging to the process are 
stopped, 
as Ray mentions. 

So, there wont be memory mapping changes happening at the same time. 

Note that the memory migration code which sys_page_migrate() uses moves
running processes to other memory zones, handling truncate, etc.

> And you cannot also just specify va_start=0, va_end=~0UL because that
> would make the node arrays grow infinitely. 
> 
> Also is there a good use case why the batch scheduler should only
> move individual areas in a process around, not the full process?

Quoting him:

"In addition to its use by batch schedulers, we also envision that
this facility could be used by a program to re-arrange the allocation
of its own pages on various nodes of the NUMA system, most likely
to optimize performance of the application during different phases
of its computation."

Seems doable. 

Are there any good xamples of optimizations that could be made by 
moving pages around except for NUMA?

Does IRIX has anything similar? 

> I think the only sane way for an external process to move another 
> around is to do it for the whole process. For that you wouldn't need
> most of the arguments, but just a simple move_process_vm call,
> or perhaps just a file in /proc where the new node can be written to.

It seems interesting for a process to move its own vma for optimizations
reasons?

> There may be an argument to do this for individual 
> tmpfs/hugetlbfs/sysv shm segments too, but mbind() already supports
> that (just map them from a different process and change the policy there)
> 
> For process use you could just do it in mbind() or perhaps
> part of the process policy (move page around when touched by process).

Hum, how is that supposed to work ? You want to modify the pagefault handler? 
-
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: How to disable slow agpgart in kernel config?

[Marcus Hartig]

Arjan van de Ven wrote:
hmm I wonder.. .could you collect lspci -vxxx settings for the AGP
device (lspci -vxxx gives you lots of devices, but only one is relevant)
in both cases, maybe the difference between the two shows something
useful...
Hmmm...only the latency at the VGA card.
With AGPGART:
01:00.0 VGA compatible controller: nVidia Corporation NV35 [GeForce FX 
5900] (rev a1) (prog-if 00 [VGA])
Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 5
Memory at e000 (32-bit, non-prefetchable) [size=16M]
Memory at d800 (32-bit, prefetchable) [size=128M]
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 3.0
00: de 10 31 03 07 00 b0 02 a1 00 00 03 00 20 00 00
10: 00 00 00 e0 08 00 00 d8 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 60 00 00 00 00 00 00 00 05 01 05 01
40: 00 00 00 00 02 00 30 00 1b 0e 00 1f 00 00 00 00
50: 01 00 00 00 01 00 00 00 ce d6 23 00 0f 00 00 00
60: 01 44 02 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

With NV_AGP:
01:00.0 VGA compatible controller: nVidia Corporation NV35 [GeForce FX 
5900] (rev a1) (prog-if 00 [VGA])
Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 5
Memory at e000 (32-bit, non-prefetchable) [size=16M]
Memory at d800 (32-bit, prefetchable) [size=128M]
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 3.0
00: de 10 31 03 07 00 b0 02 a1 00 00 03 00 f8 00 00
10: 00 00 00 e0 08 00 00 d8 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 60 00 00 00 00 00 00 00 05 01 05 01
40: 00 00 00 00 02 00 30 00 1b 0e 00 1f 02 43 00 1f
50: 01 00 00 00 01 00 00 00 ce d6 23 00 0f 00 00 00
60: 01 44 02 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Both complete output: http://www.marcush.de/bench/
Greetings,
Marcus
-
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.4.30-pre1] Sparc SMP build fixes

[David S. Miller]

On Sat, 12 Feb 2005 11:13:49 +0100
Willy Tarreau <[EMAIL PROTECTED]> wrote:

> The recent addition of an smp_rmb() in kfree_skb() by Herbert Xu
> broke SMP builds on sparc and sparc64, but it's not Herbert's fault,
> it's because of a few extra semi-colons in system.h for both archs.

I pushed this independantly to Marcelo yesterday, he just hasn't
pulled it in yet.

Sit tight :-)
-
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/

bttv: tuner: i2c i/o error: rc == -121 (should be 4)

[Margus Eha]

Tv card works but i can't change channel. Something goes wrong in tuner.c
when tvtime program tries to change frequency. In /var/log/messages i can find
tuner: i2c i/o error: rc == -121 (should be 4). 

Las working version i tried was 2.6.11-rc2
Both 2.6.11-rc3-mm1 and Both 2.6.11-rc3-mm2 are not working.

If kernel conf is needed i can send.


Margus
-
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/

once more w/feeling

[Gil Lapidus]

Greetings,

On a K6-2 500MHz box.

kernel 2.4.28 boots _fine_.

kernel 2.6.9 displays "Loading " then PC resets.

Here's the .config filtered through grep ^C:

CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_SHMEM=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
CONFIG_X86_PC=y
CONFIG_MK6=y
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_PREEMPT=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=m
CONFIG_TOSHIBA=m
CONFIG_I8K=m
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_EDD=m
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PM=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=""
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_TOSHIBA=m
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
CONFIG_PCMCIA=m
CONFIG_PCMCIA_DEBUG=y
CONFIG_YENTA=m
CONFIG_CARDBUS=y
CONFIG_PD6729=m
CONFIG_I82092=m
CONFIG_I82365=m
CONFIG_TCIC=m
CONFIG_PCMCIA_PROBE=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_IDE_TASKFILE_IO=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_CMD640_ENHANCED=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_OPTI621=m
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
CONFIG_BLK_DEV_AMD74XX=y
CONFIG_BLK_DEV_ATIIXP=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_CY82C693=y
CONFIG_BLK_DEV_HPT34X=y
CONFIG_BLK_DEV_HPT366=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_NS87415=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
CONFIG_BLK_DEV_TRM290=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDE_CHIPSETS=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_SCSI_DPT_I2O=m
CONFIG_SCSI_SATA=y
CONFIG_SCSI_ATA_PIIX=y
CONFIG_SCSI_SATA_SX4=m
CONFIG_SCSI_SATA_SIS=m
CONFIG_SCSI_IPR=m
CONFIG_SCSI_QLA2XXX=y
CONFIG_IEEE1394=y
CONFIG_IEEE1394_OHCI1394=y
CONFIG_IEEE1394_RAWIO=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_TARGET_NOTRACK=m
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_PCI=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
CONFIG_S2IO=m
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_ASYNC=m

Re: 2.6-bk: cpu hotplug + preempt = smp_processor_id warnings galore

[Zwane Mwaikambo]

On Fri, 11 Feb 2005, Nathan Lynch wrote:

> With 2.6.11-rc3-bk7 on ppc64 I am seeing lots of smp_processor_id
> warnings whenever I hotplug cpus:
> 
> # echo 0 > /sys/devices/system/cpu/cpu1/online 
> cpu 1 (hwid 1) Ready to die...
> BUG: using smp_processor_id() in preemptible [0001] code:
> ksoftirqd/1/5
> caller is .ksoftirqd+0xbc/0x1f8
> Call Trace:
> [c000fffbbce0] [] 0x (unreliable)
> [c000fffbbd60] [c01c9f1c] .smp_processor_id+0x154/0x168
> [c000fffbbe20] [c005f414] .ksoftirqd+0xbc/0x1f8
> [c000fffbbed0] [c00764cc] .kthread+0x128/0x134
> [c000fffbbf90] [c0014248] .kernel_thread+0x4c/0x6c
> 
> I believe the above warning is caused by the local_softirq_pending
> call on a "foreign" cpu before ksoftirqd/1 has been stopped.  Looking
> at the code, I think this doesn't indicate a real bug, but it would be
> better if ksoftirqd didn't check local_softirq_pending after it's been
> kicked off its cpu, right?

How about;

Index: linux-2.6.11-rc3-mm2/kernel/softirq.c
===
RCS file: /home/cvsroot/linux-2.6.11-rc3-mm2/kernel/softirq.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 softirq.c
--- linux-2.6.11-rc3-mm2/kernel/softirq.c   11 Feb 2005 05:14:57 -  
1.1.1.1
+++ linux-2.6.11-rc3-mm2/kernel/softirq.c   12 Feb 2005 18:24:54 -
@@ -355,8 +355,12 @@ static int ksoftirqd(void * __bind_cpu)
set_current_state(TASK_INTERRUPTIBLE);
 
while (!kthread_should_stop()) {
-   if (!local_softirq_pending())
+   preempt_disable();
+   if (!local_softirq_pending()) {
+   preempt_enable_no_resched();
schedule();
+   preempt_disable();
+   }
 
__set_current_state(TASK_RUNNING);
 
@@ -364,14 +368,14 @@ static int ksoftirqd(void * __bind_cpu)
/* Preempt disable stops cpu going offline.
   If already offline, we'll be on wrong CPU:
   don't process */
-   preempt_disable();
if (cpu_is_offline((long)__bind_cpu))
goto wait_to_die;
do_softirq();
-   preempt_enable();
+   preempt_enable_no_resched();
cond_resched();
+   preempt_disable();
}
-
+   preempt_enable();
set_current_state(TASK_INTERRUPTIBLE);
}
__set_current_state(TASK_RUNNING);

> # echo 1 > /sys/devices/system/cpu/cpu1/online 
> BUG: using smp_processor_id() in preemptible [0001] code:
> swapper/0
> caller is .dedicated_idle+0x68/0x22c
> Call Trace:
> [c000fffafc50] [] 0x (unreliable)
> [c000fffafcd0] [c01c9f1c] .smp_processor_id+0x154/0x168
> [c000fffafd90] [c000f998] .dedicated_idle+0x68/0x22c
> [c000fffafe80] [c000fce8] .cpu_idle+0x34/0x4c
> [c000fffaff00] [c003a744] .start_secondary+0x10c/0x150
> [c000fffaff90] [c000bd28] .enable_64b_mode+0x0/0x28
> 
> Should ppc64 simply use _smp_processor_id() in its idle loop code
> (like i386)?

I would say so, it's definitely safe.

> If I online and offline cpus rapidly enough I can eventually get the
> following:
> 
> printk: 49 messages suppressed.
> BUG: using smp_processor_id() in preemptible [0001] code:
> events/3/1262
> caller is .cache_reap+0x21c/0x2b8
> Call Trace:
> [c000ed67bb90] [] 0x (unreliable)
> [c000ed67bc10] [c01c9f1c] .smp_processor_id+0x154/0x168
> [c000ed67bcd0] [c00938e8] .cache_reap+0x21c/0x2b8
> [c000ed67bda0] [c006f4bc] .worker_thread+0x230/0x310
> [c000ed67bed0] [c00764cc] .kthread+0x128/0x134
> [c000ed67bf90] [c0014248] .kernel_thread+0x4c/0x6c
> 
> And this will repeat over and over even after I stop hotplugging
> cpus...  from the same events thread so I think it's somehow gotten
> "stuck"?

Hmm this should be covered by the local_bh_disable() in softirq 
processing.
-
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: M7101

[Jean Delvare]

Hi,

> Will m7101.c be modified once quirks enabling the device?

m7101.c is for 2.4 kernels while the proposed quirk is to be merged into
2.6 kernels, so m7101.c will still be needed as is. That said, if
cleanups are made on the way to 2.6 and someone offers a patch that
ports these cleanups back to m7101.c, I'll be happy to apply it, of
course.

Thanks,
-- 
Jean Delvare
-
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: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

[Vojtech Pavlik]

On Sat, Feb 12, 2005 at 06:01:19PM +0100, Kenan Esau wrote:
> Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik: 
> > Hi!
> > 
> > I've reimplemented the Lifebook touchscreen driver using libps2 and
> > input, to make it short and fitting into the kernel drivers.
> > 
> > Please comment on code and test for functionality!
> > 
> > PS.: The driver should register two input devices. It doesn't yet,
> > since that isn't very straightforward in the psmouse framework.
> 
> First of all it's good to see lifebook-support integrated. 
> 
> I have tested your driver on my box but the initialization fails. Do you
> have hardware available for testing? 

No, none at all.

> As far as I can see the
> init-sequence is the one from Haralds xfree 3.3.6-driver. There is a
> reason why this sequence is not like that anymore in my driver.

OK.

> This
> sequence does not always work and there is not something like a "magic
> knock sequence".

You mean that the only needed bit is setting the resolution to '7'?

> The lifebook-touchscreen hardware is a little bit slow
> and it happens quite often that it does not understand a command that
> you send.

I don't believe this - the PS/2 protocol has handshakes for both sides,
so each side can slow down as much as it wants. PLUS, the clock is
driven by the device.

> This is the reason why you often have to send a command
> several times until the hardware understands... 
> Probably this was what was seen by Harald on the USB-bus and he just
> used this sequence.

USB?!

> Second thing is that I am not shure that it is a good idea to integrate
> the lbtouch-support into the psmouse-driver since there is no real way
> of deciding if the device you are talking to is REALLY a
> lifebook-touchsreen or not. 

All normal PS/2 mice will fail on the SETRES 7 command. That's an
obligation given in the spec.

> You have put the init-sequence for the hw into the
> lifebook_detect-function which is not correct since this not really a
> "detect" but a HW-init. 

Since based on the result of the commands it decides whether there is
something (first command would fail), and whether it is a Fujitsu
TouchScreen (the SETRES 7 command would fail), it is a detection.

> IMHO the driver should be standalone and the user should decide which
> driver he wants to use. As default the touchscreen-functionality will be
> disabled and only the quick-point device will work like a normal
> PS2-mouse.

If it cannot be probed for, I agree.

But I still hope it can be probed for. Almost every PS/2 device has a
method. Maybe it's not known yet, maybe the SETRES 7 command is enough,
but I believe there is one.

> I also don't think that it is useful to have two devices for the
> touchscreen. I assume you want to have one device for relative movements
> and one for the absolute ones!?

Definitely.

> But for the implementor in userspace (X,
> SDL,...) it will be easier if ALL events from this HW-device come via
> one device-node. 

I believe it's much easier the other way around. X now has a event-based
mouse driver, and it might be a good idea to use its options on the
touchpoint on the lifebook.

> I attached the current version of my driver here so people can also have
> a look at it. I didn't release this version on my homepage yet and the
> only difference between the released version an this one is that the
> y-axis is swapped. I did this since all input devices seem to have a
> common idea of where y=0 is and my driver was the only one where y was
> just the other way round.

I think the driver I sent has the same problem.

> One more thing I observed by inspecting your code is that your
> untouch-event will never happen. 

I'll take a look.

> I think my driver works and is clean enough for integration into the
> kernel. We can talk about integrating calls to libps2 instead of doing
> the stuff myself (I am a big fan of preventing code-duplication) but
> don't you think it would be more wise to use a driver which works (since
> the very early 2.6-days) and build upon that instead of trying to
> implement your own one from the scratch and using snippets from very old
> and obsolete code?

I did the rewrite mainly because the code I had from you was doing
everything in its own way and I remember it was quite hard to
persuade back then to use the already existing helpers for that.

I also didn't at all like the 'make every little check a function of its
own' way it was done.

Similarly I don't see a reason why to filter all the touch/button data
changes in the driver, when the input layer does that for you.

If those things get fixed (which is not the case in your attached
driver), I'll gladly accept it.

But then, it'll be pretty similar to what I sent you. You can take that
as my vision of how the driver should look, even if it doesn't work as
it is.

> And as far as I can see you don't even have access to the hardware!?!?

You're right. But I simply can't have all the hardware I've written

Re: How to disable slow agpgart in kernel config?

[Arjan van de Ven]

> agpgart: 58,1 frames
> nv_agp: 63,1 frames
> 
> Its a lot in Doom3.


hmm I wonder.. .could you collect lspci -vxxx settings for the AGP
device (lspci -vxxx gives you lots of devices, but only one is relevant)
in both cases, maybe the difference between the two shows something
useful...

-
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: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

[Dmitry Torokhov]

On Saturday 12 February 2005 12:01, Kenan Esau wrote:

> Second thing is that I am not shure that it is a good idea to integrate
> the lbtouch-support into the psmouse-driver since there is no real way
> of deciding if the device you are talking to is REALLY a
> lifebook-touchsreen or not. 
> 

I think Arjan's idea about using DMI could be very effective for this
particular touchscreen.

> I also don't think that it is useful to have two devices for the
> touchscreen. I assume you want to have one device for relative movements
> and one for the absolute ones!? But for the implementor in userspace (X,
> SDL,...) it will be easier if ALL events from this HW-device come via
> one device-node. 
> 

Why? These are separate, one might want to disable touchscreen and keep
quick-point or other way around.

> I think my driver works and is clean enough for integration into the
> kernel. We can talk about integrating calls to libps2 instead of doing
> the stuff myself (I am a big fan of preventing code-duplication) but
> don't you think it would be more wise to use a driver which works (since
> the very early 2.6-days) and build upon that instead of trying to
> implement your own one from the scratch and using snippets from very old
> and obsolete code?
> 

We need to get it integrated right away I think. There just too much stuff
in psmouse that shoudl be used (rate and resolution exported through sysfs,
timeout and resend handling, etc.)

Plus, in your current driver:

- MODULE_PARM is obsolete

- data_lock spinlock is either unneeded or may cause deadlocks since it is
  used in interrupt handler and the other places that are using it do not
  disable interrupts

- it is not necessary to suppress duplicate button events in the driver
  as the driver core will do that for you and it will make interrupt
  handler almost the same as Vojtech's. Btw, I don't think his handler
  has a problem - I would expect touchscreen to send anoter packet when
  finger leaves its surface so untouch will not be lost.

- using interruptible_sleep_on for delays is somewhat inelegant I think. 

- it needs some changes to compile with the latest version of serio.

-- 
Dmitry
-
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: How to disable slow agpgart in kernel config?

[Marcus Hartig]

Terence Ripperda wrote:
> I wouldn't expect even falling back to pci dma would have this big of an
> impact on 2d performance, but perhaps there's enough bus activity for
> this to happen. Marcus, can you verify that you're actually using
> agpgart in that situation? do you possibly have our XF86Config option
> set to nvagp only? (with IOMMU compiled in or agpgart loaded, our driver
> won't allow nvagp) you can verify whether agp is enabled with this
> command when our driver is loaded and X is started up:
No, IOMMU is now off, too. And I have always used nv_agp with:
Option  "NvAgp" "1"
If the nvidia driver detects the kernel agpgart, it doesn't load nv_agp 
with a big message in the kernel log.

I've just short tested it again:
Doom3 with medium standard settings in [EMAIL PROTECTED]:
agpgart: 58,1 frames
nv_agp: 63,1 frames
Its a lot in Doom3.
(Simple) 2D test [EMAIL PROTECTED] with x11perf --> http://www.marcush.de/bench/
Same gcc, xorg 6.8.2, 2.6.11-rc3-bk8 kernel, patched (minion.de) 6629 
nvidia drivers to run with newer 2.6.11-rcX kernel,... here was only 
nv_agp and agpgart the difference. In the past without an patched driver 
the same difference.

And again using agpgart with GNOME under X and moving this thunderbird 
mail window or other bigger ones like mozille or firefox over an 
gnome-terminal pulls/draws a ca. 5cm shadow like field slowly after the 
main window. It seems so not fast enough writing to the screen, when 
moving. With nv_agp its really faster and you do not see this.

Bad english... I know. ;)
Greetings,
Marcus
-
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.9 & 2.6.10 unresponsive to keyboard upon bootup

[Roey Katz]

Hello again Dmitry,
is there anything new about this issue? any fixes in the kernel?
If you want, I can continue doing the test/debug cycle as before.
Roey
On Wed, 12 Jan 2005, Dmitry Torokhov wrote:
Date: Wed, 12 Jan 2005 22:42:51 -0500
From: Dmitry Torokhov <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
Cc: Roey Katz <[EMAIL PROTECTED]>
Subject: Re: 2.6.9 & 2.6.10 unresponsive to keyboard upon bootup
On Wednesday 12 January 2005 10:19 pm, Roey Katz wrote:
Dmitry,
I have placed the results of the patched 2.6.9-rc2-bk2 kernel at the
following address:
   http://roey.freeshell.org/mystuff/kernel/*-20050112
As expected, the system was unresponsive to keyboard input.
And what if you do not compile PS/2 mouse support in? Is keyboard still
dead?
Regarding your mouse question:
How do I test the mouse if they keyboard does not work (is there some
way to output the contents of /dev/psaux on startup? I'm not sure anymore
what file the mouse data appears in, too)
Install GPM and try moving your mouse after booting into runlevel 3 -
if cursor moves mouse works.
--
Dmitry
-
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: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

[Arjan van de Ven]

On Sat, 2005-02-12 at 18:01 +0100, Kenan Esau wrote:

> Second thing is that I am not shure that it is a good idea to integrate
> the lbtouch-support into the psmouse-driver since there is no real way
> of deciding if the device you are talking to is REALLY a
> lifebook-touchsreen or not. 
...
> IMHO the driver should be standalone and the user should decide which
> driver he wants to use. As default the touchscreen-functionality will be
> disabled and only the quick-point device will work like a normal
> PS2-mouse.

I just want to point out that this is a problem for distributions and
for not-so-technical users.

Is there *really*  no way to know if you're on a lifebook? Can't you use
say the DMI identification mechanism to find this out ? If so, I think
integrating into the regular driver very much is the right thing to
do... it makes things JustWork(tm) for users without any need for manual
configuration (which also makes distribution makers happy).




-
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: ckrm-e17

[Shailabh Nagar]

Peter Williams wrote:
Shailabh Nagar wrote:
At line 3887 of cpu.ckrm-e17.v10.patch you add the line:
set_task_cpu(p,this_cpu);
to the middle of the function wake_up_new_task() resulting in the 
following code:

} else {
this_rq = cpu_rq(this_cpu);
/*
 * Not the local CPU - must adjust timestamp. This should
 * get optimised away in the !CONFIG_SMP case.
 */
p->sdu.ingosched.timestamp = (p->sdu.ingosched.timestamp - 
this_rq->timestamp_last_tick)
+ rq->timestamp_last_tick;
set_task_cpu(p,this_cpu);
__activate_task(p, rq);
if (TASK_PREEMPTS_CURR(p, rq))
resched_task(rq->curr);

schedstat_inc(rq, wunt_moved);
/*
 * Parent and child are on different CPUs, now get the
 * parent runqueue to update the parent's 
->sdu.ingosched.sleep_avg:
 */
task_rq_unlock(rq, );
this_rq = task_rq_lock(current, );
}

where "rq" has been set by the return value of "task_rq_lock(p, 
)", and the test "(cpu == this_cpu)" has failed with "cpu" set to 
"task_cpu(p)".  The result of this when the CKRM CPU code is not 
configured into the build is that "p" will be queued on a runqueue that 
is not in agreement with "p->thread_info->cpu" which in turn will lead 
to future use of "task_rq_lock()" locking the wrong run queue and 
eventually triggering some form of race condition.

If CKRM CPU is configured into the build the results are less drastic as 
they only result in "nr_running" being incremented for the wrong run 
queue.  However, even this will have adverse scheduling effects as it 
will probably confuse the load balancing code.  Another potentially 
confusing thing with this code (when CKRM CPU is configured in) is that 
__activate_task() does NOT queue "p" on "rq" but on the queue found by 
the call "get_task_lrq(p)".

The recommended fix for this problem would be to withdraw the:
set_task_cpu(p,this_cpu);
Peter
Thanks for finding that out. Will confirm and fix in the next release.
PS I reported this to the ckrm-tech list 5 days ago but it was ignored.
Other project priorities prevented us from responding sooner. There's no 
call to jump to conclusions.

-- Shailabh
-
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/

Warnings when compiling apm

[Rogério Brito]

Hi there.

For many kernel releases, including 2.6.11-rc3-mm2, I ve been getting
warnings like the following when compiling the apm driver:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  CC  arch/i386/kernel/apm.o
arch/i386/kernel/apm.c: In function `suspend':
arch/i386/kernel/apm.c:1191: warning: `pm_send_all' is deprecated (declared at 
include/linux/pm.h:126)
arch/i386/kernel/apm.c:1241: warning: `pm_send_all' is deprecated (declared at 
include/linux/pm.h:126)
arch/i386/kernel/apm.c: In function `check_events':
arch/i386/kernel/apm.c:1357: warning: `pm_send_all' is deprecated (declared at 
include/linux/pm.h:126)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Unfortunately, I read the code in pm.h and apm.c to see if I could fix the
problem, but I am just not sure if killing the calls to pm_send_all is
something that should be done or not (the function currently is just an
inline function that returns 0).

Similar things can be said about pm_register, pm_unregister,
pm_unregister_all and pm_send.



Thanks for any guidance, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

[Kenan Esau]

Am Freitag, den 11.02.2005, 21:10 +0100 schrieb Vojtech Pavlik: 
> Hi!
> 
> I've reimplemented the Lifebook touchscreen driver using libps2 and
> input, to make it short and fitting into the kernel drivers.
> 
> Please comment on code and test for functionality!
> 
> PS.: The driver should register two input devices. It doesn't yet,
> since that isn't very straightforward in the psmouse framework.

First of all it's good to see lifebook-support integrated. 

I have tested your driver on my box but the initialization fails. Do you
have hardware available for testing? As far as I can see the
init-sequence is the one from Haralds xfree 3.3.6-driver. There is a
reason why this sequence is not like that anymore in my driver. This
sequence does not always work and there is not something like a "magic
knock sequence". The lifebook-touchscreen hardware is a little bit slow
and it happens quite often that it does not understand a command that
you send. This is the reason why you often have to send a command
several times until the hardware understands... 
Probably this was what was seen by Harald on the USB-bus and he just
used this sequence.

Second thing is that I am not shure that it is a good idea to integrate
the lbtouch-support into the psmouse-driver since there is no real way
of deciding if the device you are talking to is REALLY a
lifebook-touchsreen or not. 

You have put the init-sequence for the hw into the
lifebook_detect-function which is not correct since this not really a
"detect" but a HW-init. 

IMHO the driver should be standalone and the user should decide which
driver he wants to use. As default the touchscreen-functionality will be
disabled and only the quick-point device will work like a normal
PS2-mouse.

I also don't think that it is useful to have two devices for the
touchscreen. I assume you want to have one device for relative movements
and one for the absolute ones!? But for the implementor in userspace (X,
SDL,...) it will be easier if ALL events from this HW-device come via
one device-node. 

I attached the current version of my driver here so people can also have
a look at it. I didn't release this version on my homepage yet and the
only difference between the released version an this one is that the
y-axis is swapped. I did this since all input devices seem to have a
common idea of where y=0 is and my driver was the only one where y was
just the other way round.

One more thing I observed by inspecting your code is that your
untouch-event will never happen. 

I think my driver works and is clean enough for integration into the
kernel. We can talk about integrating calls to libps2 instead of doing
the stuff myself (I am a big fan of preventing code-duplication) but
don't you think it would be more wise to use a driver which works (since
the very early 2.6-days) and build upon that instead of trying to
implement your own one from the scratch and using snippets from very old
and obsolete code?

And as far as I can see you don't even have access to the hardware!?!?


Greetings 


Kenan
diff -uprN -X dontdiff linux-2.6.11-rc3-vanilla/drivers/input/touchscreen/Kconfig linux-2.6.11-rc3-lbtouch/drivers/input/touchscreen/Kconfig
--- linux-2.6.11-rc3-vanilla/drivers/input/touchscreen/Kconfig	2004-12-24 22:34:45.0 +0100
+++ linux-2.6.11-rc3-lbtouch/drivers/input/touchscreen/Kconfig	2005-02-12 16:52:27.0 +0100
@@ -35,3 +35,10 @@ config TOUCHSCREEN_GUNZE
 	  To compile this driver as a module, choose M here: the
 	  module will be called gunze.
 
+
+config TOUCHSCREEN_LBTOUCH
+	tristate "Lifebook touchscreen"
+	depends on INPUT && INPUT_TOUCHSCREEN && SERIO
+	help
+	  Say Y here if you have got a Fujitsu-Siemens Lifebook
+	  B-Series and want to be able to use its touchscreen.
diff -uprN -X dontdiff linux-2.6.11-rc3-vanilla/drivers/input/touchscreen/lbtouch.c linux-2.6.11-rc3-lbtouch/drivers/input/touchscreen/lbtouch.c
--- linux-2.6.11-rc3-vanilla/drivers/input/touchscreen/lbtouch.c	1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11-rc3-lbtouch/drivers/input/touchscreen/lbtouch.c	2005-02-12 16:52:26.0 +0100
@@ -0,0 +1,603 @@
+/*
+ * $Id: lbtouch.c,v 1.3 2004/05/17 17:50:00 conan Exp $
+ *
+ *  Copyright (c) 2000-2004 Kenan Esau
+ */
+
+/*
+ * Lifebook touchscreen driver for Linux
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, 

linux-2.6.11-rc3 and isdn mppp

[Christian Heim]

Well, i have to setup ISDN here at home, and wanted to use both channels.
I am able to add the second channel, but then the kernel (at least i think) 
starts to complain.

>17:36:22 kraftwerk Badness in local_bh_enable at kernel/softirq.c:140
>17:36:22 kraftwerk [] local_bh_enable+0x71/0x80
>17:36:22 kraftwerk [] isdn_ppp_xmit+0xe7/0x7d0
>17:36:22 kraftwerk [] isdn_net_xmit+0x184/0x1d0
>17:36:22 kraftwerk [] ip_nat_cheat_check+0x28/0x40 [iptable_nat]
>17:36:22 kraftwerk [] isdn_net_start_xmit+0x284/0x2a0
>17:36:22 kraftwerk [] dev_queue_xmit_nit+0xeb/0xf0
>17:36:22 kraftwerk [] nat_packet+0x84/0xb0 [iptable_nat]
>17:36:22 kraftwerk [] qdisc_restart+0x60/0x150
>17:36:22 kraftwerk [] dev_queue_xmit+0x165/0x1f0
>17:36:22 kraftwerk [] neigh_connected_output+0x87/0xd0
>17:36:22 kraftwerk [] ip_finish_output2+0xc9/0x1b0
>17:36:22 kraftwerk [] ip_finish_output2+0x0/0x1b0
>17:36:22 kraftwerk [] nf_hook_slow+0xb2/0xf0
>17:36:22 kraftwerk [] ip_finish_output2+0x0/0x1b0
>17:36:22 kraftwerk [] ip_forward_finish+0x0/0x40
>17:36:22 kraftwerk [] ip_finish_output+0x1da/0x1e0
>17:36:22 kraftwerk [] ip_finish_output2+0x0/0x1b0
>17:36:22 kraftwerk [] ip_forward_finish+0x0/0x40
>17:36:22 kraftwerk [] ip_forward_finish+0x19/0x40
>17:36:22 kraftwerk [] nf_hook_slow+0xb2/0xf0
>17:36:22 kraftwerk [] ip_forward_finish+0x0/0x40
>17:36:22 kraftwerk [] ip_forward+0x17a/0x200
>17:36:22 kraftwerk [] ip_forward_finish+0x0/0x40
>17:36:22 kraftwerk [] ip_rcv_finish+0x0/0x220
>17:36:22 kraftwerk [] ip_rcv_finish+0x199/0x220
>17:36:22 kraftwerk [] nf_iterate+0x72/0xb0
>17:36:22 kraftwerk [] ip_rcv_finish+0x0/0x220
>17:36:22 kraftwerk [] nf_hook_slow+0xb2/0xf0
>17:36:22 kraftwerk [] ip_forward_finish+0x0/0x40
>17:36:22 kraftwerk [] ip_forward+0x17a/0x200
>17:36:22 kraftwerk [] ip_forward_finish+0x0/0x40
>17:36:22 kraftwerk [] ip_rcv_finish+0x0/0x220
>17:36:22 kraftwerk [] ip_rcv_finish+0x199/0x220
>17:36:22 kraftwerk [] nf_iterate+0x72/0xb0
>17:36:22 kraftwerk [] ip_rcv_finish+0x0/0x220
>17:36:22 kraftwerk [] nf_hook_slow+0xb2/0xf0
>17:36:22 kraftwerk [] ip_rcv_finish+0x0/0x220
>17:36:22 kraftwerk [] ip_rcv+0x362/0x400
>17:36:22 kraftwerk [] ip_rcv_finish+0x0/0x220
>17:36:22 kraftwerk [] netif_receive_skb+0x119/0x170
>17:36:22 kraftwerk [] alloc_skb+0x32/0xd0
>17:36:22 kraftwerk [] rtl8139_rx+0x18d/0x310
>17:36:22 kraftwerk [] rtl8139_poll+0x41/0xc0
>17:36:22 kraftwerk [] net_rx_action+0x61/0xe0
>17:36:22 kraftwerk [] __do_softirq+0x79/0x90
>17:36:22 kraftwerk [] do_softirq+0x41/0x50
>17:36:22 kraftwerk ===
>17:36:22 kraftwerk [] do_IRQ+0x5f/0xa0
>17:36:22 kraftwerk [] common_interrupt+0x1a/0x20
>17:36:22 kraftwerk [] default_idle+0x23/0x30
>17:36:22 kraftwerk [] cpu_idle+0x48/0x60
>17:36:22 kraftwerk [] start_kernel+0x14d/0x190
>17:36:22 kraftwerk [] unknown_bootoption+0x0/0x1b0

I'm using the vanilla-2.6.11-rc3 sources with the following config:
>CONFIG_PPP=y
>CONFIG_PPP_MULTILINK=y
>CONFIG_PPP_FILTER=y
># CONFIG_PPP_ASYNC is not set
>CONFIG_PPP_SYNC_TTY=y
>CONFIG_PPP_DEFLATE=y
>CONFIG_PPP_BSDCOMP=y
>CONFIG_PPPOE=y
># ISDN subsystem
>CONFIG_ISDN=y
># Old ISDN4Linux
>CONFIG_ISDN_I4L=y
>CONFIG_ISDN_PPP=y
>CONFIG_ISDN_PPP_VJ=y
>CONFIG_ISDN_MPP=y
>CONFIG_IPPP_FILTER=y
>CONFIG_ISDN_PPP_BSDCOMP=y
># CONFIG_ISDN_AUDIO is not set
># ISDN feature submodules
># CONFIG_ISDN_DRV_LOOP is not set
># CONFIG_ISDN_DIVERSION is not set
># ISDN4Linux hardware drivers
>CONFIG_ISDN_DRV_HISAX=m
># CONFIG_ISDN_DRV_TPAM is not set
># CONFIG_ISDN_CAPI is not set

The connection is been established with isdn4k-utils-3.2_p1.

And again this only happens if I add a second link to the master device!

Hope anybody could help me

With kind regards

Christian Heim
-
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.10 thru 2.6.11-rc3 hang

[Gregory Davis]

This is probably an isolated incident, but I am having kernel hangs using
2.6.10 thru 2.6.11-rc3.  I have tried all different patchsets (mm, ck, cko),
and all produce the same behavior.  2.6.8.1 does not produce the behavior.
Basically, after a few minutes, the kernel hangs, and interrupts are
apparently not working as the keyboard leds don't respond anymore.  I
recently swapped out a cdrom for a dvdrom drive, and was able to use it fine
for a while with ck4 patched to 2.6.10.  Then I got gutsy and tried the mm
patch for 2.6.10, to start using reiser4.  That was when the kernel started
doing this hanging.  One surefire way to trigger a hang is to start a dvd
with mplayer:  the dvd reads the first few frames of any dvd, then hang;
however, hangs happen randomly otherwise.  I am running KDM as a login
manager, and X obviously when this happens, but without DRI.  I also have
tried going back to vanilla kernel, reformatting my drive to reiserfs3, and
an otherwise previous state, but the kernel still hangs.  I even unplugged
lots of stuff inside the PC to see if it was a current draw issue, but that
had no effect; besides 2.6.8.1 works (although X got really really really
slow and jerky for some reason).  I made sure all the CFLAGS were unset
before compiling, and this is with gcc-3.4.1, as have been the past umpteen
kernel builds for me.  I think I screwed up my system, or triggered some
obscure bug, but please send any ideas my way, and CC [EMAIL PROTECTED] as
I am not subscribed to the list.

Thanks,
Greg Davis


-
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.11-rc3-bk9 hangs hard my laptop

[Alessandro Suardi]

On Sat, 12 Feb 2005 15:49:05 +0100, Alessandro Suardi
<[EMAIL PROTECTED]> wrote:
> Dell Latitude C640, PIV @1.8Ghz, 1GB RAM, uptodate FC2
> 
> -bk7 (which I currently rebooted in) is okay.
> -bk9 at first try got me to the login prompt, logged in, ran startx...
>  frozen with the black background before seeing anything.
> 
> Second try hung well before, at the point where it switches the
>  radeonfb on.
> 
> Only cure is to keep the power button pressed for 10".
> 
> Will try building -bk8 (which is currently running on my
>  old desktop K7-800) and report...

-bk8 which I'm now booted in is also OK, so something
 broke between -bk8 and -bk9... attached .config and
 /var/log/messages from the boot in -bk8 and the one
 in -bk9 which succeeded before hanging on startx.

Thanks in advance,

--alessandro

  "There is no distance that I don't see
  I do have a will - No limit to my reach"
  
(Wallflowers, "Empire In My Mind")


config-2611rc3bk9.gz
Description: GNU Zip compressed data


messages-2611rc3bk8.gz
Description: GNU Zip compressed data


messages-2611rc3bk9.gz
Description: GNU Zip compressed data

Re: /proc/*/statm, exactly what does "shared" mean?

[Hugh Dickins]

On Sat, 12 Feb 2005, Richard F. Rebel wrote:
> 
> That said, many mod_perl users are *VERY* interested in being able to
> detect and observe how "shared" our forked children are.  Shared meaning
> private pages shared with children (copy on write).  Is it even possible
> to do this in 2.6 kernels?  If so, any pointers would be very helpful.

Not in any of the vanilla kernels.

Mauricio has a /proc//smaps patch, in which he returns to looking
at every pte slot of every vma of the process as /proc//statm did
in 2.4.  I suggest you ask him offline for his latest version (the last
I saw did not include support for 2.6.11's pud level; and looped in an
inefficient way, repeatedly locating, mapping and unmapping the page
table for each pte slot - needs refactoring into pgd_range, pud_range,
pmd_range, pte_range levels like 2.4's statm).

It wouldn't be hard to take his framework (before or after improvements),
or the 2.4 proc_pid_statm framework, and modify that to give you the
information you're looking for.  But I doubt that the resulting patch
would be accepted into a vanilla kernel - there's no end to the kinds
of numbers that different people might want to see.

I wonder how important swapping is in your case.  If it's an
exceptional case that you can ignore, then a "private shared"
entry would be identified by code something like:

if (pte_present(pte)) {
pfn = pte_pfn(pte);
if (pfn_valid(pfn)) {
page = pfn_to_page(pfn);
if (PageAnon(page) && page_mapcount(page) > 1)
private_shared++;
}
}

But if swap use is significant, then it gets rather more complicated:
a present page, even when its mapcount is 1, might still be shared with
other processes, from which which the pte has been unmapped; and where
the pte is not present, there may be a swap entry shared with others.
It can be worked out, but awkward and more than a few lines of code.

Hugh
-
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: COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6

[Eric W. Biederman]

Werner Almesberger <[EMAIL PROTECTED]> writes:

> Eric W. Biederman wrote:
> > Actually this is trivial to do by using a file in initramfs.
> > If we need something in a well defined format anyway.
> 
> Yes, constructing an additional initramfs, or modifying an existing
> one to hold such data is certainly a possibility.
> 
> I think there are mainly three choices:
>  1) the command line
>  2) an initramfs
>  3) some other, yet to be defined data structure
> 
> 1) is relatively easy to do, but leads to more little parsers and
> doesn't scale too well. 2) scales well but has a relatively high
> overhead (constructing/scanning a cpio archive, etc., particularly
> for items needed early in the boot process), and does not work too
> well for discontiguous data structures. 

There is certainly an issue with reading it early.  But constructing
an additional cpio and sticking it into the initrd block is fairly
simple.  For detecting devices especially in the case that takes
a while that isn't something we need to do early
in the boot process.

> 3) is of course what we should try to avoid :-)

Well the data structure is still yet to be defined.  The
question you raised is how to pass it.
 
> So far, I also think that using an initramfs, or at least
> something that looks like one, even if not normally used as such,
> is the thing to try first.

Something like that.I have yet to see a even a proof of concept
of the idea of passing device information, to clean up probes.
Nor am I quite certain if it is really useful.  But when it
happens I am sure we can cope.

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] kmalloc() bug in pci-dma.c

[James Bottomley]

On Fri, 2005-02-11 at 17:24 -0800, Venkatesh Pallipadi wrote:
> After burning my fingers with a similar mistake in one of the patches 
> that I am working on, I did a quick grep to find out all faulty kmalloc() 
> calls and found this.
> 
> dma_declare_coherent_memory() is calling kmalloc with wrong arguments. 
> Attached patch fixes this.

Oh Wow, did I really do that ... brown paper bag time for me, I suppose.

> Please apply.

Andrew, please put it in.

James


-
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.11-rc3-mm2

[Henning Rohde]

Hi,

Yuval Tanny wrote:
> Andrew Morton wrote:
>>cachefs-filesystem.patch
>>  CacheFS filesystem
> ...

as you mention cachefs - know what's the status of supporting nfs?
Or is the project as dead as the mailing-list?

Is there any whole-in-one patch relative to vanilla-sources, 
at best including nfs-support?


Thanks in advance,

 Henning Rohde

-
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: COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6

[Werner Almesberger]

Eric W. Biederman wrote:
> Actually this is trivial to do by using a file in initramfs.
> If we need something in a well defined format anyway.

Yes, constructing an additional initramfs, or modifying an existing
one to hold such data is certainly a possibility.

I think there are mainly three choices:
 1) the command line
 2) an initramfs
 3) some other, yet to be defined data structure

1) is relatively easy to do, but leads to more little parsers and
doesn't scale too well. 2) scales well but has a relatively high
overhead (constructing/scanning a cpio archive, etc., particularly
for items needed early in the boot process), and does not work too
well for discontiguous data structures. 3) is of course what we
should try to avoid :-)

So far, I also think that using an initramfs, or at least
something that looks like one, even if not normally used as such,
is the thing to try first.

- Werner

-- 
  _
 / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.net//
-
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: [RFC 2.6.11-rc2-mm2 7/7] mm: manual page migration -- sys_page_migrate

[Andi Kleen]

On Sat, Feb 12, 2005 at 07:34:32AM -0500, Arjan van de Ven wrote:
> On Fri, 2005-02-11 at 19:26 -0800, Ray Bryant wrote:
> > This patch introduces the sys_page_migrate() system call:
> > 
> > sys_page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);
> 
> are you really sure you want to expose nodes to userspace via an ABI
> this solid and never changing? To me that feels somewhat like too much
> of an internal thing to expose that will mean that those internals are
> now set in stone due to the interface...

They're already exposed through mbind/set_mempolicy/get_mempolicy and sysfs
of course.

-Andi
-
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.11-rc3-bk9 hangs hard my laptop

[Alessandro Suardi]

Dell Latitude C640, PIV @1.8Ghz, 1GB RAM, uptodate FC2

-bk7 (which I currently rebooted in) is okay.
-bk9 at first try got me to the login prompt, logged in, ran startx...
 frozen with the black background before seeing anything.

Second try hung well before, at the point where it switches the
 radeonfb on.

Only cure is to keep the power button pressed for 10".

Will try building -bk8 (which is currently running on my
 old desktop K7-800) and report...

--alessandro

  "There is no distance that I don't see
  I do have a will - No limit to my reach"
  
(Wallflowers, "Empire In My Mind")
-
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: /proc/*/statm, exactly what does "shared" mean?

[Richard F. Rebel]

Hugh,

Thank you immensely for answering this so clearly.  Although it leaves
me at a short end, I am grateful I no longer have to bang my head in
this direction any further.  I have wasted a HUGE amount of time in
recent months trying to figure out why different kernel versions caused
my applications memory footprint to change so.

That said, many mod_perl users are *VERY* interested in being able to
detect and observe how "shared" our forked children are.  Shared meaning
private pages shared with children (copy on write).  Is it even possible
to do this in 2.6 kernels?  If so, any pointers would be very helpful.

Thanks again,

Richard F. Rebel

On Sat, 2005-02-12 at 13:06 +, Hugh Dickins wrote:
> On Fri, 11 Feb 2005, Richard F. Rebel wrote:
> > 
> > I can't seem to find clear documentation about the 'share' column
> > from /proc//statm.
> > 
> > Does this include pages that are shared with forked children marked as
> > copy-on-write?
> > 
> > Does this only reflect libraries that are dynamically loaded?  What
> > about shared memory segments/mmaps (ala shmat or mmmap)?
> > 
> > If there is a place where I might find documentation that is more clear
> > beyond the proc.txt in the kernel docs and then man pages for procfs,
> > I'd welcome a pointer.
> 
> You may not be entirely happy with this answer.
> It is a count of "pages of the process" which are "shared" in some sense.
> But precisely what that means has changed from time to time: depending on
> our perception of what we can safely afford the overhead of counting.
> 
> You may want to look at fs/proc proc_pid_statm() source for the release
> of interest, and follow that back to see exactly what is being counted.
> 
> Throughout 2.4 (and 2.2 too I think) it was the count of those pages
> instantiated in the process address space which currently have a page
> count greater than 1.  That would include private pages shared with
> forked children, pages from the pagecache (including pages mapped
> from executable or library or shared memory or file mmap), those
> private pages which currently have swap allocated (so they're also
> in the swapcache), and any pages which transitorily have page count
> raised for whatever reason (they'd likely already be in one of the
> above categories).  A ragbag of meanings, but that's all you can
> get from looking at page count.
> 
> Counting up that not very meaningful number, at frequent intervals
> on large process address spaces, is a waste of valuable time.
> 
> From 2.5.37 to 2.6.9, it's the total extent of file-backed areas
> (file including executable or library or shared memory) in the
> process address space: a total extent (in pagesize units),
> not a count of instantiated pages.  Much quicker to calculate.
> 
> But there were complaints about that, and a need to revert from
> total extent to count of instantiated pages.
> 
> From 2.6.10 onwards, for the foreseeable future, it is the count
> of those pages instantiated in the process address space which are
> shared with a file (including executable or library or shared memory)
> i.e. those pages which are not anonymous, not private.  That count
> does not include private pages shared with forked children, nor
> does it include private pages which happen to have swap allocated.
> 
> Hugh
> -
> 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/
-- 
Richard F. Rebel <[EMAIL PROTECTED]>
WhenU.com


signature.asc
Description: This is a digitally signed message part

RE: Using O_DIRECT for file writing in a kernel module

[Hanson, Jonathan M]

On Fri, 2005-02-11 at 17:58 -0700, Hanson, Jonathan M wrote:
>   I'm trying to write to a file with the O_DIRECT flag from a
> kernel module in a 2.4 series of kernel on x86 hardware. I've learned
> that the O_DIRECT flag requires that the amount of data written and
the
> file offset pointer must be multiples of the underlying "block size."


ehhh why are you writing to a file from a kernel module? That's
generally considered a really bad idea

[Jon M. Hanson] For what I'm doing I have no other choice but to write
to a file from my kernel module.

-
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.11-rc3: intel8x0 alsa outputs no sound

[Alessandro Suardi]

On Sat, 12 Feb 2005 01:23:19 +0100, Tomas Szepe <[EMAIL PROTECTED]> wrote:
> On Feb-05 2005, Sat, 16:06 -0600
> Narayan Desai <[EMAIL PROTECTED]> wrote:
> 
> > Try muting the headphone jack sense control with alsamixer. I had the
> > same problem with rc2 on my t41p, and that solved it.
> 
> This doesn't help on a T40p, I'm afraid.
> No sound in 2.6.11-rc3 with snd-intel8x0.ko, worked all ok in 2.6.10.

Sorry to jump late in the thread - apologies in advance if
 this info has already been provided...

On my Dell C640, onboard sound has been working forever,
 but it's a while since I have it in-kernel:

[EMAIL PROTECTED] root]# dmesg | grep -i intel8
intel8x0_measure_ac97_clock: measured 49438 usecs
intel8x0: clocking to 48000
[EMAIL PROTECTED] root]# grep -i 8X0 /usr/src/linux/.config
CONFIG_SND_INTEL8X0=y
CONFIG_SND_INTEL8X0M=m
[EMAIL PROTECTED] root]# uname -a
Linux incident 2.6.11-rc3-bk7 #1 Fri Feb 11 10:12:09 CET 2005 i686
i686 i386 GNU/Linux

--alessandro
-
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: COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6

[Eric W. Biederman]

Werner Almesberger <[EMAIL PROTECTED]> writes:

> Andi Kleen wrote:
> > It's dependent on the architecture already. I would like to enable
> > it on i386/x86-64 because the kernel command line is often used
> > to pass parameters to installers, and having a small limit there
> > can be awkward.
> 
> Something to keep in mind when extending the command line is that
> we'll probably need a mechanism for passing additional (and
> possibly large) data blocks from the boot loader soon.
> 
> The reason for this is that, if booting through kexec, it would be
> attractive to pass device scan results, so that the second kernel
> doesn't have to repeat the work. As an obvious extension, anyone
> who wants to boot *quickly* could also pass such data from
> persistent storage without actually performing the device scan at
> all when the machine is booted.
> 
> The command line may be suitable for this, but to allow for passing
> a lot of data, its place in memory should perhaps just be reserved,
> at least until the system has passed initialization, without trying
> to copy it to a "safe" place early in kernel startup.

Actually this is trivial to do by using a file in initramfs.
If we need something in a well defined format anyway.

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: [RFC UPDATE PATCH] add wait_event_*_lock() functions and comments

[Sergey Vlasov]

On Sat, 12 Feb 2005 12:38:26 +0100 Arnd Bergmann wrote:

> On Freedag 11 Februar 2005 20:55, Nishanth Aravamudan wrote:
> 
> > + * If the macro name contains:
> > + * lock, then @lock should be held before calling wait_event*().
> > + * It is released before sleeping and grabbed after
> > + * waking, saving the current IRQ mask in @flags. This lock
> > + * should also be held when changing any variables
> > + * affecting the condition and when waking up the process.
> 
> Hmm, I see two problems with that approach:
> 
> 1. It might lead to people not thinking about their locking order
> thoroughly if you introduce a sleeping function that is called with
> a spinlock held. Anyone relying on that lock introduces races because
> it actually is given up by the macro. I'd prefer it to be called 
> without the lock and then have it acquire the lock only to check the
> condition, e.g:
> 
> #define __wait_event_lock(wq, condition, lock, flags)  \
> do {   \
>DEFINE_WAIT(__wait);\
>\
>for (;;) {  \
>prepare_to_wait(, &__wait, TASK_UNINTERRUPTIBLE);\
>spin_lock_irqsave(lock, flags); \
>if (condition)  \
>break;  \
>spin_unlock_irqrestore(lock, flags);\
>schedule(); \
>}   \
>spin_unlock_irqrestore(lock, flags);\
>finish_wait(, &__wait);  \
> } while (0)

But in this case the result of testing the condition becomes useless
after spin_unlock_irqrestore - someone might grab the lock and change
things.   Therefore the calling code would need to add a loop around
wait_event_lock - and the wait_event_* macros were added precisely to
encapsulate such a loop and avoid the need to code it manually.


pgpWr8tJ7VL0F.pgp
Description: PGP signature

Re: [PATCH, new ACPI driver] new sony_acpi driver

[Jean Delvare]

> Based on feedback from Jean Delvare and Pekka Enberg, here is an
> updated version.

Works for me (Vaio PCG-GR214EP). Tested with 2.6.11-rc3-bk8.

I then enabled the debug mode. I couldn't find anything relevant WRT
what each additional file is supposed to do, but I still have noticed a
number of things you might be interested in.

ctr doesn't seem to affect the contrast for me. I also noticed that the
value seems to be stored on 8 bits. Higher bits are ignored (e.g. write
300, read 44). Default value is 64.

cmi behaves strangely. Its default value is 0. Whatever I write to it
(including 0), next read returns 131.

pbr seems to be stored on 4 bits. Higher bits are ignored (e.g. write
20, read 4). Default value is 0.

csxb is the dangerous one. Default 0. Writing 41 to it deadlocked my
system. Writing 42 changed pbr from 0 to 8 as a side effect. Each write
generates an error in the logs:
  sony_acpi: acpi_evaluate_object failed

cmi and csxb are reset to 0 on sony_acpi module cycling. brightness, ctr
and pbr are preserved.

Hope that helps. Let me know if you want me to test specific things.
-- 
Jean Delvare
-
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: [RFC] Reliable video POSTing on resume

[Bodo Eggert]

Kendall Bennett <[EMAIL PROTECTED]> wrote:

> Laptops are a little different as they will make calls from the Video
> BIOS into the system BIOS, so you need to make sure that the system BIOS
> is also available in the execution environment.

Any video BIOS (especially EGA) may call system BIOS functions, e.g. via the
old INT10 (which will get copied to INT42).

HGC and VGA are in the system BIOS. They don't need magic, but they need to
be initialized on order to keep the monitor from burning. On the other hand,
they used to be initialised correctly.
-
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: /proc/*/statm, exactly what does "shared" mean?

[Hugh Dickins]

On Fri, 11 Feb 2005, Richard F. Rebel wrote:
> 
> I can't seem to find clear documentation about the 'share' column
> from /proc//statm.
> 
> Does this include pages that are shared with forked children marked as
> copy-on-write?
> 
> Does this only reflect libraries that are dynamically loaded?  What
> about shared memory segments/mmaps (ala shmat or mmmap)?
> 
> If there is a place where I might find documentation that is more clear
> beyond the proc.txt in the kernel docs and then man pages for procfs,
> I'd welcome a pointer.

You may not be entirely happy with this answer.
It is a count of "pages of the process" which are "shared" in some sense.
But precisely what that means has changed from time to time: depending on
our perception of what we can safely afford the overhead of counting.

You may want to look at fs/proc proc_pid_statm() source for the release
of interest, and follow that back to see exactly what is being counted.

Throughout 2.4 (and 2.2 too I think) it was the count of those pages
instantiated in the process address space which currently have a page
count greater than 1.  That would include private pages shared with
forked children, pages from the pagecache (including pages mapped
from executable or library or shared memory or file mmap), those
private pages which currently have swap allocated (so they're also
in the swapcache), and any pages which transitorily have page count
raised for whatever reason (they'd likely already be in one of the
above categories).  A ragbag of meanings, but that's all you can
get from looking at page count.

Counting up that not very meaningful number, at frequent intervals
on large process address spaces, is a waste of valuable time.

>From 2.5.37 to 2.6.9, it's the total extent of file-backed areas
(file including executable or library or shared memory) in the
process address space: a total extent (in pagesize units),
not a count of instantiated pages.  Much quicker to calculate.

But there were complaints about that, and a need to revert from
total extent to count of instantiated pages.

>From 2.6.10 onwards, for the foreseeable future, it is the count
of those pages instantiated in the process address space which are
shared with a file (including executable or library or shared memory)
i.e. those pages which are not anonymous, not private.  That count
does not include private pages shared with forked children, nor
does it include private pages which happen to have swap allocated.

Hugh
-
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: [RFC 2.6.11-rc2-mm2 7/7] mm: manual page migration -- sys_page_migrate

[Arjan van de Ven]

On Fri, 2005-02-11 at 19:26 -0800, Ray Bryant wrote:
> This patch introduces the sys_page_migrate() system call:
> 
> sys_page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);

are you really sure you want to expose nodes to userspace via an ABI
this solid and never changing? To me that feels somewhat like too much
of an internal thing to expose that will mean that those internals are
now set in stone due to the interface...


-
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: [RFC UPDATE PATCH] add wait_event_*_lock() functions and comments

[Arnd Bergmann]

On Freedag 11 Februar 2005 20:55, Nishanth Aravamudan wrote:

> + * If the macro name contains:
> + *   lock, then @lock should be held before calling wait_event*().
> + *   It is released before sleeping and grabbed after
> + *   waking, saving the current IRQ mask in @flags. This lock
> + *   should also be held when changing any variables
> + *   affecting the condition and when waking up the process.

Hmm, I see two problems with that approach:

1. It might lead to people not thinking about their locking order
thoroughly if you introduce a sleeping function that is called with
a spinlock held. Anyone relying on that lock introduces races because
it actually is given up by the macro. I'd prefer it to be called 
without the lock and then have it acquire the lock only to check the
condition, e.g:

#define __wait_event_lock(wq, condition, lock, flags)  \
do {   \
   DEFINE_WAIT(__wait);\
   \
   for (;;) {  \
   prepare_to_wait(, &__wait, TASK_UNINTERRUPTIBLE);\
   spin_lock_irqsave(lock, flags); \
   if (condition)  \
   break;  \
   spin_unlock_irqrestore(lock, flags);\
   schedule(); \
   }   \
   spin_unlock_irqrestore(lock, flags);\
   finish_wait(, &__wait);  \
} while (0)

2. You define the macros only for using spin_lock_irqsave. To make the
API complete, you would also need
spin_lock()
spin_lock_irq()
spin_lock_bh()
read_lock()
read_lock_irq()
read_lock_bh()
read_lock_irqsave()
write_lock()
write_lock_irq()
write_lock_bh()
write_lock_irqsave()

Of course, that is complete overkill if you want to define all the 
wait_event variations for each of those locking variations, but sooner or
later someone will want another one.

One solution that might work could look like
#define __cond_spin_locked(cond, lock) \
({ __typeof__(cond) c; spin_lock(lock); \
c = (cond); spin_unlock(lock); c; })

#define wait_event_lock(wq, condition, lock) \
wait_event(wq, __cond_spin_locked(condition, lock))

#define wait_event_timeout_lock(wq, condition, lock, flags, timeout) \
wait_event_timeout(wq, __cond_spin_locked(condition, lock), timeout)

and so forth.

OTOH, that is easy enough that it can as well be encapsulated in the
places where it is needed.

Arnd <><


pgp9U623mV7rH.pgp
Description: signature

Re: bttv : overlay mode and big disk io hang and could corrupt the fs

[matthieu castet]

Hi,
matthieu castet wrote:
Hi,
if I run "xawtv" [1] and then do a "grep -r toto /usr", my system 
quickly freeze. If there isn't any xawv running nothing happen. I don't 
try to use xawtv with grab mode (port 54) because I don't want to loose 
data by crashing again my / fs.

I retry it and I arrived to get some log (see the attach file).
But after rebooting, I had a big surprise, the / ext3 fs was corrupted 
and I need to run fsck by hand 

Matthieu
I have done other tests.
If I use grabdisplay mode the problem doesn't occur.
If using overlay mode with port 54 the problem is present.
I have also try the cvs bttv driver and the problem isn't fixed.
Can someone look at it?
It seem that something is corrupting kernel memory because usb failed & 
ext3 failed...

I attached a new log when the problem appear.
Note that there are similitude with 
http://www.ussg.iu.edu/hypermail/linux/kernel/0412.3/0881.html and 
http://marc.theaimsgroup.com/?t=11053154392=1=2

Matthieu

[1]
$xawtv -hwscan
This is xawtv-3.94, running on Linux/i686 (2.6.10)
looking for available devices
port 53-53  [ -xvport 53 ]
type : Xvideo, video overlay
name : video4linux
port 54-54
type : Xvideo, image scaler
name : NV Video Overlay
port 55-86
type : Xvideo, image scaler
name : NV Video Blitter
/dev/video0: OK [ -device /dev/video0 ]
type : v4l2
name : BT878 video (Pinnacle PCTV Stud
flags: overlay capture tuner
Feb 12 12:08:33 localhost kernel: Linux video capture interface: v1.00
Feb 12 12:08:33 localhost kernel: bttv: driver version 0.9.15 loaded
Feb 12 12:08:33 localhost kernel: bttv: snapshot date 2005-02-10
Feb 12 12:08:33 localhost kernel: bttv: using 8 buffers with 2080k (520 pages) 
each for capture
Feb 12 12:08:33 localhost kernel: bttv: Bt8xx card found (0).
Feb 12 12:08:33 localhost kernel: ACPI: PCI interrupt :00:0a.0[A] -> GSI 17 
(level, low) -> IRQ 17
Feb 12 12:08:33 localhost kernel: bttv0: Bt878 (rev 17) at :00:0a.0, irq: 
17, latency: 32, mmio: 0xddcfe000
Feb 12 12:08:33 localhost kernel: bttv0: detected: Pinnacle PCTV [card=39], PCI 
subsystem ID is 11bd:0012
Feb 12 12:08:33 localhost kernel: bttv0: using: Pinnacle PCTV Studio/Rave 
[card=39,insmod option]
Feb 12 12:08:33 localhost kernel: bttv0: gpio: en=, out= 
in=00ff27ff [init]
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for MSP34xx @ 0x80... 
not found
Feb 12 12:08:33 localhost kernel: bttv0: miro: id=9 tuner=3 radio=no stereo=no
Feb 12 12:08:33 localhost kernel: bttv0: using tuner=3
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for MSP34xx @ 0x80... 
not found
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for TDA9875 @ 0xb0... 
not found
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for TDA7432 @ 0x8a... 
not found
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for TDA9887 @ 0x86... 
not found
Feb 12 12:08:34 localhost kernel: tuner: chip found at addr 0xc0 i2c-bus bt878 
#0 [sw]
Feb 12 12:08:34 localhost kernel: tuner: type set to 3 (Philips (SECAM+PAL_BG) 
(FI1216MF, FM1216MF, FR1216MF))
Feb 12 12:08:34 localhost kernel: bttv0: registered device video0
Feb 12 12:08:34 localhost kernel: bttv0: registered device vbi0
Feb 12 12:08:34 localhost kernel: bttv0: PLL: 28636363 => 35468950 . ok
Feb 12 12:09:14 localhost kernel: tuner: tv freq set to 208.00
Feb 12 12:09:14 localhost kernel: tv: VHF high range
Feb 12 12:09:14 localhost kernel: tuner: tv 0x0f 0x6f 0x8e 0x97
Feb 12 12:09:14 localhost kernel: tv: VHF high range
Feb 12 12:09:14 localhost kernel: tuner: tv 0x0f 0x6f 0x8e 0x97
Feb 12 12:09:49 localhost kernel: bttv0: OCERR @ 3328b01c,bits: HSYNC OFLOW 
RISCI* OCERR*
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb 12 12:09:49 localhost kernel: 

Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview

[Andi Kleen]

Ray Bryant <[EMAIL PROTECTED]> writes:
> set of pages associated with a particular process need to be moved.
> The kernel interface that we are proposing is the following:
>
> page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);

[Only commenting on the interface, haven't read your patches at all]

This is basically mbind() with MPOL_F_STRICT, except that it has a pid 
argument. I assume that's for the benefit of your batch scheduler.

But it's not clear to me how and why the batch scheduler should know about
virtual addresses of different processes anyways. Walking
/proc/pid/maps? That's all inherently racy when the process is doing
mmap in parallel. The only way I can think of to do this would be to
check for changes in maps after a full move and loop, but then you risk
livelock.

And you cannot also just specify va_start=0, va_end=~0UL because that
would make the node arrays grow infinitely.

Also is there a good use case why the batch scheduler should only
move individual areas in a process around, not the full process?

I think the only sane way for an external process to move another 
around is to do it for the whole process. For that you wouldn't need
most of the arguments, but just a simple move_process_vm call,
or perhaps just a file in /proc where the new node can be written to.

There may be an argument to do this for individual 
tmpfs/hugetlbfs/sysv shm segments too, but mbind() already supports
that (just map them from a different process and change the policy there)

For process use you could just do it in mbind() or perhaps
part of the process policy (move page around when touched by process). 

-Andi
-
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.4.30-pre1] Sparc SMP build fixes

[Willy Tarreau]

Hi Marcelo and David,

The recent addition of an smp_rmb() in kfree_skb() by Herbert Xu
broke SMP builds on sparc and sparc64, but it's not Herbert's fault,
it's because of a few extra semi-colons in system.h for both archs.

The smp_rmb() has been inserted this way :

   if (likely(atomic_read(>users) == 1))
   smp_rmb();
   else if (likely(!atomic_dec_and_test(>users)))
   return;

But it's defined like this on sparc and sparc64 :

   #define smp_rmb()   __asm__ __volatile__("":::"memory");

So you get it :-)

I quickly grepped include/asm-* and found 85 obvious similar cases in
various files and on various defines. I'm not sure that everything
builds on every arch.

However, while I was fixing system.h for sparc and sparc64, I also
fixed a few more defines in the same file which had the same problem.
In case of sparc64, the use of "mb();" would have resulted in 3
consecutive semi-colons.

Please consider including this.

Cheers,
Willy


--- ./include/asm-sparc/system.h.badSat Sep 18 14:15:43 2004
+++ ./include/asm-sparc/system.hSat Feb 12 10:55:05 2005
@@ -295,9 +295,9 @@
 #define wmb()  mb()
 #define set_mb(__var, __value)  do { __var = __value; mb(); } while(0)
 #define set_wmb(__var, __value) set_mb(__var, __value)
-#define smp_mb()   __asm__ __volatile__("":::"memory");
-#define smp_rmb()  __asm__ __volatile__("":::"memory");
-#define smp_wmb()  __asm__ __volatile__("":::"memory");
+#define smp_mb()   __asm__ __volatile__("":::"memory")
+#define smp_rmb()  __asm__ __volatile__("":::"memory")
+#define smp_wmb()  __asm__ __volatile__("":::"memory")
 
 #define nop() __asm__ __volatile__ ("nop");
 

--- ./include/asm-sparc64/system.h.bad  Sat Feb 12 10:40:21 2005
+++ ./include/asm-sparc64/system.h  Sat Feb 12 10:54:17 2005
@@ -106,9 +106,9 @@
 
 #define nop()  __asm__ __volatile__ ("nop")
 
-#define membar(type)   __asm__ __volatile__ ("membar " type : : : "memory");
+#define membar(type)   __asm__ __volatile__ ("membar " type : : : "memory")
 #define mb()   \
-   membar("#LoadLoad | #LoadStore | #StoreStore | #StoreLoad");
+   membar("#LoadLoad | #LoadStore | #StoreStore | #StoreLoad")
 #define rmb()  membar("#LoadLoad")
 #define wmb()  membar("#StoreStore")
 #define set_mb(__var, __value) \
@@ -121,9 +121,9 @@
 #define smp_rmb()  rmb()
 #define smp_wmb()  wmb()
 #else
-#define smp_mb()   __asm__ __volatile__("":::"memory");
-#define smp_rmb()  __asm__ __volatile__("":::"memory");
-#define smp_wmb()  __asm__ __volatile__("":::"memory");
+#define smp_mb()   __asm__ __volatile__("":::"memory")
+#define smp_rmb()  __asm__ __volatile__("":::"memory")
+#define smp_wmb()  __asm__ __volatile__("":::"memory")
 #endif
 
 #define flushi(addr)   __asm__ __volatile__ ("flush %0" : : "r" (addr) : 
"memory")
@@ -132,7 +132,7 @@
 
 /* Performance counter register access. */
 #define read_pcr(__p)  __asm__ __volatile__("rd%%pcr, %0" : "=r" (__p))
-#define write_pcr(__p) __asm__ __volatile__("wr%0, 0x0, %%pcr" : : "r" 
(__p));
+#define write_pcr(__p) __asm__ __volatile__("wr%0, 0x0, %%pcr" : : "r" 
(__p))
 #define read_pic(__p)  __asm__ __volatile__("rd %%pic, %0" : "=r" (__p))
 
 /* Blackbird errata workaround.  See commentary in


-
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/

FWD: Hi Linux, like to watch real people getting Dirty. No Fees for Life.

[Spays S. Entente]

Hi Linux,

Do You like watching real live people, getting down and dirty. Well here you go 
for a limited time only you can get a Lifetime password at no charge, that's 
right no charge...

voted #1 new website in 2005 by the industry..

http://over.aurilavepoppetleggumdigging.com/369997/rpm/lifetime.html


A chain is no stronger than its weakest link. 



A light purse makes a heavy heart. . A chain is no stronger than its weakest 
link. . Anger and hate hinder good counsel. . Hall binks are oft sliddery. 
An explanation .
Make hay while the sun shines. 

Never let the sun go down on your anger. 

no more?
http://of.three.aurilavepoppetleggumdigging.com/emms/preference/control.php








Different strokes for different folks. . You snooze, you loose. . Actions speak 
louder than words. .
The best things in life are free. . Love to live and live to love. . Half a 
loaf is better than none. .

Before you meet the handsome prince you have to kiss a lot of toads. . A friend 
to everybody is a friend to nobody. . Good company on the road is the shortest 
cut. .


-
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: [ANNOUNCE] hotplug-ng 001 release

[Harald Dunkel]

Greg KH wrote:
Because we don't have an easy way yet to build against a copy of klibc
on a system?  For right now, it's the simplest way to ensure that it
works for everyone, once klibc moves into the kernel tree I can remove
it from udev and hotplug-ng.
If it is not possible to use klibc together with a non-Linux
system (e.g. FreeBSD or Mach), then I would suggest to make
klibc an optional kernel patch and drop it from udev and
hotplug.
Is it causing problems for you?
Some months ago I had contributed a patch to add an install
target to the klibc Makefiles. I just wonder why it has been
ignored.
Regards
Harri


signature.asc
Description: OpenPGP digital signature

Re: [RFC 2.6.11-rc2-mm2 7/7] mm: manual page migration -- sys_page_migrate

[Paul Jackson]

Minor comments ... nothing profound.

Ray wrote:
> once we agree on what the authority model should be.

Are the usual kill-like permissions sufficient?
You can migrate the pages of a process if you can kill it.

===

In the following routine, tighten up some vertical spacing,
add { ... } , ...

The migrated and count manipulations are confusing my
feeble brain.  Is this thing supposed to return 0 if all
count pages are migrated?  Sure seems that it does, as it
returns 'migrated', which is 'count - migrated', but that
migrated is really count, so it returns 'count - count',
which is zero.  Huh ...  The phrase 'return migrated' would
make me think it returned some count of how many were
migrated on success, not zero.

The variable name 'remains' is rather elaborate for what
looks like a trivial return case.  But perhaps it actually
provides a better clue to the return value, which apparently
is the number of pages _not_ migrated successfully.

Think carefully about what each variable represents, and
then use each variable consistently.

And try to avoid the embedded 'return remains'.  A function
header comment, saying what this routine does and returns might
be helpful.

=
static int
migrate_vma_common(struct list_head *page_list, short *node_map, int count)
{
int pass, remains, migrated;
struct page *page;

for (pass = 0; pass < 10; msleep(10), pass++) {
remains = try_to_migrate_pages(page_list, node_map);
if (remains < 0)
return remains;

migrated = 0;
if (!list_empty(page_list)) {
list_for_each_entry(page, page_list, lru)
migrated++;
} else {
migrated = count;
break;
}
migrated = count - migrated;
}
return migrated;
}
=

Better init tmp_new_nodes, node_map to 0, or if tmp_old_news fails to
allocate, you might try freeing bogus values for the other two in
sys_page_migrate():

===
+   short *tmp_old_nodes;
+   short *tmp_new_nodes;
+   short *node_map;
+   ...
+
+
+   tmp_old_nodes = (short *) kmalloc(size, GFP_KERNEL);
+   tmp_new_nodes = (short *) kmalloc(size, GFP_KERNEL);
+   node_map = (short *) kmalloc(MAX_NUMNODES*sizeof(short), GFP_KERNEL);


-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
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/

FWD: Hi Linux, like to watch real people getting Dirty. No Fees for Life.

[Spays S. Entente]

Hi Linux,

Do You like watching real live people, getting down and dirty. Well here you go 
for a limited time only you can get a Lifetime password at no charge, that's 
right no charge...

voted #1 new website in 2005 by the industry..

http://over.aurilavepoppetleggumdigging.com/369997/rpm/lifetime.html


A chain is no stronger than its weakest link. 



A light purse makes a heavy heart. . A chain is no stronger than its weakest 
link. . Anger and hate hinder good counsel. . Hall binks are oft sliddery. 
An explanation .
Make hay while the sun shines. 

Never let the sun go down on your anger. 

no more?
http://of.three.aurilavepoppetleggumdigging.com/emms/preference/control.php








Different strokes for different folks. . You snooze, you loose. . Actions speak 
louder than words. .
The best things in life are free. . Love to live and live to love. . Half a 
loaf is better than none. .

Before you meet the handsome prince you have to kiss a lot of toads. . A friend 
to everybody is a friend to nobody. . Good company on the road is the shortest 
cut. .


-
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.4.30-pre1] Sparc SMP build fixes

[Willy Tarreau]

Hi Marcelo and David,

The recent addition of an smp_rmb() in kfree_skb() by Herbert Xu
broke SMP builds on sparc and sparc64, but it's not Herbert's fault,
it's because of a few extra semi-colons in system.h for both archs.

The smp_rmb() has been inserted this way :

   if (likely(atomic_read(skb-users) == 1))
   smp_rmb();
   else if (likely(!atomic_dec_and_test(skb-users)))
   return;

But it's defined like this on sparc and sparc64 :

   #define smp_rmb()   __asm__ __volatile__(:::memory);

So you get it :-)

I quickly grepped include/asm-* and found 85 obvious similar cases in
various files and on various defines. I'm not sure that everything
builds on every arch.

However, while I was fixing system.h for sparc and sparc64, I also
fixed a few more defines in the same file which had the same problem.
In case of sparc64, the use of mb(); would have resulted in 3
consecutive semi-colons.

Please consider including this.

Cheers,
Willy


--- ./include/asm-sparc/system.h.badSat Sep 18 14:15:43 2004
+++ ./include/asm-sparc/system.hSat Feb 12 10:55:05 2005
@@ -295,9 +295,9 @@
 #define wmb()  mb()
 #define set_mb(__var, __value)  do { __var = __value; mb(); } while(0)
 #define set_wmb(__var, __value) set_mb(__var, __value)
-#define smp_mb()   __asm__ __volatile__(:::memory);
-#define smp_rmb()  __asm__ __volatile__(:::memory);
-#define smp_wmb()  __asm__ __volatile__(:::memory);
+#define smp_mb()   __asm__ __volatile__(:::memory)
+#define smp_rmb()  __asm__ __volatile__(:::memory)
+#define smp_wmb()  __asm__ __volatile__(:::memory)
 
 #define nop() __asm__ __volatile__ (nop);
 

--- ./include/asm-sparc64/system.h.bad  Sat Feb 12 10:40:21 2005
+++ ./include/asm-sparc64/system.h  Sat Feb 12 10:54:17 2005
@@ -106,9 +106,9 @@
 
 #define nop()  __asm__ __volatile__ (nop)
 
-#define membar(type)   __asm__ __volatile__ (membar  type : : : memory);
+#define membar(type)   __asm__ __volatile__ (membar  type : : : memory)
 #define mb()   \
-   membar(#LoadLoad | #LoadStore | #StoreStore | #StoreLoad);
+   membar(#LoadLoad | #LoadStore | #StoreStore | #StoreLoad)
 #define rmb()  membar(#LoadLoad)
 #define wmb()  membar(#StoreStore)
 #define set_mb(__var, __value) \
@@ -121,9 +121,9 @@
 #define smp_rmb()  rmb()
 #define smp_wmb()  wmb()
 #else
-#define smp_mb()   __asm__ __volatile__(:::memory);
-#define smp_rmb()  __asm__ __volatile__(:::memory);
-#define smp_wmb()  __asm__ __volatile__(:::memory);
+#define smp_mb()   __asm__ __volatile__(:::memory)
+#define smp_rmb()  __asm__ __volatile__(:::memory)
+#define smp_wmb()  __asm__ __volatile__(:::memory)
 #endif
 
 #define flushi(addr)   __asm__ __volatile__ (flush %0 : : r (addr) : 
memory)
@@ -132,7 +132,7 @@
 
 /* Performance counter register access. */
 #define read_pcr(__p)  __asm__ __volatile__(rd%%pcr, %0 : =r (__p))
-#define write_pcr(__p) __asm__ __volatile__(wr%0, 0x0, %%pcr : : r 
(__p));
+#define write_pcr(__p) __asm__ __volatile__(wr%0, 0x0, %%pcr : : r 
(__p))
 #define read_pic(__p)  __asm__ __volatile__(rd %%pic, %0 : =r (__p))
 
 /* Blackbird errata workaround.  See commentary in


-
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: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview

[Andi Kleen]

Ray Bryant [EMAIL PROTECTED] writes:
 set of pages associated with a particular process need to be moved.
 The kernel interface that we are proposing is the following:

 page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);

[Only commenting on the interface, haven't read your patches at all]

This is basically mbind() with MPOL_F_STRICT, except that it has a pid 
argument. I assume that's for the benefit of your batch scheduler.

But it's not clear to me how and why the batch scheduler should know about
virtual addresses of different processes anyways. Walking
/proc/pid/maps? That's all inherently racy when the process is doing
mmap in parallel. The only way I can think of to do this would be to
check for changes in maps after a full move and loop, but then you risk
livelock.

And you cannot also just specify va_start=0, va_end=~0UL because that
would make the node arrays grow infinitely.

Also is there a good use case why the batch scheduler should only
move individual areas in a process around, not the full process?

I think the only sane way for an external process to move another 
around is to do it for the whole process. For that you wouldn't need
most of the arguments, but just a simple move_process_vm call,
or perhaps just a file in /proc where the new node can be written to.

There may be an argument to do this for individual 
tmpfs/hugetlbfs/sysv shm segments too, but mbind() already supports
that (just map them from a different process and change the policy there)

For process use you could just do it in mbind() or perhaps
part of the process policy (move page around when touched by process). 

-Andi
-
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: bttv : overlay mode and big disk io hang and could corrupt the fs

[matthieu castet]

Hi,
matthieu castet wrote:
Hi,
if I run xawtv [1] and then do a grep -r toto /usr, my system 
quickly freeze. If there isn't any xawv running nothing happen. I don't 
try to use xawtv with grab mode (port 54) because I don't want to loose 
data by crashing again my / fs.

I retry it and I arrived to get some log (see the attach file).
But after rebooting, I had a big surprise, the / ext3 fs was corrupted 
and I need to run fsck by hand 

Matthieu
I have done other tests.
If I use grabdisplay mode the problem doesn't occur.
If using overlay mode with port 54 the problem is present.
I have also try the cvs bttv driver and the problem isn't fixed.
Can someone look at it?
It seem that something is corrupting kernel memory because usb failed  
ext3 failed...

I attached a new log when the problem appear.
Note that there are similitude with 
http://www.ussg.iu.edu/hypermail/linux/kernel/0412.3/0881.html and 
http://marc.theaimsgroup.com/?t=11053154392r=1w=2

Matthieu

[1]
$xawtv -hwscan
This is xawtv-3.94, running on Linux/i686 (2.6.10)
looking for available devices
port 53-53  [ -xvport 53 ]
type : Xvideo, video overlay
name : video4linux
port 54-54
type : Xvideo, image scaler
name : NV Video Overlay
port 55-86
type : Xvideo, image scaler
name : NV Video Blitter
/dev/video0: OK [ -device /dev/video0 ]
type : v4l2
name : BT878 video (Pinnacle PCTV Stud
flags: overlay capture tuner
Feb 12 12:08:33 localhost kernel: Linux video capture interface: v1.00
Feb 12 12:08:33 localhost kernel: bttv: driver version 0.9.15 loaded
Feb 12 12:08:33 localhost kernel: bttv: snapshot date 2005-02-10
Feb 12 12:08:33 localhost kernel: bttv: using 8 buffers with 2080k (520 pages) 
each for capture
Feb 12 12:08:33 localhost kernel: bttv: Bt8xx card found (0).
Feb 12 12:08:33 localhost kernel: ACPI: PCI interrupt :00:0a.0[A] - GSI 17 
(level, low) - IRQ 17
Feb 12 12:08:33 localhost kernel: bttv0: Bt878 (rev 17) at :00:0a.0, irq: 
17, latency: 32, mmio: 0xddcfe000
Feb 12 12:08:33 localhost kernel: bttv0: detected: Pinnacle PCTV [card=39], PCI 
subsystem ID is 11bd:0012
Feb 12 12:08:33 localhost kernel: bttv0: using: Pinnacle PCTV Studio/Rave 
[card=39,insmod option]
Feb 12 12:08:33 localhost kernel: bttv0: gpio: en=, out= 
in=00ff27ff [init]
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for MSP34xx @ 0x80... 
not found
Feb 12 12:08:33 localhost kernel: bttv0: miro: id=9 tuner=3 radio=no stereo=no
Feb 12 12:08:33 localhost kernel: bttv0: using tuner=3
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for MSP34xx @ 0x80... 
not found
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for TDA9875 @ 0xb0... 
not found
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for TDA7432 @ 0x8a... 
not found
Feb 12 12:08:33 localhost kernel: bttv0: i2c: checking for TDA9887 @ 0x86... 
not found
Feb 12 12:08:34 localhost kernel: tuner: chip found at addr 0xc0 i2c-bus bt878 
#0 [sw]
Feb 12 12:08:34 localhost kernel: tuner: type set to 3 (Philips (SECAM+PAL_BG) 
(FI1216MF, FM1216MF, FR1216MF))
Feb 12 12:08:34 localhost kernel: bttv0: registered device video0
Feb 12 12:08:34 localhost kernel: bttv0: registered device vbi0
Feb 12 12:08:34 localhost kernel: bttv0: PLL: 28636363 = 35468950 . ok
Feb 12 12:09:14 localhost kernel: tuner: tv freq set to 208.00
Feb 12 12:09:14 localhost kernel: tv: VHF high range
Feb 12 12:09:14 localhost kernel: tuner: tv 0x0f 0x6f 0x8e 0x97
Feb 12 12:09:14 localhost kernel: tv: VHF high range
Feb 12 12:09:14 localhost kernel: tuner: tv 0x0f 0x6f 0x8e 0x97
Feb 12 12:09:49 localhost kernel: bttv0: OCERR @ 3328b01c,bits: HSYNC OFLOW 
RISCI* OCERR*
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
non-integral number of cells in incoming data.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: incoming 
data length = 1.
Feb 12 12:09:49 localhost kernel: [EAGLE-USB] eu_uni_process_in_data: 
ATM_CELL_SIZE = 35.
Feb 12 12:09:49 localhost kernel: 

Re: [RFC UPDATE PATCH] add wait_event_*_lock() functions and comments

[Arnd Bergmann]

On Freedag 11 Februar 2005 20:55, Nishanth Aravamudan wrote:

 + * If the macro name contains:
 + *   lock, then @lock should be held before calling wait_event*().
 + *   It is released before sleeping and grabbed after
 + *   waking, saving the current IRQ mask in @flags. This lock
 + *   should also be held when changing any variables
 + *   affecting the condition and when waking up the process.

Hmm, I see two problems with that approach:

1. It might lead to people not thinking about their locking order
thoroughly if you introduce a sleeping function that is called with
a spinlock held. Anyone relying on that lock introduces races because
it actually is given up by the macro. I'd prefer it to be called 
without the lock and then have it acquire the lock only to check the
condition, e.g:

#define __wait_event_lock(wq, condition, lock, flags)  \
do {   \
   DEFINE_WAIT(__wait);\
   \
   for (;;) {  \
   prepare_to_wait(wq, __wait, TASK_UNINTERRUPTIBLE);\
   spin_lock_irqsave(lock, flags); \
   if (condition)  \
   break;  \
   spin_unlock_irqrestore(lock, flags);\
   schedule(); \
   }   \
   spin_unlock_irqrestore(lock, flags);\
   finish_wait(wq, __wait);  \
} while (0)

2. You define the macros only for using spin_lock_irqsave. To make the
API complete, you would also need
spin_lock()
spin_lock_irq()
spin_lock_bh()
read_lock()
read_lock_irq()
read_lock_bh()
read_lock_irqsave()
write_lock()
write_lock_irq()
write_lock_bh()
write_lock_irqsave()

Of course, that is complete overkill if you want to define all the 
wait_event variations for each of those locking variations, but sooner or
later someone will want another one.

One solution that might work could look like
#define __cond_spin_locked(cond, lock) \
({ __typeof__(cond) c; spin_lock(lock); \
c = (cond); spin_unlock(lock); c; })

#define wait_event_lock(wq, condition, lock) \
wait_event(wq, __cond_spin_locked(condition, lock))

#define wait_event_timeout_lock(wq, condition, lock, flags, timeout) \
wait_event_timeout(wq, __cond_spin_locked(condition, lock), timeout)

and so forth.

OTOH, that is easy enough that it can as well be encapsulated in the
places where it is needed.

Arnd 


pgp9U623mV7rH.pgp
Description: signature

Re: [RFC 2.6.11-rc2-mm2 7/7] mm: manual page migration -- sys_page_migrate

[Arjan van de Ven]

On Fri, 2005-02-11 at 19:26 -0800, Ray Bryant wrote:
 This patch introduces the sys_page_migrate() system call:
 
 sys_page_migrate(pid, va_start, va_end, count, old_nodes, new_nodes);

are you really sure you want to expose nodes to userspace via an ABI
this solid and never changing? To me that feels somewhat like too much
of an internal thing to expose that will mean that those internals are
now set in stone due to the interface...


-
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: /proc/*/statm, exactly what does shared mean?

[Hugh Dickins]

On Fri, 11 Feb 2005, Richard F. Rebel wrote:
 
 I can't seem to find clear documentation about the 'share' column
 from /proc/pid/statm.
 
 Does this include pages that are shared with forked children marked as
 copy-on-write?
 
 Does this only reflect libraries that are dynamically loaded?  What
 about shared memory segments/mmaps (ala shmat or mmmap)?
 
 If there is a place where I might find documentation that is more clear
 beyond the proc.txt in the kernel docs and then man pages for procfs,
 I'd welcome a pointer.

You may not be entirely happy with this answer.
It is a count of pages of the process which are shared in some sense.
But precisely what that means has changed from time to time: depending on
our perception of what we can safely afford the overhead of counting.

You may want to look at fs/proc proc_pid_statm() source for the release
of interest, and follow that back to see exactly what is being counted.

Throughout 2.4 (and 2.2 too I think) it was the count of those pages
instantiated in the process address space which currently have a page
count greater than 1.  That would include private pages shared with
forked children, pages from the pagecache (including pages mapped
from executable or library or shared memory or file mmap), those
private pages which currently have swap allocated (so they're also
in the swapcache), and any pages which transitorily have page count
raised for whatever reason (they'd likely already be in one of the
above categories).  A ragbag of meanings, but that's all you can
get from looking at page count.

Counting up that not very meaningful number, at frequent intervals
on large process address spaces, is a waste of valuable time.

From 2.5.37 to 2.6.9, it's the total extent of file-backed areas
(file including executable or library or shared memory) in the
process address space: a total extent (in pagesize units),
not a count of instantiated pages.  Much quicker to calculate.

But there were complaints about that, and a need to revert from
total extent to count of instantiated pages.

From 2.6.10 onwards, for the foreseeable future, it is the count
of those pages instantiated in the process address space which are
shared with a file (including executable or library or shared memory)
i.e. those pages which are not anonymous, not private.  That count
does not include private pages shared with forked children, nor
does it include private pages which happen to have swap allocated.

Hugh
-
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: [RFC] Reliable video POSTing on resume

[Bodo Eggert]

Kendall Bennett [EMAIL PROTECTED] wrote:

 Laptops are a little different as they will make calls from the Video
 BIOS into the system BIOS, so you need to make sure that the system BIOS
 is also available in the execution environment.

Any video BIOS (especially EGA) may call system BIOS functions, e.g. via the
old INT10 (which will get copied to INT42).

HGC and VGA are in the system BIOS. They don't need magic, but they need to
be initialized on order to keep the monitor from burning. On the other hand,
they used to be initialised correctly.
-
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, new ACPI driver] new sony_acpi driver

[Jean Delvare]

 Based on feedback from Jean Delvare and Pekka Enberg, here is an
 updated version.

Works for me (Vaio PCG-GR214EP). Tested with 2.6.11-rc3-bk8.

I then enabled the debug mode. I couldn't find anything relevant WRT
what each additional file is supposed to do, but I still have noticed a
number of things you might be interested in.

ctr doesn't seem to affect the contrast for me. I also noticed that the
value seems to be stored on 8 bits. Higher bits are ignored (e.g. write
300, read 44). Default value is 64.

cmi behaves strangely. Its default value is 0. Whatever I write to it
(including 0), next read returns 131.

pbr seems to be stored on 4 bits. Higher bits are ignored (e.g. write
20, read 4). Default value is 0.

csxb is the dangerous one. Default 0. Writing 41 to it deadlocked my
system. Writing 42 changed pbr from 0 to 8 as a side effect. Each write
generates an error in the logs:
  sony_acpi: acpi_evaluate_object failed

cmi and csxb are reset to 0 on sony_acpi module cycling. brightness, ctr
and pbr are preserved.

Hope that helps. Let me know if you want me to test specific things.
-- 
Jean Delvare
-
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: [RFC UPDATE PATCH] add wait_event_*_lock() functions and comments

[Sergey Vlasov]

On Sat, 12 Feb 2005 12:38:26 +0100 Arnd Bergmann wrote:

 On Freedag 11 Februar 2005 20:55, Nishanth Aravamudan wrote:
 
  + * If the macro name contains:
  + * lock, then @lock should be held before calling wait_event*().
  + * It is released before sleeping and grabbed after
  + * waking, saving the current IRQ mask in @flags. This lock
  + * should also be held when changing any variables
  + * affecting the condition and when waking up the process.
 
 Hmm, I see two problems with that approach:
 
 1. It might lead to people not thinking about their locking order
 thoroughly if you introduce a sleeping function that is called with
 a spinlock held. Anyone relying on that lock introduces races because
 it actually is given up by the macro. I'd prefer it to be called 
 without the lock and then have it acquire the lock only to check the
 condition, e.g:
 
 #define __wait_event_lock(wq, condition, lock, flags)  \
 do {   \
DEFINE_WAIT(__wait);\
\
for (;;) {  \
prepare_to_wait(wq, __wait, TASK_UNINTERRUPTIBLE);\
spin_lock_irqsave(lock, flags); \
if (condition)  \
break;  \
spin_unlock_irqrestore(lock, flags);\
schedule(); \
}   \
spin_unlock_irqrestore(lock, flags);\
finish_wait(wq, __wait);  \
 } while (0)

But in this case the result of testing the condition becomes useless
after spin_unlock_irqrestore - someone might grab the lock and change
things.   Therefore the calling code would need to add a loop around
wait_event_lock - and the wait_event_* macros were added precisely to
encapsulate such a loop and avoid the need to code it manually.


pgpWr8tJ7VL0F.pgp
Description: PGP signature

Re: COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6

[Eric W. Biederman]

Werner Almesberger [EMAIL PROTECTED] writes:

 Andi Kleen wrote:
  It's dependent on the architecture already. I would like to enable
  it on i386/x86-64 because the kernel command line is often used
  to pass parameters to installers, and having a small limit there
  can be awkward.
 
 Something to keep in mind when extending the command line is that
 we'll probably need a mechanism for passing additional (and
 possibly large) data blocks from the boot loader soon.
 
 The reason for this is that, if booting through kexec, it would be
 attractive to pass device scan results, so that the second kernel
 doesn't have to repeat the work. As an obvious extension, anyone
 who wants to boot *quickly* could also pass such data from
 persistent storage without actually performing the device scan at
 all when the machine is booted.
 
 The command line may be suitable for this, but to allow for passing
 a lot of data, its place in memory should perhaps just be reserved,
 at least until the system has passed initialization, without trying
 to copy it to a safe place early in kernel startup.

Actually this is trivial to do by using a file in initramfs.
If we need something in a well defined format anyway.

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/