Re: IDE bug in 2.4.2-ac12?

[konrad_lkml]

Vojtech Pavlik wrote:
> On Tue, Mar 06, 2001 at 09:32:46PM +, Paul Bristow wrote:
> > On Tuesday 06 March 2001 19:13, Konrad Stopsack wrote:
> > > Hello guys,
> > >
> > > I hope you've read my posting "DMA problem with ZIP drive and VIA
> > > VT82C598MVP / VT82C586B chip" (why does anybody answer?).
> > > I now tried the 2.4.2-ac12 kernel including the latest VIA 82c586b
> driver
> > > (version 3.21), but the effects were almost the same:
> > > - just when the kernel tried to access to the hard disk during boot,
> DMA
> > > errors were occured
> > > - "hdparm /dev/hda" displayed 9 MB per second (and not 11 MB like
> without
> > > ZIP) - /proc/ide/via reported 16 MB transfer rate (and not 33MB like
> > > without ZIP drive)
> > > - Kernel 2.4.2-ac12 reports a "ide-floppy: hdd: I/O error, pc = 5a,
> key = 
> > > 5, asc = 24, ascq =  0" error, 2.4.2 doesn't
> > >
> > > My IDE configuration is:
> > > /dev/hda: Hard disk  => Primary IDE controller
> > > /dev/hdc CD-ROM  => Secondary IDE controller
> > > /dev/hdd: ZIP   => Secondary IDE controller
> > >
> > > Could you please tell me whether it's a bug or a feature?
> > 
> > OK.  The ZIP drive can not handle uDMA, so it's normal for the 
secondary
> 
> > controller to drop back.  In my opinion, the primary controller should
> stay 
> > at uDMA speed, but it is PC hardware so it is perfectly possible there
> is 
> > something cheap that locks them together.  I will bring up ac-12 and
> check 
> > the error message...
> 
> Actually I'm beginning to suspect the PSU here ... does removing the
> CD-ROM (leaving just the HDD and the ZIP in) help? Does the ZIP cause
> errors even when connected just to the power cable (and not the IDE
> cable)?
> 
Do you mean the Power Supply Unit? Or the Program Storage Unit? ;-)

To answer to your questions:
 - I haven't tried to remove the CD-ROM because both devices shall work 
together
 - the ZIP doesn't cause problems when just the power cable is connected

Although my PC has only got an old Baby AT 200W power supply I don't think 
that's the point.

cu Konrad

-- 
Konrad Stopsack - [EMAIL PROTECTED]

Sent through GMX FreeMail - http://www.gmx.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/

2.4.2-acX and reiserfs

[[EMAIL PROTECTED]]

I'm 99.9% certain that those patches referred to have been merged with the
latest 2.4.2-acX, but just to make it 100% certain I'm asking this question.
At www.namesys.com, the reiserfs website, I read:
"Latest patch for linux-2.4.2 contains fixes for tail conversion bug,
preallocated block leakage, object id sharing problem, dir fsync bug and
other minor fixes/improvements."
Have _all_ those fixes gone into the latest ac-patch? (I saw references to
"tail conversion fixes" and "dir fsync bug" in Alan's Changelog, but I
didn't find all of them so I'm not sure. :-)
The reason of why I'm wondering is that I've been having serious trouble
with reiserfs, and when I'm going for a new fresh installation I want to be
100% sure that all fixes have been merged.
So I would really appreciate a confirmation that all fixes have been merged,
so I won't have to worry. :-)

Please reply to this email-address: [EMAIL PROTECTED] (as I'm not subscribed
to the Linux kernel mailing-list as of now).

Thanks a lot,
Ole André



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

Re: Linux 2.4.2ac14

[Doug Ledford]

Alan Cox wrote:
> 2.4.2-ac14
> o   Updated i810_audio.c(Doug Ledford)

I wanted to let people know that there is a lot of new code in this particular
update that needs testing.  The nice thing is that quake3 should now play with
this sound driver so the testing can at least be a little bit of fun ;-) 
Basically, all the stuff that used to work still should, mmap audio should now
work, and you should not have to specify any ftsodell=1 options to the driver
any more and it shouldn't sound like Alvin and the Chipmunks when you don't. 
If anyone finds problems with this driver, please let me know.  I tested what
I could, but I'm sure there are things I possibly missed.  Oh, one more thing,
when playing mp3's via xmms and using the oss output module, the number of
interrupts the system has to service is down by about 100 per second or more,
so it should be slightly lighter on system CPU time as well.

-- 

 Doug Ledford <[EMAIL PROTECTED]>  http://people.redhat.com/dledford
  Please check my web site for aic7xxx updates/answers before
  e-mailing me about problems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Questions about Enterprise Storage with Linux

[james rich]

On Wed, 7 Mar 2001, Tom Sightler wrote:

> 2.  Does linux have any problems with large (500GB+) NFS exports, how about
> large files over NFS?
> 
> 3.  What filesystem would be best for such large volumes?  We currently use
> reirserfs on our internal system, but they generally have filesystems in the
> 18-30GB ranges and we're talking about potentially 10-20x that.  Should we
> look at JFS/XFS or others?

I think that for filesystems this size you definately want to look at XFS
of JFS.  Maybe you will decide not to use them - but you should test them.

I am currently using XFS and it really works.  It currently has some
issues when used with raid 1, but it is probably the most suited for what
you want.  Exporting an XFS volume over NFS is no problem.  You can also
use xfs_growfs to change the size of your XFS partition.  I haven't had
any instability during all the time I've used XFS.

James Rich
[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 2.4.3

[Krzysztof Halasa]

"Richard B. Johnson" <[EMAIL PROTECTED]> writes:

> Attempts to run linux-2.4.3-pre2 on chaos.analogic.com results
> in **MASSIVE** file-system destruction. I have (had) all SCSI
> disks, using the BusLogic controller.
> 
> There is something **MAJOR** going on BAD, BAD, BAD, even disks
> that were not mounted got trashed.

What gcc version did you use to compile it?
-- 
Krzysztof Halasa
Network Administrator
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] /dev/fb*

[Geert Uytterhoeven]

Hi Linus,

This patch fixes the /dev/fb* entries in devices.txt to conform to the actual
code (which has been there since at least one year).

PLEASE apply this patch! MANY thanks!

--- linux-2.4.3-pre3/Documentation/devices.txt  Sat Dec 30 20:26:10 2000
+++ linux-2.4.2-ac14/Documentation/devices.txt  Thu Mar  8 07:27:30 2001
@@ -660,6 +660,12 @@
 
  29 char   Universal frame buffer
  0 = /dev/fb0  First frame buffer
+ 1 = /dev/fb1  Second frame buffer
+   ...
+31 = /dev/fb31 32nd frame buffer
+
+   Backward compatibility aliases {2.6}
+
 32 = /dev/fb1  Second frame buffer
...
224 = /dev/fb7  Eighth frame buffer

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

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

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

Re: 2.4.2 ext2 filesystem corruption ? (was 2.4.2: What happened?(No

[Alexander Viro]

On Wed, 7 Mar 2001, Ben Greear wrote:

> I see it differently:  If it's possible for the driver to protect the
> user, and it does not, then it strikes me as irresponsible programming.  If
> there is a reason other than 'only elite users are cool enough to tune
> their system, and they never make mistakes', then that's ok, but I have
> not heard that argument yet.

*users* have no business changing the system configuration. End of story.
Again, if somebody doesn't read manpages before doing stuff under root -
no point trying to protect him. He will find a way to fsck up, no matter
how many "safety" checks you put in. BTW, that's the first time I've seen
"elite" used as a term for "able to understand the meaning of words 'use
with extreme caution'". Oh, well...
Cheers,
Al

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

Re: 2.4.2 ext2 filesystem corruption ? (was 2.4.2: What happened ?(No

[Ben Greear]

Alexander Viro wrote:
> 
> On Wed, 7 Mar 2001, Ben Greear wrote:
> 
> > However, messing with the hdparms options can do random things, at
> > least from my perspective as a user:  It may bring exciting new performance
> > to your system, and it may subtly, or not so, corrupt your file system.
> 
> It's root-only. If you run unfamiliar stuff as root without thorough
> RTFM or choose to ignore "use with extreme caution" contained in the
> manpage - hdparm is the least of your problems. Think of it as evolution
> in action...
> Cheers,
> Al

I see it differently:  If it's possible for the driver to protect the
user, and it does not, then it strikes me as irresponsible programming.  If
there is a reason other than 'only elite users are cool enough to tune
their system, and they never make mistakes', then that's ok, but I have
not heard that argument yet.

Of course, I'd love it if the HD driver automatically brought it over
4MBps (it's 7200 RPM, for goodness sake!!).  (It sounds like, from
reading the hdparm man page, that my HD should do at least 20MBps..)

Either way, I've said my piece, and will go back to wrestling with
why my network/overall performance is sucking so badly all of a sudden...

Enjoy,
Ben

-- 
Ben Greear ([EMAIL PROTECTED])  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com (Released under GPL)
http://scry.wanfear.com   http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Questions about Enterprise Storage with Linux

[Tim Moore]

Tom Sightler wrote:
> ...
> For example if we purchase a NetApp Filer, or EMC Celerra with 1TB of
> storage, and elect to export that entire amount as a single NFS mount, and
> then use that storage to allow several Linux boxes to share 100GB
> (admittedly temporary) files, will Linux handle that, at least in theory?

Linux/NFS works very well with Filers.  I did a lot of throughput
testing at Netapp circa 2.2.10-12 with Gigabit Ethernet (AceNIC).  Why
would you need to put 1TB on a single mount point?

Filers are also blessed by Oracle and can take care of the volume
management and backup issues.  The principle advantage is avalibility
(balanced against cost of course).  If you do talk to Netapp, ask for
someone that has linux/Filer experience.

rgds,
tim.

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

Re: Linux 2.4.2ac12 (vt82c686 info)

[Rogerio Brito]

On Mar 07 2001, Vojtech Pavlik wrote:
> Also, the vt82c686 will work just fine with Linux, but will be limited
> to UDMA33, because UDMA66 on this chip does reliably fail.

How do I know which one I have? Using the revision of the
chip?

lspci only shows that I have a vt82c686 (revision 22 --
perhaps this is the clue), but I have been using UDMA66 drives
here with *no* corruption so far (or I haven't stressed my
system enough to notice it).

Here are the lines from my lspci which I think are relevant
here:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10)
00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  
Any hints are more than welcome.

[]s, Roger...

P.S.: This is an ASUS A7V mobo.
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 ext2 filesystem corruption ? (was 2.4.2: What happened ?(No

[Alexander Viro]

On Wed, 7 Mar 2001, Ben Greear wrote:

> However, messing with the hdparms options can do random things, at
> least from my perspective as a user:  It may bring exciting new performance
> to your system, and it may subtly, or not so, corrupt your file system.

It's root-only. If you run unfamiliar stuff as root without thorough
RTFM or choose to ignore "use with extreme caution" contained in the
manpage - hdparm is the least of your problems. Think of it as evolution
in action...
Cheers,
Al

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

Re: Linux 2.4.2ac14

[Keitaro Yosimura]

Hi. alan.

>2.4.2-ac14

at patching.
>The next patch would create the file `include/linux/hdlc.h',
>which already exists!  Assume -R? [n] n
>Apply anyway? [n] y
>patching file `include/linux/hdlc.h'
>Patch attempted to create file `include/linux/hdlc.h', which already exists.
>Hunk #1 FAILED at 1.
>1 out of 1 hunk FAILED -- saving rejects to include/linux/hdlc.h.rej

must remove before patching? or ignore it?

<|> YOSHIMURA 'ramsy' Keitaro / Japan Linux Association
<|> mailto:[EMAIL PROTECTED]
<|> http://jla.linux.or.jp/index.html

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

Re: Questions about Enterprise Storage with Linux

[Jauder Ho]

On Wed, 7 Mar 2001, Tom Sightler wrote:

> The questions that have been asked are as follows (assume 2.4.x kernels):
>
> 1.  What is the largest block device that linux currently supports?  i.e.
> Can I create a single 1TB volume on my storage device and expect linux to
> see it and be able to format it?

http://www.suse.de/~aj/linux_lfs.html should clear up

> 2.  Does linux have any problems with large (500GB+) NFS exports, how about
> large files over NFS?

See above

> 3.  What filesystem would be best for such large volumes?  We currently use
> reirserfs on our internal system, but they generally have filesystems in the
> 18-30GB ranges and we're talking about potentially 10-20x that.  Should we
> look at JFS/XFS or others?

I am not sure what you intend this application for. If it is mission
critical in any way shape or form, I would still recommend using something
like Veritas (which unfortunately is not ported to Linux yet). I have
heard good things about XFS although I have not had the chance to use it
yet.

> 4.  We're seriously considering using LVM for volume management.  Does it
> have size limits per volume or other limitations that we should be aware of?
>
> I'm sure these answers are out there, but I haven't been able to find
> definitive answers (it seems everyone has a different answer to each
> question).  Any assistance in pointing me to the correct information would
> be greatly appreciated.

Have fun and do post your findings back to l-k. I would be interested in
hearing what you end up with.

--Jauder

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 ext2 filesystem corruption ? (was 2.4.2: What happened ? (No

[Ben Greear]

Alan Cox wrote:
> 
> > I'm not arguing it was a smart thing to do, but I would think that the
> > fs/kernel/driver writers could keep really nasty and un-expected things
> > from happenning.  For instance, the driver could dis-allow any new (non-hdparm)
> 
> Like stopping root from using rm -r ? Where is the line drawn

rm -r does not do un-expected things, and it does not corrupt your file
system, it merely removes it.  That is the only thing it does, and it
does it every time.

However, messing with the hdparms options can do random things, at
least from my perspective as a user:  It may bring exciting new performance
to your system, and it may subtly, or not so, corrupt your file system.

If the drivers can detect what type of HD/chipset we are using, surely
it can know not to allow the user to do stupid things that are out of
spec w/regards to the hardware?

For the power/insane user, there could be a --really-do-stupid-thing-i-told-you-to
option, and it should be that hard to type!!

Ben

-- 
Ben Greear ([EMAIL PROTECTED])  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com (Released under GPL)
http://scry.wanfear.com   http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-pre2 aic7xxx crash on alpha

[Justin T. Gibbs]

>(scsi1:A:0:0): data overrun detected in Data-out phase.  Tag == 0x36.
>(scsi1:A:0:0): Have seen Data Phase.  Length = 0.  NumSGs = 0.

As I mentioned to you the last time you brought up this problem, I
don't believe that this is caused by the aic7xxx driver, but the
aic7xxx driver may be the first to notice the corruption.  Somehow
the system is generating disk requests with a zero length buffer
provided to the controller.  That is the cause of the data-overruns.
Perhaps there is a problem with the dma mapping operations on your
particular type of Alpha?

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

[PATCH] remove CONFIG_PCMCIA_SERIAL_CB from Configure.help

[Steven Cole]

It appears that use of CONFIG_PCMCIA_SERIAL_CB was removed in
2.4.2-ac12.  The two files affected were Config.in  and the Makefile 
in drivers/char/pcmcia.  

If in fact this option is now history, the reference in Configure.help should also 
be history.  I noticed this when the number of Configure.help "orphans" increased
from 40 to 41 recently.

Here is the patch to do this, against 2.4.2-ac14.

Steven

--- linux/Documentation/Configure.help.orig Wed Mar  7 21:13:56 2001
+++ linux/Documentation/Configure.help  Wed Mar  7 21:14:52 2001
@@ -2464,20 +2464,6 @@
   a module, say M here and read Documentation/modules.txt. If unsure,
   say N.
 
-CardBus serial device support
-CONFIG_PCMCIA_SERIAL_CB
-  Say Y here to enable support for CardBus serial devices, including
-  serial port cards, modems, and the modem functions of multi-function
-  ethernet/modem devices. (CardBus cards are the newer and better 
-  version of PCMCIA- or PC-cards: credit card size devices often 
-  used with laptops.)
-
-  This driver is also available as a module ( = code which can be
-  inserted in and removed from the running kernel whenever you want).
-  The module will be called serial_cb.o. If you want to compile it as
-  a module, say M here and read Documentation/modules.txt. If unsure,
-  say N.
-
 /dev/agpgart (AGP Support) (EXPERIMENTAL)
 CONFIG_AGP
   AGP (Accelerated Graphics Port) is a bus system mainly used to
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 kernel - and regular sync'ing?

[Brian Dushaw]

Hey There Kernel-people!
   I have a disk accessing question you may be able to help me with,
if I may be so bold
   I have a notebook computer, and in the interests of saving power
I am trying to get its disk to go into suspend mode (hdparm -S 6 /dev/hda,
say...)  However, something seems to be continuously accessing the disk
at irregular intervals of 10-30 seconds, most likely calls to sync, so
that the disk never gets to sleep for long.  I've followed advice in the
various HOWTO's, e.g. modifying the line "ud::once:/sbin/update" in
/etc/inittab to only sync once an hour, to no avail.  Watching "top", it
sure looks as if various kernel-based daemons are responsible...nothing
else is running!
   Can you offer me any advice?  Any tweeks I can make to tell the system
that sync'ing only once every 5 minutes is o.k.?
   I have the 2.4.2 kernel (older kernels behaved the same way) and
the RedHat 6.2 distribution.

Thx!
B.D.

-- 
%

Brian Dushaw
Applied Physics Laboratory
University of Washington
1013 N.E. 40th Street
Seattle, WA  98105-6698
(206) 685-4198   (206) 543-1300
(206) 543-6785 (fax)
[EMAIL PROTECTED]

Web Page:  http://staff.washington.edu/dushaw/index.html

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

Re: Questions about Enterprise Storage with Linux

[Tom Sightler]

> >1.  What is the largest block device that linux currently supports?  i.e.
> >Can I create a single 1TB volume on my storage device and expect linux to
> >see it and be able to format it?
>
> Checkout the GFS project for really large filesystems with a high
capability
> of "fail safe" configuration.
>
> The block/file limits are more determined by the size of the hosts.
Alpha/Sparc
> based systems use 64 bit operations, Intel/AMD use 32 bit. It also depends
> on usage of the sign bit in the drivers. Most 32bit systems are limited
> to 1 TB (depending on the driver of course - some allow for 2 TB).

Yes, I should have clarified, we will be using the Intel platform.

A large portion of the fiber channel storage (as much as 300GB in year one)
will be dedicated to an Oracle 8i database, I'm not sure if GFS is truly
suited for this server, although we have considered using LVM (perhaps even
RAWIO on LVM although I see reports of problems with that) to ease some
storage management issues (we've been testing LVM with reiserfs and are very
impressed with the ease of adding space and growing the filesystem live).

> >2.  Does linux have any problems with large (500GB+) NFS exports, how
about
> >large files over NFS?
>
> I can't really say - you might clarify by what you count as large ( just >
2G
> should be fine for any current kernel), not sure if "large" means
25-100GB.

For example if we purchase a NetApp Filer, or EMC Celerra with 1TB of
storage, and elect to export that entire amount as a single NFS mount, and
then use that storage to allow several Linux boxes to share 100GB
(admittedly temporary) files, will Linux handle that, at least in theory?
Basically, I don't know what the file size limits are on NFS (on any system,
not neccesarily just Linux) and was hoping someone could tell me.

And actually, we have looked at GFS as an alternative for this function,
biggest disadvantage is cost of connecting 7 machines via fiber channel (we
already have GigE from the network connectivity), but it does look like an
excellent option which we may very well go with.

And some of these sizes I'm asking about are just seeking the limits, I'll
personally be amazed if we actually approach within half of these sizes any
time soon, but then again, data always manages to grow to fill whatever
storage you have available so I guess you never know, right?

> >3.  What filesystem would be best for such large volumes?  We currently
use
> >reirserfs on our internal system, but they generally have filesystems in
the
> >18-30GB ranges and we're talking about potentially 10-20x that.  Should
we
> >look at JFS/XFS or others?
>
> The GFS project already has tested 2TB in fiber channel array(s) with full
> multi-host connectivity (shared filesystems rather than NFS).
>
> The big advantage with GFS is that redundant servers can be available
> by having two or more NFS servers attached to the same GFS filesystem.

Yep, as I mentioned above, we may very well use GFS here.  It certainly has
some advantages that we really like, but we need to justify the additional
host of HBA's and another fiber channel switch (saying it won't work over
NFS would be enough to justify it).  We also had some concerns of stability
with GFS, not that we know of any issues, but we don't really have an easy
way test it in our current environment, and we haven't ordered the new
equipment yet.

> >4.  We're seriously considering using LVM for volume management.  Does it
> >have size limits per volume or other limitations that we should be aware
of?
>
> GFS may serve better. It is a full shared filesystem with RAID target
disks
> (these are smart controllers) and incudes journaling.

The LVM issue was largely for the managent of the volumes dedicated to the
Oracle database (basically a replacement for Veritas Volume Manager that
Oracle on Solaris folks seem to love).  Once again, we don't think GFS is
really suited for Oracle (other opinions accepted).  I was interrupted a few
too many times when composing the first email, I should have been more
detailed about exactly what we were doing, what we've looked at, etc.

Thanks,
Tom


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

Re: Process vs. Threads

[David Schwartz]

> Gregory Maxwell wrote:
>
> >
> > There are no threads in Linux.
> > All tasks are processes.
> > Processes can share any or none of a vast set of resources.
> >
> Is there a way a user program can find out what resources
> are shared among which processes?
>
> That would allow enhancing ps, top, etc to
> report memory usage correctly.

In fact, 'top' does report memory usage correctly. What 'top' should do,
however, is (by default) suppress the display of additional processes that
share a vm, showing only the 'highest parent' in the tree of processes that
share a vm.

DS



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

Re: Questions about Enterprise Storage with Linux

[Marcelo Tosatti]

On Wed, 7 Mar 2001, Jesse Pollard wrote:

> On Wed, 07 Mar 2001, Tom Sightler wrote:
> >Hi All,
> >
> >I'm seeking information in regards to a large Linux implementation we are
> >planning.  We have been evaluating many storage options and I've come up
> >with some questions that I have been unable to answer as far as Linux
> >capabilities in regards to storage.
> >
> >We are looking at storage systems that provide approximately 1TB of capacity
> >for now and can scale to 10+TB in the future.  We will almost certainly use
> >a storage system that provides both fiber channel connectivity as well as
> >NFS connectivity.
> >
> >The questions that have been asked are as follows (assume 2.4.x kernels):
> >
> >1.  What is the largest block device that linux currently supports?  i.e.
> >Can I create a single 1TB volume on my storage device and expect linux to
> >see it and be able to format it?
> 
> Checkout the GFS project for really large filesystems with a high capability
> of "fail safe" configuration.
> 
> The block/file limits are more determined by the size of the hosts. Alpha/Sparc
> based systems use 64 bit operations, Intel/AMD use 32 bit. It also depends
> on usage of the sign bit in the drivers. Most 32bit systems are limited
> to 1 TB (depending on the driver of course - some allow for 2 TB).

Even on 64-bit architectures the hard upper limit is 2TB. (32-bit block
numbers)



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

[PATCH] 2.4.2 -- Process Aggregates

[Sam Watters]

Applies against the 2.4.2 kernel and supports i386 and ia64 systems.

This patch provides the ability to register support for generic
process groups.  It does this by adding and entry in the task_struct
to maintain a list of pagg (process aggregate) group attachments (or
memberships).  In addition, there are interfaces for modules to register
as providing support for types of process aggregates.  Changes were made
to the fork and exit system calls so that child processes inherits group
memberships from the parent process.

PAGG features:

- Child inherits attachment to the same PAGG
  containers as the parent. 

- PAGG Containers are updated when new processes are
  attached (eg. during process forks). 

- PAGG Containers are updated when a process is
  detached (eg. when a process exits). 

- System call for controlling linux kernel modules
  that implement PAGG containers. 


Another patch will follow that implements a job container using this
pagg interface. The title for that patch will be: "[PATCH] 2.4.2 --
Linux Jobs".  Since the pagg patch provides a generic feature, and jobs
is just one implementation using that feature, the code was split into
two patches.  The pagg patch is useful by itself and does not require
the job patch.

This work was done so that we could provide a job accounting package
(called CSA).

For additional information about process aggregates & jobs, please go
to the home page at:

http://oss.sgi.com/projects/pagg

At this site you can download these patches and the commands package
(in RPM or tarball format).  Also, there are additional patches for
other 2.4.x kernels.

For additional information about CSA job accounting, please consult the
home page at:

http://oss.sgicom/projects/csa

patch follows (linux-2.4.2-pagg.patch):
---
diff -Naur linux-2.4.2/Documentation/Configure.help
linux-2.4.2-pagg/Documentation/Configure.help
--- linux-2.4.2/Documentation/Configure.helpMon Feb 19 12:18:18 2001
+++ linux-2.4.2-pagg/Documentation/Configure.help   Mon Mar  5 08:46:36 2001
@@ -14648,6 +14648,14 @@
   keys are documented in Documentation/sysrq.txt. Don't say Y unless
   you really know what this hack does.
 
+Process Aggregates support
+CONFIG_PAGG
+  Say Y here if you will be loading modules which provide support
+  for process aggregate containers.  Currently, this option is only
+  applicable to Intel (i386) architectures. Examples of such modules
+  include the Linux Jobs module and the Linux Array Sessions module.
+  If you will not be using such modules, say N.
+
 ISDN subsystem
 CONFIG_ISDN
   ISDN ("Integrated Services Digital Networks", called RNIS in France)
diff -Naur linux-2.4.2/Documentation/pagg.txt
linux-2.4.2-pagg/Documentation/pagg.txt
--- linux-2.4.2/Documentation/pagg.txt  Wed Dec 31 18:00:00 1969
+++ linux-2.4.2-pagg/Documentation/pagg.txt Mon Mar  5 08:46:36 2001
@@ -0,0 +1,253 @@
+Linux Process Aggregates (PAGG)
+---
+
+Comments by:   Sam Watters <[EMAIL PROTECTED]>
+Last Update:   2001.01.30
+
+
+1. Description
+
+Borrowing the process aggregate concept found in IRIX 6.5 and implementing
+that concept in the Linux kernel provides a generalized mechanism for
+providing arbitrary process groups.  The process aggregate or PAGG
+consists of a series of functions for registering and unregistering
+support for PAGG's with the kernel.  This is similar to the support
+currently provided within Linux that allows for dynamic support
+of filesystems, block and character devices, symbol tables, network
+devices, serial devices, and execution domains.  Implementation of the
+PAGG provides developers the basic hooks necessary  to implement kernel
+modules for specific process containers, such as the job container.
+
+The fork(2) system call was altered to support PAGGs.  If a process is
+attached to any PAGG containers and that process forks, the child process
+will also be attached to the same PAGG containers.  The PAGG containers
+are be updated to indicate that a new process has been attached.
+The update is accomplished via a callback function provided by the
+PAGG module.
+
+The exit notification function in the kernel has also been altered.  If a
+process is attached to any PAGG containers and that process is exiting,
+the PAGG containers are updated to indicate that a process has detached
+from the container.  The update is accomplished via a callback function
+provided by the PAGG module.
+
+
+2.  Kernel Changes
+
+This section will describe files and data structures that need to be 
+modified to implement PAGGs.  In addition, new files and data 
+structures will also be introduced.
+
+3.1. Modified Files
+
+The following files require changes to implement PAGGs:
+
+-  Documentation/Configure.help
+-  arch/i386/config.in
+-  include/asm-i386/unistd.h  
+-  include/linux/sched.h
+-  arch/i386/kernel/entry.S
+-  kernel/Makefile  
+-  kernel/exit.c
+-  

[PATCH] 2.4.2 - Linux Jobs

[Sam Watters]

Applies against the 2.4.2 kernel, supports i386 and ia64, and depends
upon the Linux Process Aggregates (PAGG) patch (linux-2.4.2-pagg.patch).
The PAGG patch was delivered in a previous post with the subject: "[PATCH]
2.4.2 - Process Aggregates".  At the bottom of this description will be
a web page reference that allows these patches and a command package to
be downloaded.

This patch implements a process aggregate container -- a generic
process group.  Specifically, this patch implements process groups
called jobs.  

A job is a group of related processes, all descended from a point of entry
(POE) process and identified by a unique job ID.  A job can contain
multiple process groups, session, and processes.  The job acts as a
process containment mechanism and a process is not allowed to escape
from the job container.  This allows resource limits to be extended
from the process level to the job level.  Additionally, the job allows
accounting information to be accumulated for all processes that executed
within the job container.  This provides users and administrators with
increased capabilities for system scheduling and planning for work loads.

The job, has the following characteristics:

-  A job is an inescapable container.  A process cannot leave the job 
   container nor can a new process be created outside the job without 
   explicit  action, that is, a system call with root privilege.

-  Each new process inherits the job ID and limits from its parent  
   process.

-  All point of entry processes (job initiators) create a new job and 
   set the job limits appropriately.

-  Users can raise and lower their own job limits within maximum 
   values specified by the system administrator.

-  The job initiator performs authentication and security checks.

-  The process control initialization process (init(1M)) and start-up  
   scripts called by init are not part of a job.  Likewise, system 
   daemons are usually not part of a job.  

This work was done so that we could provide a job accounting package
(called CSA).

For additional information about process aggregates & jobs, please go
to the home page at:

http://oss.sgi.com/projects/pagg

At this site you can download these patches and the commands package
(in RPM or tarball format).  Also, there are additional patches for
other 2.4.x kernels.

For additional information about CSA job accounting, please consult the
home page at:

http://oss.sgicom/projects/csa

patch follows (linux-2.4.2-pagg-job.patch):
---
diff -Naur linux-2.4.2-pagg/Documentation/Configure.help
linux-2.4.2-pagg-job/Documentation/Configure.help
--- linux-2.4.2-pagg/Documentation/Configure.help   Mon Mar  5 08:46:36 2001
+++ linux-2.4.2-pagg-job/Documentation/Configure.help   Mon Mar  5 08:58:43 2001
@@ -14656,6 +14656,34 @@
   include the Linux Jobs module and the Linux Array Sessions module.
   If you will not be using such modules, say N.
 
+Process Aggregates Job support
+CONFIG_PAGG_JOB
+  The Job feature implements a type of process aggregate,
+  or grouping.  A job is the collection of all processes that
+  are descended from a point-of-entry process.  Examples of such
+  points-of-entry include telnet, rlogin, and console logins.
+  A job differs from a session and process group since the job
+  container (or group) is inescapable.  Only root level processes,
+  or those with the CAP_SYS_RESOURCE capability, can create new jobs
+  or escape from a job.
+
+  A job is identified by a unique job identifier (jid).  Currently,
+  that jid can be used to obtain status information about the job
+  and the processes it contians.  The jid can also be used to send
+  signals to all processes contained in the job.  In addition,
+  other processes can wait for the completion of a job - the event
+  where the last process contained in the job has exited.
+
+  In the future, resource limit features will be added to jobs.
+  Such limits would be enforced against the aggregate usage of
+  resources by all processes within the job.
+
+  If you want to compile support for jobs into the kernel, select
+  this entry using Y.  If you want the support for jobs provided as
+  a module, select this entry using M.  If you do not want support
+  for jobs, select this entry using N (this is the default setting).
+
+
 ISDN subsystem
 CONFIG_ISDN
   ISDN ("Integrated Services Digital Networks", called RNIS in France)
diff -Naur linux-2.4.2-pagg/Documentation/job.txt
linux-2.4.2-pagg-job/Documentation/job.txt
--- linux-2.4.2-pagg/Documentation/job.txt  Wed Dec 31 18:00:00 1969
+++ linux-2.4.2-pagg-job/Documentation/job.txt  Mon Mar  5 08:58:43 2001
@@ -0,0 +1,610 @@
+Linux Jobs - A Process Aggregate (PAGG) Module
+--
+
+Comments by:   Sam Watters <[EMAIL PROTECTED]>
+Last Change:   2001.01.30
+
+
+1. Overview
+
+This document provides two additional sections.  Section 2 

Re: Questions about Enterprise Storage with Linux

[Jesse Pollard]

On Wed, 07 Mar 2001, Tom Sightler wrote:
>Hi All,
>
>I'm seeking information in regards to a large Linux implementation we are
>planning.  We have been evaluating many storage options and I've come up
>with some questions that I have been unable to answer as far as Linux
>capabilities in regards to storage.
>
>We are looking at storage systems that provide approximately 1TB of capacity
>for now and can scale to 10+TB in the future.  We will almost certainly use
>a storage system that provides both fiber channel connectivity as well as
>NFS connectivity.
>
>The questions that have been asked are as follows (assume 2.4.x kernels):
>
>1.  What is the largest block device that linux currently supports?  i.e.
>Can I create a single 1TB volume on my storage device and expect linux to
>see it and be able to format it?

Checkout the GFS project for really large filesystems with a high capability
of "fail safe" configuration.

The block/file limits are more determined by the size of the hosts. Alpha/Sparc
based systems use 64 bit operations, Intel/AMD use 32 bit. It also depends
on usage of the sign bit in the drivers. Most 32bit systems are limited
to 1 TB (depending on the driver of course - some allow for 2 TB).

>2.  Does linux have any problems with large (500GB+) NFS exports, how about
>large files over NFS?

I can't really say - you might clarify by what you count as large ( just > 2G
should be fine for any current kernel), not sure if "large" means 25-100GB.

>3.  What filesystem would be best for such large volumes?  We currently use
>reirserfs on our internal system, but they generally have filesystems in the
>18-30GB ranges and we're talking about potentially 10-20x that.  Should we
>look at JFS/XFS or others?

The GFS project already has tested 2TB in fiber channel array(s) with full
multi-host connectivity (shared filesystems rather than NFS). See:

http://www.sistina.com/gfs/

for details. It is not currently included in Linux distribution. The
current GFS version is 4.0 and works in kernel 2.2.18 and higher.

The big advantage with GFS is that redundant servers can be available
by having two or more NFS servers attached to the same GFS filesystem.

>4.  We're seriously considering using LVM for volume management.  Does it
>have size limits per volume or other limitations that we should be aware of?

GFS may serve better. It is a full shared filesystem with RAID target disks
(these are smart controllers) and incudes journaling.

>I'm sure these answers are out there, but I haven't been able to find
>definitive answers (it seems everyone has a different answer to each
>question).  Any assistance in pointing me to the correct information would
>be greatly appreciated.

I haven't had direct expierence with GFS, but it looks very impressive in
the documentation.

-- 
-
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: yacc dependency of aic7xxx driver

[Peter Samuelson]

[Jörn Nettingsmeier, quoting Robert Muller]
> Just create a shell script called yacc with the following content
> ---
> #!/bin/sh
> bison --yacc $*
> ---
> i ran into the same problem with a school proiject here yesterday

Why does nobody learn shell anymore?  (Just curious.)

  #!/bin/sh
  exec bison -y "$@"

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

2.4.3-pre2 aic7xxx crash on alpha

[Wakko Warner]

I can trigger this every time.
I'm using 2 2gb DEC drives (seagate) wide-scsi.  I have an adaptec
aha-2940uw card installed on the primary pci bus.
I'm using reiserfs and LVM (striped), but I can reproduce this w/o these.
All I have to do is:
for dev in /dev/sd[bcd];do cp /dev/zero $dev & ; done
and before it finishes, it crashes.  I think it crashes upon completion.

LVM basically does the same thing as far as writing to all 3 drives.
The way I caused the one below was coping /dev/zero to a reiserfs LVM drive
(1.6gb striped across all 3 disks).  This time, it didn't actually finish,
but it did write 1.49gb to the disk before it died (141mb left).

Dmesg output (including oops):
Linux version 2.4.3-pre2 (wakko@kakarot) (gcc version 2.95.2 2220 (Debian 
GNU/Linux)) #7 Tue Mar 6 20:12:04 EST 2001
Booting on Noritake using machine vector Noritake from SRM
Command line: root=0801 ro console=ttyS0
memcluster 0, usage 1, start0, end  171
memcluster 1, usage 0, start  171, end20403
memcluster 2, usage 1, start20403, end20480
freeing pages 171:384
freeing pages 635:20403
On node 0 totalpages: 20480
zone(0): 20480 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=0801 ro console=ttyS0
Using epoch = 1900
Console: colour VGA+ 80x25
Calibrating delay loop... 525.28 BogoMIPS
Memory: 157088k/163224k available (1156k kernel code, 4768k reserved, 249k data, 232k 
init)
Dentry-cache hash table entries: 32768 (order: 6, 524288 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 65536 bytes)
Page-cache hash table entries: 32768 (order: 5, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 262144 bytes)
POSIX conformance testing by UNIFIX
  got res[9000:90ff] for resource 0 of Adaptec AIC-7881U
  got res[9400:943f] for resource 0 of Ensoniq ES1371 [AudioPCI-97]
  got res[280:2ff] for resource 1 of 3DLabs Permedia II 2D+3D
  got res[300:37f] for resource 2 of 3DLabs Permedia II 2D+3D
  got res[220:221] for resource 0 of 3DLabs Permedia II 2D+3D
  got res[222:222] for resource 6 of Adaptec AIC-7881U
  got res[223:223] for resource 6 of 3DLabs Permedia II 2D+3D
  got res[224:2240fff] for resource 1 of Adaptec AIC-7881U
  got res[a000:a0ff] for resource 0 of Q Logic ISP1020
  got res[a400:a47f] for resource 0 of Digital Equipment Corporation DECchip 21142/43
  got res[a480:a4bf] for resource 0 of 3Com Corporation 3c905 100BaseTX [Boomerang]
  got res[380:383] for resource 6 of Digital Equipment Corporation DECchip 
21142/43
  got res[384:384] for resource 6 of Q Logic ISP1020
  got res[385:385] for resource 6 of 3Com Corporation 3c905 100BaseTX 
[Boomerang]
  got res[386:3860fff] for resource 1 of Q Logic ISP1020
  got res[3861000:386107f] for resource 1 of Digital Equipment Corporation DECchip 
21142/43
PCI: Bus 1, bridge: Digital Equipment Corporation DECchip 21050
  IO window: a000-afff
  MEM window: 0380-038f
PCI enable device: (Intel Corporation 82375EB)
  cmd reg 0x7
PCI enable device: (Digital Equipment Corporation DECchip 21050)
  cmd reg 0x107
PCI enable device: (Adaptec AIC-7881U)
  cmd reg 0x47
PCI enable device: (3DLabs Permedia II 2D+3D)
  cmd reg 0x7
PCI enable device: (Ensoniq ES1371 [AudioPCI-97])
  cmd reg 0x5
PCI enable device: (Q Logic ISP1020)
  cmd reg 0x47
PCI enable device: (Digital Equipment Corporation DECchip 21142/43)
  cmd reg 0x47
PCI enable device: (3Com Corporation 3c905 100BaseTX [Boomerang])
  cmd reg 0x47
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 103824kB/34608kB, 320 slots per queue
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
ttyS03 at 0x02e8 (irq = 3) is a 16550A
SCSI subsystem driver Revision: 1.00
qlogicisp : new isp1020 revision ID (2)
scsi0 : QLogic ISP1020 SCSI on PCI bus 01 device 00 irq 17 I/O base 0xa000
  Vendor: WDIGTLModel: ENTERPRISERev: 1.80
  Type:   Direct-Access  ANSI SCSI revision: 02
  Vendor: ARCHIVE   Model: Python 25501-XXX  Rev: 2.54
  Type:   Sequential-Access  ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 4254819 512-byte hdwr sectors (2178 MB)
Partition check:
 sda: sda1 sda2 sda3 sda4 sda5
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
ip_conntrack (637 buckets, 5096 max)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 232k freed
eth0: Digital DS21143 Tulip rev 48 at 0xa400, 00:00:F8:06:85:5D, IRQ 28.
eth0:  EEPROM default media type Autosense.
eth0:  Index #0 - Media 10baseT 

Re: Misspelled spinlock_prefetch for MK7 (was: Linux 2.4.2ac14)

[junio]

Sorry, I have wasted your time by speaking too early.

Here is a corrected version of my fix; the old one replaced one
typo with another X-<.

You need this to link for Athron/Durons.

--- 2.4.2-ac14/include/asm-i386/processor.h Wed Mar  7 16:59:48 2001
+++ 2.4.2-ac14/include/asm-i386/processor.h Wed Mar  7 17:25:17 2001
@@ -499,7 +499,7 @@
 {
 __asm__ __volatile__ ("prefetch (%0)" : : "r"(x));
 }
-#define spinock_prefetch(x)prefetchw(x)
+#define spin_lock_prefetch(x)  prefetchw(x)

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

Re: Linux 2.4.2ac12 and ac13 breaks usb-visor

[Greg KH]

On Wed, Mar 07, 2001 at 05:20:56PM -0600, Erik DeBill wrote:
> 
> I went to install some new software on my Visor yesterday and got a
> rude surpise, as my system froze hard (unpingable, no response to
> keyboard or mouse, no oops).  A bit of experimenting shows:
> 
> It works fine with usb-uhci in all versions I tested.
> 
> Plain 2.4.2 works fine with either usb-uhci or uhci.

uhci.o will cause crashes eventually.  It doesn't work with the visor
driver, sorry.  Stick with usb-uhci is you use the visor USB driver.

I just tried -ac14, with all of the usb subsystem as modules, and
everything worked fine syncing data, and installing packages on my
visor.

I'll try to run with everything compiled into the kernel later tonight.
Does -ac14 with all of USB as modules, using usb-uhci work for you?

thanks,

greg k-h

-- 
greg@(kroah|wirex).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/

Questions about Enterprise Storage with Linux

[Tom Sightler]

Hi All,

I'm seeking information in regards to a large Linux implementation we are
planning.  We have been evaluating many storage options and I've come up
with some questions that I have been unable to answer as far as Linux
capabilities in regards to storage.

We are looking at storage systems that provide approximately 1TB of capacity
for now and can scale to 10+TB in the future.  We will almost certainly use
a storage system that provides both fiber channel connectivity as well as
NFS connectivity.

The questions that have been asked are as follows (assume 2.4.x kernels):

1.  What is the largest block device that linux currently supports?  i.e.
Can I create a single 1TB volume on my storage device and expect linux to
see it and be able to format it?

2.  Does linux have any problems with large (500GB+) NFS exports, how about
large files over NFS?

3.  What filesystem would be best for such large volumes?  We currently use
reirserfs on our internal system, but they generally have filesystems in the
18-30GB ranges and we're talking about potentially 10-20x that.  Should we
look at JFS/XFS or others?

4.  We're seriously considering using LVM for volume management.  Does it
have size limits per volume or other limitations that we should be aware of?

I'm sure these answers are out there, but I haven't been able to find
definitive answers (it seems everyone has a different answer to each
question).  Any assistance in pointing me to the correct information would
be greatly appreciated.

Thanks,
Tom


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

Misspelled spinlock_prefetch for MK7 (was: Linux 2.4.2ac14)

[junio]

You need this to compile for Athron/Durons.

--- 2.4.2-ac14/include/asm-i386/processor.h Wed Mar  7 16:59:48 2001
+++ 2.4.2-ac14/include/asm-i386/processor.h Wed Mar  7 17:25:17 2001
@@ -499,7 +499,7 @@
 {
 __asm__ __volatile__ ("prefetch (%0)" : : "r"(x));
 }
-#define spinock_prefetch(x)prefetchw(x)
+#define spinlock_prefetch(x)   prefetchw(x)
 
 #endif
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH 2.4.0 parisc PCI support

[Grant Grundler]

Ivan Kokshaysky wrote:
...
> Well, it seems that I finally see what is wrong with your code, and
> why it worked in your case. You assume that "window" resources of
> the bridge are already known when we call pbus_assign_resources_sorted().
> This is incorrect.

Oh...do we know the "sizes" of all child resources from the bus walk?
I'll check that and see if it can be safely changed.

> Probably you rely on pci_read_bridge_bases() doing
> something meaningful (I looked at the parisc pci code in current 2.4.x,
> don't know about your CVS tree).

Nope - don't call that for A500 (machines with PDC PAT)...that might in
fact be another problem later related to some PDC (aka BIOS) changes.

> Yes, at least some of the DEC bridges
> after power-up/reset have 0s in base/limit registers. This means
> that you have ranges -0fff (4K) for IO and -000f (1M)
> for MEM. Obviously it's enough to hold all resources on the
> cards you've tested, but it won't work in common case. There is
> a lot of reasons why; just a couple of them:
> - according to PPB specification, base/limits registers of the bridge
>   after reset are *undefined*, so you'll probably have troubles
>   with non-DEC bridges.
> - there is a number of alpha systems with a built-in PCI-PCI bridge
>   and real PCI slots behind it. Obviously 4K/1M isn't enough for
>   these systems, and it was the main reason of rewriting that code.
> etc etc etc.

Yup - I think you are right on all counts here.
I'll rework the parisc code tonight/tomorrow and see if I can get rid
of the contentious generic PCI changes. I should be able to.

> Basically, you won't know bridge "window" size for a given bus until
> you'll have allocated *all* devices on *all* its child busses.

Linux doesn't. It's possible to deal with window register size in
the initial bus walk (where BAR sizes are determined).

> Besides, including bridge resources in the "sort lists" is meaningless,
> since these resources have fixed alignment - 4K for IO and 1M for MEM,
> unlike "regular" ones, which alignment == size.

The alignment would have to be handled correctly and I thought
pcibios_align_resource() did that. I see now the arch/parisc one doesn't
and others probably don't either. Let me think about this more...


> Unfortunately I haven't anything with a bridge handy at the moment
> to test that patch. Besides, we'll have here a sort of holidays till
> Sunday. So maybe next week...

np. thanks.

> 
> > I don't think existing PCI code is very "dirty".
> 
> I hope so. :-)

:^)

> However, some problems need to be worked out:
> 1. generic vs. arch code - we've already discussed some of these
> 2. Prefetchable Memory - do we need to deal with it? Though looking
>at modern x86 systems I tend to keep it disabled :-)

Ditto for parisc.

> 3. pdev_enable_device() - it's a bit ugly, confuses people and
>possibly is not needed at all.

Agreed.

thanks,
grant

Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Re: Can't compile 2.4.2-ac14

[Andrew Morton]

"J . A . Magallon" wrote:
> 
> Try this:

This is the better fix.

I apologise for this stuff-up.

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Re: Can't compile 2.4.2-ac14

[J . A . Magallon]

On 03.08 MATSUSHIMA Akihiro wrote:
> Hello,
> I receive the following error with make bzImage:
> 
> i386_ksyms.c:170: `do_BUG' undeclared here (not in a function)
> i386_ksyms.c:170: initializer element is not constant
> i386_ksyms.c:170: (near initialization for `__ksymtab_do_BUG.value')
> make[1]: *** [i386_ksyms.o] Error 1
> make[1]: Leaving directory `/usr/src/linux-2.4.2-ac14/arch/i386/kernel'
> make: *** [_dir_arch/i386/kernel] Error 2
> 

Try this:

--- linux-2.4.2-ac14/arch/i386/mm/fault.c.orig  Thu Mar  8 01:26:47 2001
+++ linux-2.4.2-ac14/arch/i386/mm/fault.c   Thu Mar  8 01:27:10 2001
@@ -110,11 +110,13 @@
}
 }
 
+#ifdef CONFIG_DEBUG_BUGVERBOSE
 void do_BUG(const char *file, int line)
 {
bust_spinlocks(1);
printk("kernel BUG at %s:%d!\n", file, line);
 }
+#endif
 
 asmlinkage void do_invalid_op(struct pt_regs *, unsigned long);
 extern unsigned long idt;
--- linux-2.4.2-ac14/arch/i386/kernel/i386_ksyms.c.orig Thu Mar  8
01:27:56 2001
+++ linux-2.4.2-ac14/arch/i386/kernel/i386_ksyms.c  Thu Mar  8 01:28:13
2001
@@ -167,5 +167,7 @@
 EXPORT_SYMBOL(empty_zero_page);
 #endif
 
+#ifdef CONFIG_DEBUG_BUGVERBOSE
 EXPORT_SYMBOL(do_BUG);
+#endif
 

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.2-ac13 #3 SMP Wed Mar 7 00:09:17 CET 2001 i686

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

Re: Linux 2.4.2ac14

[Greg KH]

On Wed, Mar 07, 2001 at 04:40:52PM -0800, Greg KH wrote:
> On Wed, Mar 07, 2001 at 11:13:37PM +, Alan Cox wrote:
> > o   Fix the non build problem with do_BUG   (Andrew Morton)
> 
> gcc -D__KERNEL__ -I/home/greg/linux/linux-2.4.2-ac14/include -Wall 
>-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686  
>-mno-terminator-canary-DEXPORT_SYMTAB -c i386_ksyms.c
> i386_ksyms.c:170: `do_BUG' undeclared here (not in a function)
> i386_ksyms.c:170: initializer element for `__ksymtab_do_BUG.value' is not constant
> make[1]: *** [i386_ksyms.o] Error 1
> make[1]: Leaving directory
> `/home/greg/linux/linux-2.4.2-ac14/arch/i386/kernel'
> make: *** [_dir_arch/i386/kernel] Error 2
> 
> .config attached

Enabling CONFIG_DEBUG_BUGVERBOSE allows the build to work.

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: aic7xxx funcs without return values

[Justin T. Gibbs]

>Hi,
>
>Just a note to make gcc 2.96 (and future) happy. The aic7xxx driver is full of
>inline funcs that should return a value and do not do that:

They don't return a value because doing so is meaningless.  You aren't
going to get past the panic.  The compiler should know that assuming
panic is properly tagged as a function that cannot return.

You may also want to check up on your C since having a break after
a return is, well, kinda silly.  In all the usage of this inline, the
width is constant, so gcc should completely optimize away the switch
and surrounding code.

--
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: Can't compile 2.4.2-ac14

[Alan Cox]

> Hello,
> I receive the following error with make bzImage:
> 
> i386_ksyms.c:170: `do_BUG' undeclared here (not in a function)
> i386_ksyms.c:170: initializer element is not constant
> i386_ksyms.c:170: (near initialization for `__ksymtab_do_BUG.value')
> make[1]: *** [i386_ksyms.o] Error 1
> make[1]: Leaving directory `/usr/src/linux-2.4.2-ac14/arch/i386/kernel'
> make: *** [_dir_arch/i386/kernel] Error 2

Change it to

#ifdef CONFIG_DEBUG_BUGVERBOSE
EXPORT_SYMBOL(do_BUG);
#endif

sorry

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Re: Linux 2.4.2ac14

[Tachino Nobuhiro]

Hello,

2.4.2ac14 compilation fails when CONFIG_DEBUG_BUGVERBOSE is not enabled.
Here is my small patch.


diff -r -u linux-2.4.2-ac14.org/include/asm-i386/page.h 
linux-2.4.2-ac14/include/asm-i386/page.h
--- linux-2.4.2-ac14.org/include/asm-i386/page.hThu Mar  8 09:31:45 2001
+++ linux-2.4.2-ac14/include/asm-i386/page.hThu Mar  8 09:21:43 2001
@@ -87,8 +87,8 @@
  * see^H^H^Hhear bugs in early bootup as well!
  */
 
-#ifdef CONFIG_DEBUG_BUGVERBOSE
 extern void do_BUG(const char *file, int line);
+#ifdef CONFIG_DEBUG_BUGVERBOSE
 #define BUG() do { \
do_BUG(__FILE__, __LINE__); \
__asm__ __volatile__(".byte 0x0f,0x0b");\
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.2ac14

[Greg KH]

On Wed, Mar 07, 2001 at 11:13:37PM +, Alan Cox wrote:
> o Fix the non build problem with do_BUG   (Andrew Morton)

gcc -D__KERNEL__ -I/home/greg/linux/linux-2.4.2-ac14/include -Wall -Wstrict-prototypes 
-O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i686  
-mno-terminator-canary-DEXPORT_SYMTAB -c i386_ksyms.c
i386_ksyms.c:170: `do_BUG' undeclared here (not in a function)
i386_ksyms.c:170: initializer element for `__ksymtab_do_BUG.value' is not constant
make[1]: *** [i386_ksyms.o] Error 1
make[1]: Leaving directory
`/home/greg/linux/linux-2.4.2-ac14/arch/i386/kernel'
make: *** [_dir_arch/i386/kernel] Error 2

.config attached

thanks,

greg k-h

-- 
greg@(kroah|wirex).com



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

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

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

#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_PM=y
# CONFIG_ACPI is not set
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play configuration
#
# CONFIG_PNP is not set
# CONFIG_ISAPNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_BLK_DEV_LVM is not set

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set
# CONFIG_BLK_DEV_IDEDISK_IBM is not set
# CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set
# 

Re: static scheduling - SCHED_IDLE?

[ludovic]

Oswald Buddenhagen wrote:
> 
> > The problem with these things it that sometimes such a task may hold
> > a lock, which can prevent higher-priority tasks from running.
> >
> true ... three ideas:
> - a sort of temporary priority elevation (the opposite of SCHED_YIELD)
>   as long as the process holds some lock
> - automatically schedule the task, if some higher-priorized task wants
>   the lock
> - preventing the processes from aquiring locks at all (obviously this
>   is not possible for required locks inside the kernel, but i don't
>   know enough about this)
> 
> > A solution would be to make sure that these tasks get at least one
> > time slice every 3 seconds or so, so they can release any locks
> > they might be holding and the system as a whole won't livelock.
> >
> did "these" apply only to the tasks, that actually hold a lock?
> if not, then i don't like this idea, as it gives the processes
> time for the only reason, that it _might_ hold a lock. this basically
> undermines the idea of static classes. in this case, we could actually
> just make the "nice" scale incredibly large and possibly nonlinear,
> as mark suggested.
> 

Since the linux kernel is not preemptive, the problem is a little
bit more complicated; A low priority kernel thread won't lose the 
CPU while holding a lock except if it wants to. That simplifies the
locking problem you mention but the idea of background low priority 
threads that run when the machine is really idle is also not this
simple.

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

Re: Process vs. Threads

[Hank Leininger]

On 2001-03-07, "Albert D. Cahalan" <[EMAIL PROTECTED]> wrote:

> Then for proper ps and top output, you need a reasonably efficient
> way to grab all threads as a group. This could be as simple as
> ensuring that /proc directory reads return related tasks together.
> This works too:   /proc/42/threads/98 -> ../../98

For this (but not for other "proper thread support" things you mention)
would it be enough to have /proc publish some token that represent unique
->fs, ->mm, etc pointers?  (The kernel-space address of each would work,
though that might be leaking too much info; the least userspace must treat
such values as opaque canary tokens.)  This does not give you the most
efficient "ps --threads 231" but it does let ps, top, (fuser?), etc group
processes with the same vm, files, etc, no?  ...I'm kinda surprised such a
thing doesn't already exist actually.  Unless of course, it does exist, but
is not enough :-P

--
Hank Leininger <[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/

aic7xxx funcs without return values

[J . A . Magallon]

Hi,

Just a note to make gcc 2.96 (and future) happy. The aic7xxx driver is full of
inline funcs that should return a value and do not do that:

gcc -D__KERNEL__ -I/usr/src/linux-2.4.2-ac14/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2
-march=i686-c -o aic7xxx_linux.o aic7xxx_linux.c
In file included from aic7xxx_linux.c:131:
aic7xxx_osm.h: In function `ahc_pci_read_config':
aic7xxx_osm.h:839: warning: control reaches end of non-void function

That function, for example, is missing the returns and the breaks:

static __inline uint32_t
ahc_pci_read_config(ahc_dev_softc_t pci, int reg, int width)
{
switch (width) {
case 1:
{
uint8_t retval;
pci_read_config_byte(pci, reg, );
return (retval);
}

case 2:
{
uint16_t retval;
pci_read_config_word(pci, reg, );
return (retval);
}
case 4:
{
uint32_t retval;
pci_read_config_dword(pci, reg, );
return (retval);
}
default:
panic("ahc_pci_read_config: Read size too big");
/* NOTREACHED */
}
}

Or if you are so worried about early returns and fast paths:

static __inline uint32_t
ahc_pci_read_config(ahc_dev_softc_t pci, int reg, int width)
{
uint8_t b_val;
uint16_ts_val;
uint32_tl_val;

switch (width) {
case 1:
pci_read_config_byte(pci, reg, _val);
return b_bal;
break;
case 2:
pci_read_config_word(pci, reg, _val);
return s_bal;
break;
case 4:
pci_read_config_dword(pci, reg, _val);
return l_bal;
break;
}
panic("ahc_pci_read_config: Read size too big");
return 0;
}

Stack is changed only once, gcc is happy, and perhaps the explicit breaks
help gcc to optimize the code.

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.2-ac13 #3 SMP Wed Mar 7 00:09:17 CET 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/

Can't compile 2.4.2-ac14

[MATSUSHIMA Akihiro]

Hello,
I receive the following error with make bzImage:

i386_ksyms.c:170: `do_BUG' undeclared here (not in a function)
i386_ksyms.c:170: initializer element is not constant
i386_ksyms.c:170: (near initialization for `__ksymtab_do_BUG.value')
make[1]: *** [i386_ksyms.o] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.2-ac14/arch/i386/kernel'
make: *** [_dir_arch/i386/kernel] Error 2


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

Re: Linux 2.4.2ac12 and ac13 breaks usb-visor

[Greg KH]

I've been running with just that single visor patch on 2.4.2 for quite
some time now.  But I'm building ac13 right now, and I'll let you know
what I find out in a bit.

thanks for letting me know.

greg k-h

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

Re: Linux 2.4.2ac12 and ac13 breaks usb-visor

[Alan Cox]

> On ac12 and 13 if the visor driver is compiled into the kernel it wil=
> l
> work poorly for a time (very slow sync, jpilot/pilot-link complains o=

Does 2.4.2ac11 work - I ask this as ac12 has some visro changes

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

Re: Kernel 2.4.3 and new aic7xxx

[Justin T. Gibbs]

>hmmm..  Is there a reason why this would be -needed-?  It wouldn't be
>hard to implement, but I would rather not have drivers dealing with a
>list whose normal state is defined as "mostly sorted"...

That's the wrong definition.  The list is "sorted by probe order".

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

Linux 2.4.2ac12 and ac13 breaks usb-visor

[Erik DeBill]

I went to install some new software on my Visor yesterday and got a
rude surpise, as my system froze hard (unpingable, no response to
keyboard or mouse, no oops).  A bit of experimenting shows:

It works fine with usb-uhci in all versions I tested.

Plain 2.4.2 works fine with either usb-uhci or uhci.

On ac12 and 13 if the visor driver is compiled into the kernel it will
work poorly for a time (very slow sync, jpilot/pilot-link complains of
"weird packet" or "timeout") and then quit, refusing to even register
when the device connects.  Once this happens, after hitting the "sync"
button the pda just sits and eventually times out, saying it failed to
connect to the desktop.

If I compile the driver as a module on ac12 and 13 it will hang the
system on module unload after a failed attempt to install software to
the pda.  Normal syncs may work, but installing 3-4 files will hang
the system every time.  Since the Visor only registers as a USB device
for the duration of the transfer this hangs the system as soon as the
sync attempt quits.

In no case do I get any error messages in the logs, no console
messages, and no oops.

This isn't a critical issue, as the usb-uhci driver works fine, but
the uhci driver is the default.  Still, hanging the system is
misbehavior.

I also noticed that selecting to statically compile usb serial
adapters, then selecting module for the Visor driver wouldn't compile
the Visor module.  As long as the usb serial and Visor were both set
the same (either static or module) it compiles fine.

I'd be happy to test patches, or step back through the 2.4.2-ac series
to find exactly where things broke (but the changelog below shows a
change to the visor in 2.4.2-ac12).


Thanks,
Erik


On Tue, Mar 06, 2001 at 10:42:33PM +, Alan Cox wrote:
> 
>   ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
> 
> 2.4.2-ac13
> o Clean up mad16 detection stuff  (Pavel Rabel)
> o Fix epca unload (Andrey Panin)
> o Change null apic handling   (Maciej Rozycki)
> o aicasm now uses db3 (Sergey Kubushin)
> o Fix aic7xxx cross compile   (Cort Dougan)
> o Merge small net driver fixups/config fixes  (Jeff Garzik)
> o Update symbios drivers  (Gérard Roudier)
> o Rusty has moved (Rusty Russell)
> o 3c509/3c515 compile fixes   (Jeff Garzik)
> o Console locking updates - should fix vesafb (Andrew Morton)
>   clock problems
> o Merge the serial.c 5.0.5 update (Jeff Garzik, 
>   Ted Ts'o)
> o Merge SiS framebuffer updates   (Can-Ru Yeou)
> o Update ctrlfb   (Takashi Oe,
>Michel Lanners)
> o Add epson 640U scanner to the usb scanner list  (Patrick Dreker)
> 
> 2.4.2-ac12
> o Move the pci_enable_device for cardbus  (David Hinds)
> o Add Sony MSC-U01N to the unusual devices(Marcel Holtmann)
> o Final smc-mca fixups - should now work  (James Bottomley)
> o Document kernel string/mem* functions   (Matthew Wilcox)
>   | and I added a memcpy warning
> o Update VIA IDE driver to 3.21   (Vojtech Pavlik)
>   |No UDMA66 on 82c686, fix /proc and udma on
>   |686b, fix dma disables
> o Allow sleeping in ctrl-alt-del callbacks(Andrew Morton)
>   |Fix i2o, dac960, watchdog, gdth hangs on exit
> o Fix binfmt_misc (and make the proc handling (Al Viro)
>   |a filesystem -
>   |mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
> o Update the ACI support for sound/radio stuff(Robert Siemer)
> o Add RDS support to miroRadio(Robert Siemer)
> o Remove serverworks handling. The BIOS is our(me)
>   best (and right now only) hope for that chip
> o Tune the vm behavioru a bit more(Mike Galbraith)
> o Update PAS16 documentation  (Thomas Molina)
> o Reiserfs tools recommended are now 0d not 0b(Steven Cole)
> o Wan driver small fixes  (Jeff Garzik)
> o Net driver fixes for 3c503, 3c509, 3c515,   (Jeff Garzik)
>   8139too, de4x5, defxx, dgrs, dmfe, eth16i, 
>   ewrk3, natsemi, ni5010, pci-skeleton, rcpci45,
>   sis900, sk_g16, smc-ultra, sundance, tlan,
>   via-rhine, winbond-840, yellowfin, wavelan_cs
>   tms380tr
> o Trim 3K off the aha1542 driver size (Andrzej Krzysztofowicz)
> o Trim 1K off qlogicfas   (Andrzej Krzysztofowicz)
> o Fix openfirmware/mm boot on ppc (Cort Dougan)
> o Fix topdir handling in Makefile (Keith Owens)
> o Minor fusion driver updates 

Re: Process vs. Threads

[Albert D. Cahalan]

Helge Hafting writes:
> Gregory Maxwell wrote:

>> There are no threads in Linux.
>> All tasks are processes.
>> Processes can share any or none of a vast set of resources.
>
> Is there a way a user program can find out what resources 
> are shared among which processes? 
>
> That would allow enhancing ps, top, etc to
> report memory usage correctly.

I already looked into this. Sorry, it can not be done.

Linux briefly had the code needed to support threads properly.
Linus added it with the warning that it would be removed if he
didn't get enough feedback. Well I have a real job, and the code
was gone before the weekend! Look around near 2.4.0-test8 maybe.

For proper thread support:

First you need the concept of a thread group. This groups tasks
together similar to the way they form process groups and sessions.

Then for proper POSIX thread support, you need a flag to indicate
some awkward POSIX-mandated signal behavior within a thread group.

Then for proper ps and top output, you need a reasonably efficient
way to grab all threads as a group. This could be as simple as
ensuring that /proc directory reads return related tasks together.
This works too:   /proc/42/threads/98 -> ../../98

Severely non-POSIX threads are just not going to do anything sane,
unless thread groups get automatically wrapped around any threads
that share resources. So if 50 shares memory with 67, and 50 shares
the filesystem with 82, then 67 and 82 are non-POSIX threads of the
same non-POSIX process even if they share nothing with each other.

Automatic wrapping works much better, assuming it doesn't also cause
the awkward POSIX signal behavior by default. Tasks should need to
explicitly request the extra suffering.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Mapping a piece of one process' addrspace to another?

[James H. Cloos Jr.]

> "AV" == Alexander Viro <[EMAIL PROTECTED]> writes:

AV> Double ugh. Why bother with ioctl() when you can just have a
AV> second channel and do read()/write() on it?

Because you cannot rewrite -- or even re-compile -- every app this
should support.  OSS emulation by ALSA is a great example, given
how many binary-only apps already exist which need OSS emulation
on an ALSA box.

I'm sure sound is not the only real application for this.

-JimC
-- 
James H. Cloos, Jr.   1024D/ED7DAEA6 
<[EMAIL PROTECTED]>  E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: can't read DVD (under 2.4.[12] & 2.2.17)

[Jens Axboe]

On Wed, Mar 07 2001, Pozsar Balazs wrote:
> 
> Adding the
>  cgc.buflen = 20;
> line into drivers/cdrom/cdrom.c: dvd_read_physical(...)
> solves my problem.
> 
> I don't know the difference, but first you mentioned
>  cgc.buflen = 16;
> so i tried that also, and it worked the same.
> 
> I'll write again if i'm having problems. :)
> Thanks for the fast patch.

Great, it worked out in the end :-)

> I think you should also check 2.2.

Definitely, 2.2 and 2.4 are 100% similar in this regard.

-- 
Jens Axboe

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

Question...

[Alberio Bathory-Frota]

I was wondering what the difference between wake_up_process and
wake_up_process_synchronous is?

Thanks for your input,
Alberio.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] RFC: fix ethernet device initialization

[Alan Cox]

> It'll only take a few days.  Do we want?  If not, we can
> extend the dev_probe_lock() thing to cover probes for
> other busses.  USB, I guess.

cardbus.. usb.. insmod/rmmod

I'd like it fixed, but you have to convince DaveM
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] RFC: fix ethernet device initialization

[Andrew Morton]

Jeff Garzik wrote:
> 
> People from time to time point out a wart in ethernet initialization:
> 

They sure do.  You were away at the time, but I had a 94 file,
140k patch late last year which fixed all this.  It's
at

http://www.uow.edu.au/~andrewm/linux/netdevice.patch

and the design doc is at

http://www.uow.edu.au/~andrewm/linux/netdevice2.txt

>From a quick look, I think the only substantive difference
here is that my `prepare_etherdev()' function allocates
and reserves the device's name (eth0), but prevents it
from being available in netdevice namespace lookups.  This
was done because lots of drivers wanted to do:

init_etherdev();(Replaced with prepare_etherdev())
printk("%s: something", dev->name);

The changes to dev.c and net_init.c were fairly subtle
and took some thinking about - we should revisit them
if you want to go ahead with this.

The patch all worked OK, was back-compatible with unaltered
drivers, and indeed altered all the drivers.  But it kind of
got lost.  Too big, too late and dev_probe_lock() was there.

Now, Arjan says that this race is causing oopses.  This
surprises me, because current kernels have the the dev_probe_lock()
hack which I put in.  This fixes the problem for PCI and Cardbus
drivers. The ISA drivers generally use the dev->init() technique
which is not racy.  There isn't a lot left over.  Arjan?  Which driver?

The other reason I'm surprised that it's causing oopses: most
racy drivers do this:

xxx_probe()
{
init_etherdev();

dev->open = xxx_open;
return;
}

So the vastly most probably failure mode if the race occurs 
is this: the interface is opened while dev->open is NULL.
This won't oops.  Sure, the interface is screwed because
the open() routine hasn't been called, but it should hang
in there.  A subsequent close() of the interface *will*
call dev->close, and I guess the driver is likely to get
upset if its close() routine is called without a corresponding
open().

Yes, we can fix this if we want, and kill off dev_probe_lock().
It'll only take a few days.  Do we want?  If not, we can
extend the dev_probe_lock() thing to cover probes for
other busses.  USB, I guess.


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

[Alan Cox]

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

2.4.2-ac14
o   Fix the non build problem with do_BUG   (Andrew Morton)
o   Fix interface autocreation bug in ipx   (Arnaldo Carvalho
Also fix pprop routing bugs, tctrl handling  de Melo)
Fix wrong comments, fix ipx sysctl handling
clean up code
o   Updated i810_audio.c(Doug Ledford)
o   Fix up printer status readback  (Tim Waugh)
o   Add support for "ide=nodma" on command line (Arjan van de Ven)
o   More spelling fixes (Dag Wieers)
o   Add pci vendor table to lanstreamer (Mike Sullivan)
o   Do extra sanity checks on ext2 mount(Andreas Dilger)
o   Multithreaded core dump handling(Don Dugger)
| This is fairly experimental so the more eyes
| the better but it does sort out a very annoying weakness
o   Prefetch on lists for parisc and x86(Arjan Van de Ven,
| Work about 4% on scheduler performance on PIII Matthew Wilcox)
o   Natsemi power management changes(Tjeerd Mulder)
o   Fix assorted smb bugs   (Urban Widmark)
o   Fix a sisfb build problem   (Andrew Morton)

2.4.2-ac13
o   Clean up mad16 detection stuff  (Pavel Rabel)
o   Fix epca unload (Andrey Panin)
o   Change null apic handling   (Maciej Rozycki)
o   aicasm now uses db3 (Sergey Kubushin)
o   Fix aic7xxx cross compile   (Cort Dougan)
o   Merge small net driver fixups/config fixes  (Jeff Garzik)
o   Update symbios drivers  (Gérard Roudier)
o   Rusty has moved (Rusty Russell)
o   3c509/3c515 compile fixes   (Jeff Garzik)
o   Console locking updates - should fix vesafb (Andrew Morton)
clock problems
o   Merge the serial.c 5.0.5 update (Jeff Garzik, 
Ted Ts'o)
o   Merge SiS framebuffer updates   (Can-Ru Yeou)
o   Update ctrlfb   (Takashi Oe,
 Michel Lanners)
o   Add epson 640U scanner to the usb scanner list  (Patrick Dreker)

2.4.2-ac12
o   Move the pci_enable_device for cardbus  (David Hinds)
o   Add Sony MSC-U01N to the unusual devices(Marcel Holtmann)
o   Final smc-mca fixups - should now work  (James Bottomley)
o   Document kernel string/mem* functions   (Matthew Wilcox)
| and I added a memcpy warning
o   Update VIA IDE driver to 3.21   (Vojtech Pavlik)
|No UDMA66 on 82c686, fix /proc and udma on
|686b, fix dma disables
o   Allow sleeping in ctrl-alt-del callbacks(Andrew Morton)
|Fix i2o, dac960, watchdog, gdth hangs on exit
o   Fix binfmt_misc (and make the proc handling (Al Viro)
|a filesystem -
|mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
o   Update the ACI support for sound/radio stuff(Robert Siemer)
o   Add RDS support to miroRadio(Robert Siemer)
o   Remove serverworks handling. The BIOS is our(me)
best (and right now only) hope for that chip
o   Tune the vm behavioru a bit more(Mike Galbraith)
o   Update PAS16 documentation  (Thomas Molina)
o   Reiserfs tools recommended are now 0d not 0b(Steven Cole)
o   Wan driver small fixes  (Jeff Garzik)
o   Net driver fixes for 3c503, 3c509, 3c515,   (Jeff Garzik)
8139too, de4x5, defxx, dgrs, dmfe, eth16i, 
ewrk3, natsemi, ni5010, pci-skeleton, rcpci45,
sis900, sk_g16, smc-ultra, sundance, tlan,
via-rhine, winbond-840, yellowfin, wavelan_cs
tms380tr
o   Trim 3K off the aha1542 driver size (Andrzej Krzysztofowicz)
o   Trim 1K off qlogicfas   (Andrzej Krzysztofowicz)
o   Fix openfirmware/mm boot on ppc (Cort Dougan)
o   Fix topdir handling in Makefile (Keith Owens)
o   Minor fusion driver updates (Steve Ralston)
o   Merge Etrax cris updates(Bjorn Wesen)
o   Clgen fb copyright update   (Jeff Garzik)
o   AGP linkage fix (Jeff Garzik)
o   Update visor driver to work with minijam(Arnim Laeuger)
o   Fix a usb devio return code (Dan Streetman)
o   Resync a few other net device changes with the
submits Jeff sent to Linus  (Jeff Garzik)
o   Add missing md 

Re: can't read DVD (under 2.4.[12] & 2.2.17)

[Pozsar Balazs]

Adding the
 cgc.buflen = 20;
line into drivers/cdrom/cdrom.c: dvd_read_physical(...)
solves my problem.

I don't know the difference, but first you mentioned
 cgc.buflen = 16;
so i tried that also, and it worked the same.

I'll write again if i'm having problems. :)
Thanks for the fast patch.

I think you should also check 2.2.

Balazs Pozsar.

On Wed, 7 Mar 2001, Jens Axboe wrote:

> On Wed, Mar 07 2001, Jens Axboe wrote:
> > On Wed, Mar 07 2001, Jens Axboe wrote:
> > > Really good question, I sent this patch in the private thread between
> > > me and Pozsar just in case the length is what the drive complains about.
> >
> > Agrh, that's not all. I will fix this properly, sorry about the noise.
>
> This should work. Pozsar, could you test?
>
> I suspect that Derik is right though, that the 05/24/00 is because
> the dvdinfo is requesting info for a non-existant physical layer.
> I've attempted to quiet that error. You dvdinfo output did look
> very odd.
>
>


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

Kernel upgrading problems, please help...

[Jie Zhou]

I did an upgrade from  kernel-2.2.16 to the latest version-2.4.2.
During the "make bzImage"step, I got bunch of this warning:
"pasting would not give a valid preprocessing token". then I just ignored
it and after all done
rebooted the linux and got into the new kernel successfully. However, when
I tried to
mount my DVD RAM using the command mount -t udf /dev/hdb /mnt/dvd
(I did choose the support for udf filesystem), the command completed with a
promp appears.but
after the 'busy' light on the DVD catridge gets on, it never gets off any
more, and
the computer froze then. I thought it might be because I haven't unmount
the DVD
, so I restarted the computer and use the 'dmesg' command to see what
happens, then I found a lot of
"Unable to identify CD-ROM Format" messages in it. so I did a 'mount'
command to check whether it's
 mounted or not, and the result shows that the /dev/hdb(which is the DVD on
my computer) is not mounted
yet.So I did the mount -t udf /dev/hdb /mnt/dvd again, same thing happens
again-the computer froze with the DVD light on.
I read in the book "Running Linux", the author said
"If any errors or warnings occur while compiling, you cannot expect the
resulting
kernel to work correctly..." I'm wondering if it's because of the the
warning I got during
the process of compiling the image file-"pasting would not give a valid
preprocessing token"
that the mount command fails.
Any kind of suggestions are appreciated..

-Jie


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

Re: Kernel 2.4.3 and new aic7xxx

[Jeff Garzik]

"Justin T. Gibbs" wrote:
> How often is the list manipulated?  My guess is not very often.

Modified very infrequently...  at boot, and for each hotplug insertion
or removal.  It's not even read very often.


> You can allow people to read the list without taking a spinlock and
> only acquire the spinlock on list manipulations.  Inserting an
> element can be performed atomically so there isn't an SMP issue
> so long as you don't allow more than one processor to insert at
> the same time.  This would allow you to perform insertion sort
> meaning that everything from /proc to device drivers auto-magically
> sees the devices in the order they were probed.

I was just thinking the same thing.  list_splice and an insertion sort
can be used instead of all that allocation crap.


> For hot plug devices
> you might want to insert them at the end to follow the "order probed"
> motif.

hmmm..  Is there a reason why this would be -needed-?  It wouldn't be
hard to implement, but I would rather not have drivers dealing with a
list whose normal state is defined as "mostly sorted"...

-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.18 IDE tape problem, with ide-scsi

[Camm Maguire]

Thank you again for your help.  While I do seem to get more errors
with the ide-tape driver, I am also seeing some problems on further
examination which are common to both ide-tape and st over ide-scsi, so
perhaps I have a bad drive or tape.

When trying to mt eom, for example, I get

=
st0: Error: 2800, cmd: 5 0 0 0 0 0 Len: 16
[valid=0] Info fld=0x0, Current st09:00: sns = 70  5
ASC=20 ASCQ= 0
Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 
0x00 0x00 
st0: Can't read block limits.
st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8
st0: Density 45, tape length: 0, drv buffer: 1
st0: Block size: 512, buffer size: 32768 (64 blocks).
st0: Retensioning tape.
st0: Error: 2800, cmd: 5 0 0 0 0 0 Len: 16
[valid=0] Info fld=0x0, Current st09:00: sns = 70  5
ASC=20 ASCQ= 0
Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 
0x00 0x00 
st0: Can't read block limits.
st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8
st0: Density 45, tape length: 0, drv buffer: 1
st0: Block size: 512, buffer size: 32768 (64 blocks).
st0: Spacing tape forward over 16383 filemarks.
st0: Spacing to end of recorded medium.
st0: Error: 2800, cmd: 11 3 0 0 0 0 Len: 16
Info fld=0x3feb, Deferred st09:00: sns = f1  3
ASC=11 ASCQ= 3
Raw sense data:0xf1 0x00 0x03 0x00 0x00 0x3f 0xeb 0x0a 0x00 0x00 0x00 0x00 0x11 0x03 
0x00 0x00 
st0: Error: 2800, cmd: 5 0 0 0 0 0 Len: 16
[valid=0] Info fld=0x0, Current st09:00: sns = 70  5
ASC=20 ASCQ= 0
Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x00 0x00 0x00 0x20 0x00 
0x00 0x00 
st0: Can't read block limits.
st0: Mode sense. Length 11, medium b6, WBS 10, BLL 8
st0: Density 45, tape length: 0, drv buffer: 1
st0: Block size: 512, buffer size: 32768 (64 blocks).
st0: Rewinding tape.
=

What is the 11,3?  Where can I find these codes listed?  Why is the
drive having trouble finding the end of the tape?  I'll be testing
more tapes soon, but this definitely happens with at least several.
The mt command returned to the prompt with 'Input/ouput error'.

Many Thanks again,

Khalid Aziz <[EMAIL PROTECTED]> writes:

> Camm Maguire wrote:
> > 
> > Greetings!  OK, with st debugging, here are the most common errors
> > with the Conner:
> > 
> > Feb 27 14:46:39 intech9 kernel: st0: Error: 2800, cmd: 8 1 0 0 40 0 Len: 16
> > Feb 27 14:46:39 intech9 kernel: Info fld=0x24, Current st09:00: sns = f0  8
> > Feb 27 14:46:39 intech9 kernel: ASC=14 ASCQ= 3
> > Feb 27 14:46:39 intech9 kernel: Raw sense data:0xf0 0x00 0x08 0x00 0x00 0x00 0x24 
>0x0a 0x00 0x00 0x00 0x00 0x14 0x03 0x00 0x00
> > Feb 27 14:46:39 intech9 kernel: st0: Sense: f0  0  8  0  0  0 24  a
> > Feb 27 14:46:39 intech9 kernel: st0: Tape error while reading.
> 
> This was a read command that failed. Request sense information shows a
> sense key of 0x08 which is a "Blank check". This sense key indicates
> either a blank medium found or another error at EOD. ASC/ASCQ of
> 0x14/0x03 say "End-Of-Data not found". This indicates something wrong
> with the tape or maybe the drive needs cleaning. Do you get this error
> with more than one tape?
> 
> 
> > Feb 27 14:46:40 intech9 kernel: st0: Error: 2800, cmd: 5 0 0 0 0 0 Len: 16
> > Feb 27 14:46:40 intech9 kernel: [valid=0] Info fld=0x0, Current st09:00: sns = 70  
>5
> > Feb 27 14:46:40 intech9 kernel: ASC=20 ASCQ= 0
> > Feb 27 14:46:40 intech9 kernel: Raw sense data:0x70 0x00 0x05 0x00 0x00 0x00 0x00 
>0x0a 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00
> > Feb 27 14:46:40 intech9 kernel: st0: Can't read block limits.
> 
> This was a "Read Block Limits" command which the drive claimed it does
> not recognize. "Read Block Limits" is a mandatory command for SCSI
> sequential access devices which is why "st" is issuing this command. The
> tape drive you have is not SCSI, so the manufacturer chose not to
> implement this command. The driver may still be able to work after "Read
> Block Limits" fails, but I have not read enough code to be sure.
> 
> > Feb 27 14:46:40 intech9 kernel: st0: Mode sense. Length 11, medium b6, WBS 10, BLL 
>8
> > Feb 27 14:46:40 intech9 kernel: st0: Density 45, tape length: 0, drv buffer: 1
> > Feb 27 14:46:40 intech9 kernel: st0: Block size: 512, buffer size: 32768 (64 
>blocks).
> > 
> > Any advice appreciated!
> 
> 
> Khalid Aziz Linux Development Laboratory
> (970)898-9214Hewlett-Packard
> [EMAIL PROTECTED]Fort Collins, CO
> 
> 

-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah
-
To 

Re: Kernel 2.4.3 and new aic7xxx

[Justin T. Gibbs]

>I would prefer to sort the list at probe not boot time.  That makes it
>easy to reverse the order on the fly, depending on what the driver
>requests at runtime.  It's SMP-friendly, because I can grab a private
>copy of the PCI device list, sort it, and scan it.  You don't have to
>re-sort at every pci_insert_device, for hotplug machines.  The only
>potential downside is I need to check and see if the bootmem case needs
>to be handled, when making a private copy of the pci devices list for
>sorting.

How often is the list manipulated?  My guess is not very often.
You can allow people to read the list without taking a spinlock and
only acquire the spinlock on list manipulations.  Inserting an
element can be performed atomically so there isn't an SMP issue
so long as you don't allow more than one processor to insert at
the same time.  This would allow you to perform insertion sort
meaning that everything from /proc to device drivers auto-magically
sees the devices in the order they were probed.  For hot plug devices
you might want to insert them at the end to follow the "order probed"
motif.

--
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: Microsoft ZERO Sector Virus, Result of Taskfile WAR

[Craig Ruff]

On Wed, Mar 07, 2001 at 02:35:56PM -0800, Andre Hedrick wrote:
> So basically you are pointing out that there is now a sequencer reject in
> linux?  Because this used to effect and wipe drives, but you are showing
> that Linux now does scsi commands check for execution on the /dev/sdxx?

Nope, there is a "sequencer reject" is not present.  SCSI drives do not store
sensitive, driver controller private, information in a user accessible
location.

Now, it may be possible to really mess up a drive with the write buffer
command to attempt to download new firmware.  One hopes that the
manufacturers include some sanity checking to prevent short firmware
writes, bad checksum, etc from rendering the drive useless.

Typically what happens is that the user confuses a partition table overwrite
with the drive having been rendered useless.  Of course, there is always
a chance for firmware bugs, but I've never been bit by one.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Forcible removal of modules

[Alan Cox]

> For PCI drivers, you implement the ::suspend and ::remove hooks.
> > I have a race free version of pm_send_all if you want it.
> Is this the same thing that is in 2.4.3-pre3?

Mine is race free for the basics, his is a far far more elegant solution to the
whole problem space. It might be 2.5 stuff but its definitely a good idea

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

Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR

[Andre Hedrick]

So basically you are pointing out that there is now a sequencer reject in
linux?  Because this used to effect and wipe drives, but you are showing
that Linux now does scsi commands check for execution on the /dev/sdxx?

On Wed, 7 Mar 2001, Craig Ruff wrote:

> On Wed, Mar 07, 2001 at 01:15:46PM -0800, Andre Hedrick wrote:
> > 
> > Then run this and see if you live.
> 
> Well, I ran it, the disk lives.  The typescript is appended below.
> Interestingly, scsikiller didn't cream the partition table like I
> expected.  However the dd if=/dev/zero of=/dev/sdc certainly did.
> 
> I've been using dd to copy entire disks for 18 years.  Not just SCSI,
> but SMD, IPI and IDE.  I've never had a problem with multi-sector writes
> starting at any sector on drives.  Unless there is a bug in the
> drive's firmware, about the only thing you can do software wise to
> a SCSI disk is to interrupt a format command, which can leave things
> messed up a bit until the next format.
> 
> 
> Script started on Wed Mar  7 14:55:00 2001
> bells# fdisk /dev/sdc
> 
> Command (m for help): p
> 
> Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
> Units = cylinders of 16065 * 512 bytes
> 
>Device BootStart   EndBlocks   Id  System
> /dev/sdc1 1   553   4441941   83  Linux
> 
> Command (m for help): q
> 
> bells# dd if=/dev/sdc of=sdc.part bs=512 count=1
> 1+0 records in
> 1+0 records out
> bells# cat scsikiller.c
> /* scsikiller.c */
> #include 
> #include 
> #include 
> 
> struct cdb6hdr{
>   unsigned int inbufsize;
>   unsigned int outbufsize;
>   unsigned char cdb [6];
> } __attribute__ ((packed));
> 
> int main (int argv, char **argc)
> {
>   int fd;
>   unsigned char tBuf[526];
>   struct cdb6hdr *ioctlhdr;
> 
>   if (argv != 2) exit(-1);
>   
>   fd = open (*(argc+1), O_RDWR );
>   if (fd < 0) exit (-1);
> 
>   memset(, 0, 526);
>   
>   ioctlhdr = (struct cdb6hdr *) 
>   
>   ioctlhdr->inbufsize = 512;
>   ioctlhdr->outbufsize = 0;
>   ioctlhdr->cdb[0] = WRITE_6;
>   ioctlhdr->cdb[4] = 1;
>   
>   return ioctl(fd, 1, );
> }
> bells# cc -o scsikiller scsikiller.c
> bells# scsikiller /dev/sdc
> bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
> 100+0 records in
> 100+0 records out
> bells# fdisk /dev/sdc
> 
> Command (m for help): p
> 
> Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
> Units = cylinders of 16065 * 512 bytes
> 
>Device BootStart   EndBlocks   Id  System
> /dev/sdc1 1   553   4441941   83  Linux
> 
> Command (m for help): q
> 
> bells# dd if=sdc.part of=/dev/sdc
> 1+0 records in
> 1+0 records out
> bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
> 100+0 records in
> 100+0 records out
> bells# dd if=/dev/zero of=/dev/sc bs=512 count=100
 ^^
I assume typo ??

> 100+0 records in
> 100+0 records out
> bells# fdisk /dev/sdc
> Device contains neither a valid DOS partition table, nor Sun or SGI disklabel
> Building a new DOS disklabel. Changes will remain in memory only,
> until you decide to write them. After that, of course, the previous
> content won't be recoverable.
> 
> 
> Command (m for help): q
> 
> bells# dd if=sdc.part of=/dev/sdc
> 1+0 records in
> 1+0 records out
> bells# fdisk /dev/sdc
> 
> Command (m for help): p
> 
> Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
> Units = cylinders of 16065 * 512 bytes
> 
>Device BootStart   EndBlocks   Id  System
> /dev/sdc1 1   553   4441941   83  Linux
> 
> Command (m for help): q
> 
> bells# ^Dexit
> 
> Script done on Wed Mar  7 14:57:35 2001
> 

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/

[PATCH] documentation for mm.h

[Rik van Riel]

Hi,

I've taken today to write some documentation for
include/linux/mm.h, as used in 2.4.x

Tonight and tomorrow I'll work on the documentation of other
files. Corrections, improvements and additions to this patch
are requested, lets try to get our stuff documented...

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

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/



--- mm.h.orig   Wed Mar  7 15:36:32 2001
+++ mm.hWed Mar  7 19:30:44 2001
@@ -39,32 +39,37 @@
  * library, the executable area etc).
  */
 struct vm_area_struct {
-   struct mm_struct * vm_mm;   /* VM area parameters */
-   unsigned long vm_start;
-   unsigned long vm_end;
+   struct mm_struct * vm_mm;   /* The address space we belong to. */
+   unsigned long vm_start; /* Our start address within vm_mm. */
+   unsigned long vm_end;   /* Our end address within vm_mm. */

/* linked list of VM areas per task, sorted by address */
struct vm_area_struct *vm_next;

-   pgprot_t vm_page_prot;
-   unsigned long vm_flags;
+   pgprot_t vm_page_prot;  /* Access permissions of this VMA. */
+   unsigned long vm_flags; /* Flags, listed below. */

/* AVL tree of VM areas per task, sorted by address */
short vm_avl_height;
struct vm_area_struct * vm_avl_left;
struct vm_area_struct * vm_avl_right;

-   /* For areas with an address space and backing store,
+   /*
+* For areas with an address space and backing store,
 * one of the address_space->i_mmap{,shared} lists,
 * for shm areas, the list of attaches, otherwise unused.
 */
struct vm_area_struct *vm_next_share;
struct vm_area_struct **vm_pprev_share;

+   /* Function pointers to deal with this struct. */
struct vm_operations_struct * vm_ops;
-   unsigned long vm_pgoff; /* offset in PAGE_SIZE units, *not* 
PAGE_CACHE_SIZE */
-   struct file * vm_file;
-   unsigned long vm_raend;
+
+   /* Information about our backing store: */
+   unsigned long vm_pgoff; /* Offset (within vm_file) in PAGE_SIZE
+  units, *not* PAGE_CACHE_SIZE */
+   struct file * vm_file;  /* File we map to (can be NULL). */
+   unsigned long vm_raend; /* XXX: put full readahead info here. */
void * vm_private_data; /* was vm_pte (shared mem) */
 };

@@ -90,6 +95,7 @@
 #define VM_LOCKED  0x2000
 #define VM_IO   0x4000 /* Memory mapped I/O or similar */

+   /* Used by sys_madvise() */
 #define VM_SEQ_READ0x8000  /* App will access data sequentially */
 #define VM_RAND_READ   0x0001  /* App will not benefit from clustered reads */

@@ -124,37 +130,144 @@
 };

 /*
+ * Each physical page in the system has a struct page associated with
+ * it to keep track of whatever it is we are using the page for at the
+ * moment. Note that we have no way to track which tasks are using
+ * a page.
+ *
  * Try to keep the most commonly accessed fields in single cache lines
  * here (16 bytes or greater).  This ordering should be particularly
  * beneficial on 32-bit processors.
  *
  * The first line is data used in page cache lookup, the second line
  * is used for linear searches (eg. clock algorithm scans).
+ *
+ * TODO: make this structure smaller, it could be as small as 32 bytes.
  */
 typedef struct page {
-   struct list_head list;
-   struct address_space *mapping;
-   unsigned long index;
-   struct page *next_hash;
-   atomic_t count;
-   unsigned long flags;/* atomic flags, some possibly updated asynchronously 
*/
-   struct list_head lru;
-   unsigned long age;
-   wait_queue_head_t wait;
-   struct page **pprev_hash;
-   struct buffer_head * buffers;
-   void *virtual; /* non-NULL if kmapped */
-   struct zone_struct *zone;
+   struct list_head list;  /* ->mapping has some page lists. */
+   struct address_space *mapping;  /* The inode (or ...) we belong to. */
+   unsigned long index;/* Our offset within mapping. */
+   struct page *next_hash; /* Next page sharing our hash bucket in
+  the pagecache hash table. */
+   atomic_t count; /* Usage count, see below. */
+   unsigned long flags;/* atomic flags, some possibly
+  updated asynchronously */
+   struct list_head lru;   /* Pageout list, eg. active_list;
+  protected by pagemap_lru_lock !! */
+   unsigned long age;  /* Page aging counter. */
+   

Re: can't read DVD (under 2.4.[12] & 2.2.17)

[Jens Axboe]

On Wed, Mar 07 2001, Jens Axboe wrote:
> On Wed, Mar 07 2001, Jens Axboe wrote:
> > Really good question, I sent this patch in the private thread between
> > me and Pozsar just in case the length is what the drive complains about.
> 
> Agrh, that's not all. I will fix this properly, sorry about the noise.

This should work. Pozsar, could you test?

I suspect that Derik is right though, that the 05/24/00 is because
the dvdinfo is requesting info for a non-existant physical layer.
I've attempted to quiet that error. You dvdinfo output did look
very odd.

-- 
Jens Axboe



--- /opt/kernel/linux-2.4.3-pre3/drivers/cdrom/cdrom.c  Thu Feb 22 14:55:22 2001
+++ drivers/cdrom/cdrom.c   Wed Mar  7 23:25:52 2001
@@ -1171,42 +1171,50 @@
 
 static int dvd_read_physical(struct cdrom_device_info *cdi, dvd_struct *s)
 {
-   int ret, i;
-   u_char buf[4 + 4 * 20], *base;
+   unsigned char buf[20], *base;
struct dvd_layer *layer;
struct cdrom_generic_command cgc;
struct cdrom_device_ops *cdo = cdi->ops;
+   int ret, layer_num = s->physical.layer_num;
+
+   if (layer_num >= DVD_LAYERS)
+   return -EINVAL;
 
init_cdrom_command(, buf, sizeof(buf), CGC_DATA_READ);
cgc.cmd[0] = GPCMD_READ_DVD_STRUCTURE;
-   cgc.cmd[6] = s->physical.layer_num;
+   cgc.cmd[6] = layer_num;
cgc.cmd[7] = s->type;
cgc.cmd[9] = cgc.buflen & 0xff;
 
+   /*
+* refrain from reporting errors on non-existing layers (mainly)
+*/
+   cgc.quiet = 1;
+
if ((ret = cdo->generic_packet(cdi, )))
return ret;
 
base = [4];
-   layer = >physical.layer[0];
+   layer = >physical.layer[layer_num];
 
-   /* place the data... really ugly, but at least we won't have to
-  worry about endianess in userspace or here. */
-   for (i = 0; i < 4; ++i, base += 20, ++layer) {
-   memset(layer, 0, sizeof(*layer));
-   layer->book_version = base[0] & 0xf;
-   layer->book_type = base[0] >> 4;
-   layer->min_rate = base[1] & 0xf;
-   layer->disc_size = base[1] >> 4;
-   layer->layer_type = base[2] & 0xf;
-   layer->track_path = (base[2] >> 4) & 1;
-   layer->nlayers = (base[2] >> 5) & 3;
-   layer->track_density = base[3] & 0xf;
-   layer->linear_density = base[3] >> 4;
-   layer->start_sector = base[5] << 16 | base[6] << 8 | base[7];
-   layer->end_sector = base[9] << 16 | base[10] << 8 | base[11];
-   layer->end_sector_l0 = base[13] << 16 | base[14] << 8 | base[15];
-   layer->bca = base[16] >> 7;
-   }
+   /*
+* place the data... really ugly, but at least we won't have to
+* worry about endianess in userspace.
+*/
+   memset(layer, 0, sizeof(*layer));
+   layer->book_version = base[0] & 0xf;
+   layer->book_type = base[0] >> 4;
+   layer->min_rate = base[1] & 0xf;
+   layer->disc_size = base[1] >> 4;
+   layer->layer_type = base[2] & 0xf;
+   layer->track_path = (base[2] >> 4) & 1;
+   layer->nlayers = (base[2] >> 5) & 3;
+   layer->track_density = base[3] & 0xf;
+   layer->linear_density = base[3] >> 4;
+   layer->start_sector = base[5] << 16 | base[6] << 8 | base[7];
+   layer->end_sector = base[9] << 16 | base[10] << 8 | base[11];
+   layer->end_sector_l0 = base[13] << 16 | base[14] << 8 | base[15];
+   layer->bca = base[16] >> 7;
 
return 0;
 }
--- /opt/kernel/linux-2.4.3-pre3/include/linux/cdrom.h  Tue Jan 30 08:24:56 2001
+++ include/linux/cdrom.h   Wed Mar  7 23:00:07 2001
@@ -524,10 +524,12 @@
__u32 end_sector_l0;
 };
 
+#define DVD_LAYERS 4
+
 struct dvd_physical {
__u8 type;
__u8 layer_num;
-   struct dvd_layer layer[4];
+   struct dvd_layer layer[DVD_LAYERS];
 };
 
 struct dvd_copyright {

Re: [PATCH] RFC: fix ethernet device initialization

[Jeff Garzik]

Jeff Garzik wrote:
> Our API already supports a solution -- setup the device, then call
> register_netdev.  The patch below adds a helper, alloc_etherdev, to
> eliminate duplicate code in drivers.  Ethernet device initialization,
> after the patch, should now look like
> 
> dev = alloc_etherdev(sizeof(struct netdev_private));
> ... initialize device ...
> ... set up net_device struct members ...
> rc = register_netdevice(dev);
> if (rc) /* handle error */
> netif_start_queue(dev);

Think-o in my example:  netif_start_queue occurs in dev->open(), not in
the probe phase.  Simply ignore that line in the example and you are ok.

Jeff


-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR

[Andries . Brouwer]

Andre Hedrick writes:

> That is not the case Joanne is pointing out.
> The SCSI low-level format glue performed by the HOST gets destroyed
> If you write to LBA Zero.  ATA only suffers the lose of the partition
> table and that can be recovered, but SCSI needs that information to know
> where everything else is on the drive.

Joanne Dow wrote:

> > Jens, and others, I have noted a very simple data killer technique that
> > at LEAST works on Quantum SCSI drives as of a couple years ago and some
> > other earlier drives I felt could be sacrificed to the test. You can write
> > as many blocks at once as SCSI supports to the drive as long as you do
> > *NOT* start at block zero. If you write more than 1 block to block zero
> > the drive becomes unformatted. The only recovery is to reformat the
> > drive. The data on the drive is lost for good.

Hm, it is not yet April 1st.
But then, Joanne keeps pet dragons, I believe.
Perhaps writing to sector 0 of a SCSI drive is harmless
in case one does not keep such animals?

Andries

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

Re: kernel lock contention and scalability

[Tim Wright]

On Tue, Mar 06, 2001 at 10:12:17PM -0500, Jeff Dike wrote:
> [EMAIL PROTECTED] said:
> > If you're a UP system, it never makes sense to spin in userland, since
> > you'll just burn up a timeslice and prevent the lock holder from
> > running. I haven't looked, but assume that their code only uses
> > spinlocks on SMP. If you're an SMP system, then you shouldn't be using
> > a spinlock unless the critical section is "short", in which case the
> > waiters should simply spin in userland rather than making system calls
> > which is simply overhead.
> 
> This is a problem that UML is going to have when I turn SMP back on.  
> Emulating a multiprocessor box on a UP host with the existing locking 
> primitives is going to result in exactly this problem.
> 

Yes. On a uniprocessor system, a simple fallback is to just use a semaphore
instead of a spinlock, since you can guarantee that there's no point in
scheduling the current task until the holder of the "lock" releases it.
Otherwise, the spin calling sched_yield() each iteration isn't too horrible.

> > Actually, what's really needed here is an efficient form of
> > dynamically marking a process as non-preemptible so that when
> > acquiring a spinlock the process can ensure that it exits the critical
> > section as fast as possible, when it would relinquish its
> > non-preemptible privilege.
> 
> That sounds like a pretty fundamental (and abusable) mechanism.
> 

It would be if it were generally available. The implementation on DYNIX/ptx
requires a privilege (PRIV_SCHED IIRC), to be able to use it. It was added
for a database to prevent preemption during critical sections.

> I had a suggestion from an IBM guy at ALS last year to make UML "spin"-locks 
> actually sleep in the host (this doesn't make them sleep locks in userspace 
> because they don't call schedule), which sounds reasonable.  This gives the 
> lock-holder an opportunity to run immediately.  It's unclear to me what the 
> wake-up mechanism would be, though.
> 

Hmmm.. depends what you mean by sleep i.e sleep(3) vs. making a system call
that sleeps. I would have thought the latter, and use semaphores again.

> Another thought I had was to raise the priority of a thread holding a 
> spinlock.  This would reduce the chance that it would be preempted by a thread 
> that will waste a timeslice spinning on that lock.  I don't know whether this 
> is a good idea either.
> 

That's basically a weaker version of the no-preempt. Not a bad idea, but
less than optimal :-)

Regards,

Tim

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR

[Craig Ruff]

On Wed, Mar 07, 2001 at 01:15:46PM -0800, Andre Hedrick wrote:
> 
> Then run this and see if you live.

Well, I ran it, the disk lives.  The typescript is appended below.
Interestingly, scsikiller didn't cream the partition table like I
expected.  However the dd if=/dev/zero of=/dev/sdc certainly did.

I've been using dd to copy entire disks for 18 years.  Not just SCSI,
but SMD, IPI and IDE.  I've never had a problem with multi-sector writes
starting at any sector on drives.  Unless there is a bug in the
drive's firmware, about the only thing you can do software wise to
a SCSI disk is to interrupt a format command, which can leave things
messed up a bit until the next format.


Script started on Wed Mar  7 14:55:00 2001
bells# fdisk /dev/sdc

Command (m for help): p

Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes

   Device BootStart   EndBlocks   Id  System
/dev/sdc1 1   553   4441941   83  Linux

Command (m for help): q

bells# dd if=/dev/sdc of=sdc.part bs=512 count=1
1+0 records in
1+0 records out
bells# cat scsikiller.c
/* scsikiller.c */
#include 
#include 
#include 

struct cdb6hdr{
unsigned int inbufsize;
unsigned int outbufsize;
unsigned char cdb [6];
} __attribute__ ((packed));

int main (int argv, char **argc)
{
int fd;
unsigned char tBuf[526];
struct cdb6hdr *ioctlhdr;

if (argv != 2) exit(-1);

fd = open (*(argc+1), O_RDWR );
if (fd < 0) exit (-1);

memset(, 0, 526);
  
ioctlhdr = (struct cdb6hdr *) 
  
ioctlhdr->inbufsize = 512;
ioctlhdr->outbufsize = 0;
ioctlhdr->cdb[0] = WRITE_6;
ioctlhdr->cdb[4] = 1;
  
return ioctl(fd, 1, );
}
bells# cc -o scsikiller scsikiller.c
bells# scsikiller /dev/sdc
bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
100+0 records in
100+0 records out
bells# fdisk /dev/sdc

Command (m for help): p

Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes

   Device BootStart   EndBlocks   Id  System
/dev/sdc1 1   553   4441941   83  Linux

Command (m for help): q

bells# dd if=sdc.part of=/dev/sdc
1+0 records in
1+0 records out
bells# dd if=/dev/sdc of=/dev/null bs=512 count=100
100+0 records in
100+0 records out
bells# dd if=/dev/zero of=/dev/sc bs=512 count=100
100+0 records in
100+0 records out
bells# fdisk /dev/sdc
Device contains neither a valid DOS partition table, nor Sun or SGI disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.


Command (m for help): q

bells# dd if=sdc.part of=/dev/sdc
1+0 records in
1+0 records out
bells# fdisk /dev/sdc

Command (m for help): p

Disk /dev/sdc: 255 heads, 63 sectors, 553 cylinders
Units = cylinders of 16065 * 512 bytes

   Device BootStart   EndBlocks   Id  System
/dev/sdc1 1   553   4441941   83  Linux

Command (m for help): q

bells# ^Dexit

Script done on Wed Mar  7 14:57:35 2001
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ncpfs: d_add + ncp_d_validate fixes

[Alexander Viro]

On Wed, 7 Mar 2001, Petr Vandrovec wrote:

> Hi Linus, hi Alan,
>   could you apply following patch into 2.4.2-ac14 and 2.4.3-pre4?
> It does:
> 
>last three hunks: do not d_add() already hashed dentry.
>  It is fix for problem discovered by Urban
>  in his smbfs. Probably it is more utilized
>  than ncpfs...
>rest: moved test for dentry->d_parent != parent before
>  call to d_validate(), instead of doing
>  it in caller after ncp_d_validate() returns.
>  Al Viro asked for this some time ago, but
>  it somewhat did not found its way into 
>  mainstream kernel yet...
>  While I was on it, I changed ncp_d_validate
>  layout a bit to get shorter code.

Petr, while you are at it, care to merge the following patch? It cleans up
both SMBFS and NCPFS side of this business and removes crap from
dcache.c. It's against vanilla 2.4.2, but it should apply at least to
2.4.3-pre2 - none of the relevant areas are affected.
Cheers,
Al

diff -urN S2/fs/dcache.c S2-d_validate/fs/dcache.c
--- S2/fs/dcache.c  Thu Feb 22 06:45:12 2001
+++ S2-d_validate/fs/dcache.c   Wed Mar  7 16:57:45 2001
@@ -744,57 +744,48 @@
 
 /**
  * d_validate - verify dentry provided from insecure source
- * @dentry: The dentry alleged to be valid
- * @dparent: The parent dentry
+ * @dentry: The dentry alleged to be valid child of @dparent
+ * @dparent: The parent dentry (known to be valid)
  * @hash: Hash of the dentry
  * @len: Length of the name
  *
  * An insecure source has sent us a dentry, here we verify it and dget() it.
  * This is used by ncpfs in its readdir implementation.
  * Zero is returned in the dentry is invalid.
- *
- * NOTE: This function does _not_ dereference the pointers before we have
- * validated them. We can test the pointer values, but we
- * must not actually use them until we have found a valid
- * copy of the pointer in kernel space..
  */
  
-int d_validate(struct dentry *dentry, struct dentry *dparent,
-  unsigned int hash, unsigned int len)
+int d_validate(struct dentry *dentry, struct dentry *dparent)
 {
+   unsigned long dent_addr = (unsigned long) dentry;
+   unsigned long min_addr = PAGE_OFFSET;
+   unsigned long align_mask = 0x0F;
struct list_head *base, *lhp;
-   int valid = 1;
+   int valid = 0;
 
-   spin_lock(_lock);
-   if (dentry != dparent) {
-   base = d_hash(dparent, hash);
-   lhp = base;
-   while ((lhp = lhp->next) != base) {
-   if (dentry == list_entry(lhp, struct dentry, d_hash)) {
-   __dget_locked(dentry);
-   goto out;
-   }
-   }
-   } else {
-   /*
-* Special case: local mount points don't live in
-* the hashes, so we search the super blocks.
-*/
-   struct super_block *sb = sb_entry(super_blocks.next);
+   if (dent_addr < min_addr)
+   goto out;
+   if (dent_addr > (unsigned long)high_memory - sizeof(struct dentry))
+   goto out;
+   if ((dent_addr & ~align_mask) != dent_addr)
+   goto out;
+   if ((!kern_addr_valid(dent_addr)) || (!kern_addr_valid(dent_addr -1 +
+   sizeof(struct dentry
+   goto out;
+
+   if (dentry->d_parent != dparent)
+   goto out;
 
-   for (; sb != sb_entry(_blocks); 
-sb = sb_entry(sb->s_list.next)) {
-   if (!sb->s_dev)
-   continue;
-   if (sb->s_root == dentry) {
-   __dget_locked(dentry);
-   goto out;
-   }
+   spin_lock(_lock);
+   lhp = base = d_hash(dparent, dentry->d_name.hash);
+   while ((lhp = lhp->next) != base) {
+   if (dentry == list_entry(lhp, struct dentry, d_hash)) {
+   valid = 1;
+   __dget_locked(dentry);
+   break;
}
}
-   valid = 0;
-out:
spin_unlock(_lock);
+out:
return valid;
 }
 
diff -urN S2/fs/ncpfs/dir.c S2-d_validate/fs/ncpfs/dir.c
--- S2/fs/ncpfs/dir.c   Fri Feb 16 22:52:07 2001
+++ S2-d_validate/fs/ncpfs/dir.cWed Mar  7 16:58:11 2001
@@ -326,55 +326,14 @@
return res;
 }
 
-/* most parts from nfsd_d_validate() */
-static int
-ncp_d_validate(struct dentry *dentry)
-{
-   unsigned long dent_addr = (unsigned long) dentry;
-   unsigned long min_addr = PAGE_OFFSET;
-   unsigned long align_mask = 

Re: Kernel 2.4.3 and new aic7xxx

[Jeff Garzik]

Linus Torvalds wrote:
> I suspect it's easier to just make the PCI layer call the probe function
> in that order, instead of working around it in your driver.

That seems like a really good idea, especially in light of the fact that
some drivers are doing (have to do?) -reverse- order PCI scanning.

I would prefer to sort the list at probe not boot time.  That makes it
easy to reverse the order on the fly, depending on what the driver
requests at runtime.  It's SMP-friendly, because I can grab a private
copy of the PCI device list, sort it, and scan it.  You don't have to
re-sort at every pci_insert_device, for hotplug machines.  The only
potential downside is I need to check and see if the bootmem case needs
to be handled, when making a private copy of the pci devices list for
sorting.

-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel crash during resync of raid5 on SMP

[Neil Brown]

On Wednesday March 7, [EMAIL PROTECTED] wrote:
> I run a Dual prozessor SMP system on 2.4.2-ac12 for a while
> in degraded mode. Today I put in a new disk to switch to
> full raid5 mode. Shortly after the command raidhotadd  the 
> system crashed with the message lost interrupt on cpu1.

Was there an Oops? Can we see? decoded with ksymoops of course.
Are you happy to retry? (i.e. raidsetfaulty; raidhotremove,
raidhotadd).  If so, Could you try with 2.4.2?

Where abouts in the sync-process did it die?  Start? end? middle?
various?

NeilBrown


> 
> This continued after reboot. I finaly managed to get it running again
> by booting with kernel parameter maxcpus=1. In this one CPU mode
> it finished resycing. 
> 
> During this process I was never able to resync with two CPU's.
> 
> After finishing rescyncing the system run now fine in SMP Dual mode again.
> 
> Perhaps there might be an issue with spinlocks during resyncing.
> 
> Bye Otto
> 
> 
> 
> 
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]

Re: Q. about oops backtrace

[Urban Widmark]

On Wed, 7 Mar 2001, Pete Zaitcev wrote:

> Trace; c0127414 
> Trace; c0136a2d 
> Trace; c012722e 
> Trace; c0127290 
> Trace; c0127414 
> Trace; c014cdec 
> Trace; c0143f80 
> Trace; c0144aae 
> Trace; c014cdec 
> Trace; c01392c9 
> Trace; c0138130 
> Trace; c013805d 
> Trace; c0148b97 
> Trace; c01091c7 
> 
> What is with those recursive handle_mm_fault calls?

Unless I'm mistaken the call trace in an i386 oops is printed by
arch/i386/kernel/traps.c:show_trace()

And it simply prints any value within certain limits.
if (((addr >= (unsigned long) &_stext) &&
 (addr <= (unsigned long) &_etext)) ||
((addr >= module_start) && (addr <= module_end))) {
/* ... print it ... */

If a function is passed as a parameter it will of course be on the stack,
even when it isn't a return value.

The dput entries are strange too, does dput call path_walk?
(is the translation from numbers to symbols correct?)

/Urban

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

[Petr Vandrovec]

Hi Alan,
   if you are going to apply patch I saw today morning on linux-kernel
to disable redzoning on SLAB_HWCACHE aligned areas, drop this one into
wastebasket.
   If not, please apply this. When CONFIG_DEBUG_SLAB is enbled,
dentries do not live on 16bytes boundary, but on x*8 + 4 :-( So I
can validate only two low bits.
   This patch is for 2.4.2-ac13 with applied patch I sent just few
minutes ago.
   Urban's smbfs has same problem, as it uses almost same validate
code...
Thanks,
Petr Vandrovec
[EMAIL PROTECTED]


--- linux/fs/ncpfs/dir.cWed Mar  7 22:40:12 2001
+++ linux/fs/ncpfs/dir.cWed Mar  7 21:09:36 2001
@@ -332,7 +332,11 @@
 {
unsigned long dent_addr = (unsigned long) dentry;
const unsigned long min_addr = PAGE_OFFSET;
+#ifdef CONFIG_DEBUG_SLAB
+   const unsigned long align_mask = 0x03;
+#else
const unsigned long align_mask = 0x0F;
+#endif
unsigned int len;
 
if (dent_addr < min_addr)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: can't read DVD (under 2.4.[12] & 2.2.17)

[Jens Axboe]

On Wed, Mar 07 2001, Jens Axboe wrote:
> Really good question, I sent this patch in the private thread between
> me and Pozsar just in case the length is what the drive complains about.

Agrh, that's not all. I will fix this properly, sorry about the noise.

-- 
Jens Axboe

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

[PATCH] ncpfs: d_add + ncp_d_validate fixes

[Petr Vandrovec]

Hi Linus, hi Alan,
  could you apply following patch into 2.4.2-ac14 and 2.4.3-pre4?
It does:

   last three hunks: do not d_add() already hashed dentry.
 It is fix for problem discovered by Urban
 in his smbfs. Probably it is more utilized
 than ncpfs...
   rest: moved test for dentry->d_parent != parent before
 call to d_validate(), instead of doing
 it in caller after ncp_d_validate() returns.
 Al Viro asked for this some time ago, but
 it somewhat did not found its way into 
 mainstream kernel yet...
 While I was on it, I changed ncp_d_validate
 layout a bit to get shorter code.

Thanks,
Petr Vandrovec
[EMAIL PROTECTED]



--- linux/fs/ncpfs/dir.cFri Feb  9 20:29:44 2001
+++ linux/fs/ncpfs/dir.cWed Mar  7 22:40:12 2001
@@ -328,19 +328,18 @@
 
 /* most parts from nfsd_d_validate() */
 static int
-ncp_d_validate(struct dentry *dentry)
+ncp_d_validate(struct dentry *dentry, struct dentry* parent)
 {
unsigned long dent_addr = (unsigned long) dentry;
-   unsigned long min_addr = PAGE_OFFSET;
-   unsigned long align_mask = 0x0F;
+   const unsigned long min_addr = PAGE_OFFSET;
+   const unsigned long align_mask = 0x0F;
unsigned int len;
-   int valid = 0;
 
if (dent_addr < min_addr)
goto bad_addr;
if (dent_addr > (unsigned long)high_memory - sizeof(struct dentry))
goto bad_addr;
-   if ((dent_addr & ~align_mask) != dent_addr)
+   if (dent_addr & align_mask)
goto bad_align;
if ((!kern_addr_valid(dent_addr)) || (!kern_addr_valid(dent_addr -1 +
sizeof(struct dentry
@@ -351,20 +350,21 @@
len = dentry->d_name.len;
if (len > NCP_MAXPATHLEN)
goto out;
+   if (dentry->d_parent != parent)
+   goto out;
/*
 * Note: d_validate doesn't dereference the parent pointer ...
 * just combines it with the name hash to find the hash chain.
 */
-   valid = d_validate(dentry, dentry->d_parent, dentry->d_name.hash, len);
-out:
-   return valid;
+   return d_validate(dentry, dentry->d_parent, dentry->d_name.hash, len);
 
 bad_addr:
PRINTK("ncp_d_validate: invalid address %lx\n", dent_addr);
goto out;
 bad_align:
PRINTK("ncp_d_validate: unaligned address %lx\n", dent_addr);
-   goto out;
+out:
+   return 0;
 }
 
 static struct dentry *
@@ -373,9 +373,8 @@
struct dentry *dent = dentry;
struct list_head *next;
 
-   if (ncp_d_validate(dent)) {
-   if (dent->d_parent == parent &&
-  (unsigned long)dent->d_fsdata == fpos) {
+   if (ncp_d_validate(dent, parent)) {
+   if ((unsigned long)dent->d_fsdata == fpos) {
if (!dent->d_inode) {
dput(dent);
dent = NULL;
@@ -580,6 +579,7 @@
struct ncp_cache_control ctl = *ctrl;
struct qstr qname;
int valid = 0;
+   int hashed = 0;
ino_t ino = 0;
__u8 __name[256];
 
@@ -602,9 +602,11 @@
newdent = d_alloc(dentry, );
if (!newdent)
goto end_advance;
-   } else
+   } else {
+   hashed = 1;
memcpy((char *) newdent->d_name.name, qname.name,
newdent->d_name.len);
+   }
 
if (!newdent->d_inode) {
entry->opened = 0;
@@ -612,7 +614,9 @@
newino = ncp_iget(inode->i_sb, entry);
if (newino) {
newdent->d_op = _dentry_operations;
-   d_add(newdent, newino);
+   d_instantiate(newdent, newino);
+   if (!hashed)
+   d_rehash(newdent);
}
} else
ncp_update_inode2(newdent->d_inode, entry);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: can't read DVD (under 2.4.[12] & 2.2.17)

[Jens Axboe]

On Wed, Mar 07 2001, Derek Fawcus wrote:
> > > hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
> > > hdd: packet command error: error=0x50
> > > ATAPI device hdd:
> > >   Error: Illegal request -- (Sense key=0x05)
> > >   Invalid field in command packet -- (asc=0x24, ascq=0x00)
> > >   The failed "Send DVD Structure" packet command was:
> > >   "ad 00 00 00 00 00 02 00 00 54 00 00 "
> > > Could not read Physical layer 2
> > > Copyright: CPST=1, RMI=0xfd
> > 
> > I don't know the program you mention, but it's definitely buggy. It
> > sets byte 6 to 0x02 which is not valid at all.
> 
> The program is attempting to read from the third layer!  Thats why it
> fails.  This value gets set from the .layer_num element supplied
> in the struct dvd_physical supplied to the ioctl call.
> 
> > Byte 7 is the format code, but 0x02 is reserved there too. Who wrote
> > this program? Tell him it's buggy, it's not the driver.
> 
> Originally me (a couple of years ago),  and I'm not supprised at it 
> being buggy,  it was a simple program to explore a couple of the
> ioctl calls.  I never got particularly sensible data from a multi-layer
> DVD (maybe the firmware in my drives is dodgy).

The report sense was buggy, and that fooled me. The cdb is not wrong
at all, apart from the length which you mention further on. It's a
READ_DVD_STRUCTURE command, not a SEND_DVD_STRUCTURE.

> the original code was something like:
> 
>   dvd_struct d;
>   int layer, layers = 4;
> 
>   d.physical.type = DVD_STRUCT_PHYSICAL;
> 
>   for (layer = 0; layer < layers; ++layer) {
> d.physical.layer_num = layer;
> 
> ioctl(fd, DVD_READ_STRUCT, );
> 
> printf("Layer %d[%d]\n", layer, layers);
> display data in d.physical.layer[layer]
> 
> layers = d.physical.layer[layer].nlayers + 1;
>   }

Much the same today, the program was forwarded to me ;-)

> The way I interpreted this API is that one requests the layer number to
> read the data from,  and that index in the array would be filled in with
> data.  However this seems a bit pointless - if only one layers worth of
> data will be returned at a time,  then why have an array of 4 entries?

Really good question, I sent this patch in the private thread between
me and Pozsar just in case the length is what the drive complains about.

-- 
Jens Axboe



--- /opt/kernel/linux-2.4.3-pre2/drivers/cdrom/cdrom.c  Thu Feb 22 14:55:22 2001
+++ drivers/cdrom/cdrom.c   Wed Mar  7 22:25:14 2001
@@ -1172,7 +1172,7 @@
 static int dvd_read_physical(struct cdrom_device_info *cdi, dvd_struct *s)
 {
int ret, i;
-   u_char buf[4 + 4 * 20], *base;
+   u_char buf[20], *base;
struct dvd_layer *layer;
struct cdrom_generic_command cgc;
struct cdrom_device_ops *cdo = cdi->ops;

Re: [PATCH] RFC: fix ethernet device initialization

[Arjan van de Ven]

In article <[EMAIL PROTECTED]> you wrote:
> This bug, which I fix, isn't causing oops AFAIK, just
> exporting ugliness to user space etc.

It CAN and IS causing oopses. init_etherdev() causes /sbin/hotplug to be
invoked, which in turn ifconfig up's the interface.
Several (if not all) drivers have an _up() function which cannot handle 
not-yet initialized device nodes.

Now we don't see this often as on UP systems, /sbin/hotplug is only started
_after_ the probe function either sleeps or exits, and 95% of the probe
functions don't sleep. (The ones that do are indeed reported to oops)
For SMP systems, I guess not that many have cardbus or other hotplug NICs

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

Re: can't read DVD (under 2.4.[12] & 2.2.17)

[Derek Fawcus]

On Wed, Mar 07, 2001 at 09:36:32PM +0100, Jens Axboe wrote:
> On Wed, Mar 07 2001, Pozsar Balazs wrote:
> > Details: (dmesg)
> > 
> > When I run "dvdinfo /dev/hdd" I get:
> > Disc is encrypted.
> > Layer 0[3]
> >  Num Layers: 2
> >  Start Sector0xd000
> >  End Sector  0xd000
> >  End Sector L0   0xd000

> > Layer 1[3]
> >  Num Layers: 2
> >  Start Sector0xd000
> >  End Sector  0x1d000
> >  End Sector L0   0xd000

> > hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
> > hdd: packet command error: error=0x50
> > ATAPI device hdd:
> >   Error: Illegal request -- (Sense key=0x05)
> >   Invalid field in command packet -- (asc=0x24, ascq=0x00)
> >   The failed "Send DVD Structure" packet command was:
> >   "ad 00 00 00 00 00 02 00 00 54 00 00 "
> > Could not read Physical layer 2
> > Copyright: CPST=1, RMI=0xfd
> 
> I don't know the program you mention, but it's definitely buggy. It
> sets byte 6 to 0x02 which is not valid at all.

The program is attempting to read from the third layer!  Thats why it
fails.  This value gets set from the .layer_num element supplied
in the struct dvd_physical supplied to the ioctl call.

> Byte 7 is the format code, but 0x02 is reserved there too. Who wrote
> this program? Tell him it's buggy, it's not the driver.

Originally me (a couple of years ago),  and I'm not supprised at it 
being buggy,  it was a simple program to explore a couple of the
ioctl calls.  I never got particularly sensible data from a multi-layer
DVD (maybe the firmware in my drives is dodgy).

the original code was something like:

  dvd_struct d;
  int layer, layers = 4;

  d.physical.type = DVD_STRUCT_PHYSICAL;

  for (layer = 0; layer < layers; ++layer) {
d.physical.layer_num = layer;

ioctl(fd, DVD_READ_STRUCT, );

printf("Layer %d[%d]\n", layer, layers);
display data in d.physical.layer[layer]

layers = d.physical.layer[layer].nlayers + 1;
  }

This was from observations of the data returned by my DVD drive,  where
the .nlayers was always returned as 0 or 1 for single or dual layer
discs,  and always as 0 for flippers.  Having a drive return the number
of layers as 2 doesn't agree with this.  Unless his drive is simply
returning 1 based numbers,  whereas mine returned 0 based numbers.

Actually I never forund the API especially sensible - this could just be
due to the data I saw back from my DVD drive.

The way I interpreted this API is that one requests the layer number to
read the data from,  and that index in the array would be filled in with
data.  However this seems a bit pointless - if only one layers worth of
data will be returned at a time,  then why have an array of 4 entries?

Or is it intended that you should be able to read identical data from
either layer (on either side).  That all layers on the disk would have
had this structure physically recorded identically,  and that for a
disk with n 'layers',  n elements of the array will be filled as
appropriate.

On my drive for array indicies > 0 the data in the structure elements
is always 0.  It also makes no difference which layer I read (assuming
that its actually dual layer),  the results of the 2 ioctl calls are
identical.

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

Kernel crash during resync of raid5 on SMP

[Otto Meier]

I run a Dual prozessor SMP system on 2.4.2-ac12 for a while
in degraded mode. Today I put in a new disk to switch to
full raid5 mode. Shortly after the command raidhotadd  the 
system crashed with the message lost interrupt on cpu1.

This continued after reboot. I finaly managed to get it running again
by booting with kernel parameter maxcpus=1. In this one CPU mode
it finished resycing. 

During this process I was never able to resync with two CPU's.

After finishing rescyncing the system run now fine in SMP Dual mode again.

Perhaps there might be an issue with spinlocks during resyncing.

Bye Otto







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

Re: Linux 2.4.2ac12 (vt82c686 info)

[John Heil]

On Wed, 7 Mar 2001, Vojtech Pavlik wrote:

> Date: Wed, 7 Mar 2001 20:14:37 +0100
> From: Vojtech Pavlik <[EMAIL PROTECTED]>
> To: George Garvey <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: Linux 2.4.2ac12 (vt82c686 info)
> 
> On Tue, Mar 06, 2001 at 05:05:46AM -0800, George Garvey wrote:
> > 
> > > No, just the vt82c686. vt82c686a and vt82c686b are OK.
> > 
> > So can the vt82c686 be replaced with one of these other chips? What
> > action is available to owners of MBs with chips that don't work w/Linux?
> 
> It can be replaced if you can desolder a 352 contact BGA chip. I don't
> know of anyone who does.
> 
> Also, the vt82c686 will work just fine with Linux, but will be limited
> to UDMA33, because UDMA66 on this chip does reliably fail.

Based on following the lkml threads on Via chipsets, it seems that
the 686a at or above rev 22, will run UDMA66 just fine.
Below that, lies the flakiness...
My Tyan based 686a rev 22 has been trouble free save a bad cable.

I just acquired a new 1.1G athlon on an asus a7v133. It has a 686b.
What should I expect w the 686b?  and is the Via 686b data sheet 
available somewhere? 

Thanx

> 
> Furthermore, these chips are very rare - I don't know anyone owning one.
> 
> -- 
> Vojtech Pavlik
> SuSE Labs
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
[EMAIL PROTECTED]
http://www.sc-software.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: Microsoft ZERO Sector Virus, Result of Taskfile WAR

[Richard B. Johnson]

On Wed, 7 Mar 2001, Andre Hedrick wrote:

> 
> Harvey,
> 
> That is not the case Joanne is pointing out.
> The SCSI low-level format glue performed by the HOST gets destroyed
> If you write to LBA Zero.  ATA only suffers the lose of the partition
> table and that can be recovered, but SCSI needs that information to know
> where everything else is on the drive.
> 
> You know I really do not care anymore that people can screw themselves,
> and that Linux has choosen the road of pure UNIX, user beware.  After the
> last battles, I encourge stupidity, because the no IOCTLS will require you
> know how to use the hardware rules completely, and if you compose the
> wrong command because you can not/will not understand the rules of IO and
> use the interface improperly, tough.
[SNIPPED...]

You can read/write/trash LBA zero all you want with SCSI. It contains
only user (your) data. The disk drive contains a RCT (reconstruction and
caching table). The entries in this are built up during the format-unit
command. If you interrupt the power at just the right instant during
a format-unit, you can corrupt this table and make the drive unusable.

It is highly unlikely that you'd be able to crowbar the supply at just
the right instant, even if you designed the drive and knew what it
was doing at every instance.

This is not something you could do with software. SCSI talks SCSI, there
are no SCSI commands that say "corrupt the RCT". So a virus, although
it can blow away all user data, and can initiate a format-unit command
(BIOS function code 7), can't get at anything that will disable
the drive.

That said, the format-unit command takes some interesting parameters.
One of them is a defect list. It is possible to format the drive so
that all cylinders are "defective"!!  Of course this goes away when
you format the drive without such a defect list.


Cheers,
Dick Johnson

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

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


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

[PATCH] RFC: fix ethernet device initialization

[Jeff Garzik]

People from time to time point out a wart in ethernet initialization:

The net_device is allocated and registered to the system in
init_etherdev, which is usually one of the first things an ethernet
driver probe function does.  The net_device's final members are setup at
some time between then and the exit of the probe function.  There is
never a clear point where the net device is available to the system for
use.

Our API already supports a solution -- setup the device, then call
register_netdev.  The patch below adds a helper, alloc_etherdev, to
eliminate duplicate code in drivers.  Ethernet device initialization,
after the patch, should now look like

dev = alloc_etherdev(sizeof(struct netdev_private));
... initialize device ...
... set up net_device struct members ...
rc = register_netdevice(dev);
if (rc) /* handle error */
netif_start_queue(dev);

This makes the ethernet driver look and behave similar to other APIs in
the kernel, and presents a nice and atomic
present-this-netdev-to-the-system operation.

It should be noted that there is a net_device::init function.  IIRC in
the last discussion of this issue, ::init() was mentioned as a possible
solution.  I agree that init() can be used, but I do not like the idea
of using init as a probe function, as the ISA drivers do it.  This means
the ethernet device has the potential of holdling rtnl_lock for a long
time, and staying in the probe function, inside register_netdevice, for
a long time.  And...  I agree that init() can be used as a constructor
for filling in dev->xxx and dev->priv->xxx values, but I think doing so
is pointless: you must fill in certain values before your "constructor"
is called, just so your constructor has enough information to operate.

Patch description:

* Add alloc_etherdev, alloc_trdev, alloc_hippi_dev, alloc_fcdev, ...
* Use declarator macros to create init_etherdev, init_trdev, etc., and
remove duplicate code.
* Move net_init EXPORT_SYMBOL from net/netsyms.c to net_init.c.
* Convert drivers/net/8139too.c to use alloc_etherdev, as an example.

Final word, mostly PCI drivers need this change.  ISA drivers use the
net_device::init constructor approach.  IMHO they shouldn't stay in
register_netdevice so long, but that is a wart.  This patch fixes a bug,
the huge span of time between init_etherdev and the indeterminant point
in the future when the net device is ready for use.

Comments?

-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie

Index: drivers/net/8139too.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/8139too.c,v
retrieving revision 1.1.1.29
diff -u -r1.1.1.29 8139too.c
--- drivers/net/8139too.c   2001/03/05 23:46:05 1.1.1.29
+++ drivers/net/8139too.c   2001/03/07 20:58:24
@@ -647,11 +647,43 @@
  (RX_DMA_BURST << RxCfgDMAShift);
 
 
+static void __rtl8139_cleanup_dev (struct net_device *dev)
+{
+   struct rtl8139_private *tp;
+   struct pci_dev *pdev;
+
+   assert (dev != NULL);
+   assert (dev->priv != NULL);
+
+   tp = dev->priv;
+   assert (tp->pci_dev != NULL);
+   pdev = tp->pci_dev;
+
+#ifndef USE_IO_OPS
+   if (tp->mmio_addr)
+   iounmap (tp->mmio_addr);
+#endif /* !USE_IO_OPS */
+
+   /* it's ok to call this even if we have no regions to free */
+   pci_release_regions (pdev);
+
+#ifndef RTL8139_NDEBUG
+   /* poison memory before freeing */
+   memset (dev, 0xBC,
+   sizeof (struct net_device) +
+   sizeof (struct rtl8139_private));
+#endif /* RTL8139_NDEBUG */
+
+   kfree (dev);
+
+   pci_set_drvdata (pdev, NULL);
+}
+
+
 static int __devinit rtl8139_init_board (struct pci_dev *pdev,
-struct net_device **dev_out,
-void **ioaddr_out)
+struct net_device **dev_out)
 {
-   void *ioaddr = NULL;
+   void *ioaddr;
struct net_device *dev;
struct rtl8139_private *tp;
u8 tmp8;
@@ -663,20 +695,19 @@
DPRINTK ("ENTER\n");
 
assert (pdev != NULL);
-   assert (ioaddr_out != NULL);
 
-   *ioaddr_out = NULL;
*dev_out = NULL;
 
-   /* dev zeroed in init_etherdev */
-   dev = init_etherdev (NULL, sizeof (*tp));
+   /* dev and dev->priv zeroed in alloc_etherdev */
+   dev = alloc_etherdev (sizeof (*tp));
if (dev == NULL) {
-   printk (KERN_ERR PFX "unable to alloc new ethernet\n");
+   printk (KERN_ERR PFX "Unable to alloc new net device\n");
DPRINTK ("EXIT, returning -ENOMEM\n");
return -ENOMEM;
}
SET_MODULE_OWNER(dev);
tp = dev->priv;
+   tp->pci_dev = pdev;
 
/* 

Re: [PATCH] RFC: fix ethernet device initialization

[Jeff Garzik]

Oh, it should be noted that since this is intended as a stable 2.4
series change.  The patch does not change any existing APIs, only adds a
function.  Existing 2.4 drivers are free to continue using
init_etherdev...  This bug, which I fix, isn't causing oops AFAIK, just
exporting ugliness to user space etc.
-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR

[Andre Hedrick]

Then run this and see if you live.

On Wed, 7 Mar 2001, Craig Ruff wrote:

> On Wed, Mar 07, 2001 at 12:32:08PM -0800, Andre Hedrick wrote:
> > The SCSI low-level format glue performed by the HOST gets destroyed
> > If you write to LBA Zero.
> 
> This is simply not true.  I write to SCSI disk's block 0 all of the time
> and never loose data.  Obviously, you can lose the partition information
> if that is where it is kept.  I've also never had trouble with SCSI
> disks correctly writing multiple sectors starting at block zero.  This
> includes older Quantum drives.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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


/* scsikiller.c */

#include 

#include 

#include 



struct cdb6hdr{

unsigned int inbufsize;

unsigned int outbufsize;

unsigned char cdb [6];

} __attribute__ ((packed));



int main (int argv, char **argc)

{

int fd;

unsigned char tBuf[526];

struct cdb6hdr *ioctlhdr;



if (argv != 2) exit(-1);



fd = open (*(argc+1), O_RDWR );

if (fd < 0) exit (-1);



memset(, 0, 526);

  

ioctlhdr = (struct cdb6hdr *) 

  

ioctlhdr->inbufsize = 512;

ioctlhdr->outbufsize = 0;

ioctlhdr->cdb[0] = WRITE_6;

ioctlhdr->cdb[4] = 1;

  

return ioctl(fd, 1, );

}

Racing power management

[John Fremlin]

 Jeff Garzik <[EMAIL PROTECTED]> writes:

> John Fremlin wrote:
> > Why not set up the device driver to handle PM events itself. See
> > Documentation/pm.txt under Driver Interface.
> 
> For PCI drivers, you implement the ::suspend and ::remove hooks.
> 
> > I have a race free version of pm_send_all if you want it.
> 
> Is this the same thing that is in 2.4.3-pre3?

Aarrgh. Looks like Alan Cox got his version in kernel first. (I did
write mine before.)

If I am not mistaken there is one (hypothetical) race still remaining
in Alan's version. Last time I checked the only code doing pm_send_all
was in the i386 APM driver (and so of course there is no chance of any
race at all even with the old version, if I understand correctly).

But suppose there were another pm_send_all caller. APM would decide to
user suspend and call pm_send_all asking for a SUSPEND to check it was
allowed to. While this is happening some clueless loser decides to
pm_send_all RESUME for whatever reason. This loser has to wait until
the APM pm_send_all finishes, but hypothetically and if I am not
mistaken, his pm_send_all RESUME could get in just after the APM
pm_send_all finished and just before APM made the physical BIOS call
to suspend the machine. This would screw stuff up of course.

You may say, this is rather improbable if not impossible, but it does
suggest that it would be a good idea to have locking wrapping
pm_send_all and the hardware machine suspend request. Cue: John's
pmpolicy patch.

Unfortunately, my patch adds another thing as well: /sbin/powermanager
so it got (is getting) trampled on by a lot of people who didn't like
that idea. If anybody wants the race free PM by itself, I can factor
out that bit.

-- 

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

PROBLEM: crash with linux 2.4.2

[pierre . doritch]

Hello,

I ran 2.4.2 under heavy load since 2 days.
I try to decrypt my /etc/passwd files with the program John
the Ripper on a Pentium133.
This process is very long ;-)

I don't understand the error. Hope it will be useful.

Pierre


you can see the load average and the uptime after crash:
10:09am up 5 days, 21:02, 2 users, load average: 18.68,
18.07, 16.85



the output of dmesg command after crash :

5e58960 edx: 0004
esi: c0268a74 edi: 0001 ebp:  esp:
c1945d28
ds: 0018 es: 0018 ss: 0018
Process fvwm95 (pid: 7630, stackpage=c1945000)
Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4
0002  c0dda14f
 0286  c0268a40 c0128872 c0268ccc
c0268cd8  
 00b8 c01289bc c0268ccc  0002
0001  c1945df8
Call Trace: [] [] []
[] [] [] []
 [] [] []

Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8
2b 05
kernel BUG at page_alloc.c:191!
invalid operand: 
CPU: 0
EIP: 0010:[]
EFLAGS: 00010092
eax: 0020 ebx: c1041c78 ecx: c5e58960 edx:
0005
esi: c0268a74 edi: 0001 ebp:  esp:
c1d97e08
ds: 0018 es: 0018 ss: 0018
Process sh (pid: 7631, stackpage=c1d97000)
Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4
0002  06ab
 0286  c0268a40 c0128872 c0268ccc
c0268cd8  
 00b8 c01289bc c0268ccc  0002
0001 c11b2dd8 c51fa420
Call Trace: [] [] []
[] [] [] []
 [] [] [] []
[]

Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8
2b 05
kernel BUG at page_alloc.c:191!
invalid operand: 
CPU: 0
EIP: 0010:[]
EFLAGS: 00010086
eax: 0020 ebx: c1041c78 ecx: c5e58960 edx:
0005
esi: c0268a74 edi: 0001 ebp:  esp:
c1d97e1c
ds: 0018 es: 0018 ss: 0018
Process sh (pid: 7632, stackpage=c1d97000)
Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4
0002  c0268ccc
 0282  c0268a40 c0128872 c0268ccc
c0268cd8  
 00b8 c01289bc c0268ccc  0002
0001 c0ec9be0 c5e58960
Call Trace: [] [] []
[] [] [] []
 [] [] [] []

Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8
2b 05
kernel BUG at page_alloc.c:191!
invalid operand: 
CPU: 0
EIP: 0010:[]
EFLAGS: 00010086
eax: 0020 ebx: c1041c78 ecx: c5e58b40 edx:
0005
esi: c0268a74 edi: 0001 ebp:  esp:
c215fd40
ds: 0018 es: 0018 ss: 0018
Process gdmlogin (pid: 7658, stackpage=c215f000)
Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4
0002  04ae
 0286  c0268a40 c0128872 c0268ccc
c0268cd8  
 00b8 c01289bc c0268ccc  0002
0001 c206ca60 c5e58b40
Call Trace: [] [] []
[] [] [] []
 [] [] [] []
[] [] [] []
 [] [] []

Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8
2b 05
kernel BUG at page_alloc.c:191!
invalid operand: 
CPU: 0
EIP: 0010:[]
EFLAGS: 00010086
eax: 0020 ebx: c1041c78 ecx: c5e58b40 edx:
0005
esi: c0268a74 edi: 0001 ebp:  esp:
c19c3d40
ds: 0018 es: 0018 ss: 0018
Process gdmlogin (pid: 7662, stackpage=c19c3000)
Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4
0002  04ae
 0286  c0268a40 c0128872 c0268ccc
c0268cd8  
 00b8 c01289bc c0268ccc  0002
0001 c0ec9f60 c5e58b40
Call Trace: [] [] []
[] [] [] []
 [] [] [] []
[] [] [] []
 [] [] []

Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8
2b 05
kernel BUG at page_alloc.c:191!
invalid operand: 
CPU: 0
EIP: 0010:[]
EFLAGS: 00010082
eax: 0020 ebx: c1041c78 ecx: c5e58960 edx:
0007
esi: c0268a74 edi: 0001 ebp:  esp:
c19c3e3c
ds: 0018 es: 0018 ss: 0018
Process bash (pid: 7665, stackpage=c19c3000)
Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4
0002  0ff8
 0282  c0268a40 c0128872 c0268ccc
c0268cd8  
 00b8 c01289bc c0268ccc  0002
0001 c10682dc c5e58960
Call Trace: [] [] []
[] [] [] []
 [] []

Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8
2b 05
kernel BUG at page_alloc.c:191!
invalid operand: 
CPU: 0
EIP: 0010:[]
EFLAGS: 00010082
eax: 0020 ebx: c1041c78 ecx: c5e58b40 edx:
0008
esi: c0268a74 edi: 0001 ebp:  esp:
c1943e3c
ds: 0018 es: 0018 ss: 0018
Process bash (pid: 7668, stackpage=c1943000)
Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4
0002  0ff8
 0282  c0268a40 c0128872 c0268ccc
c0268cd8  
 00b8 c01289bc c0268ccc  0002
0001 c106c148 c5e58b40
Call Trace: [] [] []
[] [] [] []
 [] [] []

Code: 0f 0b 83 c4 0c 90 8b 03 8b 53 04 89 50 04 89 02 89 d8
2b 05
kernel BUG at page_alloc.c:191!
invalid operand: 
CPU: 0
EIP: 0010:[]
EFLAGS: 00010082
eax: 0020 ebx: c1041c78 ecx: c5e58b40 edx:
0007
esi: c0268a74 edi: 0001 ebp:  esp:
c0f97e3c
ds: 0018 es: 0018 ss: 0018
Process bash (pid: 7672, stackpage=c0f97000)
Stack: c0225aa5 c0225c33 00bf c0268a40 c0268cd4
0002  0011
 0282  c0268a40 

Re: Mapping a piece of one process' addrspace to another?

[Jeremy Elson]

Alexander Viro writes:
>Erm. If ioctls are device-specific - the program is already bound to
>specific driver. If they are for class of devices (and if I guessed
>right that's the case you are interested in - sound, isn't it?) we
>could let the stub driver in kernel open two pipes and redirect
>read()/write() on device to the first one turn ioctls into read()/write()
>on the second. That way you can get userland programs serving that
>stuff with no magic required.

One problem, in addition to the points Abramo made, is that there's no
metadata that goes along with the data you're writing to the pipe.
This is fine as long as there's only one process reading, but in the
case of a single driver serving multiple instances of an open file,
there has to be some way for the userspace driver to communicate to
the kernel which open file needs to get the data.

A similar problem is that metadata needs to accompany the read request
when the userspace driver gets it (i.e., current file position, file
flags, size of the read that was requested, etc.)  Although, that data
might be transmitted on the OOB channel.

Also, even though my framework right now only does character devices,
it's a pretty simple extension to support userspace block devices and
network devices as well.  In these cases I think using a pipe gets
more and more complicated.

>From reading all the responses to the thread (thanks, everyone, for
your useful comments), it sounds like the best thing to do is use
Manfred's zerocopy pipe code as a model and implement something
similar in my framework.  It's not really that much code anyway so
it's not much of a waste reimplementing it.  And, I think
reimplementing those 30 lines will be much simpler than trying to
manage 2 parallel channels.  If the zerocopy patch becomes part of the
kernel anyway, it gets even simpler, since I can probably just call
pio_copy_to_user instead of copying it.

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

Re: scsi vs ide performance on fsync's

[Jens Axboe]

On Wed, Mar 07 2001, Stephen C. Tweedie wrote:
> On Wed, Mar 07, 2001 at 09:15:36PM +0100, Jens Axboe wrote:
> > On Wed, Mar 07 2001, Stephen C. Tweedie wrote:
> > > 
> > > For most fs'es, that's not an issue.  The fs won't start writeback on
> > > the primary disk at all until the journal commit has been acknowledged
> > > as firm on disk.
> > 
> > But do you then force wait on that journal commit?
> 
> It doesn't matter too much --- it's only the writeback which is doing
> this (ext3 uses a separate journal thread for it), so any sleep is
> only there to wait for the moment when writeback can safely begin:
> users of the filesystem won't see any stalls.

Ok, but even if this is true for ext3 it may not be true for other
journalled fs. AFAIR, reiser is doing an explicit wait_on_buffer
which would then amount to quite a performance hit (speculation,
haven't measured).

> > A barrier operation is sufficient then. So you're saying don't
> > over design, a simple barrier is all you need?
> 
> Pretty much so.  The simple barrier is the only thing which can be
> effectively optimised at the hardware level with SCSI anyway.

True

-- 
Jens Axboe

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

Re: scsi vs ide performance on fsync's

[Stephen C. Tweedie]

Hi,

On Wed, Mar 07, 2001 at 09:15:36PM +0100, Jens Axboe wrote:
> On Wed, Mar 07 2001, Stephen C. Tweedie wrote:
> > 
> > For most fs'es, that's not an issue.  The fs won't start writeback on
> > the primary disk at all until the journal commit has been acknowledged
> > as firm on disk.
> 
> But do you then force wait on that journal commit?

It doesn't matter too much --- it's only the writeback which is doing
this (ext3 uses a separate journal thread for it), so any sleep is
only there to wait for the moment when writeback can safely begin:
users of the filesystem won't see any stalls.

> A barrier operation is sufficient then. So you're saying don't
> over design, a simple barrier is all you need?

Pretty much so.  The simple barrier is the only thing which can be
effectively optimised at the hardware level with SCSI anyway.

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

Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR

[Craig Ruff]

On Wed, Mar 07, 2001 at 12:32:08PM -0800, Andre Hedrick wrote:
> The SCSI low-level format glue performed by the HOST gets destroyed
> If you write to LBA Zero.

This is simply not true.  I write to SCSI disk's block 0 all of the time
and never loose data.  Obviously, you can lose the partition information
if that is where it is kept.  I've also never had trouble with SCSI
disks correctly writing multiple sectors starting at block zero.  This
includes older Quantum drives.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: can't read DVD (under 2.4.[12] & 2.2.17)

[Jens Axboe]

On Wed, Mar 07 2001, Pozsar Balazs wrote:
> Details: (dmesg)
> 
> Linux version 2.4.2-3mdk ([EMAIL PROTECTED]) (gcc version
> egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Feb 27 02:14:17
> CET 2001
> ...
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> VP_IDE: IDE controller on PCI bus 00 dev 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 vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
> ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:pio, hdb:pio
> ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio, hdd:DMA
> HPT370: IDE controller on PCI bus 00 dev 70
> PCI: Found IRQ 11 for device 00:0e.0
> HPT370: chipset revision 3
> HPT370: not 100% native mode: will probe irqs later
> ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:pio, hdf:pio
> ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio
> hdd: Pioneer DVD-ROM ATAPIModel DVD-105S 012, ATAPI CD/DVD-ROM drive
> hdg: QUANTUM FIREBALLlct20 20, ATA DISK drive
> ide1 at 0x170-0x177,0x376 on irq 15
> ide3 at 0xe400-0xe407,0xe802 on irq 11
> hdg: 39876480 sectors (20417 MB) w/418KiB Cache, CHS=39560/16/63,
> UDMA(100)
> hdd: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.12
> Partition check:
>  hdg: hdg1 hdg2 hdg3 hdg4
> ...
> 
> 
> 
> When I run "dvdinfo /dev/hdd" I get:
> Disc is encrypted.
> Layer 0[3]
>  Book Version:   0
>  Book Type:  13
>  Min Rate:   0
>  Disc Size:  0
>  Layer Type: 0
>  Track Path: 1
>  Num Layers: 2
>  Track Density:  0
>  Linear Density: 0
>  BCA:1
>  Start Sector0xd000
>  End Sector  0xd000
>  End Sector L0   0xd000
> Layer 1[3]
>  Book Version:   0
>  Book Type:  13
>  Min Rate:   0
>  Disc Size:  0
>  Layer Type: 0
>  Track Path: 1
>  Num Layers: 2
>  Track Density:  0
>  Linear Density: 0
>  BCA:1
>  Start Sector0xd000
>  End Sector  0x1d000
>  End Sector L0   0xd000
> hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
> hdd: packet command error: error=0x50
> ATAPI device hdd:
>   Error: Illegal request -- (Sense key=0x05)
>   Invalid field in command packet -- (asc=0x24, ascq=0x00)
>   The failed "Send DVD Structure" packet command was:
>   "ad 00 00 00 00 00 02 00 00 54 00 00 "
> Could not read Physical layer 2
> Copyright: CPST=1, RMI=0xfd

I don't know the program you mention, but it's definitely buggy. It
sets byte 6 to 0x02 which is not valid at all. Byte 7 is the format
code, but 0x02 is reserved there too. Who wrote this program? Tell
him it's buggy, it's not the driver.

-- 
Jens Axboe

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

Re: Q: explicit alignment control for the slab allocator

[Manfred Spraul]

From: "Jes Sorensen" <[EMAIL PROTECTED]>
> > "Manfred" == Manfred Spraul <[EMAIL PROTECTED]> writes:
>
> Manfred> Mark Hemment wrote:
> >> As no one uses the feature it could well be broken, but is that a
> >> reason to change its meaning?
>
> Manfred> Some hardware drivers use HW_CACHEALIGN and assume certain
> Manfred> byte alignments, and arm needs 1024 byte aligned blocks.
>
> Isn't that just a reinvention of SMP_CACHE_BYTES? Or are there
> actually machines out there where the inbetween CPU cache line size
> differs from the between CPU and DMA controller cache line size?
>
No.

First of all HW_CACHEALIGN aligns to the L1 cache, not SMP_CACHE_BYTES.
Additionally you sometimes need a guaranteed alignment for other
problems, afaik ARM needs 1024 bytes for some structures due to cpu
restrictions, and several usb controllers need 16 byte alignment.

And some callers of kmem_cache_create() want SMP_CACHE_BYTES alignment,
other callers (and DaveM) expect L1_CACHE_BYTES alignment.

It's more a API clarification than a real change.

I think it can wait until 2.5:
drivers should use pci_alloc_consistent_pool(), not
kmalloc_aligned()+virt_to_bus(), arm can wait and the ability to choose
between SMP and L1 alignment is not that important.

--
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: [linux-lvm] EXT2-fs panic (device lvm(58,0)):

[Andreas Dilger]

Bill Clark wrote (to the moderated [EMAIL PROTECTED] list):
> Not sure if this is a LVM problem or a ext2fs problem. It is happening
> with the 2.4.2 kernel and the 0.9 release of the LVM user tools.  
> 
> kernel: Kernel panic: EXT2-fs panic (device lvm(58,0)):
> load_block_bitmap: block_group >= groups_count - block_group = 131071,
> groups_count = 24
> 
> There is a 1gig+ file on the filesystem, and most operations on it seem
> to bring about the error.  

Basically, the error you are getting is impossible.  In all calls to
load_block_bitmap(), the "group number" is either checked directly, or
"block" (which is what is used to find "group number") is checked to be <
s_blocks_count, so by inference should return a valid group number.

The only remote possibility is in ext2_free_blocks() if block+count
overflows a 32-bit unsigned value.  Only 2 places call ext2_free_blocks()
with a count != 1, and ext2_free_data() looks to be OK.  The other
possibility is that i_prealloc_count is bogus - that is it!  Nowhere
is i_prealloc_count initialized to zero AFAICS.

In most cases, this would return a "freeing blocks not in datazone" error,
but depending on the values, it may just pass the test.  This may also
be the cause of the errors people have previously reported where it
looks like they are freeing block numbers which look like ASCII data.
This would happen in ext2_discard_prealloc() when we have a value for
i_prealloc_count != 0 (easy) and i_prealloc_block points to some valid
block number (less likely, but moreso on a large filesystem).

Cheers, Andreas
==
diff -ru linux/fs/ext2/ialloc.c.orig linux/fs/ext2/ialloc.c
--- linux/fs/ext2/ialloc.c.orig Fri Dec  8 18:35:54 2000
+++ linux/fs/ext2/ialloc.c  Wed Mar  7 12:22:11 2001
@@ -432,6 +444,8 @@
inode->u.ext2_i.i_file_acl = 0;
inode->u.ext2_i.i_dir_acl = 0;
inode->u.ext2_i.i_dtime = 0;
+   inode->u.ext2_i.i_prealloc_count = 0;
inode->u.ext2_i.i_block_group = i;
if (inode->u.ext2_i.i_flags & EXT2_SYNC_FL)
inode->i_flags |= S_SYNC;
diff -ru linux/fs/ext2/inode.c.orig linux/fs/ext2/inode.c
--- linux/fs/ext2/inode.c.orig  Tue Jan 16 01:29:29 2001
+++ linux/fs/ext2/inode.c   Wed Mar  7 12:05:47 2001
@@ -1048,6 +1038,8 @@
(((__u64)le32_to_cpu(raw_inode->i_size_high)) << 32);
}
inode->i_generation = le32_to_cpu(raw_inode->i_generation);
+   inode->u.ext2_i.i_prealloc_count = 0;
inode->u.ext2_i.i_block_group = block_group;
 
/*
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Q. about oops backtrace

[Pete Zaitcev]

Hello:

I was investigating an oops and the trace looked like this:

>>EIP; c01c54a9<=
Trace; c01c3654 
Trace; c01c0f0f 
Trace; c015e7e2 
Trace; c01155a6 
Trace; c01272a9 
Trace; c0127414 
Trace; c0136a2d 
Trace; c012722e 
Trace; c0127290 
Trace; c0127414 
Trace; c014cdec 
Trace; c0143f80 
Trace; c0144aae 
Trace; c014cdec 
Trace; c01392c9 
Trace; c0138130 
Trace; c013805d 
Trace; c0148b97 
Trace; c01091c7 

What is with those recursive handle_mm_fault calls?
That does not look quite right. I _assume_ that the
stack would collapse properly upon return, but still...
I would appreciate a suggestion about what .S file to read
for the explanation.

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

Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR

[Andre Hedrick]

Harvey,

That is not the case Joanne is pointing out.
The SCSI low-level format glue performed by the HOST gets destroyed
If you write to LBA Zero.  ATA only suffers the lose of the partition
table and that can be recovered, but SCSI needs that information to know
where everything else is on the drive.

You know I really do not care anymore that people can screw themselves,
and that Linux has choosen the road of pure UNIX, user beware.  After the
last battles, I encourge stupidity, because the no IOCTLS will require you
know how to use the hardware rules completely, and if you compose the
wrong command because you can not/will not understand the rules of IO and
use the interface improperly, tough.

On Wed, 7 Mar 2001, Harvey Fishman wrote:

> Joanne, since a SCSI drive contains a processor (one of the small
> computer systems that are interfacing) it requires that the local
> personality data be stored in non-volatile storage someplace.
> Most drives used a dedicated area of the drive surface, which was
> SUPPOSED to be inaccessible to any outside process.  If you were
> able to muck with that sector or sectors, then it was REAL EASY
> to make the drive terminally unusable.  But as I say, you should
> not be able to directly reach that area.
> 
> Since ATA drives are generally also small self-contained systems
> who differ from SCSI drives mainly in the details of the interface
> protocols, they probably suffer from the same problem.
> 
> But you ain't supposed to be able to get at that area...
> 
> Harvey
> 
> On Tue, 6 Mar 2001, J. Dow wrote:
> 
> > From: "Jens Axboe" <[EMAIL PROTECTED]>
> > To: "Andre Hedrick" <[EMAIL PROTECTED]>
> > Cc: "Alan Cox" <[EMAIL PROTECTED]>; "Linus Torvalds"
> > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > 
> > > > This is a LIE, it does not destroy the drive, only the partition table.
> > > > Please recally the limited effects of "DiskDestroyer" and "SCSIkiller"
> > > >
> > > > This is why we had the flaming discussion about command filters.
> > >
> > > But I might want to do this (write sector 0), why would we want
> > 
> > Jens, and others, I have noted a very simple data killer technique that
> > at LEAST works on Quantum SCSI drives as of a couple years ago and some
> > other earlier drives I felt could be sacrificed to the test. You can write
> > as many blocks at once as SCSI supports to the drive as long as you do
> > *NOT* start at block zero. If you write more than 1 block to block zero
> > the drive becomes unformatted. The only recovery is to reformat the
> > drive. The data on the drive is lost for good. I found no recovery for
> > this. I have, to my great chagrin, discovered this twice, the hard way.
> > Once on a large Micropolis harddisk I was working with in the block zero
> > area for partitioning purposes. And the other time when I was attempting
> > to make a complete duplicate of a 2G Quantum SCSI disk to another identical
> > 2G SCSI disk. I ended up writing a script for the process that wrote one
> > block to block zero and then proceeded to use large blocks for the rest
> > of the disk, using dd under 2.0.36 at the time.
> > 
> > If this problem still exists the lowest level drivers in the OS should
> > offer protection for this problem so people working at any higher level
> > do not see it and fall victim to it.
> > 
> > {^_^}Joanne Dow, [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/
> > 
> 
> 
>  Harvey Fishman   |
> [EMAIL PROTECTED] |   A little heresy is good for the soul.
>   718-258-7276|
> 

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: can't read DVD (under 2.4.[12] & 2.2.17)

[Pozsar Balazs]

Details: (dmesg)

Linux version 2.4.2-3mdk ([EMAIL PROTECTED]) (gcc version
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Feb 27 02:14:17
CET 2001
...
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 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 vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio, hdd:DMA
HPT370: IDE controller on PCI bus 00 dev 70
PCI: Found IRQ 11 for device 00:0e.0
HPT370: chipset revision 3
HPT370: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio
hdd: Pioneer DVD-ROM ATAPIModel DVD-105S 012, ATAPI CD/DVD-ROM drive
hdg: QUANTUM FIREBALLlct20 20, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
ide3 at 0xe400-0xe407,0xe802 on irq 11
hdg: 39876480 sectors (20417 MB) w/418KiB Cache, CHS=39560/16/63,
UDMA(100)
hdd: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hdg: hdg1 hdg2 hdg3 hdg4
...



When I run "dvdinfo /dev/hdd" I get:
Disc is encrypted.
Layer 0[3]
 Book Version:   0
 Book Type:  13
 Min Rate:   0
 Disc Size:  0
 Layer Type: 0
 Track Path: 1
 Num Layers: 2
 Track Density:  0
 Linear Density: 0
 BCA:1
 Start Sector0xd000
 End Sector  0xd000
 End Sector L0   0xd000
Layer 1[3]
 Book Version:   0
 Book Type:  13
 Min Rate:   0
 Disc Size:  0
 Layer Type: 0
 Track Path: 1
 Num Layers: 2
 Track Density:  0
 Linear Density: 0
 BCA:1
 Start Sector0xd000
 End Sector  0x1d000
 End Sector L0   0xd000
hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdd: packet command error: error=0x50
ATAPI device hdd:
  Error: Illegal request -- (Sense key=0x05)
  Invalid field in command packet -- (asc=0x24, ascq=0x00)
  The failed "Send DVD Structure" packet command was:
  "ad 00 00 00 00 00 02 00 00 54 00 00 "
Could not read Physical layer 2
Copyright: CPST=1, RMI=0xfd


I also get this in syslog:

hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdd: packet command error: error=0x50
ATAPI device hdd:
  Error: Illegal request -- (Sense key=0x05)
  Invalid field in command packet -- (asc=0x24, ascq=0x00)
  The failed "Send DVD Structure" packet command was:
  "ad 00 00 00 00 00 02 00 00 54 00 00 "


Tell me i can give you any more info.

Balazs Pozsar.



On Wed, 7 Mar 2001, Jens Axboe wrote:

> On Wed, Mar 07 2001, Pozsar Balazs wrote:
> >
> > hi all,
> >
> > Whatever I tried, I couldn't get my DVDs read. I get:
> >  sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
> > or, I don't use ide-scsi, i get the ATAPI equivalent.
> > I have udf support compiled in, i have successfully authenticated the
> > disk(s), but lo luck.
> >
> > The drive is:
> >Vendor: PIONEER   Model: DVD-ROM DVD-105   Rev: 1.22
> >
> > I tried 2.2.17, 2.4.1 & 2.4.2 (and a few different compiled versions of
> > them)
> >
> > What might be the problem?
>
> I don't know, you provide virtually no information. Use the ATAPI
> driver, and dump dmesg info when this happens. Then send that along.
>
>

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

Re: Interesting fs corruption story

[Tim Wright]

On Tue, Mar 06, 2001 at 08:10:10PM -0500, Ettore Perazzoli wrote:
> On 06 Mar 2001 17:01:02 -0800, Tim Wright wrote:
[...]
> > The fix for me was to rebuild the kernel and make sure CONFIG_APM_ALLOW_INTS
> > was enabled. So, do you ever use power management and is this similar, or do
> > you have a completely different problem ?
> 
>   Wow, this sounds like this might be the problem.  I just checked my
> `.config' and indeed `CONFIG_APM_ALLOW_INTS' is not enabled.  And indeed
> I have been suspending/resuming the machine a few times before the
> partition got corrupted.
> 
>   So, does DMA work correctly on your system after setting this option?

Yes, it does. I have the drive running in UDMA mode 2, and get ~16MB/s from
'hdparm -t -T'. I have the "use DMA automatically" option turned on in the
kernel, so I inherit the BIOS settings which are correct.

I've used standby and hibernation with complete success since.

Regards,

Tim

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: scsi vs ide performance on fsync's

[Jens Axboe]

On Wed, Mar 07 2001, Stephen C. Tweedie wrote:
> On Wed, Mar 07, 2001 at 07:51:52PM +0100, Jens Axboe wrote:
> > On Wed, Mar 07 2001, Stephen C. Tweedie wrote:
> > 
> > My bigger concern is when the journalled fs has a log on a different
> > queue.
> 
> For most fs'es, that's not an issue.  The fs won't start writeback on
> the primary disk at all until the journal commit has been acknowledged
> as firm on disk.

But do you then force wait on that journal commit?

> Certainly for ext3, synchronisation between the log and the primary
> disk is no big thing.  What really hurts is writing to the log, where
> we have to wait for the log writes to complete before submitting the
> commit write (which is sequentially allocated just after the rest of
> the log blocks).  Specifying a barrier on the commit block would allow
> us to keep the log device streaming, and the fs can deal with
> synchronising the primary disk quite happily by itself.

A barrier operation is sufficient then. So you're saying don't
over design, a simple barrier is all you need?

-- 
Jens Axboe

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

Re: Forcible removal of modules

[Jeff Garzik]

John Fremlin wrote:
> Why not set up the device driver to handle PM events itself. See
> Documentation/pm.txt under Driver Interface.

For PCI drivers, you implement the ::suspend and ::remove hooks.

> I have a race free version of pm_send_all if you want it.

Is this the same thing that is in 2.4.3-pre3?

-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ac13 and lp related problem

[f5ibh]

Hi Tim,

>> Mar  7 11:55:55 debian-f5ibh lpd[567]: lp: filter 'f' terminated
>> (termsig=13)

>   Which filter?

Dunno what means 'f', I use magicfilter and the /etc/printcap generated by
magifilterconfig contains :

lp|escp500|Stylus Color 500:\
:lp=/dev/lp0:sd=/var/spool/lpd/escp500:\
:sh:pw#80:pl#72:px#1440:mx#0:\
:if=/etc/magicfilter/StylusColor-500@720dpi-filter:\
:af=/var/log/lp-acct:lf=/var/log/lp-errs:

>Does the patch I posted yesterday help?
I've not had the problem yesterday ;-)
I will try to retrieve the patch and test it.


Thank you, regards

Jean-Luc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: kernel BUG at slabc:1095! [was: 2.4.x total system crash -nooops (SCSI problems?)]

[Peter Mottram]

On Mon, 5 Mar 2001, Jeff Garzik wrote:

> Is it possible to get addition information, using the vmdump patch?
> http://oss.sgi.com/projects/lkcd/
>

vmdump patch added but system locked up before managing to crash dump. I
have managed to get an OOPS though.   :-)

trying a simple:

# scanimage

i get.

(SCSI0:6:0) cannot abort running or disconnected command
Unable to handle kernel null pointer dereference at virtual address
0008
 printing eip:
c01c87de
*pde = 
Oops : 
CPU : 1
EIP : 0010:[]
EFLAGS: 00010282
eax:  ebx: dfe5bdcc ecx: dc19be20 edx: 005d
esi: c18aa000 edi: 0282 epb: 0002 esp: dffedeb4
ds: 0018 es: 0018 ss: 0018
Process swapper (pid:0, stackpage=dffed000)
Stack= c01c93a0 dfe5bdcc c18aa000  c02cce78 c18aa118 c01cb156 c18aa000
   0002 c0326d50  c030ec60 c18aa0a8 36da c01c8f70 c18aa000
   dffedf0c dffedf0c c011b66c  0009 0020 c0326d60 c0326d60
Call Trace: [] [] [] []
[] [] [] [] []
[] [] [] [] []
[] [] [] [] []
Code: 8b 48 08 85 c9 74 09 f0 ff 01 0f 8e f9 ee 07 00 c3 90 83 ec
Dumping to device 0x802 [sd(8,2)]kernel BUG at slab.c:1095!


And that's all folks (I think I typed that all in correctly).

Anyone want any more info?

Regards
PeteM

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

Re: can't read DVD (under 2.4.[12] & 2.2.17)

[Jens Axboe]

On Wed, Mar 07 2001, Pozsar Balazs wrote:
> 
> hi all,
> 
> Whatever I tried, I couldn't get my DVDs read. I get:
>  sr0: CDROM (ioctl) reports ILLEGAL REQUEST.
> or, I don't use ide-scsi, i get the ATAPI equivalent.
> I have udf support compiled in, i have successfully authenticated the
> disk(s), but lo luck.
> 
> The drive is:
>Vendor: PIONEER   Model: DVD-ROM DVD-105   Rev: 1.22
> 
> I tried 2.2.17, 2.4.1 & 2.4.2 (and a few different compiled versions of
> them)
> 
> What might be the problem?

I don't know, you provide virtually no information. Use the ATAPI
driver, and dump dmesg info when this happens. Then send that along.

-- 
Jens Axboe

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