Re: [ofa-general] [PATCH 2.6.21-rc2] iw_cxgb3: Don't use mm after its freed in iwch_mmap().

2007-03-06 Thread Roland Dreier
Thanks, applied.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Thomas Gleixner
On Tue, 2007-03-06 at 08:25 +0100, Ingo Molnar wrote:
 The programming of periodic tick devices needs to be saved/restored 
 across suspend/resume - otherwise we might end up with a system coming 
 up that relies on getting a PIT (or HPET) interrupt, while those devices 
 default to 'no interrupts' after powerup. (To confuse things it worked 
 to a certain degree on some systems because the lapic gets initialized 
 as a side-effect of SMP bootup.)
 
 This suspend / resume thing was dropped unintentionally during the 
 last-minute -mm code reshuffling.
 
 Signed-off-by: Ingo Molnar [EMAIL PROTECTED]

Signed-off-by: Thomas Gleixner [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/


Question: schedule()

2007-03-06 Thread Mockern
Hi,

What does schedule() function do? I want to make my kthread preemptive.

Thanks
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch 00/13] Syslets, Threadlets, generic AIO support, v3

2007-03-06 Thread Pavel Machek
 As for why common abstractions like file are a good thing, think about why
 having /dev/null is cleaner that having a special plug DEVNULL_FD fd
 value to be plugged everywhere,
 
 This is a stupid comparaison. By your logic we should also have /dev/stdin,
 /dev/stdout and /dev/stderr.

Bzzt, wrong. We have them.

[EMAIL PROTECTED]:~$ ls -al /dev/std*
lrwxrwxrwx 1 root root 4 Nov 12  2003 /dev/stderr - fd/2
lrwxrwxrwx 1 root root 4 Nov 12  2003 /dev/stdin - fd/0
lrwxrwxrwx 1 root root 4 Nov 12  2003 /dev/stdout - fd/1
[EMAIL PROTECTED]:~$ ls -al /proc/self/fd
total 0
dr-x-- 2 pavel users  0 Mar  6 09:18 .
dr-xr-xr-x 4 pavel users  0 Mar  6 09:18 ..
lrwx-- 1 pavel users 64 Mar  6 09:18 0 - /dev/ttyp2
lrwx-- 1 pavel users 64 Mar  6 09:18 1 - /dev/ttyp2
lrwx-- 1 pavel users 64 Mar  6 09:18 2 - /dev/ttyp2
lr-x-- 1 pavel users 64 Mar  6 09:18 3 - /proc/2299/fd
[EMAIL PROTECTED]:~$

 But here the list could be almost endless.
 And please don't start the, they don't scale or they need heavy file
 binding tossfeast. They scale as well as the interface that will receive
 them (poll, select, epoll). Heavy file binding what? 100 or so bytes for
 the struct file? How many signal/timer fd are you gonna have? Like 100K?
 Really moot argument when opposed to the benefit of being compatible with
 existing POSIX interfaces and being more Unix friendly.
 
 So why the HELL don't we have those yet? Why haven't you designed
 epoll with those in mind? Why don't you back your claims with patches?
 (I'm not a kernel developer.)

Either stop flaming kernel developers or become one. It is  that
simple.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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] Kconfig: Update swsusp description

2007-03-06 Thread Pavel Machek
Hi!

 Index: linux-2.6.21-rc2/kernel/power/Kconfig
 ===
 --- linux-2.6.21-rc2.orig/kernel/power/Kconfig2007-02-28 
 23:54:45.0 +0100
 +++ linux-2.6.21-rc2/kernel/power/Kconfig 2007-03-04 11:50:48.0 
 +0100
 @@ -81,30 +81,35 @@ config SOFTWARE_SUSPEND
   bool Software Suspend
   depends on PM  SWAP  ((X86  (!SMP || SUSPEND_SMP)) || ((FRV || 
 PPC32)  !SMP))
   ---help---
 +   Enable the suspend to disk (STD) functionality.
  
 +   You can suspend your machine with 'echo disk  /sys/power/state'.
 +   Alternatively, you can use the additional userland tools available
 +   from http://suspend.sf.net.
 +
 +   In principle it does not require ACPI or APM, although for example
 +   ACPI will be used if available.
 +
 +   It creates an image which is saved in your active swap. Upon the next
 boot, pass the 'resume=/dev/swappartition' argument to the kernel to

Actually, these days resume=... on kernel command line needs to be
there for suspend, too, IIRC.

 +   Right now you may boot without resuming and resume later but in the
 +   meantime you cannot use the swap partition(s)/file(s) involved in
 +   suspending.  Also in this case you must not use the

I'd prefer not to encourage this use. It has too many traps ready for
people.

Otherwise looks ok.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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] paravirt: VDSO page is essential

2007-03-06 Thread Ingo Molnar

* Roland McGrath [EMAIL PROTECTED] wrote:

  Jan Beulich just posted a patch to do just this - relocate the 
  vdso's ELF header.  If that's all that's really required to keep 
  COMPAT_VDSO viable under PARAVIRT, then it seems like the way to go.
 
 I found 
 http://marc.theaimsgroup.com/?l=xen-develm=117309332600075w=2 and 
 that must be the one you meant.  The ELF-grokking form of that is 
 exactly what I had in mind.  The find relocs with cmp scheme is 
 pretty silly, but also works fine.  It trades tweaky ELF knowledge 
 with tweaky fragile build methods, but it's all about the same to me.

this looks good to me too in principle, the #else branch. But the actual 
implementation will have to be redone quite a bit i fear. Some details: 
relocate_vdso() needs some major coding style cleanups. This bit:

-# define VDSO_PRELINK  VDSO_HIGH_BASE
+# ifndef CONFIG_XEN
+#  define VDSO_PRELINK VDSO_HIGH_BASE
+# else
+#  define VDSO_PRELINK (0UL - FIX_VDSO * PAGE_SIZE)
+# endif

should be Kconfig driven, not #ifdef driven, due to cleanliness and also 
because lguest wants to have the same thing. Plus:

+#if defined(CONFIG_XEN)  defined(CONFIG_COMPAT_VDSO)

i'd just make this depend on CONFIG_COMPAT_VDSO, always. Same here:

+#if defined(CONFIG_XEN)  defined(CONFIG_COMPAT_VDSO)
+static void __init relocate_vdso

just make this driven in the normal CONFIG_COMPAT_VDSO case too - even 
though we 'prelink' the VDSO to the usual address - we better run 
through the same code all the time and reduce the number of variants as 
much as possible.

furthermore, there should be a paravirt_ops method to chose the 
relocation address, unless i'm missing something. On the native kernel 
that address will default to 0xe000. (if CONFIG_COMPAT_VDSO is 
selected)

this way there will only be two main variants to worry about: compat and 
modern (which is the current status quo anyway), instead of 4-5 
variants.

Ingo
-
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] sched: fix idle at tick

2007-03-06 Thread J.A. Magallón
On Tue, 6 Mar 2007 18:41:08 +1100, Con Kolivas [EMAIL PROTECTED] wrote:

 On Tuesday 06 March 2007 18:02, Andrew Morton wrote:
  On Tue, 6 Mar 2007 17:25:36 +1100 Con Kolivas [EMAIL PROTECTED] wrote:
   Signed-off-by: Con Kolivas [EMAIL PROTECTED]
   ---
kernel/sched.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
  
   Index: linux-2.6.21-rc2-mm1-base/kernel/sched.c
   ===
   --- linux-2.6.21-rc2-mm1-base.orig/kernel/sched.c 2007-03-06
   17:19:17.0 +1100 +++
   linux-2.6.21-rc2-mm1-base/kernel/sched.c  2007-03-06 17:20:40.0
   +1100 @@ -3444,7 +3444,7 @@ void scheduler_tick(void)
  
 update_cpu_clock(p, rq, now);
  
   - if (idle_at_tick)
   + if (!idle_at_tick)
 task_running_tick(rq, p);
#ifdef CONFIG_SMP
 update_load(rq);
 
  Looks right, thanks.  The original patch had
 
  -   if (p == rq-idle)
  +   if (idle_at_tick)
  /* Task on the idle queue */
  wake_priority_sleeper(rq);
  else
  task_running_tick(rq, p);
 
  but it got damaged by smt-nice removal.
 
 I gathered something like that happened. If it wasn't clear this change 
 caused 
 massive scheduler damage with no cpu accounting whatsoever occurring. I 
 recommend putting it in your hotfixes/ dir if you're not planning an -mm2 
 soon.
 

Good! I can confirm this makes things going smoothly again

(apart from the speed of the x11 nv driver at 1600x1200 ;) ).

hot-fixes candidate.

--
J.A. Magallon jamagallon()ono!com \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2007.1 (Cooker) for i586
Linux 2.6.20-jam01 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP 
PREEMPT
-
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: [ck] Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler

2007-03-06 Thread Xavier Bestel
On Tue, 2007-03-06 at 09:10 +1100, Con Kolivas wrote:
 Hah I just wish gears would go away. If I get hardware where it runs at just 
 the right speed it looks like it doesn't move at all. On other hardware the 
 wheels go backwards and forwards where the screen refresh rate is just 
 perfectly a factor of the frames per second (or something like that). 
 
 This is not a cpu scheduler test and you're inferring that there are cpu 
 scheduling artefacts based on an application that has bottlenecks at 
 different places depending on the hardware combination. 

I'd add that Xorg has its own scheduler (for X11 operations, of course),
that has its own quirks, and chances are that it is the one you're
testing with glxgears. And as Con said, as long as glxgears does more
FPS than your screen refresh rate, its flickering its completely
meaningless: it doesn't even attempt to sync with vblank. Al, you'd
better try with Quake3 or Nexuiz, or even Blender if you want to test 3D
interactivity under load.

Xav


-
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.21-rc2-mm2

2007-03-06 Thread Andrew Morton

Temporarily at

  http://userweb.kernel.org/~akpm/2.6.21-rc2-mm2/

Will appear later at

  
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc2/2.6.20-rc2-mm2/


- git-block.patch is having problems which are getting in the way - it has
  been dropped.

- As a consequence all the AIO patches were dropped

- Some MM patches were dropped:

  - lumpy-reclaim is being redone

  - remove-mlocked-pages-from-the-LRU: is being redone

  - remove-anon-pages-from-the-LRU-if-we-have-no-swap: ditto

- Merged Mel's MM patches: GFP_MOVABLE and anti-fragmentation.  I don't
  yet know if we want to do this, but let's get the code some more test and
  eyeball time.

- Lots of patches were folded into their base patches.




Boilerplate:

