Re: Cosmetic JFFS patch.

[Aaron Lehmann]

On Wed, Jun 27, 2001 at 01:50:28PM -0700, Linus Torvalds wrote:
> How about we drop the "printk" altogether, and make it all a comment?

Can we please also drop annoying static informational printk's?



> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039

The later line is not something of interest to most people, and if it
happens to be they can research it rather than being force-fed history
on bootup.

> POSIX conformance testing by UNIFIX

Ditto.

> usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber
> usb-uhci.c: USB Universal Host Controller Interface driver

How about "usb-uhci.c: USB Universal Host Controller Interface driver v1.251"
instead?

dmesg buffer space is rather limited and IMHO there isn't space to
waste on credit-giving in boot logs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: NETDEV WATCHDOG with 2.4.5

[Tim Timmerman]

Andrew,

   Thanks for your suggestions.. I'll try the noapic boot tonight, see
   if that makes any difference. The patches will have to wait till
   the weekend...

   TimT. 

-- 
[EMAIL PROTECTED]  040-2683613
[EMAIL PROTECTED]   Voodoo Programmer/Keeper of the Rubber Chicken
Next week I'm moving to Mars, so if you have any boxes ...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: mounting a fs in two places at once?

[Chris Wedgwood]

On Wed, Jun 27, 2001 at 10:22:17AM -0400, Alexander Viro wrote:

> If you want root-proof analog of chroot - fine, but that will require
> at least taking away the ability to mount/umount anything.

How does FreeBSD implement this with jails? Don't jailed people get
dummy /dev access that is more or less crippled?


I wonder if all this effort is really worth it though, it seems like
lots of 'fixes' to avoid the all-powerful root, so perhaps the fix
lies elsewhere?



  --cw

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

[G. Hugh Song]

My Linux for Alpha on UP2000 SMP has had the same problem with 
the newer kernels 2.4.* with the tulip network driver.
It's got Netgear 310TX with the Digital's original 21140 chip.
In my case, it has nothing to do with the APIC because Alpha 
does not have anything related to APIC.

I suspected that the the message may indicate various
different situations:

G. Hugh Song

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] mm/memory.c locking comments fix

[Paul Menage]

Some of the comments in and before handle_pte_fault() are obsolete or
misleading:

- page_table_lock has been pushed up into handle_mm_fault() and down
into the various do_xxx_page() handlers.

- mmap_sem protects the adding of vma structures to the vmlist, not
pages to the page tables.

Paul

--- linux/mm/memory.c   Fri Apr 27 14:23:25 2001
+++ linux.new/mm/memory.c   Wed Jun 27 20:57:48 2001
@@ -1280,14 +1280,10 @@
  * with external mmu caches can use to update those (ie the Sparc or
  * PowerPC hashed page tables that act as extended TLBs).
  *
- * Note the "page_table_lock". It is to protect against kswapd removing
- * pages from under us. Note that kswapd only ever _removes_ pages, never
- * adds them. As such, once we have noticed that the page is not present,
- * we can drop the lock early.
- *
- * The adding of pages is protected by the MM semaphore (which we hold),
- * so we don't need to worry about a page being suddenly been added into
- * our VM.
+ * The addition and removal of vma structures is protected by the MM
+ * semaphore (which we hold), so we don't need to worry about a vma
+ * being suddenly been added into our VM, or the vma that we hold
+ * becoming invalid.  
  */
 static inline int handle_pte_fault(struct mm_struct *mm,
struct vm_area_struct * vma, unsigned long address,
@@ -1297,11 +1293,6 @@
 
entry = *pte;
if (!pte_present(entry)) {
-   /*
-* If it truly wasn't present, we know that kswapd
-* and the PTE updates will not touch it later. So
-* drop the lock.
-*/
if (pte_none(entry))
return do_no_page(mm, vma, address, write_access, pte);
return do_swap_page(mm, vma, address, pte, pte_to_swp_entry(entry), 
write_access);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.6-pre6 fix drivers/net/Config.in error

[Jeff Garzik]

Steven Cole wrote:
> -   dep_bool '  EISA, VLB, PCI and on board controllers' CONFIG_NET_PCI
> +   dep_bool '  EISA, VLB, PCI and on board controllers' CONFIG_NET_PCI $CONFIG_PCI

See the "EISA" and "VLB" parts in there?  EISA != PCI

-- 
Jeff Garzik  | Andre the Giant has a posse.
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/

RFC: PCI Power Management Documentation

[Patrick Mochel]

I've rewritten the PCI Power Management documentation that I was going to
submit to Linus. I figured I would submit it here to get some proactive
feedback on it.

My thought was to create a Documentation/power/ directory with various
documents describing the way that the kernel implements power management,
as well as the interfaces for implementing it at both a system-wide and
driver level.

Comments gladly welcomed.

-pat


PCI Power Management


An overview of the concepts and the related functions in the Linux kernel

Patrick Mochel <[EMAIL PROTECTED]>

---

1. Overview
2. How the PCI Subsystem Does Power Management
3. PCI Utility Functions
4. PCI Device Drivers
5. Resources

1. Overview
~~~

The PCI Power Management Specification was introduced between the PCI 2.1 and
PCI 2.2 Specifications. It a standard interface for controlling various 
power management operations.

Implementation of the PCI PM Spec is optional, as are several sub-components of
it. If a device supports the PCI PM Spec, the device will have an 8 byte 
capability field in its PCI configuration space. This field is used to describe
and control the standard PCI power management features.

The PCI PM spec defines 4 operating states for devices (D0 - D3) and for buses
(B0 - B3). The higher the number, the less power the device consumes. However,
the higher the number, the longer the latency is for the device to return to 
an operational state (D0).

Bus power management is not covered in this version of this document.

Note that all PCI devices support D0 and D3 by default, regardless of whether or
not they implement any of the PCI PM spec.

The possible state transitions that a device can undergo are:

+---+
| Current State | New State |
+---+
| D0| D1, D2, D3|
+---+
| D1| D2, D3|
+---+
| D2| D3|
+---+
| D1, D2, D3| D0|
+---+

Note that when the system is entering a global suspend state, all devices will be 
placed into D3 and when resuming, all devices will be placed into D0. However, 
when the system is running, other state transitions are possible.

2. How The PCI Subsystem Handles Power Management
~

The PCI suspend/resume functionality is accessed indirectly via the Power Management 
subsystem. At boot, the PCI driver registers a power management callback with that 
layer.
Upon entering a suspend state, the PM layer iterates through all of its registered 
callbacks. This currently takes place only during APM state transitions.

Upon going to sleep, the PCI subsystem walks its device tree twice. Both times, it does
a depth first walk of the device tree. The first walk saves  each of the device's 
state 
and checks for devices that will prevent the system from entering a global power 
state. 
The next walk then places the devices in a low power state.

The first walk allows a graceful recovery in the event of a failure, since none of the 
devices have actually been powered down.

In both walks, in particular the second, all children of a bridge are touched before 
the
actual bridge itself. This allows the bridge to retain power while its children are 
being
accessed.

Upon resuming from sleep, just the opposite must be true: all bridges must be powered 
on
and restored before their children are powered on. This is easily accomplished with a
breadth-first walk of the PCI device tree.


3. PCI Utility Functions


These are helper functions designed to be called by individual device drivers.
Assuming that a device behaves as advertised, these should be applicable in most
cases. However, results may vary.

Note that these functions are never implicitly called for the driver. The driver is 
always
responsible for deciding when and if to call these.


pci_save_state
--

Usage:
pci_save_state(dev, buffer);

Description:
Save first 64 bytes of PCI config space. Buffer must be allocated by caller.


pci_restore_state
-

Usage:
pci_restore_state(dev,buffer);

Description:
Restore previously saved config space. (First 64 bytes only);

If buffer is NULL, then restore what information we know about the device
from bootup: BARs and interrupt line.


pci_set_power_state
---

Usage:
pci_set_power_state(dev,state);

Description:
Transition device to low power state using PCI PM Capabilities registers.

Will fail under one of the following conditions:
- If state is less than current state, but not D0 (illegal transition)
- Device doesn't support PM Capabilities
- Device does not support requested state


pci_enable_wake
---

2.4.x features

[Khyron]

I'm looking for information, either in documentation (!) or
however its available, about the following features in the
2.4.x series kernels:

1. wake-one
2. _syscall4
3. process ID table resizing

Where can I find these documented (no, "the source" isn't a
good answer AFAIAC, even though its true)? Or better, can
anyone answer the following questions about each of these:

A. How do I activate these features? Are they kernel config
   time parameters or standard?
B. How robust is the code implementing these features?

Please feel free to let me know if I have been misled if
#3 isn't an actual feature.

Thanks in advance!


Khyron  mailto:[EMAIL PROTECTED]
Key fingerprint = 53BB 08CA 6A4B 8AF8 DF9B  7E71 2D20 AD30 6684 E82D
"Drama free in 2001!"



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Andre Hedrick]

On Thu, 28 Jun 2001 [EMAIL PROTECTED] wrote:

> From: Andre Hedrick <[EMAIL PROTECTED]>
> 
> You know yourself first and all the screwed up ATAPI products that are
> still using SFF-8020 that has been obsoleted before I start maintaining
> the subsystem three plus years ago. 
> 
> Hi Andre -
> 
> Why precisely is complying to SFF-8020 broken?
> That was the standard. The standard that Microsoft required.

You have stated it clearly it is past tense.

> Other people made a different standard, and claimed that theirs
> was better or more official or whatever, but reality is that
> the products were not manufactured following this so-called
> better standard.

Ignoring "junk hardware" is not practical it will bite you everyday all
day long.Best example is VIA.

> You are a good disciple of Hale, but it is no use ignoring the

If one is going to learn the rules it is best to have learned from on of
the "Fathers of ATA", and given that I have been crowned "Hale Jr." I take
this a compliment.  The reality is that I am not anywhere in the same
class of understanding as Hale Landis, but getting there.

> fact that a very large number of devices was made following SFF-8020.
> These devices are not necessarily screwed, they tend to work fine,
> although both ATA and ATAPI devices have their quirks.

If they all did the same thing (regardless of class) it would be a
different issue.  Basic things like asking for N amounts of data and
getting back N+M > N the buffer allocated.  Or worse is the under
data-run.  Other issues are DRQ, failure to hold/set busy-bit.

The ATAPI people do not even follow the rules in the defunct guide.

> SFF-8020, later INF-8020, became part of ATA/ATAPI-4 (1998).
> The T13 people that merged SFF-8020 and produced ATA/ATAPI-4
> changed a few details about how a master is supposed to react
> when a nonexistent slave is selected. Nobody really noticed,

That point is only important during POST and execution of drive
diagnostics command and Linux does not call that command.

> and ATA/ATAPI-5 still had the same requirements. But then long
> discussions about this difference caused ATA/ATAPI-6 to go back
> to the original SFF-8020 requirements. Do you disagree with this
> description of history? If you agree then it is not SFF-8020
> but ATA/ATAPI-4 and ATA/ATAPI-5 that today must be considered broken
> in this respect. I am referring to Section 9.16.1 of these standards.
> 
> Maybe there are other things in SFF-8020 that you consider broken?

See above, regardless of the brokeness whe have to mucky with it.
So I move to develop to a standard that I have influence and direction
control, then deal with the exceptions.

ATA-X created the "packet-command" and "data-phase-handlers" based on the
zero-bit in the error_feature task-register.

Lastly it does not exist anymore, a real problem for manufacturers
building product on a document that does not exist.  Worse is that there
are companies making hardware based on SFF-8020 v2.5!

Cheers,

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



Expired   SFF-8020i Rev 2.6 





SFF Committee documentation may be purchased (see p4).

SFF Committee documents are available by FaxAccess at 408-741-1600













SFF Committee



  SFF-8020i Specification for 



  ATA Packet Interface for CD-ROM 



  Rev 2.6   January 22, 1996







Secretariat:  SFF Committee





Abstract:  INF-8020i defines defines a Packet Interface for use with CD-ROM 

drives that use the ATA (AT Attachment) interface.



The members voted in September 1999 that this specification Expire. 



SFF-8020 has been incorporated into two national standards, SCSI MMC (Multi 

Media Commands) and ATA/ATAPI (AT Attachment). 



For current information, see:



 - www.t10.org for the latest revision of SCSI MMC-x 

 - www.t13.org for the latest revision of ATA/ATAPI-x

Re: Linux Kernel Urgently Needed-Open Source Projects

[Carl Spalletta]

On Monday July 25, 2001 Jasmin Brown wrote:

>Aufgaben: 
>permanente Anpassung wichtiger Systemkomponenten an
unsere
et cetera

Since nobody jumped on the improbably named Yasmin
Brown & Jill Simmons for daring to post a classified
within these hallowed precincts, I submit herewith my
own contribution to interstellar amity - a free
translation of the German text from that article:

cat << ENDQUOTE
die funktionen:
   ein) Permanent adjustment of important system
komponents to our orders. Orders which must be obeyed!
In this konnection, program SOURCE projects from
Kernel modules mit:
   zwei) Advancement of our Apache Webservers.
   drei) Konception and implementation of teufels für 
 our master architecture and elimination of
 race conditions.
   fier) Configuration and code modification; for 
 example of GFS, Apache, or Linux kernel.
ENDQUOTE

I think that was the gist of it.


__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.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/

Re: Asus CUV4X-DLS

[J. Nick Koston]

Thanks for the tips, however it doesn't help :-(

Anyways in case anyone is curious the i/o problem still happens
with an aic7xxx card put in and the onboard scsi disabled.

[snip] 
> "J. Nick Koston" wrote:
> > 
> > There seems to be a major problem with this board and 2.4.x kernels.
> > I consistantly get SCSI Input/Output errors on multiple drives that I
> > know are good when running a SMP kernel.  These errors do no happen
> > with a UP kernel.  This is happening on multiple systems and with
> > multiple know good scsi drives of all speeds and sizes.
> 
> Make sure you have the latest BIOS upgrade and set the MPS revision in
> the BIOS to 1.1 rather than 1.4. This cured a similar issue for me and
> USB on the CUV4X-D motherboard, but as your board is different, your
> mileage may vary.

Already set at 1.1
> 
> Also, try passing "noapic" to the kernel on boot if the problem still
> persists. The downside is that all interrupts will be handled by a
> single CPU. There is a definite problem with VIA chipsets.
> 
Tried this as well (mentioned in my original email)

> John

-- 

 PGP signature

Re: A signal fairy tale

[Balbir Singh]

|
|> Let me know, when somebody has a patch or needs help, I would like to
|> help or take a look at it.
|
|Maybe we can both hack on this.
|

Sure, that should be interesting, did you have something in mind ? We can
start right away.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.6-pre6 fix drivers/net/Config.in error

