Re: No 100 HZ timer!

[Ben Greear]

Bret Indrelee wrote:
> 
> On Thu, 12 Apr 2001, george anzinger wrote:
> > Bret Indrelee wrote:
> > >
> > > On Thu, 12 Apr 2001, george anzinger wrote:
> > > > Bret Indrelee wrote:
> > > > > Keep all timers in a sorted double-linked list. Do the insert
> > > > > intelligently, adding it from the back or front of the list depending on
> > > > > where it is in relation to existing entries.
> > > >
> > > > I think this is too slow, especially for a busy system, but there are
> > > > solutions...
> > >
> > > It is better than the current solution.
> >
> > Uh, where are we talking about.  The current time list insert is real
> > close to O(1) and never more than O(5).
> 
> I don't like the cost of the cascades every (as I recall) 256
> interrupts. This is more work than is done in the rest of the interrupt
> processing, happens during the tick interrupt, and results in a rebuild of
> much of the table.
> 
> -Bret

Wouldn't a heap be a good data structure for a list of timers?  Insertion
is log(n) and finding the one with the least time is O(1), ie pop off the
front  It can be implemented in an array which should help cache
coherency and all those other things they talked about in school :)

Ben
> 
> --
> Bret Indrelee |  Sometimes, to be deep, we must act shallow!
> [EMAIL PROTECTED]   |  -Riff in The Quatrix
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Ben Greear ([EMAIL PROTECTED])  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com (Released under GPL)
http://scry.wanfear.com   http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Sudden scsi timeouts on main disk.

[Rafael E. Herrera]

Hi,

While playing a dvd I was plugging a headphone and my machine froze and had to reset.
The machine was running 2.4.3 with the new aha7xxx driver.

I booted back into 2.2.18. It took a while to get pass the scsi BIOS. It finally 
detected
all the drives, but lilo would not find the scsi disk to boot. After several attempts 
it
finally booted but started to get scsi time outs from my main disk. My scsi adapter
is an adaptec 7895. The logs are:

Apr 13 01:16:17 inca kernel: scsi : aborting command due to timeout : pid 3797, scsi0, 
channel 0, id 0, lun 0 Read (10) 00 00 88 aa f3 00 00 08 00 
Apr 13 01:16:17 inca kernel: (scsi0:0:0:0) SCSISIGI 0x54, SEQADDR 0x156, SSTAT0 0x7, 
SSTAT1 0x7
Apr 13 01:16:17 inca kernel: (scsi0:0:0:0) SG_CACHEPTR 0x0, SSTAT2 0x10, STCNT 0x0
Apr 13 01:16:19 inca kernel: SCSI host 0 abort (pid 3797) timed out - resetting
Apr 13 01:16:19 inca kernel: SCSI bus is being reset for host 0 channel 0.
Apr 13 01:16:20 inca kernel: (scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 8.
Apr 13 01:16:50 inca kernel: scsi : aborting command due to timeout : pid 3801, scsi0, 
channel 0, id 0, lun 0 Read (10) 00 00 88 ac 8b 00 00 08 00 
Apr 13 01:16:50 inca kernel: (scsi0:0:0:0) SCSISIGI 0x54, SEQADDR 0x156, SSTAT0 0x7, 
SSTAT1 0x7
Apr 13 01:16:50 inca kernel: (scsi0:0:0:0) SG_CACHEPTR 0x0, SSTAT2 0x10, STCNT 0x0
Apr 13 01:16:52 inca kernel: SCSI host 0 abort (pid 3801) timed out - resetting
Apr 13 01:16:52 inca kernel: SCSI bus is being reset for host 0 channel 0.
Apr 13 01:16:53 inca kernel: (scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 8.
Apr 13 01:17:23 inca kernel: scsi : aborting command due to timeout : pid 3820, scsi0, 
channel 0, id 0, lun 0 Request Sense 00 00 00 10 00 
Apr 13 01:17:23 inca kernel: (scsi0:0:0:0) SCSISIGI 0x54, SEQADDR 0x156, SSTAT0 0x7, 
SSTAT1 0x17
Apr 13 01:17:23 inca kernel: (scsi0:0:0:0) SG_CACHEPTR 0x0, SSTAT2 0x10, STCNT 0x0
Apr 13 01:17:24 inca kernel: SCSI host 0 abort (pid 3820) timed out - resetting
Apr 13 01:17:24 inca kernel: SCSI bus is being reset for host 0 channel 0.
Apr 13 01:17:25 inca kernel: (scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 8.

This has not happened before and the time outs are occurring intermittently. Are the 
logs
a signal of hardware error? What would be the steps to check the machine? Any 
suggestion
would be appreciated.

-- 
 Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Yacc in 2.4.3 causes kernel compile to fail (aicasm_gram.y)

[David E. Weekly]

There is a singular Yacc file in 2.4.3:
linux/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y

This is the first time I remember seeing a Yacc file in the Linux kernel
source code, but I'm young and stupid.

Since the default Makefile mapping for .y files is to call yacc, and since I
have bison on my system instead, compiling the aic7xxx code into 2.4.3 broke
my build.

The Makefile system is expecting the YACC variable to be defined; a
straightforward workaround is then to define:

export YACC="`which bison` -y"

The -y option makes sure that bison outputs files in the same way that yacc
does (i.e., y.tab.c and not [filename].tab.c).

I would put in my two cents that the better way to do this is to add YACC to
the list of "make variables" in the root Makefile.

I'm guessing that anyone compiling the AIC 7xxx SCSI drivers who has bison
and hasn't configured a spoof "yacc" will run into this problem.

-david


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

more via wierdness

[Ed Tomlinson]

Hi,

Strange thing that shows up here.  Using a MB with a MVP3
chipset I have
hda - 13G udma2
hdb - nothing physical but the driver does not always agree
hdc - cdrom udma2 sometimes...
hdd - HP Colorada 20GB tape dma - sometimes...

I say sometimes for the devices ide1 since what /proc/ide/via
and hdparm (used only for info) report changes boot to boot.

Why is this happening?  I am using ac5 but have observed this
for a while.  Note that everything seem to work fine in both
cases (PIO or DMA)...

What else would help debuging this?

Ed Tomlinson <[EMAIL PROTECTED]>




00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- FastB2B-
00: 06 11 98 85 07 00 20 22 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 90 90 00 00
20: 00 e4 f0 e7 00 e8 f0 e9 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 00
40: 60 ec 60 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47)
Subsystem: VIA Technologies, Inc. MVP3 ISA Bridge
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- TAbort- SERR- TAbort- SERR-  [disabled] [size=64K]
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=0 PME-
Capabilities: [f0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=7 SBA+ AGP+ 64bit- FW- Rate=x1
00: 2b 10 25 05 07 00 90 02 04 00 00 03 08 40 00 00
10: 08 00 00 e8 00 00 00 e4 00 00 00 e5 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 2b 10 79 21
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 10 20
40: 20 c1 53 50 00 3c 00 00 06 ff ff 07 00 00 00 00
50: 00 30 00 01 19 84 9b 01 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 f0 22 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 02 00 20 00 03 02 00 1f 01 03 00 07 00 00 00 00



--VIA BusMastering IDE Configuration
Driver Version: 3.23
South Bridge:   VIA vt82c586b
Revision:   ISA 0x47 IDE 0x6
Highest DMA rate:   UDMA33
BM-DMA base:0xa000
PCI clock:  33MHz
Master Read  Cycle IRDY:1ws
Master Write Cycle IRDY:1ws
BM IDE Status Register Read Retry:  yes
Max DRDY Pulse Width:   No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush:  yes yes
End Sector FIFO flush: no  no
Prefetch Buffer:  yes yes
Post Write Buffer:yes  no
Enabled:  yes yes
Simplex only:  no  no
Cable Type:   40w 40w
---drive0drive1drive2drive3-
Transfer Mode:   UDMA   DMA  UDMA   DMA
Address Setup:   30ns 120ns  30ns  30ns
Cmd Active:  90ns  90ns  90ns  90ns
Cmd Recovery:30ns  30ns  30ns  30ns
Data Active: 90ns 330ns  90ns  90ns
Data Recovery:   30ns 270ns  30ns  30ns
Cycle Time:  60ns 600ns  60ns 120ns
Transfer Rate:   33.0MB/s   3.3MB/s  33.0MB/s  16.5MB/s


#
# 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 

[BUG] ide-tape is readonly here

[Ed Tomlinson]

Hi,

Upgraded to ac5 tonight.  Problems with 8139too.o
caused a few crashes and scrambled a few files.
Restoring them was fun.  Seems that while ide-tape
can write to my 'HP Colorado 20G' drive, it gets
an I/O error when it trys to read...  If I flip to 
ide-scsi and friends (much slower for backups btw)
the restore works.

What is needed to debug this?

Ed Tomlinson <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: k 2.4.2; usb; handspring-visor

[Bob McElrath]

Erik DeBill [[EMAIL PROTECTED]] wrote:
> On Wed, Apr 11, 2001 at 08:52:30AM -0500, John Madden wrote:
> > > Apr  8 23:33:09 horus kernel: hub.c: USB new device connect on bus1/1,
> > > assigned device number 5
> > > Apr  8 23:33:12 horus kernel: usb_control/bulk_msg: timeout
> > > Apr  8 23:33:12 horus kernel: usb.c: USB device not accepting new
> > > address=5 (error=-110)
> > 
> > Funny, I've been getting the same messages (on 2.4.0 and now 2.4.3) for a 
> > while now, and I thought the problem was with my Visor.  (...I haven't 
> > been able to sync for months...)
> 
> Have you tried using the normal UHCI driver, instead of the UHCI
> Alternate Driver (JE)?  I know the "alternate" one is default from
> Linus, but it's incompatible with the usb-visor driver.  The
> maintainer said he'd patch the docs to clear up the confusion, but it
> hasn't shown up in the mainstream kernels yet.

I've also been seeing these messages (for a very, very long time), with
both the uhci and usb-uhci drivers, with many different devices (not
just visor).  Usually the only way to fix it is to have the usb stuff
compiled as modules, remove it all, and the re-insmod it all.  Then it
works again for a little while...

There really needs to be only one driver.  It's just confusing.

> In my case, trying to use the visor would actually lock up the
> machine, requiring a cold boot.  Switched to the other UHCI driver
> and it works fine.

Never had to reboot though...on either x86 or alpha with UHCI...

Cheers,
-- Bob

Bob McElrath ([EMAIL PROTECTED]) 
Univ. of Wisconsin at Madison, Department of Physics

 PGP signature

[BUG] 8139too 'too much work at interrupt'

[Ed Tomlinson]

Hi,

Upgraded to ac5 tonight.  It stalled shortly after start a 
program to suck news.  Looking at a serial console I see
hundreds of the above message with a status of
intrStatus = 0x0001

Sysrq was active on the serial console so I did a T and P
before syncing are rebooting...  If the translated traces
are of any use just ask.

Ed Tomlinson <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bug in natsemi driver 1.07 for linux 2.4.2

[Troy Benjegerdes]

On Fri, Mar 30, 2001 at 07:04:29AM +0200, Sebastian Klemke wrote:
> Hi!
> 
> The driver for the natsemi NIC does not properly filter out requested
> multicast groups when in multicast mode.  Multicast groups I joined
> are simply dropped by the MAC address filter of the card, the kernel
> filters them correctly in allmulti or promiscuous mode. I've tested
> driver versions 1.05 which comes with linux 2.4.2, an older version
> that came with linux-2.4.0test12 and 1.07 which came with 2.4.2-ac20.
> 
> I contacted Donald Becker and he told me to post it here.

Have you tried Donald Becker's version of the driver under linux 2.2.x?

The only natsemi driver I've ever had come close to working is in
2.4.4pre1, and even then it's got some problems that cause poor
perfomance, nfs timeouts, and dropped connections with the squid http
proxy.

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  [EMAIL PROTECTED]
-"If this message isn't misspelled, I didn't write it" -- Me -
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Shulz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: memory usage - dentry_cacheg

[Ed Tomlinson]

On Thursday 12 April 2001 22:03, Alexander Viro wrote:
> On Thu, 12 Apr 2001, Ed Tomlinson wrote:
> > On Thursday 12 April 2001 11:12, Alexander Viro wrote:
> > What prompted my patch was observing situations where the icache (and
> > dcache too) got so big that they were applying artifical pressure to the
> > page and buffer caches. I say artifical since checking the stats these
> > caches showed over 95% of the entries unused.  At this point there is
> > usually another 10% or so of objects allocated by the slab caches but not
> > accounted for in the stats (not a problem they are accounted if the cache
> > starts using them).
>
> "Unused" as in "->d_count==0"? That _is_ OK. Basically, you will have
> positive ->d_count only on directories and currently opened files.
> E.g. during compile in /usr/include/* you will have 3-5 file dentries
> with ->d_count > 0 - ones that are opened _now_. It doesn't mean that
> everything else rest is unused in any meaningful sense. Can be freed - yes,
> but that's a different story.
>
> If you are talking about "unused" from the slab POV - _ouch_. Looks like
> extremely bad fragmentation ;-/ It's surprising, and if that's thte case
> I'd like to see more details.

>From the POV of dentry_stat.nr_unused.  From the slab POV, dentry_stat.nr_dentry
always equals the number of objects used as reported in /proc/slabinfo.  If I
could remember my stats from ages back I could take a stab at estimating the
fragmentation...  From experience if you look at memory_pressure before and 
after a shrink of the dcache you will usually see it decrease if there if
there is more that 75% or so free reported by dentry_stat.nr_unused.  

The inode cache is not as good.  With fewer inodes per page (slab) I 
would expect that percentage to be lower.  Instead it usually has to be
above 80% to get pages free...

I am trying your change now.

Ed Tomlinson

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: k 2.4.2; usb; handspring-visor

[Erik DeBill]

On Wed, Apr 11, 2001 at 08:52:30AM -0500, John Madden wrote:
> > Apr  8 23:33:09 horus kernel: hub.c: USB new device connect on bus1/1,
> > assigned device number 5
> > Apr  8 23:33:12 horus kernel: usb_control/bulk_msg: timeout
> > Apr  8 23:33:12 horus kernel: usb.c: USB device not accepting new
> > address=5 (error=-110)
> 
> Funny, I've been getting the same messages (on 2.4.0 and now 2.4.3) for a 
> while now, and I thought the problem was with my Visor.  (...I haven't 
> been able to sync for months...)

Have you tried using the normal UHCI driver, instead of the UHCI
Alternate Driver (JE)?  I know the "alternate" one is default from
Linus, but it's incompatible with the usb-visor driver.  The
maintainer said he'd patch the docs to clear up the confusion, but it
hasn't shown up in the mainstream kernels yet.

In my case, trying to use the visor would actually lock up the
machine, requiring a cold boot.  Switched to the other UHCI driver
and it works fine.

Erik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

natsemi.c still broken...

[Troy Benjegerdes]

On Wed, Apr 11, 2001 at 09:32:36PM -0500, Troy Benjegerdes wrote:
> On Wed, Mar 28, 2001 at 12:58:57PM -0500, Jeff Garzik wrote:
> > There are some improvements in the latest 2.4 test patch, 2.4.3-pre8.  I
> > would be very interested in hearing feedback on that.  I finally got two
> > test cards, FA311 and FA312, so I can work on it a bit too.
> 
> Okay, I finally got around to testing this on 2.4.4-pre1. for the 5 or so 
> minutes I've been using it so far, it seems okay (I'm able to log in this 
> time), and I'm running NetPIPE to check performance.
> 
> Perfomance isn't great (the peak bandwidth is 65 Mbps or so), but this
> could be partially due to my switch or the other machine I'm testing it
> with.

Okay, I've been running with 2.4.4-pre1 for awhile now, and although the
driver does hang up on nfs traffic, it still has problems. After running
for awhile, it seems to have dropouts of server hundred milliseconds where
no packets go through. This is somewhat evident in interactive SSH
sessions, and causes clients connecting to the squid proxy I am running on
the machine to behave quite badly. (debian's 'apt' via the proxy is
particulaly bad)

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  [EMAIL PROTECTED]
-"If this message isn't misspelled, I didn't write it" -- Me -
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Shulz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-Kernel Archive: No 100 HZ timer !

[Andre Hedrick]

On Thu, 12 Apr 2001, george anzinger wrote:

> Actually we could do the same thing they did for errno, i.e.
> 
> #define jiffies get_jiffies()
> extern unsigned get_jiffies(void);

> No, not really.  HZ still defines the units of jiffies and most all the
> timing is still related to it.  Its just that interrupts are only "set
> up" when a "real" time event is due.

Great HZ always defines units of jiffies, but that is worthless if there
is not a ruleset that tells me a value to divide by to return it to a
specific quantity of time.

Cheers,

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Help with Fasttrack/100 Raid on Linux

[Andre Hedrick]

Stephen,

Just telling me this fact is preaching to the choir, you have to express
this on the mailing list, so others can hear first hand that you dislike
the product and their support is non-existant.

You will get no support for kernels that are not precompiled with distros,
that will be a fact.  They have ne desire or intention to support linux.
Instead of accepting help, the patronize.

The insult the global linux community with phrases like: 'we are more
concerned with quality and compatablity, than to runs to market...'

Yet they have yet to follow the programming rules of modules, including
the basics of spinlocks/semephores/queue-locks.

So great icon of compatablity with the other os, is vaporware.
You should not trust that their driver will protect you other OS if you
access under Linux.  I expect it to eat and damage it just like you are
seeing you Linux partitions being eaten.

Sorry, but http://www.linux-ide.org/ clearly states that nothing below a
given line supports hardware/bios-soft raid.

Regards,

Andre Hedrick
Linux ATA Development

On Thu, 12 Apr 2001, Stephen Woodbridge wrote:

> Andre,
> 
> Thank you for your quick response. I was afraid that was going to be the
> situation. They have not been much help. I guess I will just buy another
> regular ATA/100 controller and use software RAID. I wish I had know this
> before I spent the money on the FastTrack100 controller.
> 
> Best regards,
>   -Steve
> 
> Andre Hedrick wrote:
> > 
> > Stephen,
> > 
> > Sorry but that is a closed source driver and you have to goto Promise, LOL.
> > Last time I talked to them they sent me an email virus that choked a drive.
> > Scan your mail first and then count your fingers if you have to shake
> > hands with somebody their
> > 
> > Andre Hedrick
> > Linux ATA Development
> > 
> > On Thu, 12 Apr 2001, Stephen Woodbridge wrote:
> > 
> > > Andre,
> > >
> > > I have searched everywhere for some help getting my Promise
> > > FrastTrack/100 Raid controller working. I finally found the ft.o driver
> > > on the Promise website and have gotten it installed correctly (I think),
> > > but I can NOT get fdisk to recognize the drive. Any help would be
> > > greatly appreciated.
> > >
> > > Best regards,
> > >   -Stephen Woodbridge
> > >
> > > Here is what I have done so far:
> > >
> > > RedHat 6.2
> > > Linux 2.2.18
> > > (No other scsi devices in system)
> > >
> > > I added to /etc/conf.modules
> > >   alias block-major-8 ft
> > > and copied the ft.o to /lib/modules/2.2.18/scsi
> > > and did the depmod -a
> > > and rebooted
> > >
> > >   (after boot) ...
> > > [root@linus /root]# lsmod
> > > Module  Size  Used by
> > > lockd  44688   0  (autoclean) (unused)
> > > sunrpc 58820   0  (autoclean) [lockd]
> > > 3c509   5996   1  (autoclean)
> > > tulip  31888   1  (autoclean)
> > > es1371 25920   0
> > > soundcore   2596   4  [es1371]
> > >
> > > [root@linus /root]# fdisk /dev/sda# tried repeatedly
> > >
> > > Unable to open /dev/sda
> > >
> > > [root@linus /root]# lsmod
> > > Module  Size  Used by
> > > ft 71048   0  (autoclean) (unused)
> > > scsi_mod   38372   1  (autoclean) [ft]
> > > lockd  44688   0  (autoclean) (unused)
> > > sunrpc 58820   0  (autoclean) [lockd]
> > > 3c509   5996   1  (autoclean)
> > > tulip  31888   1  (autoclean)
> > > es1371 25920   0
> > > soundcore   2596   4  [es1371]
> > > [root@linus /root]#
> > >
> > > When fdisk tried to access /dev/sda the module was loaded and the
> > > following banner shows up on the console:
> > >
> > > TastTrack Driver v1.10 build 3 (06.OCT.2000)
> > > scsi0 : FASTTRACK
> > > scsi : 1 host
> > >   Vendor: Promise Model: 1x2 Mirror/RAID1 Rev 1.10
> > >   Type:   Direct-Access   ANSI SCSI revision: 02
> > >   Vendor: Promise Model: 1x2 Mirror/RAID1 Rev 1.10
> > >   Type:   Direct-Access   ANSI SCSI revision: 02
> > >   Vendor: Promise Model: 1x2 Mirror/RAID1 Rev 1.10
> > >   Type:   Direct-Access   ANSI SCSI revision: 02
> > >   Vendor: Promise Model: 1x2 Mirror/RAID1 Rev 1.10
> > >   Type:   Direct-Access   ANSI SCSI revision: 02
> > >

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: No 100 HZ timer!

[Bret Indrelee]

On Thu, 12 Apr 2001, george anzinger wrote:
> Bret Indrelee wrote:
> > 
> > On Thu, 12 Apr 2001, george anzinger wrote:
> > > Bret Indrelee wrote:
> > > > Keep all timers in a sorted double-linked list. Do the insert
> > > > intelligently, adding it from the back or front of the list depending on
> > > > where it is in relation to existing entries.
> > >
> > > I think this is too slow, especially for a busy system, but there are
> > > solutions...
> > 
> > It is better than the current solution.
> 
> Uh, where are we talking about.  The current time list insert is real
> close to O(1) and never more than O(5).

I don't like the cost of the cascades every (as I recall) 256
interrupts. This is more work than is done in the rest of the interrupt
processing, happens during the tick interrupt, and results in a rebuild of
much of the table.

-Bret

--
Bret Indrelee |  Sometimes, to be deep, we must act shallow!
[EMAIL PROTECTED]   |  -Riff in The Quatrix

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: POSIX 52 53? 54

[yodaiken]

POSIX 1003.13 defines profiles 51-4 where 51 is a single POSIX
process with multiple threads (RTLinux) and 54 is a full POSIX OS
with the RT extensions (Linux).

On Thu, Apr 12, 2001 at 08:15:34PM -0700, george anzinger wrote:
> Any one know any thing about a POSIX draft 52 or 53 or 54.  I think they
> are suppose to have something to do with real time.
> 
> Where can they be found?  What do they imply for the kernel?
> 
> George
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

POSIX 52 53? 54

[george anzinger]

Any one know any thing about a POSIX draft 52 or 53 or 54.  I think they
are suppose to have something to do with real time.

Where can they be found?  What do they imply for the kernel?

George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-Kernel Archive: No 100 HZ timer !

[george anzinger]

Andre Hedrick wrote:
> 
> On Fri, 13 Apr 2001, Alan Cox wrote:
> 
> > > Okay but what will be used for a base for hardware that has critical
> > > timing issues due to the rules of the hardware?
> >
> > > #define WAIT_MIN_SLEEP  (2*HZ/100)  /* 20msec - minimum sleep time */
> > >
> > > Give me something for HZ or a rule for getting a known base so I can have
> > > your storage work and not corrupt.
> >
> >
> > The same values would be valid with add_timer and friends regardless. Its just
> > that people who do
> >
> >   while(time_before(jiffies, started+DELAY))
> >   {
> >   if(poll_foo())
> >   break;
> >   }
> >
> > would need to either use add_timer or we could implement get_jiffies()

Actually we could do the same thing they did for errno, i.e.

#define jiffies get_jiffies()
extern unsigned get_jiffies(void);

> 
> Okay regardless of the call what is it going to be or do we just random
> and go oh-crap data!?!?
> 
> Since HZ!==100 of all archs that have ATA/ATAPI support, it is a mircale
> that FS corruption and system death is not more rampant, except for the
> fact that hardware is quick by a factor of 10+ so that 1000 does not quite
> do as much harm but the associated mean of HZ changes and that is a
> problem with slower hardware.

No, not really.  HZ still defines the units of jiffies and most all the
timing is still related to it.  Its just that interrupts are only "set
up" when a "real" time event is due.

George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

BUG at exit.c:458

[Arthur Pedyczak]

Hi all,
After running 2.4.3 for 9 days my system froze when copying a cd
(dd if=/dev/cdrom of=file)

After rebooting I found the following in the syslog:
===

Apr 12 22:05:28 cs865114-a kernel: Unable to handle kernel paging request at virtual 
address a95af80d
Apr 12 22:05:28 cs865114-a kernel:  printing eip:
Apr 12 22:05:28 cs865114-a kernel: c01433b6
Apr 12 22:05:28 cs865114-a kernel: *pde = 
Apr 12 22:05:28 cs865114-a kernel: Oops: 
Apr 12 22:05:28 cs865114-a kernel: CPU:0
Apr 12 22:05:28 cs865114-a kernel: EIP:0010:[iput+38/336]
Apr 12 22:05:28 cs865114-a kernel: EFLAGS: 00210282
Apr 12 22:05:28 cs865114-a kernel: eax: a95af7fd   ebx: d2b12400   ecx: d2b12410   
edx: d2b12410
Apr 12 22:05:28 cs865114-a kernel: esi: a95af7fd   edi: d2b12400   ebp: 3470   
esp: d7fe7f64
Apr 12 22:05:28 cs865114-a kernel: ds: 0018   es: 0018   ss: 0018
Apr 12 22:05:28 cs865114-a kernel: Process kswapd (pid: 4, stackpage=d7fe7000)
Apr 12 22:05:28 cs865114-a kernel: Stack: d2290a60 d2290a40 c0141806 d2b12400 d7e618a0 
d7e618a0 0008 0545
Apr 12 22:05:28 cs865114-a kernel:d7fe6000  0759 c012a6d1 00010f00 
0004  0004
Apr 12 22:05:28 cs865114-a kernel:c0141b11 37cd c012a74e 0006 0004 
00010f00 c0236f8c 0006
Apr 12 22:05:28 cs865114-a kernel: Call Trace: [prune_dcache+230/336] 
[refill_inactive+129/160] [shrink_dcache_memory+33/64] [do_try_to_free_pages+94/128] 
[kswapd+107/240] [init+0/320] [init+0/320]
Apr 12 22:05:28 cs865114-a kernel:[kernel_thread+38/48] [kswapd+0/240]
Apr 12 22:05:28 cs865114-a kernel:
Apr 12 22:05:28 cs865114-a kernel: Code: 8b 46 10 85 c0 74 04 53 ff d0 58 ff 4b 24 0f 
94 c0 84 c0 0f
Apr 12 22:05:29 cs865114-a kernel: kernel BUG at exit.c:458!

===


ksymoops output:

===
ksymoops 2.3.4 on i686 2.4.3.  Options used
 -v /usr/src/linux/vmlinux (specified)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.3/ (default)
 -m /usr/src/linux/System.map (specified)

Apr 12 22:05:28 cs865114-a kernel: Unable to handle kernel paging request at virtual 
address a95af80d
Apr 12 22:05:28 cs865114-a kernel: c01433b6
Apr 12 22:05:28 cs865114-a kernel: *pde = 
Apr 12 22:05:28 cs865114-a kernel: Oops: 
Apr 12 22:05:28 cs865114-a kernel: CPU:0
Apr 12 22:05:28 cs865114-a kernel: EIP:0010:[iput+38/336]
Apr 12 22:05:28 cs865114-a kernel: EFLAGS: 00210282
Apr 12 22:05:28 cs865114-a kernel: eax: a95af7fd   ebx: d2b12400   ecx: d2b12410   
edx: d2b12410
Apr 12 22:05:28 cs865114-a kernel: esi: a95af7fd   edi: d2b12400   ebp: 3470   
esp: d7fe7f64
Apr 12 22:05:28 cs865114-a kernel: ds: 0018   es: 0018   ss: 0018
Apr 12 22:05:28 cs865114-a kernel: Process kswapd (pid: 4, stackpage=d7fe7000)
Apr 12 22:05:28 cs865114-a kernel: Stack: d2290a60 d2290a40 c0141806 d2b12400 d7e618a0 
d7e618a0 0008 0545
Apr 12 22:05:28 cs865114-a kernel:d7fe6000  0759 c012a6d1 00010f00 
0004  0004
Apr 12 22:05:28 cs865114-a kernel:c0141b11 37cd c012a74e 0006 0004 
00010f00 c0236f8c 0006
Apr 12 22:05:28 cs865114-a kernel: Call Trace: [prune_dcache+230/336] 
[refill_inactive+129/160] [shrink_dcache_memory+33/64] [do_try_to_free_pages+94/128] 
[kswapd+107/240] [init+0/320] [init+0/320]
Apr 12 22:05:28 cs865114-a kernel: Code: 8b 46 10 85 c0 74 04 53 ff d0 58 ff 4b 24 0f 
94 c0 84 c0 0f
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   8b 46 10  mov0x10(%esi),%eax
Code;  0003 Before first symbol
   3:   85 c0 test   %eax,%eax
Code;  0005 Before first symbol
   5:   74 04 je b <_EIP+0xb> 000b Before first symbol
Code;  0007 Before first symbol
   7:   53push   %ebx
Code;  0008 Before first symbol
   8:   ff d0 call   *%eax
Code;  000a Before first symbol
   a:   58pop%eax
Code;  000b Before first symbol
   b:   ff 4b 24  decl   0x24(%ebx)
Code;  000e Before first symbol
   e:   0f 94 c0  sete   %al
Code;  0011 Before first symbol
  11:   84 c0 test   %al,%al
Code;  0013 Before first symbol
  13:   0f 00 00  sldt   (%eax)

==
My hardware:
Motherboard: Asus P2B
CPU: P-III 600 (no overclocking)
RAM: 384 MB
IDE: PIIX4: IDE controller on PCI bus 00 dev 21
 PIIX4: chipset revision 1
 hda: WDC WD200BB-00AUA1, ATA DISK drive
 hdb: MATSHITA CR-589, ATAPI CD/DVD-ROM drive  (ide-scsi)
 hdc: WDC AC313000R, ATA DISK drive
  

Re: Problem with 2.4.1/2.4.3 and CD-RW ide-scsi drive

[Tim Meushaw]

On Thu, Apr 12, 2001 at 09:32:40PM -0400, Douglas Gilbert wrote:
> At the risk of Jens jumping on this post, I think
> there was some problem mounting cdroms that is
> fixed in the "ac" series, the latest of which is
> 2.4.3-ac5 . Perhaps you could try it and report
> back.

Okay, I'll give that a try, probably testing it on Saturday, and will
give the results of it.  I'd be also interested to see if it works with
those fixes or not.
 
> The fact that you can write a cd (which does not 
> involve the sr driver) means that the rest of the SCSI 
> subsystem and the ide-scsi driver seem to be working 
> ok. I doubt that this is a problem with the mount 
> command. 

That's good to hear at least.  :-)  It did seem like ide-scsi was
working fine, given every other operation I could think of other than
mount was working perfectly.

Thanks for the reply!  I'll make sure to say if 2.4.3-ac5 affects things
any.

Tim

-- 
Timothy A. Meushaw
[EMAIL PROTECTED]
http://www.pobox.com/~meushaw/

 PGP signature

Re: [PATCH] Re: memory usage - dentry_cacheg

[Alexander Viro]

On Thu, 12 Apr 2001, Ed Tomlinson wrote:

> On Thursday 12 April 2001 11:12, Alexander Viro wrote:
> What prompted my patch was observing situations where the icache (and dcache 
> too) got so big that they were applying artifical pressure to the page and 
> buffer caches. I say artifical since checking the stats these caches showed 
> over 95% of the entries unused.  At this point there is usually another 10% 
> or so of objects allocated by the slab caches but not accounted for in the 
> stats (not a problem they are accounted if the cache starts using them).

"Unused" as in "->d_count==0"? That _is_ OK. Basically, you will have
positive ->d_count only on directories and currently opened files.
E.g. during compile in /usr/include/* you will have 3-5 file dentries
with ->d_count > 0 - ones that are opened _now_. It doesn't mean that
everything else rest is unused in any meaningful sense. Can be freed - yes,
but that's a different story.

If you are talking about "unused" from the slab POV - _ouch_. Looks like
extremely bad fragmentation ;-/ It's surprising, and if that's thte case
I'd like to see more details.
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: memory usage - dentry_cacheg

[Ed Tomlinson]

On Thursday 12 April 2001 11:12, Alexander Viro wrote:
> On Thu, 12 Apr 2001, Rik van Riel wrote:
> > On Thu, 12 Apr 2001, Ed Tomlinson wrote:
> > > I have been playing around with patches that fix this problem.  What
> > > seems to happen is that the VM code is pretty efficent at avoiding the
> > > calls to shrink the caches.  When they do get called its a case of to
> > > little to late.  This is espically bad in lightly loaded systems.
> > > The following patch helps here.  I also have a more complex version
> > > that uses autotuning, but would rather push the simple code, _if_ it
> > > does the job.
> >
> > I like this patch. The thing I like most is that it tries to free
> > from this cache if there is little activity, not when we are low
> > on memory and it is physically impossible to get rid of the cache.
> >
> > Remember that evicting early from the inode and dentry cache doesn't
> > matter since we can easily rebuild this data from the buffer and page
> > cache.
>
> Ahem. Yes, for local block-based filesystems, provided that directories are
> small and that indirect blocks will not flush the inode table buffers out
> of buffer cache, etc., etc.
>
> Keeping inodes clean when pressure is low is a nice idea. That way you can
> easily evict when needed. Evicting early... Not really.

What prompted my patch was observing situations where the icache (and dcache 
too) got so big that they were applying artifical pressure to the page and 
buffer caches. I say artifical since checking the stats these caches showed 
over 95% of the entries unused.  At this point there is usually another 10% 
or so of objects allocated by the slab caches but not accounted for in the 
stats (not a problem they are accounted if the cache starts using them).

Suspect your change to the prune logic is not going to help the above situation 
much - if the shrink functions are not called often enough we end up with over 
size caches. 

Comments?
Ed Tomlinson <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with 2.4.1/2.4.3 and CD-RW ide-scsi drive

[Douglas Gilbert]

Tim Meushaw <[EMAIL PROTECTED]> wrote:
> I've got an update for this problem I emailled about 
> last night (and for which I only received one reply :-) ).
>
> Strangely enough, I'm able to actually burn a CD 
> using the cd-rw described below, and can verify 
> data written to it (using X-CD-Roast). I still can't 
> actually mount a cd in the drive without getting the 
> error described below, but at least I can burn CDs now.
> 
> Does this behavior sound like a kernel problem, or 
> does it suggest a bug in the 'mount' utility?

Tim,
At the risk of Jens jumping on this post, I think
there was some problem mounting cdroms that is
fixed in the "ac" series, the latest of which is
2.4.3-ac5 . Perhaps you could try it and report
back.

The fact that you can write a cd (which does not
involve the sr driver) means that the rest of the SCSI
subsystem and the ide-scsi driver seem to be working
ok. I doubt that this is a problem with the mount
command.

Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem: Random paging request errors

[Jon Eisenstein]

> > (2) Every so often, I get a non-fatal error on my screen about a
> > kernel paging request error.
> 
> If it's usually the same address, we're probably dealing with
> a kernel bug. If you always get different addresses, chances
> are your RAM is broken (you can test this with memtest86).

I tested with memtest86, and luckily found no problems (and good, because
this RAM is new!).
 
> Decoding the oops is always useful, especially if you can find
> a pattern after you've decoded a few. And if you don't manage
> to find any pattern in them, you know the suspicion lies with
> the hardware ...

I decoded the oops, from /var/log/messages, but I'm not sure how to read
it. Do you have any pointers? Where should I be looking for patterns? Do I
just wait until the next time it happens, get a second log, and diff them?
> 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with 2.4.1/2.4.3 and CD-RW ide-scsi drive

[Tim Meushaw]

I've got an update for this problem I emailled about last night (and for
which I only received one reply :-) ).

Strangely enough, I'm able to actually burn a CD using the cd-rw
described below, and can verify data written to it (using X-CD-Roast).
I still can't actually mount a cd in the drive without getting the error
described below, but at least I can burn CDs now.

Does this behavior sound like a kernel problem, or does it suggest a bug
in the 'mount' utility?

Tim

On Wed, Apr 11, 2001 at 10:53:57PM -0400, Tim Meushaw wrote:
> Hi there.  I just got a new CD-RW drive and am trying to get it working
> under Linux.  I've got the ide-scsi modules all loaded, but have weird
> errors when trying to mount a disk.
> 
> Here are the messages from "dmesg" that I get when the ide-cd and
> ide-scsi modules are loaded.  My DVD-ROM is /dev/hdc, and the CD-RW is
> /dev/hdd (or /dev/sr0):
> 
> -
> hdc: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.12
> ide-cd: ignoring drive hdd
> scsi0 : SCSI host adapter emulation for IDE ATAPI devices
>   Vendor: SONY  Model: CD-RW  CRX160ERev: 1.0e
>   Type:   CD-ROM ANSI SCSI revision: 02
> Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
> sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
> -
> 
> So, it looks like the drive is attached to /dev/sr0 properly.  Then, I
> run "cdrecord -scanbus" to make sure:
> 
> -
> Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling
> Linux sg driver version: 3.1.17
> Using libscg version 'schily-0.1'
> scsibus0:
> 0,0,0 0) 'SONY' 'CD-RW  CRX160E  ' '1.0e' Removable CD-ROM
> -
> 
> So, it REALLY looks like it's working.  However, here's what I get when
> I try to mount an ordinary data CD:
> 
> -
> athens:~# mount -t iso9660 /dev/sr0 /cdrw
> mount: block device /dev/sr0 is write-protected, mounting read-only
> SCSI cdrom error : host 0 channel 0 id 0 lun 0 return code = 2800
> [valid=0] Info fld=0x0, Current sd0b:00: sense key Hardware Error
> Additional sense indicates Logical unit communication CRC error (Ultra-DMA/32)
>  I/O error: dev 0b:00, sector 64
> isofs_read_super: bread failed, dev=0b:00, iso_blknum=16, block=32
> mount: wrong fs type, bad option, bad superblock on /dev/sr0,
>or too many mounted file systems
> -
> 
> I've tried this with both kernel 2.4.1 and 2.4.3 and have the exact same
> error.  I've also tried multiple data CDs and have the same messages.
> The CD-RW is a Sony CRX-160E, plugged in to an Asus A7V motherboard (the
> PCI bus is described by "lspci" as "VIA Technologies, Inc. VT8363/8365
> [KT133/KM133 AGP]").  I'm not sure what other information I can provide,
> but I'll be happy to give anything else that might be needed to help fix
> this problem.
> 
> Thanks a lot!
> Tim
> 
> -- 
> Timothy A. Meushaw
> [EMAIL PROTECTED]
> http://www.pobox.com/~meushaw/



-- 
Timothy A. Meushaw
[EMAIL PROTECTED]
http://www.pobox.com/~meushaw/

 PGP signature

Re: Proposal for a new PCI function call

[Alan Cox]

> Hmmm, I was wondering if could come up with a pretty way to do this on
> 32 bit boxes that wants to enable highmem DMA. Right now
> pci_set_dma_mask() wants a dma_addr_t which means you have to do
> #ifdef CONFIG_HIGHMEM  #else  #endif.
> 
> Introducing a new function that takes bit flags as arguments might be
> better?

pci_set_dma_mask_bits() ? So you could do

pci_set_dma_mask_bits(pdev, 64);

We want everything to go through pci_set_dma_mask... type functions either way
so that we can and the mask with upstream bridges when we hit address range 
limits in some peoples hardware

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

system call logging in userspace

[Chad Hogan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I'm not very experienced with dealing directly with the kernel, so I was 
hoping for a little advice...

I'd like to implement some sort of rudimentary (file)system-call logging.  
Specifically, I'd like information about write, open, creat, unlink, and 
maybe a few others to be pushed into userspace.  Mostly, I'd just like to 
know what files are being created, modified, and deleted as it happens.

It seems quite easy to me -- I was thinking of doing this with a module.  
I'll just grab the pointer from sys_call_table[__NR_open] and replace it with 
my own little wrapper that does nothing but call the original function, and 
then log the call in some manner.



asmlinkage int my_sys_open(const char *fname, int flags, int mode)
{
 [preliminary stuff]

 returnval = real_sys_open(fname, flags, mode);

 [log information based on returnval, fname, whatever];

 return returnval;
}


int init_module()
{
 [other stuff]

 real_sys_open = sys_call_table[__NR_open];
 sys_call_table[__NR_open] = my_sys_open;
 return 0;
}

init cleanup_module()
{
 sys_call_table[__NR_open] = real_sys_open;
}

===

The simplicity of the whole thing is what scares me a little bit.  Am I being 
horribly naive about something here?  It seems like an obviously useful 
module to have around, and yet I've never seen it and I couldn't find anyone 
who had done it already.  Is there a much better way to accomplish this than 
loading in a module?  Am I risking serious fs corruption?

It occurs to me that I may have some problems if something else changes the 
sys_call_table[__NR_open] and the two modules don't cooperate...

Thanks.
- -- 
Chad Hogan [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE61kkHiSF5tViVwg0RAkMOAJ4rMTC/xvvknmiSf512Y5d06ezdpgCfZH+s
rEQ6ltXalr2SVqFg7lhIFYc=
=iBPm
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Proposal for a new PCI function call

[Jes Sorensen]

> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:

>> I think the function idea would let us do some sanity checking to
>> make sure drivers weren't setting this to 64bit on non-64 bit
>> busses and stuff.

Jeff> pci_set_dma_mask.  Modify that to do the additional checks you
Jeff> need.

Jeff> Nobody should be setting dma_mask directly anymore, it should be
Jeff> done through this function.

Hmmm, I was wondering if could come up with a pretty way to do this on
32 bit boxes that wants to enable highmem DMA. Right now
pci_set_dma_mask() wants a dma_addr_t which means you have to do
#ifdef CONFIG_HIGHMEM  #else  #endif.

Introducing a new function that takes bit flags as arguments might be
better?

Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: generic_osync_inode() broken?

[Marcelo Tosatti]

On Thu, 12 Apr 2001, Linus Torvalds wrote:

> 
> 
> On Thu, 12 Apr 2001, Marcelo Tosatti wrote:
> >
> > Comments?
> >
> > --- fs/inode.c~ Thu Mar 22 16:04:13 2001
> > +++ fs/inode.c  Thu Apr 12 15:18:22 2001
> > @@ -347,6 +347,11 @@
> >  #endif
> >
> > spin_lock(_lock);
> > +   while (inode->i_state & I_LOCK) {
> > +   spin_unlock(_lock);
> > +   __wait_on_inode(inode);
> > +   spin_lock(_lock);
> > +   }
> > if (!(inode->i_state & I_DIRTY))
> > goto out;
> > if (datasync && !(inode->i_state & I_DIRTY_DATASYNC))
> 
> Ehh.
> 
> Why not just lock the inode around the thing?
> 
> The above looks rather ugly.

Ok, me again.
 
The inode->i_state locking is rather nasty: there is no need to lock the
inode. We just have to wait for it to become unlocked, since its
guaranteed that who locked it wrote it to disk. (sync_one())

Aviro suggested the following, which is much cleaner than the previous
patch: 


--- fs/inode.c~ Thu Apr 12 21:15:23 2001
+++ fs/inode.c  Thu Apr 12 21:16:35 2001
@@ -301,6 +301,8 @@
while (inode->i_state & I_DIRTY)
sync_one(inode, sync);
spin_unlock(_lock);
+   if (sync)
+   wait_on_inode(inode);
}
else
printk("write_inode_now: no super block\n");
@@ -357,6 +359,7 @@
 
  out:
spin_unlock(_lock);
+   wait_on_inode(inode);
return err;
 }
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Help with Fasttrack/100 Raid on Linux

[Alan Cox]

> > > FrastTrack/100 Raid controller working. I finally found the ft.o driver
> 
> Did you try building it from source?  Their docs say beta ft.o is RH 6.2-7.0
> which would make me a bit nervous.
> 
> ftp://ftp.promise.com/Controllers/IDE/FastTrak100/Linux/LinuxBETA/

They dont supply most of the source, just get a different controller.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Help with Fasttrack/100 Raid on Linux

[Tim Moore]

> > FrastTrack/100 Raid controller working. I finally found the ft.o driver

Did you try building it from source?  Their docs say beta ft.o is RH 6.2-7.0
which would make me a bit nervous.

ftp://ftp.promise.com/Controllers/IDE/FastTrak100/Linux/LinuxBETA/

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.3-ac5

[Andrea Arcangeli]

On Thu, Apr 12, 2001 at 07:17:26PM -0400, Greg Louis wrote:
> On 20010412 (Thu) at 1726:11 +0100, Alan Cox wrote:
> > 
> > 2.4.3-ac5
> 
> > o   Fix rwsem compile problem   (me)
> 
> No such luck, I fear, at least not with egcs-2.91.66:
> /usr/src/linux-2.4.3ac5/include/asm/rwsem.h:26: badly punctuated
> parameter list in #define'
> /usr/src/linux-2.4.3ac5/include/asm/rwsem.h: In function 'down_read':
> /usr/src/linux-2.4.3ac5/include/asm/rwsem.h:52: warning: implicit
> declaration of function 'rwsemdebug'

I didn't checked ac5 but this is how I fixed the UP compile problem of 4pre2:

--- 2.4.4pre2aa/include/asm-i386/rwsem.h.~1~Thu Apr 12 17:25:24 2001
+++ 2.4.4pre2aa/include/asm-i386/rwsem.hThu Apr 12 17:38:10 2001
@@ -17,7 +17,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #if RWSEM_DEBUG

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-Kernel Archive: No 100 HZ timer !

[Andre Hedrick]

On Fri, 13 Apr 2001, Alan Cox wrote:

> > Okay but what will be used for a base for hardware that has critical
> > timing issues due to the rules of the hardware?
> 
> > #define WAIT_MIN_SLEEP  (2*HZ/100)  /* 20msec - minimum sleep time */
> > 
> > Give me something for HZ or a rule for getting a known base so I can have
> > your storage work and not corrupt.
> 
> 
> The same values would be valid with add_timer and friends regardless. Its just
> that people who do
> 
>   while(time_before(jiffies, started+DELAY))
>   {
>   if(poll_foo())
>   break;
>   }
> 
> would need to either use add_timer or we could implement get_jiffies()

Okay regardless of the call what is it going to be or do we just random
and go oh-crap data!?!?

Since HZ!==100 of all archs that have ATA/ATAPI support, it is a mircale
that FS corruption and system death is not more rampant, except for the
fact that hardware is quick by a factor of 10+ so that 1000 does not quite
do as much harm but the associated mean of HZ changes and that is a
problem with slower hardware.

Nevermind just going nuts over the issues...
Just trying to keep the flamage down and stuff like that

Cheers,

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.3-ac5

[Greg Louis]

On 20010412 (Thu) at 1726:11 +0100, Alan Cox wrote:
> 
> 2.4.3-ac5

> o Fix rwsem compile problem   (me)

No such luck, I fear, at least not with egcs-2.91.66:
/usr/src/linux-2.4.3ac5/include/asm/rwsem.h:26: badly punctuated
parameter list in #define'
/usr/src/linux-2.4.3ac5/include/asm/rwsem.h: In function 'down_read':
/usr/src/linux-2.4.3ac5/include/asm/rwsem.h:52: warning: implicit
declaration of function 'rwsemdebug'

I went in and #if 0'd around the #ifdef at line 26 and uncommented the
corresponding lines in "old gcc" and it worked fine.  Do gcc and egcs
really not define anything source could #ifdef to figure out to which
compiler it's being submitted?  Yuk!

-- 
| G r e g  L o u i s  | gpg public key:  |
|   http://www.bgl.nu/~glouis |   finger [EMAIL PROTECTED] |

 PGP signature

Re: Linux-Kernel Archive: No 100 HZ timer !

[Alan Cox]

> Okay but what will be used for a base for hardware that has critical
> timing issues due to the rules of the hardware?

> #define WAIT_MIN_SLEEP  (2*HZ/100)  /* 20msec - minimum sleep time */
> 
> Give me something for HZ or a rule for getting a known base so I can have
> your storage work and not corrupt.


The same values would be valid with add_timer and friends regardless. Its just
that people who do

while(time_before(jiffies, started+DELAY))
{
if(poll_foo())
break;
}

would need to either use add_timer or we could implement get_jiffies()



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [test-PATCH] Re: [QUESTION] 2.4.x nice level

[Pozsar Balazs]

On Wed, Apr 11, 2001 at 12:53:16PM -0300, Rik van Riel wrote:
> On Wed, 11 Apr 2001, Rik van Riel wrote:
> 
> > OK, here it is. It's nothing like montavista's singing-dancing
> > scheduler patch that does all, just a really minimal change that
> > should stretch the nice levels to yield the following CPU usage:
> > 
> > Nice05   10   15   19
> > %CPU  100   56   2561
> 
>   PID USER PRI  NI  SIZE SWAP  RSS SHARE STAT %CPU %MEM   TIME COMMAND
>   980 riel  17   0   2960  296   240 R54.1  0.5  54:19 loop
>  1005 riel  16   5   2960  296   240 R N  27.0  0.5   0:34 loop
>  1006 riel  17  10   2960  296   240 R N  13.5  0.5   0:16 loop
>  1007 riel  18  15   2960  296   240 R N   4.5  0.5   0:05 loop
>   987 riel  20  19   2960  296   240 R N   0.4  0.5   0:25 loop

How does this scale to negative nice levels? Afaik it should, in some way.
(I don't mean that it's wrong in this state, i'm just asking).

regards,
Balazs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Help with Fasttrack/100 Raid on Linux

[Andre Hedrick]

Stephen,

Sorry but that is a closed source driver and you have to goto Promise, LOL.
Last time I talked to them they sent me an email virus that choked a drive.
Scan your mail first and then count your fingers if you have to shake
hands with somebody their

Andre Hedrick
Linux ATA Development

On Thu, 12 Apr 2001, Stephen Woodbridge wrote:

> Andre,
> 
> I have searched everywhere for some help getting my Promise
> FrastTrack/100 Raid controller working. I finally found the ft.o driver
> on the Promise website and have gotten it installed correctly (I think),
> but I can NOT get fdisk to recognize the drive. Any help would be
> greatly appreciated.
> 
> Best regards,
>   -Stephen Woodbridge
> 
> Here is what I have done so far:
> 
> RedHat 6.2
> Linux 2.2.18
> (No other scsi devices in system)
> 
> I added to /etc/conf.modules
>   alias block-major-8 ft
> and copied the ft.o to /lib/modules/2.2.18/scsi
> and did the depmod -a
> and rebooted
> 
>   (after boot) ...
> [root@linus /root]# lsmod
> Module  Size  Used by
> lockd  44688   0  (autoclean) (unused)
> sunrpc 58820   0  (autoclean) [lockd]
> 3c509   5996   1  (autoclean)
> tulip  31888   1  (autoclean)
> es1371 25920   0
> soundcore   2596   4  [es1371]
> 
> [root@linus /root]# fdisk /dev/sda# tried repeatedly
> 
> Unable to open /dev/sda
> 
> [root@linus /root]# lsmod
> Module  Size  Used by
> ft 71048   0  (autoclean) (unused)
> scsi_mod   38372   1  (autoclean) [ft]
> lockd  44688   0  (autoclean) (unused)
> sunrpc 58820   0  (autoclean) [lockd]
> 3c509   5996   1  (autoclean)
> tulip  31888   1  (autoclean)
> es1371 25920   0
> soundcore   2596   4  [es1371]
> [root@linus /root]#
> 
> When fdisk tried to access /dev/sda the module was loaded and the
> following banner shows up on the console:
> 
> TastTrack Driver v1.10 build 3 (06.OCT.2000)
> scsi0 : FASTTRACK
> scsi : 1 host
>   Vendor: Promise Model: 1x2 Mirror/RAID1 Rev 1.10
>   Type:   Direct-Access   ANSI SCSI revision: 02
>   Vendor: Promise Model: 1x2 Mirror/RAID1 Rev 1.10
>   Type:   Direct-Access   ANSI SCSI revision: 02
>   Vendor: Promise Model: 1x2 Mirror/RAID1 Rev 1.10
>   Type:   Direct-Access   ANSI SCSI revision: 02
>   Vendor: Promise Model: 1x2 Mirror/RAID1 Rev 1.10
>   Type:   Direct-Access   ANSI SCSI revision: 02
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Unable to use ethernet after suspend and smbmount (laptop)

[Kevin A. Burton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


OK.

This is Kernel 2.4.3.

If I smbmount an exported filesystem from another GNU/Linux machine and then
suspend my laptop, after I resume I am unable to use the network at all.

I really think this is a bug raised by another bug.  The xirc2ps_cs Ethernet Cardbus
driver has a bug where after a suspend I have to eject the card and then insert
it again and then run 'ifup eth0'.  I think it actually may be a bug in my
cardbus but I don't know.

Anyway Linux won't unload (rmmod xirc2ps_cs) because the smbfs is using it.  :(
If force smbfs to unmount maybe this could be resolved but as we all know an
'umount -f /mnt/MOUNT' doesn't really force :(

Anyway.  If anyone has any suggestions I would appreciate it.  If I unmount
*before* I suspend then everything works fine.  The problem is that sometimes I
forget! :(

Kevin

- -- 
Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596 

You may say I'm a dreamer, but I'm not the only one. - John Lennon



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

iD8DBQE61iPWAwM6xb2dfE0RAvXwAJ9/NdkCXuX5jXPUpPAp/9iGOtrvMgCgzMho
DmYqTqZmZnk3YrXuwqnPwWE=
=4vhk
-END PGP SIGNATURE-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: scheduler went mad?

[Valdis . Kletnieks]

On Fri, 13 Apr 2001 01:02:21 +0200, Szabolcs Szakacsits said:

> Not __alloc_pages() calls oom_kill() however do_page_fault(). Not the
> same. After the system tried *really* hard to get *one* free page and
> couldn't managed why loop forever? To eat CPU and waiting for

For what it's worth, this *IS NOT* the case I'm getting bit by:

While kswapd was hung, I already had (from /proc/meminfo)

MemFree: 34064 kB

I suspect that kswapd is getting hung spinning on some *specific*
requirement that it's falling short on?

/Valdis

 PGP signature

Re: No 100 HZ timer!

[george anzinger]

Bret Indrelee wrote:
> 
> On Thu, 12 Apr 2001, george anzinger wrote:
> > Bret Indrelee wrote:
> > > Keep all timers in a sorted double-linked list. Do the insert
> > > intelligently, adding it from the back or front of the list depending on
> > > where it is in relation to existing entries.
> >
> > I think this is too slow, especially for a busy system, but there are
> > solutions...
> 
> It is better than the current solution.

Uh, where are we talking about.  The current time list insert is real
close to O(1) and never more than O(5).
> 
> The insert takes the most time, having to scan through the list. If you
> had to scan the whole list it would be O(n) with a simple linked list. If
> you insert it from the end, it is almost always going to be less than
> that.

Right, but compared to the current O(5) max, this is just too long.
> 
> The time to remove is O(1).
> 
> Fetching the first element from the list is also O(1), but you may have to
> fetch several items that have all expired. Here you could do something
> clever. Just make sure it is O(1) to determine if the list is empty.
> 
I would hope to move expired timers to another list or just process
them.  In any case they should not be a problem here.

One of the posts that started all this mentioned a tick less system (on
a 360 I think) that used the current time list.  They had to scan
forward in time to find the next event and easy 10 ms was a new list to
look at.  Conclusion: The current list structure is NOT organized for
tick less time keeping.

George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ide.2.2.19.04092001.patch

[Andre Hedrick]

On Thu, 12 Apr 2001, Shane Wegner wrote:

> On Thu, Apr 12, 2001 at 03:05:53PM -0700, Andre Hedrick wrote:
> > 
> > So you want a VIA-old and VIA-new ??
> 
> Hi,
> 
> Is the version of the driver in the latest IDE patch v4.x? 
> That's odd as that driver does work fine on Linux 2.4.3. 
> It's just the one in 2.2.19+ide.2.2.19.0405 which seems to
> be locking up.

Not it is a migration to what is in Linux 2.4.3, but not there yet.
This is a 3.x version.

> Best regards,
> Shane
> 
> > 
> > On Tue, 10 Apr 2001, Shane Wegner wrote:
> > 
> > > On Mon, Apr 09, 2001 at 05:33:13PM -0700, Andre Hedrick wrote:
> > > > 
> > > > This is up with some updates
> > > Hi,
> > > 
> > > This isn't working here on my Abit VP6 board.  The
> > > ide.2.2.18.1221 works fine but this latest patch as well as
> > > ide.2.2.19.0325 fails.
> > > 
> > > Uniform Multi-Platform E-IDE driver Revision: 6.30
> > > 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
> > > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> > > VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
> > > ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio
> > > ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio, hdd:pio
> > > HPT370: IDE controller on PCI bus 00 dev 70
> > > HPT370: chipset revision 3
> > > HPT370: not 100% native mode: will probe irqs later
> > > ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:pio, hdf:pio
> > > ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio
> > > hda: Maxtor 92720U8, ATA DISK drive
> > > hdg: Maxtor 96147U8, ATA DISK drive
> > > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> > > ide3 at 0xe400-0xe407,0xe802 on irq 10
> > > 
> > > That's where it stops.  Locks solid, not even sysrq-b
> > > works.
> > > 
> > > Shane
> > > 
> > > -- 
> > > Shane Wegner: [EMAIL PROTECTED]
> > >   http://www.cm.nu/~shane/
> > > PGP:  1024D/FFE3035D
> > >   A0ED DAC4 77EC D674 5487
> > >   5B5C 4F89 9A4E FFE3 035D
> > > 
> > 
> > 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
> 
> -- 
> Shane Wegner: [EMAIL PROTECTED]
>   http://www.cm.nu/~shane/
> PGP:  1024D/FFE3035D
>   A0ED DAC4 77EC D674 5487
>   5B5C 4F89 9A4E FFE3 035D
> 

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 8139too: defunct threads

[David Woodhouse]

[EMAIL PROTECTED] said:
>  ho-hum.  Jeff, I think the best fix here is to bite the bullet and
> write kernel_daemon(), which will delegate thread creation to keventd,
> which is the only thing we have which reaps zombies.  Any better
> ideas?

Yes. Let init do it, as God intended. Why reap threads in the kernel when 
they could just reparent themselves as children of pid 1?

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ide.2.2.19.04092001.patch

[Shane Wegner]

On Thu, Apr 12, 2001 at 03:05:53PM -0700, Andre Hedrick wrote:
> 
> So you want a VIA-old and VIA-new ??

Hi,

Is the version of the driver in the latest IDE patch v4.x? 
That's odd as that driver does work fine on Linux 2.4.3. 
It's just the one in 2.2.19+ide.2.2.19.0405 which seems to
be locking up.

Best regards,
Shane

> 
> On Tue, 10 Apr 2001, Shane Wegner wrote:
> 
> > On Mon, Apr 09, 2001 at 05:33:13PM -0700, Andre Hedrick wrote:
> > > 
> > > This is up with some updates
> > Hi,
> > 
> > This isn't working here on my Abit VP6 board.  The
> > ide.2.2.18.1221 works fine but this latest patch as well as
> > ide.2.2.19.0325 fails.
> > 
> > Uniform Multi-Platform E-IDE driver Revision: 6.30
> > 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
> > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> > VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
> > ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio
> > ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio, hdd:pio
> > HPT370: IDE controller on PCI bus 00 dev 70
> > HPT370: chipset revision 3
> > HPT370: not 100% native mode: will probe irqs later
> > ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:pio, hdf:pio
> > ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio
> > hda: Maxtor 92720U8, ATA DISK drive
> > hdg: Maxtor 96147U8, ATA DISK drive
> > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> > ide3 at 0xe400-0xe407,0xe802 on irq 10
> > 
> > That's where it stops.  Locks solid, not even sysrq-b
> > works.
> > 
> > Shane
> > 
> > -- 
> > Shane Wegner: [EMAIL PROTECTED]
> >   http://www.cm.nu/~shane/
> > PGP:  1024D/FFE3035D
> >   A0ED DAC4 77EC D674 5487
> >   5B5C 4F89 9A4E FFE3 035D
> > 
> 
> 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

-- 
Shane Wegner: [EMAIL PROTECTED]
  http://www.cm.nu/~shane/
PGP:  1024D/FFE3035D
  A0ED DAC4 77EC D674 5487
  5B5C 4F89 9A4E FFE3 035D
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ide.2.2.19.04092001.patch

[Andre Hedrick]

So you want a VIA-old and VIA-new ??

On Tue, 10 Apr 2001, Shane Wegner wrote:

> On Mon, Apr 09, 2001 at 05:33:13PM -0700, Andre Hedrick wrote:
> > 
> > This is up with some updates
> Hi,
> 
> This isn't working here on my Abit VP6 board.  The
> ide.2.2.18.1221 works fine but this latest patch as well as
> ide.2.2.19.0325 fails.
> 
> Uniform Multi-Platform E-IDE driver Revision: 6.30
> 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
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
> ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio, hdd:pio
> HPT370: IDE controller on PCI bus 00 dev 70
> HPT370: chipset revision 3
> HPT370: not 100% native mode: will probe irqs later
> ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:pio, hdf:pio
> ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio
> hda: Maxtor 92720U8, ATA DISK drive
> hdg: Maxtor 96147U8, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide3 at 0xe400-0xe407,0xe802 on irq 10
> 
> That's where it stops.  Locks solid, not even sysrq-b
> works.
> 
> Shane
> 
> -- 
> Shane Wegner: [EMAIL PROTECTED]
>   http://www.cm.nu/~shane/
> PGP:  1024D/FFE3035D
>   A0ED DAC4 77EC D674 5487
>   5B5C 4F89 9A4E FFE3 035D
> 

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: (ide.2.2.19.04092001.patch:) DiskPerf compile problem

[Andre Hedrick]

http://www.xx.kernel.org/pub/linux/kernel/people/hedrick/utility-patches/DiskPerf-1.0.4.tar.gz
http://www.xx.kernel.org/pub/linux/kernel/people/hedrick/utility-patches/DiskPerf-1.0.4.tar.bz2

Cheers,

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Incorect signal handling ?

[Doug McNaught]

Daniel Podlejski <[EMAIL PROTECTED]> writes:

> Hi,
> 
> there is litlle programm:
> 
>   signal (SIGALRM, empty);
>   alarm (1);
> 
> a = read(fd, buf, 511);
> 
> while (a && a != -1) a = read(fd, buf, 511);

> I open /tmp/nic and run compiled program.
> There should be error EINTR in read, but isn't.

"Fast" system calls (eg reads from disk) are generally
uninterruptible; thus the signal will be deferred until the read()
returns.

-Doug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: scheduler went mad?

[Szabolcs Szakacsits]

On Thu, 12 Apr 2001, Rik van Riel wrote:
> On Thu, 12 Apr 2001, Szabolcs Szakacsits wrote:
> > You mean without dropping out_of_memory() test in kswapd and calling
> > oom_kill() in page fault [i.e. without additional patch]?
> No.  I think it's ok for __alloc_pages() to call oom_kill()
> IF we turn out to be out of memory, but that should not even
> be needed.

Not __alloc_pages() calls oom_kill() however do_page_fault(). Not the
same. After the system tried *really* hard to get *one* free page and
couldn't managed why loop forever? To eat CPU and waiting for
out_of_memory() to *guess* when system is in OOM? I don't think so, if
processes can't progress because system can't page in any of their
pages, somebody must go.

> Also, when a task in __alloc_pages() is OOM-killed, it will
> have PF_MEMALLOC set and will immediately break out of the
> loop. The rest of the system will spin around in the loop
> until the victim has exited and then their allocations will
> succeed.

Yes, I think this is a problem. In page fault if OOM, "bad" process
selected, scheduled, killed and everybody runs happily even without to
notice system is low on memory. Fast and gracious process killing
instead of slow, painful death IF out_of_memory() correctly detects OOM.

Szaka

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-Kernel Archive: No 100 HZ timer !

[Andre Hedrick]

Okay but what will be used for a base for hardware that has critical
timing issues due to the rules of the hardware?

I do not care but your drives/floppy/tapes/cdroms/cdrws do:

/*
 * Timeouts for various operations:
 */
#define WAIT_DRQ(5*HZ/100)  /* 50msec - spec allows up to 20ms */
#ifdef CONFIG_APM
#define WAIT_READY  (5*HZ)  /* 5sec - some laptops are very slow */
#else
#define WAIT_READY  (3*HZ/100)  /* 30msec - should be instantaneous */
#endif /* CONFIG_APM */
#define WAIT_PIDENTIFY  (10*HZ) /* 10sec  - should be less than 3ms (?), if all ATAPI 
CD is closed at boot */
#define WAIT_WORSTCASE  (30*HZ) /* 30sec  - worst case when spinning up */
#define WAIT_CMD(10*HZ) /* 10sec  - maximum wait for an IRQ to happen */
#define WAIT_MIN_SLEEP  (2*HZ/100)  /* 20msec - minimum sleep time */

Give me something for HZ or a rule for getting a known base so I can have
your storage work and not corrupt.

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RTC !!

[David Woodhouse]

[EMAIL PROTECTED] said:
> The RTC interrupt  is programmable from 2 Hz to 8192 Hz, in powers of
> 2. So the interrupts that you could get are one of the following:
> 0.122ms, .244ms, .488ms, .977ms, 1.953ms, 3.906ms, 7.813ms, and so on.
>Is there any  workaround , so that i can use RTC for meeting my
> requirement of an interrupt every 1.666..ms!!  ( I know that i can use
> UTIME or #define HZ 600, but i want to know if i can use RTC for this
> purpose ) 

You could also use the RTC  for providing the system tick (You'd need to 
make HZ a power of two, obviously) and then use the 8254 for providing your 
600Hz interrupt.

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Oscillations in disk write compaction, poor interactive performance

[SodaPop]

Subject:  Oscillations in disk write compaction

The following data sets are the output of a small program that
reads a random 4k block from a large data file, makes a trivial
alteration to the block, and writes the block back into the
file (in place).  In all three cases the file is larger than
the physical memory of the machine.  In the first two cases,
the file is the exact same.

It appears that in 2.4, we are much more aggressive about ordering
and combining writes to disk - which is probably a good thing, as
it helps increase disk throughput.  But it is also a bad thing,
as it seems that this ties up the disk and rest of the system for
long periods of time.

It also seems that in the 2.4 kernels, we can get into a sort of
oscillation mode, where we can have long periods of disk activity
where nothing can get done - the low points, where only 2-3 writes
per second can occur, so completely screw up the interactive
performance that you simply have to take your hands off the
keyboard and go get coffee until the disk writes complete.  I know
we get better performance overall this way, but it can be
frustrating when this occurs in the middle of video capture.

More notes below.  Anyone got any ideas?  Or have I done something
horribly stupid here?

-dennis T





2.2.14 - 160 meg intel PII.  Relatively slow ide drive, 6 MB/sec
---
File size: 209715200  Blocks: 51200
57.10 writes/second (10 second average, 4096 byte blocks).
57.10 writes/second (10 second average, 4096 byte blocks).
56.70 writes/second (10 second average, 4096 byte blocks).
57.30 writes/second (10 second average, 4096 byte blocks).
60.40 writes/second (10 second average, 4096 byte blocks).
64.30 writes/second (10 second average, 4096 byte blocks).
65.70 writes/second (10 second average, 4096 byte blocks).
60.90 writes/second (10 second average, 4096 byte blocks).
44.60 writes/second (10 second average, 4096 byte blocks).
45.30 writes/second (10 second average, 4096 byte blocks).
56.40 writes/second (10 second average, 4096 byte blocks).
67.60 writes/second (10 second average, 4096 byte blocks).
69.40 writes/second (10 second average, 4096 byte blocks).
66.80 writes/second (10 second average, 4096 byte blocks).
70.80 writes/second (10 second average, 4096 byte blocks).
18.80 writes/second (10 second average, 4096 byte blocks).
74.90 writes/second (10 second average, 4096 byte blocks).
76.00 writes/second (10 second average, 4096 byte blocks).
75.70 writes/second (10 second average, 4096 byte blocks).
59.60 writes/second (10 second average, 4096 byte blocks).
42.70 writes/second (10 second average, 4096 byte blocks).
73.00 writes/second (10 second average, 4096 byte blocks).
50.60 writes/second (10 second average, 4096 byte blocks).
102.80 writes/second (10 second average, 4096 byte blocks).
64.10 writes/second (10 second average, 4096 byte blocks).
91.30 writes/second (10 second average, 4096 byte blocks).
29.70 writes/second (10 second average, 4096 byte blocks).
28.80 writes/second (10 second average, 4096 byte blocks).
95.60 writes/second (10 second average, 4096 byte blocks).
58.50 writes/second (10 second average, 4096 byte blocks).
131.90 writes/second (10 second average, 4096 byte blocks).
6.80 writes/second (10 second average, 4096 byte blocks).
118.00 writes/second (10 second average, 4096 byte blocks).
3.10 writes/second (10 second average, 4096 byte blocks).
73.70 writes/second (10 second average, 4096 byte blocks).
30.00 writes/second (10 second average, 4096 byte blocks).
87.80 writes/second (10 second average, 4096 byte blocks).
97.80 writes/second (10 second average, 4096 byte blocks).
54.60 writes/second (10 second average, 4096 byte blocks).
64.60 writes/second (10 second average, 4096 byte blocks).
6.40 writes/second (10 second average, 4096 byte blocks).
126.20 writes/second (10 second average, 4096 byte blocks).
23.50 writes/second (10 second average, 4096 byte blocks).
88.00 writes/second (10 second average, 4096 byte blocks).
85.00 writes/second (10 second average, 4096 byte blocks).
90.70 writes/second (10 second average, 4096 byte blocks).
12.90 writes/second (10 second average, 4096 byte blocks).
40.90 writes/second (10 second average, 4096 byte blocks).



2.4.3 - 160 meg intel PII.  Same machine as above, dual boot
---
File size: 209715200  Blocks: 51200
57.40 writes/second (10 second average, 4096 byte blocks).
69.20 writes/second (10 second average, 4096 byte blocks).
84.90 writes/second (10 second average, 4096 byte blocks).
58.70 writes/second (10 second average, 4096 byte blocks).
52.60 writes/second (10 second average, 4096 byte blocks).
36.60 writes/second (10 second average, 4096 byte blocks).
35.10 writes/second (10 second average, 4096 byte blocks).
65.80 writes/second (10 second average, 4096 byte blocks).
74.70 writes/second (10 second average, 4096 byte blocks).
88.90 writes/second 

Re: 8139too: defunct threads

[Rod Stewart]

On Thu, 12 Apr 2001, Andrew Morton wrote:
> Rod Stewart wrote:
> >
> > On Thu, 12 Apr 2001, Andrew Morton wrote:
> > > Is there something unusual about your setup?
> >
> > One box is standard PIII with RH 7.0, the other is a custom Crusoe TM5400
> > board.  But from further investigation it appears to be a kernel config
> > option.  As I've got a 2.4.0 kernel which has very little compiled in and
> > not showing the problem and another kernel which has many more networking
> > options built in and showing the problem.  I've seen this problem
> > since 2.4.0.test11.
> >
>
> Sorry.  I meant: what is process 1 on this machine?  Is it not
> the normal init?  If not, then according to Alan, the fault
> lies with your userspace.  Kernel requires that PID 1 reap
> children.

Yes, it is the normal init on both boxes.

-Rms

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 8139too: defunct threads

[Andrew Morton]

Rod Stewart wrote:
> 
> On Thu, 12 Apr 2001, Andrew Morton wrote:
> > Is there something unusual about your setup?
> 
> One box is standard PIII with RH 7.0, the other is a custom Crusoe TM5400
> board.  But from further investigation it appears to be a kernel config
> option.  As I've got a 2.4.0 kernel which has very little compiled in and
> not showing the problem and another kernel which has many more networking
> options built in and showing the problem.  I've seen this problem
> since 2.4.0.test11.
> 

Sorry.  I meant: what is process 1 on this machine?  Is it not
the normal init?  If not, then according to Alan, the fault
lies with your userspace.  Kernel requires that PID 1 reap
children.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Incorect signal handling ?

[Richard B. Johnson]

On Thu, 12 Apr 2001, Daniel Podlejski wrote:

> Hi,
> 
> there is litlle programm:
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> static void empty(int sig)
> {
>   printf ("hello\n");
>   return;
> }
> 
> void main()
> {
> int fd, a;
> char buf[512];
> 
>   if (fd = open("/tmp/nic", O_RDONLY) < 0)
>   {
>   perror ("open");
>   exit(1);
>   }
> 
>   signal (SIGALRM, empty);
>   alarm (1);
> 
> a = read(fd, buf, 511);
> 
> while (a && a != -1) a = read(fd, buf, 511);
> 
>   if (a == -1)
>   {
>   perror ("read");
>   exit(1);
>   }
>   else printf ("EOF\n");
> 
> exit(0);
> }
> 
> I open /tmp/nic and run compiled program.
> There should be error EINTR in read, but isn't.
> Why ?
> 

The test program contains several errors. Here is a 'fixed' version.

#include 
#include 
#include 
#include 
#include 
#include 
#include 

static void empty(int sig)
{
printf ("hello\n");
return;
}

void main()
{
int fd, a;
struct sigaction sa;
char buf[512];

if (fd = open("/dev/zero", O_RDONLY) < 0)
{
perror ("open");
exit(1);
}
sigaction(SIGALRM, NULL, );
sa.sa_handler = empty;
sa.sa_flags   = SA_INTERRUPT;
sigaction(SIGALRM, , NULL);
alarm (1);

while ((a = read(fd, buf, 511)) > 0)
;

if (a == -1)
{
perror ("read");
exit(1);
}
else printf ("EOF\n");
exit(0);
}


First, you need to read something that can be interrupted. A 511 byte
read from a small file will probably never be interrupted. The code
can be spending much more time in the 'while (funny stuff)' loop than
it takes to read that file.

I chose to read from an infinite-size 'file'.

Second, your 'C' runtime library probably defaults to non-BSD signals.
That is to say, the "SA_RESTART" bit is probably set in the flags.
To get the system call interrupted, you need to have that bit clear.
The way to do it is with sigaction(); signal() is just not capable
of doing what you want, now that 'C' runtime libraries default to
POSIX-signal behavior rather than BSD-signals.

FYI, main() can never be void. It must return an 'int'.
  while (a && a != -1) a = read(fd, buf, 511);
doesn't make much sense. (a && a) is either TRUE or FALSE. It
will, therefore NEVER be -1. Maybe you meant (a & a)? If so,
why not just (a != -1) or (a > 0) ?

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: goodbye

[Mike Fedyk]

On Sat, Apr 07, 2001 at 11:17:29PM -0500, David Fries wrote:
> There is a lot of comfort looking at /var/log/mail.log and seeing mail
> accepted by the computer servicing the other person's account.  Now
> all I have is, accepted by university, hope it gets there...
> 
While I operate my own mail server at home and work, and agree that having
logs for the entire transaction is great, I may have a solution for you:

Setup your email program to bcc to an address that is also on the internet
(bigfoot.com is what I use) and have it forward to your account at the
university.  That way, when it comes back you'll have a good idea that the
other recipient on the internet received the message also.

Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: List of all-zero .data variables in linux-2.4.3 available

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Ulrich Drepper <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> "Adam J. Richter" <[EMAIL PROTECTED]> writes:
> 
> > >Shouldn't a compiler be able to deal with this instead?
> > 
> > Yes.
> 
> No.  gcc must not do this.  There are situations where you must place
> a zero-initialized variable in .data.  It is a programmer problem.
> 

And this cannot be decorated with __attribute__((section(".data")))
why?

-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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 8139too: defunct threads

[Rod Stewart]

On Thu, 12 Apr 2001, Andrew Morton wrote:
> Rod Stewart wrote:
> >
> > On Thu, 12 Apr 2001, Andrew Morton wrote:
> > > Rod Stewart wrote:
> > > >
> > > > Hello,
> > > >
> > > > Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct
> > > > thread for each device we have; if the driver is built into the kernel.
> > > > If the driver is built as a module, no defunct threads appear.
> > >
> > > What is the parent PID for the defunct tasks?  zero?
> >
> > According to ps, 1
>
> Ah.  Of course.  All (or most) kernel initialisation is
> done by PID 1.  Search for "kernel_thread" in init/main.c
>
> So it seems that in your setup, process 1 is not reaping
> children, which is why this hasn't been reported before.
> Is there something unusual about your setup?

One box is standard PIII with RH 7.0, the other is a custom Crusoe TM5400
board.  But from further investigation it appears to be a kernel config
option.  As I've got a 2.4.0 kernel which has very little compiled in and
not showing the problem and another kernel which has many more networking
options built in and showing the problem.  I've seen this problem
since 2.4.0.test11.

I'll send a note once I find the config option which is causing this,
probably tomorrow.

Thanks,
-Rms

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[upatch #11] 2.4.3-ac5 - static const char *foo to static char foo[]

[Francois Romieu]

Hello,

  it compiles fine and there is no MAINTAINER entry for it nor specific
email address in the source file.

diff -u --recursive linux-2.4.3-ac5.orig/drivers/char/keyboard.c 
linux-2.4.3-ac5/drivers/char/keyboard.c
--- linux-2.4.3-ac5.orig/drivers/char/keyboard.cThu Apr 12 20:23:06 2001
+++ linux-2.4.3-ac5/drivers/char/keyboard.c Thu Apr 12 21:10:37 2001
@@ -632,8 +632,8 @@
 
 static void do_pad(unsigned char value, char up_flag)
 {
-   static const char *pad_chars = "0123456789+-*/\015,.?()";
-   static const char *app_map = "pqrstuvwxylSRQMnnmPQ";
+   static char pad_chars[] = "0123456789+-*/\015,.?()";
+   static char app_map[] = "pqrstuvwxylSRQMnnmPQ";
 
if (up_flag)
return; /* no action, if this is a key release */
@@ -689,7 +689,7 @@
 
 static void do_cur(unsigned char value, char up_flag)
 {
-   static const char *cur_chars = "BDCA";
+   static char cur_chars[] = "BDCA";
if (up_flag)
return;
 

-- 
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 4th try: i386 rw_semaphores fix

[D . W . Howells]

Andrew Morton wrote:
> It still doesn't compile with gcc-2.91.66 because of the "#define
> rwsemdebug(FMT, ...)" thing. What can we do about this? 

Hmmm... It probably needs to be made conditional on the version of the 
compiler by means of the macros that hold the version numbers.

> I cooked up a few more tests, generally beat the thing 
> up. This code works. Good stuff. I'll do some more testing 
> later this week - put some delays inside the semaphore code 
> itself to stretch the timing windows, but I don't see how 
> it can break it. 

Excellent. I tried to keep it as simple as possible to make it easier to test 
and follow.

> Manfred says the rep;nop should come *before* the memory 
> operation, but I don't know if he's been heard... 

Probably... It's copied directly out of the spinlock stuff. I noticed it at 
the time, but it didn't stick in my memory.

> The spin_lock_irqsave() in up_read/up_write shouldn't be 
> necessary plus it puts the readers onto the 
> waitqueue with add_wait_queue_exclusive, so an up_write 
> will only release one reader.

Not so... have you looked at the new __wait_ctx_common() function? It 
actually ignores the exclusive flag since it uses other criteria as to whom 
to wake. All the add_wait_queue_exclusive() function does is put the process 
on the _back_ of the queue as far as rwsems are concerned.

> Other architectures need work. 
> If they can live with a spinlock in the fastpath, then 
> the code at http://www.uow.edu.au/~andrewm/linux/rw_semaphore.tar.gz 
> is bog-simple and works.

Sorry to pre-empt you, but have you seen my "advanced" patch? I sent it to 
the list in an email with the subject:

[PATCH] i386 rw_semaphores, general abstraction patch

I added a general fallback implementation with the inline implementation 
functions written wholly in C and using spinlocks.

> Now I think we should specify the API a bit: 

Agreed... I'll think more in it on Tuesday, though... after Easter.

Your points, however, look fairly reasonable.

> Perhaps the writer-wakes-multiple 
> readers stuff isn't happening

It does. Using my test program & module, try:

driver -5 & sleep 1; driver 100 &

Keep doing "ps", and you'll see all the reader processes jump into the S 
state at the same time, once all the writers have finished. You may need to 
increase the delay between the ups and downs in the module to see it clearly.

David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML2 1.0.0 doesn't remember configuration changes

[Ingo Oeser]

On Wed, Apr 11, 2001 at 10:06:46PM -0400, [EMAIL PROTECTED] wrote:
> Editconfig was a mistake.  OK, I think I understand the rules now.  Is it:
> 
> (1) First, try to read from .config
> (2) If .config doesn't exist, read from $(ARCH)/defconfig
> 
> ?

Right. But with the following constraints:

   make oldconfig takes _any_ .config from _any_ kernel and builds a
   new one for _this_ kernel asking any remaining questions
   
   make xconfig, make menuconfig, make config take a .config from
   _this_ kernel and configure for _this_ kernel

   if they don't find and .config, then they fall back to
   $(ARCH)/defconfig


Would be nice, if CML2 works like this too, because it's not nice
to go through all the options again, if I install a new kernel or
just want to change my current kernel config add a module.

But your CML2 is sure great work.

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
  been there and had much fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: No 100 HZ timer!

[Bret Indrelee]

On Thu, 12 Apr 2001, george anzinger wrote:
> Bret Indrelee wrote:
> > Keep all timers in a sorted double-linked list. Do the insert
> > intelligently, adding it from the back or front of the list depending on
> > where it is in relation to existing entries.
> 
> I think this is too slow, especially for a busy system, but there are
> solutions...

It is better than the current solution.

The insert takes the most time, having to scan through the list. If you
had to scan the whole list it would be O(n) with a simple linked list. If
you insert it from the end, it is almost always going to be less than
that.

The time to remove is O(1).

Fetching the first element from the list is also O(1), but you may have to
fetch several items that have all expired. Here you could do something
clever. Just make sure it is O(1) to determine if the list is empty.

[ snip ]
> > The real trick is to do a lot less processing on every tick than is
> > currently done. Current generation PCs can easily handle 1000s of
> > interrupts a second if you keep the overhead small.
> 
> I don't see the logic here.  Having taken the interrupt, one would tend
> to want to do as much as possible, rather than schedule another
> interrupt to continue the processing.  Rather, I think you are trying to
> say that we can afford to take more interrupts for time keeping.  Still,
> I think what we are trying to get with tick less timers is a system that
> takes FEWER interrupts, not more.

The system should be CAPABLE of handling 1000s of interrupts without
excessive system load.

The actual number of interrupts would be reduced if we adjusted the
interrupt interval based on the head of the list.

Two different things.

-Bret

--
Bret Indrelee |  Sometimes, to be deep, we must act shallow!
[EMAIL PROTECTED]   |  -Riff in The Quatrix

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 8139too: defunct threads

[Alan Cox]

> Plus it would mean that the kernel requires, for its
> correct operation, that process "1" is a child reaper.
> Is this a good thing?

That is already required. The rest of the reparenting functionality is also
in kernel/exit.c already

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

O_DIRECT

[Andrea Arcangeli]

I wrote the O_DIRECT zerocopy raw I/O support (dma from disk to the userspace
memory through the filesystem). The patch against 2.4.4pre2 + rawio-3 is here:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre2/o_direct-1

Only ext2 is supported at the moment, but extending it to the other fses that
use the common code helper functions is trivial (I guess Chris will take care
of reiserfs, it may be an option to not do tail packing for files opened with
O_DIRECT so you can dma from userspace the tail as well).

The above patch depends on the rawio performance improvement patch posted to
the list a few days ago here (latest version here):


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre2/rawio-3

The rawio-3 patch is suggested for integration, certainly it's saner and faster
than mainline 2.4 (a note of credit: part of the fixes in the rawio-3 patch
are merged from SCT's patch).

To benchmark the improvement given by O_DIRECT, I hacked bonnie to open the
file with O_DIRECT in the "block" tests and I changed the chunk size to 1MB (so
that the blkdev layer will send large requests the hardware). Then I made a
comparision between the bonnie numbers w/o and w/ O_DIRECT (the -o_direct param
to bonnie now selects the O_DIRECT or standard behaviour, I also added
a -fast param to skip the slow seek test).  I cutted out the numbers that
aren't using O_DIRECT to make the report more readable.

Those are still preliminary results on a mid machine: 2-way SMP PII 450mhz with
128mbyte of ram on a lvm volume (physical volume is a single IDE disk, so not
striped and all in the same harddisk) using a working set of 400mbytes.

without using o_direct:
  ---Sequential Output ---Sequential Input-- --Random--
  -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
   MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
  400    12999 12.1  5918 10.8    13412 12.1   xxx  xxx
  400    12960 12.3  5896 11.1    13520 13.3   xxx  xxx

with o_direct:
  ---Sequential Output ---Sequential Input-- --Random--
  -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
   MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
  400    12810  1.8  5855  1.6    13529  1.2   xxx  xxx
  400    12814  1.8  5866  1.7    13519  1.3   xxx  xxx

As you can see there's a small performance drop in writes and I guess it's
beause we are some more synchronous and it takes a bit more of time between the
completion of one I/O request and the the sumbission of a new one and that's ok.
(if you really care that litte difference can be covered by using async-io)

The most interesting part is the cpu load that just decreases down to 1/2%
during all the I/O and this is ""only"" a 13mbyte/sec harddisk and on
top of lvm. I didn't run any benchmark on any faster disk and without lvm but
O_DIRECT is the obvious way to go for streaming endless data to disk (possibly
at 100mbyte/sec or more) like in multimedia or scientific apps and of course
with DBMS that do their own userspace management of the I/O cache in shm.

>From a DBMS point of view the only downside of the O_DIRECT compared to the
rawio device is: 1) walking of the meatadata in the fs [but that is in turn
_the_ feature that gives more flexibility to the administrator] and 2) O_DIRECT
cannot be done on a shared disk without also using a filesystem like GFS
because the regular fs doesn't know how to keep the metadata coherent across
multiple hosts.

Programming-wise the coherency of the cache under the direct I/O is the only
non obvious issue, what I did is been simply to flush the data (nothing of the
metadata!) before starting the direct I/O and to discard all the unmapped
pagecache from the inode after any direct write or to invalidate them (clear
all dirty bits in the pagecache and on the overlapped buffers if the page was
mapped so the next read through the cache will hit the disk again). This seems
safe even if it somehow breaks the semantics of mmaps (for example if the file
is mmaped during the o_direct the mmap view won't be updated, but o_direct
after all is magic anyways in the way it requires alignment of address and size
of the user buffer so this doesn't seem to be a problem... and not keeping
perfect coherency of the not useful cases increases performance of the useful
cases. I didn't see a value in updating the cache, if you want to update the
cache in a mapping simply don't use O_DIRECT ;).

To invalidate the cache I couldn't use the invalidate_inode_pages and
truncate_inode_pages, the former was too weak (I cannot simply skip the
stuff that is not just clean and unmapped or the user could never see
the updates afterwards when he stops using O_DIRECT), and the latter was too
aggressive (it 

Re: 8139too: defunct threads

[Andrew Morton]

Rod Stewart wrote:
> 
> On Thu, 12 Apr 2001, Andrew Morton wrote:
> > Rod Stewart wrote:
> > >
> > > Hello,
> > >
> > > Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct
> > > thread for each device we have; if the driver is built into the kernel.
> > > If the driver is built as a module, no defunct threads appear.
> >
> > What is the parent PID for the defunct tasks?  zero?
> 
> According to ps, 1

Ah.  Of course.  All (or most) kernel initialisation is
done by PID 1.  Search for "kernel_thread" in init/main.c

So it seems that in your setup, process 1 is not reaping
children, which is why this hasn't been reported before.
Is there something unusual about your setup?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: new aic7xxx driver problems

[Justin T. Gibbs]

>> Can you elaborate on what you had to modify ?
>
>I just added AHC_ULTRA to the features of 7850
>
>AHC_AIC7850_FE = AHC_SPIOCAP|AHC_AUTOPAUSE|AHC_TARGETMODE|AHC_ULTRA,
>  ^^

What's the PCI id of the card you are using?

>Plain v6.1.11 hangs. It prints scsi0: blah blah scsi1: sdfdfgsg, I hear the cd
>spinning up and nothing more.

Did you apply a patch, or upgrade using the tar file?  If the latter,
you're missing some changes to the SCSI layer that make the initial
bus settle delay implimentation more sane.

--
Justin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Incorect signal handling ?

[Daniel Podlejski]

Hi,

there is litlle programm:

#include 
#include 
#include 
#include 
#include 
#include 
#include 

static void empty(int sig)
{
printf ("hello\n");
return;
}

void main()
{
int fd, a;
char buf[512];

if (fd = open("/tmp/nic", O_RDONLY) < 0)
{
perror ("open");
exit(1);
}

signal (SIGALRM, empty);
alarm (1);

a = read(fd, buf, 511);

while (a && a != -1) a = read(fd, buf, 511);

if (a == -1)
{
perror ("read");
exit(1);
}
else printf ("EOF\n");

exit(0);
}

I open /tmp/nic and run compiled program.
There should be error EINTR in read, but isn't.
Why ?

-- 
Daniel Podlejski <[EMAIL PROTECTED]>
   ... Here await the birth of the son
   The seventh, the heavenly, the chosen one ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 8139too: defunct threads

[Andrew Morton]

Alan Cox wrote:
> 
> >  swapper doesn't know how to reap children, and
> > AFAIK there's no way for a kernel thread to fully clean itself
> > up.  This is always done by the parent.
> 
> Make daemonize() move threads with parent 0 to parent 1

Reparenting would require diving inside this lot:

/* 
 * pointers to (original) parent process, youngest child, younger sibling,
 * older sibling, respectively.  (p->father can be replaced with 
 * p->p_pptr->pid)
 */
struct task_struct *p_opptr, *p_pptr, *p_cptr, *p_ysptr, *p_osptr;
struct list_head thread_group;

plus maybe rewriting pgrps, sessions, gids, etc.  Challenging.

Plus it would mean that the kernel requires, for its
correct operation, that process "1" is a child reaper.
Is this a good thing?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: badly punctuated parameter list in `#define' (2.4.3-ac5 and 2 .4.4 -pre2)

[Wayne . Brown]

Drat, I just noticed my #$@%&$ email program word-wrapped some of the long
lines.  The four lines that contain just while(0) should be appended (preceded
by a space) to the lines just previous to them.

Wayne




Christoph Hellwig <[EMAIL PROTECTED]> on 04/12/2001 03:16:38 PM

To:   Wayne Brown/Corporate/Altec@Altec
cc:   [EMAIL PROTECTED], [EMAIL PROTECTED]

Subject:  Re: badly punctuated parameter list in `#define' (2.4.3-ac5 and 2 .4.4
  -pre2)



On Thu, Apr 12, 2001 at 03:08:28PM -0500, [EMAIL PROTECTED] wrote:
> >old compiler.  The right ifdef seems to be:
>
> >
> >  #if __GNUC__ == 2 && __GNUC_MINOR__ < 95
> >
> >Could you test it this way?
>
> Yes, that works for me.  Is this the sort of thing you had in mind?

Yes.
Linus any chance to apply the following patch?

 Christoph

>
> Wayne
>
>
> --- include/asm-i386/rwsem.h.old   Thu Apr 12 14:50:08 2001
> +++ include/asm-i386/rwsem.h  Thu Apr 12 14:54:14 2001
> @@ -20,18 +20,24 @@
>  #include 
>  #include 
>
> +#if __GNUC__ == 2 && __GNUC_MINOR__ < 95
> +
> +/* old gcc */
>  #if RWSEM_DEBUG
> -#define rwsemdebug(FMT,...) do { if (sem->debug) printk(FMT,__VA_ARGS__); }
> while(0)
> +#define rwsemdebug(FMT, ARGS...) do { if (sem->debug) printk(FMT,##ARGS); }
> while(0)
>  #else
> -#define rwsemdebug(FMT,...)
> +#define rwsemdebug(FMT, ARGS...)
>  #endif
>
> -/* old gcc */
> +#else
> +
>  #if RWSEM_DEBUG
> -//#define rwsemdebug(FMT, ARGS...) do { if (sem->debug) printk(FMT,##ARGS); }
> while(0)
> +#define rwsemdebug(FMT,...) do { if (sem->debug) printk(FMT,__VA_ARGS__); }
> while(0)
>  #else
> -//#define rwsemdebug(FMT, ARGS...)
> +#define rwsemdebug(FMT,...)
>  #endif
> +
> +#endif /* __GNUC__ == 2 && __GNUC_MINOR__ < 95 */
>
>  #ifdef CONFIG_X86_XADD
>  #include  /* use XADD based semaphores if possible */
>
---end quoted text---

--
Of course it doesn't work. We've performed a software upgrade.




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: new aic7xxx driver problems

[Giuliano Pochini]

> >I have two Adaptec 2930CU (ultra narrow) cards. I modified the driver to
> >make them work in ultra mode.
>
> Can you elaborate on what you had to modify ?

I just added AHC_ULTRA to the features of 7850

AHC_AIC7850_FE  = AHC_SPIOCAP|AHC_AUTOPAUSE|AHC_TARGETMODE|AHC_ULTRA,
  ^^

> >Apr  3 23:05:10 Jay kernel: scsi1:0:4:0: Attempting to queue an ABORT message
>
> Please run your system with aic7xxx=verbose and send me the resulting
> messages.  You should also upgrade to v6.1.11 of the driver.

Plain v6.1.11 hangs. It prints scsi0: blah blah scsi1: sdfdfgsg, I hear the cd
spinning up and nothing more. The system doesn't crash completely because the
cursor don't stop blinking (I don't use a hw cursor). I think it's just
waiting
something will never arrive.

(ppc750)

Bye.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: scheduler went mad?

[Rik van Riel]

On Thu, 12 Apr 2001, Szabolcs Szakacsits wrote:

> You mean without dropping out_of_memory() test in kswapd and calling
> oom_kill() in page fault [i.e. without additional patch]?

No.  I think it's ok for __alloc_pages() to call oom_kill()
IF we turn out to be out of memory, but that should not even
be needed.

Also, when a task in __alloc_pages() is OOM-killed, it will
have PF_MEMALLOC set and will immediately break out of the
loop. The rest of the system will spin around in the loop
until the victim has exited and then their allocations will
succeed.

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com.br/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: badly punctuated parameter list in `#define' (2.4.3-ac5 and 2 .4.4 -pre2)

[Christoph Hellwig]

On Thu, Apr 12, 2001 at 03:08:28PM -0500, [EMAIL PROTECTED] wrote:
> >old compiler.  The right ifdef seems to be:
> 
> >
> >  #if __GNUC__ == 2 && __GNUC_MINOR__ < 95
> >
> >Could you test it this way?
> 
> Yes, that works for me.  Is this the sort of thing you had in mind?

Yes.
Linus any chance to apply the following patch?

Christoph

> 
> Wayne
> 
> 
> --- include/asm-i386/rwsem.h.old   Thu Apr 12 14:50:08 2001
> +++ include/asm-i386/rwsem.h  Thu Apr 12 14:54:14 2001
> @@ -20,18 +20,24 @@
>  #include 
>  #include 
> 
> +#if __GNUC__ == 2 && __GNUC_MINOR__ < 95
> +
> +/* old gcc */
>  #if RWSEM_DEBUG
> -#define rwsemdebug(FMT,...) do { if (sem->debug) printk(FMT,__VA_ARGS__); }
> while(0)
> +#define rwsemdebug(FMT, ARGS...) do { if (sem->debug) printk(FMT,##ARGS); }
> while(0)
>  #else
> -#define rwsemdebug(FMT,...)
> +#define rwsemdebug(FMT, ARGS...)
>  #endif
> 
> -/* old gcc */
> +#else
> +
>  #if RWSEM_DEBUG
> -//#define rwsemdebug(FMT, ARGS...) do { if (sem->debug) printk(FMT,##ARGS); }
> while(0)
> +#define rwsemdebug(FMT,...) do { if (sem->debug) printk(FMT,__VA_ARGS__); }
> while(0)
>  #else
> -//#define rwsemdebug(FMT, ARGS...)
> +#define rwsemdebug(FMT,...)
>  #endif
> +
> +#endif /* __GNUC__ == 2 && __GNUC_MINOR__ < 95 */
> 
>  #ifdef CONFIG_X86_XADD
>  #include  /* use XADD based semaphores if possible */
> 
---end quoted text---

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: real-time file monitoring at the kernel level

[Ryan Butler]

you might check out fam and imon (fam is userspace, imon is a kernel patch).

Both are open source SGI tools, imon is the inode monitor.

Both can be found at http://oss.sgi.com


>Hello,
>
>I was wondering if anyone has a patch, or is working on something for what
>im looking for, or if they are interested in an idea i have (forgive me if
>this is someone elses idea, ill give credit to them), for file monitoring
>at the kernel level.
>I have put up a brief explanation of what im looking for at
>http://flog.uncontrolled.org/, but in a nutshell, it is this:
>
>a kernel patch (or module) that would allow me to have, say, /proc/flog,
>which shows real-time file monitoring information, which could be tail
>-f'd like so:
>
>root@server~# tail -f /proc/flog
>modify: root "/var/log/auth.log" 2410150229
>access: root "/etc/passwd" 2410150324
>modify: root "/etc/passwd" 2410150441
>remove: root "/var/log/auth.log" 2410150502
>create: root "/usr/bin/.. /" 2410150534
>create: root "/usr/bin/.. /backdoor" 2410150627
>modify: bob "/home/bob/mailbox" 2410150854
>modify: root "/var/www/htdocs/index.html" 2410150927
>
>the above would describe a theoretical breakin from a hacker, which i
>believe would be extremely useful in intrusion detection. My idea of this
>is further outlined at http://flog.uncontrolled.org/, including
>theoretical usage, practice, description, etc.
>The reason i ask the linux-kernel community is my coding ability does not
>allow me to hack at the kernel, and so i would need help with this, or any
>other information that would point me in the right direction that im
>looking for.
>
>If someone is interested in this, or has any information whatsoever,
>please let me know!
>
>thanks,
>[EMAIL PROTECTED]
>
>PS: im not looking for LIDS
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: badly punctuated parameter list in `#define' (2.4.3-ac5 and 2.4.4 -pre2)

[Wayne . Brown]

Christoph Hellwig <[EMAIL PROTECTED]> wrote:

>So the /* old gcc */ part should probably be enabled based on a define for the

>old compiler.  The right ifdef seems to be:

>
>  #if __GNUC__ == 2 && __GNUC_MINOR__ < 95
>
>Could you test it this way?

Yes, that works for me.  Is this the sort of thing you had in mind?

Wayne


--- include/asm-i386/rwsem.h.old   Thu Apr 12 14:50:08 2001
+++ include/asm-i386/rwsem.h  Thu Apr 12 14:54:14 2001
@@ -20,18 +20,24 @@
 #include 
 #include 

+#if __GNUC__ == 2 && __GNUC_MINOR__ < 95
+
+/* old gcc */
 #if RWSEM_DEBUG
-#define rwsemdebug(FMT,...) do { if (sem->debug) printk(FMT,__VA_ARGS__); }
while(0)
+#define rwsemdebug(FMT, ARGS...) do { if (sem->debug) printk(FMT,##ARGS); }
while(0)
 #else
-#define rwsemdebug(FMT,...)
+#define rwsemdebug(FMT, ARGS...)
 #endif

-/* old gcc */
+#else
+
 #if RWSEM_DEBUG
-//#define rwsemdebug(FMT, ARGS...) do { if (sem->debug) printk(FMT,##ARGS); }
while(0)
+#define rwsemdebug(FMT,...) do { if (sem->debug) printk(FMT,__VA_ARGS__); }
while(0)
 #else
-//#define rwsemdebug(FMT, ARGS...)
+#define rwsemdebug(FMT,...)
 #endif
+
+#endif /* __GNUC__ == 2 && __GNUC_MINOR__ < 95 */

 #ifdef CONFIG_X86_XADD
 #include  /* use XADD based semaphores if possible */


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SCSI Tape Corruption - update 2

[Lorenzo Marcantonio]

On Thu, 12 Apr 2001, Gérard Roudier wrote:

> using a sym53c875 controller. In this case, kernel 2.2 was fine.
>
> > Now I'll build some old 2.2 kernel to try...
>
> If 2.2 is ok with your tape, a software error in 2.4 gets very likely, in
> my opinion.

Well, the 2.2 distributed with Mandrake 7.2 works fine ... :)

Hmmm... 32 CONSECUTIVE bytes are a very peculiar error. What can it be?

Still experimenting...

-- Lorenzo Marcantonio

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: List of all-zero .data variables in linux-2.4.3 available

[Adam J. Richter]

>Thanks, but Andrey Panin did you one better -- he produced a patch which
>fixes up a good number of these.  You should follow lkml more closely :)

I missed that patch and have been unable to find it on google/dejanews.
However, my point is to provide an exhaustive list with sizes (and the tool
for generating it), to make it easier to spot and prioritize ones that
may have been missed.

Anyhow, thanks for the tip.  Perhaps I should run this program and
post results again on a subsequent kernel release (presumably
with Andrey's patch), although anyone else can run this program
just as easily.

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."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: generic_osync_inode() broken?

[Marcelo Tosatti]

On Thu, 12 Apr 2001, Marcelo Tosatti wrote:

> 
> On Thu, 12 Apr 2001, Linus Torvalds wrote:
> 
> > On Thu, 12 Apr 2001, Marcelo Tosatti wrote:
> > >
> > > Comments?
> > >
> > > --- fs/inode.c~   Thu Mar 22 16:04:13 2001
> > > +++ fs/inode.cThu Apr 12 15:18:22 2001
> > > @@ -347,6 +347,11 @@
> > >  #endif
> > >
> > >   spin_lock(_lock);
> > > + while (inode->i_state & I_LOCK) {
> > > + spin_unlock(_lock);
> > > + __wait_on_inode(inode);
> > > + spin_lock(_lock);
> > > + }
> > >   if (!(inode->i_state & I_DIRTY))
> > >   goto out;
> > >   if (datasync && !(inode->i_state & I_DIRTY_DATASYNC))
> > 
> > Ehh.
> > 
> > Why not just lock the inode around the thing?
> > 
> > The above looks rather ugly.
> 
> You mean writing a function called "lock_inode()" or whatever to basically
> do what I did ? 

Oh well, its still bad.

We drop the inode_lock before calling write_inode_now() (which is broken,
too :)), which means someone can set I_LOCK under us.

I'll send you a patch to fix that one (and other callers of
write_inode_now()) later.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Request for Configure.help entries for newly added config options.

[Steven Cole]

As of kernel 2.4.3-ac5, there are now 574 config options which have
no help text in Configure.help. I believe these are not derived options,
but setable options which could use a help entry.

Here is a list of these items which have been introduced very recently.
Each group is incremental, versus 2.4.3-ac[n-1].

Of course, there are 548 other options which also should have texts.

If you see one of your options here, please consider generating a patch
for Configure.help, or send me the information and I'll do the rest.

Thanks,
Steven

2.4.3-ac5

CONFIG_IA64_EFIVARS
CONFIG_ITANIUM
CONFIG_MCKINLEY
CONFIG_MCKINLEY_A0_SPECIFIC
CONFIG_MCKINLEY_ASTEP_SPECIFIC

2.4.3-ac4

CONFIG_ARCH_CLPS711X
CONFIG_ARCH_P720T
CONFIG_ARM_THUMB
CONFIG_CPU_ARM1020
CONFIG_CPU_ARM610
CONFIG_CPU_ARM710
CONFIG_CPU_ARM720T
CONFIG_CPU_ARM920T
CONFIG_CPU_SA110
CONFIG_DASD_DIAG
CONFIG_DEBUG_CLPS711X_UART2
CONFIG_DEBUGSYM
CONFIG_GCOV
CONFIG_GPROF
CONFIG_HOSTFS
CONFIG_NET_UM_ETH
CONFIG_NET_UMN
CONFIG_SA1100_PANGOLIN
CONFIG_SA1100_SHERMAN
CONFIG_SSL

2.4.3-ac3

none

2.4.3-ac2

CONFIG_GEMINI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: List of all-zero .data variables in linux-2.4.3 available

[Adam J. Richter]

>>  I am aware of a couple of cases where code relied on static
>> variables being allocated contiguously, but, in both cases, those
>> variables were either all zeros or all non-zeros, so my proposed
>> change would not break such code.

>Continuous placement is not the only property defined by
>initialization.  There are many more.  You cannot change this since it
>will quite a few programs and libraries and subtle and hard to
>impossible to identify ways.  Simply educate programmers to not
>initialize.

If it is so simple to "educate" programmers on this,
could you provide and example or some specifics, especially on why
this should not even be a compiler option?  Surely that will save
you some iterations in this discussion.

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."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: List of all-zero .data variables in linux-2.4.3 available

[Jeff Garzik]

"Adam J. Richter" wrote:
> For anyone who is interested, I have produced a list of all
> of the .data variables that contain all zeroes and could be moved to
> .bss within the kernel and all of the modules (all of the modules
> that we build at Yggdrasil for x86, which is almost all).  These
> are global or static variables that have been declared

Thanks, but Andrey Panin did you one better -- he produced a patch which
fixes up a good number of these.  You should follow lkml more closely :)

-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH(?): linux-2.4.4-pre2: fork should run child first

[Adam J. Richter]

Hubertus Franke <[EMAIL PROTECTED]> writes:

>Try this ... this will guarantee that (p->counter) > (current->counter)
>and it seems not as radical

> p->counter = (current->counter + 1) >> 1;
>current->counter = (current->counter - 1) >> 1;
>if (!current->counter)
>current->need_resched = 1;

>instead of this


>-   p->counter = (current->counter + 1) >> 1;
>-   current->counter >>= 1;
>-   if (!current->counter)
>-   current->need_resched = 1;
>+   p->counter = current->counter;
>+   current->counter = 0;
>+   current->need_resched = 1;


No.  I tried your change and also tried it with setting
current->need_resched to 1 in all cases, and it still seems to run the
parent first in at least half of the tries.  Evidently,
current->counter must be zero to make the currently running process
give up the CPU immediately, which is the important thing (so that the
parent does not touch its virtual memory for a while).

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."


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: List of all-zero .data variables in linux-2.4.3 available

[Ulrich Drepper]

"Adam J. Richter" <[EMAIL PROTECTED]> writes:

>   I am aware of a couple of cases where code relied on static
> variables being allocated contiguously, but, in both cases, those
> variables were either all zeros or all non-zeros, so my proposed
> change would not break such code.

Continuous placement is not the only property defined by
initialization.  There are many more.  You cannot change this since it
will quite a few programs and libraries and subtle and hard to
impossible to identify ways.  Simply educate programmers to not
initialize.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkml]Re: [PATCH] matroxfb and mga XF4 driver coexistence...

[Chris Meadors]

On Thu, 12 Apr 2001, [EMAIL PROTECTED] wrote:

> Of course, but if we can fix the problem by making the kernel smaller,
> what possible motive could you have for opposing it other than 'but it
> doesn't solve _my_ problems!' ?

Agreed.  The only thing I was thinking, was if the kernel is doing the
right thing now, it shouldn't be forced to work around a bug in XFree.
By not "fixing" the kernel, the XFree team would be forced to do the right
thing.

As for me, I'm going to see about getting the matroxfb working, so if the
patch goes in I'll be able to use a nice 132 character wide terminal
again.  And I'm getting addicted to dual head in X, might be fun on the
console too.

-Chris
-- 
Two penguins were walking on an iceberg.  The first penguin said to the
second, "you look like you are wearing a tuxedo."  The second penguin
said, "I might be..." --David Lynch, Twin Peaks

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Proposal for a new PCI function call

[Jeff Garzik]

Steve Modica wrote:
> 
> Hi All,
> 
> We found recently that the acenic driver for the 3com gigabit ethernet card does
> not enable 64 bit DMAs.  (this is done by setting the appropriate mask in
> pci_dev->dma_mask).
> 
> Jes suggested that the appropriate way to fix this would be to create a function
> like pci_enable_dma64 and then have the driver call that, rather than directly
> setting this value (a small handful of drivers do this now).
> 
> I think the function idea would let us do some sanity checking to make sure
> drivers weren't setting this to 64bit on non-64 bit busses and stuff.

pci_set_dma_mask.  Modify that to do the additional checks you need.

Nobody should be setting dma_mask directly anymore, it should be done
through this function.

Jeff


-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 8139too: defunct threads

[Rod Stewart]

On Thu, 12 Apr 2001, Andrew Morton wrote:
> Rod Stewart wrote:
> >
> > Hello,
> >
> > Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct
> > thread for each device we have; if the driver is built into the kernel.
> > If the driver is built as a module, no defunct threads appear.
>
> What is the parent PID for the defunct tasks?  zero?

According to ps, 1

[root@stewart-nw34 networking]# ps alexw
  F   UID PID  PPID PRI  NI   VSZ  RSS WCHAN  STAT TTY TIME  COMMAND
044 0  14 1   9   0 00 do_exi Z?  0:00 [eth0 ]
044 0  15 1   9   0 00 do_exi Z?  0:00 [eth1 ]
044 0  16 1   9   0 00 do_exi Z?  0:00 [eth2 ]
040 0 240 1   9   0 00 rtl813 SW   ?  0:00 [eth0]

-Rms

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: scanner problem

[Gérard Roudier]

On Thu, 12 Apr 2001 [EMAIL PROTECTED] wrote:

> hi,
> 
> when trying to scan with xsane and "agfa snapscan 1236s", i get the
> following message:
> 
> Attached scsi generic sg2 at scsi0, channel 0, id 5, lun 0, type 6
> sym53c895-0-<5,*>: target did not report SYNC.

This message is just a warning. If your scanner does not support
synchronous data transfers, then it is ok. You may want to check the doc
of the device on this point.

> sym53c895-0-<5,0>: extraneous data discarded.
> sym53c895-0-<5,0>: COMMAND FAILED (89 0) @cff3d000.

This is the way the driver signals data overrun. Btw, I never used xsane.
If this tool has some trace mode that tells what SCSI commands are sent to
the device, this would help to get such traces.

> what can i do about this?

At least, try to catch the SCSI commands that are sent to the device, and
report them.

  Gérard.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: generic_osync_inode() broken?

[Marcelo Tosatti]

On Thu, 12 Apr 2001, Linus Torvalds wrote:

> On Thu, 12 Apr 2001, Marcelo Tosatti wrote:
> >
> > Comments?
> >
> > --- fs/inode.c~ Thu Mar 22 16:04:13 2001
> > +++ fs/inode.c  Thu Apr 12 15:18:22 2001
> > @@ -347,6 +347,11 @@
> >  #endif
> >
> > spin_lock(_lock);
> > +   while (inode->i_state & I_LOCK) {
> > +   spin_unlock(_lock);
> > +   __wait_on_inode(inode);
> > +   spin_lock(_lock);
> > +   }
> > if (!(inode->i_state & I_DIRTY))
> > goto out;
> > if (datasync && !(inode->i_state & I_DIRTY_DATASYNC))
> 
> Ehh.
> 
> Why not just lock the inode around the thing?
> 
> The above looks rather ugly.

You mean writing a function called "lock_inode()" or whatever to basically
do what I did ? 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 8139too: defunct threads

[Alan Cox]

>  swapper doesn't know how to reap children, and
> AFAIK there's no way for a kernel thread to fully clean itself
> up.  This is always done by the parent.

Make daemonize() move threads with parent 0 to parent 1

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: badly punctuated parameter list in `#define' (2.4.3-ac5 and 2.4.4 -pre2)

[Christoph Hellwig]

In article <[EMAIL PROTECTED]> you wrote:
>
> When compiling 2.4.3-ac5 (and also 2.4.4-pre2) I get this:
>
> /usr/src/linux-2.4.3-ac5/include/asm/rwsem.h:26: badly punctuated parameter list
>  in `#define'
>
> This appears to be due to some code in rwsem.h that is written for a different
> version of gcc. (I'm still using gcc-2.91.66 as specified in
> Documentation/Changes.)  It works for me if I replace it with the code in the
> section labeled /* old gcc */.  Here's a patch to do that:

So the /* old gcc */ part should probably be enabled based on a define for the
old compiler.  The right ifdef seems to be:

  #if __GNUC__ == 2 && __GNUC_MINOR__ < 95

Could you test it this way?

Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: generic_osync_inode() broken?

[Linus Torvalds]

On Thu, 12 Apr 2001, Marcelo Tosatti wrote:
>
> Comments?
>
> --- fs/inode.c~   Thu Mar 22 16:04:13 2001
> +++ fs/inode.cThu Apr 12 15:18:22 2001
> @@ -347,6 +347,11 @@
>  #endif
>
>   spin_lock(_lock);
> + while (inode->i_state & I_LOCK) {
> + spin_unlock(_lock);
> + __wait_on_inode(inode);
> + spin_lock(_lock);
> + }
>   if (!(inode->i_state & I_DIRTY))
>   goto out;
>   if (datasync && !(inode->i_state & I_DIRTY_DATASYNC))

Ehh.

Why not just lock the inode around the thing?

The above looks rather ugly.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Proposal for a new PCI function call

[Steve Modica]

Hi All,

We found recently that the acenic driver for the 3com gigabit ethernet card does
not enable 64 bit DMAs.  (this is done by setting the appropriate mask in
pci_dev->dma_mask).

Jes suggested that the appropriate way to fix this would be to create a function
like pci_enable_dma64 and then have the driver call that, rather than directly
setting this value (a small handful of drivers do this now).

I think the function idea would let us do some sanity checking to make sure
drivers weren't setting this to 64bit on non-64 bit busses and stuff.

Anyhow, so long as no one has any heartburn with this, we'll try to put
something together and submit it.  I'm not subscribed to the list *yet* (need to
get procmail setup), so please leave me in the CC line.

Thanks!
Steve

-- 
Steve Modica
Manager - Networking Drivers Group
"Give a man a fish, and he will eat for a day, hit him with a fish and
he leaves you alone" - me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

generic_osync_inode() broken?

[Marcelo Tosatti]

Hi, 

generic_osync_inode() (called by generic_file_write()) is not checking if
the inode being synced has the I_LOCK bit set before checking the I_DIRTY
bit.

AFAICS, the following problem can happen:

sync()
...
sync_one()
reset I_DIRTY, set I_LOCK
filemap_fdatasync() <-- #window 
write_inode()  <-- #window  
filemap_fdatawait() <-- #window
unset I_LOCK

There is no guarantee that the inode is fully synced until sync_one()
cleans the inode I_LOCK bit. 

If generic_osync_inode() checks the I_DIRTY bit (and sees it clean) during
"#window", an "O_SYNC write()" call may return to userspace without having
all the data actually synced.

If I'm not missing something here this patch should the problem. 

Comments? 

--- fs/inode.c~ Thu Mar 22 16:04:13 2001
+++ fs/inode.c  Thu Apr 12 15:18:22 2001
@@ -347,6 +347,11 @@
 #endif
 
spin_lock(_lock);
+   while (inode->i_state & I_LOCK) {
+   spin_unlock(_lock);
+   __wait_on_inode(inode);
+   spin_lock(_lock);
+   }
if (!(inode->i_state & I_DIRTY))
goto out;
if (datasync && !(inode->i_state & I_DIRTY_DATASYNC))

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH(?): linux-2.4.4-pre2: fork should run child first

[Adam J. Richter]

>> = Adam J. Richter <[EMAIL PROTECTED]>
>  = Horst von Brand <[EMAIL PROTECTED]>

>>  I suppose that running the child first also has a minor
>> advantage for clone() in that it should make programs that spawn lots
>> of threads to do little bits of work behave better on machines with a
>> small number of processors, since the threads that do so little work that
>> they accomplish they finish within their time slice will not pile up
>> before they have a chance to run.  So, rather than give the parent's CPU
>> priority to the child only if CLONE_VFORK is not set, I have decided to
>> do a bit of machete surgery and have the child always inherit all of the
>> parent's CPU priority all of the time.  It simplifies the code and
>> probably saves a few clock cycles (and before you say that this will
>> cost a context switch, consider that the child will almost always run
>> at least one time slice anyhow).

>And opens the system up to DoS attacks: You can't have a process fork(2)
>at will and so increase its (aggregate) CPU priority.

My change does not increase the aggregate priority of
parent+child.  Perhaps I misunderstand your comment.

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."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: List of all-zero .data variables in linux-2.4.3 available

[Ulrich Drepper]

"Adam J. Richter" <[EMAIL PROTECTED]> writes:

> >Shouldn't a compiler be able to deal with this instead?
> 
>   Yes.

No.  gcc must not do this.  There are situations where you must place
a zero-initialized variable in .data.  It is a programmer problem.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

badly punctuated parameter list in `#define' (2.4.3-ac5 and 2.4.4-pre2)

[Wayne . Brown]

When compiling 2.4.3-ac5 (and also 2.4.4-pre2) I get this:

/usr/src/linux-2.4.3-ac5/include/asm/rwsem.h:26: badly punctuated parameter list
 in `#define'

This appears to be due to some code in rwsem.h that is written for a different
version of gcc. (I'm still using gcc-2.91.66 as specified in
Documentation/Changes.)  It works for me if I replace it with the code in the
section labeled /* old gcc */.  Here's a patch to do that:

--- include/asm-i386/rwsem.h.old   Thu Apr 12 13:47:00 2001
+++ include/asm-i386/rwsem.h  Thu Apr 12 13:48:04 2001
@@ -21,16 +21,16 @@
 #include 

 #if RWSEM_DEBUG
-#define rwsemdebug(FMT,...) do { if (sem->debug) printk(FMT,__VA_ARGS__); }
while(0)
+//#define rwsemdebug(FMT,...) do { if (sem->debug) printk(FMT,__VA_ARGS__); }
while(0)
 #else
-#define rwsemdebug(FMT,...)
+//#define rwsemdebug(FMT,...)
 #endif

 /* old gcc */
 #if RWSEM_DEBUG
-//#define rwsemdebug(FMT, ARGS...) do { if (sem->debug) printk(FMT,##ARGS); }
while(0)
+#define rwsemdebug(FMT, ARGS...) do { if (sem->debug) printk(FMT,##ARGS); }
while(0)
 #else
-//#define rwsemdebug(FMT, ARGS...)
+#define rwsemdebug(FMT, ARGS...)
 #endif

 #ifdef CONFIG_X86_XADD


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: scheduler went mad?

[Szabolcs Szakacsits]

On Thu, 12 Apr 2001, Rik van Riel wrote:
> On Thu, 12 Apr 2001, Szabolcs Szakacsits wrote:
> > I still feel a bit unconfortable about processes looping forever in
> > __alloc_pages and because of this oom_killer also can't be moved to
> > page fault handler where I think its place should be. I'm using the
> > patch below.
> It's BROKEN.  This means that if you have one task using up
> all memory and you're waiting for the OOM kill of that task
> to have effect, your syslogd, etc... will have their allocations
> fail and will die.

You mean without dropping out_of_memory() test in kswapd and calling
oom_kill() in page fault [i.e. without additional patch]? Yes, you're
competely true but I have the patch [see example below, 'm1' is the bad
guy] just didn't have time to extensively test it and don't know whether
there is side efffects getting rid of this infinite looping in
__alloc_pages() but locked up processes apparently don't make people
very happy ;)

Szaka

Out of Memory: Killed process 830 (m1), saved process 696 (httpd)
   procs  memoryswap  io system
 r  b  w   swpd   free   buff  cache  si  sobibo   incs
 6  0  0  0   9492100   1496   0   0  1386 2 2904  3877
 5  0  0  0   7812104   1788   0   0   289 0  68922
 5  0  0  0   6248104   1788   0   0 0 0  10819
 5  0  0  0   4748108   1840   0   056 0  21921
 5  0  0  0   3268108   1868   0   028 0  16523
 5  0  1  0   1864 76   1868   0   0 0 5  12061
 5  0  1  0   1432 76   1252   0   0 0 0  108  1130
 5  0  1  0   1236 80796   0   065 0  246  4588
 5  0  1  0   1236 80668   0   0 0 0  110  8869
 6  0  1  0948112696   0   0   805 0 1814  8231
Out of Memory: Killed process 858 (m1), saved process 811 (vmstat)
 5  0  1  0924152444   0   0  1153 0 2731 18231
 4  0  1  0   1720148828   0   0   750 3 1711  1876
 5  0  1  0   1156148760   0   0   290 0  723  1967
 4  0  1  0   1152132664   0   070 0  277  7249
 4  0  1  0   1140144560   0   054 0  238  7942
 4  0  1  0   1140144460   0   032 0  212  7521
Out of Memory: Killed process 834 (m1), saved process 418 (identd)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: List of all-zero .data variables in linux-2.4.3 available

[Adam J. Richter]

[EMAIL PROTECTED] writes:
>Shouldn't a compiler be able to deal with this instead?

Yes.  I sent some email to bug-gcc about this a couple of
months ago and even posted some (probably horribly incorrect) code
showing roughly the change I had in mind in the gcc source code
for the simple case of scalar variables.  I was told that some code
to this was put in and then removed from gcc a long time ago, and
nobody seemed interested in putting it back in.  I would think that this
would be a basic optimization that I would expect the compiler to make,
just like deleting "if(0) {..}" code, but gcc does not currently
do that.  If somebody would like to fix gcc and do the necessary
lobbying to get such a change integrated, that would be great.  However,
until that actually happens, I hope the file that I posted to
ftp://ftp.yggdrasil.com/private/adam/linux/zerovars/ will be useful
to individual maintainers and in identifying the largest arrays of
zeroes that can fix fixed in a few lines.

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."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 8139too: defunct threads

[Andrew Morton]

Rod Stewart wrote:
> 
> Hello,
> 
> Using the 8139too driver, 0.9.15c, we have noticed that we get a defunct
> thread for each device we have; if the driver is built into the kernel.
> If the driver is built as a module, no defunct threads appear.

What is the parent PID for the defunct tasks?  zero?

 swapper doesn't know how to reap children, and
AFAIK there's no way for a kernel thread to fully clean itself
up.  This is always done by the parent.

ho-hum.  Jeff, I think the best fix here is to bite the
bullet and write kernel_daemon(), which will delegate
thread creation to keventd, which is the only thing
we have which reaps zombies.  Any better ideas?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkml]Re: [PATCH] matroxfb and mga XF4 driver coexistence...

