All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Vaguely NFS related problem
From: Trond Myklebust @ 2002-12-13 14:07 UTC (permalink / raw)
  To: Jeff L. Smith; +Cc: Neil Brown, nfs
In-Reply-To: <3DF8C2BF.8050109@atheros.com>

>>>>> " " == Jeff L Smith <jeff@atheros.com> writes:

     > I plan to upgrade to 2.4.20 as soon as I can take the
     > fileservers down long enough, but that will be a few weeks.
     > But then that begs the question, should I apply Trond's 2.4.20
     > patches?

FYI: There are no further NFS server-related patches in my 2.4.20
patchsets.

The only server patches I included earlier were beta-versions of the
NFS over TCP related stuff ('cos they conflicted with some of the
client changes). Now that the finalized TCP code has been merged into
the mainstream kernel by Neil, I've dropped them.

Cheers,
  Trond


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply

* Re: 2.5.51: new warning from lilo
From: Dave Jones @ 2002-12-13 14:11 UTC (permalink / raw)
  To: Alan Cox; +Cc: Pavel Machek, Linux Kernel Mailing List
In-Reply-To: <1039789418.25121.25.camel@irongate.swansea.linux.org.uk>

On Fri, Dec 13, 2002 at 02:23:38PM +0000, Alan Cox wrote:
 > > Warning: Kernel & BIOS return differing head/sector geometries for
 > > device 0x80
 > >     Kernel: 8944 cylidners, 15 heads, 63 sectors
 > >       BIOS: 525 cylinders, 255 heads, 63 sectors
 > > 
 > > lilo did not warn under 2.5.50. Now... Will it boot?
 > 
 > Someone took various bits of geometry mapping out of the kernel. It will
 > now give different values. As to whether lilo will still boot I don't
 > know. I'd be suprised if it was a problem. 

Hasn't caused a problem on any of my test boxes.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

^ permalink raw reply

* Re: 2.5.51: sleep broken
From: P. Christeas @ 2002-12-13 14:04 UTC (permalink / raw)
  To: Grover, Andrew, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <200212130111.32710.p_christ-U04EIuiosng@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

>
> Sorry, I was quite lazy debugging that. Seems though that 20021205 doesn't
> have that. I'll let you know if it should be pushed into 2.5.52..
>
That line should go on, it works.
However, it seems that something is still broken w. sleep.  
Yesterday, 1 out of 2 attempts to sleep,wake failed. The machine froze, with 
an apparent race (the cpu heated up).
Today, I could get an OOPS in 1 of 3 attempts to sleep. I give (early) the 
decoded info (I have no ksyms!? ). Perhaps you could make out sth of the 
trace..

[-- Attachment #2: oops.dec --]
[-- Type: text/plain, Size: 2459 bytes --]

ksymoops 2.4.5 on i686 2.5.51.  Options used
     -v /usr/src/linux/vmlinux (specified)
     -K (specified)
     -l /proc/modules (default)
     -o /lib/modules/2.5.51/ (default)
     -m /boot/System.map (specified)

No modules in ksyms, skipping objects
No ksyms, skipping lsmod
NMI: IOCK error (debug interrupt?)
CPU:    0
EIP:    0060:[acpi_hw_register_read+207/528]    Not tainted
EIP:    0060:[<c01c555f>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00000046
eax: 00000000   ebx: 00000000   ecx: cff54100   edx: 00000000
esi: 00000001   edi: 00000001   ebp: c4fb5eb8   esp: c4fb5e94
ds: 0068   es: 0068   ss: 0068
Stack: 00000010 c4fb5ea8 cff54100 00000000 00feebc0 00000000 00000000 c4fb5ef4
       c032f078 c4fb5edc c01c5271 00000000 00000001 c4fb5ecc 00000000 c4fb5ef4
       c032f0a0 c032f0a8 c4fb5f08 c01c5d9b 00000006 c4fb5ef4 00000001 00003001
Call Trace: [acpi_get_register+97/160]  [acpi_enter_sleep_state+507/608]  [acpi_system_suspend+76/80]  [acpi_suspend+135/192]  [acpi_system_write_sleep+171/224]  [vfs_write+175/288]  [sys_write+60/96]  [syscall_call+7/11]
Call Trace: [<c01c5271>]  [<c01c5d9b>]  [<c01dca9c>]  [<c01dcb27>]  [<c01dcccb>]  [<c014c71f>]  [<c014c82c>]  [<c010a203>]
Code: eb 9f a1 50 5b 39 c0 0f b6 50 58 05 94 00 00 00 c7 04 24 10


>>EIP; c01c555f <acpi_hw_register_read+cf/210>   <=====

>>ecx; cff54100 <END_OF_CODE+fba9e8c/????>
>>ebp; c4fb5eb8 <END_OF_CODE+4c0bc44/????>
>>esp; c4fb5e94 <END_OF_CODE+4c0bc20/????>

Trace; c01c5271 <acpi_get_register+61/a0>
Trace; c01c5d9b <acpi_enter_sleep_state+1fb/260>
Trace; c01dca9c <acpi_system_suspend+4c/50>
Trace; c01dcb27 <acpi_suspend+87/c0>
Trace; c01dcccb <acpi_system_write_sleep+ab/e0>
Trace; c014c71f <vfs_write+af/120>
Trace; c014c82c <sys_write+3c/60>
Trace; c010a203 <syscall_call+7/b>

Code;  c01c555f <acpi_hw_register_read+cf/210>
00000000 <_EIP>:
Code;  c01c555f <acpi_hw_register_read+cf/210>   <=====
   0:   eb 9f                     jmp    ffffffa1 <_EIP+0xffffffa1> c01c5500 <acpi_hw_register_read+70/210>   <=====
Code;  c01c5561 <acpi_hw_register_read+d1/210>
   2:   a1 50 5b 39 c0            mov    0xc0395b50,%eax
Code;  c01c5566 <acpi_hw_register_read+d6/210>
   7:   0f b6 50 58               movzbl 0x58(%eax),%edx
Code;  c01c556a <acpi_hw_register_read+da/210>
   b:   05 94 00 00 00            add    $0x94,%eax
Code;  c01c556f <acpi_hw_register_read+df/210>
  10:   c7 04 24 10 00 00 00      movl   $0x10,(%esp,1)


^ permalink raw reply

* [parisc-linux] Re: fic problem
From: John Marvin @ 2002-12-13 13:42 UTC (permalink / raw)
  To: parisc-linux

>               __asm__ __volatile__("fic (%0)" :: "r" (spot) );

The assembler should not allow this, but it does. The problem is that
whoever wrote the assembly/disassembly support for parisc didn't really
understand the difference between instructions with 2 bit s fields and
3 bit s fields. fdc has a 2 bit s field, so when you specify "fdc (%0)"
it puts a 0 in the s field, which tells the processor to use the space
registers associated with the top two bits of the address (sr4-sr7). But
if you disassemble the instruction it will print "fdc (sr0,<register>),
which is incorrect, since sr0 is not involved.

fic has a 3 bit s field. In that case, the space register must be specified
explicitly. specifying "fic (%0)" should be illegal. But instead the
assembler just puts a zero in the s field of the instruction. But in this
case it does mean to use sr0. So when you specify "fic (%0)", you are
really specifying "fic (sr0,%0)". Since sr0 is a scratch space register,
you probably have not set it to anything appropriate, so that is probably
why the fic instruction is segfaulting on you (assuming "spot" is a legal
address in your address space).

On parisc linux we use a linear, non segmented address space, so all four
quadrants of the address space are in the same parisc space. That means
that sr4 through sr7 are set to the same value while running in user space.
So, you should change your call to fic to use any of those 4 space registers.
The general convention has been to use sr7. So instead of specifying
"fic (%0)", you should specify "fic (sr7,%0)".

John Marvin
jsm@fc.hp.com

^ permalink raw reply

* Re: 2.5.51: new warning from lilo
From: Pavel Machek @ 2002-12-13 13:46 UTC (permalink / raw)
  To: Alan Cox; +Cc: Linux Kernel Mailing List
In-Reply-To: <1039789418.25121.25.camel@irongate.swansea.linux.org.uk>

Hi!

> > Lilo now presents me with new warning:
> > 
> > Warning: Kernel & BIOS return differing head/sector geometries for
> > device 0x80
> >     Kernel: 8944 cylidners, 15 heads, 63 sectors
> >       BIOS: 525 cylinders, 255 heads, 63 sectors
> > 
> > lilo did not warn under 2.5.50. Now... Will it boot?
> 
> Someone took various bits of geometry mapping out of the kernel. It will
> now give different values. As to whether lilo will still boot I don't
> know. I'd be suprised if it was a problem. 

It still boots.
								Pavel

-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

^ permalink raw reply

* Re: PROBLEM: PS/2 keyboard and mouse not available/working/weird
From: Bas Vermeulen @ 2002-12-13 12:53 UTC (permalink / raw)
  To: Take Vos; +Cc: Vojtech Pavlik, Linux Kernel Mailing List
In-Reply-To: <200212122036.18595.Take.Vos@binary-magic.com>

On Thu, 12 Dec 2002, Take Vos wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tuesday 22 October 2002 16:34, Vojtech Pavlik wrote:
> > On Tue, Oct 22, 2002 at 04:03:49PM +0200, Take Vos wrote:
> > > In 2.5.44 both my PS/2 mice are not available, neither is my keyboard,
> > > although after sufficient keystrokes, sometimes 5, sometimes more, the
> > > keyboard is found, this is with Xfree.
> I am now using 2.5.51 and I still have the problem when I reboot from a 2.5.51 
> kernel to a 2.5.51 or 2.4.19 kernel both my internal keyboard and mouse (DELL 
> Inspiron 8100) are not working anymore. The strange thing is the keyboard 
> does work in grub.
> 
> relevant dmesg output:
> 	device class 'input': registering
> 	register interface 'mouse' with class 'input'
> 	mice: PS/2 mouse device common for all mice
> 	register interface 'joystick' with class 'input'
> 	register interface 'event' with class 'input'
> 	input: PS/2 Synaptics TouchPad on isa0060/serio1
> 	serio: i8042 AUX port at 0x60,0x64 irq 12
> 	input: AT Set 2 keyboard on isa0060/serio0
> 	serio: i8042 KBD port at 0x60,0x64 irq 1

I have exactly the same problem on an Inspiron 8000. Been that way since 
2.5.4x (7 or 8), but cannot get a working 2.5.51 to test at this point.

Just to add another data point. :)

Bas Vermeulen

-- 
"God, root, what is difference?" 
	-- Pitr, User Friendly

"God is more forgiving." 
	-- Dave Aronson


^ permalink raw reply

* Re: 2.5.5[01]]: Xircom Cardbus broken (PCI resource collisions)
From: Valdis.Kletnieks @ 2002-12-13 13:45 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Alessandro Suardi, linux-kernel
In-Reply-To: <1039774224.1449.0.camel@laptop.fenrus.com>

