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)
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
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: [PATCH] enable auto=yes by default when using udev
On Tue, Jul 04, 2006 at 02:29:10PM +0400, Michael Tokarev wrote:
Why to test for udev at all? If the device does not exist, regardless
because udev whas what was giving me pains :)
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
i believe we can set autof to 2 by default.
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.
we need to distinguish between explicit auto=no, explicit auto=yes and
implicit auto=yes for this. maybe this is overkill
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.
agreed!
L.
--
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
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
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: 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
