* Re: genirq vs. fastack
From: Benjamin Herrenschmidt @ 2006-05-31 9:11 UTC (permalink / raw)
To: tglx; +Cc: Ingo Molnar, Linux Kernel list
In-Reply-To: <1149064735.20582.85.camel@localhost.localdomain>
> I see your point, but isn't EOI the chip specific implementation of
> chip->ack() in that case ?
Not ack, end :)
The ack is implicit when retreiving the irq number (when the irq
happens), the register is even called the ack register :) the EOI isn't
ack'ing, it's really "end of interrupt", that is end of handling by the
processor, thus the CPU local priority can be lowered to what it was
when the interrupt happened.
> The intention was to get down to the chip primitives and away from the
> flow type chip->functions. Your patch would actually force the flow
> control part (if (!(desc->status & IRQ_DISABLED))) back into the end()
No. end() for mpic and xics will be the exact same one-liner. The whole
point is that on those chips, mask/unmask are completely disconnected
from the interrupt flow. Mask should happen when disable_irq() is called
wether the irq is in progress or not, independently, and thus the
handler shouldn't mask. Beside, eoi _must_ be called wether it was
masked in between or not or the controller will lose track.
> function for Ingo's x86 implementation. So the intended seperation of
> low level chip functions and flow control would be moot.
Nope. Both MPIC and xics will mask/unmask in ... mask() and unmask()
_and_ have a end() handler that does a EOI without testing if the irq
was disabled. There is no flow handling. That's the whole point of the
handler for "smart" controllers. Non smart controllers can use normal
flow handlers as far as I'm concerned.
Ben.
^ permalink raw reply
* Re: Question about tcp hash function tcp_hashfn()
From: David Miller @ 2006-05-31 9:12 UTC (permalink / raw)
To: johnpol; +Cc: draghuram, linux-kernel, netdev
In-Reply-To: <20060531090301.GA26782@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Wed, 31 May 2006 13:03:02 +0400
> Current simple XOR hash used in socket selection code is just bloody
> good! Jenkins hash unfortunately has _significant_ artefacts which
> were found in netchannel [1] hash selection analysis [2]. And
> Jenkins hash is far too slower.
Yes, it wins from a simplicity standpoint and it performs quite well.
It was tuned from real socket data sets, but from systems running many
many years ago :)
FreeBSD even adopted this hash into their PCB hashing code at one
point.
I think it will need to be changed nevertheless. Even though this
hash works on established sockets, it is attackable just like the
routing hash used to be. If an attacker has sufficient resources, he
can make hash chains in the TCP established hash table very long. As
the years pass, it becomes easier and easier for one to have enough
computing power at their disposal to carry out this kind of attack.
So something like Jenkins with a random hash input become more and
more critical. And this requires some kind of way to rehash, RCU
table locking opens the door for that. Current locking scheme is
too tightly bound for that kind of flexibility.
I wish Ben L. would resubmit the TCP hash locking stuff he said he'd
work on. :)
^ permalink raw reply
* Re: Need some help on dmraid RAID5
From: Heinz Mauelshagen @ 2006-05-31 9:09 UTC (permalink / raw)
To: device-mapper development
In-Reply-To: <A6A77F954AFACF42928F5E931ABDB18F481DB2@bgsmsx411.gar.corp.intel.com>
On Mon, May 29, 2006 at 04:19:55PM +0530, Srinivas, Vidya wrote:
> Hi,
Hi Vidya.
>
> I am checking dmraid functionality for RAID5 with 3 disks. I am using
> the latest available patch on
> http://people.redhat.com/heinzm/sw/dm/dm-raid45/
> I have some confusion in the same.
>
> The target length in the function raid_ctr in dm-raid4-5.c is being
> displayed to me as the smallest disk sectors.
No.
> However, I understand that
> the target length should be the total sectors (of all available disks)
> available for data (which in my case should be 2 disk sectors since 1
> disk sectors would be utilized for parity)
Yes, it's 'number of disks - 1' with a minimum of 3 disks.
>
> What I understand is, in the user level dmraid, in
> lib/activate/activate.c, under dm_raid45, sectors value is calculated
> by:
>
> Sectors = _smallest(lc,rs,0)
>
> And, the same sectors value is passed to _dm_raid45_bol.
>
> Whatever goes from this _dm_raid45_bol directly goes to the kernel
> dm-raid4-5.c and under raid_ctr gets printed as ti->len right? So, the
> smallest sectors (of all the devices) goes to ti->len. In my case also,
> the smallest disk sectors is being printed as ti->len and not the total
> data sectors. Am I wrong?
If so, it would be wrong.
The _smallest() calculation identifies the smallest of the deveices
in a RAID set in order to make up sane mappings (i.e. all disks mapped
to in a target line must have this minumum size).
>
>
> Also, I had another doubt in dm-raid4-5.c, under static struct raid_type
> raid_types[], values for raid5_ls is:
>
> {Raid5_ls. "RAID5 (left symmetric), 1, 3, raid5, left_sym}, where the
> number of parity devices (being the 3rd parameter) is taken as 1.
Well, that number indicates the capacity being used for parity chunks
(i.e. 1 device).
>
> But, I feel, since there isn't any dedicated parity device for RAID5,
> shouldn't this be taken as 0. When I take this as 1, I am getting the
> error, target length not divisable by number of devices.
Can you send me your metadata (files created by 'dmraid -rD', tar'ed/bzip2'ed
into Srinivas_Vidya-raid5.tar.bz2), please.
>
> When I take it as 0, my RAID volume is being created and things seem to
> work.
Strange. Will lokk into this once I got your metadata.
>
> Any suggestions would be helpful
>
> Thanks
> Vidya
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
--
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Red Hat GmbH
Consulting Development Engineer Am Sonnenhang 11
Storage Development 56242 Marienrachdorf
Germany
Mauelshagen@RedHat.com PHONE +49 171 7803392
FAX +49 2626 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply
* Re: RAID-1 and Reiser4 issue: umount hangs
From: Arend Freije @ 2006-05-31 9:06 UTC (permalink / raw)
To: Alexander Zarochentsev
Cc: reiserfs-list, E.Gryaznova, Vladimir Saveliev, Hans Reiser
In-Reply-To: <200605311113.48131.zam@namesys.com>
Alexander Zarochentsev wrote:
> On Tuesday 30 May 2006 23:20, Arend Freije wrote:
>
>> Alexander Zarochentsev wrote:
>>
>>> Hello,
>>>
>>> On Tuesday 30 May 2006 00:17, Arend Freije wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm using Reiser4 for my filesystems on disk (/dev/sda) , and it
>>>> works just fine. Recently I bought a second disk (/dev/sdb) for
>>>> RAID-1 mirroring. With mdadm I created a degraded raid-1 array on
>>>> /dev/md/0, devices missing,/dev/sdb1. After that I created a
>>>> Reiser4 filesystem on /dev/md/0 and mounted it at /mnt. Then I
>>>> copied the data from /dev/sda1 to /mnt.
>>>>
>>> would it work better with "no_write_barrier" mount option?
>>>
>> It would indeed. What's the purpose of this option?
>>
>
> It disables write barrier support in reiser4 which may be buggy. It is
> not necessary that reiser4 code has a bug, but the elevator, md device
> or disk driver code.
>
Alexander,
You're probably right. I found several posts on the linux-kernel list
involving problems with write barrier support in combination with SATA
and ext3 . So I tried:
# mkfs -t ext3 /dev/md/0
# mount -o barrier=1 /dev/md/0 /mnt
# cp -a $src /mnt
# umount /mnt
And indeed, umount hangs now as well.
So it seems to be a linux-kernel issue after all...
If write-barrier support is a known problem, wouldn't it be better to
disable it in the Reiser4 driver by default, as in the ext3-driver ?
Kind Regards,
Arend Freije
^ permalink raw reply
* Re: Re: printk on framebuffer console
From: Geert Uytterhoeven @ 2006-05-31 9:05 UTC (permalink / raw)
To: Linux Fbdev development list; +Cc: Terence Soh
In-Reply-To: <447D189C.1010100@gmail.com>
On Wed, 31 May 2006, Antonino A. Daplas wrote:
> Terence Soh wrote:
> >>> Are xxxfb_setcolreg function() and info->pseudo_palette necessary for
> >>> FB_VISUAL_TRUECOLOR? I thought it's required for FB_VISUAL_PSEUDOCOLOR.
> >>>
> >>
> >>
> >> Other way around, the info->pseudo_palette is needed for truecolor and
> >> directcolor. So fill this array properly, and you should be good to go.
> >> Look at any driver (ie vesafb.c) on how it's done.
> >>
> > Thanks Tony,
> >
> > Turned out that I was missing the xxxfb_setcolreg function() and
> > info->pseudo_palette. Once that's done, the console is appearing on the
> > framebuffer.
> >
> > Another question. The console only prints starting from the scripts in
> > /etc/init.d/rcS , the printk messages from the various drivers are
> > missing. My kernel command line is "console=ttyS0 root=/dev/mtdblock3
> > rootfstype=jffs2". Is there any reason why?
>
> Remove the console=ttyS0 from your boot parameter (or change it to tty0)
> and the system messages should go to the framebuffer console.
Or use `console=ttyS0 console=tty0' to get kernel messages on both.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
^ permalink raw reply
* Re: Question about tcp hash function tcp_hashfn()
From: Evgeniy Polyakov @ 2006-05-31 9:03 UTC (permalink / raw)
To: David Miller, draghuram, linux-kernel, netdev
In-Reply-To: <20060531020009.A1868@openss7.org>
On Wed, May 31, 2006 at 02:00:09AM -0600, Brian F. G. Bidulock (bidulock@openss7.org) wrote:
> > For sure and there are plans afoot to move over to
> > dynamic table sizing and the Jenkins hash function.
>
> Yes, that could be far more efficient.
In theory practice and theory are the same, but in practice they are
different.
Current simple XOR hash used in socket selection code is just bloody good!
Jenkins hash unfortunately has _significant_ artefacts which were found
in netchannel [1] hash selection analysis [2].
And Jenkins hash is far too slower.
1. Netchannel.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=netchannel
2. Compared Jenkins hash with XOR hash used in TCP socket selection
code.
http://tservice.net.ru/~s0mbre/blog/2006/05/14#2006_05_14
--
Evgeniy Polyakov
^ permalink raw reply
* RE: VMX Assist and x86 segment registers
From: Petersson, Mats @ 2006-05-31 9:02 UTC (permalink / raw)
To: Randy Thelen, xen-devel
In-Reply-To: <73055A70-2CEB-4E3A-AD17-252DF3F2666B@netapp.com>
Randy,
There are several places in Xen where the weirdness of using protected
mode segments in real mode or the other way around break things. I can't
comment on the validity of your fix as such - but here's a few comments
on the COMMENT of the segment data:
Since you've set the granularity bit to 1 -> 4KB "steps" in limit (the
top bit of c in 00cf92), I think you'll find that the first 4GB of RAM
is accessible, since you've also set the upper bits of the twenty-bit
segment limit (the F in the snippet of segment data above), the segment
limit being 0xfffff << 12 + 0xfff -> 0xffffffff == 0-(4GB-1).
Also, it's not a code-segment (or you've have the top bit in the nibble
that is now 2 in the cf92 bits), but a data-segment, so you have 32-bit
DATA in the segment, not 32-bit code
You may as well set the accessed bit - no one cares about it, but it
saves a write to the segment descriptor when it becomes accessed the
first time... It used to be important in 16-bit segmented mode, where
segments could be swapped out (before paging became available - this is
what the Present bit is for, and of course, if you have a segment that
hasn't been accessed for a while, that would be a good candidate for
chucking out to disk, if other segments need to be brought into RAM...
OS/2 1.x would have used this for "virtual" memory support...)
You can't tell that I've struggled with segments just a few times
before, can you? ;-)
--
Mats
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of
> Randy Thelen
> Sent: 31 May 2006 07:42
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] VMX Assist and x86 segment registers
>
> Executive summary --
>
> If you're interested in running FreeBSD in an HVM domain on
> VT-x hardware, please EXPERIMENT with the attached patch.
> However, the patch is not in and of itself a fix. I'm simply
> looking for more help on solving this bigger problem and
> pushing the patch to the Xen community is the best way I
> could think of to get more insight into the problem.
>
> If you're still interested, please continue reading.
>
> Folks --
>
> Here's an esoteric topic: x86 segment registers and their
> emulation with vmxassist. Anybody interested in engaging in
> this one? ;-)
>
> Here's the story. FreeBSD doesn't boot on Intel processors
> with VT-x hardware in an HVM domain. It turns out I'm
> dependent upon that functionality. So, I began to
> investigate. Dragons lie in them thar hills. (Snakes,
> spiders, whatever: I -hate- segmentation and I -
> hate- segment registers. So you can imagine the frustration
> I had as I realized I needed to become intimately familiar
> with them to solve my problem.)
>
> Here's the deal, the x86 processor allows segment registers
> to be set in one mode (e.g., "real mode") and the used in
> another mode (e.g., "protected mode"). For an example of how
> this trick is utilized, peruse subject 15: Accessing 4 Gigs
> of Memory in Real Mode:
>
> http://www.cs.uu.nl/wais/html/na-dir/assembly-language/x86/general/
> part2.html
>
> (Be prepared to be completely disgusted.)
>
> At any rate, between my own debugging and reading articles of
> the sort above, I realized that vmxassist was incorrectly
> handling segment registers.
>
> I've made a patch that I've attached but I am -NOT-
> recommending this for general consumption. This patch is
> -ONLY- recommended for those who want to run FreeBSD on VT-x
> hardware and those who are willing to work through additional
> bugs to solve interesting problems. (If you have an interest
> in running other OSes on VT-x hardware, you're free to try
> the patch, but I can't say that I'll spend much time trying
> to solve the problems you bump into.)
>
> I believe that the current handling of segment registers in
> vmxassist
> isn't quite right. A more complicated model needs to be developed.
> I'm not sure exactly how different it needs to be or exactly
> in what ways it needs to be modified.
>
> But, if this topic interests you, I'd be interested in
> continuing this discussion.
>
> Once you apply the patch, you'll need to perform a make in
> the xen/ tools/firmware directory. That will cause a new
> hvmloader to be constructed. You can either install it (I
> don't recommend it) or you can modify your configuration
> file(s) so that the "kernel" is this new hvmloader file:
>
> kernel = "/usr/src/xen-3.0-testing/tools/firmware/hvmloader/hvmloader"
>
> If you've read this far, you might take interest in rereading
> my post on this problem:
>
> http://lists.xensource.com/archives/html/xen-devel/2006-05/msg
> 01300.html
>
> -- Randy Thelen
>
^ permalink raw reply
* Re: dm-linear error: Device lookup failed
From: Heinz Mauelshagen @ 2006-05-31 9:02 UTC (permalink / raw)
To: device-mapper development; +Cc: hjm
In-Reply-To: <1149041704.31267.25.camel@solid.brisbane.redhat.com>
On Wed, May 31, 2006 at 12:15:04PM +1000, Mark Huth wrote:
> Thanks for the reply Heinz,
>
> I have to admit that I am a complete noob when when it comes to
> understanding how device-mapper works and the documentation I've read
> doesn't shed much light either I'm afraid.
Could be that you've got outdated LVM metadata on the devices still.
You can check with the LVM 'pvs' command, if that's the case.
If you don't want that metadata, use pvremove to get rid of it.
Heinz
>
> > Mark,
> >
> > you're saying, the system is wotking properly, but without the respecive
> > mapping tables it's hard to tell if there's a hidden issue.
> >
> > The message shows, that device-mapper is unable to discover 2 devices
> > while loading (a) mapping table(s).
> >
>
> The machine indeed has 2 IDE disks. I am wondering how I can prevent
> this error message from occuring? It sounds like something is wrong
> even though there doesn't seem to be (but is there really?).
>
> Thanks,
> Mark
>
> > On Tue, May 23, 2006 at 08:57:45AM +1000, Mark Huth wrote:
> > > Hi,
> > > I am encountering the following error/message whilst the machine is
> > > booting up:
> > >
> > > kernel: device-mapper: 4.5.0-ioctl (2005-10-04) initialised: dm-
> > > devel redhat com
> > > kernel: device-mapper: dm-linear: Device lookup failed
> > > kernel: device-mapper: error adding target to table
> > > kernel: device-mapper: dm-linear: Device lookup failed
> > > kernel: device-mapper: error adding target to table
> > > kernel: cdrom: open failed.
> > > last message repeated 2 times
> > >
> > > I am not using LVM (just a bunch of raid0 partitions) so it seems that
> > > this error is more informational rather than a sign of possible
> > > problems, and the system seems to otherwise be functioning normally. So
> > > I was wondering if anyone on this list can confirm that it is nothing to
> > > worry about and if there a way to make the system happy to prevent this
> > > message from showing up. I am using RHEL4U3 (kernel 2.6.9-34.EL).
> > >
> > > Thanks,
> > > Mark
> > >
> > > --
> > > dm-devel mailing list
> > > dm-devel redhat com
> > > https://www.redhat.com/mailman/listinfo/dm-devel
> >
> > --
> >
> > Regards,
> > Heinz -- The LVM Guy --
> >
> > *** Software bugs are stupid.
> > Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Red Hat GmbH
Consulting Development Engineer Am Sonnenhang 11
Storage Development 56242 Marienrachdorf
Germany
Mauelshagen@RedHat.com PHONE +49 171 7803392
FAX +49 2626 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply
* Re: Question about tcp hash function tcp_hashfn()
From: David Miller @ 2006-05-31 9:02 UTC (permalink / raw)
To: bidulock; +Cc: draghuram, linux-kernel, netdev
In-Reply-To: <20060531024954.A2458@openss7.org>
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
Date: Wed, 31 May 2006 02:49:54 -0600
> This would be faster than a Jenkins hash approach because it
> would not be necessary to calculate the hash function at all for
> in-window segments. Per packet overheads would decrease and
> better small packet performance would be experienced (i.e. your
> http server). It has better hash coverage because MD4 and other
> cryptographic algorithms used for initial sequence number
> selection have far better properties than Jenkins.
>
> What do you think?
I don't know how practical this is. The 4GB sequence space
wraps very fast on 10 gigabit, so we'd be rehashing a bit
and 100 gigabit would make things worse whenever that shows
up.
It is, however, definitely an interesting idea.
We also need the pure traditional hashes for net channels. I don't
see how we could use your scheme for net channels, because we are just
hashing in the interrupt handler of the network device driver in order
to get a queue to tack the packet onto, we're not interpreting the
sequence numbers and thus would not able to maintain the sequence
space based hashing state.
On a 3ghz cpu, the jenkins hash is essentially free. Even on slower
cpus, jhash_2words for example is just 20 cycles on a sparc64 chip.
It's ~40 integer instructions and they all pair up perfectly to
dual issue. We'd probably use jhash_3words() for TCP ipv4 which
would get us into the 30 cycle range.
A few years ago when I introduced jenkins into the tree, I thought
it's execution cost might be an issue. I really don't anymore.
^ permalink raw reply
* Re: configure host and target
From: Tomáš Ebenlendr @ 2006-05-31 8:59 UTC (permalink / raw)
To: The development of GRUB 2
In-Reply-To: <200605310302.20147.okuji@enbug.org>
So if I understand it correctly:
Grub & modules (i.e., everything that is run w/o OS) is target.
Grub-emu (i.e., everythhing that is run in some OS) is host.
We don't have "make-tools" in c-code nor asm. (This is host in
some projects:
tools that are first compiled and then used while compiling another
parts)
On 31 Květen 2006, 3:02, Yoshinori K. Okuji napsal(a):
> I describe the new build system a bit here. Maybe this should be written
> in
> somewhere else (such as INSTALL) as well...
>
> GRUB uses "target" and "host". "build" is not explicitly used. A target
> represents a native environment where GRUB runs. In reality, the target
> type
> affects:
>
> - the cpu type
>
> - the executable format (for now, must be ELF)
>
> The vendor and the operating system in a target type does not really
> matter,
> except for the choice of programs and supported executable formats,
> because
> you should specify a platform (such as firmware) by --with-platform to
> configure.
>
> A host type specifies an environment where utilities are executed. Unless
> you
> are cross-compiling GRUB, you do not have to care very much.
>
> The usage of compiler flags is the following:
>
> - CC, CFLAGS, CPPFLAGS, ASFLAGS and LDFLAGS are used for the host type.
>
> - If you need to specify non-standard locations for header files or
> libraries,
> you should specify CPPFLAGS or LDFLAGS.
>
> - If you cross-compile GRUB, you can set CC explicitly, but optionally.
>
> - You do not need to struggle with CFLAGS or ASFLAGS. This is required
> only if
> you intend to debug GRUB, or you want to optimize GRUB differently for an
> unknown reason.
>
> - TARGET_CC, TARGET_CFLAGS, TARGET_CPPFLAGS, TARGET_ASFLAGS and
> TARGET_LDFLAGS
> are used for the target type.
>
> - You might need to specify TARGET_CC explicitly, if you cross-compile
> GRUB.
>
> - You should not touch other TARGET_* variables, unless you understand
> what
> you are doing.
>
> Besides these flags, GRUB uses target-specific flags (here, "target" means
> a
> Makefile target, but not a target type in autoconf). This allows us to
> apply
> flags specific to each object. This design is based on automake, since the
> makefile generator in GRUB was influenced by automake significantly.
>
> For example, when compiling normal.mod, normal_mod_CFLAGS,
> normal_mod_LDFLAGS,
> etc. are applied as well as TARGET_CFLAGS, TARGET_LDFLAGS, etc. This part
> is
> important only for developers, as the user is not supposed to tweak these
> target-specific flags manually.
>
> Okuji
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
--
Tomas 'Ebi' Ebenlendr
http://get.to/ebik
^ permalink raw reply
* Re: reiser4 for 2.6.16 (version 3)
From: mail @ 2006-05-31 8:54 UTC (permalink / raw)
To: Vladimir V. Saveliev; +Cc: Alexander Zarochentsev, reiserfs-list
In-Reply-To: <1149003085.6590.37.camel@tribesman.namesys.com>
Already. All fine :)
On Tue, 30 May 2006 19:31:25 +0400
"Vladimir V. Saveliev" <vs@namesys.com> wrote:
> Hello
>
> On Tue, 2006-05-30 at 17:49 +0400, mail@viliar.net.ru
> wrote:
> > #cd /usr/src/linux-std
> > #make clean
> > #gzip -dc ../reiser4-for-2.6.16-3.patch.gz | patch -p1
> > --silent
> > #make all
> > #make modules_install
> > ---cut---
> > if [ -r System.map -a -x /sbin/depmod ]; then
> /sbin/depmod
> > -ae -F System.map 2.6.16.18; fi
> > WARNING:
> > /lib/modules/2.6.16.18/kernel/fs/reiser4/reiser4.ko
> needs
> > unknown symbol balance_dirty_pages
> > WARNING:
> > /lib/modules/2.6.16.18/kernel/fs/reiser4/reiser4.ko
> needs
> > unknown symbol page_cache_readahead
> > make: *** [_modinst_post] Ошибка 1
> >
>
> thanks, please try that
>
ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/reiser4-for-2.6.16-4.patch.gz
>
>
> > # uname -a
> > Linux losthold.vs 2.6.16.18 #12 PREEMPT Mon May 29
> 21:43:25
> > MSD 2006 i686 AMD Athlon(tm) unknown GNU/Linux
> > # gcc -v
> > Using built-in specs.
> > Target: i586-mandriva-linux-gnu
> > Configured with: ../configure --prefix=/usr
> > --libexecdir=/usr/lib --with-slibdir=/lib
> > --mandir=/usr/share/man --infodir=/usr/share/info
> > --enable-shared --enable-threads=posix
> --disable-checking
> > --enable-languages=c,c++,ada,f95,objc,java
> > --host=i586-mandriva-linux-gnu --with-system-zlib
> > --enable-long-long --enable-__cxa_atexit
> > --enable-clocale=gnu --disable-libunwind-exceptions
> > --enable-java-awt=gtk
> >
> --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
> > --enable-gtk-cairo --disable-libjava-multilib
> > Thread model: posix
> > gcc version 4.0.1 (4.0.1-5mdk for Mandriva Linux
> release
> > 2006.0)
> >
> > reiser4-for-2.6.16-2.patch.gz -- compile and install
> > without this problem.
> >
> >
> >
> >
> > On Tue, 30 May 2006 15:54:35 +0400
> > Alexander Zarochentsev <zam@namesys.com> wrote:
> > > On Monday 29 May 2006 21:30, Vladimir V. Saveliev
> wrote:
> > > > Hello
> > > >
> > > >
> > >
> >
>
ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.16/reiser4-for-2.6.16-3
> > > >.patch.gz contains the most recent reiser4 code
> which is
> > > considered
> > > > stable inside Namesys. This code is supposed to be
> in
> > > mm kernel next
> > > > to 2.6.17-rc4-mm3.
> > > >
> > > > Please try it. Any feedback is welcome.
> > >
> > >
> > > it works on the Cuba server.
> > >
> > > uptime is
> > > 3:54pm up 5:25, 2 users, load average: 0,00,
> 0,00,
> > > 0,00
> > >
> > > >
> > > >
> > >
> > > --
> > > Alex.
> >
> >
> > A.
> >
> > --------------
> >
> > "Hic Jacet Ego"
> >
>
A.
--------------
"Hic Jacet Ego"
^ permalink raw reply
* Re: Question about tcp hash function tcp_hashfn()
From: Brian F. G. Bidulock @ 2006-05-31 8:49 UTC (permalink / raw)
To: David Miller; +Cc: draghuram, linux-kernel, netdev
In-Reply-To: <20060531.004953.91760903.davem@davemloft.net>
David,
On Wed, 31 May 2006, David Miller wrote:
>
> For sure and there are plans afoot to move over to
> dynamic table sizing and the Jenkins hash function.
Just a suggestion, but I have an approach that stands to be
faster than Jenkins deriving from the verification tag approach
that I took for SCTP (OpenSS7 SCTP not lksctp).
TCP uses a cryptographic hash function to select its initial
sequence number (SCTP does the same for vtag). Last I checked
it was taken from an MD4 swirled entropy pool and further
combined with the local and remote IP addresses and port
numbers.
Each received segment contains a sequence number that is offset
from the initial sequence number but is expected to appear
within the current window. Most of the high order bits of an
in-window sequence number are predicatable at any point in time
and, due to cryptographic strength, are more efficient than
Jenkins, ... and they are right there in the received packet.
The approach would take the high order bits of the received
sequence number and use them to index a separate sequence number
keyed established hash (which could be dynamic). As the window
changes, the socket would have to be removed and reinserted into
this hash, but the repositioning would be infrequent. Out of
window segments would fail to find a socket, but could fall back
to the current established hash, or even the bind hash. A layer
of caching could increase the hash lookup speed further for
noisy senders.
This would be faster than a Jenkins hash approach because it
would not be necessary to calculate the hash function at all for
in-window segments. Per packet overheads would decrease and
better small packet performance would be experienced (i.e. your
http server). It has better hash coverage because MD4 and other
cryptographic algorithms used for initial sequence number
selection have far better properties than Jenkins.
What do you think?
^ permalink raw reply
* kernel reports kernel bug when trying to start kaddressbook
From: Noel @ 2006-05-31 8:44 UTC (permalink / raw)
To: linux-kernel
May 31 09:19:01 padoc kernel: [17232590.616000] ------------[ cut here
]------------
May 31 09:19:01 padoc kernel: [17232590.616000] kernel BUG at mm/swap.c:52!
May 31 09:19:01 padoc kernel: [17232590.616000] invalid opcode: 0000 [#4]
May 31 09:19:01 padoc kernel: [17232590.616000] Modules linked in:
usbcore autofs4 via_rhine 8139too crc32
May 31 09:19:01 padoc kernel: [17232590.616000] CPU: 0
May 31 09:19:01 padoc kernel: [17232590.616000] EIP:
0060:[<c013d925>] Tainted: G M VLI
May 31 09:19:01 padoc kernel: [17232590.616000] EFLAGS: 00210246
(2.6.16.4+20060419.padoc.envite #1)
May 31 09:19:01 padoc kernel: [17232590.616000] EIP is at put_page+0x25/0x40
May 31 09:19:01 padoc kernel: [17232590.616000] eax: 00000002 ebx:
cea51664 ecx: 00016325 edx: c12c64a0
May 31 09:19:01 padoc kernel: [17232590.616000] esi: 08199000 edi:
c12c64a0 ebp: ca329e20 esp: ca329d88
May 31 09:19:01 padoc kernel: [17232590.616000] ds: 007b es: 007b
ss: 0068
May 31 09:19:01 padoc kernel: [17232590.616000] Process kaddressbook
(pid: 10310, threadinfo=ca328000 task=cbc5d090)
May 31 09:19:01 padoc kernel: [17232590.616000] Stack: <0>c01424a8
c12c64a0 08199000 16325045 16325045 fffffec1 00000000 cea48e40
May 31 09:19:01 padoc kernel: [17232590.616000] 082b0000 cea49080
082b0000 ca329e20 c0142623 c03c5bac c4097a14 cea49080
May 31 09:19:01 padoc kernel: [17232590.616000] 08053000 082b0000
ca329e20 00000000 082affff cea49080 cea49080 c4097a14
May 31 09:19:01 padoc kernel: [17232590.616000] Call Trace:
May 31 09:19:01 padoc kernel: [17232590.616000] [<c01424a8>]
zap_pte_range+0x178/0x230
May 31 09:19:01 padoc kernel: [17232590.616000] [<c0142623>]
unmap_page_range+0xc3/0x130
May 31 09:19:01 padoc kernel: [17232590.616000] [<c014277b>]
unmap_vmas+0xeb/0x1a0
May 31 09:19:01 padoc kernel: [17232590.616000] [<c01470eb>]
exit_mmap+0x6b/0xf0
May 31 09:19:01 padoc kernel: [17232590.616000] [<c011789c>]
mmput+0x2c/0x80
May 31 09:19:01 padoc kernel: [17232590.616000] [<c015dafe>]
exec_mmap+0xae/0x140
May 31 09:19:01 padoc kernel: [17232590.616000] [<c015e1ab>]
flush_old_exec+0x4b/0x230
May 31 09:19:01 padoc kernel: [17232590.616000] [<c015da40>]
kernel_read+0x50/0x60
May 31 09:19:01 padoc kernel: [17232590.616000] [<c017ca6f>]
load_elf_binary+0x32f/0xd50
May 31 09:19:01 padoc kernel: [17232590.616000] [<c013ad0e>]
__alloc_pages+0x5e/0x310
May 31 09:19:01 padoc kernel: [17232590.616000] [<c01c6a8c>]
copy_from_user+0x4c/0xc0
May 31 09:19:01 padoc kernel: [17232590.616000] [<c015d58d>]
copy_strings+0x1dd/0x230
May 31 09:19:01 padoc kernel: [17232590.616000] [<c015e5ed>]
search_binary_handler+0x5d/0x1b0
May 31 09:19:01 padoc kernel: [17232590.616000] [<c015e8c0>]
do_execve+0x180/0x200
May 31 09:19:01 padoc kernel: [17232590.616000] [<c0101932>]
sys_execve+0x42/0x80
May 31 09:19:01 padoc kernel: [17232590.616000] [<c0102bbb>]
sysenter_past_esp+0x54/0x75
May 31 09:19:01 padoc kernel: [17232590.616000] Code: bc 27 00 00 00 00
8b 54 24 04 8b 02 f6 c4 40 75 24 8b 42 04 40 74 14 83 42 04 ff 0f 98 c0
84 c0 75 02 90 c3 89 d0 e9 ab 02 00 00 <0f> 0b 34 00 f9 eb 2f c0 eb e2
eb 8f eb 0d 90 90 90 90 90 90 90
May 31 09:19:01 padoc kernel: [17232590.616000] <6>note:
kaddressbook[10310] exited with preempt_count 1
^ permalink raw reply
* [U-Boot-Users] USB OHCI drivers unification
From: Markus Klotzbücher @ 2006-05-31 8:43 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060530145421.GU21995@enneenne.com>
Hi Rodolfo,
Rodolfo Giometti <giometti@linux.it> writes:
> may I know what you have already done on this topic?
Sure. I basically took the same approach as you suggested in your
previous mail, but have split the the lowlevel functions into board and
cpu dependant handling. I think this makes sense as boards for example
can use the same cpu ohci controller but may require specific board
dependant power settings. Either can be chosen by defining
CFG_USB_OHCI_BOARD_INIT and CFG_USB_OHCI_CPU_INIT respectively.
I also discovered that the actions taken in case of failure sometimes
differ from those to stop the controller, so I added the fail functions.
So I ended up with these hooks:
usb_cpu_init
usb_cpu_stop
usb_cpu_fail
usb_board_init
usb_board_stop
usb_board_fail
I have currently adapted the monahans, the at91rm9200, and the s3c24x0
cpus to use the generic driver. Please note that I used the
cpu/arm920t/at91rm9200/usb_ohci.[hc] driver as a starting point for the
generic driver.
We are currently starting a new USB testing branch for testing these and
other USB related changes, which should be available in the git repo
soon.
> Please take a look at my patch to enable USB OHCI support on AU1x00
> CPUs; in fact the problem was about virtual and physical addresses on
> MIPS platforms. For ARM platforms you may define as void the functions
> "virt_to_phys()" and phys_to_virt() but for MIPS are essential.
Your patch looks fine, but would you mind resubmitting it against the
USB testing branch using the generic driver (drivers/usb_ohci.c) ?
Thank you!
Regards
Markus Klotzb?cher
^ permalink raw reply
* Re: [patch 00/61] ANNOUNCE: lock validator -V1
From: Ingo Molnar @ 2006-05-31 8:40 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Roland Dreier, Dave Jones, Dominik Brodowski, Arjan van de Ven,
Andrew Morton, linux-kernel, Michal Piotrowski, nanhai.zou
In-Reply-To: <4d8e3fd30605301458h33fc5e47t5c6f35bc08f2b545@mail.gmail.com>
* Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> GTK? A typo, I suppose.
brainfart, sorry :)
> QGit is a git GUI viewer built on Qt/C++ (that I hope will be added to
> the git.git tree soon).
yeah.
Ingo
^ permalink raw reply
* Re: linux-2.6 x86_64 kgdb issue
From: Piet Delaney @ 2006-05-31 8:39 UTC (permalink / raw)
To: Andi Kleen
Cc: Piet Delaney, Amit S. Kale, Vladimir A. Barinov, Andrew Morton,
kgdb-bugreport, trini, linux-kernel
In-Reply-To: <200605310913.54758.ak@suse.de>
On Wed, 2006-05-31 at 09:13 +0200, Andi Kleen wrote:
> On Wednesday 31 May 2006 08:46, Piet Delaney wrote:
> > On Wed, 2006-05-31 at 07:50 +0200, Andi Kleen wrote:
> > > > Perhaps we should add a kgdb config menu option and #define
> > > > CONFIG_16KSTACKS to double the stack size so the kernel can be
> > > > debugged with more context available. I'm currently using -O0 for
> > > > the networking stack and -O1 for the rest of the kernel. Sounds like
> > > > it would be helpful now for AMD64 targets.
> > >
> > > You only got stack overflows when working with kgdb right?
> >
> > Yes, I was using kgdb to look at the stack audits I stored in
> > the thread structure.
>
> Again this likely points to kgdb using too much stack.
My bet is that in this case I was storing a LOT of
data in the thread structure, so the space left for
the stack was massively reduced.
I was using a debugging tool for taking snapshots of the
top 16 PC's on the stack when you take a spinlock; for
each premption level. It's thread specific data, so the
thread structure seemed like a reasonable place to store it.
>
>
> > > Sounds like a kgdb problem to me then that can and should be probably fixed. e.g.
> > > afaik kgdb isn't reentrant anyways so it could just use static buffers.
> >
> > On Solaris the problem was that the kernel stack was larger because tail
> > optimization was disabled with optimization disabled. I'm not having
> > a kgdb problem with i386, it seems that Vladimir is/was and Amit
> > suspected it being due to the AMD64 requiring largers stacks. Seems
> > plausible to me. I thought you might have thoughts on that.
>
> Stack usage in Linux isn't that tight that it should make a difference.
> If something needs too much stack we just fix it.
>
> > >
> > > I would suggest against adding any new config options for this - it would
> > > conflict with the great goal of having loadable debuggers that work
> > > on any kernels.
> >
> > What's the conflict with larger kernel stacks and a loadable (kgdb)
> > module?
>
> We'll not increase the stacks by default but the debugger should
> work anyways.
Sure but the debugger environment must tolerate larger stacks.
A developer may prefer to use a larger stack, like in my case
of storing debug info in the thread structure. The interrupt
stack checks can easily miss nicking the thread structure, so
increasing the stack size for experimentation SHOULD always work.
>
> > I was suggesting larger stack space for the kernel, not kgdb. I agree
> > this case might be one where kgdb has caused the kernel to trip over
> > the edge. I don't feel comfortable running on a kernel that running
> > that close to running out of stack space. Maybe that's just a personal
> > preference; I'm paranoid I guess. I like having rock solid systems and
> > wacking the stack isn't always detected. On SunOS we had a REDZONE but
> > last I check Linux didn't; has one been added?
>
> Interrupts can check for too much stack space used.
But this can miss a minor abuse. The interrupt check
is a quick and simple hack but I wonder if it's really
optimal for commercial implementations.
>
> > If it hasn't it might
> > be good to keep in mind having a CPU specific physical page available
> > when we grow into the REDZONE. Looked to me like the stack grows right
> > into the thread structure; might make a nice exploit for a linux root
> > kit.
>
> If you have a stack overflow you usually have other problems than that.
Yep, like viewing the stack with kgdb. With Solaris all of the task use
the same virtual address space for the stack, so mapping in a physical
page was easy. Linux stacks are mapped linear 1:1 to physical pages,
so it's not easy.
>
> > Having loadable debuggers seems a bit high hopes, as 'we' haven't even
> > release linux with kgdb built into the Linux src yet.
>
> Yes because you if modular works you don't need to build it in.
I think all modules should be ABLE to be built in. 2.6 has made good
progress in that regard. I'd prefer to see kgdb also ABLE to be linked
in or a module; just like most modules are doing now. I don't see an
advantage to the Linux community to REQUIRING the kgdb module to
NOT being ABLE to be linked in. Using modules often requires more
work to set up and get working right. It has it's advantages, I'd
prefer to leave it up to the developer to choose. Sometimes you
unload a module and pre-existing callbacks can mess up things in
unexpected way when the size of data structures change. I've used
kgdb on modules but for stuff like the TCP stack I really don't
want to mess with that. I'd prefer we make it easier for users
to get set up for kernel debugging. Just config kgdb, avoid using
kernel modules, install and run. Having kgdb in the kernel source
tree doesn't preclude it's use as a module. It does require it to
be under the GNU license. Unfortunately the HPUX kgdb patch wasn't
under the GNU license; it had some nice features, like kgdb over
TCP with ssh encryption. An that was 10 years ago!
>
> Modular was working at some point on x86-64 for kdb and the original 2.6 version
> of kgdb was nearly there too.
Yea, I saw that, too bad we can't seem to get a version of kgdb into
the kernel that can be update with the rest of the kernel. As I recall
NetBSD, FreeBSD, and OpenBSD have always done it that way. 'We' almost
got George Anzinger's kgdb patch into Linux; it was working great in the
mm series. Seems it should all be configurable with #ifdef CONFIG_KGDB
just like other kernel features. If you want to support other debuggers
than gdb I suppose common trap code could use a common CONFIG_* token.
-piet
>
> -Andi
>
--
---
piet@bluelane.com
^ permalink raw reply
* Re: genirq vs. fastack
From: Thomas Gleixner @ 2006-05-31 8:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Ingo Molnar, Linux Kernel list
In-Reply-To: <1149040361.766.10.camel@localhost.localdomain>
Hi Ben,
On Wed, 2006-05-31 at 11:52 +1000, Benjamin Herrenschmidt wrote:
> Hi Thomas, Ingo !
>
> There is one bit in genirq that I don't get (and doesn't work for me),
> it's the "fastack" handler. It does:
>
> out:
> if (!(desc->status & IRQ_DISABLED))
> desc->chip->ack(irq);
> else
> desc->chip->mask(irq);
>
> Which doesn't at all match the needs of things like XICS or MPIC and
> thus I wonder if it does also make sense for controllers for which you
> intend it. It should just be:
>
> desc->chip->end(irq);
>
> Basically, those controllers will have 1) already acke'd the interrupt
> by the time you get the vector (the act of getting the vector does the
> ack), 2) will use a processor priority mecanism to handle non-reentrency
> of an interrupt thus mask/unmask is completely orthogonal to handling of
> interrupts and thus there is no need to do anything about mask/unmask in
> the handler, 3) all we need is to do an "EOI" (end of interrupt) at the
> end of the handling, which is what is done logically in the end()
> handler.
I see your point, but isn't EOI the chip specific implementation of
chip->ack() in that case ?
The intention was to get down to the chip primitives and away from the
flow type chip->functions. Your patch would actually force the flow
control part (if (!(desc->status & IRQ_DISABLED))) back into the end()
function for Ingo's x86 implementation. So the intended seperation of
low level chip functions and flow control would be moot.
tglx
^ permalink raw reply
* Re: t9001 fails because Net::SMTP is missing
From: Johannes Schindelin @ 2006-05-31 8:32 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20060531060530.GA9333@hand.yhbt.net>
Hi,
On Tue, 30 May 2006, Eric Wong wrote:
> Odd that Net::SMTP isn't installed on Johannes' machine, though, as it's
> part of the standard Perl 5.8 (maybe even before) installation.
In terms of corporate setups, 5.8 really is pretty new, you know?
As for "s/use/require/", I can not access on that machine today, but I
will test it.
Ciao,
Dscho
^ permalink raw reply
* Re: RT_PREEMPT problem with cascaded irqchip
From: Yann.LEPROVOST @ 2006-05-31 8:26 UTC (permalink / raw)
To: tglx
Cc: Daniel Walker, linux-kernel, linux-kernel-owner, Ingo Molnar,
Steven Rostedt, Esben Nielsen, Sven-Thorsten Dietrich
In-Reply-To: <1149031517.20582.55.camel@localhost.localdomain>
> Yann,
>
> Can you please use a sane mail client ? There is no point to have the
> headers of the previous mail inserted in some fancy way. Also please
> answer inline and not on top of the reply.
>
> Thanks.
Sorry for the behavior of my mail client, I have unfortunately no
chance to change it.
However, I think you'll prefer this format.
>
> On Tue, 2006-05-30 at 16:44 +0200, Yann.LEPROVOST@wavecom.fr wrote:
> > Well, in fact the issue doesn't come neither from the mask/unmask
procedure
> > nor from the set_irq calls.
> > Correct gpio mask/unmask are called before the gpio_irq_handler.
> >
> > However, there is an issue in gpio_irq_handler (specific to generic_irq
and
> > AT91RM9200, i think) concerning desc->chip->chip_data.
> > The following change has to be applied :
> >
> > -- pio = (void __force __iomem *) desc->chip->chip_data;
> > ++ pio = (void __force __iomem *) desc->chip_data;
>
> Hmm. Is that part of your code or is it related to code in mainline ?
This is currently part of the 2.6.16 mainline! However, I have seen
that this line has been replaced
by "pio = get_irq_chip_data(irq);" in 2.6.17-rc4-genirq4 which access
desc->chip_data. So this problem
has been solved by genirq4...
>
> > Moreover, I think that the call to redirect_hardirq have to be insered
in
> > gpio_irq_handler but I don't know how to do that.
>
> Why should that be done. The gpio_irq_handler should be called from the
> demultiplexing handler, via desc->handler(..). ARM has a conversion
> macro - desc_handle_irq() for that.
>
Yep, I misunderstood the role of gpio_irq_handler...
> Anyway, the ARM code in 2.6.16-rtXX is lacking some of the changes we
> did in the genirq patchset. Sorry: - ENOTENOUGHINSTANCES
>
> I'm in the progress to update that.
>
> tglx
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* RE: [Qemu-devel] qemu dsound and crash
From: ZIGLIO, Frediano, VF-IT @ 2006-05-31 8:28 UTC (permalink / raw)
To: qemu-devel
>
> ZIGLIO, Frediano wrote:
>
> >I analyzed the dsound problem (using Windows dsound audio
> driver cause
> >crash when closing console window cf "Qemu impressions").
> The problem is
> >very complicated. Is seems that for some reasons dsound dll
> is unloaded
> >before msvcrt (which hold atexit and exit function) so dsound free
> >memory then msvcrt calls at exit callbacks which try to access freed
> >structure... The problem occur on Windows XP and I got error
> using Qemu
> >downloaded at http://www.h7.dion.ne.jp/~qemu-win/ and compiling 0.8.1
> >from sources. dsound.dll is loaded calling CoCreateInstance in
> >audio/dsoundaudio.c (line 975) however is very strange this dll free
> >cause even dsound.dll depends on msvcrt.dll. Perhaps a
> workaround can be
> >to call SetConsoleCtrlHandler on main and calling exit by
> our own... I
> >noted that for some reason qemu.exe seems to load msvcrt.dll two
> >times...
>
> Thanks for your info. I wondered what caused the problem. It
> seems that
> optimization also have effect on the problem.
>
> Regards,
> Kazu
>
Thanks,
at least I know someone read my mails :)
Well... how I discovered the cause
- launched qemu, closing with "X" crash
- I compiled qemu (without dsound support) and accidentally "X" works...
- after recompiling with dsound + fmod qemu crash with "X"
- now what cause the error
---------------------------
qemu.exe - Application Error
---------------------------
The instruction at "0x00438213" referenced memory at "0x0b112210". The
memory could not be "read".
Click on OK to terminate the program
---------------------------
OK
---------------------------
- 0x00438213 is in dsoundaudio.c (enabled mapfile on linker to discover
this)
- I added many printf and discovered that problem was dsound->Release()
- added others printf, Release is not called two times
- opened debugger and placed a break point on access of 0x0b112210
(after DSound creation)
- memory change in a HeapFree called from dsound.DllMain from
ntdll.LdrShutdownProcess from kernel32
What did I do next (today) ? I didn't understand why qemu.exe imports
msvcrt two times... I linked with --verbose flags and I noted that some
libraries are linked twice but removing these duplications have no
effects (as I expected). I noted that -lmsvcrt and -lmoldname are linked
together. This caused some problems in another project some time ago so
I decided to remove -lmoldname... after a lot of replacement in sources
(like open -> _open, read -> _read and so on) I got it linked with one
msvcrt import from qemu.exe, but this not solve initial problem... so
this is not the cause... I can confirm that my workaround works fine but
I'm unable to explain the dsound problem... why the hell should windows
free dsound before msvcrt?
freddy77
^ permalink raw reply
* Re: OpenGL-based framebuffer concepts
From: Ondrej Zajicek @ 2006-05-31 8:26 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <447CD367.5050606@gmail.com>
On Wed, May 31, 2006 at 07:21:11AM +0800, Antonino A. Daplas wrote:
> > 2) To modify appropriate fbdev drivers to not do mode change at startup.
> > Fill fb_*_screeninfo with appropriate values for text mode instead.
>
> Most drivers do not change the mode at startup. Do not load fbcon, and
> you will retain your text mode even if a framebuffer is loaded.
Yes, but i wrote about _using_ fbcon and fbdev without mode change.
> > 3) (optional) To modify appropriate fbdev drivers to be able to switch
> > back from graphics mode to text mode.
>
> And a few drivers already do that, i810fb and rivafb. Load rivafb or i810fb,
> switch to graphics mode, unload, and you're back to text mode.
I though about being able to explicitly change mode from graphics to text
(for example when fbdev-only X switch to fbcon) while using fbdev.
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago@mail.cz, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
^ permalink raw reply
* Re: long/heavy USB fs operations panics 2.6.16.18
From: Indrek Kruusa @ 2006-05-31 8:20 UTC (permalink / raw)
To: Jordan Crouse; +Cc: linux-kernel
In-Reply-To: <20060530031037.GA11543@cosmic.amd.com>
Jordan Crouse wrote:
> On 29/05/06 19:41 +0300, Indrek Kruusa wrote:
>
>> Duh... I have to doublecheck it but currently it seems that our BIOS
>> needs a fix. I hope you haven't had much trouble with my problem report.
>> I much appreciate your feedback.
>>
>
> Well, let us know if the problem persists. Good luck.
>
I am not able to describe it in depth but there was "layout" or
"placement" changes needed in our mini-version BIOS (so they said). I
just figured out that with full-blown BIOS there wasn't problems. By now
the "mini" BIOS is also OK (especially for Linux).
Indrek
^ permalink raw reply
* Re: printk on framebuffer console
From: Terence Soh @ 2006-05-31 8:17 UTC (permalink / raw)
To: Antonino A. Daplas; +Cc: Linux Fbdev development list
In-Reply-To: <447D189C.1010100@gmail.com>
> Remove the console=ttyS0 from your boot parameter (or change it to tty0)
> and the system messages should go to the framebuffer console.
You're right, that worked.
Is there any way I can disable the printf/printk once my QT-Embedded
application starts?
Terence.
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
^ permalink raw reply
* Re: [parisc-linux] Question on video cards.
From: Max Grabert @ 2006-05-31 8:16 UTC (permalink / raw)
To: pyrotek; +Cc: parisc-linux
In-Reply-To: <1149048178_22889@mail.internode.on.net>
[-- Attachment #1.1: Type: text/plain, Size: 3549 bytes --]
On 31/05/06, pyrotek <pyrotek@internode.on.net> wrote:
>
>
> Hello all,
>
> I know this topic has been done to death. And I have read quite a lot in
> the
> mailing list archives.
> If I've missed something please feal free to point me in the right
> direction.
>
> I've got a Fx10 (grumbles)
> I don't want to go back to a Vis-EG 8bit colour no thanks I use the Fx10
> in
> Hp-UX
>
> >From my limited understanding "some" PCI video cards "may" work.
>
> I have read that the voodoo 2 card "should" work?
> >From my memory this was a PCI card that connected to your main video card
> via a small vga cable. is this the card everyone is talking about?
Yes. It was basically sold as a 3D add-on card, and when
using a 3D game, your main graphics card would switch
off and the Voodoo2 would display the 3D picture.
However the Voodoo2 can actually be used as a 'normal'
graphics card (incl. accelerated 2D), but AFAIK it was
not identified as a graphics card to the x86-BIOS and
therefore not initialized as such and also the Windows drivers didn't
support 2D with the Voodoo2.
IIRC the Voodoo Banshee was basically somewhat 'upgraded' Voodoo2 with
working 2D support and sold as a 'real' graphics card.
But when running Linux you can use the Voodoo2 just like
any normal graphics card.
If so can I piggy back it off my FX10? Or do I need to use it by it self?
You should be able to do both. Use sticon/stifb/X11 (fbdev) with the FX10
and the voodoo fb driver X11 (fbdev) for the Voodoo2.
If you want to use the Voodoo2 alone, you might want
to include the fbcon driver as well, but you'll always need
to use the serial console if you want to get into the PDC
if you don't use the FX10.
----
I have a Voodoo2 and a Matrox Millenium I
(4MB + 4MB add on). Both used to work fine with
32bit kernels on a C240, C3000 and C3700,
the Voodoo2 at 1024x768x24bit, and the Matrox with
1280x1024x24bit (my monitor doesn't support more).
My Voodoo2 however as a terrible signal quality!
I also had several success reports from people using
a Matrox Millenium II (AFAIK very similar to v1 anyway) ...
... HOWEVER I haven't tested whether all the cards works
with recent kernels, last time I used that machine as a
desktop was half a year back with a 2.6.9 kernel or
something. IIRC also 64bit fbcon worked back then, but
the machine would HPMC when it tried to start XFree86.
IIRC the first person who succeeded in having a 24bit desktop with a non-HP
gfx card did it with a ATI Rage XL.
I also have the same card, but I never managed to get
it working.
Note though you will get a 24bit desktop with these
gfx cards you will have no 2D acceleration, as they
are just work with X11/fbdev. Once we get the native
Xorg working on parisc they should be fast enough
for video playback I guess, but right now it is a quite
sluggish desktop experience ...
-----
BTW, I've read some paper that described the effort required to get ATI and
NVidia cards to initialize on
non-Intel systems by the means of a software x86-Emulator (like the one that
is in XFree86/Xorg).
IIRC the nvidia cards where the least troublesome, but
the init sequence needed for ATI cards are also well
understood.
----
I don't know what parts need to be done to get the
x86-BIOS emu or XFree86/Xorg working on parisc,
but once fixed you should be able to get accelerated 2D
with readily available gfx cards such as newer cards from
ATI/NVidia.
I don't think it would be that easy to get accelerated
3D working though, since someone would also have
to port DRI etc...
Greetings,
Max
[-- Attachment #1.2: Type: text/html, Size: 4265 bytes --]
[-- Attachment #2: Type: text/plain, Size: 169 bytes --]
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* Re: Unlocked flash is re-locked by unknow
From: Henrik Bork Steffensen @ 2006-05-31 8:12 UTC (permalink / raw)
To: linux-mtd
In-Reply-To: <Pine.LNX.4.64.0605301511150.16927@localhost.localdomain>
Nicolas Pitre wrote:
>A spike on the flash power maybe?
>
>
Yes, that's it!
The 2.6 seems to generate 20-40% larger spikes on Vcc than
the old 2.4.19-rmk7, which runs 30 Bogomips were the 2.6
runs at 90 Bogomips. (i have no idea of this is just the
bogomips loop which runs faster or the cpu actually runs
faster)
Thanks you very much - we obviously needed fresh eyes on
the subject.
--
med venlig hilsen / best regards / Mit freundlichen Grüßen
Henrik Bork Steffensen
RoseTechnology A/S
http://www.rosetechnology.dk
^ 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.