Re: Strange lockups on 2.4.2

[Keith Owens]

On Mon, 26 Mar 2001 23:16:27 -0600, 
Steven Walter <[EMAIL PROTECTED]> wrote:
>This has happened twice, now, though I don't believe its completely
>reproduceable.  What happens is an Oops, which drops me into kdb.  I've
>been in X both times, however, which makes kdb rather useless.

Documentation/serial-console.txt

>The thing I find most interesting about this is that only 4 lines of the
>oops gets into the log.  4 lines, both times.  This time, those lines
>were:
>
> printing eip:
>c0112e1f
>Oops: 0002
>CPU:0

That is a symptom of a broken klogd.  Always run klogd with the -x
switch.  If that does not work, take a look at

ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/v2.4/patch-sysklogd-1-3-31-ksymoops-1.gz

One day the sysklogd maintainers might just fix this bug, that bug fix
is almost 2 years old.

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

Re: Use semaphore for producer/consumer case...

[Stelian Pop]

On Mon, Mar 26, 2001 at 07:12:55PM +0200, Manfred Spraul wrote:

> > > That doesn't work, at least the i386 semaphore implementation
> doesn't
> > > support semaphore counts < 0.
> >
> > Does that mean that kernel semaphore can not be used for something
> > else than mutual exclusion ?
> >
> It's a bit better: counts >= 0 are supported, i.e. you can call up()
> before down(), and that's used in several places.

I see... it's somewhat different than the classical semaphore 
implementation, but usable anyway.

> The for loop that Nigel proposed should solve your problem. Multiple
> up's are handled correctly.

Now I understand his suggestion. Thanks to both of you.

Stelian.
-- 
Stelian Pop <[EMAIL PROTECTED]>
|- Ingénieur Informatique Libre --|
| Alcôve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
|--- Alcôve, l'informatique est libre |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [RESEND] update chipsfb driver

[Colonel]

> Linus,

> At present, drivers/video/chipsfb.c can only be used on PPC, and it
> doesn't compile even on PPC.  The patch below makes it compile, and
> by changing it to use the generic inb/outb, means that there is at
> least a chance it can be used on other platforms.  The patch is
> against 2.4.3-pre7, could you apply it please?   
>  

I have an old Planar wall mount with Chips & Tech video, powered by a
T.I. 486DX100 (the BIOS is 7 years old).  I originally bought it to
use the frame buffer in a portable application, and this patch is the
FIRST time I've ever obtained an image.  Thanks!

The colormap is wrong, but at least I have some sort of working device
now.  I shelved the project over a year ago, what's a good site to
come up to speed on?

r
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Prevent OOM from killing init

[Helge Hafting]

Alan Cox wrote:
> 
> > >How do you return an out of memory error to a C program that is out of memory
> > >due to a stack growth fault. There is actually not a language construct for it
> > SIGSEGV.
> > Stack overflow for a language like C using standard implementation techniques
> > is the same as a page fault while accessing a page for which there is no backing
> > store. SIGSEGV is the logical choice, and the one I'd expect on other Unices.
> 
> Guess again. You are expanding the stack because you have no room left on it.
> You take a fault. You want to report a SIGSEGV. Now where are you
> going to put the stack frame ?
> 
> SIGSEGV in combination with a preallocated alternate stack maybe, but then you
> still need to recover. C++ you can maybe do it with exception handling but
> C doesnt really have the structure and longjmp just doesnt cut it.

Seems to me a guard page would do the trick.  Make the last page of the
stack
non-overcommitable and marked not present.  Maybe non-swappable too in
case
nothing else can be swapped out for some reason.
(Yes, that wastes a page per process)
Whenever we hit the guard page, try expanding the stack.  
If it works - fine.  If not - make the guard page present _and_ deliver
the SIGSEGV using this last page of stack.  No complicated alternate
stack construct, just report OOM one page in advance.

OOM is still possible if the program don't handle SIGSEGV well.
But a smart program now have the option of doing emergency deallocations
and/or dump its precious intermediate results to file.

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

Re: URGENT : System hands on "Freeing unused kernel memory: "

[J . A . Magallon]

On 03.27 Thomas Foerster wrote:
> 
> But suddenly the box was offline. One technical assistant from our ISP tried
> to reboot
> our server (he couldn't tell me if there had been any messages on the screen),
> but the
> system always hangs on 
> 
> Freeing unused kernel memory: xxk freed
> 

Try booting with init=/bin/bash, it looks like kernel gets a bad /sbin/init,
and gets stuck. Perhaps the shutdown damaged init, it starts to run and get
hung.

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.2-ac25 #5 SMP Mon Mar 26 17:46:56 CEST 2001 i686

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

Re: paride error, aparantly with VFS

[idalton]

On Mon, Mar 26, 2001 at 07:10:11PM +0100, Tim Waugh wrote:
> On Sun, Mar 25, 2001 at 09:37:38PM -0800, [EMAIL PROTECTED] wrote:
> 
> > do_pd_read_drq: status = 0x10050 = SEEK READY TMO
> 
> Please try a recent -ac kernel and let me know if the problem persists
> or goes away.

ac25 appears to have this problem fixed.

Still got bit by the OOPS problem in my other post when I tried to
switch drives in the box, though.

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

Compact flash disk and slave drives in 2.4.2

[Richard Smith]

I spent most of the day today trying to track down why the embedded system I am 
working 
on would not recognize hdb on boot.  It refused to show in the devices list even 
though I 
specifically told the kernel it existed with the hdb=c,h,s option.

After working on what seemed like a hardware problem for quite a while I finally 
decided 
that there must be something flaky in the ide driver code and began to add some debug 
printk's

In which I found the following in ide.c:

/*
 * CompactFlash cards and their brethern pretend to be removable hard disks,
 * except:
 *  (1) they never have a slave unit, and
 *  (2) they don't have doorlock mechanisms.
 * This test catches them, and is invoked elsewhere when setting appropriate
 * config bits.
 *
*/

Since hda in my system is a CompactFlash card I began to look further and then with 
some 
discovered the following in ide-probe.c

/*
 * Prevent long system lockup probing later for non-existant
 * slave drive if the hwif is actually a flash memory card of some variety:
 */
if (drive_is_flashcard(drive)) {
ide_drive_t *mate = (drive)->drives[1^drive->select.b.unit];
if (!mate->ata_flash) {
mate->present = 0;
ide_drive_t *mate = (drive)->drives[1^drive->select.b.unit]
mate->noprobe = 1;
}
}

Now perhaps I am just way out on the wacky edge of things but I don't agree with the 
above in the slightest.  We use CF's in conjunction with slaves all the time.  Almost 
all 
of our embedded devices boot from CF's and I routinely add a HD as a slave to the 
system 
to do developement with but it's always been under DOS.  

I comment out the check above and all is well... hdb shows up as expected.   

Can someone explain to me why the above check was added and if its continued existence 
is 
necessary?  Whats this long system lockup thing mentioned?

Even if there is some danger of a long lockup I suggest that at least a message that 
its 
ignoring hdb is the least it could do rather than sliently ignoreing it.  Especially 
when 
I specifically told it a hdb existed via the command line.  Shouldn't command line 
parameters take precidence?  

I not subscribed to the kernel-list so please copy me in the response.

Thanks.


--
Richard A. Smith[EMAIL PROTECTED] 
"I'd hang out with science kids - they can blow things up!
 I mean, what's cooler than that?"
   - Tori Amos


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

Re: regression testing

[Werner Almesberger]

Eric W. Biederman wrote:
> Yes user-mode linux
> could help here (you could stress test the core kernel without worry
> that when it crashes your machine will crash as well).  

A similar approach can be used for very detailed tests of specific
subsystems. E.g. that's what we've started doing, kind of as a by-product
of some other work, with tcsim, which runs most of the traffic control
subsystem in user space. (ftp://icaftp.epfl.ch/pub/linux/tcng/)

The advantage over using UML is that we have a much simpler environment,
allowing for more straightforward integration, and we can exercise tight
control over infrastructure parts like timers or network events. Once
UML is part of the mainstream kernel, it would be interesting to try to
obtain the same functionality with UML too.

Some added goodies include the ability to run kernel code with malloc
debuggers like Electric Fence, which has already helped to find a few
real bugs. (Does EFence work with UML ?)

- Werner

-- 
  _
 / Werner Almesberger, ICA, EPFL, CH   [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Building linux kernel 2.4.0 for MIPS.

[Nazim Khan]

Hi,

Can I build the linux kernel 2.4.0 for MIPS(R3000) processor.
I have cross compiler and binutils intstalled on my host m/c (x86).

Will it compile ?
Do I need to do any extra patche for MIPS ?
Does the built image work ?

Any input or suggestion are welcome.



Thanks and regards,
Nazim


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

BUG: devfs/root doesn't follow pivot_root

[Ph. Marek]

Hi Richard,

in fs/devfs/util.c is
void __init devfs_make_root (const char *name)
which is wrong as pivot_root allows changing the root-device in the runtime.

I think it should be 
void __init devfs_make_root (const char *name)
and get called by
fs/super.c:
asmlinkage long sys_pivot_root(const char *new_root, const char *put_old)
after
chroot_fs_refs(root,root_mnt,new_nd.dentry,new_nd.mnt);
error = 0;

Is that correct?


Thanks for your attention,


regards

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

URGENT : System hands on "Freeing unused kernel memory: "

[Thomas Foerster]

Hello folks,

i have a realy strange and annyoing problem here.

I have a very busy webserver. Around 2 weeks ago i upgraded from 2.2.18 to 2.4.2-ac20
(SCSI-System, 512 MB RAM, 3 SCSI-Disks, P-III-500). Everything worked fine, the 2.4x 
Kernel
boosted the box a lot :)

But suddenly the box was offline. One technical assistant from our ISP tried to reboot
our server (he couldn't tell me if there had been any messages on the screen), but the
system always hangs on 

Freeing unused kernel memory: xxk freed

So we took the box home and tried to boot it from a bootdisk (generated as we 
installed the box,
redhat 7.0). The SAME problem occurs ... 

Freeing unused kernel memory: xxk freed

The system hangs (i've tried 2.2.18 AND 2.4.2-ac20, 2.2.16 is on our bootdisk). I 
thought
it could be the swap-partition ... so we inserted an IDE Disk, installed a small 
system so that
i was able to mount the SCSI-Disks. So i rebuild the swap-parition with
mkswap /dev/sda5 and activated it via swapon /dev/sda5 ... worked.

So i tried to boot it again from the SCSI-Disks ... nothing! The same odd failure ...

I've never hat such Problems before .. we've already changed every piece of hardware 
that's been in the
box (except the disks, but theire looking ok because i can mount them and run e2fsck 
over it :) )

I need help, because we're already down for 3 Days now. What causes the system to hang 
at this point??
What must i do the be able to boot the system from the scsi-disks again?

Thanx a lot,
  Thomas

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

Re: question \ information request on init \ boot sequence when using initrd

[Werner Almesberger]

Amit D Chaudhary wrote:
> To put it in brief, since running sbin/init from /linuxrc as resulting 
> in init not having PID 1 and thereby not doing some initialization as 
> expected.

Easy solution: don't run linuxrc, run something else instead. E.g.
putting the following into the kernel's command line should do th
trick:
init=/your_script root=/dev/ram

(With your_script being the original version, without real-root-dev)

> Thereby instead of loading running /sbin/init, we just set 
> /proc/sys/kernel/real-root-dev to /dev/ram0's value which then does the 

Anything involving real-root-dev is likely to be an anachronism.
Combining it with pivot_root just makes it more weird.

> Is this ok or should be modify /sbin/init to run properly inspite of PID 
> <> 1 or is there a 3rd way of doing this?

I'd consider the "PID of init must be 1" a bit of an anachronism too.
After all, a modern Unix system has quite a few demons that you don't
want to kill either, so why make init special ? But anyway, you don't
need to change init.

- Werner

-- 
  _
 / Werner Almesberger, ICA, EPFL, CH   [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: question \ information request on init \ boot sequence whenusing initrd

[Scott Murray]

On 26 Mar 2001, Stuart Lynne wrote:

> In article <[EMAIL PROTECTED]>,
> Amit D Chaudhary <[EMAIL PROTECTED]> wrote:
[snip]
> You can run your linuxrc with:
>
>   init=/linuxrc

Yes.

> and then end your /linuxrc with:
>
>   exec /sbin/init

No.  He's doing a pivot_root to a new root filesystem.  You have
to do the 'exec chroot . /sbin/init ...' command given in the file
Documentation/initrd.txt in order for init to start up correctly.

Having played with pivoting to a ramfs out of an initrd for the
last several days, I can think of a couple of possible problems.
The first is that Amit's final linuxrc command:

>exec sbin/chroot . sbin/init.new 3 dev/console 2>&1

is different from what's described in initrd.txt.  I'm using the
exact line that's in there in my linuxrc, and it works fine.
Amit, try changing that line to:

exec chroot . /sbin/init.new 3 dev/console 2>&1

and see if that works.  This does require having chroot in your
initrd, but that is mentioned in initrd.txt as a requirement
anyways.  If init.new is the wrapper that I think was mentioned
here previously, I'd suggest just trying a regular init and doing
the umount and free of the ramdisk later somewhere in your
rc.sysinit or equivalent.

The second potential problem I can think of would be a missing
dev/console node in the new root filesystem.  I think I experienced
a similar failure mode once last Friday; it may have been the time
I forgot to mount devfs on /dev in my new root filesystem.

Scott


--
=
Scott Murrayemail: [EMAIL PROTECTED]
http://www.spiteful.org (coming soon) ICQ: 10602428
-
 "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"

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

386 'ls' gets SIGILL iff /proc is mounted

[Eric Buddington]

2.4.2-ac23 nfsroot on a 386SX/20 with 6Mb RAM

On boot to single user, 'ls' and 'ls -l' work fine.

After mounting /proc, 'ls' still works, but 'ls -l' fails
with SIGILL after reading /etc/timezone (so says strace).

Unmounting /proc fixes the problem. Unmounting /dev doesn't.

I also, just now, had a spate of 'permission denied' errors
while trying to ls /dev/ subdirectories, and unexpected stale NFS handles.

The problems are varied enough that I suspect bad hardware, but would
flaky RAM cause such similar failures repeatedly? And is there a way
to test RAM explicitly?

Any tips appreciated, either to me ([EMAIL PROTECTED]) or to
the list.

-Eric

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

Re: Larger dev_t

[Linus Torvalds]

On Sun, 25 Mar 2001 [EMAIL PROTECTED] wrote:
>
> Now what I wrote is that *I* am strongly in favor of sizeof(dev_t) = 8.
> You think that I want bloat - in reality sizeof(dev_t) = 8 makes life
> simpler.
>
> My system here has for example in super.c:
>
> static dev_t next_unnamed_device = 0x100ULL;
>
> kdev_t get_unnamed_dev(void) {
> return to_kdev_t(next_unnamed_device++);
> }

Fine.

You'e now forced every piece of code that needs a dev_t to carry along the
overhead of having a 64-bit field, for the advantage of making
"get_unnamed_dev()" smaller and faster.

The thing is, I have _never_ EVER seen "get_unnamed_dev()" on any kernel
profile.

And I don't remember when (if ever) we had a bug in it.

So the advantage of making it smaller/faster/simpler seems to be a purely
theoretical one.

> a large name space allows one to omit checking what part can be
> reused - reuse is unnecessary. That is also why I use a 64-bit pid:
> upon a fork one does not have to search for pids, pgrps, sessions
> with a given pid, and getpid() can be

Hey, 5 years ago we could have said the same for a 32-bit pid.

The fact is, that there are programs out there that use "int" for pids.

It's equally true that changing "pid_t" will require that you recompile
every single app that might have a kernel interface to the current 32-bit
pid_t.

AND you just created tons of problems for things like the non-obvious
stuff like

ioctl(fd, FASETOWN, arg);

because "arg" is defined to be a single word.

In short, you've just broken existing binaries in ways that will be _damn_
hard to debug (they magically start breaking only after the pid-space has
wrapped the first 32 bits).

And that's a DOCUMENTED interface. Never mind all the undocumented stuff
that assumes (for all the reasonable historical reasons) that "pid" fits
in an "int". Tell me there aren't applications like that, and I'll laugh
in your face.

In short, both your arguments are totally bogus. Your "simpler" function
is in fact a horrible rats nest and a source of subtle bugs that you
apparently never even thought about.

And that's without ever actually mentioning the word "bloat" and "data
cache usage".

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/

Re: "mount -o loop" lockup issue

[Rik van Riel]

On Mon, 26 Mar 2001, David Konerding wrote:

> It's a bug in Linux 2.4.2, fixed in later versions.  
> Regression/quality control testing would have caught this, but the
> developers usually just break things and wait for people to complain
> as their "Regression" testers.

As said before, we're interested in people willing to do regression
tests on the kernel. Unfortunately, not all that many testers have
stepped forward and not all that many artificial tests are being run.

Good thing we still have the beta-testers to catch these things,
while running the kernel in real-world scenarios... ;)

regards,

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

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

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

Strange lockups on 2.4.2

[Steven Walter]

This has happened twice, now, though I don't believe its completely
reproduceable.  What happens is an Oops, which drops me into kdb.  I've
been in X both times, however, which makes kdb rather useless.  I
blindly type "go", and interrupts get reenabled, at least (I know
because my mp3 stops looping and begins playing again).  This almost
must mean at least part of userspace survives.  Probably only X dies,
since VT switching and numlock-toggling doesn't work.  I can Ctrl+SysRq
S-U-B, though.

The thing I find most interesting about this is that only 4 lines of the
oops gets into the log.  4 lines, both times.  This time, those lines
were:

 printing eip:
c0112e1f
Oops: 0002
CPU:0

This corresponds to schedule according to System.map (that's the nearest
symbol without going over).  Before I believe it was path_walk.  If
anyone's got an idea, it'd be helpful.  Btw, this machine consistently
passes memtest, most recently ran 2 passes of all tests with no errors
found.
-- 
-Steven
Freedom is the freedom to say that two plus two equals four.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.4.2-ac26

[Alan Cox]

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

Intermediate diffs are available from

http://www.bzimage.org

(Note that the cmsfs port to 2.4 is a work in progress)

2.4.2-ac26
o   Fix es1370 build bug(me)
o   Fix sbpcd compile warnings  (me)
o   Update usbnet driver(Oleg Drokin)
o   Update Alpha to pre8 vm changes (Ivan Kokshaysky)
o   Fix radeonfb config selections  (Chris Lawrence)
o   Fix vmalloc mismerge(Various)
o   Fix n_r3964 console panic   (Andrew Morton)
o   Update ibm camera drivers
o   Support 701b toshoboe fir
o   New xircom_cb driver(Arjan van de Ven, Jeff Garzik,
 Don Becker, Doug Ledford)
o   Fix procfs mount point for binfmt_misc  (Al Viro)
o   Update hpt366 ide blacklist
o   Further ide blacklist updates
o   Smooth vm balancing (Marcelo Tosatti)
o   Fix irda assert (Arjan van de Ven)
o   Keep contrack cache sizes sane  (Ben LaHaise)
o   Fix possible file truncate/write race   (Ben LaHaise)
o   Make bootmem panic sanely on out of memory  (Ben LaHaise)
o   Fix unload crash in pci_socket  (me)
o   Revert previous wrong bootmem change(Ben LaHaise)

2.4.2-ac25
o   Handle PCI/ISA simple MP tables via ELCR(John William)
o   Fix get_sb_single   (Al Viro)
o   Update es1370, es1371,esssolo   (Thomas Sailer,
 Tjeerd Mulder,
 Nathanial Daw)
o   Update orinoco_cs   (Jean Tourilhes)
o   Fix races found in the new kbd/console code (Andrew Morton)
o   Remove dead timer.h docs(Tim Wright)
o   Update ppc to new generic mm changes(Paul Mackerras)
o   Clean up mdacon (Paul Gortmaker)
o   Remove duplicate configure.help texts   (Steven Cole)
o   Fix symbol export for shm_file_open (Keith Owens)
o   First batch of pointer reference bug fixes  (Andrew Morton)
from Stanford report
o   Fix de4x5 oops on Alpha XP1000  (George France)
o   Chipsfb update  (Paul Mackerras)
o   Fix higmem block_prepare_write crash(Stephen Tweedie)
o   Bring PAE36 back up to date, handle x86 errata  (Ingo Molnar)
o   Fix ov511 crash if opened while loading (Pete Zaitcev)
o   Merge Linus 2.4.3pre8
o   Update Advansys scsi driver (Bob Frey)

2.4.2-ac24
o   Fix build bug with tsc in ac23  (me)
o   Update contact info for Phil Blundell   (Phil Blundell)
o   Update mm locking comments/rss locking  (Andrew Morton)
o   Update toshiba SMM driver   (Jonathan Buzzard)
o   Update old adaptec driver to 5.2.4  (Doug Ledford)
o   CS46xx updates  (Tom Woller)
o   Quieten input layer printks a bit   (me)
o   Turn off APIC_DEBUG by default to cut noise down(me)
o   Add Orinoco PCMCIA wireless support (David Gibson)
o   Go back to 2.4.3pre6 tulip  (Jeff Garzik)
o   Fix double accounting of cpu time bug   (Kevin Buhr)
o   Drop ppp patch  (me)

2.4.2-ac23
o   Fix a nasty shared memory locking bug   (Stephen Tweedie)
o   Fix off by one bootmem memory corruptor (Ben LaHaise)
o   Fix avmb1 oops on init  (Carsten Paeth)
o   Fix isdn makefile bugs  (Kai Germaschewski)
o   Clean up isdn minor checks  (Julien Gaulmin)
o   Workaround PPP CCP negotiation bugs (Kai Germaschewski)
o   Fix timer handling bug in ISDN  (Henk-Jan Slotboom)
o   Fix i386 #ifdef bug with notsc disable  (Anton Blanchard)
o   Fix NMI docs(Keith Owens)
o   Fix oops on out of memory in proc_symlink   (me)
| Found by Stanford tools
o   Fix oops caused by devfs changes to soundcore   (me)
| Found by Stanford tools
o   Fix rmmod crash on sundance alta(me)
| Found by Stanford tools
o   Fix potential crash in nsc-ircc.c   (me)
| Found by Stanford tools
o   Fix memory leak in i810 audio   (Doug Ledford)
o   Fix several compile warnings with gcc 3.0 cvs   (J Magallon)
o  

Re: "mount -o loop" lockup issue

[Alan Cox]

> It's a bug in Linux 2.4.2, fixed in later versions.  Regression/quality control
> testing would
> have caught this, but the developers usually just break things and wait for people
> to complain
> as their "Regression" testers.

Hardly. We knew it was broken since well before 2.4.0. It just got a little
interesting to fix.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 64-bit block sizes on 32-bit systems

[Jesse Pollard]

On Mon, 26 Mar 2001, Jonathan Morton wrote:
>>These are NOT the only 64 bit systems - Intel, PPC, IBM (in various guises).
>>If you need raw compute power, the Alpha is pretty good (we have over a
>>1000 in a Cray T3..).
>
>Best of all, the PowerPC and the POWER are binary-compatible to a very
>large degree - just the latter has an extra set of 64-bit instructions.
>What was that I was hearing about having to redevelop or recompile your
>apps for 64-bit?
>
>I can easily imagine a 64-bit filesystem being accessed by a bunch of
>RS/6000s and monitored using an old PowerMac.  Goodness, the PowerMac 9600
>even has 6 PCI slots to put all those SCSI-RAID and Ethernet cards in.  :)

Save the money - get one fiber channel and connect to all that through
one interface...

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

Re: VIA686b chipset and dma_intr errors, and 3c905B errors

[Nicholas Petreley]

Update: 

Thanks to some advice and help from Mark Hahn, I downloaded
the DFT utility from IBM that checks and fixes their
drives.  A low-level format fixed the problems (the utility
calls it "erase disk".  That seems odd to me, since I
thought that IDE drives automatically took care of bad
blocks, but apparently this needed the low-level format. 
I'll keep an eye on that drive, though...

As for the 3C905B, I've already replaced it with an
eepro100, but as Mark suggested in an email, I will turn
off the "optimal" performance setting in the BIOS and see
if that gets rid of all the bizarre behavior.  Apparently
that's not a kernel problem but a bios problem.  

-Nick

-- 
**
Nicholas Petreley   Caldera Systems - LinuxWorld/InfoWorld
[EMAIL PROTECTED] - http://www.petreley.com - Eph 6:12
**
.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: question \ information request on init \ boot sequence when using initrd

[Stuart Lynne]

In article <[EMAIL PROTECTED]>,
Amit D Chaudhary <[EMAIL PROTECTED]> wrote:
>Hi,
>
>We(my team) had some questions regarding booting from initrd and using 
>/linuxrc. It will help someone(David, Werner,...) can give their 
>thoughts on this.
>
>To put it in brief, since running sbin/init from /linuxrc as resulting 
>in init not having PID 1 and thereby not doing some initialization as 
>expected.
>
>Thereby instead of loading running /sbin/init, we just set 
>/proc/sys/kernel/real-root-dev to /dev/ram0's value which then does the 
>following
>runs 2 statements in init/main.c to unlock_kernel and free init memory 
>and then run sbin/init.
>This results in /sbin/init running fine.
>
>Is this ok or should be modify /sbin/init to run properly inspite of PID 
><> 1 or is there a 3rd way of doing this?
>
>
>mkdir initrd
>../bin/pivot_root . initrd
>
>exec sbin/chroot . sbin/init.new 3 dev/console 2>&1
>
>
>The above results in init running with PID != 1 and thereby skipping 
>some relevant processing my default. see ps output below:
>
>Instead of the "chroot" above is changed to following
>exec sbin/chroot . sh -c 'bin/mount proc proc -t proc; echo 0x0100 > 
>proc/sys/kernel/real-root-dev'
>And linuxrc exits
>
>
>
>(none):root> ps -e
>   PID TTY  TIME CMD
> 1 ?00:00:04 swapper
> 2 ?00:00:00 keventd
> 3 ?00:00:00 kswapd
> 4 ?00:00:00 kreclaimd
> 5 ?00:00:00 bdflush
> 6 ?00:00:00 kupdate
> 7 ?00:00:00 mtdblockd
> 8 ?00:00:00 init
>26 ?00:00:00 sh
>39 ?00:00:00 portmap
>50 ?00:00:00 ypbind
>51 ?00:00:00 ypbind
>84 ?00:00:00 inetd
>93 ?00:00:00 syslogd
>   100 ?00:00:00 klogd
>   119 ?00:00:00 ps


You can run your linuxrc with:

init=/linuxrc

and then end your /linuxrc with:

exec /sbin/init

-- 
__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: "mount -o loop" lockup issue

[William Stearns]

Good day, all,

On Mon, 26 Mar 2001, Jason Madden wrote:

> On Mon, 26 Mar 2001, David E. Weekly wrote:
>
> > On Linux 2.4.2, running a "mount -o loop" on a file properly created with
> > "dd if=/dev/zero of=/path/to/my/file.img count=1024" seems to decide to
> > freeze up my shell (not my system). An strace showed the lockup happening at
> > the actual system "mount()" call, which never returns.
> >
> > Since mount() is in glibc, it might be relevant to note that I'm running
> > Mandrake's glibc 2.1.3-16mdk. I compiled the kernel with a gcc of 2.95.3
> > [1991030] (although oddly enough this binary seems to have come with the
> > gcc-2.95.2 RPM and installed itself as /usr/bin/gcc-2.95.2) and binutils
> > 2.10.0.24-4mdk.
> I also experience this problem (using a floppy disk image created by
> dd if=/dev/fd0 of=floppy.img bs=1024, and then mount -o loop
> floppy.img /mnt/floppy ) with a different version
> of glibc (RedHat's 2.1.92-5 rpm) and binutils (binutils-2.10.0.18-1). Loop
> is compiled into the kernel.
>
> Once the mount command was executed, my load average shot up to a steady
> 1.0 on an idle system, and remained there until I rebooted. top
> et. al. showed no cpu utilization by the frozen mount.

Jens Axboe, along with a number of other people, has put in a lot
of time coming up with a fix for the loop mount lockups.  You can either
get his patch directly from
ftp://ftp.kernel.org/pub/linux/kernel/people/axboe/patches/
or simply use the most recent 2.4.2-ac patch (from
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/
) to get this updated loop device code.  I'm certain Jens would
like to hear from you if you find any problems with the updated code.
Cheers,
- Bill

---
The day Microsoft makes something that doesn't suck is
probably the day they start making vacuum cleaners.
--  Ernst Jan Plugge
(Courtesy of Christian Vogel <[EMAIL PROTECTED]>)
--
William Stearns ([EMAIL PROTECTED]).  Mason, Buildkernel, named2hosts,
and ipfwadm2ipchains are at:http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.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: "mount -o loop" lockup issue

[David Konerding]

It's a bug in Linux 2.4.2, fixed in later versions.  Regression/quality control
testing would
have caught this, but the developers usually just break things and wait for people
to complain
as their "Regression" testers.

Jason Madden wrote:

> On Mon, 26 Mar 2001, David E. Weekly wrote:
>
> > On Linux 2.4.2, running a "mount -o loop" on a file properly created with
> > "dd if=/dev/zero of=/path/to/my/file.img count=1024" seems to decide to
> > freeze up my shell (not my system). An strace showed the lockup happening at
> > the actual system "mount()" call, which never returns.
> >
> > Since mount() is in glibc, it might be relevant to note that I'm running
> > Mandrake's glibc 2.1.3-16mdk. I compiled the kernel with a gcc of 2.95.3
> > [1991030] (although oddly enough this binary seems to have come with the
> > gcc-2.95.2 RPM and installed itself as /usr/bin/gcc-2.95.2) and binutils
> > 2.10.0.24-4mdk.
> I also experience this problem (using a floppy disk image created by
> dd if=/dev/fd0 of=floppy.img bs=1024, and then mount -o loop
> floppy.img /mnt/floppy ) with a different version
> of glibc (RedHat's 2.1.92-5 rpm) and binutils (binutils-2.10.0.18-1). Loop
> is compiled into the kernel.
>
> Once the mount command was executed, my load average shot up to a steady
> 1.0 on an idle system, and remained there until I rebooted. top
> et. al. showed no cpu utilization by the frozen mount.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: "mount -o loop" lockup issue

[Mohammad A. Haque]

Jason Madden wrote:
> 
> On Mon, 26 Mar 2001, David E. Weekly wrote:
> 
> > On Linux 2.4.2, running a "mount -o loop" on a file properly created with
> > "dd if=/dev/zero of=/path/to/my/file.img count=1024" seems to decide to
> > freeze up my shell (not my system). An strace showed the lockup happening at
> > the actual system "mount()" call, which never returns.

> I also experience this problem (using a floppy disk image created by
> dd if=/dev/fd0 of=floppy.img bs=1024, and then mount -o loop
> floppy.img /mnt/floppy ) with a different version
> of glibc (RedHat's 2.1.92-5 rpm) and binutils (binutils-2.10.0.18-1). Loop
> is compiled into the kernel.

Follow this thread -->


Latest loop patch is available at


-- 

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

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

Re: "mount -o loop" lockup issue

[Jason Madden]

On Mon, 26 Mar 2001, David E. Weekly wrote:

> On Linux 2.4.2, running a "mount -o loop" on a file properly created with
> "dd if=/dev/zero of=/path/to/my/file.img count=1024" seems to decide to
> freeze up my shell (not my system). An strace showed the lockup happening at
> the actual system "mount()" call, which never returns.
> 
> Since mount() is in glibc, it might be relevant to note that I'm running
> Mandrake's glibc 2.1.3-16mdk. I compiled the kernel with a gcc of 2.95.3
> [1991030] (although oddly enough this binary seems to have come with the
> gcc-2.95.2 RPM and installed itself as /usr/bin/gcc-2.95.2) and binutils
> 2.10.0.24-4mdk.
I also experience this problem (using a floppy disk image created by
dd if=/dev/fd0 of=floppy.img bs=1024, and then mount -o loop
floppy.img /mnt/floppy ) with a different version
of glibc (RedHat's 2.1.92-5 rpm) and binutils (binutils-2.10.0.18-1). Loop
is compiled into the kernel.

Once the mount command was executed, my load average shot up to a steady
1.0 on an idle system, and remained there until I rebooted. top
et. al. showed no cpu utilization by the frozen mount.


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

Re: ReiserFS phenomenon with 2.4.2 ac24/ac12

[Christoph Lameter]

On Mon, 26 Mar 2001, Chris Mason wrote:
> On Monday, March 26, 2001 03:21:29 PM -0800 Christoph Lameter
> > On Mon, 26 Mar 2001, Chris Mason wrote:
> >> On Saturday, March 24, 2001 11:56:08 AM -0800 Christoph Lameter
> >> <[EMAIL PROTECTED]> wrote:
> >> > I got a directory /a/yy that I tried to erase with rm -rf /a/yy.
> >> > 
> >> > rm hangs...
> >> > 
> >> > ls gives the following output:
> >> > 
> >> > ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
> >> > ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
> >> > ls: /a/yy/cache3A8CCC6A0490B05.gifcache393C2B6A2CD2DF1.crumb: No such
> >> > file or directory
> >> > ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
> >> > ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
> >> > ls: /a/yy/cache3A8CCC6A0490B05.gifcache393C2B6A2CD2DF1.crumb: No such
> >> > file or directory
> >> > 
> >> > and so on and so on
> >> > 
> >> > I tried a reiserfscheck -x on the /a volume but the strangeness still
> >> > persists. What is going on here?
> >> There should be more messages on the console that will help identify the
> >> problem.  Please check through /var/log/messages and send along anything
> >> that looks odd.
> > 
> > 
> > Yes I see messages like this in the log:
> > 
> > Mar 26 06:47:50 k2-400 kernel: Out of Memory: Killed process 421 (mysqld).
> 
> Hmmm, I was expecting something from reiserfs.  The file not found messages
> from ls usually go along with warnings from reiserfs about an i/o error.
> What does a readonly reiserfsck say (without the -x).

Sorry the HD is ok. Is there any way to get rid of the mess?

output of reiserfsck:

grow_id_map: objectid map expanded: used 1024, 1 blocks
bad_leaf: block 9454 has invalid item 4: 1928 5204 0x1 DIR, len 184, entry count 5, 
fsck need 0, format old
grow_id_map: objectid map expanded: used 2048, 2 blocks
grow_id_map: objectid map expanded: used 3072, 3 blocks
grow_id_map: objectid map expanded: used 4096, 4 blocks
shrink_id_map: objectid map shrinked: used 4096, 5 blocks
grow_id_map: objectid map expanded: used 4096, 4 blocks
shrink_id_map: objectid map shrinked: used 4096, 5 blocks
grow_id_map: objectid map expanded: used 4096, 4 blocks
grow_id_map: objectid map expanded: used 5120, 5 blocks
grow_id_map: objectid map expanded: used 6144, 6 blocks
grow_id_map: objectid map expanded: used 7168, 7 blocks
grow_id_map: objectid map expanded: used 8192, 8 blocks
grow_id_map: objectid map expanded: used 9216, 9 blocks
grow_id_map: objectid map expanded: used 10240, 10 blocks
grow_id_map: objectid map expanded: used 11264, 11 blocks
grow_id_map: objectid map expanded: used 12288, 12 blocks
shrink_id_map: objectid map shrinked: used 12288, 13 blocks
grow_id_map: objectid map expanded: used 12288, 12 blocks
shrink_id_map: objectid map shrinked: used 12288, 13 blocks
grow_id_map: objectid map expanded: used 12288, 12 blocks
grow_id_map: objectid map expanded: used 13312, 13 blocks
shrink_id_map: objectid map shrinked: used 13312, 14 blocks
grow_id_map: objectid map expanded: used 13312, 13 blocks
shrink_id_map: objectid map shrinked: used 13312, 14 blocks
grow_id_map: objectid map expanded: used 13312, 13 blocks
shrink_id_map: objectid map shrinked: used 13312, 14 blocks
grow_id_map: objectid map expanded: used 13312, 13 blocks
shrink_id_map: objectid map shrinked: used 13312, 14 blocks
shrink_id_map: objectid map shrinked: used 12288, 13 blocks
shrink_id_map: objectid map shrinked: used 11264, 12 blocks
grow_id_map: objectid map expanded: used 11264, 11 blocks
shrink_id_map: objectid map shrinked: used 11264, 12 blocks
grow_id_map: objectid map expanded: used 11264, 11 blocks
shrink_id_map: objectid map shrinked: used 11264, 12 blocks
grow_id_map: objectid map expanded: used 11264, 11 blocks
shrink_id_map: objectid map shrinked: used 11264, 12 blocks
grow_id_map: objectid map expanded: used 11264, 11 blocks
grow_id_map: objectid map expanded: used 12288, 12 blocks
shrink_id_map: objectid map shrinked: used 12288, 13 blocks
grow_id_map: objectid map expanded: used 12288, 12 blocks
shrink_id_map: objectid map shrinked: used 12288, 13 blocks
grow_id_map: objectid map expanded: used 12288, 12 blocks
shrink_id_map: objectid map shrinked: used 12288, 13 blocks
grow_id_map: objectid map expanded: used 12288, 12 blocks
shrink_id_map: objectid map shrinked: used 12288, 13 blocks
grow_id_map: objectid map expanded: used 12288, 12 blocks
shrink_id_map: objectid map shrinked: used 12288, 13 blocks
grow_id_map: objectid map expanded: used 12288, 12 blocks
shrink_id_map: objectid map shrinked: used 12288, 13 blocks
grow_id_map: objectid map expanded: used 12288, 12 blocks
shrink_id_map: objectid map shrinked: used 12288, 13 blocks
grow_id_map: objectid map expanded: used 12288, 12 blocks
shrink_id_map: objectid map shrinked: used 12288, 13 blocks
free block count 447444 mismatches with a correct one 447840. 
on-disk bitmap does not match to the correct one. 
check_semantic_tree: 

Re: ATAPI burner and IDE SCSI emulation

[Ben Ford]

I believe this has more to do with how the author of cdrecord chose to 
implement it rather than the kernel.  Why don't you speak to him?

-b

Andreas Franck wrote:

> Hello people,
> 
> after having "upgraded" (?) my distro from my wonderfully hand-configured 
> Debian system (which I unfortunately wrecked up lately) to S*SE 7.1, I'm now 
> really displeasured about the IDE-SCSI emulation thing for my ATAPI CD 
> roaster. Not that I was not able to set it up correctly, but being a bit 
> fastidious and used to be able to configure almost everything I wanted, 
> including what drivers I wanted to load, by choosing modules I was deeply 
> disappointed about the sof the IDE SCSI emulation driver, which seems really 
> baroque. 
> 
> For the unknowing, here are the general "newbie" steps nneded to make a 
> simple ATAPI CD roaster roast at all: Compile the kernel with IDE-SCSI 
> support enabled (or as a module), then you have to pass a mysterious 
> "hdx=ide-scsi" on the kernel commandline (through LILO or whatsoever), then 
> the "normal" IDE driver refuses to take any control over your CD burner. This 
> makes it possible for the IDE SCSI driver to take this job.
> 
> To actually USE my burner, it even gets more complicated (... I always speak 
> for the "Joe Blow" user, I have gone through all this and succeeded 
> finally...) - I have not only to load the SCSI CD-ROM driver to be able to 
> read any CDs with the burner, reset the /dev/cdrom (or /dev/cdburner) link 
> accordingly, but I also need this mysterious generic SCSI module loaded...
> 
> People, my say this is the biggest mess of configuration for me since I last 
> built up my first WNOS TCP/IP system, which was 7 years ago. And this is my 
> mission:
> 
> Clean this mess up. Make CD roasting work fine without this SCSI crap (sorry, 
> no offense intended, but from the "user perspective" its friendliness goes 
> far to -ininity...)
> 
> I'd appreciate any comments, am willing to take big slaps on my head from any 
> major wood part, and would like to know if anything/anyone is already working 
> towards this, or is doing any other tasks in this area.
> 
> Im particular I'd better look at the packet writing stuff (who's involved? 
> Jens Axboe?) before I start anything too big :) Again, any comments or 
> pointers to other projects are welcome, I can't wait to be able to toast CDs 
> on my machine without going through this nightmare again :-)
> 
> Greetings (and: please don't take anything personal or too serious, it's just 
> me being frustrated after having set up my system and nothing working 
> again...)
> 
> Andreas
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


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

question \ information request on init \ boot sequence when using initrd

[Amit D Chaudhary]

Hi,

We(my team) had some questions regarding booting from initrd and using 
/linuxrc. It will help someone(David, Werner,...) can give their 
thoughts on this.

To put it in brief, since running sbin/init from /linuxrc as resulting 
in init not having PID 1 and thereby not doing some initialization as 
expected.

Thereby instead of loading running /sbin/init, we just set 
/proc/sys/kernel/real-root-dev to /dev/ram0's value which then does the 
following
runs 2 statements in init/main.c to unlock_kernel and free init memory 
and then run sbin/init.
This results in /sbin/init running fine.

Is this ok or should be modify /sbin/init to run properly inspite of PID 
<> 1 or is there a 3rd way of doing this?

Thanks
Amit



This is on linux-2.4.1 kernel running on PPC.
/linuxrc is as follow:

../bin/mount -t ramfs none tmp_rootfs

#untar'ing the new root.
../bin/tar -b 512 -zxf /dev/mtd1

mkdir initrd
../bin/pivot_root . initrd

exec sbin/chroot . sbin/init.new 3 dev/console 2>&1


The above results in init running with PID != 1 and thereby skipping 
some relevant processing my default. see ps output below:

Instead of the "chroot" above is changed to following
exec sbin/chroot . sh -c 'bin/mount proc proc -t proc; echo 0x0100 > 
proc/sys/kernel/real-root-dev'
And linuxrc exits



(none):root> ps -e
   PID TTY  TIME CMD
 1 ?00:00:04 swapper
 2 ?00:00:00 keventd
 3 ?00:00:00 kswapd
 4 ?00:00:00 kreclaimd
 5 ?00:00:00 bdflush
 6 ?00:00:00 kupdate
 7 ?00:00:00 mtdblockd
 8 ?00:00:00 init
26 ?00:00:00 sh
39 ?00:00:00 portmap
50 ?00:00:00 ypbind
51 ?00:00:00 ypbind
84 ?00:00:00 inetd
93 ?00:00:00 syslogd
   100 ?00:00:00 klogd
   119 ?00:00:00 ps


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 while futzing with nfsboot 2.4.2-ac24

[Eric Buddington]

This ooops happened while trying to nfsboot a 386, and restarting nfsd
halfway through the boot process. I bet it's not a common problem...

Server is 2.4.2-ac23, client (the Oopser) is 2.4.2-ac24.

The oops is partial because I had to hand-copy from the console, and
it blanked after a few minutes. The client was trying to mount its
root fs at the time (it failed).

-Eric

--

ksymoops 2.4.1 on i586 2.4.2-ac23.  Options used
 -V (default)
 -K (specified)
 -L (specified)
 -O (specified)
 -m /packages/linux/2.4.2-ac24/i386-nfsroot/boot/System.map (specified)

*pde = 
Oops: 
EIP: 0010:[<>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax:  ebx: fff4 ecx: c0095420 edx: c0095380
Call Trace: [ ]
Code: Bad EIP value

>>EIP;  Before first symbol
Trace; c0139c37 
Trace; c0139fe7 
Trace; c013aa2f 
Trace; c012fb22 
Trace; c012fe25 
Trace; e0108d73 

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

Re: 2.4.3-pre8 problem with 8139too - failure to load

[Tom Eastep]

Thus spoke Frank Jacobberger:


> Trying to do insmod 8139too.o from the :
> /lib/modules/2.4.3-pre8/kernel/drivers/net directory show these
> unresolved symbols:
>
> 8139too.o: unresolved symbol alloc_etherdev
> 8139too.o: unresolved symbol unregister_netdev
> 8139too.o: unresolved symbol register_netdev
>

I ran into a similar problem with tulip.o -- I was able to work around the
problem by turning off module versioning (CONFIG_MODVERSIONS).

-Tom
-- 
Tom Eastep \ Alt Email: [EMAIL PROTECTED]
ICQ #60745924   \ Websites: http://seawall.sourceforge.net
[EMAIL PROTECTED]   \  http://seattlefirewall.dyndns.org
Shoreline, Washington USA \ http://shorewall.sourceforge.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/

[PATCH] Very small fix for 2.4.3-pre8 unresolved symbols

[Ian Hastie]

It just adds net_init.o to the definition of export-objs.

--- linux-2.4.3-pre8/drivers/net/Makefile.symbols   Tue Mar 27 00:30:58 2001
+++ linux-2.4.3-pre8/drivers/net/Makefile   Tue Mar 27 03:00:21 2001
@@ -16,7 +16,7 @@
 # This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'.
 
 export-objs := 8390.o arlan.o aironet4500_core.o aironet4500_card.o 
ppp_async.o \
-   ppp_generic.o slhc.o pppox.o auto_irq.o
+   ppp_generic.o slhc.o pppox.o auto_irq.o net_init.o
 
 ifeq ($(CONFIG_TULIP),y)
   obj-y += tulip/tulip.o

-- 
Ian.

I don't have a sig either!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] one-line bugfix 2.4.2 iobuf.c

[Anthony J. Battersby]

Explanation:

The bufp pointer should be indexed rather than incremented because it is used
a few lines above as a base pointer to free successfully allocated items if
kmalloc fails.

 Begin Patch 

--- fs/iobuf.c.orig Wed Mar 21 10:12:36 2001
+++ fs/iobuf.c  Wed Mar 21 10:12:30 2001
@@ -55,7 +55,7 @@
return -ENOMEM;
}
kiobuf_init(iobuf);
-   *bufp++ = iobuf;
+   bufp[i] = iobuf;
}
 
return 0;

 End Patch 

When replying, please CC me at [EMAIL PROTECTED] since I am not subscribed to
the mailing list.

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

"mount -o loop" lockup issue

[David E. Weekly]

On Linux 2.4.2, running a "mount -o loop" on a file properly created with
"dd if=/dev/zero of=/path/to/my/file.img count=1024" seems to decide to
freeze up my shell (not my system). An strace showed the lockup happening at
the actual system "mount()" call, which never returns.

Since mount() is in glibc, it might be relevant to note that I'm running
Mandrake's glibc 2.1.3-16mdk. I compiled the kernel with a gcc of 2.95.3
[1991030] (although oddly enough this binary seems to have come with the
gcc-2.95.2 RPM and installed itself as /usr/bin/gcc-2.95.2) and binutils
2.10.0.24-4mdk.

I'm very sorry to post to this list, but several people independantly told
me that there was a loopback mountpoint deadlocking issue with 2.4.2 and
that I should check here. Of course, this could be a completely retarded
system configuration issue, in which case please shut me up and I'll go away
quietly. But if it is an issue with a known resolution I'd love to hear it -
I wasn't able to find resolution on the web or with several rather
knowledgeable people.

-david weekly [[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: Linux Worm (fwd)

[Drew Bertola]

Bob_Tracy writes: 
> So let's quit covering for 'em.  Let's have the name(s) behind that
> idiotic policy letter, because I would not knowingly allow any company
> I work for to hire such people.
> 
> ProblemRemedy
>   -----
>   hangnail   amputate
>   headache   amputate
>   (etc.)

you can add:
cancer withdraw into complete denial

-- 
Drew Bertola  | Send a text message to my pager or cell ... 
  |   http://jpager.com/Drew

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

Re: ASSISTANCE

[Stefan Becker]

Juha Saarinen wrote:
> This is a variant on the Nigerian Scam... avoid at all cost.
This is very funny.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Lovely crash with 2.4.2-ac24.

[Andrew Morton]

"Zephaniah E. Hull" wrote:
> 
> [-ac24 crash]

Guys, this is related to the tty hangup code calling the
console code in interrupt context.  Fixed in -ac25.  The
IDE connection is just stack fluff.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OT] Sane Architectures

[Matthew Fredrickson]

On Mon, Mar 26, 2001 at 06:07:56PM -0500, Adam Schrotenboer wrote:
> > alpha?  mips?
> 
> Yes, I just didn't feel like listing all arch's. Plus, (ducks) the MIPS 
> is no longer supported by Windoze, and I rarely see any discussion on lk 
> about this arch, and I forgot about Alpha for a minute.

Mostly because there is an entirely seperate mailing list for MIPS issues.
You'll find a quite active list that is so prestegious there are guys
that work the MIPS Technologies (The MIPS people :-) ) on it.  You might even
want to check in on it.  The MIPS arch is actually quite nice.  It has
generally good FP performance, a large pool of general use registers, and many
other really convenient attributes.  You can join the list by sending a
mail to [EMAIL PROTECTED] with 

subscribe linux-mips [EMAIL PROTECTED]

in the body.

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

2.4.2-ac25 Compile error in es1370.c

[Art Wagner]

Alan;
I got the attached compile error in /drivers/sound/es1370.c.
If any further information might be helpful please e-mail me or 
post to LKML.
Art Wagner
[EMAIL PROTECTED]


make[2]: Leaving directory `/usr/src/linux-2.4.2-ac/drivers/scsi'
make[2]: Entering directory `/usr/src/linux-2.4.2-ac/drivers/video'
make -C aty modules
make[3]: Entering directory `/usr/src/linux-2.4.2-ac/drivers/usb/storage'
ld -m elf_i386 -r -o usb-storage.o scsiglue.o protocol.o transport.o usb.o 
initializers.o debug.o freecom.o
make[3]: Leaving directory `/usr/src/linux-2.4.2-ac/drivers/usb/storage'
make[2]: Leaving directory `/usr/src/linux-2.4.2-ac/drivers/usb'
make[3]: Entering directory `/usr/src/linux-2.4.2-ac/drivers/video/aty'
make[3]: Nothing to be done for `modules'.
make[3]: Leaving directory `/usr/src/linux-2.4.2-ac/drivers/video/aty'
make[2]: Leaving directory `/usr/src/linux-2.4.2-ac/drivers/video'
es1370.c: In function `es1370_probe':
es1370.c:2667: structure has no member named `trigger'
es1370.c:2667: structure has no member named `read'
make[2]: *** [es1370.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.4.2-ac/drivers/sound'
make[1]: *** [_modsubdir_sound] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.2-ac/drivers'
make: *** [_mod_drivers] Error 2

Re: ReiserFS phenomenon with 2.4.2 ac24/ac12

[Christoph Lameter]

On Mon, 26 Mar 2001, Chris Mason wrote:

> On Saturday, March 24, 2001 11:56:08 AM -0800 Christoph Lameter
> <[EMAIL PROTECTED]> wrote:
> 
> > I got a directory /a/yy that I tried to erase with rm -rf /a/yy.
> > 
> > rm hangs...
> > 
> > ls gives the following output:
> > 
> > ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
> > ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
> > ls: /a/yy/cache3A8CCC6A0490B05.gifcache393C2B6A2CD2DF1.crumb: No such file
> > or directory
> > ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
> > ls: /a/yy/cache3A0F94EA0A00557.html: No such file or directory
> > ls: /a/yy/cache3A8CCC6A0490B05.gifcache393C2B6A2CD2DF1.crumb: No such file
> > or directory
> > 
> > and so on and so on
> > 
> > I tried a reiserfscheck -x on the /a volume but the strangeness still
> > persists. What is going on here?
> There should be more messages on the console that will help identify the
> problem.  Please check through /var/log/messages and send along anything that
> looks odd.


Yes I see messages like this in the log:

Mar 26 06:47:50 k2-400 kernel: Out of Memory: Killed process 421 (mysqld).
Mar 26 06:48:02 k2-400 kernel: Out of Memory: Killed process 425 (mysqld).
Mar 26 06:48:04 k2-400 kernel: Out of Memory: Killed process 426 (mysqld).
Mar 26 06:48:04 k2-400 kernel: Out of Memory: Killed process 427 (mysqld).
Mar 26 06:48:04 k2-400 kernel: Out of Memory: Killed process 562 (apache).
Mar 26 06:48:04 k2-400 kernel: Out of Memory: Killed process 563 (apache).
Mar 26 06:48:04 k2-400 kernel: Out of Memory: Killed process 564 (apache). 
 


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

Re: Larger dev_t

[Guest section DW]

On Mon, Mar 26, 2001 at 01:18:06PM -0800, John Byrne wrote:

> Do you have any interest in doing away with the concept of major and
> minor numbers altogether; turning the dev_t into an opaque unique id?
> 
> At the application level, the kinds of information that is derived from
> the major/minor number should probably be derived in some other manner
> such as a library or system call. Code that determines device type by
> comparing with the major/minor numbers should probably be discouraged in
> the long run and this could be a good time to start.

Programs that use explicit major/minor information are probably broken
or at least very nonportable.
On the other hand, unfortunately the Unix API has a few explicit
occurrences of major/minor. For example, one has ls(1) and mknod(1).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OT] Sane Architectures

[Adam Schrotenboer]

Mark Hahn wrote:

>> Are there any architectures that are simple (sane) to implement sftw on? 
> 
> 
> sftw?  software?  yes: portable C/C++ is a fine platform.

Not really the platform, but the architecture, from a C/C++ compiler and 
kernel/asm/lowlevel lang development standpoint

> 
>> The i386 is plagued by it's 16-bit (arguably its 8 or even 4 bit) past. 
> 
> 
> I wonder what you mean by that.  it's ia32's accumulator-based
> architecture, and stack-based FPU that "plague" it, neither of which
> has anything to do with bitness.  or are you actually talking about
> instruction encoding?

the limited number of registers (3 bits allocated, IIRC) which limits 
the number to 8 minus CS,DS,IP; meaning only 5 GPRs, the requirement of 
an (antiquated) BIOS (design), 16-bit bootstrap

> 
>> This can include architectures like the IA64 & the upcoming x86-64. Just 
>> looking for something with lots of GPR's, sane MM support, etc.
> 
If not lots of GPRs, but at least enough to be able to allocate sanely.

> 
> alpha?  mips?

Yes, I just didn't feel like listing all arch's. Plus, (ducks) the MIPS 
is no longer supported by Windoze, and I rarely see any discussion on lk 
about this arch, and I forgot about Alpha for a minute.

I admit that I likely look like an idiot right now, and I am not 
intending to insult anyone, just curious about this.

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

ATAPI burner and IDE SCSI emulation

[Andreas Franck]

Hello people,

after having "upgraded" (?) my distro from my wonderfully hand-configured 
Debian system (which I unfortunately wrecked up lately) to S*SE 7.1, I'm now 
really displeasured about the IDE-SCSI emulation thing for my ATAPI CD 
roaster. Not that I was not able to set it up correctly, but being a bit 
fastidious and used to be able to configure almost everything I wanted, 
including what drivers I wanted to load, by choosing modules I was deeply 
disappointed about the sof the IDE SCSI emulation driver, which seems really 
baroque. 

For the unknowing, here are the general "newbie" steps nneded to make a 
simple ATAPI CD roaster roast at all: Compile the kernel with IDE-SCSI 
support enabled (or as a module), then you have to pass a mysterious 
"hdx=ide-scsi" on the kernel commandline (through LILO or whatsoever), then 
the "normal" IDE driver refuses to take any control over your CD burner. This 
makes it possible for the IDE SCSI driver to take this job.

To actually USE my burner, it even gets more complicated (... I always speak 
for the "Joe Blow" user, I have gone through all this and succeeded 
finally...) - I have not only to load the SCSI CD-ROM driver to be able to 
read any CDs with the burner, reset the /dev/cdrom (or /dev/cdburner) link 
accordingly, but I also need this mysterious generic SCSI module loaded...

People, my say this is the biggest mess of configuration for me since I last 
built up my first WNOS TCP/IP system, which was 7 years ago. And this is my 
mission:

Clean this mess up. Make CD roasting work fine without this SCSI crap (sorry, 
no offense intended, but from the "user perspective" its friendliness goes 
far to -ininity...)

I'd appreciate any comments, am willing to take big slaps on my head from any 
major wood part, and would like to know if anything/anyone is already working 
towards this, or is doing any other tasks in this area.

Im particular I'd better look at the packet writing stuff (who's involved? 
Jens Axboe?) before I start anything too big :) Again, any comments or 
pointers to other projects are welcome, I can't wait to be able to toast CDs 
on my machine without going through this nightmare again :-)

