Re: No more than 255 device files with Debian Sarge
Stefan Sperling <sperl@nateurope.com> writes:
> Hello!
>
> 0. I discovered a strange phenomenon with a Debian
> Sarge installation. I am able to replicate it
> on several machines. It occurs on freshly
> installed machines as well as on "older" ones.
>
> The problem is this:
>
> I want to create more than 4000 device files
> for a project. I am aware that this is an
> uncommon scenario. But it is a customer request.
>
> Generating the device files works well for the
> first 255 ones. Then the major number is
> incremented by 1 and the minor number starts over
> with 0. mknod NEVER returns an error.
>
> 1. I tried this with kernel 2.6.8 as well as with
> kernel 2.6.16 - no change. devfs is removed.
>
> I can show this phenomenon on a Debian machine
> with some example values:
>
> nattest:/home/sperl/tmp# mknod testnode1 c 200 16
> nattest:/home/sperl/tmp# mknod testnode2 c 200 255
> nattest:/home/sperl/tmp# mknod testnode3 c 200 256
> nattest:/home/sperl/tmp# mknod testnode4 c 200 511
> nattest:/home/sperl/tmp# mknod testnode5 c 200 512
> nattest:/home/sperl/tmp# ls -l
> total 0
> crw-r--r-- 1 root root 200, 16 2006-11-23 10:07 testnode1
> crw-r--r-- 1 root root 200, 255 2006-11-23 10:07 testnode2
> crw-r--r-- 1 root root 201, 0 2006-11-23 10:07 testnode3
> crw-r--r-- 1 root root 201, 255 2006-11-23 10:07 testnode4
> crw-r--r-- 1 root root 202, 0 2006-11-23 10:07 testnode5
You have 16bit major/minor numbers, 8 bit for major, 8 bit for
minor. Since 8 bit can only hold values from 0 to 255 the minor number
overflows. I'm assuming the code looks like this:
unsigned short major_minor = (major << 8) + minor;
> 2. Doing the same on my Ubuntu installation running a 2.6.15
> kernel I get this:
>
> root@natss:/home/sperl/tmp2# mknod testnode1 c 200 16
> root@natss:/home/sperl/tmp2# mknod testnode2 c 200 255
> root@natss:/home/sperl/tmp2# mknod testnode3 c 200 256
> root@natss:/home/sperl/tmp2# mknod testnode4 c 200 511
> root@natss:/home/sperl/tmp2# mknod testnode5 c 200 512
> root@natss:/home/sperl/tmp2# ls -l
> insgesamt 0
> crw-r--r-- 1 root root 200, 16 2006-11-23 10:10 testnode1
> crw-r--r-- 1 root root 200, 255 2006-11-23 10:11 testnode2
> crw-r--r-- 1 root root 200, 256 2006-11-23 10:11 testnode3
> crw-r--r-- 1 root root 200, 511 2006-11-23 10:11 testnode4
> crw-r--r-- 1 root root 200, 512 2006-11-23 10:11 testnode5
>
> As you can see, on Ubuntu everything is as expected.
Then someone noticed that 16 bit for major+minor are quite restrictive
and more and more of it gets used up. What if we run out of
major/minor pairs? So they sat down and created bigger major/minor numbers
so now there are more of them.
> 3. I even wrote an own version of mknod to check if there is
> a bug in the tool. Result: All files are created correctly
> with Ubuntu but not with Debian.
>
> 4. I wrote a tiny device driver just to verify that the minor
> numbers are not only displayed wrong by "ls". Result: I was
> able to access all devices with major number 200 from my test
> application but not the ones with 201, 202,... For major
> number 200 everything looked sane; the minor number I have
> seen in my open function looked healthy.
>
> 5. When I do create a devicefile like testnode3 (with minor number
> 256) from the Ubuntu machine via NFS this is what happens:
> On the Ubuntu machine the file looks ok (major 200, minor 256).
> On the Debian console I see the same file with major 201 and
> minor 0.
>
> 6. When I start my test application and try to open testnode3 on
> the Debian machine I cannot open the device.
>
> 7. I already experimented with the kernel configuration. Even
> excluding devfs did not help.
>
> I found nothing similair in the Debian bug report database nor
> on the rest of the Internet either.
>
> Does anyone of you have an idea?
Fetch a newer kernel for debian from backports or compile your
own. That should solve the problem.
> Thanks for reading!
>
> Greetings,
> Stefan
MfG
Goswin
Reply to: