2.6.18-rc6-mm2

2.6.18-rc6-mm2

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/

- autofs4 mounting remains busted.

- CONFIG_BLOCK=n doesn't (quite) work.  Will fix later.

- CONFIG_MSI=y is probably broken - try disabling it before reporting
  interrupt-related oopses.  Then please report it whether or not that fixed
  it.

- Could I point out the fifth bullet-point in the "Boilerplate" section,
  below?

- git-cryptodev.patch is dropped due to my continuing inability to pull a
  clean git diff (there is hope, but more work is needed)

  - Ditto git-sas.patch

  - And git-audit-master.patch (I think).

  Things will improve around the 2.6.19-rc1 timeframe.

- 1,915 patches breaks the previous record by ~200.

- This kernel includes the patch to sort the PCI devices breadth-first. 
  This might cause strange things to happen (particular devices get assigned
  to different /dev nodes, for example).  If this is suspected, please try
  reverting gregkh-pci-pci-sort-device-lists-breadth-first.patch then send a
  report.



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 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 majordomo@vger.kernel.org

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

- Semi-daily 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.18-rc6-mm1:


 origin.patch
 git-acpi.patch
 git-alsa.patch
 git-agpgart.patch
 git-block.patch
 git-cifs.patch
 git-cpufreq.patch
 git-drm.patch
 git-dvb.patch
 git-geode.patch
 git-gfs2.patch
 git-ia64.patch
 git-ieee1394.patch
 git-infiniband.patch
 git-input.patch
 git-intelfb.patch
 git-kbuild.patch
 git-libata-all.patch
 git-lxdialog.patch
 git-mtd.patch
 git-netdev-all.patch
 git-net.patch
 git-nfs.patch
 git-ocfs2.patch
 git-parisc.patch
 git-pcmcia.patch
 git-powerpc.patch
 git-r8169.patch
 git-s390.patch
 git-scsi-misc.patch
 git-scsi-rc-fixes.patch
 git-scsi-target.patch
 git-watchdog.patch
 git-xfs.patch

 git trees

-use-the-correct-restart-option-for-futex_lock_pi.patch
-optical-proc-ide-media.patch
-sh-fix-fpn_start-typo.patch
-sis5513-add-sis-south-bridge-id-0x966.patch
-ext3_getblk-should-handle-hole-correctly.patch
-invalidate_complete_page-race-fix.patch
-nfs-large-non-page-aligned-direct-i-o-clobbers-memory.patch
-input-i8042-get-rid-of-polling-timer.patch
-asus-mv-device-ids.patch
-gregkh-usb-usb-hid-core.c-fix-duplicate-usb_device_id_gtco_404.patch
-gregkh-usb-usb-support-for-usb20svga-wh-usb20svga-dg.patch
-gregkh-usb-usb-new-device-id-for-ftdi_sio-usb-serial-driver.patch
-gregkh-usb-usb-usbtouchscreen-fix-itm-data-reading.patch
-gregkh-usb-usb-must_check-fixes.patch
-x86_64-mm-module-locks-raw-spinlock.patch

 Merged into mainline or a subsystem tree.

+libata-ignore-cfa-signature-while-sanity-checking-an-atapi-device.patch
+lockdep-double-the-number-of-stack-trace-entries.patch
+we-can-not-allow-anonymous-contributions-to-the-kernel.patch
+alim15x3c-m5229-rev-c8-support-for-dma-cd-writer.patch
+scsi-lockdep-annotation-in-scsi_send_eh_cmnd.patch
+rcu_do_batch-make-qlen-decrement-irq-safe.patch
+x86-reserve-a-boot-loader-id-number-for-xen.patch
+headers_check-improve-include-regexp.patch
+headers_check-clarify-error-message.patch
+headers_check-reduce-user-visible-noise-in-linux-nfs_fsh.patch
+headers_check-remove-asm-timexh-from-user-export.patch
+headers_check-move-inclusion-of-linux-linkageh-in.patch
+headers_check-move-kernel-only-includes-within-asm-i386-elfh.patch
+headers_check-dont-expose-pfn-stuff-to-userspace-in.patch
+headers_check-fix-userspace-build-of-asm-mips-pageh.patch
+cciss-version-update-new-hw.patch

 2.6.18 queue (already sent to Linus)

+usbserial-reference-leak.patch

 USB fix (probably for 2.6.18)

+jbd-fix-commit-of-ordered-data-buffers.patch

 JBD fix (for 2.6.19 and 2.6.18.x)

+fix-incorrect-handling-of-pci-express-root-bridge-_hid.patch

 PCI fix

+maintainers-updates-to-ieee-1394-subsystem.patch

 1394 maintainers update

+revert-libata-ignore-cfa-signature-while-sanity-checking-an-atapi-device.patch

 Make git-libata-all.patch apply.

+redo-libata-ignore-cfa-signature-while-sanity-checking-an-atapi-device.patch

 Reapply this fix after git-libata-all.patch.

+git-libata-all-ata_piix-build-fix.patch

 Fix git-libata-all.patch.

+rtnetlink-fix-netdevice-name-corruption.patch

 Fix the net-device-names-go-bad bug.

+gregkh-pci-pci-sort-device-lists-breadth-first.patch

 PCI tree update.

+gregkh-usb-usb-ub-let-cdrecord-to-see-a-device-with-media-absent.patch
+gregkh-usb-usb-core-must_check.patch
+gregkh-usb-usb-misc-must_check.patch
+gregkh-usb-usb-atm-must_check.patch
+gregkh-usb-usb-class-must_check.patch
+gregkh-usb-usb-input-must_check.patch
+gregkh-usb-usb-host-must_check.patch
+gregkh-usb-usb-serial-must_check-fixes.patch

 USB tree updates.

+watchdog-use-enotty-instead-of-enoioctlcmd-in-ioctl.patch

 Watchdog driver fixes.

+hostap_cs-added-support-for-proxim-harmony-pci-w-lan.patch

 Wireless device support.

+x86_64-mm-lockdep-stacktrace-no-recursion.patch
+x86_64-mm-compat-pselect-must-check.patch
+x86_64-mm-compat-uname-must-check.patch
+x86_64-mm-pda-noreturn.patch
+x86_64-mm-fix-idle-notifiers.patch
+x86_64-mm-pci-probe-type1-first.patch
+x86_64-mm-i386-acpi-mcfg-check.patch
+x86_64-mm-acpi-mcfg-check.patch
+x86_64-mm-remove-mcfg-dmi.patch
+x86_64-mm-insert-gart-region-into-resource-map.patch
+x86_64-mm-mcfg-resource.patch
+x86_64-mm-i386-mcfg-resource.patch
+x86_64-mm-i386-pack-descriptor.patch
+x86_64-mm-i386-multiline-oops.patch

 x86_64 tree updates.

+xfs-rename-uio_read.patch

 Rename a function in XFS to avoid a clash.

+numa-add-zone_to_nid-function-update.patch

 Improve numa-add-zone_to_nid-function.patch

+vm-add-per-zone-writeout-counter.patch

 Add new counter to /proc/vmstat: counts number of pages written out via the
 vm scanner.

+own-header-file-for-struct-page.patch
+convert-s390-page-handling-macros-to-functions.patch
+convert-s390-page-handling-macros-to-functions-fix.patch

 MM header file cleanups.

+frv-improve-frvs-use-of-generic-irq-handling.patch
+frv-permit-__do_irq-to-be-dispensed-with.patch

 FRV update.

+avr32-rename-at32stk100x-atstk100x.patch

 AVR32 update

+nommu-move-the-fallback-arch_vma_name-to-a-sensible-place-fix.patch

 Fix nommu-move-the-fallback-arch_vma_name-to-a-sensible-place.patch

+uml-tty-locking.patch

 TTY locking fix

-lockdep-core-add-enable-disable_irq_irqsave-irqrestore-apis-frv-fix.patch

 Folded into
 lockdep-core-add-enable-disable_irq_irqsave-irqrestore-apis.patch (I think)

+linux-kernel-dump-test-module-fixes.patch

 Fix linux-kernel-dump-test-module.patch

+ext3-more-whitespace-cleanups.patch
+ext3-fix-sparse-warnings.patch
+submittingpatches-add-a-note-about-format=flowed-when-sending-patches.patch
+kmemdup-introduce.patch
+kmemdup-some-users.patch
+linux-magich-for-magic-numbers.patch
+linux-magich-for-magic-numbers-sparc-fix.patch
+cpuset-fix-obscure-attach_task-vs-exiting-race.patch
+create-fs-utimesc.patch
+cciss-support-for-2tb-logical-volumes.patch

 Misc updates.

+add-genetlink-utilities-for-payload-length-calculation.patch
+fix-taskstats-size-calculation-use-the-new-genetlink-utility-functions.patch
+fix-getdelaysc-cpumask-length-and-error-reporting.patch

 taskstats fixes for the Comprehensive System Accounting patches in -mm.

-vt-update-spawnpid-to-be-a-struct-pid_t.patch
-vt-update-spawnpid-to-be-a-struct-pid_t-tidy.patch
+vt-rework-the-console-spawning-variables.patch
+vt-make-vt_pid-a-struct-pid-making-it-pid-wrap-around-safe.patch

 Updated.

+update-mq_notify-to-use-a-struct-pid.patch
+file-add-locking-to-f_getown.patch
+usb-fixup-usb-so-it-uses-struct-pid.patch

 More pid management updates.

+proc-convert-task_sig-to-use-lock_task_sighand.patch
+proc-convert-do_task_stat-to-use-lock_task_sighand.patch
+proc-drop-tasklist-lock-in-task_state.patch
+proc-properly-compute-tgid_offset.patch
+proc-remove-trailing-blank-entry-from-pid_entry-arrays.patch
+proc-remove-the-useless-smp-safe-comments-from-proc.patch
+proc-comment-what-proc_fill_cache-does.patch
+introduce-get_task_pid-to-fix-unsafe-get_pid.patch

 More /porc core updates.

+allow-ide_generic_all-to-be-used-modular-and-built-in.patch

 IDE fix.

+savagefb-use-generic-ddc-reading-fix.patch

 Fix savagefb-use-generic-ddc-reading.patch

+rcu-simplify-improve-batch-tuning.patch

 RCU tuneup.

+pr_debug-aio-use-size_t-length-modifier-in-pr_debug-format-arguments.patch
+pr_debug-configfs-use-size_t-length-modifier-in-pr_debug-format-argument.patch
+pr_debug-sysfs-use-size_t-length-modifier-in-pr_debug-format-arguments.patch
+pr_debug-umem-repair-nonexistant-bh-pr_debug-reference.patch
+pr_debug-tipar-repair-nonexistant-pr_debug-argument-use.patch
+pr_debug-dell_rbu-fix-pr_debug-argument-warnings.patch
+pr_debug-ifb-replace-missing-comma-to-separate-pr_debug-arguments.patch
+pr_debug-trident-use-size_t-length-modifier-in-pr_debug-format-arguments.patch
+pr_debug-check-pr_debug-arguments.patch
+isdn-debug-build-fix.patch
+isdn-more-pr_debug-fixes.patch

 Make pr_debug() check its arguments even if !defined(DEBUG).  Plus fixes
 arising from this.




All 1915 patches:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/patch-list

Re: 2.6.18-rc6-mm2

[Andy Whitcroft]

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> 
> - autofs4 mounting remains busted.
> 
> - CONFIG_BLOCK=n doesn't (quite) work.  Will fix later.
> 
> - CONFIG_MSI=y is probably broken - try disabling it before reporting
>   interrupt-related oopses.  Then please report it whether or not that fixed
>   it.
> 
> - Could I point out the fifth bullet-point in the "Boilerplate" section,
>   below?
> 
> - git-cryptodev.patch is dropped due to my continuing inability to pull a
>   clean git diff (there is hope, but more work is needed)
> 
>   - Ditto git-sas.patch
> 
>   - And git-audit-master.patch (I think).
> 
>   Things will improve around the 2.6.19-rc1 timeframe.
> 
> - 1,915 patches breaks the previous record by ~200.
> 
> - This kernel includes the patch to sort the PCI devices breadth-first. 
>   This might cause strange things to happen (particular devices get assigned
>   to different /dev nodes, for example).  If this is suspected, please try
>   reverting gregkh-pci-pci-sort-device-lists-breadth-first.patch then send a
>   report.
> 
> 
> 
> 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 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 majordomo@vger.kernel.org
> 
> - 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.
> 
> - Semi-daily 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.18-rc6-mm1:
> 
> 
>  origin.patch
>  git-acpi.patch
>  git-alsa.patch
>  git-agpgart.patch
>  git-block.patch
>  git-cifs.patch
>  git-cpufreq.patch
>  git-drm.patch
>  git-dvb.patch
>  git-geode.patch
>  git-gfs2.patch
>  git-ia64.patch
>  git-ieee1394.patch
>  git-infiniband.patch
>  git-input.patch
>  git-intelfb.patch
>  git-kbuild.patch
>  git-libata-all.patch
>  git-lxdialog.patch
>  git-mtd.patch
>  git-netdev-all.patch
>  git-net.patch
>  git-nfs.patch
>  git-ocfs2.patch
>  git-parisc.patch
>  git-pcmcia.patch
>  git-powerpc.patch
>  git-r8169.patch
>  git-s390.patch
>  git-scsi-misc.patch

Seems that the module unload bug in scsi.c (details below) is still
there...  I'll follow up with the work around patch I am using.

-apw

Seems that -mm fails to compile when CONFIG_MODULES is set but
CONFIG_MODULE_UNLOAD is not.

   LD      .tmp_vmlinux1
  drivers/built-in.o(.text+0x47724): In function `scsi_device_put':
  drivers/scsi/scsi.c:887: undefined reference to `module_refcount'

Config fragment:
  CONFIG_MODULES=y
  # CONFIG_MODULE_UNLOAD is not set
  # CONFIG_MODULE_SRCVERSION_ALL is not set

This seems to be caused by changes in the scsi-misc git tree, from the
changes in the two commits below:

  [SCSI] sd: fix cache flushing on module removal
				(and individual device removal)
  [SCSI] fix up non-modular SCSI

  85b6c720b0931101c8bcc3a5abdc2b8514b0fb4b
  f479ab87936563a286b8aa0e39003c40fa31c6da

It looks very much like module_refcount is really not meant to be an
external interface, cirtainly its not available in all module
'load/unload modes'.

[PATCH] BODGE scsi misc module reference count checks with no MODULE_UNLOAD

[Andy Whitcroft]

BODGE scsi misc module reference count checks with no MODULE_UNLOAD

A quick bodge to try and get this to compile for testing.

Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 20d2cdf..2acc0cb 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -884,7 +884,11 @@ void scsi_device_put(struct scsi_device 
 
 	/* The module refcount will be zero if scsi_device_get()
 	 * was called from a module removal routine */
-	if (module && module_refcount(module) != 0)
+	if (module
+#ifdef CONFIG_MODULE_UNLOAD
+			&& module_refcount(module) != 0
+#endif
+			)
 		module_put(module);
 	put_device(&sdev->sdev_gendev);
 }

Re: [PATCH] BODGE scsi misc module reference count checks with no MODULE_UNLOAD

[Helge Hafting]

