Re: Panic Kernel Dump to umass device?
In message <[EMAIL PROTECTED]>, Scott Long writes:
>You're correct that dumping is meant to be done with interrupts and task
>switching disabled. The first thing that the umass driver is missing is
>a working CAM poll handler. Without this, there is no way for command
>completions to be seen when interrupts are disabled. Beyond that, I
>somewhat suspect that the USB stack expects to be able to push command
>completion work off to worker threads, at least for some situations, and
>that also will not work in the kernel dump environment. So, there is a
>lot of work needed to make this happen.
The USB stack supports polled operations, so it's actually not to
hard to make this work. Below is a patch I had in one of my local
trees that adds a CAM poll handler to the umass driver. I've just
tested this and it does seem to make kernel dumping work, but I
guess it might not be as reliable as dumping to other devices.
Ian
Index: umass.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/umass.c,v
retrieving revision 1.128
diff -u -r1.128 umass.c
--- umass.c 9 Jan 2006 01:33:53 - 1.128
+++ umass.c 11 Feb 2006 12:57:43 -
@@ -2627,21 +2627,17 @@
}
}
-/* umass_cam_poll
- * all requests are handled through umass_cam_action, requests
- * are never pending. So, nothing to do here.
- */
Static void
umass_cam_poll(struct cam_sim *sim)
{
-#ifdef USB_DEBUG
struct umass_softc *sc = (struct umass_softc *) sim->softc;
DPRINTF(UDMASS_SCSI, ("%s: CAM poll\n",
USBDEVNAME(sc->sc_dev)));
-#endif
- /* nop */
+ usbd_set_polling(sc->sc_udev, 1);
+ usbd_dopoll(sc->iface);
+ usbd_set_polling(sc->sc_udev, 0);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RAID5 on athlon64 machines
I built an Asus A8N SLI Deluxe based system and installed FreeBSD-6.1-BETA1 on it. This works well enough. Now I am looking for a decent RAID5 solution. This motherboard has two SATA RAID controllers. But one does only RAID1. The other supports RAID5 but seems to require s/w assistance from windows driver. The BIOS does let you designate a set of disks as a raid5 group but Freebsd does not recognize it as a group in any case. I noticed that vinum is gone from -current and we have gvinum now but it does not implement all of the vinum commands. But that is ok if it provides what I need. I played with it a little bit. Its sequential read performance is ok (I am using 3 disks for RAID5 and the read rate is twice the speed of one disk as expected). But the write rate is abysmal! I get about 12.5MB/s or about 1/9 of the read rate. So what gives? Are there some magic stripe sizes for better performance? I used a stripe size of 279k as per vinum recommendation. Theoretically the sequential write rate should be same or higher than the sequential read rate. Given an N+1 disk array, for N blocks reads you XOR N + 1 blocks and compare the result to 0 but for N block writes you XOR N blocks. So there is less work for large writes. Which leads me to ask: is gvinum stable enough for real use or should I just get a h/w RAID card? If the latter, any recommendations? What I'd like: Critical: - RAID5 - good write performance - orderly shutdown (I noticed vinum stop command is gone but may be it is not needed?) - quick recovery from a system crash. It shouldn't have to rebuild the whole array. - parity check on reads (a crash may have rendered a stripe inconsistent) - must not correct bad parity by rewriting a stripe Nice to have: - ability to operate in "degraded" mode, where one of the disks is dead. - ability to rebuild the array in background - commands to take a disk offline, associate a spare with a particular disk - use a spare drive effectively - allow a bad parity stripe for future writes - allow rewriting parity under user control. Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RAID5 on athlon64 machines
> Theoretically the sequential write rate should be same or > higher than the sequential read rate. Given an N+1 disk Seq write rate for the whole RAID5 array will always be lower than the write rate for it's single disk. See 'http://en.wikipedia.org/wiki/RAID#RAID_5' " Traditional RAID5 A1 A2 A3 Ap B1 B2 Bp B3 C1 Cp C2 C3 Dp D1 D2 D3 [...] If another block, or some portion of a block, is written on that same stripe the parity block (or some portion of the parity block) is recalculated and rewritten. For small writes, this requires reading the old parity, reading the old data, writing the new parity, and writing the new data. [...] The parity blocks are not read on data reads, since this would be unnecessary overhead and would diminish performance. The parity blocks are read, however, when a read of a data sector results in a cyclic redundancy check (CRC) error." Timestamp: 0x43EE7046 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RAID5 on athlon64 machines
> > > Theoretically the sequential write rate should be same or > > higher than the sequential read rate. Given an N+1 disk > > Seq write rate for the whole RAID5 array will always be lower > than the write rate for it's single disk. You compute max data rates by considering the most optimistic scenario, which is large sequetial writes. For *this* situation write rate will be higher than a single disk's. > The parity blocks are not read on data reads, since this would be > unnecessary overhead and would diminish performance. The parity > blocks are read, however, when a read of a data sector results > in a cyclic redundancy check (CRC) error." You can only do so if you know the array is consistent. If the system crashed there is no such guarantee. So you either have to rebuild the whole array to get to a consistent state or do a parity check. If you don't check parity and you have an inconsistent array, you can have a silent error (the data may be trashed but you don't know that). But if you use RAM without parity or ECC, you probably already don't care about such errors. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kern/60163
I heard from Chiharu Shibata <[EMAIL PROTECTED]> about kern/60163. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60163 (He knew that this pr was closed, recently) I cannot believe sos's close reason. ** The most significant problem is "Cannot mount CD-EXTRA multisession cd.". No related /dev/acdXtY. ** If there are no reason expect sos' close reason, the patch should be committed. How about this? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic Kernel Dump to umass device?
Ian Dowse wrote: > > The USB stack supports polled operations, so it's actually not to > hard to make this work. Below is a patch I had in one of my local > trees that adds a CAM poll handler to the umass driver. I've just > tested this and it does seem to make kernel dumping work, but I > guess it might not be as reliable as dumping to other devices. Thanks, that helps. It works nicely with a uhci USB controller. However when the ohci driver is in use, we crash somewhere in usb_transfer_complete. I'll look into this further. Cheers, Nate ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pre-loaded mfsroot size and FreeBSD 4.9 with 4G RAM
Jacques Fourie wrote: > > I have installed 6.0-RELEASE and the behaviour is still the same. If I try > to pre-load an md_image of 64M with 4G of RAM installed, the kernel panics > early in the boot cycle. Here is the panic on 6.0-RELEASE: > > 131072K of memory above 4GB ignored This is a kind of stupid question but is there any chance that the 64MB image overlaps with the PCI address hole? To elaborate: with 4GB memory installed there would be no address range to access the memory-mapped 32-bit PCI cards. So the motherboard circuitry relocates some amount of memory (the 128MB shown above) from some lower address to above 4GB and frees this address space below 4GB for mapping of the PCI cards. So the interesting question is: what is the address of this PCI hole and what is the loading address of the FreeBSD md_image? If they overlap then naturally a part of the image would go into nowhere and cause a panic. On my machine this PCI hole can be disabled in BIOS (I think so, there is also some kind of configuration in BIOS but I did not pay much attention to it as I don't have 4GB). -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
