SCSI scanning

[Jan Niehusmann]

test9-pre1 does not contain a fix for the test8 scsi scanning problem. SCSI
disks are detected twice if scsi is not compiled as a module. Torben already
posted a patch.

Jan

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

pcmcia fixes for apple powerbook

[Paul Mackerras]

David,

The patch below fixes some problems I found in trying to use the
in-kernel pcmcia/cardbus support in 2.4.0-test8 on my 1999 G3
powerbook, which has a TI 1211 cardbus controller.

The first part of the patch fixes a simple endianness problem in cs.c.
Following that is a small change that removes a compile warning when
CONFIG_ISA is not set (as in my case).  The change to ti113x.h adds a
special open routine for the TI1211; in my case I need to set the
multifunction pin routing register (config offset 0x8c) to 2 in order
to route the INTA signal out the MFUNC0 pin, and the firmware doesn't
do this automatically.  Finally I have added #ifdef CONFIG_ISA in a
couple of places in yenta.c to make sure we don't try to use ISA
interrupt routing when we don't have an ISA bus.

Assuming this patch looks OK to you, could you send it to Linus?

Thanks,
Paul.

diff -urN linux/drivers/pcmcia/cs.c linuxppc_2_3/drivers/pcmcia/cs.c
--- linux/drivers/pcmcia/cs.c   Sat Sep  9 19:00:23 2000
+++ linuxppc_2_3/drivers/pcmcia/cs.cSat Sep 16 11:37:29 2000
@@ -1629,6 +1629,7 @@
 config_req_t *req)
 {
 int i;
+u_char b;
 u_int base;
 socket_info_t *s;
 config_t *c;
@@ -1721,14 +1722,14 @@
write_cis_mem(s, 1, (base + CISREG_ESR)>>1, 1, &c->ExtStatus);
 }
 if (req->Present & PRESENT_IOBASE_0) {
-   i = c->io.BasePort1 & 0xff;
-   write_cis_mem(s, 1, (base + CISREG_IOBASE_0)>>1, 1, &i);
-   i = (c->io.BasePort1 >> 8) & 0xff;
-   write_cis_mem(s, 1, (base + CISREG_IOBASE_1)>>1, 1, &i);
+   b = c->io.BasePort1 & 0xff;
+   write_cis_mem(s, 1, (base + CISREG_IOBASE_0)>>1, 1, &b);
+   b = (c->io.BasePort1 >> 8) & 0xff;
+   write_cis_mem(s, 1, (base + CISREG_IOBASE_1)>>1, 1, &b);
 }
 if (req->Present & PRESENT_IOSIZE) {
-   i = c->io.NumPorts1 + c->io.NumPorts2 - 1;
-   write_cis_mem(s, 1, (base + CISREG_IOSIZE)>>1, 1, &i);
+   b = c->io.NumPorts1 + c->io.NumPorts2 - 1;
+   write_cis_mem(s, 1, (base + CISREG_IOSIZE)>>1, 1, &b);
 }
 
 /* Configure I/O windows */
@@ -1835,8 +1836,7 @@
 {
 socket_info_t *s;
 config_t *c;
-int try, ret = 0, irq = 0;
-u_int mask;
+int ret = 0, irq = 0;
 
 if (CHECK_HANDLE(handle))
return CS_BAD_HANDLE;
@@ -1857,6 +1857,7 @@
/* If the interrupt is already assigned, it must match */
irq = s->irq.AssignedIRQ;
if (req->IRQInfo1 & IRQ_INFO2_VALID) {
+   u_int mask;
mask = req->IRQInfo2 & s->cap.irq_mask;
ret = ((mask >> irq) & 1) ? 0 : CS_BAD_ARGS;
} else
@@ -1864,6 +1865,7 @@
 } else {
ret = CS_IN_USE;
if (req->IRQInfo1 & IRQ_INFO2_VALID) {
+   u_int mask, try;
mask = req->IRQInfo2 & s->cap.irq_mask;
for (try = 0; try < 2; try++) {
for (irq = 0; irq < 32; irq++)
diff -urN linux/drivers/pcmcia/ti113x.h linuxppc_2_3/drivers/pcmcia/ti113x.h
--- linux/drivers/pcmcia/ti113x.h   Thu May 25 12:53:52 2000
+++ linuxppc_2_3/drivers/pcmcia/ti113x.hSat Sep 16 11:37:29 2000
@@ -272,6 +272,36 @@
yenta_proc_setup
 };
 
+static int ti1211_open(pci_socket_t *socket)
+{
+#ifdef CONFIG_PPC
+   /*
+* On Powerbooks with the TI1211 cardbus chip, we have to set the
+* multifunction pin routing register to route the PCI INTA to the
+* MFUNC0 pin.
+*/
+   config_writel(socket, TI122X_IRQMUX, 2);
+#endif /* CONFIG_PPC */
+
+   ti_open(socket);
+   return 0;
+}
+
+static struct pci_socket_ops ti1211_ops = {
+   ti1211_open,
+   yenta_close,
+   ti_init,
+   yenta_suspend,
+   yenta_get_status,
+   yenta_get_socket,
+   yenta_set_socket,
+   yenta_get_io_map,
+   yenta_set_io_map,
+   yenta_get_mem_map,
+   yenta_set_mem_map,
+   yenta_proc_setup
+};
+
 #endif /* CONFIG_CARDBUS */
 
 #endif /* _LINUX_TI113X_H */
diff -urN linux/drivers/pcmcia/yenta.c linuxppc_2_3/drivers/pcmcia/yenta.c
--- linux/drivers/pcmcia/yenta.cSat Sep  9 19:00:23 2000
+++ linuxppc_2_3/drivers/pcmcia/yenta.c Sat Sep 16 11:37:29 2000
@@ -240,6 +240,7 @@
u8 intr;
bridge |= (state->flags & SS_RESET) ? CB_BRIDGE_CRST : 0;
 
+#ifdef CONFIG_ISA
/* ISA interrupt control? */
intr = exca_readb(socket, I365_INTCTL);
intr = (intr & ~0xf);
@@ -248,10 +249,13 @@
bridge |= CB_BRIDGE_INTR;
}
exca_writeb(socket, I365_INTCTL, intr);
+#endif /* CONFIG_ISA */
}  else {
u8 reg;
 
+#ifdef CONFIG_ISA
bridge |= CB_BRIDGE_INTR;
+#endif /* CONFIG_ISA */
reg = exca_readb(socket, I365_INTCTL) & (I365_RING_ENA | 
I365_INTR_ENA);
reg |= (state->flags & SS_RESET) ? 0 : I365_PC_RESET;
reg |= (state->flags & SS_IOCARD) ? I365_PC_IOCARD : 0;
@@ -482,6 +

[patch-2.4.0-test9-pre1] mm/filemap.c

[Bill Wendling]

Hi Linus,
 
Here's a resubmitted small optimization for the mm/filemap.c file.
 
- The `curr = curr->next;' statement doesn't need to be executed
  if the repeat is taken. I used the list_for_each() macro to
  accomodate this better.
 
Share and enjoy!

-- 
|| Bill Wendling[EMAIL PROTECTED]


--- linux-2.4.0-test9-pre1/mm/filemap.c Sat Sep 16 02:21:03 2000
+++ linux-2.4.0-test9-pre1-new/mm/filemap.c Sat Sep 16 02:31:54 2000
@@ -193,12 +193,10 @@
 repeat:
head = &mapping->pages;
spin_lock(&pagecache_lock);
-   curr = head->next;
-   while (curr != head) {
+   list_for_each(curr, head) {
unsigned long offset;
 
page = list_entry(curr, struct page, list);
-   curr = curr->next;
offset = page->index;
 
/* Is one of the pages to truncate? */

Re: Yet another report on the dquot oops

[David Ford]

J Sloan wrote:

> David Ford wrote:
>
> > Did you apply the quota patch that was posted this week?
>
> Yes, thanx for the sanity check -
>
> After the oops, I remembered something about a patch,
> and there was indeed one posted by Herr Diehl.
>
> Will check that out - now I'm curious if there's some
> reason Linus didn't like the patch, since it wasn't in test9

My guess is that it hasn't reached the top of the queue yet.  Gotta
'member, he has to go through a lot of patches and give them the eyeball
before they go in.

-d


--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."




begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;28256
fn:David Ford
end:vcard

Re: New topic (PowerPC Linux PCI HELL)

[Gérard Roudier]

On Fri, 15 Sep 2000, Richard B. Johnson wrote:

> On Fri, 15 Sep 2000, [ISO-8859-1] Gérard Roudier wrote:
> 
> > 
> > 
> > On Fri, 15 Sep 2000, Linus Torvalds wrote:
> > 
> > > On Fri, 15 Sep 2000, Gérard Roudier wrote:
> > > > 
> 

[ ... ]

> > > No ifs, why's or buts. A driver that just enables the IO windows is a
> > > buggy driver. 
> > 
> > In PCI, you donnot enable windows, but you enable/disable devices to
> > generate and/or respond to transactions.
> 
> Well really? From the programmers point-of-view, you have just enabled
> some windows into address space. The word "transaction" has gotten way
> too much visibility. The fact that some hardware mechanism has gotten
> involved reading from and writing to a device means nothing except
> that a write (if enabled) is posted. We don't bother thinking about
> "transactions" when we write to SDRAM do we? To the programmer, we
> write to it and it sticks. The fact that there was a hardware transaction
> involving a read/modify/write of (usually) much more than our byte
> isn't a concern.

Hmmm... If you know what drivers have been written with such a limited
"low skilled" CPU centric approach in mind, let me know. I will just avoid
forever using the resulting crap.

  Gerard.

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

Re: test9-pre1

[bert hubert]

On Fri, Sep 15, 2000 at 07:03:36PM -0700, Linus Torvalds wrote:
> 
> Ok, the new MM balancing has been getting good reviews, and no longer has
> any known issues. Integrated. We'd have needed to do it sooner or later
> anyway (just see what happened in 2.2.x), the sooner we do it the less
> traumatic it will end up being.

Thanks go out to everybody involved. I can cease my whining now :-) 

Regards,

bert hubert

-- 
PowerDNS Versatile DNS Services  |  - U N I X -
Trilab   The Technology People   |

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

Re: test9-pre1

[Rik van Riel]

On Sat, 16 Sep 2000, bert hubert wrote:
> On Fri, Sep 15, 2000 at 07:03:36PM -0700, Linus Torvalds wrote:
> > 
> > Ok, the new MM balancing has been getting good reviews, and no longer has
> > any known issues. Integrated. We'd have needed to do it sooner or later
> > anyway (just see what happened in 2.2.x), the sooner we do it the less
> > traumatic it will end up being.
> 
> Thanks go out to everybody involved. I can cease my whining now :-) 

Note that the big performance tuning has only just begun...

Now that the number of users of the new VM code has increased
tenfold overnight, I'm sure I'll get a lot more reports of
workloads where performance isn't right yet...

(even though most workloads should see increased performance)

It's almost a shame I'll be at Linux Kongress next week and
only sporadically connected to the net ;)

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

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

pcmcia fixes for apple powerbook

[Paul Mackerras]

David,

The patch below fixes some problems I found in trying to use the
in-kernel pcmcia/cardbus support in 2.4.0-test9-pre1 on my 1999 G3
powerbook, which has a TI 1211 cardbus controller.

The first part of the patch fixes a simple endianness problem in cs.c.
Following that is a small change that removes a compile warning when
CONFIG_ISA is not set (as in my case).  The change to ti113x.h adds a
special open routine for the TI1211; in my case I need to set the
multifunction pin routing register (config offset 0x8c) to 2 in order
to route the INTA signal out the MFUNC0 pin, and the firmware doesn't
do this automatically.  Finally I have added #ifdef CONFIG_ISA in a
couple of places in yenta.c to make sure we don't try to use ISA
interrupt routing when we don't have an ISA bus.

I'm also seeing some contact bounce problems when cards are inserted,
although test9-pre1 is slightly better than test8 in this respect.  If
I kill cardmgr, install the card, and restart cardmgr, it comes up
just fine.

Assuming this patch looks OK to you, could you send it to Linus?

Thanks,
Paul.

diff -urN linux/drivers/pcmcia/cs.c pmac/drivers/pcmcia/cs.c
--- linux/drivers/pcmcia/cs.c   Sat Sep 16 16:25:57 2000
+++ pmac/drivers/pcmcia/cs.cSat Sep 16 16:54:07 2000
@@ -1634,6 +1634,7 @@
 config_req_t *req)
 {
 int i;
+u_char b;
 u_int base;
 socket_info_t *s;
 config_t *c;
@@ -1726,14 +1727,14 @@
write_cis_mem(s, 1, (base + CISREG_ESR)>>1, 1, &c->ExtStatus);
 }
 if (req->Present & PRESENT_IOBASE_0) {
-   i = c->io.BasePort1 & 0xff;
-   write_cis_mem(s, 1, (base + CISREG_IOBASE_0)>>1, 1, &i);
-   i = (c->io.BasePort1 >> 8) & 0xff;
-   write_cis_mem(s, 1, (base + CISREG_IOBASE_1)>>1, 1, &i);
+   b = c->io.BasePort1 & 0xff;
+   write_cis_mem(s, 1, (base + CISREG_IOBASE_0)>>1, 1, &b);
+   b = (c->io.BasePort1 >> 8) & 0xff;
+   write_cis_mem(s, 1, (base + CISREG_IOBASE_1)>>1, 1, &b);
 }
 if (req->Present & PRESENT_IOSIZE) {
-   i = c->io.NumPorts1 + c->io.NumPorts2 - 1;
-   write_cis_mem(s, 1, (base + CISREG_IOSIZE)>>1, 1, &i);
+   b = c->io.NumPorts1 + c->io.NumPorts2 - 1;
+   write_cis_mem(s, 1, (base + CISREG_IOSIZE)>>1, 1, &b);
 }
 
 /* Configure I/O windows */
@@ -1840,8 +1841,7 @@
 {
 socket_info_t *s;
 config_t *c;
-int try, ret = 0, irq = 0;
-u_int mask;
+int ret = 0, irq = 0;
 
 if (CHECK_HANDLE(handle))
return CS_BAD_HANDLE;
@@ -1862,6 +1862,7 @@
/* If the interrupt is already assigned, it must match */
irq = s->irq.AssignedIRQ;
if (req->IRQInfo1 & IRQ_INFO2_VALID) {
+   u_int mask;
mask = req->IRQInfo2 & s->cap.irq_mask;
ret = ((mask >> irq) & 1) ? 0 : CS_BAD_ARGS;
} else
@@ -1869,6 +1870,7 @@
 } else {
ret = CS_IN_USE;
if (req->IRQInfo1 & IRQ_INFO2_VALID) {
+   u_int mask, try;
mask = req->IRQInfo2 & s->cap.irq_mask;
for (try = 0; try < 2; try++) {
for (irq = 0; irq < 32; irq++)
diff -urN linux/drivers/pcmcia/ti113x.h pmac/drivers/pcmcia/ti113x.h
--- linux/drivers/pcmcia/ti113x.h   Thu May 25 12:53:52 2000
+++ pmac/drivers/pcmcia/ti113x.hFri Sep 15 23:36:53 2000
@@ -272,6 +272,36 @@
yenta_proc_setup
 };
 
+static int ti1211_open(pci_socket_t *socket)
+{
+#ifdef CONFIG_PPC
+   /*
+* On Powerbooks with the TI1211 cardbus chip, we have to set the
+* multifunction pin routing register to route the PCI INTA to the
+* MFUNC0 pin.
+*/
+   config_writel(socket, TI122X_IRQMUX, 2);
+#endif /* CONFIG_PPC */
+
+   ti_open(socket);
+   return 0;
+}
+
+static struct pci_socket_ops ti1211_ops = {
+   ti1211_open,
+   yenta_close,
+   ti_init,
+   yenta_suspend,
+   yenta_get_status,
+   yenta_get_socket,
+   yenta_set_socket,
+   yenta_get_io_map,
+   yenta_set_io_map,
+   yenta_get_mem_map,
+   yenta_set_mem_map,
+   yenta_proc_setup
+};
+
 #endif /* CONFIG_CARDBUS */
 
 #endif /* _LINUX_TI113X_H */
diff -urN linux/drivers/pcmcia/yenta.c pmac/drivers/pcmcia/yenta.c
--- linux/drivers/pcmcia/yenta.cSat Sep 16 16:25:57 2000
+++ pmac/drivers/pcmcia/yenta.c Sat Sep 16 17:13:38 2000
@@ -245,6 +245,7 @@
u8 intr;
bridge |= (state->flags & SS_RESET) ? CB_BRIDGE_CRST : 0;
 
+#ifdef CONFIG_ISA
/* ISA interrupt control? */
intr = exca_readb(socket, I365_INTCTL);
intr = (intr & ~0xf);
@@ -253,10 +254,13 @@
bridge |= CB_BRIDGE_INTR;
}
exca_writeb(socket, I365_INTCTL, intr);
+#endif /* CONFIG_ISA */
}  else {
u8 reg;
 
+#ifdef CONFIG_ISA
bridge |= CB_BRIDGE_INTR;
+#endif /* CONFIG_ISA */
reg = exca_readb(socket, I365_INTCTL) & (I365_RING

TODO list for new VM

[Rik van Riel]

Hi,

Here is the TODO list for the new VM. The only thing
really needed for 2.4 is the OOM handler and the
page->mapping->flush() callback is really wanted by
the journaling filesystem folks.

The rest are mostly extra's that would be nice; these
things won't be pushed for inclusion except if it turns
out to be really trivial to implement, high performance
on the cases they're supposed to affect and their influence
is highly localised...

(sorry folks, but for 2.4 I'll be really conservative)

---> TODO list for the new VM <---

for kernel 2.4, necessary:
- out of memory handling
[integrate the OOM killer, 10 minutes work]

for kernel 2.4, really wanted:
- page->mapping->flush() callback in page_launder(),
  for easier integration with journaling filesystems
  and maybe the network filesystems
[about 30 minutes of work on the VM side]

for kernel 2.4, wanted:
- include Ben LaHaise's code, which moves readahead
  to the VMA level, this way we can do streaming swap
  IO, complete with drop_behind()
- code to make the "knee" smoother, currently the system
  keeps eating memory from the cache up to a certain point
  and then starts to swap a lot, it would be nice to smooth
  this curve a bit
- thrashing control, maybe process suspension with some
  forced swapping ?

for kernel 2.5:
- physical->virtual reverse mapping, so we can do much
  better page aging with less CPU usage spikes
- better IO clustering for swap (and filesystem) IO
- move all the global VM variables, lists, etc. into
  the pgdat struct for better NUMA scalability
- (maybe) some QoS things, as far as they are major
  improvements with minor intrusion

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

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

Re: RAID HW Questions...

[Alan Cox]

> Well. Since DPT rammed me in the ass with their "SmartRAID V" RAID I need
> to buy a new RAID card. I don't know who to trust. I was told (about 1
> year ago) that DPT was the Co. that liked/worked with the linux community.
> Obviously they don't. I don't a driver for over $12,000 in RAID HW. So,

The driver should be on DPT's site. Im not sure on the current state with the
DPT decade/century/millenium series but source (ugly or otherwise) is around
and I am hoping to get it merged once some headers have been cleaned up.

> supported, I mean not some crap ass driver written by an intern. I want
> something that inspires love from the author. I want a driver that works.
> 
> Who out there (for the HW RAID stuff) really works with the Linux Kernel
> Developers? ie What HW vendor?

Currently in kernel
---
IBM write their own drivers for the ServeRAID
AMI/DELL for the MegaRAID
Mylex help Leonard Zubkoff with the DAC960 driver
Compaq write their own drivers for the SMART2 and ISS interfaces
ICP Vortex have been doing their own drivers for their cards back since
1996 (1.2.13)
DPT have been heling with their older SmartRAID cards and there are drivers
in kernel

and I may have forgotten some.

The current I2O based smartraid stuff got tangled in some I2O sig sillies about
copyrights on their own header files but thats something I talked with 
DPT about and not that hard to fix



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

test9-pre1 breaks pcmcia (or PCI?)

[Tigran Aivazian]

Hi Martin,

I have finally got around to testing your pci.c fix against
2.4.0-test9-pre1. The results are:

a) without your fix I see neither the cardbus eth nic nor the ones behined
the DEC pci-pci bridge. (I did see the cardbus nic on test8 though)

b) with your fix I see all devices behind the bridge but still can't see
the cardbus one.

c) on 2.2.x everything is fine.

I have attached two bootlogs and lspci outputs under 2.4.0-test9-pre1 -
with and without Martin's patch.

Regards,
Tigran


Linux version 2.4.0-test9 (root@penguin) (gcc version egcs-2.91.66 19990314/Linux 
(egcs-1.1.2 release)) #1 Sat Sep 16 10:15:38 BST 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: c000 @ 000c (reserved)
 BIOS-e820: 07ef @ 0010 (usable)
 BIOS-e820: 0001 @ 07ff (ACPI data)
 BIOS-e820: 0006 @ 100a (reserved)
 BIOS-e820: 0020 @ ffe0 (reserved)
On node 0 totalpages: 32752
zone(0): 4096 pages.
zone(1): 28656 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=240test9 ro root=302
Initializing CPU#0
Detected 448626804 Hz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 894.57 BogoMIPS
Memory: 126676k/131008k available (1304k kernel code, 3944k reserved, 91k data, 172k 
init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
CPU: Intel Pentium III (Coppermine) stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED])
PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router default [8086/1234] at 00:07.0
Limiting direct PCI/PCI transfers.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
P6 Microcode Update Driver v1.07
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x0860-0x0867, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x0868-0x086f, BIOS settings: hdc:DMA, hdd:pio
hda: IBM-DARA-206000, ATA DISK drive
hdc: SAMSUNG CD-ROM SN-124, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 11733120 sectors (6007 MB) w/418KiB Cache, CHS=730/255/63, UDMA(33)
hdc: ATAPI 24X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.11
Partition check:
 hda: hda1 hda2 hda3 hda4
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.10c
maestro: version 0.14 time 10:18:18 Sep 16 2000
maestro: Configuring ESS Maestro 2E found at IO 0xD800 IRQ 5
maestro:  subvendor id: 0x00aa1028
maestro: PCI power managment capability: 0x7622
maestro: AC97 Codec detected: v: 0x83847609 caps: 0x6940 pwr: 0xf
maestro: 1 channels configured.
Linux PCMCIA Card Services 3.1.20
  options:  [pci] [cardbus]
Yenta IRQ list 0298, PCI irq11
Socket status: 3020
kmem_create: Forcing size word alignment - nfs_fh
Yenta IRQ list 0298, PCI irq11
Socket status: 3010
cs: cb_alloc(bus 2): vendor 0x0868, device 0x3000
PCI: Failed to allocate resource 0 for PCI device 0868:3000
PCI: Failed to allocate resource 1 for PCI device 0868:3000
PCI: Failed to allocate resource 2 for PCI device 0868:3000
PCI: Failed to allocate resource 3 for PCI device 0868:3000
PCI: Failed to allocate resource 4 for PCI device 0868:3000
PCI: Failed to allocate resource 5 for PCI device 0868:3000
PCI: Failed to allocate resource 6 for PCI device 0868:3000
PCI: Enabling device 02:00.0 (0868 -> 086a)
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 172k freed
Adding Swap: 136512k swap-space (priority -1)
cs: IO port probe 0x1000-0x17ff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
cs: memory probe 0xa000-0xa0ff: clean.
ttyS01 at port 0x02f8 (irq = 3) is a 16550A
microcode: CPU0 not 'upgrading' to earlier revisi

Re: RAID HW Questions...

[Bryan Whitehead]

On Sat, 16 Sep 2000, Alan Cox wrote:

> > Well. Since DPT rammed me in the ass with their "SmartRAID V" RAID I need
> > to buy a new RAID card. I don't know who to trust. I was told (about 1
> > year ago) that DPT was the Co. that liked/worked with the linux community.
> > Obviously they don't. I don't a driver for over $12,000 in RAID HW. So,
> 
> The driver should be on DPT's site. Im not sure on the current state with the
> DPT decade/century/millenium series but source (ugly or otherwise) is around
> and I am hoping to get it merged once some headers have been cleaned up.

The driver directory is on thier web site. true. But it only works for
specific versions of kernel's from RH. They do have the sources available
also. The problem comes when compiling. They specifically say not to use
Linux's i2o stuff. Fine. They claim they have their "own" i2o
implementaion. But it won't build, actually it won;t link. After looking
at the FAQ more they say I need to build with gcc version 2.7.2. Becasue
their driver only works with that. So i remove the gcc from my system and
install an old gcc / linker. no change. Still the same damn error. It's
not like I'm some stupid moron (i wish that were the case then I'd be able
to ask someone else WTF the problem is and they could answer). I'm a
sysadmin at JPL and am responsible for (in our section) all our builds of
GNU software. Plus I manage all the Linux machines. To top it off I do
development for Mission and Control for NASA's Deep Space network. So i'm
used to building wierd-ass stuff and getting it workin. I've worked so
long and hard on this problem I finally gave up and want to buy a new
card. i'm sick of the bitches at DPT not responding to my email and giving
me no help. I'm not going to run that crap ass 2.2.5 kernel or the 2.2.12
kernel from RH (the only kernels they support according to the web page).
I need to have at LEAST 2.2.16 for security resons. But they don't give a
crap.

If Linux can get the card working with they native i2o drivers then
great. I'd be very happy with that. But I've waited for 6 months now and
I'm to the point I don't mind blowing another $10,000 in taxpayers money
to get the fsck'n RAID working in 2.2.17 land and hopefully 2.4 soon.


> 
> > supported, I mean not some crap ass driver written by an intern. I want
> > something that inspires love from the author. I want a driver that works.
> > 
> > Who out there (for the HW RAID stuff) really works with the Linux Kernel
> > Developers? ie What HW vendor?
> 
> Currently in kernel
> ---
> IBM write their own drivers for the ServeRAID
> AMI/DELL for the MegaRAID
> Mylex help Leonard Zubkoff with the DAC960 driver
> Compaq write their own drivers for the SMART2 and ISS interfaces
> ICP Vortex have been doing their own drivers for their cards back since
>   1996 (1.2.13)
> DPT have been heling with their older SmartRAID cards and there are drivers
>   in kernel
> 
> and I may have forgotten some.
> 
> The current I2O based smartraid stuff got tangled in some I2O sig sillies about
> copyrights on their own header files but thats something I talked with 
> DPT about and not that hard to fix

All I gatta say is thier driver is a piece of crap. I'll use Linux's i2o
if it works but I'm not using there crap. I'v lost all respect and trust
from DPT and they will not get any of MY money/budget.

If you would like me to try *ANYTHING* out to aid in getting the Card
working I'm all yours. I'm a bit burned out but hell, If you think it's
not that far away. Then who am i to argue?

> 
> 
> 

-- 
---
Bryan Whitehead
Email: [EMAIL PROTECTED]
WorkE: [EMAIL PROTECTED]

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

Attempting to mount Zip causes floppy access (2.2.16)

[Nick Holloway]

I have a zip disk which I attempted to mount using the following fstab
entry:

/dev/sda4 /zip vfat noauto,nodev,nosuid,user

This caused a spew of "bread failed" errors, and the mount process ended
up blocked in "wait_on_buffer".  I thought at first that Zip disk had
gone to silicon heaven.

After rebooting, I had a look at the kernel messages, and was _amazed_ to
see the following:

SCSI device sda: hdwr sector= 512 bytes.
Sectors= 196608 [96 MB] [0.1 GB]
sda: Write Protect is off
 sda: sda1 sda2 sda3 sda4
floppy0: disk absent or changed during operation
end_request: I/O error, dev 02:00 (floppy), sector 1
bread in fat_access failed
[...]

There are two questions.  Firstly, why did the mount process get stuck
in the kernel, and secondly (and more importantly) what was it doing
accessing "/dev/fd0"?

The Zip is a bit suspect, as when I attempted to transfer stuff from
a Windows machine, it reported the size as a few Mb, and had to be
formatted.  I don't know if the media is going bad, but I have just dd'd
the contents off without problems.

If I try and look at the partition table, "cfdisk" refuses, and "fdisk"
complains bitterly.  If I try and "dd if=/dev/sda4" then this just hangs,
again in "wait_on_buffer".

Regardless of bad media and corrupt partition tables, I don't see why
the kernel is accessing a completely unrelated device.

I'll leave the zip disk as it is, so if needed I can run any tests to
try and isolate the problem.

Details; Kernel 2.2.16;  Debian 2.2;  Zip+ 100 accessed through aha152x.

-- 
 `O O'  | [EMAIL PROTECTED]
// ^ \\ | http://www.pyrites.org.uk/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: usb-uhci forgets to destroy kmem entries

[Oleg Drokin]

Hello!

On Fri, Sep 15, 2000 at 10:04:59PM +0200, Manfred Spraul wrote:

> > +#ifdef DEBUG_SLAB
> > + if (retval < 0 ) {
> > + if(kmem_cache_destroy(uhci_desc_kmem))
> Why only #ifdef DEBUG_SLAB?
> AFAICS the driver should always destroy it's slab cache.
Because we have such construction in usb-uhci.c::uhci_init():

#ifdef DEBUG_SLAB

uhci_desc_kmem = kmem_cache_create("uhci_desc", sizeof(uhci_desc_t), 0,
SLAB_HWCACHE_ALIGN, NULL, NULL);

if(!uhci_desc_kmem) {
err("kmem_cache_create for uhci_desc failed (out of memory)");
return -ENOMEM;
}

urb_priv_kmem = kmem_cache_create("urb_priv", sizeof(urb_priv_t), 0, 
SLAB_HWCACHE_ALIGN, NULL, NULL);

if(!urb_priv_kmem) {
err("kmem_cache_create for urb_priv_t failed (out of memory)");
return -ENOMEM;
}
#endif

And DEBUG_SLAB is unconditionally defined in the beginning of usb-uhci.c, too

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

An elevator algorithm

[Xuan Baldauf]

Hello,

I'm not a kernel hacker (and therefore I'm not familiar with the kernel
terminology), and maybe this idea is already old, but here is an
algorithm for an elevator which tries to guarantee smoothness and no
stalling:

Every rw-request gets an expiry timeout (e.g. in jiffies) where it's
completion must have started. Every request is member of two sorted
lists which support fast add|remove and iterating to the previous|next
member (linked list, binary tree, etc.):
The request list sorted by expiry and the request list sorted by block
number. When a rw-access is requested, the request gets its timeout and
is inserted in those two lists. The elevator has a current request on
which it is working. When the elevator is finished, it removes the
current request from the two lists and gets the "current time" (in
jiffies). If the head of the request list sorted by expiry has a time
equal to or smaller than the current time, the elevator continues with
that request. Else it continues with the next or previous request in the
list sorted by block number. (It can decide which direction, wether to
continue with the old direction or wether to always start with a
definite direction)

This way, you have good elevator characteristics while being somewhat
able to guarantee maximum request duration. If the timeout expired, the
requested block is served immediately. Only when the system is
overloaded, so that the difference between the current time and the
oldest expiry timout exceeds a given maximum, the elevator fails. In
this case, the system should be throttled (inserting new requests should
block), I think. Users could determine the expiry-timeouts so that
important applications get shorter timeouts while not-so-important
applications which can wait can request a longer timeout.

This algorithm is, of course, only per low-level-device.

What do you think?

Xuân.


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

Re: RAID HW Questions...

[Alan Cox]

> kernel from RH (the only kernels they support according to the web page).
> I need to have at LEAST 2.2.16 for security resons. But they don't give a
> crap.

Someone posted the 2.2.16port of their driver URL to [EMAIL PROTECTED]

> If Linux can get the card working with they native i2o drivers then

Thats what I've been working on and so far failed - I have hardware from them
but they dont seem to get on with our i2o code.


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

2.4.0-test8 tried to kill init!

[Harley Anderson]

I was just sitting here reading a page in lynx that I grabbed yesterday and got
spammed by 2 or 3 oopsies..
The machine had been up for approximately 44 hours with fairly light load.
Only caught the bottom of the 1st or second one but it had

  kernel BUG at page_alloc.c:194!

at the bottom. The next one was from the startup script from my ROM mud
segfaulting, so the one b4 was most likely the mud itself trying to grab a bad
bit of memory. For once it isn't my dodgy code responsible for it dying...
Some kind of oom thing maybe?

Right after this I flicked to another VC (already logged in as root), I think I
tried to do a ps, but then got this monster:
(I copied it out by hand, so it might not be 100% right) 


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

Unable to handle kernel paging request at virtual address 82613f33
c0121e56
*pde = 
Oops: 0002
CPU:  0
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010283
eax: c13c   ebx: c13e2fc8   ecx: cbfb6e7c   edx: c13e2fc8
esi: fff4   edi: 04a4   ebp: 82613edc   esp: c1309f44
ds: 0018  es: 0018  ss: 0018
Process init (pid: 1, stackpage=c1309000)
Stack: c0124186 cbfb6e7c 04a4 c13e2fc8 c4084da0 ffea  0180
   0180 81a4 cbf533a0 0001 c13e2fc8 0900 04a4 cbfb6e34
    004a4900  c1308000 cbfb6e7c  c012b26a c4084da0
Call Trace: [] [] [] []
Code: 10 55 57 56 53 8b 4c 24 2c 8b 19 eb 04 90 8b 5b 10 85 db 74

>>EIP; c0121e56 <__find_lock_page+2/dc>   <=
Trace; c0124186 
Trace; 81a4 
Trace; c012b26a 
Trace; c010a3d7 
Code;  c0121e56 <__find_lock_page+2/dc>
 <_EIP>:
Code;  c0121e56 <__find_lock_page+2/dc>   <=
   0:   10 55 57  adcb   %dl,0x57(%ebp)   <=
Code;  c0121e59 <__find_lock_page+5/dc>
   3:   56pushl  %esi
Code;  c0121e5a <__find_lock_page+6/dc>
   4:   53pushl  %ebx
Code;  c0121e5b <__find_lock_page+7/dc>
   5:   8b 4c 24 2c   movl   0x2c(%esp,1),%ecx
Code;  c0121e5f <__find_lock_page+b/dc>
   9:   8b 19 movl   (%ecx),%ebx
Code;  c0121e61 <__find_lock_page+d/dc>
   b:   eb 04 jmp11 <_EIP+0x11> c0121e67 
<__find_lock_page+13/dc>
Code;  c0121e63 <__find_lock_page+f/dc>
   d:   90nop
Code;  c0121e64 <__find_lock_page+10/dc>
   e:   8b 5b 10  movl   0x10(%ebx),%ebx
Code;  c0121e67 <__find_lock_page+13/dc>
  11:   85 db testl  %ebx,%ebx
Code;  c0121e69 <__find_lock_page+15/dc>
  13:   74 00 je 15 <_EIP+0x15> c0121e6b 
<__find_lock_page+17/dc>

Kernel panic: attempt to kill init!


And here is my dmesg:

Linux version 2.4.0-test8 (root@fury) (gcc version egcs-2.91.66 19990314/Linux 
(egcs-1.1.2 release)) #24 Sat Sep 9 17:36:22 EST 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 0001 @  (reserved)
 BIOS-e820: 0bf0 @ 0010 (usable)
On node 0 totalpages: 49152
zone(0): 4096 pages.
zone(1): 45056 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=test8 ro root=304 reboot=warm
Initializing CPU#0
Detected 300690318 Hz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 599.65 BogoMIPS
Memory: 191760k/196608k available (912k kernel code, 4460k reserved, 77k data, 180k 
init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Intel Pentium II (Klamath) stepping 04
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED])
PCI: PCI BIOS revision 2.10 entry at 0xfae60, last bus=1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7000] at 00:07.0
Limiting direct PCI/PCI transfers.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.13)
Starting kswapd v1.7
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native

Re: No Bug: accept discards socket options/O_NONBLOCK

[Matthias Andree]

On Fri, 15 Sep 2000, D. J. Bernstein wrote:

> O_NONBLOCK is not an fd property. It is an ofile property. Two different
> fds created by dup() will point to the same O_NONBLOCK bit.

Who says that accept() is to use dup()?

There is a difference in "new file descriptor" (what accept returns) and
"copy of the file descriptor" (what dup returns). 

You are relying on unspecified implementation details(*) and claiming Linux
was buggy. Please show papers that document either that accept must use
dup or that accept must copy file descriptor flags before claiming
someone else misbehaving.



*) unspecified as per SUS v2, Linux, FreeBSD, OpenBSD, NetBSD, Solaris,
HP-UX manual pages.

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

Re: No Bug: accept discards socket options/O_NONBLOCK

[Matthias Andree]

On Fri, 15 Sep 2000, Michael Poole wrote:

> Most of the programs called by inetd don't expect non-blocking I/O on
> their stdin and stdout, which they would suddenly get if accept()'ed
> sockets inherited the non-blocking nature of inetd's listening socket.

Looking at nkit 0.4.2, I cannot see a thing such as a non-blocking
listening socket (name the line if there is). Where does inetd set its
listening sockets to O_NONBLOCK? Why should an application that
originates on BSD misbehave if it got BSD semantics?

-- 
Matthias Andree

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

Linux 2.2.18pre9

[Alan Cox]

Resynchronize the USB stuff and starting bringing the ARM into line

2.2.18pre9
o   Fix usb module load oops(Thomas Sailer)
o   Bring USB boot drivers in line with 2.4t8   (Greg Kroah-Hartman)
o   And USB print drivers   (Greg Kroah-Hartman)
o   And USB Rio driver  (Greg Kroah-Hartman)
o   And USB dc2xx driver(Greg Kroah-Hartman)
o   And USB mdc800 driver   (Greg Kroah-Hartman)
o   NFSv3 support and NFS updates   (Trond Myklebust and co)
o   Compaq 64bit/66Mhz PCI Fibrechannel driver  (Amy Vanzant-Hodge)
o   Disable microtouch driver (doesnt work in 2.2   (Greg Kroah-Hartman)
currently)
o   Update ADFS support (Russell King)
o   Update ARM arch specific code and includes  (Russell King)
o   Update ARM specific drivers (Russell King)
o   Use both fast and slow A20 gating on boot   (Kira Brown)
| if your box doesnt boot I want to know about it...
| Needed for stuff like the AMD Elan

2.2.18pre8
o   Fix mtrr compile bug(Peter Blomgren)
o   Alpha PCI boot up fix   (Michal Jaegermann)
o   Fix vt/keyboard dependancy in USB config(Arjan van de Ven)
o   Fix sound hangs on cs4281   (Tom Woller)
o   Fix Alpha vmlinuz.lds   (Andrea Arcangeli)
o   Fix CDROMPLAYTRKIND bug, allow root to open (Jens Axboe)
the cd door whenver.
o   Update ov511 to match 2.4   (Greg Kroah-Hartman)
o   Further devio.c fix (Greg Kroah-Hartman)
o   Update NR_TASKS comment (Jarkko Kovala)
o   Further sparc64 ioctl translator fixes  (Andi Kleen)

2.2.18pre7
o   Fix the AGP compile in bug  (Arjan van de Ven)
o   Revert old incorrect syncppp state change   (Ivan Passos)
o   Fix i810 rng to actually get built in   (Arjan van de Ven)
o   Megaraid compile fix, joystick, mkiss fixes (Arjan van de Ven)
o   Kawasaki USB ethernet depends on net(Arjan van de Ven)
o   Compaq cpqarray update  (Charles White)
o   Fix usb problem with no USB unit found  (Oleg Drokin)
o   Driver for the radio on some maestro cards  (Adam Tlalka)
o   Additional shared map support needed for sparc64(Dave Miller)
o   Fix wdt_pci when compiled in(me, Arjan van de Ven)
o   Fix usb missing symbol when non modular (Arjan van de Ven)
o   Identify chip and also handle MTRR for the  (me)
Cyrix III
o   Allow binding to all ports multicast(Andi Kleen)
o   Bring USB docs up to date   (Greg Kroah-Hartman)
o   Bring USB devio up to date  (Greg Kroah-Hartman)
o   pci_resource_len null function for non PCI case (Arjan van de Ven)
o   Fix synchronous write off end of disk bug   (Jari Ruusu)

2.2.18pre6
o   Fix the IDE PCI not compiling bug   (Dag Wieers)
o   Kill an escaped reference to vger.rutgers   (Dave Miller)
o   Small rtl8139 fixups(Jeff Garzik)
o   Add USB bluetooth driver(Greg Kroah-Hartman)
o   Fix oops in visor driver(Greg Kroah-Hartman)
o   Remove some unneeded ext2 includes,fix a bug(Andreas Dilger)
in the UFS code
o   Fix rtc race between timer and rtc irq  (Andrea Arcangeli)
o   Fix slow gettimeofday SMP race  (Andrea Arcangeli)
o   Check lost_ticks in settimeofday to be more (Andrea Arcangeli)
precise

2.2.18pre5
o   Added older VIA ide chipsets to the not to be   (me)
autotuned list
o   Fix crash on boot problem with __setup stuff(me)
o   Small acenic fix(Matt Domsch)
o   Fix hfc_pci isdn driver (Jens David)
o   Fix smbfs configuration problem (Urban Widmark)
o   Emu10K wrapper/build fixes  (Rui Sousa)
o   Small cleanups  (Arjan van de Ven)
o   Fix sparc32 build bug   (Horst von Brand)
o   Fix quota oops  (Martin Diehl)
o   Add i810 random number driver   (Jeff Garzik)
o   Clear suid bits on ext2 truncate as per SuS (Andi Kleen)
o   Fix illegal use of section attributes   (Arjan van de Ven)
o   Documentation for nmi watchdog  (Marcelo Tosatti)
o   Fix uninitialised variable warnings (Arjan van de Ven)
o   Save DR6 condition into the TSS   

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Jamie Lokier]

[EMAIL PROTECTED] wrote:
> > Sure the global system is slower.  But the "interactive feel" is faster.
> 
> Let's pop up little buttons to make it "feel" faster.

If little buttons pop up quickly when I click on them, then yes that's
better interactive feel.  Sometimes the disk is involved in this.

Nobody has a problem with tuning the task scheduler to work this way.

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

CONFIG_VIDEO_BT848 in 2.4.0-test9pre1 missing

[Dietmar Kling]

Hi,

Is there any reason that the 
CONFIG_VIDEO_BT848 is missing in menuconfig?

(doesn't show up in .config either)

I added it manually in .config and the bttv drivers seem to compile


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

Re: (reiserfs) An elevator algorithm

[Ragnar Kjørstad]

On Sat, Sep 16, 2000 at 01:17:53PM +0200, Xuan Baldauf wrote:
> I'm not a kernel hacker (and therefore I'm not familiar with the kernel
> terminology), and maybe this idea is already old, but here is an
> algorithm for an elevator which tries to guarantee smoothness and no
> stalling:
> 
> Every rw-request gets an expiry timeout (e.g. in jiffies) where it's
> completion must have started. Every request is member of two sorted
> lists which support fast add|remove and iterating to the previous|next
> member (linked list, binary tree, etc.):
> The request list sorted by expiry and the request list sorted by block
> number. When a rw-access is requested, the request gets its timeout and
> is inserted in those two lists. The elevator has a current request on
> which it is working. When the elevator is finished, it removes the
> current request from the two lists and gets the "current time" (in
> jiffies). If the head of the request list sorted by expiry has a time
> equal to or smaller than the current time, the elevator continues with
> that request. Else it continues with the next or previous request in the
> list sorted by block number. (It can decide which direction, wether to
> continue with the old direction or wether to always start with a
> definite direction)
> 
> This way, you have good elevator characteristics while being somewhat
> able to guarantee maximum request duration. If the timeout expired, the
> requested block is served immediately. Only when the system is
> overloaded, so that the difference between the current time and the
> oldest expiry timout exceeds a given maximum, the elevator fails. In
> this case, the system should be throttled (inserting new requests should
> block), I think. Users could determine the expiry-timeouts so that
> important applications get shorter timeouts while not-so-important
> applications which can wait can request a longer timeout.
> 
> This algorithm is, of course, only per low-level-device.
> 
> What do you think?

If the load is to high to serve requests within the time-limit, the
elevator-code will stop working, and everything will slow down.

You should not serve a request imidiately when it's too old (because the
requests supposed to be served first according to the elevator is likely
to become too old soon, and then you only add more seeking), but only
stop inserting new requests before it.

If I understand the current code correctly, it works like this:

Current queue:

02:04:05:06:09:15 # sector to be written to
05:03:02:04:00:01 # request-nr

In this example the "timeout" is 5 requests, so a new request can never
be placed before a existing request with request-nr < new-request-nr-5;

One request is served (from the head of the queue) and a request to
sector 3 is added:

04:05:06:09:03:15 # sector to be written to
03:02:04:00:06:01 # request-nr

One request is served (from the head of the queue) and a request to
sector 2 is added:

05:06:09:03:15:02 # sector to be written to
02:04:00:06:01:07 # request-nr

One request is served (from the head of the queue) and a request to
sector 16 is added:

06:09:03:15:02:16 # sector to be written to
04:00:06:01:07:08 # request-nr


So we've ended up with a very silly queue

Now, the description of the algorithm said that there was a number
within each request that was declined by one whenever a new request
passed it in the queue. This will never be used after it becomes
negative, so it would be the same to decline the number of all the
requests by 1, right? And comparing this changing number to 0 is the
same as comparing request-numbers, only more work, right? So I assume I
didn't understand the algorithm correctly :)


Now, lets do the same test with my suggested multiple queue approach:


Current queue (full):
02:04:05:06:09:15 # sector to be written to
05:03:02:04:00:01 # request-nr

In this example the "timeout" is 5 requests, so only 6 requests can be
inserted into each queue.

One request is served (from the head of the queue) and a request to
sector 3 is added:

Current queue (full)
04:05:06:09:15 # sector to be written to
03:02:04:00:01 # request-nr
Second queue:
03 # sector to be written to
06 # request-nr


One request is served (from the head of the queue) and a request to
sector 2 is added:

Current queue (full)
05:06:09:15 # sector to be written to
02:04:00:01 # request-nr
Second queue:
02:03 # sector to be written to
07:06 # request-nr

One request is served (from the head of the queue) and a request to
sector 16 is added:


Current queue (full)
06:09:15 # sector to be written to
04:00:01 # request-nr
Second queue:
02:03:16 # sector to be written to
07:06:08 # request-nr


looks much better, doesn't it?


But then again, maybe I just didn't understand how the current code
works... I'm going to shut up now..



-- 
Ragnar Kjørstad
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkm

[PATCH] Fix floppy ioctl (which were broken in 2.4.0-test5)

[Alain Knaff]

The following patch (against 2.4.0-test8) restores ioctl functionality,
which has been broken in 2.4.0-test6-pre7:

--- 2.4.0-test8/linux/drivers/block/floppy.cMon Sep 11 20:09:28 2000
+++ linux/drivers/block/floppy.cSat Sep 16 15:03:39 2000
@@ -3435,6 +3435,8 @@
 static int fd_ioctl(struct inode *inode, struct file *filp, unsigned int cmd,
unsigned long param)
 {
+#define FD_IOCTL_MODE_BIT 8
+#define FD_IOCTL_ALLOWED ((filp) && ((filp)->f_mode & FD_IOCTL_MODE_BIT))
 #define OUT(c,x) case c: outparam = (const char *) (x); break
 #define IN(c,x,tag) case c: *(x) = inparam. tag ; return 0
 
@@ -3502,7 +3504,7 @@
return -EINVAL;
 
/* permission checks */
-   if (((cmd & 0x40) && !(filp->f_mode & 2)) ||
+   if (((cmd & 0x40) && !FD_IOCTL_ALLOWED) ||
((cmd & 0x80) && !capable(CAP_SYS_ADMIN)))
return -EPERM;
 
@@ -3774,6 +3776,12 @@
buffer_track = -1;
invalidate_buffers(MKDEV(FLOPPY_MAJOR,old_dev));
}
+
+   /* Allow ioctls if we have write-permissions even if read-only open.
+* Needed so that programs such as fdrawcmd still can work on write
+* protected disks */
+   if ((filp->f_mode & 2) || (permission(inode,2) == 0))
+   filp->f_mode |= FD_IOCTL_MODE_BIT;
 
if (UFDCS->rawcmd == 1)
UFDCS->rawcmd = 2;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

attempt to access beyond end of device

[Stephen E. Clark]

Help.

I am getting the above error when trying to build an Oracle Database. I
have tried 2.2.14 and
2.2.18pre8 with the same results. I am putting the DB on /usr8 which
from the df -m command should have plenty of room.

Is this a kernel problem or a problem on my part?

Below is part of my /var/log/messages file which shows my configuration
as well as the errors.

How do I relate dev 08:02 to my actual physical devices. I have 2 ide
drives and 3 scsi drives.

At the end of /var/log/messages I have appended my /etc/fstab, the
output from a df -m comand and fdisk output for each drive.

Any help in pointing to the problem would be greatly appreciated.

Thanks
Steve

excerpts from /var/log/messages:

Sep 15 19:01:54 joker syslogd 1.3-3: restart.
Sep 15 19:01:55 joker syslog: syslogd startup succeeded
Sep 15 19:01:55 joker syslog: klogd startup succeeded
Sep 15 19:01:55 joker kernel: klogd 1.3-3, log source = /proc/kmsg
started.
Sep 15 19:01:55 joker kernel: Inspecting /boot/System.map-2.2.18pre8
Sep 15 19:01:55 joker kernel: Loaded 8573 symbols from
/boot/System.map-2.2.18pre8.
Sep 15 19:01:55 joker kernel: Symbols match kernel version 2.2.18.
Sep 15 19:01:55 joker kernel: No module symbols loaded.
Sep 15 19:01:55 joker kernel: Linux version 2.2.18pre8
([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #2 Fri Sep 15 22:55:43 EDT 2000 
Sep 15 19:01:55 joker kernel: Detected 451030 kHz processor. 
Sep 15 19:01:55 joker kernel: Console: colour VGA+ 80x25 
Sep 15 19:01:55 joker kernel: Calibrating delay loop... 897.84 BogoMIPS 
Sep 15 19:01:55 joker kernel: Memory: 127452k/131072k available (1464k
kernel code, 412k reserved, 1680k data, 64k init) 
Sep 15 19:01:55 joker kernel: Dentry hash table entries: 16384 (order 5,
128k) 
Sep 15 19:01:55 joker kernel: Buffer cache hash table entries: 131072
(order 7, 512k) 
Sep 15 19:01:55 joker kernel: Page cache hash table entries: 32768
(order 5, 128k) 
Sep 15 19:01:55 joker kernel: VFS: Diskquotas version dquot_6.4.0
initialized 
Sep 15 19:01:55 joker kernel: CPU: L1 I Cache: 32K  L1 D Cache: 32K 
Sep 15 19:01:55 joker kernel: CPU: AMD-K6(tm) 3D processor stepping 0c 
Sep 15 19:01:55 joker kernel: Checking 386/387 coupling... OK, FPU using
exception 16 error reporting. 
Sep 15 19:01:55 joker kernel: Checking 'hlt' instruction... OK. 
Sep 15 19:01:55 joker kernel: POSIX conformance testing by UNIFIX 
Sep 15 19:01:55 joker kernel: mtrr: v1.35a (19990819) Richard Gooch
([EMAIL PROTECTED]) 
Sep 15 19:01:55 joker kernel: PCI: PCI BIOS revision 2.10 entry at
0xfb220 
Sep 15 19:01:55 joker kernel: PCI: Using configuration type 1 
Sep 15 19:01:55 joker kernel: PCI: Probing PCI hardware 
Sep 15 19:01:55 joker kernel: PCI: 00:38 [1106/0586]: Work around ISA
DMA hangs (00) 
Sep 15 19:01:55 joker kernel: Activating ISA DMA hang workarounds. 
Sep 15 19:01:55 joker kernel: Linux NET4.0 for Linux 2.2 
Sep 15 19:01:55 joker kernel: Based upon Swansea University Computer
Society NET3.039 
Sep 15 19:01:55 joker kernel: NET4: Unix domain sockets 1.0 for Linux
NET4.0. 
Sep 15 19:01:55 joker kernel: NET4: Linux TCP/IP 1.0 for NET4.0 
Sep 15 19:01:55 joker kernel: IP Protocols: ICMP, UDP, TCP, IGMP 
Sep 15 19:01:55 joker kernel: TCP: Hash tables configured (ehash 131072
bhash 65536) 
Sep 15 19:01:55 joker kernel: IPv4 over IPv4 tunneling driver 
Sep 15 19:01:55 joker kernel: early initialization of device tunl0 is
deferred 
Sep 15 19:01:55 joker kernel: GRE over IPv4 tunneling driver 
Sep 15 19:01:55 joker kernel: early initialization of device gre0 is
deferred 
Sep 15 19:01:55 joker kernel: Initializing RT netlink socket 
Sep 15 19:01:55 joker kernel: Starting kswapd v 1.5  
Sep 15 19:01:55 joker kernel: parport0: PC-style at 0x378 [SPP,PS2] 
Sep 15 19:01:55 joker kernel: Detected PS/2 Mouse Port. 
Sep 15 19:01:55 joker kernel: Serial driver version 4.27 with no serial
options enabled 
Sep 15 19:01:55 joker kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A 
Sep 15 19:01:55 joker kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A 
Sep 15 19:01:55 joker kernel: pty: 256 Unix98 ptys configured 
Sep 15 19:01:55 joker kernel: lp0: using parport0 (polling). 
Sep 15 19:01:55 joker kernel: Real Time Clock Driver v1.09 
Sep 15 19:01:55 joker kernel: RAM disk driver initialized:  16 RAM disks
of 0K size 
Sep 15 19:01:55 joker kernel: loop: registered device at major 7 
Sep 15 19:01:55 joker kernel: VP_IDE: IDE controller on PCI bus 00 dev
39 
Sep 15 19:01:55 joker kernel: VP_IDE: not 100% native mode: will probe
irqs later 
Sep 15 19:01:55 joker kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS
settings: hda:DMA, hdb:DMA 
Sep 15 19:01:55 joker kernel: ide0: VIA Bus-Master (U)DMA Timing Config
Success 
Sep 15 19:01:55 joker kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS
settings: hdc:pio, hdd:pio 
Sep 15 19:01:55 joker kernel: ide1: VIA Bus-Master (U)DMA Timing Config
Success 
Sep 15 19:01:55 joker kernel: hda: JTS CORPORATION CHAMPION MODEL
C3200-2A, ATA DISK drive 
Sep 15 1

Re: [PATCH] Fix floppy ioctl (which were broken in 2.4.0-test5)

[Tigran Aivazian]

Alain,

Al Viro, myself and Linus broke this intentionally. Please read the
comments we put in blkdev_get() in fs/block_dev.c and understand that this
is a non-trivial issue - we had an interesting conversation about it -
unfortunately all my mailfolders are gone (as a side-effect of truncate
issues :) so I can't remeber the thread subject - seek and ye shall find.

So, your patch would panic the system as it used to before the fix.

Regards,
Tigran

 On Sat, 16 Sep
2000, Alain Knaff wrote:

> The following patch (against 2.4.0-test8) restores ioctl functionality,
> which has been broken in 2.4.0-test6-pre7:
> 
> --- 2.4.0-test8/linux/drivers/block/floppy.c  Mon Sep 11 20:09:28 2000
> +++ linux/drivers/block/floppy.c  Sat Sep 16 15:03:39 2000
> @@ -3435,6 +3435,8 @@
>  static int fd_ioctl(struct inode *inode, struct file *filp, unsigned int cmd,
>   unsigned long param)
>  {
> +#define FD_IOCTL_MODE_BIT 8
> +#define FD_IOCTL_ALLOWED ((filp) && ((filp)->f_mode & FD_IOCTL_MODE_BIT))
>  #define OUT(c,x) case c: outparam = (const char *) (x); break
>  #define IN(c,x,tag) case c: *(x) = inparam. tag ; return 0
>  
> @@ -3502,7 +3504,7 @@
>   return -EINVAL;
>  
>   /* permission checks */
> - if (((cmd & 0x40) && !(filp->f_mode & 2)) ||
> + if (((cmd & 0x40) && !FD_IOCTL_ALLOWED) ||
>   ((cmd & 0x80) && !capable(CAP_SYS_ADMIN)))
>   return -EPERM;
>  
> @@ -3774,6 +3776,12 @@
>   buffer_track = -1;
>   invalidate_buffers(MKDEV(FLOPPY_MAJOR,old_dev));
>   }
> +
> + /* Allow ioctls if we have write-permissions even if read-only open.
> +  * Needed so that programs such as fdrawcmd still can work on write
> +  * protected disks */
> + if ((filp->f_mode & 2) || (permission(inode,2) == 0))
> + filp->f_mode |= FD_IOCTL_MODE_BIT;
>  
>   if (UFDCS->rawcmd == 1)
>   UFDCS->rawcmd = 2;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Tigran Aivazian]

FYI, here is a chunk of our conversation - I just realized that most of it
was private with AV and Linus so it is reasonable that you didn't see it.

Regards,
Tigran

-- Forwarded message --
Date: Sun, 6 Aug 2000 22:45:44 -0400 (EDT)
From: Alexander Viro <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Cc: Tigran Aivazian <[EMAIL PROTECTED]>, Alexander Viro <[EMAIL PROTECTED]>
Subject: Re: bug in blkdev <-> VFS interaction. (oops) (fwd)




On Sun, 6 Aug 2000, Linus Torvalds wrote:

> So this is why I suggested moving the blkdev_get() into read_super(): at
> that point root mounting actually has enough information to create a
> "good" fake inode (ie it has the superblock pointer that we are going to
> mount on). 
> 
> Yes, it will still be a fake inode, it will just be slightly less fake,
> and now the fake inode is restricted to only happen at root mount time.

Linus, I think that the real cure is different. Ask yourself "WTF does
floppy_open() call permission() at all?". Look at the code:

/* Allow ioctls if we have write-permissions even if read-only open */
if ((filp->f_mode & 2) || (permission(inode,2) == 0))
filp->f_mode |= IOCTL_MODE_BIT;

It is obviously bogus: if the program wants to do them - let it open device
for write. Then the check in question will happen where it belongs.

In other words, let's remove the dungpile instead of trying to build a bridge
over it.
Cheers,
Al



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

Re: 2.4.0-test8 tried to kill init!

[Rik van Riel]

On Sat, 16 Sep 2000, Harley Anderson wrote:

> I was just sitting here reading a page in lynx that I grabbed yesterday and got
> spammed by 2 or 3 oopsies..
> The machine had been up for approximately 44 hours with fairly light load.
> Only caught the bottom of the 1st or second one but it had
> 
>   kernel BUG at page_alloc.c:194!

If I'm not mistaken, this is a BAD_RANGE check,
indicating that a page hasn't been filed away
in the right memory zone...

> at the bottom. The next one was from the startup script from my
> ROM mud segfaulting,

Sounds like memory corruption ...

> Right after this I flicked to another VC (already logged in as
> root), I think I tried to do a ps, but then got this monster:

[snip bad oops]


This sounds like either some bit errors in memory
(memtest86 will find those), or a device driver
scribbling over memory, or the memory not being
refreshed or operated at the right speed (memory
to slow for the speed you're running it at?)...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

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

Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial

[Igmar Palsenberg]

On Fri, 15 Sep 2000, David Ciemiewicz wrote:

> [4.] Linux version 2.2.14-5.0 ([EMAIL PROTECTED]) (gcc version

Don't report bugs with this old version.

[root@base igmar]# uname -a
Linux base.jdimedia.nl 2.2.17acl #2 Mon Sep 11 02:23:03 CEST 2000 i586
unknown

[root@base igmar]# cat /proc/tty/driver/serial
serinfo:1.0 driver:4.27
0: uart:16550A port:3F8 irq:4 baud:1200 tx:3328 rx:354427 fe:245 brk:914
RTS|DTR1: uart:16550A port:2F8 irq:3 baud:9600 tx:103818 rx:4576 CTS|DSR
2: uart:unknown port:3E8 irq:4
3: uart:unknown port:2E8 irq:3

Works fine here.



Igmar

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

No Subject

[Terence Ang]

Dear All,

Could anyone kindly tell me how to setup software RAID1 on IDE drives under 
RedHat 6.2?

I have got one extra PCI IDE card with 2 hard disks (not mentioning the existing 
Linux OS hard disk)

It seemed that the card could not be detected under Linux.

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

Re: [PATCH] Fix floppy ioctl (which were broken in 2.4.0-test5)

[Alexander Viro]

On Sat, 16 Sep 2000, Alain Knaff wrote:

> The following patch (against 2.4.0-test8) restores ioctl functionality,
> which has been broken in 2.4.0-test6-pre7:

I would reserve "broken" for original state. What's wrong with "if you
want write permissions to be checked during open() - open the bloody file
for write"? IOW, why on the Earth do we need magical semantics in this
case?

Moreover, permission(9) requires full-blown struct inode. Care to tell
what filesystem it should belong to when we are mounting the
root? BTW, you do realize that if root is mounted read-only your check
(for /dev/fd0) will give negative? permission(9) doesn't treat devices as
something special - open() does.

Another thing: you are defining new ->f_flags bits. Private to the
driver. It asks for trouble - they are invisible in fs.h and if somebody
would start adding new generic flags...

The bottom line being: permissions on floppy ioctls look like a serious
(and completely unnecessary) kludge. If you want open(2) check write
permissions - do what every normal UNIX program would do and pass the
O_RDWR or O_WRONLY - thay's why they are there, after all. Cleaner,
simpler and doesn't rely on permission(9) being able to cope with fake
inode.

If you really want to have "deny if device node is on read-only
filesystem" (the only real difference between new and old behaviour) - I
would really like to hear the reason for that. I definitely see reasons
why it is bogus.

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alain Knaff]

>FYI, here is a chunk of our conversation - I just realized that most of it
>was private with AV and Linus so it is reasonable that you didn't see it.

Thanks for mailing me this. Well, I would have actually preferred to
take part in this discussion when it first took place, rather than
learning about it more than a month later. But hey, better late then
never.

>-- Forwarded message --
>Date: Sun, 6 Aug 2000 22:45:44 -0400 (EDT)
>From: Alexander Viro <[EMAIL PROTECTED]>
>To: Linus Torvalds <[EMAIL PROTECTED]>
>Cc: Tigran Aivazian <[EMAIL PROTECTED]>, Alexander Viro <[EMAIL PROTECTED]>
>Subject: Re: bug in blkdev <-> VFS interaction. (oops) (fwd)
>
>On Sun, 6 Aug 2000, Linus Torvalds wrote:
>
>> So this is why I suggested moving the blkdev_get() into read_super(): at
>> that point root mounting actually has enough information to create a
>> "good" fake inode (ie it has the superblock pointer that we are going to
>> mount on). 
>> 
>> Yes, it will still be a fake inode, it will just be slightly less fake,
>> and now the fake inode is restricted to only happen at root mount time.
>
>Linus, I think that the real cure is different. Ask yourself "WTF does
>floppy_open() call permission() at all?". Look at the code:
>
>/* Allow ioctls if we have write-permissions even if read-only open */
>   if ((filp->f_mode & 2) || (permission(inode,2) == 0))
>   filp->f_mode |= IOCTL_MODE_BIT;
>
>It is obviously bogus: if the program wants to do them - let it open device
>for write. Then the check in question will happen where it belongs.

Well, if you (A. Viro) would have bothered to ASK, I could have told
you the reason for this test right away: you cannot open a
write-protected floppy disk for writing, however you might still want
to issue ioctls that need "privileged" access to it. With your patch,
there is no way of reading an XDF disk if it is write protected.
Moreover, on a normal open, the floppy driver attempts a test read to
do format autodetecting. Obviously, this is unappropriate for certain
operations, such as formatting a disk, hence you need a way to open
for neither read/write but still have the appropriate permission
check.

>In other words, let's remove the dungpile instead of trying to build a bridge
>over it.

Oh, thanks so much for your kind words. Why are you so quick to assume
that your fellow developers do "obviously bogus" stuff, rather than
just ASKING them why they wrote a certain piece of code? My e-mail
address was not exactly hard to find, was it?

Ok, now let's move on to some constructive problem solving: wouldn't
it be possible to tag the fake inode in a certain way, so as to make
it clear that it is indeed a fake inode? That way, I could do sth like
the following:

if ((filp->f_mode & 2) || 
(!IS_FAKE(inode) &&(permission(inode,2) == 0)))
filp->f_mode |= IOCTL_MODE_BIT;


>From your other mail, I understand that these fake inodes only happen
for mounting the root filesystem: in that situation, you don't need to
perform ioctls anyways, so no problem forgetting the IOCTL_MODE_BIT
for this situation.

>   Cheers,
>   Al
>
>

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

Re: Update Linux 2.4 Status/TODO list

[Marco d'Itri]

On Sep 15, Alexander Viro <[EMAIL PROTECTED]> wrote:

 >> I tried doing that for Andrea but I think it's not useful, active is
 >> mmapped and strace shows nothing interesting.
 >mmapped... Does mmap() go past the end of file?
I asked INN developers and they think it should not.
The file size is fixed and its fields are updated in place.

 >>  >BTW, how does test8+patch to block_truncate_page() behave?
There is no change, yesterday at shutdown the active file has not been
updated.

-- 
ciao,
Marco


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

VM comparison

[James Lewis Nance]

Hello All,
I am interested in Rik's new VM system so I am running some "How long does
it take to build mozilla" benchmarks.  I only have results for 2.2.17 and
2.4.0-test9-pre1 right now, but the results look very good and I wanted to
share them:

bessie> cat 2.2.17/time.*
4086.110u 544.630s 1:23:55.50 91.9% 0+0k 0+0io 4972913pf+8543w
4090.640u 524.060s 1:23:14.79 92.3% 0+0k 0+0io 4963086pf+4833w
4090.530u 516.750s 1:23:02.86 92.4% 0+0k 0+0io 4962276pf+2901w
4079.830u 523.390s 1:24:35.97 90.6% 0+0k 0+0io 4963914pf+3967w
bessie> cat 2.4.0-test9/time.*
3792.580u 354.240s 1:15:33.35 91.4% 0+0k 0+0io 4136435pf+0w
3813.200u 354.770s 1:15:17.04 92.2% 0+0k 0+0io 4136443pf+0w
3814.320u 356.090s 1:15:30.21 92.0% 0+0k 0+0io 4136452pf+0w

I want to add 2.4.0-test8 and 2.4.0-test-pre1+Rik'sfix to the list and I
also want to boot up with ram=48M to add more VM pressure.

Thanks,

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

Re: Linux 2.2.18pre9

[Matthias Andree]

On Sat, 16 Sep 2000, Alan Cox wrote:

> Resynchronize the USB stuff and starting bringing the ARM into line
> 
> 2.2.18pre9
> o NFSv3 support and NFS updates   (Trond Myklebust and co)

Great. Will test.

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

Re: [PATCH] Fix floppy ioctl (which were broken in 2.4.0-test5)

[Andries Brouwer]

On Sat, Sep 16, 2000 at 03:26:33PM +0200, Alain Knaff wrote:

> The following patch (against 2.4.0-test8) restores ioctl functionality,
> which has been broken in 2.4.0-test6-pre7:


> + /* Allow ioctls if we have write-permissions even if read-only open.
> +  * Needed so that programs such as fdrawcmd still can work on write
> +  * protected disks */
> + if ((filp->f_mode & 2) || (permission(inode,2) == 0))
> + filp->f_mode |= FD_IOCTL_MODE_BIT;


Strange obscure kludges.
In util-linux 2.10o fdformat was fixed to work with 2.4.0test6.
In util-linux 2.10p (not yet released) setfdprm is fixed.
Only if there are programs that cannot be fixed we should
look at the kernel code again. But not go back to the old state.

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

Re: 2.4.0-test8 tried to kill init! (addendum)

[Harley Anderson]

> This sounds like either some bit errors in memory
> (memtest86 will find those), or a device driver
> scribbling over memory, or the memory not being
> refreshed or operated at the right speed (memory
> to slow for the speed you're running it at?)...

Hmm, Andrew just informed me that the rtl8139 driver in test8 is pretty nasty. 
Does that sound like a probable suspect?
The card itself hasn't talked to anything in a few days, is it likely to mess
with memory if it isn't doing anything?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Ooops with 2.2.17

[Jens Hoffrichter]

Hi, 

On my Server just happenend a Kernel-Ooops, and afterwards some programs
crashed, e.g. "w" crashed with a Segmentation fault and "ps" crashed
with a Signal 11.

Recently I encountered Oopse on a regularly basis, but after upgrading
to 2.2.17, everything seemed to be alright, but now, 3 days later the
first oops after the upgrade occured.

The system is a AMD K5/PR100, 64 MB of RAM and a Debian Potato
installed.

I've included the decoded oops message and my kernel-config.

Thanks in advance,

Jens

 Output of ksymoops -

WARNING: This version of ksymoops is obsolete.
WARNING: The current version can be obtained from ftp://ftp.ocs.com.au/pub/ksymoops
Options used: -V (default)
  -o /lib/modules/2.2.17/ (default)
  -k /proc/ksyms (default)
  -l /proc/modules (default)
  -m /boot/System.map-2.2.17 (specified)
  -c 1 (default)

No modules in ksyms, skipping objects
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010206
eax: 0200   ebx: c36e4b60   ecx: c36e4fe0   edx: c36e4ddc
esi: 40074000   edi: c33e0140   ebp: 2000   esp: c18edefc
ds: 0018   es: 0018   ss: 0018
Process local (pid: 17436, process nr: 42, stackpage=c18ed000)
Stack:  b9ac c3655a20 c3197280  c36e47a0 c2b20990 0004
   c1858578 c0110f5c c33e0140 c1858578 ba20 c0110f53 c33e0140 
    c1634000 c33e0140 4014dddc  c0110f14 c33e0140 c18ec000
Call Trace: [] [] [] [] [] 
[] []
Code: 8b 40 08 85 c0 74 0b 83 c4 fc 55 56 53 ff d0 83 c4 10 8b 43

>>EIP: c011a692 
Trace: c0110f5c 
Trace: c0110f53 
Trace: c0110f14 
Trace: c011597a 
Trace: c0115971 
Trace: c0115b5d 
Trace: c0107a64 
Code:  c011a692   <_EIP>: <===
Code:  c011a692 0:8b 40 08mov
0x8(%eax),%eax <===
Code:  c011a695 3:85 c0   test   
%eax,%eax
Code:  c011a697 5:74 0b   je 
 c011a6a4 
Code:  c011a699 7:83 c4 fcadd
$0xfffc,%esp
Code:  c011a69c a:55  push   
%ebp
Code:  c011a69d b:56  push   
%esi
Code:  c011a69e c:53  push   
%ebx
Code:  c011a69f d:ff d0   call   
*%eax
Code:  c011a6a1 f:83 c4 10add
$0x10,%esp
Code:  c011a6a412:8b 43 00mov
0x0(%ebx),%eax


3 warnings issued.  Results may not be reliable.


 Kernel config ---

#
# Automatically generated make config: don't edit
#

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
CONFIG_M586=y
# CONFIG_M586TSC is not set
# CONFIG_M686 is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_1GB=y
# CONFIG_2GB is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_SMP is not set

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_QUIRKS=y
# CONFIG_PCI_OPTIMIZE is not set
CONFIG_PCI_OLD_PROC=y
# CONFIG_MCA is not set
# CONFIG_VISWS is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
# CONFIG_BINFMT_JAVA is not set
# CONFIG_PARPORT is not set
# CONFIG_APM is not set
# CONFIG_TOSHIBA is not set

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_VIA82C586 is not set
# CONFIG_BLK_DEV_CMD646 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_IDE_CHIPSETS is not set

#
# Additional Block Devices
#
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_PARIDE_PARPORT=y
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_DEV_HD is not set

#
# Networking options
#
CONFIG_PACKET=y
# CON

2.2.18pre7 [OOPS] + [PATCH]

[Andrzej Krzysztofowicz]

>From kufel!ankry  Fri Sep 15 23:04:36 2000
Return-Path: 
Received: from kufel.UUCP (uucp@localhost)
by green.mif.pg.gda.pl (8.9.3/8.9.3) with UUCP id XAA15722
for green.mif.pg.gda.pl!ankry; Fri, 15 Sep 2000 23:04:36 +0200
Received: (from ankry@localhost)
by kufel.dom (8.9.3/8.9.3) id XAA03971
for green!ankry; Fri, 15 Sep 2000 23:08:21 +0200
From: Andrzej Krzysztofowicz 
Message-Id: <[EMAIL PROTECTED]>
Subject: 2.2.18pre7 [OOPS] +  [PATCH]
To: kufel!green.mif.pg.gda.pl!ankry
Date: Fri, 15 Sep 2000 23:08:21 +0200 (CEST)
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[EMAIL PROTECTED], cox

Hi,

   I think, I found accidentally a bug in the universal cdrom driver with no
/proc fs support. The following configuration gives me an oops during boot
(key options):

CONFIG_SYSCTL=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SR=y
CONFIG_SCSI_QLOGIC_FAS=y
# CONFIG_PROC_FS is not set

Oops, and patch that fixes it for build-in cdrom.c follows.

Unfortunately I'm not sure whether it is correct, that MOD_INC_USE_COUNT /
MOD_DEC_USE_COUNT for cdrom module are called only via /proc interface and
can't work when /proc is disabled ...
Well, maybe the module is locked in an alteranative way ? Can anybody confirm
it ?


Unable to handle NULL pointer dereference at virtual address 001c
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 
Oops: 0002
CPU:0
EIP:0010:[]
EFLAGS: 00010202
eax:    ebx: c01df3f8   ecx:    edx: c7ffc0e0
esi: c01df42c   edi: c7ff3018   ebp: 000b   esp: c7ff9f74
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, process nr: 1, stackpage=c7ff9000)
Stack: c01a1e33 c01c69cc  c7ff9fac c7ff3040  c019f930 c7ff3018
   c01df3c0    c7ff9fa8 00307273  c01ea343
   0f00 c01e1fd8 c0106000 c01e733d 0f00 c01e1fd8 c0106000 8000
Call Trace: [] [] [] [] [] 
[] []
   [] 
Code: c7 40 1c d0 65 1a c0 a1 cc f4 1d c0 a3 84 b3 20 c0 a1 d0 f4

4533 symbols from /usr/src/kernel/2.2/linux/System.map

EIP:   0xc01a65f6 t cdrom_sysctl_register+0x22/0x6c
trace: 0xc01a1e33 T register_cdrom+0x73/0x1d8
trace: 0xc01c69cc T stext_lock+0xf5d8/0x19f5c
trace: 0xc019f930 t sr_finish+0x128/0x178
trace: 0xc0106000 T get_options+0x0/0x74
trace: 0xc0106000 T get_options+0x0/0x74
trace: 0xc011ef48 T kswapd+0x0/0x9c
trace: 0xc0106093 t init+0x7/0x140
trace: 0xc0106527 T kernel_thread+0x23/0x30
code:   :
code: 0:c7 40 1c d0 65 1a c0movl   $0xc01a65d0,0x1c(%eax)
code: 7:a1 cc f4 1d c0  mov0xc01df4cc,%eax
code: c:a3 84 b3 20 c0  mov%eax,0xc020b384
code:11:a1  .byte 0xa1
code:12:d0  (bad)  
code:13:f4  hlt


--- drivers/cdrom/cdrom.c.old   Fri Sep 15 22:09:44 2000
+++ drivers/cdrom/cdrom.c   Fri Sep 15 22:48:28 2000
@@ -2557,6 +2557,7 @@
 
 static struct ctl_table_header *cdrom_sysctl_header;
 
+#ifdef CONFIG_PROC_FS
 /*
  * This is called as the fill_inode function when an inode
  * is going into (fill = 1) or out of service (fill = 0).
@@ -2573,6 +2574,7 @@
MOD_DEC_USE_COUNT;
}
 }
+#endif /* CONFIG_PROC_FS */
 
 static void cdrom_sysctl_register(void)
 {
@@ -2582,7 +2584,9 @@
return;
 
cdrom_sysctl_header = register_sysctl_table(cdrom_root_table, 1);
+#ifdef CONFIG_PROC_FS
cdrom_root_table->child->de->fill_inode = &cdrom_procfs_modcount;
+#endif /* CONFIG_PROC_FS */
 
/* set the defaults */
cdrom_sysctl_settings.autoclose = autoclose;


-- 
===
  Andrzej M. Krzysztofowicz   [EMAIL PROTECTED]
  tel.  (0-58) 347 14 61
Wydz.Fizyki Technicznej i Matematyki Stosowanej Politechniki Gdanskiej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alexander Viro]

On Sat, 16 Sep 2000, Alain Knaff wrote:

> >FYI, here is a chunk of our conversation - I just realized that most of it
> >was private with AV and Linus so it is reasonable that you didn't see it.
> 
> Thanks for mailing me this. Well, I would have actually preferred to
> take part in this discussion when it first took place, rather than
> learning about it more than a month later. But hey, better late then
> never.

Oops... Mea culpa. Alain, my apologies for that.
Al

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

ISAPnP + Soundblaster doesn't work without 'multiple=0'

[Harald Dunkel]

Hi folks,

According to Documentation/sound/Soundblaster I have to report that
I had to set the option 'multiple=0' to make my Soundblaster16 work.
Without this option I get the following message at boot time:

:
:
Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
SB 4.13 detected OK (220)
sb: I/O region in use.
Sound: Hmm, DMA1 was left allocated - fixed
Sound: Hmm, DMA6 was left allocated - fixed
Unable to handle kernel paging request at virtual address c8866060
 printing eip:
c885844d
*pde = 012d8063
*pte = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010286
eax: c8866060   ebx: c120cd20   ecx:    edx: 
esi: c1282660   edi:    ebp:    esp: c7c95f08
ds: 0018   es: 0018   ss: 0018
Process aumix (pid: 65, stackpage=c7c95000)
Stack:  c1282660 c7d06500 c128e660  c1282660 c7d06500 c128e660 
   72616863 6a616d2d 312d726f c1280034 ffeb c0128394 c7d06500 c1282660 
   c1282660 c7d06500  c01276a9 c7d06500 c1282660 0002 0804ddb4 
Call Trace: [] [] [] [] [] 
Code: 8b 10 85 d2 74 1d 52 e8 cf cc 8b f7 83 c4 04 85 c0 74 14 8b 
:
:

This is the output of ksymoops:

ksymoops 2.3.4 on i586 2.4.0-test8.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test8/ (default)
 -m /usr/src/linux/System.map (specified)

Unable to handle kernel paging request at virtual address c8866060
c885844d
*pde = 012d8063
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: c8866060   ebx: c120cd20   ecx:    edx: 
esi: c1282660   edi:    ebp:    esp: c7c95f08
ds: 0018   es: 0018   ss: 0018
Process aumix (pid: 65, stackpage=c7c95000)
Stack:  c1282660 c7d06500 c128e660  c1282660 c7d06500 c128e660 
   72616863 6a616d2d 312d726f c1280034 ffeb c0128394 c7d06500 c1282660 
   c1282660 c7d06500  c01276a9 c7d06500 c1282660 0002 0804ddb4 
Call Trace: [] [] [] [] [] 
Code: 8b 10 85 d2 74 1d 52 e8 cf cc 8b f7 83 c4 04 85 c0 74 14 8b 

>>EIP; c885844d <[soundcore]soundcore_open+49/184>   <=
Trace; c0128394 
Trace; c01276a9 
Trace; c01275e3 
Trace; c01278d9 
Trace; c0108d23 
Code;  c885844d <[soundcore]soundcore_open+49/184>
 <_EIP>:
Code;  c885844d <[soundcore]soundcore_open+49/184>   <=
   0:   8b 10 mov(%eax),%edx   <=
Code;  c885844f <[soundcore]soundcore_open+4b/184>
   2:   85 d2 test   %edx,%edx
Code;  c8858451 <[soundcore]soundcore_open+4d/184>
   4:   74 1d je 23 <_EIP+0x23> c8858470 <[soundcore]sou
ndcore_open+6c/184>
Code;  c8858453 <[soundcore]soundcore_open+4f/184>
   6:   52push   %edx
Code;  c8858454 <[soundcore]soundcore_open+50/184>
   7:   e8 cf cc 8b f7call   f78bccdb <_EIP+0xf78bccdb> c0115128 
Code;  c8858459 <[soundcore]soundcore_open+55/184>
   c:   83 c4 04  add$0x4,%esp
Code;  c885845c <[soundcore]soundcore_open+58/184>
   f:   85 c0 test   %eax,%eax
Code;  c885845e <[soundcore]soundcore_open+5a/184>
  11:   74 14 je 27 <_EIP+0x27> c8858474 <[soundcore]sou
ndcore_open+70/184>
Code;  c8858460 <[soundcore]soundcore_open+5c/184>
  13:   8b 00 mov(%eax),%eax



This problem seems to be in since 2.4.0-test7. 




Please mail me if I can help to fix the problem. 


Regards

Harri
-- 
Harald Dunkel | [EMAIL PROTECTED] | If your operating system seems to
Synopsys GmbH | Kaiserstr. 100 | be made by Dr. Frankenstein, then
52134 Herzogenrath, Germany| it is time for a change.
+49 2407 9558 (fax? 44: 0) |Try Linux!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Preallocated skb's?

[jamal]

On Fri, 15 Sep 2000, Bogdan Costescu wrote:

> On Fri, 15 Sep 2000, jamal wrote:
> 
> > Only the timer runs at HZ granularity ;-<
> 
> Some cards provide their own high resolution timers; latest 3Com cards
> provide several with different purposes (none currently used). The
> question is how many of these also provide the Rx early interrupts.
> You also mentioned an auto-tunable Rx mitigation scheme. How do you
> implement it without using hardware timers ?
> 

Oh, the tulip 21143 explicitly has an interupt mitigation timer; this is
for both the tx and rx. But i see you can also use a general purpose timer
on the NIC to simulate mitigation.
disable rx interupts and other sources of noise (eg rx no buf) and set the
timer to wait a certain number of packet times.
Donald's drivers generally have this scheme built in; however, it is a
one-shot mode on rx work overload (mostly there for interupt sharing
according to one of Donald's old posts).
So what you do instead is have a table of these 'mitigation' values[1]
and select the appropriate mitigation value; i.e you have a pointer that
moves up and down the table and based on the load picks the correct
mitigation value.
When Robert Oks the current tulip, you should be able to see how it is
done there.

> > 20Msec is probably too much time. If my math is not wrong, 1 bit time in
> > a 100Mps is 1 ns; 64 bytes is 512ns.
> 
> I think your are wrong by a factor of 10 here, 1 bit time at 100Mbps
> should be 10 ns. Then 64 bytes is 5.12 us (u=micro). Anyway, this is
> comparable with the time needed to reach ISR, so you can have several
> (but small number) of packets already waiting for processing.
> 
> > You use the period(5-10micros), while waiting
> > for full packet arrival, to make the route decision (lookup etc).
> > i.e this will allow for a better FF; it will not offload things.
> 
> Just that you span several layers by doing this, it's not driver specific
> anymore.

I think we should heed Donald's advice on this early rx. I would take
Donald's word for it; he's been there done that. He knows.
eg the PCI burst issues makes a lot of sense. Unless someone with the
right tools (eg PCI bus monitors) might do some measurements and maybe
challenge Donald ;->

cheers,
jamal

[1] the table would look something like:
table[0] == 1 packet per interupt (default); disable timer
table[1] == 2 packets per interupt
table[3] == 3 packets per interupt 
.
.
etc.
use 64 bytes as the packet size since it is the smallest ethernet size.
as you pointed out that is 51.2 microsecs. so 102.4 microsecs for table[1]


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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alexander Viro]

On Sat, 16 Sep 2000, Alain Knaff wrote:

> Ok, now could you tell me a way how to easily detect a "fake inode",
> and I rewrite my "restore ioctl functionality patch" in a way as not
> to break floppy root mounts.

s/root//

fake means NULL ->i_sb, nothing fancy about that. IS_RDONLY() used to be
very defensive and that's the only thing that didn't let this code blow
into your face from the very beginning. You can protect the call of
permission() with if (inode->i_sb). However,  I still think that it's
bogus - after a look at the ioctl list it seems that most of them are
sysctls in disguise (come on, verbosity level for debugging printk()s as
ioctl()?)

Probably the clean solution would be to add a character device per
controller (/dev/fdc), turning eject /dev/fd0 into
% echo eject 0 > /dev/fdc0
etc. Then access control is done via permissions of /dev/fdc* - no need
to make the driver aware of VFS guts, layout of struct inode, etc.

I can do that. It doesn't require any modifications to the core part of
the driver (trivial character device glue + tiny parser calling the same
functions that fd_ioctl() calls), so it should be reasonably safe.
I would really like to know what uses floppy-specific ioctls, though -
look at the callers would probably clarify the situation.

Comments?

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

Re: attempt to access beyond end of device

[Andries Brouwer]

On Sat, Sep 16, 2000 at 09:35:46AM -0400, Stephen E. Clark wrote:

> How do I relate dev 08:02 to my actual physical devices. I have 2 ide
> drives and 3 scsi drives.

dev 08:02 is /dev/sda2, your swap device.

> Sep 15 19:01:55 joker kernel: Adding Swap: 66020k swap-space (priority
> -1) 
> Sep 15 19:01:55 joker kernel: Adding Swap: 52412k swap-space (priority
> -2) 
> Sep 15 23:24:34 joker inetd[419]: pid 1458: exit status 1
> Sep 15 23:53:48 joker kernel: attempt to access beyond end of device 
> Sep 15 23:53:48 joker kernel: 08:02: rw=1, want=40164, limit=40162 
> Sep 15 23:53:48 joker kernel: dev 08:02 blksize=4096 blocknr=10040
> sector=80320 size=4096 count=1 

> /dev/hda3   swapswapdefaults   
> /dev/sda2   swapswapdefaults   

> /dev/hda3   251   381 66024   82  Linux swap
> /dev/sda26165 40162+  82  Linux swap

You see what happened:
You added /dev/sda2, a device that has 40162 blocks,
and told the kernel that it was good for 52412k swap space.

I seem to recall that I once fixed this, in the sense that
the kernel noticed a mismatch between the size of the swap device
and what the swap header says - but maybe that was only for 2.4
or perhaps it never got in - will check.
In the meantime it seems that your problems will be fixed
if you redo mkswap.

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Trond Myklebust]

> " " == Michael Eisler <[EMAIL PROTECTED]> writes:

 > Focus on correctness and do the expedient thing first, which
 > is:
 > - The first time a file is locked, flush dirty pages
 >  to the server, and then invalidate the page cache

This would be implemented with the last patch I proposed.

 > - While the file is locked, do vypass the page cache for all
 >I/O.

This is not possible given the current design of the Linux VFS. The
design is such that all reads/writes go through the page cache. I'm
not sure that it is possible to get round this without some major
changes in VFS philosophy. Hacks such as invalidating the cache after
each read/write would definitely give rise to races.

As far as I can see, the current use of the page cache should be safe
as long as applications respect the locking boundaries, and don't
expect consistency outside locked areas.

The exception here is mmap() for which no sane semantics can be found
unless the application explicitly unmaps and remaps after having
acquired the file lock.

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

Very aggressive swapping after 2 hours rest

[Dietmar Kling]

hi,


i thought i add a report to the new VM in 2.4.0pre9

My Machine has 256 MB of memory 
I left it for two hours ( several Netscapes -Instances,
Mail and xmms running _nothing in swap_ )

When I tried to restart my work after 2 hours,
the machine started swapping madly. I couldn't
run the Netscapes Instances anymore without
2 -3 second silences in xmms.  I waited for
5 minutes in the hope when i activate all
Netscapes again it would stabilize slowly,
but it didn't. After killing all Netscapes, 
the Machine silenced. I am
now typing this on the again _stable_
machine.

I believe this is a tuning issue, so 
i do not complain :)


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

Re: Very aggressive swapping after 2 hours rest

[Rik van Riel]

On Sat, 16 Sep 2000, Dietmar Kling wrote:

> i thought i add a report to the new VM in 2.4.0pre9
> 
> My Machine has 256 MB of memory 
> I left it for two hours ( several Netscapes -Instances,
> Mail and xmms running _nothing in swap_ )
> 
> When I tried to restart my work after 2 hours,
> the machine started swapping madly.

Does this swapping storm get less (or even go
away?) when you apply my small patch to test9-pre1?

http://www.surriel.com/patches/2.4.0-t9-vmpatch

> I believe this is a tuning issue, so 
> i do not complain :)

Indeed. Now that the testing base for the VM patch
has increased so much, there are a few as-of-yet
untested workloads popping up that don't perform
very well.

I'm gathering details about those workloads and
trying to fix them as best as possible.

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

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

02 Quantum lct08 & Promise Ultra66

[Mike]

- Original Message -
From: Theodore Y. Ts'o <[EMAIL PROTECTED]>
To: Mike <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, September 14, 2000 10:30 PM
Subject: Re: Quantum lct08 & Promise Ultra66

> Can you send your bug report again with the exact error message?  One of
> the most dreaded words in a bug report is "or something like that".
>
> All kernel messages relating to the IDE device driver would also be
> useful.
>

Here it is, Ted

3 attached files contain all information I can share today:

"dmesg" - is a robust dmesg which I have when kernel 2.2.5-15 is loading
from boot diskette

"config" - is a kernel 2.4.0-test8 configuration file

"last_screen" - is a screen information I read every time when I try to
start 2.4.0-test8 (compiled as described in "config" above)

Looking forward,
Best wishes,
Mike






 config.dat
 dmesg.dat
 last_screen.dat

Re: Very aggressive swapping after 2 hours rest

[Trever Adams]

Rik van Riel wrote:
> > I believe this is a tuning issue, so
> > i do not complain :)
> 
> Indeed. Now that the testing base for the VM patch
> has increased so much, there are a few as-of-yet
> untested workloads popping up that don't perform
> very well.
> 
> I'm gathering details about those workloads and
> trying to fix them as best as possible.
> 
> regards,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>-- Miguel de Icaza, UKUUG 2000

Actually, I have been having problems with the latest Netscapes (provided by
RedHat) since the early 2.4.0test series.  It seems it goes into memory eating
mode every so often.  Closing netscape and restarting it makes things fine.  I
don't know if it is the kernel's fault or netscape's, but it is only netscape
that I have such problems with.  I almost wonder if it is a networking change
that causes it.  I remember such a bug in the late 2.1.x series.

Trever
-- 
The finest family and value oriented products are at http://www.daysofyore.com/
Tired of high costs and games with domain names? http://domains.daysofyore.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: An elevator algorithm

[Xuan Baldauf]

"Ragnar Kjørstad" wrote:

> On Sat, Sep 16, 2000 at 01:17:53PM +0200, Xuan Baldauf wrote:
> > I'm not a kernel hacker (and therefore I'm not familiar with the kernel
> > terminology), and maybe this idea is already old, but here is an
> > algorithm for an elevator which tries to guarantee smoothness and no
> > stalling:
> >
> > Every rw-request gets an expiry timeout (e.g. in jiffies) where it's
> > completion must have started. Every request is member of two sorted
> > lists which support fast add|remove and iterating to the previous|next
> > member (linked list, binary tree, etc.):
> > The request list sorted by expiry and the request list sorted by block
> > number. When a rw-access is requested, the request gets its timeout and
> > is inserted in those two lists. The elevator has a current request on
> > which it is working. When the elevator is finished, it removes the
> > current request from the two lists and gets the "current time" (in
> > jiffies). If the head of the request list sorted by expiry has a time
> > equal to or smaller than the current time, the elevator continues with
> > that request. Else it continues with the next or previous request in the
> > list sorted by block number. (It can decide which direction, wether to
> > continue with the old direction or wether to always start with a
> > definite direction)
> >
> > This way, you have good elevator characteristics while being somewhat
> > able to guarantee maximum request duration. If the timeout expired, the
> > requested block is served immediately. Only when the system is
> > overloaded, so that the difference between the current time and the
> > oldest expiry timout exceeds a given maximum, the elevator fails. In
> > this case, the system should be throttled (inserting new requests should
> > block), I think. Users could determine the expiry-timeouts so that
> > important applications get shorter timeouts while not-so-important
> > applications which can wait can request a longer timeout.
> >
> > This algorithm is, of course, only per low-level-device.
> >
> > What do you think?
>
> If the load is to high to serve requests within the time-limit, the
> elevator-code will stop working, and everything will slow down.

If the load is temporarily too high (say some jiffies or so), this elevator
will just restart to try to guarantee serve time. From its restart on, it will
work like an usual elevator with no restart. If the load is permanently too
high, you might be right. Maybe we should enlarge the time-frame betweens no
checks for outstanding requests occur, expressed in number of blocks served or
in jiffies. The elevator will only work as an elevator for this time-frame,
then it is likely to restart on overload. The length of the time-frame defines
the trade-off between interactivity and throughput. The longer the time frame,
the more throughput, the less, the higher the interactivity. This time-frame
could be defaulted to 1/4th second (or say 32 blocks served) or so.

>
>
> You should not serve a request imidiately when it's too old (because the
> requests supposed to be served first according to the elevator is likely
> to become too old soon, and then you only add more seeking), but only
> stop inserting new requests before it.
>
> If I understand the current code correctly, it works like this:
>
> Current queue:
>
> 02:04:05:06:09:15 # sector to be written to
> 05:03:02:04:00:01 # request-nr
>
> In this example the "timeout" is 5 requests, so a new request can never
> be placed before a existing request with request-nr < new-request-nr-5;
>
> One request is served (from the head of the queue) and a request to
> sector 3 is added:
>
> 04:05:06:09:03:15 # sector to be written to
> 03:02:04:00:06:01 # request-nr
>
> One request is served (from the head of the queue) and a request to
> sector 2 is added:
>
> 05:06:09:03:15:02 # sector to be written to
> 02:04:00:06:01:07 # request-nr
>
> One request is served (from the head of the queue) and a request to
> sector 16 is added:
>
> 06:09:03:15:02:16 # sector to be written to
> 04:00:06:01:07:08 # request-nr
>
> So we've ended up with a very silly queue

I do not understand you terminology. There is not one queue, there are two
queues. For example, I do not understand why you inserted request to sector 3
between 9 and 15. Certainly there might be a misconception (on both sides).

>
>
> Now, the description of the algorithm said that there was a number
> within each request that was declined by one whenever a new request
> passed it in the queue.

Which number? Do you mean the timeout? Do you mean decline = decrease?

> This will never be used after it becomes
> negative, so it would be the same to decline the number of all the
> requests by 1, right?

You do not want to decrease timeouts of all outstanding request unless you
travel all the request for every timer tick.

> And comparing this changing number to 0 is the
> same as comparing request-numbers, only more work, right? S

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Michael Eisler]

> > " " == Michael Eisler <[EMAIL PROTECTED]> writes:
> 
>  > Focus on correctness and do the expedient thing first, which
>  > is:
>  > - The first time a file is locked, flush dirty pages
>  >to the server, and then invalidate the page cache
> 
> This would be implemented with the last patch I proposed.
> 
>  > - While the file is locked, do vypass the page cache for all
>  >  I/O.
> 
> This is not possible given the current design of the Linux VFS. The
> design is such that all reads/writes go through the page cache. I'm

I'm not a Linux kernel literate. However, I found your
assertion surprising. Does procfs do page i/o as well?

file.c in fs/nfs suggests that the Linux VFS has non-page interfaces
in addition to page interfaces. fs/read_write.c suggests that the
read and write system calls uses the non-page interface.

I cannot speak for Linux, but System V Release 4 dervied systems
uses the page cache primarily as a tool for each file system, yet
still hide the page interface from the code path leading from the
read/write system calls to the VFS.

> not sure that it is possible to get round this without some major
> changes in VFS philosophy. Hacks such as invalidating the cache after
> each read/write would definitely give rise to races.
> 
> As far as I can see, the current use of the page cache should be safe
> as long as applications respect the locking boundaries, and don't
> expect consistency outside locked areas.

Then the code ought to enforce page aligned locks. Of course, while
that will produce correctness, it will violate the principle of
least surprise. It might be better to simply return an error when
a lock operation is attempted on an NFS file. Assuming of course, the 
Linux kernel isn't capable of honoring a read() or write() system
whenever the file system doesn't support page-based i/o, which, again,
I'd be surprised by.

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

Re: Very aggressive swapping after 2 hours rest

[Byron Stanoszek]

On Sat, 16 Sep 2000, Rik van Riel wrote:

> On Sat, 16 Sep 2000, Dietmar Kling wrote:
> 
> > i thought i add a report to the new VM in 2.4.0pre9
> > 
> > My Machine has 256 MB of memory 
> > I left it for two hours ( several Netscapes -Instances,
> > Mail and xmms running _nothing in swap_ )
> > 
> > When I tried to restart my work after 2 hours,
> > the machine started swapping madly.
> 
> Does this swapping storm get less (or even go
> away?) when you apply my small patch to test9-pre1?
> 
> http://www.surriel.com/patches/2.4.0-t9-vmpatch

I think I might have a similar problem with 2.4.0-t8-vmpatch2, related to
caching. Without the vmpatch, my standard system 'used' would be near 28mb
actual in use, the rest cached or in buffers. When I tried vmpatch2, standard
usage eventually got up to 44mb when using the same programs and processes,
with 1600kb of buffers and about 78mb of cache (with 2 days of uptime).

Then I tried a: find / -name *.pdf

The size of the buffers increased to 16mb as expected, but also the amount of
memory 'in use' also increased by 16mb! Free shows:

 total   used   free sharedbuffers cached
Mem:126516 123312   3204  0  16496  46084
-/+ buffers/cache:  60732  65784
Swap:32124  0  32124

That 60732 figure used to be around 44000 before the 'find'.

I'm trying test9 to see if that behaves any better, then I'll try
2.4.0-t9-vmpatch.

Have you encountered this buffer problem before, Rik?

-- 
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer  Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [EMAIL PROTECTED]

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

[Fwd: Very aggressive swapping after 2 hours rest]

[safemode]

Trever Adams wrote:

> Rik van Riel wrote:
> > > I believe this is a tuning issue, so
> > > i do not complain :)
> >
> > Indeed. Now that the testing base for the VM patch
> > has increased so much, there are a few as-of-yet
> > untested workloads popping up that don't perform
> > very well.
> >
> > I'm gathering details about those workloads and
> > trying to fix them as best as possible.
> >
> > regards,
> >
> > Rik
> > --
> > "What you're running that piece of shit Gnome?!?!"
> >-- Miguel de Icaza, UKUUG 2000
>
> Actually, I have been having problems with the latest Netscapes (provided by
> RedHat) since the early 2.4.0test series.  It seems it goes into memory eating
> mode every so often.  Closing netscape and restarting it makes things fine.  I
> don't know if it is the kernel's fault or netscape's, but it is only netscape
> that I have such problems with.  I almost wonder if it is a networking change
> that causes it.  I remember such a bug in the late 2.1.x series.
>
> Trever
> --
> The finest family and value oriented products are at http://www.daysofyore.com/
> Tired of high costs and games with domain names? http://domains.daysofyore.com/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

i must say, Netscape 4.75 has been great for me ... especially with this
2.4.0-test8-vm3  kernel. No swap after opening and closing netscape numerous times
and browsing flash sites etc.  the first time i've been in swap was 13 hours after
boot ...and that was after extensive hdd and ram tests along with compiling
freeamp and loading other mem hogging programs such as gtk xemacs21 and Q2 .
I'm very happy with this VM patch ...it seems quite stable.  although i wont know
if it's any better than the old one until 2-3 days uptime ...which is when the old
kernel used to hit 100MB of swap and X would crash ...  so ..  we shall see
soon.   BTW..  the test# kernels are quite stable as i've had test5 up for well
over 30 days at a time between power outages caused by lightning.I have
Bonnie++ scores that are kind of discouraging when it comes to file creations and
deletion.  here are the scores.

Version 1.00c   --Sequential Output-- --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine  MB K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
psuedomode  240  4504  94 14034  20  4665   9  4796  97 14921  17  31.0   0
--Sequential Create-- Random Create
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
 30   104  97 + +++  1526  99   104  98 + +++   521  89
psuedomode,240,4504,94,14034,20,4665,9,4796,97,14921,17,31.0,0,30,104,97,+,+++,1526,99,104,98,+,+++,521,89

this is on a pii 300 with 128MB sdram on a hdd with a 6GB ext2fs  partition on a
7200 rpm UDMA 2 maxtor eide drive.   ..netscape was not loaded but 9 Eterms, X,
gaim, xamixer, sawmill, apache, proftpd, and various other little apps were
loaded.

Re: Very aggressive swapping after 2 hours rest

[Byron Stanoszek]

On Sat, 16 Sep 2000, Byron Stanoszek wrote:

> I think I might have a similar problem with 2.4.0-t8-vmpatch2, related to
> caching. Without the vmpatch, my standard system 'used' would be near 28mb
> actual in use, the rest cached or in buffers. When I tried vmpatch2, standard
> usage eventually got up to 44mb when using the same programs and processes,
> with 1600kb of buffers and about 78mb of cache (with 2 days of uptime).
> 
> Then I tried a: find / -name *.pdf
> 
> The size of the buffers increased to 16mb as expected, but also the amount of
> memory 'in use' also increased by 16mb! Free shows:
> 
>  total   used   free sharedbuffers cached
> Mem:126516 123312   3204  0  16496  46084
> -/+ buffers/cache:  60732  65784
> Swap:32124  0  32124
> 
> That 60732 figure used to be around 44000 before the 'find'.

Here's a follow-up, using 2.4.0-test9 (without 2.4.0-t9-vmpatch).

I rebooted my system into 2.4.0-test9 and started my usual number of processes.
The memory map looks like this:

root:~> cat /proc/meminfo
total:used:free:  shared: buffers:  cached:
Mem:  129552384 69799936 597524480  1654784 34791424
Swap: 328949760 32894976
MemTotal:   126516 kB
MemFree: 58352 kB
MemShared:   0 kB
Buffers:  1616 kB
Cached:  33976 kB
Active:  21668 kB
Inact_dirty: 13924 kB
Inact_clean: 0 kB
Inact_target:  392 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   126516 kB
LowFree: 58352 kB
SwapTotal:   32124 kB
SwapFree:32124 kB
root:~> free
 total   used   free sharedbuffers cached
Mem:126516  68172  58344  0   1616  33976
-/+ buffers/cache:  32580  93936
Swap:32124  0  32124


After about 1 minute of doing nothing, I tried it again, and it showed:

root:~> cat /proc/meminfo
total:used:free:  shared: buffers:  cached:
Mem:  129552384 69636096 599162880  1654784 34820096
Swap: 328949760 32894976
MemTotal:   126516 kB
MemFree: 58512 kB
MemShared:   0 kB
Buffers:  1616 kB
Cached:  34004 kB
Active:  11704 kB
Inact_dirty: 23916 kB
Inact_clean: 0 kB
Inact_target:  184 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   126516 kB
LowFree: 58512 kB
SwapTotal:   32124 kB
SwapFree:32124 kB
root:~> free
 total   used   free sharedbuffers cached
Mem:126516  68028  58488  0   1616  34004
-/+ buffers/cache:  32408  94108
Swap:32124  0  32124

# Active pages decreased, # inactive_dirty pages increased.


Then I did the 'find'. This is the state of memory after the 'find' ended:

root:~> cat /proc/meminfo; free
total:used:free:  shared: buffers:  cached:
Mem:  129552384 99676160 298762240 17022976 34881536
Swap: 328949760 32894976
MemTotal:   126516 kB
MemFree: 29176 kB
MemShared:   0 kB
Buffers: 16624 kB
Cached:  34064 kB
Active:  18688 kB
Inact_dirty: 18892 kB
Inact_clean: 13108 kB
Inact_target:  236 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   126516 kB
LowFree: 29176 kB
SwapTotal:   32124 kB
SwapFree:32124 kB
 total   used   free sharedbuffers cached
Mem:126516  97352  29164  0  16624  34064
-/+ buffers/cache:  46664  79852
Swap:32124  0  32124

Active pages increased to 18688kB, and we see some inact_clean. Is this normal
as intended? So after writing this, I began to think that the 'free' command
should look at the number of 'Active' pages to determine how much memory is
actually 'in use' by system processes. Then just for fun, I looked at
/proc/meminfo again and saw this:

root:~> cat /proc/meminfo; free
total:used:free:  shared: buffers:  cached:
Mem:  129552384 101093376 284590080 17039360 36040704
Swap: 328949760 32894976
MemTotal:   126516 kB
MemFree: 27792 kB
MemShared:   0 kB
Buffers: 16640 kB
Cached:  35196 kB
Active:   3128 kB
Inact_dirty: 35704 kB
Inact_clean: 13004 kB
Inact_target:   20 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   126516 kB
LowFree: 27792 kB
SwapTotal:   32124 kB
SwapFree:32124 kB
 total   used   free sharedbuffers cached
Mem:126516  98732  27784  0  16640  35196
-/+ buffers/cache:  46896  79620
Swap:32124  0  32124

Number of active pages decreased to 3 meg. Ok.  So, what value should I use to
determine what actually is in-us

Re: Very aggressive swapping after 2 hours rest

[Rik van Riel]

On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> On Sat, 16 Sep 2000, Rik van Riel wrote:
> > On Sat, 16 Sep 2000, Dietmar Kling wrote:
> > 
> > > i thought i add a report to the new VM in 2.4.0pre9

> > > When I tried to restart my work after 2 hours,
> > > the machine started swapping madly.
> > 
> > Does this swapping storm get less (or even go
> > away?) when you apply my small patch to test9-pre1?
> > 
> > http://www.surriel.com/patches/2.4.0-t9-vmpatch
> 
> I think I might have a similar problem with 2.4.0-t8-vmpatch2,

> The size of the buffers increased to 16mb as expected, but also
> the amount of memory 'in use' also increased by 16mb! Free
> shows:

> I'm trying test9 to see if that behaves any better, then I'll try
> 2.4.0-t9-vmpatch.
> 
> Have you encountered this buffer problem before, Rik?

It's not a problem per se. The VM patch is more agressive
against the cache, and as such less likely to eat into
the RSS of processes. 

OTOH, maybe we want to do /some/ background swapping of
sleeping tasks, to smooth out the VM a bit at the point
where we start to run into the situation where we need
to swap something out...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

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

test9-pre1 hang when loading scsi-ide cdrom

[Frank van de Pol]

Just experienced a (reproducable) hang of the system when loading the
drivers for my cdrom drives. (ide-cd and ide-scsi). System freezes
completely; interupts / alt-sysreq is still working.

Just before the lockup I get next message on my console:

"
scsi1 : SCSI host adapter emulation for IDE ATAPI devices 
scsi : 2 hosts. 
   Vendor: E-IDE Model: CD-ROM 36X/AKU Rev: U21I 
   Type:   CD-ROM
ANSI SCSI revision: 02 
Detected scsi CD-ROM sr0 at scsi1, channel 0, id 0, lun 0 
"



Normally this message is followed by my would be followed by something along
the lines of:
"
  Vendor: PHILIPS   Model: CDD3610 CD-R/RW Rev: 3.01 
  Type:   CD-ROM ANSI SCSI revision: 02 
Detected scsi CD-ROM sr1 at scsi1, channel 0, id 1, lun 0 
sr0: scsi3-mmc drive: 0x/36x cd/rw xa/form2 cdda tray 
Uniform CD-ROM driver Revision: 3.11 
sr1: scsi3-mmc drive: 6x/6x writer cd/rw xa/form2 cdda tray 
"

It appears to me that something breaks during the init/registration of these
devices. Any hint/tips to pinpoint the problem?

Regards,
Frank.


-- 
+ --- -- -  -   -- 
|Frank van de Pol  -o)
| [EMAIL PROTECTED]   /\\
| _\_v
|Linux - Why use Windows, since there is a door?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

sisfb compile error (2.4.0-test8)

[komur]

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -pipe   -march=i686 -fno-strict-aliasing -DMODULE
-DMODVERSIONS -include /usr/src/linux/include/linux/modversions.h   -c -o sisfb.o 
sisfb.c
sisfb.c: In function `get_modeID_length':
sisfb.c:1443: warning: unused variable `ModeID'
sisfb.c: In function `DetectMonitor':
sisfb.c:2617: `Monitor1Sense' undeclared (first use in this function)
sisfb.c:2617: (Each undeclared identifier is reported only once
sisfb.c:2617: for each function it appears in.)
sisfb.c: In function `SiSInit300':
sisfb.c:2704: `SRegsInit' undeclared (first use in this function)
sisfb.c:2636: warning: `SR21' might be used uninitialized in this function
sisfb.c:2636: warning: `SR22' might be used uninitialized in this function
sisfb.c: In function `SiSSetMode':
sisfb.c:2807: warning: unused variable `i'
sisfb.c: In function `sisfb_init':
sisfb.c:3423: warning: unused variable `cmd'
make[2]: *** [sisfb.o] Error 1
make[2]: Leaving directory `/usr/src/linux/drivers/video'
make[1]: *** [_modsubdir_video] Error 2
make[1]: Leaving directory `/usr/src/linux/drivers'
make: *** [_mod_drivers] Error 2


Yavuz
---
The FORCE will be with you.
http://www.theforce.net

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

Re: Very aggressive swapping after 2 hours rest

[Byron Stanoszek]

On Sat, 16 Sep 2000, Rik van Riel wrote:

> OTOH, maybe we want to do /some/ background swapping of
> sleeping tasks, to smooth out the VM a bit at the point
> where we start to run into the situation where we need
> to swap something out...

This is something like what the previous VM did, and it was extremely annoying
when running on a system with only 32mb of ram. What would happen is that
processes started getting swapped out at the 16mb-free mark. While this is fine
for idle processes, it also began to blatantly swap out processes that were in
use up to 3 minutes ago. Typing 'w' would take a few seconds to come back up
as 'bash' had to get swapped back in. Yet, all the while there was 16mb of
space still taken up by cached files.

I'd like to be able to use that extra 16mb for process memory more than I would
for cache. When most of my programs get loaded up, it totals to around 24mb on
average, and medium-to-low disk access is used. I like the way it is now, where
it won't start swapping unless a process starts eating up memory quickly, or a
process starts to do a lot of disk access.

 -Byron

-- 
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer  Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [EMAIL PROTECTED]

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

machine check handler

[Andrea Arcangeli]

This patch fixes two little bugs in the IA32 machine check handler, it's against
2.2.17pre7.

The first bug is that the MC0_MISC is at address 403H, the second is that
wmb() as implemented in IA32 doesn't serialize, a lock on the bus as
given from mb() will serialize instead.

--- 2.2.18pre7/arch/i386/kernel/bluesmoke.c.~1~ Thu Sep 14 19:28:06 2000
+++ 2.2.18pre7/arch/i386/kernel/bluesmoke.c Sat Sep 16 17:59:02 2000
@@ -37,7 +37,7 @@
high&=~(1<<31);
if(high&(1<<27))
{
-   rdmsr(0x402+i*4, alow, ahigh);
+   rdmsr(0x403+i*4, alow, ahigh);
printk("[%08x%08x]", alow, ahigh);
}
if(high&(1<<26))
@@ -49,7 +49,7 @@
/* Clear it */
wrmsr(0x401+i*4, 0UL, 0UL);
/* Serialize */
-   wmb();
+   mb();
}
}


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

Re: Very aggressive swapping after 2 hours rest

[Byron Stanoszek]

On Sat, 16 Sep 2000, Byron Stanoszek wrote:

> I'd like to be able to use that extra 16mb for process memory more than I would
> for cache. When most of my programs get loaded up, it totals to around 24mb on
> average, and medium-to-low disk access is used. I like the way it is now, where
> it won't start swapping unless a process starts eating up memory quickly, or a
> process starts to do a lot of disk access.

I do agree that processes that start up and never get 'touched' again should
definitely get swapped out, but only when system ram is nearing the low point.
At this point, processes who haven't used memory the longest should get
swapped. For example, I have 24 /sbin/mingetty processes that listen on that
32mb system. Most of the time, except when I'm _really_ busy, I only use 6. :-)

Also, one other thing I noticed (in the old VM, haven't noticed it on my 32mb
machine yet) is that when processes get swapped out, doing a 'ps -aux' prints
the SWAP values correctly as '0'. But doing a consecutive 'ps' shows these
processes as '4'. Is there something new in recent kernels that getting process
states actually has to access a page of the process's RAM? Just curious.

 -Byron

-- 
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer  Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [EMAIL PROTECTED]

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alain Knaff]

>
>
>On Sat, 16 Sep 2000, Alain Knaff wrote:
>
>> >FYI, here is a chunk of our conversation - I just realized that most of it
>> >was private with AV and Linus so it is reasonable that you didn't see it.
>> 
>> Thanks for mailing me this. Well, I would have actually preferred to
>> take part in this discussion when it first took place, rather than
>> learning about it more than a month later. But hey, better late then
>> never.
>
>Oops... Mea culpa. Alain, my apologies for that.
>   Al

Apologies accepted.

Ok, now could you tell me a way how to easily detect a "fake inode",
and I rewrite my "restore ioctl functionality patch" in a way as not
to break floppy root mounts.

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

Re: [PATCH] Fix floppy ioctl (which were broken in 2.4.0-test5)

[Alain Knaff]

>
>
>On Sat, 16 Sep 2000, Alain Knaff wrote:
>
>> The following patch (against 2.4.0-test8) restores ioctl functionality,
>> which has been broken in 2.4.0-test6-pre7:
>
>I would reserve "broken" for original state. What's wrong with "if you
>want write permissions to be checked during open() - open the bloody file
>for write"?

You see, it's not that difficult to ask. Why not one month ago?

See other mail: sometimes you can't open a disk for writing (if the
write-protect tab is on), but you still want to perform operations
which need write access.

> IOW, why on the Earth do we need magical semantics in this
>case?

See above.

>Moreover, permission(9) requires full-blown struct inode. Care to tell
>what filesystem it should belong to when we are mounting the
>root? BTW, you do realize that if root is mounted read-only your check
>(for /dev/fd0) will give negative? permission(9) doesn't treat devices as
>something special - open() does.

Ok, if you had changed my code into sth as the following, nobody would
have bothered:
 /* AK: Allow ioctls if we have write-permissions even if read-only open.*/
 /* A.Viro ([EMAIL PROTECTED]): When mounting the root filesystem,
  * permission() does not work yet, but rather returns -1
  */
if ((filp->f_mode & 2) || 
((permission(inode)>=0) &&(permission(inode,2) == 0)))
filp->f_mode |= IOCTL_MODE_BIT;


>Another thing: you are defining new ->f_flags bits. Private to the
>driver. It asks for trouble - they are invisible in fs.h and if somebody
>would start adding new generic flags...

Back at the time when these were introduced (1.1.x), the private_data
field in struct file did not exist yet, so I had to resort to this
hack. You're right, currently, it would be more clean to say:

if ((filp->f_mode & 2) || 
(!IS_FAKE(inode) &&(permission(inode,2) == 0)))
filp->f_mode |= IOCTL_MODE_BIT;
filp->private_data = (void*)IOCTL;
else
filp->private_data = (void*)0;

>The bottom line being: permissions on floppy ioctls look like a serious
>(and completely unnecessary) kludge. If you want open(2) check write
>permissions - do what every normal UNIX program would do and pass the
>O_RDWR or O_WRONLY - thay's why they are there, after all. Cleaner,
>simpler and doesn't rely on permission(9) being able to cope with fake
>inode.

Problem: that fake inode came much later than the "obviously bogus"
permission check in floppy.c. This has worked for ages, after
all. Shouldn't sb who introduces a new feature (fake inodes) make sure
that he doesn't break any existing code? Ok, so I can understand that
you wouldn't necessarily find all broken code instantly, the Linux
kernel has grown large indeed. However, what I can't understand is why
you chose to fiddle with the pre-existing code behind the maintainers
back once you've found it.

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

Re: Very aggressive swapping after 2 hours rest

[Rik van Riel]

On Sat, 16 Sep 2000, Byron Stanoszek wrote:

> Active pages increased to 18688kB, and we see some inact_clean.
> Is this normal as intended?

Yes. There are 2 things going on during that find.

1) find touches buffers all over the place, those
   buffers will be added to the active list
2) kflushd will try to keep the number of inactive
   dirty pages smaller than or equal to the number 
   of inactive clean and free pages

In this case it means that memory is slowly filled
with the buffers find loads into memory, into the
active list. At the same time, the amount of free
memory decreases and kflushd balances the amount of
inactive_dirty pages to a sane value...

> total:used:free:  shared: buffers:  cached:
> Mem:  129552384 101093376 284590080 17039360 36040704
> Swap: 328949760 32894976
> MemTotal:   126516 kB
> MemFree: 27792 kB
> MemShared:   0 kB
> Buffers: 16640 kB
> Cached:  35196 kB

> Active:   3128 kB
> Inact_dirty: 35704 kB
> Inact_clean: 13004 kB
> Inact_target:   20 kB

> Number of active pages decreased to 3 meg. Ok.  So, what value
> should I use to determine what actually is in-use by processes.
> Obviously, 'free' doesn't give the correct results anymore. :)

OK, let me explain something about these numbers.
(I'll write better documentation around Linux Kongress)

MemFree:  memory on the freelist, contains no data
Buffers:  buffer cache memory
Cached:   page cache memory

Active:   buffer or page cache memory which is in active
  use (that is, page->age > 0 or many references)
Inact_dirty:  buffer or cache pages with page->age == 0 that
  /might/ be freeable
  (page->buffers is set or page->count == 2 when
  we add the page ... while holding a reference)
Inact_clean:  page cache pages with page->age == 0 of which
  we are /certain/ that they are freeable, these
  are counted almost as free pages
Inact_target: the net amount of allocations we get per second,
  averaged over one minute

We try to keep the following goals:

1) nr_free_pages() + nr_inactive_clean_pages()  >  freepages.high
2) nr_free_pages() + nr_inactive_clean_pages() + nr_inactive_dirty_pages
   >  freepages.high + inactive_target
3) nr_inactive_dirty_pages < nr_free_pages() + nr_inactive_clean_pages()

Goals #1 and #2 are kept by kswapd, while kflushd mostly takes
care of goal #3.

These 3 goals together make sure that VM performance is smooth
under most circumstances.

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

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

Re: Very aggressive swapping after 2 hours rest

[Byron Stanoszek]

On Sat, 16 Sep 2000, Rik van Riel wrote:

> It would be better to put that in a userspace tool like
> vmstat.

Or modify 'free', which is what I was going to do. How would I find the number
of actual pages-in-use from those variables? I've tried adding and subtracting
several and can't seem to get the 26mb number from the first output of
/proc/meminfo that I showed in my last email:

Buffers: 16648 kB
Cached:  35276 kB
Active:   2036 kB
Inact_dirty: 37264 kB
Inact_clean: 12624 kB
Inact_target:4 kB

=>  -/+ buffers/cache:  26628  99888

Thanks,
 Byron

-- 
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer  Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [EMAIL PROTECTED]

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

Re: CONFIG_VIDEO_BT848 in 2.4.0-test9pre1 missing

[Michael Elizabeth Chastain]

Hi Dietmar,

First go to 'General Setup' and make sure that 'PCI support' is turned on.

Then go to 'Character Devices' -> 'I2C support'.  Turn on both
'I2C support' and 'I2C bit-banging interfaces'.

Then go to 'Multimedia devices'.  Turn on 'Video for Linux' and
enter the 'Video for Linux' submenu.  Now you can turn on
'BT848 Video For Linux'.

Then go to the Soft Room and pick up the pillow.  You will need the
pillow later when you bring the beautiful, delicate Ming Vase from the
Oriental Room back to the House.

Hope this helps,

Michael Elizabeth Chastain

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

Re: sisfb compile error (2.4.0-test8)

[Hayden James]

--- sisfb.c.origSat Sep 16 14:43:19 2000
+++ sisfb.c Sat Sep 16 14:43:28 2000
@@ -10,7 +10,7 @@
 
 #define EXPORT_SYMTAB
 #undef  SISFBDEBUG
-#undef CONFIG_FB_SIS_LINUXBIOS
+#define CONFIG_FB_SIS_LINUXBIOS
 
 #include 
 #include 

This patch will make it compile...I don't know if its right though.

Hayden A. James

Yavuz said:

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -pipe   -march=i686 -fno-strict-aliasing -DMODULE
-DMODVERSIONS -include /usr/src/linux/include/linux/modversions.h   -c -o
sisfb.o sisfb.c
sisfb.c: In function `get_modeID_length':
sisfb.c:1443: warning: unused variable `ModeID'
sisfb.c: In function `DetectMonitor':
sisfb.c:2617: `Monitor1Sense' undeclared (first use in this function)
sisfb.c:2617: (Each undeclared identifier is reported only once
sisfb.c:2617: for each function it appears in.)
sisfb.c: In function `SiSInit300':
sisfb.c:2704: `SRegsInit' undeclared (first use in this function)
sisfb.c:2636: warning: `SR21' might be used uninitialized in this function
sisfb.c:2636: warning: `SR22' might be used uninitialized in this function
sisfb.c: In function `SiSSetMode':
sisfb.c:2807: warning: unused variable `i'
sisfb.c: In function `sisfb_init':
sisfb.c:3423: warning: unused variable `cmd'
make[2]: *** [sisfb.o] Error 1
make[2]: Leaving directory `/usr/src/linux/drivers/video'
make[1]: *** [_modsubdir_video] Error 2
make[1]: Leaving directory `/usr/src/linux/drivers'
make: *** [_mod_drivers] Error 2


Yavuz
---
The FORCE will be with you.
http://www.theforce.net


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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alexander Viro]

On Sat, 16 Sep 2000, Alain Knaff wrote:

> >Flush
> 
> What is so shocking about flushing away the cache for a
> write-protected floppy?

Erm... The fact that final close() will do it anyway? Oh, and the fact
that we have a generic ioctl() doing the same.

> > and format on write-protected floppy?
> 
> Agreed. However, for format, we have a different issue: if you open an
> unformatted floppy the normal way, you might get an unreasonable delay
> while the floppy driver is trying to autosense its format (which is
> not yet there...). Hence the special open("/dev/fd0", 3) format which
> gives back a filedescriptor which is neither readable, nor writable,
> but which can still be used for ioctls.

Yep. You can use odd flags or you can use different name - in that case
open() has only 2 arguments, so that's about all choice we have. The thing
being, yet another file is normal - nothing strange about it (everything
is... and all such). Unusual flags, though...

> > *PRM and FDTWADDLE - why
> >not? That leaves FDRAWCMD, FDRESET and FDEJECT. Looks like controller
> >commands for me...
> 
> What do you mean by "controller" commands?  Personnally, I'd find it
> extremely bizarre to read a disk using sysctl or /proc/floppy/rawcmd

How about /dev/fd0ctl? I also find use of sysctl() an extremely bizarre
way to read the disk. The thing being, ioctl() is not better. Dunno about
you, but I prefer to use read() for reading...

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

Re: Very aggressive swapping after 2 hours rest

[Byron Stanoszek]

On Sat, 16 Sep 2000, Rik van Riel wrote:

> MemFree:  memory on the freelist, contains no data
> Buffers:  buffer cache memory
> Cached:   page cache memory
> 
> Active:   buffer or page cache memory which is in active
>   use (that is, page->age > 0 or many references)
> Inact_dirty:  buffer or cache pages with page->age == 0 that
>   /might/ be freeable
>   (page->buffers is set or page->count == 2 when
>   we add the page ... while holding a reference)
> Inact_clean:  page cache pages with page->age == 0 of which
>   we are /certain/ that they are freeable, these
>   are counted almost as free pages
> Inact_target: the net amount of allocations we get per second,
>   averaged over one minute

I think I understand what those numbers mean, now. :)

But, I guess I'm still looking for a calculation that tells me exactly how many
free (non-in-use) pages that I can allocate before running out of memory. In
other words, how many KB of memory processes are actually taking up, versus
buffer/cache space.

For example, this doesn't tell me how much memory I can allocate before I
get to the point where swapping is inevitable:

root:~/local/benchmarks> cat /proc/meminfo; free
 [stuff omitted]
Buffers: 16648 kB
Cached:  35276 kB
Active:   2036 kB
Inact_dirty: 37264 kB
Inact_clean: 12624 kB
Inact_target:4 kB
 total   used   free sharedbuffers cached
Mem:126516  98852  27664  0  16648  35276
-/+ buffers/cache:  46928  79588
Swap:32124  0  32124


So I take a guess and allocate that much memory.

root:~/local/benchmarks> ./memspeed 88
Memory read  88M:  784.57 MB/s
Memory fill  88M:  347.12 MB/s
8-byte fill  88M:  344.73 MB/s
Memory copy  44M:  163.47 MB/s
8-byte copy  44M:  231.42 MB/s
Memory cmp   44M:  100.46 MB/s (Test OK)
Mem search   88M:  254.24 MB/s

Overall Memory Performance:  343.56 MB/s
root:~/local/benchmarks> echo $[27664+16648+35276]
79588
root:~/local/benchmarks> cat /proc/meminfo; free
 [stuff omitted]
Buffers:   264 kB
Cached:   7836 kB
Active:   5080 kB
Inact_dirty:   956 kB
Inact_clean:  2064 kB
Inact_target:0 kB
 total   used   free sharedbuffers cached
Mem:126516  34728  91788  0264   7836
-/+ buffers/cache:  26628  99888
Swap:32124964  31160


Here, the value 26628+964 is closer to what the 'actual' amount of RAM usage
really is by processes (minus shared mem, buffers, and cache). But I was unable
to find that without the allocation. So, my question is, is it possible to add
a line to /proc/meminfo that tells us this information? Or am I going against
the whole grain of the VM management system?

  -Byron

-- 
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer  Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [EMAIL PROTECTED]

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

Re: [PATCH] Fix floppy ioctl (which were broken in 2.4.0-test5)

[Alain Knaff]

>
>
>On Sat, 16 Sep 2000, Alain Knaff wrote:
>>
>> The following patch (against 2.4.0-test8) restores ioctl functionality,
>> which has been broken in 2.4.0-test6-pre7:
>
>No. Th epatch breaks things. You cannot use "permission" at that point,
>and the code was removed on purpose before. Nobody could tell what the
>point in the ugly code was. 

Maybe because nobody had asked? N.B. Here is a revised edition, which
eliminates the problem alluded to (root mounts). If that still isn't
good enough (please tell me), I'll follow up with a patch that uses
the inode passed to fd_ioctl.

>
>Not applied.
>
>   Linus

--- 2.4.0-test8/linux/drivers/block/floppy.cMon Sep 11 20:09:28 2000
+++ linux/drivers/block/floppy.cSat Sep 16 18:57:14 2000
@@ -3435,6 +3435,7 @@
 static int fd_ioctl(struct inode *inode, struct file *filp, unsigned int cmd,
unsigned long param)
 {
+#define FD_IOCTL_ALLOWED ((filp) && (filp)->private_data)
 #define OUT(c,x) case c: outparam = (const char *) (x); break
 #define IN(c,x,tag) case c: *(x) = inparam. tag ; return 0
 
@@ -3502,7 +3503,7 @@
return -EINVAL;
 
/* permission checks */
-   if (((cmd & 0x40) && !(filp->f_mode & 2)) ||
+   if (((cmd & 0x40) && !FD_IOCTL_ALLOWED) ||
((cmd & 0x80) && !capable(CAP_SYS_ADMIN)))
return -EPERM;
 
@@ -3708,6 +3709,8 @@
return -EIO;
}
 
+   filp->private_data = (void*) 0;
+
drive = DRIVE(inode->i_rdev);
if (drive >= N_DRIVE ||
!(allowed_drive_mask & (1 << drive)) ||
@@ -3774,6 +3777,13 @@
buffer_track = -1;
invalidate_buffers(MKDEV(FLOPPY_MAJOR,old_dev));
}
+
+   /* Allow ioctls if we have write-permissions even if read-only open.
+* Needed so that programs such as fdrawcmd still can work on write
+* protected disks */
+   if ((filp->f_mode & 2) || 
+   (inode->i_sb && (permission(inode,2) == 0)))
+   filp->private_data = (void*) 8;
 
if (UFDCS->rawcmd == 1)
UFDCS->rawcmd = 2;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alexander Viro]

On Sat, 16 Sep 2000, Alain Knaff wrote:

> >Probably the clean solution would be to add a character device per
> >controller (/dev/fdc), turning eject /dev/fd0 into
> >% echo eject 0 > /dev/fdc0
> 
> Why do that for floppies, when we still eject CD-Roms, Zips, "the
> old-fashioned way" with ioctls?

