Re: dentry cache order 7 is broken
dean gaudet writes:
> also, for order > 7, was the real intention to use a shift of
> (order*2)&31?
No, the whole thing is buggered. How stupid, my fault.
It was the 64-bit platform fascist at work :-)
How does this work for you (against 2.4.x)?
--- fs/dcache.c.~1~ Tue Feb 6 23:00:58 2001
+++ fs/dcache.c Thu Feb 8 00:09:10 2001
@@ -696,7 +696,8 @@
static inline struct list_head * d_hash(struct dentry * parent, unsigned long hash)
{
hash += (unsigned long) parent / L1_CACHE_BYTES;
- hash = hash ^ (hash >> D_HASHBITS) ^ (hash >> D_HASHBITS*2);
+ hash = hash ^ (hash >> D_HASHBITS) ^
+ (hash >> (D_HASHBITS+(D_HASHBITS/2)));
return dentry_hashtable + (hash & D_HASHMASK);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid 2.4.0 kernel
> much-improved block layer of 2.4.x throws larger I/Os at the driver. So, > the developers at Adaptec are busy trying to add support to break large > requests into smaller chunks, and then gather them back together. That sounds like it should be doable at the queuing layer. If not the scsi queue code or ll_rw_blk wants a bit of tweaking - Jens ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PS/2 Mouse/Keyboard conflict and lockup
On Thu, Feb 08, 2001 at 03:35:00AM +0100, Udo A. Steinberg wrote: > > I'm not sure whether this is related to the ominous ps/2 mouse bug > you have been chasing, but this problem is 100% reproducible and > very annoying. > > After upgrading my Asus A7V Bios from 1003 to 1005D, gpm no longer > receives any mouse events and the mouse doesn't work in text > consoles. Once I kill gpm and restart gpm -t ps2 the keyboard > locks up. > > Logging in remotely and looking at dmesg revealed the following: > > keyboard: Timeout - AT keyboard not present? > keyboard: unrecognized scancode (70) - ignored > > If I don't kill and restart gpm, but start X, the mouse works > perfectly, but only in X. > Similiar problems here after my upgrade to 1005D. Linux somehow kills the keyboard if I start the box without a PS/2 mouse connected. I have another machine (these are both 2.4.1) which is a much older K6-233, and it too kills the keyboard if no mouse is present. Keyboard works at LILO prompt but is dead by the time I get to login. GPM doesn't work for me either. P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PS/2 Mouse/Keyboard conflict and lockup
> I'm not sure whether this is related to the ominous ps/2 mouse bug > you have been chasing, but this problem is 100% reproducible and > very annoying. It isnt but it might be related to which 2.2.19pre you are running (if any) > After upgrading my Asus A7V Bios from 1003 to 1005D, gpm no longer > receives any mouse events and the mouse doesn't work in text > consoles. Once I kill gpm and restart gpm -t ps2 the keyboard > locks up. Does downgrading the bios fix it. If so then I suspect you need to talk to the BIOS vendor. You might find that turning off USB legacy keyboard/mouse emulation helps too - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eepro100.c, kernel 2.4.1
On Thu, 8 Feb 2001, Alan Cox wrote: > > It's the printk that gets it wrong, although that's harmless. > > Intel's documentation states that the bug does NOT exist if the > > bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct, > > the printk is wrong. > > So why does it fix the problem for him. His report and your reply don't > make sense viewed together I don't think it fixes *this* bug. However, the bug workaround effectively reinitializes the chip, so it might serve as a generic 'reset and try again' kind of workaround. In that case, we might as well enable it unconditionally... but I don't see it as a good solution. It's a stop-gap measure at best. We need to find out what exactly happens. Until he tells us more about how his boxes "were failing before", there really isn't much we can diagnose. I happen to also have an Intel ISP1100 box here, and I know what's inside -- i82559 C-step chips which definitely don't have this bug. The bug is an i82557-only bug; what makes things confusing is Intel idea of giving multiple chips the same PCI id. They can be identified via the PCI rev: i82557 step A-C: rev 1-3 i82558 step A-B: rev 4-5 i82559 step A-C: rev 6-8 Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eepro100.c, kernel 2.4.1
> It's the printk that gets it wrong, although that's harmless. > Intel's documentation states that the bug does NOT exist if the > bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct, > the printk is wrong. So why does it fix the problem for him. His report and your reply don't make sense viewed together - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eepro100.c, kernel 2.4.1
On Wed, Feb 07, 2001 at 11:23:01PM -0800, Ion Badulescu wrote: > Intel's documentation states that the bug does NOT exist if the > bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct, > the printk is wrong. I wonder if it's not Intel's documentation which is wrong : it seems that the bug showed up also with the network cards used in my boxes, and the patch I proposed seemed to fix that problem. -- Augustin Vidovic http://www.vidovic.org/augustin/ "Nous sommes tous quelque chose de naissance, musicien ou assassin, mais il faut apprendre le maniement de la harpe ou du couteau." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[Patch] aic7xxx update.
This is relative to the 5.2.2 driver already in 2.4.1-ac4 and it fixes the
7880 (and similar) problems. Alan, you'll need to make sure the little patch
I sent earlier is not already applied to your tree since it will conflict with
this patch.
This has been tested on a 7850, 7880, 7890, and 7892 chipset. In general,
this covers two of the four classes of aic7xxx controller. The 7890 and 7892
both fall in the class Ultra2 and if one works the other typically does as
well. The 7850 and 7880 both fall in the class of legacy non-Ultra2
controller and if one works the other usually does. The other two classes are
all 7770 based controllers (EISA/VLB controllers, which I don't have any
machines with these cards to test on any more) and 7895 controllers, which are
half way between a legacy controller and an Ultra2 controller and don't fit in
any class except their own.
So, what this driver really needs is someone with a 7895 and someone with a
VLB/EISA controller to test it out. All the other controllers should be
working reliably at this point.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
diff -U3 -rN scsi.save/aic7xxx/aic7xxx.seq scsi/aic7xxx/aic7xxx.seq
--- scsi.save/aic7xxx/aic7xxx.seq Wed Feb 7 15:07:28 2001
+++ scsi/aic7xxx/aic7xxx.seqThu Feb 8 01:52:38 2001
@@ -291,11 +291,7 @@
mov A, LASTPHASE;
- if ((p->features & AHC_ULTRA2) != 0) {
- testA, ~P_DATAINjz u2_p_data;
- } else {
- testA, ~P_DATAINjz p_data;
- }
+ testA, ~P_DATAINjz p_data;
cmp A,P_COMMAND je p_command;
cmp A,P_MESGOUT je p_mesgout;
cmp A,P_STATUS je p_status;
@@ -336,73 +332,130 @@
/* clear target specific flags */
clr SEQ_FLAGS ret;
- if ((p->features & AHC_ULTRA2) != 0) {
-
-
-u2_data_phase_reinit:
+data_phase_reinit:
/*
* If we re-enter the data phase after going through another phase, the
* STCNT may have been cleared, so restore it from the residual field.
* On Ultra2, we have to put it into the HCNT field because we have to
* drop the data down into the shadow layer via the preload ability.
*/
+ if ((p->features & AHC_ULTRA2) != 0) {
bmovHADDR, SHADDR, 4;
bmovHCNT, SCB_RESID_DCNT, 3;
- jmp u2_data_phase_loop;
-u2_p_data:
+ }
+ if ((p->chip & AHC_CHIPID_MASK) == AHC_AIC7895) {
+ bmovSTCNT, SCB_RESID_DCNT, 3;
+ }
+ if ((p->features & AHC_CMD_CHAN) == 0) {
+ mvi DINDEX, STCNT;
+ mvi SCB_RESID_DCNT call bcopy_3;
+ }
+ jmp data_phase_loop;
+p_data:
+ if ((p->features & AHC_ULTRA2) != 0) {
mvi DMAPARAMS, PRELOADEN|SCSIEN|HDMAEN;
- testLASTPHASE, IOI jnz . + 2;
- or DMAPARAMS, DIRECTION;
- callassert; /*
-* Ensure entering a data
-* phase is okay - seen identify, etc.
-*/
+ } else {
+ mvi DMAPARAMS, WIDEODD|SCSIEN|SDMAEN|HDMAEN|FIFORESET;
+ }
+ testLASTPHASE, IOI jnz . + 2;
+ or DMAPARAMS, DIRECTION;
+ callassert; /*
+* Ensure entering a data
+* phase is okay - seen identify, etc.
+*/
+ if ((p->features & AHC_CMD_CHAN) != 0) {
mvi CCSGADDR, CCSGADDR_MAX;
- testSEQ_FLAGS, DPHASE jnz u2_data_phase_reinit;
- or SEQ_FLAGS, DPHASE; /* we've seen a data phase */
- /*
-* Initialize the DMA address and counter from the SCB.
-* Also set SG_COUNT and SG_NEXT in memory since we cannot
-* modify the values in the SCB itself until we see a
-* save data pointers message.
-*/
+ }
+
+ testSEQ_FLAGS, DPHASE jnz data_phase_reinit;
+ or SEQ_FLAGS, DPHASE; /* we've seen a data phase */
+ /*
+* Initialize the DMA address and counter from the SCB.
+* Also set SG_COUNT and SG_NEXT in memory since we cannot
+* modify the values in the SCB itself until we see a
+* save data pointers message.
+*/
+ if ((p->features & AHC_CMD_CHAN) != 0) {
bmovHADDR, SCB_DATAPTR, 7;
bmovSG_COUNT, SCB_SGCOUNT, 5;
-u2_data_phase_loop:
- /* Guard against overruns */
- testSG_COUNT, 0xff jnz u2_data_phase_inbounds;
+ if ((p->features & AHC_ULTRA2) == 0) {
+ bmov
Re: [PATCH] eepro100.c, kernel 2.4.1
On Thu, 8 Feb 2001 14:53:55 +0900, Augustin Vidovic <[EMAIL PROTECTED]> wrote: > --- linux-2.4.1/drivers/net/eepro100.c Sun Jan 28 03:40:14 2001 > +++ linux-2.4.1-vido1/drivers/net/eepro100.cThu Feb 8 14:08:49 2001 > @@ -815,7 +815,7 @@ > > sp->phy[0] = eeprom[6]; > sp->phy[1] = eeprom[7]; > - sp->rx_bug = (eeprom[3] & 0x03) == 3 ? 0 : 1; > + sp->rx_bug = eeprom[3] & 0x03; > > if (sp->rx_bug) > printk(KERN_INFO " Receiver lock-up workaround activated.\n"); This patch is wrong, please DON'T apply it. It's the printk that gets it wrong, although that's harmless. Intel's documentation states that the bug does NOT exist if the bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct, the printk is wrong. The correct patch for 2.4.1 is attached. 2.2.18 needs something similar, the same patch can be applied with some fuzz. Thanks, Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. --- /usr/src/local/linux-2.4.vanilla/drivers/net/eepro100.c Wed Feb 7 15:45:16 2001 +++ linux-2.4/drivers/net/eepro100.cWed Feb 7 23:07:29 2001 @@ -725,7 +725,7 @@ /* The self-test results must be paragraph aligned. */ volatile s32 *self_test_results; int boguscnt = 16000; /* Timeout for set-test. */ - if (eeprom[3] & 0x03) + if ((eeprom[3] & 0x03) != 0x03) printk(KERN_INFO " Receiver lock-up bug exists -- enabling" " work-around.\n"); printk(KERN_INFO " Board assembly %4.4x%2.2x-%3.3d, Physical" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
dentry cache order 7 is broken
this looks to be a problem going back all the way to at least 2.2. if you've got 512Mb of RAM you end up with a dentry cache of order 7 -- 65536 entries. this results in a D_HASHBITS of 16. if you look at d_hash it contains this code: hash = hash ^ (hash >> D_HASHBITS) ^ (hash >> D_HASHBITS*2); D_HASHBITS*2 = 32, which on an x86 results in a shift of 0. (ia32 is defined to mask a variable shift down to the low 5 bits and use the low 5 bits.) this results in a hash with very little perturbance at all, since the 1st and 3rd terms of the xor are equal and cancel... and the resulting performance is pretty abysmal. i'm getting hash chains with well over 100 entries in them just doing a find on the kernel source tree. if i hard code to order 8 then i get nice well distributed hash chains, 5 entries max. also, for order > 7, was the real intention to use a shift of (order*2)&31? -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
DMA overrun in i810_audio
I'm getting hundreds of thousands of "DMA overrun on send" messages in my kernel logs from the i810_audio driver. Help! I'm running stock Linux 2.4.1. -- syslog -- Feb 7 22:34:27 angeline kernel: Intel 810 + AC97 Audio, version 0.01, 22:21:54 Feb 7 2001 Feb 7 22:34:27 angeline kernel: PCI: Found IRQ 11 for device 00:1f.5 Feb 7 22:34:27 angeline kernel: PCI: Setting latency timer of device 00:1f.5 to 64 Feb 7 22:34:27 angeline kernel: i810: Intel ICH2 found at IO 0xdc00 and 0xd800, IRQ 11 Feb 7 22:34:27 angeline kernel: ac97_codec: AC97 Audio codec, id: 0x414c:0x432f (Unknown) Feb 7 22:34:27 angeline kernel: i810_audio: only 48Khz playback available. ... Feb 7 22:34:57 angeline kernel: DMA overrun on send Feb 7 22:34:57 angeline last message repeated 633 times Feb 7 22:34:57 angeline kernel: on send Feb 7 22:34:57 angeline kernel: DMA overrun on send Feb 7 22:34:58 angeline last message repeated 2740 times ... -- lspci -vvv- 00:00.0 Host bridge: Intel Corporation: Unknown device 1130 (rev 02) Subsystem: ABIT Computer Corp.: Unknown device 0402 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- 00:1e.0 PCI bridge: Intel Corporation 82820 820 (Camino 2) Chipset PCI (rev 01) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- 00:1f.0 ISA bridge: Intel Corporation 82820 820 (Camino 2) Chipset ISA Bridge (ICH2) (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K] Capabilities: [60] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [44] AGP version 2.0 Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2 Command: RQ=0 SBA- AGP- 64bit- FW- Rate= 02:02.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=1M] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 02:03.0 Multimedia audio controller: Aureal Semiconductor Vortex 2 (rev fe) Subsystem: Diamond Multimedia Systems Monster Sound II Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- [disabled] [size=64K] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- -- Michael S. Fischer <[EMAIL PROTECTED]> AKA Otterley _O_ Lead Hacketeer, Dynamine Consulting, Silicon Valley, CA | Phone: +1 650 533 4684 | AIM: IsThisOtterley | ICQ: 4218323 | "From the bricks of shame is built the hope"--Alan Wilder net.goth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On 07 Feb 2001 11:48:16 -0500, Chris Mason wrote: > > > On Wednesday, February 07, 2001 08:38:54 AM -0800 David Rees > <[EMAIL PROTECTED]> wrote: > > > On Wed, Feb 07, 2001 at 10:47:09AM -0500, Chris Mason wrote: > >> > >> Ok, how about we list the known bugs: > >> > >> zeros in log files, apparently only between bytes 2048 and 4096 (not > >> reproduced yet). > > > > Could this bug be related to the reported corruption that people with > > new VIA chipsets have been also reporting on ext2? It seems similar > > because of the location of the corruption: > > > > http://marc.theaimsgroup.com/?l=linux-kernel=98147483712620=2 > > > > Anyway, it can't hurt to ask the bug reported if they're using a > > newer VIA chipset and see if they will upgrade their BIOS which seems > > to fix the problem. > > I'd love to blame this on VIA problems, but people are seeing it on other > chipsets too ;-) > > People who report this aren't seeing general corruption, just zeros in > files of specific sizes. So, it really should be a reiserfs bug. I run Reiser on all but /boot, and it seems to enjoy corrupting my mbox'es randomly. Using the old-style Reiser FS format, 2.4.2-pre1, Evolution, on a CMD640 chipset with the fixes enabled. This also occurs in some log files, but I put it down to syslogd crashing or something. d -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Module usage count - sound
Kernel 2.4.1 I have sound support, OSS and my soundcard (sb) configured as modules If I just play a sound on /dev/dsp, I get the following after the program exits: mixcoac:~> cat /proc/modules sb 2000 0 (autoclean) sb_lib 33504 0 (autoclean) [sb] uart401 6224 0 (autoclean) [sb_lib] sound 55280 0 (autoclean) [sb_lib uart401] soundcore 3664 5 (autoclean) [sb_lib sound] This means that the sound modules are not longer used and thus, removable. Everything OK so far. The problem occurs when /dev/dsp is blocked by the above described process, and another process (say SOX, XMMS and such) attempts to write to the same device. After the two of them finish, the usage count is not reset for some reason, like mixcoac:~> cat /proc/modules sb 2000 1 (autoclean) sb_lib 33504 0 (autoclean) [sb] uart401 6224 0 (autoclean) [sb_lib] sound 55280 0 (autoclean) [sb_lib uart401] soundcore 3664 5 (autoclean) [sb_lib sound] So, the module cannot be removed and stays loaded forever. This problem is 100% reproductable. What's wrong? any ideas? --- Mauricio Martínez Northeastern University[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] eepro100.c, kernel 2.4.1
Patch for drivers/net/eepro100.c in kernel 2.4.1 (and before). For some of the bugged Intel EtherExpress Pro 100 network cards, although the driver diagnoses the receiver lock-up bug, the workaround is not enabled. It appears that the test for the diagnostic and the test for the workaround activation are different. I assumed the diagnostic test is OK and I changed the work-around activation test. I had several Intel ISP1100 boxes with the bug diagnosed, but the workaround not enabled, and after the patch, the workaround is activated and the boxes seem to be alright even under very high network trafic (they were failing before, due to the card bug, I think). Attached is the tarball of the patch, I believe conform to the list FAQ guidelines. Since the patch is only one line, I also include it in the body of this message as plain text. --- linux-2.4.1/drivers/net/eepro100.c Sun Jan 28 03:40:14 2001 +++ linux-2.4.1-vido1/drivers/net/eepro100.cThu Feb 8 14:08:49 2001 @@ -815,7 +815,7 @@ sp->phy[0] = eeprom[6]; sp->phy[1] = eeprom[7]; - sp->rx_bug = (eeprom[3] & 0x03) == 3 ? 0 : 1; + sp->rx_bug = eeprom[3] & 0x03; if (sp->rx_bug) printk(KERN_INFO " Receiver lock-up workaround activated.\n"); I don't understand why the tests for the diagnostic and for the workaround activation were different. Maybe a simple bug, but maybe there was an obscure reason. I someone knows... -- Augustin Vidovic http://www.vidovic.org/augustin/ "Nous sommes tous quelque chose de naissance, musicien ou assassin, mais il faut apprendre le maniement de la harpe ou du couteau." patch-eepro100-vido1.tar
PATCH 2.4.1.ac5: Update ac97 codec ids and codec-specific patches
Alan,
Attached is a patch against 2.4.1-ac5 which syncs the codec id list and
codec-specific init functions with the ones in my CVS tree. Most of
this is a merge from ALSA, and I would put the changes in the category
"needs to go to Linus, but only after a bunch of testing"
Important changes:
* Merge codec-specific initialization code from ALSA and maestro.c
* Sort codec id list by value. Add several new codec ids. None removed
(thrice checked!), of course. Note the Tritech device id from maestro
(0x00FF) seems almost certainly wrong... but since maestro.c didn't mask
it at all, I won't either.
Minor changes:
* Add URLs for Intel AC97 docs and homepage
* Use kernel-standard ARRAY_SIZE macro, not arraysize
* Const-ify a couple tables
* Remove excess whitespace after AC97_REC_PHONE mention
* Change existing sigmatel_init return values from one to zero (not that
the return values are -ever- used, at present)
--
Jeff Garzik | "You see, in this world there's two kinds of
Building 1024 | people, my friend: Those with loaded guns
MandrakeSoft | and those who dig. You dig." --Blondie
Index: linux_2_4/drivers/sound/ac97_codec.c
diff -u linux_2_4/drivers/sound/ac97_codec.c:1.1.1.11
linux_2_4/drivers/sound/ac97_codec.c:1.1.1.11.4.3
--- linux_2_4/drivers/sound/ac97_codec.c:1.1.1.11 Tue Feb 6 21:46:55 2001
+++ linux_2_4/drivers/sound/ac97_codec.cWed Feb 7 21:40:40 2001
@@ -20,6 +20,16 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
+ **
+ *
+ * The Intel Audio Codec '97 specification is available at the Intel
+ * audio homepage: http://developer.intel.com/ial/scalableplatforms/audio/
+ *
+ * The specification itself is currently available at:
+ * ftp://download.intel.com/ial/scalableplatforms/ac97r22.pdf
+ *
+ **
+ *
* History
* v0.4 Mar 15 2000 Ollie Lho
* dual codecs support verified with 4 channels output
@@ -49,42 +59,61 @@
static int ac97_init_mixer(struct ac97_codec *codec);
-static int sigmatel_init(struct ac97_codec *codec);
+static int wolfson_init(struct ac97_codec * codec);
+static int tritech_init(struct ac97_codec * codec);
+static int tritech_maestro_init(struct ac97_codec * codec);
+static int sigmatel_9708_init(struct ac97_codec *codec);
+static int sigmatel_9721_init(struct ac97_codec *codec);
+static int sigmatel_9744_init(struct ac97_codec *codec);
static int enable_eapd(struct ac97_codec *codec);
-
-#define arraysize(x) (sizeof(x)/sizeof((x)[0]))
-static struct {
- unsigned int id;
+/* sorted by vendor/device id */
+static const struct {
+ u32 id;
char *name;
int (*init) (struct ac97_codec *codec);
} ac97_codec_ids[] = {
- {0x414B4D00, "Asahi Kasei AK4540 rev 0", NULL},
- {0x414B4D01, "Asahi Kasei AK4540 rev 1", NULL},
- {0x41445340, "Analog Devices AD1881" , NULL},
- {0x41445360, "Analog Devices AD1885" , enable_eapd},
- {0x43525900, "Cirrus Logic CS4297", enable_eapd},
- {0x43525903, "Cirrus Logic CS4297" , enable_eapd},
- {0x43525913, "Cirrus Logic CS4297A" , enable_eapd},
- {0x43525923, "Cirrus Logic CS4298", NULL},
- {0x4352592B, "Cirrus Logic CS4294", NULL},
- {0x4352592D, "Cirrus Logic CS4294", NULL},
- {0x43525931, "Cirrus Logic CS4299", NULL},
- {0x43525934, "Cirrus Logic CS4299", NULL},
- {0x4e534331, "National Semiconductor LM4549" , NULL},
- {0x53494c22, "Silicon Laboratory Si3036" , NULL},
- {0x53494c23, "Silicon Laboratory Si3038" , NULL},
- {0x83847600, "SigmaTel STAC" , NULL},
+ {0x41445303, "Analog Devices AD1819", NULL},
+ {0x41445340, "Analog Devices AD1881", NULL},
+ {0x41445348, "Analog Devices AD1881A", NULL},
+ {0x41445460, "Analog Devices AD1885", enable_eapd},
+ {0x414B4D00, "Asahi Kasei AK4540", NULL},
+ {0x414B4D01, "Asahi Kasei AK4542", NULL},
+ {0x414B4D02, "Asahi Kasei AK4543", NULL},
+ {0x414C4710, "ALC200/200P", NULL},
+ {0x43525900, "Cirrus Logic CS4297", enable_eapd},
+ {0x43525903, "Cirrus Logic CS4297", enable_eapd},
+ {0x43525913, "Cirrus Logic CS4297A rev A", enable_eapd},
+ {0x43525914, "Cirrus Logic CS4297A rev B", NULL},
+ {0x43525923, "Cirrus Logic CS4298", NULL},
+ {0x4352592B, "Cirrus Logic CS4294", NULL},
+ {0x4352592D, "Cirrus Logic CS4294", NULL},
+ {0x43525931, "Cirrus Logic CS4299 rev A", NULL},
+ {0x43525933, "Cirrus Logic CS4299 rev C", NULL},
+ {0x43525934, "Cirrus Logic CS4299 rev D", NULL},
+ {0x45838308, "ESS Allegro ES1988", NULL},
+ {0x49434511, "ICE1232", NULL}, /* I hope --jk
Re: [PATCH] Re: UP APIC reenabling vs. cpu type detection ordering
Mikael Pettersson wrote: > > H. Peter Anvin wrote: > > >"Maciej W. Rozycki" wrote: > >... > >> It might be viable just to delete the test altogether, though and just > >> trap #GP(0) on the MSR access. For the sake of simplicity. If a problem > >> with a system ever arizes, we may handle it then. > >> > >> Note that we still have to choose appropriate vendor-specific PeMo > >> handling and an event for the NMI watchdog anyway. > > > >Right... if that is the case then it seems reasonable. > > No, poking into MSRs not explicitly defined on the current CPU is > inherently unsafe. I have several x86 CPU data sheets here in front > of me which say the same thing: "Don't write to undocumented MSRs." > You cannot assume that every single x86 out there stays clear of > all Intel-defined MSRs. Intel has also expanded this set over time: > older designs may not even have known about the APIC_BASE MSR. > You misread me. "In that case it seems reasonable to do vendor-specific detection." -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Promise, DMA and RAID5 problems running 2.4.1
Petr Vandrovec wrote: > It is known bug which I reported to Andre already. Open > drivers/ide/ide.c in favorite text editor, and replace strange > body of ide_delay_50ms() with simple mdelay(50). Promise driver > invokes ide_delay_50ms with interrupts disabled, so it freezes > here forever. If you have NMI watchdog, you'll get nice oopses. > > As for DMA failure itself, I have no idea what is wrong in your > case, but I found that mine Promise works with Linux only iff there > is master on each channel, slave alone does not work. And I did not > tried master+slave together. > Petr Vandrovec > [EMAIL PROTECTED] Ok, I changed ide.c and stopped getting the freeze, but bad DMA status errors were still showing up. Then I connected all the drives as masters (2x ATA-100, 2x ATA-66) and havent gotten anything yet. Buffered disk reads are still about 36.50 MB/sec on the raid5 device, so its fast enough for what I need. Next step is to see how well Reiserfs works here. Thank you everyone who has helped. A.Sajjad Zaidi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-ac5 - The loopback hang saga continues (not me ?)
The same here. I have had no problems with either 2.4.0 or 2.4.1, and I don't even have the Axboe's patch applied. Which makes me wonder where is the problem. I am also using encryption (patch-int-2.4.0.3, idea cipher) and util-linux-2.10o. The container file is not as big, only 256MB with 65MB of data, and the largest file is ~30MB. I had to convert from the blowfish and used dump|restore. There were no problems whatsoever. Dejan On Thu, Feb 08, 2001 at 03:48:34AM +0100, Pascal Brisset wrote: > FYI following hints from the linux-crypto mailing-list archives, I am > using the following configuration : > > linux-2.4.0 > patch-int-2.4.0.3 > http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-1.gz > http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-bdev-inc-1.gz > util-linux-2.10o > Documentation/crypto/util-linux-2.10o.patch > > I setup an encrypted 2097152000 byte loopback partition and moved > 800MB of data there, including a 90MB file. > > My only problems are: > - rc.d/init.d/S01reboot sometimes fails to unmount partitions with > loop files on them (this already happened with 2.2.17). > - losetup after losetup -d sometimes fails. > > -- Pascal > > > Linux-crypto: cryptography in and on the Linux system > Archive: http://mail.nl.linux.org/linux-crypto/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: UP APIC reenabling vs. cpu type detection ordering
H. Peter Anvin wrote:
>"Maciej W. Rozycki" wrote:
>...
>> It might be viable just to delete the test altogether, though and just
>> trap #GP(0) on the MSR access. For the sake of simplicity. If a problem
>> with a system ever arizes, we may handle it then.
>>
>> Note that we still have to choose appropriate vendor-specific PeMo
>> handling and an event for the NMI watchdog anyway.
>>
>
>Right... if that is the case then it seems reasonable.
No, poking into MSRs not explicitly defined on the current CPU is
inherently unsafe. I have several x86 CPU data sheets here in front
of me which say the same thing: "Don't write to undocumented MSRs."
You cannot assume that every single x86 out there stays clear of
all Intel-defined MSRs. Intel has also expanded this set over time:
older designs may not even have known about the APIC_BASE MSR.
No, the problem we're facing here is a phase ordering issue.
There are actually several bugs lurking here:
1. identify_cpu() (and more importantly get_cpu_vendor()) is called
very late (init/main.c's check_bugs()), while we obviously need
that info much earlier. Thus, boot_cpu_data.x86_vendor is still
uninitialised (zero by .bss) when we read it for the purpose of
setting up the local APIC.
2. include/asm-i386/processor.h #defines X86_VENDOR_INTEL as 0.
Thus, we may accidentally believe that the CPU is an Intel, if
we read x86_vendor before identify_cpu() had done its deed.
This explains why Petr Vandrovec's testing on K7 succeeded (the
APIC-enabling code mistook his K7 for a P6). Change Intel's
vendor id to something non-zero and you'll see that on
UP P6 the local APIC doesn't get initialised.
3. init/main.c calls time_init() before check_bugs() and thus
identify_cpu(). time_init() calls dodgy_tsc() which calls
get_cpu_vendor(). However, get_cpu_vendor() only works on
CPUID-enabled CPUs, so dodgy_tsc()'s call to init_cyrix()
isn't guaranteed to happen. (init_cyrix() will be called later,
but that may be too late.)
Also, time_init() checks cpu_has_tsc, but since this is before
identify_cpu() has done its thing, the capabilities are still
the raw ones from head.S's CPUID calls.
4. The cpu detection code rewrite in 2.4.0-test
introduced a bug. The capabilities field was expanded from
one to four words, which changed the starting offset of
the vendor_id string. But the offsets in head.S weren't
updated, causing head.S's initial vendor_id data to be stored
in the wrong place. This hasn't been noticed yet since
identify_cpu() does this work again correctly, but it does
mean that calling get_cpu_vendor() before identify_cpu()
doesn't work any more.
Below is a patch against 2.4.1-ac5 which fixes CPU detection
as far as the UP_APIC stuff is concerned. I had to add a
get_cpu_vendor() call to detect_init_APIC(), so that our
detection code gets a chance to work. I also fixed the field
ordering and offsets in processor.h and head.S. The resulting
kernel works ok on my UP P6.
(Petr: can you check that it still works on your K7?)
Ideally, identify_cpu() should be run before init_apic_mappings(),
but my attempts to do so has so far had some weird side-effects
(lost interrupts, incorrect bogomips, apparently stuck watchdog,
and keyboard timeouts), so I won't touch that stuff.
/Mikael
--- linux-2.4.1-ac5/arch/i386/kernel/apic.c.~1~ Thu Feb 8 02:01:39 2001
+++ linux-2.4.1-ac5/arch/i386/kernel/apic.c Thu Feb 8 05:28:21 2001
@@ -388,21 +388,23 @@
{
u32 h, l, dummy, features;
- if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
- printk("No APIC support for non-Intel processors.\n");
- return -1;
- }
+ get_cpu_vendor(_cpu_data);
- if (boot_cpu_data.x86 < 5) {
- printk("No local APIC on pre-Pentium Intel processors.\n");
- return -1;
+ switch (boot_cpu_data.x86_vendor) {
+ case X86_VENDOR_AMD:
+ if (boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model > 1)
+ break;
+ goto no_apic;
+ case X86_VENDOR_INTEL:
+ if (boot_cpu_data.x86 == 6 ||
+ (boot_cpu_data.x86 == 5 && cpu_has_apic))
+ break;
+ goto no_apic;
+ default:
+ goto no_apic;
}
if (!cpu_has_apic) {
- if (boot_cpu_data.x86 == 5) {
- printk("APIC turned off by hardware.\n");
- return -1;
- }
/*
* Some BIOSes disable the local APIC in the
* APIC_BASE MSR. This can only be done in
@@ -434,6 +436,10 @@
printk("Found and enabled local APIC!\n");
return 0;
+
+no_apic:
+ printk("No local APIC present or hardware disabled\n");
+ return -1;
}
void __init init_apic_mappings(void)
--- linux-2.4.1-ac5/arch/i386/kernel/head.S.~1~ Tue Dec 12
[PATCH] starfire driver for 2.2.x
Hi Alan, As promised, here is the same driver ported to 2.2.x. I used the definitions in kcomp.h, as well as the excellent stuff from emu10k1's wrapper. The patch was generated agains 2.2.18, but I checked that it applies cleanly to 2.2.19pre8. BTW, would you consider a patch adding more stuff to kcomp.h? Thanks, Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - diff -urNX diff_kernel_excludes /usr/src/local/linux-2.2.18-vanilla/Documentation/Configure.help linux-2.2.18/Documentation/Configure.help --- /usr/src/local/linux-2.2.18-vanilla/Documentation/Configure.helpSun Dec 10 16:49:41 2000 +++ linux-2.2.18/Documentation/Configure.help Wed Feb 7 19:40:42 2001 @@ -6238,6 +6238,18 @@ If you don't have this card, of course say N. +Adaptec Starfire support (EXPERIMENTAL) +CONFIG_ADAPTEC_STARFIRE + Say Y here if you have an Adaptec Starfire (or DuraLAN) PCI network + adapter. The DuraLAN chip is used on the 64 bit PCI boards from + Adaptec e.g. the ANA-6922A. The older 32 bit boards use the tulip + driver. + + If you want to compile this driver as a module ( = code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read Documentation/modules.txt. This is recommended. + The module will be called starfire.o. + Alteon AceNIC/3Com 3C985/NetGear GA620 Gigabit support CONFIG_ACENIC Say Y here if you have an Alteon AceNIC or 3Com 3C985 PCI Gigabit diff -urNX diff_kernel_excludes /usr/src/local/linux-2.2.18-vanilla/MAINTAINERS linux-2.2.18/MAINTAINERS --- /usr/src/local/linux-2.2.18-vanilla/MAINTAINERS Sun Dec 10 16:49:41 2000 +++ linux-2.2.18/MAINTAINERSWed Feb 7 19:34:25 2001 @@ -916,6 +916,11 @@ W: http://www.stallion.com S: Supported +STARFIRE/DURALAN NETWORK DRIVER +P: Ion Badulescu +M: [EMAIL PROTECTED] +S: Maintained + STARMODE RADIO IP (STRIP) PROTOCOL DRIVER W: http://mosquitonet.Stanford.EDU/strip.html S: Unsupported ? diff -urNX diff_kernel_excludes /usr/src/local/linux-2.2.18-vanilla/drivers/net/Config.in linux-2.2.18/drivers/net/Config.in --- /usr/src/local/linux-2.2.18-vanilla/drivers/net/Config.in Sun Dec 10 16:49:42 2000 +++ linux-2.2.18/drivers/net/Config.in Wed Feb 7 17:56:02 2001 @@ -132,6 +132,7 @@ if [ "$CONFIG_NET_EISA" = "y" ]; then tristate 'AMD PCnet32 (VLB and PCI) support' CONFIG_PCNET32 if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then + tristate 'Adaptec Starfire support (EXPERIMENTAL)' CONFIG_ADAPTEC_STARFIRE tristate 'Ansel Communications EISA 3200 support (EXPERIMENTAL)' CONFIG_AC3200 fi tristate 'Apricot Xen-II on board Ethernet' CONFIG_APRICOT diff -urNX diff_kernel_excludes /usr/src/local/linux-2.2.18-vanilla/drivers/net/Makefile linux-2.2.18/drivers/net/Makefile --- /usr/src/local/linux-2.2.18-vanilla/drivers/net/MakefileSun Dec 10 16:49:42 2000 +++ linux-2.2.18/drivers/net/Makefile Wed Feb 7 17:57:21 2001 @@ -742,6 +742,14 @@ endif endif +ifeq ($(CONFIG_ADAPTEC_STARFIRE),y) +L_OBJS += starfire.o +else + ifeq ($(CONFIG_ADAPTEC_STARFIRE),m) + M_OBJS += starfire.o + endif +endif + ifeq ($(CONFIG_AC3200),y) L_OBJS += ac3200.o CONFIG_8390_BUILTIN = y diff -urNX diff_kernel_excludes /usr/src/local/linux-2.2.18-vanilla/drivers/net/starfire.c linux-2.2.18/drivers/net/starfire.c --- /usr/src/local/linux-2.2.18-vanilla/drivers/net/starfire.c Wed Dec 31 16:00:00 1969 +++ linux-2.2.18/drivers/net/starfire.c Wed Feb 7 19:33:56 2001 @@ -0,0 +1,1903 @@ +/* starfire.c: Linux device driver for the Adaptec Starfire network adapter. */ +/* + Written 1998-2000 by Donald Becker. + + This software may be used and distributed according to the terms of + the GNU General Public License (GPL), incorporated herein by reference. + Drivers based on or derived from this code fall under the GPL and must + retain the authorship, copyright and license notice. This file is not + a complete program and may only be used when the entire operating + system is licensed under the GPL. + + The author may be reached as [EMAIL PROTECTED], or C/O + Scyld Computing Corporation + 410 Severn Ave., Suite 210 + Annapolis MD 21403 + + Support and updates available at + http://www.scyld.com/network/starfire.html + + --- + + Linux kernel-specific changes: + + LK1.1.1 (jgarzik): + - Use PCI driver interface + - Fix MOD_xxx races + - softnet fixups + + LK1.1.2 (jgarzik): + - Merge Becker version 0.15 + + LK1.1.3 (Andrew Morton) + - Timer cleanups + + LK1.1.4 (jgarzik): + - Merge Becker version 1.03 + + LK1.2.1 (Ion Badulescu <[EMAIL PROTECTED]>) + - Support hardware Rx/Tx checksumming + - Use the GFP firmware
Re: reiserfs - problems mounting after power outage (FIXED)
Problem solved. I downloaded the latest reiserfs_utils 3.6.25 from namesys.com and built and ran reiserfsck against the partition with the --rebuild-tree option. It completed successfully and I was able to mount the partition without any further problems. I'll build and install a 2.4.1 kernel sometime tomorrow and get it running on that machine to address any further issues. many thanks for the tips & suggestions Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] starfire reads irq before pci_enable_device.
Manfred Spraul wrote: > > Jeff Garzik wrote: > > > > + SET_MODULE_OWNER(dev); > > > > irq = pdev->irq; > > > > One question: > The code copies 'pdev->irq' into 'dev->irq'. > > Is that required, who need 'dev->irq'? > > > retval = request_irq(dev->irq, _handler, SA_SHIRQ, dev->name, dev); > > Can't the driver use? > retval = request_irq(np->pci_dev->irq) Sure it can. A PCI driver can completely ignore dev->irq, if it so desires. However... Setting dev->irq is really a courtesy, because while the net core code doesn't use it at all, it is reported to userspace such as ifconfig. And because the netdev setup code could potentially assign a value to dev->irq on its own, if the driver does -not- set dev->irq, the value reported to userspace might incorrect instead of just being zero. [side note - ifconfig only obtains the lower 16 bits of the dev->base_addr value, grump grump] Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TCP_NOPUSH on FreeBSD, TCP_CORK on Linux (was: Is sendfile all that
Dan Kegel <[EMAIL PROTECTED]> wrote: > >Tony, are people using the TCP_NOPUSH define as a way to detect >the presence of T/TCP support? No, MSG_EOF is the right way to do that. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] FAIR ISLE: WESTERLY VEERING NORTHERLY 4 OR 5. WINTRY SHOWERS. MAINLY GOOD. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remaining net/ pci_enable_device cleanups.
[EMAIL PROTECTED] wrote:
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/defxx.c
>linux-dj/drivers/net/defxx.c
> --- linux/drivers/net/defxx.c Wed Feb 7 21:55:56 2001
> +++ linux-dj/drivers/net/defxx.cWed Feb 7 22:34:27 2001
applied
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/dgrs.c
>linux-dj/drivers/net/dgrs.c
> --- linux/drivers/net/dgrs.cWed Feb 7 21:55:56 2001
> +++ linux-dj/drivers/net/dgrs.c Wed Feb 7 22:17:37 2001
applied
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/dmfe.c
>linux-dj/drivers/net/dmfe.c
> --- linux/drivers/net/dmfe.cWed Feb 7 21:55:56 2001
> +++ linux-dj/drivers/net/dmfe.c Wed Feb 7 22:18:18 2001
> @@ -356,6 +356,11 @@
>
> DMFE_DBUG(0, "dmfe_probe()", 0);
>
> + /* Enable Master/IO access, Disable memory access */
> + if (pci_enable_device(pdev))
> + goto err_out;
> + pci_set_master(pdev);
not applied -- used this code instead:
/* Enable Master/IO access, Disable memory access */
i = pci_enable_device(pdev);
if (i) return i;
pci_set_master(pdev);
pci_read_config_word(pdev, PCI_COMMAND, _command);
pci_comand &= ~PCI_COMMAND_MEM;
pci_write_config_word(pdev, PCI_COMMAND, pci_command);
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/eepro100.c
>linux-dj/drivers/net/eepro100.c
> --- linux/drivers/net/eepro100.cWed Feb 7 21:55:56 2001
> +++ linux-dj/drivers/net/eepro100.c Wed Feb 7 22:00:35 2001
> @@ -557,6 +557,17 @@
> if (speedo_debug > 0 && did_version++ == 0)
> printk(version);
>
> + /* save power state b4 pci_enable_device overwrites it */
> + pm = pci_find_capability(pdev, PCI_CAP_ID_PM);
> + if (pm) {
> + u16 pwr_command;
> + pci_read_config_word(pdev, pm + PCI_PM_CTRL, _command);
> + acpi_idle_state = pwr_command & PCI_PM_CTRL_STATE_MASK;
> + }
> +
> + if (pci_enable_device(pdev))
> + goto err_out_none;
applied then modified: -ENODEV is rarely a descriptive return code on
pci_enable_device failure
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/epic100.c
>linux-dj/drivers/net/epic100.c
> --- linux/drivers/net/epic100.c Wed Feb 7 21:55:56 2001
> +++ linux-dj/drivers/net/epic100.c Wed Feb 7 22:15:22 2001
applied
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/natsemi.c
>linux-dj/drivers/net/natsemi.c
> --- linux/drivers/net/natsemi.c Wed Feb 7 21:55:56 2001
> +++ linux-dj/drivers/net/natsemi.c Wed Feb 7 22:03:05 2001
already applied/fixed
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/pcnet32.c
>linux-dj/drivers/net/pcnet32.c
> --- linux/drivers/net/pcnet32.c Wed Feb 7 21:55:57 2001
> +++ linux-dj/drivers/net/pcnet32.c Wed Feb 7 22:00:35 2001
> @@ -482,7 +482,12 @@
>
> printk(KERN_INFO "pcnet32_probe_pci: found device %#08x.%#08x\n", ent->vendor,
>ent->device);
>
> -ioaddr = pci_resource_start (pdev, 0);
> + if ((err = pci_enable_device(pdev)) < 0) {
> + printk(KERN_ERR "pcnet32.c: failed to enable device -- err=%d\n", err);
> + return err;
> + }
> +
> + ioaddr = pci_resource_start (pdev, 0);
applied, then fixed up the fubar'd indentation..
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/rcpci45.c
>linux-dj/drivers/net/rcpci45.c
> --- linux/drivers/net/rcpci45.c Wed Feb 7 21:55:57 2001
> +++ linux-dj/drivers/net/rcpci45.c Wed Feb 7 22:13:56 2001
applied
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/rtl8129.c
>linux-dj/drivers/net/rtl8129.c
> --- linux/drivers/net/rtl8129.c Wed Feb 7 21:55:57 2001
> +++ linux-dj/drivers/net/rtl8129.c Wed Feb 7 22:08:47 2001
not applied -- already met its demise in my tree :)
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/sis900.c
>linux-dj/drivers/net/sis900.c
> --- linux/drivers/net/sis900.c Wed Feb 7 21:55:57 2001
> +++ linux-dj/drivers/net/sis900.c Wed Feb 7 22:08:04 2001
applied
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/sundance.c
>linux-dj/drivers/net/sundance.c
> --- linux/drivers/net/sundance.cMon Dec 11 21:38:29 2000
> +++ linux-dj/drivers/net/sundance.c Wed Feb 7 22:03:56 2001
applied
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/winbond-840.c
>linux-dj/drivers/net/winbond-840.c
> --- linux/drivers/net/winbond-840.c Wed Feb 7 21:56:00 2001
> +++ linux-dj/drivers/net/winbond-840.c Wed Feb 7 22:05:21 2001
applied
--
Jeff Garzik | "You see, in this world there's two kinds of
Building 1024 | people, my friend: Those with loaded guns
MandrakeSoft | and those who dig. You dig." --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
2.4.2-pre1: kernel oops during unmount
2.4.2-pre1 + ReiserFS 3.6.25 (included) + loop-4 ksymoops 2.3.7 on i686 2.4.2-pre1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.2-pre1/ (default) -m /boot/System.map (specified) Unable to handle kernel NULL pointer dereference at virtual address c0143023 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00013206 eax: c14d3e00 ebx: c81051c0 ecx: cfa3f000 edx: cf7f36c0 esi: edi: ebp: ce469f3c esp: ce469f04 ds: 0018 es: 0018 ss: 0018 Process umount (pid: 9117, stackpage=ce469000) Stack: c14d3e00 ce469f3c ce469f3c c025d5b8 c01430d5 c025bf1c c14d3e00 ce469f3c c14d3e00 cf9b32c0 c025d580 c025d5b8 ce469f3c ce469f3c c01354d3 c14d3e00 c14c0440 c14d3e00 b53c c0134839 c01358d1 Call Trace: [] [] [] [] [] [] [] [] Code: 8b 3f 3b 74 24 1c 74 65 8d 5e f8 8b 44 24 20 39 83 8c 00 00 >>EIP; c0143023<= Trace; c01430d5 Trace; c01354d3 Trace; c0134839 Trace; c01358d1 Trace; c01359aa Trace; c0122fcb Trace; c01359eb Trace; c0108fe7 Code; c0143023 <_EIP>: Code; c0143023<= 0: 8b 3f mov(%edi),%edi <= Code; c0143025 2: 3b 74 24 1c cmp0x1c(%esp,1),%esi Code; c0143029 6: 74 65 je 6d <_EIP+0x6d> c0143090 Code; c014302b 8: 8d 5e f8 lea0xfff8(%esi),%ebx Code; c014302e b: 8b 44 24 20 mov0x20(%esp,1),%eax Code; c0143032 f: 39 83 8c 00 00 00 cmp%eax,0x8c(%ebx) -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid 2.4.0 kernel
On Wed, Feb 07 2001, [EMAIL PROTECTED] wrote: > > I haven't seen this driver, but if it uses the SCSI layer instead > > of being a "pure" block driver then I can see a slight problem > > in that currently only understand max sg entry limits and not > > total request sizes. I would rather fix this limitation then, and > > would also be interested to know if any of the (older) SCSI drivers > > have such limitations too. > > Yes, it's a SCSI driver, not a block driver. Adaptec thought it prudent to > try to fix this in their driver rather than try to change the SCSI layer in > 2.4.x just now. They expected it would be more difficult getting such a > change through validation and into the kernel in a timely manner. The changes are going to be really small and obvious. Which I bet the driver changes won't :-). And as I said, if other drivers have this limitation too then we need to do it anyway. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] PCI-SCI Drivers v1.2-1 Released
Linux Kernel, The PCI-SCI Drivers for the Dolphin Scalable Coherent Interface v1.2-1 has posted at vger.timpanogas.org:/sci/pci-sci-1.2-1. This release corrects several hardware related bugs, and corrects several previously reported build and performance problems related to the RedHat 7.1 Fischer Release. These drivers are released under the GNU public license, and are freely downloadable and re-distributable. These drivers are provided in both .tar.gz and RPM formats. Please direct any questions, bug reports, or comments to either [EMAIL PROTECTED] or [EMAIL PROTECTED] Analysis of performance problems related to the gcc 2.96 compiler on the fischer release indicate that there are some problems with mixing powertools RPMs and egcs compatibility modules on a base release that may result in poor code generation. We wiped the entire RedHat 7.1 Fischer system, and performed a clean install with just the base compiler, and none of the compatibilty tools, and the performance numbers for sci_copy (scibench2) came back up to expected levels for the target system. Since SCI allows userspace -> userspace copying across systems, the problem code was being generated in user space and not kernel. We did not attempt to track any further than installing just the base RedHat 7.1 Fischer release -- the numbers were acceptable for the target system. The performance numbers attached to this release wer run on a PIII Intel System using the 440BX Bridge chipset on a system with a maximum PCI throughput of 87 MB/S. NOTES: *Fixed concurrent DMA and PIO error detection bug for D330 adapters *Linux:Fixed problems to allocate ATT tables for large SCI memsizes. *Linux:Added proper handling of driver unload if driver load fails. *Linux:fixed sleepOk flags to allow __GFP_WAIT flags to be passed to __get_free_pages() to correct alloc failures in Linux when memory gets fragmented. *Linux:fixed ASSERT() macros for modversioned IRM builds on Linux systems. *Added SIMD/MMX support / Windows 2000. Not ported to Linux yet. (coming to Linux soon) *Added proper handling of SCIInitialize() failiure in all examples/demos. *UNIX: Fixed SCIMapLocal/RemoteSegment() bug when mapping to a segment offset. *Linux:added code to /src/adm/MAKE/CONFIG-LINUX to append the -D__SMP__ build option when SMP support is detected in kernel source tree to correct SMP build errors on 2.2/2.4 kernels JVM Please note: call to SCIInitialize/SCITerminate will be mandatory from next version of SISCI. SISCI applications should update code ASAP. SCIInitialize() must be the first SISCI function used. SCITerminate() should be the last one used. /opt/DIS/bin/scibench2 compiled Feb 7 2001 : 19:15:19 Test parameters for client Local nodeId: 4 Remote nodeId : 8 Local adapter no. : 0 Segment size: 65536 Loops to execute: 1 ILoops to execute : 1000 Key Offset : 0 Source buffer type : User malloc Memcopy mode: scicopy Direction : PUSH Error Check : No SISCI API version : SISCI API version 1.10.0 ( Feb 7 2001 ) Adapter type: D320 Serial number : 100963 Hostbridge : 440BX IO Bus frequency: 33 MHz SCI Link frequency : 100 MHz B-Link frequency: 66 MHz Connect to remote segment (id=0x80400) connected Remote segment (id=0x80400) is connected. Remote segment (id=0x80400) is mapped to user space. -- Starting the data transfer -- Segment Size: Average Transfer Time: Throughput: 4 2.14 us 1.87 MBytes/s 8 2.22 us 3.61 MBytes/s 162.53 us 6.32 MBytes/s 324.25 us 7.53 MBytes/s 643.42 us18.70 MBytes/s 128 6.07 us21.09 MBytes/s 256 6.34 us40.40 MBytes/s 512 6.46 us79.28 MBytes/s 1024 12.57 us81.46 MBytes/s 2048 29.53 us69.36 MBytes/s 4096 50.59 us80.96 MBytes/s 8192100.85 us81.23 MBytes/s 16384 208.46 us78.60 MBytes/s 32768 404.03 us81.10 MBytes/s 65536 808.05 us81.10 MBytes/s Node 4 triggering interrupt Interrupt message sent to remote node The remote segment is unmapped The segment is disconnected - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
> I haven't seen this driver, but if it uses the SCSI layer instead > of being a "pure" block driver then I can see a slight problem > in that currently only understand max sg entry limits and not > total request sizes. I would rather fix this limitation then, and > would also be interested to know if any of the (older) SCSI drivers > have such limitations too. Yes, it's a SCSI driver, not a block driver. Adaptec thought it prudent to try to fix this in their driver rather than try to change the SCSI layer in 2.4.x just now. They expected it would be more difficult getting such a change through validation and into the kernel in a timely manner. -Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid 2.4.0 kernel
On Wed, Feb 07 2001, [EMAIL PROTECTED] wrote: > Adaptec is still working on it. Basically (and as Jason discovered), the > driver and firmware can't handle single I/O requests larger than 64KB. Even > when scatter/gathered, if the total is >64KB, it chokes. This was just fine > for 2.2.x (no one has ever run into this problem there), but the > much-improved block layer of 2.4.x throws larger I/Os at the driver. So, > the developers at Adaptec are busy trying to add support to break large > requests into smaller chunks, and then gather them back together. Poor hardware, even IDE does better than this with scatter gather. However, that's not why I'm replying. A driver should never have to deal with bigger requests than it can handle. This just leads to duplicated code in the block drivers and someone getting it wrong (in fact, 2.4.1-pre showed bugs in the cpqarray driver doing this for sg). The block layer is flexible enough to stop merging beyond the low level drivers limit. I haven't seen this driver, but if it uses the SCSI layer instead of being a "pure" block driver then I can see a slight problem in that currently only understand max sg entry limits and not total request sizes. I would rather fix this limitation then, and would also be interested to know if any of the (older) SCSI drivers have such limitations too. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RedHat kernel RPM 2.2.16
AH HA! Thanks! - Original Message - From: "David Woodhouse" <[EMAIL PROTECTED]> To: "Jim Roland" <[EMAIL PROTECTED]> Cc: "J. Dow" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, February 07, 2001 2:37 AM Subject: Re: RedHat kernel RPM 2.2.16 > > [EMAIL PROTECTED] said: > > FWIW, the rpm -i did unpack the kernel to the /usr/src/redhat/SOURCES > > directory, however, I had to manually untar the sources to /usr/src to > > get my kernel, move over the appropriate .config file, and manually > > run the patches to patch the sources. Forcing RPM to be very > > talkative (via -vv) gave me a bunch of "action unknown" errors, and > > the rpm's install scripts did not execute. This occurs on an RH7 > > system as well. Seems to be something wrong with RH's kernel rpm? > > Install the kernel-source binary RPM, which contains the build tree already > extracted and set up as you desire, instead of the master SRPM which > contains build instructions for all the kernel versions. > > i.e. kernel-source-2.2.16-3.i386.rpm, not kernel-2.2.16-3.src.rpm > > -- > dwmw2 > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
> I see in the archives of this mailing list that someone was > working on the > aacraid driver for the 2.4 kernel however that post was > almost 2 months old. Adaptec is still working on it. Basically (and as Jason discovered), the driver and firmware can't handle single I/O requests larger than 64KB. Even when scatter/gathered, if the total is >64KB, it chokes. This was just fine for 2.2.x (no one has ever run into this problem there), but the much-improved block layer of 2.4.x throws larger I/Os at the driver. So, the developers at Adaptec are busy trying to add support to break large requests into smaller chunks, and then gather them back together. > I know Alan Cox denied inclusion of the driver due to the > poor nature it was > written for the 2.2 tree. Every post that I have seen so far > has just said > that Adaptec is working on it. So, there are three objectives: 1) Get and maintain a working 2.2.x driver. Yes, Alan Cox doesn't want to merge this into the stock kernel, so until then, it's available separately, and several distributions have picked it up, such as Red Hat Linux 7. 2) Get a working 2.4.x driver. Dell and Adaptec both believe this is critical. Again, we don't expect this driver to make it into the 2.4.x stock kernel, it'll be made available separately to those who want it. This is where development time is being spent today. The best I can say here is "we hope to have something soon". 3) Develop an aacraid driver for both 2.2.x and 2.4.x that will be accepted into the stock kernels. For this to happen, Adaptec engineers will be re-writing the driver from the ground up as a Linux driver. Due to schedule constraints (wanting 2.4.x support sooner rather than later), and because we didn't expect the 64K issue, this has been delayed until 2) is finished. Hopefully the 64K limit will be eradicated then too. I've made a web page http://domsch.com/linux on which I've posted all the 2.2.x aacraid patches, and where I'll post a 2.4.x patch when it's available. I've also created an announcements-only mailing list http://domsch.com/mailman/listinfo/linux-aacraid-announce which you may subscribe to and receive notices of new driver availability. I've created a developers list http://domsch.com/mailman/listinfo/linux-aacraid-devel for discussion of the driver if you wish to contribute. Both the web page and mailing lists will likely be moved to a Dell.com server in the near future. I hope this helps clarify the situation. Thank you for your interest and continued patience. -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs - problems mounting after power outage
Quoting Andre Hedrick <[EMAIL PROTECTED]>: > > Dream on if you think "Writeback cacheing is disabled" on all systems > bye > default. If you did not wack it. It is not off. > Yeah, I know, Andre. I turned it off in the 3ware card's BIOS setup. I'm not completely idiotic, just dumb enough to not have ordered a UPS for this box sooner. One is on the way now though. :-) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oopses in 2.4.1 (lots of them)
On Wed, 7 Feb 2001, Alan Cox wrote: > > am not sure how to eliminate or confirm this. Recently I added some RAM > > (256->384) and decided to get rid of swap. This seemed to have destabilized > > the system, although nothing is obvious. I can try to stress the system by > > Get a copy of memtest86, its a standalone memory tester. > Alan, Linus, Thanks for your help. I ran memtest86 for 6 hrs. RAM looks O.K.. I added swap back (just in case). Now I will be eliminating suspicious kernel modules one by one. Will post results in few days. Cheers! Arthur - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-ac5 - The loopback hang saga continues (not me ?)
FYI following hints from the linux-crypto mailing-list archives, I am using the following configuration : linux-2.4.0 patch-int-2.4.0.3 http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-1.gz http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-bdev-inc-1.gz util-linux-2.10o Documentation/crypto/util-linux-2.10o.patch I setup an encrypted 2097152000 byte loopback partition and moved 800MB of data there, including a 90MB file. My only problems are: - rc.d/init.d/S01reboot sometimes fails to unmount partitions with loop files on them (this already happened with 2.2.17). - losetup after losetup -d sometimes fails. -- Pascal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PS/2 Mouse/Keyboard conflict and lockup
"Udo A. Steinberg" wrote: > > I'm not sure whether this is related to the ominous ps/2 mouse bug > you have been chasing, but this problem is 100% reproducible and > very annoying. > > After upgrading my Asus A7V Bios from 1003 to 1005D, gpm no longer > receives any mouse events and the mouse doesn't work in text > consoles. Once I kill gpm and restart gpm -t ps2 the keyboard > locks up. Alright, I found the culprit - ACPI. Once I had compiled the kernel without it, all the problems mysteriously vanished. I knew there was a reason it was marked 'Experimental' :) Sorry for the noise. -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs - problems mounting after power outage
Dream on if you think "Writeback cacheing is disabled" on all systems bye default. If you did not wack it. It is not off. On Wed, 7 Feb 2001, Jeff McWilliams wrote: > Chris, > > Thanks for the reply. > > > Which reiserfs version is this? Upgrading to the reiserfs included in > > 2.4.1 would be a good plan, there have been a few bug fixes since test9 > > times (none specfically related to this). > > > > /var/log/messages shows ReiserFS reporting version 3.6.18. > > > If this raid controller has writeback cache, make sure you either have a > > battery backup for the cache, or have writeback turned off. > > > > It has no battery backup for the cache. Writeback cacheing is disabled. > > > How hung is it? Does the whole system stop, or does this mount just > > block forever? > > > > When the mount hangs the rest of the system is responsive. I can to go other > virtual consoles and do other things and it works fine. If I attempt to shut > down the system (shutdown -h now) the kernel blocks trying to unmount local > filesystems just before powering down. > > > The reiserfs tools I used are from Debian's reiserfsprogs_3.0.20001019-3.deb > > > These programs also hang? Does reiserfsck (which version BTW) give any > > output at all? > > > > > > If I do a reiserfsck /dev/sda7 I get the following: > > ns2:/usr/share/doc/reiserfsprogs# reiserfsck --rebuild-tree /dev/sda7 > > <-reiserfsck, 2000-> > reiserfsprogs 3.x > > This is an experimental version of reiserfsck, MAKE A BACKUP FIRST! > Don't run this program unless something is broken. You may want > to backup first. Some types of random FS damage can be recovered > from by this program, which basically throws away the internal nodes > of the tree and then reconstructs them. This program is for use only > by the desperate, and is of only beta quality. Email > [EMAIL PROTECTED] with bug reports. > Will replay just like mounting would > Do you want to run this program?[N/Yes] (note need to type Yes):Yes > Replaying log.. > Looking for the oldest transaction to start with ok > 1 valid trans found. Will replay from 50 to 50 > Replaying transaction.. 0 left.. > > > How long should I wait for this to run? It's an 8 gig partition with perhaps > a few megs of data on it. I've let this run for 20 minutes or so (the system is > a Pentium 200MMX with 64M of RAM, console mode only, no XFree86 stuff), and > it just runs, consuming 97% CPU according to top. /proc/loadavg reports > 1.00 0.97 0.71 2/29 378 > > I'm interested in building 2.4.1 but I haven't seen a released one yet and > haven't done an Alan Cox patch series kernel build before. Maybe it's time to > try. :-) > > That might have to wait until this weekend though. I'm a developer by day, > and a sys admin by night or on the weekends. I can also grab and build the > latest toolset instead of using the Debian pre-packaged ones if you think that > this will help. > > Jeff > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs - problems mounting after power outage
Chris, Thanks for the reply. > Which reiserfs version is this? Upgrading to the reiserfs included in > 2.4.1 would be a good plan, there have been a few bug fixes since test9 > times (none specfically related to this). > /var/log/messages shows ReiserFS reporting version 3.6.18. > If this raid controller has writeback cache, make sure you either have a > battery backup for the cache, or have writeback turned off. > It has no battery backup for the cache. Writeback cacheing is disabled. > How hung is it? Does the whole system stop, or does this mount just > block forever? > When the mount hangs the rest of the system is responsive. I can to go other virtual consoles and do other things and it works fine. If I attempt to shut down the system (shutdown -h now) the kernel blocks trying to unmount local filesystems just before powering down. The reiserfs tools I used are from Debian's reiserfsprogs_3.0.20001019-3.deb > These programs also hang? Does reiserfsck (which version BTW) give any > output at all? > > If I do a reiserfsck /dev/sda7 I get the following: ns2:/usr/share/doc/reiserfsprogs# reiserfsck --rebuild-tree /dev/sda7 <-reiserfsck, 2000-> reiserfsprogs 3.x This is an experimental version of reiserfsck, MAKE A BACKUP FIRST! Don't run this program unless something is broken. You may want to backup first. Some types of random FS damage can be recovered from by this program, which basically throws away the internal nodes of the tree and then reconstructs them. This program is for use only by the desperate, and is of only beta quality. Email [EMAIL PROTECTED] with bug reports. Will replay just like mounting would Do you want to run this program?[N/Yes] (note need to type Yes):Yes Replaying log.. Looking for the oldest transaction to start with ok 1 valid trans found. Will replay from 50 to 50 Replaying transaction.. 0 left.. How long should I wait for this to run? It's an 8 gig partition with perhaps a few megs of data on it. I've let this run for 20 minutes or so (the system is a Pentium 200MMX with 64M of RAM, console mode only, no XFree86 stuff), and it just runs, consuming 97% CPU according to top. /proc/loadavg reports 1.00 0.97 0.71 2/29 378 I'm interested in building 2.4.1 but I haven't seen a released one yet and haven't done an Alan Cox patch series kernel build before. Maybe it's time to try. :-) That might have to wait until this weekend though. I'm a developer by day, and a sys admin by night or on the weekends. I can also grab and build the latest toolset instead of using the Debian pre-packaged ones if you think that this will help. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Promise, DMA and RAID5 problems running 2.4.1
"A.Sajjad Zaidi" wrote: > > do you understand that you can't really have raid on ide involving > > two drives on the same channel? > > Is that just because of performance or are there other problems? Its working > fine as it is, but Im considering setting up all drives as masters (2x > ATA-100, 2x ATA-66). It's because IDE is a blocking bus - each drive must complete its' task before the data bus is released for the next IO operation. So, the first drive will finish writing to the disk before the second drive can start. (That's one reason why SCSI is preferred for high end systems - you can "disconnect" from an IO operation to allow other IO's to be sent to other devices on the same bus) -- Stephen Wille Padnos Programmer, Engineer, Problem Solver [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Promise, DMA and RAID5 problems running 2.4.1
Mark Hahn wrote: > > drives (all IBM-DTLA307045 s) that I realised that the cylinder/head > > translation is different and I cant use the whole drive unless its > > partitioned while attached to the other IDE ports. > > no, it's just that the bios doesn't perform the LBA geometry lie > outside the hd[abcd]. Hmm, thats weird, because hd[abcd] were the ones without the LBA geometry. Maybe it was because ide was reversed (ide=reverse lilo parameter). > boot with hde=",255,63" (or whatever). Thanks, I was searching for something like that. > > Second, I set up raid mirroring for 4 drives(2 raid, 2spare). Since one > > drive isnt available yet, one of the 2 raid partitions are set as > > 'failed-disk'. All drives are connected to the ATA-100 controller. This > > do you understand that you can't really have raid on ide involving > two drives on the same channel? Is that just because of performance or are there other problems? Its working fine as it is, but Im considering setting up all drives as masters (2x ATA-100, 2x ATA-66). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] starfire reads irq before pci_enable_device.
Hi Jeff,
On Wed, 07 Feb 2001 14:57:16 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Here's the patch I have, against vanilla 2.4.2-pre1, with the
> pci_enable_device preferred changes included...
Well, I decided to bite the bullet and port my zerocopy starfire
changes to the official tree, properly ifdef'ed. So here it goes,
the patch was made against 2.4.1 vanilla and includes all the
fixes from Jeff and myself that were sent to the list so far.
I've also added myself as the starfire maintainer -- I hope
nobody objects.
Alan, if you want, I can rediff this against 2.4.1-ac. I'll
also try and send a 2.2.19 patch shortly.
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
--
--- linux-2.4.vanilla/MAINTAINERS Wed Feb 7 15:45:15 2001
+++ linux-2.4-boxter/MAINTAINERSWed Feb 7 17:38:50 2001
@@ -1166,6 +1166,11 @@
W: http://www.stallion.com
S: Supported
+STARFIRE/DURALAN NETWORK DRIVER
+P: Ion Badulescu
+M: [EMAIL PROTECTED]
+S: Maintained
+
STARMODE RADIO IP (STRIP) PROTOCOL DRIVER
W: http://mosquitonet.Stanford.EDU/strip.html
S: Unsupported ?
--- linux-2.4.vanilla/drivers/net/starfire.cFri Aug 11 15:57:58 2000
+++ linux-2.4-boxter/drivers/net/starfire.c Wed Feb 7 17:38:19 2001
@@ -34,6 +34,10 @@
LK1.1.4 (jgarzik):
- Merge Becker version 1.03
+
+ LK1.2.1 (Ion Badulescu <[EMAIL PROTECTED]>)
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
*/
/* These identify the driver base version and may not be removed. */
@@ -43,11 +47,36 @@
" Updates and info at http://www.scyld.com/network/starfire.html\n";
static const char version3[] =
-" (unofficial 2.4.x kernel port, version 1.1.4, August 10, 2000)\n";
+" (unofficial 2.4.x kernel port, version 1.2.1, February 07, 2001)\n";
/* The user-configurable values.
These may be modified when a driver module is loaded.*/
+/*
+ * Adaptec's license for their Novell drivers (which is where I got the
+ * firmware files) does not allow to redistribute them. Thus, we can't
+ * include them with this driver.
+ *
+ * However, an end-user is allowed to download and use them, after
+ * converting them to C header files using starfire_firmware.pl.
+ * Once that's done, the #undef must be changed into a #define
+ * for this driver to really use the firmware. Note that Rx/Tx
+ * hardware TCP checksumming is not possible without the firmware.
+ *
+ * I'm currently talking to Adaptec about this redistribution issue.
+ * Stay tuned...
+ */
+#undef HAS_FIRMWARE
+/*
+ * The current frame processor firmware fails to checksum a fragment
+ * of length 1. If and when this is fixed, the #define below can be removed.
+ */
+#define HAS_BROKEN_FIRMWARE
+/*
+ * Define this if using the driver with the zero-copy patch
+ */
+#undef ZEROCOPY
+
/* Used for tuning interrupt latency vs. overhead. */
static int interrupt_mitigation = 0x0;
@@ -88,25 +117,39 @@
#define PKT_BUF_SZ 1536/* Size of each temporary Rx
buffer.*/
+/*
+ * The ia64 doesn't allow for unaligned loads even of integers being
+ * misaligned on a 2 byte boundary. Thus always force copying of
+ * packets as the starfire doesn't allow for misaligned DMAs ;-(
+ * 23/10/2000 - Jes
+ *
+ * Neither does the Alpha. -Ion
+ */
+#if defined(__ia64__) || defined(__alpha__)
+#define PKT_SHOULD_COPY(pkt_len) 1
+#else
+#define PKT_SHOULD_COPY(pkt_len) (pkt_len < rx_copybreak)
+#endif
+
+#ifdef ZEROCOPY
+#define skb_first_frag_len(skb)skb_headlen(skb)
+#else /* not ZEROCOPY */
+#define skb_first_frag_len(skb)(skb->len)
+#endif /* not ZEROCOPY */
+
#if !defined(__OPTIMIZE__)
#warning You must compile this file with the correct options!
#warning See the last lines of the source file.
#error You must compile this driver with "-O".
#endif
-/* Include files, designed to support most kernel versions 2.0.0 and later. */
-#include
#include
-#if LINUX_VERSION_CODE < 0x20300 && defined(MODVERSIONS)
-#include
-#endif
-
#include
#include
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -117,12 +160,17 @@
#include
#include
+#ifdef HAS_FIRMWARE
+#include "starfire_firmware.h"
+#endif /* HAS_FIRMWARE */
+
MODULE_AUTHOR("Donald Becker <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Adaptec Starfire Ethernet driver");
MODULE_PARM(max_interrupt_work, "i");
MODULE_PARM(mtu, "i");
MODULE_PARM(debug, "i");
MODULE_PARM(rx_copybreak, "i");
+MODULE_PARM(interrupt_mitigation, "i");
MODULE_PARM(options, "1-" __MODULE_STRING(MAX_UNITS) "i");
MODULE_PARM(full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i");
@@ -155,8 +203,9 @@
See the Adaptec manual for the many possible structures, and options for
each structure. There are far too many to document here.
-For transmit
PS/2 Mouse/Keyboard conflict and lockup
Hi Alan et. all I'm not sure whether this is related to the ominous ps/2 mouse bug you have been chasing, but this problem is 100% reproducible and very annoying. After upgrading my Asus A7V Bios from 1003 to 1005D, gpm no longer receives any mouse events and the mouse doesn't work in text consoles. Once I kill gpm and restart gpm -t ps2 the keyboard locks up. Logging in remotely and looking at dmesg revealed the following: keyboard: Timeout - AT keyboard not present? keyboard: unrecognized scancode (70) - ignored If I don't kill and restart gpm, but start X, the mouse works perfectly, but only in X. Any ideas? -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 Kernel Crash
On Wed, 7 Feb 2001, David Woodhouse wrote: > [EMAIL PROTECTED] said: > > On one of my linux boxen, that is used as an ISDN router after a 3 > > days of up time I get this: > > Read http://www.tux.org/lkml/#s4-3 > > Particularly the "Don't even bother..." part. The Call Trace was decoded by klogd, running it through ksymoops won't really work. AFAICS the trace makes sense. Since I can't think of any relation to the ISDN stack, I asked BaRT to post the trace to l-k, and I think it actually provides useful information. So I'ld hope somebody takes a look into this. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
turn $2000.00 into $16000.00 in 2 weeks
New Concept in Gifting! Join A Team Of 6 And 7 Figure Earners The sole purpose of this Activity is to enable us to bless more people and to change lives by helping others receive gifts, which will enable the receiver to share their blessings with others! * Gift $2000 to prosper over $16,000 * No dues or membership fees * Introduce only two into this private activity * No purchases, no quotas, no selling! * No meetings, conference calls, no pressure! * Participation is by invitation only and of your own free will. * 6 & 7 figure income earners as leadership Interested? The program is moving fast. Go to: http://serfd.pokeadot.com for more details. If you can not get to the website call 1-310-706-2050 ext. 4594 and please leave your: Name Email address Phone number (with area code) Time zone and best time to call To be removed send an email to: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TCP_NOPUSH on FreeBSD, TCP_CORK on Linux (was: Is sendfile all that
Alexy wrote: > > > How close is TCP_NOPUSH to behaving identically to TCP_CORK now? > > They have not so much of common. > > TCP_NOPUSH enables T/TCP and its presense used to mean that > T/TCP is possible on this system. Linux headers cannot > even contain TCP_NOPUSH. But Tony Finch wrote: > They are exactly the same. Alexy, Tony just checked in a change to FreeBSD to make TCP_NOPUSH behave the same as TCP_CORK. Tony, are people using the TCP_NOPUSH define as a way to detect the presence of T/TCP support? In that case, perhaps the right thing to do to achieve source compatibility would be for FreeBSD to also define TCP_CORK (and give it TCP_NOPUSH as a value, perhaps). - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] micro-opt DEBUG_ADD_PAGE
On Wed, 7 Feb 2001, Linus Torvalds wrote:
> No. The optimization is entirely legal - but the fact that
> "constant_test_bit()" uses a "volatile unsigned int *" is the reason why
> gcc thinks it can't optimize it.
This thing did attract me somewhat and I decided to learn a little about
compilers.
Result: Unfortunately it's not just the volatile, there's a bunch of
conditions you have to fulfill to have the compiler optimize this. (Sounds
like work for the compiler guys).
Test program is attached, inspecting the code (egcs 2.91.66 and
gcc-2.96 (-69) generate the same code gives the following conclusions:
- f1(unsigned long f): manually optimized
if (f & ((1 << 1) | (1 << 2) | (1 << 4))) {
-> optimized code (of course)
- f2(unsigned long f): leave some work to the compiler
if ((f & (1 << 1)) || (f & (1 << 2)) || (f & (1 << 4))) {
-> optimized code (good)
- f3(unsigned int f): use constant_test_bit macro
if (constant_test_bit(1, ) || constant_test_bit(2, ) ||
constant_test_bit(4, )) {
-> optimized code
where
#define constant_test_bit(nr, addr) \
(((1UL << (nr & 31)) & ((unsigned int*)(addr))[nr >> 5]) != 0)
(doesn't optimize when putting *const* unsigned int there)
- f4: same thing as f3, but use (unsigned long f) instead of
(unsigned int f)
-> no optimization
- f5: same thing as f3, but use inline function for constant_test_bit
-> no optimization
- f6: same thing as f3, but use test_bit instead of constant_test_bit,
where
#define test_bit(nr,addr) \
(__builtin_constant_p(nr) ? \
constant_test_bit((nr),(addr)) : \
variable_test_bit((nr),(addr)))
-> no optimization
Conclusion: With the compilers tested, lots of cases are not optimized
although the could be in theory:
- casting even from unsigned int to unsigned long breaks optimization
- macros are better than inline
- Even though evaluated at compile time, __builtin_constant_p breaks
optimization here, too.
BTW: volatile makes optimization impossible as well, of course, it leads
to repeated reloads of the variable, whereas otherwise it's cached in a
register in the above "no optimization" cases. That's expected behavior.
--Kai
Test code:
--
#define ADDR (*(volatile long *) addr)
static __inline__ int inl_constant_test_bit(int nr, const void * addr)
{
return ((1UL << (nr & 31)) & (((unsigned int *) addr)[nr >> 5])) != 0;
}
#define constant_test_bit(nr, addr) (((1UL << (nr & 31)) & ((unsigned int*)(addr))[nr
>> 5]) != 0)
static __inline__ int variable_test_bit(int nr, volatile void * addr)
{
int oldbit;
__asm__ __volatile__(
"btl %2,%1\n\tsbbl %0,%0"
:"=r" (oldbit)
:"m" (ADDR),"Ir" (nr));
return oldbit;
}
#define test_bit(nr,addr) \
(__builtin_constant_p(nr) ? \
constant_test_bit((nr),(addr)) : \
variable_test_bit((nr),(addr)))
int f1(unsigned long f)
{
if (f & ((1 << 1) | (1 << 2) | (1 << 4))) {
return 1;
}
return 0;
}
int f2(unsigned long f)
{
if ((f & (1 << 1)) || (f & (1 << 2)) || (f & (1 << 4))) {
return 1;
}
return 0;
}
int f3(unsigned int f)
{
if (constant_test_bit(1, ) || constant_test_bit(2, ) || constant_test_bit(4,
)) {
return 1;
}
return 0;
}
int f4(unsigned long f)
{
if (constant_test_bit(1, ) || constant_test_bit(2, ) || constant_test_bit(4,
)) {
return 1;
}
return 0;
}
int f5(unsigned int f)
{
if (inl_constant_test_bit(1, ) || inl_constant_test_bit(2, ) ||
inl_constant_test_bit(4, )) {
return 1;
}
return 0;
}
int f6(unsigned int f)
{
if (test_bit(1, ) || test_bit(2, ) || test_bit(4, )) {
return 1;
}
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: nfs_refresh_inode: inode number mismatch
On Wednesday February 7, [EMAIL PROTECTED] wrote: > > This is a weird problem that I am looking at right. It seems to indicate a > bug in the nfs server. > > I have a MIPS machine that boots from a NFS root fs hosted on a redhat 6.2 > workstation. Everything works fine except that after a few reboots I start to > see the error messages like the following: What verison of Linux? If it is less than 2.2.18, then an upgrade will help you a lot. If it is >= 2.2.18, I will look some more. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
nfs_refresh_inode: inode number mismatch
This is a weird problem that I am looking at right. It seems to indicate a bug in the nfs server. I have a MIPS machine that boots from a NFS root fs hosted on a redhat 6.2 workstation. Everything works fine except that after a few reboots I start to see the error messages like the following: Freeing unused kernel memory: 24k freed INIT: version 2.77 booting nfs_refresh_inode: inode number mismatch expected (0x308/0x28b3d2), got (0x308/0x12b91b) INIT: Entering runlevel: 3 sh-2.03# Restarting the nfs server on the host does not get rid of the messages. Things will get better if I reboot the host. I traced the network packets, and it seems obvious that the server is returning wrong fileid in the "write reply" message. Below is a segment of the extracted packet trace. It is obvious that the nfs server returns a wrong fileid for the same handle it returned earlier to the client. The confusing part is the nfs server actually serves the first write request, and a couple of other requests, correctly but failed for the second time, returning a wrong fileid. In my particular setup, it seems only certain files (inodes) tend to get screwed up. Does anybody have an idea as to what is wrong here? Please cc your reply to my email address. TIA. Jun -- round 3: case 1: 2177 lookup: ioctl.save 2178 lookup reply: fileid: 2667474 handle: cabaebfed2b32800e6ab28000803080354c21100b2302b0c 2181 write: offset:0 total count: 60 handle: cabaebfed2b32800e6ab28000803080354c21100b2302b0c 2182 write reply: fileid: 2667474 size: 60 2183 setattr: handle: cabaebfed2b32800e6ab28000803080354c21100b2302b0c 2184 setattr reply: fileid: 2667474 2185 write: handle: cabaebfed2b32800e6ab28000803080354c21100b2302b0c 2186 write reply: fileid 1227035 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Memory Setting with prom_meminit() in memory.c.....
Dear all,
The board I used has two pieces of RAM. The virtual address start at 0x
and
0x0200 . One is 4 MB(0x ) and the other is 16 MB(0x0200 ).
But
orginal file is writted as the following. How could I modify this file to
match my
target board?
Green
/*
* memory.c: memory initialisation code.
*
* Copyright (C) Harald Koerfgen
* Copyright (C) Jim Pick
* Copyright (C) Pavel Machek
*
* $Id: memory.c,v 1.16 2000/07/09 03:36:18 nop Exp $
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* À³¸Ó¤£¬O¥Îvitec_helio¡A©Ò¥H·|¶]other >This line is Chinese(Big5) */
/* We don't use VTECH_HELIO. So the CONFIG_VTECH_HELIO is not defined */
#ifdef CONFIG_VTECH_HELIO
#define PROM_DEBUG
#endif
#ifdef PROM_DEBUG
extern int prom_printf(char * fmt, ...);
#endif
#ifndef CONFIG_VTECH_HELIO
int main_memory = CONFIG_MAIN_MEMORY; /* We should autoconfigure this. For
now, just let the user select. */
int exp_memory = CONFIG_EXP_MEMORY;
#define MEGA (1024*1024)
#endif
extern char _end;
extern char _fdata;
#define PFN_UP(x) (((x) + PAGE_SIZE-1) >> PAGE_SHIFT)
#define PFN_DOWN(x) ((x) >> PAGE_SHIFT)
#define PFN_ALIGN(x) (((unsigned long)(x) + (PAGE_SIZE - 1)) & PAGE_MASK)
/* Modyfied by Green 2001/02/07 */
/* This function show the message through COM port */
#ifdef JAODEBUG
extern int Jprom_printf(const char * fmt, ...);
#else
#define Jprom_printf(fmt, a...)
#endif
/* End of modification*/
#ifdef CONFIG_VTECH_HELIO /* We didn't go here insteal of
prom_meminit_other() */
static void __init prom_meminit_helio(void)
{
.
.
}
#else /* CONFIG_VTECH_HELIO */
static void __init prom_meminit_other(void)
{
extern unsigned long videomemory;
unsigned long free_start;
unsigned long free_end;
unsigned long start_pfn;
unsigned long bootmap_size;
unsigned long ramspace;
static char vidmem[(320 * 240 / 2) + PAGE_SIZE - 1];
/* Okay the Helio has an odd memory layout, split into 4 banks of 2M
* at the following places:
*
* 0x
* 0x0040
* 0x0200
* 0x0240 (add 0x8000 for virtual address)
*
* We allocate the bootmem as a continuous bank and then free up the
* relevant memory holes. Of these the kernel will be using some
* of the first bank so be careful how we deal with it.
*/
Jprom_printf("prom_meminit_other>Beginning\n");
videomemory = KSEG0ADDR(PFN_ALIGN(vidmem));
start_pfn = PFN_UP((unsigned long)&_end);
/*_end=801abba0>0x000801ac*/
free_start = PHYSADDR(PFN_ALIGN(&_end));
#ifdef CONFIG_VTECH_HELIO_EMULATOR
/* What's worse, the emulator implements two 4M banks at
* 0x and 0x0200. Fixing soon, but until then:
*/
ramspace = 0x0240; /* With holes!! */
free_end = 0x0040;
Jprom_printf("--->ramspace: 0x%08x\n", ramspace);
bootmap_size = init_bootmem(start_pfn, ramspace >> PAGE_SHIFT);
/* Free up the *two* memory banks */
free_bootmem(free_start + bootmap_size, free_end - free_start -
bootmap_size);
free_bootmem(0x0200, 0x0040);
#else
ramspace = 0x0260; /* With holes!! */
free_end = 0x0020;
bootmap_size = init_bootmem(start_pfn, ramspace >> PAGE_SHIFT);
Jprom_printf("_end = 0x%08x>_end \n",&_end);
Jprom_printf("start_pfn= 0x%08x>FPN_UP() \n",start_pfn);
Jprom_printf("free_start = 0x%08x>PHYSADDR \n",free_start);
Jprom_printf("free_end = 0x%08x>0x0020 \n",free_end);
Jprom_printf("bootmap_size =
0x%08x>bootmapsize\n",bootmap_size);
Jprom_printf("PAGE_SHIFT = 0x%08x>PAGE_SHIFT \n",PAGE_SHIFT);
Jprom_printf("ramspace = 0x%08x>0x0260 \n",ramspace);
/* Free up the four memory banks */
free_bootmem(free_start + bootmap_size, free_end - free_start -
bootmap_size);
free_bootmem(0x0040, 0x0020);
free_bootmem(0x0200, 0x0020);
free_bootmem(0x0240, 0x0020);
#endif
//#ifdef CONFIG_FB
// extern unsigned long videomemory;
//#endif
// unsigned long free_start, free_end, start_pfn, bootmap_size;
// unsigned long mem_size = main_memory*MEGA;
//
// free_end = mem_size;
// if (exp_memory)
// mem_size = 0x0200 | (exp_memory*MEGA);
//
// free_start = PHYSADDR(PFN_ALIGN(&_end));
// start_pfn = PFN_UP((unsigned long)&_end);
//
// #ifdef CONFIG_FB
/*
* This has to be in line with VIDEORAM_SIZE in r3912fb.c
*/
// switch (mips_machtype) {
// case MACH_R39XX_SHARP_MOBILON:
// case MACH_R39XX_COMPAQ:
//modified by Jao
//free_end -= 640*240;
// free_end -= 320*240;
// videomemory = KSEG0ADDR(free_end);
// break;
// case MACH_R39XX_PHILIPS_VELO:
// free_end -= 480*240/2; /* Velo has actually 2 different bit depths, this
is for 4bit.
//It is bigger that's why it is used here. */
// videomemory = KSEG0ADDR(free_end);
// break;
// case
Re: 2.4.1-ac5 - The loopback hang saga continues
> It appears that the loopback-hang parasite is alive and well in 2.4.1-ac5. > I've done several tests and I thus provide the following information: > > The bug is independent of UP or SMP configured.. it hung both ways, but the > box itself is UP. > > It appears to hang when internal buffers get filled. The way I see it, copying > files from disk to the loopback device (which is a file on the same disk) > begins to read from the disk. When the internal read buffer is full, the > kernel's queued writes start activating and the data gets copied to the > loopback file. This process repeats over and over, as it should normally. > > Sometimes however, during a read from the disk, it fills up its buffers and > then never makes the accompanying write. In fact, the entire device freezes on > the read. > > I was able to lessen the frequency of hanging by using the -v flag and tapping > ^S and ^Q to temporarily 'pause' copying. This ensures that the read buffer > will never become full to the point where it could cause the hang, and appears > to work -- until it came across the libc.a file. There was no way to pause it > here because nothing is being outputted to the screen while it's copying > libc.a. Unfortunately, it fills the buffer too quick and hangs 100% every time. > The disk is totally nonresponsive at this point, and a hard reset is necessary. > > I hope this helps anyone who is still tracking down the loopback problem. > > Regards, > Byron > > -- > Byron Stanoszek Ph: (330) 644-3059 I can confirm this. The system totally locks when this occurs. I let it sit all night when it did this the last time, and it didn't recover. It requires a large file transfer to usually invoke it. Billy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
On Wed, 7 Feb 2001, Jason Ford wrote: > Byron, > > I got your patch to compile in fine however it still exhibits the same > behavior that the older patches did. It looks like the commands sent to the > controller are still not working correctly as the new subsystem in the > kernel was rewritten. > > This is the error I get in my messages file when trying to copy from one > disk partition to another one. > > so on and so on.. Am I doing something wrong? Nope. It looks horribly broken. Oh well.. I guess I'd stick to 2.2.19-pre on the Dell machines for the time being. -Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Problem: OOPS in getblk in 2.2.16-3smp - may be software RAID related
I sent this oops to the file system and a raid maintainer asking for
more
info and received no response. Please let mw know if there is a better
place to send it.
I received a kernel oops in the file system layer on my dual PIII w/
software Raid5
running RedHat 6.2 with the redhat kernel 2.2.16-3smp. I took down all
the system
info that I thought would be relevant, if I missed anything let me know.
The oops occurred suddenly after doing what it had been doing for 6
solid months
and has not given me any grief since.
If there are known errors that could have caused this in the kernel I am
running
please let me know.
Please CC me on any responses.
Much thanks
Orion Henry
Jan 8 19:18:30 aule kernel: Unable to handle kernel paging request at
virtual address 00020078
Jan 8 19:18:30 aule kernel: current->tss.cr3 = 0e52f000, %%cr3 =
0e52f000
Jan 8 19:18:30 aule kernel: *pde =
Jan 8 19:18:30 aule kernel: Oops: 0002
Jan 8 19:18:30 aule kernel: CPU:0
Jan 8 19:18:30 aule kernel: EIP:0010:[getblk+205/324]
Jan 8 19:18:30 aule kernel: EFLAGS: 00010207
Jan 8 19:18:30 aule kernel: eax: c11e00e0 ebx: c11e06e0 ecx:
000c edx: 00020040
Jan 8 19:18:30 aule kernel: esi: 1000 edi: 000c ebp:
0900 esp: ce613d9c
Jan 8 19:18:30 aule kernel: ds: 0018 es: 0018 ss: 0018
Jan 8 19:18:30 aule kernel: Process spawn (pid: 28305, process nr: 45,
stackpage=ce613000)
Jan 8 19:18:30 aule kernel: Stack: 0900 03a9 000c c0141ee7
0900 004503a9 1000 0045
Jan 8 19:18:30 aule kernel:ce613f08 dce91100 dce91100 0e75
1000 0008 03b0 0e75
Jan 8 19:18:30 aule kernel:0900 de14c480 ce613e24 8000
de14c480 ce612000 0008 0e75
Jan 8 19:18:30 aule kernel: Call Trace: [ext2_new_block+2291/2756]
[ext2_alloc_block+344/356] [inode_getblk+205/392] [ext2_getblk+194/524]
[ext2_file_write+1308/1584] [refile_buffer+86/184]
[locks_delete_lock+52/128]
The Offending Code is Here
--
>From /usr/src/linux-2.2.16/fs/buffer.c:
--
/*
* Ok, this is getblk, and it isn't very clear, again to hinder
* race-conditions. Most of the code is seldom used, (ie repeating),
* so it should be much more efficient than it looks.
*
* The algorithm is changed: hopefully better, and an elusive bug
removed.
*
* 14.02.92: changed it to sync dirty buffers a bit: better performance
* when the filesystem starts to get full of dirty blocks (I hope).
*/
struct buffer_head * getblk(kdev_t dev, int block, int size)
{
struct buffer_head * bh;
int isize;
repeat:
bh = get_hash_table(dev, block, size);
if (bh) {
if (!buffer_dirty(bh)) {
bh->b_flushtime = 0;
}
return bh;
}
isize = BUFSIZE_INDEX(size);
get_free:
bh = free_list[isize];
if (!bh)
goto refill;
remove_from_free_list(bh);
/* OK, FINALLY we know that this buffer is the only one of its
kind,
* and that it's unused (b_count=0), unlocked, and clean.
*/
init_buffer(bh, dev, block, end_buffer_io_sync, NULL);
bh->b_state=0;
insert_into_queues(bh);
return bh;
/*
* If we block while refilling the free list, somebody may
* create the buffer first ... search the hashes again.
*/
refill:
refill_freelist(size);
if (!find_buffer(dev,block,size))
goto get_free;
goto repeat;
}
--
And it looks like this in the debugger:
$ gdb /boot/vmlinux-2.2.16-3
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
(gdb) disas getblk
Dump of assembler code for function getblk:
0xc012765c :sub$0x4,%esp
0xc012765f : push %ebp
0xc0127660 : push %edi
0xc0127661 : push %esi
0xc0127662 : push %ebx
0xc0127663 : xor%ebp,%ebp
0xc0127665 : mov0x20(%esp,1),%esi
0xc0127669 : mov0x18(%esp,1),%bp
0xc012766e : push %esi
0xc012766f : mov0x20(%esp,1),%edi
0xc0127673 : push %edi
0xc0127674 : push %ebp
0xc0127675 : call 0xc01272f4
0xc012767a : mov%eax,%ebx
0xc012767c : add$0xc,%esp
0xc012767f : test %ebx,%ebx
0xc0127681 : je 0xc0127698
0xc0127683 : mov0x18(%ebx),%eax
0xc0127686 : test $0x2,%al
0xc0127688 : jne0xc0127691
0xc012768a : movl $0x0,0x2c(%ebx)
0xc0127691 : mov%ebx,%eax
0xc0127693 : jmp0xc0127798
0xc0127698 : mov%esi,%eax
0xc012769a : sar
[PATCH] to deal with bad dev->refcnt in unregister_netdevice()
Earlier I reported error messages when I tried to eject
a Xircom CEM56 network card under Linux 2.4.x. (See below.
I also submitted this patch as a followup to that thread.)
Here is a patch which may not solve the underlying
problem but which does prevent the kernel from generating
an infinite number of
"unregister_netdevice: waiting for eth0 to become free.
Usage count = -1"
messages on "cardctl eject" and from hanging up at shutdown.
-
root@thanatos:/usr/src/kernel-source-2.4.1-ac3/net/core# diff -Naur dev.c_ORIG dev.c
--- dev.c_ORIG Mon Feb 5 17:39:31 2001
+++ dev.c Wed Feb 7 18:35:45 2001
@@ -2555,7 +2555,7 @@
*/
now = warning_time = jiffies;
- while (atomic_read(>refcnt) != 1) {
+ while (atomic_read(>refcnt) > 1) {
if ((jiffies - now) > 1*HZ) {
/* Rebroadcast unregister notification */
notifier_call_chain(_chain, NETDEV_UNREGISTER, dev);
---
The underlying problem seem so be that refcnt is zero or
less at this point. This is erroneous. The error in
maintaining the refcnt appears to occur only when
I configure the eth0 interface (using pump or dhclient).
The more times I "ifup eth0" and "ifdown eth0" before
ejecting the card, the lower the "usage count" is
reported to be (i.e., the larger the negative number!).
Be that as it may, because of the erroneous refcnt,
the above while loop within unregister_netdevice()
loops forever in the original code. As modified it
falls through; and this makes the kernel usable for me.
In order to avoid the
"KERNEL: assertion(dev->ip_ptr==NULL)failed at
dev.c(2422):netdev_finish_unregister"
message and the occasional
"Freeing alive device"
message it seems to suffice that I kill the dhclient
process before running "ifdown eth0". Am I right in
assuming that the latter messages aren't serious?
I hope the networking gurus can find the real bugs here.
Thomas Hood
> I have a bit more information about this bug now.
> The message "assertion(yadda) failed ..." occurs only
> if the eth0 interface has been configured using pump
> or dhclient. If the card isn't connected to the network
> the message never occurs. If eth0 is merely brought up
> and down using ifconfig the message doesn't occur. Only
> if pump or dhclient has configured eth0 does the message
> occur. Sometimes it occurs on "ifdown eth0", sometimes
> on "cardctl eject" and sometimes during the shutdown
> sequence.
>
> Thomas
>
> >
> > Dear l-k.
> >
> > I'm still having this problem with kernel 2.4.0:
> >
> > Conditions:
> > Linux 2.4.0 compiled on an IBM ThinkPad 600 51U (Pentium II)
> > laptop with PCMCIA support. Same behavior with integral kernel
> > PCMCIA, modular kernel PCMCIA and modular Hinds PCMCIA. System
> > is Progeny Debian beta II.
> >
> > I have a Xircom modem/ethernet card which works correctly using
> > the serial_cs, xirc2ps_cs, ds, i82365 and pcmcia_core modules;
> > however when I try to "cardctl eject" or "reboot" I get first,
> >"KERNEL: assertion(dev->ip_ptr==NULL)failed at
> > dev.c(2422):netdev_finish_unregister"
> > (not exact since I had to copy it down on paper ... doesn't
> > show up in the logs) then a perpetual series of:
> >"unregister_netdevice: waiting for eth0 to become free.
> > Usage count = -1"
> > messages every five seconds or so. "ps -A" reveals that
> > modprobe is running; it can't be killed even with "kill -9".
> > The "ifconfig" command locks up. Shutdown won't complete
> > so I end up having to use SysRq-S-U-B to reboot.
> >
> > This problem only occurs if the Xircom card is connected to
> > the Ethernet (in which case it is configured using DHCP).
> > If the card is left unconnected to the network, the problem
> > does not occur---the card can be ejected.
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
someone knows a good sendmail mailing list ?
someone knows a good sendmail mailing list ? active like this one ? thanks.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI slowdown...
Grover, Andrew wrote: > Since you have a symtomatic system, if you're willing to do some testing to > either prove or disprove your theory (that entering C2/C3 interrupts enabled > helps things) I would greatly appreciate it. Leaving interrupts enabled does help a little, but the machine is still unusably slow, so it's not the fix. > Also, the next ACPI update will let you disable using this code for idle (so > we have some breathing room while we fix it) and will print some more C > state info on boot, because although you don't say, it sounds like you have > a desktop system, which usually don't support C2/C3, and so should not be > trying to enter them. Disabling the idle code definitely fixes it. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[Patch] ServerWorks peer bus fix for 2.4.x
The ServerWorks peer bus problem is still present on the 2.4.1 kernel. The
problem stems from the fact that there can be more than one secondary bus
for a given north bridge. For example, the Compaq Proliant DL580 has two
"root busses" coming off of a single north bridge. I'm including below an
email from Adam Lackorzynski. In his email, he includes a patch that fixes
the problem. I think Martin objected because he thought the patch got the
meaning of the two config registers wrong, but it is, in fact, correct.
Please accept this patch so that the 2.4 kernel can see all PCI devices on
systems with the ServerWorks chipset.
Thanks,
Dan Zink
[EMAIL PROTECTED]
--
The patch below (against vanilla 2.4.0) makes Linux recognize
PCI-Devices sitting in another PCI bus than 0 (or 1).
This was tested on a Netfinity 7100-8666 using a ServerWorks chipset.
00:00.0 Host bridge: ServerWorks CNB20HE (rev 21)
00:00.1 Host bridge: ServerWorks CNB20HE (rev 01)
00:00.2 Host bridge: ServerWorks: Unknown device 0006
00:00.3 Host bridge: ServerWorks: Unknown device 0006
00:01.0 SCSI storage controller: Adaptec 7896
00:01.1 SCSI storage controller: Adaptec 7896
00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet
LANCE] (rev 44)
00:06.0 VGA compatible controller: S3 Inc. Trio 64 3D (rev 01)
00:0f.0 ISA bridge: ServerWorks OSB4 (rev 4f)
00:0f.1 IDE interface: ServerWorks: Unknown device 0211
00:0f.2 USB Controller: ServerWorks: Unknown device 0220 (rev 04)
02:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43
(rev 41)
02:06.0 RAID bus controller: IBM: Unknown device 01bd
The last two lines do not occur without the patch.
diff -ur linux-2.4.0/linux/arch/i386/kernel/pci-pc.c
linux/arch/i386/kernel/pci-pc.c
--- linux-2.4.0/linux/arch/i386/kernel/pci-pc.c Thu Jun 22 16:17:16 2000
+++ linux/arch/i386/kernel/pci-pc.c Tue Jan 16 18:10:30 2001
@@ -849,10 +849,13 @@
* ServerWorks host bridges -- Find and scan all secondary buses.
* Register 0x44 contains first, 0x45 last bus number routed there.
*/
- u8 busno;
- pci_read_config_byte(d, 0x44, );
- printk("PCI: ServerWorks host bridge: secondary bus %02x\n", busno);
- pci_scan_bus(busno, pci_root_ops, NULL);
+ u8 busno_first, busno_last, i;
+ pci_read_config_byte(d, 0x44, _first);
+ pci_read_config_byte(d, 0x45, _last);
+ for (i = busno_first; i <= busno_last; i++) {
+ printk("PCI: ServerWorks host bridge: secondary bus %02x\n",
i);
+ pci_scan_bus(i, pci_root_ops, NULL);
+ }
pcibios_last_bus = -1;
}
Adam
--
Adam [EMAIL PROTECTED]
Lackorzynski http://a.home.dhs.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: aacraid 2.4.0 kernel
Byron, I got your patch to compile in fine however it still exhibits the same behavior that the older patches did. It looks like the commands sent to the controller are still not working correctly as the new subsystem in the kernel was rewritten. This is the error I get in my messages file when trying to copy from one disk partition to another one. Feb 7 19:32:11 bass kernel: SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 1 Feb 7 19:32:11 bass kernel: I/O error: dev 08:08, sector 657672 Feb 7 19:32:11 bass kernel: Feb 7 19:32:11 bass kernel: Feb 7 19:32:11 bass kernel: AacHba_`DoScsiWrite: WRITE request is larger than 64K Feb 7 19:32:11 bass kernel: AacHba_DoScsiWrite: ByteCount: 69632 Feb 7 19:32:11 bass kernel: AacHba_DoScsiWrite: SG ELEMENTS: 16 Feb 7 19:32:11 bass kernel: Dump SG Element Size... Feb 7 19:32:11 bass kernel: SG Segment 0: 4096 Feb 7 19:32:11 bass kernel: SG Segment 1: 4096 Feb 7 19:32:11 bass kernel: SG Segment 2: 4096 Feb 7 19:32:11 bass kernel: SG Segment 3: 4096 Feb 7 19:32:11 bass kernel: SG Segment 4: 4096 Feb 7 19:32:11 bass kernel: SG Segment 5: 4096 Feb 7 19:32:11 bass kernel: SG Segment 6: 4096 Feb 7 19:32:11 bass kernel: SG Segment 7: 8192 Feb 7 19:32:11 bass kernel: SG Segment 8: 4096 Feb 7 19:32:11 bass kernel: SG Segment 9: 4096 Feb 7 19:32:11 bass kernel: SG Segment 10: 4096 Feb 7 19:32:11 bass kernel: SG Segment 11: 4096 Feb 7 19:32:11 bass kernel: SG Segment 12: 4096 Feb 7 19:32:11 bass kernel: SG Segment 13: 4096 Feb 7 19:32:11 bass kernel: SG Segment 14: 4096 Feb 7 19:32:11 bass kernel: SG Segment 15: 4096 Feb 7 19:32:11 bass kernel: Feb 7 19:32:12 bass kernel: Feb 7 19:32:12 bass kernel: SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 1 Feb 7 19:32:12 bass kernel: I/O error: dev 08:08, sector 665864 Feb 7 19:32:12 bass kernel: Feb 7 19:32:12 bass kernel: Feb 7 19:32:12 bass kernel: AacHba_`DoScsiWrite: WRITE request is larger than 64K Feb 7 19:32:12 bass kernel: AacHba_DoScsiWrite: ByteCount: 69632 Feb 7 19:32:12 bass kernel: AacHba_DoScsiWrite: SG ELEMENTS: 16 Feb 7 19:32:12 bass kernel: Dump SG Element Size... Feb 7 19:32:12 bass kernel: SG Segment 0: 4096 Feb 7 19:32:12 bass kernel: SG Segment 1: 4096 Feb 7 19:32:12 bass kernel: SG Segment 2: 4096 Feb 7 19:32:12 bass kernel: SG Segment 3: 4096 Feb 7 19:32:12 bass kernel: SG Segment 4: 4096 Feb 7 19:32:12 bass kernel: SG Segment 5: 4096 Feb 7 19:32:12 bass kernel: SG Segment 6: 4096 Feb 7 19:32:12 bass kernel: SG Segment 7: 4096 Feb 7 19:32:12 bass kernel: SG Segment 8: 8192 Feb 7 19:32:12 bass kernel: SG Segment 9: 4096 Feb 7 19:32:12 bass kernel: SG Segment 10: 4096 Feb 7 19:32:12 bass kernel: SG Segment 11: 4096 Feb 7 19:32:12 bass kernel: SG Segment 12: 4096 Feb 7 19:32:12 bass kernel: SG Segment 13: 4096 Feb 7 19:32:12 bass kernel: SG Segment 14: 4096 Feb 7 19:32:12 bass kernel: SG Segment 15: 4096 Feb 7 19:32:12 bass kernel: Feb 7 19:32:12 bass kernel: so on and so on.. Am I doing something wrong? Thanks for your reply post.. Jason -Original Message- From: Byron Stanoszek [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 5:48 PM To: Jason Ford Cc: [EMAIL PROTECTED] Subject: Re: aacraid 2.4.0 kernel On Wed, 7 Feb 2001, Jason Ford wrote: > I see in the archives of this mailing list that someone was working on the > aacraid driver for the 2.4 kernel however that post was almost 2 months old. > I know Alan Cox denied inclusion of the driver due to the poor nature it was > written for the 2.2 tree. Every post that I have seen so far has just said > that Adaptec is working on it. However, I am sure there are many people out > there like myself that have to support this card in enviroments that would > be benifical to upgrade to 2.4 kernel. I am not a part of this list however > have been scouring through geocrawler.com archives of this list everyday for > the last month hoping and waiting. While it's totally unofficial, I have a patch for aacraid 1.0.6 for 2.4.1-ac5. I have not tested it yet, but it compiles cleanly. I'd like to hear any results (good or bad) you have on it. You can find it at: ftp://ftp.winds.org/linux/patches/2.4.1/aacraid-2.4.1-1.0.6.patch Regards, Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Bug: 2.4.0 w/ PCMCIA on ThinkPad: KERNEL: assertion(dev->ip_ptr==NULL)failed at dev.c(2422):netdev_finish_unregister
Here is a patch which may not solve the underlying
problem but which does prevent the kernel from
generating an infinite number of error messages
on "cardctl eject" and from hanging up on shutdown.
jdthood@thanatos:/usr/src/kernel-source-2.4.1-ac3/net/core# diff dev.c_ORIG dev.c
2558c2558
< while (atomic_read(>refcnt) != 1) {
---
> while (atomic_read(>refcnt) > 1) {
-
The underlying problem is that refcnt is zero or less
at this point. This is erroneous. The error in
maintaining the refcnt appears to occur only when
I configure the eth0 interface using pump or dhclient.
Be that as it may, because of the erroneous refcnt,
this while loop loops forever in the original. As
modified it falls through; and this makes the kernel
usable for me.
I hope the networking gurus can find the real bug.
Thomas Hood
> I have a bit more information about this bug now.
> The message "assertion(yadda) failed ..." occurs only
> if the eth0 interface has been configured using pump
> or dhclient. If the card isn't connected to the network
> the message never occurs. If eth0 is merely brought up
> and down using ifconfig the message doesn't occur. Only
> if pump or dhclient has configured eth0 does the message
> occur. Sometimes it occurs on "ifdown eth0", sometimes
> on "cardctl eject" and sometimes during the shutdown
> sequence.
>
> Thomas
>
> > Dear l-k.
> >
> > I'm still having this problem with kernel 2.4.0:
> >
> > Conditions:
> > Linux 2.4.0 compiled on an IBM ThinkPad 600 51U (Pentium II)
> > laptop with PCMCIA support. Same behavior with integral kernel
> > PCMCIA, modular kernel PCMCIA and modular Hinds PCMCIA. System
> > is Progeny Debian beta II.
> >
> > I have a Xircom modem/ethernet card which works correctly using
> > the serial_cs, xirc2ps_cs, ds, i82365 and pcmcia_core modules;
> > however when I try to "cardctl eject" or "reboot" I get first,
> >"KERNEL: assertion(dev->ip_ptr==NULL)failed at
> > dev.c(2422):netdev_finish_unregister"
> > (not exact since I had to copy it down on paper ... doesn't
> > show up in the logs) then a perpetual series of:
> >"unregister_netdevice: waiting for eth0 to become free.
> > Usage count = -1"
> > messages every five seconds or so. "ps -A" reveals that
> > modprobe is running; it can't be killed even with "kill -9".
> > The "ifconfig" command locks up. Shutdown won't complete
> > so I end up having to use SysRq-S-U-B to reboot.
> >
> > This problem only occurs if the Xircom card is connected to
> > the Ethernet (in which case it is configured using DHCP).
> > If the card is left unconnected to the network, the problem
> > does not occur---the card can be ejected.
> >
> > Thomas Hood
> > Please cc: your replies to me at jdthood_AT_yahoo.co.uk
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait
On Wednesday February 7, [EMAIL PROTECTED] wrote:
>
>
> On Wed, 7 Feb 2001, Christoph Hellwig wrote:
>
> > On Tue, Feb 06, 2001 at 12:59:02PM -0800, Linus Torvalds wrote:
> > >
> > > Actually, they really aren't.
> > >
> > > They kind of _used_ to be, but more and more they've moved away from that
> > > historical use. Check in particular the page cache, and as a really
> > > extreme case the swap cache version of the page cache.
> >
> > Yes. And that exactly why I think it's ugly to have the left-over
> > caching stuff in the same data sctruture as the IO buffer.
>
> I do agree.
>
> I would not be opposed to factoring out the "pure block IO" part from the
> bh struct. It should not even be very hard. You'd do something like
>
> struct block_io {
> .. here is the stuff needed for block IO ..
> };
>
> struct buffer_head {
> struct block_io io;
> .. here is the stuff needed for hashing etc ..
> }
>
> and then you make "generic_make_request()" and everything lower down take
> just the "struct block_io".
>
I was just thinking the same, or a similar thing.
I wanted to do
struct io_head {
stuff
};
struct buffer_head {
struct io_head;
more stuff;
}
so that, as an unnamed substructure, the content of the struct io_head
would automagically be promoted to appear to be content of
buffer_head.
However I then remembered (when it didn't work) that unnamed
substructures are a feature of the Plan-9 C compiler, not the GNU
Compiler Collection. (Any gcc coders out there think this would be a
good thing to add?
http://plan9.bell-labs.com/sys/doc/compiler.html
)
Anyway, I produced the same result in a rather ugly way with #defines
and modified raid5 to use 32byte block_io structures instead of the
80+ byte buffer_heads, and it ... doesn't quite work :-( it boots
fine, but raid5 dies and the Oops message is a few kilometers away.
Anyway, I think the concept it fine.
Patch is below for your inspection.
It occurs to me that Stephen's desire to pass lots of requests through
make_request all at once isn't a bad idea and could be done by simply
linking the io_heads together with b_reqnext.
This would require:
1/ all callers of generic_make_request (there are 3) to initialise
b_reqnext
2/ all registered make_request_fn functions (there are again 3 I
think) to cope with following b_reqnext
It shouldn't be too hard to make the elevator code take advantage of
any ordering that it fines in the list.
I don't have a patch which does this.
NeilBrown
--- ./include/linux/fs.h2001/02/07 22:45:37 1.1
+++ ./include/linux/fs.h2001/02/07 23:09:05
@@ -207,6 +207,7 @@
#define BH_Protected 6 /* 1 if the buffer is protected */
/*
+ * THIS COMMENT NO-LONGER CORRECT.
* Try to keep the most commonly used fields in single cache lines (16
* bytes) to improve performance. This ordering should be
* particularly beneficial on 32-bit processors.
@@ -217,31 +218,43 @@
* The second 16 bytes we use for lru buffer scans, as used by
* sync_buffers() and refill_freelist(). -- sct
*/
+
+/*
+ * io_head is all that is needed by device drivers.
+ */
+#define io_head_fields \
+ unsigned long b_state; /* buffer state bitmap (see above) */ \
+ struct buffer_head *b_reqnext; /* request queue */ \
+ unsigned short b_size; /* block size */\
+ kdev_t b_rdev; /* Real device */ \
+ unsigned long b_rsector;/* Real buffer location on disk */ \
+ char * b_data; /* pointer to data block (512 byte) */ \
+ void (*b_end_io)(struct buffer_head *bh, int uptodate); /* I/O completion */ \
+ void *b_private;/* reserved for b_end_io */ \
+ struct page *b_page;/* the page this bh is mapped to */ \
+ /* this line intensionally left blank */
+struct io_head {
+ io_head_fields
+};
+
+/* buffer_head adds all the stuff needed by the buffer cache */
struct buffer_head {
- /* First cache line: */
+ io_head_fields
+
struct buffer_head *b_next; /* Hash queue list */
unsigned long b_blocknr;/* block number */
- unsigned short b_size; /* block size */
unsigned short b_list; /* List that this buffer appears */
kdev_t b_dev; /* device (B_FREE = free) */
atomic_t b_count; /* users using this block */
- kdev_t b_rdev; /* Real device */
- unsigned long b_state; /* buffer state bitmap (see above) */
unsigned long b_flushtime; /* Time when (dirty) buffer should be written
*/
struct buffer_head *b_next_free;/* lru/free list linkage */
struct buffer_head *b_prev_free;/* doubly linked list
RE: 2.4.x and oops on 'mount -t smbfs'
Resolved! Running like a bought one now. Thanks Urban, you are so cool
that you should be in movies.
~NJ!~
> -Original Message-
> From: Urban Widmark [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, February 08, 2001 9:39 AM
> To: Jim Shaw
> Cc: [EMAIL PROTECTED]
> Subject: Re: 2.4.x and oops on 'mount -t smbfs'
>
> On Wed, 7 Feb 2001 [EMAIL PROTECTED] wrote:
>
> > I've compiled a number of 2.4.1 and 2.4.0 kernels (actually supports the
> 4GB
> > RAM!!! Yay), and I have only one more problem to sort out. Under
> > 2.4.x, the mount completes successfully, but 'ls /net' causes an OOPS:
> .
>
> Try http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.1-pre10-cache-2.patch
>
> Let me know if it works for you or not.
> (patch should be ok with 2.4.0 or 2.4.1)
>
> /Urban
JBWere Limited
DISCLAIMER
JBWere Limited and its related entities distributing this document and
each of their respective directors, officers and agents ("the Were Group")
believe that the information contained in this document is correct and that
any estimates, opinions, conclusions or recommendations contained in this
document are reasonably held or made as at the time of compilation. However,
no warranty is made as to the accuracy or reliability of any estimates,
opinions, conclusions, recommendations (which may change without notice) or
other information contained in this document and, to the maximum extent
permitted by law, the Were Group disclaims all liability and responsibility
for any direct or indirect loss or damage which may be suffered by any recipient
through relying on anything contained in or omitted from this document.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: suspecious ide hdparm results with 2.4.1 (and a minor capacity question)
>> There are two entirely different things both called LBA. >> Neither of them wastes any space. > You sure? Yes. One is the hardware disk access - all disk access is LBA these days, certainly by Linux, but if the disk is small one can also use CHS access, when it is old one has to use CHS. The other thing called LBA is a translation scheme. Translation means that the BIOS will use one set of parameters when talking to the disk, and another when talking to DOS or so. This just means that the same sector on the disk has different names. But when you partition your disk using DOS fdisk, it will want to use an integral number of "cylinders" for each partition, and for example with 8MB cylinders you may have the bad luck that the rounding costs you almost 8MB. But here each of the possible translations can be lucky or unlucky. Under Linux there is no restriction that a partition has to start on a cylinder boundary, but an integral number of blocks is used, so for example with 1KB blocks and an odd number of sectors this may cost you 512 bytes. These days one sees various (rather ugly) patches floating around just to get at this last sector. (But they are unnecessary, I think.) Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] aic7xxx panic Re: Linux 2.4.1-ac5
"J . A . Magallon" wrote: > > On 02.07 Tigran Aivazian wrote: > > Alan, Doug, > > > > If this is a known problem -- ignore. Otherwise, I will gladly assist as > > much as you need. > > > > Just tried ac5 kernel and, behold (btw, why does serial console not work > > anymore, I had to copy these by hand): > > > > (scsi0) BRKADRINT error(0x44): > > Illegal Opcode in sequencer program > > PCI Error detected > > (scsi0) SEQADDR=0x58 > > Kernel panic: aic7xxx: unrecoverable BRKADRINT > > > > The Linux 2.4.2-pre1 works fine. Next thing I was thinking was to try ac4 > > and also to try on a different machine which has a different revision of > > the same type of aic7xxx HBA. > > > > I am running ac5 on a AHA-2940U2/W, no problem. > > I patched the kernel with a patch from Doug Ledford posted in the list. Problems with disks and CD-ROMs connected to non-Ultra2 controllers is confirmed and I think my fix is just about done (currently testing a minor sequencer change to solve the problem, I cleared SG_COUNT when I shouldn't have, which meant disconnects in the middle of a transfer spelled death for the transfer, resulting in a data overrun on reconnect, and this problem only shows up on non-Ultra2 controllers under real transfers scenarios, which my testing missed because I was using all Ultra2 controllers, so I built another test machine with non-Ultra2 controllers to check my fix) -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Mailing lists for Linux on OS/390?
We are starting to look at setting up a test environment for Linux on OS/390 platforms (probably using VM/VSE). Does anyone know of any good mail-lists or usenet groups et al that would be specific to this type of porting/running on this platform? Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs] SPEC SFS fails at low loads...
On Wednesday, February 07, 2001 04:35:32 PM + Tigran Aivazian <[EMAIL PROTECTED]> wrote: > Hi, > > Under 2.4.1, after a little bit of running SPEC SFS (with NFSv3) I get > these messages on the server: > > vs-13042: reiserfs_read_inode2: [0 1 0x0 SD] not found > vs-13048: reiserfs_iget: bad_inode. Stat data of (0 1) not found > vs-13048: reiserfs_iget: bad_inode. Stat data of (0 1) not found > vs-13048: reiserfs_iget: bad_inode. Stat data of (0 1) not found > > and the run aborts. > > Any clues? Andi covered most of the details, you can get a combined version of patches from Neil Brown and I at ftp.reiserfs.org, which I can't seem to get to right now. If you want a copy, I can send along in private mail. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs - problems mounting after power outage
On Wednesday, February 07, 2001 12:31:43 PM -0500 Jeff McWilliams <[EMAIL PROTECTED]> wrote: > I'm having difficulty mounting a reiserfs partition after a power outage. > > This is 2.4.0-test9 compiled with reiserfs as a module, and Which reiserfs version is this? Upgrading to the reiserfs included in 2.4.1 would be a good plan, there have been a few bug fixes since test9 times (none specfically related to this). > the ide.2.4.0-t9-6.task.0923.path IDE patch - mostly to get updated support for > the 3WARE IDE RAID controller. > If this raid controller has writeback cache, make sure you either have a battery backup for the cache, or have writeback turned off. > /dev/sda is the 3ware escalade raid mirror - two Maxtor 20 gig drives. > > reiserfs is compiled as a module, the distribution is Debian Linux > "Potato" > [ ... ] > The partition I'm having trouble with is /dev/sda7. /dev/sda6 recovered okay. > /dev/sda7 doesn't have a lot of data on it, and I CAN deal with the lost data, > but it doesn't leave me with a very good feeling of confidence in reiserfs > if I can't successfully recover from a power failure. > > > What happens when I type mount /dev/sda7 is this: > > reiserfs: using 3.5.x disk format > reiserfs: checking transaction log (device 08:07) ... > > and then it hangs. I then have to hit the reset button to reboot. > How hung is it? Does the whole system stop, or does this mount just block forever? > I've tried running reiserfsck with --check, --correct-bitmap, > --rebuild-sb, and --rebuild-tree. NO luck there. > These programs also hang? Does reiserfsck (which version BTW) give any output at all? -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x and oops on 'mount -t smbfs'
On Wed, 7 Feb 2001 [EMAIL PROTECTED] wrote: > I've compiled a number of 2.4.1 and 2.4.0 kernels (actually supports the 4GB > RAM!!! Yay), and I have only one more problem to sort out. Under > 2.4.x, the mount completes successfully, but 'ls /net' causes an OOPS: . Try http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.1-pre10-cache-2.patch Let me know if it works for you or not. (patch should be ok with 2.4.0 or 2.4.1) /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] aic7xxx panic Re: Linux 2.4.1-ac5
On 02.07 Tigran Aivazian wrote: > Alan, Doug, > > If this is a known problem -- ignore. Otherwise, I will gladly assist as > much as you need. > > Just tried ac5 kernel and, behold (btw, why does serial console not work > anymore, I had to copy these by hand): > > (scsi0) BRKADRINT error(0x44): > Illegal Opcode in sequencer program > PCI Error detected > (scsi0) SEQADDR=0x58 > Kernel panic: aic7xxx: unrecoverable BRKADRINT > > The Linux 2.4.2-pre1 works fine. Next thing I was thinking was to try ac4 > and also to try on a different machine which has a different revision of > the same type of aic7xxx HBA. > I am running ac5 on a AHA-2940U2/W, no problem. I patched the kernel with a patch from Doug Ledford posted in the list. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.1-ac5 #1 SMP Wed Feb 7 22:15:19 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA silent disk corruption - patch
On Tue, Feb 06, 2001 at 05:01:46PM +0100, Udo A. Steinberg wrote: > Dale Farnsworth wrote: > > > > However, if I enable the BIOS parameter "I/O Recovery Time", I can still > > enable read caching without seeing any data corruption. > > The lastest BIOS revision (1005C) enables "I/O Recovery Time" by default > > where the previous revision I had (1004D) did not. > > Interesting stuff. > > Asus, Germany released 1005D today. It's available from > ftp://ftp.asuscom.de/pub/ASUSCOM/BIOS/Socket_A/VIA_Chipset/Apollo_KT133/A7V/1005D.zip > > No comments about what they changed and/or fixed. > Good news here, looks like the new BIOS fixes it (1005D). I've run a heavy test for at least 10 hours without a single blip. The BIOS is set for "optimal". Hoorah! Here's the North bridge diff for anyone who can't get a BIOS update :-) P. --- bad.pci Sun Feb 4 22:29:22 2001 +++ new.pci Wed Feb 7 23:11:28 2001 @@ -1,7 +1,7 @@ 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- - Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- http://www.tux.org/lkml/
Re: [reiserfs] SPEC SFS fails at low loads...
Tigran Aivazian <[EMAIL PROTECTED]> writes: > Hi, > > Under 2.4.1, after a little bit of running SPEC SFS (with NFSv3) I get > these messages on the server: > > vs-13042: reiserfs_read_inode2: [0 1 0x0 SD] not found > vs-13048: reiserfs_iget: bad_inode. Stat data of (0 1) not found > vs-13048: reiserfs_iget: bad_inode. Stat data of (0 1) not found > vs-13048: reiserfs_iget: bad_inode. Stat data of (0 1) not found > > and the run aborts. > > Any clues? Reiserfs really needs 64bit of inode in the NFS file handles, otherwise this happens as soon as you run out of the file handle cache with many active clients. The 2.2 code did a brute force search in this case (the handles are unique in 32bit, it's just very costly to look them up without the other 32bit), but it usually consumed so much CPU time that people thought the server crashed. There are patches to do that for knfsd for both 2.2 and 2.4, but they haven't been merged yet. It needs a small VFS enhancement and knfsd changes. Note that stock (unpatched) unfsd also doesn't work in all cases for other reasons, it makes assumptions about the inode space that do not work out on a longer used reiserfs. This has also been fixed. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Remaining net/ pci_enable_device cleanups.
Hi Jeff, l-k,
Here's my current diff resynced against ac5. This catches
all the remaining cases in drivers/net except for starfire
(which you posted a bigger patch for).
Oh, there's also a kmalloc change in macsonic.c that I've
had hanging around for a while.
If this looks ok, I'll split it into chunks for Alan & the
appropriate maintainers.
regards,
Dave.
--
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs
diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/defxx.c
linux-dj/drivers/net/defxx.c
--- linux/drivers/net/defxx.c Wed Feb 7 21:55:56 2001
+++ linux-dj/drivers/net/defxx.cWed Feb 7 22:34:27 2001
@@ -393,6 +393,7 @@
*
* Arguments:
* pdev - pointer to pci device information (NULL for EISA)
+ * ioaddr - pointer to port (NULL for PCI)
*
* Functional Description:
*
@@ -426,6 +427,13 @@
*/
dev = init_fddidev( NULL, sizeof(*bp));
+ /* Enable PCI device. */
+ if (pdev != NULL) {
+ if (pci_enable_device (pdev))
+ goto err_out;
+ ioaddr = pci_resource_start (pdev, 1);
+ }
+
if (!dev) {
printk (KERN_ERR "defxx: unable to allocate fddidev, aborting\n");
return -ENOMEM;
@@ -461,8 +469,6 @@
bp->bus_type = DFX_BUS_TYPE_PCI;
bp->pci_dev = pdev;
pdev->driver_data = dev;
- if (pci_enable_device (pdev))
- goto err_out_region;
pci_set_master (pdev);
}
@@ -481,7 +487,7 @@
static int __devinit dfx_init_one(struct pci_dev *pdev, const struct pci_device_id
*ent)
{
- return dfx_init_one_pci_or_eisa(pdev, pci_resource_start (pdev, 1));
+ return dfx_init_one_pci_or_eisa(pdev, NULL);
}
static int __init dfx_eisa_init(void)
diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/dgrs.c
linux-dj/drivers/net/dgrs.c
--- linux/drivers/net/dgrs.cWed Feb 7 21:55:56 2001
+++ linux-dj/drivers/net/dgrs.c Wed Feb 7 22:17:37 2001
@@ -1368,6 +1368,17 @@
while ((pdev = pci_find_device(SE6_PCI_VENDOR_ID, SE6_PCI_DEVICE_ID,
pdev)) != NULL)
{
+ /*
+* Get and check the bus-master and latency values.
+* Some PCI BIOSes fail to set the master-enable bit,
+* and the latency timer must be set to the maximum
+* value to avoid data corruption that occurs when the
+* timer expires during a transfer. Yes, it's a bug.
+*/
+ if (pci_enable_device(pdev))
+ continue;
+ pci_set_master(pdev);
+
plxreg = pci_resource_start (pdev, 0);
io = pci_resource_start (pdev, 1);
mem = pci_resource_start (pdev, 2);
@@ -1391,17 +1402,6 @@
pci_write_config_dword(pdev, 0x30, plxdma + 1);
pci_read_config_dword(pdev, 0x30, );
plxdma &= ~15;
-
- /*
-* Get and check the bus-master and latency values.
-* Some PCI BIOSes fail to set the master-enable bit,
-* and the latency timer must be set to the maximum
-* value to avoid data corruption that occurs when the
-* timer expires during a transfer. Yes, it's a bug.
-*/
- if (pci_enable_device(pdev))
- continue;
- pci_set_master(pdev);
dgrs_found_device(io, mem, irq, plxreg, plxdma);
diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/dmfe.c
linux-dj/drivers/net/dmfe.c
--- linux/drivers/net/dmfe.cWed Feb 7 21:55:56 2001
+++ linux-dj/drivers/net/dmfe.c Wed Feb 7 22:18:18 2001
@@ -356,6 +356,11 @@
DMFE_DBUG(0, "dmfe_probe()", 0);
+ /* Enable Master/IO access, Disable memory access */
+ if (pci_enable_device(pdev))
+ goto err_out;
+ pci_set_master(pdev);
+
pci_iobase = pci_resource_start(pdev, 0);
pci_irqline = pdev->irq;
@@ -371,11 +376,6 @@
printk(KERN_ERR "dmfe: I/O base is zero\n");
goto err_out;
}
-
- /* Enable Master/IO access, Disable memory access */
- if (pci_enable_device(pdev))
- goto err_out;
- pci_set_master(pdev);
#if 0 /* pci_{enable_device,set_master} sets minimum latency for us now */
diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/eepro100.c
linux-dj/drivers/net/eepro100.c
--- linux/drivers/net/eepro100.cWed Feb 7 21:55:56 2001
+++ linux-dj/drivers/net/eepro100.c Wed Feb 7 22:00:35 2001
@@ -557,6 +557,17 @@
if (speedo_debug > 0
Re: bidirectional named pipe?
Alan Cox wrote: > > > I'm porting some software to Linux that requires use of a bidirectional, > > named pipe. The architecture is as follows: A server creates a named pipe > > Pipes are not bidirectional in Linux. We follow traditional non stream > behaviour > > > /dev/spx". I experiemented with socket-based pipes under Linux, but I > > couldn't gain access to them by open()ing the name. Is there help? I > > AF_UNIX sockets are bidirectional but like all sockets use bind() and > connect(). How hard would it be to add? The limitation on fifos that you get the same one every time you open it makes some things tricky -- the server has to move the fifo and mkfifo a new one to replace its data with something else, for instance, which is not atomic. I don't understand, in the original problem, how the server opens the named bipipe differently from the servers, to be on one end rather than the other. A way to map a file name to a socket pair would be nice, the first to open it could get one end of it and everyone else would get the other end, or there would be a switch. You could patch the file system code, I wonder how deep the changes would have to be, if you did it in terms of lots of fifos. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aacraid 2.4.0 kernel
On Wed, 7 Feb 2001, Jason Ford wrote: > I see in the archives of this mailing list that someone was working on the > aacraid driver for the 2.4 kernel however that post was almost 2 months old. > I know Alan Cox denied inclusion of the driver due to the poor nature it was > written for the 2.2 tree. Every post that I have seen so far has just said > that Adaptec is working on it. However, I am sure there are many people out > there like myself that have to support this card in enviroments that would > be benifical to upgrade to 2.4 kernel. I am not a part of this list however > have been scouring through geocrawler.com archives of this list everyday for > the last month hoping and waiting. While it's totally unofficial, I have a patch for aacraid 1.0.6 for 2.4.1-ac5. I have not tested it yet, but it compiles cleanly. I'd like to hear any results (good or bad) you have on it. You can find it at: ftp://ftp.winds.org/linux/patches/2.4.1/aacraid-2.4.1-1.0.6.patch Regards, Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OK to mount multiple FS in one dir?
Peter Samuelson wrote: > A more useful thing to fall out of the same hacking is loopback > mounting -- i.e. the same filesystem mounted multiple places. In > Linux-land I guess we call it 'mount --bind'. > > Peter Does this kind of thing play nice with nfs and coda, in terms of change notifications and write-backs? In distributed FS we've got the same thing mounted multiple places, of course, but not on the same machine -- David Nicol 816.235.1187 [EMAIL PROTECTED] Pedestrians always have the right of way - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.1-ac5 - The loopback hang saga continues
It appears that the loopback-hang parasite is alive and well in 2.4.1-ac5. I've done several tests and I thus provide the following information: The bug is independent of UP or SMP configured.. it hung both ways, but the box itself is UP. It appears to hang when internal buffers get filled. The way I see it, copying files from disk to the loopback device (which is a file on the same disk) begins to read from the disk. When the internal read buffer is full, the kernel's queued writes start activating and the data gets copied to the loopback file. This process repeats over and over, as it should normally. Sometimes however, during a read from the disk, it fills up its buffers and then never makes the accompanying write. In fact, the entire device freezes on the read. I was able to lessen the frequency of hanging by using the -v flag and tapping ^S and ^Q to temporarily 'pause' copying. This ensures that the read buffer will never become full to the point where it could cause the hang, and appears to work -- until it came across the libc.a file. There was no way to pause it here because nothing is being outputted to the screen while it's copying libc.a. Unfortunately, it fills the buffer too quick and hangs 100% every time. The disk is totally nonresponsive at this point, and a hard reset is necessary. I hope this helps anyone who is still tracking down the loopback problem. Regards, Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: suspecious ide hdparm results with 2.4.1 (and a minor capacity question)
On Wed, Feb 07, 2001 at 06:44:34PM +0100, [EMAIL PROTECTED] wrote: > > It's currently in LBA mode (I believe) and that, to my knowledge, > > wastes the most space. > > There are two entirely different things both called LBA. > Neither of them wastes any space. You sure? I admit to not having much knowledge of this but BIOS always reports different sized for LBA, NORMAL and LARGE. This is what I'm referring to. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: hotplugging with regular PCI cards
It looks like support for this is available at: http://opensource.compaq.com/sourceforge/project/?group_id=13 -Jamey Hicks -Original Message- From: Adam J. Richter [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 1:08 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: hotplugging with regular PCI cards I saw an interesting demonstration at LinuxWorld last week. Compaq had a machine that did hot plugging with regular PCI cards (not Compact PCI). If anyone out there is familiar with this machine, I would be interested in knowing what the status is on getting the support for that backplain integrated into the stock kernels. When that occurs, that will be yet another reason to treat all new style PCI drivers as potentially hot pluggable, even if those cards are not currently available in a CardBus or CompactPCI form, and in particular to change all of the xxx_pci_tbl declarations in PCI drivers that are currently marked as __initdata back to __devinitdata. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." ___ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1 and Adaptec Duralan aka Starfire.c
On Wed, 07 Feb 2001 11:48:32 +0100, Stefan Majer <[EMAIL PROTECTED]> wrote: > Hi All > > I installed a Adaptec Quad Port Ethernet Adapter called Quartet64 and > after compiling 2.4.1 > with starfire support i got the following messages in syslog > > after > > ifconfig eth2 172.17.1.4 netmask 255.255.0.0 up > > Feb 7 11:37:29 cerro kernel: eth2: Internal fault: The skbuff addresses > do not match in netdev_rx: 242749457 vs. ce781000 / ce781010. These are harmless, although very annoying. Use the driver from 2.4.1-acXX, it has this and other things fixed. Just copy starfire.c into your tree/drivers/net, it will work fine. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
aacraid 2.4.0 kernel
I see in the archives of this mailing list that someone was working on the aacraid driver for the 2.4 kernel however that post was almost 2 months old. I know Alan Cox denied inclusion of the driver due to the poor nature it was written for the 2.2 tree. Every post that I have seen so far has just said that Adaptec is working on it. However, I am sure there are many people out there like myself that have to support this card in enviroments that would be benifical to upgrade to 2.4 kernel. I am not a part of this list however have been scouring through geocrawler.com archives of this list everyday for the last month hoping and waiting. Does anyone know the status of the driver or even the possibilities of it getting included into the next kernel version (2.4.2)? Please CC me on any replies that you may send. Thanks for you time.. Jason Ford [EMAIL PROTECTED] Heymax Interactive http://www.heymax.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Hamachi not doing pci_enable before reading resources
On Wed, 7 Feb 2001, [ISO-8859-1] Gérard Roudier wrote: > > You missed the newer statements about every piece of hardware being > assumed to be hot-pluggable and all the hardware being under full control > by CPU. > > You also missed the well known point that only device drivers are broken > under Linux and that all the generic O/S code is just perfect. :-) > > Gérard. > Yep. I missed a lot. When the next 'release' comes out, I'll have to rewrite all my drivers again --sigh... Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Wednesday, February 07, 2001 11:05:51 PM +0100 Xuan Baldauf <[EMAIL PROTECTED]> wrote: > Mhhh. It's a busy server from which I am about 700km away. I don't like to > restart it now. (Especially because it cannot boot from hard disk, only > from floppy disk, due to bios problems). But I'd be happy if following is > true: > > (1) Enabling "-o notails" is possible at runtime, i.e. "mount / -o > remount,notails" works and Nope. > (2) Notails is compatible with all the tails found on disk (so notails > only changes the way the disk is written, not the way the disk is read). > This part is true. Honestly, I don't want to do this kind of debugging on a busy server. Sure, it is completely safe, etc, etc, but ... We'll get the info elsewhere, leave the busy servers out of it ;-) -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Lock in with 2.4.1 and NFS
On Wednesday February 7, [EMAIL PROTECTED] wrote: > > Hi, > I have a strange problem on one of our server. > I have 2.4.1 patched with ACLs 0.7.5 (from acl.bestbits.at) and some RAID + > LVM volumes. > At regular interval, NFS stops working (nfsd stops) and a stop/start of the > NFS service doesn't work. > The NFS service stop blocks in "exportfs -auv" when trying to unmount a > client working apparently well. One time > it was a solaris 2.6 client, another time it was a linux 2.4 machine. > Any help appreciated. > Thanks > -jec > > PS: I'm not in the kernel list. Please CC > This scenario sounds a lot like one of the nfsd threads has oopsed while holding a readlock on the export table, and so exportfs cannot get a write lock. Could you check your kernel logs for an Oops message? NeilBrown > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > Jean-Eric Cuendet > Linkvest SA > Av des Baumettes 19, 1020 Renens Switzerland > Tel +41 21 632 9043 Fax +41 21 632 9090 > http://www.linkvest.com E-mail: [EMAIL PROTECTED] > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[bug] aic7xxx panic Re: Linux 2.4.1-ac5
Alan, Doug, If this is a known problem -- ignore. Otherwise, I will gladly assist as much as you need. Just tried ac5 kernel and, behold (btw, why does serial console not work anymore, I had to copy these by hand): (scsi0) BRKADRINT error(0x44): Illegal Opcode in sequencer program PCI Error detected (scsi0) SEQADDR=0x58 Kernel panic: aic7xxx: unrecoverable BRKADRINT The Linux 2.4.2-pre1 works fine. Next thing I was thinking was to try ac4 and also to try on a different machine which has a different revision of the same type of aic7xxx HBA. Any more ideas? Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Chris Mason wrote: > On Thursday, February 08, 2001 10:47:29 AM +1300 Chris Wedgwood > <[EMAIL PROTECTED]> wrote: > > > these appear on your system every couple of days right? if so... are > > you able to run with the fs mount notails for a couple of days and > > see if you still experience these? > > > > my guess is you probably still will as most log files aren't > > candidates for tail-packing (too large) but it will help eliminate > > one more thing > > > > Yes, it really would. > > 1) mount -o notail > 2) rm old_logfile > 3) restart syslog > > This will ensure the log files don't have tails at all. Knowing for sure > the bug doesn't involve tails would remove much code from the search. > > -chris Mhhh. It's a busy server from which I am about 700km away. I don't like to restart it now. (Especially because it cannot boot from hard disk, only from floppy disk, due to bios problems). But I'd be happy if following is true: (1) Enabling "-o notails" is possible at runtime, i.e. "mount / -o remount,notails" works and (2) Notails is compatible with all the tails found on disk (so notails only changes the way the disk is written, not the way the disk is read). Is this true? Xuân. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Thursday, February 08, 2001 10:47:29 AM +1300 Chris Wedgwood <[EMAIL PROTECTED]> wrote: > these appear on your system every couple of days right? if so... are > you able to run with the fs mount notails for a couple of days and > see if you still experience these? > > my guess is you probably still will as most log files aren't > candidates for tail-packing (too large) but it will help eliminate > one more thing > Yes, it really would. 1) mount -o notail 2) rm old_logfile 3) restart syslog This will ensure the log files don't have tails at all. Knowing for sure the bug doesn't involve tails would remove much code from the search. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Hamachi not doing pci_enable before reading resources
You missed the newer statements about every piece of hardware being assumed to be hot-pluggable and all the hardware being under full control by CPU. You also missed the well known point that only device drivers are broken under Linux and that all the generic O/S code is just perfect. :-) Gérard. On Wed, 7 Feb 2001, Richard B. Johnson wrote: > On Wed, 7 Feb 2001 [EMAIL PROTECTED] wrote: > > > > > Hi Alan, > > > > Another driver not doing pci_enable_device() early enough. > > > > Dave. > > > > A PCI device does not and should not be enabled to probe for resources! > It is only devices that have BIOS that require the device to be enabled > for memory I/O prior to downloading the BIOS into RAM. The BARs are > read/writable (and are required to be), even when the Mem/I/O bits > in the cmd/status register are clear. > > This is a required condition! You certainly don't want to write all > ones to a decode (to find the resource length) of a live, on-line chip! > If the chip hickups (think network chips connected to networks, on a > warm-boot), you will trash lots of stuff in memory. > > It looks as though you are "fixing" drivers that are not broken and, > in fact, are trying to do the right thing. Maybe the PCI code in the > kernel is preventing access to resources unless the device has been > enabled??? If so, it's broken and should be fixed, instead of all > the drivers. > > Cheers, > Dick Johnson > > Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). > > "Memory is like gasoline. You use it up when you are running. Of > course you get it all back when you reboot..."; Actual explanation > obtained from the Micro$oft help desk. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] micro-opt DEBUG_ADD_PAGE
On Wed, 7 Feb 2001, Hugh Dickins wrote: > > The "(1< activate_page_nolock() compiled -O2 -march=i686 with egcs-2.91.66 (RH7.0 > kgcc), gcc-2.96-69 (RH7.0 gcc+fixes), gcc-2.97 (gcc-snapshot-20010207-1). > > None of those optimizes this: I believe the semantics of "||" (don't > try next test if first succeeds) forbid the optimization "|" gives? No. The optimization is entirely legal - but the fact that "constant_test_bit()" uses a "volatile unsigned int *" is the reason why gcc thinks it can't optimize it. Oh, well. That "volatile" is really totally bogus. But it's there because there are probably drivers that do while (test_bit(...)) /* nothing */; and the compiler woul doptimize it away a bit too much without the volatile. Dang. You could try to remove the volatile from test_bit, and see if that fixes it - but then we'd have to find and add the proper "rmb()" calls to people who do the endless loop kind of thing like above. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
VT82C597 + Maxtor UDMA failures
I'm trying to troubleshoot a failure with my Maxtor hard drive that I have
experienced consistantly, even in the 2.2.x kernels (I'm now running
2.2.1-test10, .config is attached). It detects all of my drives fine:
block: queued sectors max/low 126786kB/95090kB, 384 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c586b IDE UDMA33 controller on pci0:7.1
ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA
hda: Maxtor 52049U4, ATA DISK drive
hdb: WDC AC31200F, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
hdc: Maxtor 90680D4, ATA DISK drive
hdd: ATAPI 40X CDROM DRIVE, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 40020624 sectors (20491 MB) w/2048KiB Cache, CHS=2491/255/63,
UDMA(33)
hdb: 2503872 sectors (1282 MB) w/64KiB Cache, CHS=621/64/63, DMA
hdc: 13281408 sectors (6800 MB) w/256KiB Cache, CHS=13176/16/63, UDMA(33)
hdd: ATAPI 40X CD-ROM drive, 128kB Cache, UDMA(33)
And then all the services load up, etc. Once I log in, though, either in
gdm or on the console, it will pause for around 10-15 seconds, and then
display this:
hdc: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: status timeout: status=0xd0 { Busy }
hdc: DMA disabled
hdd: DMA disabled
hdc: drive not ready for command
ide1: reset: success
(hdc is the problem, obviously) Once this occurs, the system appears to
run normally. I don't really care about hdd (cdrom), although I figure
they are probably related somehow.
Windows is able to use UDMA fine on this drive. Also note that this isn't
a UDMA66 drive, and I'm not trying to use it (most of the other posts
I've seen with similar problems were related to 66).
Drives on ide0 seem to run in udma mode just fine, also...
Here's /proc/ide/via:
--VIA BusMastering IDE Configuration
Driver Version: 2.1e
South Bridge: VIA vt82c586b rev 0x47
Command register: 0x7
Latency timer: 64
PCI clock: 33MHz
Master Read Cycle IRDY:1ws
Master Write Cycle IRDY:1ws
FIFO Output Data 1/2 Clock Advance: off
BM IDE Status Register Read Retry: on
Max DRDY Pulse Width: No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush: on on
End Sect. FIFO flush: on on
Prefetch Buffer: on on
Post Write Buffer: on on
FIFO size: 8 8
Threshold Prim.: 1/2 1/2
Bytes Per Sector: 512 512
Both channels togth: yes yes
---drive0drive1drive2drive3-
BMDMA enabled:yes yesnono
Transfer Mode: UDMA DMA/PIO UDMA UDMA
Address Setup: 30ns 60ns 30ns 30ns
Active Pulse:90ns 90ns 90ns 90ns
Recovery Time: 30ns 60ns 30ns 30ns
Cycle Time: 60ns 150ns 60ns 60ns
Transfer Rate: 33.0MB/s 13.2MB/s 33.0MB/s 33.0MB/s
What I don't understand is, the transfer mode still seems to be "UDMA",
but "BMDMA" is not enabled. Aren't they inter-dependant? One in the
same? I'm obviously no expert, so any help would be appreciated.
Thanks in advance,
Ryan
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
CONFIG_MK6=y
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
#
Re: 2.4.0 pdev_enable_device() call in setup-bus.c
Ivan Kokshaysky wrote:
> Mainly because there are driverless devices like display adapters,
> PCI bridges, or PCI devices with legacy drivers (IDE, for example).
Ok. It seems that all of those would have to interact with
the PCI code someplace. And that's were pci_enable_device()
could be called. eg. PCI Bridges could be handled in it's
"driver": pci_setup_bridge().
> OTOH, pdev_enable_device() most likely will be removed, but
> it's 2.5 material.
Agreed - standardizing the enable path would be good for above devices.
I'd like to see arch hooks added for stuff like default latency and
PCI_BRIDGE_CONTROL. My gut feeling is the "root" struct pci_bus
allocation and initialization should be done by arch specific code
*before* pci_scan_bus() is called. That would allow cfg space defaults
to be set to arch specific values on a per bus basis *before* doing
the bus walks instead of hacking this in pci_bus_fixup() later.
thanks,
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: having a hard time with 2.4.x
While attempting to port Linux to a new platform using a compiler other
then GCC I noticed that there appears to be a volatile missing on the
declaration of xtime in include/linux/sched.h. The compiler I am using
considers this to be an error. The following may help your problem.
include/linux/sched.h
*** sched.h 2001/02/05 21:48:10 1.3
--- sched.h 2001/02/07 05:19:09
***
*** 533,539
extern unsigned long volatile jiffies;
extern unsigned long itimer_ticks;
extern unsigned long itimer_next;
! extern struct timeval xtime;
extern void do_timer(struct pt_regs *);
extern unsigned int * prof_buffer;
--- 533,539
extern unsigned long volatile jiffies;
extern unsigned long itimer_ticks;
extern unsigned long itimer_next;
! extern volatile struct timeval xtime;
extern void do_timer(struct pt_regs *);
Ulrich Windl writes:
>
> Hello,
>
> I have some news on the topic of timekeeping in Linux-2.4:
>
> As Alan Cox pointed out the ACPI changes between 2.4.0 and 2.4.1 created a
> extremely slow console output (if not more). Configuring away ACPI support
> solved that problem.
>
> However there is still a problem that I cannot explain. I wrote a test program
> for my modified kernel (I did not try the original one). I'll include the
> program plus results (if you want to see the patch go to
> ftp.kernel.org/pub/linux/daemons/ntp/PPS and get PPS-2.4.0-pre3.tar.bz2 (patch
> plus signature)):
>
> #include
> #include
> #define NTP_NANO
> #include
>
> int main()
> {
> struct timextx;
> longlastns = 0;
>
> tx.modes = 0;
> while(1)
> {
> adjtimex();
> printf("%d %d %d\n",
> tx.time.tv_sec, tx.time.tv_nsec,
> tx.time.tv_nsec - lastns);
> lastns = tx.time.tv_nsec;
> fflush(stdout);
> }
> }
--
Steve Piatz [EMAIL PROTECTED]
Cray Inc. 651-605-9049
1340 Mendota Heights Road
Mendota Heights, MN 55120
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: single copy pipe/fifo
Manfred Spraul writes: > process 2 (on cpu 1) > read(fd,buf,64kB). > * reads the data > * now it must wake up, but it will return from the syscall, thus > wake_up_interruptible(). Oh, I see and thus the pre-kiovec case would be: process 2 (on cpu 1) read(fd, buf,64kb) * reads 4K * wake_up_interruptible_sync() * sleep() * reads 4K etc etc. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0 pdev_enable_device() call in setup-bus.c
On Wed, Feb 07, 2001 at 11:50:52AM -0800, Grant Grundler wrote: > Can you explain why pci_assign_unassigned_resources() > calls pdev_enable_device() for every PCI device instead > of having each PCI *driver* call pci_enable_device() > as part of driver initialization? Mainly because there are driverless devices like display adapters, PCI bridges, or PCI devices with legacy drivers (IDE, for example). OTOH, pdev_enable_device() most likely will be removed, but it's 2.5 material. Ivan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: single copy pipe/fifo
"David S. Miller" wrote: > > Manfred Spraul writes: > > * if you run 2 instances on a dual cpu P II/350 it's a big win, but if > > you run only one instance, then the bw_pipe processes will jump from one > > cpu to the other and it's only a small improvement (~+15%). > > wake_up_interruptible_sync is meant specifically to avoid > this cpu hopping behavior. > I use it whereever possible, but in this case it's not possible: pipe is empty. process 1 (on cpu 1) write(fd,buf,64kB). * creates kiobuf * sleeps. process 2 (on cpu 1) read(fd,buf,64kB). * reads the data * now it must wake up, but it will return from the syscall, thus wake_up_interruptible(). * wakeup notices that cpu1 is busy and sends process 1 to cpu 2 * read returns read(fd, buf, 64kB) * no data waiting, sleeps. process 1 (on cpu 2) * write returns write(fd, buf, 64 kB) * creates kiobuf * wake_up_interruptible_sync(), since it will schedule * schedule() but now schedule will pull process 2 to cpu 2 I haven't verified the sequence with kdb, but I'm certain that this happens. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.1-ac5
On Wed, 7 Feb 2001, Matthias Schniedermeyer wrote: > > > now that -ac grows that huge, could you put out incremental patches? > > > > Takes me too much time. But if anyone else wants to, go ahead > > This is what i use to diff 2 different kernels > > - snip - >... > - snip - > > This takes about 8 seconds (for 2.4 kernels) on my Dual PIII-933, 1Gig-RAM Or you take the two patches and use interdiff [1]. > Bis denn cu, Adrian [1] http://people.redhat.com/twaugh/ftp/interdiff/stable/ -- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG] 2.4.x SMP kernel breaks legacy PIC interrupts 13/2
Dear Mr. Molnar, Could you please take a look at this issue ? Also, if you could cc: me on a possible reply, since I am not subscribed to the mailing list... Thanks in advance, Christoph Schmitz --- The symptom: Compaq leverages IRQ 13, usually used to raise a floating point exception on Intel pre-Pentium systems, to trigger management interrupts (i.e. on fan failure, etc.). This interrupt level is usually NOT shareable, but through some magic, we managed to register an ISR for our management driver on IRQ 13. In the kernel 2.2.x, this worked fine for both SMP and UP kernels. On the 2.4.x SMP kernels, we do NOT get any interrupts when using request_irq() for IRQ 13. Debugging: If you boot the SMP kernel with the 'noapic' parameter, the interrupt works fine. We are aware that IRQ 2 and IRQ 13 will be always routed through the legacy 8259A PIC as opposed to the IO-APIC. If we change the kernel to route IRQ 13 through the APIC, everything works fine. Furthermore, if we route any other working interrupt through the PIC, it does not work. It appears to be related to putting the PIC into auto-EOI mode. The 2.4 SMP kernel puts the PIC in auto-EOI mode while setting up the timer interrupt. See init_8259A(1) in the check_timer routine in arch/i386/kernel/io_apic.c. Conclusion: PIC and APIC routed interrupts do not coexist peacefully in the 2.4.x SMP kernel. We need to figure out why PIC interrupts don't work with the APIC interrupts enabled, or stop forcing IRQ 2 and 13 to the PIC when APIC interrupts are enabled. As it is right now, you will never see an IRQ 2 or 13 while in APIC mode on the 2.4.x SMP kernel, which makes the code carefully preserving PIC interrupts superfluous. If fixing this kernel flaw turns out to be too involved, at the very least, we would like to suggest the code forcing IRQ's 2 and 13 onto the PIC be removed from the 2.4 kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA silent disk corruption - likely fix
On Mon, 05 Feb 2001, Peter Horton wrote: > I've found the cause of silent disk corruption on my A7V motherboard, > and it might affect all boards with the same North bridge (KT133 etc). ... > [1] the BIOS appears to let you change the option but it defaults the > option the moment you leave the "advanced settings" screen :-( Is your BIOS current? Gigabyte 7ZXR BIOSes (F4) e. g. have exhibited not-so-different troubles (once you set a suspend timeout, you could not reset it lest you reloaded the entire BIOS anew; with American Megatrends' BIOS this means you lose ALL settings except your Standard CMOS setup), this problem is fixed in F5J (I did not bother to look for an official F5 release yet). -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/media/radio/radio-maxiradio.c - 2.4.1-ac4
Thanks for the trouble.
Your patch had some problem in the maxiradio_radio_init function as
pci_register_driver returns the number of devices found and not 0 when
succesful. I fixed it and here is my patch against the original driver.
Diff output is still weird.
--- radio-maxiradio.c.orig Wed Feb 7 00:27:37 2001
+++ radio-maxiradio.c Wed Feb 7 22:50:12 2001
@@ -17,6 +17,9 @@
*
*
* CHANGES:
+ * 0.75b
+ * - better pci interface thanks to Francois Romieu <[EMAIL PROTECTED]>
+ *
* 0.75
* - tiding up
* - removed support for multiple devices as it didn't work anyway
@@ -309,80 +312,80 @@
MOD_DEC_USE_COUNT;
}
-
-inline static __u16 radio_install(struct pci_dev *pcidev);
-
MODULE_AUTHOR("Dimitromanolakis Apostolos, [EMAIL PROTECTED]");
MODULE_DESCRIPTION("Radio driver for the Guillemot Maxi Radio FM2000 radio.");
EXPORT_NO_SYMBOLS;
-void __exit maxiradio_radio_exit(void)
+static int __devinit maxiradio_init_one(struct pci_dev *pdev, const struct
+pci_device_id *ent)
{
- video_unregister_device(_radio);
+ if(!request_region(pci_resource_start(pdev, 0),
+ pci_resource_len(pdev, 0), "Maxi Radio FM 2000")) {
+ printk(KERN_ERR "radio-maxiradio: can't reserve I/O ports\n");
+ goto err_out;
+ }
- release_region(radio_unit.io,4);
-}
+ if (pci_enable_device(pdev))
+ goto err_out_free_region;
-int __init maxiradio_radio_init(void)
-{
- struct pci_dev *pcidev = NULL;
- int found;
-
- if(!pci_present())
- return -ENODEV;
-
- found = 0;
+ radio_unit.io = pci_resource_start(pdev, 0);
+ init_MUTEX(_unit.lock);
+ maxiradio_radio.priv = _unit;
- pcidev = pci_find_device(PCI_VENDOR_ID_GUILLEMOT,
-
PCI_DEVICE_ID_GUILLEMOT_MAXIRADIO,
- pcidev);
-
- found += radio_install(pcidev);
-
- if(found == 0) {
- printk(KERN_INFO "radio-maxiradio: no devices found.\n");
- return -ENODEV;
+ if(video_register_device(_radio, VFL_TYPE_RADIO)==-1) {
+ printk("radio-maxiradio: can't register device!");
+ goto err_out_free_region;
}
+ printk(KERN_INFO "radio-maxiradio: version "
+ DRIVER_VERSION
+ " time "
+ __TIME__ " "
+ __DATE__
+ "\n");
+
+ printk(KERN_INFO "radio-maxiradio: found Guillemot MAXI Radio device (io =
+0x%x)\n",
+ radio_unit.io);
return 0;
-}
-module_init(maxiradio_radio_init);
-module_exit(maxiradio_radio_exit);
+err_out_free_region:
+ release_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0));
+err_out:
+ return -ENODEV;
+}
-inline static __u16 radio_install(struct pci_dev *pcidev)
+static void __devexit maxiradio_remove_one(struct pci_dev *pdev)
{
- radio_unit.io = pcidev->resource[0].start;
+ video_unregister_device(_radio);
+ release_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0));
+}
- pci_enable_device(pcidev);
- maxiradio_radio.priv = _unit;
- init_MUTEX(_unit.lock);
-
- if(video_register_device(_radio, VFL_TYPE_RADIO)==-1) {
- printk("radio-maxiradio: can't register device!");
- return 0;
- }
-
-
- printk(KERN_INFO "radio-maxiradio: version "
- DRIVER_VERSION
- "\n");
-
- printk(KERN_INFO
- "radio-maxiradio: found Guillemot MAXI Radio device (io = 0x%x)\n",
- radio_unit.io
- );
+static struct pci_device_id maxiradio_pci_tbl[] __devinitdata = {
+ { PCI_VENDOR_ID_GUILLEMOT, PCI_DEVICE_ID_GUILLEMOT_MAXIRADIO,
+ PCI_ANY_ID, PCI_ANY_ID, },
+ { 0,}
+};
+MODULE_DEVICE_TABLE(pci, maxiradio_pci_tbl);
- if(!request_region(radio_unit.io, 4, "Maxi Radio FM 2000"))
- {
- printk(KERN_ERR "radio-maxiradio: port 0x%x already in use\n",
- radio_unit.io);
-
- return 0;
- }
+static struct pci_driver maxiradio_driver = {
+ name: "radio-maxiradio",
+ id_table: maxiradio_pci_tbl,
+ probe: maxiradio_init_one,
+ remove: maxiradio_remove_one,
+};
+
+int __init maxiradio_radio_init(void)
+{
+ int count = pci_register_driver(_driver);
+
+ if(count > 0) return 0; else return -ENODEV;
+}
-
Re: Linux 2.4.1-ac5
> > now that -ac grows that huge, could you put out incremental patches? > > Takes me too much time. But if anyone else wants to, go ahead This is what i use to diff 2 different kernels - snip - diffkernel) mount none /d/kernel -t ramfs cd /d/kernel tar -zxf $1 cp -a linux linuxa cd /d/kernel/linuxa zcat $2 | patch -p1 -E -s cd /d/kernel/linux zcat $3 | patch -p1 -E -s cd /d/kernel diff -Nur linuxa linux cd umount /d/kernel - snip - This takes about 8 seconds (for 2.4 kernels) on my Dual PIII-933, 1Gig-RAM Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Promise, DMA and RAID5 problems running 2.4.1
On Wed, 7 Feb 2001, Alan Cox wrote: > > Iff CONFIG_BLK_DEV_IDECS is set then yes, doing schedule is better. > > But I do not see any benefit in doing > > > > unsigned long timeout = jiffies + ((HZ + 19)/20) + 1; > > while (0 < (signed long)(timeout - jiffies)); > > On that bit we agree. What do you want fixed? Send a patch and lets try it Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: single copy pipe/fifo
Manfred Spraul writes: > * if you run 2 instances on a dual cpu P II/350 it's a big win, but if > you run only one instance, then the bw_pipe processes will jump from one > cpu to the other and it's only a small improvement (~+15%). wake_up_interruptible_sync is meant specifically to avoid this cpu hopping behavior. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
single copy pipe/fifo
I finished my single copy pipe/fifo implementation.
Main changes:
* it's more a rewrite of pipe_read() and pipe_write().
Both functions were a nightmare of nested loops and gotos.
I wrote a test app - with the right timing multiple writers on a fifo
can race and then they busy loop in the current pipe_write() - adding
another set of goto's for single copy is imho a bad idea.
* slightly faster for non-zero copy transfers due to the code
simplification.
* No single copy for exactly 4096 byte writes, only > PIPE_BUF.
Single copy (and thus blocking) such writes could trigger bugs in user
space apps that errorneously assume that a pipe write of PIPE_BUF bytes
after a successful poll(POLLOUT) doesn't block even if O_NONBLOCK is not
set. It's not defined in posix or susv2, but no unix version I tested
blocks in such writes.
* on P II/350 single cpu it's a big win (~+70 % bw_pipe)
* if you run 2 instances on a dual cpu P II/350 it's a big win, but if
you run only one instance, then the bw_pipe processes will jump from one
cpu to the other and it's only a small improvement (~+15%).
I've attached the patch, the test app is at
http://colorfullife.com/~manfred/kiopipe/fail.cpp
Please test it!
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 1
// EXTRAVERSION =
--- 2.4/fs/pipe.c Thu Nov 16 22:18:26 2000
+++ build-2.4/fs/pipe.c Wed Feb 7 17:17:13 2001
@@ -10,6 +10,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -35,97 +37,149 @@
down(PIPE_SEM(*inode));
}
+struct pipe_pio {
+ int *pdone;
+ struct kiobuf iobuf;
+};
+
+static int
+pio_copy_to_user(struct kiobuf* iobuf, int offset, char* ubuf, int chars)
+{
+ int page_nr;
+ offset += iobuf->offset;
+ page_nr = offset/PAGE_SIZE;
+ offset %= PAGE_SIZE;
+ while(chars) {
+ int pcount = PAGE_SIZE-offset;
+ void *kaddr;
+ if (pcount > chars)
+ pcount = chars;
+ kaddr = kmap(iobuf->maplist[page_nr]);
+ if (copy_to_user(ubuf, kaddr+offset, pcount))
+ return 1;
+ kunmap(iobuf->maplist[page_nr]);
+ chars -= pcount;
+ ubuf += pcount;
+ offset = 0;
+ page_nr++;
+ }
+ return 0;
+}
+
static ssize_t
pipe_read(struct file *filp, char *buf, size_t count, loff_t *ppos)
{
struct inode *inode = filp->f_dentry->d_inode;
- ssize_t size, read, ret;
+ ssize_t read, ret;
- /* Seeks are not allowed on pipes. */
- ret = -ESPIPE;
- read = 0;
+ /* pread is not allowed on pipes. */
if (ppos != >f_pos)
- goto out_nolock;
+ return -ESPIPE;
/* Always return 0 on null read. */
- ret = 0;
if (count == 0)
- goto out_nolock;
+ return 0;
- /* Get the pipe semaphore */
- ret = -ERESTARTSYS;
- if (down_interruptible(PIPE_SEM(*inode)))
- goto out_nolock;
+ down(PIPE_SEM(*inode));
- if (PIPE_EMPTY(*inode)) {
-do_more_read:
+ read = 0;
+ for (;;) {
+ /* read what data is available */
+ int chars = PIPE_LEN(*inode);
+ if (chars) {
+ char *pipebuf = PIPE_BASE(*inode);
+ int offset = PIPE_START(*inode);
+
+ if (chars > count)
+ chars = count;
+ ret = -EFAULT;
+ if(PIPE_IS_PIO(*inode)) {
+ struct pipe_pio* pio = ((struct pipe_pio*)pipebuf);
+ if(pio_copy_to_user(>iobuf, offset, buf, chars))
+ goto out;
+
+ PIPE_LEN(*inode) -= chars;
+ if(!PIPE_LEN(*inode)) {
+ unmap_kiobuf(>iobuf);
+ *pio->pdone = 1;
+ PIPE_IS_PIO(*inode) = 0;
+ PIPE_START(*inode) = 0;
+ } else {
+ PIPE_START(*inode) += chars;
+ }
+ } else {
+ if (chars > PIPE_SIZE-offset)
+ chars = PIPE_SIZE-offset;
+ if (copy_to_user(buf, pipebuf+offset, chars))
+ goto out;
+ PIPE_LEN(*inode) -= chars;
+ if (!PIPE_LEN(*inode)) {
+ /* Cache behaviour optimization */
+ PIPE_START(*inode) = 0;
+ } else {
+
Re: [PATCH] Hamachi not doing pci_enable before reading resources
> I stand by my statement. PCI devices that require resources are > required to provide read/write registers indicating these resources > whether or not the enable bits are set. This is mandatory. And the assignment of those resources is done by pci_enable_device. So looking at the irq data or the BAR assignment until pci_enable_device has done its work doesnt tell you anything meaningful It doesnt just flip the IO and MEM bits - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