[Steven Cole]

I got this error for 2.4.6-pre6 for make xconfig

drivers/net/Config.in: 145: can't handle dep_bool/dep_mbool/dep_tristate condition
make[1]: *** [kconfig.tk] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.6-pre6/scripts'
make: *** [xconfig] Error 2

This may be the proper fix.
Steven

--- linux/drivers/net/Config.in.originalWed Jun 27 20:39:50 2001
+++ linux/drivers/net/Config.in Wed Jun 27 20:41:28 2001
@@ -142,7 +142,7 @@
   tristate '  NE/2 (ne2000 MCA version) support' CONFIG_NE2_MCA
   tristate '  IBM LAN Adapter/A support' CONFIG_IBMLANA
fi
-   dep_bool '  EISA, VLB, PCI and on board controllers' CONFIG_NET_PCI
+   dep_bool '  EISA, VLB, PCI and on board controllers' CONFIG_NET_PCI $CONFIG_PCI
if [ "$CONFIG_NET_PCI" = "y" ]; then
   dep_tristate 'AMD PCnet32 PCI support' CONFIG_PCNET32 $CONFIG_PCI
   dep_tristate 'Adaptec Starfire support (EXPERIMENTAL)' 
CONFIG_ADAPTEC_STARFIRE $CONFIG_PCI $CONFIG_EXPERIMENTAL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: A signal fairy tale

[Daniel R. Kegel]

Christopher Smith <[EMAIL PROTECTED]> wrote:

> Jamie Lokier <[EMAIL PROTECTED]> wrote:
> > Btw, this functionality is already available using sigaction().  Just
> > search for a signal whose handler is SIG_DFL.  If you then block that
> > signal before changing, checking the result, and unblocking the signal,
> > you can avoid race conditions too.  (This is what my programs do).
> 
> It's more than whether a signal is blocked or not, unfortunately. Lots of 
> applications will invoke sigwaitinfo() on whatever the current signal mask 
> is, which means you can't rely on sigaction to solve your problems. :-(

As Chris points out, allocating a signal by the scheme Jamie
describes is neccessary but not sufficient.  The problem Chris
ran into is that he allocated a signal fair and square, only to find
the application picking it up via sigwaitinfo()!
Yes, this is a bug in the application -- but it's interesting that this
bug only shows up when you try to integrate a new, well-behaved, library 
into the app.  It's a fragile part of the Unix API.  sigopen() is
a way for libraries to defend themselves against misuse of sigwaitinfo()
by big applications over which you have no control.

So sigopen() is a technological fix to a social problem, I guess.
- 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: wake_up vs. wake_up_sync

[Hubertus Franke]

Manfred,

Calling this a BUG is misleading. It is ok to be occasionally wrong
regarding the preemption priority as long as RT tasks are not involved.
This is due to the fact that PROC_CHANGE_PENALTIES are used, which already
provide for some priority inversion.

Hubertus Franke
email: [EMAIL PROTECTED]
(w) 914-945-2003(fax) 914-945-4425   TL: 862-2003



Manfred Spraul <[EMAIL PROTECTED]>@vger.kernel.org on 06/27/2001
06:41:29 PM

Sent by:  [EMAIL PROTECTED]


To:   Mike Kravetz <[EMAIL PROTECTED]>
cc:   Scott Long <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject:  Re: wake_up vs. wake_up_sync



Mike Kravetz wrote:
>
> On Wed, Jun 27, 2001 at 11:22:19PM +0200, Manfred Spraul wrote:
> > > Why would you want to prevent
> > > reschedule_idle()?
> > >
> > If one process runs, wakes up another process and _knows_ that it's
> > going to sleep immediately after the wake_up it doesn't need the
> > reschedule_idle: the current cpu will be idle soon, the scheduler
> > doesn't need to find another cpu for the woken up thread.
>
> I'm curious.  How does the caller of wake_up_sync know that the
> current cpu will soon be idle.  Does it assume that there are no
> other tasks on the runqueue waiting for a CPU?  If there are other
> tasks on the runqueue, isn't it possible that another task has a
> higher goodness value than the task being awakened.  In such a case,
> isn't is possible that the awakened task could sit on the runqueue
> (waiting for a CPU) while tasks with a lower goodness value are
> allowed to run?
>

I found one combination where that could happen:

process.thread
A.1: highest priority, runs on cpu0
B.1: lowest priority, runs on cpu1
A.2: another thread of process A, priority
PROC_CHANGE_PENALTY+PRIORITY(B.1)+1, sleeping.
B.2: same priority as A.2, sleeping, same process as B.1

A.1:
{
 wake_up("A.2");
/* nothing happens: preemption_goodness is 0 since B.1 has both
PROC_CHANGE_PENALTY and the += 1 from 'same mm'
*/
 wake_up_sync("B.2");
 schedule();
/* schedule selects A.2 instead of B.2 due to the += 1 from 'same mm'.
BUG: B.2 should replace B.1 on cpu1. The preemption_goodness is 1.
*/

IMHO obscure and very rare.

But I just found a bigger problem:
If wake_up_sync wakes up more than 1 process then cpus could remain in
cpu_idle() although processes are on the runqueue without cpus.

--
 Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: A signal fairy tale

[Daniel R. Kegel]

From: Christopher Smith <[EMAIL PROTECTED]>
>> [ sigopen() proposal ]
>... From a programming standpoint, this 
>looks like a really nice approach. I must say I prefer this approach to the 
>various "event" strategies I've seen to date, as it fixes the primary 
>problem with signals, while still allowing us to hook in to all the 
>standard POSIX API's that already use signals. 

Thanks.  I'm sure people already thought of this long ago, it's basically just 
the usual "In Unix, everything's a file".  Until you ran into that
problem where the jvm was stealing your signals, though, I hadn't seen
a situation where having signals behave like files would be important.

>It'd be nice if I could pass 
>in a 0 for signum and have the kernel select from unused signals (problem 
>being that "unused" is not necessarily easy to define), althouh I guess an 
>inefficient version of this could be handled in userland.

There is a (non-threadsafe) convention that Jamie Lokier pointed out
for finding an unused thread.   If we allowed sigopen(-1) to allocate
a new signal for you, it'd probably just use the same scheme...

>I presume the fd could be shared between threads and otherwise behave like 
>a normal fd, which would be sper nice.

Yes.

>I guess the main thing I'm thinking is this could require some significant 
>changes to the way the kernel behaves. Still, it's worth taking a "try it 
>and see approach". If anyone else thinks this is a good idea I may hack 
>together a sample patch and give it a whirl.

What's the biggest change you see?  From my (two-martini-lunch-tainted)
viewpoint, it's just another kind of signal masking, sorta...

>Thanks again good fairy Dan/Eunice. ;-)

You're welcome (and I'll tell Eunice you liked her idea!).

- 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: A signal fairy tale

[Daniel R. Kegel]

Balbir Singh <[EMAIL PROTECTED]> wrote:

>Shouldn't there be a sigclose() and other operations to make the API
>orthogonal.

No, plain old close() on the file descriptor returned by sigopen()
would do the trick.

>sigopen() should be selective about the signals it allows
>as argument. Try and make sigopen() thread specific, so that if one
>thread does a sigopen(), it does not imply it will do all the signal
>handling for all the threads.

IMHO sigopen()/read() should behave just like sigwait() with respect 
to threads.  That means that in Posix, it would not be thread specific,
but in Linux, it would be thread specific, because that's how signals
and threads work there at the moment.

>Does using sigopen() imply that signal(), sigaction(), etc cannot be used.
>In the same process one could do a sigopen() in the library, but the
>process could use sigaction()/signal() without knowing what the library
>does (which signals it handles, etc).

Between sigopen() and close(), calling signal() or sigaction() on that 
signal would probably return EBUSY.   A well-behaved program already
looks for an unoccupied signal using sigaction (as Jamie Lokier
points out), so they shouldn't try to reuse a signal in use by sigopen().

- 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: RFC: Changes for PCI

[Tom Gall]

Jeff Garzik wrote:

> Tom Gall wrote:
> > Well you have device drivers like the symbios scsi driver for instance that
> > tries to determine if it's seen a card before. It does this by looking at the
> > bus,dev etc numbers...  It's quite reasonable for two different scsi cards to be
> > on the same bus number, same dev number etc yet they are in different PCI
> > domains.
> >
> > Is this a device driver bug or feature?
>
> I hesitate to call it a device driver bug, because that was likely the
> best decision Gerard could make at the time.

I don't doubt it. I wouldn't doubt I've been guilty of simliar things in my past...


> However, I think the driver (only going by your description) would be
> more correct to use a pointer to struct pci_dev.  We have a token in the
> kernel that is guaranteed 100% unique to any given PCI device:  the
> pointer to its struct pci_dev.

Sound good.

> > > Changing the meaning of dev->bus->number globally seems pointless.  If
> > > you are going to do that, just do it the right way and introduce another
> > > struct member, pci_domain or somesuch.
>
> Sorry, not pci_domain, just system bus number, for any bus, like we
> talked about in the previous discussion.

Yes agreed. However do you think it's possible for the additional of such a value now
in 2.4.x series? Alan? Linus?

Regards,

Tom
--
Tom Gall - PPC64 Maintainer  "Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc


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

VIA 686B/Data Corruption FAQ

[Gareth Hughes]

http://www.viahardware.com/686bfaq.shtm

Couldn't find a mention of this in the archives, but those interested in
the VIA chipset issues should check this out.  The page contains the
following officail statement from VIA:

The data corruption error, which some web sites and people have reported
with the 686b Southbridge, is caused by incorrect bios registry setting
to the Northbridge. These bios settings were made by motherboard
manufacturers, in an attempt to fix a conflict with the Sound Blaster
Live Value cards. Information has been provided to all motherboard
manufacturers on how to correctly resolve both the data corruption error
and the Sound Blaster Live conflict. The patch released by VIA in the
4in1 4.31 drivers replicates the correct bios settings. We provided
this patch to make sure as many people got a fix to their Sound Blaster
Live problems as soon as possible. Most motherboard manufacturers have
now corrected their bios and the patch is not necessarily needed
although it will not harm any VIA based system if installed.

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

Asus CUV4X-DLS

[J. Nick Koston]

There seems to be a major problem with this board and 2.4.x kernels.
I consistantly get SCSI Input/Output errors on multiple drives that I
know are good when running a SMP kernel.  These errors do no happen
with a UP kernel.  This is happening on multiple systems and with
multiple know good scsi drives of all speeds and sizes.

Test#1:

2.4.2 (redhat 7.1 version)

dd if=/dev/sda of=/dev/null
(fails with input/output error)

Test #2:

2.4.2 (redhat 7.1 version)
noapic on boot

dd if=/dev/sda of=/dev/null
(fails with input/output error)

Test #3:

2.4.2 (redhat 7.1 edition)

dd if=/dev/sda of=/dev/null
PASS!


   Nick







-- 

 PGP signature

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Andries . Brouwer]

From: Andre Hedrick <[EMAIL PROTECTED]>

You know yourself first and all the screwed up ATAPI products that are
still using SFF-8020 that has been obsoleted before I start maintaining
the subsystem three plus years ago. 

Hi Andre -

Why precisely is complying to SFF-8020 broken?
That was the standard. The standard that Microsoft required.
Other people made a different standard, and claimed that theirs
was better or more official or whatever, but reality is that
the products were not manufactured following this so-called
better standard.
You are a good disciple of Hale, but it is no use ignoring the
fact that a very large number of devices was made following SFF-8020.
These devices are not necessarily screwed, they tend to work fine,
although both ATA and ATAPI devices have their quirks.

SFF-8020, later INF-8020, became part of ATA/ATAPI-4 (1998).
The T13 people that merged SFF-8020 and produced ATA/ATAPI-4
changed a few details about how a master is supposed to react
when a nonexistent slave is selected. Nobody really noticed,
and ATA/ATAPI-5 still had the same requirements. But then long
discussions about this difference caused ATA/ATAPI-6 to go back
to the original SFF-8020 requirements. Do you disagree with this
description of history? If you agree then it is not SFF-8020
but ATA/ATAPI-4 and ATA/ATAPI-5 that today must be considered broken
in this respect. I am referring to Section 9.16.1 of these standards.

Maybe there are other things in SFF-8020 that you consider broken?

Andries


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Freezing bug in all kernels greater than 2.4.5-ac13 *AND*2.4.6-pre2

[Marcelo Tosatti]

On Wed, 27 Jun 2001, Marcelo Tosatti wrote:

> 
> 
> On Wed, 27 Jun 2001 [EMAIL PROTECTED] wrote:
> 
> > I decided, for the hell of it, to test the pre series as I've been
> > nudged by many people to try it in favor of the ac kernel series that
> > I've been having problems with. Well, it turns out I have ran into
> > exactly the same problem I had with the ac kernel series, which quite
> > frankly is surprising the hell out of me.
> > 
> > To make the kernel freeze/slow down to a crawl with affected kernels on
> > my machine I do this test:
> > 
> > Load X (This fills up my ram and causes me to swap a bit)
> > run a rxvt and su to root (proboably unnecessary)
> > du /
> > 
> > Now, somewhere in this test I start swapping a little bit, nothing
> > big... then BAM. hard disk, mouse, keyboard, all completely and utterly
> > stop. Video continues to work, but my cpu's load goes absolutely INSANE.
> > (If it recovers, gkrellm generally says I've gotten a loadavg somewhere
> > between 3-20, depending on how long it was stuck) This can last for
> > seconds (usually) minutes (once) or it can simply get worse and hang the
> > machine (many, many many times)
> > 
> > When it recovers from this, I generally see a MASSIVE write to swap,
> > (I'm using gkrellm to monitor it) and the system continues on as if
> > nothing happened - until, of course, this happens again. A kernel
> > compile can cause it. a rm -R of a large directory can cause it. Loading
> > a large application can cause it.
> > 
> > On some kernels this is more noticable than others - ac15 does it the
> > worst, although pre3 rivals it, and the symptoms are different on
> > ac17/18 - it'll simply freeze randomly and with no recovery instead of
> > sometimes freezing or sometimes slowing down to a crawl and recovering
> > or freezing. (Which is worse? You decide.)
> > 
> > Now, as before, I tested this with swap and without swap. With swap, I
> > get the hangs/freezes in all the affected kernels. Without swap, I
> > don't. Nada.
> > 
> > Now, the big question of the day folks: What changed between 2.4.6-pre2
> > and 2.4.6-pre3 that ALSO changed between 2.4.5-ac13 and 2.4.5-ac14 - and
> > now, what part of those patches were the VM? Anyone? I don't see in
> > 2.4.6-pre3 what changed that was part of the VM... So I am trying to
> > narrow it down a bit :)
> > 
> > This bug is driving me slightly nuts, so I want it dead. Anyone got a
> > exterminator handy? =)
> 
> Rik's page_launder() changes. 