- See the `hot-fixes' directory for any important updates to this patchset.

- To fetch an -mm tree using git, use (for example)

  git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git 
tag v2.6.16-rc2-mm1
  git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1

- -mm kernel commit activity can be reviewed by subscribing to the
  mm-commits mailing list.

echo subscribe mm-commits | mail [EMAIL PROTECTED]

- If you hit a bug in -mm and it is not obvious which patch caused it, it is
  most valuable if you can perform a bisection search to identify which patch
  introduced the bug.  Instructions for this process are at

http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt

  But beware that this process takes some time (around ten rebuilds and
  reboots), so consider reporting the bug first and if we cannot immediately
  identify the faulty patch, then perform the bisection search.

- When reporting bugs, please try to Cc: the relevant maintainer and mailing
  list on any email.

- When reporting bugs in this kernel via email, please also rewrite the
  email Subject: in some manner to reflect the nature of the bug.  Some
  developers filter by Subject: when looking for messages to read.

- Occasional snapshots of the -mm lineup are uploaded to
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
  the mm-commits list.



Changes since 2.6.20-rc2-mm1:


 origin.patch
 git-acpi.patch
 git-alsa.patch
 git-arm.patch
 git-avr32.patch
 git-cifs.patch
 git-cpufreq.patch
 git-drm.patch
 git-dvb.patch
 git-gfs2-nmw.patch
 git-hid.patch
 git-ia64.patch
 git-ieee1394.patch
 git-input.patch
 git-leds.patch
 git-libata-all.patch
 git-md-accel.patch
 git-mmc.patch
 git-ubi.patch
 git-netdev-all.patch
 git-ioat.patch
 git-ocfs2.patch
 git-parisc.patch
 git-r8169.patch
 git-selinux.patch
 git-pciseg.patch
 git-s390.patch
 git-sh.patch
 git-unionfs.patch
 git-watchdog.patch
 git-wireless.patch
 git-wireless-fixup.patch
 git-ipwireless_cs.patch
 git-gccbug.patch

 git trees

-cyclades-return-closing_wait.patch
-io_apic-needs-apicdefh.patch
-msi-sanely-support-hardware-level-msi-disabling.patch
-msi-fixup-the-msi-enable-disable-logic.patch
-msi-support-masking-msi-irqs-without-a-mask-bit.patch
-ecryptfs-check-xattr-operation-support-fix.patch
-parport-is-an-orphan.patch
-fix-soft-lockup-with-iseries-viocd-driver.patch
-add-config_generic_gpio.patch
-gpio_keys-driver-shouldnt-be-arm-specific.patch
-dz-remove-struct-pt_regs-references.patch
-schedule-wext-rtnl-for-removal.patch
-shmem-and-simple-const-super_operations.patch
-sched-remove-smt-nice.patch
-fb-sm501fb-off-by-1-sysfs-store.patch
-fix-radeon-blanking-return-value.patch
-page-migration-fix-vma-flag-checking.patch
-vmi-timer-fixes-round-two.patch
-vmi-sched-clock-paravirt-op-fix.patch
-vmi-cpu-cycles-fix.patch
-vmi-fix-highpte.patch
-vmi-paravirt-drop-udelay-op.patch
-vmi-pit-override.patch
-vmi-fix-nohz-compile.patch
-vmi-apic-ops.patch
-vmi-smp-fixes.patch
-pvrusb-warning-fix.patch
-git-leds-fixup.patch
-git-leds-make-it-compile.patch
-libata-core-fix-simplex-handling.patch
-libata-dev_config-does-not-need-ap-and-adev-passing.patch
-ide-alim15x3-fix-pio-mode-setup.patch
-ide-cmd64x-fix-pio-mode-setup-take3.patch
-ide-ide-fix-drive-side-80c-cable-check.patch
-ide-cmd64x-fix-recovery-time-calculation.patch
-ide-piix-slc90e66-more-tuneproc-fixing-take2.patch
-ide-ide-get-best-pio-mode-returns-incorrect-iordy-setting-take2.patch
-ide-ide-cs-update-device-table.patch
-ide-ide-fix-pmac-breakage.patch
-ide-pci-adjust-legacy-ide-resource-setting-v2.patch
-ide-siimage-drac4-note.patch
-ide-ide-remove-a-ton-of-pointless-undef-really-slow-io.patch
-ide-ide-max-dma-mode-v2.patch
-ide-ide-remove-obsolete-params-v2.patch
-ide-ide-legacy-params-v2.patch
-ide-delkin_cb-pci_module_init-to-pci_register_driver.patch
-ide-ide-fix-pmac-breakage-fix.patch
-ehea-dynamic-add--remove-port.patch
-ehea-dynamic-add--remove-port-update.patch
-fix-mv643xx_eth-compilation.patch
-parisc-unbreak-setupc-re-command_line.patch
-pcie-fix-section-mismatch-warning.patch
-aer-fix-section-mismatch-warning.patch
-usb-serial-secret-patch.patch

Re: i2c vs nVidia [Re: 2.6.21-rc2-mm1]

2007-03-06 Thread Jean Delvare
Hi Greg, Andrew, J.A.,

On Mon, 5 Mar 2007 16:44:44 -0800, Greg KH wrote:
 On Mon, Mar 05, 2007 at 04:33:20PM -0800, Andrew Morton wrote:
  On Tue, 6 Mar 2007 01:16:21 +0100
  J.A. Magall__n [EMAIL PROTECTED] wrote:
  
   On Fri, 2 Mar 2007 03:00:26 -0800, Andrew Morton [EMAIL PROTECTED] 
   wrote:
   

Temporarily at

  http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/

   
   More things...
   
   Yes, this is related to nVidia driver. First of all, I'm not asking for 
   help
   for a broken closed-source driver. I just want Linux to be 
   foolbullet-proof ;).
   
   As one can expect from a closed-source driver, recent changes in Linux 
   broke it.
   New nVidia drivers include some i2c sensors. The driver worked till 
   2.6.20-rc6-mm3.

This statement is incorrect. Rather:
* New nVidia drivers register their I2C busses with i2c-core (which
  isn't a bad thing.)
* Some nVidia adapters have sensors (this isn't new.)

   Since then, I can't use them. I have tracked down the problem to i2c.
   nVidia driver tries to create 3 i2c devices, and I get this:
   
   **WARNING** I2C adapter driver [NVIDIA i2c adapter 0 at 1:00.0] forgot to 
   specify physical device; fix it!
i2c-10: attach_adapter failed (-16) for driver [w83627hf]
   **WARNING** I2C adapter driver [NVIDIA i2c adapter 1 at 1:00.0] forgot to 
   specify physical device; fix it!
i2c-11: attach_adapter failed (-16) for driver [w83627hf]
   **WARNING** I2C adapter driver [NVIDIA i2c adapter 2 at 1:00.0] forgot to 
   specify physical device; fix it!
i2c-12: attach_adapter failed (-16) for driver [w83627hf]
  
  This problem has always been there - there's a patch in -mm which simply
  converts this message from pr_debug() into printk().

The forgot to specify physical device messages are expected and
harmless, as Andrew said. It's up to nVidia to fix their driver, and it
should be trivial.

The attach_adapter failed messages are not expected, though, and this
is the first report. I'll have to investigate this.

-16 is -EBUSY, it is returned to us by the w83627hf driver which really
has no reason to ever try to attach to the nVidia I2C busses - it is
supposed to only attach to the i2c-isa driver. So I guess that the
i2c-core changes broke i2c-isa somehow.

We should really get rid of i2c-isa now so that we stop wasting our
time with it :(

   Two problems arise:
   - The directories in /sys/class/i2c-adapter/ are created, but trying to ls
 its contents oopses:
   
   last sysfs file: class/i2c-adapter/i2c-0/name
   Modules linked in: nvidia(P) nfsd exportfs lockd nfs_acl sunrpc 
   snd_intel8x0 snd_ens1371 gameport snd_rawmidi snd_ac97_codec w83627hf 
   ac97_bus hwmon_vid snd_pcm hwmon snd_timer i2c_isa snd_page_alloc 
   i2c_i801 snd i2c_dev loop intel_agp agpgart udf e1000 3c59x microcode 
   ohci1394 ieee1394 usblp evdev
   CPU:3
   EIP:0060:[c0194b0c]Tainted: P   VLI
   EFLAGS: 00010202   (2.6.20-jam01 #1)
   EIP is at sysfs_follow_link+0xe6/0x254
   eax: 00020b36   ebx: f329edd8   ecx:    edx: f4ab84d8
   esi: f0df4ee8   edi: 0100   ebp: 0002   esp: f4039ea4
   ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
   Process sensors (pid: 4991, ti=f4038000 task=f7efa540 task.ti=f4038000)
   Stack: f7ee4338 f4039edc f0ef7000 ffea f4ab84d8  c0387128 
   
  c02f76a0 f329edd8 0100 bfd2b6fc c0162b12   
   
    45eb5857 1f6efe56 c2235fc0  f4039f44 
   c011c434
   Call Trace:
[c0162b12] generic_readlink+0x27/0x6e
[c011c434] timespec_trunc+0x18/0x5d
[c011ca11] current_fs_time+0x41/0x50
[c015f43a] sys_readlinkat+0x61/0x7a
[c015f47a] sys_readlink+0x27/0x2b
[c01027ee] sysenter_past_esp+0x5f/0x85
[c02f] __down_interruptible+0xa2/0x10e
===
   Code: 24 18 b8 00 b2 39 c0 e8 6e ba 15 00 8b 44 24 18 85 c0 0f 84 42 01 
   00 00 b8 cc ee 37 c0 e8 dd 73 f9 ff 8b 44 24 10 31 ed 83 c5 01 8b 40 24 
   85 c0 75 f6 8b 44 24 18 89 04 24 bb 01 00 00 00 31 f6 
   EIP: [c0194b0c] sysfs_follow_link+0xe6/0x254 SS:ESP 0068:f4039ea4
   BUG: at lib/kref.c:32 kref_get()
[c01ec858] kref_get+0x3d/0x3f
[c01ebcd6] kobject_get+0xf/0x13
[c0194c00] sysfs_follow_link+0x1da/0x254
[c0162b12] generic_readlink+0x27/0x6e
[c011c434] timespec_trunc+0x18/0x5d
[c011ca11] current_fs_time+0x41/0x50
[c015f43a] sys_readlinkat+0x61/0x7a
[c015f47a] sys_readlink+0x27/0x2b
[c01027ee] sysenter_past_esp+0x5f/0x85
[c02f] __down_interruptible+0xa2/0x10e
===
   
   - As adapters do not get a driver (or what ?), each time you start X, 
   three
 new folders are created in /sys/class/i2c-adapter/

It is true that i2c adapters no longer have a driver, but my
understanding is that this is expected for ex-class devices. Greg, can
you please confirm this?

 For some AGP black magic, the driver is loaded/registered/whatever 2 
  

Re: SATA resume slowness, e1000 MSI warning

2007-03-06 Thread Ingo Molnar

* Kok, Auke [EMAIL PROTECTED] wrote:

 BUG: at drivers/pci/msi.c:611 pci_enable_msi()

 I would poke Eric Biederman(sp?) about this one.  Maybe its even 
 solved by the MSI-enable-related patch he posted in the past 24-48 
 hours.
 
 I tried the 3-patch series [PATCH 0/3] Basic msi bug fixes.. and 
 they fix this problem for me. Were you expecting the OOPS in the first 
 place? [...]

the bug was the warning message (a WARN_ON()) above - not an oops. So 
that warning message is gone in your testing?

Ingo
-
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.21-rc2-mm2

2007-03-06 Thread J.A. Magallón
On Tue, 6 Mar 2007 00:44:08 -0800, Andrew Morton [EMAIL PROTECTED] wrote:

 
 Temporarily at
 
   http://userweb.kernel.org/~akpm/2.6.21-rc2-mm2/
 

Does this include a fix for the NFS problem ?

BTW, I have in my kernel a patch like this below, isn't it needed ?
Original thread:

http://marc.theaimsgroup.com/?l=linux-kernelm=117189051227292w=2

--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -2919,14 +2919,14 @@ static int __make_request(request_queue_
 */
blk_queue_bounce(q, bio);
 
+   spin_lock_irq(q-queue_lock);
/*
 * Check if we can merge with the plugged list before grabbing
 * any locks.
 */
if (!check_plug_merge(q, ioc, bio))
-   goto out;
+   goto out_unlock;
 
-   spin_lock_irq(q-queue_lock);
el_ret = elv_merge(q, req, bio);
if (el_ret == ELEVATOR_BACK_MERGE) {
if (bio_attempt_back_merge(q, req, bio)) {
@@ -2984,7 +2984,6 @@ out_unlock:
list_add_tail(req-queuelist, ioc-plugged_list);
}
 
-out:
return 0;
 
 end_io_eopnotsupp:

--
J.A. Magallon jamagallon()ono!com \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2007.1 (Cooker) for i586
Linux 2.6.20-jam01 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP 
PREEMPT
-
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: SATA resume slowness, e1000 MSI warning

2007-03-06 Thread Ingo Molnar

* Ingo Molnar [EMAIL PROTECTED] wrote:

 with real resume it takes even longer time - but i dont see where the 
 delays come from in that case - i suspect it's SATA.

update: Thomas' PIT/HPET resume-fix patch fixed the delay for me.

Ingo
-
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] Kconfig: Update swsusp description

2007-03-06 Thread Rafael J. Wysocki
On Tuesday, 6 March 2007 09:32, Pavel Machek wrote:
 Hi!
 
  Index: linux-2.6.21-rc2/kernel/power/Kconfig
  ===
  --- linux-2.6.21-rc2.orig/kernel/power/Kconfig  2007-02-28 
  23:54:45.0 +0100
  +++ linux-2.6.21-rc2/kernel/power/Kconfig   2007-03-04 11:50:48.0 
  +0100
  @@ -81,30 +81,35 @@ config SOFTWARE_SUSPEND
  bool Software Suspend
  depends on PM  SWAP  ((X86  (!SMP || SUSPEND_SMP)) || ((FRV || 
  PPC32)  !SMP))
  ---help---
  + Enable the suspend to disk (STD) functionality.
   
  + You can suspend your machine with 'echo disk  /sys/power/state'.
  + Alternatively, you can use the additional userland tools available
  + from http://suspend.sf.net.
  +
  + In principle it does not require ACPI or APM, although for example
  + ACPI will be used if available.
  +
  + It creates an image which is saved in your active swap. Upon the next
boot, pass the 'resume=/dev/swappartition' argument to the kernel to
 
 Actually, these days resume=... on kernel command line needs to be
 there for suspend, too, IIRC.

I didn't change this line, so?
 
  + Right now you may boot without resuming and resume later but in the
  + meantime you cannot use the swap partition(s)/file(s) involved in
  + suspending.  Also in this case you must not use the
 
 I'd prefer not to encourage this use. It has too many traps ready for
 people.

But IMHO there should be a warning that if you boot without resuming, make sure
you'll not resume after the next reboot or bad things will happen.

Greetings,
Rafael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] paravirt: VDSO page is essential

2007-03-06 Thread Roland McGrath
 -# define VDSO_PRELINK  VDSO_HIGH_BASE
 +# ifndef CONFIG_XEN
 +#  define VDSO_PRELINK VDSO_HIGH_BASE
 +# else
 +#  define VDSO_PRELINK (0UL - FIX_VDSO * PAGE_SIZE)
 +# endif
 
 should be Kconfig driven, not #ifdef driven, due to cleanliness and also 
 because lguest wants to have the same thing. Plus:

In fact, with the relocate_vdso stuff it doesn't matter what VDSO_PRELINK
is at compile time.  It saves the small amount of startup cost if it
matches the runtime address, but that is probably not noticeable.

 furthermore, there should be a paravirt_ops method to chose the 
 relocation address, unless i'm missing something. On the native kernel 
 that address will default to 0xe000. (if CONFIG_COMPAT_VDSO is 
 selected)

For everything else to work, it needs to be set by changing __FIXADDR_TOP,
which seems to be done by calling reserve_top_address early enough.
It looks like that needs to be properly tied into paravirt_ops somehow.


Thanks,
Roland
-
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] paravirt: VDSO page is essential

2007-03-06 Thread Jeremy Fitzhardinge
Roland McGrath wrote:
 For everything else to work, it needs to be set by changing __FIXADDR_TOP,
 which seems to be done by calling reserve_top_address early enough.
 It looks like that needs to be properly tied into paravirt_ops somehow.
   

The startup code for whatever hypervisor you're running makes a call to
reserve_top to reserve the appropriate amount of address space.  This
happens very early.

J
-
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: Question: schedule()

2007-03-06 Thread albcamus

your kthread IS preemptible unless you call preempt_disable or some
locking functions explicitly .

Regards,
albcamus

2007/3/6, Mockern [EMAIL PROTECTED]:

Hi,

What does schedule() function do? I want to make my kthread preemptive.

Thanks
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


-
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.21-rc2-mm2

2007-03-06 Thread Andrew Morton
On Tue, 6 Mar 2007 10:06:23 +0100 J.A. Magallón [EMAIL PROTECTED] wrote:

 On Tue, 6 Mar 2007 00:44:08 -0800, Andrew Morton [EMAIL PROTECTED] wrote:
 
  
  Temporarily at
  
http://userweb.kernel.org/~akpm/2.6.21-rc2-mm2/
  
 
 Does this include a fix for the NFS problem ?

Which NFS problem?

 BTW, I have in my kernel a patch like this below, isn't it needed ?
 Original thread:
 
 http://marc.theaimsgroup.com/?l=linux-kernelm=117189051227292w=2

That patch caused additional failures.  But I tossed out the git-block tree,
so that problem should no longer be there.

-
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: Trouble using some (fast) compact flash as ide device on an embedded system

2007-03-06 Thread Marco Lazzarotto
Ciao!

Bartlomiej Zolnierkiewicz ha scritto:
 On Friday 02 March 2007, Pavel Machek wrote:
 
Hi!


As I reported in bug 8036 in bugzilla.kernel.org,

Hardware Environment:

 - Use a compact flash SanDisk SDCFB-128 Firmware revision HDX 2.15
   (we used other compact flashes with the same hw ad sw for years
with  no trouble)

It happens on both etx boards:
 - VIA SOM-ETX (4475)
 - Gene-4312

ERRATA CORRIGE: Gene-4312 is not a etx board ;-) but a pc/104


Doing the command
sfdisk -R /dev/hdc

gives:

 * * *
ide1: start_request: current=0xc6ebe754 (rq-sect=0,block 0)
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hdc: drive not ready for command
ide1: start_request: current=0xc6ebe754 (rq-sect=0,block 0)
hdc: do_special: 0x02
hdc: do_special: recalibrate
ide1: start_request: current=0xc6ebe754 (rq-sect=0,block 0)
hdc: reading: block=0 sectors=8, buffer = 0xc6cd4
ide1: end_request: current=0xc6ebe754
 * * *

the 'bad bit' in status error is DataRequest



doing
sfdisk -l /dev/hdc

gives:

 * * *
ide1: start_request: current=0xc6ebecd4 (rq-sect=0,block 0)
hdc: reading: block=0, sectors=32, buffer=0xc6f37000
hdc: lost interrupt
hdc: lost interrupt [and so on several times]
 * * *

I have no knowledge of the internals of the linux kernel, but I'm a
programmer and have both hardware and time to spend on solving this issue.

Debug it, then :-). Try limiting its speed with hdparm to see if it
helps.

I tried hdparm -p 0 /dev/hdc but nothing changes

 I would suggest trying booting with ide=nodma first.

I tried this too, without success.
I disabled 'Use PCI DMA by default when available' in the kernel, if
this is enabled the message 'hdc: lost interrupt' comes when the kernel
tries to access the CF for the first time.

 * * * Other information : * * *

If I try hdparm -I /dev/hdc immediately after boot I receive:

/ # hdparm -I /dev/hdc

/dev/hdc:
hdc: ide_cmd_ioctl()
hdc: ide_do_drive_cmd()
ide1: start_request: current=0xc6e1dcc8 (rq-sect=0,block0)
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: 0xec
hdc: drive not ready for command

ATA device, with non-removable media
Standards:
Likely used: 1
Configuration:
Logical max current
cylinders   0   0
heads   0   0
sectors/track   0   0
--
device size with M = 1024*1024:   0 MBytes
device size with M = 1000*1000:   0 MBytes
Capabilities:
IORDY not likely
Cannot perform double-word IO
R/W multiple sector transfer: not supported
DMA: not supported
PIO: pio0
/ #

Then, I must do for example

/ # dd if=/dev/hdc of=/dev/null bs=512 count=1 skip=128

ide1: start_request: current=0xc6e7fcd4 (rq-sect=128,block 128)
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hdc: GOOD BITS   : ATA status=0x40 { DriveReady }
ide: failed opcode was: unknown
hdc: BAD BITS: ATA status=0x08 { DataRequest }
ide: failed opcode was: unknown
hdc: drive not ready for command
ide1: start_request: current=0xc6e7fcd4 (rq-sect=128,block 128)
hdc: do_special: 0x02
hdc: do_special: recalibrate
ide1: start_request: current=0xc6e7fcd4 (rq-sect=128,block 128)
hdc: reading: block=128, sectors=8, buffer=0xc1306000
ide1: end_request:   current=0xc6e7fcd4
1+0 record in
1+0 record out
/ #

The lines with 'GOOD BITS' and 'BAD BITS' is debugging made by me in
drivers/ide/ide-iops.c :
*startstop = ide_error(drive, status error, stat);
+   *startstop = ide_error(drive, GOOD BITS   , (stat  good));
+   *startstop = ide_error(drive, BAD BITS, (stat  bad));

After that, redoing the command
/ # dd if=/dev/hdc of=/dev/null bs=512 count=1 skip=128
does not give an error, and

/ # hdparm -I /dev/hdc  # gives:

CompactFlash ATA device, with removable media
Model Number:   SanDisk SDCFB-128
Serial Number:  012101G0604F3431
Firmware Revision:  HDX 2.15
Standards:
Supported: 10
Likely used: 10
Configuration:
Logical max current
cylinders   980 497
heads   8   8
sectors/track   32  63
--
CHS current addressable sectors: 250488
LBAuser addressable sectors: 250880
device size with M = 1024*1024: 122 MBytes
device size with M = 1000*1000: 128 MBytes
Capabilities:
LBA, IORDY(may be)(cannot be disabled)
Standby timer values: spec'd by Vendor
R/W multiple sector transfer: Max = 1   Current = 1
DMA: mdma0 mdma1 *mdma2
 Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
 Cycle time: no flow control=120ns  IORDY flow control=120ns
Integrity word not set (found 0x, expected 0x10a5)

/ #

after that,

/ # dd if=/dev/hdc of=/dev/null 

Re: [S390] system call cleanup.

2007-03-06 Thread Martin Schwidefsky
On Tue, 2007-03-06 at 07:27 +, Christoph Hellwig wrote:
  +   struct pt_regs *regs = task_pt_regs(current);
  +   char *filename;
  +   unsigned long result;
  +   int rc;
  +
  +   filename = getname(compat_ptr(regs-orig_gpr2));
  +   if (IS_ERR(filename)) {
  +   result = PTR_ERR(filename);
   goto out;
 
 The old code here..
 
  +   struct pt_regs *regs = task_pt_regs(current);
   unsigned long clone_flags;
   unsigned long newsp;
  int __user *parent_tidptr, *child_tidptr;
 
 ..and here..
 
  +asmlinkage long sys_clone(void)
   {
  +   struct pt_regs *regs = task_pt_regs(current);
   unsigned long clone_flags;
   unsigned long newsp;
  int __user *parent_tidptr, *child_tidptr;
 
 ..and here used spaces instead of tabs, it would be nice to clean this
 up while you're at it.

Will do, thanks for the hint.

-- 
blue skies,  IBM Deutschland Entwicklung GmbH
   MartinVorsitzender des Aufsichtsrats: Johann Weihen
 Geschäftsführung: Herbert Kircher
Martin Schwidefsky   Sitz der Gesellschaft: Böblingen
Linux on zSeries Registergericht: Amtsgericht Stuttgart,
   Development   HRB 243294

Reality continues to ruin my life. - Calvin.


-
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: PAGE_SIZE Availability Inconsistency

2007-03-06 Thread Christoph Hellwig
On Mon, Mar 05, 2007 at 03:55:06PM -0800, David Brown wrote:
 I was rtfc'ing the code one day and noticed somethings about the
 PAGE_SIZE define that is kinda inconsistent around its relative
 location to the __KERNEL__ define.
 
 On some architectures the PAGE_SIZE is outside the __KERNEL__ define
 (i386 and x86_64) and on others its inside the define (ia64 and
 powerpc).  I was wondering if this is because the powerpc and ia64
 architectures have dynamic page sizes so that's why they can't export
 PAGE_SIZE outside __KERNEL__.
 
 I'm kinda wondering how I'm supposed to write portable user-space code
 if I want to use the PAGE_SIZE define on different architectures.

PAGE_SIZE should not be available at all.  Please use getpagesize()
instead.
-
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: Question: schedule()

2007-03-06 Thread Schmidt Michal

Mockern wrote:

Hi,

What does schedule() function do? I want to make my kthread preemptive.


It makes a scheduling decision, i.e. it assigns the CPU time to a
suitable runnable task. If called with the current task's state set to 
TASK_(UN)INTERRUPTIBLE, it puts the task to sleep.
Kernel threads are preemptible if the kernel is configured with 
CONFIG_PREEMPT.

What exactly are you trying to do?

If you're new to Linux kernel programming, I suggest you read Robert
Love's book Linux Kernel Development.
Linux Device Drivers by J.Corbet, A.Rubini and G.Kroah-Hartman will be
very helpful too and it is available online: http://lwn.net/Kernel/LDD3/

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


BUG in kernel-rt 2.6.20-0119.rt8

2007-03-06 Thread Zoltan Boszormenyi

Hi,

I am using kernel-rt on my FC6/x86-64 system,
the CPU is an Athlon64 X2.

It locks up very rarely (I haven't found any sign in the logs for that)
but I always get this on shutdown, I wonder if it might be related
to the lockup:

Mar  5 23:53:52 static-81-17-177-202 kernel: BUG: using 
smp_processor_id() in preemptible [] code: nfsd/3939
Mar  5 23:53:52 static-81-17-177-202 kernel: caller is 
drain_array+0x25/0x132

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: Call Trace:
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8026d828] 
dump_trace+0xbd/0x3d8
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8026db87] 
show_trace+0x44/0x6d
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8026ddc8] 
dump_stack+0x13/0x15
Mar  5 23:53:52 static-81-17-177-202 kernel:  [80355e2e] 
debug_smp_processor_id+0xe3/0xf1
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802e01b5] 
drain_array+0x25/0x132
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802e07ac] 
__cache_shrink+0xd5/0x1a6
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802e0a47] 
kmem_cache_destroy+0x6c/0xe3
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8878a809] 
:nfsd:nfsd4_free_slab+0x16/0x21
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8878a824] 
:nfsd:nfsd4_free_slabs+0x10/0x36
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8878baf9] 
:nfsd:nfs4_state_shutdown+0x1a2/0x1ae
Mar  5 23:53:52 static-81-17-177-202 kernel:  [887750f8] 
:nfsd:nfsd_last_thread+0x47/0x76
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8867f63a] 
:sunrpc:svc_destroy+0x8d/0xd1
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8867f738] 
:sunrpc:svc_exit_thread+0xba/0xc6
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8877595f] 
:nfsd:nfsd+0x2a3/0x2b8
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802600f8] 
child_rip+0xa/0x12

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: ---
Mar  5 23:53:52 static-81-17-177-202 kernel: | preempt count: 0001 ]
Mar  5 23:53:52 static-81-17-177-202 kernel: | 1-level deep critical 
section nesting:
Mar  5 23:53:52 static-81-17-177-202 kernel: 

Mar  5 23:53:52 static-81-17-177-202 kernel: .. [80355ddb] 
 debug_smp_processor_id+0x90/0xf1
Mar  5 23:53:52 static-81-17-177-202 kernel: .[802e01b5] 
..   ( = drain_array+0x25/0x132)

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: BUG: nfsd:3939 task might 
have lost a preemption check!

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: Call Trace:
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8026d828] 
dump_trace+0xbd/0x3d8
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8026db87] 
show_trace+0x44/0x6d
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8026ddc8] 
dump_stack+0x13/0x15
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8028be9b] 
preempt_enable_no_resched+0x5c/0x5e
Mar  5 23:53:52 static-81-17-177-202 kernel:  [80355e33] 
debug_smp_processor_id+0xe8/0xf1
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802e01b5] 
drain_array+0x25/0x132
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802e07ac] 
__cache_shrink+0xd5/0x1a6
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802e0a47] 
kmem_cache_destroy+0x6c/0xe3
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8878a809] 
:nfsd:nfsd4_free_slab+0x16/0x21
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8878a824] 
:nfsd:nfsd4_free_slabs+0x10/0x36
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8878baf9] 
:nfsd:nfs4_state_shutdown+0x1a2/0x1ae
Mar  5 23:53:52 static-81-17-177-202 kernel:  [887750f8] 
:nfsd:nfsd_last_thread+0x47/0x76
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8867f63a] 
:sunrpc:svc_destroy+0x8d/0xd1
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8867f738] 
:sunrpc:svc_exit_thread+0xba/0xc6
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8877595f] 
:nfsd:nfsd+0x2a3/0x2b8
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802600f8] 
child_rip+0xa/0x12

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: ---
Mar  5 23:53:52 static-81-17-177-202 kernel: | preempt count:  ]
Mar  5 23:53:52 static-81-17-177-202 kernel: | 0-level deep critical 
section nesting:
Mar  5 23:53:52 static-81-17-177-202 kernel: 


Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: BUG: using 
smp_processor_id() in preemptible [] code: nfsd/3939
Mar  5 23:53:52 static-81-17-177-202 kernel: caller is 
drain_array+0x25/0x132

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: Call Trace:
Mar  5 

Re: [PATCH -mm] utrace: nommu fixup support utrace

2007-03-06 Thread David Howells
Wu, Bryan [EMAIL PROTECTED] wrote:

 When adding utrace support to blackfin architecture, I found a compiling
 error in nommu related utrace stuff. Then this little patch will fix
 this for nommu arch utrace.

You really don't want to do it like this.  This prevents ELF shared libraries
from being shared at all if UTRACE is enabled.

David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.21-rc2-mm2

2007-03-06 Thread J.A. Magallón
On Tue, 6 Mar 2007 01:15:24 -0800, Andrew Morton [EMAIL PROTECTED] wrote:

 On Tue, 6 Mar 2007 10:06:23 +0100 J.A. Magallón [EMAIL PROTECTED] wrote:
 
  On Tue, 6 Mar 2007 00:44:08 -0800, Andrew Morton [EMAIL PROTECTED] wrote:
  
   
   Temporarily at
   
 http://userweb.kernel.org/~akpm/2.6.21-rc2-mm2/
   
  
  Does this include a fix for the NFS problem ?
 
 Which NFS problem?
 

http://marc.theaimsgroup.com/?l=linux-kernelm=117305359825926w=2

  BTW, I have in my kernel a patch like this below, isn't it needed ?
  Original thread:
  
  http://marc.theaimsgroup.com/?l=linux-kernelm=117189051227292w=2
 
 That patch caused additional failures.  But I tossed out the git-block tree,
 so that problem should no longer be there.
 

OK, thanks.

--
J.A. Magallon jamagallon()ono!com \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2007.1 (Cooker) for i586
Linux 2.6.20-jam01 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP 
PREEMPT
-
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] Kconfig: Update swsusp description

2007-03-06 Thread Pavel Machek
Hi!

   Index: linux-2.6.21-rc2/kernel/power/Kconfig
   ===
   --- linux-2.6.21-rc2.orig/kernel/power/Kconfig2007-02-28 
   23:54:45.0 +0100
   +++ linux-2.6.21-rc2/kernel/power/Kconfig 2007-03-04 11:50:48.0 
   +0100
   @@ -81,30 +81,35 @@ config SOFTWARE_SUSPEND
 bool Software Suspend
 depends on PM  SWAP  ((X86  (!SMP || SUSPEND_SMP)) || ((FRV || 
   PPC32)  !SMP))
 ---help---
   +   Enable the suspend to disk (STD) functionality.

   +   You can suspend your machine with 'echo disk  /sys/power/state'.
   +   Alternatively, you can use the additional userland tools available
   +   from http://suspend.sf.net.
   +
   +   In principle it does not require ACPI or APM, although for example
   +   ACPI will be used if available.
   +
   +   It creates an image which is saved in your active swap. Upon the next
   boot, pass the 'resume=/dev/swappartition' argument to the kernel to
  
  Actually, these days resume=... on kernel command line needs to be
  there for suspend, too, IIRC.
 
 I didn't change this line, so?

So I should go and fix it ;-). (I'm now overloaded with email sorry
for being terse.)

Can we do something like

+ Enable the suspend to disk (STD) functionality.
+ In principle it does not require any support from BIOS, although 
+ ACPI will be used if available.

+ You can suspend your machine with 'echo disk 
+ /sys/power/state' after placing resume=/dev/swappartition on
+ kernel command line.
+ Alternatively, you can use the additional userland tools available
+ from http://suspend.sf.net.

(and remove ...upon next boot... section).

   +   Right now you may boot without resuming and resume later but in the
   +   meantime you cannot use the swap partition(s)/file(s) involved in
   +   suspending.  Also in this case you must not use the
  
  I'd prefer not to encourage this use. It has too many traps ready for
  people.
 
 But IMHO there should be a warning that if you boot without resuming, make 
 sure
 you'll not resume after the next reboot or bad things will happen.

+   It is possible to boot without resuming and resume later but
+   if you access any partitions/files used by suspended kernel,
+   you'll probably loose your data. See ... for details.

?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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.21-rc2-mm2

2007-03-06 Thread Andrew Morton
On Tue, 6 Mar 2007 10:38:23 +0100 J.A. Magallón [EMAIL PROTECTED] wrote:

 On Tue, 6 Mar 2007 01:15:24 -0800, Andrew Morton [EMAIL PROTECTED] wrote:
 
  On Tue, 6 Mar 2007 10:06:23 +0100 J.A. Magallón [EMAIL PROTECTED] wrote:
  
   On Tue, 6 Mar 2007 00:44:08 -0800, Andrew Morton [EMAIL PROTECTED] 
   wrote:
   

Temporarily at

  http://userweb.kernel.org/~akpm/2.6.21-rc2-mm2/

   
   Does this include a fix for the NFS problem ?
  
  Which NFS problem?
  
 
 http://marc.theaimsgroup.com/?l=linux-kernelm=117305359825926w=2

yup, that got fixed.
-
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.21-rc2-mm2

2007-03-06 Thread J.A. Magallón
On Tue, 6 Mar 2007 01:42:40 -0800, Andrew Morton [EMAIL PROTECTED] wrote:

 On Tue, 6 Mar 2007 10:38:23 +0100 J.A. Magallón [EMAIL PROTECTED] wrote:
 
  On Tue, 6 Mar 2007 01:15:24 -0800, Andrew Morton [EMAIL PROTECTED] wrote:
  
   On Tue, 6 Mar 2007 10:06:23 +0100 J.A. Magallón [EMAIL PROTECTED] 
   wrote:
   
On Tue, 6 Mar 2007 00:44:08 -0800, Andrew Morton [EMAIL PROTECTED] 
wrote:

 
 Temporarily at
 
   http://userweb.kernel.org/~akpm/2.6.21-rc2-mm2/
 

Does this include a fix for the NFS problem ?
   
   Which NFS problem?
   
  
  http://marc.theaimsgroup.com/?l=linux-kernelm=117305359825926w=2
 
 yup, that got fixed.

Thanks, I will build it tonite...

--
J.A. Magallon jamagallon()ono!com \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2007.1 (Cooker) for i586
Linux 2.6.20-jam01 (gcc 4.1.2 20070302 (prerelease) (4.1.2-1mdv2007.1)) #2 SMP 
PREEMPT
-
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 -mm] utrace: nommu fixup support utrace

2007-03-06 Thread Wu, Bryan
On Tue, 2007-03-06 at 09:37 +, David Howells wrote:
 Wu, Bryan [EMAIL PROTECTED] wrote:
 
  When adding utrace support to blackfin architecture, I found a compiling
  error in nommu related utrace stuff. Then this little patch will fix
  this for nommu arch utrace.
 
 You really don't want to do it like this.  This prevents ELF shared libraries
 from being shared at all if UTRACE is enabled.
 
 David

Got it, I will find another way to fix this.
Now, I just make it compile pass. 

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


[kj]patch7:replace pci_find_device in sound/oss/trident.c

2007-03-06 Thread Surya
Hi,
 Cleanup of pci_find_device to pci_get_device in sound/oss/trident.c
Applies and compiles clean to latest Linus tree. Not tested!

thanks..


Signed-off-by: Surya Prabhakar [EMAIL PROTECTED]
--- 

diff --git a/sound/oss/trident.c b/sound/oss/trident.c
index 72a8a0e..882ab27 100644
--- a/sound/oss/trident.c
+++ b/sound/oss/trident.c
@@ -4450,8 +4450,8 @@ trident_probe(struct pci_dev *pci_dev, c
 
/* Add H/W Volume Control By Matt Wu Jul. 06, 2001 */
card-hwvolctl = 0;
-   pci_dev_m1533 = pci_find_device(PCI_VENDOR_ID_AL, 
-   PCI_DEVICE_ID_AL_M1533, 
+   pci_dev_m1533 = pci_get_device(PCI_VENDOR_ID_AL,
+   PCI_DEVICE_ID_AL_M1533,
pci_dev_m1533);
rc = -ENODEV;
if (pci_dev_m1533 == NULL)
@@ -4481,6 +4481,7 @@ trident_probe(struct pci_dev *pci_dev, c
 
/* claim our irq */
rc = -ENODEV;
+   pci_dev_put(pci_dev_m1533);
if (request_irq(card-irq, trident_interrupt, IRQF_SHARED,
card_names[pci_id-driver_data], card)) {
printk(KERN_ERR trident: unable to allocate irq %d\n, 

-- 
surya.
-
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] Use a zero-size array in the struct devres

2007-03-06 Thread Catalin Marinas
Commit 9ac7849e35f705830f7b016ff272b0ff1f7ff759 adds the devres
structure containing a flexible unsigned long long array, with a
comment about the guaranteed alignment. According to the gcc manual,
flexible arrays are considered incomplete types and it is an error to
ask for their alignment. This patch makes data[] a zero-size array.

Signed-off-by: Catalin Marinas [EMAIL PROTECTED]
---

I came across this when trying to build kmemleak as the modified
container_of macro tries to get the size of the devres.data member and
sizeof cannot be applied to incomplete types.

 drivers/base/devres.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index e177c95..0d6c067 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -22,7 +22,7 @@ struct devres_node {
 struct devres {
struct devres_node  node;
/* -- 3 pointers */
-   unsigned long long  data[]; /* guarantee ull alignment */
+   unsigned long long  data[0];/* guarantee ull 
alignment */
 };
 
 struct devres_group {

-
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 3/3][RFC] Containers: Pagecache controller reclaim

2007-03-06 Thread Kari Hurtta
Vaidyanathan Srinivasan [EMAIL PROTECTED] writes
in gmane.linux.kernel,gmane.linux.kernel.mm:

 --- linux-2.6.20.orig/mm/pagecache_acct.c
 +++ linux-2.6.20/mm/pagecache_acct.c
 @@ -29,6 +29,7 @@
  #include linux/uaccess.h
  #include asm/div64.h
  #include linux/pagecache_acct.h
 +#include linux/memcontrol.h
 
  /*
   * Convert unit from pages to kilobytes
 @@ -337,12 +338,20 @@ int pagecache_acct_cont_overlimit(struct
   return 0;
  }
 
 -extern unsigned long shrink_all_pagecache_memory(unsigned long nr_pages);
 +extern unsigned long shrink_container_memory(unsigned int memory_type,
 + unsigned long nr_pages, void *container);
 
  int pagecache_acct_shrink_used(unsigned long nr_pages)
  {
   unsigned long ret = 0;
   atomic_inc(reclaim_count);
 +
 + /* Don't call reclaim for each page above limit */
 + if (nr_pages  NR_PAGES_RECLAIM_THRESHOLD) {
 + ret += shrink_container_memory(
 + RECLAIM_PAGECACHE_MEMORY, nr_pages, NULL);
 + }
 +
   return 0;
  }
 

'ret' is not used ?

/ Kari Hurtta

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


Makefile for module with multiple directories

2007-03-06 Thread Rick Brown

Hi,

I want to compile a kernel module whose source is organized in a
directory hierarchy. For eg:

driver
  |---A
  ||---1.c
  ||---2.c
  |
  |---B
   |---3.c
   |---4.c

I want to compile a single module (.ko) out of these source files. Can
you please suggest me a Makefile?

Thanks,

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


BUG() during suspend to disk (2.6.21-rc2, x86_64)

2007-03-06 Thread Vivek Goyal
Hi,

I see following BUG() on serial console while hibernating on a x86_64
machine. I am using 2.6.21-rc2 kernel.


BUG: at arch/x86_64/kernel/acpi/sleep.c:70 init_low_mapping()

Call Trace:
 [80214b9a] acpi_save_state_mem+0x70/0xd6
 [8036e90e] acpi_pm_enter+0x23/0xc1
 [8024eec4] pm_suspend_disk+0x1ac/0x228
 [8024dc9b] enter_state+0x50/0x1e6
 [8036ecce] acpi_system_write_sleep+0x5c/0x79
 [8027b767] vfs_write+0xad/0x136
 [8027bca4] sys_write+0x45/0x6e
 [80209bbe] system_call+0x7e/0x83

Thanks
Vivek

-
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: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Michael S. Tsirkin
 Quoting Linus Torvalds [EMAIL PROTECTED]:

 Ok, it does indeed solve the problem for me.

Not yet for me unfortunately, although this seems to help.
Is this the patch I should have applied?
http://lkml.org/lkml/2007/3/5/445

With this applied, on resume I get *some* screen output soon after resume
(e.g. with s2ram I get several characters on VGA, X starts drawing some windows)
but then the crescent symbol starts blinking again and the system hangs.

Could this be the ACPI problem Thomas mentions (acpi_processor_start is not 
called
when CPU#1 is resumed)?

-- 
MST
-
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: 2.6.20-1 not working on ibook g4 (BUG/Oops)

2007-03-06 Thread David Woodhouse
On Tue, 2007-03-06 at 14:53 +1300, Paul Collins wrote:
 In case it's of interest, 2.6.20 has been running fine on my
 PowerBook5,4. 

How much memory? What if you boot with mem=512M or mem=256M?

It works fine on my PowerBook5,3 unless I do that.

-- 
dwmw2

-
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: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Michael S. Tsirkin
 Quoting Linus Torvalds [EMAIL PROTECTED]:

 Ok, it does indeed solve the problem for me.

Not yet for me unfortunately, although this seems to help.
Is this the patch I should have applied?
http://lkml.org/lkml/2007/3/5/445

With this applied, on resume I get *some* screen output soon after resume
(e.g. with s2ram I get several characters on VGA, X starts drawing some windows)
but then the crescent symbol starts blinking again and the system hangs.

Could this be the ACPI problem Thomas mentions (acpi_processor_start is not 
called
when CPU#1 is resumed)?

-- 
MST
-
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: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Ingo Molnar

* Michael S. Tsirkin [EMAIL PROTECTED] wrote:

  Quoting Linus Torvalds [EMAIL PROTECTED]:
 
  Ok, it does indeed solve the problem for me.
 
 Not yet for me unfortunately, although this seems to help.
 Is this the patch I should have applied?
 http://lkml.org/lkml/2007/3/5/445
 
 With this applied, on resume I get *some* screen output soon after 
 resume (e.g. with s2ram I get several characters on VGA, X starts 
 drawing some windows) but then the crescent symbol starts blinking 
 again and the system hangs.

could you try this via s2ram on a text console, to see whether the 
kernel spits out any warning before it locks up?

Ingo
-
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: khubd and ent:sda1 sucking CPU with reiser4 + USB HD

2007-03-06 Thread Oliver Neukum
Am Dienstag, 6. März 2007 05:13 schrieb Eric Buddington:
 reiser4[khubd(163)]: commit_current_atom 
 (fs/reiser4/txnmgr.c:1049)[nikita-3176]:
 WARNING: Flushing like mad: 16384
 reiser4[khubd(163)]: commit_current_atom 
 (fs/reiser4/txnmgr.c:1049)[nikita-3176]:
 WARNING: Flushing like mad: 32768
 ...many simiar messages
 
 Most problematically, khubd and ent:sda1! are conspiring to suck 100%
 CPU time, even after powering off the drive. A bunch of processes are
 stuck in 'D' state, possibly because they're trying to access the dead
 disk, which won't umount (device is busy).

It looks like khubd allocates memory and enters reiser4. Possibly we have
GFP_KERNEL in khubd where we should have GFP_NOIO or reiser4 has
a problem dealing with IO failures.

Regards
Oliver

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [linux-usb-devel] [DOC] The documentation for HID Simple Driver Interface 0.5.0

2007-03-06 Thread Jiri Kosina
On Tue, 6 Mar 2007, Li Yu wrote:

  If we define HID bus allowing drivers to bind on VID:PID and provide 
  default library module for parsing HID reports and providing access to 
  HID transports (USB/BT) then writing tiny drivers adjusting just a 
  part of hid_input_event and relying on default implemenattaion where 
  it makes sense will become a breeze.
 But (You may guess I will say this word :), before the HID bus or other 
 better implementation come , I hope use the extended keys of my keyboard 
 on Linux, and I guess other people also think same with me, so we need 
 something here temporarily, even it do not merge into upstream code 
 tree.
 And, I want to know that is somebody works on HID bus, Can I join it?

I will probably start working on it one day. Anyway some parts of what 
Dmitry described are already in the mainline since 2.6.20 - the parser 
code (and hid_device registration and initialization in general) is 
already there. Access to transport layers (USB/BT) is partly also there 
(see hid_open(), hid_close() and hidinput_input_event() callbacks in 
struct hid_device). So really the only one pending thing which is 
non-trivial would be creating an interface for registering the device 
driver for given VID/PID on the HID bus, and solving the fallback 
mechanism, i.e. assuring that everything works for drivers which are OK 
with generic hid and hid-input behavior.

I will happily accept such patches from you, if you do them. Otherwise I 
will start to work on it in a future anyway.

Thanks,

-- 
Jiri Kosina
-
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: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Michael S. Tsirkin
 Quoting Ingo Molnar [EMAIL PROTECTED]:
 Subject: Re: [5/6] 2.6.21-rc2: known regressions
 
 
 * Michael S. Tsirkin [EMAIL PROTECTED] wrote:
 
   Quoting Linus Torvalds [EMAIL PROTECTED]:
  
   Ok, it does indeed solve the problem for me.
  
  Not yet for me unfortunately, although this seems to help.
  Is this the patch I should have applied?
  http://lkml.org/lkml/2007/3/5/445
  
  With this applied, on resume I get *some* screen output soon after 
  resume (e.g. with s2ram I get several characters on VGA, X starts 
  drawing some windows) but then the crescent symbol starts blinking 
  again and the system hangs.
 
 could you try this via s2ram on a text console, to see whether the 
 kernel spits out any warning before it locks up?

Yes, that's what I did. Unfortunately only a couple of characters were
shown before it locked up.

I still need to check what does this do in the NO_HZ configuration.

BTW, Ingo, can you suspend/resume any number of times with this patch?

-- 
MST
-
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: i2c vs nVidia [Re: 2.6.21-rc2-mm1]

2007-03-06 Thread Jean Delvare
Hi All,

On Tue, 6 Mar 2007 09:45:43 +0100, Jean Delvare wrote:
   I guess we need to wait and see if someone hits the same problems
   with an in-kernel driver.
 
 I just did, with i2c-nforce2. The key to trigger it seems to be to load
 an i2c bus driver _after_ loading i2c-isa and a suitable i2c-isa-based
 hardware monitoring driver (w83791d, w83627hf, w83627ehf, it87, lm78,
 pc87360, sis5595, smsc47m1, smsc47b397, via686a or vt8231.) I have no
 idea why, though. Given that I was able to trigger the problem with
 only my own patches on top of Linus' tree, it means that the bug was
 clearly introduced by one of my patches. I'll bisect my stack now to
 find out which one. There aren't that many patches so it should be
 relatively quick.

Faulty patch is i2c-06-remove-duplicate-i2c-drivers-list.patch. The
oops is the result of the combination of two factors:

1* I'm too optimistic trying to remove the duplicate i2c drivers list
now. i2c-isa drivers are listed in the list managed by the driver
model, but not in the list managed by i2c-core. This difference between
both lists caused new errors to be returned, triggering the second
problem.

2* We do not want i2c_add_adapter to fail just because one
attach_adapter callback returned an error. The patch improperly caused
this to happen, while i2c_add_adapter is not designed to handle these
errors.

The bottom line is that I really need to kill i2c-isa before I can
apply this patch. So I'll drop it out for now, sorry for the noise.

-- 
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: 2.6.21-rc2-mm2

2007-03-06 Thread Andrew Morton
On Tue, 6 Mar 2007 19:27:18 +0900 KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:

 
 Following panic ouccurred (always) on ia64/NUMA(with empty node.)
 
 Bug in here.
 ==
 void move_native_irq(int irq)
 {
 struct irq_desc *desc = irq_desc + irq;
 
 if (likely(!(desc-status  IRQ_MOVE_PENDING)))
 return;
 
 if (unlikely(desc-status  IRQ_DISABLED))
 return;
 
 desc-chip-mask(irq);  -maybe this *mask* is NULL pointer
 move_masked_irq(irq);
 desc-chip-unmask(irq);
 }
 ==
 
 Is mask  always valid pointer ?

I can only find two `struct irq_chip's in arch/ia64 and they both have a
.mask.  And a .unmask.  So perhaps that is a misreading of what oopsed.

There are no changes in kernel/irq/ in -mm.  Are you sure mainline doesn't
do this too?

Anyway, can you please take a closer look at exactly what pointer it is
oopsing on?

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


2.6.21-rc2-mm2 rtc_cmos cart/horse problem

2007-03-06 Thread Mike Galbraith
Greetings,

I noticed the below during boot.

[   28.772015] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[   35.451802] rtc_cmos: dev (239:0)
[   35.461708] rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
[   35.474330] rtc0: alarms up to one month

-Mike

-
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.21-rc2-mm2

2007-03-06 Thread Jens Axboe
On Tue, Mar 06 2007, J.A. Magallón wrote:
 On Tue, 6 Mar 2007 00:44:08 -0800, Andrew Morton [EMAIL PROTECTED] wrote:
 
  
  Temporarily at
  
http://userweb.kernel.org/~akpm/2.6.21-rc2-mm2/
  
 
 Does this include a fix for the NFS problem ?
 
 BTW, I have in my kernel a patch like this below, isn't it needed ?
 Original thread:
 
 http://marc.theaimsgroup.com/?l=linux-kernelm=117189051227292w=2
 
 --- a/block/ll_rw_blk.c
 +++ b/block/ll_rw_blk.c
 @@ -2919,14 +2919,14 @@ static int __make_request(request_queue_
*/
   blk_queue_bounce(q, bio);
  
 + spin_lock_irq(q-queue_lock);
   /*
* Check if we can merge with the plugged list before grabbing
* any locks.
*/
   if (!check_plug_merge(q, ioc, bio))
 - goto out;
 + goto out_unlock;
  
 - spin_lock_irq(q-queue_lock);
   el_ret = elv_merge(q, req, bio);
   if (el_ret == ELEVATOR_BACK_MERGE) {
   if (bio_attempt_back_merge(q, req, bio)) {
 @@ -2984,7 +2984,6 @@ out_unlock:
   list_add_tail(req-queuelist, ioc-plugged_list);
   }
  
 -out:
   return 0;
  
  end_io_eopnotsupp:

No it's not, plus andrew didn't include git-block in this release so
you'd have a hard time even applying it. The above patch would also
eliminate 50% of the win of per-process plugging, if you go and grab the
queue lock anyway.

-- 
Jens Axboe

-
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: tdfx framebuffer garbles display in 2.6.19.5

2007-03-06 Thread DervishD
Hi Antonino :)

 * Antonino A. Daplas [EMAIL PROTECTED] dixit:
 On Tue, 2007-03-06 at 07:25 +0100, DervishD wrote:
   * Antonino A. Daplas [EMAIL PROTECTED] dixit:
   On Thu, 2007-03-01 at 17:01 +0100, DervishD wrote:
 * Antonino A. Daplas [EMAIL PROTECTED] dixit:
 Can you try this patch?  It might help with the screen
 corruption.

With the patch, the scroll slows to a crawl and the system is
unusable. The time to scroll 30 lines is about a minute or so
(probably more, I just measured for a while).

If you want me to test other patches, just tell :)
   
   Can you change the mdelay to udelay and use higher/lower delay values
   to see if there's any improvement?
  
  Yes, as soon as I can build a new kernel and reboot. Any suggested
  value?
 
 You can start with 5 and increment by 5.  So you need not reboot each
 time, compile tdfxfb as a module, and set CONFIG_HW_CONSOLE_BINDING=y
 (under drivers-char).

I've done that for testing, but I haven't build that kernel yet (not
spare time by now).

 Make sure you have vbetool, and use the attached script.

I don't have vbetool, but I'll get it.
 
 The script assumes vbetool is in /usr/sbin, if not just edit. Also,
 unbinding will only work if X (or any graphics app, for that matter) is
 not loaded.

No problem, it will be off while I test. I'll try to make the tests
probably this friday or the weekend, as soon as I can.

Thanks a lot for your interest :)

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
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 3/3][RFC] Containers: Pagecache controller reclaim

2007-03-06 Thread Vaidyanathan Srinivasan


Kari Hurtta wrote:
 Vaidyanathan Srinivasan [EMAIL PROTECTED] writes
 in gmane.linux.kernel,gmane.linux.kernel.mm:
 
 --- linux-2.6.20.orig/mm/pagecache_acct.c
 +++ linux-2.6.20/mm/pagecache_acct.c
 @@ -29,6 +29,7 @@
  #include linux/uaccess.h
  #include asm/div64.h
  #include linux/pagecache_acct.h
 +#include linux/memcontrol.h

  /*
   * Convert unit from pages to kilobytes
 @@ -337,12 +338,20 @@ int pagecache_acct_cont_overlimit(struct
  return 0;
  }

 -extern unsigned long shrink_all_pagecache_memory(unsigned long nr_pages);
 +extern unsigned long shrink_container_memory(unsigned int memory_type,
 +unsigned long nr_pages, void *container);

  int pagecache_acct_shrink_used(unsigned long nr_pages)
  {
  unsigned long ret = 0;
  atomic_inc(reclaim_count);
 +
 +/* Don't call reclaim for each page above limit */
 +if (nr_pages  NR_PAGES_RECLAIM_THRESHOLD) {
 +ret += shrink_container_memory(
 +RECLAIM_PAGECACHE_MEMORY, nr_pages, NULL);
 +}
 +
  return 0;
  }

 
 'ret' is not used ?

