2.6.12-rc1-mm2

[Stefano Rivoir]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.
6.12-rc1-mm2/
- Some fixes for the recent DRM problems.

Hi Andrew,

While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, and
Xorg fails to enable DRI (attached, lspci and .config):

Unable to handle kernel paging request at virtual address 72ff64d7
printing eip:
e087eb44
*pde = 00000000
Oops: 0002 [#1]
PREEMPT
Modules linked in: radeon drm sd_mod scsi_mod lp hotkey fan container button
ide_cd 8250_pnp parport_pc parport floppy pcspkr sk98lin yenta_socket
rsrc_nonstatic pcmcia_core ehci_hcd usbhid ohci_hcd snd_intel8x0m 8250_pci
8250 serial_core ohci1394 ieee1394 sis_agp agpgart vfat fat video thermal
processor ac battery snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss
snd_pcm snd_timer snd soundcore snd_page_alloc skge evdev
CPU: 0
EIP: 0060:[<e087eb44>] Not tainted VLI
EFLAGS: 00013286 (2.6.12-rc1-mm2)
EIP is at agp_find_bridge+0x0/0xffffc77f [agpgart]
eax: dff1d000 ebx: de228400 ecx: 00000000 edx: 000000d0
esi: dd860000 edi: de228450 ebp: e1a4bd90 esp: dd811f48
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 4698, threadinfo=dd810000 task=dfca3030)
Stack: e1a085fb dd860000 00000000 e1a4c240 e1a06ed0 dd860000 e1a4c240 dff1d000
dd860000 e1a071ce e1a4c240 c01abfaf e1a4bd90 dff1d000 e1a4c240 00000310
e1a03adf ffffffff 00000000 00000310 fffffffc e1a4e180 dd810000 dd810000
Call Trace:
[<e1a085fb>] drm_agp_init+0x3b/0xb0 [drm]
[<e1a06ed0>] drm_fill_in_dev+0xf0/0x1b0 [drm]
[<e1a071ce>] drm_get_dev+0x4e/0xc0 [drm]
[<c01abfaf>] kobject_get+0xf/0x20
[<e1a03adf>] drm_init+0x6f/0xb0 [drm]
[<c0130589>] sys_init_module+0x139/0x1e0
[<c0102fdb>] sysenter_past_esp+0x54/0x75
Code: 6e 66 69 67 5f 62 79 74 65 00 61 67 70 5f 70 75 74 5f 62 72 69 64 67 65
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 <c0> a7 87 e0 dc 94
cd de dc 94 cd de 00 00 00 00 00 00 00 00 00

[Brice Goglin]

Post by Stefano Rivoir

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.
6.12-rc1-mm2/
- Some fixes for the recent DRM problems.

Hi Andrew,
While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, and

Same problem on my Radeon M6 LY here.
This seems to be due to agp_find_bridge not being exported anymore
in agp_backend.h. Dave might have forgotten it when reworking my patch.
Patch attached.

Brice

Signoff-by: Brice Goglin <***@ens-lyon.org>

--- linux-mm/include/linux/agp_backend.h.old 2005-03-24
16:17:25.000000000 +0100
+++ linux-mm/include/linux/agp_backend.h 2005-03-24
16:10:25.000000000 +0100
@@ -100,6 +100,7 @@
extern int agp_bind_memory(struct agp_memory *, off_t);
extern int agp_unbind_memory(struct agp_memory *);
extern void agp_enable(struct agp_bridge_data *, u32);
+extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *);
extern struct agp_bridge_data *agp_backend_acquire(struct pci_dev *);
extern void agp_backend_release(struct agp_bridge_data *);

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Stefano Rivoir]

Post by Brice Goglin

Post by Stefano Rivoir

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/
2. 6.12-rc1-mm2/
- Some fixes for the recent DRM problems.

Hi Andrew,
While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup,

--- linux-mm/include/linux/agp_backend.h.old 2005-03-24
16:17:25.000000000 +0100
+++ linux-mm/include/linux/agp_backend.h 2005-03-24
16:10:25.000000000 +0100
@@ -100,6 +100,7 @@
extern int agp_bind_memory(struct agp_memory *, off_t);
extern int agp_unbind_memory(struct agp_memory *);
extern void agp_enable(struct agp_bridge_data *, u32);
+extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *);
extern struct agp_bridge_data *agp_backend_acquire(struct pci_dev *);
extern void agp_backend_release(struct agp_bridge_data *);

Right, that fixed it for me.

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Andrew Morton]

Post by Stefano Rivoir

Post by Brice Goglin

Post by Stefano Rivoir

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/
2. 6.12-rc1-mm2/
- Some fixes for the recent DRM problems.

Hi Andrew,
While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup,

--- linux-mm/include/linux/agp_backend.h.old 2005-03-24
16:17:25.000000000 +0100
+++ linux-mm/include/linux/agp_backend.h 2005-03-24
16:10:25.000000000 +0100
@@ -100,6 +100,7 @@
extern int agp_bind_memory(struct agp_memory *, off_t);
extern int agp_unbind_memory(struct agp_memory *);
extern void agp_enable(struct agp_bridge_data *, u32);
+extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *);
extern struct agp_bridge_data *agp_backend_acquire(struct pci_dev *);
extern void agp_backend_release(struct agp_bridge_data *);

Right, that fixed it for me.

There were contradictory patches in flight and I stuck the latest drm tree
into rc1-mm2 at the last minute, alas. You should revert
agp-make-some-code-static.patch.

But I assume that fixing the compile warnings does not fix the oopses which
Stefano and Brice are seeing?

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Brice Goglin]

Post by Andrew Morton

Post by Stefano Rivoir

Post by Brice Goglin
--- linux-mm/include/linux/agp_backend.h.old 2005-03-24
16:17:25.000000000 +0100
+++ linux-mm/include/linux/agp_backend.h 2005-03-24
16:10:25.000000000 +0100
@@ -100,6 +100,7 @@
extern int agp_bind_memory(struct agp_memory *, off_t);
extern int agp_unbind_memory(struct agp_memory *);
extern void agp_enable(struct agp_bridge_data *, u32);
+extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *);
extern struct agp_bridge_data *agp_backend_acquire(struct pci_dev *);
extern void agp_backend_release(struct agp_bridge_data *);

Right, that fixed it for me.

There were contradictory patches in flight and I stuck the latest drm tree
into rc1-mm2 at the last minute, alas. You should revert
agp-make-some-code-static.patch.
But I assume that fixing the compile warnings does not fix the oopses which
Stefano and Brice are seeing?

My patch does fix both the compile warnings and my oops on my Radeon laptop.

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Alexey Dobriyan]

Post by Brice Goglin

Post by Andrew Morton

Post by Stefano Rivoir

Post by Brice Goglin
--- linux-mm/include/linux/agp_backend.h.old
+++ linux-mm/include/linux/agp_backend.h
+extern struct agp_bridge_data * (*agp_find_bridge)(struct pci_dev *);

Right, that fixed it for me.

There were contradictory patches in flight and I stuck the latest drm
tree into rc1-mm2 at the last minute, alas. You should revert
agp-make-some-code-static.patch.
But I assume that fixing the compile warnings does not fix the oopses
which Stefano and Brice are seeing?

My patch does fix both the compile warnings and my oops on my Radeon laptop.

It also allows my machine to boot.

Alexey

...
drm_agp_init+0x30/0x8e
drm_fill_in_dev+0xe7/0x195
drm_get_dev+0x4a/0xba
kobject_get+0xf/0x13
do_initcalls+0x54/0xb0
init+0x0/0x100
init+0x0/0x100
kernel_thread_helper+0x0/0x0b
kernel_thread_helper+0x5/0x0b
...
<0>Kernel panic - not syncing: Attempted to kill init!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Manuel Lauss]

Post by Stefano Rivoir

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.
6.12-rc1-mm2/
- Some fixes for the recent DRM problems.

Hi Andrew,
While I was OK with DRM up to 2.6.12-rc1-mm1, now I get this at startup, and
Unable to handle kernel paging request at virtual address 72ff64d7
e087eb44
*pde = 00000000
Oops: 0002 [#1]
PREEMPT
Modules linked in: radeon drm sd_mod scsi_mod lp hotkey fan container button
ide_cd 8250_pnp parport_pc parport floppy pcspkr sk98lin yenta_socket
rsrc_nonstatic pcmcia_core ehci_hcd usbhid ohci_hcd snd_intel8x0m 8250_pci
8250 serial_core ohci1394 ieee1394 sis_agp agpgart vfat fat video thermal
processor ac battery snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss
snd_pcm snd_timer snd soundcore snd_page_alloc skge evdev
CPU: 0
EIP: 0060:[<e087eb44>] Not tainted VLI
EFLAGS: 00013286 (2.6.12-rc1-mm2)
EIP is at agp_find_bridge+0x0/0xffffc77f [agpgart]
eax: dff1d000 ebx: de228400 ecx: 00000000 edx: 000000d0
esi: dd860000 edi: de228450 ebp: e1a4bd90 esp: dd811f48
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 4698, threadinfo=dd810000 task=dfca3030)
Stack: e1a085fb dd860000 00000000 e1a4c240 e1a06ed0 dd860000 e1a4c240 dff1d000
dd860000 e1a071ce e1a4c240 c01abfaf e1a4bd90 dff1d000 e1a4c240 00000310
e1a03adf ffffffff 00000000 00000310 fffffffc e1a4e180 dd810000 dd810000
[<e1a085fb>] drm_agp_init+0x3b/0xb0 [drm]
[<e1a06ed0>] drm_fill_in_dev+0xf0/0x1b0 [drm]
[<e1a071ce>] drm_get_dev+0x4e/0xc0 [drm]
[<c01abfaf>] kobject_get+0xf/0x20
[<e1a03adf>] drm_init+0x6f/0xb0 [drm]
[<c0130589>] sys_init_module+0x139/0x1e0
[<c0102fdb>] sysenter_past_esp+0x54/0x75
Code: 6e 66 69 67 5f 62 79 74 65 00 61 67 70 5f 70 75 74 5f 62 72 69 64 67 65
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 <c0> a7 87 e0 dc 94
cd de dc 94 cd de 00 00 00 00 00 00 00 00 00