Eek. I mean Rik's page_launder() changes are _causing_ the problem. (its
the only VM change between 2.4.6-pre2->pre3/2.4.5-ac13->ac14)

Question:

Whats the size of the inactive dirty and clean lists when you're about to
crash.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Freezing bug in all kernels greater than 2.4.5-ac13 *AND*2.4.6-pre2

[Marcelo Tosatti]

On Wed, 27 Jun 2001 [EMAIL PROTECTED] wrote:

> I decided, for the hell of it, to test the pre series as I've been
> nudged by many people to try it in favor of the ac kernel series that
> I've been having problems with. Well, it turns out I have ran into
> exactly the same problem I had with the ac kernel series, which quite
> frankly is surprising the hell out of me.
> 
> To make the kernel freeze/slow down to a crawl with affected kernels on
> my machine I do this test:
> 
> Load X (This fills up my ram and causes me to swap a bit)
> run a rxvt and su to root (proboably unnecessary)
> du /
> 
> Now, somewhere in this test I start swapping a little bit, nothing
> big... then BAM. hard disk, mouse, keyboard, all completely and utterly
> stop. Video continues to work, but my cpu's load goes absolutely INSANE.
> (If it recovers, gkrellm generally says I've gotten a loadavg somewhere
> between 3-20, depending on how long it was stuck) This can last for
> seconds (usually) minutes (once) or it can simply get worse and hang the
> machine (many, many many times)
> 
> When it recovers from this, I generally see a MASSIVE write to swap,
> (I'm using gkrellm to monitor it) and the system continues on as if
> nothing happened - until, of course, this happens again. A kernel
> compile can cause it. a rm -R of a large directory can cause it. Loading
> a large application can cause it.
> 
> On some kernels this is more noticable than others - ac15 does it the
> worst, although pre3 rivals it, and the symptoms are different on
> ac17/18 - it'll simply freeze randomly and with no recovery instead of
> sometimes freezing or sometimes slowing down to a crawl and recovering
> or freezing. (Which is worse? You decide.)
> 
> Now, as before, I tested this with swap and without swap. With swap, I
> get the hangs/freezes in all the affected kernels. Without swap, I
> don't. Nada.
> 
> Now, the big question of the day folks: What changed between 2.4.6-pre2
> and 2.4.6-pre3 that ALSO changed between 2.4.5-ac13 and 2.4.5-ac14 - and
> now, what part of those patches were the VM? Anyone? I don't see in
> 2.4.6-pre3 what changed that was part of the VM... So I am trying to
> narrow it down a bit :)
> 
> This bug is driving me slightly nuts, so I want it dead. Anyone got a
> exterminator handy? =)

Rik's page_launder() changes. 


> 
> Refer to my previous post with this subject for my original description
> of this problem. It's still there in ac18, though I've not tested 19
> (Some have said it's not likely to have been fixed, and I've been
> regress testing 2.4.6pre's today.)
> 
> Subject: Possible freezing bug located after ac13
> 
> Let me know if I can provide any additional information that will help
> nail this bug to the wall. (I want to torture it. =)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] swapin flush cache bug

[NIIBE Yutaka]

Hello Stephen, 

Stephen C. Tweedie wrote:
 > First, don't we want to do a flush_page_to_ram() *before* starting the
 > swap IO?

Well, let me explain the issue.  It is the thing we need to do
flushing *after* I/O.

--
Problem with virtually indexed physically tagged write-back cache.

(1) Page got swapped out

   Swap out
   [ Page ] > [ Disk ]

(2) Page got swapped in asynchronously, possibly by read-ahead

   Swap in
   [ Page ] < [ Disk ]
   K

   The I/O from disk goes through kernel virtual address K.
   We have cache entries indexed by K.

(3) Page fault occurs at user space U

   U > [ Page ] -> [ Disk ]
   K

   The control goes to do_swap_page, found the page at
   lookup_swap_cache.

   If K and U indexes differently, we have cache alias issues, we need
   to flush the entries indexed by K and let them go to memory.  Or else, 
   user space will see bogus data in Page.
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Freezing bug in all kernels greater than 2.4.5-ac13 *AND* 2.4.6-pre2

[tcm]

I decided, for the hell of it, to test the pre series as I've been
nudged by many people to try it in favor of the ac kernel series that
I've been having problems with. Well, it turns out I have ran into
exactly the same problem I had with the ac kernel series, which quite
frankly is surprising the hell out of me.

To make the kernel freeze/slow down to a crawl with affected kernels on
my machine I do this test:

Load X (This fills up my ram and causes me to swap a bit)
run a rxvt and su to root (proboably unnecessary)
du /

Now, somewhere in this test I start swapping a little bit, nothing
big... then BAM. hard disk, mouse, keyboard, all completely and utterly
stop. Video continues to work, but my cpu's load goes absolutely INSANE.
(If it recovers, gkrellm generally says I've gotten a loadavg somewhere
between 3-20, depending on how long it was stuck) This can last for
seconds (usually) minutes (once) or it can simply get worse and hang the
machine (many, many many times)

When it recovers from this, I generally see a MASSIVE write to swap,
(I'm using gkrellm to monitor it) and the system continues on as if
nothing happened - until, of course, this happens again. A kernel
compile can cause it. a rm -R of a large directory can cause it. Loading
a large application can cause it.

On some kernels this is more noticable than others - ac15 does it the
worst, although pre3 rivals it, and the symptoms are different on
ac17/18 - it'll simply freeze randomly and with no recovery instead of
sometimes freezing or sometimes slowing down to a crawl and recovering
or freezing. (Which is worse? You decide.)

Now, as before, I tested this with swap and without swap. With swap, I
get the hangs/freezes in all the affected kernels. Without swap, I
don't. Nada.

Now, the big question of the day folks: What changed between 2.4.6-pre2
and 2.4.6-pre3 that ALSO changed between 2.4.5-ac13 and 2.4.5-ac14 - and
now, what part of those patches were the VM? Anyone? I don't see in
2.4.6-pre3 what changed that was part of the VM... So I am trying to
narrow it down a bit :)

This bug is driving me slightly nuts, so I want it dead. Anyone got a
exterminator handy? =)

Refer to my previous post with this subject for my original description
of this problem. It's still there in ac18, though I've not tested 19
(Some have said it's not likely to have been fixed, and I've been
regress testing 2.4.6pre's today.)

Subject: Possible freezing bug located after ac13

Let me know if I can provide any additional information that will help
nail this bug to the wall. (I want to torture it. =)

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

Re: spindown

[Troy Benjegerdes]

On Thu, Jun 21, 2001 at 06:07:01PM +0200, Jamie Lokier wrote:
> Pavel Machek wrote:
> > > Isn't this why noflushd exists or is this an evil thing that shouldn't
> > > ever be used and will eventually eat my disks for breakfast?
> > 
> > It would eat your flash for breakfast. You know, flash memories have
> > no spinning parts, so there's nothing to spin down.
> 
> Btw Pavel, does noflushd work with 2.4.4?  The noflushd version 2.4 I
> tried said it couldn't find some kernel process (kflushd?  I don't
> remember) and that I should use bdflush.  The manual says that's
> appropriate for older kernels, but not 2.4.4 surely.

Yes, noflushd works with 2.4.x. I'm running it on an ibook with 
debian-unstable.

And as a word of warning: while running noflushd, make sure you 'sync' a 
few times after an 'apt-get dist-upgrade' that upgrades damn near 
everything before doing something that crashes the kernel. This WILL eat 
your ext2fs for breakfast.

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  [EMAIL PROTECTED]
-"If this message isn't misspelled, I didn't write it" -- Me -
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Shulz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] swapin flush cache bug

[Stephen C. Tweedie]

Hi,

On Thu, Jun 28, 2001 at 09:07:52AM +0900, NIIBE Yutaka wrote:
> Marcelo Tosatti wrote:
>  > I think Stephen C. Tweedie has some considerations about the cache
>  > flushing calls on do_swap_page().
> 
> Yup.  IIRC, he said that flushing cache at do_swap_page() (which I've
> tried at first) is not good, because it's the hot path and it causes
> another performance problem in apache or sendmail, where many
> processes share the pages in swap cache.
> 
> Then, the fix I sent yesterday is second try.  The flush is moved to
> I/O routine, instead of do_swap_page().

I really want somebody who has worked on weird caching architectures
to look at it too, but I don't see that the new code works well.
First, don't we want to do a flush_page_to_ram() *before* starting the
swap IO?  There's no point dma'ing the swap page to ram if old, dirty
cache data is then going to be written back on top of that.

Secondly, the flushing of icache/dcache only needs to be done by the
time we come to use the page, so can be performed any time, before or
after the IO.  We're not going to be accessing the page during IO so
if we flush first we won't risk having stale cache data by the time
the IO completes.

So, why not just do the flushing before the IO?  Adding an async trap
to flush the page after swap IO seems the wrong approach: this should
be possible to fix synchronously.

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

Tulip driver still broken at 2.4.6-pre5

[Stephen Davies]

Hello.

I have just built 2.4.6-pre5 in the hope that the tulip 21041 driver 
support might have been fixed but find that it is not.
(SMC/Digital DC21041 Tulip rev 17)

Cheers and thanks,
Stephen Davies


Stephen Davies Consulting  [EMAIL PROTECTED]
Adelaide, South Australia. Voice: 08-8177 1595
Computing & Network solutions. Fax: 08-8177 0133


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] swapin flush cache bug

[Marcelo Tosatti]

On Thu, 28 Jun 2001, NIIBE Yutaka wrote:

> Marcelo Tosatti wrote:
>  > I think Stephen C. Tweedie has some considerations about the cache
>  > flushing calls on do_swap_page().
> 
> Yup.  IIRC, he said that flushing cache at do_swap_page() (which I've
> tried at first) is not good, because it's the hot path and it causes
> another performance problem in apache or sendmail, where many
> processes share the pages in swap cache.

I guess he has some other comments about it... 

Again, Stephen ? 

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

Re: The Joy of Forking

[Troy Benjegerdes]

On Mon, Jun 25, 2001 at 04:03:54AM -0400, Rick Hohensee wrote:

> > >   rtlinux by default
> > >   no SMP
> > >   SMP doesn't scale. If this fork comes, the smart maintainer
> > >   will take the non-SMP fork.
> > 
> > Depends on platform and bus. From reports, it seems to scale just fine on
> > non-intel systems.
> 
> Big expensive systems. Non-desktop systems. Non-end-user systems. And
> clustering will eat its lunch eventually anyway.

You don't get much more end-user than a $2500 Dual Processor Mac G4. 
(And as soon as you say $2500 is a lot of money, I can probably find a 
dual CPU PentiumIII system for < $1000)

We would be perfectly happy if you have the time and ability to maintain a 
fork that can do all of this, and those of us that have more than one CPU 
type will be perfectly happy to ignore it.

-- 
Troy Benjegerdes | master of mispeeling | 'da hozer' |  [EMAIL PROTECTED]
-"If this message isn't misspelled, I didn't write it" -- Me -
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's 
why I draw cartoons. It's my life." -- Charles Shulz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] swapin flush cache bug

[NIIBE Yutaka]

Marcelo Tosatti wrote:
 > I think Stephen C. Tweedie has some considerations about the cache
 > flushing calls on do_swap_page().

Yup.  IIRC, he said that flushing cache at do_swap_page() (which I've
tried at first) is not good, because it's the hot path and it causes
another performance problem in apache or sendmail, where many
processes share the pages in swap cache.

Then, the fix I sent yesterday is second try.  The flush is moved to
I/O routine, instead of do_swap_page().

Actually, I really wonder why current code causes no problem in other
architectures.
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: RFC: Changes for PCI

[Pete Zaitcev]

> Well you have device drivers like the symbios scsi driver for instance that
> tries to determine if it's seen a card before. It does this by looking at the
> bus,dev etc numbers...

Can it be done by comparing struct pci_dev pointers for equal?

-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: RFC: Changes for PCI

[Jeff Garzik]

Tom Gall wrote:
> Well you have device drivers like the symbios scsi driver for instance that
> tries to determine if it's seen a card before. It does this by looking at the
> bus,dev etc numbers...  It's quite reasonable for two different scsi cards to be
> on the same bus number, same dev number etc yet they are in different PCI
> domains.
> 
> Is this a device driver bug or feature?

I hesitate to call it a device driver bug, because that was likely the
best decision Gerard could make at the time.

However, I think the driver (only going by your description) would be
more correct to use a pointer to struct pci_dev.  We have a token in the
kernel that is guaranteed 100% unique to any given PCI device:  the
pointer to its struct pci_dev.


> > Changing the meaning of dev->bus->number globally seems pointless.  If
> > you are going to do that, just do it the right way and introduce another
> > struct member, pci_domain or somesuch.
> 
> Right, one could do that and then all the large machine architectures would have
> their own implementation for the same problem. That's not necessarily a bad
> thing, but some commonality I think would be a good thing.

Sorry, not pci_domain, just system bus number, for any bus, like we
talked about in the previous discussion.

Jeff


-- 
Jeff Garzik  | Andre the Giant has a posse.
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/

[OT] Re: [comphist] Re: Microsoft and Xenix.

[Guest section DW]

On Wed, Jun 27, 2001 at 08:26:55AM -0500, Jesse Pollard wrote:

> a DF-32 for PDP 8 systems with 32 K bytes of disk space

32768 13-bit words (12-bit plus parity)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: RFC: Changes for PCI

[anton]

 
> Why not use sysdata like the other arches?
> 
> Changing the meaning of dev->bus->number globally seems pointless.  If
> you are going to do that, just do it the right way and introduce another
> struct member, pci_domain or somesuch.

Thats 2.5 material. For 2.4 we should do as davem suggested and make
the bus number unique. I do this by just adding 256 to each overlapping
host bridge.

Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: RFC: Changes for PCI

[anton]

Hi,

> The following 3 functions are added. Their purpose is a little
> different than to add support for more than 256 buses but they are
> important. Skip ahead and I'll explain what they are for
> 
> int (*pci_read_bases)(struct pci_dev *, int cnt,int rom);  /* These optional
> hooks provide */
> int (*pci_read_irq)(struct pci_dev *); /* the arch dependant
> code a way*/
> int (*pci_fixup_registers)(struct pci_dev *);  /* to manage the
> registers. */

I do not think these functions are required at all.

