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 bou...@antioche.eu.org
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: 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: 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
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
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. 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
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
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: 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=data_stripe_size 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
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: 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
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