I have been setting watch points and tracing the value of ret.
Basically that is used while debugging.  I have not removed it since
this is an RFC post and we would go through many cleanups cycles.

I will remember to remove it in the next version or verify that the
compiler does remove 'ret' :)

--Vaidy

 / Kari Hurtta
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.21-rc2-mm2

2007-03-06 Thread KAMEZAWA Hiroyuki
On Tue, 6 Mar 2007 03:09:27 -0800
Andrew Morton [EMAIL PROTECTED] wrote:

  ==
  
  Is mask  always valid pointer ?
 
 I can only find two `struct irq_chip's in arch/ia64 and they both have a
 .mask.  And a .unmask.  So perhaps that is a misreading of what oopsed.
 
 There are no changes in kernel/irq/ in -mm.  Are you sure mainline doesn't
 do this too?
 
 Anyway, can you please take a closer look at exactly what pointer it is
 oopsing on?
 
Okay, I'll try -rc2 and look into more, tomorrow.

-Kame 

-
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: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Soeren Sonnenburg
On Tue, 2007-03-06 at 12:46 +0200, Michael S. Tsirkin wrote:
  Quoting Ingo Molnar [EMAIL PROTECTED]:
  Subject: Re: [5/6] 2.6.21-rc2: known regressions
  
  
  * Michael S. Tsirkin [EMAIL PROTECTED] wrote:
  
Quoting Linus Torvalds [EMAIL PROTECTED]:
   
Ok, it does indeed solve the problem for me.
   
   Not yet for me unfortunately, although this seems to help.
   Is this the patch I should have applied?
   http://lkml.org/lkml/2007/3/5/445
   
   With this applied, on resume I get *some* screen output soon after 
   resume (e.g. with s2ram I get several characters on VGA, X starts 
   drawing some windows) but then the crescent symbol starts blinking 
   again and the system hangs.
  
  could you try this via s2ram on a text console, to see whether the 
  kernel spits out any warning before it locks up?
 
 Yes, that's what I did. Unfortunately only a couple of characters were
 shown before it locked up.
 
 I still need to check what does this do in the NO_HZ configuration.
 
 BTW, Ingo, can you suspend/resume any number of times with this patch?

well I could at least two times in a row in my minimalistic setup
(config attached) however using the full kernel config it still
hangs ... (config also attached in case you watn to compare it).

Soeren
-- 
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.


linux-config-2.6.21-isolated-s2ram-debug.bz2
Description: application/bzip


linux-config-2.6.21.bz2
Description: application/bzip


Re: 2.6.21-rc2-mm2

2007-03-06 Thread Con Kolivas
(tglx cc'ed as he may know something about this - sorry if it's inappropriate)

On Tuesday 06 March 2007 19:44, Andrew Morton wrote:
 Temporarily at

   http://userweb.kernel.org/~akpm/2.6.21-rc2-mm2/

 Will appear later at

  
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc2/2.
6.20-rc2-mm2/

qemu doesn't like it with the config from my core2duo (attached below).

qemu-system-x86_64 -kernel  
arch/x86_64/boot/bzImage -hda ../temp/linux-0.2.img -append 
root=/dev/hda -smp 2 -nographic -serial stdio -append console=ttyS0

Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal
error, but for better emulation accuracy either use a 2.6 host Linux kernel or
type 'echo 1024  /proc/sys/dev/rtc/max-user-freq' as root.
(qemu) Linux version 2.6.21-rc2-mm2 ([EMAIL PROTECTED]) (gcc version 4.1.2 
20061115 (prerelease) (Debian 4.1.1-21)) #2 SMP PREEMPT Tue Mar 6 22:42:56 
EST 2007
Command line: console=ttyS0
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e8000 - 0010 (reserved)
 BIOS-e820: 0010 - 07ff (usable)
 BIOS-e820: 07ff - 0800 (ACPI data)
 BIOS-e820: fffc - 0001 (reserved)
end_pfn_map = 1048576
DMI not present or invalid.
ACPI: RSDP 000FA6D0, 0014 (r0 QEMU  )
ACPI: RSDT 07FF, 002C (r0 QEMU   QEMURSDT1 QEMU1)
ACPI: FACP 07FF002C, 0074 (r0 QEMU   QEMUFACP1 QEMU1)
ACPI: DSDT 07FF0100, 0832 (r1   BXPC   BXDSDT1 INTL 20060912)
ACPI: FACS 07FF00C0, 0040
ACPI: APIC 07FF0938, 0048 (r0 QEMU   QEMUAPIC1 QEMU1)
Zone PFN ranges:
  DMA 0 - 4096
  DMA324096 -  1048576
  Normal1048576 -  1048576
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0:0 -  159
0:  256 -32752
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Nosave address range: 0009f000 - 000a
Nosave address range: 000a - 000e8000
Nosave address range: 000e8000 - 0010
Allocating PCI resources starting at 1000 (gap: 800:f7fc)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 33792 bytes of per cpu data
Built 1 zonelists.  Total pages: 31110
Kernel command line: console=ttyS0
Initializing CPU#0
PID hash table entries: 512 (order: 9, 4096 bytes)
Marking TSC unstable due to TSCs unsynchronized
time.c: Detected 2461.549 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Checking aperture...
Memory: 123928k/131008k available (2332k kernel code, 6532k reserved, 1359k 
data, 216k init)
Calibrating delay using timer specific routine.. 5715.81 BogoMIPS 
(lpj=2857906)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
do_IRQ: 0.48 No irq handler for vector
do_IRQ: 0.48 No irq handler for vector
do_IRQ: 0.48 No irq handler for vector
do_IRQ: 0.48 No irq handler for vector
do_IRQ: 0.48 No irq handler for vector
do_IRQ: 0.48 No irq handler for vector
do_IRQ: 0.48 No irq handler for vector
do_IRQ: 0.48 No irq handler for vector
do_IRQ: 0.48 No irq handler for vector
do_IRQ: 0.48 No irq handler for vector
Using local APIC timer interrupts.
result 62504298
Detected 62.504 MHz APIC timer.
SMP alternatives: switching to SMP code
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 11970.64 BogoMIPS 
(lpj=5985322)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
QEMU Virtual CPU version 0.9.0 stepping 03
Brought up 2 CPUs
migration_cost=1939
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Interpreter enabled
ACPI: (supports S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
:00:01.1: cannot adjust BAR0 (not I/O)
:00:01.1: cannot adjust BAR1 (not I/O)
:00:01.1: cannot adjust BAR2 (not I/O)
:00:01.1: cannot adjust BAR3 (not I/O)
PCI quirk: region b000-b03f claimed by PIIX4 ACPI
PCI quirk: region b100-b10f claimed by PIIX4 SMB
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *9 10 11 12)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12)
Linux Plug and Play 

Re: [S390] Use generic bug.

2007-03-06 Thread Heiko Carstens
On Mon, Mar 05, 2007 at 02:56:29PM -0800, David Miller wrote:
 From: Martin Schwidefsky [EMAIL PROTECTED]
 Date: Mon, 5 Mar 2007 23:43:54 +0100
 
  +   if (__builtin_constant_p(__ret_warn_on)) {  \
  +   if (__ret_warn_on)  \
  +   __EMIT_BUG(BUGFLAG_WARNING);\
 
 I see we'll have this construct on powerpc, parisc and now s390.
 
 But if it's going to trigger essentially at compile time, I
 think it's much better to BUILD_BUG_ON() in this case instead
 of counting on the code path to actually run and the user to
 notice and report the kernel log message.

So something like WARN_ON(1) won't compile, but BUG_ON(1) still
would? Seems odd to me.
Also since there is nothing like WARN(), you have to use WARN_ON(1).
Btw.: sparc64 has plenty of these ;)

I would prefer to have something like a per arch defined WARN()
and a common code WARN_ON() like we have it already for BUG_ON().
Then I would agree: if WARN_ON() is used with a constant the build
should fail. Just to tell the author that he did something wrong
or simply should use WARN(). And of course the existing BUG_ON()
could be converted as well.
-
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/


encrypting jffs2 filesystem with DM-crypt or what else?

2007-03-06 Thread emin ak

Hi Folks,
I need to encrypt a jffs2/mtd formatted flash filesystem for an
embedded device, Normally using a loopback interface (cryptoloop,
DM-crypt or loop-aes) solves this problem but they are not well known
on journalling file systems (like jffs2) because of cached write etc..
Also I could'nt find any guideline for encrypting fikesystem on a
flash.
There is an ugly workaround to overcome this problem, I have placed an
encrypted ext2 filesystem image on an normal jffs2 partition and mount
this encrypted partition on a loopback, but this is not secure,
consumes alot for disk space and not reliable (is'nt it?)
Is there any other way to encrypt an jjffs2 partition, if not, what do
you think about my ugly workaround?
Thank alot
Emin
-
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: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Ingo Molnar

* Soeren Sonnenburg [EMAIL PROTECTED] wrote:

  BTW, Ingo, can you suspend/resume any number of times with this 
  patch?
 
 well I could at least two times in a row in my minimalistic setup 
 (config attached) however using the full kernel config it still hangs 
 ... (config also attached in case you watn to compare it).

i can confirm that with your full config i see a hang too. This is most 
likely the ACPI problem - we are debugging this now and will come up 
with a patch.

Ingo
-
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: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Jeff Chua

On 3/6/07, Soeren Sonnenburg [EMAIL PROTECTED] wrote:


   Not yet for me unfortunately, although this seems to help.
   Is this the patch I should have applied?
   http://lkml.org/lkml/2007/3/5/445


Same problem for me on 2.6.21-rc2/rc1 on IBM X60s. I've applied this
patch and Ingo Molnar's patch and s2ram still can't suspend. I tried
turning off CONFIG_KVM as well, but makes no difference.

Will try turning off CONFIG_NO_HZ to see if this makes any difference.
2.6.20 works fine.
Jeff.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: kref refcounting breakage in mainline

2007-03-06 Thread Mel Gorman
On (05/03/07 16:25), Greg KH didst pronounce:
 On Fri, Mar 02, 2007 at 12:58:33AM -0800, Andrew Morton wrote:
  
  -mm has a debugging patch which warns when atomic_dec_and_test() takes an
  atomic_t negative
  (ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/detect-atomic-counter-underflows.patch).
  
  
  When it is applied to current mainline, a simple `rmmod ipw2200' gives:
  
  [   75.825072] BUG: atomic counter underflow at:
  [   75.825180]  [c01c6eb4] kref_put+0x66/0x82
  [   75.825278]  [c022e4d4] bus_remove_driver+0x66/0x75
  [   75.825383]  [c022ee2c] driver_unregister+0x8/0x13
  [   75.825484]  [c01d7add] pci_unregister_driver+0xc/0x45
  [   75.825593]  [c0132147] sys_delete_module+0x157/0x17c
  [   75.825703]  [c013c663] audit_syscall_entry+0x10d/0x137
  [   75.825818]  [c0103b14] syscall_call+0x7/0xb
  [   75.825913]  [c02d] xfrm4_dst_destroy+0xe/0xd5
  
  This didn't happen in 2.6.20-mm2, so this bug was introduced by a patch
  which was not in the -mm lineup twelve days ago.
  
  Presumably the effect of this is a memory leak or a use-after-free.
 
 Ok, after a zillion bisects, I've tracked this down to:
   commit 63ce18cfe685115ff8d341bae4c9204a79043cf0
   Author: Mike Galbraith [EMAIL PROTECTED]
   Date:   Wed Feb 21 12:45:35 2007 -0800
 
   driver core: refcounting fix
   
   Fix a reference counting bug exposed by commit
   725522b5453dd680412f2b6463a988e4fd148757.  If driver.mod_name 
 exists, we
   take a reference in module_add_driver(), and never release it.  
 Undo that
   reference in module_remove_driver().
   
   Signed-off-by: Mike Galbraith [EMAIL PROTECTED]
   Cc: Kay Sievers [EMAIL PROTECTED]
   Signed-off-by: Andrew Morton [EMAIL PROTECTED]
   Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
   
 

On http://test.kernel.org, elm3b132 is showing a similar error message for
the IPS driver on 2.6.21-rc2-mm1. There is no such device in the machine so
this is a normal error path for no devices found. The warning looks like

BUG: atomic counter underflow at:
 [c027ccb4] kref_put+0x7d/0x9d
 [c02a4e38] bus_remove_driver+0x36/0x41
 [c02a5997] driver_unregister+0xb/0x13
 [c0286bdd] pci_unregister_driver+0xb/0x13
 [c04c653a] ips_module_init+0x41/0x57
 [c04b2bd2] do_initcalls+0x58/0xf5
 [c01353d5] register_irq_proc+0x75/0x92
 [c04b2c97] init+0x0/0x8b
 [c04b2ce0] init+0x49/0x8b
 [c01030ff] kernel_thread_helper+0x7/0x10

This is essentially identical to the warning on ipw2200. It occurs whether
the driver is compiled into the kernel or as a module.  Reverting Mike's
patch fixes the problem - or at least the warning has disappeared.

However, I've cc'd the IPS maintainers so they can confirm they are
calling pci_unregister_driver() correctly. I note that many drivers in
drivers/scsi do not call pci_unregister_driver() in the module_init path.
ipw2200 also calls pci_unregister_driver() in the module_init path when
an error is encountered.

So, maybe this is an error in how the drivers use pci_[un]register_driver()
instead of a problem with Mike's patch?

 Mike, I've reverted this patch, and I don't see any references leaking.
 And, as your patch released the reference on the driver, and the
 module_add_driver() call would not grab a reference to the driver, only
 the module kobject, I don't see what you were trying to fix with this
 patch.
 
 Do you have a test case that this fixes?
 
 Otherwise, I'll just revert it.
 
 thanks,
 
 greg k-h
 -
 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/

-- 
-- 
Mel Gorman
Part-time Phd Student  Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
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: userspace pagecache management tool

2007-03-06 Thread Pádraig Brady
Andrew Morton wrote:
 Yes.  Let's flesh it out the backup program policy some more:
 
 - Unconditionally invalidate output files
 
 - on entry to read(), probe pagecache, record which pages in the range are 
 present
 
 - on entry to next read(), shoot down those pages from the previous read
   which weren't in pagecache.
 
 - But we can do better!  LRU the page's files up to a certain number of pages.
 
 - Once that point is exceeded, we need to reclaim some pages.  Which
   ones?  Well, we've been observing all reads, so we can record which pages
   were referenced once, and which ones were referenced multiple times so we
   can do arbitrarily complex page aging in there.
 
 - On close(), nuke all pages which weren't in core during open(), even if
   this app referenced them multiple times.
 
 - If the backup program decided to read its input files with mmap we're
   rather screwed.  We can't intercept pagefaults so the best we can do is
   to restore the file's pagecache to its previous state on close().
 
   Or if it's really a problem, get control in there somehow and
   periodically poll the pagecache occupancy via mincore(), use madvise()
   then fadvise() to trim it back.
 
 That all sounds reasonably doable.  It'd be pretty complex to do it
 in-kernel but we could do it there too.  Problem is if course that the
 above strategy is explicitly optimised for the backup program and if it's
 in-kernel it becomes applicable to all other workloads.

I can see the above being possible, but I can't see the reason
for exposing that complexity to userspace. If I'm the target
audience for that API then it's broken as I'd mess it up,
or would take too long to get it right.

Can't we just fix the posix_fadvise() implementation to
only evict pages paged in by the current process.
Perhaps one could possibly just evict pages with _mapcount==0 ?

cheers,
Pádraig.
-
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: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Michael S. Tsirkin
 Quoting Ingo Molnar [EMAIL PROTECTED]:
 Subject: Re: [5/6] 2.6.21-rc2: known regressions
 
 
 * Soeren Sonnenburg [EMAIL PROTECTED] wrote:
 
   BTW, Ingo, can you suspend/resume any number of times with this 
   patch?
  
  well I could at least two times in a row in my minimalistic setup 
  (config attached) however using the full kernel config it still hangs 
  ... (config also attached in case you watn to compare it).
 
 i can confirm that with your full config i see a hang too. This is most 
 likely the ACPI problem - we are debugging this now and will come up 
 with a patch.
 
   Ingo

Here's mine too, in case someone's interested.

-- 
MST



linux-2.6.21-work.config.gz
Description: Binary data


Re: kernel BUG at arch/x86_64/mm/../../i386/mm/hugetlbpage.c:140!

2007-03-06 Thread Alexander Y. Fomichev
On Saturday 03 March 2007, Nish Aravamudan wrote:
 On 3/2/07, Alexander Y. Fomichev [EMAIL PROTECTED] wrote:
  G'day
 
  I'm hit a bug on 2.6.21-rc1 at startup of mysql with 'large-pages' flag
  set. (at this point mysql trying to allocate pages from hugetlb pool by
  sysv shm syscalls). Seems like it could be triggered by previous badness
  and probably hugetlb itself is not related. Anyway i couldn't reproduce
  it by now with 2.6.21-rc2 git commit
  562aa1d4c6a874373f9a48ac184f662fbbb06a04. Very likely it has been fixed
  somwhere between 2.6.21-rc1 and -rc2, but i couldn't find something
  related by git log so any comments are welcome.

 Adam Litke posted a bug fix for hugetlb shm:
 http://lkml.org/lkml/2007/3/1/381.

 Does that help fix your problem too?

 Thanks,
 Nish

Yep, it is, though Adam address this patch powerpc and ia64 issue but
x86_64 (and probably i386) affected too.

-- 
Best regards.
Alexander Y. Fomichev [EMAIL PROTECTED]
Public PGP key: http://sysadminday.org.ru/gluk.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/


Re: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Michael S. Tsirkin
 Quoting Ingo Molnar [EMAIL PROTECTED]:
 Subject: Re: [5/6] 2.6.21-rc2: known regressions
 
 
 * Michael S. Tsirkin [EMAIL PROTECTED] wrote:
 
Not yet for me unfortunately, although this seems to help.
Is this the patch I should have applied?
http://lkml.org/lkml/2007/3/5/445

With this applied, on resume I get *some* screen output soon after 
resume (e.g. with s2ram I get several characters on VGA, X starts 
drawing some windows) but then the crescent symbol starts blinking 
again and the system hangs.
   
   could you try this via s2ram on a text console, to see whether the 
   kernel spits out any warning before it locks up?
  
  Yes, that's what I did. Unfortunately only a couple of characters were 
  shown before it locked up.
  
  I still need to check what does this do in the NO_HZ configuration.
  
  BTW, Ingo, can you suspend/resume any number of times with this patch?
 
 yeah, i can now suspend/resume an arbitrary number of times, vga, 
 network, SATA all works fine after that. (i tried it 5 times)
 
 i also have the patch below applied - but i dont think it should make a 
 difference to your case. (maybe it does though)

Nope, system hangs on resume with or without this patch applied.

 I've attached my config as well.

Haven't tried that yet.

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


[GIT PULL] MMC and NCP fixes

2007-03-06 Thread Pierre Ossman
Linus, please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus

to receive the following updates:

 drivers/mmc/mmc.c |   83 ++--
 drivers/mmc/sdhci.c   |   39 +++-
 fs/ncpfs/inode.c  |   16 -
 fs/ncpfs/sock.c   |  151 ++--
 include/linux/mmc/host.h  |8 +++
 include/linux/ncp_fs_sb.h |2 +
 6 files changed, 184 insertions(+), 115 deletions(-)

Mark Lord (1):
  sdhci: make isr tolerant of read errors

Pierre Ossman (3):
  ncpfs: make sure server connection survives a kill
  mmc: require explicit support for high-speed
  sdhci: release irq during suspend

Rgds
-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.org
-
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 0/8] x86 boot, pda and gdt cleanups

2007-03-06 Thread Rusty Russell
Hi all,

The GDT stuff on x86 is a little more complex than it need be, but
playing with boot code is always dangerous.  These compile and boot on
UP and SMP for me, but Andrew should let the cook in -mm for a while.

Thanks!
Rusty.

-
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] strlcpy is smart enough

2007-03-06 Thread Jean Delvare
strlcpy already accounts for the trailing zero in its length
computation, so there is no need to substract one to the buffer size.

Untested, as I do not have the hardware.

Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
 arch/s390/kernel/debug.c  |2 +-
 arch/xtensa/platform-iss/network.c|2 +-
 drivers/net/ehea/ehea_ethtool.c   |4 ++--
 sound/aoa/codecs/snd-aoa-codec-onyx.c |4 ++--
 sound/aoa/codecs/snd-aoa-codec-tas.c  |4 ++--
 sound/oss/btaudio.c   |2 +-
 6 files changed, 9 insertions(+), 9 deletions(-)