[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

On Fri, 13 Dec 2002 11:10:24 +0100, Arjan van de Ven said:
> On Thu, 2002-12-12 at 23:47, Valdis.Kletnieks@vt.edu wrote:
> > --- drivers/pcmcia/cardbus.c.dist	2002-12-03 01:49:29.000000000 -0500
> > +++ drivers/pcmcia/cardbus.c	2002-12-03 01:50:23.000000000 -0500
> > @@ -283,8 +283,6 @@
> >  		dev->hdr_type = hdr & 0x7f;
> >  
> >  		pci_setup_device(dev);
> > -		if (pci_enable_device(dev))
> > -			continue;
> >  
> >  		strcpy(dev->dev.bus_id, dev->slot_name);
> >  
> > @@ -302,6 +300,8 @@
> >  			pci_writeb(dev, PCI_INTERRUPT_LINE, irq);
> >  		}
> >  
> > +		if (pci_enable_device(dev))
> > +			continue;
> >  		device_register(&dev->dev);
> >  		pci_insert_device(dev, bus);
> >  	}
> 
> interesting. BUT aren't we writing to the device 3 lines before where
> you add the pci_enable_device()? That sounds like a bad plan to me ;(

That's where pci_enable_device() *USED* to be - this is backing out a change
made in 2.5.50 - it added the if/continue wrapper and moved it up about 15
lines in the code. The problem seems to be that for many devices,
pci_enable_device() fails unless we do the pci_writeb() magic first.  Or
perhaps it's the call to pci_assign_resource() - I don't know. ;) The 2.4.18
tree has the pci_enable_device() at the same place - just without the if/
continue around it.  It can't be THAT evil, as that's the way 2.4.0 to 2.4.18
and 2.5.0 to 2.5.49 did it.. ;)

I see why the if/continue was added - you don't want to be calling
device_register()/pci_insert_device() if pci_enable_device() loses.  I don't
see why 2.5.50 moved the code up after pci_setup_device(). There's an outside
chance that the concept of moving the call was correct, but that it should have
been moved to between the calls to pci_assign_resource() and pci_readb().
If that's the case, then you're correct as well....

/Valdis (who shouldn't be trying to think before caffeine.. ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply

* Re: 2.5.51: new warning from lilo
From: Alan Cox @ 2002-12-13 14:23 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021212193451.GA458@elf.ucw.cz>

On Thu, 2002-12-12 at 19:34, Pavel Machek wrote:
> Hi!
> 
> Lilo now presents me with new warning:
> 
> Warning: Kernel & BIOS return differing head/sector geometries for
> device 0x80
>     Kernel: 8944 cylidners, 15 heads, 63 sectors
>       BIOS: 525 cylinders, 255 heads, 63 sectors
> 
> lilo did not warn under 2.5.50. Now... Will it boot?

Someone took various bits of geometry mapping out of the kernel. It will
now give different values. As to whether lilo will still boot I don't
know. I'd be suprised if it was a problem. 

Alan


^ permalink raw reply

* Re: Local APIC(?)+PIII mobile
From: Joel Jaeggli @ 2002-12-13 13:45 UTC (permalink / raw)
  To: João Seabra; +Cc: linux-kernel
In-Reply-To: <200212131156.11262.seabra@aac.uc.pt>

the intel 440mx chipset that the asus is based on doesn't include an apic. 
an apic is for doing multiprocessor interupt managemnet. across multiple 
I/O subsystem each can have it own set of interupts...

On Fri, 13 Dec 2002, João Seabra wrote:

> Hi all
> 
>  I have an Asus S8600. 
>  Mobile PIII 800Mhz + 192M RAM.
>  If i select "Local APIC support on uniprocessors" the kernel while booting 
> says there's no APIC present.Why?
>  I know the same problem with some other laptops.
>  Others detect it.
>  
> 
>  At home my Athlon Tunderbird + Asus A7V133-C with local APIC enabled detects 
> it but doesn seem to use it ... 
> 
>  cat /proc/interrupts
>            CPU0
>   0:     375529          XT-PIC  timer
>   1:       7452          XT-PIC  keyboard
>   2:          0          XT-PIC  cascade
>   5:     113246          XT-PIC  bttv, eth0
>   8:          2          XT-PIC  rtc
>  10:     144373          XT-PIC  EMU10K1
>  11:     382444          XT-PIC  nvidia
>  12:     153864          XT-PIC  PS/2 Mouse
>  14:      12346          XT-PIC  ide0
>  15:         12          XT-PIC  ide1
> NMI:          0
> ERR:          0
> 
> Anyway why do I need local APIC :) ?What are the advantages?Links?
> 
> Thank you very much for your kindness
> 
>  Best Regards,
> 
>  João Seabra
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli	      Academic User Services   joelja@darkwing.uoregon.edu    
--    PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E      --
  In Dr. Johnson's famous dictionary patriotism is defined as the last
  resort of the scoundrel.  With all due respect to an enlightened but
  inferior lexicographer I beg to submit that it is the first.
	   	            -- Ambrose Bierce, "The Devil's Dictionary"



^ permalink raw reply

* Re: fetchmail and smtp problem
From: Haines Brown @ 2002-12-13 13:31 UTC (permalink / raw)
  To: ray; +Cc: linux-newbie
In-Reply-To: <5.1.0.14.1.20021212161342.020eb720@celine>

Ray,

> Both localhost and localhost.localdomain are candidatef for appearing to 
> the right of the @ sign, as alternatives to (in your case) hartford-hwp.com 
> . From the failures, it appears that you are trying to use them to the left 
> of the @ sign, as a substitute for brownh . Attempts to do this, quite 
> properly, fail.
 
Yes, I realize that, but my hostname is hartford-hwp.com, and so I
thought I could mail to the hostname and its aliases. I thought it
worth a try.

> So, based solely on these tests, there is NO evidence that sendmail
> is misconfigured. Bad addresses do bounce, and you do seem to get
> the bounces.

Which, given the challenges of sendmail, is good news.