I get a similar Oops at boot; I noticed this warning during compilation:

drivers/char/drm/drm_agpsupport.c: In function `drm_agp_init':
drivers/char/drm/drm_agpsupport.c:391: warning: implicit declaration of function `agp_find_bridge'
drivers/char/drm/drm_agpsupport.c:391: warning: assignment makes pointer from integer without a cast

I dont know what header to include/modify to make it go away.
DRM and AGP are compiled into the kernel (no modules).
--
Manuel Lauss

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Steven Cole]

CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
: undefined reference to `class_device_creat'
make: *** [.tmp_vmlinux1] Error 1

I glanced at the code, and this little patch fixes the problem:

Steven

[Greg KH]

CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
: undefined reference to `class_device_creat'
make: *** [.tmp_vmlinux1] Error 1

Ick, sorry, that was my fault. I've applied this patch to my trees,
thanks.

Hm, I wonder how I missed this, I did do a 'make allmodconfig' build to
try to catch this kind of stuff...

thanks,

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Andrew Morton]

Post by Greg KH
Ick, sorry, that was my fault. I've applied this patch to my trees,
thanks.
Hm, I wonder how I missed this, I did do a 'make allmodconfig' build to
try to catch this kind of stuff...

allmodconfig doesn't catch BROKEN_ON_SMP code. I've been caught out by
that a few times.

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Steven Cole]

I'm getting the following build error with 2.6.12-rc1-mm2:

CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o(.init.text+0x4323): In function `zft_init':
: undefined reference to `class_device_creat'
make: *** [.tmp_vmlinux1] Error 1

2.6.12-rc1-mm1 built and is running just fine. I used the
-rc1-mm1 .config, did make oldconfig, make bzImage. Here is
the .config:

[***@spc1 linux-2.6.12-rc1-mm2]$ grep ^CONFIG .config
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_CLEAR_PAGES=y
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION="-GX110"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KALLSYMS=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_BASE_SMALL=0
CONFIG_X86_PC=y
CONFIG_MPENTIUMIII=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_EDD=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_PHYSICAL_START=0x100000
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=32000
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_AOE_PARTITIONS=16
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_TCPDIAG=y
CONFIG_XFRM=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_LIBPS2=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_FTAPE=y
CONFIG_ZFTAPE=y
CONFIG_ZFT_DFLT_BLK_SZ=10240
CONFIG_ZFT_COMPRESSOR=y
CONFIG_FT_NR_BUFFERS=3
CONFIG_FT_PROC_FS=y
CONFIG_FT_NORMAL_DEBUG=y
CONFIG_FT_STD_FDC=y
CONFIG_FT_FDC_THR=8
CONFIG_FT_FDC_MAX_RATE=2000
CONFIG_FT_ALPHA_CLOCK=0
CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_SELECT=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT3_FS=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_REISER4_FS=y
CONFIG_REISERFS_FS=y
CONFIG_DNOTIFY=y
CONFIG_ISO9660_FS=y
CONFIG_FAT_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=y
CONFIG_NTFS_RW=y
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_DEVFS_FS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_UTF8=y
CONFIG_PRINTK_TIME=y
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_FRAME_POINTER=y
CONFIG_EARLY_PRINTK=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_CAPABILITIES=y
CONFIG_CRC_CCITT=y
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Lee Revell]

-mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually
they are pulled 3-4 hours before the release of the -mm kernel.

Andrew,

Do you notify the subsystem maintainers ahead of time so that critical
fixes can be pushed to BK?

I am thinking of the recent ALSA example, where the emu10k1 driver was
b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week.

Lee

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Andrew Morton]

Post by Stefano Rivoir

-mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually
they are pulled 3-4 hours before the release of the -mm kernel.

Andrew,
Do you notify the subsystem maintainers ahead of time so that critical
fixes can be pushed to BK?

Occasionally I'll go out and ping people, but almost always the subsystem
guys know what the development cycle is, and they appropriately decide
which code should go in, and when.

Post by Stefano Rivoir
I am thinking of the recent ALSA example, where the emu10k1 driver was
b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week.

We've been discussing how to get ALSA CVS into ALSA bk more promptly.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Rafael J. Wysocki]

Hi,

Post by Andrew Morton

Post by Stefano Rivoir

-mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually
they are pulled 3-4 hours before the release of the -mm kernel.

Andrew,
Do you notify the subsystem maintainers ahead of time so that critical
fixes can be pushed to BK?

Occasionally I'll go out and ping people, but almost always the subsystem
guys know what the development cycle is, and they appropriately decide
which code should go in, and when.

Post by Stefano Rivoir
I am thinking of the recent ALSA example, where the emu10k1 driver was
b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week.

We've been discussing how to get ALSA CVS into ALSA bk more promptly.

BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process
goes into the D state immediately), which did not happen before. This is 100%
reproducible, on two different AMD64-based boxes, with different sound chips.

Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Rafael J. Wysocki]

Post by Rafael J. Wysocki
Hi,

Post by Andrew Morton

Post by Stefano Rivoir

-mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually
they are pulled 3-4 hours before the release of the -mm kernel.

Andrew,
Do you notify the subsystem maintainers ahead of time so that critical
fixes can be pushed to BK?

Occasionally I'll go out and ping people, but almost always the subsystem
guys know what the development cycle is, and they appropriately decide
which code should go in, and when.

Post by Stefano Rivoir
I am thinking of the recent ALSA example, where the emu10k1 driver was
b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week.

We've been discussing how to get ALSA CVS into ALSA bk more promptly.

BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process
goes into the D state immediately), which did not happen before. This is 100%
reproducible, on two different AMD64-based boxes, with different sound chips.

Er, sorry for the noise on alsa-devel. Actually, rmmod doesn't work for me at all
on x86-64 (on two different boxes).

Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Laurent Riffard]

Post by Rafael J. Wysocki
Hi,

Post by Andrew Morton

Post by Stefano Rivoir

-mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually
they are pulled 3-4 hours before the release of the -mm kernel.

Andrew,
Do you notify the subsystem maintainers ahead of time so that critical
fixes can be pushed to BK?

Occasionally I'll go out and ping people, but almost always the subsystem
guys know what the development cycle is, and they appropriately decide
which code should go in, and when.

Post by Stefano Rivoir
I am thinking of the recent ALSA example, where the emu10k1 driver was
b0rked in 2.6.12-mm1, but the fix had been in ALSA CVS for a week.

We've been discussing how to get ALSA CVS into ALSA bk more promptly.

BTW, on 2.6.12-rc1-mm2 I can't rmmod the snd_intel8x0 module (the process
goes into the D state immediately), which did not happen before. This is 100%
reproducible, on two different AMD64-based boxes, with different sound chips.
Greets,
Rafael

hello,

Same kinds of problem here. It depends on the removed module. I mean:
"rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod
ohci1394" hangs.

Sysrq-T when rmmoding snd_ens1371 :

rmmod D C92EBE8C 0 8231 8159 (NOTLB)
c92ebea0 00000082 00000003 c92ebe8c 00000000 5685fc00 000f4253 cd624530
cd624658 cff60874 cff60844 c92ebebc c92ebef0 c02618c7 00000000
cd624530
c0113137 00000000 00000000 00000282 cd248c20 cd248c07 00000001
cd624530
Call Trace:
[wait_for_completion+124/193] wait_for_completion+0x7c/0xc1
[<c02618c7>] wait_for_completion+0x7c/0xc1
[device_release_driver+52/116] device_release_driver+0x34/0x74
[<c01f0ae3>] device_release_driver+0x34/0x74
[__remove_driver+8/12] __remove_driver+0x8/0xc
[<c01f0b2b>] __remove_driver+0x8/0xc
[driver_for_each_device+50/87] driver_for_each_device+0x32/0x57
[<c01f0bd8>] driver_for_each_device+0x32/0x57
[driver_detach+17/19] driver_detach+0x11/0x13
[<c01f0b40>] driver_detach+0x11/0x13
[bus_remove_driver+76/130] bus_remove_driver+0x4c/0x82
[<c01f05eb>] bus_remove_driver+0x4c/0x82
[driver_unregister+14/23] driver_unregister+0xe/0x17
[<c01f0cb2>] driver_unregister+0xe/0x17
[pci_unregister_driver+14/23] pci_unregister_driver+0xe/0x17
[<c019b242>] pci_unregister_driver+0xe/0x17
[sys_delete_module+322/379] sys_delete_module+0x142/0x17b
[<c0128356>] sys_delete_module+0x142/0x17b

Sysrq-T when rmmoding ohci1394 :

rmmod D 00000001 0 12353 10401 (NOTLB)
cefa9ea0 00000082 c012f3d9 00000001 0001e848 e88bbbc0 000f426d cb613570
cb613698 cff60074 cff60044 cefa9ebc cefa9ef0 c02618d7 00000000
cb613570
c0113137 00000000 00000000 00000286 cd379e60 cd379e47 00000001
cb613570
Call Trace:
[wait_for_completion+124/193] wait_for_completion+0x7c/0xc1
[<c02618d7>] wait_for_completion+0x7c/0xc1
[device_release_driver+52/116] device_release_driver+0x34/0x74
[<c01f0aeb>] device_release_driver+0x34/0x74
[__remove_driver+8/12] __remove_driver+0x8/0xc
[<c01f0b33>] __remove_driver+0x8/0xc
[driver_for_each_device+50/87] driver_for_each_device+0x32/0x57
[<c01f0be0>] driver_for_each_device+0x32/0x57
[driver_detach+17/19] driver_detach+0x11/0x13
[<c01f0b48>] driver_detach+0x11/0x13
[bus_remove_driver+76/130] bus_remove_driver+0x4c/0x82
[<c01f05f3>] bus_remove_driver+0x4c/0x82
[driver_unregister+14/23] driver_unregister+0xe/0x17
[<c01f0cba>] driver_unregister+0xe/0x17
[pci_unregister_driver+14/23] pci_unregister_driver+0xe/0x17
[<c019b242>] pci_unregister_driver+0xe/0x17
[sys_delete_module+322/379] sys_delete_module+0x142/0x17b
[<c0128356>] sys_delete_module+0x142/0x17b
[sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75

.config attached

~~
laurent

[Andrew Morton]

Post by Laurent Riffard
hello,
"rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod
ohci1394" hangs.
rmmod D C92EBE8C 0 8231 8159 (NOTLB)
c92ebea0 00000082 00000003 c92ebe8c 00000000 5685fc00 000f4253 cd624530
cd624658 cff60874 cff60844 c92ebebc c92ebef0 c02618c7 00000000
cd624530
c0113137 00000000 00000000 00000282 cd248c20 cd248c07 00000001
cd624530
[wait_for_completion+124/193] wait_for_completion+0x7c/0xc1
[<c02618c7>] wait_for_completion+0x7c/0xc1
[device_release_driver+52/116] device_release_driver+0x34/0x74
[<c01f0ae3>] device_release_driver+0x34/0x74
[__remove_driver+8/12] __remove_driver+0x8/0xc
[<c01f0b2b>] __remove_driver+0x8/0xc
[driver_for_each_device+50/87] driver_for_each_device+0x32/0x57
[<c01f0bd8>] driver_for_each_device+0x32/0x57
[driver_detach+17/19] driver_detach+0x11/0x13
[<c01f0b40>] driver_detach+0x11/0x13
[bus_remove_driver+76/130] bus_remove_driver+0x4c/0x82
[<c01f05eb>] bus_remove_driver+0x4c/0x82
[driver_unregister+14/23] driver_unregister+0xe/0x17
[<c01f0cb2>] driver_unregister+0xe/0x17
[pci_unregister_driver+14/23] pci_unregister_driver+0xe/0x17
[<c019b242>] pci_unregister_driver+0xe/0x17
[sys_delete_module+322/379] sys_delete_module+0x142/0x17b
[<c0128356>] sys_delete_module+0x142/0x17b

It looks like we're getting stuck in the wait_for_completion() in the new
klist_remove().

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Patrick Mochel]

Post by Andrew Morton

Post by Laurent Riffard
hello,
"rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod
ohci1394" hangs.

<snip>

Post by Andrew Morton
It looks like we're getting stuck in the wait_for_completion() in the new
klist_remove().

D'oh! It's getting hung while waiting to remove the current node from the
list (which it can't remove because it's being used). The patch below
should fix it.

Pat

===== drivers/base/dd.c 1.3 vs edited =====
--- 1.3/drivers/base/dd.c 2005-03-21 12:25:04 -08:00
+++ edited/drivers/base/dd.c 2005-03-24 16:55:21 -08:00
@@ -177,7 +177,7 @@

sysfs_remove_link(&drv->kobj, kobject_name(&dev->kobj));
sysfs_remove_link(&dev->kobj, "driver");
- klist_remove(&dev->knode_driver);
+ klist_del(&dev->knode_driver);

down(&dev->sem);
device_detach_shutdown(dev);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Greg KH]

Post by Patrick Mochel

Post by Andrew Morton

Post by Laurent Riffard
hello,
"rmmod loop" or "rmmod pcspkr" works. But "rmmod snd_ens1371" or "rmmod
ohci1394" hangs.

<snip>

Post by Andrew Morton
It looks like we're getting stuck in the wait_for_completion() in the new
klist_remove().

D'oh! It's getting hung while waiting to remove the current node from the
list (which it can't remove because it's being used). The patch below
should fix it.

Thanks, I've added this to my bk trees.

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Laurent Riffard]

Post by Patrick Mochel

Post by Andrew Morton

Post by Laurent Riffard
hello,
Same kinds of problem here. It depends on the removed module. I
mean: "rmmod loop" or "rmmod pcspkr" works. But "rmmod
snd_ens1371" or "rmmod ohci1394" hangs.

<snip>

Post by Andrew Morton
It looks like we're getting stuck in the wait_for_completion() in
the new klist_remove().

D'oh! It's getting hung while waiting to remove the current node from
the list (which it can't remove because it's being used). The patch
below should fix it.
Pat
===== drivers/base/dd.c 1.3 vs edited =====
--- 1.3/drivers/base/dd.c 2005-03-21 12:25:04 -08:00
+++ edited/drivers/base/dd.c 2005-03-24 16:55:21 -08:00
@@ -177,7 +177,7 @@
sysfs_remove_link(&drv->kobj, kobject_name(&dev->kobj));
sysfs_remove_link(&dev->kobj, "driver");
- klist_remove(&dev->knode_driver);
+ klist_del(&dev->knode_driver);
down(&dev->sem);
device_detach_shutdown(dev);

Ok, I can confirm this patch solved the problem.

Thanks for your help.
--
laurent

[Reuben Farrelly]

Hi,

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm2/
- Added David Miller's networking tree to the -mm lineup as bk-net.patch.
- Added Herbert Xu's crypto development tree to the -mm lineup as
bk-cryptodev.patch.
-mm kernels now aggregate Linus's tree and 34 subsystem trees. Usually
they are pulled 3-4 hours before the release of the -mm kernel.
Usually it is possible to determine the latest cset from each tree by
looking at the first couple of lines of the relevant patch in the
broken-out/ directory. Although sometimes it isn't there if I had to
massage the diff.
- There may be an x86_64 problem here, although it works for me. If it
fails early in boot, try reverting
x86_64-separate-amd-cmp-detection-from-hyper-threading.patch
- There's some work here on the recent USB PM resume bugs. If you had
problems there, please test and be sure to cc
- Some fixes for the recent DRM problems.
- Big DVB update
- md updates
- nfs4 server updates
- Lots more fixes
- Lots more bugs.

Fails to compile for me:

CC [M] fs/nfs/dir.o
CC [M] fs/nfs/inode.o
CC [M] fs/nfs/nfs4proc.o
fs/nfs/nfs4proc.c:2976: error: static declaration of
'nfs4_file_inode_operations' follows non-static declaration
fs/nfs/nfs4_fs.h:179: error: previous declaration of
'nfs4_file_inode_operations' was here
make[2]: *** [fs/nfs/nfs4proc.o] Error 1
make[1]: *** [fs/nfs] Error 2
make: *** [fs] Error 2

I needed to remove this line:

extern struct inode_operations nfs4_file_inode_operations;

from fs/nfs/nfs4_fs.h.

Patch attached.

Reuben

[Adrian Bunk]

...
...
-revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functions.patch
Drop this - the modules are now in the kernel.
...

As already discussed, there's still no module using this in the kernel.

The part of this patch that still applies is below.

<-- snip -->

These module exports have no GPL'ed callers.

Signed-off-by: Adrian Bunk <***@stusta.de>

--- linux-2.6.12-rc1-mm2-full/arch/ia64/kernel/sal.c.old 2005-03-25 01:31:22.000000000 +0100
+++ linux-2.6.12-rc1-mm2-full/arch/ia64/kernel/sal.c 2005-03-25 01:34:24.000000000 +0100
@@ -273,7 +273,6 @@
SAL_CALL(*isrvp, oemfunc, arg1, arg2, arg3, arg4, arg5, arg6, arg7);
return 0;
}
-EXPORT_SYMBOL(ia64_sal_oemcall);

int
ia64_sal_oemcall_nolock(struct ia64_sal_retval *isrvp, u64 oemfunc, u64 arg1,
@@ -286,17 +285,3 @@
arg7);
return 0;
}
-EXPORT_SYMBOL(ia64_sal_oemcall_nolock);
-
-int
-ia64_sal_oemcall_reentrant(struct ia64_sal_retval *isrvp, u64 oemfunc,
- u64 arg1, u64 arg2, u64 arg3, u64 arg4, u64 arg5,
- u64 arg6, u64 arg7)
-{
- if (oemfunc < IA64_SAL_OEMFUNC_MIN || oemfunc > IA64_SAL_OEMFUNC_MAX)
- return -1;
- SAL_CALL_REENTRANT(*isrvp, oemfunc, arg1, arg2, arg3, arg4, arg5, arg6,
- arg7);
- return 0;
-}
-EXPORT_SYMBOL(ia64_sal_oemcall_reentrant);

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Miles Lane]