--- linux-2.6.21-rc2.orig/arch/s390/kernel/debug.c  2007-03-06 
13:20:19.0 +0100
+++ linux-2.6.21-rc2/arch/s390/kernel/debug.c   2007-03-06 13:34:27.0 
+0100
@@ -268,7 +268,7 @@ debug_info_alloc(char *name, int pages_p
rc-level  = level;
rc-buf_size   = buf_size;
rc-entry_size = sizeof(debug_entry_t) + buf_size;
-   strlcpy(rc-name, name, sizeof(rc-name)-1);
+   strlcpy(rc-name, name, sizeof(rc-name));
memset(rc-views, 0, DEBUG_MAX_VIEWS * sizeof(struct debug_view *));
memset(rc-debugfs_entries, 0 ,DEBUG_MAX_VIEWS *
sizeof(struct dentry*));
--- linux-2.6.21-rc2.orig/arch/xtensa/platform-iss/network.c2007-03-06 
13:20:19.0 +0100
+++ linux-2.6.21-rc2/arch/xtensa/platform-iss/network.c 2007-03-06 
13:34:27.0 +0100
@@ -251,7 +251,7 @@ static int tuntap_open(struct iss_net_pr
 
memset(ifr, 0, sizeof ifr);
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
-   strlcpy(ifr.ifr_name, dev_name, sizeof ifr.ifr_name - 1);
+   strlcpy(ifr.ifr_name, dev_name, sizeof ifr.ifr_name);
 
if ((err = simc_ioctl(fd, TUNSETIFF, (void*) ifr))  0) {
printk(Failed to set interface, returned %d 
--- linux-2.6.21-rc2.orig/drivers/net/ehea/ehea_ethtool.c   2007-03-06 
13:20:19.0 +0100
+++ linux-2.6.21-rc2/drivers/net/ehea/ehea_ethtool.c2007-03-06 
13:34:27.0 +0100
@@ -144,8 +144,8 @@ static int ehea_nway_reset(struct net_de
 static void ehea_get_drvinfo(struct net_device *dev,
   struct ethtool_drvinfo *info)
 {
-   strlcpy(info-driver, DRV_NAME, sizeof(info-driver) - 1);
-   strlcpy(info-version, DRV_VERSION, sizeof(info-version) - 1);
+   strlcpy(info-driver, DRV_NAME, sizeof(info-driver));
+   strlcpy(info-version, DRV_VERSION, sizeof(info-version));
 }
 
 static u32 ehea_get_msglevel(struct net_device *dev)
--- linux-2.6.21-rc2.orig/sound/aoa/codecs/snd-aoa-codec-onyx.c 2007-03-06 
13:20:19.0 +0100
+++ linux-2.6.21-rc2/sound/aoa/codecs/snd-aoa-codec-onyx.c  2007-03-06 
13:34:27.0 +0100
@@ -1018,7 +1018,7 @@ static int onyx_create(struct i2c_adapte
onyx-i2c.driver = onyx_driver;
onyx-i2c.adapter = adapter;
onyx-i2c.addr = addr  0x7f;
-   strlcpy(onyx-i2c.name, onyx audio codec, I2C_NAME_SIZE-1);
+   strlcpy(onyx-i2c.name, onyx audio codec, I2C_NAME_SIZE);
 
if (i2c_attach_client(onyx-i2c)) {
printk(KERN_ERR PFX failed to attach to i2c\n);
@@ -1033,7 +1033,7 @@ static int onyx_create(struct i2c_adapte
goto fail;
}
 
-   strlcpy(onyx-codec.name, onyx, MAX_CODEC_NAME_LEN-1);
+   strlcpy(onyx-codec.name, onyx, MAX_CODEC_NAME_LEN);
onyx-codec.owner = THIS_MODULE;
onyx-codec.init = onyx_init_codec;
onyx-codec.exit = onyx_exit_codec;
--- linux-2.6.21-rc2.orig/sound/aoa/codecs/snd-aoa-codec-tas.c  2007-03-06 
13:20:19.0 +0100
+++ linux-2.6.21-rc2/sound/aoa/codecs/snd-aoa-codec-tas.c   2007-03-06 
13:34:27.0 +0100
@@ -899,14 +899,14 @@ static int tas_create(struct i2c_adapter
tas-i2c.addr = addr;
/* seems that half is a saner default */
tas-drc_range = TAS3004_DRC_MAX / 2;
-   strlcpy(tas-i2c.name, tas audio codec, I2C_NAME_SIZE-1);
+   strlcpy(tas-i2c.name, tas audio codec, I2C_NAME_SIZE);
 
if (i2c_attach_client(tas-i2c)) {
printk(KERN_ERR PFX failed to attach to i2c\n);
goto fail;
}
 
-   strlcpy(tas-codec.name, tas, MAX_CODEC_NAME_LEN-1);
+   strlcpy(tas-codec.name, tas, MAX_CODEC_NAME_LEN);
tas-codec.owner = THIS_MODULE;
tas-codec.init = tas_init_codec;
tas-codec.exit = tas_exit_codec;
--- linux-2.6.21-rc2.orig/sound/oss/btaudio.c   2007-03-06 13:20:19.0 
+0100
+++ linux-2.6.21-rc2/sound/oss/btaudio.c2007-03-06 13:38:00.0 
+0100
@@ -344,7 +344,7 @@ static int btaudio_mixer_ioctl(struct in
if (cmd == SOUND_OLD_MIXER_INFO) {
_old_mixer_info info;
memset(info,0,sizeof(info));
-strlcpy(info.id,bt878,sizeof(info.id)-1);
+strlcpy(info.id, bt878, sizeof(info.id));
 strlcpy(info.name,Brooktree Bt878 audio,sizeof(info.name));
 if (copy_to_user(argp, info, sizeof(info)))
   

Re: [PATCH] Use a zero-size array in the struct devres

2007-03-06 Thread Tejun Heo
Hello, Catalin.

Catalin Marinas wrote:
 Commit 9ac7849e35f705830f7b016ff272b0ff1f7ff759 adds the devres
 structure containing a flexible unsigned long long array, with a
 comment about the guaranteed alignment. According to the gcc manual,
 flexible arrays are considered incomplete types and it is an error to
 ask for their alignment. This patch makes data[] a zero-size array.

The gcc manual says nothing about alignment.  What it says is sizeof()
doesn't work.  If flexible array doesn't honor the alignment of the
declared type, it would be useless for its designed purpose of
supporting *array* of dynamically-determined length.

 I came across this when trying to build kmemleak as the modified
 container_of macro tries to get the size of the devres.data member and
 sizeof cannot be applied to incomplete types.

If kmemleak's container_of cannot deal with the current struct devres,
it means it can't deal with flexible arrays at all.  Flexible array
being the standard as opposed to 0 size array gcc extension, I guess a
lot of people would prefer flexible array.

It would be best if kmemleak's container_of can be modified to work with
flexible arrays.  If that's not possible, I guess it needs wider
discussion to determine whether to ditch flexible array for kmemleak.

Thanks.

-- 
tejun
-
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: kernel BUG at arch/x86_64/mm/../../i386/mm/hugetlbpage.c:140!

2007-03-06 Thread Alexander Y. Fomichev
On Saturday 03 March 2007, Bill Irwin wrote:
 On Fri, Mar 02, 2007 at 04:51:15PM +0300, Alexander Y. Fomichev wrote:
  I'm hit a bug on 2.6.21-rc1 at startup of mysql with 'large-pages' flag
  set. (at this point mysql trying to allocate pages from hugetlb pool by
  sysv shm syscalls). Seems like it could be triggered by previous badness
  and probably hugetlb itself is not related. Anyway i couldn't reproduce
  it by now with 2.6.21-rc2 git commit
  562aa1d4c6a874373f9a48ac184f662fbbb06a04. Very likely it has been fixed
  somwhere between 2.6.21-rc1 and -rc2, but i couldn't find something
  related by git log so any comments are welcome.

 If you have a known-working kernel version, git-bisect might help you
 track down where it was introduced. Given the messages prior to the
 hugetlbpage.c BUG_ON I'd say that this is something else besides the
 specific code listed by line number, 

Nop, seems like it is hugetlb bug fixed by Adam 
commit 516dffdcd8827a40532798602830dfcfc672294c
[PATCH] Fix get_unmapped_area and fsync for hugetlb shm segments
I've disregard it thoughtlessly so Adam marks it specific for powerpc/ia64.
(hmm.. i donno realy why, huge pages should be alined anyway and if i 
understend it correctly it may not be if is_file_hugepages() fails)

As of junk just before the BUG this again IIUC because o-direct staff
catches this issue before hugetlb.

 though I wouldn't rule out hugetlb
 having tripped over itself before the actual BUG.


Yep, it is.

 -- wli


-- 
Best regards.
Alexander Y. Fomichev [EMAIL PROTECTED]
Public PGP key: http://sysadminday.org.ru/gluk.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/


Re: 2.6.21-rc2-mm2

2007-03-06 Thread Thomas Gleixner
On Tue, 2007-03-06 at 22:58 +1100, Con Kolivas wrote:
 (tglx cc'ed as he may know something about this - sorry if it's inappropriate)

John cc'ed as well :)

  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc2/2.
 6.20-rc2-mm2/
 
 qemu doesn't like it with the config from my core2duo (attached below).
 
 qemu-system-x86_64 -kernel  
 arch/x86_64/boot/bzImage -hda ../temp/linux-0.2.img -append 
 root=/dev/hda -smp 2 -nographic -serial stdio -append console=ttyS0
 
 Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal
 error, but for better emulation accuracy either use a 2.6 host Linux kernel or
 type 'echo 1024  /proc/sys/dev/rtc/max-user-freq' as root.
 (qemu) Linux version 2.6.21-rc2-mm2 ([EMAIL PROTECTED]) (gcc version 4.1.2 
 20061115 (prerelease) (Debian 4.1.1-21)) #2 SMP PREEMPT Tue Mar 6 22:42:56 
 EST 2007
 Command line: console=ttyS0
 BIOS-provided physical RAM map:
  BIOS-e820:  - 0009fc00 (usable)
  BIOS-e820: 0009fc00 - 000a (reserved)
  BIOS-e820: 000e8000 - 0010 (reserved)
  BIOS-e820: 0010 - 07ff (usable)
  BIOS-e820: 07ff - 0800 (ACPI data)
  BIOS-e820: fffc - 0001 (reserved)
 end_pfn_map = 1048576
 DMI not present or invalid.
 ACPI: RSDP 000FA6D0, 0014 (r0 QEMU  )
 ACPI: RSDT 07FF, 002C (r0 QEMU   QEMURSDT1 QEMU1)
 ACPI: FACP 07FF002C, 0074 (r0 QEMU   QEMUFACP1 QEMU1)
 ACPI: DSDT 07FF0100, 0832 (r1   BXPC   BXDSDT1 INTL 20060912)
 ACPI: FACS 07FF00C0, 0040
 ACPI: APIC 07FF0938, 0048 (r0 QEMU   QEMUAPIC1 QEMU1)
 Zone PFN ranges:
   DMA 0 - 4096
   DMA324096 -  1048576
   Normal1048576 -  1048576
 Movable zone start PFN for each node
 early_node_map[2] active PFN ranges
 0:0 -  159
 0:  256 -32752
 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
 Processor #0 (Bootup-CPU)
 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
 Processor #1
 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
 IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
 Setting APIC routing to flat
 Using ACPI (MADT) for SMP configuration information
 Nosave address range: 0009f000 - 000a
 Nosave address range: 000a - 000e8000
 Nosave address range: 000e8000 - 0010
 Allocating PCI resources starting at 1000 (gap: 800:f7fc)
 SMP: Allowing 2 CPUs, 0 hotplug CPUs
 PERCPU: Allocating 33792 bytes of per cpu data
 Built 1 zonelists.  Total pages: 31110
 Kernel command line: console=ttyS0
 Initializing CPU#0
 PID hash table entries: 512 (order: 9, 4096 bytes)
 Marking TSC unstable due to TSCs unsynchronized
 time.c: Detected 2461.549 MHz processor.
 Console: colour VGA+ 80x25
 Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
 Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
 Checking aperture...
 Memory: 123928k/131008k available (2332k kernel code, 6532k reserved, 1359k 
 data, 216k init)
 Calibrating delay using timer specific routine.. 5715.81 BogoMIPS 
 (lpj=2857906)
 Mount-cache hash table entries: 256
 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
 CPU: L2 Cache: 512K (64 bytes/line)
 SMP alternatives: switching to UP code
 ACPI: Core revision 20070126
 do_IRQ: 0.48 No irq handler for vector
 do_IRQ: 0.48 No irq handler for vector
 do_IRQ: 0.48 No irq handler for vector
 do_IRQ: 0.48 No irq handler for vector
 do_IRQ: 0.48 No irq handler for vector
 do_IRQ: 0.48 No irq handler for vector
 do_IRQ: 0.48 No irq handler for vector
 do_IRQ: 0.48 No irq handler for vector
 do_IRQ: 0.48 No irq handler for vector
 do_IRQ: 0.48 No irq handler for vector
 Using local APIC timer interrupts.
 result 62504298
 Detected 62.504 MHz APIC timer.
 SMP alternatives: switching to SMP code
 Booting processor 1/2 APIC 0x1
 Initializing CPU#1
 Calibrating delay using timer specific routine.. 11970.64 BogoMIPS 
 (lpj=5985322)

Hmm, CPU#1 has ~ double speed of CPU#0

 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
 CPU: L2 Cache: 512K (64 bytes/line)
 QEMU Virtual CPU version 0.9.0 stepping 03
 Brought up 2 CPUs
 migration_cost=1939
 NET: Registered protocol family 16
 ACPI: bus type pci registered
 PCI: Using configuration type 1
 ACPI: Interpreter enabled
 ACPI: (supports S5)
 ACPI: Using IOAPIC for interrupt routing
 ACPI: PCI Root Bridge [PCI0] (:00)
 :00:01.1: cannot adjust BAR0 (not I/O)
 :00:01.1: cannot adjust BAR1 (not I/O)
 :00:01.1: cannot adjust BAR2 (not I/O)
 :00:01.1: cannot adjust BAR3 (not I/O)
 PCI quirk: region b000-b03f claimed by PIIX4 ACPI
 PCI quirk: region b100-b10f claimed by PIIX4 SMB
 ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12)
 ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *9 10 11 12)
 ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11 

Re: [PATCH 1/2] x86_64: add reporting of SVM flags to /proc/cpuinfo

2007-03-06 Thread Joerg Roedel
On Mon, Mar 05, 2007 at 04:25:31PM +0100, Andi Kleen wrote:
 On Monday 05 March 2007 15:39, Joerg Roedel wrote:
  From: Joerg Roedel [EMAIL PROTECTED]
  
  This patch adds the advanced SVM reporting to /proc/cpuinfo on the x86_64
  architecture.
 
 Adding more fields to /proc/cpuinfo is always somewhat risky because
 there are lots of badly written parsers for it.

Can you point me to some really broken parsers of /proc/cpuinfo to test
with?

 I considered adding the SVM fields myself, but decided against it because
 it didn't seem generally useful enough.

I don't see that this is less important than the power flags in that
file. Some users might be interested to see if their processor has npt
for example by simply looking into cpuinfo.
As I said, would be interested to know more about these badly written
parsers.

Joerg

-- 
Joerg Roedel
Operating System Research Center
AMD Saxony LLC  Co. KG


-
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: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Ingo Molnar
* Ingo Molnar [EMAIL PROTECTED] wrote:

   BTW, Ingo, can you suspend/resume any number of times with this 
   patch?
  
  well I could at least two times in a row in my minimalistic setup 
  (config attached) however using the full kernel config it still 
  hangs ... (config also attached in case you watn to compare it).
 
 i can confirm that with your full config i see a hang too. This is 
 most likely the ACPI problem - we are debugging this now and will come 
 up with a patch.

update: this only happens with simulation, and even then it's not a full 
hang but 'hangs until i hit a key'. With real resume i'm hitting a real 
key anyway so it doesnt hang.

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


Intel chooses not to support its HECI/QPS Chip in Linux?

2007-03-06 Thread Justin Piszcz



On Mon, 5 Feb 2007, Justin Piszcz wrote:




On Mon, 5 Feb 2007, Arjan van de Ven wrote:


On Sun, 2007-02-04 at 10:57 -0500, Justin Piszcz wrote:

Hi,

Anyone from Intel that reads LKML, could you provide an update as to what
is happening with support for your HECI Controller/QPS chip, which is used
on 965 (and possibly other?) chipsets.


I asked the right folks and the word I got was Soon. The code we have
needs some major cleanups before it's suitable for lkml posting... but
it'll be there soon. We're working on the cleanups full time We'll
send an update when we're further along



Very good news, thanks for the update!

Justin.



It has been  1 month since this last e-mail, I was wondering if anyone in 
the community [or Intel] could provide an update?  I spoke with one of the 
lmsensors the other day and he stated that there may be a plan to 
incorporate the CPU temperature soon, depending on what Intel does/what 
they provide.


Are we any closer to getting full HECI support in the kernel today than 
last month?


Justin.
-
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 1/8] Remove cpu_gdt_table: use boot_gdt_table until migration to per-cpu

2007-03-06 Thread Rusty Russell
Linux uses three GDTs to boot: the boot_gdt_table, which contains only
the __BOOT_CS and __BOOT_DS entries is used first up, before kernel is
mapped at PAGE_OFFSET.  Then we transition to cpu_gdt_table during
boot, and finally we allocate a per-cpu GDT and switch to that.

We can simplify this by using the boot_gdt_table until switching to
the per-cpu GDT table.  As a bonus, this gets rid of the
horribly-named cpu_gdt_table (it's not per-cpu, and the T in GDT
already stands for table).

Finally, some old bogus comments are deleted.

Signed-off-by: Rusty Russell [EMAIL PROTECTED]

diff -r 9cf03cbf8bde arch/i386/kernel/cpu/common.c
--- a/arch/i386/kernel/cpu/common.c Thu Mar 01 16:40:41 2007 +1100
+++ b/arch/i386/kernel/cpu/common.c Thu Mar 01 21:58:16 2007 +1100
@@ -694,7 +694,7 @@ __cpuinit int init_gdt(int cpu, struct t
 * Initialize the per-CPU GDT with the boot GDT,
 * and set up the GDT descriptor:
 */
-   memcpy(gdt, cpu_gdt_table, GDT_SIZE);
+   memcpy(gdt, boot_gdt_table, GDT_SIZE);
cpu_gdt_descr-size = GDT_SIZE - 1;
 
pack_descriptor((u32 *)gdt[GDT_ENTRY_PDA].a,
diff -r 9cf03cbf8bde arch/i386/kernel/head.S
--- a/arch/i386/kernel/head.S   Thu Mar 01 16:40:41 2007 +1100
+++ b/arch/i386/kernel/head.S   Thu Mar 01 22:05:37 2007 +1100
@@ -595,31 +595,19 @@ idt_descr:
.word IDT_ENTRIES*8-1   # idt contains 256 entries
.long idt_table
 
-# boot GDT descriptor (later on used by CPU#0):
+# The boot GDT descriptor once paging is enabled.
.word 0 # 32 bit align gdt_desc.address
 ENTRY(early_gdt_descr)
.word GDT_ENTRIES*8-1
-   .long cpu_gdt_table
-
-/*
- * The boot_gdt_table must mirror the equivalent in setup.S and is
- * used only for booting.
- */
+   .long boot_gdt_table
+
+/* The boot Global Descriptor Table: after boot we allocate a per-cpu copy */
.align L1_CACHE_BYTES
 ENTRY(boot_gdt_table)
-   .fill GDT_ENTRY_BOOT_CS,8,0
-   .quad 0x00cf9a00/* kernel 4GB code at 0x */
-   .quad 0x00cf9200/* kernel 4GB data at 0x */
-
-/*
- * The Global Descriptor Table contains 28 quadwords, per-CPU.
- */
-   .align L1_CACHE_BYTES
-ENTRY(cpu_gdt_table)
.quad 0x/* NULL descriptor */
.quad 0x/* 0x0b reserved */
-   .quad 0x/* 0x13 reserved */
-   .quad 0x/* 0x1b reserved */
+   .quad 0x00cf9a00/* boot: 4GB code at 0x */
+   .quad 0x00cf9200/* boot: 4GB data at 0x */
.quad 0x/* 0x20 unused */
.quad 0x/* 0x28 unused */
.quad 0x/* 0x33 TLS entry 1 */
diff -r 9cf03cbf8bde include/asm-i386/desc.h
--- a/include/asm-i386/desc.h   Thu Mar 01 16:40:41 2007 +1100
+++ b/include/asm-i386/desc.h   Thu Mar 01 21:57:37 2007 +1100
@@ -12,7 +12,7 @@
 
 #include asm/mmu.h
 
-extern struct desc_struct cpu_gdt_table[GDT_ENTRIES];
+extern struct desc_struct boot_gdt_table[GDT_ENTRIES];
 
 struct Xgt_desc_struct {
unsigned short size;


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2/8] Remove NR_CPUS from asm-generic/percpu.h

2007-03-06 Thread Rusty Russell
I managed to get an error about NR_CPUS undefined after a make
allyesconfig.  Admittedly this was a patched kernel, but it's easy to
remove it and avoid the error in future even if it's OK at the moment.

Signed-off-by: Rusty Russell [EMAIL PROTECTED]

diff -r 4519e3475c4f include/asm-generic/percpu.h
--- a/include/asm-generic/percpu.h  Mon Mar 05 12:17:10 2007 +1100
+++ b/include/asm-generic/percpu.h  Mon Mar 05 16:14:05 2007 +1100
@@ -5,7 +5,7 @@
 #define __GENERIC_PER_CPU
 #ifdef CONFIG_SMP
 
-extern unsigned long __per_cpu_offset[NR_CPUS];
+extern unsigned long __per_cpu_offset[];
 
 #define per_cpu_offset(x) (__per_cpu_offset[x])
 


-
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 3/8] Use per-cpu variables for GDT, PDA

2007-03-06 Thread Rusty Russell
Allocating PDA and GDT at boot is a pain.  Using simple per-cpu
variables adds happiness (although we need the GDT page-aligned for
Xen, see later).

Finally, we can simply call it cpu_gdt rather than enduring the
superfluous and unnecessarily redundant tautology of cpu_gdt_table.

Signed-off-by: Rusty Russell [EMAIL PROTECTED]

diff -r c2b61e13394d arch/i386/kernel/cpu/common.c
--- a/arch/i386/kernel/cpu/common.c Fri Mar 02 09:35:32 2007 +1100
+++ b/arch/i386/kernel/cpu/common.c Mon Mar 05 11:34:31 2007 +1100
@@ -25,8 +25,10 @@ DEFINE_PER_CPU(struct Xgt_desc_struct, c
 DEFINE_PER_CPU(struct Xgt_desc_struct, cpu_gdt_descr);
 EXPORT_PER_CPU_SYMBOL(cpu_gdt_descr);
 
-struct i386_pda *_cpu_pda[NR_CPUS] __read_mostly;
-EXPORT_SYMBOL(_cpu_pda);
+DEFINE_PER_CPU(struct desc_struct, cpu_gdt[GDT_ENTRIES]);
+
+DEFINE_PER_CPU(struct i386_pda, _cpu_pda);
+EXPORT_PER_CPU_SYMBOL(_cpu_pda);
 
 static int cachesize_override __cpuinitdata = -1;
 static int disable_x86_fxsr __cpuinitdata;
@@ -609,52 +611,6 @@ struct pt_regs * __devinit idle_regs(str
return regs;
 }
 
-static __cpuinit int alloc_gdt(int cpu)
-{
-   struct Xgt_desc_struct *cpu_gdt_descr = per_cpu(cpu_gdt_descr, cpu);
-   struct desc_struct *gdt;
-   struct i386_pda *pda;
-
-   gdt = (struct desc_struct *)cpu_gdt_descr-address;
-   pda = cpu_pda(cpu);
-
-   /*
-* This is a horrible hack to allocate the GDT.  The problem
-* is that cpu_init() is called really early for the boot CPU
-* (and hence needs bootmem) but much later for the secondary
-* CPUs, when bootmem will have gone away
-*/
-   if (NODE_DATA(0)-bdata-node_bootmem_map) {
-   BUG_ON(gdt != NULL || pda != NULL);
-
-   gdt = alloc_bootmem_pages(PAGE_SIZE);
-   pda = alloc_bootmem(sizeof(*pda));
-   /* alloc_bootmem(_pages) panics on failure, so no check */
-
-   memset(gdt, 0, PAGE_SIZE);
-   memset(pda, 0, sizeof(*pda));
-   } else {
-   /* GDT and PDA might already have been allocated if
-  this is a CPU hotplug re-insertion. */
-   if (gdt == NULL)
-   gdt = (struct desc_struct *)get_zeroed_page(GFP_KERNEL);
-
-   if (pda == NULL)
-   pda = kmalloc_node(sizeof(*pda), GFP_KERNEL, 
cpu_to_node(cpu));
-
-   if (unlikely(!gdt || !pda)) {
-   free_pages((unsigned long)gdt, 0);
-   kfree(pda);
-   return 0;
-   }
-   }
-
-   cpu_gdt_descr-address = (unsigned long)gdt;
-   cpu_pda(cpu) = pda;
-
-   return 1;
-}
-
 /* Initial PDA used by boot CPU */
 struct i386_pda boot_pda = {
._pda = boot_pda,
@@ -670,31 +626,17 @@ static inline void set_kernel_fs(void)
asm volatile (mov %0, %%fs : : r (__KERNEL_PDA) : memory);
 }
 
-/* Initialize the CPU's GDT and PDA.  The boot CPU does this for
-   itself, but secondaries find this done for them. */
-__cpuinit int init_gdt(int cpu, struct task_struct *idle)
+/* Initialize the CPU's GDT and PDA.  This is either the boot CPU doing itself
+   (still using boot_gdt_table), or a CPU doing it for a secondary which
+   will soon come up. */
+__cpuinit void init_gdt(int cpu, struct task_struct *idle)
 {
struct Xgt_desc_struct *cpu_gdt_descr = per_cpu(cpu_gdt_descr, cpu);
-   struct desc_struct *gdt;
-   struct i386_pda *pda;
-
-   /* For non-boot CPUs, the GDT and PDA should already have been
-  allocated. */
-   if (!alloc_gdt(cpu)) {
-   printk(KERN_CRIT CPU%d failed to allocate GDT or PDA\n, cpu);
-   return 0;
-   }
-
-   gdt = (struct desc_struct *)cpu_gdt_descr-address;
-   pda = cpu_pda(cpu);
-
-   BUG_ON(gdt == NULL || pda == NULL);
-
-   /*
-* Initialize the per-CPU GDT with the boot GDT,
-* and set up the GDT descriptor:
-*/
+   struct desc_struct *gdt = per_cpu(cpu_gdt, cpu);
+   struct i386_pda *pda = per_cpu(_cpu_pda, cpu);
+
memcpy(gdt, boot_gdt_table, GDT_SIZE);
+   cpu_gdt_descr-address = (unsigned long)gdt;
cpu_gdt_descr-size = GDT_SIZE - 1;
 
pack_descriptor((u32 *)gdt[GDT_ENTRY_PDA].a,
@@ -706,17 +648,13 @@ __cpuinit int init_gdt(int cpu, struct t
pda-_pda = pda;
pda-cpu_number = cpu;
pda-pcurrent = idle;
-
-   return 1;
-}
-
+}
+
+/* Move this CPU from boot_gdt_table  boot_pda to this cpu's proper one. */
 void __cpuinit cpu_set_gdt(int cpu)
 {
struct Xgt_desc_struct *cpu_gdt_descr = per_cpu(cpu_gdt_descr, cpu);
 
-   /* Reinit these anyway, even if they've already been done (on
-  the boot CPU, this will transition from the boot gdt+pda to
-  the real ones). */
load_gdt(cpu_gdt_descr);
set_kernel_fs();
 }
@@ -804,13 +742,8 @@ void __cpuinit cpu_init(void)
struct task_struct *curr 

[PATCH 4/8] Cleanup setup_pda

2007-03-06 Thread Rusty Russell
The comment above this function has never been true in mainline:
talking to Jeremy it's from previous patch churn.  What setup_pda
actually does is to write the segment entry for boot_pda into the
boot_gdt_table.  Ideally, this would be a static initialization, but
because the addresses are split over multiple parts in the funk bit
layout of the GDT entry (thanks Intel!) that's not a valid C
initializer.

We in fact call this routine on every CPU bringup, but that's
harmless.  Non-boot CPUs switch to their own GDTs immediately in
initialize_secondary.

VMI certainly doesn't need to call it explicitly.

Signed-off-by: Rusty Russell [EMAIL PROTECTED]

diff -r 2d9aa53572e2 arch/i386/kernel/head.S
--- a/arch/i386/kernel/head.S   Tue Mar 06 19:01:08 2007 +1100
+++ b/arch/i386/kernel/head.S   Tue Mar 06 19:01:12 2007 +1100
@@ -365,17 +365,10 @@ 1:movb $1,X86_HARD_MATH
.byte 0xDB,0xE4 /* fsetpm for 287, ignored by 387 */
ret
 
-/*
- * Point the GDT at this CPU's PDA.  On boot this will be
- * cpu_gdt_table and boot_pda; for secondary CPUs, these will be
- * that CPU's GDT and PDA.
- */
-ENTRY(setup_pda)
-   /* get the PDA pointer */
-   movl start_pda, %eax
-
-   /* slot the PDA address into the GDT */
-   mov early_gdt_descr+2, %ecx
+/* Initialize the boot_gdt_table's GDT_ENTRY_PDA (can't be done statically) */
+setup_pda:
+   movl $boot_pda, %eax
+   movl $boot_gdt_table, %ecx
mov %ax, (__KERNEL_PDA+0+2)(%ecx)   /* base  0x */
shr $16, %eax
mov %al, (__KERNEL_PDA+4+0)(%ecx)   /* base  0x00ff */
@@ -554,9 +547,6 @@ ENTRY(empty_zero_page)
  * This starts the data section.
  */
 .data
-ENTRY(start_pda)
-   .long boot_pda
-
 ENTRY(stack_start)
.long init_thread_union+THREAD_SIZE
.long __BOOT_DS
diff -r 2d9aa53572e2 arch/i386/kernel/vmi.c
--- a/arch/i386/kernel/vmi.cTue Mar 06 19:01:08 2007 +1100
+++ b/arch/i386/kernel/vmi.cTue Mar 06 19:01:47 2007 +1100
@@ -525,8 +525,6 @@ void vmi_pmd_clear(pmd_t *pmd)
 #endif
 
 #ifdef CONFIG_SMP
-extern void setup_pda(void);
-
 static void __devinit
 vmi_startup_ipi_hook(int phys_apicid, unsigned long start_eip,
 unsigned long start_esp)
@@ -555,8 +553,6 @@ vmi_startup_ipi_hook(int phys_apicid, un
ap.gs = 0;
 
ap.eflags = 0;
-
-   setup_pda();
 
 #ifdef CONFIG_X86_PAE
/* efer should match BSP efer. */


-
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: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Michael S. Tsirkin
 Quoting Ingo Molnar [EMAIL PROTECTED]:
 Subject: Re: [5/6] 2.6.21-rc2: known regressions
 
 * Ingo Molnar [EMAIL PROTECTED] wrote:
 
BTW, Ingo, can you suspend/resume any number of times with this 
patch?
   
   well I could at least two times in a row in my minimalistic setup 
   (config attached) however using the full kernel config it still 
   hangs ... (config also attached in case you watn to compare it).
  
  i can confirm that with your full config i see a hang too. This is 
  most likely the ACPI problem - we are debugging this now and will come 
  up with a patch.
 
 update: this only happens with simulation, and even then it's not a full 
 hang but 'hangs until i hit a key'. With real resume i'm hitting a real 
 key anyway so it doesnt hang.

How 'bout my .config?


-- 
MST
-
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 5/8] Cleanup GDT access

2007-03-06 Thread Rusty Russell
Now we have an explicit per-cpu GDT variable, we don't need to keep
the descriptors around to use them to find the GDT.  Also remove the
cpu_pda() accessor: it's just a per-cpu variable.

Signed-off-by: Rusty Russell [EMAIL PROTECTED]

diff -r e9d5b8e6f5ee arch/i386/kernel/cpu/common.c
--- a/arch/i386/kernel/cpu/common.c Tue Mar 06 16:20:48 2007 +1100
+++ b/arch/i386/kernel/cpu/common.c Tue Mar 06 17:04:37 2007 +1100
@@ -22,11 +22,8 @@
 
 #include cpu.h
 
-DEFINE_PER_CPU(struct Xgt_desc_struct, cpu_gdt_descr);
-EXPORT_PER_CPU_SYMBOL(cpu_gdt_descr);
-
 DEFINE_PER_CPU(struct desc_struct, cpu_gdt[GDT_ENTRIES]);
-
+EXPORT_PER_CPU_SYMBOL_GPL(cpu_gdt);
 DEFINE_PER_CPU(struct i386_pda, _cpu_pda);
 EXPORT_PER_CPU_SYMBOL(_cpu_pda);
 
@@ -631,14 +628,11 @@ static inline void set_kernel_fs(void)
will soon come up. */
 __cpuinit void init_gdt(int cpu, struct task_struct *idle)
 {
-   struct Xgt_desc_struct *cpu_gdt_descr = per_cpu(cpu_gdt_descr, cpu);
struct desc_struct *gdt = per_cpu(cpu_gdt, cpu);
struct i386_pda *pda = per_cpu(_cpu_pda, cpu);
 
+   /* Based on boot_gdt_table: set PDA so it can be used immediately */
memcpy(gdt, boot_gdt_table, GDT_SIZE);
-   cpu_gdt_descr-address = (unsigned long)gdt;
-   cpu_gdt_descr-size = GDT_SIZE - 1;
-
pack_descriptor((u32 *)gdt[GDT_ENTRY_PDA].a,
(u32 *)gdt[GDT_ENTRY_PDA].b,
(unsigned long)pda, sizeof(*pda) - 1,
@@ -653,9 +647,12 @@ __cpuinit void init_gdt(int cpu, struct 
 /* Move this CPU from boot_gdt_table  boot_pda to this cpu's proper one. */
 void __cpuinit cpu_set_gdt(int cpu)
 {
-   struct Xgt_desc_struct *cpu_gdt_descr = per_cpu(cpu_gdt_descr, cpu);
-
-   load_gdt(cpu_gdt_descr);
+   struct Xgt_desc_struct gdt_descr;
+
+   gdt_descr.address = (unsigned long)per_cpu(cpu_gdt, cpu);
+   gdt_descr.size = GDT_SIZE - 1;
+
+   load_gdt(gdt_descr);
set_kernel_fs();
 }
 
diff -r e9d5b8e6f5ee arch/i386/kernel/efi.c
--- a/arch/i386/kernel/efi.cTue Mar 06 16:20:48 2007 +1100
+++ b/arch/i386/kernel/efi.cTue Mar 06 17:05:41 2007 +1100
@@ -69,12 +69,10 @@ static void efi_call_phys_prelog(void) _
 {
unsigned long cr4;
unsigned long temp;
-   struct Xgt_desc_struct *cpu_gdt_descr;
+   struct Xgt_desc_struct gdt_descr;
 
spin_lock(efi_rt_lock);
local_irq_save(efi_rt_eflags);
-
-   cpu_gdt_descr = per_cpu(cpu_gdt_descr, 0);
 
/*
 * If I don't have PSE, I should just duplicate two entries in page
@@ -105,17 +103,19 @@ static void efi_call_phys_prelog(void) _
 */
local_flush_tlb();
 
-   cpu_gdt_descr-address = __pa(cpu_gdt_descr-address);
-   load_gdt(cpu_gdt_descr);
+   gdt_descr.address = __pa(get_cpu_gdt_table(0));
+   gdt_descr.size = GDT_SIZE - 1;
+   load_gdt(gdt_descr);
 }
 
 static void efi_call_phys_epilog(void) __releases(efi_rt_lock)
 {
unsigned long cr4;
-   struct Xgt_desc_struct *cpu_gdt_descr = per_cpu(cpu_gdt_descr, 0);
-
-   cpu_gdt_descr-address = (unsigned long)__va(cpu_gdt_descr-address);
-   load_gdt(cpu_gdt_descr);
+   struct Xgt_desc_struct gdt_descr;
+
+   gdt_descr.address = (unsigned long)get_cpu_gdt_table(0);
+   gdt_descr.size = GDT_SIZE - 1;
+   load_gdt(gdt_descr);
 
cr4 = read_cr4();
 
diff -r e9d5b8e6f5ee arch/i386/kernel/entry.S
--- a/arch/i386/kernel/entry.S  Tue Mar 06 16:20:48 2007 +1100
+++ b/arch/i386/kernel/entry.S  Tue Mar 06 17:04:37 2007 +1100
@@ -561,8 +561,7 @@ END(syscall_badsys)
 #define FIXUP_ESPFIX_STACK \
/* since we are on a wrong stack, we cant make it a C code :( */ \
movl %fs:PDA_cpu, %ebx; \
-   PER_CPU(cpu_gdt_descr, %ebx); \
-   movl GDS_address(%ebx), %ebx; \
+   PER_CPU(cpu_gdt, %ebx); \
GET_DESC_BASE(GDT_ENTRY_ESPFIX_SS, %ebx, %eax, %ax, %al, %ah); \
addl %esp, %eax; \
pushl $__KERNEL_DS; \
diff -r e9d5b8e6f5ee arch/i386/kernel/traps.c
--- a/arch/i386/kernel/traps.c  Tue Mar 06 16:20:48 2007 +1100
+++ b/arch/i386/kernel/traps.c  Tue Mar 06 17:04:37 2007 +1100
@@ -1018,9 +1018,7 @@ fastcall unsigned long patch_espfix_desc
 fastcall unsigned long patch_espfix_desc(unsigned long uesp,
  unsigned long kesp)
 {
-   int cpu = smp_processor_id();
-   struct Xgt_desc_struct *cpu_gdt_descr = per_cpu(cpu_gdt_descr, cpu);
-   struct desc_struct *gdt = (struct desc_struct *)cpu_gdt_descr-address;
+   struct desc_struct *gdt = __get_cpu_var(cpu_gdt);
unsigned long base = (kesp - uesp)  -THREAD_SIZE;
unsigned long new_kesp = kesp - base;
unsigned long lim_pages = (new_kesp | (THREAD_SIZE - 1))  PAGE_SHIFT;
diff -r e9d5b8e6f5ee include/asm-i386/desc.h
--- a/include/asm-i386/desc.h   Tue Mar 06 16:20:48 2007 +1100
+++ b/include/asm-i386/desc.h   Tue Mar 06 17:04:37 2007 +1100
@@ -13,6 +13,7 @@
 #include asm/mmu.h
 
 extern struct 

[PATCH 6/8] Allow per-cpu variables to be page-aligned

2007-03-06 Thread Rusty Russell
Xen wants page-aligned GDT (and PDA must not cross a page-boundary,
but that doesn't happen at the moment since it's so close to start of
page).  Let's allow page-alignment in general for per-cpu data.

Because larger alignments can use more room, we increase the max
per-cpu memory to 64k rather than 32k: it's getting a little tight.

Signed-off-by: Rusty Russell [EMAIL PROTECTED]

diff -r 213b1ec27001 arch/alpha/kernel/vmlinux.lds.S
--- a/arch/alpha/kernel/vmlinux.lds.S   Tue Mar 06 19:01:59 2007 +1100
+++ b/arch/alpha/kernel/vmlinux.lds.S   Tue Mar 06 19:02:03 2007 +1100
@@ -69,7 +69,7 @@ SECTIONS
   . = ALIGN(8);
   SECURITY_INIT
 
-  . = ALIGN(64);
+  . = ALIGN(8192);
   __per_cpu_start = .;
   .data.percpu : { *(.data.percpu) }
   __per_cpu_end = .;
diff -r 213b1ec27001 arch/arm/kernel/vmlinux.lds.S
--- a/arch/arm/kernel/vmlinux.lds.S Tue Mar 06 19:01:59 2007 +1100
+++ b/arch/arm/kernel/vmlinux.lds.S Tue Mar 06 19:02:03 2007 +1100
@@ -59,7 +59,7 @@ SECTIONS
usr/built-in.o(.init.ramfs)
__initramfs_end = .;
 #endif
-   . = ALIGN(64);
+   . = ALIGN(4096);
__per_cpu_start = .;
*(.data.percpu)
__per_cpu_end = .;
diff -r 213b1ec27001 arch/cris/arch-v32/vmlinux.lds.S
--- a/arch/cris/arch-v32/vmlinux.lds.S  Tue Mar 06 19:01:59 2007 +1100
+++ b/arch/cris/arch-v32/vmlinux.lds.S  Tue Mar 06 19:02:03 2007 +1100
@@ -91,6 +91,7 @@ SECTIONS
}
SECURITY_INIT
 
+   . =  ALIGN (8192);
__per_cpu_start = .;
.data.percpu  : { *(.data.percpu) }
__per_cpu_end = .;
diff -r 213b1ec27001 arch/frv/kernel/vmlinux.lds.S
--- a/arch/frv/kernel/vmlinux.lds.S Tue Mar 06 19:01:59 2007 +1100
+++ b/arch/frv/kernel/vmlinux.lds.S Tue Mar 06 19:02:03 2007 +1100
@@ -57,6 +57,7 @@ SECTIONS
   __alt_instructions_end = .;
  .altinstr_replacement : { *(.altinstr_replacement) }
 
+  . = ALIGN(4096);
   __per_cpu_start = .;
   .data.percpu  : { *(.data.percpu) }
   __per_cpu_end = .;
diff -r 213b1ec27001 arch/i386/kernel/vmlinux.lds.S
--- a/arch/i386/kernel/vmlinux.lds.STue Mar 06 19:01:59 2007 +1100
+++ b/arch/i386/kernel/vmlinux.lds.STue Mar 06 19:02:03 2007 +1100
@@ -196,7 +196,7 @@ SECTIONS
__initramfs_end = .;
   }
 #endif
-  . = ALIGN(L1_CACHE_BYTES);
+  . = ALIGN(4096);
   .data.percpu  : AT(ADDR(.data.percpu) - LOAD_OFFSET) {
__per_cpu_start = .;
*(.data.percpu)
diff -r 213b1ec27001 arch/m32r/kernel/vmlinux.lds.S
--- a/arch/m32r/kernel/vmlinux.lds.STue Mar 06 19:01:59 2007 +1100
+++ b/arch/m32r/kernel/vmlinux.lds.STue Mar 06 19:02:03 2007 +1100
@@ -110,7 +110,7 @@ SECTIONS
   __initramfs_end = .;
 #endif
 
-  . = ALIGN(32);
+  . = ALIGN(4096);
   __per_cpu_start = .;
   .data.percpu  : { *(.data.percpu) }
   __per_cpu_end = .;
diff -r 213b1ec27001 arch/mips/kernel/vmlinux.lds.S
--- a/arch/mips/kernel/vmlinux.lds.STue Mar 06 19:01:59 2007 +1100
+++ b/arch/mips/kernel/vmlinux.lds.STue Mar 06 19:02:03 2007 +1100
@@ -119,7 +119,7 @@ SECTIONS
   .init.ramfs : { *(.init.ramfs) }
   __initramfs_end = .;
 #endif
-  . = ALIGN(32);
+  . = ALIGN(_PAGE_SIZE);
   __per_cpu_start = .;
   .data.percpu  : { *(.data.percpu) }
   __per_cpu_end = .;
diff -r 213b1ec27001 arch/parisc/kernel/vmlinux.lds.S
--- a/arch/parisc/kernel/vmlinux.lds.S  Tue Mar 06 19:01:59 2007 +1100
+++ b/arch/parisc/kernel/vmlinux.lds.S  Tue Mar 06 19:02:03 2007 +1100
@@ -181,7 +181,7 @@ SECTIONS
   .init.ramfs : { *(.init.ramfs) }
   __initramfs_end = .;
 #endif
-  . = ALIGN(32);
+  . = ALIGN(ASM_PAGE_SIZE);
   __per_cpu_start = .;
   .data.percpu  : { *(.data.percpu) }
   __per_cpu_end = .;
diff -r 213b1ec27001 arch/powerpc/kernel/vmlinux.lds.S
--- a/arch/powerpc/kernel/vmlinux.lds.S Tue Mar 06 19:01:59 2007 +1100
+++ b/arch/powerpc/kernel/vmlinux.lds.S Tue Mar 06 19:02:03 2007 +1100
@@ -139,11 +139,7 @@ SECTIONS
__initramfs_end = .;
}
 #endif
-#ifdef CONFIG_PPC32
-   . = ALIGN(32);
-#else
-   . = ALIGN(128);
-#endif
+   . = ALIGN(PAGE_SIZE);
.data.percpu : {
__per_cpu_start = .;
*(.data.percpu)
diff -r 213b1ec27001 arch/ppc/kernel/vmlinux.lds.S
--- a/arch/ppc/kernel/vmlinux.lds.S Tue Mar 06 19:01:59 2007 +1100
+++ b/arch/ppc/kernel/vmlinux.lds.S Tue Mar 06 19:02:03 2007 +1100
@@ -130,7 +130,7 @@ SECTIONS
   __ftr_fixup : { *(__ftr_fixup) }
   __stop___ftr_fixup = .;
 
-  . = ALIGN(32);
+  . = ALIGN(4096);
   __per_cpu_start = .;
   .data.percpu  : { *(.data.percpu) }
   __per_cpu_end = .;
diff -r 213b1ec27001 arch/s390/kernel/vmlinux.lds.S
--- a/arch/s390/kernel/vmlinux.lds.STue Mar 06 19:01:59 2007 +1100
+++ b/arch/s390/kernel/vmlinux.lds.STue Mar 06 19:02:03 2007 +1100
@@ -99,7 +99,7 @@ SECTIONS
   . = ALIGN(2);
   __initramfs_end = .;
 #endif
-  . = ALIGN(256);
+  . = ALIGN(4096);
   __per_cpu_start = .;
   .data.percpu  : { *(.data.percpu) }
   __per_cpu_end = .;

[PATCH 7/8] Page-align the GDT

2007-03-06 Thread Rusty Russell
Xen wants a dedicated page for the GDT.  I believe VMI likes it too.
lguest, KVM and native don't care.

Simple transformation to page-aligned struct gdt_page.

Signed-off-by: Rusty Russell [EMAIL PROTECTED]

diff -r 576929b5b43f arch/i386/kernel/cpu/common.c
--- a/arch/i386/kernel/cpu/common.c Tue Mar 06 16:28:38 2007 +1100
+++ b/arch/i386/kernel/cpu/common.c Tue Mar 06 16:47:11 2007 +1100
@@ -22,8 +22,8 @@
 
 #include cpu.h
 
-DEFINE_PER_CPU(struct desc_struct, cpu_gdt[GDT_ENTRIES]);
-EXPORT_PER_CPU_SYMBOL_GPL(cpu_gdt);
+DEFINE_PER_CPU(struct gdt_page, gdt_page);
+EXPORT_PER_CPU_SYMBOL_GPL(gdt_page);
 DEFINE_PER_CPU(struct i386_pda, _cpu_pda);
 EXPORT_PER_CPU_SYMBOL(_cpu_pda);
 
@@ -628,7 +628,7 @@ static inline void set_kernel_fs(void)
will soon come up. */
 __cpuinit void init_gdt(int cpu, struct task_struct *idle)
 {
-   struct desc_struct *gdt = per_cpu(cpu_gdt, cpu);
+   struct desc_struct *gdt = per_cpu(gdt_page, cpu).gdt;
struct i386_pda *pda = per_cpu(_cpu_pda, cpu);
 
/* Based on boot_gdt_table: set PDA so it can be used immediately */
@@ -649,7 +649,7 @@ void __cpuinit cpu_set_gdt(int cpu)
 {
struct Xgt_desc_struct gdt_descr;
 
-   gdt_descr.address = (unsigned long)per_cpu(cpu_gdt, cpu);
+   gdt_descr.address = (unsigned long)per_cpu(gdt_page, cpu).gdt;
gdt_descr.size = GDT_SIZE - 1;
 
load_gdt(gdt_descr);
diff -r 576929b5b43f arch/i386/kernel/entry.S
--- a/arch/i386/kernel/entry.S  Tue Mar 06 16:28:38 2007 +1100
+++ b/arch/i386/kernel/entry.S  Tue Mar 06 16:47:11 2007 +1100
@@ -561,7 +561,7 @@ END(syscall_badsys)
 #define FIXUP_ESPFIX_STACK \
/* since we are on a wrong stack, we cant make it a C code :( */ \
movl %fs:PDA_cpu, %ebx; \
-   PER_CPU(cpu_gdt, %ebx); \
+   PER_CPU(gdt_page, %ebx); \
GET_DESC_BASE(GDT_ENTRY_ESPFIX_SS, %ebx, %eax, %ax, %al, %ah); \
addl %esp, %eax; \
pushl $__KERNEL_DS; \
diff -r 576929b5b43f arch/i386/kernel/head.S
--- a/arch/i386/kernel/head.S   Tue Mar 06 16:28:38 2007 +1100
+++ b/arch/i386/kernel/head.S   Tue Mar 06 16:47:11 2007 +1100
@@ -592,7 +592,7 @@ ENTRY(early_gdt_descr)
.long boot_gdt_table
 
 /* The boot Global Descriptor Table: after boot we allocate a per-cpu copy */
-   .align L1_CACHE_BYTES
+   .p2align PAGE_SHIFT
 ENTRY(boot_gdt_table)
.quad 0x/* NULL descriptor */
.quad 0x/* 0x0b reserved */
diff -r 576929b5b43f arch/i386/kernel/traps.c
--- a/arch/i386/kernel/traps.c  Tue Mar 06 16:28:38 2007 +1100
+++ b/arch/i386/kernel/traps.c  Tue Mar 06 16:28:40 2007 +1100
@@ -1018,7 +1018,7 @@ fastcall unsigned long patch_espfix_desc
 fastcall unsigned long patch_espfix_desc(unsigned long uesp,
  unsigned long kesp)
 {
-   struct desc_struct *gdt = __get_cpu_var(cpu_gdt);
+   struct desc_struct *gdt = __get_cpu_var(gdt_page).gdt;
unsigned long base = (kesp - uesp)  -THREAD_SIZE;
unsigned long new_kesp = kesp - base;
unsigned long lim_pages = (new_kesp | (THREAD_SIZE - 1))  PAGE_SHIFT;
diff -r 576929b5b43f include/asm-i386/desc.h
--- a/include/asm-i386/desc.h   Tue Mar 06 16:28:38 2007 +1100
+++ b/include/asm-i386/desc.h   Tue Mar 06 16:47:22 2007 +1100
@@ -13,7 +13,11 @@
 #include asm/mmu.h
 
 extern struct desc_struct boot_gdt_table[GDT_ENTRIES];
-DECLARE_PER_CPU(struct desc_struct, cpu_gdt[GDT_ENTRIES]);
+struct gdt_page
+{
+   struct desc_struct gdt[GDT_ENTRIES];
+} __attribute__((aligned(PAGE_SIZE)));
+DECLARE_PER_CPU(struct gdt_page, gdt_page);
 
 struct Xgt_desc_struct {
unsigned short size;
@@ -24,7 +28,7 @@ extern struct Xgt_desc_struct idt_descr;
 extern struct Xgt_desc_struct idt_descr;
 static inline struct desc_struct *get_cpu_gdt_table(unsigned int cpu)
 {
-   return per_cpu(cpu_gdt, cpu);
+   return per_cpu(gdt_page, cpu).gdt;
 }
 
 extern struct desc_struct idt_table[];
@@ -104,7 +108,8 @@ static inline fastcall void native_set_l
pack_descriptor(a, b, (unsigned long)addr,
entries * sizeof(struct desc_struct) - 1,
DESCTYPE_LDT, 0);
-   write_gdt_entry(__get_cpu_var(cpu_gdt), GDT_ENTRY_LDT, a, b);
+   write_gdt_entry(__get_cpu_var(gdt_page).gdt, GDT_ENTRY_LDT,
+   a, b);
__asm__ __volatile__(lldt %w0::q (GDT_ENTRY_LDT*8));
}
 }


-
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: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Thomas Gleixner
On Tue, 2007-03-06 at 13:51 +0100, Ingo Molnar wrote:
 * Ingo Molnar [EMAIL PROTECTED] wrote:
 
BTW, Ingo, can you suspend/resume any number of times with this 
patch?
   
   well I could at least two times in a row in my minimalistic setup 
   (config attached) however using the full kernel config it still 
   hangs ... (config also attached in case you watn to compare it).
  
  i can confirm that with your full config i see a hang too. This is 
  most likely the ACPI problem - we are debugging this now and will come 
  up with a patch.
 
 update: this only happens with simulation, and even then it's not a full 
 hang but 'hangs until i hit a key'. With real resume i'm hitting a real 
 key anyway so it doesnt hang.

Hmm. The key is consumed in the BIOS, so there should be no
interrupt. /me digs deeper.

tglx


-
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: [5/6] 2.6.21-rc2: known regressions

2007-03-06 Thread Ingo Molnar

* Michael S. Tsirkin [EMAIL PROTECTED] wrote:

  update: this only happens with simulation, and even then it's not a 
  full hang but 'hangs until i hit a key'. With real resume i'm 
  hitting a real key anyway so it doesnt hang.
 
 How 'bout my .config?

your config works fine here too - did full suspend/resume twice without 
any problems. Maybe it's the ACPI related regression Thomas is seeing.

Ingo
-
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 8/8] Convert PDA into the percpu section

2007-03-06 Thread Rusty Russell
Currently x86 (similar to x84-64) has a special per-cpu structure
called i386_pda which can be easily and efficiently referenced via
the %fs register.  An ELF section is more flexible than a structure,
allowing any piece of code to use this area.  Indeed, such a section
already exists: the per-cpu area.

So this patch
(1) Removes the PDA and uses per-cpu variables for each current member.
(2) Replaces the __KERNEL_PDA segment with __KERNEL_PERCPU.
(3) Creates a per-cpu mirror of __per_cpu_offset called this_cpu_off, which
can be used to calculate addresses for this CPU's variables.
(4) Moves the boot cpu's GDT/percpu setup to smp_prepare_boot_cpu(),
immediately after the per-cpu areas are allocated.

The result is one less x86-specific concept.

Signed-off-by: Rusty Russell [EMAIL PROTECTED]

diff -r b30bbd45ba64 arch/i386/kernel/asm-offsets.c
--- a/arch/i386/kernel/asm-offsets.cTue Mar 06 23:35:01 2007 +1100
+++ b/arch/i386/kernel/asm-offsets.cTue Mar 06 23:35:03 2007 +1100
@@ -15,7 +15,6 @@
 #include asm/processor.h
 #include asm/thread_info.h
 #include asm/elf.h
-#include asm/pda.h
 #ifdef CONFIG_LGUEST_GUEST
 #include asm/lguest.h
 #include ../lguest/lg.h
@@ -105,10 +104,6 @@ void foo(void)
 
OFFSET(crypto_tfm_ctx_offset, crypto_tfm, __crt_ctx);
 
-   BLANK();
-   OFFSET(PDA_cpu, i386_pda, cpu_number);
-   OFFSET(PDA_pcurrent, i386_pda, pcurrent);
-
 #ifdef CONFIG_PARAVIRT
BLANK();
OFFSET(PARAVIRT_enabled, paravirt_ops, paravirt_enabled);
diff -r b30bbd45ba64 arch/i386/kernel/cpu/common.c
--- a/arch/i386/kernel/cpu/common.c Tue Mar 06 23:35:01 2007 +1100
+++ b/arch/i386/kernel/cpu/common.c Tue Mar 06 23:37:51 2007 +1100
@@ -18,14 +18,11 @@
 #include asm/apic.h
 #include mach_apic.h
 #endif
-#include asm/pda.h
 
 #include cpu.h
 
 DEFINE_PER_CPU(struct gdt_page, gdt_page);
 EXPORT_PER_CPU_SYMBOL_GPL(gdt_page);
-DEFINE_PER_CPU(struct i386_pda, _cpu_pda);
-EXPORT_PER_CPU_SYMBOL(_cpu_pda);
 
 static int cachesize_override __cpuinitdata = -1;
 static int disable_x86_fxsr __cpuinitdata;
@@ -600,51 +597,44 @@ void __init early_cpu_init(void)
 #endif
 }
 
-/* Make sure %gs is initialized properly in idle threads */
+/* Make sure %fs is initialized properly in idle threads */
 struct pt_regs * __devinit idle_regs(struct pt_regs *regs)
 {
memset(regs, 0, sizeof(struct pt_regs));
-   regs-xfs = __KERNEL_PDA;
+   regs-xfs = __KERNEL_PERCPU;
return regs;
 }
 
-/* Initial PDA used by boot CPU */
-struct i386_pda boot_pda = {
-   ._pda = boot_pda,
-   .cpu_number = 0,
-   .pcurrent = init_task,
-};
-
 static inline void set_kernel_fs(void)
 {
-   /* Set %fs for this CPU's PDA.  Memory clobber is to create a
-  barrier with respect to any PDA operations, so the compiler
-  doesn't move any before here. */
-   asm volatile (mov %0, %%fs : : r (__KERNEL_PDA) : memory);
-}
-
-/* Initialize the CPU's GDT and PDA.  This is either the boot CPU doing itself
+   /* Set %fs for this CPU's per-cpu area.  Memory clobber is to
+  create a barrier with respect to any per-cpu operations, so the
+  compiler doesn't move any before here. */
+   asm volatile (mov %0, %%fs : : r (__KERNEL_PERCPU) : memory);
+}
+
+/* Initialize the CPU's GDT.  This is either the boot CPU doing itself
(still using boot_gdt_table), or a CPU doing it for a secondary which
will soon come up. */
 __cpuinit void init_gdt(int cpu, struct task_struct *idle)
 {
struct desc_struct *gdt = per_cpu(gdt_page, cpu).gdt;
-   struct i386_pda *pda = per_cpu(_cpu_pda, cpu);
-
-   /* Based on boot_gdt_table: set PDA so it can be used immediately */
+
+   /* Based on boot_gdt_table: set percpu so it can be used immediately */
memcpy(gdt, boot_gdt_table, GDT_SIZE);
-   pack_descriptor((u32 *)gdt[GDT_ENTRY_PDA].a,
-   (u32 *)gdt[GDT_ENTRY_PDA].b,
-   (unsigned long)pda, sizeof(*pda) - 1,
+#ifdef CONFIG_SMP
+   pack_descriptor((u32 *)gdt[GDT_ENTRY_PERCPU].a,
+   (u32 *)gdt[GDT_ENTRY_PERCPU].b,
+   __per_cpu_offset[cpu], 0xF,
0x80 | DESCTYPE_S | 0x2, 0); /* present read-write data 
segment */
-
-   memset(pda, 0, sizeof(*pda));
-   pda-_pda = pda;
-   pda-cpu_number = cpu;
-   pda-pcurrent = idle;
-}
-
-/* Move this CPU from boot_gdt_table  boot_pda to this cpu's proper one. */
+   per_cpu(this_cpu_off, cpu) = __per_cpu_offset[cpu];
+   per_cpu(cpu_number, cpu) = cpu;
+#endif /* SMP*/
+
+   per_cpu(current_task, cpu) = idle;
+}
+
+/* Move this CPU from boot_gdt_table to this cpu's proper one. */
 void __cpuinit cpu_set_gdt(int cpu)
 {
struct Xgt_desc_struct gdt_descr;
@@ -738,8 +728,7 @@ void __cpuinit cpu_init(void)
int cpu = smp_processor_id();
struct task_struct *curr = current;
 
-   /* Set up the real GDT and PDA, so we can 

Re: Problem with freezable workqueues

2007-03-06 Thread Johannes Berg
On Tue, 2007-02-27 at 22:51 +0100, Rafael J. Wysocki wrote:

 For 2.6.21-rc1 I've invented the appended workaround (works for me, waiting 
 for
 Johannes to confirm it works for him too), but I think we need something 
 better
 for -mm and future kernels.

Finally I could get back to this but after reading the thread I figured
it might not be necessary to test this. Please let me know ASAP if you
want this patch tested as well or it'll take quite a long time (going
skiing for a week on Saturday)

In any case, I made the two xfs workqueues non-freezable and everything
on my quad powermac works again, I also couldn't detect any filesystem
correction. I wanted to adapt the BUG_ON(block IO not from suspend code)
patch from suspend2 but haven't gotten around to it yet.

johannes


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


Re: [PATCH 8/8] Convert PDA into the percpu section

2007-03-06 Thread Ingo Molnar

* Rusty Russell [EMAIL PROTECTED] wrote:

 Currently x86 (similar to x84-64) has a special per-cpu structure 
 called i386_pda which can be easily and efficiently referenced via 
 the %fs register.  An ELF section is more flexible than a structure, 
 allowing any piece of code to use this area.  Indeed, such a section 
 already exists: the per-cpu area.
 
 So this patch
 (1) Removes the PDA and uses per-cpu variables for each current member.

hmm ... i very much like this, but its needs performance and kernel-size 
testing before it can move from -mm into mainline. We are now exposing 
wide ranges of the kernel to segment prefixes again. (Btw., i'd expect 
there to be a kernel size reduction.)

Ingo
-
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 6/8] Allow per-cpu variables to be page-aligned

2007-03-06 Thread Ingo Molnar

* Rusty Russell [EMAIL PROTECTED] wrote:

 Xen wants page-aligned GDT (and PDA must not cross a page-boundary, 
 but that doesn't happen at the moment since it's so close to start of 
 page).  Let's allow page-alignment in general for per-cpu data.
 
 Because larger alignments can use more room, we increase the max 
 per-cpu memory to 64k rather than 32k: it's getting a little tight.

i recently needed page-aligned per-cpu data too for KVM-paravirt. Btw., 
what's the size increase of the native kernel?

Acked-by: Ingo Molnar [EMAIL PROTECTED]

Ingo
-
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 1/8] Remove cpu_gdt_table: use boot_gdt_table until migration to per-cpu

2007-03-06 Thread Ingo Molnar

* Rusty Russell [EMAIL PROTECTED] wrote:

 +/* The boot Global Descriptor Table: after boot we allocate a per-cpu copy */
   .align L1_CACHE_BYTES
  ENTRY(boot_gdt_table)
 - .fill GDT_ENTRY_BOOT_CS,8,0
 - .quad 0x00cf9a00/* kernel 4GB code at 0x */
 - .quad 0x00cf9200/* kernel 4GB data at 0x */
 -
 -/*
 - * The Global Descriptor Table contains 28 quadwords, per-CPU.
 - */
 - .align L1_CACHE_BYTES
 -ENTRY(cpu_gdt_table)
   .quad 0x/* NULL descriptor */
   .quad 0x/* 0x0b reserved */
 - .quad 0x/* 0x13 reserved */
 - .quad 0x/* 0x1b reserved */
 + .quad 0x00cf9a00/* boot: 4GB code at 0x */
 + .quad 0x00cf9200/* boot: 4GB data at 0x */
   .quad 0x/* 0x20 unused */
   .quad 0x/* 0x28 unused */
   .quad 0x/* 0x33 TLS entry 1 */

actually, the reason for the small boot GDT was that some systems 
wouldnt even boot with a larger GDT. (there was some BIOS interaction, 
forgot what it was - iirc it was mach-visws and also some other older 
box)

the 'simplification' you do here is actually how Linux worked before it 
was fixed for those systems.

so i'd be quite nervous to touch this area of the GDT code. (I'd support 
a renaming though, gdt_table is indeed ugly.)

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/8] Remove NR_CPUS from asm-generic/percpu.h

2007-03-06 Thread Ingo Molnar

* Rusty Russell [EMAIL PROTECTED] wrote:

 I managed to get an error about NR_CPUS undefined after a make 
 allyesconfig.  Admittedly this was a patched kernel, but it's easy to 
 remove it and avoid the error in future even if it's OK at the moment.

 -extern unsigned long __per_cpu_offset[NR_CPUS];
 +extern unsigned long __per_cpu_offset[];

i'd much rather have us fix that include file dependency problem than to 
work it around by hiding the true dimension of the __per_cpu_offset 
array

Ingo
-
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.21-rc2-mm2

2007-03-06 Thread Con Kolivas
On Tuesday 06 March 2007 23:52, Thomas Gleixner wrote:
 On Tue, 2007-03-06 at 22:58 +1100, Con Kolivas wrote:
  (tglx cc'ed as he may know something about this - sorry if it's
  inappropriate)

 John cc'ed as well :)

Thanks.

   [8018401c] do_timer+0x301/0x419

  ---
 
  list *do_timer+0x301
  0x8018401c is in do_timer
  (/home/con/kernel/linux-2.6.21-rc2-mm2/include/linux/clocksource.h:186).
  181 u64 tmp;
  182
  183 /* XXX - All of this could use a whole lot of
  optimization */ 184 tmp = length_nsec;
  185 tmp = c-shift;
  186 tmp += c-mult/2;
  187 do_div(tmp, c-mult);
  188
  189 c-cycle_interval = (cycle_t)tmp;
  190 if (c-cycle_interval == 0)

 That's extremly strange. This is inside of
 clocksource_calculate_interval() in:

 static void change_clocksource(void)
 {
 struct clocksource *new;
 cycle_t now;
 u64 nsec;

 new = clocksource_get_next();

 if (clock == new)
 return;

 now = clocksource_read(new);
 nsec =  __get_nsec_offset();
 timespec_add_ns(xtime, nsec);

 clock = new;
 clock-cycle_last = now;

 clock-error = 0;
 clock-xtime_nsec = 0;
   clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);

 tick_clock_notify();

 printk(KERN_INFO Time: %s clocksource has been installed.\n,
clock-name);
 }

 So clock seems to be NULL, but was accessed before
 clocksource_calculate_interval() as well.

It seems to be specifically tripping at c-mult after reading c-shift if I'm 
reading it correctly.

Note again, this is qemu, not real hardware and it will likely be giving very 
unrealistic values for timer calibrations.

-- 
-ck
-
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 1/8] Remove cpu_gdt_table: use boot_gdt_table until migration to per-cpu

2007-03-06 Thread Ingo Molnar

* Ingo Molnar [EMAIL PROTECTED] wrote:

  +   .quad 0x00cf9a00/* boot: 4GB code at 0x */
  +   .quad 0x00cf9200/* boot: 4GB data at 0x */
  .quad 0x/* 0x20 unused */
  .quad 0x/* 0x28 unused */
  .quad 0x/* 0x33 TLS entry 1 */
 
 actually, the reason for the small boot GDT was that some systems 
 wouldnt even boot with a larger GDT. (there was some BIOS interaction, 
 forgot what it was - iirc it was mach-visws and also some other older 
 box)
 
 the 'simplification' you do here is actually how Linux worked before 
 it was fixed for those systems.
 
 so i'd be quite nervous to touch this area of the GDT code. (I'd 
 support a renaming though, gdt_table is indeed ugly.)

and this seems to have a ripple effect on the rest of your GDT changes - 
i'll wait for this to be cleared before doing a line by line review of 
them. I commented on the mostly-unaffected ones already.

Ingo
-
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] Wistron button support for TravelMate 610

2007-03-06 Thread Dmitry Torokhov

Hi Eric,

On 3/5/07, Eric Piel [EMAIL PROTECTED] wrote:

Hello,

Here is a patch adding support to wistron button for Acer TravelMate
610. This is tested and works fine with the exception of the leds which
cannot be controlled (yet, that would require writing a led interface
for them when I've got time ;-) )



I believe we have KEY_WLAN for Wifi, not KEY_XFER. I will fix that up.


I'm sending just this one for now (as I can test it) but if you like it,
I would like to try to add all the database of keyboards available in
acerhk (that Olaf has written).


That would be nice. I have one request though - please send patches
inline instead of attachments, or, if you need to send it as an
attachment then put patch description and signed-off-by there as well
so I don't have to reassemble it.

--
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: Question: shutdown Linux from user space

2007-03-06 Thread Jiri Kosina
On Tue, 6 Mar 2007, Mockern wrote:

 I need to shutdown Linux from user level application. Which is the best 
 way to do it? (I need it for embedded system)

Use sys_reboot() syscall with either LINUX_REBOOT_CMD_HALT or 
LINUX_REBOOT_CMD_POWER_OFF.

Also this is probably offtopic here, please use kernelnewbies mailinglist 
instead.

-- 
Jiri Kosina
-
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: encrypting jffs2 filesystem with DM-crypt or what else?

2007-03-06 Thread markus reichelt
* emin ak [EMAIL PROTECTED] wrote:

 I need to encrypt a jffs2/mtd formatted flash filesystem for an
 embedded device, Normally using a loopback interface (cryptoloop,
 DM-crypt or loop-aes) solves this problem but they are not well
 known on journalling file systems (like jffs2) because of cached
 write etc.. Also I could'nt find any guideline for encrypting
 fikesystem on a flash.

device-backed loops are ok, file-based once aren't. The cache issue
you talk about concerns writing caches of HDDs f.e., I haven't seen a
flash device with writing cache. However, in most cases writing cache
can be turned off.

Go with README in the loop-aes package. Don't use cryptoloop, it's
insecure.


 There is an ugly workaround to overcome this problem, I have placed
 an encrypted ext2 filesystem image on an normal jffs2 partition and
 mount this encrypted partition on a loopback, but this is not
 secure, consumes alot for disk space and not reliable (is'nt it?)
 Is there any other way to encrypt an jjffs2 partition, if not, what
 do you think about my ugly workaround?

You shouldn't do that. One more option is, in case you feel lucky and
space is not of great concern, ecryptfs in latest kernels. It's still
experimental but its roadmap looks promising. And they need testers
;-)


-- 
left blank, right bald


pgpMhGsJPmT0t.pgp
Description: PGP signature


[ALSA PATCH] alsa-git merge request

2007-03-06 Thread Jaroslav Kysela

Linus, please pull from [the linus branch at]:

  master.kernel.org:/pub/scm/linux/kernel/git/perex/alsa.git linus
gitweb interface:
  http://www.kernel.org/git/?p=linux/kernel/git/perex/alsa.git

The GNU patch is available at:

  ftp://ftp.alsa-project.org/pub/kernel-patches/alsa-git-2007-03-06.patch.gz

The following files will be updated:

 Documentation/sound/alsa/ALSA-Configuration.txt |   12 ++-
 include/sound/version.h |4 +-
 sound/pci/ac97/ac97_patch.c |2 +
 sound/pci/ali5451/ali5451.c |2 +
 sound/pci/cmipci.c  |   18 +++
 sound/pci/echoaudio/echoaudio.c |2 +
 sound/pci/hda/patch_analog.c|3 ++
 sound/pci/hda/patch_conexant.c  |8 -
 sound/pci/hda/patch_realtek.c   |   21 --
 sound/pci/hda/patch_sigmatel.c  |   35 +--
 sound/pci/riptide/riptide.c |2 +
 sound/pci/rme9652/hdspm.c   |2 +
 sound/soc/codecs/wm9712.c   |3 +-
 13 files changed, 94 insertions(+), 20 deletions(-)


The following things were done:

Jaroslav Kysela (1):
  [ALSA] version 1.0.14rc3

Joe Sauer (1):
  [ALSA] soc - Fix WM9712 register cache entry

Liam Girdwood (1):
  [ALSA] soc - WM9712 PCM volume

Takashi Iwai (7):
  [ALSA] hda-codec - Add LFE support on Dell M90
  [ALSA] hda-codec - Add missing Mic Boost controls for ALC262
  [ALSA] hda-codec - Define pin configs for MacBooks
  [ALSA] Add missing sysfs device assignment for ALSA PCI drivers
  [ALSA] ac97 - Add Thinkpad X31 and R40 to AD1981x blacklist
  [ALSA] hda-codec - Add missing Mic Boost for AD1986A codec
  [ALSA] cmipci - Allow to disable integrated FM port

Tobin Davis (2):
  [ALSA] hda-codec - Add method for configuring Mac Pro without PCI SSID
  [ALSA] hda-codec - Fix logic error in headphone mute for Conexant codecs


-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
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] Use a zero-size array in the struct devres

2007-03-06 Thread Catalin Marinas
Tejun,

Tejun Heo [EMAIL PROTECTED] wrote:
 Catalin Marinas wrote:
 Commit 9ac7849e35f705830f7b016ff272b0ff1f7ff759 adds the devres
 structure containing a flexible unsigned long long array, with a
 comment about the guaranteed alignment. According to the gcc manual,
 flexible arrays are considered incomplete types and it is an error to
 ask for their alignment. This patch makes data[] a zero-size array.

 The gcc manual says nothing about alignment.  What it says is sizeof()
 doesn't work.  If flexible array doesn't honor the alignment of the
 declared type, it would be useless for its designed purpose of
 supporting *array* of dynamically-determined length.

Chapter 5.31 (http://gcc.gnu.org/onlinedocs/gcc/Alignment.html) states
that it is an error to ask for the alignment of an incomplete type
and flexible array members have incomplete type (according to ISO C99
as described in http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html).

It sounds to me like the alignment of an incomplete type is not
guaranteed (as you can't even enquire about it, though I might be
wrong). This is probably dependent on the compiler as well - with
gcc-3.3 on x86, __alignof__(unsigned long long) is 8 but the
offsetof(struct test, data) below is 12 (and it doesn't make any
difference whether it is a 0-size array or not):

struct test {
unsigned long a;
unsigned long b;
unsigned long c;
unsigned long long data[];
};

 I came across this when trying to build kmemleak as the modified
 container_of macro tries to get the size of the devres.data member and
 sizeof cannot be applied to incomplete types.

 If kmemleak's container_of cannot deal with the current struct devres,
 it means it can't deal with flexible arrays at all.  Flexible array
 being the standard as opposed to 0 size array gcc extension, I guess a
 lot of people would prefer flexible array.

I'm OK with flexible arrays (kmemleak uses them as well) but not as a
member of structure getting passed to the container_of macro.

I did a quick grep through the kernel and it looks like Linux mainly
uses 0-size rather than flexible arrays at the end of a structure
(500 vs ~14). This might be for historical reasons but it's not a big
issue in modifying them.

 It would be best if kmemleak's container_of can be modified to work with
 flexible arrays.  If that's not possible, I guess it needs wider
 discussion to determine whether to ditch flexible array for
 kmemleak.

Kmemleak needs the sizeof the member passed to container_of and I'm
not aware of any __builtin_* predicate that would detect incomplete
types.

-- 
Catalin
-
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 -rt] airo: threaded IRQ handler sleeps forever

2007-03-06 Thread Michal Schmidt
The airo driver tries to avoid excessive latencies when issuing commands
to the card by calling schedule() after several retries. But
issuecommand() can be run from an interrupt handler. The function is
careful enough to check with in_atomic() if it is safe to call schedule().
This check breaks when the interrupt handler is threaded, because then
in_atomic() is always false there. The handler is run as
TASK_INTERRUPTIBLE, so schedule() takes it off the runqueue and it never
wakes up again.
Here's an obvious fix - simply don't call schedule() when using
preemptible hardirqs.
An improved solution might be to identify the commands that take so long
to issue and avoid sending them from the interrupt handler. In my
testing there was only one such command: CMD_ACCESS. I need to
investigate if it's always possible to delay it to airo's kthread.

Signed-off-by: Michal Schmidt [EMAIL PROTECTED]

diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index 44a2270..98014c0 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -3938,8 +3938,10 @@ static u16 issuecommand(struct airo_info *ai, Cmd *pCmd, 
Resp *pRsp) {
if ((IN4500(ai, COMMAND)) == pCmd-cmd)
// PC4500 didn't notice command, try again
OUT4500(ai, COMMAND, pCmd-cmd);
+#ifndef CONFIG_PREEMPT_HARDIRQS
if (!in_atomic()  (max_tries  255) == 0)
schedule();
+#endif
}
 
if ( max_tries == -1 ) {


-
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.21-rc2-mm2

2007-03-06 Thread Thomas Gleixner
On Wed, 2007-03-07 at 00:24 +1100, Con Kolivas wrote:
  printk(KERN_INFO Time: %s clocksource has been installed.\n,
 clock-name);
  }
 
  So clock seems to be NULL, but was accessed before
  clocksource_calculate_interval() as well.
 
 It seems to be specifically tripping at c-mult after reading c-shift if I'm 
 reading it correctly.
 
 Note again, this is qemu, not real hardware and it will likely be giving very 
 unrealistic values for timer calibrations.

I know, but this does not really explain why the 

tmp += c-mult/2;

results in a NULL pointer access after 

tmp = c-shift;

Does disassembling the code in question give some info ? You might also
try to look with GDB at it.

tglx


-
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: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793

2007-03-06 Thread Jiri Kosina
On Tue, 6 Mar 2007, Amedee Van Gasse wrote:

  This would be in fact very interesting to know. 1) does the BUG trigger 
  only with newer versions of bluez-utils? 2) If so, does everything work 
  with these older versions, or do the things fail in a same way, but 
  silently?
 I could install an older version of my distribution and see what 
 happens, but that means I'll have to reserve some disk space and a lot 
 more time. I hope one of the many live cds also support bluetooth, that 
 would speed things up a lot. Will try to do that, but it'll take some 
 time.

I think that for the initial test just installing older version of 
bluez-utils might be enough to verify whether they do or don't cause the 
BUG to trigger.

 I installed something called usbsnoop and waved a lot of dead chickens 
 to convince the bluetooth receiver to pair again with the keyboard. 
 Attached is the logfile. I hope this helps, if not just tell me what you 
 need.

Thanks. Looks like there are the following reports that could potentially 
be used to switch the dongle from HID to HCI (assuming that Logitech 
didn't change behavior of its devices too much)

ff 80 00 00 03 00
ff 80 80 02 00 00
ff 80 80 01 00 00
(and maybe ff 80 09 01 00 00 ?)

This doesn't look like what is currently supported by hid2hci function 
switch_logitech(), but I would rather leave this to Marcel.

Thanks,

-- 
Jiri Kosina
-
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] Use a zero-size array in the struct devres

2007-03-06 Thread Tejun Heo
Catalin Marinas wrote:
 Chapter 5.31 (http://gcc.gnu.org/onlinedocs/gcc/Alignment.html) states
 that it is an error to ask for the alignment of an incomplete type
 and flexible array members have incomplete type (according to ISO C99
 as described in http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html).
 
 It sounds to me like the alignment of an incomplete type is not
 guaranteed (as you can't even enquire about it, though I might be
 wrong). This is probably dependent on the compiler as well - with
 gcc-3.3 on x86, __alignof__(unsigned long long) is 8 but the
 offsetof(struct test, data) below is 12 (and it doesn't make any
 difference whether it is a 0-size array or not):
 
 struct test {
 unsigned long a;
 unsigned long b;
 unsigned long c;
 unsigned long long data[];
 };

data[0] and data[1] or whatever will also give you offset of 12.  Dunno
why, but it is.  Anyways, whatever the wording in the manual is,
flexible arrays just have to have the required alignment to do its job
as advertised.  :-)

 I came across this when trying to build kmemleak as the modified
 container_of macro tries to get the size of the devres.data member and
 sizeof cannot be applied to incomplete types.
 If kmemleak's container_of cannot deal with the current struct devres,
 it means it can't deal with flexible arrays at all.  Flexible array
 being the standard as opposed to 0 size array gcc extension, I guess a
 lot of people would prefer flexible array.
 
 I'm OK with flexible arrays (kmemleak uses them as well) but not as a
 member of structure getting passed to the container_of macro.
 
 I did a quick grep through the kernel and it looks like Linux mainly
 uses 0-size rather than flexible arrays at the end of a structure
 (500 vs ~14). This might be for historical reasons but it's not a big
 issue in modifying them.

I think it's mostly historical.  Flexible array is still a relatively
new thing.  I don't mind changing devres to zero sized array, but please
explain in the commit message and as a comment that the choice is for
kmemleak's container_of(), and cc Greg K-H as the change should probably
go through his tree.

Thanks.

-- 
tejun
-
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: 2.6.20-1 not working on ibook g4 (BUG/Oops)

2007-03-06 Thread francesco foresti
Hi,
i'm happy to report that i've been able to boot my ibook without any error, 
using Ken Moffat's .config (thanks again Ken!) as a base. 
I'm putting the prominent part here for completeness.
I still have no idea what caused these errors, but at least i'll try to find
what was compiled with the failing config that is not compiled anymore with 
this one.

Best
-- 
===
Francesco Foresti
Registered Linux User #332599
key fingerprint = 59D5 1E61 6631 5DEF DC88 C64C 7F53 2F45 99FB CD21
CONFIG_PPC32=y
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
CONFIG_CLASSIC32=y
CONFIG_6xx=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_32=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_INITRAMFS_SOURCE=
CONFIG_SYSCTL=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_KMOD=y
CONFIG_BLOCK=y
CONFIG_LBD=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
CONFIG_DEFAULT_IOSCHED=anticipatory
CONFIG_PPC_MULTIPLATFORM=y
CONFIG_PPC_PMAC=y
CONFIG_PPC_NATIVE=y
CONFIG_PPC_MPC106=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_PMAC=y
CONFIG_PPC601_SYNC_FIX=y
CONFIG_TAU=y
CONFIG_MPIC=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_PROC_DEVICETREE=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=
CONFIG_SECCOMP=y
CONFIG_ISA_DMA_API=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_PPC_INDIRECT_PCI=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCCARD=m
CONFIG_PCMCIA=m
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y
CONFIG_YENTA=m
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
CONFIG_PCCARD_NONSTATIC=m
CONFIG_HIGHMEM_START=0xfe00
CONFIG_LOWMEM_SIZE=0x3000
CONFIG_KERNEL_START=0xc000
CONFIG_TASK_SIZE=0x8000
CONFIG_BOOT_LOAD=0x0080
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_FIB_HASH=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG=cubic
CONFIG_NETFILTER=y
CONFIG_NETFILTER_NETLINK=m
CONFIG_NF_CONNTRACK_ENABLED=m
CONFIG_NF_CONNTRACK_SUPPORT=y
CONFIG_NF_CONNTRACK=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m
CONFIG_IP_DCCP_ACKVEC=y
CONFIG_IP_DCCP_CCID2=m
CONFIG_IP_DCCP_CCID3=m
CONFIG_IP_DCCP_TFRC_LIB=m
CONFIG_IP_DCCP_CCID3_RTO=100
CONFIG_LLC=m
CONFIG_ATALK=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y

Re: [ck] Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler

2007-03-06 Thread Al Boldi
Xavier Bestel wrote:
 On Tue, 2007-03-06 at 09:10 +1100, Con Kolivas wrote:
  Hah I just wish gears would go away. If I get hardware where it runs at
  just the right speed it looks like it doesn't move at all. On other
  hardware the wheels go backwards and forwards where the screen refresh
  rate is just perfectly a factor of the frames per second (or something
  like that).
 
  This is not a cpu scheduler test and you're inferring that there are cpu
  scheduling artefacts based on an application that has bottlenecks at
  different places depending on the hardware combination.

 I'd add that Xorg has its own scheduler (for X11 operations, of course),
 that has its own quirks, and chances are that it is the one you're
 testing with glxgears. And as Con said, as long as glxgears does more
 FPS than your screen refresh rate, its flickering its completely
 meaningless: it doesn't even attempt to sync with vblank. Al, you'd
 better try with Quake3 or Nexuiz, or even Blender if you want to test 3D
 interactivity under load.

Actually, games aren't really usefull to evaluate scheduler performance, due 
to their bursty nature.

OTOH, gears runs full throttle, including any of its bottlenecks. In fact, 
it's the bottlenecks that add to its realism.  It exposes underlying 
scheduler hickups visually, unless buffered by the display-driver, in which 
case you just use the vesa-driver to be sure.

If gears starts to flicker on you, just slow it down with a cpu hog like:

# while :; do :; done 

Add as many hogs as you need to make the hickups visible.

Again, these hickups are only visible when using uneven nice+ levels.

BTW, another way to show these hickups would be through some kind of a 
cpu/proc timing-tracer.  Do we have something like that?


Thanks!

--
Al

-
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] Use a zero-size array in the struct devres

2007-03-06 Thread Catalin Marinas
Tejun Heo [EMAIL PROTECTED] wrote:
 Catalin Marinas wrote:
 It sounds to me like the alignment of an incomplete type is not
 guaranteed (as you can't even enquire about it, though I might be
 wrong). This is probably dependent on the compiler as well - with
 gcc-3.3 on x86, __alignof__(unsigned long long) is 8 but the
 offsetof(struct test, data) below is 12 (and it doesn't make any
 difference whether it is a 0-size array or not):
 
 struct test {
 unsigned long a;
 unsigned long b;
 unsigned long c;
 unsigned long long data[];
 };

 data[0] and data[1] or whatever will also give you offset of 12.  Dunno
 why, but it is.  Anyways, whatever the wording in the manual is,
 flexible arrays just have to have the required alignment to do its job
 as advertised.  :-)

On ARM (with gcc-4) it gives 16 for both offsetof and sizeof.

 I did a quick grep through the kernel and it looks like Linux mainly
 uses 0-size rather than flexible arrays at the end of a structure
 (500 vs ~14). This might be for historical reasons but it's not a big
 issue in modifying them.

 I think it's mostly historical.  Flexible array is still a relatively
 new thing.  I don't mind changing devres to zero sized array, but please
 explain in the commit message and as a comment that the choice is for
 kmemleak's container_of(), and cc Greg K-H as the change should probably
 go through his tree.

OK. I'll probably wait until I post a new version of kmemleak against
2.6.21-rcX.

Thanks.

-- 
Catalin
-
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] hwbkpt: Hardware breakpoints (was Kwatch)

2007-03-06 Thread Alan Stern
On Mon, 5 Mar 2007, Roland McGrath wrote:

  The actual guarantee I need is that nobody will switch_to() the task while
  my routines are running.
 
 You can't get that.  It can always be woken for SIGKILL (which is a good
 thing).  What you are guaranteed is that if it does, it will never return
 to user mode.  So it has to be ok for switching in to use the bits in any
 intermediate state you might get them, meaning any possible garbage state
 is harmful only to user mode or is otherwise recoverable (worst case
 perhaps the exception handler has to know to ignore some traps).  This is
 already true with ptrace and -thread.debugreg, as well as the normal user
 registers.  In your case, if you wanted to be paranoid you could clear
 TIF_DEBUG before you touch anything, and set it again only after you're
 done (with memory barriers as needed).

Guess I'll have to take that approach.  The new additions to __switch_to() 
follow a linked list, and obviously it's not safe to do that while the 
list is being updated.  (No, I'm not about to start using RCU for this!)


  If someone really needs to do that, they can always put their own call to
  (un)register_kernel_hwbkpt() at the entry(exit) to the complex subsystems.  
  Or perhaps it should be a job for systemtap, which would use hwbkpt to do
  the actual work.
 
 But you don't have an option to avoid interrupting other CPUs to update,
 which is not necessary or desireable for this usage.  That's what I was
 referring to.  If it's not trivial to add, it isn't needed now.

I see your point.  If you want to monitor a certain location in kernel
space but only while in the context of a specific task, the new framework
doesn't provide any way of doing it.  One approach could be to use a
regular kernel breakpoint and return immediately if the task of interest
isn't the current one.  Beyond that, let's punt.


  Which implies that do_debug needs to decide whether or not to issue 
  SIGTRAP.  Presumably the condition will be that any of the DR_STEP or 
  DR_TRAPn bits remain set after the notifier chain has run.  This means the 
  kprobes code will have to be modified to clear DR_STEP in args-err.
 
 Yeah, I guess that's right.  It should still return NOTIFY_STOP when
 args-err has no other bits set, so notifiers aren't called with zero.

In practice that might not work.  On my machine, at least, reads of DR6
return ones in all the reserved bit positions.

Alan Stern

-
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] Wistron button support for TravelMate 610

2007-03-06 Thread Éric Piel

03/06/2007 02:36 PM, Dmitry Torokhov wrote/a écrit:

Hi Eric,

I believe we have KEY_WLAN for Wifi, not KEY_XFER. I will fix that up.
Oh! Yes, this sounds better, I used KEY_XFER just for historical reasons 
;-) Thanks






I'm sending just this one for now (as I can test it) but if you like it,
I would like to try to add all the database of keyboards available in
acerhk (that Olaf has written).


That would be nice. I have one request though - please send patches
inline instead of attachments, or, if you need to send it as an
attachment then put patch description and signed-off-by there as well
so I don't have to reassemble it.

Ok, sorry for the troubles. I'll keep patch and description together 
next time :-)


See you,
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/


  1   2   3   4   5   6   >