Greetings (and: please don't take anything personal or too serious, it's just 
me being frustrated after having set up my system and nothing working 
again...)

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

VIA686b chipset and dma_intr errors, and 3c905B errors

[Nicholas Petreley]

> 
> Ok, now its clear that I have a big troubles with hardware.
> I compiled kernel 2.2.18+IDE_patches with support for VIA chipset and still get
> errors of type:
> 
> kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> 
> before these kernel reports a long string of messages
> 

I got those errors on a brand new IBM ATA100 drive.  I
exchanged it for a new one which worked fine for a couple
of weeks, but now the new one is beginning to give me the
same errors.  I've noticed a rash of people reporting these
errors since 2.4.x.  Is it really that the new kernel is
simply better at reporting bad drives?  Or is there
something else going on with the kernel?  (Or are IBM
drives just crappy?)

Here's a portion of the messages I'm getting...

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error}
hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=48973752, sector=1854944
end_request: I/O error, dev 03:08 (hda), sector 1854944

asus a7v/kt133
IDE is Via 686b

By the way, my 3c905B went bahooties since about ac21 I
think.  I was under the impression that Alan backed out of
the suspected changes for ac23 but the problem remained.  I
replaced it with an eepro100, but I don't know if it's the
card or what.

-Nick


-- 
**
Nicholas Petreley   Caldera Systems - LinuxWorld/InfoWorld
[EMAIL PROTECTED] - http://www.petreley.com - Eph 6:12
**
.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

