Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
On Sep 25, 6:51am, Izumi Tsutsui wrote: You seem to have defective e-mail software, it doesn't properly quote. } > I have a realy strange collection of } > old machines, but pretty sure none of it has more than one floppy drive, } > actually most of them have only broken drives). } } BTW all X680x0 machines have two 5.25" floppy drives, } though it uses sys/arch/x68k/dev/fd.c and it already suppurts I'm not sure what this has to do with anything, given that you're now talking about a different driver. } 1024bytes/sector format by default. It has a modified fd_types array. } It was based on isa/fd.c and also uses: } >> #define FDUNIT(dev)(minor(dev) / 8) } >> #define FDTYPE(dev)(minor(dev) % 8) Still don't know what this has to do with anything, other then demonstrating that it treats minor numbers the same way that sys/dev/isa/fd.c does. }-- End of excerpt from Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
On Sep 25, 6:43am, Izumi Tsutsui wrote: } } > The kernels aren't broken and don't require fixing. } } The topic is how to add 8th type and currently fd.c uses hardcoded '8'. Actually, the topic is asking what the purpose of FDUNIT and FDTYPE is. That question has been answered. } If we can simply change it to 16, why did we introduce complicated } __HAVE_OLD_DISKLABEL for harddisks? Again, disklabels have nothing to do with floppies, or conversely, the letter part of the "floppy unit" has nothing to do with partitions. }-- End of excerpt from Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
> I have a realy strange collection of > old machines, but pretty sure none of it has more than one floppy drive, > actually most of them have only broken drives). BTW all X680x0 machines have two 5.25" floppy drives, though it uses sys/arch/x68k/dev/fd.c and it already suppurts 1024bytes/sector format by default. It was based on isa/fd.c and also uses: >> #define FDUNIT(dev) (minor(dev) / 8) >> #define FDTYPE(dev) (minor(dev) % 8) --- Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
> The kernels aren't broken and don't require fixing. The topic is how to add 8th type and currently fd.c uses hardcoded '8'. If we can simply change it to 16, why did we introduce complicated __HAVE_OLD_DISKLABEL for harddisks? --- Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
On Sep 24, 8:03pm, Izumi Tsutsui wrote: } } > So, instead of fixing the very broken MAKEDEV script, you want to } > mangle multiple floppy drivers? At the end of the day, MAKEDEV is } > broken, it should not be treating floppy drives like hard drives. The } > unit letters don't have the same meaning and never have. } } There are two options, fixing kernels, or The kernels aren't broken and don't require fixing. } fixing /dev nodes on existing disks (not only MAKEDEV script). As things sit now, you can't use the second floppy drive on an amd64 machine. Although, there are going to be very few amd64 machines with two floppy drives (heck, modern PC motherboards don't have a floppy controller any more), that should be fixed. } I'm afraid few developers will maintain MAKEDEV script properly, Then they shouldn't be messing with it. } and few users will rerun /dev/MAKEDEV on upgrade. It will be automatically run by sysinst. If somebody manually does an upgrade and doesn't do it properly that's their problem. Besides, failing to run MAKEDEV will bite you in other ways, such as missing dev nodes for new devices. } Nowadays floppy is almost dead, so we don't have to care about } compatibility, though... This doesn't mean we should be doing hack jobs. NetBSD is about doing things right. }-- End of excerpt from Izumi Tsutsui
Re: 5.1 RAID5 write performance
e...@math.uni-bonn.de (=?iso-8859-1?Q?Edgar_Fu=DF?=) writes: >I first tried against the fs. I now added a scratch partition and tried the >devices: >I get 40 to 50MB/s on the raw device and a whopping 0.57MB/s on the block >device! The block device writes through the buffer cache which has its own idea of block sizes which is either the filesystem block size stored in the disklabel for that partition or 2048 bytes as a default. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
On Thu, May 05, 2011 at 01:27:50AM +0900, Izumi Tsutsui wrote: > I'm afraid few developers will maintain MAKEDEV script properly, > and few users will rerun /dev/MAKEDEV on upgrade. Nothing that usr.sbin/postinstall can't fix (or at least warn about) > Nowadays floppy is almost dead, so we don't have to care about > compatibility, though... Indeed - but this also means, nobody will be bitten by the change when we fix it (IIUC only machines with > 1 floppy would be affected anyway, unless you use the new formats - I have a realy strange collection of old machines, but pretty sure none of it has more than one floppy drive, actually most of them have only broken drives). Martin
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
On Sep 24, 6:14pm, Izumi Tsutsui wrote: } > On Wed, May 04, 2011 at 08:50:10PM +0900, Izumi Tsutsui wrote: } > > The problem is that there might be some ports whose MAXPARTITIONS is still 8 } > > and such ports can't use type 8. } > } > Why not? It is not used as a partiton of fd*. } > MAKEDEV is already wrong for those ports, the fd nodes probably should have } > special case handling. } } On i386: } --- } % ls -l fd1* } brw-r- 1 root operator 2, 8 May 7 2003 fd1a } [snip] } brw-r- 1 root operator 2, 15 May 7 2003 fd1h } brw-r- 1 root operator 2, 524296 May 7 2003 fd1i } [snip] } brw-r- 1 root operator 2, 524303 May 7 2003 fd1p } --- } } on amd64: } --- } # ls -l fd1* } brw-r- 1 root operator 2, 16 May 4 23:31 fd1a } [snip] } brw-r- 1 root operator 2, 31 May 4 23:31 fd1p } # } --- } } So current isa/fd.c can't handle the second drive } on ports where (MAXPARTITIONS != 8 && !__HAVE_OLD_DISKLABEL). } } For compatibility with longstanding inconsistent MAKEDEV(8), } it might be better to use DISKUNIT() and DISKPART() for } FDUNIT() and FDTYPE() as other disks, so that we don't have } to have special device minor handling for each MD fd device in } MI MAKEDEV.tmpl script. So, instead of fixing the very broken MAKEDEV script, you want to mangle multiple floppy drivers? At the end of the day, MAKEDEV is broken, it should not be treating floppy drives like hard drives. The unit letters don't have the same meaning and never have. }-- End of excerpt from Izumi Tsutsui
Re: 5.1 RAID5 write performance
More observations on my issue: > Did you dd against the raw device, the block device, or against the file > system on top of the raid? I first tried against the fs. I now added a scratch partition and tried the devices: I get 40 to 50MB/s on the raw device and a whopping 0.57MB/s on the block device! Nevertheless, when writing to the block dev, sysstat shows the raid being 100% busy and each of the discs being 50-60% busy. Moreover, when writing to the block dev, dd's WCHAN is vnode! > Did you try to match up the raid data stripe size with the filesystem > block size? No, I didn't. But it is aligned by chance. > What kind of performance do you get if you do the following: > dd if=/dev/zero of=/dev/rraid0d bs= count=100 On a scratch raid2h, some 0,57MB/s. > Do you get reasonable write performance for each of the component disk in > the raid? I.e. is there any possibility of partially failing disk? Yes. 21MB/s for each for them. > I noticed you tried raid1, which only takes 2 disk, so is the 3rd disk okay? The RAID1s are across three discs, too. Two more random observations: I continuously see ~3763 Interrupts on ioapic0 pin4, yes dmesg doesn't show anything for that pin. Nevertheless, there is ~0% CPU time spent in interrupt mode. When un-tar-ing src.tgz, the raid (plus it's components) are busy for minutes after the command finishes. Looks like there's something seriously wrong here, especially the raw dev being a hundred times faster than the block dev.
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
> So, instead of fixing the very broken MAKEDEV script, you want to > mangle multiple floppy drivers? At the end of the day, MAKEDEV is > broken, it should not be treating floppy drives like hard drives. The > unit letters don't have the same meaning and never have. There are two options, fixing kernels, or fixing /dev nodes on existing disks (not only MAKEDEV script). I'm afraid few developers will maintain MAKEDEV script properly, and few users will rerun /dev/MAKEDEV on upgrade. Nowadays floppy is almost dead, so we don't have to care about compatibility, though... --- Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
On Sep 24, 3:25pm, Izumi Tsutsui wrote: } } The problem is that there might be some ports whose MAXPARTITIONS is still 8 } and such ports can't use type 8. Given that floppies don't have disklabels (and don't support them), what does MAXPARTITIONS have to do with anything? }-- End of excerpt from Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
> On Wed, May 04, 2011 at 08:50:10PM +0900, Izumi Tsutsui wrote: > > The problem is that there might be some ports whose MAXPARTITIONS is still 8 > > and such ports can't use type 8. > > Why not? It is not used as a partiton of fd*. > MAKEDEV is already wrong for those ports, the fd nodes probably should have > special case handling. On i386: --- % ls -l fd1* brw-r- 1 root operator 2, 8 May 7 2003 fd1a brw-r- 1 root operator 2, 9 May 7 2003 fd1b brw-r- 1 root operator 2, 10 May 7 2003 fd1c brw-r- 1 root operator 2, 11 May 7 2003 fd1d brw-r- 1 root operator 2, 12 May 7 2003 fd1e brw-r- 1 root operator 2, 13 May 7 2003 fd1f brw-r- 1 root operator 2, 14 May 7 2003 fd1g brw-r- 1 root operator 2, 15 May 7 2003 fd1h brw-r- 1 root operator 2, 524296 May 7 2003 fd1i brw-r- 1 root operator 2, 524297 May 7 2003 fd1j brw-r- 1 root operator 2, 524298 May 7 2003 fd1k brw-r- 1 root operator 2, 524299 May 7 2003 fd1l brw-r- 1 root operator 2, 524300 May 7 2003 fd1m brw-r- 1 root operator 2, 524301 May 7 2003 fd1n brw-r- 1 root operator 2, 524302 May 7 2003 fd1o brw-r- 1 root operator 2, 524303 May 7 2003 fd1p --- on amd64: --- # ls -l fd1* brw-r- 1 root operator 2, 16 May 4 23:31 fd1a brw-r- 1 root operator 2, 17 May 4 23:31 fd1b brw-r- 1 root operator 2, 18 May 4 23:31 fd1c brw-r- 1 root operator 2, 19 May 4 23:31 fd1d brw-r- 1 root operator 2, 20 May 4 23:31 fd1e brw-r- 1 root operator 2, 21 May 4 23:31 fd1f brw-r- 1 root operator 2, 22 May 4 23:31 fd1g brw-r- 1 root operator 2, 23 May 4 23:31 fd1h brw-r- 1 root operator 2, 24 May 4 23:31 fd1i brw-r- 1 root operator 2, 25 May 4 23:31 fd1j brw-r- 1 root operator 2, 26 May 4 23:31 fd1k brw-r- 1 root operator 2, 27 May 4 23:31 fd1l brw-r- 1 root operator 2, 28 May 4 23:31 fd1m brw-r- 1 root operator 2, 29 May 4 23:31 fd1n brw-r- 1 root operator 2, 30 May 4 23:31 fd1o brw-r- 1 root operator 2, 31 May 4 23:31 fd1p # --- So current isa/fd.c can't handle the second drive on ports where (MAXPARTITIONS != 8 && !__HAVE_OLD_DISKLABEL). For compatibility with longstanding inconsistent MAKEDEV(8), it might be better to use DISKUNIT() and DISKPART() for FDUNIT() and FDTYPE() as other disks, so that we don't have to have special device minor handling for each MD fd device in MI MAKEDEV.tmpl script. --- Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
> The problem is that there might be some ports whose MAXPARTITIONS is > still 8 and such ports can't use type 8. Nothing says fd.c has to use MAXPARTITIONS (nor the macros built using it) when breaking up the device minor number. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
On Wed, May 04, 2011 at 08:50:10PM +0900, Izumi Tsutsui wrote: > The problem is that there might be some ports whose MAXPARTITIONS is still 8 > and such ports can't use type 8. Why not? It is not used as a partiton of fd*. MAKEDEV is already wrong for those ports, the fd nodes probably should have special case handling. Martin
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
On 4 May 2011 12:50, Izumi Tsutsui wrote: > The problem is that there might be some ports whose MAXPARTITIONS is still 8 > and such ports can't use type 8. Maybe this is time to update those remaining ports to 16... :)
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
The problem is that there might be some ports whose MAXPARTITIONS is still 8 and such ports can't use type 8. --- Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
> Unfortunatley, ultimately the kernel is correct (as always). Well, in the sense that what counts is what the kernel does. > But you can easily change it to work div/mod 16 of course. That's what I did (becuase I added a ten-sector-per-track-format on type 8). > It is all just a convention between MAKEDEV and the kernel > (which should match). That's exactly what I'd been trying to say in the first place. So I would prefer the kernel to be changed to match MAKEDEV, not the other way round.
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
On Wed, May 04, 2011 at 12:52:30PM +0200, Edgar Fuß wrote: > > What is FDUNIT good for? > Well, ehm, I suppose that's supposed to be, ehm, the unit number, e.g. 0 or 1 > for fd0x/fd1x. Oh, duh, of course ;-) Unfortunatley, ultimately the kernel is correct (as always). But you can easily change it to work div/mod 16 of course. It is all just a convention between MAKEDEV and the kernel (which should match). Martin
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
> FDUNIT and FDTYPE both derive from minor(dev). Yes. > MAKEDEV creates 16 minors, so you get unit 0 and 1, and 8 types each. I get sixteen fd0x and sixteen fd1x entries. Is my MAKEDEV broken? > What is FDUNIT good for? Well, ehm, I suppose that's supposed to be, ehm, the unit number, e.g. 0 or 1 for fd0x/fd1x.
Re: NFS server problems (lockup) on netbsd-5
On Wed, May 04, 2011 at 10:58:41AM +0200, Manuel Bouyer wrote: > > My "netbsd-5" NFS server using sources from the 8th of March has worked > > fine for 56 days. > > Well, It's really not easy to reproduce (I tried reproducing it with > a test server and couldn't). On the production server there are home > directories for about 100 linux clients; there's no home directory > on the test server ... In which case the problem might be even older because my server doesn't have to handle that kind of load. It has home directories on it which get accessed by a Mac OS X NFS client that uses a locking a lot but it never had to handle more than three clients. Kind regards -- Matthias Scheler http://zhadum.org.uk/
fix for port-xen/44734 (now kern/44734)
Hello,
I looked at port-xen/44734 "Starting atalkd triggers assertion panic with
i386 xen domU", which I requalified as kern/44734 as it's not xen-specific.
The problem is that MOWNER_ATTACH(&aarp_mowner) is not done before
using it in aarpprobe(). I propose to move MOWNER_ATTACH(&aarp_mowner)
to ddp_init(), the drawback being that aarp_mowner is now exposed
outside of aarp.c
Is it acceptable ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Index: aarp.c
===
RCS file: /cvsroot/src/sys/netatalk/aarp.c,v
retrieving revision 1.27
diff -u -p -r1.27 aarp.c
--- aarp.c 24 Apr 2008 11:38:37 - 1.27
+++ aarp.c 4 May 2011 09:44:59 -
@@ -511,7 +511,6 @@ aarptnew(const struct at_addr *addr)
first = 0;
callout_init(&aarptimer_callout, 0);
callout_reset(&aarptimer_callout, hz, aarptimer, NULL);
- MOWNER_ATTACH(&aarp_mowner);
}
aat = &aarptab[AARPTAB_HASH(*addr) * AARPTAB_BSIZ];
for (n = 0; n < AARPTAB_BSIZ; n++, aat++) {
Index: aarp.h
===
RCS file: /cvsroot/src/sys/netatalk/aarp.h,v
retrieving revision 1.2
diff -u -p -r1.2 aarp.h
--- aarp.h 10 Dec 2005 23:29:05 - 1.2
+++ aarp.h 4 May 2011 09:44:59 -
@@ -76,4 +76,6 @@ struct aarptab {
#define AARPOP_RESPONSE0x02
#define AARPOP_PROBE 0x03
+extern struct mowner aarp_mowner;
+
#endif /* !_NETATALK_AARP_H_ */
Index: ddp_usrreq.c
===
RCS file: /cvsroot/src/sys/netatalk/ddp_usrreq.c,v
retrieving revision 1.33
diff -u -p -r1.33 ddp_usrreq.c
--- ddp_usrreq.c4 May 2008 07:22:14 - 1.33
+++ ddp_usrreq.c4 May 2011 09:44:59 -
@@ -569,6 +569,7 @@ ddp_init(void)
MOWNER_ATTACH(&atalk_tx_mowner);
MOWNER_ATTACH(&atalk_rx_mowner);
+ MOWNER_ATTACH(&aarp_mowner);
}
#if 0
Re: NFS server problems (lockup) on netbsd-5
On Wed, May 04, 2011 at 07:55:02AM +0100, Matthias Scheler wrote: > On Tue, Apr 26, 2011 at 06:31:19PM +0200, Manuel Bouyer wrote: > > Hello, > > I tried upgrading a NFS server to today's netbsd-5 branch, without success. > > The previous kernel (netbsd-5 from 7 feb 2010) is rock solid. > > I tried a kernel from before the recent nfs-related pullups, it shows > > the same symptoms. > > My "netbsd-5" NFS server using sources from the 8th of March has worked > fine for 56 days. Well, It's really not easy to reproduce (I tried reproducing it with a test server and couldn't). On the production server there are home directories for about 100 linux clients; there's no home directory on the test server ... > > Based on that time frame my best guess is that one of these pullups > might have caused your problem: > > http://releng.netbsd.org/cgi-bin/req-5.cgi?show=1580 > http://releng.netbsd.org/cgi-bin/req-5.cgi?show=1581 > http://releng.netbsd.org/cgi-bin/req-5.cgi?show=1582 > http://releng.netbsd.org/cgi-bin/req-5.cgi?show=1583 > http://releng.netbsd.org/cgi-bin/req-5.cgi?show=1600 I can take out 1600; I tried a kernel from before this one and it didn't work either. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