***@Monkey100:/sys/class/i2c-adapter# ls * -l
***@Monkey100:/sys# cat */*/*/*

ksymoops 2.4.9 on i686 2.6.12-rc1-mm2. Options used
-o /lib/modules/2.6.12-rc1-mm2 (specified)
-m /boot/System.map-2.6.12-rc1-mm2 (specified)

Unable to handle kernel paging request at virtual address 24fc1024
c0198448
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c0198448>] Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210206 (2.6.12-rc1-mm2)
eax: 00000001 ebx: c039f820 ecx: 00000001 edx: 24fc1000
esi: e75b6cc4 edi: f7c015e4 ebp: e7b93e94 esp: e7b93e94
ds: 007b es: 007b ss: 0068
Stack: e7b93eb8 c0198644 f7c01694 00000000 f7c015e4 e7b93eb8 c039f820 e75b6cc4
f7c015e4 e7b93edc c0198790 f7c01694 f7c015e4 e712a000 f7c01694 e712a000
fffffff4 e7b93f10 e7b93ef8 c019884f e75b6cc4 e712a000 ffffffea e75b6cc4
Call Trace:
[<c010410f>] show_stack+0x7f/0xa0
[<c01042aa>] show_registers+0x15a/0x1c0
[<c01044ac>] die+0xfc/0x190
[<c011450b>] do_page_fault+0x31b/0x670
[<c0103cf3>] error_code+0x4f/0x54
[<c0198644>] sysfs_get_target_path+0x14/0x80
[<c0198790>] sysfs_getlink+0xe0/0x150
[<c019884f>] sysfs_follow_link+0x4f/0x60
[<c016b46f>] generic_readlink+0x2f/0x90
[<c01635b6>] sys_readlink+0x86/0x90
[<c0103249>] syscall_call+0x7/0xb
Code: 42 70 e8 a4 fc 19 00 e9 f3 fe ff ff 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 31 c0 89 e5 8b 55 08<8b>
52 24 40 85 d2 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00

EIP; c0198448 <object_depth+8/20> <=====
ebx; c039f820 <sysfs_rename_sem+0/c>
edx; 24fc1000 <phys_startup_32+24ec1000/c0000000>
esi; e75b6cc4 <pg0+270ebcc4/3fb33400>
edi; f7c015e4 <pg0+377365e4/3fb33400>
ebp; e7b93e94 <pg0+276c8e94/3fb33400>
esp; e7b93e94 <pg0+276c8e94/3fb33400>

Trace; c010410f <show_stack+7f/a0>
Trace; c01042aa <show_registers+15a/1c0>
Trace; c01044ac <die+fc/190>
Trace; c011450b <do_page_fault+31b/670>
Trace; c0103cf3 <error_code+4f/54>
Trace; c0198644 <sysfs_get_target_path+14/80>
Trace; c0198790 <sysfs_getlink+e0/150>
Trace; c019884f <sysfs_follow_link+4f/60>
Trace; c016b46f <generic_readlink+2f/90>
Trace; c01635b6 <sys_readlink+86/90>
Trace; c0103249 <syscall_call+7/b>

This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.

Code; c019841d <.text.lock.dir+d7/fa>
00000000 <_EIP>:
Code; c019841d <.text.lock.dir+d7/fa>
0: 42 inc %edx
Code; c019841e <.text.lock.dir+d8/fa>
1: 70 e8 jo ffffffeb <_EIP+0xffffffeb>
Code; c0198420 <.text.lock.dir+da/fa>
3: a4 movsb %ds:(%esi),%es:(%edi)
Code; c0198421 <.text.lock.dir+db/fa>
4: fc cld
Code; c0198422 <.text.lock.dir+dc/fa>
5: 19 00 sbb %eax,(%eax)
Code; c0198424 <.text.lock.dir+de/fa>
7: e9 f3 fe ff ff jmp fffffeff <_EIP+0xfffffeff>
Code; c0198429 <.text.lock.dir+e3/fa>
c: 90 nop
Code; c019842a <.text.lock.dir+e4/fa>
d: 90 nop
Code; c019842b <.text.lock.dir+e5/fa>
e: 90 nop
Code; c019842c <.text.lock.dir+e6/fa>
f: 90 nop
Code; c019842d <.text.lock.dir+e7/fa>
10: 90 nop
Code; c019842e <.text.lock.dir+e8/fa>
11: 90 nop
Code; c019842f <.text.lock.dir+e9/fa>
12: 90 nop
Code; c0198430 <.text.lock.dir+ea/fa>
13: 90 nop
Code; c0198431 <.text.lock.dir+eb/fa>
14: 90 nop
Code; c0198432 <.text.lock.dir+ec/fa>
15: 90 nop
Code; c0198433 <.text.lock.dir+ed/fa>
16: 90 nop
Code; c0198434 <.text.lock.dir+ee/fa>
17: 90 nop
Code; c0198435 <.text.lock.dir+ef/fa>
18: 90 nop
Code; c0198436 <.text.lock.dir+f0/fa>
19: 90 nop
Code; c0198437 <.text.lock.dir+f1/fa>
1a: 90 nop
Code; c0198438 <.text.lock.dir+f2/fa>
1b: 90 nop
Code; c0198439 <.text.lock.dir+f3/fa>
1c: 90 nop
Code; c019843a <.text.lock.dir+f4/fa>
1d: 90 nop
Code; c019843b <.text.lock.dir+f5/fa>
1e: 90 nop
Code; c019843c <.text.lock.dir+f6/fa>
1f: 90 nop
Code; c019843d <.text.lock.dir+f7/fa>
20: 90 nop
Code; c019843e <.text.lock.dir+f/60>
Trace; c01681de <__link_path_walk+8ce/ec0>
Trace; c016885f <link_path_walk+8f/190>
Trace; c0168c45 <path_lookup+95/170>
Trace; c01693ef <open_namei+7f/650>
Trace; c015823c <filp_open+3c/60>
Trace; c01586e8 <sys_open+48/d0>
Trace; c0103249 <syscall_call+7/b>

This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.

