Re: isa_read/write not available on ppc - solution suggestions ??

[Geert Uytterhoeven]

On 1 May 2001, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
>  <[EMAIL PROTECTED]> wrote:
> >>[EMAIL PROTECTED] wrote:
> >>> 
> >>> To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the
> >>> isa_read/write's have to be changed to regular read/write due to the 
> >lack
> >>> of the isa_read/write functions for ppc.
> >
> >> Treat it like a PCI device and use ioremap().  Then change isa_readl()
> >> to readl() etc.
> >
> >Bleurgh, the latest version of the driver (not in the kernel yet) searches 
> >for turbo based cards by checking the isa address space from 0xc - 
> >0xe in 8k chunks. So we'd have to ioremap each 8k section, check it, 
> >find out the adapter isn't there and then iounmap it. 
> >
> >Oh well, if that's what it takes =:0
> 
> I would suggest the opposite approach instead: make the PPC just support
> isa_readx/isa_writex instead.
> 
> Much simpler, and doesn't need changes to (correct) driver sources.

And while you're at it, please add isa_{request,release}_mem_region() as well.

Reasoning: while we can (and do) make ioremap(0xa, ...) work fine on PPC
(you must not use ioremap() for RAM, so it must be ISA memory space), we can't
distinguish between the first 16 MB of RAM and ISA memory space for
{request,release}_mem_region()...

Gr{oetje,eeting}s,

Geert

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

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

Patch: softdog and WDIOS_DISABLECARD

[Shane Wegner]

Hi,

I have found a potential problem with the current
implementation of the software watchdog.  I have
CONFIG_WATCHDOG_NOWAYOUT set for a reliable watchdog. 
However, there are instances where I want to explicitly
shut it down.  The problem with disabling
CONFIG_WATCHDOG_NOWAYOUT is that events other than an
explicit shutdown can disable the timer.  A SIGSEGV
perhaps or the daemon being killed by the OOM handler.  In
cases like this, the system should reboot IMO.

This small patch adds the appropriate options to enable and
disable the timer explicitly.

--- softdog.c.orig  Wed May  2 00:15:56 2001
+++ softdog.c   Wed May  2 00:15:19 2001
@@ -130,6 +130,7 @@
static struct watchdog_info ident = {
identity: "Software Watchdog",
};
+   int rv;
switch (cmd) {
default:
return -ENOIOCTLCMD;
@@ -140,6 +141,25 @@
case WDIOC_GETSTATUS:
case WDIOC_GETBOOTSTATUS:
return put_user(0,(int *)arg);
+   case WDIOC_SETOPTIONS:
+   if(copy_from_user(&rv, (int*) arg, sizeof(int)))
+   return -EFAULT;
+
+   if (rv & WDIOS_DISABLECARD) {
+   lock_kernel();
+   del_timer(&watchdog_ticktock);
+   unlock_kernel();
+   return 0;
+   }
+
+   if (rv & WDIOS_ENABLECARD) {
+   lock_kernel();
+   mod_timer(&watchdog_ticktock, jiffies +
+  (soft_margin * HZ));
+   unlock_kernel();
+   return 0;
+   }
+
case WDIOC_KEEPALIVE:
mod_timer(&watchdog_ticktock, jiffies+(soft_margin*HZ));
return 0;

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

PATCH: es1370 move pci_enable_device

[Marcus Meissner]

Hi,

This moves pci_enable_device to the correct position in es1370 and
cleans up the return values in es1370_probe.

Ciao, Marcus

Index: drivers/sound/es1370.c
===
RCS file: /build/mm/work/repository/linux-mm/drivers/sound/es1370.c,v
retrieving revision 1.13
diff -u -r1.13 es1370.c
--- drivers/sound/es1370.c  2001/04/17 17:26:05 1.13
+++ drivers/sound/es1370.c  2001/05/02 06:51:05
@@ -2560,19 +2560,21 @@
{ SOUND_MIXER_WRITE_OGAIN, 0x4040 }
 };
 