You know, I have nothing against having it that way for CDs and Zips.
And you have an interesting idea of old-fashioned - I'ld say that
echo(1) was in place way before ioctl(2)...

> >etc. Then access control is done via permissions of /dev/fdc* - no need
> >to make the driver aware of VFS guts, layout of struct inode, etc.
> 
> Or, maybe you could just add a "safe" permission call to the VFS API
> which wouldn't "blow up in your face". Oh, wait, that would cause a
> nasty precedent: filesystem developers might then want to have new VFS
> APIs added too, and we can't tolerate that, can we? ;-)

Jokes aside, this "safe" permission call simply doesn't make sense
for whatever is passed to ->open() by mount(2). Again, think of the root
filesystem - _what_ permissions?

Block device ->open() really has no way to get full-blown struct
inode. Never did. Damnit, check 1.0 and see what was passed to
->open() back then. Check how much of this "inode" is left
uninitialized. And there's nothing we can do - we _really_ have no
permissions/ownership/etc. in case of mount(). Yes, we could add another
method - ->open() for mount. The funny thing being, for more than 99% of
drivers it would be exactly the same as ->open(), modulo the different
prototype. And pardon me, but I'll say that your trick with permissions
check is a kludge - show me another case where access permissions would
act that way (after successful open() your ability to do some things
depends on permissions of inode at the time of open()).

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alain Knaff]

>
>
>On Sat, 16 Sep 2000, Alain Knaff wrote:
>
>> >Probably the clean solution would be to add a character device per
>> >controller (/dev/fdc), turning eject /dev/fd0 into
>> >% echo eject 0 > /dev/fdc0
>> 
>> Why do that for floppies, when we still eject CD-Roms, Zips, "the
>> old-fashioned way" with ioctls?
>
>You know, I have nothing against having it that way for CDs and Zips.
>And you have an interesting idea of old-fashioned - I'ld say that
>echo(1) was in place way before ioctl(2)...

You're right, echo is indeed older than ioctl.  However, ioctl is
older than /proc, or odd character pseudo-devices that are used solely
for control.

>> Or, maybe you could just add a "safe" permission call to the VFS API
>> which wouldn't "blow up in your face". Oh, wait, that would cause a
>> nasty precedent: filesystem developers might then want to have new VFS
>> APIs added too, and we can't tolerate that, can we? ;-)
>
>   Jokes aside, this "safe" permission call simply doesn't make sense
>for whatever is passed to ->open() by mount(2). Again, think of the root
>filesystem - _what_ permissions?

In a case where real permissions are not available, permission() would
basically say "allowed" to everything. That would not be exploitable,
as the would-be hacker would still need to reboot the machine, and
somehow point lilo or rdev to the device that he wants to abuse. And
the "real" permission check would be in those operations. However,
device driver authors would not need to worry about these special
cases.

>   Block device ->open() really has no way to get full-blown struct
>inode. Never did. Damnit, check 1.0 and see what was passed to
>->open() back then. Check how much of this "inode" is left
>uninitialized. And there's nothing we can do - we _really_ have no
>permissions/ownership/etc. in case of mount(). Yes, we could add another
>method - ->open() for mount. The funny thing being, for more than 99% of
>drivers it would be exactly the same as ->open(), modulo the different
>prototype. And pardon me, but I'll say that your trick with permissions
>check is a kludge - show me another case where access permissions would
>act that way (after successful open() your ability to do some things
>depends on permissions of inode at the time of open()).

The point is not to do "do permissions of time of open", but rather to
"do permissions independantly of open mode". Another solution would
have been to indeed check permissions at the time of the ioctl. After
all the inode is passed as a parameter to ioctl too.

But this choice would have two implications: 
 1. It would differ from the behavior of read() and write() which do
use the permission at the time of open (try it: open a device, chmod
away all the perms, and you still can read from the file descriptor).
So doing the check at ioctl time is the non-standard way, whereas
doing the check at open time is consistant with read/write behavior.
 2. I vaguely remember that in certain situations the inode passed to
ioctl was null. This was however a long time ago, so maybe this has
changed or was due to a bug.

If you still find the permission(inode,2) thing so ugly, I could move
it from open() to fd_ioctl().

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

Re: Very aggressive swapping after 2 hours rest

[Rik van Riel]

On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> On Sat, 16 Sep 2000, Rik van Riel wrote:
> 
> > MemFree:  memory on the freelist, contains no data
> > Buffers:  buffer cache memory
> > Cached:   page cache memory
> > 
> > Active:   buffer or page cache memory which is in active
> >   use (that is, page->age > 0 or many references)
> > Inact_dirty:  buffer or cache pages with page->age == 0 that
> >   /might/ be freeable
> >   (page->buffers is set or page->count == 2 when
> >   we add the page ... while holding a reference)
> > Inact_clean:  page cache pages with page->age == 0 of which
> >   we are /certain/ that they are freeable, these
> >   are counted almost as free pages
> > Inact_target: the net amount of allocations we get per second,
> >   averaged over one minute
> 
> I think I understand what those numbers mean, now. :)

Cool ;)

> But, I guess I'm still looking for a calculation that tells me
> exactly how many free (non-in-use) pages that I can allocate
> before running out of memory.

>  total   used   free sharedbuffers cached
> Mem:126516  34728  91788  0264   7836
> -/+ buffers/cache:  26628  99888
> Swap:32124964  31160
> 
> 
> Here, the value 26628+964 is closer to what the 'actual' amount
> of RAM usage really is by processes (minus shared mem, buffers,
> and cache). But I was unable to find that without the
> allocation. So, my question is, is it possible to add a line to
> /proc/meminfo that tells us this information?

It would be better to put that in a userspace tool like
vmstat.

Oh, and now we're talking about vmstat, I guess that
program also needs support for displaying the number
of active/inactive_dirty/inactive_clean pages ... ;)

(any volunteers?)

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alain Knaff]

>
>
>On Sat, 16 Sep 2000, Alain Knaff wrote:
>
>> Moreover you seem to have an interesting definition of "most": for
>> many of those ioctls, sysctl would be rather clumsy: FDRAWCMD,
>> FDSETPRM, FDCLRPRM, FDDEFPRM, FDFMTBEG, FDFMTTRK, FDFMTEND, FDFLUSH,
>> FDRESET, FDTWADDLE, FDEJECT. Or do you really mean that for reading a
>
>Flush

What is so shocking about flushing away the cache for a
write-protected floppy?

> and format on write-protected floppy?

Agreed. However, for format, we have a different issue: if you open an
unformatted floppy the normal way, you might get an unreasonable delay
while the floppy driver is trying to autosense its format (which is
not yet there...). Hence the special open("/dev/fd0", 3) format which
gives back a filedescriptor which is neither readable, nor writable,
but which can still be used for ioctls.

> *PRM and FDTWADDLE - why
>not? That leaves FDRAWCMD, FDRESET and FDEJECT. Looks like controller
>commands for me...

What do you mean by "controller" commands?  Personnally, I'd find it
extremely bizarre to read a disk using sysctl or /proc/floppy/rawcmd

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alain Knaff]

>
>
>On Sat, 16 Sep 2000, Alain Knaff wrote:
>
>> Ok, now could you tell me a way how to easily detect a "fake inode",
>> and I rewrite my "restore ioctl functionality patch" in a way as not
>> to break floppy root mounts.
>
>s/root//
>
>fake means NULL ->i_sb, nothing fancy about that. IS_RDONLY() used to be
>very defensive and that's the only thing that didn't let this code blow
>into your face from the very beginning. You can protect the call of
>permission() with if (inode->i_sb).

Thanks.

So I'll just make that:

/* Allow ioctls if we have write-permissions even if read-only open.
 * Needed so that programs such as fdrawcmd still can work on write
 * protected disks */
if ((filp->f_mode & 2) ||
(inode->i_sb && (permission(inode,2) == 0)))
filp->private_data = (void*) 8;

>However,  I still think that it's
>bogus - after a look at the ioctl list it seems that most of them are
>sysctls in disguise (come on, verbosity level for debugging printk()s as
>ioctl()?)

Again, sysctl was not yet available, back when this was written.
Moreover you seem to have an interesting definition of "most": for
many of those ioctls, sysctl would be rather clumsy: FDRAWCMD,
FDSETPRM, FDCLRPRM, FDDEFPRM, FDFMTBEG, FDFMTTRK, FDFMTEND, FDFLUSH,
FDRESET, FDTWADDLE, FDEJECT. Or do you really mean that for reading a
disk, or formatting a disk, you should need sysctl?

>Probably the clean solution would be to add a character device per
>controller (/dev/fdc), turning eject /dev/fd0 into
>% echo eject 0 > /dev/fdc0

Why do that for floppies, when we still eject CD-Roms, Zips, "the
old-fashioned way" with ioctls?

>etc. Then access control is done via permissions of /dev/fdc* - no need
>to make the driver aware of VFS guts, layout of struct inode, etc.

Or, maybe you could just add a "safe" permission call to the VFS API
which wouldn't "blow up in your face". Oh, wait, that would cause a
nasty precedent: filesystem developers might then want to have new VFS
APIs added too, and we can't tolerate that, can we? ;-)

>I can do that. It doesn't require any modifications to the core part of
>the driver (trivial character device glue + tiny parser calling the same
>functions that fd_ioctl() calls), so it should be reasonably safe.

Given your track record, I'd rather not... ;-)

>I would really like to know what uses floppy-specific ioctls, though -
>look at the callers would probably clarify the situation.

Floppy formatting programs, programs that read/write non-PC disks (ya
know, lots of people still use CP/M disks for exchanging data with
their "legacy" hardware such as synthesizers, machine tools, glass
cutting machines, etc.), floppy configuration tools, etc. Ok, so these
programs might be used less frequently than other programs, but so are
programs that use IDE specific ioctls, programs that use SCSI specific
ioctls, etc.

>
>Comments?

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alexander Viro]

On Sat, 16 Sep 2000, Alain Knaff wrote:

> Moreover you seem to have an interesting definition of "most": for
> many of those ioctls, sysctl would be rather clumsy: FDRAWCMD,
> FDSETPRM, FDCLRPRM, FDDEFPRM, FDFMTBEG, FDFMTTRK, FDFMTEND, FDFLUSH,
> FDRESET, FDTWADDLE, FDEJECT. Or do you really mean that for reading a

Flush and format on write-protected floppy? *PRM and FDTWADDLE - why
not? That leaves FDRAWCMD, FDRESET and FDEJECT. Looks like controller
commands for me...

> Floppy formatting programs, programs that read/write non-PC disks (ya
> know, lots of people still use CP/M disks for exchanging data with
> their "legacy" hardware such as synthesizers, machine tools, glass
> cutting machines, etc.), floppy configuration tools, etc. Ok, so these
> programs might be used less frequently than other programs, but so are
> programs that use IDE specific ioctls, programs that use SCSI specific
> ioctls, etc.

OK, so fdutils and mtools should give a reasonable sample, right? I'm
talking about examples of use, not "everything that uses the thing".

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

[PATCH] Fix floppy ioctls, REVISED edition

[Alain Knaff]

The following patch (against 2.4.0-test8) restores floppy ioctl functionality,
which has been broken in 2.4.0-test6-pre7. It now tests for fake
ioctl's, so their should be no interaction with read-only mounts:

--- 2.4.0-test8/linux/drivers/block/floppy.cMon Sep 11 20:09:28 2000
+++ linux/drivers/block/floppy.cSat Sep 16 18:57:14 2000
@@ -3435,6 +3435,7 @@
 static int fd_ioctl(struct inode *inode, struct file *filp, unsigned int cmd,
unsigned long param)
 {
+#define FD_IOCTL_ALLOWED ((filp) && (filp)->private_data)
 #define OUT(c,x) case c: outparam = (const char *) (x); break
 #define IN(c,x,tag) case c: *(x) = inparam. tag ; return 0
 
@@ -3502,7 +3503,7 @@
return -EINVAL;
 
/* permission checks */
-   if (((cmd & 0x40) && !(filp->f_mode & 2)) ||
+   if (((cmd & 0x40) && !FD_IOCTL_ALLOWED) ||
((cmd & 0x80) && !capable(CAP_SYS_ADMIN)))
return -EPERM;
 
@@ -3708,6 +3709,8 @@
return -EIO;
}
 
+   filp->private_data = (void*) 0;
+
drive = DRIVE(inode->i_rdev);
if (drive >= N_DRIVE ||
!(allowed_drive_mask & (1 << drive)) ||
@@ -3774,6 +3777,13 @@
buffer_track = -1;
invalidate_buffers(MKDEV(FLOPPY_MAJOR,old_dev));
}
+
+   /* Allow ioctls if we have write-permissions even if read-only open.
+* Needed so that programs such as fdrawcmd still can work on write
+* protected disks */
+   if ((filp->f_mode & 2) || 
+   (inode->i_sb && (permission(inode,2) == 0)))
+   filp->private_data = (void*) 8;
 
if (UFDCS->rawcmd == 1)
UFDCS->rawcmd = 2;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: RAID HW Questions...

[Ricky Beam]

On Sat, 16 Sep 2000, Bryan Whitehead wrote:
>> The driver should be on DPT's site. Im not sure on the current state with the

(The driver _IS_ on DPT's site.  It always has been.)

>The driver directory is on thier web site. true. But it only works for
>specific versions of kernel's from RH. They do have the sources available

This is true of _any_ binary module.  That's why I never use binary modules.

>also. The problem comes when compiling. They specifically say not to use
>Linux's i2o stuff. Fine. They claim they have their "own" i2o
>implementaion. But it won't build, actually it won;t link. After looking
>at the FAQ more they say I need to build with gcc version 2.7.2. Becasue
>their driver only works with that. So i remove the gcc from my system and
>install an old gcc / linker. no change. Still the same damn error.

Have you bothered tell us what that error is?  I've not seen anything on
dpt's mail-list. (Which is where this should be discussed.)

>not like I'm some stupid moron (i wish that were the case then I'd be able
...
>development for Mission and Control for NASA's Deep Space network. So i'm
(you aren't inspiring any confidence here...)

>I need to have at LEAST 2.2.16 for security resons. But they don't give a
>crap.

Yes they do.  You just are talking to the right people.  (Maybe those "right
people" aren't there anymore.  DPT is now an Adaptec company, remember.)

>If Linux can get the card working with they native i2o drivers then
>great.

One of the primary reasons for use the DPT driver is to use the DPT RAID
mananger.  The Linux I2O code doesn't (currently) have that support.  It
could be added later, but someone's got to get the card to work with the
existing I2O code. (And I'll add the standard warning about SCSI card
HW RAID solutions... all of them require mucking about with the SCSI core
to prevent command timeouts.  In the case of the DPT card, it can take over
2 MINUTES to signal command completion -- my card will queue 210 commands
in an instant.)


>I'm to the point I don't mind blowing another $10,000 in taxpayers money
>to get the fsck'n RAID working in 2.2.17 land and hopefully 2.4 soon.

Point of fact: There _are_ people using >2.2.12 with the DPT driver.
Point of fact: There _are_ people usin 2.4 with the DPT driver.

I'm the one who made it work at 2.3.33... I sent those changes to DPT and
mailed several lists.

(http://chickenboo.bluetopia.net/~jfbeam/DPT/)

[jfbeam:pts/0]chickenboo:~/[2:05pm]:uname -a
Linux chickenboo 2.4.0-test5-SMP #13 SMP Thu Aug 24 16:23:36 EDT 2000 i686 unknown

[jfbeam:pts/0]chickenboo:~/[2:05pm]:gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

[jfbeam:pts/0]chickenboo:~/[2:10pm]:cat /proc/scsi/dpt_i2o/0 
Vendor: DPT Model: PM1554U2 Rev: 3013, scsi 0:

DPT I2O Driver Version: 1.09.1-cramer/1.2:

cmd_per_lun = 210, max_id = 15, max_lun = 7, max_channel = 1
sg_tablesize = 39, irq = 16, OutstandingMsgs = 0
maxfromiopmsgs = 64, maxtoiopmsgs = 210

Devices:
Channel = 0, Target = 0, Lun = 0
Channel = 1, Target = 4, Lun = 0

[jfbeam:pts/0]chickenboo:~/[2:11pm]:cat /proc/scsi/scsi
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: DPT  Model: CHICKENBOO   Rev: 3013
  Type:   Direct-AccessANSI SCSI revision: 02
Host: scsi0 Channel: 01 Id: 04 Lun: 00
  Vendor: SONY Model: SDT-1Rev: 0101
  Type:   Sequential-AccessANSI SCSI revision: 02

It's currently booting from that controller.  The driver also works as a
module.

>All I gatta say is thier driver is a piece of crap. I'll use Linux's i2o

Yes, it's hideous... it was originally a SCO driver.  But it works.

>If you would like me to try *ANYTHING* out to aid in getting the Card
>working I'm all yours. I'm a bit burned out but hell, If you think it's
>not that far away. Then who am i to argue?

For starters, you can tell us exactly what the hell your problem is.  Blow
off all the steam you want, but no one can help you until you tell us your
specific problem.

--Ricky

PS: I've had my difficulties with Mylex as well -- as if replacing the RTC
battery is going to fix a parity calculation fault in the firmware.
They knew damn well that battery had nothing to do with that card
crashing.


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

insmod failure in kernel-2.2.14

[aprasad]

i am using kernel-2.2.14-5.0,
i wrote a simple module to just printk a a message and tried to insmod it,
but
it gave error message: resource/device busy (EBUSY)
but the message gets printed in /var/log/messages

the code is:
--
#define MODULE
#include
int init_module(void)
{
 printk("this is amodule");
}
void cleanup_module(void)
{
 printk("removing the module");
}

NOTE:kindly cc the message to [EMAIL PROTECTED]


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

Re: Very aggressive swapping after 2 hours rest

[Rik van Riel]

On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> 
> > I'd like to be able to use that extra 16mb for process memory more than I would
> > for cache. When most of my programs get loaded up, it totals to around 24mb on
> > average, and medium-to-low disk access is used. I like the way it is now, where
> > it won't start swapping unless a process starts eating up memory quickly, or a
> > process starts to do a lot of disk access.
> 
> I do agree that processes that start up and never get 'touched'
> again should definitely get swapped out, but only when system
> ram is nearing the low point. At this point, processes who
> haven't used memory the longest should get swapped.

This is one of the things I'm thinking about at the moment.
Doing something like this should make the VM run a bit more
smooth at the moment the system would have just started
swapping, and the "kick in" of swap wouldn't be as sudden
as it is now.

> Also, one other thing I noticed (in the old VM, haven't noticed
> it on my 32mb machine yet) is that when processes get swapped
> out, doing a 'ps -aux' prints the SWAP values correctly as '0'.
> But doing a consecutive 'ps' shows these processes as '4'. Is
> there something new in recent kernels that getting process
> states actually has to access a page of the process's RAM? Just
> curious.

Shared glibc pages which are still in active use by other
processes aren't swapped out. As long as somebody is still
using this page actively we won't swap it out anyway, so
we might as well keep it mapped in the page table of every
process which references it ...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Trond Myklebust]

> " " == Michael Eisler <[EMAIL PROTECTED]> writes:

 > I'm not a Linux kernel literate. However, I found your
 > assertion surprising. Does procfs do page i/o as well?

No. It has its own setup.

 > file.c in fs/nfs suggests that the Linux VFS has non-page
 > interfaces in addition to page interfaces. fs/read_write.c
 > suggests that the read and write system calls uses the non-page
 > interface.

Yes. fs/read_write calls the NFS subsystem. The problem then is that
NFS uses the generic_file_{read,write,mmap}() interfaces. These are
what enforce use of the page cache.

You could drop these functions, but that would mean designing an
entire VFS for NFS's use alone. Such a decision would have to be very
well motivated in order to convince Linus.

>> As far as I can see, the current use of the page cache should
>> be safe as long as applications respect the locking boundaries,
>> and don't expect consistency outside locked areas.

 > Then the code ought to enforce page aligned locks. Of course,
 > while that will produce correctness, it will violate the
 > principle of least surprise. It might be better to simply

AFAICS that would be a bad idea, since it will lead to programs having
to know about the hardware granularity. You could easily imagine
deadlock situations that could arise if one program is unwittingly
locking an area that is meant to be claimed by another.

I'm not clear on why you want to enforce page alignedness though? As
long as writes respect the lock boundaries (and not page boundaries)
why would use of a page cache change matters?

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Alan Cox]

> I'm not a Linux kernel literate. However, I found your
> assertion surprising. Does procfs do page i/o as well?

No. An fs isnt required to use the page caches at all. It makes life a lot saner
to do so

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

folk: no more resource available

[octave klaba]

Hi,
Running on 2.2.17 / raid-soft (piii600/512ram) I have the
problems with the number of process. When ps auxw | wc -l
is more than 500 process no command works and all I get is
folk: no more resource available.

How can I run more that 500 process ? is there any
/proc to change or is the hard limitation of kernel
2.2.x ? 

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alexander Viro]

On Sat, 16 Sep 2000, Alain Knaff wrote:

> >You know, I have nothing against having it that way for CDs and Zips.
> >And you have an interesting idea of old-fashioned - I'ld say that
> >echo(1) was in place way before ioctl(2)...
> 
> You're right, echo is indeed older than ioctl.  However, ioctl is
> older than /proc, or odd character pseudo-devices that are used solely
> for control.

/proc - sure, but character devices? That's funny, because I distinctly
remember using write() for control of TTY in v7. Stuff like color, etc.
If it's not "solely for control"... Oh, OK - not solely, you have the
control and data streams mixed. And that's better which way?

> The point is not to do "do permissions of time of open", but rather to
> "do permissions independantly of open mode".

Exactly. Sorry for bad English - that's precisely what I meant. Can you
show me another example of such thing?

> If you still find the permission(inode,2) thing so ugly, I could move
> it from open() to fd_ioctl().

No, thanks. That would be even more weird.

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

[PATCH 2.4.0.9.1] Re: sisfb compile error (2.4.0-test8)

[Jeff Garzik]

This patch should fix sisfb the right way...  You don't want to define
...LINUXBIOS for normal situations..

Jeff



-- 
Jeff Garzik  | Would you *really* want to
Building 1024| get on a non-stop flight?
MandrakeSoft, Inc.   |   -- George Carlin

Index: drivers/video/sisfb.c
===
RCS file: /g/cvslan/linux_2_3/drivers/video/sisfb.c,v
retrieving revision 1.1.1.8
diff -u -r1.1.1.8 sisfb.c
--- drivers/video/sisfb.c   2000/09/05 03:41:24 1.1.1.8
+++ drivers/video/sisfb.c   2000/09/16 19:01:14
@@ -356,8 +356,6 @@
0x0B, 0x0C, 0x0D, 0x0F, 0x10
 };
 
-#ifdef CONFIG_FB_SIS_LINUXBIOS
-
 #define Monitor1Sense 0x20
 
 unsigned char SRegsInit[] = { 
@@ -371,6 +369,8 @@
0x8e, 0x40, 0x00, 0x00, 0x08, 0x00, 0xff, 0xff
 };
 
+#ifdef CONFIG_FB_SIS_LINUXBIOS
+
 unsigned char SRegs[] = { 
0x03, 0x01, 0x0F, 0x00, 0x0E, 0xA1, 0x02, 0x13,
0x3F, 0x86, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00,
@@ -1440,7 +1440,6 @@
 
 static u16 get_modeID_length(unsigned long ROMAddr, u16 ModeNo)
 {
-   unsigned char ModeID;
u16 modeidlength;
u16 usModeIDOffset;
unsigned short PreviousWord,CurrentWord;

Re: folk: no more resource available

[Rik van Riel]

On Sat, 16 Sep 2000, octave klaba wrote:

> Running on 2.2.17 / raid-soft (piii600/512ram) I have the
> problems with the number of process. When ps auxw | wc -l
> is more than 500 process no command works and all I get is
> folk: no more resource available.
> 
> How can I run more that 500 process ? is there any
> /proc to change or is the hard limitation of kernel
> 2.2.x ? 

Edit include/linux/threads.h and increase the maximum
number processes...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock()does not provide coherency guarantee

[Linus Torvalds]

On 16 Sep 2000, Trond Myklebust wrote:
> 
> Yes. fs/read_write calls the NFS subsystem. The problem then is that
> NFS uses the generic_file_{read,write,mmap}() interfaces. These are
> what enforce use of the page cache.
> 
> You could drop these functions, but that would mean designing an
> entire VFS for NFS's use alone. Such a decision would have to be very
> well motivated in order to convince Linus.

Ehh..

I would say that such a decision would be stupid beyond belief, and
impossible to motivate.

NFS certainly doesn't _have_ to use the page cache. However, not using the
page cache would basically in the end be equivalent to 
 (a) not having coherent mmap's over NFS
 (b) probably having much weaker caching
neither of which is really an option at all, I suspect.

You could do caching on your own, but I dare anybody to come up with a
better cache that is able to handle mmap and read/write coherency.

The page granularity issues come from mmap, not from the page cache per
se. ANYTHING that solves the coherency issue is pretty much bound by the
limitations of a page-cache-like thing - they are not limitations of the
implementation, but limitations pretty much inherent to the problem
itself.

Linus

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alain Knaff]

>On Sat, 16 Sep 2000, Alain Knaff wrote:
>
>> >Flush
>> 
>> What is so shocking about flushing away the cache for a
>> write-protected floppy?
>
>Erm... The fact that final close() will do it anyway?

Well it shouldn't, that would be a useless performance hit.

> Oh, and the fact
>that we have a generic ioctl() doing the same.

This is interesting.  Could you supply some details, so I can add
support for it to the floppy driver?

>> > *PRM and FDTWADDLE - why
>> >not? That leaves FDRAWCMD, FDRESET and FDEJECT. Looks like controller
>> >commands for me...
>> 
>> What do you mean by "controller" commands?  Personnally, I'd find it
>> extremely bizarre to read a disk using sysctl or /proc/floppy/rawcmd
>
>How about /dev/fd0ctl? I also find use of sysctl() an extremely bizarre
>way to read the disk. The thing being, ioctl() is not better. Dunno about
>you, but I prefer to use read() for reading...

Why do we suddenly have to change the structure of the floppy API,
after it worked flawlessly for years? What will be next? Will we
suddenly need a /dev/cdromplay in addition to /dev/cdrom just because
you don't understand some of Jens' code, but are too proud to ask (or
too lazy to browse /usr/src/linux/CREDITS)?  This is getting
ridiculous...

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

Re: test9-pre1 hang when loading scsi-ide cdrom

[Kenneth Johansson]

Frank van de Pol wrote:

> Just experienced a (reproducable) hang of the system when loading the
> drivers for my cdrom drives. (ide-cd and ide-scsi). System freezes
> completely; interupts / alt-sysreq is still working.
>

...

>
> It appears to me that something breaks during the init/registration of these
> devices. Any hint/tips to pinpoint the problem?
>

If it worked for you in test8 the only thing that changed is that in sr.c the
init_sr() function been maked with __init and the exit_sr() with __exit. You
could test removing them (__init and __exit that is not the function) it should
not matter but it's all I could find :(

By the way it works for me and I compile sr as a module mybe you don't ?


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

Re: insmod failure in kernel-2.2.14

[Christoph Hellwig]

In article <[EMAIL PROTECTED]> you wrote:
> i am using kernel-2.2.14-5.0,
> i wrote a simple module to just printk a a message and tried to insmod it,
> but
> it gave error message: resource/device busy (EBUSY)
> but the message gets printed in /var/log/messages

> the code is:
> --
> #define MODULE
> #include
> int init_module(void)
> {
>  printk("this is amodule");

add 'return 0' here

> }
> void cleanup_module(void)
> {
>  printk("removing the module");
> }

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: RAID HW Questions...

[Bryan Whitehead]

On Sat, 16 Sep 2000, Ricky Beam wrote:

> This is true of _any_ binary module.  That's why I never use binary modules.

That's why I don't want to use them either.

> Have you bothered tell us what that error is?  I've not seen anything on
> dpt's mail-list. (Which is where this should be discussed.)

I've emailed [EMAIL PROTECTED] (that's what the linuxi2oreadme.txt says to
do for help) MANY times pleading for help. i asked for Phone#'s, web
pages, ftp sites, and yes email lists. I've yet to get a reply in 6 months
of asking.
 
> Yes they do.  You just are talking to the right people.  (Maybe those "right
> people" aren't there anymore.  DPT is now an Adaptec company, remember.)

If I can call and email for 6 months and never get a reply that means they
DON'T care in my book.

> Point of fact: There _are_ people using >2.2.12 with the DPT driver.
> Point of fact: There _are_ people usin 2.4 with the DPT driver.

You know what? I REALLY hope I'm wrong. I really do. I hope it was sitting
in front of me the whole time. Please please please tell me where I can
get it. (and 2.2.12 isn't good enough).

> I'm the one who made it work at 2.3.33... I sent those changes to DPT and
> mailed several lists.
> 
> (http://chickenboo.bluetopia.net/~jfbeam/DPT/)

Great! What about 2.2.17? ot 2.4.0(test) ? I really don't care much
about 2.3.33. 

> For starters, you can tell us exactly what the hell your problem is.  Blow
> off all the steam you want, but no one can help you until you tell us your
> specific problem.

He's something to start on: If you want full build logs let me know. They
may take awile to get. (I'd rather not work on the weekend).
I have 2 systems. one in production, one just sitting around
for me to mess with. They both have the same exact software. I'll
show the current configuration from the production machine using
the binary drivers from DPT.

BTW this is where I got the drivers:
ftp://ftp.adaptec.com/raid/dpt/SRV/software/drivers/linux/
here is my sysinfo (same as what you put out).
uname -a
Linux www.rccacm.org 2.2.5-22smp #1 SMP Wed Jun 2 09:11:51 EDT 1999 i686
unknown
gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
cat /proc/scsi/dpt/1 
Vendor: DPT Model: PM2554U2 Rev: 211D, scsi 1:

DPT I2O Driver Version: 1.06/1.1:

cmd_per_lun = 210, max_id = 15, max_lun = 7, max_channel = 0
sg_tablesize = 39, irq = 18, OutstandingMsgs = 0
maxfromiopmsgs = 64, maxtoiopmsgs = 210

Devices:
Channel = 0, Target = 1, Lun = 0
cat /proc/scsi/scsi
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: QUANTUM  Model: ATLAS IV 9 WLS   Rev: 0808
Type:   Direct-AccessANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: DPT  Model: RAID-5   Rev: 211D
Type:   Direct-AccessANSI SCSI revision: 02

Now for the Building. This is using 2.2.17 Kernel. The errors are the same
for the previous Kernels as well. I patched in the 109patch.gz file found
in the FTP site I gave you. (As it's stated to do in the readme - you neet
to d/l dpti2olinux.zip to get the linuxi2oreadme.txt). At the very end of
the .txt file it states a error I *might* get. i get that one. This is
what it says:
Q:  When attempting to compile my kernel, I am getting lots
of error such as:
drivers/scsi/scsi.a(dpt_i2o.o): In function `dpt_add_timer':
dpt_i2o.o(.text+0x10): undefined reference to
`del_timer_Rsmp_5811f067'
A:  This is an error seen when using a compiler newer than gcc 2.7.2.  Use 
gcc 2.7.2 or older.

I've used gcc 2.7.2 and get the same results. :(

Another wierd thing is even though they have a "patch" for this card they
give instructions to manually edit it a .h file they forgot to include.



-- 
---
Bryan Whitehead
Email: [EMAIL PROTECTED]
WorkE: [EMAIL PROTECTED]

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

Re: insmod failure in kernel-2.2.14

[Alan Cox]

> i wrote a simple module to just printk a a message and tried to insmod it,
> but
> it gave error message: resource/device busy (EBUSY)
> but the message gets printed in /var/log/messages

Compile it with -Wall and you should see why
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Giuliano Pochini]

> The current HUGE queue size is probably another reason for
> the very bad latencies we sometimes see...

Yes, but if the queue is short processes are likely to remain
blocked in D state for more time and the chances to merge rq
are smaller.
IMHO we should add a way to give priority to rqs from live
tasks. i.e. a "cp" usually puts stuff on the queue and then
exits. There's no need to service that i/o immediately.

> > I don't think you should allow merges. If one process is doing a big
> > IO operation on a big file it would still get _all_ capacity, right?
>
> Only if you were to allow unlimited merges ;)
>
> I guess a 'decent' maximum size for one request would
> be somewhere around 256kB, since this is the amount of
> data a drive can read in the time of one disk seek...

Today's HDs transfer rates of 10+MB/s are not uncommon. 256KB is a bit
too small IMHO. SCSI discs that don't support TQ (e.g. quantum) get a
performance hit.

Bye.


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

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Giuliano Pochini]

> That's one approach; I prefer my "weighted scoring" approach. Supposing we
> have three devices: a solid state disk (instant "seeks"), a hard drive and
> a tape. The SSD will benefit from merges (fewer commands to process), but
> not hugely - set both the metrics at 1, so a 64Kb request is just under
> twice the "cost" of a 32Kb one. The hard drive can seek fairly quickly,
> but long reads are preferable - say, seek_cost = 16, block_cost = 1. A
> single 64Kb request is "cheaper" than a pair of 32Kb requests, but not
> hugely so. Then the tape: seeks can take a few minutes, so make it
> seek_cost = 65536, block_cost = 1: we don't really care how much is being
> read, within reason, since seeks are so "expensive".

If we could read by a SCSI command the maximun/typical/minimum seek and
transfer speed directly from the drive things were a lot simpler :))

Bye.

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

Re: folk: no more resource available

[Alan Cox]

> How can I run more that 500 process ? is there any
> /proc to change or is the hard limitation of kernel
> 2.2.x ? 

Edit include/linux/tasks.h

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

Re: RAID HW Questions...

[Alan Cox]

> One of the primary reasons for use the DPT driver is to use the DPT RAID
> mananger.  The Linux I2O code doesn't (currently) have that support.  It
> could be added later, but someone's got to get the card to work with the

DPT don't do standard I2O block management. Linux supports the standard stuff
including configuring your raid card with a web browser


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

Re: RAID HW Questions...

[Ricky Beam]

On Sat, 16 Sep 2000, Bryan Whitehead wrote:
>> Have you bothered tell us what that error is?  I've not seen anything on
>> dpt's mail-list. (Which is where this should be discussed.)
>
>I've emailed [EMAIL PROTECTED] (that's what the linuxi2oreadme.txt says to
>do for help) MANY times pleading for help. i asked for Phone#'s, web
>pages, ftp sites, and yes email lists. I've yet to get a reply in 6 months
>of asking.

Gez, Adaptec has made a fscking mess out of this -- I knew those *sses would.

>> Yes they do.  You just are talking to the right people.  (Maybe those "right
>> people" aren't there anymore.  DPT is now an Adaptec company, remember.)
>
>If I can call and email for 6 months and never get a reply that means they
>DON'T care in my book.

([EMAIL PROTECTED] is the mail list, btw)

The people I talked to in April:
"Salyzyn, Mark" <[EMAIL PROTECTED]>
"Tran, Huy" <[EMAIL PROTECTED]>

At the time, they had someone "starting on monday" to handle the linux
driver.  I guess they never made it to work that Monday :-)

>> I'm the one who made it work at 2.3.33... I sent those changes to DPT and
>> mailed several lists.
>> 
>> (http://chickenboo.bluetopia.net/~jfbeam/DPT/)
>
>Great! What about 2.2.17? ot 2.4.0(test) ? I really don't care much
>about 2.3.33. 

I don't run 2.2.  And I showed you the driver (that very 2.3.33 driver)
running on 2.4.0-test...  I've put a README in there to deal with alot
of these questions (and I knew you where gonna bitch about it being 2.3.33)

Why are people always to inflexable as to require everything to match up
atom to atom (bit for bit) before they will try anything?  Did you look
at the patches at all?  They hardly touch the kernel sources at all.  The
changes necessary are to the dpt_i2o driver itself.

As I've stated in the README, I do not have explicit permission to distribute
their driver.

>Vendor: DPT Model: PM2554U2 Rev: 211D, scsi 1:

First, get the latest firmware (I have no clue where adaptec might have
hidden them.)

>Q:  When attempting to compile my kernel, I am getting lots
>of error such as:
>   drivers/scsi/scsi.a(dpt_i2o.o): In function `dpt_add_timer':
>   dpt_i2o.o(.text+0x10): undefined reference to
>   `del_timer_Rsmp_5811f067'
>A:  This is an error seen when using a compiler newer than gcc 2.7.2.  Use 
>   gcc 2.7.2 or older.

Right.  This is caused by the compiler... *cough*bullshit*cough*.  Either
del_timer isn't exported or the dpt driver didn't load the right include
file.  I'll go play with 2.2.17 later. (Some companies have a negative
clue level.)

>Another wierd thing is even though they have a "patch" for this card they
>give instructions to manually edit it a .h file they forgot to include.

See above about "clue".

--Ricky

PS: Ignore the mis-information from Adaptec/DPT.  If you're as smart as you
should be, you can fix this yourself (assuming you know much about the
linux kernel and how it gets built.)


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

Re: test9-pre1 hang when loading scsi-ide cdrom

[Frank van de Pol]

On Sat, Sep 16, 2000 at 09:04:55PM +0200, Kenneth Johansson wrote:
> 
> If it worked for you in test8 the only thing that changed is that in sr.c the
> init_sr() function been maked with __init and the exit_sr() with __exit. You
> could test removing them (__init and __exit that is not the function) it should
> not matter but it's all I could find :(

I'll give it a try. 

Previous version I tried was test7. Didn't run test8 because it gave some
compilation error (which have been fixed in the test9-pre1 :-)

> 
> By the way it works for me and I compile sr as a module mybe you don't ?
I'm compiling it as module too. This ide-scsi driver the 2nd scsi host, 1st
one is a AHA-2940UW (aic-7xxx). 

Frank.


-- 
+ --- -- -  -   -- 
|Frank van de Pol  -o)
| [EMAIL PROTECTED]   /\\
| _\_v
|Linux - Why use Windows, since there is a door?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Attempting to mount Zip causes floppy access (2.2.16)

[Andries Brouwer]

On Sat, Sep 16, 2000 at 11:35:24AM +0100, Nick Holloway wrote:

> I have a zip disk which I attempted to mount using the following fstab
> entry:
> 
> /dev/sda4 /zip vfat noauto,nodev,nosuid,user
> 
> This caused a spew of "bread failed" errors, and the mount process ended
> up blocked in "wait_on_buffer".  I thought at first that Zip disk had
> gone to silicon heaven.
> 
> After rebooting, I had a look at the kernel messages, and was _amazed_ to
> see the following:
> 
> SCSI device sda: hdwr sector= 512 bytes.
> Sectors= 196608 [96 MB] [0.1 GB]
> sda: Write Protect is off
>  sda: sda1 sda2 sda3 sda4
> floppy0: disk absent or changed during operation
> end_request: I/O error, dev 02:00 (floppy), sector 1
> bread in fat_access failed
> [...]
> 
> There are two questions.  Firstly, why did the mount process get stuck
> in the kernel, and secondly (and more importantly) what was it doing
> accessing "/dev/fd0"?

Does that follow? Maybe the floppy I/O error occurred at some other
time, or for some other reason. Can you reproduce access of device 02:00
using mount /dev/sda4?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[James Sutherland]

On Sat, 16 Sep 2000, Giuliano Pochini wrote:

> I wrote, then got air-brushed out of the thread?!
> > That's one approach; I prefer my "weighted scoring" approach. Supposing we
> > have three devices: a solid state disk (instant "seeks"), a hard drive and
> > a tape. The SSD will benefit from merges (fewer commands to process), but
> > not hugely - set both the metrics at 1, so a 64Kb request is just under
> > twice the "cost" of a 32Kb one. The hard drive can seek fairly quickly,
> > but long reads are preferable - say, seek_cost = 16, block_cost = 1. A
> > single 64Kb request is "cheaper" than a pair of 32Kb requests, but not
> > hugely so. Then the tape: seeks can take a few minutes, so make it
> > seek_cost = 65536, block_cost = 1: we don't really care how much is being
> > read, within reason, since seeks are so "expensive".
> 
> If we could read by a SCSI command the maximun/typical/minimum seek and
> transfer speed directly from the drive things were a lot simpler :))

We can almost do that with any device; if we have a nice interface for
user-space tuning (a few /proc files), we can be told at boot-time what
the characteristics of each device are. A simple piece of code which does
a couple of seeks and a big read or two on each device would achieve this
easily enough.

We don't need to know the exact characteristics, but it could be of some
use in fine-tuning performance; my overall approach should work reasonably
well for any given device, I think?


James.

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

Tailmerging for Ext2 - release 0.0

[Daniel Phillips]

Here we are, finally: code.  I do not make any claim that this code is
elegant, correct, complete, esthetically pleasing or that it will
refrain from eating your hard disk.

What this code will do is let you verify for yourself whether my
proposed approach to tailmerging for Ext2 is worth the effort.  After
you build the mrg2 module you can go around and test various
partitions to see how much safe you would save with this tailmerging
approach:

  mount /dev/hda9 /try-me -t mrg2 -o tails=tell

This is non-invasive, i.e., it doesn't write to the partition.  I
think.  :-)

I've tried this a few times myself and gotten some pretty impressive
results: 14 percent of data blocks saved for the linux source tree and
30% saved for the mozilla tree.  Even better is what it does to
worst-case disk wastage.  With no special handling of tail blocks Ext2
is quite capable of wasting 99.9% of your disk space in the worst
case.  With this tailmerging algorithm the worst case improves to
about 50% wastage... much, much, better.  Keep in mind it's not just
space savings at stake here - fewer blocks to read means less time
spent reading them.  The question is: what is the bottom line
performance impact?  I just don't know yet.  Please help me and try
the code.  Even better, *read the code* then try it.

This code has been tested far less than it should have been. 
Basically, I tried a few test cases and fixed the obvious bugs that
came up, then zipped it and shipped it out.  The merge/unmerge code is
a little more tested than the file operations code.  There is one
thing you can be sure of: this is not thread safe.  Yet.  I'll look at
those issues next week.

And when this code is working perfectly it will still only be version
0.4.  Version 0.5 is the first version that will do incremental
tail merging, i.e., actually be useful.  I'm thinking now about
algorithms and data structures for that because I think the first half
of this problem is pretty well licked.  Please, you be the judge of
that.

Let me put in one more plug here.  There is some urgency to this
tailmerging stuff because the trend is towards bigger and bigger
filesystem block sizes,  Bigger blocks sizes means more potential
wastage of space in tail blocks.  We really need the bigger blocks so
we can have bigger filesystems and faster I/O transfers, but the tail
fragmentation problem has to be solved before we can head much further
in that direction.

And finally, some credits: thanks to Hans Reiser for giving me the
idea to do this, to Stephen Tweedie for a timely push in the right
direction, Chris Mason for his war stories and helpful suggestions,
and Al Viro for keeping a watchful eye out for dragon attacks.

The patch is here:

  http://innominate.org/~phillips/tailmerge.0.0.zip

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