* [Xenomai-core] Proposal to use buildbot for Xenomai
From: Niklaus Giger @ 2006-04-07 21:37 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]
Hi everybody
If you point your browser at http://ngiger.dyndns.org/buildbot/ (with ending
slash please), you will find a first prototype of the continuos integration
tool buildbot (http://buildbot.sourceforge.net/)
It proves that it possible to automatically retrieve each revison of the
Xenomai and compile it for (at the moment) two targets, a stock PPC and a
custom PPC405 board (cross-compiling).
At the moment it already is useful for me, but I would like to ask your
opinion about its usefulness. Would this be useful for you too? Do you have a
special target to propose (other architectures, other target like skins, all
xenomai components as modules/built-ins, mvm simulator)?
Be warned that setting up a buildbot master/slave using known good
configuration is easy and can be accomplished in less than half an hour, but
tweaking the master.cfg takes time and errors are not always easy to spot.
E.g. I spent about 40 hours to until I could present you this email and the
attached documents.
Corrections/suggestions to all documents included are welcome.
In the attached tar file you find a pdf file with detailed instructions on how
to setup a build slave/master for xenomai to experiment with.
I am willing to work in the next weeks (or months) to improve the buildbot
master, integrate more slaves. If the xenomai developers would like to
transfer (now or some time later) the master to another machine this would be
fine for me too. Anywhy if this buildbot master generates too much traffic I
might be forced to remove it, as the machine is my private small server
connected via ASDL (1000kb upstream and only about 200kb downstream for you).
My plans to improve include:
- fix any error reported by the eventual users of the buildbot
- fix some buildbot minor annoyance
a) may be a prettier stylesheet
b) use the names of the buildsteps as in
http://ngiger.dyndns.org/buildbot/hcu3/builds/13 also in the main page)
- Handle correctly cases like changes in the xenomai repository which require
new configs, new kernel or patch-versions
- Not only compile xenomai but also actually run some tests to prove the
changes valid.
This will either require buildbot changes to add a step where one can reboot
a slave and run the next step with the new kernel (How to handle non-boots?)
or
add a separate target board whose power supply can be switched off/on by an
external device. What I found are either
I) Ethernet controlled power switch like
http://info.infratec-ag.de/catalog/product_info.php?products_id=830&language=en&osCsid=a3995263b1f1ca75af33fe9d0d5fa384
or IO-devices, like the
II) USB LabJack http://www.labjack.com/labjack_u12.html.
Suggestions for a cheaper solution would be always welcome.
Best regards
--
Niklaus Giger
[-- Attachment #2: xeno_buildbot.tar.bz2 --]
[-- Type: application/x-tbz, Size: 90913 bytes --]
^ permalink raw reply
* [Qemu-devel] [PATCH] fix breakpoint address conversions
From: andrzej zaborowski @ 2006-04-07 21:38 UTC (permalink / raw)
To: qemu-devel
Hi,
This patch adds conversion of the breakpoint addresses from the target
to host space when invalidating translation blocks.
This issue prevented breakpoints from working on machines that have
physical memory mapped starting at a different place than address zero
(such as TI OMAP boards), except for the cases when the translation
block was accidentaly invalidated due to e.g a jump, at the same time.
As a result this was also breaking the stepping single instructions in
gdb. This patch fixes this problem.
--
balrog 2oo6
Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-07 21:39 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2008>
======================================================================
Reported By: mborsick
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2008
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Redhat/Fedora
Kernel Version: 2.6.16-1.2080 and with Xen
======================================================================
Date Submitted: 04-07-2006 00:43 CEST
Last Modified: 04-07-2006 23:39 CEST
======================================================================
Summary: No Sound with snd-hda-intel driver Asus P5VDC-MX
Description:
Kernel is up-to-date Xen kernel.
Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.
======================================================================
----------------------------------------------------------------------
rlrevell - 04-07-06 23:32
----------------------------------------------------------------------
"This 05:08:0 and 05:09:0 was not seen with the default "PCI access
mode"=ANY and PCIx ON.I use Gentoo kernel gentoo-sources-2.15-r8 (x86), I
hope this can help."
So if you boot with the default settings lspci shows no sound cards at
all?
This is a kernel or BIOS issue - there's nothing ALSA can do if the sound
card doesn't appear on the bus.
What sound card is this thing supposed to have? I can't believe you both
have the same board but lspci is showing three different soundcards?
----------------------------------------------------------------------
buboleck - 04-07-06 23:39
----------------------------------------------------------------------
I have disabled my onboard via snd card and sata. Currently I use some
external creative pci card. My board is exatctly the same.
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 00:43 mborsick New Issue
04-07-06 00:43 mborsick Distribution => Redhat/Fedora
04-07-06 00:43 mborsick Kernel Version => 2.6.16-1.2080 and
with Xen
04-07-06 01:07 rlrevell Note Added: 0009129
04-07-06 02:13 mborsick Note Added: 0009130
04-07-06 02:35 rlrevell Note Added: 0009131
04-07-06 06:38 mborsick Note Added: 0009135
04-07-06 22:45 buboleck Note Added: 0009156
04-07-06 22:47 buboleck Note Edited: 0009156
04-07-06 22:49 buboleck Note Edited: 0009156
04-07-06 23:06 rlrevell Note Added: 0009157
04-07-06 23:16 buboleck Issue Monitored: buboleck
04-07-06 23:26 buboleck Note Added: 0009158
04-07-06 23:32 rlrevell Note Added: 0009159
04-07-06 23:39 buboleck Note Added: 0009160
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [Qemu-devel] Re: [PATCH] fix breakpoint address conversions
From: andrzej zaborowski @ 2006-04-07 21:39 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <fb249edb0604071438w36fd932bn102907f852f2b0ef@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 899 bytes --]
On 07/04/06, andrzej zaborowski <balrog@zabor.org> wrote:
> Hi,
> This patch adds conversion of the breakpoint addresses from the target
> to host space when invalidating translation blocks.
> This issue prevented breakpoints from working on machines that have
> physical memory mapped starting at a different place than address zero
> (such as TI OMAP boards), except for the cases when the translation
> block was accidentaly invalidated due to e.g a jump, at the same time.
> As a result this was also breaking the stepping single instructions in
> gdb. This patch fixes this problem.
> --
> balrog 2oo6
>
> Dear Outlook users: Please remove me from your address books
> http://www.newsforge.com/article.pl?sid=03/08/21/143258
>
I forgot about the attachment...
--
balrog 2oo6
Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258
[-- Attachment #2: qemu-breakpoints.patch --]
[-- Type: application/octet-stream, Size: 809 bytes --]
diff -pNaur qemu/exec.c qemu-omap-clean/exec.c
--- qemu/exec.c 2006-02-08 22:43:39.000000000 +0000
+++ qemu-omap-clean/exec.c 2006-04-07 20:56:55.000000000 +0000
@@ -993,9 +993,17 @@ static void tb_reset_jump_recursive(Tran
#if defined(TARGET_HAS_ICE)
static void breakpoint_invalidate(CPUState *env, target_ulong pc)
{
- target_ulong phys_addr;
+ target_ulong phys_addr, addr, pd;
+ PhysPageDesc *p;
- phys_addr = cpu_get_phys_page_debug(env, pc);
+ addr = cpu_get_phys_page_debug(env, pc);
+ p = phys_page_find(addr >> TARGET_PAGE_BITS);
+ if (!p) {
+ pd = IO_MEM_UNASSIGNED;
+ } else {
+ pd = p->phys_offset;
+ }
+ phys_addr = (pd & TARGET_PAGE_MASK) | (addr & ~TARGET_PAGE_MASK);
tb_invalidate_phys_page_range(phys_addr, phys_addr + 1, 0);
}
#endif
^ permalink raw reply
* Re: [2.6.16] saa7134 disable_ir oops
From: Hartmut Hackmann @ 2006-04-07 21:40 UTC (permalink / raw)
To: Linux and Kernel Video
Cc: stable, Brian Marete, David Liontooth, linux-kernel,
Mauro Carvalho Chehab
In-Reply-To: <20060407133628.GG10864@master.mivlgu.local>
Hi,
Sergey Vlasov wrote:
> On Fri, Apr 07, 2006 at 10:16:10AM -0300, Mauro Carvalho Chehab wrote:
>
>>Em Qui, 2006-04-06 ?s 20:20 +0400, Sergey Vlasov escreveu:
>>
>>>On Fri, 24 Mar 2006 14:00:46 -0800 David Liontooth wrote:
>>
>>>Does the following patch fix things?
>>>
>>
>>Applied at v4l-dvb tree. Thanks.
>
>
> IMHO this patch should also be added to 2.6.16-stable - it fixes oops in
> configurations which worked fine with older kernels.
>
> -----------------------------------------------------------------------
>
> saa7134: Fix oops with disable_ir=1
>
> When disable_ir=1 parameter is used, or when saa7134_input_init1()
> fails for any other reason, dev->remote will remain NULL, and the
> driver will oops in saa7134_hwinit2(). Therefore dev->remote must be
> checked before dereferencing.
>
> Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
>
> --- linux-2.6.16.orig/drivers/media/video/saa7134/saa7134-core.c 2006-03-20 08:53:29 +0300
> +++ linux-2.6.16/drivers/media/video/saa7134/saa7134-core.c 2006-04-06 20:00:56 +0400
> @@ -543,6 +543,8 @@ static irqreturn_t saa7134_irq(int irq,
> if (report & SAA7134_IRQ_REPORT_GPIO16) {
> switch (dev->has_remote) {
> case SAA7134_REMOTE_GPIO:
> + if (!dev->remote)
> + break;
> if (dev->remote->mask_keydown & 0x10000) {
> saa7134_input_irq(dev);
> }
> @@ -559,6 +561,8 @@ static irqreturn_t saa7134_irq(int irq,
> if (report & SAA7134_IRQ_REPORT_GPIO18) {
> switch (dev->has_remote) {
> case SAA7134_REMOTE_GPIO:
> + if (!dev->remote)
> + break;
> if ((dev->remote->mask_keydown & 0x40000) ||
> (dev->remote->mask_keyup & 0x40000)) {
> saa7134_input_irq(dev);
> @@ -671,7 +675,7 @@ static int saa7134_hwinit2(struct saa713
> SAA7134_IRQ2_INTE_PE |
> SAA7134_IRQ2_INTE_AR;
>
> - if (dev->has_remote == SAA7134_REMOTE_GPIO) {
> + if (dev->has_remote == SAA7134_REMOTE_GPIO && dev->remote) {
> if (dev->remote->mask_keydown & 0x10000)
> irq2_mask |= SAA7134_IRQ2_INTE_GPIO16;
> else if (dev->remote->mask_keydown & 0x40000)
>
Let's think this over, please.
1) The problem originally was that a card type with remote control was
forced for a card that doesn't have one.
2) On the other hand you are right, this situation should not cause an oops.
The code should be that GPIO irqs should be completely ignored unless a handler
has been installed, so the
if (dev->has_remote)
is completely wrong and should be repaced by something explictly initialized,
maybe the dev->remote pointer does the trick better.
I never worked seriously on this fraction of the driver, so there might be a
better solution.
Comments?
Hartmut
^ permalink raw reply
* Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
From: Al Boldi @ 2006-04-07 21:32 UTC (permalink / raw)
To: Peter Williams; +Cc: linux-kernel
In-Reply-To: <44344A59.9070007@bigpond.net.au>
[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]
Peter Williams wrote:
> Al Boldi wrote:
> > Peter Williams wrote:
> >> Al Boldi wrote:
> >>> Peter Williams wrote:
> >>>> Al Boldi wrote:
> >>>>>>>> Control parameters for the scheduler can be read/set via files
> >>>>>>>> in:
> >>>>>>>>
> >>>>>>>> /sys/cpusched/<scheduler>/
> >>>>>
> >>>>> The default values for spa make it really easy to lock up the
> >>>>> system.
> >>>>
> >>>> Which one of the SPA schedulers and under what conditions? I've been
> >>>> mucking around with these and may have broken something. If so I'd
> >>>> like to fix it.
> >>>
> >>> spa_no_frills, with a malloc-hog less than timeslice. Setting
> >>> promotion_floor to max unlocks the console.
> >>
> >> OK, you could also try increasing the promotion interval.
> >
> > Seems that this will only delay the lock in spa_svr but not inhibit it.
>
> OK. But turning the promotion mechanism off completely (which is what
> setting the floor to the maximum) runs the risk of a runaway high
> priority task locking the whole system up. IMHO the only SPA scheduler
> where it's safe for the promotion floor to be greater than MAX_RT_PRIO
> is spa_ebs. So a better solution is highly desirable.
Yes.
> I'd like to fix this problem but don't fully understand what it is.
> What do you mean by a malloc-hog? Would it possible for you to give me
> an example of how to reproduce the problem?
Can you try the attached mem-eater passing it the number of kb to be eaten.
i.e. '# while :; do ./eatm 9999 ; done'
This will print the number of bytes eaten and the timing in ms.
Adjust the number of kb to be eaten such that the timing will be less than
timeslice (120ms by default for spa). Switch to another vt and start
pressing enter. A console lockup should follow within seconds for all spas
except ebs.
Thanks!
--
Al
[-- Attachment #2: eatm.c --]
[-- Type: text/x-csrc, Size: 810 bytes --]
#include <stdio.h>
#include <sys/time.h>
unsigned long elapsed(int start) {
static struct timeval s,e;
if (start) return gettimeofday(&s, NULL);
gettimeofday(&e, NULL);
return ((e.tv_sec - s.tv_sec) * 1000 + (e.tv_usec - s.tv_usec) / 1000);
}
int main(int argc, char **argv) {
unsigned long int i,j,max;
unsigned char *p;
if (argc>1)
max=atol(argv[1]);
else
max=0x60000;
elapsed(1);
for (i=0;((i<max/1024) && (p = (char *)malloc(1024*1024)));i++) {
for (j=0;j<1024;p[1024*j++]=0);
fprintf(stderr,"\r%d MB ",i+1);
}
for (j=max-(i*=1024);((i<max) && (p = (char *)malloc(1024)));i++) {
*p = 0;
}
fprintf(stderr,"%d KB ",j-(max-i));
fprintf(stderr,"eaten in %lu msec (%lu MB/s)\n",elapsed(0),i/(elapsed(0)?:1)*1000/1024);
return 0;
}
^ permalink raw reply
* [Qemu-devel] [PATCH] fix DEBUG_TB_CHECK in exec.c
From: andrzej zaborowski @ 2006-04-07 21:43 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 245 bytes --]
With DEBUG_TB_CHECK enabled, exec.c fails to build. This patch
corrects the compilation errors.
Regards,
Andrew
--
balrog 2oo6
Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258
[-- Attachment #2: qemu-exec-cleanups.patch --]
[-- Type: application/octet-stream, Size: 2380 bytes --]
diff -pNaur qemu/exec.c qemu-omap-clean/exec.c
--- qemu/exec.c 2006-02-08 22:43:39.000000000 +0000
+++ qemu-omap-clean/exec.c 2006-04-07 20:56:55.000000000 +0000
@@ -40,8 +40,8 @@
//#define DEBUG_TLB
/* make various TB consistency checks */
-//#define DEBUG_TB_CHECK
-//#define DEBUG_TLB_CHECK
+//#define DEBUG_TB_CHECK
+//#define DEBUG_TLB_CHECK
/* threshold to flush the translated code buffer */
#define CODE_GEN_BUFFER_MAX_SIZE (CODE_GEN_BUFFER_SIZE - CODE_GEN_MAX_SIZE)
@@ -319,16 +319,17 @@ void tb_flush(CPUState *env1)
#ifdef DEBUG_TB_CHECK
+#ifndef CONFIG_SOFTMMU
static void tb_invalidate_check(unsigned long address)
{
TranslationBlock *tb;
int i;
address &= TARGET_PAGE_MASK;
- for(i = 0;i < CODE_GEN_HASH_SIZE; i++) {
- for(tb = tb_hash[i]; tb != NULL; tb = tb->hash_next) {
+ for(i = 0;i < CODE_GEN_PHYS_HASH_SIZE; i++) {
+ for(tb = tb_phys_hash[i]; tb != NULL; tb = tb->phys_hash_next) {
if (!(address + TARGET_PAGE_SIZE <= tb->pc ||
address >= tb->pc + tb->size)) {
- printf("ERROR invalidate: address=%08lx PC=%08lx size=%04x\n",
+ printf("ERROR invalidate: address=%08lx PC=%08x size=%04x\n",
address, tb->pc, tb->size);
}
}
@@ -341,17 +342,18 @@ static void tb_page_check(void)
TranslationBlock *tb;
int i, flags1, flags2;
- for(i = 0;i < CODE_GEN_HASH_SIZE; i++) {
- for(tb = tb_hash[i]; tb != NULL; tb = tb->hash_next) {
+ for(i = 0;i < CODE_GEN_PHYS_HASH_SIZE; i++) {
+ for(tb = tb_phys_hash[i]; tb != NULL; tb = tb->phys_hash_next) {
flags1 = page_get_flags(tb->pc);
flags2 = page_get_flags(tb->pc + tb->size - 1);
if ((flags1 & PAGE_WRITE) || (flags2 & PAGE_WRITE)) {
- printf("ERROR page flags: PC=%08lx size=%04x f1=%x f2=%x\n",
+ printf("ERROR page flags: PC=%08x size=%04x f1=%x f2=%x\n",
tb->pc, tb->size, flags1, flags2);
}
}
}
}
+#endif
void tb_jmp_check(TranslationBlock *tb)
{
@@ -907,7 +909,7 @@ void tb_link_phys(TranslationBlock *tb,
if (tb->tb_next_offset[1] != 0xffff)
tb_reset_jump(tb, 1);
-#ifdef DEBUG_TB_CHECK
+#if defined(DEBUG_TB_CHECK) && !defined(CONFIG_SOFTMMU)
tb_page_check();
#endif
}
^ permalink raw reply
* Re: [LARTC] __Very__ Low Bandwidth
From: Andy Furniss @ 2006-04-07 21:46 UTC (permalink / raw)
To: lartc
In-Reply-To: <442D44FE.7070105@infomatrix.com>
Matthew Pearson wrote:
> I am using the script below to simulate a very low bandwidth connection.
> I found that I could turn the bandwidth knob down to about 4kbit, but
> below that I didn't get any traffic through. I've had a look at this
> generally, but couldn't find an answer. It doesn't even seem like the
> first reply packet gets through. I have tried it with much bigger
> buffers, but this doesn't help.
>
> I found that if I put a web proxy on the machine that is running this,
> then the minimum I can turn the bandwidth down to is 12kbit and below
> that the web browser doesn't get anything back.
>
> Is this because the delay is so great that things are getting thrown
> away by the kernel? Could I munge the packets to turn up the TTL or
> something similar?
>
> Many thanks for some excellent tools.
>
> Matthew Pearson
>
> #!/bin/bash
>
> CLIENT1\x192.168.1.190/32
> CLIENT2\x192.168.1.191/32
> OPERd;
> DEV=eth0
> RATE=3kbit
> PEAKRATE=3kbit
> BUFFER1\x10kb
> BUFFER2\x10kb
>
> echo -e "Attach Egress policy..."
> tc qdisc $OPER dev $DEV root handle 1:0 htb default 15
> tc class $OPER dev $DEV parent 1:0 classid 1:1 htb rate 240kbit
>
> tc class $OPER dev $DEV parent 1:1 classid 1:2 htb rate 240kbit ceil
> 240kbit
> tc class $OPER dev $DEV parent 1:1 classid 1:3 htb rate 240kbit ceil
> 240kbit
> tc class $OPER dev $DEV parent 1:1 classid 1:15 htb rate 240kbit ceil
> 240kbit
>
> tc qdisc $OPER dev $DEV parent 1:2 handle 2:0 tbf rate $RATE burst $RATE
> limit $BUFFER1 peakrate $PEAKRATE mtu 1600
I don't really get using tbf under htb - but it may be OK.
The reason it fails <12kbit is because you use it for burst - which is a
buffer length so <12kbit won't pass a 1500 byte packet.
Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [PATCH 03/17] uml: fix 2 harmless cast warnings for 64-bit
From: Blaisorblade @ 2006-04-07 21:46 UTC (permalink / raw)
To: Jeff Dike; +Cc: Andrew Morton, linux-kernel, user-mode-linux-devel
In-Reply-To: <20060407160218.GA4962@ccure.user-mode-linux.org>
On Friday 07 April 2006 18:02, Jeff Dike wrote:
> On Fri, Apr 07, 2006 at 04:30:54PM +0200, Paolo 'Blaisorblade' Giarrusso
wrote:
> > From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
> >
> > Fix two harmless warnings in 64-bit compilation (the 2nd doesn't trigger
> > for now because of a missing __attribute((format)) for cow_printf, but
> > next patches fix that).
> I don't object to this bit, but it doesn't seem to match the comment. Was
> there another cast that you meant to have here, but missed?
No, the below one was a whitespace change which slipped in without mention
(but that I confirm).
> > - n = min((size_t)len, ARRAY_SIZE(console_buf) - console_index);
> > + n = min((size_t) len, ARRAY_SIZE(console_buf) - console_index);
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* [uml-devel] Re: [PATCH 03/17] uml: fix 2 harmless cast warnings for 64-bit
From: Blaisorblade @ 2006-04-07 21:46 UTC (permalink / raw)
To: Jeff Dike; +Cc: Andrew Morton, linux-kernel, user-mode-linux-devel
In-Reply-To: <20060407160218.GA4962@ccure.user-mode-linux.org>
On Friday 07 April 2006 18:02, Jeff Dike wrote:
> On Fri, Apr 07, 2006 at 04:30:54PM +0200, Paolo 'Blaisorblade' Giarrusso
wrote:
> > From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
> >
> > Fix two harmless warnings in 64-bit compilation (the 2nd doesn't trigger
> > for now because of a missing __attribute((format)) for cow_printf, but
> > next patches fix that).
> I don't object to this bit, but it doesn't seem to match the comment. Was
> there another cast that you meant to have here, but missed?
No, the below one was a whitespace change which slipped in without mention
(but that I confirm).
> > - n = min((size_t)len, ARRAY_SIZE(console_buf) - console_index);
> > + n = min((size_t) len, ARRAY_SIZE(console_buf) - console_index);
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-07 21:47 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2008>
======================================================================
Reported By: mborsick
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2008
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Redhat/Fedora
Kernel Version: 2.6.16-1.2080 and with Xen
======================================================================
Date Submitted: 04-07-2006 00:43 CEST
Last Modified: 04-07-2006 23:47 CEST
======================================================================
Summary: No Sound with snd-hda-intel driver Asus P5VDC-MX
Description:
Kernel is up-to-date Xen kernel.
Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.
======================================================================
----------------------------------------------------------------------
buboleck - 04-07-06 23:46
----------------------------------------------------------------------
I have disabled my onboard via snd card and sata. Currently I use some
external creative pci card. My board is exatctly the same.
Actually this
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 70)
is the real onboard sound card. And it is detected by kernel, lspci shows
it, but this HDA apears and kills the PCI slots :(.
----------------------------------------------------------------------
rlrevell - 04-07-06 23:47
----------------------------------------------------------------------
If you enable the onboard sound in the BIOS and load snd-via82xx manually
does the onboard sound work? It looks like it should.
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 00:43 mborsick New Issue
04-07-06 00:43 mborsick Distribution => Redhat/Fedora
04-07-06 00:43 mborsick Kernel Version => 2.6.16-1.2080 and
with Xen
04-07-06 01:07 rlrevell Note Added: 0009129
04-07-06 02:13 mborsick Note Added: 0009130
04-07-06 02:35 rlrevell Note Added: 0009131
04-07-06 06:38 mborsick Note Added: 0009135
04-07-06 22:45 buboleck Note Added: 0009156
04-07-06 22:47 buboleck Note Edited: 0009156
04-07-06 22:49 buboleck Note Edited: 0009156
04-07-06 23:06 rlrevell Note Added: 0009157
04-07-06 23:16 buboleck Issue Monitored: buboleck
04-07-06 23:26 buboleck Note Added: 0009158
04-07-06 23:32 rlrevell Note Added: 0009159
04-07-06 23:39 buboleck Note Added: 0009160
04-07-06 23:40 buboleck Note Edited: 0009160
04-07-06 23:43 buboleck Note Edited: 0009160
04-07-06 23:46 buboleck Note Edited: 0009160
04-07-06 23:47 rlrevell Note Added: 0009161
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* RHEL3 kernel panic with md
From: Colin McDonald @ 2006-04-07 21:47 UTC (permalink / raw)
To: linux-raid
I appear to have a corrupt file system and now it is mirrored. LOL.
I am running Redhat Enterprise 3 and using mdtools.
I booted from the install media iso and went into rescue mode. RH was
unable to find the partitions automatically but after exiting into
bash i can run fdisk -l and i see all of the partitions.
I know this is sparse info but would any of the group be able to give
the best approach to getting them mounted and fsck'd?
Thank you in advance
Colin
^ permalink raw reply
* command queueing cmd_per_lun, queue_depth and tags
From: Patrick Mansfield @ 2006-04-07 21:49 UTC (permalink / raw)
To: linux-scsi
Currently cmd_per_lun is the default queue depth for both tagged and
untagged queueing. That is, if the LLDD does not modify queue_depth in its
slave_configure, queue_depth will be set to cmd_per_lun, no matter what
the command queueing/tag support.
If we don't allow queueing in the LLDD, and cmd_per_lun is supposed to be
the default depth for untagged support, shouldn't it always be 1, and
hence go away?
Similarily, why do some LLDD's use a cmd_per_lun of 3, or (like
ncr53c8xx_slave_configure) set queue_depth for !tagged_supported to
anything other than 1?
I know (at least) FCP can always do simple queueing, but I don't think
scsi core should allow multiple commands to be sent if the device does not
have CMDQUE (or BQUE).
It seems more sensible to have cmd_per_lun be more like it was in 2.4,
where it was (generally) the default queue_depth for all devices on an
initiator (all devices on a scsi_host).
Also we don't even check the BQUE in the INQUIRY result (byte 6, bit 7).
Should this be changed? That is set tagged_supported if BQUE is set, like
we do for CMDQUE (byte 7 bit 1). And also set simple_tags if
tagged_supported is set.
That is something like this patch to always set queue_depth to 1 by
default, then later if BQUE or CMDQUE are set, set queue_depth to
cmd_per_lun. Of course slave_configure can still override this, but this
change means queue_depth is 1 if you call scsi_deactivate_tcq().
Using this patch might also require changes in some LLDD's, like ipr.
diff -uprN -X /home/patman/dontdiff /home/linux/views/linux-2.6.17-rc1/drivers/scsi/scsi.c linux-2.6.17-rc1/drivers/scsi/scsi.c
--- /home/linux/views/linux-2.6.17-rc1/drivers/scsi/scsi.c 2006-04-03 11:35:58.000000000 -0700
+++ linux-2.6.17-rc1/drivers/scsi/scsi.c 2006-04-07 10:00:15.000000000 -0700
@@ -866,9 +866,7 @@ EXPORT_SYMBOL(scsi_finish_command);
* Arguments: sdev - SCSI Device in question
* tagged - Do we use tagged queueing (non-0) or do we treat
* this device as an untagged device (0)
- * tags - Number of tags allowed if tagged queueing enabled,
- * or number of commands the low level driver can
- * queue up in non-tagged mode (as per cmd_per_lun).
+ * tags - Number of tags allowed if tagged queueing enabled
*
* Returns: Nothing
*
@@ -883,6 +881,8 @@ void scsi_adjust_queue_depth(struct scsi
{
unsigned long flags;
+ if (!tagged)
+ tags = 1;
/*
* refuse to set tagged depth to an unworkable size
*/
@@ -913,7 +913,6 @@ void scsi_adjust_queue_depth(struct scsi
"disabled\n");
case 0:
sdev->ordered_tags = sdev->simple_tags = 0;
- sdev->queue_depth = tags;
break;
}
out:
@@ -935,8 +934,7 @@ EXPORT_SYMBOL(scsi_adjust_queue_depth);
*
* Returns: 0 - No change needed
* >0 - Adjust queue depth to this new depth
- * -1 - Drop back to untagged operation using host->cmd_per_lun
- * as the untagged command depth
+ * -1 - Drop back to untagged operation
*
* Lock Status: None held on entry
*
@@ -960,7 +958,7 @@ int scsi_track_queue_full(struct scsi_de
return 0;
if (sdev->last_queue_full_depth < 8) {
/* Drop back to untagged */
- scsi_adjust_queue_depth(sdev, 0, sdev->host->cmd_per_lun);
+ scsi_adjust_queue_depth(sdev, 0, 1);
return -1;
}
diff -uprN -X /home/patman/dontdiff /home/linux/views/linux-2.6.17-rc1/drivers/scsi/scsi_scan.c linux-2.6.17-rc1/drivers/scsi/scsi_scan.c
--- /home/linux/views/linux-2.6.17-rc1/drivers/scsi/scsi_scan.c 2006-04-03 11:35:58.000000000 -0700
+++ linux-2.6.17-rc1/drivers/scsi/scsi_scan.c 2006-04-07 09:47:47.000000000 -0700
@@ -256,7 +256,7 @@ static struct scsi_device *scsi_alloc_sd
}
sdev->request_queue->queuedata = sdev;
- scsi_adjust_queue_depth(sdev, 0, sdev->host->cmd_per_lun);
+ scsi_adjust_queue_depth(sdev, 0, 1);
scsi_sysfs_device_initialize(sdev);
@@ -719,9 +719,12 @@ static int scsi_add_lun(struct scsi_devi
* End sysfs code.
*/
- if ((sdev->scsi_level >= SCSI_2) && (inq_result[7] & 2) &&
- !(*bflags & BLIST_NOTQ))
+ if ((sdev->scsi_level >= SCSI_2) && ((inq_result[6] & 0x10) ||
+ (inq_result[7] & 2)) && !(*bflags & BLIST_NOTQ)) {
sdev->tagged_supported = 1;
+ scsi_adjust_queue_depth(sdev, MSG_SIMPLE_TAG,
+ sdev->host->cmd_per_lun);
+ }
/*
* Some devices (Texel CD ROM drives) have handshaking problems
* when used with the Seagate controllers. borken is initialized
-- Patrick Mansfield
^ permalink raw reply
* Re: [PATCH 08/17] uml: prepare fixing compilation output
From: Blaisorblade @ 2006-04-07 21:50 UTC (permalink / raw)
To: Jeff Dike; +Cc: Andrew Morton, linux-kernel, user-mode-linux-devel
In-Reply-To: <20060407160540.GB4962@ccure.user-mode-linux.org>
On Friday 07 April 2006 18:05, Jeff Dike wrote:
> On Fri, Apr 07, 2006 at 04:31:08PM +0200, Paolo 'Blaisorblade' Giarrusso
wrote:
> > Move the build of user-offsets to arch/um/Kbuild, this will allow using
> > the normal user-objs machinery. I had written this to fixup for a Kbuild
> > change, but another fix was merged. This is still useful however.
> What's the benefit of this?
Er, just a style issue - or now it's a little cleanup just for style - I've
thought to merge it anyway, even if I haven't converted it to a standard
rule.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* [uml-devel] Re: [PATCH 08/17] uml: prepare fixing compilation output
From: Blaisorblade @ 2006-04-07 21:50 UTC (permalink / raw)
To: Jeff Dike; +Cc: Andrew Morton, linux-kernel, user-mode-linux-devel
In-Reply-To: <20060407160540.GB4962@ccure.user-mode-linux.org>
On Friday 07 April 2006 18:05, Jeff Dike wrote:
> On Fri, Apr 07, 2006 at 04:31:08PM +0200, Paolo 'Blaisorblade' Giarrusso
wrote:
> > Move the build of user-offsets to arch/um/Kbuild, this will allow using
> > the normal user-objs machinery. I had written this to fixup for a Kbuild
> > change, but another fix was merged. This is still useful however.
> What's the benefit of this?
Er, just a style issue - or now it's a little cleanup just for style - I've
thought to merge it anyway, even if I haven't converted it to a standard
rule.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: Oops at __bio_clone with 2.6.16-rc6 anyone??????
From: Andrew Morton @ 2006-04-07 21:54 UTC (permalink / raw)
To: Don Dupuis; +Cc: linux-kernel
In-Reply-To: <632b79000604071129hf28af6x59d73f6708ccff6b@mail.gmail.com>
"Don Dupuis" <dondster@gmail.com> wrote:
>
> ...
>
> This is the oops output from 2.6.16.1
>
> Apr 7 07:12:52 (none) kernel: Unable to handle kernel paging request at
> virtual address f8000000
> Apr 7 07:12:52 (none) kernel: printing eip:
> Apr 7 07:12:52 (none) kernel: c0155cfd
> Apr 7 07:12:52 (none) kernel: *pde = 00000000
> Apr 7 07:12:52 (none) kernel: Oops: 0000 [#1]
> Apr 7 07:12:52 (none) kernel: SMP
> Apr 7 07:12:52 (none) kernel: Modules linked in:
> Apr 7 07:12:52 (none) kernel: CPU: 1
> Apr 7 07:12:52 (none) kernel: EIP: 0060:[<c0155cfd>] Not tainted VLI
> Apr 7 07:12:52 (none) kernel: EFLAGS: 00010206 (2.6.16.1 #4)
> Apr 7 07:12:52 (none) kernel: EIP is at __bio_clone+0x29/0x9b
> Apr 7 07:12:52 (none) kernel: eax: 00000300 ebx: f5e37280 ecx: 00000082
> edx: f7fffe80
> Apr 7 07:12:52 (none) kernel: esi: f8000000 edi: f7f56a78 ebp: f7ce9b98
> esp: f7ce9b84
> Apr 7 07:12:52 (none) kernel: ds: 007b es: 007b ss: 0068
> Apr 7 07:12:52 (none) kernel: Process ldconfig (pid: 533, threadinfo=f7ce9000
> task=f7c3d540)
> Apr 7 07:12:52 (none) kernel: Stack: <0>f7e29458 f5e37280 f5e37280 f7fffe80
> f5e2b140 f7ce9ba8 c0155d9a f7d9ed98
> Apr 7 07:12:52 (none) kernel: 00000000 f7ce9bf4 c02c7126 00000080
> 00000000 00000e00 c01d2a5c 00000000
> Apr 7 07:12:52 (none) kernel: 0000007f 00000080 f7fffe80 f7e23bc0
> f7e22000 f7fffe80 f7e29458 c015690f
> Apr 7 07:12:52 (none) kernel: Call Trace:
> Apr 7 07:12:52 (none) kernel: [<c0104260>] show_stack_log_lvl+0xa8/0xb0
> Apr 7 07:12:52 (none) kernel: [<c0104397>] show_registers+0x109/0x171
> Apr 7 07:12:52 (none) kernel: [<c010456e>] die+0xfb/0x16f
> Apr 7 07:12:52 (none) kernel: [<c0114754>] do_page_fault+0x359/0x48b
> Apr 7 07:12:52 (none) kernel: [<c0103f0b>] error_code+0x4f/0x54
> Apr 7 07:12:52 (none) kernel: [<c0155d9a>] bio_clone+0x2b/0x31
> Apr 7 07:12:52 (none) kernel: [<c02c7126>] make_request+0x208/0x3d4
> Apr 7 07:12:52 (none) kernel: [<c02c6ff1>] make_request+0xd3/0x3d4
> Apr 7 07:12:52 (none) kernel: [<c01d2a5c>] generic_make_request+0xf5/0x105
> Apr 7 07:12:52 (none) kernel: [<c01d2b0d>] submit_bio+0xa1/0xa9
> Apr 7 07:12:52 (none) kernel: [<c016f307>] mpage_bio_submit+0x1c/0x21
> Apr 7 07:12:52 (none) kernel: [<c016f710>] do_mpage_readpage+0x30b/0x44d
> Apr 7 07:12:52 (none) kernel: [<c016f8df>] mpage_readpages+0x8d/0xf1
> Apr 7 07:12:52 (none) kernel: [<c01a6dc3>] ext3_readpages+0x14/0x16
> Apr 7 07:12:52 (none) kernel: [<c013d867>] read_pages+0x26/0xc6
> Apr 7 07:12:53 (none) kernel: [<c013da20>]
> __do_page_cache_readahead+0x119/0x135
> Apr 7 07:12:53 (none) kernel: [<c013dae4>] do_page_cache_readahead+0x3d/0x49
> Apr 7 07:12:53 (none) kernel: [<c0138c5e>] filemap_nopage+0x149/0x2c9
> Apr 7 07:12:53 (none) kernel: [<c0143528>] do_no_page+0x82/0x245
> Apr 7 07:12:53 (none) kernel: [<c0143855>] __handle_mm_fault+0xf4/0x1ba
> Apr 7 07:12:53 (none) kernel: [<c011456f>] do_page_fault+0x174/0x48b
> Apr 7 07:12:53 (none) kernel: [<c0103f0b>] error_code+0x4f/0x54
> Apr 7 07:12:53 (none) kernel: Code: 5d c3 55 89 e5 57 56 53 51 51 89 45 f0 8b
> 42
We seem to have lost a line of "Code:" there.
Could you please mail me your vmlinux? And a new oops trace, if it's not
the vmlinux which produced the above.
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-07 21:52 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2008>
======================================================================
Reported By: mborsick
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2008
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Redhat/Fedora
Kernel Version: 2.6.16-1.2080 and with Xen
======================================================================
Date Submitted: 04-07-2006 00:43 CEST
Last Modified: 04-07-2006 23:52 CEST
======================================================================
Summary: No Sound with snd-hda-intel driver Asus P5VDC-MX
Description:
Kernel is up-to-date Xen kernel.
Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.
======================================================================
----------------------------------------------------------------------
rlrevell - 04-07-06 23:47
----------------------------------------------------------------------
If you enable the onboard sound in the BIOS and load snd-via82xx manually
does the onboard sound work? It looks like it should.
----------------------------------------------------------------------
buboleck - 04-07-06 23:52
----------------------------------------------------------------------
No it's not working. It plays something just once for about one sec and
stops. If I start again nothing comes out.
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 00:43 mborsick New Issue
04-07-06 00:43 mborsick Distribution => Redhat/Fedora
04-07-06 00:43 mborsick Kernel Version => 2.6.16-1.2080 and
with Xen
04-07-06 01:07 rlrevell Note Added: 0009129
04-07-06 02:13 mborsick Note Added: 0009130
04-07-06 02:35 rlrevell Note Added: 0009131
04-07-06 06:38 mborsick Note Added: 0009135
04-07-06 22:45 buboleck Note Added: 0009156
04-07-06 22:47 buboleck Note Edited: 0009156
04-07-06 22:49 buboleck Note Edited: 0009156
04-07-06 23:06 rlrevell Note Added: 0009157
04-07-06 23:16 buboleck Issue Monitored: buboleck
04-07-06 23:26 buboleck Note Added: 0009158
04-07-06 23:32 rlrevell Note Added: 0009159
04-07-06 23:39 buboleck Note Added: 0009160
04-07-06 23:40 buboleck Note Edited: 0009160
04-07-06 23:43 buboleck Note Edited: 0009160
04-07-06 23:46 buboleck Note Edited: 0009160
04-07-06 23:47 rlrevell Note Added: 0009161
04-07-06 23:52 buboleck Note Added: 0009162
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [PATCH 0/3] [RFC] fixed duration connection
From: Eric Leblond @ 2006-04-07 21:53 UTC (permalink / raw)
To: Patrick McHardy; +Cc: eric, Netfilter Development Mailinglist, nufw-devel
In-Reply-To: <4433CCBF.6060103@trash.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Patrick McHardy wrote:
> Eric Leblond wrote:
>>For this reason, we've worked on a simple kernel level implementation.
>>This is done via a second "struct timer" that is added in connection
>>structure. Activation of the timer, is for now done via userspace by
>>using libnetfilter_conntrack or by using new option -T of the conntrack
>>tool.
>
>
> If I understand you correctly, a fixed timeout is just a timeout that
> isn't refreshed, right? Why can't we just use the regular timers etc.
> and add a flag that it should not be touched by ip_ct_refresh? This
> would also eliminate the need for any ctnetlink changes since the
> timeout value can already be specified.
A set of patch following this recommandation is to follow.
Big thanks to Patrick !
- --
Eric Leblond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFENt9rnxA7CdMWjzIRAjj4AKCCLFCSsT1QRpJ1Cen4PlI0qKseeACfYChO
jlewNiF3gV8IifVWoMfxshI=
=uBaq
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] kzalloc: use in alloc_netdev
From: David S. Miller @ 2006-04-07 21:53 UTC (permalink / raw)
To: akpm; +Cc: blaisorblade, linux-kernel
In-Reply-To: <20060406225232.660e8251.akpm@osdl.org>
From: Andrew Morton <akpm@osdl.org>
Date: Thu, 6 Apr 2006 22:52:32 -0700
> "Paolo 'Blaisorblade' Giarrusso" <blaisorblade@yahoo.it> wrote:
> >
> > Noticed this use, fixed it.
>
> OK, but I think that if we're going to make conversions like this it's best
> to do it in decent-sized chunks, just to keep the patch volume down.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Fix swap entry for MIPS32 36-bit physical address
From: Sergei Shtylyov @ 2006-04-07 22:04 UTC (permalink / raw)
To: linux-mips; +Cc: Bob Breuer, Jordan Crouse, Konstantin Baidarov
In-Reply-To: <4436D793.6080701@ru.mvista.com>
Hello.
Sergei Shtylyov wrote:
> With 64-bit physical address enabled, 'swapon' was causing kernel oops
> on Alchemy CPUs (MIPS32) because of the swap entry type field corrupting
> the _PAGE_FILE bit in pte_low. So, change layout of the swap entry to use
> all bits
> except _PAGE_PRESENT and _PAGE_FILE (the harware protection bits are loaded
> from pte_high which should be cleared by __swp_entry_to_pte() macro) --
> which gives 25 bits for the swap entry offset.
Hm, just noticed that this fix renders set_pte()/pte_clear() erroneous by
reusing _PAGE_GLOBAL (bit 0) in pte_low field of pte_t -- pte_high should have
been used instead or those macros fixed. So, refrain from committing as yet...
WBR, Sergei
> Signed-off-by: Konstantin Baydarov <kbaidarov@ru.mvista.com>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
> ------------------------------------------------------------------------
>
> diff --git a/include/asm-mips/pgtable-32.h b/include/asm-mips/pgtable-32.h
> index 4d6bc45..b0ad112 100644
> --- a/include/asm-mips/pgtable-32.h
> +++ b/include/asm-mips/pgtable-32.h
> @@ -190,11 +190,27 @@ pfn_pte(unsigned long pfn, pgprot_t prot
>
> #else
>
> +#if defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32)
> +/*
> + * For 36-bit physical address we store swap entry in pte_low and 0 in pte_high,
> + * which gives us 25 bits available for the offset...
> + */
> +#define __swp_type(x) ((x).val & 0x1f)
> +#define __swp_offset(x) ((((x).val >> 5) & 0x1) | \
> + (((x).val >> 6) & 0xe) | \
> + (((x).val >> 11) << 4))
> +#define __swp_entry(type,offset) \
> + ((swp_entry_t) { ((type) & 0x1f) | \
> + (((offset) & 0x1) << 5) | \
> + (((offset) & 0xe) << 6) | \
> + (((offset) >> 4 ) << 11) })
> +#else
> /* Swap entries must have VALID and GLOBAL bits cleared. */
> #define __swp_type(x) (((x).val >> 8) & 0x1f)
> #define __swp_offset(x) ((x).val >> 13)
> #define __swp_entry(type,offset) \
> ((swp_entry_t) { ((type) << 8) | ((offset) << 13) })
> +#endif /* defined(CONFIG_64BIT_PHYS_ADDR) && defined(CONFIG_CPU_MIPS32) */
>
> /*
> * Bits 0, 1, 2, 7 and 8 are taken, split up the 27 bits of offset
>
>
^ permalink raw reply
* Re: [PATCH 1/3] [kernel patch] fixed duration connection
From: Eric Leblond @ 2006-04-07 21:57 UTC (permalink / raw)
To: Eric Leblond
Cc: Netfilter Development Mailinglist, Patrick McHardy, nufw-devel
In-Reply-To: <4436DF6B.4060208@inl.fr>
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Here's the patch against Linus git tree.
It simply modifies enum ip_conntrack_status by adding a
IPS_FIXED_TIMEOUT field. This field is then checked at refresh time.
- --
Regit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFENuA+nxA7CdMWjzIRAoedAKCOuZyfUK8CWq3k5UBzZSc+HP1slwCgh00S
PYw7RpDtK/3TwMByLfCihNk=
=+LK+
-----END PGP SIGNATURE-----
[-- Attachment #2: fixed_timeout-flag.patch --]
[-- Type: text/x-patch, Size: 4862 bytes --]
diff --git a/include/linux/netfilter/nf_conntrack_common.h b/include/linux/netfilter/nf_conntrack_common.h
index 3ff88c8..a827ce2 100644
--- a/include/linux/netfilter/nf_conntrack_common.h
+++ b/include/linux/netfilter/nf_conntrack_common.h
@@ -69,6 +69,13 @@ enum ip_conntrack_status {
/* Connection is dying (removed from lists), can not be unset. */
IPS_DYING_BIT = 9,
IPS_DYING = (1 << IPS_DYING_BIT),
+
+#if defined(CONFIG_IP_NF_CT_FIXED_TIMEOUT) || defined(CONFIG_NF_CT_FIXED_TIMEOUT)
+ /* Connection has fixed timeout. */
+ IPS_FIXED_TIMEOUT_BIT = 10,
+ IPS_FIXED_TIMEOUT = (1 << IPS_FIXED_TIMEOUT_BIT),
+#endif
+
};
/* Connection tracking event bits */
diff --git a/include/linux/netfilter/nfnetlink_conntrack.h b/include/linux/netfilter/nfnetlink_conntrack.h
diff --git a/include/linux/netfilter_ipv4/ip_conntrack.h b/include/linux/netfilter_ipv4/ip_conntrack.h
index d54d7b2..44f6e33 100644
--- a/include/linux/netfilter_ipv4/ip_conntrack.h
+++ b/include/linux/netfilter_ipv4/ip_conntrack.h
@@ -85,6 +85,7 @@ struct ip_conntrack
/* Timer function; drops refcnt when it goes off. */
struct timer_list timeout;
+
#ifdef CONFIG_IP_NF_CT_ACCT
/* Accounting Information (same cache line as other written members) */
struct ip_conntrack_counter counters[IP_CT_DIR_MAX];
@@ -292,6 +293,13 @@ static inline int is_dying(struct ip_con
return test_bit(IPS_DYING_BIT, &ct->status);
}
+#if defined(CONFIG_IP_NF_CT_FIXED_TIMEOUT) || defined(CONFIG_NF_CT_FIXED_TIMEOUT)
+static inline int is_fixedtimeout(struct ip_conntrack *ct)
+{
+ return test_bit(IPS_FIXED_TIMEOUT_BIT, &ct->status);
+}
+#endif
+
extern unsigned int ip_conntrack_htable_size;
#define CONNTRACK_STAT_INC(count) (__get_cpu_var(ip_conntrack_stat).count++)
diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
index 77855cc..1f306ec 100644
--- a/net/ipv4/netfilter/Kconfig
+++ b/net/ipv4/netfilter/Kconfig
@@ -46,6 +46,18 @@ config IP_NF_CT_ACCT
If unsure, say `N'.
+config IP_NF_CT_FIXED_TIMEOUT
+ bool "Connection tracking fixed timeout (EXPERIMENTAL)"
+ depends on EXPERIMENTAL && IP_NF_CONNTRACK
+ help
+ If this option is enabled, the connection tracking code will
+ be able to have connection that will expire automatically after
+ a given time.
+
+ This feature can be used with libnetfilter_conntrack library.
+
+ If unsure, say `N'.
+
config IP_NF_CONNTRACK_MARK
bool 'Connection mark tracking support'
depends on IP_NF_CONNTRACK
diff --git a/net/ipv4/netfilter/ip_conntrack_core.c b/net/ipv4/netfilter/ip_conntrack_core.c
index ceaabc1..44fa788 100644
--- a/net/ipv4/netfilter/ip_conntrack_core.c
+++ b/net/ipv4/netfilter/ip_conntrack_core.c
@@ -1130,18 +1130,27 @@ void __ip_ct_refresh_acct(struct ip_conn
write_lock_bh(&ip_conntrack_lock);
- /* If not in hash table, timer will not be active yet */
- if (!is_confirmed(ct)) {
- ct->timeout.expires = extra_jiffies;
- event = IPCT_REFRESH;
- } else {
- /* Need del_timer for race avoidance (may already be dying). */
- if (del_timer(&ct->timeout)) {
- ct->timeout.expires = jiffies + extra_jiffies;
- add_timer(&ct->timeout);
- event = IPCT_REFRESH;
- }
- }
+#if defined(CONFIG_IP_NF_CT_FIXED_TIMEOUT) || defined(CONFIG_NF_CT_FIXED_TIMEOUT)
+ /* only update if this is not a fixed timeout */
+ if (! is_fixedtimeout(ct)){
+#endif
+ /* If not in hash table, timer will not be active yet */
+ if (!is_confirmed(ct)) {
+ ct->timeout.expires = extra_jiffies;
+ event = IPCT_REFRESH;
+ } else {
+ /* Need del_timer for race avoidance (may already be dying). */
+ if (del_timer(&ct->timeout)) {
+ ct->timeout.expires = jiffies + extra_jiffies;
+ add_timer(&ct->timeout);
+ event = IPCT_REFRESH;
+ }
+ }
+#if defined(CONFIG_IP_NF_CT_FIXED_TIMEOUT)
+ } else {
+ DEBUGP("FIXED TIMEOUT: Not updating\n");
+ }
+#endif
#ifdef CONFIG_IP_NF_CT_ACCT
if (do_acct) {
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index e2893ef..8c24fc4 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -60,6 +60,18 @@ config NF_CONNTRACK_MARK
of packets, but this mark value is kept in the conntrack session
instead of the individual packets.
+config CONFIG_NF_CT_FIXED_TIMEOUT
+ bool "Connection with fixed expiration delay (EXPERIMENTAL)"
+ depends on EXPERIMENTAL && NF_CONNTRACK
+ help
+ If this option is enabled, the connection tracking code will
+ be able to have connection that will expire automatically after
+ a given time.
+
+ This feature can be used with libnetfilter_conntrack library.
+
+ If unsure, say `N'.
+
config NF_CONNTRACK_EVENTS
bool "Connection tracking events (EXPERIMENTAL)"
depends on EXPERIMENTAL && NF_CONNTRACK
^ permalink raw reply related
* Re: [PATCH 2/3] [libnetfilter_conntrack] fixed duration connection
From: Eric Leblond @ 2006-04-07 21:59 UTC (permalink / raw)
To: Netfilter Development Mailinglist; +Cc: Patrick McHardy, nufw-devel
In-Reply-To: <4436DF6B.4060208@inl.fr>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Hi,
This patch add support for the IPS_FIXED_TIMEOUT state.
BR,
--
Regit
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: libnetfilter_conntrack_fixed_timeout-flag.patch --]
[-- Type: text/x-patch; name="libnetfilter_conntrack_fixed_timeout-flag.patch", Size: 4108 bytes --]
Index: include/libnetfilter_conntrack/linux_nfnetlink_conntrack.h
===================================================================
--- include/libnetfilter_conntrack/linux_nfnetlink_conntrack.h (révision 6576)
+++ include/libnetfilter_conntrack/linux_nfnetlink_conntrack.h (copie de travail)
@@ -29,6 +29,7 @@
CTA_HELP,
CTA_NAT,
CTA_TIMEOUT,
+ CTA_FIXED_TIMEOUT,
CTA_MARK,
CTA_COUNTERS_ORIG,
CTA_COUNTERS_REPLY,
Index: include/libnetfilter_conntrack/libnetfilter_conntrack.h
===================================================================
--- include/libnetfilter_conntrack/libnetfilter_conntrack.h (révision 6576)
+++ include/libnetfilter_conntrack/libnetfilter_conntrack.h (copie de travail)
@@ -89,6 +89,7 @@
struct nfct_tuple tuple[NFCT_DIR_MAX];
u_int32_t timeout;
+ u_int32_t fixed_timeout;
u_int32_t mark;
u_int32_t status;
u_int32_t use;
@@ -125,19 +126,22 @@
NFCT_TIMEOUT_BIT = 2,
NFCT_TIMEOUT = (1 << NFCT_TIMEOUT_BIT),
- NFCT_MARK_BIT = 3,
+ NFCT_FIXED_TIMEOUT_BIT = 3,
+ NFCT_FIXED_TIMEOUT = (1 << NFCT_FIXED_TIMEOUT_BIT),
+
+ NFCT_MARK_BIT = 4,
NFCT_MARK = (1 << NFCT_MARK_BIT),
- NFCT_COUNTERS_ORIG_BIT = 4,
+ NFCT_COUNTERS_ORIG_BIT = 5,
NFCT_COUNTERS_ORIG = (1 << NFCT_COUNTERS_ORIG_BIT),
- NFCT_COUNTERS_RPLY_BIT = 5,
+ NFCT_COUNTERS_RPLY_BIT = 6,
NFCT_COUNTERS_RPLY = (1 << NFCT_COUNTERS_RPLY_BIT),
- NFCT_USE_BIT = 6,
+ NFCT_USE_BIT = 7,
NFCT_USE = (1 << NFCT_USE_BIT),
- NFCT_ID_BIT = 7,
+ NFCT_ID_BIT = 8,
NFCT_ID = (1 << NFCT_ID_BIT)
};
Index: src/libnetfilter_conntrack.c
===================================================================
--- src/libnetfilter_conntrack.c (révision 6576)
+++ src/libnetfilter_conntrack.c (copie de travail)
@@ -548,6 +548,11 @@
flags |= NFCT_TIMEOUT;
}
+ if (cda[CTA_FIXED_TIMEOUT-1]) {
+ ct.fixed_timeout = ntohl(*(u_int32_t *)NFA_DATA(cda[CTA_FIXED_TIMEOUT-1]));
+ flags |= NFCT_FIXED_TIMEOUT;
+ }
+
if (cda[CTA_MARK-1]) {
ct.mark = ntohl(*(u_int32_t *)NFA_DATA(cda[CTA_MARK-1]));
flags |= NFCT_MARK;
@@ -596,6 +601,13 @@
return sprintf(buf, "%u ", ct->timeout);
}
+int nfct_sprintf_fixed_timeout(char *buf, struct nfct_conntrack *ct)
+{
+ return sprintf(buf, "%u ", ct->fixed_timeout);
+}
+
+
+
int nfct_sprintf_protoinfo(char *buf, struct nfct_conntrack *ct)
{
int size = 0;
@@ -664,7 +676,10 @@
if (flags & NFCT_TIMEOUT)
size += nfct_sprintf_timeout(buf+size, ct);
- if (flags & NFCT_PROTOINFO)
+ if (flags & NFCT_FIXED_TIMEOUT)
+ size += nfct_sprintf_fixed_timeout(buf+size, ct);
+
+ if (flags & NFCT_PROTOINFO)
size += nfct_sprintf_protoinfo(buf+size, ct);
size += nfct_sprintf_address(buf+size, &ct->tuple[NFCT_DIR_ORIGINAL]);
@@ -954,6 +969,7 @@
char buf[NFCT_BUFSIZE];
u_int32_t status = htonl(ct->status | IPS_CONFIRMED);
u_int32_t timeout = htonl(ct->timeout);
+ u_int32_t fixed_timeout = htonl(ct->fixed_timeout);
u_int32_t mark = htonl(ct->mark);
u_int8_t l3num = ct->tuple[NFCT_DIR_ORIGINAL].l3protonum;
@@ -975,6 +991,10 @@
nfnl_addattr_l(&req->nlh, sizeof(buf), CTA_TIMEOUT, &timeout,
sizeof(u_int32_t));
+
+ if (fixed_timeout)
+ nfnl_addattr_l(&req->nlh, sizeof(buf), CTA_FIXED_TIMEOUT, &fixed_timeout,
+ sizeof(u_int32_t));
if (ct->mark != 0)
nfnl_addattr_l(&req->nlh, sizeof(buf), CTA_MARK, &mark,
@@ -993,6 +1013,7 @@
char buf[NFCT_BUFSIZE];
u_int32_t status = htonl(ct->status | IPS_CONFIRMED);
u_int32_t timeout = htonl(ct->timeout);
+ u_int32_t fixed_timeout = htonl(ct->fixed_timeout);
u_int32_t id = htonl(ct->id);
u_int32_t mark = htonl(ct->mark);
u_int8_t l3num = ct->tuple[NFCT_DIR_ORIGINAL].l3protonum;
@@ -1015,7 +1036,12 @@
if (ct->timeout != 0)
nfnl_addattr_l(&req->nlh, sizeof(buf), CTA_TIMEOUT, &timeout,
sizeof(u_int32_t));
+
+ if (ct->fixed_timeout != 0)
+ nfnl_addattr_l(&req->nlh, sizeof(buf), CTA_FIXED_TIMEOUT, &fixed_timeout,
+ sizeof(u_int32_t));
+
if (ct->mark != 0)
nfnl_addattr_l(&req->nlh, sizeof(buf), CTA_MARK, &mark,
sizeof(u_int32_t));
^ permalink raw reply
* [U-Boot-Users] PATCH: CFG_GPIO0_OR and CFG_GPIO0_ODR to setup GPIO completely
From: Tolunay Orkun @ 2006-04-07 22:00 UTC (permalink / raw)
To: u-boot
Re: http://sf.net/mailarchive/forum.php?thread_id=10122605&forum_id=12898
CHANGELOG:
* (ppc4xx) Add CFG_GPIO0_OR, CFG_GPIO0_ODR to setup GPIO completely.
- Add configuration of Open Drain GPIO Output selection
- Add configuration of initial value of GPIO output pins
Sign-off-by: Tolunay Orkun <listmember@orkun.us>
diff --git a/cpu/ppc4xx/cpu_init.c b/cpu/ppc4xx/cpu_init.c
index 1a139d7..761fcf7 100644
--- a/cpu/ppc4xx/cpu_init.c
+++ b/cpu/ppc4xx/cpu_init.c
@@ -115,6 +115,12 @@ cpu_init_f (void)
/*
* GPIO0 setup (select GPIO or alternate function)
*/
+#if defined(CFG_GPIO0_OR)
+ out32(GPIO0_OR, CFG_GPIO0_OR); /* set initial state of output pins */
+#endif
+#if defined(CFG_GPIO0_ODR)
+ out32(GPIO0_ODR, CFG_GPIO0_ODR); /* open-drain select */
+#endif
out32(GPIO0_OSRH, CFG_GPIO0_OSRH); /* output select */
out32(GPIO0_OSRL, CFG_GPIO0_OSRL);
out32(GPIO0_ISR1H, CFG_GPIO0_ISR1H); /* input select */
^ permalink raw reply related
* Re: [PATCH 2.6.17-rc1-mm1] m32r: Fix cpu_possible_map and cpu_present_map initialization for SMP kernel
From: Andrew Morton @ 2006-04-07 22:03 UTC (permalink / raw)
To: Hirokazu Takata; +Cc: linux-kernel, fujiwara, takata
In-Reply-To: <20060407.194745.233672521.takata.hirokazu@renesas.com>
Hirokazu Takata <takata@linux-m32r.org> wrote:
>
> This patch fixes a boot problem of the m32r SMP kernel
> 2.6.16-rc1-mm3 or later.
This sounds like something which needs to be backported into 2.6.16.x,
correct?
Also, should "m32r: security fix of {get,put}_user macros" go into 2.6.16.x?
^ permalink raw reply
* Re: [PATCH 0/3] [conntrack] fixed duration connection
From: Eric Leblond @ 2006-04-07 22:01 UTC (permalink / raw)
To: Netfilter Development Mailinglist; +Cc: Patrick McHardy, nufw-devel
In-Reply-To: <4436DF6B.4060208@inl.fr>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
This patch against conntrack tool adds support for fixed connection. for
example :
conntrack -U -d 153.113.34.136 -s 192.168.11.32 -p tcp \\
--orig-port-src 59119 --orig-port-dst 22 -t 10 \\
-u ASSURED,SEEN_REPLY,FIXED_TIMEOUT
will fix timeout of connection to 10 seconds after command.
BR,
- --
Regit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFENuFWnxA7CdMWjzIRAqu2AJ4oOokoHVGh5KWxBv/nahkc4OtIDwCfRsqV
bPL3bs87V4eM/ymbSlnP/vc=
=IjGO
-----END PGP SIGNATURE-----
^ 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.