* [U-Boot-Users] Secure Firmware + Firmware Upgrade?
From: Rohit Sharma @ 2006-06-05 9:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060605130906.3FCDA352655@atlas.denx.de>
On Mon, 05 Jun 2006 18:39:06 +0530, Wolfgang Denk <wd@denx.de> wrote:
> In message <op.tanxj1fkdfxu59@sys.t-mobile.de> you wrote:
>>
>> The only issue i see for now is that the image header structure won't
>> accomodate
>> the Digital signature string i.e. "image_header_t" and it has to be
>> appended at the
>> end of the firmware data blob.
>
> You could write the signature to a separate file and use a multi-file
> image to combine image and signature.
Thanks for the suggestion!!!
>> Due the nature of the product this is possible but than again the
>> warranty
>> would void if some one updates the software by themselves.
>
> The same is true if someone loads and runs an image that was not
> officially released - so why goong through all this effort just to
> make it more difficult to someone who *wants* to ignore the warranty?
Due to the very nature any corrupted image can be actually turn out to
be futile for the very person. Its for their safety only.
Thanks for your kind help.
Best Regards
rohit
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
^ permalink raw reply
* Re: Re: [Xen-devel] irq 17: nobody cared (try booting with the "irqpoll" option)
From: Hans-Christian Armingeon @ 2006-06-05 9:48 UTC (permalink / raw)
To: xen-users; +Cc: Keir Fraser, xen-devel
In-Reply-To: <77127a822746ae533dd703ab1c5aa38c@cl.cam.ac.uk>
Hi,
thank you for replying to my email.
Am Montag, 5. Juni 2006 09:51 schrieb Keir Fraser:
>
> On 5 Jun 2006, at 00:10, Hans-Christian Armingeon wrote:
>
> > Well, and on irq 17, there is the USB controller, that is "pluged"
> > into the domU too.
> >
> > Are there any other things, I can do to debug this issue?
>
> Ah, a known issue. Jan Beulich has supplied a patch for this (email
> subject "replacement for noirqdebug hack"). I want to find some time
> this week to work on a solution I'd prefer, and float it on this list
> for discussion.
I have
extra = "swiotlb=force noirqdebug"
in my config for the domU. I had to use swiotlb=force because of an oops.
I removed the irqpoll option from the dom0 kernel, and replaced it with noirqdebug.
Is that correct?
Johnny
>
> For now, just boot with noirqdebug on your dom0 and driver domain
> kernel command lines.
>
> -- Keir
Johnny
^ permalink raw reply
* RE: Transparent proxy setup with apache on the nat gateway
From: Nicolas Mailhot @ 2006-06-05 9:48 UTC (permalink / raw)
To: Sietse van Zanen; +Cc: netfilter
In-Reply-To: <02BB8A4AC86C564C89C7F14CF98CE0C49C73@knowledge.wizdom.nu>
[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]
Le lundi 05 juin 2006 à 10:40 +0200, Sietse van Zanen a écrit :
Thank you for taking the time to look at my problem !
> I think the error is in your first two rules for the PREROUTING chain
> in the NAT table:
...
> All WEB traffic will only hit the first rule and never the second.
I have traces of many attempts in my rule file - I never used those two
rules together so it's not the problem
> I think you should try something like this.
> Have apache proxy listen on localhost (127.0.0.1) port 8081
> Iptables -t NAT -A PREROUTING -p tcp -i eth0(internal nic) -m
> multiport
> --dports http,https,squid,svn,http-alt,webcache -j REDIRECT --to
> 127.0.0.1:8081
If I use REDIRECT the to is interpreted like --to-port and I see the LAN
system hammer the gateway 127 port :(
If I use
-A PREROUTING -i eth1 -p tcp -m multiport --dports
http,https,squid,svn,http-alt,webcache -j REDIRECT --to-port 8081
the requests are redirected to port 8081 of the lan interface IP
(192.168.1.1, I can live with that) but the result is abysmal :
apache logs
"GET / HTTP/1.1" requests instead of
"GET http://www.slashdot.org/ HTTP/1.1" requests
so all sites are served as if the browser asked for the local root
(empty) and the browser only receives blank pages
Regards,
--
Nicolas Mailhot
[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] typo: buad -> baud
From: Russell King @ 2006-06-05 9:46 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, trivial
In-Reply-To: <20060413113751.GK2335@quickstop.soohrt.org>
On Thu, Apr 13, 2006 at 01:37:51PM +0200, Horst Schirmeier wrote:
> Replacing mistyped "buad" with "baud" where applicable.
>
> Signed-off-by: Horst Schirmeier <horst@schirmeier.com>
Thanks - I've only picked this up because it's serial/arm related and
obviously correct (doesn't touch any code.) I'm not sure why anyone
else hasn't picked it up.
> ---
>
> arch/mips/ddb5xxx/ddb5476/dbg_io.c | 2 +-
> arch/mips/ddb5xxx/ddb5477/kgdb_io.c | 2 +-
> arch/mips/gt64120/ev64120/serialGT.c | 2 +-
> arch/mips/gt64120/momenco_ocelot/dbg_io.c | 2 +-
> arch/mips/ite-boards/generic/dbg_io.c | 2 +-
> arch/mips/momentum/jaguar_atx/dbg_io.c | 2 +-
> arch/mips/momentum/ocelot_c/dbg_io.c | 2 +-
> arch/mips/momentum/ocelot_g/dbg_io.c | 2 +-
> include/asm-arm/arch-l7200/serial_l7200.h | 2 +-
> include/asm-arm/arch-l7200/uncompress.h | 2 +-
> 10 files changed, 10 insertions(+), 10 deletions(-)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: swsusp and PSE
From: Pavel Machek @ 2006-06-05 9:39 UTC (permalink / raw)
To: Shaohua Li; +Cc: Linux-pm mailing list
In-Reply-To: <1149472065.32046.163.camel@sli10-desk.sh.intel.com>
On Po 05-06-06 09:47:45, Shaohua Li wrote:
> On Thu, 2006-06-01 at 22:24 +0800, Pavel Machek wrote:
> > On Čt 01-06-06 10:17:22, Nicolas Troncoso Carrere wrote:
> > > Hi,
> > > I was trying out swsusp, but up bumped up with the issue that it
> > needs PSE.
> > > I've been reading the source, but havent been able to get a grasp on
> > why does
> > > it need PSE.
> > > Could you enlighten me?
> >
> > W/o PSE, we are using pagetables during data copy, and we may
> > overwrite pagetable that is still used.
> w/PSE pagetable might be overwritten too and data copy uses identity
> mapping, overwrite pagetable doesn't harm to me.
w/PSE, identity mapping is fully contained in top-level pagedir, and
that is properly marked nosave.
wo/PSE, you'd need to properly mark nosave not only top-level pagedir,
but also all the needed descendants. Not impossible, just a bit
tricky, see x86-64 version for inspiration.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
_______________________________________________
linux-pm mailing list
linux-pm@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/linux-pm
^ permalink raw reply
* Re: [LARTC] How to explde HTB.INIT tc commands?
From: Stefano Mainardi @ 2006-06-05 9:37 UTC (permalink / raw)
To: lartc
In-Reply-To: <be119c020606020715s7a0f7007r674ba1919533b82c@mail.gmail.com>
2006/6/4, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>:
> Stefano Mainardi wrote:
> > Hi to all,
> > [...]
>
> You already sent that mail three times in less than 30 hours.
> Please stop.
I know, is a error of my SMTP.
>
> Somebody will answer if he/she knows.
I know too.
htb.init compile, i've found it.
Regards
--
Stefano Mainardi
Presidente Associazione ILDN - Italian Linux Distro Network
Mobile: 349/3917212
Skype: mainardistefano
IM (ICQ): 250-292-408
Blog: http://www.mainardistefano.org
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: Selecting unixfile plugin
From: Ben Martin @ 2006-06-05 9:35 UTC (permalink / raw)
To: Edward Shishkin; +Cc: reiserfs-list
In-Reply-To: <4483F791.7020608@namesys.com>
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
[snip]
>
> Yes, it is. Although this stuff should be qualified as experimental.
> If you have spare disk space and another box with serial connection,
> then we will send you the setup..
>
> Edward.
Cool. I'm looking forward to playing around with it. Hopefully I can
tailor the instructions to work with Xen or a filesystem mounted on
loopback (what I have at current) so the "spare machine" is somewhat
protected from the worst case.
I could generate the setup of scratch machine and serial connection if
this is required though.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [RESEND] Re: [PATCH] Update writing udev rules documentation
From: Remco @ 2006-06-05 9:29 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <200606051128.32960.remco@d-compu.dyndns.org>
> Comments appreciated.
>
This may be an useful addition, gave me a bit of a headache the past two
days.
Both the lp and the usblp driver create devices named lp[n], though
the kernel messages suggest an usblp[n] device for the USB printer.
When both a parallel port printer and an USB printer are attached they will
both be called lp0 leaving the system with only one device node. (So one of
the printers will be missing)
So far the best way to make a distinction seemed to be filtering on
subsystem, e.g.:
# printers
KERNEL="lp[0-9]*", SUBSYSTEM="printer", NAME="printer/lpt%n"
KERNEL="lp[0-9]*", SUBSYSTEM="usb", NAME="printer/usb%n"
This way parallel port printers will be called 'printer/lpt[n]' and USB
printers 'printer/usb[n]'.
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* [RESEND] Re: [PATCH] Update writing udev rules documentation
From: Remco @ 2006-06-05 9:28 UTC (permalink / raw)
To: linux-hotplug
> The patch isn't very readable, if anyone wants to review the changes I
> suggest you just look at the online version as almost all of it has been
> rewritten:
> http://www.reactivated.net/writing_udev_rules.html
>
> Comments appreciated.
>
Under 'About this document'
I don't think hotplug is a requirement nowadays.
Under 'Built-in persistent naming schemes'
I'm not sure this is true but
'/dev/disk/by-id/usb-Prolific_Technology_Inc._USB_Mass_Storage_Device-part1'
sounds semi-persistent to me. Imagine you've got two of these memory
sticks, what names do they get, and how can they be differentiated ? Since I
don't see an unique id, and unless udev has some trick up it's sleeve, I
suppose the second device detected will either overwrite the link created
by the first, or it won't create a link at all.
Under 'Putting your rules into action':
Maybe it's time to replace udevstart with udevtrigger ? Or at least mention
the udevtrigger/udevsettle combo.
I don't know if it's worthwhile mentioning that if a rule gets changed and
udevtrigger is run, the new device node / symlinks will be created
alongside the older existing one(s). Anything created by the old rules will
stay in place. The old stuff either needs to be removed manually or it will
disappear when the /dev tree is built from scratch. (probably only after a
reboot)
Under 'Logging'
AFAICT udev_log is used to set the logging severity. Normally setting it to
'err' is probably recommended, 'info' is useful for debugging and will dump
a lot of information to syslog. If I remember correctly, for this to work,
some option needs to be set to 'yes' during the build. (like 'make
USE_LOG=yes' or something similar)
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: mixing cache size on xeon4's in smp system
From: Chris Wedgwood @ 2006-06-05 9:26 UTC (permalink / raw)
To: Marty Leisner; +Cc: linux-kernel
In-Reply-To: <200606042317.k54NHfIS026034@dell2.home>
On Sun, Jun 04, 2006 at 11:17:41PM +0000, Marty Leisner wrote:
> I've heard advice "see if flakey things happen" -- that's not advice
> I want to follow...
it might work, i don't think anyone would really recommend it
if it's a non-critical machine try it out, beat it up with kernel
compiles or something to stress test it a bit
^ permalink raw reply
* Re: mixing cache size on xeon4's in smp system
From: Chris Wedgwood @ 2006-06-05 9:25 UTC (permalink / raw)
To: Marty Leisner, linux-kernel
In-Reply-To: <20060604173825.A28581@openss7.org>
On Sun, Jun 04, 2006 at 05:38:25PM -0600, Brian F. G. Bidulock wrote:
> For most motherboards the answer is no, regardless of whether you
> are running Linux or not.
Actually, I've had a system when the hardware was failing and one CPU
lost it's bottle and thought it had less cache (and maybe was a
different speed, forget).
Anyhow, Linux did work with the exception of timekeeping was screwy
(hence I think the speed of one CPU was wrong and I had to reboot with
notsc or something until I got the CPU replaced).
^ permalink raw reply
* Re: [PATCH] swsusp: allow drivers to determine between write-resume and actual wakeup
From: Pavel Machek @ 2006-06-05 9:23 UTC (permalink / raw)
To: Tejun Heo; +Cc: Jeff Garzik, linux-kernel, linux-ide
In-Reply-To: <20060605091131.GE8106@htj.dyndns.org>
On Po 05-06-06 18:11:31, Tejun Heo wrote:
> Currently, there is no way to tell whether a device is resuming to
> write swsusp image or waking up from actual software suspend. FREEZE
> and SUSPEND are different operations for some devices (e.g. disks
> don't spin down for FREEZE) and the resume operation for each is also
> different.
>
> This patch makes swsusp change device power state from PMSG_FREEZE to
> PMSG_SUSPEND on resume from software suspend. A driver can determine
> whether it's getting thawed or resuming by looking at device power
> state - if FREEZE, it's getting thawed to write image; if SUSPEND,
> resuming from software suspend. This patch doesn't affect drivers
> which don't update device power state. Only drivers which set power
> state to FREEZE after freezing are affected.
No, sorry.
If driver is interested if previous operation was FREEZE or
SUSPEND... just store that information locally.
If you want to know if you RESUME was after normal FREEZE or if it is
after reboot, there's better patch floating around to do that.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* NFS4 and host restrictions
From: Damian Pietras @ 2006-06-05 9:23 UTC (permalink / raw)
To: nfs
Hi,
I'm trying to work out how to restrict access to NFS4 directories by
client IP.
What I want to achive is something like that:
/nfs4 - virtual root
/nfs4/host1dir
/nfs4/host2dir
I want to restrict access for /nfs4/host1dir to host1 only and for
/nfs4/host2dir to host2.
I've tried few configurations in /etc/exportfs and nothing works, for example:
/nfs4 *(rw,sync,fsid=0)
/nfs4/host1dir host1(rw,sync)
/nfs4/host2dir host2(rw,sync)
This allows anyone to mount /nfs4/host1dir and /nfs4/host2dir
And this:
/nfs4 i127.0.0.1(rw,sync,fsid=0)
/nfs4/host1dir host1(rw,sync)
/nfs4/host2dir host2(rw,sync)
nobody is allowed to mount anything.
I can't figure it out and I couldn't find any information how it's
supposed to work. Can you help me?
I'm using nfs-utils 1.0.7.
--
Damian Pietras
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: Perfomance problem on MIPS
From: Ralf Baechle @ 2006-06-05 9:23 UTC (permalink / raw)
To: art; +Cc: linux-mips
In-Reply-To: <15613.060605@sigrand.ru>
On Mon, Jun 05, 2006 at 02:43:47PM +0700, art wrote:
> Hello all!
> I work with processor: MIPS 4KC.
> I check network performance without iptables & conntrac enabled
> and it has near 80Mbit/s.
> When I enable (without adding rules) network performance was
> near 40Mbit/s.
> While testing ksoftirqd is get near 50% of cpu. And (it is so
> strange) top eats the same! However cpu has 100% load and
> perfomance is real bad.
> Has anybody same problem?
Just loading the connection tracking module will pull networking
performance into a deep hole, no surprise there. All your numbers are on
the low side though. What clock rate is your CPU running?
Ralf
^ permalink raw reply
* Re: Selecting unixfile plugin
From: Edward Shishkin @ 2006-06-05 9:21 UTC (permalink / raw)
To: Ben Martin; +Cc: reiserfs-list
In-Reply-To: <1149491181.3926.59.camel@sam>
Ben Martin wrote:
>Hi,
>
>
Hello
> After much digging around as to how to use the reiser4 compression
>plugin I have found this message.
>http://marc.theaimsgroup.com/?l=reiserfs&m=113190018626958&w=2
>
>I'm using 2.6.15 + resier4 + metas patches.
>
>I'm trying to set the default plugin to cryptcompress for a directory in
>a r4 filesystem.
>
>It seems that the plugins/regular is thought to be a directory when I
>echo "cryptcompress\0" >|plugins/regular
>
>Trying various combinations of things inside regular/ like echoing into
>label etc don't seem to have an effect when read back again.
>
>It seems from the below link and grepping the 2.6.15 reiser4 patch that
>echoing "cryptcompress" >| mydir/..../plugins/regular/label
>should make new files in mydir use the cryptcompress plugin by defualt.
>http://www.namesys.com/cryptcompress-related_plugins.html
>
>The info like http://www.namesys.com/cryptcompress_design.html seems to
>be targetted toward developers rather than users. Are there any
>references or logs of command line interactions to enable and tweak
>compression/crypto aimed at end user consumption?
>
>
>
Yes, it is. Although this stuff should be qualified as experimental.
If you have spare disk space and another box with serial connection,
then we will send you the setup..
Edward.
>Also from what I've seem a
>sed s/metas/..../g
>might be in order for
>http://www.namesys.com/v4/pseudo.html
>
>
>
>
^ permalink raw reply
* Re: Fusing Debian patches back into nfs-utils
From: Steinar H. Gunderson @ 2006-06-05 9:20 UTC (permalink / raw)
To: nfs
In-Reply-To: <17539.41286.81087.480257@cse.unsw.edu.au>
On Mon, Jun 05, 2006 at 01:13:10PM +1000, Neil Brown wrote:
> I've noticing this problem before and always shied away from it.
> While the value might be "unpredictable", someone might be depending
> on the current behaviour, and changing it could break things for some
> people while fixing things for others...
> Can you -- or anyone else -- convince me that this is really a good
> and safe thing to do? I'm fairly open to being convince, but I don't
> feel I'm familiar enough with all the issues and would love to hear
> from someone who is.
> My particular concern is "What might it break, and how much of a
> problem could that be?"
The biggest problem is, IMO: People expect stuff to be done as "nobody" (or,
at least uid 65534, which is mapped to "nobody" on all systems that I know).
"nobody" in Linux (as opposed to, say, Hurd) is not really someone with no
rights, but can own files etc. -- so if you had something owned by "nobody",
or "nobody" was a member of some specific group, you'd expect that to work.
Now it can easily vary between different systems, which is rather bad.
As far as I'm concerned, we've already probably had multiple instances of
this changing (from 65534 to 4294967294, when upgrading) and nobody really
noticed; I don't see the harm of changing it back to it's the same
everywhere.
> Hmm... I think the real bug here is that a '#' is treated as starting
> a comment even if it isn't at the start of a word.
> xgetc shouldn't check for '#', xgettok should.
> The kernel doesn't currently escape '#' in /proc/fs/nfs/exports so
> reading pathnames containing '#' from there will still be a problem.
>
> So I might fix that too..... could that break anything?
Well, I think it's at least inconsistent with the man page as it's written
today; in that case, the man page should be rewritten too. Look at the
original bug report on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=239230
to see the entire section.
>> - mountd_state_directory.diff: Let the user select (via a new parameter)
>> the path to the NFS state directory for mountd, to match the statd
>> functionality. (If you take it in, you might want to remove the part in
>> the manpage saying it's Debian-specific.)
> Seems pretty pointless ;-) but that won't stop be accepting it...
It is reportedly useful for read-only /var -- people with special clustering
needs complained about the lack of such things, IIRC.
> I love getting patches that also update the man page! Now if I can
> only train people to update ChangeLog too :-)
:-)
> Hmmm. I'm not sure I like removing blank lines just for the same of
> some silly warning - blank lines are good for readability.
> I have instead replaced them with a single ' which removes the warning
> and is almost as good as a blank.
OK, that sounds good too. I don't know why the blanks are disallowed, but
just leaving a man page with known errors wouldn't be too good either. :-)
/* Steinar */
--
Homepage: http://www.sesse.net/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: merging new drivers (was Re: 2.6.18 -mm merge plans)
From: Arjan van de Ven @ 2006-06-05 9:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: Christoph Hellwig, jeff, linux-kernel
In-Reply-To: <20060605021054.4d5428da.akpm@osdl.org>
On Mon, 2006-06-05 at 02:10 -0700, Andrew Morton wrote:
> On Mon, 5 Jun 2006 09:59:18 +0100
> Christoph Hellwig <hch@infradead.org> wrote:
>
> > On Sun, Jun 04, 2006 at 06:47:11PM -0700, Andrew Morton wrote:
> > > Yes, I agree. As long as we reasonably think that a piece of code *will*
> > > become acceptable within a reasonable amount of time then going early is
> > > safe.
> >
> >
> > Definitly not the case for areca. The only progress at all is where people
> > like Arjan, Randy or me did very intensive babysitting. And it's still far
> > from beeing there.
> >
> > And especially in scsi land I'm absolutely against putting in more substandard
> > drivers. The subsystem is still badly plagued from lots of old drivers that
> > aren't up to any standards, and we need to decrease the maintaince load due
> > to odd drivers not increase it even further.
>
> So.. How are we going to get the Areca controllers supported in Linux?
> The code's been sitting in -mm for over a year and the vendor does have
> staff assigned to work on it.
the driver is improving for sure.
What seems to work well is when we make a work-to-do list, the vendor
then goes about and fixes most of that quite quickly. I think I'm
approaching the end of useful review input I can give (they fixed most
if not all the stuff I flagged before), it would be really nice if
Christoph or some other scsi person would do a review again and make a
list of "these should be fixed and then we can merge" (and a list of
"these can be fixed post merge" as well)
^ permalink raw reply
* Re: NAND OOB Questions...
From: Charles Manning @ 2006-06-05 9:23 UTC (permalink / raw)
To: linux-mtd, tglx; +Cc: Steve Finney
In-Reply-To: <1149495264.11983.12.camel@localhost.localdomain>
On Monday 05 June 2006 20:14, Thomas Gleixner wrote:
> On Thu, 2006-06-01 at 09:38 -0700, Steve Finney wrote:
> > 1) The Samsung K9F56* NAND chip allows doing more than one write
> > to the OOB area of a page without an erase; the second write
> > may zero bits that were set to 1 by the first write. Is the Samsung
>
> Bits can not be set to 1 by the first write. FLASH cells are set to 1 by
> erasing and programming can set bits to 0.
>
> > chip unusual in this, or is this normal NAND behavior? (I believe
> > this would be normal for NOR flash).
>
> On NOR you can do this almost unlimited. NAND is much more restricted
> vs. write ordering.
Just one point of clarification that tglx might not have spelled out clearly
here.
In both NAND and NOR you cannot set a 0 bit back to a 1 bit by programming.
You can only do this by erasing the erasable block.
Where NOR and NAND differ is that if you program a pattern into NOR that tries
to set a 0 to a 1 then (in most cases) the programming operation will be
aborted. However, NAND will program the zeros only and 1 bits are just "don't
care".
^ permalink raw reply
* Re: 2.6.17-rc5-mm3
From: Ingo Molnar @ 2006-06-05 9:12 UTC (permalink / raw)
To: J.A. Magallón; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <20060605012842.3d58095f@werewolf.auna.net>
* J.A. Magallón <jamagallon@ono.com> wrote:
> I got this with -mm2, is it supposed to be cured in -mm3 ? I still
> have to try with mm3:
> (all tests failed like this...)
>
> Jun 2 14:34:39 annwn kernel: --------------------------------------------------------
> Jun 2 14:34:39 annwn kernel: 141 out of 206 testcases failed, as expected. |
> Jun 2 14:34:39 annwn kernel: ----------------------------------------------------
>
> Expected ? Uh ?
to have lock validation you should have these options enabled:
CONFIG_PROVE_SPIN_LOCKING=y
CONFIG_PROVE_RW_LOCKING=y
CONFIG_PROVE_MUTEX_LOCKING=y
CONFIG_PROVE_RWSEM_LOCKING=y
otherwise the tests are still run, but the deadlocks are not detected.
That's why those 141 testcases are 'expected' failures.
and definitely try -mm3 plus the current combo patch:
http://redhat.com/~mingo/lockdep-patches/lockdep-combo-2.6.17-rc5-mm3.patch
Ingo
^ permalink raw reply
* [PATCH] swsusp: allow drivers to determine between write-resume and actual wakeup
From: Tejun Heo @ 2006-06-05 9:11 UTC (permalink / raw)
To: pavel, Jeff Garzik, linux-kernel, linux-ide
Currently, there is no way to tell whether a device is resuming to
write swsusp image or waking up from actual software suspend. FREEZE
and SUSPEND are different operations for some devices (e.g. disks
don't spin down for FREEZE) and the resume operation for each is also
different.
This patch makes swsusp change device power state from PMSG_FREEZE to
PMSG_SUSPEND on resume from software suspend. A driver can determine
whether it's getting thawed or resuming by looking at device power
state - if FREEZE, it's getting thawed to write image; if SUSPEND,
resuming from software suspend. This patch doesn't affect drivers
which don't update device power state. Only drivers which set power
state to FREEZE after freezing are affected.
Note that the behavior introduced by this patch is more correct in
that, on resume, the last power operation done on those devices are
PMSG_SUSPEND, not PMSG_FREEZE.
Signed-off-by: Tejun Heo <htejun@gmail.com>
---
Hello, Pavel.
I'm currently working on libata suspend/resume support. libata needs
to take different actions for getting thawed and resuming, so this
patch. If you have any better idea, please let me know.
Also, another piece of information libata can use is whether the
current power operation is due to runtime (per-device) PM request or
system PM event. In ATA, many EH operations are bus-wide and it would
be better/simpler to perform PM bus-wide if possible. I think this
can be done by adding a function to query global PM state.
Thanks.
drivers/base/power/resume.c | 25 +++++++++++++++++++++++++
include/linux/pm.h | 1 +
kernel/power/swsusp.c | 4 ++++
3 files changed, 30 insertions(+), 0 deletions(-)
4f2edc42e5b0d628ba164e4f438a7255672a82a2
diff --git a/drivers/base/power/resume.c b/drivers/base/power/resume.c
index 317edbf..3e08c58 100644
--- a/drivers/base/power/resume.c
+++ b/drivers/base/power/resume.c
@@ -122,3 +122,28 @@ void device_power_up(void)
EXPORT_SYMBOL_GPL(device_power_up);
+/**
+ * device_prep_swsusp_resume - Prep for resume from swsusp
+ *
+ * Change power state of devices from PMSG_FREEZE to PMSG_SUSPEND
+ * in preparation for resume from swsusp. This allows drivers to
+ * tell whether they are resuming from frozen state to write
+ * image or from actual swsusp.
+ */
+
+void device_prep_swsusp_resume(void)
+{
+ struct device *dev;
+
+ list_for_each_entry(dev, &dpm_off_irq, power.entry)
+ if (dev->power.power_state.event == PM_EVENT_FREEZE)
+ dev->power.power_state = PMSG_SUSPEND;
+
+ down(&dpm_sem);
+ down(&dpm_list_sem);
+ list_for_each_entry(dev, &dpm_off, power.entry)
+ if (dev->power.power_state.event == PM_EVENT_FREEZE)
+ dev->power.power_state = PMSG_SUSPEND;
+ up(&dpm_list_sem);
+ up(&dpm_sem);
+}
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 66be589..3e1d79c 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -184,6 +184,7 @@ #endif
extern void device_pm_set_parent(struct device * dev, struct device * parent);
extern int device_power_down(pm_message_t state);
+extern void device_prep_swsusp_resume(void);
extern void device_power_up(void);
extern void device_resume(void);
diff --git a/kernel/power/swsusp.c b/kernel/power/swsusp.c
index c4016cb..a534f84 100644
--- a/kernel/power/swsusp.c
+++ b/kernel/power/swsusp.c
@@ -238,6 +238,10 @@ int swsusp_suspend(void)
printk(KERN_ERR "Error %d suspending\n", error);
/* Restore control flow magically appears here */
restore_processor_state();
+
+ if (!in_suspend)
+ device_prep_swsusp_resume();
+
Restore_highmem:
restore_highmem();
device_power_up();
--
1.3.2
^ permalink raw reply related
* Re: merging new drivers (was Re: 2.6.18 -mm merge plans)
From: Andrew Morton @ 2006-06-05 9:10 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: jeff, linux-kernel
In-Reply-To: <20060605085918.GB26766@infradead.org>
On Mon, 5 Jun 2006 09:59:18 +0100
Christoph Hellwig <hch@infradead.org> wrote:
> On Sun, Jun 04, 2006 at 06:47:11PM -0700, Andrew Morton wrote:
> > Yes, I agree. As long as we reasonably think that a piece of code *will*
> > become acceptable within a reasonable amount of time then going early is
> > safe.
>
>
> Definitly not the case for areca. The only progress at all is where people
> like Arjan, Randy or me did very intensive babysitting. And it's still far
> from beeing there.
>
> And especially in scsi land I'm absolutely against putting in more substandard
> drivers. The subsystem is still badly plagued from lots of old drivers that
> aren't up to any standards, and we need to decrease the maintaince load due
> to odd drivers not increase it even further.
So.. How are we going to get the Areca controllers supported in Linux?
The code's been sitting in -mm for over a year and the vendor does have
staff assigned to work on it.
^ permalink raw reply
* Re: OLPC (One Laptop Per Child) Developer's program.
From: David Woodhouse @ 2006-06-05 9:07 UTC (permalink / raw)
To: Anand Kumria; +Cc: netdev
In-Reply-To: <e5umgs$lfj$1@sea.gmane.org>
On Sun, 2006-06-04 at 13:17 +0000, Anand Kumria wrote:
> > One thing we really need is NAT-PT or an equivalent for allowing access
> > to the Legacy Internet from IPv6-only hosts. As soon as I finish playing
> > with JFFS2 improvements, I plan to start looking at that.
>
> Wouldn't miredo mostly fit the bill? It won't get through Symmetric NATs
> (by design) but those are supposed to be uncommon.
That seems to be a method for IPv4 hosts to get IPv6 connectivity. What
I'm after is a method for IPv6 hosts to get IPv4 connectivity -- like
NAT-PT.
--
dwmw2
^ permalink raw reply
* Re: [RFC][PATCH] request_irq(...,SA_BOOTMEM);
From: Ingo Molnar @ 2006-06-05 9:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: Benjamin Herrenschmidt, linux-kernel, tglx, torvalds
In-Reply-To: <20060605012405.ac17f918.akpm@osdl.org>
* Andrew Morton <akpm@osdl.org> wrote:
> And yes, the mutex code will (with debug enabled) unconditionally
> enable interrupts. ppc64 tends to oops when this happens, in the
> timer handler (so it'll be intermittent...)
hm, i sent a patch to fix that, long time ago.
> But looking at
> work-around-ppc64-bootup-bug-by-making-mutex-debugging-save-restore-irqs.patch
> I realise I don't understand it. We only go into the irq-enabling
> code in the case of contention, and there cannot be contention in this
> case?
in the debug case we go into the 'slowpath' all the time - so that we
can do the debug checks under the mutex lock.
if we get real contention then we have a might_sleep() check that will
catch that.
i'd suggest to push
work-around-ppc64-bootup-bug-by-making-mutex-debugging-save-restore-irqs.patch
upstream - i thought we agreed that while it's a bit hacky and slows the
mutex code down a bit, it's not practical right now to forbid
uncontended mutex_lock() in early init code?
Ingo
^ permalink raw reply
* Re: 2.6.17-rc5-mm3: bad unlock ordering (reiser4?)
From: Barry K. Nathan @ 2006-06-05 9:00 UTC (permalink / raw)
To: Ingo Molnar
Cc: Valdis.Kletnieks, Andrew Morton, arjan, linux-kernel,
reiserfs-dev, Hans Reiser
In-Reply-To: <20060605081220.GA30123@elte.hu>
On 6/5/06, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Barry K. Nathan <barryn@pobox.com> wrote:
[snip]
> > So, does that mean the plan is to annotate/tweak things in order to
> > shut up *each and every* false positive in the kernel?
>
> yes. Note that for the many reasons i outlined before they are only
> "half false positives" - i.e. they are potentially dangerous constructs
> and they are potentially inefficient - hence we _want to_ document them
> in the code, to increase the cleanliness of the kernel. A pure "false
> positive" would be a totally valid and perfect locking construct being
> flagged by the lock validator.
>
> nor do these warnings really hurt anyone. Lockdep prints info and then
> shuts up - the system continues to work.
Ok, thanks for explaining that.
> > Anyway, I tried your patch and I got this:
>
> please try the addon patch below.
I don't know if you saw this comment on the lock validator article at LWN?
---begin quote---
The kernel lock validator
Posted May 31, 2006 9:35 UTC (Wed) by subscriber nix [Link]
... and now reiser4 turns up with a tree of locks where each rank may
be taken within the rank above safely, but where there are a
potentially unbounded number of ranks...
---end quote---
I have no idea if that's actually the case, but if it is, it might be relevant.
Anyway, I have a new, more scary-looking lockdep warning:
http://members.cox.net/barrykn/linux/trace/dmesg.reiser4-4
http://members.cox.net/barrykn/linux/trace/latency_trace_reiser4-4.bz2
[ 316.680616] ( smbd-824 |#0): new 239822061 us user-latency.
[ 316.680805] stopped custom tracer.
[ 316.680951]
[ 316.680964] =====================================================
[ 316.681241] [ BUG: possible circular locking deadlock detected! ]
[ 316.681412] -----------------------------------------------------
[ 316.681575] smbd/824 is trying to acquire lock:
[ 316.681727] (&txnh->hlock){--..}, at: [<e09a884a>]
txn_end+0x3f9/0x47c [reiser4]
[ 316.682366]
[ 316.682379] but task is already holding lock:
[ 316.682629] (&atom->alock){--..}, at: [<e09a78da>]
txnh_get_atom+0x23/0x85 [reiser4]
[ 316.683192]
[ 316.683206] which lock already depends on the new lock,
[ 316.683472] which could lead to circular deadlocks!
[ 316.683633]
[ 316.683648] the existing dependency chain (in reverse order) is:
[ 316.683922]
[ 316.683936] -> #1 (&atom->alock){--..}:
[ 316.684392] [<c012f30f>] lockdep_acquire+0x67/0x7f
[ 316.685084] [<c029b67f>] _spin_lock+0x1d/0x2b
[ 316.685772] [<e09a7c0c>] try_capture+0x2d0/0x9cb [reiser4]
[ 316.686514] [<e09a214d>] longterm_lock_znode+0x2fc/0x415 [reiser4]
[ 316.687245] [<e09af884>] coord_by_handle+0x142/0xb76 [reiser4]
[ 316.687982] [<e09b03cc>] coord_by_key+0x55/0x5a [reiser4]
[ 316.688714] [<e09a3ca5>] insert_by_key+0x31/0x5c [reiser4]
[ 316.689483] [<e09bb77d>]
write_sd_by_inode_common+0x117/0x502 [reiser4]
[ 316.690340] [<e09bbb95>] create_object_common+0x2d/0x37 [reiser4]
[ 316.691092] [<e09b8f57>] create_vfs_object+0x376/0x551 [reiser4]
[ 316.691841] [<e09b91bb>] create_common+0x44/0x4b [reiser4]
[ 316.692581] [<c0167a6e>] vfs_create+0x67/0xad
[ 316.693259] [<c016a832>] open_namei+0x19b/0x6cd
[ 316.693936] [<c0158d64>] do_filp_open+0x2b/0x42
[ 316.694621] [<c0158ddc>] do_sys_open+0x61/0xef
[ 316.695276] [<c0158e9d>] sys_open+0x18/0x1a
[ 316.695934] [<c029b8cc>] syscall_call+0x7/0xb
[ 316.696629]
[ 316.696643] -> #0 (&txnh->hlock){--..}:
[ 316.697087] [<c012f30f>] lockdep_acquire+0x67/0x7f
[ 316.697781] [<c029b67f>] _spin_lock+0x1d/0x2b
[ 316.698451] [<e09a884a>] txn_end+0x3f9/0x47c [reiser4]
[ 316.699242] [<e09a443c>] reiser4_exit_context+0xb2/0x125 [reiser4]
[ 316.699981] [<e09b90f2>] create_vfs_object+0x511/0x551 [reiser4]
[ 316.700729] [<e09b91bb>] create_common+0x44/0x4b [reiser4]
[ 316.701467] [<c0167a6e>] vfs_create+0x67/0xad
[ 316.702142] [<c016a832>] open_namei+0x19b/0x6cd
[ 316.702823] [<c0158d64>] do_filp_open+0x2b/0x42
[ 316.703493] [<c0158ddc>] do_sys_open+0x61/0xef
[ 316.704159] [<c0158e9d>] sys_open+0x18/0x1a
[ 316.704831] [<c029b8cc>] syscall_call+0x7/0xb
[ 316.705518]
[ 316.705532] other info that might help us debug this:
[ 316.705566]
[ 316.705936] 2 locks held by smbd/824:
[ 316.706085] #0: (&inode->i_mutex){--..}, at: [<c0299d58>]
mutex_lock+0xd/0xf
[ 316.706654] #1: (&atom->alock){--..}, at: [<e09a78da>]
txnh_get_atom+0x23/0x85 [reiser4]
[ 316.707335]
[ 316.707349] stack backtrace:
[ 316.709560] [<c01032ab>] show_trace_log_lvl+0x64/0x125
[ 316.710003] [<c01038bd>] show_trace+0x1b/0x20
[ 316.710421] [<c0103914>] dump_stack+0x1f/0x24
[ 316.710842] [<c012e400>] print_circular_bug_tail+0x5d/0x69
[ 316.712546] [<c012eca2>] __lockdep_acquire+0x896/0xa91
[ 316.714438] [<c012f30f>] lockdep_acquire+0x67/0x7f
[ 316.716133] [<c029b67f>] _spin_lock+0x1d/0x2b
[ 316.717929] [<e09a884a>] txn_end+0x3f9/0x47c [reiser4]
[ 316.718768] [<e09a443c>] reiser4_exit_context+0xb2/0x125 [reiser4]
[ 316.719319] [<e09b90f2>] create_vfs_object+0x511/0x551 [reiser4]
[ 316.720536] [<e09b91bb>] create_common+0x44/0x4b [reiser4]
[ 316.721610] [<c0167a6e>] vfs_create+0x67/0xad
[ 316.724954] [<c016a832>] open_namei+0x19b/0x6cd
[ 316.728125] [<c0158d64>] do_filp_open+0x2b/0x42
[ 316.730886] [<c0158ddc>] do_sys_open+0x61/0xef
[ 316.733473] [<c0158e9d>] sys_open+0x18/0x1a
[ 316.736245] [<c029b8cc>] syscall_call+0x7/0xb
--
-Barry K. Nathan <barryn@pobox.com>
^ permalink raw reply
* Re: 2.6.17-rc5-mm3 -- ACPI errors (are these ones that are significant?)
From: Andrew Morton @ 2006-06-05 8:59 UTC (permalink / raw)
To: Miles Lane; +Cc: linux-kernel, linux-acpi
In-Reply-To: <a44ae5cd0606050124h4c82f45aq27f68f9d07956642@mail.gmail.com>
On Mon, 5 Jun 2006 01:24:27 -0700
"Miles Lane" <miles.lane@gmail.com> wrote:
> During boot:
>
> acpi_processor-0731 [00] processor_preregister_: Error while parsing
> _PSD domain information. Assuming no coordination
>
> During resume and after the "BUG: sleeping function called from
> invalid context at include/asm/semaphore.h:99 in_atomic():0,
> irqs_disabled():1" that I reported earlier:
>
> PM: Finishing wakeup.
> acpi: resuming
> ACPI: read EC, IB not empty
> ACPI: read EC, OB not full
> ACPI Exception (evregion-0412): AE_TIME, Returned by Handler for
> [EmbeddedControl] [20060310]
> ACPI Exception (dswexec-0459): AE_TIME, While resolving operands for
> [Store] [20060310]
> ACPI Error (psparse-0522): Method parse/execution failed
> [\_TZ_.THRM._TMP] (Node c189ec44), AE_TIME
> agpgart-intel 0000:00:00.0: resuming
Please copy linux-acpi on acpi-related problems.
^ 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.