All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Funny repack behaviour
From: Johannes Schindelin @ 2006-04-08 22:11 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604081528070.2215@localhost.localdomain>

Hi,

On Sat, 8 Apr 2006, Nicolas Pitre wrote:

> On Sat, 8 Apr 2006, Johannes Schindelin wrote:
> 
> > Hi,
> > 
> > I just accidentally reran "git-repack -a -d" on a repository, where I just 
> > had run it. And I noticed a funny thing: Of about 4000 objects, it reused 
> > all but 8. So I reran it, and it reused all but 2. I ran it once again, 
> > and it reused all.
> > 
> > The really funny thing is: it created the same pack every time!
> 
> Probably not.  Subsequent packs were most probably even smaller !

Oh, you're right. I was tricked by the identical pack-names. Somehow I 
forgot that the pack name just reflects a hash of the _unpacked_ objects, 
not the pack file itself.

Sorry for the noise.

Ciao,
Dscho

^ permalink raw reply

* [linux-lvm] Concise LVM Summary
From: linux_user98765 @ 2006-04-08 21:11 UTC (permalink / raw)
  To: linux-lvm

I'm trying to write a perl script to give concise output of 
pvs, vgs, lvs, pvdisplay, vgdisplay, lvdisplay and df -- something
like:


VG home [PE (4MB): 0 (0 b) / 52205 (203.93 GB)]
LV /dev/home/lvol0 /home [LE: 52205 (203.93 GB); DF: 64G/201G (129G)
34%]
PV /dev/sdb [PE (4096KB): 0 (0 b) / 38156 (149.05 GB); DF: ??/149G (??)
??%]
PV /dev/hdb4 [PE (4096KB): 0 (0 b) / 14049 (54.88 GB); DF: ??/55G (??)
??%]


however, there are a few things I have yet to figure out:

- determine the actual disk usage of a particular PV in a given LV
- the lvs column option which produces the heading "Log"
- the nature of the pvs,vgs,lvs separator inconsistencies:

lvs - Headers and LV lines are separator terminated
vgs - Headers not separator terminated, VG lines are
pvs - Headers not separator terminated, PV lines are

- The unabreviated names of the column headings
  (a website detailing each would be nice)
- whether pvdisplay,vgdisplay,lvdisplay offer anything more than
  pvs, vgs, lvs with all columns displayed
- Why the majority of pvs,vgs,lvs columns lack data

I'm still working on the code, but the above are the major stumbling
blocks I've come across so far...

TIA!

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

^ permalink raw reply

* [parisc-linux] Q: TLS local dynamic case and zero initialized ti_offset?
From: Carlos O'Donell @ 2006-04-08 22:16 UTC (permalink / raw)
  To: Randolph Chung, parisc-linux

Randolph,

In the local dynamic case we emit one reloc R_PARISC_TLS_DTPMOD32.
This means that at runtime there is a GOT entry with an absoluate
address which points to a tls_index structure, which has it's
ti_module filled by the dynamic loader (after processing the DTPMOD32
reloc). The question I have is, does this tls_index appear in bss? Is
the offset ti_offset initialized to zero? The zero offset is required
since we want __tls_get_addr to return the start of the modules block,
so we can subsequently offset into that block without calling
__tls_get_addr again.

Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

^ permalink raw reply

* Re: Black box flight recorder for Linux
From: JustFillBug @ 2006-04-08 22:28 UTC (permalink / raw)
  To: linux-kernel
In-Reply-To: <4437E4B7.40208@superbug.co.uk>

On 2006-04-08, James Courtier-Dutton <James@superbug.co.uk> wrote:
> Andi Kleen wrote:
>> Reset button is like a cold boot and it generally ends up with cleared 
>> RAM.
>> 
> Thank you. That saved me 30mins hacking. :-)
>

How about Magic sysRq reboot? 


^ permalink raw reply

* Xen cpufreq support status: how to notify hypervisor of frequency change?
From: Matt T. Yourst @ 2006-04-08 22:29 UTC (permalink / raw)
  To: xen-devel; +Cc: yourst

Hi,

I previously posted a patch to make the dom0 cpufreq drivers properly use 
DOM0_MSR (instead of wrmsr) to adjust the processor frequency and voltage. 

This does indeed adjust the frequency, but Xen seems to have major latency 
problems whenever the frequency change takes affect, causing various problems 
like losing mouse events, uncontrolled keyboard repeats, and choppy audio and 
video playback for a few seconds after the shift.

This appears to happen because virtual timer interrupts do not get delivered 
on a regular basis for a few seconds following the frequency change.

Assuming we want to keep the cpufreq driver itself in dom0, what's the proper 
way to notify the hypervisor that the CPU frequency has just changed, so it 
can adjust its timers like the cpufreq driver on the native kernel does?

