Re: PIO disk writes using 100% system time and performing poorly with VIA vt82c686b on kernels 2.2 & 2.4

[Vojtech Pavlik]

On Tue, Apr 24, 2001 at 07:19:41PM -0400, Ignacio Monge wrote:

>   I have  VIA686a too and a UDMA100 hard disk.
>   This is my cat /proc/ide/via:
> 
> --VIA BusMastering IDE Configuration
> Driver Version: 3.23
> South Bridge:   VIA vt82c686a
> Revision:   ISA 0x22 IDE 0x10
> Highest DMA rate:   UDMA66
> BM-DMA base:0xb800
> PCI clock:  33MHz
> ---Primary IDE---Secondary IDE--
> Enabled:  yes yes
> Cable Type:   40w 40w
> ---drive0drive1drive2drive3-
> Transfer Mode:DMA  UDMA   PIO   PIO
> Address Setup:   30ns  30ns 120ns 120ns
> Cmd Active:  90ns  90ns 480ns 480ns
> Cmd Recovery:30ns  30ns 480ns 480ns
> Data Active: 90ns  90ns 330ns 330ns
> Data Recovery:   30ns  30ns 270ns 270ns
> Cycle Time: 120ns  60ns 600ns 600ns
> Transfer Rate:   16.5MB/s  33.0MB/s   3.3MB/s   3.3MB/s
> 
>   As you can see, l use UDMA66 instead UDMA100. 

You use UDMA33 dor your second drive and MWDMA16 for your first.
Check your BIOS UDMA enable settings.

> I don't know why. Maybe VIA vt82c686a doesn't support it?

Yes, it supports modes only up to 66 MB/sec.

> I have answering in this list a days ago about this problem. but none seems to have 
>a question. Like you, my system goes down when I try to compile something (I have a 
>394 Mb of RAM and a 1 Ghz processor).
>   Although, my hdparm output is this:
>   /dev/hde2:
>  Timing buffer-cache reads:   128 MB in  0.79 seconds =162.03 MB/sec
>  Timing buffered disk reads:  64 MB in  2.44 seconds = 26.23 MB/sec
>   and sometime looks better.

26 megabytes per second is quite surprising in your setup

>   I don't know is this is a problem with the VIA kernel driver or not. But the 
>system doesn't seem to work fine since 2.4.2 or 2.4.1 kernel. I hope (plz!) this 
>problem will be fixed in future.

You can disable the VIA driver.

>   PS: in cat /proc/ide/via I see "Cable Type:   40w  
>   40w"... Is it right? I have a 80w cable, not 40.

Check your BIOS settings, if you have disabled UDMA in the BIOS, the
driver can't detect the cable. If that doesn't work, use "ide0=ata66"
on the kernel command line.

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

routing & ipchains

[Andrew B. Cramer]

Greetings All,
After upgrading from kernel 2.0.38 w/ slackware-3.4 to
kernel 2.2.16 w/ slackware-7.1 I have developed the following
routing problems.

Hardware -
eth0 - 10meg on net 192.168.0.0 i/f 192.168.0.1 subnet 
255.255.255.128
eth1 - 100meg on net 192.168.0.128 i/f 192.168.0.130 subnet 
255.255.255.128

>From either network I can use ipchains and surf/telnet/ftp/... on 
each network to the ppp0 dialup connection. I cannot ping or 
anything from eth0 to eth1 or back.

-Route with ppp0 up
Destination Gateway Genmask Flags Metric Ref
Use Iface
205.243.155.100 0.0.0.0 255.255.255.255 UH0  00 
ppp0
192.168.0.0 0.0.0.0 255.255.255.128 U 0  00 
eth1
192.168.0.128   0.0.0.0 255.255.255.128 U 0  00 
eth0
192.168.0.0 192.168.0.1 255.255.255.0   UG0  00 
eth1
127.0.0.0   0.0.0.0 255.0.0.0   U 0  00 lo
0.0.0.0 205.243.155.100 0.0.0.0 UG0  00 
ppp0
0.0.0.0 192.168.0.1 0.0.0.0 UG0  00 eth1
0.0.0.0 192.168.0.130   0.0.0.0 UG0  00 eth0
---End of Route Table--

TIA - if other files are needed, I can forward.

Best - Andy

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

Re: [patch] swap-speedup-2.4.3-B3

[Marcelo Tosatti]

On Tue, 24 Apr 2001, Linus Torvalds wrote:

> Basically, I don't want to mix synchronous and asynchronous
> interfaces. Everything should be asynchronous by default, and waiting
> should be explicit.

The following patch changes all swap IO functions to be asynchronous by
default and changes the callers to wait when needed (except
rw_swap_page_base which will block writers if there are too many in flight
swap IOs). 

Ingo's find_get_swapcache_page() does not wait on locked pages anymore,
which is now up to the callers.

time make -j32 test with 4 CPUs machine, 128M ram and 128M swap: 

pre5

228.04user 28.14system 5:16.52elapsed 80%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (525113major+678617minor)pagefaults 0swaps

pre5 + attached patch 

227.18user 25.49system 3:40.53elapsed 114%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (495387major+644924minor)pagefaults 0swaps


Comments? 


diff -Nur linux.orig/include/linux/pagemap.h linux/include/linux/pagemap.h
--- linux.orig/include/linux/pagemap.h  Wed Apr 25 00:51:36 2001
+++ linux/include/linux/pagemap.h   Wed Apr 25 00:53:04 2001
@@ -77,7 +77,12 @@
unsigned long index, struct page **hash);
 extern void lock_page(struct page *page);
 #define find_lock_page(mapping, index) \
-   __find_lock_page(mapping, index, page_hash(mapping, index))
+   __find_lock_page(mapping, index, page_hash(mapping, index))
+
+extern struct page * __find_get_swapcache_page (struct address_space * mapping,
+   unsigned long index, struct page **hash);
+#define find_get_swapcache_page(mapping, index) \
+   __find_get_swapcache_page(mapping, index, page_hash(mapping, index))
 
 extern void __add_page_to_hash_queue(struct page * page, struct page **p);
 
diff -Nur linux.orig/include/linux/swap.h linux/include/linux/swap.h
--- linux.orig/include/linux/swap.h Wed Apr 25 00:51:36 2001
+++ linux/include/linux/swap.h  Wed Apr 25 00:53:04 2001
@@ -111,8 +111,8 @@
 extern int try_to_free_pages(unsigned int gfp_mask);
 
 /* linux/mm/page_io.c */
-extern void rw_swap_page(int, struct page *, int);
-extern void rw_swap_page_nolock(int, swp_entry_t, char *, int);
+extern void rw_swap_page(int, struct page *);
+extern void rw_swap_page_nolock(int, swp_entry_t, char *);
 
 /* linux/mm/page_alloc.c */
 
@@ -121,8 +121,7 @@
 extern void add_to_swap_cache(struct page *, swp_entry_t);
 extern int swap_check_entry(unsigned long);
 extern struct page * lookup_swap_cache(swp_entry_t);
-extern struct page * read_swap_cache_async(swp_entry_t, int);
-#define read_swap_cache(entry) read_swap_cache_async(entry, 1);
+extern struct page * read_swap_cache_async(swp_entry_t);
 
 /* linux/mm/oom_kill.c */
 extern int out_of_memory(void);
diff -Nur linux.orig/mm/filemap.c linux/mm/filemap.c
--- linux.orig/mm/filemap.c Wed Apr 25 00:51:35 2001
+++ linux/mm/filemap.c  Wed Apr 25 00:53:04 2001
@@ -678,6 +678,34 @@
 }
 
 /*
+ * Find a swapcache page (and get a reference) or return NULL.
+ * The SwapCache check is protected by the pagecache lock.
+ */
+struct page * __find_get_swapcache_page(struct address_space *mapping,
+ unsigned long offset, struct page **hash)
+{
+   struct page *page;
+
+   /*
+* We need the LRU lock to protect against page_launder().
+*/
+
+   spin_lock(_lock);
+   page = __find_page_nolock(mapping, offset, *hash);
+   if (page) {
+   spin_lock(_lru_lock);
+   if (PageSwapCache(page)) 
+   page_cache_get(page);
+   else
+   page = NULL;
+   spin_unlock(_lru_lock);
+   }
+   spin_unlock(_lock);
+
+   return page;
+}
+
+/*
  * Same as the above, but lock the page too, verifying that
  * it's still valid once we own it.
  */
diff -Nur linux.orig/mm/memory.c linux/mm/memory.c
--- linux.orig/mm/memory.c  Wed Apr 25 00:51:35 2001
+++ linux/mm/memory.c   Wed Apr 25 00:53:04 2001
@@ -1040,7 +1040,7 @@
break;
}
/* Ok, do the async read-ahead now */
-   new_page = read_swap_cache_async(SWP_ENTRY(SWP_TYPE(entry), offset), 
0);
+   new_page = read_swap_cache_async(SWP_ENTRY(SWP_TYPE(entry), offset));
if (new_page != NULL)
page_cache_release(new_page);
swap_free(SWP_ENTRY(SWP_TYPE(entry), offset));
@@ -1063,13 +1063,13 @@
if (!page) {
lock_kernel();
swapin_readahead(entry);
-   page = read_swap_cache(entry);
+   page = read_swap_cache_async(entry);
unlock_kernel();
if (!page) {
spin_lock(>page_table_lock);
return -1;
}
-
+   wait_on_page(page);
flush_page_to_ram(page);

TULIP driver broken

[Ian Zink]

Well it would appear the tulip driver regressed from 2.4.2-ac22 and
2.4.3. (2.4.3-ac12 isn't working either) Once again, my tulip card just
spews carrier errors and doesn't even get a link light.

If someone could point me to a patch I would appreciate it. I have
attached any pretient information below.


Thanks, Ian Zink


Linux zforce 2.4.3-ac12 #5 Tue Apr 24 02:49:03 CDT 2001 i686 unknown

  Bus  0, device  11, function  0:
Ethernet controller: Digital Equipment Corporation DECchip 21140
[FasterNet]
 (rev 32).
  IRQ 10.
  Master Capable.  Latency=32.  Min Gnt=20.Max Lat=40.
  I/O at 0xb000 [0xb07f].
  Non-prefetchable 32 bit memory at 0xe080 [0xe080007f].

eth0  Link encap:Ethernet  HWaddr 00:00:C0:41:99:E9
  inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:243 dropped:0 overruns:0 carrier:243
  collisions:0 txqueuelen:100
  RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
  Interrupt:10 Base address:0xb000

Linux version 2.4.3-ac12 (root@zforce) (gcc version 2.95.4 20010319
(Debian prer
elease)) #5 Tue Apr 24 02:49:03 CDT 2001


Linux Tulip driver version 0.9.14e (April 20, 2001)
PCI: Found IRQ 10 for device 00:0b.0
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1)
block.
00:0b.0:  MII transceiver #3 config 3100 status 7809 advertising 01e1.
00:0b.0:  Advertising 0001 on PHY 3, previously advertising 01e1.
00:0b.0:  Advertising 0001 (to advertise is 0001).
eth0: Digital DS21140 Tulip rev 32 at 0xb000, 00:00:C0:41:99:E9, IRQ 10.



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

Re: Request for comment -- a better attribution system

[Eric S. Raymond]

Roger Gammans <[EMAIL PROTECTED]>:
> On Tue, Apr 24, 2001 at 09:14:41AM -0400, Horst von Brand wrote:
> > People who want to take over "because it is s00 k3w1 to be a maintainer"
> > with no real interest in the code, just in the fact that it is orphaned...
> 
> No. People who want to give something back to the linux community
> and want to find an option within their ability and time constariants.

Indeed.  Beware elitism.  If lkml become a closed society, it will become
a dead one shortly thereafter.
-- 
http://www.tuxedo.org/~esr/;>Eric S. Raymond

"The great object is, that every man be armed. [...] 
Every one who is able may have a gun."
-- Patrick Henry, speech of June 14 1788
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Event tools, do they exist

[Andrew Morton]

george anzinger wrote:
> 
> This is an attempt to look in the wheel locker.
> 
> I need a simple event sub system for use in the kernel.  I envision at
> least two types of events: the history event and the timing event.
> 
> The timing event would keep track of start/stop times by class.  If, for
> example, I wanted to know how much time the kernel spends doing the
> recalc in schedule() I would put and event start in front of it and an
> end at the other end.  The sub system would note the first event time
> and the cumulative time between all starts and stops on the same event.
> When reported by /proc/ it would give the total event time, the elapsed
> time and the % of processor time for each of the possibly several
> classes.

http://www.uow.edu.au/~andrewm/linux/#timepegs  (The patch
against 2.4.1-pre10 still applies!)

> The history event would record each events time, location, data1,
> data2.  It would keep N of these (the last N) and report M (M= /proc/.  This list should also be kept in a format that a simple
> debugger can easily examine.

Linux Trace Toolkit may be able to do this.

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

Re: Scheduling bug for SCHED_FIFO and SCHED_RR

[Nigel Gamble]

On Fri, 20 Apr 2001, Nigel Gamble wrote:
> A SCHED_FIFO or SCHED_RR task with priority n+1 will not preempt a
> running task with priority n.  You need to give the higher priority task
> a priority of at least n+2 for it to be chosen by the scheduler.
> 
> The problem is caused by reschedule_idle(), uniprocessor version:
> 
>   if (preemption_goodness(tsk, p, this_cpu) > 1)
>   tsk->need_resched = 1;
> 
> For real-time scheduling to work correctly, need_resched should be set
> whenever preemption_goodness() is greater than 0, not 1.

This bug is also in the SMP version of reschedule_idle().  The
corresponding fix (against 2.4.3-ac14) is:

--- 2.4.3-ac14/kernel/sched.c   Tue Apr 24 18:40:15 2001
+++ linux/kernel/sched.cTue Apr 24 18:41:32 2001
@@ -246,7 +246,7 @@
 */
oldest_idle = (cycles_t) -1;
target_tsk = NULL;
-   max_prio = 1;
+   max_prio = 0;
 
for (i = 0; i < smp_num_cpus; i++) {
cpu = cpu_logical_map(i);

Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [EMAIL PROTECTED]

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

Re: [PATCH] Single user linux

[Disconnect]

On Tue, 24 Apr 2001, Aaron Lehmann did have cause to say:

> On Wed, Apr 25, 2001 at 10:07:48AM +1000, Daniel Stone wrote:
> > What real value does it have, apart from the geek "look at me, I'm using
> > bash" value?
> 
> I don't really want to get into it at the moment, but imagine hacking
> netfilter without lugging a laptop around. PDA's are sleek and cool,
> and using UNIX on them lets you write shell scripts to sort your
> addresses and stuff like that. Basically it's everything that's cool
> about Unix as a workstation OS scaled down to PDA-size.

Two (not quite exclusive ;) ..) points:

First, most pda's have apps like telnet/ssh/etc available. (And even more
specific apps are available for various uses - I recall a palm pilot app
that talked to cisco gear and gave a nice gui for 90% of the config, plus
a terminal for the rest.)

And second, I agree that there are some great advantages to small linux
(my ipaq runs linux, and my barely larger libretto is a full debian
mirror) but all of these (even pocketlinux, which is basically not linux)
work with the concept of multiple users.  Whether for profiles or for
system vs user, they all use it.  This patch is trash.



-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P- L+++>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: orinoco_cs & IrDA

[Jean Tourrilhes]

On Tue, Apr 24, 2001 at 06:25:50PM -0700, Jean Tourrilhes wrote:
> 
>   Ok, now to the second chapter. These are all the changes
> accumulated since the patch I sent one month ago (cf previous e-mail).
>   Changes :
>   o more Prism2/Symbol compatibility goodies
>   o Tested D-Link cards and Lucent firmware 7.28
>   o Cleanup, bug fixes from David Gibson
>   The whole is tested, as usual... 75% of the patch was on my
> web pages for the last month and people seem to have liked it.
> 
>   I've made 2 patches, one for 2.4.4-pre6 and one for
> 2.4.3-ac13. The difference between the two is minor (one line).
> 
>   Linus : please have a look at orinoco_v4b.diff (first
> attachement). Of course, this patch will apply and work only if you
> have applied the patch in my previous e-mail.
> 
>   Alan : orinoco_v4b-alan.diff is for you (second attachement).
> 
>   Have fun...
> 
>   Jean

File attached this time...

Jean