Code; c019841d <.text.lock.dir+d7/fa>
00000000 <_EIP>:
Code; c019841d <.text.lock.dir+d7/fa>
0: 42 inc %edx
Code; c019841e <.text.lock.dir+d8/fa>
1: 70 e8 jo ffffffeb <_EIP+0xffffffeb>
Code; c0198420 <.text.lock.dir+da/fa>
3: a4 movsb %ds:(%esi),%es:(%

----------------------------------------------

<1>Unable to handle kernel paging request at virtual address 36bc3024
c0198448
*pde = 00000000
Oops: 0000 [#6]
CPU: 0
EIP: 0060:[<c0198448>] Not tainted VLI
EFLAGS: 00210206 (2.6.12-rc1-mm2)
eax: 00000001 ebx: c039f820 ecx: 00000001 edx: 36bc3000
esi: e75b6cc4 edi: f7c015e4 ebp: e3423dc4 esp: e3423dc4
ds: 007b es: 007b ss: 0068
Stack: e3423de8 c0198644 f7c01694 00000000 f7c015e4 e3423de8 c039f820 e75b6cc4
f7c015e4 e3423e0c c0198790 f7c01694 f7c015e4 e02fe000 f7c01694 e02fe000
fffffff4 e3423f50 e3423e28 c019884f e75b6cc4 e02fe000 e3423e64 e3422000
Call Trace:
[<c010410f>] show_stack+0x7f/0xa0
[<c01042aa>] show_registers+0x15a/0x1c0
[<c01044ac>] die+0xfc/0x190
[<c011450b>] do_page_fault+0x31b/0x670
[<c0103cf3>] error_code+0x4f/0x54
[<c0198644>] sysfs_get_target_path+0x14/0x80
[<c0198790>] sysfs_getlink+0xe0/0x150
[<c019884f>] sysfs_follow_link+0x4f/0x60
[<c01681de>] __link_path_walk+0x8ce/0xec0
[<c016885f>] link_path_walk+0x8f/0x190
[<c0168c45>] path_lookup+0x95/0x170
[<c01693ef>] open_namei+0x7f/0x650
[<c015823c>] filp_open+0x3c/0x60
[<c01586e8>] sys_open+0x48/0xd0
[<c0103249>] syscall_call+0x7/0xb
Code: 42 70 e8 a4 fc 19 00 e9 f3 fe ff ff 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 31 c0 89 e5 8b 55 08<8b>
52 24 40 85 d2 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00

EIP; c0198448 <object_depth+8/20> <=====
ebx; c039f820 <sysfs_rename_sem+0/c>
edx; 36bc3000 <phys_startup_32+36ac3000/c0000000>
esi; e75b6cc4 <pg0+270ebcc4/3fb33400>
edi; f7c015e4 <pg0+377365e4/3fb33400>
ebp; e3423dc4 <pg0+22f58dc4/3fb33400>
esp; e3423dc4 <pg0+22f58dc4/3fb33400>

Trace; c010410f <show_stack+7f/a0>
Trace; c01042aa <show_registers+15a/1c0>
Trace; c01044ac <die+fc/190>
Trace; c011450b <do_page_fault+31b/670>
Trace; c0103cf3 <error_code+4f/54>
Trace; c0198644 <sysfs_get_target_path+14/80>
Trace; c0198790 <sysfs_getlink+e0/150>
Trace; c019884f <sysfs_follow_link+4f/60>
Trace; c01681de <__link_path_walk+8ce/ec0>
Trace; c016885f <link_path_walk+8f/190>
Trace; c0168c45 <path_lookup+95/170>
Trace; c01693ef <open_namei+7f/650>
Trace; c015823c <filp_open+3c/60>
Trace; c01586e8 <sys_open+48/d0>
Trace; c0103249 <syscall_call+7/b>

This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.

Code; c019841d <.text.lock.dir+d7/fa>
00000000 <_EIP>:
Code; c019841d <.text.lock.dir+d7/fa>
0: 42 inc %edx
Code; c019841e <.text.lock.dir+d8/fa>
1: 70 e8 jo ffffffeb <_EIP+0xffffffeb>
Code; c0198420 <.text.lock.dir+da/fa>
3: a4 movsb %ds:(%esi),%es:(%edi)
Code; c0198421 <.text.lock.dir+db/fa>
4: fc cld
Code; c0198422 <.text.lock.dir+dc/fa>
5: 19 00 sbb %eax,(%eax)
Code; c0198424 <.text.lock.dir+de/fa>
7: e9 f3 fe ff ff jmp fffffeff
<_EIP+0xfffftext.lock.dir+f1/fa>
1a: 90 nop
Code; c0198438 <.text.lock.dir+f2/fa>
1b: 90 nop
Code; c0198439 <.text.lock.dir+f3/fa>
1c: 90 nop
Code; c019843a <.text.lock.dir+f4/fa>
1d: 90 nop
Code; c019843b <.text.lock.dir+f5/fa>
1e: 90 nop
Code; c019843c <.text.lock.dir+f6/fa>
1f: 90 nop
Code; c019843d <.text.lock.dir+f7/fa>
20: 90 nop
Code; c019843e <.text.lock.dir+f8/fa>
21: 90 nop
Code; c019843f <.text.lock.dir+f9/fa>
22: 90 nop
Code; c0198440 <object_depth+0/20>
23: 55 push %ebp
Code; c0198441 <object_depth+1/20>
24: 31 c0 xor %eax,%eax
Code; c0198443 <object_depth+3/20>
26: 89 e5 mov %esp,%ebp
Code; c0198445 <object_depth+5/20>
28: 8b 55 08 mov 0x8(%ebp),%edx

This decode from eip onwards should be reliable

Code; c0198448 <object_depth+8/20>
00000000 <_EIP>:
Code; c0198448 <object_depth+8/20> <=====
0: 8b 52 24 mov 0x24(%edx),%edx <=====
Code; c019844b <object_depth+b/20>
3: 40 inc %eax
Code; c019844c <object_depth+c/20>
4: 85 d2 test %edx,%edx
Code; c019844e <object_depth+e/20>
6: 75 f8 jne 0 <_EIP>
Code; c0198450 <object_depth+10/20>
8: c9 leave
Code; c0198451 <object_depth+11/20>
9: c3 ret
Code; c0198452 <object_depth+12/20>
a: 8d b4 26 00 00 00 00 lea 0x0(%esi),%esi
Code; c0198459 <object_depth+19/20>
11: 8d .byte 0x8d
Code; c019845a <object_depth+1a/20>
12: bc .byte 0xbc
Code; c019845b <object_depth+1b/20>
13: 27 daa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Andrew Morton]

Post by Miles Lane
ksymoops 2.4.9 on i686 2.6.12-rc1-mm2. Options used
-o /lib/modules/2.6.12-rc1-mm2 (specified)
-m /boot/System.map-2.6.12-rc1-mm2 (specified)
Unable to handle kernel paging request at virtual address 24fc1024
c0198448
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c0198448>] Not tainted VLI

I wonder why the EIP sometimes doesn't get decoded.

Post by Miles Lane
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210206 (2.6.12-rc1-mm2)
eax: 00000001 ebx: c039f820 ecx: 00000001 edx: 24fc1000
esi: e75b6cc4 edi: f7c015e4 ebp: e7b93e94 esp: e7b93e94
ds: 007b es: 007b ss: 0068
Stack: e7b93eb8 c0198644 f7c01694 00000000 f7c015e4 e7b93eb8 c039f820 e75b6cc4
f7c015e4 e7b93edc c0198790 f7c01694 f7c015e4 e712a000 f7c01694 e712a000
fffffff4 e7b93f10 e7b93ef8 c019884f e75b6cc4 e712a000 ffffffea e75b6cc4
[<c010410f>] show_stack+0x7f/0xa0
[<c01042aa>] show_registers+0x15a/0x1c0
[<c01044ac>] die+0xfc/0x190
[<c011450b>] do_page_fault+0x31b/0x670
[<c0103cf3>] error_code+0x4f/0x54
[<c0198644>] sysfs_get_target_path+0x14/0x80
[<c0198790>] sysfs_getlink+0xe0/0x150
[<c019884f>] sysfs_follow_link+0x4f/0x60
[<c016b46f>] generic_readlink+0x2f/0x90
[<c01635b6>] sys_readlink+0x86/0x90
[<c0103249>] syscall_call+0x7/0xb
Code: 42 70 e8 a4 fc 19 00 e9 f3 fe ff ff 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 31 c0 89 e5 8b 55 08<8b>
52 24 40 85 d2 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00

EIP; c0198448 <object_depth+8/20> <=====

I can't repeat it here. Are you able to narrow it down to a specific sysfs
file?

The .config might help.

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Andrew Morton]

Post by Andrew Morton

Post by Miles Lane
Unable to handle kernel paging request at virtual address 24fc1024
c0198448
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c0198448>] Not tainted VLI

I wonder why the EIP sometimes doesn't get decoded.

Post by Miles Lane
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210206 (2.6.12-rc1-mm2)

ksymoops seems to remove lines from the kernel output that it doesn't
like.

but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you
saying that ksymoops rubbed that out and stuck a hex number in there?

I've seen this many times on ARM, and each time I see an oops
from a 2.6 kernel which has been ksymoopsed, I always ask the submitter
to send the original non-ksymoopsed version.
Users need to be re-educated _not_ to use ksymoops.

I wonder if there's something clever we could do to the kallsymsised oops
output so that ksymoops would simply cease to recognise it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Russell King]

Post by Andrew Morton

Post by Andrew Morton

Post by Miles Lane
Unable to handle kernel paging request at virtual address 24fc1024
c0198448
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c0198448>] Not tainted VLI

I wonder why the EIP sometimes doesn't get decoded.

Post by Miles Lane
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210206 (2.6.12-rc1-mm2)

ksymoops seems to remove lines from the kernel output that it doesn't
like.

but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you
saying that ksymoops rubbed that out and stuck a hex number in there?

The kernel's x86 format is:

printk("EIP: %04x:[<%08lx>] CPU: %d\n",0xffff & regs->xcs,regs->eip, smp_processor_id());
print_symbol("EIP is at %s\n", regs->eip);

so what you have there is the first EIP: line. The "EIP is at
symbol+0xN/0xM" is produced by the print_symbol statement, which
ksymoops decided to omit from the output.

It can be clearly seen from the rest of the oops (the call trace)
that print_symbol definitely does produce output, so kallsyms hasn't
been disabled.

Post by Andrew Morton
I wonder if there's something clever we could do to the kallsymsised oops
output so that ksymoops would simply cease to recognise it.

I have been wondering why we still mark the addresses with [< >]
even though we've decoded them ourselves. Maybe omitting these
would be sufficient in the kallsyms-decoded case?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Russell King]

Post by Russell King

Post by Andrew Morton

Post by Andrew Morton

Post by Miles Lane
Unable to handle kernel paging request at virtual address 24fc1024
c0198448
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c0198448>] Not tainted VLI

I wonder why the EIP sometimes doesn't get decoded.

Post by Miles Lane
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210206 (2.6.12-rc1-mm2)

ksymoops seems to remove lines from the kernel output that it doesn't
like.

but. but. There used to be a symbol+0xN/0xM in the EIP: line. Are you
saying that ksymoops rubbed that out and stuck a hex number in there?

printk("EIP: %04x:[<%08lx>] CPU: %d\n",0xffff & regs->xcs,regs->eip, smp_processor_id());
print_symbol("EIP is at %s\n", regs->eip);

Argh, wrong one, it's supposed to be:

print_modules();
printk("CPU: %d\nEIP: %04x:[<%08lx>] %s VLI\nEFLAGS: %08lx"
" (%s) \n",
smp_processor_id(), 0xffff & regs->xcs, regs->eip,
print_tainted(), regs->eflags, system_utsname.release);
print_symbol("EIP is at %s\n", regs->eip);

but the result is the same. Also note that the modules line is also
missing from the posted oops.

(Why does x86 duplicate the register dumping between process.c and
traps.c ?)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Miles Lane]

Ahem. In this case, I think it was operator error. I reproduced the
problem and have included the entire output of ksymoops below.