I'd really like to have cpufreq working properly under Xen (for both 
workstations and to a lesser extent servers), so what would be the best way 
to get this running?

- Matt Yourst

-------------------------------------------------------
 Matt T. Yourst               yourst@cs.binghamton.edu
 Binghamton University, Department of Computer Science
-------------------------------------------------------

^ permalink raw reply

* Re: Raid 4 idea!
From: JaniD++ @ 2006-04-08 22:40 UTC (permalink / raw)
  To: Bill Davidsen; +Cc: linux-raid
In-Reply-To: <443824A8.6070903@tmr.com>

Hello,

...

> > What do you think, Neil?

> I don't know what Neil thinks, but I have never liked the performance
implications of RAID-4, could you say a few words about why 4 rather  than
5? My one test with RAID-4 showed the parity drive as a huge bottleneck, and
seeing that practice followed theory, I gave up on it.

I think the performance is depend on the specific job.
In my case, the level 4 is better than level 5.
My system is a download server.
This job makes a lot of reads, and some write.
I use 4x12 unit raid4 array, and 1 raid0 array from 4 raid4.

Why?
let me see:
1. easy to start without the parity disk.
    1/a without the parity disk, it is more faster than raid5/4, and i can
easy and fast upload the server with data, and after the upload is done,
relatively quickly can generate the 4x1 parity information at one time!
    1/b if more disk fails, a little easyer to recover than raid5

2. I speaks more read and a little write.
On raid5 if somebody want to write only one bit to the array, all drive need
to read, and two disk is need to write after.
This requires too much time to force to wait the read processes.
But on raid4, all the drives need to read, and only one of the valuable
drives need to write! (+ the parity drive)
This is a little bit faster for me...

3. and this is the most important:
My system have 2 bottleneck with about 1000 downloader users at one time:
a, the drives seek time
b, the io bandwith.
I can make the balance between this 2 bottleneck with the readahead
settings.
On raid 5 the blockdev readahead _reads the parity too_, and waste the
bandwith, and the cache of the drive, the cache in memory, but can seeks N
drive.
On raid 4, the readahead is all valuable, but i can use only N-1 drive to
seeking.

4. on case of very high download traffic, and requires an upload too, i can
disable the party, and speed up the write process, and after the load is
fall back to normal, i can recreate the parity again.
This is a balance between the  performance, and redundancy.
This is a little dangerous, but this is my choise, and this way is, why
linux is so beautiful! :-)

5. with Neils patch i can use the bitmap too. ;-)

6. the parity drive becomes the bottleneck because it is offload the other
drives.
On other hand, if i plan to upgrade the system, i only need to buy faster
parity device! :-)

7/a on extreme case, i can move the parity out from the box, using NBD.
The nbd server can speed up and / or can store all the four parity drive
with more cost effective way.

7/b Optionally i can set up the NBD server again, and silenty (slowly)
reconstruct the parity again using the legacy raid 1, and i can use one USB
mobile rack to move the live parity from loop device to the new HDD in rack,
and i need to stop the system only for replace the bad disk to the new done
synced parity drive.
(I did not use hot-swap at the moment.)

> And in return I'll point out that this makes recovery very expensive, read
everything while reconstructing, then read everything all over again when
making a new parity drive after repair.

On my idea?
Yes, this is right.
But!
If one drive is failing, the parity disk convertion close equal time to
reconstruction, except, it goes more and more faster while the degraded
raid4 array gets closer to the clean raid0! (raid4 without parity)

And with one (exactly 4x1) failed drive my system can go on the top
performance, until i replace the old drive to new one.

The final parity recreation on raid4:
I can only point to the mdadm default raid5 creation mechanism, the "fantom"
spare drive!
Neil sad, this is faster than norma raid5 creation, and he have right!
With this option, only 1 disk is writing, and all other is only reading!

Cheers,
Janos





-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979


^ permalink raw reply

* Re: Black box flight recorder for Linux
From: linux @ 2006-04-08 22:45 UTC (permalink / raw)
  To: linux-kernel; +Cc: hancockr, James

> I wouldn't think most BIOSes these days would bother to clear system RAM 
> on a reboot. Certainly Microsoft was encouraging vendors not to do this 
> because it slowed down system boot time.

I don't think they explicitly clear it all, but they do write to it to
test how much RAM is installed and don't bother to put back what they
scribbled on.


Sufficient ECC techniques sould probably recover from the damage.  For a
first attempt, I'd take 4096-byte pages, not use the first and last 8
bytes at all, and divide the remaining 4080 bytes into 16 interleaved
255-byte ECC segments, each using a byte-wide Reed-Solomon code.
(The fraction of that 255 devoted to ECC is up to you; n-bit-wide
Reed-Solomon just requires that data + ECC <= (2^n - 1) bytes of n
bits each.)

