Hi,
So here it goes the first pre of 2.4.18 series: Pretty big patch with 3
arch updates.
Nothing critical to the core, though.
pre1:
- S390 merge (IBM)
- SuperH merge (SuperH team)
- PPC merge (Benjamin Herrenschmidt)
- PCI DMA update (David S. Miller)
- radeonfb update (Ani Joshi)
- aty128fb update (Ani Joshi)
- Add nVidia GeForce3 support to rivafb (Ani Joshi)
- Add PM support to opl3sa2 (Zwane Mwaikambo)
- Basic ethtool support for 3com, starfire
and pcmcia net drivers (Jeff Garzik)
- Add MII ethtool interface (Jeff Garzik)
- starfire,sundance,dl2k,sis900,8139{too,cp},
natsemi driver updates (Jeff Garzik)
- ufs/minix: mark inodes as bad in case of read
failure (Christoph Hellwig)
- ReiserFS fixes (Oleg Drokin)
- sonypi update (Stelian Pop)
- n_hdlc update (Paul Fulghum)
- Fix compile error on aty_base.c (Tobias Ringstrom)
- Document cpu_to_xxxx() on kernel-hacking doc (Rusty Russell)
- USB update (Greg KH)
- Fix sysctl console loglevel bug on
IA64 (and possibly other archs) (Jesper Juhl)
- Update Athlon/VIA PCI quirks (Calin A. Culianu)
- blkmtd update (Simon Evans)
- boot protocol update (makes the highest
possible initrd address available to the
bootloader) (H. Peter Anvin)
- NFS fixes (Trond Myklebust)
Just a reminder, sis woes persist -
all else seems fine at this point.
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.18pre1; fi
depmod: *** Unresolved symbols in
/lib/modules/2.4.18pre1/kernel/drivers/char/drm/sis.o
depmod: sis_malloc_Ra3329ed5
depmod: sis_free_Rced25333
Regards,
jjs
Marcelo Tosatti wrote:
>Hi,
>
>So here it goes the first pre of 2.4.18 series: Pretty big patch with 3
>arch updates.
>
>Nothing critical to the core, though.
>
>
>pre1:
>
>- S390 merge (IBM)
>- SuperH merge (SuperH team)
>- PPC merge (Benjamin Herrenschmidt)
>- PCI DMA update (David S. Miller)
>- radeonfb update (Ani Joshi)
>- aty128fb update (Ani Joshi)
>- Add nVidia GeForce3 support to rivafb (Ani Joshi)
>- Add PM support to opl3sa2 (Zwane Mwaikambo)
>- Basic ethtool support for 3com, starfire
> and pcmcia net drivers (Jeff Garzik)
>- Add MII ethtool interface (Jeff Garzik)
>- starfire,sundance,dl2k,sis900,8139{too,cp},
> natsemi driver updates (Jeff Garzik)
>- ufs/minix: mark inodes as bad in case of read
> failure (Christoph Hellwig)
>- ReiserFS fixes (Oleg Drokin)
>- sonypi update (Stelian Pop)
>- n_hdlc update (Paul Fulghum)
>- Fix compile error on aty_base.c (Tobias Ringstrom)
>- Document cpu_to_xxxx() on kernel-hacking doc (Rusty Russell)
>- USB update (Greg KH)
>- Fix sysctl console loglevel bug on
> IA64 (and possibly other archs) (Jesper Juhl)
>- Update Athlon/VIA PCI quirks (Calin A. Culianu)
>- blkmtd update (Simon Evans)
>- boot protocol update (makes the highest
> possible initrd address available to the
> bootloader) (H. Peter Anvin)
>- NFS fixes (Trond Myklebust)
>
>
>
>-
>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/
>
> - radeonfb update (Ani Joshi)
This seems to break the compile for radeonfb for me:
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -c -o radeonfb.o radeonfb.c
radeonfb.c: In function `radeon_save_state':
radeonfb.c:2283: `TMDS_TRANSMITTER_CNTL' undeclared (first use in this function)
radeonfb.c:2283: (Each undeclared identifier is reported only once
radeonfb.c:2283: for each function it appears in.)
radeonfb.c: In function `radeon_load_video_mode':
radeonfb.c:2560: `TMDS_RAN_PAT_RST' undeclared (first use in this function)
radeonfb.c:2561: `ICHCSEL' undeclared (first use in this function)
radeonfb.c:2561: `TMDS_PLLRST' undeclared (first use in this function)
radeonfb.c: In function `radeon_write_mode':
radeonfb.c:2650: `TMDS_TRANSMITTER_CNTL' undeclared (first use in this function)
radeonfb.c:2655: `LVDS_STATE_MASK' undeclared (first use in this function)
radeonfb.c: At top level:
radeonfb.c:2957: warning: `fbcon_radeon8' defined but not used
make[3]: *** [radeonfb.o] Error 1
make[3]: Leaving directory `/usr/src/linux/drivers/video'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux/drivers/video'
make[1]: *** [_subdir_video] Error 2
make[1]: Leaving directory `/usr/src/linux/drivers'
make: *** [_dir_drivers] Error 2
More info upon reuqest, but I wasn't able to find any reference to these
symbols anywhere outisde of radeonfb.c, so I don't think it's specific
to my setup.
Nathan
--
Nathan Walp || [email protected]
GPG Fingerprint: || http://faceprint.com/
5509 6EF3 928B 2363 9B2B DA17 3E46 2CDC 492D DB7E
On Wed, 26 Dec 2001 11:55:27 -0800,
J Sloan <[email protected]> wrote:
>Just a reminder, sis woes persist -
>all else seems fine at this point.
>
>if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.18pre1; fi
>depmod: *** Unresolved symbols in
>/lib/modules/2.4.18pre1/kernel/drivers/char/drm/sis.o
>depmod: sis_malloc_Ra3329ed5
>depmod: sis_free_Rced25333
You have to select CONFIG_FB_SIS as well. This is a deficency in CML1
that is difficult to fix, there are cross directory dependencies.
On Thu, 27 Dec 2001, Keith Owens wrote:
> On Wed, 26 Dec 2001 11:55:27 -0800,
> J Sloan <[email protected]> wrote:
> >Just a reminder, sis woes persist -
> >all else seems fine at this point.
> >
> >if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.18pre1; fi
> >depmod: *** Unresolved symbols in
> >/lib/modules/2.4.18pre1/kernel/drivers/char/drm/sis.o
> >depmod: sis_malloc_Ra3329ed5
> >depmod: sis_free_Rced25333
>
> You have to select CONFIG_FB_SIS as well. This is a deficency in CML1
> that is difficult to fix, there are cross directory dependencies.
>
This workaround seems to work (I know it's ugly):
--- linux-2.4.18-pre1/drivers/char/drm/Config.in Sat Dec 22 07:20:44 2001
+++ linux/drivers/char/drm/Config.in Thu Dec 27 06:51:19 2001
@@ -14,4 +14,7 @@
dep_tristate ' Intel I810' CONFIG_DRM_I810 $CONFIG_AGP
dep_tristate ' Matrox g200/g400' CONFIG_DRM_MGA $CONFIG_AGP
dep_tristate ' SiS' CONFIG_DRM_SIS $CONFIG_AGP
+ if [ "$CONFIG_DRM_SIS" != "n" ]; then
+ define_bool CONFIG_FB_SIS y
+ fi
fi
--- linux-2.4.18-pre1/drivers/video/Config.in Fri Nov 23 07:41:27 2001
+++ linux/drivers/video/Config.in Thu Dec 27 06:30:32 2001
@@ -139,6 +139,9 @@
tristate ' ATI Radeon display support (EXPERIMENTAL)' CONFIG_FB_RADEON
tristate ' ATI Rage128 display support (EXPERIMENTAL)' CONFIG_FB_ATY128
tristate ' SIS acceleration (EXPERIMENTAL)' CONFIG_FB_SIS
+ if [ "$CONFIG_DRM_SIS" != "n" -a "$CONFIG_FB_SIS" != "y" ]; then
+ define_bool CONFIG_FB_SIS y
+ fi
if [ "$CONFIG_FB_SIS" != "n" ]; then
bool ' SIS 630/540/730 support' CONFIG_FB_SIS_300
bool ' SIS 315H/315 support' CONFIG_FB_SIS_315
--
Niels Kristian Bech Jensen -- [email protected] -- http://www.image.dk/~nkbj/
----------->> Stop software piracy --- use free software! <<-----------
On Thu, 27 Dec 2001 07:05:06 +0100 (CET),
Niels Kristian Bech Jensen <[email protected]> wrote:
>On Thu, 27 Dec 2001, Keith Owens wrote:
>> You have to select CONFIG_FB_SIS as well. This is a deficency in CML1
>> that is difficult to fix, there are cross directory dependencies.
>>
>This workaround seems to work (I know it's ugly):
>
>--- linux-2.4.18-pre1/drivers/char/drm/Config.in Sat Dec 22 07:20:44 2001
>+++ linux/drivers/char/drm/Config.in Thu Dec 27 06:51:19 2001
>@@ -14,4 +14,7 @@
> dep_tristate ' Intel I810' CONFIG_DRM_I810 $CONFIG_AGP
> dep_tristate ' Matrox g200/g400' CONFIG_DRM_MGA $CONFIG_AGP
> dep_tristate ' SiS' CONFIG_DRM_SIS $CONFIG_AGP
>+ if [ "$CONFIG_DRM_SIS" != "n" ]; then
>+ define_bool CONFIG_FB_SIS y
>+ fi
> fi
>--- linux-2.4.18-pre1/drivers/video/Config.in Fri Nov 23 07:41:27 2001
>+++ linux/drivers/video/Config.in Thu Dec 27 06:30:32 2001
>@@ -139,6 +139,9 @@
> tristate ' ATI Radeon display support (EXPERIMENTAL)' CONFIG_FB_RADEON
> tristate ' ATI Rage128 display support (EXPERIMENTAL)' CONFIG_FB_ATY128
> tristate ' SIS acceleration (EXPERIMENTAL)' CONFIG_FB_SIS
>+ if [ "$CONFIG_DRM_SIS" != "n" -a "$CONFIG_FB_SIS" != "y" ]; then
>+ define_bool CONFIG_FB_SIS y
>+ fi
> if [ "$CONFIG_FB_SIS" != "n" ]; then
> bool ' SIS 630/540/730 support' CONFIG_FB_SIS_300
> bool ' SIS 315H/315 support' CONFIG_FB_SIS_315
Breaks with CONFIG_FB=n. You are setting CONFIG_FB_SIS=y when the
overall FB system may be disabled, that will not work.
The problem is that DRM_SIS should only be visible when FB=y,
EXPERIMENTAL=y, PCI=y and FB_SIS=y. But the FB stuff is in
drivers/video which is read after drivers/char. Easy to do in CML2,
almost impossible in CML1.
> Linux 2.4.18-pre1
>
>
> Hi,
>
> So here it goes the first pre of 2.4.18 series: Pretty big patch with 3
> arch updates.
>
> Nothing critical to the core, though.
>
Will the "new" eepro100 driver been included into 2.4.18?
Martin
--
+-----------------------------------------------------+
|Martin Knoblauch |
|-----------------------------------------------------|
|http://www.knobisoft.de/cats |
|-----------------------------------------------------|
|e-mail: [email protected] |
+-----------------------------------------------------+
On Wed, Dec 26, 2001 at 03:11:44PM -0200, Marcelo Tosatti wrote:
> Hi,
>
> So here it goes the first pre of 2.4.18 series: Pretty big patch with 3
> arch updates.
>
> Nothing critical to the core, though.
>
>
> pre1:
[...]
> - sonypi update (Stelian Pop)
[...]
The patch isn't present in -pre1, however. I attach it again, in
case it's more convenient for you.
Stelian.
diff -uNr --exclude-from=dontdiff linux-2.4.17.orig/Documentation/sonypi.txt linux-2.4.17/Documentation/sonypi.txt
--- linux-2.4.17.orig/Documentation/sonypi.txt Wed Dec 26 10:33:53 2001
+++ linux-2.4.17/Documentation/sonypi.txt Tue Dec 18 13:11:40 2001
@@ -25,7 +25,8 @@
can be downloaded at: <http://www.alcove-labs.org/en/software/sonypi/>
This driver supports also some ioctl commands for setting the LCD screen
-brightness (some more commands may be added in the future).
+brightness and querying the batteries charge information (some more
+commands may be added in the future).
This driver can also be used to set the camera controls on Picturebook series
(brightness, contrast etc), and is used by the video4linux driver for the
diff -uNr --exclude-from=dontdiff linux-2.4.17.orig/drivers/char/sonypi.c linux-2.4.17/drivers/char/sonypi.c
--- linux-2.4.17.orig/drivers/char/sonypi.c Wed Dec 26 10:33:57 2001
+++ linux-2.4.17/drivers/char/sonypi.c Tue Dec 18 13:11:40 2001
@@ -109,25 +109,29 @@
return result;
}
-static void sonypi_ecrset(u16 addr, u16 value) {
+static void sonypi_ecrset(u8 addr, u8 value) {
- wait_on_command(1, inw_p(SONYPI_CST_IOPORT) & 3);
- outw_p(0x81, SONYPI_CST_IOPORT);
- wait_on_command(0, inw_p(SONYPI_CST_IOPORT) & 2);
- outw_p(addr, SONYPI_DATA_IOPORT);
- wait_on_command(0, inw_p(SONYPI_CST_IOPORT) & 2);
- outw_p(value, SONYPI_DATA_IOPORT);
- wait_on_command(0, inw_p(SONYPI_CST_IOPORT) & 2);
-}
-
-static u16 sonypi_ecrget(u16 addr) {
-
- wait_on_command(1, inw_p(SONYPI_CST_IOPORT) & 3);
- outw_p(0x80, SONYPI_CST_IOPORT);
- wait_on_command(0, inw_p(SONYPI_CST_IOPORT) & 2);
- outw_p(addr, SONYPI_DATA_IOPORT);
- wait_on_command(0, inw_p(SONYPI_CST_IOPORT) & 2);
- return inw_p(SONYPI_DATA_IOPORT);
+ wait_on_command(1, inb_p(SONYPI_CST_IOPORT) & 3);
+ outb_p(0x81, SONYPI_CST_IOPORT);
+ wait_on_command(0, inb_p(SONYPI_CST_IOPORT) & 2);
+ outb_p(addr, SONYPI_DATA_IOPORT);
+ wait_on_command(0, inb_p(SONYPI_CST_IOPORT) & 2);
+ outb_p(value, SONYPI_DATA_IOPORT);
+ wait_on_command(0, inb_p(SONYPI_CST_IOPORT) & 2);
+}
+
+static u8 sonypi_ecrget(u8 addr) {
+
+ wait_on_command(1, inb_p(SONYPI_CST_IOPORT) & 3);
+ outb_p(0x80, SONYPI_CST_IOPORT);
+ wait_on_command(0, inb_p(SONYPI_CST_IOPORT) & 2);
+ outb_p(addr, SONYPI_DATA_IOPORT);
+ wait_on_command(0, inb_p(SONYPI_CST_IOPORT) & 2);
+ return inb_p(SONYPI_DATA_IOPORT);
+}
+
+static u16 sonypi_ecrget16(u8 addr) {
+ return sonypi_ecrget(addr) | (sonypi_ecrget(addr + 1) << 8);
}
/* Initializes the device - this comes from the AML code in the ACPI bios */
@@ -510,24 +514,60 @@
static int sonypi_misc_ioctl(struct inode *ip, struct file *fp,
unsigned int cmd, unsigned long arg) {
int ret = 0;
- u8 val;
+ u8 val8;
+ u16 val16;
down(&sonypi_device.lock);
switch (cmd) {
- case SONYPI_IOCGBRT:
- val = sonypi_ecrget(0x96) & 0xff;
- if (copy_to_user((u8 *)arg, &val, sizeof(val))) {
- ret = -EFAULT;
- goto out;
- }
- break;
- case SONYPI_IOCSBRT:
- if (copy_from_user(&val, (u8 *)arg, sizeof(val))) {
- ret = -EFAULT;
- goto out;
- }
- sonypi_ecrset(0x96, val);
- break;
+ case SONYPI_IOCGBRT:
+ val8 = sonypi_ecrget(0x96);
+ if (copy_to_user((u8 *)arg, &val8, sizeof(val8))) {
+ ret = -EFAULT;
+ goto out;
+ }
+ break;
+ case SONYPI_IOCSBRT:
+ if (copy_from_user(&val8, (u8 *)arg, sizeof(val8))) {
+ ret = -EFAULT;
+ goto out;
+ }
+ sonypi_ecrset(0x96, val8);
+ break;
+ case SONYPI_IOCGBAT1CAP:
+ val16 = sonypi_ecrget16(0xb2);
+ if (copy_to_user((u16 *)arg, &val16, sizeof(val16))) {
+ ret = -EFAULT;
+ goto out;
+ }
+ break;
+ case SONYPI_IOCGBAT1REM:
+ val16 = sonypi_ecrget16(0xa2);
+ if (copy_to_user((u16 *)arg, &val16, sizeof(val16))) {
+ ret = -EFAULT;
+ goto out;
+ }
+ break;
+ case SONYPI_IOCGBAT2CAP:
+ val16 = sonypi_ecrget16(0xba);
+ if (copy_to_user((u16 *)arg, &val16, sizeof(val16))) {
+ ret = -EFAULT;
+ goto out;
+ }
+ break;
+ case SONYPI_IOCGBAT2REM:
+ val16 = sonypi_ecrget16(0xaa);
+ if (copy_to_user((u16 *)arg, &val16, sizeof(val16))) {
+ ret = -EFAULT;
+ goto out;
+ }
+ break;
+ case SONYPI_IOCGBATFLAGS:
+ val8 = sonypi_ecrget(0x81) & 0x07;
+ if (copy_to_user((u8 *)arg, &val8, sizeof(val8))) {
+ ret = -EFAULT;
+ goto out;
+ }
+ break;
default:
ret = -EINVAL;
}
diff -uNr --exclude-from=dontdiff linux-2.4.17.orig/drivers/char/sonypi.h linux-2.4.17/drivers/char/sonypi.h
--- linux-2.4.17.orig/drivers/char/sonypi.h Wed Dec 26 10:33:57 2001
+++ linux-2.4.17/drivers/char/sonypi.h Fri Dec 21 15:35:37 2001
@@ -35,7 +35,7 @@
#ifdef __KERNEL__
#define SONYPI_DRIVER_MAJORVERSION 1
-#define SONYPI_DRIVER_MINORVERSION 8
+#define SONYPI_DRIVER_MINORVERSION 9
#include <linux/types.h>
#include <linux/pci.h>
diff -uNr --exclude-from=dontdiff linux-2.4.17.orig/include/linux/sonypi.h linux-2.4.17/include/linux/sonypi.h
--- linux-2.4.17.orig/include/linux/sonypi.h Thu Oct 11 20:17:22 2001
+++ linux-2.4.17/include/linux/sonypi.h Fri Dec 21 15:35:37 2001
@@ -75,9 +75,21 @@
#define SONYPI_EVENT_LID_OPENED 37
-/* brightness etc. ioctls */
-#define SONYPI_IOCGBRT _IOR('v', 0, __u8)
-#define SONYPI_IOCSBRT _IOW('v', 0, __u8)
+/* get/set brightness */
+#define SONYPI_IOCGBRT _IOR('v', 0, __u8)
+#define SONYPI_IOCSBRT _IOW('v', 0, __u8)
+
+/* get battery full capacity/remaining capacity */
+#define SONYPI_IOCGBAT1CAP _IOR('v', 2, __u16)
+#define SONYPI_IOCGBAT1REM _IOR('v', 3, __u16)
+#define SONYPI_IOCGBAT2CAP _IOR('v', 4, __u16)
+#define SONYPI_IOCGBAT2REM _IOR('v', 5, __u16)
+
+/* get battery flags: battery1/battery2/ac adapter present */
+#define SONYPI_BFLAGS_B1 0x01
+#define SONYPI_BFLAGS_B2 0x02
+#define SONYPI_BFLAGS_AC 0x04
+#define SONYPI_IOCGBATFLAGS _IOR('v', 7, __u8)
#ifdef __KERNEL__
--
Stelian Pop <[email protected]>
|---------------- Free Software Engineer -----------------|
| Alc?ve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
|------------- Alc?ve, liberating software ---------------|
Hello all,
Marcelo Tosatti wrote:
> - Update Athlon/VIA PCI quirks (Calin A.
>
Culianu)
I tested this patch and unfortunately, I have to say, it is not working
(if it should prevent the suddenly changing time on VIA-boards).
I have the same problem with suddenly changing time as without this patch.
Furthermore, there are these entries in messages. They came in while
printing via parport to printer HP6P.
Dec 28 18:34:09 athlon kernel: DMA write timed out
Dec 28 18:34:35 athlon kernel: DMA write timed out
Dec 28 18:35:01 athlon kernel: DMA write timed out
Dec 28 18:35:52 athlon last message repeated 2 times
Dec 28 18:36:17 athlon kernel: DMA write timed out
Dec 28 18:37:09 athlon last message repeated 2 times
Dec 28 18:37:32 athlon kernel: DMA write timed out
Dec 28 18:37:59 athlon kernel: DMA write timed out
Dec 28 18:38:25 athlon kernel: DMA write timed out
Dec 28 18:38:51 athlon kernel: DMA write timed out
Kernel tells that lp0 uses
"lp0: ECP mode".
I configured in modules.conf:
alias parport_lowlevel parport_pc
options parport_pc io=0x278 irq=5 dma=3
which should be correct regarding bios configurations.
Unfortunately I can't say, if these entries came in before or after the
problem with the changing time.
The entries in messages and the time changing problem appeared during a
lot of diskusage (io).
Regards,
Andreas Hartmann
> > - Update Athlon/VIA PCI quirks (Calin A.
>I tested this patch and unfortunately, I have to say, it is not working
(if it should prevent the
>suddenly changing time on VIA-boards). I have the same problem with
suddenly changing time as
>without this patch.
Nope, the change is related to a bug in the VIA Northbridge memory write
queue timer causing oopses on Athlon optimised linux kernels.
I believe the patch you're looking for is last seen in the ac series,
and not merged with 2.4 mainline due to triggering on unaffected
motherboards.
--
Troels Walsted Hansen
Troels Walsted Hansen wrote:
>>>- Update Athlon/VIA PCI quirks (Calin A.
>>>
>>I tested this patch and unfortunately, I have to say, it is not working
>>
> (if it should prevent the
>
>>suddenly changing time on VIA-boards). I have the same problem with
>>
> suddenly changing time as
>
>>without this patch.
>>
>
> Nope, the change is related to a bug in the VIA Northbridge memory write
> queue timer causing oopses on Athlon optimised linux kernels.
Sorry - I thought there could be a dependence between both problems.
Thank you for your hint!
Regards,
Andreas Hartmann
> I tested this patch and unfortunately, I have to say, it is not working
> (if it should prevent the suddenly changing time on VIA-boards).
> I have the same problem with suddenly changing time as without this patch.
It doesn't thats a seperate bug that nobody has bothered to fix yet. It
probably also explains the occasional wild time jumps a few people have
seen.
> I believe the patch you're looking for is last seen in the ac series,
> and not merged with 2.4 mainline due to triggering on unaffected
> motherboards.
The -ac change is mostly a workaround. There is missing locking on the timer
chip handling. Until someone (else) fixes that and we prove that there are
hardware locking issues too, I won't be submitting the workaround because
that'll just stop people fixing the bug
On Fri, Dec 28, 2001 at 08:44:02PM +0100, Andreas Hartmann wrote:
> Dec 28 18:34:09 athlon kernel: DMA write timed out
These messages are not actually errors, despite appearances. (However
DMA printing is known to be buggy currently, under some
circumstances.)
Tim.
*/
Hi All,
I've researched this question and haven't been able to find a suitable
answer. The answer may be "it's painless as-is, just go for it". It
might also be "give up now while you still have your pants".
I'd like to use the software watchdog timer, softdog.c, on the Sparc
architecture, using kernel 2.2.17. I used this to build the module:
cd /usr/src/linux-2.2.17/drivers/char
gcc -c -DMODVERSIONS -D__KERNEL__ -DMODULE -Wall -Wstrict-prototypes
softdog.c
The module builds fine with some warnings. After copying it over to
/lib/modules/2.2.17/misc/softdog.o and running depmod -a, I get
modprobe: ELF file not for this architecture
I haven't tried modprobe'ing the module yet, the above message frightens
me.
Is this driver safe for the sparc architecture? If not, what would it
take? Or did I screw up somwehere along the way?
Please CC: me as I am not on the list.
Thanks in advance,
Josh Wyatt
On Thu, Jan 10, 2002 at 09:49:00AM -0500, Josh Wyatt wrote:
> I'd like to use the software watchdog timer, softdog.c, on the Sparc
> architecture, using kernel 2.2.17. I used this to build the module:
> cd /usr/src/linux-2.2.17/drivers/char
> gcc -c -DMODVERSIONS -D__KERNEL__ -DMODULE -Wall -Wstrict-prototypes
> softdog.c
Why are you building it manually? It'd be better to turn it on
using the configuration tools, and build it in the normal way?
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Russell King wrote:
>
> On Thu, Jan 10, 2002 at 09:49:00AM -0500, Josh Wyatt wrote:
> > I'd like to use the software watchdog timer, softdog.c, on the Sparc
> > architecture, using kernel 2.2.17. I used this to build the module:
> > cd /usr/src/linux-2.2.17/drivers/char
> > gcc -c -DMODVERSIONS -D__KERNEL__ -DMODULE -Wall -Wstrict-prototypes
> > softdog.c
>
> Why are you building it manually? It'd be better to turn it on
> using the configuration tools, and build it in the normal way?
Please CC: me as I am not on the list.
I built the module manually precisely because I did not want to rebuild
the entire kernel and module set just to get this one module.
Perhaps I do not understand the correct approach to building individual
modules, on an existing tree.
What's the documented, correct approach to only building a single
module, starting with menuconfig, such that it will happily fit in with
the currently running kernel and modules? I notice that many
drivers/modules happily include the correct gcc incantation (in comment)
for doing exactly this, and many do not.
And finally, back to my original question, is it a mute point? Is the
softdog an Intel-only thing?
Thanks,
josh
>
> --
> Russell King ([email protected]) The developer of ARM Linux
> http://www.arm.linux.org.uk/personal/aboutme.html