Andrew, this command causes the Oops for me:

***@Monkey100:/sys/class/i2c-adapter/i2c-1# ls
./ ../ device@
***@Monkey100:/sys/class/i2c-adapter/i2c-1# ls -l
Segmentation fault

***@Monkey100:/sys/class/i2c-adapter/i2c-1# dmesg|ksymoops -o
/lib/modules/2.6.12-rc1-mm2 -m /boot/System.map-2.6.12-rc1-mm2
ksymoops 2.4.9 on i686 2.6.12-rc1-mm2. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.6.12-rc1-mm2 (specified)
-m /boot/System.map-2.6.12-rc1-mm2 (specified)

Error (regular_file): read_ksyms stat /proc/ksyms failed
ksymoops: No such file or directory
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
[<c010414e>] dump_stack+0x1e/0x20
[<c01f0b12>] kref_get+0x42/0x50
[<c01f005b>] kobject_get+0x1b/0x30
[<c01986f1>] sysfs_getlink+0x41/0x150
[<c019884f>] sysfs_follow_link+0x4f/0x60
[<c016b46f>] generic_readlink+0x2f/0x90
[<c01635b6>] sys_readlink+0x86/0x90
[<c0103249>] syscall_call+0x7/0xb
[<c010414e>] dump_stack+0x1e/0x20
[<c01f0b12>] kref_get+0x42/0x50
[<c01f005b>] kobject_get+0x1b/0x30
[<c019874d>] sysfs_getlink+0x9d/0x150
[<c019884f>] sysfs_follow_link+0x4f/0x60
[<c016b46f>] generic_readlink+0x2f/0x90
[<c01635b6>] sys_readlink+0x86/0x90
[<c0103249>] syscall_call+0x7/0xb
Unable to handle kernel paging request at virtual address 00001000
c0198479
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c0198479>] Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210246 (2.6.12-rc1-mm2)
eax: 00000000 ebx: 00000000 ecx: ffffffff edx: f7c0181c
esi: 00000001 edi: 00001000 ebp: e7519e94 esp: e7519e88
ds: 007b es: 007b ss: 0068
Stack: 00000002 e4fdea1c f7c0181c e7519eb8 c0198651 f7c0181c 00000020 f7c0181c
e7519eb8 c039f820 e4fdea1c f7c0181c e7519edc c0198790 f7c018cc f7c0181c
e46a3000 f7c018cc e46a3000 fffffff4 e7519f10 e7519ef8 c019884f e4fdea1c
Call Trace:
[<c010410f>] show_stack+0x7f/0xa0
[<c01042aa>] show_registers+0x15a/0x1c0
[<c01044ac>] die+0xfc/0x190
[<c011450b>] do_page_fault+0x31b/0x670
[<c0103cf3>] error_code+0x4f/0x54
[<c0198651>] sysfs_get_target_path+0x21/0x80
[<c0198790>] sysfs_getlink+0xe0/0x150
[<c019884f>] sysfs_follow_link+0x4f/0x60
[<c016b46f>] generic_readlink+0x2f/0x90
[<c01635b6>] sys_readlink+0x86/0x90
[<c0103249>] syscall_call+0x7/0xb
Code: 75 f8 c9 c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5
57 56 8b 55 08 be 01 00 00 00 53 31 db 8b 3a b9 ff ff ff ff 89 d8<f2>
ae f7 d1 49 8b 52 24 8d 74 31 01 85 d2 75 e7 5b 89 f0 5e 5f

EIP; c0198479 <object_path_length+19/30> <=====
ecx; ffffffff <__kernel_rt_sigreturn+1bbf/????>
edx; f7c0181c <pg0+3773581c/3fb32400>
ebp; e7519e94 <pg0+2704de94/3fb32400>
esp; e7519e88 <pg0+2704de88/3fb32400>

Trace; c010410f <show_stack+7f/a0>
Trace; c01042aa <show_registers+15a/1c0>
Trace; c01044ac <die+fc/190>
Trace; c011450b <do_page_fault+31b/670>
Trace; c0103cf3 <error_code+4f/54>
Trace; c0198651 <sysfs_get_target_path+21/80>
Trace; c0198790 <sysfs_getlink+e0/150>
Trace; c019884f <sysfs_follow_link+4f/60>
Trace; c016b46f <generic_readlink+2f/90>
Trace; c01635b6 <sys_readlink+86/90>
Trace; c0103249 <syscall_call+7/b>

This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.

Code; c019844e <object_depth+e/20>
00000000 <_EIP>:
Code; c019844e <object_depth+e/20>
0: 75 f8 jne fffffffa <_EIP+0xfffffffa>
Code; c0198450 <object_depth+10/20>
2: c9 leave
Code; c0198451 <object_depth+11/20>
3: c3 ret
Code; c0198452 <object_depth+12/20>
4: 8d b4 26 00 00 00 00 lea 0x0(%esi),%esi
Code; c0198459 <object_depth+19/20>
b: 8d bc 27 00 00 00 00 lea 0x0(%edi),%edi
Code; c0198460 <object_path_length+0/30>
12: 55 push %ebp
Code; c0198461 <object_path_length+1/30>
13: 89 e5 mov %esp,%ebp
Code; c0198463 <object_path_length+3/30>
15: 57 push %edi
Code; c0198464 <object_path_length+4/30>
16: 56 push %esi
Code; c0198465 <object_path_length+5/30>
17: 8b 55 08 mov 0x8(%ebp),%edx
Code; c0198468 <object_path_length+8/30>
1a: be 01 00 00 00 mov $0x1,%esi
Code; c019846d <object_path_length+d/30>
1f: 53 push %ebx
Code; c019846e <object_path_length+e/30>
20: 31 db xor %ebx,%ebx
Code; c0198470 <object_path_length+10/30>
22: 8b 3a mov (%edx),%edi
Code; c0198472 <object_path_length+12/30>
24: b9 ff ff ff ff mov $0xffffffff,%ecx
Code; c0198477 <object_path_length+17/30>
29: 89 d8 mov %ebx,%eax

This decode from eip onwards should be reliable

Code; c0198479 <object_path_length+19/30>
00000000 <_EIP>:
Code; c0198479 <object_path_length+19/30> <=====
0: f2 ae repnz scas %es:(%edi),%al <=====
Code; c019847b <object_path_length+1b/30>
2: f7 d1 not %ecx
Code; c019847d <object_path_length+1d/30>
4: 49 dec %ecx
Code; c019847e <object_path_length+1e/30>
5: 8b 52 24 mov 0x24(%edx),%edx
Code; c0198481 <object_path_length+21/30>
8: 8d 74 31 01 lea 0x1(%ecx,%esi,1),%esi
Code; c0198485 <object_path_length+25/30>
c: 85 d2 test %edx,%edx
Code; c0198487 <object_path_length+27/30>
e: 75 e7 jne fffffff7 <_EIP+0xfffffff7>
Code; c0198489 <object_path_length+29/30>
10: 5b pop %ebx
Code; c019848a <object_path_length+2a/30>
11: 89 f0 mov %esi,%eax
Code; c019848c <object_path_length+2c/30>
13: 5e pop %esi
Code; c019848d <object_path_length+2d/30>
14: 5f pop %edi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Andrew Morton]

Post by Miles Lane
Ahem. In this case, I think it was operator error. I reproduced the
problem and have included the entire output of ksymoops below.

Please don't use ksymoops. 2.6 kernels decode oopses internally and
ksymoops actually removes a little info.

Post by Miles Lane
Segmentation fault

What device is that, and which driver is handling it?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Jean Delvare]

Hi Andrew, Miles,

Post by Andrew Morton

Post by Miles Lane
Segmentation fault

What device is that, and which driver is handling it?

If I am allowed a wild guess here... Isn't by any chance i2c-1 one the
the 3 i2c adapters exported by the nvidiafb driver, which we know isn't
playing nicely with the i2c core? To me, it is simply a different
expression of the same bug Miles hit some days ago when loading the
i2c-dev or eeprom modules [1].

Miles, do you have the same problem with i2c-0 and i2c-2, or only i2c-1?

Can you please confirm that with CONFIG_FB_NVIDIA_I2C unset, the oops
vanishes?

[1] http://archives.andrew.net.au/lm-sensors/msg29974.html

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Miles Lane]

Post by Jean Delvare

Post by Andrew Morton

Post by Miles Lane
Segmentation fault

What device is that, and which driver is handling it?

If I am allowed a wild guess here... Isn't by any chance i2c-1 one the
the 3 i2c adapters exported by the nvidiafb driver, which we know isn't
playing nicely with the i2c core? To me, it is simply a different
expression of the same bug Miles hit some days ago when loading the
i2c-dev or eeprom modules [1].

You are exactly right. The /sys issues had to do with i2c stuff
associated the nvidiafb driver.

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Russell King]

Post by Andrew Morton

Post by Miles Lane
Unable to handle kernel paging request at virtual address 24fc1024
c0198448
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c0198448>] Not tainted VLI

I wonder why the EIP sometimes doesn't get decoded.

Post by Miles Lane
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210206 (2.6.12-rc1-mm2)

ksymoops seems to remove lines from the kernel output that it doesn't
like. I've seen this many times on ARM, and each time I see an oops
from a 2.6 kernel which has been ksymoopsed, I always ask the submitter
to send the original non-ksymoopsed version.

