Linux scalability?

[Sasi Peter]

Hi!

I am just writing an essay, an have mentioned TUX as a performance and
scalability linearity recort holder with TUX, referencing the specweb99
website summary page:

http://www.spec.org/osg/web99/results/web99.html

However, taking a closer look, it turns out, that the above statement
holds true only for 1 and 2 processor machines. Scalability already
suffers at 4 processors, and at 8 processors, TUX 2.0 (7500) gets beaten
by IIS 5.0 (8001), and these were measured on the same kind of box!

How come, TUX is s good at the lowend (1 and 2 CPUs), and scales this
bad?

-- 
SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Storage - redundant path failover / failback - quo vadis linux?

[Stefan . Bader]

Hi,

Please respond to Christoph Biardzki <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject:Storage - redundant path failover / failback - quo vadis
linux?



>I was investigating redundant path failover with FibreChannel disk
devices
>during the last weeks. The idea is to use a second, redundant path to a
>storage device when the first one fails. Ideally one could also implement
>load balancing with these paths.

I was looking at the same concepts lately. Not only from the view of the
failover
side but also for the aspects of using this paths (maybe even more than
one) for
the load balancing (which gets more important the more traffic goes to a
device).



>- The "T3"-Patch for 2.2-Kernels which patches the sd-Driver und the
>Qlogic-FC-HBA-Driver. When you pull an FC-Cable on a host equiped with
two
>HBAs the failover is almost immediate and an automatic failback (after
>"repairing") is possible

The drawback would be here (beside whether the load balancing is done
there
or not) is that this limits the solution to a specific type of devices.
One would have to have the same things in every device driver that wants
to
support multiple paths.

>- The "multipath"-Personality-patch for the md-Driver by Ingo Molnar
>(intergrated in the redhat 2.4.2-Kernel) You set up an md-device on
>two devices (which are actually the same physical device seen twice on
the
>dual paths) and when the primary one fails, the system will access the
>other one. There seems to be no failback possibility, however, and the
>failover takes around 30s.

The same idea here. Maybe going one step further. Intstead of using md the
idea
was to enhance the lvm to support multipathing. Since for lvm a physical
device
can be any block device (supporting certain gendisk interfaces) the paths
to the
device do not need to use the same physical interface (e.g. one path is
fibre
channel, another one ethernet).
The overhead during normal operation (depending of course whether and how
load
balancing is done) should be not much worse than the normal lvm operation
(request
always have to be mapped from the logical volume to a physical volume - so
this
adds just one other step). And since lvm keeps unique id's on its physical
devices
even the detection could somehow be automatic... :)
The failover stuff won't be that easy. I don't know how one could detect
the failure
of a path at this level fast enough. For now lvm itself doesn't care about
an io
request as soon as it is dispatched to a physical device. First approach
could be
to check the results of io requests and disable a path if there are too
many failures.
Then from time to time try that path again an re-enable it as soon as
there is success.
However, I think it could take rather long to be sure a path has failed
(maybe that are
the 30s delay in md).

>My question is which way is the more probable solution for future linux
>kernels?
>The low-level-approach of the "T3"-patch requires changes to the
>scsi-drivers and the hardware-drivers but provides optimal communication
>between the driver and the hardware

Thinking about it: if there would be some sort of 'available' flag in the
gendisk
structure, that would be updated by the low-level drivers. This could the
used by
a high-level design to use or skip a failed device/path...
In the S/390 (or zSeries) environment the device drivers are even able to
detect
a failing connection even if there is no data going to a device. That way
the device
would be disabled even _before_ anybody tries to write...

>The high-level-approach of the "multipath"-personality is
>hardware-independant but works very slowly. On the other hand I see no
>clear way how to check for availability of the (previously failed)
primary
>channel to automate a fail-back.

Well, slower, but I think there will be many that take that performance
loss already
by using lvm or md (for the benefit of flexible/large filesystems) this
approach would
add failover while beeing IMHO only a little less performant.



Stefan

Linux for eServer development, IBM Germany
[EMAIL PROTECTED]
--

  When all other means of communication fail, try words.


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

APIC errors on 2.4.4

[Andy Arvai]

Hi,

I'm having IO-APIC errors with 2.4.4. I spent some time searching the
web to understand more about this problem and I'm still not sure if
it is a hardware problem on the motherboard or a problem with the
kernel. I will try the noapic boot option, but are there any
patches that might fix this? Here are some of the errors I was
getting:

May 15 22:47:43 rad kernel: APIC error on CPU0: 02(01)
May 15 22:48:00 rad kernel: APIC error on CPU0: 01(02)
May 15 22:48:00 rad kernel: APIC error on CPU1: 02(02)
May 15 22:49:11 rad kernel: APIC error on CPU0: 02(02)
May 15 22:49:11 rad kernel: APIC error on CPU1: 02(02)
May 15 22:49:32 rad kernel: APIC error on CPU1: 02(02)
May 15 22:49:32 rad kernel: APIC error on CPU0: 02(02)
May 15 22:50:38 rad kernel: APIC error on CPU1: 02(02)
May 15 22:50:38 rad kernel: APIC error on CPU0: 02(02)
May 15 22:50:46 rad kernel: unexpected IRQ trap at vector d9
May 15 22:51:16 rad kernel: scsi0:0:0:0: Attempting to queue an ABORT message
May 15 22:51:16 rad kernel: scsi0:0:0:0: Command already completed
May 15 22:51:16 rad kernel: aic7xxx_abort returns 8194
May 15 22:51:26 rad kernel: scsi0:0:0:0: Attempting to queue an ABORT message
May 15 22:51:26 rad kernel: scsi0:0:0:0: Command already completed
May 15 22:51:26 rad kernel: aic7xxx_abort returns 8194

Thanks for any ideas.

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

New AIC7xxx driver - Berkeley DB1 to DB3

[Lorenzo Marcantonio]

Can someone verify if it's legal to change the include/link in the
assembler for AIC7xxx ? DB 1.85 has header clash with DB 3 (db.h).

It SEEMS to work but I'd rather be sure (since I've got that nasty 32
bit corruption prob on SCSI char devices...)

-- Lorenzo Marcantonio


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

[SCSI TAPE CORRUPTION] - AARGH... it's even on CDWR!

[Lorenzo Marcantonio]

Yesterday, I burnt some deployment CD for W98SE (yes, THAT thing...),
about 400 megs of stuff. And they DIDN'T work.

dd'ed the image from the cd device, then compared with the original
(luckily I had still it on my HDD)

32 defective bytes !!! from 32KB before :(((

Note that I've never suffered from HD corruption.

Maybe something on SCSI character devices?

Crying...
-- Lorenzo Marcantonio



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

Re: VIA/PDC/Athlon

[Steffen Persvold]

Pavel Roskin wrote:
> 
> Hello, Zilvinas!
> 
> There are utilities that work with PnP BIOS. They are included with
> pcmcia-cs (which is weird - it should be a separate package) and called
> "lspci" and "setpci". They depend on PnP BIOS support in the kernel
> (CONFIG_PNPBIOS).
> 
> Dumping your PnP BIOS configuration and checking whether it has changed
> after booting to Windows would be more reasonable than checking your PCI
> configuration (IMHO).

Ehm, "lspci" and "setpci" is part of the pci-utils package (at least on RedHat)
and is used to dump/modify PCI configuration space (/proc/bus/pci). If you know
how to use these tools to dump PNP bios, please tell us.

Regards
-- 
  Steffen Persvold   Systems Engineer
  Email : mailto:[EMAIL PROTECTED] Scali AS (http://www.scali.com)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-2.4.4 failure to compile

[Lorenzo Marcantonio]

On Thu, 17 May 2001, H. Peter Anvin wrote:

> I think the header file you're talking about is the db1 header file,
> which has nothing to do with yacc -- it's the Berkeley libdb version 1,
> which is a pretty bad thing to require.
>

I've got it to compile (and apparently work) even con libdb3... which
has the compability header db_185.h (or something similar).

IIRC, libdb1 was bundled with libc till release 2.1.3. Since 2.2 they've
said 'get it at sleepycat...'.

BTW, there are ifdef inside the driver about which header to include
(db.h or db_185.h IIRC).

I still doesn't comprend what does it NEED FOR the libdb...

-- Lorenzo Marcantonio


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

CML2 1.4.5 is available

[Eric S. Raymond]

The latest version is always available at http://www.tuxedo.org/~esr/cml2/

Release 1.4.5: Fri May 18 02:02:27 EDT 2001
* Rulesfile updated for 2.4.5pre3, 2.4.4ac10.

The project page now also includes a download URL for the latest
version of the Configure.help file.  It features over 340 entries that
are missing in the one Linus and Alan are shipping.
-- 
http://www.tuxedo.org/~esr/";>Eric S. Raymond

"The best we can hope for concerning the people at large is that they be
properly armed."
-- Alexander Hamilton, The Federalist Papers at 184-188
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 OS boilerplate

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Paul Gortmaker <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> > Does there exist an outline (detailed or not) of the boot process from
> > the point of BIOS bootsector load to when the kernel proper begins
> 
> IIRC, there is some useful info contained within loadlin.  Also, I
> found a doc by hpa called "THE LINUX/I386 BOOT PROTOCOL" in my local
> archive of cruft -  I just assumed it was in Documentation/ but
> apparently it never made it there (yet).
> 

Documentation/i386/boot.txt

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

Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Thu, 17 May 2001, Rik van Riel wrote:

> On Thu, 17 May 2001, Mike Galbraith wrote:
>
> > > Has anyone benched 2.4.5pre3 vs 2.4.4 vs. ?
> >
> > Only doing parallel kernel builds.  Heavy load throughput is up,
> > but it swaps too heavily.  It's a little too conservative about
> > releasing cache now imho. (keeping about double what it should be
> > with this load.. easily [thump] tweaked;)
>
> "about double what it should be"
>
> That's an interesting statement, unless you have some
> arguments to define exactly how much cache the system
> should keep.

Do you think there's 60-80mb of good cachable data? ;-)  The "double"
is based upon many hundreds of test runs.  I "know" that performance
is best with this load when the cache stays around 25-35Mb.  I know
this because I've done enough bend adjusting to get throughput to
within one minute of single task times to have absolutely no doubt.
I can get it to 30 seconds with much obscene tweaking, and have done
it with zero additional overhead for make -j 30 ten times in a row.
(that kernel was.. plain weird. perfect synchronization.. voodoo!)

> Or are you just comparing with 2.2 and you'd rather
> have 2.2 performance? ;)

Nope.  I've bent this vm up a little and build kernels that kicked the
snot out of the previous record holder (classzone).  I know for a fact
that it can kick major butt.. why I fiddle with it when it doesn't.

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

java/old_mmap allocation problems...

[firenza]

hi,

i'm having problems to convince java (1.3.1) to allocate more
than 1.9gb of memory on 2.4.2-ac2 (SMP/6gb phys mem) or more
than 1.1gb on 2.2.18 (SMP/2gb phys mem)...

modifing /proc/sys/vm parameters didn't help either... the fact
that i can allocate more memory under 2.4 than under 2.2 lets
me hope that there is some possible kernel/vm tweaking that
would increase those limits...

any pointers would be greatly appreciated!

cheers,
-firenza

PS:

strace snippet of "java -Xmx2g" on the 2.4 system
brk(0x8057000)  = 0x8057000
old_mmap(NULL, 163840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x43691000
old_mmap(NULL, 2181038080, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM 

strace snippet of "java -Xmx1500m" on the 2.2 system
old_mmap(0x2e082000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2e082000
old_mmap(NULL, 163840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2e102000
old_mmap(NULL, 1606418432, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM 

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

serial driver patch

[Attila Karpati]

Hi all,

I have a 16450 serial chip at home and it bothered me that if I play music and
compile some programs there are packet errors reported by
/sbin/ifconfig. Irqtune did help a bit but not much, so created a small patch
to add an option to use the SA_INTERRUPT flag in serial.c. Since then there
are no packet errors. You can find the patch at the end of my mail. The patch
is against 2.4.4. Maybe other people who use irqtune find it useful.

Bye,
 Attila

diff -urbBd linux.orig/drivers/char/Config.in linux/drivers/char/Config.in
--- linux.orig/drivers/char/Config.in   Wed Mar  7 04:44:34 2001
+++ linux/drivers/char/Config.inFri May 18 06:31:36 2001
@@ -20,6 +20,7 @@
 if [ "$CONFIG_SERIAL_EXTENDED" = "y" ]; then
bool '  Support more than 4 serial ports' CONFIG_SERIAL_MANY_PORTS
bool '  Support for sharing serial interrupts' CONFIG_SERIAL_SHARE_IRQ
+   bool '  Disable other interrupts and disable sharing' 
+CONFIG_SERIAL_DISABLE_INTERRUPTS_DONT_SHARE
bool '  Autodetect IRQ on standard ports (unsafe)' CONFIG_SERIAL_DETECT_IRQ
bool '  Support special multiport boards' CONFIG_SERIAL_MULTIPORT
bool '  Support the Bell Technologies HUB6 card' CONFIG_HUB6
diff -urbBd linux.orig/drivers/char/serial.c linux/drivers/char/serial.c
--- linux.orig/drivers/char/serial.cSat Apr 14 05:26:07 2001
+++ linux/drivers/char/serial.c Fri May 18 06:29:10 2001
@@ -1336,8 +1336,13 @@
} else 
handler = rs_interrupt_single;
 
-   retval = request_irq(state->irq, handler, SA_SHIRQ,
-"serial", &IRQ_ports[state->irq]);
+   retval = request_irq(state->irq, handler, 
+#ifdef CONFIG_SERIAL_DISABLE_INTERRUPTS_DONT_SHARE
+SA_INTERRUPT
+#else
+SA_SHIRQ
+#endif
+, "serial", &IRQ_ports[state->irq]);
if (retval) {
if (capable(CAP_SYS_ADMIN)) {
if (info->tty)
@@ -1489,7 +1494,12 @@
if (IRQ_ports[state->irq]) {
free_irq(state->irq, &IRQ_ports[state->irq]);
retval = request_irq(state->irq, rs_interrupt_single,
-SA_SHIRQ, "serial",
+#ifdef CONFIG_SERIAL_DISABLE_INTERRUPTS_DONT_SHARE
+SA_INTERRUPT
+#else
+SA_SHIRQ
+#endif
+, "serial",
 &IRQ_ports[state->irq]);

if (retval)
@@ -2503,8 +2513,13 @@
else
handler = rs_interrupt;
 
-   retval = request_irq(state->irq, handler, SA_SHIRQ,
-"serial", &IRQ_ports[state->irq]);
+   retval = request_irq(state->irq, handler, 
+#ifdef CONFIG_SERIAL_DISABLE_INTERRUPTS_DONT_SHARE
+SA_INTERRUPT
+#else
+SA_SHIRQ
+#endif
+, "serial", &IRQ_ports[state->irq]);
if (retval) {
printk("Couldn't reallocate serial interrupt "
   "driver!!\n");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.5pre3 warning fixes

[Albert D. Cahalan]

Bingner Sam J. Con writes:

> Looks to me like it's adding { and } on each side of the
> "c->devices->prev=d;" statement... so changing from:
> 
> if (c->devices != NULL)
>   c->devices->prev=d;
> 
> to 
> 
> if (c->devices != NULL){
>   c->devices->prev=d;
> }
> 
> I assume the new compiler likes the if to have explicit
> brackets instead of using the next statement...

Maybe one of these will make it happy:

(void)(c->devices && (c->devices->prev=d));

!c->devices ?: (c->devices->prev=d);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Linking

[Keith Owens]

On Mon, 18 Jun 2001 09:29:51 +0530, 
"Anil Kumar" <[EMAIL PROTECTED]> wrote:
>How do i link the kernel functions such as test_ans_set functions with my
>applications.

You don't.  The kernel use the kernel functions, user space
applications use glibc functions, the two do not mix.

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

question about the route command

[Gabriel Rocha]

ok, pardon my ignorance if this has nothing to do with the kernel
proper, but it is something i find very neat on OpenBSD that I would
love to see implemented into linux...it is the change option to route.
Under Obsd I can simply route change ip gateway...i'd like to be able to
do the same if its something easy to implement...ideas? --gabe


-- 

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

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Fri, 18 May 2001, Sasi Peter wrote:
> On Thu, 17 May 2001, Rik van Riel wrote:
> 
> > Or are you just comparing with 2.2 and you'd rather
> > have 2.2 performance? ;)
> 
> Actually, yes. Doing fileserving with Samba, and also using the box
> interactively feels better with 2.2, and also the average TCP througput
> (measured by iptraf) seems higher.

This part is probably mostly due to the inode and dentry
cache balancing being completely broken in current 2.4
kernels. Expect a patch soon (I'm running something really
ugly right now here at home, I'll make something cleaner).

regards,

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

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

Send all your spam to [EMAIL PROTECTED] (spam digging piggy)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: VIA/PDC/Athlon

[Pavel Roskin]

Hello, Zilvinas!

There are utilities that work with PnP BIOS. They are included with
pcmcia-cs (which is weird - it should be a separate package) and called
"lspci" and "setpci". They depend on PnP BIOS support in the kernel
(CONFIG_PNPBIOS).

Dumping your PnP BIOS configuration and checking whether it has changed
after booting to Windows would be more reasonable than checking your PCI
configuration (IMHO).

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

Re: Linux 2.4.4-ac10

[Sasi Peter]

On Thu, 17 May 2001, Rik van Riel wrote:

> Or are you just comparing with 2.2 and you'd rather
> have 2.2 performance? ;)

Actually, yes. Doing fileserving with Samba, and also using the box
interactively feels better with 2.2, and also the average TCP througput
(measured by iptraf) seems higher.

-- 
SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/


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

Linking

[Anil Kumar]

How do i link the kernel functions such as test_ans_set functions with my
applications.
thanks,
anil


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

Question

[C.Praveen]

Hello,

i have a very simple question.
please CC any reply to me, since im not subscribed to the list


On the same processor i have the following code (initially a = 0)

1. write a = 1
2. read b

if an interrupt occurred after line 1 and before line 2, and that ISR
reads the value of a, is there a chance it can see the value of a as 0?
Hope the question isnt too stupid, but the processor can buffer stores to
memory ? (Does it supply the correct value of a to the isr if it does). if
not, mb wont solve the problem i suppose? its meant for other cpus ?

Thanks,

Praveen 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: [QUESTION] "No 100Hz timer" thread - any LKML archive?

[Daniel Phillips]

On Friday 18 May 2001 00:06, Dan Kegel wrote:
> Tomas Telensky ([EMAIL PROTECTED]) wrote:
> > does anybody know about any archive/digest service for this mailing
> > list? Majordomo at vger doesn't support this. Or does anybody of
> > you archive all e-mails?
> > [...]
> See http://marc.theaimsgroup.com/?l=linux-kernel for a good search
> tool. Dunno about raw archives...

It has a "download raw" that's quite unique among web archives in
that it lets you get hold of the unmangled patch.  Though I wish the
headers were included...

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.0, 2.2.18: A critical problem with tty_io.c

[Al Borchers]

Alan Cox wrote:
> It has to be changed, the race is basically unfixable any other way. I didn't
> lightly make that change

I agree.  The patch seems like the correct solution.  What will it take to
get the patch in the 2.4.x kernels?  Do we need someone to go through the serial
drivers and fix their open/close routines to work with this patch?  Peter
and I can take some time to do that--if that would help.

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

Re: LANANA: To Pending Device Number Registrants

[Jonathan Lundell]

At 11:23 PM +0200 2001-05-17, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 15.05.01 in 
>:
>
>>  What about:
>>
>>  1 (network domain). I have two network interfaces that I connect to
>>  two different network segments, eth0 & eth1; they're ifconfig'd to
>>  the appropriate IP and MAC addresses. I really do need to know
>>  physically which (physical) hole to plug my eth0 cable into.
>
>Sorry, the software doesn't know that. Never has, for that matter.

Well, no, it doesn't. That's a problem. Jeff Garzik's ethtool 
extension at least tells me the PCI bus/dev/fcn, though, and from 
that I can write a userland mapping function to the physical 
location. My point, though, is that finding the socket is a real-life 
problem on systems with multiple interfaces. I don't expect the 
kernel to know the physical locations, but the user has to be able to 
get from kernel/ifconfig names (eth#) to sockets, one way or another. 
Support for a uniform means of doing the mapping, even if it needs 
userland help, would be good.

>  > (Extension: same situation, but it's a firewall and I've got 12 ports
>>  to connect.) (Extension #2: if I add a NIC to the system and reboot,
>>  I'd really prefer that the NICs already in use didn't get renumbered.)
>
>Make your config script look at the hardware MAC addresses. Those don't
>change.

They're not necessarily unique, though.

>  > 2 (disk domain). I have multiple spindles on multiple SCSI adapters.
>>  I want to allocate them to more than one RAID0/1/5 set, with the
>>  usual considerations of putting mirrors on different adapters,
>>  spreading my RAID5 drives optimally, ditto stripes. I need (eg) SCSI
>>  paths to config all this, and I further need real physical locations
>>  to identify failed drives that need to be hot-replaced. The mirror
>>  members will move around as drives are replaced and hot spares come
>>  into play.
>
>Use partition UUIDs, or SCSI serial numbers, or whatever. This works
>today.

This pushes the problem back in time: I need to write the UUID, for 
example, at some point. And, with hot-swappable drives, I'm still 
interested in the physical location. I really know know that there's 
a good answer to this problem, especially with FC, but I need to tell 
an operator, "replace this particular physical drive". It doesn't do 
any good to tell the operator the UUID.

>  > Seems like more that merely informational.
>
>The *location*? Nope. Some unique id for the device, if available at all:
>sure.

What good does it do to tell an operator to connect a cable to a MAC 
address? Or to remove a drive having a particular UUID? If it's "mere 
information", it's *necessary* mere information.

>  > (A side observation: PCI or SCSI bus/device/lun/etc paths are not
>>  physical locations; you also need external hardware-specific
>>  knowledge to be able to talk about real physical locations in a way
>>  that does the system operator any good.)
>
>And those you typically do not have.

But (ideally) should.

-- 
/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: newbie problem: compiling kernel 2.4.4, make modules_install , Help please !

[Keith Owens]

On Thu, 17 May 2001 20:50:46 +0200 (CEST), 
Joel Cordonnier <[EMAIL PROTECTED]> wrote:
>It's the first time that i try to compile my own
>kernel. At the moment, I have an old RH 6.1 with a
>2.2.12 kernel.
>- make modules_install ==> PROBLEM !
>FIRST the message say that no argument -F exist for
>the command /sbin/depmod.

Always read Documentation/Changes and check that *all* your utilities
are up to date before working on a new 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: Linux 2.4.4-ac11

[Mads Martin Jørgensen]

* Bill Nottingham <[EMAIL PROTECTED]> [May 17. 2001 18:55]:
> (catching up...)
> 
> Alan Cox ([EMAIL PROTECTED]) said: 
> > 2.4.4-ac9
> ...
> > o   Further tulip updates   (Jeff Garzik)
> ...
> > 2.4.4-ac8
> > o   Tulip driver updates(Jeff Garzik)
> 
> These updates (sorry, haven't tracked down which of the two) conspire to
> break the tulip on my ia64, it's a:

You should try the newest driver from:

http://sourceforge.net/projects/tulip/

-- 
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic and
totally illogic, with just a little bit more effort."
-- A. P. J.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

rtl8139 - kernel 2.4.3

[Ted Gervais]

I get the following when ftping from one workstation to another.
Using kernel 2.4.3 and Redhat7.1:

Assertion failed! tp->tx_info[entry].skb == NULL,8139too.c,rtl8139_start_xmit,line=1676
Assertion failed! tp->tx_info[entry].mapping == 
0,8139too.c,rtl8139_start_xmit,line=1677
Assertion failed! tp->tx_info[entry].skb == NULL,8139too.c,rtl8139_start_xmit,line=1676
Assertion failed! tp->tx_info[entry].mapping == 
0,8139too.c,rtl8139_start_xmit,line=1677
Assertion failed! tp->tx_info[entry].skb == NULL,8139too.c,rtl8139_start_xmit,line=1676
Assertion failed! tp->tx_info[entry].mapping == 
0,8139too.c,rtl8139_start_xmit,line=1677
eth0: Out-of-sync dirty pointer, 456 vs. 462.
Assertion failed! tp->tx_info[entry].skb == NULL,8139too.c,rtl8139_start_xmit,line=1676
Assertion failed! tp->tx_info[entry].mapping == 
0,8139too.c,rtl8139_start_xmit,line=1677
Assertion failed! tp->tx_info[entry].skb == NULL,8139too.c,rtl8139_start_xmit,line=1676
Assertion failed! tp->tx_info[entry].mapping == 
0,8139too.c,rtl8139_start_xmit,line=1677


Is there a fix for this?  Kernel 2.4.4 is worse. It gives me a 'kernel
panic'..  doing the same ftp transfer between workstations.

---
The mosquito is the state bird of New Jersey.
-- Andy Warhol

Ted Gervais <[EMAIL PROTECTED]>
44.135.34.201 linux.ve1drg.ampr.org


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

Re: Linux 2.4.4-ac11

[Bill Nottingham]

(catching up...)

Alan Cox ([EMAIL PROTECTED]) said: 
> 2.4.4-ac9
...
> o Further tulip updates   (Jeff Garzik)
...
> 2.4.4-ac8
> o Tulip driver updates(Jeff Garzik)

These updates (sorry, haven't tracked down which of the two) conspire to
break the tulip on my ia64, it's a:

02:01.0 Ethernet controller: Digital Equipment Corporation DECchip 21041 [Tulip
Pass 3] (rev 21)

What normally happens is that all the TX packets show up
as carrier errors, and no packets are ever recieved.

Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] "No 100Hz timer" thread - any LKML archive?

[Sven Koch]

On Thu, 17 May 2001, Tomas Telensky wrote:

> does anybody know about any archive/digest service for this mailing
> list? Majordomo at vger doesn't support this. Or does anybody of you
> archive all e-mails?
>
> I'm especially interested in the _WHOLE_ thread "No 100Hz timer !" now.
> (but the question is asked in general). If you have the complete thread,
> I would be very glad if you could expose it on WWW for me to download.

I've put my archive-mboxes and a grepmail-result with your thread to
http://ares.sdinet.de/lkml/

Have Fun

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: reading from (rivafb) framebuffer is really slow

[Felix von Leitner]

When benchmarking DirectFB, I found that a typical software alpha
blending rectangle fill is completely dominated (I'm talking 90% of the
CPU cycles here) by the time it takes to read pixels from the
framebuffer.

The pixels are read linearly in chunks of aligned 32-bit words.  It's a
Geforce 2 GTS in 1024x768 with 32-bit color depth using rivafb.  This
looks quite crass to me.  Any ideas?  Maybe rivafb does not initialize
AGP and the card is in PCI mode or something?

Felix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] drivers/char/serial.c bug in ST16C654 detection

[Theodore Tso]

On Wed, May 16, 2001 at 04:12:45PM -0600, Val Henson wrote:
> Anyone know where Ted Tso is?  He hasn't posted in several weeks.
> Alan, will you put this in -ac?  This patch fixes a bug in serial.c
> that causes a crash on machines with a ST16C654.

I'm around, just swamped with a few other things.  Dealing with serial
driver issues is on the top of my to do list

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Kernel bug with UNIX sockets not detecting other end gone?

[David Schwartz]

> Hmm - there's definitely a Linux inconsistency here. With SOCK_DGRAM,
> read() is blocking but write() is giving ECONNRESET.
>
> The ECONNRESET makes sense to me (despite this being a datagram socket),
> because the sockets are anonymous. Once one end goes away, the other end
> is pretty useless.
>
> Cheers
> Chris

One can justify any behavior, since this is a datagram socket but the
kernel does know that it has been 'disconnected'. One can even justify the
inconcsistent behavior -- the write definitely has no place to go (now), but
the read can't be totally sure that there is no possible way anybody could
ever find the other end and write to it.I think it would, however, be
preferable to have it return ECONNRESET in all cases (read, write, and
'select'/'poll' should hit on read and write).

DS

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

Re: Ide Floppy problems

[Mihai Moldovanu]

>> May 17 05:42:20 m kernel: hdd: lost interrupt
>> May 17 05:42:20 m kernel: ide-floppy: CoD != 0 in idefloppy_pc_intr
>> May 17 05:42:20 m kernel: hdd: ATAPI reset complete
>> May 17 05:43:10 m kernel: hdd: lost interrupt
>> May 17 05:43:10 m kernel: ide-floppy: CoD != 0 in idefloppy_pc_intr
>> May 17 05:43:10 m kernel: hdd: ATAPI reset complete
>> After another 1 minute of this repeated messages I push reset .
>> Any ideeas ?
>
> CONFIG_BLK_DEV_IDEFLOPPY=n
> CONFIG_BLK_DEV_IDESCSI=y
> CONFIG_SCSI=y
> CONFIG_BLK_DEV_SD=y
>
> And, your ZIP drive shows up as SCSI disk. This also has the advantage
> that you can use ziptool to write protect / unprotect / eject ZIP
> disks. Ide-floppy never worker properly for me. Ide-scsi has worked
> without problems.


Does not work with SCSI drivers. Same kind of error .

May 18 03:10:02 m kernel: hdd: lost interrupt
May 18 03:10:02 m kernel: ide-scsi: CoD != 0 in idescsi_pc_intr
May 18 03:10:02 m kernel: hdd: ATAPI reset complete
May 18 03:10:02 m kernel: hdd: irq timeout: status=0x80 { Busy }

-- 
Mihai Moldovanu



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

Workaround Found for Re: CD-RW ide-scsi problem presists with 2.4.4 (was Re: Problem with 2.4.1/2.4.3 and CD-RW ide-scsi drive)

[Tim Meushaw]

Thanks to an email I got (hi Thomas!), I was able to use a workaround to
the problem described below.  I don't know if it's the accepted fix or
not, but it worked for me.

What I did was set the DMA mode of the drive differently.  I used the
following hdparm command:
hdparm -d 1 -X 34 /dev/hdd

After running that, I didn't have any problems.  I wasn't able to tell
what the mode was before running that, as I received errors from hdparm
for half the parameters, presumably because of the SCSI emulation
.

I'm no longer subscribed to this list (too much traffic!), but wanted to
report this workaround, and thanks to Thomas Baecker for giving me this
answer when the same thing worked for him.  :-)

Tim

On Sat, Apr 28, 2001 at 02:37:50PM -0400, Tim Meushaw wrote:
> I had received info that this may have been fixed in 2.4.3-ac5.  I
> didn't get the chance to test it there, but I installed 2.4.4 this
> morning.  Alas, I receive exactly the same errors with 2.4.4 as I did
> previously with 2.4.3.
> 
> One thing that did differ, though, shortly after I sent this first
> email, magically the drive started working properly.  I was able to
> mount disks perfectly.  However, I had to reboot for some reason or
> another, and the problem came back and has stayed with me ever since.
> As far as I know I didn't do anything to make it work when it did, it
> just "started working", which isn't an answer I like, but that's all I
> can say :-)
> 
> Tim
> 
> On Wed, Apr 11, 2001 at 10:53:57PM -0400, Tim Meushaw wrote:
> > Hi there.  I just got a new CD-RW drive and am trying to get it working
> > under Linux.  I've got the ide-scsi modules all loaded, but have weird
> > errors when trying to mount a disk.
> > 
> > Here are the messages from "dmesg" that I get when the ide-cd and
> > ide-scsi modules are loaded.  My DVD-ROM is /dev/hdc, and the CD-RW is
> > /dev/hdd (or /dev/sr0):
> > 
> > -
> > hdc: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33)
> > Uniform CD-ROM driver Revision: 3.12
> > ide-cd: ignoring drive hdd
> > scsi0 : SCSI host adapter emulation for IDE ATAPI devices
> >   Vendor: SONY  Model: CD-RW  CRX160ERev: 1.0e
> >   Type:   CD-ROM ANSI SCSI revision: 02
> > Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
> > sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
> > -
> > 
> > So, it looks like the drive is attached to /dev/sr0 properly.  Then, I
> > run "cdrecord -scanbus" to make sure:
> > 
> > -
> > Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling
> > Linux sg driver version: 3.1.17
> > Using libscg version 'schily-0.1'
> > scsibus0:
> > 0,0,0 0) 'SONY' 'CD-RW  CRX160E  ' '1.0e' Removable CD-ROM
> > -
> > 
> > So, it REALLY looks like it's working.  However, here's what I get when
> > I try to mount an ordinary data CD:
> > 
> > -
> > athens:~# mount -t iso9660 /dev/sr0 /cdrw
> > mount: block device /dev/sr0 is write-protected, mounting read-only
> > SCSI cdrom error : host 0 channel 0 id 0 lun 0 return code = 2800
> > [valid=0] Info fld=0x0, Current sd0b:00: sense key Hardware Error
> > Additional sense indicates Logical unit communication CRC error (Ultra-DMA/32)
> >  I/O error: dev 0b:00, sector 64
> > isofs_read_super: bread failed, dev=0b:00, iso_blknum=16, block=32
> > mount: wrong fs type, bad option, bad superblock on /dev/sr0,
> >or too many mounted file systems
> > -
> > 
> > I've tried this with both kernel 2.4.1 and 2.4.3 and have the exact same
> > error.  I've also tried multiple data CDs and have the same messages.
> > The CD-RW is a Sony CRX-160E, plugged in to an Asus A7V motherboard (the
> > PCI bus is described by "lspci" as "VIA Technologies, Inc. VT8363/8365
> > [KT133/KM133 AGP]").  I'm not sure what other information I can provide,
> > but I'll be happy to give anything else that might be needed to help fix
> > this problem.
> > 
> > Thanks a lot!
> > Tim
> > 
> > -- 
> > Timothy A. Meushaw
> > [EMAIL PROTECTED]
> > http://www.pobox.com/~meushaw/
> 
> 
> 
> -- 
> Timothy A. Meushaw
> [EMAIL PROTECTED]
> http://www.pobox.com/~meushaw/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

 PGP signature

Re: eepro100 rev 12 problems

[Ion Badulescu]

On Fri, 18 May 2001, James Fidell wrote:

> > Is this a real card, or is it built-in on the motherboard?
> 
> It's a real card.

All right, that's good to know. Maybe I'll get one for myself, so I can 
test new code on it -- right now I only have rev 9 and earlier cards.

> For various reasons that are far to boring to go into here, I'm not entirely
> free in my choice of card.  What I'll probably do is try to get a rev 8 card
> swapped in for the rev 12 one.  If I can't get a rev 8 card for that machine,
> I'll go with the e100 driver and let you know what happens.

Yes, and do let us know what happens. Whatever the problem is, it wants 
fixing sooner than later.

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

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

Re: Kernel bug with UNIX sockets not detecting other end gone?

[Chris Evans]

On Thu, 17 May 2001, Alan Cox wrote:

> > The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
> > Since the other end is clearly gone, I would expect some sort of error
> > condition. Indeed, FreeBSD gives ECONNRESET.
>
> Since its a datagram socket Im not convinced thats a justifiable assumption.

Hmm - there's definitely a Linux inconsistency here. With SOCK_DGRAM,
read() is blocking but write() is giving ECONNRESET.

The ECONNRESET makes sense to me (despite this being a datagram socket),
because the sockets are anonymous. Once one end goes away, the other end
is pretty useless.

Cheers
Chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: write() writes too many bytes?

[Eric Buddington]

My apologies for bothering the list with this cool-sounding but bogus
problem; I only sent it accidentally (I discovered my mistake while
writing the original) and followed with a retraction which I stupidly
sent to the old rutgers address. Wish I had sent the original there,
too.

I was fooled by characters inserted by emacs when I loaded up the file
to look at it. I loaded it as text, then converted to hex. Emacs had
already added some '^'s to denote escape characters, and left them in.
My mistake.

-Eric

> My program write()s 2- and 4- byte chunks or data to a file (for a WAV
> header). When the data being written contains an 0xff byte, it is
> apparently written to disk as 2 bytes: 0x81ff.

- End forwarded message -
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-ac11

[Alan Cox]

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

 Intermediate diffs are available from
http://www.bzimage.org


2.4.4-ac11
o   Fix hang after "Freeing unused.." on S/390  (Dick Hitt)
o   Fix ramfs accounting bug(Christoph Rohland)
o   Raw HID access interface for USB(Brad Hards)
o   Fix missing release_region on QlogicFAS (Marcus Meissner)
o   Fix missing release region in NCR53c406 code(Marcus Meissner)
o   Make trident use the new pm callbacks   (Pavel Roskin)
o   Fix dmi ident handling  (Arjan van de Ven)
o   dc2xx locking fixes (Greg Kroah-Hartmann)
o   Fix overrun on the acm driver   (Greg Kroah-Hartmann)
o   Sitecom workarounds for mct-u232(Stelian Pop)
o   Makefile fixes  (Al Viro)
o   Make hgafb show logo if non modular only like   (me)
the rest
o   Merge back the invalidate_device changes into   (me)
the new cciss/cpqarray
o   Rio and sx serial driver updates(Rogier Wolff)
o   Add another SB AWE 32 variant to the tables (Jeremy Manson)
o   Fix serial.c warning(Jesper Juhl)
o   Basic maestro dock support  (Ben Pfaff)
o   Add defines for testing prefetch(Arjan van de Ven)
o   Protect nls.h from repeat include   (Anton Altaparmakov)
o   Clean up resource handling in esssolo1  (Marcus Meissner)
o   Fix mysnc on /dev/fb(Andrea Arcangeli)
o   Further IBM token ring updates  (Mike Phillips)
o   Fix usermode Linux makefile problem (Andrew Morton)
o   Merge first block of LVM changes(Heinz & others)
o   Forward port 2.2 syncppp flags features (Paul Fulghum)
o   Merge lp486e driver for 2.4 (Andries Brouwer)
| Experimental...
o   Merge new cmpci driver  (ChenLi Tien)
o   & remove 2.2 back compat gunge, modem gunge (me)
o   Update frame buffer project/mailing list data   (Geert Uytterhoeven)
o   Fix m68k bitops (Roman Zippel)
o   Add w83877f watchdog driver (Scott Jennings)
o   Merge A2232 serial driver   (Enver Haase)
o   Fix wrong memory free in isdn_ppp   (Christopher Kanaan)

2.4.4-ac10
o   Move cs46xx docs into the right spot(Arjan van de Ven)
o   Merge Linus 2.4.5pre3
- switch to Linus page fault race fixes
- switch to Linus arch/ppc
- merged serial driver cli fixes but also
  added an extra missing moxa check
- used -ac better version of comx fix
- used -ac better version of scsi fix
- now 2.4.5pre vm seems sane dump other vmscan
  experiments
[not merged; rage-xl code]
o   

2.4.4-ac9
o   Clean up x86isms from the UML code  (Chris Emerson)
o   Remove un-needed UML flag,fix hang under load   (Jeff Dike)
o   Fix attach race in UML  (Jeff Dike)
o   Fix warnings, clean up cpp abuses in UML(Roman Zippel)
o   Remove -D__KERNEL__ from user space of UML  (Roman Zippel)
o   Add NCR53c700 and 53c700/66 driver  (James Bottomley)
|For NCR Dual 700 microchannel card
o   Alpha semaphore updates (Ivan Kokshaysky)
p   Fix ibmtr build a bit   (Andrzej Krzysztofowicz)
o   Tidy sysrq-t output (Russell King)
o   Fix miata halt to SRM   (Tom Vier)
o   Fix aging on buffer cache pages (Marcelo Tosatti)
o   Fix looping behaviour on failing memory (Marcelo Tosatti)
allocations
o   Handle the PIIX4 on the new intel 82801BAM  (Tim Raymond)
o   Fix user visible -ENOIOCTLCMD returns   (Shane Wegner)
o   Fix startech uart detection problem (Val Henson)
o   Further tulip updates   (Jeff Garzik)
o   Revert hpt366 patch

2.4.4-ac8
o   Prefetch constant copy_to_user data (Arjan van de Ven)
o   Update cpqarray driver - use pci dma api(Charles White)
o   Update cciss driver - use pci dma api   (Charles White)
o   Enable compiled in synclink driver  (Paul Fulghum)
o   Fix plip section conflict   (Keith Owens)
o   Tulip driver updates(Jeff Garzik)
o   Frame buffer logo updates   (Geert Uytterhoeven)
o   Update __initdata documentation (Ingo Oeser)
o   Linearize sunrpc buffers using GFP_KER

Re: eepro100 rev 12 problems

[James Fidell]

Quoting Ion Badulescu ([EMAIL PROTECTED]):
> On Thu, 17 May 2001 16:59:04 +0100, James Fidell <[EMAIL PROTECTED]> wrote:
> > I have two eepro100 interfaces in a machine, one rev 8, which works just
> > fine, and another rev 12, which appears as a device when the kernel boots
> > and can be configured with an IP address etc., but I can't get any data
> > in or out of it.  All the other hardware looks like it's working fine and
> > all my rev 8 cards work, so I'm led to ask, are there any known problems
> > with eepro100 rev 12 cards under 2.2.18?
> 
> Is this a real card, or is it built-in on the motherboard?

It's a real card.

> I don't think eepro100 has got much testing with rev > 9, though it should
> have worked. All eepro100 chips are supposed to be backwards compatible with
> the 82557, but maybe our driver initializes some registers in a way that
> upsets newer chips. Not having docs for the newer chips doesn't help,
> either...
> 
> Intel's own e100 driver probably works, their code does things differently if
> rev >= 12 (what they call the D102 revision). Give it a spin, I guess.

For various reasons that are far to boring to go into here, I'm not entirely
free in my choice of card.  What I'll probably do is try to get a rev 8 card
swapped in for the rev 12 one.  If I can't get a rev 8 card for that machine,
I'll go with the e100 driver and let you know what happens.

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

Re: Linux-Kernel Archive: ide-floppy

[Alan Cox]

> > If people can pin down cases where -ac fails and the main tree doesnt that
> > would be good. There shouldnt be any differences that matter but apparently there
> > are
> 
> Thump "StoatWblr" about the ali crash...

I have talked to him about it - it doesnt involve ide-floppy or ide tho

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

Re: [PATCH] drivers/char/serial.c bug in ST16C654 detection

[Val Henson]

On Thu, May 17, 2001 at 09:49:11AM -0400, Stuart MacDonald wrote:

> Are you using the serial console though? That seems to be
> implied by your problem, but I just want to check.

Yes, I have serial console only on this board.

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

Re: Linux-Kernel Archive: ide-floppy

[Andre Hedrick]

On Thu, 17 May 2001, Alan Cox wrote:

> Date: Thu, 17 May 2001 23:58:52 +0100 (BST)
> 
> > As for AC patches have not gotten around to messing with, but I have a few
> > reported cases where stock or pre-patched linus-trees work and
> > pre-patched ac-trees fail...
> 
> If people can pin down cases where -ac fails and the main tree doesnt that
> would be good. There shouldnt be any differences that matter but apparently there
> are

Thump "StoatWblr" about the ali crash...

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com

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

Re: Kernel bug with UNIX sockets not detecting other end gone?

[Alan Cox]

> The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
> Since the other end is clearly gone, I would expect some sort of error
> condition. Indeed, FreeBSD gives ECONNRESET.

Since its a datagram socket Im not convinced thats a justifiable assumption.

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: Linux-Kernel Archive: ide-floppy

[Alan Cox]

> As for AC patches have not gotten around to messing with, but I have a few
> reported cases where stock or pre-patched linus-trees work and
> pre-patched ac-trees fail...

If people can pin down cases where -ac fails and the main tree doesnt that
would be good. There shouldnt be any differences that matter but apparently there
are
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Kernel bug with UNIX sockets not detecting other end gone?

[Chris Evans]

Hi,

I wonder if the following is a bug? It certainly differs from FreeBSD 4.2
behaviour, which gives the behaviour I would expect.

The following program blocks indefinitely on Linux (2.2, 2.4 not tested).
Since the other end is clearly gone, I would expect some sort of error
condition. Indeed, FreeBSD gives ECONNRESET.

#include 
#include 
#include 
#include 

int
main(int argc, const char* argv[])
{
  int the_sockets[2];
  int retval;
  char the_char;
  int opt = 1;

  retval = socketpair(PF_UNIX, SOCK_DGRAM, 0, the_sockets);
  if (retval != 0)
  {
perror("socketpair");
exit(1);
  }
  close(the_sockets[0]);
  /* Linux (2.2) blocks here; FreeBSD does not */
  retval = read(the_sockets[1], &the_char, sizeof(the_char));
}

Cheers
Chris

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

Re: 2.2.xx ? messages related to parport printer ?

[Tim Waugh]

On Thu, May 10, 2001 at 05:12:33PM +0200, Jean-Luc Coulon wrote:

> >Huh.  Does it do the same thing every time you load parport_probe?
> >Does it always get truncated in the same place?
> 
> Yes ! :-/

Nothing really uses that information in 2.2 anyway, so it's harmless
at least.  It's probably a timing thing; take a look at the
differences between the 2.2 and 2.4 code for that.

Tim.
*/

 PGP signature

Re: Linux-Kernel Archive: ide-floppy

[Andre Hedrick]

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.2/0082.html

> Whenever I boot (2.4.4-ac6) I get this error message if there is a zip
> disk in the drive.
> 
> hdb: 98288kB, 196576 blocks, 512 sector size, hdb: 98304kB, 96/64/32 CHS,
> 4096 kBps, 512 sector size, 2941 rpm ide-floppy: hdb: I/O error, pc = 5a,
> key = 5, asc = 24, ascq = 0
> 
> The drive seems to work fine for everything except writing large files
> (>500k) - umount hangs indefinitely. This has been a problem for all the
> kernels I've used since I got the drive (2.2.18, 2.2.20, 2.4.0->2.4.4-ac6
> series). The ide-floppy support is compiled into the kernel but I've had
> similar problems when using it as a module. The disks work perfectly on a
> windows box and even worked fine when I was using the drive with windows.
> 
> Can anyone shed any light on this for me?

Linux p6dnf 2.4.5-pre2 #1 SMP Thu May 17 14:46:10 PDT 2001 i686 unknown

Well I dusted of the device an chucked it into a box via handy-dandy
hotswap shuttle and..

May 17 15:29:59
 p6dnf kernel: hdl: 98304kB, 196608 blocks, 512 sector size,
May 17 15:29:59
 p6dnf kernel: hdl: 98304kB, 32/64/96 CHS, 4096 kBps, 512 sector size, 2941 rpm

Pop the module out and back in and ...

May 17 15:46:58
 p6dnf kernel: hdl: 98304kB, 32/64/96 CHS, 4096 kBps, 512 sector size, 2941 rpm

As for AC patches have not gotten around to messing with, but I have a few
reported cases where stock or pre-patched linus-trees work and
pre-patched ac-trees fail...

So you got me on that one.

--
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com






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

2.2, 2.4 bug in sock_no_fcntl()/F_SETOWN? (fwd)

[Chris Evans]

Resend (no response first time)

-- Forwarded message --
Date: Wed, 24 Jan 2001 21:09:09 + (GMT)
From: Chris Evans <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: 2.2, 2.4 bug in sock_no_fcntl()/F_SETOWN?


Hi,

Looking at the code for sock_no_fcntl() in net/core.c, I cannot specify
"0" as a value for F_SETOWN, unless I'm the superuser. I believe this to
be a bug, it stops de-registering an interest in SIGURG signals. Let me
know if you want a patch.

Cheers
Chris


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LANANA: To Pending Device Number Registrants

[Johannes Erdfelt]

On Thu, May 17, 2001, Kai Henningsen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 15.05.01 in 
><[EMAIL PROTECTED]>:
> 
> > I had always made the assumption that sockets were created because you
> > couldn't easily map IPv4 semantics onto filesystems. It's unreasonable
> > to have a file for every possible IP address/port you can communicate
> > with.
> 
> Not at all. What is unreasonable is douing a "ls" on the directory in  
> question.
> 
> Big deal; make it mode d--x--x--x. Problem solved.
> 
> And I'm pretty certain stuff like that *has* been done - wasn't there a  
> ftp file system where you could "ls /mountpoint/ftp.kernel.org/pub/linux"?

I think this is the difference between reasonable and unreasonable.

I'm sure it could be done, but should it?

JE

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

Re: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (H. Peter Anvin)  wrote on 16.05.01 in 
<[EMAIL PROTECTED]>:

> At some point something talks to the device -- in this case, it's the
> SCSI layer.  Follow the interfaces in the kernel and it becomes obvious.

rc = sys_iskind(int filehandle, const char *driverkind)

rc = 0 or Esomething

Think of it as a generalization of isatty(). Maybe

#define isatty(f) sys_iskind(f, "tty")

:-;

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Richard Gooch)  wrote on 16.05.01 in 
<[EMAIL PROTECTED]>:

> H. Peter Anvin writes:
> > Richard Gooch wrote:
> > >
> > > H. Peter Anvin writes:
> > > > Richard Gooch wrote:
> > > > > Argh! What I wrote in text is what I meant to say. The code didn't
> > > > > match. No wonder people seemed to be missing the point. So the line
> > > > > of code I actually meant was:
> > > > > if (strcmp (buffer + len - 3, "/cd") != 0) {
> > > >
> > > > This is still a really bad idea.  You don't want to tie this kind of
> > > > things to the name.
> > >
> > > Why do you think it's a bad idea?
> >
> > Because you are now, once again, tying two things that are
> > completely and utterly unrelated: device classification and device
> > name.  It breaks every time someone comes out with a new device
> > which is "kind of like an old device, but not really," like
> > CD-writers (which was kind-of-like WORM, kind-of-like CD-ROM) and
> > DVD (kind-of-like CD)...
>
> But all devices which export a CD-ROM interface will do so. So the
> device node that is associated with the CD-ROM driver will export
> CD-ROM semantics, and the trailing name will be "/cd".

Uh, how do they have the filename end in more than one device type suffix  
at the same time?

That was the point, remember. You're trying to find out about a device on  
the end of your file handle, and that device *does* match more than one of  
these.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Jonathan Lundell)  wrote on 15.05.01 in 
:

> What about:
>
> 1 (network domain). I have two network interfaces that I connect to
> two different network segments, eth0 & eth1; they're ifconfig'd to
> the appropriate IP and MAC addresses. I really do need to know
> physically which (physical) hole to plug my eth0 cable into.

Sorry, the software doesn't know that. Never has, for that matter.

> (Extension: same situation, but it's a firewall and I've got 12 ports
> to connect.) (Extension #2: if I add a NIC to the system and reboot,
> I'd really prefer that the NICs already in use didn't get renumbered.)

Make your config script look at the hardware MAC addresses. Those don't  
change.

> 2 (disk domain). I have multiple spindles on multiple SCSI adapters.
> I want to allocate them to more than one RAID0/1/5 set, with the
> usual considerations of putting mirrors on different adapters,
> spreading my RAID5 drives optimally, ditto stripes. I need (eg) SCSI
> paths to config all this, and I further need real physical locations
> to identify failed drives that need to be hot-replaced. The mirror
> members will move around as drives are replaced and hot spares come
> into play.

Use partition UUIDs, or SCSI serial numbers, or whatever. This works  
today.

> Seems like more that merely informational.

The *location*? Nope. Some unique id for the device, if available at all:  
sure.

> (A side observation: PCI or SCSI bus/device/lun/etc paths are not
> physical locations; you also need external hardware-specific
> knowledge to be able to talk about real physical locations in a way
> that does the system operator any good.)

And those you typically do not have.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 15.05.01 in 
<[EMAIL PROTECTED]>:

> They might also be exactly the same channel, except with certain magic
> bits set. The example peter gave was fine: tty devices could very usefully
> be opened with something like
>
>   fd = open("/dev/tty00/nonblock,9600,n8", O_RDWR);
>
> where we actually open up exactly the same channel as if we opened up
> /dev/cua00, we just set the speed etc at the same time. Which makes things
> a hell of a lot more readable, AND they are again easily done from
> scripts. The above is exactly the kind of thing that UNIX has not done
> well, and some others have done better (let's face it, even _DOS_ did it
> better, for chrissake! Those callout devices and those ioctl's are a pain
> in the ass, for no really good reason).

Umm ... where to begin.

1. No, DOS didn't do it better - DOS devices were mostly a bad copy of  
Xenix devices.

2. DOS definitely didn't do it better for serial ports. Serial ports are  
the single most broken devices that DOS supports by default, so much so  
that literally *no* serious program that needed the serial ports used the  
built-in driver. Only toy programs did that. Because those drivers weren't  
anything but toys themselves.

I know this the hard way. I used serial ports under DOS for something like  
ten years.

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LANANA: To Pending Device Number Registrants

[Kai Henningsen]

[EMAIL PROTECTED] (Johannes Erdfelt)  wrote on 15.05.01 in 
<[EMAIL PROTECTED]>:

> I had always made the assumption that sockets were created because you
> couldn't easily map IPv4 semantics onto filesystems. It's unreasonable
> to have a file for every possible IP address/port you can communicate
> with.

Not at all. What is unreasonable is douing a "ls" on the directory in  
question.

Big deal; make it mode d--x--x--x. Problem solved.

And I'm pretty certain stuff like that *has* been done - wasn't there a  
ftp file system where you could "ls /mountpoint/ftp.kernel.org/pub/linux"?

MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: mm/memory.c: Missing pte_mkyoung() on mk_pte() calls?

[Marcelo Tosatti]

Two seconds after I sent the message Benjamin told me on IRC that
PAGE_ACCESSED is included in the default page protections... duh. 


On Thu, 17 May 2001, Marcelo Tosatti wrote:

> 
> Linus,
> 
> I was looking at mm/memory.c (2.4), and I've noticed that we don't call
> pte_mkyoung() on newly created pte's for most of the fault paths.
> break_cow(), for example:
> 
>  establish_pte(vma, address, page_table, pte_mkwrite(pte_mkdirty(mk_pte(new_page, v 
>ma->vm_page_prot;
> 
> Is there any reason why we don't set the young bit on such places ?
> 
> I don't think that the window between the pte creation and the actual
> access of the pte by the process is always big enough to avoid kswapd (or
> other task trying to free memory) from ripping a created pte. 
> 
> 
> 
> 

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

mm/memory.c: Missing pte_mkyoung() on mk_pte() calls?

[Marcelo Tosatti]

Linus,

I was looking at mm/memory.c (2.4), and I've noticed that we don't call
pte_mkyoung() on newly created pte's for most of the fault paths.
break_cow(), for example:

 establish_pte(vma, address, page_table, pte_mkwrite(pte_mkdirty(mk_pte(new_page, v 
ma->vm_page_prot;

Is there any reason why we don't set the young bit on such places ?

I don't think that the window between the pte creation and the actual
access of the pte by the process is always big enough to avoid kswapd (or
other task trying to free memory) from ripping a created pte. 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-ac10 IDE Floppy Still hangs

[Mihai Moldovanu]

Ok . There still is a problem even in 2.4.4-ac10 with IDE FLoppy .
Here is what i did and errors i got .

[root@m /mnt]# mount /dev/hdd4 /mnt/zip
ide-floppy: hdd: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
ide-floppy: hdd: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0
[root@m /mnt]# mkdir /mnt/zip/test
[root@m /mnt]# sync
( at this point system seems to freeze, but after aprox 1 minute it recovers )
hdd: lost interrupt
ide-floppy: CoD != 0 in idefloppy_pc_intr
hdd: ATAPI reset complete
[root@m /mnt]#

This is my system configuration:

[root@m /mnt]# uname -a
Linux m 2.4.4-ac10 #1 Fri May 18 00:40:46 EEST 2001 i686 unknown


May 18 00:53:41 m kernel: ide: Assuming 33MHz system bus speed for PIO
modes; override with idebus=xx
May 18 00:53:41 m kernel: VP_IDE: IDE controller on PCI bus 00 dev 39
May 18 00:53:41 m kernel: VP_IDE: chipset revision 6
May 18 00:53:41 m kernel: VP_IDE: not 100%% native mode: will probe irqs later
May 18 00:53:41 m kernel: ide: Assuming 33MHz system bus speed for PIO
modes; override with idebus=xx
May 18 00:53:41 m kernel: VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100
controller on pci00:07.1
May 18 00:53:41 m kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS settings:
hda:DMA, hdb:pio
May 18 00:53:41 m kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS settings:
hdc:DMA, hdd:pio
May 18 00:53:41 m kernel: hda: IBM-DTLA-307030, ATA DISK drive
May 18 00:53:41 m kernel: hdc: Pioneer DVD-ROM ATAPIModel DVD-114 0124,
ATAPI CD/DVD-ROM drive
May 18 00:53:41 m kernel: hdd: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive
May 18 00:53:41 m kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
May 18 00:53:41 m kernel: ide1 at 0x170-0x177,0x376 on irq 15
May 18 00:53:41 m kernel: hda: 60036480 sectors (30739 MB) w/1916KiB Cache,
CHS=29314/64/32, UDMA(100)
May 18 00:53:41 m kernel: hdc: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33)
May 18 00:53:41 m kernel: Uniform CD-ROM driver Revision: 3.12
May 18 00:53:41 m kernel: hdd: 98304kB, 196608 blocks, 512 sector size,
May 18 00:53:41 m kernel: hdd: 98304kB, 96/64/32 CHS, 4096 kBps, 512 sector
size, 2941 rpm
May 18 00:53:41 m kernel: ide-floppy: hdd: I/O error, pc = 5a, key =  5, asc
= 24, ascq =  0


Do you have any suggestions ?

-- 
TFM Group Romania , Linux division

Mihai Moldovanu


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

8139too on 2.2.19 doesn't close file descriptors

[Santiago Garcia Mantinan]

Hi!

I was tracking down a problem with Debian installation freezing when doing
the ifconfig of the 8139too driver on 2.2.19 kernel, and found that this was
caused by 8139too for 2.2.19 not closing it's file descriptors.

The original code by Jeff for the 2.4 series is ok, and searching for the
cause of the problem I have found a difference in the way rtl8139_thread
exits on both versions:

2.2 version:
up (&tp->thr_exited);
return 0;

2.4 version:
up_and_exit (&tp->thr_exited, 0);

I think the problem must be there, not doing the do_exit on the 2.2 version,
but I may be wrong, can anybody look this up?

Thanks in advance!

Regards...
-- 
Manty/BestiaTester -> http://manty.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] "No 100Hz timer" thread - any LKML archive?

[Dan Kegel]

Tomas Telensky ([EMAIL PROTECTED]) wrote:
> does anybody know about any archive/digest service for this mailing 
> list? Majordomo at vger doesn't support this. Or does anybody of you 
> archive all e-mails? 
> 
> I'm especially interested in the _WHOLE_ thread "No 100Hz timer !" now. 
> (but the question is asked in general). If you have the complete thread, 
> I would be very glad if you could expose it on WWW for me to download. 
> 
> I've met different better or worse http interfaces to archives 
> (included www.mail-archive.com). But I'm not satisfied with them - no 
> header's, I must wget... I want to have a folder of e-mails and sort 
> them by threads in mutt - this is only possible when headers are 
> preserved. 

See http://marc.theaimsgroup.com/?l=linux-kernel for a good search tool.
Dunno about raw archives...

- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: oops in 2.4.4-ac9 (mm/slab.c)

[Andreas Franck]

Alan Cox wrote: 

> Its a deliberate debugging trap.
>
> > #if DEBUG
> > if (cachep->flags & SLAB_POISON)
> > if (kmem_check_poison_obj(cachep, objp))
> > BUG();
> > ^^ This one is triggered
>
> Someone freed memory and then scribbled on it.
>
> The first thing useful here is to know which drivers you were using shortly
> before the oops

Sorry, I really can't reproduce it; as I said, it was nothing unusual I did 
(with respect to loaded drivers, which I always have quite a lot of), and it 
happened while doing some editing in vi, which surely doesn't have any bad 
impact, I hope dearly :-)

But it might as well have been some cron job or so, I'll try to check better 
when this happens again. Any more debugging hints you could give me?

Mike Galbraith wrote:
> blogd?

It's SuSE-specific I think, something to log boot messages to a console. 
This SHOULD have finished at this point, however - it's only needed during 
the boot process, so I don't know why this is there... 

> In any case, one thing you can do is to disable the BUG() and
> see if whoever scribbled on the freed area has a reference to
> it still and trips over the damage poison or the new owner did
> to what he thinks is his data.

Can you explain that in more detail, what I should do and what is expected to 
happen then?

Greetings,
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LANANA: To Pending Device Number Registrants

[Oliver Neukum]

On Thursday, 17. May 2001 18:58, Tim Jansen wrote:
> On Thursday 17 May 2001 08:43, Thomas Sailer wrote:
> > Cheap USB devices (and sometimes even expensive ones)
> > do not have serial numbers or other unique identifiers.
> > Therefore some sort of topology based addressing scheme
> > has to be used in that case.
>
> No, there is another addressing scheme that can be for devices without
> serial number: the vendor and product ids. Most people do not have two
> devices of the same kind, so you often do not need the topology at all.

We need to handle the case, even if it is rare. Thus the code must be there. 
If it is there we may as well use it.

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

Re: Linux 2.4.4-ac10: Oops

[Alan Cox]

> SCSI subsystem driver Revision: 1.00
> PCI: Found IRQ 11 for device 00:0b.0
> Unable to handle kernel NULL pointer dereference at virtual address 000
> printing eip:

What scsi drivers do you have and which are on IRQ 11
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-Kernel Archive: ATA overlap/queuing support ?

[Jens Axboe]

On Thu, May 17 2001, Andre Hedrick wrote:
> ATA-overlap or ATAPI-overlap?  The later is known as DSC based on
> SFF-8020/8070/8090, I have forgotten where it is located but I have the
> docs, and it is supported in ide-floppy and ide-tape.

And ide-cd

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

Re: VIA/PDC/Athlon

[Alan Cox]

> Ummm... Here's stripped dmesg of both kernels... Is this compiler thingie or
> Athlon optimizations?

Neither by the look of it

> Notice also different detected PDC20265 BIOS settings! So 2.4.4-ac9 detects
> those BIOS settings correctly and 2.4.2-2 doesn't. That's probably reason
> why 2.4.2-2 works?

Could be.

> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

CRC errors are cable errors so that bit is reasonable in itself


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

Re: Linux-Kernel Archive: ATA overlap/queuing support ?

[Andre Hedrick]

Is there support in linux for ATA overlap/queuing ?

It should ( among other things ) improve concurent performance
of two devices on the same channel.

--
David Balazic
--

> http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.2/0022.html

No, queuing is broken and requires a special host to do the auto-polling.
Right now only HighPoint has a host that will perform that operation.

Also it requires TFAM and that will not be include until 2.5.

ATA-overlap or ATAPI-overlap?  The later is known as DSC based on
SFF-8020/8070/8090, I have forgotten where it is located but I have the
docs, and it is supported in ide-floppy and ide-tape.

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com

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

Re: [PATCH] 2.4.5pre3 warning fixes

[Alan Cox]

> if (c->devices != NULL){
>   c->devices->prev=d;
> }
> 
> I assume the new compiler likes the if to have explicit brackets instead of
> using the next statement...

Then its not a C compiler
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.0, 2.2.18: A critical problem with tty_io.c

[Alan Cox]

> Ted can you get this patch in the kernel or ban it as interface breaking
> heresy?  It would be much nicer for us device driver writers to have just
> one interface to support.

It has to be changed, the race is basically unfixable any other way. I didn't
lightly make that change

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

[QUESTION] "No 100Hz timer" thread - any LKML archive?

[Tomas Telensky]

Hi,
does anybody know about any archive/digest service for this mailing
list? Majordomo at vger doesn't support this. Or does anybody of you
archive all e-mails?

I'm especially interested in the _WHOLE_ thread "No 100Hz timer !" now.
(but the question is asked in general). If you have the complete thread,
I would be very glad if you could expose it on WWW for me to download.

I've met different better or worse http interfaces to archives
(included www.mail-archive.com). But I'm not satisfied with them - no
header's, I must wget... I want to have a folder of e-mails and sort
them by threads in mutt - this is only possible when headers are
preserved.

Thank you

Tomas



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.5pre3 warning fixes -- fixed

[Rich Baum]

In my previous patch I got  drivers/i2c/i2c-core.c confused with 
drivers/i2o/i2o_core.c  i2o_core.c did not have a warning at that line.  
Also, Jeff Garzik suggested I change the fixes for labels at the end of 
compound statements.  It also includes Petr 
Vandrovec's patch to rwsem.h so that 2.4.5preX would compile under gcc 3.0 
snapshots. Here is the new patch.

diff -urN -X /linux/dontdiff linux/arch/i386/math-emu/fpu_trig.c 
rb/arch/i386/math-emu/fpu_trig.c
--- linux/arch/i386/math-emu/fpu_trig.c Sat Apr 28 18:13:25 2001
+++ rb/arch/i386/math-emu/fpu_trig.cThu May 17 15:38:40 2001
@@ -1543,6 +1543,7 @@
  EXCEPTION(EX_INTERNAL | 0x116);
  return;
 #endif /* PARANOID */
+ break;
}
 }
   else if ( (st0_tag == TAG_Valid) || (st0_tag == TW_Denormal) )
diff -urN -X /linux/dontdiff linux/drivers/atm/fore200e.c 
rb/drivers/atm/fore200e.c
--- linux/drivers/atm/fore200e.cFri Feb  9 14:30:22 2001
+++ rb/drivers/atm/fore200e.c   Thu May 17 15:39:17 2001
@@ -439,6 +439,7 @@
 
 case FORE200E_STATE_BLANK:
/* nothing to do for that state */
+   break;
 }
 }
 
diff -urN -X /linux/dontdiff linux/drivers/cdrom/sbpcd.c 
rb/drivers/cdrom/sbpcd.c
--- linux/drivers/cdrom/sbpcd.c Sat Apr 28 18:13:35 2001
+++ rb/drivers/cdrom/sbpcd.cTue May 15 21:39:47 2001
@@ -1118,7 +1118,7 @@
return (0);
 }
 /*==*
/
-#endif 0
+#endif /* 0 */
 /*==*
/
 static int ResponseInfo(void)
 {
diff -urN -X /linux/dontdiff linux/drivers/i2o/i2o_lan.c 
rb/drivers/i2o/i2o_lan.c
--- linux/drivers/i2o/i2o_lan.c Fri Feb  9 14:30:23 2001
+++ rb/drivers/i2o/i2o_lan.cTue May 15 21:38:19 2001
@@ -938,7 +938,7 @@
spin_unlock_irq(&priv->tx_lock);
return 0;
 }
-#endif CONFIG_NET_FC
+#endif /* CONFIG_NET_FC */
 
 /*
  * i2o_lan_packet_send(): Send a packet as is, including the MAC header.
diff -urN -X /linux/dontdiff linux/drivers/media/video/tuner.c 
rb/drivers/media/video/tuner.c
--- linux/drivers/media/video/tuner.c   Mon Feb 19 17:43:36 2001
+++ rb/drivers/media/video/tuner.c  Thu May 17 15:39:50 2001
@@ -558,6 +558,7 @@
 #endif
default:
/* nothing */
+   break;
}

return 0;
diff -urN -X /linux/dontdiff linux/drivers/net/tokenring/ibmtr.c 
rb/drivers/net/tokenring/ibmtr.c
--- linux/drivers/net/tokenring/ibmtr.c Tue Mar 20 15:05:00 2001
+++ rb/drivers/net/tokenring/ibmtr.cThu May 17 15:40:19 2001
@@ -1186,6 +1186,7 @@
isa_writeb(~SRB_RESP_INT, ti->mmio + ACA_OFFSET + 
ACA_RESET + ISRP_ODD);
 
  skip_reset:
+   break;
} /* SRB response */
 
if (status & ASB_FREE_INT) { /* ASB response */
diff -urN -X /linux/dontdiff linux/drivers/net/wan/hdlc.c 
rb/drivers/net/wan/hdlc.c
--- linux/drivers/net/wan/hdlc.cSat Apr 28 18:13:46 2001
+++ rb/drivers/net/wan/hdlc.c   Thu May 17 15:41:50 2001
@@ -1082,7 +1082,9 @@
}
break;
 
-   default:/* to be defined */
+   default:
+   /* to be defined */
+   break;
}
 
dev_kfree_skb(skb);
diff -urN -X /linux/dontdiff linux/drivers/net/wan/sdla_fr.c 
rb/drivers/net/wan/sdla_fr.c
--- linux/drivers/net/wan/sdla_fr.c Sat Apr 28 18:13:46 2001
+++ rb/drivers/net/wan/sdla_fr.cThu May 17 15:42:34 2001
@@ -4435,7 +4435,8 @@
trigger_fr_poll(dev);

break;
-   default:  // ARP's and RARP's -- Shouldn't happen.
+   default:
+   break;  // ARP's and RARP's -- Shouldn't happen.
}
 
return 0;   
diff -urN -X /linux/dontdiff linux/drivers/net/wan/sdla_x25.c 
rb/drivers/net/wan/sdla_x25.c
--- linux/drivers/net/wan/sdla_x25.cSat Apr 28 18:13:47 2001
+++ rb/drivers/net/wan/sdla_x25.c   Tue May 15 21:40:42 2001
@@ -3108,7 +3108,7 @@
case 0x08:  /* modem failure */
 #ifndef MODEM_NOT_LOG
printk(KERN_INFO "%s: modem failure!\n", card->devname);
-#endif MODEM_NOT_LOG
+#endif /* MODEM_NOT_LOG */
api_oob_event(card,mb);
break;
 
diff -urN -X /linux/dontdiff linux/drivers/scsi/NCR53c406a.c 
rb/drivers/scsi/NCR53c406a.c
--- linux/drivers/scsi/NCR53c406a.c Fri Mar  2 14:12:11 2001
+++ rb/drivers/scsi/NCR53c406a.cTue May 15 21:47:25 2001
@@ -221,7 +221,7 @@
 (void *)0xc8000
 };
 #define ADDRESS_COUNT (sizeof( addresses ) / sizeof( unsigned ))
-#endif USE_BIOS
+#endif /* USE_BIOS */
   
 /* possible i/o port addresses */
 static unsigned short ports[] =
@@ -244,7 +244,7 @@
 { "Copyright (C) Acculogic, Inc.\r\n2.8M Diskette Extension Bios ver 
4.04.0

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Thu, 17 May 2001, Mike Galbraith wrote:

> > Has anyone benched 2.4.5pre3 vs 2.4.4 vs. ?
> 
> Only doing parallel kernel builds.  Heavy load throughput is up,
> but it swaps too heavily.  It's a little too conservative about
> releasing cache now imho. (keeping about double what it should be
> with this load.. easily [thump] tweaked;)

"about double what it should be"

That's an interesting statement, unless you have some
arguments to define exactly how much cache the system
should keep.

Or are you just comparing with 2.2 and you'd rather
have 2.2 performance? ;)

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

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

Send all your spam to [EMAIL PROTECTED] (spam digging piggy)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] new version of singlecopy pipe

[Manfred Spraul]

"David S. Miller" wrote:
> 
> J . A . Magallon writes:
>  > > What platform?
> 
>  > Any more info ?
> 
> No, I thought it might be some cache flushing issue
> on a non-x86 machine.
> 
I found the problem: 
I sent out the old patch :-(

Attached is the correct version of patch-copy_user_user.

--
Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 4
//  EXTRAVERSION = -ac8
--- 2.4/kernel/ptrace.c Sat Mar 31 21:49:29 2001
+++ build-2.4/kernel/ptrace.c   Thu May 17 19:43:09 2001
@@ -19,13 +19,14 @@
 /*
  * Access another process' address space, one page at a time.
  */
-static int access_one_page(struct mm_struct * mm, struct vm_area_struct * vma, 
unsigned long addr, void *buf, int len, int write)
+static int access_one_page(struct mm_struct * mm, struct vm_area_struct * vma, 
+unsigned long addr, void *buf, size_t len, int write)
 {
pgd_t * pgdir;
pmd_t * pgmiddle;
pte_t * pgtable;
char *maddr; 
struct page *page;
+   int i;
 
 repeat:
spin_lock(&mm->page_table_lock);
@@ -50,7 +51,7 @@
if (page != ZERO_PAGE(addr) || write) {
if ((!VALID_PAGE(page)) || PageReserved(page)) {
spin_unlock(&mm->page_table_lock);
-   return 0;
+   return OTHER_EFAULT;
}
}
get_page(page);
@@ -59,38 +60,40 @@
 
if (write) {
maddr = kmap(page);
-   memcpy(maddr + (addr & ~PAGE_MASK), buf, len);
+   i = copy_from_user(maddr + (addr & ~PAGE_MASK), buf, len);
flush_page_to_ram(page);
flush_icache_page(vma, page);
kunmap(page);
} else {
maddr = kmap(page);
-   memcpy(buf, maddr + (addr & ~PAGE_MASK), len);
+   i = copy_to_user(buf, maddr + (addr & ~PAGE_MASK), len);
flush_page_to_ram(page);
kunmap(page);
}
put_page(page);
-   return len;
+   return i ? CUR_EFAULT : 0;
 
 fault_in_page:
spin_unlock(&mm->page_table_lock);
/* -1: out of memory. 0 - unmapped page */
-   if (handle_mm_fault(mm, vma, addr, write) > 0)
+   i = handle_mm_fault(mm, vma, addr, write);
+   if (i > 0)
goto repeat;
-   return 0;
-
+   if (i < 0)
+   return OTHER_ENOMEM;
+   return OTHER_EFAULT;
 bad_pgd:
spin_unlock(&mm->page_table_lock);
pgd_ERROR(*pgdir);
-   return 0;
+   return OTHER_EFAULT;
 
 bad_pmd:
spin_unlock(&mm->page_table_lock);
pmd_ERROR(*pgmiddle);
-   return 0;
+   return OTHER_EFAULT;
 }
 
-static int access_mm(struct mm_struct *mm, struct vm_area_struct * vma, unsigned long 
addr, void *buf, int len, int write)
+static int access_mm(struct mm_struct *mm, struct vm_area_struct * vma, unsigned long 
+addr, void *buf, size_t len, int write, int *pcopied)
 {
int copied = 0;
 
@@ -102,30 +105,36 @@
if (this_len > len)
this_len = len;
retval = access_one_page(mm, vma, addr, buf, this_len, write);
-   copied += retval;
-   if (retval != this_len)
-   break;
+   if (retval) {
+   if (pcopied)
+   *pcopied = copied;
+   return retval;
+   }
+   copied += this_len;
 
-   len -= retval;
+   len -= this_len;
if (!len)
break;
 
-   addr += retval;
-   buf += retval;
+   addr += this_len;
+   buf += this_len;
 
if (addr < vma->vm_end)
continue;   
-   if (!vma->vm_next)
-   break;
-   if (vma->vm_next->vm_start != vma->vm_end)
-   break;
+   if (!vma->vm_next || vma->vm_next->vm_start != vma->vm_end) {
+   if (pcopied)
+   *pcopied = copied;
+   return OTHER_EFAULT;
+   }

vma = vma->vm_next;
}
-   return copied;
+   if (pcopied)
+   *pcopied = copied;
+   return 0;
 }
 
-int access_process_vm(struct task_struct *tsk, unsigned long addr, void *buf, int 
len, int write)
+int access_process_vm(struct task_struct *tsk, unsigned long addr, void *buf, size_t 
+len, int write)
 {
int copied;
struct mm_struct *mm;
@@ -143,12 +152,44 @@
down_read(&mm->mmap_sem);
vma = find_extend_vma(mm, addr);
copied = 0;
-   if (vma)
-   copied = access_mm(mm, vma, addr, buf, len, write);
+   if (vma) {
+   mm_segment_t old;
+   old = get_fs();
+   set_fs(KERNEL_DS);
+   /* silently i

Linux 2.4.4-ac10: Oops

[FAVRE Gregoire]

Hello,

I have just compiled 2.4.4-ac10 and got:

...
SCSI subsystem driver Revision: 1.00
PCI: Found IRQ 11 for device 00:0b.0
Unable to handle kernel NULL pointer dereference at virtual address 000
printing eip:
c01d11d0
*pde = 
Oops: 0002
CPU: 0
EIP: 0010:[]
EFLAGS: 00010282
eax: dfff1000 ...

Are the last ... needed, if yes I'll copy them (is there an easy way to do it)?
Just let me know about it ;-)

gcc -v gives me:
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.96/specs
gcc version 2.96 2731 (Linux-Mandrake 8.1 2.96-0.50mdk)

I have put under http:://ulima.unil.ch/greg/linux/ some files:
the config of my kernels (2.4.4-ac9 and ac10), the System.map, the
output of dmesg from 2.4.4-ac9, the output of lspci -v and finally
the list of the rpm that are installed on my system.

Thanks you very much,

Greg

http://ulima.unil.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED]

 PGP signature

2.4.4-ac9 freezes

[mirabilos]

Hi again,
I have (as reported) compiled 2.4.4-ac9 with RWSEM_GENERIC on
and now have two freezes:
a) playback sound and try to hit a key
b) access the floppy

.config and other info on request - due to bandwidth :)

Thanks in advance if you have any clue... /me not

-mirabilos
-- 
by telnet
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: VIA/PDC/Athlon

[Jussi Laako]

Alan Cox wrote:
> 
> RH 2.4.2-2 and 2.4.4-ac9 are I believe the same driver exactly. 2.4.3 is 
> an ancient known not to work well driver

Ummm... Here's stripped dmesg of both kernels... Is this compiler thingie or
Athlon optimizations?
Notice also different detected PDC20265 BIOS settings! So 2.4.4-ac9 detects
those BIOS settings correctly and 2.4.2-2 doesn't. That's probably reason
why 2.4.2-2 works?

--- 8< ---

Linux version 2.4.4-ac9 (root@davinci) (gcc version 2.95.3 20010315
(release)) #1 Wed May 16 17:37:30 EEST 2001

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 21
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:04.1
ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:DMA
PDC20265: IDE controller on PCI bus 00 dev 88
PCI: Found IRQ 10 for device 00:11.0
PDC20265: chipset revision 2
PDC20265: not 100% native mode: will probe irqs later
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:DMA, hdf:DMA
ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:DMA, hdh:DMA
hda: IBM-DTLA-307030, ATA DISK drive
hdb: SONY CDU4811, ATAPI CD/DVD-ROM drive
hde: IBM-DTLA-307030, ATA DISK drive
hdf: IBM-DTLA-307030, ATA DISK drive
hdg: IBM-DTLA-307030, ATA DISK drive
hdh: IBM-DTLA-307030, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide2 at 0x8800-0x8807,0x8402 on irq 10
ide3 at 0x8000-0x8007,0x7802 on irq 10
hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(100)
hde: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
hdf: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
hdg: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
hdh: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
Partition check:
 hda:hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide0: reset: success
 hda1 hda2 hda3 hda4
 hde: hde1 hde2 hde3 hde4
 hdf: unknown partition table
 hdg: unknown partition table
 hdh: unknown partition table

--- 8< ---

Linux version 2.4.2-2 ([EMAIL PROTECTED]) (gcc version 2.96
2731 (Red Hat Linux 7.1 2.96-79)) #1 Sun Apr 8 20:41:30 EDT 2001

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 21
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:04.1
ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:DMA
PDC20265: IDE controller on PCI bus 00 dev 88
PCI: Found IRQ 10 for device 00:11.0
PDC20265: chipset revision 2
PDC20265: not 100% native mode: will probe irqs later
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio
hda: IBM-DTLA-307030, ATA DISK drive
hdb: SONY CDU4811, ATAPI CD/DVD-ROM drive
hde: IBM-DTLA-307030, ATA DISK drive
hdf: IBM-DTLA-307030, ATA DISK drive
hdg: IBM-DTLA-307030, ATA DISK drive
hdh: IBM-DTLA-307030, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide2 at 0x8800-0x8807,0x8402 on irq 10
ide3 at 0x8000-0x8007,0x7802 on irq 10
hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(33)
hde: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
hdf: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
hdg: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
hdh: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
Partition check:
 hda: hda1 hda2 hda3 hda4
 hde: hde1 hde2 hde3 hde4
 hdf: unknown partition table
 hdg: unknown partition table
 hdh: unknown partition table

--- 8< ---

 - Jussi Laako

-- 
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B  39DD A4DE 63EB C216 1E4B
Available at PGP keyservers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.0, 2.2.18: A critical problem with tty_io.c

[Al Borchers]

Maciej, Ted --

Maciej's patch to tty_io.c from lkml 2/22/01

  http://www.uwsg.indiana.edu/hypermail/linux/kernel/0101.2/1049.html

has been incorporated in RH 7.1's kernel (for example) but not in the
main 2.4.x kernels.

This presents two different interfaces for serial drivers, and it is
awkward to detect and support both interfaces.  The change breaks some
drivers from Digi International, for example.

In Maciej's patch, if a driver open is interrupted the driver close
IS NOT called.  In the 2.4.x series the close IS called.

A serial driver needs to know whether close is going to be called or
not after an interrupted open, so it can do clean up--like DEC_MOD_USE_COUNT--
appropriately.

Suppose the driver open calls INC_MOD_USE_COUNT, sleeps for the port to get
carrier, then gets interrupted.  If the open calls DEC_MOD_USE_COUNT after
the interrupt, the use count will be right under Maciej's patch but too low on
2.4.x.  If the open does not call DEC_MOD_USE_COUNT after an interrupt, instead
deferring that for the close, then the use count will be too high under
Maciej's patch, but right under 2.4.x.  This is particularly a problem if there
is another outstanding open on the port--in that case you can end up with zero
use count (and a closed port!) while the port is open or a non-zero use count
when no one has the port open. 

Personally, I think Maciej's patch is correct and interrupted opens should
clean up after themselves--however, this is a different interface than presented
by the tty subsystem up to now, and will require changes in some serial drivers.

Ted can you get this patch in the kernel or ban it as interface breaking
heresy?  It would be much nicer for us device driver writers to have just
one interface to support.

Thanks,
-- Al Borchers, Peter Berger

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

[PATCH] Allow 'hidden' interfaces in 2.4.x

[Phil Oester]

The attached patch (against 2.4.4-ac10) adds the
/proc/sys/net/ipv4/conf/*/hidden option which is present in 2.2.x series.
This is somewhat similar to the arp-filter functionality which was added in
~2.4.4-ac10.  The difference is that this is not dependent upon the routing
table, it is simply configured using proc fs.

This is particularly useful in load-balanced server farms where loopback
addresses are configured for direct client-server traffic.  Without this
patch, Linux will respond to arp requests for the virtual IPs, making
effective load balancing difficult.

-Phil Oester


diff -r -u -x *~ -x *.rej
linux-2.4.4-ac10/Documentation/filesystems/proc.txt
linux-2.4.4-ac10-hidden/Documentation/filesystems/proc.txt
--- linux-2.4.4-ac10/Documentation/filesystems/proc.txt Fri Apr  6 13:42:48
2001
+++ linux-2.4.4-ac10-hidden/Documentation/filesystems/proc.txt  Thu May 17
15:01:45 2001
@@ -1578,6 +1578,17 @@

 Determines whether to send ICMP redirects to other hosts.

+hidden
+--
+
+Hide addresses attached to this device from other devices.
+Such addresses will never be selected by source address autoselection
+mechanism.  Also, host will not answer broadcast ARP requests for them and
+will not announce it as source address of ARP requests.  The addresses are,
+however, still reachable via IP.  This is primarily useful in
load-balancing
+environments.  This flag is activated only if it is enabled both in
specific
+device section and in "all" section.
+
 Routing settings
 

diff -r -u -x *~ -x *.rej
linux-2.4.4-ac10/Documentation/networking/ip-sysctl.txt
linux-2.4.4-ac10-hidden/Documentation/networking/ip-sysctl.txt
--- linux-2.4.4-ac10/Documentation/networking/ip-sysctl.txt Thu May 17
14:53:02 2001
+++ linux-2.4.4-ac10-hidden/Documentation/networking/ip-sysctl.txt  Thu May
17 15:02:47 2001
@@ -392,6 +392,15 @@
Default value is 0. Note that some distributions enable it
in startip scripts.

+hidden - BOOLEAN
+   Hide addresses attached to this device from other devices.
+   Such addresses will never be selected by source address autoselection
+   mechanism.  Also, host will not answer broadcast ARP requests for them and
+   will not announce it as source address of ARP requests.  The addresses
are,
+   however, still reachable via IP.  This is primarily useful in
load-balancing
+   environments.  This flag is activated only if it is enabled both in
specific
+   device section and in "all" section.
+
 Alexey Kuznetsov.
 [EMAIL PROTECTED]

diff -r -u -x *~ -x *.rej linux-2.4.4-ac10/include/linux/inetdevice.h
linux-2.4.4-ac10-hidden/include/linux/inetdevice.h
--- linux-2.4.4-ac10/include/linux/inetdevice.h Thu May 17 14:53:07 2001
+++ linux-2.4.4-ac10-hidden/include/linux/inetdevice.h  Thu May 17 14:30:25
2001
@@ -18,6 +18,7 @@
int mc_forwarding;
int tag;
int arp_filter;
+   int hidden;
void*sysctl;
 };

@@ -44,6 +45,7 @@

 #define IN_DEV_LOG_MARTIANS(in_dev)(ipv4_devconf.log_martians ||
(in_dev)->cnf.log_martians)
 #define IN_DEV_PROXY_ARP(in_dev)   (ipv4_devconf.proxy_arp ||
(in_dev)->cnf.proxy_arp)
+#define IN_DEV_HIDDEN(in_dev)  ((in_dev)->cnf.hidden &&
ipv4_devconf.hidden)
 #define IN_DEV_SHARED_MEDIA(in_dev)(ipv4_devconf.shared_media ||
(in_dev)->cnf.shared_media)
 #define IN_DEV_TX_REDIRECTS(in_dev)(ipv4_devconf.send_redirects ||
(in_dev)->cnf.send_redirects)
 #define IN_DEV_SEC_REDIRECTS(in_dev)   (ipv4_devconf.secure_redirects ||
(in_dev)->cnf.secure_redirects)
diff -r -u -x *~ -x *.rej linux-2.4.4-ac10/include/linux/sysctl.h
linux-2.4.4-ac10-hidden/include/linux/sysctl.h
--- linux-2.4.4-ac10/include/linux/sysctl.h Thu May 17 14:53:07 2001
+++ linux-2.4.4-ac10-hidden/include/linux/sysctl.h  Thu May 17 14:32:40 2001
@@ -326,7 +326,8 @@
NET_IPV4_CONF_BOOTP_RELAY=10,
NET_IPV4_CONF_LOG_MARTIANS=11,
NET_IPV4_CONF_TAG=12,
-   NET_IPV4_CONF_ARPFILTER=13
+   NET_IPV4_CONF_ARPFILTER=13,
+   NET_IPV4_CONF_HIDDEN=14
 };

 /* /proc/sys/net/ipv6 */
diff -r -u -x *~ -x *.rej linux-2.4.4-ac10/net/ipv4/arp.c
linux-2.4.4-ac10-hidden/net/ipv4/arp.c
--- linux-2.4.4-ac10/net/ipv4/arp.c Thu May 17 14:53:07 2001
+++ linux-2.4.4-ac10-hidden/net/ipv4/arp.c  Thu May 17 14:47:44 2001
@@ -66,7 +66,9 @@
  * Alexey Kuznetsov:   new arp state machine;
  * now it is in net/core/neighbour.c.
  * Krzysztof Halasa:   Added Frame Relay ARP support.
- */
+ * Julian Anastasov:   "hidden" flag: hide the
+ * interface and don't reply for it
+*/

 #include 
 #include 
@@ -317,12 +319,23 @@
 static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
 {
u32 saddr;
+   int from_skb;
+   struct in_device *in_dev2 = NULL;
+   struct net_device *dev2 = NULL;
u8  *dst_ha = NULL;
struct

RE: Linux-2.4.4 failure to compile

[Cress, Andrew R]

Try setting CONFIG_AIC7XXX_BUILD_FIRMWARE=n as a workaround.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 2:04 PM
To: [EMAIL PROTECTED]
Cc: Linux kernel; [EMAIL PROTECTED]
Subject: Re: Linux-2.4.4 failure to compile


In article <[EMAIL PROTECTED]> you wrote:
> "Richard B. Johnson" wrote:
>> 
>> Hello;
>> 
>> I downloaded linux-2.4.4. The basic kernel compiles but the aic7xxx
>> SCSI module that I require on some machines, doesn't.

> The aic7xxx assembler requiring libdb1 is a bungle.  Getting the headers
> for that right on various distros is not easy.  Add to that it requires
> YACC, when most people have bison (yes, a shell script is easy to make,
but
> not always an option). 

If make wants to use yacc but you don't have it, it's probably a mistake
in the make(1) configuration - the Makefile uses implicit rules and
distributions not having yacc should not call it in make's implicit rules.

Christoph

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.5pre3 warning fixes

[Mohammad A. Haque]

On Thu, 17 May 2001, Rich Baum wrote:

> This patch fixes warnings in 2.4.5pre3 about extra tokens at the end of
> #endif statements and labels at the end of compound statements when using gcc
> 3.0 snapshots.
>
> - if (c->devices != NULL)
> + if (c->devices != NULL){
>   c->devices->prev=d;
> + }
>   c->devices=d;
>

It didn't really complain about this one did it? Braces are optional
here or is that not part of ANSI C?

--

=
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: [PATCH] 2.4.5pre3 warning fixes

[Jeff Garzik]

Rich Baum wrote:
> @@ -1543,6 +1543,7 @@
>   EXCEPTION(EX_INTERNAL | 0x116);
>   return;
>  #endif /* PARANOID */
> + ;
> }
>  }
>else if ( (st0_tag == TAG_Valid) || (st0_tag == TW_Denormal) )
> @@ -437,7 +437,7 @@
> /* XXX shouldn't we *start* by deregistering the device? */
> atm_dev_deregister(fore200e->atm_dev);
> 
> -case FORE200E_STATE_BLANK:
> +case FORE200E_STATE_BLANK:;
> /* nothing to do for that state */
>  }
>  }
> @@ -556,7 +556,7 @@
> }
> break;
>  #endif
> -   default:
> +   default:;
> /* nothing */
> }
> 

IMHO the ":;" form is really easy to miss or mistake.

Can't you put a "break;" after the "nothing" comment instead?  The
compiled code is not bigger, and while the source gets a bit bigger, I
think the extra "break;" helps maintenance in the long term.

Jeff


-- 
Jeff Garzik  | Game called on account of naked chick
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LANANA: To Pending Device Number Registrants

[Brian Wheeler]

[ I normally just lurk and read the archives, but...here's where I get into
  trouble! ]

It seems to me that there are several issues that have come up in this thread,
but here are my thoughts on some of them:

* Identifying hardware:
Since we don't want to use topology as the primary method of 
  identifying a device, perhaps it could be the secondary method.  If a device
  id consisted of several parts, userspace could make an educated guess about
  which devices correspond to which names, across reboots.  Consider an ID
  consisting of:
* vendor 
* model 
* serial number 
* content-cookie 
* topology-cookie 
  The two cookie values are opaque, but reproducable.  The content cookie might
  be an MD5 of the partition table of a disk, or its serial number, or 
  something to that effect.  The topology cookie would some topology 
  parameters (such as mem address, irq, io ports, slot #, etc) which could be 
  used to identify the device later.  These are only used for identification, 
  not for discovering topology.

  If all 5 fields match, then we know what it is.  If only topology-cookie is 
  different, then it just moved.  If content-cookie is different then it might
  be a different device  (There's a trickyness to partitioning, I suppose).

  I suppose these ID fields could also be used by a userspace tool to 
  load/unload drivers as necessary.

  The id could also determine the device is only inaccessable (not removed)
  when it disappears.  So, if disk5 disappeared on reboot, the next disk
  added would be given an ID at the end of the list, while disk5 would remain
  unused.  Only on a 'cleanup' would disk5 become reassignable.  This fixes
  issues like a device being unpowered on boot and a new one being powered up.


* User-space device naming
  I think the diskN naming is nice.  "randomly assigned" major ids won't be a
  problem, except on NFS mounted /dev directories.  If the kernel maintained
  a filesystem (like devfs or proc) which always managed the "currently 
  available" devices the only problem to solve would be dealing with software
  which opens the /dev node to get a driver loaded.

  
  It would be very cool if the dev filesystem could be exported to other linux
  boxes, so you could transparently have access to block devices (like nbd does
  now) and character devices (like the sound card)

  mount -t dev -o other_machine /dev/other_machine
  cat foo.au > /dev/other_machine/audio &
  


* IOCTL
  Since ioctl() is commonly regarded as a kluge, is there any reason why it
  couldn't be replaced by the /dev/fb0/frame0 thing that was described earlier?
  The libc implementation of ioctl could convert the binary data back into 
  text calls.  Gross, but possible...though it would probably be better to just
  depreciate the ioctl mechanism.   It could also package it for remote 
  usage (see my pipe_dream above).

  If device info/controls are tied to subdirectory entries, it would be nice
  to be able to get a device's capabilities via existance checking...
  I.E. '-e /dev/disk0/eject' could check of the device is ejectable.


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

RE: [PATCH] 2.4.5pre3 warning fixes

[Bingner Sam J. Contractor RSIS]

Looks to me like it's adding { and } on each side of the
"c->devices->prev=d;" statement... so changing from:

if (c->devices != NULL)
c->devices->prev=d;

to 

if (c->devices != NULL){
c->devices->prev=d;
}

I assume the new compiler likes the if to have explicit brackets instead of
using the next statement...

Sam Bingner

-Original Message-
From: Alan Cox [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 9:40 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [PATCH] 2.4.5pre3 warning fixes


> --- linux/drivers/i2o/i2o_core.c  Thu May 17 11:38:28 2001
> +++ rb/drivers/i2o/i2o_core.c Thu May 17 11:48:08 2001
> @@ -380,8 +380,9 @@
>   d->owner=NULL;
>   d->next=c->devices;
>   d->prev=NULL;
> - if (c->devices != NULL)
> + if (c->devices != NULL){
>   c->devices->prev=d;
> + }

What does this have to do with gcc compiler warnings ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: alpha/2.4.x: CPU misdetection, possible miscompilation

[Jay Estabrook]

On Thu, May 17, 2001 at 02:23:03PM +0200, Michael Wildpaner wrote:
> 
> trying to boot any 2.4.x kernel on a Tsunami DP264 alpha with dual EV67,
> we found the following problems:
> 
> CPU misdetection:
> 
>   On our machine the cpu->type field contains 0x8000B
>   (= 2^35 + 11) instead of 0xB (= hwrpb.h: #define EV67_CPU 11).
> 
>   The spurious high bit leads to false/default values for
>   on_chip_cache in smp.c:smp_tune_scheduling.
>...
>+/* mask for cpu->type (arbitrary assumption based on #define's in hwrpb.h) */
>+#define CPU_TYPE_MASK 0xFF
>...
>-  switch (cpu->type)
>+  switch (cpu->type & CPU_TYPE_MASK)

The Alpha Architecture Reference Manual describes the PROCESSOR TYPE field
of the per-CPU slot HWRPB information, as:

bitsinterpretation
--
63-32   minor type
31-0major type

so the above patch should have CPU_TYPE_MASK as 0x (optimistic :-);
or you could just:

switch ((unsigned int) cpu->type)

like the /proc/cpuinfo printing code in setup.c does.

The "minor type" is usually a reference to the "pass" number of the chip,
and can be ignored.

--Jay++

-
Jay A EstabrookAlpha Engineering - LINUX Project
Compaq Computer Corp. - MRO1-2/K20 (508) 467-2080
200 Forest Street, Marlboro MA 01752   [EMAIL PROTECTED]
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 2.4.5pre3 warning fixes

[Alan Cox]

> --- linux/drivers/i2o/i2o_core.c  Thu May 17 11:38:28 2001
> +++ rb/drivers/i2o/i2o_core.c Thu May 17 11:48:08 2001
> @@ -380,8 +380,9 @@
>   d->owner=NULL;
>   d->next=c->devices;
>   d->prev=NULL;
> - if (c->devices != NULL)
> + if (c->devices != NULL){
>   c->devices->prev=d;
> + }

What does this have to do with gcc compiler warnings ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: CPU overheat with 2.2

[Nils Holland]

On Thursday 17 May 2001 16:45, Simon Richter wrote:
> On Thu, 17 May 2001, Jussi Hamalainen wrote:
> > > CPU is a Pentium 166 MMX on an Asus TX97 mainboard, ISA cards are a
> > > 3c509 and a Soundblaster.
> >
> > The Asus TX97 is known to be a CPU toaster. I've replaced dozens of
> > them because of overheating problems. I don't know why the problem
> > seems to come up with Linux though.
>
> Hrm, it has worked with 2.0 for two years now, with CPU temperature never
> exceeding 40 degrees Celsius... :-/

Yes, this problem is indeed strange. I once had it happening here, and I 
tried several things (playing around with kernel config options, etc) but 
nothing would help. However, by now that board has been replaced so I can 
offer no more advice.

Greetings
Nils

-- 
--
Nils Holland - [EMAIL PROTECTED]
NightCastle Productions - Linux in Tiddische, Germany
http://www.nightcastleproductions.org
"They asked me where this earthquake would begin,
 I offered to let them feel my pulse."
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.5pre3 warning fixes

[Rich Baum]

This patch fixes warnings in 2.4.5pre3 about extra tokens at the end of 
#endif statements and labels at the end of compound statements when using gcc 
3.0 snapshots.

Rich

diff -urN -X /linux/dontdiff linux/arch/i386/math-emu/fpu_trig.c 
rb/arch/i386/math-emu/fpu_trig.c
--- linux/arch/i386/math-emu/fpu_trig.c Sat Apr 28 18:13:25 2001
+++ rb/arch/i386/math-emu/fpu_trig.cWed May 16 12:04:24 2001
@@ -1543,6 +1543,7 @@
  EXCEPTION(EX_INTERNAL | 0x116);
  return;
 #endif /* PARANOID */
+ ;
}
 }
   else if ( (st0_tag == TAG_Valid) || (st0_tag == TW_Denormal) )
diff -urN -X /linux/dontdiff linux/drivers/atm/fore200e.c 
rb/drivers/atm/fore200e.c
--- linux/drivers/atm/fore200e.cFri Feb  9 14:30:22 2001
+++ rb/drivers/atm/fore200e.c   Tue May 15 21:39:07 2001
@@ -437,7 +437,7 @@
/* XXX shouldn't we *start* by deregistering the device? */
atm_dev_deregister(fore200e->atm_dev);
 
-case FORE200E_STATE_BLANK:
+case FORE200E_STATE_BLANK:;
/* nothing to do for that state */
 }
 }
diff -urN -X /linux/dontdiff linux/drivers/cdrom/sbpcd.c 
rb/drivers/cdrom/sbpcd.c
--- linux/drivers/cdrom/sbpcd.c Sat Apr 28 18:13:35 2001
+++ rb/drivers/cdrom/sbpcd.cTue May 15 21:39:47 2001
@@ -1118,7 +1118,7 @@
return (0);
 }
 /*==*
/
-#endif 0
+#endif /* 0 */
 /*==*
/
 static int ResponseInfo(void)
 {
diff -urN -X /linux/dontdiff linux/drivers/i2o/i2o_core.c 
rb/drivers/i2o/i2o_core.c
--- linux/drivers/i2o/i2o_core.cThu May 17 11:38:28 2001
+++ rb/drivers/i2o/i2o_core.c   Thu May 17 11:48:08 2001
@@ -380,8 +380,9 @@
d->owner=NULL;
d->next=c->devices;
d->prev=NULL;
-   if (c->devices != NULL)
+   if (c->devices != NULL){
c->devices->prev=d;
+   }
c->devices=d;
*d->dev_name = 0;
 
diff -urN -X /linux/dontdiff linux/drivers/i2o/i2o_lan.c 
rb/drivers/i2o/i2o_lan.c
--- linux/drivers/i2o/i2o_lan.c Fri Feb  9 14:30:23 2001
+++ rb/drivers/i2o/i2o_lan.cTue May 15 21:38:19 2001
@@ -938,7 +938,7 @@
spin_unlock_irq(&priv->tx_lock);
return 0;
 }
-#endif CONFIG_NET_FC
+#endif /* CONFIG_NET_FC */
 
 /*
  * i2o_lan_packet_send(): Send a packet as is, including the MAC header.
diff -urN -X /linux/dontdiff linux/drivers/media/video/tuner.c 
rb/drivers/media/video/tuner.c
--- linux/drivers/media/video/tuner.c   Mon Feb 19 17:43:36 2001
+++ rb/drivers/media/video/tuner.c  Thu May 17 12:28:59 2001
@@ -556,7 +556,7 @@
}
break;
 #endif
-   default:
+   default:;
/* nothing */
}

diff -urN -X /linux/dontdiff linux/drivers/net/tokenring/ibmtr.c 
rb/drivers/net/tokenring/ibmtr.c
--- linux/drivers/net/tokenring/ibmtr.c Tue Mar 20 15:05:00 2001
+++ rb/drivers/net/tokenring/ibmtr.cTue May 15 21:40:09 2001
@@ -1185,7 +1185,7 @@
isa_writeb(~CMD_IN_SRB, ti->mmio + ACA_OFFSET + 
ACA_RESET + ISRA_ODD);
isa_writeb(~SRB_RESP_INT, ti->mmio + ACA_OFFSET + 
ACA_RESET + ISRP_ODD);
 
- skip_reset:
+ skip_reset:;
} /* SRB response */
 
if (status & ASB_FREE_INT) { /* ASB response */
diff -urN -X /linux/dontdiff linux/drivers/net/wan/hdlc.c 
rb/drivers/net/wan/hdlc.c
--- linux/drivers/net/wan/hdlc.cSat Apr 28 18:13:46 2001
+++ rb/drivers/net/wan/hdlc.c   Tue May 15 21:41:23 2001
@@ -1082,7 +1082,7 @@
}
break;
 
-   default:/* to be defined */
+   default:;   /* to be defined */
}
 
dev_kfree_skb(skb);
diff -urN -X /linux/dontdiff linux/drivers/net/wan/sdla_fr.c 
rb/drivers/net/wan/sdla_fr.c
--- linux/drivers/net/wan/sdla_fr.c Sat Apr 28 18:13:46 2001
+++ rb/drivers/net/wan/sdla_fr.cTue May 15 21:41:00 2001
@@ -4435,7 +4435,7 @@
trigger_fr_poll(dev);

break;
-   default:  // ARP's and RARP's -- Shouldn't happen.
+   default:;  // ARP's and RARP's -- Shouldn't happen.
}
 
return 0;   
diff -urN -X /linux/dontdiff linux/drivers/net/wan/sdla_x25.c 
rb/drivers/net/wan/sdla_x25.c
--- linux/drivers/net/wan/sdla_x25.cSat Apr 28 18:13:47 2001
+++ rb/drivers/net/wan/sdla_x25.c   Tue May 15 21:40:42 2001
@@ -3108,7 +3108,7 @@
case 0x08:  /* modem failure */
 #ifndef MODEM_NOT_LOG
printk(KERN_INFO "%s: modem failure!\n", card->devname);
-#endif MODEM_NOT_LOG
+#endif /* MODEM_NOT_LOG */
api_oob_event(card,mb);
break;
 
diff -urN -X /linux/dontdiff linux/drivers/scsi/NCR53c406a.c 
rb/drivers/scsi/NCR53c406a.c
--- linux/drivers/scsi

Re: Linux 2.4.4-ac10

[Alan Cox]

> And a pair more:

No
> --- linux-2.4.4-ac10/include/linux/raid/md_k.h.orig   Thu May 17 19:35:41
> 2001
> +++ linux-2.4.4-ac10/include/linux/raid/md_k.hThu May 17 19:36:15 2001
> @@ -38,6 +38,8 @@
>   case RAID5: return 5;
>   }
>   panic("pers_to_level()");
> +
> + return 0;

panic appears properly declared as __attribute(noreturn). This looks to me like
a gcc bug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LANANA: To Pending Device Number Registrants

[Jeff Randall]

Eric W. Biederman wrote:
> Daniel Phillips <[EMAIL PROTECTED]> writes:
> > On Tuesday 15 May 2001 23:20, Nicolas Pitre wrote:
> > > Personally, I'd really like to see /dev/ttyS0 be the first detected
> > > serial port on a system, /dev/ttyS1 the second, etc.
> > 
> > There are well-defined rules for the first four on PC's.  The ttySx 
> > better match the labels the OEM put on the box.
> 
> Actually it would be better to have the OEM put a label in the
> firmware, and then have a way to query the device for it's label.
> 
> The legacy rules are nice but serial ports are done with superio chips
> now.  And superio chips are almost all ISA PNP chips without device
> enumeration, and isolation. 

Not all serial ports are superio chips.  There's all kinds of serial
ports on all kinds of different busses being supported under Linux.  The
company I work for supports serial ports on ISA, PCI, SCSI, Ethernet, and
USB at the moment...


-- 
Jeff Randall - [EMAIL PROTECTED]  "A paranoid person is never alone,
   he knows he's always the center
   of attention..."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

hang with 2.4.5-pre3

[Zdenek Kabelac]

Hello

Just pointing out that my system has locked hard in XWindows system.
Sorry no-oops as linux so far is unable to switch to VGA mode in this
case
and show me this log.

I'd not seen any oops with 2.4.5-pre1 during the whole usage of this
kernel
on my SMP box BP6.

-pre3 has locked after 5 hours - and I've been working with this machine
only for the last hour.

I could only describe situation: - starting multithread application
which has been loading data across nfs.

Thats all I can say ... switching back to -pre1
(BTW Core is still no being generated for threaded apps in -pre3 -
please fix)

bye

kabi

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

Re: Linux 2.4.4-ac10

[Alan Cox]

> 
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2 
>-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 
>-march=i686 -malign-functions=4 -c -o apm.o apm.c
> {standard input}: Assembler messages:
> {standard input}:180: Warning: indirect lcall without `*'
> {standard input}:274: Warning: indirect lcall without `*'
> 
> Does anyone know what's up with that? Kernel problem or binutils issue?

binutils is issuing a correct warning but if we fix the warning old old binutils
will then refuse to assemble it right.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Updates...ide.2.4.5-p1.05132001...FastTrak...CSB5...AMD761

[Andre Hedrick]

What did we do

First we added two things for the Promise owners.

If you have a FastTrak and you wish to use it in normal mode, we have a
solution now.  Place all the drives in "span" with only one drive per
array.  This makes each array a single device.  This will work; however,
you must set the new Promise Option to enable the HOST regardless.
Do not set this option with Promise's I2O card!

CSB5...erm it is a work in progress but should be fully functional in
24-48 hours.

AMD761 is fully functional upto ATA-66, the ATA-100 feature is not
complete, but will register so...if you board works great, otherwise issue
an hdparm -X68 /dev/hdX to set the HOST into ATA-66 mode.

The dreaded timeout is actively being killed.

The mystery of hot-swap, well see LANANA threadsince there is a freeze
on char-major-10-XXX device points, thus there is a freeeze on this code
coming to Linux. :-(

I hope to have all of this cleaned up and ready for submission for the
pre3/4/5 patch releases.

Cheers,

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com

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

RE: kernel2.2.x to kernel2.4.x

[Dunlap, Randy]

see http://www.firstfloor.org/~andi/softnet/

~Randy


> -Original Message-
> From: jalaja devi [mailto:[EMAIL PROTECTED]]
> 
> How can I handle this from kernel2.2 to kernel2.4
> 
> Can I replace like this??
> 
> if (test_and_set_bit (0, (void *)&dev->tbusy)){ return
> EBUSY;} == with  netif_stop_queue (dev);
> 
> clear_bit ((void *)&dev->tbusy); = with
> netif_start_queue(dev);
> 
> Thanks
> Jalaja
> 
> --- Alan Cox <[EMAIL PROTECTED]> wrote:
> > > I tried porting a network driver from kernel2.2.x
> > to
> > > 2.4. When i tried loading the driver, it shows the
> > > unresolved symbols for
> > > copy_to_user_ret
> > 
> > if(copy_to_user(...))
> > return -EFAULT
> > 
> > > outs
> > 
> > Has not gone away, your includes are wrong
> > 
> > > __bad_udelay
> > 
> > You are using too large a udelay use mdelay
> > -
> > To unsubscribe from this list: send the line
> > "unsubscribe linux-kernel" in
> > the body of a message 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 Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.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/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: eepro100 rev 12 problems

[Ion Badulescu]

On Thu, 17 May 2001 16:59:04 +0100, James Fidell <[EMAIL PROTECTED]> wrote:
> I have two eepro100 interfaces in a machine, one rev 8, which works just
> fine, and another rev 12, which appears as a device when the kernel boots
> and can be configured with an IP address etc., but I can't get any data
> in or out of it.  All the other hardware looks like it's working fine and
> all my rev 8 cards work, so I'm led to ask, are there any known problems
> with eepro100 rev 12 cards under 2.2.18?

Is this a real card, or is it built-in on the motherboard?

I don't think eepro100 has got much testing with rev > 9, though it should
have worked. All eepro100 chips are supposed to be backwards compatible with
the 82557, but maybe our driver initializes some registers in a way that
upsets newer chips. Not having docs for the newer chips doesn't help, either...

Intel's own e100 driver probably works, their code does things differently if
rev >= 12 (what they call the D102 revision). Give it a spin, I guess.

Ion

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

Re: Linux 2.4.4-ac10

[Jeff Garzik]

"J . A . Magallon" wrote:
> --- linux-2.4.4-ac10/include/linux/raid/md_k.h.orig Thu May 17 19:35:41
> 2001
> +++ linux-2.4.4-ac10/include/linux/raid/md_k.h  Thu May 17 19:36:15 2001
> @@ -38,6 +38,8 @@
> case RAID5: return 5;
> }
> panic("pers_to_level()");
> +
> +   return 0;
>  }

panic should be marked attribute(noreturn), so gcc is being silly here
by warning at all.

I do this too, because IMHO its inline and won't make things bigger just
shut up the warning.  But Alan will yell at you for fixing gcc bugs in
the kernel source :)

Also, add a comment "fixes gcc warning" next to the code, so people know
why it's there.

-- 
Jeff Garzik  | Game called on account of naked chick
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IDE CD writer fails on 2.4.x

[Frank van de Pol]

sorry, not sure which of my CDR trouble you're refering to, but I still am
not succesful in burning cdroms from my linux box (2.4.4-ac5). The hardware
runs fine using older versions or MS windows though.

Regards,
Frank.

On Wed, May 16, 2001 at 12:46:38PM +1000, Glen Morris wrote:
> Frank
> 
> I'm having exactly the same problem with my Ricoh CD-RW since moving from
> kernel 2.2.17 to 2.4.4.
> 
> Did you find the solution?
> 
> Kind regards,
> 
> Glen
> 
> Glen Morris
> PO Box 183
> Kurrajong 2758
> Tel. 02 4576 1404
> Fax. 02 4576 0005



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

Re: uid_t and gid_t vs. __kernel_uid_t and __kernel_gid_t

[Ralf Baechle]

On Mon, May 14, 2001 at 09:14:26PM +, Petr Vandrovec wrote:

> > I had to communicate uid/gid from an application down 
> > to a driver, and discovered that uid and gid in user
> > space are different from those in kernel space.
> 
> ncpfs uses 'unsigned long' in its ncp_mount_data_v4, as MIPS uses
> 'long' type for uid/gid. Unfortunately it still needs conversions
> on some archs, so maybe using u_int64_t is just best solution
> (AFAIK as MIPS unsigned long is 64bit, you have to use u_int64_t
> if you want same type accross architectures).

Only for the 64 bit ABI and kernel on MIPS have a long data type of 64 bits.
General rule for Linux sizeof(pointer) = sizeof(long).

> Kernel part then just checks wheter uid == (__kernel_uid_t)uid and 
> gives up if they differ.

Otherwise funny ones line (u16) 65536 == 0 -> root access could happen ...

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

Re: Linux 2.4.4-ac10

[J . A . Magallon]

On 05.17 Ingo Oeser wrote:
> On Thu, May 17, 2001 at 05:45:38PM +0100, Alan Cox wrote:
> > 2.4.4-ac10
> 
> I think someone forgot this little return. It removes the
> following warning:
> 
> serial.c:4208: warning: control reaches end of non-void function
> 
> 
> --- linux-2.4.4-ac10/drivers/char/serial.cThu May 17 20:41:05 2001
> +++ linux-2.4.4-ac10-ioe/drivers/char/serial.cThu May 17 20:35:53 2001
> @@ -4205,6 +4205,7 @@
>  {
>   __set_current_state(TASK_UNINTERRUPTIBLE);
>   schedule_timeout(HZ/10);
> +   return 0;
>  }
>  

And a pair more:

--- linux-2.4.4-ac10/include/linux/raid/md_k.h.orig Thu May 17 19:35:41
2001
+++ linux-2.4.4-ac10/include/linux/raid/md_k.h  Thu May 17 19:36:15 2001
@@ -38,6 +38,8 @@
case RAID5: return 5;
}
panic("pers_to_level()");
+
+   return 0;
 }
 
 extern inline int level_to_pers (int level)
--- linux-2.4.3-ac12/drivers/scsi/aic7xxx/aic7xxx_osm.h.origSun Apr 22
10:21:55 2001
+++ linux-2.4.3-ac12/drivers/scsi/aic7xxx/aic7xxx_osm.h Mon Apr 23
10:55:58 2001
@@ -843,10 +843,10 @@
pci_read_config_dword(pci, reg, &retval);
return (retval);
}
-   default:
-   panic("ahc_pci_read_config: Read size too big");
-   /* NOTREACHED */
}
+   panic("ahc_pci_read_config: Read size too big");
+   /* NOTREACHED */
+   return 0;
 }
 
 static __inline void ahc_pci_write_config(ahc_dev_softc_t pci,

-- 
J.A. Magallon   #  Let the source be with you...
mailto:[EMAIL PROTECTED]
Linux Mandrake release 8.1 (Cooker) for i586
Linux werewolf 2.4.4-ac9 #4 SMP Mon May 14 11:22:40 CEST 2001 i686

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

Re: Linux-2.4.4 failure to compile

[H. Peter Anvin]

"Richard B. Johnson" wrote:
> 
> I have both. I also have `flex`, but not `lex'. `lex' is a simlink to
> flex. What this compile wanted is some header files in expects for
> `yacc` that are not present. And they don't come with the `bison`
> distribution. Maybe they came with `yacc` years ago? Anyway there
> are some poor assumptions being made in the source Makefile.
> 
> It would be nice to have the 'microcode' assembler running for
> aic7xxx since it is now required for the thing to load.
> 

It worked just fine with "bison" here (with the appropriate shell script
added.)

I think the header file you're talking about is the db1 header file,
which has nothing to do with yacc -- it's the Berkeley libdb version 1,
which is a pretty bad thing to require.

-hpa

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

RE: Exporting symbols from a module.

[Khachaturov, Vassilii]

If you have a local makefile with which you wish to build your module 
not linked under the kernel tree in the proper way, you still can
"ride" on the master Makefile.

This way one can eliminate the dependency on your particular 
machine kernel compilation options to be hardwired in the local Makefile.
I.e., once you reconfigure the kernel, your driver will compile
itself when you do a local "make" with the correct set of the new flags.

This is what you can do on 2.2 (Makefile excerpt follows):
EXTRA_CFLAGS := -DDEBUG -DLINUX -I/usr/src/foo/include
MI_OBJS  := your-module.o
O_TARGET := your-module.o
O_OBJS   := your1.o your2.o

# Reuse Linux kernel master makefile on this directory
ifdef MAKING_MODULES
include $(TOPDIR)/Rules.make
else
all::
cd '/usr/src/linux' && make modules SUBDIRS=$(PWD)
endif

In 2.4 the syntax is different. Rename
MI_OBJS to obj-m and O_OBJS to obj-y to achieve the same goal there:
obj-m  := your-module.o
O_TARGET := your-module.o
obj-y   := your1.o your2.o

HTH,
Vassilii

> -Original Message-
> From: Anders Peter Fugmann [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 17, 2001 12:51 PM
> To: Andreas Dilger
> Cc: linux-kernel
> Subject: Re: Exporting symbols from a module.
> 
> 
> Resolved.
> 
> I just looked at what the kernel did whne compiling a module that 
> exported some symbols, and discovered that I needed
> to set CFLAGS to:
> 
> -D__KERNEL__ -I$/usr/src/linux)  -Wall -Wstrict-prototypes \
> -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe \
> -DMODULE  -DMODVERSIONS -include \
> /usr/src/linux/modversions.h
> 
> Now all works correctly, and I can load my modules.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.4-ac10

[Matti Aarnio]

On Thu, May 17, 2001 at 09:40:39PM +0300, Matti Aarnio wrote:
> On Thu, May 17, 2001 at 08:33:36PM +0200, Udo A. Steinberg wrote:
> > With 2.4.4-ac10 and binutils 2.11 I get the following warnings:
> 
>   It is a warning about kernel code using assembler statements
>   which are not valid with some older assemblers.

  Naeh, I am confusing (you, and myself).  Fixing those (adding the '*')
  would not work with some older assemblers.

  Claiming minimum level of 2.10/2.11 for assembler/binutils would
  certainly allow fixing things by adding the missing '*'.

> > gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2 
>-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 
>-march=i686 -malign-functions=4 -c -o pci-pc.o pci-pc.c
> > pci-pc.c:964: warning: `pci_fixup_via691' defined but not used
> > pci-pc.c:977: warning: `pci_fixup_via691_2' defined but not used
> > {standard input}: Assembler messages:
> > {standard input}:747: Warning: indirect lcall without `*'
> > {standard input}:832: Warning: indirect lcall without `*'
> > {standard input}:919: Warning: indirect lcall without `*'
> > {standard input}:958: Warning: indirect lcall without `*'
...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-2.4.4 failure to compile

[Richard B. Johnson]

On 17 May 2001, H. Peter Anvin wrote:

> Followup to:  <[EMAIL PROTECTED]>
> By author:Tim Hockin <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> > 
> > The aic7xxx assembler requiring libdb1 is a bungle.  Getting the headers
> > for that right on various distros is not easy.  Add to that it requires
> > YACC, when most people have bison (yes, a shell script is easy to make, but
> > not always an option). 
> > 
> 
> Most people have both.  However, if your distribution installs bison
> and not yacc and does *NOT* install the "bison as yacc" wrapper, you
> should complain to your distributor.
> 
> As far as "not always an option", that's ridiculous.  If there really
> isn't someone around who can install it globally, then put it in ~/bin
> and set your PATH.
> 
> The command "yacc" should be expected to work.  This is as insane as
> the flamage in the cdrecord documentation about Linux installing GNU
> make as "make".
> 
>   -hpa

I have both. I also have `flex`, but not `lex'. `lex' is a simlink to
flex. What this compile wanted is some header files in expects for
`yacc` that are not present. And they don't come with the `bison`
distribution. Maybe they came with `yacc` years ago? Anyway there
are some poor assumptions being made in the source Makefile.

It would be nice to have the 'microcode' assembler running for
aic7xxx since it is now required for the thing to load.


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/

newbie problem: compiling kernel 2.4.4, make modules_install , Help please !

[Joel Cordonnier]

Hi !

It's the first time that i try to compile my own
kernel. At the moment, I have an old RH 6.1 with a
2.2.12 kernel.

I have downloaded the latest stable kernel 2.4.4
tar.gz kernel.

I follow these steps:
- make xonfig (a give what i need)
- make dep (for dependencies)
- make bzImage.
All seems OK for these steps.

Then 
- make modules and 
- make modules_install ==> PROBLEM !

FIRST the message say that no argument -F exist for
the command /sbin/depmod. So I change in the Makefile
the call 
if [ -r System.map ]; then /sbin/depmod -ae -F
System.map  2.4.4; fi
TO
if [ -r System.map ]; then /sbin/depmod -ae System.map
 2.4.4; fi

AFTER THIS CHANGE, i have the following error:


...
make[1]: Entering directory
`/usr/src/linux-2.4.4/arch/i386/mm'
make[1]: Nothing to be done for `modules_install'.
make[1]: Leaving directory
`/usr/src/linux-2.4.4/arch/i386/mm'
make -C  arch/i386/lib modules_install
make[1]: Entering directory
`/usr/src/linux-2.4.4/arch/i386/lib'
make[1]: Nothing to be done for `modules_install'.
make[1]: Leaving directory
`/usr/src/linux-2.4.4/arch/i386/lib'
cd /lib/modules/2.4.4; \
mkdir -p pcmcia; \
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i
-r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae System.map
 2.4.4; fi
can't open /lib/modules/System.map/modules.dep

I check, and there is no file or directory named
/lib/modules/System.map or directory!


Help please !
Thanks
Joel






___
Do You Yahoo!? -- Pour faire vos courses sur le Net, 
Yahoo! Shopping : http://fr.shopping.yahoo.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/