Re: Nvidia SATA - Seagate SATA Drives
Robert Hancock wrote:
Jim Gifford wrote:
Robert Hancock wrote:
Jim Gifford wrote:
Here's the situation. I have a MSI KN8Neo-f motherboard with a
Seagate Barracuda 250 GB SATA drive. I have replaced this drive
three times in the last two weeks due to it failing. Now the only
thing in common is the use of a 2.6.22.9 kernel I built from
scratch, before that I was using 2.6.19 kernel but working on doing
some upgrades for the CLFS project and tried a 2.6.22.9. I will
explain the situation and including the links I used for fix the
issues.
It boots up and instantly has a problem detecting so I have to add
irqpoll to my bootup line. {Reference
http://my.opera.com/snowburn/blog/index.dml/tag/failed%20to%20set%20xfermode}
Then I get the adma issue, so I add sata_nv.adma=0 to my bootup
line.{Reference
http://www.ussg.iu.edu/hypermail/linux/kernel/0706.1/1424.html}
Now after a few times of booting the drive completely fails. So is
the nv_sata drive the cause?? Based on what I have done yes, and
the reason I can say that is because I took another one of those
drives and the same computer loaded Windows(forgive me for using
this word!!!) on it and it worked perfectly.
You'll have to be more specific about "completely fails".. Also, it
would be useful to get the dmesg output from dmesg directly and not
from syslog, as the entries posted under the second link you gave
were missing some critical information (it seems that syslog can do
this in some cases..) In particular the line showing what command
failed would be useful.
It never gets into the system at all, just locks up. The hard drive
starts clicking and eventually doesn't get recognized by BIOS.
That doesn't sound like a kernel problem if it's not even recognized
by the BIOS, there's nothing the kernel should be able to do that
could cause that. Sounds more like a hardware issue. If the drive has
been replaced before then it could be a power supply or temperature
problem?
I thought that also, just tried a new power supply, same problem. I can
recreate this problem within minutes with a new drive. Got 2 more drives
left in this batch. Temperature is in the low range of the specs.
-
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: Nvidia SATA - Seagate SATA Drives
Robert Hancock wrote:
Jim Gifford wrote:
Here's the situation. I have a MSI KN8Neo-f motherboard with a
Seagate Barracuda 250 GB SATA drive. I have replaced this drive three
times in the last two weeks due to it failing. Now the only thing in
common is the use of a 2.6.22.9 kernel I built from scratch, before
that I was using 2.6.19 kernel but working on doing some upgrades for
the CLFS project and tried a 2.6.22.9. I will explain the situation
and including the links I used for fix the issues.
It boots up and instantly has a problem detecting so I have to add
irqpoll to my bootup line. {Reference
http://my.opera.com/snowburn/blog/index.dml/tag/failed%20to%20set%20xfermode}
Then I get the adma issue, so I add sata_nv.adma=0 to my bootup
line.{Reference
http://www.ussg.iu.edu/hypermail/linux/kernel/0706.1/1424.html}
Now after a few times of booting the drive completely fails. So is
the nv_sata drive the cause?? Based on what I have done yes, and the
reason I can say that is because I took another one of those drives
and the same computer loaded Windows(forgive me for using this
word!!!) on it and it worked perfectly.
You'll have to be more specific about "completely fails".. Also, it
would be useful to get the dmesg output from dmesg directly and not
from syslog, as the entries posted under the second link you gave were
missing some critical information (it seems that syslog can do this in
some cases..) In particular the line showing what command failed would
be useful.
It never gets into the system at all, just locks up. The hard drive
starts clicking and eventually doesn't get recognized by BIOS.
Using "irqpoll" is not a very good workaround, it really is just a
band-aid to get things working. Often this indicates motherboard IRQ
routing issues. You may want to make sure you have the latest BIOS
installed for the board.
I'll check for a new BIOS, but believe I have the most current on it.
One other issue that showed up was the drive does not recognize the
drive when it's in the 3gb transfer mode, I have to jumper it to
1.5gb mode.
Here's a link to the drive model:
http://www.seagate.com/ww/v/index.jsp?vgnextoid=a62099f4fa74c010VgnVCM10dd04090aRCRD&locale=en-US
Here's a link to my motherboard:
http://www.msicomputer.com/product/p_spec.asp?model=K8N_Neo4-F&class=mb
It has 2GB of Memory and a Nvidia PCI-E Graphics Adapter
I will work with any member of the lkml team to help isolate the
issue, the only issue is that when it locks up everything has to be
written down or photographed.
-
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/
Nvidia SATA - Seagate SATA Drives
Here's the situation. I have a MSI KN8Neo-f motherboard with a Seagate
Barracuda 250 GB SATA drive. I have replaced this drive three times in
the last two weeks due to it failing. Now the only thing in common is
the use of a 2.6.22.9 kernel I built from scratch, before that I was
using 2.6.19 kernel but working on doing some upgrades for the CLFS
project and tried a 2.6.22.9. I will explain the situation and
including the links I used for fix the issues.
It boots up and instantly has a problem detecting so I have to add
irqpoll to my bootup line. {Reference
http://my.opera.com/snowburn/blog/index.dml/tag/failed%20to%20set%20xfermode}
Then I get the adma issue, so I add sata_nv.adma=0 to my bootup
line.{Reference
http://www.ussg.iu.edu/hypermail/linux/kernel/0706.1/1424.html}
Now after a few times of booting the drive completely fails. So is the
nv_sata drive the cause?? Based on what I have done yes, and the reason
I can say that is because I took another one of those drives and the
same computer loaded Windows(forgive me for using this word!!!) on it
and it worked perfectly.
One other issue that showed up was the drive does not recognize the
drive when it's in the 3gb transfer mode, I have to jumper it to 1.5gb mode.
Here's a link to the drive model:
http://www.seagate.com/ww/v/index.jsp?vgnextoid=a62099f4fa74c010VgnVCM10dd04090aRCRD&locale=en-US
Here's a link to my motherboard:
http://www.msicomputer.com/product/p_spec.asp?model=K8N_Neo4-F&class=mb
It has 2GB of Memory and a Nvidia PCI-E Graphics Adapter
I will work with any member of the lkml team to help isolate the issue,
the only issue is that when it locks up everything has to be written
down or photographed.
Jim Gifford - CLFS Developer
http://www.cross-lfs.org
-
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/
Powermac Sound Issue with Wallstreet PowerBook
For over the last few weeks, I've been trying to get sound working on my Powerbook G3. I've tried various different things with no luck. Anyone got any ideas?? dmasound_pmac: Awacs/Screamer Codec Mfct: 2 Rev 3 input: dmasound beeper as /class/input/input4 PowerMac Screamer DMA sound driver rev 016 installed Core driver edition 01.06 : PowerMac Built-in Sound driver edition 00.07 Write will use4 fragments of 32768 bytes as default Read will use4 fragments of 32768 bytes as default Advanced Linux Sound Architecture Driver Version 1.0.13 (Tue Nov 28 14:07:24 2006 UTC). PM: Adding info for platform:snd_powermac snd: can't request rsrc 0 (Sound Control: 0xf3014000:f3014fff) ALSA device list: No soundcards found. - 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: 64bit build of tulip driver
With Grant's help I was able to get the tulip driver to work with 64 bit
MIPS.
Again Thanx Grant. Attached is the patch I used.
diff -Naur linux-2.6.11.6/drivers/net/tulip/eeprom.c linux-2.6.11.6/drivers/net/tulip/eeprom.c
--- linux-2.6.11.6/drivers/net/tulip/eeprom.c 2005-03-25 19:28:37 -0800
+++ linux-2.6.11.6/drivers/net/tulip/eeprom.c 2005-04-01 09:13:39 -0800
@@ -63,6 +63,22 @@
*/
{ 0x1e00, 0x, 0x000b, 0x8f01, 0x0103, 0x0300, 0x0821, 0x000, 0x0001, 0x, 0x01e1 }
},
+ {"Cobalt Microserver", 0, 0x10, 0xE0, {0x1e00, /* 0 == controller #, 1e == offset */
+ 0x, /* 0 == high offset, 0 == gap */
+ 0x0800, /* Default Autoselect */
+ 0x8001, /* 1 leaf, extended type, bogus len */
+ 0x0003, /* Type 3 (MII), PHY #0 */
+ 0x0400, /* 0 init instr, 4 reset instr */
+ 0x0801, /* Set control mode, GP0 output */
+ 0x, /* Drive GP0 Low (RST is active low) */
+ 0x0800, /* control mode, GP0 input (undriven) */
+ 0x, /* clear control mode */
+ 0x7800, /* 100TX FDX + HDX, 10bT FDX + HDX */
+ 0x01e0, /* Advertise all above */
+ 0x5000, /* FDX all above */
+ 0x1800, /* Set fast TTM in 100bt modes */
+ 0x, /* PHY cannot be unplugged */
+ }},
{NULL}};
diff -Naur linux-2.6.11.6/drivers/net/tulip/interrupt.c linux-2.6.11.6/drivers/net/tulip/interrupt.c
--- linux-2.6.11.6/drivers/net/tulip/interrupt.c 2005-03-25 19:28:40 -0800
+++ linux-2.6.11.6/drivers/net/tulip/interrupt.c 2005-04-01 08:59:41 -0800
@@ -26,7 +26,7 @@
#define MIT_SIZE 15
#define MIT_TABLE 15 /* We use 0 or max */
-unsigned int mit_table[MIT_SIZE+1] =
+static unsigned int mit_table[MIT_SIZE+1] =
{
/* CRS11 21143 hardware Mitigation Control Interrupt
We use only RX mitigation we other techniques for
diff -Naur linux-2.6.11.6/drivers/net/tulip/media.c linux-2.6.11.6/drivers/net/tulip/media.c
--- linux-2.6.11.6/drivers/net/tulip/media.c 2005-03-25 19:28:17 -0800
+++ linux-2.6.11.6/drivers/net/tulip/media.c 2005-04-01 08:57:20 -0800
@@ -44,8 +44,10 @@
/* MII transceiver control section.
Read and write the MII registers using software-generated serial
- MDIO protocol. See the MII specifications or DP83840A data sheet
- for details. */
+ MDIO protocol.
+ See IEEE 802.3-2002.pdf (Section 2, Chapter "22.2.4 Management functions")
+ or DP83840A data sheet for more details.
+ */
int tulip_mdio_read(struct net_device *dev, int phy_id, int location)
{
@@ -88,7 +90,7 @@
value = ioread32(ioaddr + CSR9);
iowrite32(value & 0xFFEF, ioaddr + CSR9);
- value = (phy_id << 21) | (location << 16) | 0x8000;
+ value = (phy_id << 21) | (location << 16) | 0x0800;
iowrite32(value, ioaddr + CSR10);
while(--i > 0) {
@@ -166,7 +168,7 @@
value = ioread32(ioaddr + CSR9);
iowrite32(value & 0xFFEF, ioaddr + CSR9);
- value = (phy_id << 21) | (location << 16) | 0x4000 | (val & 0x);
+ value = (phy_id << 21) | (location << 16) | 0x0400 | (val & 0x);
iowrite32(value, ioaddr + CSR10);
while(--i > 0) {
@@ -307,13 +309,29 @@
int reset_length = p[2 + init_length];
misc_info = (u16*)(reset_sequence + reset_length);
if (startup) {
+ int timeout = 10; /* max 1 ms */
iowrite32(mtable->csr12dir | 0x100, ioaddr + CSR12);
for (i = 0; i < reset_length; i++)
iowrite32(reset_sequence[i], ioaddr + CSR12);
+
+ /* flush posted writes */
+ ioread32(ioaddr + CSR12);
+
+ /* Sect 3.10.3 in DP83840A.pdf (p39) */
+ udelay(500);
+
+ /* Section 4.2 in DP83840A.pdf (p43) */
+ /* and IEEE 802.3 "22.2.4.1.1 Reset" */
+ while (timeout-- &&
+ (tulip_mdio_read (dev, phy_num, MII_BMCR) & BMCR_RESET))
+ udelay(100);
}
for (i = 0; i < init_length; i++)
iowrite32(init_sequence[i], ioaddr + CSR12);
+
+ioread32(ioaddr + CSR12); /* flush posted writes */
}
+
tmp_info = get_u16(&misc_info[1]);
if (tmp_info)
tp->advertising[phy_num] = tmp_info | 1;
diff -Naur linux-2.6.11.6/drivers/net/tulip/tulip.h linux-2.6.11.6/drivers/net/tulip/tulip.h
--- linux-2.6.11.6/drivers/net/tulip/tulip.h 2005-03-25 19:28:36 -0800
+++ linux-2.6.11.6/drivers/net/tulip/tulip.h 2005-04-01 09:01:07 -0800
@@ -475,8 +475,11 @@
udelay(10);
if (!i)
- printk(KERN_DEBUG "%s: tulip_stop_rxtx() failed\n",
- tp->pdev->slot_name);
+ printk(KERN_DEBUG "%s: tulip_stop_rxtx() failed"
+ " (CSR5 0x%x CSR6 0x%x)\n",
+ pci_name(tp->pdev),
+ ioread32(ioaddr + CSR5),
+ ioread32(ioaddr + CSR6));
}
}
diff -Naur linux-2.6.11.6/drivers/net/tulip/tulip_core.c linux-2.6.11.6/drivers/net/tulip/tulip_core.c
--- linux-2.6.11.6/drivers/net/tulip/tulip_core.c 2005-03-25 19:28:22 -0800
+++ linux-2.6.11.6/drivers/net/tulip/tulip_core.c 2005-04-01 09:01:54 -0800
@@ -22,7 +22,7 @@
#else
#define DRV_VERSION "1.1.13"
#endif
-#define DRV_RELDATE "May 11, 2002"
+#define DRV_RELDATE "December 15, 2004"
Re: 64bit build of tulip driver
Grant, Thank you, I took your driver as a reference and added in the cobalt specifics to the eeprom.c file, works perfectly now. - 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: 64bit build of tulip driver
Grant Thanx for your feedback. I got it working, but I don't think the patch is the best. Here is the patch, and the information, but if you can recommend a different way to fix it, let me know. The patch was done by Peter Horton. Here is the link to the full patch, http://ftp.jg555.com/patches/raq2/linux/linux-2.6.11.6-raq2_fix-2.patch but here is the section for this issue @@ -1628,6 +1631,16 @@ } } +#if defined(CONFIG_MIPS_COBALT) && defined(CONFIG_MIPS64) +/* + * something very bad is happening. without this + * cache flush the PHY can't be read. I've tried + * various ins & outs, delays etc but only a call + * to printk or this flush seems to fix it ... help! + */ +flush_cache_all(); +#endif + /* Find the connected MII xcvrs. Doing this in open() would allow detecting external xcvrs later, but takes much time. */ Are there any config option differences? e.g. MWI or MMIO options enabled on 64-bit but not 32-bit? I verified that there are no differences. ISTR to remember submitting a patch so additional data gets printed in tulip_stop_rxtx. Here is a reference to the patch but I don't think it is relevant to the this problem: http://lkml.org/lkml/2004/12/15/119 Applied the patch, here is the output :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) :00:07.0: tulip_stop_rxtx() failed (CSR5 0xf066 CSR6 0xb3862002) I was able to get some more information on the bootup sequence with the updates. Here is the output now from the driver Linux Tulip driver version 1.1.13 (May 11, 2002) PCI: Enabling device :00:07.0 (0045 -> 0047) tulip0: Old format EEPROM on 'Cobalt Microserver' board. Using substitute media control info. tulip0: EEPROM default media type Autosense. tulip0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. tulip0: ***WARNING***: No MII transceiver found! eth0: Digital DS21143 Tulip rev 65 at b0001400, 00:10:E0:00:32:DE, IRQ 19. PCI: Enabling device :00:0c.0 (0005 -> 0007) tulip1: Old format EEPROM on 'Cobalt Microserver' board. Using substitute media control info. tulip1: EEPROM default media type Autosense. tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. tulip1: ***WARNING***: No MII transceiver found! eth1: Digital DS21143 Tulip rev 65 at ffffb0001480, 00:10:E0:00:32:DF, IRQ 20. -- Jim Gifford [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/
64bit build of tulip driver
Under 32bit the tulip driver works fine, but under 64 bit it gives me a lot if problems. I updated the tulip to what is in the current repository, and the issue still exists. Any suggestions. First off it continually sends data out the network interface and never negotiates is speed and duplex. Second in the log files all I see is an uninformative message :00:07.0: tulip_stop_rxtx() failed Here is all the bootup information differences I can find on the driver 64 bit Dec 31 16:01:29 lfs tulip0: ***WARNING***: No MII transceiver found! Dec 31 16:01:29 lfs tulip1: ***WARNING***: No MII transceiver found! 32 bit Dec 31 16:01:16 lfs tulip0: MII transceiver #1 config 1000 status 7809 advertising 01e1 Dec 31 16:01:16 lfs tulip1: MII transceiver #1 config 1000 status 7809 advertising 01e1. Complete boot log - yes I know the date and time are off. Under a 64 bit compile Dec 31 16:01:29 lfs Linux Tulip driver version 1.1.13 (May 11, 2002) Dec 31 16:01:29 lfs PCI: Enabling device :00:07.0 (0045 -> 0047) Dec 31 16:01:29 lfs tulip0: Old format EEPROM on 'Cobalt Microserver' board. Using substitute media control info. Dec 31 16:01:29 lfs tulip0: EEPROM default media type Autosense. Dec 31 16:01:29 lfs tulip0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 31 16:01:29 lfs tulip0: ***WARNING***: No MII transceiver found! Dec 31 16:01:29 lfs eth0: Digital DS21143 Tulip rev 65 at b0001400, 00:10:E0:00:32:DE, IRQ 19. Dec 31 16:01:29 lfs PCI: Enabling device :00:0c.0 (0005 -> 0007) Dec 31 16:01:29 lfs tulip1: Old format EEPROM on 'Cobalt Microserver' board. Using substitute media control info. Dec 31 16:01:29 lfs tulip1: EEPROM default media type Autosense. Dec 31 16:01:29 lfs tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 31 16:01:29 lfs tulip1: ***WARNING***: No MII transceiver found! Dec 31 16:01:29 lfs eth1: Digital DS21143 Tulip rev 65 at b0001480, 00:10:E0:00:32:DF, IRQ 20. Dec 31 16:01:29 lfs bootlog: Bringing up the eth0 interface...[ OK ] Dec 31 16:01:30 lfs bootlog: Adding IPv4 address 172.16.0.99 to the eth0 interface...[ OK ] Dec 31 16:01:31 lfs bootlog: Setting up default gateway...[ OK ] Dec 31 16:01:32 lfs :00:07.0: tulip_stop_rxtx() failed Dec 31 16:01:38 lfs :00:07.0: tulip_stop_rxtx() failed Dec 31 16:01:44 lfs :00:07.0: tulip_stop_rxtx() failed Dec 31 16:01:50 lfs :00:07.0: tulip_stop_rxtx() failed Dec 31 16:01:56 lfs :00:07.0: tulip_stop_rxtx() failed Dec 31 16:02:02 lfs :00:07.0: tulip_stop_rxtx() failed Dec 31 16:02:08 lfs :00:07.0: tulip_stop_rxtx() failed Under 32 bit Dec 31 16:01:16 lfs Linux Tulip driver version 1.1.13 (May 11, 2002) Dec 31 16:01:16 lfs PCI: Enabling device :00:07.0 (0045 -> 0047) Dec 31 16:01:16 lfs tulip0: Old format EEPROM on 'Cobalt Microserver' board. Using substitute media control info. Dec 31 16:01:16 lfs tulip0: EEPROM default media type Autosense. Dec 31 16:01:16 lfs tulip0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 31 16:01:16 lfs tulip0: MII transceiver #1 config 1000 status 7809 advertising 01e1. Dec 31 16:01:16 lfs eth0: Digital DS21143 Tulip rev 65 at b0001400, 00:10:E0:00:32:DE, IRQ 19. Dec 31 16:01:16 lfs tulip1: Old format EEPROM on 'Cobalt Microserver' board. Using substitute media control info. Dec 31 16:01:16 lfs tulip1: EEPROM default media type Autosense. Dec 31 16:01:16 lfs tulip1: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Dec 31 16:01:16 lfs tulip1: MII transceiver #1 config 1000 status 7809 advertising 01e1. Dec 31 16:01:16 lfs eth1: Digital DS21143 Tulip rev 65 at b0001480, 00:10:E0:00:32:DF, IRQ 20. Dec 31 16:01:17 lfs bootlog: Bringing up the eth0 interface...[ OK ] Dec 31 16:01:17 lfs bootlog: Adding IPv4 address 172.16.0.99 to the eth0 interface...[ OK ] Dec 31 16:01:18 lfs bootlog: Setting up default gateway...[ OK ] Dec 31 16:01:20 lfs eth0: Setting full-duplex based on MII#1 link partner capability of 45e1. -- Jim Gifford [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/
Patch for iomap on MIPS was Re: Build issue current MIPS - RaQ2
Jim Gifford wrote: I have not been able to build kernels since 2.6.9 on my RaQ2 for some time. I have tried the linux-mips.org port and the current 2.6.11.5 release. I keep getting the same error. Building modules, stage 2. MODPOST *** Warning: "pci_iounmap" [drivers/net/tulip/tulip.ko] undefined! *** Warning: "pci_iomap" [drivers/net/tulip/tulip.ko] undefined! I Finally figured it out, Here is a patch diff -Naur linux-2.6.11/arch/mips/lib/Makefile linux-mips-2.6.11/arch/mips/lib/Makefile --- linux-2.6.11/arch/mips/lib/Makefile 2005-03-01 23:37:48 -0800 +++ linux-mips-2.6.11/arch/mips/lib/Makefile2005-03-19 21:49:03 -0800 @@ -2,7 +2,10 @@ # Makefile for MIPS-specific library files.. # -lib-y += csum_partial_copy.o dec_and_lock.o iomap.o memcpy.o promlib.o \ +lib-y += csum_partial_copy.o dec_and_lock.o memcpy.o promlib.o \ strlen_user.o strncpy_user.o strnlen_user.o + +obj-y += iomap.o + EXTRA_AFLAGS := $(CFLAGS) -- Jim Gifford [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/
Build issue current MIPS - RaQ2
I have not been able to build kernels since 2.6.9 on my RaQ2 for some time. I have tried the linux-mips.org port and the current 2.6.11.5 release. I keep getting the same error. Building modules, stage 2. MODPOST *** Warning: "pci_iounmap" [drivers/net/tulip/tulip.ko] undefined! *** Warning: "pci_iomap" [drivers/net/tulip/tulip.ko] undefined! with Make V=1 Building modules, stage 2. make -rR -f /usr/src/linux-2.6.11.5/scripts/Makefile.modpost scripts/mod/modpost -o /usr/src/linux-2.6.11.5/Module.symvers vmlinux drivers/block/loop.o drivers/block/rd.o drivers/cdrom/cdrom.o drivers/char/rtc.o drivers/net/tulip/tulip.o drivers/scsi/scsi_mod.o drivers/scsi/scsi_transport_spi.o drivers/scsi/sd_mod.o drivers/scsi/sr_mod.o drivers/scsi/st.o drivers/scsi/sym53c8xx_2/sym53c8xx.o fs/exportfs/exportfs.o fs/isofs/isofs.o fs/lockd/lockd.o fs/nfs/nfs.o fs/nfsd/nfsd.o fs/nls/nls_ascii.o fs/nls/nls_base.o fs/nls/nls_cp437.o fs/nls/nls_iso8859-1.o fs/nls/nls_utf8.o fs/smbfs/smbfs.o lib/crc32.o lib/zlib_inflate/zlib_inflate.o net/key/af_key.o net/netlink/netlink_dev.o net/packet/af_packet.o net/sunrpc/sunrpc.o net/unix/unix.o *** Warning: "pci_iounmap" [drivers/net/tulip/tulip.ko] undefined! *** Warning: "pci_iomap" [drivers/net/tulip/tulip.ko] undefined! Now it seems to me that the Makefile.modpost would need to include arch/mips/lib/iomap.o file to correct this issue, but that doesn't seem like the correct thing to do, and I have no clue on how to do that. -- Jim Gifford [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/
Question about initramfs
Question: Initramfs is going to replace initrd, but I haven't seen anyone explain how to copy modules that are built during the build process moved into the initramfs archive. Has somebody done, this or is this still a work in progress? -- ---- Jim Gifford [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/
