Hi there,
Any reason why dmi_scan is availble on the i386 arch and not on the
x86_64 arch? I would have a need for the latter (for run-time
identification purposes, not boot-time blacklisting).
Thanks,
Jean Delvare
On Wed, Nov 03, 2004 at 01:10:14PM +0100, Jean Delvare wrote:
>
> Hi there,
>
> Any reason why dmi_scan is availble on the i386 arch and not on the
> x86_64 arch? I would have a need for the latter (for run-time
> identification purposes, not boot-time blacklisting).
So far nothing needed it, so I didn't add it. For what do you need it?
-Andi
Hi Andi,
> > Any reason why dmi_scan is availble on the i386 arch and not on the
> > x86_64 arch? I would have a need for the latter (for run-time
> > identification purposes, not boot-time blacklisting).
>
> So far nothing needed it, so I didn't add it. For what do you need it?
I am in the process of adding SMBus multiplexing support for the Tyan
S4882 motherboard, as seen on this thread:
http://marc.theaimsgroup.com/?l=linux-kernel&m=109863982018999&w=2
In the proposed patch, I use the PCI ID of the SMBus master to identify
the board and enable the additional code. However, I just asked for
confirmation to the Tyan engineers I am working with and they told me
that the PCI ID has not been customized (I should have figured that out
by myself since the subvendor ID was AMD's, not Tyan's, but well
sometimes you just don't get it). Thus my approach is not correct.
One possible approach would be to use the DMI data, since it is properly
set on the S4882 motherboard:
Handle 0x0001
DMI type 1, 25 bytes.
System Information
Manufacturer: TYAN
Product Name: S4882
Thus my question. As you can see, what I would need is merely an
include/linux/dmi.h-like interface that would work for x86_64 instead of
only i386. I do not need the dmi_scan blacklisting mechanism, just the
part which fetches and stores DMI data for later use. As a side note, I
wonder if this can be done without duplicating a large part of
arch/i386/kernel/dmi_scan.c.
Before you ask, detecting the need of SMBus multiplexing by somehow
scanning the SMBus is believed to be unreliable and possibly dangerous,
which is why I favor the approach of a list of known boards to enable
the multiplexing on.
Thanks,
Jean
On Wed, Nov 03, 2004 at 02:12:07PM +0100, Jean Delvare wrote:
>
> Hi Andi,
>
> > > Any reason why dmi_scan is availble on the i386 arch and not on the
> > > x86_64 arch? I would have a need for the latter (for run-time
> > > identification purposes, not boot-time blacklisting).
> >
> > So far nothing needed it, so I didn't add it. For what do you need it?
>
> I am in the process of adding SMBus multiplexing support for the Tyan
> S4882 motherboard, as seen on this thread:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109863982018999&w=2
Here's a patch for testing.
-Andi
Index: linux/arch/x86_64/kernel/setup.c
===================================================================
--- linux.orig/arch/x86_64/kernel/setup.c 2004-11-03 15:21:16.%N +0100
+++ linux/arch/x86_64/kernel/setup.c 2004-11-03 15:21:16.%N +0100
@@ -40,6 +40,7 @@
#include <linux/acpi.h>
#include <linux/kallsyms.h>
#include <linux/edd.h>
+#include <linux/dmi.h>
#include <asm/mtrr.h>
#include <asm/uaccess.h>
#include <asm/system.h>
@@ -1120,3 +1121,12 @@
.stop = c_stop,
.show = show_cpuinfo,
};
+
+/* We don't need DMI early, so call it later after bootmem when
+ ioremap works. */
+static __init void call_dmi(void)
+{
+ dmi_scan_machine();
+}
+core_initcall(call_dmi);
+
\ No newline at end of file
Index: linux/arch/x86_64/kernel/Makefile
===================================================================
--- linux.orig/arch/x86_64/kernel/Makefile 2004-11-03 15:21:16.%N +0100
+++ linux/arch/x86_64/kernel/Makefile 2004-11-03 15:21:16.%N +0100
@@ -6,7 +6,7 @@
EXTRA_AFLAGS := -traditional
obj-y := process.o semaphore.o signal.o entry.o traps.o irq.o \
ptrace.o time.o ioport.o ldt.o setup.o i8259.o sys_x86_64.o \
- x8664_ksyms.o i387.o syscall.o vsyscall.o \
+ x8664_ksyms.o i387.o syscall.o vsyscall.o dmi_scan.o \
setup64.o bootflag.o e820.o reboot.o warmreboot.o quirks.o
obj-$(CONFIG_X86_MCE) += mce.o
@@ -41,3 +41,4 @@
microcode-$(subst m,y,$(CONFIG_MICROCODE)) += ../../i386/kernel/microcode.o
intel_cacheinfo-y += ../../i386/kernel/cpu/intel_cacheinfo.o
quirks-y += ../../i386/kernel/quirks.o
+dmi_scan-y += ../../i386/kernel/dmi_scan.o
Index: linux/arch/i386/kernel/dmi_scan.c
===================================================================
--- linux.orig/arch/i386/kernel/dmi_scan.c 2004-10-19 01:55:01.%N +0200
+++ linux/arch/i386/kernel/dmi_scan.c 2004-11-03 15:28:49.%N +0100
@@ -11,6 +11,12 @@
#include <linux/dmi.h>
#include <linux/bootmem.h>
+#ifdef CONFIG_X86_64
+#define bt_ioremap ioremap
+#define bt_iounmap(a,b) iounmap(a)
+#define alloc_bootmem(a) kmalloc(a, GFP_ATOMIC)
+#endif
+
int es7000_plat = 0;
@@ -162,6 +168,9 @@
#define NO_MATCH { DMI_NONE, NULL}
#define MATCH DMI_MATCH
+/* Before you add x86-64 specific entries here move this to a sepatate file. */
+#ifndef CONFIG_X86_64
+
/*
* Toshiba keyboard likes to repeat keys when they are not repeated.
*/
@@ -251,6 +260,8 @@
}
#endif
+#endif
+
/*
* Process the DMI blacklists
*/
@@ -263,6 +274,8 @@
static __initdata struct dmi_blacklist dmi_blacklist[]={
+#ifndef CONFIG_X86_64
+
{ broken_toshiba_keyboard, "Toshiba Satellite 4030cdt", { /* Keyboard generates spurious repeats */
MATCH(DMI_PRODUCT_NAME, "S4030CDT/4.3"),
NO_MATCH, NO_MATCH, NO_MATCH
@@ -441,6 +454,8 @@
#endif
+#endif
+
{ NULL, }
};
Index: linux/include/linux/dmi.h
===================================================================
--- linux.orig/include/linux/dmi.h 2004-08-15 19:45:50.%N +0200
+++ linux/include/linux/dmi.h 2004-11-03 15:21:16.%N +0100
@@ -32,7 +32,7 @@
#define DMI_MATCH(a,b) { a, b }
-#if defined(CONFIG_X86) && !defined(CONFIG_X86_64)
+#if defined(CONFIG_X86)
extern int dmi_check_system(struct dmi_system_id *list);
extern char * dmi_get_system_info(int field);
@@ -44,4 +44,6 @@
#endif
+extern void dmi_scan_machine(void);
+
#endif /* __DMI_H__ */
> > Any reason why dmi_scan is availble on the i386 arch and not on the
> > x86_64 arch? I would have a need for the latter (for run-time
> > identification purposes, not boot-time blacklisting).
>
> Here's a patch for testing.
Thanks Andi. Unfortunately, I don't own an x86_64 system myself, so I
won't be able to test your code. The system I have been working on had
been made temporarily remotely accessible to me by Tyan, but working on
kernel stuff remotely on a system you don't really control isn't
convenient, as you may easily imagine. I had them reboot it manually
several times (for some reason the box wouldn't reboot by itself when
asked to).
I think I need to get my hands on an x86_64 system I could really play at
will with, as more and more Linux individuals and companies are using
these. Any Linux-oriented company wanting to support the projects I am
working on (lm_sensors [1], dmidecode [2] and linux 2.6 itself) through
the donation of an x86_64 system?
Thanks,
Jean
[1] http://www.lm-sensors.nu/
[2] http://www.nongnu.org/dmidecode/
On Wed, Nov 03, 2004 at 04:19:39PM +0100, Jean Delvare wrote:
>
> > > Any reason why dmi_scan is availble on the i386 arch and not on the
> > > x86_64 arch? I would have a need for the latter (for run-time
> > > identification purposes, not boot-time blacklisting).
> >
> > Here's a patch for testing.
>
> Thanks Andi. Unfortunately, I don't own an x86_64 system myself, so I
Ok. I won't push the patch then when it isn't really needed.
-Andi
On 3/11/2004, Andi Kleen wrote:
> Ok. I won't push the patch then when it isn't really needed.
Fair enough, agreed.
Thanks,
Jean
On 03.11.2004, at 16:19, Jean Delvare wrote:
> Thanks Andi. Unfortunately, I don't own an x86_64 system myself, so I
> won't be able to test your code. The system I have been working on had
> been made temporarily remotely accessible to me by Tyan, but working on
> kernel stuff remotely on a system you don't really control isn't
> convenient, as you may easily imagine. I had them reboot it manually
> several times (for some reason the box wouldn't reboot by itself when
> asked to).
Is this stuff any relevant to a Tyan Tiger K8W (S2875), i.e. is Tyan
employing the multiplexing trick on several boards or just the one you
tried to identify?
Servus,
Daniel
Hi Daniel,
> Is this stuff any relevant to a Tyan Tiger K8W (S2875), i.e. is Tyan
> employing the multiplexing trick on several boards or just the one you
> tried to identify?
The SMBus multiplexing is rarely used and highly board dependent. I have
no reason to believe that the Tyan Tiger K8W (S2875) has its SMBus
multiplexed (and if it were, it would require different, although
similar, code than I wrote for the S4882 anyway).
For reference, the only boards I know for sure use a form of multiplexing
for their hardware monitoring capabilities are the Iwill MPX2 and the
Gigabyte GA7 DPXDW+. Both use LM90 chips. One of them (can't remember
which) does true SMBus multiplexing over two of these, while the other
has a single chip which can be routed to either of two thermal diodes.
The sensors drivers don't support these setups yet.
I think I also remember of a board where fan inputs were somehow
multiplexed (the board had six fan headers, all of them reported speeds
in the BIOS setup screen, but the hardware monitoring chip would only
have three tachometers inputs.) I can't seem to remember the brand and
model, and we did not investigate the problem deep enough to propose a
solution back then anyway.
As a matter of fact, my proposal to support the S4882 SMBus multiplexing
is the first attempt to support this kind of setup. Note that other
proposals were already made but they were aimed at supporting home-made
setups, not publicly available motherboards.
--
Jean
On 04.11.2004, at 10:12, Jean Delvare wrote:
> I think I also remember of a board where fan inputs were somehow
> multiplexed (the board had six fan headers, all of them reported speeds
> in the BIOS setup screen, but the hardware monitoring chip would only
> have three tachometers inputs.) I can't seem to remember the brand and
> model, and we did not investigate the problem deep enough to propose a
> solution back then anyway.
The sensors conf for the S2875 provided by Tyan only displays
3 FAN RPM values while the board has at least 4. At the moment I'm
using 3 fans with tacho signal but can only determine 2 values, the
third value is constantly 0.
Also the setup puzzles me a bit; why would Tyan pack several SMBus
setups into a single motherboard but only connect devices to one
of them. Actually sensors-detect claims that there is one
unrecognized client on the "unused" SMBus.
Servus,
Daniel
On 4/11/2004, Daniel Egger wrote:
> The sensors conf for the S2875 provided by Tyan only displays
> 3 FAN RPM values while the board has at least 4. At the moment I'm
> using 3 fans with tacho signal but can only determine 2 values, the
> third value is constantly 0.
The (admittedly limited) documentation [1] I have for the S2875 states
that only 3 of the 6 fan headers have their tachometer pin wired. This
matches the W83627HF hardware monitoring chip capabilities, which is why
I see no evidence of any kind of multiplexing on that board.
> Also the setup puzzles me a bit; why would Tyan pack several SMBus
> setups into a single motherboard but only connect devices to one
> of them. Actually sensors-detect claims that there is one
> unrecognized client on the "unused" SMBus.
Not all SMBus clients are hardware monitoring chips. The fact that
sensors-detect didn't recognize it would even suggest that your unknown
chip isn't. What you see may be about anything, including
pseudo-clients used for the SMBus protocol itself.
Feel free to submit a dump (using i2cdump) of that unknown chip if you
want me to comment on it.
As a side note, Tyan actually has a long history of embedding more than
one hardware monitoring chip in their high-end server boards. This makes
full sense when the board has plenty of fan headers and supports several
CPU. The S4882 for example has 6 hardware monitoring chips, and this is
one reason why the SMBus had to be multiplexed (4 of these chips use the
same address).
[1] ftp://ftp.tyan.com/datasheets/d_s2875_120.pdf
Jean
On 04.11.2004, at 14:02, Jean Delvare wrote:
> The (admittedly limited) documentation [1] I have for the S2875 states
> that only 3 of the 6 fan headers have their tachometer pin wired. This
> matches the W83627HF hardware monitoring chip capabilities, which is
> why
> I see no evidence of any kind of multiplexing on that board.
Ah, I start to make sense of what exactly you're doing.
> Not all SMBus clients are hardware monitoring chips. The fact that
> sensors-detect didn't recognize it would even suggest that your unknown
> chip isn't. What you see may be about anything, including
> pseudo-clients used for the SMBus protocol itself.
> Feel free to submit a dump (using i2cdump) of that unknown chip if you
> want me to comment on it.
egger@ulli:~$ sudo i2cdetect -l
i2c-2 unknown SMBus2 AMD8111 adapter at c400
Algorithm unavailable
i2c-1 dummy ISA main adapter ISA bus
algorithm
i2c-0 unknown SMBus AMD756 adapter at 50e0
Algorithm unavailable
egger@ulli:~$ sudo i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-2.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: XX XX XX XX XX 08 XX XX XX XX XX XX XX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
70: XX XX XX XX XX XX XX XX
egger@ulli:~$ sudo i2cdump 2 8
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-2, address 0x8, mode byte
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
Anything else I can try?
Servus,
Daniel
> > Feel free to submit a dump (using i2cdump) of that unknown chip if you
> > want me to comment on it.
>
> egger@ulli:~$ sudo i2cdetect -l
> i2c-2 unknown SMBus2 AMD8111 adapter at c400
> (...)
> egger@ulli:~$ sudo i2cdetect 2
> (...)
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: XX XX XX XX XX 08 XX XX XX XX XX XX XX
> 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 70: XX XX XX XX XX XX XX XX
According to the SMBus 2.0 specs [1], page 59, address 0x08 represents
the SMBus host itself, so it's not a client. This SMBus is empty.
> Anything else I can try?
No, this bus is simply empty, no need to look any further. For some
reason these AMD chipsets have two different SMBus. Most motherboard
manufacturers only use the first one.
Jean
[1] http://www.smbus.org/specs/smbus20.pdf
On 04.11.2004, at 16:30, Jean Delvare wrote:
> According to the SMBus 2.0 specs [1], page 59, address 0x08 represents
> the SMBus host itself, so it's not a client. This SMBus is empty.
>
>> Anything else I can try?
>
> No, this bus is simply empty, no need to look any further. For some
> reason these AMD chipsets have two different SMBus. Most motherboard
> manufacturers only use the first one.
Thanks for your detective work.
Servus,
Daniel