> The 3 additional functions are hooks so that an architecture has a
> chance to make sure things are in order beforehand. pci_read_bases is
> for the management and fixup of the BARs. pci_read_irq is the same but
> for IRQs.  pci_fixup_registers again same idea but for bridge
> resources.
> 
> The essense of the design here is to allow you to get in and make sure
> everything is ok with the card, bridge etc, beforehand so as to avoid
> multiple bus walks. 

Please look at how other architectures solve this problem. For example
on ppc32 we already fix up the BARs if required. There are also hooks
to fix the irq, you seem to be duplicating all of this.

Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: What is the best way for multiple net_devices

[andrew may]

On Wed, Jun 27, 2001 at 03:36:37PM -0700, Maksim Krasnyanskiy wrote:
> 
> >Any examples of drivers and apps that do this cleanly. The ones I have seen are not.
> TUN/TAP driver and tuncfg utility
> http://vtun.sf.net/tun

OK, thanks that is nice, but I think adding support to get into the /dev
namespace may be a little heavy for things like bonding or ipip.

I did not see tuncfg. From what I could see there were 2 ways to create
new devices. There was a script with mknod and then the ioctl(fd, TUNSETIFF, 
(void *) ).

I could do a similar ioctl for a pure net device but I still need a dummy
socket for creating/destroying devices.

I am going for an embedded system so I want to keep things light.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] User chroot

[Andries . Brouwer]

> Not that the documentation on MAP_ANON is any good either
> but at least the mere existence of the flag is mentioned.

> Seriously:
> both features ought to be documented in the man pages
> (I did submit a man page too, back in 1996)

Ah yes, I see. We both wrote a man page, and each contained
stuff not in the other, and I asked you to merge them, but
then nothing happened anymore. Maybe I should merge them
myself.

[In case you do the merging: please distinguish clearly
between what is prescribed by POSIX (or SUSv2, or Austin draft 7)
and what is implemented by (g)libc or the Linux kernel.
I see that your version has prototypes like
caddr_t mmap(caddr_t  addr, ...
but this caddr_t is typically from BSD, and is void * these days.]

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: RFC: Changes for PCI

[Tom Gall]

Jeff Garzik wrote:
> 
> Tom Gall wrote:
> >   The first part changes number, primary, and secondary to unsigned ints from
> > chars. What we do is encode the PCI "domain" aka PCI Primary Host Bridge, aka
> > pci controller in with the bus number. In our case we do it like this:
> >
> > pci_controller=dev->bus->number>>8) &0xFF
> > bus_number= dev->bus->number&0xFF),
> >
> >   Is this reasonable for everyone?
> 
> Why not use sysdata like the other arches?

Hi Jeff,

Well you have device drivers like the symbios scsi driver for instance that
tries to determine if it's seen a card before. It does this by looking at the
bus,dev etc numbers...  It's quite reasonable for two different scsi cards to be
on the same bus number, same dev number etc yet they are in different PCI
domains.

Is this a device driver bug or feature?

> Changing the meaning of dev->bus->number globally seems pointless.  If
> you are going to do that, just do it the right way and introduce another
> struct member, pci_domain or somesuch.

Right, one could do that and then all the large machine architectures would have
their own implementation for the same problem. That's not necessarily a bad
thing, but some commonality I think would be a good thing.
 
> Jeff

Regards,

Tom

-- 
Tom Gall - PPC64 Maintainer  "Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: wake_up vs. wake_up_sync

[Mike Kravetz]

On Wed, Jun 27, 2001 at 02:57:43PM -0700, Scott Long wrote:
> Does reschedule_idle() ever cause the current CPU to get scheduled? That
> is, if someone calls wake_up() and wakes up a higher-priority process
> could reschedule_idle() potentially immediately switch the current CPU
> to that higher-priority process?

No.  reschedule_idle() never directly performs a 'task to task' context
switch itself.  Instead, it simply marks a currently running task to
indicate that a reschedule is needed on that task's CPU.  No task context
switch will occur until schedule() is run on that CPU.

-- 
Mike Kravetz [EMAIL PROTECTED]
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: wake_up vs. wake_up_sync

[Manfred Spraul]

Mike Kravetz wrote:
> 
> On Wed, Jun 27, 2001 at 11:22:19PM +0200, Manfred Spraul wrote:
> > > Why would you want to prevent
> > > reschedule_idle()?
> > >
> > If one process runs, wakes up another process and _knows_ that it's
> > going to sleep immediately after the wake_up it doesn't need the
> > reschedule_idle: the current cpu will be idle soon, the scheduler
> > doesn't need to find another cpu for the woken up thread.
> 
> I'm curious.  How does the caller of wake_up_sync know that the
> current cpu will soon be idle.  Does it assume that there are no
> other tasks on the runqueue waiting for a CPU?  If there are other
> tasks on the runqueue, isn't it possible that another task has a
> higher goodness value than the task being awakened.  In such a case,
> isn't is possible that the awakened task could sit on the runqueue
> (waiting for a CPU) while tasks with a lower goodness value are
> allowed to run?
>

I found one combination where that could happen:

process.thread
A.1: highest priority, runs on cpu0
B.1: lowest priority, runs on cpu1
A.2: another thread of process A, priority
PROC_CHANGE_PENALTY+PRIORITY(B.1)+1, sleeping.
B.2: same priority as A.2, sleeping, same process as B.1

A.1:
{
wake_up("A.2");
/* nothing happens: preemption_goodness is 0 since B.1 has both
PROC_CHANGE_PENALTY and the += 1 from 'same mm'
*/
wake_up_sync("B.2");
schedule();
/* schedule selects A.2 instead of B.2 due to the += 1 from 'same mm'.
BUG: B.2 should replace B.1 on cpu1. The preemption_goodness is 1.
*/

IMHO obscure and very rare. 

But I just found a bigger problem:
If wake_up_sync wakes up more than 1 process then cpus could remain in
cpu_idle() although processes are on the runqueue without cpus.

--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: What is the best way for multiple net_devices

[Maksim Krasnyanskiy]

>Any examples of drivers and apps that do this cleanly. The ones I have seen are not.
TUN/TAP driver and tuncfg utility
http://vtun.sf.net/tun
  
Max

Maksim Krasnyanskiy 
Senior Kernel Engineer
Qualcomm Incorporated

[EMAIL PROTECTED]
http://bluez.sf.net
http://vtun.sf.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: What is the best way for multiple net_devices

[Stuart Lynne]

In article <[EMAIL PROTECTED]>,
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>andrew may wrote:
>> 
>> Is there a standard way to make multiple copies of a network device?
>> 
>> For things like the bonding/ipip/ip_gre and others they seem to expect
>> insmod -o copy1 module.o
>> insmod -o copy2 module.o
>
>The network driver should provide the capability to add new devices.
>
>Most drivers currently have the capability to do N devices, where N is
>some constant set at compile time.  Typically you use ifconfig, a
>special-purpose userland program, or sometimes even sysctls to configure
>additional net devices.

Ioctls require modifications to other parts of the kernel and a supporting
user land program.

Passing the number to create via insmod seems to be a reasonable compromise.

>It's certainly possible to modify the driver to create additional
>network interfaces on the fly, but a lot of drivers are not coded to do
>that at present.

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

Re: Cosmetic JFFS patch.

[Linus Torvalds]

On Wed, 27 Jun 2001, Alan Cox wrote:

> > I find printk's with copyright notices quite disturbing. You will notice
> > that I don't have any myself. I think the whole thing is very tasteless,
> > and the "polite reminder" is just complete crap.
>
> If someone took all references to your name out of the kernel and put it out
> as 'Foobaros' by Foobarco you might take a different view.

I don't _have_ any instances of my name being printed out to annoy the
user, so that's a very theoretical argument.

> Intentionally or otherwise in the change thats what the JFFS argument is about.

This is my current patch in my tree. I refuse to have bickering in
printk's. You can edit the comment all you want.

Linus

-
diff -urN v2.4.5/linux/fs/jffs/inode-v23.c linux/fs/jffs/inode-v23.c
--- v2.4.5/linux/fs/jffs/inode-v23.cSun May 20 11:35:00 2001
+++ linux/fs/jffs/inode-v23.c   Wed Jun 27 13:51:50 2001
@@ -16,6 +16,7 @@
  * Ported to Linux 2.3.x and MTD:
  * Copyright (C) 2000  Alexander Larsson ([EMAIL PROTECTED]), Cendio Systems AB
  *
+ * Copyright 2000, 2001  Red Hat, Inc.
  */

 /* inode.c -- Contains the code that is called from the VFS.  */
@@ -1719,9 +1720,6 @@
 static int __init
 init_jffs_fs(void)
 {
-   printk("JFFS version "
-  JFFS_VERSION_STRING
-  ", (C) 1999, 2000  Axis Communications AB\n");
return register_filesystem(_fs_type);
 }


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: What is the best way for multiple net_devices

[andrew may]

On Wed, Jun 27, 2001 at 06:04:02PM -0400, Jeff Garzik wrote:
> andrew may wrote:
> > 
> > Is there a standard way to make multiple copies of a network device?
> > 
> > For things like the bonding/ipip/ip_gre and others they seem to expect
> > insmod -o copy1 module.o
> > insmod -o copy2 module.o
> 
> The network driver should provide the capability to add new devices.

I am planning to write or patch some drivers to do this as well as other
things. 

I would want to add things at run time after the module is alreaded loaded.
So options to the module won't work.

I don't know how to use ifconfig to create a new device.

Any examples of drivers and apps that do this cleanly. The ones I have
seen are not.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: RFC: Changes for PCI

[Jeff Garzik]

Tom Gall wrote:
>   The first part changes number, primary, and secondary to unsigned ints from
> chars. What we do is encode the PCI "domain" aka PCI Primary Host Bridge, aka
> pci controller in with the bus number. In our case we do it like this:
> 
> pci_controller=dev->bus->number>>8) &0xFF
> bus_number= dev->bus->number&0xFF),
> 
>   Is this reasonable for everyone?

Why not use sysdata like the other arches?

Changing the meaning of dev->bus->number globally seems pointless.  If
you are going to do that, just do it the right way and introduce another
struct member, pci_domain or somesuch.

Jeff


-- 
Jeff Garzik  | Andre the Giant has a posse.
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: PROBLEM:Illegal instruction when mount nfs file systems using cyr ixIII

[Alan Cox]

> The problem is that VIA Cyrix III announces itself (via CPUID)
> as a "family 6" processor, i.e. i686 compatible. This is not
> completely accurate, since it doesn't implement the conditional
> move instruction. [Yeah, I know there's a CPUID feature flag for

Intel specifically state that you cannot use CMOV without checking
for it. Its actually a gcc/binutils tool bug. The CPU is right.

> To make the machine work you'll have to ensure that the kernel,
> user-space libraries and programs, and NFS-imported programs
> all are compiled for a lesser CPU than i686.

For RH 

rpm -qa |grep ".i686*"

and update the packages listed with their i586/i386 ones. 

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: Cosmetic JFFS patch.

[Alan Cox]

> I find printk's with copyright notices quite disturbing. You will notice
> that I don't have any myself. I think the whole thing is very tasteless,
> and the "polite reminder" is just complete crap.

If someone took all references to your name out of the kernel and put it out
as 'Foobaros' by Foobarco you might take a different view.

Intentionally or otherwise in the change thats what the JFFS argument is about.

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

RFC: Changes for PCI

[Tom Gall]

Hi All,

  I'm looking for commentary on the following. As you might recall I had posted
a note a few days back on the lkml about the kinds of systems ppc64 runs on and
the reality of having a boatload of PCI buses out there. 

  I sure appreciate all the comments and feedback.

  Today appended below are two patches that address more or less how we've
solved the problem for ppc64 from an architecture independant standpoint.
Hopefully you will find these patches reasonable or at a minimum a starting part
for more discussion to make this happen. (Our ppc64 work is at linuxppc64.org or
in my dir on kernel.org pub/linux/kernel/people/tgall if you're interested)

  Part one is the following changes to include/linux/pci.h

  The first part changes number, primary, and secondary to unsigned ints from
chars. What we do is encode the PCI "domain" aka PCI Primary Host Bridge, aka
pci controller in with the bus number. In our case we do it like this: 

pci_controller=dev->bus->number>>8) &0xFF 
bus_number= dev->bus->number&0xFF),

  Is this reasonable for everyone?

  subordinate probably doesn't need to go to an int really when I come to think
about it as it can fit in a char, but how about in the future? A switch to an
unsigned int as well seemed prudent.

  The following 3 functions are added. Their purpose is a little different than
to add support for more than 256 buses but they are important. Skip ahead and
I'll explain what they are for

int (*pci_read_bases)(struct pci_dev *, int cnt,int rom);  /* These optional
hooks provide */
int (*pci_read_irq)(struct pci_dev *); /* the arch dependant
code a way*/
int (*pci_fixup_registers)(struct pci_dev *);  /* to manage the
registers. */


--- linux-2.4.5-ac18/include/linux/pci.hTue Jun 26 21:59:23 2001
+++ linuxppc64_2_4/include/linux/pci.h  Wed Jun 27 13:36:26 2001
@@ -60,6 +60,8 @@
 #define PCI_CACHE_LINE_SIZE0x0c/* 8 bits */ 
 #define PCI_LATENCY_TIMER  0x0d/* 8 bits */ 
 #define PCI_HEADER_TYPE0x0e/* 8 bits */ 
+
+#define  PCI_MULTIFUNCTION_CARD 0x80 /* Multi-function bit in header. */
 #define  PCI_HEADER_TYPE_NORMAL0
 #define  PCI_HEADER_TYPE_BRIDGE 1
 #define  PCI_HEADER_TYPE_CARDBUS 2
@@ -294,6 +296,13 @@
 #define PCIIOC_MMAP_IS_MEM (PCIIOC_BASE | 0x02)/* Set mmap state to MEM
space. */
 #define PCIIOC_WRITE_COMBINE   (PCIIOC_BASE | 0x03)/* Enable/disable
write-combining. */
 
+/* Ioctls for /proc/bus/pci/X/Y nodes. */
+#define PCIIOC_BASE('P' << 24 | 'C' << 16 | 'I' << 8)
+#define PCIIOC_CONTROLLER  (PCIIOC_BASE | 0x00)/* Get controller for PCI
device. */
+#define PCIIOC_MMAP_IS_IO  (PCIIOC_BASE | 0x01)/* Set mmap state to I/O
space. */
+#define PCIIOC_MMAP_IS_MEM (PCIIOC_BASE | 0x02)/* Set mmap state to MEM
space. */
+#define PCIIOC_WRITE_COMBINE   (PCIIOC_BASE | 0x03)/* Enable/disable
write-combining. */
+
 #ifdef __KERNEL__
 
 #include 
@@ -409,10 +418,10 @@
void*sysdata;   /* hook for sys-specific extension */
struct proc_dir_entry *procdir; /* directory entry in /proc/bus/pci */
 
-   unsigned char   number; /* bus number */
-   unsigned char   primary;/* number of primary bridge */
-   unsigned char   secondary;  /* number of secondary bridge */
-   unsigned char   subordinate;/* max number of subordinate buses */
+   unsigned int  number;   /* pci_controller number + bus number */
+   unsigned int  primary;  /* number of primary bridge */
+   unsigned int  secondary;/* number of secondary bridge */
+   unsigned int  subordinate;  /* max number of subordinate buses */
 
charname[48];
unsigned short  vendor; 
@@ -449,6 +458,9 @@
int (*write_byte)(struct pci_dev *, int where, u8 val);
int (*write_word)(struct pci_dev *, int where, u16 val);
int (*write_dword)(struct pci_dev *, int where, u32 val);
+   int (*pci_read_bases)(struct pci_dev *, int cnt,int rom);  /* These optional
hooks provide */
+   int (*pci_read_irq)(struct pci_dev *); /* the arch
dependant code a way*/
+   int (*)(struct pci_dev *);  /* to manage the registers. */
 };
 
 struct pbus_set_ranges_data

The other file we changed is drivers/pci/pci.c

  The 3 additional functions are hooks so that an architecture has a chance to
make sure things are in order beforehand. pci_read_bases is for the management
and fixup of the BARs. pci_read_irq is the same but for IRQs.
pci_fixup_registers again same idea but for bridge resources.

  The essense of the design here is to allow you to get in and make sure
everything is ok with the card, bridge etc, beforehand so as to avoid multiple
bus walks. 

diff -u linux-2.4.5-ac18/drivers/pci/pci.c linuxppc64_2_4/drivers/pci/pci.c
--- linux-2.4.5-ac18/drivers/pci/pci.c  Tue Jun 26 21:55:54 2001
+++ linuxppc64_2_4/drivers/pci/pci.cTue Jun 26 08:09:31 2001
@@ -1,5 +1,5 @@
 /*
- * $Id: pci.c,v 1.91 1999/01/21 13:34:01 davem Exp $
+ *
  *
  * 

Re: What is the best way for multiple net_devices

[Jeff Garzik]

andrew may wrote:
> 
> Is there a standard way to make multiple copies of a network device?
> 
> For things like the bonding/ipip/ip_gre and others they seem to expect
> insmod -o copy1 module.o
> insmod -o copy2 module.o

The network driver should provide the capability to add new devices.

Most drivers currently have the capability to do N devices, where N is
some constant set at compile time.  Typically you use ifconfig, a
special-purpose userland program, or sometimes even sysctls to configure
additional net devices.

It's certainly possible to modify the driver to create additional
network interfaces on the fly, but a lot of drivers are not coded to do
that at present.

-- 
Jeff Garzik  | Andre the Giant has a posse.
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: Allocating non-contigious memory

[Alan Cox]

> Would it be useful to turn that particular code into a subroutine that
> is called from each driver, or would that cause other problems?

It would but then I suspect Linus wouldnt want to take it as it might
encourage people to use it 8)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: wake_up vs. wake_up_sync

[Scott Long]

Does reschedule_idle() ever cause the current CPU to get scheduled? That
is, if someone calls wake_up() and wakes up a higher-priority process
could reschedule_idle() potentially immediately switch the current CPU
to that higher-priority process?

Because this is NOT what I want to happen (it would produce a deadlock
in this particular situation). Having other CPUs get scheduled is ok,
but having the process that called wake_up() get kicked out would be
very bad. In that case I suppose I will have to use wake_up_sync().

Would the following be an appropriate solution?

{
wake_up_sync(>q);

/* Potential deadlock situation */
user_unlock(>lock);

/* Potential for deadlock has passed */
reschedule_idle();
}

Thanks,
Scott

Manfred Spraul wrote:
> 
> > I'm having trouble understanding the difference between these.
> > Synchronous apparently causes try_to_wake_up() to NOT call
> > reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I
> > assume it just looks for an idle CPU and makes that CPU reschedule.
> >
> > What is the purpose of wake_up_sync?
> 
> Avoid the reschedule_idle() call - it's quite costly, and it could cause
> processes jumping from one cpu to another.
> 
> > Why would you want to prevent
> > reschedule_idle()?
> >
> If one process runs, wakes up another process and _knows_ that it's
> going to sleep immediately after the wake_up it doesn't need the
> reschedule_idle: the current cpu will be idle soon, the scheduler
> doesn't need to find another cpu for the woken up thread.
> 
> I think the pipe code is the only user of _sync right now - pipes cause
> an incredible amount of task switches.
> 
> --
> Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Andre Hedrick]

Gunther,

It fixes a BUG in CFA, but what will it do to the other stuff?
Parse it exclusive to CFA and there is not an issue.

Also look closely

No all ./arch have a control register doing this randomly without know the
rest of the driver will kill more than it fixes.

static int try_to_identify (ide_drive_t *drive, byte cmd)
{
int rc;
ide_ioreg_t hd_status;
unsigned long timeout;
unsigned long irqs = 0;
byte s, a;

if (IDE_CONTROL_REG) {

} else {
ide_delay_50ms();
hd_status = IDE_STATUS_REG;
}

}

It will not be accepted until it correctly address and handles all HOSTs
correctly, period.

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

On Wed, 27 Jun 2001, Gunther Mayer wrote:

> Andre Hedrick wrote:
> > 
> > PARANIOA.
> 
> This is not a valid reason.
> 
> This clearly fixes a bug in linux. Note: the irq disable
> is local to ide-cs. Are you paranoid enough to believe
> enabling the irq by writing globally to the control register that
> existed since ATA will have ill effects? 
> 
> You claim the relevant PCMCIA ATA behaviour is not ATA(>3?) compliant,
> however you didn`t yet give any facts to support this !
> 
> You claim this locks the driver, again no facts.
> 
> 
> > 
> > Remember that ATAPI is generally screwed beyond reality, so adjusting the
> > probe code in general (global) is a bad thing.
> ...
> > On Wed, 27 Jun 2001, Alan Cox wrote:
> > 
> > > > obsoleting ATA-2 did their attention at CFA become alarmed.  I agree that
> > > > there needs to be a fix, but not at the price of locking the rest of the
> > > > driver.  Since we now the identity of the device prior to assigned the
> > > > interrupt we can handle the execption, but you do not go around blanket
> > > > wacking the control register of all devices.
> 
> The proposed patch is very simple (as per Linus' liking). When considering to
> install an earlier (and  global) irq handler I believe you can see
> this will impose a much greater risk !
> 
> > >
> > > I dont see why it locks up the driver ?
> 


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

What is the best way for multiple net_devices

[andrew may]

Is there a standard way to make multiple copies of a network device?

For things like the bonding/ipip/ip_gre and others they seem to expect
insmod -o copy1 module.o
insmod -o copy2 module.o

It seems to me that this will waste space creating copies of all the 
static data.

Then there are things like ipsec that create a few static net_dev
structures, but I have no idea how they deal with more entries. 
They probably don't.

The PCI drivers seem to be pretty clean with init_one type functions.

Is there anything similar for generic hardware-less network devices.

I would hate to have write an ioctl to create a new device without
loading a module twice.

--
Andrew May
[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: wake_up vs. wake_up_sync

[Mike Kravetz]

On Wed, Jun 27, 2001 at 11:22:19PM +0200, Manfred Spraul wrote:
> > Why would you want to prevent
> > reschedule_idle()?
> > 
> If one process runs, wakes up another process and _knows_ that it's
> going to sleep immediately after the wake_up it doesn't need the
> reschedule_idle: the current cpu will be idle soon, the scheduler
> doesn't need to find another cpu for the woken up thread.

I'm curious.  How does the caller of wake_up_sync know that the
current cpu will soon be idle.  Does it assume that there are no
other tasks on the runqueue waiting for a CPU?  If there are other
tasks on the runqueue, isn't it possible that another task has a
higher goodness value than the task being awakened.  In such a case,
isn't is possible that the awakened task could sit on the runqueue
(waiting for a CPU) while tasks with a lower goodness value are
allowed to run?

-- 
Mike Kravetz [EMAIL PROTECTED]
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] proc_file_read() (Was: Re: proc_file_read() question)

[Roman Zippel]

Hi,

Martin Wilck wrote:

> Hum - is there no simple way to determine whether a pointer is
> a valid pointer to something returned by __get_free_pages ()? You are
> right, S390 in particular seems to allow arbitrary addresses starting from
> 0.

M68k does so too, although the first page is never used and usually
unmapped to catch NULL pointers.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Allocating non-contigious memory

[Riley Williams]

Hi Alan.

 >> What is the Right Way[tm] as of 2.4.6 to allocate 16Mb as 4K
 >> pages and get the pci bus address for each page?  Bonus points
 >> is they're virtually contiguous, but that's not necessary.
 >> IIRC, the old vmalloc-then-walk-the-pagetables trick is
 >> considered out-of-bounds nowadays.

 > If you want it virtually contiguous then copy the code from bttv
 > that out-of-bounds or otherwise is now found in about 8 drivers
 > in the kernel.

Would it be useful to turn that particular code into a subroutine that
is called from each driver, or would that cause other problems?

Best wishes from Riley.

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

sched.h problem in 2.4.x and new gcc compilers

[Gonzalo Aguilar]

Hello, there is a little problem with some headers and
new glibs and compilers. Kernel fails to compile and worst
is the extern declaration in sched.h

Don't if this is a gcc or glib problem (surely gcc) but doesn't
works...

The patch is only redeclaring xtime in extern:

*** cut here **
--- include/linux/sched.h   Wed Jun 27 23:19:04 2001
+++ include/linux/sched.h~  Thu Jun 21 12:36:26 2001
@@ -537,7 +537,7 @@
 extern unsigned long volatile jiffies;
 extern unsigned long itimer_ticks;
 extern unsigned long itimer_next;
-extern volatile struct timeval xtime __attribute__ ((aligned (16)));
+extern struct timeval xtime;
 extern void do_timer(struct pt_regs *);
 
 extern unsigned int * prof_buffer;
* cut here **

I made it with the copy that joe editor does, you know the change is:

-extern volatile struct timeval xtime __attribute__ ((aligned (16)));
+extern struct timeval xtime;

There are other problems with multiline string literals all over the
code
but this is only a warning... One is this...

/mnt/hd2/src/linux-2.4.5/include/asm/checksum.h:72:30: warning:
multi-line string literals are deprecated

Hope it helps. It's a ridiculous patch but now it's fixed.

Thanks
-- 
Gonzalo Aguilar. Madrid, España (Spain) |
Reymad Studios | [EMAIL PROTECTED] |
Privado| [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: (reposting) how to get DMA'able memory within 4GB on 64-bit machine

[David S. Miller]

MEHTA,HIREN (A-SanJose,ex1) writes:
 > Is there a way for a driver to ask kernel to
 > give DMA'able memory within 4GB ? I read about
 > pci_alloc_consistent(). But I could not find out
 > whether that guarantees the DMA'able memory to be
 > within 4GB or not. Is there any other kernel routine
 > that I should call from Driver to get such a memory ?

All of the pci_*() DMA allocation/mapping interfaces give you
32-bit PCI dma addresses.

Later,
David S. Miller
[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: wake_up vs. wake_up_sync

[Manfred Spraul]

> I'm having trouble understanding the difference between these.
> Synchronous apparently causes try_to_wake_up() to NOT call
> reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I
> assume it just looks for an idle CPU and makes that CPU reschedule.
> 
> What is the purpose of wake_up_sync?

Avoid the reschedule_idle() call - it's quite costly, and it could cause
processes jumping from one cpu to another.

> Why would you want to prevent
> reschedule_idle()?
> 
If one process runs, wakes up another process and _knows_ that it's
going to sleep immediately after the wake_up it doesn't need the
reschedule_idle: the current cpu will be idle soon, the scheduler
doesn't need to find another cpu for the woken up thread.

I think the pipe code is the only user of _sync right now - pipes cause
an incredible amount of task switches.

--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] User chroot

[Albert D. Cahalan]

H. Peter Anvin writes:
> "Albert D. Cahalan" wrote:

>> BTW, it is way wrong that /dev/zero should be needed at all.
>> Such use is undocumented ("man zero", "man mmap") anyway, and
>> AFAIK one should use mmap() with MAP_ANON instead. Not that
>> the documentation on MAP_ANON is any good either, but at least
>> the mere existence of the flag is mentioned.
>
> RTFM(POSIX).

No manual entry for RTFM in section POSIX

Seriously:

1. both features ought to be documented in the man pages
   (I did submit a man page too, back in 1996)

2. it is slow and nasty to open /dev/zero for getting memory
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: When the FUD is all around (sniff).

[Fabrice Gautier]

On Tue, 26 Jun 2001 14:33:03 +0200
Alessandro Suardi <[EMAIL PROTECTED]> wrote:

> 
> I have trouble in finding words to describe such blatant ignorance.


A Troll ?

oh.. geez, this was not something on the internet...

-- 
Fabrice Gautier <[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] User chroot

[H. Peter Anvin]

"Albert D. Cahalan" wrote:
> 
> BTW, it is way wrong that /dev/zero should be needed at all.
> Such use is undocumented ("man zero", "man mmap") anyway, and
> AFAIK one should use mmap() with MAP_ANON instead. Not that
> the documentation on MAP_ANON is any good either, but at least
> the mere existence of the flag is mentioned.
> 

RTFM(POSIX).

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: BSD sockets with sys_socketcall

[Matti Aarnio]

On Wed, Jun 27, 2001 at 12:23:27PM -0700, Prasad Koya wrote:
> How does socket(), bind() and other BSD socket API
> calls in user applications are handled by system
> socketcall(). Does the compiler (say gcc) substitute
> socket() in user app with socketcall(SYS_SOCKET,..)?

   You are using libc wrappers which translate the BSD API
   to Linux kernel ABI.

> Thanks

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

Re: [PATCH] User chroot

[Albert D. Cahalan]

H. Peter Anvin writes:
> Albert D. Cahalan wrote:

>> Normal users can use an environment provided for them.
>>
>> While trying to figure out why the "heyu" program would not
>> work on a Red Hat box, I did just this. As root I set up all
>> the device files needed, along Debian libraries and the heyu
>> executable itself. It was annoying that I couldn't try out
>> my chroot environment as a regular user.
>>
>> Creating the device files isn't a big deal. It wouldn't be
>> hard to write a setuid app to make the few needed devices.
>> If we had per-user limits, "mount --bind /dev/zero /foo/zero"
>> could be allowed. One way or another, devices can be provided.
>
> Hell no!  This would give the user a way to subvert root or other
> system-provided things by having device nodes or such appear where
> they aren't expected.  NOT GOOD.

On every normal (default Red Hat or Debian at least) system
this is already trivial:

ln /dev/zero /tmp/zero
ln /dev/hda ~/hda
ln /dev/mem /var/tmp/README

So the user often can provide device nodes. The above is _worse_
than allowing "mount --bind ..." because the admin has to search
the whole filesystem to find such links.

Never mind that though; it doesn't matter how the devices are
created. Social engineering can work. Once the device problem
is taken care of, chroot() becomes useful for normal users.

BTW, it is way wrong that /dev/zero should be needed at all.
Such use is undocumented ("man zero", "man mmap") anyway, and
AFAIK one should use mmap() with MAP_ANON instead. Not that
the documentation on MAP_ANON is any good either, but at least
the mere existence of the flag is mentioned.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Re: AMD thunderbird oops

[Luigi Genoni]

On Wed, 27 Jun 2001 [EMAIL PROTECTED] wrote:

> Well considering the other night the power supply went dead, I think that is part of 
>the problem.  It is brand new, and I am being sent another one (free of course).
I would have bet that power supply was erogating elettricity with a
discontinous intensity.
I saw that RAM stability is the first think to be affected (together
with L2 cache stability) in those cases.
>
> I also had my mb loaded at the time (scsi cd-rw, cdrom, internal zip, floppy, 1 hd, 
>Sound card, video, modem, NIC, scsi card) but my last tyan was fine with that load it 
>may be a kt7a thing.
>
> Several people said that random (keyword here) oopses are more often a hardware 
>thing.  I wonder if the kt7a is going to be able to perform  fully loaded..
>
> is anyone running one fully loaded? 4 ide drives, 2 floppy, (5 pci and 1 isa) or 
>6pci, agp, 512MEG+ RAM?

yes,

1.300 Mhz

1 agp
4 pci
1 isa (I love my sound blaster 16 on ISA, could not live without)
3 disks
1 floppy
1 zip
1 dvd
5 fans

350 watt power supply.


Luigi

> Joe
>
> Dave Jones <[EMAIL PROTECTED]> wrote:
> > On Tue, 26 Jun 2001, Alan Cox wrote:
> > My current speculation is that the sdram setup on some of these boards can't
> > actually take the full CPU spec caused by these hand tuned routines. There is
> > some evidence to support that as several other boards only work with Athlon
> > optimisation if you set the BIOS options to 'conservative' not 'optimised'
>
> Interesting, and plausable theory. It would be more interesting to see
> register dumps of the memory timing registers on both good and bad
> systems, to see if this is the case.
>
> Unfortunatly afair the register level specs of all the affected chipsets
> are not available.
>
> regards,
>
> Dave.
>
> --
> | Dave Jones.http://www.suse.de/~davej
> | SuSE Labs
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Gunther Mayer]

Andre Hedrick wrote:
> 
> PARANIOA.

This is not a valid reason.

This clearly fixes a bug in linux. Note: the irq disable
is local to ide-cs. Are you paranoid enough to believe
enabling the irq by writing globally to the control register that
existed since ATA will have ill effects? 

You claim the relevant PCMCIA ATA behaviour is not ATA(>3?) compliant,
however you didn`t yet give any facts to support this !

You claim this locks the driver, again no facts.


> 
> Remember that ATAPI is generally screwed beyond reality, so adjusting the
> probe code in general (global) is a bad thing.
...
> On Wed, 27 Jun 2001, Alan Cox wrote:
> 
> > > obsoleting ATA-2 did their attention at CFA become alarmed.  I agree that
> > > there needs to be a fix, but not at the price of locking the rest of the
> > > driver.  Since we now the identity of the device prior to assigned the
> > > interrupt we can handle the execption, but you do not go around blanket
> > > wacking the control register of all devices.

The proposed patch is very simple (as per Linus' liking). When considering to
install an earlier (and  global) irq handler I believe you can see
this will impose a much greater risk !

> >
> > I dont see why it locks up the driver ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Cosmetic JFFS patch.

[Linus Torvalds]

On Tue, 26 Jun 2001, David Woodhouse wrote:
>
> Linus, Alan - Please apply the following self-explanatory patch.

How about we drop the "printk" altogether, and make it all a comment?

I find printk's with copyright notices quite disturbing. You will notice
that I don't have any myself. I think the whole thing is very tasteless,
and the "polite reminder" is just complete crap.

You're allowed to remove offensive printk's, that's not a copyright notice
in Linux, that's just a big ugly bother. The copyright notice is that big
comment at the top of the file.

Linus

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

Oops at boot with 2.4.5

[Manuel A. McLure]

When I use an initrd, sometimes when warm-booting I get an "Unable to handle
kernel NULL pointer dereference"  OOPS just after the "Trying to unmount old
root ..." message. I ran gdb on vmlinux and got the following stack trace:

0xc0180516 :  mov0x10(%eax),%eax
0xc0137c37 : mov%edi,0xc(%ebx)
0xc01861a0 : add$0xc,%esp
0xc01864d3 :mov%eax,%ebx
0xc0112949 :  pop%ebp
0xc0132be1 <__refile_buffer+97>:pop%ecx
0xc018047a :   xor%eax,%eax
0xc01347eb :   mov$0x1,%eax
0xc0133062 :   test   %eax,%eax
0xc0123905 :   mov$0x1,%eax
0xc01431af :  pop%eax
0xc01447b0 :  pop%ecx
0xc0137e46 :add$0xc,%esp
0xc0135edc :add$0xc,%esp
0xc0105000 :push   %edi
0xc0117ba3 :add$0x10,%esp
0xc0105000 :push   %edi
0xc01051e8 : pop%edx
0xc010520e :   call   0xc0111a60 
0xc0105000 :push   %edi
0xc01056c6 :  mov$0x1,%eax
0xc0105200 :  push   %ebp

A reset at this point usually (but not always) succeeds in booting, and once
the machine succeeds in booting it is completely stable (for my admittedly
low load).

Hardware is an Athlon Tbird 900MHz (not overclocked) on an MSI K7T Turbo-R
motherboard. I've worked around this by building my SCSI driver into the
kernel and removing the need for an initrd.

Kernel is official 2.4.5 built with Athlon optimizations.

--
Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]>
Zathras is used to being beast of burden to other peoples needs. Very sad
life. Probably have very sad death, but at least there is symmetry.
 



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

wake_up vs. wake_up_sync

[Scott Long]

I'm having trouble understanding the difference between these.
Synchronous apparently causes try_to_wake_up() to NOT call
reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I
assume it just looks for an idle CPU and makes that CPU reschedule.

What is the purpose of wake_up_sync? Why would you want to prevent
reschedule_idle()?

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

Re: PROBLEM:Illegal instruction when mount nfs file systems using cyr ixIII

[Mikael Pettersson]

On Wed, 27 Jun 2001 17:42:01 +0800, Frank Zhu wrote:

>I use a PIII machine as the server and cyrixIII machine as the client.The
>kernel is 2.4.5.The distribute is red hat 7.1
>when i mount the nfs file system at the client it failed.The core file is
>created.using the gdb it report  :
>Program terminated with signal 4(SIGILL),Illegal instruction
>#0  0x40003e28 in ??()
>
>If i change the cpu (CyrixIII) to PIII all is ok.

You don't say exactly where the failure occurs, but I suspect
that you're feeding i686-class machine code to your VIA Cyrix III.

The problem is that VIA Cyrix III announces itself (via CPUID)
as a "family 6" processor, i.e. i686 compatible. This is not
completely accurate, since it doesn't implement the conditional
move instruction. [Yeah, I know there's a CPUID feature flag for
CMOV. I also know gcc doesn't check it, and I suspect glibc
doesn't either.]

To make the machine work you'll have to ensure that the kernel,
user-space libraries and programs, and NFS-imported programs
all are compiled for a lesser CPU than i686.

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

Re: How to change DVD-ROM speed?

[Jens Axboe]

On Wed, Jun 27 2001, Jesse Pollard wrote:
> > Excellent. I'd say use the same ioctl if you can, but default to using
> > SET_STREAMING for DVD drives.
> 
> As long as it still works for the combo drives - CD/CD-RW/DVD
> Sony VIAO high end laptops, Toshiba has one, maybe others by now.

As long as it has the DVD features, SET_STREAMING must be supported. So
provided that the combos adhere to that part of the spec (ha), it will
work.

-- 
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: Re: AMD thunderbird oops

[joeja]

Well considering the other night the power supply went dead, I think that is part of 
the problem.  It is brand new, and I am being sent another one (free of course).  

I also had my mb loaded at the time (scsi cd-rw, cdrom, internal zip, floppy, 1 hd, 
Sound card, video, modem, NIC, scsi card) but my last tyan was fine with that load it 
may be a kt7a thing. 

Several people said that random (keyword here) oopses are more often a hardware thing. 
 I wonder if the kt7a is going to be able to perform  fully loaded.. 

is anyone running one fully loaded? 4 ide drives, 2 floppy, (5 pci and 1 isa) or 6pci, 
agp, 512MEG+ RAM?

Joe 

Dave Jones <[EMAIL PROTECTED]> wrote:
> On Tue, 26 Jun 2001, Alan Cox wrote:
> My current speculation is that the sdram setup on some of these boards can't
> actually take the full CPU spec caused by these hand tuned routines. There is
> some evidence to support that as several other boards only work with Athlon
> optimisation if you set the BIOS options to 'conservative' not 'optimised'

Interesting, and plausable theory. It would be more interesting to see
register dumps of the memory timing registers on both good and bad
systems, to see if this is the case.

Unfortunatly afair the register level specs of all the affected chipsets
are not available.

regards,

Dave.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs


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

Re: Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Andre Hedrick]

PARANIOA.

Remember that ATAPI is generally screwed beyond reality, so adjusting the
probe code in general (global) is a bad thing.

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

On Wed, 27 Jun 2001, Alan Cox wrote:

> > obsoleting ATA-2 did their attention at CFA become alarmed.  I agree that
> > there needs to be a fix, but not at the price of locking the rest of the
> > driver.  Since we now the identity of the device prior to assigned the
> > interrupt we can handle the execption, but you do not go around blanket
> > wacking the control register of all devices.
> 
> I dont see why it locks up the driver ?
> 
> 

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

Re: How to change DVD-ROM speed?

[Jeffrey W. Baker]

On Wed, 27 Jun 2001, Jesse Pollard wrote:

> As long as it still works for the combo drives - CD/CD-RW/DVD
> Sony VIAO high end laptops, Toshiba has one, maybe others by now.

OK when I send the patch I'll assume you will test it :)

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

Re: How to change DVD-ROM speed?

[Jesse Pollard]

> 
> On Wed, Jun 27 2001, Jeffrey W. Baker wrote:
> > > On Wed, Jun 27 2001, Jeffrey W. Baker wrote:
> > > > I am trying to change the spin rate of my IDE DVD-ROM drive.  My system is
> > > > an Apple PowerBook G4, and I am using kernel 2.4.  I want the drive to
> > > > spin at 1X when I watch movies.  Currently, it spins at its highest speed,
> > > > which is very loud and a large power load.
> > > >
> > > > /proc/sys/dev/cdrom/info indicates that the speed of the drive can be
> > > > changed.  I use hdparm -E 1 /dev/dvd to attempt to set the speed, and it
> > > > reports success.  However, the drive continues to spin at its highest
> > > > speed.
> > >
> > > Linux still uses the old-style SET_SPEED command, which is probably not
> > > supported correctly by your newer drive. Just checking, I see latest Mt
> > > Fuji only lists it for CD-RW. For DVD, we're supposed to do
> > > SET_STREAMING to specify such requirements.
> > >
> > > Feel free to implement it :-)
> > 
> > I will be happy to :)  Should I hang conditional code off the existing
> > ioctl (CDROM_SELECT_SPEED, ide_cdrom_select_speed) or use a new one?
> 
> Excellent. I'd say use the same ioctl if you can, but default to using
> SET_STREAMING for DVD drives.

As long as it still works for the combo drives - CD/CD-RW/DVD
Sony VIAO high end laptops, Toshiba has one, maybe others by now.

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

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

PATCH (2.4.5): /dev/poll support (3rd time lucky)

[Zarjazz]

Not my day it seems ! Hopefully I remembered to attach the file this time :)

--

Hi,
this patch adds Solaris 7/8 like /dev/poll support to the kernel.

I can claim no real credit for this as basically this is a fixed version of
a patch available from http://www.citi.umich.edu/projects/linux-scalability/
to compile correctly with 2.4.5 that only seemed to work with the 2.3.x
devel branch. The reason for this is so I can compile & test an application
on my home linux pc when I'm not around my nice work Solaris boxes :)

Please note, I have not got the knowledge of kernel development to know if
this patch is broken or badly written. It may be bugged and/or worse than
the standard poll() call but my application works so I'll leave profiling
etc to people more knowledgable than me.

Vince.



 devpoll-2.4.5.patch

PATCH (2.4.5): /dev/poll support

[Vincent Sweeney]

I think pgp-signing just barfed my last email (typical) so I'm retyping /
resending this:

Hi,
this patch adds Solaris 7/8 like /dev/poll support to the kernel.

I can claim no real credit for this as basically this is a fixed version of
a patch available from http://www.citi.umich.edu/projects/linux-scalability/
to compile correctly with 2.4.5 that only seemed to work with the 2.3.x
devel branch. The reason for this is so I can compile & test an application
on my home linux pc when I'm not around my nice work Solaris boxes :)

Please note, I have not got the knowledge of kernel development to know if
this patch is broken or badly written. It may be bugged and/or worse than
the standard poll() call but my application works so I'll leave profiling
etc to people more knowledgable than me.

Vince.


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

BSD sockets with sys_socketcall

[Prasad Koya]

How does socket(), bind() and other BSD socket API
calls in user applications are handled by system
socketcall(). Does the compiler (say gcc) substitute
socket() in user app with socketcall(SYS_SOCKET,..)?

Also, why don't I see _syscallN() macro for socketcall
or any other BSD socket calls? 

I'd greatly appreciate your help.

Please CC to [EMAIL PROTECTED] as I don't subscribe to
the mailing list.

Thanks


__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.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/

PATCH (2.4.5): /dev/poll support

[Vincent Sweeney]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

more knowledgable than me can 

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 7.0.3 for non-commercial use 

iQA/AwUBOzoyDz8f58rgPfa4EQIQRwCgxPE/JcNHuegj9fEklY7uhJr8O5UAnAtq
W46SBMHzCtsQYznIaKHFB8a+
=UaUj
-END PGP SIGNATURE-


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 at inode.c:486! (2.4.5)

[Soeren Sonnenburg]

This happens here from time to time :-(

Is it fixed in some 2.4.6preX ?

Soeren.

==snip

kernel BUG at inode.c:486!
invalid operand: 
CPU:0
EIP:0010:[load_aout_library+19/640]
EFLAGS: 00010286
eax: 001b   ebx: e43baa80   ecx: d7f54000   edx: e3801ac0
esi: c029f200   edi: e3e57940   ebp: d7f55fa4   esp: d7f55edc
ds: 0018   es: 0018   ss: 0018
Process latex (pid: 24761, stackpage=d7f55000)
Stack: c024ab70 c024abcf 01e6 e43baa80 c0142df7 e43baa80 e2ea6240
e43baa80
   c01689fd e43baa80 c01406f6 e2ea6240 e43baa80 e2ea6240 
c01390e8
   e2ea6240 d7f55f58 c013982a e3e57940 d7f55f58  c780e000

Call Trace: [proc_read_status+439/464] [nfs3svc_decode_sattrargs+381/512]
[get_new_inode+278/352] [vfs_rename_dir+248/1216] [sys_rename+42/528]
[sys_link+10/304] [expand_files+60/80]
   [put_last_free+109/112] [system_call+51/56]

Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68
kernel BUG at inode.c:486!
invalid operand: 
CPU:0
EIP:0010:[load_aout_library+19/640]
EFLAGS: 00010286
eax: 001b   ebx: e40fb980   ecx: cb27   edx: e3801ac0
esi: c029f200   edi: e2ea63c0   ebp: cb271fa4   esp: cb271e64
ds: 0018   es: 0018   ss: 0018
Process latex (pid: 24762, stackpage=cb271000)
Stack: c024ab70 c024abcf 01e6 e40fb980 c0142df7 e40fb980 e2ea6c40
e40fb980
   c01689fd e40fb980 c01406f6 e2ea6c40 e40fb980 e2ea6c40 
c01390e8
   e2ea6c40 cb271ee0 c013982a e2ea63c0 cb271ee0  cb271fa4
c1cca340
Call Trace: [proc_read_status+439/464] [nfs3svc_decode_sattrargs+381/512]
[get_new_inode+278/352] [vfs_rename_dir+248/1216] [sys_rename+42/528]
[fifo_open+167/592] [nfs3svc_decode_renameargs+9/5
   [sys_rename+378/528] [expand_files+60/80] [put_last_free+109/112]
[system_call+51/56]

Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68
kernel BUG at inode.c:486!
invalid operand: 
CPU:0
EIP:0010:[load_aout_library+19/640]
EFLAGS: 00010286
eax: 001b   ebx: c7743cc0   ecx: cb27   edx: e3801ac0
esi: c029f200   edi: e2ea65c0   ebp: cb271fa4   esp: cb271edc
ds: 0018   es: 0018   ss: 0018
Process latex (pid: 24763, stackpage=cb271000)
Stack: c024ab70 c024abcf 01e6 c7743cc0 c0142df7 c7743cc0 e2ea66c0
c7743cc0
   c01689fd c7743cc0 c01406f6 e2ea66c0 c7743cc0 e2ea66c0 
c01390e8
   e2ea66c0 cb271f58 c013982a e2ea65c0 cb271f58  d93d2000

Call Trace: [proc_read_status+439/464] [nfs3svc_decode_sattrargs+381/512]
[get_new_inode+278/352] [vfs_rename_dir+248/1216] [sys_rename+42/528]
[sys_link+10/304] [expand_files+60/80]
   [put_last_free+109/112] [system_call+51/56]

Code: 0f 0b 83 c4 0c f6 83 f4 00 00 00 10 75 1f 68 e8 01 00 00 68
==snip
--
"Ein Sprichwort der Prols sagt: Ist der Mensch wissend geworden, steht
unvermittelt sein Ende bevor. Vielleicht ist es weiser unwissend zu
bleiben..."
"Wissen hat irgendwann ein Ende, Nichtwissen ist unendlich. Zweifeln sie
etwa am Grossen Bruder, 87155 Barnes P?" (aus Bruder OZ/AC)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.5): 2nd ed. Fix PCMCIA ATA/IDE + PCI IRQ sharing

[Gunther Mayer]

Hi,
this includes the last fix + now it is willing to share PCI irqs.
Of course you still need CONFIG_IDEPCI_SHARE_IRQ set.

Now CF is working very fine, hdparm-4.1 shows 1.27 MB/sec.
(Only after treaking the source for small (i.e. <64MB) devices).

Regards, Gunther




--- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
+++ linux/drivers/ide/ide-cs.c  Wed Jun 27 20:19:45 2001
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -223,6 +224,15 @@
 #define CFG_CHECK(fn, args...) \
 if (CardServices(fn, args) != 0) goto next_entry
 
+int idecs_register (int arg1, int arg2, int irq)
+{
+hw_regs_t hw;
+ide_init_hwif_ports(, (ide_ioreg_t) arg1, (ide_ioreg_t) arg2, NULL);
+hw.irq = irq;
+hw.chipset = ide_pci; // this enables IRQ sharing w/ PCI irqs
+return ide_register_hw(, NULL);
+}
+
 void ide_config(dev_link_t *link)
 {
 client_handle_t handle = link->handle;
@@ -324,12 +334,15 @@
 if (link->io.NumPorts2)
release_region(link->io.BasePort2, link->io.NumPorts2);
 
+outb(0x02, ctl_base); // Set nIEN = disable device interrupts
+ // else it hangs on PCI-Cardbus Add-in cards wedging irq
+
 /* retry registration in case device is still spinning up */
 for (i = 0; i < 10; i++) {
-   hd = ide_register(io_base, ctl_base, link->irq.AssignedIRQ);
+   hd = idecs_register(io_base, ctl_base, link->irq.AssignedIRQ);
if (hd >= 0) break;
if (link->io.NumPorts1 == 0x20) {
-   hd = ide_register(io_base+0x10, ctl_base+0x10,
+   hd = idecs_register(io_base+0x10, ctl_base+0x10,
  link->irq.AssignedIRQ);
if (hd >= 0) {
io_base += 0x10; ctl_base += 0x10;
--- linux245.orig/drivers/ide/ide-probe.c   Sun Mar 18 18:25:02 2001
+++ linux/drivers/ide/ide-probe.c   Wed Jun 27 17:31:45 2001
@@ -685,6 +685,8 @@
 #else /* !CONFIG_IDEPCI_SHARE_IRQ */
int sa = (hwif->chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : 
SA_INTERRUPT;
 #endif /* CONFIG_IDEPCI_SHARE_IRQ */
+
+   outb(0x00, hwif->io_ports[IDE_CONTROL_OFFSET]); // clear nIEN == 
+enable irqs
if (ide_request_irq(hwif->irq, _intr, sa, hwif->name, hwgroup)) {
if (!match)
kfree(hwgroup);
--- linux245.orig/drivers/ide/ide.c Wed May  2 01:05:00 2001
+++ linux/drivers/ide/ide.c Wed Jun 27 20:18:23 2001
@@ -2181,6 +2181,7 @@
memcpy(hwif->io_ports, hwif->hw.io_ports, sizeof(hwif->hw.io_ports));
hwif->irq = hw->irq;
hwif->noprobe = 0;
+   hwif->chipset = hw->chipset;
 
if (!initializing) {
ide_probe_module();
--- linux245.orig/include/linux/ide.h   Sat May 26 03:02:42 2001
+++ linux/include/linux/ide.h   Wed Jun 27 19:01:35 2001
@@ -226,6 +226,19 @@
 #endif
 
 /*
+ * hwif_chipset_t is used to keep track of the specific hardware
+ * chipset used by each IDE interface, if known.
+ */
+typedef enum {  ide_unknown,ide_generic,ide_pci,
+ide_cmd640, ide_dtc2278,ide_ali14xx,
+ide_qd6580, ide_umc8672,ide_ht6560b,
+ide_pdc4030,ide_rz1000, ide_trm290,
+ide_cmd646, ide_cy82c693,   ide_4drives,
+ide_pmac
+} hwif_chipset_t;
+
+
+/*
  * Structure to hold all information about the location of this port
  */
 typedef struct hw_regs_s {
@@ -234,6 +247,7 @@
int dma;/* our dma entry */
ide_ack_intr_t  *ack_intr;  /* acknowledge interrupt */
void*priv;  /* interface specific data */
+   hwif_chipset_t  chipset;
 } hw_regs_t;
 
 /*
@@ -396,17 +410,6 @@
 typedef void (ide_maskproc_t) (ide_drive_t *, int);
 typedef void (ide_rw_proc_t) (ide_drive_t *, ide_dma_action_t);
 
-/*
- * hwif_chipset_t is used to keep track of the specific hardware
- * chipset used by each IDE interface, if known.
- */
-typedef enum { ide_unknown,ide_generic,ide_pci,
-   ide_cmd640, ide_dtc2278,ide_ali14xx,
-   ide_qd6580, ide_umc8672,ide_ht6560b,
-   ide_pdc4030,ide_rz1000, ide_trm290,
-   ide_cmd646, ide_cy82c693,   ide_4drives,
-   ide_pmac
-} hwif_chipset_t;
 
 #ifdef CONFIG_BLK_DEV_IDEPCI
 typedef struct ide_pci_devid_s {



P.S.


However, my "lsata"'s heuristics shows this as ATA1
(i.e. no ATA2 features used):

lsata /dev/hde

ihack for pcmcia compact flash
ATA Level = 1
ATAPI (Packet Interface): no
ATA Device Information for Command 0xEC

Conforming to 'AT Attachment for Disk Drives'
ANSI X3.221-1994
X3T10 791D Revision 4c Working Draft
All reserved Bits shall be zero (Chap. 8.8, p.25)

Word 0 General Configuration
1 Shall be 0. Reserved for non-magnetic drives
0 Format speed tolerance gap required ? 'no' : 'yes'
0 Track Offset 

2.4.5 oops in __free_pages from networking soft IRQ / skb_release

[Nicolai 'Prefect' Haehnle]

[1.] One line summary of the problem:

Oops killing soft interrupt in networking subsystem on plain 2.4.5 kernel.

[2.] Full description of the problem/report:

I recently updated the system on my router (486 100Mhz, 12MB RAM) to kernel 
2.4.5. The router has one ethernet interface and an ISDN dialup with dynamic 
IP address (and thus masquerading). I'm using the new netfilter code for 
firewall settings, masquerading, etc...
This is working all fine, but rarely - that is, around every 5 hours with 
heavy load, but sometimes earlier and sometimes later - the kernel locks up 
after an oops in an interrupt handler.

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

networking, netfilter, iptables, masquerading, free_pages

[4.] Kernel version (from /proc/version):

Linux version 2.4.5 (root@zen) (gcc version 2.95.2.1 19991024 (release)) #3 
Sun Jun 24 17:23:28 CEST 2001

[5.] Output of Oops.. message (if applicable) with symbolic information
 resolved (see Documentation/oops-tracing.txt)

ksymoops 2.4.1 on i486 2.4.5.  Options used
 -v /usr/src/linux/vmlinux (specified)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.5/ (default)
 -m /usr/src/linux/System.map (specified)

Warning (compare_maps): ksyms_base symbol 
__VERSIONED_SYMBOL(shmem_file_setup) not found in vmlinux.  Ignoring 
ksyms_base entry
*pde = 
Oops: 
CPU: 0
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 702e6e6f ebx:  ecx: 702e6e6ef edx: 
esi: c06b1700 edi: c0fdb270 ebp: 00050 esp: c023dde4
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c023d000)
Stack: c01a530d f400 c06b1700 c01a58f3 c06b1700 c06b1700 c0098a00 c09150b0
   c0098a00 fffa c01a834d c06b1700 0002 c0045f10 c00b1700 c01ab4f3
   c06b1700 c06b1700  0004 c01b40e0 c01b415d c06b1700 0001
Call Trace: [] [] [] [] [] 
[] []
[] [] [] [] [] 
[] [] []
[] [] [] [] [] 
[] [] []
[] [] [] [] [] 
[] [] []
Code: 8b 41 18 85 c0 7c 11 ff 49 14 0f 94 c0 84 c0 74 07 89 c8 e8

>>EIP; c0126ae2 <__free_pages+2/20>   <=
Trace; c01a530d 
Trace; c01a58f3 
Trace; c01a834d 
Trace; c01ab4f3 
Trace; c01b40e0 
Trace; c01b415d 
Trace; c01ac467 
Trace; c01b17b0 
Trace; c01b4062 
Trace; c01b40e0 
Trace; c01b17fa 
Trace; c01ac467 
Trace; c01b05dc 
Trace; c01b1754 
Trace; c01b17b0 
Trace; c01b09e0 
Trace; c01b0b69 
Trace; c01b09e0 
Trace; c01ac467 
Trace; c01b0826 
Trace; c01b09e0 
Trace; c01a88cd 
Trace; c01141af 
Trace; c01080b1 
Trace; c0105140 
Trace; c0106c60 
Trace; c0105140 
Trace; c0105163 
Trace; c01051c8 
Trace; c0105000 
Trace; c0100197 
Code;  c0126ae2 <__free_pages+2/20>
 <_EIP>:
Code;  c0126ae2 <__free_pages+2/20>   <=
   0:   8b 41 18  mov0x18(%ecx),%eax   <=
Code;  c0126ae5 <__free_pages+5/20>
   3:   85 c0 test   %eax,%eax
Code;  c0126ae7 <__free_pages+7/20>
   5:   7c 11 jl 18 <_EIP+0x18> c0126afa 
<__free_pages+1a/20>
Code;  c0126ae9 <__free_pages+9/20>
   7:   ff 49 14  decl   0x14(%ecx)
Code;  c0126aec <__free_pages+c/20>
   a:   0f 94 c0  sete   %al
Code;  c0126aef <__free_pages+f/20>
   d:   84 c0 test   %al,%al
Code;  c0126af1 <__free_pages+11/20>
   f:   74 07 je 18 <_EIP+0x18> c0126afa 
<__free_pages+1a/20>
Code;  c0126af3 <__free_pages+13/20>
  11:   89 c8 mov%ecx,%eax
Code;  c0126af5 <__free_pages+15/20>
  13:   e8 00 00 00 00call   18 <_EIP+0x18> c0126afa 
<__free_pages+1a/20>
 
Kernel panic: Aiee, killing interrupt handler!
 
1 warning issued.  Results may not be reliable.

[6.] A small shell script or example program which triggers the
 problem (if possible)

I couldn't figure out what exactly (malformed packet, ... ?) causes the crash.

[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)

Linux zen 2.4.5 #3 Sun Jun 24 17:23:28 CEST 2001 i486 unknown
 
Gnu C  2.95.2.1
Gnu make   3.79.1
binutils   2.10.1
util-linux 2.10r
mount  2.10r
modutils   2.4.0
e2fsprogs  1.19
isdn4k-utils   3.1pre1
Linux C Library2.2.1
Dynamic linker (ldd)   2.2.1
Procps 2.0.7
Net-tools  1.57
Console-tools  0.2.3
Sh-utils   2.0
Modules Loaded hisax isdn slhc ne2k-pci 8390

[7.2.] Processor information (from /proc/cpuinfo):

processor   : 0
vendor_id   : unknown
cpu family  : 4
model   : 0
model name  : 486
stepping: unknown
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : no
cpuid level : -1
wp  : yes
flags   :
bogomips: 49.66

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

hisax

Re: Allocating non-contigious memory

[Alan Cox]

> What is the Right Way[tm] as of 2.4.6 to allocate 16Mb as 4K pages and
> get the pci bus address for each page?  Bonus points is they're
> virtually contiguous, but that's not necessary.  IIRC, the old
> vmalloc-then-walk-the-pagetables trick is considered out-of-bounds
> nowadays.

If you want it virtually contiguous then copy the code from bttv that 
out-of-bounds or otherwise is now found in about 8 drivers in the kernel.

If you don't need that then you can map user space and use kiovecs - which
is nicer for many things

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PCI Power Management / Interrupt Context

[Jeff Garzik]

Linus Torvalds wrote:
> 
> In article <[EMAIL PROTECTED]>,
> David T Eger  <[EMAIL PROTECTED]> wrote:
> >
> >So I'm writing some code for a PCI card that is a framebuffer device, and
> >happily filling in the functions for the probe() and remove() functions
> >when I read documentation (Documentation/pci.txt) which mentions that
> >remove() can be called from interrupt context.
> 
> This used to be true for a short while for hot-plug CardBus. I don't
> think it is true any more - and if it is, that would be a bug.
> 
> So I think it's the documentation that is in error, and we should just
> fix that.
> 
> Jeff?

Correct, pci_driver::remove does not get called from interrupt context.

I don't know where the heck this thread is coming from ;-)  The docs
appear to be correct:

> remove  Pointer to a function which gets called whenever a device
> being handled by this driver is removed (either during
> deregistration of the driver or when it's manually pulled
> out of a hot-pluggable slot). This function always gets
> called from process context, so it can sleep.

-- 
Jeff Garzik  | Andre the Giant has a posse.
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/

Allocating non-contigious memory

[Olivier Galibert]

What is the Right Way[tm] as of 2.4.6 to allocate 16Mb as 4K pages and
get the pci bus address for each page?  Bonus points is they're
virtually contiguous, but that's not necessary.  IIRC, the old
vmalloc-then-walk-the-pagetables trick is considered out-of-bounds
nowadays.

  OG.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PCI Power Management / Interrupt Context

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
David T Eger  <[EMAIL PROTECTED]> wrote:
>
>So I'm writing some code for a PCI card that is a framebuffer device, and
>happily filling in the functions for the probe() and remove() functions
>when I read documentation (Documentation/pci.txt) which mentions that
>remove() can be called from interrupt context.

This used to be true for a short while for hot-plug CardBus. I don't
think it is true any more - and if it is, that would be a bug.

So I think it's the documentation that is in error, and we should just
fix that.

Jeff?

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

[noOOPS] Crash in -ac15 on SMP init fixed in -ac19

[Jay Thorne]

Dunno what the problem was, but the 2.4.5-ac15 problem I was having on the
4 way alphas is fixed in ac19. 

>Unable to handle kernel paging request at virtual address
043ffc69c078
>CPU 2 init(1): Oops 0
>pc = []  ra = []  ps = 

Anyone venture a guess? The patch log does not seem to show specific
mentions of mm fixups from ac15 to 19

--
Jay Thorne Manager, Systems & Technology, UserFriendly Media, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: A signal fairy tale

[Christopher Smith]

--On Wednesday, June 27, 2001 11:18:28 +0200 Jamie Lokier 
<[EMAIL PROTECTED]> wrote:
> Btw, this functionality is already available using sigaction().  Just
> search for a signal whose handler is SIG_DFL.  If you then block that
> signal before changing, checking the result, and unblocking the signal,
> you can avoid race conditions too.  (This is what my programs do).

It's more than whether a signal is blocked or not, unfortunately. Lots of 
applications will invoke sigwaitinfo() on whatever the current signal mask 
is, which means you can't rely on sigaction to solve your problems. :-(

--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: A signal fairy tale

[Christopher Smith]

--On Wednesday, June 27, 2001 11:51:36 +0530 Balbir Singh 
<[EMAIL PROTECTED]> wrote:
> Shouldn't there be a sigclose() and other operations to make the API
Wouldn't the existing close() be good enough for that?

> orthogonal. sigopen() should be selective about the signals it allows
> as argument. Try and make sigopen() thread specific, so that if one
> thread does a sigopen(), it does not imply it will do all the signal
> handling for all the threads.

Actually, this is exactly what you do want to happen. Linux's existing 
signals + threads semantics are not exactly ideal for high-performance 
computing. Of course, fd's are shared by all threads, so all of the threads 
would be able to read the siginfo structures into memory.

> Does using sigopen() imply that signal(), sigaction(), etc cannot be used.
> In the same process one could do a sigopen() in the library, but the
> process could use sigaction()/signal() without knowing what the library
> does (which signals it handles, etc).

If I understood Dan's intentions correctly, you could use signal() and 
sigaction(), but while the fd is open, signals would be queued up to the fd 
rather than passed off to a signal handler or sigwaitinfo(). Care to 
comment  Dan?

> Let me know, when somebody has a patch or needs help, I would like to
> help or take a look at it.

Maybe we can both hack on this.

--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: [PATCH] User chroot

[H. Peter Anvin]

Followup to:  <83fdx$[EMAIL PROTECTED]>
By author:[EMAIL PROTECTED] (Kai Henningsen)
In newsgroup: linux.dev.kernel
>
> [EMAIL PROTECTED] (Jorgen Cederlof)  wrote on 27.06.01 in 
><20010627014534.B2654@ondska>:
> 
> > If we only allow user chroots for processes that have never been
> > chrooted before, and if the suid/sgid bits won't have any effect under
> > the new root, it should be perfectly safe to allow any user to chroot.
> 
> Hmm. Dos this work with initrd and root pivoting?
> 

At the moment, yes.  Once Viro gets his root-changes in, this breaks,
since ALL processes will be chrooted.

-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: VM Requirement Document - v0.0

[Rik van Riel]

On Wed, 27 Jun 2001, Martin Knoblauch wrote:

>  I do not care much whether the cache is using 99% of the systems memory
> or 50%. As long as there is free memory, using it for cache is great. I
> care a lot if the cache takes down interactivity, because it pushes out
> processes that it thinks idle, but that I need in 5 seconds. The caches
> pressure against processes

Too bad that processes are in general cached INSIDE the cache.

You'll have to write a new balancing story now ;)

regards,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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

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

Re: How to change DVD-ROM speed?

[Jens Axboe]

On Wed, Jun 27 2001, Jeffrey W. Baker wrote:
> > On Wed, Jun 27 2001, Jeffrey W. Baker wrote:
> > > I am trying to change the spin rate of my IDE DVD-ROM drive.  My system is
> > > an Apple PowerBook G4, and I am using kernel 2.4.  I want the drive to
> > > spin at 1X when I watch movies.  Currently, it spins at its highest speed,
> > > which is very loud and a large power load.
> > >
> > > /proc/sys/dev/cdrom/info indicates that the speed of the drive can be
> > > changed.  I use hdparm -E 1 /dev/dvd to attempt to set the speed, and it
> > > reports success.  However, the drive continues to spin at its highest
> > > speed.
> >
> > Linux still uses the old-style SET_SPEED command, which is probably not
> > supported correctly by your newer drive. Just checking, I see latest Mt
> > Fuji only lists it for CD-RW. For DVD, we're supposed to do
> > SET_STREAMING to specify such requirements.
> >
> > Feel free to implement it :-)
> 
> I will be happy to :)  Should I hang conditional code off the existing
> ioctl (CDROM_SELECT_SPEED, ide_cdrom_select_speed) or use a new one?

Excellent. I'd say use the same ioctl if you can, but default to using
SET_STREAMING for DVD drives.

-- 
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: EEPro100 bug in 2.4.6pre5

[Jeff Garzik]

Alan Cox wrote:
> Someone has done S/CONFIG_EEPRO100_PM/CONFIG_PM/ on the driver and in doing
> so permanently enabled the eepro100 pm code which to say the least doesnt work
> for a lot of people but gives them weird eepro100 hangs

Do you have a bug report of this actually breaking?

eepro100 is doing standard PCI PM.  The only reason AFAICS why it was
breaking for people was that the previous PCI PM code did not do all the
stuff it needed to do.  PCI PM should cover the various cases correctly,
now, ditto eepro100.

-- 
Jeff Garzik  | Andre the Giant has a posse.
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: EEPro100 bug in 2.4.6pre5

[Alan Cox]

> Do you have a bug report of this actually breaking?

I've not been able to make 2.4.6pre5 stay up long enough to do any real
testing on this. It just keeps hanging all the time anyway

> eepro100 is doing standard PCI PM.  The only reason AFAICS why it was
> breaking for people was that the previous PCI PM code did not do all the
> stuff it needed to do.  PCI PM should cover the various cases correctly,
> now, ditto eepro100.

The they should fix Config.in

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

Re: Microsoft and Xenix.

[Peter De Schrijver]

On Wed, Jun 27, 2001 at 10:09:41AM +0200, Geert Uytterhoeven wrote:
> On Tue, 26 Jun 2001, Michael Meissner wrote:
> > On Tue, Jun 26, 2001 at 11:16:27AM -0400, Rob Landley wrote:
> > > The AS400 seems to be based out of Austin.  We hear a lot about it around 
> > > here...
> > 
> > Ummm, the AS/400 was based out of Rochester, Minnesota at least initially.  It
> > was the follow to System/3 -> System/36 -> System/38, and customers originally
> > programmed it in RPG-III and Cobol.  Now that AS/400's are based on special
> > PowerPC's, the home may have moved to Austin, which is the PowerPC/AIX center.
> > The AS/400 line was intended to be the mid-range system, between the mainframes
> > (360 -> 370 -> 3080 -> 3900 -> ???) and the PCs.
> 
> 360 -> 370 -> 3080 -> 3090 -> ES/9000 -> zSeries, IIRC
> 
 360 -> 370 -> 3080 -> 3090 -> ES/9000 -> S/390 -> zSeries ?

Peter.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: mounting a fs in two places at once?

[Ben Ford]

Chris Wedgwood wrote:

>On Mon, Jun 25, 2001 at 02:20:16AM -0700, Ben Ford wrote:
>
>>Feature.  It actually makes it quite nice when you want to allow
>>chrooted user(s) access to a common directory, you just mount a
>>partition in all the users home dirs.
>>
>
>For security, this can be a bad idea.
>

'tis very true.

I have been using this for FTP users, such as allowing a common /mp3 
download directory relative to each users jail.  That is what I was 
referring to, should have been more specific.

-b

-- 
:__o
:   -\<,
:   0/ 0
---



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

Re: How to change DVD-ROM speed?

[Jeffrey W. Baker]

On Wed, 27 Jun 2001, Jens Axboe wrote:

> On Wed, Jun 27 2001, Jeffrey W. Baker wrote:
> > I am trying to change the spin rate of my IDE DVD-ROM drive.  My system is
> > an Apple PowerBook G4, and I am using kernel 2.4.  I want the drive to
> > spin at 1X when I watch movies.  Currently, it spins at its highest speed,
> > which is very loud and a large power load.
> >
> > /proc/sys/dev/cdrom/info indicates that the speed of the drive can be
> > changed.  I use hdparm -E 1 /dev/dvd to attempt to set the speed, and it
> > reports success.  However, the drive continues to spin at its highest
> > speed.
>
> Linux still uses the old-style SET_SPEED command, which is probably not
> supported correctly by your newer drive. Just checking, I see latest Mt
> Fuji only lists it for CD-RW. For DVD, we're supposed to do
> SET_STREAMING to specify such requirements.
>
> Feel free to implement it :-)

I will be happy to :)  Should I hang conditional code off the existing
ioctl (CDROM_SELECT_SPEED, ide_cdrom_select_speed) or use a new one?

Best,
Jeffrey

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] proc_file_read() (Was: Re: proc_file_read() question)

[Martin Wilck]

> PAGE_OFFSET definitely works for me, but a quick scan of the headers
> suggests that non-sun3 m68k builds define PAGE_OFFSET as 0, as does
> s390.

Hum - is there no simple way to determine whether a pointer is
a valid pointer to something returned by __get_free_pages ()? You are
right, S390 in particular seems to allow arbitrary addresses starting from
0.

> Sure, the overloading is self-admittedly hacky, but (again I assume)
> the motivation was to avoid breaking the clients, many of which are
> not in the kernel.org tree. Your proposed change overloads a third
> interpretation on start, namely an arbitrary pointer, outside the
> page allocation.

For some reason I was convinced that this was the originally intended
use of start. The only quotes I find right now are Ori Pomerantz'
Module Programming Guide (http://www.linuxdoc.org/LDP/lkmpg/node16.html)
and Rubini's "Writing Device Drivers", chapter 4. Also, the comment in the
code
if (!start) {
/*
 * For proc files that are less than 4k
 */
...
}
supports this notion somehow (start only set if data size > page size).

After all, unless you want to mangle the file position as intended by
the hack, there is no point in touching start at all in proc_read (),
ppos will be updated automatically.

Perhaps I have misunderstood something here.
Who wrote the original code, after all?

Martin

-- 
Martin Wilck <[EMAIL PROTECTED]>
FSC EP PS DS1, Paderborn  Tel. +49 5251 8 15113



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

Re: How to change DVD-ROM speed?

[Jens Axboe]

On Wed, Jun 27 2001, Jeffrey W. Baker wrote:
> I am trying to change the spin rate of my IDE DVD-ROM drive.  My system is
> an Apple PowerBook G4, and I am using kernel 2.4.  I want the drive to
> spin at 1X when I watch movies.  Currently, it spins at its highest speed,
> which is very loud and a large power load.
> 
> /proc/sys/dev/cdrom/info indicates that the speed of the drive can be
> changed.  I use hdparm -E 1 /dev/dvd to attempt to set the speed, and it
> reports success.  However, the drive continues to spin at its highest
> speed.

Linux still uses the old-style SET_SPEED command, which is probably not
supported correctly by your newer drive. Just checking, I see latest Mt
Fuji only lists it for CD-RW. For DVD, we're supposed to do
SET_STREAMING to specify such requirements.

Feel free to implement it :-)

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