For extra hack value, you could detect at boot what parts of your
log got corrupted and avoid using those parts when logging new data.
(There are complications...)

It is possible to update RS ECC incrementally, or perhaps it would be
better to store the tail of the log in some less efficient form (like
multiple replication) and then pack it into ECC when full.


The other thing that might be a problem is that I don't know how long
refresh stops during reset.  Again, ECC can be your friend.
(And code for it already exists in lib/reed_solomon/)

^ permalink raw reply

* 2.4.32: unresolved symbol unregister_qdisc
From: George P Nychis @ 2006-04-08 22:47 UTC (permalink / raw)
  To: linux-kernel

Hey,

I have a kernel module that uses unregister_qdisc and register_qdisc, whenever i try to insert the module I get:
/lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol unregister_qdisc
/lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol register_qdisc

Am i missing some sort of support in the kernel?

Please CC all responses directly to me :)

Thanks!
George


^ permalink raw reply

* [Qemu-devel] [usb] correct position of hid descriptor for emulated usb mouse
From: Lonnie Mendez @ 2006-04-08 22:47 UTC (permalink / raw)
  To: qemu-devel

   I was trying out qemu's emulated usb mouse under debian sid and 
windows xp.  It worked fine under debian but failed to start under 
windows xp guest.

   It turns out the hid descriptor in the qemu_mouse_config_descriptor 
array is out of position.  Please see section 7.1 in the document HID1_11:

"The HID descriptor shall be interleaved between the Interface and
Endpoint descriptors for HID Interfaces. That is, the order shall be:

Configuration descriptor
Interface descriptor (specifying HID Class)
HID descriptor (associated with above Interface)
Endpoint descriptor (for HID Interrupt In Endpoint)
Optional Endpoint descriptor (for HID Interrupt Out Endpoint)"

The patch is linked below:

http://gnome.dnsalias.net/patches/qemu-hidmousexp.patch

^ permalink raw reply

* Re: Userland swsusp failure (mm-related)
From: Rafael J. Wysocki @ 2006-04-08 22:47 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Fabio Comolli, linux-kernel, Nick Piggin
In-Reply-To: <20060408161555.GA1722@elf.ucw.cz>

Hi,

On Saturday 08 April 2006 18:15, Pavel Machek wrote:
> > > This is my first (and unique) failure since I began testing uswsusp
> > > (2.6.17-rc1 version). It happened (I think) because more than 50% of
> > > physical memory was occupied at suspend time (about 550 megs out og
> > > 1G) and that was what I was trying to test. After freeing some memory
> > > suspend worked (there was no need to reboot).
> > 
> > Well, it looks like we didn't free enough RAM for suspend in this case.
> > Unfortunately we were below the min watermark for ZONE_NORMAL and
> > we tried to allocate with GFP_ATOMIC (Nick, shouldn't we fall back to
> > ZONE_DMA in this case?).
> > 
> > I think we can safely ignore the watermarks in swsusp, so probably
> > we can set PF_MEMALLOC for the current task temporarily and reset
> > it when we have allocated memory.  Pavel, what do you think?
> 
> Seems little hacky but okay to me.
> 
> Should not fixing "how much to free" computation to free a bit more be
> enough to handle this?

Yes, but in that case we'll leave some memory unused. ;-)

Rafael

^ permalink raw reply

* Re: 2.4.32: unresolved symbol unregister_qdisc
From: David S. Miller @ 2006-04-08 22:54 UTC (permalink / raw)
  To: gnychis; +Cc: linux-kernel, netdev
In-Reply-To: <32947.128.2.140.234.1144536454.squirrel@128.2.140.234>

From: "George P Nychis" <gnychis@cmu.edu>
Date: Sat, 8 Apr 2006 18:47:34 -0400 (EDT)

> Hey,
> 
> I have a kernel module that uses unregister_qdisc and register_qdisc, whenever i try to insert the module I get:
> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol unregister_qdisc
> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol register_qdisc
> 
> Am i missing some sort of support in the kernel?

Make sure CONFIG_NET_SCHED is enabled and that you compiled your module against
that kernel.

Where does this sch_xcp come from?  It's not in the vanilla sources.

Also, please direct networking questions to the netdev@vger.kernel.org
mailing list which I have added to the CC:.

^ permalink raw reply

* Re: Accessing physical memory
From: Arnd Bergmann @ 2006-04-08 23:07 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <200604082352.55490.antonio.dibacco@aruba.it>

On Saturday 08 April 2006 23:52, Antonio Di Bacco wrote:
> How can I access the physical memory? Can I MMAP for example /dev/mem? Is 
> there a simpler way?

/dev/mem access is the most simple way. A cleaner solution is usually to
write your own simple character device driver for the stuff you want to
access in memory.

Depending on why you want to access memory, slram may be the right
driver, e.g. when you want to store a file system there.

	Arnd <><

^ permalink raw reply

* Re: How to create independent branches
From: colin @ 2006-04-08 23:15 UTC (permalink / raw)
  To: peter.baumann; +Cc: git

  669  git-symbolic-ref HEAD refs/heads/slave
  670  echo "ref: refs/heads/master" > .git/HEAD
  671  git-symbolic-ref HEAD refs/heads/slave
  672  git add bar

> Another question. I'd like to create a totaly independent branch (like
> the "todo" branch in git). Is there a more user friendly way than doing
> 
> git-checkout -b todo
> rm .git/refs/heads/todo
> rm .git/index
> rm <all_files_in_your_workdir>
> 
> ... hack hack hack ...
> git-commit -a
> 
> I looked all over the docs, but can't find anything obvious.

If I undertstand, you basically want to create a second
initial commit, so you have two trees in your repository.

Well, an initial commit is just a commit object with no parents.

Try:
- Set up the workdir the way you want.  You have to git-add
  any newly added files, but git-update-index (called by
  git-commit -a) will remove from the index any files
  removed from the working directory, so you don't have to
  worry about those.
- Make sure refs/heads/todo doesn't exist
- "git-symbolic-ref HEAD refs/heads/todo"
  This makes HEAD a symlink (well, symref) to refs/heads/todo,
  which doesn't exist.
- git-commit -a
  Since the HEAD link doesn't exist, this does an initial
  commit.

It's not supremely user friendly, because multiple initial commits can
lead to problems down the road trying to merge, so you'd better know what
you're doing.

Another option is to just set up a second working directory, with a
shared object store, and do the checkin from there.  You can have the
.git/refs directories shared (via a symlink) or not.  If they're not
shared, you can later make them shared by copying over the relevant refs.


Oh, yes, note that if you fat-finger the "git-symbolic-ref HEAD" command,
any attempts to fix it will complain "not a git repository".
That's because a reference to refs/heads/ in HEAD is how git
identifies a repository.  "echo ref: refs/heads/master > .git/HEAD"
will fix it.

^ permalink raw reply

* Re: [linux-lvm] LVM over IP network
From: Sander Steffann @ 2006-04-08 23:19 UTC (permalink / raw)
  To: LVM general discussion and development
In-Reply-To: <1144412972.44365b2c36361@mail.sify.com>

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

Hi,
  I have 10 Dell workstation on a LAN. Each  workstation has 80
  GB hard drive. Two workstations consumed most of the disk space and
  remaining eight workstations still has plenty of disk space unused.

  ...

  What I want basically, if I could just collect those 800 GB
  excess space (not utilized) and assign it to the work stations starving
  for disk space. Is this achievable through LVM or EVMS?
I would never do something like this. You make each workstation dependent on all the other workstations. If one of them is turned off, crashes, dies, etc. your other workstations lose their data. Disks are cheap these days. Just buy an extra drive for the workstations that need it.

Good luck,
Sander