Users need to be re-educated _not_ to use ksymoops.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Lee Revell]

Users need to be re-educated _not_ to use ksymoops.

How about changing the fscking docs to not tell users to use it?

Seems like lots of stuff in Documentation/ is stuck in 2.4 land. How
about purging it? Incorrect docs are worse than nothing.

Lee

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Lee Revell]

Post by Lee Revell

Users need to be re-educated _not_ to use ksymoops.

How about changing the fscking docs to not tell users to use it?

Would be useful. The "fscking" problem is that no one actually owns the
documents, so there's no central focus to keep them up to date.

Are you serious? So Documentation/sound/alsa/* isn't maintained by the
ALSA maintainers?

Last I checked, Documentation/oops-tracking.txt wasn't under
Documentation/sound/alsa. It seems obvious to me, but maybe it isn't
obvious to others, as your message appears to suggest.

No, I just misread your message as "none of the docs are maintained"
rather than "oops-tracking.txt is not maintained".

As far as the question of ALSA documentation being up to date, that's
one set of directories in the kernel tree I've _never_ looked at, so
can't comment. Sorry.

The ALSA docs are in fact up to date.

Lee

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Russell King]

Post by Lee Revell

Users need to be re-educated _not_ to use ksymoops.

How about changing the fscking docs to not tell users to use it?

Would be useful. The "fscking" problem is that no one actually owns the
documents, so there's no central focus to keep them up to date.

Are you serious? So Documentation/sound/alsa/* isn't maintained by the
ALSA maintainers?

Last I checked, Documentation/oops-tracking.txt wasn't under
Documentation/sound/alsa. It seems obvious to me, but maybe it isn't
obvious to others, as your message appears to suggest.

As far as the question of ALSA documentation being up to date, that's
one set of directories in the kernel tree I've _never_ looked at, so
can't comment. Sorry.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Lee Revell]

Post by Lee Revell

Users need to be re-educated _not_ to use ksymoops.

How about changing the fscking docs to not tell users to use it?

Would be useful. The "fscking" problem is that no one actually owns the
documents, so there's no central focus to keep them up to date.

Are you serious? So Documentation/sound/alsa/* isn't maintained by the
ALSA maintainers?

Wow, this would explain why all Linux documentation is at least 2 years
out of date.

Maybe we need a docfsck? 8)
I certainly don't have authority to tell x86 people not to use ksymoops.
Therefore, I think my suggested change (which up until recently I thought
was an ARM only problem) should be done by someone else.

At least from my experience, ksymoops is useless on x86 for 2.6 kernels.
Here is a patch to finally bring oops-tracing.txt into the 2.6 era. :-P

Sugned-Off-By: Lee Revell <***@joe-job.com>

Lee

--- Documentation/oops-tracing.txt~ 2005-03-17 20:34:06.000000000 -0500
+++ Documentation/oops-tracing.txt 2005-03-25 16:41:07.000000000 -0500
@@ -1,23 +1,22 @@
+NOTE: ksymoops is useless on 2.6. Please use the Oops in its original format
+(from dmesg, etc). Ignore any references in this or other docs to "decoding
+the Oops" or "running it through ksymoops". If you post an Oops fron 2.6 that
+has been run through ksymoops, people will just tell you to repost it.
+
Quick Summary
-------------

-Install ksymoops from
-ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops
-Read the ksymoops man page.
-ksymoops < the_oops.txt
-
-and send the output the maintainer of the kernel area that seems to be
-involved with the problem, not to the ksymoops maintainer. Don't worry
-too much about getting the wrong person. If you are unsure send it to
-the person responsible for the code relevant to what you were doing.
-If it occurs repeatably try and describe how to recreate it. Thats
-worth even more than the oops
+Find the Oops and send it to the maintainer of the kernel area that seems to be
+involved with the problem. Don't worry too much about getting the wrong person.
+If you are unsure send it to the person responsible for the code relevant to
+what you were doing. If it occurs repeatably try and describe how to recreate
+it. That's worth even more than the oops.

If you are totally stumped as to whom to send the report, send it to
linux-***@vger.kernel.org. Thanks for your help in making Linux as
stable as humanly possible.

-Where is the_oops.txt?
+Where is the Oops?
----------------------

Normally the Oops text is read from the kernel buffers by klogd and
@@ -43,15 +42,14 @@
them yourself. Search kernel archives for kmsgdump, lkcd and
oops+smram.

-No matter how you capture the log output, feed the resulting file to
-ksymoops along with /proc/ksyms and /proc/modules that applied at the
-time of the crash. /var/log/ksymoops can be useful to capture the
-latter, man ksymoops for details.
-

Full Information
----------------

+NOTE: the message from Linus below applies to 2.4 kernel. I have preserved it
+for historical reasons, and because some of the information in it still
+applies. Especially, please ignore any references to ksymoops.
+
From: Linus Torvalds <***@osdl.org>

How to track down an Oops.. [originally a mail to linux-kernel]

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Russell King]

Post by Lee Revell

Users need to be re-educated _not_ to use ksymoops.

How about changing the fscking docs to not tell users to use it?

Would be useful. The "fscking" problem is that no one actually owns the
documents, so there's no central focus to keep them up to date.

Maybe we need a docfsck? 8)

I certainly don't have authority to tell x86 people not to use ksymoops.
Therefore, I think my suggested change (which up until recently I thought
was an ARM only problem) should be done by someone else.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Christophe Saout]

Hi,

+x86_64-fix-config_preempt.patch
x86_64-fix-config_preempt.patch
x86_64: Fix CONFIG_PREEMPT

Has this one been stress-tested?

I've got the impression that things have become a lot worse.

I've been seeing things like these:

Mar 25 01:00:48 websrv2 REISERFS: panic (device dm-1): clm-6000: do_balance, fs generation has changed
Mar 25 01:00:48 websrv2
Mar 25 01:00:48 websrv2 ----------- [cut here ] --------- [please bite here ] ---------
Mar 25 01:00:48 websrv2 Kernel BUG at prints:362
Mar 25 01:00:48 websrv2 invalid operand: 0000 [1] PREEMPT
Mar 25 01:00:48 websrv2 CPU 0
Mar 25 01:00:48 websrv2 Modules linked in: iptable_nat ipt_MARK iptable_mangle ipt_LOG ipt_multiport ipt_owner ipt_mark ipt_state ipt_REJECT iptable_filter ip_tables twofish serpent blowfish ext3 jbd reiser4 sha256 aes dm_crypt ip_conntrack_irc ip_conntrack_ftp ip_conntrack via_rhine 8139too crc32
Mar 25 01:00:48 websrv2 Pid: 25172, comm: rm Not tainted 2.6.12-rc1-cs1
Mar 25 01:00:48 websrv2 RIP: 0010:[<ffffffff801cfe13>] <ffffffff801cfe13>{reiserfs_panic+211}
Mar 25 01:00:48 websrv2 RSP: 0018:ffff81001efe37b8 EFLAGS: 00010292
Mar 25 01:00:48 websrv2 RAX: 0000000000000059 RBX: ffffffff803fbcac RCX: 00000000c0000100
Mar 25 01:00:48 websrv2 RDX: 0000000000000000 RSI: ffff81007d0b31f0 RDI: 00000000ffffffff
Mar 25 01:00:48 websrv2 RBP: ffff81004f960060 R08: ffff81001efe2000 R09: 0000000000000002
Mar 25 01:00:48 websrv2 R10: 00000000ffffffff R11: ffffffff80340ef0 R12: ffff81007f850230
Mar 25 01:00:48 websrv2 R13: ffff81007f850000 R14: 0000000000000000 R15: ffff81004f9565d0
Mar 25 01:00:48 websrv2 FS: 00002aaaaaabaae0(0000) GS:ffffffff805be800(0000) knlGS:0000000055563dc0
Mar 25 01:00:48 websrv2 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Mar 25 01:00:48 websrv2 CR2: 00002aaaaaaff008 CR3: 000000001ebbd000 CR4: 00000000000006e0
Mar 25 01:00:48 websrv2 Process rm (pid: 25172, threadinfo ffff81001efe2000, task ffff81007d0b31f0)
Mar 25 01:00:48 websrv2 Stack: 0000003000000010 ffff81001efe38a8 ffff81001efe37d8 ffff81001c041530
Mar 25 01:00:48 websrv2 ffff81001efe39d8 ffffffff801d4e42 ffff81007e659a00 0000000000000063
Mar 25 01:00:48 websrv2 0000000000000063 0000000000000000
Mar 25 01:00:48 websrv2 Call Trace:<ffffffff801d4e42>{pathrelse_and_restore+66} <ffffffff8010efe6>{retint_kernel+46}
Mar 25 01:00:48 websrv2 <ffffffff801bb847>{do_balance+39} <ffffffff801bd315>{do_balance+6901}
Mar 25 01:00:48 websrv2 <ffffffff801cbd90>{unfix_nodes+128} <ffffffff801be15b>{do_balance+10555}
Mar 25 01:00:48 websrv2 <ffffffff801d7bf9>{reiserfs_cut_from_item+1673} <ffffffff801bfcfa>{reiserfs_unlink+362}
Mar 25 01:00:48 websrv2 <ffffffff801873ae>{vfs_unlink+462} <ffffffff801874f9>{sys_unlink+233}
Mar 25 01:00:48 websrv2 <ffffffff8018a268>{sys_getdents+232} <ffffffff8010f221>{error_exit+0}
Mar 25 01:00:48 websrv2 <ffffffff8010e906>{system_call+126}
Mar 25 01:00:48 websrv2
Mar 25 01:00:48 websrv2 Code: 0f 0b b8 c1 3f 80 ff ff ff ff 6a 01 4d 85 ed 48 c7 c2 40 ba
Mar 25 01:00:48 websrv2 RIP <ffffffff801cfe13>{reiserfs_panic+211} RSP <ffff81001efe37b8>

or

Mar 25 16:39:21 websrv2 VFS: brelse: Trying to free free buffer
Mar 25 16:39:21 websrv2 Badness in __brelse at fs/buffer.c:1295
Mar 25 16:39:21 websrv2
Mar 25 16:39:21 websrv2 Call Trace:<ffffffff8017787f>{__find_get_block+479} <ffffffff8017a175>{__getblk+37}
Mar 25 16:39:21 websrv2 <ffffffff801de3d5>{do_journal_end+2181} <ffffffff80147d70>{keventd_create_kthread+0}
Mar 25 16:39:21 websrv2 <ffffffff801cbf50>{reiserfs_sync_fs+64} <ffffffff8017c0b3>{sync_supers+211}
Mar 25 16:39:21 websrv2 <ffffffff8015a22a>{wb_kupdate+42} <ffffffff8015ae8f>{pdflush+399}
Mar 25 16:39:21 websrv2 <ffffffff8015a200>{wb_kupdate+0} <ffffffff80147d70>{keventd_create_kthread+0}
Mar 25 16:39:21 websrv2 <ffffffff8015ad00>{pdflush+0} <ffffffff80147d2d>{kthread+205}
Mar 25 16:39:21 websrv2 <ffffffff8010f3d7>{child_rip+8} <ffffffff80147d70>{keventd_create_kthread+0}
Mar 25 16:39:21 websrv2 <ffffffff80147c60>{kthread+0} <ffffffff8010f3cf>{child_rip+0}

Fortunately the kernel locked up and there was no data corruption.

I've got PREEMPT and PREEMPT_BKL enabled under UP.

I just took a look at the change and found this:

x86-64 does this (in entry.S):

bt $9,EFLAGS-ARGOFFSET(%rsp) /* interrupts off? */
jnc retint_restore_args
movl $PREEMPT_ACTIVE,threadinfo_preempt_count(%rcx)
sti
call schedule
cli
GET_THREAD_INFO(%rcx)
movl $0,threadinfo_preempt_count(%rcx)
jmp exit_intr