diff -u -p linux/drivers/net/pcmcia/wireless.25b/hermes.h 
linux/drivers/net/pcmcia/hermes.h
--- linux/drivers/net/pcmcia/wireless.25b/hermes.h  Tue Apr 24 15:57:48 2001
+++ linux/drivers/net/pcmcia/hermes.h   Tue Apr 24 16:04:34 2001
@@ -35,18 +35,18 @@
 /*
  * Limits and constants
  */
-#defineHERMES_ALLOC_LEN_MIN((uint16_t)4)
-#defineHERMES_ALLOC_LEN_MAX((uint16_t)2400)
+#defineHERMES_ALLOC_LEN_MIN(4)
+#defineHERMES_ALLOC_LEN_MAX(2400)
 #defineHERMES_LTV_LEN_MAX  (34)
-#defineHERMES_BAP_DATALEN_MAX  ((uint16_t)4096)
-#defineHERMES_BAP_OFFSET_MAX   ((uint16_t)4096)
-#defineHERMES_PORTID_MAX   ((uint16_t)7)
-#defineHERMES_NUMPORTS_MAX 
((uint16_t)(HERMES_PORTID_MAX+1))
-#defineHERMES_PDR_LEN_MAX  ((uint16_t)260) /* in bytes, 
from EK */
-#defineHERMES_PDA_RECS_MAX ((uint16_t)200) /* a guess */
-#defineHERMES_PDA_LEN_MAX  ((uint16_t)1024)/* in 
bytes, from EK */
-#defineHERMES_SCANRESULT_MAX   ((uint16_t)35)
-#defineHERMES_CHINFORESULT_MAX ((uint16_t)8)
+#defineHERMES_BAP_DATALEN_MAX  (4096)
+#defineHERMES_BAP_OFFSET_MAX   (4096)
+#defineHERMES_PORTID_MAX   (7)
+#defineHERMES_NUMPORTS_MAX (HERMES_PORTID_MAX+1)
+#defineHERMES_PDR_LEN_MAX  (260)   /* in bytes, from EK */
+#defineHERMES_PDA_RECS_MAX (200)   /* a guess */
+#defineHERMES_PDA_LEN_MAX  (1024)  /* in bytes, from EK */
+#defineHERMES_SCANRESULT_MAX   (35)
+#defineHERMES_CHINFORESULT_MAX (8)
 #defineHERMES_FRAME_LEN_MAX(2304)
 #defineHERMES_MAX_MULTICAST(16)
 #defineHERMES_MAGIC(0x7d1f)
@@ -86,122 +86,125 @@
 /*
  * CMD register bitmasks
  */
-#defineHERMES_CMD_BUSY ((uint16_t)0x8000)
-#defineHERMES_CMD_AINFO((uint16_t)0x7f00)
-#defineHERMES_CMD_MACPORT  ((uint16_t)0x0700)
-#defineHERMES_CMD_RECL ((uint16_t)0x0100)
-#defineHERMES_CMD_WRITE((uint16_t)0x0100)
-#defineHERMES_CMD_PROGMODE ((uint16_t)0x0300)
-#defineHERMES_CMD_CMDCODE  ((uint16_t)0x003f)
+#defineHERMES_CMD_BUSY (0x8000)
+#defineHERMES_CMD_AINFO(0x7f00)
+#defineHERMES_CMD_MACPORT  (0x0700)
+#defineHERMES_CMD_RECL (0x0100)
+#defineHERMES_CMD_WRITE(0x0100)
+#defineHERMES_CMD_PROGMODE (0x0300)
+#defineHERMES_CMD_CMDCODE  (0x003f)
 
 /*
  * STATUS register bitmasks
  */
-#defineHERMES_STATUS_RESULT((uint16_t)0x7f00)
-#defineHERMES_STATUS_CMDCODE   ((uint16_t)0x003f)
+#defineHERMES_STATUS_RESULT(0x7f00)
+#defineHERMES_STATUS_CMDCODE   (0x003f)
 
 /*
  * OFFSET refister bitmasks
  */
-#defineHERMES_OFFSET_BUSY  ((uint16_t)0x8000)
-#defineHERMES_OFFSET_ERR   ((uint16_t)0x4000)
-#defineHERMES_OFFSET_DATAOFF   ((uint16_t)0x0ffe)
+#defineHERMES_OFFSET_BUSY  (0x8000)
+#defineHERMES_OFFSET_ERR   (0x4000)
+#defineHERMES_OFFSET_DATAOFF   

Re: orinoco_cs & IrDA

[Jean Tourrilhes]

On Tue, Apr 24, 2001 at 03:56:37PM -0700, Jean Tourrilhes wrote:
> On Tue, Apr 24, 2001 at 03:15:08PM -0700, Jean Tourrilhes wrote:
> > 
> [...]
> > Downloaded the patch again (patch-2.4.4-pre6), checked that it
> > was complete, my patch is in. Oups ! Do I feel stupid...
> 
>   Let's finish this story. As indicated above, the first
> fragment of the patch I sent on month ago is in the kernel. The two
> other fragments didn't make it. They are attached...

Ok, now to the second chapter. These are all the changes
accumulated since the patch I sent one month ago (cf previous e-mail).
Changes :
o more Prism2/Symbol compatibility goodies
o Tested D-Link cards and Lucent firmware 7.28
o Cleanup, bug fixes from David Gibson
The whole is tested, as usual... 75% of the patch was on my
web pages for the last month and people seem to have liked it.

I've made 2 patches, one for 2.4.4-pre6 and one for
2.4.3-ac13. The difference between the two is minor (one line).

Linus : please have a look at orinoco_v4b.diff (first
attachement). Of course, this patch will apply and work only if you
have applied the patch in my previous e-mail.

Alan : orinoco_v4b-alan.diff is for you (second attachement).

Have fun...

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

CML2 Transition experiences

[jeff millar]

1. If I install CML2 and go directly to "make xconfig", it deduces it needs
to set top level options because some of the low level options are set.  For
example SCSI enabled because some SCSI device is set or hot plug because
PCMCIA is set...because some PCMCIA device is set.  The _problem_ is...none
of these options were set in the CML1 generated .config file... and it
_extremely_ tedious to use xconfig to clear out all the cruft.

A much better (but not yet right) way is to use "make ttyconfig" to quickly
generate config.out from .config  relatively fewer errors and ability to say
no at a top level and cause all the lower level stuff to go away.  make
ttyconfig seems to parse the .config file in a different (and better) order.

Suggestion:  On the first pass of CML2 processing through .config, before
first config.out created, trust the top level setting and ignore lower level
settings if top setting off.

2. So after some playing around, I want to go back to CML1.  But the .config
generated by CML2 is not compatible.  I don't know if it's supposed to be
but there's lots of problems.

Suggestion:  Save your .config before you play with this stuff.

Bottom line:  looks promising but I still haven't gotten a good compile from
it, yet.

jeff


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

Re: Linux 2.4.3ac13

[Andrzej Krzysztofowicz]

> 
> Also, I initially built ac13 with:
> 
>   make mrproper
>   make menuconfig
> 
> and it doesn't ask whether I want to build the normal USHI USB driver either as
> a module or builtin to the kernel, only whether I want to build the alternative
> USHI USB dirver (the JE driver).  Make xconfig asks whether you want to build
> both drivers.  I'm not sure whether this was a bug in previous versions or
> not.

It is an old problem, probably caused by ugly hack in drivers/usb/Config.in
(using a variable before it is defined).
The following patch should fix it in some way...


diff -u drivers/usb/Config.in~ drivers/usb/Config.in
--- drivers/usb/Config.in~  Sat Feb 10 23:16:30 2001
+++ drivers/usb/Config.in   Sat Feb 17 00:06:34 2001
@@ -22,6 +22,8 @@
fi
if [ "$CONFIG_USB_UHCI" != "y" ]; then
   dep_tristate '  UHCI Alternate Driver (JE) support' CONFIG_USB_UHCI_ALT 
$CONFIG_USB
+   else
+  define_bool CONFIG_USB_UHCI_ALT n
fi
dep_tristate '  OHCI (Compaq, iMacs, OPTi, SiS, ALi, ...) support' CONFIG_USB_OHCI 
$CONFIG_USB
 

Andrzej
-- 
===
  Andrzej M. Krzysztofowicz   [EMAIL PROTECTED]
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can't read SCSI TAPE

[Tim Moore]

> mt : mt-st v. 0.4

Also mt-st < v0.5b were fairly broken especially with positioning.

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

Re: 2.2.19 Realaudio masq problem

[Tim Moore]

I've been running masquerading unchanged from 2.2.13, currently 2.2.19 as:

real IP +
 masq. 192.168.1.NNN
DSL <-> gateway <-> switch <-> client 1
server <-> client 2
   ...
   <-> client n

There was some general slowness over the last few days (Bay Area, California
<-> US East Coast) including realaudio being unable to locate servers and/or
content.  This one is working right now:

RealPlayer v 7.0.3.338

abit:~ > cat On24ram.asp
rtsp://rm.on24.com/media/news/04192001/palumbo_ted6.rm
--stop--
http://rm.on24.com/media/news/04192001/palumbo_ted6.rm

Try '# strace /usr/bin/X11/realplay On24ram.asp > log' and see where the
connect fails if you aren't getting specific error messages.

rgds,
tim.

Whit Blauvelt wrote:
> 
> The Release Notes say "Fix problems with realaudio masquerading". Looked
> promising, since with 2.2.17 one masqueraded system (but not another) was
> having occassional problems with realaudio at some (but not all) sites.
> 
> Compiled 2.2.19 with 'make oldconfig,' no to new options. Otherwise running
> with the same firewall and masquerading settings (and yes I built and
> installed ip_masq_raudio.o). Masquerading is otherwise working, but now
> neither masqueraded system can connect with realaudio - the realplay routine
> to find a way to make a connection automatically fails for both.

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

Process start times moving in reverse on 2.4.x

[Phil Oester]

I've been having continual unexplained lockup problems since converting one
of my outgoing qmail servers to 2.4.x.  This has been discussed before on
this list, where the symptoms are that anything typed on console takes
forever to actually come up, and after a few minutes the machine is so
unresponsive it requires a powercycle.

Noticed that when this box is in its state of unresponsiveness, the process
start times in ps gradually move backwards.  The following listings were
taken over about a 1.5 hour timespan.

First
root 1 0  0 11:04 ?00:00:09 init
root 2 1  0 11:04 ?00:00:00 [keventd]
root 3 1  0 11:04 ?00:00:00 [kswapd]
root 4 1  0 11:04 ?00:00:00 [kreclaimd]
root 5 1  0 11:04 ?00:00:00 [bdflush]
root 6 1  0 11:04 ?00:00:02 [kupdated]
root96 1  0 11:06 ?00:00:00 [kreiserfsd]
root   356 1  0 11:06 ?00:00:02 syslogd -m 0
root   366 1  0 11:06 ?00:00:00 klogd
Second
root 1 0  0 10:54 ?00:00:09 init
root 2 1  0 10:54 ?00:00:00 [keventd]
root 3 1  0 10:54 ?00:00:00 [kswapd]
root 4 1  0 10:54 ?00:00:00 [kreclaimd]
root 5 1  0 10:54 ?00:00:00 [bdflush]
root 6 1  0 10:54 ?00:00:02 [kupdated]
root96 1  0 10:56 ?00:00:00 [kreiserfsd]
root   356 1  0 10:56 ?00:00:02 syslogd -m 0
root   366 1  0 10:56 ?00:00:00 klogd
Third
root 1 0  0 10:03 ?00:00:09 init
root 2 1  0 10:03 ?00:00:00 [keventd]
root 3 1  0 10:03 ?00:00:00 [kswapd]
root 4 1  0 10:03 ?00:00:00 [kreclaimd]
root 5 1  0 10:03 ?00:00:00 [bdflush]
root 6 1  0 10:03 ?00:00:02 [kupdated]
root96 1  0 10:06 ?00:00:00 [kreiserfsd]
root   356 1  0 10:06 ?00:00:02 syslogd -m 0
root   366 1  0 10:06 ?00:00:00 klogd
Fourth
root 1 0  0 09:53 ?00:00:09 init
root 2 1  0 09:53 ?00:00:00 [keventd]
root 3 1  0 09:53 ?00:00:00 [kswapd]
root 4 1  0 09:53 ?00:00:00 [kreclaimd]
root 5 1  0 09:53 ?00:00:00 [bdflush]
root 6 1  0 09:53 ?00:00:02 [kupdated]
root96 1  0 09:55 ?00:00:00 [kreiserfsd]
root   356 1  0 09:55 ?00:00:02 syslogd -m 0
root   366 1  0 09:55 ?00:00:00 klogd


Thoughts?

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

Event tools, do they exist

[george anzinger]

This is an attempt to look in the wheel locker.

I need a simple event sub system for use in the kernel.  I envision at
least two types of events: the history event and the timing event.

The timing event would keep track of start/stop times by class.  If, for
example, I wanted to know how much time the kernel spends doing the
recalc in schedule() I would put and event start in front of it and an
end at the other end.  The sub system would note the first event time
and the cumulative time between all starts and stops on the same event. 
When reported by /proc/ it would give the total event time, the elapsed
time and the % of processor time for each of the possibly several
classes.

The history event would record each events time, location, data1,
data2.  It would keep N of these (the last N) and report M (M=http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Single user linux

[Gerhard Mack]

On Wed, 25 Apr 2001, Daniel Stone wrote:

> OK. "time make bzImage". Of course, mine's really slow (and I will consider
> myself publically humiliated if my only Linux machine is beaten on a kernel
> compile by an iPAQ). I 'spose, if it only goes into suspend, the ability to
> write "uptime" on it constitutes a walking penis extension after a while?

When I first started I compiled my linux kernels on a 386 dx with 8 mb ram
heh.  I think a lot of the current PDAs are faster.

Gerhard


--
Gerhard Mack

[EMAIL PROTECTED]

<>< As a computer I find your faith in technology amusing.

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

Re: [PATCH] Single user linux

[Stuart Lynne]

In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>> > Quit being a naysayer. UNIX on a PDA is a wet dream.
>> What real value does it have, apart from the geek "look at me, I'm using
>> bash" value?
>
>It means I can do anything on my ipaq I can do anywhere else. I can run 
>multiple apps at a time. I can run X11. I can run the palm emulator even ;)
>
>Its the same reason Linux is valuable on an S/390 mainframe. Its a common pool
>of apps, environments and tools. Anything your PC can do, my ipaq can do.

Or even if you only ever use the builtin apps on your Linux PDA, it means you 
didn't subsidize Microsoft.

-- 
__O 
Lineo - For Embedded Linux Solutions  _-\<,_ 
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <[EMAIL PROTECTED]>   www.fireplug.net604-461-7532
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Single user linux

[Daniel Stone]

On Tue, Apr 24, 2001 at 05:35:10PM -0700, Aaron Lehmann wrote:
> On Wed, Apr 25, 2001 at 10:32:46AM +1000, Daniel Stone wrote:
> > True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a
> > tab! not space! you just broke my makefiles! aargh!), and compiling
> > Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA.
> > Hrmz.
> 
> I didn't say it was practical. But those PDA's are getting downright
> speedy. Much faster than UNIX workstations from days of old.

Please, oh please, tell me my machine would beat it on a "time make
bzImage". Else I'll do something really stupid. Like, get one for my
workstation and feel the improvement ;)
 
> Input is a big problem, but we'll leave that to technology (speech?
> microkeyboards?)

Aye - difference between space and tab. Broken Makefiles, anyone?

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

Re: [PATCH] Single user linux

[Daniel Stone]

On Wed, Apr 25, 2001 at 01:16:03AM +0100, Alan Cox wrote:
> > > Quit being a naysayer. UNIX on a PDA is a wet dream.
> > What real value does it have, apart from the geek "look at me, I'm using
> > bash" value?
> 
> It means I can do anything on my ipaq I can do anywhere else. I can run 
> multiple apps at a time. I can run X11. I can run the palm emulator even ;)

How long does it take you to write "date"? Plus, aren't you content with
IRCing on your *phone*? ;)
 
> Its the same reason Linux is valuable on an S/390 mainframe. Its a common pool
> of apps, environments and tools. Anything your PC can do, my ipaq can do.

OK. "time make bzImage". Of course, mine's really slow (and I will consider
myself publically humiliated if my only Linux machine is beaten on a kernel
compile by an iPAQ). I 'spose, if it only goes into suspend, the ability to
write "uptime" on it constitutes a walking penis extension after a while?

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

Re: [PATCH] Single user linux

[Aaron Lehmann]

On Wed, Apr 25, 2001 at 10:32:46AM +1000, Daniel Stone wrote:
> True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a
> tab! not space! you just broke my makefiles! aargh!), and compiling
> Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA.
> Hrmz.

I didn't say it was practical. But those PDA's are getting downright
speedy. Much faster than UNIX workstations from days of old.

Input is a big problem, but we'll leave that to technology (speech?
microkeyboards?)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Single user linux

[Daniel Stone]

On Tue, Apr 24, 2001 at 05:20:27PM -0700, Aaron Lehmann wrote:
> On Wed, Apr 25, 2001 at 10:07:48AM +1000, Daniel Stone wrote:
> > What real value does it have, apart from the geek "look at me, I'm using
> > bash" value?
> 
> I don't really want to get into it at the moment, but imagine hacking
> netfilter without lugging a laptop around. PDA's are sleek and cool,
> and using UNIX on them lets you write shell scripts to sort your
> addresses and stuff like that. Basically it's everything that's cool
> about Unix as a workstation OS scaled down to PDA-size.

True, but then imagine trying to hack C (no, that's a CURLY BRACE, and a
tab! not space! you just broke my makefiles! aargh!), and compiling
Netfilter (it takes HOW MANY hours to compile init/main.c?!?) on a PDA.
Hrmz.

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

Re: [PATCH] Single user linux

[Jonathan Lundell]

At 5:01 PM -0700 2001-04-24, Aaron Lehmann wrote:
>On Tue, Apr 24, 2001 at 11:38:01PM +1000, Daniel Stone wrote:
>> And UNIX on a phone is pure overkill.
>
>Quit being a naysayer. UNIX on a PDA is a wet dream.

http://www.agendacomputing.com/ (not that the reviews have been very kind)
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Mail boucing...

[Shawn Starr]

Sorry if my mail has been bouncing. I've been experimenting with some
configurations and I am moving tomorrow so my domain/IP will be changing.

Whoever, deleted me from list, thanks. Please don't block sh0n.net though
from posting.

I'll read myself when my new IP is added to my domain.

Thank you.
Shawn.


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

Re: [PATCH] Single user linux

[Aaron Lehmann]

On Wed, Apr 25, 2001 at 10:07:48AM +1000, Daniel Stone wrote:
> What real value does it have, apart from the geek "look at me, I'm using
> bash" value?

I don't really want to get into it at the moment, but imagine hacking
netfilter without lugging a laptop around. PDA's are sleek and cool,
and using UNIX on them lets you write shell scripts to sort your
addresses and stuff like that. Basically it's everything that's cool
about Unix as a workstation OS scaled down to PDA-size.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Single user linux

[Alan Cox]

> > Quit being a naysayer. UNIX on a PDA is a wet dream.
> What real value does it have, apart from the geek "look at me, I'm using
> bash" value?

It means I can do anything on my ipaq I can do anywhere else. I can run 
multiple apps at a time. I can run X11. I can run the palm emulator even ;)

Its the same reason Linux is valuable on an S/390 mainframe. Its a common pool
of apps, environments and tools. Anything your PC can do, my ipaq can do.

Alan

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

[PATCH] remove wakeup_bdflush(0) from __alloc_pages()

[Marcelo Tosatti]

Linus, 

Can you please apply the following patch ? 

It avoids allocators from waking up bdflush all the time even when it does
not have any job to do (ie no more than 30% (default) of dirty buffers). 

Thanks 

On Tue, 24 Apr 2001, Colonel wrote:

> From: Colonel <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> In-reply-to: <[EMAIL PROTECTED]>
>   (message from Marcelo Tosatti on Mon, 23 Apr 2001 20:31:12 -0300
>   (BRT))
> Subject: Re: 2.4.4-pre6 :  THANKS!  very snappy here [nt]
> Reply-to: [EMAIL PROTECTED]
> References:  <[EMAIL PROTECTED]>
> 
>Date: Mon, 23 Apr 2001 20:31:12 -0300 (BRT)
>From: Marcelo Tosatti <[EMAIL PROTECTED]>
>X-Sender: [EMAIL PROTECTED]
> 
> 
>Just as curiosity --- did it got faster in pre5 ? 
> 
>On Mon, 23 Apr 2001, Colonel wrote:
> 
>> but since you read it, system seems like it's running twice as fast
> 
> 
> Actually, it made not be pre6.  I patched the kernel per some thread
> on LKML a few days before, but had not had the opportunity to reboot
> and run it until pre6.  The patch was :
> 
> 
> --- linux/mm/page_alloc.c.~1~ Tue Mar 20 15:05:46 2001
> +++ linux/mm/page_alloc.c Sat Apr 21 19:01:47 2001
> @@ -454,7 +454,6 @@
>   if (gfp_mask & __GFP_WAIT) {
>   memory_pressure++;
>   try_to_free_pages(gfp_mask);
> - wakeup_bdflush(0);
>   goto try_again;
>   }
>   }
> 
> 
> It would make more sense that the above change was responsible for the
> improvement.
> 

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

2.2.19 Realaudio masq problem

[Whit Blauvelt]

The Release Notes say "Fix problems with realaudio masquerading". Looked
promising, since with 2.2.17 one masqueraded system (but not another) was
having occassional problems with realaudio at some (but not all) sites.

Compiled 2.2.19 with 'make oldconfig,' no to new options. Otherwise running
with the same firewall and masquerading settings (and yes I built and
installed ip_masq_raudio.o). Masquerading is otherwise working, but now
neither masqueraded system can connect with realaudio - the realplay routine
to find a way to make a connection automatically fails for both.

Please cc me, not subscribed.

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

Re: [PATCH] Single user linux

[Daniel Stone]

On Tue, Apr 24, 2001 at 05:01:18PM -0700, Aaron Lehmann wrote:
> On Tue, Apr 24, 2001 at 11:38:01PM +1000, Daniel Stone wrote:
> > And UNIX on a phone is pure overkill.
> 
> Quit being a naysayer. UNIX on a PDA is a wet dream.

What real value does it have, apart from the geek "look at me, I'm using
bash" value?

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

Re: [PATCH] Single user linux

[Aaron Lehmann]

On Tue, Apr 24, 2001 at 11:38:01PM +1000, Daniel Stone wrote:
> And UNIX on a phone is pure overkill.

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

Re: Linux 2.4.3ac13

[Michael Meissner]

On Tue, Apr 24, 2001 at 07:36:42PM -0400, Johannes Erdfelt wrote:
> On Tue, Apr 24, 2001, Michael Meissner <[EMAIL PROTECTED]> wrote:
> > and it doesn't ask whether I want to build the normal USHI USB driver either as
> > a module or builtin to the kernel, only whether I want to build the alternative
> > USHI USB dirver (the JE driver).  Make xconfig asks whether you want to build
> > both drivers.  I'm not sure whether this was a bug in previous versions or
> > not.
> 
> That's probably because you selected the alternative UHCI driver to
> build into the kernel. In that case, the other UHCI driver is not
> available as an option anymore. If you select it as a module, then both
> will be available.

Ummm, no.

As I said, I first cleaned everything out with mrproper, and then went through
the options in order.  Since the alternative UHCI driver does not occur until
after the question for the normal UHCI driver in drivers/usb/Configure.in, it
never asked me the question of building the normal UHCI driver.  I just
verified that if I use make xconfig instead of make menuconfig, I will be able
to choose either driver (yes, if you choose one as builtin, it won't allow you
to choose the other, but I'm talking about building them as modules, and the
initial selection after make mrproper is done).

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.4.3-ac14

[Alan Cox]

Oops forgot to update the text. This one is of course not just compile fixes

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

Re: Linux 2.4.3ac13

[Johannes Erdfelt]

On Tue, Apr 24, 2001, Michael Meissner <[EMAIL PROTECTED]> wrote:
> and it doesn't ask whether I want to build the normal USHI USB driver either as
> a module or builtin to the kernel, only whether I want to build the alternative
> USHI USB dirver (the JE driver).  Make xconfig asks whether you want to build
> both drivers.  I'm not sure whether this was a bug in previous versions or
> not.

That's probably because you selected the alternative UHCI driver to
build into the kernel. In that case, the other UHCI driver is not
available as an option anymore. If you select it as a module, then both
will be available.

JE

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

Re: [PATCH] Longstanding elf fix (2.4.3 fix)

[Eric W. Biederman]

Ion Badulescu <[EMAIL PROTECTED]> writes:

> On 23 Apr 2001 12:54:22 -0600, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> 
> > I'll include it again.  I had it attached as a plain text attachment,
> > I don't know if that is a problem or not.
> 
> Actually it was attached as text/x-patch, not as text/plain... so
> pine certainly refused to display it inline.

Interesting I'll have to play with that some time.  I really think
for basic display it should only care about the text part.  But
oh well.

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

Re: Linux 2.4.3ac13

[Michael Meissner]

On Tue, Apr 24, 2001 at 01:14:11AM +0100, Alan Cox wrote:
> 
>   ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
> 
>   Intermediate diffs are available from
> 
>   http://www.bzimage.org
> 
> This isnt a proper release as such, it should just deal with most of the 
> compile failure/symbol failure problems.
> 
> 2.4.3-ac13
> o Switch to NOVERS symbols for rwsem  (me)
>   | Called from asm blocks so they can't be versioned
> o Fix gcc 2.95 building on rwsem  (Niels Jensen)
> o Fix cmsfs build (Andrzej Krzysztofowicz)
> o Fix rio build/HZ setup  (Andrzej Krzysztofowicz)
> o Fix PPP filtering dependancy in config  (Andrzej Krzysztofowicz)

I just tried 2.4.3-ac13 on my laptop, a Toshiba Tecra 8000, which has a
NeoMagic video controller.  I boot it using the VESA frame buffer, using the
arguments:

video=vesa:mtrr vga=0x317

for a 16-bit 1024x768 screen.  The video doesn't come on at all, but the
machine boots up normally (ie, I can log into it via ssh via the wireless
pcmcia card).  If I boot up with the VGA console, the screen is displayed just
fine.  This worked in 2.4.3-ac11.

Also, I initially built ac13 with:

make mrproper
make menuconfig

and it doesn't ask whether I want to build the normal USHI USB driver either as
a module or builtin to the kernel, only whether I want to build the alternative
USHI USB dirver (the JE driver).  Make xconfig asks whether you want to build
both drivers.  I'm not sure whether this was a bug in previous versions or
not.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.4.3-ac14

[Alan Cox]

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

Intermediate diffs are available from

http://www.bzimage.org

This isnt a proper release as such, it should just deal with most of the 
compile failure/symbol failure problems.

2.4.3-ac14
o   Merge read-only veritas VxFS support(Christoph Hellwig)
o   Fix missing return in broken_apm_power  (Alex Riesen)
o   Remove bogus rwsem hacks from usbdevice_fs.h(Alex Riesen)
o   Fix umount/sync_inodes race (Al Viro)
o   Make new xircom driver report when promisc used (Arjan van de Ven)
o   Fix acenic PCI flag set up  (Phil Copeland)
o   Make nfs smart about passing max file sizes (Trond Myklebust)
o   Add initrd support to User Mode Linux   (Jeff Dike)
o   Fix timer irq race in User Mode Linux   (Jeff Dike)
o   Fix UML for semaphore changes   (Jeff Dike)
o   Update thw W9966 parallel port camera driver(Jakob Kemi)
o   Further dmfe SMP fixups (Tobias Ringstrom)
o   Kernel manual pages in man9 (Tim Waugh)
o   Work around BIOSes that implement E801 sizing
but don't implement the CX/DX values part   (Michael Miller)
o   Fix atp driver build(Arjan van de Ven)
o   Fix irda poll handling  (Dag Brattli)
o   Remove unused buggy pdc202xx code   (Arjan van de Ven)
o   Clean up iphase ATM (Arnaldo Carvalho
de Melo)
o   Setup slave PDC20265 controller on fasttrak (Arjan van de Ven)
as normal IDE
o   Add __init/__initdata to most net driver   (Andrzej Krzysztofowicz)
version info
o   SDDR09 config entry was missing (Phil Stracchino)
o   Configure.help NFS updates (Andrzej Krzysztofowicz)
o   Netfilter updates   (Rusty Russell and co)
o   Update 2.4 ipconfig to support dhcp (Eric Biederman)
o   es1371 setup updates/error check/pci bits   (Marcus Meissner)
o   Fix buzzing ymfpci  (Nick Brown)
o   Update nm256 audio driver   (Marcus Meissner)
o   Blacklist updates   (Arjan van de Ven)

2.4.3-ac13
o   Switch to NOVERS symbols for rwsem  (me)
| Called from asm blocks so they can't be versioned
o   Fix gcc 2.95 building on rwsem  (Niels Jensen)
o   Fix cmsfs build (Andrzej Krzysztofowicz)
o   Fix rio build/HZ setup  (Andrzej Krzysztofowicz)
o   Fix PPP filtering dependancy in config  (Andrzej Krzysztofowicz)

2.4.3-ac12
o   Rewrite the i2o post handling code to fix   (me)
DMA memory scribbles
o   Handle IOP constipation in the i2o_block layer  (me)
o   Fix bugs in the i2o table query causing reboots (me)
in i2o_proc on the DPT card
o   Add quirks for i2o cards that handle large I/O  (me)
queues badly [Promise supertrak100]
o   Add cache heuristics to the I2O block driver(me)
| We don't cache large writes (assume seq)
| We writeback small writes (random, metadata)
o   Disable use of writeback caching if there is(me)
no battery backup
o   Merge Linus 2.4.4pre6
o   Further semaphore fixes (David Howells)
o   Correct 'void main' to 'int main' in rtc doc(Jesper Juhl)
o   Hopefully fix bugtraq reported netfilter ftp
flaw
o   Fix unistd.h for ARM(Russell King)
o   Fix pre-emption of rt tasks (Nigel Gamble)
o   Fix revalidation bugs in cciss/cpqarray (Charles White)
when rereading partitions
o   Acenic updates  (Jes Sorensen)
o   Fix MAINTAINERS sort order  (David Woodhouse)
o   Restore DVDRAM fix with cdrom init fix too  (Jens Axboe)
o   Fix irda disconnect timeout bug (Dag Brattli)
o   Experimentally reap dead swap harder(Dave Miller)
o   Remove dead low mtu checks from drivers (Arnaldo Carvalho de
 Melo)
o   Add missing sk_chk_filter export(Byeong-ryeol Kim)
o   Quieten pci printks, send them to log   (Arjan van de Ven)
o   Hopefully fix fastrak oops  (me)

2.4.3-ac11
o   Merge Linus 2.4.4pre5
o   Back out problem dvdram changes
o   Make reiserfs use daemonize (Chris Mason)
o   Fix lvm map buglet  (Jens Axboe)
o   tms380 driver fixes 

#define HZ 1024 -- negative effects?

[Michael Rothwell]

Are there any negative effects of editing include/asm/param.h to change 
HZ from 100 to 1024? Or any other number? This has been suggested as a 
way to improve the responsiveness of the GUI on a Linux system. Does it 
throw off anything else, like serial port timing, etc.?

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

Re: [PATCH] adding PCI bus information to SCSI layer

[Jonathan Lundell]

At 3:59 PM -0600 4/24/01, Richard Gooch wrote:
>The plan I have (which I hope to get started on soon, now that I'm
>back from travels), is to change /dev/scsi/host# from a directory into
>a symbolic link to a directory called: /dev/bus/pci0/slot1/function0.
>Thus, to access a partition via location, one would use the path:
>/dev/bus/pci0/slot1/function0/bus0/target1/lun2/part3.

A minor PCI terminology point: PCI buses are subdivided into devices, not 
(necessarily) slots. So, for example, a multiple-device PCI card (say, two SCSI 
controllers) might have a PCI bridge creating a new bus, and two devices (not slots) 
on that bus. (It could alternatively be implemented as a single device with two 
functions,  given a dual-interface chip, but not necessarily.)

So a better name would be /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3 (taking the 
liberty of abbreviating some of the other names).

How, if at all, would RAID devices, using more than one physical device, or SCSI bus, 
or PCI card, fit into this naming scheme?


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

Re: [Semi-OT] Dual Athlon support in kernel

[Martin Clausen]

On Tue, Apr 24, 2001 at 01:22:15AM -0400, Mike A. Harris wrote:
> Also, what is a good rock solid SCSI RAID controller?  Money is
> no object.  Reliability, performance and Linux compatibility are
> though.

I have very good experiences with the Mylex controllers/drivers! 

But then again I also have good experiences with the new-style SW-RAID;
it performs very well indead and it is quite cheap :) 

Regards,
Martin

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

Re: compile error 2.4.4pre6: inconsistent operand constraints in an

[Colonel]

In list.kernel, axel <[EMAIL PROTECTED]> wrote:
>
>How about correcting the needed gcc version in Documentation/Changes?


Linux, with up to date documention??  In your dreams perhaps.


>On Mon, 23 Apr 2001, Alan Cox wrote:
>
>> > after having had trouble with compilation due to old gcc version, i have
>> > updated to gcc 3.0 and received the following error:
>> 
>> 2.4.4pre6 only builds with gcc 2.96. If you apply the __builtin_expect fixes
>> it builds and runs fine with 2.95. Not tried egcs. The gcc 3.0 asm constraints
>> one I've yet to see a fix for.


BTW.  The above attitude was fostered by informing the Changes
maintainer that the recommended NFS userspace server was on the
exploits list (back in the 2.0 kernel days when knfs was new) and
getting a "I don't use that, so what" response.

...and the documentation continued to recommend an exploitable NFS
server... in short: you must cross-check to be sure, at least in linux
you have a few more options.


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

Re: Linux 2.4.3ac13

[Alan Cox]

> === Cut ===
> [root@nomad /root]# depmod -ae
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.3ac13/kernel/drivers/net/aironet4500_card.o
> depmod: __bad_udelay
> === Cut ===

Yeah I need to change the __bad_udelay trick. The inline in inline case that
triggers a bad_udelay link wrongly is annoying but apparently not something
the gcc folks guarantee wont happen.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.3ac13

[Sergey Kubushin]

=== Cut ===
[root@nomad /root]# depmod -ae
depmod: *** Unresolved symbols in
/lib/modules/2.4.3ac13/kernel/drivers/net/aironet4500_card.o
depmod: __bad_udelay
=== Cut ===

---
Sergey Kubushin Sr. Unix Administrator
CyberBills, Inc.Phone:  702-567-8857
874 American Pacific Dr,Fax:702-567-8808
Henderson, NV 89014

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

Re: orinoco_cs & IrDA

[Jean Tourrilhes]

On Tue, Apr 24, 2001 at 03:15:08PM -0700, Jean Tourrilhes wrote:
> 
[...]
>   Downloaded the patch again (patch-2.4.4-pre6), checked that it
> was complete, my patch is in. Oups ! Do I feel stupid...

Let's finish this story. As indicated above, the first
fragment of the patch I sent on month ago is in the kernel. The two
other fragments didn't make it. They are attached...

wireless.v11b.diff :
--
Update the various wireless LAN driver in the kernel to
version 11 (definition already in the kernel). This update is
necessary to avoid crashes in the user space utilities.

orinoco_w11.diff :

Same deal for the new orinoco_cs driver.
I've also added the retry limit setting, but this feature is
not enabled (priv->has_retry = 0).


Alan : those two are already in your last kernel, please ignore.

Linus : those are not in your kernel.

That's it...

Jean


diff -u -p linux/drivers/net/wireless.25/wavelan.c linux/drivers/net/wavelan.c
--- linux/drivers/net/wireless.25/wavelan.c Wed Mar 28 17:27:27 2001
+++ linux/drivers/net/wavelan.c Wed Mar 28 17:28:34 2001
@@ -2028,8 +2028,17 @@ static int wavelan_ioctl(struct net_devi
if (wrq->u.data.pointer != (caddr_t) 0) {
struct iw_range range;
 
-   /* Set the length (useless:  it's constant). */
+   /* Set the length (very important for backward
+* compatibility) */
wrq->u.data.length = sizeof(struct iw_range);
+
+   /* Set all the info we don't care or don't know
+* about to zero */
+   memset(, 0, sizeof(range));
+
+   /* Set the Wireless Extension versions */
+   range.we_version_compiled = WIRELESS_EXT;
+   range.we_version_source = 9;
 
/* Set information in the range struct.  */
range.throughput = 1.6 * 1000 * 1000;   /* don't argue on this 
! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/wavelan_cs.c 
linux/drivers/net/pcmcia/wavelan_cs.c
--- linux/drivers/net/pcmcia/wireless.25/wavelan_cs.c   Wed Mar 28 17:21:02 2001
+++ linux/drivers/net/pcmcia/wavelan_cs.c   Wed Mar 28 17:23:19 2001
@@ -2239,8 +2239,15 @@ wavelan_ioctl(struct net_device *dev,/
{
  struct iw_range   range;
 
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
  wrq->u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know about to zero */
+ memset(, 0, sizeof(range));
+
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9;  /* Nothing for us in v10 and v11 */
 
  /* Set information in the range struct */
  range.throughput = 1.4 * 1000 * 1000; /* don't argue on this ! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/netwave_cs.c 
linux/drivers/net/pcmcia/netwave_cs.c
--- linux/drivers/net/pcmcia/wireless.25/netwave_cs.c   Wed Mar 28 17:24:40 2001
+++ linux/drivers/net/pcmcia/netwave_cs.c   Wed Mar 28 17:29:39 2001
@@ -710,8 +710,17 @@ static int netwave_ioctl(struct net_devi
if(wrq->u.data.pointer != (caddr_t) 0) {
   struct iw_range  range;
   
-  /* Set the length (useless : its constant...) */
+  /* Set the length (very important for backward compatibility) */
   wrq->u.data.length = sizeof(struct iw_range);
+
+  /* Set all the info we don't care or don't know about to zero */
+  memset(, 0, sizeof(range));
+
+#if WIRELESS_EXT > 10
+  /* Set the Wireless Extension versions */
+  range.we_version_compiled = WIRELESS_EXT;
+  range.we_version_source = 9; /* Nothing for us in v10 and v11 */
+#endif /* WIRELESS_EXT > 10 */
   
   /* Set information in the range struct */
   range.throughput = 450 * 1000;   /* don't argue on this ! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/ray_cs.c 
linux/drivers/net/pcmcia/ray_cs.c
--- linux/drivers/net/pcmcia/wireless.25/ray_cs.c   Wed Mar 28 17:21:57 2001
+++ linux/drivers/net/pcmcia/ray_cs.c   Wed Mar 28 17:30:16 2001
@@ -1332,8 +1332,14 @@ static int ray_dev_ioctl(struct net_devi
  struct iw_range   range;
  memset((char *) , 0, sizeof(struct iw_range));
 
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
  wrq->u.data.length = sizeof(struct iw_range);
+
+#if WIRELESS_EXT > 10
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9;

Re: 2.2.19 and file lock on NFS?

[Trond Myklebust]

> " " == apark  <[EMAIL PROTECTED]> writes:

 > Hi, Recently upgraded to 2.2.19, along with new
 > nfs-utils(0.3.1).  But I have a program that requires a
 > exclusive write lock on a NFSed directory.  When I was using
 > 2.2.17 all was ok, but now it returns ENOLCK.  Does anybody
 > else have the same problem?  Thanks

Hi,

You are probably failing to run the statd daemon or you may have set
up over-restrictive /etc/hosts.(allow|deny).

See the latest NFS-HOWTO for a full description on how to set up
locking.

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

Re: [PATCH] Longstanding elf fix (2.4.3 fix)

[Ion Badulescu]

On 23 Apr 2001 12:54:22 -0600, Eric W. Biederman <[EMAIL PROTECTED]> wrote:

> I'll include it again.  I had it attached as a plain text attachment,
> I don't know if that is a problem or not.

Actually it was attached as text/x-patch, not as text/plain... so
pine certainly refused to display it inline.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: hundreds of mount --bind mountpoints?

[Trond Myklebust]

> " " == Alexander Viro <[EMAIL PROTECTED]> writes:

 > _Ouch_. So what are you going to do if another iget4() comes
 > between the moment when you hash the inode and set these
 > fields? You are filling them only after you drop inode_lock, so
 > AFAICS the current code has the same problem.

The entire call to iget4() is protected by the BKL in all relevant
instances. As long as we don't sleep between find_inode() and
nfs_fill_inode(), we're safe.

In fact the BKL protection is needed also for another reason: we don't
actually initialize the inode in the I_LOCK-protected read_inode() but
instead rely on the caller of iget4 to do it for us. The reason is
that one we would need to pass the struct nfs_fattr to read_inode()
and this wasn't possible until the ReiserFS people introduced
read_inode2().

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

Re: [PATCH] properly detect ActionTec modem of PCI_CLASS_COMMUNICATION_OTHER

[Steven Walter]

On Tue, Apr 24, 2001 at 05:18:36PM -0400, Brian Gerst wrote:
> Steven Walter wrote:
> > 
> > This patch allows the serial driver to properly detect and set up the
> > ActionTec PCI modem.  This modem has a PCI class of COMMUNICATION_OTHER,
> > which is why this modem is not otherwise detected.
> > 
> > Any suggestions on the patch are welcome.  Thanks
> 
> A small suggestion:  Vendor/device id are sufficient to identify the
> device.  You can change PCI_CLASS_COMMUNICATION_OTHER << 8 to 0.

Excellent suggestion.  Follows is the amended patch.  Compiled and
tested to work.  BTW: patch is against 2.4.3.
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell

--- clean-2.4.3/drivers/char/serial.c   Fri Mar 30 23:15:33 2001
+++ linux/drivers/char/serial.c Tue Apr 24 16:32:02 2001
@@ -4706,6 +4728,8 @@
 
 
 static struct pci_device_id serial_pci_tbl[] __devinitdata = {
+   { PCI_VENDOR_ID_ATT, PCI_DEVICE_ID_ATT_VENUS_MODEM,
+ PCI_ANY_ID, PCI_ANY_ID, },
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
 PCI_CLASS_COMMUNICATION_SERIAL << 8, 0x00, },
{ 0, }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Compiled sound causes loss of scrollback console : 2.4.4-p6

[Colonel]

While tracking down a sound problem, I decided to compile in the
soundblaster rather than use modules.  It's been a long time since I
ran sound under linux, but that used to work fine.

I watched the reboot, noticed the usual isapnp stuff (part of problem)

...
PCI: Probing PCI hardware
Limiting direct PCI/PCI transfers.
Activating ISA DMA hang workarounds.
isapnp: Scanning for PnP cards...
isapnp: Calling quirk for 01:00
isapnp: SB audio device quirk - increasing port range
isapnp: Card 'Creative SB16 PnP'
isapnp: 1 Plug & Play card detected total
...

and then noticed that there were no soundblaster messages and tried to
scrollback to verify.  Pressing Shift-PageUp did absolutely nothing.

The only change was to move from modules to compiled for sound, OSS,
and soundblaster.  Booting the previous kernel(s) showed a working
scrollback.  2.4.4-pre6 compiled under gcc 2.95.3 20010315 release.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how does linux support domino?

[Jorge Nerin]

Xiong Zhao wrote:

> hello.on linux we will see a new domino server process/thread is created for each
> client.how does linux do this?does it use pthread?using fork or clone or someway 
> else?what's the common way of linux to support apps like lotus domino that will
> have lots of concurrent users which are served by seperate server process/thread?
> regards
> 
> james

Well, in Linux there is no separate concept of threads, so each thread
is a separate process with it's own PID and the PPID of the main thread.
In fact pthread_create() sits just on top of clone().

The way each program handles multiple conections is up to the program,
for example apache 1.3 and below does a fork(), mozilla does a
pthread_create(), BOA does a select() in only one process, and apache
2.0 and up does both a fork() and pthread_create().

-- 
Jorge Nerin
<[EMAIL PROTECTED]>


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

Re: orinoco_cs & IrDA

[Jean Tourrilhes]

On Tue, Apr 24, 2001 at 08:47:30PM +0100, Alan Cox wrote:
> > patch (without feedback), whereas Alan picked it up (if I remember
> > correctly it was included in his 'patch-2.4.2-ac28').
> > So now, what should I do with the rest of my updates and the
> > new one that have accumulated since ? Should I wait until you grab the
> > first patch from Alan's tree ? Should I send the new patches directly
> > to Alan so that he can accumulate a monster patch ? Should I just
> > accumulate the patches on my web page ?
> 
> Im happy to accumulate them but please send them to Linus too. I tend not to
> submit stuff on to Linus where there is an active maintainer and assume the
> maintainer will do it when ready.

Oups ! Big mea culpa ! Apologies.
While trying to compile my kernel, I've just realised the the
patch I've downloaded wasn't complete. My browser cut it in the middle
claiming that it was 100% complete.
Downloaded the patch again (patch-2.4.4-pre6), checked that it
was complete, my patch is in. Oups ! Do I feel stupid...

Apologies to everybody... Sorry for the confusion...

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

Re: hundreds of mount --bind mountpoints?

[Alexander Viro]

On 24 Apr 2001, Trond Myklebust wrote:

> Hi Al,
> 
>   I believe your patch introduces a race for the NFS case. The problem
> lies in the fact that nfs_find_actor() needs to read several of the
> fields from nfs_inode_info. By adding an allocation after the inode
> has been hashed, you are creating a window during which the inode can
> be found by find_inode(), but during which you aren't even guaranteed
> that the nfs_inode_info exists let alone that it's been initialized
> by nfs_fill_inode().

_Ouch_. So what are you going to do if another iget4() comes between
the moment when you hash the inode and set these fields? You are
filling them only after you drop inode_lock, so AFAICS the current
code has the same problem.

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

Re: hundreds of mount --bind mountpoints?

[Ingo Oeser]

On Tue, Apr 24, 2001 at 02:49:23PM -0400, Alexander Viro wrote:
> On Tue, 24 Apr 2001, Andreas Dilger wrote:
> > One thing to watch out for is that the current code zeros the u. struct
> > for us (as you pointed out to me previously), but allocating from the
> > slab cache will not...  This could be an interesting source of bugs for
> > some filesystems that assume zero'd inode_info structs.
> True, but easy to catch.

Jepp. Just request SLAB_ZERO (still to be implemented) instead of
SLAB_POISON or provide an constructor.

A nice set of macros for this would make it quite easy. The ctor
is the way to handle it. May be we could even put all the fs
specific initalizers into it (e.g. magics, zeroes).

Regards

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

Re: [PATCH] adding PCI bus information to SCSI layer

[Richard Gooch]

Matt Domsch writes:
> Thanks everyone for your input again.  I've made the changes suggested, and
> would appreciate this being applied to Linus' and Alan's trees.  This is
> necessary for solving the "what disk does BIOS think is my boot disk"
> problem on IA-64, and I hope to extend it to IA-32 when BIOSs permit.
> 
> Jeff Garzik recommended the IOCTL return pci_dev::slot_name, so now it does,
> and this simplifies the ioctl greatly.
> Doug Gilbert recommended wrapping things in #ifdef's, so I created a new
> CONFIG_SCSI_PCI_INFO define.

As I said to Matt privately, I think adding this kind of ioctl is
ugly. We have enough ioctl's as it is. All Matt is trying to do is to
access drives via location, so exposing location-based device nodes
via devfs is IMNSHO cleaner.

The plan I have (which I hope to get started on soon, now that I'm
back from travels), is to change /dev/scsi/host# from a directory into
a symbolic link to a directory called: /dev/bus/pci0/slot1/function0.
Thus, to access a partition via location, one would use the path:
/dev/bus/pci0/slot1/function0/bus0/target1/lun2/part3.

Regards,

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

Re: hundreds of mount --bind mountpoints?

[Trond Myklebust]

> " " == Alexander Viro <[EMAIL PROTECTED]> writes:

 > On Mon, 23 Apr 2001, Jan Harkes wrote:

>> On Mon, Apr 23, 2001 at 10:45:05PM +0200, Ingo Oeser wrote:

>> > BTW: Is it still less than one page? Then it doesn't make me
>> >nervous. Why? Guess what granularity we allocate at, if we
>> >just store pointers instead of the inode.u. Or do you like
>> >every FS creating his own slab cache?

 > Oh, for crying out loud. All it takes is half an hour per
 > filesystem.  Here - completely untested patch that does it for
 > NFS. Took about that long. Absolutely straightforward, very
 > easy to verify correctness.

 > Some stuff may need tweaking, but not much (e.g. some functions
 > should take nfs_inode_info instead of inodes, etc.). From the
 > look of flushd cache it seems that we would be better off with
 > cyclic lists instead of single-linked ones for the hash, but I
 > didn't look deep enough.

 > So consider the patch below as proof-of-concept. Enjoy:

Hi Al,

  I believe your patch introduces a race for the NFS case. The problem
lies in the fact that nfs_find_actor() needs to read several of the
fields from nfs_inode_info. By adding an allocation after the inode
has been hashed, you are creating a window during which the inode can
be found by find_inode(), but during which you aren't even guaranteed
that the nfs_inode_info exists let alone that it's been initialized
by nfs_fill_inode().

One solution could be to have find_inode sleep on encountering a
locked inode. It would have to be something along the lines of

static struct inode * find_inode(struct super_block * sb, unsigned long ino, struct 
list_head *head, find_inode_t find_actor, void *opaque)
{
struct list_head *tmp;
struct inode * inode;

tmp = head;
for (;;) {
tmp = tmp->next;
inode = NULL;
if (tmp == head)
break;
inode = list_entry(tmp, struct inode, i_hash);
if (inode->i_ino != ino)
continue;
if (inode->i_sb != sb)
continue;
if (find_actor) {
if (inode->i_state & I_LOCK) {
spin_unlock(_lock);
__wait_on_inode(inode);
spin_lock(_lock);
tmp = head;
continue;
}
if (!find_actor(inode, ino, opaque))
continue;
}
break;
}
return inode;
}


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

Re: PIO disk writes using 100% system time and performing poorly with VIA vt82c686b on kernels 2.2 & 2.4

[Francois Cami]

Ignacio Monge wrote:
> 
> Hi.
> I have  VIA686a too and a UDMA100 hard disk.

So do I.

> This is my cat /proc/ide/via:
> 
> --VIA BusMastering IDE Configuration
> Driver Version: 3.23
> South Bridge:   VIA vt82c686a
> Revision:   ISA 0x22 IDE 0x10
> Highest DMA rate:   UDMA66

> ---drive0drive1drive2drive3-
> Transfer Mode:DMA  UDMA   PIO   PIO
> Address Setup:   30ns  30ns 120ns 120ns
> Cmd Active:  90ns  90ns 480ns 480ns
> Cmd Recovery:30ns  30ns 480ns 480ns
> Data Active: 90ns  90ns 330ns 330ns
> Data Recovery:   30ns  30ns 270ns 270ns
> Cycle Time: 120ns  60ns 600ns 600ns
> Transfer Rate:   16.5MB/s  33.0MB/s   3.3MB/s   3.3MB/s

What is odd here is the 33MB/s on drive 1. If it was operating
at UDMA66, that would be more like 66MB/s (see my own /proc/ide/via).
I guess you should try putting a drive on IDEO as master and the
second on IDE1 (which seems empty) as master too. 

> As you can see, l use UDMA66 instead UDMA100. I don't know why. Maybe VIA 
> vt82c686a doesn't support it? I have answering in this list a days ago about this 
> problem. but none seems to have a question. 

686a maxes out at UDMA66. 686b does UDMA100.

> Like you, my system goes down when I try to compile so
> mething (I have a 394 Mb of RAM and a 1 Ghz processor).

I'm clueless, my 686a with IBM DTLA works fine (board is
ASUS A7V, kernel 2.4.3, Duron700, 256MB PC133). The new VIA 
IDE fixes in the kernel _might_ be the cause, but I'm not sure.

> Although, my hdparm output is this:
> /dev/hde2:
>  Timing buffer-cache reads:   128 MB in  0.79 seconds =162.03 MB/sec
>  Timing buffered disk reads:  64 MB in  2.44 seconds = 26.23 MB/sec
> and sometime looks better.
> 
> I don't know is this is a problem with the VIA kernel driver or not. But the
> system doesn't seem to work fine since 2.4.2 or 2.4.1 kernel. I hope (plz!) this
> problem will be fixed in future.
> Luck.
> 
> PS: in cat /proc/ide/via I see "Cable Type:   40w
>  >   40w"... Is it right? I have a 80w cable, not 40.
> 
> 

I see 80w in mine, maybe your cable is broken... Did you put the blue
end
of the cable on the motherboard ? Also detecting a 40w cable disables
UDMA66 I guess.


Here's my /proc/ide/via :

--VIA BusMastering IDE Configuration
Driver Version: 3.20
South Bridge:   VIA vt82c686a
Revision:   ISA 0x22 IDE 0x10
BM-DMA base:0xd800
PCI clock:  33MHz
Master Read  Cycle IRDY:0ws
Master Write Cycle IRDY:0ws
BM IDE Status Register Read Retry:  yes
Max DRDY Pulse Width:   No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush:  yes yes
End Sector FIFO flush: no  no
Prefetch Buffer:  yes  no
Post Write Buffer:yes  no
Enabled:  yes yes
Simplex only:  no  no
Cable Type:   80w 40w
---drive0drive1drive2drive3-
Transfer Mode:   UDMA   PIO   DMA   PIO
Address Setup:   30ns 120ns  60ns 120ns
Cmd Active:  90ns  90ns  90ns  90ns
Cmd Recovery:30ns  30ns  90ns  90ns
Data Active: 90ns 330ns  90ns 330ns
Data Recovery:   30ns 270ns  90ns 270ns
Cycle Time:  30ns 600ns 180ns 600ns
Transfer Rate:   66.0MB/s   3.3MB/s  11.0MB/s   3.3MB/s


François Cami

-- 

All that is gold does not glitter,
Not all those who wander are lost,
The old that is strong does not wither,
Deep roots are not touched by the frost.
From the ashes a fire shall be woken,
A light from the shadows shall spring,
Renewed shall the blade that was broken,
The crownless again shall be king.

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

Re: BUG: USB/Reboot

[Alan Cox]

> If USB is disabled on a server works MB reboots hang in 2.2.x

In almost all cases a hang after Linux reboots the system and it not coming
back to the BIOS is a BIOS bug.

You can confirm this by asking the kernel to do a real bios reboot with
the reboot= option
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] properly detect ActionTec modem of PCI_CLASS_COMMUNICATION_OTHER

[Brian Gerst]

Steven Walter wrote:
> 
> This patch allows the serial driver to properly detect and set up the
> ActionTec PCI modem.  This modem has a PCI class of COMMUNICATION_OTHER,
> which is why this modem is not otherwise detected.
> 
> Any suggestions on the patch are welcome.  Thanks

A small suggestion:  Vendor/device id are sufficient to identify the
device.  You can change PCI_CLASS_COMMUNICATION_OTHER << 8 to 0.

--

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

[PATCH] adding PCI bus information to SCSI layer

[Matt_Domsch]

Thanks everyone for your input again.  I've made the changes suggested, and
would appreciate this being applied to Linus' and Alan's trees.  This is
necessary for solving the "what disk does BIOS think is my boot disk"
problem on IA-64, and I hope to extend it to IA-32 when BIOSs permit.

Jeff Garzik recommended the IOCTL return pci_dev::slot_name, so now it does,
and this simplifies the ioctl greatly.
Doug Gilbert recommended wrapping things in #ifdef's, so I created a new
CONFIG_SCSI_PCI_INFO define.

Patches against 2.4.4-pre6 are available at http://domsch.com/linux/scsi/.
linux-2.4.4-pre6-scsi-pci-info-010424.patch - Adds the IOCTL and
CONFIG_SCSI_PCI_INFO, and touches a bunch of SCSI drivers.
scsimon_243_1_pci-010424.patch - Changes scsimon Makefile and sm_test.c to
support this.
scsimon_243_1_pci_driver.patch - Changes scsimon.[ch] to support this.

When this goes in, I request the assistance of the SCSI driver maintainers.
I've changed quite a few drivers, but couldn't easily see how to change a
few others.  I am bcc'ing the maintainers of drivers I changed or need help
from.

Drivers that I changed:

3w-.c   
AM53C974.c  
advansys.c  
aic7xxx_old.c   
atp870u.c   
cpqfcTSinit.c   
dmx3191d.c
fdomain.c   
gdth.c  
ips.c   
ncr53c8xx.c 
qla1280.c   
qlogicfc.c  
qlogicisp.c 
sym53c8xx.c 
tmscsim.c   
megaraid.c  
53c7,8xx.c  
pci2000.c   
pci2220i.c  


Non-trivial drivers that I didn't change, but request their
maintainers do so:

BusLogic.c  
aic7xxx.c   
eata.c  
eata_dma.c  
eata_pio.c  
ini9100u.c  
inia100.c   


Drivers I didn't need to change (they're not PCI devices, best as I can
tell):
NCR53C9x.c
NCR53c406a.c
aha152x.c
aha1542.c
aha1740.c
esp.c
fd_mcs.c
ibmmca.c
ide-scsi.c
imm.c
in2000.c
mac53c94.c
mesh.c
ppa.c
qlogicfas.c
qlogicpti.c
sgiwd93.c
sim710.c
sym53c416.c
u14-34f.c
ultrastor.c
53c7xx.c
a2091.c
a3000.c
atari_scsi.c
dtc.c
fcal.c
g_NCR5380.c
gvp11.c
mac_scsi.c
mvme147.c
pas16.c
pluto.c
psi240i.c
seagate.c
sun3_scsi.c
t128.c
wd7000.c


Thanks,
Matt

--
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

BUG: USB/Reboot

[Collectively Unconscious]

If USB is disabled on a server works MB reboots hang in 2.2.x

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

Re: hundreds of mount --bind mountpoints?

[Erik Mouw]

On Tue, Apr 24, 2001 at 12:47:38PM -0600, Andreas Dilger wrote:
> While I applaud your initiative, you made an unfortunate choice of
> filesystems to convert.  The iso_inode_info is only 4*__u32, as is
> proc_inode_info.  Given that we still need to keep a pointer to the
> external info structs, and the overhead of the slab cache itself
> (both CPU usage and memory overhead, however small), I don't think
> it is worthwhile to have isofs and procfs in separate slabs.

Well, I know a little bit about procfs because I'm currently
documenting it, so that's why I picked it first. After I got the idea,
isofs was quite easy.

In retrospect it would have been more effective to pick a filesystem
with a larger *_inode_info field, but then again: Al is right. Struct
inode is cluttered with *_inode_info fields, while we use anonymous
data entries in other parts of the kernel (like the data pointer in
struct proc_dir_entry, or the priv pointer in struct net_device).

There is another advantage: suppose you're hacking on a filesystem and
change it's *_fs_i.h header. With Al's proposal you only have to
recompile the filesystem you're hacking on, while you have to recompile
the complete kernel in the current situation.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Spurious interrupts for UP w/ IO-APIC on ServerWorks

[Jim Schutt]

Alan Cox wrote:

> > I've got a dual-processor system built around the Intel SBT2 motherboard, 
> > which uses the ServerWorks LE chipset. 2.4.3 SMP works fine. When I 
> > build a UP kernel with IO-APIC support, I get this during boot: 
> 
> Turn off the OSB4 driver - bet that helps 

It does -- no more spurious interrupts.

Thanks -- Jim

-- 
Jim Schutt  <[EMAIL PROTECTED]>
Sandia National Laboratories, Albuquerque, New Mexico USA

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

2001-04-24 release of hotplug scripts

[Greg KH]

I've just packaged up the latest Linux hotplug scripts into a release,
which can be found at:
http://sourceforge.net/project/showfiles.php?group_id=17679
 
This release adds the Debian scripts to the tarball, although all of the
debian specific changes were not merged into the main scripts, it would
have caused too much conflict, sorry.  But the Debian patch is now much
smaller :)  It also adds a hotplug manpage donated by Debian developer
Fumitoshi UKAI.

Numerous little changes were also added to the scripts, here is the full
changelog:
- added debian hotplug.8 manpage by Fumitoshi UKAI
- bugfixes to modprobing
- make sure setup scripts run even when there is no module
- "event not supported" only seen if debugging
- added debian directory filled with things needed to package
  the scripts for a debian release.
- make sure setup scripts (for usermode drivers/apps) will
  run even without a kernel driver
- bugfix match_flags support from Gioele Barabuci; might
  require bash2-isms
- add kernel 2.2.18 bcdDevice bug workaround (Ben Woodard)
- cleanups from Gioele Barabuci
- tweaked the post and preun sections to fix problem of hotplug
  not starting automatically when the package is upgraded.

I've built RedHat 6.x and 7.x specific rpms due to some small
differences in where the two version place their documentation.  The
individual releases are at:

For RedHat 6.x:

http://prdownloads.sourceforge.net/linux-hotplug/hotplug-2001_04_24-1_6.x.noarch.rpm

http://prdownloads.sourceforge.net/linux-hotplug/hotplug-2001_04_24-1_6.x.src.rpm

For RedHat 7.x:

http://prdownloads.sourceforge.net/linux-hotplug/hotplug-2001_04_24-1_7.x.noarch.rpm

http://prdownloads.sourceforge.net/linux-hotplug/hotplug-2001_04_24-1_7.x.src.rpm

Source tarball:
http://prdownloads.sourceforge.net/linux-hotplug/hotplug-2001_04_24.tar.gz


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

2.2.19 and file lock on NFS?

[apark]

Hi,

Recently upgraded to 2.2.19, along with new nfs-utils(0.3.1).
But I have a program that requires a exclusive write lock
on a NFSed directory.  When I was using 2.2.17 all was ok,
but now it returns ENOLCK.  Does anybody else have the
same problem?
Thanks

-Andrew

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

Re: sym53c875 error

[Gérard Roudier]

On Tue, 24 Apr 2001, Hamilton, Eamonn wrote:

> Hi Folks.
> 
> Under all of the kernels I have access to try ( 2.2.19, 2.4.X & 2.4.X-ac* ),
> when I try and write an image in XA2 format to my SCSI writer ( Yamaha
> CDR-400t ), I get a DMA overrun. When I try with a kernel patched with the
> beta symbios driver ( 2.1.9 ), it works just fine.

Interesting.

Note that sym-2.1.9 status is probably far better than beta. I just
haven't information enough to know how reliable this driver version
actually is. FYI, I use sym-2.1.x under Linux and FreeBSD since several
months. The NetBSD port is still work in progress, but the driver works
just fine for me under this O/S too.

> This is on a Debian woody system, using cdrecord 1.10 ( also 1.9 and 1.8
> with the same symptoms ) attached to a Tekram DC390F.
> 
> Transcript as follows :
> 
> cdrecord dev=0,3,0 -dummy -xa2 firmware.iso
> 
> Cdrecord 1.10a18 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jörg Schilling
> scsidev: '0,3,0'
> scsibus: 0 target: 3 lun: 0
> Linux sg driver version: 3.1.17
> Using libscg version 'schily-0.5'
> Device type: Removable CD-ROM
> Version: 2
> Response Format: 2
> Capabilities   :
> Vendor_info: 'YAMAHA  '
> Identifikation : 'CDR400t '
> Revision   : '1.0q'
> Device seems to be: Yamaha CDR-400.
> Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
> Driver flags   : SWABAUDIO
> Starting to write CD/DVD at speed 1 in dummy mode for single session.
> Last chance to quit, starting dummy write in 1 seconds.
> cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error
> CDB:  2A 00 00 00 01 C2 00 00 1F 00
> status: 0x0 (GOOD STATUS)
> DMA overrun, resid: -248

Would be interesting to know how cdrecord calculates the residual. It
should probably use the return value from read()/write(). Does it ?

> cmd finished after 0.579s timeout 40s
> write track data: error after 0 bytes
> Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00
> 
> 
> And while that lot happens, I get
> 
> sym53c875-0-<3,*>: target did not report SYNC.

This message is not normal given the device that for sure supports 
synchronous data transfers. I will look into this problem, first.

> sym53c875-0-<3,*>: extraneous data discarded.
> sym53c875-0-<3,*>: COMMAND FAILED (89 0) @c12a3800.

This one could have been triggerred by previous errors ???.

> Standard burns work ok, it's just the xa2 stuff I have a problem with so
> far. I also tried using the old NCR driver with the same results.

If you mean that the ncr53c8xx driver gets the same error, then the cause
can be a either common bug in sym53c8xx and ncr53c8xx, or caused by a
difference between sym53c8xx/ncr53c8xx and sym-2.1.9.

The main difference that comes to mind is that sym-2 uses the new error
handling interface but sym53c8xx/ncr53c8xx use the old one. If it is the
cause, then the sg driver might get involved in the failure.

> Anybody got any ideas?

No more than the above for now.
Will let you know if I get better ones.

Regards,
  Gérard.

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

Re: BUG: Global FPU corruption in 2.2

[Michal Jaegermann]

On Tue, Apr 24, 2001 at 06:56:32PM +0200, Christian Ehrhardt wrote:
> On Tue, Apr 24, 2001 at 09:10:07AM -0700, Linus Torvalds wrote:
> > ptrace only operates on processes that are stopped. So there are no
> > locking issues - we've synchronized on a much higher level than a
> > spinlock or semaphore.
> 
> This is only true for requests other than PTRACE_ATTACH and
> PTRACE_ATTACH is exactly what I'm worried about.

May I remind everybody that at the beginning of this thread I posted
another example, from an SMP Alpha, of FPU problems.  It certainly
was not exactly like the one under discussion but it looked that
it had a similar "smell" to it.

It looks like that to reproduce this Alpha example one needs processors
with a rather fast clock and this hardware version is not yet very
widely available.

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

Re: orinoco_cs & IrDA

[Alan Cox]

> patch (without feedback), whereas Alan picked it up (if I remember
> correctly it was included in his 'patch-2.4.2-ac28').
>   So now, what should I do with the rest of my updates and the
> new one that have accumulated since ? Should I wait until you grab the
> first patch from Alan's tree ? Should I send the new patches directly
> to Alan so that he can accumulate a monster patch ? Should I just
> accumulate the patches on my web page ?

Im happy to accumulate them but please send them to Linus too. I tend not to
submit stuff on to Linus where there is an active maintainer and assume the
maintainer will do it when ready.

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

Re: Spurious interrupts for UP w/ IO-APIC on ServerWorks

[Alan Cox]

> I've got a dual-processor system built around the Intel SBT2 motherboard,
> which uses the ServerWorks LE chipset.  2.4.3 SMP works fine.  When I 
> build a UP kernel with IO-APIC support, I get this during boot:

Turn off the OSB4 driver - bet that helps

> 2.4.3 has this behavior, 2.4.3-ac9 works fine. I found this in the -ac
> changelog; perhaps it's relevant:
> 
> > 2.4.2-ac12 
> [...]
> > o Remove serverworks handling. The BIOS is our (me) 
> > best (and right now only) hope for that chip 

Yep. Thats the bug fix you need.

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

Spurious interrupts for UP w/ IO-APIC on ServerWorks

[Jim Schutt]

Hi,

I've got a dual-processor system built around the Intel SBT2 motherboard,
which uses the ServerWorks LE chipset.  2.4.3 SMP works fine.  When I 
build a UP kernel with IO-APIC support, I get this during boot:

[... everything seems ok until ...]
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ServerWorks OSB4: IDE controller on PCI bus 00 dev 79
ServerWorks OSB4: chipset revision 0
ServerWorks OSB4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x0840-0x0847, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0x0848-0x084f, BIOS settings: hdc:DMA, hdd:DMA
spurious APIC interrupt on CPU#0, should never happen.
spurious APIC interrupt on CPU#0, should never happen.
hda: CD-ROM 52X/AKH, ATAPI CD/DVD-ROM drive
spurious APIC interrupt on CPU#0, should never happen.
spurious APIC interrupt on CPU#0, should never happen.
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
spurious APIC interrupt on CPU#0, should never happen.
spurious APIC interrupt on CPU#0, should never happen.
hda: lost interrupt
spurious APIC interrupt on CPU#0, should never happen.
hda: lost interrupt
hda: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Floppy drive(s): fd0 is 1.44M
spurious APIC interrupt on CPU#0, should never happen.
spurious APIC interrupt on CPU#0, should never happen.
floppy0: no floppy controllers found
Serial driver version 5.05 (2000-12-13) with MANY_PORTS SHARE_IRQ SERIAL_PCI
ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
SCSI subsystem driver Revision: 1.00
(scsi0)  found at PCI 1/4/0
(scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 392 instructions downloaded
(scsi1)  found at PCI 1/4/1
(scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs
(scsi1) Downloading sequencer code... 392 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
   
scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
   
scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0
Inquiry 00 00 00 ff 00 
spurious APIC interrupt on CPU#0, should never happen.
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
spurious APIC interrupt on CPU#0, should never happen.
SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
SCSI bus is being reset for host 0 channel 0.
[... repeat above 6 lines until I reset hw ...]


2.4.3 has this behavior, 2.4.3-ac9 works fine. I found this in the -ac
changelog; perhaps it's relevant:

> 2.4.2-ac12 
[...]
> o Remove serverworks handling. The BIOS is our (me) 
> best (and right now only) hope for that chip 

Here's the pertinent (I think) part of 2.4.3 .config:

CONFIG_MPENTIUMIII=y
CONFIG_X86_GOOD_APIC=y
# CONFIG_SMP is not set
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y

Details available on request.

Thanks -- Jim

-- 
Jim Schutt  <[EMAIL PROTECTED]>
Sandia National Laboratories, Albuquerque, New Mexico USA

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

Page_alloc / Swap 2.4.3 kernel BUG with system idle

[Raimondo Giammanco]

Here is a bug report in the format requested by linux/REPORTING-BUGS.

[1] Page_alloc / Swap 2.4.3 kernel BUG with system idle
[2] The System was idle for 1h or so while I was away, and coming
back I found it frozen. It was responding to ping, but telnet
and relogin weren't working. According to /var/log/messages,
it was running (   /sbin/rmmod -as) and (run-parts
/etc/cron.hourly).
Possibly it was running in background xmms but it was stopped, and
multiple nedit windows were active. Xscreensaver 3.28 from tar.gz
was running when I left the machine and it wasn't on when I came
back.
[3] Kernel Page_alloc/Swap
[4] Linux version 2.4.3 (gcc version 2.96 2731 (Red Hat Linux 7.0))
#2 SMP Sun  Apr 22 11:26:34 CEST 2001
[5] 
Apr 24 14:41:27 patagarro kernel: kernel BUG at page_alloc.c:73!
Apr 24 14:41:27 patagarro kernel: invalid operand: 
Apr 24 14:41:27 patagarro kernel: CPU:1
Apr 24 14:41:27 patagarro kernel: EIP:0010:[__free_pages_ok+35/800]
Apr 24 14:41:27 patagarro kernel: EFLAGS: 00010286
Apr 24 14:41:27 patagarro kernel: eax: 001f   ebx: c1122908   ecx:
0082   edx: 0100
Apr 24 14:41:27 patagarro kernel: esi: c1122908   edi:    ebp:
c3775aa0   esp: c30dfdf8
Apr 24 14:41:27 patagarro kernel: ds: 0018   es: 0018   ss: 0018
Apr 24 14:41:27 patagarro kernel: Process rubik (pid: 1576,
stackpage=c30df000)
Apr 24 14:41:27 patagarro kernel: Stack: c023ad4b c023ae79 0049
6212 c1044010 c0291e80 0206  
Apr 24 14:41:27 patagarro kernel:c1122908 c1122908 000f9000
c2a07c7c c012e2c5 c0a23620 c0101d1c d1936000 
Apr 24 14:41:27 patagarro kernel:c0110691 c1122908 00e1
c0121e25 c1122908 0225  0040 
Apr 24 14:41:27 patagarro kernel: Call Trace:
[free_page_and_swap_cache+197/208] [swapper_pg_dir+3356/4096]
[] [flush_tlb_all+17/96] [zap_page_range+453/624] []
[] 
Apr 24 14:41:27 patagarro kernel:[] []
[exit_mmap+201/304] [mmput+55/96] [do_exit+213/656]
[dequeue_signal+109/176] [do_signal+569/684] [sys_select+1138/1152] 
Apr 24 14:41:27 patagarro kernel:[sys_ioctl+521/528]
[signal_return+20/24] 
Apr 24 14:41:27 patagarro kernel: 
Apr 24 14:41:27 patagarro kernel: Code: 0f 0b 83 c4 0c 8b 73 08 85 f6 74
16 6a 4b 68 79 ae 23 c0 68 
Apr 24 14:45:40 patagarro kernel: kernel BUG at swap.c:183!
Apr 24 14:45:40 patagarro kernel: invalid operand: 
Apr 24 14:45:40 patagarro kernel: CPU:0
Apr 24 14:45:40 patagarro kernel: EIP:   
0010:[deactivate_page_nolock+184/336]
Apr 24 14:45:40 patagarro kernel: EFLAGS: 00013282
Apr 24 14:45:40 patagarro kernel: eax: 001a   ebx: c1122908   ecx:
   edx: 0002
Apr 24 14:45:40 patagarro kernel: esi: c1122908   edi: 0003   ebp:
0001   esp: cbf69fa0
Apr 24 14:45:40 patagarro kernel: ds: 0018   es: 0018   ss: 0018
Apr 24 14:45:40 patagarro kernel: Process kswapd (pid: 3,
stackpage=cbf69000)
Apr 24 14:45:40 patagarro kernel: Stack: c023a6eb c023a806 00b7
c1122924 c012cb79 c1122908 00010f00 c0296c80 
Apr 24 14:45:40 patagarro kernel:0006 0008e000 c012cef6
0006  c0105000 0008e000  
[6] No clue about the triggering effect
[7]
2 smp PII-350 linux box based on Gigabyte GA-6bxd ( chipset 440bx, bios
version f2).
4 dimm socket: 1 64 pc100, 1 128 pc100, 2 free.
Asus 3400tnt/tv 16 MB , agp 2X.

Other information in dmesg:

Linux version 2.4.3  (gcc version 2.96 2731 (Red Hat Linux 7.0)) #2
SMP Sun Apr 22 11:26:34 CEST 2001
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820:  - 0001 (reserved)
 BIOS-e820: 0010 - 0bff (usable)
 BIOS-e820: 0bff3000 - 0c00 (ACPI data)
 BIOS-e820: 0bff - 0bff3000 (ACPI NVS)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
found SMP MP-table at 000f5b30
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
On node 0 totalpages: 49136
zone(0): 4096 pages.
zone(1): 45040 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.1
Virtual Wire compatibility mode.
OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0
Processor #0 Pentium(tm) Pro APIC version 17
Floating point unit present.
Machine Exception supported.
64 bit compare & exchange supported.
Internal APIC present.
SEP present.
MTRR  present.
PGE  present.
MCA  present.
CMOV  present.
Bootup CPU
Processor #1 Pentium(tm) Pro APIC version 17
Floating point unit present.
Machine Exception supported.
64 bit compare & exchange supported.

Re: compile error 2.4.4pre6: inconsistent operand constraints in an

[Wayne . Brown]

With the __builtin_expect patch [EMAIL PROTECTED] posted, both
2.4.4-pre6 and 2.4.3-ac12 compile with egcs-2.91.66.  Also, 2.4.3-ac13 builds
without any further patches needed.

Wayne




Alan Cox <[EMAIL PROTECTED]> on 04/23/2001 05:58:47 PM

To:   [EMAIL PROTECTED] (axel)
cc:   [EMAIL PROTECTED] (bcc: Wayne Brown/Corporate/Altec)

Subject:  Re: compile error 2.4.4pre6: inconsistent operand constraints in an



> after having had trouble with compilation due to old gcc version, i have
> updated to gcc 3.0 and received the following error:

2.4.4pre6 only builds with gcc 2.96. If you apply the __builtin_expect fixes
it builds and runs fine with 2.95. Not tried egcs. The gcc 3.0 asm constraints
one I've yet to see a fix for.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/





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

Re: BUG: Global FPU corruption in 2.2

[Alan Cox]

> Alan Cox <[EMAIL PROTECTED]> writes:
> > The preferable one for performance is certainly to backport the 2.4 changes
> 
> Is it any more substantial than changing all uses of the ptrace flags
> to the new variable?

It affects asm blocks and offsets on some ports. Its not too bad tho

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

Re: BUG: Global FPU corruption in 2.2

[Victor Zandy]

Alan Cox <[EMAIL PROTECTED]> writes:

> The preferable one for performance is certainly to backport the 2.4 changes

Is it any more substantial than changing all uses of the ptrace flags
to the new variable?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkml]Re: Matrox FB console driver

[thunder7]

On Tue, Apr 24, 2001 at 06:19:31AM -0500, Andy Carlson wrote:
> time prime before x
> real1m23.535s
> user0m40.550s
> sys 0m42.980s
> 
> /proc/mtrr before x
> reg00: base=0x (   0MB), size= 256MB: write-back, count=1
> reg01: base=0xfd80 (4056MB), size=   4MB: write-combining, count=1
> 
> time prime after x
> real0m48.732s
> user0m41.070s
> sys 0m7.690s
> 
> /proc/mtrr after x
> reg00: base=0x (   0MB), size= 256MB: write-back, count=1
> reg01: base=0xfd80 (4056MB), size=   4MB: write-combining, count=1
> 
> time prime in X
> real0m42.835s
> user0m41.180s
> sys 0m1.710s
> 
Well, it isn't that.
Still, it was recently discussed that X might leave some settings in the
video-card (Matrox).

So I tried the following:

time spdtest.sh before X with spdtest.sh:

#!/bin/sh
i=1
while [ $i -lt 500 ]
do
   clear
   echo $i
   cat test.out;
   i=`expr $i + 1`
done

and after X, no change.
This is a G400/32 Mb with framebuffer @ 1600x1200x16bpp, and X 4.0.3,
same resolution. Kernel 2.4.3-ac12, Abit VP6 dual P3/866.

There was no significant change in any of the reported times.

I don't know. Your problem is interesting. Do other programs have this
too?

Jurriaan
-- 
And the gosts of hope walk silent halls
At the death of the promised land
All is gone, all is gone
But these changing winds can turn cold and hostile
New Model Army
GNU/Linux 2.4.3-ac12 SMP/ReiserFS 2x1743 bogomips load av: 0.00 0.03 0.01
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: hundreds of mount --bind mountpoints?

[Andreas Dilger]

Al writes:
> > Well, if we get rid of NFS (50 x __u32) and HFS (44 * __u32) (sizes are
> > approximate for 32-bit arches - I was just counting by hand and not
> > strictly checking alignment), then almost all other filesystems are below
> > 25 * __u32 (i.e. half of the previous size).
> 
> Yeah, but NFS suddenly takes 25+50 words... That's the type of complaints
> I'm thinking about.

But then again, you are saving 50-25 words for every non-NFS inode, and I
think _most_ systems will have more local inodes than NFS inodes.  Even
NFS servers will have local inodes, only clients (AFAIK) use nfs_inode_info.

> > Maybe the size of the union can depend on CONFIG_*_FS?  There should be
> > an absolute minimum size (16 * __u32 or so), but then people who want
> > reiserfs as their primary fs do not need to pay the memory penalty of ext2.
> > For ext2 (the next largest and most common fs), we could make it part of
> > the union if it is compiled in, and on a slab cache if it is a module?
> 
> NO. Sorry about shouting, but that's the way to madness. I can understand
> code depending on SMP vs. UP and similar beasts, but presense of specific
> filesystems 

But then again, if the size of nfs_inode_info changes, it is the same
problem... sizeof(struct inode) may have changed (depends if slab has
some padding between inodes or not).  If we stick to a minimum size
(16 words or maybe even 8), then it will never change anymore, and we
do not have overhead for small inode_info structs.

> > Should uncommon-but-widely-used things like socket and shmem have their
> > own slab cache, or should they just allocate from the generic size-32 slab?
> 
> That's pretty interesting - especially for sockets. I wonder whether
> we would get problems with separate allocation of these - we don't
> go from inode to socket all that often, but...

I never thought of that.  I guess the socket code does not know which
fs the inode_info was allocated from, so it cannot free it from the slab
(even if it had access to these slabs, which it does not).  In that case,
each fs would have struct socket as the minimum size allocatable, which
is unfortunately one of the largest inode_info sizes.  It is smaller
than ext2, but...

Any ideas?  Do we ever get back into fs-specific clear_inode() from
a socket?  In that case, the socket would just hold a pointer to the
fs-specific inode_info inside its own struct socket until the inode
is dropped.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OFFTOPIC] Re: [PATCH] Single user linux

[David =?ISO-8859-1?Q?G=F3mez]

On Tue, 24 Apr 2001, Tomas Telensky wrote:

> 
> But, what I should say to the network security, is that AFAIK in the most
> of linux distributions the standard daemons (httpd, sendmail) are run as
> root! Having multi-user system or not! Why? For only listening to a port
> <1024? Is there any elegant solution?
> 

httpd as root ? that's what i call a clueless network admin.
sendmail has an OBSOLETE design. Use a good MTA like qmail. Exim or
smail are ok, but they're still "sendmailish".


David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra


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

Re: Device Registry (DevReg) Patch 0.2.0

[Tim Jansen]

On Tuesday 24 April 2001 18:43, mirabilos wrote:
> What about indenting? I think of 0 spaces before the device name,
> 1 space before properties which belong to the device. 
> Structure per entry:
>[Space] Name colon property

But what is the advantage? Its not less work in the kernel, and in user-space 
you need to write a parser for this. You would have made a new format for 
hierarchical data that no one else uses only to avoid using XML in the 
kernel. 


> Is one level enough? I'm currently offline so didn't check the sample

No, for example for USB you have the levels 
devices/configurations/interfaces/endpoints. 

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

Re: hundreds of mount --bind mountpoints?

[Alexander Viro]

On Tue, 24 Apr 2001, Andreas Dilger wrote:

> While I applaud your initiative, you made an unfortunate choice of
> filesystems to convert.  The iso_inode_info is only 4*__u32, as is
> proc_inode_info.  Given that we still need to keep a pointer to the
> external info structs, and the overhead of the slab cache itself
> (both CPU usage and memory overhead, however small), I don't think
> it is worthwhile to have isofs and procfs in separate slabs.
> 
> On the other hand, sockets and shmem are both relatively large...
> Watch out that the *_inode_info structs have all of the fields
> initialized, because the union field is zeroed for us, but slab is not.

Frankly, I'd rather start with encapsulation part. It's easy to
verify, it can go in right now and it makes separate allocation
part uncluttered. Besides, it simply makes code cleaner, so it
makes sense even if don't want to go for separate allocation for
that particular fs.

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

Re: hundreds of mount --bind mountpoints?

[Alexander Viro]

On Tue, 24 Apr 2001, Andreas Dilger wrote:

> One thing to watch out for is that the current code zeros the u. struct
> for us (as you pointed out to me previously), but allocating from the
> slab cache will not...  This could be an interesting source of bugs for
> some filesystems that assume zero'd inode_info structs.

True, but easy to catch.
 
> Well, if we get rid of NFS (50 x __u32) and HFS (44 * __u32) (sizes are
> approximate for 32-bit arches - I was just counting by hand and not
> strictly checking alignment), then almost all other filesystems are below
> 25 * __u32 (i.e. half of the previous size).

Yeah, but NFS suddenly takes 25+50 words... That's the type of complaints
I'm thinking about.
 
> Maybe the size of the union can depend on CONFIG_*_FS?  There should be
> an absolute minimum size (16 * __u32 or so), but then people who want
> reiserfs as their primary fs do not need to pay the memory penalty of ext2.
> For ext2 (the next largest and most common fs), we could make it part of
> the union if it is compiled in, and on a slab cache if it is a module?

NO. Sorry about shouting, but that's the way to madness. I can understand
code depending on SMP vs. UP and similar beasts, but presense of specific
filesystems 

> Should uncommon-but-widely-used things like socket and shmem have their
> own slab cache, or should they just allocate from the generic size-32 slab?

That's pretty interesting - especially for sockets. I wonder whether
we would get problems with separate allocation of these - we don't
go from inode to socket all that often, but...

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

Re: hundreds of mount --bind mountpoints?

[Andreas Dilger]

Eric Mouw writes:
> Al is right, it is no rocket science. Here is a patch against
> 2.4.4-pre6 for procfs and isofs. It took me an hour to do because I'm
> not familiar with the fs code. It compiles, and the procfs code even
> runs (sorry, no CDROM player availeble on my embedded StrongARM
> system), though it is possible that there are some bugs in it.

While I applaud your initiative, you made an unfortunate choice of
filesystems to convert.  The iso_inode_info is only 4*__u32, as is
proc_inode_info.  Given that we still need to keep a pointer to the
external info structs, and the overhead of the slab cache itself
(both CPU usage and memory overhead, however small), I don't think
it is worthwhile to have isofs and procfs in separate slabs.

On the other hand, sockets and shmem are both relatively large...
Watch out that the *_inode_info structs have all of the fields
initialized, because the union field is zeroed for us, but slab is not.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

orinoco_cs & IrDA

[Jean Tourrilhes]

Hi Linus,

I've got a question... I would like where to send my driver
patches...

One month ago, I sent a small update for the orinoco_cs driver
and Wireless Extensions. I didn't put all the changes I had for
orinoco_cs because I believe in small incremental updates limited to a
specific area (even if all the changes are trivial). You ignored my
patch (without feedback), whereas Alan picked it up (if I remember
correctly it was included in his 'patch-2.4.2-ac28').
So now, what should I do with the rest of my updates and the
new one that have accumulated since ? Should I wait until you grab the
first patch from Alan's tree ? Should I send the new patches directly
to Alan so that he can accumulate a monster patch ? Should I just
accumulate the patches on my web page ?

Another day, I will also tell you about the IrDA patches...

Have fun...

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

Re: hundreds of mount --bind mountpoints?

[Andreas Dilger]

Al writes:
> Encapsulation part is definitely worth doing - it cleans the code up
> and doesn't change the result of compile. Adding allocation/freeing/
> cache initialization/cache removal and chaninging FOOFS_I() definition -
> well, it's probably worth to keep such patches around, but whether
> to switch any individual filesystem during 2.4 is a policy decision.
> Up to maintainer, indeed. Notice that these patches (separate allocation
> per se) are going to be within 3-4Kb per filesystem _and_ completely
> straightforward.

One thing to watch out for is that the current code zeros the u. struct
for us (as you pointed out to me previously), but allocating from the
slab cache will not...  This could be an interesting source of bugs for
some filesystems that assume zero'd inode_info structs.

Fortunately, it doesn't appear that my patch to clean out all of the
"duplicate" zero initializers in the fs-specific code was accepted...

> What I would like to avoid is scenario like:
> 
> Maintainers of filesystems with large private inodes: Why would we separate
> them? We would only waste memory, since the other filesystems stay in ->u
> and keep it large.

Well, if we get rid of NFS (50 x __u32) and HFS (44 * __u32) (sizes are
approximate for 32-bit arches - I was just counting by hand and not
strictly checking alignment), then almost all other filesystems are below
25 * __u32 (i.e. half of the previous size).

For large-private-inode filesystems, we are wasting memory in EVERY inode
in the slab cache, not just ones in use with the large private inode.  If
it were the most common filesystem (ext2, maybe reiser, msdos next) then
it wouldn't make much difference.

At some point reducing the union size is not efficient to have separate
slab allocations from a memory usage standpoint.

The remaining info structs are (approx. for 32-bit arch) (size in __u32):

ext227
affs26
ufs 25
socket  24
shmem   22
coda20
qnx418

minix   16
umsdos  15
hpfs15
efs 14
sysv13
reiser  12
udf 12
ntfs11
ncp 10
msdos   9
adfs7
smb 6
usbdev  5
proc4
iso 4
bfs 3
romfs   2


> Maintainers of the rest of filesystems: Since there's no patches that would
> take large stuff out of ->u, why would we bother?

Maybe the size of the union can depend on CONFIG_*_FS?  There should be
an absolute minimum size (16 * __u32 or so), but then people who want
reiserfs as their primary fs do not need to pay the memory penalty of ext2.
For ext2 (the next largest and most common fs), we could make it part of
the union if it is compiled in, and on a slab cache if it is a module?

Should uncommon-but-widely-used things like socket and shmem have their
own slab cache, or should they just allocate from the generic size-32 slab?

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Single user linux

[Garett Spencley]

> that also explain why win95 user doesn't want to use NT. not
> because they can't afford it (belive me, here NT costs only
> us$2), but additional headache isn't acceptable.

I'm going to speak from experience:

My mother, who is the biggest windoze fan on the face of the universe, got
fed up with win98 and decided to move to win2k. The hole "multi-user" thing
doesn't bother her in the slightest. She has a non-admin account for
herself "karen".

You want a better example?

My little cousin is not much into computers but he uses one enough to check
mail, surf the web etc... Like many win98 users he was re-installing it
about once a month. He finally got so fed up he asked me to install Linux
for him!

He is now very happy. He doesn't care about the fact that he has to type
in his user name. He even doesn't know any shell commands. He would
probably actually get concerned if he had to use root always because that
would reveal the same problems that he was having with win98.

There's a lot of things you can do to make Linux easier for newbies. None
of them involve hacking the kernel. Have you tried Linux-Mandrake 8.0 yet?

-- 
Garett Spencley

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

Re: BUG: Global FPU corruption in 2.2

[Alan Cox]

> > child->flags |= PF_PTRACED; 
> > 
> > without waiting for the child to have stopped. 
> 
> I can see how this could case PF_USEDFPU to be cleared inadvertently,
> but I do not have any ideas for testing this.  Is it clear that this
> is the source of the problem?

There is no guarantee that |= is implemented atomically - in fact its quite
likely to read

get child->flags
or PF_PTRACED
write child->flags

and a PF_USEDFPU on another processor at the same instant -would- end up being
lost.

There are two fixes

1.  Make all the ops atomic (foo_bit())
2.  Split the flags

The preferable one for performance is certainly to backport the 2.4 changes

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

Problem with DHCP when using tokenring on 2.4.x

[mshiju]

Hello,
   I have a problem with DHCP when using tokenring card on 2.4.x
kernel . When I am using IBM tokenring adapter( all) and trying to hook on
to the lan n/w using DHCP ,I get an error message "operation failed " from
the dhcp client . The dhcp server is getting the broadcast message when the
dhcp client  is run. I am using pump that comes with 6.2 redhat
distribution .  There is no problem when using static IP.  I could
experience this problem only  on 2.4.x . I am able to get a valid IP
address on  2.2.x kernel when using tokenring adapter. And also there is no
problem when using ethernet adapter on 2.4.x . . Has anyone experienced
this problem on 2.4.x . Can any one help me to resolve this problem.

Thanks & Regards
Shiju


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

Re: Device Registry (DevReg) Patch 0.2.0

[Tim Jansen]

On Tuesday 24 April 2001 18:39, Martin Dalecki wrote:
> Are there alternatives to get complex and extendable information out to 
> user space?
> Yes filesystem structures. 


How exactly can this work? A single value per file is not very helpful if you 
have a thousand values. You could cluster them (for example one level in the 
XML hierarchy == one file), but this will soon get very complicated. Its much 
more work to implement in the kernel, its painful in user-space and you cant 
just use a text editor to look at it (because you always have to look at 10 
files per device). 
IMHO only a single XML file per physical device is an option, but I do not 
know how to name the files...


> Or just simple parsing in the user space plain binary data.

This would be a compatibility nightmare and hard to maintain. Once you 
decided for a binary format you cannot change or extend it without breaking 
user-space apps. This may save a few lines code, but not many. All you need 
to add a line to XML output is a sprintf and a call to devreg_write_line(). 

One of the ideas of devreg is that while it has a common format for generic 
information, like the name and topology of physical devices, every driver can 
add additional data (this is why XML namespaces are used). Currently only the 
USB and PCI subsystems add data to devreg, but in future versions the device 
driver itself or other subsystems should do this, too. 

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

Re: BUG: Global FPU corruption in 2.2

[Victor Zandy]

Linus Torvalds writes:
> Ahh.. This actually _does_ look like a race on "current->flags": 
> PTRACE_ATTACH will do a 
> 
> child->flags |= PF_PTRACED; 
> 
> without waiting for the child to have stopped. 

I can see how this could case PF_USEDFPU to be cleared inadvertently,
but I do not have any ideas for testing this.  Is it clear that this
is the source of the problem?

What would be involved in backporting the split ptrace flags to 2.2?
Are there other solutions?

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

Re: Greetings!

[Matti Aarnio]

On Tue, Apr 24, 2001 at 02:03:44PM -0400, Richard B. Johnson wrote:
> On Tue, 24 Apr 2001, Chin-Tser Huang wrote:
> > Because there was a mail whose subject is "Children first in fork".
> 
> Gotta watch out for source-code that uses a 'reaper' to kill children
> from SIGCHLD. We'll get auto-mail from pervert.snuffer.com.

:-)I added  "@safestory.com" to be forbidden in headers.
This topic WILL die  ;)

> Cheers,
> Dick Johnson

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

Re: BUG: Global FPU corruption in 2.2

[Victor Zandy]

"Christian Ehrhardt" <[EMAIL PROTECTED]> writes:
> Victor: Could you try to reproduce the system wide corruption if you
> add an explicit call to stts(); at the very end of __switch_to?
> This should prevent the FPU corruption from spreading.

After adding this call, I cannot reproduce the global corruption.
There is still occasional local corruption of individual pi processes
while pt is running.

Vic




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

Re: Greetings!

[Richard B. Johnson]

On Tue, 24 Apr 2001, Chin-Tser Huang wrote:

> Because there was a mail whose subject is "Children first in fork".
> 

Gotta watch out for source-code that uses a 'reaper' to kill children
from SIGCHLD. We'll get auto-mail from pervert.snuffer.com.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: Greetings!

[Rik van Riel]

On Tue, 24 Apr 2001, Chin-Tser Huang wrote:

> Because there was a mail whose subject is "Children first in fork".

> > 1 in 6 children are victimized before the age of 16.

Considering these statistics, I'm all for running children
first after fork ...

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

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

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

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

Re: [PATCH] Single user linux

[J Sloan]

[EMAIL PROTECTED] wrote:

> hi,
>
> a friend of my asked me on how to make linux easier to use
> for personal/casual win user.
>
>
> from that, i also found out that it is very awkward to type
> username and password every time i use my computer.
> so here's a patch.

Neet hack, but maybe the kernel isn't the best
place to do this -

For instance, you can simply use the KDE 2.1.1 login
manager, with the current kernel intact, to automatically
log in and start the X session of a specific user, upon
entering runlevel 5 -

Might this not be a better direction?

cu

jjs

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

Re: Greetings!

[Chin-Tser Huang]

Because there was a mail whose subject is "Children first in fork".

On Tue, 24 Apr 2001 [EMAIL PROTECTED] wrote:

>
>
> well... the book sounds good...
> but... I am still thinking... what it has to do with linux kernel ??
>
>
>
>
> [EMAIL PROTECTED] on 04/24/2001 04:27:56 PM
>
> To:   [EMAIL PROTECTED]
> cc:(bcc: Amol Lad/HSS)
>
> Subject:  Greetings!
>
>
>
>
>
> 1 in 6 children are victimized before the age of 16.
>
> Hello, my name is Jason Colgan and I am writing to you about my father's unique
> book on child safety.
>
> I hope you don't mind me emailing you, but I found your email address on a
> website that was related to children, so I figured you would definitely be
> interested in this.
>
> My father, a retired police Captain, authored a children's book using his unique
> experience with child safety.  My father has investigated, arrested and taken
> confessions from child molesters, kidnappers, murderers and some of the most
> dangerous people in the world.  He often spoke and interacted with them before
> they had the chance to speak with lawyers or others, so he was able to gain an
> honest understanding of the way they think and the manner in which they
> victimize children.
>
> My father put his 23 years of experience to work for a good cause and developed
> a children's book, written in a storybook fashion starring a small family of
> bunnies.  The book has already caused quite a stir and has been featured in
> local newspapers and even the news.  Even more important, the people who have
> purchased the book love it and so do their children.  It truly presents a
> simplified way to educate your child on matters that are difficult for parents,
> grandparents, or guardians to discuss.
>
> I would like you to learn more about my father's book by visiting
> www.SafeStory.com
>
> If you are curious to see what others think, there is a link on that web site
> which has some customer opinions and even shows you the write-ups the book has
> received on Amazon.com.
>
> Thank you so much for your time and if you have any questions at all, please
> email me or call and I would love to answer them!
>
> My sincerest thanks,
> Jason
>
>
> http://www.SafeStory.com
>
>
> P.S. Please email me at [EMAIL PROTECTED] or call me anytime. My home phone number
> is 401-463-2856.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

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

Problem with DHCP when using tokenring on 2.4.x

[mshiju]

Hello,
   I have a problem with DHCP when using tokenring card on 2.4.x
kernel . When I am using IBM tokenring adapter( all) and trying to hook on
to the lan n/w using DHCP ,I get an error message "operation failed " from
the dhcp client . The dhcp server is getting the broadcast message when the
dhcp client  is run. I am using pump that comes with 6.2 redhat
distribution .  There is no problem when using static IP.  I could
experience this problem only  on 2.4.x . I am able to get a valid IP
address on  2.2.x kernel when using tokenring adapter. And also there is no
problem when using ethernet adapter on 2.4.x . . Has anyone experienced
this problem on 2.4.x . Can any one help me to resolve this problem.

Thanks & Regards
Shiju


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

Re: [PATCH] Single user linux

[Russell King]

On Tue, Apr 24, 2001 at 07:44:17PM +0700, [EMAIL PROTECTED] wrote:
> come on, it's hard for me as it's hard for you. not everybody
> expect a computer to be like people here thinks how a computer
> should be.

I'm sorry, you're looking at the problem the wrong way around.
Its not a kernel problem, but a user space problem.

> think about personal devices. something like the nokia communicator.
> a system security passwd is acceptable, but that's it. no those-
> device-user would like to know about user account, file ownership,
> etc. they just want to use it.

If you do everything as one user, then you are effectively in a
single-user mode.  Just make sure that the user owns all the files
that they might need.

Your change still doesn't get rid of the /bin/login program - you still
have to do that, so why not do it anyway?

Also, I know of no personal device that gives you access to system
software (which is effectively what giving a user 'root' access
gives you).  How many users do you know who can copy the firmware
in their phone or organiser?

> that also explain why win95 user doesn't want to use NT. not
> because they can't afford it (belive me, here NT costs only
> us$2), but additional headache isn't acceptable.

I'm sorry, that's a different problem, and _even_ Windows 95 and 98
has a "User Logon".  Only if you use the system in a single user mode
does it not have a logon.  You can do the same with Linux again
without making kernel modifications.

I'd like to point out that RedHat have thought about this, and they
have some of the infrastructure in there to automatically log you
on at boot time in (within X).

As I say, this is a user space issue, and distributions are addressing
it adequately.

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

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

Re: PIO disk writes using 100% system time and performing poorly with VIA vt82c686b on kernels 2.2 & 2.4

[Ignacio Monge]

Hi.
I have  VIA686a too and a UDMA100 hard disk.
This is my cat /proc/ide/via:

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


As you can see, l use UDMA66 instead UDMA100. I don't know why. Maybe VIA 
vt82c686a doesn't support it? I have answering in this list a days ago about this 
problem. but none seems to have a question. Like you, my system goes down when I try 
to compile something (I have a 394 Mb of RAM and a 1 Ghz processor).
Although, my hdparm output is this:
/dev/hde2:
 Timing buffer-cache reads:   128 MB in  0.79 seconds =162.03 MB/sec
 Timing buffered disk reads:  64 MB in  2.44 seconds = 26.23 MB/sec
and sometime looks better.

I don't know is this is a problem with the VIA kernel driver or not. But the 
system doesn't seem to work fine since 2.4.2 or 2.4.1 kernel. I hope (plz!) this 
problem will be fixed in future.
Luck.

PS: in cat /proc/ide/via I see "Cable Type:   40w  
   40w"... Is it right? I have a 80w cable, not 40.


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

Re: [OFFTOPIC] Re: [PATCH] Single user linux

[Markus Schaber]

Hello,

On Tue, 24 Apr 2001, Alan Cox wrote:

> > Now, in order for step 4 to be done safely, procmail should be running
> > as the user it's meant to deliver the mail for. for this to happen
> > sendmail needs to start it as that user in step 3 and to do that it
> > needs extra privs, above and beyond that of a normal user.
>
>   email -> sendmail
>   sendmail 'its local' -> spool
>
> user:
>   get_mail | procmail
>   mutt
>
> The mail server doesnt need to run procmail. If you wanted to run mail batches
> through on a regular basis you can use cron for it, or leave a daemon running

Oh, well, cron is just another suid program.

This example would just be the ideal scenario for posix- or novell-style
ACLs in the filesystem.

You run the MDA/MTA under some mailerdaemon uid. And then a user can
explicitly give this daemon read access to .procmail etc. You can also
give the MTA (and nobody else) write access to /var/spool/mail. The MDA
then gives the specifical user full access to the spoolfile when creating
it, or adding mail to it. And the user can fetch his mail and truncate or
delete the file just as he and his software is used to.

There are much more things with ACLs, especially in workgroup environments
(That's why I loved the old Novel server in our university), but they
never got into the kernel.  And as far as I (as a non-hacker) understand,
the fields reserved for this feature were dropped for the large file
support, so we may never see ACLs.

Gruß,
Markus
-- 
| Gluecklich ist, wer vergisst, was nicht aus ihm geworden ist.
+---. ,>
http://www.uni-ulm.de/~s_mschab/ \   /
mailto:[EMAIL PROTECTED]  \_/


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

Kernel Oops when using the Netfilter QUEUE target

[Martin Clausen]

Hi there!

I have encountered a problem (perhaps a bug)! The attached code makes my kernel oops
in some cases when injecting new packets through Netfilter's QUEUE target. The problem 
only appears when the original packet is a TCP packet; i have tried with ICMP and UDP 
packets 
also but this does not trigger any oops. I have tried to code on several computers and 
they 
all oops. The following description regards the case when submitting new packets 
instead 
of TCP packets.

It seems that new packets can not have a length greater than 92 bytes under 2.4.2-ac21
and 76 under 2.4.3; these sizes may vary but the oops can be triggered by choosing
a larger packet size.

Netfilter is configured the following way:

[root@lwb7 ipsecd]# modprobe iptable_filter
[root@lwb7 ipsecd]# modprobe ip_queue  
[root@lwb7 ipsecd]# iptables -t mangle -A OUTPUT -d lwb5 -j LOG
[root@lwb7 ipsecd]# iptables -t mangle -A OUTPUT -d lwb5 -j QUEUE
[root@lwb7 ipsecd]# lsmod
Module  Size  Used by
ipt_LOG 4063   1  (autoclean)
iptable_mangle  2542   0  (autoclean) (unused)
ip_queue5946   0  (unused)
iptable_filter  2533   0  (unused)
ip_tables  14936   3  [ipt_LOG iptable_mangle iptable_filter]
NVdriver  688003  12  (autoclean)
8139too16845   1  (autoclean)
[root@lwb7 ipsecd]# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source   destination 

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination 
LOGall  --  anywhere lwb5.it.dtu.dk LOG level warning 
QUEUE  all  --  anywhere lwb5.it.dtu.dk  

I have added some printk's in net/code/netfilter.c in nf_reinject() and i seems that
the kernel oops' in info->okfn(skb) (i added printk before and after):

IN= OUT=eth0 SRC=130.225.76.37 DST=130.225.76.35 LEN=60 TOS=0x00 PREC=0x00 TTL=64 
ID=173 PROTO=TCP SPT=1025 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0
nf_hook: Verdict = QUEUE. 
In nf_reinject() before info->okfn(skb) line 521  
Unable to handle kernel NULL pointer dereference at virtual address 02b4   
printing eip:
c01e7456  
*pde = 
   
  
Entering kdb (current=0xc68f6000, pid 884) Oops: Oops 
due to oops @ 0xc01e7456  
eax = 0x05dc ebx = 0xc7acf224 ecx = 0x000e edx = 0xc72f8440   
esi = 0xc7cee740 edi = 0x esp = 0xc68f7c90 eip = 0xc01e7456   
ebp = 0xc68f7cb0 xss = 0x0018 xcs = 0x0010 eflags = 0x00010287
xds = 0x0018 xes = 0x0018 origeax = 0x  = 0xc68f7c5c 
kdb> 

I will be glad to submit som more (debug) information?!

I really hope someone can help me :)

Best regards,
Martin Clausen

-- 
   There's no place like ~


/* Compile: gcc -o nfcrash nfcrash.c -lipq
 */ 

#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 

#include 
#include 

/* For CRASH_ME <= 32 everything seems to work (2.4.2-ac21).
 * For CRASH_ME > 32 the kernel oops'es in case of TCP traffic (2.4.2-ac21)?!
 * 
 * For CRASH_ME <= 16 everything seems to work (2.4.3).
 * For CRASH_ME > 16 the kernel oops'es in case of TCP traffic (2.4.3)?!
 * 
 */
const int CRASH_ME = 17;

const int ESP_OFF = 0;

unsigned short in_cksum(unsigned short *addr, int len)
{
  int nleft = len;
  int sum   = 0;
  unsigned short *w = addr;
  unsigned short answer = 0;
  
  while (nleft > 1) {
sum += *w++;
nleft -= 2;
  }

  if (nleft == 1) {
*(unsigned char *)() = *(unsigned char *) w;
sum += answer;
  }
  
  sum = (sum >> 16) + (sum & 0x); 
  sum += (sum >> 16);
  answer = ~sum; 
  
  return answer;
}

int main(int argc, char **argv)
{
  struct ipq_handle *qh;
  struct ipq_packet_msg *qpkt;
  struct iphdr *iph;
  unsigned char buff[8192];
  unsigned char *esppkt;
  int esppkt_len;
  int type; 
  int len;
  
  /* Init first (flags are not implemented; yet) */
  if ( (qh = ipq_create_handle(0)) == NULL) {
/* Run away... */
ipq_perror("create_handle()");
exit(1);
  }

  /* We would like to receive not only metadata... */
  if (ipq_set_mode(qh, IPQ_COPY_PACKET, sizeof(buff)) < 0) {
ipq_perror("set_mode()");
goto cleanup;
  }
  
  /* Now real fun begins... Just stay in loop, read packets,
   * accept them if they are IP. */
  while (1) {
len = ipq_read(qh, buff, sizeof buff, 0);

if (len == 0) {
  fprintf(stderr, "read(): Zero 

Re: [OFFTOPIC] Re: [PATCH] Single user linux

[Alan Cox]

> And get_mail must have elevated privileges to search for the users mail...
> or sendmail must have already switched user on reciept to put it in the
> users inbox which also requires privleges...

No. Think instead of blindly following existing implementation

socket(AF_UNIX, SOCK_STREAM, 0);
connect("/var/run/mailservice");
write("GIMMEMYMAIL\n");
read("200 CATCH..");
read(all my mail)

The daemon needs no priviledge. The client needs no priviledge. The 
PEERCRED authentication on AF_UNIX sockets does the work. I can even pass you
back the file handle of the mailbox if I was using an old style non database
indexed mail spool.

> It's much more efficent to process each mail as it arrives.

You are doing a lot more exec() calls that way. If you get enough mail
to make spool space an issue you want a daemon.

Alan


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

Re: [PATCH] Single user linux

[Stephen Satchell]

"Thinking out of the box," you don't need to modify the kernel or the 
userland utilities to make Linux automatically launch a dedicated terminal 
for embedded applications.  All you need to do is look at the file 
/etc/inittab and read the man pages for this file.  For console access, you 
merely make a shell the first program launched, and you specify RESPAWN as 
the restart type so that if the shell crashes you get your shell back.  The 
invocation may need to be put in a wrapper so that standard input, standard 
output, and standard error are set properly, as are the environment variables.

The security model of Unix need not be sacrificed.  The wrapper can set the 
user ID to a default non-zero user so that there is more security than the 
all-root solution that others have suggested.  For administrative duties, 
the user would use su (and appropriate password) to acquire the appropriate 
permissions.
Back when Unix was first given out by Bell Labs in the '70s, several Bell 
people wrote papers describing exactly how to do this sort of thing in 
Version 7.  In the thirty years since the technique was described, the 
underlying structure -- init/getty/login -- hasn't changed.  I suspect that 
many people here haven't explored the power of inittab, especially given 
the discussion about dying daemons a few months back and how the problem 
was solved in the beginning and the solution ignored today.  (For those of 
you interested, you might want to check the archives for the tangent in the 
OOMkiller discussion.)

(Sorry, I've not found those papers on-line, and my copies were lost about 
seven moves ago.)

Satch


At 06:44 PM 4/24/01 +0700, [EMAIL PROTECTED] wrote:

>hi,
>
>a friend of my asked me on how to make linux easier to use
>for personal/casual win user.
>
>i found out that one of the big problem with linux and most
>other operating system is the multi-user thing.
>
>i think, no personal computer user should know about what's
>an operating system idea of a user. they just want to use
>the computer, that's it.
>
>by a personal computer i mean home pc, notebook, tablet,
>pda, and communicator. only one user will use those devices,
>or maybe his/her friend/family. do you think that user want
>to know about user account?
>
>from that, i also found out that it is very awkward to type
>username and password every time i use my computer.
>so here's a patch. i also have removed the user_struct from
>my kernel, but i don't think you'd like #ifdef's.
>may be it'll be good for midori too.
>
>
> imel
>
>
>
>--- sched.h Mon Apr  2 18:57:06 2001
>+++ sched.h~Tue Apr 24 17:32:33 2001
>@@ -655,6 +655,12 @@
>unsigned long, const char *, void *);
>  extern void free_irq(unsigned int, void *);
>
>+#ifdef CONFIG_NOUSER
>+#define capable(x) 1
>+#define suser()1
>+#define fsuser()   1
>+#else
>+
>  /*
>   * This has now become a routine instead of a macro, it sets a flag if
>   * it returns true (to do BSD-style accounting where the process is flagged
>@@ -706,6 +712,8 @@
> }
> return 0;
>  }
>+
>+#endif /* CONFIG_NOUSER */
>
>  /*
>   * Routines for handling mm_structs
>
>diff -ur linux/Documentation/Configure.help 
>nouser/Documentation/Configure.help
>--- linux/Documentation/Configure.help  Mon Apr  2 18:53:29 2001
>+++ nouser/Documentation/Configure.help Tue Apr 24 18:08:49 2001
>@@ -13626,6 +13626,14 @@
>a work-around for a number of buggy BIOSes. Switch this option on if
>your computer crashes instead of powering off properly.
>
>+Disable Multi-user (DANGEROUS)
>+CONFIG_NOUSER
>+  Disable kernel multi-user support. Normally, we treat each user
>+  differently, depending on his/her permissions. If you _really_
>+  think that you're not going to use your computer in a hostile
>+  environment and would like to cut a few bytes, say Y.
>+  Most people should say N.
>+
>  Watchdog Timer Support
>  CONFIG_WATCHDOG
>If you say Y here (and to one of the following options) and create a
>diff -ur linux/arch/i386/config.in nouser/arch/i386/config.in
>--- linux/arch/i386/config.in   Mon Feb  5 18:50:27 2001
>+++ nouser/arch/i386/config.in  Tue Apr 24 17:53:42 2001
>@@ -244,6 +244,8 @@
> bool 'Use real mode APM BIOS call to power off' 
> CONFIG_APM_REAL_MODE_POWER_OFF
>  fi
>
>+bool 'Disable Multi-user (DANGEROUS)' CONFIG_NOUSER
>+
>  endmenu
>
>  source drivers/mtd/Config.in
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

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

Re: [OFFTOPIC] Re: [PATCH] Single user linux

[Jesse Pollard]

-  Received message begins Here  -

> 
> > 1. email -> sendmail
> > 2. sendmail figures out what it has to do with it. turns out it's deliver
> ...
> 
> > Now, in order for step 4 to be done safely, procmail should be running
> > as the user it's meant to deliver the mail for. for this to happen
> > sendmail needs to start it as that user in step 3 and to do that it
> > needs extra privs, above and beyond that of a normal user.
> 
>   email -> sendmail
>   sendmail 'its local' -> spool
> 
> user:
>   get_mail | procmail
>   mutt
> 
> The mail server doesnt need to run procmail. If you wanted to run mail batches
> through on a regular basis you can use cron for it, or leave a daemon running

And get_mail must have elevated privileges to search for the users mail...
or sendmail must have already switched user on reciept to put it in the
users inbox which also requires privleges...

And an additional daemon (owned by the user) is yet another attack point...

Cron could be used to batch message handling... as long as it runs before
the users quota is used up. This becomes the same as using IMAP or fetchmail
to download it.

It's much more efficent to process each mail as it arrives.

All this does is move the program that requires privileges to somewhere
else. It doesn't eliminate it.

Granted, sendmail could use a better implementation of a security model.

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

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