-#define RSRCISIOREGION(dev,num) (pci_resource_start((dev), (num)) != 0 && \
-pci_resource_flags((dev), (num)) & IORESOURCE_IO)
-
 static int __devinit es1370_probe(struct pci_dev *pcidev, const struct pci_device_id 
*pciid)
 {
struct es1370_state *s;
mm_segment_t fs;
-   int i, val;
+   int i, val, ret;
+
+   if ((ret=pci_enable_device(pcidev)))
+   return ret;
 
-   if (!RSRCISIOREGION(pcidev, 0))
-   return -1;
+   if ((!pci_resource_flags(pcidev, 0) & IORESOURCE_IO) ||
+!pci_resource_start(pcidev, 0)
+   )
+   return -ENODEV;
if (pcidev->irq == 0) 
-   return -1;
+   return -ENODEV;
i = pci_set_dma_mask(pcidev, 0x);
if (i) {
printk(KERN_WARNING "es1370: architecture does not support 32bit PCI 
busmaster DMA\n");
@@ -2580,7 +2582,7 @@
}
if (!(s = kmalloc(sizeof(struct es1370_state), GFP_KERNEL))) {
printk(KERN_WARNING "es1370: out of memory\n");
-   return -1;
+   return -ENOMEM;
}
memset(s, 0, sizeof(struct es1370_state));
init_waitqueue_head(&s->dma_adc.wait);
@@ -2597,14 +2599,14 @@
s->irq = pcidev->irq;
if (!request_region(s->io, ES1370_EXTENT, "es1370")) {
printk(KERN_ERR "es1370: io ports %#lx-%#lx in use\n", s->io, 
s->io+ES1370_EXTENT-1);
+   ret = -EBUSY;
goto err_region;
}
-   if (pci_enable_device(pcidev))
-   goto err_irq;
-   if (request_irq(s->irq, es1370_interrupt, SA_SHIRQ, "es1370", s)) {
+   if ((ret=request_irq(s->irq, es1370_interrupt, SA_SHIRQ, "es1370",s))) {
printk(KERN_ERR "es1370: irq %u in use\n", s->irq);
goto err_irq;
}
+
/* initialize codec registers */
/* note: setting CTRL_SERR_DIS is reported to break
 * mic bias setting (by [EMAIL PROTECTED]) */
@@ -2631,14 +2633,22 @@
   (s->ctrl & CTRL_XCTL0) ? "out" : "in",
   (s->ctrl & CTRL_XCTL1) ? "1" : "0");
/* register devices */
-   if ((s->dev_audio = register_sound_dsp(&es1370_audio_fops, -1)) < 0)
+   if ((s->dev_audio = register_sound_dsp(&es1370_audio_fops, -1)) < 0) {
+   ret = s->dev_audio;
goto err_dev1;
-   if ((s->dev_mixer = register_sound_mixer(&es1370_mixer_fops, -1)) < 0)
+   }
+   if ((s->dev_mixer = register_sound_mixer(&es1370_mixer_fops, -1)) < 0) {
+   ret = s->dev_mixer;
goto err_dev2;
-   if ((s->dev_dac = register_sound_dsp(&es1370_dac_fops, -1)) < 0)
+   }
+   if ((s->dev_dac = register_sound_dsp(&es1370_dac_fops, -1)) < 0) {
+   ret = s->dev_dac;
goto err_dev3;
-   if ((s->dev_midi = register_sound_midi(&es1370_midi_fops, -1)) < 0)
+   }
+   if ((s->dev_midi = register_sound_midi(&es1370_midi_fops, -1)) < 0) {
+   ret = s->dev_midi;
goto err_dev4;
+   }
/* initialize the chips */
outl(s->ctrl, s->io+ES1370_REG_CONTROL);
outl(s->sctrl, s->io+ES1370_REG_SERIAL_CONTROL);
@@ -2688,7 +2698,7 @@
release_region(s->io, ES1370_EXTENT);
  err_region:
kfree(s);
-   return -1;
+   return ret;
 }
 
 static void __devinit es1370_remove(struct pci_dev *dev)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unknown HZ value! (2000) Assume 1024.

[Tom Holroyd]

On Wed, 2 May 2001, Albert D. Cahalan wrote:

> This is pretty bogus. The idle time can run _backwards_ on an SMP
> system.

True, but it's failing for single CPU systems (like mine), too.

>> I notice also that since kstat.per_cpu_nice is an unsigned int, it's
>> going to overflow in another 3.6 days anyhow. ... Any chance of making
>> those guys longs?

> For 32-bit systems, we use 32-bit values to reduce overhead.
> This causes problems at 495/smp_num_cpus days of uptime.

You mean for HZ == 100.  And I guess the overhead in question is the cost
of a 64 bit add vs. a 32 bit add HZ times per second?  On a 64 bit
machine, that overhead is likely to be exactly zero.  It is zero on my
machine.  For integer math on an Alpha, changing the ints to longs can
even make a program run faster.

> Proposed hack: set a very-long-duration timer (several days)
> to check for the high bit changing. Count bit flips.

What about the interval between when it flips and when you notice it?

No, change the kstat variables to unsigned longs on 64 bit systems.
In fact, make them unsigned longs on any system, as opposed to something
like u_int64 or whatever.  (And fix the code in proc_misc.c that uses
them.)

For 32 bit systems with HZ == 1024, decide if an overhead of about 1 usec
per second is too much to justify using 64 bits.  That's 4 seconds lost
over the 49 days it takes to fail (if your hardware isn't that fast what
are you doing with HZ == 1024 in the first place).

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

Re: PATCH: es1370 move pci_enable_device

[Marcus Meissner]

On Wed, May 02, 2001 at 09:44:21AM +0200, Marcus Meissner wrote:
> Hi,
> 
> This moves pci_enable_device to the correct position in es1370 and
> cleans up the return values in es1370_probe
> 
> Ciao, Marcus

> + if ((!pci_resource_flags(pcidev, 0) & IORESOURCE_IO) ||

Slightly bad placed braces, fixed.

Ciao, Marcus
Index: drivers/sound/es1370.c
===
RCS file: /build/mm/work/repository/linux-mm/drivers/sound/es1370.c,v
retrieving revision 1.13
diff -u -r1.13 es1370.c
--- drivers/sound/es1370.c  2001/04/17 17:26:05 1.13
+++ drivers/sound/es1370.c  2001/05/02 07:55:33
@@ -2560,19 +2560,21 @@
{ SOUND_MIXER_WRITE_OGAIN, 0x4040 }
 };
 
-#define RSRCISIOREGION(dev,num) (pci_resource_start((dev), (num)) != 0 && \
-pci_resource_flags((dev), (num)) & IORESOURCE_IO)
-
 static int __devinit es1370_probe(struct pci_dev *pcidev, const struct pci_device_id 
*pciid)
 {
struct es1370_state *s;
mm_segment_t fs;
-   int i, val;
+   int i, val, ret;
+
+   if ((ret=pci_enable_device(pcidev)))
+   return ret;
 
-   if (!RSRCISIOREGION(pcidev, 0))
-   return -1;
+   if ( !(pci_resource_flags(pcidev, 0) & IORESOURCE_IO) ||
+!pci_resource_start(pcidev, 0)
+   )
+   return -ENODEV;
if (pcidev->irq == 0) 
-   return -1;
+   return -ENODEV;
i = pci_set_dma_mask(pcidev, 0x);
if (i) {
printk(KERN_WARNING "es1370: architecture does not support 32bit PCI 
busmaster DMA\n");
@@ -2580,7 +2582,7 @@
}
if (!(s = kmalloc(sizeof(struct es1370_state), GFP_KERNEL))) {
printk(KERN_WARNING "es1370: out of memory\n");
-   return -1;
+   return -ENOMEM;
}
memset(s, 0, sizeof(struct es1370_state));
init_waitqueue_head(&s->dma_adc.wait);
@@ -2597,14 +2599,14 @@
s->irq = pcidev->irq;
if (!request_region(s->io, ES1370_EXTENT, "es1370")) {
printk(KERN_ERR "es1370: io ports %#lx-%#lx in use\n", s->io, 
s->io+ES1370_EXTENT-1);
+   ret = -EBUSY;
goto err_region;
}
-   if (pci_enable_device(pcidev))
-   goto err_irq;
-   if (request_irq(s->irq, es1370_interrupt, SA_SHIRQ, "es1370", s)) {
+   if ((ret=request_irq(s->irq, es1370_interrupt, SA_SHIRQ, "es1370",s))) {
printk(KERN_ERR "es1370: irq %u in use\n", s->irq);
goto err_irq;
}
+
/* initialize codec registers */
/* note: setting CTRL_SERR_DIS is reported to break
 * mic bias setting (by [EMAIL PROTECTED]) */
@@ -2631,14 +2633,22 @@
   (s->ctrl & CTRL_XCTL0) ? "out" : "in",
   (s->ctrl & CTRL_XCTL1) ? "1" : "0");
/* register devices */
-   if ((s->dev_audio = register_sound_dsp(&es1370_audio_fops, -1)) < 0)
+   if ((s->dev_audio = register_sound_dsp(&es1370_audio_fops, -1)) < 0) {
+   ret = s->dev_audio;
goto err_dev1;
-   if ((s->dev_mixer = register_sound_mixer(&es1370_mixer_fops, -1)) < 0)
+   }
+   if ((s->dev_mixer = register_sound_mixer(&es1370_mixer_fops, -1)) < 0) {
+   ret = s->dev_mixer;
goto err_dev2;
-   if ((s->dev_dac = register_sound_dsp(&es1370_dac_fops, -1)) < 0)
+   }
+   if ((s->dev_dac = register_sound_dsp(&es1370_dac_fops, -1)) < 0) {
+   ret = s->dev_dac;
goto err_dev3;
-   if ((s->dev_midi = register_sound_midi(&es1370_midi_fops, -1)) < 0)
+   }
+   if ((s->dev_midi = register_sound_midi(&es1370_midi_fops, -1)) < 0) {
+   ret = s->dev_midi;
goto err_dev4;
+   }
/* initialize the chips */
outl(s->ctrl, s->io+ES1370_REG_CONTROL);
outl(s->sctrl, s->io+ES1370_REG_SERIAL_CONTROL);
@@ -2688,7 +2698,7 @@
release_region(s->io, ES1370_EXTENT);
  err_region:
kfree(s);
-   return -1;
+   return ret;
 }
 
 static void __devinit es1370_remove(struct pci_dev *dev)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PROBLEM: 2.4.4 oops, will not boot

[Gordon Sadler]

Please CC on replies.
Attached is REPORTING-BUGS template from source, and a hand copied oops
that I ran through ksymoops. I really hope this is resolved, anything
further needed, just ask.

It's freezing while startup scripts are run, on Debian Sid, it has just
finished clean /var /tmp etc, and is doing one of three things from tail
end of /etc/rcS/S55bootmisc.sh:
1. if [ -c /dev/ttyp0 ]
 then
chmod 666 /dev/tty[p-za-e][0-9a-f]
chown root:tty /dev/tty[p-za-e][0-9a-f]
   fi
2. if [ "$EDITMOTD" != no ]
 then
uname -a > /etc/motd.tmp
sed 1d /etc/motd >> /etc/motd.tmp
mv /etc/motd.tmp /etc/motd
   fi
3. dmesg > /var/log/dmesg

It never gets to /etc/rcS/S55urandom: echo -n "Initializing random number generator... 
"

In addition, about 30 seconds after the oops, while I was copying it,
the following printed at bottom of screen:
VM: refill_inactive, wrong page on list




[1.] One line summary of the problem:
2.4.4 oops, will not boot

[2.] Full description of the problem/report:
With 2.4.4 I actually received an oops prior to login, but forgot to hand
copy it, will try to replicate and run through ksymoops.
2.4.4ac2 blanks the screen right after LILO, then absolutely nothing, I
was able to use reset button on computer.

[3.] Keywords (i.e., modules, networking, kernel):
kernel AMD VIA

[4.] Kernel version (from /proc/version):
2.4.4{ac2}
2.2.19 works just fine using it now

[5.] Output of Oops.. message (if applicable) with symbolic information 
 resolved (see Documentation/oops-tracing.txt)
To follow, assuming I can replicate with 2.4.4 and copy without typos.

[6.] A small shell script or example program which triggers the
 problem (if possible)
 
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Debian Sid
Gnu C  2.95.4
Gnu make   3.79.1
binutils   2.11.90.0.7
util-linux 2.11b
mount  2.11b
modutils   2.4.5
e2fsprogs  1.19
Linux C Library2.2.2
Dynamic linker (ldd)   2.2.2
Procps 2.0.7
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   2.0.11

[7.2.] Processor information (from /proc/cpuinfo):
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 3
model name  : AMD Duron(tm) Processor
stepping: 1
cpu MHz : 801.828
cache size  : 64 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 psn mmxext mmx fxsr 3dnowext 3dnow
bogomips: 1599.07

[7.3.] Module information (from /proc/modules):

[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
Obtained under running 2.2.19:
/proc/ioports
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
02f8-02ff : serial(set)
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(set)
d000-d007 : ide0
88401000-8840101f : Intel Speedo3 Ethernet
/proc/iomem
Non-existant

[7.5.] PCI information ('lspci -vvv' as root)
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- 
FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 
[Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- 
FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- 
FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 

[7.6.] SCSI information (from /proc/scsi/scsi)

[7.7.] Other information that might be relevant to the problem
   (please look in /proc and include all information that you
   think to be relevant):
[X.] Other notes, patches, fixes, workarounds:
SCSI is available as a module, but for test purposes I am using only IDE
provided by mothe

ioctl call for network device

[sébastien person]

Hi,

I've succeed to do an ioctl call and recept it in my module

ioctl(file_descriptor, cmd, struct ifreq)

but I believe that I'm oblige to use the struct ifreq and I can't
pass any other arguments because an user can't acces kernel space
so the ioctl call recopy data in the kernel space (this is what I've
understood, maybe I'm wrong ...).

My problem is that I need to pass some int arguments (the best way was an
int* ) but the struct ifreq doesn't permit me it, so could I add other
arguments as we can do in an normal ioctl call ?

I hope this is the wrong place for this question.

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

Re: PATCH 2.4.4: Via audio fixes

[Richard Guenther]

On Mon, 30 Apr 2001, Jeff Garzik wrote:

> The attached patch includes fixes to the Via audio driver for which I'm
> interested finding testers.  Testing and a private "it works" (hopefully
> :)) or "it doesn't work,  is what breaks for me" would be
> appreciated.

Works as before -> mono recording does _not_ work, i.e. gives garbage
(as described in sf bugreport).

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

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

Re: Breakage of opl3sax cards since 2.4.3 (at least)

[Vivek Dasmohapatra]

On Wed, 2 May 2001, Russ Dill wrote:

> Actually, this occured at 2.4.2
> 
> I searched though the archives, and the only people who were able to get
> this resolved were those with a non-isapnp card (by added isapnp=0).
> However, I have an isapnp card and the driver doesn't think my card
> exists. If I lod it, withot options, I get:

I have an isapnp opl3sax system [2.4.3-ac5] - the sound card initialises
fine, I just have to kick the second logical device with by cat'ing the
following into /proc/isapnp:

card 0 YMH0802
dev 0 YMH0022
port 0 0x201
activate

Which then activates the gameport: What are the contents of your
/proc/isapnp? Mine says: 

##
Card 1 'YMH0802:YAMAHA OPL3-SAx Audio System' PnP version 1.0
  Logical device 0 'YMH0021:Unknown'
Device is active
Active port 0x240,0xe80,0x388,0x300,0x100
Active IRQ 5 [0x2]
Active DMA 1,3
Resources 0
  Priority preferred
  Port 0x220-0x220, align 0xf, size 0x10, 16-bit address decoding
  Port 0x530-0x530, align 0x7, size 0x8, 16-bit address decoding
  Port 0x388-0x388, align 0x3, size 0x4, 16-bit address decoding
  Port 0x330-0x330, align 0x1, size 0x2, 16-bit address decoding
  Port 0x370-0x370, align 0x1, size 0x2, 16-bit address decoding
  IRQ 5 High-Edge
  DMA 0 8-bit byte-count type-A
  DMA 1 8-bit byte-count type-A
  Alternate resources 0:1
Priority acceptable
Port 0x240-0x240, align 0xf, size 0x10, 16-bit address decoding
Port 0xe80-0xe80, align 0x7, size 0x8, 16-bit address decoding
Port 0x388-0x388, align 0x3, size 0x4, 16-bit address decoding
Port 0x300-0x300, align 0x1, size 0x2, 16-bit address decoding
Port 0x100-0xffe, align 0x1, size 0x2, 16-bit address decoding
IRQ 5,7,2/9,10,11 High-Edge
DMA 0,1,3 8-bit byte-count type-A
DMA 0,1,3 8-bit byte-count type-A
  Alternate resources 0:2
Priority functional
Port 0x220-0x280, align 0xf, size 0x10, 16-bit address decoding
Port 0x530-0xf48, align 0x7, size 0x8, 16-bit address decoding
Port 0x388-0x3f8, align 0x7, size 0x4, 16-bit address decoding
Port 0x300-0x334, align 0x1, size 0x2, 16-bit address decoding
Port 0x100-0xffe, align 0x1, size 0x2, 16-bit address decoding
IRQ 3,5,7,2/9,10,11 High-Edge
DMA 0,1,3 8-bit byte-count type-A
DMA 0,1,3 8-bit byte-count type-A
  Logical device 1 'YMH0022:Unknown'
Compatible device PNPb02f
Device is active
Active port 0x201
Active DMA 0,0
Resources 0
  Priority preferred
  Port 0x201-0x201, align 0x0, size 0x1, 16-bit address decoding
  Alternate resources 0:1
Priority acceptable
Port 0x202-0x202, align 0x0, size 0x1, 16-bit address decoding
  Alternate resources 0:2
Priority acceptable
Port 0x203-0x203, align 0x0, size 0x1, 16-bit address decoding
  Alternate resources 0:3
Priority acceptable
Port 0x204-0x20f, align 0x0, size 0x1, 16-bit address decoding
##


I start the sound system with the following script:

modprobe soundcore
modprobe sound
modprobe mpu401 # not sure I need this
modprobe ad1848
modprobe opl3sa2 mss_io=0x530 io=0x388 mpu_io=0x330 irq=5 dma=0 dma2=1
modprobe opl3   # or this.

[Note that this part works fine without prodding /proc/isapnp]

Of course, you have a YMH0020, and I have a YMH0021, that could be making
all the difference.

-- 
Death before decaf.



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

[PROBLEM] socket buffering problem in 2.2.19

[Tomi Lapinlampi]

Hi,

There seems to be some kind of a buffering problem in the 2.2.19
kernel. The following sequence of system calls on a nonblocking TCP 
socket (on the client side) generates a broken pipe:

write(2)HTTP REQUESTread(2)
2. HTTP client  > HTTP Server

HTTP RESPONSE   write(2)
3. HTTP client <- HTTP Server

shutdown(2), close(2)
4. HTTP client <- HTTP Server

select(2) returns,
read(2) => broken pipe, HTTP response is lost
5. HTTP client 

Re: Breakage of opl3sax cards since 2.4.3 (at least)

[Russ Dill]

On 02 May 2001 09:30:03 +0100, Vivek Dasmohapatra wrote:

> I have an isapnp opl3sax system [2.4.3-ac5] - the sound card
initialises

> fine, I just have to kick the second logical device with by cat'ing the
> following into /proc/isapnp:
> 
> card 0 YMH0802
> dev 0 YMH0022
> port 0 0x201
> activate
> 
> Which then activates the gameport: What are the contents of your
> /proc/isapnp? 


this sounds similar to my manual running of isapnp

> Of course, you have a YMH0020, and I have a YMH0021, that could be making
> all the difference.



not quite, you seem to have a YMH0802, while I have a YMH0802, what
error were you originally getting?
with mine, it doesn't want to isapnp it, so after I do that on my own, I
get:
russ kernel: opl3sa2: Control I/O port 0x240 is not a YMF7xx chipset!

anyway, I changed the above to:

card 0 YMH0020
dev 0 YMH0022
port 0 0x201
activate

does nothing...the diff between the two /proc/isapnp's are (the second
part of the first chunk and the last chunk are a result of me running
isapnp):

-Card 1 'YMH0020:OPL3-SAX Sound Board' PnP version 1.0
+Card 1 'YMH0802:YAMAHA OPL3-SAx Audio System' PnP version 1.0 
   Logical device 0 'YMH0021:Unknown'
 Device is active
 Active port 0x240,0xe80,0x388,0x300,0x100
-Active IRQ 10 [0x2]
-Active DMA 0,3
+Active IRQ 5 [0x2] 
+Active DMA 1,3 
 Resources 0
   Priority preferred
   Port 0x220-0x220, align 0xf, size 0x10, 16-bit address decoding
@@ -18,7 +18,7 @@
 Priority acceptable
 Port 0x240-0x240, align 0xf, size 0x10, 16-bit address decoding
 Port 0xe80-0xe80, align 0x7, size 0x8, 16-bit address decoding
-Port 0x388-0x388, align 0x7, size 0x4, 16-bit address decoding
+Port 0x388-0x388, align 0x3, size 0x4, 16-bit address decoding 
 Port 0x300-0x300, align 0x1, size 0x2, 16-bit address decoding
 Port 0x100-0xffe, align 0x1, size 0x2, 16-bit address decoding
 IRQ 5,7,2/9,10,11 High-Edge
@@ -49,5 +49,5 @@
 Priority acceptable
 Port 0x203-0x203, align 0x0, size 0x1, 16-bit address decoding
   Alternate resources 0:3
-Priority functional
+Priority acceptable 
 Port 0x204-0x20f, align 0x0, size 0x1, 16-bit address decoding



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

Ati Rage 128 problems.

[Shahin, Mofeed]

G'day all,

I have a laptop (Dell Inspiron 8000) which has an Ati M4 Mobility.
The problem happens whan I try to do 3D stuff on it.
The example I am using is quake2 pointing at the Mesa GL drivers. (Redhat
7.1)
I get about 5-15 seconds into the demo when the whole machine locks up. It
sometimes comes back and says something along the lines of ~"R128 timed
out".
Some times I even get a message in /var/log/messages along the lines of 
"error in r128_flush_pixmap_cache" or something like that.
I don't have the laptop in front of me at the moment, and that is why my
recollection of the error messages is not precise.

I am wandering if this is a known bug, or new one, or if I am to blame.

BTW : I am running Redhat 7.1 with 2.4.2-2.

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

Re: Breakage of opl3sax cards since 2.4.3 (at least)

[Vivek Dasmohapatra]

On Wed, 2 May 2001, Russ Dill wrote:

> On 02 May 2001 09:30:03 +0100, Vivek Dasmohapatra wrote:
> 
> > I have an isapnp opl3sax system [2.4.3-ac5] - the sound card
> > initialises
[cut] 
> not quite, you seem to have a YMH0802, while I have a YMH0802, what
> error were you originally getting?

ad1848/cs4248 codec driver Copyright (C) by Hannu Savolainen 1993-1996
opl3sa2: Activated ISA PnP card 0 (active=1)
opl3sa2: chipset version = 0x4
opl3sa2: Found OPL3-SA3 (YMF715E or YMF719E)
 at 0x100
 at 0xe84 irq 5 dma 1,3
 at 0x300 irq 5
opl3sa2: Search for a card at 0x904.
opl3sa2: Control I/O port 0x388 is not a YMF7xx chipset!
opl3sa2: There was a problem probing one  of the ISA PNP cards, continuing
opl3sa2: Control I/O port 0x388 is not a YMF7xx chipset!
opl3sa2: There was a problem probing one  of the ISA PNP cards, continuing
opl3sa2: Control I/O port 0x388 is not a YMF7xx chipset!
opl3sa2: There was a problem probing one  of the ISA PNP cards, continuing
YM3812 and OPL-3 driver Copyright (C) by Hannu Savolainen, Rob Hooft 1993-1996

-- 
If voting could change things, it would be illegal.

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

Re: X15 alpha release: as fast as TUX but in user space

[Ingo Molnar]

On Sun, 29 Apr 2001, Fabio Riccardi wrote:

> TUX has definitively been my performance yardstick for the development
> of X15, but I had many sources of inspiration for the X15
> architecture. Maybe the most relevant are the Flash Web Server (Pai,
> Druschel, Zwaenepoel), several Linus observations on this list about
> (web) server architecture and kernnel services, and the reading of the
> Hennessy & Patterson architecture books. [...]

i think Zach's phhttpd is an important milestone as well, it's the first
userspace webserver that shows how to use event-based, sigio-based async
networking IO and sendfile() under Linux. (I believe it had some
performance problems related to sigio queue overflow, these issues might
be solved in the latest kernels.) The zerocopy enhancements should help
phhttpd as well.

Ingo

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

Re: iso9660 endianness cleanup patch

[Martin Dalecki]

"H. Peter Anvin" wrote:
> 
> Hi guys,
> 
> I was looking over the iso9660 code, and noticed that it was doing
> endianness conversion via ad hoc *functions*, not even inlines; nor did
> it take any advantage of the fact that iso9660 is bi-endian (has "all"
> data in both bigendian and littleendian format.)
> 
> The attached patch fixes both.  It is against 2.4.4, but from the looks
> of it it should patch against -ac as well.

Please beware: There is a can of worms you are openning up here, 
since there are many broken CD producer programms out there, which
only provide the little endian data and incorrect big endian
entries. I had some CD's of this form myself. So the endian neutrality
of the iso9660 is only in the theory present...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

pci_fixup_via691_2 - again

[Jacek Popławski]

Will it be possible to disable this fixup in kernel setup? I think, when VIA
MVP3 people will see, that 2.4.x is slower than 2.2.19, they just stay with
2.2.19, and if I understand correctly - 2.2.19 is unsafe like 2.4.4 with that
fixup disabled. I use this chipset for about year, never had any strange
filesystem crash. People who use Linux as a server system should enable any
security fixup, but if I use Linux as a workstation - I need fast video. And I
do backups.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Do You really Want a Job ?

[Imarketing]

+Hello! Do You really Want a Job?+

++---+ 
American program "Imarketing" finds people forHomeWork in their free time!
It's one of the most popular marketing program in   the world and  You can 
work with It now !!! 
All information is on: 
http://www.home.lv/homeworld/
++ 
 
+Sveiki! Vai Jus tiesam Gribat Stradat ?+ 
+--+-+ 
Amerikanu  programa "Imarketing" mekle cilvekusprieks HomeWork vinu brivaja laika! 
Ta ir viena no popularakam marketinga  programam pasaule, un tagad Jus ari varat 
stradat ar to! 
Visa informacija atrodas seit: 
http://www.home.lv/homeworld/
++ 
 
 +Privet! Vi deistvitelno Hotitje Rabotat'?+ 
+--+-+ 
Amerikanskaja programma "Imarketing" ishet ljudeidlja HomeWork v ih zhe svobodnoje 
vremja! 
Eto odna iz samih populjarnih marketingovihprogram v mire i teperj Vi tozhe 
mozhete rabotatj 
v nei!
Vsja informacija nahoditsja zdesj: 
http://www.home.lv/homeworld/
++ 
 

American "Imarketing"
 

P.S.: if You don't need any offerings of job in the future, let us know, please. 
Thank You.
 
---
This message contains no viruses. 
Guaranteed by Kaspersky Anti-Virus.
www.antivirus.lv


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

Broken gcc ?

[Amarendra GODBOLE]

Hello World !

If I recall correctly, RHL 7 shipped with a broken gcc. Has it been 
fixed ? Basically, is it safe to switch to RHL 7 for development 
purposes ? Presently I use RHL 6.2 with 2.2.14 kernel.

Apologies if this is not the proper list for this question, and yes,
thanks in advance.

Peace,
-amar-

-- 
http://www.obscure.org/~amunix/
I have made mistakes but I have never made the mistake of claiming
that I have never made one.
-- James Gordon Bennett



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

RE: Linux NAT questions

[Michel Wilson]

> what I am trying to do is this. I have a genuine network, say 1.1.1.x, and
> my Linux host is on it, as 1.1.1.252 (eth0). I also have a second
> network at
> the back of the Linux box, 192.168.200.x, and a web server on
> that network,
> 192.168.200.2. The Linux address is 192.168.200.1 on eth1.
>
> What I want to do is make the web server appear on the 1.1.1.x network as
> 1.1.1.160. I have done this before with Firewall-1 on NT, by
> putting an arp
> entry for 1.1.1.160 to point to the Linux machine eth0. The packets get
> redirected into the Linux machine, then translated, and then routed out of
> eth1.
>
> The benefit is that there is no routing change to the 1.1.1.x network, and
> the Linux box isn't even seen as a router.
>
> I would appreciate any help with this. Any command to do this?
>
> Chee Tong
This isn't really a kernel question. I think you'd better ask it on some
linux network list/newsgroup. But here's an answer anyway

You could add 1.1.1.160 to eth0:
   ip addr add 1.1.1.160 dev eth0
and then use NAT to redirect these to the webserver:
   iptables -t nat -A PREROUTING -p tcp --dst 1.1.1.160 -i eth1 -j
DNAT --to-destination 192.168.200.2

This should work, AFAIK, but i didn't try it myself. You could also try to
use the arp command (see 'man arp'), but i don't know exactly how that
works.

Good luck!

Michel Wilson.

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

Re: Followup to previous post: Atlon/VIA Instabilities

[Linux Kernel Developer]

>   No, actually the instability starts right after/when the root
> filesystem is mounted (it seems).  I have no foreign modules installed
> when this error occurs.  Even if I did, why would the Abit KA7 with the
> same [other] hardware and software NOT show this problem, even with all
> opts enabled?

In my experience I've noticed motherboards can have a huge impact on
stability despite the chipsets, hardware used, etc.  Abit is well known and
liked in the overclocking circles, consequently I would strongly suspect
that their motherboards are generally highly stable when compared to most
others.  In fact, my experience with them seams to support this thesis.  Its
possible that the other motherboard you were using is just flaky.  Does the
other one happen to be a PC-Chips one?  These generally can be quite cheap,
feature rich, and even have the best chipsets but still have proved
themselves to be quite flaky to me in the past.  FIC seams to have a similar
problem, although they actually improve on their boards stability over time
(have some rock solid high volume servers on "stabilized" FIC boards);
sometimes with just a conveniently available BIOS update.  Shuttle also
seams to have gone downhill but that might have just been a one time
occurrence.

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

Re: bandwidth

[mirabilos]

> What you have todo is to learn how to configure your mailer to display
> headers you want.

Not the displaying annoys me, it's the traffic. The headers usually are
less than multiple quoted sigs, though.

>   elm and balsa can do it. Do not know about
Outlook...
> (btw, it is curious, mailing to lkml with outlook...)

I'm not the only one. I prefer telnet but its cut&paste is broken, so
I can't reply. But OjE shows no extra headers for me, just they go
through
the 31kbps phone line :(

-mirabilos
--
EA F0 FF 00 F0 #$@%CARRIER LOST

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

Re: Unknown HZ value! (2000) Assume 1024.

[Ingo Oeser]

On Wed, May 02, 2001 at 02:42:58AM -0400, Albert D. Cahalan wrote:
> > In .../fs/proc/proc_misc.c:kstat_read_proc(), the cpu line is being
> > computed by:
> > 
> > len = sprintf(page, "cpu  %u %u %u %lu\n", user, nice, system,
> >   jif * smp_num_cpus - (user + nice + system));
> 
> This is pretty bogus. The idle time can run _backwards_ on an SMP
> system. What is "top" supposed to do with that, print a negative
> number for %idle time? (some versions do, while others truncate
> at zero or wrap around to 4 billion -- pick your poison)

Just a "me too". I've seen this with one or two days uptime
already. An idle of more than 40.000%. May be this means, that
the machine was _very_ bored and needs my attention ;-)

cat /proc/cpuinfo

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 6
cpu MHz : 851.987
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat 
pse36 mmx fxsr sse
bogomips: 1697.38

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 6
cpu MHz : 851.987
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat 
pse36 mmx fxsr sse
bogomips: 1697.38

Just FYI.

Regards

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

RE: Linux NAT questions- (kernel upgrade??)

[Sim, CT (Chee Tong)]

Hi.. I follow your instruction, but I encounter this issue, my kernel need
to be upgrade? MAy I know how to determine the current kernel version and
how to upgrade it?? 


[root@guava /root]# iptables -t nat -A PREROUTING -p tcp --dst 1.1.1.160 -i
eth1 -j D
NAT --to-destination 192.168.200.2
iptables v1.1.1: can't initialize iptables table `nat': iptables who? (do
you need to insm
od?)
Perhaps iptables or your kernel needs to be upgraded.


[root@guava simc]# rpm -ivh iptables-1_2_0-6_i386.rpm
error: failed dependencies:
kernel >= 2.4.0 is needed by iptables-1.2.0-6


-Original Message-
From: Michel Wilson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 02, 2001 5:13 PM
To: Sim, CT (Chee Tong)
Cc: [EMAIL PROTECTED]
Subject: RE: Linux NAT questions


> what I am trying to do is this. I have a genuine network, say 1.1.1.x, and
> my Linux host is on it, as 1.1.1.252 (eth0). I also have a second
> network at
> the back of the Linux box, 192.168.200.x, and a web server on
> that network,
> 192.168.200.2. The Linux address is 192.168.200.1 on eth1.
>
> What I want to do is make the web server appear on the 1.1.1.x network as
> 1.1.1.160. I have done this before with Firewall-1 on NT, by
> putting an arp
> entry for 1.1.1.160 to point to the Linux machine eth0. The packets get
> redirected into the Linux machine, then translated, and then routed out of
> eth1.
>
> The benefit is that there is no routing change to the 1.1.1.x network, and
> the Linux box isn't even seen as a router.
>
> I would appreciate any help with this. Any command to do this?
>
> Chee Tong
This isn't really a kernel question. I think you'd better ask it on some
linux network list/newsgroup. But here's an answer anyway

You could add 1.1.1.160 to eth0:
   ip addr add 1.1.1.160 dev eth0
and then use NAT to redirect these to the webserver:
   iptables -t nat -A PREROUTING -p tcp --dst 1.1.1.160 -i eth1 -j
DNAT --to-destination 192.168.200.2

This should work, AFAIK, but i didn't try it myself. You could also try to
use the arp command (see 'man arp'), but i don't know exactly how that
works.

Good luck!

Michel Wilson.


==
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en 
de afzender direct te informeren door het bericht te retourneren. 
==
The information contained in this message may be confidential 
and is intended to be exclusively for the addressee. Should you 
receive this message unintentionally, please do not use the contents 
herein and notify the sender immediately by return e-mail.


==

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

Re: Maximum files per Directory

[Ingo Oeser]

On Tue, May 01, 2001 at 03:03:44PM -0700, H. Peter Anvin wrote:
> > Bit of both. You exceeded the max link count, and your
> > performance would have been abominable too. cyrus should be
> > using heirarchies of directories for very large amounts of
> > stuff.
Right.

> But also showing, once again, that this particular scalability problem
> really is a headache for some people.

If you do ls on that directory as an admin, you'll see, what the
REAL cause of this headache is: 

The application doing such stupid thing!

People (writing applications) building up such large directories
should be forced to read every entry of it aloud. 

Then they'll learn[1] and the problem is solved.

Regards

Ingo Oeser

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

Re: [Patch] deadlock on write in tmpfs

[Stephen C. Tweedie]

hi,

On Tue, May 01, 2001 at 03:39:47PM +0200, Christoph Rohland wrote:
> 
> tmpfs deadlocks when writing into a file from a mapping of the same
> file. 
> 
> So I see two choices: 
> 
> 1) Do not serialise the whole of shmem_getpage_locked but protect
>critical pathes with the spinlock and do retries after sleeps
> 2) Add another semaphore to serialize shmem_getpage_locked and
>shmem_truncate
> 
> I tried some time to get 1) done but the retry logic became way too
> complicated. So the attached patch implements 2)
> 
> I still think it's ugly to add another semaphore, but it works.

