elease 2.7 for now. 2.6 has no known
problem so far, and there aren't enough significant improvements in CVS
to justify a new release IMHO.
Thanks,
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
major problems are found in 2.6 before then, of course.
Thanks,
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
do it only if it is
relatively straightforward.
Thanks,
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
dback I get from the users, I might have to
change a few things.
Thanks,
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
s may benefit from the new command line interface, although
this interface shouldn't be considered stable until version 2.8, as it
may evolve depending on the feedback I receive.
* Six product names were added to vpddecode.
Thanks,
--
Jean Delvare
__
gt; DJGPP issue, so someone with DJGPP
knowledge would probably be more helpful.
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
he
default). I guess mmap() isn't available on DOS, so you edit the
Makefile to remove that define from CFLAGS, which should let you go
around the problem.
Anyway, this is precisely the part of the code you will need to replace,
so it doesn't really m
Hi Ian,
[Ian Anderson]
> Got in touch with Eric Auer over at FreeDOS and his suggestion was
> to use _farpeekb or DPMI access.
>
> http://www.delorie.com/djgpp/doc/libc-2.02/libc_270.html
>
> or
>
> http://www.delorie.com/djgpp/doc/libc-2.02/libc_8.html
>
> _farpeekb seems a lot simpler. If I
rate these changes in the
mainline sources though, because I would be unable to maintain
compatibility afterwards (not having a test system).
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
should probably remove to make the returned strings more suitable for
scripting. I'll work on that later this week.
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
ted files at the right
time using "type". Such files can be static [1], or can be generated on
the fly using debug [2]. Second solution is a small DOS binary called
ech.com which does exactly "echo -n" [3].
[1] http://www.ericphelps.com/batch/lines/frag-man.htm
[2] h
cessor-frequency
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
tic, BTW, as I
am not willing to fix warnings caused by these.
The warning about 'strcasecmp' is correct, I was not including the
correct header file. I was including instead of .
I had never realized these were two different header files. For some
reason it didn't cause a
urse, both
together saves even more). So if -Os actually seems to cause trouble on
ia64, you may want to use stripped -O1 instead.
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
he command line interface
(both dmidecode and vpddecode) and IBM systems (vpddecode).
Thanks,
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
Hi Petter,
[Jean Delvare]
> > I plan to release version 2.8 within the next two weeks. I would
> > welcome any tester of the current CVS version. Please report if
> > anything doesn't look right, be it a compilation or runtime issue.
[Petter Reinholdtsen]
> I ge
thinkpad. I tested both
> dmidecode and vpddecode. :)
I'm glad to read this. Thanks for the tests again!
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
/dmidecode/dmidecode-2.8.tar.bz2
http://download.savannah.gnu.org/releases/dmidecode/dmidecode-2.8.tar.bz2.sig
http://download.savannah.gnu.org/releases/dmidecode/dmidecode-2.8.tar.gz
http://download.savannah.gnu.org/releases/dmidecode/dmidecode-2.8.tar.gz.sig
Thanks,
--
Je
[Jean Delvare]
> > Dmidecode 2.8 was released yesterday as was initially planned. The
> > changes from 2.7 are as follows:
[Petter Reinholdtsen]
> Great to hear. I just found time to make a new Debian release. It
> was uploaded into Debian a few minutes ago, and should b
[Jean Delvare]
> > Well, the format change which happened in version 2.7 was rather
> > more intrusive, and nobody complained as far as I know. I don't
> > expect the removal of a trailing period to affect anyone out there.
[Petter Reinholdtsen]
> I guess we will find
p the
lookup table from vpddecode. Providing no product name is IMHO better
than providing inaccurate or wrong data, and this will lower the
maintenance effort as a nice side effect.
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmid
gt; has anyone else noticed this? can anyone give me some kind of advice on
> where I can modify the source to try to get this information regardless
> of whether or not some of the attributes are NULL?
No, I've never seen this. All systems in my test suite have size 8 for
this struct
Hi Talmai,
[Jean Delvare]
> > Please provide the output of:
> > dmidecode -t 2
> > dmidecode -u -t 2
[Talmai Oliveira]
> Its the same output for both commands:
>
> # dmidecode 2.8
> SMBIOS 2.3 present.
I see. The table is broken so dmidecode fails to locate this
t
that's certainly a personal point of view ;)
Put in short, setting up that kind of survey takes a lot of time if you
want it to be reliable and successful, and I just don't have that much
time for it, nor do I think the benefit is worth the investment. But
anyone can do that, if they think it's worth the effort.
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
versions. For example running
> the command like this:
>
> diff -ur dmidecode-original-sourcedir dmidecode-forwindows-sourcedir
>
> Send the resulting text file to this list.
I will only consider taking these changes if they are non-intrus
ou can then send here.
The mailing-list strips binary attachements, anyway.
> Also, I forgot to mention the besides dmidecode.dev there's another new file
> native.h.
>
> Here's the new diff, think I got I right now
--
Jean Delvare
configured in an admittedly conservative
way. I don't want people to flood the subscribers with large binary
files. The list only accepted attachements are plain text and patches.
Come on, we are asking for a clean patch with only your changes. It's
not that difficult.
diff -ruN dmidecode-
sion of
dmidecode since then. I hope to be able to sort out the main pending
issues by February (most notably SMBIOS 2.5 support) and release
version 2.9 then.
Thanks,
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
the manufacturer
documentation by yourself.
> If there is a way to do it, does it depend (the detection) on the system
> running an smp kernel?
No, the DMI table is written by the BIOS before the OS is even started.
> Cannot look at /proc/cpuinfo since kernel 2.4 doesn't show the numbe
machine
myself.
Thanks,
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
Giulio,
On Mon, 12 Feb 2007 14:09:11 +0100, Jean Delvare wrote:
> On Thu, 19 Oct 2006 12:47:54 +0200, Giulio Orsero wrote:
> > Linux 2.4
> >
> > How, if possible, to detect whether the running processor is a dual-core one
> > using dmidecode?
>
> The proce
Giulio,
On Fri, 16 Feb 2007 21:59:50 +0100, Giulio Orsero wrote:
> On 2/16/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
>
> > Processor Information
> >(...)
> >Core Count: 2
> >Core Enabled: 2
> >Thread Count: 2
> &
.tar.gz
http://download.savannah.gnu.org/releases/dmidecode/dmidecode-2.9.tar.gz.sig
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
-dimms.pl script that comes with lm-sensors.
Using the DMI data is definitely the easiest way to achieve what you
want to do, but of course it will only work on systems those DMI table
holds reliable information.
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
m, Windows is exposing different data depending on who is asking.
There's nothing I can do about it in dmidecode. If there's any way to address
the problem, that would be something for the cygwin folks to investigate.
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
em is hardware (or more likely BIOS) specific.
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
On Fri, 30 May 2008 13:40:54 +0200, Tomasz Chmielewski wrote:
> Jean Delvare schrieb:
> > Hi Tomasz,
> >
> > On Fri, 30 May 2008 12:03:21 +0200, Tomasz Chmielewski wrote:
> >> To use a SYSTEM account - as an Administrator, run in cmd.exe window:
> >
tests on such machines, but my
coverage is relatively limited compared to the large number of SMBIOS
2.3 and 2.4 tables I have access to. I am also interested in tests on
non-x86 hardware and non-Linux systems, as I wasn't able to test many
of these lately.
Thank
/dmidecode/dmidecode-2.10.tar.bz2
http://download.savannah.gnu.org/releases/dmidecode/dmidecode-2.10.tar.bz2.sig
http://download.savannah.gnu.org/releases/dmidecode/dmidecode-2.10.tar.gz
http://download.savannah.gnu.org/releases/dmidecode/dmidecode-2.10.tar.gz.sig
--
Jean Delvare
On Sat, 06 Dec 2008 13:22:10 +0100, phcoder wrote:
> Hello I wrote a patch to be able to decode smbios/dmi dump. Just run
> dmidecode -i
> Vladimir 'phcoder' Serbinenko
This is already implemented in dmidecode 2.10.
--
Jean Delvare
_
ode have an entry point at the beginning of the file.
I am not sure why you want to use ioreg in the first place. Doesn't
dmidecode work on OSX?
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
;t want to depend on BIOS
correctness, then dmidecode isn't the tool you need. What you want is
the eeprom kernel driver together with the decode-dimms script from the
i2c-tools package [1]. It only works on systems where the SPD EEPROM on
the memory modules are exposed o
the faster the memory module.
You can read additional information on this topic on the
always-excellent wikipedia:
http://en.wikipedia.org/wiki/DDR2_SDRAM#Specification_standards
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
ave a spare higher speed module at hand or can
borrow one for a short period of time, you could just try to stick that
one module alone in the machine and see at which speed the BIOS says it
will run it. This should tell you right away if your system supports
that speed or not.
--
Jean Delva
for anyone with average C skills to get
into it. If you are looking for a small project to contribute to, this
may be a good opportunity, please think about it!
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
ror Information Handle: Not Provided
> Number Of Devices: 12
You're right, this is a bug. Good catch... it's been there since the
very beginning of dmidecode 2.x.
Bug fixed in CVS:
http://cvs.savannah.gnu.org/viewvc/dmidecode/dmidecode.c?root=dmidecode&r1=1.141&r2=1.142
Thanks for reporting.
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
lt;= 0x13)
> return type[code - 0x01];
> - if (code >= 0xA0 && code <= 0xAA)
> + if (code >= 0xA0 && code <= 0xB0)
> return type_0xA0[code - 0xA0];
> return out_of_spec;
> }
> @@ -2120,10 +2150,15 @@ static const char *dmi_memory_device_typ
> "RDRAM",
> "DDR",
> "DDR2",
> - "DDR2 FB-DIMM" /* 0x14 */
> + "DDR2 FB-DIMM",
> + "Reserved",
> + "Reserved",
> + "Reserved",
> + "DDR3",
> + "FBD2", /* 0x19 */
> };
>
> - if (code >= 0x01 && code <= 0x14)
> + if (code >= 0x01 && code <= 0x19)
> return type[code - 0x01];
> return out_of_spec;
> }
>
>
Other than that, it looks good to me (although I admit I did not
cross-check with the SMBIOS specifications). Thanks for your
contribution!
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
On Fri, 28 Aug 2009 11:23:35 -0400, Jarod Wilson wrote:
> On Friday 28 August 2009 11:05:06 Jean Delvare wrote:
> > Hi Jarod,
> >
> > On Thu, 27 Aug 2009 09:25:40 -0400, Jarod Wilson wrote:
> > > dmidecode: additions from smbios 2.6.1 spec update
> > >
>
On Fri, 28 Aug 2009 14:57:50 -0400, Jarod Wilson wrote:
> On Friday 28 August 2009 13:03:08 Jean Delvare wrote:
> > On Fri, 28 Aug 2009 11:23:35 -0400, Jarod Wilson wrote:
> > > On Friday 28 August 2009 11:05:06 Jean Delvare wrote:
> > > > Hi Jarod,
> > >
o there seems to be a consensus that serial numbers shouldn't be
disclosed to all users.
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
gt; { 0xE6, "Embedded Opteron Quad-Core" }, /* From
> CIM_Processor.Family */
> { 0xE7, "Phenom Triple-Core" }, /* From CIM_Processor.Family */
Thanks for reporting and thanks for the patch, I've just applied it to
CVS.
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
would appreciate if you could please run dmidecode --dump-bin
on these systems and share the dump files with me.
Thanks,
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
tions, I'll commit
these patches to the CVS repository next week.
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
:26.0 +0100
+++ dmidecode/dmidecode.c 2010-11-13 10:22:41.0 +0100
@@ -2,7 +2,7 @@
* DMI Decode
*
* Copyright (C) 2000-2002 Alan Cox
- * Copyright (C) 2002-2008 Jean Delvare
+ * Copyright (C) 2002-2010 Jean Delvare
*
* This program is free software; you can
e & 0x00FC) == 0)
printf(" None\n");
else
{
int i;
printf("\n");
- for (i = 2; i <= 2; i++)
+ for (i = 2; i <= 7; i++)
if (code & (1 << i))
printf("%s%s\n", prefix, characteristics[i -
2]);
}
@@ -3101,6 +3128,9 @@ static void dmi_decode(const struct dmi_
if (h->length < 0x15) break;
if (h->length < 0x15 + data[0x13] * data[0x14]) break;
dmi_chassis_elements(data[0x13], data[0x14], data +
0x15, "\t");
+ if (h->length < 0x16 + data[0x13] * data[0x14]) break;
+ printf("\tSKU Number: %s\n",
+ dmi_string(h, data[0x16 + data[0x13] *
data[0x14]]));
break;
case 4: /* 7.5 Processor Information */
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
(data + 0x08) -
DWORD(data + 0x04) + 1);
+ }
printf("\n");
if (!(opt.flags & FLAG_QUIET))
{
--- dmidecode.orig/util.c 2010-09-29 13:59:31.0 +0200
+++ dmidecode/util.c2010-11-11 18:27:33.0 +0100
@@ -201,3 +201,19 @@ err_close:
fclose(f);
return -1;
}
+
+/* Returns end - start + 1, assuming start < end */
+u64 u64_range(u64 start, u64 end)
+{
+ u64 res;
+
+ res.h = end.h - start.h;
+ res.l = end.l - start.l;
+
+ if (end.l < start.l)
+ res.h--;
+ if (++res.l == 0)
+ res.h++;
+
+ return res;
+}
--- dmidecode.orig/util.h 2008-10-28 11:12:19.0 +0100
+++ dmidecode/util.h2010-11-11 16:53:32.0 +0100
@@ -27,3 +27,4 @@
int checksum(const u8 *buf, size_t len);
void *mem_chunk(size_t base, size_t len, const char *devmem);
int write_dump(size_t base, size_t len, const void *data, const char
*dumpfile, int add);
+u64 u64_range(u64 start, u64 end);
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
if (data[0x04] == 0xF0) { /* OEM */
+ printf("\tVendor ID: 0x%02X%02X%02X%02X\n",
+ data[0x05], data[0x06], data[0x07],
+ data[0x08]);
+ }
+ break;
+
case 126: /* 7.44 Inactive */
printf("Inactive\n");
break;
--
Jean Delvare
___
http://lists.nongnu.org/mailman/listinfo/dmidecode-devel
On Sat, 13 Nov 2010 20:43:39 +0100, Jean Delvare wrote:
> Hi all,
>
> Here is a patch set adding support for SMBIOS 2.7.0 to dmidecode. I
> implemented almost everything except for the new type 42 which is kind
> of obscure, so I'm waiting to see actual implementations by
On Wed, 24 Nov 2010 14:54:37 +0100, Jean Delvare wrote:
> On Sat, 13 Nov 2010 20:43:39 +0100, Jean Delvare wrote:
> > Hi all,
> >
> > Here is a patch set adding support for SMBIOS 2.7.0 to dmidecode. I
> > implemented almost everything except for the new type 42 which
to find the next record.
> There's a new --broken-table parameter to use that mechanism. Without that
> flag, processing of the table is done as usual.
> Patch attached as well as a dump of the broken table.
I see no patch and no dump.
--
Jean Delvare
__
On Tue, 7 Dec 2010 16:19:45 +0100, Jean Delvare wrote:
> On Wed, 24 Nov 2010 14:54:37 +0100, Jean Delvare wrote:
> > Patches all committed. I think we want to release a new version of
> > dmidecode soon, so that distributions can include support for SMBIOS
> > 2.6.1 and 2.
_spec;
}
@@ -1660,12 +1678,18 @@ static const char *dmi_slot_type(u8 code
"PCI Express 2 x2",
"PCI Express 2 x4",
"PCI Express 2 x8",
- "PCI Express 2 x16", /* 0xB0 */
+ "P
sed to be always OK. I presume
you're explicitly passing a compilation flag to gcc (or whatever you're
using) to make it treat this as an error. Maybe -Wc++-compat?
Either stop using this compilation flag, or just explicitly cast the
result of mem_chunk() to u8 *.
--
Jean Delvare
_
e working together on such libification work ?
This has been proposed many times, and every time I suggest that anyone
in need of library-based DMI data access should simply use libsmbios
which offers exactly this:
http://linux.dell.com/libsmbios/download/libsmbios/
If there any p
n one logical processor." This covers both
hyper-threading (which your CPU doesn't implement) and multi-core
(which your CPU does implement.) So it's OK for your CPU to have the
HTT flag set and thus OK for dmidecode to tell you so.
[1] http://www.inte
Status: Populated, Enabled
Status: Unpopulated
#
That being, said, please keep in mind that on a given system, dmidecode
is only as accurate as its BIOS. If the BIOS fills the DMI table
incorrectly, then the information reported by dmidecode will be
incorrect too.
--
Jean Delvare
__
emory_voltage_value(u16
if (code == 0)
printf(" Unknown");
else
- printf(" %.3f V", (float)code / 1000);
+ printf(code % 100 ? " %g V" : " %.1f V", (float)code / 1000);
}
static const char
On Wed, 24 Apr 2013 08:18:54 -0400 (EDT), Anton Arapov wrote:
> I do agree with the change, seems three digits of precision is indeed
> unnecessary, will apply it.
Oh, I still have write access so I can commit it myself. Just wanted to
hear opinions before I do.
--
Jean D
ssary."
1500 would be displayed as "1.5 V" and 1350 as "1.35 V". I.e. exactly
what you want, if I understand correctly.
--
Jean Delvare
___
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
if you have any. I agree it would be great if we could decode
more / all of these HP-specific entries.
--
Jean Delvare
___
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
need.
[1] With one exception in legacy_decode, which is clearly an overlook as
it diverges from smbios_decode, so I'll fix it right now.
> And I forgot to mention:
> See the commit:
> http://cvs.savannah.gnu.org/viewvc/dmidecode/man/dmidecode.8?root=dmidecode&r1
Le Thursday 20 March 2014 à 11:45 +0100, Anton Arapov a écrit :
> On Thu, Mar 20, 2014 at 10:34:09AM +0100, Jean Delvare wrote:
> > (...)
> > Note that the message starts with hash marks. All other messages which
> > start with a hash mark are omitted in quiet mode [1]. Thus
er, all
questions on the mailing list were answered.
So I do not understand where you see any problem.
> Perhaps you can join the project and apply them yourself?
... which doesn't mean we do not welcome new contributors. We definitely
do :-)
--
Jean Delvare
SUSE L3 Supp
nly received notifications for
new bug reports and not new support requests, this is fixed now.
Such issues can also be discussed on this list.
--
Jean Delvare
SUSE L3 Support
___
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
e/dmi usable by user-space tools is IMHO a good hint
that the interface is screwed up.
I'd rather have the kernel export the 2 relevant memory chunks through
sysfs as raw, binary blobs. That way dmidecode could just fetch these
instead of reading from /dev/mem. This approach would require mini
On Thu, 5 Feb 2015 11:11:07 +, Leif Lindholm wrote:
> On Thu, Feb 05, 2015 at 10:58:39AM +0100, Jean Delvare wrote:
> > On Mon, 17 Nov 2014 11:36:35 +, Leif Lindholm wrote:
> > > Has anyone looked into using the /sys/firmware/dmi (CONFIG_DMI_SYSFS)
> > > int
#define MAX_ENTRY_TYPE 255 /* Most of these aren't used, but we consider
> >> the top entry type is only 8 bits */
> >>
> >> +static const u8 *smbios_raw_header;
It's called an entry point in the specification and every document out
there (including your own text above), why do you want to suddenly call
it a "header"? The term "header" is used to designate something
completely different in the context of DMI/SMBIOS data so I find it
quite confusing.
Please also note that the recently released version 3.0.0 of the SMBIOS
specification introduces a new entry point format, and the firmware is
allowed to implement both the old and the new format. It may be
desirable to expose both to user-space under different names.
Thanks,
--
Jean Delvare
SUSE L3 Support
___
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
I think you sent that already. If
you mean the code of the library itself, then I'd rather look at the
whole project than just a "patch". Where is it hosted?
--
Jean Delvare
SUSE L3 Support
___
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
ng the data you need from sysfs instead of /dev/mem is a good move
IMHO, and I will support that. But all you need in order to achieve
that is to let the kernel code export the entry point and the DMI table
as binary files. Plugging dmidecode on top of that should be pretty
straightforward and should
Hi Ivan,
On Wed, 04 Mar 2015 14:28:20 +0200, Ivan.khoronzhuk wrote:
> On 02/26/2015 11:41 AM, Jean Delvare wrote:
> > On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:
> >> Please also note that the recently released version 3.0.0 of the SMBIOS
> >> specifica
Hi Ivan,
On Sat, 07 Mar 2015 22:53:32 +0200, Ivan.khoronzhuk wrote:
> On 03/05/2015 09:46 AM, Jean Delvare wrote:
> > It's not just two tables (I don't expect a lot of BIOSes to provide two
> > tables in practice, and they would have essentially the same format
> &g
On Sun, 8 Mar 2015 14:53:04 +0100, Ard Biesheuvel wrote:
> On 8 March 2015 at 12:31, Jean Delvare wrote:
> > On Sat, 07 Mar 2015 22:53:32 +0200, Ivan.khoronzhuk wrote:
> >> The specification doesn't oblige firmware to provide two entry points.
> >> An implementati
On Sun, 8 Mar 2015 18:38:57 +0100, Ard Biesheuvel wrote:
> On 8 March 2015 at 18:11, Jean Delvare wrote:
> > On Sun, 8 Mar 2015 14:53:04 +0100, Ard Biesheuvel wrote:
> >> And the 32-bit entry point could well be 3.0 anyway, if
> >> it uses any of the new enum values f
Hi Ivan,
Sorry for the late reply. I think I addressed some points in other
replies already, but for completeness let me reply to this post too.
Le Wednesday 04 March 2015 à 14:30 +0200, Ivan.khoronzhuk a écrit :
> On 02/26/2015 11:36 AM, Jean Delvare wrote:
> > On Wed, 4 Feb 2015
work correctly without /dev/mem. Also patch adds
> raw dmi table to simplify dmi table processing in user space, as were
> proposed by Jean Delvare.
"as was proposed" or even "as proposed" sounds more correct.
BTW, which tree is your patch based on? I can't get it t
Hi Ivan,
On Thu, 19 Mar 2015 19:35:34 +0200, Ivan.khoronzhuk wrote:
> On 19.03.15 17:30, Jean Delvare wrote:
> > Le Monday 16 March 2015 à 22:57 +0200, Ivan Khoronzhuk a écrit :
> >> Some utils, like dmidecode and smbios, need to access SMBIOS entry
> >> table area
On Fri, 20 Mar 2015 12:00:34 +, Matt Fleming wrote:
> On Fri, 2015-03-20 at 09:16 +0100, Jean Delvare wrote:
> >
> > OK, I understand. Now I see the two patches I was missing, I'll pick
> > them so that I can apply your patch cleanly on top of my tree.
> >
&g
; >
> >59d7e3c02860 firmware: dmi_scan: Use direct access to static vars
> >d759d96eb5cc firmware: dmi_scan: Use full dmi version for SMBIOS3
> >
> > Am I still sending those for v4.1?
FWIW I have still not reviewed thes
t, or the new enumerated values, or both)?
Having a real-world example would make testing much easier.
Thanks,
--
Jean Delvare
SUSE L3 Support
___
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
correct
> purposes.
>
> Signed-off-by: Ivan Khoronzhuk
> ---
> drivers/firmware/dmi_scan.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
> (...)
Yes, as discussed before, good idea.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Su
/sys/firmware/dmi/
> +What:/sys/firmware/dmi/entries/
> Date:February 2011
> Contact: Mike Waychison
> Description:
Thanks for doing this.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
___
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
DMI table or BIOS
authoring tools.
If there really ever is a need to ignore the _SM3_ entry point, I'd
rather have a kernel boot parameter for this. This would guarantee that
the kernel and user-space applications always operate on the same data.
So I would keep the sysfs interface simple, as Ivan implemented it.
--
Jean Delvare
SUSE L3 Support
___
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
2015-04-16 10:00:19.180803593 +0200
@@ -2,7 +2,7 @@
* BIOS Decode
*
* Copyright (C) 2000-2002 Alan Cox
- * Copyright (C) 2002-2008 Jean Delvare
+ * Copyright (C) 2002-2015 Jean Delvare
*
* This program is free software; you can redistribute it and/or modify
* it under the
me route so that Linus has as
little merge work to do as possible. So either you pick them all, or I
do. If I do, you'll have to drop the 2 patches you have in efi-next.
Again I'm fine either way, so please let me know what makes your life
easier and let's do that.
Thanks,
--
Jean
orrectly without /dev/mem. Also patch adds
> raw dmi table to simplify dmi table processing in user space, as
> proposed by Jean Delvare.
>
> Signed-off-by: Ivan Khoronzhuk
> ---
> .../ABI/testing/sysfs-firmware-dmi-tables | 22 ++
> drivers/firmware/dmi-sysfs.c
}
>
> - if (smbios_decode(buf, opt.devmem))
> + if (smbios_decode(buf, opt.devmem, DWORD(buf + 0x18)))
> found++;
> goto done;
>
> @@ -4690,7 +4703,7 @@ memory_scan:
> {
> if (memcmp(buf + fp, "_SM_", 4) == 0 && fp <= 0xFFE0)
> {
> - if (smbios_decode(buf+fp, opt.devmem))
> + if (smbios_decode(buf+fp, opt.devmem, DWORD(buf + fp +
> 0x18)))
> {
> found++;
> fp += 16;
--
Jean Delvare
SUSE L3 Support
___
https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
Hi Ivan,
Le Thursday 16 April 2015 à 15:56 +0300, Ivan.khoronzhuk a écrit :
> On 16.04.15 12:52, Jean Delvare wrote:
> > On Thu, 2 Apr 2015 15:57:02 +0300, Ivan Khoronzhuk wrote:
> >> +static BIN_ATTR(smbios_entry_point, S_IRUSR, raw_table_read, NULL, 0);
> > This one co
Hi Ivan,
On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote:
> On 16.04.15 11:35, Jean Delvare wrote:
> > On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:
> >> Jean, do you want me to pick this patch up or are you going to?
> > Good question, we nee
while (r != 0);
> +
> + close(fd);
> + return p;
> +}
>
> int checksum(const u8 *buf, size_t len)
> {
> diff --git a/util.h b/util.h
> index e564292..ca8080e 100644
> --- a/util.h
> +++ b/util.h
> @@ -28,3 +28,4 @@ int checksum(const u8 *buf, size_t
_decode(buf+fp, opt.devmem))
> + if (smbios_decode(buf+fp, opt.devmem, DWORD(buf + fp +
> 0x18)))
> {
> found++;
> fp += 16;
> @@ -4698,7 +4715,7 @@ memor
1 - 100 of 493 matches
Mail list logo