[-- Attachment #2: Type: text/html, Size: 1564 bytes --]

^ permalink raw reply

* Re: 2.4.32: unresolved symbol unregister_qdisc
From: George P Nychis @ 2006-04-08 23:18 UTC (permalink / raw)
  To: David S. Miller; +Cc: linux-kernel, netdev
In-Reply-To: <20060408.155430.111013393.davem@davemloft.net>

Yeah, this module is unfortunately not under the GPL, it was made for research and i am not the author, I was only given the code for my own research.

I enabled that support in the kernel, and then tried to recompile and get tons of errors/warnings... so maybe I am missing something else to be enabled in the kernel... here are a few examples of errors:
/usr/include/linux/skbuff.h:30:26: net/checksum.h: No such file or directory
/usr/include/asm/irq.h:16:25: irq_vectors.h: No such file or directory
/usr/include/linux/irq.h:72: error: `NR_IRQS' undeclared here (not in a function)
/usr/include/asm/hw_irq.h:28: error: `NR_IRQ_VECTORS' undeclared here (not in a function)

I think those are the top most errors, so if i can fix those hopefully the rest shall vanish!

- George


> From: "George P Nychis" <gnychis@cmu.edu> Date: Sat, 8 Apr 2006 18:47:34
> -0400 (EDT)
> 
>> Hey,
>> 
>> I have a kernel module that uses unregister_qdisc and register_qdisc,
>> whenever i try to insert the module I get: 
>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o:
>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol
>> unregister_qdisc /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o:
>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol
>> register_qdisc
>> 
>> Am i missing some sort of support in the kernel?
> 
> Make sure CONFIG_NET_SCHED is enabled and that you compiled your module
> against that kernel.
> 
> Where does this sch_xcp come from?  It's not in the vanilla sources.
> 
> Also, please direct networking questions to the netdev@vger.kernel.org 
> mailing list which I have added to the CC:.
> 
> 


-- 


^ permalink raw reply

* [Bug 6303] Fujitsu-Siemens P4 Amilo D 7830 laptop has no govenors with 2.6.16
From: bugme-daemon @ 2006-04-08 23:19 UTC (permalink / raw)
  To: cpufreq

http://bugzilla.kernel.org/show_bug.cgi?id=6303





------- Additional Comments From cbradney@zip.com.au  2006-04-08 16:19 -------
Seems to be back with 2.6.17rc1, although the minimum Mhz is now around 2333 
even with powersave governor active, max is 2666.600 (correct). The minimum 
with 2.6.15 and before used to be 333.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

^ permalink raw reply

* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-08 23:21 UTC (permalink / raw)
  To: alsa-devel


A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2008> 
======================================================================
Reported By:                mborsick
Assigned To:                tiwai
======================================================================
Project:                    ALSA - driver
Issue ID:                   2008
Category:                   PCI - hda-intel
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Distribution:               Redhat/Fedora
Kernel Version:             2.6.16-1.2080 and with Xen
======================================================================
Date Submitted:             04-07-2006 00:43 CEST
Last Modified:              04-09-2006 01:21 CEST
======================================================================
Summary:                    No Sound with snd-hda-intel driver Asus P5VDC-MX
Description: 
Kernel is up-to-date Xen kernel.

Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.

======================================================================

----------------------------------------------------------------------
 mborsick - 04-08-06 22:30 
----------------------------------------------------------------------
Been following this, but have been unable to jump in because of other IT
projects I am working on here. Do you want me to file this with the linnux
kernel folks?

----------------------------------------------------------------------
 buboleck - 04-09-06 01:21 
----------------------------------------------------------------------
:) yes please

Issue History
Date Modified  Username       Field                    Change              
======================================================================
04-07-06 00:43 mborsick       New Issue                                    
04-07-06 00:43 mborsick       Distribution              => Redhat/Fedora   
04-07-06 00:43 mborsick       Kernel Version            => 2.6.16-1.2080 and
with Xen
04-07-06 01:07 rlrevell       Note Added: 0009129                          
04-07-06 02:13 mborsick       Note Added: 0009130                          
04-07-06 02:35 rlrevell       Note Added: 0009131                          
04-07-06 06:38 mborsick       Note Added: 0009135                          
04-07-06 22:45 buboleck       Note Added: 0009156                          
04-07-06 22:47 buboleck       Note Edited: 0009156                         
04-07-06 22:49 buboleck       Note Edited: 0009156                         
04-07-06 23:06 rlrevell       Note Added: 0009157                          
04-07-06 23:16 buboleck       Issue Monitored: buboleck                    
04-07-06 23:26 buboleck       Note Added: 0009158                          
04-07-06 23:32 rlrevell       Note Added: 0009159                          
04-07-06 23:39 buboleck       Note Added: 0009160                          
04-07-06 23:40 buboleck       Note Edited: 0009160                         
04-07-06 23:43 buboleck       Note Edited: 0009160                         
04-07-06 23:46 buboleck       Note Edited: 0009160                         
04-07-06 23:47 rlrevell       Note Added: 0009161                          
04-07-06 23:52 buboleck       Note Added: 0009162                          
04-08-06 00:02 rlrevell       Note Added: 0009163                          
04-08-06 00:16 buboleck       Note Added: 0009164                          
04-08-06 00:19 buboleck       Note Added: 0009165                          
04-08-06 00:29 rlrevell       Note Added: 0009166                          
04-08-06 00:32 buboleck       Note Added: 0009167                          
04-08-06 00:41 rlrevell       Note Added: 0009168                          
04-08-06 00:42 buboleck       Note Added: 0009169                          
04-08-06 00:44 buboleck       Note Edited: 0009169                         
04-08-06 22:30 mborsick       Note Added: 0009173                          
04-09-06 01:21 buboleck       Note Added: 0009174                          
======================================================================




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

^ permalink raw reply

* Re: Userland swsusp failure (mm-related)
From: Con Kolivas @ 2006-04-08 23:24 UTC (permalink / raw)
  To: linux-kernel; +Cc: Rafael J. Wysocki, Pavel Machek, Fabio Comolli, Nick Piggin