CML2 0.9.7 is available

[Eric S. Raymond]

Release 0.9.7: Mon Mar 26 16:55:48 EST 2001
* Can now configure everything except the CONFIG_-less CRIS symbols.
* Prefix-stripping for backward compatibility with, e.g. CONFIG_3C515.
* Resolve all FIXMES, including Andre Hedrick's IDE vendor stuff.

CML2 can now configure symbols with leading numerics, removing the
last remaining CML1 compatibility problem.  Once the CRIS-architecture
symbols are brought into conformance with the CML1 spec, CML2 will
be able to completely configure a stock kernel tree.  All known gaps
in the CML1 translation have been fixed.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

The abortion rights and gun control debates are twin aspects of a deeper
question --- does an individual ever have the right to make decisions
that are literally life-or-death?  And if not the individual, who does?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] Questions about *_do_scsi & create_proc_entry

[Jeff Garzik]

>   Another question is that by inspecting the NULL checker's result, I
> found that *_do_scsi is always used in the following way "SRpnt =
> *_do_scsi(SRPnt, ...)" no matther SRPnt is NULL or not. If SRpnt is not
> NULL, why don't just use
>  *_do_scsi(SRPnt, ...);
> The same thing happens to init_etherdev.

WRT init_etherdev, that's the intended effect, because it's 'dev' arg
might indeed by NULL.

-- 
Jeff Garzik   | May you have warm words on a cold evening,
Building 1024 | a full moon on a dark night,
MandrakeSoft  | and a smooth road all the way to your door.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.2.19 aic7xxx breaks pcmcia

[Keith Owens]

On Mon, 26 Mar 2001 08:48:09 -0800, 
David Hinds <[EMAIL PROTECTED]> wrote:
>On Mon, Mar 26, 2001 at 05:14:13PM +1000, Keith Owens wrote:
>What are the things you're planning that will cause trouble?

Support for building third party drivers and patch sets as separate
source trees.  Base kernel in in one source tree, external patch or
driver set is in another source tree, kbuild reads from multiple source
trees and writes to a separate object directory.  The multiple source
trees break the assumption that all source is in one tree, lines like
  #include <../drivers/scsi/aic7xxx.h>
do not work with multiple sources.

You are right about the long compile lines though, example with three
source trees, reflowed for readability.

/usr/bin/kgcc -I /build/kaos/2.4.1-object-kdb/arch/i386/kernel/
  -I /build/kaos/kdb/arch/i386/kernel/
  -I /build/kaos/common/arch/i386/kernel/
  -I /build/kaos/2.4.1-makefile-2.5/arch/i386/kernel/ -I-
  -D__ASSEMBLY__  -D__KERNEL__ -I include -I .tmp_include/src_002
  -I .tmp_include/src_001 -I .tmp_include/src_000 -traditional -c
  -o arch/i386/kernel/trampoline.o
  /build/kaos/2.4.1-makefile-2.5/arch/i386/kernel/trampoline.S

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

Re: Larger dev_t

[Linus Torvalds]

On Mon, 26 Mar 2001, John Byrne wrote:

> > Re: Larger dev_t
> >
> On Sat Mar 24 2001 Linus Torvalds ([EMAIL PROTECTED]) wrote:
> > There is no way in HELL I will ever accept a 64-bit dev_t.
> >
> > I _will_ accept a 32-bit dev_t, with 12 bits for major numbers, and 20
> > bits for minor numbers.
>
> Do you have any interest in doing away with the concept of major and
> minor numbers altogether; turning the dev_t into an opaque unique id?

Inside the kernel we'll eventually do that.

However, outside the kernel you still need the notion of device numbers if
for no other reasons than legacy /dev space (other applications like 'tar'
care too, but they only care about uniqueness, not about much else).

> At the application level, the kinds of information that is derived from
> the major/minor number should probably be derived in some other manner
> such as a library or system call.

It is. It's called "stat()", and a lot of people do depend on a
device number being available. Few people care what that number actually
_is_, though.

So device numbers aren't going away, they are very much part of the UNIX
legacy. We don't need to care about them too much inside the kernel,
though. What most drivers really want to know is "sub-unit number", and
not much else.

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/

Re: CML1 cleanup patch, take 3

[Eric S. Raymond]

Philip Blundell <[EMAIL PROTECTED]>:
> >if [ "$CONFIG_PRINTER" != "n" ]; then
> >-  bool 'Support IEEE1284 status readback' CONFIG_PRINTER_READBACK
> >+  bool 'Support IEEE1284 status readback' CONFIG_PARPORT_1284
> >fi
> 
> This isn't really right.  Although it's true that
> CONFIG_PARPORT_1284 enables the stuff that used to be controlled by
> CONFIG_PRINTER_READBACK, the two aren't synonymous.  The m68k port
> ought to just use drivers/parport/Config.in like everybody else.

Yes, I figured this out.  The CML2 rules file section for m68k already uses
the normal, architecture-independent parallel-port subtree (some of the
individual options in it are suppressed on certain platforms).

At this point, the only place CONFIG_PRINTER_READBACK actually occurs
seems to be in doc files.  So selecting it is a no-op, but one that
obviously means the user wanted the IEEE1284 support.  Even given the
two aren't equivalent, I don't see a better way to handle this than the
above.  Let's be kind to our 2.4.x users.

-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

The right of self-defense is the first law of nature: in most
governments it has been the study of rulers to confine this right
within the narrowest limits possible.  Wherever standing armies
are kept up, and when the right of the people to keep and bear
arms is, under any color or pretext whatsoever, prohibited,
liberty, if not already annihilated, is on the brink of
destruction." 
-- Henry St. George Tucker (in Blackstone's Commentaries)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problems with Wake on LAN

[Santiago Garcia Mantinan]

> Are you using Becker's ftp://www.scyld.com/pub/diag/ether-wake.c ?

Yes.

> Did you turn on the enable_wol module option?  Note that might be a new
> option in the 2.4.3-preXX series...

Well, it is indeed a 2.4.3-pre feature, as I had looked for it on 2.4.2, it
was not there, but it is at least on pre8.

This new driver allows me to WOL, but only if I don't choose ACPI, if I
choose ACPI then I have the same problem as with 2.4.2. APM works ok though.

Thanks for your help, now I'm gonna ask the ACPI guys about this.

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

Re: [PATCH] OOM handling

[Jonathan Morton]

>> Understood - my Physics courses covered this as well, but not using the
>> word "normalise".
>
>Be that as it may, Martin's comments about normalizing are nonsense.
>Rik's killer (at least in 2.4.3-pre7) produces a badness value that's
>a product of badness factors of various units.  It then uses these
>products only for relative comparisons, choosing the process with
>maximum badness product to kill.  No normalization is necessary, nor
>would it have any effect.
>
>The reason a 256 Meg process on a 1 Gig machine was being killed had
>nothing to do with normalization---it was a bug where the OOM killer
>was being called long before we were reduced to last resorts.

Of course, I realised that.  Actually, what the code does is take an
initial badness factor (the memory usage), then divide it using goodness
factors (some based on time, some purely arbitrary), both of which can be
considered dimensionless.  Also, at the end, the absolute value is not
considered - we simply look at the biggest one and kill it.  All
"denormalisation" does is scale all the values, it doesn't affect which one
actually turns out biggest.


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

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

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

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-END GEEK CODE BLOCK-


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

Re: CML1 cleanup patch, take 3

[Philip Blundell]

>if [ "$CONFIG_PRINTER" != "n" ]; then
>-  bool 'Support IEEE1284 status readback' CONFIG_PRINTER_READBACK
>+  bool 'Support IEEE1284 status readback' CONFIG_PARPORT_1284
>fi

This isn't really right.  Although it's true that CONFIG_PARPORT_1284 enables 
the stuff that used to be controlled by CONFIG_PRINTER_READBACK, the two 
aren't synonymous.  The m68k port ought to just use drivers/parport/Config.in 
like everybody else.

p.


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

Re: 64-bit block sizes on 32-bit systems

[Jonathan Morton]

>These are NOT the only 64 bit systems - Intel, PPC, IBM (in various guises).
>If you need raw compute power, the Alpha is pretty good (we have over a
>1000 in a Cray T3..).

Best of all, the PowerPC and the POWER are binary-compatible to a very
large degree - just the latter has an extra set of 64-bit instructions.
What was that I was hearing about having to redevelop or recompile your
apps for 64-bit?

I can easily imagine a 64-bit filesystem being accessed by a bunch of
RS/6000s and monitored using an old PowerMac.  Goodness, the PowerMac 9600
even has 6 PCI slots to put all those SCSI-RAID and Ethernet cards in.  :)

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

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

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

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-END GEEK CODE BLOCK-


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

[CHECKER] Questions about *_do_scsi & create_proc_entry

[Junfeng Yang]

Hi,

   I have a question about *_do_scsi(Scsi_Request *SRpnt, ...). If *SRpnt
is not NULL, *_do_scsi will not return NULL. I'm not quite sure about the
precondition in the following three 'errors' flaged by the NULL checker.
In these cases, can
*_do_scsi return NULL?

   Another question is that by inspecting the NULL checker's result, I
found that *_do_scsi is always used in the following way "SRpnt =
*_do_scsi(SRPnt, ...)" no matther SRPnt is NULL or not. If SRpnt is not
NULL, why don't just use
 *_do_scsi(SRPnt, ...);
The same thing happens to init_etherdev.

   Last question: we found 3 potential errors in arch/i386/kernel. It
seems that create_proc_entry could return NULL. Please help us to verify
if they are bugs or not.

   As usual, please CC us at [EMAIL PROTECTED] Any help will be
appreciated.

-Junfeng


-
[UNKNOWN] osst_do_scsi will never return NULL if argument SRpnt isn't
NULL. But they copy SRpnt back by *aSRpnt, implies it could be NULL
/u2/acc/oses/linux/2.4.1/drivers/scsi/osst.c:1145:osst_read_back_buffer_and_rewrite:
ERROR:NULL:1042:1145: Using unknown ptr "SRpnt" illegally! set by
'osst_do_scsi':1042

for (i = 0, p = buffer; i < frames; i++, p += OS_DATA_SIZE) {

memset(cmd, 0, MAX_COMMAND_SIZE);
cmd[0] = 0x3C;  /* Buffer Read   */
cmd[1] = 6; /* Retrieve Faulty Block */
cmd[7] = 32768 >> 8;
cmd[8] = 32768 & 0xff;
Start --->
SRpnt = osst_do_scsi(SRpnt, STp, cmd, OS_FRAME_SIZE,
SCSI_DATA_READ,
STp->timeout, MAX_RETRIES,
TRUE);

if ((STp->buffer)->syscall_result) {
printk(KERN_ERR "osst%d: Failed to read block back
from OnStream buffer\n", dev);
vfree((void *)buffer);
*aSRpnt = SRpnt;
return (-EIO);
}
osst_copy_from_buffer(STp->buffer, p);
//  memcpy(p, STp->buffer->b_data, OS_DATA_SIZE);
#if DEBUG
if (debugging)
printk(OSST_DEB_MSG "osst%d: Read back logical
block %d, data %x %x %x %x\n",
  dev, logical_blk_num + i, p[0],
p[1], p[2], p[3]);
#endif
}

SRpnt is copied back
through *aSRpnt here
-->
*aSRpnt = SRpnt;
-
[UNKNOWN]
/u2/acc/oses/linux/2.4.1/drivers/scsi/osst.c:1145:osst_read_back_buffer_and_rewrite:
ERROR:NULL::1145: Using unknown ptr "SRpnt" illegally! set by
'osst_do_scsi':
-
[UNKNOWN] osst_do_scsi can return NULL
/u2/acc/oses/linux/2.4.1/drivers/scsi/osst.c:1243:osst_reposition_and_retry:
ERROR:NULL:1237:1243: Using unknown ptr "SRpnt" illegally! set by
'osst_do_scsi':1237
#if DEBUG
printk(OSST_DEB_MSG "osst%d: About to write
pending lblk %d at frame %d\n",
  dev, STp->logical_blk_num-1,
STp->first_frame_position);
#endif

Start--->
SRpnt = osst_do_scsi(SRpnt, STp, cmd,
OS_FRAME_SIZE, SCSI_DATA_WRITE,
STp->timeout,
MAX_WRITE_RETRIES, TRUE);

Copied back here --->
*aSRpnt = SRpnt;

if (STp->buffer->syscall_result) {  /*
additional write error */
if ((SRpnt->sr_sense_buffer[ 2] & 0x0f) ==
13 &&
 SRpnt->sr_sense_buffer[12] ==
0 &&
 SRpnt->sr_sense_buffer[13] ==
2) {


-
[UNKNOWN] create_proc_entry
/u2/acc/oses/linux/2.4.1/arch/i386/kernel/irq.c:1160:init_irq_proc:
ERROR:NULL:1158:1160: Using unknown ptr "entry" illegally! set by
'create_proc_entry':1158

root_irq_dir = proc_mkdir("irq", 0);

/* create /proc/irq/prof_cpu_mask */
Start-->
entry = create_proc_entry("prof_cpu_mask", 0600, root_irq_dir);
Error-->
entry->nlink = 1;
entry->data = (void *)_cpu_mask;
entry->read_proc = prof_cpu_mask_read_proc;
entry->write_proc = prof_cpu_mask_write_proc;


-
[UNKNOWN] create_proc_entry can return NULL
/u2/acc/oses/linux/2.4.1/arch/i386/kernel/irq.c:1139:register_irq_proc:
ERROR:NULL:1137:1139: Using unknown ptr "entry" illegally! set by
'create_proc_entry':1137
irq_dir[irq] = proc_mkdir(name, root_irq_dir);


/* create /proc/irq/1234/smp_affinity */
Start-->
entry = create_proc_entry("smp_affinity", 0600, irq_dir[irq]);
Error-->
entry->nlink = 1;
entry->data = (void *)(long)irq;
entry->read_proc = irq_affinity_read_proc;

Re: 64-bit block sizes on 32-bit systems

[Manfred Spraul]

From: "LA Walsh" <[EMAIL PROTECTED]>
> Manfred Spraul wrote:
> >
> > >4k page size * 2GB = 8TB.
> >
> > Try it.
> > If your drive (array) is larger than 512byte*4G (4TB) linux will eat
> > your data.
> ---
> I have a block device that doesn't use 'sectors'.  It
> only uses the logical block size (which is currently set for
> 1K).  Seems I could up that to the max blocksize (4k?) and
> get 8TB...No?
>
> I don't use the generic block make request (have my
> own).
>
Which field do you access? bh->b_blocknr instead of bh->r_sector?

There were plans to split the buffer_head into 2 structures: buffer
cache data and the block io data.
b_blocknr is buffer cache only, no driver should access them.

http://groups.google.com/groups?q=NeilBrown+io_head=en==off
num=1=928643305=1

--
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] OOM handling

[Kevin Buhr]

Jonathan Morton <[EMAIL PROTECTED]> writes:
>
> Understood - my Physics courses covered this as well, but not using the
> word "normalise".

Be that as it may, Martin's comments about normalizing are nonsense.
Rik's killer (at least in 2.4.3-pre7) produces a badness value that's
a product of badness factors of various units.  It then uses these
products only for relative comparisons, choosing the process with
maximum badness product to kill.  No normalization is necessary, nor
would it have any effect.

The reason a 256 Meg process on a 1 Gig machine was being killed had
nothing to do with normalization---it was a bug where the OOM killer
was being called long before we were reduced to last resorts.

Kevin <[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: 64-bit block sizes on 32-bit systems

[Jesse Pollard]

Martin Dalecki <[EMAIL PROTECTED]>:
> "Eric W. Biederman" wrote:
> > 
> > Matthew Wilcox <[EMAIL PROTECTED]> writes:
> > 
> > > On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
> > > > What do you mean by problems 5 years down the road?  The real issue is that
> > > > this 32-bit block count limit affects composite devices like MD RAID and
> > > > LVM today, not just individual disks.  There have been several postings
> > > > I have seen with people having a problem _today_ with a 2TB limit on
> > > > devices.
> > >
> > > people who can afford 2TB of disc can afford to buy a 64-bit processor.
> > 
> > Currently that doesn't solve the problem as block_nr is held in an int.
> > And as gcc compiles an int to a 32bit number on a 64bit processor, the
> > problem still isn't solved.
> > 
> > That at least we need to address.
> 
> And then you must face the fact that there may be the need for
> some of the shelf software, which isn't well supported on 
> correspondig 64 bit architectures... as well. So the
> arguemnt doesn't hold up to the reality in any way.

You are missing the point - I may need to use a 32 bit system to monitor
a large file system. I don't need the compute power of most 64 bit systems
to monitor user file activity.

> BTW. For many reasons 32 bit architecutres are in
> respoect of some application shemes *faster* the 64.

Which is why I want to use them with a 64 bit file system. Some of the
weather models run here have been known to exceed 100 GB data file. Yes
one  file. Most only need 20GB, but there are a couple of hundred of them...  

> Ultra III in 64 mode just crawls in comparision to 32.

Depends on what you are doing. If you need to handle large arrays of
floating point it is reasonable (not great, just reasonable).

> Alpha - unfortulatly an orphaned and dyring archtecutre... which
> is not well supported by sw verndors...

These are NOT the only 64 bit systems - Intel, PPC, IBM (in various guises).
If you need raw compute power, the Alpha is pretty good (we have over a
1000 in a Cray T3..).

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

Re: Larger dev_t

[John Byrne]

> Re: Larger dev_t
> 
On Sat Mar 24 2001 Linus Torvalds ([EMAIL PROTECTED]) wrote:
> There is no way in HELL I will ever accept a 64-bit dev_t.
> 
> I _will_ accept a 32-bit dev_t, with 12 bits for major numbers, and 20
> bits for minor numbers.
> 

Do you have any interest in doing away with the concept of major and
minor numbers altogether; turning the dev_t into an opaque unique id?

At the application level, the kinds of information that is derived from
the major/minor number should probably be derived in some other manner
such as a library or system call. Code that determines device type by
comparing with the major/minor numbers should probably be discouraged in
the long run and this could be a good time to start.

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

Re: Compiling problem kernel 2.4.2

[Tobias Ringstrom]

On Mon, 26 Mar 2001, Theodoor Scholte wrote:

> There are no relevant messsages in that file.

Strange, but I bet that you can compile again, right?  (Just remove the
broken compile.h that the dd command created)  Must have been an NFS
fluke, and without any more precise error messages, there is not much to
do, unless you can reproduce it.

/Tobias


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

Re: [kbuild-devel] Re: CML1 cleanup patch, take 3

[Eric S. Raymond]

John Cowan <[EMAIL PROTECTED]>:
> > If CML2 is adopted and I become the config system maimtainer,
>^
> Typo-ROTFL!

Of such errors are linguistic innovations made.  I wonder if this one
will propagate enough that I have to put it in the Jargon File? :-)
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

Our society won't be truly free until "None of the Above" is always an option.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kbuild-devel] Re: CML1 cleanup patch, take 3

[John Cowan]

Eric S. Raymond wrote:


> If CML2 is adopted and I become the config system maimtainer,
   ^
Typo-ROTFL!

-- 
There is / one art || John Cowan <[EMAIL PROTECTED]>
no more / no less  || http://www.reutershealth.com
to do / all things || http://www.ccil.org/~cowan
with art- / lessness   \\ -- Piet Hein

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

PCI lockup with multiple VGA cards

[Jordan Crouse]

Please CC back to me, as I am not subscribed to the list (but I soon
will be!)

I am writing a new framebuffer driver for a PCI based Chips and
Technologies 69000 HiQVideo chipset in the 2.4.2 code base on an i386
machine.  (They are custom cards, but they use the standard BIOS and
setup provided by the vendor).  One of the requirements is that I
provide support for multiple cards.  I am having no problems at all with
the first card.  It gets probed correctly, all the framebuffer and
register memory gets allocated and remapped fine, and eventually Tux
pops up on the screen.  

Now, when the second card is probed, it locates and ioremap()s the
framebuffer and registers correctly, and I can even read and write to
the MMIO mapped registers, but
when I try to access the framebuffer memory, the system locks up.  I
have a LED attached to the chip to show access, and it is lit indicating
that the problem occurred while the chip was being accessed.  I
eliminated the possibility of bad hardware by using both cards
individually without problems.  My best guess is that this may be a PCI
problem, but that's only a shot in the dark.  

Looking back in the archives, I saw several old references to the
possibility that multiple PCI VGA cards could lock up under certain
circumstances.  I am wondering if I am seeing these problems in action. 
I would definitely like some guidance from somebody who may have been
down this road before, and can provide much needed insight.

My general system setup is as follows:

I have a i386 machine (Pentium II) with nothing unusual attached (except
for the two custom CT69000 cards).  The kernel is 2.4.2-ac25 not running
SMP.  I switched the PCI mode to "direct" to avoid having the BIOS get
involved.  Plug and play is not enabled.  

The two cards are being setup identically, except that the "primary"
card (the one that the BIOS discovered and is using for text output),
has IO enabled, where as the 
second one does not (giving the second one IO access has no effect on
the problem).  PCI burst write is turned on, and both cards do not have
access to the BIOS ROM.  I have tried both remapping the memory as
cached and uncached, and I have also tried using MTRR, all with no
results.
 
Attached is the PCI probe function.  The lockup will occur sometime
between when I write to the memory and when I read it back (sometimes
the write succeeds, and sometimes it doesn't.  The read never works).  

If anyone has any other questions, or wants a copy of the driver, I will
be happy to oblige (it is still not quite ready for prime time, as one
can tell by my blatant lack of K indentation, but I am happy to
provide it to one and all).  Thank you all for your help.

Jordan



static int __init chips69000_probe(struct pci_dev *pdev, const struct
pci_device_id *dummy)
{
  int i;

  unsigned char *testaddr;

  unsigned long fb_size = (2 * 1024 * 1024);  /* 2 MB */  
  unsigned long blit_reg_size = 0x40;
  unsigned long blit_data_size = 0x2;
  unsigned long io_reg_size = 0xAF;

  unsigned long addr;

  u_int32_t cmd;
  u_int32_t val;

  u_int16_t wval;
  int bval;

  struct fb_info_chips *fbinfo;
  
  /* First of all, verify that the card is really ours */
  pci_read_config_word(pdev, 0x00, );

  if (wval != 0x102C) 
{
  printk(KERN_ERR "Card in slot %s is not a C device!\n",
pdev->name);
  return(-1);
}
  
  pci_read_config_word(pdev, 0x02, );
  
  if (wval != 0x00C0) 
{
  printk(KERN_ERR "Card in slot %s is not a C 69000 device!\n",
pdev->name);
  return(-1);
}

  printk(KERN_INFO "69000: Found a %s in slot %s\n", pdev->name,
pdev->slot_name);
  
  /* And try to enable to the device */
  if (pci_enable_device(pdev)) 
{
  printk(KERN_ERR "69000: Doh!  unable to enable the device\n");
  return(-1);
}

  /* Good to go.  Now, allocate new memory to hold the device info */
  fbinfo = (struct fb_info_chips *) kmalloc(sizeof(*fbinfo),
GFP_KERNEL);
  
  if (!fbinfo) 
{
  printk(KERN_ERR "69000:  Doh! Unable to access memory!\n");
  return(-1);
}

  memset(fbinfo, 0, sizeof(*fbinfo));
  
  /* Now set up enough info for the acutal driver to get moving */

  fbinfo->pcidev = pdev;
  pdev->driver_data = fbinfo;
   
  /* Get the address of resource 0 */
  addr = pci_resource_start(fbinfo->pcidev, 0);
   
  printk(KERN_INFO "69000:  Discovered %x bytes of memory at %x\n",
pci_resource_len(fbinfo->pcidev, 0),
addr);

  if (!request_mem_region(addr, pci_resource_len(fbinfo->pcidev, 0),
"chips69000 driver")) 
{
  printk(KERN_ERR "69000:  Unable to request the appropriate driver
memory at %x (size %x)\n",
 (unsigned long) addr, pci_resource_len(fbinfo->pcidev, 0));
  return(-1);
}
  
  printk(KERN_INFO "69000:  Successfully allocated %dK bytes of memory
at %x\n",
 pci_resource_len(fbinfo->pcidev, 0) / 1024, addr);

  /* Now start mapping those sections that we need */

  

Re: 64-bit block sizes on 32-bit systems

[Dan Hollis]

On Mon, 26 Mar 2001, Andreas Dilger wrote:
> Matthew Wilcox writes:
> > people who can afford 2TB of disc can afford to buy a 64-bit processor.
> This whole "64-bit" fallacy has got to stop.

Indeed.

> Now it is "anybody who needs > 2TB disk should use a 64-bit CPU", soon
> to be wrong.

It was already wrong in 1995.

-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: [PATCH] Prevent OOM from killing init

[Rik van Riel]

On 26 Mar 2001, James Antill wrote:

>  If you want overcommit great, and I think it's a valid default
> ... but it'd be nice if I could say I don't want it for apps that
> aren't written using glib etc.

Agreed.  Jonathan Morton seems to be making progress in testing
and debugging the non-overcommit patch from some time ago. If
things turn out to be trivial enough I wouldn't be surprised if
we got to see the option of non-overcommit somewhere in future
2.4 and 2.5 kernels...

regards,

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

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


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

Re: 64-bit block sizes on 32-bit systems

[Jes Sorensen]

> "Matthew" == Matthew Wilcox <[EMAIL PROTECTED]> writes:

Matthew> On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger
Matthew> wrote:
>> What do you mean by problems 5 years down the road?  The real issue
>> is that this 32-bit block count limit affects composite devices
>> like MD RAID and LVM today, not just individual disks.  There have
>> been several postings I have seen with people having a problem
>> _today_ with a 2TB limit on devices.

Matthew> people who can afford 2TB of disc can afford to buy a 64-bit
Matthew> processor.

Oh great, and migrating a large application to a new architecture is
soo cheap. Disk costs nothing these days and there is a legitimate
need here.

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

Re: CML1 cleanup patch, take 3

[Eric S. Raymond]

Jeff Garzik <[EMAIL PROTECTED]>:
> Wow, your script was longer than your patch :)

But independent of the version/patchlevel, which was the point of shipping it.

If CML2 is adopted and I become the config system maimtainer,
symbolreplace is one of a number of small tools I'll drop into the scripts
directory to address the namespace-management problem.  At over 1800
symbols, power tools are needed.  Even just garbage-collecting unused
symbols isn't trivial.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

"The power to tax involves the power to destroy;...the power to
destroy may defeat and render useless the power to create"
-- Chief Justice John Marshall, 1819.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML1 cleanup patch, take 3

[Jeff Garzik]

Wow, your script was longer than your patch :)

Patch looks ok to me...

-- 
Jeff Garzik   | May you have warm words on a cold evening,
Building 1024 | a full moon on a dark night,
MandrakeSoft  | and a smooth road all the way to your door.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 64-bit block sizes on 32-bit systems

[Martin Dalecki]

"Eric W. Biederman" wrote:
> 
> Matthew Wilcox <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
> > > What do you mean by problems 5 years down the road?  The real issue is that
> > > this 32-bit block count limit affects composite devices like MD RAID and
> > > LVM today, not just individual disks.  There have been several postings
> > > I have seen with people having a problem _today_ with a 2TB limit on
> > > devices.
> >
> > people who can afford 2TB of disc can afford to buy a 64-bit processor.
> 
> Currently that doesn't solve the problem as block_nr is held in an int.
> And as gcc compiles an int to a 32bit number on a 64bit processor, the
> problem still isn't solved.
> 
> That at least we need to address.

And then you must face the fact that there may be the need for
some of the shelf software, which isn't well supported on 
correspondig 64 bit architectures... as well. So the
arguemnt doesn't hold up to the reality in any way.
BTW. For many reasons 32 bit architecutres are in
respoect of some application shemes *faster* the 64.
Ultra III in 64 mode just crawls in comparision to 32.
Alpha - unfortulatly an orphaned and dyring archtecutre... which
is not well supported by sw verndors...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 64-bit block sizes on 32-bit systems

[LA Walsh]

Manfred Spraul wrote:
> 
> >4k page size * 2GB = 8TB.
> 
> Try it.
> If your drive (array) is larger than 512byte*4G (4TB) linux will eat
> your data.
---
I have a block device that doesn't use 'sectors'.  It
only uses the logical block size (which is currently set for
1K).  Seems I could up that to the max blocksize (4k?) and
get 8TB...No?

I don't use the generic block make request (have my
own).  

-- 
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CML1 cleanup patch, take 2

[Jeff Garzik]

Tom Rini wrote:
> On Mon, Mar 26, 2001 at 09:50:53AM -0500, Jeff Garzik wrote:
> > PPC guys:  this is a gratuitous renaming change that is not required.
> > If you have been following the "CML1 cleanup patch" thread, you see that
> > Eric is blindly dictating policy when he says that CONFIG_[0-9] needs to
> > be cleaned up.

> The counter point to this is what does "CONFIG_6xx" or 8xx mean?  It's as bad
> as CONFIG_Mxxx imho :)

No argument.. :)  I definitely encourage namespace cleanup in 2.5 -- but
please don't change an identifier just because it begins with a numeric
prefix...  Change it because it needs to be changed.

Best regards,

Jeff


-- 
Jeff Garzik   | May you have warm words on a cold evening,
Building 1024 | a full moon on a dark night,
MandrakeSoft  | and a smooth road all the way to your door.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.2,mount --bind, system hangs

[gabor]

Hi, 
linux 2.4.2 can be killed with multiple 'mount --bind ' -s.
The problem is reproduceable (at least on my system),
and works with User Mode Linux, too. Example script follows:

#!/bin/sh
OUTER=100
INNER=30
for j in `seq $OUTER`
do
for i in `seq $INNER`
do
   echo "$j:$i"
   touch $i $i.m
   mount --bind $i $i.m
done
done

The system usually hangs in the third iteration of the 
outer loop. No error messages, vt switching still works, network 
connections hang.
(Yes, the script looks cruel, however I ran into this problem
with a (broken) real-life setup that closely resembles this script with 
parameters OUTER=2 or 3 and INNER=19 )
The system is otherwise stable, no overclocking, etc...

System information: debian 2.2, with upgraded modutils, mount,
ppp, iptables; HW: AMD Athlon 550, MB: Asus K7V-RM, 128M RAM

Detailed stuff:

Kernel version:
Linux version 2.4.2 (root@tonhal) (gcc version 2.95.2 2220 \
(Debian GNU/Linux)) #5 Mon Feb 26 22:13:40 CET 2001

output of scripts/ver_linux:
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux tonhal 2.4.2 #5 Mon Feb 26 22:13:40 CET 2001 i686 unknown
Kernel modules 2.4.1
Gnu C  2.95.2
Gnu Make   3.79.1
Binutils   2.9.5.0.37
Linux C Library2.1.3
Dynamic linker ldd: version 1.9.11
Procps 2.0.6
Mount  2.11a
Net-tools  2.05
Console-tools  0.2.3
Sh-utils   2.0
Modules Loaded ipt_state ipt_MASQUERADE iptable_filter \
ip_conntrack_ftp iptable_nat ip_conntrack ip_tables ppp_deflate \
bsd_comp ppp_async ppp_generic slhc via-rhine serial via82cxxx_audio \
ac97_codec soundcore w83781d sensors i2c-viapro i2c-core

Third party modules: lm_sensors-2.5.4, i2c-2.5.4 

Basic cpu and pci information:

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 1
model name  : AMD-K7(tm) Processor
stepping: 2
cpu MHz : 550.029
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat mmx 
syscall mmxext 3dnowext 3dnow
bogomips: 1097.72
-
00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:04.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super 
AC97/Audio] (rev 20)
00:09.0 Ethernet controller: VIA Technologies, Inc.: Unknown device 3065 (rev 42)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04)
-
I can give more information on request.


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

Re: 64-bit block sizes on 32-bit systems

[Rik van Riel]

On Mon, 26 Mar 2001, Matthew Wilcox wrote:

> people who can afford 2TB of disc can afford to buy a 64-bit processor.

You realise that this'll double the price of storage?  ;)

(at least, in a year or two)

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

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

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

Re: [kbuild-devel] CML1 cleanup patch, take 3

[Michael Elizabeth Chastain]

Eric Raymond writes:
> Bjorn Wesen <[EMAIL PROTECTED]> informs me that the CRIS symbol bugs
> will be fixed in the next CRIS port update.

Hey, there's even a spec which says that config symbols have to look
like CONFIG_*:

  # Documentation/kbuild/config-language.txt
  A /symbol/ is a single unquoted word.  A symbol must have a name of
  the form CONFIG_*.  scripts/mkdep.c relies on this convention in order
  to generate dependencies on individual CONFIG_* symbols instead of
  making one massive dependency on include/linux/autoconf.h.

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

hooking APIC timer doesnt work?

[Dinesh Nagpure]

Hello all,
I am trying to use the LAPIC timer to generate interrupt for some kernel 
profiling work I am doing...but the timer ISR isnt invoking atallhere is 
what I have done
1)Initialized a interrupt gate  modifying the trap_init function in traps.c 
to use vector 0x32
set_intr_gate(0x32,);

2) Added a handler in entry.s

ENTRY(inthtooltimer)
pushl %eax
SAVE_ALL
movl %esp,%edx
pushl $0
pushl %edx
call SYMBOL_NAME(do_inthtooltimer)
addl $8,%esp
RESTORE_ALL

3) Added a high level C function do_inthtooltimer in traps.c with all proper 
asmlinkage declerations and all

4) In my driver module I initialize the LAPIC timer register for
ONE_SHOT, NOT_MASKED, VECTOR32 and SEND_PENDING as given in the intel 
architecture manual and also set the divide config register to divide by 
1and the initial count register is also set...

Problem is my timer handler isnt getting called atall...

I am disabling the SMP support and APIC support options in menuconfig

I assume rest of the APIC initialization is done properly because I am 
instrumenting the APIC Performance Counter interrupt also for delivery mode 
NMI and it seems to be getting called properly as I see /proc/interrupts 
showing increment in NMI count..

Am i missing out something...
Thanks
Dinesh
_
Get your FREE download of MSN Explorer at http://explorer.msn.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: 64-bit block sizes on 32-bit systems

[Jesse Pollard]

-  Received message begins Here  -

> 
> On Mon, Mar 26, 2001 at 08:39:21AM -0800, LA Walsh wrote:
> > I vaguely remember a discussion about this a few months back.
> > If I remember, the reasoning was it would unnecessarily slow
> > down smaller systems that would never have block devices in
> > the 4-28T range attached.  
> 
> 4k page size * 2GB = 8TB.
> 
> i consider it much more likely on such systems that the page size will
> be increased to maybe 16 or 64k which would give us 32TB or 128TB.
> you keep on trying to increase the size of types without looking at
> what gcc outputs in the way of code that manipulates 64-bit types.
> seriously, why don't you just try it?  see what the performance is.
> see what the code size is.  then come back with some numbers.  and i mean
> numbers, not `it doesn't feel any slower'.
> 
> personally, i'm going to see what the situation looks like in 5 years time
> and try to solve the problem then.  there're enough real problems with the
> VFS today that i don't feel inclined to fix tomorrow's potential problems.

I don't feel that it is that far away ... IBM has already released a 64 CPU
intel based system (NUMA). We already have systems in that class (though
64 bit based) that use 5 TB file systems. The need is coming, and appears
to be coming fast. It should be resolved during the improvements to the
VFS.

A second reason to include it in the VFS is that the low level filesystem
implementation would NOT be required to use it. If the administrator
CHOOSES to access a 16TB filesystem from a workstation, then it should
be possible (likely something like the GFS, where the administrator is
just monitoring things, would be reasonable for a 32 bit system to do).

As I see it, the VFS itself doesn't really care what the block size is,
it just carries relatively opaque values that the filesystem implementation
uses. Most of the overhead should just be copying an extra 4 bytes around.

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

CML1 cleanup patch, take 3

[Eric S. Raymond]

Progress is being made.  I submitted a cleanup patch in order to get rid
of three headaches before the 2.5 fork.  Three good things have since
happened since:

(1) Bjorn Wesen <[EMAIL PROTECTED]> informs me that the CRIS symbol bugs
will be fixed in the next CRIS port update.  This will get rid of the
single worst problem I was looking at.  (Somebody else pointed out that
the present symbol names are invisible to `make dep'.)

(2) Greg Banks and Rik van Riel pointed out (separately) that I was too close 
to the namespace problem; with a two-line change to my compiler I don't
need to get numeric-prefix symbols cleaned up yet.  I think it's still
a good  idea for the longer term, however, and a couple of the people
who own those symbols have already endorsed changing them.

(3) The CONFIG_AIC7XXX_TAGGED_QUEUEING to CONFIG_AIC7XXX_TCQ_ON_BY_DEFAULT
change that was on my buglist seems to have come out in the wash in the
pre8 patch.

All that's left for me to do at this point, therefore, is fix the
PRINTER_READBACK glitch.  I will do my analysis tools on the assumption
that the CRIS symbols are going to be fixed.

This file is a patch expressed in two ways.  First, procedurally, as a
way to duplicate its effects on any kernel source tree.  Secondly, as
an explicit patch against 2.4.3-pre8.  It replaces my previous patches
against 2.4.3-pre6 and 2.4.3-pre8.

No actual object code will be changed by this patch.

For the procedural form, you will require the following Python 2.0 script
(note that this script has added anoption since my pre8 patch.):

 SCRIPT BEGINS HERE ---
#!/usr/bin/env python
#
# symbolreplace -- replace symbols in the current Linux source tree

import sys, os, re, getopt

renamings = {}  # Dictionary of translations
dobackup = 1
verbose = 0

#
# This is the only bit of knowledge in this script that knows anything
# about the lexical rules of the symbols we're looking for.  It's used as a
# guard expression on either side of each old symbol name -- matches
# must begin either with this guard or with a beginning-of-line, and end
# either with this guard or an end-of-line.  The purpose is to prevent false
# matches on FOO in FOOBAR and BARFOO.
#
guard = "[^A-Za-z0-9_]"

def backup(file):
"Create a backup for the given file."
# Compute where the RCS directory for this file should live.
# Create it if necessary.
rcs_dir = os.path.join(os.path.dirname(file), "RCS")
if not os.path.exists(rcs_dir):
os.mkdir(rcs_dir)

# If there is no RCS master corresponding to the file, create one,
rcs_file = os.path.join(rcs_dir, os.path.basename(file) + ",v")
if not os.path.exists(rcs_file):
os.system("ci -u -t- " + file + " >/dev/null 2>&1")

# Check out a working copy if needed.
if not os.access(file, os.W_OK):
os.system("co -l " + file + " >/dev/null 2>&1")

def treevisit(root, visitor):
"Apply the visitor function to every file under the given root path."
def treewalker(hook, dirname, files):
for file in files:
here = os.path.join(dirname, file)
if os.path.isfile(here) and here.find("RCS") == -1:
hook(here)
os.path.walk(root, treewalker, visitor)

def replacer(file):
if verbose:
print file

# Suck the entire file into core as a list of lines.
ifp = open(file, "r")
contents = ifp.read()
ifp.close()

# Now perform the substitution on each line.
substitutions = 0
for pattern in renamings.keys():
new_contents = pattern.sub(r"\1"+renamings[pattern]+r"\2", contents)
if new_contents != contents:
substitutions = substitutions + 1
contents = new_contents

# Spew the results.
if substitutions:
if dobackup:
backup(file)
ofp = open(file, "w")
ofp.write(contents)
ofp.close()

def guardify(old):
"Turn the given symbol into a properly guarded regexp."
return re.compile("(^|" + guard +")" + old + "(" + guard + "|$)")

def read_translations(fp):
"Read translation requests from the given file object, ignoring comments."
while 1:
line = fp.readline()
if not line:
break
elif line[0] == '#' or line[0] == '\n':
continue
else:
(old, new) = line.split()
renamings[guardify(old)] = new

# Main sequence

if __name__ == '__main__': 
# Main sequence

# Process options
(options, arguments) = getopt.getopt(sys.argv[1:], "d:ns:v")
topdir = "."
for (switch, val) in options:
if (switch == '-d'):# Location of source tree if not .
topdir = val
elif (switch == '-n'):  # Suppress backups
dobackup = 0
elif (switch == '-s'):  # Do old:new substitution
(old, new) = val.split(":")

Re: ACPI power-off doesn't work on Asus CUV4X (VIA Apollo 133)

[Alex Riesen]

On Mon, Mar 26, 2001 at 10:35:33AM -0800, Grover, Andrew wrote:
> > > > As i recompiled 2.4.2-ac20 with ACPI support
> > > > the system cannot switch itself off.
> > > > I get a message "Couldn't switch to S5" if
> > > > At load it shows that the mode is supported.
> > > 
> > > Same with AMR P6BAP-AP and P6VAP-AP () mainboards.
> 
> > > #define APCI_DEBUG 1 has NO effect on verbosity of messages :-(
> 
> The ACPI version in the kernel has debug messages stripped, for historical
> reasons. There is a non-stripped version available at
> http://developer.intel.com/technology/iapc/acpi/downloads.htm but this also
...
> 
> Either try the version on the website, or make this change and see if it
> helps:
> 
>   drivers/acpi/hardware/hwsleep.c (at the bottom) :
> 
>   acpi_hw_register_write(ACPI_MTX_LOCK, PM1_a_CONTROL, PM1_acontrol);
>   acpi_hw_register_write(ACPI_MTX_LOCK, PM1_b_CONTROL, PM1_bcontrol);
>   acpi_hw_register_write(ACPI_MTX_LOCK, PM1_CONTROL, <-- remove
> these
>   (1 << acpi_hw_get_bit_shift (SLP_EN_MASK))); <--

Didn't help for me. Exactly the same result.
I think about to try the driver from above...

Some details (from bios boot screen):

Award Medallion BIOS v6.0
ASUS CUV4X ACPI BIOS Revision 1006

bottom line:
07/25/2000-VT6942-CUV4X

Cannot tell whether ASUS have update for this BIOS,
because it looks that i dont get their page loaded in next 100 years
with the damned slow link i have. This may be the reason i'll
not try the original driver, too :-(


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


/proc/pci:
PCI devices found:
  Bus  0, device   0, function  0:
Host bridge: VIA Technologies, Inc. VT8605 [ProSavage PM133] (rev 129).
  Prefetchable 32 bit memory at 0xf800 [0xfbff].
  Bus  0, device   1, function  0:
PCI bridge: VIA Technologies, Inc. VT8605 [PM133 AGP] (rev 0).
  Master Capable.  No bursts.  Min Gnt=8.
  Bus  0, device   4, function  0:
ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 34).
  Bus  0, device   4, function  1:
IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 16).
  Master Capable.  Latency=32.  
  I/O at 0xd800 [0xd80f].
  Bus  0, device   4, function  2:
USB Controller: VIA Technologies, Inc. UHCI USB (rev 16).
  IRQ 10.
  Master Capable.  Latency=32.  
  I/O at 0xd400 [0xd41f].
  Bus  0, device   4, function  3:
USB Controller: VIA Technologies, Inc. UHCI USB (#2) (rev 16).
  IRQ 10.
  Master Capable.  Latency=32.  
  I/O at 0xd000 [0xd01f].
  Bus  0, device   4, function  4:
Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 48).
  Bus  0, device  15, function  0:
Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 6).
  IRQ 10.
  Master Capable.  Latency=64.  Min Gnt=12.Max Lat=128.
  I/O at 0xb800 [0xb83f].
  Bus  0, device  17, function  0:
Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 65).
  IRQ 11.
  Master Capable.  Latency=32.  Min Gnt=20.Max Lat=40.
  I/O at 0xb400 [0xb47f].
  Non-prefetchable 32 bit memory at 0xed80 [0xed8003ff].
  Bus  1, device   0, function  0:
VGA compatible controller: nVidia Corporation GeForce 256 (rev 16).
  IRQ 11.
  Master Capable.  Latency=64.  Min Gnt=5.Max Lat=1.
  Non-prefetchable 32 bit memory at 0xee00 [0xeeff].
  Prefetchable 32 bit memory at 0xf000 [0xf7ff].



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

Re: Linux Worm (fwd)

[Ben Ford]

What company was it that you worked for?  I'm sure we could convince 
them otherwise . . . .

-b


Gregory Maxwell wrote:

> On Mon, Mar 26, 2001 at 10:07:22AM -0500, Richard B. Johnson wrote:
> [snip]
> 
>> I have just received notice that my machines will no longer be
>> provided access to "The Internet".
>> 
>> "Effective on or before 16:00:00 local time, the only personal
>> computers that will be allowed Internet access are those administered
>> by a Microsoft Certified Network Administrator. This means that
>> no Unix or Linux machines will be provided access beyond the local
>> area network. If you require Internet access, the company will
>> provide a PC which runs a secure operating system such as Microsoft
>> Windows, or Windows/NT. Insecure operating systems like Linux must
>> be removed from company owned computers before the end of this week."
> 
> 
> You've demonstrated over and over again that you work for a constantly
> stupid company. 
> 
> Please find someplace else to work, your issues have become more depressing
> then amusing. :)
> 
> It's sad that people like the one who sent out messages like that can stay
> employed. In the last year there have been several Windows love-bug type
> worms each causing damaged estimated in the billions. One or two Linux worms
> that go after a long fixed problem with no published accounts of significant
> damage and you get that sort of email..
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: Lovely crash with 2.4.2-ac24.

[Zephaniah E\. Hull]

On Mon, Mar 26, 2001 at 10:31:17AM -0800, Andre Hedrick wrote:
> On Mon, 26 Mar 2001, Zephaniah E. Hull wrote:
> 
> > On Mon, Mar 26, 2001 at 09:46:54AM -0800, Andre Hedrick wrote:
> > > 
> > > Zephaniah,
> > > 
> > > Does this happen in a non-ac kernel?
> > > I have not updated code since around 2.4.0, but other have.
> > > You point ot a few times w/ ac18, but is there one before that which does
> > > not cause this to happen?
> > > 
> > > The question is to gain isolation of the changes.
> > 
> > I'm not sure, I did not see it on 2.4.2-ac18 until I started doing a lot
> > of X compiling, but I can't reproduce at will which makes this a little
> > harder.
> > 
> > I could try 2.4.2 the current 2.4.3-pre kernels from Linus if that would
> > help? (Though, as I said, it seems to happen semi-randomly, though more
> > when there is heavy disk activity.)
> 
> But hardware class and vender?

K6-2 500, the MB is a Super 7, Tyan S1590S-100.

It is a VIA Apollo 3 (MVP3) AGPset chipset, only goes up to DMA/33.

The drive is a 10G Western Digital, output from the kernel on boot up below.

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c586b (rev 47) IDE UDMA33 controller on pci00:07.1
ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
hda: WDC WD102AA, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 20044080 sectors (10263 MB) w/2048KiB Cache, CHS=1247/255/63, UDMA(33)

If I've left anything out just ask.

Zephaniah E. Hull.


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

-- 
 PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801
Keys available at http://whitestar.soark.net/~warp/public_keys.
   CCs of replies from mailing lists are encouraged.

Having been the victim of forgeries myself, I sympathise. I've still got
my nutcraker handy for the day I identify and catch the scum...
  -- Richard Gooch on l-k.

 PGP signature

Re: Compiling problem kernel 2.4.2

[Theodoor Scholte]

>And you always get exactly this message?  What happens if you run
> cat /usr/src/linux/include/linux/compile.h

This is the output of cat /usr/src/linux/include/linux/compile.h :
#define UTS_VERSION "#1 SMP Sun Mar 25 21:51:51 CEST 2001"
#define LINUX_COMPILE_TIME "21:51:51"
#define LINUX_COMPILE_BY "root"
#define LINUX_COMPILE_HOST "server"
#define LINUX_COMPILE_DOMAIN "scholte.nl"
#define LINUX_COMPILER "gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 
release)"


> dd if=/dev/zero of=/usr/src/linux/include/linux/compile.h count=10

This is the output of dd if=/dev/zero 
of=/usr/src/linux/include/linux/compile.h count=10 :
10+0 records in
10+0 records out

>Have you checked /var/log/messages (or dmesg) for relevant messages?

There are no relevant messsages in that file.

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

Re: Linux Worm (fwd)

[Stephen Satchell]

At 10:24 AM 3/26/01 -0500, you wrote:
>It's sad that people like the one who sent out messages like that can stay
>employed. In the last year there have been several Windows love-bug type
>worms each causing damaged estimated in the billions. One or two Linux worms
>that go after a long fixed problem with no published accounts of significant
>damage and you get that sort of email..

What is even sadder is that, for loser companies like the one cited, there 
is a series of Linux certification programs (not distribution-dependent) 
under development at CompTIA (the Computing Technology Industry Association).

Satch

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

Re: 64-bit block sizes on 32-bit systems

[Eric W. Biederman]

Matthew Wilcox <[EMAIL PROTECTED]> writes:

> On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
> > What do you mean by problems 5 years down the road?  The real issue is that
> > this 32-bit block count limit affects composite devices like MD RAID and
> > LVM today, not just individual disks.  There have been several postings
> > I have seen with people having a problem _today_ with a 2TB limit on
> > devices.
> 
> people who can afford 2TB of disc can afford to buy a 64-bit processor.

Currently that doesn't solve the problem as block_nr is held in an int.
And as gcc compiles an int to a 32bit number on a 64bit processor, the
problem still isn't solved.

That at least we need to address.

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

RE: ACPI power-off doesn't work on Asus CUV4X (VIA Apollo 133)

[Grover, Andrew]

> From: Ingo Oeser [mailto:[EMAIL PROTECTED]]
> > > As i recompiled 2.4.2-ac20 with ACPI support
> > > the system cannot switch itself off.
> > > I get a message "Couldn't switch to S5" if
> > > try to call reboot(2).
> > > At load it shows that the mode is supported.
> > 
> > Same with AMR P6BAP-AP and P6VAP-AP () mainboards.

> > #define APCI_DEBUG 1 has NO effect on verbosity of messages :-(

The ACPI version in the kernel has debug messages stripped, for historical
reasons. There is a non-stripped version available at
http://developer.intel.com/technology/iapc/acpi/downloads.htm but this also
includes other new code, which may or may not be what you want.

> The BIG Problem is: This is an embedded machine, so I cannot
> attach all the funny debug tools. The most thing I can do is
> printk and evtl. ikdb. I have only 16MB flash disk on this
> machine and it is full already :-(

Either try the version on the website, or make this change and see if it
helps:

drivers/acpi/hardware/hwsleep.c (at the bottom) :

acpi_hw_register_write(ACPI_MTX_LOCK, PM1_a_CONTROL, PM1_acontrol);
acpi_hw_register_write(ACPI_MTX_LOCK, PM1_b_CONTROL, PM1_bcontrol);
acpi_hw_register_write(ACPI_MTX_LOCK, PM1_CONTROL, <-- remove
these
(1 << acpi_hw_get_bit_shift (SLP_EN_MASK))); <--


Regards -- Andy

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

IDE bug?

[SteveC]

I was sent this after my IDE got trashed using 2.4.2

?> PS for people using a hard disk with a LART: Upgrade to
>>   linux-2.4.2-rmk1-np2 as soon as possible. Earlier kernels had a nasty
>>   IDE bug that could destroy your filesystem. That happened to me...
>dude, maybe this is what fscked up your fs.

but I can't find reference to said bug - pointers appreciated

have fun,

SteveC [EMAIL PROTECTED] fractalus.com/steve [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: Lovely crash with 2.4.2-ac24.

[Andre Hedrick]

On Mon, 26 Mar 2001, Zephaniah E. Hull wrote:

> On Mon, Mar 26, 2001 at 09:46:54AM -0800, Andre Hedrick wrote:
> > 
> > Zephaniah,
> > 
> > Does this happen in a non-ac kernel?
> > I have not updated code since around 2.4.0, but other have.
> > You point ot a few times w/ ac18, but is there one before that which does
> > not cause this to happen?
> > 
> > The question is to gain isolation of the changes.
> 
> I'm not sure, I did not see it on 2.4.2-ac18 until I started doing a lot
> of X compiling, but I can't reproduce at will which makes this a little
> harder.
> 
> I could try 2.4.2 the current 2.4.3-pre kernels from Linus if that would
> help? (Though, as I said, it seems to happen semi-randomly, though more
> when there is heavy disk activity.)

But hardware class and vender?

> 
> Zephaniah E. Hull.
> > 
> > On Mon, 26 Mar 2001, Zephaniah E. Hull wrote:
> > 
> > > This had hit me a few times with ac18 (I'm not sure it was the same
> > > crash though) and just hit me again with ac24.
> > > 
> > > Alan cced due to it being in the ac kernels, Andre because the trace
> > > seems to point to the IDE code.
> > > 
> > > Thanks.
> > > 
> > > Zephaniah E. Hull.
> > > 
> > > -- 
> > >  PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801
> > > Keys available at http://whitestar.soark.net/~warp/public_keys.
> > >CCs of replies from mailing lists are encouraged.
> > > 
> > >  Mercury: gpm isn't a very good web browser.  fix it.
> > > 
> > 
> > Andre Hedrick
> > Linux ATA Development
> > ASL Kernel Development
> > -
> > ASL, Inc. Toll free: 1-877-ASL-3535
> > 1757 Houret Court Fax: 1-408-941-2071
> > Milpitas, CA 95035Web: www.aslab.com
> > 
> 
> -- 
>  PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801
> Keys available at http://whitestar.soark.net/~warp/public_keys.
>CCs of replies from mailing lists are encouraged.
> 
> "Delivery anywhere in the world within thirty minutes or the second one's
>  free." - "pizza box" art atop a Minuteman ICBM silo, Paul A. Suhler, RHF
> 

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

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

2.4.2-ac25 error: Malformed setting 'kernel.printk' after cs46xx load/unload

[Steven Cole]

I got an error message on bootup and shutdown of 2.4.2-ac25 just after
loading and unloading the cs46xx module.  The error was not logged
to /var/log/messages, but I copied it from the screen.

On boot:

Loading sound module (cs46xx)
Loading mixer settings:
error: Malformed setting 'kernel.printk='

On shutdown:

Saving mixer settings:
Unloading sound module (cs46xx)
error: Malformed setting 'kernel.printk='

This is the first time I've seen this message.
It does not occur with -ac20 or earlier.

The sound still works just fine with 2.4.2-ac25. :)

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

2.2.19 toshiba module fix

[Greg KH]

The following patch enables the toshiba module to compile correctly on
2.2.19.

thanks,

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg


diff -Naur -X /home/greg/linux/dontdiff linux-2.2.19/drivers/char/toshiba.c 
linux-2.2.19-greg/drivers/char/toshiba.c
--- linux-2.2.19/drivers/char/toshiba.c Sun Mar 25 09:45:19 2001
+++ linux-2.2.19-greg/drivers/char/toshiba.cMon Mar 26 09:19:08 2001
@@ -78,7 +78,7 @@
 #include
 #endif
 
-#include"toshiba.h"
+#include
 
 #define TOSH_MINOR_DEV 181
 

Re: 64-bit block sizes on 32-bit systems

[Matthew Wilcox]

On Mon, Mar 26, 2001 at 08:01:21PM +0200, Manfred Spraul wrote:
> drivers/block/ll_rw_blk.c, in submit_bh()
> >bh->b_rsector = bh->b_blocknr * (bh->b_size >> 9);
> 
> But it shouldn't cause data corruptions:
> It was discussed a few months ago, and iirc LVM refuses to create too
> large volumes.

Ah yes, I'd forgotten the block layer still works in terms of 512-byte blocks.

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

Re: Adaptec Array1000

[Roberto Fichera]

At 10.51 26/03/01 -0700, Justin T. Gibbs wrote:

> >Hi all,
> >
> >Does anyone know how to configure this controller (chipset AAA-133U2
> >aka AIC-78xx) with one RAID5 hardware volume ? The kernel 2.2.16 see
> >all the disks (4x18Gb) but don't see the unique volume.
>
>These boards are not currently supported in RAID mode.  Your
>best bet is Linux MD.

Ok! As I was thinking, I must configure it with Linux MD.

Thanks.


Roberto Fichera.

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

Re: paride error, aparantly with VFS

[Tim Waugh]

On Sun, Mar 25, 2001 at 09:37:38PM -0800, [EMAIL PROTECTED] wrote:

> do_pd_read_drq: status = 0x10050 = SEEK READY TMO

Please try a recent -ac kernel and let me know if the problem persists
or goes away.

Tim.
*/

 PGP signature

Re: 64-bit block sizes on 32-bit systems

[Matthew Wilcox]

On Mon, Mar 26, 2001 at 10:47:13AM -0700, Andreas Dilger wrote:
> What do you mean by problems 5 years down the road?  The real issue is that
> this 32-bit block count limit affects composite devices like MD RAID and
> LVM today, not just individual disks.  There have been several postings
> I have seen with people having a problem _today_ with a 2TB limit on
> devices.

people who can afford 2TB of disc can afford to buy a 64-bit processor.

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

Re: 64-bit block sizes on 32-bit systems

[Manfred Spraul]

>> I vaguely remember a discussion about this a few months back.
>> If I remember, the reasoning was it would unnecessarily slow
>> down smaller systems that would never have block devices in
>> the 4-28T range attached.
>
>4k page size * 2GB = 8TB.

Try it.
If your drive (array) is larger than 512byte*4G (4TB) linux will eat
your data.

drivers/block/ll_rw_blk.c, in submit_bh()
>bh->b_rsector = bh->b_blocknr * (bh->b_size >> 9);

But it shouldn't cause data corruptions:
It was discussed a few months ago, and iirc LVM refuses to create too
large volumes.

--
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: 2.4.2 fs/inode.c

[Chris Mason]

On Thursday, March 22, 2001 01:42:15 PM -0500 Jan Harkes
<[EMAIL PROTECTED]> wrote:

> 
> I found some code that seems wrong and didn't even match it's comment.
> Patch is against 2.4.2, but should go cleanly against 2.4.3-pre6 as well.
> 

Ok, this looks correct, makes reiserfs faster, and survived under load.  The
idea was to only call dirty_inode if sync_one might decide the inode needs
flushing to disk.  So, the check in __mark_inode_dirty should look the same
as the check in sync_one.

> --- linux/fs/inode.c.orig Thu Mar 22 13:20:55 2001
> +++ linux/fs/inode.c  Thu Mar 22 13:21:32 2001
> @@ -133,7 +133,7 @@
>  
>if (sb) {
>/* Don't do this for I_DIRTY_PAGES - that doesn't actually dirty the
>inode itself */ 
> - if (flags & (I_DIRTY | I_DIRTY_SYNC)) {
> + if (flags & (I_DIRTY_SYNC | I_DIRTY_DATASYNC)) {
>if (sb->s_op && sb->s_op->dirty_inode)
>sb->s_op->dirty_inode(inode);
>}
> -

-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: 64-bit block sizes on 32-bit systems

[Eric W. Biederman]

LA Walsh <[EMAIL PROTECTED]> writes:

> I vaguely remember a discussion about this a few months back.
> If I remember, the reasoning was it would unnecessarily slow
> down smaller systems that would never have block devices in
> the 4-28T range attached.  

With classic 512 byte sectors the top size is right about 2TB.

The basic thought is that 64bit numbers tend to suck, so we don't
want then in any fast paths on a 32bit system.

> However, isn't it possible there will continue to be a series
> of P-IV,V,VI,VII ...etc, addons that will be used for sometime
> to come.  I've even heard it suggested that we might see
> 2 or more CPU's on a single chip as a way to increase cpu
> capacity w/o driving up clock speed.  Given the cheapness of
> .25T drives now, seeing the possibility of 4T drives doesn't seem
> that remote (maybe 5 years?).  
> 
> Side question: does the 32-bit block size limit also apply to 
> RAID disks or does it use a different block-nr type?
For now yes it does.

> 
> So...is it the plan, or has it been though about -- 'abstracting'
> block numbes as a typedef 'block_nr', then at compile time
> having it be selectable as to whether or not this was to
> be a 32-bit or 64 bit quantity -- that way older systems would
> lose no efficiency.  Drivers that couldn't be or hadn't been
> ported to use 'block_nr' could default to being disabled if
> 64-bit blocks were selected, etc.
> 
> So has this idea been tossed about and or previously thrashed?

Using a 64bit number of 32bit systems has so far been trashed.
Though this does look like a real problem that needs to be solved
at some point.  I doubt we can wait past 2.5 though if we want the
code ready when the hardware is.

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

Re: NCR53c8xx driver and multiple controllers...(not new prob)

[Gérard Roudier]

On Sun, 25 Mar 2001, LA Walsh wrote:

> Here is the 'alternate' output when the ncr53c8xx driver is
> compiled in:
> 
> SCSI subsystem driver Revision: 1.00
> scsi-ncr53c7,8xx : at PCI bus 0, device 8, function 0
> scsi-ncr53c7,8xx : warning : revision of 35 is greater than 2.
> scsi-ncr53c7,8xx : NCR53c810 at memory 0xfa101000, io 0x2000, irq 58
> scsi0 : burst length 16
> scsi0 : NCR code relocated to 0x37d6c610 (virt 0xf7d6c610)
> scsi0 : test 1 started
> scsi0 : NCR53c{7,8}xx (rel 17)
> request_module[block-major-8]: Root fs not mounted
> VFS: Cannot open root device "807" or 08:07
> Please append a correct "root=" boot option
> Kernel panic: VFS: Unable to mount root fs on 08:07
> -

The 53c7,8xx driver is a different driver that hasn't been updated for the
support of the 53C896. I figure out that you already have been replied
upon this point.

For your machine configuration you want to use either the NCR53C8XX driver
or the SYM53C8XX driver. The SYM53C8XX driver has a better support for the
896 as it handles phase mismatch from SCRIPTS. The both drivers share the
same kernel config options for simplicity (in fact the SYM53C8XX driver
just steals the NCR53C8XX config options).

Go to the SCSI low-level configuration form under make menuconfig for
example and configure the SYM53C8XX driver as 'Y' and the NCR53C8XX driver
as 'N'. Btw, also configure 'N' the 53c7,8xx driver to avoid conflicts.

You may also have a look at the help entries for these drivers and at the 
file linux/drivers/scsi/README.ncr53c8xx (also applies to SYM53C8XX).

A driver named SYM-2 that replaces both the NCR53C8XX and the SYM53C8XX
drivers also exists. This driver is multi-platform and for now has been 
added support for Linux, FreeBSD and NetBSD. It is intended to replace the
NCR53C8XX and the SYM53C8XX. It is not included in Linux for now since we
only have _stable_ kernels at the moment and the NCR+SYM driver pair is
the current _stable_ support for SYMBIOS 53C8XX controllers. 
If you want to try SYM-2: ftp://ftp.tux.org/roudier/README-drivers-linux

  Gérard.

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

Re: [kbuild-devel] Re: CML1 cleanup patch

[Eric S. Raymond]

Rik van Riel <[EMAIL PROTECTED]>:
> What's wrong with using the _file type_ for these things ?

I don't understand that.
 
> Conversely, why can't CML2 use the CONFIG_ prefix to
> determine if a symbol is a configuration option, like
> we're doing now?

I do understand this.  Greg Banks pointed it out last night, and I'm
testing a CML2 version that implements it now.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

The two pillars of `political correctness' are, 
  a) willful ignorance, and
  b) a steadfast refusal to face the truth
-- George MacDonald Fraser
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Adaptec Array1000

[Justin T. Gibbs]

>Hi all,
>
>Does anyone know how to configure this controller (chipset AAA-133U2
>aka AIC-78xx) with one RAID5 hardware volume ? The kernel 2.2.16 see
>all the disks (4x18Gb) but don't see the unique volume.

These boards are not currently supported in RAID mode.  Your
best bet is Linux MD.

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

Re: 64-bit block sizes on 32-bit systems

[LA Walsh]

Matthew Wilcox wrote:
> 
> On Mon, Mar 26, 2001 at 08:39:21AM -0800, LA Walsh wrote:
> > I vaguely remember a discussion about this a few months back.
> > If I remember, the reasoning was it would unnecessarily slow
> > down smaller systems that would never have block devices in
> > the 4-28T range attached.
> 
> 4k page size * 2GB = 8TB.
---
Drat...was being more optimistic -- you're right
the block_nr can be negative.  Somehow thought page size could
be 8Kliving in future land.  That just makes the limitations
even closer at hand...:-(

> you keep on trying to increase the size of types without looking at
> what gcc outputs in the way of code that manipulates 64-bit types.
---
Maybe someone will backport some of the features of the
IA-64 code generator into 'gcc'.  I've been told that in some 
cases it's a 2.5x performance difference.  If 'gcc' is generating
bad code, then maybe the 'gcc' people will increase the quality
of their code -- I'm sure they are just as eagerly working on
gcc improvements as we are kernel improvements.  When I worked
on the PL/M compiler project at Intel, I know our code-optimization
guy would spend endless cycles trying to get better optimization
out of the code.  He got great joy out of doing so. -- and
that was almost 20 years ago -- and code generation has come
a *long* way since then.

> seriously, why don't you just try it?  see what the performance is.
> see what the code size is.  then come back with some numbers.  and i mean
> numbers, not `it doesn't feel any slower'.
---
As for 'trying' it -- would anyone care if we virtualized
the block_nr into a typedef?  That seems like it would provide
for cleaner (type-checked) code at no performance penalty and
more easily allow such comparisons.

Well this is my point: if I have disks > 8T, wouldn't
it be at *all* beneficial to be able to *choose* some slight
performance impact and access those large disks vs. having not
choice?  Having it as a configurable would allow a given 
installation to make that choice rather than them having no
choice.  BTW, are block_nr's on RAID arrays subject to this
limitation?
> 
> personally, i'm going to see what the situation looks like in 5 years time
> and try to solve the problem then.
---
It's not the same, but SGI has had customers for over
3 years using >2T *files*.  The point I'm looking at is if
the P-X series gets developed enough, and someone is using a
4-16P system, a corp user might be approaching that limit
today or tomorrow.  Joe User, might not for 5 years, but that's
what the configurability is about.  Keep linux usable for both
ends of the scale -- "I love scalability"

-l

-- 
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338
-- 
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Lovely crash with 2.4.2-ac24.

[Andre Hedrick]

Zephaniah,

Does this happen in a non-ac kernel?
I have not updated code since around 2.4.0, but other have.
You point ot a few times w/ ac18, but is there one before that which does
not cause this to happen?

The question is to gain isolation of the changes.

On Mon, 26 Mar 2001, Zephaniah E. Hull wrote:

> This had hit me a few times with ac18 (I'm not sure it was the same
> crash though) and just hit me again with ac24.
> 
> Alan cced due to it being in the ac kernels, Andre because the trace
> seems to point to the IDE code.
> 
> Thanks.
> 
> Zephaniah E. Hull.
> 
> -- 
>  PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801
> Keys available at http://whitestar.soark.net/~warp/public_keys.
>CCs of replies from mailing lists are encouraged.
> 
>  Mercury: gpm isn't a very good web browser.  fix it.
> 

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

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

Re: slow latencies on IDE disk drives( controller? )

[Andre Hedrick]

Hello GAT,

Can you be more specific?  I need a kernel and hardware info and generally
more info than what is given.  Is this a PIO/DMA process is it a laptop or
unsupported hardware?

On Mon, 26 Mar 2001, Uncle George wrote:

> I am processing sound data on /dev/dsp. Generally the ~61k devive buffer
> is enough to keep the device satiated && gives the program time to fill
> up the device buffer when there is 16k of buffer space that needs to be
> filled.
> 
> But on occasion the /dev/dsp device "slurrs" ( sounds like what happens
> when the speed of a tape recorder slows down due to a finger placed down
> on the capstain ) unexpectedly. This was eventually traced to the usage
> of an IDE disk drive. using the scsi drive does not cause the problem to

How did you derive this path to the ATA driver?
What is the drive, and how fast (or how slow) is it?

> manifest itself( at least my ears say so ). but using "dd if=/dev/hda4
> of=/dev/null ) does immediately cause the slurring to happen.
> 
> 
> I think I can create a simple pgm to demo this problem, but the DATA
> file that gets feed into /dev/dsp is a little large for e-mail.

The content of the barf is not important, but the process you are doing to
create this issue is.

Andre Hedrick
Linux ATA Development

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