If the locking is for a completely different reason, then a different
semaphore is quite appropriate.  In this case you're trying to lock
the shm internal info structures, which is quite different from the
sort of inode locking which the VFS tries to do itself, so the new
semaphore appears quite clean --- and definitely needed.

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

Re: 2.4 and 2GB swap partition limit

[Stephen C. Tweedie]

Hi,

On Tue, May 01, 2001 at 06:14:54PM +0200, Rogier Wolff wrote:

> Shouldn't the algorithm be: 
> 
> - If (current_access == write )
>   free (swap_page);
>   else
>   map (page, READONLY)
> 
> and 
>   when a write access happens, we fault again, and map free the 
>   swap-page as it is now dirty anyway. 

That's what 2.2 did.  2.4 doesn't have to. 

The trouble is, you really want contiguous virtual memory to remain
contiguous on swap.  Freeing individual pages like this on fault can
cause a great deal of fragmentation in swap.  We'd far rather keep the
swap page reserved for future use by the same page so that the VM
region remains contiguous on disk.

That's fine as far as it goes, but the problem happens if you _never_
free up such pages.  We should reap the unused swap page if we run out
of swap.  We don't, and _that_ is the problem --- not the fact that
the page is left allocated in the first place, but the fact that we
don't do anything about it once we are short on disk.

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

Re: Disk Performance Measurements

[Jens Axboe]

On Wed, May 02 2001, Shaun wrote:
> In regards to diskr/wblk, drive_stat_acct() increments the number of
> sectors/blocks read based n the values in the request being processed by
> add_request(). But add_request() is only called for requests that can't be
> merged with requests currently on the queue. Thus the counters can't be
> updated for sectors that are read by being added to aqueued
> request. Unless I'm mistaken this makes the diskr/wblk mostly useless.

Look again, drive_stat_acct is also called for list merges (just with 0
set for new i/o of course).


> record the _kilobytes_ read or written to the disks. His code adds
> drive_pg_stat_acct(). This routine increments disk_pgin/out once for each
> call to make_request(). Presumably he has assumed every call to
> make_request will always be for 2 sectors/1 Kilobytes worth of
> data. However I added printk() statements to try to verify this and found
> that the request to the block device need not be 1024 bytes, I frequently
> saw 4096 requests. In fact, the "correct_size" for the block device
> appeared to be changeable from partition to partition on the same
> disk. This "correct_size" appears to be related to the block size for the
> filesystem on the partition/disk? Following from the above logic it would
> appear that the pgin/pgout statistics are also useless since you don't
> know how large the requests were?

The size of requests will typically vary with the block size set by
ext2. So if you have 1kB block size on your fs, that partition will
receive 1kB buffers. Similar for 4kB. The stats collected in the kernel
are sector based, units of 512 bytes. The proc printed value should be
in kB however for pgpin/out and 512b sectors for rio/rblk wio/wblk.

-- 
Jens Axboe

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

Weird HWaddr with rtl 8139too since 8129 merge?

[Tim Krieglstein]

Hi 

I just compiled the 2.4.4 release with gcc version 2.95.3 20010315 (Debian release).
After starting up both realtek 8139 network cards (ok they where cheap) won't work.
The source of the problem seems to be the hwaddr of the cards (ifconfig output):
eth0  Link encap:Ethernet  HWaddr FF:FF:FF:FF:FF:FF  
  inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:4294967293 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100 
  RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
  Interrupt:11 Base address:0xe000 

eth1  Link encap:Ethernet  HWaddr FF:FF:FF:FF:FF:FF  
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:4294967293 overruns:0 frame:0
  TX packets:0 errors:0 dropped:4 overruns:0 carrier:0
  collisions:0 txqueuelen:100 
  RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
  Interrupt:11 Base address:0xe800 
When booting 2.4.2-ac20 both cards work fine. I looked a bit into the source of the 
driver, but
there where tons of changes obviusly because of the merge of the 8129 Support, so i 
didn't look
into this further.

I'll append lspci to give an overview of installed hardware.

Thanks for any help
Tim
-- 
It's a damn poor mind that can only think of one way to spell a word. - Andrew Jackson


00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 
20)
00:08.0 SCSI storage controller: Adaptec AIC-7861 (rev 01)
00:09.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 11)
00:09.1 Multimedia controller: Brooktree Corporation Bt878 (rev 11)
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
00:0c.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
01:00.0 VGA compatible controller: nVidia Corporation GeForce 256 DDR (rev 10)

Re: 2.4 and 2GB swap partition limit

[Rogier Wolff]

Stephen C. Tweedie wrote:
> Hi,
> 
> On Tue, May 01, 2001 at 06:14:54PM +0200, Rogier Wolff wrote:
> 
> > Shouldn't the algorithm be: 
> > 
> > - If (current_access == write )
> > free (swap_page);
> >   else
> > map (page, READONLY)
> > 
> > and 
> >   when a write access happens, we fault again, and map free the 
> >   swap-page as it is now dirty anyway. 
> 
> That's what 2.2 did.  2.4 doesn't have to. 
> 
> The trouble is, you really want contiguous virtual memory to remain
> contiguous on swap.  Freeing individual pages like this on fault can
> cause a great deal of fragmentation in swap.  We'd far rather keep the
> swap page reserved for future use by the same page so that the VM
> region remains contiguous on disk.
> 
> That's fine as far as it goes, but the problem happens if you _never_
> free up such pages.  We should reap the unused swap page if we run out
> of swap.  We don't, and _that_ is the problem --- not the fact that
> the page is left allocated in the first place, but the fact that we
> don't do anything about it once we are short on disk.

first: Thanks for clearing this up for me. 

So, there are in fact some more "states" a swap-page can be in:

-(0) free
-(1) allocated, not in mem. 
-(2) on swap, valid copy of memory. 
-(3) on swap: invalid copy, allocated for fragmentation, can 
be freed on demand if we are close to running out of swap.

If we running low on (0) swap-pages we can first start to reap the (3)
pages, and if that runs out, we can start reaping the (2)
pages. Right?


Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: X15 alpha release: as fast as TUX but in user space (fwd)

[Andi Kleen]

[sorry for the late answer -- i was involuntarily offline for a few days]

On Sat, Apr 28, 2001 at 04:56:27PM -0600, Richard Gooch wrote:
> Whatever happened to that hack that was discussed a year or two ago?
> The one where (also on IA32) a magic page was set up by the kernel
> containing code for fast system calls, and the kernel would write
> calibation information to that magic page. The code written there
> would use the TSC in conjunction with that calibration data.
> 
> There was much discussion about this idea, even Linus was keen on
> it. But IIRC, nothing ever happened.

It's already implemented in the x86-64 port, thanks to Andrea
Arcangelli.

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

Re: X15 alpha release: as fast as TUX but in user space (fwd)

[Ingo Molnar]

On Wed, 2 May 2001, Andi Kleen wrote:

> > Whatever happened to that hack that was discussed a year or two ago?
> > The one where (also on IA32) a magic page was set up by the kernel
> > containing code for fast system calls, and the kernel would write
> > calibation information to that magic page. The code written there
> > would use the TSC in conjunction with that calibration data.
> >
> > There was much discussion about this idea, even Linus was keen on
> > it. But IIRC, nothing ever happened.
>
> It's already implemented in the x86-64 port, thanks to Andrea
> Arcangelli.

well, it was first prototyped in the vsyscall patches :-)

Ingo

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

NFS-performance drop with 2.4.4 and 8139too

[Hendrik Volker Brunn]

When upgrading from kernel 2.4.3 to 2.4.4 my 
NFS-performance drops badly.

NFS-server:

knfsd, linux-2.4.4, 8139too-0.9.16


NFS-client:

linux-2.4.4, 8139too-0.9.16

transfers seem to start with about 2 MB/s but drop 
immediatly to about 20 K/s.

http, ssh - performance is as usual.

When switching the client back to linux-2.4.3 with 
8139too-0.9.15c nfs performs with about 6 MB/s which 
is fine with me.

Please tell me if I can provide any further helpful information.

Hendrik


PCI devices found:
  Bus  0, device   0, function  0:
Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 2).
  Master Capable.  Latency=64.  
  Prefetchable 32 bit memory at 0xe000 [0xe3ff].
  Bus  0, device   1, function  0:
PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 2).
  Master Capable.  Latency=64.  Min Gnt=128.
  Bus  0, device   7, function  0:
ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2).
  Bus  0, device   7, function  1:
IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1).
  Master Capable.  Latency=64.  
  I/O at 0xf000 [0xf00f].
  Bus  0, device   7, function  2:
USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1).
  Master Capable.  Latency=64.  
  I/O at 0xe000 [0xe01f].
  Bus  0, device   7, function  3:
Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2).
  IRQ 9.
  Bus  0, device   8, function  0:
VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] (rev 0).
  IRQ 16.
  Master Capable.  Latency=64.  
  Prefetchable 32 bit memory at 0xe400 [0xe4ff].
  Non-prefetchable 32 bit memory at 0xe500 [0xe5003fff].
  Non-prefetchable 32 bit memory at 0xe600 [0xe67f].
  Bus  0, device   9, function  0:
SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 3).
  IRQ 17.
  Master Capable.  Latency=64.  Min Gnt=17.Max Lat=64.
  I/O at 0xe400 [0xe4ff].
  Non-prefetchable 32 bit memory at 0xe9001000 [0xe90010ff].
  Non-prefetchable 32 bit memory at 0xe900 [0xe9000fff].
  Bus  0, device  10, function  0:
Multimedia video controller: Brooktree Corporation Bt878 (rev 2).
  IRQ 18.
  Master Capable.  Latency=64.  Min Gnt=16.Max Lat=40.
  Prefetchable 32 bit memory at 0xe9002000 [0xe9002fff].
  Bus  0, device  10, function  1:
Multimedia controller: Brooktree Corporation Bt878 (rev 2).
  IRQ 18.
  Master Capable.  Latency=64.  Min Gnt=4.Max Lat=255.
  Prefetchable 32 bit memory at 0xe9003000 [0xe9003fff].
  Bus  0, device  11, function  0:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 16).
  IRQ 19.
  Master Capable.  Latency=64.  Min Gnt=32.Max Lat=64.
  I/O at 0xe800 [0xe8ff].
  Non-prefetchable 32 bit memory at 0xe9004000 [0xe90040ff].
  Bus  0, device  12, function  0:
SCSI storage controller: Advanced Micro Devices [AMD] 53c974 [PCscsi] (rev 16).
  IRQ 16.
  Master Capable.  Latency=64.  Min Gnt=4.Max Lat=40.
  I/O at 0xec00 [0xec7f].


If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux jupiter 2.4.3 #1 SMP Wed May 2 11:42:51 CEST 2001 i686 unknown
 
Gnu C  2.95.3
Gnu make   3.79.1
binutils   2.10.1
util-linux 2.10r
mount  2.10r
modutils   2.4.5
e2fsprogs  1.19
reiserfsprogs  3.x.0j
Dynamic linker (ldd)   2.2.2
Procps 2.0.7
Console-tools  0.2.3
Sh-utils   2.0.11
Modules Loaded 


#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
# CONFIG_MODULES is not set

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_HAVE_DEC_LOCK=y

#
# General setup
#
CONFIG_

Re: 2.4 and 2GB swap partition limit

[Stephen C. Tweedie]

Hi,

On Wed, May 02, 2001 at 12:54:15PM +0200, Rogier Wolff wrote:
> 
> first: Thanks for clearing this up for me. 
> 
> So, there are in fact some more "states" a swap-page can be in:
> 
>   -(0) free
>   -(1) allocated, not in mem. 
>   -(2) on swap, valid copy of memory. 
>   -(3) on swap: invalid copy, allocated for fragmentation, can 
>   be freed on demand if we are close to running out of swap.
> 
> If we running low on (0) swap-pages we can first start to reap the (3)
> pages, and if that runs out, we can start reaping the (2)
> pages. Right?

Yes.  However, there is other state to worry about too.  Anonymous
pages are referenced from process page tables.  As long as the page
tables are referring to the copy in memory, you can free up the copy
on disk.  However, if any ptes point to the copy on disk, you cannot
(and remember, process forks can result in multiple process mm's
pointing to the same anonymous page, and some of those mm's may point
to swap while others point to the in-core page).

So the aim is more complex.  Basically, once we are short on VM, we
want to eliminate redundant copies of swap data.  That implies two
possible actions, not one --- we can either remove the swap page for
data which is already in memory, or we can remove the in-memory copy
of data which is already on swap.  Which one is appropriate will
depend on whether the ptes in the system point to the swap entry or
the memory entry.  If we have ptes pointing to both, then we cannot
free either.

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

RE: Linux NAT questions- (kernel upgrade??)

[Michel Wilson]

> Hi.. I follow your instruction, but I encounter this issue, my kernel need
> to be upgrade? MAy I know how to determine the current kernel version and
> how to upgrade it??

You can see the current kernel version by doing uname -a. It is also shown
at boot time.

>
>
> [root@guava /root]# iptables -t nat -A PREROUTING -p tcp --dst
> 1.1.1.160 -i
> eth1 -j D
> NAT --to-destination 192.168.200.2
> iptables v1.1.1: can't initialize iptables table `nat': iptables who? (do
> you need to insm
> od?)
> Perhaps iptables or your kernel needs to be upgraded.
>
>
> [root@guava simc]# rpm -ivh iptables-1_2_0-6_i386.rpm
> error: failed dependencies:
> kernel >= 2.4.0 is needed by iptables-1.2.0-6
For iptables you'll need kernel >= 2.4.0, as stated. I don't know if RedHat
has a precompiled rpm somewhere (i don't use RedHat) but i would think so.
You might ask your local RedHat guru ;-).
Other options are:
- build your own 2.4.x (see Kernel-HOWTO, if it's not too outdated)
- use ipchains.

I don't know ipchains enough to tell you how to do it, i don't even know if
it's possible But
http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO-6.html#ss6.8 may be of
interest to you.

Greetings,

Michel Wilson.

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

Re: Followup to previous post: Atlon/VIA Instabilities

[Tom Leete]

Seth Goldberg wrote:
> 
> Hi,
> 
>   So it seems that CONFIG_X86_USE_3DNOW is simply used to
> enable access to the routines in mmx.c (the athlon-optimized
> routines on CONFIG_K7 kernels), so then it appears that somehow
> this is corrupting memory / not behaving as it should (very
> technical, right?) :)...
> 
>  --Seth

This is a shot in the dark. Do you have floating-point emulation on
(CONFIG_MATH_EMULATION=y)?

Tom

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

[PATCH] kernel locking guide fix.

[Rusty Russell]

diff -urN -I \$.*\$ -X /tmp/kerndiff.hKrYxB --minimal 
linux-2.4.4-official/Documentation/DocBook/kernel-locking.tmpl 
working-2.4.4-rcu/Documentation/DocBook/kernel-locking.tmpl
--- linux-2.4.4-official/Documentation/DocBook/kernel-locking.tmpl  Tue May  1 
12:26:15 2001
+++ working-2.4.4-rcu/Documentation/DocBook/kernel-locking.tmpl Wed May  2 21:14:19 
+2001
@@ -760,8 +760,11 @@
 
 
 
-  Any atomic operation is defined to act as a memory barrier
-  (ie. as per the mb() macro).  Also,
+  Some atomic operations are defined to act as a memory barrier
+  (ie. as per the mb() macro, but if in
+  doubt, be explicit.
+  
+  Also,
   spinlock operations act as partial barriers: operations after
   gaining a spinlock will never be moved to precede the
   spin_lock() call, and operations before

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

Re: reason for VIA performance drop since 2.4.2-ac21

[Alan Cox]

> It has nothing to do with mtrr or K6.  In file arch/i386/kernel/pci-pc.c there
> is a pci_fixup_via691_2 function.  It appeared in 2.4.2-ac21. And it works for
> my chipset - VIA_82C598. When I put "return" in body of this function,
> recompile and start kernel 2.4.4 - "x11perf -putimage100" shows that video
> works fast again.

My log says that this was a change pulled in from Linus tree. I don't know who
put it there or why

> 1) this is just a debug code, and kernels >2.4.2-ac20 shouldn't be used by VIA
> MVP3 owners
> 2) this code fix crash possibility, and all kernels without it (including
> 2.2.19) are buggy with VIA MVP3

Im not aware of any write posting bugs on the MVP3 but I dont follow the
chipset in detail.


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

Re: Question on including 'math.h' from C runtime...

[Alan Cox]

> '/usr/include/math.h' in most cases. There are only two places
> in the kernel that also include this header file. They are:
> 
>drivers/atm/iphase.c

That probably shouldnt be using it

>drivers/net/hamradio/soundmodem/gentbl.c

This one is intentional. gentbl is a program linked in user space and used
to generate a .h file then built for the kernel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Alan Cox]

> > why resort to silly windows tools, when lspci under Linux does it for you?
> 
>   Because lspci does not display all 256 bytes of pci configuration
> information.

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

Re: ioctl call for network device

[sébastien person]

Le Wed, 2 May 2001 13:55:34 +0200 
Ofer Fryman <[EMAIL PROTECTED]> à écrit :

> The definition of ioctl is "extern int __ioctl __P ((int __fd, unsigned long
> int __request, ...));" on Linux 2.0.x, and I believe it is also on any other
> Linux version.

yes but I use an network device specific ioctl call wich perform interface-specific
ioctl commands.
the prototype of the ioctl reception in the module is (as described in rubini book,
O reilly, linux device drivers):

int (*do_ioctl) (struct device *dev, struct ifreq *ifr, int cmd);

so can I pass over the limitations of the definition ?
I do ioctl that use private ioctl flags (e.g. SIOCDEVPRIVATE)

> So If you can pass what ever pointer or number you want instead of struct
> ifreq, If you use Linux under 2.2.x you will need to use copy_fromfs to get
> the buffer info, otherwise you can access it directly from the kernel mode
> with the restriction of interrupt handlers and bottom-halfs. 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2001 10:08 AM
> To: liste noyau linux
> Subject: ioctl call for network device
> 
> 
> Hi,
> 
> I've succeed to do an ioctl call and recept it in my module
> 
> ioctl(file_descriptor, cmd, struct ifreq)
> 
> but I believe that I'm oblige to use the struct ifreq and I can't
> pass any other arguments because an user can't acces kernel space
> so the ioctl call recopy data in the kernel space (this is what I've
> understood, maybe I'm wrong ...).
> 
> My problem is that I need to pass some int arguments (the best way was an
> int* ) but the struct ifreq doesn't permit me it, so could I add other
> arguments as we can do in an normal ioctl call ?
> 
> I hope this is the wrong place for this question.
> 
> sebastien person
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: (follow-up) 2.4.4, ac1,ac2,ac3 - panics on ICMPv6 packets

[Alan Cox]

>  2.4.4, ac1, ac2 AND now ac3 will panic on receiving ICMPv6 packets (like 
>traceroute6 and ping6)
>  See my earlier messages for panic info.

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

Re: 2.4.3-ac9/4 - NFS corruption

[Trond Myklebust]

> " " == Raphael Manfredi <[EMAIL PROTECTED]> writes:

 > Yes, mail is delivered on the server by mailagent, so with
 > proper local locking.

That's not good enough. The NFS client needs to know when it is in
sync with the server...

 > :If so it's completely normal behaviour: the userland NFS
 > doesn't :support file locking, so there's no way that the
 > client can guarantee :that some task on the server won't write
 > to the file behind its :back...

 > Does kernel-land NFS support file locking?

Yes. See the NFS-HOWTO for details.

 > In any case, "mutt" does not lock the file, so yes, I'm
 > perfectly aware there could be a race.  But not the kind of
 > race that would NULL-ify 5 bytes on the file when read from the
 > client, whilst those same bytes are perfectly normal when read
 > from the server.

That can easily happen if the client thinks that the file is longer
than it is on the server. A client has to rely on its cached value of
the file length in order to append to a file, since it has to specify
an offset at which to write. If that offset exceeds the current file
length, the server does the equivalent of a truncate() to extend the
file.

See RFC1094 and RFC1813 for further details on how NFS implements
reading and writing...

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

Re: PROBLEM: 2.4.4{ac2} will not boot

[Alan Cox]

> threads that are indicating the same problem, is there still usefulness
> in trying to capture an oops from 2.4.4? Bit odd that 2.4.4ac2 just
> blackens my screen, isn't it?

Capturing the 2.4.4 oops is useful

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

Re: 2.4.4, 2.4.4-ac1 and -ac3: oops loading future domain scsi module

[Alan Cox]

> shpnt->io_port = port_base;
> +  if(pdev!=NULL)
> scsi_set_pci_device(shpnt->pci_dev, pdev);
> shpnt->n_io_port = 0x10;
> print_banner( shpnt );
> 
> I hope this is the right way...

I suspect it should be

if(shpnt->pci_dev)

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

Re: Maximum files per Directory

[Ketil Froyn]

On Tue, 1 May 2001, Alan Cox wrote:

> > cyrus-imapd i ran into problems.
> > At about 2^15 files the filesystem gave up, telling me that there cannot be
> > more files in a directory.
> >
> > Is this a vfs-Issue or an ext2-issue?
>
> Bit of both. You exceeded the max link count, and your performance would have
> been abominable too. cyrus should be using heirarchies of directories for
> very large amounts of stuff.

That's not always best, is it? I've been testing a bit with reiserfs, and
with LOTS of files, I lose performance with a lot of directories compared
to putting all the files in one directory.

Of course, that is only read-performance. Write performance is enhanced
(at least when creating new files) by splitting this into some more
directories. So how you want to split this up depends whether your data is
write-many-read-once or write-once-read-many or something in between. That
is my experience with reiserfs, anyway.

Ketil

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

Re: Patch: softdog and WDIOS_DISABLECARD

[Alan Cox]

> I have found a potential problem with the current
> implementation of the software watchdog.  I have
> CONFIG_WATCHDOG_NOWAYOUT set for a reliable watchdog. 
> However, there are instances where I want to explicitly
> shut it down.  The problem with disabling

It is intentional you cannot shut it down. The whole point of that mode
of operation is that you can make definitive statements about your watchdogs.

You can swap the watchdog process with any simple program that keeps it ticking
while you do other work, then swap back.

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

Re: ioctl call for network device

[Alan Cox]

> but I believe that I'm oblige to use the struct ifreq and I can't
> pass any other arguments because an user can't acces kernel space
> so the ioctl call recopy data in the kernel space (this is what I've
> understood, maybe I'm wrong ...).

You can either pass your own data inside of ifr_data[] or you can pass
a pointer in ifr_data and do the copy to/from user space yourself
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Broken gcc ?

[Alan Cox]

> If I recall correctly, RHL 7 shipped with a broken gcc. Has it been 
> fixed ? Basically, is it safe to switch to RHL 7 for development 
> purposes ? Presently I use RHL 6.2 with 2.2.14 kernel.

I do all my kernel development with gcc 2.96-69 and 2.96-81 (the errata
7.0 and the 7.1 gcc).

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

Re: NFS-performance drop with 2.4.4 and 8139too

[Kurt Garloff]

Hi,

did you already try the patch that Andrew Morton sent in the 
"New rtl8139 driver prevents ssh from exiting." thread?

On Wed, May 02, 2001 at 11:54:58AM +0200, Hendrik Volker Brunn wrote:
> When upgrading from kernel 2.4.3 to 2.4.4 my 
> NFS-performance drops badly.

> knfsd, linux-2.4.4, 8139too-0.9.16
> linux-2.4.4, 8139too-0.9.16
> 
> transfers seem to start with about 2 MB/s but drop 
> immediatly to about 20 K/s.

PS: If you send your .config, pipe it via grep -v "^#"

Regards,
-- 
Kurt Garloff  <[EMAIL PROTECTED]>  Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG   SCSI, Security

 PGP signature

Re: [Patch] deadlock on write in tmpfs

[Christoph Rohland]

Hi Stephen,

On Tue, 1 May 2001, Stephen C. Tweedie wrote:
> If the locking is for a completely different reason, then a
> different semaphore is quite appropriate.  In this case you're
> trying to lock the shm internal info structures, which is quite
> different from the sort of inode locking which the VFS tries to do
> itself, so the new semaphore appears quite clean --- and definitely
> needed.

It's not the addition to the inode semaphore I do care about, but the
addition to the spin lock which protects also the shmem internals. But
you are probably right: It only protects the onthefly pages between
page cache and swap cache.

Greetings
Christoph


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

RE: Linux NAT questions- (kernel upgrade??)

[Feng Xian]

i think iptables is a new feature in kernel 2.4.x(and you have to build
it in the kernel or as module). you can use ipchains if
you are running kernel with lower version, 2.2.something.

Alex

On Wed, 2 May 2001, Sim, CT (Chee Tong) wrote:

> Hi.. I follow your instruction, but I encounter this issue, my kernel need
> to be upgrade? MAy I know how to determine the current kernel version and
> how to upgrade it??
>
>
> [root@guava /root]# iptables -t nat -A PREROUTING -p tcp --dst 1.1.1.160 -i
> eth1 -j D
> NAT --to-destination 192.168.200.2
> iptables v1.1.1: can't initialize iptables table `nat': iptables who? (do
> you need to insm
> od?)
> Perhaps iptables or your kernel needs to be upgraded.
>
>
> [root@guava simc]# rpm -ivh iptables-1_2_0-6_i386.rpm
> error: failed dependencies:
> kernel >= 2.4.0 is needed by iptables-1.2.0-6
>
>
> -Original Message-
> From: Michel Wilson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2001 5:13 PM
> To: Sim, CT (Chee Tong)
> Cc: [EMAIL PROTECTED]
> Subject: RE: Linux NAT questions
>
>
> > what I am trying to do is this. I have a genuine network, say 1.1.1.x, and
> > my Linux host is on it, as 1.1.1.252 (eth0). I also have a second
> > network at
> > the back of the Linux box, 192.168.200.x, and a web server on
> > that network,
> > 192.168.200.2. The Linux address is 192.168.200.1 on eth1.
> >
> > What I want to do is make the web server appear on the 1.1.1.x network as
> > 1.1.1.160. I have done this before with Firewall-1 on NT, by
> > putting an arp
> > entry for 1.1.1.160 to point to the Linux machine eth0. The packets get
> > redirected into the Linux machine, then translated, and then routed out of
> > eth1.
> >
> > The benefit is that there is no routing change to the 1.1.1.x network, and
> > the Linux box isn't even seen as a router.
> >
> > I would appreciate any help with this. Any command to do this?
> >
> > Chee Tong
> This isn't really a kernel question. I think you'd better ask it on some
> linux network list/newsgroup. But here's an answer anyway
>
> You could add 1.1.1.160 to eth0:
>ip addr add 1.1.1.160 dev eth0
> and then use NAT to redirect these to the webserver:
>iptables -t nat -A PREROUTING -p tcp --dst 1.1.1.160 -i eth1 -j
> DNAT --to-destination 192.168.200.2
>
> This should work, AFAIK, but i didn't try it myself. You could also try to
> use the arp command (see 'man arp'), but i don't know exactly how that
> works.
>
> Good luck!
>
> Michel Wilson.
>
>
> ==
> De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
> is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
> onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en
> de afzender direct te informeren door het bericht te retourneren.
> ==
> The information contained in this message may be confidential
> and is intended to be exclusively for the addressee. Should you
> receive this message unintentionally, please do not use the contents
> herein and notify the sender immediately by return e-mail.
>
>
> ==
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
Feng Xian
   _o) .~.  (o_
   /\\ /V\  //\
  _\_V// \\ V_/_
 /(   )\
  ^^-^^
   ALEX

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

RE: 2.4.4, 2.4.4-ac1 and -ac3: oops loading future domain scsi module

[Matt_Domsch]

> > +if(pdev!=NULL)
> > scsi_set_pci_device(shpnt->pci_dev, pdev);
>
> I suspect it should be
> 
>   if(shpnt->pci_dev)
> 
> but the effect is identical


That one's mine.  It should be:
   scsi_set_pci_device(shpnt, pdev);

There's no reason to check if pdev != NULL first, as it's NULL in the
structure beforehand, and NULL afterward.

I'll fix and submit a patch, and make sure I didn't make the same mistake
elsewhere too.

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

Re: ioctl call for network device

[Richard B. Johnson]

On Wed, 2 May 2001, [ISO-8859-1] sébastien person wrote:

> Le Wed, 2 May 2001 13:55:34 +0200 
> Ofer Fryman <[EMAIL PROTECTED]> à écrit :
> 
> > The definition of ioctl is "extern int __ioctl __P ((int __fd, unsigned long
> > int __request, ...));" on Linux 2.0.x, and I believe it is also on any other
> > Linux version.
> 
> yes but I use an network device specific ioctl call wich perform interface-specific
> ioctl commands.
> the prototype of the ioctl reception in the module is (as described in rubini book,
> O reilly, linux device drivers):
> 
> int (*do_ioctl) (struct device *dev, struct ifreq *ifr, int cmd);
> 
> so can I pass over the limitations of the definition ?
> I do ioctl that use private ioctl flags (e.g. SIOCDEVPRIVATE)
> 

struct ifreq has a member called ifr_data. It is a pointer. You can
put a pointer to any of your data, including the most complex structure
you might envision, in that area. This allows you to pass anything
to and from your module. This pointer can be properly dereferenced
in kernel space but you should use copy_to/from_user and friends so a
user-space coding bug won't panic the kernel.

Also, the value of the commands that you want to use for the ioctl() can
(probably should), start at SIOCDEVPRIVATE.

In other words, given the commands DEV_START, DEV_STOP, DEV_DESTROY,
they should be defined as:

#define DEV_START   SIOCDEVPRIVATE
#define DEV_STOPSIOCDEVPRIVATE + 1
#define DEV_DESTROY SIOCDEVPRIVATE + 2

Given a user-space aggregate of type FOO, to be accessed by the
module, it would be coded as:

FOO foo;
struct ifreq ifr;

strcpy(ifr.ifr_name, "eth0");
ifr.ifr_data = (char *) &foo;
ioctl(sock, DEV_DESTROY, &ifr);

So, as you can see, there are no limitations of the definition.
In fact, it's a really well designed interface.

Cheers,
Dick Johnson

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

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


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

Re: Linux NAT questions- (kernel upgrade??)

[Russell King]

On Wed, May 02, 2001 at 08:22:54AM -0400, Feng Xian wrote:
> i think iptables is a new feature in kernel 2.4.x(and you have to build
> it in the kernel or as module). you can use ipchains if
> you are running kernel with lower version, 2.2.something.

I think you'll find that 2.4 is compatible with ipchains, as long as
you load the relevent module/configure the kernel right.

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

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

RE: 2.4.4, 2.4.4-ac1 and -ac3: oops loading future domain scsi mo dule

[Matt_Domsch]

> That one's mine.  It should be:
>scsi_set_pci_device(shpnt, pdev);

Can you please try this patch and see if it works for you?

diff -burN linux-2.4.4/drivers/scsi/fdomain.c linux/drivers/scsi/fdomain.c
--- linux-2.4.4/drivers/scsi/fdomain.c  Fri Apr 27 15:59:18 2001
+++ linux/drivers/scsi/fdomain.cWed May  2 07:27:32 2001
@@ -971,7 +971,7 @@
return 0;
shpnt->irq = interrupt_level;
shpnt->io_port = port_base;
-   scsi_set_pci_device(shpnt->pci_dev, pdev);
+   scsi_set_pci_device(shpnt, pdev);
shpnt->n_io_port = 0x10;
print_banner( shpnt );




Thanks,
Matt

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

Re: Linux NAT questions- (kernel upgrade??)

[Vivek Dasmohapatra]

On Wed, 2 May 2001, Russell King wrote:

> On Wed, May 02, 2001 at 08:22:54AM -0400, Feng Xian wrote:
> > i think iptables is a new feature in kernel 2.4.x(and you have to build
> > it in the kernel or as module). you can use ipchains if
> > you are running kernel with lower version, 2.2.something.
> 
> I think you'll find that 2.4 is compatible with ipchains, as long as
> you load the relevent module/configure the kernel right.

Which doesn't appear to be the problem, as the guy seems to be running 2.2
or at least 2.4 w/o iptables.

-- 
"Aren't you ashamed of yourself?"
"No, I have people to do that for me."

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

Compiling kernel

[alad]

Hi,
 The question may sound very stupid... But I have following doubt.

suppose I am making some change in sched.c and now I want to build my kernel
that reflects the change..
Is there any way I can avoid answering all the questions when I do make zImage ?

In short how should I compile the kernel (in very small time) to see my changes.

Thanks (for not flaming me)
Amol


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

Re: 2.4 and 2GB swap partition limit

[Hugh Dickins]

On Wed, 2 May 2001, Stephen C. Tweedie wrote:
> 
> So the aim is more complex.  Basically, once we are short on VM, we
> want to eliminate redundant copies of swap data.  That implies two
> possible actions, not one --- we can either remove the swap page for
> data which is already in memory, or we can remove the in-memory copy
> of data which is already on swap.  Which one is appropriate will
> depend on whether the ptes in the system point to the swap entry or
> the memory entry.  If we have ptes pointing to both, then we cannot
> free either.

Sorry for stating the obvious, but that last sentence gives up too easily.
If we have ptes pointing to both, then we cannot free either until we have
replaced all the references to one by references to the other.

Hugh

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

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Moses McKnight]

Mark Hahn wrote:

>>  Actually, I think there are 2 problems that have been discussed -- the
>>disk corruption and a general instability resulting in oops'es at
>>various points shortly after boot up.
>>
> 
> I don't see this.  specifically, there were scattered reports
> of a via-ide problem a few months ago; this is the issue that's 
> gotten some press, and for which Alan has a fix.  and there are reports 
> of via-smp problems at boot (which go away with noapic).  I see no reports 
> of the kind of general instability you're talking about.  and all the 
> via-users I've heard of have no such stability problems - 
> me included (kt133/duron).
> 
> the only general issue is that kx133 systems seem to be difficult
> to configure for stability.  ugly things like tweaking Vio.
> there's no implication that has anything to do with Linux, though.


When I reported my problem a couple weeks back another fellow
said he and several others on the list had the same problem,
and as far as I can tell it is *only* with the IWILL boards.
When I compiled with k7 optimizations I'd get all kinds of oopses
and panics and never fully boot.  They were different every time.
When any of the lesser optimizations are used I have no problems.
My memory is one 256MB Corsair PC150 dimm, CPU is a Thunderbird 850,
and mobo is an IWILL KK266 (KT133A).  The CPU runs between 35°C
and 40°C.


>>  My memory system jas been set up very conservitavely and has been
>>rock solid in my other board (ka7), so I doubt it's that, but I
>>sure am happy to try a few more cominations of bios settings.  Anything
>>I should look for in particular?
>>
> 
> how many dimms do you have?  interleave settings?  Vio jumper?
> already checked on cooling issues?  and that you're not overclocking...


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

Re: 2.4.4, 2.4.4-ac1 and -ac3: oops loading future domain scsi module

[martin]

On Wed, May 02, 2001 at 09:03:59AM +0200, Carlo E. Prelz wrote:

>   Subject: 2.4.4, 2.4.4-ac1 and -ac3: oops loading future domain scsi module
>   Date: Wed, May 02, 2001 at 08:30:18AM +0200
> 
> Quoting Carlo E. Prelz ([EMAIL PROTECTED]):
> 
> > Here I am with another, fresh oops that I encountered while exploring
> > new kernels. This time, the oops is generated when trying to load the
> > module for a very old (1993) Future Domain SCSI card. 2.4.3-ac7 was my
> > previous kernel and worked perfectly. 
> 
> I made some more research. Eventually, it seems the problem is in this
> patch that was included in 2.4.4:
> 
> @@ -969,6 +971,7 @@
> return 0;
> shpnt->irq = interrupt_level;
> shpnt->io_port = port_base;
> +   scsi_set_pci_device(shpnt->pci_dev, pdev);
> shpnt->n_io_port = 0x10;
> print_banner( shpnt );
> 
> Well, but my card is ISA! It should not set any PCI device. 
> 
> I applied the following patch, and the problem disappeared:
> 
> --- fdomain.c~Wed May  2 07:08:27 2001
> +++ fdomain.c Wed May  2 08:58:03 2001
> @@ -971,6 +971,7 @@
>   return 0;
> shpnt->irq = interrupt_level;
> shpnt->io_port = port_base;
> +  if(pdev!=NULL)
> scsi_set_pci_device(shpnt->pci_dev, pdev);
> shpnt->n_io_port = 0x10;
> print_banner( shpnt );
> 
> I hope this is the right way...

Well I got the same oops with a PCI card...
After some research I found that the first argument to the inline
function scsi_set_pci_device is supposed to be a pointer to a
struct Scsi_Host.
The patch below should work for both ISA and PCI.

Regards
/Martin


--- fdomain.c.orig  Wed May  2 13:33:09 2001
+++ fdomain.c   Wed May  2 14:04:45 2001
@@ -971,7 +971,7 @@
return 0;
shpnt->irq = interrupt_level;
shpnt->io_port = port_base;
-   scsi_set_pci_device(shpnt->pci_dev, pdev);
+   scsi_set_pci_device(shpnt, pdev);
shpnt->n_io_port = 0x10;
print_banner( shpnt );
 


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

Re: 2.4.4, 2.4.4-ac1 and -ac3: oops loading future domain scsi mo dule

[Carlo E. Prelz]

Subject: RE: 2.4.4, 2.4.4-ac1 and -ac3: oops loading future domain scsi mo dule
Date: Wed, May 02, 2001 at 07:40:50AM -0500

Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):

> > That one's mine.  It should be:
> >scsi_set_pci_device(shpnt, pdev);
> 
> Can you please try this patch and see if it works for you?

Yesss...

scsi1:  BIOS version 3.2 at 0xca000 using scsi id 7
scsi1:  TMC-18C50 chip at 0x140 irq 5
scsi1 : Future Domain 16-bit SCSI Driver Version 5.50

Thanks
Carlo

-- 
  * Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - [EMAIL PROTECTED] che bisogno ci sarebbe
  *   di parlare tanto di amore e di rettitudine? (Chuang-Tzu)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ISSUE: fs corruption under 2.4.4

[Michal Kaspar]

1. Filesystem corruption under 2.4.4
2. I encountered fs corruption shortly after upgrade from 2.4.3 to 2.4.4.
I found it after turning on my computer. The partitions seemed clean, but
a lot of files needed for system start could not be found.
The day before I turned it off correctly. I do not know what exactly
trggered the situation. Before turning it off I coppied some large (600+
MiB) from network via samba to slave harddisk on primary IDE channell. My
root partition is on primary master, the chipset is VIA KT133 (VT82C686).
3. filesystem, ext2fs, samba, networking, FAT
4. 2.4.4
7.1.
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux miklin 2.4.3 #8 Ne dub 1 19:28:25 CEST 2001 i686 unknown
Kernel modules found
ver: eucho: command not found
Binutils   2.10.91.0.2
Linux C Library2.2.so
ldd: missing file arguments
Try `ldd --help' for more information.
ls: /usr/lib/libg++.so: No such file or directory
Procps 2.0.7
Mount  2.10r
Net-tools  (2000-05-21)
Kbd[option...]
Sh-utils   2.0
Sh-utils   Parker.
Sh-utils
Sh-utils   Inc.
Sh-utils   NO
7.2
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 3
model name  : AMD Duron(tm) Processor
stepping: 0
cpu MHz : 600.044
cache size  : 64 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips: 1196.03
7.3.
emu10k144752   1 (autoclean)
usbmouse1920   0 (unused)
NVdriver  627216  17 (autoclean)
ne2k-pci4736   1 (autoclean)
83906144   0 (autoclean) [ne2k-pci]
ipchains   33056   0 (unused)
ntfs   36528   1 (autoclean)
nls_iso8859-2   3392   1 (autoclean)
nls_cp852   3616   1 (autoclean)
vfat   11408   1 (autoclean)
fat31040   0 (autoclean) [vfat]
md 41408   0 (unused)
mousedev4160   1
hid11744   0 (unused)
input   3168   0 [usbmouse mousedev hid]
usb-uhci   21904   0 (unused)
usbcore48112   1 [usbmouse hid usb-uhci]
7.5. The system board is MSI K7T Pro vith VIA KT133 chipset. Ide
interface VT82C686. Ethernet controller is RTL-8029(AS). Graphic card
NVidia GeForce MX with NVidia drivers.
X. The distribution I use is RedHat 7.1 upgraded from previous versions.
Running e2fsck helped little. I had to remove some files with debugfs and
create them again from backup. Mainly symlinks were affected.

-- 
Michal Kašpar

VŠE Praha

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

Re: Compiling kernel

[Anton Altaparmakov]

On Wed, 2 May 2001 [EMAIL PROTECTED] wrote:
>  The question may sound very stupid... But I have following doubt.
> 
> suppose I am making some change in sched.c and now I want to build my kernel
> that reflects the change..
> Is there any way I can avoid answering all the questions when I do make zImage ?
> 
> In short how should I compile the kernel (in very small time) to see my changes.

Assuming you have already configured your kernel and previously compiled
it then no questions should be asked. - The way I work is to do make
bzImage, try it, modify. make bzImage, try, etc... No questions asked.

If you did an accidental make mrproper or make clean in between then make
a copy of you old .config (I keep mine in /usr/src/my2.4.4config for
example so I would do from /usr/src/linux: cp ../my2.4.4config .config)
then run make oldconfig

followed by make dep && make bzImage

In future don't do a make mrproper or clean for that matter. All modified
files are automatically recompiled while non-modified ones are taken from
old compile. - This saves incredible amounts of time when using a Pentium
133 for development...

> Thanks (for not flaming me)

You are welcome. (-:

HTH,

Anton
-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

about kernel 2.4.x

[sébastien person]

Hi,
is someone could explain me what are the main differences between kernel 2.2.x and 
2.4.x ?
thanks

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

Re: isa_read/write not available on ppc - solution suggestions ??

[mike_phillips]

> We can certainly do that, no problem.

> BUT that won't get a token ring pcmcia card working in the newer
> powerbooks, such as the titanium G4 powerbook, because the PCI host
> bridge doesn't map any cpu addresses to the bottom 16MB of PCI memory
> space.  This is not a problem as far as pcmcia cards are concerned -
> the pcmcia stuff just picks an appropriate address (typically in the
> range 0x9000 - 0x9fff) and sets the pcmcia/cardbus bridge to
> map that to the card.  But it means that the physical addresses for
> the card's memory space will be above the 16MB point, so it is
> essential to do the ioremap.

This is where the multiple support issue comes in. In ibmtr_cs.c we do 
ioremap the addresses so pcmcia all works nicely. What we don't do at 
present is an ioremap in ibmtr.c for the non-pcmcia adapters (isa & mca). 
So, I suppose the real fix would be to implement the ioremap in ibmtr.c so 
that regular read/writes can be used everywhere in the driver. (This is 
half the battle with changes to the driver, it supports so many 
combinations that one change for one type of adapter can kill support for 
another adapter, and that's my bottom line with updates: No loss of 
functionality we already had.)

Or we could just tell people to use the cardbus token ring adapter on ppc 
instead ;)

Mike

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

randon number generator in kernel..

[Deepika Kakrania]

 Hi,

  Can anyone tell me whether there is already any function to generate
random number inside kernel. If there is one what is that?

Thanks in advance.

Regards,
Deepika

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

[PATCH] Problem: file /proc/tty/driver/serial does not get deleted on module unload in Kernel 2.4.4

[Johannes Kolb]

[1.] Summary: The file /proc/tty/driver/serial does not get deleted on module unload
[2.] Description: If the serial driver (compiled as module) is loaded and then 
  unloaded, the proc-entry tty/driver/serial does not get deleted. 
  The remaining file is invalid and produces a kernel-oops on access.
[3.] Keywords: procfs, tty, serial driver
[4.] Kernel version: 2.4.4

[6.] Shell script:
  #!/bin/bash
  insmod serial
  rmmod serial
  ls /proc/tty/driver

[7.] Environment (IMHO irrelevant)
[7.1.] Software:
Linux jk1 2.4.4 #3 Mon Apr 30 00:11:51 CEST 2001 i586 unknown
 
Gnu C  2.95.3
Gnu make   3.79
binutils   2.10.1
mount  2.9y
modutils   2.4.1
e2fsprogs  1.19
reiserfsprogs  3.x.0b
PPP2.4.0
Linux C Library2.2.2
Dynamic linker (ldd)   2.2.2
Procps 2.0.2
Net-tools  1.46
Kbd0.96
Sh-utils   1.12
Modules Loaded serial isa-pnp ipchains
   
[6.2.] Processor:  Intel Pentium, 90 MHz 

[X.] Other notes

I played with the source and found out that the following one-line-patch helps.
If the function proc_tty_unregister is called, the string driver->driver_name
is empty, but ent->name still contains the right filename; so by using this
the proc-entry is deleted correctly.

--- linux/fs/proc/vanilla/proc_tty.cSun Apr 29 23:34:09 2001
+++ linux/fs/proc/proc_tty.cSun Apr 29 23:46:32 2001
@@ -161,7 +161,7 @@
if (!ent)
return;

-   remove_proc_entry(driver->driver_name, proc_tty_driver);
+   remove_proc_entry(ent->name, proc_tty_driver);

driver->proc_entry = 0;
 }

I'm not on this list, so please answer with CC to me.

hope, I could help,
bye

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

Re: randon number generator in kernel..

[Alan Cox]

>   Can anyone tell me whether there is already any function to generate
> random number inside kernel. If there is one what is that?

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

Re: X15 alpha release: as fast as TUX but in user space

[Zach Brown]

> i think Zach's phhttpd is an important milestone as well, it's the first
> userspace webserver that shows how to use event-based, sigio-based async
> networking IO and sendfile() under Linux. (I believe it had some

*blush*

> performance problems related to sigio queue overflow, these issues might
> be solved in the latest kernels.) The zerocopy enhancements should help
> phhttpd as well.

oh, it has a bunch of problems :)  over-threading created complexity in
the fast path.  It always spends memory on a contiguous header region for
each connection, which may not be valid in the days of zero copy sendmsg.
It does IO in the fast path.  And looking back at it, I'm struck by how
naive most of the code is :) :)

I've always been tempted to go back and take a real swing at a
nice content server, but there's only so many hours in the day, and
apache+thttpd+tux complete the problem space.  If X15 isn't released
with an open license, I may be tempted yet again :)

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

Re: randon number generator in kernel..

[Erik Mouw]

On Wed, May 02, 2001 at 07:24:39PM +0530, Deepika Kakrania wrote:
>   Can anyone tell me whether there is already any function to generate
> random number inside kernel. If there is one what is that?

See drivers/char/random.c


Erik

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

input core pointers, someone?

[Magnus Bodin]

I'm about to write a (IR) KEYBOARD device driver. I guess I'm better off
using the existing work on the USB-path with input core etc that appeared
sometimes around 2.2?

Is there ANY documentation/schematics on how this works or is it 'Read The
Fantastic Source' and/or e-mail Pavel Machek that is my way to go?

_Any_ pointers is of interest.

/magnus

--
::..   Magnus Bodin
::...   http://x42.com/
::...
teoiasrnhlcmdwgpyvk/.f?b2)(x 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Broken gcc ?

[Bob McElrath]

Amarendra GODBOLE [[EMAIL PROTECTED]] wrote:
> Hello World !
> 
> If I recall correctly, RHL 7 shipped with a broken gcc. Has it been 
> fixed ? Basically, is it safe to switch to RHL 7 for development 
> purposes ? Presently I use RHL 6.2 with 2.2.14 kernel.

It "works"...sorta.  It will compile the kernel.  But in my development
using lots of STL and C++, I've become an expert at generating "Internal
compiler error" with it.  YMMV.

> Apologies if this is not the proper list for this question, and yes,
> thanks in advance.

Not really...

Cheers,
-- Bob

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

 PGP signature

RE: input core pointers, someone?

[Dunlap, Randy]

http://www.suse.cz/development/input/

and Vojtech Pavlik ([EMAIL PROTECTED])


~Randy503-677-5408_
--- 

> -Original Message-
> From: Magnus Bodin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2001 7:18 AM
> To: [EMAIL PROTECTED]
> Subject: input core pointers, someone?
> 
> 
> 
> I'm about to write a (IR) KEYBOARD device driver. I guess I'm 
> better off
> using the existing work on the USB-path with input core etc 
> that appeared sometimes around 2.2?
> 
> Is there ANY documentation/schematics on how this works or is 
> it 'Read The
> Fantastic Source' and/or e-mail Pavel Machek that is my way to go?
> 
> _Any_ pointers is of interest.
> 
> /magnus

> 


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

Re: Linux Kernel Debuggers, KDB or KGDB?

[Ingo Oeser]

On Tue, May 01, 2001 at 10:22:14AM -0500, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > Basically you could add support for ALL generic subsystems, that
> > support dummy hardware, like SCSI and ISDN for example.
> > Is that planned or do I suggest sth. stupid here? ;-) 
> 
> Neither.  I know squat about hardware, so I had no idea that SCSI and ISDN 
> would be easy to do from UML.
> 
> If the SCSI and ISDN people want to produce appropriate UML drivers, I take 
> patches :-)

Everything is there. SCSI and ISDN have the equivalent devices of the
"lo" driver for the networking layer. Or the equivalent of
tun/tap devices for the ethernet layer.

It just have to be an config.in option in UML and every other
adapters switched off.

The problem is: I still do not really get how UML really works.
Many of the mapping rules (Kernel machanism on normal arch ->
UML) are not quite clear to me.

Is there a paper or sth. like that describing the design a bit
more in detail? I only found usage papers on the user-mode-linux
home page.

Regards

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

[PATCH] 2.4.4-ac3 +IPX -SYSCTL compile fix

[Pavel Roskin]

Hello!

File net/ipx/sysctl_net_ipx.c provides dummy functions for
ipx_register_sysctl and ipx_unregister_sysctl if CONFIG_SYSCTL is not
defined. The problem is, sysctl_net_ipx.c is not even compiled in this
case.

I'm moving the dummy functions to af_ipx.c where they are used. Not sure
about conformance with the coding standards, but I think that "static
inline" is preferred over defines. Feel free to correct me.

The patch is also here:
http://www.red-bean.com/~proski/linux/ipxsysctl.diff

The patch has been tested. IPX works fine without SYSCTL.

Regards,
Pavel Roskin

--
--- linux.orig/net/ipx/af_ipx.c
+++ linux/net/ipx/af_ipx.c
@@ -116,8 +116,18 @@
 #include 
 #include 

+#ifdef CONFIG_SYSCTL
 extern void ipx_register_sysctl(void);
 extern void ipx_unregister_sysctl(void);
+#else
+static inline void ipx_register_sysctl(void)
+{
+}
+
+static inline void ipx_unregister_sysctl(void)
+{
+}
+#endif

 /* Configuration Variables */
 static unsigned char ipxcfg_max_hops = 16;
--- linux.orig/net/ipx/sysctl_net_ipx.c
+++ linux/net/ipx/sysctl_net_ipx.c
@@ -44,11 +44,5 @@ void ipx_unregister_sysctl(void)
 }

 #else
-void ipx_register_sysctl(void)
-{
-}
-
-void ipx_unregister_sysctl(void)
-{
-}
+#error This file shouldn't be compiled without CONFIG_SYSCTL defined
 #endif

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

Re: 2.4 and 2GB swap partition limit

[Stephen C. Tweedie]

Hi,

On Wed, May 02, 2001 at 01:49:16PM +0100, Hugh Dickins wrote:
> On Wed, 2 May 2001, Stephen C. Tweedie wrote:
> > 
> > So the aim is more complex.  Basically, once we are short on VM, we
> > want to eliminate redundant copies of swap data.  That implies two
> > possible actions, not one --- we can either remove the swap page for
> > data which is already in memory, or we can remove the in-memory copy
> > of data which is already on swap.  Which one is appropriate will
> > depend on whether the ptes in the system point to the swap entry or
> > the memory entry.  If we have ptes pointing to both, then we cannot
> > free either.
> 
> Sorry for stating the obvious, but that last sentence gives up too easily.
> If we have ptes pointing to both, then we cannot free either until we have
> replaced all the references to one by references to the other.

Sure, but it's far from obvious that we need to worry about this.  2.2
has exactly this same behaviour for shared pages, and so if people are
complaining about a 2.4 regression, this particular aspect of the
behaviour is clearly not the underlying problem.

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

Both 2.4.4aa2 and 2.4.4aa3 fail to compile

[Maintaniner on duty]

With gcc-2.95.2 provided by SuSE-7.0 for Alpha on UP2000 SMP with 2GB memory


gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe -mno-fp-regs -ffixed-8 -mcpu=ev6 
-Wa,-mev6-c -o extable.o extable.c
extable.c: In function `search_exception_table_without_gp':
extable.c:54: `modlist_lock' undeclared (first use in this function)
extable.c:54: (Each undeclared identifier is reported only once
extable.c:54: for each function it appears in.)
make[2]: *** [extable.o] Error 1
make[2]: Leaving directory `/usr/src/linux/arch/alpha/mm'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux/arch/alpha/mm'
make: *** [_dir_arch/alpha/mm] Error 2


Regards,

G. Hugh Song

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

Re: Linux Kernel Debuggers, KDB or KGDB?

[Andi Kleen]

On Tue, May 01, 2001 at 11:16:50AM +1000, Keith Owens wrote:
> My ideal debugger is one that combines the internal knowledge of kdb
> with the source level debugging of gdb.  I know how to do this over a
> serial line, finding time to write the code is the problem.

http://pice.sourceforge.net is one approach to it; but it's currently
a bit limited: e.g. ATM UP-i386-2.2 only and somewhat windowish; also the
approach only really works for modules not complete kernel sources unless
you have a *lot* of memory. Still in its limits it works.

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

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

[Ingo Oeser]

On Tue, May 01, 2001 at 09:32:41PM +0100, Alan Cox wrote:
> Having thought over the issues I plan to maintain a 32bit dev_t kernel with
> conventional mknod behaviour, even if Linus won't. One very interesting item
> that Peter Anvin noted is that its not clear in POSIX that
> 
>   mknod /dev/ttyF00 c 100 100
> 
>   open("/dev/ttyF00/speed=9600,clocal");
> 
> is illegal. That may be a nice way to get much of the desired
> behaviour without totally breaking compatibility

Ouch! 

How is that supposed to work with the dcache?

1. Does POSIX state, that "/" is the directory/entry[1] separator?
2. Can a device node be an directory?

If 1. and not 2., there is no way to implement it like that.

I don't know how people call this, if they call sth. like DevFS
"crappy", but I would be very surprised, if they call it "clean".

Just think of: 

test -r /dev/ttyF00/speed=9600,clocal && cat /dev/ttyF00/speed=9600,clocal

Or the equivalent in C in most of the programs, which read sth.

POSIX might not forbid this, because common sense already does ;-)

Regards

Ingo Oeser

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

Re: isa_read/write not available on ppc - solution suggestions ??

[Jonathan Lundell]

At 3:46 PM -0700 2001-05-01, Linus Torvalds wrote:
>On Tue, 1 May 2001, Russell King wrote:
>  >
>>  In which case, can we change the following in IO-mapping.txt please?
>
>Oh, sorry. I misread your question. The _return_ value is a cookie.
>
>The first argument should basically be the start of a "struct pci_dev"
>resource entry, but obviously architecture-specific code can (and does)
>know what the thing means. And the ISA space (ie 0xA-0x10) has
>been considered an acceptable special case.
>
>So the only usage that is "portable" is to do something like
>
>   cookie = ioremap(pdev->resource[0].start, pdev->resource[0].len);
>
>and I guess we should actually create some helper functions for that too.
>
>You can use ioremap in other ways, but there's nothing to say that they
>will work reliably across multiple PCI buses etc.

What's the Linu[sx] attitude to using a type to help control (and 
illuminate) the use of these objects? I'm thinking here in particular 
of the cookie returned by ioremap() and used by readx/writex, but I 
suppose there might be similar applicability to its first parameter.
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: (follow-up) 2.4.4, ac1,ac2,ac3 - panics on ICMPv6 packets

[Cliff Albert]

On Wed, May 02, 2001 at 12:26:28PM +0100, Alan Cox wrote:

> >  2.4.4, ac1, ac2 AND now ac3 will panic on receiving ICMPv6 packets (like 
>traceroute6 and ping6)
> >  See my earlier messages for panic info.
> 
> Does building without netfilter support help ?

There is no netfilter support in my kernel at all neither v4 or v6
I have got confirmed from several people that if they ping6 their box it also dies

-- 
Cliff Albert| IRCNet:#linux.nl, #ne2000, #linux, #freebsd.nl
[EMAIL PROTECTED] |#openbsd, #ipv6, #cu2.nl
-[ICQ: 18461740]| 6BONE: CA2-6BONE   RIPE: CA3348-RIPE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 2.4.4-ac3 +IPX -SYSCTL compile fix

[Pavel Roskin]

> +#error This file shouldn't be compiled without CONFIG_SYSCTL defined

Oops, sorry! Unterminated string constant in preprocessor. It should be

#error This file should not be compiled without CONFIG_SYSCTL defined

The patch at http://www.red-bean.com/~proski/linux/ipxsysctl.diff has been
updated.

-- 
Regards,
Pavel Roskin

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

TV viewing broken in 2.4.4 (and 2.4.3)

[Robert Holmberg]

When my tv picture gets over a certain size, say when I enter fullscreen mode using 
xawtv or just resize my window over a certain point, most of the picture turns black 
and I get only a small strip of tv picture to the left of xawtv's window. TV was 
working well under 2.4.2.

I reported this bug before for 2.4.3 and a patch which fixed (or worked around) this 
problem was posted. The patch still works for 2.4.4

diff -urN linux/arch/i386/kernel/pci-pc.c
linux/arch/i386/kernel/pci-pc.c
--- linux/arch/i386/kernel/pci-pc.c Sat Mar 31 00:12:41 2001
+++ linux/arch/i386/kernel/pci-pc.c Thu Mar 29 05:00:04 2001
@@ -1035,7 +1035,7 @@
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,  PCI_DEVICE_ID_VIA_82C686_4,
 pci_fixup_via_acpi },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,  PCI_DEVICE_ID_VIA_8363_0,  
 pci_fixup_vt8363 },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,  PCI_DEVICE_ID_VIA_82C691,  
 pci_fixup_via691 },
-   { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,  PCI_DEVICE_ID_VIA_82C598_1,
 pci_fixup_via691_2 },
+// { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,  PCI_DEVICE_ID_VIA_82C598_1,
+ pci_fixup_via691_2 },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82371AB_3, 
 pci_fixup_piix4_acpi },
{ 0 }
 };

Since the seems to be a VIA problem: I have a VIA MPV3 motherboard using an AMD K6-2 
processor. My TV card is a Hauppage WinTV.

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

Problem with map_user_kiobuf() not mapping to physical memory

[Terry Barnaby]

We are developing a Linux driver which allows a device to read/write
directly
into a processes virtual memory space.
I have a question on using map_user_kiobuf() as we are having problems.
I was under the impression that if I used map_user_kiobuf() this would
map
the users virtual address space into locked physical memory pages so
that
I/O could be performed.
However, I note that if the user just mallocs memory and does not access
it
(No physical memory pages created) and then passes this virtual address
space
to the driver which performs a map_user_kiobuf() on it, the resulting
kiobuf
structure has all of the pagelist[] physical address entries set to the
same value
and the maplist[] entries set to 0. The devices access to this memory
now
causes system problems.
Is map_user_kiobuf() working correctly ?
Should I call some function to map the virtual address space into
physical memory
or at least pages before I call map_user_kiobuf() ?

Cheers

Terry

--
  Dr Terry Barnaby BEAM Ltd
  Phone: +44 1454 324512   Northavon Business Center, Dean Rd
  Fax:   +44 1454 313172   Yate, Bristol, BS37 5NH, UK
  Email: [EMAIL PROTECTED]Web: www.beam.demon.co.uk
  BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software Dev
 "Tandems are twice the fun !"



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

Re: inserting a Forth-like language into the Linux kernel

[Rick Hohensee]

> 

I thought my mail client was doing "reply to all recipients". If it _was_
then this is redundant and I apologize.

> 
> 
> On Tue, 1 May 2001, Rick Hohensee wrote:
>  
> > (kspamd) is the Linux-side wrapper for H3sm
> 
> C|N>K
> 
> OK, you owe me a new keyboard. And thanks for new .sig.

Oh, uh, sorry about that, Chief.

> BTW, Rick, out of curiosity - how many Greencard Lawyers does it take
> to upgrade the thing to full-blown H1 S&M?
> 

I dono. How many you got?

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

[RFC] gcc compile-time assertions

[David Howells]

I'm looking for comments on an idea I've thrashed out with David Woodhouse,
Arjan Van de Ven and Andrew Haley...

I've written a patch for gcc to implement compile-time assertions with an eye
to making use of this in the kernel in the future (assuming I can get it to be
accepted into gcc).

One of the main uses I can see for it is for things like udelay() that need
their arguments range checking. The current method of doing this is by causing
an undefined symbol to be referenced, thereby causing the linker to emit an
error that can be hard to trace.

The gcc patch can be downloaded:

ftp://infradead.org/pub/people/dwh/ctassert.diff

Basically, what I've written is a small extension for gcc that implements
compile-time assertion checking through a new built in function (this has
negligible impact on the rest of the source for gcc).

The assertion function takes two arguments, a condition and a message
string. The return value is an expression "condition!=0". The function would
prototype something like:

int __builtin_ct_assert( condition, const char message[])

Additionally, if that expression can be evaluated to a constant of zero at
compile time, an error will be issued that includes the message string in its
text.

The main reason I'd like to see this added to gcc is to help improve the Linux
kernel's robustness by catching certain conditions at compile time. For
instance, Linux's udelay() function (which waits for a number of microseconds
up to a limit of 2uS), is implemented in the i386 architecture thus:

| extern void __bad_udelay(void);
| extern void __udelay(unsigned long usecs);
| extern void __const_udelay(unsigned long usecs);
|
| #define udelay(n) (__builtin_constant_p(n) ? \
|   ((n) > 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \
|   __udelay(n))

This relies on __bad_udelay() getting referenced in the program when n is too
large, and causing a linker error, which is quite hard to trace since the
kernel build makes heavy use of incremental linking.

This can be re-implemented using my gcc patch:

| #define udelay(n) ( \
|__builtin_ct_assert((n)<=2,"udelay() value should be <=2uS"), \
|__builtin_constant_p(n) ? __const_udelay((n) * 0x10c6ul) : __udelay(n))

And producing an error of the following sort:

| test.c:21: compile-time assertion failed: udelay() value should be <=2uS

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

nfs performance at high loads

[Kapish K]

Hello!!
Well... thanks for all the suggestions, but we might need to 
stick with 2.4.2 for various other dependencies, but, I have a 
surprising thing to report on the observations. I tried the 
zero-copy patch on 2.4.0, and it seemed to help in solving the 
memory allocation problem, and also did have some decent 
throughput and response time ( around 5 milliseconcds or so ).
But, with 2.4.2, its horrible!!! Yes, we don't see any memory 
allocation problems, but nfs seems to have been really screwed 
up or something. I haven't had the chance to look at the code ( 
should try to do so soon ), but does anybody have any idea of 
lurking bugs in this area?? This is totally unacceptable. We see 
response times of 80 milliseconds!!! There is something really 
gone wrong here...
any ideas??
Thanks 


Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Alan Cox]

> 1. Does POSIX state, that "/" is the directory/entry[1] separator?
> 2. Can a device node be an directory?
> 
> If 1. and not 2., there is no way to implement it like that.

Why not. It doesn't say what happens if there is pathname left over when you
hit the device specifically.

tar would archive the device node, not the options.


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

Re: Problem with map_user_kiobuf() not mapping to physical memory

[Bjorn Wesen]

On Wed, 2 May 2001, Terry Barnaby wrote:
> However, I note that if the user just mallocs memory and does not access
> it
> (No physical memory pages created) and then passes this virtual address
> space
> to the driver which performs a map_user_kiobuf() on it, the resulting
> kiobuf
> structure has all of the pagelist[] physical address entries set to the
> same value
> and the maplist[] entries set to 0. The devices access to this memory
> now
> causes system problems.
> Is map_user_kiobuf() working correctly ?
> Should I call some function to map the virtual address space into
> physical memory
> or at least pages before I call map_user_kiobuf() ?

No.. but you might just have done something wrong.

See the example in arch/cris/drivers/examples/kiobuftest.c

(that example does not deallocate the vectors properly IIRC, but the
actual kiobuf mapping sequence should work)

/BW

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

Re: TV viewing broken in 2.4.4 (and 2.4.3)

[Alan Cox]

> I reported this bug before for 2.4.3 and a patch which fixed (or worked around) this 
>problem was posted. The patch still works for 2.4.4

The fixup is bogus. Im not sure who wrote it or why. Its not the right fix for
the VIA later chip bugs. Its not the right way to do a two chip combination
fixup if that was really needed.

Deleting it seems sensible


Alan

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

Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

[Jonathan Morton]

>> the only general issue is that kx133 systems seem to be difficult
>> to configure for stability.  ugly things like tweaking Vio.
>> there's no implication that has anything to do with Linux, though.
>
>
>When I reported my problem a couple weeks back another fellow
>said he and several others on the list had the same problem,
>and as far as I can tell it is *only* with the IWILL boards.
>When I compiled with k7 optimizations I'd get all kinds of oopses
>and panics and never fully boot.  They were different every time.
>When any of the lesser optimizations are used I have no problems.
>My memory is one 256MB Corsair PC150 dimm, CPU is a Thunderbird 850,
>and mobo is an IWILL KK266 (KT133A).  The CPU runs between 35°C
>and 40°C.

I'm using an Abit KT7 board (KT133) and my new 1GHz T'bird (running 50-60°C
in a warm room) is giving me no trouble.  This is with the board and RAM
pushed as fast as it will go without actually overclocking anything...  and
yes, I do have Athlon/K7 optimisations turned on in my kernel (2.4.3).