Andy Whitcroft wrote:
> BODGE scsi misc module reference count checks with no MODULE_UNLOAD
>
> A quick bodge to try and get this to compile for testing.
>
> Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Thanks, this was necessary to compile a non-modular kernel.

Helge Hafting

Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

Hi,

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> 


This patch removes delated files from headers_install target.

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Signed-off-by: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>

diff -uprN -X linux-mm/Documentation/dontdiff linux-mm-clean/include/linux/Kbuild linux-mm/include/linux/Kbuild
--- linux-mm-clean/include/linux/Kbuild	2006-09-12 11:19:46.000000000 +0200
+++ linux-mm/include/linux/Kbuild	2006-09-12 11:16:14.000000000 +0200
@@ -2,7 +2,7 @@ header-y := byteorder/ dvb/ hdlc/ isdn/
 	netfilter/ netfilter_arp/ netfilter_bridge/ netfilter_ipv4/	\
 	netfilter_ipv6/

-header-y += affs_fs.h affs_hardblocks.h aio_abi.h a.out.h arcfb.h	\
+header-y += affs_hardblocks.h aio_abi.h a.out.h arcfb.h	\
 	atmapi.h atmbr2684.h atmclip.h atm_eni.h atm_he.h		\
 	atm_idt77105.h atmioc.h atmlec.h atmmpc.h atm_nicstar.h		\
 	atmppp.h atmsap.h atmsvc.h atm_zatm.h auto_fs4.h auxvec.h	\
@@ -12,7 +12,7 @@ header-y += affs_fs.h affs_hardblocks.h
 	dqblk_v2.h dqblk_xfs.h efs_fs_sb.h elf-fdpic.h elf.h elf-em.h	\
 	fadvise.h fd.h fdreg.h ftape-header-segment.h ftape-vendors.h	\
 	fuse.h futex.h genetlink.h gen_stats.h gigaset_dev.h hdsmart.h	\
-	hpfs_fs.h hysdn_if.h i2c-dev.h i8k.h icmp.h			\
+	hysdn_if.h i2c-dev.h i8k.h icmp.h			\
 	if_arcnet.h if_arp.h if_bonding.h if_cablemodem.h if_fc.h	\
 	if_fddi.h if.h if_hippi.h if_infiniband.h if_packet.h		\
 	if_plip.h if_ppp.h if_slip.h if_strip.h if_tunnel.h in6.h	\
@@ -21,7 +21,7 @@ header-y += affs_fs.h affs_hardblocks.h
 	jffs2.h keyctl.h limits.h lock_dlm_plock.h major.h matroxfb.h	\
 	meye.h minix_fs.h mmtimer.h mqueue.h mtio.h ncp_no.h		\
 	netfilter_arp.h netrom.h nfs2.h nfs4_mount.h nfs_mount.h	\
-	openprom_fs.h param.h pci_ids.h pci_regs.h personality.h	\
+	param.h pci_ids.h pci_regs.h personality.h	\
 	pfkeyv2.h pg.h pkt_cls.h pkt_sched.h posix_types.h ppdev.h	\
 	prctl.h ps2esdi.h qic117.h qnxtypes.h quotaio_v1.h quotaio_v2.h	\
 	radeonfb.h raw.h resource.h rose.h sctp.h smbno.h snmp.h	\

Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
>

I get this while umounting jfs (umount segfaulted).

BUG: unable to handle kernel paging request at virtual address 6b6b6c4f
 printing eip:
c013a612
*pde = 00000000
Oops: 0002 [#1]
4K_STACKS PREEMPT SMP
last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
Modules linked in: jfs nls_base xfs reiser4 reiserfs ext2 loop ipv6
w83627hf hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios_ns
ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter
ip_tables x_tables cpufreq_userspace p4_clockmod speedstep_lib
binfmt_misc thermal processor fan container evdev snd_intel8x0
snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss
snd_pcm sk98lin snd_timer skge snd soundcore snd_page_alloc intel_agp
agpgart ide_cd i2c_i801 iTCO_wdt cdrom rtc unix
CPU:    1
EIP:    0060:[<c013a612>]    Not tainted VLI
EFLAGS: 00010046   (2.6.18-rc6-mm2 #120)
EIP is at __lock_acquire+0x35e/0xae8
eax: 00000000   ebx: 6b6b6b6b   ecx: c036b3d8   edx: 00000000
esi: 00000002   edi: f1620030   ebp: f158be7c   esp: f158be48
ds: 007b   es: 007b   ss: 0068
Process umount (pid: 19719, ti=f158b000 task=f1620030 task.ti=f158b000)
Stack: 000007bf 00000000 00000000 f173fd4c f1620030 f2543874 00000002 00000000
       00000078 c02f980b f16205b8 00000002 f1620030 f158beb0 c013ae74 00000000
       00000002 00000000 fdcfc85b c02f7e43 00000003 f1620590 00000004 f1620608
Call Trace:
 [<c013ae74>] lock_release_non_nested+0xd8/0x143
 [<c013b291>] lock_release+0x178/0x19f
 [<c02f7dc5>] __mutex_unlock_slowpath+0xbb/0x131
 [<c02f7e43>] mutex_unlock+0x8/0xa
 [<c017655f>] generic_shutdown_super+0x9c/0xd9
 [<c01765bc>] kill_block_super+0x20/0x32
 [<c017667c>] deactivate_super+0x5d/0x6f
 [<c01892bc>] mntput_no_expire+0x52/0x85
 [<c017b2c9>] path_release_on_umount+0x15/0x18
 [<c018a469>] sys_umount+0x1e1/0x215
 [<c018a4aa>] sys_oldumount+0xd/0xf
 [<c0103156>] sysenter_past_esp+0x5f/0x99
DWARF2 unwinder stuck at sysenter_past_esp+0x5f/0x99

Leftover inexact backtrace:

 =======================
Code: 68 0b e6 2f c0 68 e7 04 00 00 68 e9 f4 31 c0 68 f4 84 31 c0 e8
7f 7b fe ff e8 3d a4 fc ff 83 c4 10 eb 08 85 db 0f 84 6d 07 00 00 <f0>
ff 83 e4 00 00 00 8b 55 dc 8b 92 5c 05 00 00 89 55 e4 83 fa
EIP: [<c013a612>] __lock_acquire+0x35e/0xae8 SS:ESP 0068:f158be48
 <3>BUG: sleeping function called from invalid context at
/usr/src/linux-mm/mm/slab.c:2985
in_atomic():0, irqs_disabled():1
 [<c01041ba>] dump_trace+0x63/0x1ca
 [<c0104333>] show_trace_log_lvl+0x12/0x25
 [<c0104993>] show_trace+0xd/0x10
 [<c0104a58>] dump_stack+0x16/0x18
 [<c011a8b7>] __might_sleep+0x8d/0x95
 [<c01709f7>] kmem_cache_zalloc+0x28/0xe3
 [<c0152dae>] taskstats_exit_alloc+0x2e/0x6c
 [<c01246e4>] do_exit+0x1b6/0x9fe
 [<c01048a3>] die+0x2ae/0x2d4
 [<c0118b0c>] do_page_fault+0x4a4/0x584
 [<c02f9b4f>] error_code+0x3f/0x44
DWARF2 unwinder stuck at error_code+0x3f/0x44
Leftover inexact backtrace:

 [<c013ae74>] lock_release_non_nested+0xd8/0x143
 [<c013b291>] lock_release+0x178/0x19f
 [<c02f7dc5>] __mutex_unlock_slowpath+0xbb/0x131
 [<c02f7e43>] mutex_unlock+0x8/0xa
 [<c017655f>] generic_shutdown_super+0x9c/0xd9
 [<c01765bc>] kill_block_super+0x20/0x32
 [<c017667c>] deactivate_super+0x5d/0x6f
 [<c01892bc>] mntput_no_expire+0x52/0x85
 [<c017b2c9>] path_release_on_umount+0x15/0x18
 [<c018a469>] sys_umount+0x1e1/0x215
 [<c018a4aa>] sys_oldumount+0xd/0xf
 [<c0103156>] sysenter_past_esp+0x5f/0x99
 =======================

http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-config1
http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-dmesg1

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 12/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> >
>
> I get this while umounting jfs (umount segfaulted).

s/jfs/xfs

/home/michal/bin/test_mount_fs.sh: line 22:  2354 Segmentation fault
sudo umount /mnt/fs-farm/xfs/

>
> BUG: unable to handle kernel paging request at virtual address 6b6b6c4f
>  printing eip:
> c013a612
> *pde = 00000000
> Oops: 0002 [#1]
> 4K_STACKS PREEMPT SMP
> last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
> Modules linked in: jfs nls_base xfs reiser4 reiserfs ext2 loop ipv6
> w83627hf hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios_ns
> ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter
> ip_tables x_tables cpufreq_userspace p4_clockmod speedstep_lib
> binfmt_misc thermal processor fan container evdev snd_intel8x0
> snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss
> snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss
> snd_pcm sk98lin snd_timer skge snd soundcore snd_page_alloc intel_agp
> agpgart ide_cd i2c_i801 iTCO_wdt cdrom rtc unix
> CPU:    1
> EIP:    0060:[<c013a612>]    Not tainted VLI
> EFLAGS: 00010046   (2.6.18-rc6-mm2 #120)
> EIP is at __lock_acquire+0x35e/0xae8
> eax: 00000000   ebx: 6b6b6b6b   ecx: c036b3d8   edx: 00000000
> esi: 00000002   edi: f1620030   ebp: f158be7c   esp: f158be48
> ds: 007b   es: 007b   ss: 0068
> Process umount (pid: 19719, ti=f158b000 task=f1620030 task.ti=f158b000)
> Stack: 000007bf 00000000 00000000 f173fd4c f1620030 f2543874 00000002 00000000
>        00000078 c02f980b f16205b8 00000002 f1620030 f158beb0 c013ae74 00000000
>        00000002 00000000 fdcfc85b c02f7e43 00000003 f1620590 00000004 f1620608
> Call Trace:
>  [<c013ae74>] lock_release_non_nested+0xd8/0x143
>  [<c013b291>] lock_release+0x178/0x19f
>  [<c02f7dc5>] __mutex_unlock_slowpath+0xbb/0x131
>  [<c02f7e43>] mutex_unlock+0x8/0xa
>  [<c017655f>] generic_shutdown_super+0x9c/0xd9
>  [<c01765bc>] kill_block_super+0x20/0x32
>  [<c017667c>] deactivate_super+0x5d/0x6f
>  [<c01892bc>] mntput_no_expire+0x52/0x85
>  [<c017b2c9>] path_release_on_umount+0x15/0x18
>  [<c018a469>] sys_umount+0x1e1/0x215
>  [<c018a4aa>] sys_oldumount+0xd/0xf
>  [<c0103156>] sysenter_past_esp+0x5f/0x99
> DWARF2 unwinder stuck at sysenter_past_esp+0x5f/0x99
>
> Leftover inexact backtrace:
>
>  =======================
> Code: 68 0b e6 2f c0 68 e7 04 00 00 68 e9 f4 31 c0 68 f4 84 31 c0 e8
> 7f 7b fe ff e8 3d a4 fc ff 83 c4 10 eb 08 85 db 0f 84 6d 07 00 00 <f0>
> ff 83 e4 00 00 00 8b 55 dc 8b 92 5c 05 00 00 89 55 e4 83 fa
> EIP: [<c013a612>] __lock_acquire+0x35e/0xae8 SS:ESP 0068:f158be48
>  <3>BUG: sleeping function called from invalid context at
> /usr/src/linux-mm/mm/slab.c:2985
> in_atomic():0, irqs_disabled():1
>  [<c01041ba>] dump_trace+0x63/0x1ca
>  [<c0104333>] show_trace_log_lvl+0x12/0x25
>  [<c0104993>] show_trace+0xd/0x10
>  [<c0104a58>] dump_stack+0x16/0x18
>  [<c011a8b7>] __might_sleep+0x8d/0x95
>  [<c01709f7>] kmem_cache_zalloc+0x28/0xe3
>  [<c0152dae>] taskstats_exit_alloc+0x2e/0x6c
>  [<c01246e4>] do_exit+0x1b6/0x9fe
>  [<c01048a3>] die+0x2ae/0x2d4
>  [<c0118b0c>] do_page_fault+0x4a4/0x584
>  [<c02f9b4f>] error_code+0x3f/0x44
> DWARF2 unwinder stuck at error_code+0x3f/0x44
> Leftover inexact backtrace:
>
>  [<c013ae74>] lock_release_non_nested+0xd8/0x143
>  [<c013b291>] lock_release+0x178/0x19f
>  [<c02f7dc5>] __mutex_unlock_slowpath+0xbb/0x131
>  [<c02f7e43>] mutex_unlock+0x8/0xa
>  [<c017655f>] generic_shutdown_super+0x9c/0xd9
>  [<c01765bc>] kill_block_super+0x20/0x32
>  [<c017667c>] deactivate_super+0x5d/0x6f
>  [<c01892bc>] mntput_no_expire+0x52/0x85
>  [<c017b2c9>] path_release_on_umount+0x15/0x18
>  [<c018a469>] sys_umount+0x1e1/0x215
>  [<c018a4aa>] sys_oldumount+0xd/0xf
>  [<c0103156>] sysenter_past_esp+0x5f/0x99
>  =======================
>
> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-config1
> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-dmesg1
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: 2.6.18-rc6-mm2

[Andrew Morton]

On Tue, 12 Sep 2006 17:42:10 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:

> On 12/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> > >
> >
> > I get this while umounting jfs (umount segfaulted).
> 
> s/jfs/xfs

Do you mean that both JFS and XFS exhibit this bug, or only XFS?

> /home/michal/bin/test_mount_fs.sh: line 22:  2354 Segmentation fault
> sudo umount /mnt/fs-farm/xfs/
> 

Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 13/09/06, Andrew Morton <akpm@osdl.org> wrote:
> On Tue, 12 Sep 2006 17:42:10 +0200
> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
> > On 12/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> > > >
> > >
> > > I get this while umounting jfs (umount segfaulted).
> >
> > s/jfs/xfs
>
> Do you mean that both JFS and XFS exhibit this bug, or only XFS?

Only XFS. (s/jfs/xfs - "Thinking in s/c++/sed :)")

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: 2.6.18-rc6-mm2

[Andrew Morton]

On Wed, 13 Sep 2006 01:34:34 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:

> On 13/09/06, Andrew Morton <akpm@osdl.org> wrote:
> > On Tue, 12 Sep 2006 17:42:10 +0200
> > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> >
> > > On 12/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > > On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
> > > > >
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> > > > >
> > > >
> > > > I get this while umounting jfs (umount segfaulted).
> > >
> > > s/jfs/xfs
> >
> > Do you mean that both JFS and XFS exhibit this bug, or only XFS?
> 
> Only XFS. (s/jfs/xfs - "Thinking in s/c++/sed :)")
> 

OK, thanks.  Let us rub the xfs-masters lamp and see what emerges.

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[David Chinner]

On Tue, Sep 12, 2006 at 04:37:49PM -0700, Andrew Morton wrote:
> On Wed, 13 Sep 2006 01:34:34 +0200
> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> 
> > On 13/09/06, Andrew Morton <akpm@osdl.org> wrote:
> > > On Tue, 12 Sep 2006 17:42:10 +0200
> > > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> > >
> > > > On 12/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > > > On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
> > > > > >
> > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> > > > > >
> > > > >
> > > > > I get this while umounting jfs (umount segfaulted).
> > > >
> > > > s/jfs/xfs
> > >
> > > Do you mean that both JFS and XFS exhibit this bug, or only XFS?
> > 
> > Only XFS. (s/jfs/xfs - "Thinking in s/c++/sed :)")
> 
> OK, thanks.  Let us rub the xfs-masters lamp and see what emerges.

Just for XFs list folks:


http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-config1
http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-dmesg1

Call Trace:
[<c013ae74>] lock_release_non_nested+0xd8/0x143
[<c013b291>] lock_release+0x178/0x19f
[<c02f7dc5>] __mutex_unlock_slowpath+0xbb/0x131
[<c02f7e43>] mutex_unlock+0x8/0xa
[<c017655f>] generic_shutdown_super+0x9c/0xd9
[<c01765bc>] kill_block_super+0x20/0x32
[<c017667c>] deactivate_super+0x5d/0x6f
[<c01892bc>] mntput_no_expire+0x52/0x85
[<c017b2c9>] path_release_on_umount+0x15/0x18
[<c018a469>] sys_umount+0x1e1/0x215
[<c018a4aa>] sys_oldumount+0xd/0xf
[<c0103156>] sysenter_past_esp+0x5f/0x99

I'm not sure why XFS would cause this - the crash is outside XFS releasing
a mutex (sb->s_lock) that XFS code has never touched. I doubt anyone
in the XFS team has done any testing on this -mm kernel...

What is the test case, Michal? Can you post the script you used?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[David Chinner]

On Wed, Sep 13, 2006 at 11:58:50AM +1000, David Chinner wrote:
> Call Trace:
> [<c013ae74>] lock_release_non_nested+0xd8/0x143
> [<c013b291>] lock_release+0x178/0x19f
> [<c02f7dc5>] __mutex_unlock_slowpath+0xbb/0x131
> [<c02f7e43>] mutex_unlock+0x8/0xa
> [<c017655f>] generic_shutdown_super+0x9c/0xd9
> [<c01765bc>] kill_block_super+0x20/0x32
> [<c017667c>] deactivate_super+0x5d/0x6f
> [<c01892bc>] mntput_no_expire+0x52/0x85
> [<c017b2c9>] path_release_on_umount+0x15/0x18
> [<c018a469>] sys_umount+0x1e1/0x215
> [<c018a4aa>] sys_oldumount+0xd/0xf
> [<c0103156>] sysenter_past_esp+0x5f/0x99
> 
> I'm not sure why XFS would cause this - the crash is outside XFS releasing
> a mutex (sb->s_lock) that XFS code has never touched. I doubt anyone
> in the XFS team has done any testing on this -mm kernel...
> 
> What is the test case, Michal? Can you post the script you used?

I've booted 2.6.18-rc6-mm2 and mounted and unmounted several xfs
filesystems. I'm currently running xfsqa on it, and I haven't seen
any failures on unmount yet.

That test case would be really handy, Michal.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 13/09/06, David Chinner <dgc@sgi.com> wrote:
> On Wed, Sep 13, 2006 at 11:58:50AM +1000, David Chinner wrote:
> > Call Trace:
> > [<c013ae74>] lock_release_non_nested+0xd8/0x143
> > [<c013b291>] lock_release+0x178/0x19f
> > [<c02f7dc5>] __mutex_unlock_slowpath+0xbb/0x131
> > [<c02f7e43>] mutex_unlock+0x8/0xa
> > [<c017655f>] generic_shutdown_super+0x9c/0xd9
> > [<c01765bc>] kill_block_super+0x20/0x32
> > [<c017667c>] deactivate_super+0x5d/0x6f
> > [<c01892bc>] mntput_no_expire+0x52/0x85
> > [<c017b2c9>] path_release_on_umount+0x15/0x18
> > [<c018a469>] sys_umount+0x1e1/0x215
> > [<c018a4aa>] sys_oldumount+0xd/0xf
> > [<c0103156>] sysenter_past_esp+0x5f/0x99
> >
> > I'm not sure why XFS would cause this - the crash is outside XFS releasing
> > a mutex (sb->s_lock) that XFS code has never touched. I doubt anyone
> > in the XFS team has done any testing on this -mm kernel...
> >
> > What is the test case, Michal? Can you post the script you used?
>
> I've booted 2.6.18-rc6-mm2 and mounted and unmounted several xfs
> filesystems. I'm currently running xfsqa on it, and I haven't seen
> any failures on unmount yet.
>
> That test case would be really handy, Michal.

http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/test_mount_fs.sh

ls -hs /home/fs-farm/
total 3.6G
513M ext2.img  513M ext4.img  513M reiser3.img  513M xfs.img
513M ext3.img  513M jfs.img   513M reiser4.img

>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> Principal Engineer
> SGI Australian Software Group
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[David Chinner]

On Wed, Sep 13, 2006 at 11:43:32AM +0200, Michal Piotrowski wrote:
> On 13/09/06, David Chinner <dgc@sgi.com> wrote:
> >
> >I've booted 2.6.18-rc6-mm2 and mounted and unmounted several xfs
> >filesystems. I'm currently running xfsqa on it, and I haven't seen
> >any failures on unmount yet.
> >
> >That test case would be really handy, Michal.
> 
> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/test_mount_fs.sh
> 
> ls -hs /home/fs-farm/
> total 3.6G
> 513M ext2.img  513M ext4.img  513M reiser3.img  513M xfs.img
> 513M ext3.img  513M jfs.img   513M reiser4.img

Ok, so you're using loopback and mounting one of each filesystem, then
unmounting them in the same order. I have mounted and unmounted an
XFS filesystem in isolation in exactly the same way you have been, but
I haven't seen any failures.

Can you rerun the test with just XFS in your script and see if you
see any failures? If you don't see any failures, can you add each
filesystem back in one at a time until you see failures again?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

David Chinner wrote:
> On Wed, Sep 13, 2006 at 11:43:32AM +0200, Michal Piotrowski wrote:
>> On 13/09/06, David Chinner <dgc@sgi.com> wrote:
>>> I've booted 2.6.18-rc6-mm2 and mounted and unmounted several xfs
>>> filesystems. I'm currently running xfsqa on it, and I haven't seen
>>> any failures on unmount yet.
>>>
>>> That test case would be really handy, Michal.
>> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/test_mount_fs.sh
>>
>> ls -hs /home/fs-farm/
>> total 3.6G
>> 513M ext2.img  513M ext4.img  513M reiser3.img  513M xfs.img
>> 513M ext3.img  513M jfs.img   513M reiser4.img
> 
> Ok, so you're using loopback and mounting one of each filesystem, then
> unmounting them in the same order. I have mounted and unmounted an
> XFS filesystem in isolation in exactly the same way you have been, but
> I haven't seen any failures.
> 
> Can you rerun the test with just XFS in your script and see if you
> see any failures? If you don't see any failures, can you add each
> filesystem back in one at a time until you see failures again?


I still get an oops (with xfs only). Maybe it's file system image problem.

xfs_info /mnt/fs-farm/xfs/
meta-data=/dev/loop1             isize=256    agcount=8, agsize=16384 blks
         =                       sectsz=512
data     =                       bsize=4096   blocks=131072, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=1200, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0

> 
> Cheers,
> 
> Dave.

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 14/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> David Chinner wrote:
> > On Wed, Sep 13, 2006 at 11:43:32AM +0200, Michal Piotrowski wrote:
> >> On 13/09/06, David Chinner <dgc@sgi.com> wrote:
> >>> I've booted 2.6.18-rc6-mm2 and mounted and unmounted several xfs
> >>> filesystems. I'm currently running xfsqa on it, and I haven't seen
> >>> any failures on unmount yet.
> >>>
> >>> That test case would be really handy, Michal.
> >> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/test_mount_fs.sh
> >>
> >> ls -hs /home/fs-farm/
> >> total 3.6G
> >> 513M ext2.img  513M ext4.img  513M reiser3.img  513M xfs.img
> >> 513M ext3.img  513M jfs.img   513M reiser4.img
> >
> > Ok, so you're using loopback and mounting one of each filesystem, then
> > unmounting them in the same order. I have mounted and unmounted an
> > XFS filesystem in isolation in exactly the same way you have been, but
> > I haven't seen any failures.
> >
> > Can you rerun the test with just XFS in your script and see if you
> > see any failures? If you don't see any failures, can you add each
> > filesystem back in one at a time until you see failures again?
>
>
> I still get an oops (with xfs only). Maybe it's file system image problem.
>
> xfs_info /mnt/fs-farm/xfs/
> meta-data=/dev/loop1             isize=256    agcount=8, agsize=16384 blks
>          =                       sectsz=512
> data     =                       bsize=4096   blocks=131072, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=1
> naming   =version 2              bsize=4096
> log      =internal               bsize=4096   blocks=1200, version=1
>          =                       sectsz=512   sunit=0 blks
> realtime =none                   extsz=65536  blocks=0, rtextents=0

Can I send to you this fs image? It's only 246KB bz2 file.

>
> >
> > Cheers,
> >
> > Dave.

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 14/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> Can I send to you this fs image? It's only 246KB bz2 file.

I have uploaded this on my http.
http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/xfs.img.bz2

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[David Chinner]

On Thu, Sep 14, 2006 at 10:50:42AM +0200, Michal Piotrowski wrote:
> On 14/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> >David Chinner wrote:
> >> On Wed, Sep 13, 2006 at 11:43:32AM +0200, Michal Piotrowski wrote:
> >>> On 13/09/06, David Chinner <dgc@sgi.com> wrote:
> >>>> I've booted 2.6.18-rc6-mm2 and mounted and unmounted several xfs
> >>>> filesystems. I'm currently running xfsqa on it, and I haven't seen
> >>>> any failures on unmount yet.
> >>>>
> >>>> That test case would be really handy, Michal.
> >>> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/test_mount_fs.sh
> >>>
> >>> ls -hs /home/fs-farm/
> >>> total 3.6G
> >>> 513M ext2.img  513M ext4.img  513M reiser3.img  513M xfs.img
> >>> 513M ext3.img  513M jfs.img   513M reiser4.img
> >>
> >> Ok, so you're using loopback and mounting one of each filesystem, then
> >> unmounting them in the same order. I have mounted and unmounted an
> >> XFS filesystem in isolation in exactly the same way you have been, but
> >> I haven't seen any failures.
> >>
> >> Can you rerun the test with just XFS in your script and see if you
> >> see any failures? If you don't see any failures, can you add each
> >> filesystem back in one at a time until you see failures again?
> >
> >
> >I still get an oops (with xfs only). Maybe it's file system image problem.
> >
> >xfs_info /mnt/fs-farm/xfs/
> >meta-data=/dev/loop1             isize=256    agcount=8, agsize=16384 blks
> >         =                       sectsz=512
> >data     =                       bsize=4096   blocks=131072, imaxpct=25
> >         =                       sunit=0      swidth=0 blks, unwritten=1
> >naming   =version 2              bsize=4096
> >log      =internal               bsize=4096   blocks=1200, version=1
> >         =                       sectsz=512   sunit=0 blks
> >realtime =none                   extsz=65536  blocks=0, rtextents=0
> 
> Can I send to you this fs image? It's only 246KB bz2 file.

I've downloaded it, and I don't see a panic on that fs at all.
I've got it sitting in a tight loop mounting and unmounting the
image you sent me, and nothing has gone wrong. I don't think it's
a corrupted filesystem problem - it seems more like a memory corruption
problem to me.

What arch are you running on and what compiler are you using?
Can you try 2.6.18-rc6 and see if it panics like this on your
machine? there is little difference in xfs between -rc6 and -rc6-mm2
so it would be good to know if this is a problem isolated to
the -mm tree or not....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 14/09/06, David Chinner <dgc@sgi.com> wrote:
> On Thu, Sep 14, 2006 at 10:50:42AM +0200, Michal Piotrowski wrote:
> > On 14/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > >David Chinner wrote:
> > >> On Wed, Sep 13, 2006 at 11:43:32AM +0200, Michal Piotrowski wrote:
> > >>> On 13/09/06, David Chinner <dgc@sgi.com> wrote:
> > >>>> I've booted 2.6.18-rc6-mm2 and mounted and unmounted several xfs
> > >>>> filesystems. I'm currently running xfsqa on it, and I haven't seen
> > >>>> any failures on unmount yet.
> > >>>>
> > >>>> That test case would be really handy, Michal.
> > >>> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/test_mount_fs.sh
> > >>>
> > >>> ls -hs /home/fs-farm/
> > >>> total 3.6G
> > >>> 513M ext2.img  513M ext4.img  513M reiser3.img  513M xfs.img
> > >>> 513M ext3.img  513M jfs.img   513M reiser4.img
> > >>
> > >> Ok, so you're using loopback and mounting one of each filesystem, then
> > >> unmounting them in the same order. I have mounted and unmounted an
> > >> XFS filesystem in isolation in exactly the same way you have been, but
> > >> I haven't seen any failures.
> > >>
> > >> Can you rerun the test with just XFS in your script and see if you
> > >> see any failures? If you don't see any failures, can you add each
> > >> filesystem back in one at a time until you see failures again?
> > >
> > >
> > >I still get an oops (with xfs only). Maybe it's file system image problem.
> > >
> > >xfs_info /mnt/fs-farm/xfs/
> > >meta-data=/dev/loop1             isize=256    agcount=8, agsize=16384 blks
> > >         =                       sectsz=512
> > >data     =                       bsize=4096   blocks=131072, imaxpct=25
> > >         =                       sunit=0      swidth=0 blks, unwritten=1
> > >naming   =version 2              bsize=4096
> > >log      =internal               bsize=4096   blocks=1200, version=1
> > >         =                       sectsz=512   sunit=0 blks
> > >realtime =none                   extsz=65536  blocks=0, rtextents=0
> >
> > Can I send to you this fs image? It's only 246KB bz2 file.
>
> I've downloaded it, and I don't see a panic on that fs at all.
> I've got it sitting in a tight loop mounting and unmounting the
> image you sent me, and nothing has gone wrong. I don't think it's
> a corrupted filesystem problem - it seems more like a memory corruption
> problem to me.

I'm checking memory from time to time with memtest86.

>
> What arch are you running on and what compiler are you using?

gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)

I'll build system with gcc 3.4

> Can you try 2.6.18-rc6 and see if it panics like this on your
> machine?

2.6.18-rc7 works fine.

> there is little difference in xfs between -rc6 and -rc6-mm2
> so it would be good to know if this is a problem isolated to
> the -mm tree or not....
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> Principal Engineer
> SGI Australian Software Group
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 14/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> On 14/09/06, David Chinner <dgc@sgi.com> wrote:
> >
> > What arch are you running on and what compiler are you using?
>
> gcc -v
> Using built-in specs.
> Target: i386-redhat-linux
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --enable-checking=release --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-libgcj-multifile
> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada
> --enable-java-awt=gtk --disable-dssi
> --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
> --with-cpu=generic --host=i386-redhat-linux
> Thread model: posix
> gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)
>
> I'll build system with gcc 3.4

It's not a compiler issue.

Binary search should solve this mystery.

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 14/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> On 14/09/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > On 14/09/06, David Chinner <dgc@sgi.com> wrote:
> > >
> > > What arch are you running on and what compiler are you using?
> >
> > gcc -v
> > Using built-in specs.
> > Target: i386-redhat-linux
> > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> > --infodir=/usr/share/info --enable-shared --enable-threads=posix
> > --enable-checking=release --with-system-zlib --enable-__cxa_atexit
> > --disable-libunwind-exceptions --enable-libgcj-multifile
> > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada
> > --enable-java-awt=gtk --disable-dssi
> > --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
> > --with-cpu=generic --host=i386-redhat-linux
> > Thread model: posix
> > gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)
> >
> > I'll build system with gcc 3.4
>
> It's not a compiler issue.
>
> Binary search should solve this mystery.

I was wrong - it's in vanilla tree
(http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-dmesg1).

cat hunt | head -n 3
origin.patch
BAD
libata-ignore-cfa-signature-while-sanity-checking-an-atapi-device.patch

I can reproduce this bug with all CONFIG_DEBUG_*=y.
(only
CONFIG_DEBUG_SYNCHRO_TEST=m
CONFIG_RCU_TORTURE_TEST=m
as modules)

I have checked memory
http://www.stardust.webpages.pl/files/crap/memtest.jpg and everything
seems to be fine.

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[David Chinner]

On Thu, Sep 14, 2006 at 07:01:38PM +0200, Michal Piotrowski wrote:
> >>
> >> I'll build system with gcc 3.4
> >
> >It's not a compiler issue.
> >
> >Binary search should solve this mystery.
> 
> I was wrong - it's in vanilla tree
> (http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-dmesg1).
> 
> cat hunt | head -n 3
> origin.patch
> BAD
> libata-ignore-cfa-signature-while-sanity-checking-an-atapi-device.patch

Not sure what this means....

> I can reproduce this bug with all CONFIG_DEBUG_*=y.
> (only
> CONFIG_DEBUG_SYNCHRO_TEST=m
> CONFIG_RCU_TORTURE_TEST=m
> as modules)

I notice you're running i386 with 4k stacks - I wonder if you're blowing the
stack by running xfs on loopback. I've been testing on x86_64 and ia64
which don't have those issues. Can you try with 8K stacks instead of
4k stacks?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[Andrew Morton]

On Fri, 15 Sep 2006 12:57:45 +1000
David Chinner <dgc@sgi.com> wrote:

> On Thu, Sep 14, 2006 at 07:01:38PM +0200, Michal Piotrowski wrote:
> > >>
> > >> I'll build system with gcc 3.4
> > >
> > >It's not a compiler issue.
> > >
> > >Binary search should solve this mystery.
> > 
> > I was wrong - it's in vanilla tree
> > (http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-dmesg1).
> > 
> > cat hunt | head -n 3
> > origin.patch
> > BAD
> > libata-ignore-cfa-signature-while-sanity-checking-an-atapi-device.patch
> 
> Not sure what this means....

"BAD" is a bisection point, as per
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt.  So
just 2.6.18-rc6+origin.patch exhibits the failure.  That is mainline.

> > I can reproduce this bug with all CONFIG_DEBUG_*=y.
> > (only
> > CONFIG_DEBUG_SYNCHRO_TEST=m
> > CONFIG_RCU_TORTURE_TEST=m
> > as modules)
> 
> I notice you're running i386 with 4k stacks - I wonder if you're blowing the
> stack by running xfs on loopback. I've been testing on x86_64 and ia64
> which don't have those issues. Can you try with 8K stacks instead of
> 4k stacks?

hm, that wouldn't be good.

Enabling CONFIG_DEBUG_STACK_USAGE will make the fourth column in the
sysrq-T output display the minimum-ever free stack space for each task.

sleep         S ffff810100f0bea8     0 18893  22372                     (NOTLB)

                                     ^ this number.

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[David Chinner]

On Thu, Sep 14, 2006 at 08:48:01PM -0700, Andrew Morton wrote:
> On Fri, 15 Sep 2006 12:57:45 +1000
> David Chinner <dgc@sgi.com> wrote:
> 
> > On Thu, Sep 14, 2006 at 07:01:38PM +0200, Michal Piotrowski wrote:
> > > >>
> > > >> I'll build system with gcc 3.4
> > > >
> > > >It's not a compiler issue.
> > > >
> > > >Binary search should solve this mystery.
> > > 
> > > I was wrong - it's in vanilla tree
> > > (http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-dmesg1).
> > > 
> > > cat hunt | head -n 3
> > > origin.patch
> > > BAD
> > > libata-ignore-cfa-signature-while-sanity-checking-an-atapi-device.patch
> > 
> > Not sure what this means....
> 
> "BAD" is a bisection point, as per
> http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt.  So
> just 2.6.18-rc6+origin.patch exhibits the failure.  That is mainline.

Ah - thanks for explaining that for me, Andrew.

Michal, there were several XFS fixes (4, I think) that went into -rc7.  If
-rc6 fails and -rc7 doesn't then we need to check if one of those fixes is
responsible. The crash doesn't match any of the symptoms we've seen from them,
but it's worth checking.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 15/09/06, David Chinner <dgc@sgi.com> wrote:
> On Thu, Sep 14, 2006 at 08:48:01PM -0700, Andrew Morton wrote:
> > "BAD" is a bisection point, as per
> > http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt.  So
> > just 2.6.18-rc6+origin.patch exhibits the failure.  That is mainline.
>
> Ah - thanks for explaining that for me, Andrew.
>
> Michal, there were several XFS fixes (4, I think) that went into -rc7.  If
> -rc6 fails and -rc7 doesn't then we need to check if one of those fixes is
> responsible.

As I said before "I was wrong" (I use lockdep only with -mm kernels).

> The crash doesn't match any of the symptoms we've seen from them,
> but it's worth checking.

http://www.ussg.iu.edu/hypermail/linux/kernel/0608.1/1202.html

The problem with this bug is "bad interaction" between lockdep and
XFS. (I forgot about this probably because lockdep was broken for me
in 2.6.18-rc5-mm* - and previous bug appeared while mounting XFS, not
umounting).

2006-07-03 locdep was merged
2006-07-28 - 2006-08-10 a few XFS fixes

So I guess that binary search won't solve this mystery.

>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> Principal Engineer
> SGI Australian Software Group
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: [xfs-masters] Re: 2.6.18-rc6-mm2

[David Chinner]

On Fri, Sep 15, 2006 at 10:06:48AM +0200, Michal Piotrowski wrote:
> On 15/09/06, David Chinner <dgc@sgi.com> wrote:
> >On Thu, Sep 14, 2006 at 08:48:01PM -0700, Andrew Morton wrote:
> >> "BAD" is a bisection point, as per
> >> http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt.  
> >So
> >> just 2.6.18-rc6+origin.patch exhibits the failure.  That is mainline.
> >
> >Ah - thanks for explaining that for me, Andrew.
> >
> >Michal, there were several XFS fixes (4, I think) that went into -rc7.  If
> >-rc6 fails and -rc7 doesn't then we need to check if one of those fixes is
> >responsible.
> 
> As I said before "I was wrong" (I use lockdep only with -mm kernels).
> 
> >The crash doesn't match any of the symptoms we've seen from them,
> >but it's worth checking.
> 
> http://www.ussg.iu.edu/hypermail/linux/kernel/0608.1/1202.html
> 
> The problem with this bug is "bad interaction" between lockdep and
> XFS. (I forgot about this probably because lockdep was broken for me
> in 2.6.18-rc5-mm* - and previous bug appeared while mounting XFS, not
> umounting).

According to the above link, unmount was the problem as well.

I know little about lockdep, but if this really is the superblock
lock that we are oopsing on then I cannot see how XFS is involved
at all seeing as it does not ever touch the superblock lock.

I'd say the first step is to get a lockdep expert to explain why
we are oopsing here....

> 2006-07-03 locdep was merged
> 2006-07-28 - 2006-08-10 a few XFS fixes
> 
> So I guess that binary search won't solve this mystery.

Don't use lockdep with XFS yet. XFS hasn't been instrumented
with lockdep notations, so nothing good will come from using
it right now. There is work in progress to fix this, but it's not
ready yet.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
>

My FC6T2 bug appeared in -mm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202223

Any ideas about this?

echo shutdown > /sys/power/disk; echo disk > /sys/power/state

CPU 1 is now offline
lockdep: not fixing up alternatives.

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.18-rc6-mm2 #120
-------------------------------------------------------
bash/1961 is trying to acquire lock:
 ((cpu_chain).rwsem){----}, at: [<c012e289>]
blocking_notifier_call_chain+0x11/0x2d

but task is already holding lock:
 (workqueue_mutex){--..}, at: [<c02f8156>] mutex_lock+0x1c/0x1f

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:
-> #1 (workqueue_mutex){--..}:
       [<c0138b97>] add_lock_to_list+0x5c/0x7a
       [<c013aca0>] __lock_acquire+0x9ec/0xae8
       [<c013b0fc>] lock_acquire+0x6b/0x88
       [<c02f7f1b>] __mutex_lock_slowpath+0xd6/0x2f5
       [<c02f8156>] mutex_lock+0x1c/0x1f
       [<c01312de>] workqueue_cpu_callback+0x109/0x1ff
       [<c012de43>] notifier_call_chain+0x20/0x31
       [<c012e295>] blocking_notifier_call_chain+0x1d/0x2d
       [<c013f867>] _cpu_down+0x48/0x207
       [<c013fbf8>] disable_nonboot_cpus+0x98/0x12c
       [<c01451d6>] prepare_processes+0xe/0x41
       [<c014539e>] pm_suspend_disk+0x9/0xe2
       [<c0144635>] enter_state+0x53/0x177
       [<c01447df>] state_store+0x86/0x9c
       [<c01abde4>] subsys_attr_store+0x20/0x25
       [<c01abee3>] sysfs_write_file+0xa6/0xcc
       [<c0174d60>] vfs_write+0xcd/0x174
       [<c01753fa>] sys_write+0x3b/0x71
       [<c0103156>] sysenter_past_esp+0x5f/0x99
       [<ffffffff>] 0xffffffff
-> #0 ((cpu_chain).rwsem){----}:
       [<c013a280>] print_circular_bug_tail+0x2e/0x62
       [<c013abd7>] __lock_acquire+0x923/0xae8
       [<c013b0fc>] lock_acquire+0x6b/0x88
       [<c0136e60>] down_read+0x28/0x3b
       [<c012e289>] blocking_notifier_call_chain+0x11/0x2d
       [<c013f98e>] _cpu_down+0x16f/0x207
       [<c013fbf8>] disable_nonboot_cpus+0x98/0x12c
       [<c01451d6>] prepare_processes+0xe/0x41
       [<c014539e>] pm_suspend_disk+0x9/0xe2
       [<c0144635>] enter_state+0x53/0x177
       [<c01447df>] state_store+0x86/0x9c
       [<c01abde4>] subsys_attr_store+0x20/0x25
       [<c01abee3>] sysfs_write_file+0xa6/0xcc
       [<c0174d60>] vfs_write+0xcd/0x174
       [<c01753fa>] sys_write+0x3b/0x71
       [<c0103156>] sysenter_past_esp+0x5f/0x99
       [<ffffffff>] 0xffffffff

other info that might help us debug this:

2 locks held by bash/1961:
 #0:  (cpu_add_remove_lock){--..}, at: [<c02f8156>] mutex_lock+0x1c/0x1f
 #1:  (workqueue_mutex){--..}, at: [<c02f8156>] mutex_lock+0x1c/0x1f

stack backtrace:
 [<c01041ba>] dump_trace+0x63/0x1ca
 [<c0104333>] show_trace_log_lvl+0x12/0x25
 [<c0104993>] show_trace+0xd/0x10
 [<c0104a58>] dump_stack+0x16/0x18
 [<c013a2a9>] print_circular_bug_tail+0x57/0x62
 [<c013abd7>] __lock_acquire+0x923/0xae8
 [<c013b0fc>] lock_acquire+0x6b/0x88
 [<c0136e60>] down_read+0x28/0x3b
 [<c012e289>] blocking_notifier_call_chain+0x11/0x2d
 [<c013f98e>] _cpu_down+0x16f/0x207
 [<c013fbf8>] disable_nonboot_cpus+0x98/0x12c
 [<c01451d6>] prepare_processes+0xe/0x41
 [<c014539e>] pm_suspend_disk+0x9/0xe2
 [<c0144635>] enter_state+0x53/0x177
 [<c01447df>] state_store+0x86/0x9c
 [<c01abde4>] subsys_attr_store+0x20/0x25
 [<c01abee3>] sysfs_write_file+0xa6/0xcc
 [<c0174d60>] vfs_write+0xcd/0x174
 [<c01753fa>] sys_write+0x3b/0x71
 [<c0103156>] sysenter_past_esp+0x5f/0x99
DWARF2 unwinder stuck at sysenter_past_esp+0x5f/0x99

Leftover inexact backtrace:

l *blocking_notifier_call_chain+0x11/0x2d
0xc012e278 is in blocking_notifier_call_chain
(/usr/src/linux-mm/kernel/sys.c:324).
319      *      of the last notifier function called.
320      */
321
322     int blocking_notifier_call_chain(struct blocking_notifier_head *nh,
323                     unsigned long val, void *v)
324     {
325             int ret;
326
327             down_read(&nh->rwsem);
328             ret = notifier_call_chain(&nh->head, val, v);

l *mutex_lock+0x1c/0x1f
0xc02f813a is in mutex_lock (/usr/src/linux-mm/kernel/mutex.c:85).
80       *   deadlock debugging. )
81       *
82       * This function is similar to (but not equivalent to) down().
83       */
84      void inline fastcall __sched mutex_lock(struct mutex *lock)
85      {
86              might_sleep();
87              /*
88               * The locking fastpath is the 1->0 transition from
89               * 'unlocked' into 'locked' state.

http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-dmesg2
http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-config1

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: 2.6.18-rc6-mm2

[Jiri Slaby]

Michal Piotrowski wrote:
> On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/ 
>>
>>
> 
> My FC6T2 bug appeared in -mm
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202223
> 
> Any ideas about this?

Hi,
this is known:
http://lkml.org/lkml/2006/9/8/56

> echo shutdown > /sys/power/disk; echo disk > /sys/power/state
> 
> CPU 1 is now offline
> lockdep: not fixing up alternatives.
> 
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.18-rc6-mm2 #120
> -------------------------------------------------------
> bash/1961 is trying to acquire lock:
> ((cpu_chain).rwsem){----}, at: [<c012e289>]
> blocking_notifier_call_chain+0x11/0x2d
> 
> but task is already holding lock:
> (workqueue_mutex){--..}, at: [<c02f8156>] mutex_lock+0x1c/0x1f
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> -> #1 (workqueue_mutex){--..}:
>       [<c0138b97>] add_lock_to_list+0x5c/0x7a
>       [<c013aca0>] __lock_acquire+0x9ec/0xae8
>       [<c013b0fc>] lock_acquire+0x6b/0x88
>       [<c02f7f1b>] __mutex_lock_slowpath+0xd6/0x2f5
>       [<c02f8156>] mutex_lock+0x1c/0x1f
>       [<c01312de>] workqueue_cpu_callback+0x109/0x1ff
>       [<c012de43>] notifier_call_chain+0x20/0x31
>       [<c012e295>] blocking_notifier_call_chain+0x1d/0x2d
>       [<c013f867>] _cpu_down+0x48/0x207
>       [<c013fbf8>] disable_nonboot_cpus+0x98/0x12c
>       [<c01451d6>] prepare_processes+0xe/0x41
>       [<c014539e>] pm_suspend_disk+0x9/0xe2
>       [<c0144635>] enter_state+0x53/0x177
>       [<c01447df>] state_store+0x86/0x9c
>       [<c01abde4>] subsys_attr_store+0x20/0x25
>       [<c01abee3>] sysfs_write_file+0xa6/0xcc
>       [<c0174d60>] vfs_write+0xcd/0x174
>       [<c01753fa>] sys_write+0x3b/0x71
>       [<c0103156>] sysenter_past_esp+0x5f/0x99
>       [<ffffffff>] 0xffffffff
> -> #0 ((cpu_chain).rwsem){----}:
>       [<c013a280>] print_circular_bug_tail+0x2e/0x62
>       [<c013abd7>] __lock_acquire+0x923/0xae8
>       [<c013b0fc>] lock_acquire+0x6b/0x88
>       [<c0136e60>] down_read+0x28/0x3b
>       [<c012e289>] blocking_notifier_call_chain+0x11/0x2d
>       [<c013f98e>] _cpu_down+0x16f/0x207
>       [<c013fbf8>] disable_nonboot_cpus+0x98/0x12c
>       [<c01451d6>] prepare_processes+0xe/0x41
>       [<c014539e>] pm_suspend_disk+0x9/0xe2
>       [<c0144635>] enter_state+0x53/0x177
>       [<c01447df>] state_store+0x86/0x9c
>       [<c01abde4>] subsys_attr_store+0x20/0x25
>       [<c01abee3>] sysfs_write_file+0xa6/0xcc
>       [<c0174d60>] vfs_write+0xcd/0x174
>       [<c01753fa>] sys_write+0x3b/0x71
>       [<c0103156>] sysenter_past_esp+0x5f/0x99
>       [<ffffffff>] 0xffffffff
> 
> other info that might help us debug this:
> 
> 2 locks held by bash/1961:
> #0:  (cpu_add_remove_lock){--..}, at: [<c02f8156>] mutex_lock+0x1c/0x1f
> #1:  (workqueue_mutex){--..}, at: [<c02f8156>] mutex_lock+0x1c/0x1f
> 
> stack backtrace:
> [<c01041ba>] dump_trace+0x63/0x1ca
> [<c0104333>] show_trace_log_lvl+0x12/0x25
> [<c0104993>] show_trace+0xd/0x10
> [<c0104a58>] dump_stack+0x16/0x18
> [<c013a2a9>] print_circular_bug_tail+0x57/0x62
> [<c013abd7>] __lock_acquire+0x923/0xae8
> [<c013b0fc>] lock_acquire+0x6b/0x88
> [<c0136e60>] down_read+0x28/0x3b
> [<c012e289>] blocking_notifier_call_chain+0x11/0x2d
> [<c013f98e>] _cpu_down+0x16f/0x207
> [<c013fbf8>] disable_nonboot_cpus+0x98/0x12c
> [<c01451d6>] prepare_processes+0xe/0x41
> [<c014539e>] pm_suspend_disk+0x9/0xe2
> [<c0144635>] enter_state+0x53/0x177
> [<c01447df>] state_store+0x86/0x9c
> [<c01abde4>] subsys_attr_store+0x20/0x25
> [<c01abee3>] sysfs_write_file+0xa6/0xcc
> [<c0174d60>] vfs_write+0xcd/0x174
> [<c01753fa>] sys_write+0x3b/0x71
> [<c0103156>] sysenter_past_esp+0x5f/0x99
> DWARF2 unwinder stuck at sysenter_past_esp+0x5f/0x99
> 
> Leftover inexact backtrace:
> 
> l *blocking_notifier_call_chain+0x11/0x2d
> 0xc012e278 is in blocking_notifier_call_chain
> (/usr/src/linux-mm/kernel/sys.c:324).
> 319      *      of the last notifier function called.
> 320      */
> 321
> 322     int blocking_notifier_call_chain(struct blocking_notifier_head *nh,
> 323                     unsigned long val, void *v)
> 324     {
> 325             int ret;
> 326
> 327             down_read(&nh->rwsem);
> 328             ret = notifier_call_chain(&nh->head, val, v);
> 
> l *mutex_lock+0x1c/0x1f
> 0xc02f813a is in mutex_lock (/usr/src/linux-mm/kernel/mutex.c:85).
> 80       *   deadlock debugging. )
> 81       *
> 82       * This function is similar to (but not equivalent to) down().
> 83       */
> 84      void inline fastcall __sched mutex_lock(struct mutex *lock)
> 85      {
> 86              might_sleep();
> 87              /*
> 88               * The locking fastpath is the 1->0 transition from
> 89               * 'unlocked' into 'locked' state.
> 
> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-dmesg2
> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-config1

regards,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: 2.6.18-rc6-mm2

[Jiri Slaby]

Jiri Slaby wrote:
> Michal Piotrowski wrote:
>> On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
>>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/ 
>>>
>>>
>>
>> My FC6T2 bug appeared in -mm
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202223
>>
>> Any ideas about this?
> 
> Hi,
> this is known:
> http://lkml.org/lkml/2006/9/8/56

Of course, you know it, there is a link to the redhat bugzilla in the root post 
of this...

regards,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

[-mm patch] arm build fail: vfpsingle.c

[Frederik Deweerdt]

On Tue, Sep 12, 2006 at 12:06:18AM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> 
Hi,

It looks like Zach Brown's patch pr_debug-check-pr_debug-arguments
worked as inteded. That is, it doesn't "allow completely incorrect code
to build." :).

The arm build fails with the following message:
  CC      arch/arm/vfp/vfpsingle.o
  arch/arm/vfp/vfpsingle.c: In function `__vfp_single_normaliseround':
  arch/arm/vfp/vfpsingle.c:201: error: `func' undeclared (first use in
  this function)
  arch/arm/vfp/vfpsingle.c:201: error: (Each undeclared identifier is
  reported only once
  arch/arm/vfp/vfpsingle.c:201: error: for each function it appears in.)
  make[1]: *** [arch/arm/vfp/vfpsingle.o] Error 1
  make: *** [arch/arm/vfp] Error 2

The following patch fixes the issue by using func only when DEBUG is
defined.

Regards,
Frederik


Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>

--- 2.6.18-rc6-mm2/arch/arm/vfp/vfpsingle.c~	2006-09-12 19:57:50 +0000
+++ 2.6.18-rc6-mm2/arch/arm/vfp/vfpsingle.c	2006-09-12 19:58:07 +0000
@@ -198,8 +198,10 @@ u32 vfp_single_normaliseround(int sd, st
 	vfp_single_dump("pack: final", vs);
 	{
 		s32 d = vfp_single_pack(vs);
+#ifdef DEBUG
 		pr_debug("VFP: %s: d(s%d)=%08x exceptions=%08x\n", func,
 			 sd, d, exceptions);
+#endif
 		vfp_put_float(d, sd);
 	}
 

Re: [-mm patch] arm build fail: vfpsingle.c

[Zach Brown]

Frederik Deweerdt wrote:
> On Tue, Sep 12, 2006 at 12:06:18AM -0700, Andrew Morton wrote:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
>>
> Hi,
> 
> It looks like Zach Brown's patch pr_debug-check-pr_debug-arguments
> worked as inteded.

:).  I should really take the time to get some cross compilers going.

>   arch/arm/vfp/vfpsingle.c:201: error: `func' undeclared (first use in
>   this function)

Does changing 'func' to '__func__' in the arguments fix it?

- z

Re: [-mm patch] arm build fail: vfpsingle.c

[Frederik Deweerdt]

On Tue, Sep 12, 2006 at 11:27:57AM -0700, Zach Brown wrote:
> Frederik Deweerdt wrote:
> > On Tue, Sep 12, 2006 at 12:06:18AM -0700, Andrew Morton wrote:
> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> >>
> > Hi,
> > 
> > It looks like Zach Brown's patch pr_debug-check-pr_debug-arguments
> > worked as inteded.
> 
> :).  I should really take the time to get some cross compilers going.
> 
> >   arch/arm/vfp/vfpsingle.c:201: error: `func' undeclared (first use in
> >   this function)
> 
> Does changing 'func' to '__func__' in the arguments fix it?
Yes it does, but the intended use of 'func' (or so I understood) is to
print the calling function name, not the current function's, isn't it?

Frederik
> 
> - z
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [-mm patch] arm build fail: vfpsingle.c

[Zach Brown]

> Yes it does, but the intended use of 'func' (or so I understood) is to
> print the calling function name, not the current function's, isn't it?

Dunno, I took it to mean the current function from the context of that
patch.  I could be wrong, of course.

- z

Re: [-mm patch] arm build fail: vfpsingle.c

[Frederik Deweerdt]

On Tue, Sep 12, 2006 at 12:07:35PM -0700, Zach Brown wrote:
> 
> > Yes it does, but the intended use of 'func' (or so I understood) is to
> > print the calling function name, not the current function's, isn't it?
> 
> Dunno, I took it to mean the current function from the context of that
> patch.  I could be wrong, of course.
I've just checked, this are some of the callers of
vfp_single_normaliseround (last argument is 'func'):

in vfp_single_fuito: 
	vfp_single_normaliseround(sd, &vs, fpscr, 0, "fuito");
in vfp_single_fsito:
	vfp_single_normaliseround(sd, &vs, fpscr, 0, "fsito");
in vfp_single_fnmul:
	vfp_single_normaliseround(sd, &vsd, fpscr, exceptions, "fnmul");

It definitely looks like we want the calling function to be printed
here.

Regards,
Frederik

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

2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325

[Rafael J. Wysocki]

On Tuesday, 12 September 2006 09:06, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/

'rmmod ohci_hcd' causes the following oops to appear on my HPC 6325 every
time (happens also on -rc6-mm1, does not happen on -rc7):

Unable to handle kernel NULL pointer dereference at 0000000000000274 RIP:
 [<ffffffff8822c185>] :ohci_hcd:ohci_hub_status_data+0x25/0x27b
PGD 35ca9067 PUD 369a4067 PMD 0
Oops: 0000 [1] SMP
last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
CPU 0
Modules linked in: netconsole cpufreq_ondemand cpufreq_userspace cpufreq_powersa
ve powernow_k8 freq_table button af_packet edd battery snd_pcm_oss snd_mixer_oss
 snd_seq snd_seq_device ac ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_man
gle iptable_nat ip_nat iptable_filter ip6table_mangle ip_conntrack nfnetlink ip_
tables ip6table_filter ip6_tables x_tables ipv6 loop dm_mod usbhid ff_memless hc
i_usb bluetooth snd_hda_intel snd_hda_codec bcm43xx ohci1394 ohci_hcd shpchp pci
_hotplug pcmcia ehci_hcd i2c_piix4 ieee1394 firmware_class ieee80211softmac usbc
ore tg3 sdhci ieee80211 ieee80211_crypt mmc_core ide_cd k8temp yenta_socket rsrc
_nonstatic pcmcia_core i2c_core hwmon snd_pcm snd_timer snd soundcore snd_page_a
lloc cdrom ext3 jbd fan thermal processor atiixp ide_disk ide_core sg
Pid: 3667, comm: rmmod Tainted: G   M  2.6.18-rc6-mm2 #19
RIP: 0010:[<ffffffff8822c185>]  [<ffffffff8822c185>] :ohci_hcd:ohci_hub_status_d
ata+0x25/0x27b
RSP: 0018:ffffffff805c7e18  EFLAGS: 00010296
RAX: 0000000000000000 RBX: ffff81003485c508 RCX: 0000000000000000
RDX: 0000000000000064 RSI: ffffffff805c7e68 RDI: ffff81003485c640
RBP: ffffffff805c7e58 R08: 0000000000000000 R09: ffff810037438138
R10: ffffffff80701c40 R11: ffff81003263bc88 R12: ffff81003485c640
R13: ffffffff805c7e68 R14: ffffc2000003c000 R15: ffff81003485c508
FS:  00002ba0d06fa6d0(0000) GS:ffffffff8066f000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000274 CR3: 000000002f153000 CR4: 00000000000006e0
Process rmmod (pid: 3667, threadinfo ffff81003263a000, task ffff81003697c810)
Stack:  ffffffff802813b0 ffffffff805c7e40 ffffffff80281258 ffff81003485c508
 ffff81003485c508 ffff81003485c508 ffffc2000003c000 ffffffff805c7e68
 ffffffff805c7ea8 ffffffff8818e03f 003d09e3f5998950 ffffffff80509860
Call Trace:
 [<ffffffff8818e03f>] :usbcore:usb_hcd_poll_rh_status+0x40/0x13b
 [<ffffffff8822c01b>] :ohci_hcd:ohci_irq+0xcb/0x210
 [<ffffffff8818e78b>] :usbcore:usb_hcd_irq+0x2f/0x5f
 [<ffffffff8020ef13>] handle_IRQ_event+0x33/0x66
 [<ffffffff802af5f8>] handle_fasteoi_irq+0x9d/0xe3
 [<ffffffff80267c85>] do_IRQ+0x104/0x11f
 [<ffffffff80259621>] ret_from_intr+0x0/0xa
DWARF2 unwinder stuck at ret_from_intr+0x0/0xa

Leftover inexact backtrace:

 <IRQ>  <EOI>  [<ffffffff802ee4ac>] sysfs_hash_and_remove+0x9/0x137
 [<ffffffff802eed13>] sysfs_remove_file+0x10/0x12
 [<ffffffff8038baf7>] class_device_remove_file+0x12/0x14
 [<ffffffff8822aa02>] :ohci_hcd:ohci_stop+0xf5/0x17b
 [<ffffffff8818d9d2>] :usbcore:usb_remove_hcd+0xdc/0x114
 [<ffffffff8040f8eb>] klist_release+0x0/0x82
 [<ffffffff88197f45>] :usbcore:usb_hcd_pci_remove+0x1e/0x7d
 [<ffffffff803204d8>] pci_device_remove+0x25/0x3c
 [<ffffffff8038b1b5>] __device_release_driver+0x80/0x9c
 [<ffffffff8038b617>] driver_detach+0xac/0xee
 [<ffffffff8038ad92>] bus_remove_driver+0x75/0x98
 [<ffffffff8038b696>] driver_unregister+0x15/0x21
 [<ffffffff80320686>] pci_unregister_driver+0x13/0x8e
 [<ffffffff8822cd1c>] :ohci_hcd:ohci_hcd_pci_cleanup+0x10/0x12
 [<ffffffff8029b281>] sys_delete_module+0x1b5/0x1e6
 [<ffffffff8025910e>] system_call+0x7e/0x83


Code: 8a 98 74 02 00 00 e8 d6 3b 03 f8 48 89 45 d0 41 8b 84 24 e4
RIP  [<ffffffff8822c185>] :ohci_hcd:ohci_hub_status_data+0x25/0x27b
 RSP <ffffffff805c7e18>
CR2: 0000000000000274
 <0>Kernel panic - not syncing: Aiee, killing interrupt handler!

where

(gdb) l *ohci_hub_status_data+0x25
0x4185 is in ohci_hub_status_data (drivers/usb/host/ohci-hub.c:316).
311             struct ohci_hcd *ohci = hcd_to_ohci (hcd);
312             int             i, changed = 0, length = 1;
313             int             can_suspend;
314             unsigned long   flags;
315
316             can_suspend = device_may_wakeup(&hcd->self.root_hub->dev);
317             spin_lock_irqsave (&ohci->lock, flags);
318
319             /* handle autosuspended root:  finish resuming before
320              * letting khubd or root hub timer see state changes.

I guess it may be related to the suspend issues?

Re: 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325

[Rafael J. Wysocki]

On Wednesday, 13 September 2006 15:58, Rafael J. Wysocki wrote:
> On Tuesday, 12 September 2006 09:06, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> 
> 'rmmod ohci_hcd' causes the following oops to appear on my HPC 6325 every
> time (happens also on -rc6-mm1, does not happen on -rc7):

So far, I have verified that the problem already happened on -rc5-mm1.

Greetings,
Rafael


> Unable to handle kernel NULL pointer dereference at 0000000000000274 RIP:
>  [<ffffffff8822c185>] :ohci_hcd:ohci_hub_status_data+0x25/0x27b
> PGD 35ca9067 PUD 369a4067 PMD 0
> Oops: 0000 [1] SMP
> last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
> CPU 0
> Modules linked in: netconsole cpufreq_ondemand cpufreq_userspace cpufreq_powersa
> ve powernow_k8 freq_table button af_packet edd battery snd_pcm_oss snd_mixer_oss
>  snd_seq snd_seq_device ac ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_man
> gle iptable_nat ip_nat iptable_filter ip6table_mangle ip_conntrack nfnetlink ip_
> tables ip6table_filter ip6_tables x_tables ipv6 loop dm_mod usbhid ff_memless hc
> i_usb bluetooth snd_hda_intel snd_hda_codec bcm43xx ohci1394 ohci_hcd shpchp pci
> _hotplug pcmcia ehci_hcd i2c_piix4 ieee1394 firmware_class ieee80211softmac usbc
> ore tg3 sdhci ieee80211 ieee80211_crypt mmc_core ide_cd k8temp yenta_socket rsrc
> _nonstatic pcmcia_core i2c_core hwmon snd_pcm snd_timer snd soundcore snd_page_a
> lloc cdrom ext3 jbd fan thermal processor atiixp ide_disk ide_core sg
> Pid: 3667, comm: rmmod Tainted: G   M  2.6.18-rc6-mm2 #19
> RIP: 0010:[<ffffffff8822c185>]  [<ffffffff8822c185>] :ohci_hcd:ohci_hub_status_d
> ata+0x25/0x27b
> RSP: 0018:ffffffff805c7e18  EFLAGS: 00010296
> RAX: 0000000000000000 RBX: ffff81003485c508 RCX: 0000000000000000
> RDX: 0000000000000064 RSI: ffffffff805c7e68 RDI: ffff81003485c640
> RBP: ffffffff805c7e58 R08: 0000000000000000 R09: ffff810037438138
> R10: ffffffff80701c40 R11: ffff81003263bc88 R12: ffff81003485c640
> R13: ffffffff805c7e68 R14: ffffc2000003c000 R15: ffff81003485c508
> FS:  00002ba0d06fa6d0(0000) GS:ffffffff8066f000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000274 CR3: 000000002f153000 CR4: 00000000000006e0
> Process rmmod (pid: 3667, threadinfo ffff81003263a000, task ffff81003697c810)
> Stack:  ffffffff802813b0 ffffffff805c7e40 ffffffff80281258 ffff81003485c508
>  ffff81003485c508 ffff81003485c508 ffffc2000003c000 ffffffff805c7e68
>  ffffffff805c7ea8 ffffffff8818e03f 003d09e3f5998950 ffffffff80509860
> Call Trace:
>  [<ffffffff8818e03f>] :usbcore:usb_hcd_poll_rh_status+0x40/0x13b
>  [<ffffffff8822c01b>] :ohci_hcd:ohci_irq+0xcb/0x210
>  [<ffffffff8818e78b>] :usbcore:usb_hcd_irq+0x2f/0x5f
>  [<ffffffff8020ef13>] handle_IRQ_event+0x33/0x66
>  [<ffffffff802af5f8>] handle_fasteoi_irq+0x9d/0xe3
>  [<ffffffff80267c85>] do_IRQ+0x104/0x11f
>  [<ffffffff80259621>] ret_from_intr+0x0/0xa
> DWARF2 unwinder stuck at ret_from_intr+0x0/0xa
> 
> Leftover inexact backtrace:
> 
>  <IRQ>  <EOI>  [<ffffffff802ee4ac>] sysfs_hash_and_remove+0x9/0x137
>  [<ffffffff802eed13>] sysfs_remove_file+0x10/0x12
>  [<ffffffff8038baf7>] class_device_remove_file+0x12/0x14
>  [<ffffffff8822aa02>] :ohci_hcd:ohci_stop+0xf5/0x17b
>  [<ffffffff8818d9d2>] :usbcore:usb_remove_hcd+0xdc/0x114
>  [<ffffffff8040f8eb>] klist_release+0x0/0x82
>  [<ffffffff88197f45>] :usbcore:usb_hcd_pci_remove+0x1e/0x7d
>  [<ffffffff803204d8>] pci_device_remove+0x25/0x3c
>  [<ffffffff8038b1b5>] __device_release_driver+0x80/0x9c
>  [<ffffffff8038b617>] driver_detach+0xac/0xee
>  [<ffffffff8038ad92>] bus_remove_driver+0x75/0x98
>  [<ffffffff8038b696>] driver_unregister+0x15/0x21
>  [<ffffffff80320686>] pci_unregister_driver+0x13/0x8e
>  [<ffffffff8822cd1c>] :ohci_hcd:ohci_hcd_pci_cleanup+0x10/0x12
>  [<ffffffff8029b281>] sys_delete_module+0x1b5/0x1e6
>  [<ffffffff8025910e>] system_call+0x7e/0x83
> 
> 
> Code: 8a 98 74 02 00 00 e8 d6 3b 03 f8 48 89 45 d0 41 8b 84 24 e4
> RIP  [<ffffffff8822c185>] :ohci_hcd:ohci_hub_status_data+0x25/0x27b
>  RSP <ffffffff805c7e18>
> CR2: 0000000000000274
>  <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
> 
> where
> 
> (gdb) l *ohci_hub_status_data+0x25
> 0x4185 is in ohci_hub_status_data (drivers/usb/host/ohci-hub.c:316).
> 311             struct ohci_hcd *ohci = hcd_to_ohci (hcd);
> 312             int             i, changed = 0, length = 1;
> 313             int             can_suspend;
> 314             unsigned long   flags;
> 315
> 316             can_suspend = device_may_wakeup(&hcd->self.root_hub->dev);
> 317             spin_lock_irqsave (&ohci->lock, flags);
> 318
> 319             /* handle autosuspended root:  finish resuming before
> 320              * letting khubd or root hub timer see state changes.

Re: 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325

[Alan Stern]

On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:

> 'rmmod ohci_hcd' causes the following oops to appear on my HPC 6325 every
> time (happens also on -rc6-mm1, does not happen on -rc7):
> 
> Unable to handle kernel NULL pointer dereference at 0000000000000274 RIP:
>  [<ffffffff8822c185>] :ohci_hcd:ohci_hub_status_data+0x25/0x27b
> PGD 35ca9067 PUD 369a4067 PMD 0

> Call Trace:
>  [<ffffffff8818e03f>] :usbcore:usb_hcd_poll_rh_status+0x40/0x13b
>  [<ffffffff8822c01b>] :ohci_hcd:ohci_irq+0xcb/0x210
>  [<ffffffff8818e78b>] :usbcore:usb_hcd_irq+0x2f/0x5f
>  [<ffffffff8020ef13>] handle_IRQ_event+0x33/0x66
>  [<ffffffff802af5f8>] handle_fasteoi_irq+0x9d/0xe3
>  [<ffffffff80267c85>] do_IRQ+0x104/0x11f
>  [<ffffffff80259621>] ret_from_intr+0x0/0xa
> DWARF2 unwinder stuck at ret_from_intr+0x0/0xa
> 
> Leftover inexact backtrace:
> 
>  <IRQ>  <EOI>  [<ffffffff802ee4ac>] sysfs_hash_and_remove+0x9/0x137
>  [<ffffffff802eed13>] sysfs_remove_file+0x10/0x12
>  [<ffffffff8038baf7>] class_device_remove_file+0x12/0x14
>  [<ffffffff8822aa02>] :ohci_hcd:ohci_stop+0xf5/0x17b
>  [<ffffffff8818d9d2>] :usbcore:usb_remove_hcd+0xdc/0x114
>  [<ffffffff8040f8eb>] klist_release+0x0/0x82
>  [<ffffffff88197f45>] :usbcore:usb_hcd_pci_remove+0x1e/0x7d
>  [<ffffffff803204d8>] pci_device_remove+0x25/0x3c
>  [<ffffffff8038b1b5>] __device_release_driver+0x80/0x9c
>  [<ffffffff8038b617>] driver_detach+0xac/0xee
>  [<ffffffff8038ad92>] bus_remove_driver+0x75/0x98
>  [<ffffffff8038b696>] driver_unregister+0x15/0x21
>  [<ffffffff80320686>] pci_unregister_driver+0x13/0x8e
>  [<ffffffff8822cd1c>] :ohci_hcd:ohci_hcd_pci_cleanup+0x10/0x12
>  [<ffffffff8029b281>] sys_delete_module+0x1b5/0x1e6
>  [<ffffffff8025910e>] system_call+0x7e/0x83
> 
> 
> Code: 8a 98 74 02 00 00 e8 d6 3b 03 f8 48 89 45 d0 41 8b 84 24 e4
> RIP  [<ffffffff8822c185>] :ohci_hcd:ohci_hub_status_data+0x25/0x27b
>  RSP <ffffffff805c7e18>
> CR2: 0000000000000274
>  <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
> 
> where
> 
> (gdb) l *ohci_hub_status_data+0x25
> 0x4185 is in ohci_hub_status_data (drivers/usb/host/ohci-hub.c:316).
> 311             struct ohci_hcd *ohci = hcd_to_ohci (hcd);
> 312             int             i, changed = 0, length = 1;
> 313             int             can_suspend;
> 314             unsigned long   flags;
> 315
> 316             can_suspend = device_may_wakeup(&hcd->self.root_hub->dev);
> 317             spin_lock_irqsave (&ohci->lock, flags);
> 318
> 319             /* handle autosuspended root:  finish resuming before
> 320              * letting khubd or root hub timer see state changes.
> 
> I guess it may be related to the suspend issues?

No, this is completely separate.  The suspend issue involved ehci-hcd, not 
ohci-hcd.

This problem has already been identified by Pete Zaitcev in this thread:

	http://marc.theaimsgroup.com/?t=115769512800001&r=1&w=2

Perhaps Pete has an updated patch to fix the problem.  If not, I could 
write one.

Alan Stern

Re: 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325

[Rafael J. Wysocki]

On Wednesday, 13 September 2006 20:44, Alan Stern wrote:
> On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
> 
> > 'rmmod ohci_hcd' causes the following oops to appear on my HPC 6325 every
> > time (happens also on -rc6-mm1, does not happen on -rc7):
> > 
> > Unable to handle kernel NULL pointer dereference at 0000000000000274 RIP:
> >  [<ffffffff8822c185>] :ohci_hcd:ohci_hub_status_data+0x25/0x27b
> > PGD 35ca9067 PUD 369a4067 PMD 0
> 
> > Call Trace:
> >  [<ffffffff8818e03f>] :usbcore:usb_hcd_poll_rh_status+0x40/0x13b
> >  [<ffffffff8822c01b>] :ohci_hcd:ohci_irq+0xcb/0x210
> >  [<ffffffff8818e78b>] :usbcore:usb_hcd_irq+0x2f/0x5f
> >  [<ffffffff8020ef13>] handle_IRQ_event+0x33/0x66
> >  [<ffffffff802af5f8>] handle_fasteoi_irq+0x9d/0xe3
> >  [<ffffffff80267c85>] do_IRQ+0x104/0x11f
> >  [<ffffffff80259621>] ret_from_intr+0x0/0xa
> > DWARF2 unwinder stuck at ret_from_intr+0x0/0xa
> > 
> > Leftover inexact backtrace:
> > 
> >  <IRQ>  <EOI>  [<ffffffff802ee4ac>] sysfs_hash_and_remove+0x9/0x137
> >  [<ffffffff802eed13>] sysfs_remove_file+0x10/0x12
> >  [<ffffffff8038baf7>] class_device_remove_file+0x12/0x14
> >  [<ffffffff8822aa02>] :ohci_hcd:ohci_stop+0xf5/0x17b
> >  [<ffffffff8818d9d2>] :usbcore:usb_remove_hcd+0xdc/0x114
> >  [<ffffffff8040f8eb>] klist_release+0x0/0x82
> >  [<ffffffff88197f45>] :usbcore:usb_hcd_pci_remove+0x1e/0x7d
> >  [<ffffffff803204d8>] pci_device_remove+0x25/0x3c
> >  [<ffffffff8038b1b5>] __device_release_driver+0x80/0x9c
> >  [<ffffffff8038b617>] driver_detach+0xac/0xee
> >  [<ffffffff8038ad92>] bus_remove_driver+0x75/0x98
> >  [<ffffffff8038b696>] driver_unregister+0x15/0x21
> >  [<ffffffff80320686>] pci_unregister_driver+0x13/0x8e
> >  [<ffffffff8822cd1c>] :ohci_hcd:ohci_hcd_pci_cleanup+0x10/0x12
> >  [<ffffffff8029b281>] sys_delete_module+0x1b5/0x1e6
> >  [<ffffffff8025910e>] system_call+0x7e/0x83
> > 
> > 
> > Code: 8a 98 74 02 00 00 e8 d6 3b 03 f8 48 89 45 d0 41 8b 84 24 e4
> > RIP  [<ffffffff8822c185>] :ohci_hcd:ohci_hub_status_data+0x25/0x27b
> >  RSP <ffffffff805c7e18>
> > CR2: 0000000000000274
> >  <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
> > 
> > where
> > 
> > (gdb) l *ohci_hub_status_data+0x25
> > 0x4185 is in ohci_hub_status_data (drivers/usb/host/ohci-hub.c:316).
> > 311             struct ohci_hcd *ohci = hcd_to_ohci (hcd);
> > 312             int             i, changed = 0, length = 1;
> > 313             int             can_suspend;
> > 314             unsigned long   flags;
> > 315
> > 316             can_suspend = device_may_wakeup(&hcd->self.root_hub->dev);
> > 317             spin_lock_irqsave (&ohci->lock, flags);
> > 318
> > 319             /* handle autosuspended root:  finish resuming before
> > 320              * letting khubd or root hub timer see state changes.
> > 
> > I guess it may be related to the suspend issues?
> 
> No, this is completely separate.  The suspend issue involved ehci-hcd, not 
> ohci-hcd.

Well, on my box it's ohci-hcd too.

> This problem has already been identified by Pete Zaitcev in this thread:
> 
> 	http://marc.theaimsgroup.com/?t=115769512800001&r=1&w=2

Ah, thanks.

> Perhaps Pete has an updated patch to fix the problem.  If not, I could 
> write one.

For now I can use the original Pete's patch, but it would be nice to have a
fix in -mm. ;-)

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325

[Pete Zaitcev]

On Wed, 13 Sep 2006 14:44:48 -0400 (EDT), Alan Stern <stern@rowland.harvard.edu> wrote:

> This problem has already been identified by Pete Zaitcev in this thread:
> 
> 	http://marc.theaimsgroup.com/?t=115769512800001&r=1&w=2
> 
> Perhaps Pete has an updated patch to fix the problem.  If not, I could 
> write one.

No, not yet. I am working on getting David's approach with irq = -1
tested at Stratus. Since it was the only reproducer known to me, I wanted
to test. Now that Rafael has a fault case, I'll expedite.

-- Pete

Re: 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325

[Rafael J. Wysocki]

On Thursday, 14 September 2006 00:31, Pete Zaitcev wrote:
> On Wed, 13 Sep 2006 14:44:48 -0400 (EDT), Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> > This problem has already been identified by Pete Zaitcev in this thread:
> > 
> > 	http://marc.theaimsgroup.com/?t=115769512800001&r=1&w=2
> > 
> > Perhaps Pete has an updated patch to fix the problem.  If not, I could 
> > write one.
> 
> No, not yet. I am working on getting David's approach with irq = -1
> tested at Stratus. Since it was the only reproducer known to me, I wanted
> to test. Now that Rafael has a fault case, I'll expedite.

In fact I can reproduce it on two different boxes now.

Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325

[Pete Zaitcev]

On Thu, 14 Sep 2006 13:19:53 +0200, "Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> In fact I can reproduce it on two different boxes now.

How about the attached?

-- Pete

diff -urp -X dontdiff linux-2.6.18-rc6/drivers/usb/host/ohci-hcd.c linux-2.6.18-rc6-lem/drivers/usb/host/ohci-hcd.c
--- linux-2.6.18-rc6/drivers/usb/host/ohci-hcd.c	2006-09-06 21:56:32.000000000 -0700
+++ linux-2.6.18-rc6-lem/drivers/usb/host/ohci-hcd.c	2006-09-14 22:48:15.000000000 -0700
@@ -775,7 +775,9 @@ static void ohci_stop (struct usb_hcd *h
 
 	ohci_usb_reset (ohci);
 	ohci_writel (ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
-	
+	free_irq(hcd->irq, hcd);
+	hcd->irq = -1;
+
 	remove_debug_files (ohci);
 	unregister_reboot_notifier (&ohci->reboot_notifier);
 	ohci_mem_cleanup (ohci);

Re: 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325

[Rafael J. Wysocki]

On Saturday, 16 September 2006 00:45, Pete Zaitcev wrote:
> On Thu, 14 Sep 2006 13:19:53 +0200, "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > In fact I can reproduce it on two different boxes now.
> 
> How about the attached?

Apparently works. :-)

Thanks,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: 2.6.18-rc6-mm2: rmmod ohci_hcd oopses on HPC 6325

[David Brownell]

On Friday 15 September 2006 3:45 pm, Pete Zaitcev wrote:
> On Thu, 14 Sep 2006 13:19:53 +0200, "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > In fact I can reproduce it on two different boxes now.
> 
> How about the attached?
> 
> -- Pete

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>


> diff -urp -X dontdiff linux-2.6.18-rc6/drivers/usb/host/ohci-hcd.c linux-2.6.18-rc6-lem/drivers/usb/host/ohci-hcd.c
> --- linux-2.6.18-rc6/drivers/usb/host/ohci-hcd.c	2006-09-06 21:56:32.000000000 -0700
> +++ linux-2.6.18-rc6-lem/drivers/usb/host/ohci-hcd.c	2006-09-14 22:48:15.000000000 -0700
> @@ -775,7 +775,9 @@ static void ohci_stop (struct usb_hcd *h
>  
>  	ohci_usb_reset (ohci);
>  	ohci_writel (ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
> -	
> +	free_irq(hcd->irq, hcd);
> +	hcd->irq = -1;
> +
>  	remove_debug_files (ohci);
>  	unregister_reboot_notifier (&ohci->reboot_notifier);
>  	ohci_mem_cleanup (ohci);
> 

Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
>

Kernel 2.6.18-rc6-mm2 - xfs-rename-uio_read.patch
Built with gcc 3.4
Reading specs from /usr/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.6/specs
Configured with: ./configure --prefix=/usr/local/ --disable-nls
--enable-shared --enable-languages=c --program-suffix=-3.4
Thread model: posix
gcc version 3.4.6

ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 17
BUG: unable to handle kernel paging request at virtual address 5a5a5aaa
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
 printing eip:
c01f596a
*pde = 00000000
Oops: 0000 [#1]
4K_STACKS PREEMPT SMP
last sysfs file:
Modules linked in:
CPU:    0
EIP:    0060:[<c01f596a>]    Not tainted VLI
EFLAGS: 00010202   (2.6.18-rc6-mm2 #122)
EIP is at kref_get+0x7/0x55
eax: 5a5a5aaa   ebx: 5a5a5aaa   ecx: c75cfe54   edx: c75cfe54
esi: c033152f   edi: c75cfe5e   ebp: c755be20   esp: c755be18
ds: 007b   es: 007b   ss: 0068
Process usb-probe-<NULL (pid: 291, ti=c755b000 task=c759aab0 task.ti=c755b000)
Stack: 5a5a5a92 c033152f c755be2c c01f529b c75cfe80 c755be50 c01b1513 c755be50
       fffffff4 c75bd51c 5a5a5a92 c75b8eec c0331525 5a5a5a92 c755be68 c01b15ca
       ffffffef c75cfeac c752e044 c752e044 c755be80 c025d2ff c752e12c c75cfeac
Call Trace:
 [<c01f529b>] kobject_get+0x12/0x17
 [<c01b1513>] sysfs_add_link+0x5f/0xa3
 [<c01b15ca>] sysfs_create_link+0x73/0x8c
 [<c025d2ff>] device_add_class_symlinks+0x2f/0x111
 [<c025d5f4>] device_add+0x181/0x2ea
 [<c025d76f>] device_register+0x12/0x15
 [<c02936b2>] usb_create_ep_files+0xaf/0x146
 [<c0293013>] usb_create_sysfs_dev_files+0x80/0xbb
 [<c0296402>] generic_probe+0xc/0x55
 [<c0290e54>] usb_probe_device+0x35/0x3b
 [<c025f1eb>] really_probe+0x3a/0xbb
 [<c025f31e>] driver_probe_device+0x99/0xa5
 [<c025f332>] __device_attach+0x8/0xa
 [<c025e828>] bus_for_each_drv+0x38/0x5d
 [<c025f384>] device_attach+0x50/0x67
 [<c025e9fe>] bus_attach_device+0x1a/0x35
 [<c025d65e>] device_add+0x1eb/0x2ea
 [<c028c182>] __usb_new_device+0x102/0x134
 [<c0134b3d>] kthread+0x79/0xa1
 [<c0103e53>] kernel_thread_helper+0x7/0x10
 =======================
Code: 40 89 06 3b 45 18 5e 7f 04 ff 07 31 db 8d 65 f4 89 d8 5b 5e 5f
5d c3 90 90 55 c7 00 01 00 00 00 89 e5 5d c3 55 89 e5 56 53 89 c3 <8b>
00 85 c0 0f 94 c0 0f b6 f0 b8 38 b9 38 c0 89 f2 e8 f4 0f 01
Sep 14 12:58:09 euridica kernel: EIP: [<c01f596a>] kref_get+0x7/0x55
SS:ESP 0068:c755be18
Sep 14 12:58:09 euridica kernel:  <7>PCI: Setting latency timer of
device 0000:00:1d.2 to 64

l *0xc01f596a
0xc01f596a is in kref_get (/usr/src/linux-mm/lib/kref.c:32).
27       * kref_get - increment refcount for object.
28       * @kref: object.
29       */
30      void kref_get(struct kref *kref)
31      {
32              WARN_ON(!atomic_read(&kref->refcount));
33              atomic_inc(&kref->refcount);
34      }
35
36      /**

http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-config1

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: 2.6.18-rc6-mm2

[Andrew Morton]

(Added linux-usb-devel)

On Thu, 14 Sep 2006 13:11:49 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:

> On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> >
> 
> Kernel 2.6.18-rc6-mm2 - xfs-rename-uio_read.patch
> Built with gcc 3.4
> Reading specs from /usr/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.6/specs
> Configured with: ./configure --prefix=/usr/local/ --disable-nls
> --enable-shared --enable-languages=c --program-suffix=-3.4
> Thread model: posix
> gcc version 3.4.6
> 
> ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 17
> BUG: unable to handle kernel paging request at virtual address 5a5a5aaa
> usb usb2: configuration #1 chosen from 1 choice
> hub 2-0:1.0: USB hub found
>  printing eip:
> c01f596a
> *pde = 00000000
> Oops: 0000 [#1]
> 4K_STACKS PREEMPT SMP
> last sysfs file:
> Modules linked in:
> CPU:    0
> EIP:    0060:[<c01f596a>]    Not tainted VLI
> EFLAGS: 00010202   (2.6.18-rc6-mm2 #122)
> EIP is at kref_get+0x7/0x55
> eax: 5a5a5aaa   ebx: 5a5a5aaa   ecx: c75cfe54   edx: c75cfe54
> esi: c033152f   edi: c75cfe5e   ebp: c755be20   esp: c755be18
> ds: 007b   es: 007b   ss: 0068
> Process usb-probe-<NULL (pid: 291, ti=c755b000 task=c759aab0 task.ti=c755b000)

That's an interesting process name..

> Stack: 5a5a5a92 c033152f c755be2c c01f529b c75cfe80 c755be50 c01b1513 c755be50
>        fffffff4 c75bd51c 5a5a5a92 c75b8eec c0331525 5a5a5a92 c755be68 c01b15ca
>        ffffffef c75cfeac c752e044 c752e044 c755be80 c025d2ff c752e12c c75cfeac
> Call Trace:
>  [<c01f529b>] kobject_get+0x12/0x17
>  [<c01b1513>] sysfs_add_link+0x5f/0xa3
>  [<c01b15ca>] sysfs_create_link+0x73/0x8c
>  [<c025d2ff>] device_add_class_symlinks+0x2f/0x111
>  [<c025d5f4>] device_add+0x181/0x2ea
>  [<c025d76f>] device_register+0x12/0x15
>  [<c02936b2>] usb_create_ep_files+0xaf/0x146
>  [<c0293013>] usb_create_sysfs_dev_files+0x80/0xbb
>  [<c0296402>] generic_probe+0xc/0x55
>  [<c0290e54>] usb_probe_device+0x35/0x3b
>  [<c025f1eb>] really_probe+0x3a/0xbb
>  [<c025f31e>] driver_probe_device+0x99/0xa5
>  [<c025f332>] __device_attach+0x8/0xa
>  [<c025e828>] bus_for_each_drv+0x38/0x5d
>  [<c025f384>] device_attach+0x50/0x67
>  [<c025e9fe>] bus_attach_device+0x1a/0x35
>  [<c025d65e>] device_add+0x1eb/0x2ea
>  [<c028c182>] __usb_new_device+0x102/0x134
>  [<c0134b3d>] kthread+0x79/0xa1
>  [<c0103e53>] kernel_thread_helper+0x7/0x10
>  =======================
> Code: 40 89 06 3b 45 18 5e 7f 04 ff 07 31 db 8d 65 f4 89 d8 5b 5e 5f
> 5d c3 90 90 55 c7 00 01 00 00 00 89 e5 5d c3 55 89 e5 56 53 89 c3 <8b>
> 00 85 c0 0f 94 c0 0f b6 f0 b8 38 b9 38 c0 89 f2 e8 f4 0f 01
> Sep 14 12:58:09 euridica kernel: EIP: [<c01f596a>] kref_get+0x7/0x55
> SS:ESP 0068:c755be18
> Sep 14 12:58:09 euridica kernel:  <7>PCI: Setting latency timer of
> device 0000:00:1d.2 to 64
> 
> l *0xc01f596a
> 0xc01f596a is in kref_get (/usr/src/linux-mm/lib/kref.c:32).
> 27       * kref_get - increment refcount for object.
> 28       * @kref: object.
> 29       */
> 30      void kref_get(struct kref *kref)
> 31      {
> 32              WARN_ON(!atomic_read(&kref->refcount));
> 33              atomic_inc(&kref->refcount);
> 34      }
> 35
> 36      /**
> 
> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/mm-config1
> 
> Regards,
> Michal
> 
> -- 
> Michal K. K. Piotrowski
> LTG - Linux Testers Group
> (http://www.stardust.webpages.pl/ltg/)

Re: 2.6.18-rc6-mm2

[Greg KH]

On Thu, Sep 14, 2006 at 01:11:49PM +0200, Michal Piotrowski wrote:
> On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> >
> 
> Kernel 2.6.18-rc6-mm2 - xfs-rename-uio_read.patch
> Built with gcc 3.4
> Reading specs from /usr/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.6/specs
> Configured with: ./configure --prefix=/usr/local/ --disable-nls
> --enable-shared --enable-languages=c --program-suffix=-3.4
> Thread model: posix
> gcc version 3.4.6
> 
> ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 17
> BUG: unable to handle kernel paging request at virtual address 5a5a5aaa
> usb usb2: configuration #1 chosen from 1 choice
> hub 2-0:1.0: USB hub found
> printing eip:
> c01f596a
> *pde = 00000000
> Oops: 0000 [#1]
> 4K_STACKS PREEMPT SMP
> last sysfs file:
> Modules linked in:
> CPU:    0
> EIP:    0060:[<c01f596a>]    Not tainted VLI
> EFLAGS: 00010202   (2.6.18-rc6-mm2 #122)
> EIP is at kref_get+0x7/0x55
> eax: 5a5a5aaa   ebx: 5a5a5aaa   ecx: c75cfe54   edx: c75cfe54
> esi: c033152f   edi: c75cfe5e   ebp: c755be20   esp: c755be18
> ds: 007b   es: 007b   ss: 0068
> Process usb-probe-<NULL (pid: 291, ti=c755b000 task=c759aab0 
> task.ti=c755b000)

You have the USB multi-threaded device probing config option
(CONFIG_USB_MULTITHREAD_PROBE) enabled, right?

Does disabling it fix this problem?

That option has been reworked by Alan Stern, and I need to intregate it
into my tree soon.  This is the first report of a problem with the
current stuff, I wonder why.

Can you send the output of /sys/proc/bus/usb/devices with the same
devices plugged in on a different, no oopsing kernel?

thanks,

greg k-h

Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 14/09/06, Greg KH <gregkh@suse.de> wrote:
> On Thu, Sep 14, 2006 at 01:11:49PM +0200, Michal Piotrowski wrote:
> > On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> > >
> >
> > Kernel 2.6.18-rc6-mm2 - xfs-rename-uio_read.patch
> > Built with gcc 3.4
> > Reading specs from /usr/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.6/specs
> > Configured with: ./configure --prefix=/usr/local/ --disable-nls
> > --enable-shared --enable-languages=c --program-suffix=-3.4
> > Thread model: posix
> > gcc version 3.4.6
> >
> > ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 17
> > BUG: unable to handle kernel paging request at virtual address 5a5a5aaa
> > usb usb2: configuration #1 chosen from 1 choice
> > hub 2-0:1.0: USB hub found
> > printing eip:
> > c01f596a
> > *pde = 00000000
> > Oops: 0000 [#1]
> > 4K_STACKS PREEMPT SMP
> > last sysfs file:
> > Modules linked in:
> > CPU:    0
> > EIP:    0060:[<c01f596a>]    Not tainted VLI
> > EFLAGS: 00010202   (2.6.18-rc6-mm2 #122)
> > EIP is at kref_get+0x7/0x55
> > eax: 5a5a5aaa   ebx: 5a5a5aaa   ecx: c75cfe54   edx: c75cfe54
> > esi: c033152f   edi: c75cfe5e   ebp: c755be20   esp: c755be18
> > ds: 007b   es: 007b   ss: 0068
> > Process usb-probe-<NULL (pid: 291, ti=c755b000 task=c759aab0
> > task.ti=c755b000)
>
> You have the USB multi-threaded device probing config option
> (CONFIG_USB_MULTITHREAD_PROBE) enabled, right?

Yes, I have.

>
> Does disabling it fix this problem?

I'll disable it and try to reproduce the problem.

> That option has been reworked by Alan Stern, and I need to intregate it
> into my tree soon.  This is the first report of a problem with the
> current stuff, I wonder why.
>
> Can you send the output of /sys/proc/bus/usb/devices with the same
> devices plugged in on a different, no oopsing kernel?

cat /proc/bus/usb/devices

T:  Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.18-rc7-g63b98080 uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.3
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.18-rc7-g63b98080 uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=118/900 us (13%), #Int=  1, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.18-rc7-g63b98080 uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=04d9 ProdID=0499 Rev= 2.90
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.18-rc7-g63b98080 uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 8
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.18-rc7-g63b98080 ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=0000:00:1d.7
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms

>
> thanks,
>
> greg k-h
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: 2.6.18-rc6-mm2

[Greg KH]

On Fri, Sep 15, 2006 at 12:17:33AM +0200, Michal Piotrowski wrote:
> On 14/09/06, Greg KH <gregkh@suse.de> wrote:
> >On Thu, Sep 14, 2006 at 01:11:49PM +0200, Michal Piotrowski wrote:
> >> On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
> >> >
> >> 
> >>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> >> >
> >>
> >> Kernel 2.6.18-rc6-mm2 - xfs-rename-uio_read.patch
> >> Built with gcc 3.4
> >> Reading specs from 
> >/usr/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.6/specs
> >> Configured with: ./configure --prefix=/usr/local/ --disable-nls
> >> --enable-shared --enable-languages=c --program-suffix=-3.4
> >> Thread model: posix
> >> gcc version 3.4.6
> >>
> >> ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 17
> >> BUG: unable to handle kernel paging request at virtual address 5a5a5aaa
> >> usb usb2: configuration #1 chosen from 1 choice
> >> hub 2-0:1.0: USB hub found
> >> printing eip:
> >> c01f596a
> >> *pde = 00000000
> >> Oops: 0000 [#1]
> >> 4K_STACKS PREEMPT SMP
> >> last sysfs file:
> >> Modules linked in:
> >> CPU:    0
> >> EIP:    0060:[<c01f596a>]    Not tainted VLI
> >> EFLAGS: 00010202   (2.6.18-rc6-mm2 #122)
> >> EIP is at kref_get+0x7/0x55
> >> eax: 5a5a5aaa   ebx: 5a5a5aaa   ecx: c75cfe54   edx: c75cfe54
> >> esi: c033152f   edi: c75cfe5e   ebp: c755be20   esp: c755be18
> >> ds: 007b   es: 007b   ss: 0068
> >> Process usb-probe-<NULL (pid: 291, ti=c755b000 task=c759aab0
> >> task.ti=c755b000)
> >
> >You have the USB multi-threaded device probing config option
> >(CONFIG_USB_MULTITHREAD_PROBE) enabled, right?
> 
> Yes, I have.
> 
> >
> >Does disabling it fix this problem?
> 
> I'll disable it and try to reproduce the problem.

Great, please let us know.  Your device list looks simple, I don't see
why this would happen (no confusing devices).  In fact, this is getting
triggered by the root hub, which Alan's update specifically addresses by
not making that be multithreaded, as it's not needed.

I'll work on intergrating that patch update.

thanks,

greg k-h

Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 15/09/06, Greg KH <gregkh@suse.de> wrote:
> On Fri, Sep 15, 2006 at 12:17:33AM +0200, Michal Piotrowski wrote:
> > On 14/09/06, Greg KH <gregkh@suse.de> wrote:
> > >On Thu, Sep 14, 2006 at 01:11:49PM +0200, Michal Piotrowski wrote:
> > >> On 12/09/06, Andrew Morton <akpm@osdl.org> wrote:
> > >> >
> > >>
> > >>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm2/
> > >> >
> > >>
> > >> Kernel 2.6.18-rc6-mm2 - xfs-rename-uio_read.patch
> > >> Built with gcc 3.4
> > >> Reading specs from
> > >/usr/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.6/specs
> > >> Configured with: ./configure --prefix=/usr/local/ --disable-nls
> > >> --enable-shared --enable-languages=c --program-suffix=-3.4
> > >> Thread model: posix
> > >> gcc version 3.4.6
> > >>
> > >> ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 17
> > >> BUG: unable to handle kernel paging request at virtual address 5a5a5aaa
> > >> usb usb2: configuration #1 chosen from 1 choice
> > >> hub 2-0:1.0: USB hub found
> > >> printing eip:
> > >> c01f596a
> > >> *pde = 00000000
> > >> Oops: 0000 [#1]
> > >> 4K_STACKS PREEMPT SMP
> > >> last sysfs file:
> > >> Modules linked in:
> > >> CPU:    0
> > >> EIP:    0060:[<c01f596a>]    Not tainted VLI
> > >> EFLAGS: 00010202   (2.6.18-rc6-mm2 #122)
> > >> EIP is at kref_get+0x7/0x55
> > >> eax: 5a5a5aaa   ebx: 5a5a5aaa   ecx: c75cfe54   edx: c75cfe54
> > >> esi: c033152f   edi: c75cfe5e   ebp: c755be20   esp: c755be18
> > >> ds: 007b   es: 007b   ss: 0068
> > >> Process usb-probe-<NULL (pid: 291, ti=c755b000 task=c759aab0
> > >> task.ti=c755b000)
> > >
> > >You have the USB multi-threaded device probing config option
> > >(CONFIG_USB_MULTITHREAD_PROBE) enabled, right?
> >
> > Yes, I have.
> >
> > >
> > >Does disabling it fix this problem?
> >
> > I'll disable it and try to reproduce the problem.
>
> Great, please let us know.

Good news, I can't reproduce this bug with CONFIG_USB_MULTITHREAD_PROBE=n.

BTW. This might be a problem with CONFIG_PCI_MULTITHREAD_PROBE=y
http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/bug.jpg

>  Your device list looks simple, I don't see
> why this would happen (no confusing devices).  In fact, this is getting
> triggered by the root hub, which Alan's update specifically addresses by
> not making that be multithreaded, as it's not needed.
>
> I'll work on intergrating that patch update.
>
> thanks,
>
> greg k-h
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: 2.6.18-rc6-mm2

[Greg KH]

On Fri, Sep 15, 2006 at 10:35:37PM +0200, Michal Piotrowski wrote:
> Good news, I can't reproduce this bug with CONFIG_USB_MULTITHREAD_PROBE=n.

Great, thanks for letting me know.

> BTW. This might be a problem with CONFIG_PCI_MULTITHREAD_PROBE=y
> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/bug.jpg

That looks odd.  What device is your root partition on?  And what is the
"switchroot" stuff being printed out, is that in an initramfs?

thanks,

greg k-h

Re: 2.6.18-rc6-mm2

[Michal Piotrowski]

On 15/09/06, Greg KH <gregkh@suse.de> wrote:
> On Fri, Sep 15, 2006 at 10:35:37PM +0200, Michal Piotrowski wrote:
> > Good news, I can't reproduce this bug with CONFIG_USB_MULTITHREAD_PROBE=n.
>
> Great, thanks for letting me know.
>
> > BTW. This might be a problem with CONFIG_PCI_MULTITHREAD_PROBE=y
> > http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/bug.jpg
>
> That looks odd.  What device is your root partition on?

SATA HDD.

>  And what is the
> "switchroot" stuff being printed out, is that in an initramfs?

Yes, it's initrd generated by new-kernel-pkg (Fedora).

>
> thanks,
>
> greg k-h
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)

Re: 2.6.18-rc6-mm2

[Greg KH]

On Sat, Sep 16, 2006 at 02:14:52PM +0200, Michal Piotrowski wrote:
> On 15/09/06, Greg KH <gregkh@suse.de> wrote:
> >On Fri, Sep 15, 2006 at 10:35:37PM +0200, Michal Piotrowski wrote:
> >> Good news, I can't reproduce this bug with 
> >CONFIG_USB_MULTITHREAD_PROBE=n.
> >
> >Great, thanks for letting me know.
> >
> >> BTW. This might be a problem with CONFIG_PCI_MULTITHREAD_PROBE=y
> >> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm2/bug.jpg
> >
> >That looks odd.  What device is your root partition on?
> 
> SATA HDD.

Which type of SATA device?  Is it ata_piix perhaps?

If so, you need the hack below to enable these devices to work properly.
I can't vouch for any problems that might happen with the patch, but
I've been using it successfully for quite a while.

thanks,

greg k-h

---------------------
Subject: Driver: multi-threaded hacks

 - Fix "issue" with ata_piix doing multi-threaded boot

Use at your own risk.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/scsi/ata_piix.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- gregkh-2.6.orig/drivers/scsi/ata_piix.c
+++ gregkh-2.6/drivers/scsi/ata_piix.c
@@ -1024,7 +1024,7 @@ static int __init piix_init(void)
 	if (rc)
 		return rc;
 
-	in_module_init = 0;
+//	in_module_init = 0;  multi-threaded probe doesn't like this...
 
 	DPRINTK("done\n");
 	return 0;

2.6.18-rc6-mm2: __fscache_register_netfs compile error

[Christian Kujau]

Hello,

I could not find this anywhere reported, so here it goes:

when is enabled, gcc-4.0.3 (ubuntu/dapper, x86_64) gives:

fs/built-in.o: In function `init_nfs_fs':inode.c:(.init.text+0x16a9): undefined reference to `__fscache_register_netfs'
:inode.c:(.init.text+0x1757): undefined reference to `__fscache_unregister_netfs'

see the full error here:
http://nerdbynature.de/bits/2.6.18-rc6-mm2/make.log

I suspect a missing "#include <linux/fscache.h>" but could not find out 
where yet :(

Thanks,
Christian.
-- 
BOFH excuse #96:

Vendor no longer supports the product

Re: 2.6.18-rc6-mm2: __fscache_register_netfs compile error

[Christian Kujau]

On Sun, 17 Sep 2006, Christian Kujau wrote:
> when is enabled, gcc-4.0.3 (ubuntu/dapper, x86_64) gives:
------^ uh, that should read:

"when CONFIG_NFS_FSCACHE is enabled..."

The diff to the old-and-working-config is here:
http://nerdbynature.de/bits/2.6.18-rc6-mm2/config.diff

Christian.
-- 
BOFH excuse #50:

Change in Earth's rotational speed

Re: 2.6.18-rc6-mm2: __fscache_register_netfs compile error

[David Howells]

Christian Kujau <evil@g-house.de> wrote:

> I could not find this anywhere reported, so here it goes:
> 
> when is enabled, gcc-4.0.3 (ubuntu/dapper, x86_64) gives:
> 
> fs/built-in.o: In function `init_nfs_fs':inode.c:(.init.text+0x16a9): undefined reference to `__fscache_register_netfs'
> :inode.c:(.init.text+0x1757): undefined reference to `__fscache_unregister_netfs'

It looks like your build failed to build the fscache facility or built it as a
module but build NFS directly into the kernel.  What's your full configuration?

David

Re: 2.6.18-rc6-mm2: __fscache_register_netfs compile error

[David Howells]

Hmmm...  It looks like a configurator problem:

	warthog>grep 'NFS\|CACHE' .config 
	CONFIG_X86_L1_CACHE_BYTES=128
	CONFIG_X86_L1_CACHE_SHIFT=7
	CONFIG_X86_INTERNODE_CACHE_BYTES=128
	# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
	CONFIG_IRDA_CACHE_LAST_LSAP=y
	# CONFIG_CDROM_PKTCDVD_WCACHE is not set
	CONFIG_FS_MBCACHE=y
 --->	CONFIG_FSCACHE=m
	# CONFIG_CACHEFILES is not set
 --->	CONFIG_NFS_FS=y
	CONFIG_NFS_V3=y
	CONFIG_NFS_V3_ACL=y
	CONFIG_NFS_V4=y
	CONFIG_NFS_FSCACHE=y
	CONFIG_NFS_DIRECTIO=y
	CONFIG_NFSD=m
	CONFIG_NFSD_V2_ACL=y
	CONFIG_NFSD_V3=y
	CONFIG_NFSD_V3_ACL=y
	CONFIG_NFSD_V4=y
	CONFIG_NFSD_TCP=y
	CONFIG_NFS_ACL_SUPPORT=y
	CONFIG_NFS_COMMON=y
	CONFIG_NCPFS_NFS_NS=y

I'm not sure what I can do about that.  NFS_FS doesn't depend on FSCACHE, and
so isn't forced to become a module when FSCACHE is.  The dependency is through
one of NFS's configuation options.

David

Re: 2.6.18-rc6-mm2: __fscache_register_netfs compile error

[Christian Kujau]

Hello David,

On Fri, 22 Sep 2006, David Howells wrote:
> --->	CONFIG_FSCACHE=m
> 	# CONFIG_CACHEFILES is not set
> --->	CONFIG_NFS_FS=y
[...]
> I'm not sure what I can do about that.  NFS_FS doesn't depend on FSCACHE, and
> so isn't forced to become a module when FSCACHE is.  The dependency is through
> one of NFS's configuation options.

I'll try to build with different settings (CONFIG_FSCACHE=y and will 
look at the Kconfig for this one again, only my (faster) build-machine 
is offline right now...

Thanks,
Christian.
-- 
BOFH excuse #378:

Operators killed by year 2000 bug bite.

Re: 2.6.18-rc6-mm2: __fscache_register_netfs compile error

[Christian Kujau]

for the record (and to make the archives happy): the compile error 
went away with the latest -mm version (same config, make oldconfig).

Thanks,
Christian.
-- 
BOFH excuse #11:

magnetic interference from money/credit cards