Aug 10 18:16:26 tt2 kernel: attempt to access beyond end of device
Aug 10 18:16:26 tt2 kernel: 0b:00, want=532574, limit=532572
klogd starts using 100% CPU.
So it looks like the race condition is in the cdrom layer.
Anything else I can do to try find this bug, I will be happy to do.
Cheers Mof.
On Fri, 6 Aug 1999, Chuck Lever wrote:
> mofeed-
>
> there's a race somewhere that's causing shrink_mmap to deduct too much
> from buffermem, making it go negative. i don't think that it's specific
> to a particular driver. i haven't been able to simply and consistently
> reproduce the race -- maybe you could come up with some way to do this?
> is it specific to how much data you copied, for instance?
>
> On Fri, 6 Aug 1999, Mofeed Shahin wrote:
> > First off I will explain what I was doing that caused the problem.
> > I was copying a whole CD to the hard-drive. They are both scsi AIC7xxx.
> >
> > While I was copying I noticed Xosview not looking too healthy so I ran top
> > and noticed that the amount of buffer memory was obviously wrong.
> >
> > here is the vmstat output :
> >
> > :vmstat
> > procs memory swap io system cpu
> > r b w swpd free buff cache si so bi bo in cs us sy id
> > 1 0 0 744 2908 4193304 205452 0 0 2 4 52 14 47 0 53
> > ^^^^^^^
> > Notice the 4.1 GIG of buffer memory.
> >
> > Also half way through the copy klogd started using up all the CPU time on
> > one of the processors.
> > Even after the copy had finished klogd was still using up large amounts of
> > CPU (100%).
>
> - Chuck Lever
> --
> corporate: <chuckl@netscape.com>
> personal: <chucklever@netscape.net> or <cel@monkey.org>
>
> The Linux Scalability project:
> http://www.citi.umich.edu/projects/linux-scalability/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/