[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: nfblock vs udev



On Thu, 28 Aug 2008, Petr Stehl�wrote:
> Stephen R Marenka píše v Čt 10. 07. 2008 v 21:40 -0500:
> > I updated my test kernels [0] and kernel patches at [1].
> > [0] http://people.debian.org/~smarenka/m68k/kernel
> > [1] http://people.debian.org/~smarenka/m68k/kernel/patches
> > 
> > These were built with the gcc-4.2 cross-compiler at [2].
> > [2] http://people.debian.org/~smarenka/m68k/cross-compilers
> > 
> > I managed to get a udev on nfblock debug log at [3].
> > [3] http://people.debian.org/~smarenka/tmp/udevboot.log
> > 
> > Hopefully someone can make sense of it and help me out. Right now 
> > nfblock kernels and debian-installer don't play nicely together.
> 
> I have just tried starting a 2.6.25 kernel on Debian disk.img (both from
> Stephen). This is what happens from the nfblock side before it halts:
> 
> 1) XHGetCapacity is called on device 16 (= [IDE0]) and gets positive
> answer: size of the device in blocks is 20971440 (=10 GB)
> 
> 2) XHRead(16.0, recno=0, count=0, buf=$8) is called - it tries to read 0
> sectors so the answer is OK - probably just a quick test from the linux
> kernel if the device is inserted and readable.

I'd expect it to read the first PAGE_SIZE bytes, i.e. 8 blocks of
blocksize 512 = 4 KiB, to identify the partition table.

> 3) ARAnyM XHRead(16.0, recno=0, count=65280, buf=$8) is called - it
> tries to read 65280 sectors to address $8, so it's going to overwrite
> bottom 32 MB of memory with data from the disk drive.
> 
> Then it crashes with the double bus fault - I don't know where the PC is
> but maybe the currect program code gets overwritten by the disk data -
> that would explain the crash easily.
> 
> I can debug this further from the outside but I was wondering if it is
> normal to read 65280 sectors blindly and store it to 0x00000008 address.
> Why such an amount of data? And is the address 0x0008 OK as a disk
> buffer? I almost feel like the parameters are not passed in correctly
> (65280 is 0xff00).

Same here: 8 blocks is 4 KiB.

So the values passed to the `buf' parameter are actually values for the `count'
parameter.

However, the values passed to the `count' parameter are not buffer
addresses, as I'd expect them to be PAGE_SIZE aligned in the buffer
cache.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Reply to: