Re: Linux SATA Support Question - Is the ULI M1575 chip supported?
On Mon, 3 Jul 2006, Jeff Garzik wrote:
Justin Piszcz wrote:
In the source:
enum {
uli_5289= 0,
uli_5287= 1,
uli_5281= 2,
uli_max_ports = 4,
/* PCI configuration registers */
ULI5287_BASE= 0x90, /* sata0 phy SCR registers */
ULI5287_OFFS= 0x10, /* offset from sata0-sata1 phy
regs */
ULI5281_BASE= 0x60, /* sata0 phy SCR registers */
ULI5281_OFFS= 0x60, /* offset from sata0-sata1 phy
regs */
};
However, in the manual for this motherboard it states it has a ULI M1575,
can anyone comment?
http://us.dfi.com.tw/Upload/Manual/90800601.pdf
What is the PCI ID?
Jeff
Don't have the board yet, researching different motherboards for Linux
compatbility -before- purchase..
Justin.
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enable auto=yes by default when using udev
Neil Brown wrote: On Monday July 3, [EMAIL PROTECTED] wrote: Hello, the following patch aims at solving an issue that is confusing a lot of users. when using udev, device files are created only when devices are registered with the kernel, and md devices are registered only when started. mdadm needs the device file _before_ starting the array. so when using udev you must add --auto=yes to the mdadm commandline or to the ARRAY line in mdadm.conf following patch makes auto=yes the default when using udev The principle I'm reasonably happy with, though you can now make this the default with a line like CREATE auto=yes in mdadm.conf. However + +/* if we are using udev and auto is not set, mdadm will almost + * certainly fail, so we force it here. + */ +if (autof == 0 access(/dev/.udevdb,F_OK) == 0) +autof=2; + I'm worried that this test is not very robust. On my Debian/unstable system running used, there is no /dev/.udevdb though there is a /dev/.udev/db I guess I could test for both, but then udev might change again I'd really like a more robust check. Why to test for udev at all? If the device does not exist, regardless if udev is running or not, it might be a good idea to try to create it. Because IT IS NEEDED, period. Whenever the operation fails or not, and whenever we fail if it fails or not - it's another question, and I think that w/o explicit auto=yes, we may ignore create error and try to continue, and with auto=yes, we fail on create error. Note that /dev might be managed by some other tool as well, like mudev from busybox, or just a tiny shell /sbin/hotplug script. Note also that the whole root filesystem might be on tmpfs (like in initramfs), so /dev will not be a mountpoint. Also, I think mdadm should stop creating strange temporary nodes somewhere as it does now. If /dev/whatever exist, use it. If not, create it (unless, perhaps, auto=no is specified) directly with proper mknod(/dev/mdX), but don't try to use some temporary names in /dev or elsewhere. In case of nfs-mounted read-only root filesystem, if someone will ever need to assemble raid arrays in that case.. well, he can either prepare proper /dev on the nfs server, or use tmpfs-based /dev, or just specify /tmp/mdXX instead of /dev/mdXX - whatever suits their needs better. /mjt - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enable auto=yes by default when using udev
On Tue, Jul 04, 2006 at 12:46:03AM +0200, Luca Berra wrote: On Mon, Jul 03, 2006 at 09:14:38AM +1000, Neil Brown wrote: However + + /* if we are using udev and auto is not set, mdadm will almost +* certainly fail, so we force it here. +*/ + if (autof == 0 access(/dev/.udevdb,F_OK) == 0) + autof=2; + I'm worried that this test is not very robust. On my Debian/unstable system running used, there is no /dev/.udevdb though there is a /dev/.udev/db I guess I could test for both, but then udev might change again I'd really like a more robust check. is /dev/.udev/db a debianism? no it is not in this case a check for both might suffice, else i will have to think harder about it. -- Luca Berra -- [EMAIL PROTECTED] Communication Media Services S.r.l. /\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enable auto=yes by default when using udev
Michael Tokarev [EMAIL PROTECTED] wrote: Why to test for udev at all? If the device does not exist, regardless if udev is running or not, it might be a good idea to try to create it. Because IT IS NEEDED, period. Whenever the operation fails or not, and Perhaps it was just a typo and you damage more if you just create it. Typical behaviour is to *not* just create device nodes because they don't exist but instead assume administrators know what they do. That's why I personally think it's better to rely on administrator's decision about automatic creation of device nodes. regards Mario -- As a rule, the more bizarre a thing is, the less mysterious it proves to be. -- Sherlock Holmes by Arthur Conan Doyle - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux SATA Support Question - Is the ULI M1575 chip supported?
On 04/07/06, Jeff Garzik [EMAIL PROTECTED] wrote:
Justin Piszcz wrote:
In the source:
enum {
uli_5289= 0,
uli_5287= 1,
uli_5281= 2,
uli_max_ports = 4,
/* PCI configuration registers */
ULI5287_BASE= 0x90, /* sata0 phy SCR registers */
ULI5287_OFFS= 0x10, /* offset from sata0-sata1 phy
regs */
ULI5281_BASE= 0x60, /* sata0 phy SCR registers */
ULI5281_OFFS= 0x60, /* offset from sata0-sata1 phy
regs */
};
However, in the manual for this motherboard it states it has a ULI
M1575, can anyone comment?
http://us.dfi.com.tw/Upload/Manual/90800601.pdf
What is the PCI ID?
Jeff
Sure this won't help, but just in case... my board:
http://www.asrock.com/product/939Dual-SATA2.htm
Chipset - Northbridge: ULi M1695
- Southbridge: ULI M1567
PCI ID of Southbridge in lspci output below looks like 5289
00:00.0 Host bridge: ALi Corporation M1695 K8 Northbridge [PCI Express
and HyperTransport]
00:01.0 PCI bridge: ALi Corporation: Unknown device 524b
00:02.0 PCI bridge: ALi Corporation: Unknown device 524c
00:04.0 Host bridge: ALi Corporation M1689 K8 Northbridge [Super K8 Single Chip]
00:05.0 PCI bridge: ALi Corporation AGP8X Controller
00:06.0 PCI bridge: ALi Corporation M5249 HTT to PCI Bridge
00:07.0 ISA bridge: ALi Corporation M1563 HyperTransport South Bridge (rev 70)
00:07.1 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
00:11.0 Ethernet controller: ALi Corporation M5263 Ethernet Controller (rev 40)
00:12.0 IDE interface: ALi Corporation M5229 IDE (rev c7)
00:12.1 IDE interface: ALi Corporation ULi 5289 SATA (rev 10)
00:13.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
00:13.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
snip
Justin: I'm using 2.6.17.1 and the sata_uli driver seems to be
handling the SATA drives just fine. But as I say, it's a different
southbridge, so apologies if I'm just contributing to the noise :o)
Not sure if this is comprehensive: http://pci-ids.ucw.cz/iii/?i=10b9
It doesn't appear to list the M1575's pci id there.
adam
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
