* 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
* Re: 645 highbo
From: Safira Benner @ 2006-05-31 8:13 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1.1: Type: text/plain, Size: 563 bytes --]
Hi,
C ? A L i S
V ? A G R A
L E V ? T R A
P R O Z ^ C
X ^ N A X
V A L / U M
M E R ? D i A
A M B / E N
S O M ^
http://www.vokasihasol.com
their journey across the plains below.
The Lord of the Eagles would not take them anywhere near where men
lived. They would shoot at us with their great bows of yew, he said,
for they would think we were after their sheep. And at other times they
would be right. No! we are glad to cheat the goblins of their sport, and
glad to repay our thanks to you, but we will not risk ourselves for
[-- Attachment #1.2: Type: text/html, Size: 981 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
[-- Attachment #3: Type: text/plain, Size: 161 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel
^ permalink raw reply
* [U-Boot-Users] Which configuration?
From: Stefan Roese @ 2006-05-31 8:11 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060531075245.64790@gmx.net>
Hi Norman,
On Wednesday 31 May 2006 09:52, Norman Baier wrote:
> I would like to update the U-Boot of my embedded jukebox. It has a PPC 405
> CPU without FPU.
Which one? 405GR, 405GPr, 405CR, 405EP? Or something else? It's not easy to
recommened a board that fits your need the best without any knowledge about
it.
Also good to know would be what kind of FLASH you use (type and width), and
how the SDRAM is connected to your CPU (DIMM module or onboard).
With such informations you can look through the different 405 board config
files and chose the one that fits the best to your custom design.
> I was reading the documentation on the denx site and the
> README in the source distribution, but I did not really find out which
> configuration would best fit me. Can you please point me to some good
> documentation? What are TQM8xxl boards and how do I find out, whether or
> not I have one?
TQM8xxl are MPC8xx based CPU modules from TQ Components.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH,RFC] [MTD] replace MTD_NORFLASH with MTD_GENERIC_TYPE
From: Artem B. Bityutskiy @ 2006-05-31 8:09 UTC (permalink / raw)
To: Jörn Engel; +Cc: linux-mtd, David Woodhouse
In-Reply-To: <20060530185017.GG26220@wohnheim.fh-wedel.de>
On Tue, 2006-05-30 at 20:50 +0200, Jörn Engel wrote:
> Again, Artem won't like this. But this time I would like to see
> better objections than before. Just to show how silly they are:
>
> "*you* should prove why it is useless, not me"
> That is what these patches are doing. I remove every existing user of
> mtd->type and thereby prove that mtd->type was useless in this
> particular case. When I'm finished and have dealt with every case,
> the proof is complete.
>
> "i want to print a type of flash my JFFS2 file system is
> working on"
> Show me the code. If you have out-of-tree patches that may collide
> with my work - tough luck. I have out-of-tree patches as well and as
> long as they are not merged, it is _my_ duty to deal with any breakage
> created by other's changes in the kernel. That has always been the
> general rule and for a good reason.
Please, stop this, there is no reason for greening. You was several
times said about my real reasons. This was just an answer for your "I
don't want to delve into your explanation, I just let David judge".
Once more.
1. Having an mtd->field field and capabilities flags a bad idea. Why?
1a: Who initializes this mtd->flags field? If I want to add 20 new
capabilities, how many places do I have to change? As many as there are
drivers in MTD? Insane.
2a. In general, the capabilities thing is application-dependent. And it
must stay in application's area, not deep in drivers.
3a: If I'm a user of MTD, and I want to add 20 new capability, do I have
to change MTD itself? It's not my business to do this.
4a. How wide is the mtd->flags field? 32 bits? So, you restrict me by 32
capabilities? And if I need more, I have to combine the existing ones?
Why is it better then using mtd->type?
So, this is not an extensible solution.
2. OK, what do you offer instead (the question nobody asked yet)?
Forget about mtd->flags. Leave alone mtd->type. Add an
include/linux/mtd/flash_capabilities.h header which looks like this:
/* If the flash allows to clear individual bits */
#define mtd_can_clear_bits(mtd) (mtd->type == MTD_NORFLASH)
/* If the goat may be milked */
#define mtd_can_milk_a_goat(mtd) (bah)
....
etc.
So, you have your set of capabilities. You use this header in JFFS2 and
clean it up. Your task is solved.
If I want to add a new flash type, I fix the flash_capabilities.h
header. If I add a new capability - I fix the header as well. I don't
get my dirty forepaws into other drivers. It's extensible.
To put it differently, I offer to add the capabilities stuff as a thin
layer over MTD, not to jab it deeply into the MTD core.
3. It's difficult to understand what is MTD_GENERIC_TYPE stuff. In
reality, this is just a temporary junk, which is supposed to go later.
But temporary junk usually tends to stay forever. I can't understand why
you cannot avoid introducing it.
4. OK, if you still think that mtd->flags is better, please, go ahead.
After all, it may be fixed later if needed. And may be I'm just wrong.
But, please, do it without this strange MTD_GENERIC_TYPE stuff. Why
can't you?
5. Introducing capabilities and removing mtd->type are 2 completely
different activities. No need to mix them, IMO.
I appreciate your work, and offer another way to do this. I think it is
better, and didn't so far hear any good argument against it. Thanks for
reading this :-)
--
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.
^ permalink raw reply
* Re: OpenGL-based framebuffer concepts
From: Pavel Machek @ 2006-05-31 8:08 UTC (permalink / raw)
To: D. Hazelton
Cc: Jon Smirl, Dave Airlie, Alan Cox, Kyle Moffett, Manu Abraham,
linux cbon, Helge Hafting, Valdis.Kletnieks, linux-kernel
In-Reply-To: <200605302314.25957.dhazelton@enter.net>
Hi!
> > > Actually the suspend/resume has to be in userspace, X just re-posts
> > > the video ROM and reloads the registers... so the repost on resume has
> > > to happen... so some component needs to be in userspace..
> >
> > I'd like to see the simple video POST program get finished. All of the
> > pieces are lying around. A key step missing is to getting klibc added
> > to the kernel tree which is being worked on.
>
> True. But how long is it going to be before klibc is merged?
It is in -mm tree just now. Just work against -mm tree, it is tree
you'll need to merge against, anyway.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [U-Boot-Users] Intel 28F256J3C
From: Stefan Roese @ 2006-05-31 8:07 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060531074839.2124F353B06@atlas.denx.de>
Hi Xuxian,
On Wednesday 31 May 2006 09:48, Wolfgang Denk wrote:
> In message <447d42b2.45c5968f.442a.ffff9351@mx.gmail.com> you wrote:
> > I try to make u-boot work on my board which is similar with OMAP5912OSK.
> > But the flash we using is 28F256J3C. I have already added 28F256J3C's
> > manufacture code and device id in the proper position of u-boot. But
> > there are several questions I can't figure out.
>
> Any reason for not using the CFI driver?
Please take Wolfgangs advice and use the common CFI flash driver. The current
U-Boot OMAP5912OSK port also uses this driver. It should work without any
changes with your flash type.
Best regards,
Stefan
^ permalink raw reply
* Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux)
From: Janos Haar @ 2006-05-31 8:00 UTC (permalink / raw)
To: Nathan Scott; +Cc: linux-kernel, linux-xfs
In-Reply-To: <20060531143849.C478554@wobbly.melbourne.sgi.com>
----- Original Message -----
From: "Nathan Scott" <nathans@sgi.com>
To: "Janos Haar" <djani22@netcenter.hu>
Cc: <linux-kernel@vger.kernel.org>; <linux-xfs@oss.sgi.com>
Sent: Wednesday, May 31, 2006 6:38 AM
Subject: XFS related hang (was Re: How to send a break? - dump from frozen
64bit linux)
> On Tue, May 30, 2006 at 09:20:31PM -0400, Steven Rostedt wrote:
> > Added all those listed in the MAINTAINERS file for XFS.
>
> Thanks Steve.
>
> > On Tue, 2006-05-30 at 15:03 -0400, Valdis.Kletnieks@vt.edu wrote:
> > > On Tue, 30 May 2006 12:22:01 +0200, Janos Haar said:
> > > Half the processes on the box seem wedged at that same mutex_lock. I
can't
> > > seem to find an xfs_qm_shake in my source tree though.
>
> Its in fs/xfs/quota/xfs_qm.c.
>
> > kswapd0 D ffff81011fe03c38 0 297 1 1287 19
(L-TLB)
> > ffff81011fe03c38 0000000000000004 000000000000000a ffff81011f92ba68
> > ffff81011f92b850 ffffffff805a23a0 0000149f99fa7d7c
000000000003bcde
> > 000000002f2c46e0 ffff81008bc37180
> > Call Trace: <ffffffff804e5522>{schedule_timeout+34}
> > <ffffffff80269f87>{xfs_qm_dqunpin_wait+220}
<ffffffff80140e74>{debug_mutex_free_waiter+141}
>
> So, we're waiting here on a synchronisation variable that'll
> be released once the dquot metadata buffer write completes.
>
> > So it is now waiting to be woken up by something that calls:
> >
> > xfs_qm_dquot_logitem_unpin which seems to be the function to wake it
> > up.
>
> Mhmm, that'd be called by the I/O completion handler on the buffer
> containing that dquot.
>
> > And decyphering all the macro crap it seems that the function that wakes
> > it up is xfs_trans_chunk_committed, or xfs_trans_uncommit.
>
> Right (the former, at this point in the code).
>
> > The above xfs_qm_dqunpin_wait still looks awfully racy, and the
> > xfs_log_force, which I'm assuming wakes up whoever is suppose to wake up
> > kswapd0, doesn't have a return code check. So if it failed to do
>
> The logforce isn't race-critical here - its ensuring writeout
> of previously logged buffers is started before we go to sleep
> waiting for the driver to wake us up when its done.
>
> An earlier I/O error on the journal is the only thing the log
> force can return as an error there, which isnt useful at that
> point anyway (we're in a kernel thread trying to free mem).
>
> > whatever the hell it's doing (that code gives me a headache), it looks
>
> Heh, likewise. I have voodoo dolls of one or two of the early
> XFS folks that I like to poke with needles occasionally.. :)
>
> > like this guy might sleep forever holding a lock that will prevent
> > others from freeing kernel memory.
>
> It will sleep until the previously initiated buffer write is done.
> AFAICT, we aren't seeing the I/O completion here for some reason...
> which points more to a possible device driver or h/ware issue (that
> is the usual root cause of this sort of hang, anyway).
>
> cheers.
Hey, i think i found something.
My quota on my huge device is broken.
(inferno -- 18014398504855404 0 0 18446744073709551519
0 0)
I cant found a way to re-initialize it.
But anyway, at this point i dont need it, trying to disable the quota usage.
We will see....
Thanks a lot!
Janos
>
> --
> Nathan
> -
> 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: Question about tcp hash function tcp_hashfn()
From: Brian F. G. Bidulock @ 2006-05-31 8:00 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.
Yes, that could be far more efficient.
^ permalink raw reply
* [Bluez-users] RS-232 Dongle
From: Tamed Technology - Robert Rawlins @ 2006-05-31 7:55 UTC (permalink / raw)
To: bluez-users
[-- Attachment #1.1: Type: text/plain, Size: 1324 bytes --]
Morning Guys,
First of all thanks for your time on answering this query, I have a
couple of questions that I need asking, I'm completely new to BlueZ and
Still quite fresh to Linux so you'll have to excuse my naivety.
I currently have a Linux box running BlueZ and running a USB Dongle from
3Com, and everything seems to run perfectly fine, I'm able to scan for
devices, send files to them etc etc.
Now, I'm looking to connect a Serial Adapter from SENA, which I've been
told operates on a CSR chipset, and connects to the back of my unit
using a RS-232 connector.
I've spent some time reading through all the documentation I can find
and seem to be running across the concept of 'hciattach' for connecting
this device so I can process commands through hcitool to my device.
I've also read a lot about ensuring I have the latest Kernel patch
running on my system. However I have no idea on how to check my current
Kernel version, or how to install the latest version onto the box.
Can you please offer some advice on how to check my kernel, install the
latest addition and attach my RS-232 adapter to my BlueZ interface so I
can use that rather than my USB dongle?
If there are any additional steps that are likely to be needed can you
please point me in the right direction?
Many Thanks Guys,
Rob Rawlins
[-- Attachment #1.2: Type: text/html, Size: 6587 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
[-- Attachment #3: Type: text/plain, Size: 164 bytes --]
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ 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.