while i386 does this:

testl $IF_MASK,EFLAGS(%esp) # interrupts off (exception path) ?
jz restore_all
call preempt_schedule_irq
jmp need_resched

preempt_schedule_irq is not an i386 specific function and seems to take
special care of BKL preemption and since reiserfs does use the BKL to do
certain things I think this actually might be the problem...?

I'm not saying that this fix is wrong (it is obviously the right fix)
but it causes another problem to show up.

Unfortunately I don't have a amd64 machine to play with, so can somebody
please check this?

[Christophe Saout]

Hi,

x86_64-fix-config_preempt.patch
x86_64: Fix CONFIG_PREEMPT

This patch causes another bug to show up some lines below with
CONFIG_PREEMPT_BKL. schedule releases the BKL which it shouldn't do.

Call preempt_schedule_irq instead (like for i386). This seems to fix the
easily reproducible filesystem errors I've seen (with reiserfs, which
heavily relies on the BKL).

Signed-off-by: Christophe Saout <***@saout.de>

--- linux-2.6.12-rc1-mm2.orig/arch/x86_64/kernel/entry.S 2005-03-24 17:32:22.000000000 +0100
+++ linux-2.6.12-rc1-mm2/arch/x86_64/kernel/entry.S 2005-03-26 23:40:30.000000000 +0100
@@ -517,12 +517,7 @@
jnc retint_restore_args
bt $9,EFLAGS-ARGOFFSET(%rsp) /* interrupts off? */
jnc retint_restore_args
- movl $PREEMPT_ACTIVE,threadinfo_preempt_count(%rcx)
- sti
- call schedule
- cli
- GET_THREAD_INFO(%rcx)
- movl $0,threadinfo_preempt_count(%rcx)
+ call preempt_schedule_irq
jmp exit_intr
#endif
CFI_ENDPROC

[Andi Kleen]

Post by Christophe Saout
Hi,

x86_64-fix-config_preempt.patch
x86_64: Fix CONFIG_PREEMPT

This patch causes another bug to show up some lines below with
CONFIG_PREEMPT_BKL. schedule releases the BKL which it shouldn't do.
Call preempt_schedule_irq instead (like for i386). This seems to fix the
easily reproducible filesystem errors I've seen (with reiserfs, which
heavily relies on the BKL).

I would not apply this one for now. It needs checking if the
patch that requires this change does not require more changes.

-Andi

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Andi Kleen]

Post by Christophe Saout
Fortunately the kernel locked up and there was no data corruption.
I've got PREEMPT and PREEMPT_BKL enabled under UP.
bt $9,EFLAGS-ARGOFFSET(%rsp) /* interrupts off? */
jnc retint_restore_args
movl $PREEMPT_ACTIVE,threadinfo_preempt_count(%rcx)
sti
call schedule
cli
GET_THREAD_INFO(%rcx)
movl $0,threadinfo_preempt_count(%rcx)
jmp exit_intr
testl $IF_MASK,EFLAGS(%esp) # interrupts off (exception path) ?
jz restore_all
call preempt_schedule_irq
jmp need_resched
preempt_schedule_irq is not an i386 specific function and seems to take
special care of BKL preemption and since reiserfs does use the BKL to do
certain things I think this actually might be the problem...?

Hmm, preempt_schedule_irq is not in mainline as far as I can see.
My patches are always for mainline; i dont do a special
patch kit for -mm*

It looks like a unfortunate interaction with some other patches
in mm. Andrew, can you disable CONFIG_PREEMPT on x86-64 in
mm for now?

Just calling preempt_schedule_irq may also work,
but most likely the patch that introduces that function needs
careful reading if it does not require more support from architectures.
BTW I suspect it will break other archs too...

Post by Christophe Saout
Unfortunately I don't have a amd64 machine to play with, so can somebody
please check this?

How did you generate the crash dumps above then?

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Christophe Saout]

Post by Andi Kleen

Post by Christophe Saout
preempt_schedule_irq is not an i386 specific function and seems to take
special care of BKL preemption and since reiserfs does use the BKL to do
certain things I think this actually might be the problem...?

Hmm, preempt_schedule_irq is not in mainline as far as I can see.
My patches are always for mainline; i dont do a special
patch kit for -mm*

PREEMPT_BKL has been in mainline since 2.6.11-rc1, preempt_schedule_irq
made it in 2.6.11-rc3. Please look here:
http://linux.bkbits.net:8080/linux-2.6/search/?expr=preempt_schedule_irq&search=ChangeSet+comments

For i386 the first change was to switch to preempt_schedule in this code
path: http://linux.bkbits.net:8080/linux-2.6/***@1.1966.39.63

preempt_schedule takes care of setting PREEMPT_ACTIVE and resetting it
afterwards, so I removed that from the assembler code.

Then preempt_schedule_irq has been introduced to move the sti/cli back
around the call to schedule:
http://linux.bkbits.net:8080/linux-2.6/***@1.1982.28.91

So in the end the only thing that the patch I proposed was doing is to
*additionally* handle the PREEMPT_BKL case so that schedule doesn't
accidentally release the BKL semaphore when it shouldn't because we are
preempting and nobody explicitly called schedule.

Several other archs have done the same. No bug has shown up until the
recent -mm kernel where the execution of this code path actually became
possible (the "jc -> jnc" fix some lines above).

Post by Andi Kleen
It looks like a unfortunate interaction with some other patches
in mm. Andrew, can you disable CONFIG_PREEMPT on x86-64 in
mm for now?

These things are in 2.6.11 (except that they never got called because of
the wrong interrupt flag check in the IRQ handler).

Post by Andi Kleen

Post by Christophe Saout
Unfortunately I don't have a amd64 machine to play with, so can somebody
please check this?

How did you generate the crash dumps above then?

Well, nobody minds if I play with a webserver in the middle of the
night, as long as it works during the day. Shoot me. :)

Both servers are running fine since I applied my patch last night.

Now that I looked into it I think that it's obviously the correct
solution.

[Andi Kleen]

Post by Christophe Saout

Post by Andi Kleen

Post by Christophe Saout
preempt_schedule_irq is not an i386 specific function and seems to take
special care of BKL preemption and since reiserfs does use the BKL to do
certain things I think this actually might be the problem...?

Hmm, preempt_schedule_irq is not in mainline as far as I can see.
My patches are always for mainline; i dont do a special
patch kit for -mm*

PREEMPT_BKL has been in mainline since 2.6.11-rc1, preempt_schedule_irq
http://linux.bkbits.net:8080/linux-2.6/search/?expr=preempt_schedule_irq&search=ChangeSet+comments

Hmm, true. I must have missed it with the last merge.

Looking at the changeset your simple patch is probably ok.

Post by Christophe Saout
Now that I looked into it I think that it's obviously the correct
solution.

Agreed.

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



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------