> There might be a configuration problem in rmail (an MUA I am
> unfamiliar with) that causes the bcc attempts to fail, or there may
> be something else causing that problem (in fetchmail, sendmail, or
> the ISP's smtp server) ... but nothing you report below helps to
> sort that one out.

My understanding is that after fetchmail puts incoming mail into my
incoming queue (/var/spool/mail/brownh), rmail takes it, reformats the
header, and passes it along to sendmail, saving it in its own queue
(~/RMAIL). Rmail is meant for use with uucp and sendmail under
emacs. While I gather it can be a standalone application, I've not
been able to use it that way (ignorance). It has a -T debug option,
which I'll try, and a -D option to use a specified domain instead of
the default domain of ``UUCP''. It has no configuration as far as I
know, but only its executable and another binary file,
/usr/bin/rmail.sendmail.

But rather than chase my tail trying to fathom rmail, I'll use mutt
and also set up Mozilla as a mail utility to see what happens.
 
> I can't figure out what you are talking about with respect to item
> #2 in your list of messages.
> 
> Finally, in an earlier message you expressed some bewilderment about
> the term "outbox".

> a place where your MUA stores copies of e-mail messages you have
> sent.

I have always associated the term with MS, perhaps inaccurately (or
was Netscape reponsible?). I don't recall it from DOS or OS/2
days. The three examples I listed were from what I took to be rmail's
outgoing queue (or sendmail's incoming?), /var/spool/brownh, (I assume
the "outbox"). Sorry I was not clearer on that. You ask for more
information on the message that tried to get out to a mail forwarding
server (kb1grm@arrl.net), but timed out. Here is it:

> From brownh@hartford-hwp.com  Thu Dec 12 14:49:05 2002
> Return-Path: <brownh@hartford-hwp.com>
> Received: from hartford-hwp.com (hartford-hwp.com [127.0.0.1])
> 	by hartford-hwp.com (8.12.5/8.12.5) with ESMTP id gBCJn2Mw000877
> 	for <brownh@hartford-hwp.com>; Thu, 12 Dec 2002 14:49:04 -0500
> Received: (from brownh@localhost)
>	by hartford-hwp.com (8.12.5/8.12.5/Submit) id gBBN6WfB002624;
>	Wed, 11 Dec 2002 18:06:32 -0500
> Date: Wed, 11 Dec 2002 18:06:32 -0500
> Message-Id: <200212112306.gBBN6WfB002624@hartford-hwp.com>
> From: Haines Brown <brownh@hartford-hwp.com>
> To: kb1grm@arrl.net
> Subject: test from RH8.0 to kb1grm, dec 11 1800
> Reply-to: brownh@hartford-hwp.com
>
> From MAILER-DAEMON@hartford-hwp.com  Thu Dec 12 14:49:06 2002
> Return-Path: <MAILER-DAEMON@hartford-hwp.com>
> Received: from hartford-hwp.com (hartford-hwp.com [127.0.0.1])
> 	by hartford-hwp.com (8.12.5/8.12.5) with ESMTP id gBCJn2N0000877
>	for <brownh@hartford-hwp.com>; Thu, 12 Dec 2002 14:49:05 -0500
> Received: from localhost (localhost)
>	by hartford-hwp.com (8.12.5/8.12.5/Submit) id gBCJn2fM000871;
>	Thu, 12 Dec 2002 14:49:05 -0500
> Date: Thu, 12 Dec 2002 14:49:05 -0500
> From: Mail Delivery Subsystem <MAILER-DAEMON@hartford-hwp.com>
> Message-Id: <200212121949.gBCJn2fM000871@hartford-hwp.com>
> To: brownh@hartford-hwp.com
> MIME-Version: 1.0
> Content-Type: multipart/report; report-type=delivery-status;
>	boundary="gBCJn2fM000871.1039722545/hartford-hwp.com"
> Subject: Warning: could not send message for past 4 hours
> Auto-Submitted: auto-generated (warning-timeout)
>
> This is a MIME-encapsulated message
>
> --gBCJn2fM000871.1039722545/hartford-hwp.com
>
>    **********************************************
>    **      THIS IS A WARNING MESSAGE ONLY      **
>    **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
>    **********************************************
>
> The original message was received at Wed, 11 Dec 2002 18:06:32 -0500
> from brownh@localhost
>
>   ----- Transcript of session follows -----
> 451 arrl.net: Name server timeout
> 451 arrl.net: Name server timeout
> Warning: message still undelivered after 4 hours
> Will keep trying until message is 5 days old
>
> --gBCJn2fM000871.1039722545/hartford-hwp.com
> Content-Type: message/delivery-status
> 
> Reporting-MTA: dns; hartford-hwp.com
> Arrival-Date: Wed, 11 Dec 2002 18:06:32 -0500
> 
> Final-Recipient: RFC822; kb1grm@arrl.net
> Action: delayed
> Status: 4.4.3
> Last-Attempt-Date: Thu, 12 Dec 2002 14:49:05 -0500
> Will-Retry-Until: Mon, 16 Dec 2002 18:06:32 -0500
>
> --gBCJn2fM000871.1039722545/hartford-hwp.com
> Content-Type: message/rfc822
>
> Return-Path: <brownh>
> Received: (from brownh@localhost)
>	by hartford-hwp.com (8.12.5/8.12.5/Submit) id gBBN6WfB002624;
>	Wed, 11 Dec 2002 18:06:32 -0500
> Date: Wed, 11 Dec 2002 18:06:32 -0500
> Message-Id: <200212112306.gBBN6WfB002624@hartford-hwp.com>
> From: Haines Brown <brownh@hartford-hwp.com>
> To: kb1grm@arrl.net
> Subject: test from RH8.0 to kb1grm, dec 11 1800
> Reply-to: brownh@hartford-hwp.com

I did not originally expand on this message because it seemed to me to
resemble the first. Here, brown@localhost reports that the mailer
daemon at hartford-hwp.com had to delay sending the message to
kb1grm@hartford-hwp.com because it could not resolve the arrl.net
domain? This message strikes me as the kind of thing one would expect
in the incoming queue.

> You should see if rmail maintains a maibox called out, or outbox, or
> sent-messages, or some other plausible synonym; if it does, you
> could then let us *see* the problem messages (at least the headers)
> rather than just telling us what you remember, or what you think is
> important, about them.

I suspect the message above, more than four hours having passed, will
show up in rmail's incoming queue when next I boot. 

Fetchmail has a lot of options, and I'm trying to make sense of
them. One or two might be revealing.

Haines

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

^ permalink raw reply

* Re: Local APIC(?)+PIII mobile
From: Alan Cox @ 2002-12-13 14:15 UTC (permalink / raw)
  To: João Seabra; +Cc: Linux Kernel Mailing List
In-Reply-To: <200212131156.11262.seabra@aac.uc.pt>

On Fri, 2002-12-13 at 11:56, João Seabra wrote:
>  I have an Asus S8600. 
>  Mobile PIII 800Mhz + 192M RAM.
>  If i select "Local APIC support on uniprocessors" the kernel while booting 
> says there's no APIC present.Why?
>  I know the same problem with some other laptops.
>  Others detect it.

Because there isn't one present 8)

The APIC although on processor isnt present in all processors - at least
not all older ones. Its not a required CPU feature so not every
processor vendor includes it on all their processors.

Alan



^ permalink raw reply

* [parisc-linux] 2.4.20-pa14 64bit crash on boot - A500-5X
From: Thibaut VARENE @ 2002-12-13 13:28 UTC (permalink / raw)
  To: parisc-linux

[-- Attachment #1: Type: text/plain, Size: 3358 bytes --]

Hi pa-ckers

I'm dropping here a brief report of a crash I just experienced with
the latest 2.4 kernel on our A500.

For various reasons you don't want to know, I cannot currently track
that problem down, so i'm providing the System.map and .config of that
kernel :)

kernel built using hppa64-gcc-3.0.4 on the A500, based on the previous
kernel's .config (2.4.19-pa22).

Console log:

pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
Redundant entry in serial pci_table.  Please send the output of
lspci -vv, this message (103c,1048,103c,1049)
and the manufacturer and name of serial board or modem board
to serial-pci-info@lists.sourceforge.net.
ttyS00 at iomem 0xfffffffff8000000 (irq = 132) is a 16550A
ttyS01 at iomem 0xfffffffff8000008 (irq = 132) is a 16550A
ttyS02 at iomem 0xfffffffff8000010 (irq = 132) is a 16550A

Press Q/q to quit, Enter to continue: 

Redundant entry in serial pci_table.  Please send the output of
lspci -vv, this message (103c,1048,103c,104a)
and the manufacturer and name of serial board or modem board
to serial-pci-info@lists.sourceforge.net.
spin_unlock(000000001039a8d0): no lock cpu 0 curr PC 00000000101101a4
swapper/1

Stack Dump:
 0000000014ced200:  000000ff0804ff0e 00000000a9c50000 0000000010143bd4
0000000000000040 
 0000000014ced1e0:  00000000103f8d60 0000000010356684 0000000000000084
fffffffff8000010 
 0000000014ced1c0:  0000000010549800 0000000000000000 0000000010549800
000000001046ce00 
 0000000014ced1a0:  00000000104b6c00 0000000010549800 000000001046ce00
028000001046ce00 
 0000000014ced180:  00000000104ec000 000000001046ce00 000000001048e7b4
0000000014cece90 
 0000000014ced160:  000000000000007e 00000000103569a8 0000000014cecfb8
000000001046ce00 

Kernel addresses on the stack:
 [<0000000010143bd4>]  [<000000001014bf2c>]  [<0000000010281a94>] 
[<000000001014018c>] 
 [<0000000010281b98>]  [<00000000101003c0>]  [<0000000010108460>] 
[<0000000010108518>] 
 [<00000000101317dc>]  [<0000000010137c98>]  [<0000000010326804>] 
[<0000000010100390>] 
 [<0000000010137960>] 


Press Q/q to quit, Enter to continue: 

Kernel Fault: Code=26 regs=0000000014ced200 (Addr=0000000000000008)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00001000000001001111111100001110 Not tainted
r00-03  0000000000000000 0000000010518e50 0000000010143bd4
0000000010538b48
r04-07  0000000000000000 000000000800000f 000000001046ce00
0000000000000000
r08-11  0000000010538898 00000000105389d8 00000000103fc4b0
0000000010538898
r12-15  00000000103fc4a0 0000000010538898 0000000010538898
0000000010538898
r16-19  00000000103fc480 0000000010538898 0000000010538898
0000000010538b48
r20-23  0000000000000000 0000000010519e50 0000000000002e49
0000000000002eac
r24-27  0000000000000001 0000000000002eac 00000000103df7c0
000000001046ce00
r28-31  0000000000000000 0000000014ced1f0 0000000014ced200
000000001047be00
sr0-3   0000000000000000 0000000000000000 0000000000000000
0000000000000000
sr4-7   0000000000000000 0000000000000000 0000000000000000
0000000000000000

IASQ: 0000000000000000 0000000000000000 IAOQ: 0000000010143c48
0000000010143c4c
 IIR: 0e8312d0    ISR: 0000000000000000  IOR: 0000000000000008
 CPU:        0   CR30: 0000000014cec000 CR31: 00000000104f0000
 ORIG_R28: 0000000010325edc


HTH,


Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/

[-- Attachment #2: config-2.4.20-pa14 --]
[-- Type: application/octet-stream, Size: 12092 bytes --]

#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_PARISC=y
# CONFIG_UID16 is not set
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type
#
# CONFIG_PA7100 is not set
# CONFIG_PA7200 is not set
# CONFIG_PA7100LC is not set
CONFIG_PA8X00=y
CONFIG_PA20=y
CONFIG_PARISC64=y
# CONFIG_PDC_NARROW is not set

#
# General options
#
CONFIG_SMP=y
CONFIG_CHASSIS_LCD_LED=y
# CONFIG_IOMMU_CCIO is not set
CONFIG_GSC=y
# CONFIG_GSC_LASI is not set
# CONFIG_GSC_WAX is not set
# CONFIG_EISA is not set
# CONFIG_ISA is not set
CONFIG_PCI=y
CONFIG_GSC_DINO=y
CONFIG_PCI_LBA=y
CONFIG_IOSAPIC=y
CONFIG_IOMMU_SBA=y
# CONFIG_SUPERIO is not set
CONFIG_PCI_NAMES=y

#
# General setup
#
# CONFIG_HOTPLUG is not set
CONFIG_NET=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SOM=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_PM is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_BLK_STATS=y

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

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
CONFIG_VLAN_8021Q=y
# CONFIG_IPX is not set
# CONFIG_ATALK is not set

#
# Appletalk devices
#
# CONFIG_DEV_APPLETALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

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

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set

#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_SR_EXTRA_DEVS=2
# CONFIG_CHR_DEV_SG is not set
# CONFIG_SCSI_DEBUG_QUEUES is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_DMA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_LASI700 is not set
# CONFIG_SCSI_NCR53C7xx is not set
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_IOMAPPED=y
# CONFIG_ASK_ZALON is not set
# CONFIG_ASK_NCR53C8XX is not set
# CONFIG_ASK_SYM53C8XX is not set
# CONFIG_SCSI_ZALON is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_DEBUG is not set

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_LASI_82596 is not set
# CONFIG_SUNLANCE is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_APRICOT is not set
# CONFIG_CS89x0 is not set
CONFIG_TULIP=y
CONFIG_TULIP_MWI=y
CONFIG_TULIP_MMIO=y
# CONFIG_DE4X5 is not set
# CONFIG_DGRS is not set
# CONFIG_DM9102 is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_LNE390 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_NE3210 is not set
# CONFIG_ES3210 is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_SUNDANCE_MMIO is not set
# CONFIG_TLAN is not set
# CONFIG_TC35815 is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_RHINE_MMIO is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_MYRI_SBUS is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Input core support
#
# CONFIG_INPUT is not set
# CONFIG_INPUT_KEYBDEV is not set
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256

#
# I2C support
#
# CONFIG_I2C is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_MOUSE is not set

#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
# CONFIG_QIC02_TAPE is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_GENRTC=y
# CONFIG_AMD_PM768 is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set

#
# HIL support
#

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_FAT_FS is not set
# CONFIG_MSDOS_FS is not set
# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
# CONFIG_JFS_FS is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UDF_RW is not set
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set

#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_TCP is not set
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set
# CONFIG_ZISOFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_SMB_NLS is not set
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Console drivers
#

#
# Frame-buffer support
#
# CONFIG_FB is not set
# CONFIG_STI_CONSOLE is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# Kernel hacking
#
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_SPINLOCK=y

#
# Library routines
#
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y

[-- Attachment #3: System.map-2.4.20-pa14.bz2 --]
[-- Type: application/octet-stream, Size: 130901 bytes --]

^ permalink raw reply

* Re: [PATCH][RESEND] POSIX message queues, 2.5.50
From: Krzysztof Benedyczak @ 2002-12-13 13:24 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: linux-kernel, Abbas, Mohamed, Michal Wronski, Manfred Spraul
In-Reply-To: <20021203151238.A14315@infradead.org>



On Tue, 3 Dec 2002, Christoph Hellwig wrote:

> > +struct mq_attr {
> > +	long mq_flags;		/* message queue flags */
> > +	long mq_maxmsg;		/* maximum number of messages */
> > +	long mq_msgsize;	/* maximum message size */
> > +	long mq_curmsgs;	/* number of messages currently queued */
>
> Please don't use longs as ioctl arguments, better s32.  (and why
> can't this be unsigned, btw?)


I have no idea why it can't be unsigned. POSIX defined it to be long so we
just follow it :-)

We have made other code improvements (e.g. it can work as module) and
here is latest version.
Our page http://www.mat.uni.torun.pl/~wrona/posix_ipc
contains also this patch in version suitable for 2.4.19 kernel.

Regards

Krzysiek


---------------------------------------------------------------------------
diff -urN linux-2.5.50-org/CREDITS linux-2.5.50-patched/CREDITS
--- linux-2.5.50-org/CREDITS	2002-11-27 23:36:15.000000000 +0100
+++ linux-2.5.50-patched/CREDITS	2002-12-02 13:09:57.000000000 +0100
@@ -279,6 +279,15 @@
 S: Greenbelt, Maryland 20771
 S: USA

+N: Krzysztof Benedyczak
+E: golbi@mat.uni.torun.pl
+W: http://www.mat.uni.torun.pl/~golbi
+D: POSIX message queues fs (with M. Wronski)
+S: ul. Podmiejska 52
+S: Radunica
+S: 83-000 Pruszcz Gdanski
+S: Poland
+
 N: Randolph Bentson
 E: bentson@grieg.seaslug.org
 W: http://www.aa.net/~bentson/
@@ -3380,6 +3389,14 @@
 S: Portland, OR 97204
 S: USA

+N: Michal Wronski
+E: wrona@mat.uni.torun.pl
+W: http://www.mat.uni.torun.pl/~wrona
+D: POSIX message queues fs (with K. Benedyczak)
+S: ul. Teczowa 23/12
+S: 80-680 Gdansk-Sobieszewo
+S: Poland
+
 N: Frank Xia
 E: qx@math.columbia.edu
 D: Xiafs filesystem [defunct]
diff -urN linux-2.5.50-org/Documentation/ioctl-number.txt linux-2.5.50-patched/Documentation/ioctl-number.txt
--- linux-2.5.50-org/Documentation/ioctl-number.txt	2002-11-27 23:36:20.000000000 +0100
+++ linux-2.5.50-patched/Documentation/ioctl-number.txt	2002-11-29 21:03:35.000000000 +0100
@@ -186,5 +186,6 @@
 0xB0	all	RATIO devices		in development:
 					<mailto:vgo@ratio.de>
 0xB1	00-1F	PPPoX			<mailto:mostrows@styx.uwaterloo.ca>
+0xB2	00-04	linux/mqueue.h		<http://mat.uni.torun.pl/~wrona/posix_ipc>
 0xCB	00-1F	CBM serial IEC bus	in development:
 					<mailto:michael.klein@puffin.lb.shuttle.de>
diff -urN linux-2.5.50-org/fs/Kconfig linux-2.5.50-patched/fs/Kconfig
--- linux-2.5.50-org/fs/Kconfig	2002-11-27 23:36:03.000000000 +0100
+++ linux-2.5.50-patched/fs/Kconfig	2002-12-10 01:31:02.000000000 +0100
@@ -588,6 +588,28 @@

 	  If unsure, say N.

+config POSIX_MQUEUE
+	tristate "POSIX Message Queues"
+	---help---
+	  POSIX variant of message queues is a part of IPC. In POSIX message
+	  queues every message has a priority which decides about succession
+	  of receiving it by a process. If you want to compile and run
+	  programs written e.g. for Solaris with use of its POSIX message
+	  queues (functions mq_*) say Y here. To use this feature you will
+	  also need mqueue library, available from
+	  <http://www.mat.uni.torun.pl/~wrona/posix_ipc/>
+
+	  POSIX message queues are visible as a filesystem called 'mqueue'
+	  and should be mounted in /dev/mqueue in order to work with standard
+	  library.
+
+	  If you want to compile this as a module ( = code which can be
+	  inserted in and removed from the running kernel whenever you want),
+	  say M here and read <file:Documentation/modules.txt>.  The module
+	  will be called mqueue.o.
+
+	  If unsure, say N.
+
 config TMPFS
 	bool "Virtual memory file system support (former shm fs)"
 	help
diff -urN linux-2.5.50-org/include/linux/mqueue.h linux-2.5.50-patched/include/linux/mqueue.h
--- linux-2.5.50-org/include/linux/mqueue.h	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.5.50-patched/include/linux/mqueue.h	2002-12-06 13:54:39.000000000 +0100
@@ -0,0 +1,43 @@
+#ifndef _LINUX_MQUEUE_H
+#define _LINUX_MQUEUE_H
+
+#include <asm/types.h>
+
+#define MQ_MAX		64	/* max number of message queues */
+#define MQ_MAXMSG 	40	/* max number of messages in each queue */
+#define MQ_MSGSIZE 	16384	/* max message size */
+#define MQ_MAXSYSSIZE	1048576	/* max size that all m.q. can have together */
+#define MQ_PRIO_MAX 	32768	/* max priority */
+
+typedef int mqd_t;
+
+struct kern_mq_attr {
+	__u32	mq_flags;	/* message queue flags */
+	__u32	mq_maxmsg;	/* maximum number of messages */
+	__u32	mq_msgsize;	/* maximum message size */
+	__u32	mq_curmsgs;	/* number of messages currently queued */
+};
+
+
+/*
+*	struct for passing data via ioctls calls
+*/
+
+
+/* the same for send & receive */
+struct ioctl_mq_sndrcv {
+	__u64	msg_ptr;
+	__u32	msg_len;
+	__u64	msg_prio;	/* it is long or long* */
+	__u64	timeout;
+};
+
+
+#define MQ_IOC_CREATE	_IOW(0xB2, 0, struct kern_mq_attr)
+#define MQ_IOC_GETATTR	_IOR(0xB2, 1, struct kern_mq_attr)
+#define MQ_IOC_SEND	_IOW(0xB2, 2, struct ioctl_mq_sndrcv)
+#define MQ_IOC_RECEIVE	_IOR(0xB2, 3, struct ioctl_mq_sndrcv)
+#define MQ_IOC_NOTIFY	_IOW(0xB2, 4, struct sigevent)
+
+
+#endif
diff -urN linux-2.5.50-org/ipc/Makefile linux-2.5.50-patched/ipc/Makefile
--- linux-2.5.50-org/ipc/Makefile	2002-11-27 23:35:50.000000000 +0100
+++ linux-2.5.50-patched/ipc/Makefile	2002-11-27 21:13:35.000000000 +0100
@@ -5,5 +5,6 @@
 obj-y   := util.o

 obj-$(CONFIG_SYSVIPC) += msg.o sem.o shm.o
+obj-$(CONFIG_POSIX_MQUEUE) += mqueue.o

 include $(TOPDIR)/Rules.make
diff -urN linux-2.5.50-org/ipc/mqueue.c linux-2.5.50-patched/ipc/mqueue.c
--- linux-2.5.50-org/ipc/mqueue.c	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.5.50-patched/ipc/mqueue.c	2002-12-10 01:16:05.000000000 +0100
@@ -0,0 +1,1074 @@
+/*
+ * POSIX message queues filesystem for Linux.
+ *
+ * Copyright (C) 2002 	Krzysztof Benedyczak 	(golbi@mat.uni.torun.pl)
+ *			Michal Wronski		(wrona@mat.uni.torun.pl)
+ *
+ * This file is released under the GPL.
+ */
+
+
+#include <linux/mqueue.h>
+#include <linux/slab.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/smp_lock.h>
+#include <linux/poll.h>
+#include <linux/sched.h>
+#include <linux/init.h>
+#include <linux/pagemap.h>
+
+#include <asm/current.h>
+#include <asm/siginfo.h>
+#include <asm/uaccess.h>
+
+
+#define MQUEUE_MAGIC	0x19800202
+#define DIRENT_SIZE	20
+#define FILENT_SIZE	60
+
+
+struct msg {			/* this represent particular message */
+	unsigned int msg_len;	/* in the queue */
+	unsigned int msg_prio;
+	char *mtext;
+};
+
+struct ext_wait_queue {		/* queue of sleeping processes */
+	struct task_struct *task;
+	struct list_head list;
+};
+
+
+/* this stores extra data for inode - queue specific data */
+struct mqueue_inode_info {
+	struct kern_mq_attr attr;
+	/* table of sorted pointers to messages */
+	struct msg *messages[MQ_MAXMSG];
+	pid_t notify_pid;	/* who we have to notify (or 0) */
+	struct sigevent notify;	/* notification */
+	/* for processes waiting for free space or message (respectively) */
+	/* this is left mainly because of poll */
+	wait_queue_head_t wait_q[2];
+	/* avoids extra invocations of wake_up */
+	wait_queue_head_t wait_q2[2];
+	struct ext_wait_queue e_wait_q[2];	/* 0=free space   1=message */
+	struct semaphore mq_sem;
+	/* size of queue in memory (msgs & struct) */
+	__u32 qsize;
+
+	/* VFS stuff */
+	struct inode vfs_inode;
+};
+
+
+static unsigned long msgs_size;	/* sum of sizes of all msgs in all queues */
+static unsigned int queues_count;	/* number of existing queues */
+static struct semaphore mq_sem;	/* main queues semaphore */
+
+/* fs stuff */
+static inline struct mqueue_inode_info *MQUEUE_I(struct inode *ino)
+{
+	return list_entry(ino, struct mqueue_inode_info, vfs_inode);
+}
+
+static kmem_cache_t *mqueue_inode_cachep;
+
+static int mqueue_ioctl_file(struct inode *inode, struct file *filp,
+			     unsigned int cmd, unsigned long arg);
+static unsigned int mqueue_poll_file(struct file *,
+				     struct poll_table_struct *);
+static struct super_block *mqueue_get_sb(struct file_system_type *fs_type,
+					 int flags, char *dev_name,
+					 void *data);
+static int mqueue_create(struct inode *dir, struct dentry *dent, int mode);
+static struct inode *mqueue_alloc_inode(struct super_block *sb);
+static void mqueue_destroy_inode(struct inode *inode);
+static int mqueue_release_file(struct inode *ino, struct file *f);
+static void mqueue_delete_inode(struct inode *ino);
+static int mqueue_unlink(struct inode *dir, struct dentry *dent);
+static ssize_t mqueue_read_file(struct file *, char *, size_t, loff_t *);
+
+static struct inode *mqueue_get_inode(struct super_block *sb, int mode);
+
+static struct inode_operations mqueue_dir_inode_operations = {
+	.lookup = simple_lookup,
+	.create = mqueue_create,
+	.unlink = mqueue_unlink,
+};
+
+static struct file_operations mqueue_file_operations = {
+	.ioctl = mqueue_ioctl_file,
+	.release = mqueue_release_file,
+	.poll = mqueue_poll_file,
+	.read = mqueue_read_file,
+};
+
+static struct super_operations mqueue_super_ops = {
+	.alloc_inode = mqueue_alloc_inode,
+	.destroy_inode = mqueue_destroy_inode,
+	.statfs = simple_statfs,
+	.delete_inode = mqueue_delete_inode,
+	.drop_inode = generic_delete_inode,
+};
+
+static struct file_system_type mqueue_fs_type = {
+	.owner = THIS_MODULE,
+	.name = "mqueue",
+	.get_sb = mqueue_get_sb,
+	.kill_sb = kill_litter_super,
+};
+
+
+/*
+*		GENERAL FUNCTIONS FOR FS CREATION
+*/
+
+/*
+* 	auxiliary function - produce a new inode
+*/
+static struct inode *mqueue_get_inode(struct super_block *sb, int mode)
+{
+	struct inode *inode;
+	struct mqueue_inode_info *ino_extra;
+
+	inode = new_inode(sb);
+	if (inode) {
+		inode->i_mode = mode;
+		inode->i_uid = current->fsuid;
+		inode->i_gid = current->fsgid;
+		inode->i_blksize = PAGE_CACHE_SIZE;
+		inode->i_blocks = 0;
+		inode->i_rdev = NODEV;
+		inode->i_atime = inode->i_mtime = inode->i_ctime =
+		    CURRENT_TIME;
+		if ((mode & S_IFMT) == S_IFREG) {
+			inode->i_fop = &mqueue_file_operations;
+			inode->i_size = FILENT_SIZE;
+			/* mqueue specific info */
+			ino_extra = MQUEUE_I(inode);
+			init_MUTEX(&(ino_extra->mq_sem));
+			init_waitqueue_head((&(ino_extra->wait_q[0])));
+			init_waitqueue_head((&(ino_extra->wait_q[1])));
+			init_waitqueue_head((&(ino_extra->wait_q2[0])));
+			init_waitqueue_head((&(ino_extra->wait_q2[1])));
+			INIT_LIST_HEAD(&(ino_extra->e_wait_q[0].list));
+			INIT_LIST_HEAD(&(ino_extra->e_wait_q[1].list));
+			ino_extra->notify_pid = 0;
+			ino_extra->notify.sigev_signo = 0;
+			ino_extra->notify.sigev_notify = SIGEV_NONE;
+			ino_extra->qsize =
+			    sizeof(struct mqueue_inode_info);
+			ino_extra->attr.mq_curmsgs = 0;
+			/* fill up with defaults
+			 * (mq_open will set it up via next ioctl call) */
+			ino_extra->attr.mq_maxmsg = 0;
+			ino_extra->attr.mq_msgsize = 0;
+		} else if ((mode & S_IFMT) == S_IFDIR) {
+			inode->i_nlink++;
+			/* Some things misbehave if size == 0 on a directory */
+			inode->i_size = 2 * DIRENT_SIZE;
+			inode->i_op = &mqueue_dir_inode_operations;
+			inode->i_fop = &simple_dir_operations;
+		}
+	}
+	return inode;
+}
+
+
+static int mqueue_parse_options(char *options, int *mode, uid_t * uid,
+				gid_t * gid, int silent)
+{
+	char *this_char, *value, *rest;
+
+	while ((this_char = strsep(&options, ",")) != NULL) {
+		if (!*this_char)
+			continue;
+		if ((value = strchr(this_char, '=')) != NULL) {
+			*value++ = 0;
+		} else {
+			if (!silent)
+				printk(KERN_ERR
+				       "mqueuefs: No value for mount option '%s'\n",
+				       this_char);
+			return 1;
+		}
+
+		if (!strcmp(this_char, "mode")) {
+			if (!mode)
+				continue;
+			*mode = simple_strtoul(value, &rest, 8);
+			if (*rest)
+				goto bad_val;
+		} else if (!strcmp(this_char, "uid")) {
+			if (!uid)
+				continue;
+			*uid = simple_strtoul(value, &rest, 0);
+			if (*rest)
+				goto bad_val;
+		} else if (!strcmp(this_char, "gid")) {
+			if (!gid)
+				continue;
+			*gid = simple_strtoul(value, &rest, 0);
+			if (*rest)
+				goto bad_val;
+		} else {
+			if (!silent)
+				printk(KERN_ERR
+				       "mqueuefs: Bad mount option %s\n",
+				       this_char);
+			return 1;
+		}
+	}
+	return 0;
+
+bad_val:
+	if (!silent)
+		printk(KERN_ERR
+		       "mqueuefs: Bad value '%s' for mount option '%s'\n",
+		       value, this_char);
+	return 1;
+
+}
+
+
+/* function for get_sb_nodev. Fill up our data in super block */
+static int mqueue_fill_super(struct super_block *sb, void *data,
+			     int silent)
+{
+	struct inode *inode;
+	uid_t uid = current->fsuid;
+	gid_t gid = current->fsgid;
+	int mode = S_IRWXUGO;
+
+	if (mqueue_parse_options(data, &mode, &uid, &gid, silent))
+		return -EINVAL;
+	sb->s_blocksize = PAGE_CACHE_SIZE;
+	sb->s_blocksize_bits = PAGE_CACHE_SHIFT;
+	sb->s_magic = MQUEUE_MAGIC;
+	sb->s_op = &mqueue_super_ops;
+
+	inode = mqueue_get_inode(sb, S_IFDIR | mode);
+
+	if (!inode)
+		return -ENOMEM;
+	inode->i_uid = uid;
+	inode->i_gid = gid;
+
+	sb->s_root = d_alloc_root(inode);
+
+	if (!sb->s_root) {
+		iput(inode);
+		return -ENOMEM;
+	}
+	return 0;
+}
+
+/* called when mounting */
+static struct super_block *mqueue_get_sb(struct file_system_type *fs_type,
+					 int flags, char *dev_name,
+					 void *data)
+{
+	return get_sb_nodev(fs_type, flags, data, mqueue_fill_super);
+}
+
+
+static struct inode *mqueue_alloc_inode(struct super_block *sb)
+{
+	struct mqueue_inode_info *ei;
+	ei = (struct mqueue_inode_info *)
+	    kmem_cache_alloc(mqueue_inode_cachep, SLAB_KERNEL);
+	if (!ei)
+		return NULL;
+	return &ei->vfs_inode;
+}
+
+static void mqueue_destroy_inode(struct inode *inode)
+{
+	kmem_cache_free(mqueue_inode_cachep, MQUEUE_I(inode));
+}
+
+static void init_once(void *foo, kmem_cache_t * cachep,
+		      unsigned long flags)
+{
+	struct mqueue_inode_info *p = (struct mqueue_inode_info *) foo;
+
+	if ((flags & (SLAB_CTOR_VERIFY | SLAB_CTOR_CONSTRUCTOR)) ==
+	    SLAB_CTOR_CONSTRUCTOR) {
+		inode_init_once(&p->vfs_inode);
+	}
+}
+
+
+static int init_inode_cache(void)
+{
+	mqueue_inode_cachep = kmem_cache_create("mqueue_inode_cache",
+						sizeof(struct
+						       mqueue_inode_info),
+						0, SLAB_HWCACHE_ALIGN,
+						init_once, NULL);
+	if (mqueue_inode_cachep == NULL)
+		return -ENOMEM;
+	return 0;
+}
+
+static void destroy_inode_cache(void)
+{
+	if (kmem_cache_destroy(mqueue_inode_cachep))
+		printk(KERN_INFO
+		       "mqueue_inode_cache: not all structures were freed\n");
+}
+
+
+/*
+*	init function
+*/
+static int __init init_mqueue_fs(void)
+{
+	int error;
+	error = init_inode_cache();
+
+	if (error) {
+		printk(KERN_ERR
+		       "Could not init inode cache for mqueue filesystem\n");
+		return error;
+	}
+
+	error = register_filesystem(&mqueue_fs_type);
+	if (error) {
+		printk(KERN_ERR "Could not register mqueue filesystem\n");
+		goto out_inodecache;
+	}
+
+	/* internal initialization - not common for vfs */
+	msgs_size = 0;
+	queues_count = 0;
+	init_MUTEX(&mq_sem);
+
+	return 0;
+
+out_inodecache:
+	destroy_inode_cache();
+	return error;
+}
+
+static void __exit exit_mqueue_fs(void)
+{
+	unregister_filesystem(&mqueue_fs_type);
+	destroy_inode_cache();
+}
+
+module_init(init_mqueue_fs)
+module_exit(exit_mqueue_fs)
+
+MODULE_LICENSE("GPL");
+
+static void mqueue_delete_inode(struct inode *ino)
+{
+	int i;
+	struct mqueue_inode_info *info;
+
+	if ((ino->i_mode & S_IFMT) == S_IFDIR) {
+		clear_inode(ino);
+		return;
+	}
+	info = MQUEUE_I(ino);
+	i = 0;
+	down(&info->mq_sem);
+	while (info->attr.mq_curmsgs > 0) {
+		kfree(info->messages[i]->mtext);
+		msgs_size -= info->messages[i]->msg_len;
+		kfree(info->messages[i]);
+		info->messages[i] = NULL;
+		i++;
+		info->attr.mq_curmsgs--;
+	}
+	up(&info->mq_sem);
+	clear_inode(ino);
+	down(&mq_sem);
+	queues_count--;
+	up(&mq_sem);
+}
+
+static int mqueue_unlink(struct inode *dir, struct dentry *dent)
+{
+	struct inode *inode = dent->d_inode;
+
+	dir->i_size -= DIRENT_SIZE;
+	inode->i_nlink--;
+	dput(dent);
+	return 0;
+}
+
+
+static int mqueue_create(struct inode *dir, struct dentry *dent, int mode)
+{
+	struct inode *ino;
+	int error = 0;
+
+	down(&mq_sem);
+	if (queues_count >= MQ_MAX) {
+		error = -ENOSPC;
+		goto out;
+	}
+	ino = mqueue_get_inode(dir->i_sb, mode);
+	if (!ino) {
+		error = -ENOMEM;
+		goto out;
+	}
+
+	queues_count++;
+	up(&mq_sem);
+
+	dir->i_size += DIRENT_SIZE;
+	dir->i_ctime = dir->i_mtime = CURRENT_TIME;
+
+	d_instantiate(dent, ino);
+	dget(dent);
+	return 0;
+out:
+	up(&mq_sem);
+	return error;
+}
+
+/*
+*	This is routine for system read from queue file.
+*	To avoid mess with doing some
+*	sort of mq_receive here we allow to read only: queue size &
+* 	notification info (the only values that are interesting from user
+*	point of view and aren't accessible through std. routines)
+*/
+static ssize_t mqueue_read_file(struct file *file, char *data, size_t size,
+				loff_t * off)
+{
+	char buffer[FILENT_SIZE + 1];
+	struct mqueue_inode_info *info = MQUEUE_I(file->f_dentry->d_inode);
+	ssize_t retval = 0;
+
+	if (*off >= FILENT_SIZE)
+		return 0;
+
+	snprintf(buffer, FILENT_SIZE + 1,
+		 "QSIZE:%-10u NOTIFY:%-5d SIGNO:%-6d NOTIFY_PID:%-6d",
+		 info->qsize, info->notify.sigev_notify,
+		 info->notify.sigev_signo, info->notify_pid);
+
+	retval = FILENT_SIZE - *off;
+	if (copy_to_user(data, buffer + *off, retval)) {
+		retval = (ssize_t) - EFAULT;
+		goto out;
+	}
+	*off += retval;
+out:
+	return retval;
+}
+
+
+static int mqueue_release_file(struct inode *ino, struct file *f)
+{
+	struct mqueue_inode_info *info = MQUEUE_I(ino);
+
+	down(&info->mq_sem);
+	if (info->notify_pid == current->pid) {
+		info->notify_pid = 0;
+		info->notify.sigev_signo = 0;
+		info->notify.sigev_notify = SIGEV_NONE;
+	}
+	up(&info->mq_sem);
+	return 0;
+}
+
+
+static unsigned int mqueue_poll_file(struct file *file,
+				     struct poll_table_struct *poll_tab)
+{
+	struct mqueue_inode_info *info = MQUEUE_I(file->f_dentry->d_inode);
+	int retval = 0;
+
+	poll_wait(file, &info->wait_q[0], poll_tab);
+	poll_wait(file, &info->wait_q[1], poll_tab);
+
+	down(&info->mq_sem);
+	if (info->attr.mq_curmsgs)
+		retval = POLLIN | POLLRDNORM;
+
+	if (info->attr.mq_curmsgs < info->attr.mq_maxmsg)
+		retval |= POLLOUT | POLLWRNORM;
+	up(&info->mq_sem);
+
+	return retval;
+}
+
+
+/*
+*			CORE MQUEUE FUNCTIONS
+*/
+
+/*
+*  This cut&paste version of wait_event() without event checking & with
+*  exclusive adding to queue.
+*/
+void inline wait_exclusive(wait_queue_head_t * wq,
+			   struct mqueue_inode_info *i)
+{
+	wait_queue_t wait;
+	init_waitqueue_entry(&wait, current);
+
+	add_wait_queue_exclusive(wq, &wait);
+	set_current_state(TASK_UNINTERRUPTIBLE);
+
+	up(&i->mq_sem);
+	schedule();
+	down(&i->mq_sem);
+
+	current->state = TASK_RUNNING;
+	remove_wait_queue(wq, &wait);
+}
+
+/* Removes from info->e_wait_q[sr] current process */
+static void wq_remove(struct mqueue_inode_info *info, int sr)
+{
+	struct ext_wait_queue *ptr;
+
+	if (!list_empty(&(info->e_wait_q[sr].list)))
+		list_for_each_entry(ptr, &(info->e_wait_q[sr].list), list) {
+			if (ptr->task->pid == current->pid) {
+				list_del(&(ptr->list));
+				kfree(ptr);
+				break;
+		}
+		}
+}
+
+/* adds current to info->e_wait_q[sr] before element with smaller prio */
+static inline int wq_add(struct mqueue_inode_info *info, int sr)
+{
+	struct ext_wait_queue *tmp, *ptr;
+
+	tmp = kmalloc(sizeof(struct ext_wait_queue), GFP_KERNEL);
+	if (tmp == NULL)
+		return -2;
+	tmp->task = current;
+
+	if (list_empty(&info->e_wait_q[sr].list))
+		list_add(&tmp->list, &info->e_wait_q[sr].list);
+	else {
+		list_for_each_entry(ptr, &info->e_wait_q[sr].list, list)
+			if (ptr->task->static_prio <= current->static_prio) {
+				/* we add before ptr element */
+				__list_add(&tmp->list, ptr->list.prev,
+					&ptr->list);
+				return 0;
+			}
+		/* we add on tail */
+		list_add_tail(&tmp->list, &info->e_wait_q[sr].list);
+	}
+	return 0;
+}
+
+/* removes from info->e_wait_q[sr] current process.
+ * Only for wq_sleep(): as we are here current must be one
+ * before-first (last) (meaning first in order as our 'queue' is inversed) */
+static inline void wq_remove_last(struct mqueue_inode_info *info, int sr)
+{
+	struct ext_wait_queue *tmp =
+	    list_entry(info->e_wait_q[sr].list.prev,
+		       struct ext_wait_queue, list);
+	list_del(&(tmp->list));
+	kfree(tmp);
+}
+
+/* adds current process
+ * sr: 0-send 1-receive
+ * Returns: 0=ok -1=signal -2=memory allocation error -3=timeout passed*/
+static int wq_sleep(struct mqueue_inode_info *info, int sr,
+		    signed long timeout)
+{
+	wait_queue_t __wait;
+	long error;
+
+	if (wq_add(info, sr) < 0)
+		return -2;
+
+	init_waitqueue_entry(&__wait, current);
+	add_wait_queue(&(info->wait_q[sr]), &__wait);
+
+	for (;;) {
+		set_current_state(TASK_INTERRUPTIBLE);
+		if ((current->pid ==
+		     (list_entry(info->e_wait_q[sr].list.prev,
+				 struct ext_wait_queue, list))->task->pid)
+		    && ((info->attr.mq_curmsgs > 0 && sr == 1)
+			|| (info->attr.mq_curmsgs <
+			    info->attr.mq_maxmsg && sr == 0)))
+			 break;
+		if (!signal_pending(current)) {
+			up(&info->mq_sem);
+			error = schedule_timeout(timeout);
+			down(&info->mq_sem);
+			if ((!error) && (!signal_pending(current))) {
+				remove_wait_queue(&(info->wait_q[sr]),
+						  &__wait);
+				wq_remove(info, sr);
+				return -3;
+			}
+			continue;
+		} else {
+			current->state = TASK_RUNNING;
+			remove_wait_queue(&(info->wait_q[sr]), &__wait);
+			wq_remove(info, sr);
+			return -1;
+		}
+	}
+	current->state = TASK_RUNNING;
+	remove_wait_queue(&(info->wait_q[sr]), &__wait);
+	wq_remove_last(info, sr);
+
+	return 0;
+}
+
+/* wakes up all sleeping processes in queue */
+static void wq_wakeup(struct mqueue_inode_info *info, int sr)
+{
+	if (sr == 0) {
+		/* We can't invoke wake_up for processes waiting for free space
+		 * if there is less then MAXMSG-1 messages - then wake_up was
+		 * invoked previously (and finished) but mq_sleep() of proper
+		 * (only one) process didn't start to continue running yet,
+		 * thus we must wait until this process receives IT'S message
+		 */
+		if ((info->attr.mq_curmsgs < info->attr.mq_maxmsg - 1)
+		    && (!list_empty(&info->e_wait_q[sr].list))) {
+			wait_exclusive(&(info->wait_q2[sr]), info);
+		}
+	} else {
+		/* As above but for processes waiting for new message */
+		if ((info->attr.mq_curmsgs > 1)
+		    && (!list_empty(&info->e_wait_q[sr].list))) {
+			wait_exclusive(&(info->wait_q2[sr]), info);
+		}
+	}
+	/* We can wake up now - either all are sleeping or
+	 * queue is empty. */
+	if (!list_empty(&info->e_wait_q[sr].list))
+		wake_up_process((list_entry(info->e_wait_q[sr].list.prev,
+					    struct ext_wait_queue,
+					    list))->task);
+}
+
+/*
+ * Invoked via ioctl to do the rest of work when creating new queue:
+ * set limits
+ */
+static int mq_create_ioctl(struct inode *ino, struct kern_mq_attr *u_attr)
+{
+	struct kern_mq_attr attr;
+	struct mqueue_inode_info *info = MQUEUE_I(ino);
+	int error = 0;
+
+	down(&info->mq_sem);
+	if (info->attr.mq_maxmsg != 0) {
+		error = -EBADF;
+		goto out;
+	}
+	if (u_attr != NULL) {
+		if (copy_from_user
+		    (&attr, u_attr, sizeof(struct kern_mq_attr))) {
+			error = -EFAULT;
+			goto out;
+		}
+		if (attr.mq_maxmsg == 0
+		    || attr.mq_msgsize == 0
+		    || attr.mq_maxmsg > MQ_MAXMSG
+		    || attr.mq_msgsize > MQ_MSGSIZE) {
+			error = -EINVAL;
+			goto out;
+		}
+		info->attr.mq_maxmsg = attr.mq_maxmsg;
+		info->attr.mq_msgsize = attr.mq_msgsize;
+	} else {
+		info->attr.mq_maxmsg = MQ_MAXMSG;
+		info->attr.mq_msgsize = MQ_MSGSIZE;
+	}
+out:
+	up(&info->mq_sem);
+	return error;
+}
+
+/*
+ * The next two functions are only to do little split of too long mq_send_ioctl
+ */
+
+static inline int check_send_arg(struct mqueue_inode_info *info, int oflag,
+				 struct ioctl_mq_sndrcv *arg,
+				 long *timeout)
+{
+	struct timespec ts;
+
+	/* checks if O_NONBLOCK is set and queue is full */
+	if ((oflag & O_NONBLOCK) != 0)
+		if (info->attr.mq_curmsgs == info->attr.mq_maxmsg)
+			return -EAGAIN;
+	/* checks msg_prio boundary */
+	if (arg->msg_prio >= (unsigned long) MQ_PRIO_MAX)
+		return -EINVAL;
+	/* checks if message isn't too large */
+	if (arg->msg_len > info->attr.mq_msgsize)
+		return -EMSGSIZE;
+	/* get & validate timeout */
+	if (arg->timeout) {
+		if (copy_from_user
+		    (&ts, (struct timespec *) (long) arg->timeout,
+		     sizeof(struct timespec)))
+			return -EFAULT;
+		if (ts.tv_nsec < 0 || ts.tv_sec < 0
+		    || ts.tv_nsec >= 1000000000L)
+			return -EINVAL;
+		/* it schould be enough */
+		*timeout = timespec_to_jiffies(&ts);
+	} else
+		*timeout = MAX_SCHEDULE_TIMEOUT;
+	return 0;
+}
+
+static inline void do_notify(struct mqueue_inode_info *info)
+{
+	struct siginfo sig_i;
+
+	/* notification
+	 * invoked when there is registered process and there isn't process
+	 * waiting synchronously for message AND state of queue changed from
+	 * empty to not empty*/
+	if (info->notify_pid != 0 && list_empty(&info->e_wait_q[1].list)
+	    && info->attr.mq_curmsgs == 1) {
+		/* TODO:
+		 *    Add support for sigev_notify==SIGEV_THREAD
+		 */
+		/* sends signal */
+		if (info->notify.sigev_notify == SIGEV_SIGNAL) {
+			sig_i.si_signo = info->notify.sigev_signo;
+			sig_i.si_errno = 0;
+			sig_i.si_code = SI_MESGQ;
+			sig_i.si_pid = current->pid;
+			sig_i.si_uid = current->uid;
+			kill_proc_info(info->notify.sigev_signo,
+				       &sig_i, info->notify_pid);
+		}
+		/* after notification unregisters process */
+		info->notify_pid = 0;
+		info->notify.sigev_signo = 0;
+		info->notify.sigev_notify = SIGEV_NONE;
+	}
+}
+
+int mq_send_ioctl(struct inode *ino, int oflag,
+		  struct ioctl_mq_sndrcv *u_arg)
+{
+	struct msg *tmp_ptr1;
+	char *tmp_ptr2;
+	int sleep_ret, i, error = 0;
+	struct mqueue_inode_info *info = MQUEUE_I(ino);
+	long timeout;
+	struct ioctl_mq_sndrcv arg;
+
+	if ((oflag & O_ACCMODE) == O_RDONLY)
+		return -EBADF;
+
+	if (copy_from_user(&arg, (void *) u_arg, sizeof(arg))) {
+		printk(KERN_ERR
+		       " mqueue fs: can't copy data from user space");
+		return -EFAULT;
+	}
+
+	down(&info->mq_sem);
+
+	error = check_send_arg(info, oflag, &arg, &timeout);
+	if (error < 0)
+		goto out;
+
+	/* checks if queue is full -> I'm waitng as O_NONBLOCK isn't        */
+	/* set then. mq_receive wakes up only 1 process                     */
+	if (info->attr.mq_curmsgs == info->attr.mq_maxmsg) {
+		sleep_ret = wq_sleep(info, 0, timeout);
+		if (sleep_ret == -1) {
+			error = -EINTR;
+			goto out;
+		} else if (sleep_ret == -2) {
+			error = -ENOMEM;
+			goto out;
+		} else if (sleep_ret == -3) {
+			error = -ETIMEDOUT;
+			goto out;
+		}
+	}
+
+	down(&mq_sem);
+	/* check if this message will exceed overall limit for mesages */
+	if (msgs_size + arg.msg_len > MQ_MAXSYSSIZE) {
+		error = -ENOMEM;
+		goto out_lock;
+	}
+
+	/* first try to allocate memory, before doing anything with
+	 * existing queues */
+	tmp_ptr1 = kmalloc(sizeof(struct msg), GFP_KERNEL);
+	if (!tmp_ptr1) {
+		error = -ENOMEM;
+		goto out_lock;
+	}
+	tmp_ptr2 = kmalloc(arg.msg_len, GFP_KERNEL);
+	if (!tmp_ptr2) {
+		error = -ENOMEM;
+		goto out_1free;
+	}
+
+	/* adds message to the queue */
+	i = info->attr.mq_curmsgs - 1;
+	while (i >= 0
+	       && info->messages[i]->msg_prio <
+	       (unsigned int) arg.msg_prio) {
+		info->messages[i + 1] = info->messages[i];
+		i--;
+	}
+
+	i++;			/* i == position */
+	info->messages[i] = tmp_ptr1;
+	info->messages[i]->msg_len = arg.msg_len;
+	info->messages[i]->msg_prio = (unsigned int) arg.msg_prio;
+	info->messages[i]->mtext = tmp_ptr2;
+	if (copy_from_user
+	    (info->messages[i]->mtext, (char *) (long) arg.msg_ptr,
+	     arg.msg_len)) {
+		error = -EFAULT;
+		printk(KERN_ERR " coping data from user failed\n");
+		goto out_2free;
+	}
+
+	info->attr.mq_curmsgs++;
+	msgs_size += arg.msg_len;
+	up(&mq_sem);
+	info->qsize += arg.msg_len;
+
+	do_notify(info);
+
+	/* after sending message we must wake up (ONLY 1 no matter which) */
+	/* process sleeping in wq_wakeup() */
+	wake_up(&(info->wait_q2[0]));
+
+	/* wakes up processes waiting for message */
+	wq_wakeup(info, 1);
+	goto out;
+out_2free:
+	kfree(tmp_ptr2);
+out_1free:
+	kfree(tmp_ptr1);
+out_lock:
+	up(&mq_sem);
+out:
+	up(&info->mq_sem);
+	return error;
+}
+
+
+ssize_t mq_receive_ioctl(struct inode * ino, long oflag,
+			 struct ioctl_mq_sndrcv * u_arg)
+{
+	int i, sleep_ret;
+	struct mqueue_inode_info *info = MQUEUE_I(ino);
+	struct timespec ts;
+	long timeout;
+	ssize_t retval;
+	struct ioctl_mq_sndrcv arg;
+
+	if ((oflag & O_ACCMODE) == O_WRONLY)
+		return -EBADF;
+
+	if (copy_from_user(&arg, u_arg, sizeof(struct ioctl_mq_sndrcv))) {
+		printk(KERN_ERR
+		       " mqueue fs: can't copy data from user space");
+		return -EFAULT;
+	}
+
+	down(&info->mq_sem);
+	/* checks if O_NONBLOCK is set and queue is empty */
+	if ((oflag & O_NONBLOCK) != 0)
+		if (info->attr.mq_curmsgs == 0) {
+			retval = -EAGAIN;
+			goto out;
+		}
+	/* get & validate timeout */
+	if (arg.timeout) {
+		if (copy_from_user
+		    (&ts, (struct timespec *) (long) arg.timeout,
+		     sizeof(struct timespec))) {
+			retval = -EFAULT;
+			goto out;
+		}
+		if (ts.tv_nsec < 0 || ts.tv_sec < 0
+		    || ts.tv_nsec >= 1000000000L) {
+			retval = -EINVAL;
+			goto out;
+		}
+		/* it schould be enough */
+		timeout = timespec_to_jiffies(&ts);
+	} else
+		timeout = MAX_SCHEDULE_TIMEOUT;
+
+	/* checks if queue is empty -> as O_NONBLOCK isn't set then
+	 * we must wait */
+	if (info->attr.mq_curmsgs == 0) {
+		sleep_ret = wq_sleep(info, 1, timeout);
+		if (sleep_ret == -1) {
+			retval = -EINTR;
+			goto out;
+		} else if (sleep_ret == -2) {
+			retval = -ENOMEM;
+			goto out;
+		} else if (sleep_ret == -3) {
+			retval = -ETIMEDOUT;
+			goto out;
+		}
+	}
+
+	/* checks if buffer is big enough */
+	if (arg.msg_len < info->messages[0]->msg_len) {
+		retval = -EMSGSIZE;
+		goto out;
+	}
+
+	retval = info->messages[0]->msg_len;
+	/* gets message */
+	if (arg.msg_prio)
+		if (put_user
+		    (info->messages[0]->msg_prio,
+		     (long *) (long) arg.msg_prio)) {
+			retval = -EFAULT;
+			goto out;
+		}
+	if (copy_to_user
+	    ((char *) (long) arg.msg_ptr, info->messages[0]->mtext,
+	     info->messages[0]->msg_len)) {
+		retval = -EFAULT;
+		goto out;
+	}
+	/* and deletes it */
+	kfree(info->messages[0]->mtext);
+	kfree(info->messages[0]);
+	for (i = 1; i < info->attr.mq_curmsgs; i++)
+		info->messages[i - 1] = (struct msg *) (info->messages[i]);
+	info->attr.mq_curmsgs--;
+	info->messages[info->attr.mq_curmsgs] = NULL;
+	/*decrease total space used by messages */
+	down(&mq_sem);
+	msgs_size -= retval;
+	up(&mq_sem);
+	info->qsize -= retval;
+
+	/* after receive we can wakeup 1 process waiting in wq_wakeup */
+	wake_up(&(info->wait_q2[1]));
+	/* wakes up processes waiting for sending message */
+	wq_wakeup(info, 0);
+out:
+	up(&info->mq_sem);
+	return retval;
+}
+
+
+int mq_notify_ioctl(struct inode *ino,
+		    const struct sigevent *u_notification)
+{
+	struct sigevent notification;
+	struct mqueue_inode_info *info = MQUEUE_I(ino);
+	int error = 0;
+
+	if (u_notification != NULL)
+		if (copy_from_user(&notification, u_notification,
+				   sizeof(struct sigevent)))
+			return -EFAULT;
+
+	down(&info->mq_sem);
+
+	if (info->notify_pid == current->pid
+	    && (u_notification == NULL ||
+		notification.sigev_notify == SIGEV_NONE)) {
+		info->notify_pid = 0;	/* remove notification */
+		info->notify.sigev_signo = 0;
+		info->notify.sigev_notify = SIGEV_NONE;
+	} else if (info->notify_pid > 0) {
+		error = -EBUSY;
+		goto out;
+	} else if (u_notification != NULL &&
+		   notification.sigev_notify != SIGEV_NONE) {
+		/* add notification */
+		info->notify_pid = current->pid;
+		info->notify.sigev_signo = notification.sigev_signo;
+		info->notify.sigev_notify = notification.sigev_notify;
+	}
+out:
+	up(&info->mq_sem);
+	return error;
+}
+
+int mq_getattr_ioctl(struct inode *ino, int oflag,
+		     struct kern_mq_attr *u_mqstat)
+{
+	struct kern_mq_attr attr;
+	struct mqueue_inode_info *info = MQUEUE_I(ino);
+	int error = 0;
+
+	down(&info->mq_sem);
+
+	attr = info->attr;
+	attr.mq_flags = oflag;
+
+	if (u_mqstat == NULL) {
+		error = -EINVAL;
+		goto out;
+	}
+
+	if (u_mqstat != NULL)
+		if (copy_to_user
+		    (u_mqstat, &attr, sizeof(struct kern_mq_attr)))
+			error = -EFAULT;
+out:
+	up(&info->mq_sem);
+	return error;
+}
+
+/*
+*	IOCTL FUNCTION - demultiplexer for various mqueues operations
+*/
+
+static int mqueue_ioctl_file(struct inode *inode, struct file *filp,
+			     unsigned int cmd, unsigned long arg)
+{
+	int ret = 1;
+
+	unlock_kernel();
+
+	switch (cmd) {
+	case MQ_IOC_CREATE:
+		ret = mq_create_ioctl(inode, (struct kern_mq_attr *) arg);
+		break;
+	case MQ_IOC_SEND:
+		ret =
+		    mq_send_ioctl(inode, filp->f_flags,
+				  (struct ioctl_mq_sndrcv *) arg);
+		break;
+	case MQ_IOC_RECEIVE:
+		ret =
+		    mq_receive_ioctl(inode, filp->f_flags,
+				     (struct ioctl_mq_sndrcv *) arg);
+		break;
+	case MQ_IOC_NOTIFY:
+		ret = mq_notify_ioctl(inode, (struct sigevent *) arg);
+		break;
+	case MQ_IOC_GETATTR:
+		ret = mq_getattr_ioctl(inode, filp->f_flags,
+				       (struct kern_mq_attr *) arg);
+		break;
+	}
+
+	lock_kernel();
+	return ret;
+}


^ permalink raw reply

* Re: Linux/alpha vs. 2.4.20 and ISO9660 vs long file names
From: Falk Hueffner @ 2002-12-13 13:22 UTC (permalink / raw)
  To: Stephen Williams; +Cc: linux-kernel
In-Reply-To: <5095-51149@sneakemail.com>

"Stephen Williams" <zhig9f05jg02@sneakemail.com> writes:

> For some reason, ls is having trouble with long file names on the
> disk. I follow with strace, and getdents64 is returning the right
> number of entries, but then ls tries to lstat a truncated name.  I
> can't say of the getdirent64 is trundating the name, but it seems
> likely.

This might be caused by a bug in stxcpy. Please try 2.4.210-pre1,
which contains a patch by Ivan Kokshaysky for this.

-- 
	Falk

^ permalink raw reply

* Re: R: Kernel bug handling TCP_RTO_MAX?
From: Andrew McGregor @ 2002-12-13 13:07 UTC (permalink / raw)
  To: Bogdan Costescu
  Cc: David S. Miller, dlstevens, matti.aarnio, niv, alan,
	stefano.andreani.ap, linux-kernel, linux-net
In-Reply-To: <Pine.LNX.4.44.0212131321400.11129-100000@kenzo.iwr.uni-heidelberg.de>

--On Friday, December 13, 2002 13:33:16 +0100 Bogdan Costescu 
<bogdan.costescu@iwr.uni-heidelberg.de> wrote:

> On Sat, 14 Dec 2002, Andrew McGregor wrote:
>
>> You're going to make lots of IETFer's really annoyed by suggesting that
>> :-)
>
> I hope not. That was the reason for allowing it to be tuned and for
> having  a default value equal to the existing one.

I know the folks in question :-)  Actually, they'd be nice about it, but 
say something like:

Well, RFC 2988 says that the present value is too small and should be 1s, 
although I take it from other discussion that experiment shows 200ms to be 
OK.

Instead, RFCs 3042 and 3390 present the IETF's preferred approach that has 
actually made it through the process.  But there are lots of drafts in 
progress, so that isn't the final word, although it is certainly better 
than tuning down RTO_MAX.

Now, I have no idea if the kernel presently implements the latter two by 
default (and on a quick look I can't find either in the code).  If not, it 
should.  Shouldn't the initial window be a tunable?

>> In a closed network, why not have SOCK_STREAM map to something faster
>> than  TCP anyway?
>
> Sure, just give me a protocol that:
> - is reliable
> - has low latency
> - comes with the standard kernel
> and I'll just use it. But you always get only 2 out ot 3...
>
> --
> Bogdan Costescu

SCTP is in 2.5 now.  Does that not fit the bill?  I admit, I don't know 
about the reliability, although I guess I'm going to find out as I have 
cause to use it shortly.  Wearing an IETF hat, I'd like to hear about this, 
as I'm on a bit of a practicality crusade there :-)

Andrew

^ permalink raw reply

* Re: Re:OT Is this going to be true ?
From: Billy Harvey @ 2002-12-13 13:19 UTC (permalink / raw)
  To: szonyi calin; +Cc: hps, lk
In-Reply-To: <20021213105625.53692.qmail@web40601.mail.yahoo.com>

On Fri, 2002-12-13 at 05:56, szonyi calin wrote:
>  --- "Henning P. Schmiedehausen" <hps@intermeta.de> a écrit : >
> Billy Harvey <Billy.Harvey@thrillseeker.net> writes:
> > Please read the FAQ at  http://www.tux.org/lkml/
> Please ...

WTF?  Does humor have to be kept at the level of the three stooges to be
understood these days?

Billy


^ permalink raw reply

* The Parallel port API- I need to write a device driver...!
From: Dean McEwan @ 2002-12-13 13:13 UTC (permalink / raw)
  To: linux-kernel

Where can I find information on how to write a
parallel port driver for a device im working on that 
needs to connect to a parallel port, I don't want
to write a driver for the parallel port just the device
that uses it.

Any help or advice would be helpful,
please 'cc any mail you send me to 
dean_mcewan@hotmail.com as Im not sure this account
is working properly. Thanks.
 ---
Cheers, Dean.



Need a new email address that people can remember
Check out the new EudoraMail at
http://www.eudoramail.com

^ permalink raw reply

* Re: bbram access problems
From: Geoffroy Stevenne @ 2002-12-13 13:35 UTC (permalink / raw)
  To: linux-mtd
In-Reply-To: <200212121540.43586.tglx@linutronix.de>

Le Thu, 12 Dec 2002 15:40:43 +0100
Thomas Gleixner <tglx@linutronix.de> a écrit:

> from slram.c
> NOTE:
>   With slram it's only possible to map a contigous memory region. 
> 
> So you can't access it with slram, as the BBSRAM is a device with
> paged access. All you have to do, is copy slram.c to bbram.c and add
> an additional parameter, which tells the driver the number of
> pages.available. Then modify the erase / read / write functions to do
> the page selection depending on the address you have to access. 
> If you think this is out of your league, then hope, that somebody does
> this for you sometimes, or ask one of the experts to help you for a
> little fee immidiately :)

Thanks to all! We will code... but I still can't figure how to prevent
other processes to access this memory area.  IANAE on memory locking and
stuff like that, nor in kernel programming in general.

I'll learn :-)

--
Geoffroy

^ permalink raw reply

* Re: [parisc-linux] fic problem
From: Matthew Wilcox @ 2002-12-13 12:45 UTC (permalink / raw)
  To: FARINATI,LEANDRO (HP-Brazil,ex1); +Cc: Parisc-Linux List (E-mail)
In-Reply-To: <9A0482A7BD2506488AD9417C93F3714FC27735@xsp01.brazil.hp.com>

On Fri, Dec 13, 2002 at 04:27:13AM -0800, FARINATI,LEANDRO (HP-Brazil,ex1) wrote:
>                 __asm__ __volatile__("fdc (%0)" :: "r" (spot) );
>                 __asm__ __volatile__("sync" ::);
>                 __asm__ __volatile__("fic (%0)" :: "r" (spot) );
> (segmentation fault in this line)
>                 __asm__ __volatile__("sync" ::);

don't do it like this.  do it this way:

		__asm__ __volatile__("\n\
			fdc (%0)\n\
			sync\n\
			fic (%0)\n\
			sync\n"
			: : "r" (spot)
		);

that ensures that these 4 insns really are together.  you might want to
look at the generated assembly output for this function (objdump -dr
foo.o |less) and/or recompile the kernel with PRINT_USER_TRAPS turned
on so you get a register dump so you can debug this yourself.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

^ permalink raw reply

* Linux installation on DOC / problems / I need your help
From: Alejandro O. Gonzalez @ 2002-12-13 13:12 UTC (permalink / raw)
  To: linux-mtd

I rebuild the kernel. Then I made this

1- run the driver
#modprobe doc2000
#modprobe docprobe

2- format the memory
#nftl_format /dev/mtd0 0 16777216

3- run nftl
#modprobe nftl

4- make a partition
#fdisk /dev/nftla
I make two partition first DOS, and second Linux.

5- make filesystem
#mkfs.msdos /dev/nftla1
#mke2fs /dev/nftla2

6-Install syslinux
#syslinux /dev/nftla1

7-configure boot and reboot

I don´t know if this procedure is correct, but when reboot the bios not
found a valid boot device.
When I format all memory with nftl_format command I delete the TrueFFS bios
of MSYS. This is Ok ?

I try then to overwrite the TrueFFS bios driver

DFORMAT /WIN:E000 /S:DOC512.EXB /NOFORMAT /FIRST

but display an error, can´t write the bios.

I do so that the bios recognize the DOC like a valid device of boot.

I try also to format with MSYS utility, then create a 2MB of DOS partition.
Boot with linux and format the last 14 MB of memory with
nftl_format. But when startup nftl driver says "we don´t support
UnitSizeFactor!=1" and it is not possible to work with a nftl partition.
I will appreciate any commentary, thank you for your time.
Regards,
Alejandro Gonzalez

^ permalink raw reply

* kernel isapnp (2.4.20)
From: h-peter recktenwald @ 2002-12-13 12:36 UTC (permalink / raw)
  To: linux-kernel
In-Reply-To: <Pine.LNX.4.33.0212082154480.913-100000@localhost.localdomain>

kernel 2.4.20 inbuilt isapp returns false data:
-----------------------------------------------
from /var/log/messages
sb creative 'vibra16', 

1) non-functional with isapnp by kernel:

kernel: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
kernel: sb: Creative ViBRA16X PnP detected
Dec  2 18:16:57 Lux3 kernel: sb: ISAPnP reports 'Creative ViBRA16X PnP' at 
i/o 0x220, irq 10, dma 1, 3
kernel: SB 4.16 detected OK (220)
kernel: SB16: Bad or missing 16 bit DMA channel
Dec  2 18:16:57 Lux3 kernel: sb: 1 Soundblaster PnP card(s) found.
------------------------------------------------

2) all but /dev/sndstat (which worked w. 2.4.19, same set-up) 
if kernel-isapnp disabled and, configured after <pnpdump> otput:

kernel: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
kernel: SB 4.16 detected OK (220)
kernel: <Sound Blaster 16 (4.16)> at 0x220 irq 7 dma 1,5
kernel: <Sound Blaster 16> at 0x330 irq 7 dma 0,0
kernel: YM3812 and OPL-3 driver Copyright (C) by Hannu Savolainen, Rob Hooft 
1993-1996
kernel: <Yamaha OPL3> at 0x388
kernel: MIDI Loopback device driver

# -----------------------------------

system, <ver_linux>:
 ---
Linux Lux3 2.4.20 #2 Sat Dec 7 09:50:48 GMT 2002 i586 unknown
 ---
C compiler             2.95.4
make                   3.79.1
binutils               20020814
util-linux             v2.11n
mount                  2.11n
modutils               2.4.15
e2fsprogs              1.27
ppp                    2.4.1
isdn4k-utils           3.1pre4
C library              2.2.5
dynamic linker (ldd)   2.2.5
procps                 2.0.7
net-tools              1.60
console-tools          0.2.3
sh-utils               2.0.11
modules                isdn_bsdcomp hisax isdn ipchains bridge romfs nls_utf8 
nls_koi8-u nls_koi8-ru nls_koi8-r nls_iso8859-7 nls_iso8859-5 nls_iso8859-4 
nls_iso8859-15 nls_iso8859-14 nls_iso8859-13 nls_iso8859-1 nls_gb2312 
nls_cp936 nls_cp866 nls_cp865 nls_cp864 nls_cp855 nls_cp852 nls_cp850 
nls_cp775 nls_cp437 nls_cp1251 nls_cp1250 nls_cp950 nls_big5 minix autofs acm 
usbcore v_midi opl3 sb sb_lib uart401 sound soundcore 8139too mii nbd

# -----------------------------------

statistics (after pnpdump config, only):

cat /dev/sndstat:
-----------------
	-/-

cat /proc/modules:
------------------
isdn_bsdcomp            5888   0
hisax                 131104  29 (autoclean)
isdn                  115200  30 (autoclean) [isdn_bsdcomp hisax]
ipchains               35876   0 (unused)
bridge                 15308   0 (unused)
romfs                   3584   0 (unused)
nls_utf8                 800   0 (unused)
    ...(more lang. mods)
nls_koi8-u              3872   1 (autoclean)
nls_iso8859-13          3392   0 (unused)
nls_iso8859-1           2880   2
minix                  18176   0 (unused)
autofs                  8932   0 (unused)
acm                     5024   0 (unused)
usbcore                53536   0 [acm]
v_midi                  4992   0 (unused)
opl3                   10792   0 (unused)
sb                      1792   0
sb_lib                 32288   0 [sb]
uart401                 6048   0 [sb_lib]
sound                  52588   0 [v_midi opl3 sb_lib uart401]
soundcore               3460   7 [sb_lib sound]
8139too                13376   1
mii                     2224   0 [8139too]
nbd                    14944   0 (unused)

cat /proc/interrupts:
---------------------
           CPU0       
  0:   44823924          XT-PIC  timer
  1:    1045591          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  4:    5026848          XT-PIC  HiSax
  7:        350          XT-PIC  soundblaster
  8:          3          XT-PIC  rtc
 10:          0          XT-PIC  eth0
 12:    3054844          XT-PIC  PS/2 Mouse
 14:     147687          XT-PIC  ide0
 15:    1403251          XT-PIC  ide1
NMI:          0 
LOC:          0 
ERR:          0
MIS:          0

cat /proc/ioports:
------------------
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0220-022f : soundblaster
0240-0240 : HiSax hscx A fifo
02f8-02ff : serial(set)
0330-0333 : MPU-401 UART
0376-0376 : ide1
0378-037a : parport0
0388-038b : Yamaha OPL3
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(set)
0640-065f : HiSax hscx A
0a40-0a40 : HiSax hscx B fifo
0cf8-0cff : PCI conf1
0e40-0e5f : HiSax hscx B
1240-1240 : HiSax isac fifo
1640-165f : HiSax isac
1a40-1a47 : avm cfg
5c20-5c3f : Acer Laboratories Inc. [ALi] M7101 PMU
d400-d40f : Acer Laboratories Inc. [ALi] M5229 IDE
  d400-d407 : ide0
  d408-d40f : ide1
