date:20001225

On Tue, 26 Dec 2000, Chris Wedgwood wrote:

> On Mon, Dec 25, 2000 at 01:42:33AM -0800, Linus Torvalds wrote:
> 
> We just don't write them out. Because right now the only thing
> that writes out dirty pages is memory pressure. "sync()",
> "fsync()" and "fdatasync()" will happily ignore dirty pages
> completely. The thing that made me overlook that simple thing in
> testing was that I was testing the new VM stuff under heavy VM
> load - to shake out any bugs.
> 
> Does this mean anyone using test13-pre4 should also expect to see
> data not being flushed on shutdown? 

No.

This all only matters to things that do shared writable mmap's.

Almost nothing does that. innd is (sadly) the only regular thing that uses
this, which is why it's always innd that breaks, even if everything else
works.

And even innd is often compiled to use "write()" instead of shared
mappings (it's a config option), so not even all innd's will break.

Linus

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

controllerless pci device support

2000-12-25 Thread Eric Shattow


would it be sensible to write a PCI device interface for controllerless PCI
devices like serial PCI ports?  I am now trying to make the older 2.2.x
series LT winmodem patch into the 2.4.0-test13pre4 sources work.  I see how
some companies are unable to release all the source code to drivers due to
legal reasons and patent restrictions.  Maybe there should be a generic
driver interface for software modems or other devices, so it is easier to -
as an example - write winmodem drivers for the serial driver without
hacking in many sets of "#ifdef LUCENT_MODEM. modified code #endif"
to the serial.c source file.
i am not able to create such a thing, and winmodems are not the most
popular thing to talk about in regards to support.  after spending 3 hours
staring at serial.c, as a beginning programmer, and hand copying the
appropriate 2.2.x winnmodem "serial.c" driver code in, i am lost.   the
module finally compiles, without error, but complains with an error that
there is an unresolved symbol "jiffie".   kind of funny, a jiffie is all
that separates me from turning my brand new laptop into a machine i can use
the modem on.  also it is equally fustrating.  will this situation improve
in time or what else can i do to get my modem working?   arrrgh!  even if
the hand-done patching of 2.4.x's serial.c file resulted in a useable
kernel module, i would not like to have to patch it every time i update my
kernel. a winmodem.o module with support for generic interfaces into the
kernel so driver vendors do not need to muck around with serial.c would be
an idea.
my real question to all is where is the support of PCI serial devices at
inside of the kernel? if i have pci bus 0:0.b sharing irq 11 with 0:0.c,
does the linux kernel support both devices working at the same time
(ethernet, and serial port aka winmodem)?

this is probably better off sent to the serial mailing list i know, but i
am more interested in whether all the problems i am having with 4 out of 6
devices on my laptop's PCI bus conflicting, whether this is because the
linux kernel does not support more than one PCI function operating
simultaneously on any given PCI device under the same PCI bus.  (
bus:device.function )

right now i get a message that says [IRQ 11 is already used by device
0:8.0] when i load drivers for the device 0:8.1, and the visa-versa message
when loading drivers for device 0:8.0.  Is this just a warning, or an
error? i can't tell.  sometimes the driver (as is the case with pcmcia
drivers, where slot0 is 0:6.0 and slot1 is 0:6.1) loads anyways, despite
the message about [IRQ 11 is alr...].  othertimes, with my ethernet drivers
and alsa sound drivers, i see the message and the drivers fail to load.

what to do

merry holidays, all. i apologize this is long and likely off topic. i mean
well though.

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

Re: 8139too driver broken? (2.4-test12) - Was: Re: rtl8139 driver broken? (2.2.16)

2000-12-25 Thread Stefan Hoffmeister

: On Sat, 23 Dec 2000 18:50:53 +0100, Stefan Hoffmeister wrote:

>The rather major problem that
>remains is performance.

In case someone is interested...

Windows 2000 SP1 now has the Realtek 8139 (Celeron 433, 192 MB, pure
SCSI); drivers as shipped with W2K. Using a 40 MB test file over FTP, I
get

  Realtek card sends with 3.5 MB/s
  Realtek card receives with 5 MB/s

The system that previously contained the 8139 card now has a (10 MBit)
8029 card - transfer rates with that card are about 850 KB/s, compared to
the 400KB/s to 530 KB/s with the (100 MBit) 8139 card.

This makes me conclude that there is some pretty serious problem left in
the 8139too driver.

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

Re: innd mmap bug in 2.4.0-test12




On Mon, 25 Dec 2000, Marco d'Itri wrote:
>
>  >Do you get any messages? I don't think you will, but it should be tested.
>
> I read you found the real cause so that may be bogus, but I have got two
> messages while booting. The first showed up while doing the fsck of a 6
> GB file systems and killed the process (fscks of smaller partitions
> completed successfully), the second occured while initializing
> /dev/random and left an unkillable dd process and a stuck boot process
> (I gathered this info with sysrq).

I'd still love to get the trace for these. I think I have a handle on the
problems, but it would stil be helpful - dropping a dirty page really
shouldn't happen except for the swap cache (and that should have been
plugged by adding the ClearPageDirty()).

Linus

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

RE: TCP keepalive seems to send to only one port

2000-12-25 Thread David Schwartz

Cesar Barros wrote:

> On Mon, Dec 25, 2000 at 04:33:07PM -0800, David Schwartz wrote:
> > If the administrator of the NAT meant for you to have a
> > permanent mapping,
> > she would have put one there. Using keepalives to hold a NAT entry open
> > indefinitely without activity would be considered abuse in most NAT
> > configurations. The NAT might not consider a keepalive to be
> > activity anyway
> > (arguably, it shouldn't).

> Well, consider the scenario of an application which opens a
> control connection
> and a data connection, and the data connection remains idle for some hours
> while you get to the beginning of the queue, and then the
> transfer starts. The
> data connection is not open forever, and the timeout (and the
> periodic pings)
> is on the control connection.

I would consider that application broken. The data connection should be
opened when it's needed, not left idle for hours and used later. If the data
connection does break somehow, there should be a provision for
re-establishing it without losing all application-level state.

I'm not saying it shouldn't be possible to work around a defective
application protocol. But to expect there to be some easy way to just flip a
switch and fix it is unreasonable.

The NAT may not even consider a keepalive to be activity. There's no
logical reason it should if the timeout is less than many hours.

DS

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

Re: TCP keepalive seems to send to only one port

2000-12-25 Thread Cesar Eduardo Barros

On Mon, Dec 25, 2000 at 04:33:07PM -0800, David Schwartz wrote:
> 
> > On Sat, Dec 23, 2000 at 04:19:31PM -0800, David Schwartz wrote:
> 
> > > > This means that keepalive is useless for keeping alive more than
> > > > one connection
> > > > to a given host.
> 
> > >   Actually, keepalive is useless for keeping connections
> > > alive anyway. It's
> > > very badly named. It's purpose is to detect dead peers, not keep peers
> > > alive.
> >
> > Then what do you do when you are behind a NAT?
> 
>   If the administrator of the NAT meant for you to have a permanent mapping,
> she would have put one there. Using keepalives to hold a NAT entry open
> indefinitely without activity would be considered abuse in most NAT
> configurations. The NAT might not consider a keepalive to be activity anyway
> (arguably, it shouldn't).

Well, consider the scenario of an application which opens a control connection
and a data connection, and the data connection remains idle for some hours
while you get to the beginning of the queue, and then the transfer starts. The
data connection is not open forever, and the timeout (and the periodic pings)
is on the control connection.

The problem is that, after four or more hours of waiting, when the other side
finally starts sending, the NAT has already forgotten about the connection.

(In case someone is wondering, the application I'm talking about is fidelio.
 Which is pretty useless on busy sites behind a NAT because of that.)

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

Re: sparc 10 w/512 megs hangs during boot

2000-12-25 Thread Ron Calderon


apparently test7 has the same problem and when I
compile test6 I get these errors:
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -m32
-pipe -mno-fpu -fcall-used-g5 -fcall-used-g7
-fno-strict-aliasing-c -o fault.o fault.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -m32
-pipe -mno-fpu -fcall-used-g5 -fcall-used-g7
-fno-strict-aliasing-c -o init.o init.c
init.c: In function `kmap_init':
init.c:92: warning: unused variable `pteval'
init.c: In function `mem_init':
init.c:460: `highmem_mapnr' undeclared (first use in
this function)
init.c:460: (Each undeclared identifier is reported
only once
init.c:460: for each function it appears in.)
init.c: In function `flush_page_to_ram':
init.c:588: warning: passing arg 1 of
`___f___flush_page_to_ram' makes integer from pointer
without a cast
make[3]: *** [init.o] Error 1
make[3]: Leaving directory
`/usr/src/linux/arch/sparc/mm'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory
`/usr/src/linux/arch/sparc/mm'
make[1]: *** [_dir_arch/sparc/mm] Error 2
make[1]: Leaving directory `/usr/src/linux'
make: *** [stamp-build] Error 2


so as far as I can see test5 is the last kernel that
can be built and booted properly on a sparc10 with
512M of ram. All others after test5 do not boot my
sparc10 with more than 128M of ram.


ron

--- Ron Calderon <[EMAIL PROTECTED]> wrote:
> test8 is borked too. I'll try test7 next
> 
> ron
> --- Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
> > On Sun, Dec 24, 2000 at 12:48:44PM -0800, Ron
> > Calderon wrote:
> > > I just finished compiling 2.4.0-test5 and that
> > worked
> > > fine with 512M ram. I'll start going thru the
> > other
> > > kernels. It'll take me sometime since compileing
> > takes
> > > a long time.
> > 
> > I've not yet started active searching. However:
> > - test5 is fine
> > - test13-pre3   is not
> > 
> > I don't know how fast your machine is, but we
> should
> > coordinate out
> > search... I'll try to build -test10final (with
> > minimal config to
> > only test boot) so that shouldn't take so very
> > long... You should
> > test sth around -test8...
> > 
> > MfG, JBG
> > 
> > -- 
> > Fehler eingestehen, Größe zeigen: Nehmt die
> > Rechtschreibreform zurück!!!
> > /* Jan-Benedict Glaw <[EMAIL PROTECTED]> --
> > +49-177-5601720 */
> > keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C
> > A444 A961 1DBD 5E75 8399 E1BB
> >  "insmod vi.o and there we go..." (Alexander
> > Viro on linux-kernel)
> > 
> 
> > ATTACHMENT part 2 application/pgp-signature 
> 
> 
> 
> __
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of
> Products.
> http://shopping.yahoo.com/
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/


__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [bug] test13-pre4 nfs/ip_defrag crash (smp)

On Mon, 25 Dec 2000, Jasper Spaans wrote:
> 
> I am having some reproducible crashes with 2.4.0-test13-pre4, whenever I
> do some 'heavy' nfs-ing.. decoded oops:

It looks like most of what you have is modules. Is netfilter enabled as a
module too? Can you reproduce it without modules, in case it's a
autounload race or similar?

Linus

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

RE: TCP keepalive seems to send to only one port

2000-12-25 Thread David Schwartz

> On Sat, Dec 23, 2000 at 04:19:31PM -0800, David Schwartz wrote:

> > > This means that keepalive is useless for keeping alive more than
> > > one connection
> > > to a given host.

> > Actually, keepalive is useless for keeping connections
> > alive anyway. It's
> > very badly named. It's purpose is to detect dead peers, not keep peers
> > alive.
>
> Then what do you do when you are behind a NAT?

If the administrator of the NAT meant for you to have a permanent mapping,
she would have put one there. Using keepalives to hold a NAT entry open
indefinitely without activity would be considered abuse in most NAT
configurations. The NAT might not consider a keepalive to be activity anyway
(arguably, it shouldn't).

> And how do you
> expire entries in
> ESTABLISHED state that could stay lingering forever without some sort of
> keepalive? (The FINs might have been lost due to a conectivity
> transient, so
> you can have another perfectly valid and alive connection with
> the same host,
> and application-level timeouts are useless for some applications
> (*cough*nc*cough*))

I don't understand this argument. First you demonstrate the need for
application-level timeouts, then you say application-level timeouts are
useless. Actually, your first argument is correct, protocols layered on top
of TCP that don't provide for timeouts are defective.

DS

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

Re: About Celeron processor memory barrier problem

2000-12-25 Thread Albert D. Cahalan

Tim Wright writes:

> There was a similar thread to this recently. The issue is that if you
> choose the wrong processor type, you may not even be able to complain.

An illegal opcode handler could deal with the problem.
It could crudely emulate just enough to make printk work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] LVM includes userlevel headers

2000-12-25 Thread Andrea Arcangeli


On Tue, Dec 26, 2000 at 12:32:44AM +0100, Andrea Arcangeli wrote:
> On Mon, Dec 25, 2000 at 11:53:33PM +0100, Christoph Hellwig wrote:
> > The first patch fixes that and the second changes the toplevel Makefile
> > to search only the kernel and gcc (for stdarg.h) includes to prevent such
> > accidents.
> 
> Looks fine, thanks.

BTW, I included your fixes into the 2.2.x backport (nostdinc in a separate
patch):


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.19pre3aa2/14_bigmem-rawio-lvm-0.9-2.2.19pre3aa2-3.bz2

ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.19pre3aa2/00_nostdinc-Christoph-Hellwig-1

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

Re: Abysmal RAID 0 performance on 2.4.0-test10 for IDE?

2000-12-25 Thread Felix von Leitner


Thus spake Felix von Leitner ([EMAIL PROTECTED]):
> Here is the result of my test program on the strip set:
>   # rb < /dev/md/0
>   30.3 meg/sec
>   #

One more detail: top says the CPU is 50% system when reading from either
one of the disk or raid devices.  That seems awfully high considering
that the Promise controller claims to do UDMA.

Any comments?

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

Re: [PATCH] winbond-840 updates, tester needed!


Manfred wrote:
> 
> I need a tester with a winbond card on a computer with a big endian cpu,
> any volunteers?
>
Attached is a patch with further cleanups:

* removed next_desc from tx descriptors - according to the
documentation, it isn't needed.

* limit each transmit buffer to < 1024 bytes.

I still see several bad packets during ftp transfers, but that might be
due to a bad cable.

Noone out there with a ppc and a winbond card?

--
Manfred

--- 2.4/drivers/net/winbond-840.c   Sun Dec 17 18:03:56 2000
+++ build-2.4/drivers/net/winbond-840.c Tue Dec 26 00:23:23 2000
@@ -21,11 +21,24 @@
Do not change the version information unless an improvement has been made.
Merely removing my name, as Compex has done in the past, does not count
as an improvement.
+
+   Changelog:
+   * ported to 2.4
+   ???
+   * spin lock update, memory barriers, new style dma mappings
+   superfluous next pointers from tx ring removed,
+   limit tx buffer size to < 1024
+
+   Manfred Spraul <[EMAIL PROTECTED]>
+
+   TODO:
+   * according to the documentation, the chip supports big endian
+   internally. Replace the cpu_to_le32 with that bit.
 */
 
 /* These identify the driver base version and may not be removed. */
 static const char version1[] =
-"winbond-840.c:v1.01 5/15/2000  Donald Becker <[EMAIL PROTECTED]>\n";
+"winbond-840.c:v1.01 (2.4 port) 5/15/2000  Donald Becker <[EMAIL PROTECTED]>\n";
 static const char version2[] =
 "  http://www.scyld.com/network/drivers.html\n";
 
@@ -81,6 +94,8 @@
 #define TX_FIFO_SIZE (2048)
 #define TX_BUG_FIFO_LIMIT (TX_FIFO_SIZE-1514-16)
 
+#define TX_BUFLIMIT(1024-128)
+
 /* Operational parameters that usually are not changed. */
 /* Time in jiffies before concluding the transmitter is hung. */
 #define TX_TIMEOUT  (2*HZ)
@@ -114,12 +129,6 @@
 #include 
 #include 
 
-/* Condensed operations for readability.
-   The compatibility defines are in kern_compat.h */
-
-#define virt_to_le32desc(addr)  cpu_to_le32(virt_to_bus(addr))
-#define le32desc_to_virt(addr)  bus_to_virt(le32_to_cpu(addr))
-
 MODULE_AUTHOR("Donald Becker <[EMAIL PROTECTED]>");
 MODULE_DESCRIPTION("Winbond W89c840 Ethernet driver");
 MODULE_PARM(max_interrupt_work, "i");
@@ -280,7 +289,7 @@
s32 status;
s32 length;
u32 buffer1;
-   u32 next_desc;
+   u32 buffer2;
 };
 
 struct w840_tx_desc {
@@ -298,9 +307,12 @@
 
 #define PRIV_ALIGN 15  /* Required alignment mask */
 struct netdev_private {
-   /* Descriptor rings first for alignment. */
-   struct w840_rx_desc rx_ring[RX_RING_SIZE];
-   struct w840_tx_desc tx_ring[TX_RING_SIZE];
+   struct w840_rx_desc *rx_ring;
+   dma_addr_t  rx_addr[RX_RING_SIZE];
+   struct w840_tx_desc *tx_ring;
+   dma_addr_t  tx_addr[RX_RING_SIZE];
+   dma_addr_t ring_dma_addr;
+   struct pci_dev *pdev;
/* The addresses of receive-in-place skbuffs. */
struct sk_buff* rx_skbuff[RX_RING_SIZE];
/* The saved address of a sent-in-place packet/buffer, for later free(). */
@@ -335,7 +347,7 @@
 static void check_duplex(struct net_device *dev);
 static void netdev_timer(unsigned long data);
 static void tx_timeout(struct net_device *dev);
-static void init_ring(struct net_device *dev);
+static int init_ring(struct net_device *dev);
 static int  start_tx(struct sk_buff *skb, struct net_device *dev);
 static void intr_handler(int irq, void *dev_instance, struct pt_regs *regs);
 static void netdev_error(struct net_device *dev, int intr_status);
@@ -364,6 +376,11 @@
return -EIO;
pci_set_master(pdev);
 
+   if(!pci_dma_supported(pdev,0x)) {
+   printk(KERN_WARNING "Winbond-840: Device %s disabled due to DMA 
+limitations.\n",
+   pdev->name);
+   return -EIO;
+   }
dev = init_etherdev(NULL, sizeof(*np));
if (!dev)
return -ENOMEM;
@@ -403,6 +420,7 @@
np = dev->priv;
np->chip_id = chip_idx;
np->drv_flags = pci_id_tbl[chip_idx].drv_flags;
+   np->pdev = pdev;
spin_lock_init(>lock);

pdev->driver_data = dev;
@@ -632,10 +650,12 @@
printk(KERN_DEBUG "%s: w89c840_open() irq %d.\n",
   dev->name, dev->irq);
 
-   init_ring(dev);
+   if((i=init_ring(dev)))
+   return i;
 
-   writel(virt_to_bus(np->rx_ring), ioaddr + RxRingPtr);
-   writel(virt_to_bus(np->tx_ring), ioaddr + TxRingPtr);
+   writel(np->ring_dma_addr, ioaddr + RxRingPtr);
+   writel(np->ring_dma_addr+sizeof(struct w840_rx_desc)*RX_RING_SIZE,
+   ioaddr + TxRingPtr);
 
for (i = 0; i < 6; i++)
writeb(dev->dev_addr[i], ioaddr + StationAddr + i);
@@ -733,11 +753,13 @@
   "config %8.8x.\n",
   dev->name,

Re: [PATCH] LVM includes userlevel headers

2000-12-25 Thread Andrea Arcangeli


On Mon, Dec 25, 2000 at 11:53:33PM +0100, Christoph Hellwig wrote:
> The first patch fixes that and the second changes the toplevel Makefile
> to search only the kernel and gcc (for stdarg.h) includes to prevent such
> accidents.

Looks fine, thanks.

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

Abysmal RAID 0 performance on 2.4.0-test10 for IDE?

2000-12-25 Thread Felix von Leitner


Hi,

I bought 4 ATA-100 Maxtor drives and put them on a Promise Ultra100
controller to make a single striping RAID of them to increase
throughput.

I wrote a small test program that simply reads stdin linearly and
displays the throughput.  The block size is 100k.  This is the result:

  # cat /etc/raidtab
  raiddev /dev/md/0
  raid-level 0
  nr-raid-disks 4
  persistent-superblock 1
  chunk-size 32

  device /dev/ide/host2/bus0/target0/lun0/part1
  raid-disk 0
  device /dev/ide/host2/bus0/target1/lun0/part1
  raid-disk 2

  device /dev/ide/host2/bus1/target0/lun0/part1
  raid-disk 1
  device /dev/ide/host2/bus1/target1/lun0/part1
  raid-disk 3

Here are the results of my test program on the disk devices:
  # rb < /dev/ide/host2/bus0/target0/lun0/part1
  27.8 meg/sec
  # rb < /dev/ide/host2/bus0/target0/lun0/part1
  26.8 meg/sec

the other two disks have approximately the same numbers.

Here is the result of my test program on the strip set:
  # rb < /dev/md/0
  30.3 meg/sec
  #

While this is faster than linear mode, I would have expected much better
performance.  These are the boot messages of the Promise adapter:

  PDC20267: IDE controller on PCI bus 00 dev 60
  PDC20267: chipset revision 2
  PDC20267: not 100% native mode: will probe irqs later
  PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
  ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:pio, hdf:pio
  ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:pio, hdh:pio
  ide2 at 0xdc00-0xdc07,0xe002 on irq 10
  ide3 at 0xe400-0xe407,0xe802 on irq 10
  hde: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=158816/16/63, UDMA(100)
  hdf: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=158816/16/63, UDMA(100)
  hdg: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=158816/16/63, UDMA(100)
  hdh: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=158816/16/63, UDMA(100)

I tuned the devices with hdparm -c 1 -a 32 -m 16 -p -u 1, for what it's worth
(did not increase throughput but appeared to lessen the CPU usage).

To verify that this is not an issue of the Promise controller, I started
two instances of my test tool at the same time, one working on hde, the
other on hdg (the two channels).  Both yielded approximately 25 meg/sec,
so it does not appear to be a hardware or driver issue.  Is the RAID
code really this slow?  Any ideas what I can do?

I am using the user space tools from raidtools-19990421-0.90.tar.bz2,
but that should not have any influence, right?

I heard that there is a new, faster RAID code somewhere, but it only
claimed to be faster on RAID level 5, not on striping.

Any tuning advice?

By the way: I noticed another thing: one of the Maxtor hard disks was
broken.  It caused the whole box to freeze solid (no numlock, no console
switches, no sysrq).  That to me severely limits the usefulness of IDE
RAID.  While SCSI problems cause trouble, too, I have never seen one
cause a complete freeze.  How am I supposed to hot-swap the disks?
I am using VESA framebuffer, so maybe there was a panic and it simply
did not appear on my screen (or in the logs).

Hope to hear from you soon (the RAID is needed on Dec 27).
Should I use LVM instead of the MD code?

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

Re: [PATCH][RFC] LVM proc fix

2000-12-25 Thread Andrea Arcangeli


On Mon, Dec 25, 2000 at 11:59:51PM +0100, Christoph Hellwig wrote:
> Hi Linus & Heinz,
> 
> there has been some discussion about the LVM /proc #ifdefs in
> Linux 2.4.0-test13pre4 (LVM 0.9).  How about just removing
> CONFIG_LVM_PROC_FS? - beople that use LVM and procfs usually do
> not care for the few extra bytes.

I think it's a good idea.

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

[PATCH][RFC] LVM proc fix

2000-12-25 Thread Christoph Hellwig


Hi Linus & Heinz,

there has been some discussion about the LVM /proc #ifdefs in
Linux 2.4.0-test13pre4 (LVM 0.9).  How about just removing
CONFIG_LVM_PROC_FS? - beople that use LVM and procfs usually do
not care for the few extra bytes.

Patch attached.

Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.


diff -uNr --exclude-from=dontdiff linux-2.4.0-test13-pre4/Documentation/Configure.help 
linux/Documentation/Configure.help
--- linux-2.4.0-test13-pre4/Documentation/Configure.helpMon Dec 25 19:21:14 
2000
+++ linux/Documentation/Configure.help  Mon Dec 25 23:55:07 2000
@@ -1450,15 +1450,6 @@
   want), say M here and read Documentation/modules.txt. The module
   will be called lvm-mod.o.
 
-Logical Volume Manager /proc file system information
-CONFIG_LVM_PROC_FS
-  If you say Y here, you are able to access overall Logical Volume
-  Manager, Volume Group, Logical and Physical Volume information in
-  /proc/lvm.
-
-  To use this option, you have to check, that the "/proc file system
-  support" (CONFIG_PROC_FS) is enabled too.
-
 Multiple devices driver support
 CONFIG_BLK_DEV_MD
   This driver lets you combine several hard disk partitions into one
diff -uNr --exclude-from=dontdiff linux-2.4.0-test13-pre4/drivers/md/Config.in 
linux/drivers/md/Config.in
--- linux-2.4.0-test13-pre4/drivers/md/Config.inSun Nov 26 17:23:18 2000
+++ linux/drivers/md/Config.in  Mon Dec 25 23:55:07 2000
@@ -17,6 +17,5 @@
 fi
 
 dep_tristate ' Logical volume manager (LVM) support' CONFIG_BLK_DEV_LVM $CONFIG_MD
-dep_mbool '   LVM information in proc filesystem' CONFIG_LVM_PROC_FS 
$CONFIG_BLK_DEV_LVM
 
 endmenu
diff -uNr --exclude-from=dontdiff linux-2.4.0-test13-pre4/drivers/md/lvm.c 
linux/drivers/md/lvm.c
--- linux-2.4.0-test13-pre4/drivers/md/lvm.cMon Dec 25 19:21:16 2000
+++ linux/drivers/md/lvm.c  Mon Dec 25 23:55:07 2000
@@ -139,6 +139,7 @@
  * lvm_proc_get_global_info()
  *02/11/2000 - implemented /proc/lvm/ hierarchy
  *07/12/2000 - make sure lvm_make_request_fn returns correct value - 0 or 1 - 
NeilBrown
+ *25/12/2000 - fix procfs #defines - Christoph Hellwig
  *
  */
 
@@ -224,7 +225,7 @@
 
 static int lvm_chr_ioctl(struct inode *, struct file *, uint, ulong);
 
-#if defined CONFIG_LVM_PROC_FS && defined CONFIG_PROC_FS
+#ifdef CONFIG_PROC_FS
 int lvm_proc_read_vg_info(char *, char **, off_t, int, int *, void *);
 int lvm_proc_read_lv_info(char *, char **, off_t, int, int *, void *);
 int lvm_proc_read_pv_info(char *, char **, off_t, int, int *, void *);
@@ -347,7 +348,7 @@
 static spinlock_t lvm_lock = SPIN_LOCK_UNLOCKED;
 static spinlock_t lvm_snapshot_lock = SPIN_LOCK_UNLOCKED;
 
-#if defined CONFIG_LVM_PROC_FS && defined CONFIG_PROC_FS
+#ifdef CONFIG_PROC_FS
 static struct proc_dir_entry *lvm_proc_dir = NULL;
 static struct proc_dir_entry *lvm_proc_vg_subdir = NULL;
 struct proc_dir_entry *pde = NULL;
@@ -433,7 +434,7 @@
_chr_fops, NULL);
 #endif
 
-#if defined CONFIG_LVM_PROC_FS && defined CONFIG_PROC_FS
+#ifdef CONFIG_PROC_FS
lvm_proc_dir = create_proc_entry (LVM_DIR, S_IFDIR, _root);
if (lvm_proc_dir != NULL) {
lvm_proc_vg_subdir = create_proc_entry (LVM_VG_SUBDIR, S_IFDIR, 
lvm_proc_dir);
@@ -521,7 +522,7 @@
blksize_size[MAJOR_NR] = NULL;
hardsect_size[MAJOR_NR] = NULL;
 
-#if defined CONFIG_LVM_PROC_FS && defined CONFIG_PROC_FS
+#ifdef CONFIG_PROC_FS
remove_proc_entry(LVM_GLOBAL, lvm_proc_dir);
remove_proc_entry(LVM_VG_SUBDIR, lvm_proc_dir);
remove_proc_entry(LVM_DIR, _root);
@@ -1263,7 +1264,7 @@
 }
 
 
-#if defined CONFIG_LVM_PROC_FS && defined CONFIG_PROC_FS
+#ifdef CONFIG_PROC_FS
 /*
  * Support functions /proc-Filesystem
  */
@@ -1452,8 +1453,6 @@
else
return count;
 } /* lvm_proc_get_global_info() */
-#endif /* #if defined CONFIG_LVM_PROC_FS && defined CONFIG_PROC_FS */
-
 
 /*
  * provide VG information
@@ -1530,7 +1529,7 @@
 
return sz;
 }
-
+#endif /* CONFIG_PROC_FS */
 
 /*
  * block device support function for /usr/src/linux/drivers/block/ll_rw_blk.c
@@ -1989,7 +1988,7 @@
_chr_fops, NULL);
 #endif
 
-#if defined CONFIG_LVM_PROC_FS && defined CONFIG_PROC_FS
+#ifdef CONFIG_PROC_FS
lvm_do_create_proc_entry_of_vg ( vg_ptr);
 #endif
 
@@ -2021,7 +2020,9 @@
for (p = 0; p < vg_ptr->pv_max; p++) {
if ( ( pv_ptr = vg_ptr->pv[p]) == NULL) {
ret = lvm_do_pv_create(arg, vg_ptr, p);
+#ifdef CONFIG_PROC_FS
lvm_do_create_proc_entry_of_pv ( vg_ptr, pv_ptr);
+#endif
if ( ret != 0) return ret;

/* We don't need the PE list
@@ -2091,7 +2092,7 @@
if (copy_from_user(vg_name, arg, sizeof(vg_name)) != 0)
return -EFAULT;
 
-#if defined CONFIG_LVM_PROC_FS && defined CONFIG_PROC_FS
+#ifdef CONFIG_PROC_FS

[PATCH] LVM includes userlevel headers

2000-12-25 Thread Christoph Hellwig


Hi Linus,

LVM 0.9 that just rolled into 2.4-test includes userlevel headers -
just to use constants from there to dublicate kernel functions.

The first patch fixes that and the second changes the toplevel Makefile
to search only the kernel and gcc (for stdarg.h) includes to prevent such
accidents.

Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.


diff -uNr --exclude-from=dontdiff linux-2.4.0-test13-pre4/drivers/md/lvm-snap.c 
linux/drivers/md/lvm-snap.c
--- linux-2.4.0-test13-pre4/drivers/md/lvm-snap.c   Mon Dec 25 19:21:16 2000
+++ linux/drivers/md/lvm-snap.c Mon Dec 25 23:59:50 2000
@@ -214,10 +214,10 @@
memset(lv_COW_table, 0, blksize_snap);
for ( ; is < lv_snap->lv_remap_ptr; is++, id++) {
/* store new COW_table entry */
-   lv_COW_table[id].pv_org_number = LVM_TO_DISK64(lvm_pv_get_number(vg, 
lv_snap->lv_block_exception[is].rdev_org));
-   lv_COW_table[id].pv_org_rsector = 
LVM_TO_DISK64(lv_snap->lv_block_exception[is].rsector_org);
-   lv_COW_table[id].pv_snap_number = LVM_TO_DISK64(lvm_pv_get_number(vg, 
lv_snap->lv_block_exception[is].rdev_new));
-   lv_COW_table[id].pv_snap_rsector = 
LVM_TO_DISK64(lv_snap->lv_block_exception[is].rsector_new);
+   lv_COW_table[id].pv_org_number = cpu_to_le64(lvm_pv_get_number(vg, 
+lv_snap->lv_block_exception[is].rdev_org));
+   lv_COW_table[id].pv_org_rsector = 
+cpu_to_le64(lv_snap->lv_block_exception[is].rsector_org);
+   lv_COW_table[id].pv_snap_number = cpu_to_le64(lvm_pv_get_number(vg, 
+lv_snap->lv_block_exception[is].rdev_new));
+   lv_COW_table[id].pv_snap_rsector = 
+cpu_to_le64(lv_snap->lv_block_exception[is].rsector_new);
}
 }
 
@@ -268,10 +268,10 @@
blocks[0] = (snap_pe_start + COW_table_sector_offset) >> (blksize_snap >> 10);
 
/* store new COW_table entry */
-   lv_COW_table[idx_COW_table].pv_org_number = 
LVM_TO_DISK64(lvm_pv_get_number(vg, lv_snap->lv_block_exception[idx].rdev_org));
-   lv_COW_table[idx_COW_table].pv_org_rsector = 
LVM_TO_DISK64(lv_snap->lv_block_exception[idx].rsector_org);
-   lv_COW_table[idx_COW_table].pv_snap_number = 
LVM_TO_DISK64(lvm_pv_get_number(vg, snap_phys_dev));
-   lv_COW_table[idx_COW_table].pv_snap_rsector = 
LVM_TO_DISK64(lv_snap->lv_block_exception[idx].rsector_new);
+   lv_COW_table[idx_COW_table].pv_org_number = cpu_to_le64(lvm_pv_get_number(vg, 
+lv_snap->lv_block_exception[idx].rdev_org));
+   lv_COW_table[idx_COW_table].pv_org_rsector = 
+cpu_to_le64(lv_snap->lv_block_exception[idx].rsector_org);
+   lv_COW_table[idx_COW_table].pv_snap_number = cpu_to_le64(lvm_pv_get_number(vg, 
+snap_phys_dev));
+   lv_COW_table[idx_COW_table].pv_snap_rsector = 
+cpu_to_le64(lv_snap->lv_block_exception[idx].rsector_new);
 
length_tmp = iobuf->length;
iobuf->length = blksize_snap;
diff -uNr --exclude-from=dontdiff linux-2.4.0-test13-pre4/include/linux/lvm.h 
linux/include/linux/lvm.h
--- linux-2.4.0-test13-pre4/include/linux/lvm.h Mon Dec 25 19:21:15 2000
+++ linux/include/linux/lvm.h   Tue Dec 26 00:01:23 2000
@@ -57,6 +57,8 @@
  *26/06/2000 - implemented snapshot persistency and resizing support
  *02/11/2000 - added hash table size member to lv structure
  *12/11/2000 - removed unneeded timestamp definitions
+ *24/12/2000 - removed LVM_TO_{CORE,DISK}*, use cpu_{from, to}_le*
+ * instead - Christoph Hellwig
  *
  */
 
@@ -67,7 +69,6 @@
 #define_LVM_KERNEL_H_VERSION   "LVM 0.9 (13/11/2000)"
 
 #include 
-#include 
 
 /*
  * preprocessor definitions
@@ -323,51 +324,6 @@
COW_table_entries_per_PE = LVM_GET_COW_TABLE_CHUNKS_PER_PE(vg, lv); \
COW_table_chunks_per_PE = ( COW_table_entries_per_PE * 
sizeof(lv_COW_table_disk_t) / SECTOR_SIZE + lv->lv_chunk_size - 1) / 
lv->lv_chunk_size; \
COW_table_entries_per_PE - COW_table_chunks_per_PE;})
-
-
-/* to disk and to core data conversion macros */
-#if __BYTE_ORDER == __BIG_ENDIAN
-
-#define LVM_TO_CORE16(x) ( \
-((uint16_t)uint16_t)(x) & 0x00FFU) << 8) | \
-(((uint16_t)(x) & 0xFF00U) >> 8
-
-#define LVM_TO_DISK16(x) LVM_TO_CORE16(x)
-
-#define LVM_TO_CORE32(x) ( \
-((uint32_t)uint32_t)(x) & 0x00FFU) << 24) | \
-(((uint32_t)(x) & 0xFF00U) << 8))) \
-(((uint32_t)(x) & 0x00FFU) >> 8))) \
-(((uint32_t)(x) & 0xFF00U) >> 24
-
-#define LVM_TO_DISK32(x) LVM_TO_CORE32(x)
-
-#define LVM_TO_CORE64(x) \
-((uint64_t)uint64_t)(x) & 0x00FFULL) << 56) | \
-(((uint64_t)(x) & 0xFF00ULL) << 40) | \
-(((uint64_t)(x) & 0x00FFULL) << 24) | \
-(((uint64_t)(x) & 0xFF00ULL) <<  8) | \
-(((uint64_t)(x) & 0x00FFULL) >>  8) | \
-

[bug] test13-pre4 nfs/ip_defrag crash (smp)

2000-12-25 Thread Jasper Spaans


Hi!

I am having some reproducible crashes with 2.4.0-test13-pre4, whenever I
do some 'heavy' nfs-ing.. decoded oops:

ksymoops 2.3.4 on i686 2.4.0-test13-pre4.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test13-pre4/ (default)
 -m /boot/System.map-2.4.0-test13-pre4 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Unable to handle kernel paging request at virtual address eabc089f
c01e263e
*pde = 
Oops: 
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: eabc0863   ebx: c40c53e0   ecx: c54a1824   edx: c28079a0
esi: 0b90   edi: c5a0df40   ebp: 05c8   esp: ce699c4c
ds: 0018   es: 0018   ss: 0018
Process rpciod (pid: 2358, stackpage=ce699000)
Stack: c28079a0  0a2b 070a 0014  c01e2a2d c28079a0 
   c5a0df40 c02ce7ac ce698000 c36f9c40 c5a0df40 eabc0863 c54a1810 d1147a82 
   c5a0df40 ce699d48 c02f6878 c01e549c ce699d58 d11471c9 c5a0df40 ce699d48 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] 
Code: 8b 40 3c 8b 4c 24 1c 89 41 3c c7 47 18 00 00 00 00 8b 54 24 

>>EIP; c01e263e<=
Trace; c01e2a2d 
Trace; eabc0863 
Trace; d1147a82 <[8139too]rtl8139_set_rx_mode+56/270>
Trace; c01e549c 
Trace; d11471c9 <[8139too]rtl8139_rx_interrupt+151/24c>
Trace; c01e549c 
Trace; c012f810 <__alloc_pages+12c/2d4>
Trace; d114640a <[8139too]rtl8139_hw_start+226/574>
Trace; c01e549c 
Trace; c01dc838 
Trace; c01e549c 
Trace; c01e549c 
Trace; c01dcab7 
Trace; c01e549c 
Trace; d114913c <[8139too].data.end+51d/43e1>
Trace; c01e4a3b 
Trace; c01e549c 
Trace; c01fa5f8 
Trace; c01d71d5 
Trace; c01e4b66 
Trace; c01fa5f8 
Trace; ea0a 
Trace; c01d50ae <__kfree_skb+132/138>
Trace; c01faa8e 
Trace; c01fa5f8 
Trace; ea0a 
Trace; ea0a 
Trace; ea0a 
Trace; c0200236 
Trace; c01d21e5 
Trace; d110b84a <[uhci]uhci_show_queues+13e/228>
Trace; c01e1cd6 
Trace; c01e1e0c 
Trace; d11677d0 <[ipt_LOG].data.end+3bd9/b469>
Trace; d1170ee8 <.bss.end+1465/>
Trace; d110e7e9 <[uhci]alloc_uhci+2c1/310>
Trace; d110b6f5 <[uhci]uhci_is_skeleton_qh+19/30>
Trace; d11099f3 <[usbcore]usbdevfs_root_inode_operations+13/40>
Trace; d110cf3b <[uhci]uhci_submit_bulk+1b3/238>
Trace; d110d264 <[uhci]uhci_result_isochronous+4/a4>
Trace; d110d339 <[uhci]uhci_find_urb_ep+35/d0>
Trace; d110dc2b <[uhci]rh_submit_urb+7b/670>
Trace; d1116cc4 <[sunrpc]xprt_reserve_status+74/7c>
Trace; d1116cc4 <[sunrpc]xprt_reserve_status+74/7c>
Trace; d1116cbc <[sunrpc]xprt_reserve_status+6c/7c>
Trace; d1116cbc <[sunrpc]xprt_reserve_status+6c/7c>
Trace; c0107480 
Trace; d1116cc4 <[sunrpc]xprt_reserve_status+74/7c>
Trace; d1116cd0 <[sunrpc]xprt_request_init+4/90>
Code;  c01e263e 
 <_EIP>:
Code;  c01e263e<=
   0:   8b 40 3c  mov0x3c(%eax),%eax   <=
Code;  c01e2641 
   3:   8b 4c 24 1c   mov0x1c(%esp,1),%ecx
Code;  c01e2645 
   7:   89 41 3c  mov%eax,0x3c(%ecx)
Code;  c01e2648 
   a:   c7 47 18 00 00 00 00  movl   $0x0,0x18(%edi)
Code;  c01e264f 
  11:   8b 54 24 00   mov0x0(%esp,1),%edx

Kernel panic: Aiee, killing interrupt handler!

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

2.4-test5 mkisofs corruption

2000-12-25 Thread Larry McVoy


I have not yet tested later versions, but 2.4-test5 corrupts my jpegs.  I
made an iso image and mounted it in loopback and they are corrupted;  it
is not loopback doing it, I burned a CD and they were corrupted the same
way.  I downgraded to 2.2.18 and that works fine.

If this is a known problem and/or has been addressed, great.  If not, please
ping me and I'll try the latest 2.4 test and see if the problem has gone 
away.

Config:
900Mhz K7 on ASUS A7V MB
PC100 mem w/ ECC (I don't think the board supports that; it's not enabled)
IDE devices:
/dev/hda is a Maxtor 91303D6, 12427MB w/512kB Cache, CHS=25249/16/63
/dev/hdb is a ATAPI 40X CD-ROM drive, 128kB Cache
/dev/hdc is a IBM-DTLA-307045, 43979MB w/1916kB Cache, CHS=5606/255/63
/dev/hdd is a IBM-DTLA-307045, 43979MB w/1916kB Cache, CHS=5606/255/63
SCSI devices:
/dev/sr0 is a MATSHITA CD-ROM, model CD-R   CW-7502
4 ethernet interfaces
eth0: 3Com 3c905B Cyclone 100baseTx
eth1: 3Com 3c905B Cyclone 100baseTx
eth2: 3Com 3c905B Cyclone 100baseTx
eth3: 3Com 3c905 Boomerang 100baseTx
PCI bus devices:
Host bridge: VIA Technologies Unknown device (rev 2).
PCI bridge: VIA Technologies Unknown device (rev 0).
ISA bridge: VIA Technologies Unknown device (rev 34).
IDE interface: VIA Technologies VT 82C586 Apollo IDE (rev 16).
Host bridge: VIA Technologies Unknown device (rev 48).
Ethernet controller: 3Com 3C905B 100bTX (rev 48).
Ethernet controller: 3Com 3C905B 100bTX (rev 48).
Ethernet controller: 3Com 3C905B 100bTX (rev 48).
SCSI storage controller: Adaptec AIC-7850 (rev 3).
Ethernet controller: 3Com 3C905 100bTX (rev 0).
Unknown mass storage controller: Promise Technology Unknown device (rev 2).
VGA compatible controller: Matrox Matrox G200 AGP (rev 1).
-- 
---
Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots

2000-12-25 Thread Thorsten Kranzkowski

On Mon, Dec 25, 2000 at 06:09:35AM +0100, Mike Galbraith wrote:
> I wouldn't (not going to here;) spend a lot of time on it.  The compiler
> has problems.  It won't build glibc-2.2, and chokes horribly on ipchains.
> 
> int ipt_register_table(struct ipt_table *table)
> {
>   int ret;
>   struct ipt_table_info *newinfo;
>   static struct ipt_table_info bootstrap
>   = { 0, 0, { 0 }, { 0 }, { } };
>^
> ip_tables.c:1361: Internal compiler error in array_size_for_constructor, at 
>varasm.c:4456

Well, I  'fixed' this by changing above line to:
= { 0, 0, { 0 }, { 0 }, };
and repeating this change (deleting the braces) about 15 times in 2 or 3 other 
files of iptables. (patch available on request)
Of course gcc shouldn't die but issue a useful message if/when syntax rules
may have changed.

Apart from that and a hand-edited arch/alpha/vmlinux.lds that got some 
newlines wrong, the kernel compiled fine and is up for over a day now.
Though this is not intel but alpha (ev4 / AXPpci33).

Marvin:~$ uname -a
Linux Marvin 2.4.0-test13pre4-ac2 #13 Sun Dec 24 15:26:57 UTC 2000 alpha unknown
Marvin:~$ uptime
  8:19pm  up 1 day,  4:28,  4 users,  load average: 0.00, 0.00, 0.00
Marvin:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/alpha-unknown-linux-gnu/2.97/specs
Configured with: ../gcc-20001211/configure --enable-threads --enable-shared 
--prefix=/usr --enable-languages=c,c++
gcc version 2.97 20001211 (experimental)

I use iptables for masquerading my local ethernet and that works as expected
so far.

Thorsten.

-- 
| Thorsten KranzkowskiInternet: [EMAIL PROTECTED]|
| Mobile: ++49 170 1876134   Snail: Niemannsweg 30, 49201 Dissen, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: About Celeron processor memory barrier problem

2000-12-25 Thread Ian Stirling


> 
> [EMAIL PROTECTED] (Tim Wright)  wrote on 24.12.00 in 
><[EMAIL PROTECTED]>:
> 
> > On Sun, Dec 24, 2000 at 11:36:00AM +0200, Kai Henningsen wrote:
> 
> > There was a similar thread to this recently. The issue is that if you
> > choose the wrong processor type, you may not even be able to complain.
> 
> Hmm ... I think I can see ways around that (essentially similar to the 16  
> bit bootstrap code), but it may indeed be more trouble than it's worth.

What about a simple solution, 
"Ok, Booting the kernel for i486+fpu and above."

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

Re: innd mmap bug in 2.4.0-test12

2000-12-25 Thread Marco d'Itri


On Dec 25, Linus Torvalds <[EMAIL PROTECTED]> wrote:

 >Add a printk() to __remove_inode_page() that complains whenever it removes
 >a dirty page. 
 >
 >Oh, in order to not see this with swap pages (which _can_ be removed when
 >they are dirty, if all users of them are gone), add a PageClearDirty() to
 >"remove_from_swap_cache()" so that we don't get false positives..
 >
 >Do you get any messages? I don't think you will, but it should be tested.
I read you found the real cause so that may be bogus, but I have got two
messages while booting. The first showed up while doing the fsck of a 6
GB file systems and killed the process (fscks of smaller partitions
completed successfully), the second occured while initializing
/dev/random and left an unkillable dd process and a stuck boot process
(I gathered this info with sysrq).

Being -test12 unstable for me, if you don't need more data I'll go back
to -test9 until the next release.

 >That's probably the infinite loop in the tty task queue handling, should
 >be fixed in test13-pre3 or so.
Looks like I missed it, evil vger postmasters unsubscribed me again for
no apparent reason...

-- 
ciao,
Marco

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

Re: BIOS problem, pro Microsoft, anti other OS


Jacques

> Can you check what does Linux 2.4.0-test behave, please?
Are you comfortable compiling kernels?
If not I'll compile one for you for the test.
Currently I'm happily under 2.4.0-test 12: 
   lsmod:
Module  Size  Used by
ppp_deflate39164   1  (autoclean)
bsd_comp4148   0  (autoclean)
ppp_async   6220   1  (autoclean)
ppp_generic12820   2  (autoclean) [ppp_deflate bsd_comp
ppp_async]
ltmodem   364948   1
input   3328   0
serial 42192   1  (autoclean) (ONLY suporting my mouse)
isa-pnp27528   0  (autoclean) [ltmodem serial]
usbcore27684   0  (unused) 

Martin  
   Are there any particular kernel config choices that will be
beneficial for this problem?

Mark
> You probably should make the ltmodem driver check the region base
> registers and interrupts and if they are not set, recommend the user to
> change the OS or PNP settings in their BIOS setup.
Can these be included in the LTmodem packages you are working up?

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

Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots

On Mon, 25 Dec 2000, Andreas Franck wrote:

> Hello Mike, hello linux-kernel hackers,
> 
> Mike Galbraith wrote:
> > I wouldn't (not going to here;) spend a lot of time on it.  The compiler
> > has problems.  It won't build glibc-2.2, and chokes horribly on ipchains.
> 
> Maybe, but you were lucky getting an ICE, and not silently failing code :-)

You bet.

> After having spent several hours debugging now, I think it was 
> worth it (at least for my understanding of lower-level kernel issues and of 
> the (rather nice and almost readable) assembly code gcc generates). There 

Don't get me wrong, chasing things like this is never a waste of time.
In the case of gcc in particular.  Our next 'stable' kernel compiler
is going to come from the gcc development tree just as the next 'stable'
kernel is coming out of the kernel development tree.

-Mike

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

Re: css hang; somewhere between test12 and test13pre4ac2


Hi Jens,
  Thanks for the patch; unfortunatly at the moment I can neither confirm
or deny whether the patch works - since the damn thing won't crash on me
with or without the patch - I suspect it depends on system mood.

But I have a PDA logging console so if it happens I should catch it.

Thanks again,

Dave

-- 
  Have a happy GNU millennium! --   
/ Dr. David Alan Gilbert  | Running GNU/Linux on   |  Happy  \ 
\   gro.gilbert @ treblig.org |  Alpha, x86, ARM and SPARC |  In Hex /
 \ ___|___ http://www.treblig.org  |/

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

Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots


On Mon, 25 Dec 2000, Andreas Franck wrote:

> Hello Mike, hello linux-kernel hackers,
> 
> Mike Galbraith wrote:
> > I wouldn't (not going to here;) spend a lot of time on it.  The compiler
> > has problems.  It won't build glibc-2.2, and chokes horribly on ipchains.
> 
> Maybe, but after having spent several hours debugging now, I think it was 
> worth it: I am almost sure this is not a gcc bug, but a nasty race condition 
> involving the semaphore handling bdflush_init. 
> 
> I figured out by spilling some printk's around in bdflush_init, which made 
> the bug magically disappear, what wasn't what I intended - but which gave me 
> a clearer impression of what's going on.

Oh?  Can you show me (offline) what you did exactly that made it go away?
(that's kinda scary.. _much_ prefer 'compiler has rough edges' option;)

-Mike

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

Re: Netgear FA311

On Mon, 25 Dec 2000, Manfred wrote:

> Could you try this setup?
> 
>  /* Configure the PCI bus bursts and FIFO thresholds. */
>  /* Configure for standard, in-spec Ethernet. */
>  np->tx_config = (1<<28) +   /* Automatic transmit padding */
>  (1<<23) +   /* Excessive collision retry */
>  (6<<20) + /* Max DMA burst = 128 byte */
>  (8<<8) +/* fill threshold = 256 byte */
>  8;  /* drain threshold = 256 byte */
>  writel(np->tx_config, ioaddr + TxConfig);
> 

Hmm, that little change worked a lot better. However thoughput is down to
700kb/s! Transferring files from the other machine to this machine is much
faster - 868kb/s.

In the logs, I only got *one* message from the natsemi driver (and this
happened when sending files from this machine to the other machine. No
problems receiving from the other machine.

Dec 25 17:28:12 tahallah kernel: eth0: Something Wicked happened! 0583.

But I just realised that the other machine I'm using has an 10 megabit
ethernet card (on the hub that one is shown on 10, my machine is shown as
100). I think this explains the throughput problem. When I get another 4
way power socket, I'll put my other machine (which has a 100 megabit card
in it) on the network and see if that makes a difference.

Cheers,
Alex
-- 
Huffapuff!

http://www.tahallah.clara.co.uk

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

Re: Netgear FA311


Alex wrote:
> In the logs I'm seeing this: 
> 
> Dec 25 15:25:18 tahallah last message repeated 2 times 
> Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0783. 
> Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0780. 

783 means:
Tx Underrun
Tx Idle
Tx Packet Error
Tx Descriptor
Rx Packet Error
Rx Descriptor
Rx OK.

Hmm. I download the Documentation from National
(http://www.national.com/pf/DP/DP83815.html),
and the the tx burst size/fill threshold/drain threshold combination is
invalid:

 from natsemi.c:
 /* Configure the PCI bus bursts and FIFO thresholds. */
 /* Configure for standard, in-spec Ethernet. */
 np->tx_config = (1<<28) +   /* Automatic transmit padding */
 (1<<23) +   /* Excessive collision retry */
 (0x0<<20) + /* Max DMA burst = 512 byte */
 (8<<8) +/* fill threshold = 256 byte */
 2;  /* drain threshold = 64 byte */
 writel(np->tx_config, ioaddr + TxConfig);


But:
 page 51
The MXDMA MUST NOT be greater than the Tx Fill Threshold 
>>

Could you try this setup?

 /* Configure the PCI bus bursts and FIFO thresholds. */
 /* Configure for standard, in-spec Ethernet. */
 np->tx_config = (1<<28) +   /* Automatic transmit padding */
 (1<<23) +   /* Excessive collision retry */
 (6<<20) + /* Max DMA burst = 128 byte */
 (8<<8) +/* fill threshold = 256 byte */
 8;  /* drain threshold = 256 byte */
 writel(np->tx_config, ioaddr + TxConfig);


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

Re: test13-pre4... udf problem with dvd access vs test12

On Mon, Dec 25 2000, Mohammad A. Haque wrote:
> Fix confirmed. Am i supposed to get some DriveSense errors? I probably
> am just don't recall.

Good. The whole idea of cdrom_log_sense is to be able to cleanly
limit the (often) sense-less (yes, haha :) ide-cd verbosity. Some of the
css stuff are obvious candidates. We want users to be aware of the
error, but often we end up flooding the logs with the same stuff over
and over again. This is often a source of confusion for the casual
user.

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

serial mouse - lockup connection 2.4.0-t12

2000-12-25 Thread dep


greetings!

the lockup of test12 leaves no droppings i can find, but in the 
course of a half-dozen lockups in the last few days i've made an 
observation or two that may be of diagnostic help.

system is a k6-2 on a via chipset mb with onboard everything but 
video (fic va-503a). kernel built with gcc-2.95.2. glibc is 2.2.

the lockups occur during mouse movement -- mouse is kensington 
emulating microsoft. the peculiar thing is that the mouse 
acceleration seems to slow a little in the seconds before the lockup. 
i don't know that this is a useful datum, but it seemed as if it 
might be significant.

the lockups are otherwise neither predictable or reproducible.
-- 
dep
--
bipartisanship: an illogical construct not unlike the idea that
if half the people like red and half the people like blue, the 
country's favorite color is purple.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre4... udf problem with dvd access vs test12

Sorry, I meant DriveReady SeekComplete Error

"Mohammad A. Haque" wrote:
> Fix confirmed. Am i supposed to get some DriveSense errors? I probably
> am just don't recall.

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre4... udf problem with dvd access vs test12

Fix confirmed. Am i supposed to get some DriveSense errors? I probably
am just don't recall.

Jens Axboe wrote:
> Yes I know about this one, I've attached the patch here again. Linus,
> could you apply?
> 
> --- drivers/ide/ide-cd.c~   Sat Dec 23 23:59:52 2000
> +++ drivers/ide/ide-cd.cSun Dec 24 00:03:38 2000
> @@ -333,7 +333,7 @@
>  {
> int log = 0;
> 
> -   if (sense == NULL || pc->quiet)
> +   if (sense == NULL || pc == NULL || pc->quiet)
> return 0;
> 
> switch (sense->sense_key) {
> 
> --
> * Jens Axboe <[EMAIL PROTECTED]>
> * SuSE Labs

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre4... udf problem with dvd access vs test12


On Mon, Dec 25 2000, Mohammad A. Haque wrote:
> Jens, I made sure to reverse the udf patch I mentioned in another thread
> (all it really is merging changes from linux-udf cvs into the current
> kernel). So this is from a clean test13-pre4 w/ some netfilter fixes.

Ok, looks unrelated however.

> >>EIP; c019c017<=

Yes I know about this one, I've attached the patch here again. Linus,
could you apply?

--- drivers/ide/ide-cd.c~   Sat Dec 23 23:59:52 2000
+++ drivers/ide/ide-cd.cSun Dec 24 00:03:38 2000
@@ -333,7 +333,7 @@
 {
int log = 0;
 
-   if (sense == NULL || pc->quiet)
+   if (sense == NULL || pc == NULL || pc->quiet)
return 0;
 
switch (sense->sense_key) {

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

Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots

Hello Mike, hello linux-kernel hackers,

Mike Galbraith wrote:
> I wouldn't (not going to here;) spend a lot of time on it.  The compiler
> has problems.  It won't build glibc-2.2, and chokes horribly on ipchains.

Maybe, but after having spent several hours debugging now, I think it was 
worth it: I am almost sure this is not a gcc bug, but a nasty race condition 
involving the semaphore handling bdflush_init. 

I figured out by spilling some printk's around in bdflush_init, which made 
the bug magically disappear, what wasn't what I intended - but which gave me 
a clearer impression of what's going on.

It seems that whyever, the cause for this failure is actually the down(sem) 
call on a not yet up()'ed semaphore, and this is where it starts to get ugly.

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

Re: BIOS problem, pro Microsoft, anti other OS

2000-12-25 Thread Martin Mares


Hello!

> This alert should probably be forwarded to Others, but appropriate
> subTask persons in the kernel-source Maintainers list were not obvious.
> 
> Briefly, documented below is the fact/complications that some PC BIOS
> chips are now coming with a default Microsoft setting, which makes them
> hostile to some functionalities of other OS.  If particular under Linux,
> a PCI Winmodem did NOT function with the Win98 BIOS setting, but did
> fine  with BIOS choice "Other OS".  Possible, other PCI devices under
> Linux OS might be simmilarly afflicated.
> 
> This indicates a need for Linux install software to be equipped with a
> utility to probe the BIOS and report back "Linux hostile" BIOS
> settings.  Today most Newbies are getting new PC boxes equipped with
> WinModems.  Hostile BIOS settings will block their capability to get
> on-line.  Unfortunately, I do not have the technical capablity to
> directly contribute.  Thus please forward this alert to however may be
> capable and concerned with dealing with the problem.

Can you check what does Linux 2.4.0-test behave, please?

I know of these problems and I hope the new PCI code in 2.4.0 is able
to assign the missing memory/IO resources without help of the BIOS, but
unfortunately 2.2 isn't and it's very difficult to back-port the fixes
as they depend on changes in many other parts of the kernel.

You probably should make the ltmodem driver check the region base
registers and interrupts and if they are not set, recommend the user to
change the OS or PNP settings in their BIOS setup.

Have a nice fortnight
-- 
Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/
First law of socio-genetics: Celibacy is not hereditary.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots

Hello Mike, hello linux-kernel hackers,

Mike Galbraith wrote:
> I wouldn't (not going to here;) spend a lot of time on it.  The compiler
> has problems.  It won't build glibc-2.2, and chokes horribly on ipchains.

Maybe, but you were lucky getting an ICE, and not silently failing code :-)

After having spent several hours debugging now, I think it was 
worth it (at least for my understanding of lower-level kernel issues and of 
the (rather nice and almost readable) assembly code gcc generates). There 
seems to be something going wrong in the down(sem) path after the 
kernel_thread call. 

I'm not sure if down() succeeds instantly when compiling the kernel with 
2.95.2, but it seems to fail for 2.97; I figured out by spilling some 
printk's around in bdflush_init, which made the bug magically disappear, due 
to the looser timing. This also might happen for compiling with frame 
pointers or with the static declaration variables, somehow.

Th bdflush_init function itself does not seem to be responsible, which 
corresponds with the assembly, which is fine and should get the same results 
for all compiled cases.

It seems that whyever, the cause for this failure is actually the down(sem) 
call on a not yet up()'ed semaphore, and this is where it starts to get ugly.

down() then calls __down_failed, which ends up in __down(); __down does some 
waitqueue handling, which I don't understand, and then calls __wake_up - up 
to then, everything seems fine, in __wake_up it is where my search ended up 
to now, but I think something is wrong in this context; however, the 
complexity of this code exceeds my knowledge by magnitudes, so I can't 
continue searching there without going mad :-)

It would be nice if someone else could look from there on, now I've narrowed 
the case down to rather low-level functions.

Greetings,
Andreas

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

Re: css hang; somewhere between test12 and test13pre4ac2

Heh, just go it. Testing

Jens Axboe wrote:
> 
> Thanks. If it's the cdrom_log_sense oops, please try also with
> previously sent patch.

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre4... udf problem with dvd access vs test12


Jens, I made sure to reverse the udf patch I mentioned in another thread
(all it really is merging changes from linux-udf cvs into the current
kernel). So this is from a clean test13-pre4 w/ some netfilter fixes.

ksymoops 0.7c on i686 2.4.0-test13-pre4.  Options used
 -V (default)
 -K (specified)
 -L (specified)
 -o /lib/modules/2.4.0-test13-pre4/ (default)
 -m /usr/src/linux/System.map (default)

No modules in ksyms, skipping objects
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010082
eax:    ebx:    ecx: d5efc610   edx: d3efc610 
esi: 0001   edi: c02fa0a4   ebp: 0003   esp: c0297e84
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c0297000)
Stack: c02fa0a4 c019c088 c02fa0a4  d3efc610 d3efc650 0001
c02fa0a4 
   0003 c1578078 c019269e c019d2d5 c02fa0a4 0012 c019d260
c019d4d8 
   c02fa0a4  c02fa0a4 d3efc650 c0192a09 c02fa0a4 d3efc650
 
Call Trace: [<0019c08b>] [] [] []
[] [] [] 
   [] [] [] [] []
[] [] [] 
   [] [] [] [] []
[] [] [] 
Code: 83 78 0c 00 74 04 31 c0 eb 4a 8a 42 02 24 0f 0f b6 c0 83 f8 

>>EIP; c019c017<=
Trace; 0019c08b Before first symbol
Trace; c019269e 
Trace; c019d2d5 
Trace; c019d260 
Trace; c019d4d8 
Trace; c0192a09 
Trace; c019c464 
Trace; c019d173 
Trace; c011ccd2 
Trace; c0193127 
Trace; c019d0ac 
Trace; c010a04f 
Trace; c010a1ac 
Trace; c01071f0 
Trace; c01071f0 
Trace; c0108e94 
Trace; c01071f0 
Trace; c01071f0 
Trace; c0100018 
Trace; c0107213 
Trace; c0107279 
Trace; c0105000 
Trace; c0100191 
Code;  c019c017 
 <_EIP>:
Code;  c019c017<=
   0:   83 78 0c 00   cmpl   $0x0,0xc(%eax)   <=
Code;  c019c01b 
   4:   74 04 je a <_EIP+0xa> c019c021

Code;  c019c01d 
   6:   31 c0 xor%eax,%eax
Code;  c019c01f 
   8:   eb 4a jmp54 <_EIP+0x54> c019c06b

Code;  c019c021 
   a:   8a 42 02  mov0x2(%edx),%al
Code;  c019c024 
   d:   24 0f and$0xf,%al
Code;  c019c026 
   f:   0f b6 c0  movzbl %al,%eax
Code;  c019c029 
  12:   83 f8 00  cmp$0x0,%eax



"Mohammad A. Haque" wrote:
> 
> I just captured the oops.
> 
> It happens when you try to mount (mount -t udf /dev/foo /mnt/bar) an
> encrypted dvd. At least it does on my end. Unencrypted dvds mount fine.
> 
> ksymoops coming soon.
> 

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: css hang; somewhere between test12 and test13pre4ac2


On Mon, Dec 25 2000, Mohammad A. Haque wrote:
> This is confirmed. mounting css dics causes oops. non-css discs work
> fine. 
> 
> oops coming soon.

Thanks. If it's the cdrom_log_sense oops, please try also with
previously sent patch.

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

Re: css hang; somewhere between test12 and test13pre4ac2

This is confirmed. mounting css dics causes oops. non-css discs work
fine. 

oops coming soon.

Jens Axboe wrote:
> The most likely suspect (as someone else pointed out) is not at
> all css (I'm not even sure what you mean by css hang?) but UDF.
> Given the fs changes. Since sysrq still works, it would help a
> lot if you could capture sysrq-p repeatedly and send it in.
> 
> Do you have any non-css discs to beat on UDF?
> 
> --
> * Jens Axboe <[EMAIL PROTECTED]>
> * SuSE Labs
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre4... udf problem with dvd access vs test12

I just captured the oops.

It happens when you try to mount (mount -t udf /dev/foo /mnt/bar) an
encrypted dvd. At least it does on my end. Unencrypted dvds mount fine.

ksymoops coming soon.

Frank Jacobberger wrote:
> 
> Odd happening here. Been running good as gold through test12 with
> accessing my dvd to using oms. Now updating to test13-pre4
> I get a complete lock up of my whole system when executing oms.
> 
> I can access the drive via mounting it... with no trouble what ever.
> 
> Here is a snip from my message file No clue what to test for here...
> 
> Perhaps udf.c is the problem?
> 
> Any ideas?

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

BIOS problem, pro Microsoft, anti other OS


To Maintainer:
PCI SUBSYSTEM
P:  Martin Mares
M:  [EMAIL PROTECTED]
L:  [EMAIL PROTECTED]
S:  Supported

This alert should probably be forwarded to Others, but appropriate
subTask persons in the kernel-source Maintainers list were not obvious.

Briefly, documented below is the fact/complications that some PC BIOS
chips are now coming with a default Microsoft setting, which makes them
hostile to some functionalities of other OS.  If particular under Linux,
a PCI Winmodem did NOT function with the Win98 BIOS setting, but did
fine  with BIOS choice "Other OS".  Possible, other PCI devices under
Linux OS might be simmilarly afflicated.

This indicates a need for Linux install software to be equipped with a
utility to probe the BIOS and report back "Linux hostile" BIOS
settings.  Today most Newbies are getting new PC boxes equipped with
WinModems.  Hostile BIOS settings will block their capability to get
on-line.  Unfortunately, I do not have the technical capablity to
directly contribute.  Thus please forward this alert to however may be
capable and concerned with dealing with the problem.

MarvS, co-maintainer: http://walbran.org/sean/linux/linmodem-howto.html

===
Subject:  Device or resource busy : SUCCESS !
 Date: Sun, 24 Dec 2000 14:46:04 +0200 (IST)
From: Jacques Goldberg <[EMAIL PROTECTED]>
 Reply-To:  Jacques Goldberg <[EMAIL PROTECTED]>
   To: [EMAIL PROTECTED]

 Well, my very sincere thanks to all of you. It works.

DETAILS:
I purchased a Gateway Solo 2550 in September, comes with ActionTec PCI
56k
modem (Lucent chip vendor 11c1, device 448).
I tried the 568 ltmodem: device or resource busy,could not guess why.
cat /pro/pci would show no interrupt
Then ltmodem 578  was made available: same problem.
But then the PnP issue at boot came again last week.
I had tried several times to discover the option in my BIOS setup.
This morning I found: in the "advanced" page there is an "Operating
System" option, to be set to "the most frequently used OS". I had left
it
as Win98/2000 (as I received the machine). 
I just selected OTHER.
Lo and behold, ltmodem.o loads without a flaw, I then had a short dumb
terminal session with minicom, and am now connected at my first attempt
with ppp, having already used X11, ssh, and Netscape.

So, again my deepest thanks to all of you on this list, and the bottom
line for newcomers:

 IF (Device.or.resource busy) CHECK YOUR BIOS.

By the way I am running RH-6.1, kernel 2.2.12-20 (CERN "official" Linux
distribution). They are on vacations now, I cannot check at this time if
their version of ppp is "generic" or reworked.

Jacques J. Goldberg
[EMAIL PROTECTED]
 Currently at TECHNION 
PHONE: Technion=+(972)(0)(4)829.36.63
   CERN=+(41)(22)767.84.72
  Original Message 
Subject: Crippling BIOSes
Date: Sun, 24 Dec 2000 14:55:36 -0500
From: Marvin Stodolsky <[EMAIL PROTECTED]>
To: LinModems <[EMAIL PROTECTED]>

Folks,
Given Jacques report, it would be good to set up a
diagnostic for BIOS which have such Microsoft/Other choices.  
Mine does not.
For those of you who have such BIOSes, please 
1) Do  boots under both choices
2) Under microsoft do:
  dmesg > ms.txt
3) Under other
   dmesg > other.txt
4) diff ms.txt other.txt
and report the differences to the List with the name of the BIOS.
If would clearly be desirable to equip future Linux kernels/software to
give a warning about the crippling microsoft option, 
which may hamper other PCI harware under Linux as well.

MarvS   

 Original Message 
Subject:   Re: dmesg detection??
 Date:   Mon, 25 Dec 2000 09:29:20 +0200 (IST)
From:Jacques Goldberg <[EMAIL PROTECTED]>
 Reply-To:   Jacques Goldberg <[EMAIL PROTECTED]>
   To:   Marvin Stodolsky <[EMAIL PROTECTED]>
  CC:[EMAIL PROTECTED]

 Gateway Solo 2150
 Phoenix BIOS version 17.50
 BIOS Page "Advanced"
 BIOS Field "Installed O/S" may be "Other" "Win98/Win2000" or "Win95"
 Did not try "Win95"
 Default was Win98/Win2000, dmesg file attached is  ms.txt
 Changed to "Other" , dmesg file atached is  other.txt

 Linux kernel 2.2.12-20
 
 SOUND:
  CONFIG_SOUND set to "m"
  Using OSS driver (ES-1371 not supported by RH-6.1  2.2.12-20
distribution)
  Using PPP version 2.3.10-3

 Everything works fine (ppp sessions with sound) once BIOS O/S choice
set
to OTHER.
 
 I repeat what my problem was:
 -could not load ltmodem : "Device or resource busy"
 -cat /pro/pci did not show IRQ, not even the word IRQ, for Lucent modem
 -setting BIOS to OTHER instantly made everything work.

Jacques J. Goldberg
[EMAIL PROTECTED]


 dmesg > ms.txt (Win98 BIOS setting)

Linux version 2.2.12-20 ([EMAIL PROTECTED]) (gcc version

Re: Proposal: devfs names ending in %d or %u

2000-12-25 Thread idalton

On Sun, Dec 24, 2000 at 11:02:39PM -0800, Barry K. Nathan wrote:
> Eric Shattow wrote:
> [snip]
> > when i insert a FAT formatted disc with a PC partition table, the partition
> > i want to mount is part1.  when i insert a HFS formatted disc with a MAC
> > partition table, the partition i want to mount is part4. this is very ugly,
> 
> and it has nothing to do with devfs. Those would be /dev/sda1 (adjust
> device name for IDE instead of SCSI, etc.) and /dev/sda4 without devfs.
> 
> In this case, the problem is that different Zip disks really do have their
> data on different partitions. (If you use enough different disks and
> formatting utilities, it won't even be the same partition for all PC disks
> or all Mac disks, IIRC.) I don't use Zip disks much anymore, although
> there's a similar phenomenon with my SCSI MO drive on my desktop Mac
> (which I recently started using Linux on again).
[snip]

And don't forget that IDE zip drives can be programmed to hide the
partition table altogether from the OS. Supposedly this can be changed
via an ATAPI command to the drive, but I don't think the kernel driver
has any support for this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] CONFIG_MOUSE should not be tristate

2000-12-25 Thread Pavel Roskin


Hello!

CONFIG_MOUSE only enables further questions. It is never used except
drivers/char/Config.in where it's checked for being "n".

CONFIG_MOUSE=m makes no sence.

The patch is against 2.4.0-test13-pre4.

___
--- linux.orig/drivers/char/Config.in
+++ linux/drivers/char/Config.in
@@ -95,7 +95,7 @@
fi
 fi

-tristate 'Mouse Support (not serial and bus mice)' CONFIG_MOUSE
+bool 'Mouse Support (not serial and bus mice)' CONFIG_MOUSE
 if [ "$CONFIG_MOUSE" != "n" ]; then
bool '  PS/2 mouse (aka "auxiliary device") support' CONFIG_PSMOUSE
tristate '  C 82C710 mouse port support (as on TI Travelmate)' 
CONFIG_82C710_MOUSE
___

Regards,
Pavel Roskin

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

Netgear FA311


Well now I've just set up the network and everything works a treat,
currently getting 850kb/s file transfers. Cool. Except for one thing.

In the logs I'm seeing this:

Dec 25 15:25:18 tahallah last message repeated 2 times
Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0783.
Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0780.
Dec 25 15:25:19 tahallah last message repeated 2 times
Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0580.
Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0783.
Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0780.
Dec 25 15:25:21 tahallah last message repeated 3 times
Dec 25 15:25:21 tahallah kernel: eth0: Something Wicked happened! 0783.
Dec 25 15:25:22 tahallah kernel: eth0: Something Wicked happened! 0780.

That's just a small snippet. Apart from those messages, all seems OK, but
I'm just wondering why it's getting those messages - what does those mean?

Cheers,
Alex
-- 
Huffapuff!

http://www.tahallah.clara.co.uk

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

Re: Masquerade hangups

2000-12-25 Thread Harald Welte


On Sun, Dec 24, 2000 at 09:02:12AM -0600, Mike Elmore wrote:
> Hello,
> 
> 
> I seem to get pretty good performance from 
> internet->masq box and from masq box->internal
> lan, but when a internal box tries to get to the
> net through the masquerade, connection seem to time
> out.  I'll get a pretty good initial burst, then
> connections stall.

please join the netfilter/iptables mailinglist (instructions on
http://netfilter.kernelnotes.org) and file us a detailed report.

It's a good idea to save linux-kernel from all the nifty details :)

> I'm using test13-pre4.  I saw some iptables stuff on
> the list a week or so ago, was this fixed in pre4 or
> is this my problem?

we (the netfilter core team) are currently not aware
of any bugs at the moment. The behaviour you've described
wasn't reported by anybody else.

> -mwe
> [EMAIL PROTECTED]

-- 
Live long and prosper
- Harald Welte / [EMAIL PROTECTED]http://www.gnumonks.org

GCS/E/IT d- s-: a-- C+++ UL$ 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+(*)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4.0test13pre4ac2

2000-12-25 Thread Andi Kleen


On Mon, Dec 25, 2000 at 10:37:54PM +1100, Andrew Morton wrote:
> Alan Cox wrote:
> > 
> > 2.4.0test13pre4-ac2
> >
> > o   Make smp cpu halt synchronous   (Andi Kleen)
> 
> errr, Andi. 
> 
> We're asking all the other CPUs to call stop_this_cpu(), and then waiting
> for them to complete the call.
> 
> But stop_this_cpu() never returns, so the machine gets stuck.

Right, it's wrong. Thanks for spotting that.

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

Re: TCP keepalive seems to send to only one port

2000-12-25 Thread Cesar Eduardo Barros


On Mon, Dec 25, 2000 at 04:27:07PM +0100, Igmar Palsenberg wrote:
> 
> > Yeah. But I'm stuck with a NAT (which isn't mine, btw) which uses 2.1.xxx-2.2.x
> > (according to nmap). Which had a default of 15 *minutes* (as I read in a HOWTO
> > somewhere). I'm trying to convince the sysadmin to raise it to two hours, but I
> > bet it'll be hard.
> 
> ipchains -S timeoutval 0 0 is the only way to do this.
> 

That's the easy part. Convincing the sysadmin (which probably is not very
clueful) is the hard one. But this is getting too OT, EOT.

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

Re: About Celeron processor memory barrier problem

2000-12-25 Thread Kai Henningsen


[EMAIL PROTECTED] (Tim Wright)  wrote on 24.12.00 in 
<[EMAIL PROTECTED]>:

> On Sun, Dec 24, 2000 at 11:36:00AM +0200, Kai Henningsen wrote:

> There was a similar thread to this recently. The issue is that if you
> choose the wrong processor type, you may not even be able to complain.

Hmm ... I think I can see ways around that (essentially similar to the 16  
bit bootstrap code), but it may indeed be more trouble than it's worth.

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

Re: TCP keepalive seems to send to only one port

2000-12-25 Thread Igmar Palsenberg



> Yeah. But I'm stuck with a NAT (which isn't mine, btw) which uses 2.1.xxx-2.2.x
> (according to nmap). Which had a default of 15 *minutes* (as I read in a HOWTO
> somewhere). I'm trying to convince the sysadmin to raise it to two hours, but I
> bet it'll be hard.

ipchains -S timeoutval 0 0 is the only way to do this.


Igmar

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

[PATCH] winbond-840 updates, tester needed!


I found a few minor problems in the current winbond driver:

* the current driver hangs/crashes during module unload.
* it doesn't use the new pci dma mapping interface
* it assumed strong memory ordering without explicit wmb()'s.
* it contains the tx_full race that Andrew Morton found.

The patch fixes these bugs. I've tested it on i386 SMP.

I need a tester with a winbond card on a computer with a big endian cpu,
any volunteers?

There are at least 2 outstanding problems with big endian cpus:

* a warning from Donald Becker that one eeprom read is broken for
big-endian machines.

* the driver doesn't use the "Descriptor Big Endian" (bit 20 of register
0) mode, instead it uses cpu_to_le32.

--
  Manfred

--- 2.4/drivers/net/winbond-840.c   Sun Dec 17 18:03:56 2000
+++ build-2.4/drivers/net/winbond-840.c Mon Dec 25 12:49:36 2000
@@ -21,11 +21,21 @@
Do not change the version information unless an improvement has been made.
Merely removing my name, as Compex has done in the past, does not count
as an improvement.
+
+   Changelog:
+   * ported to 2.4
+   ???
+   * spin lock update, memory barriers, new style dma mappings
+   Manfred Spraul
+
+   TODO:
+   * according to the documentation, the chip supports big endian
+   internally. Replace the cpu_to_le32 with that bit.
 */
 
 /* These identify the driver base version and may not be removed. */
 static const char version1[] =
-"winbond-840.c:v1.01 5/15/2000  Donald Becker <[EMAIL PROTECTED]>\n";
+"winbond-840.c:v1.01 (2.4 port) 5/15/2000  Donald Becker <[EMAIL PROTECTED]>\n";
 static const char version2[] =
 "  http://www.scyld.com/network/drivers.html\n";
 
@@ -114,12 +124,6 @@
 #include 
 #include 
 
-/* Condensed operations for readability.
-   The compatibility defines are in kern_compat.h */
-
-#define virt_to_le32desc(addr)  cpu_to_le32(virt_to_bus(addr))
-#define le32desc_to_virt(addr)  bus_to_virt(le32_to_cpu(addr))
-
 MODULE_AUTHOR("Donald Becker <[EMAIL PROTECTED]>");
 MODULE_DESCRIPTION("Winbond W89c840 Ethernet driver");
 MODULE_PARM(max_interrupt_work, "i");
@@ -298,9 +302,12 @@
 
 #define PRIV_ALIGN 15  /* Required alignment mask */
 struct netdev_private {
-   /* Descriptor rings first for alignment. */
-   struct w840_rx_desc rx_ring[RX_RING_SIZE];
-   struct w840_tx_desc tx_ring[TX_RING_SIZE];
+   struct w840_rx_desc *rx_ring;
+   dma_addr_t  rx_addr[RX_RING_SIZE];
+   struct w840_tx_desc *tx_ring;
+   dma_addr_t  tx_addr[RX_RING_SIZE];
+   dma_addr_t ring_dma_addr;
+   struct pci_dev *pdev;
/* The addresses of receive-in-place skbuffs. */
struct sk_buff* rx_skbuff[RX_RING_SIZE];
/* The saved address of a sent-in-place packet/buffer, for later free(). */
@@ -335,7 +342,7 @@
 static void check_duplex(struct net_device *dev);
 static void netdev_timer(unsigned long data);
 static void tx_timeout(struct net_device *dev);
-static void init_ring(struct net_device *dev);
+static int init_ring(struct net_device *dev);
 static int  start_tx(struct sk_buff *skb, struct net_device *dev);
 static void intr_handler(int irq, void *dev_instance, struct pt_regs *regs);
 static void netdev_error(struct net_device *dev, int intr_status);
@@ -364,6 +371,11 @@
return -EIO;
pci_set_master(pdev);
 
+   if(!pci_dma_supported(pdev,0x)) {
+   printk(KERN_WARNING "Winbond-840: Device %s disabled due to DMA 
+limitations.\n",
+   pdev->name);
+   return -EIO;
+   }
dev = init_etherdev(NULL, sizeof(*np));
if (!dev)
return -ENOMEM;
@@ -403,6 +415,7 @@
np = dev->priv;
np->chip_id = chip_idx;
np->drv_flags = pci_id_tbl[chip_idx].drv_flags;
+   np->pdev = pdev;
spin_lock_init(>lock);

pdev->driver_data = dev;
@@ -632,10 +645,12 @@
printk(KERN_DEBUG "%s: w89c840_open() irq %d.\n",
   dev->name, dev->irq);
 
-   init_ring(dev);
+   if((i=init_ring(dev)))
+   return i;
 
-   writel(virt_to_bus(np->rx_ring), ioaddr + RxRingPtr);
-   writel(virt_to_bus(np->tx_ring), ioaddr + TxRingPtr);
+   writel(np->ring_dma_addr, ioaddr + RxRingPtr);
+   writel(np->ring_dma_addr+sizeof(struct w840_rx_desc)*RX_RING_SIZE,
+   ioaddr + TxRingPtr);
 
for (i = 0; i < 6; i++)
writeb(dev->dev_addr[i], ioaddr + StationAddr + i);
@@ -733,11 +748,13 @@
   "config %8.8x.\n",
   dev->name, (int)readl(ioaddr + IntrStatus),
   (int)readl(ioaddr + NetworkConfig));
+   spin_lock_irq(>lock);
check_duplex(dev);
if (np->csr6 != old_csr6) {
writel(np->csr6 & ~0x0002, ioaddr + NetworkConfig);
writel(np->csr6 | 0x2002, ioaddr + NetworkConfig);

Re: css hang; somewhere between test12 and test13pre4ac2


On Mon, Dec 25 2000, Dave Gilbert wrote:
> > The most likely suspect (as someone else pointed out) is not at
> > all css (I'm not even sure what you mean by css hang?) but UDF.
> 
> I mean a complete system hang when playing a CSS disc - doesn't even ping.
> Doesn't recover.

Hmm

> > Given the fs changes. Since sysrq still works, it would help a
> > lot if you could capture sysrq-p repeatedly and send it in.
> 
> I think at this point the only thing that works is sysrq-b - at least the
> sysrq-u's and sysrq-s's that I've given don't seem to have cleanly
> unmounted the file system.

Could you at least check? You may need some sort of serial console too..

> > Do you have any non-css discs to beat on UDF?
> 
> Yep one disc (Scanners) - it is fine - hence my reason for beleiving it is
> a CSSism (although I guess CSS makes other demands on the UDF code).

Not so. Once a css "session" has been established, data is read just
like off any other CD. But try with this patch applied, it could be
a NULL pointer deref at the wrong time.

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs


--- drivers/ide/ide-cd.c~   Sat Dec 23 23:59:52 2000
+++ drivers/ide/ide-cd.cSun Dec 24 00:03:38 2000
@@ -333,7 +333,7 @@
 {
int log = 0;
 
-   if (sense == NULL || pc->quiet)
+   if (sense == NULL || pc == NULL || pc->quiet)
return 0;
 
switch (sense->sense_key) {

Re: css hang; somewhere between test12 and test13pre4ac2

On Mon, 25 Dec 2000, Jens Axboe wrote:

> The most likely suspect (as someone else pointed out) is not at
> all css (I'm not even sure what you mean by css hang?) but UDF.

I mean a complete system hang when playing a CSS disc - doesn't even ping.
Doesn't recover.

> Given the fs changes. Since sysrq still works, it would help a
> lot if you could capture sysrq-p repeatedly and send it in.

I think at this point the only thing that works is sysrq-b - at least the
sysrq-u's and sysrq-s's that I've given don't seem to have cleanly
unmounted the file system.

> Do you have any non-css discs to beat on UDF?

Yep one disc (Scanners) - it is fine - hence my reason for beleiving it is
a CSSism (although I guess CSS makes other demands on the UDF code).

Dave

-- 
  Have a happy GNU millennium! --   
/ Dr. David Alan Gilbert  | Running GNU/Linux on   |  Happy  \ 
\   gro.gilbert @ treblig.org |  Alpha, x86, ARM and SPARC |  In Hex /
 \ ___|___ http://www.treblig.org  |/

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

2.2.18 compile warnings

2000-12-25 Thread Thomas Molina


I get a large number of warnings like the following when compiling
2.2.18:

{standard input}:338: Warning: using `%eax' instead of `%ax' due to `l'
suffix

I'm using the compiler from RedHat 6.2:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)


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

new linux_logo16

2000-12-25 Thread Geert Uytterhoeven



Since the 16-color logo was broken a while ago, we need a new one for 2.4.0.
The main limitation is that we no longer can choose the palette, but have to
use the standard VGA 16-color palette.

I quantized the 256-color logo to the VGA palette using ppmquant and used my
rudimentary artistical skills with the GIMP to remove the background pattern.
The results are attached (yes, they are small):
  - new_logo16.png: plain quantized 256-color logo
  - new_logo16_fs.png: quantized 256-color logo using Floyd-Steinberg dithering
  - new_logo16_2.png: new_logo16.png with the background pattern removed

So either some artistic soul creates a new non-offensive politically-correct[*]
logo using the standard VGA 16-color palette, or I'll submit new_logo16_2.png
for inclusion in 2.4.0.

Any comments?

Gr{oetje,eeting}s,

Geert

[*] I don't want another to-drink-or-not-to-drink discussion.
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

 new_logo16.png
 new_logo16_fs.png
 new_logo16_2.png

Re: Linux 2.4.0test13pre4ac2

2000-12-25 Thread Andrew Morton

Alan Cox wrote:
> 
> 2.4.0test13pre4-ac2
>
> o   Make smp cpu halt synchronous   (Andi Kleen)

errr, Andi. 

We're asking all the other CPUs to call stop_this_cpu(), and then waiting
for them to complete the call.

But stop_this_cpu() never returns, so the machine gets stuck.

What were you trying to do here, BTW?

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

Re: css hang; somewhere between test12 and test13pre4ac2

On Sun, Dec 24 2000, Dave Gilbert wrote:
> Hi,
>   Somewhere between test12 and test13pre4ac2 (sheesh the version
> numbers.) CSS on ATAPI DVD ROM drives has stopped working.
> 
> Playing a CSS disc (using xine) causes a complete system hang (machine
> doesn't ping - sysrq-b still works) on test13pre4ac2.  On test12 it is
> still OK.
> 
> This is on an Alpha LX164.

The most likely suspect (as someone else pointed out) is not at
all css (I'm not even sure what you mean by css hang?) but UDF.
Given the fs changes. Since sysrq still works, it would help a
lot if you could capture sysrq-p repeatedly and send it in.

Do you have any non-css discs to beat on UDF?

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

Re: Driver for emulating a tape device on top of a cd writer...


On Tue, Dec 19 2000, Stelian Pop wrote:
> > > Basically, I would like to be able to use a cdwriter as a tape
> > > device, with software like dump(8) or tar(1). With /dev/tcdw
> > > as name (for example), I'd like to be able to do:
> > > [...]
> 
> > What you describe is actually one of the goals of the packet writing
> > driver. To do this reliably you need packet writing, I won't even
> > start to think about the headaches wihtout it...
> 
> Yes, I saw your patch for packet writing but:
> - the CD written with packet writing software may not be readable
>   on standard CD-ROM drives (and I want that, because almost 
>   everybody has one).

On CD drives sold during the last two years or so, and of course
all DVD drives they are readable. But of course of you want 100%
coverage, it isn't good enough.

> - using packet writing you basically write _files_ on top of an
>   UDF filesystem. Tar and dump (or afio, cpio etc) does not
>   support that kind of access, they expect to be given a character
>   device they can stream data to. (Of course, it is possible to
>   add some additionnal level of indirection on top of the packet
>   device and provide character based access to the UDF files, but
>   IMHO _this_ would be overkill).

Why would you even want to use UDF for this? You want raw access
to the device. Packet writing or not, this is totally unrelated.

> - data backups are expected to be fast. Writing data in DAO/TAO
>   mode is much quicker than in packet mode.

No no no, not much quicker. Write large packets and it's just
as fast as dao/tao. 64Kb packets are a bit slower because of
run-in, run-out block over head, but using larger packets this
isn't the noticable. And packet writing has so many other
advantages...

> - reliability is a question of implementation. cdrecord can
>   be very reliable. If a user space application can provide this
>   level of reliability, it should be even simpler to achieve it
>   in kernel space (and I plan to use the BurnProof/etc extensions
>   which will be present on all future cdwriters).

Even simpler to achieve reliability in the kernel? I gather you
mean feeding-data reliability, and not stability.

> > > I'll start to work on this, probably by looking at the cdrecord 
> > > low level code and porting it into kernel space.
> > 
> > Oh god no! You can do all this from user space.
> 
> Please pay attention to the fact that I was refering to the 'low level
> code'. I don't intend to write a driver who can replace cdrecord. 
> _This_ would be madness.

Very much so

> What I indend to do is just a 'small' driver, which supports only the
> mmc drives. I expect the driver to be only some hundreds lines long.

A few hundred lines? *This* I look forward to seeing :)

> Doing that from user space would mean propagating the data from
> the user space application (dump or tar) to a character mode
> driver, and back to a user space application (something like a hacked 
> cdrecord), which will return in kernel space using sg interface...
> It could be easier to write (even if I don't exactly feel confident
> about hacking the cdrecord source :) ), but the reliability and
> the performance would be far far away...

Pipes and 100% user space based, then pass to sg? I don't see the
problem.

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

test13-pre4... udf problem with dvd access vs test12

2000-12-25 Thread Frank Jacobberger


Odd happening here. Been running good as gold through test12 with
accessing my dvd to using oms. Now updating to test13-pre4
I get a complete lock up of my whole system when executing oms.

I can access the drive via mounting it... with no trouble what ever.

Here is a snip from my message file No clue what to test for here...

Perhaps udf.c is the problem?

Any ideas?

Merry Christmas

Frank





Dec 25 02:02:13 f1j kernel: hdf: packet command error: status=0x51 {
DriveReady SeekComplete Error }
Dec 25 02:02:13 f1j kernel: hdf: packet command error: error=0x00
Dec 25 02:02:13 f1j kernel: ATAPI device hdf:
Dec 25 02:02:13 f1j kernel:   Error: No sense data -- (Sense key=0x00)
Dec 25 02:02:13 f1j kernel:   No additional sense information --
(asc=0x00, ascq=0x00)
Dec 25 02:02:13 f1j kernel:   The failed "Report Key" packet command
was:
Dec 25 02:02:13 f1j kernel:   "a4 00 00 00 00 00 00 00 00 0c c4 00 "
Dec 25 02:02:14 f1j kernel: hdf: command error: status=0x51 { DriveReady
SeekComplete Error }
Dec 25 02:02:14 f1j kernel: hdf: command error: error=0x50
Dec 25 02:02:14 f1j kernel: end_request: I/O error, dev 21:40 (hdf),
sector 1148
Dec 25 02:02:14 f1j kernel: ATAPI device hdf:
Dec 25 02:02:14 f1j kernel:   Error: Illegal request -- (Sense key=0x05)

Dec 25 02:02:14 f1j kernel:   Read of scrambled sector without
authentication -- (asc=0x6f, ascq=0x03)
Dec 25 02:02:14 f1j kernel: hdf: command error: status=0x51 { DriveReady
SeekComplete Error }
Dec 25 02:02:14 f1j kernel: hdf: command error: error=0x50
Dec 25 02:02:14 f1j kernel: ATAPI device hdf:
Dec 25 02:02:14 f1j kernel:   Error: Illegal request -- (Sense key=0x05)

Dec 25 02:02:14 f1j kernel:   Read of scrambled sector without
authentication -- (asc=0x6f, ascq=0x03)
Dec 25 02:02:14 f1j kernel: hdf: command error: status=0x51 { DriveReady
SeekComplete Error }
Dec 25 02:02:14 f1j kernel: hdf: command error: error=0x50
Dec 25 02:02:14 f1j kernel: end_request: I/O error, dev 21:40 (hdf),
sector 1152
Dec 25 02:02:14 f1j kernel: ATAPI device hdf:
Dec 25 02:02:14 f1j kernel:   Error: Illegal request -- (Sense key=0x05)

Dec 25 02:02:14 f1j kernel:   Read of scrambled sector without
authentication -- (asc=0x6f, ascq=0x03)
Dec 25 02:02:14 f1j kernel: hdf: command error: status=0x51 { DriveReady
SeekComplete Error }
Dec 25 02:02:14 f1j kernel: hdf: command error: error=0x50
Dec 25 02:02:14 f1j kernel: end_request: I/O error, dev 21:40 (hdf),
sector 1153
Dec 25 02:02:14 f1j kernel: ATAPI device hdf:
Dec 25 02:02:14 f1j kernel:   Error: Illegal request -- (Sense key=0x05)

Dec 25 02:02:14 f1j kernel:   Read of scrambled sector without
authentication -- (asc=0x6f, ascq=0x03)
Dec 25 02:02:14 f1j kernel: hdf: command error: status=0x51 { DriveReady
SeekComplete Error }
Dec 25 02:02:14 f1j kernel: hdf: command error: error=0x50
Dec 25 02:02:14 f1j kernel: end_request: I/O error, dev 21:40 (hdf),
sector 1154
Dec 25 02:02:14 f1j kernel: ATAPI device hdf:
Dec 25 02:02:14 f1j kernel:   Error: Illegal request -- (Sense key=0x05)

Dec 25 02:02:14 f1j kernel:   Read of scrambled sector without
authentication -- (asc=0x6f, ascq=0x03)
Dec 25 02:02:14 f1j kernel: hdf: command error: status=0x51 { DriveReady
SeekComplete Error }
Dec 25 02:02:14 f1j kernel: hdf: command error: error=0x50
Dec 25 02:02:14 f1j kernel: end_request: I/O error, dev 21:40 (hdf),
sector 1155
Dec 25 02:02:14 f1j kernel: ATAPI device hdf:
Dec 25 02:02:14 f1j kernel:   Error: Illegal request -- (Sense key=0x05)

Dec 25 02:02:14 f1j kernel:   Read of scrambled sector without
authentication -- (asc=0x6f, ascq=0x03)


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

Re: innd mmap bug in 2.4.0-test12

On Mon, 25 Dec 2000, Linus Torvalds wrote:
> 
> Assuming we don't lose any PG_dirty bits, we might of course just lose it
> from the page tables themselves before it ever even gets to "struct page".
> I'm just surprised that it seems to be so repeatable for you - it sounds
> like we _never_ actually write out the dirty pages to disk. It's not that
> we can lose the dirty bit occasionally, we seem to lose it every time in
> your setup.

Nope. I got it.

The thing is even more embarrassing than just losing a dirty bit.

We don't lose any dirty bits (well, we could before, but after adding the
PageDirty() test to reclaim_page() we're ok now).

In fact, we know _exactly_ which pages are dirty, and which pages are not.

We just don't write them out. Because right now the only thing that writes
out dirty pages is memory pressure. "sync()", "fsync()" and "fdatasync()"
will happily ignore dirty pages completely. The thing that made me
overlook that simple thing in testing was that I was testing the new VM
stuff under heavy VM load - to shake out any bugs.

Under heavy VM load, there are no problems, because the memory pressure
will make sure everything gets written out. Under heavy VM load the thing
works just beautifully.

Under _low_, or no, memory pressure, however, the dang thing just stays in
memory. We'll happily reboot with the new contents still cached, in fact.

I bet that if you start something that eats up all your memory, and causes
some nice swapping just before you shut down the machine, your innd active
file will be right as rain after a reboot.

I'm a stupid git. I even remember thinking about the syncing issues at
some point, and then obviously just forgetting about it _completely_.

The simple fix is along the lines of adding code to fsync() that walks the
inode page list and writes out dirty pages.

The clever and clean fix is to split the inode page list into two lists,
one for dirty and one for clean pages, and only walk the dirty list.

Ho ho ho. I _so_ enjoy making a fool out of myself.

Linus

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

Re: innd mmap bug in 2.4.0-test12

On Mon, 25 Dec 2000, Marco d'Itri wrote:

> On Dec 24, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> 
>  >/* The page is dirty, or locked, move to inactive_dirty list. */
>  >if (page->buffers || TryLockPage(page)) {
>  >...
>  >
>  >and change the test to
>  >
>  >if (page->buffers || PageDirty(page) || TryLockPage(page)) {
> Done, no change.
> Got some articles, restarted the server, all is good.
> Got other articles, rebooted and the files now differ.

Willing to test some more?

Add a printk() to __remove_inode_page() that complains whenever it removes
a dirty page. 

Oh, in order to not see this with swap pages (which _can_ be removed when
they are dirty, if all users of them are gone), add a PageClearDirty() to
"remove_from_swap_cache()" so that we don't get false positives..

Do you get any messages? I don't think you will, but it should be tested.
You might mark it a BUG(), so tht we'll get a stack-trace if it happens.

Assuming we don't lose any PG_dirty bits, we might of course just lose it
from the page tables themselves before it ever even gets to "struct page".
I'm just surprised that it seems to be so repeatable for you - it sounds
like we _never_ actually write out the dirty pages to disk. It's not that
we can lose the dirty bit occasionally, we seem to lose it every time in
your setup.

I wonder if it's something specific innd does. Like "msync()" just being
broken or similar. But the code looks sane.

Hmm.. Can you send me an "strace" of innd when this happens?

> And I have another problem: I'm experiencing random hangs using X[1] with
> 2.4.0-test12.

That's probably the infinite loop in the tty task queue handling, should
be fixed in test13-pre3 or so.

Linus

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

Re: innd mmap bug in 2.4.0-test12




On Mon, 25 Dec 2000, Marco d'Itri wrote:

 On Dec 24, Linus Torvalds [EMAIL PROTECTED] wrote:
 
  /* The page is dirty, or locked, move to inactive_dirty list. */
  if (page-buffers || TryLockPage(page)) {
  ...
  
  and change the test to
  
  if (page-buffers || PageDirty(page) || TryLockPage(page)) {
 Done, no change.
 Got some articles, restarted the server, all is good.
 Got other articles, rebooted and the files now differ.

Willing to test some more?

Add a printk() to __remove_inode_page() that complains whenever it removes
a dirty page. 

Oh, in order to not see this with swap pages (which _can_ be removed when
they are dirty, if all users of them are gone), add a PageClearDirty() to
"remove_from_swap_cache()" so that we don't get false positives..

Do you get any messages? I don't think you will, but it should be tested.
You might mark it a BUG(), so tht we'll get a stack-trace if it happens.

Assuming we don't lose any PG_dirty bits, we might of course just lose it
from the page tables themselves before it ever even gets to "struct page".
I'm just surprised that it seems to be so repeatable for you - it sounds
like we _never_ actually write out the dirty pages to disk. It's not that
we can lose the dirty bit occasionally, we seem to lose it every time in
your setup.

I wonder if it's something specific innd does. Like "msync()" just being
broken or similar. But the code looks sane.

Hmm.. Can you send me an "strace" of innd when this happens?

 And I have another problem: I'm experiencing random hangs using X[1] with
 2.4.0-test12.

That's probably the infinite loop in the tty task queue handling, should
be fixed in test13-pre3 or so.

Linus


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

Re: innd mmap bug in 2.4.0-test12




On Mon, 25 Dec 2000, Linus Torvalds wrote:
 
 Assuming we don't lose any PG_dirty bits, we might of course just lose it
 from the page tables themselves before it ever even gets to "struct page".
 I'm just surprised that it seems to be so repeatable for you - it sounds
 like we _never_ actually write out the dirty pages to disk. It's not that
 we can lose the dirty bit occasionally, we seem to lose it every time in
 your setup.

Nope. I got it.

The thing is even more embarrassing than just losing a dirty bit.

We don't lose any dirty bits (well, we could before, but after adding the
PageDirty() test to reclaim_page() we're ok now).

In fact, we know _exactly_ which pages are dirty, and which pages are not.

We just don't write them out. Because right now the only thing that writes
out dirty pages is memory pressure. "sync()", "fsync()" and "fdatasync()"
will happily ignore dirty pages completely. The thing that made me
overlook that simple thing in testing was that I was testing the new VM
stuff under heavy VM load - to shake out any bugs.

Under heavy VM load, there are no problems, because the memory pressure
will make sure everything gets written out. Under heavy VM load the thing
works just beautifully.

Under _low_, or no, memory pressure, however, the dang thing just stays in
memory. We'll happily reboot with the new contents still cached, in fact.

I bet that if you start something that eats up all your memory, and causes
some nice swapping just before you shut down the machine, your innd active
file will be right as rain after a reboot.

I'm a stupid git. I even remember thinking about the syncing issues at
some point, and then obviously just forgetting about it _completely_.

The simple fix is along the lines of adding code to fsync() that walks the
inode page list and writes out dirty pages.

The clever and clean fix is to split the inode page list into two lists,
one for dirty and one for clean pages, and only walk the dirty list.

Ho ho ho. I _so_ enjoy making a fool out of myself.

Linus

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

test13-pre4... udf problem with dvd access vs test12

2000-12-25 Thread Frank Jacobberger


Odd happening here. Been running good as gold through test12 with
accessing my dvd to using oms. Now updating to test13-pre4
I get a complete lock up of my whole system when executing oms.

I can access the drive via mounting it... with no trouble what ever.

Here is a snip from my message file No clue what to test for here...

Perhaps udf.c is the problem?

Any ideas?

Merry Christmas

Frank





Dec 25 02:02:13 f1j kernel: hdf: packet command error: status=0x51 {
DriveReady SeekComplete Error }
Dec 25 02:02:13 f1j kernel: hdf: packet command error: error=0x00
Dec 25 02:02:13 f1j kernel: ATAPI device hdf:
Dec 25 02:02:13 f1j kernel:   Error: No sense data -- (Sense key=0x00)
Dec 25 02:02:13 f1j kernel:   No additional sense information --
(asc=0x00, ascq=0x00)
Dec 25 02:02:13 f1j kernel:   The failed "Report Key" packet command
was:
Dec 25 02:02:13 f1j kernel:   "a4 00 00 00 00 00 00 00 00 0c c4 00 "
Dec 25 02:02:14 f1j kernel: hdf: command error: status=0x51 { DriveReady
SeekComplete Error }
Dec 25 02:02:14 f1j kernel: hdf: command error: error=0x50
Dec 25 02:02:14 f1j kernel: end_request: I/O error, dev 21:40 (hdf),
sector 1148
Dec 25 02:02:14 f1j kernel: ATAPI device hdf:
Dec 25 02:02:14 f1j kernel:   Error: Illegal request -- (Sense key=0x05)

Dec 25 02:02:14 f1j kernel:   Read of scrambled sector without
authentication -- (asc=0x6f, ascq=0x03)
Dec 25 02:02:14 f1j kernel: hdf: command error: status=0x51 { DriveReady
SeekComplete Error }
Dec 25 02:02:14 f1j kernel: hdf: command error: error=0x50
Dec 25 02:02:14 f1j kernel: ATAPI device hdf:
Dec 25 02:02:14 f1j kernel:   Error: Illegal request -- (Sense key=0x05)

Dec 25 02:02:14 f1j kernel:   Read of scrambled sector without
authentication -- (asc=0x6f, ascq=0x03)
Dec 25 02:02:14 f1j kernel: hdf: command error: status=0x51 { DriveReady
SeekComplete Error }
Dec 25 02:02:14 f1j kernel: hdf: command error: error=0x50
Dec 25 02:02:14 f1j kernel: end_request: I/O error, dev 21:40 (hdf),
sector 1152
Dec 25 02:02:14 f1j kernel: ATAPI device hdf:
Dec 25 02:02:14 f1j kernel:   Error: Illegal request -- (Sense key=0x05)

Dec 25 02:02:14 f1j kernel:   Read of scrambled sector without
authentication -- (asc=0x6f, ascq=0x03)
Dec 25 02:02:14 f1j kernel: hdf: command error: status=0x51 { DriveReady
SeekComplete Error }
Dec 25 02:02:14 f1j kernel: hdf: command error: error=0x50
Dec 25 02:02:14 f1j kernel: end_request: I/O error, dev 21:40 (hdf),
sector 1153
Dec 25 02:02:14 f1j kernel: ATAPI device hdf:
Dec 25 02:02:14 f1j kernel:   Error: Illegal request -- (Sense key=0x05)

Dec 25 02:02:14 f1j kernel:   Read of scrambled sector without
authentication -- (asc=0x6f, ascq=0x03)
Dec 25 02:02:14 f1j kernel: hdf: command error: status=0x51 { DriveReady
SeekComplete Error }
Dec 25 02:02:14 f1j kernel: hdf: command error: error=0x50
Dec 25 02:02:14 f1j kernel: end_request: I/O error, dev 21:40 (hdf),
sector 1154
Dec 25 02:02:14 f1j kernel: ATAPI device hdf:
Dec 25 02:02:14 f1j kernel:   Error: Illegal request -- (Sense key=0x05)

Dec 25 02:02:14 f1j kernel:   Read of scrambled sector without
authentication -- (asc=0x6f, ascq=0x03)
Dec 25 02:02:14 f1j kernel: hdf: command error: status=0x51 { DriveReady
SeekComplete Error }
Dec 25 02:02:14 f1j kernel: hdf: command error: error=0x50
Dec 25 02:02:14 f1j kernel: end_request: I/O error, dev 21:40 (hdf),
sector 1155
Dec 25 02:02:14 f1j kernel: ATAPI device hdf:
Dec 25 02:02:14 f1j kernel:   Error: Illegal request -- (Sense key=0x05)

Dec 25 02:02:14 f1j kernel:   Read of scrambled sector without
authentication -- (asc=0x6f, ascq=0x03)


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

Re: css hang; somewhere between test12 and test13pre4ac2


On Sun, Dec 24 2000, Dave Gilbert wrote:
 Hi,
   Somewhere between test12 and test13pre4ac2 (sheesh the version
 numbers.) CSS on ATAPI DVD ROM drives has stopped working.
 
 Playing a CSS disc (using xine) causes a complete system hang (machine
 doesn't ping - sysrq-b still works) on test13pre4ac2.  On test12 it is
 still OK.
 
 This is on an Alpha LX164.

The most likely suspect (as someone else pointed out) is not at
all css (I'm not even sure what you mean by css hang?) but UDF.
Given the fs changes. Since sysrq still works, it would help a
lot if you could capture sysrq-p repeatedly and send it in.

Do you have any non-css discs to beat on UDF?

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

Re: Driver for emulating a tape device on top of a cd writer...


On Tue, Dec 19 2000, Stelian Pop wrote:
   Basically, I would like to be able to use a cdwriter as a tape
   device, with software like dump(8) or tar(1). With /dev/tcdw
   as name (for example), I'd like to be able to do:
   [...]
 
  What you describe is actually one of the goals of the packet writing
  driver. To do this reliably you need packet writing, I won't even
  start to think about the headaches wihtout it...
 
 Yes, I saw your patch for packet writing but:
 - the CD written with packet writing software may not be readable
   on standard CD-ROM drives (and I want that, because almost 
   everybody has one).

On CD drives sold during the last two years or so, and of course
all DVD drives they are readable. But of course of you want 100%
coverage, it isn't good enough.

 - using packet writing you basically write _files_ on top of an
   UDF filesystem. Tar and dump (or afio, cpio etc) does not
   support that kind of access, they expect to be given a character
   device they can stream data to. (Of course, it is possible to
   add some additionnal level of indirection on top of the packet
   device and provide character based access to the UDF files, but
   IMHO _this_ would be overkill).

Why would you even want to use UDF for this? You want raw access
to the device. Packet writing or not, this is totally unrelated.

 - data backups are expected to be fast. Writing data in DAO/TAO
   mode is much quicker than in packet mode.

No no no, not much quicker. Write large packets and it's just
as fast as dao/tao. 64Kb packets are a bit slower because of
run-in, run-out block over head, but using larger packets this
isn't the noticable. And packet writing has so many other
advantages...

 - reliability is a question of implementation. cdrecord can
   be very reliable. If a user space application can provide this
   level of reliability, it should be even simpler to achieve it
   in kernel space (and I plan to use the BurnProof/etc extensions
   which will be present on all future cdwriters).

Even simpler to achieve reliability in the kernel? I gather you
mean feeding-data reliability, and not stability.

   I'll start to work on this, probably by looking at the cdrecord 
   low level code and porting it into kernel space.
  
  Oh god no! You can do all this from user space.
 
 Please pay attention to the fact that I was refering to the 'low level
 code'. I don't intend to write a driver who can replace cdrecord. 
 _This_ would be madness.

Very much so

 What I indend to do is just a 'small' driver, which supports only the
 mmc drives. I expect the driver to be only some hundreds lines long.

A few hundred lines? *This* I look forward to seeing :)

 Doing that from user space would mean propagating the data from
 the user space application (dump or tar) to a character mode
 driver, and back to a user space application (something like a hacked 
 cdrecord), which will return in kernel space using sg interface...
 It could be easier to write (even if I don't exactly feel confident
 about hacking the cdrecord source :) ), but the reliability and
 the performance would be far far away...

Pipes and 100% user space based, then pass to sg? I don't see the
problem.

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

2.2.18 compile warnings

2000-12-25 Thread Thomas Molina


I get a large number of warnings like the following when compiling
2.2.18:

{standard input}:338: Warning: using `%eax' instead of `%ax' due to `l'
suffix

I'm using the compiler from RedHat 6.2:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)


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

Re: css hang; somewhere between test12 and test13pre4ac2


On Mon, 25 Dec 2000, Jens Axboe wrote:

 The most likely suspect (as someone else pointed out) is not at
 all css (I'm not even sure what you mean by css hang?) but UDF.

I mean a complete system hang when playing a CSS disc - doesn't even ping.
Doesn't recover.

 Given the fs changes. Since sysrq still works, it would help a
 lot if you could capture sysrq-p repeatedly and send it in.

I think at this point the only thing that works is sysrq-b - at least the
sysrq-u's and sysrq-s's that I've given don't seem to have cleanly
unmounted the file system.
 
 Do you have any non-css discs to beat on UDF?


Yep one disc (Scanners) - it is fine - hence my reason for beleiving it is
a CSSism (although I guess CSS makes other demands on the UDF code).

Dave

-- 
  Have a happy GNU millennium! --   
/ Dr. David Alan Gilbert  | Running GNU/Linux on   |  Happy  \ 
\   gro.gilbert @ treblig.org |  Alpha, x86, ARM and SPARC |  In Hex /
 \ ___|___ http://www.treblig.org  |/

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

Re: css hang; somewhere between test12 and test13pre4ac2


On Mon, Dec 25 2000, Dave Gilbert wrote:
  The most likely suspect (as someone else pointed out) is not at
  all css (I'm not even sure what you mean by css hang?) but UDF.
 
 I mean a complete system hang when playing a CSS disc - doesn't even ping.
 Doesn't recover.

Hmm

  Given the fs changes. Since sysrq still works, it would help a
  lot if you could capture sysrq-p repeatedly and send it in.
 
 I think at this point the only thing that works is sysrq-b - at least the
 sysrq-u's and sysrq-s's that I've given don't seem to have cleanly
 unmounted the file system.

Could you at least check? You may need some sort of serial console too..

  Do you have any non-css discs to beat on UDF?
 
 Yep one disc (Scanners) - it is fine - hence my reason for beleiving it is
 a CSSism (although I guess CSS makes other demands on the UDF code).

Not so. Once a css "session" has been established, data is read just
like off any other CD. But try with this patch applied, it could be
a NULL pointer deref at the wrong time.

-- 
* Jens Axboe [EMAIL PROTECTED]
* SuSE Labs


--- drivers/ide/ide-cd.c~   Sat Dec 23 23:59:52 2000
+++ drivers/ide/ide-cd.cSun Dec 24 00:03:38 2000
@@ -333,7 +333,7 @@
 {
int log = 0;
 
-   if (sense == NULL || pc-quiet)
+   if (sense == NULL || pc == NULL || pc-quiet)
return 0;
 
switch (sense-sense_key) {

[PATCH] winbond-840 updates, tester needed!


I found a few minor problems in the current winbond driver:

* the current driver hangs/crashes during module unload.
* it doesn't use the new pci dma mapping interface
* it assumed strong memory ordering without explicit wmb()'s.
* it contains the tx_full race that Andrew Morton found.

The patch fixes these bugs. I've tested it on i386 SMP.

I need a tester with a winbond card on a computer with a big endian cpu,
any volunteers?

There are at least 2 outstanding problems with big endian cpus:

* a warning from Donald Becker that one eeprom read is broken for
big-endian machines.

* the driver doesn't use the "Descriptor Big Endian" (bit 20 of register
0) mode, instead it uses cpu_to_le32.

--
  Manfred

--- 2.4/drivers/net/winbond-840.c   Sun Dec 17 18:03:56 2000
+++ build-2.4/drivers/net/winbond-840.c Mon Dec 25 12:49:36 2000
@@ -21,11 +21,21 @@
Do not change the version information unless an improvement has been made.
Merely removing my name, as Compex has done in the past, does not count
as an improvement.
+
+   Changelog:
+   * ported to 2.4
+   ???
+   * spin lock update, memory barriers, new style dma mappings
+   Manfred Spraul
+
+   TODO:
+   * according to the documentation, the chip supports big endian
+   internally. Replace the cpu_to_le32 with that bit.
 */
 
 /* These identify the driver base version and may not be removed. */
 static const char version1[] =
-"winbond-840.c:v1.01 5/15/2000  Donald Becker [EMAIL PROTECTED]\n";
+"winbond-840.c:v1.01 (2.4 port) 5/15/2000  Donald Becker [EMAIL PROTECTED]\n";
 static const char version2[] =
 "  http://www.scyld.com/network/drivers.html\n";
 
@@ -114,12 +124,6 @@
 #include asm/bitops.h
 #include asm/io.h
 
-/* Condensed operations for readability.
-   The compatibility defines are in kern_compat.h */
-
-#define virt_to_le32desc(addr)  cpu_to_le32(virt_to_bus(addr))
-#define le32desc_to_virt(addr)  bus_to_virt(le32_to_cpu(addr))
-
 MODULE_AUTHOR("Donald Becker [EMAIL PROTECTED]");
 MODULE_DESCRIPTION("Winbond W89c840 Ethernet driver");
 MODULE_PARM(max_interrupt_work, "i");
@@ -298,9 +302,12 @@
 
 #define PRIV_ALIGN 15  /* Required alignment mask */
 struct netdev_private {
-   /* Descriptor rings first for alignment. */
-   struct w840_rx_desc rx_ring[RX_RING_SIZE];
-   struct w840_tx_desc tx_ring[TX_RING_SIZE];
+   struct w840_rx_desc *rx_ring;
+   dma_addr_t  rx_addr[RX_RING_SIZE];
+   struct w840_tx_desc *tx_ring;
+   dma_addr_t  tx_addr[RX_RING_SIZE];
+   dma_addr_t ring_dma_addr;
+   struct pci_dev *pdev;
/* The addresses of receive-in-place skbuffs. */
struct sk_buff* rx_skbuff[RX_RING_SIZE];
/* The saved address of a sent-in-place packet/buffer, for later free(). */
@@ -335,7 +342,7 @@
 static void check_duplex(struct net_device *dev);
 static void netdev_timer(unsigned long data);
 static void tx_timeout(struct net_device *dev);
-static void init_ring(struct net_device *dev);
+static int init_ring(struct net_device *dev);
 static int  start_tx(struct sk_buff *skb, struct net_device *dev);
 static void intr_handler(int irq, void *dev_instance, struct pt_regs *regs);
 static void netdev_error(struct net_device *dev, int intr_status);
@@ -364,6 +371,11 @@
return -EIO;
pci_set_master(pdev);
 
+   if(!pci_dma_supported(pdev,0x)) {
+   printk(KERN_WARNING "Winbond-840: Device %s disabled due to DMA 
+limitations.\n",
+   pdev-name);
+   return -EIO;
+   }
dev = init_etherdev(NULL, sizeof(*np));
if (!dev)
return -ENOMEM;
@@ -403,6 +415,7 @@
np = dev-priv;
np-chip_id = chip_idx;
np-drv_flags = pci_id_tbl[chip_idx].drv_flags;
+   np-pdev = pdev;
spin_lock_init(np-lock);

pdev-driver_data = dev;
@@ -632,10 +645,12 @@
printk(KERN_DEBUG "%s: w89c840_open() irq %d.\n",
   dev-name, dev-irq);
 
-   init_ring(dev);
+   if((i=init_ring(dev)))
+   return i;
 
-   writel(virt_to_bus(np-rx_ring), ioaddr + RxRingPtr);
-   writel(virt_to_bus(np-tx_ring), ioaddr + TxRingPtr);
+   writel(np-ring_dma_addr, ioaddr + RxRingPtr);
+   writel(np-ring_dma_addr+sizeof(struct w840_rx_desc)*RX_RING_SIZE,
+   ioaddr + TxRingPtr);
 
for (i = 0; i  6; i++)
writeb(dev-dev_addr[i], ioaddr + StationAddr + i);
@@ -733,11 +748,13 @@
   "config %8.8x.\n",
   dev-name, (int)readl(ioaddr + IntrStatus),
   (int)readl(ioaddr + NetworkConfig));
+   spin_lock_irq(np-lock);
check_duplex(dev);
if (np-csr6 != old_csr6) {
writel(np-csr6  ~0x0002, ioaddr + NetworkConfig);
writel(np-csr6 | 0x2002, ioaddr + NetworkConfig);

Re: TCP keepalive seems to send to only one port

2000-12-25 Thread Igmar Palsenberg



 Yeah. But I'm stuck with a NAT (which isn't mine, btw) which uses 2.1.xxx-2.2.x
 (according to nmap). Which had a default of 15 *minutes* (as I read in a HOWTO
 somewhere). I'm trying to convince the sysadmin to raise it to two hours, but I
 bet it'll be hard.

ipchains -S timeoutval 0 0 is the only way to do this.


Igmar

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

Re: About Celeron processor memory barrier problem

2000-12-25 Thread Kai Henningsen


[EMAIL PROTECTED] (Tim Wright)  wrote on 24.12.00 in 
[EMAIL PROTECTED]:

 On Sun, Dec 24, 2000 at 11:36:00AM +0200, Kai Henningsen wrote:

 There was a similar thread to this recently. The issue is that if you
 choose the wrong processor type, you may not even be able to complain.

Hmm ... I think I can see ways around that (essentially similar to the 16  
bit bootstrap code), but it may indeed be more trouble than it's worth.

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

Re: TCP keepalive seems to send to only one port

2000-12-25 Thread Cesar Eduardo Barros


On Mon, Dec 25, 2000 at 04:27:07PM +0100, Igmar Palsenberg wrote:
 
  Yeah. But I'm stuck with a NAT (which isn't mine, btw) which uses 2.1.xxx-2.2.x
  (according to nmap). Which had a default of 15 *minutes* (as I read in a HOWTO
  somewhere). I'm trying to convince the sysadmin to raise it to two hours, but I
  bet it'll be hard.
 
 ipchains -S timeoutval 0 0 is the only way to do this.
 

That's the easy part. Convincing the sysadmin (which probably is not very
clueful) is the hard one. But this is getting too OT, EOT.

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

Re: Linux 2.4.0test13pre4ac2

2000-12-25 Thread Andi Kleen


On Mon, Dec 25, 2000 at 10:37:54PM +1100, Andrew Morton wrote:
 Alan Cox wrote:
  
  2.4.0test13pre4-ac2
 
  o   Make smp cpu halt synchronous   (Andi Kleen)
 
 errr, Andi. 
 
 We're asking all the other CPUs to call stop_this_cpu(), and then waiting
 for them to complete the call.
 
 But stop_this_cpu() never returns, so the machine gets stuck.

Right, it's wrong. Thanks for spotting that.

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

Re: Masquerade hangups

2000-12-25 Thread Harald Welte


On Sun, Dec 24, 2000 at 09:02:12AM -0600, Mike Elmore wrote:
 Hello,
 
 
 I seem to get pretty good performance from 
 internet-masq box and from masq box-internal
 lan, but when a internal box tries to get to the
 net through the masquerade, connection seem to time
 out.  I'll get a pretty good initial burst, then
 connections stall.

please join the netfilter/iptables mailinglist (instructions on
http://netfilter.kernelnotes.org) and file us a detailed report.

It's a good idea to save linux-kernel from all the nifty details :)

 I'm using test13-pre4.  I saw some iptables stuff on
 the list a week or so ago, was this fixed in pre4 or
 is this my problem?

we (the netfilter core team) are currently not aware
of any bugs at the moment. The behaviour you've described
wasn't reported by anybody else.

 -mwe
 [EMAIL PROTECTED]

-- 
Live long and prosper
- Harald Welte / [EMAIL PROTECTED]http://www.gnumonks.org

GCS/E/IT d- s-: a-- C+++ UL$ 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+(*)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Netgear FA311


Well now I've just set up the network and everything works a treat,
currently getting 850kb/s file transfers. Cool. Except for one thing.

In the logs I'm seeing this:

Dec 25 15:25:18 tahallah last message repeated 2 times
Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0783.
Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0780.
Dec 25 15:25:19 tahallah last message repeated 2 times
Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0580.
Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0783.
Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0780.
Dec 25 15:25:21 tahallah last message repeated 3 times
Dec 25 15:25:21 tahallah kernel: eth0: Something Wicked happened! 0783.
Dec 25 15:25:22 tahallah kernel: eth0: Something Wicked happened! 0780.

That's just a small snippet. Apart from those messages, all seems OK, but
I'm just wondering why it's getting those messages - what does those mean?

Cheers,
Alex
-- 
Huffapuff!

http://www.tahallah.clara.co.uk

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

[PATCH] CONFIG_MOUSE should not be tristate

2000-12-25 Thread Pavel Roskin


Hello!

CONFIG_MOUSE only enables further questions. It is never used except
drivers/char/Config.in where it's checked for being "n".

CONFIG_MOUSE=m makes no sence.

The patch is against 2.4.0-test13-pre4.

___
--- linux.orig/drivers/char/Config.in
+++ linux/drivers/char/Config.in
@@ -95,7 +95,7 @@
fi
 fi

-tristate 'Mouse Support (not serial and bus mice)' CONFIG_MOUSE
+bool 'Mouse Support (not serial and bus mice)' CONFIG_MOUSE
 if [ "$CONFIG_MOUSE" != "n" ]; then
bool '  PS/2 mouse (aka "auxiliary device") support' CONFIG_PSMOUSE
tristate '  CT 82C710 mouse port support (as on TI Travelmate)' 
CONFIG_82C710_MOUSE
___

Regards,
Pavel Roskin

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

Re: Proposal: devfs names ending in %d or %u

2000-12-25 Thread idalton


On Sun, Dec 24, 2000 at 11:02:39PM -0800, Barry K. Nathan wrote:
 Eric Shattow wrote:
 [snip]
  when i insert a FAT formatted disc with a PC partition table, the partition
  i want to mount is part1.  when i insert a HFS formatted disc with a MAC
  partition table, the partition i want to mount is part4. this is very ugly,
 
 and it has nothing to do with devfs. Those would be /dev/sda1 (adjust
 device name for IDE instead of SCSI, etc.) and /dev/sda4 without devfs.
 
 In this case, the problem is that different Zip disks really do have their
 data on different partitions. (If you use enough different disks and
 formatting utilities, it won't even be the same partition for all PC disks
 or all Mac disks, IIRC.) I don't use Zip disks much anymore, although
 there's a similar phenomenon with my SCSI MO drive on my desktop Mac
 (which I recently started using Linux on again).
[snip]

And don't forget that IDE zip drives can be programmed to hide the
partition table altogether from the OS. Supposedly this can be changed
via an ATAPI command to the drive, but I don't think the kernel driver
has any support for this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

BIOS problem, pro Microsoft, anti other OS


To Maintainer:
PCI SUBSYSTEM
P:  Martin Mares
M:  [EMAIL PROTECTED]
L:  [EMAIL PROTECTED]
S:  Supported

This alert should probably be forwarded to Others, but appropriate
subTask persons in the kernel-source Maintainers list were not obvious.

Briefly, documented below is the fact/complications that some PC BIOS
chips are now coming with a default Microsoft setting, which makes them
hostile to some functionalities of other OS.  If particular under Linux,
a PCI Winmodem did NOT function with the Win98 BIOS setting, but did
fine  with BIOS choice "Other OS".  Possible, other PCI devices under
Linux OS might be simmilarly afflicated.

This indicates a need for Linux install software to be equipped with a
utility to probe the BIOS and report back "Linux hostile" BIOS
settings.  Today most Newbies are getting new PC boxes equipped with
WinModems.  Hostile BIOS settings will block their capability to get
on-line.  Unfortunately, I do not have the technical capablity to
directly contribute.  Thus please forward this alert to however may be
capable and concerned with dealing with the problem.

MarvS, co-maintainer: http://walbran.org/sean/linux/linmodem-howto.html

===
Subject:  Device or resource busy : SUCCESS !
 Date: Sun, 24 Dec 2000 14:46:04 +0200 (IST)
From: Jacques Goldberg [EMAIL PROTECTED]
 Reply-To:  Jacques Goldberg [EMAIL PROTECTED]
   To: [EMAIL PROTECTED]

 Well, my very sincere thanks to all of you. It works.

DETAILS:
I purchased a Gateway Solo 2550 in September, comes with ActionTec PCI
56k
modem (Lucent chip vendor 11c1, device 448).
I tried the 568 ltmodem: device or resource busy,could not guess why.
cat /pro/pci would show no interrupt
Then ltmodem 578  was made available: same problem.
But then the PnP issue at boot came again last week.
I had tried several times to discover the option in my BIOS setup.
This morning I found: in the "advanced" page there is an "Operating
System" option, to be set to "the most frequently used OS". I had left
it
as Win98/2000 (as I received the machine). 
I just selected OTHER.
Lo and behold, ltmodem.o loads without a flaw, I then had a short dumb
terminal session with minicom, and am now connected at my first attempt
with ppp, having already used X11, ssh, and Netscape.

So, again my deepest thanks to all of you on this list, and the bottom
line for newcomers:

 IF (Device.or.resource busy) CHECK YOUR BIOS.

By the way I am running RH-6.1, kernel 2.2.12-20 (CERN "official" Linux
distribution). They are on vacations now, I cannot check at this time if
their version of ppp is "generic" or reworked.

Jacques J. Goldberg
[EMAIL PROTECTED]
 Currently at TECHNION 
PHONE: Technion=+(972)(0)(4)829.36.63
   CERN=+(41)(22)767.84.72
  Original Message 
Subject: Crippling BIOSes
Date: Sun, 24 Dec 2000 14:55:36 -0500
From: Marvin Stodolsky [EMAIL PROTECTED]
To: LinModems [EMAIL PROTECTED]

Folks,
Given Jacques report, it would be good to set up a
diagnostic for BIOS which have such Microsoft/Other choices.  
Mine does not.
For those of you who have such BIOSes, please 
1) Do  boots under both choices
2) Under microsoft do:
  dmesg  ms.txt
3) Under other
   dmesg  other.txt
4) diff ms.txt other.txt
and report the differences to the List with the name of the BIOS.
If would clearly be desirable to equip future Linux kernels/software to
give a warning about the crippling microsoft option, 
which may hamper other PCI harware under Linux as well.

MarvS   

 Original Message 
Subject:   Re: dmesg detection??
 Date:   Mon, 25 Dec 2000 09:29:20 +0200 (IST)
From:Jacques Goldberg [EMAIL PROTECTED]
 Reply-To:   Jacques Goldberg [EMAIL PROTECTED]
   To:   Marvin Stodolsky [EMAIL PROTECTED]
  CC:[EMAIL PROTECTED]

 Gateway Solo 2150
 Phoenix BIOS version 17.50
 BIOS Page "Advanced"
 BIOS Field "Installed O/S" may be "Other" "Win98/Win2000" or "Win95"
 Did not try "Win95"
 Default was Win98/Win2000, dmesg file attached is  ms.txt
 Changed to "Other" , dmesg file atached is  other.txt

 Linux kernel 2.2.12-20
 
 SOUND:
  CONFIG_SOUND set to "m"
  Using OSS driver (ES-1371 not supported by RH-6.1  2.2.12-20
distribution)
  Using PPP version 2.3.10-3

 Everything works fine (ppp sessions with sound) once BIOS O/S choice
set
to OTHER.
 
 I repeat what my problem was:
 -could not load ltmodem : "Device or resource busy"
 -cat /pro/pci did not show IRQ, not even the word IRQ, for Lucent modem
 -setting BIOS to OTHER instantly made everything work.

Jacques J. Goldberg
[EMAIL PROTECTED]


 dmesg  ms.txt (Win98 BIOS setting)

Linux version 2.2.12-20 ([EMAIL PROTECTED]) (gcc version
egcs-2.91.66 19990314/Linux

Re: css hang; somewhere between test12 and test13pre4ac2


On Mon, Dec 25 2000, Mohammad A. Haque wrote:
 This is confirmed. mounting css dics causes oops. non-css discs work
 fine. 
 
 oops coming soon.

Thanks. If it's the cdrom_log_sense oops, please try also with
previously sent patch.

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

Re: css hang; somewhere between test12 and test13pre4ac2


Heh, just go it. Testing

Jens Axboe wrote:
 
 Thanks. If it's the cdrom_log_sense oops, please try also with
 previously sent patch.

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots


Hello Mike, hello linux-kernel hackers,

Mike Galbraith wrote:
 I wouldn't (not going to here;) spend a lot of time on it.  The compiler
 has problems.  It won't build glibc-2.2, and chokes horribly on ipchains.

Maybe, but you were lucky getting an ICE, and not silently failing code :-)

After having spent several hours debugging now, I think it was 
worth it (at least for my understanding of lower-level kernel issues and of 
the (rather nice and almost readable) assembly code gcc generates). There 
seems to be something going wrong in the down(sem) path after the 
kernel_thread call. 

I'm not sure if down() succeeds instantly when compiling the kernel with 
2.95.2, but it seems to fail for 2.97; I figured out by spilling some 
printk's around in bdflush_init, which made the bug magically disappear, due 
to the looser timing. This also might happen for compiling with frame 
pointers or with the static declaration variables, somehow.

Th bdflush_init function itself does not seem to be responsible, which 
corresponds with the assembly, which is fine and should get the same results 
for all compiled cases.

It seems that whyever, the cause for this failure is actually the down(sem) 
call on a not yet up()'ed semaphore, and this is where it starts to get ugly.

down() then calls __down_failed, which ends up in __down(); __down does some 
waitqueue handling, which I don't understand, and then calls __wake_up - up 
to then, everything seems fine, in __wake_up it is where my search ended up 
to now, but I think something is wrong in this context; however, the 
complexity of this code exceeds my knowledge by magnitudes, so I can't 
continue searching there without going mad :-)

It would be nice if someone else could look from there on, now I've narrowed 
the case down to rather low-level functions.

Greetings,
Andreas

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

Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots


Hello Mike, hello linux-kernel hackers,

Mike Galbraith wrote:
 I wouldn't (not going to here;) spend a lot of time on it.  The compiler
 has problems.  It won't build glibc-2.2, and chokes horribly on ipchains.

Maybe, but after having spent several hours debugging now, I think it was 
worth it: I am almost sure this is not a gcc bug, but a nasty race condition 
involving the semaphore handling bdflush_init. 

I figured out by spilling some printk's around in bdflush_init, which made 
the bug magically disappear, what wasn't what I intended - but which gave me 
a clearer impression of what's going on.

It seems that whyever, the cause for this failure is actually the down(sem) 
call on a not yet up()'ed semaphore, and this is where it starts to get ugly.


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

Re: BIOS problem, pro Microsoft, anti other OS

2000-12-25 Thread Martin Mares

Hello!

This alert should probably be forwarded to Others, but appropriate
subTask persons in the kernel-source Maintainers list were not obvious.

Briefly, documented below is the fact/complications that some PC BIOS
chips are now coming with a default Microsoft setting, which makes them
hostile to some functionalities of other OS. If particular under Linux,
a PCI Winmodem did NOT function with the Win98 BIOS setting, but did
fine with BIOS choice "Other OS". Possible, other PCI devices under
Linux OS might be simmilarly afflicated.

This indicates a need for Linux install software to be equipped with a
utility to probe the BIOS and report back "Linux hostile" BIOS
settings. Today most Newbies are getting new PC boxes equipped with
WinModems. Hostile BIOS settings will block their capability to get
on-line. Unfortunately, I do not have the technical capablity to
directly contribute. Thus please forward this alert to however may be
capable and concerned with dealing with the problem.

Can you check what does Linux 2.4.0-testlatest behave, please?

I know of these problems and I hope the new PCI code in 2.4.0 is able
to assign the missing memory/IO resources without help of the BIOS, but
unfortunately 2.2 isn't and it's very difficult to back-port the fixes
as they depend on changes in many other parts of the kernel.

You probably should make the ltmodem driver check the region base
registers and interrupts and if they are not set, recommend the user to
change the OS or PNP settings in their BIOS setup.

Have a nice fortnight
--
Martin `MJ' Mares [EMAIL PROTECTED] [EMAIL PROTECTED] http://atrey.karlin.mff.cuni.cz/~mj/
First law of socio-genetics: Celibacy is not hereditary.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre4... udf problem with dvd access vs test12


On Mon, Dec 25 2000, Mohammad A. Haque wrote:
 Jens, I made sure to reverse the udf patch I mentioned in another thread
 (all it really is merging changes from linux-udf cvs into the current
 kernel). So this is from a clean test13-pre4 w/ some netfilter fixes.

Ok, looks unrelated however.

 EIP; c019c017 cdrom_log_sense+f/68   =

Yes I know about this one, I've attached the patch here again. Linus,
could you apply?

--- drivers/ide/ide-cd.c~   Sat Dec 23 23:59:52 2000
+++ drivers/ide/ide-cd.cSun Dec 24 00:03:38 2000
@@ -333,7 +333,7 @@
 {
int log = 0;
 
-   if (sense == NULL || pc-quiet)
+   if (sense == NULL || pc == NULL || pc-quiet)
return 0;
 
switch (sense-sense_key) {

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

Re: test13-pre4... udf problem with dvd access vs test12


Fix confirmed. Am i supposed to get some DriveSense errors? I probably
am just don't recall.

Jens Axboe wrote:
 Yes I know about this one, I've attached the patch here again. Linus,
 could you apply?
 
 --- drivers/ide/ide-cd.c~   Sat Dec 23 23:59:52 2000
 +++ drivers/ide/ide-cd.cSun Dec 24 00:03:38 2000
 @@ -333,7 +333,7 @@
  {
 int log = 0;
 
 -   if (sense == NULL || pc-quiet)
 +   if (sense == NULL || pc == NULL || pc-quiet)
 return 0;
 
 switch (sense-sense_key) {
 
 --
 * Jens Axboe [EMAIL PROTECTED]
 * SuSE Labs

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre4... udf problem with dvd access vs test12


Sorry, I meant DriveReady SeekComplete Error

"Mohammad A. Haque" wrote:
 Fix confirmed. Am i supposed to get some DriveSense errors? I probably
 am just don't recall.

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

serial mouse - lockup connection 2.4.0-t12

2000-12-25 Thread dep


greetings!

the lockup of test12 leaves no droppings i can find, but in the 
course of a half-dozen lockups in the last few days i've made an 
observation or two that may be of diagnostic help.

system is a k6-2 on a via chipset mb with onboard everything but 
video (fic va-503a). kernel built with gcc-2.95.2. glibc is 2.2.

the lockups occur during mouse movement -- mouse is kensington 
emulating microsoft. the peculiar thing is that the mouse 
acceleration seems to slow a little in the seconds before the lockup. 
i don't know that this is a useful datum, but it seemed as if it 
might be significant.

the lockups are otherwise neither predictable or reproducible.
-- 
dep
--
bipartisanship: an illogical construct not unlike the idea that
if half the people like red and half the people like blue, the 
country's favorite color is purple.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre4... udf problem with dvd access vs test12


On Mon, Dec 25 2000, Mohammad A. Haque wrote:
 Fix confirmed. Am i supposed to get some DriveSense errors? I probably
 am just don't recall.

Good. The whole idea of cdrom_log_sense is to be able to cleanly
limit the (often) sense-less (yes, haha :) ide-cd verbosity. Some of the
css stuff are obvious candidates. We want users to be aware of the
error, but often we end up flooding the logs with the same stuff over
and over again. This is often a source of confusion for the casual
user.

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

Re: Netgear FA311


Alex wrote:
 In the logs I'm seeing this: 
 
 Dec 25 15:25:18 tahallah last message repeated 2 times 
 Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0783. 
 Dec 25 15:25:19 tahallah kernel: eth0: Something Wicked happened! 0780. 

783 means:
Tx Underrun
Tx Idle
Tx Packet Error
Tx Descriptor
Rx Packet Error
Rx Descriptor
Rx OK.

Hmm. I download the Documentation from National
(http://www.national.com/pf/DP/DP83815.html),
and the the tx burst size/fill threshold/drain threshold combination is
invalid:

 from natsemi.c:
 /* Configure the PCI bus bursts and FIFO thresholds. */
 /* Configure for standard, in-spec Ethernet. */
 np-tx_config = (128) +   /* Automatic transmit padding */
 (123) +   /* Excessive collision retry */
 (0x020) + /* Max DMA burst = 512 byte */
 (88) +/* fill threshold = 256 byte */
 2;  /* drain threshold = 64 byte */
 writel(np-tx_config, ioaddr + TxConfig);


But:
 page 51
The MXDMA MUST NOT be greater than the Tx Fill Threshold 


Could you try this setup?

 /* Configure the PCI bus bursts and FIFO thresholds. */
 /* Configure for standard, in-spec Ethernet. */
 np-tx_config = (128) +   /* Automatic transmit padding */
 (123) +   /* Excessive collision retry */
 (620) + /* Max DMA burst = 128 byte */
 (88) +/* fill threshold = 256 byte */
 8;  /* drain threshold = 256 byte */
 writel(np-tx_config, ioaddr + TxConfig);


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

Re: Netgear FA311


On Mon, 25 Dec 2000, Manfred wrote:

 Could you try this setup?
 
  /* Configure the PCI bus bursts and FIFO thresholds. */
  /* Configure for standard, in-spec Ethernet. */
  np-tx_config = (128) +   /* Automatic transmit padding */
  (123) +   /* Excessive collision retry */
  (620) + /* Max DMA burst = 128 byte */
  (88) +/* fill threshold = 256 byte */
  8;  /* drain threshold = 256 byte */
  writel(np-tx_config, ioaddr + TxConfig);
 

Hmm, that little change worked a lot better. However thoughput is down to
700kb/s! Transferring files from the other machine to this machine is much
faster - 868kb/s.

In the logs, I only got *one* message from the natsemi driver (and this
happened when sending files from this machine to the other machine. No
problems receiving from the other machine.

Dec 25 17:28:12 tahallah kernel: eth0: Something Wicked happened! 0583.

But I just realised that the other machine I'm using has an 10 megabit
ethernet card (on the hub that one is shown on 10, my machine is shown as
100). I think this explains the throughput problem. When I get another 4
way power socket, I'll put my other machine (which has a 100 megabit card
in it) on the network and see if that makes a difference.

Cheers,
Alex
-- 
Huffapuff!

http://www.tahallah.clara.co.uk

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

Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots


On Mon, 25 Dec 2000, Andreas Franck wrote:

 Hello Mike, hello linux-kernel hackers,
 
 Mike Galbraith wrote:
  I wouldn't (not going to here;) spend a lot of time on it.  The compiler
  has problems.  It won't build glibc-2.2, and chokes horribly on ipchains.
 
 Maybe, but after having spent several hours debugging now, I think it was 
 worth it: I am almost sure this is not a gcc bug, but a nasty race condition 
 involving the semaphore handling bdflush_init. 
 
 I figured out by spilling some printk's around in bdflush_init, which made 
 the bug magically disappear, what wasn't what I intended - but which gave me 
 a clearer impression of what's going on.

Oh?  Can you show me (offline) what you did exactly that made it go away?
(that's kinda scary.. _much_ prefer 'compiler has rough edges' option;)

-Mike

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

Re: css hang; somewhere between test12 and test13pre4ac2


Hi Jens,
  Thanks for the patch; unfortunatly at the moment I can neither confirm
or deny whether the patch works - since the damn thing won't crash on me
with or without the patch - I suspect it depends on system mood.

But I have a PDA logging console so if it happens I should catch it.

Thanks again,

Dave

-- 
  Have a happy GNU millennium! --   
/ Dr. David Alan Gilbert  | Running GNU/Linux on   |  Happy  \ 
\   gro.gilbert @ treblig.org |  Alpha, x86, ARM and SPARC |  In Hex /
 \ ___|___ http://www.treblig.org  |/

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

Re: Fatal Oops on boot with 2.4.0testX and recent GCC snapshots


On Mon, 25 Dec 2000, Andreas Franck wrote:

 Hello Mike, hello linux-kernel hackers,
 
 Mike Galbraith wrote:
  I wouldn't (not going to here;) spend a lot of time on it.  The compiler
  has problems.  It won't build glibc-2.2, and chokes horribly on ipchains.
 
 Maybe, but you were lucky getting an ICE, and not silently failing code :-)

You bet.

 After having spent several hours debugging now, I think it was 
 worth it (at least for my understanding of lower-level kernel issues and of 
 the (rather nice and almost readable) assembly code gcc generates). There 

Don't get me wrong, chasing things like this is never a waste of time.
In the case of gcc in particular.  Our next 'stable' kernel compiler
is going to come from the gcc development tree just as the next 'stable'
kernel is coming out of the kernel development tree.

-Mike

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

Re: BIOS problem, pro Microsoft, anti other OS