* BUG: 2.5.52-bk4
From: Lukas Hejtmanek @ 2002-12-19 21:47 UTC (permalink / raw)
To: linux-kernel
Hello,
If I try to open (to view) /proc/net/tcp in midnight commander then
the midnight commander freezes in kernel (cannot be killed) with 99% CPU usage.
I do not see any disk_io line in /proc/stat although I have /dev/hda as primary
disk. Maybe because I'm using boot_off first and ide=reverse. So real /dev/hda
does not exist and /dev/hde is as /dev/hda.
--
Lukáš Hejtmánek
^ permalink raw reply
* Re: RFC: 405LP sleep
From: Todd Poynor @ 2002-12-19 21:36 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: devel list
In-Reply-To: <1040330490.29647.340.camel@granite.austin.ibm.com>
+int alarm_secs;
+int cdiv;
+char mode[16] = "standby"; /* "clock-suspend", "power-down",
"standby" */
+int attempts; /* debugging */
Suggest more unique names for these globals.
+ jiffies += rtc_secs_elapsed * HZ;
If jiffies is jumped forward then can kernel events (such as those
waiting on a kernel timer) be missed? Whether or not timer queues et al
are processed on wakeup, not sure if it's harmful to update the "kernel
time" when the kernel has done nothing during the sleep interval, maybe
causing various timeouts. Has this been tried with applications like X
running and verified not to kill apps on wakeup?
Matt Locke and I have been discussing whether it's best to update wall
clock time but leave jiffies alone, since "kernel time" did not advance
during the sleep interval. It's a little worrisome: the kernel advances
time by 10ms for its own operations, but wallclock time (xtime and RTC)
jumps forward 10 minutes. We've tried this a little bit on a TI OMAP
and haven't seen anything die so far, but I imagine there'll be some
application that isn't happy about the situation no matter what choice
is made.
--
Todd
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Dedicated kernel bug database
From: John Bradford @ 2002-12-19 21:55 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.33L2.0212191330120.30841-100000@dragon.pdx.osdl.net>
> | > I'm not trying to discourage you - just raising a potential gotcha.
> |
> | Overall, though, would you rather be presented with a list of
> | categories, or a list of people and what parts of the code they
> | maintain. Personally, I think that a list of people is more
> | intuitive, rather than an abstract list of categories, but I could be
> | wrong.
>
> Do we have anyone targeted for interrupt routing problems (PIC, IO APIC,
> ACPI, etc.)?
No. I nominate Alan :-).
OK, I see your point, but no bug system will ever be perfect. Does
that mean there is no point in trying to make a better one? If
everybody really thinks it's a waste of time, I won't bother. It just
seemed to me that we need something less generic than Bugzilla. Maybe
I am wrong, I don't know.
John.
^ permalink raw reply
* Re: [PATCH]: for poor sools with old I2 & 64 bits kernel
From: Juan Quintela @ 2002-12-19 21:40 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: Ralf Baechle, mipslist
In-Reply-To: <20021219212817.GL449@rembrandt.csv.ica.uni-stuttgart.de>
>>>>> "thiemo" == Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
thiemo> Juan Quintela wrote:
>> >>>>> "thiemo" == Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
>>
thiemo> Juan Quintela wrote:
>> >>
>> >> Hi
>> >> this small patch made possible to compile a 64bit kernel for
>> >> people that have old proms that only accept ecoff. As usual
>> >> stolen from the 32 bits version.
>> >>
>> >> The easiest way is creating the file in arch/mips/boot,
>> >> otherwise we need to copy elf2ecoff.c to mips64.
>>
thiemo> Sorry, but I plainly doubt you have tested this.
>>
thiemo> I tried such a method today, and elf2ecoff failed to work on ELF64 files.
thiemo> Maybe a recent enough objcopy is the better choice for this purpose.
>>
>> I tested it and it works :)
thiemo> How is this possible, given that elf2ecoff uses Elf32_* variables to
thiemo> process the ELF file? elf2ecoff might be bad enough at error checking
thiemo> to produce some binary garbage.
>> Notice that I am using egcs for MIPS64 as I am not able to compile the
>> kernel with gcc-3.2 :(
thiemo> I don't think this is compiler dependent. :-)
from arch/mips64/Makefile:
#
# Some machines like the Indy need 32-bit ELF binaries for booting purposes.
# Other need ECOFF, so we build a 32-bit ELF binary for them which we then
# convert to ECOFF using elf2ecoff.
#
ifdef CONFIG_BOOT_ELF32
GCCFLAGS += -Wa,-32 $(shell if $(CC) -Wa,-mgp64 -c -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "-Wa,-mgp64"; fi)
LINKFLAGS += -T arch/mips64/ld.script.elf32
endif
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* [LARTC] kernel compiling problem!
From: AOUN RAZA @ 2002-12-19 21:34 UTC (permalink / raw)
To: lartc
Hi all,
I am installing freeswan version 1.97 on my linux box
with kernel version 2.4.2-2.
my question is ...
but while compiling the kernel with freeswan i got
some error which are..
***********
/usr/src/linux-2.4.2/include/asm/spinlock.h:8 parse
error before '1b7d4074'
/usr/src/linux-2.4.2/include/linux/module.h:173 parse
error before '62dada05'
/usr/src/linux-2.4.2/include/linux/module.h:174 parse
error before '7a9e045'
*******************************
first i thought these errors can be due to this reason
that these values should have 0x at start to tell the
parser that this hexadecimal value...
that is why i went to files read them but i didnot
found any string like mentioned in errors .
but i didn't found any thing in spinlock.h and
module.h
like '1b7d4074','62dada05' on line 8 and 173...
can any body help me why these errors are coming...
any suggesstions,
regards
==
Syed Aoun Raza.
Student MS(IT).
Ph: +49-179-1833720
Stuttgart, Germany.
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Randy.Dunlap @ 2002-12-19 21:32 UTC (permalink / raw)
To: John Bradford; +Cc: linux-kernel
In-Reply-To: <200212192140.gBJLexVt003143@darkstar.example.net>
On Thu, 19 Dec 2002, John Bradford wrote:
| > >Interesting - so the first stage in reporting a bug would be to select
| > >the latest 2.4 and 2.5 kernels that you've noticed it in, and get a
| > >list of known bugs fixed in those versions. Also, if you'd selected
| > >the maintainer, (from an automatically generated list from the
| > >MAINTAINERS file), it could just search *their* changes in the changelog.
| > >
| > It's often difficult to pick a maintainer for a bug - it may not be the
| > fault of a single subsystem.
|
| Yes, that's true.
or maybe it's just difficult to tell which subsystem has a problem...
| > As an example, I recently had a problem getting USB and network to
| > function (on kernels 2.5.5x).
| > I noticed that toggling Local APIC would also toggle which of the
| > two devices worked.
| > Disabling ACPI allows both deviecs to function regardless of local APIC.
| >
| > So, where is the problem?
| > 1) Network driver? It doesn't work with ACPI and both Local APIC and
| > IO-APIC.
| > 2) USB driver? It doesn't work with ACPI and no UP APIC.
| > 3) APIC? Causes weird problems with various drivers when ACPI is turned on.
| > 4) ACPI? Causes weird problems with various drivers when APIC is toggled.
|
| The way I imagine it working would be that you could assign it to
| multiple maintainers, (perhaps with a maximum to discourage the
| sending of all bugs to everybody, or alternatively, you could lower
| the priority of a bug sent to multiple people, on the basis that it
| was more likely to get solved anyway, so you are, in effect, balancing
| out the attention it gets).
|
| In the case you point out, as it's primarily networking and USB, the
| bug would get assigned to Andrew Morton, Jeff Garzik, and Greg
| Kroah-Hartman, who would all be relevant people to contact.
Hm, I see this problem as more of a generic interrupt routing or ACPI
problem, not networking or USB.
| > (this exact bug was in Bugzilla, though I hadn't checked there before
| > mailing lkml ;)
| >
| > I'm not exactly a neophyte to the kernel, and I would have to do a lot
| > more digging to find the right maintainer to send this to. Also, the
| > person(s) to whom the bug is reported will depend on how much debugging
| > work I do, and in what order I do it.
|
| Good point.
|
| > I'm not trying to discourage you - just raising a potential gotcha.
|
| Overall, though, would you rather be presented with a list of
| categories, or a list of people and what parts of the code they
| maintain. Personally, I think that a list of people is more
| intuitive, rather than an abstract list of categories, but I could be
| wrong.
Do we have anyone targeted for interrupt routing problems (PIC, IO APIC,
ACPI, etc.)?
--
~Randy
^ permalink raw reply
* PATCH 2.5.x disable BAR when sizing
From: Grant Grundler @ 2002-12-19 21:37 UTC (permalink / raw)
To: mj; +Cc: linux-kernel, turukawa
Martin,
In April 2002, turukawa@icc.melco.co.jp sent a 2.4.x patch to disable
BARs while the BARs were being sized. I've "forward ported" this patch
to 2.5.x (appended). turukawa's excellent problem description and
original posting are here:
https://lists.linuxia64.org/archives//linux-ia64/2002-April/003302.html
David Mosberger agrees this is an "obvious fix".
We've been using this in the ia64 2.4 code stream since about August.
thanks,
grant
Index: drivers/pci/probe.c
===================================================================
RCS file: /var/cvs/linux-2.5/drivers/pci/probe.c,v
retrieving revision 1.2
diff -u -p -r1.2 probe.c
--- drivers/pci/probe.c 9 Oct 2002 20:42:57 -0000 1.2
+++ drivers/pci/probe.c 17 Dec 2002 21:53:14 -0000
@@ -48,6 +48,12 @@ static void pci_read_bases(struct pci_de
unsigned int pos, reg, next;
u32 l, sz;
struct resource *res;
+ u16 cmd;
+
+ /* Disable I/O & memory decoding while we size the BARs. */
+ pci_read_config_word(dev, PCI_COMMAND, &cmd);
+ pci_write_config_word(dev, PCI_COMMAND,
+ cmd & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY));
for(pos=0; pos<howmany; pos = next) {
next = pos+1;
@@ -114,6 +120,8 @@ static void pci_read_bases(struct pci_de
}
res->name = dev->name;
}
+
+ pci_write_config_word(dev, PCI_COMMAND, cmd);
}
void __devinit pci_read_bridge_bases(struct pci_bus *child)
^ permalink raw reply
* Re: [PATCH]: for poor sools with old I2 & 64 bits kernel
From: Thiemo Seufer @ 2002-12-19 21:28 UTC (permalink / raw)
To: Juan Quintela; +Cc: Thiemo Seufer, Ralf Baechle, mipslist
In-Reply-To: <m2wum5hfy2.fsf@demo.mitica>
Juan Quintela wrote:
> >>>>> "thiemo" == Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
>
> thiemo> Juan Quintela wrote:
> >>
> >> Hi
> >> this small patch made possible to compile a 64bit kernel for
> >> people that have old proms that only accept ecoff. As usual
> >> stolen from the 32 bits version.
> >>
> >> The easiest way is creating the file in arch/mips/boot,
> >> otherwise we need to copy elf2ecoff.c to mips64.
>
> thiemo> Sorry, but I plainly doubt you have tested this.
>
> thiemo> I tried such a method today, and elf2ecoff failed to work on ELF64 files.
> thiemo> Maybe a recent enough objcopy is the better choice for this purpose.
>
> I tested it and it works :)
How is this possible, given that elf2ecoff uses Elf32_* variables to
process the ELF file? elf2ecoff might be bad enough at error checking
to produce some binary garbage.
> Notice that I am using egcs for MIPS64 as I am not able to compile the
> kernel with gcc-3.2 :(
I don't think this is compiler dependent. :-)
Thiemo
^ permalink raw reply
* Re: Dedicated kernel bug database
From: John Bradford @ 2002-12-19 21:40 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <3E023602.8080007@verizon.net>
> >Interesting - so the first stage in reporting a bug would be to select
> >the latest 2.4 and 2.5 kernels that you've noticed it in, and get a
> >list of known bugs fixed in those versions. Also, if you'd selected
> >the maintainer, (from an automatically generated list from the
> >MAINTAINERS file), it could just search *their* changes in the changelog.
> >
> It's often difficult to pick a maintainer for a bug - it may not be the
> fault of a single subsystem.
Yes, that's true.
> As an example, I recently had a problem getting USB and network to
> function (on kernels 2.5.5x).
> I noticed that toggling Local APIC would also toggle which of the
> two devices worked.
> Disabling ACPI allows both deviecs to function regardless of local APIC.
>
> So, where is the problem?
> 1) Network driver? It doesn't work with ACPI and both Local APIC and
> IO-APIC.
> 2) USB driver? It doesn't work with ACPI and no UP APIC.
> 3) APIC? Causes weird problems with various drivers when ACPI is turned on.
> 4) ACPI? Causes weird problems with various drivers when APIC is toggled.
The way I imagine it working would be that you could assign it to
multiple maintainers, (perhaps with a maximum to discourage the
sending of all bugs to everybody, or alternatively, you could lower
the priority of a bug sent to multiple people, on the basis that it
was more likely to get solved anyway, so you are, in effect, balancing
out the attention it gets).
In the case you point out, as it's primarily networking and USB, the
bug would get assigned to Andrew Morton, Jeff Garzik, and Greg
Kroah-Hartman, who would all be relevant people to contact.
> (this exact bug was in Bugzilla, though I hadn't checked there before
> mailing lkml ;)
>
> I'm not exactly a neophyte to the kernel, and I would have to do a lot
> more digging to find the right maintainer to send this to. Also, the
> person(s) to whom the bug is reported will depend on how much debugging
> work I do, and in what order I do it.
Good point.
> I'm not trying to discourage you - just raising a potential gotcha.
Overall, though, would you rather be presented with a list of
categories, or a list of people and what parts of the code they
maintain. Personally, I think that a list of people is more
intuitive, rather than an abstract list of categories, but I could be
wrong.
John.
^ permalink raw reply
* Re: [LARTC] Using HTB as an ISP "provisioning engine"
From: Stef Coene @ 2002-12-19 21:10 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104033114505084@msgid-missing>
On Thursday 19 December 2002 21:51, Brian Capouch wrote:
> I am new to shaping but not to routing; forgive me if this request is
> inappropriate for this list.
>
> I am a very small ISP and would like to use HTB to enforce contractual
> bandwidth limits on my customers. I am trying to think through one
> aspect of this that is vexing me. I'm sure it's no great secret that
> many ISPs oversell their bandwidth, and in our case we have a
> combination of accounts that total approximately 2.2Mbs on our feed,
> which is 1.2Mbs. (Concentrating right now on our download stream)
>
> How could something like this be accomodated? The documentation says
> that the total bandwidth allocations of a set of subclasses should total
> that assigned to the class.
>
> But my understanding is that if I bump up the bandwidth on the primary
> class to a value greater than my actual bandwidth, then I'm going to be
> filling up queues at the upstream ISP and negatively affecting my
> performance.
>
> I'm sure there is something I'm missing, but I've discussed this with a
> couple of fellow network engineers and neither was able to posit how
> such thing might work, although they both said they were sure that it is
> a common scenario.
You can create a root class with rate = ceil = 1.2 Mbps. Create a class for
each customer with ceil = selled bandwidth and the sum of the rates=1.2Mbps.
Example :
You selled 1.1 Mbps to customer1 and 0.37 (=2.2Mbps/6) to 3 other customers.
So you have a total bandwidth of 2.2Mbps. But you have only 1.2 Mbps
available.
class rate = ceil = 1.2 Mbps
class1 rate = 0.6, ceil = 1.1Mbps
class2 rate = 0.2, ceil = 0.37Mbps
class3 rate = 0.2, ceil = 0.37Mbps
class4 rate = 0.2, ceil = 0.37Mbps
The bandwidth you selled to the customers is the ceil. They never can use
more then the ceil. If one customer is using no bandwidth, the remaining
bandwidth is given to the other customers.
If all customers are using all bandwidth, each customer is "punished" in the
same way.
You can also give the customers a possibility to use as much bandwidth as
available. To do so, give each class ceil = 1.2Mbps, but that bandwidth is
not guaranteed. In this case, the rate is the minimum bandwidth they can
get. So for a SLA, you can say to the customer : "You have a minimum
bandwidth of 0.6Mbps and a maximum bandwidth of 1.2Mbps."
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: What do you think, is compatible locking solvable at all?
From: Bart Oldeman @ 2002-12-19 21:07 UTC (permalink / raw)
To: Michal Samek; +Cc: Linux-MSDOS Mailing list
In-Reply-To: <1040286600.1529.49.camel@localhost.localdomain>
On 19 Dec 2002, Michal Samek wrote:
> dosemu developers, what do you think, is my problem (I mean totally
> compatible locking of files/records between samba/win sessions and
> samba/smbfs/dosemu sessions) solvable at all? Maybe there are some
> desing issues which make it really impossible to hack? Thanks for your
> opinions.
maybe it's better to ask the Samba and smbfs developers - DOSEMU
basically acts like just another Linux app and I know almost nothing
(only basic things) about Samba.
Bart
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Eli Carter @ 2002-12-19 21:14 UTC (permalink / raw)
To: John Bradford; +Cc: dank, linux-kernel
In-Reply-To: <200212192059.gBJKxFne002827@darkstar.example.net>
John Bradford wrote:
>>And what about GNATS? What about the others on
>>http://www.a-a-p.org/tools_tracking.html ? A number of those address
>>the web-based concern. Do any of them answer your other concerns? If
>>there are, where do those fail that bugzilla, GNATS, etc. get it right?
>
>
> Why are you so against somebody sitting down and thinking, "OK, we
> need a bug tracking database designed for debugging the Linux
> kernel."? I don't understand why you think it's a bad idea to start
> over. If my code was rubbish, then it wouldn't get used, and I wasted
> my time. Nobody else suffers.
I'm not against someone starting over. I'm against someone starting
over without considering the existing base of code. If for no other
reason than to see what worked for others and what didn't. A solid
comparison of bugzilla, GNATS, and maybe a couple others with pros and
cons for each can be extremely enlightening.... even if you decide none
of them have a good, solid design.
My questions were an attempt to get at that comparison so that there was
evidence that you knew the pitfalls of more than just bugzilla. And I
hoped that you might find another one that got some of those things right.
>>But I see that starting from scratch is just the way you work:
>>http://grabjohn.com/question.php?q=6
>
> Well, since it's me that's offering to write the code, don't I get to
> decide how to write it?
Absolutely! I'm just trying to get you to step back from 'rewrite it!'
as an initial assumption, and look at what already exists. Maybe every
wheel invented so far has 3 to 8 sides and we need to consider something
other than a polygon. Or maybe there is an oval out there that hints at
a better way. I'm just wanting to see that you have looked at more than
the square wheel.
> Besides, I'm not the only person who thinks it's a good idea to start
> over sometimes - Eric Raymond even addresses this point in The
> Cathedreal and the Bazaar.
>
> http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html
>
Yes, but I didn't see much of an explanation of _why_ nothing out there
was a good starting point. Nor did I see an indication that you had
gone and looked at more than just bugzilla.
>>Well, have fun, good luck, and I do hope you come up with something
>>useful and maintainable.
>
>
> If not, I will admit you were right to the list :-).
*chuckle* I think you are _premature_ in saying "rewrite!", not _wrong_
in saying "rewrite!" And I will by no means tell you to sit and twiddle
your thumbs instead of writing something, even if I think that something
already exists in perfect form. (Which in this case, I don't. :) )
Have fun!
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ permalink raw reply
* Re: [PATCH]: for poor sools with old I2 & 64 bits kernel
From: Juan Quintela @ 2002-12-19 21:11 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: Ralf Baechle, mipslist
In-Reply-To: <20021219210103.GJ449@rembrandt.csv.ica.uni-stuttgart.de>
>>>>> "thiemo" == Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
thiemo> Juan Quintela wrote:
>>
>> Hi
>> this small patch made possible to compile a 64bit kernel for
>> people that have old proms that only accept ecoff. As usual
>> stolen from the 32 bits version.
>>
>> The easiest way is creating the file in arch/mips/boot,
>> otherwise we need to copy elf2ecoff.c to mips64.
thiemo> Sorry, but I plainly doubt you have tested this.
thiemo> I tried such a method today, and elf2ecoff failed to work on ELF64 files.
thiemo> Maybe a recent enough objcopy is the better choice for this purpose.
I tested it and it works :)
Notice that I am using egcs for MIPS64 as I am not able to compile the
kernel with gcc-3.2 :(
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: [PATCH]:
From: Juan Quintela @ 2002-12-19 21:09 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Ralf Baechle, mipslist
In-Reply-To: <Pine.GSO.3.96.1021219215031.27339S-100000@delta.ds2.pg.gda.pl>
>>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:
maciej> On 19 Dec 2002, Juan Quintela wrote:
>> - pte_val() returs a long, print it directly.
maciej> [...]
>> - printk("Memory Mapping: VA = %08x, PA = %08x ", addr, (unsigned int) pte_val(page));
>> + printk("Memory Mapping: VA = %08x, PA = %08x ", addr, pte_val(page));
maciej> Well, I guess you need "%08lx" then. For both formats, actually.
Arghhhhhhhh, wrong patch,
Ralf, don't apply, appy this other:
Sorry for the inconvenience, just diff the wrong tree :(
Later, Juan.
Index: arch/mips64/mm/tlb-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/mm/tlb-r4k.c,v
retrieving revision 1.1.2.5
diff -u -r1.1.2.5 tlb-r4k.c
--- arch/mips64/mm/tlb-r4k.c 2 Dec 2002 00:24:53 -0000 1.1.2.5
+++ arch/mips64/mm/tlb-r4k.c 19 Dec 2002 21:03:09 -0000
@@ -244,7 +244,7 @@
pmd = pmd_offset(pgd, addr);
pte = pte_offset(pmd, addr);
page = *pte;
- printk("Memory Mapping: VA = %08x, PA = %08x ", addr, (unsigned int) pte_val(page));
+ printk("Memory Mapping: VA = %08lx, PA = %08lx ", addr, pte_val(page));
val = pte_val(page);
if (val & _PAGE_PRESENT) printk("present ");
if (val & _PAGE_READ) printk("read ");
@@ -259,7 +259,7 @@
void show_tlb(void)
{
- unsigned int flags;
+ unsigned long flags;
unsigned int old_ctx;
unsigned int entry;
unsigned int entrylo0, entrylo1, entryhi;
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: Printer error (correction)
From: Bill Pleasants @ 2002-12-19 21:03 UTC (permalink / raw)
To: Ray Olszewski; +Cc: linux-newbie
In-Reply-To: <5.1.0.14.1.20021217220641.0210c590@celine>
Hello,
When I started the computer today, the Internet Device Control worked so I copied last night's message below to put it in the thread. Also I checked the printer manual and see that the flashing light that I said indicated "toner out" indicates a malfunction designated "Service C" if not cleared by cycling power which it was.
My 12/18 mesage:
Ray Olszewski wrote:
>> You did not provide some of the information I asked for (namely, the
>> contents of /etc/resolv.conf), but from what you did provide, the
>> likely source of the lprm problem is an inconsistency between your lpr
>> setup and /etc/hosts . As you report below, your /etc/hosts file only
>> identifies the machine as localhost.localdomain and not also as just
>> localhost. Consequently, the resolver cannot associate localhost with
>> your machine, as is illustrated by the ping failure you also report.
>
>
I failed to mention there is no resolv.conf file.
>>
>> Probably you can fix the lprm problem by editing the entry (yeah, I
>> know it says "Do not remove", but this is editing, not removing) so it
>> reads:
>>
>> 127.0.0.1 localhost.localdomain localhost
>>
>> Do that and see if lprm now works. If not, tell us what the problem
>> now loks like.
>
>
"[bill@localhost bill]$ lprm
Printer 'Print@localhost' - cannot open connection - No such file or
directory
Make sure the remote host supports the LPD protocol
and accepts connections from this host and from non-privileged
(>1023) ports"
>>
>> As to the underlying problem ... by "Additional attempts to print", do
>> you mean trying to print different files? Preferably something nice
>> and easy, like a short text file (/etc/hosts itself will do for a
>> test)? Does "lpq" show anything significant? If you power-cycle the
>> printer, does it now start to print? DId the printer successfully
>> print other files prior to failing with the final page of the MapQuest
>> one?
>
>
After the change in the hosts file, I tried printing the hosts file from
gedit, another file from Open Office and your email from Mozilla. (I
did not reboot.)
"[bill@localhost bill]$ lpq
Printer 'Print@localhost' - cannot open connection - No such file or
directory
Make sure the remote host supports the LPD protocol
and accepts connections from this host and from non-privileged
(>1023) ports"
Power cycling the printer did not print. There is no error light
showing. I don't remember if more than 2 pages printed. It was a while
ago. While I was logged on as root, I also changed the boot run level
from 3 to 5.
And then .. the Network Device Control failed to function so I rebooted.
And then .... the printer started and printed the 2 MapQuest pages (from
10/15 I see) and stopped with the "toner out" light flashing. I pulled
the parallel plug, cycled the power, got the "ready" light, plugged the
parallel back and got the error light again. clicking to print this
message did not change the printer.
And then ...... The NDC failed again so I changed the hosts file back,
rebooted and still no go. So I copied this message to a floppy to take
to my MS computer to send. So that's what the problem looks like.
>>
>> At 10:44 PM 12/17/02 -0500, Bill Pleasants wrote:
>> [...]
>>
>
>
>>>>>> More immediately, how does your system do name-to-address
>>>>>> resolution? Does it rely on /etc/hosts? If so, what are the contents
>>>>>> of that file? Or does it use a nameserver? If so, is it accessable?
>>>>>> And what are the contents of the /etc/resolv.conf file?
>>>
>>>
>>>>
>>>>
>>>> I have some notion of what name-to-address resolution is for the
>>>> internet but not what it is for the Linux OS. /etc/hosts contains:
>>>> "# Do not remove the following line, or various programs
>>>> # that require network functionality will fail.
>>>> 127.0.0.1 localhost.localdomain
>>>>
>>
>>
>>>>>>
>>>>>> Does the message really say "local host" rather than "localhost"?
>>>>>> What result do you get if (from the command line) you try "ping
>>>>>> localhost"?
>>>
>>>
>>>>
>>>>
>>>> This is cut and paste:
>>>> "[bill@localhost bill]$ lprm
>>>> Get_local_host: 'localhost' IP address not available!"
>>>>
>>>> "[bill@localhost bill]$ ping localhost
>>>> ping: unknown host localhost"
>>
>>
>>
>> [...]
>>
>
>
>>>>>> Finally, as to your immediate problem ... if the third page of a
>>>>>> epecific document continues to fail to print, while other docs print
>>>>>> fine (do they? you haven't said), i'd suspect something odd about
>>>>>> the specific document. Generically, you need to investigate how
>>>>>> general the printing problem is before we can tackle it systematically.
>>>
>>>
>>>>
>>>>
>>>> I did not retain the file I first tried to print. Additional
>>>> attempts to print have produced no response from the printer. Thank
>>>> you for your offer to help.
>>
>>
>>
>> [...]
>> --
>> -------------------------------------------"Never tell me the
>> odds!"--------
>> Ray Olszewski -- Han Solo
>> Palo Alto, California, USA ray@comarre.com
>>
>
>
-------------------------------------------------------------------------------
>>
>>
>> -
>> 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
>>
>
>
-
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
-
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: Dedicated kernel bug database
From: Stephen Wille Padnos @ 2002-12-19 21:11 UTC (permalink / raw)
To: John Bradford; +Cc: Bill Davidsen, linux-kernel
In-Reply-To: <200212192032.gBJKWSpe002662@darkstar.example.net>
John Bradford wrote:
> [snip]
>
>Interesting - so the first stage in reporting a bug would be to select
>the latest 2.4 and 2.5 kernels that you've noticed it in, and get a
>list of known bugs fixed in those versions. Also, if you'd selected
>the maintainer, (from an automatically generated list from the
>MAINTAINERS file), it could just search *their* changes in the changelog.
>
It's often difficult to pick a maintainer for a bug - it may not be the
fault of a single subsystem. As an example, I recently had a problem
getting USB and network to function (on kernels 2.5.5x). I noticed that
toggling Local APIC would also toggle which of the two devices worked.
Disabling ACPI allows both deviecs to function regardless of local APIC.
So, where is the problem?
1) Network driver? It doesn't work with ACPI and both Local APIC and
IO-APIC.
2) USB driver? It doesn't work with ACPI and no UP APIC.
3) APIC? Causes weird problems with various drivers when ACPI is turned on.
4) ACPI? Causes weird problems with various drivers when APIC is toggled.
(this exact bug was in Bugzilla, though I hadn't checked there before
mailing lkml ;)
I'm not exactly a neophyte to the kernel, and I would have to do a lot
more digging to find the right maintainer to send this to. Also, the
person(s) to whom the bug is reported will depend on how much debugging
work I do, and in what order I do it.
I'm not trying to discourage you - just raising a potential gotcha.
- Steve
^ permalink raw reply
* Re: [PATCH]: for poor sools with old I2 & 64 bits kernel
From: Thiemo Seufer @ 2002-12-19 21:01 UTC (permalink / raw)
To: Juan Quintela; +Cc: Ralf Baechle, mipslist
In-Reply-To: <m2el8dixmr.fsf@demo.mitica>
Juan Quintela wrote:
>
> Hi
> this small patch made possible to compile a 64bit kernel for
> people that have old proms that only accept ecoff. As usual
> stolen from the 32 bits version.
>
> The easiest way is creating the file in arch/mips/boot,
> otherwise we need to copy elf2ecoff.c to mips64.
Sorry, but I plainly doubt you have tested this.
I tried such a method today, and elf2ecoff failed to work on ELF64 files.
Maybe a recent enough objcopy is the better choice for this purpose.
Thiemo
^ permalink raw reply
* Re: RFC: bus_type and device_class merge (or partial merge)
From: Patrick Mochel @ 2002-12-19 20:37 UTC (permalink / raw)
To: Adam J. Richter; +Cc: linux-kernel
In-Reply-To: <200212191936.LAA06204@adam.yggdrasil.com>
> If there is a more specific mailing list than lkml for discussing
> the generic driver model, please feel free to redirect me.
No, the kernel list is right. I'm a lazy bastard that travels a lot, so
response latency is often higher than it should be.
> I'm thinking about trying to embed struct device_class into
> struct bus_type or perhaps just eliminate the separate struct
> bus_type. The two structures are almost identical, especially
> considering that device_class.devnum appears not to be used by
> anything.
Someone else tried to do this a while back, and my argument was the same
as this is going to be: they are very distinct objects that describe
different things.
It is true that classes are not used much in the current kernel. The last
six months have not afforded enough time to convert as much code to use
them as I would have preferred. As a result, the class and interface code
is the least mature (and the least personally liked) of the driver model
code.
If you're interested, I've finished a paper for linux.conf.au on the
driver model that should describe the various objects and purposes (much
better than the Ottawa paper did). You can find it at:
http://kernel.org/pub/linux/kernel/people/mochel/doc/lca/driver-model-lca2003.tar.gz
Hopefully, you will find it useful. Feel free to send me comments on it,
as it may just be completely crappy.
> At first appearance, a bus_type (PCI, USB, etc.) and a
> device_class (network devices, input, block devices), may seem like
> opposite ends of the device driver abstraction, but really I think
> these are basically the same, and, more importantly, there can be many
> layers of these interfaces, and the decision about which are bus_types
> and which are device_classes is causing unnecessary coplexity. For
> example, SCSI defines both. SCSI can be a hardware bus, bus it also
> needs device_class so that scsi_debug (and eventually scsi generic) can
> use the struct interface mechanism.
They're not the same, though. They may be similar, but they are
fundamentally different.
A bus describes a physical transport. It defines semantics for
communicating with resident devices, independent of the functionality they
ultimately serve.
A class is the flipside. It describes the function a device is designed
to perform, independent of its underlying transport.
The interfaces that communicate with devices of a particular class are the
canonical entities that give devices meaning to users and userspace
programs.
Consider audio devices. The only things I care about are /dev/mixer and
/dev/dsp, which map to devices registered with the audio subsystem.
Actually, what is registered are not devices. They are objects allocated
by the driver for my sound card that describe the device in the context of
the audio subsystem. This object is independent of the bus the device
resides on. Communication from userspace to the device passes through the
driver, which formats the class requests to bus and device-specific ones
to actaully talk to the physical device. Something like this:
Me -> device node -> kernel intf -> audio subsys -> driver -> bus -> device
Some buses allow communication to devices on their bus type, regardless of
the devices' function. SCSI does this, as you mention, and so does PCI and
USB, via /proc/bus/*. Functionality is limited to what can generically be
done, and what the bus type allows you to do. They are not classes,
though. The interfaces they correspond to are specific to the underlying
transport.
SCSI is wrong about creating a device class. They are overloading
constructs for their own, twisted purposes. It's partly my fault, as I
know they could use a mechanism for registering and exporting interfaces
to bus-specific devices. It hasn't happened mainly because of time
constraints.
> Also, merging device_class and bus_type could also enable a
> little more consolidation between struct device_interface and struct
> device_driver (as with device_class.devnum, device_interface.devnum
> does not appear to be used currently).
>
> Anyhow, I think this could shrink the drivers/base a bit and
> make it slightly more understandable. I'd be interested in knowing if
> anyone else is contemplating or developing this or wants to point out
> issues to watch out for.
Consolidation is possible, but I would not recommend doing it by merging
the structures. Look for other ways to create common objects that the two
can share. The distinction between the object types is important,
conceptually, if nothing else. Especially during the continuing evolution
of the model. At least for now, and for probably a very long time, I will
not consider patches to consolidate the two object types.
-pat
^ permalink raw reply
* RE: Dedicated kernel bug database
From: Heater, Daniel (IndSys, GEFanuc, VMIC) @ 2002-12-19 21:04 UTC (permalink / raw)
To: 'John Bradford', eli.carter; +Cc: linux-kernel
>
> > > In any case, people could take the kernel bug database, and
> > > genericify it, much more easily than somebody could
> tailor an existing
> > > bug tracking application to the needs of the kernel, (which is
> > > demonstrated by the fact that the developers are not
> getting Bugzilla
> > > reports).
> >
> > Perhaps, but I'm not convinced that it would be easier to
> write a kernel
> > bug database from scratch than it would be to improve an existing
> > project to address the kernel's needs. And _that_ is what we were
> > discussing.
>
> Ah, well no wonder we're not agreeing :-), I actually saw the
> re-writing from scratch as being easier :-).
>
> Maybe I am just in the minority in that I don't find Bugzilla
> intuitive.
I'm in that minority with you then...
However, there may be an existing system that's *closer* to the needs of the
kernel than bugzilla.
I was looking at this the other day for my companies purposes. These two
looked
promising to me, but I have not gotten around to trying them.
http://www.bestpractical.com/rt//
http://myrapid.com/webcall/
^ permalink raw reply
* Re: [PATCH]:
From: Maciej W. Rozycki @ 2002-12-19 20:54 UTC (permalink / raw)
To: Juan Quintela; +Cc: Ralf Baechle, mipslist
In-Reply-To: <m2smwtixsh.fsf@demo.mitica>
On 19 Dec 2002, Juan Quintela wrote:
> - pte_val() returs a long, print it directly.
[...]
> - printk("Memory Mapping: VA = %08x, PA = %08x ", addr, (unsigned int) pte_val(page));
> + printk("Memory Mapping: VA = %08x, PA = %08x ", addr, pte_val(page));
Well, I guess you need "%08lx" then. For both formats, actually.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* [LARTC] Using HTB as an ISP "provisioning engine"
From: Brian Capouch @ 2002-12-19 20:51 UTC (permalink / raw)
To: lartc
I am new to shaping but not to routing; forgive me if this request is
inappropriate for this list.
I am a very small ISP and would like to use HTB to enforce contractual
bandwidth limits on my customers. I am trying to think through one
aspect of this that is vexing me. I'm sure it's no great secret that
many ISPs oversell their bandwidth, and in our case we have a
combination of accounts that total approximately 2.2Mbs on our feed,
which is 1.2Mbs. (Concentrating right now on our download stream)
How could something like this be accomodated? The documentation says
that the total bandwidth allocations of a set of subclasses should total
that assigned to the class.
But my understanding is that if I bump up the bandwidth on the primary
class to a value greater than my actual bandwidth, then I'm going to be
filling up queues at the upstream ISP and negatively affecting my
performance.
I'm sure there is something I'm missing, but I've discussed this with a
couple of fellow network engineers and neither was able to posit how
such thing might work, although they both said they were sure that it is
a common scenario.
Thanks.
B.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Are working modules going to be in 2.6?
From: Bill Davidsen @ 2002-12-19 20:58 UTC (permalink / raw)
To: Linux-Kernel Mailing List
I have downloaded any number of modutil this and init-mod that, built them
static, rolled my own initrd files, and as far as I can tell it just
doesn't work with 2.5.48+.
I build my own 2.4 and early 2.5 setups, they boot, right up to the point
where the "improved" module setup comes in. Since then I have to build the
drivers in to get a boot. That's acceptable for a single test machine,
it's not desirable to build a kernel for every config I support instead of
just building a new initrd file for a new config.
Is there any plan to get this working, or if a magician can make it work
perhaps publishing the spell?
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* [PATCH] 2.5.52: compilation fixes for alpha
From: Hannes Reinecke @ 2002-12-19 22:01 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
Hi all,
attached are some compilation fixes needed to get the alpha port up and
running. Note: These fixes are on top of patch-2.5.52-bk3 in the
2.5/testing directory, which contain some neccessary fixes regarding
exception handling.
Note that this is gross hackery. I'm reasonably sure that the patch to
vmlinux.lds is correct (+/- alignment); the modules stuff is just copied
straight from Rusty Russels patch (THX !).
Anyway: It works for me (tm), which is more than I could have said from
the previous 51 kernels of the 2.5 series.
I would be _very_ glad if someone in the know (rth ? davem ? Ivan K.?)
could have a look at it, make the appropriate corrections and forward it
in the appropriate channels, just to make sure the next kernels will
actually _run_ on an alpha.
Cheers,
Hannes
P.S.: Please CC to me directly, I'm not on this list.
[-- Attachment #2: bk3-alpha.patch --]
[-- Type: text/plain, Size: 5336 bytes --]
--- arch/alpha/kernel/Makefile.orig Thu Dec 19 17:44:23 2002
+++ arch/alpha/kernel/Makefile Thu Dec 19 17:44:30 2002
@@ -26,6 +26,7 @@
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_PCI) += pci.o pci_iommu.o
obj-$(CONFIG_SRM_ENV) += srm_env.o
+obj-$(CONFIG_MODULES) += module.o
ifdef CONFIG_ALPHA_GENERIC
--- arch/alpha/vmlinux.lds.S.orig Thu Dec 19 17:55:58 2002
+++ arch/alpha/vmlinux.lds.S Thu Dec 19 17:57:35 2002
@@ -55,6 +55,12 @@
__setup_end = .;
}
+ __param ALIGN(16): {
+ __start___param = .;
+ *(__param);
+ __stop___param = .;
+ }
+
.initcall.init ALIGN(8): {
__initcall_start = .;
*(.initcall1.init)
--- include/asm-alpha/module.h.orig Thu Dec 19 13:26:01 2002
+++ include/asm-alpha/module.h Thu Dec 19 13:34:11 2002
@@ -1,6 +1,11 @@
#ifndef _ASM_ALPHA_MODULE_H
#define _ASM_ALPHA_MODULE_H
-/* Module rewrite still in progress. */
+struct mod_arch_specific
+{
+};
+#define Elf_Shdr Elf64_Shdr
+#define Elf_Sym Elf64_Sym
+#define Elf_Ehdr Elf64_Ehdr
#endif /* _ASM_ALPHA_MODULE_H */
--- /dev/null Tue Oct 22 14:39:45 2002
+++ arch/alpha/kernel/module.c Thu Dec 19 17:48:41 2002
@@ -0,0 +1,135 @@
+/* Kernel module help for Alpha.
+ Copyright (C) 2002 Richard Henderson.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License along
+ with this program; if not, write to the Free Software Foundation, Inc.,
+ 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */
+
+#include <linux/moduleloader.h>
+#include <linux/elf.h>
+#include <linux/vmalloc.h>
+#include <linux/fs.h>
+#include <linux/string.h>
+#include <linux/kernel.h>
+
+#if 0
+#define DEBUGP printk
+#else
+#define DEBUGP(fmt , ...)
+#endif
+
+void *module_alloc(unsigned long size)
+{
+ if (size == 0)
+ return NULL;
+ return vmalloc(size);
+}
+
+/* Free memory returned from module_alloc */
+void module_free(struct module *mod, void *module_region)
+{
+ vfree(module_region);
+ /* FIXME: If module_region == mod->init_region, trim exception
+ table entries. */
+}
+
+/* We don't need anything special. */
+long module_core_size(const Elf64_Ehdr *hdr,
+ const Elf64_Shdr *sechdrs,
+ const char *secstrings,
+ struct module *module)
+{
+ return module->core_size;
+}
+
+long module_init_size(const Elf64_Ehdr *hdr,
+ const Elf64_Shdr *sechdrs,
+ const char *secstrings,
+ struct module *module)
+{
+ return module->init_size;
+}
+
+int apply_relocate(Elf64_Shdr *sechdrs,
+ const char *strtab,
+ unsigned int symindex,
+ unsigned int relsec,
+ struct module *me)
+{
+ return -ENOEXEC;
+}
+
+int apply_relocate_add(Elf64_Shdr *sechdrs,
+ const char *strtab,
+ unsigned int symindex,
+ unsigned int relsec,
+ struct module *me)
+{
+ Elf64_Rela *rela = (void *)sechdrs[relsec].sh_offset;
+ Elf64_Sym *sym;
+ char *location;
+ unsigned long i;
+
+ for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rela); i++) {
+ unsigned long r_type = ELF64_R_TYPE(rela[i].r_info);
+ unsigned long value = 0;
+
+ /* This is where to make the change */
+ location = (void *)sechdrs[sechdrs[relsec].sh_info].sh_offset
+ + rela[i].r_offset;
+
+ if (r_type == R_ALPHA_RELATIVE) {
+ /* Binutils before 2.12 or so are borken. We should
+ have the RELATIVE offset as the addend of the
+ relocation. If it's not present, fall back to the
+ value at the relocation address. */
+ u64 addend = rela[i].r_addend;
+ if (addend == 0)
+ addend = *(u64 *)location;
+
+ *(u64 *)location = (u64)me->module_core + addend;
+ continue;
+ }
+
+ /* This is the symbol it is referring to. */
+ sym = (Elf64_Sym *)sechdrs[symindex].sh_offset
+ + ELF64_R_SYM(rela[i].r_info);
+ if (!sym->st_value) {
+ printk(KERN_WARNING "%s: Unknown symbol %s\n",
+ me->name, strtab + sym->st_name);
+ return -ENOENT;
+ }
+ value += rela[i].r_addend;
+
+ switch (r_type) {
+ case R_ALPHA_GLOB_DAT:
+ case R_ALPHA_JMP_SLOT:
+ case R_ALPHA_REFQUAD:
+ *(u64 *)location = value;
+ break;
+ default:
+ printk(KERN_ERR "module %s: Unknown relocation: %lu\n",
+ me->name, r_type);
+ return -ENOEXEC;
+ }
+ }
+
+ return 0;
+}
+
+int module_finalize(const Elf_Ehdr *hdr,
+ const Elf_Shdr *sechdrs,
+ struct module *me)
+{
+ return 0;
+}
^ permalink raw reply
* RFC: 405LP sleep
From: Hollis Blanchard @ 2002-12-19 20:41 UTC (permalink / raw)
To: devel list
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
I think the patch is too large. You can find it at
http://penguinppc.org/~hollis/405LP-sleep.diff
I've attached the Documentation file here.
-Hollis
-----Forwarded Message-----
From: Hollis Blanchard <hollis@austin.ibm.com>
To: devel list <linuxppc-dev@lists.linuxppc.org>
Subject: RFC: 405LP sleep
Date: 19 Dec 2002 14:08:43 -0600
This patch implements sleep on the IBM 405LP (described in the
Documentation file at the top of the patch).
It's not quite ready to check in, but I'd like it to be very soon. I'm
still looking for the solution to my get_pteptr question btw...
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
[-- Attachment #2: 405LP-sleep.txt --]
[-- Type: text/plain, Size: 6141 bytes --]
Hollis Blanchard, IBM Linux Technology Center
19 Dec 2002
draft
Linux Sleep on the PowerPC 405LP
--------------------------------
The IBM 405LP embedded CPU has three different sleep modes, assisted by a unit
called "APM0". APM has four wakeup interrupt lines which it cascades onto the
UIC as irq 24. When the 405LP enters a sleep mode, the only thing that can
wake it is those four wakeup lines. One wakeup line is connected to the RTC
interrupt line, allowing wakeup when an RTC alarm goes off. The other three
are board-dependent; on Beech one is connected to a physical button.
Sleep Modes
-----------
1. In "clock-suspend" mode the output of the PLL is stopped. No units are
powered down, and so no state is lost. On wakeup, the PLL continues and
processing resumes exactly where it left off.
2. In "power-down" mode, APM signals the power supply to drop power to the CPU
and integrated peripherals. All important state, including GPRs, SPRs, and
DCRs must be saved by software before entering this sleep mode, and restored
after wakeup. SDRAM is not powered off, so state can be saved there as long as
SDRAM is put in self-refresh mode prior to the sleep.
When a wakeup occurs, the chip (CPU and integrated peripherals) is reset,
returning control to the firmware. The firmware must determine that this is a
wakeup (rather than a normal power-on) by polling the APM0_CFG and APM0_SR
registers.
3. In "standby" mode, APM first freezes the PLL. It then transfers all chip
state (excluding core registers and arrays such as the TLB) over the
i2c bus to a nonvolatile storage device (such as an EEPROM). Once that process
is complete, APM signals the power supply to drop power to the CPU
and integrated peripherals.
When a wakeup occurs, the chip (CPU and integrated peripherals) is reset but
held frozen. APM transfers the saved chip state back over the i2c bus. It then
releases the PLL and processing continues from the reset vector, returning
control to the firmware. The firmware must determine that this is a wakeup
(rather than a normal power-on) by polling the APM0_CFG and APM0_SR registers.
Interaction with Linux
----------------------
Note: that because the chip is reset on wakeup in both power-down and standby
modes, the firmware *must* be made APM-aware. Otherwise, a wakeup will simply
reset the chip, losing all state. clock-suspend mode does not require firmware
interaction.
On wake, the firmware must know how to transfer control back to Linux (which
is still resident in RAM). The following structure is used:
struct wakeup_info {
void (*wakeup_func_phys)(u32 apm0_cfg, u32 apm0_sr); /* physical addr */
u32 magic;
...
}
Firmware is aware only of the first two fields. Linux creates and populates
this structure in memory, and writes the pointer to a well-known location
(currently 0xfc physical) for the firmware to read. (Unfortunately there are
no "scratch" registers provided by the APM unit, requiring used of a
predetermined absolute physical address.) The magic number is intended to be a
simple validator ensuring that the contents of SDRAM have not been corrupted.
Currently Linux also saves one other value in the wakeup_info structure: the
(physical) stack pointer.
Linux Sleep Procedure
---------------------
This is a high-level summary; the code is well-documented.
For power-down and standby modes:
One page is allocated in which to save some CPU registers and the DCRs
currently supported by power-down mode (UART and LCD). EBC registers are
always saved even though standby mode will save/restore them, because
firmware may overwrite those registers before returning control to Linux
on wake.
The non-volatile GPRs, all 64 TLB entries, and quite a few SPRs like LR,
MSR, and EVPR are saved to the stack in an assembly routine. The registers
saved here are those that must be restored before returning into C code on
wakeup; i.e. they cannot be saved and restored in C.
The remaining code is touched into the I-cache so that SDRAM can be put into
self-refresh. The sleep command is written to the APM unit, and then the
processor spins in a bdnz loop until either:
1. the APM unit freezes the processor
2. the CTR register decrements to zero, indicating sleep did not take place
Linux Wakeup Procedure
---------------------
The firmware jumps to the address specified by wakeup_info->wakeup_func_phys .
The processor is still in untranslated mode (MSR:IR/DR = 0). The stack pointer
is immediately restored from wakeup_info->wakeup_sp_phys so that SPRs can be
loaded and restored from the stack. Finally, the non-volatile GPRs are
restored, and control returns via an rfi to the C function executed before
sleep, returning to translated mode (MSR:IR/DR = 1). The C function continues
to restore non-essential registers which were not handled in assembly.
The RTC remains active during sleep, but the timebase does not, and obviously
jiffies has not been incremented. To restore the timebase, the pre-sleep RTC
time is subtracted from the current RTC time to get the difference in seconds.
- jiffies are incremented by (seconds elapsed) * HZ.
- the timebase is incremented by (seconds elapsed) * HZ * tb_ticks_per_jiffy
User Interface
--------------
Currently the only interface to the sleep code is via sysctl (and its /proc
interface). The following /proc items are present under /proc/sys/pm :
suspend: (write-only)
triggers sleep
mode: (string)
contains one of "clock-suspend", "power-down", or "standby",
indicating the sleep mode to be used.
rtc_alarm: (integer)
the number of seconds in the future to wake up. If 0, the RTC alarm is
not set (and some other mechanism must be present to wake up the CPU).
cdiv: (integer, for debugging only)
allows the user to override the "cdiv" field of APM0_CFG, which
controls the speed at which CPU state is transferred over the i2c bus.
It should be easy to add an interrupt handler for irq 24, so that pressing the
APM button on Beech triggers both sleep and wakeup.
^ permalink raw reply
* Re: [Linux-ia64] Can't boot in SMP with kernel 2.5.50 ia64
From: David Mosberger @ 2002-12-19 20:40 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805616@msgid-missing>
>>>>> On Thu, 19 Dec 2002 08:53:06 +0100 (NFT), Xavier Bru <Xavier.Bru@bull.net> said:
Xavier> Hello,
Xavier> Booting 2.5.50 with David's patch, it seems we can't boot in
Xavier> SMP on an ia64 machine. We get the message: SMP mode
Xavier> deactivated. Problem is due to smp_prepare_cpus() declaring
Xavier> max_cpus as "unsigned int" and testing against the -1 value.
Xavier> Problem was not seen in 2.5.45 because max_cpus was
Xavier> initialized to UINT_MAX.
I think the test in smp_prepare_cpus() is bogus. I changed it to test
just against 0 (as is done in the x86 version of smpboot.c).
--david
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.