[thunder7]

On Thu, Apr 12, 2001 at 09:28:44AM -0400, Chris Meadors wrote:
> On Thu, 12 Apr 2001, Rafael E. Herrera wrote:
> > If the problem occurs whithout the frame buffer on, the problem seems to
> > be on the X server.
> 
> Exactly.  That is what I'm saying.  I've seen the problem with the
> returning to VESA text modes from XFree 4.0 anytime I use the hallib, with
> 2.2 and 2.4 kernels.  If I compile an X server without the hallib it's
> fine (G450 users don't have that option, and I like my dual head).
> 
> If X changes the mode upon starting it should put it back when it is done.
> 
Of course, but if we can fix the problem by making the kernel smaller,
what possible motive could you have for opposing it other than 'but it
doesn't solve _my_ problems!' ?

Good luck,
Jurriaan
-- 
HORROR FILM WISDOM:
7. If you're running from the monster, you will most likely trip or
fall. If you are female you can bet on it.
GNU/Linux 2.4.3-ac4 SMP/ReiserFS 2x1743 bogomips load av: 0.03 0.01 0.02
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SCSI Tape Corruption - update

[Gérard Roudier]

On Thu, 12 Apr 2001 [EMAIL PROTECTED] wrote:

> Still experimenting with my SDT-9000... tried connecting it to another
> controller
> (2940AU in place of 2904, sorry but I've only Adaptec stuff :). Same
> problem.
> Tried with another tape (even with an old DDS-2 tape). Same. Even tried
> another
> cable/removing the CDWR drive from the bus.
> 
> It seems that the tape is written incorrectly. I wrote some large file
> (300MB)
> and read it back four time. The read copies are all the same. They differ
> from the original only in 32 consecutive bytes (the replaced values SEEM
> random). Of course, 32 bytes in 300MB tar.gz files are TOO MUCH to be 
> accepted :)

A similar problem has been reported under Linux/PPC a couple of weeks ago
using a sym53c875 controller. In this case, kernel 2.2 was fine.

> Now I'll build some old 2.2 kernel to try...

If 2.2 is ok with your tape, a software error in 2.4 gets very likely, in
my opinion.

  Gérard.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Question about SysRq

[Dr. Kelsey Hudson]

On Wed, 4 Apr 2001, Boris Pisarcik wrote:
> I looked a bit at the source of sysrq handling. I've found there is
> rather big difference between sysrq+b and other killers handling.
> Sysrq+b is just called with pretty straitforward fashion - stops other
> processors on SMP and reboots directly (hardware impulse or triple fault)
> or through the bios - so it just calls for the corruptions.

ah, that would explain it...

> On the other side sysrq+s marks a single variable, which will be tested
> next cycle in the bdflush kernel threads' main loop, and adds bdflush to
> scheduler runqueue list. So it gets possibility to check for emergency
> sync onle when gets next scheduled. Does it ?
>
> Can you anyhow find something in your logs/console/serial console messages
> like 13.13.2000 kernel : Sysrq: Emergency Sync (this should be present - is
> written within keyboard handler, not after shedule) and what's next logs ?
> We could determine, if the bdflush thread got scheduled and called emergency
> syncing routine indeed.

Nope, there was nothing in the logs.

> As you wrote no of your processes does respond - probably telnet will
> not help. You may try to write experimental programme, that only log
> say current time every n seconds, and see, if it just stopped to
> log messages after lockup-time. If not - it doesn't get scheduled.
> If continues - there's problem with syncing. Again - try, as far
> as i understand, log kernel messages to serial console or alike, because
> the messages should not get written to logfiles - syslogd can't be woken up
> eg.

Telnet's disabled anyways :) Cleartext passwords SUCK. :)
I've got a nifty LCD thingy I can hook up to the serial port and use as a
console if need be.

> Quick help against those corruptions, which comes on my mind, is use
> the reiserfs. I have no real experiences with that and its reliability,
> also as aj followed some of messages in this list about resierfs - it has
> some problems too - but in definition it shoudn't get corrupted by not-
> syncing reboot. But i see this not much helpfull ,cause if you really
> would depend on big reliability, you wouldn't intall 2.3.x-pre kernel :)

I'm not about to convert my filesystems over... It's too much a hassle for
little gain. ext2 is faster anyways, IIRC.

The problem disappeared when I installed 2.4.3 release; I think it was a
DRM issue in the kernel that was causing the lockups

Thanks for the help though

 Kelsey Hudson   [EMAIL PROTECTED]
 Software Engineer
 Compendium Technologies, Inc   (619) 725-0771
---

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i2o & Promise SuperTrak100

[Andrew Chan]

While you are at it, can you bug them for FastTrak (the software RAID thing)
support?

Their drivers are ages behind and Andre doesn't seem to be able to get them
cooperate either.

I have many many boards with their FastTrak chip on and I cannot use it
either as FastTrak or even simple ATA100 controller. I'd happy if I can use
it even as simple ATA100 controller.

Andrew Chan

==

Alan Cox says:

I've been talking constructively to promise about the i2o on the supertrak
not working straight off with the kernel i2o driver. Currently it looks
promising


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: scheduler went mad?

[Valdis . Kletnieks]

On Thu, 12 Apr 2001 16:12:55 BST, Alan Cox said:

> Do you have > 800Mb of RAM ?

Following up - it just bit again (twice)

The first time, it was xmms/kswapd fighting for CPU, and xmms was again immune
to kill -9.  Interestingly enough, several minutes later, I closed 'netscape',
and xmms took the kill within a second or two.

10 minutes later, and another 2 programs that do audio got
wedged up. Oddly enough, I did an 'su', and they broke loose immediately.

I've ruled out i810_audio.c as a culprit - although I have programs that
do audio hanging, *those* programs are always writing their data down
a Unix socket to the actual process that writes to /dev/audio/dsp.
Hmm.. 'su' writes to syslog, and netscape has a few Unix sockets too.
Could the problem be related to running out of some resource related
to Unix-domain sockets, which clears up once some socket is closed?

Oddly enough, while I had 2 programs doing audio wedged, I was still
seeing (hearing actually ;) *new* processes open a connection to esd
and play sounds.  Weird.  


-- 
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech




 PGP signature