Out of interest, what FSB are you using for your machine?  I understand the
difference between the KT133 and the KT133A is that the latter supports a
266MHz FSB for the Athlon rather than 200MHz.  Since your CPU is running
cool, I doubt you've managed to accidentally o/c it, but nevertheless this
is a possibility...

The 266MHz FSB does require considerably higher standards in board
construction though, so it could be that IWILL have managed to do a shoddy
job on that end.

--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 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+(*)
-END GEEK CODE BLOCK-


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

[3com905b freeze Alpha SMP 2.4.2] FullDuplex issue ?

[Cabaniols, Sebastien]

Hello,


my hardware configuration is:

2 Alphaserver ES40 running kernel 2.4.2smp
   with 3com905b FastEthernet PCI 


The configuration is switched, 100 Full Duplex autonegotiation.



I insert the 3c59x module with debug=7.


I start an ftp transfer from machine A to B:

machine A   machine B   

ftp B   ftpd answering

get bigfile 

bigfile is 500 Megabytes, and transfer fine at 11 MegaBytes/s perfectly


Now I want to stress/test fullduplex:

machine A   machine B

ftp B   ftp A
ftpd answers to B   ftpd answer to A
get bigFile get bigFile2

The first of the above machines launching the get freezes.  

I include a file with my logs, the output of the crashed machine after
reboot.
I also include the output of uname -a, lspci -vx, vortex --aaee.

Thanks for any help, If some information is missing there do not hesitate to
ask.


Sebastien Cabaniols





uname-a

Linux es40-06 2.4.2smp #1 SMP Wed May 2 13:58:01 EDT 2001 alpha unknown
 



kernel log with debug=7 passed to modprobe




May  2 16:45:52 es40-06 kernel: 3c59x.c:LK1.1.12 06 Jan 2000  Donald Becker and 
others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $
May  2 16:45:52 es40-06 kernel: See Documentation/networking/vortex.txt
May  2 16:45:52 es40-06 kernel: eth0: 3Com PCI 3c905B Cyclone 100baseTx at 0x8400,  
00:01:02:d9:94:f0, IRQ 32
May  2 16:45:52 es40-06 kernel:   product code 'CG' rev 00.12 date 09-22-00
May  2 16:45:52 es40-06 kernel:   8K byte-wide RAM 5:3 Rx:Tx split, 
autoselect/Autonegotiate interface.
May  2 16:45:52 es40-06 kernel:   MII transceiver found at address 24, status 786d.
May  2 16:45:52 es40-06 kernel: 3c59x: Wake-on-LAN functions disabled
May  2 16:45:52 es40-06 kernel:   Enabling bus-master transmits and whole-frame 
receives.
May  2 16:46:07 es40-06 sysctl: error: 'net.ipv4.ip_always_defrag' is an unknown key
May  2 16:46:07 es40-06 sysctl: net.ipv4.ip_forward = 0
May  2 16:46:07 es40-06 sysctl: net.ipv4.conf.all.rp_filter = 1
May  2 16:46:07 es40-06 sysctl: kernel.sysrq = 0
May  2 16:46:07 es40-06 network: Setting network parameters:  succeeded
May  2 16:46:07 es40-06 ifup: SIOCADDRT: Network is unreachable
May  2 16:46:07 es40-06 network: Bringing up interface lo:  succeeded
May  2 16:46:07 es40-06 kernel: eth0: using NWAY autonegotiation
May  2 16:46:07 es40-06 kernel: eth0: MII #24 status 786d, link partner capability 
41e1, setting full-duplex.
May  2 16:46:07 es40-06 network: Bringing up interface eth0:  succeeded
May  2 16:47:02 es40-06 ftpd[1225]: FTP LOGIN FROM es40-05.idris.domain [10.1.1.5], 
toto
May  2 16:47:29 es40-06 kernel: <74 ticks.
May  2 16:47:29 es40-06 kernel: <7tart_xmit()
May  2 16:47:29 es40-06 kernel: < e401.
May  2 16:47:29 es40-06 kernel: <77>eth0: exiting interrupt, status e000.
May  2 16:47:29 es40-06 kernel: t size 66 status 60008042.
May  2 16:47:29 es40-06 kernel: boomerang_rx(): status e001
May  2 16:47:29 es40-06 kernel:  interrupt loop, status e401.
May  2 16:47:29 es40-06 kernel: <7errupt, status e201, latency 3 ticks.
May  2 16:47:29 es40-06 kernel: <_xmit()
May  2 16:47:29 es40-06 kernel: http://www.scyld.com/diag/index.html
Index #1: Found a 3c905B Cyclone 100baseTx adapter at 0x8400.
The Vortex chip may be active, so FIFO registers will not be read.
To see all register values use the '-f' flag.
Initial window 7, registers values by window:
  Window 0:     f5f5 00bf  .
  Window 1: FIFO FIFO      2000.
  Window 2: 0100 d902 1a93    000a 4000.
  Window 3:  0180 05ea 0020 000a 0800 0800 6000.
  Window 4:    0cd8 0003 8880  8000.
  Window 5: 1ffc   0600 0807 06ce 06c6 a000.
  Window 6:    0900 1000 0252 0a87 c000.
  Window 7:        e000.
Vortex chip registers at 0x8400
  0x8410: **FIFO**  0011 *STATUS*
  0x8420: 0020  0008 0004
  0x8430:  234ddcb3 c1d88090 00080004
 Indication enable is 06c6, interrupt enable is 06ce.
 No interrupt sources are pending.
 Transceiver/media interfaces available:  100baseTx 10baseT.
Transceiver type in use:  Autonegotiate.
 MAC settings: full-duplex.
 Station address set to 00:01:02:d9:93:1a.
 Configuration options 000a.
EEPROM contents (64 words, offset 0):
 0x000: 0001 02d9 931a 9055 0135 0048 4743 6d50
 0x008: 2971  0001 02d9 931a 0010  0022
 0x010: 32a2   0180    10b7
 0x018: 9055 000a      
 0x020: 0093       
 0x028:        
 0x030:        
 0x038:        
 T

Re: iso9660 endianness cleanup patch

[H. Peter Anvin]

Martin Dalecki wrote:
> 
> "H. Peter Anvin" wrote:
> >
> > Hi guys,
> >
> > I was looking over the iso9660 code, and noticed that it was doing
> > endianness conversion via ad hoc *functions*, not even inlines; nor did
> > it take any advantage of the fact that iso9660 is bi-endian (has "all"
> > data in both bigendian and littleendian format.)
> >
> > The attached patch fixes both.  It is against 2.4.4, but from the looks
> > of it it should patch against -ac as well.
> 
> Please beware: There is a can of worms you are openning up here,
> since there are many broken CD producer programms out there, which
> only provide the little endian data and incorrect big endian
> entries. I had some CD's of this form myself. So the endian neutrality
> of the iso9660 is only in the theory present...
> 

So it has been discussed, and been updated.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

xconfig is broken (example ppc 8xx)

[george anzinger]

To show the problem do:

make xconfig ARCH=ppc

in the "Platform support" menu "Processor Type" select "8xx" then close
the subminue with "MainMenu"

now select "Save and Exit"

This produces the following error messages:

ERROR - Attempting to write value for unconfigured variable
(CONFIG_SCC_ENET).
ERROR - Attempting to write value for unconfigured variable
(CONFIG_FEC_ENET).

The named CONFIG options are not set, nor are a few others related to
CONFIG_SCC_ENET.
(This means the on board NIC is not configured and since this is usually
a disc less system, boot fails when trying to mount "/" over nfs.)

make menueconfig ARCH=ppc  works correctly.

The problem appears to be related to these lines in
../ARCH/ppc/config.in


if [ "$CONFIG_CPU_PPC_8xx" = "y" ]; then
source arch/ppc/8xx_io/Config.in
fi

if [ "$CONFIG_CPU_PPC_8260" = "y" ]; then
source arch/ppc/8260_io/Config.in
fi

Only one of the two files is included, however, both configure the two
options mentioned in the error messages.

I think the problem is that the "wish" script builder does not allow a
CONFIG option to be configured in two different places, even if only one
of scripts should be included.

Additional info: Kernel revs tested 2.4.2, 2.4.3
If you swap the two "if" phrases above, the 8xx config works but the
8260 fails in the same way.  I.e. the last one wins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.4.4-ac3, asm problem in asm-i386/rwsem.h using gcc 3.0 CVS

[Christian Iseli]

Hi folks,

I currently fail to compile the 2.4.4-ac3 kernel using latest GCC 3.0 from CVS:
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
 -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
 -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c sys.c
sys.c: In function `sys_gethostname':
/usr/src/linux/include/asm/rwsem.h:152:
 inconsistent operand constraints in an `asm'

Here is the code exerpt:
/*
 * unlock after reading
 */
static inline void __up_read(struct rw_semaphore *sem)
{
__s32 tmp = -RWSEM_ACTIVE_READ_BIAS;
__asm__ __volatile__(
"# beginning __up_read\n\t"
LOCK_PREFIX "  xadd  %%edx,(%%eax)\n\t" /* subtracts 1, returns the old value 
*/
"  js2f\n\t" /* jump if the lock is being waited upon */
"1:\n\t"
".section .text.lock,\"ax\"\n"
"2:\n\t"
"  decw  %%dx\n\t" /* do nothing if still outstanding active 
readers */
"  jnz   1b\n\t"
"  pushl %%ecx\n\t"
"  call  rwsem_wake\n\t"
"  popl  %%ecx\n\t"
"  jmp   1b\n"
".previous\n"
"# ending __up_read\n"
: "+m"(sem->count), "+d"(tmp)
: "a"(sem)
: "memory", "cc");
}

I'm afraid I know zilch about asm constraints...
Can anybody spot the trouble (and fix it :) ?

Thanks,
Christian




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

Re: [3com905b freeze Alpha SMP 2.4.2] FullDuplex issue ?

[Bogdan Costescu]

On Wed, 2 May 2001, Cabaniols, Sebastien wrote:

> I insert the 3c59x module with debug=7.

Why ? debug=7 is the highest debug level and produces _lots_ of debug data
for high network activity. Do you have problems when insmod-ing without
any option and use a higher debug level just to see what's going on?

> The first of the above machines launching the get freezes.

Why do you believe that the card/driver is responsible for the freeze ?
The outputs that you provided show no problems to me.

A duplex mismatch would not freeze a computer. You would get crappy
transfer rates, usually some error messages from the driver, but
everything should otherwise work. To verify the media settings, you might
want to use mii-diag (from ftp.scyld.com).

Sincerely,

Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: [EMAIL PROTECTED]


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

Re: Maximum files per Directory

[H. Peter Anvin]

Ingo Oeser wrote:
> 
> On Tue, May 01, 2001 at 03:03:44PM -0700, H. Peter Anvin wrote:
> > > Bit of both. You exceeded the max link count, and your
> > > performance would have been abominable too. cyrus should be
> > > using heirarchies of directories for very large amounts of
> > > stuff.
> Right.
> 
> > But also showing, once again, that this particular scalability problem
> > really is a headache for some people.
> 
> If you do ls on that directory as an admin, you'll see, what the
> REAL cause of this headache is:
> 
> The application doing such stupid thing!
> 
> People (writing applications) building up such large directories
> should be forced to read every entry of it aloud.
> 
> Then they'll learn[1] and the problem is solved.
> 

"Violence is the last refuge of the incompetent."

Seriously, I don't buy this "the application is doing something stupid." 
The application is using the VFS the way it is advertised to work.  If
you think doing ls on an extrememly large directory is painful, you have
never seen the droppings of an application which tries to do
load-balancing between directories by doing real hashing.  THAT is
painful!  At least in the first case you can use grep.

The only ones we fool by repeating the mantra "stupid admin, stupid
application" is ourselves.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.4 code breaks compile of VMWare network bridging

[LA Walsh]

In 2.4.4, the define, in
include/linux/skbuff.h
and corresponding structure in
net/core/skbuff.c
, "skb_datarefp" disappeared.

I'm not reporting this as a 'bug' as kernel internal interfaces are subject
to change, but more as an "FYI".  I haven't had a chance to try to
debug or figure out the offending bit of code to see exactly what it
was trying to do, but the offending code snippet follows.  I haven't yet
reported it to the folks at VMware, but their response to problem reports
against 2.4.x is "can you duplicate it against 2.2.x, we don't support
2.4.x yet".  Perhaps someone expert in the 'net/core' area could explain
what changed and what they shouldn't be doing anymore?

It appears the references:
#  define KFREE_SKB(skb, type)  kfree_skb(skb)
#  define DEV_KFREE_SKB(skb, type)  dev_kfree_skb(skb)
^^
are the offending culprits.

Thanks for any insights...
-linda

/*
 *--
 * VNetBridgeReceiveFromDev --
 *  Receive a packet from a bridged peer device
 *  This is called from the bottom half.  Must be careful.
 * Results:
 *  errno.
 * Side effects:
 *  A packet may be sent to the vnet.
 *--
 */
int
VNetBridgeReceiveFromDev(struct sk_buff *skb,
 struct device *dev,
 struct packet_type *pt)
{
   VNetBridge *bridge = *(VNetBridge**)&((struct sock *)pt->data)->protinfo;
   int i;

   if (bridge->dev == NULL) {
  LOG(3, (KERN_DEBUG "bridge-%s: received %d closed\n",
  bridge->name, (int) skb->len));
  DEV_KFREE_SKB(skb, FREE_READ);
  return -EIO;  // value is ignored anyway
   }

   // XXX need to lock history
   for (i = 0; i < VNET_BRIDGE_HISTORY; i++) {
  struct sk_buff *s = bridge->history[i];
  if (s != NULL &&
  (s == skb || SKB_IS_CLONE_OF(skb, s))) {
 bridge->history[i] = NULL;
 KFREE_SKB(s, FREE_WRITE);
 LOG(3, (KERN_DEBUG "bridge-%s: receive %d self %d\n",
 bridge->name, (int) skb->len, i));
 // FREE_WRITE because we did the allocation, it's not used anyway
 DEV_KFREE_SKB(skb, FREE_WRITE);
 return 0;
  }
   }
   skb_push(skb, skb->data - skb->mac.raw);
   VNetSend(&bridge->port.jack, skb);

   return 0;
}

--
The above thoughts and   | They may have nothing to do with
writings are my own. | the opinions of my employer. :-)
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338


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

Re: 2.4.4 code breaks compile of VMWare network bridging

[Mohammad A. Haque]

On Wed, 2 May 2001, LA Walsh wrote:

> reported it to the folks at VMware, but their response to problem reports
> against 2.4.x is "can you duplicate it against 2.2.x, we don't support
> 2.4.x yet".  Perhaps someone expert in the 'net/core' area could explain
> what changed and what they shouldn't be doing anymore?
>

This was answered several hours ago. Check the list archives.
-- 

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

Re: How can do to disable the L1 cache in linux ?

[Eric W. Biederman]

"Alex Huang" <[EMAIL PROTECTED]> writes:

> Dear All,
>  How can do to disable the L1 cache in linux ?
> Are there some commands or directives to disable it ??

Play with the MTRR's and disable caching on memory.

Stupid but it should get what you want.

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