d800-d8ff : Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
  d800-d8ff : 8139too

cat /proc/dma:
 1: SoundBlaster8
 4: cascade
 5: SoundBlaster16

^ permalink raw reply

* [parisc-linux] fic problem
From: FARINATI,LEANDRO (HP-Brazil,ex1) @ 2002-12-13 12:27 UTC (permalink / raw)
  To: Parisc-Linux List (E-mail)

Hi people,

	I have an error with the use of fic asm instruction(see piece code
below). 
            I'm ask you if you have a tip do help me to solve this problem.

       buf = (char *)malloc(4096);
        if(!buf)
        {
                printf("\n malloc error!");
                return(1);
        }


        /* copy instr stream(s) to new page */
        start = (unsigned int *)&(label of an asm code);
        spot = (unsigned int *)buf;
        end = (unsigned int *)&(label of an asm code);

        while(start <= end)
        {
                *spot = *start;
                __asm__ __volatile__("fdc (%0)" :: "r" (spot) );
                __asm__ __volatile__("sync" ::);
                __asm__ __volatile__("fic (%0)" :: "r" (spot) );
(segmentation fault in this line)
                __asm__ __volatile__("sync" ::);
                spot++;
                start++;
        }

Thanks in advance,

-----------------------------------------------------------------------
              Leandro Marcondes Farinati
                    Software Developer

