* Re: 2.5.70-mm4 RAID1 seems to work!
2003-06-04 6:18 2.5.70-mm4 Andrew Morton
@ 2003-06-04 8:12 ` Helge Hafting
2003-06-04 13:55 ` 2.5.70-mm4 Paul Larson
` (5 subsequent siblings)
6 siblings, 0 replies; 12+ messages in thread
From: Helge Hafting @ 2003-06-04 8:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
Congratulations, raid-1 seems to work again in 2.5.70-mm4!
My work pc came up just fine. I'll try
raid-0 on my home machine later today.
Helge Hafting
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: 2.5.70-mm4
2003-06-04 6:18 2.5.70-mm4 Andrew Morton
2003-06-04 8:12 ` 2.5.70-mm4 RAID1 seems to work! Helge Hafting
@ 2003-06-04 13:55 ` Paul Larson
2003-06-04 15:33 ` 2.5.70-mm4 Paul Larson
` (4 subsequent siblings)
6 siblings, 0 replies; 12+ messages in thread
From: Paul Larson @ 2003-06-04 13:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: lkml, linux-mm
See bug 772 - http://bugme.osdl.org/show_bug.cgi?id=772
----------------------
CC kernel/ksyms.o
kernel/ksyms.c:490: `__preempt_spin_lock' undeclared here (not in a
function)
kernel/ksyms.c:490: initializer element is not constant
kernel/ksyms.c:490: (near initialization for
`__ksymtab___preempt_spin_lock.value')
kernel/ksyms.c:491: `__preempt_write_lock' undeclared here (not in a
function)
kernel/ksyms.c:491: initializer element is not constant
kernel/ksyms.c:491: (near initialization for
`__ksymtab___preempt_write_lock.value')
make[1]: *** [kernel/ksyms.o] Error 1
make: *** [kernel] Error 2
It looks like this got broken in /include/linux/spinlock.h:
#if defined(CONFIG_SMP) && defined(CONFIG_PREEMPT) &&
!defined(CONFIG_DEBUG_EVENTLOG)
void __preempt_spin_lock(spinlock_t *lock);
void __preempt_write_lock(rwlock_t *lock);
...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: 2.5.70-mm4
2003-06-04 6:18 2.5.70-mm4 Andrew Morton
2003-06-04 8:12 ` 2.5.70-mm4 RAID1 seems to work! Helge Hafting
2003-06-04 13:55 ` 2.5.70-mm4 Paul Larson
@ 2003-06-04 15:33 ` Paul Larson
2003-06-04 15:52 ` 2.5.70-mm4 Paul Larson
` (3 subsequent siblings)
6 siblings, 0 replies; 12+ messages in thread
From: Paul Larson @ 2003-06-04 15:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: lkml, linux-mm
On Wed, 2003-06-04 at 01:18, Andrew Morton wrote:
> . A patch which adds the statfs64() syscall. This involved some mangling
> of the BSD accountig code. If anyone knows how to test BSD accounting,
> please do so, or let me know.
For what it's worth, LTP has two BSD acct tests and they both pass
fine. These are not elaborate or stressful in anyway, but they make for
a good, quick sniff test.
Thanks,
Paul Larson
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: 2.5.70-mm4
2003-06-04 6:18 2.5.70-mm4 Andrew Morton
` (2 preceding siblings ...)
2003-06-04 15:33 ` 2.5.70-mm4 Paul Larson
@ 2003-06-04 15:52 ` Paul Larson
2003-06-04 18:00 ` 2.5.70-mm4 Felipe Alfaro Solana
2003-06-04 17:14 ` 2.5.70-mm4 Alexander Hoogerhuis
` (2 subsequent siblings)
6 siblings, 1 reply; 12+ messages in thread
From: Paul Larson @ 2003-06-04 15:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: lkml, linux-mm
On Wed, 2003-06-04 at 01:18, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.70/2.5.70-mm4/
A couple of issues:
Hangs on boot unless I use acpi=off, but I don't believe this is unique
to -mm. I've seen this on plain 2.5 kernels on and off before with this
8-way and others like it. AFAIK the acpi issues are ongoing and still
being worked, but please let me know if there's any information I can
gather other than what's already out there that would assist in fixing
these.
I pulled the latest cvs of LTP and started a make on it. The make
finished but when I tried to do anything I realized that it was
completely hung. NMI was on but no messages over the serial console.
I'll turn off preempt and turn on debug eventlog and see if that
provides any other useful information. Is anyone else seeing this
happen? I had seen similar hangs in -mm2 and was told that ext3 might
be the cuplrit and to wait for -mm3. I didn't get a chance to try -mm3.
Thanks,
Paul Larson
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: 2.5.70-mm4
2003-06-04 15:52 ` 2.5.70-mm4 Paul Larson
@ 2003-06-04 18:00 ` Felipe Alfaro Solana
0 siblings, 0 replies; 12+ messages in thread
From: Felipe Alfaro Solana @ 2003-06-04 18:00 UTC (permalink / raw)
To: Paul Larson; +Cc: Andrew Morton, LKML, linux-mm
On Wed, 2003-06-04 at 17:52, Paul Larson wrote:
> On Wed, 2003-06-04 at 01:18, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.70/2.5.70-mm4/
> A couple of issues:
>
> Hangs on boot unless I use acpi=off, but I don't believe this is unique
> to -mm. I've seen this on plain 2.5 kernels on and off before with this
> 8-way and others like it. AFAIK the acpi issues are ongoing and still
> being worked, but please let me know if there's any information I can
> gather other than what's already out there that would assist in fixing
> these.
This remembers me of a pretty strange issue I'm having with ACPI on my
NEC/Packard Bell Chrom@ laptop: if I plug my 3Com CardBus NIC in the
second PCMCIA slot, the kernel hangs during boot just at the time the
NIC generates an interrupt (for example, by sending a ping or some
traffic). However, if I plug the NIC into the first slot, it works
perfectly.
Curious, isn't it? I think it's related to ACPI IRQ routing: the NIC
uses IRQ10 when plugged into the first slot, but it uses IRQ5 when
plugged into the second one (which causes the mentioned hang). IRQ5 is
being shared with my YMFPCI sound card. Don't know if this is related to
the hangs, but I thought it was worth saying.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 2.5.70-mm4
2003-06-04 6:18 2.5.70-mm4 Andrew Morton
` (3 preceding siblings ...)
2003-06-04 15:52 ` 2.5.70-mm4 Paul Larson
@ 2003-06-04 17:14 ` Alexander Hoogerhuis
2003-06-04 21:12 ` 2.5.70-mm4 Helge Hafting
2003-06-04 21:33 ` 2.5.70-mm4 Rudmer van Dijk
6 siblings, 0 replies; 12+ messages in thread
From: Alexander Hoogerhuis @ 2003-06-04 17:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
Andrew Morton <akpm@digeo.com> writes:
>
> . There have been one or two reports of -mm3 getting stuck in
> get_request_wait() against CDROMs. If anyone sees that, or was seeing it
> in -mm3 and does not see it in -mm4, please let us know.
>
One of those came from me. Its better than what I've had before. I've
tinkered a bit, with and without debugging and ide-scsi, and I still
managed to get it to blow up. But I no longer see the insane loads
I've had on earlier kernels.
Attached is the output from a sesison with copying from CDs to the USB
drive with no ide-scsi, and i've put a comment it where it seems to
fall over:
usb-storage: Command WRITE_10 (10 bytes)
usb-storage: 2a 00 1b c3 2f 4f 00 04 00 00
usb-storage: Bulk command S 0x43425355 T 0x9a7 Trg 0 LUN 0 L 524288 F 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 524288 bytes, 128 entries
usb-storage: Status code 0; transferred 524288/524288
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk status Sig 0x53425355 T 0x9a7 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Command WRITE_10 (10 bytes)
usb-storage: 2a 00 1b c3 33 4f 00 04 00 00
usb-storage: Bulk command S 0x43425355 T 0x9a8 Trg 0 LUN 0 L 524288 F 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 524288 bytes, 127 entries
usb-storage: Status code 0; transferred 524288/524288
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
-- here
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: usb_storage_command_abort called
usb-storage: usb_stor_stop_transport called
usb-storage: -- cancelling URB
usb-storage: Status code -104; transferred 0/13
usb-storage: -- transfer cancelled
usb-storage: Bulk status result = 3
usb-storage: -- command was aborted
usb-storage: Bulk reset requested
usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value=0000 index=00 len=0
usb-storage: Soft reset: clearing bulk-in endpoint halt
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=88 len=0
usb-storage: usb_stor_clear_halt: result = 0
usb-storage: Soft reset: clearing bulk-out endpoint halt
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=02 len=0
usb-storage: usb_stor_clear_halt: result = 0
usb-storage: Soft reset done
usb-storage: scsi command aborted
usb-storage: *** thread sleeping.
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage: 00 00 00 00 00 00
usb-storage: Bulk command S 0x43425355 T 0x9a8 Trg 0 LUN 0 L 0 F 0 CL 6
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk status Sig 0x53425355 T 0x9a8 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
mvh,
A
--
Alexander Hoogerhuis | alexh@ihatent.com
CCNP - CCDP - MCNE - CCSE | +47 908 21 485
"You have zero privacy anyway. Get over it." --Scott McNealy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: 2.5.70-mm4
2003-06-04 6:18 2.5.70-mm4 Andrew Morton
` (4 preceding siblings ...)
2003-06-04 17:14 ` 2.5.70-mm4 Alexander Hoogerhuis
@ 2003-06-04 21:12 ` Helge Hafting
2003-06-05 1:53 ` 2.5.70-mm4 Neil Brown
2003-06-04 21:33 ` 2.5.70-mm4 Rudmer van Dijk
6 siblings, 1 reply; 12+ messages in thread
From: Helge Hafting @ 2003-06-04 21:12 UTC (permalink / raw)
To: Andrew Morton, neilb; +Cc: linux-kernel, linux-mm
Raid-1 seems to work in 2.5.70-mm4, but raid-0 still fail.
Trying to boot with raid-0 autodetect yields a long string of:
Slab error in cache_free_debugcheck
cache 'size-32' double free or
memory after object overwritten.
(Is this something "Page alloc debugging"may be used for?)
kfree+0xfc/0x330
raid0_run
raid0_run
printk
blk_queue_make_request
do_md_run
md_ioctl
dput
blkdev_ioctl
sys_ioctl
syscall_call
I get a ton of these, in between normal
initialization messages. Then the thing
dies with a panic due to exception in interrupt.
This is a monolithic smp preempt kernel on a dual celeron.
The disks are scsi, the filesystems ext2. There is one
raid-0 array and two raid-1 arrays, as well as some
ordinary partitions. Root is on raid-1.
Helge Hafting
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: 2.5.70-mm4
2003-06-04 21:12 ` 2.5.70-mm4 Helge Hafting
@ 2003-06-05 1:53 ` Neil Brown
2003-06-05 15:24 ` 2.5.70-mm4 this helped but still no raid0 Helge Hafting
0 siblings, 1 reply; 12+ messages in thread
From: Neil Brown @ 2003-06-05 1:53 UTC (permalink / raw)
To: Helge Hafting; +Cc: Andrew Morton, linux-kernel, linux-mm
On Wednesday June 4, helgehaf@aitel.hist.no wrote:
> Raid-1 seems to work in 2.5.70-mm4, but raid-0 still fail.
>
> Trying to boot with raid-0 autodetect yields a long string of:
> Slab error in cache_free_debugcheck
> cache 'size-32' double free or
> memory after object overwritten.
> (Is this something "Page alloc debugging"may be used for?)
> kfree+0xfc/0x330
> raid0_run
> raid0_run
> printk
> blk_queue_make_request
> do_md_run
> md_ioctl
> dput
> blkdev_ioctl
> sys_ioctl
> syscall_call
>
> I get a ton of these, in between normal
> initialization messages. Then the thing
> dies with a panic due to exception in interrupt.
>
> This is a monolithic smp preempt kernel on a dual celeron.
> The disks are scsi, the filesystems ext2. There is one
> raid-0 array and two raid-1 arrays, as well as some
> ordinary partitions. Root is on raid-1.
>
> Helge Hafting
grrr... I thought I had that right...
You need to remove the two calls to 'kfree' at the end of
create_strip_zones.
I have jsut sent some patches to Linus (and linux-raid@vger) which
will update his tree to include this fix.
NeilBrown
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 2.5.70-mm4 this helped but still no raid0
2003-06-05 1:53 ` 2.5.70-mm4 Neil Brown
@ 2003-06-05 15:24 ` Helge Hafting
0 siblings, 0 replies; 12+ messages in thread
From: Helge Hafting @ 2003-06-05 15:24 UTC (permalink / raw)
To: Neil Brown; +Cc: Andrew Morton, linux-kernel, linux-mm
On Thu, Jun 05, 2003 at 11:53:51AM +1000, Neil Brown wrote:
[...]
> grrr... I thought I had that right...
>
> You need to remove the two calls to 'kfree' at the end of
> create_strip_zones.
>
I commented out the two kfree's, and the kernel managed to boot.
But the raid-0 array didn't work. The boot scripts
tried to fsck it, but couldn't get a valid ext2 superblock.
(fsck -f under 2.5.69-mm8 showed no problems, the fs was clean.)
Then it was mount time. Various partition and raid-1 based
fses mounted fine, but mounting the raid-0 on /usr/src killed the kernel:
unable to handle kernel NULL pointer deref at virtual address 00000014
PREEMPTSMP
EIP at raid0_make_request
process mount
bh_lru_install
generic_make_request
autoremove_wake_function
bio_alloc
submit_bio
__bread_slow_wq
__bread
ext2_fill_super
sb_set_blocksize
get_sb_bdev
alloc_vfsmnt
ext2_get_sb
ext2_fill_super
do_kern_mount
do_add_mount
do_mount
copy_mount_options
sys_mount
syscall_call
Looks like something else is wrong with raid-0.
> I have jsut sent some patches to Linus (and linux-raid@vger) which
> will update his tree to include this fix.
>
Were there anything more than removal of the two kfrees?
Helge Hafting
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 2.5.70-mm4
2003-06-04 6:18 2.5.70-mm4 Andrew Morton
` (5 preceding siblings ...)
2003-06-04 21:12 ` 2.5.70-mm4 Helge Hafting
@ 2003-06-04 21:33 ` Rudmer van Dijk
2003-06-05 9:21 ` 2.5.70-mm4 Maciej Soltysiak
6 siblings, 1 reply; 12+ messages in thread
From: Rudmer van Dijk @ 2003-06-04 21:33 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux-mm
On Wednesday 04 June 2003 08:18, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.70/2.5.70
>-mm4/
>
I got the following errors with every file that includes
include/linux/bitops.h
include/linux/bitops.h: In function `generic_hweight64':
include/linux/bitops.h:118: warning: integer constant is too large for "long"
type
include/linux/bitops.h:118: warning: integer constant is too large for "long"
type
include/linux/bitops.h:119: warning: integer constant is too large for "long"
type
include/linux/bitops.h:119: warning: integer constant is too large for "long"
type
include/linux/bitops.h:120: warning: integer constant is too large for "long"
type
include/linux/bitops.h:120: warning: integer constant is too large for "long"
type
include/linux/bitops.h:121: warning: integer constant is too large for "long"
type
include/linux/bitops.h:121: warning: integer constant is too large for "long"
type
include/linux/bitops.h:122: warning: integer constant is too large for "long"
type
include/linux/bitops.h:122: warning: integer constant is too large for "long"
type
This is on UP, athlon, gcc 3.3
Rudmer
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: 2.5.70-mm4
2003-06-04 21:33 ` 2.5.70-mm4 Rudmer van Dijk
@ 2003-06-05 9:21 ` Maciej Soltysiak
0 siblings, 0 replies; 12+ messages in thread
From: Maciej Soltysiak @ 2003-06-05 9:21 UTC (permalink / raw)
To: Rudmer van Dijk; +Cc: Andrew Morton, linux-kernel, linux-mm
> I got the following errors with every file that includes
> include/linux/bitops.h
>
> include/linux/bitops.h: In function `generic_hweight64':
> include/linux/bitops.h:118: warning: integer constant is too large for "long"
> type
> include/linux/bitops.h:118: warning: integer constant is too large for "long"
> type
> include/linux/bitops.h:119: warning: integer constant is too large for "long"
<snip>
Same here with debian unstable with gcc-3.3, it started to act like that
since -mm4, mm3 was ok.
> This is on UP, athlon, gcc 3.3
Also UP on P4.
Regards,
Maciej
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 12+ messages in thread