Re: Vectored syscalls Was: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
Hey, > On 8. Jul 2020, at 17:38, Greg Kroah-Hartman > wrote: > > On Wed, Jul 08, 2020 at 05:16:41PM +0200, René Rebe wrote: >> Hey there, >> >> maybe instead of this rather specific, niche readfile syscall, would it not >> be beneficial >> to allow issuing any group or bundle of several arbitrary system calls so >> this could also >> be used to speed up other, more demanding high performance applications that >> need >> a bit more than just readfile()? > > Why not just use io_uring for that for I/O calls, that's what it is > designed for. Sure, but last time I check you can’t queue open, read, close like this ;-) > More "generic" syscall batching always ends up falling down in > complexity anytime anyone tries it. Good luck! Well, given latest hardware security vulnerabilities it looks more useful for real world applications than the very special case of just readfile(2) for small to medium sized files, … any maybe more worth the effort of a new system call. René -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin, https://exactcode.com https://exactscan.com | https://ocrkit.com | https://t2sde.org | https://rene.rebe.de
Vectored syscalls Was: [PATCH 0/3] readfile(2): a new syscall to make open/read/close faster
Hey there,
maybe instead of this rather specific, niche readfile syscall, would it not be
beneficial
to allow issuing any group or bundle of several arbitrary system calls so this
could also
be used to speed up other, more demanding high performance applications that
need
a bit more than just readfile()?
An iImplementation could use some SYSCALLV syscall taking some io_uring like
structure with a list of flags, syscalls and arguments, so that this case could
be submitted
as something like (illustration purposes only):
{
{ABORT_ON_ERROR, OPEN, …},
{RET_TO_ARG1, READ, …},
{0, CLOSE, …},
}
I hope that sounds useful,
René Rebe
--
ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin, https://exactcode.com
https://exactscan.com | https://ocrkit.com | https://t2sde.org |
https://rene.rebe.de
Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel
Hi, On 17 Aug 2018, at 18:54, Andi Kleen wrote: > On Fri, Aug 17, 2018 at 06:15:45PM +0200, René Rebe wrote: >> Hey, >> >> is there any mainline future for this zstd support? Currently my most >> favourite compressor for this, and for what it’s worth zstd/initrd now even >> tested on #t2sde / hp/pa-risc, … https://www.youtube.com/watch?v=MHplOJxnIHk > > Can you remove some other compressor for the kernel image if you merge this? > > The "favourite compressor" seems to roughly change every year, so if > we keep adding new ones things will get more and more convoluted. Well, we (t2 formerly known as rocklinux) only changed our pkg archive compression from bzip2 to zstd once in 20 years ,-) > Surely zstd is universally better than some existing compressor > the kernel already uses for itself for a particular sweet spot? > If it isn't it's likely not needed. Well, IMHO this is not that much code, but if you want to remove something I guess bzip2 or LZMA may be candidates. http://zstd.net -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel
Hi, On 17 Aug 2018, at 18:54, Andi Kleen wrote: > On Fri, Aug 17, 2018 at 06:15:45PM +0200, René Rebe wrote: >> Hey, >> >> is there any mainline future for this zstd support? Currently my most >> favourite compressor for this, and for what it’s worth zstd/initrd now even >> tested on #t2sde / hp/pa-risc, … https://www.youtube.com/watch?v=MHplOJxnIHk > > Can you remove some other compressor for the kernel image if you merge this? > > The "favourite compressor" seems to roughly change every year, so if > we keep adding new ones things will get more and more convoluted. Well, we (t2 formerly known as rocklinux) only changed our pkg archive compression from bzip2 to zstd once in 20 years ,-) > Surely zstd is universally better than some existing compressor > the kernel already uses for itself for a particular sweet spot? > If it isn't it's likely not needed. Well, IMHO this is not that much code, but if you want to remove something I guess bzip2 or LZMA may be candidates. http://zstd.net -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel
Hey, is there any mainline future for this zstd support? Currently my most favourite compressor for this, and for what it’s worth zstd/initrd now even tested on #t2sde / hp/pa-risc, … https://www.youtube.com/watch?v=MHplOJxnIHk René On 10 Jul 2018, at 00:13, René Rebe wrote: > Hi Nick, > > On 09 Jul 2018, at 20:04, Nick Terrell wrote: > >>> On Mar 21, 2018, at 6:29 PM, Nick Terrell wrote: >>> This patch set adds support for a ZSTD-compressed kernel and ramdisk >>> images in the kernel boot process. It only integrates the support with >>> x86, though the first patch is generic to all architectures. >> >> Hi all, >> >> Is there anything blocking this from getting merged? >> Please let me know if there is anything I can do to help move this patch >> forward. > > works fine on my side, initrd test booted on i486, x86-64, ppc, ppc64 and > sparc64. For testing on mips64 I would first need to re-base the Octane^1 > patch-set ;-) > > Greetings, > René > > ^1) https://www.youtube.com/watch?v=AU_RV8uoTIo > > -- > ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin > http://exactcode.com | http://exactscan.com | http://ocrkit.com | > http://t2-project.org | http://rene.rebe.de > -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin DE Legal: Amtsgericht Berlin (Charlottenburg) HRB 105123B, Tax-ID#: DE251602478 Managing Director: René Rebe http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel
Hey, is there any mainline future for this zstd support? Currently my most favourite compressor for this, and for what it’s worth zstd/initrd now even tested on #t2sde / hp/pa-risc, … https://www.youtube.com/watch?v=MHplOJxnIHk René On 10 Jul 2018, at 00:13, René Rebe wrote: > Hi Nick, > > On 09 Jul 2018, at 20:04, Nick Terrell wrote: > >>> On Mar 21, 2018, at 6:29 PM, Nick Terrell wrote: >>> This patch set adds support for a ZSTD-compressed kernel and ramdisk >>> images in the kernel boot process. It only integrates the support with >>> x86, though the first patch is generic to all architectures. >> >> Hi all, >> >> Is there anything blocking this from getting merged? >> Please let me know if there is anything I can do to help move this patch >> forward. > > works fine on my side, initrd test booted on i486, x86-64, ppc, ppc64 and > sparc64. For testing on mips64 I would first need to re-base the Octane^1 > patch-set ;-) > > Greetings, > René > > ^1) https://www.youtube.com/watch?v=AU_RV8uoTIo > > -- > ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin > http://exactcode.com | http://exactscan.com | http://ocrkit.com | > http://t2-project.org | http://rene.rebe.de > -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin DE Legal: Amtsgericht Berlin (Charlottenburg) HRB 105123B, Tax-ID#: DE251602478 Managing Director: René Rebe http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel
Hi Nick, On 09 Jul 2018, at 20:04, Nick Terrell wrote: >> On Mar 21, 2018, at 6:29 PM, Nick Terrell wrote: >> This patch set adds support for a ZSTD-compressed kernel and ramdisk >> images in the kernel boot process. It only integrates the support with >> x86, though the first patch is generic to all architectures. > > Hi all, > > Is there anything blocking this from getting merged? > Please let me know if there is anything I can do to help move this patch > forward. works fine on my side, initrd test booted on i486, x86-64, ppc, ppc64 and sparc64. For testing on mips64 I would first need to re-base the Octane^1 patch-set ;-) Greetings, René ^1) https://www.youtube.com/watch?v=AU_RV8uoTIo -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel
Hi Nick, On 09 Jul 2018, at 20:04, Nick Terrell wrote: >> On Mar 21, 2018, at 6:29 PM, Nick Terrell wrote: >> This patch set adds support for a ZSTD-compressed kernel and ramdisk >> images in the kernel boot process. It only integrates the support with >> x86, though the first patch is generic to all architectures. > > Hi all, > > Is there anything blocking this from getting merged? > Please let me know if there is anything I can do to help move this patch > forward. works fine on my side, initrd test booted on i486, x86-64, ppc, ppc64 and sparc64. For testing on mips64 I would first need to re-base the Octane^1 patch-set ;-) Greetings, René ^1) https://www.youtube.com/watch?v=AU_RV8uoTIo -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel
Hi, On 22 Mar 2018, at 13:35, Adam Borowski <kilob...@angband.pl> wrote: > On Thu, Mar 22, 2018 at 12:09:45PM +0100, René Rebe wrote: >> Should this currently just work without any arch change on e.g. >> ppc64, sparc64 et al.? I could do a test build and boot if that is >> of any value, ... > > Initrd: no reason it wouldn't work, although for anything related to the > boot process testing is a very good idea. If you test, you'd really want to > apply that printk patch I posted, it's too easy to accidentally get a silent > fallback to gzip or uncompressed. I wonder, perhaps such a printk could be > permanently added, at a low message priority? zstd initrd worked on sparc64/sun4u - Ultra 30: https://www.youtube.com/watch?v=10q2OxHAzQ4 Any chance we could get this initrd zstd support upstream? > Kernel itself: needs per-arch porting, but it's not advertised in kconfig > outside x86 so that's not a problem. > > If you are knowledgeful about bootloaders on ppc64, sparc64, etc, such > information would be great. -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel
Hi, On 22 Mar 2018, at 13:35, Adam Borowski wrote: > On Thu, Mar 22, 2018 at 12:09:45PM +0100, René Rebe wrote: >> Should this currently just work without any arch change on e.g. >> ppc64, sparc64 et al.? I could do a test build and boot if that is >> of any value, ... > > Initrd: no reason it wouldn't work, although for anything related to the > boot process testing is a very good idea. If you test, you'd really want to > apply that printk patch I posted, it's too easy to accidentally get a silent > fallback to gzip or uncompressed. I wonder, perhaps such a printk could be > permanently added, at a low message priority? zstd initrd worked on sparc64/sun4u - Ultra 30: https://www.youtube.com/watch?v=10q2OxHAzQ4 Any chance we could get this initrd zstd support upstream? > Kernel itself: needs per-arch porting, but it's not advertised in kconfig > outside x86 so that's not a problem. > > If you are knowledgeful about bootloaders on ppc64, sparc64, etc, such > information would be great. -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
Re: [PATCH] k10temp support for AMD Ryzen w/ Vega gfx
Hi,
On 06 Mar 2018, at 11:06, Guenter Roeck <li...@roeck-us.net> wrote:
> On 03/05/2018 10:48 PM, René Rebe wrote:
>> Hi,
>> On 06 Mar 2018, at 00:03, Guenter Roeck <li...@roeck-us.net
>> <mailto:li...@roeck-us.net>> wrote:
>>> On Mon, Mar 05, 2018 at 11:38:24PM +0100, René Rebe wrote:
>>>> Hi,
>>>>
>>>> This enables k10temp for the new AMD Ryzen APUs w/ Vega Mobile Gfx.
>>>> Tested on Ryzen 5 2500U, the temperature looked plausible.
>>>>
>>>> Signed-off-by: René Rebe <r...@exactcode.de <mailto:r...@exactcode.de>>
>>>>
>>>> PS: 1st RFC - might get white-space damaged, will resend when ACKed.
>>>> Sorry my Xemacs/Mew broke.
>>>>
>>>> --- linux-4.15/drivers/hwmon/k10temp.c.vanilla2018-03-05
>>>> 22:22:30.974331180 +
>>>> +++ linux-4.15/drivers/hwmon/k10temp.c2018-03-05 22:24:17.186327291 +
>>>> @@ -40,6 +40,10 @@
>>>> #define PCI_DEVICE_ID_AMD_17H_DF_F30x1463
>>>> #endif
>>>>
>>>> +#ifndef PCI_DEVICE_ID_AMD_17H_RR_NB
>>>> +#define PCI_DEVICE_ID_AMD_17H_RR_NB0x15d0
>>>> +#endif
>>>> +
>>>> /* CPUID function 0x8001, ebx */
>>>> #define CPUID_PKGTYPE_MASK0xf000
>>>> #define CPUID_PKGTYPE_F0x
>>>> @@ -89,6 +93,8 @@
>>>> { 0x17, "AMD Ryzen Threadripper 1950", 1 },
>>>> { 0x17, "AMD Ryzen Threadripper 1920", 1 },
>>>> { 0x17, "AMD Ryzen Threadripper 1910", 1 },
>>>> +{ 0x17, "AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx", 2 },
>>>> +{ 0x17, "AMD Ryzen 7 2700U with Radeon Vega Mobile Gfx", 2 },
>>>
>>> Do you have a confirmation that the temperature offset is correct ?
>> I tried all of the three currently used offsets and this was looked the most
>> plausible.
>> For me having some indication of temperature is better than having none at
>> all.
>> Maybe some contact at AMD can shed some light on it, too?
>
> Per the information I got (not from AMD), those CPUs are not supposed to have
> an offset.
>
> Does the system have a Super-IO chip ? If so, what temperature does it report
> ?
> Also, what temperatures do you see with 0 offset ?
hm, interesting – as other Ryzens were marked with this offsets I did not
imagine the mobile ones would have none, …
Without offset it would mean the ideapad 720s would idle after fresh boot in a
(really) cold room at a little over 40°C.
The machine does not feel that warm, but maybe it is under the heatsink (my
boot w/ full-disk encryption takes a bit)?
Should I resend the patch without the offsets as baseline for other users to
test? Without the chipset PCI ID it obviously currently does not match on those
new mobile machines, ...
René
--
ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
http://exactcode.com | http://exactscan.com | http://ocrkit.com |
http://t2-project.org | http://rene.rebe.de
Re: [PATCH] k10temp support for AMD Ryzen w/ Vega gfx
Hi,
On 06 Mar 2018, at 11:06, Guenter Roeck wrote:
> On 03/05/2018 10:48 PM, René Rebe wrote:
>> Hi,
>> On 06 Mar 2018, at 00:03, Guenter Roeck > <mailto:li...@roeck-us.net>> wrote:
>>> On Mon, Mar 05, 2018 at 11:38:24PM +0100, René Rebe wrote:
>>>> Hi,
>>>>
>>>> This enables k10temp for the new AMD Ryzen APUs w/ Vega Mobile Gfx.
>>>> Tested on Ryzen 5 2500U, the temperature looked plausible.
>>>>
>>>> Signed-off-by: René Rebe mailto:r...@exactcode.de>>
>>>>
>>>> PS: 1st RFC - might get white-space damaged, will resend when ACKed.
>>>> Sorry my Xemacs/Mew broke.
>>>>
>>>> --- linux-4.15/drivers/hwmon/k10temp.c.vanilla2018-03-05
>>>> 22:22:30.974331180 +
>>>> +++ linux-4.15/drivers/hwmon/k10temp.c2018-03-05 22:24:17.186327291 +
>>>> @@ -40,6 +40,10 @@
>>>> #define PCI_DEVICE_ID_AMD_17H_DF_F30x1463
>>>> #endif
>>>>
>>>> +#ifndef PCI_DEVICE_ID_AMD_17H_RR_NB
>>>> +#define PCI_DEVICE_ID_AMD_17H_RR_NB0x15d0
>>>> +#endif
>>>> +
>>>> /* CPUID function 0x8001, ebx */
>>>> #define CPUID_PKGTYPE_MASK0xf000
>>>> #define CPUID_PKGTYPE_F0x
>>>> @@ -89,6 +93,8 @@
>>>> { 0x17, "AMD Ryzen Threadripper 1950", 1 },
>>>> { 0x17, "AMD Ryzen Threadripper 1920", 1 },
>>>> { 0x17, "AMD Ryzen Threadripper 1910", 1 },
>>>> +{ 0x17, "AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx", 2 },
>>>> +{ 0x17, "AMD Ryzen 7 2700U with Radeon Vega Mobile Gfx", 2 },
>>>
>>> Do you have a confirmation that the temperature offset is correct ?
>> I tried all of the three currently used offsets and this was looked the most
>> plausible.
>> For me having some indication of temperature is better than having none at
>> all.
>> Maybe some contact at AMD can shed some light on it, too?
>
> Per the information I got (not from AMD), those CPUs are not supposed to have
> an offset.
>
> Does the system have a Super-IO chip ? If so, what temperature does it report
> ?
> Also, what temperatures do you see with 0 offset ?
hm, interesting – as other Ryzens were marked with this offsets I did not
imagine the mobile ones would have none, …
Without offset it would mean the ideapad 720s would idle after fresh boot in a
(really) cold room at a little over 40°C.
The machine does not feel that warm, but maybe it is under the heatsink (my
boot w/ full-disk encryption takes a bit)?
Should I resend the patch without the offsets as baseline for other users to
test? Without the chipset PCI ID it obviously currently does not match on those
new mobile machines, ...
René
--
ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
http://exactcode.com | http://exactscan.com | http://ocrkit.com |
http://t2-project.org | http://rene.rebe.de
[PATCH] k10temp support for AMD Ryzen w/ Vega gfx
Hi,
This enables k10temp for the new AMD Ryzen APUs w/ Vega Mobile Gfx.
Tested on Ryzen 5 2500U, the temperature looked plausible.
Signed-off-by: René Rebe <r...@exactcode.de>
PS: 1st RFC - might get white-space damaged, will resend when ACKed.
Sorry my Xemacs/Mew broke.
--- linux-4.15/drivers/hwmon/k10temp.c.vanilla 2018-03-05 22:22:30.974331180
+
+++ linux-4.15/drivers/hwmon/k10temp.c 2018-03-05 22:24:17.186327291 +
@@ -40,6 +40,10 @@
#define PCI_DEVICE_ID_AMD_17H_DF_F30x1463
#endif
+#ifndef PCI_DEVICE_ID_AMD_17H_RR_NB
+#define PCI_DEVICE_ID_AMD_17H_RR_NB0x15d0
+#endif
+
/* CPUID function 0x8001, ebx */
#define CPUID_PKGTYPE_MASK 0xf000
#define CPUID_PKGTYPE_F0x
@@ -89,6 +93,8 @@
{ 0x17, "AMD Ryzen Threadripper 1950", 1 },
{ 0x17, "AMD Ryzen Threadripper 1920", 1 },
{ 0x17, "AMD Ryzen Threadripper 1910", 1 },
+ { 0x17, "AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx", 2 },
+ { 0x17, "AMD Ryzen 7 2700U with Radeon Vega Mobile Gfx", 2 },
};
static void read_tempreg_pci(struct pci_dev *pdev, u32 *regval)
@@ -289,6 +2944,7 @@
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) },
+ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_RR_NB) },
{}
};
MODULE_DEVICE_TABLE(pci, k10temp_id_table);
--
ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
http://exactcode.com | http://exactscan.com | http://ocrkit.com |
http://t2-project.org | http://rene.rebe.de
[PATCH] k10temp support for AMD Ryzen w/ Vega gfx
Hi,
This enables k10temp for the new AMD Ryzen APUs w/ Vega Mobile Gfx.
Tested on Ryzen 5 2500U, the temperature looked plausible.
Signed-off-by: René Rebe
PS: 1st RFC - might get white-space damaged, will resend when ACKed.
Sorry my Xemacs/Mew broke.
--- linux-4.15/drivers/hwmon/k10temp.c.vanilla 2018-03-05 22:22:30.974331180
+
+++ linux-4.15/drivers/hwmon/k10temp.c 2018-03-05 22:24:17.186327291 +
@@ -40,6 +40,10 @@
#define PCI_DEVICE_ID_AMD_17H_DF_F30x1463
#endif
+#ifndef PCI_DEVICE_ID_AMD_17H_RR_NB
+#define PCI_DEVICE_ID_AMD_17H_RR_NB0x15d0
+#endif
+
/* CPUID function 0x8001, ebx */
#define CPUID_PKGTYPE_MASK 0xf000
#define CPUID_PKGTYPE_F0x
@@ -89,6 +93,8 @@
{ 0x17, "AMD Ryzen Threadripper 1950", 1 },
{ 0x17, "AMD Ryzen Threadripper 1920", 1 },
{ 0x17, "AMD Ryzen Threadripper 1910", 1 },
+ { 0x17, "AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx", 2 },
+ { 0x17, "AMD Ryzen 7 2700U with Radeon Vega Mobile Gfx", 2 },
};
static void read_tempreg_pci(struct pci_dev *pdev, u32 *regval)
@@ -289,6 +2944,7 @@
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) },
+ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_RR_NB) },
{}
};
MODULE_DEVICE_TABLE(pci, k10temp_id_table);
--
ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
http://exactcode.com | http://exactscan.com | http://ocrkit.com |
http://t2-project.org | http://rene.rebe.de
Re: [PREVIEW] Add x86 zstd kernel compression
Hi, On 10/05/2017 09:22 PM, Nick Terrell wrote: On 10/5/17, 1:18 AM, "René Rebe" <r...@exactcode.com> wrote: Hi Nick, On Oct 5, 2017, at 1:29, Nick Terrell <terre...@fb.com> wrote: On 10/4/17, 3:01 AM, "linux-kernel-ow...@vger.kernel.org on behalf of René Rebe" <linux-kernel-ow...@vger.kernel.org on behalf of r...@exactcode.com> wrote: Hi, I noticed zstd compression was recently added for btrfs and squashfs. Are there actually already patches floating around for zstd kernel and intird compression? Looks like that would be a quite nice fit regarding speed and compression ratio, … Regards, René I started working on some patches yesterday, and just got zstd kernel, initrd, and initramfs compression working today. I think I'll be ready to send the patches out within a week. awesome, if you have something to test I could give it a try on my test bench, too. Here is a preview of the patch, though its not quite ready. I believe it works, but I still need to clean it up a bit, and split it into the decompression function, the initrd piece, and the x86 specific piece. I'll try to get the patch set out this week, and I'll CC you. thanks for the preview, which I applied cleanly, modulo this white-space chunk: diff --git a/lib/Kconfig b/lib/Kconfig index b1445b2..02fdcac 100644 @@ -296,7 +300,7 @@ config GENERIC_ALLOCATOR # config REED_SOLOMON tristate - + config REED_SOLOMON_ENC8 bool to the 4.14-rc2 tarball and it compiled and booted on x86-64, including a zstd initrd! Great work, will probably start testing it on my personal laptop, to use the same compression everywhere. Regards, René -- René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10117 Berlin http://exactcode.com | http://t2-project.org | http://rene.rebe.de
Re: [PREVIEW] Add x86 zstd kernel compression
Hi,
On 10/05/2017 09:22 PM, Nick Terrell wrote:
On 10/5/17, 1:18 AM, "René Rebe" wrote:
Hi Nick,
On Oct 5, 2017, at 1:29, Nick Terrell wrote:
On 10/4/17, 3:01 AM, "linux-kernel-ow...@vger.kernel.org on behalf of René Rebe"
wrote:
Hi,
I noticed zstd compression was recently added for btrfs and squashfs.
Are there actually already patches floating around for zstd kernel and intird
compression?
Looks like that would be a quite nice fit regarding speed and compression
ratio, …
Regards,
René
I started working on some patches yesterday, and just got zstd kernel,
initrd, and initramfs compression working today. I think I'll be ready to
send the patches out within a week.
awesome, if you have something to test I could give it a try on my test bench,
too.
Here is a preview of the patch, though its not quite ready.
I believe it works, but I still need to clean it up a bit, and split it
into the decompression function, the initrd piece, and the x86 specific
piece. I'll try to get the patch set out this week, and I'll CC you.
thanks for the preview, which I applied cleanly, modulo this white-space
chunk:
diff --git a/lib/Kconfig b/lib/Kconfig
index b1445b2..02fdcac 100644
@@ -296,7 +300,7 @@ config GENERIC_ALLOCATOR
#
config REED_SOLOMON
tristate
-
+
config REED_SOLOMON_ENC8
bool
to the 4.14-rc2 tarball and it compiled and booted on x86-64,
including a zstd initrd!
Great work, will probably start testing it on my personal
laptop, to use the same compression everywhere.
Regards,
René
--
René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10117 Berlin
http://exactcode.com | http://t2-project.org | http://rene.rebe.de
Re: zstd kernel and initrd compression
Hi Nick, On Oct 5, 2017, at 1:29, Nick Terrell <terre...@fb.com> wrote: > On 10/4/17, 3:01 AM, "linux-kernel-ow...@vger.kernel.org on behalf of René > Rebe" <linux-kernel-ow...@vger.kernel.org on behalf of r...@exactcode.com> > wrote: >> Hi, >> >> I noticed zstd compression was recently added for btrfs and squashfs. >> Are there actually already patches floating around for zstd kernel and >> intird compression? >> Looks like that would be a quite nice fit regarding speed and compression >> ratio, … >> >> Regards, >> René > > I started working on some patches yesterday, and just got zstd kernel, > initrd, and initramfs compression working today. I think I'll be ready to > send the patches out within a week. awesome, if you have something to test I could give it a try on my test bench, too. Regards, René -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
Re: zstd kernel and initrd compression
Hi Nick, On Oct 5, 2017, at 1:29, Nick Terrell wrote: > On 10/4/17, 3:01 AM, "linux-kernel-ow...@vger.kernel.org on behalf of René > Rebe" > wrote: >> Hi, >> >> I noticed zstd compression was recently added for btrfs and squashfs. >> Are there actually already patches floating around for zstd kernel and >> intird compression? >> Looks like that would be a quite nice fit regarding speed and compression >> ratio, … >> >> Regards, >> René > > I started working on some patches yesterday, and just got zstd kernel, > initrd, and initramfs compression working today. I think I'll be ready to > send the patches out within a week. awesome, if you have something to test I could give it a try on my test bench, too. Regards, René -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
zstd kernel and initrd compression
Hi, I noticed zstd compression was recently added for btrfs and squashfs. Are there actually already patches floating around for zstd kernel and intird compression? Looks like that would be a quite nice fit regarding speed and compression ratio, … Regards, René -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
zstd kernel and initrd compression
Hi, I noticed zstd compression was recently added for btrfs and squashfs. Are there actually already patches floating around for zstd kernel and intird compression? Looks like that would be a quite nice fit regarding speed and compression ratio, … Regards, René -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
[PATCH] applesmc case led and SCSI LED activity trigger
Hi all,
Nicolas: Do you still have your modified applesmc driver for OS X
and could trace which key OS X tweaks when the screensaver
switches the display off and lights the case LED to indicate the
machine is still alife? Would be best to use the same key but
with some quick pokes I did not found it last night.
Please find below a modification for the applesmc to allow controlling
the system's case LED, e.g. to indicate disk access as Linux allows
for the former PowerPC based books as well.
If anyone knows a better SMC key to control the light please let me
know (this key appears to rise the off level and was the only one I
found working last night).
Also, please let me know if the SCSI activity trigger is at the right place
as right now there only is the IDE trigger I could get inspiration from
(I reused the IDE trigger, maybe we could just rename it to disk?).
That said, it works for me on a MacBook Pro, but I could also test
on a normal MacBook as well as a Mac Pro later in the office.
The patch touched the existing backlight related variables and
function naming intetionally for consistency.
Signed-off-by: René Rebe <[EMAIL PROTECTED]>
--- ./drivers/hwmon/applesmc.c.orig 2008-01-26 21:04:43.0 +0100
+++ ./drivers/hwmon/applesmc.c 2008-01-26 21:22:36.0 +0100
@@ -63,6 +63,8 @@
#define CLAMSHELL_KEY "MSLD" /* r-o ui8 (unused) */
+#define LED_KEY"LSLF" /* r-w ui16 */
+
#define MOTION_SENSOR_X_KEY"MO_X" /* r-o sp78 (2 bytes) */
#define MOTION_SENSOR_Y_KEY"MO_Y" /* r-o sp78 (2 bytes) */
#define MOTION_SENSOR_Z_KEY"MO_Z" /* r-o sp78 (2 bytes) */
@@ -152,7 +154,7 @@
*/
static unsigned int key_at_index;
-static struct workqueue_struct *applesmc_led_wq;
+static struct workqueue_struct *applesmc_led_wq, *applesmc_backlight_wq;
/*
* __wait_status - Wait up to 2ms for the status port to get a certain value
@@ -760,18 +762,45 @@
}
static DECLARE_WORK(backlight_work, _backlight_set);
-static void applesmc_brightness_set(struct led_classdev *led_cdev,
- enum led_brightness value)
+static void applesmc_backlight_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
{
int ret;
backlight_value = value;
- ret = queue_work(applesmc_led_wq, _work);
+ ret = queue_work(applesmc_backlight_wq, _work);
if (debug && (!ret))
printk(KERN_DEBUG "applesmc: work was already on the queue.\n");
}
+/* Store the next LED value to be written by the work */
+static unsigned int led_value;
+
+static void applesmc_led_set(struct work_struct *work)
+{
+ u8 buffer[2];
+
+ mutex_lock(_lock);
+ buffer[0] = led_value;
+ buffer[1] = 0x00;
+ applesmc_write_key(LED_KEY, buffer, 2);
+ mutex_unlock(_lock);
+}
+static DECLARE_WORK(led_work, _led_set);
+
+static void applesmc_led_brightness_set(struct led_classdev *led_cdev,
+enum led_brightness value)
+{
+ int ret;
+
+ led_value = value;
+ ret = queue_work(applesmc_led_wq, _work);
+
+ if (debug && (!ret))
+ printk(KERN_DEBUG "applesmc: work was already on the queue.\n");
+}
+
static ssize_t applesmc_key_count_show(struct device *dev,
struct device_attribute *attr, char *sysfsbuf)
{
@@ -923,10 +952,16 @@
return count;
}
+static struct led_classdev applesmc_led = {
+ .name = "smc:case-led",
+ .default_trigger= "ide-disk",
+ .brightness_set = applesmc_led_brightness_set,
+};
+
static struct led_classdev applesmc_backlight = {
- .name = "smc:kbd_backlight",
- .default_trigger= "nand-disk",
- .brightness_set = applesmc_brightness_set,
+ .name = "smc:kbd_backlight",
+ .default_trigger= "nand-disk",
+ .brightness_set = applesmc_backlight_brightness_set,
};
static DEVICE_ATTR(name, 0444, applesmc_name_show, NULL);
@@ -1363,15 +1398,28 @@
goto out_temperature;
}
+/* Create the workqueue */
+applesmc_led_wq = create_singlethread_workqueue("applesmc-led");
+if (!applesmc_led_wq) {
+ret = -ENOMEM;
+goto out_accelerometer;
+}
+
+/* register as a led device */
+ret = led_classdev_register(>dev, _led);
+if (ret < 0)
+goto out_led_wq;
+
+
if (applesmc_light) {
/* Add light sensor file */
ret = sysfs_create_file(>dev.kobj, _attr_light.attr);
if (ret)
- goto out
[PATCH] applesmc case led and SCSI LED activity trigger
Hi all,
Nicolas: Do you still have your modified applesmc driver for OS X
and could trace which key OS X tweaks when the screensaver
switches the display off and lights the case LED to indicate the
machine is still alife? Would be best to use the same key but
with some quick pokes I did not found it last night.
Please find below a modification for the applesmc to allow controlling
the system's case LED, e.g. to indicate disk access as Linux allows
for the former PowerPC based books as well.
If anyone knows a better SMC key to control the light please let me
know (this key appears to rise the off level and was the only one I
found working last night).
Also, please let me know if the SCSI activity trigger is at the right place
as right now there only is the IDE trigger I could get inspiration from
(I reused the IDE trigger, maybe we could just rename it to disk?).
That said, it works for me on a MacBook Pro, but I could also test
on a normal MacBook as well as a Mac Pro later in the office.
The patch touched the existing backlight related variables and
function naming intetionally for consistency.
Signed-off-by: René Rebe [EMAIL PROTECTED]
--- ./drivers/hwmon/applesmc.c.orig 2008-01-26 21:04:43.0 +0100
+++ ./drivers/hwmon/applesmc.c 2008-01-26 21:22:36.0 +0100
@@ -63,6 +63,8 @@
#define CLAMSHELL_KEY MSLD /* r-o ui8 (unused) */
+#define LED_KEYLSLF /* r-w ui16 */
+
#define MOTION_SENSOR_X_KEYMO_X /* r-o sp78 (2 bytes) */
#define MOTION_SENSOR_Y_KEYMO_Y /* r-o sp78 (2 bytes) */
#define MOTION_SENSOR_Z_KEYMO_Z /* r-o sp78 (2 bytes) */
@@ -152,7 +154,7 @@
*/
static unsigned int key_at_index;
-static struct workqueue_struct *applesmc_led_wq;
+static struct workqueue_struct *applesmc_led_wq, *applesmc_backlight_wq;
/*
* __wait_status - Wait up to 2ms for the status port to get a certain value
@@ -760,18 +762,45 @@
}
static DECLARE_WORK(backlight_work, applesmc_backlight_set);
-static void applesmc_brightness_set(struct led_classdev *led_cdev,
- enum led_brightness value)
+static void applesmc_backlight_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness value)
{
int ret;
backlight_value = value;
- ret = queue_work(applesmc_led_wq, backlight_work);
+ ret = queue_work(applesmc_backlight_wq, backlight_work);
if (debug (!ret))
printk(KERN_DEBUG applesmc: work was already on the queue.\n);
}
+/* Store the next LED value to be written by the work */
+static unsigned int led_value;
+
+static void applesmc_led_set(struct work_struct *work)
+{
+ u8 buffer[2];
+
+ mutex_lock(applesmc_lock);
+ buffer[0] = led_value;
+ buffer[1] = 0x00;
+ applesmc_write_key(LED_KEY, buffer, 2);
+ mutex_unlock(applesmc_lock);
+}
+static DECLARE_WORK(led_work, applesmc_led_set);
+
+static void applesmc_led_brightness_set(struct led_classdev *led_cdev,
+enum led_brightness value)
+{
+ int ret;
+
+ led_value = value;
+ ret = queue_work(applesmc_led_wq, led_work);
+
+ if (debug (!ret))
+ printk(KERN_DEBUG applesmc: work was already on the queue.\n);
+}
+
static ssize_t applesmc_key_count_show(struct device *dev,
struct device_attribute *attr, char *sysfsbuf)
{
@@ -923,10 +952,16 @@
return count;
}
+static struct led_classdev applesmc_led = {
+ .name = smc:case-led,
+ .default_trigger= ide-disk,
+ .brightness_set = applesmc_led_brightness_set,
+};
+
static struct led_classdev applesmc_backlight = {
- .name = smc:kbd_backlight,
- .default_trigger= nand-disk,
- .brightness_set = applesmc_brightness_set,
+ .name = smc:kbd_backlight,
+ .default_trigger= nand-disk,
+ .brightness_set = applesmc_backlight_brightness_set,
};
static DEVICE_ATTR(name, 0444, applesmc_name_show, NULL);
@@ -1363,15 +1398,28 @@
goto out_temperature;
}
+/* Create the workqueue */
+applesmc_led_wq = create_singlethread_workqueue(applesmc-led);
+if (!applesmc_led_wq) {
+ret = -ENOMEM;
+goto out_accelerometer;
+}
+
+/* register as a led device */
+ret = led_classdev_register(pdev-dev, applesmc_led);
+if (ret 0)
+goto out_led_wq;
+
+
if (applesmc_light) {
/* Add light sensor file */
ret = sysfs_create_file(pdev-dev.kobj, dev_attr_light.attr);
if (ret)
- goto out_accelerometer;
+ goto out_led_ledclass;
/* Create the workqueue
Re: Linux 2.6.23
Hi Linus et al., 2.6.23 does not build with my usual .config on x86_64 and gcc-4.2.1: In file included from fs/drop_caches.c:8: include/linux/mm.h:1210: warning: 'struct super_block' declared inside parameter list nclude/linux/mm.h:1210: warning: its scope is only this definition or declaration, which is probably not what you want fs/drop_caches.c:17: error: conflicting types for 'drop_pagecache_sb' include/linux/mm.h:1210: error: previous declaration of 'drop_pagecache_sb' was here fs/drop_caches.c:28: error: conflicting types for 'drop_pagecache_sb' include/linux/mm.h:1210: error: previous declaration of 'drop_pagecache_sb' was here A little forward declaration fixes this: --- linux-2.6.23/include/linux/mm.h.vanilla 2007-10-10 09:28:33.0 +0200 +++ linux-2.6.23/include/linux/mm.h 2007-10-10 09:30:23.0 +0200 @@ -1207,6 +1207,7 @@ void __user *, size_t *, loff_t *); unsigned long shrink_slab(unsigned long scanned, gfp_t gfp_mask, unsigned long lru_pages); +struct super_block; extern void drop_pagecache_sb(struct super_block *); void drop_pagecache(void); void drop_slab(void); You probably end up fixing it some other way, but as I do not know this file inside out I just wanted to drop a note. Yours, René Rebe On Tuesday 09 October 2007 22:54:30 Linus Torvalds wrote: > Finally. > > Yeah, it got delayed, not because of any huge issues, but because of > various bugfixes trickling in and causing me to reset my "release clock" > all the time. But it's out there now, and hopefully better for the wait. > > Not a whole lot of changes since -rc9, although there's a few updates to > mips, sparc64 and blackfin in there. Ignoring those arch updates, there's > basically a number of mostly one-liners (mostly in drivers, but there's > some networking fixes and soem VFS/VM fixes there too). > > Shortlog and diffstat appended (both relative to -rc9, of course - the > full log from 2.6.22 is on kernel.org as usual). > > I want this to be what people look at for a few days, but expect the x86 > merge to go ahead after that. So far, all indications are still that it's > going to be all smooth sailing, but hey, those indicators seem to always > say that, and only after the fact do people notice any problems ;) > > Linus -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23
Hi Linus et al., 2.6.23 does not build with my usual .config on x86_64 and gcc-4.2.1: In file included from fs/drop_caches.c:8: include/linux/mm.h:1210: warning: 'struct super_block' declared inside parameter list nclude/linux/mm.h:1210: warning: its scope is only this definition or declaration, which is probably not what you want fs/drop_caches.c:17: error: conflicting types for 'drop_pagecache_sb' include/linux/mm.h:1210: error: previous declaration of 'drop_pagecache_sb' was here fs/drop_caches.c:28: error: conflicting types for 'drop_pagecache_sb' include/linux/mm.h:1210: error: previous declaration of 'drop_pagecache_sb' was here A little forward declaration fixes this: --- linux-2.6.23/include/linux/mm.h.vanilla 2007-10-10 09:28:33.0 +0200 +++ linux-2.6.23/include/linux/mm.h 2007-10-10 09:30:23.0 +0200 @@ -1207,6 +1207,7 @@ void __user *, size_t *, loff_t *); unsigned long shrink_slab(unsigned long scanned, gfp_t gfp_mask, unsigned long lru_pages); +struct super_block; extern void drop_pagecache_sb(struct super_block *); void drop_pagecache(void); void drop_slab(void); You probably end up fixing it some other way, but as I do not know this file inside out I just wanted to drop a note. Yours, René Rebe On Tuesday 09 October 2007 22:54:30 Linus Torvalds wrote: Finally. Yeah, it got delayed, not because of any huge issues, but because of various bugfixes trickling in and causing me to reset my release clock all the time. But it's out there now, and hopefully better for the wait. Not a whole lot of changes since -rc9, although there's a few updates to mips, sparc64 and blackfin in there. Ignoring those arch updates, there's basically a number of mostly one-liners (mostly in drivers, but there's some networking fixes and soem VFS/VM fixes there too). Shortlog and diffstat appended (both relative to -rc9, of course - the full log from 2.6.22 is on kernel.org as usual). I want this to be what people look at for a few days, but expect the x86 merge to go ahead after that. So far, all indications are still that it's going to be all smooth sailing, but hey, those indicators seem to always say that, and only after the fact do people notice any problems ;) Linus -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] applesmc for Mac Pro 2 x Quad-Core
Hi all,
at least the 2x Quad-Core Apple Mac Pro appears to have some over-heat
protection which suddenly powers off the whole box under load. This
adds support for the fans and temerature sensors in the Mac Pro - later
some "windwarm" a-like code should probably monitor the values. For now
manually tweaking the fans prevents the sudden shutdown for me.
cd /sys/devices/platform/applesmc.768
for x in fan{1,2,3,4}; do
echo 1 > ${x}_manual
echo 1285 > ${x}_output
done
Two sensors are 0, while four are 129 °C, those might be removed again,
later.
Signed-off-by: René Rebe <[EMAIL PROTECTED]>
--- linux-2.6.22/drivers/hwmon/applesmc.c 2007-08-29 18:38:56.0
+0200
+++ linux-2.6.22.5-dist-applesmc/drivers/hwmon/applesmc.c 2007-08-29
18:04:34.0 +0200
@@ -101,7 +101,7 @@
/*
* Temperature sensors keys (sp78 - 2 bytes).
*/
-static const char* temperature_sensors_sets[][13] = {
+static const char* temperature_sensors_sets[][36] = {
/* Set 0: Macbook Pro */
{ "TA0P", "TB0T", "TC0D", "TC0P", "TG0H", "TG0P", "TG0T", "Th0H",
"Th1H", "Tm0P", "Ts0P", "Ts1P", NULL },
@@ -109,7 +109,13 @@
{ "TB0T", "TC0D", "TC0P", "TM0P", "TN0P", "TN1P", "Th0H", "Th0S",
"Th1H", "Ts0P", NULL },
/* Set 2: Macmini set */
- { "TC0D", "TC0P", NULL }
+ { "TC0D", "TC0P", NULL },
+/* Set 3: Mac Pro (2 x Quad-Core) */
+ { "TA0P", "TCAG", "TCAH", "TCBG", "TCBH", "TC0C", "TC0D", "TC0P",
+ "TC1C", "TC1D", "TC2C", "TC2D", "TC3C", "TC3D", "THTG", "TH0P",
+ "TH1P", "TH2P", "TH3P", "TMAP", "TMAS", "TMBS", "TM0P", "TM0S",
+ "TM1P", "TM1S", "TM2P", "TM2S", "TM3S", "TM8P", "TM8S", "TM9P",
+ "TM9S", "TN0H", "TS0C", NULL },
};
/* List of keys used to read/write fan speeds */
@@ -1265,14 +1271,18 @@
/*
* Create the needed functions for each fan using the macro defined above
- * (2 fans are supported)
+ * (4 fans are supported)
*/
sysfs_fan_speeds_offset(1);
sysfs_fan_speeds_offset(2);
+sysfs_fan_speeds_offset(3);
+sysfs_fan_speeds_offset(4);
static const struct attribute_group fan_attribute_groups[] = {
{ .attrs = fan1_attributes },
- { .attrs = fan2_attributes }
+ { .attrs = fan2_attributes },
+ { .attrs = fan3_attributes },
+ { .attrs = fan4_attributes }
};
/*
@@ -1302,6 +1312,52 @@
applesmc_show_temperature, NULL, 10);
static SENSOR_DEVICE_ATTR(temp12_input, S_IRUGO,
applesmc_show_temperature, NULL, 11);
+static SENSOR_DEVICE_ATTR(temp13_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 12);
+static SENSOR_DEVICE_ATTR(temp14_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 13);
+static SENSOR_DEVICE_ATTR(temp15_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 14);
+static SENSOR_DEVICE_ATTR(temp16_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 15);
+static SENSOR_DEVICE_ATTR(temp17_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 16);
+static SENSOR_DEVICE_ATTR(temp18_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 17);
+static SENSOR_DEVICE_ATTR(temp19_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 18);
+static SENSOR_DEVICE_ATTR(temp20_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 19);
+static SENSOR_DEVICE_ATTR(temp21_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 20);
+static SENSOR_DEVICE_ATTR(temp22_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 21);
+static SENSOR_DEVICE_ATTR(temp23_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 22);
+static SENSOR_DEVICE_ATTR(temp24_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 23);
+static SENSOR_DEVICE_ATTR(temp25_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 24);
+static SENSOR_DEVICE_ATTR(temp26_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 25);
+stat
[PATCH] applesmc for Mac Pro 2 x Quad-Core
Hi all,
at least the 2x Quad-Core Apple Mac Pro appears to have some over-heat
protection which suddenly powers off the whole box under load. This
adds support for the fans and temerature sensors in the Mac Pro - later
some windwarm a-like code should probably monitor the values. For now
manually tweaking the fans prevents the sudden shutdown for me.
cd /sys/devices/platform/applesmc.768
for x in fan{1,2,3,4}; do
echo 1 ${x}_manual
echo 1285 ${x}_output
done
Two sensors are 0, while four are 129 °C, those might be removed again,
later.
Signed-off-by: René Rebe [EMAIL PROTECTED]
--- linux-2.6.22/drivers/hwmon/applesmc.c 2007-08-29 18:38:56.0
+0200
+++ linux-2.6.22.5-dist-applesmc/drivers/hwmon/applesmc.c 2007-08-29
18:04:34.0 +0200
@@ -101,7 +101,7 @@
/*
* Temperature sensors keys (sp78 - 2 bytes).
*/
-static const char* temperature_sensors_sets[][13] = {
+static const char* temperature_sensors_sets[][36] = {
/* Set 0: Macbook Pro */
{ TA0P, TB0T, TC0D, TC0P, TG0H, TG0P, TG0T, Th0H,
Th1H, Tm0P, Ts0P, Ts1P, NULL },
@@ -109,7 +109,13 @@
{ TB0T, TC0D, TC0P, TM0P, TN0P, TN1P, Th0H, Th0S,
Th1H, Ts0P, NULL },
/* Set 2: Macmini set */
- { TC0D, TC0P, NULL }
+ { TC0D, TC0P, NULL },
+/* Set 3: Mac Pro (2 x Quad-Core) */
+ { TA0P, TCAG, TCAH, TCBG, TCBH, TC0C, TC0D, TC0P,
+ TC1C, TC1D, TC2C, TC2D, TC3C, TC3D, THTG, TH0P,
+ TH1P, TH2P, TH3P, TMAP, TMAS, TMBS, TM0P, TM0S,
+ TM1P, TM1S, TM2P, TM2S, TM3S, TM8P, TM8S, TM9P,
+ TM9S, TN0H, TS0C, NULL },
};
/* List of keys used to read/write fan speeds */
@@ -1265,14 +1271,18 @@
/*
* Create the needed functions for each fan using the macro defined above
- * (2 fans are supported)
+ * (4 fans are supported)
*/
sysfs_fan_speeds_offset(1);
sysfs_fan_speeds_offset(2);
+sysfs_fan_speeds_offset(3);
+sysfs_fan_speeds_offset(4);
static const struct attribute_group fan_attribute_groups[] = {
{ .attrs = fan1_attributes },
- { .attrs = fan2_attributes }
+ { .attrs = fan2_attributes },
+ { .attrs = fan3_attributes },
+ { .attrs = fan4_attributes }
};
/*
@@ -1302,6 +1312,52 @@
applesmc_show_temperature, NULL, 10);
static SENSOR_DEVICE_ATTR(temp12_input, S_IRUGO,
applesmc_show_temperature, NULL, 11);
+static SENSOR_DEVICE_ATTR(temp13_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 12);
+static SENSOR_DEVICE_ATTR(temp14_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 13);
+static SENSOR_DEVICE_ATTR(temp15_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 14);
+static SENSOR_DEVICE_ATTR(temp16_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 15);
+static SENSOR_DEVICE_ATTR(temp17_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 16);
+static SENSOR_DEVICE_ATTR(temp18_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 17);
+static SENSOR_DEVICE_ATTR(temp19_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 18);
+static SENSOR_DEVICE_ATTR(temp20_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 19);
+static SENSOR_DEVICE_ATTR(temp21_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 20);
+static SENSOR_DEVICE_ATTR(temp22_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 21);
+static SENSOR_DEVICE_ATTR(temp23_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 22);
+static SENSOR_DEVICE_ATTR(temp24_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 23);
+static SENSOR_DEVICE_ATTR(temp25_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 24);
+static SENSOR_DEVICE_ATTR(temp26_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 25);
+static SENSOR_DEVICE_ATTR(temp27_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 26);
+static SENSOR_DEVICE_ATTR(temp28_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 27);
+static SENSOR_DEVICE_ATTR(temp29_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 28);
+static SENSOR_DEVICE_ATTR(temp30_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 29);
+static SENSOR_DEVICE_ATTR(temp31_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 30);
+static SENSOR_DEVICE_ATTR(temp32_input, S_IRUGO,
+ applesmc_show_temperature, NULL, 31
Re: InitIO SCSI: Volunteers required
On Friday 20 April 2007 11:38:49 Alan Cox wrote: > I'm looking for some testers for a revamp of the initio driver. No real > code changes other than to hopefully stop it exploding on load on 64bit, > but a major reorganisation, commenting and "de-windowsification" so the > code is actually readable and I can do the pci_find_device to > pci_get_device transitions. I once had such a card flying around, feel free to attach it to me and I can see if I find the card in some box over the weekend :-) Yours, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin Geschäftsführer: Susanne Klaus, René Rebe Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B USt-IdNr.: DE251602478 http://exactcode.de | http://t2-project.org | http://rene.rebe.name - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: InitIO SCSI: Volunteers required
On Friday 20 April 2007 11:38:49 Alan Cox wrote: I'm looking for some testers for a revamp of the initio driver. No real code changes other than to hopefully stop it exploding on load on 64bit, but a major reorganisation, commenting and de-windowsification so the code is actually readable and I can do the pci_find_device to pci_get_device transitions. I once had such a card flying around, feel free to attach it to me and I can see if I find the card in some box over the weekend :-) Yours, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin Geschäftsführer: Susanne Klaus, René Rebe Sitz: Berlin, Amtsgericht Charlottenburg HRB 105 123 B USt-IdNr.: DE251602478 http://exactcode.de | http://t2-project.org | http://rene.rebe.name - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] wrong ide disk sector size (2.6.12.1)
reed ICH5: IDE controller at PCI slot :00:1f.1 ACPI: PCI Interrupt :00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18 ICH5: chipset revision 2 ICH5: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide0... input: ImPS/2 Generic Wheel Mouse on isa0060/serio1 hda: TOSHIBA MK8026GAX, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: QSI CD-ROM SCR-242, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 ieee1394: Initialized config rom entry `ip1394' ohci1394: $Rev: 1250 $ Ben Collins <[EMAIL PROTECTED]> ACPI: PCI Interrupt :01:03.0[A] -> GSI 16 (level, low) -> IRQ 16 ohci1394: fw-host0: Unexpected PCI resource length of 1000! ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[16] MMIO=[f840-f84007ff] Max Packet=[2048] ACPI: PCI Interrupt :01:06.0[A] -> GSI 18 (level, low) -> IRQ 18 ahc_pci:1:6:0: Host Adapter Bios disabled. Using default SCSI device parameters scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs ieee1394: Host added: ID:BUS[0-00:1023] GUID[000a9d050aed] sbp2: $Rev: 1219 $ Ben Collins <[EMAIL PROTECTED]> hda: max request size: 128KiB hda: 16514064 sectors (8455 MB), CHS=16383/16/63, UDMA(33) hda: cache flushes supported hda: hda1 hda2 hda3 hda4 hdc: ATAPI 24X CD-ROM drive, 128kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 JFS: nTxBlock = 1936, nTxLock = 15493 NTFS driver 2.1.22 [Flags: R/O MODULE]. SGI XFS with large block numbers, no debug enabled Registering unionfs 1.0.13 EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on hda1, internal journal kjournald starting. Commit interval 5 seconds EXT3 FS on hda4, internal journal EXT3-fs: mounted filesystem with ordered data mode. Adding 1048816k swap on /dev/hda3. Priority:-1 extents:1 intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G chipsets intelfb: Version 0.9.2 ACPI: PCI Interrupt :00:02.0[A] -> GSI 16 (level, low) -> IRQ 16 intelfb: 00:02.0: Intel(R) 865G, aperture size 128MB, stolen memory 8060kB intelfb: Mode is interlaced. intelfb: Initial video mode is [EMAIL PROTECTED] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 hw_random: RNG not detected ACPI: PCI Interrupt :00:1f.5[B] -> GSI 17 (level, low) -> IRQ 17 PCI: Setting latency timer of device :00:1f.5 to 64 intel8x0_measure_ac97_clock: measured 49623 usecs intel8x0: clocking to 48000 e100: Intel(R) PRO/100 Network Driver, 3.4.8-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation ACPI: PCI Interrupt :01:08.0[A] -> GSI 20 (level, low) -> IRQ 20 e100: eth0: e100_probe: addr 0xf8402000, irq 20, MAC addr 00:0A:9D:08:08:8C IA-32 Microcode Update Driver: v1.14 <[EMAIL PROTECTED]> microcode: CPU0 updated from revision 0x21 to 0x2e, date = 08112004 NET: Registered protocol family 10 IPv6 over IPv4 tunneling driver [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt :00:02.0[A] -> GSI 16 (level, low) -> IRQ 16 [drm] Initialized i915 1.1.0 20040405 on minor 0: mtrr: base(0xf002) is not aligned on a size(0x18) boundary e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex eth0: no IPv6 routers present Of course this leads to _major_ data corruption on the filesystems. Any idea? -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.t2-project.org +49 (0)30 255 897 45 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] wrong ide disk sector size (2.6.12.1)
, low) - IRQ 18 ICH5: chipset revision 2 ICH5: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide0... input: ImPS/2 Generic Wheel Mouse on isa0060/serio1 hda: TOSHIBA MK8026GAX, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: QSI CD-ROM SCR-242, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 ieee1394: Initialized config rom entry `ip1394' ohci1394: $Rev: 1250 $ Ben Collins [EMAIL PROTECTED] ACPI: PCI Interrupt :01:03.0[A] - GSI 16 (level, low) - IRQ 16 ohci1394: fw-host0: Unexpected PCI resource length of 1000! ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[16] MMIO=[f840-f84007ff] Max Packet=[2048] ACPI: PCI Interrupt :01:06.0[A] - GSI 18 (level, low) - IRQ 18 ahc_pci:1:6:0: Host Adapter Bios disabled. Using default SCSI device parameters scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 Adaptec 2902/04/10/15/20C/30C SCSI adapter aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs ieee1394: Host added: ID:BUS[0-00:1023] GUID[000a9d050aed] sbp2: $Rev: 1219 $ Ben Collins [EMAIL PROTECTED] hda: max request size: 128KiB hda: 16514064 sectors (8455 MB), CHS=16383/16/63, UDMA(33) hda: cache flushes supported hda: hda1 hda2 hda3 hda4 hdc: ATAPI 24X CD-ROM drive, 128kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 JFS: nTxBlock = 1936, nTxLock = 15493 NTFS driver 2.1.22 [Flags: R/O MODULE]. SGI XFS with large block numbers, no debug enabled Registering unionfs 1.0.13 EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on hda1, internal journal kjournald starting. Commit interval 5 seconds EXT3 FS on hda4, internal journal EXT3-fs: mounted filesystem with ordered data mode. Adding 1048816k swap on /dev/hda3. Priority:-1 extents:1 intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G chipsets intelfb: Version 0.9.2 ACPI: PCI Interrupt :00:02.0[A] - GSI 16 (level, low) - IRQ 16 intelfb: 00:02.0: Intel(R) 865G, aperture size 128MB, stolen memory 8060kB intelfb: Mode is interlaced. intelfb: Initial video mode is [EMAIL PROTECTED] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 shpchp: shpc_init : shpc_cap_offset == 0 shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 hw_random: RNG not detected ACPI: PCI Interrupt :00:1f.5[B] - GSI 17 (level, low) - IRQ 17 PCI: Setting latency timer of device :00:1f.5 to 64 intel8x0_measure_ac97_clock: measured 49623 usecs intel8x0: clocking to 48000 e100: Intel(R) PRO/100 Network Driver, 3.4.8-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation ACPI: PCI Interrupt :01:08.0[A] - GSI 20 (level, low) - IRQ 20 e100: eth0: e100_probe: addr 0xf8402000, irq 20, MAC addr 00:0A:9D:08:08:8C IA-32 Microcode Update Driver: v1.14 [EMAIL PROTECTED] microcode: CPU0 updated from revision 0x21 to 0x2e, date = 08112004 NET: Registered protocol family 10 IPv6 over IPv4 tunneling driver [drm] Initialized drm 1.0.0 20040925 ACPI: PCI Interrupt :00:02.0[A] - GSI 16 (level, low) - IRQ 16 [drm] Initialized i915 1.1.0 20040405 on minor 0: mtrr: base(0xf002) is not aligned on a size(0x18) boundary e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex eth0: no IPv6 routers present Of course this leads to _major_ data corruption on the filesystems. Any idea? -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.t2-project.org +49 (0)30 255 897 45 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swap is never used on ultrasparc64/32 - 2.6.11-rc2 (STILL NOT SOLVED)
Hi, On 25. Jan 2005, at 18:40 Uhr, Grzegorz Piotr Jaskiewicz wrote: [...] I can confirm this. What is your last kernel that worked? I have no data at hand - but I'm sure in either 2.6.8 or 2.6.10 swapping did work. Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.exactcode.de/t2 +49 (0)30 255 897 45 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swap is never used on ultrasparc64/32 - 2.6.11-rc2 (STILL NOT SOLVED)
Hi, On 25. Jan 2005, at 18:40 Uhr, Grzegorz Piotr Jaskiewicz wrote: [...] I can confirm this. What is your last kernel that worked? I have no data at hand - but I'm sure in either 2.6.8 or 2.6.10 swapping did work. Yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.exactcode.de/t2 +49 (0)30 255 897 45 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sis630 - help needed debugging in the kernel
;= Code; c01b8f63 2: 8a 03 mov(%ebx),%al Code; c01b8f65 4: 24 0f and$0xf,%al Code; c01b8f67 6: 0f b6 d0 movzbl %al,%edx Code; c01b8f6a 9: 8b 44 24 18 mov0x18(%esp,1),%eax Code; c01b8f6e d: 23 04 97 and(%edi,%edx,4),%eax Code; c01b8f71 10: 31 e8 xor%ebp,%eax Code; c01b8f73 12: 89 46 00 mov%eax,0x0(%esi) <0>Kernel panic: Attempted to kill init! Another prolem (which may be related) is that XFree's sis-drivers is also not working (but only because the sis301's LCD port is not enabled correct ... - Without a special hack of me and the VESA framebuffer I get simply a black screen (NO crash ...). Only the latest revisions of the SIS chip are affected by this problems. Older ones seem to work (at least in X). (I only have this new chip ...). > Regards, > > -- > Paul Mundt <[EMAIL PROTECTED]> > k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sis630 - help needed debugging in the kernel
On Sun, 17 Jun 2001 07:03:55 -0700 (PDT) James Simmons <[EMAIL PROTECTED]> wrote: [...] > Yes. It oops in fbcon_cfb8_putc. I haven't figured out yet what exactly > caused it. I don't have this card to play with :-( Did you run the other > test I suggested. Never arrived here :-(. (Pleas cc me, since I'm not on this lists ...) > Try booting at 640x480 with a color depth of 32. Then > try booting at a different resolution (1024x768) at the default color > depth. I want to see if its a error with the resolution setting or if it > is a error with setting up the data relating to the color depth handling. > The results should give me some clue. I can't set the videomode for the driver ...? I tried: video=sis:vesa:0x112 video=sis:xres:640,yres:480,depth:32 video=sis,xres:640,yres:480,depth:32 Is there another way to tell the fb driver what mode to use?? I set the shared memory size from 16MB to 64 MB: results: sisfb: framebuffer at 0xe000, mapped to 0xc880, size 65536k sisfb: MMIO at 0xefce, mapped to 0xcc801000, size 128k Unable to handle kernel paging request at virtual address cc8002e0 old results: sisfb: framebuffer at 0xe000, mapped to 0xcb80, size 16384k sisfb: MMIO at 0xefce, mapped to 0xcc801000, size 128k Unable to handle kernel paging request at virtual address cc800180 (Maybe some typo somewhere ??) PS: I have more free time the next days -> shorter latency and more kernel source read time ... k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sis630 - help needed debugging in the kernel
On Sun, 17 Jun 2001 07:03:55 -0700 (PDT) James Simmons [EMAIL PROTECTED] wrote: [...] Yes. It oops in fbcon_cfb8_putc. I haven't figured out yet what exactly caused it. I don't have this card to play with :-( Did you run the other test I suggested. Never arrived here :-(. (Pleas cc me, since I'm not on this lists ...) Try booting at 640x480 with a color depth of 32. Then try booting at a different resolution (1024x768) at the default color depth. I want to see if its a error with the resolution setting or if it is a error with setting up the data relating to the color depth handling. The results should give me some clue. I can't set the videomode for the driver ...? I tried: video=sis:vesa:0x112 video=sis:xres:640,yres:480,depth:32 video=sis,xres:640,yres:480,depth:32 Is there another way to tell the fb driver what mode to use?? I set the shared memory size from 16MB to 64 MB: results: sisfb: framebuffer at 0xe000, mapped to 0xc880, size 65536k sisfb: MMIO at 0xefce, mapped to 0xcc801000, size 128k Unable to handle kernel paging request at virtual address cc8002e0 old results: sisfb: framebuffer at 0xe000, mapped to 0xcb80, size 16384k sisfb: MMIO at 0xefce, mapped to 0xcc801000, size 128k Unable to handle kernel paging request at virtual address cc800180 (Maybe some typo somewhere ??) PS: I have more free time the next days - shorter latency and more kernel source read time ... k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sis630 - help needed debugging in the kernel
fbcon_switch+1aa/1bc Trace; c0181f04 redraw_screen+e0/160 Trace; c01856f9 take_over_console+ed/188 Trace; c01aaeb9 register_framebuffer+f9/140 Trace; c0105013 init+7/114 Trace; c010542c kernel_thread+28/38 Code; c01b8f61 fbcon_cfb8_putcs+1ad/2c8 _EIP: Code; c01b8f61 fbcon_cfb8_putcs+1ad/2c8 = 0: 89 06 mov%eax,(%esi) = Code; c01b8f63 fbcon_cfb8_putcs+1af/2c8 2: 8a 03 mov(%ebx),%al Code; c01b8f65 fbcon_cfb8_putcs+1b1/2c8 4: 24 0f and$0xf,%al Code; c01b8f67 fbcon_cfb8_putcs+1b3/2c8 6: 0f b6 d0 movzbl %al,%edx Code; c01b8f6a fbcon_cfb8_putcs+1b6/2c8 9: 8b 44 24 18 mov0x18(%esp,1),%eax Code; c01b8f6e fbcon_cfb8_putcs+1ba/2c8 d: 23 04 97 and(%edi,%edx,4),%eax Code; c01b8f71 fbcon_cfb8_putcs+1bd/2c8 10: 31 e8 xor%ebp,%eax Code; c01b8f73 fbcon_cfb8_putcs+1bf/2c8 12: 89 46 00 mov%eax,0x0(%esi) 0Kernel panic: Attempted to kill init! Another prolem (which may be related) is that XFree's sis-drivers is also not working (but only because the sis301's LCD port is not enabled correct ... - Without a special hack of me and the VESA framebuffer I get simply a black screen (NO crash ...). Only the latest revisions of the SIS chip are affected by this problems. Older ones seem to work (at least in X). (I only have this new chip ...). Regards, -- Paul Mundt [EMAIL PROTECTED] k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sis630 - help needed debugging in the kernel
Hi all! On Wed, 13 Jun 2001 23:25:02 +0200 René Rebe <[EMAIL PROTECTED]> wrote: > Thanks for the quick reply! > > On Wed, 13 Jun 2001 09:54:21 -0700 (PDT) > James Simmons <[EMAIL PROTECTED]> wrote: > > > > > > I currently try to debug why the sisfb driver crashes my machine. (SIS 630 > > > based laptop - linux-2.4.5-ac13). > > > > You can do one of two things. Post both System.map and the complete oops > > or you can run ksymoops on the oops. I can find the problem then. Thanks. > > ksymoops' output is attached. Is there any result with this trace?? [...] k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sis630 - help needed debugging in the kernel
Hi all! On Wed, 13 Jun 2001 23:25:02 +0200 René Rebe [EMAIL PROTECTED] wrote: Thanks for the quick reply! On Wed, 13 Jun 2001 09:54:21 -0700 (PDT) James Simmons [EMAIL PROTECTED] wrote: I currently try to debug why the sisfb driver crashes my machine. (SIS 630 based laptop - linux-2.4.5-ac13). You can do one of two things. Post both System.map and the complete oops or you can run ksymoops on the oops. I can find the problem then. Thanks. ksymoops' output is attached. Is there any result with this trace?? [...] k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sis630 - help needed debugging in the kernel
Thanks for the quick reply! On Wed, 13 Jun 2001 09:54:21 -0700 (PDT) James Simmons <[EMAIL PROTECTED]> wrote: > > > I currently try to debug why the sisfb driver crashes my machine. (SIS 630 > > based laptop - linux-2.4.5-ac13). > > You can do one of two things. Post both System.map and the complete oops > or you can run ksymoops on the oops. I can find the problem then. Thanks. ksymoops' output is attached. [...] k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. ksymoops.txt
sis630 - help needed debugging in the kernel
Hi all! I currently try to debug why the sisfb driver crashes my machine. (SIS 630 based laptop - linux-2.4.5-ac13). On my serial-console I get: [...] sisfb: framebuffer at 0xe000, mapped to 0xcb80, size 16384k sisfb: MMIO at 0xefce, mapped to 0xcc801000, size 128k sisfb: encountered LCD # debug output by me sisfb: fall back to 1024x768 # debug ouput by me sisfb: LCD mode # debug output by me sisfb: mode is 800x600x8, linelength=800 [...] Unable to handle kernel paging request at virtual address cc800180 [oops] This happens in the method: register_framebuffer called from sisfb_init. I compared the sisfb_init with other framebuffer drivers and can't find what is wrong. (I normally don't do kernel hacking...). What does the kernel try to do with the _io-memory_, mapped around line 2230 in sis_main.c? - Must the memory reqeuested or mapped in an other way? Another strange thing is, that the code seems to work for some people ... I would be nice if anyone could give me a hint - because the sis-drivers (kernel and X) doesn't work for many people ... k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sis630 - help needed debugging in the kernel
Hi all! I currently try to debug why the sisfb driver crashes my machine. (SIS 630 based laptop - linux-2.4.5-ac13). On my serial-console I get: [...] sisfb: framebuffer at 0xe000, mapped to 0xcb80, size 16384k sisfb: MMIO at 0xefce, mapped to 0xcc801000, size 128k sisfb: encountered LCD # debug output by me sisfb: fall back to 1024x768 # debug ouput by me sisfb: LCD mode # debug output by me sisfb: mode is 800x600x8, linelength=800 [...] Unable to handle kernel paging request at virtual address cc800180 [oops] This happens in the method: register_framebuffer called from sisfb_init. I compared the sisfb_init with other framebuffer drivers and can't find what is wrong. (I normally don't do kernel hacking...). What does the kernel try to do with the _io-memory_, mapped around line 2230 in sis_main.c? - Must the memory reqeuested or mapped in an other way? Another strange thing is, that the code seems to work for some people ... I would be nice if anyone could give me a hint - because the sis-drivers (kernel and X) doesn't work for many people ... k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sis630 - help needed debugging in the kernel
Thanks for the quick reply! On Wed, 13 Jun 2001 09:54:21 -0700 (PDT) James Simmons [EMAIL PROTECTED] wrote: I currently try to debug why the sisfb driver crashes my machine. (SIS 630 based laptop - linux-2.4.5-ac13). You can do one of two things. Post both System.map and the complete oops or you can run ksymoops on the oops. I can find the problem then. Thanks. ksymoops' output is attached. [...] k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. ksymoops.txt