*   leandro.farinati@hp.com

^ permalink raw reply

* Re: R: Kernel bug handling TCP_RTO_MAX?
From: Bogdan Costescu @ 2002-12-13 12:33 UTC (permalink / raw)
  To: Andrew McGregor
  Cc: David S. Miller, dlstevens, matti.aarnio, niv, alan,
	stefano.andreani.ap, linux-kernel, linux-net
In-Reply-To: <19000000.1039780134@localhost.localdomain>

On Sat, 14 Dec 2002, Andrew McGregor wrote:

> You're going to make lots of IETFer's really annoyed by suggesting that :-)

I hope not. That was the reason for allowing it to be tuned and for having 
a default value equal to the existing one.

> In a closed network, why not have SOCK_STREAM map to something faster than 
> TCP anyway?

Sure, just give me a protocol that:
- is reliable
- has low latency
- comes with the standard kernel
and I'll just use it. But you always get only 2 out ot 3...

-- 
Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De


^ permalink raw reply

* Re: bbram access problems
From: Geoffroy Stevenne @ 2002-12-13 11:50 UTC (permalink / raw)
  To: mtd-linux
In-Reply-To: <200212121540.43586.tglx@linutronix.de>

Le Thu, 12 Dec 2002 15:40:43 +0100
Thomas Gleixner <tglx@linutronix.de> a écrit:

 
> from slram.c
> NOTE:
>   With slram it's only possible to map a contigous memory region. 
> 
> So you can't access it with slram, as the BBSRAM is a device with
> paged access. All you have to do, is copy slram.c to bbram.c and add
> an additional parameter, which tells the driver the number of
> pages.available. Then modify the erase / read / write functions to do
> the page selection depending on the address you have to access. 
> If you think this is out of your league, then hope, that somebody does
> this for you sometimes, or ask one of the experts to help you for a
> little fee immidiately :)
> 

We should be able to do this.  Thanks for your suggestions and stay
tuned for more feedback!

Thanks,

Geof

^ permalink raw reply

* Re: massive compile failures w/ 2.5.51 on RH8.0
From: Dave Jones @ 2002-12-13 12:20 UTC (permalink / raw)
  To: Randy.Dunlap; +Cc: Rod Van Meter, linux-kernel
In-Reply-To: <Pine.LNX.4.33L2.0212122140500.21077-100000@dragon.pdx.osdl.net>

On Thu, Dec 12, 2002 at 09:42:39PM -0800, Randy.Dunlap wrote:

 > and some of these may have patches available for them on lkml.
 > I know that intermezzo does, from Peter Braam, with a small
 > follow-up by me, so it's fixable if you want it.  Surely (Rod ;).

>From reading bugzilla #11, it seems even with your additional
patch intermezzo still has problems..

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.