Re: goodbye

[Graham Murray]

Matti Aarnio <[EMAIL PROTECTED]> writes:

>   I just verified this particular aspect of VGER's MTA
>   configurations.  It has been unmodified since 21-Mar-2000,
>   that is, over a year...

On the subject of vger configuration, the FAQ states that vger "will"
start using ECN as of 22 Feb 2001. This does not seem to have
happened yet. Has this change been cancelled or merely postponed?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: goodbye

[Stephen Satchell]

At 09:02 PM 4/7/01 -0700, Joseph Carter wrote:
>Not always an option.  There are many places in the world in which your
>ISP is a monopoly.  And even in your simplistic view of the world, there
>are many places in the United States where you are held captibe by not
>having more than one local ISP.  That's even more true of broadband
>connections.  Monopoly service is the rule there, not the exception.

Concur.  One reason I started up my own sendmail for outgoing mail was 
because Pacific Bell Internet (in its various brand names) refused to close 
up open relays, even when their large clients ran spam relay servers.  When 
ORBS caused my mail to be blocked to the Linux Kernel list because of this, 
I complained to "technical support".  Their response was for me to sue ORBS 
for causing my mails to be blocked!  When asked when PBI was going to close 
up the mail relay from their customers' open servers, they said "never."

I had broadband access with them.  Fortunately PBI was clueless enough that 
I could run my own outgoing mail server and get connectivity back.  It took 
nine months before I could move off of them.

Other contributors may not be as fortunate -- I've heard about ISPs that 
block all SMTP traffic not involving their mail servers.  When they are the 
only ISP in town, that makes for a bad situation.

I also expect nothing to come from this off-topic discussion, so this will 
most likely be the last you hear from me on this subject.

Satch

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

Re: aic7xxx 6.1.10 and 2.4.4-pre1

[lists]

  Well my aicxxx problems continue:

  I did it again and indeed verified similar error messages as I had
  under stock 2.4.3 and 2.4.3+aic 6.1.8. This time it died during boot itself
  starting with complaints from ssh/xinet et al - then I started seeing the
  scsi errors.  (I believe I had also tried ac26 with similar problems hwhich IIRC 
  is  6.1.5).

  Anyway, it goes around in a loop with stuff like:

  SCB 1 ...
  scsi ... 
  scsi   ... recovery complete ..
  scsi   ... code aweke ..
  scsi   ... aic7xxx_abort returns 8194

  or somwething similar. The aic7xxx_abort returns 8194 i remember exactly the others 
  I'm a bit shaky on. Anyway it seems to loop with the recovery/abort thing.

  What can I do to help track down the problem? 

  Regards,


  Gene/

  

---

I enclose output of ver_linux - I note that it incorrectly reports util-linux
becuase it uses mount --version. On my redhat system mount is 2.10r while util-linux
is 2.10s-11. 


Linux snap 2.4.1-0.1.9 #1 Wed Feb 14 22:15:15 EST 2001 i686 unknown
 
Gnu C  2.96
Gnu make   3.79.1
binutils   2.10.91.0.2
util-linux 2.10r
modutils   2.4.5
e2fsprogs  1.19
reiserfsprogs  3.x.0b
pcmcia-cs  3.1.22
PPP2.4.0
Linux C Library2.2.2
Dynamic linker (ldd)   2.2.2
Procps 2.0.7
Net-tools  1.57
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded emu10k1 soundcore autofs joydev hid input 3c59x ipchains 
ide-scsi ide-cd cdrom usb-uhci usbcore aic7xxx sd_mod scsi_mod

---


On Sun, Apr 08, 2001 at 12:11:32AM -0400, [EMAIL PROTECTED] wrote:
> 
> I used 5000ms. I still freeze up with 2.4.3 + 6.1.10.
> 
> ...

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

Re: goodbye

[David Fries]

On Sun, Apr 08, 2001 at 02:32:28AM +0300, Matti Aarnio wrote:
> On Tue, Apr 03, 2001 at 06:14:33PM -0700, Michael Peddemors wrote:
>   Well, comparing how much spam goes thru linux-mm vs. linux-kernel,
>   I would say our methods are fairly effective.
> 
>   The incentive behind the DUL is to force users not to post
>   straight out to the world, but to use their ISP's servers
>   for outbound email --- normal M$ users do that, after all.
>   Only spammers - and UNIX powerusers - want to post directly
>   to the world from dialups.  And UNIX powerusers should know
>   better, and be able to use ISP relay service anyway.

I guess you will have to explain to me why that is supposed to be a
good thing to force people to go though their ISP.  I've had personal
experience where I returned to my University which forces everyone to
go though their mail spool and it took me a week or two before I
realized that any e-mail I sent off campus wasn't getting there and I
was using their mail services.  Turns out the university changed the
host names for our ip's and my hostname wasn't changed to reflect that
(stupid name I might add and not for human readability, the previous
ones were understandable.)

To this day I don't know what happened to those e-mails, I do know I
didn't get them and the desired people didn't get them.

There is a lot of comfort looking at /var/log/mail.log and seeing mail
accepted by the computer servicing the other person's account.  Now
all I have is, accepted by university, hope it gets there...

-- 
+-+
|  David Fries|
|  [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: aic7xxx 6.1.10 and 2.4.4-pre1

[lists]

I used 5000ms. I still freeze up with 2.4.3 + 6.1.10.

Unfortunately i could not see any messages and nothing got logged.
This time an fsck allowed me to boot back to 2.4.1.  

The visible symptoms were the same as before (2.4.3 + 6.1.8) but this time I was
unable to flip virtual consoles before the freeze so I dont even
know 100% what is causing it - it boots fine - and the scsi driver 
makes no complaints - it all looks normal. X starts up and I can login. 
it starts ok and windows start popping up -  shortly thereafter it freezes 
- just like before. 

I will try investigate further and see if I can get any more log messages.

Is there any debug boot option or compile flag that will help me find out more 
what is going on?  

/var/log/messages says this about scsi.

Apr  7 19:56:13 snap kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 
6.1.10
Apr  7 19:56:13 snap kernel: 
Apr  7 19:56:13 snap kernel: aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs
Apr  7 19:56:13 snap kernel: 
Apr  7 19:56:13 snap kernel:   Vendor: YAMAHAModel: CRW8424S  Rev: 1.0d
Apr  7 19:56:13 snap kernel:   Type:   CD-ROM ANSI SCSI 
revision: 02
Apr  7 19:56:13 snap kernel:   Vendor: SEAGATE   Model: ST318275LWRev: 0001
Apr  7 19:56:13 snap kernel:   Type:   Direct-Access  ANSI SCSI 
revision: 02
Apr  7 19:56:13 snap kernel: (scsi0:A:5): 80.000MB/s transfers (40.000MHz, offset 15, 
16bit)
Apr  7 19:56:13 snap kernel:   Vendor: SEAGATE   Model: ST318275LWRev: 0001
Apr  7 19:56:13 snap kernel:   Type:   Direct-Access  ANSI SCSI 
revision: 02
Apr  7 19:56:13 snap kernel: (scsi0:A:6): 80.000MB/s transfers (40.000MHz, offset 15, 
16bit)
Apr  7 19:56:13 snap kernel: scsi0:0:5:0: Tagged Queuing enabled.  Depth 253
Apr  7 19:56:13 snap kernel: scsi0:0:6:0: Tagged Queuing enabled.  Depth 253


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

Re: goodbye

[Ralf Baechle]

On Sun, Apr 08, 2001 at 02:32:28AM +0300, Matti Aarnio wrote:

>   The incentive behind the DUL is to force users not to post
>   straight out to the world, but to use their ISP's servers
>   for outbound email --- normal M$ users do that, after all.
>   Only spammers - and UNIX powerusers - want to post directly
>   to the world from dialups.  And UNIX powerusers should know
>   better, and be able to use ISP relay service anyway.

Surprise - my ISP doesn't even seem to have one.  Raw IP, nothing else.
Like god made ISPs.

  Ralf

--
"Embrace, Enhance, Eliminate" - it worked for the pope, it'll work for Bill.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: goodbye

[Joseph Carter]

On Sun, Apr 08, 2001 at 12:56:21PM +1000, john slee wrote:
> > Some ISPs rely on crap software & OS to process email, and have other
> 
> so you don't use those ISPs

Not always an option.  There are many places in the world in which your
ISP is a monopoly.  And even in your simplistic view of the world, there
are many places in the United States where you are held captibe by not
having more than one local ISP.  That's even more true of broadband
connections.  Monopoly service is the rule there, not the exception.

Even in those cases where broadband users are given a choice of providers,
they have to know to ask for that choice since it is never offered and by
exercising that choice you will usually find the price to be at least
double if not triple - often through no fault of your chosen ISP.  If you
order DSL without your telco's ISP, you'll usually discover a great many
"fees" they only elect to charge if you don't cooperate.


My beef is and always has been with the DUL specifically.  I have no issue
with the RBL or RSS lists.  ORBS ... well, they called one of my old ISPs'
mail an open relay when it wasn't and took 3 months to decide to rectify
the situation and remove us from their list.  That doesn't instill much
confidence.  The DUL however is blatant discrimination based on connection
class rather than any real evidence that spammers are at all affected by
it.  In fact, DUL users have no idea if the mail they block is spam or
not.

For the record, my spam filters (procmail rules) stop 19 out of 20 spams
from ever landing in my inbox.  Of those, 1 in 30 (or less) was a valid
email that was mistakenly identified.  I know this because I check the
folder I save those mails to about once a week on average for false
positives.  The rule that catches the most?  * ! ^TOknghtbrd - perhaps the
oldest spam detector ever and it catches almost all spam without keyword
match or anything else.


Okay, end of rant, please think about it, etc.

-- 
Joseph Carter <[EMAIL PROTECTED]>Free software developer

<_Anarchy_> Argh.. who's handing out the paper bags  8)


 PGP signature

patch-2.4.4-pre1.bz2 fails

[Garst R. Reese]

patching kernel 2.4.3 in /usr/src/linux
cd /usr/src
bunzip2 -c ~/kpatch/patch-2.4.4-pre1.bz2 | patch -p0 -E
as I have done hundreds of times.
tons of failed hunks and previously applied patches.
I can patch my backup of 2.4.0 -> 2.4.1 -> 2.4.2 -> 2.4.3 with no
problem.
Please cc me as I can only read the archives.
Garst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: goodbye

[john slee]

On Sat, Apr 07, 2001 at 07:07:20PM -0700, Colonel wrote:
> Some ISPs rely on crap software & OS to process email, and have other

so you don't use those ISPs

> bad habits besides.  Censorship usually does more bad than good
> (especially since dealing with 80% of the spam is trivial for
> procmail), as has been pointed out in this case.  The stupidity of the

so you would have all ~8000 subscribers add their own procmail rules?
(and post "where'd my lkml mail go" rants here when they get it wrong)

i certainly prefer matti/davem's approach

j.

-- 
"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Compaq proliant ML-350 - IDE & SCSI

[Cagle, John]

On 04/07/2001 21:55:53, Alexandru Barloiu Nicolae wrote:
> I am trying to use the DMA on the ide drives. After the reboot Dma is
> enabled but if I don't disable it with hdparm the system freezes at heavy
> work (copy something from a drive to the other). The SCSI works ok.
Without
> the DMA the system barely moves
>
> 
>
> Any ideas what's wrong?

Which kernel version are you using?  The OSB4 ide driver prior to version
2.4.2-ac27 causes problems on SMP servers.  You may want to try a more
recent kernel or remove the OSB4-specific driver and use the standard
IDE/ATA driver instead.

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

Re: goodbye

[Colonel]

In list.kernel, you wrote:
>
>On Tue, Apr 03, 2001 at 06:14:33PM -0700, Michael Peddemors wrote:
>> I think that this is one list where we have to keep the ability to post
>> from individuals separate from the need to make sure that their ISP or
>> company is compliant to a set a of rules..  The LKML can't toe the
>> strictest of lines, without loosing some possibly valuable
>> contributors..
>
>   Well, comparing how much spam goes thru linux-mm vs. linux-kernel,
>   I would say our methods are fairly effective.

A stupid measure, since you cannot determine what was rejected, i.e. how
many babies you threw out with the bathwater.

>   The incentive behind the DUL is to force users not to post
>   straight out to the world, but to use their ISP's servers
>   for outbound email --- normal M$ users do that, after all.


Some ISPs rely on crap software & OS to process email, and have other
bad habits besides.  Censorship usually does more bad than good
(especially since dealing with 80% of the spam is trivial for
procmail), as has been pointed out in this case.  The stupidity of the
this approach is well shown by the email-blacklist groups blacklisting
each other, I would think that lkml had more brains.

Controlling email is a power game, where you set yourself up as a tin
god and proclaim that you alone know what is safe for the "dumb"
masses to read.  Perhaps the lkml sheep will abide by such control, but
I would think that 'free software' would have 'free discussions'.


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

Re: uninteruptable sleep

[Anton Blanchard]

> That happened to me with 2.4.2-ac28 when I tried using DRM.
> I also got the following messages in syslog.
> 
> /var/log/messages.1:Mar 31 12:15:04 joker kernel:
> [drm:r128_do_wait_for_fifo] *ERROR* r128_do_wait_for_fifo failed!

You need to replace down(...->mmap_sem), up(...->mmap_sem) with
down_write(...), up_write(...) in the X11 r128 drm kernel module.

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

Re: P-III Oddity.

[Dave Jones]

On Sat, 7 Apr 2001, Trevor Hemsley wrote:

> I've got this on my dual processor P-III 600MHz. One of the cpus in
> this box reports cpuid level 2, the other 3. Serial number is disabled
> in the BIOS.

Interesting, the cpu serial number isn't being disabled on the
2nd CPU. Most odd. Well, we disable reporting that it's available,
but it looks like it still remains possible to get at it.

I'll dig some more tomorrow morning.

Dave.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 6.1.10 breaks 2.4.3-ac3

[Justin T. Gibbs]

>Once you said 'here is my site for this certain soft updates', you can't
>excpect that people do not check it in a regular basis, did you announce
>anything or not.

I'm not expecting anything.  I just find it amusing when people grab
stuff that has no instructions, don't look at what they've grabbed to
figure out what it is or how it works, and then complain when they
can't diagnose the result of their efforts.

--
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: aic7xxx 6.1.10 and 2.4.4-pre1

[Justin T. Gibbs]

>NORET_TYPE void panic(const char * fmt, ...)
>__attribute__ ((NORET_AND format (printf, 1, 2)));
>^
>
>Similar cases, compare include/linux/raid/md_k.h:pers_to_level() in
>2.4.3 and 2.4.3-ac3.

Then gcc is not honoring the attribute.  The only way for that
function to not return with a value is in the panic case and that
cannot happen.

--
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: P-III Oddity.

[CaT]

On Sat, Apr 07, 2001 at 09:56:40PM +0200, Dave Jones wrote:
> On Sat, 7 Apr 2001, Rogier Wolff wrote:
> 
> > One machine regularly crashes.
> > Linux version 2.2.16-3 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 
>19990314/Linux (egcs-1.1.2 release)) #1 Mon Jun 19 19:11:44 EDT 2000
> 
> Probably unrelated to the issue below. Try a more recent 2.2 ?

2.2.19pre16 here. I don't have an SMP kernel but is this right:

cpuid level : 3
Vendor ID: "GenuineIntel"; Max CPUID level 2

That line is the only line I could find that mentioned cpuid in your
code so I seem to be getting two different answers...

-- 
CaT ([EMAIL PROTECTED])*** Jenna has joined the channel.
 speaking of mental giants..
 me, a giant, bullshit
 And i'm not mental
- An IRC session, 20/12/2000

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 6.1.10 and 2.4.4-pre1

[J . A . Magallon]

On 04.08 Justin T. Gibbs wrote:
> >
> >   In file included from aic7xxx_linux.c:131:
> >   aic7xxx_osm.h: In function `ahc_pci_read_config':
> >   aic7xxx_osm.h:862: warning: control reaches end of non-void function
> 
> This is because panic() is not marked as a "no return" function.  So,

linux/include/linux/kernel.h +38:

# define NORET_TYPE/**/
# define ATTRIB_NORET  __attribute__((noreturn))
# define NORET_AND noreturn,
..
NORET_TYPE void panic(const char * fmt, ...)
__attribute__ ((NORET_AND format (printf, 1, 2)));
^

Similar cases, compare include/linux/raid/md_k.h:pers_to_level() in
2.4.3 and 2.4.3-ac3.

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

Linux werewolf 2.4.3-ac3 #1 SMP Thu Apr 5 00:28:45 CEST 2001 i686

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

Re: aic7xxx 6.1.10 breaks 2.4.3-ac3

[J . A . Magallon]

On 04.08 Justin T. Gibbs wrote:
> 
> Actually, I would say, "Apply the 2.4.3 patch.  It will probably apply
> cleanly to your kernel.  If it doesn't, and you don't know enough C
> to correct the problem, you shouldn't be playing around with kernel
> patches."
>

Below is inlined the patch that touches everything outside the aic7xxx
private subtree. The rest needed is the src.tar.gz file from your site.
Just corrected offsets.

> >That is not the way to do things. It is supposed that what people can get
> >at your site is the aic driver.
> 
> Ahh, now I have people telling me what the content of my
> site should be. ;-)

Nope, you can do whatever you like.

> 
> This has already happened in all cases save the functionality I've added
> in 6.1.10.  I haven't even gotten around to announcing 6.1.10 yet, so
> you can hardly fault me for not posting the SCSI layer changes yet.
>

Once you said 'here is my site for this certain soft updates', you can't
excpect that people do not check it in a regular basis, did you announce
anything or not.

=== patch-follows

diff -u -r -N linux-2.4.3.virgin/Documentation/Configure.help
linux-2.4.3/Documentation/Configure.help
--- linux-2.4.3.virgin/Documentation/Configure.help Wed Apr  4 15:41:33
2001
+++ linux-2.4.3/Documentation/Configure.helpWed Apr  4 15:41:37 2001
@@ -5687,7 +5687,7 @@
   Default: 253
 
 Initial Bus Reset Settle Delay
-CONFIG_AIC7XXX_RESET_DELAY
+CONFIG_AIC7XXX_RESET_DELAY_MS
   The number of milliseconds to delay after an initial bus reset.
   The bus settle delay following all error recovery actions is
   dictated by the SCSI layer and is not affected by this value.
diff -u -r -N linux-2.4.3.virgin/Makefile linux-2.4.3/Makefile
--- linux-2.4.3.virgin/Makefile Thu Mar 29 21:13:15 2001
+++ linux-2.4.3/MakefileTue Apr  3 13:04:24 2001
@@ -144,7 +144,6 @@
 DRIVERS-$(CONFIG_ATM) += drivers/atm/atm.o
 DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o
 DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o
-DRIVERS-$(CONFIG_SCSI_AIC7XXX) += drivers/scsi/aic7xxx/aic7xxx_drv.o
 DRIVERS-$(CONFIG_FUSION_BOOT) += drivers/message/fusion/fusion.o
 DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394drv.o
 
diff -u -r -N linux-2.4.3.virgin/arch/alpha/defconfig
linux-2.4.3/arch/alpha/defconfig
--- linux-2.4.3.virgin/arch/alpha/defconfig Sun Mar  4 15:30:18 2001
+++ linux-2.4.3/arch/alpha/defconfigWed Apr  4 15:49:21 2001
@@ -286,7 +286,7 @@
 # CONFIG_SCSI_AHA1740 is not set
 CONFIG_SCSI_AIC7XXX=y
 CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
-CONFIG_AIC7XXX_RESET_DELAY=5000
+CONFIG_AIC7XXX_RESET_DELAY_MS=5000
 # CONFIG_SCSI_ADVANSYS is not set
 # CONFIG_SCSI_IN2000 is not set
 # CONFIG_SCSI_AM53C974 is not set
diff -u -r -N linux-2.4.3.virgin/arch/ppc/defconfig
linux-2.4.3/arch/ppc/defconfig
--- linux-2.4.3.virgin/arch/ppc/defconfig   Sun Mar  4 15:30:18 2001
+++ linux-2.4.3/arch/ppc/defconfig  Wed Apr  4 15:49:38 2001
@@ -297,7 +297,7 @@
 # CONFIG_SCSI_AHA1740 is not set
 CONFIG_SCSI_AIC7XXX=y
 CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
-CONFIG_AIC7XXX_RESET_DELAY=15000
+CONFIG_AIC7XXX_RESET_DELAY_MS=15000
 # CONFIG_SCSI_AIC7XXX_OLD is not set
 # CONFIG_SCSI_ADVANSYS is not set
 # CONFIG_SCSI_IN2000 is not set
diff -u -r -N linux-2.4.3.virgin/arch/sparc64/defconfig
linux-2.4.3/arch/sparc64/defconfig
--- linux-2.4.3.virgin/arch/sparc64/defconfig   Sun Mar 25 19:14:21 2001
+++ linux-2.4.3/arch/sparc64/defconfig  Wed Apr  4 15:49:48 2001
@@ -307,7 +307,7 @@
 CONFIG_SCSI_QLOGICPTI=m
 CONFIG_SCSI_AIC7XXX=m
 CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
-CONFIG_AIC7XXX_RESET_DELAY=5000
+CONFIG_AIC7XXX_RESET_DELAY_MS=5000
 CONFIG_SCSI_AIC7XXX_OLD=m
 CONFIG_AIC7XXX_OLD_TCQ_ON_BY_DEFAULT=y
 CONFIG_AIC7XXX_OLD_CMDS_PER_DEVICE=8
diff -u -r -N linux-2.4.3.virgin/drivers/scsi/Makefile
linux-2.4.3/drivers/scsi/Makefile
--- linux-2.4.3.virgin/drivers/scsi/MakefileMon Mar 26 16:36:30 2001
+++ linux-2.4.3/drivers/scsi/Makefile   Tue Apr  3 13:04:15 2001
@@ -6,6 +6,12 @@
 #
 # 20 Sep 2000, Torben Mathiasen <[EMAIL PROTECTED]>
 # Changed link order to reflect new scsi initialization.
+#
+# *!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!
+# The link order must be, SCSI Core, SCSI HBA drivers, and
+# lastly SCSI peripheral drivers (disk/tape/cdrom/etc.) to
+# satisfy certain initialization assumptions in the SCSI layer.
+# *!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!*!
 
 O_TARGET := scsidrv.o
 
@@ -64,6 +70,9 @@
 obj-$(CONFIG_SCSI_AHA152X) += aha152x.o
 obj-$(CONFIG_SCSI_AHA1542) += aha1542.o
 obj-$(CONFIG_SCSI_AHA1740) += aha1740.o
+ifeq ($(CONFIG_SCSI_AIC7XXX),y)
+obj-$(CONFIG_SCSI_AIC7XXX) += aic7xxx/aic7xxx_drv.o
+endif
 obj-$(CONFIG_SCSI_AIC7XXX_OLD) += aic7xxx_old.o
 obj-$(CONFIG_SCSI_IPS) += ips.o
 obj-$(CONFIG_SCSI_FD_MCS)  += fd_mcs.o
diff -u -r -N linux-2.4.3.virgin/drivers/scsi/scsi_lib.c
linux-2.4.3/drivers/scsi/scsi_lib.c
--- linux-2.4.3.virgin/drivers/scsi/scsi_lib.c  Fri Mar  2 19:38:39 2001

Re: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel

[Paul McKenney]

> > > > 2.   Isn't it possible to get in trouble even on a UP if a task
> > > >  is preempted in a critical region?  For example, suppose the
> > > >  preempting task does a synchronize_kernel()?
> > >
> > > Ugly. I guess one way to solve it would be to readd the 2.2 scheduler
> > > taskqueue, and just queue a scheduler callback in this case.
> >
> > Another approach would be to define a "really low" priority that noone
> > other than synchronize_kernel() was allowed to use.  Then the UP
> > implementation of synchronize_kernel() could drop its priority to
> > this level, yield the CPU, and know that all preempted tasks must
> > have obtained and voluntarily yielded the CPU before synchronize_kernel
()
> > gets it back again.
>
> That just would allow nasty starvation, e.g. when someone runs a cpu
intensive
> screensaver or a seti-at-home.

Good point!  I hereby withdraw my suggested use of ultra-low priorities
for UP implementations of synchronize_kernel().  ;-)

> > I still prefer suppressing preemption on the read side, though I
> > suppose one could claim that this is only because I am -really-
> > used to it.  ;-)
>
> For a lot of reader cases non-preemption by threads is guaranteed anyways
--
> e.g.  anything that runs in interrupts, timers, tasklets and network
softirq.
> I think that already covers a lot of interesting cases.

Good point again!  For example, this does cover most of the TCP/IP
cases, right?

  Thanx, Paul

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

Re: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel

[Paul McKenney]

> > I see your point here, but need to think about it.  One question:
> > isn't it the case that the alternative to using synchronize_kernel()
> > is to protect the read side with explicit locks, which will themselves
> > suppress preemption?  If so, why not just suppress preemption on the
read
> > side in preemptible kernels, and thus gain the simpler implementation
> > of synchronize_kernel()?  You are not losing any preemption latency
> > compared to a kernel that uses traditional locks, in fact, you should
> > improve latency a bit since the lock operations are more expensive than
> > are simple increments and decrements.  As usual, what am I missing
> > here?  ;-)
>
> Already preempted tasks.

But if you are suppressing preemption in all read-side critical sections,
then wouldn't any already-preempted tasks be guaranteed to -not- be in
a read-side critical section, and therefore be guaranteed to be unaffected
by the update (in other words, wouldn't such tasks not need to be waited
for)?

> > Another approach would be to define a "really low" priority that noone
> > other than synchronize_kernel() was allowed to use.  Then the UP
> > implementation of synchronize_kernel() could drop its priority to
> > this level, yield the CPU, and know that all preempted tasks must
> > have obtained and voluntarily yielded the CPU before synchronize_kernel
()
> > gets it back again.
>
> Or "never", because I'm running RC5 etc. 8(.

U...  Good point!  Never mind use of low priorities in UP kernels
for synchronize_kernel()...

   Thanx, Paul

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

ATM with kernel 2.4.x

[Stéphane Borel]

Hello, we're trying to make a ForeRunnerLE 155 card work and we face
several problems:
-with kernel 2.4.3, we get unresolved symbol as we insmod lec
-with kernel 2.4.0-2.4.2 the sytem hangs when we try to start the atm
softs (ilmid)

So it only works with kernel <= 2.4.0-test12. We're using atm-0.78.

Does anyone know the status of atm under 2.4.x ?

Thank you for your help.

-- 
Stef
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 6.1.10 breaks 2.4.3-ac3

[Justin T. Gibbs]

>> To be expected as you didn't apply the patch to scsi_lib.c that makes
>> scsi_unblock_host() actually run the device queues to start the system
>> back up again.
>>
>
>There is no patch for 2.4.3-ac3. You could say, well if you want 6.1.10,
>use plain 2.4.3.

Actually, I would say, "Apply the 2.4.3 patch.  It will probably apply
cleanly to your kernel.  If it doesn't, and you don't know enough C
to correct the problem, you shouldn't be playing around with kernel
patches."

>That is not the way to do things. It is supposed that what people can get
>at your site is the aic driver.

Ahh, now I have people telling me what the content of my
site should be. ;-)

>If the patch contains something different, from the tarball, nobody knows.

I've figured this part out.

>If there is a bug in kernel, please mail it to lkml.

This has already happened in all cases save the functionality I've added
in 6.1.10.  I haven't even gotten around to announcing 6.1.10 yet, so
you can hardly fault me for not posting the SCSI layer changes yet.

Anyway, posting something to LK doesn't help people running already
released kernels.  Not everyone pushes the bleading edge by updating
their kernel daily.  These people should be able to get driver updates
if they need them.  As for people that run on the bleading edge, kernel
"releases" occur far too often and in too many flavors for me to track
them daily.  So, I work with Linus and Alan to get driver changes
into their trees and provide patches against released kernels.

>And in your site make VERY clear and independent the patch to correct
>that thing in main SCSI subsystem from the patch to upgrade your drivers.

People using the driver will have to have the other fixes.  They are
not separable.  Separating them will only lead to more confusion.  For
instance, 6.1.10 includes patches to Makefiles to correct for a link order
issue.  This is another *required* change for the driver to work well.
Does that need to be in a separate patch file too?

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

[Matti Aarnio]

On Tue, Apr 03, 2001 at 06:14:33PM -0700, Michael Peddemors wrote:
> This would be a shame, as he has been a valuable resource..
> Why has the list become more restrictive?

I just verified this particular aspect of VGER's MTA
configurations.  It has been unmodified since 21-Mar-2000,
that is, over a year...

If e.g. Rik's ISP has added their dialup pools to DUL registry,
that might be the reason behind the change.

> I think that this is one list where we have to keep the ability to post
> from individuals separate from the need to make sure that their ISP or
> company is compliant to a set a of rules..  The LKML can't toe the
> strictest of lines, without loosing some possibly valuable
> contributors..

Well, comparing how much spam goes thru linux-mm vs. linux-kernel,
I would say our methods are fairly effective.

The incentive behind the DUL is to force users not to post
straight out to the world, but to use their ISP's servers
for outbound email --- normal M$ users do that, after all.
Only spammers - and UNIX powerusers - want to post directly
to the world from dialups.  And UNIX powerusers should know
better, and be able to use ISP relay service anyway.

> On 03 Apr 2001 18:01:42 -0300, Rik van Riel wrote:
> > Hi,
> > 
> > this will be my last email to linux-kernel for a while since
> > davem and matti are using DUL on vger.kernel.org
> > 
> > If you need to know something, don't count on me posting
> > anything here. For memory management things, please use
> > [EMAIL PROTECTED] instead.
> > 
> > Rik
> > --
> > Virtual memory is like a game you can't win;
> > However, without VM there's truly nothing to lose...
> > 
> >   http://www.surriel.com/
> > http://www.conectiva.com/ http://distro.conectiva.com.br/
> 
> -- 
> "Catch the Magic of Linux..."
> 
> Michael Peddemors - Senior Consultant
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 6.1.10 and 2.4.4-pre1

[Justin T. Gibbs]

>   So I started again - installed redhat 7.0.9.
>   took 2.4.4-pre1  and patched it with 
>   linux-aic7xxx-6.1.10-2.4.3.patch
>
>   Patch applied cleanly but when I compile it complains a little:
>
>   In file included from aic7xxx_linux.c:131:
>   aic7xxx_osm.h: In function `ahc_pci_read_config':
>   aic7xxx_osm.h:862: warning: control reaches end of non-void function
>   
>   (for several .c files but always refers to 'ahc_pci_read_config')

This is because panic() is not marked as a "no return" function.  So,
GCC compains that, in the panic() case, we don't return a value from
this particular function.  Since we will never return in that case,
it is, at least in the aic7xxx driver, a harmless warning.

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

Lost timer configuration

[Shane Wegner]

Hi,

As this doesn't seem to do anything, I'm not too concerned. 
However,  I'm getting messages like these in my kernlog
quite regularly.

Apr  7 15:20:31 continuum kernel: probable hardware bug:
clock timer configuration lost - probably a VIA686a.
Apr  7 15:20:31 continuum kernel: probable hardware bug:
restoring chip configuration.
Apr  7 15:24:20 continuum kernel: probable hardware bug:
clock timer configuration lost - probably a VIA686a.
Apr  7 15:24:20 continuum kernel: probable hardware bug:
restoring chip configuration.
Apr  7 15:31:18 continuum kernel: probable hardware bug:
clock timer configuration lost - probably a VIA686a.
Apr  7 15:31:18 continuum kernel: probable hardware bug:
restoring chip configuration.
Apr  7 15:40:15 continuum kernel: probable hardware bug:
clock timer configuration lost - probably a VIA686a.
Apr  7 15:40:15 continuum kernel: probable hardware bug:
restoring chip configuration.

Actually it's a via 686B I believe.  It's an Abit vp6 dual
PIII board flashed to the latest bios revision from Abit. 
The odd thing is that it only occurs when copying files
from my cd-rom drive to harddisk.  The destination harddisk
is SCSI and the cd-rom is on its own IDE channel.  It does
not occur otherwise.

Just out of curiosity, if this was a hardware bug, wouldn't
they have fixed it with the 686B chipset?

Regards,
Shane


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

Re: P-III Oddity.

[Trevor Hemsley]

On Sat, 7 Apr 2001 19:58:15, Dave Jones <[EMAIL PROTECTED]> wrote:

> On Sat, 7 Apr 2001, Rogier Wolff wrote:
> 
> > One machine regularly crashes.
> > Linux version 2.2.16-3 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 
>19990314/Linux (egcs-1.1.2 release)) #1 Mon Jun 19 19:11:44 EDT 2000
> 
> Probably unrelated to the issue below. Try a more recent 2.2 ?
> 
> > cpuid level : 2
> 
> CPU serial number disabled.
> 
> > cpuid level : 3
> 
> CPU serial number enabled.

I've got this on my dual processor P-III 600MHz. One of the cpus in 
this box reports cpuid level 2, the other 3. Serial number is disabled
in the BIOS.

> You should be able to confirm this with my x86info tool.
> ftp://ftp.suse.com/pub/people/davej/x86info/x86info-1.0.tgz
> 
> If this isn't the case, can you send me the output of
> x86info -a on both CPUs ?

x86info v1.0.  Dave Jones 2001
Feedback to <[EMAIL PROTECTED]>.

Found 2 CPU
seax in: 0, eax = 0002 ebx = 756e6547 ecx = 6c65746e edx = 
49656e69
eax in: 1, eax = 0673 ebx =  ecx =  edx = 0383fbff
eax in: 2, eax = 03020101 ebx =  ecx =  edx = 0c040843
Vendor ID: "GenuineIntel"; Max CPUID level 2

Intel-specific functions
Family: 6 Model: 7 Type 0 [Pentium III/Pentium III Xeon Original OEM]
Stepping: 3
Reserved: 0

Feature flags 0383fbff:
FPUFloating Point Unit
VMEVirtual 8086 Mode Enhancements
DE Debugging Extensions
PSEPage Size Extensions
TSCTime Stamp Counter
MSRModel Specific Registers
PAEPhysical Address Extension
MCEMachine Check Exception
CX8COMPXCHG8B Instruction
APIC   On-chip Advanced Programmable Interrupt Controller present and 
enabled
SEPFast System Call
MTRR   Memory Type Range Registers
PGEPTE Global Flag
MCAMachine Check Architecture
CMOV   Conditional Move and Compare Instructions
FGPAT  Page Attribute Table
PSE-36 36-bit Page Size Extension
MMXMMX instruction set
FXSR   Fast FP/MMX Streaming SIMD Extensions save/restore
XMMStreaming SIMD Extensions instruction set
Instruction TLB: 4KB pages, 4-way set assoc, 32 entries
Instruction TLB: 4MB pages, fully assoc, 2 entries
Data TLB: 4KB pages, 4-way set assoc, 64 entries
L2 unified cache: 512KB, 4-way set assoc, 32 byte line size
Instruction cache: 16KB, 4-way set assoc, 32 byte line size
Data TLB: 4MB pages, 4-way set assoc, 8 entries
Data cache: 16KB, 2-way or 4-way set assoc, 32 byte line size
eax in: 0, eax = 0002 ebx = 756e6547 ecx = 6c65746e edx = 49656e69
eax in: 1, eax = 0673 ebx =  ecx =  edx = 0383fbff
eax in: 2, eax = 03020101 ebx =  ecx =  edx = 0c040843
Vendor ID: "GenuineIntel"; Max CPUID level 2

Intel-specific functions
Family: 6 Model: 7 Type 0 [Pentium III/Pentium III Xeon Original OEM]
Stepping: 3
Reserved: 0

Feature flags 0383fbff:
FPUFloating Point Unit
VMEVirtual 8086 Mode Enhancements
DE Debugging Extensions
PSEPage Size Extensions
TSCTime Stamp Counter
MSRModel Specific Registers
PAEPhysical Address Extension
MCEMachine Check Exception
CX8COMPXCHG8B Instruction
APIC   On-chip Advanced Programmable Interrupt Controller present and 
enabled
SEPFast System Call
MTRR   Memory Type Range Registers
PGEPTE Global Flag
MCAMachine Check Architecture
CMOV   Conditional Move and Compare Instructions
FGPAT  Page Attribute Table
PSE-36 36-bit Page Size Extension
MMXMMX instruction set
FXSR   Fast FP/MMX Streaming SIMD Extensions save/restore
XMMStreaming SIMD Extensions instruction set
Instruction TLB: 4KB pages, 4-way set assoc, 32 entries
Instruction TLB: 4MB pages, fully assoc, 2 entries
Data TLB: 4KB pages, 4-way set assoc, 64 entries
L2 unified cache: 512KB, 4-way set assoc, 32 byte line size
Instruction cache: 16KB, 4-way set assoc, 32 byte line size
Data TLB: 4MB pages, 4-way set assoc, 8 entries
Data cache: 16KB, 2-way or 4-way set assoc, 32 byte line size

/proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 7
model name  : Pentium III (Katmai)
stepping: 3
cpu MHz : 598.407
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse
bogomips: 1192.75

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

-- 
Trevor Hemsley, Brighton, UK.
[EMAIL PROTECTED]

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Jeff Garzik]

Gunther Mayer wrote:
> More module interdependencies == More complicated == More clueless users

With module autoloading, they don't have to care about module
interdependencies.  The primary thing people care about is what string
is passed to modprobe.  When that changes, things break.  As long as
that doesn't change, you are ok.  Who cares if two or five or ten helper
modules are automatically pulled in, and who cares if that list of
helper modules changes...  Functionally speaking, the user is completely
unaware of the change.


> Many users will be surprised if they must load another module (e.g."pci_multiio")
> to get their parallel and serial ports working.
> 
> Thus _must not_ happen in the stable release.

Agreed.

Jeff


-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Jeff Garzik]

Gunther Mayer wrote:
> Jeff Garzik wrote:
> > Gunther Mayer wrote:
> > > Hardware has always needed quirks (linux-2.4.3 has about 60 occurences
> > > of the word "quirks", not to mention workaround, blacklist and other synonyms)!
> > >
> > > Please apply this little patch instead of wasting time by finger-pointing
> > > and arguing.
> > >
> > > Martin, comments?
> >
> > Is Martin still alive?  He hasn't been active in PCI development well
> > over six months, maybe a year now.  Ivan (alpha hacker) appeared on the
> > scene to fix serious PCI bridge bugs, DaveM has added some PCI DMA
> > stuff, and I've added a couple driver-related things.  I haven't seen
> > code from Martin in a long long time, and only a comment or two in
> > recent memory.
> 
> See linux/MAINTAINERS for "PCI Subsystem", the attribute is even called:
>  "Supported:  Someone is actually paid to look after this".

Who cares... action not words.  :)  A lot of those MAINTAINERS entries
do not reflect reality [which is a bug, of course].

Jeff


-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: processes stuck in D state

[Barry K. Nathan]

Pau Aliagas wrote:
> Since 2.2.4-ac28 and 2.4.3 I keep on getting processes in D state that I
> cannot kill, usually mozilla or nautilus which use a large amount of RAM.

I don't have time to help debug this, but I'm getting this too, with
2.4.3 final. The previous kernel I ran was 2.4.3-pre4, and it did not
have this problem.

In my case, it's usually mozilla (I'm seeing this with the daily
snapshots, but not with mozilla-0.8.1, at least not yet), but at least
once I saw it with freeamp (2.1rc5) too.

-Barry K. Nathan <[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/

loop problems continue in 2.4.3

[Ian Eure]

i'm still having loopback problems with linux 2.4.3, even though they
were supposed to be fixed. it doesn't deadlock my maching right away
anymore, but instead causes a kernel panic after 4-6 uses of the loop
device.

the message i get is: "Kernel panic: Invalid blocksize passed to
set_blocksize"

100% reproducable. has anyone else seen this?

i did compile with gcc 2.92.3, and i have hedrick's ide patches
applied.

anyone else see this?

p.s. please cc: me in any replies, i'm not on the list.

-- 
 ___
| Ian Eure - <[EMAIL PROTECTED]> | "You're living in a facist world...
| -  Developer -| Freedom is a luxury." -Front Line
|-  InsynQ, Inc. -  | Assembly, "Digital Tension Dementia"
| Your Internet Utility Company.tm  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Multi-function PCI devices

[Jeff Garzik]

Linus Torvalds wrote:
> It only means that you should probably approach it as being a special
> "invisible PCI bridge", and basically have a specific driver for that
> chip that acts as a _bridge_ driver.
> 
> Writing a bridge driver is not that hard: your init routine will
> instantiate the devices behind the bridge (ie you would allocate two
> "struct pci_device" structures and you would add them to behind the
> "bridge", and you would make _those_ look like real serial and parallell
> devices.
> 
> See for example drivers/pcmcia/cardbus.c: cb_alloc() for how to create a
> new "pci_dev" (see the "for i = 0; i < fn ; i++)" loop: it creates the
> devices for each subfunction found behind the cardbus bridge.  It really
> boils down to "dev = kmalloc(); initialize_dev(dev); pci_insert_dev(dev,
> bus);").

Cool :)  Creative and interesting solution.

IMHO that's a slippery slope...  If you do this as a solution for
multifunction devices, you also have to consider even more stupid
hardware which exports one PCI function, but multiple BARs for different
purposes...

Another problem, which I have yet to think much about, is doing a
reverse mapping after what you just describe:  how does one figure out
that a bridge+devices is really a single hardware device?  Answering
that question is interesting for NICs as well, because 4-port NICs often
appear as four devices behind a bridge.  Some operations, such as
sharing an EEPROM across four ports, or setting a special flag if you
are quad-port hardware, require that knowledge.  [ugly hacks exist now
to get around our lack of such knowledge]

Jeff


-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 6.1.10 and 2.4.4-pre1

[lists]

   I had tried 6.1.8 + 2.4.3 and had problems which included messages like 
   'aic7xxx_abort returns 8194' and machine froze up shortly after X started.
   This on redhat 7.0. Sorry but since I was unable to even boot back the
   prev kernel (2.4.0) I cant provide any more detailed information. I have
   been following to see a few other folks have had some issues with scsi as well.

   I have 2 lvd scsi disks and one ide, AH 2940U2 - top of lilo included below -
   and bios boot order is scsi first.

   So I started again - installed redhat 7.0.9.
   took 2.4.4-pre1  and patched it with 
   linux-aic7xxx-6.1.10-2.4.3.patch

   Patch applied cleanly but when I compile it complains a little:

   In file included from aic7xxx_linux.c:131:
   aic7xxx_osm.h: In function `ahc_pci_read_config':
   aic7xxx_osm.h:862: warning: control reaches end of non-void function
   
   (for several .c files but always refers to 'ahc_pci_read_config')

   In file included from ... include/linux/raid/md.h:50,
   from init/main.c:24: ..include/linux/raid/md_k.h: In function `pers_to_level':
   raid/md_k.h:39: warning: control reaches end of non-void function

   Do I need to be concerned here?  I dont whether the presumed missing return is
   a bad thing or not. 

   I have not yet tried to boot this kernel.

   Also


# lilo.conf
boot=/dev/sda
disk=/dev/sda
 bios=0x80
disk=/dev/sdb
 bios=0x81
disk=/dev/hda
 bios=0x82
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
lba32
default=linux

...

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

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Jeff Garzik]

Gunther Mayer wrote:
> 
> Jeff Garzik wrote:
> >
>  Like I mentioned in a
> > previous message, the Via parport code is ugly and should go into a Via
> > superio driver.  It is simply not scalable to consider the alternative
> > -- add superio code to parport_pc.c for each ISA bridge out there.  I
> > think the same principle applies to this discussion as well.
> 
> Yes, superio will go away and replaced by user level utility:
> http://home.t-online.de/home/gunther.mayer/lssuperio-0.61.tar.bz2

The entire point of superio is -not- configuration.  That's what your
BIOS setup does, and/or user-level utilities.

The point of superio support is that you can obtain 100% accurate probe
information for legacy ISA devices, by looking at the information
exported by the ISA bridge.  There is no need for "probing" per se,
because you know whether or not the parallel port is enabled, exactly
what IRQ it's on, and exactly what DMA channel it uses.

So, a superio probe occurs first because it provides the maximum
information at the least cost.  Since ISA devices must still be
supported, the ISA probe should come after the PCI probe (which includes
PCI superio stuff).  ISA probes to ports already registered via the
superio probe fail at the request_region level, avoiding any unnecessary
hardware access at those ports.  There are tertiary benefits to such a
scheme as well, I'll be glad to elaborate on if people are interested in
the nitty gritty (read: boring) details.

Jeff


-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Tim Waugh]

On Sat, Apr 07, 2001 at 10:21:11PM +0200, Gunther Mayer wrote:

> Many users will be surprised if they must load another module
> (e.g."pci_multiio") to get their parallel and serial ports working.
> 
> Thus _must not_ happen in the stable release.

Yes, I agree.  I am planning for parport_serial.c to end up as part of
parport_pc.o for 2.4.

Tim.
*/

 PGP signature

Re: Multi-function PCI devices

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Michael Reinelt  <[EMAIL PROTECTED]> wrote:
>
>The card shows up on the PCI bus as one device. For the card provides
>both serial and parallel ports, it will be driven by two subsystems, the
>serial and the parallel driver.

Tough.  The PCI specification has a perfectly good way to handle this,
namely by having subfunctions on the same chip.  The particular chip
designer was lazy or something, and didn't do it the proper way.  Which
means that you cannot, and should not, use a generic PCI driver for the
chip.  Because it doesn't show up as separate devices for the separate
functions. 

Now, that doesn't mean that you can't use the card, or the existing
drivers. It only means that you should fix up the total braindamage of
the hardware.

It only means that you should probably approach it as being a special
"invisible PCI bridge", and basically have a specific driver for that
chip that acts as a _bridge_ driver.

Writing a bridge driver is not that hard: your init routine will
instantiate the devices behind the bridge (ie you would allocate two
"struct pci_device" structures and you would add them to behind the
"bridge", and you would make _those_ look like real serial and parallell
devices. 

See for example drivers/pcmcia/cardbus.c: cb_alloc() for how to create a
new "pci_dev" (see the "for i = 0; i < fn ; i++)" loop: it creates the
devices for each subfunction found behind the cardbus bridge.  It really
boils down to "dev = kmalloc(); initialize_dev(dev); pci_insert_dev(dev,
bus);"). 

At which point you can happily use the current drivers without any
modifications. 

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

Re: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel

[Andi Kleen]

On Fri, Apr 06, 2001 at 06:25:36PM -0700, Paul McKenney wrote:
> I see your point here, but need to think about it.  One question:
> isn't it the case that the alternative to using synchronize_kernel()
> is to protect the read side with explicit locks, which will themselves
> suppress preemption?  If so, why not just suppress preemption on the read
> side in preemptible kernels, and thus gain the simpler implementation
> of synchronize_kernel()?  You are not losing any preemption latency
> compared to a kernel that uses traditional locks, in fact, you should
> improve latency a bit since the lock operations are more expensive than
> are simple increments and decrements.  As usual, what am I missing
> here?  ;-)

You miss nothing I think. In fact it's already used (see below) 

> 
> > > 2.   Isn't it possible to get in trouble even on a UP if a task
> > >  is preempted in a critical region?  For example, suppose the
> > >  preempting task does a synchronize_kernel()?
> >
> > Ugly. I guess one way to solve it would be to readd the 2.2 scheduler
> > taskqueue, and just queue a scheduler callback in this case.
> 
> Another approach would be to define a "really low" priority that noone
> other than synchronize_kernel() was allowed to use.  Then the UP
> implementation of synchronize_kernel() could drop its priority to
> this level, yield the CPU, and know that all preempted tasks must
> have obtained and voluntarily yielded the CPU before synchronize_kernel()
> gets it back again.

That just would allow nasty starvation, e.g. when someone runs a cpu intensive
screensaver or a seti-at-home.

> 
> I still prefer suppressing preemption on the read side, though I
> suppose one could claim that this is only because I am -really-
> used to it.  ;-)

For a lot of reader cases non-preemption by threads is guaranteed anyways -- 
e.g.  anything that runs in interrupts, timers, tasklets and network softirq.  
I think that already covers a lot of interesting cases.


-Andi


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

Unresolved symbol in 2.4.4p1, ia32

[Jonathan Hudson]

depmod: *** Unresolved symbols in 
/lib/modules/2.4.4-pre1/kernel/drivers/ide/ide-cd.o
depmod: strstr

depmod: *** Unresolved symbols in 
/lib/modules/2.4.4-pre1/kernel/drivers/parport/parport.o
depmod: strstr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Config files for Compaq Presario 1800T Laptop

[Michael D. Crawford]

I have found that kernel 2.4.3 and XFree86 4.0.3 work very well on my
Compaq Presario 1800T laptop.

I did a lot of fiddling to get things just right, so to make things
easer for other Presario 1800 owners I have archived my kernel .config,
lilo.conf and XF86Config files here:

http://goingware.com/laptop/linux/config/

Have you figured out the configuration for some hard-to-figure-out
hardware?  Post the config files on your website!

The only real problem I have is that the DEC 21143 ethernet chip causes
trouble if I do a soft reboot between Windows and any other operating
system.  If I start with Windows 98 and reboot into either Linux or the
BeOS, the ethernet won't work.  If I start with Linux 2.4.3 and reboot
into Windows 98, Windows will hang partway through boot.  Everything
works fine if I power off before I go between Windows and another OS.

I am using the de4x5 driver for the chip.  That and the tulip driver
both claim to offer support for it, but only de4x5 actually works. 
Curiously, at some point I pulled a development version of the tulip.c
driver source off the author's ftp site and compiled it into a 2.2
kernel, and found that it worked fine.  I don't think either driver
works in the stock 2.2 kernels that I've tried.

XFree86 4.0.3 works well with 2D accelleration but not 3D (DRI).  The
ATI Rage 3D Mobility Pro is an AGP 3D accellerated chip but is uses the
Mach64 driver rather than the ati128; I don't think DRI has been done
for Mach64 yet (correct me if it should work, and I'll keep trying).

I can use the atyfb framebuffer driver in unaccellerated mode but not
accellerated.

Regards,

Mike Crawford
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]

   Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Gérard Roudier wrote:
> 
> On Sat, 7 Apr 2001, Tim Waugh wrote:
> 
> > On Sat, Apr 07, 2001 at 08:42:35PM +0200, Gunther Mayer wrote:
> >
> > > Please apply this little patch instead of wasting time by
> > > finger-pointing and arguing.
> >
> > This patch would make me happy.
> >
> > It would allow support for new multi-IO cards to generally be the
> > addition of about two lines to two files (which is currently how it's
> > done), rather than having separate mutant hybrid monstrosity drivers
> > for each card (IMHO)..
> 
> It is possible to design a single function PCI device that is able to do
> everything. Your approach is just encouraging this kind of monstrosity.
> Such montrosity will look like some single-IRQ capable ISA remake, thus
> worse than 20 years old ISA.
> 
> If we want to encourage that, then we want to stay stupid for life, in my
> nervous opinion.

If you want to discourage hardware vendors, they will stay with Windows.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i810_audio.c: Clicks while playing audio

[Doug Ledford]

Naren Devaiah wrote:
> 
> Hi,
> 
> On a HP Vectra VL 400 with a i815 motherboard playing a .wav file (haven't
> tried anything else) causes the sound to be played with a lot of periodic
> clicks.
> The kernel is 2.4.3
> dmesg shows:
> Intel 810 + AC97 Audio, version 0.01, 17:25:00 Apr  6 2001
> PCI: Enabling device 00:1f.5 ( -> 0001)
> PCI: Found IRQ 9 for device 00:1f.5
> PCI: The same IRQ used for device 00:1f.3
> PCI: Setting latency timer of device 00:1f.5 to 64
> i810: Intel ICH 82801AA found at IO 0x1300 and 0x1200, IRQ 9
> ac97_codec: AC97 Audio codec, id: 0x4352:0x5934 (Cirrus Logic CS4299)
> i810_audio: 9568 bytes in 50 milliseconds
> i810_audio: DMA overrun on send
> i810_audio: DMA overrun on send
> 
> lsmod show:
> root@darkstar:~# lsmod
> Module  Size  Used by
> i810_audio 14084   0
> ac97_codec  7908   0  [i810_audio]
> 
> My question is: What does "DMA overrun on send" mean?

It means it sounds like you have an older version of the driver (older here
means "not my latest patch").  I sent my stuff to Alan, and it was in the ac
series kernels, but I don't know what happened to make it into 2.4.3.  I'm
fixing one last known bug in the driver tonight, and when I'm done I'll put a
patch against 2.4.3 on my web site and drop a note here.

-- 

 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: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Jeff Garzik wrote:
> 
 Like I mentioned in a
> previous message, the Via parport code is ugly and should go into a Via
> superio driver.  It is simply not scalable to consider the alternative
> -- add superio code to parport_pc.c for each ISA bridge out there.  I
> think the same principle applies to this discussion as well.  

Yes, superio will go away and replaced by user level utility:
http://home.t-online.de/home/gunther.mayer/lssuperio-0.61.tar.bz2

PNPBIOS and ACPI will help to configure parallel ports (and others),
after some issues have been resolved.

Again this will be builtin to parport (and not parport_acpi.o etc)
to make it failproof.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Jeff Garzik wrote:
> 
> Gunther Mayer wrote:
> > Hardware has always needed quirks (linux-2.4.3 has about 60 occurences
> > of the word "quirks", not to mention workaround, blacklist and other synonyms)!
> >
> > Please apply this little patch instead of wasting time by finger-pointing
> > and arguing.
> >
> > Martin, comments?
> 
> Is Martin still alive?  He hasn't been active in PCI development well
> over six months, maybe a year now.  Ivan (alpha hacker) appeared on the
> scene to fix serious PCI bridge bugs, DaveM has added some PCI DMA
> stuff, and I've added a couple driver-related things.  I haven't seen
> code from Martin in a long long time, and only a comment or two in
> recent memory.

See linux/MAINTAINERS for "PCI Subsystem", the attribute is even called:
 "Supported:  Someone is actually paid to look after this".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Jeff Garzik wrote:
> 
> Tim Waugh wrote:
> > It would allow support for new multi-IO cards to generally be the
> > addition of about two lines to two files (which is currently how it's
> > done), rather than having separate mutant hybrid monstrosity drivers
> > for each card (IMHO)..
> 
> ;-)
> 
> My point of view is that hacking the kernel so that two device drivers
> can pretend they are not driving the same hardware is silly.  With such
> hardware there are always inter-dependencies, and you can either hack
> special case code into two or more drivers, or create one central
> control point from which knowledge is dispatched.  Like I mentioned in a

My point of view is making it easy for the average user.
This is the same as making it easy for maintainers of hardware drivers !

More module interdependencies == More complicated == More clueless users

Many users will be surprised if they must load another module (e.g."pci_multiio")
to get their parallel and serial ports working.

Thus _must not_ happen in the stable release.

Regards, Gunther
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 for 2.5] preemptible kernel

[Rusty Russell]

In message  you write:
> > Priority inversion is not handled in Linux kernel ATM BTW, there
> > are already situations where a realtime task can cause a deadlock
> > with some lower priority system thread (I believe there is at least
> > one case of this known with realtime ntpd on 2.4)
> 
> I see your point here, but need to think about it.  One question:
> isn't it the case that the alternative to using synchronize_kernel()
> is to protect the read side with explicit locks, which will themselves
> suppress preemption?  If so, why not just suppress preemption on the read
> side in preemptible kernels, and thus gain the simpler implementation
> of synchronize_kernel()?  You are not losing any preemption latency
> compared to a kernel that uses traditional locks, in fact, you should
> improve latency a bit since the lock operations are more expensive than
> are simple increments and decrements.  As usual, what am I missing
> here?  ;-)

Already preempted tasks.

> Another approach would be to define a "really low" priority that noone
> other than synchronize_kernel() was allowed to use.  Then the UP
> implementation of synchronize_kernel() could drop its priority to
> this level, yield the CPU, and know that all preempted tasks must
> have obtained and voluntarily yielded the CPU before synchronize_kernel()
> gets it back again.

Or "never", because I'm running RC5 etc. 8(.

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

Re: P-III Oddity.

[Dave Jones]

On Sat, 7 Apr 2001, Rogier Wolff wrote:

> One machine regularly crashes.
> Linux version 2.2.16-3 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 
>19990314/Linux (egcs-1.1.2 release)) #1 Mon Jun 19 19:11:44 EDT 2000

Probably unrelated to the issue below. Try a more recent 2.2 ?

> cpuid level : 2

CPU serial number disabled.

> cpuid level : 3

CPU serial number enabled.


You should be able to confirm this with my x86info tool.
ftp://ftp.suse.com/pub/people/davej/x86info/x86info-1.0.tgz

If this isn't the case, can you send me the output of
x86info -a on both CPUs ?

Note, that 2.4 should be disabling the serial number by
default.
(Unless you booted with the `serialnumber' bootarg.)

regards,

Dave.

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

Re: Multi-function PCI devices

[Tim Waugh]

On Sat, Apr 07, 2001 at 03:40:13PM -0400, Jeff Garzik wrote:

> Who said you have to have a separate driver for every single multi-IO
> card?  A single driver could support all serial+parallel multi-IO cards,
> for example.

Okay, I misunderstood.  I'll take a look at doing this for 2.4.

First of all, parport_pc will need to export the equivalent of
register_serial (its equivalent is probably parport_pc_probe_port).
[It actually already does this (conditionally on parport_cs).]

drivers/parport/parport_serial.c sound okay, or is a different place
better?

Tim.
*/

 PGP signature

[PATCH][RFC] appling pressure to icache and dcache - simplified

[Ed Tomlinson]

Hi,

Rik asked, "Can it be made simpler?"

So I went back to the basics, inserted a printk in kswapd and watched
the dentry_stat and inodes_stat numbers for a while.   I observed
the following pattern.  The dentry cache grows as does the number of 
unused entries in it.  Unless we shrink this cache objects do not seem
to be reused.  At the same time the inode cache usually kept about 15% 
free.

At this point I starting to shrink the dcache.  The goal being to keep 
the size of the cache as observed in /proc/slabinfo reasonable without 
much overhead.  From experimenting, it turns out that if the shrink
call is made when there is over 50% free space the cache stays small.
Using 66% is not quite as aggressive but achieves its effect with about
half the shrink calls.

With the pressure on the dcache, I looked at the icache numbers.  With  
the dcache shrinking the amount of free space in the icache was much 
higher.  It turns out that using the same logic as above with, 80% as 
the amount of free space, it works well.

Here are the results against 2.4.3-ac3

Thoughs?

-
--- linux.ac3.orig/mm/vmscan.c  Sat Apr  7 15:20:49 2001
+++ linux/mm/vmscan.c   Sat Apr  7 12:37:27 2001
@@ -997,6 +997,21 @@
 */
refill_inactive_scan(DEF_PRIORITY, 0);
 
+   /* 
+* Here we apply pressure to the dcache and icache.
+* The nr_inodes and nr_dentry track the used part of
+* the slab caches.  When there is more than X% objs free
+* in these lists, as reported by the nr_unused fields,
+* there is a very good chance that shrinking will free
+* pages from the slab caches.  For the dcache 66% works,
+* and 80% seems optimal for the icache.
+*/
+
+   if ((dentry_stat.nr_unused+(dentry_stat.nr_unused>>1)) > 
+dentry_stat.nr_dentry)
+   shrink_dcache_memory(DEF_PRIORITY, GFP_KSWAPD);
+   if ((inodes_stat.nr_unused+(inodes_stat.nr_unused>>2)) > 
+inodes_stat.nr_inodes)
+   shrink_icache_memory(DEF_PRIORITY, GFP_KSWAPD);
+
/* Once a second, recalculate some VM stats. */
if (time_after(jiffies, recalc + HZ)) {
recalc = jiffies;
-

Ed Tomlinson <[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: Multi-function PCI devices

[Jeff Garzik]

Tim Waugh wrote:
> If we have to do this, then Gunther's approach (multifunc_quirks or
> whatever) looks a lot better than having a separate driver for every
> single multi-IO card.

Who said you have to have a separate driver for every single multi-IO
card?  A single driver could support all serial+parallel multi-IO cards,
for example.

Due to the differences in busses and hardware implementations and such,
typically you want to provide two pieces of code for each common
hardware subsystem (like "parport" or "serial"):  foo_lib.c and
foo_card.c.

foo_lib.c is the guts of the hardware support, and it provides an
[un]register_foodev() interface.  foo_card.c is totally separate, and it
holds the PCI or ISAPNP or USB device ids.  foo_card does all the
hardware detection, and calls register_foodev() for each hardware device
it finds.

For small subsystems, this is obviously overkill.  But for common
subsystems like serial or parport, this makes complete sense.  If an
sbus device appears that acts just like a PC parallel port, all DaveM
needs to do is write a parport_sbus.c shim which calls
register_foodev().  No patching one central file necessary to add
support for a new bus.

Regards,

Jeff


-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 for 2.5] preemptible kernel

[Paul McKenney]

Andi, thank you for the background!  More comments interspersed...

> On Fri, Apr 06, 2001 at 04:52:25PM -0700, Paul McKenney wrote:
> > 1.   On a busy system, isn't it possible for a preempted task
> >  to stay preempted for a -long- time, especially if there are
> >  lots of real-time tasks in the mix?
>
> The problem you're describing is probably considered too hard to
> solve properly (bad answer, but that is how it is currently)
>
> Yes there is. You can also force a normal (non preemptive) kernel
> into complete livelock by just giving it enough network traffic
> to do, so that it always works in the high priority network
> softirq or doing the same with some other interrupt.
>
> Just when this happens a lot of basic things will stop working (like
> page cleaning, IO flushing etc.), so your callbacks or module unloads
> not running are probably the least of your worries.
>
> The same problem applies to a smaller scale to real time processes;
> kernel services normally do not run real-time, so they can be starved.
>
> Priority inversion is not handled in Linux kernel ATM BTW, there
> are already situations where a realtime task can cause a deadlock
> with some lower priority system thread (I believe there is at least
> one case of this known with realtime ntpd on 2.4)

I see your point here, but need to think about it.  One question:
isn't it the case that the alternative to using synchronize_kernel()
is to protect the read side with explicit locks, which will themselves
suppress preemption?  If so, why not just suppress preemption on the read
side in preemptible kernels, and thus gain the simpler implementation
of synchronize_kernel()?  You are not losing any preemption latency
compared to a kernel that uses traditional locks, in fact, you should
improve latency a bit since the lock operations are more expensive than
are simple increments and decrements.  As usual, what am I missing
here?  ;-)

> > 2.   Isn't it possible to get in trouble even on a UP if a task
> >  is preempted in a critical region?  For example, suppose the
> >  preempting task does a synchronize_kernel()?
>
> Ugly. I guess one way to solve it would be to readd the 2.2 scheduler
> taskqueue, and just queue a scheduler callback in this case.

Another approach would be to define a "really low" priority that noone
other than synchronize_kernel() was allowed to use.  Then the UP
implementation of synchronize_kernel() could drop its priority to
this level, yield the CPU, and know that all preempted tasks must
have obtained and voluntarily yielded the CPU before synchronize_kernel()
gets it back again.

I still prefer suppressing preemption on the read side, though I
suppose one could claim that this is only because I am -really-
used to it.  ;-)

  Thanx, Paul

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

P-III Oddity.

[Rogier Wolff]

Hi,

One machine regularly crashes.  

Linux version 2.2.16-3 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 
19990314/Linux (egcs-1.1.2 release)) #1 Mon Jun 19 19:11:44 EDT 2000
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 7
model name  : Pentium III (Katmai)
stepping: 3
cpu MHz : 551.255
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 
mmx fxsr xmm
bogomips: 1101.00


Another one, I don't really know, but I was comparing /proc/cpuinfo on
these two machines as they are supposed to have the same CPU: 


/home/wolff> cat /proc/version /proc/cpuinfo
Linux version 2.4.3 (wolff@cave) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 
release)) #52 Fri Apr 6 14:43:38 MEST 2001
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 7
model name  : Pentium III (Katmai)
stepping: 3
cpu MHz : 551.263
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 3
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 
mmx fxsr sse
bogomips: 1101.00

/home/wolff> 


Everything is exactly the same, except for the "cpuid level". Once the
cpu family and model are the same, I'd expect the cpuid level to be
the same too. In this case even the stepping is the same, so how can
the cpuid level differ? 

Maybe this is a reporting difference between 2.4.3 and 2.2.16

Anybody care to shed some light on this?

Roger. 

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

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gérard Roudier]

On Sat, 7 Apr 2001, Tim Waugh wrote:

> On Sat, Apr 07, 2001 at 08:42:35PM +0200, Gunther Mayer wrote:
> 
> > Please apply this little patch instead of wasting time by
> > finger-pointing and arguing.
> 
> This patch would make me happy.
> 
> It would allow support for new multi-IO cards to generally be the
> addition of about two lines to two files (which is currently how it's
> done), rather than having separate mutant hybrid monstrosity drivers
> for each card (IMHO)..

It is possible to design a single function PCI device that is able to do
everything. Your approach is just encouraging this kind of monstrosity.
Such montrosity will look like some single-IRQ capable ISA remake, thus
worse than 20 years old ISA.

If we want to encourage that, then we want to stay stupid for life, in my
nervous opinion.

  Gérard.


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

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Tim Waugh]

On Sat, Apr 07, 2001 at 03:23:12PM -0400, Jeff Garzik wrote:

> It's just ugly to keep hacking in special cases to handle hardware
> that is multifunction like this.

I just don't want it to be a huge chore to add support for these
cards.

Would everyone be happy if (say) drivers/parport/parport_serial.c had
a table and a generic version of your example function, so that the
table somehow described the multifunction cards out there?

Tim.
*/

 PGP signature

Re: Multi-function PCI devices

[Jeff Garzik]

Tim Waugh wrote:
> 
> On Sat, Apr 07, 2001 at 01:23:27PM -0400, Jeff Garzik wrote:
> 
> > You asked in your last message to show you code, here is a short
> > example.  Note that I would love to rip out the SUPERIO code in parport
> > and make it a separate driver like this short, contrived example.  Much
> > more modular than the existing solution.
> 
> (The superio code is on its way out anyway, for different reasons..)

I think there will be further discussion on this :)

> More modular?  Yes, it adds another module to support a card, so yes
> there are more modules.
> 
> But with the multifunction_quirks approach, support is a question of
> adding two lines in a table.

struct pci_driver is going to become struct driver, don't forget.  With
that in mind, the "multifunction_quirks" patch appears even more of a
bus-specific hack.

Why do you want to dirty the soon-to-be generic driver API for stupid
hardware?

It takes two seconds to write a shim driver as I have described, and
further a shim driver is not necessary on sensible hardware.

Jeff


-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Jeff Garzik]

Tim Waugh wrote:
> It would allow support for new multi-IO cards to generally be the
> addition of about two lines to two files (which is currently how it's
> done), rather than having separate mutant hybrid monstrosity drivers
> for each card (IMHO)..

;-)

My point of view is that hacking the kernel so that two device drivers
can pretend they are not driving the same hardware is silly.  With such
hardware there are always inter-dependencies, and you can either hack
special case code into two or more drivers, or create one central
control point from which knowledge is dispatched.  Like I mentioned in a
previous message, the Via parport code is ugly and should go into a Via
superio driver.  It is simply not scalable to consider the alternative
-- add superio code to parport_pc.c for each ISA bridge out there.  I
think the same principle applies to this discussion as well.  It's just
ugly to keep hacking in special cases to handle hardware that is
multifunction like this.

Jeff


-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Multi-function PCI devices

[Tim Waugh]

On Sat, Apr 07, 2001 at 03:01:57PM +0200, Gérard Roudier wrote:

> PCI multi I/O boards _shall_ provide a separate function for each kind of
> IO. Those that donnot are kind of PCI messy IO boards.

But they don't.  What are you going to do about it?

> Cheap for whom?

For the guys who make them, and for the ones who buy them.  Yes, it
sucks.

> > Again, how about other cards? Are there any PCI Multi-I/O-cards out
> > there, which are supported by linux? I'd be interested in how the driver
> > looks like
> 
> I donnot know and will never know. I only use hardware that does not look
> too shitty to me. Time is too much important for me to waste even seconds
> with dubious hardware. :)

Good luck finding a card that gets multifunction I/O right without
wasting any seconds then.

For a list of cards that are supported, or for which patches exist
(using the 'two lines in a table' approach), see
http://people.redhat.com/twaugh/parport/cards.html>.

Tim.
*/

 PGP signature

Re: Multi-function PCI devices

[Tim Waugh]

On Sat, Apr 07, 2001 at 01:23:27PM -0400, Jeff Garzik wrote:

> You asked in your last message to show you code, here is a short
> example.  Note that I would love to rip out the SUPERIO code in parport
> and make it a separate driver like this short, contrived example.  Much
> more modular than the existing solution.

(The superio code is on its way out anyway, for different reasons..)

More modular?  Yes, it adds another module to support a card, so yes
there are more modules.

But with the multifunction_quirks approach, support is a question of
adding two lines in a table.

Tim.
*/

 PGP signature

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Tim Waugh]

On Sat, Apr 07, 2001 at 02:53:23PM -0400, Jeff Garzik wrote:

> As has been explained, the current API supports this just fine without
> modification.

The current API makes it much harder to support the breadth of
hardware we're talking about.

The hardware has quirks, and this quirk is so common that it is
absolutely the norm.

Tim.
*/

 PGP signature

Re: 2.4 kernel hangs on 486 machine at boot

[Brian Gerst]

Pavel Machek wrote:
> 
> Hi!
> 
> > > > Problem: Linux kernel 2.4 consistently hangs at boot on 486 machine
> > > >
> > > > Shortly after lilo starts the kernel it hangs at the following message:
> > > > Checking if this processor honours the WP bit even in supervisor mode...
> > > > 
> > >
> > > Does this happen on 2.4.3-ac kernel trees ? I thought i had it zapped
> >
> > Yes, that fix in -ac should take care of it.  As to why only the 486
> > showed the problem, most 386's will not fault on the write protected
> > page (the whole reason for this test) and pentiums and later don't run
> > the test at all (assumed good).
> 
> We should not "assume good" -- to catch bugs like this one.

Well, in this case we cannot do the test if we enabled PSE (we would
mark the whole 4MB page read-only).  The test would have to use a
different page.

--
Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Tim Waugh]

On Sat, Apr 07, 2001 at 08:42:35PM +0200, Gunther Mayer wrote:

> Please apply this little patch instead of wasting time by
> finger-pointing and arguing.

This patch would make me happy.

It would allow support for new multi-IO cards to generally be the
addition of about two lines to two files (which is currently how it's
done), rather than having separate mutant hybrid monstrosity drivers
for each card (IMHO)..

Tim.
*/

 PGP signature

Re: Multi-function PCI devices

[Tim Waugh]

On Sat, Apr 07, 2001 at 11:04:38AM +0200, Gérard Roudier wrote:

> Given your description, this board is certainly not a multi-fonction PCI
> device. Multi-function PCI devices provide separate resources for each
> function in a way that allows each function to be driven by separate
> software drivers.

Yes, but the vendor screwed it up (probably to save money).  This is
_very_ common.  It is very unusual to have a multifunction I/O card
that gets this right (in fact Lava is the only one I can think of
off-hand).

> Band-aiding the kernel code in order to cope with such brain-deaded
> hardware would be a pity, in my opinion. Burden must stay where it
> is deserved.

If we have to do this, then Gunther's approach (multifunc_quirks or
whatever) looks a lot better than having a separate driver for every
single multi-IO card.

Tim.
*/

 PGP signature

Re: aic7xxx 6.1.10 breaks 2.4.3-ac3

[J . A . Magallon]

On 04.07 Justin T. Gibbs wrote:
> 
> That's not a sufficient way to upgrade.  The tar files are there for
> people who are porting the driver to other platforms.  You should always
> use the patches to upgrade as they often touch other portions of the
> Linux kernel that need fixes in order to work correctly with the
> aic7xxx driver.
> 
> >6.1.10 just stops after the init messages and stays there forever.
> 
> To be expected as you didn't apply the patch to scsi_lib.c that makes
> scsi_unblock_host() actually run the device queues to start the system
> back up again.
>

There is no patch for 2.4.3-ac3. You could say, well if you want 6.1.10,
use plain 2.4.3.
That is not the way to do things. It is supposed that what people can get
at your site is the aic driver. If the patch contains something different,
from the tarball, nobody knows.

If there is a bug in kernel, please mail it to lkml.
And in your site make VERY clear and independent the patch to correct
that thing in main SCSI subsystem from the patch to upgrade your drivers.

> I'm working on an html page for my site that should explain all of
> the upgrade proceedures.
> 

Good idea.

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

Linux werewolf 2.4.3-ac3 #1 SMP Thu Apr 5 00:28:45 CEST 2001 i686

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

Compaq proliant ML-350 - IDE & SCSI

[Alexandru Barloiu Nicolae]

I am trying to use the DMA on the ide drives. After the reboot Dma is
enabled but if I don't disable it with hdparm the system freezes at heavy
work (copy something from a drive to the other). The SCSI works ok. Without
the DMA the system barely moves

root@light:~# hdparm  -t -T /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  4.83 seconds = 26.50 MB/sec
 Timing buffered disk reads:  64 MB in 81.21 seconds =806.99 kB/sec

Any ideas what's wrong?

dmesg:
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ServerWorks OSB4: IDE controller on PCI bus 00 dev 79
keyboard: Timeout - AT keyboard not present?
keyboard: Timeout - AT keyboard not present?
ServerWorks OSB4: chipset revision 0
ServerWorks OSB4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:DMA, hdd:DMA
hda: WDC WD200EB-00BHF0, ATA DISK drive
hdb: Compaq CRD-8402B, ATAPI CD/DVD-ROM drive
hdc: QUANTUM FIREBALLP AS40.0, ATA DISK drive
hdd: QUANTUM FIREBALLP AS40.0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=2586/240/63, UDMA(33)
hdc: 80315072 sectors (41121 MB) w/1902KiB Cache, CHS=79677/16/63, UDMA(33)
hdd: 80315072 sectors (41121 MB) w/1902KiB Cache, CHS=79677/16/63, UDMA(33)
hdb: ATAPI 40X CD-ROM drive, 128kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
SCSI subsystem driver Revision: 1.00
sym53c8xx: at PCI bus 1, device 4, function 0
sym53c8xx: 53c896 detected
PCI: Enabling device 01:04.1 (0154 -> 0157)
sym53c8xx: at PCI bus 1, device 4, function 1
sym53c8xx: 53c896 detected
sym53c896-0: rev 0x7 on pci bus 1 device 4 function 0 irq 16
sym53c896-0: ID 7, Fast-40, Parity Checking
sym53c896-0: handling phase mismatch from SCRIPTS.
sym53c896-1: rev 0x7 on pci bus 1 device 4 function 1 irq 16
sym53c896-1: ID 7, Fast-40, Parity Checking
sym53c896-1: handling phase mismatch from SCRIPTS.
scsi0 : sym53c8xx-1.7.3a-20010304
scsi1 : sym53c8xx-1.7.3a-20010304
  Vendor: COMPAQModel: BD0186349BRev: 3B12
  Type:   Direct-Access  ANSI SCSI revision: 02
  Vendor: COMPAQModel: BD0186349BRev: 3B12
  Type:   Direct-Access  ANSI SCSI revision: 02
  Vendor: COMPAQModel: BD0186349BRev: 3B12
  Type:   Direct-Access  ANSI SCSI revision: 02
  Vendor: COMPAQModel: BD0186349BRev: 3B12
  Type:   Direct-Access  ANSI SCSI revision: 02
ncr53c8xx: at PCI bus 1, device 4, function 0
ncr53c8xx: IO region 0x2000[0..127] is in use
ncr53c8xx: at PCI bus 1, device 4, function 1
ncr53c8xx: IO region 0x2400[0..127] is in use
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
Detected scsi disk sdb at scsi0, channel 0, id 1, lun 0
Detected scsi disk sdc at scsi0, channel 0, id 2, lun 0
Detected scsi disk sdd at scsi0, channel 0, id 3, lun 0

.config:
# 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=y
# 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
# CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set
# CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set
# CONFIG_BLK_DEV_IDEDISK_WD is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
# CONFIG_BLK_DEV_TIVO is not set
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_CMD640_ENHANCED=y
# CONFIG_BLK_DEV_ISAPNP is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_PCI_WIP=y
CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_AEC62XX_TUNING=y
CONFIG_BLK_DEV_ALI15X3=y
CONFIG_WDC_ALI15X3=y
CONFIG_BLK_DEV_AMD7409=y
CONFIG_AMD7409_OVERRIDE=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_CY82C693=y
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_HPT34X=y
CONFIG_HPT34X_AUTODMA=y
CONFIG_BLK_DEV_HPT366=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
CONFIG_BLK_DEV_NS87415=y
CONFIG_BLK_DEV_OPTI621=y
CONFIG_BLK_DEV_PDC202XX=y
CONFIG_PDC202XX_BURST=y
CONFIG_BLK_DEV_OSB4=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
CONFIG_BLK_DEV_TRM290=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDE_CHIPSETS=y
CONFIG_BLK_DEV_4DRIVES=y
CONFIG_BLK_DEV_ALI14XX=y
CONFIG_BLK_DEV_DTC2278=y
CONFIG_BLK_DEV_HT6560B=y
CONFIG_BLK_DEV_PDC4030=y
CONFIG_BLK_DEV_QD6580=y
CONFIG_BLK_DEV_UMC8672=y
CONFIG_IDEDMA_AUTO=y
CONFIG_IDEDMA_IVB=y
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_IDE_MODES=y

#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y

Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Jeff Garzik]

Gunther Mayer wrote:
> Hardware has always needed quirks (linux-2.4.3 has about 60 occurences
> of the word "quirks", not to mention workaround, blacklist and other synonyms)!
> 
> Please apply this little patch instead of wasting time by finger-pointing
> and arguing.
> 
> Martin, comments?

Is Martin still alive?  He hasn't been active in PCI development well
over six months, maybe a year now.  Ivan (alpha hacker) appeared on the
scene to fix serious PCI bridge bugs, DaveM has added some PCI DMA
stuff, and I've added a couple driver-related things.  I haven't seen
code from Martin in a long long time, and only a comment or two in
recent memory.


> --- linux-2.4.3-orig/include/linux/pci.hWed Apr  4 19:46:49 2001
> +++ linux/include/linux/pci.h   Sat Apr  7 20:01:51 2001
> @@ -454,6 +454,9 @@
> void (*remove)(struct pci_dev *dev);/* Device removed (NULL if not a 
>hot-plug capable driver) */
> void (*suspend)(struct pci_dev *dev);   /* Device suspended */
> void (*resume)(struct pci_dev *dev);/* Device woken up */
> +   int multifunction_quirks;   /* Quirks for PCI serial+parport 
>cards,
> +   here multiple drivers are 
>allowed to register
> +   for the same pci id match */
>  };

As has been explained, the current API supports this just fine without
modification.

Also, changing the API in the stable series should be frowned upon,
-especially- something domain specific like this.

Jeff


-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 kernel hangs on 486 machine at boot

[Pavel Machek]

Hi!

> > > Problem: Linux kernel 2.4 consistently hangs at boot on 486 machine
> > >
> > > Shortly after lilo starts the kernel it hangs at the following message:
> > > Checking if this processor honours the WP bit even in supervisor mode...
> > > 
> > 
> > Does this happen on 2.4.3-ac kernel trees ? I thought i had it zapped
> 
> Yes, that fix in -ac should take care of it.  As to why only the 486
> showed the problem, most 386's will not fault on the write protected
> page (the whole reason for this test) and pentiums and later don't run
> the test at all (assumed good).

We should not "assume good" -- to catch bugs like this one.
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/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/

Writing to MO-Drive hangs the system

[Detlev Offenbach]

Hi out there,

I have a problem with my 2.4.3 kernel. I have a 650 MB MO-Disk attached to my 
computer via SCSI. Partitioning and formatting a disk works fine. However, if 
the disk is formatted with a DOS filesystem, writing something to it hangs 
the whole system. Not even the Ctrl-Alt-Del works. I have to use the reset 
key. With a ext2 filesystem writing works fine.

Please help.

Regards
Detlev

-- 
Detlev Offenbach
[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/

i810_audio.c: Clicks while playing audio

[Naren Devaiah]

Hi,

On a HP Vectra VL 400 with a i815 motherboard playing a .wav file (haven't
tried anything else) causes the sound to be played with a lot of periodic
clicks. 
The kernel is 2.4.3
dmesg shows:
Intel 810 + AC97 Audio, version 0.01, 17:25:00 Apr  6 2001
PCI: Enabling device 00:1f.5 ( -> 0001)
PCI: Found IRQ 9 for device 00:1f.5
PCI: The same IRQ used for device 00:1f.3
PCI: Setting latency timer of device 00:1f.5 to 64
i810: Intel ICH 82801AA found at IO 0x1300 and 0x1200, IRQ 9
ac97_codec: AC97 Audio codec, id: 0x4352:0x5934 (Cirrus Logic CS4299)
i810_audio: 9568 bytes in 50 milliseconds
i810_audio: DMA overrun on send
i810_audio: DMA overrun on send

lsmod show:
root@darkstar:~# lsmod
Module  Size  Used by
i810_audio 14084   0
ac97_codec  7908   0  [i810_audio]


My question is: What does "DMA overrun on send" mean?


Regards,
Naren



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

Re: Multi-function PCI devices

[Jeff Garzik]

Michael Reinelt wrote:
> But what I want to know before I spend time (and not-earning-money :-)
> into this, I want to know: Is this the right way (TM)? How do other
> multiport cards deal with this issue?
> 
> This is a specific question to the serial and parallel maintainers: are
> there cards supported by _both_ the serial and parallel subsystem? Do
> they work with 2.4.3? Will they work in the future? (I'm too lazy to
> compare the PCI tables from serial and parallel ;-)

FWIW Tim (in this thread) is the parallel maintainer, tytso is the
serial maintainer.  WRT serial, there exists serial_cs driver, and the
serial_cb driver -used- to exist.  The entire purpose of these "shim"
drivers was to probe their [pcmcia, CardBus] busses for the necessary
information, and then call the existing serial layer to register ports
using the probe information already discovered.  I think the pcmcia-cs
package has a similar plug-n-play shim driver for parallel ports.

To answer your question, if there are such multifunctions cards working
in 2.4.3, then their drivers are either (a) ignoring one or more
functions in favor of a primary function, or (b) lucky enough to have
hardware which export multiple PCI bus entries, one for each logical
function, making it easy to modify the subsystem driver itself to probe
for the hardware.


> Another (design) question: How will such a driver/module deal with
> autodetection and/or devfs? I don't like to specify 'alias /dev/tts/4
> netmos', because thats pure junk to me. What about pci hotplugging?

pci hotplugging happens pretty much transparently.  When a new device is
plugged in, your pci_driver::probe routine is called.  When a new device
is removed, your pci_driver::remove routine is called.

Jeff


-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 for Broken PCI Multi-IO in 2.4.3 (serial+parport)

[Gunther Mayer]

Tim Waugh wrote:
> 
> On Sat, Apr 07, 2001 at 04:57:29AM -0400, Jeff Garzik wrote:
> 
> > Where is this patch available?  I haven't heard of an extension to the
> > pci id tables, so I wonder if it's really in the queue for the official
> > kernel.
> 
> It is.  http://people.redhat.com/twaugh/patches/>  The
> 'extension' is just 'more entries', AFAIR.
> 
> > > I'm afraid this is not a bug, but a design issue, and will be hard to
> > > solve. Maybe we need a flag for such devices which allows it to be
> > > claimed ba more thean one driver?
> >
> > Not so hard.
> 
> *sigh* Jeff, when I spoke to you about this last year you said
>  'tough', or words to that effect. :-(
> 
> > There is no need to register more than one driver per PCI device -- just
> > create a PCI driver whose probe routine registers serial and parallel,
> > and whose remove routine unregisters same.
> 
> *cough* modularity *cough*
> 
> Wnat to show us some elegant code that does that?

Hardware has always needed quirks (linux-2.4.3 has about 60 occurences
of the word "quirks", not to mention workaround, blacklist and other synonyms)!

Please apply this little patch instead of wasting time by finger-pointing
and arguing.

Martin, comments?


Regards, Gunther 



--- linux-2.4.3-orig/include/linux/pci.hWed Apr  4 19:46:49 2001
+++ linux/include/linux/pci.h   Sat Apr  7 20:01:51 2001
@@ -454,6 +454,9 @@
void (*remove)(struct pci_dev *dev);/* Device removed (NULL if not a 
hot-plug capable driver) */
void (*suspend)(struct pci_dev *dev);   /* Device suspended */
void (*resume)(struct pci_dev *dev);/* Device woken up */
+   int multifunction_quirks;   /* Quirks for PCI serial+parport cards,
+   here multiple drivers are allowed 
+to register
+   for the same pci id match */
 };


--- linux-2.4.3-orig/drivers/pci/pci.c  Wed Apr  4 19:46:46 2001
+++ linux/drivers/pci/pci.c Sat Apr  7 19:59:47 2001
@@ -453,7 +453,7 @@

list_add_tail(>node, _drivers);
pci_for_each_dev(dev) {
-   if (!pci_dev_driver(dev))
+   if (!pci_dev_driver(dev) || drv->multifunction_quirks)
count += pci_announce_device(drv, dev);
}
return count;
--- linux-2.4.3-orig/drivers/parport/parport_pc.c   Wed Apr  4 19:46:46 2001
+++ linux/drivers/parport/parport_pc.c  Sat Apr  7 20:18:37 2001
@@ -2539,6 +2539,7 @@
name:   "parport_pc",
id_table:   parport_pc_pci_tbl,
probe:  parport_pc_pci_probe,
+   multifunction_quirks: 1,
 };

 static int __init parport_pc_init_superio (void)
--- linux-2.4.3-orig/drivers/char/serial.c  Wed Apr  4 19:46:43 2001
+++ linux/drivers/char/serial.c Sat Apr  7 20:00:00 2001
@@ -4178,7 +4178,7 @@
for (i=0; timedia_data[i].num; i++) {
ids = timedia_data[i].ids;
for (j=0; ids[j]; j++) {
-   if (pci_get_subvendor(dev) == ids[j]) {
+   if (pci_get_subdevice(dev) == ids[j]) {
board->num_ports = timedia_data[i].num;
return 0;
}
@@ -4718,6 +4718,7 @@
probe:  serial_init_one,
remove:serial_remove_one,
id_table:   serial_pci_tbl,
+   multifunction_quirks: 1,
 };
 gmdiff-lx243-pci-multi_io

Let init know user wants to shutdown

[Pavel Machek]

Hi!

Init should get to know that user pressed power button (so it can do
shutdown and poweroff). Plus, it is nice to let user know that we can
read such event. [I hunted bug for few hours, thinking that kernel
does not get the event at all].

Here's patch to do that. Please apply,
Pavel

diff -urb -x .dep* -x .hdep* -x *.[oas] -x *~ -x #* -x *CVS* -x *.orig -x *.rej -x 
*.old -x .menu* -x asm -x local.h -x System.map -x autoconf.h -x compile.h -x 
version.h -x .version -x defkeymap.c -x uni_hash.tbl -x zImage -x vmlinu?* -x TAGS -x 
bootsect -x *RCS* -x conmakehash -x map -x build -x build -x configure -x *target* -x 
*.flags -x *.bak clean/drivers/acpi/events/evevent.c 
linux/drivers/acpi/events/evevent.c
--- clean/drivers/acpi/events/evevent.c Sun Apr  1 00:22:57 2001
+++ linux/drivers/acpi/events/evevent.c Wed Apr  4 01:08:11 2001
@@ -30,6 +30,8 @@
 #include "acnamesp.h"
 #include "accommon.h"
 
+#include 
+
 #define _COMPONENT  EVENT_HANDLING
 MODULE_NAME ("evevent")
 
@@ -197,14 +172,18 @@
if ((status_register & ACPI_STATUS_POWER_BUTTON) &&
(enable_register & ACPI_ENABLE_POWER_BUTTON))
{
+   printk ("acpi: Power button pressed!\n");
+   kill_proc (1, SIGTERM, 1);
int_status |= acpi_ev_fixed_event_dispatch (ACPI_EVENT_POWER_BUTTON);
}
 
+
/* sleep button event */
 
if ((status_register & ACPI_STATUS_SLEEP_BUTTON) &&
(enable_register & ACPI_ENABLE_SLEEP_BUTTON))
{
+   printk("acpi: Sleep button pressed!\n");
int_status |= acpi_ev_fixed_event_dispatch (ACPI_EVENT_SLEEP_BUTTON);
}
 

-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [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/

Serious bug in ACPI enumeration

[Pavel Machek]

Hi!

My "toshiba workaround" was not toshiba specific: you stopped scanning
at first device that was not present. That's bad, you have to continue
scanning. Here's fix.

Pavel

--- clean/drivers/acpi/namespace/nsxfobj.c  Sun Apr  1 00:23:00 2001
+++ linux/drivers/acpi/namespace/nsxfobj.c  Thu Apr  5 22:49:18 2001
@@ -592,7 +595,7 @@
 
status = acpi_cm_execute_STA (node, );
if (ACPI_FAILURE (status)) {
-   return (status);
+   return AE_OK;
}
 
if (!(flags & 0x01)) {


-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [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/

FYI: ACPI devices put into proc

[Pavel Machek]

Hi!

Here it how it looks just now. This is work in progress, but feel free
to apply. [You may want to restructure it somehow, move it into
different place maybe, and call its init from convient place].

Oh, and "ACPI_OK" should be killed. It is too easy to write it instead
of AE_OK.

Pavel

--- clean/drivers/acpi/namespace/nsxfobj.c  Sun Apr  1 00:23:00 2001
+++ linux/drivers/acpi/namespace/nsxfobj.c  Thu Apr  5 22:49:18 2001
@@ -30,6 +30,9 @@
 #include "acnamesp.h"
 #include "acdispat.h"
 
+#include 
+#include 
+#include 
 
 #define _COMPONENT  NAMESPACE
 MODULE_NAME ("nsxfobj")
@@ -694,3 +697,137 @@
 
return (status);
 }
+
+static int
+proc_read_device_info(char *page, char **start, off_t off,
+   int count, int *eof, void *data)
+{
+   ACPI_HANDLE obj_handle = (u32) data;
+   ACPI_NAMESPACE_NODE *node;
+   ACPI_STATUS status;
+   char *p = page;
+   int len;
+   u32 flags;
+   DEVICE_ID   device_id;
+
+   /* don't get info more than once for a single proc read */
+   if (off != 0)
+   goto end;
+
+   acpi_cm_acquire_mutex (ACPI_MTX_NAMESPACE);
+
+   printk("acpi_read_device_info: %lx\n", obj_handle);
+   node = acpi_ns_convert_handle_to_entry (obj_handle);
+
+   acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
+
+   status = acpi_cm_execute_STA (node, );
+   if (ACPI_FAILURE (status))
+   p += sprintf(p, "Present:   No (%lx)\n", status);
+   elsep += sprintf(p, "Present:   Yes (flags %lx)\n", flags);
+
+   status = acpi_cm_execute_HID (node, _id);
+   if (!ACPI_FAILURE (status))
+   p += sprintf(p, "HID ident: %s\n", _id.buffer );
+
+   status = acpi_cm_execute_UID (node, _id);
+   if (!ACPI_FAILURE (status))
+   p += sprintf(p, "UID ident: %s\n", _id.buffer );
+
+   p += sprintf(p, "This is some random information\n");
+end:
+   len = (p - page);
+   if (len <= off+count) *eof = 1;
+   *start = page + off;
+   len -= off;
+   if (len>count) len = count;
+   if (len<0) len = 0;
+   return len;
+}
+
+static ACPI_STATUS
+acpi_ns_add_proc_callback (
+   ACPI_HANDLE obj_handle,
+   u32 nesting_level,
+   void*context,
+   void**return_value)
+{
+   ACPI_STATUS status;
+   ACPI_NAMESPACE_NODE *node;
+   u32 flags;
+   DEVICE_ID   device_id;
+   ACPI_GET_DEVICES_INFO   *info;
+
+
+   info = context;
+
+   acpi_cm_acquire_mutex (ACPI_MTX_NAMESPACE);
+
+   printk("acpi_add_proc_callback: %lx\n", obj_handle);
+   node = acpi_ns_convert_handle_to_entry (obj_handle);
+
+   acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
+
+   if (!node) {
+   return (AE_BAD_PARAMETER);
+   }
+
+   /*
+* Run _STA to determine if device is present
+*/
+
+   status = acpi_cm_execute_STA (node, );
+   if (ACPI_FAILURE (status)) {
+   return (AE_OK);
+   }
+
+   if (!(flags & 0x01)) {
+   /* don't return at the device or children of the device if not there */
+
+   return (AE_CTRL_DEPTH);
+   }
+
+   {
+   char proc_name[120];
+
+   status = acpi_cm_execute_HID (node, _id);
+
+   if (status == AE_NOT_FOUND) {
+   return (AE_OK);
+   }
+
+   else if (ACPI_FAILURE (status)) {
+   return (status);
+   }
+
+   sprintf(proc_name, "power/device_%s_%lx", device_id.buffer, obj_handle 
+);
+   printk("ACPI: creating %s\n", proc_name);
+   create_proc_read_entry(proc_name, 0, NULL,
+   proc_read_device_info, (void *) obj_handle);
+   }
+
+   return (AE_OK);
+}
+
+
+void
+acpi_namespace_init(
+   void)
+{
+   ACPI_STATUS status;
+   void ** return_value;
+
+   printk("ACPI: initializing namespace\n");
+
+   acpi_cm_acquire_mutex (ACPI_MTX_NAMESPACE);
+   status = acpi_ns_walk_namespace (ACPI_TYPE_DEVICE,
+  ACPI_ROOT_OBJECT, ACPI_UINT32_MAX,
+  NS_WALK_UNLOCK,
+  acpi_ns_add_proc_callback, NULL,
+  return_value);
+
+   acpi_cm_release_mutex (ACPI_MTX_NAMESPACE);
+
+   return (status);
+}
+

-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [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 

Re: Multi-function PCI devices

[Michael Reinelt]

Gérard Roudier wrote:
> 
> > Tim Waugh wrote:
> > > > Adding PCI entries to both serial.c and parport_pc.c was that easy
> > >
> > > And that's how it should be, IMHO.  There needs to be provision for
> > > more than one driver to be able to talk to any given PCI device.
> >
> > True, true, true.
> 
> Could you start up your brain now :) 
There's no need to start it. My brain is either 'always on', or
'suspended to ram' :-)

> and think about the actual issue. All
> the drivers must share the device resources and there is no (simple) way
> to do so generically.
> What you want to do is to write a single software driver, optionnaly
> broken into several modules, that is aware of all the functionnalities of
> the board and that will register to all involved sub-systems as needed.

I agree. that would be the clean solution. Jeff Grazik provided some
sample code, I'll try to write a driver according to this. If I find the
time

But what I want to know before I spend time (and not-earning-money :-)
into this, I want to know: Is this the right way (TM)? How do other
multiport cards deal with this issue?

This is a specific question to the serial and parallel maintainers: are
there cards supported by _both_ the serial and parallel subsystem? Do
they work with 2.4.3? Will they work in the future? (I'm too lazy to
compare the PCI tables from serial and parallel ;-)

Another (design) question: How will such a driver/module deal with
autodetection and/or devfs? I don't like to specify 'alias /dev/tts/4
netmos', because thats pure junk to me. What about pci hotplugging?

(keep in mind that I'm new to kernel development)


> What about the option of using a different hardware ? :-)

Har har har. Could you please tell me where to get one? I don't know how
it's in your country, but here in austria you can call yourself a lucky
guy if you even find a PCI serial/parallel card. If you find one, you'll
find _one_. It's packaged in a little box where it reads "PCI 2S/1P
board". The 'manual' is a bit larger than a stamp. 

I could buy one after another, and try if they have a well-designed PCI
interface. 

I don't have the time for this.

I agree with you that this kind of hardware is junk. But there's a lack
of alternatives

If there's a reasonable number of 'good' hardware out there, I'll forget
about Netmos and buy me a new card. If not, I'm willing to provide a
driver. 


bye, Michael

-- 
netWorks  Vox: +43 316  692396
Michael Reinelt   Fax: +43 316  692343
Geisslergasse 4   GSM: +43 676 3079941
A-8045 Graz, Austria  e-mail: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.3-ac2 -- How do I determine if shm is being used?

[Miles Lane]

I have mounted:

none on /var/shm type shm (rw)
tmpfs on /dev/shm type tmpfs (rw)

Yet, running "x11perf -shmput10" gives me:

X Error of failed request:  BadValue (integer parameter out of range for
operation)
  Major opcode of failed request:  146 (MIT-SHM)
  Minor opcode of failed request:  3 (X_ShmPutImage)
  Value in failed request:  0x161
  Serial number of failed request:  35107
  Current serial number in output stream:  35111

I'd like to check to make sure that shm is actually accessible
to my programs.  Is there any easy way to do this?

I have already checked the values of:

/proc/sys/kernel/shmall = 200
/proc/sys/kernel/shmmax = 4096
/proc/sys/kernel/shmmni = 3500

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

Re: Multi-function PCI devices

[Jeff Garzik]

Brian Gerst wrote:
> Gérard Roudier wrote:
> > Given your description, this board is certainly not a multi-fonction PCI
> > device. Multi-function PCI devices provide separate resources for each
> > function in a way that allows each function to be driven by separate
> > software drivers. A single function PCI device that provides several
> > functionnalities commonly handled by separate sub-systems, is nothing but
> > a bag of shit we should not want to support in any O/S in my opinion.
> > Let me claim that ingenieers that want O/Ses to support such hardware are
> > either morons or bastards.
> 
> Unfortunately, Windoze supports this configuration, and that's enough
> for most hardware designers.  This is also an issue with the joystick
> ports on many PCI sound cards.  We're not in a position to get up on the
> soap box and decree this hardware "a bag of shit" though, yet.
> 
> PS.  I have run into this issue before with joystick ports on many PCI
> sound cards.  The only one that I found that did it right (seperate PCI
> function for the game port) was the SBLive.

We -can- support multifunction cards such and these, and no we don't
need to hack the infrastructure to do it.  You might need to hack the
subsystem drivers a bit to make them more flexible, but that's it.

WRT the specific example of joystick ports, it is already possible for a
sound driver to register a joystick port.  No problem there either.

Jeff



-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

UDMA(66) drive coming up as UDMA(33)?

[David St.Clair]

I'm trying to get my hard drive to use UDMA/66.  I'm thinking the cable
is not being detected.  When the HPT366 bios is set to UDMA 4; using
hdparm -t, I get a transfer rate of 19.51 MB/s. When the HPT366 bios is
set to PIO 4 the transfer rate is the same. Is this normal for a UDMA/66
drive? What makes me think something is wrong is that the log says

"ide2: BM-DMA at 0xbc00-0xbc07, BIOS settings: hde:pio" <-- PIO? 

and

"hde: 27067824 sectors (13859 MB) w/371KiB Cache, CHS=26853/16/63,
UDMA(33)" <--- UDMA(33)? shouldn't it be UDMA(66)?

Any ideas what might be wrong? Possible bug?


Hardware:
Abit BE6 Motherboard with HPT366 controller
Quantum Fireball KA 13.6 UDMA/66 HD
80 pin connector
Linux Partition is on /dev/hde2

Software:
Redhat 7.0
Kernel 2.4.3 (non-modified)

Use multi-mode by default = Y
CMD640 chipset bugfix/support = Y
RZ1000 chipset bugfix/support = Y
Generic PCI IDE chipset support = Y
Shareing PCI IDE interrupts support = Y
Generic PCI bus-master DMA support = Y
Use PCI DMA by default when available = Y
HPT366 chipset support = Y
Intel PIIXn chipsets support = Y
PIIXn Tuning support = Y
IGNORE word93 Validation BITS = Y



My Log:

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
automount[415]: starting automounter version 3.1.6, path = /misc,
maptype = file, mapname = /etc/auto.misc
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100%% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
HPT366: onboard version of chipset, pin1=1 pin2=2
HPT366: IDE controller on PCI bus 00 dev 98
PCI: Found IRQ 11 for device 00:13.0
PCI: The same IRQ used for device 00:0b.0
PCI: The same IRQ used for device 00:13.1
HPT366: chipset revision 1
HPT366: not 100%% native mode: will probe irqs later
ide2: BM-DMA at 0xbc00-0xbc07, BIOS settings: hde:pio, hdf:pio
HPT366: IDE controller on PCI bus 00 dev 99
PCI: Found IRQ 11 for device 00:13.1
PCI: The same IRQ used for device 00:0b.0
PCI: The same IRQ used for device 00:13.0
HPT366: chipset revision 1
Initializing random number generator:  succeeded
HPT366: not 100%% native mode: will probe irqs later
 ide3: BM-DMA at 0xc800-0xc807, BIOS settings: hdg:pio, hdh:pio
hdc: Pioneer DVD-ROM ATAPIModel DVD-113 0114, ATAPI CD/DVD-ROM drive
hdd: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive
hde: QUANTUM FIREBALLP KA13.6, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xb400-0xb407,0xb802 on irq 11
hde: 27067824 sectors (13859 MB) w/371KiB Cache, CHS=26853/16/63,
UDMA(33)
hdc: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
hdd: 98304kB, 96/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm



Thank you,

David St.Clair
[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: Multi-function PCI devices

[Jeff Garzik]

Tim Waugh wrote:
> 
> On Sat, Apr 07, 2001 at 01:33:25PM +0200, Michael Reinelt wrote:
> 
> > Adding PCI entries to both serial.c and parport_pc.c was that easy
> 
> And that's how it should be, IMHO.  There needs to be provision for
> more than one driver to be able to talk to any given PCI device.

No, because that gets really ugly.  You have to create a shim driver
which allocates resources, and registers subsystems.  Only a single PCI
driver like this know best how to locate and allocate resources.  You
can wish to hack such into the serial or parallel driver's PCI probe id
lists, but that won't work for this case, and trying to do it any other
way looks suspiciously like a hack :)

You asked in your last message to show you code, here is a short
example.  Note that I would love to rip out the SUPERIO code in parport
and make it a separate driver like this short, contrived example.  Much
more modular than the existing solution.

static int __devinit foo_init_one (...)
{
u32 tmp;
int rc;
struct serial_port serial;
struct parport parport;

pci_read_config_byte(pdev, 0x40, );
serial.irq = tmp & 0xFF;
pci_read_config_word(pdev, 0x42, );
serial.port = tmp & 0x;

rc = register_serial();
if (rc < 0)
return rc;

pci_read_config_byte(pdev, 0x40, );
parport.irq = tmp & 0xFF;
pci_read_config_word(pdev, 0x42, );
parport.port = tmp & 0x;

rc = register_parport();
if (rc < 0)
return rc;

return 0;
}
static void __init foo_init(void) {
return pci_module_init(_driver);
}
static void __exit foo_exit(void) {
pci_unregister_driver(_driver);
}
module_init(foo_init);
module_exit(foo_exit);

-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NLS: koi8-u support

[Volodymyr M . Lisivka]

On 2001.04.06 22:21:35 +0300 [EMAIL PROTECTED] wrote:
> Hello!
> 
>   It was added already. But charset name is koi8-ru for
>   some strange reason

Sound good.

koi8-ru  extends koi8-u(RFC-2319) only by one Byelorussian letter.
But standartization of koi8-ru is not finished at this moment and these
encodings have different codes for some special symbols (AFAIK).
(See details on http://www.cad.ntu-kpi.kiev.ua/multiling/
and 
http://www.net.ua/KOI8-U/ )

Maybe it would be better to separate supporting of koi8-u and koi8-ru in
kernel
to avoid problems in future?

> Bye,
> Oleg
> In article <[EMAIL PROTECTED]> you wrote:
> > Please add support of KOI-8 Ukrainian (AKA koi8-u) encoding into
> kernel,
> > because
> > ukrainian users can't read files with ukrainian names from NTFS and SMB
> > disks without it.
> 
> > Patch for 2.4.x kernels (2.4.0-test10 - 2.4.3):
> > ==cut from here

-- 
Best regards,   mailto:[EMAIL PROTECTED]
Volodymyr M. LisivkaICQ#14549856

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

Re: Multi-function PCI devices

[Gérard Roudier]

On Sat, 7 Apr 2001, Michael Reinelt wrote:

> Tim Waugh wrote:
> > 
> > On Sat, Apr 07, 2001 at 01:33:25PM +0200, Michael Reinelt wrote:
> > 
> > > Adding PCI entries to both serial.c and parport_pc.c was that easy
> > 
> > And that's how it should be, IMHO.  There needs to be provision for
> > more than one driver to be able to talk to any given PCI device.
> 
> True, true, true.

Could you start up your brain now :) and think about the actual issue. All
the drivers must share the device resources and there is no (simple) way
to do so generically.
What you want to do is to write a single software driver, optionnaly
broken into several modules, that is aware of all the functionnalities of
the board and that will register to all involved sub-systems as needed.

> But - how to deal with it? Who decides if we can deal this way or not?
> PCI maintainer? Linus?
> 
> bye, Michael
> 
> P.S. I really need this. I have to unload serial and parallel and reload
> them in different order when I want either print something or talk to my
> Palm :-(

What about the option of using a different hardware ? :-)

  Gérard.

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

Re: Multi-function PCI devices

[Gérard Roudier]

On Sat, 7 Apr 2001, Michael Reinelt wrote:

> Brian Gerst wrote:
> > 
> > Gérard Roudier wrote:
> > >
> > > On Sat, 7 Apr 2001, Michael Reinelt wrote:
> > >
> > > > The card shows up on the PCI bus as one device. For the card provides
> > > > both serial and parallel ports, it will be driven by two subsystems, the
> > > > serial and the parallel driver.
> > >
> > > Given your description, this board is certainly not a multi-fonction PCI
> > > device. Multi-function PCI devices provide separate resources for each
> > > function in a way that allows each function to be driven by separate
> > > software drivers. A single function PCI device that provides several
> > > functionnalities commonly handled by separate sub-systems, is nothing but
> > > a bag of shit we should not want to support in any O/S in my opinion.
> > > Let me claim that ingenieers that want O/Ses to support such hardware are
> > > either morons or bastards.
> > 
> > Unfortunately, Windoze supports this configuration, and that's enough
> > for most hardware designers.  This is also an issue with the joystick
> > ports on many PCI sound cards.  We're not in a position to get up on the
> > soap box and decree this hardware "a bag of shit" though, yet.
> 
> How about other Multi-I/O-Cards? I think these 2S/1P (or 2P/1S or 2P/2S)
> cards are very common. At least they have been as ISA (PnP) cards. I

Please donnot compare ISA and PCI. ISA wasted trillions of user hours
because of its inability to allow automatic configuration.
PCI fixed this by assigning configuration space to each device.
These 'a la shitty ISA' Multi-I/O boards just kill the advantage of PCI by
moving again ISA burden to PCI. In year 2001, they stink a lot.

> don't know, but I'm shure there are a lot of these out there in the
> field. As mainboards without any ISA slots get more common every day,
> there will be even more PCI multi-I/O-cards (apart from everyone running
> to USB :-)

PCI multi I/O boards _shall_ provide a separate function for each kind of
IO. Those that donnot are kind of PCI messy IO boards.

> I needed another serial and parallel port, and I've got one of these
> mainboards (Asus A7V). So I had to buy such a PCI card. Nowadays you
> can't even ask for a specific hardware manufacturer, everything the guy
> in the shop knows is "yes, it's PCI, and yes, it has two serial and one
> parallel port". 
> 
> As these cards are very cheap, you can't expect very much from them (I

Cheap for whom?
What happens is that other companies or people that want to to support
such hardware must do additionnal efforts that could have been avoided if
the board had been correctly designed.

> don't even think there are any expensive ones out there). NetMos does
> not produce this cards, they produce _chips_ for such cards. So there
> are probably a lot of cards out there with these NetMos chips.
> 
> Again, how about other cards? Are there any PCI Multi-I/O-cards out
> there, which are supported by linux? I'd be interested in how the driver
> looks like

I donnot know and will never know. I only use hardware that does not look
too shitty to me. Time is too much important for me to waste even seconds
with dubious hardware. :)

  Gérard.

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

Re: aic7xxx 6.1.10 breaks 2.4.3-ac3

[Justin T. Gibbs]

>Hi.
>
>Subject says it all.
>
>With latest updates, i just deleted the kernel aic7xxx subtree, put instead
>the updated (from people.freebsd.org) tree, and built. All went fine
>until (and including) 6.1.9.

That's not a sufficient way to upgrade.  The tar files are there for
people who are porting the driver to other platforms.  You should always
use the patches to upgrade as they often touch other portions of the
Linux kernel that need fixes in order to work correctly with the
aic7xxx driver.

>6.1.10 just stops after the init messages and stays there forever.

To be expected as you didn't apply the patch to scsi_lib.c that makes
scsi_unblock_host() actually run the device queues to start the system
back up again.

I'm working on an html page for my site that should explain all of
the upgrade proceedures.

--
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: linux 2.2.19 smp interrupt problems?

[Armin Obersteiner]

hi!

thanx, worked. the old driver should be default for 8129 (selecting it for 8139 
should be deprecated) and the new one for 8139 ...
 
> > everything seems to work fine. are these interrupt problems "bad" or merely 
> > indicators of a high load. can/should one get rid of them? 
> >
> Could you try the 8139too driver?
> 
> It's a bug in the rtl8139 driver, and under really high load it can
> cause crashes.

MfG,
Armin Obersteiner
--
[EMAIL PROTECTED]pgp public key on requestCU
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 6.1.10 breaks 2.4.3-ac3

[J . A . Magallon]

Hi.

Subject says it all.

With latest updates, i just deleted the kernel aic7xxx subtree, put instead
the updated (from people.freebsd.org) tree, and built. All went fine
until (and including) 6.1.9.

6.1.10 just stops after the init messages and stays there forever.

scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.9

aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs

(6.1.10 stops here)

  Vendor: IBM   Model: DCAS-34330W   Rev: S65A
  Type:   Direct-Access  ANSI SCSI revision: 02
scsi0:0:0:0: Tagged Queuing enabled.  Depth 253
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
(scsi0:A:0): 40.000MB/s transfers (20.000MHz, offset 15, 16bit)
SCSI device sda: 8467200 512-byte hdwr sectors (4335 MB)
Partition check:
 sda: sda1 sda2 < sda5 sda6 sda7 sda8 >

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

Linux werewolf 2.4.3-ac3 #1 SMP Thu Apr 5 00:28:45 CEST 2001 i686

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

Re: Multi-function PCI devices

[Michael Reinelt]

Tim Waugh wrote:
> 
> On Sat, Apr 07, 2001 at 01:33:25PM +0200, Michael Reinelt wrote:
> 
> > Adding PCI entries to both serial.c and parport_pc.c was that easy
> 
> And that's how it should be, IMHO.  There needs to be provision for
> more than one driver to be able to talk to any given PCI device.

True, true, true.

But - how to deal with it? Who decides if we can deal this way or not?
PCI maintainer? Linus?

bye, Michael

P.S. I really need this. I have to unload serial and parallel and reload
them in different order when I want either print something or talk to my
Palm :-(

-- 
netWorks  Vox: +43 316  692396
Michael Reinelt   Fax: +43 316  692343
Geisslergasse 4   GSM: +43 676 3079941
A-8045 Graz, Austria  e-mail: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Kernel panic when trying to mount a scsi cdrom.

[Alexandre et/ou Sophie Beneteau]

[1.] One line summary of the problem:

 Kernel panic when trying to mount a scsi cdrom.
 
[2.] Full description of the problem/report:

Since version 2.4.2, I get a kernel panic everytime I try to mount an
iso9660 cdrom :

# mount /dev/scd0 /cdrom
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
sr0: scsi3-mmc drive: 24x/24x write cd/rw xa/form2 cdda tray
mount: block device /dev/scd0 is write-protected, mounting read-only
sr: ran out of meme for scatter pad
Kernel panic: scsi_free: Bad offset

(typed by hand, since the system is frozen at this point of the
operation :-) )

No problem when I read a cd-rom (with cdparanoia, cdrecord or cdrdao)
nor when I write a cd/r cd/rw, nor when I listen a cd-audio

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

scsi, kernel panic, mount

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

Linux version 2.4.3 (root@casimir) (gcc version 2.95.3 19991030
(prerelease)) #2 Sat Mar 31 19:34:40 CEST 2001

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

NO OOPS

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

mount /dev/scd0 /cdrom

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

Linux casimir 2.4.3 #2 Sat Mar 31 19:34:40 CEST 2001 i586 unknown
 
Gnu C  2.95.3
Gnu make   3.79.1
binutils   2.10.0.24
util-linux 2.11b
modutils   2.4.2
e2fsprogs  1.19
PPP2.4.0
Linux C Library1.3.so
awk: cmd. line:2: (FILENAME=- FNR=2) fatal: attempt to access field -1
Dynamic linker (ldd)   2.1.3
Linux C++ Library  2.8.0
Linux C++ Library  ..
Procps 2.0.7
Net-tools  1.50
Kbd0.99
Sh-utils   2.0
Modules Loaded ne 8390

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

processor   : 0
vendor_id   : CyrixInstead
cpu family  : 5
model   : 2
model name  : 6x86 2x Core/Bus Clock
stepping: 5
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: yes
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu cyrix_arr
bogomips: 119.60

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

ne  6704   1 (autoclean)
83906192   0 (autoclean) [ne]

[7.4.] Loaded driver and hardware information (/proc/ioports,
/proc/iomem)

-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
0213-0213 : isapnp read
0240-025f : eth0
02f8-02ff : serial(set)
03c0-03df : vga+
  03c0-03df : matrox
03f6-03f6 : ide0
03f8-03ff : serial(set)
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1

-0009efff : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000c8000-000cbfff : Extension ROM
000f-000f : System ROM
0010-04ff : System RAM
  0010-001bc34d : Kernel code
  001bc34e-001fe5bf : Kernel data
fa80-faff : Matrox Graphics, Inc. MGA 1064SG [Mystique]
fb7ec000-fb7e : Matrox Graphics, Inc. MGA 1064SG [Mystique]
  fb7ec000-fb7e : matroxfb MMIO
fb80-fbff : Matrox Graphics, Inc. MGA 1064SG [Mystique]
  fb80-fbff : matroxfb FB
e800-e80f : Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]

[7.5.] PCI information ('lspci -vvv' as root)

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

Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor:  Model: CD-R/RW RW7060S  Rev: 1.20
  Type:   CD-ROM   ANSI SCSI revision: 02

[7.7.] Other information that might be relevant to the problem
   (please look in /proc and include all information that you
   think to be relevant):

proc/scsi/sg : 

debug : dev_max(currently)=7 max_active_device=1 (origin 1)
 scsi_dma_free_sectors=160 sg_pool_secs_aval=320 def_reserved_size=32768


host_strs : Adaptec 1542

hosts : 820 0   1   16  1   0

version : 30117   Version: 3.1.17 (20001002)


[X.] Other notes, patches, fixes, workarounds:

Feel free to ask me whatever information you would need to investigate
the problem... Thanks :-)

Alex.

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

Re: Multi-function PCI devices

[Michael Reinelt]

Brian Gerst wrote:
> 
> Gérard Roudier wrote:
> >
> > On Sat, 7 Apr 2001, Michael Reinelt wrote:
> >
> > > The card shows up on the PCI bus as one device. For the card provides
> > > both serial and parallel ports, it will be driven by two subsystems, the
> > > serial and the parallel driver.
> >
> > Given your description, this board is certainly not a multi-fonction PCI
> > device. Multi-function PCI devices provide separate resources for each
> > function in a way that allows each function to be driven by separate
> > software drivers. A single function PCI device that provides several
> > functionnalities commonly handled by separate sub-systems, is nothing but
> > a bag of shit we should not want to support in any O/S in my opinion.
> > Let me claim that ingenieers that want O/Ses to support such hardware are
> > either morons or bastards.
> 
> Unfortunately, Windoze supports this configuration, and that's enough
> for most hardware designers.  This is also an issue with the joystick
> ports on many PCI sound cards.  We're not in a position to get up on the
> soap box and decree this hardware "a bag of shit" though, yet.

How about other Multi-I/O-Cards? I think these 2S/1P (or 2P/1S or 2P/2S)
cards are very common. At least they have been as ISA (PnP) cards. I
don't know, but I'm shure there are a lot of these out there in the
field. As mainboards without any ISA slots get more common every day,
there will be even more PCI multi-I/O-cards (apart from everyone running
to USB :-)

I needed another serial and parallel port, and I've got one of these
mainboards (Asus A7V). So I had to buy such a PCI card. Nowadays you
can't even ask for a specific hardware manufacturer, everything the guy
in the shop knows is "yes, it's PCI, and yes, it has two serial and one
parallel port". 

As these cards are very cheap, you can't expect very much from them (I
don't even think there are any expensive ones out there). NetMos does
not produce this cards, they produce _chips_ for such cards. So there
are probably a lot of cards out there with these NetMos chips.

Again, how about other cards? Are there any PCI Multi-I/O-cards out
there, which are supported by linux? I'd be interested in how the driver
looks like

bye, Michael


-- 
netWorks  Vox: +43 316  692396
Michael Reinelt   Fax: +43 316  692343
Geisslergasse 4   GSM: +43 676 3079941
A-8045 Graz, Austria  e-mail: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Multi-function PCI devices

[Brian Gerst]

Gérard Roudier wrote:
> 
> On Sat, 7 Apr 2001, Michael Reinelt wrote:
> 
> > Hi there,
> >
> > I've got a problem with my communication card: It's a PCI card with a
> > NetMos chip, and it provides two serial and one parallel port. It's not
> > officially supported by the linux kernel, so I wrote my own patch and
> > sent it to the parallel, serial and pci maintainer. The patch itself is
> > basically an extension of the pci id tables; and I hope it's in the
> > queue for the official kernel.
> >
> > The patch worked great for me with kernel 2.4.1 and .2, but no longer
> > with 2.4.3. The parallel port still works, but the serial port will not
> > be detected. I had a quite long debugging session last night (adding
> > printk's to the pci code takes some time, for you have to reboot to load
> > the new kernel), and I think I found the reason:
> >
> > The card shows up on the PCI bus as one device. For the card provides
> > both serial and parallel ports, it will be driven by two subsystems, the
> > serial and the parallel driver.
> 
> Given your description, this board is certainly not a multi-fonction PCI
> device. Multi-function PCI devices provide separate resources for each
> function in a way that allows each function to be driven by separate
> software drivers. A single function PCI device that provides several
> functionnalities commonly handled by separate sub-systems, is nothing but
> a bag of shit we should not want to support in any O/S in my opinion.
> Let me claim that ingenieers that want O/Ses to support such hardware are
> either morons or bastards.

Unfortunately, Windoze supports this configuration, and that's enough
for most hardware designers.  This is also an issue with the joystick
ports on many PCI sound cards.  We're not in a position to get up on the
soap box and decree this hardware "a bag of shit" though, yet.

PS.  I have run into this issue before with joystick ports on many PCI
sound cards.  The only one that I found that did it right (seperate PCI
function for the game port) was the SBLive.

-- 

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

Re: Multi-function PCI devices

[Tim Waugh]

On Sat, Apr 07, 2001 at 01:33:25PM +0200, Michael Reinelt wrote:

> Adding PCI entries to both serial.c and parport_pc.c was that easy

And that's how it should be, IMHO.  There needs to be provision for
more than one driver to be able to talk to any given PCI device.

Tim.
*/

 PGP signature

Re: Multi-function PCI devices

[Gérard Roudier]

On Sat, 7 Apr 2001, Michael Reinelt wrote:

> Hi there,
> 
> I've got a problem with my communication card: It's a PCI card with a
> NetMos chip, and it provides two serial and one parallel port. It's not
> officially supported by the linux kernel, so I wrote my own patch and
> sent it to the parallel, serial and pci maintainer. The patch itself is
> basically an extension of the pci id tables; and I hope it's in the
> queue for the official kernel. 
> 
> The patch worked great for me with kernel 2.4.1 and .2, but no longer
> with 2.4.3. The parallel port still works, but the serial port will not
> be detected. I had a quite long debugging session last night (adding
> printk's to the pci code takes some time, for you have to reboot to load
> the new kernel), and I think I found the reason:
> 
> The card shows up on the PCI bus as one device. For the card provides
> both serial and parallel ports, it will be driven by two subsystems, the
> serial and the parallel driver.

Given your description, this board is certainly not a multi-fonction PCI
device. Multi-function PCI devices provide separate resources for each
function in a way that allows each function to be driven by separate
software drivers. A single function PCI device that provides several
functionnalities commonly handled by separate sub-systems, is nothing but
a bag of shit we should not want to support in any O/S in my opinion.
Let me claim that ingenieers that want O/Ses to support such hardware are
either morons or bastards.

> I found that _either_ the parallel or the serial port works, depending
> on which module you load first. The reason for this seems to be in
> pci.c, especially in the pci_register_driver() function. It reads:
> 
> int pci_register_driver(struct pci_driver *drv)
> {
>   struct pci_dev *dev;
>   int count = 0;
> 
>   list_add_tail(>node, _drivers);
>   pci_for_each_dev(dev) {
>   if (!pci_dev_driver(dev))
>   count += pci_announce_device(drv, dev);
>   }
>   return count;
> }
> 
> 
> pci_announce_device() will be called only if there's no other driver
> claiming the device. This explains why either the parallel or the serial
> port will be detected: The first driver loaded will see the device, the
> next drivers won't.
> 
> I'm afraid this is not a bug, but a design issue, and will be hard to
> solve. Maybe we need a flag for such devices which allows it to be
> claimed ba more thean one driver?
> 
> In the meantime, what can I do to get both ports working?

Since the hardware does not allows the software to transparently share the
different functionnalities provided by the silicium, you must handle such
sharing by software. I mean, you must, at least, write a module (or
sub-driver or sub-system) that will handle the sharing of the PCI
function. Band-aiding the kernel code in order to cope with such
brain-deaded hardware would be a pity, in my opinion. Burden must stay
where it is deserved. If they want their 'save 0.01$ but push shit ahead'
hardware to be supported, they should write their drivers themselves, in
my opinion.

  Gérard.


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

problem when booting 2.4.3 from a floppy disk

[François Dupoux]

Hi,

I have a strange bug when trying to boot a kernel-2.4.3 (official release) 
from an 1.44 MB floppy disk. Just after the "Loading...", there is an 
infinite loop, and this message is printed:
0200
AX: 0212
BX: BC00
CX: 5101
DX: 
0200
AX: 0212
BX: BC00
CX: 5101
DX: 


The floppy drive continues to work, and the message is printed by the 
infinite loop.

I attached the configuration file made from make xconfig, and the proc file 
system to give you more details about my hardware.

The kernel 2.4.3 was compiled for i386. It was only patched with JFS-0.2.2. 
The "developement drivers" option was enabled in order to enable the ReiserFS 
support. The module support was disabled. The SMP is disabled.

The floppy disk was created with "make bzdisk". It printed:
setup is 2485 bytes
system is 974 kB
122+1 record in/out

I made the "make bzdisk" with 4 differents floppy disks, in order to be sure 
my floppy disk was not damaged. I had the same problem, but there was 4 
differents error messages (see at the bottom of the mail). The "make bzdisk" 
was made with exacly the same configuration. No changes were made betweewn 
each "make bzdisk".

I have the same problem if I "make bzImage" and I copy the image by hand with 
"dd if=bzImage of=/dev/fd0"

With the same configuration, when I type "make bzImage", and I boot on my 
hard-disk with LILO, the kernel-2.4.3 works very well.

I had the same kind of problem with differents kernel versions:
2.2.17, 2.2.18, 2.4.3

But I had no problem with 2.4.2 and 2.2.16.

My hardware configuration:
- intel celeron 433 not overclocked
- 448 MB of RAM
- compiled under Debian 2.2r0 with recompiled kernel-2.4.3
- 2 IDE IBM hard disks (DMA33 and DMA100) -> hda and hdc

Thanks.

--- error message with floppy disk 1 ---
0200
AX: 0212
BX: BC00
CX: 5101
DX: 

--- error message with floppy disk 2 ---
0200
AX: 0212
BX: 7400
CX: 5001
DX: 

--- error message with floppy disk 3 ---
0400
AX: 0212
BX: 7400
CX: 5001
DX: 

--- error message with floppy disk 4 ---
0200
AX: 0212
BX: 0400
CX: 5201
DX: 


 proc-fs.tar.bz2

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

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
# CONFIG_MODULES is not set

#
# Processor type and features
#
CONFIG_M386=y
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# 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_CMPXCHG is not set
CONFIG_X86_L1_CACHE_SHIFT=4
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_SMP 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 is not set
# 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=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
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=y
CONFIG_ISAPNP=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD 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=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_INITRD=y

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD 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=y
# 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_IP_MROUTE is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# 

ISIcom cards by Multi-tech

[Michael Reinelt]

Hi there,

who is maintaining the isicom driver? A customer of mine uses such a
card in a linux server, when we upgraded from kernel 2.0 to 2.4.3 this
week, there have been some minor problems with this card.

There is a driver in the official 2.4 tree, but it seems quite old.
There are newer drivers at the multitech homepage, but only for kernel
2.2. Especially one new feature (resetting the card; from time to time
the card stucks and could only be resetted by rebooting) looks very
important to me.

As multitech seems not to provide a driver for 2.4, someone must have
ported the 2.2 driver to 2.4. I'd like to talk to this person, and help
merging the 2.2 updates to 2.4.

TIA, Michael

-- 
netWorks  Vox: +43 316  692396
Michael Reinelt   Fax: +43 316  692343
Geisslergasse 4   GSM: +43 676 3079941
A-8045 Graz, Austria  e-mail: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Multi-function PCI devices

[Michael Reinelt]

Jeff Garzik wrote:
> 
> Michael Reinelt wrote:
> > basically an extension of the pci id tables; and I hope it's in the
> > queue for the official kernel.
> 
> Where is this patch available?  I haven't heard of an extension to the
> pci id tables, so I wonder if it's really in the queue for the official
> kernel.

The patches went to Jens Maurer (pci_ids.h), Theodore Y. Ts'o (serial.c
and pci_ids.h) and Tim Waugh (parport_pc.c and pci_ids.h).

Well, and 'extension' may be the wrong word. I just added entries to
pci_ids.h and to the detection tables in parport_pc.c and serial.c

> > pci_announce_device() will be called only if there's no other driver
> > claiming the device. This explains why either the parallel or the serial
> > port will be detected: The first driver loaded will see the device, the
> > next drivers won't.

> There is no need to register more than one driver per PCI device -- just
> create a PCI driver whose probe routine registers serial and parallel,
> and whose remove routine unregisters same.

This means create a new module, which does the detection and uses
serial.c and parport_pc.c? I could do this (at least try to :-), but I'd
need some help here. I'm not a kernel hacker, and don't know much about
the pci code, module dependencies, driver tables, hotplugging and all
that stuff. If someone could provide a small sample (or skeleton) code
for this, I'd try my best

On the other hand, how should the serial and parallel driver detect the
netmos card, if it's a independant module? How could this interfere with
devfs? How should devfsd know if it should load serial.o or netmos.o?

Adding PCI entries to both serial.c and parport_pc.c was that easy

bye, Michael

-- 
netWorks  Vox: +43 316  692396
Michael Reinelt   Fax: +43 316  692343
Geisslergasse 4   GSM: +43 676 3079941
A-8045 Graz, Austria  e-mail: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Proper way to release binary driver?

[Christopher Turcksin]

Hello,



I would like to thank everybody who replied to my question yesterday.
There were a lot of good suggestions and examples for me to go and look
at.

The conclusion we had come to between ourselves here was already very
similar to most things suggested, but we were running into some smaller
problems that would make our release too difficult to use for most
customers.

And ofcourse, I have no realised that it is not enough to simply release
your code under GPL. You need to tie in with the real kernel as soon as
you can.

Thanks again all for your help.


-- 
bfn,
wabbit

IBM Global Services, UK AMS in Greenock, Scotland.

" To err is human, but to really foul things up requires the root
password. "
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.2.19 smp interrupt problems?

[Manfred Spraul]

> 
> everything seems to work fine. are these interrupt problems "bad" or merely 
> indicators of a high load. can/should one get rid of them? 
>
Could you try the 8139too driver?

It's a bug in the rtl8139 driver, and under really high load it can
cause crashes.

--
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: Multi-function PCI devices

[Tim Waugh]

On Sat, Apr 07, 2001 at 04:57:29AM -0400, Jeff Garzik wrote:

> Where is this patch available?  I haven't heard of an extension to the
> pci id tables, so I wonder if it's really in the queue for the official
> kernel.

It is.  http://people.redhat.com/twaugh/patches/>  The
'extension' is just 'more entries', AFAIR.

> > I'm afraid this is not a bug, but a design issue, and will be hard to
> > solve. Maybe we need a flag for such devices which allows it to be
> > claimed ba more thean one driver?
> 
> Not so hard.

*sigh* Jeff, when I spoke to you about this last year you said
 'tough', or words to that effect. :-(

> There is no need to register more than one driver per PCI device -- just
> create a PCI driver whose probe routine registers serial and parallel,
> and whose remove routine unregisters same.

*cough* modularity *cough*

Wnat to show us some elegant code that does that?

Tim.
*/

 PGP signature

reporting a kernel bug

[Petri Järvinen]

[1.] One line summary of the problem:
machine freezes

[2.] Full description of the problem/report:
machine freezes when daily.cron runs itself

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

[4.] Kernel version (from /proc/version):
Linux version 2.4.3s1 (root@setri) (gcc version 2.95.2.1 19991024
(release)) #1 Sun Apr 1 00:22:43 EEST 2001

[5.] Output of Oops.. message (ifapplicable) with symbolic information
 resolved (see Documentation/oops-tracing.txt)
Everything from "messages" -log file:

Apr  7 04:02:00 setri anacron[15066]: Updated timestamp for job
`cron.daily' to 2001-04-07
Apr  7 04:03:02 setri kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0028
Apr  7 04:03:02 setri kernel:  printing eip:
Apr  7 04:03:02 setri kernel: c0130374
Apr  7 04:03:02 setri kernel: *pde = 
Apr  7 04:03:02 setri kernel: Oops: 
Apr  7 04:03:02 setri kernel: CPU:0
Apr  7 04:03:02 setri kernel: EIP:0010:[try_to_free_buffers+52/364]
Apr  7 04:03:02 setri kernel: EFLAGS: 00010203
Apr  7 04:03:02 setri kernel: eax:    ebx:    ecx:
   edx: 
Apr  7 04:03:02 setri kernel: esi:    edi: c3a446e0   ebp:
c11152f0   esp: c12e5f8c
Apr  7 04:03:02 setri kernel: ds: 0018   es: 0018   ss: 0018
Apr  7 04:03:02 setri kernel: Process bdflush (pid: 6,
stackpage=c12e5000)
Apr  7 04:03:02 setri kernel: Stack: c11152f0 c111530c  14fe
  c0127007 c11152f0
Apr  7 04:03:02 setri kernel: c12e4000 0041 c12e423a
c12fbfc4  0004 
Apr  7 04:03:02 setri kernel:09b2  c0130733 0007
 00010f00 c12fbf88 c12fbfc4
Apr  7 04:03:02 setri kernel: Call Trace: [page_launder+855/2132]
[bdflush+131/200] [kernel_thread+40/56]
Apr  7 04:03:02 setri kernel:
Apr  7 04:03:02 setri kernel: Code: 8b 76 28 8b 50 18 8b 40 10 83 e2 46
09 d0 0f 85 e8 00 00 00
Apr  7 04:03:06 setri kernel: kernel BUG at exit.c:458!
Apr  7 04:03:06 setri kernel: invalid operand: 
Apr  7 04:03:06 setri kernel: CPU:0
Apr  7 04:03:06 setri kernel: EIP:0010:[do_exit+550/560]
Apr  7 04:03:06 setri kernel: EFLAGS: 00010282
Apr  7 04:03:06 setri kernel: eax: 001a   ebx: c02112c0   ecx:
c12e4000   edx: 
Apr  7 04:03:06 setri kernel: esi: c12e4000   edi: 000b   ebp:
c12e4000   esp: c12e5e84
Apr  7 04:03:06 setri kernel: ds: 0018   es: 0018   ss: 0018
Apr  7 04:03:06 setri kernel: Process bdflush (pid: 6,
stackpage=c12e5000)
Apr  7 04:03:06 setri kernel: Stack: c01ddce5 c01ddd7c 01ca 
 0028 c010724e 000b
Apr  7 04:03:06 setri kernel:c0110247 c01dc9de c12e5f58 
c12e4000  c010ff24 c11152f0
Apr  7 04:03:06 setri kernel:c12c1f80  0001 c3394180
00030001 c027d8a0 0286 c12fd2a0
Apr  7 04:03:07 setri kernel: Call Trace: [die+66/68]
[do_page_fault+803/1036] [do_page_fault+0/1036]
[cursor_timer_handler+34/40] [timer_bh+546/604] [tqueue_bh+22/28]
[bh_action+27/96]
Apr  7 04:03:07 setri kernel:[tasklet_hi_action+60/96]
[error_code+52/60] [try_to_free_buffers+52/364] [page_launder+855/2132]
[bdflush+131/200] [kernel_thread+40/56]
Apr  7 04:03:07 setri kernel:
Apr  7 04:03:07 setri kernel: Code: 0f 0b 83 c4 0c e9 2b fe ff ff 8b 4c
24 04 85 c9 74 08 ff 01
Apr  7 04:03:07 setri kernel: kernel BUG at exit.c:458!
Apr  7 04:03:07 setri kernel: invalid operand: 
Apr  7 04:03:07 setri kernel: CPU:0
Apr  7 04:03:07 setri kernel: EIP:0010:[do_exit+550/560]
Apr  7 04:03:07 setri kernel: EFLAGS: 00010286
Apr  7 04:03:07 setri kernel: eax: 001a   ebx:    ecx:
0001   edx: c0213308
Apr  7 04:03:07 setri kernel: esi: c12e4000   edi: 000b   ebp:
c12e4000   esp: c12e5d8c
Apr  7 04:03:07 setri kernel: ds: 0018   es: 0018   ss: 0018
Apr  7 04:03:07 setri kernel: Process bdflush (pid: 6,
stackpage=c12e5000)
Apr  7 04:03:07 setri kernel: Stack: c01ddce5 c01ddd7c 01ca c12e5e50
 c0107464 c010724e 000b
Apr  7 04:03:07 setri kernel:c01074e3 c01d809a c12e5e50 
c12e4000  0004 
Apr  7 04:03:07 setri kernel:00030002 c011561e c12fa000 
c12e5df0 c12fa000 c12e4000 c12fa000
Apr  7 04:03:07 setri kernel: Call Trace: [do_invalid_op+0/136]
[die+66/68] [do_invalid_op+127/136] [do_exit+550/560] [vsprintf+830/876]
[error_code+52/60] [do_exit+550/560]
Apr  7 04:03:07 setri kernel:[die+66/68]
[do_page_fault+803/1036] [do_page_fault+0/1036]
[cursor_timer_handler+34/40] [timer_bh+546/604] [tqueue_bh+22/28]
[bh_action+27/96] [tasklet_hi_action+60/96]
Apr  7 04:03:07 setri kernel:[error_code+52/60]
[try_to_free_buffers+52/364] [page_launder+855/2132] [bdflush+131/200]
[kernel_thread+40/56]
Apr  7 04:03:07 setri kernel:
Apr  7 04:03:07 setri kernel: Code: 0f 0b 83 c4 0c e9 2b fe ff ff 8b 4c
24 04 85 c9 74 08 ff 01
Apr  7 04:03:07 setri kernel: kernel BUG at exit.c:458!
Apr  7 04:03:07 setri kernel: invalid operand: 
Apr  7 04:03:07 

Re: Multi-function PCI devices

[Jeff Garzik]

Michael Reinelt wrote:
> I've got a problem with my communication card: It's a PCI card with a
> NetMos chip, and it provides two serial and one parallel port. It's not
> officially supported by the linux kernel, so I wrote my own patch and
> sent it to the parallel, serial and pci maintainer. The patch itself is
> basically an extension of the pci id tables; and I hope it's in the
> queue for the official kernel.

Where is this patch available?  I haven't heard of an extension to the
pci id tables, so I wonder if it's really in the queue for the official
kernel.


> The card shows up on the PCI bus as one device. For the card provides
> both serial and parallel ports, it will be driven by two subsystems, the
> serial and the parallel driver.
[...]
> pci_announce_device() will be called only if there's no other driver
> claiming the device. This explains why either the parallel or the serial
> port will be detected: The first driver loaded will see the device, the
> next drivers won't.
> 
> I'm afraid this is not a bug, but a design issue, and will be hard to
> solve. Maybe we need a flag for such devices which allows it to be
> claimed ba more thean one driver?

Not so hard.

There is no need to register more than one driver per PCI device -- just
create a PCI driver whose probe routine registers serial and parallel,
and whose remove routine unregisters same.

Jeff


-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 tcp window id causes problems talking to windows clients

[Alan Cox]

> to be working quite well (except for the lack of swap reclamation-- I 
> appreciate the reasoning, but it makes upgrading older machines very 
> difficult.)  However, I would rather, for maintenance and sanity 

-ac will acquire swap cache reclaim in time, dunno about Linus tree but
I assume it will once it has 0 cost on hot paths. Right now there are
serious 2.4 vm correctness issues to fix first.

> Is there any plan to include the zerocopy patches into the stock kernel? 
>   The win2k dial-up/window id problem is really a showstopper but hasn't 
> generated much traffic on lkml or the digests. 
> 

I'd hope so. The binfmt_misc and file size security holes that are fixed
in -ac I also want to try and push to Linus for 2.4.4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: syslog insmod please!

[Russell King]

On Fri, Apr 06, 2001 at 01:50:29PM +0100, Philip Blundell wrote:
> Floating point on ARM is indeed something of a crock, but that particular case
> used to work -- can you tell where it's going wrong?  See entry-armv.S, 
> about line 680, for the very bad hack that was supposed to facilitate this 
> kind of thing.

I've already discussed this issue with David on irc, and I resolved it a
few kernel versions ago (read my 2.4 release notes on the web site).

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

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

Re: Proper way to release binary driver?

[Alan Cox]

> We had hoped that MODVERSIONS would allow us to provide a single (or at
> most a few) binary driver. Kernels with even minor version numbers are
> supposed to be stable (even if they are buggy) ie. not have wildly
> changing kernel interfaces.

They have a stable API. THe ABI thing is an irrelevance to free software.
avoiding the ABI compatibility mess is one of the great things free
software lets you do.

Alan

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

Multi-function PCI devices

[Michael Reinelt]

Hi there,

I've got a problem with my communication card: It's a PCI card with a
NetMos chip, and it provides two serial and one parallel port. It's not
officially supported by the linux kernel, so I wrote my own patch and
sent it to the parallel, serial and pci maintainer. The patch itself is
basically an extension of the pci id tables; and I hope it's in the
queue for the official kernel. 

The patch worked great for me with kernel 2.4.1 and .2, but no longer
with 2.4.3. The parallel port still works, but the serial port will not
be detected. I had a quite long debugging session last night (adding
printk's to the pci code takes some time, for you have to reboot to load
the new kernel), and I think I found the reason:

The card shows up on the PCI bus as one device. For the card provides
both serial and parallel ports, it will be driven by two subsystems, the
serial and the parallel driver.

I found that _either_ the parallel or the serial port works, depending
on which module you load first. The reason for this seems to be in
pci.c, especially in the pci_register_driver() function. It reads:

int pci_register_driver(struct pci_driver *drv)
{
struct pci_dev *dev;
int count = 0;

list_add_tail(>node, _drivers);
pci_for_each_dev(dev) {
if (!pci_dev_driver(dev))
count += pci_announce_device(drv, dev);
}
return count;
}


pci_announce_device() will be called only if there's no other driver
claiming the device. This explains why either the parallel or the serial
port will be detected: The first driver loaded will see the device, the
next drivers won't.

I'm afraid this is not a bug, but a design issue, and will be hard to
solve. Maybe we need a flag for such devices which allows it to be
claimed ba more thean one driver?

In the meantime, what can I do to get both ports working?

TIA, Michael

-- 
netWorks  Vox: +43 316  692396
Michael Reinelt   Fax: +43 316  692343
Geisslergasse 4   GSM: +43 676 3079941
A-8045 Graz, Austria  e-mail: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/