> When using the sata_mv driver, I can't see my drives.
>
> The drives are SATA6Gbps.
>
> The SATA card is a Supermicro AOC-SAT2-MV8 SATA3Gbps card with a
Marvell
> 88SX6081 chip onboard.
Never mind, old kernel. Fixed in 3.7.6. Sorry for the noise.
--
To unsubscribe from this list: send the
When using the sata_mv driver, I can't see my drives.
The drives are SATA6Gbps.
The SATA card is a Supermicro AOC-SAT2-MV8 SATA3Gbps card with a
Marvell
88SX6081 chip onboard.
Never mind, old kernel. Fixed in 3.7.6. Sorry for the noise.
--
To unsubscribe from this list: send the line
Does anyone know if the Tyan Thunder K8W (s2885) has a BMC controller
for IPMI management on board? If it does, what do I have to enable in
the kernel to use it?
Cheers,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Does anyone know if the Tyan Thunder K8W (s2885) has a BMC controller
for IPMI management on board? If it does, what do I have to enable in
the kernel to use it?
Cheers,
James
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Sun, 2007-09-09 at 15:46 +0200, Andi Kleen wrote:
> Thanks. How about a fix for the other problem (ACPI_NUMA- PM) too?
>
I don't want to just hard-select it until I understand what happened
between 2.6.22.6 and current git to make ACPI selectable without PM.
Personally, I think ACPI should
On Sat, 2007-08-09 at 22:00 -0700, Randy Dunlap wrote:
> > For example, you would only need to specify one "select" directive in
> > X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system
> > would then recursively walk up ACPI_NUMA's dependency hierarchy, turning
> > on what it
On Sun, 2007-09-09 at 11:07 +0200, Andi Kleen wrote:
> "James C. Georgas" <[EMAIL PROTECTED]> writes:
> >
> > It's 2.6.22.6. I'm thinking a fix would be to add "select PM" to
> > X86_64_ACPI_NUMA.
> >
> > I'm also thinking that maybe K8_
On Sun, 2007-09-09 at 11:07 +0200, Andi Kleen wrote:
James C. Georgas [EMAIL PROTECTED] writes:
It's 2.6.22.6. I'm thinking a fix would be to add select PM to
X86_64_ACPI_NUMA.
I'm also thinking that maybe K8_NUMA should be changed from depends on
PCI to select PCI, like
On Sat, 2007-08-09 at 22:00 -0700, Randy Dunlap wrote:
For example, you would only need to specify one select directive in
X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system
would then recursively walk up ACPI_NUMA's dependency hierarchy, turning
on what it needed.
On Sun, 2007-09-09 at 15:46 +0200, Andi Kleen wrote:
Thanks. How about a fix for the other problem (ACPI_NUMA- PM) too?
I don't want to just hard-select it until I understand what happened
between 2.6.22.6 and current git to make ACPI selectable without PM.
Personally, I think ACPI should be
On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote:
> 2.6.23-rc5-git1 builds for me when I follow those steps...
> except for some Section mismatch warnings.
>
OK, it worked for me also, using torvalds/linux-2.6.git. The behaviour
of the "select" directive in Kconfig appears to have changed
On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote:
> On Sat, 8 Sep 2007 18:09:04 -0700 Randy Dunlap wrote:
>
> > On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote:
> >
> > > If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly)
selected
&g
On Sat, 2007-08-09 at 18:09 -0700, Randy Dunlap wrote:
> On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote:
>
> > If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
> > automatically, but ACPI is not selected automatically. This causes
> > A
On Sat, 2007-08-09 at 18:51 -0400, James C. Georgas wrote:
> If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
> automatically, but ACPI is not selected automatically. This causes
> ACPI_NUMA to not be built, and the kernel compile fails with unresolved
> sym
On Sat, 2007-08-09 at 18:51 -0400, James C. Georgas wrote:
> Steps to reproduce:
>
> make clean
> make mrproper
> make noallconfig
Excuse me; that should read allnoconfig, not noallconfig.
James
/\V
-
To unsubscribe from this list: send the line &qu
If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
automatically, but ACPI is not selected automatically. This causes
ACPI_NUMA to not be built, and the kernel compile fails with unresolved
symbols.
Steps to reproduce:
make clean
make mrproper
make
If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
automatically, but ACPI is not selected automatically. This causes
ACPI_NUMA to not be built, and the kernel compile fails with unresolved
symbols.
Steps to reproduce:
make clean
make mrproper
make
On Sat, 2007-08-09 at 18:51 -0400, James C. Georgas wrote:
Steps to reproduce:
make clean
make mrproper
make noallconfig
Excuse me; that should read allnoconfig, not noallconfig.
James
/\V
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Sat, 2007-08-09 at 18:51 -0400, James C. Georgas wrote:
If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
automatically, but ACPI is not selected automatically. This causes
ACPI_NUMA to not be built, and the kernel compile fails with unresolved
symbols.
Uh, it seems
On Sat, 2007-08-09 at 18:09 -0700, Randy Dunlap wrote:
On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote:
If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected
automatically, but ACPI is not selected automatically. This causes
ACPI_NUMA to not be built
On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote:
On Sat, 8 Sep 2007 18:09:04 -0700 Randy Dunlap wrote:
On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote:
If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly)
selected
automatically, but ACPI is not selected
On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote:
2.6.23-rc5-git1 builds for me when I follow those steps...
except for some Section mismatch warnings.
OK, it worked for me also, using torvalds/linux-2.6.git. The behaviour
of the select directive in Kconfig appears to have changed since
I'm not sure I understand how the kernel calculates the amount of
physical RAM it can map during the boot process.
I've quoted two blocks of kernel messages below, one for a kernel with
NOHIGHMEM and another for a kernel with HIGHMEM4G.
If I do the math on the BIOS provided physical RAM map,
I'm not sure I understand how the kernel calculates the amount of
physical RAM it can map during the boot process.
I've quoted two blocks of kernel messages below, one for a kernel with
NOHIGHMEM and another for a kernel with HIGHMEM4G.
If I do the math on the BIOS provided physical RAM map,
On Tue, 2006-26-12 at 03:20 -0800, Martin Knoblauch wrote:
> On 12/25/06, David Schwartz <[EMAIL PROTECTED]> wrote:
>
> > If I bought the car from the manufacturer, it also must
> > include any rights the manufacturer might have to the car's use.
> > That includes using the car to violate
On Tue, 2006-26-12 at 03:20 -0800, Martin Knoblauch wrote:
On 12/25/06, David Schwartz [EMAIL PROTECTED] wrote:
If I bought the car from the manufacturer, it also must
include any rights the manufacturer might have to the car's use.
That includes using the car to violate emission
On Sun, 2006-24-12 at 09:33 -0800, David Schwartz wrote:
> > On Fri, 22 Dec 2006 23:19:09 PST, David Schwartz said:
>
> > > You can't sell something that doesn't exist. If you sell a car
> > > even though
> > > you can't explain how anyone could drive it, that's fraud.
>
> > Are they allowed to
On Sun, 2006-24-12 at 09:33 -0800, David Schwartz wrote:
On Fri, 22 Dec 2006 23:19:09 PST, David Schwartz said:
You can't sell something that doesn't exist. If you sell a car
even though
you can't explain how anyone could drive it, that's fraud.
Are they allowed to sell a car that
dev_del() accomplishes both tasks in one function, with the
kobj_unmap() part having no effect, if the cdev is not mapped at the
time of the call.
--
James C. Georgas <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
On Sat, 2005-08-06 at 12:21 -0700, Randy.Dunlap wrote:
> On Sat, 06 Aug 2005 09:26:15 -0400 James C. Georgas wrote:
>
> > If I allocate a struct cdev using cdev_alloc(), what function do I call
> > to free it when I'm done with it?
>
> Should be cdev_put(), which ca
On Sat, 2005-08-06 at 12:21 -0700, Randy.Dunlap wrote:
On Sat, 06 Aug 2005 09:26:15 -0400 James C. Georgas wrote:
If I allocate a struct cdev using cdev_alloc(), what function do I call
to free it when I'm done with it?
Should be cdev_put(), which calls kobject_put(), which implements
function, with the
kobj_unmap() part having no effect, if the cdev is not mapped at the
time of the call.
--
James C. Georgas [EMAIL PROTECTED]
-
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
+
+struct inode;
+
struct cdev {
struct kobject kobj;
struct module *owner;
--
James C. Georgas <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordo
+++ linux/include/linux/cdev.h 2005-08-05 21:41:39.0 -0400
@@ -2,6 +2,12 @@
#define _LINUX_CDEV_H
#ifdef __KERNEL__
+#include
+#include
+#include
+
+struct inode;
+
struct cdev {
struct kobject kobj;
struct module *owner;
--
James C. Georgas <[EMAIL PROTEC
;
--
James C. Georgas [EMAIL PROTECTED]
-
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/
+#include linux/list.h
+#include linux/types.h
+
+struct inode;
+
struct cdev {
struct kobject kobj;
struct module *owner;
--
James C. Georgas [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
36 matches
Mail list logo