In-Reply-To: <200604090047.17372.rjw@sisk.pl>

On Sunday 09 April 2006 08:47, Rafael J. Wysocki wrote:
> Hi,
>
> On Saturday 08 April 2006 18:15, Pavel Machek wrote:
> > > > This is my first (and unique) failure since I began testing uswsusp
> > > > (2.6.17-rc1 version). It happened (I think) because more than 50% of
> > > > physical memory was occupied at suspend time (about 550 megs out og
> > > > 1G) and that was what I was trying to test. After freeing some memory
> > > > suspend worked (there was no need to reboot).
> > >
> > > Well, it looks like we didn't free enough RAM for suspend in this case.
> > > Unfortunately we were below the min watermark for ZONE_NORMAL and
> > > we tried to allocate with GFP_ATOMIC (Nick, shouldn't we fall back to
> > > ZONE_DMA in this case?).
> > >
> > > I think we can safely ignore the watermarks in swsusp, so probably
> > > we can set PF_MEMALLOC for the current task temporarily and reset
> > > it when we have allocated memory.  Pavel, what do you think?
> >
> > Seems little hacky but okay to me.
> >
> > Should not fixing "how much to free" computation to free a bit more be
> > enough to handle this?
>
> Yes, but in that case we'll leave some memory unused. ;-)

How's the shrink_all_memory tweaks I sent performing for you Rafael? It may 
theoretically be prone to the same issue but I tried to make it less likely.

-- 
-ck

^ permalink raw reply

* [Qemu-devel] qemu/hw lance.c
From: Paul Brook @ 2006-04-08 23:32 UTC (permalink / raw)
  To: qemu-devel

CVSROOT:	/sources/qemu
Module name:	qemu
Branch: 	
Changes by:	Paul Brook <pbrook@savannah.gnu.org>	06/04/08 23:32:52

Modified files:
	hw             : lance.c 

Log message:
	Fix incorrect return type.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/lance.c.diff?tr1=1.6&tr2=1.7&r1=text&r2=text

^ permalink raw reply

* RE: [RFC] Hypercalls from HVM guests
From: Nakajima, Jun @ 2006-04-08 23:33 UTC (permalink / raw)
  To: Keir Fraser, Steve Ofsthun; +Cc: xen-devel

Keir Fraser wrote:
> On 7 Apr 2006, at 20:30, Steve Ofsthun wrote:
> 
>>> Actually, maybe using an unused index for CPUID (e.g. 0xb0000000)
>>> would be better? As that's defined to return all zero's, and not
>>> cause any traps whatever value you use (unless the CPU is so old
>>> that it doesn't support CPUID, of course).
>> 
>> This sounds encouraging, but is CPUID always trapped by the HVM code?
> 
> It can be, and in practise yes it is so this could work.
> 
>   -- Keir
> 
If eax is set to a value outside the recognized range of CPUID currently
defined, CPUID does not necessarily return all zero's on Intel. It's
"Reserved" (Information returned for highest basic information leaf).
Also "an unused index" can have conflicts in the future.

If we just need to tell on which CPU the current HVM guest is running, I
think "GeunineIntel" or "AuthenticAMD" is the best because it's been
used by native systems as well. 

Jun
---
Intel Open Source Technology Center

^ permalink raw reply

* Re: + git-klibc-mktemp-fix.patch added to -mm tree
From: Bodo Eggert @ 2006-04-08 23:34 UTC (permalink / raw)
  To: Sam Ravnborg, linux-kernel, akpm, hpa, mm-commits
In-Reply-To: <5Zs4F-ba-11@gated-at.bofh.it>

Sam Ravnborg <sam@ravnborg.org> wrote:
> On Sat, Apr 08, 2006 at 12:05:54AM -0700, akpm@osdl.org wrote:

>> diff -puN usr/dash/mkbuiltins~git-klibc-mktemp-fix usr/dash/mkbuiltins
>> --- 25/usr/dash/mkbuiltins~git-klibc-mktemp-fix      Sat Apr  8 14:51:11 2006
>> +++ 25-akpm/usr/dash/mkbuiltins      Sat Apr  8 14:51:11 2006

>> -    tempfile=mktemp
>> +    tempfile="mktemp /tmp/tmp.XXXXXX"
> 
> Shouldn't that be:
>> +    tempfile="$(mktemp /tmp/tmp.XXXXXX)"

No. You should use tempfile="$(mktemp ${TMPDIR:-/tmp}/tmp.XXXXXX)"
(or mktemp -t, if it's portable enough)

Besides that, tmp.XXXXXX should be replayed using a better name.

</nitpick>
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

^ permalink raw reply

* Re: 2.4.32: unresolved symbol unregister_qdisc
From: Randy.Dunlap @ 2006-04-08 23:37 UTC (permalink / raw)
  To: George P Nychis; +Cc: davem, linux-kernel, netdev
In-Reply-To: <33083.128.2.140.234.1144538327.squirrel@128.2.140.234>

On Sat, 8 Apr 2006 19:18:47 -0400 (EDT) George P Nychis wrote:

> Yeah, this module is unfortunately not under the GPL, it was made for research and i am not the author, I was only given the code for my own research.
> 
> I enabled that support in the kernel, and then tried to recompile and get tons of errors/warnings... so maybe I am missing something else to be enabled in the kernel... here are a few examples of errors:
> /usr/include/linux/skbuff.h:30:26: net/checksum.h: No such file or directory
> /usr/include/asm/irq.h:16:25: irq_vectors.h: No such file or directory
> /usr/include/linux/irq.h:72: error: `NR_IRQS' undeclared here (not in a function)
> /usr/include/asm/hw_irq.h:28: error: `NR_IRQ_VECTORS' undeclared here (not in a function)
> 
> I think those are the top most errors, so if i can fix those hopefully the rest shall vanish!

Looks like a Makefile problem then.  Can you post the Makefile?
Hopefully it is using a Makefile and not just an elaborate gcc command line.

[and please don't top-post]

> - George
> 
> 
> > From: "George P Nychis" <gnychis@cmu.edu> Date: Sat, 8 Apr 2006 18:47:34
> > -0400 (EDT)
> > 
> >> Hey,
> >> 
> >> I have a kernel module that uses unregister_qdisc and register_qdisc,
> >> whenever i try to insert the module I get: 
> >> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o:
> >> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol
> >> unregister_qdisc /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o:
> >> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol
> >> register_qdisc
> >> 
> >> Am i missing some sort of support in the kernel?
> > 
> > Make sure CONFIG_NET_SCHED is enabled and that you compiled your module
> > against that kernel.
> > 
> > Where does this sch_xcp come from?  It's not in the vanilla sources.
> > 
> > Also, please direct networking questions to the netdev@vger.kernel.org 
> > mailing list which I have added to the CC:.

---
~Randy

^ permalink raw reply

* Re: [PATCH 3/7] uts namespaces: use init_utsname when appropriate
From: Sam Vilain @ 2006-04-08 23:44 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Serge E. Hallyn, linux-kernel, Kirill Korotaev, herbert, devel,
	xemul, James Morris
In-Reply-To: <m1psjslf1s.fsf@ebiederm.dsl.xmission.com>

On Sat, 2006-04-08 at 01:09 -0600, Eric W. Biederman wrote:
> > -#define ELF_PLATFORM  (system_utsname.machine)
> > +#define ELF_PLATFORM  (init_utsname()->machine)
> >  
> >  #ifdef __KERNEL__
> >  #define SET_PERSONALITY(ex, ibcs2) do { } while (0)
> I think this one needs to be utsname()->machine.
> Currently it doesn't matter.  But Herbert has expressed
> the desire to make a machine appear like an older one.

This is extremely useful for faking it as "i386" on x86_64 systems, for
instance.

Sam.


^ permalink raw reply

* Masquerading problems - XenU 3.0 on x86_64
From: Jim Pick @ 2006-04-09  0:01 UTC (permalink / raw)
  To: xen-devel@lists.xensource.com; +Cc: netfilter-devel

Hi,

I'm trying to migrate my Xen sessions installed on 32-bit Xen 2.0 server 
to a 64-bit Xen 3.0 server.

On the Xen 2.0 server (32-bit), I built a DomU kernel with masquerading, 
and I use that to do NAT for some private networks running on the same 
box.

When I tried to do it with Xen 3.0 (64-bit), I couldn't get it to work. 
  I had to build a custom DomU kernel (from xen-3.0-testing.hg, 2.6.16, 
2 days ago) in order to include the netfilter/iptables code.  ICMP 
works.  TCP doesn't.  Non-masquerading traffic is OK.  I had the same 
problems with the 2.6.12 kernel from Xen 3.0.1.

I captured some of the traffic, and ethereal is showing that the 
masqueraded traffic being output has bad TCP checksums.

I'm going to have to do some debugging to try to figure out what's going 
wrong.

Has anybody else encountered this?  Also, if it's already been fixed 
somewhere, I'd love to know.  Any Netfilter debugging tips would also be 
appreciated.

Cheers,

  - Jim

^ permalink raw reply

* Make "--parents" logs also be incremental
From: Linus Torvalds @ 2006-04-09  0:05 UTC (permalink / raw)
  To: Junio C Hamano, Git Mailing List


The parent rewriting feature caused us to create the whole history in one 
go, and then simplify it later, because of how rewrite_parents() had been 
written. However, with a little tweaking, it's perfectly possible to do 
even that one incrementally.

Right now, this doesn't really much matter, because every user of 
"--parents" will probably generally _also_ use "--topo-order", which will 
cause the old non-incremental behaviour anyway. However, I'm hopeful that 
we could make even the topological sort incremental, or at least 
_partially_ so (for example, make it incremental up to the first merge).

In the meantime, this at least moves things in the right direction, and 
removes a strange special case.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/http-push.c b/http-push.c
index b60fa8d..57cefde 100644
--- a/http-push.c
+++ b/http-push.c
@@ -59,12 +59,12 @@ #define LOCK_REQUEST "<?xml version=\"1.
 #define LOCK_TIME 600
 #define LOCK_REFRESH 30
 
-/* bits #0-4 in revision.h */
+/* bits #0-6 in revision.h */
 
-#define LOCAL    (1u << 5)
-#define REMOTE   (1u << 6)
-#define FETCHING (1u << 7)
-#define PUSHING  (1u << 8)
+#define LOCAL    (1u << 7)
+#define REMOTE   (1u << 8)
+#define FETCHING (1u << 9)
+#define PUSHING  (1u << 10)
 
 /* We allow "recursive" symbolic refs. Only within reason, though */
 #define MAXDEPTH 5
diff --git a/rev-list.c b/rev-list.c
index 1301502..359195b 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -7,9 +7,9 @@ #include "blob.h"
 #include "tree-walk.h"
 #include "revision.h"
 
-/* bits #0-5 in revision.h */
+/* bits #0-6 in revision.h */
 
-#define COUNTED		(1u<<6)
+#define COUNTED		(1u<<7)
 
 static const char rev_list_usage[] =
 "git-rev-list [OPTION] <commit-id>... [ -- paths... ]\n"
diff --git a/revision.c b/revision.c
index ce35b5a..fe26562 100644
--- a/revision.c
+++ b/revision.c
@@ -340,6 +340,10 @@ static void add_parents_to_list(struct r
 {
 	struct commit_list *parent = commit->parents;
 
+	if (commit->object.flags & ADDED)
+		return;
+	commit->object.flags |= ADDED;
+
 	/*
 	 * If the commit is uninteresting, don't try to
 	 * prune parents - we want the maximal uninteresting
@@ -705,13 +709,6 @@ int setup_revisions(int argc, const char
 	if (revs->prune_data) {
 		diff_tree_setup_paths(revs->prune_data);
 		revs->prune_fn = try_to_simplify_commit;
-
-		/*
-		 * If we fix up parent data, we currently cannot
-		 * do that on-the-fly.
-		 */
-		if (revs->parents)
-			revs->limited = 1;
 	}
 
 	return left;
@@ -728,10 +725,12 @@ void prepare_revision_walk(struct rev_in
 					     revs->topo_getter);
 }
 
-static int rewrite_one(struct commit **pp)
+static int rewrite_one(struct rev_info *revs, struct commit **pp)
 {
 	for (;;) {
 		struct commit *p = *pp;
+		if (!revs->limited)
+			add_parents_to_list(revs, p, &revs->commits);
 		if (p->object.flags & (TREECHANGE | UNINTERESTING))
 			return 0;
 		if (!p->parents)
@@ -740,12 +739,12 @@ static int rewrite_one(struct commit **p
 	}
 }
 
-static void rewrite_parents(struct commit *commit)
+static void rewrite_parents(struct rev_info *revs, struct commit *commit)
 {
 	struct commit_list **pp = &commit->parents;
 	while (*pp) {
 		struct commit_list *parent = *pp;
-		if (rewrite_one(&parent->item) < 0) {
+		if (rewrite_one(revs, &parent->item) < 0) {
 			*pp = parent->next;
 			continue;
 		}
@@ -802,7 +801,7 @@ struct commit *get_revision(struct rev_i
 			if (!(commit->object.flags & TREECHANGE))
 				continue;
 			if (revs->parents)
-				rewrite_parents(commit);
+				rewrite_parents(revs, commit);
 		}
 		commit->object.flags |= SHOWN;
 		return commit;
diff --git a/revision.h b/revision.h
index 0caeecf..83d28d5 100644
--- a/revision.h
+++ b/revision.h
@@ -7,6 +7,7 @@ #define TREECHANGE	(1u<<2)
 #define SHOWN		(1u<<3)
 #define TMP_MARK	(1u<<4) /* for isolated cases; clean after use */
 #define BOUNDARY	(1u<<5)
+#define ADDED		(1u<<6)	/* Parents already parsed and added? */
 
 struct rev_info;
 

^ permalink raw reply related


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.