* Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)
@ 2003-07-18 14:14 82% ` Marcelo Tosatti
2003-07-18 15:13 82% ` Stephan von Krawczynski
0 siblings, 1 reply; 200+ results
From: Marcelo Tosatti @ 2003-07-18 14:14 UTC (permalink / raw)
To: Stephan von Krawczynski
Cc: Chris Mason, Andrea Arcangeli, riel, lkml, Jim Gifford
I have just started stress testing a 8way OSDL box to see if I can
reproduce the problem. I'm using pre6+axboes BH_Sync patch.
I'm running 50 dbench clients on aic7xxx (ext2) and 50 dbench clients on
DAC960 (ext3). Lets see what happens.
After lunch I'll keep looking at the oopses. During the morning I only had
time to setup the OSDL box and start the tests.
On Fri, 18 Jul 2003, Stephan von Krawczynski wrote:
> On Fri, 18 Jul 2003 09:23:10 -0300 (BRT)
> Marcelo Tosatti <marcelo@conectiva.com.br> wrote:
>
> >
> > CCed lkml for obvious reasons
> >
> > On Fri, 18 Jul 2003, Stephan von Krawczynski wrote:
> >
> > > On Wed, 16 Jul 2003 08:37:51 -0300 (BRT)
> > > Marcelo Tosatti <marcelo@conectiva.com.br> wrote:
> > >
> > > >
> > > > Stephan, can you reproduce it easily?
> > >
> > > Hello,
> > >
> > > there is definitely something about it. pre6 froze after 2 days of
> > > testing. I guess I was unlucky this time with logfiles, no messages
> > > there. There is something severe. You may call it reproducable, but not
> > > easy.
> >
> > Stephan,
> >
> > What is your workload?
> >
> > I'll try to reproduce it.
^ permalink raw reply [relevance 82%]
* Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)
2003-07-18 14:14 82% ` Marcelo Tosatti
@ 2003-07-18 15:13 82% ` Stephan von Krawczynski
0 siblings, 0 replies; 200+ results
From: Stephan von Krawczynski @ 2003-07-18 15:13 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: mason, andrea, riel, linux-kernel, maillist
On Fri, 18 Jul 2003 11:14:15 -0300 (BRT)
Marcelo Tosatti <marcelo@conectiva.com.br> wrote:
>
> I have just started stress testing a 8way OSDL box to see if I can
> reproduce the problem. I'm using pre6+axboes BH_Sync patch.
>
> I'm running 50 dbench clients on aic7xxx (ext2) and 50 dbench clients on
> DAC960 (ext3). Lets see what happens.
>
> After lunch I'll keep looking at the oopses. During the morning I only had
> time to setup the OSDL box and start the tests.
On my box it takes about 48 hours before the problem shows. But that may
heavily depend on the box I guess.
Regards,
Stephan
^ permalink raw reply [relevance 82%]
* Re: Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd)
[not found] ` <20030718112758.1da7ab03.skraw@ithnet.com>
@ 2003-07-18 12:23 82% ` Marcelo Tosatti
0 siblings, 1 reply; 200+ results
From: Marcelo Tosatti @ 2003-07-18 12:23 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: Chris Mason, Andrea Arcangeli, riel, lkml
CCed lkml for obvious reasons
On Fri, 18 Jul 2003, Stephan von Krawczynski wrote:
> On Wed, 16 Jul 2003 08:37:51 -0300 (BRT)
> Marcelo Tosatti <marcelo@conectiva.com.br> wrote:
>
> >
> > Stephan, can you reproduce it easily?
>
> Hello,
>
> there is definitely something about it. pre6 froze after 2 days of
> testing. I guess I was unlucky this time with logfiles, no messages
> there. There is something severe. You may call it reproducable, but not
> easy.
Stephan,
What is your workload?
I'll try to reproduce it.
^ permalink raw reply [relevance 82%]
* Re: [BUG] kernel BUG at kernel/timer.c 2.6.0-test1
2003-07-16 6:06 82% ` Paul Rolland
@ 2003-07-17 8:06 82% ` Rafal Bujnowski
0 siblings, 0 replies; 200+ results
From: Rafal Bujnowski @ 2003-07-17 8:06 UTC (permalink / raw)
To: linux-kernel; +Cc: Paul Rolland
A "Paul Rolland" <rol@as2917.net> na to:
> Hello,
>
> Are you using ide-scsi ? I though (from I got from the list some
> time ago) that it was not working with 2.5.x kernels, and that
> we had to use ide-cd instead...
Hello,
Yes, I use ide-scsi. Ide-cd doesn't work for me. Even I tried to unset
"preemptible kernel" in config as was mentioned on lkml. But... still
nothing.
So I have to use 2.4.20 instead of 2.6.x.
Rafal
--
[ Rafal Bujnowski ][ e-mail: bujnor<at>go2.pl ]
[ http://www.bujnor.iq.pl/ ][ e-mail: bujnor<at>poczta.onet.pl ]
[ ICQ: 85602025 GG: 4174829 ][ Jabber: bujnor<at>jabberpl.org ]
^ permalink raw reply [relevance 82%]
* Re: [BUG] kernel BUG at kernel/timer.c 2.6.0-test1
@ 2003-07-16 6:06 82% ` Paul Rolland
2003-07-17 8:06 82% ` Rafal Bujnowski
0 siblings, 1 reply; 200+ results
From: Paul Rolland @ 2003-07-16 6:06 UTC (permalink / raw)
To: 'Rafal Bujnowski', 'linux-kernel'
Hello,
Are you using ide-scsi ? I though (from I got from the list some
time ago) that it was not working with 2.5.x kernels, and that
we had to use ide-cd instead...
Regards,
Paul
>
> I have something like that in my kernel-log. I had the same on 2.5.75.
> It happens during cd burning (cd audio).
>
> kernel: ------------[ cut here ]------------
> kernel: kernel BUG at kernel/timer.c:166!
> kernel: invalid operand: 0000 [#1]
> kernel: CPU: 0
> kernel: EIP: 0060:[add_timer+151/176] Not tainted
> kernel: EFLAGS: 00010002
> kernel: EIP is at add_timer+0x97/0xb0
> kernel: eax: 00000001 ebx: e3c74000 ecx: c0361b00 edx: c040470c
> kernel: esi: 00000000 edi: e3cee2a4 ebp: e3c75ed0 esp: e3c75ebc
> kernel: ds: 007b es: 007b ss: 0068
> kernel: Process scsi_eh_0 (pid: 9, threadinfo=e3c74000 task=e3ccc680)
> kernel: Stack: 00000046 00000032 e3c74000 00000000 c040470c e3c75f00
> c02755a7 e3cee2a4
> kernel: c0274f80 00000032 00000000 e3cee280 c0404660 00000096
> 00000000 c040470c
> bujnor kernel: c040471c e3c75f10 c02755e9 c040470c 00000000
> e3c75f30 c0290f1f c040470c
> kernel: Call Trace:
> kernel: [do_reset1+567/608] do_reset1+0x237/0x260
> kernel: [atapi_reset_pollfunc+0/288] atapi_reset_pollfunc+0x0/0x120
> kernel: [ide_do_reset+25/32] ide_do_reset+0x19/0x20
> kernel: [idescsi_reset+223/288] idescsi_reset+0xdf/0x120
> kernel: [scsi_try_bus_device_reset+84/144]
> scsi_try_bus_device_reset+0x54/0x90
> kernel: [scsi_eh_bus_device_reset+102/288]
> scsi_eh_bus_device_reset+0x66/0x120
> kernel: [scsi_eh_ready_devs+40/112] scsi_eh_ready_devs+0x28/0x70
> kernel: [scsi_unjam_host+192/208] scsi_unjam_host+0xc0/0xd0
> kernel: [scsi_error_handler+218/288] scsi_error_handler+0xda/0x120
> kernel: [scsi_error_handler+0/288] scsi_error_handler+0x0/0x120
> kernel: [kernel_thread_helper+5/12] kernel_thread_helper+0x5/0xc
> kernel:
> kernel: Code: 0f 0b a6 00 cb 38 31 c0 eb 8e eb 0d 90 90 90
> 90 90 90 90 90
> kernel: <6>note: scsi_eh_0[9] exited with preempt_count 3
> kernel: hdc: ATAPI reset timed-out, status=0xd0
> kernel: hdd: DMA disabled
>
>
> And from cdrecord 2.0:
>
> Starting new track at sector: 0
> Track 01: 50 of 50 MB written (fifo 100%) [buf 99%] 4.2x.
> Track 01: Total bytes read/written: 53404512/53404512 (22706 sectors).
> Starting new track at sector: 22858
> Track 02: 29 of 31 MB written (fifo 100%) [buf 99%]
> 4.2x.cdrecord: faio_wait_on_buffer for writer timed out.
>
>
> Regards,
>
> rafal
>
>
> --
>
> [ Rafal Bujnowski ][ e-mail: bujnor<at>go2.pl
> ]
> [ http://www.bujnor.iq.pl/ ][ e-mail:
> bujnor<at>poczta.onet.pl ]
> [ ICQ: 85602025 GG: 4174829 ][ Jabber:
> bujnor<at>jabberpl.org ]
> -
> 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 [relevance 82%]
* Re: am-utils or kernel bug ? Seems to be kernel bug.. Any news ?
2003-07-15 16:18 82% ` Nicolas Turro
@ 2003-07-16 3:28 82% ` Philippe Troin
0 siblings, 0 replies; 200+ results
From: Philippe Troin @ 2003-07-16 3:28 UTC (permalink / raw)
To: Nicolas Turro; +Cc: linux-kernel, amd-dev
Nicolas Turro <Nicolas.Turro@sophia.inria.fr> writes:
> On Tue, 2003-07-15 at 16:35, Philippe Troin wrote:
> > Nicolas Turro <Nicolas.Turro@sophia.inria.fr> writes:
> >
> > > Hi, i posted a bug about amd hanging at boot time a few week ago,
> > > does anybody has a fix for it ?
> > > The bug is described here :
> > >
> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90902
> > >
> > > it seems that several groups of users besides me encounter the same
> > > bug....
> > >
> > > If not, i'll have to post-install a 2.4.18 kernel on all my new
> > > RH9 boxes :-(
> >
> > Looks like YAFP (Yet Another Futex Problem).
> >
> > Have you tried running with LD_ASSUME_KERNEL=2.2.5 ?
>
> You are right, setting LD_ASSUME_KERNEL=2.2.5 (or
> LD_ASSUME_KERNEL=2.4.1) corrects the problem.
> Do you have more info on this ´bug' ?
As a rule of thumb, whenever a program deadlocks in a futex call,
setting this variable to a < 2.5.x value might prevent the deadlock.
Google around for the exact reason why.
AFAIU, it's a RH 9.0 bug.
Phil.
^ permalink raw reply [relevance 82%]
* Re: am-utils or kernel bug ? Seems to be kernel bug.. Any news ?
2003-07-15 14:35 82% ` Philippe Troin
@ 2003-07-15 16:18 82% ` Nicolas Turro
2003-07-16 3:28 82% ` Philippe Troin
0 siblings, 1 reply; 200+ results
From: Nicolas Turro @ 2003-07-15 16:18 UTC (permalink / raw)
To: Philippe Troin; +Cc: linux-kernel, amd-dev
On Tue, 2003-07-15 at 16:35, Philippe Troin wrote:
> Nicolas Turro <Nicolas.Turro@sophia.inria.fr> writes:
>
> > Hi, i posted a bug about amd hanging at boot time a few week ago,
> > does anybody has a fix for it ?
> > The bug is described here :
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90902
> >
> > it seems that several groups of users besides me encounter the same
> > bug....
> >
> > If not, i'll have to post-install a 2.4.18 kernel on all my new
> > RH9 boxes :-(
>
> Looks like YAFP (Yet Another Futex Problem).
>
> Have you tried running with LD_ASSUME_KERNEL=2.2.5 ?
>
> Phil.
You are right, setting LD_ASSUME_KERNEL=2.2.5 (or
LD_ASSUME_KERNEL=2.4.1) corrects the problem.
Do you have more info on this ´bug' ?
--
Nicolas Turro <Nicolas.Turro@sophia.inria.fr>
INRIA
^ permalink raw reply [relevance 82%]
* Re: am-utils or kernel bug ? Seems to be kernel bug.. Any news ?
2003-07-15 8:34 82% am-utils or kernel bug ? Seems to be kernel bug.. Any news ? Nicolas Turro
@ 2003-07-15 14:35 82% ` Philippe Troin
2003-07-15 16:18 82% ` Nicolas Turro
0 siblings, 1 reply; 200+ results
From: Philippe Troin @ 2003-07-15 14:35 UTC (permalink / raw)
To: Nicolas Turro; +Cc: linux-kernel, amd-dev
Nicolas Turro <Nicolas.Turro@sophia.inria.fr> writes:
> Hi, i posted a bug about amd hanging at boot time a few week ago,
> does anybody has a fix for it ?
> The bug is described here :
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90902
>
> it seems that several groups of users besides me encounter the same
> bug....
>
> If not, i'll have to post-install a 2.4.18 kernel on all my new
> RH9 boxes :-(
Looks like YAFP (Yet Another Futex Problem).
Have you tried running with LD_ASSUME_KERNEL=2.2.5 ?
Phil.
^ permalink raw reply [relevance 82%]
* Re: am-utils or kernel bug ? Seems to be kernel bug.. Any news ?
@ 2003-07-15 8:34 82% Nicolas Turro
2003-07-15 14:35 82% ` Philippe Troin
0 siblings, 1 reply; 200+ results
From: Nicolas Turro @ 2003-07-15 8:34 UTC (permalink / raw)
To: linux-kernel, amd-dev
Hi, i posted a bug about amd hanging at boot time a few week ago,
does anybody has a fix for it ?
The bug is described here :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90902
it seems that several groups of users besides me encounter the same
bug....
If not, i'll have to post-install a 2.4.18 kernel on all my new
RH9 boxes :-(
--
Nicolas Turro <Nicolas.Turro@sophia.inria.fr>
INRIA
^ permalink raw reply [relevance 82%]
* Re: [Bug 892] New: kernel BUG at include/linux/list.h:148!
@ 2003-07-09 5:21 82% ` Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2003-07-09 5:21 UTC (permalink / raw)
To: ramon.rey; +Cc: linux-kernel
"Martin J. Bligh" <mbligh@aracnet.com> wrote:
>
> kernel BUG at include/linux/list.h:148!
> EIP is at remove_wait_queue+0x59/0x80
> Call Trace:
> [<c0194a85>] devfs_d_revalidate_wait+0x145/0x160
> [<c0116f60>] default_wake_function+0x0/0x20
> [<c0116f60>] default_wake_function+0x0/0x20
> [<c01574e4>] do_lookup+0x44/0x80
> [<c015796e>] link_path_walk+0x44e/0x840
> [<c01585ea>] open_namei+0x8a/0x3a0
There will be a patch in 2.5.74-mm3 which should fix this. If you know how
to reproduce the bug, please test that kernel.
^ permalink raw reply [relevance 82%]
* Re: [Bug 810] New: Kernel BUG at mm/slab.c:981
@ 2003-06-15 18:38 82% ` Michael Buesch
0 siblings, 0 replies; 200+ results
From: Michael Buesch @ 2003-06-15 18:38 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 15 June 2003 20:20, Martin J. Bligh wrote:
> Summary: Kernel BUG at mm/slab.c:981
> Kernel Version: 2.5.70-71
> Status: NEW
> Severity: blocking
> Owner: akpm@digeo.com
> Submitter: s_aldinger@hotmail.com
>
>
> Since .69 I've been unable to boot. no config changes. I had to write this
> out and then type so if something looks really off it might be a typo, give
> a shout and I'll check it.
>
> Kernel BUG at mm/slab.c:981
> invalid operand:0000 [#1]
> cpu: 0
> EIP: 0060:[<c0136eca>] Not tainted
> Eflags: 00010202
> eax: 000001a8 ebx:c053a5c0 ecx:c04ae990 edx:00001797
> esi:00000000 edi:00000000 esp:c153ff6c
> ds:007b es:007b ss:0068
> Process swapper (pid: 1, threadinfo=c153e000 task=c151d880)
> Stack: ffffe869 00000029 0000000292 0000176b 00001797 c0546829
> 00000246 c011b51e c053a5c0
> 00000000 00000000 00000000 c01d5046 c04464b8 000001a8 00000000
> 00000001
> c01d4ff2 00000000 c0527e9c c0451f20 c053a5c0 c051cbbd
> 00000000
> Call Trace [<c011b51e>] [<c01d5046>] [<c01d4ff2>] [<c0527e9c>]
> [<c051c6bd>] [<c0128542>] [<c0105051>] [<c010502c>]
> [<c010895d>]
> code: 0f 0b d5 03 60 28 44 c0 c7 44 24 04 d0 00 00 00 c7 04 24 e0
> <0> Kernel panic: Attempted to kill init!
Without ksymoops'ing it, IMHO it's rather useless. :)
- --
Regards Michael Büsch
http://www.8ung.at/tuxsoft
20:37:12 up 4:21, 2 users, load average: 1.05, 1.03, 1.00
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+7L0KoxoigfggmSgRAmzsAJ9GY1iHazGXAxjms/zf84oMtKwy7wCdHsWV
0Y+QKGR5idPA1mvL+ZLFh8M=
=5uKV
-----END PGP SIGNATURE-----
^ permalink raw reply [relevance 82%]
* Re: [BUG] 2.4.21 - kernel BUG at dev.c:991
@ 2003-06-14 8:04 82% ` Christopher S. Aker
0 siblings, 0 replies; 200+ results
From: Christopher S. Aker @ 2003-06-14 8:04 UTC (permalink / raw)
To: linux-kernel
> I'm experiencing a reproducible "kernel BUG at dev.c:991!" call from
> core/net/dev.c in 2.4.21.
I'm able to make things work by using the eepro100 driver instead of intel's e100.
-Chris
^ permalink raw reply [relevance 82%]
* Unconfirmed bug reports in my bug database
@ 2003-06-03 13:54 82% john
0 siblings, 0 replies; 200+ results
From: john @ 2003-06-03 13:54 UTC (permalink / raw)
To: linux-kernel
I've got quite a few active bug reports in my bug database, which are not attached to any confirmed bugs:
http://grabjohn.com/kernelbugdatabase/index.php?action=21&id=56&session=
http://grabjohn.com/kernelbugdatabase/index.php?action=21&id=53&session=
http://grabjohn.com/kernelbugdatabase/index.php?action=21&id=46&session=
http://grabjohn.com/kernelbugdatabase/index.php?action=21&id=45&session=
http://grabjohn.com/kernelbugdatabase/index.php?action=21&id=28&session=
http://grabjohn.com/kernelbugdatabase/index.php?action=21&id=19&session=
If anybody can confirm that these are reproducable, not reproducable, or that fixes have gone in to any particular kernel, please let me know, or update the database yourself.
By the way, some more feedback on this bug database would be appreciated - do people like it, hate it, not care, or what? There is no need to create an account to use it anymore, by the way, and there hasn't been for a few months now - you can just use the links at the top to navigate through it regardless of whether you're logged in or not.
John.
^ permalink raw reply [relevance 82%]
* Re: FW: am-utils or kernel bug ? Seems to be kernel or glibc bug...
2003-05-14 8:27 82% ` FW: am-utils or kernel bug ? Seems to be kernel or glibc bug Nicolas Turro
@ 2003-05-14 13:35 82% ` Ion Badulescu
0 siblings, 0 replies; 200+ results
From: Ion Badulescu @ 2003-05-14 13:35 UTC (permalink / raw)
To: Nicolas Turro; +Cc: linux-kernel
On 14 May 2003, Nicolas Turro wrote:
> You were right, Ion,
> switching to a RH8 kernel ( 2.4.18-14 ) , solved the issue. I cannot
> reproduce this futex bug on the father process...
>
> Who should i contact in order to correct things ?
bugzilla.redhat.com is a good first start.
Hmm. I just realized that I was also running my script on a plain vanilla
2.4.20 kernel, NOT rh9's own kernel, so that's probably why I couldn't
reproduce the problem. I'll try again tonight, but as you said this points
strongly towards some new RH kernel feature which is less than stable or
which modifies certain semantics in ways that occasionally break amd.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
^ permalink raw reply [relevance 82%]
* Re: FW: am-utils or kernel bug ? Seems to be kernel or glibc bug...
[not found] <Pine.LNX.4.44.0305132214120.2091-100000@moisil.badula.org>
@ 2003-05-14 8:27 82% ` Nicolas Turro
2003-05-14 13:35 82% ` Ion Badulescu
0 siblings, 1 reply; 200+ results
From: Nicolas Turro @ 2003-05-14 8:27 UTC (permalink / raw)
To: Ion Badulescu; +Cc: linux-kernel
On Wed, 2003-05-14 at 04:23, Ion Badulescu wrote:
> > > i am running Redhat 9.0 ( kernel 2.4.20 )
> > > and am-utils (am-utils-6.0.9-2) (because i need the browsing
feature
> > > that automount doen't support).
> > >
> > > Unfortunatelly, amd sometimes hangs at boot time during its
> > > initialization (/etc/rc.d/init.d/amd ).
> > > I can reproduce this bug with /etc/rc.d/init.d/amd start / stop
> > > sequences, sometimes the start hangs sometimes it works.
> > > This bug occurs on ALL RedHat 9.0 boxes we have (7 PC with totally
> > > different hardware).
...
> > > [root@redhat-serv root]# strace -p 2454
> > > futex(0x4212e1c8, FUTEX_WAIT, -2, NULL <unfinished ...>
> > >
> > >
> > > [root@redhat-serv root]# strace -p 2455
> > > select(1024, [4 5 6 7], NULL, NULL, {932, 980000} <unfinished ...>
>
> I'll be damned if I understand what the futex is used for here. But since
> that's the parent amd, presumably it's waiting for the child to complete
> something, probably a mount.
>
> As for the second trace, we need to know what the four filedescriptors are
> for. 'lsof -p 2455' should shed some light...
>
> I suspect either a bug in glibc (likely), or a bug in the way amd uses
> some Unix primitives and which just happen to work on older glibc's (less
> likely). It's going to be rather hard to debug, however, if we can't
> reproduce it locally.
>
> Another suggestion I have is this: boot into an older kernel without futex
> support (2.4.18-27.7.x should do just fine, ignore the missing
> dependencies because they are not fatal). Glibc will adjust to the older
> kernel and use other mechanisms, and we'll see if the hang still occurs.
> Basically, since futexes were back-ported by Red Hat from 2.5 kernels, I
> suspect there might be some bugs or races in there, and this test would
> help to clear it out.
You were right, Ion,
switching to a RH8 kernel ( 2.4.18-14 ) , solved the issue. I cannot
reproduce this futex bug on the father process...
Who should i contact in order to correct things ?
--
Nicolas Turro <Nicolas.Turro@sophia.inria.fr>
INRIA
^ permalink raw reply [relevance 82%]
* Re: [BUG 2.5.X] pipe/fcntl/F_GETFL/F_SETFL obvious kernel bug
2003-04-24 21:23 82% ` Andrew Morton
@ 2003-04-24 21:35 82% ` Jean Tourrilhes
0 siblings, 0 replies; 200+ results
From: Jean Tourrilhes @ 2003-04-24 21:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, jgarzik, davem, kuznet
On Thu, Apr 24, 2003 at 02:23:06PM -0700, Andrew Morton wrote:
> Jean Tourrilhes <jt@bougret.hpl.hp.com> wrote:
> >
> > Hi,
> >
> > I reported this obvious kernel 2.5.X bug 6 months ago, and as
> > of 2.5.67 it is still not fixed. Do you know who I should send this
> > bug report to ?
>
> fcntl(fd, F_GETFL, intp) does not put the return value into *intp. The
> flags are in fcntl()'s return value. Same with 2.4.
*blush*. Thanks for the quick and precise answer, and sorry
about the noise.
Jean
^ permalink raw reply [relevance 82%]
* Re: [BUG 2.5.X] pipe/fcntl/F_GETFL/F_SETFL obvious kernel bug
2003-04-24 18:33 82% [BUG 2.5.X] pipe/fcntl/F_GETFL/F_SETFL obvious kernel bug Jean Tourrilhes
@ 2003-04-24 21:23 82% ` Andrew Morton
2003-04-24 21:35 82% ` Jean Tourrilhes
0 siblings, 1 reply; 200+ results
From: Andrew Morton @ 2003-04-24 21:23 UTC (permalink / raw)
To: jt; +Cc: jt, linux-kernel, jgarzik, davem, kuznet
Jean Tourrilhes <jt@bougret.hpl.hp.com> wrote:
>
> Hi,
>
> I reported this obvious kernel 2.5.X bug 6 months ago, and as
> of 2.5.67 it is still not fixed. Do you know who I should send this
> bug report to ?
fcntl(fd, F_GETFL, intp) does not put the return value into *intp. The
flags are in fcntl()'s return value. Same with 2.4.
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <stdio.h>
int main()
{
int trigger_pipe[2];
int err;
int flags;
int newflags;
pipe(trigger_pipe);
/* Get flags */
flags = fcntl(trigger_pipe[0], F_GETFL, NULL);
fprintf(stderr, "Set flags: 0x%x\n", flags);
/* Set flags */
flags |= O_NONBLOCK;
err = fcntl(trigger_pipe[0], F_SETFL, flags);
fprintf(stderr, "Set flags: %d\n", err);
/* Check flags */
flags = fcntl(trigger_pipe[0], F_GETFL, NULL);
fprintf(stderr, "Get flags: 0x%0x\n", flags);
}
^ permalink raw reply [relevance 82%]
* [BUG 2.5.X] pipe/fcntl/F_GETFL/F_SETFL obvious kernel bug
@ 2003-04-24 18:33 82% Jean Tourrilhes
2003-04-24 21:23 82% ` Andrew Morton
0 siblings, 1 reply; 200+ results
From: Jean Tourrilhes @ 2003-04-24 18:33 UTC (permalink / raw)
To: Linux kernel mailing list, Jeff Garzik, davem, kuznet
Hi,
I reported this obvious kernel 2.5.X bug 6 months ago, and as
of 2.5.67 it is still not fixed. Do you know who I should send this
bug report to ?
Thanks...
Jean
---------------------------------------------
Compile test program below.
On 2.5.67 :
GET FLAGS : 0 - 40044F18
SET FLAGS : -1 - 22
On 2.4.21-pre7 :
GET FLAGS : 0 - 40043F18
SET FLAGS : 0 - 0
---------------------------------------------
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <stdio.h>
int main()
{
int trigger_pipe[2];
int err;
int flags;
pipe(trigger_pipe);
err = fcntl(trigger_pipe[0], F_GETFL, &flags);
fprintf(stderr, "GET FLAGS : %d - %X\n", err, flags);
if(err >= 0)
{
flags |= O_NONBLOCK;
//flags |= O_NDELAY;
//flags &= ~O_NDELAY;
err = fcntl(trigger_pipe[0], F_SETFL, flags);
fprintf(stderr, "SET FLAGS : %d - %d\n", err, errno);
}
return(0);
}
^ permalink raw reply [relevance 82%]
* Re: Fwd: [Bug 592] New: BUG at kernel/softirq.c:105
@ 2003-04-16 11:23 82% ` Patrick McHardy
0 siblings, 0 replies; 200+ results
From: Patrick McHardy @ 2003-04-16 11:23 UTC (permalink / raw)
To: Russell King; +Cc: Linux Kernel List
Andrew Morton wrote something about this BUG, his mail
is here: http://marc.theaimsgroup.com/?l=linux-kernel&m=104979788626334&w=2
Bye,
Patrick
Russell King wrote:
>I've been trying to trace this callpath, and have hit a dead end in
>release_dev(). It seems to go weird after there, which makes it
>difficult to audit the code path.
>
>Anyone got any ideas?
>
>I'm not too bothered about this bug since I don't look after the ppp
>or tty (line discipline) code, so I'm also looking for someone else
>to assign this to.
>
>
^ permalink raw reply [relevance 82%]
* Re: [BUG] E7x05 chipset bug in 2.5 kernels' AGPGART driver.
@ 2003-04-04 7:58 82% ` Denis Vlasenko
0 siblings, 0 replies; 200+ results
From: Denis Vlasenko @ 2003-04-04 7:58 UTC (permalink / raw)
To: Dave Jones, Fendrakyn; +Cc: linux-kernel
On 3 April 2003 00:10, Dave Jones wrote:
> On Wed, Apr 02, 2003 at 08:50:03PM +0200, Fendrakyn wrote:
> > There is a mistake in the Makefile of drivers/char/agp, the line
> > concerning i7x05-agp support does not match the one in the
> > Kconfig, thus e7x05 support is never compiled, be it as a module
> > or in the kernel.
>
> I'm really amazed. This has been broken for months, and no-one
> noticed. The day I fixed it in the agpgart bk tree, I got a half
> dozen reports, and now I'm getting one daily. Truly bizarre.
Jargon file have an entry about class of bugs which
are latent (do not bite anybody) until discovered.
When discovered, relevant pieces of code promptly stop working.
I thought that was a joke ;)
--
vda
^ permalink raw reply [relevance 82%]
* [BUG] E7x05 chipset bug in 2.5 kernels' AGPGART driver.
@ 2003-04-02 18:50 82% Fendrakyn
0 siblings, 1 reply; 200+ results
From: Fendrakyn @ 2003-04-02 18:50 UTC (permalink / raw)
To: linux-kernel
Hello,
I noticed there is a bug in E7x05 (Granite Bay) chipset support of the AGPGART
driver that does not seem to have been submitted yet.
There is a mistake in the Makefile of drivers/char/agp, the line concerning
i7x05-agp support does not match the one in the Kconfig, thus e7x05 support
is never compiled, be it as a module or in the kernel.
There are mistakes in the i7x05-agp source code. A few missings ";" and some
undeclared functions prevent the module from properly compiling. Those
mistakes are easily fixed though.
The last problem is more important and I have yet to find a solution. It seems
like the driver stores device 0 in his agp_bridge->dev (0x255d for E7205,
0x2550 for E7505) but it uses registers from device 1 (0x2552) thus the
chipset cannot be configured properly. The fetch_size function fails to
determine aperture size.
Sorry if this is redundant and is already being looked at.
Gareth C.
P.S : include answers in C.C if you may, pretty please.
^ permalink raw reply [relevance 82%]
* [parisc-linux] glibc/gcc bug -> perl/gcc bug?
@ 2003-03-31 2:32 82% ` Carlos O'Donell
0 siblings, 0 replies; 200+ results
From: Carlos O'Donell @ 2003-03-31 2:32 UTC (permalink / raw)
To: Randolph Chung; +Cc: parisc-linux
> perl-5.8 fails to build on hppa because of a test failure. The problem
> can be seen very easily:
>
> tausq@gsyprf11:~/build/perl-5.8.0$ cat t/t.pl
> print log "A";
> tausq@gsyprf11:~/build/perl-5.8.0$ ./perl t/t.pl
> Can't take log of 2.75773e-308 at t/t.pl line 1.
>
> that should have said:
> tausq@gsyprf11:~/build/perl-5.8.0$ /usr/bin/perl t/t.pl
> Can't take log of 0 at t/t.pl line 1.
>
> interestingly, a debug build of perl (using -g and no -O flags) doesn't
> have the same problem, so this looks like some kind of compiler
> optimization bug. I've tried this with both 3.2.3 and 3.3... same
> problems.
>
> would anyone like to try to look at this some more and see if they can
> isolate the C code/a small test case that is causing the problem?
Glibc's math tests are still failing even under gcc-3.3 (not to mention
the threading problems I'm in the middle of fixing).
Though I'm seeing more:
Failure: Real part of: cacos (NaN + inf i) == NaN - inf i: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN - inf i) == NaN + inf i: Exception "Invalid operation" set
Failure: Real part of: cacos (NaN + NaN i) == NaN + NaN i: Exception "Invalid operation" set
Or:
Failure: Test: Imaginary part of: ctanh (NaN - 0 i) == NaN - 0 i
Result:
is: nan nan
should be: -0.00000000000000000000e+00 -0x0.00000000000000000000p+0
Even with a new ulps, the tests were still failing.
c.
^ permalink raw reply [relevance 82%]
* Re: [BUG] 2.5.65-mm3 kernel BUG at fs/ext3/super.c:1795!
2003-03-21 20:39 82% ` Andrew Morton
@ 2003-03-22 2:55 82% ` Alexander Hoogerhuis
-1 siblings, 0 replies; 200+ results
From: Alexander Hoogerhuis @ 2003-03-22 2:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
Andrew Morton <akpm@digeo.com> writes:
> Alexander Hoogerhuis <alexh@ihatent.com> wrote:
> >
> > Andrew Morton <akpm@digeo.com> writes:
> > >
> > > [SNIP]
> > >
> >
> > Disk I/O on my machine froze up during very light work after a few
> > hours, luckily I had a window open on another machine so I could do a
> > simple capture and save the info:
> >
> > kernel BUG at fs/ext3/super.c:1795!
> > invalid operand: 0000 [#1]
> > CPU: 0
> > EIP: 0060:[<c018b522>] Not tainted VLI
> > EFLAGS: 00010246
> > EIP is at ext3_write_super+0x36/0x94
> > eax: 00000000 ebx: c8834000 ecx: efb5904c edx: efb59000
> > esi: efb59000 edi: c8834000 ebp: c8835ecc esp: c8835ec0
> > ds: 007b es: 007b ss: 0068
> > Process pdflush (pid: 7853, threadinfo=c8834000 task=ed0a5880)
> > Stack: c8835ee4 00000287 efb5904c c8835ee4 c0153148 efb59000 00000077 51eb851f
> > c8835fcc c8835fa4 c0137fd0 c03892fc 007b9f47 007b168f 00000000 00000000
> > c8835ef4 00000000 00000001 00000000 00000001 00000000 00000053 00000000
> > Call Trace:
> > [<c0153148>] sync_supers+0xde/0xea
> > [<c0137fd0>] wb_kupdate+0x68/0x161
> > [<c0118985>] schedule+0x1a4/0x3ac
> > [<c01386e8>] __pdflush+0xdc/0x1d8
> > [<c01387e4>] pdflush+0x0/0x15
> > [<c01387f5>] pdflush+0x11/0x15
> > [<c0137f68>] wb_kupdate+0x0/0x161
> > [<c0108e69>] kernel_thread_helper+0x5/0xb
>
> How on earth did you do that?
>
> sync_supers() does lock_super, then calls ext3_write_super.
>
> ext3_write_super() does a down_trylock() on sb->s_lock and goes BUG
> if it acquired the lock.
>
> So you've effectively done this:
>
> down(&sem);
> if (down_trylock(&sem))
> BUG();
>
> This can only be a random memory scribble, a hardware bug or a
> preempt-related bug in down_trylock().
Heh. My "portable murphy field" if powerful. Honestly, all I did was
to have a few gnome-terminals, an emacs or two, a few mozillas and a
bit more up, same as always, and jut "just happened" (that's what all
kids claim when they break stuff) :)
mvh,
A
--
Alexander Hoogerhuis | alexh@ihatent.com
CCNP - CCDP - MCNE - CCSE | +47 908 21 485
"You have zero privacy anyway. Get over it." --Scott McNealy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply [relevance 82%]
* Re: [BUG] 2.5.65-mm3 kernel BUG at fs/ext3/super.c:1795!
@ 2003-03-22 2:55 82% ` Alexander Hoogerhuis
0 siblings, 0 replies; 200+ results
From: Alexander Hoogerhuis @ 2003-03-22 2:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
Andrew Morton <akpm@digeo.com> writes:
> Alexander Hoogerhuis <alexh@ihatent.com> wrote:
> >
> > Andrew Morton <akpm@digeo.com> writes:
> > >
> > > [SNIP]
> > >
> >
> > Disk I/O on my machine froze up during very light work after a few
> > hours, luckily I had a window open on another machine so I could do a
> > simple capture and save the info:
> >
> > kernel BUG at fs/ext3/super.c:1795!
> > invalid operand: 0000 [#1]
> > CPU: 0
> > EIP: 0060:[<c018b522>] Not tainted VLI
> > EFLAGS: 00010246
> > EIP is at ext3_write_super+0x36/0x94
> > eax: 00000000 ebx: c8834000 ecx: efb5904c edx: efb59000
> > esi: efb59000 edi: c8834000 ebp: c8835ecc esp: c8835ec0
> > ds: 007b es: 007b ss: 0068
> > Process pdflush (pid: 7853, threadinfo=c8834000 task=ed0a5880)
> > Stack: c8835ee4 00000287 efb5904c c8835ee4 c0153148 efb59000 00000077 51eb851f
> > c8835fcc c8835fa4 c0137fd0 c03892fc 007b9f47 007b168f 00000000 00000000
> > c8835ef4 00000000 00000001 00000000 00000001 00000000 00000053 00000000
> > Call Trace:
> > [<c0153148>] sync_supers+0xde/0xea
> > [<c0137fd0>] wb_kupdate+0x68/0x161
> > [<c0118985>] schedule+0x1a4/0x3ac
> > [<c01386e8>] __pdflush+0xdc/0x1d8
> > [<c01387e4>] pdflush+0x0/0x15
> > [<c01387f5>] pdflush+0x11/0x15
> > [<c0137f68>] wb_kupdate+0x0/0x161
> > [<c0108e69>] kernel_thread_helper+0x5/0xb
>
> How on earth did you do that?
>
> sync_supers() does lock_super, then calls ext3_write_super.
>
> ext3_write_super() does a down_trylock() on sb->s_lock and goes BUG
> if it acquired the lock.
>
> So you've effectively done this:
>
> down(&sem);
> if (down_trylock(&sem))
> BUG();
>
> This can only be a random memory scribble, a hardware bug or a
> preempt-related bug in down_trylock().
Heh. My "portable murphy field" if powerful. Honestly, all I did was
to have a few gnome-terminals, an emacs or two, a few mozillas and a
bit more up, same as always, and jut "just happened" (that's what all
kids claim when they break stuff) :)
mvh,
A
--
Alexander Hoogerhuis | alexh@ihatent.com
CCNP - CCDP - MCNE - CCSE | +47 908 21 485
"You have zero privacy anyway. Get over it." --Scott McNealy
^ permalink raw reply [relevance 82%]
* Re: [BUG] 2.5.65-mm3 kernel BUG at fs/ext3/super.c:1795!
@ 2003-03-21 20:39 82% ` Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2003-03-21 20:39 UTC (permalink / raw)
To: Alexander Hoogerhuis; +Cc: linux-kernel, linux-mm
Alexander Hoogerhuis <alexh@ihatent.com> wrote:
>
> Andrew Morton <akpm@digeo.com> writes:
> >
> > [SNIP]
> >
>
> Disk I/O on my machine froze up during very light work after a few
> hours, luckily I had a window open on another machine so I could do a
> simple capture and save the info:
>
> kernel BUG at fs/ext3/super.c:1795!
> invalid operand: 0000 [#1]
> CPU: 0
> EIP: 0060:[<c018b522>] Not tainted VLI
> EFLAGS: 00010246
> EIP is at ext3_write_super+0x36/0x94
> eax: 00000000 ebx: c8834000 ecx: efb5904c edx: efb59000
> esi: efb59000 edi: c8834000 ebp: c8835ecc esp: c8835ec0
> ds: 007b es: 007b ss: 0068
> Process pdflush (pid: 7853, threadinfo=c8834000 task=ed0a5880)
> Stack: c8835ee4 00000287 efb5904c c8835ee4 c0153148 efb59000 00000077 51eb851f
> c8835fcc c8835fa4 c0137fd0 c03892fc 007b9f47 007b168f 00000000 00000000
> c8835ef4 00000000 00000001 00000000 00000001 00000000 00000053 00000000
> Call Trace:
> [<c0153148>] sync_supers+0xde/0xea
> [<c0137fd0>] wb_kupdate+0x68/0x161
> [<c0118985>] schedule+0x1a4/0x3ac
> [<c01386e8>] __pdflush+0xdc/0x1d8
> [<c01387e4>] pdflush+0x0/0x15
> [<c01387f5>] pdflush+0x11/0x15
> [<c0137f68>] wb_kupdate+0x0/0x161
> [<c0108e69>] kernel_thread_helper+0x5/0xb
How on earth did you do that?
sync_supers() does lock_super, then calls ext3_write_super.
ext3_write_super() does a down_trylock() on sb->s_lock and goes BUG
if it acquired the lock.
So you've effectively done this:
down(&sem);
if (down_trylock(&sem))
BUG();
This can only be a random memory scribble, a hardware bug or a
preempt-related bug in down_trylock().
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply [relevance 82%]
* Re: [BUG] 2.5.65-mm3 kernel BUG at fs/ext3/super.c:1795!
@ 2003-03-21 20:39 82% ` Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2003-03-21 20:39 UTC (permalink / raw)
To: Alexander Hoogerhuis; +Cc: linux-kernel, linux-mm
Alexander Hoogerhuis <alexh@ihatent.com> wrote:
>
> Andrew Morton <akpm@digeo.com> writes:
> >
> > [SNIP]
> >
>
> Disk I/O on my machine froze up during very light work after a few
> hours, luckily I had a window open on another machine so I could do a
> simple capture and save the info:
>
> kernel BUG at fs/ext3/super.c:1795!
> invalid operand: 0000 [#1]
> CPU: 0
> EIP: 0060:[<c018b522>] Not tainted VLI
> EFLAGS: 00010246
> EIP is at ext3_write_super+0x36/0x94
> eax: 00000000 ebx: c8834000 ecx: efb5904c edx: efb59000
> esi: efb59000 edi: c8834000 ebp: c8835ecc esp: c8835ec0
> ds: 007b es: 007b ss: 0068
> Process pdflush (pid: 7853, threadinfo=c8834000 task=ed0a5880)
> Stack: c8835ee4 00000287 efb5904c c8835ee4 c0153148 efb59000 00000077 51eb851f
> c8835fcc c8835fa4 c0137fd0 c03892fc 007b9f47 007b168f 00000000 00000000
> c8835ef4 00000000 00000001 00000000 00000001 00000000 00000053 00000000
> Call Trace:
> [<c0153148>] sync_supers+0xde/0xea
> [<c0137fd0>] wb_kupdate+0x68/0x161
> [<c0118985>] schedule+0x1a4/0x3ac
> [<c01386e8>] __pdflush+0xdc/0x1d8
> [<c01387e4>] pdflush+0x0/0x15
> [<c01387f5>] pdflush+0x11/0x15
> [<c0137f68>] wb_kupdate+0x0/0x161
> [<c0108e69>] kernel_thread_helper+0x5/0xb
How on earth did you do that?
sync_supers() does lock_super, then calls ext3_write_super.
ext3_write_super() does a down_trylock() on sb->s_lock and goes BUG
if it acquired the lock.
So you've effectively done this:
down(&sem);
if (down_trylock(&sem))
BUG();
This can only be a random memory scribble, a hardware bug or a
preempt-related bug in down_trylock().
^ permalink raw reply [relevance 82%]
* [Bug] module unloading or unmap_vma bug ?
@ 2003-03-12 2:08 82% Xiong Jiang
0 siblings, 0 replies; 200+ results
From: Xiong Jiang @ 2003-03-12 2:08 UTC (permalink / raw)
To: linux-kernel
Hi, folks,
Maybe this was reported or maybe not...
Plain 2.5.64 kernel, with isofs as modules, using the new module-init-tool.
Try modprobe isofs and unload it, then try it again, then I got following
segfault. Then modules system got something wrong and have to reboot.
And shutdown procedure is halted when iptable service is to be stopped.
Here is now to reproduce it:
/sbin/modprobe isofs
/sbin/rmmod isofs
/sbin/rmmod zlib_inflate
/sbin/modprobe isofs
/sbin/rmmod isofs
Process rmmod (pid: 693, threadinfo=cd096000 task=cd2d07c0)
Stack: 40017000 cd097f38 c0141bf4 c03035a4 d0864d74 d0864d60 00000000 cd097f2c
c01aba94 d0864d74 d0864d74 cd097f3c c01abab4 d0864d74 00000000 cd097f50
c016a562 d0864d74 c0288518 d0864f40 cd097f5c d0861ac2 d0864d60 cd097fbc
Call Trace:
[<c0141bf4>] unmap_vmas+0xc4/0x220
[<d0864d74>] iso9660_fs_type+0x14/0x80 [isofs]
[<d0864d60>] iso9660_fs_type+0x0/0x80 [isofs]
[<c01aba94>] kobject_del+0x14/0x20
[<d0864d74>] iso9660_fs_type+0x14/0x80 [isofs]
[<d0864d74>] iso9660_fs_type+0x14/0x80 [isofs]
[<c01abab4>] kobject_unregister+0x14/0x20
[<d0864d74>] iso9660_fs_type+0x14/0x80 [isofs]
[<c016a562>] unregister_filesystem+0x32/0x40
[<d0864d74>] iso9660_fs_type+0x14/0x80 [isofs]
[<d0864f40>] +0x0/0x140 [isofs]
[<d0861ac2>] +0x12/0x20 [isofs]
[<d0864d60>] iso9660_fs_type+0x0/0x80 [isofs]
[<c01330d3>] sys_delete_module+0x1b3/0x1f0
[<c0145667>] sys_munmap+0x57/0x80
[<c010b282>] sysenter_entry+0x52/0x70
Code: 0f 0b 0a 01 56 1e 26 c0 ff 07 83 4f 04 08 85 ff 0f 84 37 01
^ permalink raw reply [relevance 82%]
* Fwd: tcp seq nr wrapping bug + patch
@ 2003-03-10 15:16 82% Ulrik De Bie
0 siblings, 0 replies; 200+ results
From: Ulrik De Bie @ 2003-03-10 15:16 UTC (permalink / raw)
To: jmorris, a, netdev
[-- Attachment #1: Type: text/plain, Size: 137 bytes --]
Hello,
I resend this patch which fixes a stupid mistake in the tcp sequence number in the 2.2 kernel.
Kind regards,
Ulrik De Bie
[-- Attachment #2: Type: message/rfc822, Size: 1205 bytes --]
From: "Ulrik De Bie" <ulrik.debie@newtec.be>
To: <alan.cox@linux.org>,<a@oo.ms>
Subject: tcp seq nr wrapping bug + patch
Date: Wed, 11 Sep 2002 17:36:27 +0200
When the sequence number in a tcp session is about to wrap for packets
leaving the system, a problem arises:
When the system call writev is called, with a count of 5 for instance, and the
second iov entry makes the sequence number wrap, then the other 3 will be
sent in separate packets, because the comparison will be wrong.
before() fixes this problem.
Sorry that I'm sending from a windows machine at the moment, I don't have
a linux mail machine available at the very moment.
Kind regards,
Ulrik De Bie
udb@newtec.be
--- linux-2.2.21/net/ipv4/tcp.c Wed Sep 11 11:03:10 2002
+++ linux/net/ipv4/tcp.c Wed Sep 11 17:27:53 2002
@@ -823,7 +823,7 @@
*/
if (skb_tailroom(skb) > 0 &&
(mss_now - copy) > 0 &&
- tp->snd_nxt < TCP_SKB_CB(skb)->end_seq) {
+ before(tp->snd_nxt , TCP_SKB_CB(skb)->end_seq)) {
int last_byte_was_odd = (copy % 4);
/*
^ permalink raw reply [relevance 82%]
* Re: [Bug 449] New: Kernel BUG when tun device is closed
@ 2003-03-07 16:35 82% ` Kevin P. Fleming
0 siblings, 0 replies; 200+ results
From: Kevin P. Fleming @ 2003-03-07 16:35 UTC (permalink / raw)
To: LKML
Martin J. Bligh wrote:
> http://bugme.osdl.org/show_bug.cgi?id=449
>
> Summary: Kernel BUG when tun device is closed (oops attached)
> Kernel Version: 2.5.64
> Status: NEW
> Severity: normal
> Owner: mochel@osdl.org
> Submitter: kpfleming@cox.net
>
>
> Distribution: heavily modified RedHat 7.3
> Hardware Environment: MSI K7T266-Pro2 motherboard, Athlon Thunderbird 1GHz CPU,
> (2) WD1600JB disks, etc.
> Software Environment: vtund-2.5
> Problem Description: vtund works fine normally (is in client mode on this
> system). when the server end of the link was shutdown, the client tried to close
> its open "tun" device. this action caused the oops below.
>
I have already updated this bug to show that Patrick's patch posted
yesterday appears to solve the problem.
^ permalink raw reply [relevance 82%]
* Re: Bug report bounced + bug report
2003-02-28 15:28 82% Bug report bounced + bug report Han Holl
@ 2003-02-28 16:58 82% ` Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 2003-02-28 16:58 UTC (permalink / raw)
To: Han Holl; +Cc: Linux Kernel Mailing List
On Fri, 2003-02-28 at 15:28, Han Holl wrote:
> Well, subject says it all really. Here is a (minimal) patch:
>
> --- main.c.orig Fri Feb 28 15:56:54 2003
> +++ main.c Fri Feb 28 15:40:37 2003
> @@ -495,6 +495,8 @@
> { "sdn", 0x08d0 },
> { "sdo", 0x08e0 },
> { "sdp", 0x08f0 },
> + { "cciss/c0d0p",0x6800 },
> + { "cciss/c0d1p",0x6810 },
> { "rd/c0d0p",0x3000 },
> { "rd/c0d1p",0x3008 },
> { "rd/c0d2p",0x3010 },
>
Nothing wrong with it, but the kernel nowdays really expects the translation
to be done by the bootloader. Lilo gets this right, Grub it seems does not
know about it.
^ permalink raw reply [relevance 82%]
* Bug report bounced + bug report
@ 2003-02-28 15:28 82% Han Holl
2003-02-28 16:58 82% ` Alan Cox
0 siblings, 1 reply; 200+ results
From: Han Holl @ 2003-02-28 15:28 UTC (permalink / raw)
To: linux-kernel
Hi,
I tried to report a bug in kernel 2.2.23 to Alan.Cox@linux.org, as instructed
by the 2.2.23 documents, but got a bounce message:
The Postfix program
<Alan.Cox@linux.org>: Name service error for domain linux.org: Host found but
no data record of requested type
Here is the bug report:
Subject: Cannot boot Compaq Smart Array 532 with grub on 2.2.23
Hi,
Well, subject says it all really. Here is a (minimal) patch:
--- main.c.orig Fri Feb 28 15:56:54 2003
+++ main.c Fri Feb 28 15:40:37 2003
@@ -495,6 +495,8 @@
{ "sdn", 0x08d0 },
{ "sdo", 0x08e0 },
{ "sdp", 0x08f0 },
+ { "cciss/c0d0p",0x6800 },
+ { "cciss/c0d1p",0x6810 },
{ "rd/c0d0p",0x3000 },
{ "rd/c0d1p",0x3008 },
{ "rd/c0d2p",0x3010 },
Cheers,
Han Holl
^ permalink raw reply [relevance 82%]
* Re: [Bug 365] New: Raid-0 causes kernel BUG at drivers/block/ll_rw_blk.c:1996
@ 2003-02-16 9:54 82% ` Jens Axboe
0 siblings, 0 replies; 200+ results
From: Jens Axboe @ 2003-02-16 9:54 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: linux-kernel
On Sat, Feb 15 2003, Martin J. Bligh wrote:
>
> http://bugme.osdl.org/show_bug.cgi?id=365
>
> Summary: Raid-0 causes kernel BUG at
> drivers/block/ll_rw_blk.c:1996
> Kernel Version: 2.5.61
> Status: NEW
> Severity: blocking
> Owner: bugme-janitors@lists.osdl.org
> Submitter: harisri@bigpond.com
>
>
> Distribution: RH 8.0
> Hardware Environment: Athlon, AMD 761 (AMD North Bridge, VIA South bridge),
> IDE Hard drives
> Software Environment: Gnu C 3.2, Linux C Library 2.2.93,
> raidtools-1.00.2-3.3 Problem Description: 2.5.61 oops while trying to
> activate raid-0 volumes. Please refer the thread
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103830814911111&w=2 for more
> information from Neil Brown, Jens Axboe and Andrew Morton.
>
> Steps to reproduce: Try to enable raid-0 volumes under 2.5.49 to 2.5.61
Known bug, raid0 doesn't accept a full PAGE_CACHE_SIZE page at any
offset, and the api relies on that. Fix is probably to add the sub-page
split stuff.
--
Jens Axboe
^ permalink raw reply [relevance 82%]
* Re: [Kernel Bug Database] Bug report 34 - Matrox framebuffer drivers don't compile
2003-02-08 20:45 82% [Kernel Bug Database] Bug report 34 - Matrox framebuffer drivers don't compile John Bradford
@ 2003-02-12 20:52 82% ` James Simmons
0 siblings, 0 replies; 200+ results
From: James Simmons @ 2003-02-12 20:52 UTC (permalink / raw)
To: John Bradford; +Cc: linux-kernel
> Automatically added comment on 8th Feb 2003 at 11:19:50
> New bug added.
> The following kernel versions were initially submitted as broken: 2.5.59
I know. I'm back to working on it.
^ permalink raw reply [relevance 82%]
* [Kernel Bug Database] Bug report 34 - Matrox framebuffer drivers don't compile
@ 2003-02-08 20:45 82% John Bradford
2003-02-12 20:52 82% ` James Simmons
0 siblings, 1 reply; 200+ results
From: John Bradford @ 2003-02-08 20:45 UTC (permalink / raw)
To: linux-kernel
Automatically added comment on 8th Feb 2003 at 11:19:50
New bug added.
The following kernel versions were initially submitted as broken: 2.5.59
Comment by guest on 8th Feb 2003 at 11:19:50
Debian system, gcc version 3.2.2 20030131 (Debian prerelease).
make menuconfig
mane bzImage
-> in drivers/video/matrox
when compiling matroxfb_base.c
gcc cannot find
video/fbcon.h (included in through matroxfb_base.h)
video/fbcon-cfb4.h (included in through matroxfb_base.h)
video/fbcon-cfb8.h (included in through matroxfb_base.h)
video/fbcon-cfb16.h (included in through matroxfb_base.h)
video/fbcon-cfb32.h (included in through matroxfb_base.h)
Comment by john on 8th Feb 2003 at 11:51:25
See confirmed bug 8
^ permalink raw reply [relevance 82%]
* [Bug + Patch] opl3sa2 unregister bug
@ 2003-01-19 14:04 82% Daniel Ritz
0 siblings, 0 replies; 200+ results
From: Daniel Ritz @ 2003-01-19 14:04 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: linux-kernel
hi jaroslav
i played a bit with snd-opl3sa2...
modprobe snd-opl3sa2 #1 fails, no sound card found, module _not_ loaded
modprobe snd-opl3sa2 #2 produces that one:
pnp: the card driver 'opl3sa2' has been registered
Yamaha OPL3-SA soundcard not found or device busy
pnp: the card driver 'opl3sa2' has been registered
Badness in kobject_register at lib/kobject.c:152
Call Trace:
[<c0199146>] kobject_register+0x3e/0x50
[<c01aa72f>] bus_add_driver+0x53/0xd8
[<d08c793c>] opl3sa2_pnpc_driver+0x3c/0xfffefff4 [snd_opl3sa2]
[<d08c7900>] opl3sa2_pnpc_driver+0x0/0xfffefff4 [snd_opl3sa2]
[<d08c793c>] opl3sa2_pnpc_driver+0x3c/0xfffefff4 [snd_opl3sa2]
[<c01aaafa>] driver_register+0x36/0x3c
[<d08c791c>] opl3sa2_pnpc_driver+0x1c/0xfffefff4 [snd_opl3sa2]
[<c01a0c86>] pnpc_register_driver+0x36/0x54
[<d08c791c>] opl3sa2_pnpc_driver+0x1c/0xfffefff4 [snd_opl3sa2]
[<d08c5b65>] +0x2a5/0xffff2034 [snd_opl3sa2]
[<d08b78c8>] alsa_card_opl3sa2_init+0x44/0x6c [snd_opl3sa2]
[<d08c7900>] opl3sa2_pnpc_driver+0x0/0xfffefff4 [snd_opl3sa2]
[<d08c79a0>] +0x0/0xfffeff54 [snd_opl3sa2]
[<c012b836>] sys_init_module+0x13a/0x1cc
[<c010a917>] syscall_call+0x7/0xb
to fix it:
--- linux-2.5/sound/isa/opl3sa2.c~ 2003-01-19 14:42:20.000000000 +0100
+++ linux-2.5/sound/isa/opl3sa2.c 2003-01-19 14:43:54.000000000 +0100
@@ -896,6 +896,9 @@
#ifdef MODULE
printk(KERN_ERR "Yamaha OPL3-SA soundcard not found or device busy\n");
#endif
+#ifdef CONFIG_PNP
+ pnpc_unregister_driver(&opl3sa2_pnpc_driver);
+#endif
return -ENODEV;
}
return 0;
@@ -905,7 +908,9 @@
{
int dev;
+#ifdef CONFIG_PNP
pnpc_unregister_driver(&opl3sa2_pnpc_driver);
+#endif
for (dev = 0; dev < SNDRV_CARDS; dev++)
snd_card_free(snd_opl3sa2_cards[dev]);
}
against 2.5.59 + your driver patch from
http://marc.theaimsgroup.com/?l=linux-kernel&m=104292513020851
rgds,
-daniel
^ permalink raw reply [relevance 82%]
* Re: [BUG] QM_MODULES: Function not implemented... [ No bug! ]
@ 2003-01-16 7:31 82% ` Damian Kolkowski
0 siblings, 0 replies; 200+ results
From: Damian Kolkowski @ 2003-01-16 7:31 UTC (permalink / raw)
To: Linux Kernel
* Damian Kolkowski (deimos@deimos.one.pl) wrote:
> P.S. The modules are instaled but they could not be loaded.
Because I don't have _module-init-tools_. My stupid bug :-)
--
# Damian *dEiMoS* Kolkowski # http://deimos.one.pl/ #
^ permalink raw reply [relevance 82%]
* [BUG] floopy driver bug in 2.4.20
@ 2003-01-07 21:10 82% Pozsar Balazs
0 siblings, 0 replies; 200+ results
From: Pozsar Balazs @ 2003-01-07 21:10 UTC (permalink / raw)
To: linux-kernel
Hi all,
I found wierd bug in the floppy driver. When I have _no_ floppy inserted
in the drive, I get the expected ENXIO every _other_ (second) time, but I
get success (!) the other times:
root@brefatox:~# dd if=/dev/zero of=/dev/fd0u1440 bs=1440k count=1; echo
$?
dd: opening `/dev/fd0u1440': No such device or address
1
root@brefatox:~# dd if=/dev/zero of=/dev/fd0u1440 bs=1440k count=1; echo
$?
1+0 records in
1+0 records out
0
root@brefatox:~# dd if=/dev/zero of=/dev/fd0u1440 bs=1440k count=1; echo
$?
dd: opening `/dev/fd0u1440': No such device or address
1
root@brefatox:~# dd if=/dev/zero of=/dev/fd0u1440 bs=1440k count=1; echo
$?
1+0 records in
1+0 records out
0
root@brefatox:~# dd if=/dev/zero of=/dev/fd0u1440 bs=1440k count=1; echo
$?
dd: opening `/dev/fd0u1440': No such device or address
1
root@brefatox:~# dd if=/dev/zero of=/dev/fd0u1440 bs=1440k count=1; echo
$?
1+0 records in
1+0 records out
0
root@brefatox:~#
...and so on...
Why is this?
root@brefatox:~# dd --version
dd (coreutils) 4.5.4
...
--
pozsy
^ permalink raw reply [relevance 82%]
* Re: Dedicated kernel bug database
@ 2002-12-22 2:50 82% Hell.Surfers
0 siblings, 0 replies; 200+ results
From: Hell.Surfers @ 2002-12-22 2:50 UTC (permalink / raw)
To: john, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 124 bytes --]
What are your ideas???
Regards, Dean.
On Fri, 20 Dec 2002 09:48:53 +0000 (GMT) John Bradford <john@grabjohn.com> wrote:
[-- Attachment #2: Type: message/rfc822, Size: 3081 bytes --]
From: John Bradford <john@grabjohn.com>
To: mbligh@aracnet.com (Martin J. Bligh)
Cc: linux-kernel@vger.kernel.org
Subject: Re: Dedicated kernel bug database
Date: Fri, 20 Dec 2002 09:48:53 +0000 (GMT)
Message-ID: <200212200948.gBK9mrXh000326@darkstar.example.net>
[CC list trimmed]
> > I've got loads of ideas about how we could build a better bug database
>
> Go ahead, knock yourself out. Come back when you're done.
Not sure what you mean. I do intend to start coding a new bug
database system today, and I'll announce it on the list when it's
ready. If nobody likes it, I wasted my time.
> > - for example, we have categories at the moment in Bugzilla. Why? We
> > already have a MAINTAINERS file, so say somebody looks up the relevant
> > maintainer in that list, finds them, then goes to enter a bug in
> > Bugzilla. Now they have to assign it to a category, and different
> > people may well assign the same bug to different categories -
> > immediately making duplicate detection more difficult.
>
> Have you actually looked at the maintainers file?
Yes.
> It's a twisted mess of outdated information,
Then it should be updated, that is nothing to do with Bugzilla.
> in no well formated order.
Looks easy enough to parse with regular expressions to me.
> The category list in Bugzilla was an attempt to bring some sanity to
> the structure,
By adding an extra layer of abstraction. I don't agree that that
helps.
> though I won't claim it's perfect. We really need a 3-level tree,
> but that's a fair amount of work to code.
I disagree, (that we need a 3-level tree).
John.
-
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 [relevance 82%]
* Bug by starting with missed first devies - bug fix included !!
@ 2002-12-18 20:06 82% Christoph Plattner
0 siblings, 0 replies; 200+ results
From: Christoph Plattner @ 2002-12-18 20:06 UTC (permalink / raw)
To: linux-raid
Hello RADI hackers,
some days ago I recongnized, that `raidstart' has a problem, if
`raid-disk 0' is missed or defect. This was a critical problem
on my RAID 5 for me.
Solution for this problem: try to use all devices to get RAID info,
not only the first defined device (bad design bug).
I am not sure, if this is already reported or fixed, I have release
20010914, and the raidstart `v0.3d'.
Please answer directly to me, I am not registered on the RAID
mailing list !! (Perhaps I will do in future).
One possible fix:
bash# diff -u raidlib.c.ORIG raidlib.c
--- raidlib.c.ORIG Wed Dec 18 20:59:11 2002
+++ raidlib.c Sun Dec 15 13:42:06 2002
@@ -395,11 +395,29 @@
case raidstart:
{
struct stat s;
+ int did = 0;
+ int done = 0;
+
+ fd = open_or_die(cfg->md_name);
- stat (cfg->device_name[0], &s);
+ while (cfg->device_name [did])
+ {
+ stat (cfg->device_name [did], &s);
- fd = open_or_die(cfg->md_name);
- if (do_mdstart (fd, cfg->md_name, s.st_rdev)) rc++;
+ if (do_mdstart (fd, cfg->md_name, s.st_rdev) == 0)
+ {
+ done = 1;
+ break;
+ }
+ did ++;
+ }
+
+ if (done == 0)
+ {
+ rc++;
+ close (fd);
+ }
+
break;
}
With friendly regards
Christoph Plattner
--
-------------------------------------------------------
private: christoph.plattner@gmx.at
company: christoph.plattner@alcatel.at
^ permalink raw reply [relevance 82%]
* Re: Wildcards matching ".": exports bug or just documentation bug?
2002-10-04 11:57 82% Wildcards matching ".": exports bug or just documentation bug? Stephen C. Tweedie
@ 2002-11-13 13:55 82% ` Stephen C. Tweedie
0 siblings, 0 replies; 200+ results
From: Stephen C. Tweedie @ 2002-11-13 13:55 UTC (permalink / raw)
To: nfs, neilb, trond.myklebust; +Cc: Stephen Tweedie, linux-fsdevel
Hi,
On Fri, Oct 04, 2002 at 12:57:04PM +0100, Stephen C. Tweedie wrote:
> mountd treats wildcards in hostnames in the exports file as matching
> anything, including ".".
> However, the exports man page explicitly states that "*" and "?" do not
> match ".":
> So, which is right, the actual behaviour or the documented behaviour?
> I'd tend to lean towards the former.
Ping? This is a pretty serious discrepancy between the documented and
implemented behaviour. The documentation *explicitly* states that
*.com
won't match foo.bar.com, but the implentation matches this just fine.
Given that the documented behaviour doesn't actually give you a way to
match an export for all arbitrarily-deep subdomains underneath a
domain, I'd think matching subdomains of all levels with "*" makes
more sense than matching only a single level, so it's the
documentation that needs to be updated.
--Stephen
^ permalink raw reply [relevance 82%]
* Re: linux/bug.h and asm/bug.h
2002-11-04 12:51 82% ` Russell King
@ 2002-11-04 13:39 82% ` William Lee Irwin III
0 siblings, 0 replies; 200+ results
From: William Lee Irwin III @ 2002-11-04 13:39 UTC (permalink / raw)
To: Ralf Baechle, Rusty Russell, torvalds, trivial, linux-kernel
On Mon, Nov 04, 2002 at 12:51:15PM +0000, Russell King wrote:
> I'm a little peeved since everyone's likes this from Rusty, but ignored
> exactly the same thing from me. Sigh, life is cruel some times.
> Message-Id: E18289f-0007tm-00@flint.arm.linux.org.uk
> Subject: [PATCH] 2.5.43-bug
> Date: Thu, 17 Oct 2002 11:45:27 +0100
Sorry about that, I didn't notice it then. I was distracted by other
things around 2.5.43 ...
Bill
^ permalink raw reply [relevance 82%]
* Re: linux/bug.h and asm/bug.h
2002-11-04 12:41 82% ` Ralf Baechle
@ 2002-11-04 12:51 82% ` Russell King
2002-11-04 13:39 82% ` William Lee Irwin III
0 siblings, 1 reply; 200+ results
From: Russell King @ 2002-11-04 12:51 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Rusty Russell, torvalds, trivial, linux-kernel
On Mon, Nov 04, 2002 at 01:41:48PM +0100, Ralf Baechle wrote:
> On Mon, Nov 04, 2002 at 01:22:45PM +1100, Rusty Russell wrote:
> > As the number of bug-related macros grows, this makes sense.
> >
> > 1) Introduce linux/bug.h and #include it from linux/kernel.h so noone
> > breaks.
> > 2) Move BUG() macro from asm*/page.h to asm*/bug.h, and #include it.
>
> Great, people were talking about the mess caused by this just last night.
> Just one request, move the BUG_ON definition into <asm/bug.h> also. This
> permits the use of conditional trap instructions for those architecture
> that have them.
I'm a little peeved since everyone's likes this from Rusty, but ignored
exactly the same thing from me. Sigh, life is cruel some times.
Message-Id: E18289f-0007tm-00@flint.arm.linux.org.uk
Subject: [PATCH] 2.5.43-bug
Date: Thu, 17 Oct 2002 11:45:27 +0100
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [relevance 82%]
* Re: linux/bug.h and asm/bug.h
2002-11-04 2:43 82% ` William Lee Irwin III
@ 2002-11-04 12:41 82% ` Ralf Baechle
2002-11-04 12:51 82% ` Russell King
1 sibling, 1 reply; 200+ results
From: Ralf Baechle @ 2002-11-04 12:41 UTC (permalink / raw)
To: Rusty Russell; +Cc: torvalds, trivial, linux-kernel
On Mon, Nov 04, 2002 at 01:22:45PM +1100, Rusty Russell wrote:
> As the number of bug-related macros grows, this makes sense.
>
> 1) Introduce linux/bug.h and #include it from linux/kernel.h so noone
> breaks.
> 2) Move BUG() macro from asm*/page.h to asm*/bug.h, and #include it.
Great, people were talking about the mess caused by this just last night.
Just one request, move the BUG_ON definition into <asm/bug.h> also. This
permits the use of conditional trap instructions for those architecture
that have them.
Ralf
^ permalink raw reply [relevance 82%]
* Re: linux/bug.h and asm/bug.h
@ 2002-11-04 2:43 82% ` William Lee Irwin III
2002-11-04 12:41 82% ` Ralf Baechle
1 sibling, 0 replies; 200+ results
From: William Lee Irwin III @ 2002-11-04 2:43 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-kernel
On Mon, Nov 04, 2002 at 01:22:45PM +1100, Rusty Russell wrote:
> As the number of bug-related macros grows, this makes sense.
> 1) Introduce linux/bug.h and #include it from linux/kernel.h so noone
> breaks.
> 2) Move BUG() macro from asm*/page.h to asm*/bug.h, and #include it.
> Thanks,
> Rusty.
Thank you, this is a longstanding source of irritation (from the
standpoint of mere cleanliness) here.
Bill
^ permalink raw reply [relevance 82%]
* [BUG] Kernel panic while booting 2.5.45 (was: Re: [BUG]Kernel Panic while booting 2.5.44)
@ 2002-11-03 11:08 82% ` Andreas Tscharner
0 siblings, 0 replies; 200+ results
From: Andreas Tscharner @ 2002-11-03 11:08 UTC (permalink / raw)
To: Linux Kernel Mailinglist
On Sun, 27 Oct 2002 18:04:25 +0100
Andreas Tscharner <starfire@dplanet.ch> wrote:
Hello World,
The same problem again. Way too many oopses and finally:
>
>
> [<c01293db>] generic_file_read+0x7b/0x9c
> [<c0146b24>] vfs_follow_link+0x11c/0x180
> [<c014c419>] dput+0x19/0x184
> [<c012d03a>] kmem_cache_alloc+0x26/0x1b0
> [<c013ab30>] get_empty_filp+0x130/0x194
> [<c013aa4f>] get_empty_filp+0x4f/0x194
> [<c0138e99>] dentry_open+0xb9/0x16c
> [<c0139981>] vfs_read+0x1c/0x158
> [<c01418f8>] kernel_read+0x40/0x4c
> [<c0157e90>] load_elf_binary+0x2ec/0xb08
> [<c0157ba4>] load_elf_binary+0x0/0xb08
> [<c01300e1>] __alloc_pages+0x81/0x23c
> [<c0142452>] search_binary_handler+0x96/0x200
> [<c0142760>] do_execve>011a4/0x250
> [<c0142777>] do_execve+0x1bb/0x250
> [<c0105b0f>] sys_execve+0x2f/0x60
> [<c0106fcb>] syscall_call+0x7/0xb
> [<c0110068>] free_initmem+0x54/0x7c
> [<c0105165>] init+0x10d/0x178
> [<c0105058>] init+0x0/0x178
> [<c01054b9>] kernel_thread_helper+0x5/0xc
>
> bad: scheduling while atomic!
> Call Trace
> [<c01118b1>] schedule+0x3d/0x2d8
> [<c0106ff2>] work_resched+0x5/0x16
> [<c01054b9>] kernel_thread_helper+0x5/0xc
>
> Unable to handle kernel paging request at virtual address 40000b50
> printing eip:
> 40000b50
> *pde=00000000
> Oops: 0004
>
> CPU: 0
> EIP: 0023:[<40000b50>] Not tainted
> EFLAGS: 00010246
> eax: 00000000 ebx: 00000000 ecx: 00000000 edx: 00000000
> esi: 00000000 edi: 00000000 ebp: 00000000 esp: bfffff10
> ds: 002b es: 002b ss: 002b
>
> Process init (pid: 1, threadinfo=dffc6000 task=dffc4040)
> <0>Kernep panic: Attempted to kill init!
>
>
>
The configuration is still the same:
>
> #
> # Automatically generated by make menuconfig: don't edit
> #
> CONFIG_X86=y
> # CONFIG_SBUS is not set
> CONFIG_UID16=y
> CONFIG_GENERIC_ISA_DMA=y
>
> #
> # Code maturity level options
> #
> CONFIG_EXPERIMENTAL=y
>
> #
> # General setup
> #
> CONFIG_NET=y
> CONFIG_SYSVIPC=y
> CONFIG_BSD_PROCESS_ACCT=y
> CONFIG_SYSCTL=y
>
> #
> # Loadable module support
> #
> CONFIG_MODULES=y
> # CONFIG_MODVERSIONS is not set
> CONFIG_KMOD=y
>
> #
> # Processor type and features
> #
> # CONFIG_M386 is not set
> # CONFIG_M486 is not set
> # CONFIG_M586 is not set
> # CONFIG_M586TSC is not set
> # CONFIG_M586MMX is not set
> # CONFIG_M686 is not set
> CONFIG_MPENTIUMIII=y
> # CONFIG_MPENTIUM4 is not set
> # CONFIG_MK6 is not set
> # CONFIG_MK7 is not set
> # CONFIG_MELAN is not set
> # CONFIG_MCRUSOE is not set
> # CONFIG_MWINCHIPC6 is not set
> # CONFIG_MWINCHIP2 is not set
> # CONFIG_MWINCHIP3D is not set
> # CONFIG_MCYRIXIII is not set
> CONFIG_X86_WP_WORKS_OK=y
> CONFIG_X86_INVLPG=y
> CONFIG_X86_CMPXCHG=y
> CONFIG_X86_XADD=y
> CONFIG_X86_BSWAP=y
> CONFIG_X86_POPAD_OK=y
> # CONFIG_RWSEM_GENERIC_SPINLOCK is not set
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_X86_L1_CACHE_SHIFT=5
> CONFIG_X86_TSC=y
> CONFIG_X86_GOOD_APIC=y
> CONFIG_X86_USE_PPRO_CHECKSUM=y
> # CONFIG_HUGETLB_PAGE is not set
> # CONFIG_SMP is not set
> CONFIG_PREEMPT=y
> # CONFIG_X86_UP_APIC is not set
> # CONFIG_X86_UP_IOAPIC is not set
> CONFIG_X86_MCE=y
> # CONFIG_X86_MCE_NONFATAL is not set
> # CONFIG_X86_MCE_P4THERMAL is not set
> # CONFIG_CPU_FREQ is not set
> # CONFIG_TOSHIBA is not set
> # CONFIG_I8K is not set
> # CONFIG_MICROCODE is not set
> CONFIG_X86_MSR=y
> CONFIG_X86_CPUID=y
> # CONFIG_EDD is not set
> CONFIG_NOHIGHMEM=y
> # CONFIG_HIGHMEM4G is not set
> # CONFIG_HIGHMEM64G is not set
> # CONFIG_MATH_EMULATION is not set
> CONFIG_MTRR=y
> CONFIG_HAVE_DEC_LOCK=y
>
> #
> # Power management options (ACPI, APM)
> #
>
> #
> # ACPI Support
> #
> # CONFIG_ACPI is not set
> # CONFIG_PM is not set
> # CONFIG_APM is not set
>
> #
> # Bus options (PCI, PCMCIA, EISA, MCA, ISA)
> #
> CONFIG_PCI=y
> # CONFIG_PCI_GOBIOS is not set
> # CONFIG_PCI_GODIRECT is not set
> CONFIG_PCI_GOANY=y
> CONFIG_PCI_BIOS=y
> CONFIG_PCI_DIRECT=y
> # CONFIG_SCx200 is not set
> CONFIG_PCI_NAMES=y
> # CONFIG_ISA is not set
> # CONFIG_EISA is not set
> # CONFIG_MCA is not set
> # CONFIG_HOTPLUG is not set
> # CONFIG_PCMCIA is not set
> # CONFIG_HOTPLUG_PCI is not set
>
> #
> # Executable file formats
> #
> CONFIG_KCORE_ELF=y
> # CONFIG_KCORE_AOUT is not set
> CONFIG_BINFMT_AOUT=m
> CONFIG_BINFMT_ELF=y
> CONFIG_BINFMT_MISC=m
>
> #
> # Memory Technology Devices (MTD)
> #
> # CONFIG_MTD is not set
>
> #
> # Parallel port support
> #
> CONFIG_PARPORT=y
> CONFIG_PARPORT_PC=y
> CONFIG_PARPORT_PC_CML1=y
> # CONFIG_PARPORT_SERIAL is not set
> # CONFIG_PARPORT_PC_FIFO is not set
> # CONFIG_PARPORT_PC_SUPERIO is not set
> # CONFIG_PARPORT_AMIGA is not set
> # CONFIG_PARPORT_MFC3 is not set
> # CONFIG_PARPORT_ATARI is not set
> # CONFIG_PARPORT_GSC is not set
> # CONFIG_PARPORT_SUNBPP is not set
> # CONFIG_PARPORT_OTHER is not set
> CONFIG_PARPORT_1284=y
>
> #
> # Plug and Play configuration
> #
> # CONFIG_PNP is not set
> # CONFIG_PNP_NAMES is not set
> # CONFIG_PNP_DEBUG is not set
> # CONFIG_ISAPNP is not set
> # CONFIG_PNPBIOS is not set
>
> #
> # Block devices
> #
> CONFIG_BLK_DEV_FD=y
> # CONFIG_BLK_DEV_XD is not set
> # CONFIG_PARIDE is not set
> # CONFIG_BLK_CPQ_DA is not set
> # CONFIG_BLK_CPQ_CISS_DA is not set
> # CONFIG_CISS_SCSI_TAPE is not set
> # CONFIG_BLK_DEV_DAC960 is not set
> # CONFIG_BLK_DEV_UMEM is not set
> # CONFIG_BLK_DEV_LOOP is not set
> # CONFIG_BLK_DEV_NBD is not set
> # CONFIG_BLK_DEV_RAM is not set
> # CONFIG_BLK_DEV_INITRD is not set
> # CONFIG_LBD is not set
>
> #
> # ATA/ATAPI/MFM/RLL device support
> #
> CONFIG_IDE=y
>
> #
> # IDE, ATA and ATAPI Block devices
> #
> CONFIG_BLK_DEV_IDE=y
> # CONFIG_BLK_DEV_HD_IDE is not set
> # CONFIG_BLK_DEV_HD is not set
> CONFIG_BLK_DEV_IDEDISK=y
> CONFIG_IDEDISK_MULTI_MODE=y
> # CONFIG_IDEDISK_STROKE is not set
> # CONFIG_BLK_DEV_IDECS is not set
> CONFIG_BLK_DEV_IDECD=y
> # CONFIG_BLK_DEV_IDEFLOPPY is not set
> CONFIG_BLK_DEV_IDESCSI=m
> # CONFIG_IDE_TASK_IOCTL is not set
> # CONFIG_BLK_DEV_CMD640 is not set
> # CONFIG_BLK_DEV_CMD640_ENHANCED is not set
> # CONFIG_BLK_DEV_ISAPNP is not set
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_BLK_DEV_GENERIC=y
> CONFIG_IDEPCI_SHARE_IRQ=y
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> # CONFIG_BLK_DEV_IDE_TCQ is not set
> # CONFIG_BLK_DEV_IDE_TCQ_DEFAULT is not set
> # CONFIG_BLK_DEV_OFFBOARD is not set
> # CONFIG_BLK_DEV_IDEDMA_FORCED is not set
> CONFIG_IDEDMA_PCI_AUTO=y
> # CONFIG_IDEDMA_ONLYDISK is not set
> CONFIG_BLK_DEV_IDEDMA=y
> # CONFIG_IDEDMA_PCI_WIP is not set
> # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
> CONFIG_BLK_DEV_ADMA=y
> # CONFIG_BLK_DEV_AEC62XX is not set
> # CONFIG_BLK_DEV_ALI15X3 is not set
> # CONFIG_WDC_ALI15X3 is not set
> # CONFIG_BLK_DEV_AMD74XX is not set
> # CONFIG_AMD74XX_OVERRIDE is not set
> # CONFIG_BLK_DEV_CMD64X is not set
> # CONFIG_BLK_DEV_CY82C693 is not set
> # CONFIG_BLK_DEV_CS5530 is not set
> # CONFIG_BLK_DEV_HPT34X is not set
> # CONFIG_HPT34X_AUTODMA is not set
> # CONFIG_BLK_DEV_HPT366 is not set
> # CONFIG_BLK_DEV_PIIX is not set
> # CONFIG_BLK_DEV_NFORCE is not set
> # CONFIG_BLK_DEV_NS87415 is not set
> # CONFIG_BLK_DEV_OPTI621 is not set
> # CONFIG_BLK_DEV_PDC202XX_OLD is not set
> # CONFIG_PDC202XX_BURST is not set
> # CONFIG_BLK_DEV_PDC202XX_NEW is not set
> # CONFIG_PDC202XX_FORCE is not set
> # CONFIG_BLK_DEV_RZ1000 is not set
> # CONFIG_BLK_DEV_SVWKS is not set
> # CONFIG_BLK_DEV_SIIMAGE is not set
> # CONFIG_BLK_DEV_SIS5513 is not set
> # CONFIG_BLK_DEV_SLC90E66 is not set
> # CONFIG_BLK_DEV_TRM290 is not set
> # CONFIG_BLK_DEV_VIA82CXXX is not set
> # CONFIG_IDE_CHIPSETS is not set
> CONFIG_IDEDMA_AUTO=y
> # CONFIG_IDEDMA_IVB is not set
> # CONFIG_DMA_NONPCI is not set
> CONFIG_BLK_DEV_IDE_MODES=y
>
> #
> # SCSI device support
> #
> CONFIG_SCSI=y
> CONFIG_BLK_DEV_SD=y
> CONFIG_SD_EXTRA_DEVS=40
> # CONFIG_CHR_DEV_ST is not set
> # CONFIG_CHR_DEV_OSST is not set
> # CONFIG_BLK_DEV_SR is not set
> CONFIG_CHR_DEV_SG=y
> # CONFIG_SCSI_MULTI_LUN is not set
> # CONFIG_SCSI_REPORT_LUNS is not set
> # CONFIG_SCSI_CONSTANTS is not set
> # CONFIG_SCSI_LOGGING is not set
>
> #
> # SCSI low-level drivers
> #
> # CONFIG_BLK_DEV_3W_XXXX_RAID is not set
> # CONFIG_SCSI_7000FASST is not set
> # CONFIG_SCSI_ACARD is not set
> # CONFIG_SCSI_AACRAID is not set
> # CONFIG_SCSI_AIC7XXX is not set
> # CONFIG_SCSI_AIC7XXX_OLD is not set
> # CONFIG_SCSI_DPT_I2O is not set
> # CONFIG_SCSI_ADVANSYS is not set
> # CONFIG_SCSI_IN2000 is not set
> # CONFIG_SCSI_AM53C974 is not set
> # CONFIG_SCSI_MEGARAID is not set
> # CONFIG_SCSI_BUSLOGIC is not set
> # CONFIG_SCSI_CPQFCTS is not set
> # CONFIG_SCSI_DMX3191D is not set
> # CONFIG_SCSI_DTC3280 is not set
> # CONFIG_SCSI_EATA is not set
> # CONFIG_SCSI_EATA_DMA is not set
> # CONFIG_SCSI_EATA_PIO is not set
> # CONFIG_SCSI_FUTURE_DOMAIN is not set
> # CONFIG_SCSI_GDTH is not set
> # CONFIG_SCSI_GENERIC_NCR5380 is not set
> # CONFIG_SCSI_IPS is not set
> # CONFIG_SCSI_INITIO is not set
> # CONFIG_SCSI_INIA100 is not set
> CONFIG_SCSI_PPA=y
> # CONFIG_SCSI_IMM is not set
> # CONFIG_SCSI_IZIP_EPP16 is not set
> # CONFIG_SCSI_IZIP_SLOW_CTR is not set
> # CONFIG_SCSI_NCR53C406A is not set
> # CONFIG_SCSI_NCR53C7xx is not set
> # CONFIG_SCSI_SYM53C8XX_2 is not set
> # CONFIG_SCSI_NCR53C8XX is not set
> # CONFIG_SCSI_SYM53C8XX is not set
> # CONFIG_SCSI_PAS16 is not set
> # CONFIG_SCSI_PCI2000 is not set
> # CONFIG_SCSI_PCI2220I is not set
> # CONFIG_SCSI_PSI240I is not set
> # CONFIG_SCSI_QLOGIC_FAS is not set
> # CONFIG_SCSI_QLOGIC_ISP is not set
> # CONFIG_SCSI_QLOGIC_FC is not set
> # CONFIG_SCSI_QLOGIC_1280 is not set
> # CONFIG_SCSI_SYM53C416 is not set
> # CONFIG_SCSI_DC390T is not set
> # CONFIG_SCSI_T128 is not set
> # CONFIG_SCSI_U14_34F is not set
> # CONFIG_SCSI_NSP32 is not set
> # CONFIG_SCSI_DEBUG is not set
>
> #
> # Multi-device support (RAID and LVM)
> #
> # CONFIG_MD is not set
> # CONFIG_BLK_DEV_MD is not set
> # CONFIG_MD_LINEAR is not set
> # CONFIG_MD_RAID0 is not set
> # CONFIG_MD_RAID1 is not set
> # CONFIG_MD_RAID5 is not set
> # CONFIG_MD_MULTIPATH is not set
> # CONFIG_BLK_DEV_LVM is not set
>
> #
> # Fusion MPT device support
> #
> # CONFIG_FUSION is not set
> # CONFIG_FUSION_BOOT is not set
> # CONFIG_FUSION_ISENSE is not set
> # CONFIG_FUSION_CTL is not set
> # CONFIG_FUSION_LAN is not set
>
> #
> # IEEE 1394 (FireWire) support (EXPERIMENTAL)
> #
> # CONFIG_IEEE1394 is not set
>
> #
> # I2O device support
> #
> # CONFIG_I2O is not set
> # CONFIG_I2O_PCI is not set
> # CONFIG_I2O_BLOCK is not set
> # CONFIG_I2O_LAN is not set
> # CONFIG_I2O_SCSI is not set
> # CONFIG_I2O_PROC is not set
>
> #
> # Networking options
> #
> CONFIG_PACKET=y
> # CONFIG_PACKET_MMAP is not set
> # CONFIG_NETLINK_DEV is not set
> # CONFIG_NETFILTER is not set
> # CONFIG_FILTER is not set
> CONFIG_UNIX=y
> CONFIG_INET=y
> # CONFIG_IP_MULTICAST is not set
> # CONFIG_IP_ADVANCED_ROUTER is not set
> # CONFIG_IP_PNP is not set
> # CONFIG_NET_IPIP is not set
> # CONFIG_NET_IPGRE is not set
> # CONFIG_ARPD is not set
> # CONFIG_INET_ECN is not set
> # CONFIG_SYN_COOKIES is not set
> CONFIG_IPV6=m
>
> #
> # SCTP Configuration (EXPERIMENTAL)
> #
> CONFIG_IPV6_SCTP__=m
> # CONFIG_IP_SCTP is not set
> # CONFIG_ATM is not set
> # CONFIG_VLAN_8021Q is not set
> # CONFIG_LLC is not set
> # CONFIG_IPX is not set
> # CONFIG_ATALK is not set
> # CONFIG_DEV_APPLETALK is not set
> # CONFIG_DECNET is not set
> # CONFIG_BRIDGE is not set
> # CONFIG_X25 is not set
> # CONFIG_LAPB is not set
> # CONFIG_NET_DIVERT is not set
> # CONFIG_ECONET is not set
> # CONFIG_WAN_ROUTER is not set
> # CONFIG_NET_FASTROUTE is not set
> # CONFIG_NET_HW_FLOWCONTROL is not set
>
> #
> # QoS and/or fair queueing
> #
> # CONFIG_NET_SCHED is not set
>
> #
> # Network device support
> #
> CONFIG_NETDEVICES=y
>
> #
> # ARCnet devices
> #
> # CONFIG_ARCNET is not set
> CONFIG_DUMMY=m
> # CONFIG_BONDING is not set
> # CONFIG_EQUALIZER is not set
> # CONFIG_TUN is not set
> # CONFIG_ETHERTAP is not set
>
> #
> # Ethernet (10 or 100Mbit)
> #
> CONFIG_NET_ETHERNET=y
> # CONFIG_SUNLANCE is not set
> # CONFIG_HAPPYMEAL is not set
> # CONFIG_SUNBMAC is not set
> # CONFIG_SUNQE is not set
> # CONFIG_SUNGEM is not set
> CONFIG_NET_VENDOR_3COM=y
> # CONFIG_EL1 is not set
> # CONFIG_EL2 is not set
> # CONFIG_ELPLUS is not set
> # CONFIG_EL16 is not set
> # CONFIG_ELMC is not set
> # CONFIG_ELMC_II is not set
> CONFIG_VORTEX=y
> # CONFIG_LANCE is not set
> # CONFIG_NET_VENDOR_SMC is not set
> # CONFIG_NET_VENDOR_RACAL is not set
>
> #
> # Tulip family network device support
> #
> # CONFIG_NET_TULIP is not set
> # CONFIG_HP100 is not set
> # CONFIG_NET_ISA is not set
> # CONFIG_NET_PCI is not set
> # CONFIG_NET_POCKET is not set
>
> #
> # Ethernet (1000 Mbit)
> #
> # CONFIG_ACENIC is not set
> # CONFIG_DL2K is not set
> # CONFIG_E1000 is not set
> # CONFIG_E1000_NAPI is not set
> # CONFIG_MYRI_SBUS is not set
> # CONFIG_NS83820 is not set
> # CONFIG_HAMACHI is not set
> # CONFIG_YELLOWFIN is not set
> # CONFIG_SK98LIN is not set
> # CONFIG_TIGON3 is not set
> # CONFIG_FDDI is not set
> # CONFIG_HIPPI is not set
> # CONFIG_PLIP is not set
> # CONFIG_PPP is not set
> # CONFIG_SLIP is not set
>
> #
> # Wireless LAN (non-hamradio)
> #
> # CONFIG_NET_RADIO is not set
>
> #
> # Token Ring devices
> #
> # CONFIG_TR is not set
> # CONFIG_NET_FC is not set
> # CONFIG_RCPCI is not set
> # CONFIG_SHAPER is not set
>
> #
> # Wan interfaces
> #
> # CONFIG_WAN is not set
>
> #
> # Amateur Radio support
> #
> # CONFIG_HAMRADIO is not set
>
> #
> # IrDA (infrared) support
> #
> # CONFIG_IRDA is not set
>
> #
> # ISDN subsystem
> #
> # CONFIG_ISDN_BOOL is not set
>
> #
> # Telephony Support
> #
> # CONFIG_PHONE is not set
> # CONFIG_PHONE_IXJ is not set
> # CONFIG_PHONE_IXJ_PCMCIA is not set
>
> #
> # Input device support
> #
> CONFIG_INPUT=y
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_INPUT_MOUSEDEV_PSAUX=y
> CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
> CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
> # CONFIG_INPUT_JOYDEV is not set
> # CONFIG_INPUT_TSDEV is not set
> # CONFIG_INPUT_EVDEV is not set
> # CONFIG_INPUT_EVBUG is not set
> # CONFIG_GAMEPORT is not set
> CONFIG_SOUND_GAMEPORT=y
> # CONFIG_GAMEPORT_NS558 is not set
> # CONFIG_GAMEPORT_L4 is not set
> # CONFIG_GAMEPORT_EMU10K1 is not set
> # CONFIG_GAMEPORT_VORTEX is not set
> # CONFIG_GAMEPORT_FM801 is not set
> # CONFIG_GAMEPORT_CS461x is not set
> CONFIG_SERIO=y
> CONFIG_SERIO_I8042=y
> # CONFIG_SERIO_SERPORT is not set
> # CONFIG_SERIO_CT82C710 is not set
> # CONFIG_SERIO_PARKBD is not set
> CONFIG_INPUT_KEYBOARD=y
> CONFIG_KEYBOARD_ATKBD=y
> # CONFIG_KEYBOARD_SUNKBD is not set
> # CONFIG_KEYBOARD_XTKBD is not set
> # CONFIG_KEYBOARD_NEWTON is not set
> CONFIG_INPUT_MOUSE=y
> CONFIG_MOUSE_PS2=y
> # CONFIG_MOUSE_SERIAL is not set
> # CONFIG_MOUSE_INPORT is not set
> # CONFIG_MOUSE_LOGIBM is not set
> # CONFIG_MOUSE_PC110PAD is not set
> # CONFIG_INPUT_JOYSTICK is not set
> # CONFIG_JOYSTICK_ANALOG is not set
> # CONFIG_JOYSTICK_A3D is not set
> # CONFIG_JOYSTICK_ADI is not set
> # CONFIG_JOYSTICK_COBRA is not set
> # CONFIG_JOYSTICK_GF2K is not set
> # CONFIG_JOYSTICK_GRIP is not set
> # CONFIG_JOYSTICK_GRIP_MP is not set
> # CONFIG_JOYSTICK_GUILLEMOT is not set
> # CONFIG_JOYSTICK_INTERACT is not set
> # CONFIG_JOYSTICK_SIDEWINDER is not set
> # CONFIG_JOYSTICK_TMDC is not set
> # CONFIG_JOYSTICK_IFORCE is not set
> # CONFIG_JOYSTICK_WARRIOR is not set
> # CONFIG_JOYSTICK_MAGELLAN is not set
> # CONFIG_JOYSTICK_SPACEORB is not set
> # CONFIG_JOYSTICK_SPACEBALL is not set
> # CONFIG_JOYSTICK_STINGER is not set
> # CONFIG_JOYSTICK_TWIDDLER is not set
> # CONFIG_JOYSTICK_DB9 is not set
> # CONFIG_JOYSTICK_GAMECON is not set
> # CONFIG_JOYSTICK_TURBOGRAFX is not set
> # CONFIG_INPUT_JOYDUMP is not set
> # CONFIG_INPUT_TOUCHSCREEN is not set
> # CONFIG_TOUCHSCREEN_GUNZE is not set
> # CONFIG_INPUT_MISC is not set
> # CONFIG_INPUT_PCSPKR is not set
> # CONFIG_INPUT_UINPUT is not set
>
> #
> # Character devices
> #
> CONFIG_VT=y
> CONFIG_VT_CONSOLE=y
> CONFIG_HW_CONSOLE=y
> # CONFIG_SERIAL_NONSTANDARD is not set
>
> #
> # Serial drivers
> #
> CONFIG_SERIAL_8250=y
> # CONFIG_SERIAL_8250_CONSOLE is not set
> # CONFIG_SERIAL_8250_CS is not set
> # CONFIG_SERIAL_8250_EXTENDED is not set
> # CONFIG_SERIAL_8250_MANY_PORTS is not set
> # CONFIG_SERIAL_8250_SHARE_IRQ is not set
> # CONFIG_SERIAL_8250_DETECT_IRQ is not set
> # CONFIG_SERIAL_8250_MULTIPORT is not set
> # CONFIG_SERIAL_8250_RSA is not set
> CONFIG_SERIAL_CORE=y
> CONFIG_UNIX98_PTYS=y
> CONFIG_UNIX98_PTY_COUNT=256
> CONFIG_PRINTER=y
> # CONFIG_LP_CONSOLE is not set
> # CONFIG_PPDEV is not set
> # CONFIG_TIPAR is not set
>
> #
> # I2C support
> #
> # CONFIG_I2C is not set
>
> #
> # Mice
> #
> # CONFIG_BUSMOUSE is not set
> # CONFIG_QIC02_TAPE is not set
>
> #
> # Watchdog Cards
> #
> # CONFIG_WATCHDOG is not set
> CONFIG_INTEL_RNG=y
> # CONFIG_AMD_RNG is not set
> # CONFIG_NVRAM is not set
> CONFIG_RTC=y
> # CONFIG_DTLK is not set
> # CONFIG_R3964 is not set
> # CONFIG_APPLICOM is not set
> # CONFIG_SONYPI is not set
>
> #
> # Ftape, the floppy tape device driver
> #
> # CONFIG_FTAPE is not set
> CONFIG_AGP=y
> CONFIG_AGP_INTEL=y
> # CONFIG_AGP_I810 is not set
> # CONFIG_AGP_VIA is not set
> # CONFIG_AGP_AMD is not set
> # CONFIG_AGP_SIS is not set
> # CONFIG_AGP_ALI is not set
> # CONFIG_AGP_SWORKS is not set
> # CONFIG_AGP_AMD_8151 is not set
> CONFIG_DRM=y
> # CONFIG_DRM_TDFX is not set
> # CONFIG_DRM_R128 is not set
> # CONFIG_DRM_RADEON is not set
> # CONFIG_DRM_I810 is not set
> # CONFIG_DRM_I830 is not set
> # CONFIG_DRM_MGA is not set
> # CONFIG_MWAVE is not set
> # CONFIG_SCx200_GPIO is not set
> # CONFIG_RAW_DRIVER is not set
>
> #
> # Multimedia devices
> #
> # CONFIG_VIDEO_DEV is not set
>
> #
> # File systems
> #
> # CONFIG_QUOTA is not set
> # CONFIG_QFMT_V1 is not set
> # CONFIG_QFMT_V2 is not set
> # CONFIG_AUTOFS_FS is not set
> CONFIG_AUTOFS4_FS=y
> CONFIG_REISERFS_FS=y
> # CONFIG_REISERFS_CHECK is not set
> # CONFIG_REISERFS_PROC_INFO is not set
> # CONFIG_ADFS_FS is not set
> # CONFIG_ADFS_FS_RW is not set
> # CONFIG_AFFS_FS is not set
> # CONFIG_HFS_FS is not set
> # CONFIG_BFS_FS is not set
> CONFIG_EXT3_FS=m
> CONFIG_JBD=m
> # CONFIG_JBD_DEBUG is not set
> CONFIG_FAT_FS=m
> # CONFIG_MSDOS_FS is not set
> # CONFIG_UMSDOS_FS is not set
> CONFIG_VFAT_FS=m
> # CONFIG_EFS_FS is not set
> # CONFIG_JFFS_FS is not set
> # CONFIG_JFFS2_FS is not set
> # CONFIG_CRAMFS is not set
> # CONFIG_TMPFS is not set
> CONFIG_RAMFS=y
> CONFIG_ISO9660_FS=y
> CONFIG_JOLIET=y
> # CONFIG_ZISOFS is not set
> # CONFIG_JFS_FS is not set
> # CONFIG_JFS_DEBUG is not set
> # CONFIG_JFS_STATISTICS is not set
> # CONFIG_MINIX_FS is not set
> # CONFIG_VXFS_FS is not set
> # CONFIG_NTFS_FS is not set
> # CONFIG_NTFS_DEBUG is not set
> # CONFIG_NTFS_RW is not set
> # CONFIG_HPFS_FS is not set
> CONFIG_PROC_FS=y
> CONFIG_DEVFS_FS=y
> CONFIG_DEVFS_MOUNT=y
> # CONFIG_DEVFS_DEBUG is not set
> CONFIG_DEVPTS_FS=y
> # CONFIG_QNX4FS_FS is not set
> # CONFIG_QNX4FS_RW is not set
> # CONFIG_ROMFS_FS is not set
> CONFIG_EXT2_FS=y
> # CONFIG_SYSV_FS is not set
> CONFIG_UDF_FS=m
> # CONFIG_UDF_RW is not set
> # CONFIG_UFS_FS is not set
> # CONFIG_UFS_FS_WRITE is not set
> # CONFIG_XFS_FS is not set
> # CONFIG_XFS_RT is not set
> # CONFIG_XFS_QUOTA is not set
>
> #
> # Network File Systems
> #
> # CONFIG_CODA_FS is not set
> # CONFIG_INTERMEZZO_FS is not set
> # CONFIG_NFS_FS is not set
> # CONFIG_NFS_V3 is not set
> # CONFIG_NFS_V4 is not set
> # CONFIG_ROOT_NFS is not set
> # CONFIG_NFSD is not set
> # CONFIG_NFSD_V3 is not set
> # CONFIG_NFSD_V4 is not set
> # CONFIG_NFSD_TCP is not set
> # CONFIG_SUNRPC is not set
> # CONFIG_LOCKD is not set
> # CONFIG_EXPORTFS is not set
> # CONFIG_CIFS is not set
> # CONFIG_SMB_FS is not set
> # CONFIG_NCP_FS is not set
> # CONFIG_NCPFS_PACKET_SIGNING is not set
> # CONFIG_NCPFS_IOCTL_LOCKING is not set
> # CONFIG_NCPFS_STRONG is not set
> # CONFIG_NCPFS_NFS_NS is not set
> # CONFIG_NCPFS_OS2_NS is not set
> # CONFIG_NCPFS_SMALLDOS is not set
> # CONFIG_NCPFS_NLS is not set
> # CONFIG_NCPFS_EXTRAS is not set
> # CONFIG_AFS_FS is not set
> # CONFIG_ZISOFS_FS is not set
>
> #
> # Partition Types
> #
> # CONFIG_PARTITION_ADVANCED is not set
> CONFIG_MSDOS_PARTITION=y
> # CONFIG_SMB_NLS is not set
> CONFIG_NLS=y
>
> #
> # Native Language Support
> #
> CONFIG_NLS_DEFAULT="iso8859-1"
> CONFIG_NLS_CODEPAGE_437=m
> # CONFIG_NLS_CODEPAGE_737 is not set
> # CONFIG_NLS_CODEPAGE_775 is not set
> CONFIG_NLS_CODEPAGE_850=m
> # CONFIG_NLS_CODEPAGE_852 is not set
> # CONFIG_NLS_CODEPAGE_855 is not set
> # CONFIG_NLS_CODEPAGE_857 is not set
> # CONFIG_NLS_CODEPAGE_860 is not set
> # CONFIG_NLS_CODEPAGE_861 is not set
> # CONFIG_NLS_CODEPAGE_862 is not set
> # CONFIG_NLS_CODEPAGE_863 is not set
> # CONFIG_NLS_CODEPAGE_864 is not set
> # CONFIG_NLS_CODEPAGE_865 is not set
> # CONFIG_NLS_CODEPAGE_866 is not set
> # CONFIG_NLS_CODEPAGE_869 is not set
> # CONFIG_NLS_CODEPAGE_936 is not set
> # CONFIG_NLS_CODEPAGE_950 is not set
> # CONFIG_NLS_CODEPAGE_932 is not set
> # CONFIG_NLS_CODEPAGE_949 is not set
> # CONFIG_NLS_CODEPAGE_874 is not set
> # CONFIG_NLS_ISO8859_8 is not set
> # CONFIG_NLS_CODEPAGE_1250 is not set
> # CONFIG_NLS_CODEPAGE_1251 is not set
> CONFIG_NLS_ISO8859_1=y
> # CONFIG_NLS_ISO8859_2 is not set
> # CONFIG_NLS_ISO8859_3 is not set
> # CONFIG_NLS_ISO8859_4 is not set
> # CONFIG_NLS_ISO8859_5 is not set
> # CONFIG_NLS_ISO8859_6 is not set
> # CONFIG_NLS_ISO8859_7 is not set
> # CONFIG_NLS_ISO8859_9 is not set
> # CONFIG_NLS_ISO8859_13 is not set
> # CONFIG_NLS_ISO8859_14 is not set
> CONFIG_NLS_ISO8859_15=m
> # CONFIG_NLS_KOI8_R is not set
> # CONFIG_NLS_KOI8_U is not set
> # CONFIG_NLS_UTF8 is not set
>
> #
> # Console drivers
> #
> CONFIG_VGA_CONSOLE=y
> CONFIG_VIDEO_SELECT=y
> # CONFIG_MDA_CONSOLE is not set
>
> #
> # Frame-buffer support
> #
> # CONFIG_FB is not set
>
> #
> # Sound
> #
> CONFIG_SOUND=y
>
> #
> # Open Sound System
> #
> # CONFIG_SOUND_PRIME is not set
>
> #
> # Advanced Linux Sound Architecture
> #
> CONFIG_SND=m
> CONFIG_SND_SEQUENCER=m
> # CONFIG_SND_SEQ_DUMMY is not set
> CONFIG_SND_OSSEMUL=y
> CONFIG_SND_MIXER_OSS=m
> CONFIG_SND_PCM_OSS=m
> CONFIG_SND_SEQUENCER_OSS=y
> CONFIG_SND_RTCTIMER=m
> # CONFIG_SND_VERBOSE_PRINTK is not set
> # CONFIG_SND_DEBUG is not set
> # CONFIG_SND_DEBUG_MEMORY is not set
> # CONFIG_SND_DEBUG_DETECT is not set
>
> #
> # Generic devices
> #
> # CONFIG_SND_DUMMY is not set
> # CONFIG_SND_VIRMIDI is not set
> # CONFIG_SND_MTPAV is not set
> # CONFIG_SND_SERIAL_U16550 is not set
> # CONFIG_SND_MPU401 is not set
>
> #
> # PCI devices
> #
> # CONFIG_SND_ALI5451 is not set
> # CONFIG_SND_CS46XX is not set
> # CONFIG_SND_CS46XX_NEW_DSP is not set
> # CONFIG_SND_CS4281 is not set
> CONFIG_SND_EMU10K1=m
> # CONFIG_SND_KORG1212 is not set
> # CONFIG_SND_NM256 is not set
> # CONFIG_SND_RME32 is not set
> # CONFIG_SND_RME96 is not set
> # CONFIG_SND_RME9652 is not set
> # CONFIG_SND_HDSP is not set
> # CONFIG_SND_TRIDENT is not set
> # CONFIG_SND_YMFPCI is not set
> # CONFIG_SND_ALS4000 is not set
> # CONFIG_SND_CMIPCI is not set
> # CONFIG_SND_ENS1370 is not set
> # CONFIG_SND_ENS1371 is not set
> # CONFIG_SND_ES1938 is not set
> # CONFIG_SND_ES1968 is not set
> # CONFIG_SND_MAESTRO3 is not set
> # CONFIG_SND_FM801 is not set
> # CONFIG_SND_ICE1712 is not set
> # CONFIG_SND_INTEL8X0 is not set
> # CONFIG_SND_SONICVIBES is not set
> # CONFIG_SND_VIA82XX is not set
>
> #
> # ALSA USB devices
> #
> # CONFIG_SND_USB_AUDIO is not set
>
> #
> # USB support
> #
> CONFIG_USB=y
> # CONFIG_USB_DEBUG is not set
> # CONFIG_USB_DEVICEFS is not set
> # CONFIG_USB_LONG_TIMEOUT is not set
> # CONFIG_USB_BANDWIDTH is not set
> # CONFIG_USB_DYNAMIC_MINORS is not set
> # CONFIG_USB_EHCI_HCD is not set
> # CONFIG_USB_OHCI_HCD is not set
> CONFIG_USB_UHCI_HCD_ALT=y
> # CONFIG_USB_AUDIO is not set
> # CONFIG_USB_BLUETOOTH_TTY is not set
> # CONFIG_USB_MIDI is not set
> # CONFIG_USB_ACM is not set
> # CONFIG_USB_PRINTER is not set
> CONFIG_USB_STORAGE=y
> # CONFIG_USB_STORAGE_DEBUG is not set
> # CONFIG_USB_STORAGE_DATAFAB is not set
> # CONFIG_USB_STORAGE_FREECOM is not set
> # CONFIG_USB_STORAGE_ISD200 is not set
> # CONFIG_USB_STORAGE_DPCM is not set
> # CONFIG_USB_STORAGE_HP8200e is not set
> # CONFIG_USB_STORAGE_SDDR09 is not set
> # CONFIG_USB_STORAGE_SDDR55 is not set
> # CONFIG_USB_STORAGE_JUMPSHOT is not set
> # CONFIG_USB_HID is not set
> # CONFIG_USB_HIDINPUT is not set
> # CONFIG_HID_FF is not set
> # CONFIG_HID_PID is not set
> # CONFIG_LOGITECH_FF is not set
> # CONFIG_USB_HIDDEV is not set
>
> #
> # USB HID Boot Protocol drivers
> #
> # CONFIG_USB_KBD is not set
> # CONFIG_USB_MOUSE is not set
> # CONFIG_USB_AIPTEK is not set
> # CONFIG_USB_WACOM is not set
> # CONFIG_USB_POWERMATE is not set
> # CONFIG_USB_XPAD is not set
> # CONFIG_USB_MDC800 is not set
> # CONFIG_USB_SCANNER is not set
> # CONFIG_USB_MICROTEK is not set
> # CONFIG_USB_HPUSBSCSI is not set
> # CONFIG_USB_DABUSB is not set
> # CONFIG_USB_VICAM is not set
> # CONFIG_USB_DSBR is not set
> # CONFIG_USB_IBMCAM is not set
> # CONFIG_USB_KONICAWC is not set
> # CONFIG_USB_OV511 is not set
> # CONFIG_USB_PWC is not set
> # CONFIG_USB_SE401 is not set
> # CONFIG_USB_STV680 is not set
> # CONFIG_USB_CATC is not set
> # CONFIG_USB_CDCETHER is not set
> # CONFIG_USB_KAWETH is not set
> # CONFIG_USB_PEGASUS is not set
> # CONFIG_USB_RTL8150 is not set
> # CONFIG_USB_USBNET is not set
> # CONFIG_USB_USS720 is not set
>
> #
> # USB Serial Converter support
> #
> # CONFIG_USB_SERIAL is not set
> # CONFIG_USB_SERIAL_GENERIC is not set
> # CONFIG_USB_SERIAL_BELKIN is not set
> # CONFIG_USB_SERIAL_WHITEHEAT is not set
> # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
> # CONFIG_USB_SERIAL_EMPEG is not set
> # CONFIG_USB_SERIAL_FTDI_SIO is not set
> # CONFIG_USB_SERIAL_VISOR is not set
> # CONFIG_USB_SERIAL_IPAQ is not set
> # CONFIG_USB_SERIAL_IR is not set
> # CONFIG_USB_SERIAL_EDGEPORT is not set
> # CONFIG_USB_SERIAL_EDGEPORT_TI is not set
> # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
> # CONFIG_USB_SERIAL_KEYSPAN is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA19QW is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA19QI is not set
> # CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set
> # CONFIG_USB_SERIAL_KLSI is not set
> # CONFIG_USB_SERIAL_MCT_U232 is not set
> # CONFIG_USB_SERIAL_PL2303 is not set
> # CONFIG_USB_SERIAL_SAFE is not set
> # CONFIG_USB_SERIAL_SAFE_PADDED is not set
> # CONFIG_USB_SERIAL_CYBERJACK is not set
> # CONFIG_USB_SERIAL_XIRCOM is not set
> # CONFIG_USB_SERIAL_OMNINET is not set
> # CONFIG_USB_EMI26 is not set
> # CONFIG_USB_TIGL is not set
> # CONFIG_USB_AUERSWALD is not set
> # CONFIG_USB_RIO500 is not set
> # CONFIG_USB_BRLVGER is not set
> # CONFIG_USB_LCD is not set
> # CONFIG_USB_SPEEDTOUCH is not set
> # CONFIG_USB_TEST is not set
>
> #
> # Bluetooth support
> #
> # CONFIG_BT is not set
>
> #
> # Profiling support
> #
> # CONFIG_PROFILING is not set
>
> #
> # Kernel hacking
> #
> # CONFIG_SOFTWARE_SUSPEND is not set
> CONFIG_DEBUG_KERNEL=y
> # CONFIG_DEBUG_STACKOVERFLOW is not set
> CONFIG_DEBUG_SLAB=y
> # CONFIG_DEBUG_IOVIRT is not set
> CONFIG_MAGIC_SYSRQ=y
> # CONFIG_DEBUG_SPINLOCK is not set
> CONFIG_KALLSYMS=y
>
> #
> # Security options
> #
> CONFIG_SECURITY_CAPABILITIES=y
>
> #
> # Library routines
> #
> # CONFIG_CRC32 is not set
> # CONFIG_ZLIB_INFLATE is not set
> # CONFIG_ZLIB_DEFLATE is not set
> CONFIG_X86_BIOS_REBOOT=y
>
Regards
Andreas
--
Andreas Tscharner starfire@dplanet.ch
----------------------------------------------------------------------
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning."
-- Rich Cook
^ permalink raw reply [relevance 82%]
* Re: [BUG] USB Kernel bug in 2.5.45
2002-11-02 23:10 82% ` Jochen Friedrich
@ 2002-11-02 23:24 82% ` Greg KH
0 siblings, 0 replies; 200+ results
From: Greg KH @ 2002-11-02 23:24 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Linux Kernel
On Sun, Nov 03, 2002 at 12:10:43AM +0100, Jochen Friedrich wrote:
> Hi Greg,
>
> > If you disable devfs does it work ok?
>
> Yes, it does...
Great, thanks for trying. I don't see any more problems here :)
thanks,
greg k-h
^ permalink raw reply [relevance 82%]
* Re: [BUG] USB Kernel bug in 2.5.45
2002-11-02 20:44 82% ` Greg KH
@ 2002-11-02 23:10 82% ` Jochen Friedrich
2002-11-02 23:24 82% ` Greg KH
0 siblings, 1 reply; 200+ results
From: Jochen Friedrich @ 2002-11-02 23:10 UTC (permalink / raw)
To: Greg KH; +Cc: Linux Kernel
Hi Greg,
> If you disable devfs does it work ok?
Yes, it does...
drivers/usb/core/usb.c: deregistering driver hiddev
drivers/usb/core/usb.c: deregistering driver hid
and the module is gone.
--jochen
^ permalink raw reply [relevance 82%]
* Re: [BUG] USB Kernel bug in 2.5.45
@ 2002-11-02 20:44 82% ` Greg KH
2002-11-02 23:10 82% ` Jochen Friedrich
0 siblings, 1 reply; 200+ results
From: Greg KH @ 2002-11-02 20:44 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Linux Kernel
On Sat, Nov 02, 2002 at 07:37:55PM +0100, Jochen Friedrich wrote:
> Hi,
>
> when running "rmmod hid" while a USB HID device is still connected (but
> not used), i get this Oops messages:
>
> drivers/usb/core/usb.c: deregistering driver hiddev
> drivers/usb/core/usb.c: deregistering driver hid
> devfs_put(fffffc0009393000): poisoned pointer
If you disable devfs does it work ok?
thanks,
greg k-h
^ permalink raw reply [relevance 82%]
* Re: [BUG] yet another icmp reply transition bug
2002-10-31 9:13 82% ` Harald Welte
@ 2002-10-31 9:49 82% ` Balazs Scheidler
0 siblings, 0 replies; 200+ results
From: Balazs Scheidler @ 2002-10-31 9:49 UTC (permalink / raw)
To: Harald Welte; +Cc: Netfilter Development Mailinglist
On Thu, Oct 31, 2002 at 10:13:29AM +0100, Harald Welte wrote:
> On Wed, Oct 30, 2002 at 07:44:58PM +0100, Balazs Scheidler wrote:
>
> > This is exactly the problem I have posted several times now. (I found it
> > during my tproxy development). I have modified ICMP nat so that the inner
> > packet is translated at the same time the outer packet is. I saw no real
> > reasons to NAT ICMP packets in two phases (other than simmetricity).
>
> Mh. Somehow I never really understdood the implications and the significance
> of your findings. I'm sorry for my ignorance.
no problem.
>
> > When fixing the problem I came up with two solutions:
> >
> > 1) fix opposite_hook, and allow many possible points of inner header
> > translation (e.g. a manip in PREROUTING may mean ICMP reply in
> > POSTROUTING _or_ LOCAL_IN _or_ LOCAL_OUT)
>
> This was my initial idea as well. But it becomes horribly complex and
> looks more like a hack - the kind of code where you need more comments
> than code in order to make it half-way understandable :(
that's what I meant on 'not robust' ;)
>
> > 2) as the first one doesn't seem too robust to me, I fixed the translation
> > and did the whole thing in one step. The inner header is translated at
> > the same time the outer header is translated. I have seen no real use in
> > having the inconsistent (translated outer, and untranslated inner header)
> > packet traverse the IP stack.
>
> This sounds reasonable. The question is: Do we ever have a case where we
> cannot translate both, but still want the packet to be passed on? But
> in case of uncertainty, passing less information is preferred than yet another
> information leak (about internal addresses, ...).
The same manip is applied to both the inner and outer headers. So I think
there's no case when we don't know what to do. (once we have that single
manip)
conntrack happens prior to NAT, so the icmp packet is already taken as
related to a session, conntracking will not be affected.
The only possible problem I see is packet confirmation (a quick look shows
that it doesn't care about ICMP though)
PS: I've been running with this fix applied for ages now, and I saw no
problems.
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
^ permalink raw reply [relevance 82%]
* Re: [BUG] yet another icmp reply transition bug
@ 2002-10-31 9:13 82% ` Harald Welte
2002-10-31 9:49 82% ` Balazs Scheidler
0 siblings, 1 reply; 200+ results
From: Harald Welte @ 2002-10-31 9:13 UTC (permalink / raw)
To: Balazs Scheidler; +Cc: Netfilter Development Mailinglist
[-- Attachment #1: Type: text/plain, Size: 2062 bytes --]
On Wed, Oct 30, 2002 at 07:44:58PM +0100, Balazs Scheidler wrote:
> This is exactly the problem I have posted several times now. (I found it
> during my tproxy development). I have modified ICMP nat so that the inner
> packet is translated at the same time the outer packet is. I saw no real
> reasons to NAT ICMP packets in two phases (other than simmetricity).
Mh. Somehow I never really understdood the implications and the significance
of your findings. I'm sorry for my ignorance.
> When fixing the problem I came up with two solutions:
>
> 1) fix opposite_hook, and allow many possible points of inner header
> translation (e.g. a manip in PREROUTING may mean ICMP reply in
> POSTROUTING _or_ LOCAL_IN _or_ LOCAL_OUT)
This was my initial idea as well. But it becomes horribly complex and
looks more like a hack - the kind of code where you need more comments
than code in order to make it half-way understandable :(
> 2) as the first one doesn't seem too robust to me, I fixed the translation
> and did the whole thing in one step. The inner header is translated at
> the same time the outer header is translated. I have seen no real use in
> having the inconsistent (translated outer, and untranslated inner header)
> packet traverse the IP stack.
This sounds reasonable. The question is: Do we ever have a case where we
cannot translate both, but still want the packet to be passed on? But
in case of uncertainty, passing less information is preferred than yet another
information leak (about internal addresses, ...).
> I've posted my fix several times, I'll post it again if you like.
I'll pick it from the archives, thanks.
Expect more comments soon.
> Bazsi
--
Live long and prosper
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [relevance 82%]
* Re: fork bug [WAS: Re: "mount" bug]
2002-10-27 12:57 82% ` fork bug [WAS: Re: "mount" bug] jb1
@ 2002-10-27 19:49 82% ` Harry Kalogirou
0 siblings, 0 replies; 200+ results
From: Harry Kalogirou @ 2002-10-27 19:49 UTC (permalink / raw)
To: jb1; +Cc: Linux-8086
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
> On 26 Oct 2002, Harry Kalogirou wrote:
>
> > "Cannot fork" is emmited by the shell, when the fork() system call
> > fails. The system call will fail :
> >
> > 1) If there are no more process slots available.
> > 2) There is not enough free memory.
> >
> > What exacly happend there, I realy can't tell. The only thing I can tell
> > is that something "very" bad happed there. I personaly havedn't seen
> > ELKS behave like that before.
>
> There appears to be a bug in the "get_pid()" function from fork.c. The
> code fragment:
> if (++last_pid == 32768)
> last_pid = 1;
> must eventually fail because last_pid is declared as type pid_t, which is
> typedef'ed as __s16, which is in turn typedef'ed as signed short int.
> Since signed 16-bit numbers roll over from 32767 to negative numbers, they
> can never equal 32768. A possible fix might be:
> if ( (++last_pid && 0x7fff) == 0 )
> last_pid = 1;
> or, perhaps smaller and faster:
> if !( (last_pid++) &= 0x7fff )
> last_pid++;
> The latter may have superfluous parentheses because I'm not sure of the
> precedence, and whether "variable++" is smaller and faster than
> "++variable" is probably compiler-dependent.
>
Commited...
Harry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [relevance 82%]
* fork bug [WAS: Re: "mount" bug]
@ 2002-10-27 12:57 82% ` jb1
2002-10-27 19:49 82% ` Harry Kalogirou
0 siblings, 1 reply; 200+ results
From: jb1 @ 2002-10-27 12:57 UTC (permalink / raw)
To: Harry Kalogirou; +Cc: Linux-8086
On 26 Oct 2002, Harry Kalogirou wrote:
> "Cannot fork" is emmited by the shell, when the fork() system call
> fails. The system call will fail :
>
> 1) If there are no more process slots available.
> 2) There is not enough free memory.
>
> What exacly happend there, I realy can't tell. The only thing I can tell
> is that something "very" bad happed there. I personaly havedn't seen
> ELKS behave like that before.
There appears to be a bug in the "get_pid()" function from fork.c. The
code fragment:
if (++last_pid == 32768)
last_pid = 1;
must eventually fail because last_pid is declared as type pid_t, which is
typedef'ed as __s16, which is in turn typedef'ed as signed short int.
Since signed 16-bit numbers roll over from 32767 to negative numbers, they
can never equal 32768. A possible fix might be:
if ( (++last_pid && 0x7fff) == 0 )
last_pid = 1;
or, perhaps smaller and faster:
if !( (last_pid++) &= 0x7fff )
last_pid++;
The latter may have superfluous parentheses because I'm not sure of the
precedence, and whether "variable++" is smaller and faster than
"++variable" is probably compiler-dependent.
^ permalink raw reply [relevance 82%]
* Re: Yay, bug tracking! (was Re: Bug tracking in the run up from 2.5 to 2.6)
2002-10-22 9:37 82% ` Jeff Garzik
@ 2002-10-24 18:34 82% ` Cliff White
0 siblings, 0 replies; 200+ results
From: Cliff White @ 2002-10-24 18:34 UTC (permalink / raw)
To: Jeff Garzik
Cc: Alan Cox, Martin J. Bligh, Rik van Riel,
Linux Kernel Mailing List, cliffw
> Alan Cox wrote:
> > Bug reporting systems need maintenance or they collapse
>
> Agreed, and IBM said that they would provide people doing this...
> otherwise I would not have been so enthusiastic :)
>
OSDL is very interested in linking this with the PLM - since the
PLM is doing automated kernel builds with multiple .configs, we can
harvest build bugs from there. I am also willing to help with some of the
maintenance and sorting work.
Martin, i left you a message.
cliffw
> -
> 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 [relevance 82%]
* Re: Yay, bug tracking! (was Re: Bug tracking in the run up from 2.5 to 2.6)
2002-10-22 9:49 82% ` Alan Cox
@ 2002-10-22 9:37 82% ` Jeff Garzik
2002-10-24 18:34 82% ` Cliff White
0 siblings, 1 reply; 200+ results
From: Jeff Garzik @ 2002-10-22 9:37 UTC (permalink / raw)
To: Alan Cox; +Cc: Martin J. Bligh, Rik van Riel, Linux Kernel Mailing List
Alan Cox wrote:
> Bug reporting systems need maintenance or they collapse
Agreed, and IBM said that they would provide people doing this...
otherwise I would not have been so enthusiastic :)
^ permalink raw reply [relevance 82%]
* Re: Yay, bug tracking! (was Re: Bug tracking in the run up from 2.5 to 2.6)
2002-10-22 1:43 82% ` Martin J. Bligh
@ 2002-10-22 9:49 82% ` Alan Cox
2002-10-22 9:37 82% ` Jeff Garzik
0 siblings, 1 reply; 200+ results
From: Alan Cox @ 2002-10-22 9:49 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Rik van Riel, Jeff Garzik, Linux Kernel Mailing List
On Tue, 2002-10-22 at 02:43, Martin J. Bligh wrote:
> > Count me in as a participant. One thing that would be nice is
> > a mailing list where the bugs (and the changes to bugs) get
> > mailed, so we can get updates by email.
>
> Bugzilla has email triggers, so this should be dead easy to do.
> Not sure if we need a list - bugzilla should be able to keep
> each people's "watching" criteria itself. If it turns out lists
> are easier, that should be easy to fix.
>
> > I'll help track down, fix and admin bugs.
>
> Thanks (to both of you ;-))!
>From some good and bad experiences in the desktop universe - you need
people who are willing to collate bugs, sort them, tidy duplicates,
identify the most common bug report etc. Without that it doesn't work.
Watching what Luis did to the gnome bug reporting has been an education
but I don't think he can be cloned trivially and I don't think we could
run off with him 8)
Bug reporting systems need maintenance or they collapse
^ permalink raw reply [relevance 82%]
* Re: Yay, bug tracking! (was Re: Bug tracking in the run up from 2.5 to 2.6)
2002-10-22 1:40 82% ` Rik van Riel
@ 2002-10-22 1:43 82% ` Martin J. Bligh
2002-10-22 9:49 82% ` Alan Cox
0 siblings, 1 reply; 200+ results
From: Martin J. Bligh @ 2002-10-22 1:43 UTC (permalink / raw)
To: Rik van Riel, Jeff Garzik; +Cc: linux-kernel
> Count me in as a participant. One thing that would be nice is
> a mailing list where the bugs (and the changes to bugs) get
> mailed, so we can get updates by email.
Bugzilla has email triggers, so this should be dead easy to do.
Not sure if we need a list - bugzilla should be able to keep
each people's "watching" criteria itself. If it turns out lists
are easier, that should be easy to fix.
> I'll help track down, fix and admin bugs.
Thanks (to both of you ;-))!
M.
^ permalink raw reply [relevance 82%]
* Re: Yay, bug tracking! (was Re: Bug tracking in the run up from 2.5 to 2.6)
@ 2002-10-22 1:40 82% ` Rik van Riel
2002-10-22 1:43 82% ` Martin J. Bligh
0 siblings, 1 reply; 200+ results
From: Rik van Riel @ 2002-10-22 1:40 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Martin J. Bligh, linux-kernel
On Mon, 21 Oct 2002, Jeff Garzik wrote:
> Martin J. Bligh wrote:
> > We're proposing to create a bug tracking system to help keep track of
> > 2.5 kernel bugs ... in an attempt to help get 2.5 stabilised as quickly as
> > possible.
>
> This is fantastic.
<AOL/>
Count me in as a participant. One thing that would be nice is
a mailing list where the bugs (and the changes to bugs) get
mailed, so we can get updates by email.
I'll help track down, fix and admin bugs.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a>
^ permalink raw reply [relevance 82%]
* Re: [BUG] raw over raid5: BUG at drivers/block/ll_rw_blk.c:1967
@ 2002-10-15 6:41 82% ` Neil Brown
2002-10-14 20:49 82% ` Andrew Morton
1 sibling, 0 replies; 200+ results
From: Neil Brown @ 2002-10-15 6:41 UTC (permalink / raw)
To: David Mansfield; +Cc: linux-kernel
On Monday October 14, lkml@dm.cobite.com wrote:
>
> Hi everyone,
>
> I haven't been able to run raw over raid5 since 2.5.30 or so, but every
> time I'm about to report it, a new kernel comes out and the problem
> changes completely :-( Now I'm finally going to start getting out the info
> it the hopes someone can fix it. The oops was triggered by attempting to
> read from /dev/raw/raw1 (bound to /dev/md0) using dd. System info
> follows oops:
>
> ------------[ cut here ]------------
> kernel BUG at drivers/block/ll_rw_blk.c:1967!
> invalid operand: 0000
>
You are not alone in reporting this BUG...
I blame the Scsi/bio layer.
Jens Axboe blames raid5.
:-)
Hopefully we will find it one place or the other.
The other report didn't use raw to get the bug, but if using raw makes
it reproducable, I will try that and see if I can reproduce it easily.
NeilBrown
^ permalink raw reply [relevance 82%]
* Re: [BUG] raw over raid5: BUG at drivers/block/ll_rw_blk.c:1967
2002-10-14 20:49 82% ` Andrew Morton
2002-10-14 21:57 82% ` David Mansfield
@ 2002-10-14 22:18 82% ` David Mansfield
1 sibling, 0 replies; 200+ results
From: David Mansfield @ 2002-10-14 22:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Mon, 14 Oct 2002, Andrew Morton wrote:
> David Mansfield wrote:
> > ------------[ cut here ]------------
> > kernel BUG at drivers/block/ll_rw_blk.c:1967!
>
> I don't think you told us the kernel version?
>
> There have been recent fixes wrt sizing of the BIOs which the
> direct-io layer sends down. So please make sure that you're
> testing Linus's current -bk, or 2.5.42 plus
>
I've tried to test 2.5.42-mm2 but it doesn't compile. There were (I
assume 'sard') changes made to remove the DK_MAX_MAJOR etc. but there is
to patch to drivers/md/md.c so it fails to compile:
# find -name \*.c | xargs grep DK_MAX_MAJOR
./drivers/md/md.c:static unsigned int sync_io[DK_MAX_MAJOR][DK_MAX_DISK];
./drivers/md/md.c: if ((index >= DK_MAX_DISK) || (major >=
DK_MAX_MAJOR))
./drivers/md/md.c: if ((idx >= DK_MAX_DISK) || (major >=
DK_MAX_MAJOR))
David
--
/==============================\
| David Mansfield |
| david@cobite.com |
\==============================/
^ permalink raw reply [relevance 82%]
* Re: [BUG] raw over raid5: BUG at drivers/block/ll_rw_blk.c:1967
2002-10-14 20:49 82% ` Andrew Morton
@ 2002-10-14 21:57 82% ` David Mansfield
2002-10-14 22:18 82% ` David Mansfield
1 sibling, 0 replies; 200+ results
From: David Mansfield @ 2002-10-14 21:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Mon, 14 Oct 2002, Andrew Morton wrote:
> David Mansfield wrote:
> >
> > Hi everyone,
> >
> > I haven't been able to run raw over raid5 since 2.5.30 or so, but every
> > time I'm about to report it, a new kernel comes out and the problem
> > changes completely :-( Now I'm finally going to start getting out the info
> > it the hopes someone can fix it. The oops was triggered by attempting to
> > read from /dev/raw/raw1 (bound to /dev/md0) using dd. System info
> > follows oops:
> >
> > ------------[ cut here ]------------
> > kernel BUG at drivers/block/ll_rw_blk.c:1967!
>
> I don't think you told us the kernel version?
Arrgh. It was 2.5.42 vanilla.
> There have been recent fixes wrt sizing of the BIOs which the
> direct-io layer sends down. So please make sure that you're
> testing Linus's current -bk, or 2.5.42 plus
>
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.42/2.5.42-mm2/broken-out/dio-bio-add-fix-1.patch
I've applied this patch and retested. I was able to run dd once this
time, hit ctrl-c, all ok. But I hit up-arrow and re-did it and it gave
the same oops. I'm going to try with the full (latest) mm patch.
> Either that, or raid5 is bust ;)
>
I guess so.
David
--
/==============================\
| David Mansfield |
| lkml@dm.cobite.com |
\==============================/
^ permalink raw reply [relevance 82%]
* Re: [BUG] Compile failure (gcc 2.96 bug?). 2.5.42 raid0.c
2002-10-14 20:54 82% ` Arjan van de Ven
@ 2002-10-14 21:11 82% ` Arjan van de Ven
0 siblings, 0 replies; 200+ results
From: Arjan van de Ven @ 2002-10-14 21:11 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: David Mansfield, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
On Mon, 2002-10-14 at 22:54, Arjan van de Ven wrote:
> On Mon, 2002-10-14 at 22:27, David Mansfield wrote:
> >
> > - sector_t x = block;
> > + volatile sector_t y = 0;
> > + sector_t x = block - y;
> > sector_div(x, (unsigned long)conf->smallest->size);
> > hash = conf->hash_table + x;
> > }
> this appears to be a bad code bug; do_div() requires the first argument
> to be an u64 and we cast it to unsigned long here....
ehm ignore me I'm blind
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [relevance 82%]
* Re: [BUG] Compile failure (gcc 2.96 bug?). 2.5.42 raid0.c
@ 2002-10-14 20:54 82% ` Arjan van de Ven
2002-10-14 21:11 82% ` Arjan van de Ven
0 siblings, 1 reply; 200+ results
From: Arjan van de Ven @ 2002-10-14 20:54 UTC (permalink / raw)
To: David Mansfield; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
On Mon, 2002-10-14 at 22:27, David Mansfield wrote:
>
> - sector_t x = block;
> + volatile sector_t y = 0;
> + sector_t x = block - y;
> sector_div(x, (unsigned long)conf->smallest->size);
> hash = conf->hash_table + x;
> }
this appears to be a bad code bug; do_div() requires the first argument
to be an u64 and we cast it to unsigned long here....
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [relevance 82%]
* Re: [BUG] raw over raid5: BUG at drivers/block/ll_rw_blk.c:1967
2002-10-15 6:41 82% ` Neil Brown
@ 2002-10-14 20:49 82% ` Andrew Morton
2002-10-14 21:57 82% ` David Mansfield
2002-10-14 22:18 82% ` David Mansfield
1 sibling, 2 replies; 200+ results
From: Andrew Morton @ 2002-10-14 20:49 UTC (permalink / raw)
To: David Mansfield; +Cc: linux-kernel
David Mansfield wrote:
>
> Hi everyone,
>
> I haven't been able to run raw over raid5 since 2.5.30 or so, but every
> time I'm about to report it, a new kernel comes out and the problem
> changes completely :-( Now I'm finally going to start getting out the info
> it the hopes someone can fix it. The oops was triggered by attempting to
> read from /dev/raw/raw1 (bound to /dev/md0) using dd. System info
> follows oops:
>
> ------------[ cut here ]------------
> kernel BUG at drivers/block/ll_rw_blk.c:1967!
I don't think you told us the kernel version?
There have been recent fixes wrt sizing of the BIOs which the
direct-io layer sends down. So please make sure that you're
testing Linus's current -bk, or 2.5.42 plus
http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.42/2.5.42-mm2/broken-out/dio-bio-add-fix-1.patch
Either that, or raid5 is bust ;)
^ permalink raw reply [relevance 82%]
* :Re: Bug on Mdk 9.0
@ 2002-10-12 19:28 82% Hell.Surfers
0 siblings, 0 replies; 200+ results
From: Hell.Surfers @ 2002-10-12 19:28 UTC (permalink / raw)
To: jbradford, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 114 bytes --]
dont flame me bi@tch. :)
Cheers, Dean.
On Sat, 12 Oct 2002 20:30:01 +0100 (BST) jbradford@dial.pipex.com wrote:
[-- Attachment #2: Type: message/rfc822, Size: 902 bytes --]
From: jbradford@dial.pipex.com
To: Hell.Surfers@cwctv.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: Bug on Mdk 9.0
Date: Sat, 12 Oct 2002 20:30:01 +0100 (BST)
Message-ID: <200210121930.g9CJU1Co011425@darkstar.example.net>
> wood u stop tawkin 733t m8.
Y d0n7 U 570p u5!n 5u(h @ 1337 3-M@!7 @pp71(@7!0n, wh!(h d035n'7 3v3n
qu073 pr0p3r7y :-)
John.
^ permalink raw reply [relevance 82%]
* Re: BUG: 2.5.41 left raid array to unclean mode (Kernel bug at raid1.c:667)
[not found] <15778.27247.271665.487076@notabene.cse.unsw.edu.au>
@ 2002-10-08 15:09 82% ` Jani Averbach
0 siblings, 0 replies; 200+ results
From: Jani Averbach @ 2002-10-08 15:09 UTC (permalink / raw)
To: Neil Brown; +Cc: mingo, linux-raid
On Tue, 8 Oct 2002, Neil Brown wrote:
> Just remove the first instance of:
>
> return NOTIFY_DONE;
>
> from drivers/md/md.c
>
Done that, and so far it seems to work ok.
Thanks,
Jani
--
Jani Averbach
^ permalink raw reply [relevance 82%]
* BUG: 2.5.41 left raid array to unclean mode (Kernel bug at raid1.c:667)
@ 2002-10-07 23:49 82% Jani Averbach
0 siblings, 0 replies; 200+ results
From: Jani Averbach @ 2002-10-07 23:49 UTC (permalink / raw)
To: mingo, neilb; +Cc: linux-raid
Hello,
(Resending this, orig was 2002-03-10)
[1.] One line summary of the problem:
Shutdown left (always) software raid array in unclean mode, next shutdown
(during reconstructing) will cause kernel bug.
[2.] Full description of the problem/report:
With 2.5.6 (and 2.5.6-pre1 at least) shutdown procedure left raid
array in unclean state. Next time when machine is going down (during
reconstruction) there will be kernel bug in the raid1.c:656. This is
completely reproductable.
If you run shutdown after reconstruction has been finished, there is no
problem. However raid array is again left in unclean mode.
...
This is still the case with kernel 2.5.41.
Please see details from here:
http://marc.theaimsgroup.com/?l=linux-raid&m=101576857227286&w=2
It would be really nice if this one get nailed down. I would like to test
2.5.x again, but at the moment it is a bit no go.
Thanks for the hacking kernel!
BR, Jani
--
Jani Averbach
^ permalink raw reply [relevance 82%]
* Wildcards matching ".": exports bug or just documentation bug?
@ 2002-10-04 11:57 82% Stephen C. Tweedie
2002-11-13 13:55 82% ` Stephen C. Tweedie
0 siblings, 1 reply; 200+ results
From: Stephen C. Tweedie @ 2002-10-04 11:57 UTC (permalink / raw)
To: nfs; +Cc: Stephen Tweedie, linux-fsdevel
Hi,
mountd treats wildcards in hostnames in the exports file as matching
anything, including ".".
However, the exports man page explicitly states that "*" and "?" do not
match ".":
Machine names may contain the wildcard characters * and ?. This can
be used to make the exports file more compact; for instance,
*.cs.foo.edu matches all hosts in the domain cs.foo.edu. However,
these wildcard characters do not match the dots in a domain name, so
the above pattern does not include hosts such as a.b.cs.foo.edu.
So, which is right, the actual behaviour or the documented behaviour?
I'd tend to lean towards the former.
--Stephen
^ permalink raw reply [relevance 82%]
* RE: [Linux-ia64] glibc bug / pthread bug???
@ 2002-10-01 21:28 82% ` Boehm, Hans
0 siblings, 0 replies; 200+ results
From: Boehm, Hans @ 2002-10-01 21:28 UTC (permalink / raw)
To: linux-ia64
It's probably a feature. The test program is incorrect. However, this does seem to be a rather common bug, and a particularly nasty corner of the pthreads spec.
In a multithreaded application, you are only allowed to make async-signal-safe calls in the child. AFAIK, neither timer_create nor perror are async-signal-safe. Neither is exit().
This requirement makes some small amount of sense, since fork() creates a new address space containing only that thread. Locks that happened to be held by other threads at the time of the fork may be held in the child process, and thus any attempt to acquire a (system?) lock or the like may deadlock the child process. There may also be other linuxthreads specific issues, e.g. I'm not sure to what extent the manager thread is functional in the child.
Hans
> -----Original Message-----
> From: Jack Steiner [mailto:steiner@sgi.com]
> Sent: Tuesday, October 01, 2002 1:08 PM
> To: linux-ia64@linuxia64.org
> Subject: [Linux-ia64] glibc bug / pthread bug???
>
>
> Has anyone seen this problem or know enough about glibc/threads
> to have a good idea about what is busted.
>
>
> The test case listed below consistently hang using 2.4.18 &
> glibc-2.2.4-19.3.
>
> If only one instance (fork=1)of the test is run, it runs ok.
> If multiple copies
> of the test are run, it hangs in:
>
> * rt_sigsuspend
> * __sigsuspend
> * __pthread_wait_for_restart_signal
> * pthread_cond_wait
> * thread_func
> * pthread_start_thread
>
> Has anyone seen this???
>
> /*
> * compile with
> * gcc -g -Wall -o test test.c -lrt
> *
> * execute
> * test [<inner_loop_count> [<outer_loop_count>]]
> *
> *
> * Test creates timer threads that hang in
> * rt_sigsuspend
> * __sigsuspend
> * __pthread_wait_for_restart_signal
> * pthread_cond_wait
> * thread_func
> * pthread_start_thread
> *
> */
>
> #include <signal.h>
> #include <time.h>
> #include <stdio.h>
> #include <sys/types.h>
> #include <sys/time.h>
> #include <sys/times.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <sys/wait.h>
>
> int forks=5;
> int count=5;
>
> void *
> slave(void)
> {
> timer_t timerid;
> pid_t pid;
> int i, status;
>
> for (i=0; i<forks; i++) {
> if (fork() = 0) {
> if (timer_create(CLOCK_REALTIME,
> NULL, &timerid) = -1) {
> perror("timer_create");
> exit(1);
> }
> execlp("/bin/date", "date", (char *)0);
> }
>
> pid = wait(&status);
> }
>
> exit(0);
> }
>
> int
> main (int argc, char *argv[])
> {
> int i;
>
> count = argc >= 2 ? atoi(argv[1]) : 5;
> forks = argc >= 3 ? atoi(argv[2]) : 5;
>
> for (i=0; i<count; i++) {
> if (fork() = 0)
> slave();
> }
>
> exit(0);
> }
>
>
>
> --
> Thanks
>
> Jack Steiner (651-683-5302) (vnet 233-5302) steiner@sgi.com
>
>
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
>
^ permalink raw reply [relevance 82%]
* Re: [BUG/PATCH] : bug in tty_default_put_char()
@ 2002-08-28 23:16 82% ` Russell King
0 siblings, 0 replies; 200+ results
From: Russell King @ 2002-08-28 23:16 UTC (permalink / raw)
To: jt; +Cc: Linux kernel mailing list
On Wed, Aug 28, 2002 at 03:41:03PM -0700, Jean Tourrilhes wrote:
> Patch below allow to set "uart=none", which is necessary for
> FIR hardware. Patch for 2.5.31.
Ok, thanks.
> The write is comming from the PPP line discipline. If PPP
> can't transmit the data, it just drops it and assume higher layers
> will retry. This is true for TCP, but not for "chat".
Last time I read the pppd code, chat doesn't talk via the ppp code, but
via the serial device itself. I'm still confused about this report,
since it could mean something is very wrong somewhere and not knowing
where is really bugging me. I really don't like sleeping problems that
come back to bite later.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [relevance 82%]
* Re: [BUG/PATCH] : bug in tty_default_put_char()
2002-08-26 19:07 82% ` Alan Cox
@ 2002-08-26 20:17 82% ` Russell King
0 siblings, 0 replies; 200+ results
From: Russell King @ 2002-08-26 20:17 UTC (permalink / raw)
To: Alan Cox; +Cc: jt, Linux kernel mailing list
On Mon, Aug 26, 2002 at 08:07:27PM +0100, Alan Cox wrote:
> On Mon, 2002-08-26 at 19:59, Jean Tourrilhes wrote:
> > Just check drivers/char/n_tty.c for every occurence of
> > put_char() and be scared. The problem is to find a practical solution.
> > For myself, I've added some clever workaround in IrCOMM to
> > accept data before full setup.
>
> Sure making it return the right errors doesnt fix anything, but it
> allows you to fix some of it bit by bit.
put_char() is not allowed to fail since the caller should have already
checked for buffer space via the write_room() method.
All places look adequately protected in n_tty.c, so I'm not currently
sure how Jean's users are seeing this condition; I'd need to have a
BUG() showing the call trace of such an event happening.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [relevance 82%]
* Re: [BUG/PATCH] : bug in tty_default_put_char()
@ 2002-08-26 19:31 82% ` Russell King
[not found] ` <20020826195346.GC8749@bougret.hpl.hp.com>
[not found] ` <1030388224.2797.2.camel@irongate.swansea.linux.org.uk>
1 sibling, 1 reply; 200+ results
From: Russell King @ 2002-08-26 19:31 UTC (permalink / raw)
To: jt; +Cc: Linux kernel mailing list, Alan Cox, tytso, Andrew Morton,
irda-users
On Mon, Aug 26, 2002 at 11:07:49AM -0700, Jean Tourrilhes wrote:
> Bug : tty_default_put_char() doesn't check the return value of
> tty->driver.write(). However, the later may fail if buffers are full.
Hmm.
> Solution : It's not obvious what should be done. The attached
> patch is certainly wrong, but gives you an idea of what the problem
> is.
Every invocation of the put_char() method should be preceded by a check
to ensure that there is sufficient space in the drivers buffer (via the
drivers write_room() call.) Could you add a BUG() on this condition
and get some call traces please?
> I'll try to workaround that in IrCOMM.
I don't think that should be necessary. The tty layer is obviously
doing something it shouldn't (trying to stuff characters into a buffer
of zero size) so it should get fixed.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [relevance 82%]
* Re: [BUG/PATCH] : bug in tty_default_put_char()
2002-08-26 18:59 82% ` Jean Tourrilhes
@ 2002-08-26 19:07 82% ` Alan Cox
2002-08-26 20:17 82% ` Russell King
0 siblings, 1 reply; 200+ results
From: Alan Cox @ 2002-08-26 19:07 UTC (permalink / raw)
To: jt; +Cc: Linux kernel mailing list
On Mon, 2002-08-26 at 19:59, Jean Tourrilhes wrote:
> Just check drivers/char/n_tty.c for every occurence of
> put_char() and be scared. The problem is to find a practical solution.
> For myself, I've added some clever workaround in IrCOMM to
> accept data before full setup.
Sure making it return the right errors doesnt fix anything, but it
allows you to fix some of it bit by bit.
^ permalink raw reply [relevance 82%]
* Re: [BUG/PATCH] : bug in tty_default_put_char()
[not found] ` <1030388224.2797.2.camel@irongate.swansea.linux.org.uk>
@ 2002-08-26 18:59 82% ` Jean Tourrilhes
2002-08-26 19:07 82% ` Alan Cox
0 siblings, 1 reply; 200+ results
From: Jean Tourrilhes @ 2002-08-26 18:59 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux kernel mailing list
On Mon, Aug 26, 2002 at 07:57:04PM +0100, Alan Cox wrote:
> On Mon, 2002-08-26 at 19:07, Jean Tourrilhes wrote:
> > Hi,
> >
> > Bug : tty_default_put_char() doesn't check the return value of
> > tty->driver.write(). However, the later may fail if buffers are full.
> >
> > Solution : It's not obvious what should be done. The attached
> > patch is certainly wrong, but gives you an idea of what the problem
> > is.
>
> Make it an int and return the tty->driver.write value. We know that
> since its void nobody is currently checking the error code, and now they
> can where it matters
Just check drivers/char/n_tty.c for every occurence of
put_char() and be scared. The problem is to find a practical solution.
For myself, I've added some clever workaround in IrCOMM to
accept data before full setup.
Regards,
Jean
^ permalink raw reply [relevance 82%]
* Re: [2.4 BUFFERING BUG] (was [BUG] 2.4 VM sucks. Again)
2002-07-10 8:05 82% ` Andrew Morton
@ 2002-07-10 8:14 82% ` Roy Sigurd Karlsbakk
0 siblings, 0 replies; 200+ results
From: Roy Sigurd Karlsbakk @ 2002-07-10 8:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: Martin J. Bligh, linux-kernel
On Wednesday 10 July 2002 10:05, Andrew Morton wrote:
> Roy Sigurd Karlsbakk wrote:
> > hi
> >
> > I've been using the patch below from Andrew for some weeks now, sometimes
> > under quite heavy load, and find it quite stable.
>
> Wish we knew why. I've tried many times to reproduce the problem
> which you're seeing. With just two gigs of memory, buffer_heads
> really cannot explain anything. It's weird.
well - firstly, I'm using _1_ gig of memory - highmem (= 900 megs something)
secondly - I have reproduced it on two different installations, although on
the same hardware - standard PC with SiS MB and an extra promise controller,
RAID-0 on 4 drives and chunksize 1MB. Given a 30-50 processes each reading a
4gig file and sending it over HTTP, everything works fine _if_ and only _if_
the client reads at high speed. If, however, the client reads at normal
streaming speed (4,3Mbps), buffers go bOOM.
> We discussed this in Ottawa - I guess Andrea will add the toss-the-buffers
> code on the read side (basically the filemap.c stuff). That may
> be sufficient, but without an understanding of what is going on,
> it is hard to predict.
Is there _any_ more data I can give, or any more testing I can do, then I'll
do my very best to help
roy
--
Roy Sigurd Karlsbakk, Datavaktmester
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply [relevance 82%]
* Re: [2.4 BUFFERING BUG] (was [BUG] 2.4 VM sucks. Again)
2002-07-10 7:50 82% ` [2.4 BUFFERING BUG] (was [BUG] 2.4 VM sucks. Again) Roy Sigurd Karlsbakk
@ 2002-07-10 8:05 82% ` Andrew Morton
2002-07-10 8:14 82% ` Roy Sigurd Karlsbakk
0 siblings, 1 reply; 200+ results
From: Andrew Morton @ 2002-07-10 8:05 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk; +Cc: Martin J. Bligh, linux-kernel
Roy Sigurd Karlsbakk wrote:
>
> hi
>
> I've been using the patch below from Andrew for some weeks now, sometimes
> under quite heavy load, and find it quite stable.
>
Wish we knew why. I've tried many times to reproduce the problem
which you're seeing. With just two gigs of memory, buffer_heads
really cannot explain anything. It's weird.
We discussed this in Ottawa - I guess Andrea will add the toss-the-buffers
code on the read side (basically the filemap.c stuff). That may
be sufficient, but without an understanding of what is going on,
it is hard to predict.
-
^ permalink raw reply [relevance 82%]
* [2.4 BUFFERING BUG] (was [BUG] 2.4 VM sucks. Again)
@ 2002-07-10 7:50 82% ` Roy Sigurd Karlsbakk
2002-07-10 8:05 82% ` Andrew Morton
0 siblings, 1 reply; 200+ results
From: Roy Sigurd Karlsbakk @ 2002-07-10 7:50 UTC (permalink / raw)
To: Andrew Morton, Martin J. Bligh; +Cc: linux-kernel
hi
I've been using the patch below from Andrew for some weeks now, sometimes
under quite heavy load, and find it quite stable.
Just wanted to say ...
roy
> > I don't think Andrew is ready to submit this yet ... before anything
> > gets merged back, it'd be very worthwhile testing the relative
> > performance of both solutions ... the more testers we have the
> > better ;-)
>
> Cripes no. It's pretty experimental. Andrea spotted a bug, too. Fixed
> version is below.
>
> It's possible that keeping the number of buffers as low as possible
> will give improved performance over Andrea's approach because it
> leaves more ZONE_NORMAL for other things. It's also possible that
> it'll give worse performance because more get_block's need to be
> done for file overwriting.
>
>
> --- 2.4.19-pre8/include/linux/pagemap.h~nuke-buffers Fri May 24 12:24:56
> 2002 +++ 2.4.19-pre8-akpm/include/linux/pagemap.h Fri May 24 12:26:30 2002
> @@ -89,13 +89,7 @@ extern void add_to_page_cache(struct pag
> extern void add_to_page_cache_locked(struct page * page, struct
> address_space *mapping, unsigned long index); extern int
> add_to_page_cache_unique(struct page * page, struct address_space *mapping,
> unsigned long index, struct page **hash);
>
> -extern void ___wait_on_page(struct page *);
> -
> -static inline void wait_on_page(struct page * page)
> -{
> - if (PageLocked(page))
> - ___wait_on_page(page);
> -}
> +extern void wait_on_page(struct page *);
>
> extern struct page * grab_cache_page (struct address_space *, unsigned
> long); extern struct page * grab_cache_page_nowait (struct address_space *,
> unsigned long); --- 2.4.19-pre8/mm/filemap.c~nuke-buffers Fri May 24
> 12:24:56 2002 +++ 2.4.19-pre8-akpm/mm/filemap.c Fri May 24 12:24:56 2002
> @@ -608,7 +608,7 @@ int filemap_fdatawait(struct address_spa
> page_cache_get(page);
> spin_unlock(&pagecache_lock);
>
> - ___wait_on_page(page);
> + wait_on_page(page);
> if (PageError(page))
> ret = -EIO;
>
> @@ -805,33 +805,29 @@ static inline wait_queue_head_t *page_wa
> return &wait[hash];
> }
>
> -/*
> - * Wait for a page to get unlocked.
> +static void kill_buffers(struct page *page)
> +{
> + if (!PageLocked(page))
> + BUG();
> + if (page->buffers)
> + try_to_release_page(page, GFP_NOIO);
> +}
> +
> +/*
> + * Wait for a page to come unlocked. Then try to ditch its buffer_heads.
> *
> - * This must be called with the caller "holding" the page,
> - * ie with increased "page->count" so that the page won't
> - * go away during the wait..
> + * FIXME: Make the ditching dependent on CONFIG_MONSTER_BOX or something.
> */
> -void ___wait_on_page(struct page *page)
> +void wait_on_page(struct page *page)
> {
> - wait_queue_head_t *waitqueue = page_waitqueue(page);
> - struct task_struct *tsk = current;
> - DECLARE_WAITQUEUE(wait, tsk);
> -
> - add_wait_queue(waitqueue, &wait);
> - do {
> - set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> - if (!PageLocked(page))
> - break;
> - sync_page(page);
> - schedule();
> - } while (PageLocked(page));
> - __set_task_state(tsk, TASK_RUNNING);
> - remove_wait_queue(waitqueue, &wait);
> + lock_page(page);
> + kill_buffers(page);
> + unlock_page(page);
> }
> +EXPORT_SYMBOL(wait_on_page);
>
> /*
> - * Unlock the page and wake up sleepers in ___wait_on_page.
> + * Unlock the page and wake up sleepers in lock_page.
> */
> void unlock_page(struct page *page)
> {
> @@ -1400,6 +1396,11 @@ found_page:
>
> if (!Page_Uptodate(page))
> goto page_not_up_to_date;
> + if (page->buffers) {
> + lock_page(page);
> + kill_buffers(page);
> + unlock_page(page);
> + }
> generic_file_readahead(reada_ok, filp, inode, page);
> page_ok:
> /* If users can be writing to this page using arbitrary
> @@ -1457,6 +1458,7 @@ page_not_up_to_date:
>
> /* Did somebody else fill it already? */
> if (Page_Uptodate(page)) {
> + kill_buffers(page);
> UnlockPage(page);
> goto page_ok;
> }
> @@ -1948,6 +1950,11 @@ retry_find:
> */
> if (!Page_Uptodate(page))
> goto page_not_uptodate;
> + if (page->buffers) {
> + lock_page(page);
> + kill_buffers(page);
> + unlock_page(page);
> + }
>
> success:
> /*
> @@ -2006,6 +2013,7 @@ page_not_uptodate:
>
> /* Did somebody else get it up-to-date? */
> if (Page_Uptodate(page)) {
> + kill_buffers(page);
> UnlockPage(page);
> goto success;
> }
> @@ -2033,6 +2041,7 @@ page_not_uptodate:
>
> /* Somebody else successfully read it in? */
> if (Page_Uptodate(page)) {
> + kill_buffers(page);
> UnlockPage(page);
> goto success;
> }
> @@ -2850,6 +2859,7 @@ retry:
> goto retry;
> }
> if (Page_Uptodate(page)) {
> + kill_buffers(page);
> UnlockPage(page);
> goto out;
> }
> --- 2.4.19-pre8/kernel/ksyms.c~nuke-buffers Fri May 24 12:24:56 2002
> +++ 2.4.19-pre8-akpm/kernel/ksyms.c Fri May 24 12:24:56 2002
> @@ -202,7 +202,6 @@ EXPORT_SYMBOL(ll_rw_block);
> EXPORT_SYMBOL(submit_bh);
> EXPORT_SYMBOL(unlock_buffer);
> EXPORT_SYMBOL(__wait_on_buffer);
> -EXPORT_SYMBOL(___wait_on_page);
> EXPORT_SYMBOL(generic_direct_IO);
> EXPORT_SYMBOL(discard_bh_page);
> EXPORT_SYMBOL(block_write_full_page);
> --- 2.4.19-pre8/mm/vmscan.c~nuke-buffers Fri May 24 12:24:56 2002
> +++ 2.4.19-pre8-akpm/mm/vmscan.c Fri May 24 12:24:56 2002
> @@ -365,8 +365,13 @@ static int shrink_cache(int nr_pages, zo
> if (unlikely(!page_count(page)))
> continue;
>
> - if (!memclass(page_zone(page), classzone))
> + if (!memclass(page_zone(page), classzone)) {
> + if (page->buffers && !TryLockPage(page)) {
> + try_to_release_page(page, GFP_NOIO);
> + unlock_page(page);
> + }
> continue;
> + }
>
> /* Racy check to avoid trylocking when not worthwhile */
> if (!page->buffers && (page_count(page) != 1 || !page->mapping))
> @@ -562,6 +567,11 @@ static int shrink_caches(zone_t * classz
> nr_pages -= kmem_cache_reap(gfp_mask);
> if (nr_pages <= 0)
> return 0;
> + if ((gfp_mask & __GFP_WAIT) && (shrink_buffer_cache() > 16)) {
> + nr_pages -= kmem_cache_reap(gfp_mask);
> + if (nr_pages <= 0)
> + return 0;
> + }
>
> nr_pages = chunk_size;
> /* try to keep the active list 2/3 of the size of the cache */
> --- 2.4.19-pre8/fs/buffer.c~nuke-buffers Fri May 24 12:24:56 2002
> +++ 2.4.19-pre8-akpm/fs/buffer.c Fri May 24 12:26:28 2002
> @@ -1500,6 +1500,10 @@ static int __block_write_full_page(struc
> /* Stage 3: submit the IO */
> do {
> struct buffer_head *next = bh->b_this_page;
> + /*
> + * Stick it on BUF_LOCKED so shrink_buffer_cache() can nail it.
> + */
> + refile_buffer(bh);
> submit_bh(WRITE, bh);
> bh = next;
> } while (bh != head);
> @@ -2615,6 +2619,25 @@ static int sync_page_buffers(struct buff
> int try_to_free_buffers(struct page * page, unsigned int gfp_mask)
> {
> struct buffer_head * tmp, * bh = page->buffers;
> + int was_uptodate = 1;
> +
> + if (!PageLocked(page))
> + BUG();
> +
> + if (!bh)
> + return 1;
> + /*
> + * Quick check for freeable buffers before we go take three
> + * global locks.
> + */
> + if (!(gfp_mask & __GFP_IO)) {
> + tmp = bh;
> + do {
> + if (buffer_busy(tmp))
> + return 0;
> + tmp = tmp->b_this_page;
> + } while (tmp != bh);
> + }
>
> cleaned_buffers_try_again:
> spin_lock(&lru_list_lock);
> @@ -2637,7 +2660,8 @@ cleaned_buffers_try_again:
> tmp = tmp->b_this_page;
>
> if (p->b_dev == B_FREE) BUG();
> -
> + if (!buffer_uptodate(p))
> + was_uptodate = 0;
> remove_inode_queue(p);
> __remove_from_queues(p);
> __put_unused_buffer_head(p);
> @@ -2645,7 +2669,15 @@ cleaned_buffers_try_again:
> spin_unlock(&unused_list_lock);
>
> /* Wake up anyone waiting for buffer heads */
> - wake_up(&buffer_wait);
> + smp_mb();
> + if (waitqueue_active(&buffer_wait))
> + wake_up(&buffer_wait);
> +
> + /*
> + * Make sure we don't read buffers again when they are reattached
> + */
> + if (was_uptodate)
> + SetPageUptodate(page);
>
> /* And free the page */
> page->buffers = NULL;
> @@ -2674,6 +2706,62 @@ busy_buffer_page:
> }
> EXPORT_SYMBOL(try_to_free_buffers);
>
> +/*
> + * Returns the number of pages which might have become freeable
> + */
> +int shrink_buffer_cache(void)
> +{
> + struct buffer_head *bh;
> + int nr_todo;
> + int nr_shrunk = 0;
> +
> + /*
> + * Move any clean unlocked buffers from BUF_LOCKED onto BUF_CLEAN
> + */
> + spin_lock(&lru_list_lock);
> + for ( ; ; ) {
> + bh = lru_list[BUF_LOCKED];
> + if (!bh || buffer_locked(bh))
> + break;
> + __refile_buffer(bh);
> + }
> +
> + /*
> + * Now start liberating buffers
> + */
> + nr_todo = nr_buffers_type[BUF_CLEAN];
> + while (nr_todo--) {
> + struct page *page;
> +
> + bh = lru_list[BUF_CLEAN];
> + if (!bh)
> + break;
> +
> + /*
> + * Park the buffer on BUF_LOCKED so we don't revisit it on
> + * this pass.
> + */
> + __remove_from_lru_list(bh);
> + bh->b_list = BUF_LOCKED;
> + __insert_into_lru_list(bh, BUF_LOCKED);
> + page = bh->b_page;
> + if (TryLockPage(page))
> + continue;
> +
> + page_cache_get(page);
> + spin_unlock(&lru_list_lock);
> + if (try_to_release_page(page, GFP_NOIO))
> + nr_shrunk++;
> + unlock_page(page);
> + page_cache_release(page);
> + spin_lock(&lru_list_lock);
> + }
> + spin_unlock(&lru_list_lock);
> +// printk("%s: liberated %d page's worth of buffer_heads\n",
> +// __FUNCTION__, nr_shrunk);
> + return (nr_shrunk * sizeof(struct buffer_head)) / PAGE_CACHE_SIZE;
> +}
> +
> /* ================== Debugging =================== */
>
> void show_buffers(void)
> @@ -2988,6 +3076,7 @@ int kupdate(void *startup)
> #ifdef DEBUG
> printk(KERN_DEBUG "kupdate() activated...\n");
> #endif
> + shrink_buffer_cache();
> sync_old_buffers();
> run_task_queue(&tq_disk);
> }
> --- 2.4.19-pre8/include/linux/fs.h~nuke-buffers Fri May 24 12:24:56 2002
> +++ 2.4.19-pre8-akpm/include/linux/fs.h Fri May 24 12:24:56 2002
> @@ -1116,6 +1116,7 @@ extern int FASTCALL(try_to_free_buffers(
> extern void refile_buffer(struct buffer_head * buf);
> extern void create_empty_buffers(struct page *, kdev_t, unsigned long);
> extern void end_buffer_io_sync(struct buffer_head *bh, int uptodate);
> +extern int shrink_buffer_cache(void);
>
> /* reiserfs_writepage needs this */
> extern void set_buffer_async_io(struct buffer_head *bh) ;
>
>
> -
--
Roy Sigurd Karlsbakk, Datavaktmester
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply [relevance 82%]
* Re: [small BUG] Makefile bug with gcc 3.1 and non english locales
2002-06-01 1:33 82% [small BUG] Makefile bug with gcc 3.1 and non english locales Edouard Gomez
@ 2002-06-01 1:44 82% ` Kai Germaschewski
0 siblings, 0 replies; 200+ results
From: Kai Germaschewski @ 2002-06-01 1:44 UTC (permalink / raw)
To: Edouard Gomez; +Cc: lkml
On Sat, 1 Jun 2002, Edouard Gomez wrote:
> kbuild_2_4_nostdinc := -nostdinc $(shell $(CC) -print-search-dirs | sed -ne 's/install: \(.*\)/-I \1include/gp')
Russell King suggested the following nice construct, which I'll submit for
2.5 shortly. It should work for you, too.
> CFLAGS += -nostdinc -iwithprefix include
>
> `-iwithprefix DIR'
> Add a directory to the second include path. The directory's name
> is made by concatenating PREFIX and DIR, where PREFIX was
> specified previously with `-iprefix'. If you have not specified a
> prefix yet, the directory containing the installed passes of the
> compiler is used as the default.
--Kai
^ permalink raw reply [relevance 82%]
* [small BUG] Makefile bug with gcc 3.1 and non english locales
@ 2002-06-01 1:33 82% Edouard Gomez
2002-06-01 1:44 82% ` Kai Germaschewski
0 siblings, 1 reply; 200+ results
From: Edouard Gomez @ 2002-06-01 1:33 UTC (permalink / raw)
To: lkml
Hello,
well, if i use gcc 3.1 with the current Makefile, the gcc specific include
dir is not well parsed in this expression :
kbuild_2_4_nostdinc := -nostdinc $(shell $(CC) -print-search-dirs | sed -ne 's/install: \(.*\)/-I \1include/gp')
because my system is fr_FR and the gcc output begins with :
Installé: ...
So i have to put LC_ALL=C before compiling the kernel.
I think you should set LC_ALL=C in the Makefile in order to avoid that
problem with locales.
Regards
PS : Please CC me the answers.
--
Edouard Gomez
^ permalink raw reply [relevance 82%]
* Kernel Bug or XFree Bug?
@ 2002-04-10 7:04 82% Brett Nuske
0 siblings, 0 replies; 200+ results
From: Brett Nuske @ 2002-04-10 7:04 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 939 bytes --]
Hi,
Having gotten my SiS300 running with DRM, whenever
I run a program requiring an OpenGL, mulitiple
scrambled copies of the program's screen are
then present on the screen below the second damper
wire on my monitor (I have attached a copy of what
it looks like if anyone is interested).a
Nothing crashes when this happens and can be
rectified by resetting the window manager.
Memory isn't a problem with over 100M free.
I don't know if this is a problem with the SiS
support in the kernel or an XFree86 problem.
Any help would be appreciated and apologies
if this isn't a kernel problem.
Regards
****************************************************
* Brett Nuske *
* 3nd Year B.APP.SCI.(Computer Science) *
* COSC1082/CS118 Tutor *
* City Helpdesk Staff (Computer Science) *
****************************************************
[-- Attachment #2: Type: IMAGE/JPEG, Size: 64763 bytes --]
^ permalink raw reply [relevance 82%]
* Re: ISO9660 bug and loopback driver bug - a bigger problem then it would appear?
2002-02-27 14:29 82% ` Richard B. Johnson
@ 2002-02-27 16:54 82% ` Jesper Juhl
0 siblings, 0 replies; 200+ results
From: Jesper Juhl @ 2002-02-27 16:54 UTC (permalink / raw)
To: root; +Cc: barubary, alan, linux-kernel
On Wed, 2002-02-27 at 15:29, Richard B. Johnson wrote:
> On Wed, 27 Feb 2002, Jesper Juhl wrote:
> [SNIPPED year 2100 "bug"]
> [SNIPPED year 2100 "bug" --fix!]
>
> >
> > If the above is indeed correct, wouldn't it then be better to just do
> > those changes in 2.5.x instead of 2.4.x (and then maybe backport them
> > later)...
>
> I suggest the changes wait until Version 99.99. Many of the File Systems
> affected won't even exist 98 years from now -and an 'int' will probably
> be 256 bits.
>
Sure ;) I'll just leave it alone for now. Maybe later if things change
it can be fixed without requireing major changes.
--
Mvh. / Best regards
Jesper Juhl - jju@dif.dk
^ permalink raw reply [relevance 82%]
* Re: ISO9660 bug and loopback driver bug - a bigger problem then it would appear?
@ 2002-02-27 14:29 82% ` Richard B. Johnson
2002-02-27 16:54 82% ` Jesper Juhl
0 siblings, 1 reply; 200+ results
From: Richard B. Johnson @ 2002-02-27 14:29 UTC (permalink / raw)
To: Jesper Juhl; +Cc: barubary, alan, linux-kernel
On Wed, 27 Feb 2002, Jesper Juhl wrote:
[SNIPPED year 2100 "bug"]
[SNIPPED year 2100 "bug" --fix!]
>
> If the above is indeed correct, wouldn't it then be better to just do
> those changes in 2.5.x instead of 2.4.x (and then maybe backport them
> later)...
I suggest the changes wait until Version 99.99. Many of the File Systems
affected won't even exist 98 years from now -and an 'int' will probably
be 256 bits.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
111,111,111 * 111,111,111 = 12,345,678,987,654,321
^ permalink raw reply [relevance 82%]
* Re: ISO9660 bug and loopback driver bug
2002-02-26 12:02 82% ` Barubary
@ 2002-02-26 12:37 82% ` Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 2002-02-26 12:37 UTC (permalink / raw)
To: Barubary; +Cc: linux-kernel, Alan Cox
> Why is it locale-dependent? All ISO9660 file times are stored as Gregorian
> calendar dates regardless of who made them, and the target (UNIX file time)
Thanks - I wasn't aware it was always defined to be the gregorian calendar
in ISO9660. The orthodox calendar differs in computation (its more accurate)
and the two actually diverge in 2800. (Pan Orthodox congress 1923 if anyone
actually cares)
> isn't locale-dependent either. Why would it affect the calculation if the
> local system used the Muslim calendar?
Unix file time is clean of those problems
> Shouldn't there be a gregorian_date_to_unix_time() function in the kernel so
> that every driver that needs such conversion can share that implementation?
> It would keep date processing consistent and make it easy to spot date bugs.
Not a bad idea if there are enough file systems doing it.
^ permalink raw reply [relevance 82%]
* Re: ISO9660 bug and loopback driver bug
2002-02-26 12:01 82% ` Rainer Ellinger
@ 2002-02-26 12:08 82% ` Barubary
0 siblings, 0 replies; 200+ results
From: Barubary @ 2002-02-26 12:08 UTC (permalink / raw)
To: Rainer Ellinger; +Cc: linux-kernel
Can you try a file between 2^31 and 2^32-1, inclusive? Maybe it's a
sign-related bug in the loopback driver, not a 64 bit I/O bug.
The file I tried to mount is this on an NTFS partition:
12/10/2001 20:13 3,522,562,048 dvd.iso
"losetup" fails too, meaning it's the loopback driver (and possibly the NTFS
driver) that is glitching, not the ISO driver.
Maybe trying to mount *anything* from an NTFS driver doesn't work? I'll
have to check that possibility too...
-- Barubary
----- Original Message -----
From: "Rainer Ellinger" <rainer@ellinger.de>
To: "Barubary" <barubary@cox.net>
Cc: <linux-kernel@vger.kernel.org>
Sent: Tuesday, February 26, 2002 4:01 AM
Subject: Re: ISO9660 bug and loopback driver bug
> Barubary wrote:
>
> > Now the loopback bug. Files whose size is greater than 2^31-1 don't
work
> > with the loopback driver.
>
> Can't reproduce. I can mount 4.7GB DVD-Images and i'm currently working
with an 48GB File mounted via loop, and a 100GB partition
> mounted via loop. I'm using loop-AES encryption patch with 2.4.17/18-rc4.
I'm not aware if there's a fix in this patch. afaik it
> should also work with vanilla loop.c.
>
> --
> rainer@ellinger.de
>
>
^ permalink raw reply [relevance 82%]
* Re: ISO9660 bug and loopback driver bug
2002-02-26 12:04 82% ` Alan Cox
@ 2002-02-26 12:02 82% ` Barubary
2002-02-26 12:37 82% ` Alan Cox
0 siblings, 1 reply; 200+ results
From: Barubary @ 2002-02-26 12:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Alan Cox
> Thats actually locale dependant, but yes. I'll fix that one.
Why is it locale-dependent? All ISO9660 file times are stored as Gregorian
calendar dates regardless of who made them, and the target (UNIX file time)
isn't locale-dependent either. Why would it affect the calculation if the
local system used the Muslim calendar?
You're probably right, but I just want to know why so I'll know for the
future.
Shouldn't there be a gregorian_date_to_unix_time() function in the kernel so
that every driver that needs such conversion can share that implementation?
It would keep date processing consistent and make it easy to spot date bugs.
-- Barubary
^ permalink raw reply [relevance 82%]
* Re: ISO9660 bug and loopback driver bug
2002-02-26 11:54 82% ` Jesper Juhl
@ 2002-02-26 12:01 82% ` Rainer Ellinger
2002-02-26 12:08 82% ` Barubary
2002-02-26 12:04 82% ` Alan Cox
2 siblings, 1 reply; 200+ results
From: Rainer Ellinger @ 2002-02-26 12:01 UTC (permalink / raw)
To: Barubary; +Cc: linux-kernel
Barubary wrote:
> Now the loopback bug. Files whose size is greater than 2^31-1 don't work
> with the loopback driver.
Can't reproduce. I can mount 4.7GB DVD-Images and i'm currently working with an 48GB File mounted via loop, and a 100GB partition
mounted via loop. I'm using loop-AES encryption patch with 2.4.17/18-rc4. I'm not aware if there's a fix in this patch. afaik it
should also work with vanilla loop.c.
--
rainer@ellinger.de
^ permalink raw reply [relevance 82%]
* Re: ISO9660 bug and loopback driver bug
@ 2002-02-26 11:54 82% ` Jesper Juhl
2002-02-26 12:01 82% ` Rainer Ellinger
2002-02-26 12:04 82% ` Alan Cox
2 siblings, 0 replies; 200+ results
From: Jesper Juhl @ 2002-02-26 11:54 UTC (permalink / raw)
To: Barubary; +Cc: linux-kernel
On Tue, 2002-02-26 at 12:37, Barubary wrote:
> First, the ISO9660 bug. The ISO file system driver in Linux doesn't handle
> leap years correctly. It assumes all years divisible by 4 are leap years,
> which is incorrect. For those that don't know the right algorithm, all
> years that (are divisible by 4) and ((not divisible by 100), or (divisible
> by 400)) are leap years. ISO file dates on or after March 1, 2100 will be 1
> day off when viewed under Linux as a result. The bug is in fs/isofs/util.c,
> function iso_date(). This is a very low priority bug, because a) nobody
> cares about ISO file date accuracy including me; and b) it shouldn't matter
> until 2100. Anyone bored enough to fix this? :) I guess I could do it...
>
I'll fix it. I'm still learning about the kernel, and fixing small bugs
is a good way to learn - and this one is on a scale I can handle. :-)
I'll look at it tonight and mail a patch to lkml as soon as the work is
done.
> Now the loopback bug. Files whose size is greater than 2^31-1 don't work
> with the loopback driver. It fails with strange errors, like "device not
> found". This bug prevents DVD-ROM .iso files from being mounted as either
> UDF or ISO file systems - the particular use I encountered it with. It's a
> bit higher of a priority than the ISO9660 date bug, because it prevents
> useful features from working. Still not too important though.
>
I'll give this one a shot as well, but I'm not yet sure I'm up to it -
will have to look at the code first. :)
--
Mvh. / Best regards
Jesper Juhl - jju@dif.dk
^ permalink raw reply [relevance 82%]
* Re: ISO9660 bug and loopback driver bug
2002-02-26 11:54 82% ` Jesper Juhl
2002-02-26 12:01 82% ` Rainer Ellinger
@ 2002-02-26 12:04 82% ` Alan Cox
2002-02-26 12:02 82% ` Barubary
2 siblings, 1 reply; 200+ results
From: Alan Cox @ 2002-02-26 12:04 UTC (permalink / raw)
To: Barubary; +Cc: linux-kernel
> which is incorrect. For those that don't know the right algorithm, all
> years that (are divisible by 4) and ((not divisible by 100), or (divisible
> by 400)) are leap years. ISO file dates on or after March 1, 2100 will be 1
Thats actually locale dependant, but yes. I'll fix that one.
> Now the loopback bug. Files whose size is greater than 2^31-1 don't work
> with the loopback driver. It fails with strange errors, like "device not
> found". This bug prevents DVD-ROM .iso files from being mounted as either
The loopback driver isnt 64bit file I/O aware afaik. That might be trickier
to fix.
^ permalink raw reply [relevance 82%]
* Re: [BUG] Suspected bug in getpeername and getsockname
@ 2002-01-18 0:05 82% Balbir Singh
0 siblings, 0 replies; 200+ results
From: Balbir Singh @ 2002-01-18 0:05 UTC (permalink / raw)
To: davem; +Cc: linux-kernel
>Can the user eat up more than a scheduling quantum because of the
>work done by ->getname()? I certainly don't think you can prove
>this.
>
That depends on what ->getname() does. Anyway
in my opinion any code which does all the processing
and then catches any error is BROKEN.
>It certainly isn't work the long discussion we're having about it,
>that is for sure.
>
I agree! no point
>You want this to make your broken getname() protocol semantics work
>and I'd like you to address that instead. I get the feeling that
>you've designed this weird behavior and that it is not specified in
>any standard anyways that your protocol must behave in this way. I
>suggest you change it to work without the user length being
>available.
>
There is no other choice but to live with it.
Regards,
Balbir
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
^ permalink raw reply [relevance 82%]
* Re: [BUG] Suspected bug in getpeername and getsockname
@ 2002-01-17 23:35 82% Balbir Singh
0 siblings, 0 replies; 200+ results
From: Balbir Singh @ 2002-01-17 23:35 UTC (permalink / raw)
To: davem; +Cc: linux-kernel
>From: "David S. Miller" <davem@redhat.com>
>
> Even if we do not pass the value passed by the user
> to the protocol specific code, I would like to cleanup
> the code in socket.c to check for invalid values
> upfront and save time and space in all the calls.
>
>Optimizing error cases never bears any fruit.
In this case, I certainly think it does. Could u give a
case as to why doing this would be harmful? I think the
only issue can be maintainability and doing the change
cleanly. But I think u are a good maintainer and will
accept the changes only if they are properly fixed.
Right :-)
Balbir
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
^ permalink raw reply [relevance 82%]
* Re: [BUG] Suspected bug in getpeername and getsockname
@ 2002-01-17 23:26 82% ` David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 2002-01-17 23:26 UTC (permalink / raw)
To: balbir_soni; +Cc: linux-kernel
From: "Balbir Singh" <balbir_soni@hotmail.com>
Date: Thu, 17 Jan 2002 15:20:14 -0800
Depending on the length passed to me in getpeername,
I fill in the correct members and return it back.
What broken protocol works like this?
Even if we do not pass the value passed by the user
to the protocol specific code, I would like to cleanup
the code in socket.c to check for invalid values
upfront and save time and space in all the calls.
Optimizing error cases never bears any fruit.
^ permalink raw reply [relevance 82%]
* Re: [BUG] Suspected bug in getpeername and getsockname
@ 2002-01-17 22:11 82% Balbir Singh
0 siblings, 0 replies; 200+ results
From: Balbir Singh @ 2002-01-17 22:11 UTC (permalink / raw)
To: davem; +Cc: linux-kernel
Actually, you are correct about that.
The reasons why I wanted to pass the address is length
is
1. It gives more flexibility for any body implementing
the protocol specific code.
2. We anyway copy the length in move_addr_to_user, we
might as well do it in the system call and pass the
length to the protocol.
3. We can finally copy only the length specified back
to the user as we do currently.
I correct my self, it is not a BUG.
But, consider a case where a user passes a negative value
in len. The system call calls the protocol specific
code and then later at the end in move_addr_to_user()
catches the error. I feel the error should be
caught first hand, we should not have spent the
time and space calling the protocol specific code at all,
we should catch the error and return immediately.
I feel there are several instances of this in the
socket system calls.
Don't u feel they should be fixed.
Balbir
>If move_addr_to_user() takes care of all of the issues, there is no
>reason for the protocol specific code to know anything about the
>user's len at all.
>
>You have to show me a purpose for it to get passed down. What would
>it get used for? All the protocol specific could should (and does)
>do is provide the data back to the top level routine and
>move_addr_to_user() takes care of the remaining details.
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
^ permalink raw reply [relevance 82%]
* Re: [BUG] Suspected bug in getpeername and getsockname
2002-01-17 16:27 82% [BUG] Suspected bug in getpeername and getsockname Balbir Singh
2002-01-17 20:24 82% ` kuznet
@ 2002-01-17 21:11 82% ` David S. Miller
1 sibling, 0 replies; 200+ results
From: David S. Miller @ 2002-01-17 21:11 UTC (permalink / raw)
To: balbir_soni; +Cc: linux-kernel
From: "Balbir Singh" <balbir_soni@hotmail.com>
Date: Thu, 17 Jan 2002 08:27:17 -0800
What I was trying to state is that the protocol specific
code does not get to see the length passed from the user.
The protocol specific code would like to look at what
the user passed.
If move_addr_to_user() takes care of all of the issues, there is no
reason for the protocol specific code to know anything about the
user's len at all.
You have to show me a purpose for it to get passed down. What would
it get used for? All the protocol specific could should (and does)
do is provide the data back to the top level routine and
move_addr_to_user() takes care of the remaining details.
^ permalink raw reply [relevance 82%]
* Re: [BUG] Suspected bug in getpeername and getsockname
2002-01-17 16:27 82% [BUG] Suspected bug in getpeername and getsockname Balbir Singh
@ 2002-01-17 20:24 82% ` kuznet
2002-01-17 21:11 82% ` David S. Miller
1 sibling, 0 replies; 200+ results
From: kuznet @ 2002-01-17 20:24 UTC (permalink / raw)
To: Balbir Singh; +Cc: linux-kernel
Hello!
> The protocol specific code would like to look at what
> the user passed.
For what purpose?
Protocol has no rights to use this length, because user has right
to pass buffer of any length and address will be simply truncated.
And the truncation is made by net/socket.c, so that protocols need
not worry about this.
Alexey
^ permalink raw reply [relevance 82%]
* Re: [BUG] Suspected bug in getpeername and getsockname
@ 2002-01-17 16:27 82% Balbir Singh
2002-01-17 20:24 82% ` kuznet
2002-01-17 21:11 82% ` David S. Miller
0 siblings, 2 replies; 200+ results
From: Balbir Singh @ 2002-01-17 16:27 UTC (permalink / raw)
To: davem; +Cc: linux-kernel
What I was trying to state is that the protocol specific
code does not get to see the length passed from the user.
The protocol specific code would like to look at what
the user passed.
Balbir
>You totally missed what move_addr_to_user() does, which is in fact
>truncate the copied len to what the user supplied. Also, the comments
>in move_addr_to_user even quote the bits of 1003.1g you a referring
>to.
>
>In short, the bug you suggest is not there.
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
^ permalink raw reply [relevance 82%]
* Re: [BUG] Suspected bug in getpeername and getsockname
@ 2002-01-17 0:54 82% ` David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 2002-01-17 0:54 UTC (permalink / raw)
To: balbir_soni; +Cc: linux-kernel
You totally missed what move_addr_to_user() does, which is in fact
truncate the copied len to what the user supplied. Also, the comments
in move_addr_to_user even quote the bits of 1003.1g you a referring
to.
In short, the bug you suggest is not there.
^ permalink raw reply [relevance 82%]
* [Fwd: Re: SDDR-31, or possible kernel bug]
@ 2001-12-24 22:48 82% Kyle
0 siblings, 0 replies; 200+ results
From: Kyle @ 2001-12-24 22:48 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 196 bytes --]
I have a flash card which, when read, locks up linux hard. Here's the
particulars so far. Is there anything I can do to help out kernel bug
checking before I try to reformat this flash card?
[-- Attachment #2: Re: SDDR-31, or possible kernel bug --]
[-- Type: message/rfc822, Size: 7135 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 5328 bytes --]
I suggest you contact linux-kernel@vger.kernel.org and see what they say.
Matt
On Mon, Dec 24, 2001 at 09:45:51AM -0700, Kyle wrote:
> Matthew Dharm wrote:
>
> >Yes, I'm still supporting it.
> >
> >Can you recompile your kernel with USB Mass Storage Verbose debugging
> >turned on?
> >
> Hmmm, I have an interesting new development. I had previously been doing:
>
> mount -t vfat /dev/sda1 /mnt/flash
>
> The device appeared to mount fine, but as soon as I would do:
>
> find /mnt/flash
>
> the system will *hard* lock. I just put the problem flash in a PCMCIA
> adapter and stuck it in my laptop. It is recognized nicely on /dev/hde.
> I do:
>
> mount -t vfat /dev/hde1 /mnt/flash
>
> which works ok, but when I do:
>
> find /mnt/flash
>
> the system hard locks just as before (but without usb being involved at
> all)...
>
> I looked in syslog and found:
>
> Dec 24 10:07:08 nb0 kernel: hde: hde1
> Dec 24 10:07:08 nb0 kernel: FAT: bogus logical sector size 20487
> Dec 24 10:07:08 nb0 kernel: VFS: Can't find a valid FAT filesystem on
> dev 21:00.
> Dec 24 10:07:08 nb0 kernel: hde: hde1
>
> I repeated the test and still got the hard lock, but the error messages
> about the FAT being messed up are not there. So I looked back in
> earlier logs of when I had been trying to mount the usb flash reader and
> sure enough: Even though later crashes had yielded no syslog messages,
> there were earlier ones that did. Here's a section of syslog:
>
> Dec 21 19:29:49 nb0 syslogd 1.4.1: restart.
> Dec 21 19:34:44 nb0 su(pam_unix)[1239]: session opened for user root by
> kyle(uid=1000)
> Dec 21 19:42:46 nb0 apmd[699]: Battery: -0.055762 (0:18) 4294967295
> days, 4294967291:4294967244 (100% unknown)
> Dec 21 20:06:37 nb0 modprobe: modprobe: Can't locate module char-major-97
> Dec 21 20:06:37 nb0 last message repeated 3 times
> Dec 21 20:07:02 nb0 modprobe: modprobe: Can't locate module freedos
> Dec 21 20:07:09 nb0 modprobe: modprobe: Can't locate module freefat
> Dec 21 20:07:24 nb0 kernel: Attached scsi removable disk sda at scsi0,
> channel 0, id 0, lun 0
> Dec 21 20:07:24 nb0 kernel: usb-uhci.c: interrupt, status 3, frame# 228
> Dec 21 20:07:24 nb0 kernel: usb-uhci.c: interrupt, status 3, frame# 242
> Dec 21 20:07:24 nb0 kernel: usb-uhci.c: interrupt, status 3, frame# 256
> Dec 21 20:07:24 nb0 kernel: sda : READ CAPACITY failed.
> Dec 21 20:07:24 nb0 kernel: sda : status = 1, message = 00, host = 0,
> driver = 08
> Dec 21 20:07:24 nb0 kernel: Current sd00:00: sense key Not Ready
> Dec 21 20:07:24 nb0 kernel: Additional sense indicates Medium not present
> Dec 21 20:07:24 nb0 kernel: sda : block size assumed to be 512 bytes,
> disk size 1GB.
> Dec 21 20:07:24 nb0 kernel: sda: I/O error: dev 08:00, sector 0
> Dec 21 20:07:24 nb0 kernel: unable to read partition table
> Dec 21 20:07:24 nb0 kernel: Device not ready. Make sure there is a disc
> in the drive.
> Dec 21 20:07:24 nb0 kernel: usb-uhci.c: interrupt, status 3, frame# 292
> Dec 21 20:07:24 nb0 kernel: usb-uhci.c: interrupt, status 3, frame# 306
> Dec 21 20:07:24 nb0 kernel: usb-uhci.c: interrupt, status 3, frame# 320
> Dec 21 20:07:24 nb0 kernel: sda : READ CAPACITY failed.
> Dec 21 20:07:24 nb0 kernel: sda : status = 1, message = 00, host = 0,
> driver = 08
> Dec 21 20:07:24 nb0 kernel: Current sd00:00: sense key Not Ready
> Dec 21 20:07:24 nb0 kernel: Additional sense indicates Medium not present
> Dec 21 20:07:24 nb0 kernel: sda : block size assumed to be 512 bytes,
> disk size 1GB.
> Dec 21 20:07:24 nb0 kernel: sda: I/O error: dev 08:00, sector 0
> Dec 21 20:07:24 nb0 kernel: unable to read partition table
> Dec 21 20:07:46 nb0 kernel: SCSI device sda: 125185 512-byte hdwr
> sectors (64 MB)
> Dec 21 20:07:46 nb0 kernel: sda: Write Protect is off
> Dec 21 20:07:46 nb0 kernel: sda: sda1
> Dec 21 20:12:21 nb0 syslogd 1.4.1: restart.
>
> I don't understand why later attempts don't log to syslog, but it
> appears to me that there is data corruption of some kind in this
> particular flash card. Every test that's failed had this card involved
> and other cards have not (yet) failed.
>
> I'm not sure if I should try reformatting the flash card or if we would
> lose a valuable chance to find a potential kernel problem. Is the
> kernel expected to survive if I mount a corrupt filesystem?
>
> I realize this sounds like the problem is not in your driver, but do you
> have any suggestions?
>
> >
> >
> >On Fri, Dec 21, 2001 at 07:58:17PM -0700, Kyle wrote:
> >
> >> Are you still supporting the usb-storage code?
> >>
> >>I have some of the SDDR-31 flash readers I'm using under Linux. They
> >>seem to work most of the time but when I get a flash card with lots of
> >>pictures on it, I hard lock the machine when I try to browse the newly
> >>mounted filesystem.
> >>
> >>I'm running redhat 7.2 (2.4.9 stock kernel).
> >>
> >>Any ideas where to start looking?
> >>
> >
>
>
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
I think the problem is there's a nut loose on your keyboard.
-- Greg to Customer
User Friendly, 1/5/1999
[-- Attachment #2.1.2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [relevance 82%]
* Re: VIA acknowledges North Bridge bug (AKA Linux Kernel with Athlon optimizations bug)
2001-12-05 19:21 82% VIA acknowledges North Bridge bug (AKA Linux Kernel with Athlon optimizations bug) Troels Walsted Hansen
@ 2001-12-05 21:09 82% ` Calin A. Culianu
0 siblings, 0 replies; 200+ results
From: Calin A. Culianu @ 2001-12-05 21:09 UTC (permalink / raw)
To: Troels Walsted Hansen; +Cc: linux-kernel
So does this mean we will be seeing a patch that clears bits 6,7, and 8 in
register 55 on the northbridge soon?
-Calin
On Wed, 5 Dec 2001, Troels Walsted Hansen wrote:
> Remember the pci_fixup_via_athlon_bug() (AKA "Athlon bug stomper")
> function which went into kernel 2.4.14 after much discussion?
>
> Apparently the mysterious register 55 in the Northbridge controls a
> buggy Memory Write Queue timer. They finally acknowledged the problem
> when Nvidia drivers and Windows XP started pushing the hardware enough
> to trigger the bug...
>
> http://bbs.pcstats.com/viahardware/messageview.cfm?catid=19&threadid=863
> 8
>
>
^ permalink raw reply [relevance 82%]
* VIA acknowledges North Bridge bug (AKA Linux Kernel with Athlon optimizations bug)
@ 2001-12-05 19:21 82% Troels Walsted Hansen
2001-12-05 21:09 82% ` Calin A. Culianu
0 siblings, 1 reply; 200+ results
From: Troels Walsted Hansen @ 2001-12-05 19:21 UTC (permalink / raw)
To: linux-kernel
Remember the pci_fixup_via_athlon_bug() (AKA "Athlon bug stomper")
function which went into kernel 2.4.14 after much discussion?
Apparently the mysterious register 55 in the Northbridge controls a
buggy Memory Write Queue timer. They finally acknowledged the problem
when Nvidia drivers and Windows XP started pushing the hardware enough
to trigger the bug...
http://bbs.pcstats.com/viahardware/messageview.cfm?catid=19&threadid=863
8
--
Troels Walsted Hansen
^ permalink raw reply [relevance 82%]
* BUG BUG hunt the bugs!!! patch-2.4.15-pre5
@ 2001-11-12 20:13 82% ` Martin Dalecki
0 siblings, 0 replies; 200+ results
From: Martin Dalecki @ 2001-11-12 20:13 UTC (permalink / raw)
Cc: Linus Torvalds, Alan Cox, linux-kernel
Hallo out there!
Same symptom from patch-2.4.15-pre4:
diff -u --recursive --new-file v2.4.14/linux/net/irda/irda_device.c
linux/net/irda/irda_device.c
--- v2.4.14/linux/net/irda/irda_device.c Sun Sep 23 11:41:02 2001
+++ linux/net/irda/irda_device.c Sun Nov 11 10:20:21 2001
bla bla bla...
@@ -124,6 +127,12 @@
#ifdef CONFIG_WINBOND_FIR
w83977af_init();
#endif
+#ifdef CONFIG_SA1100_FIR
+ sa1100_irda_init();
+#endif
+#ifdef CONFIG_SA1100_FIR
+ sa1100_irda_init();
+#endif
#ifdef CONFIG_NSC_FIR
nsc_ircc_init();
#endif
@@ -151,6 +160,12 @@
#ifdef CONFIG_OLD_BELKIN
old_belkin_init();
#endif
+#ifdef CONFIG_EP7211_IR
+ ep7211_ir_init();
+#endif
+#ifdef CONFIG_EP7211_IR
+ ep7211_ir_init();
+#endif
return 0;
You see the initialization done twice!
^ permalink raw reply [relevance 82%]
* Re: RH 7.1 gcc 2.96 bug (was Re: TAKE - work around gcc bug during xfs_growfs )
@ 2001-10-12 13:41 82% ` Steve Lord
0 siblings, 0 replies; 200+ results
From: Steve Lord @ 2001-10-12 13:41 UTC (permalink / raw)
To: erich; +Cc: Eric Sandeen, linux-xfs, linux-kernel
Thanks for the diagnosis - we need help when it comes to reading intel
assembler in depth. Please pass this on to redhat.
Steve
>
> Eric Sandeen <sandeen@sgi.com> wrote:
>
> > > You may want to check it against the rawhide -99 version, since you know
> > > exactly what to test for. If you'd like I could try that tonight for
> > > you.
> >
> > Sure, if you'd like to test it that would be great. I was going to
> > install that compiler RPM, but it needs a new binutils which needs a
> > new glibc which needs... :)
> >
> > Take a look at that URL for the diff I posted, and back it out.
> >
> > To test for the error,
> ...[example creating an XFS filesystem about 1/2 the partition size,
> then growing it to the full partition size]...
> > If you see any errors, it didn't work. :)
>
> Well, I wasn't able to reproduce with your test case at all. I suspect
> that maybe it's the fact that I only had a 2GB spare partition to try it
> on.
>
> On the positive (??!?) side, I looked at the disassembly and found
> what the compiler is doing wrong in the case you worked around
> (ok, so you probably already know this, but I'm putting this here
> so that someone can fix the bug or convince RedHat to move to
> away from 2.96, maybe to 3.x).
>
> In the second one of the 5 cases of where you added a temporary rather
> than a putting the macro in the function parameter sequence directly,
> there are some operations done to what appear to be spill locations,
> but the spill and reload are never performed... so it seems these
> locations were allocated for spill/reload, but then wires got crossed
> somewhere.
>
> In the "fixed" version, the exact same operations are performed
> on the same stack locations, but the spill happens before and a reload
> happens afterward, hence my suspicions.
>
> Here is the assembly output difference (from the original and recently
> "fixed" version of "linux/fs/xfs/xfs_fsops.c" in the linux-xfs CVS
> tree):
>
> "original version":
>
> sall %cl, %eax
> testb $32, %cl
> cmovne %eax, %edx
> cmovne %edi, %eax
>
> [no spill?!?]
>
> --> addl $2, 16(%esp)
> --> adcl $0, 20(%esp)
>
> [no reload!?!]
>
> shldl $9, %eax, %edx
> sall $9, %eax
> pushl %edx
> pushl %eax
>
>
> "fixed version":
>
> sall %cl, %eax
> testb $32, %cl
> cmovne %eax, %edx
> cmovne %ebx, %eax
> S-> movl %eax, 8(%esp)
> --> addl $2, 8(%esp)
> S-> movl %edx, 12(%esp)
> --> adcl $0, 12(%esp)
> pushl $8708
> movl 80(%esp), %ecx
> sall $9, %ecx
> pushl %ecx
> R-> movl 16(%esp), %eax
> R-> movl 20(%esp), %edx
> shldl $9, %eax, %edx
> sall $9, %eax
> pushl %edx
> pushl %eax
>
>
> Note the ending code sequence to push the parameters on the stack
> are the same, but in the first sequence, the operations are done
> on memory locations that have no connection with the rest of the
> code. Ack.
>
> It is very reproducable and happens in all the RedHat 7.1 gcc 2.96
> series compiler versions I tried: -81 (the one in the base release),
> -85 (the one in RedHat's update set), -88, and -99 (the most recent
> currently in RawHide). Personally, this problem is weird enough to
> kind of spook me... seems they've had busted register spill/reload
> logic for a while.
>
> The RawHide GCC 3.0.1 compiler I grabbed doesn't have this problem,
> and the rest of the code in that file appears to be correct regardless
> of your workaround. Same with "kgcc".
>
>
> Do you want me to send this to RedHat? ...or have you got as good/
> better explanation to hand to them already?
>
>
> --
> Erich Stefan Boleyn <erich@uruk.org> http://www.uruk.org/
> "Reality is truly stranger than fiction; Probably why fiction is so popular"
^ permalink raw reply [relevance 82%]
* Re: 2.4.10-pre5: Bug in alloc_pages [should be bug in page_alloc.c]
@ 2001-09-08 11:06 82% Nick Piggin
0 siblings, 0 replies; 200+ results
From: Nick Piggin @ 2001-09-08 11:06 UTC (permalink / raw)
To: Linux-Kernel
^ permalink raw reply [relevance 82%]
* [New URL FOR K6 bug] Re: K6 sig11 Bug detection.
@ 2001-08-17 12:05 82% ` André Dahlqvist
0 siblings, 0 replies; 200+ results
From: André Dahlqvist @ 2001-08-17 12:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Alan Cox
> Also the link http://www.mygale.com/~poulot/k6bug.html does not exist.
New URL seams to be http://www.multimania.com/poulot/k6bug.html.
Alan, can you correct this in your next -ac?
--
André Dahlqvist <andre.dahlqvist@telia.com>
^ permalink raw reply [relevance 82%]
* Re: [BUG] hotplug network agent / apmd bug...
2001-07-25 5:15 82% [BUG] hotplug network agent / apmd bug Ryan Mack
@ 2001-07-25 20:23 82% ` Ryan Mack
2001-07-25 14:39 82% ` David Brownell
1 sibling, 0 replies; 200+ results
From: Ryan Mack @ 2001-07-25 20:23 UTC (permalink / raw)
To: linux-hotplug
It's probably a distro bug then, in which case I've already submitted it
to RH.
-Ryan
On Wed, 25 Jul 2001, David Brownell wrote:
> Hmm, I've not hacked apmd stuff in ages, but as I recall
> it didn't ship with any configuration-specific support in
> its scripts -- stuff like "cardctl" and "service" commands.
> Are you positive those aren't distro bugs?
>
> In general it'd make more sense to start networking
> first, I suspect..
>
> - Dave
>
> ----- Original Message -----
> From: "Ryan Mack" <rmack@mackman.net>
> To: <linux-hotplug-devel@lists.sourceforge.net>; <apenwarr@worldvisions.ca>
> Sent: Tuesday, July 24, 2001 10:15 PM
> Subject: [BUG] hotplug network agent / apmd bug...
>
>
> > The apm-script included in apmd-3.0final does the following on resume:
> >
> > cardctl resume/insert
> > service networking start
> >
> > Unfortunately, if one of your pcmcia cards is a PCI-merged networking card
> > such as the 3c575_cb, hotplug does the following upon seeing the card
> > resumed...
> >
> > if networking is started, configure the new interface
> >
> > Thus, because apmd reenables pcmcia before networking, a pcmcia network
> > adapter won't be configured by hotplug.
> >
> > One easy sollution, is that if the pcmcia network adapter is always in the
> > system, you can enable ONBOOT for the interface, and thus the networking
> > script will enable it for you. In my case (frequently switching between
> > LAN and WAN cards), that isn't an option.
> >
> > Anyhow, if one of the two projects could fix this it would be much
> > appreciated. I'd submit a patch, but I'm not sure which project should be
> > patched.
> >
> > Thanks, Ryan Mack
> >
> >
> > _______________________________________________
> > Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
> > Linux-hotplug-devel@lists.sourceforge.net
> > http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
>
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [relevance 82%]
* Re: [BUG] hotplug network agent / apmd bug...
2001-07-25 5:15 82% [BUG] hotplug network agent / apmd bug Ryan Mack
2001-07-25 20:23 82% ` Ryan Mack
@ 2001-07-25 14:39 82% ` David Brownell
1 sibling, 0 replies; 200+ results
From: David Brownell @ 2001-07-25 14:39 UTC (permalink / raw)
To: linux-hotplug
Hmm, I've not hacked apmd stuff in ages, but as I recall
it didn't ship with any configuration-specific support in
its scripts -- stuff like "cardctl" and "service" commands.
Are you positive those aren't distro bugs?
In general it'd make more sense to start networking
first, I suspect..
- Dave
----- Original Message -----
From: "Ryan Mack" <rmack@mackman.net>
To: <linux-hotplug-devel@lists.sourceforge.net>; <apenwarr@worldvisions.ca>
Sent: Tuesday, July 24, 2001 10:15 PM
Subject: [BUG] hotplug network agent / apmd bug...
> The apm-script included in apmd-3.0final does the following on resume:
>
> cardctl resume/insert
> service networking start
>
> Unfortunately, if one of your pcmcia cards is a PCI-merged networking card
> such as the 3c575_cb, hotplug does the following upon seeing the card
> resumed...
>
> if networking is started, configure the new interface
>
> Thus, because apmd reenables pcmcia before networking, a pcmcia network
> adapter won't be configured by hotplug.
>
> One easy sollution, is that if the pcmcia network adapter is always in the
> system, you can enable ONBOOT for the interface, and thus the networking
> script will enable it for you. In my case (frequently switching between
> LAN and WAN cards), that isn't an option.
>
> Anyhow, if one of the two projects could fix this it would be much
> appreciated. I'd submit a patch, but I'm not sure which project should be
> patched.
>
> Thanks, Ryan Mack
>
>
> _______________________________________________
> Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [relevance 82%]
* [BUG] hotplug network agent / apmd bug...
@ 2001-07-25 5:15 82% Ryan Mack
2001-07-25 20:23 82% ` Ryan Mack
2001-07-25 14:39 82% ` David Brownell
0 siblings, 2 replies; 200+ results
From: Ryan Mack @ 2001-07-25 5:15 UTC (permalink / raw)
To: linux-hotplug
The apm-script included in apmd-3.0final does the following on resume:
cardctl resume/insert
service networking start
Unfortunately, if one of your pcmcia cards is a PCI-merged networking card
such as the 3c575_cb, hotplug does the following upon seeing the card
resumed...
if networking is started, configure the new interface
Thus, because apmd reenables pcmcia before networking, a pcmcia network
adapter won't be configured by hotplug.
One easy sollution, is that if the pcmcia network adapter is always in the
system, you can enable ONBOOT for the interface, and thus the networking
script will enable it for you. In my case (frequently switching between
LAN and WAN cards), that isn't an option.
Anyhow, if one of the two projects could fix this it would be much
appreciated. I'd submit a patch, but I'm not sure which project should be
patched.
Thanks, Ryan Mack
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [relevance 82%]
* Re: bug: 2.4.[<=6] kernel has Cyrix 'coma' bug?
2001-07-22 13:10 93% bug: 2.4.[<=6] kernel has Cyrix 'coma' bug? Steven Lass
@ 2001-07-22 21:36 82% ` Steven Lass
0 siblings, 0 replies; 200+ results
From: Steven Lass @ 2001-07-22 21:36 UTC (permalink / raw)
To: linux-kernel
Just tried the 2.4.7 kernel & it freezes too.
-steve
Steven Lass wrote:
>
> dev-list,
>
> Every 2.4 kernel that I've tried freezes my Cyrix MediaGX system at boot
> up.
>
> Typically the last messages displayed are:
>
> Working around Cyrix MediaGX virtual DMA bugs
> CPU: Cyrix Media GX Core/Bus Clock Stepping 02
> Checking 'hlt' instruction
>
> Occasionally, the "Checking 'hlt' instruction" is not displayed before
> it freezes.
>
> My system is a PowerSpec Model 1810 (no laughs please), my Phoenix BIOS
> reports "Cyrix GX 3.2 180MHz".
>
> I've compiled/installed numerous 2.2.x kernels w/o any trouble. The
> Redhat 7.1 CDROM image freezes at boot. I've compiled the 2.4.4, 2.4.5,
> & 2.4.6 kernels with various config settings, but they all freeze at
> boot. I'm currently running redhat 7.0, so I've tried compiling with
> gcc (gcc 2.96 20000731) & kgcc (egcs 1.1.2 release), no luck.
>
> I'm willing to compile the 2.4.[<4} kernels or try any other
> pre-compiled kernels if anyone has a suggestion.
>
> Please CC: me on any response
> -steve
^ permalink raw reply [relevance 82%]
* Re: PROBLEM: <BUG Report: kernel BUG at slab.c:1062! from pppd with speedtouch drivers and pppoatm>
[not found] ` <200107112351.f6BNpa304221@penguin.transmeta.com>
@ 2001-07-12 15:10 82% ` Richard Purdie
0 siblings, 0 replies; 200+ results
From: Richard Purdie @ 2001-07-12 15:10 UTC (permalink / raw)
To: linux-kernel
Linus Torvalds wrote:
> Looks like a "cmovne" that traps - are you sure you've compiled your
> module with the right CPU flags? In particular, maybe you compiled it
> for a i686, and are running it on a Pentium?
Spot on correct. I wish I could do that from a panic report :)
For the record the atm library also needs recompiling from kernel 2.4.5 to
2.4.6 otherwise you also get problems. Probably those number changes
again...
Thanks to all for your help.
I'd never have found that myself. The ADSL line is now running :)
Cheers,
RP
^ permalink raw reply [relevance 82%]
* Re: PROBLEM: <BUG Report: kernel BUG at slab.c:1062! from pppd with speedtouch drivers and pppoatm>
@ 2001-07-11 23:51 82% ` Linus Torvalds
[not found] ` <200107112351.f6BNpa304221@penguin.transmeta.com>
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2001-07-11 23:51 UTC (permalink / raw)
To: linux-kernel
In article <003f01c10a63$08f50540$0301a8c0@rpnet.com>,
Richard Purdie <rpurdie@bigfoot.com> wrote:
>
>Now I'm back to the kerenel panic below which takes down the system at the
>same point as before:
Looks like a "cmovne" that traps - are you sure you've compiled your
module with the right CPU flags? In particular, maybe you compiled it
for a i686, and are running it on a Pentium?
Linus
^ permalink raw reply [relevance 82%]
* Re: PROBLEM: <BUG Report: kernel BUG at slab.c:1062! from pppd with speedtouch drivers and pppoatm>
2001-07-11 18:01 82% PROBLEM: <BUG Report: kernel BUG at slab.c:1062! from pppd with speedtouch drivers and pppoatm> Richard Purdie
@ 2001-07-11 18:19 82% ` Georg Nikodym
0 siblings, 0 replies; 200+ results
From: Georg Nikodym @ 2001-07-11 18:19 UTC (permalink / raw)
To: Richard Purdie; +Cc: linux-kernel
>>>>> "RP" == Richard Purdie <rpurdie@bigfoot.com> writes:
>> > I'm trying to get Linux to work with an Alcatel Speedtouch ADSL
>> > USB
RP> modem.
>> > By executing the following script after boot up I get the BUG
>> > message
RP> after
>> > running pppd.
>>
>> Have you tried asking the author of the speedtouch driver about
>> this?
RP> I've sent him a copy of the bug report I submitted here. I'm
RP> still unsure of where the problem lies. My machine is being
RP> unpredictable even when the driver hasn't been loaded.
The BUG() invocation is a result of invalid flags being passed to
kmem_cache_grow().
The numeric values associated with things like GFP_ATOMIC changed in
2.4.6. Your problem is likely related to the use of modules built on
something other than the kernel you're running.
(I know this because I spent entirely too long debugging somebody's
code yesterday that thought it was a good idea to have his own copies
of the definitions of GFP_ATOMIC, et al.)
^ permalink raw reply [relevance 82%]
* Re: PROBLEM: <BUG Report: kernel BUG at slab.c:1062! from pppd with speedtouch drivers and pppoatm>
@ 2001-07-11 18:01 82% Richard Purdie
2001-07-11 18:19 82% ` Georg Nikodym
0 siblings, 1 reply; 200+ results
From: Richard Purdie @ 2001-07-11 18:01 UTC (permalink / raw)
To: linux-kernel
> > I'm trying to get Linux to work with an Alcatel Speedtouch ADSL USB
modem.
> > By executing the following script after boot up I get the BUG message
after
> > running pppd.
>
> Have you tried asking the author of the speedtouch driver about this?
I've sent him a copy of the bug report I submitted here. I'm still unsure of
where the problem lies. My machine is being unpredictable even when the
driver hasn't been loaded.
Cheers,
RP
^ permalink raw reply [relevance 82%]
* Re: PROBLEM: <BUG Report: kernel BUG at slab.c:1062! from pppd with speedtouch drivers and pppoatm>
@ 2001-07-11 16:14 82% ` Greg KH
2001-07-11 15:37 82% ` dr john halewood
1 sibling, 0 replies; 200+ results
From: Greg KH @ 2001-07-11 16:14 UTC (permalink / raw)
To: Richard Purdie; +Cc: linux-kernel
On Wed, Jul 11, 2001 at 04:11:09PM +0100, Richard Purdie wrote:
>
> I'm trying to get Linux to work with an Alcatel Speedtouch ADSL USB modem.
> By executing the following script after boot up I get the BUG message after
> running pppd.
Have you tried asking the author of the speedtouch driver about this?
greg k-h
^ permalink raw reply [relevance 82%]
* Re: PROBLEM: <BUG Report: kernel BUG at slab.c:1062! from pppd with speedtouch drivers and pppoatm>
2001-07-11 15:37 82% ` dr john halewood
@ 2001-07-11 15:55 82% ` Richard Purdie
1 sibling, 0 replies; 200+ results
From: Richard Purdie @ 2001-07-11 15:55 UTC (permalink / raw)
To: john; +Cc: linux-kernel
> Just to check: I got exactly the same thing, and a very similar oops (EIP
> in kmem_cache_grow &c) when trying to load sb.o & opl3.o under
> 2.4.7-pre5. It was caused by the fact that I hadn't updated
> /etc/modules.conf to point to the correct directory, and the kernel was
> trying to load modules from 2.4.5.
> Can you check to make sure that the modules being loaded are the correct
> ones for the kernel version?
I'm quite certain that it's loading modules from /lib/modules/2.4.6
(confirmed with modprobe -c). My /etc/modules.conf file doesn't have any
paths in it.
Cheers,
RP
^ permalink raw reply [relevance 82%]
* Re: PROBLEM: <BUG Report: kernel BUG at slab.c:1062! from pppd with speedtouch drivers and pppoatm>
2001-07-11 16:14 82% ` Greg KH
@ 2001-07-11 15:37 82% ` dr john halewood
2001-07-11 15:55 82% ` Richard Purdie
1 sibling, 2 replies; 200+ results
From: dr john halewood @ 2001-07-11 15:37 UTC (permalink / raw)
To: Richard Purdie, linux-kernel
On Wednesday 11 July 2001 16:11, Richard Purdie wrote:
> [1.] One line summary of the problem:
>
> BUG Report: kernel BUG at slab.c:1062!
Just to check: I got exactly the same thing, and a very similar oops (EIP in
kmem_cache_grow &c) when trying to load sb.o & opl3.o under 2.4.7-pre5. It
was caused by the fact that I hadn't updated /etc/modules.conf to point to
the correct directory, and the kernel was trying to load modules from 2.4.5.
Can you check to make sure that the modules being loaded are the correct ones
for the kernel version?
cheers
john
^ permalink raw reply [relevance 82%]
* Re: intermittent hangs with threads (clone() bug?/linuxthreads bug?)
@ 2001-06-20 8:22 82% ` bert hubert
0 siblings, 0 replies; 200+ results
From: bert hubert @ 2001-06-20 8:22 UTC (permalink / raw)
To: 'linux-kernel@vger.kernel.org'
On Tue, Jun 19, 2001 at 05:23:48PM -0400, Ed Connell wrote:
> If I run, for example, linuxthreads/Examples/ex1 (one thread prints 'a',
> one prints 'b') it will run fine. If I run it from a shell script
> (bash or ksh) with exec ex1
> it almost always hangs. When I do a "ps" I see the original "ex1" process
> plus another defunct "ex1" process with a higher pid. This defunct
and if you redirect output to /dev/null?
regards,
bert
--
http://www.PowerDNS.com Versatile DNS Services
Trilab The Technology People
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
^ permalink raw reply [relevance 82%]
* [BUG] bug in mmap_kmem
@ 2001-06-19 10:34 82% Yoav Etsion
0 siblings, 0 replies; 200+ results
From: Yoav Etsion @ 2001-06-19 10:34 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Tsafrir Dan
Hi,
The problem is that mmaping a segment <addr,len> from /dev/kmem gives
differnet results than reading the same <addr,len>.
It seems that the bug is that mmap_kmem is a macro for mmap_mem (for
/dev/mem).
mmap_mem maps a _physical_ offset into a vm area vma, while mmap_kmem
should map a _virtual_ offset into a vm area.
I hacked it to work by copying mmap_mem to mmap_kmem and adding __pa() in
the proper assginment, but I don't know how to check if the offset is
valid in the kernel virtual memory. Maybe someone who knows the mm code
better can fix this?
Thanks,
Yoav Etsion
^ permalink raw reply [relevance 82%]
* Re: BUG?: 2.4.5 breaks reiserfs (kernel BUG)
2001-05-27 17:20 82% BUG?: 2.4.5 breaks reiserfs (kernel BUG) Bjerkeset, Svein Olav
@ 2001-05-27 22:22 82% ` Alexander Viro
0 siblings, 0 replies; 200+ results
From: Alexander Viro @ 2001-05-27 22:22 UTC (permalink / raw)
To: svbj; +Cc: linux-kernel, Linus Torvalds, Alan Cox
On Sun, 27 May 2001, Bjerkeset, Svein Olav wrote:
> Hi,
>
> Today I downloaded kernel 2.4.5 and compiled it. The kernel worked fine
> until
> I tried to halt the computer. When trying to unmount the reiserfs
> filesystems,
> the system freezes with the following output:
>
> journal_begin called without kernel lock held
> kernel BUG at journal.c:423!
Yes. My fault - badly merged patch in -pre6, actually.
Details:
* kill_super() gets called without BKL, but doesn't grab BKL around
the calls of ->write_super() and ->put_super()
* by the time when it calls these methods filesystem is quiet. I.e.
nothing else has a chance to touch its data structures. So actually only
reiserfs (which checks that we hold BKL) had noticed.
* It _is_ a bug - changing locking rules is for 2.5.
Fix:
--- fs/super.c Fri May 25 21:51:14 2001
+++ fs/super.c Sun May 27 00:21:53 2001
@@ -873,6 +873,7 @@
}
spin_unlock(&dcache_lock);
down_write(&sb->s_umount);
+ lock_kernel();
sb->s_root = NULL;
/* Need to clean after the sucker */
if (fs->fs_flags & FS_LITTER)
@@ -901,6 +902,7 @@
put_filesystem(fs);
sb->s_type = NULL;
unlock_super(sb);
+ unlock_kernel();
up_write(&sb->s_umount);
if (bdev) {
blkdev_put(bdev, BDEV_FS);
^ permalink raw reply [relevance 82%]
* BUG?: 2.4.5 breaks reiserfs (kernel BUG)
@ 2001-05-27 17:20 82% Bjerkeset, Svein Olav
2001-05-27 22:22 82% ` Alexander Viro
0 siblings, 1 reply; 200+ results
From: Bjerkeset, Svein Olav @ 2001-05-27 17:20 UTC (permalink / raw)
To: linux-kernel
Hi,
Today I downloaded kernel 2.4.5 and compiled it. The kernel worked fine
until
I tried to halt the computer. When trying to unmount the reiserfs
filesystems,
the system freezes with the following output:
journal_begin called without kernel lock held
kernel BUG at journal.c:423!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c01b5fb0>]
EFLAGS: 00210282
eax: 0000001d ebx: c1eb1f28 ecx: c7ab2000 edx: 00000001
esi: c13c8200 edi: 3b11320b ebp: 0000000a esp: c1eb1ec0
ds: 0018 es: 0018 ss: 0018
Process umount (pid: 1027, stackpage=c1eb1000)
Stack: c02ef289 c02ef3e4 000001a7 c01b855b c02f0401 c1eb1f28 c13c8200
c034e020
c13c8234 3b11320b 00000000 c67f55c0 c13c8200 c1eb0000 c13c8244
c01b876e
c1eb1f28 c13c8200 0000000a 00000000 c01a92f8 c1eb1f28 c13c8200
0000000a
Call Trace: [<c01b855b>] [<c01b876e>] [<c01a92f8>] [<c0137baa>]
[<c0137be1>] [<c0136e8c>] [<c013cecc>]
[<c013808d>] [<c0122f62>] [<c01380c4>] [<c0106efb>]
Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 90 31 c0 c3 90 56 be 40 2f
BTW: The kernel is compiled with egcs 2.91.66
Please CC to svbj@online.no as I am not subscribed to this list
Svein Olav Bjerkeset
ý:.žË›±Êâmçë¢kaŠÉb²ßìzwm…ébïîžË›±Êâmébžìÿ‘êçz_âžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~††Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣømšSåy«\x1eæ¶\x17…\x01\x06†ÛiÿÿðÃ\x0fí»\x1fè®\x0få’i\x7f
^ permalink raw reply [relevance 82%]
* Re: it isn't aa's rwsem-generic-6 bug but something else [Re: aa's rwsem-generic-6 bug? Process stuck in 'R' state.]
2001-04-26 15:45 82% ` Andrea Arcangeli
@ 2001-04-26 16:10 82% ` Bob McElrath
0 siblings, 0 replies; 200+ results
From: Bob McElrath @ 2001-04-26 16:10 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]
Andrea Arcangeli [andrea@suse.de] wrote:
> On Thu, Apr 26, 2001 at 12:38:02AM -0500, Bob McElrath wrote:
> > When I posted this bug originally, you came right out and said it was
> > probably the rwsemaphores. I really have no idea how the rwsemaphores
>
> You were talking about the ps table hang when I told you about the rwsem
> races. I had the same trouble on my alpha and I reproduced the races
> trivially by lanucing:
>
> make MAKE='make -j2' -j2 &
>
> while :; do ps xa ; sleep 1 ; done
>
> After a few seconds ps deadlocked. Try that on the old asm semaphores.
This does not cause a hang on my machine with your new rwsemaphores.
> It was 100% reproducible, and after I rewrote the rwsemaphores the
> deadlock gone away completly.
>
> Your X hanging in R state is completly unrelated to the rwsem ps table
> hang problem as far I can tell.
Ok, so what are the other alternatives? In the R state, the scheduler
should give it some CPU at the first available jiffy, correct? After
several minutes it was still stuck in the R state, and had received 0
CPU time.
Could this be a scheduler bug?
Another thing I just noticed: watching the ps list, gcc is getting
called with -mcpu=ev56, which in turn is calling as with -mev6. Since
this is an ev56 processor, not the newer ev6, this could conceivable be
generating illegal instructions, though I haven't ever seen any kernel
illegal instruction faults.
*Sigh*
-- Bob
Bob McElrath (rsmcelrath@students.wisc.edu)
Univ. of Wisconsin at Madison, Department of Physics
[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]
^ permalink raw reply [relevance 82%]
* Re: it isn't aa's rwsem-generic-6 bug but something else [Re: aa's rwsem-generic-6 bug? Process stuck in 'R' state.]
@ 2001-04-26 15:45 82% ` Andrea Arcangeli
2001-04-26 16:10 82% ` Bob McElrath
0 siblings, 1 reply; 200+ results
From: Andrea Arcangeli @ 2001-04-26 15:45 UTC (permalink / raw)
To: Bob McElrath; +Cc: linux-kernel
On Thu, Apr 26, 2001 at 12:38:02AM -0500, Bob McElrath wrote:
> When I posted this bug originally, you came right out and said it was
> probably the rwsemaphores. I really have no idea how the rwsemaphores
You were talking about the ps table hang when I told you about the rwsem
races. I had the same trouble on my alpha and I reproduced the races
trivially by lanucing:
make MAKE='make -j2' -j2 &
while :; do ps xa ; sleep 1 ; done
After a few seconds ps deadlocked. Try that on the old asm semaphores.
It was 100% reproducible, and after I rewrote the rwsemaphores the
deadlock gone away completly.
Your X hanging in R state is completly unrelated to the rwsem ps table
hang problem as far I can tell.
> I'm running a debug X build at this point, and have identified at least
If you can reproduce without starting X I will be interested in fixing
the hang. Maybe you have a graphics card with a fb driver that doesn't
need VESA that maybe works on the alpha, then you could run X without
privilegies. (btw, in theory we could make the VESA thing working as
well using the x86 emulator in SRM but nobody attempted to implement
that yet)
> instead of gcc...then figured what the hell) The rest were with egcs
> 1.1.2. I'll use egcs 1.1.2 in the future.
good.
Andrea
^ permalink raw reply [relevance 82%]
* Re: 2.4.3 VFS bug and namei.c bug
[not found] <8E2EEEE24B6FD211ADC400104B71BA020169DB4A@MESSAGING>
@ 2001-04-16 20:25 82% ` Andre Hedrick
0 siblings, 0 replies; 200+ results
From: Andre Hedrick @ 2001-04-16 20:25 UTC (permalink / raw)
To: Mickey Lalescu; +Cc: 'linux-kernel@vger.kernel.org'
dev 08:01
This is a SCSI device sorry...
On Mon, 16 Apr 2001, Mickey Lalescu wrote:
> I am not sure if this is an IDE problem it seems to be an VFS one but I
> can't find the maintainer for VFS. Ouch while I was trying to submit this
> other bug I've got another one. Here is the output of the new one
>
> I/O error: dev 08:01, sector 67080
> kernel BUG at namei.c:343!
> invalid operand: 0000
> CPU: 0
> EIP: 0010:[<c0170585>]
> EFLAGS: 00010282
> eax: 0000001b ebx: cb8efe68 ecx: c4de6000 edx: c02c7f68
> esi: c393a660 edi: cb8efea8 ebp: cb8efe0c esp: cb8efe00
> ds: 0018 es: 0018 ss: 0018
> Process man (pid: 415, stackpage=cb8ef000)
> Stack: c0276e8b c0276f43 00000157 0000005b 0000006c 0026b6ff 000001f4
> 00000000
> 00000003 cd02a3c0 c012fb40 c0276fee cb8efe68 cb8efea8 cf941bc0
> c01706ab
> c393a660 cf941c20 00000003 cb8efe68 cb8efea8 00000000 cd02a3c0
> c5ed5000
> Call Trace: [<c012fb40>] [<c01706ab>] [<c0140986>] [<c0138b6f>] [<c013930d>]
> [<c013995a>] [<c0136863>]
> [<c0107044>] [<c0106f27>]
>
> Code: 0f 0b 83 c4 0c 8b 54 24 3c 52 8b 44 24 3c 50 57 55 e8 25 fc
> Segmentation fault
>
>
> I am also getting some reiserfs errors. I don't know if this is related with
> the other two bugs. I coud not capture the text of this last error.
>
>
> Mickey Lalescu, Application Architect
> Personus (Toronto)
> 36 Lombard Street., 3rd Floor, Toronto ON M5C 2X3
> TEL 416 941-9340 Ext. 134 FAX 416 941-9183
> EMAIL mickey@personus.com <mailto:mickey@personus.com> WEB <
> http://www.personus.com <http://www.personus.com/> >
>
>
> 1 + 1 = 3 for huge values of 1
>
>
>
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-----------------------------------------------------------------------------
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035 Web: www.aslab.com
^ permalink raw reply [relevance 82%]
* Re: [BUG] kernel BUG at slab.c:1402! -- 2.4.2-0.1.28
2001-03-22 7:36 82% ` Keith Owens
@ 2001-03-22 8:08 82% ` Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2001-03-22 8:08 UTC (permalink / raw)
To: Keith Owens; +Cc: Greg Billock, linux-kernel
Keith Owens wrote:
>
> On Wed, 21 Mar 2001 23:15:14 -0800,
> Greg Billock <greg@thebilberry.com> wrote:
> >Summary: Hotplugging a USB device causes an unrecoverable kernel Aiee!
> >
> >Copied from screen after interrupt handler killed, so sorry for
> >incompleteness. This
> >bug is reproducable so if necessary, I can try it again....
>
> The complete oops report is required, and it needs to be run through
> ksymoops. See Documentation/oops-tracing.txt.
It's a known problem, I think. USB is incompatible
with slab redzoning. Turn off `Debug memory allocation'
in the kernel hacking menu.
^ permalink raw reply [relevance 82%]
* Re: [BUG] kernel BUG at slab.c:1402! -- 2.4.2-0.1.28
2001-03-22 7:15 82% [BUG] kernel BUG at slab.c:1402! -- 2.4.2-0.1.28 Greg Billock
@ 2001-03-22 7:36 82% ` Keith Owens
2001-03-22 8:08 82% ` Andrew Morton
0 siblings, 1 reply; 200+ results
From: Keith Owens @ 2001-03-22 7:36 UTC (permalink / raw)
To: Greg Billock; +Cc: linux-kernel
On Wed, 21 Mar 2001 23:15:14 -0800,
Greg Billock <greg@thebilberry.com> wrote:
>Summary: Hotplugging a USB device causes an unrecoverable kernel Aiee!
>
>Copied from screen after interrupt handler killed, so sorry for
>incompleteness. This
>bug is reproducable so if necessary, I can try it again....
The complete oops report is required, and it needs to be run through
ksymoops. See Documentation/oops-tracing.txt.
^ permalink raw reply [relevance 82%]
* [BUG] kernel BUG at slab.c:1402! -- 2.4.2-0.1.28
@ 2001-03-22 7:15 82% Greg Billock
2001-03-22 7:36 82% ` Keith Owens
0 siblings, 1 reply; 200+ results
From: Greg Billock @ 2001-03-22 7:15 UTC (permalink / raw)
To: linux-kernel
Summary: Hotplugging a USB device causes an unrecoverable kernel Aiee!
Copied from screen after interrupt handler killed, so sorry for
incompleteness. This
bug is reproducable so if necessary, I can try it again....
kernel BUG at slab.c:1402!
invalid operand: 0000
CPU: 0
EIP: 0010: [<c012ddb4>]
EFLAGS: 00010086
eax: 1b ebx: 26d6a4 ecx: 81 edx: 14
esi: c82d3 edi: c82d3564 ebp: cdffb0a0 esp: c0289e98
ds: 18 es: 18 ss: 18
Process swapper (pid: 0, stackpage= c0289000)
.......
Kernel panic: Aiee, killing interrupt handler!
Sorry for the incomplete data. The system doesn't write anything to logs
about the crash, since it is a pretty hard one, but I can reproduce this
bug
if it hasn't been reported yet (I didn't find it in archives) or the
above is
insufficient.
More data:
AMD K6-2 400 processor, >200MB memory
Gnu C 2.96
Binutils 2.10.0.18
Linux C library 1.92.so
Procps 2.0.7
Mount 2.10m
Net-tools (2000-05-21)
sh-utils 2.0
Modules: 8139too, nls_iso8859-1, nls_cp437, vfat, fat, usb-ohci, usbcore
-Greg Billock
greg@thebilberry.com
^ permalink raw reply [relevance 82%]
* Re: [BUG] kernel BUG at printk.c:458! -- 2.4.2-ac20
@ 2001-03-18 9:19 82% ` Arnaldo Carvalho de Melo
2001-03-19 1:40 82% ` Andrew Morton
1 sibling, 0 replies; 200+ results
From: Arnaldo Carvalho de Melo @ 2001-03-18 9:19 UTC (permalink / raw)
To: BERECZ Szabolcs; +Cc: linux-kernel
Em Mon, Mar 19, 2001 at 02:14:35AM +0100, BERECZ Szabolcs escreveu:
> Hi!
>
> I was copying some files from ext2fs to reiserfs, and then this bug
> occured:
>
> kernel BUG at printk.c:458!
same thing here, two or three times, I was too lazy to write down the oops
and decode it, will try next time, and I also have reiserfs here in one
partition, 2.4.2-ac18, gcc 2.95.3 as well, further details available upon
request.
- Arnaldo
^ permalink raw reply [relevance 82%]
* Re: [BUG] kernel BUG at printk.c:458! -- 2.4.2-ac20
2001-03-18 9:19 82% ` Arnaldo Carvalho de Melo
@ 2001-03-19 1:40 82% ` Andrew Morton
1 sibling, 0 replies; 200+ results
From: Andrew Morton @ 2001-03-19 1:40 UTC (permalink / raw)
To: BERECZ Szabolcs; +Cc: linux-kernel
BERECZ Szabolcs wrote:
>
> kernel BUG at printk.c:458!
>
--- drivers/char/console.c.orig Mon Mar 19 12:38:27 2001
+++ drivers/char/console.c Mon Mar 19 12:38:49 2001
@@ -2305,6 +2305,9 @@
{
struct vt_struct *vt = (struct vt_struct *)tty->driver_data;
+ if (in_interrupt())
+ return;
+
pm_access(pm_con);
acquire_console_sem();
set_cursor(vt->vc_num);
^ permalink raw reply [relevance 82%]
* [Linux-ia64] Re: Pagesize bug vs. libpthread bug :(
@ 2001-02-12 15:35 82% Bill Nottingham
0 siblings, 0 replies; 200+ results
From: Bill Nottingham @ 2001-02-12 15:35 UTC (permalink / raw)
To: linux-ia64
Francis Galiegue (fg@mandrakesoft.com) said:
> I've succeeded in compiling and installing the CVS version of glibc dated
> 20010208, but since then all programs using libpthread segfault. This includes
> all fileutils, among others. Fortunately I have a "stable" glibc installed in
> my chroot and so can export LD_LIBRARY_PATH to point to them, so my system is
> still usable.
Take a later snapshot. Using pthreads was broken for a few days.
Bill
^ permalink raw reply [relevance 82%]
* [Linux-ia64] Pagesize bug vs. libpthread bug :(
@ 2001-02-12 12:03 82% Francis Galiegue
0 siblings, 0 replies; 200+ results
From: Francis Galiegue @ 2001-02-12 12:03 UTC (permalink / raw)
To: linux-ia64
I've succeeded in compiling and installing the CVS version of glibc dated
20010208, but since then all programs using libpthread segfault. This includes
all fileutils, among others. Fortunately I have a "stable" glibc installed in
my chroot and so can export LD_LIBRARY_PATH to point to them, so my system is
still usable.
But that won't solve at all this pagesize problem. Hence my question: is there a
patch somewhere that makes programs linked statically with libnss work (hence
rpm) applying over *stock* glibc 2.2? I hate to have to choose between two
bugs, but I'd rather have ls, mv, etc work... And I'm not knowledgeable about
glibc internals at all...
Please help :(
--
Francis Galiegue, fg@mandrakesoft.com - Normand et fier de l'être
"Programming is a race between programmers, who try and make more and more
idiot-proof software, and universe, which produces more and more remarkable
idiots. Until now, universe leads the race" -- R. Cook
^ permalink raw reply [relevance 82%]
* Re: [BUG?] AMD 5x86 and 2.4 (was Re: [BUG?] AMD K5 and 2.4)
2000-11-15 19:58 82% ` [BUG?] AMD 5x86 and 2.4 (was Re: [BUG?] AMD K5 and 2.4) Barry K. Nathan
@ 2000-11-27 1:25 82% ` Andreas Eibach
2000-11-16 11:00 82% ` Vojtech Pavlik
1 sibling, 0 replies; 200+ results
From: Andreas Eibach @ 2000-11-27 1:25 UTC (permalink / raw)
To: barryn, linux-kernel; +Cc: hahn
> It looks like I was mistaken in my original message. I have an AMD 5x86,
not
> a K5.
Careful.
AFAIK, '5x86' (without anything added) is a description for Cyrix/IBM
processors ONLY.
5x86/6x86/6x86MX are _also_ Cyrix names for CPUs.
'MMX' is a registered (!) trademark by Intel Corp., so Cyrix were obliged to
choose another name for the MMX technology (sorta) that they used in their
CPUs. They named it 'MX' and appended this to the name.
Nevertheless, you are right. You do NOT have a K5.
The *correct* name for your processor is 'Am5x86', though, which is a
trademark of AMD, by the way.
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 82%]
* Re: [KBUILD] Re: [BUG] 2.4.0-test11-ac3 breaks raid autodetect (was Re: [BUG] raid5 link error? (was [PATCH] raid5 fix after xor.c cleanup))
2000-11-27 8:12 82% ` Luca Berra
@ 2000-11-27 10:49 82% ` Christoph Hellwig
1 sibling, 0 replies; 200+ results
From: Christoph Hellwig @ 2000-11-27 10:49 UTC (permalink / raw)
To: Neil Brown
Cc: Friedrich Lobenstock, Alan Cox, linux-kbuild, linux-kernel,
linux-raid
On Mon, Nov 27, 2000 at 01:18:52PM +1100, Neil Brown wrote:
> Thanks for this....
>
> I have looked more deeply, and discovered the error of my ways.
> As the Makefiles now stand, all export-objs (OX_OBJS) get linked
> before non-export-objs (O_OBJS) in the same directory, independantly
> of any ordering imposed within the Makefile.
Yes.
> This caused md.o to get linked before raid?.o.
> Due to carelessness on my part I didn't notice this happening when I
> was testing.
>
> The following patch fixes it. I hope the change to Rules.make is
> acceptable - I have CCed to linux-kbuild incase anyone there has an
> issue with it.
I don't think so. Look at drivers/usb/Makefile for an other (cleaner)
solution to solve this. I don't think it is a good idea to solve the
same problem with two different hacks...
Christoph
--
Always remember that you are unique. Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 82%]
* Re: [BUG] 2.4.0-test11-ac3 breaks raid autodetect (was Re: [BUG] raid5 link error? (was [PATCH] raid5 fix after xor.c cleanup))
@ 2000-11-27 8:12 82% ` Luca Berra
2000-11-27 10:49 82% ` [KBUILD] " Christoph Hellwig
1 sibling, 0 replies; 200+ results
From: Luca Berra @ 2000-11-27 8:12 UTC (permalink / raw)
To: Neil Brown; +Cc: Alan Cox, linux-kernel, linux-raid
On Mon, Nov 27, 2000 at 01:18:52PM +1100, Neil Brown wrote:
> > Sorry to tell you that I just tried linux-2.4.0-test11-ac3 (which has this
> > patch) and I couldn't boot because the kernel detects the raid1 devices
> > but kicks the shortly after. I had to back out this code.
>
> Thanks for this....
>
> I have looked more deeply, and discovered the error of my ways.
also test11-ac4 contains the following patch which is broken and should
be reversed! (if xor.o is built as a module it will export the symbol
calibrate_xor_block_R??????? and require calibrate_xor_block ?!?)
anyway the only piece of code that uses calibrate_xor_block is
drivers/md/xor.c itself, so why export?
Regards,
L.
--- drivers/md/xor.c Sun Nov 26 21:35:14 2000
+++ drivers/md/xor.c.ac4.foo Sun Nov 26 21:43:52 2000
@@ -98,7 +98,7 @@
speed / 1000, speed % 1000);
}
-static int
+int
calibrate_xor_block(void)
{
void *b1, *b2;
@@ -139,5 +139,6 @@
}
MD_EXPORT_SYMBOL(xor_block);
+MD_EXPORT_SYMBOL(calibrate_xor_block);
module_init(calibrate_xor_block);
--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 82%]
* Re: [BUG?] AMD 5x86 and 2.4 (was Re: [BUG?] AMD K5 and 2.4)
2000-11-15 19:58 82% ` [BUG?] AMD 5x86 and 2.4 (was Re: [BUG?] AMD K5 and 2.4) Barry K. Nathan
2000-11-27 1:25 82% ` Andreas Eibach
@ 2000-11-16 11:00 82% ` Vojtech Pavlik
1 sibling, 0 replies; 200+ results
From: Vojtech Pavlik @ 2000-11-16 11:00 UTC (permalink / raw)
To: barryn; +Cc: linux-kernel, hahn
On Wed, Nov 15, 2000 at 11:58:27AM -0800, Barry K. Nathan wrote:
> It looks like I was mistaken in my original message. I have an AMD 5x86, not
> a K5.
>
> Nevertheless, menuconfig lists the 586 option as "586/K5/5x86/6x86/6x86MX".
> But, it fails to boot on my 5x86 and I have to compile for a 486 (for 2.4).
> As I mentioned in my previous message, the 586/... option boots with 2.2.
>
> I just noticed that, under both 2.2 and 2.4, uname -a identifies the
> machine as an i486.
>
> Should the 486 option be changed to "486/5x86" and the 586/... option
> changed to "586/K5/6x86/6x86MX"? Or is there a bug here that needs fixing?
> (IIRC, Cyrix and IBM made 5x86's as well - are those more like fast 486's
> or slow Pentiums? I don't remember. If they're like Pentiums, perhaps
> "486/AMD 5x86" and "586/non-AMD 5x86/6x86/6x86MX"...?)
If I recall correctly:
Am5x86 == AMD X5 == a very fast 486 processor with a big WB cache
Cx5x86 == IBM 5x86 == a slow Pentium-like processor in a 486 socket
So yes, for the AMD 5x86 you have to select '486'.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 82%]
* [BUG?] AMD 5x86 and 2.4 (was Re: [BUG?] AMD K5 and 2.4)
@ 2000-11-15 19:58 82% ` Barry K. Nathan
2000-11-27 1:25 82% ` Andreas Eibach
2000-11-16 11:00 82% ` Vojtech Pavlik
0 siblings, 2 replies; 200+ results
From: Barry K. Nathan @ 2000-11-15 19:58 UTC (permalink / raw)
To: linux-kernel; +Cc: hahn
It looks like I was mistaken in my original message. I have an AMD 5x86, not
a K5.
Nevertheless, menuconfig lists the 586 option as "586/K5/5x86/6x86/6x86MX".
But, it fails to boot on my 5x86 and I have to compile for a 486 (for 2.4).
As I mentioned in my previous message, the 586/... option boots with 2.2.
I just noticed that, under both 2.2 and 2.4, uname -a identifies the
machine as an i486.
Should the 486 option be changed to "486/5x86" and the 586/... option
changed to "586/K5/6x86/6x86MX"? Or is there a bug here that needs fixing?
(IIRC, Cyrix and IBM made 5x86's as well - are those more like fast 486's
or slow Pentiums? I don't remember. If they're like Pentiums, perhaps
"486/AMD 5x86" and "586/non-AMD 5x86/6x86/6x86MX"...?)
-Barry K. Nathan <barryn@pobox.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 82%]
* Re: [tulip-bug] ADMtek Comet bug
[not found] <Pine.LNX.4.21.0010171527340.2124-100000@anime.net>
@ 2000-11-03 1:26 82% ` Dan Hollis
0 siblings, 0 replies; 200+ results
From: Dan Hollis @ 2000-11-03 1:26 UTC (permalink / raw)
To: tulip-bug; +Cc: tulip, linux-kernel, linux-net
Anyone having a problem with the ADMtek Comet TX lockups, please contact
me. I believe I have found a fix but need some people to test it.
Details of this bug can be found here:
http://www.tux.org/hypermail/linux-tulip-bug/2000-Oct/0012.html
-Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 82%]
* [Fwd: [parisc-linux] Bug report]
@ 2000-09-11 15:19 82% Ryan Bradetich
0 siblings, 0 replies; 200+ results
From: Ryan Bradetich @ 2000-09-11 15:19 UTC (permalink / raw)
To: rstickel; +Cc: parisc-linux
[-- Attachment #1: Type: text/plain, Size: 6324 bytes --]
Hmm...
I sent this message out last friday, but I haven't seen it show up in my email
box.
So.... here goes again :)
- Ryan
Ryan Bradetich wrote:
> Robert,
>
> I have problems booting the 735/755 when the kernel is built with
> lasi/asp option enabled (it is enabled in the default config). If I diable
> this option, I can boot the 735/755 to a root prompt.
>
> I do not know if the kernel on the CD was built with this option, but
> you could build a newer kernel with this option diabled and try it
> for the 710.
>
> Hope this helps,
>
> -Ryan
>
> P.S. This is on my TODO list to fix after I work on the U2/UTurn
> code. If someone else is interested in taking a look at it, let me know
> and I'll pass on the little bit of information I have about this problem.
>
> Robert Stickel wrote:
>
> > Hello,
> >
> > The good news: We are really excited about the Puffin project.
> >
> > The bad news: We tried to boot an Apollo 9000/710 on your PA/Linux
> > Developer's
> > Release CD, Version 0.1 - Snapshot 2000/08/04 and never quite got to a
> > root
> > prompt (see transcript below). Should this be possible or are we
> > missing
> > something?
> >
> > Thanks for any advice,
> >
> > rstickel@mindspring.com
> > sts@minitower.gtri.gatech.edu
> >
> > Transcript of attempt to boot Apollo 9000/710 on Puffin CD. At the
> > request_irq(259, c01ec76c, 0x0, asp, c3fcd080)
> > line the systems hangs.
> >
> > (c) Copyright. Hewlett-Packard Company. 1991.
> > All rights reserved.
> >
> > PDC ROM rev. 2.0
> > IODC ROM rev. 2.0
> > 64 MB of memory configured and tested.
> >
> > Selecting a system to boot.
> > To stop selection process, press and hold the ESCAPE key.
> >
> > Selection process stopped.
> >
> > Searching for Potential Boot Devices.
> > To terminate search, press and hold the ESCAPE key.
> >
> > Device Selection Device Path Device Type
> > ----------------------------------------------------------------------------
> >
> > P0 scsi.6.0 MATSHITACD-ROM CR-8005A
> > P1 scsi.5.0 IOMEGA ZIP 100
> > P2 scsi.4.0 iomega jaz 1GB
> > P3 scsi.3.0 SEAGATE ST11200N SUN1.05
> > P4 scsi.2.0 SEAGATE ST31230N
> > P5 scsi.1.0 IBM 0662
> >
> > b) Boot from specified device
> > s) Search for bootable devices
> > a) Enter Boot Administration mode
> > x) Exit and continue boot sequence
> > ?) Help
> >
> > Select from menu: a
> > BOOT_ADMIN> info
> > ----------------------------- Hardware Configuration
> > ------------------------
> >
> > Machine model: 9000/710
> >
> > Processor Frequency = 50000000 Hz
> > I/O Subsystem Frequency = 25000000 Hz
> >
> > LAN Jumper Status: Internal ThinLAN Port selected
> >
> > Processor Revision = 3
> > System Controller Revision = 0
> > Floating Point Coprocessor Revision = 3
> >
> > Hardware Version 12288 (0x00003000)
> > Software Version 1153 (0x00000481)
> >
> > BOOT_ADMIN> boot alt
> >
> > Trying scsi.6.0
> > Boot path initialized.
> > Attempting to load IPL.
> >
> > Hard booted.
> > palo ipl bame@noam Fri Aug 4 18:36:35 MDT 2000
> > 0/vmlinux 2349352 bytes @ 0x6e8800
> > 0/palo-cmdline '0/vmlinux TERM=linux HOME=/ root=/dev/scd0'
> > Kernel: partition 0 file /vmlinux
> > ELF32 executable
> >
> > Entry 00100000 first 00100000 n 4
> > Segment 0 load 00100000 size 1511580 mediaptr 0x1000
> > Segment 1 load 00272000 size 132368 mediaptr 0x173000
> > Segment 2 load 00294000 size 86880 mediaptr 0x194000
> > Segment 3 load 002ac000 size 8192 mediaptr 0x1aa000
> > branching to kernel entry point 0x00100000
> > pdc_cons registered !
> > The Kernel has started...
> > Free memory starts at: 0xc02dc000
> > PALO command line: 'TERM=linux HOME=/ root=/dev/scd0'
> > PALO initrd 0-0
> > FP CCR was 0x0, will be set to 0xc0
> > model 00003000 00000481 00000000 00000000 78243572 00000000 00000004
> > 0000000d 00000000
> > vers 00000003
> > CPUID vers 0 rev 0
> > CPU(s): 1 x PA7000 at 50.000000 MHz
> > Searching for devices in PDC firmware... an older box...
> > Found devices:
> > 1. Stinger Optional Graphics (10) at 0xf4000000, versions 0x6, 0x0,
> > 0x77, 0x0, 0x0
> > 2. Bushmaster Core BA (11) at 0xf082f000, versions 0x6, 0x0, 0x70, 0x0,
> > 0x0
> > 3. Bushmaster Core SCSI (10) at 0xf0825000, versions 0x6, 0x0, 0x71,
> > 0x0, 0x0
> > 4. Bushmaster Core LAN (802.3) (10) at 0xf0826000, versions 0x6, 0x0,
> > 0x72, 0x0, 0x0
> > 5. Bushmaster Core HIL (10) at 0xf0821000, versions 0x6, 0x0, 0x73, 0x0,
> > 0x0
> > 6. Bushmaster Core RS-232 (10) at 0xf0823000, versions 0x6, 0x0, 0x75,
> > 0x0, 0x0
> > 7. Bushmaster Core RS-232 (10) at 0xf0822000, versions 0x6, 0x0, 0x75,
> > 0x0, 0x0
> > 8. Bushmaster Core Centronics (10) at 0xf0824000, versions 0x6, 0x0,
> > 0x74, 0x0, 0x0
> > 9. Bushmaster Audio (10) at 0xf1000000, versions 0x6, 0x0, 0x7a, 0x0,
> > 0x0
> > 10. Bushmaster (710) (0) at 0xfffbe000, versions 0x300, 0x0, 0x4, 0x0,
> > 0x81
> > 11. Bushmaster (1) at 0xfffbf000, versions 0x16, 0x0, 0x9, 0x0, 0x0
> > That's a total of 11 devices.
> > Linux version 2.3.99-pre8 (bame@noam) (gcc version 2.96 20000707
> > (experimental)) #24 Fri Aug 4 18:27:58 MDT 2000
> > initrd: 00000000-00000000
> > pagetable_init
> > On node 0 totalpages: 16384
> > zone(0): 8192 pages.
> > zone(1): 8192 pages.
> > zone(2): 0 pages.
> > trap_init
> > Calibrating delay loop... 46.08 BogoMIPS
> > Memory: 61380k available
> > Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
> > Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
> > Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
> > kmem_create: Poisoning requested, but con given - bdev_cache
> > Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
> > kmem_create: Poisoning requested, but con given - inode_cache
> > POSIX conformance testing by UNIFIX
> > ASP version 1 at 0xf0800000 found.
> > request_irq(259, c01ec76c, 0x0, asp, c3fcd080)
> >
> > ---------------------------------------------------------------------------
> > To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> > `unsubscribe' as the subject.
[-- Attachment #2: Type: message/rfc822, Size: 6343 bytes --]
From: Ryan Bradetich <rbradetich@uswest.net>
To: Robert Stickel <rstickel@mindspring.com>
Cc: parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] Bug report
Date: Fri, 08 Sep 2000 20:04:47 -0600
Message-ID: <39B99ABE.A1E2597F@uswest.net>
Robert,
I have problems booting the 735/755 when the kernel is built with
lasi/asp option enabled (it is enabled in the default config). If I diable
this option, I can boot the 735/755 to a root prompt.
I do not know if the kernel on the CD was built with this option, but
you could build a newer kernel with this option diabled and try it
for the 710.
Hope this helps,
-Ryan
P.S. This is on my TODO list to fix after I work on the U2/UTurn
code. If someone else is interested in taking a look at it, let me know
and I'll pass on the little bit of information I have about this problem.
Robert Stickel wrote:
> Hello,
>
> The good news: We are really excited about the Puffin project.
>
> The bad news: We tried to boot an Apollo 9000/710 on your PA/Linux
> Developer's
> Release CD, Version 0.1 - Snapshot 2000/08/04 and never quite got to a
> root
> prompt (see transcript below). Should this be possible or are we
> missing
> something?
>
> Thanks for any advice,
>
> rstickel@mindspring.com
> sts@minitower.gtri.gatech.edu
>
> Transcript of attempt to boot Apollo 9000/710 on Puffin CD. At the
> request_irq(259, c01ec76c, 0x0, asp, c3fcd080)
> line the systems hangs.
>
> (c) Copyright. Hewlett-Packard Company. 1991.
> All rights reserved.
>
> PDC ROM rev. 2.0
> IODC ROM rev. 2.0
> 64 MB of memory configured and tested.
>
> Selecting a system to boot.
> To stop selection process, press and hold the ESCAPE key.
>
> Selection process stopped.
>
> Searching for Potential Boot Devices.
> To terminate search, press and hold the ESCAPE key.
>
> Device Selection Device Path Device Type
> ----------------------------------------------------------------------------
>
> P0 scsi.6.0 MATSHITACD-ROM CR-8005A
> P1 scsi.5.0 IOMEGA ZIP 100
> P2 scsi.4.0 iomega jaz 1GB
> P3 scsi.3.0 SEAGATE ST11200N SUN1.05
> P4 scsi.2.0 SEAGATE ST31230N
> P5 scsi.1.0 IBM 0662
>
> b) Boot from specified device
> s) Search for bootable devices
> a) Enter Boot Administration mode
> x) Exit and continue boot sequence
> ?) Help
>
> Select from menu: a
> BOOT_ADMIN> info
> ----------------------------- Hardware Configuration
> ------------------------
>
> Machine model: 9000/710
>
> Processor Frequency = 50000000 Hz
> I/O Subsystem Frequency = 25000000 Hz
>
> LAN Jumper Status: Internal ThinLAN Port selected
>
> Processor Revision = 3
> System Controller Revision = 0
> Floating Point Coprocessor Revision = 3
>
> Hardware Version 12288 (0x00003000)
> Software Version 1153 (0x00000481)
>
> BOOT_ADMIN> boot alt
>
> Trying scsi.6.0
> Boot path initialized.
> Attempting to load IPL.
>
> Hard booted.
> palo ipl bame@noam Fri Aug 4 18:36:35 MDT 2000
> 0/vmlinux 2349352 bytes @ 0x6e8800
> 0/palo-cmdline '0/vmlinux TERM=linux HOME=/ root=/dev/scd0'
> Kernel: partition 0 file /vmlinux
> ELF32 executable
>
> Entry 00100000 first 00100000 n 4
> Segment 0 load 00100000 size 1511580 mediaptr 0x1000
> Segment 1 load 00272000 size 132368 mediaptr 0x173000
> Segment 2 load 00294000 size 86880 mediaptr 0x194000
> Segment 3 load 002ac000 size 8192 mediaptr 0x1aa000
> branching to kernel entry point 0x00100000
> pdc_cons registered !
> The Kernel has started...
> Free memory starts at: 0xc02dc000
> PALO command line: 'TERM=linux HOME=/ root=/dev/scd0'
> PALO initrd 0-0
> FP CCR was 0x0, will be set to 0xc0
> model 00003000 00000481 00000000 00000000 78243572 00000000 00000004
> 0000000d 00000000
> vers 00000003
> CPUID vers 0 rev 0
> CPU(s): 1 x PA7000 at 50.000000 MHz
> Searching for devices in PDC firmware... an older box...
> Found devices:
> 1. Stinger Optional Graphics (10) at 0xf4000000, versions 0x6, 0x0,
> 0x77, 0x0, 0x0
> 2. Bushmaster Core BA (11) at 0xf082f000, versions 0x6, 0x0, 0x70, 0x0,
> 0x0
> 3. Bushmaster Core SCSI (10) at 0xf0825000, versions 0x6, 0x0, 0x71,
> 0x0, 0x0
> 4. Bushmaster Core LAN (802.3) (10) at 0xf0826000, versions 0x6, 0x0,
> 0x72, 0x0, 0x0
> 5. Bushmaster Core HIL (10) at 0xf0821000, versions 0x6, 0x0, 0x73, 0x0,
> 0x0
> 6. Bushmaster Core RS-232 (10) at 0xf0823000, versions 0x6, 0x0, 0x75,
> 0x0, 0x0
> 7. Bushmaster Core RS-232 (10) at 0xf0822000, versions 0x6, 0x0, 0x75,
> 0x0, 0x0
> 8. Bushmaster Core Centronics (10) at 0xf0824000, versions 0x6, 0x0,
> 0x74, 0x0, 0x0
> 9. Bushmaster Audio (10) at 0xf1000000, versions 0x6, 0x0, 0x7a, 0x0,
> 0x0
> 10. Bushmaster (710) (0) at 0xfffbe000, versions 0x300, 0x0, 0x4, 0x0,
> 0x81
> 11. Bushmaster (1) at 0xfffbf000, versions 0x16, 0x0, 0x9, 0x0, 0x0
> That's a total of 11 devices.
> Linux version 2.3.99-pre8 (bame@noam) (gcc version 2.96 20000707
> (experimental)) #24 Fri Aug 4 18:27:58 MDT 2000
> initrd: 00000000-00000000
> pagetable_init
> On node 0 totalpages: 16384
> zone(0): 8192 pages.
> zone(1): 8192 pages.
> zone(2): 0 pages.
> trap_init
> Calibrating delay loop... 46.08 BogoMIPS
> Memory: 61380k available
> Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
> Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
> kmem_create: Poisoning requested, but con given - bdev_cache
> Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
> kmem_create: Poisoning requested, but con given - inode_cache
> POSIX conformance testing by UNIFIX
> ASP version 1 at 0xf0800000 found.
> request_irq(259, c01ec76c, 0x0, asp, c3fcd080)
>
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.
^ permalink raw reply [relevance 82%]
* Attempting to use SCSI tape drive triggers kernel BUG
@ 2006-03-02 5:08 82% Dave Jones
0 siblings, 0 replies; 200+ results
From: Dave Jones @ 2006-03-02 5:08 UTC (permalink / raw)
To: linux-scsi
[-- Attachment #1: Type: text/plain, Size: 85 bytes --]
This has been around for a while, and is still there with latest
rc5-git's.
Dave
[-- Attachment #2: Type: message/rfc822, Size: 6353 bytes --]
From: bugzilla@redhat.com
To: davej@redhat.com
Subject: [Bug 180389] Attempting to use SCSI tape drive triggers kernel BUG
Date: Tue, 28 Feb 2006 12:53:00 -0500
Message-ID: <200602281753.k1SHr0UF020840@www.beta.redhat.com>
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Attempting to use SCSI tape drive triggers kernel BUG
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180389
fenlason@redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO_REPORTER |ASSIGNED
Status|NEEDINFO_REPORTER |ASSIGNED
------- Additional Comments From fenlason@redhat.com 2006-02-28 12:52 EST -------
2.6.15-1.1991_FC5smp still fails
st0: Block limits 2 - 16777215 bytes.
kfree_debugcheck: out of range ptr fffffffch.
------------[ cut here ]------------
kernel BUG at mm/slab.c:2490!
invalid opcode: 0000 [#1]
SMP
last sysfs file: /block/sda/sda1/size
Modules linked in: nfsd exportfs lockd nfs_acl ipv6 ppdev autofs4 rfcomm l2cap
b
luetooth sunrpc lp parport_pc parport floppy nvram uhci_hcd st sg snd_cmipci
gam
eport snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss
snd_mixer
_oss snd_pcm snd_page_alloc matroxfb_base snd_opl3_lib matroxfb_DAC1064
snd_time
r matroxfb_accel snd_hwdep matroxfb_Ti3026 snd_mpu401_uart matroxfb_g450
snd_raw
midi g450_pll snd_seq_device snd matroxfb_misc soundcore matrox_w1 wire e100
mii
i2c_piix4 i2c_core dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd aic7xxx
scsi_t
ransport_spi sd_mod scsi_mod
CPU: 0
EIP: 0060:[<c015f311>] Not tainted VLI
EFLAGS: 00010086 (2.6.15-1.1991_FC5smp #1)
EIP is at kfree_debugcheck+0x20/0x51
eax: 00000031 ebx: 0003ffff ecx: d4018dfc edx: c0315f6d
esi: fffffffc edi: fffffffc ebp: 00000246 esp: d4018df8
ds: 007b es: 007b ss: 0068
Process amcheck (pid: 2568, threadinfo=d4018000 task=d46d03b0)
Stack: <0>c0315f6d fffffffc 00000000 dffdeb00 c015fa51 c0149d2e 00000000
dffdeb0
0
dffdcb70 00000246 c0161559 dfd6c9d0 c1770170 00000000 de613598 c0149d2e
d463cea0 c1770170 d463cea0 c016822d 00000a00 00000000 c01680e8 e0842418
Call Trace:
[<c015fa51>] cache_free_debugcheck+0x1b/0x1b9 [<c0149d2e>]
mempool_free+0x5
f/0x63
[<c0161559>] kmem_cache_free+0x2a/0x5c [<c0149d2e>]
mempool_free+0x5f/0x63
[<c016822d>] bio_free+0x25/0x30 [<c01680e8>] bio_put+0x28/0x29
[<e0842418>] scsi_execute_async+0x13f/0x317 [scsi_mod] [<e0a38677>]
st_do_s
csi+0x1d3/0x228 [st]
[<e0a3a4f9>] st_sleep_done+0x0/0x3a [st] [<e0a3c439>] st_read+0x2fb/0x78b
[
st]
[<e0a3c13e>] st_read+0x0/0x78b [st] [<c01641c9>] vfs_read+0x9f/0x13e
[<c0164615>] sys_read+0x3c/0x63 [<c0103d81>] syscall_call+0x7/0xb
Code: 26 0a cc 5e 31 c0 58 5b 5e 5f c3 56 53 89 c6 8d 98 00 00 00 40 c1 eb 0c
3b
1d 00 23 48 c0 72 15 50 68 6d 5f 31 c0 e8 16 48 fc ff <0f> 0b ba 09 cc 5e 31
c0
58 5a 6b c3 28 03 05 10 23 48 c0 8b 00
Continuing in 1 seconds.
<3>Debug: sleeping function called from invalid context at
include/linux/rwsem.
h:43
in_atomic():0, irqs_disabled():1
[<c0124881>] profile_task_exit+0x13/0x48 [<c01261a3>] do_exit+0x1c/0x6fc
[<c010526c>] register_die_notifier+0x0/0x2f [<c010584e>]
do_invalid_op+0x0/
0x9d
[<c01058df>] do_invalid_op+0x91/0x9d [<c015f311>]
kfree_debugcheck+0x20/0x5
1
[<c0123993>] vprintk+0x195/0x329 [<c0149d69>] mempool_alloc+0x37/0xd3
[<c0160050>] kmem_cache_alloc+0x7f/0x89 [<c0149d69>]
mempool_alloc+0x37/0xd
3
[<c0149d69>] mempool_alloc+0x37/0xd3 [<c01d2d5a>]
cfq_set_request+0x318/0x4
3a
[<c01048a7>] error_code+0x4f/0x54 [<c015f311>] kfree_debugcheck+0x20/0x51
[<c015fa51>] cache_free_debugcheck+0x1b/0x1b9 [<c0149d2e>]
mempool_free+0x5
f/0x63
[<c0161559>] kmem_cache_free+0x2a/0x5c [<c0149d2e>]
mempool_free+0x5f/0x63
[<c016822d>] bio_free+0x25/0x30 [<c01680e8>] bio_put+0x28/0x29
[<e0842418>] scsi_execute_async+0x13f/0x317 [scsi_mod] [<e0a38677>]
st_do_s
csi+0x1d3/0x228 [st]
[<e0a3a4f9>] st_sleep_done+0x0/0x3a [st] [<e0a3c439>] st_read+0x2fb/0x78b
[
st]
[<e0a3c13e>] st_read+0x0/0x78b [st] [<c01641c9>] vfs_read+0x9f/0x13e
[<c0164615>] sys_read+0x3c/0x63 [<c0103d81>] syscall_call+0x7/0xb
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [relevance 82%]
* [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot path [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot path [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot path
@ 2009-10-13 20:09 83% Per Strandh
0 siblings, 0 replies; 200+ results
From: Per Strandh @ 2009-10-13 20:09 UTC (permalink / raw)
To: git@vger.kernel.org
git-p4 clone (and sync) did not work if the specified depot path contained spaces.
Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.
Signed-off-by: Per Strandh <per.strandh@q-matic.se>
---
contrib/fast-import/git-p4 | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..01b6bbb 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -440,8 +440,8 @@ def originP4BranchesExist():
def p4ChangesForPaths(depotPaths, changeRange):
assert depotPaths
- output = p4_read_pipe_lines("changes " + ' '.join (["%s...%s" % (p, changeRange)
- for p in depotPaths]))
+ output = p4_read_pipe_lines("changes \"" + ' '.join (["%s...%s" % (p, changeRange)
+ for p in depotPaths]) + "\"" )
changes = {}
for line in output:
@@ -1437,10 +1437,10 @@ class P4Sync(Command):
newestRevision = 0
fileCnt = 0
- for info in p4CmdList("files "
+ for info in p4CmdList("files \""
+ ' '.join(["%s...%s"
% (p, revision)
- for p in self.depotPaths])):
+ for p in self.depotPaths]) + "\""):
if info['code'] == 'error':
sys.stderr.write("p4 returned an error: %s\n"
--
1.6.3.msysgit.0
git-p4 clone (and sync) did not work if the specified depot path contained spaces.
Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.
Signed-off-by: Per Strandh <per.strandh@q-matic.se>
---
contrib/fast-import/git-p4 | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..01b6bbb 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -440,8 +440,8 @@ def originP4BranchesExist():
def p4ChangesForPaths(depotPaths, changeRange):
assert depotPaths
- output = p4_read_pipe_lines("changes " + ' '.join (["%s...%s" % (p, changeRange)
- for p in depotPaths]))
+ output = p4_read_pipe_lines("changes \"" + ' '.join (["%s...%s" % (p, changeRange)
+ for p in depotPaths]) + "\"" )
changes = {}
for line in output:
@@ -1437,10 +1437,10 @@ class P4Sync(Command):
newestRevision = 0
fileCnt = 0
- for info in p4CmdList("files "
+ for info in p4CmdList("files \""
+ ' '.join(["%s...%s"
% (p, revision)
- for p in self.depotPaths])):
+ for p in self.depotPaths]) + "\""):
if info['code'] == 'error':
sys.stderr.write("p4 returned an error: %s\n"
--
1.6.3.msysgit.0
git-p4 clone (and sync) did not work if the specified depot path contained spaces.
Fixed by quoting the argument to the "p4 changes" and "p4 files" commands.
Signed-off-by: Per Strandh <per.strandh@q-matic.se>
---
contrib/fast-import/git-p4 | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..01b6bbb 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -440,8 +440,8 @@ def originP4BranchesExist():
def p4ChangesForPaths(depotPaths, changeRange):
assert depotPaths
- output = p4_read_pipe_lines("changes " + ' '.join (["%s...%s" % (p, changeRange)
- for p in depotPaths]))
+ output = p4_read_pipe_lines("changes \"" + ' '.join (["%s...%s" % (p, changeRange)
+ for p in depotPaths]) + "\"" )
changes = {}
for line in output:
@@ -1437,10 +1437,10 @@ class P4Sync(Command):
newestRevision = 0
fileCnt = 0
- for info in p4CmdList("files "
+ for info in p4CmdList("files \""
+ ' '.join(["%s...%s"
% (p, revision)
- for p in self.depotPaths])):
+ for p in self.depotPaths]) + "\""):
if info['code'] == 'error':
sys.stderr.write("p4 returned an error: %s\n"
--
1.6.3.msysgit.0
^ permalink raw reply related [relevance 83%]
* Bug#428234: marked as done (linux-sound-base: not empty so not removed)
[not found] ` <20070610045818.5861.54596.reportbug@jidanni2.jidanni.org>
@ 2007-09-11 20:21 83% ` Debian Bug Tracking System
0 siblings, 0 replies; 200+ results
From: Debian Bug Tracking System @ 2007-09-11 20:21 UTC (permalink / raw)
To: Elimar Riesebieter, 428234
[-- Attachment #1: Type: text/plain, Size: 738 bytes --]
Your message dated Tue, 11 Sep 2007 22:17:28 +0200
with message-id <20070911201728.GT17585@frodo.home.lxtec.de>
and subject line [Pkg-alsa-devel] Bug#428234: Bug#428234: linux-sound-base: not empty so not removed
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
[-- Attachment #2: Type: message/rfc822, Size: 2194 bytes --]
From: Dan Jacobson <jidanni@jidanni.org>
To: Debian Bug Tracking System <maintonly@bugs.debian.org>
Subject: linux-sound-base: not empty so not removed
Date: Sun, 10 Jun 2007 12:58:18 +0800
Message-ID: <20070610045818.5861.54596.reportbug@jidanni2.jidanni.org>
Package: linux-sound-base
Severity: wishlist
dpkg - warning: while removing linux-sound-base, directory `/etc/modutils' not empty so not removed.
dpkg - warning: while removing linux-sound-base, directory `/etc/hotplug' not empty so not removed.
$ find /etc/modutils /etc/hotplug -type f|xargs ls -ogtu
-rwxr-xr-x 1 249 2007-05-24 20:48 /etc/hotplug/usb/libgphoto2
-rwxr-xr-x 1 3907 2007-04-25 22:38 /etc/hotplug/usb/gpsd.hotplug
-rw-r--r-- 1 946 2007-04-25 22:38 /etc/hotplug/usb/gpsd.usermap
-rw-r--r-- 1 97 2006-10-05 21:09 /etc/modutils/apm
-rw-r--r-- 1 309 2006-09-22 23:33 /etc/hotplug/usb.usermap
-rw-r--r-- 1 38952 2006-01-09 00:20 /etc/hotplug/usb.distmap
-rwxr-xr-x 1 528 2006-01-09 00:20 /etc/hotplug/usb/ipaq
-rw-r--r-- 1 252 2005-07-29 03:37 /etc/modutils/ppp
$ find /etc/modutils /etc/hotplug -type f|xargs -n 1 dlocate
$
OK, removing by hand. If you know who they belong to, please clone this bug...
[-- Attachment #3: Type: message/rfc822, Size: 4400 bytes --]
From: Elimar Riesebieter <riesebie@lxtec.de>
To: Dan Jacobson <jidanni@jidanni.org>, 428234@bugs.debian.org
Cc: 428234-done@bugs.debian.org
Subject: [Pkg-alsa-devel] Bug#428234: Bug#428234: linux-sound-base: not empty so not removed
Date: Tue, 11 Sep 2007 22:17:28 +0200
Message-ID: <20070911201728.GT17585@frodo.home.lxtec.de>
On Sun, 10 Jun 2007 the mental interface of
Dan Jacobson told:
> Package: linux-sound-base
> Severity: wishlist
>
> dpkg - warning: while removing linux-sound-base, directory `/etc/modutils' not empty so not removed.
> dpkg - warning: while removing linux-sound-base, directory `/etc/hotplug' not empty so not removed.
> $ find /etc/modutils /etc/hotplug -type f|xargs ls -ogtu
> -rwxr-xr-x 1 249 2007-05-24 20:48 /etc/hotplug/usb/libgphoto2
> -rwxr-xr-x 1 3907 2007-04-25 22:38 /etc/hotplug/usb/gpsd.hotplug
> -rw-r--r-- 1 946 2007-04-25 22:38 /etc/hotplug/usb/gpsd.usermap
> -rw-r--r-- 1 97 2006-10-05 21:09 /etc/modutils/apm
> -rw-r--r-- 1 309 2006-09-22 23:33 /etc/hotplug/usb.usermap
> -rw-r--r-- 1 38952 2006-01-09 00:20 /etc/hotplug/usb.distmap
> -rwxr-xr-x 1 528 2006-01-09 00:20 /etc/hotplug/usb/ipaq
> -rw-r--r-- 1 252 2005-07-29 03:37 /etc/modutils/ppp
> $ find /etc/modutils /etc/hotplug -type f|xargs -n 1 dlocate
> $
Try apt-file search /etc/hotplug
> OK, removing by hand. If you know who they belong to, please clone this bug...
Ooooops! Don't do that! /etc/hotplug is a shared dir for your
system. It is true, that removing linux-sound-base won't delete that
dir, if there are other files than installed by alsa-driver reiding
within!
Anyway, this isn't a bug for any Debian package. Closed.
Elimar
--
.~.
/V\ L I N U X
/( )\ >Phear the Penguin<
^^-^^
_______________________________________________
Pkg-alsa-devel mailing list
Pkg-alsa-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-alsa-devel
[-- Attachment #4: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [relevance 83%]
* Bug#407690: marked as done (ld10k1 segfaults on 2.6.19 kernel)
[not found] ` <20070120144825.28798.9415.reportbug@nias.19.ros.03046.com>
@ 2007-09-11 20:06 84% ` Debian Bug Tracking System
0 siblings, 0 replies; 200+ results
From: Debian Bug Tracking System @ 2007-09-11 20:06 UTC (permalink / raw)
To: Elimar Riesebieter
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
Your message dated Tue, 11 Sep 2007 22:04:37 +0200
with message-id <20070911200437.GS17585@frodo.home.lxtec.de>
and subject line Bug#407690: [Pkg-alsa-devel] Bug#407690: kernel 2.6.19.2 incompatibel with debian libasound2-dev
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
[-- Attachment #2: Type: message/rfc822, Size: 3116 bytes --]
From: Markus Schulz <msc@antzsystem.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: segfault on starting ld10k1
Date: Sat, 20 Jan 2007 15:48:25 +0100
Message-ID: <20070120144825.28798.9415.reportbug@nias.19.ros.03046.com>
Package: ld10k1
Version: 1.0.13-1
Severity: grave
Justification: renders package unusable
segfaults at startup
if compiled source-package version and generated a backtrace.
(gdb) bt
#0 0xb7ef9410 in ?? ()
#1 0xbf92f5fc in ?? ()
#2 0x00000006 in ?? ()
#3 0x00006fdc in ?? ()
#4 0xb7cd69d1 in raise () from /lib/tls/i686/cmov/libc.so.6
#5 0xb7cd8219 in abort () from /lib/tls/i686/cmov/libc.so.6
#6 0xb7d0c88a in __fsetlocking () from /lib/tls/i686/cmov/libc.so.6
#7 0xb7d141df in mallopt () from /lib/tls/i686/cmov/libc.so.6
#8 0xb7d14282 in free () from /lib/tls/i686/cmov/libc.so.6
#9 0x08052264 in ld10k1_init_driver (dsp_mgr=0x8056dc0, tram_size=0) at
ld10k1_driver.c:414
#10 0x0805037c in main_loop (param=0xbf9307b8, audigy=0,
card_id=0xbf9304d8 "Live",
tram_size=0, ctlp=0x8066260) at ld10k1_fnc1.c:202
#11 0x08049e6e in main (argc=1, argv=0xbf930884) at ld10k1.c:333
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.19.2-nias
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages ld10k1 depends on:
ii libasound2 1.0.13-1 ALSA library
ii libc6 2.3.6.ds1-10 GNU C Library: Shared libraries
ii liblo10k1-0 1.0.13-1 ALSA emu10k1/2 patch-loader librar
ii lsb-base 3.1-22 Linux Standard Base 3.1 init scrip
ld10k1 recommends no packages.
-- no debconf information
[-- Attachment #3: Type: message/rfc822, Size: 3958 bytes --]
[-- Attachment #3.1.1: Type: text/plain, Size: 649 bytes --]
On Tue, 23 Jan 2007 the mental interface of
Markus Schulz told:
> Am Montag, 22. Januar 2007 23:20 schrieb Elimar Riesebieter:
> > On Mon, 22 Jan 2007 the mental interface of
> >
> > Markus Schulz told:
> > > Am Montag, 22. Januar 2007 22:34 schrieb Elimar Riesebieter:
> > > [..wrong patch..]
> > >
> > > > No, thats me ;)
> > >
> > > ok, i will try with new kernel build soon.
>
> works fine with original debian ld10k1 packages and patched
> alsa-drivers, thanks.
Forgot to close this. Included in 1.0.14 and should work fine now.
Elimar
--
You cannot propel yourself forward by
patting yourself on the back.
[-- Attachment #3.1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #4: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [relevance 84%]
* [U-Boot] [PATCH 6/6] bug.h: move runtime BUG/WARN macros into <linux/bug.h>
@ 2017-09-13 11:45 84% ` Masahiro Yamada
0 siblings, 0 replies; 200+ results
From: Masahiro Yamada @ 2017-09-13 11:45 UTC (permalink / raw)
To: u-boot
<common.h> and <linux/bug.h> define BUG(_ON) in a different way.
To avoid the conflict, they wrap the defines with #ifndef BUG,
enabling the first-included one. Horrible.
Collect them into a self-contained header <linux/bug.h> to make
these macros easier to use.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/usb/dwc3/linux-compat.h | 1 -
include/common.h | 9 +--------
include/linux/bug.h | 28 ++++++++++++++++++++++++++++
include/linux/compat.h | 15 ---------------
4 files changed, 29 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/dwc3/linux-compat.h b/drivers/usb/dwc3/linux-compat.h
index 64db4ec..5cbe377 100644
--- a/drivers/usb/dwc3/linux-compat.h
+++ b/drivers/usb/dwc3/linux-compat.h
@@ -14,7 +14,6 @@
#define WARN(val, format, arg...) debug(format, ##arg)
#define dev_WARN(dev, format, arg...) debug(format, ##arg)
-#define WARN_ON_ONCE(val) debug("Error %d\n", val)
static inline size_t strlcat(char *dest, const char *src, size_t n)
{
diff --git a/include/common.h b/include/common.h
index e66b8ff..f5344a0 100644
--- a/include/common.h
+++ b/include/common.h
@@ -23,6 +23,7 @@ typedef volatile unsigned char vu_char;
#include <time.h>
#include <asm-offsets.h>
#include <linux/bitops.h>
+#include <linux/bug.h>
#include <linux/delay.h>
#include <linux/types.h>
#include <linux/printk.h>
@@ -89,14 +90,6 @@ void __assert_fail(const char *assertion, const char *file, unsigned line,
({ if (!(x) && _DEBUG) \
__assert_fail(#x, __FILE__, __LINE__, __func__); })
-#ifndef BUG
-#define BUG() do { \
- printf("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __FUNCTION__); \
- panic("BUG!"); \
-} while (0)
-#define BUG_ON(condition) do { if (unlikely((condition)!=0)) BUG(); } while(0)
-#endif /* BUG */
-
typedef void (interrupt_handler_t)(void *);
#include <asm/u-boot.h> /* boot information for Linux kernel */
diff --git a/include/linux/bug.h b/include/linux/bug.h
index 133544c..f07bb71 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -1,6 +1,34 @@
#ifndef _LINUX_BUG_H
#define _LINUX_BUG_H
+#include <vsprintf.h> /* for panic() */
#include <linux/build_bug.h>
+#include <linux/compiler.h>
+#include <linux/printk.h>
+
+#define BUG() do { \
+ printk("BUG at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
+ panic("BUG!"); \
+} while (0)
+
+#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
+
+#define WARN_ON(condition) ({ \
+ int __ret_warn_on = !!(condition); \
+ if (unlikely(__ret_warn_on)) \
+ printk("WARNING at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
+ unlikely(__ret_warn_on); \
+})
+
+#define WARN_ON_ONCE(condition) ({ \
+ static bool __warned; \
+ int __ret_warn_once = !!(condition); \
+ \
+ if (unlikely(__ret_warn_once && !__warned)) { \
+ __warned = true; \
+ WARN_ON(1); \
+ } \
+ unlikely(__ret_warn_once); \
+})
#endif /* _LINUX_BUG_H */
diff --git a/include/linux/compat.h b/include/linux/compat.h
index bc027ad..1b3f089 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -87,21 +87,6 @@ static inline void kmem_cache_destroy(struct kmem_cache *cachep)
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
-#ifndef BUG
-#define BUG() do { \
- printf("U-Boot BUG@%s:%d!\n", __FILE__, __LINE__); \
-} while (0)
-
-#define BUG_ON(condition) do { if (condition) BUG(); } while(0)
-#endif /* BUG */
-
-#define WARN_ON(condition) ({ \
- int __ret_warn_on = !!(condition); \
- if (unlikely(__ret_warn_on)) \
- printf("WARNING in %s line %d\n", __FILE__, __LINE__); \
- unlikely(__ret_warn_on); \
-})
-
#define PAGE_SIZE 4096
/* drivers/char/random.c */
--
2.7.4
^ permalink raw reply related [relevance 84%]
* [U-Boot] [PATCH v2 7/8] bug.h: move runtime BUG/WARN macros into <linux/bug.h>
@ 2017-09-16 5:10 84% ` Masahiro Yamada
2017-10-05 21:52 90% ` [U-Boot] [U-Boot, v2, " Tom Rini
0 siblings, 1 reply; 200+ results
From: Masahiro Yamada @ 2017-09-16 5:10 UTC (permalink / raw)
To: u-boot
Collect runtime BUG/WARN into a self-contained header <linux/bug.h>
to make these macros easier to use.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v2: None
drivers/usb/dwc3/linux-compat.h | 1 -
include/common.h | 9 +--------
include/linux/bug.h | 28 ++++++++++++++++++++++++++++
include/linux/compat.h | 15 ---------------
4 files changed, 29 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/dwc3/linux-compat.h b/drivers/usb/dwc3/linux-compat.h
index 64db4ecc3c6f..5cbe377e3cd9 100644
--- a/drivers/usb/dwc3/linux-compat.h
+++ b/drivers/usb/dwc3/linux-compat.h
@@ -14,7 +14,6 @@
#define WARN(val, format, arg...) debug(format, ##arg)
#define dev_WARN(dev, format, arg...) debug(format, ##arg)
-#define WARN_ON_ONCE(val) debug("Error %d\n", val)
static inline size_t strlcat(char *dest, const char *src, size_t n)
{
diff --git a/include/common.h b/include/common.h
index 7ea78bde83f7..18963355840d 100644
--- a/include/common.h
+++ b/include/common.h
@@ -23,6 +23,7 @@ typedef volatile unsigned char vu_char;
#include <time.h>
#include <asm-offsets.h>
#include <linux/bitops.h>
+#include <linux/bug.h>
#include <linux/delay.h>
#include <linux/types.h>
#include <linux/printk.h>
@@ -90,14 +91,6 @@ void __assert_fail(const char *assertion, const char *file, unsigned line,
({ if (!(x) && _DEBUG) \
__assert_fail(#x, __FILE__, __LINE__, __func__); })
-#ifndef BUG
-#define BUG() do { \
- printf("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __FUNCTION__); \
- panic("BUG!"); \
-} while (0)
-#define BUG_ON(condition) do { if (unlikely((condition)!=0)) BUG(); } while(0)
-#endif /* BUG */
-
typedef void (interrupt_handler_t)(void *);
#include <asm/u-boot.h> /* boot information for Linux kernel */
diff --git a/include/linux/bug.h b/include/linux/bug.h
index 133544ca46f0..f07bb716fc04 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -1,6 +1,34 @@
#ifndef _LINUX_BUG_H
#define _LINUX_BUG_H
+#include <vsprintf.h> /* for panic() */
#include <linux/build_bug.h>
+#include <linux/compiler.h>
+#include <linux/printk.h>
+
+#define BUG() do { \
+ printk("BUG at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
+ panic("BUG!"); \
+} while (0)
+
+#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
+
+#define WARN_ON(condition) ({ \
+ int __ret_warn_on = !!(condition); \
+ if (unlikely(__ret_warn_on)) \
+ printk("WARNING at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
+ unlikely(__ret_warn_on); \
+})
+
+#define WARN_ON_ONCE(condition) ({ \
+ static bool __warned; \
+ int __ret_warn_once = !!(condition); \
+ \
+ if (unlikely(__ret_warn_once && !__warned)) { \
+ __warned = true; \
+ WARN_ON(1); \
+ } \
+ unlikely(__ret_warn_once); \
+})
#endif /* _LINUX_BUG_H */
diff --git a/include/linux/compat.h b/include/linux/compat.h
index bc027adcb936..1b3f089687e4 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -87,21 +87,6 @@ static inline void kmem_cache_destroy(struct kmem_cache *cachep)
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
-#ifndef BUG
-#define BUG() do { \
- printf("U-Boot BUG@%s:%d!\n", __FILE__, __LINE__); \
-} while (0)
-
-#define BUG_ON(condition) do { if (condition) BUG(); } while(0)
-#endif /* BUG */
-
-#define WARN_ON(condition) ({ \
- int __ret_warn_on = !!(condition); \
- if (unlikely(__ret_warn_on)) \
- printf("WARNING in %s line %d\n", __FILE__, __LINE__); \
- unlikely(__ret_warn_on); \
-})
-
#define PAGE_SIZE 4096
/* drivers/char/random.c */
--
2.7.4
^ permalink raw reply related [relevance 84%]
* [Bug 2195] New: Reproduced bug 1594: kernel BUG at mm/slab.c:1269
@ 2004-02-25 23:48 85% Martin J. Bligh
0 siblings, 0 replies; 200+ results
From: Martin J. Bligh @ 2004-02-25 23:48 UTC (permalink / raw)
To: linux-kernel
http://bugme.osdl.org/show_bug.cgi?id=2195
Summary: Reproduced bug 1594: kernel BUG at mm/slab.c:1269
Kernel Version: 2.6.3
Status: NEW
Severity: normal
Owner: akpm@digeo.com
Submitter: schofield@ftw.at
Distribution: Mepis / Debian sid x86
Hardware Environment: x86: Intel P4 1.6GHz
Software Environment:
gcc (GCC) 3.3.3 (Debian)
config file:
http://userver.ftw.at/~ejs/resources/config_2.6.3_kernel_bug
kernel compiled for this config file for x86:
http://userver.ftw.at/~ejs/resources/bzImage_2.6.3_kernel_bug
Patched kernel from 2.6.2 to 2.6.3 with official patch at
http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Fpatch-2.6.3.bz2.
B
Problem Description:
Same bug as #1594; line number incremented by one since 2.6.0-test10 ...
Before the 2.6.3 patch yesterday this bug did not occur. Since then it occurs
each reboot. The system has been unstable today, but I cannot isolate the cause.
Message in /var/log/messages:
...
Feb 24 11:58:44 polaris kernel: kmem_cache_create: duplicate cache dm_io
Feb 24 11:58:44 polaris kernel: ------------[ cut here ]------------
Feb 24 11:58:44 polaris kernel: kernel BUG at mm/slab.c:1269!
Feb 24 11:58:44 polaris kernel: invalid operand: 0000 [#1]
Feb 24 11:58:44 polaris kernel: CPU: 0
Feb 24 11:58:44 polaris kernel: EIP: 0060:[<c013a45c>] Not tainted
Feb 24 11:58:44 polaris kernel: EFLAGS: 00010202
Feb 24 11:58:44 polaris kernel: EIP is at kmem_cache_create+0x3ac/0x49c
Feb 24 11:58:44 polaris kernel: eax: 00000029 ebx: f7df46dc ecx: c04006f8
edx: 00000282
Feb 24 11:58:44 polaris kernel: esi: c0320502 edi: f89a2ebb ebp: f7d13cc8
esp: f797df40
Feb 24 11:58:44 polaris kernel: ds: 007b es: 007b ss: 0068
Feb 24 11:58:44 polaris kernel: Process modprobe (pid: 924, threadinfo=f797c000
task=f7cc6080)
Feb 24 11:58:44 polaris kernel: Stack: c03077a0 f89a2eb5 00000000 f797df5c f7d13
d04 c0000000 fffffffc 00000000
Feb 24 11:58:44 polaris kernel: 00000000 f797c000 f89a5c60 c034da58 f8849
03b f89a2eb5 00000010 00000080
Feb 24 11:58:44 polaris kernel: 00000000 00000000 00000000 00000000 f8849
0a9 c034da70 f797c000 f89a5f00
Feb 24 11:58:44 polaris kernel: Call Trace:
Feb 24 11:58:44 polaris kernel: [<f884903b>] local_init+0x3b/0x98 [dm_mod]
Feb 24 11:58:44 polaris kernel: [<f88490a9>] dm_init+0x11/0x3d [dm_mod]
Feb 24 11:58:44 polaris kernel: [<c0131996>] sys_init_module+0x117/0x228
Feb 24 11:58:44 polaris kernel: [<c010a86b>] syscall_call+0x7/0xb
Feb 24 11:58:44 polaris kernel:
Feb 24 11:58:44 polaris kernel: Code: 0f 0b f5 04 c7 6f 30 c0 8b 0b e9 76 ff ff
ff 8b 47 34 c7 04
...
Steps to reproduce:
Try booting with the kernel cited above, or booting from a kernel compiled with
the 2.6.3 sources and the config file given ...
^ permalink raw reply [relevance 85%]
* [bugzilla-daemon@bugzilla.kernel.org: [Bug 45621] New: Kernel ooops: BUG: unable to handle kernel paging request at 000000080000001c]
@ 2012-08-05 22:36 87% Theodore Ts'o
0 siblings, 0 replies; 200+ results
From: Theodore Ts'o @ 2012-08-05 22:36 UTC (permalink / raw)
To: linux-mm; +Cc: bugzilla-daemon
[-- Attachment #1: Type: text/plain, Size: 428 bytes --]
Hi, I'm hoping this rings a bell with an mm developer:
https://bugzilla.kernel.org/show_bug.cgi?id=45621
It looks like the user is reporting a OOPS which was caused by the
inode's mapping->page_tree having gotten corrupted. The call stack
was from a write system call while the system was undergoing heavy
I/O, on a v3.4.7 kernel.
If someone could take a quick look at this, I'd really appreciate it.
Thanks!!
- Ted
[-- Attachment #2: Type: message/rfc822, Size: 10472 bytes --]
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 45621] New: Kernel ooops: BUG: unable to handle kernel paging request at 000000080000001c
Date: Sat, 4 Aug 2012 23:33:18 +0000 (UTC)
Message-ID: <bug-45621-13602@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=45621
Summary: Kernel ooops: BUG: unable to handle kernel paging
request at 000000080000001c
Product: File System
Version: 2.5
Kernel Version: 3.4.7
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: ext4
AssignedTo: fs_ext4@kernel-bugs.osdl.org
ReportedBy: markus.doits@googlemail.com
Regression: No
During heavy io on my ext4 filesystems, I sometimes get this oops:
[10645.902287] BUG: unable to handle kernel paging request at 000000080000001c
[10645.902881] IP: [<ffffffff8110c4d1>] find_get_page+0x41/0xa0
[10645.903359] PGD 1e21cb067 PUD 0
[10645.903638] Oops: 0000 [#1] PREEMPT SMP
[10645.903986] CPU 1
[10645.904147] Modules linked in: md5 aes_x86_64 aes_generic xts gf128mul
dm_crypt dm_mod usb_storage uas nfsd exportfs tun w83627ehf hwmon_vid
iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_conntrack ip_tables x_tables rc_dib0700_rc5 dvb_usb_dib0700
dib3000mc dib8000 dib0070 dib7000m dib7000p dibx000_common dib0090 dvb_usb
dvb_core microcode i915 iTCO_wdt i2c_algo_bit drm_kms_helper intel_agp
iTCO_vendor_support drm psmouse ghash_clmulni_intel mei(C) evdev atl1c rc_core
intel_gtt pcspkr serio_raw i2c_i801 i2c_core acpi_cpufreq mperf processor
cryptd coretemp crc32c_intel video button loop fuse nfs nfs_acl lockd
auth_rpcgss sunrpc fscache ext4 crc16 jbd2 mbcache sd_mod ahci libahci ehci_hcd
xhci_hcd libata scsi_mod usbcore usb_common
[10645.910482]
[10645.910602] Pid: 2958, comm: rsync Tainted: G C 3.4.7-1-ARCH #1 To
Be Filled By O.E.M. To Be Filled By O.E.M./H61M/U3S3
[10645.911595] RIP: 0010:[<ffffffff8110c4d1>] [<ffffffff8110c4d1>]
find_get_page+0x41/0xa0
[10645.912276] RSP: 0018:ffff8801fe1eba28 EFLAGS: 00010246
[10645.912713] RAX: ffff880100ad1198 RBX: 0000000800000000 RCX:
00000000fffffffa
[10645.913303] RDX: 0000000000000001 RSI: ffff880100ad1198 RDI:
0000000000000000
[10645.913893] RBP: ffff8801fe1eba48 R08: 0000000800000000 R09:
ffff880100ad0f88
[10645.914481] R10: ffffffffa0188e00 R11: 0000000000000000 R12:
ffff88008a307058
[10645.915071] R13: 00000000000084bf R14: 000000000102005a R15:
0000000000000050
[10645.915663] FS: 00007f8c4d7f4700(0000) GS:ffff88021f280000(0000)
knlGS:0000000000000000
[10645.916333] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[10645.916807] CR2: 000000080000001c CR3: 00000001d296a000 CR4:
00000000000407e0
[10645.917393] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[10645.917985] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[10645.918574] Process rsync (pid: 2958, threadinfo ffff8801fe1ea000, task
ffff880211fcafa0)
[10645.919250] Stack:
[10645.919413] ffff8801fe1eba48 ffff88008a307050 00000000000084bf
00000000000084bf
[10645.920059] ffff8801fe1eba78 ffffffff8110c6d6 ffff8801fe1eba68
ffffffffa00558d3
[10645.920702] 0000000000000004 ffff88008a307050 ffff8801fe1ebac8
ffffffff8110cdf2
[10645.921344] Call Trace:
[10645.942181] [<ffffffff8110c6d6>] find_lock_page+0x26/0x80
[10645.963412] [<ffffffffa00558d3>] ? jbd2_journal_start+0x13/0x20 [jbd2]
[10645.984833] [<ffffffff8110cdf2>] grab_cache_page_write_begin+0x72/0x100
[10645.984853] [<ffffffffa0149bf0>] ext4_da_write_begin+0xa0/0x230 [ext4]
[10645.984858] [<ffffffffa014c47d>] ? ext4_da_write_end+0xad/0x390 [ext4]
[10645.984861] [<ffffffff8110be74>] generic_file_buffered_write+0x124/0x2b0
[10645.984864] [<ffffffff8110da4a>] __generic_file_aio_write+0x22a/0x440
[10645.984868] [<ffffffff8146775e>] ? __mutex_lock_slowpath+0x24e/0x340
[10645.984871] [<ffffffff8110dcd1>] generic_file_aio_write+0x71/0xe0
[10645.984876] [<ffffffffa014334f>] ext4_file_write+0xaf/0x260 [ext4]
[10645.984879] [<ffffffff8116e286>] do_sync_write+0xe6/0x120
[10645.984883] [<ffffffff811f8a9c>] ? security_file_permission+0x2c/0xb0
[10645.984885] [<ffffffff8116e871>] ? rw_verify_area+0x61/0xf0
[10645.984887] [<ffffffff8116eb88>] vfs_write+0xa8/0x180
[10645.984888] [<ffffffff8116eeca>] sys_write+0x4a/0xa0
[10645.984891] [<ffffffff8146aaa9>] system_call_fastpath+0x16/0x1b
[10645.984892] Code: 89 f5 4c 8d 63 08 e8 3f 8e fc ff 4c 89 ee 4c 89 e7 e8 f4
77 13 00 48 85 c0 48 89 c6 74 44 48 8b 18 48 85 db 74 22 f6 c3 03 75 3f <8b> 53
1c 85 d2 74 d9 8d 7a 01 89 d0 f0 0f b1 7b 1c 39 c2 75 26
[10645.984908] RIP [<ffffffff8110c4d1>] find_get_page+0x41/0xa0
[10645.984910] RSP <ffff8801fe1eba28>
[10645.984911] CR2: 000000080000001c
[10646.075497] ---[ end trace 9841da8b9a0cb390 ]---
Using archlinux stable.
Anything else I can do to hunt this bug down?
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [relevance 87%]
* Bug#341392: (fwd) Bug#341392: linux-2.6: kernel BUG at mm/slab.c:1807!
@ 2005-12-05 14:57 87% maximilian attems
0 siblings, 0 replies; 200+ results
From: maximilian attems @ 2005-12-05 14:57 UTC (permalink / raw)
To: netdev; +Cc: 341392, Frans Pop
please take a look at belows BUG_ON()
at a quick glance didn't find a patch for that in git-commits-list.
belows kernel has all fixes from the latest 2.6.14.3 stable.
----- Forwarded message from Frans Pop <aragorn@tiscali.nl> -----
Subject: Bug#341392: linux-2.6: kernel BUG at mm/slab.c:1807!
Date: Wed, 30 Nov 2005 13:14:02 +0100
From: Frans Pop <aragorn@tiscali.nl>
To: submit@bugs.debian.org
Package: linux-2.6
Version: 2.6.14-4
Severity: serious
The following error happens on Debian Installer boot in vmware (386 kernel).
This problem was not present in -3.
The system does come up after the error, but it looks so basic (memory
management AFAICT) that I've set RC severity anyway.
Feel free to adjust if you disagree.
Cheers,
FJP
ACPI: Processor [CPU0] (supports 8 throttling states)
kmem_cache_create: duplicate cache UNIX
------------[ cut here ]------------
kernel BUG at mm/slab.c:1807!
invalid operand: 0000 [#1]
Modules linked in: unix thermal processor fan pcnet32 mii uhci_hcd usbcore
CPU: 0
EIP: 0060:[<c013c552>] Not tainted VLI
EFLAGS: 00010202 (2.6.14-2-386)
EIP is at kmem_cache_create+0x4ea/0x64c
eax: 0000002b ebx: c9c26b4c ecx: c02f8080 edx: 0000206b
esi: c0303829 edi: ca86fde9 ebp: c9c26980 esp: c988ff38
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 1605, threadinfo=c988e000 task=c98c8a70)
Stack: c02ba8f8 ca86fde4 0000000a c9a957a0 c9c2699c ffffff80 00000080 c0000000
00000080 ca870080 ca86fd60 0804e154 ca86fde4 c02410d2 ca86fde4 0000015c
00000000 00002000 00000000 00000000 ca804000 ca870080 0804e190 0804e154
Call Trace:
[<c02410d2>] proto_register+0x56/0x1b4
[<ca804000>] af_unix_init+0x0/0x5f [unix]
[<ca80400d>] af_unix_init+0xd/0x5f [unix]
[<c012e8a1>] sys_init_module+0x99/0x16c
[<c01030dd>] syscall_call+0x7/0xb
Code: c9 fc ff ff 55 e8 0f 0e 00 00 59 e9 a9 fd ff ff 90 ff 74 24 30 68 f8 a8 2b c0 e8 6e b3
fd ff ff 05 4c 16 39 c0 0f 8e cb 15 00 00 <0f> 0b 0f 07 0d a0 2b c0 58 5a e9 d7 fd ff ff b8
00 e0 ff ff 21
<6>usbcore: registered new driver usbkbd
drivers/usb/input/usbkbd.c: :USB HID Boot Protocol keyboard driver
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
----- End forwarded message -----
^ permalink raw reply [relevance 87%]
* [PATCH]atl1e:fix bug [Bug 11454] New: atl1e - BUG: scheduling while atomic: modprobe/678/0x00000002
@ 2008-08-31 4:51 87% jie.yang
2008-08-31 5:08 90% ` Matthew Wilcox
0 siblings, 1 reply; 200+ results
From: jie.yang @ 2008-08-31 4:51 UTC (permalink / raw)
To: akpm; +Cc: bugme-daemon, harn-solo, jeff, matthew, netdev, linux-kernel,
Jie Yang
from Jie Yang <jie.yang@atheros.com>
On Saturday, August 30, 2008 5:27 AM
Andrew Morton <akpm@linux-foundation.org]>
> On Fri, 29 Aug 2008 14:08:09 -0700 (PDT)
> bugme-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=11454
> >
> > Summary: atl1e - BUG: scheduling while atomic:
> > modprobe/678/0x00000002
> > Product: Drivers
> > Version: 2.5
> > KernelVersion: 2.6.27-rc5
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: high
> > Priority: P1
> > Component: Network
> > AssignedTo: jgarzik@pobox.com
> > ReportedBy: harn-solo@gmx.de
> >
> >
> > Latest working kernel version: -
> > Earliest failing kernel version: 2.6.27-rc1
> > Software: x86_64
> >
>
> drivers/net/atl1e/atl1e_hw.c: struct atl1e_adapter *adapter
> = (struct atl1e_adapter *)hw->adapter;
> drivers/net/atl1e/atl1e_hw.c: struct atl1e_adapter *adapter
> = (struct atl1e_adapter *)hw->adapter;
> drivers/net/atl1e/atl1e_hw.c: struct atl1e_adapter *adapter
> = (struct atl1e_adapter *)hw->adapter;
>
> are unneeded and undesirable. hw->adapter already has type
> atl1e_adapter*.
>
just as Matthew Wilcox <matthew@wil.cx> mentioned:
> Lockdep warns about the mdio_lock taken with interrupts enabled then
> later taken from interrupt context. Initially, I considered changing
> these to spin_lock_irq/spin_unlock_irq, but then I looked at
> atl1e_phy_init() and saw that it calls msleep(). Sleeping while
> holding a spinlock is not allowed either.
>
> In the probe path, we haven't registered the interrupt handler, so it
> can't poke at this card yet. It's before we call register_netdev(),
> so I don't think any other threads can reach this card either. If I'm
> right, we don't need a spinlock at all.
So, just do not take mdio_lock lock in atl1e_probe, and remove the
unneeded (struct atl1e_adapter *)
Signed-off-by: Jie Yang <jie.yang@atheros.com>
---
BTW: I do not know if this format is suitable for repling [Bugme-new],
if it is not suitable, just let me know.
diff --git a/drivers/net/atl1e/atl1e_hw.c b/drivers/net/atl1e/atl1e_hw.c
index 949e753..8cbc1b5 100644
--- a/drivers/net/atl1e/atl1e_hw.c
+++ b/drivers/net/atl1e/atl1e_hw.c
@@ -397,7 +397,7 @@ static int atl1e_phy_setup_autoneg_adv(struct atl1e_hw *hw)
*/
int atl1e_phy_commit(struct atl1e_hw *hw)
{
- struct atl1e_adapter *adapter = (struct atl1e_adapter *)hw->adapter;
+ struct atl1e_adapter *adapter = hw->adapter;
struct pci_dev *pdev = adapter->pdev;
int ret_val;
u16 phy_data;
@@ -431,7 +431,7 @@ int atl1e_phy_commit(struct atl1e_hw *hw)
int atl1e_phy_init(struct atl1e_hw *hw)
{
- struct atl1e_adapter *adapter = (struct atl1e_adapter *)hw->adapter;
+ struct atl1e_adapter *adapter = hw->adapter;
struct pci_dev *pdev = adapter->pdev;
s32 ret_val;
u16 phy_val;
@@ -525,7 +525,7 @@ int atl1e_phy_init(struct atl1e_hw *hw)
*/
int atl1e_reset_hw(struct atl1e_hw *hw)
{
- struct atl1e_adapter *adapter = (struct atl1e_adapter *)hw->adapter;
+ struct atl1e_adapter *adapter = hw->adapter;
struct pci_dev *pdev = adapter->pdev;
u32 idle_status_data = 0;
diff --git a/drivers/net/atl1e/atl1e_main.c b/drivers/net/atl1e/atl1e_main.c
index 7685b99..9b60352 100644
--- a/drivers/net/atl1e/atl1e_main.c
+++ b/drivers/net/atl1e/atl1e_main.c
@@ -2390,9 +2390,7 @@ static int __devinit atl1e_probe(struct pci_dev *pdev,
}
/* Init GPHY as early as possible due to power saving issue */
- spin_lock(&adapter->mdio_lock);
atl1e_phy_init(&adapter->hw);
- spin_unlock(&adapter->mdio_lock);
/* reset the controller to
* put the device in a known good starting state */
err = atl1e_reset_hw(&adapter->hw);
^ permalink raw reply related [relevance 87%]
* Fwd: Bug#921004: downgrade to firmware-amd-graphics_20180825-1_all.deb
[not found] ` <2e69cb23-06ee-5bcd-4feb-0eb88c0f4143-GANU6spQydw@public.gmane.org>
@ 2019-01-31 16:02 88% ` Michel Dänzer
0 siblings, 0 replies; 200+ results
From: Michel Dänzer @ 2019-01-31 16:02 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
Bad news I'm afraid, looks like the latest firmware (based on
linux-firmware commit bc656509a3cfb60fcdfc905d7e23c18873e4e7b9 from
2019-01-14) broke some RX 580 cards.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
[-- Attachment #2: Bug#921004: amdgpu: The CS has been cancelled because the context is lost_.eml --]
[-- Type: message/rfc822, Size: 8922 bytes --]
From: Jean-Dominique Frattini <jd.frattini-GANU6spQydw@public.gmane.org>
To: submit-61a8vm9lEZVf4u+23C9RwQ@public.gmane.org
Subject: Bug#921004: amdgpu: The CS has been cancelled because the context is lost.
Date: Thu, 31 Jan 2019 14:40:41 +0100
Message-ID: <1c2b5af4-ea57-0b07-723d-cb4ccb760219-GANU6spQydw@public.gmane.org>
Package: xserver-xorg-video-amdgpu
Version: 18.1.0-1
Severity: critical
Debian: Stretch amd64
Regression: Yes
Graphic card: AMD Radeon Rx 580
Good Morning,
since the latest update of xserver-xorg-video-amdgpu and
firmware-amd-graphics, most GL applications do not display anything and
display this error message in the console:
amdgpu: The CS has been cancelled because the context is lost.
This makes Debian unusable for developing and running GL programs.
--
Jean-Dominique Frattini
[-- Attachment #3: Bug#921004: downgrade to firmware-amd-graphics_20180825-1_all_deb.eml --]
[-- Type: message/rfc822, Size: 9057 bytes --]
From: Jean-Dominique Frattini <jd.frattini-GANU6spQydw@public.gmane.org>
To: 921004-61a8vm9lEZVf4u+23C9RwQ@public.gmane.org
Subject: Bug#921004: downgrade to firmware-amd-graphics_20180825-1_all.deb
Date: Thu, 31 Jan 2019 15:07:45 +0100
Message-ID: <2e69cb23-06ee-5bcd-4feb-0eb88c0f4143-GANU6spQydw@public.gmane.org>
Good Morning,
downgrading to firmware-amd-graphics_20180825-1_all.deb seems to fix the
issue.
Please let me know if I should report this bug directly to
firmware-amd-graphics.
[-- Attachment #4: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [relevance 88%]
* Re: [Bugme-new] [Bug 19942] New: Not a intel bug: kernel BUG at drivers/pci/intel-iommu.c:1656
[not found] <bug-19942-10286@https.bugzilla.kernel.org/>
@ 2010-10-11 20:45 89% ` Andrew Morton
0 siblings, 0 replies; 200+ results
From: Andrew Morton @ 2010-10-11 20:45 UTC (permalink / raw)
To: gronslet
Cc: e1000-devel, netdev, bugzilla-daemon, Jesse Barnes, bugme-daemon,
David Woodhouse
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sat, 9 Oct 2010 10:07:15 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=19942
>
> Summary: Not a intel bug: kernel BUG at
> drivers/pci/intel-iommu.c:1656
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.36-0.35.rc7.git0.fc15.x86_64
> Platform: All
> OS/Version: Linux
> Tree: Fedora
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: gronslet@gmail.com
> Regression: No
>
>
> On my Fedora Rawhide system, I keep getting these errors, which kills my wifi
> and require me to reboot my Lenovo Thinkpad T400. Please also see
> https://bugzilla.redhat.com/show_bug.cgi?id=637554
> https://bugs.freedesktop.org/show_bug.cgi?id=30722
>
> In the latter, I was asked to file the bug here, as it isn't a intel bug.
> Fedora Rawhide, kernel-2.6.36-0.35.rc7.git0.fc15.x86_64,
> xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64, xorg-x11-drivers-7.4-1.fc14.x86_64
> xorg-x11-server-utils-7.4-20.fc15.x86_64,
> NetworkManager-0.8.1-7.git20100831.fc15.x86_64
>
> This happens when I resume my laptop after suspend to ram:
>
> [24572.218077] PM: resume devices took 0.987 seconds
> [24572.239068] PM: Finishing wakeup.
> [24572.239216] Restarting tasks ...
> [24572.239332] usb 2-4: USB disconnect, address 2
> [24572.245520] done.
> [24572.245702] video LNXVIDEO:00: Restoring backlight state
> [24572.249109] ehci_hcd 0000:00:1d.7: dma_pool_free buffer-2048,
> ffff880134f9d000/ffffb000 (bad dma)
> [24572.249631] ehci_hcd 0000:00:1d.7: dma_pool_free buffer-2048,
> ffff880134f9d080/ffffb080 (bad dma)
> [24572.249977] cdc_ether 2-4:1.7: wwan0: unregister 'cdc_ether'
> usb-0000:00:1d.7-4, Mobile Broadband Network Device
> [24573.685674] ------------[ cut here ]------------
> [24573.685709] kernel BUG at drivers/pci/intel-iommu.c:1656!
> [24573.685734] invalid opcode: 0000 [#1] SMP
> [24573.685761] last sysfs file: /sys/devices/system/cpu/sched_mc_power_savings
> [24573.685791] CPU 0
> [24573.685803] Modules linked in: rfcomm sunrpc sco bnep l2cap cpufreq_ondemand
> acpi_cpufreq freq_table mperf ip6t_REJECT xt_physdev nf_conntrack_ipv6
> ip6table_filter ipt_MASQUERADE iptable_nat ip6_tables nf_nat sha256_generic
> cryptd aes_x86_64 aes_generic cbc dm_crypt uinput arc4 ecb
> snd_hda_codec_conexant snd_hda_intel iwlagn snd_hda_codec snd_hwdep zaurus
> iwlcore snd_seq snd_seq_device r852 sm_common cdc_ether nand nand_ids nand_ecc
> microcode mac80211 uvcvideo usbnet mtd mii cdc_acm snd_pcm btusb cdc_wdm
> bluetooth videodev iTCO_wdt i2c_i801 iTCO_vendor_support joydev cfg80211
> thinkpad_acpi v4l1_compat v4l2_compat_ioctl32 e1000e snd_timer rfkill
> snd_page_alloc wmi snd soundcore ipv6 sdhci_pci sdhci firewire_ohci mmc_core
> firewire_core yenta_socket crc_itu_t i915 drm_kms_helper drm i2c_algo_bit
> i2c_core video output [last unloaded: scsi_wait_scan]
> [24573.686007]
> [24573.686007] Pid: 8321, comm: NetworkManager Not tainted
> 2.6.36-0.35.rc7.git0.fc15.x86_64 #1 6474AR4/6474AR4
> [24573.686007] RIP: 0010:[<ffffffff8126ea48>] [<ffffffff8126ea48>]
> __domain_mapping+0x43/0x1ce
> [24573.686007] RSP: 0018:ffff880133727648 EFLAGS: 00010206
> [24573.694051] RAX: 0000000001ffffff RBX: ffff8800b4687400 RCX:
> 000000000000001b
> [24573.694051] RDX: 000000000008b621 RSI: 000ffffffffffdff RDI:
> ffff8801320f6dc0
> [24573.694051] RBP: ffff880133727698 R08: 0000000000000001 R09:
> 0000000000000003
> [24573.694051] R10: ffff8801320f6df8 R11: 0000000000000000 R12:
> 0000000000000000
> [24573.694051] R13: ffff8801320f6dc0 R14: ffff88013bc04ff8 R15:
> 0000000000000001
> [24573.694051] FS: 00007fb24c872800(0000) GS:ffff880002c00000(0000)
> knlGS:0000000000000000
> [24573.694051] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [24573.694051] CR2: 000000000042da00 CR3: 000000012fbc2000 CR4:
> 00000000000006f0
> [24573.694051] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [24573.694051] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [24573.694051] Process NetworkManager (pid: 8321, threadinfo ffff880133726000,
> task ffff88012f8f0000)
> [24573.694051] Stack:
> [24573.694051] ffff88013707e240 ffff8801320f6dc0 ffff880133727698
> 000ffffffffffdff
> [24573.694051] <0> 0000000000000000 ffff8800b4687400 000000008b621000
> ffff8801320f6dc0
> [24573.694051] <0> ffff88013bc04ff8 0000000000000000 ffff8801337276f8
> ffffffff8126f710
> [24573.694051] Call Trace:
> [24573.694051] [<ffffffff8126f710>] __intel_map_single.clone.25+0xdc/0x16b
> [24573.694051] [<ffffffff8126f88c>] intel_alloc_coherent+0xae/0xd5
> [24573.694051] [<ffffffffa018c128>] e1000_alloc_ring_dma.clone.28+0x94/0xc0
> [e1000e]
> [24573.694051] [<ffffffffa018e359>] e1000e_setup_tx_resources+0x65/0xaa
> [e1000e]
> [24573.694051] [<ffffffffa018e891>] e1000_open+0x64/0x41e [e1000e]
> [24573.694051] [<ffffffff813eeb45>] __dev_open+0x9b/0xd2
> [24573.694051] [<ffffffff813eed87>] __dev_change_flags+0xad/0x130
> [24573.694051] [<ffffffff813eee8b>] dev_change_flags+0x21/0x56
> [24573.694051] [<ffffffff813f90f9>] do_setlink+0x2ba/0x61f
> [24573.694051] [<ffffffff8107d8c7>] ? print_lock_contention_bug+0x1b/0xd5
> [24573.694051] [<ffffffff81249f7f>] ? debug_check_no_obj_freed+0x65/0x18a
> [24573.694051] [<ffffffff8107d8c7>] ? print_lock_contention_bug+0x1b/0xd5
> [24573.694051] [<ffffffff813f96be>] rtnl_setlink+0xd0/0xf2
> [24573.694051] [<ffffffff813f99ac>] rtnetlink_rcv_msg+0x1eb/0x201
> [24573.694051] [<ffffffff813f97c1>] ? rtnetlink_rcv_msg+0x0/0x201
> [24573.694051] [<ffffffff8140d3e5>] netlink_rcv_skb+0x45/0x90
> [24573.694051] [<ffffffff813f8d29>] rtnetlink_rcv+0x26/0x2d
> [24573.694051] [<ffffffff8140cec0>] netlink_unicast+0xee/0x157
> [24573.694051] [<ffffffff8140d1e1>] netlink_sendmsg+0x2b8/0x2d6
> [24573.694051] [<ffffffff813da64e>] __sock_sendmsg+0x6b/0x77
> [24573.694051] [<ffffffff813da9a8>] sock_sendmsg+0xa8/0xc1
> [24573.694051] [<ffffffff8107ff07>] ? lock_acquire+0xee/0xfd
> [24573.694051] [<ffffffff810fb080>] ? might_fault+0x5c/0xac
> [24573.694051] [<ffffffff8107fe0d>] ? lock_release+0x19a/0x1a6
> [24573.694051] [<ffffffff810fb0c9>] ? might_fault+0xa5/0xac
> [24573.694051] [<ffffffff813e4dbb>] ? copy_from_user+0x2f/0x31
> [24573.694051] [<ffffffff813e51ae>] ? verify_iovec+0x57/0x99
> [24573.694051] [<ffffffff813dc971>] sys_sendmsg+0x235/0x2b3
> [24573.694051] [<ffffffff8112bb26>] ? rcu_read_lock+0x0/0x35
> [24573.694051] [<ffffffff8107ff07>] ? lock_acquire+0xee/0xfd
> [24573.694051] [<ffffffff8112bb26>] ? rcu_read_lock+0x0/0x35
> [24573.694051] [<ffffffff813dc405>] ? sys_sendto+0x125/0x152
> [24573.694051] [<ffffffff8112c5a2>] ? fput+0x22/0x1d6
> [24573.694051] [<ffffffff8112c4ae>] ? fget_light+0x79/0x83
> [24573.694051] [<ffffffff81133e5b>] ? path_put+0x22/0x27
> [24573.694051] [<ffffffff810a8443>] ? audit_syscall_entry+0x11c/0x148
> [24573.694051] [<ffffffff8149da45>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [24573.694051] [<ffffffff81009cf2>] system_call_fastpath+0x16/0x1b
> [24573.694051] Code: d4 48 89 ca 48 89 7d b8 6b 8f 84 00 00 00 09 48 89 75 c8
> 4d 89 c7 83 c1 12 83 f9 3f 7f 0f 4a 8d 44 06 ff 48 d3 e8 48 85 c0 74 02 <0f> 0b
> 41 f6 c1 03 b8 ea ff ff ff 0f 84 6b 01 00 00 41 81 e1 03
> [24573.694051] RIP [<ffffffff8126ea48>] __domain_mapping+0x43/0x1ce
> [24573.694051] RSP <ffff880133727648>
> [24573.821392] ---[ end trace 391efc8948e1496b ]---
> [24573.832050] NetworkManager used greatest stack depth: 2064 bytes left
> [24574.026042] usb 4-2: new full speed USB device using uhci_hcd and address 3
> [24574.187102] usb 4-2: New USB device found, idVendor=0a5c, idProduct=2145
> [24574.188244] usb 4-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [24574.189418] usb 4-2: Product: ThinkPad Bluetooth with Enhanced Data Rate II
> [24574.190567] usb 4-2: Manufacturer: Lenovo Computer Corp
> [24576.230085] usb 2-4: new high speed USB device using ehci_hcd and address 3
> [24577.080715] usb 2-4: New USB device found, idVendor=0bdb, idProduct=1900
> [24577.081862] usb 2-4: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [24577.083009] usb 2-4: Product: Ericsson F3507g Mobile Broadband Minicard
> Composite Device
> [24577.084140] usb 2-4: Manufacturer: Ericsson
> [24577.085263] usb 2-4: SerialNumber: 3541430207407750
> [24577.144202] cdc_acm 2-4:1.1: ttyACM0: USB ACM device
> [24577.163044] cdc_acm 2-4:1.3: ttyACM1: USB ACM device
> [24577.174389] cdc_wdm 2-4:1.5: cdc-wdm0: USB WDM device
> [24577.183588] cdc_wdm 2-4:1.6: cdc-wdm1: USB WDM device
> [26974.894966] thinkpad_acpi: EC reports that Thermal Table has changed
>
>
> Note that I explicitly have disabled iommu for intel:
> # cat /proc/cmdline
> ro root=/dev/VolGroup00/lv_root rhgb quiet selinux=0 vga=0x318
> SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=no intel_iommu=igfx_off
>
> I've seen this on 2.6.36-0.35.rc7.git0.fc15.x86_64,
> 2.6.36-0.27.rc5.git6.fc15.x86_64,2.6.36-0.32.rc6.git2.fc15.x86_64.
I don't have any of those kernel versions here, but I'm guessing that
this test is triggering:
BUG_ON(addr_width < BITS_PER_LONG && (iov_pfn + nr_pages - 1) >> addr_width);
It could be that e1000e is feeding in garbage, or it could be that
intel-iommu is screwed up.
It's a bit hard to tell what's happening because that BUG_ON was quite
poorly thought out. It tests three different variables, doesn't tell
us their values and even though it _could_ cleanly recover and allow
the machine to continue to operate it simply whacks the box.
So we now have a pickle on our hands, because you use prebuilt kernels
and are probably not in a position to test patches.
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply [relevance 89%]
* [STABLE][PATCH 1/1] u-boot-bug: Added U-Boot for BUG (from BUG Labs SVN)
@ 2009-05-05 10:28 89% ` Marcin Juszkiewicz
2009-05-05 11:25 90% ` Philip Balister
0 siblings, 1 reply; 200+ results
From: Marcin Juszkiewicz @ 2009-05-05 10:28 UTC (permalink / raw)
To: openembedded-devel; +Cc: Marcin Juszkiewicz
From: Marcin Juszkiewicz <marcin@buglabs.net>
Signed-off-by: Marcin Juszkiewicz <marcin@buglabs.net>
---
conf/distro/include/sane-srcrevs.inc | 1 +
recipes/u-boot/u-boot-bug_svn.bb | 37 ++++++++++++++++++++++++++++++++++
2 files changed, 38 insertions(+), 0 deletions(-)
create mode 100644 recipes/u-boot/u-boot-bug_svn.bb
diff --git a/conf/distro/include/sane-srcrevs.inc b/conf/distro/include/sane-srcrevs.inc
index 64781eb..d924070 100644
--- a/conf/distro/include/sane-srcrevs.inc
+++ b/conf/distro/include/sane-srcrevs.inc
@@ -239,6 +239,7 @@ SRCREV_pn-table ?= "2191"
SRCREV_pn-tichy ?= "ab68d849502009cf3214df48ffa8075a10cc2177"
SRCREV_pn-tmut ?= "60"
SRCREV_pn-toscoterm ?= "f02add76f365a2fecd2dbefc230ceaab20244f96"
+SRCREV_pn-u-boot-bug ?= "8674"
SRCREV_pn-u-boot-openmoko ?= "650149a53dbdd48bf6dfef90930c8ab182adb512"
SRCREV_pn-u-boot-openmoko-devel ?= "ba029a1426bfca169572bf80d50a8b190a6b0e19"
SRCREV_pn-uclibc ?= "25712"
diff --git a/recipes/u-boot/u-boot-bug_svn.bb b/recipes/u-boot/u-boot-bug_svn.bb
new file mode 100644
index 0000000..c1930f4
--- /dev/null
+++ b/recipes/u-boot/u-boot-bug_svn.bb
@@ -0,0 +1,37 @@
+DESCRIPTION = "U-boot bootloader w/ BUG support"
+LICENSE = "GPL"
+SECTION = "bootloader"
+PRIORITY = "optional"
+PV = "1.3.2+svnr${SRCREV}"
+SRCREV = "${AUTOREV}"
+PR = "r6"
+
+SRC_URI = "\
+ svn://svn.buglabs.net/bug/branches/R1.4/qa;module=u-boot;proto=svn \
+"
+S = "${WORKDIR}/u-boot"
+
+COMPATIBLE_MACHINE = "bug"
+PACKAGE_ARCH = "${MACHINE}"
+
+EXTRA_OEMAKE = "CROSS_COMPILE=${TARGET_PREFIX}"
+TARGET_LDFLAGS = ""
+
+do_compile () {
+ oe_runmake mx31_bug2_config
+ oe_runmake clean
+ oe_runmake all
+}
+
+do_deploy () {
+ install -d ${DEPLOY_DIR_IMAGE}
+ install -m 0644 ${S}/u-boot.bin ${DEPLOY_DIR_IMAGE}/u-boot-${PV}-${PR}.bin
+ ln -sf ${DEPLOY_DIR_IMAGE}/u-boot-${PV}-${PR}.bin ${DEPLOY_DIR_IMAGE}/uboot-latest.bin
+}
+
+do_stage() {
+ install -m 0755 tools/mkimage ${STAGING_BINDIR_NATIVE}/mkimage
+}
+
+do_deploy[dirs] = "${S}"
+addtask deploy before do_package after do_install
--
1.6.3.rc0
^ permalink raw reply related [relevance 89%]
* RE: [PATCH]atl1e:fix bug [Bug 11454] New: atl1e - BUG: scheduling while atomic: modprobe/678/0x00000002
2008-08-31 5:08 90% ` Matthew Wilcox
@ 2008-08-31 5:31 89% ` Jie Yang
0 siblings, 0 replies; 200+ results
From: Jie Yang @ 2008-08-31 5:31 UTC (permalink / raw)
To: Matthew Wilcox
Cc: akpm@linux-foundation.org, bugme-daemon@bugzilla.kernel.org,
harn-solo@gmx.de, jeff@garzik.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
On Sunday, August 31, 2008 1:09 PM
Matthew Wilcox <matthew@wil.cx> wrote:
> How about taking my original patch, sent August 12th instead?
> That has a good changelog and proper attribution. The
> removal of the unnecessary casts can be a separate message.
>
> If you weren't cc'd on the patch (Jeff was), you can pick it
> up from netdev.
>
Yes, I do have the patch, should I resend with Signed-off-by: Matthew Wilcox <willy@linux.intel.com>.
for that patch may have conflicts now.
the origin patch:
diff --git a/drivers/net/atl1e/atl1e_main.c b/drivers/net/atl1e/atl1e_main.c index 82d7be1..ba22a51 100644
--- a/drivers/net/atl1e/atl1e_main.c
+++ b/drivers/net/atl1e/atl1e_main.c
@@ -2389,9 +2389,7 @@ static int __devinit atl1e_probe(struct pci_dev *pdev,
}
/* Init GPHY as early as possible due to power saving issue */
- spin_lock(&adapter->mdio_lock);
atl1e_phy_init(&adapter->hw);
- spin_unlock(&adapter->mdio_lock);
/* reset the controller to
* put the device in a known good starting state */
err = atl1e_reset_hw(&adapter->hw);
the new one:
diff --git a/drivers/net/atl1e/atl1e_main.c b/drivers/net/atl1e/atl1e_main.c
index 7685b99..9b60352 100644
--- a/drivers/net/atl1e/atl1e_main.c
+++ b/drivers/net/atl1e/atl1e_main.c
@@ -2390,9 +2390,7 @@ static int __devinit atl1e_probe(struct pci_dev *pdev,
}
/* Init GPHY as early as possible due to power saving issue */
- spin_lock(&adapter->mdio_lock);
atl1e_phy_init(&adapter->hw);
- spin_unlock(&adapter->mdio_lock);
/* reset the controller to
* put the device in a known good starting state */
err = atl1e_reset_hw(&adapter->hw);
the line num changed from 2389 to 2390. :(
Best wishes
jie
^ permalink raw reply related [relevance 89%]
* [Bug 110972] bug bug
[not found] <bug-110972-502@http.bugs.freedesktop.org/>
@ 2019-06-23 22:20 90% ` bugzilla-daemon
2019-06-23 14:02 90% ` bugzilla-daemon
1 sibling, 0 replies; 200+ results
From: bugzilla-daemon @ 2019-06-23 22:20 UTC (permalink / raw)
To: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 685 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=110972
Andre Klapper <a9016009@gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Component|General |Two
Product|DRI |Spam
Group| |spam
Resolution|--- |INVALID
--- Comment #1 from Andre Klapper <a9016009@gmx.de> ---
Go away and test somewhere else.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2418 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [relevance 90%]
* [Bug 110972] bug bug
[not found] <bug-110972-502@http.bugs.freedesktop.org/>
2019-06-23 22:20 90% ` [Bug 110972] bug bug bugzilla-daemon
@ 2019-06-23 14:02 90% ` bugzilla-daemon
1 sibling, 0 replies; 200+ results
From: bugzilla-daemon @ 2019-06-23 14:02 UTC (permalink / raw)
To: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 440 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=110972
Vaishnavi <vailoke22@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |vailoke22@gmail.com
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1222 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [relevance 90%]
* [U-Boot] [U-Boot, v2, 7/8] bug.h: move runtime BUG/WARN macros into <linux/bug.h>
2017-09-16 5:10 84% ` [U-Boot] [PATCH v2 7/8] bug.h: move runtime BUG/WARN macros into <linux/bug.h> Masahiro Yamada
@ 2017-10-05 21:52 90% ` Tom Rini
0 siblings, 0 replies; 200+ results
From: Tom Rini @ 2017-10-05 21:52 UTC (permalink / raw)
To: u-boot
On Sat, Sep 16, 2017 at 02:10:45PM +0900, Masahiro Yamada wrote:
> Collect runtime BUG/WARN into a self-contained header <linux/bug.h>
> to make these macros easier to use.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Applied to u-boot/master, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171005/b76c03f9/attachment.sig>
^ permalink raw reply [relevance 90%]
* Bug is a rework idea and not a bug for Bug Id 72851 on Bugzilla
@ 2014-06-16 3:02 90% ` Nick Krause
0 siblings, 0 replies; 200+ results
From: Nick Krause @ 2014-06-16 3:02 UTC (permalink / raw)
To: linux; +Cc: grant.likely, robh+dt, linux-arm-kernel, linux-kernel, devicetree
This bug based on the comments around it seems to need to closes
due to it being a code rework and not a bug. The If for the bug on
the Bugzilla is 72851 as stated in the bug log is that it's a code
rework idea and not a bug.
Cheers Nick
^ permalink raw reply [relevance 90%]
* Bug is a rework idea and not a bug for Bug Id 72851 on Bugzilla
@ 2014-06-16 3:02 90% ` Nick Krause
0 siblings, 0 replies; 200+ results
From: Nick Krause @ 2014-06-16 3:02 UTC (permalink / raw)
To: linux-arm-kernel
This bug based on the comments around it seems to need to closes
due to it being a code rework and not a bug. The If for the bug on
the Bugzilla is 72851 as stated in the bug log is that it's a code
rework idea and not a bug.
Cheers Nick
^ permalink raw reply [relevance 90%]
* Bug is a rework idea and not a bug for Bug Id 72851 on Bugzilla
@ 2014-06-16 3:02 90% ` Nick Krause
0 siblings, 0 replies; 200+ results
From: Nick Krause @ 2014-06-16 3:02 UTC (permalink / raw)
To: linux-lFZ/pmaqli7XmaaqVzeoHQ
Cc: grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
This bug based on the comments around it seems to need to closes
due to it being a code rework and not a bug. The If for the bug on
the Bugzilla is 72851 as stated in the bug log is that it's a code
rework idea and not a bug.
Cheers Nick
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [relevance 90%]
* [Bug 45941] BUG: soft lockup - CPU#1 stuck for 21s! [kworker/1:1:64] BUG: soft lockup - CPU#4 stuck for 22s! [flush-252:0:384]
[not found] <bug-45941-13602@https.bugzilla.kernel.org/>
2012-08-14 11:43 90% ` [Bug 45941] BUG: soft lockup - CPU#1 stuck for 21s! [kworker/1:1:64] BUG: soft lockup - CPU#4 stuck for 22s! [flush-252:0:384] bugzilla-daemon
@ 2013-11-19 23:36 90% ` bugzilla-daemon
2012-08-24 10:05 90% ` bugzilla-daemon
2 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2013-11-19 23:36 UTC (permalink / raw)
To: linux-ext4
https://bugzilla.kernel.org/show_bug.cgi?id=45941
Alan <alan@lxorguk.ukuu.org.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [relevance 90%]
* [Bug 45941] BUG: soft lockup - CPU#1 stuck for 21s! [kworker/1:1:64] BUG: soft lockup - CPU#4 stuck for 22s! [flush-252:0:384]
[not found] <bug-45941-13602@https.bugzilla.kernel.org/>
2012-08-14 11:43 90% ` [Bug 45941] BUG: soft lockup - CPU#1 stuck for 21s! [kworker/1:1:64] BUG: soft lockup - CPU#4 stuck for 22s! [flush-252:0:384] bugzilla-daemon
2013-11-19 23:36 90% ` bugzilla-daemon
@ 2012-08-24 10:05 90% ` bugzilla-daemon
2 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2012-08-24 10:05 UTC (permalink / raw)
To: linux-ext4
https://bugzilla.kernel.org/show_bug.cgi?id=45941
--- Comment #3 from Loris Luise <loris.luise@gmail.com> 2012-08-24 10:05:12 ---
I made 2 modifications on the server running linux and currently no more soft
lockup has happened
1) removed irqbalance daemon from ubuntu server
2) unchecked "Synchronize guest time with host" from VM setting (VMWare esx)
Modification 1) most probably solved the problem.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [relevance 90%]
* [Bug 45941] BUG: soft lockup - CPU#1 stuck for 21s! [kworker/1:1:64] BUG: soft lockup - CPU#4 stuck for 22s! [flush-252:0:384]
[not found] <bug-45941-13602@https.bugzilla.kernel.org/>
@ 2012-08-14 11:43 90% ` bugzilla-daemon
2013-11-19 23:36 90% ` bugzilla-daemon
2012-08-24 10:05 90% ` bugzilla-daemon
2 siblings, 0 replies; 200+ results
From: bugzilla-daemon @ 2012-08-14 11:43 UTC (permalink / raw)
To: linux-ext4
https://bugzilla.kernel.org/show_bug.cgi?id=45941
Alan <alan@lxorguk.ukuu.org.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |alan@lxorguk.ukuu.org.uk
Component|Other |ext4
Kernel Version|Linux 3.5.1-030501-generic |3.5.1
|#201208091310 SMP |
AssignedTo|other_other@kernel-bugs.osd |fs_ext4@kernel-bugs.osdl.or
|l.org |g
Product|Other |File System
--- Comment #1 from Alan <alan@lxorguk.ukuu.org.uk> 2012-08-14 11:43:28 ---
This looks like an I/O never completed but it may be a pointer to something
else (eg sys_readahead/ext4 interaction). Assigning to the ext4 folk see if
they have any thoughts but thats half guesswork 8)
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply [relevance 90%]
* [Bug #42850] [BUG] Kernel Bug at fs/btrfs/volumes.c:3638
@ 2012-03-11 21:31 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2012-03-11 21:31 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Florian Mickler,
Nageswara R Sastry
This message has been generated automatically as a part of a summary report
of recent regressions.
The following bug entry is on the current list of known regressions
from 3.2. Please verify if it still should be listed and let the tracking team
know (either way).
Bug-Entry : https://bugzilla.kernel.org/show_bug.cgi?id=42850
Subject : [BUG] Kernel Bug at fs/btrfs/volumes.c:3638
Submitter : Nageswara R Sastry <rnsastry@linux.vnet.ibm.com>
Date : 2012-02-24 10:53 (17 days old)
Message-ID : <4F476959.2010400@linux.vnet.ibm.com>
References : http://marc.info/?l=linux-kernel&m=133008013332251&w=2
^ permalink raw reply [relevance 90%]
* [Bug #42850] [BUG] Kernel Bug at fs/btrfs/volumes.c:3638
@ 2012-03-11 21:31 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2012-03-11 21:31 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Florian Mickler,
Nageswara R Sastry
This message has been generated automatically as a part of a summary report
of recent regressions.
The following bug entry is on the current list of known regressions
from 3.2. Please verify if it still should be listed and let the tracking team
know (either way).
Bug-Entry : https://bugzilla.kernel.org/show_bug.cgi?id=42850
Subject : [BUG] Kernel Bug at fs/btrfs/volumes.c:3638
Submitter : Nageswara R Sastry <rnsastry-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Date : 2012-02-24 10:53 (17 days old)
Message-ID : <4F476959.2010400-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=133008013332251&w=2
^ permalink raw reply [relevance 90%]
* [Bug #42850] [BUG] Kernel Bug at fs/btrfs/volumes.c:3638
@ 2012-03-04 20:31 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2012-03-04 20:31 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Florian Mickler,
Nageswara R Sastry
This message has been generated automatically as a part of a summary report
of recent regressions.
The following bug entry is on the current list of known regressions
from 3.2. Please verify if it still should be listed and let the tracking team
know (either way).
Bug-Entry : https://bugzilla.kernel.org/show_bug.cgi?id=42850
Subject : [BUG] Kernel Bug at fs/btrfs/volumes.c:3638
Submitter : Nageswara R Sastry <rnsastry@linux.vnet.ibm.com>
Date : 2012-02-24 10:53 (10 days old)
Message-ID : <4F476959.2010400@linux.vnet.ibm.com>
References : http://marc.info/?l=linux-kernel&m=133008013332251&w=2
^ permalink raw reply [relevance 90%]
* [Bug #42850] [BUG] Kernel Bug at fs/btrfs/volumes.c:3638
@ 2012-03-04 20:31 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2012-03-04 20:31 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Florian Mickler,
Nageswara R Sastry
This message has been generated automatically as a part of a summary report
of recent regressions.
The following bug entry is on the current list of known regressions
from 3.2. Please verify if it still should be listed and let the tracking team
know (either way).
Bug-Entry : https://bugzilla.kernel.org/show_bug.cgi?id=42850
Subject : [BUG] Kernel Bug at fs/btrfs/volumes.c:3638
Submitter : Nageswara R Sastry <rnsastry-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Date : 2012-02-24 10:53 (10 days old)
Message-ID : <4F476959.2010400-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=133008013332251&w=2
^ permalink raw reply [relevance 90%]
* Re: Bug#638172: Re: Bug#638172: BUG: soft lockup - CPU#0 stuck for 61s! [qemu-dm:3205]
2011-10-18 10:54 90% ` Ian Campbell
@ 2011-10-18 11:00 90% ` Giuseppe Sacco
0 siblings, 0 replies; 200+ results
From: Giuseppe Sacco @ 2011-10-18 11:00 UTC (permalink / raw)
To: Ian Campbell; +Cc: Konrad Rzeszutek Wilk, Ben Hutchings, xen-devel, 638172
Il giorno mar, 18/10/2011 alle 11.54 +0100, Ian Campbell ha scritto:
> On Fri, 2011-08-26 at 10:28 +0200, Giuseppe Sacco wrote:
> > I just installed the new kernel and switched to 64bit hypervisor. I'll
> > let you know about any news.
>
> Has everything been OK since you switched?
Yes: no crashes since then.
Thanks,
Giuseppe
^ permalink raw reply [relevance 90%]
* Re: Bug#638172: Re: Bug#638172: BUG: soft lockup - CPU#0 stuck for 61s! [qemu-dm:3205]
2011-08-26 8:28 90% ` Giuseppe Sacco
2011-08-26 8:31 90% ` Ian Campbell
@ 2011-10-18 10:54 90% ` Ian Campbell
2011-10-18 11:00 90% ` Giuseppe Sacco
1 sibling, 1 reply; 200+ results
From: Ian Campbell @ 2011-10-18 10:54 UTC (permalink / raw)
To: Giuseppe Sacco; +Cc: Konrad Rzeszutek Wilk, Ben Hutchings, xen-devel, 638172
On Fri, 2011-08-26 at 10:28 +0200, Giuseppe Sacco wrote:
> I just installed the new kernel and switched to 64bit hypervisor. I'll
> let you know about any news.
Has everything been OK since you switched?
Ian.
>
> Il giorno ven, 26/08/2011 alle 08.25 +0100, Ian Campbell ha scritto:
> [...]
> > I'm in the process of uploading a kernel to
> > http://xenbits.xen.org/people/ianc/2.6.32-36~xen0/ which has a bunch of
> > patches to the event channel (aka IRQ) subsystem backported. I think the
> > kernel flavour you want is there already please could you give it a go
> > when you get the chance.
>
> During boot I got this message. Is this related to this bug or to new
> kernel?
>
> [ 0.004000] ------------[ cut here ]------------
> [ 0.004000] WARNING: at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_xen/arch/x86/xen/enlighten.c:726 perf_events_lapic_init+0x28/0x29()
> [ 0.004000] Hardware name: MS-7368
> [ 0.004000] Modules linked in:
> [ 0.004000] Pid: 0, comm: swapper Not tainted 2.6.32-5-xen-686 #1
> [ 0.004000] Call Trace:
> [ 0.004000] [<c1037839>] ? warn_slowpath_common+0x5e/0x8a
> [ 0.004000] [<c103786f>] ? warn_slowpath_null+0xa/0xc
> [ 0.004000] [<c1011db0>] ? perf_events_lapic_init+0x28/0x29
> [ 0.004000] [<c14033dd>] ? init_hw_perf_events+0x2dd/0x376
> [ 0.004000] [<c1403030>] ? check_bugs+0x8/0xd8
> [ 0.004000] [<c13fb808>] ? start_kernel+0x309/0x31d
> [ 0.004000] [<c13fd410>] ? xen_start_kernel+0x564/0x56b
> [ 0.004000] [<c1409045>] ? check_nmi_watchdog+0xcd/0x1f2
> [ 0.004000] ---[ end trace a7919e7f17c0a725 ]---
>
> Thanks,
> Giuseppe
>
>
--
Ian Campbell
Current Noise: Anathema - Flying
There's no future in time travel.
^ permalink raw reply [relevance 90%]
* Re: [Bug #41102] BUG dentry: Poison overwritten / BUG buffer_head: Poison overwritten
@ 2011-08-30 18:47 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2011-08-30 18:47 UTC (permalink / raw)
To: Paul Bolle
Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki,
Florian Mickler
On Tuesday, August 30, 2011, Paul Bolle wrote:
> On Sun, 2011-08-28 at 21:01 +0200, Rafael J. Wysocki wrote:
> > Please verify if it still should
> > be listed and let the tracking team know (either way).
>
> From comment #2:
> > [...] please note that the 3.0.1 kernel I
> > triggered this issue with seems to be the first I ran on this machine that has
> > CONFIG_SLUB_DEBUG_ON set. So on this machine this issue - if it's more than a
> > one time goof - would never have showed up in the logs unless I manually booted
> > with "slub_debug" on the command line. And I can't remember booting with
> > "slub_debug".
>
> At this moment I see little reason to track this bug entry as a
> regression.
OK, dropped from the list of recent regressions.
Thanks,
Rafael
^ permalink raw reply [relevance 90%]
* Re: [Bug #41102] BUG dentry: Poison overwritten / BUG buffer_head: Poison overwritten
@ 2011-08-30 18:47 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2011-08-30 18:47 UTC (permalink / raw)
To: Paul Bolle
Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki,
Florian Mickler
On Tuesday, August 30, 2011, Paul Bolle wrote:
> On Sun, 2011-08-28 at 21:01 +0200, Rafael J. Wysocki wrote:
> > Please verify if it still should
> > be listed and let the tracking team know (either way).
>
> From comment #2:
> > [...] please note that the 3.0.1 kernel I
> > triggered this issue with seems to be the first I ran on this machine that has
> > CONFIG_SLUB_DEBUG_ON set. So on this machine this issue - if it's more than a
> > one time goof - would never have showed up in the logs unless I manually booted
> > with "slub_debug" on the command line. And I can't remember booting with
> > "slub_debug".
>
> At this moment I see little reason to track this bug entry as a
> regression.
OK, dropped from the list of recent regressions.
Thanks,
Rafael
^ permalink raw reply [relevance 90%]
* Re: [Bug #41102] BUG dentry: Poison overwritten / BUG buffer_head: Poison overwritten
2011-08-28 19:01 90% ` [Bug #41102] BUG dentry: Poison overwritten / BUG buffer_head: Poison overwritten Rafael J. Wysocki
@ 2011-08-30 12:13 90% ` Paul Bolle
0 siblings, 0 replies; 200+ results
From: Paul Bolle @ 2011-08-30 12:13 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki,
Florian Mickler
On Sun, 2011-08-28 at 21:01 +0200, Rafael J. Wysocki wrote:
> Please verify if it still should
> be listed and let the tracking team know (either way).
>From comment #2:
> [...] please note that the 3.0.1 kernel I
> triggered this issue with seems to be the first I ran on this machine that has
> CONFIG_SLUB_DEBUG_ON set. So on this machine this issue - if it's more than a
> one time goof - would never have showed up in the logs unless I manually booted
> with "slub_debug" on the command line. And I can't remember booting with
> "slub_debug".
At this moment I see little reason to track this bug entry as a
regression.
Paul Bolle
^ permalink raw reply [relevance 90%]
* Re: [Bug #41102] BUG dentry: Poison overwritten / BUG buffer_head: Poison overwritten
@ 2011-08-30 12:13 90% ` Paul Bolle
0 siblings, 0 replies; 200+ results
From: Paul Bolle @ 2011-08-30 12:13 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki,
Florian Mickler
On Sun, 2011-08-28 at 21:01 +0200, Rafael J. Wysocki wrote:
> Please verify if it still should
> be listed and let the tracking team know (either way).
From comment #2:
> [...] please note that the 3.0.1 kernel I
> triggered this issue with seems to be the first I ran on this machine that has
> CONFIG_SLUB_DEBUG_ON set. So on this machine this issue - if it's more than a
> one time goof - would never have showed up in the logs unless I manually booted
> with "slub_debug" on the command line. And I can't remember booting with
> "slub_debug".
At this moment I see little reason to track this bug entry as a
regression.
Paul Bolle
^ permalink raw reply [relevance 90%]
* [Bug #41102] BUG dentry: Poison overwritten / BUG buffer_head: Poison overwritten
@ 2011-08-28 19:01 90% ` Rafael J. Wysocki
2011-08-30 12:13 90% ` Paul Bolle
0 siblings, 1 reply; 200+ results
From: Rafael J. Wysocki @ 2011-08-28 19:01 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Florian Mickler, Paul Bolle
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.39 and 3.0.
The following bug entry is on the current list of known regressions
introduced between 2.6.39 and 3.0. Please verify if it still should
be listed and let the tracking team know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=41102
Subject : BUG dentry: Poison overwritten / BUG buffer_head: Poison overwritten
Submitter : Paul Bolle <pebolle@tiscali.nl>
Date : 2011-08-13 22:29 (16 days old)
^ permalink raw reply [relevance 90%]
* Re: Bug#638172: Re: Bug#638172: BUG: soft lockup - CPU#0 stuck for 61s! [qemu-dm:3205]
2011-08-26 8:28 90% ` Giuseppe Sacco
@ 2011-08-26 8:31 90% ` Ian Campbell
2011-10-18 10:54 90% ` Ian Campbell
1 sibling, 0 replies; 200+ results
From: Ian Campbell @ 2011-08-26 8:31 UTC (permalink / raw)
To: Giuseppe Sacco; +Cc: Konrad Rzeszutek Wilk, Ben Hutchings, xen-devel, 638172
On Fri, 2011-08-26 at 10:28 +0200, Giuseppe Sacco wrote:
> Hi,
> I just installed the new kernel and switched to 64bit hypervisor. I'll
> let you know about any news.
>
> Il giorno ven, 26/08/2011 alle 08.25 +0100, Ian Campbell ha scritto:
> [...]
> > I'm in the process of uploading a kernel to
> > http://xenbits.xen.org/people/ianc/2.6.32-36~xen0/ which has a bunch of
> > patches to the event channel (aka IRQ) subsystem backported. I think the
> > kernel flavour you want is there already please could you give it a go
> > when you get the chance.
>
> During boot I got this message. Is this related to this bug or to new
> kernel?
It's a benign (but annoying) warning. I'm angling to get it dropped:
http://marc.info/?l=xen-devel&m=131400621622691
>
> [ 0.004000] ------------[ cut here ]------------
> [ 0.004000] WARNING: at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_xen/arch/x86/xen/enlighten.c:726 perf_events_lapic_init+0x28/0x29()
> [ 0.004000] Hardware name: MS-7368
> [ 0.004000] Modules linked in:
> [ 0.004000] Pid: 0, comm: swapper Not tainted 2.6.32-5-xen-686 #1
> [ 0.004000] Call Trace:
> [ 0.004000] [<c1037839>] ? warn_slowpath_common+0x5e/0x8a
> [ 0.004000] [<c103786f>] ? warn_slowpath_null+0xa/0xc
> [ 0.004000] [<c1011db0>] ? perf_events_lapic_init+0x28/0x29
> [ 0.004000] [<c14033dd>] ? init_hw_perf_events+0x2dd/0x376
> [ 0.004000] [<c1403030>] ? check_bugs+0x8/0xd8
> [ 0.004000] [<c13fb808>] ? start_kernel+0x309/0x31d
> [ 0.004000] [<c13fd410>] ? xen_start_kernel+0x564/0x56b
> [ 0.004000] [<c1409045>] ? check_nmi_watchdog+0xcd/0x1f2
> [ 0.004000] ---[ end trace a7919e7f17c0a725 ]---
>
> Thanks,
> Giuseppe
>
>
--
Ian Campbell
May your Tongue stick to the Roof of your Mouth with the Force of a
Thousand Caramels.
^ permalink raw reply [relevance 90%]
* Re: Bug#638172: Re: Bug#638172: BUG: soft lockup - CPU#0 stuck for 61s! [qemu-dm:3205]
2011-08-26 7:25 90% ` Bug#638172: " Ian Campbell
@ 2011-08-26 8:28 90% ` Giuseppe Sacco
2011-08-26 8:31 90% ` Ian Campbell
2011-10-18 10:54 90% ` Ian Campbell
0 siblings, 2 replies; 200+ results
From: Giuseppe Sacco @ 2011-08-26 8:28 UTC (permalink / raw)
To: Ian Campbell; +Cc: Konrad Rzeszutek Wilk, Ben Hutchings, xen-devel, 638172
Hi,
I just installed the new kernel and switched to 64bit hypervisor. I'll
let you know about any news.
Il giorno ven, 26/08/2011 alle 08.25 +0100, Ian Campbell ha scritto:
[...]
> I'm in the process of uploading a kernel to
> http://xenbits.xen.org/people/ianc/2.6.32-36~xen0/ which has a bunch of
> patches to the event channel (aka IRQ) subsystem backported. I think the
> kernel flavour you want is there already please could you give it a go
> when you get the chance.
During boot I got this message. Is this related to this bug or to new
kernel?
[ 0.004000] ------------[ cut here ]------------
[ 0.004000] WARNING: at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_xen/arch/x86/xen/enlighten.c:726 perf_events_lapic_init+0x28/0x29()
[ 0.004000] Hardware name: MS-7368
[ 0.004000] Modules linked in:
[ 0.004000] Pid: 0, comm: swapper Not tainted 2.6.32-5-xen-686 #1
[ 0.004000] Call Trace:
[ 0.004000] [<c1037839>] ? warn_slowpath_common+0x5e/0x8a
[ 0.004000] [<c103786f>] ? warn_slowpath_null+0xa/0xc
[ 0.004000] [<c1011db0>] ? perf_events_lapic_init+0x28/0x29
[ 0.004000] [<c14033dd>] ? init_hw_perf_events+0x2dd/0x376
[ 0.004000] [<c1403030>] ? check_bugs+0x8/0xd8
[ 0.004000] [<c13fb808>] ? start_kernel+0x309/0x31d
[ 0.004000] [<c13fd410>] ? xen_start_kernel+0x564/0x56b
[ 0.004000] [<c1409045>] ? check_nmi_watchdog+0xcd/0x1f2
[ 0.004000] ---[ end trace a7919e7f17c0a725 ]---
Thanks,
Giuseppe
^ permalink raw reply [relevance 90%]
* Re: Bug#638172: Re: Bug#638172: BUG: soft lockup - CPU#0 stuck for 61s! [qemu-dm:3205]
@ 2011-08-26 7:25 90% ` Ian Campbell
2011-08-26 8:28 90% ` Giuseppe Sacco
2011-08-25 7:23 90% ` Bug#638172: [Xen-devel] " Giuseppe Sacco
1 sibling, 1 reply; 200+ results
From: Ian Campbell @ 2011-08-26 7:25 UTC (permalink / raw)
To: 638172; +Cc: Konrad, Ben Hutchings, xen-devel, Wilk, Giuseppe Sacco
[-- Attachment #1.1: Type: text/plain, Size: 713 bytes --]
Hi Giuseppe,
On Thu, 2011-08-25 at 07:56 +0100, Ian Campbell wrote:
>
> > But, I may use a different kernel and let the server goes until crashes:
> > no problem in rebooting it for kernel update.
>
> Thanks that would be useful, I'll put something together and let you
> know.
I'm in the process of uploading a kernel to
http://xenbits.xen.org/people/ianc/2.6.32-36~xen0/ which has a bunch of
patches to the event channel (aka IRQ) subsystem backported. I think the
kernel flavour you want is there already please could you give it a go
when you get the chance.
Thanks,
Ian.
--
Ian Campbell
On-line, adj.:
The idea that a human being should always be accessible to a computer.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [relevance 90%]
* Bug#638172: [Xen-devel] Re: Bug#638172: BUG: soft lockup - CPU#0 stuck for 61s! [qemu-dm:3205]
2011-08-26 7:25 90% ` Bug#638172: " Ian Campbell
@ 2011-08-25 7:23 90% ` Giuseppe Sacco
1 sibling, 0 replies; 200+ results
From: Giuseppe Sacco @ 2011-08-25 7:23 UTC (permalink / raw)
To: Ian Campbell
Cc: Konrad Rzeszutek Wilk, 638172@bugs.debian.org, Ben Hutchings,
xen-devel
Il giorno gio, 25/08/2011 alle 07.56 +0100, Ian Campbell ha scritto:
[...]
> > And yes, it is a 32bit debian squeeze system on a 64 bit Athlon cpu.
>
> But are you running the amd64 or 686 flavour of the hypervisor? Both are
> available in 32bit Debian. FWIW I would always recommend running the 64
> bit hypervisor (even with 32 bit dom0) if you are able to.
The only hypervisor package installed is xen-hypervisor-4.0-i386. I was
not aware that it would be possible to use the amd64 version when
running a 32bit kernel dom0. If you suggest it, I may switch to the
64bit version when I'll install your patched kernel.
Thanks,
Giuseppe
^ permalink raw reply [relevance 90%]
* Bug#638172: [Xen-devel] Re: Bug#638172: BUG: soft lockup - CPU#0 stuck for 61s! [qemu-dm:3205]
@ 2011-08-25 6:52 90% ` Giuseppe Sacco
0 siblings, 1 reply; 200+ results
From: Giuseppe Sacco @ 2011-08-25 6:52 UTC (permalink / raw)
To: Ian Campbell
Cc: Konrad Rzeszutek Wilk, 638172@bugs.debian.org, Ben Hutchings,
xen-devel
Il giorno mer, 24/08/2011 alle 22.24 +0100, Ian Campbell ha scritto:
[...]
> Giuseppe, are you able to reproduce the issue you are seeing at will? If
> I build a test kernel would you be able to try it? You are using a -686
> kernel right (as opposed to amd64). OOI which hypervisor flavour do you
> use?
Unfortunately not. This server crashes often, but I do not have any
method to let it crashes. The worst case is when it crashes just after
reboot, the opposite was after a month from reboot.
But, I may use a different kernel and let the server goes until crashes:
no problem in rebooting it for kernel update.
And yes, it is a 32bit debian squeeze system on a 64 bit Athlon cpu.
Bye,
Giuseppe
^ permalink raw reply [relevance 90%]
* [PATCH 1/1] poky-lsb: Compile library libQtOpenGL* for building an lsb image Fix bug [YOCTO #1020] This patch is part of fixing bug [YOCTO #1020]. If another patch to install libQtOpenGL* to lsb image is merged to poky, \ then this bug will be fixed.For an lsb image prepared to meet lsb requirement, library "libQtOpenGL*" should be compiled. So I add this patch for passing lsb test.
@ 2011-06-10 10:00 90% ` Xiaofeng Yan
0 siblings, 0 replies; 200+ results
From: Xiaofeng Yan @ 2011-06-10 10:00 UTC (permalink / raw)
To: poky
From: Xiaofeng Yan <xiaofeng.yan@windriver.com>
Signed-off-by: Xiaofeng Yan <xiaofeng.yan@windriver.com>
---
meta-yocto/conf/distro/poky-lsb.conf | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta-yocto/conf/distro/poky-lsb.conf b/meta-yocto/conf/distro/poky-lsb.conf
index eb1cf82..29f526d 100644
--- a/meta-yocto/conf/distro/poky-lsb.conf
+++ b/meta-yocto/conf/distro/poky-lsb.conf
@@ -6,4 +6,4 @@ DISTROOVERRIDES = "poky:linuxstdbase"
DISTRO_FEATURES += "pam largefile"
PREFERRED_PROVIDER_virtual/libx11 = "libx11"
-
+QT_GLFLAGS = "-opengl"
--
1.7.0.4
^ permalink raw reply related [relevance 90%]
* [Bug #25822] [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
@ 2011-02-21 22:37 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2011-02-21 22:37 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Florian Mickler, Gurudas Pai,
Miklos Szeredi
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.36 and 2.6.37.
The following bug entry is on the current list of known regressions
introduced between 2.6.36 and 2.6.37. Please verify if it still should
be listed and let the tracking team know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25822
Subject : [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
Submitter : Gurudas Pai <gurudas.pai@oracle.com>
Date : 2010-12-29 6:58 (55 days old)
Message-ID : <4D1AD935.1020504@oracle.com>
References : http://marc.info/?l=linux-kernel&m=129360511222037&w=2
Handled-By : Miklos Szeredi <mszeredi@suse.cz>
Patch : https://lkml.org/lkml/2010/12/29/131
https://lkml.org/lkml/2011/1/20/163
^ permalink raw reply [relevance 90%]
* [Bug #25822] [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
@ 2011-02-21 22:37 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2011-02-21 22:37 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Florian Mickler, Gurudas Pai,
Miklos Szeredi
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.36 and 2.6.37.
The following bug entry is on the current list of known regressions
introduced between 2.6.36 and 2.6.37. Please verify if it still should
be listed and let the tracking team know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25822
Subject : [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
Submitter : Gurudas Pai <gurudas.pai-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date : 2010-12-29 6:58 (55 days old)
Message-ID : <4D1AD935.1020504-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129360511222037&w=2
Handled-By : Miklos Szeredi <mszeredi-AlSwsSmVLrQ@public.gmane.org>
Patch : https://lkml.org/lkml/2010/12/29/131
https://lkml.org/lkml/2011/1/20/163
^ permalink raw reply [relevance 90%]
* [Bug #25822] [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
@ 2011-02-12 23:38 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2011-02-12 23:38 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Florian Mickler, Gurudas Pai
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.36 and 2.6.37.
The following bug entry is on the current list of known regressions
introduced between 2.6.36 and 2.6.37. Please verify if it still should
be listed and let the tracking team know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25822
Subject : [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
Submitter : Gurudas Pai <gurudas.pai@oracle.com>
Date : 2010-12-29 6:58 (46 days old)
Message-ID : <4D1AD935.1020504@oracle.com>
References : http://marc.info/?l=linux-kernel&m=129360511222037&w=2
Patch : https://lkml.org/lkml/2010/12/29/131
https://lkml.org/lkml/2011/1/20/163
^ permalink raw reply [relevance 90%]
* [Bug #25822] [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
@ 2011-02-12 23:38 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2011-02-12 23:38 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Florian Mickler, Gurudas Pai
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.36 and 2.6.37.
The following bug entry is on the current list of known regressions
introduced between 2.6.36 and 2.6.37. Please verify if it still should
be listed and let the tracking team know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25822
Subject : [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
Submitter : Gurudas Pai <gurudas.pai-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date : 2010-12-29 6:58 (46 days old)
Message-ID : <4D1AD935.1020504-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129360511222037&w=2
Patch : https://lkml.org/lkml/2010/12/29/131
https://lkml.org/lkml/2011/1/20/163
^ permalink raw reply [relevance 90%]
* [Bug #25822] [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
@ 2011-02-03 0:05 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2011-02-03 0:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Florian Mickler, Gurudas Pai
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.36 and 2.6.37.
The following bug entry is on the current list of known regressions
introduced between 2.6.36 and 2.6.37. Please verify if it still should
be listed and let the tracking team know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25822
Subject : [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
Submitter : Gurudas Pai <gurudas.pai@oracle.com>
Date : 2010-12-29 6:58 (36 days old)
Message-ID : <4D1AD935.1020504@oracle.com>
References : http://marc.info/?l=linux-kernel&m=129360511222037&w=2
Patch : https://lkml.org/lkml/2010/12/29/131
^ permalink raw reply [relevance 90%]
* [Bug #25822] [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
@ 2011-02-03 0:05 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2011-02-03 0:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Florian Mickler, Gurudas Pai
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.36 and 2.6.37.
The following bug entry is on the current list of known regressions
introduced between 2.6.36 and 2.6.37. Please verify if it still should
be listed and let the tracking team know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25822
Subject : [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
Submitter : Gurudas Pai <gurudas.pai-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date : 2010-12-29 6:58 (36 days old)
Message-ID : <4D1AD935.1020504-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129360511222037&w=2
Patch : https://lkml.org/lkml/2010/12/29/131
^ permalink raw reply [relevance 90%]
* [Bug #25822] [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
[not found] <96DQe4a_2tH.A.4RE.497GNB@chimera>
@ 2010-12-29 23:07 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2010-12-29 23:07 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Maciej Rutecki, Florian Mickler, Gurudas Pai
This message has been generated automatically as a part of a summary report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.36. Please verify if it still should be listed and let the tracking team
know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25822
Subject : [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
Submitter : Gurudas Pai <gurudas.pai@oracle.com>
Date : 2010-12-29 6:58 (1 days old)
Message-ID : <4D1AD935.1020504@oracle.com>
References : http://marc.info/?l=linux-kernel&m=129360511222037&w=2
^ permalink raw reply [relevance 90%]
* [Bug #15935] [BUG] btrfs: report a direct-IO bug
@ 2010-05-09 21:17 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2010-05-09 21:17 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciej Rutecki, liubo
This message has been generated automatically as a part of a summary report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.33. Please verify if it still should be listed and let the tracking team
know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15935
Subject : [BUG] btrfs: report a direct-IO bug
Submitter : liubo <liubo2009@cn.fujitsu.com>
Date : 2010-05-06 1:47 (4 days old)
Message-ID : <4BE21FC1.1010901@cn.fujitsu.com>
References : http://marc.info/?l=linux-kernel&m=127311036803487&w=2
^ permalink raw reply [relevance 90%]
* [Bug #15935] [BUG] btrfs: report a direct-IO bug
@ 2010-05-09 21:17 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2010-05-09 21:17 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciej Rutecki, liubo
This message has been generated automatically as a part of a summary report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.33. Please verify if it still should be listed and let the tracking team
know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15935
Subject : [BUG] btrfs: report a direct-IO bug
Submitter : liubo <liubo2009-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Date : 2010-05-06 1:47 (4 days old)
Message-ID : <4BE21FC1.1010901-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127311036803487&w=2
^ permalink raw reply [relevance 90%]
* RE: Bug 14579 (was: RE: Bug 14579 - Devices disappear... and Bug 14577 - Data corruption with Adaptec)
2009-11-19 10:48 90% ` Lukas Kolbe
@ 2009-11-19 10:58 90% ` Desai, Kashyap
0 siblings, 0 replies; 200+ results
From: Desai, Kashyap @ 2009-11-19 10:58 UTC (permalink / raw)
To: Lukas Kolbe; +Cc: linux-scsi@vger.kernel.org, sfrey@techfak.uni-bielefeld.de
[-- Attachment #1: Type: text/plain, Size: 2943 bytes --]
> -----Original Message-----
> From: Lukas Kolbe [mailto:lkolbe@techfak.uni-bielefeld.de]
> Sent: Thursday, November 19, 2009 4:19 PM
> To: Desai, Kashyap
> Cc: linux-scsi@vger.kernel.org; sfrey@techfak.uni-bielefeld.de
> Subject: RE: Bug 14579 (was: RE: Bug 14579 - Devices disappear... and Bug
> 14577 - Data corruption with Adaptec)
>
> Am Donnerstag, den 19.11.2009, 16:00 +0530 schrieb Desai, Kashyap:
> >
> > > -----Original Message-----
> > > From: Lukas Kolbe [mailto:lkolbe@techfak.uni-bielefeld.de]
> > > Sent: Thursday, November 19, 2009 3:48 PM
> > > To: Desai, Kashyap
> > > Cc: linux-scsi@vger.kernel.org; sfrey@techfak.uni-bielefeld.de
> > > Subject: Bug 14579 (was: RE: Bug 14579 - Devices disappear... and Bug
> > > 14577 - Data corruption with Adaptec)
> > >
> > > Am Donnerstag, den 19.11.2009, 10:43 +0530 schrieb Desai, Kashyap:
> > > > OK. So I get it now. You are working to solve major issue which is
> > > > related to your RAID 60 + Adaptec controller. If you want to upgrade
> > > > LSI driver, we can always go for latest driver. I can provide you
> > > > latest driver source tar ball. Back porting to 2.6.30 is fine.
> > >
> > > That would be great, thank you. It seems the Adaptec-problem will
> still
> > > take a while to debug, so if we can get further with the LSI issue it
> > > would be much appreciated. It might take a few days of testing after
> we
> > > build 2.6.30 with the new mtpfusion.
> > >
> > I think, without solving one issue (Adaptec related), I am not in
> > position to understand what is an issue w.r.t LSI ? Pls clarify. If
> > you can provide me Logs for LSI driver and provide me pointer to look
> > inside, I can do something on this.
>
> It's all in Bug #14579, see
> http://bugzilla.kernel.org/show_bug.cgi?id=14579
>
> Basically, after a while writing to the tape drive that is attached to
> the LSI controller, the bus either resets itself without finding the
> tape drives again, or we get an oops and the system crashes. This is a
> seperate problem from the one we have with the Adaptec RAID on 2.6.32,
> that is the reason why we opened two bugs.
>
Looking at oops message attached to bug14579, I am still unable to map anything which might be related to LSI driver, in sort I am not getting any pointers related to fusion driver from OOPS message . Better way to provide Oops will be console redirect.
> If you can provide us with the current mptfusion, we can build it for
> 2.6.30 and test wether the bus reset and/or oops do still happen. If
> they don't, you made a few people very happy :)
>
I have attached latest fusion driver version 3.04.13 for upstream kernel.
You can run *compile* script inside fusion folder to compile it.
You have to copy *.ko to /lib/modules/`uname -r`/ and create mkinitrd once again to reflect driver update in mkinitrd.
Please try
> --
> Kind regards,
> Lukas
>
[-- Attachment #2: fusion_3.04.13.tar.gz --]
[-- Type: application/x-gzip, Size: 256238 bytes --]
^ permalink raw reply [relevance 90%]
* RE: Bug 14579 (was: RE: Bug 14579 - Devices disappear... and Bug 14577 - Data corruption with Adaptec)
2009-11-19 10:30 90% ` Desai, Kashyap
@ 2009-11-19 10:48 90% ` Lukas Kolbe
2009-11-19 10:58 90% ` Desai, Kashyap
0 siblings, 1 reply; 200+ results
From: Lukas Kolbe @ 2009-11-19 10:48 UTC (permalink / raw)
To: Desai, Kashyap; +Cc: linux-scsi@vger.kernel.org, sfrey@techfak.uni-bielefeld.de
Am Donnerstag, den 19.11.2009, 16:00 +0530 schrieb Desai, Kashyap:
>
> > -----Original Message-----
> > From: Lukas Kolbe [mailto:lkolbe@techfak.uni-bielefeld.de]
> > Sent: Thursday, November 19, 2009 3:48 PM
> > To: Desai, Kashyap
> > Cc: linux-scsi@vger.kernel.org; sfrey@techfak.uni-bielefeld.de
> > Subject: Bug 14579 (was: RE: Bug 14579 - Devices disappear... and Bug
> > 14577 - Data corruption with Adaptec)
> >
> > Am Donnerstag, den 19.11.2009, 10:43 +0530 schrieb Desai, Kashyap:
> > > OK. So I get it now. You are working to solve major issue which is
> > > related to your RAID 60 + Adaptec controller. If you want to upgrade
> > > LSI driver, we can always go for latest driver. I can provide you
> > > latest driver source tar ball. Back porting to 2.6.30 is fine.
> >
> > That would be great, thank you. It seems the Adaptec-problem will still
> > take a while to debug, so if we can get further with the LSI issue it
> > would be much appreciated. It might take a few days of testing after we
> > build 2.6.30 with the new mtpfusion.
> >
> I think, without solving one issue (Adaptec related), I am not in
> position to understand what is an issue w.r.t LSI ? Pls clarify. If
> you can provide me Logs for LSI driver and provide me pointer to look
> inside, I can do something on this.
It's all in Bug #14579, see
http://bugzilla.kernel.org/show_bug.cgi?id=14579
Basically, after a while writing to the tape drive that is attached to
the LSI controller, the bus either resets itself without finding the
tape drives again, or we get an oops and the system crashes. This is a
seperate problem from the one we have with the Adaptec RAID on 2.6.32,
that is the reason why we opened two bugs.
If you can provide us with the current mptfusion, we can build it for
2.6.30 and test wether the bus reset and/or oops do still happen. If
they don't, you made a few people very happy :)
--
Kind regards,
Lukas
^ permalink raw reply [relevance 90%]
* RE: Bug 14579 (was: RE: Bug 14579 - Devices disappear... and Bug 14577 - Data corruption with Adaptec)
2009-11-19 10:17 90% ` Bug 14579 (was: RE: Bug 14579 - Devices disappear... and Bug 14577 - Data corruption with Adaptec) Lukas Kolbe
@ 2009-11-19 10:30 90% ` Desai, Kashyap
2009-11-19 10:48 90% ` Lukas Kolbe
0 siblings, 1 reply; 200+ results
From: Desai, Kashyap @ 2009-11-19 10:30 UTC (permalink / raw)
To: Lukas Kolbe; +Cc: linux-scsi@vger.kernel.org, sfrey@techfak.uni-bielefeld.de
> -----Original Message-----
> From: Lukas Kolbe [mailto:lkolbe@techfak.uni-bielefeld.de]
> Sent: Thursday, November 19, 2009 3:48 PM
> To: Desai, Kashyap
> Cc: linux-scsi@vger.kernel.org; sfrey@techfak.uni-bielefeld.de
> Subject: Bug 14579 (was: RE: Bug 14579 - Devices disappear... and Bug
> 14577 - Data corruption with Adaptec)
>
> Am Donnerstag, den 19.11.2009, 10:43 +0530 schrieb Desai, Kashyap:
> > OK. So I get it now. You are working to solve major issue which is
> > related to your RAID 60 + Adaptec controller. If you want to upgrade
> > LSI driver, we can always go for latest driver. I can provide you
> > latest driver source tar ball. Back porting to 2.6.30 is fine.
>
> That would be great, thank you. It seems the Adaptec-problem will still
> take a while to debug, so if we can get further with the LSI issue it
> would be much appreciated. It might take a few days of testing after we
> build 2.6.30 with the new mtpfusion.
>
I think, without solving one issue (Adaptec related), I am not in position to understand what is an issue w.r.t LSI ? Pls clarify. If you can provide me Logs for LSI driver and provide me pointer to look inside, I can do something on this.
> --
> Lukas Kolbe
>
>
^ permalink raw reply [relevance 90%]
* Bug 14579 (was: RE: Bug 14579 - Devices disappear... and Bug 14577 - Data corruption with Adaptec)
@ 2009-11-19 10:17 90% ` Lukas Kolbe
2009-11-19 10:30 90% ` Desai, Kashyap
0 siblings, 1 reply; 200+ results
From: Lukas Kolbe @ 2009-11-19 10:17 UTC (permalink / raw)
To: Desai, Kashyap; +Cc: linux-scsi@vger.kernel.org, sfrey
Am Donnerstag, den 19.11.2009, 10:43 +0530 schrieb Desai, Kashyap:
> OK. So I get it now. You are working to solve major issue which is
> related to your RAID 60 + Adaptec controller. If you want to upgrade
> LSI driver, we can always go for latest driver. I can provide you
> latest driver source tar ball. Back porting to 2.6.30 is fine.
That would be great, thank you. It seems the Adaptec-problem will still
take a while to debug, so if we can get further with the LSI issue it
would be much appreciated. It might take a few days of testing after we
build 2.6.30 with the new mtpfusion.
--
Lukas Kolbe
^ permalink raw reply [relevance 90%]
* Re: [STABLE][PATCH 1/1] u-boot-bug: Added U-Boot for BUG (from BUG Labs SVN)
2009-05-05 10:28 89% ` [STABLE][PATCH 1/1] u-boot-bug: Added U-Boot for BUG (from BUG Labs SVN) Marcin Juszkiewicz
@ 2009-05-05 11:25 90% ` Philip Balister
0 siblings, 0 replies; 200+ results
From: Philip Balister @ 2009-05-05 11:25 UTC (permalink / raw)
To: openembedded-devel
[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]
Acked-by: Philip Balister <philip@balister.org>
Marcin Juszkiewicz wrote:
> From: Marcin Juszkiewicz <marcin@buglabs.net>
>
>
> Signed-off-by: Marcin Juszkiewicz <marcin@buglabs.net>
> ---
> conf/distro/include/sane-srcrevs.inc | 1 +
> recipes/u-boot/u-boot-bug_svn.bb | 37 ++++++++++++++++++++++++++++++++++
> 2 files changed, 38 insertions(+), 0 deletions(-)
> create mode 100644 recipes/u-boot/u-boot-bug_svn.bb
>
> diff --git a/conf/distro/include/sane-srcrevs.inc b/conf/distro/include/sane-srcrevs.inc
> index 64781eb..d924070 100644
> --- a/conf/distro/include/sane-srcrevs.inc
> +++ b/conf/distro/include/sane-srcrevs.inc
> @@ -239,6 +239,7 @@ SRCREV_pn-table ?= "2191"
> SRCREV_pn-tichy ?= "ab68d849502009cf3214df48ffa8075a10cc2177"
> SRCREV_pn-tmut ?= "60"
> SRCREV_pn-toscoterm ?= "f02add76f365a2fecd2dbefc230ceaab20244f96"
> +SRCREV_pn-u-boot-bug ?= "8674"
> SRCREV_pn-u-boot-openmoko ?= "650149a53dbdd48bf6dfef90930c8ab182adb512"
> SRCREV_pn-u-boot-openmoko-devel ?= "ba029a1426bfca169572bf80d50a8b190a6b0e19"
> SRCREV_pn-uclibc ?= "25712"
> diff --git a/recipes/u-boot/u-boot-bug_svn.bb b/recipes/u-boot/u-boot-bug_svn.bb
> new file mode 100644
> index 0000000..c1930f4
> --- /dev/null
> +++ b/recipes/u-boot/u-boot-bug_svn.bb
> @@ -0,0 +1,37 @@
> +DESCRIPTION = "U-boot bootloader w/ BUG support"
> +LICENSE = "GPL"
> +SECTION = "bootloader"
> +PRIORITY = "optional"
> +PV = "1.3.2+svnr${SRCREV}"
> +SRCREV = "${AUTOREV}"
> +PR = "r6"
> +
> +SRC_URI = "\
> + svn://svn.buglabs.net/bug/branches/R1.4/qa;module=u-boot;proto=svn \
> +"
> +S = "${WORKDIR}/u-boot"
> +
> +COMPATIBLE_MACHINE = "bug"
> +PACKAGE_ARCH = "${MACHINE}"
> +
> +EXTRA_OEMAKE = "CROSS_COMPILE=${TARGET_PREFIX}"
> +TARGET_LDFLAGS = ""
> +
> +do_compile () {
> + oe_runmake mx31_bug2_config
> + oe_runmake clean
> + oe_runmake all
> +}
> +
> +do_deploy () {
> + install -d ${DEPLOY_DIR_IMAGE}
> + install -m 0644 ${S}/u-boot.bin ${DEPLOY_DIR_IMAGE}/u-boot-${PV}-${PR}.bin
> + ln -sf ${DEPLOY_DIR_IMAGE}/u-boot-${PV}-${PR}.bin ${DEPLOY_DIR_IMAGE}/uboot-latest.bin
> +}
> +
> +do_stage() {
> + install -m 0755 tools/mkimage ${STAGING_BINDIR_NATIVE}/mkimage
> +}
> +
> +do_deploy[dirs] = "${S}"
> +addtask deploy before do_package after do_install
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]
^ permalink raw reply [relevance 90%]
* Re: [PATCH]atl1e:fix bug [Bug 11454] New: atl1e - BUG: scheduling while atomic: modprobe/678/0x00000002
2008-08-31 4:51 87% [PATCH]atl1e:fix bug [Bug 11454] New: atl1e - BUG: scheduling while atomic: modprobe/678/0x00000002 jie.yang
@ 2008-08-31 5:08 90% ` Matthew Wilcox
2008-08-31 5:31 89% ` Jie Yang
0 siblings, 1 reply; 200+ results
From: Matthew Wilcox @ 2008-08-31 5:08 UTC (permalink / raw)
To: jie.yang; +Cc: akpm, bugme-daemon, harn-solo, jeff, netdev, linux-kernel
On Sun, Aug 31, 2008 at 12:51:58PM +0800, jie.yang@atheros.com wrote:
> from Jie Yang <jie.yang@atheros.com>
>
> On Saturday, August 30, 2008 5:27 AM
> Andrew Morton <akpm@linux-foundation.org]>
> > On Fri, 29 Aug 2008 14:08:09 -0700 (PDT)
> > bugme-daemon@bugzilla.kernel.org wrote:
> >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=11454
> > >
> > > Summary: atl1e - BUG: scheduling while atomic:
> > > modprobe/678/0x00000002
> > > Product: Drivers
> > > Version: 2.5
> > > KernelVersion: 2.6.27-rc5
> > > Platform: All
> > > OS/Version: Linux
> > > Tree: Mainline
> > > Status: NEW
> > > Severity: high
> > > Priority: P1
> > > Component: Network
> > > AssignedTo: jgarzik@pobox.com
How about taking my original patch, sent August 12th instead? That has
a good changelog and proper attribution. The removal of the
unnecessary casts can be a separate message.
If you weren't cc'd on the patch (Jeff was), you can pick it up from
netdev.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply [relevance 90%]
* [Bug #10290] [BUG] Linux 2.6.25-rc6 - kernel BUG at fs/mpage.c:476! on powerpc
@ 2008-04-13 18:56 90% ` Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2008-04-13 18:56 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kamalesh Babulal
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.24. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10290
Subject : [BUG] Linux 2.6.25-rc6 - kernel BUG at fs/mpage.c:476! on powerpc
Submitter : Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Date : 2008-03-20 13:13 (25 days old)
References : http://lkml.org/lkml/2008/3/20/39
^ permalink raw reply [relevance 90%]
* [Bug #10290] [BUG] Linux 2.6.25-rc6 - kernel BUG at fs/mpage.c:476! on powerpc
@ 2008-04-08 23:02 90% Rafael J. Wysocki
0 siblings, 0 replies; 200+ results
From: Rafael J. Wysocki @ 2008-04-08 23:02 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kamalesh Babulal
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.24. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10290
Subject : [BUG] Linux 2.6.25-rc6 - kernel BUG at fs/mpage.c:476! on powerpc
Submitter : Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Date : 2008-03-20 13:13 (20 days old)
References : http://lkml.org/lkml/2008/3/20/39
^ permalink raw reply [relevance 90%]
* Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
[not found] ` <20070209204431.GR32661@doriath.informatik.uni-erlangen.de>
@ 2007-02-09 21:28 90% ` David Härdeman
0 siblings, 0 replies; 200+ results
From: David Härdeman @ 2007-02-09 21:28 UTC (permalink / raw)
To: Johannes Schlumberger, 409875
Cc: waldi, debian-devel, pkg-lvm-maintainers, dm-devel, lool+alioth,
agk
reassign 409875 libdevmapper1.02
retitle 409875 libdevmapper should provide more helpful error messages
severity 409875 minor
thanks
On Fri, Feb 09, 2007 at 09:44:32PM +0100, Johannes Schlumberger wrote:
>> Thanks, this looks mighty suspicious...it looks like /dev/md0 is mounted
>> as your root partition by the initramfs? Please provide me with "ls -al
>> /dev/root" and "cat /proc/cmdline" as well as the contents of your grub
>> or lilo config file.
>
>I am so sorry for stealing yours and other persons time like this. I had
>root=/dev/md0 in my menu.lst and / as /dev/hdd6 in my fstab. I have to say I am
>strongly embarassed.
No problem, it happends to all of us. There still is a bug here
though...the error messages from libdevmapper are obtuse to say the
least.
libdevmapper explained that /dev/md0 is in use with the message:
"Command failed: device-mapper: reload ioctl failed: Invalid argument"
That is a bug in my book.
I'll reassign this bug to libdevmapper (and retitle it accordingly).
I'll also CC all people that I've bugged earlier so that they know that
this issue is no more.
>Thank you a lot for figuring this out and all your patience.
That's ok, you just owe me a beer.
--
David Härdeman
^ permalink raw reply [relevance 90%]
* Re: [Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf() + MMX bug
2007-01-16 16:19 90% ` Ludovic Drolez
@ 2007-01-16 17:50 90% ` Aurelien Jarno
0 siblings, 0 replies; 200+ results
From: Aurelien Jarno @ 2007-01-16 17:50 UTC (permalink / raw)
To: qemu-devel
Ludovic Drolez a écrit :
> I've also found the buggy SSE instruction by tracing modf() with gdb.
> It's similar to the MMX bug found below: only the 32 bits part of the register
> is stored instead of the whole 64 bits.
>
> The bug is in the movd instruction in 64 bits emulation.
> Under gdb, just before the movd I had %rsi=0x3FF0000000000000
> and, after movd, %xmm0=0 ! Only the 32bits part seems to be copied when
> the source is a 64bits register.
>
> 2edaa: 48 d3 e0 shl %cl,%rax
> 2edad: 48 21 c6 and %rax,%rsi
> 2edb0: 66 48 0f 6e c6 movd %rsi,%xmm0
>
> So in fact the valgrind mmx bug and the modf() bug have the same cause.
>
I have just looked at the documentation from AMD. I confirm that in
32-bit mode, the 32 bits of the register have to be copied in the lower
part of mmx or xmm register. In 64-bit mode, the 64 bits of the register
have to be copied in the mmx register or in the lower part of the xmm
register.
So that confirms the implementation in QEMU is wrong.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply [relevance 90%]
* [Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf() + MMX bug
2007-01-16 11:22 90% ` [Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf() + MMX bug Ludovic Drolez
@ 2007-01-16 16:19 90% ` Ludovic Drolez
2007-01-16 17:50 90% ` Aurelien Jarno
0 siblings, 1 reply; 200+ results
From: Ludovic Drolez @ 2007-01-16 16:19 UTC (permalink / raw)
To: qemu-devel
I've also found the buggy SSE instruction by tracing modf() with gdb.
It's similar to the MMX bug found below: only the 32 bits part of the register
is stored instead of the whole 64 bits.
The bug is in the movd instruction in 64 bits emulation.
Under gdb, just before the movd I had %rsi=0x3FF0000000000000
and, after movd, %xmm0=0 ! Only the 32bits part seems to be copied when
the source is a 64bits register.
2edaa: 48 d3 e0 shl %cl,%rax
2edad: 48 21 c6 and %rax,%rsi
2edb0: 66 48 0f 6e c6 movd %rsi,%xmm0
So in fact the valgrind mmx bug and the modf() bug have the same cause.
Anyone knows where to fix this bug ?
Cheers,
Ludovic.
>
> Hi !
>
> I've run the valgrind tests on Qemu 0.8.2, in particular insn_basic,
> insn_fpu, _mmx, _sse, _sse2. No bugs were found in SSE and FPU
> emulation, but one was found in MMX !:
>
> ~/tests/none/tests/amd64 # diff insn_mmx.r insn_mmx.stdout.exp
> 1,6c1,2
> < movd_1 ... not ok
> < result0.sd[0] = 1234 (expected 1234)
> < result0.sd[1] = 0 (expected 5678)
> < movd_2 ... not ok
> < result0.sd[0] = 1234 (expected 1234)
> < result0.sd[1] = 0 (expected 5678)
> ---
> > movd_1 ... ok
> > movd_2 ... ok
>
> Which comes from the following test:
> #
> # %mm <-> ireg64
> #
> movd mm.sd[1234,5678] r64.sd[1111,2222] => 1.sd[1234,5678]
> movd r64.sd[1234,5678] mm.sd[1111,2222] => 1.sd[1234,5678]
>
>
> So one MMX bug when using 64 bits regs has been found, but the SSE2 bug is
> still a mystery :-(
>
> Cheers,
>
>
--
Ludovic DROLEZ Linbox / Free&ALter Soft
www.linbox.com www.linbox.org
^ permalink raw reply [relevance 90%]
* [Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf() + MMX bug
@ 2007-01-16 11:22 90% ` Ludovic Drolez
2007-01-16 16:19 90% ` Ludovic Drolez
0 siblings, 1 reply; 200+ results
From: Ludovic Drolez @ 2007-01-16 11:22 UTC (permalink / raw)
To: qemu-devel
Julian Seward wrote:
>>>Would someone be able to track down this SSE QEMU bug seen only in SLES's
>>>modf() function ?
>
>
> The Valgrind sources contain test programs, including expected outputs,
> for all SSE/SSE2/SSE3 instructions on amd64 (see none/tests/amd64/insn-sse
> and insn-sse2). Running those on QEMU might be a quick and easy first
> check for something wrong in the SSE department. They are not completely
> comprehensive but may find obvious arithmetic errors and instruction
> decoding errors.
>
Hi !
I've run the valgrind tests on Qemu 0.8.2, in particular insn_basic, insn_fpu,
_mmx, _sse, _sse2. No bugs were found in SSE and FPU emulation, but one was
found in MMX !:
~/tests/none/tests/amd64 # diff insn_mmx.r insn_mmx.stdout.exp
1,6c1,2
< movd_1 ... not ok
< result0.sd[0] = 1234 (expected 1234)
< result0.sd[1] = 0 (expected 5678)
< movd_2 ... not ok
< result0.sd[0] = 1234 (expected 1234)
< result0.sd[1] = 0 (expected 5678)
---
> movd_1 ... ok
> movd_2 ... ok
Which comes from the following test:
#
# %mm <-> ireg64
#
movd mm.sd[1234,5678] r64.sd[1111,2222] => 1.sd[1234,5678]
movd r64.sd[1234,5678] mm.sd[1111,2222] => 1.sd[1234,5678]
So one MMX bug when using 64 bits regs has been found, but the SSE2 bug is
still a mystery :-(
Cheers,
--
Ludovic DROLEZ Linbox / Free&ALter Soft
www.linbox.com www.linbox.org tel: +33 3 87 50 87 90
152 rue de Grigy - Technopole Metz 2000 57070 METZ
^ permalink raw reply [relevance 90%]
* Bug#385857: [Bluez-devel] Bug#385857: [Pkg-bluetooth-maintainers] Bug#385857: please upgrade to bluez-utils and bluez-libs 3.4
@ 2006-09-05 11:07 90% ` Marcel Holtmann
0 siblings, 0 replies; 200+ results
From: Marcel Holtmann @ 2006-09-05 11:07 UTC (permalink / raw)
To: BlueZ development; +Cc: Flavio Stanchina, 385857, bluez-devel
Hi Filippo,
> > > > > bluez-libs compiled out of the box by just unpacking and moving the
> > > > > debian directory over, but bluez-utils needs some work:
> > > > >
> > > > > * remove bluez-bcm203x package (bcm203x firmware loader removed upstream)
> > > >
> > > > Not needed at all. You don't wanna support a 2.4 kernel and even if you
> > > > really want to, you won't find any of these devices anymore. For all 2.6
> > > > kernels the bcm203x kernel module takes care of loading the firmware.
> > >
> > > I'm going to drop it after etch release when we'll discontinue support for 2.4
> > > kernels.
> >
> > You can drop it now actually. A Liunx 2.4 kernel user and owner of this
> > device is a really really unlikely combination. I mean it. It would take
> > me at least a couple of hours to find my dongle.
>
> good luck with finding your dongle :)
> anyway, as rare as it is etch is going to support 2.4 kernels.
your choice, but it is no longer part of bluez-utils.
> > > > This package has to die and from an USB and udev perspective it was a
> > > > really nasty hack.
> > > >
> > > > > * remove 000_rfcomm_conf_example.patch: the example is already commented
> > > > > * remove 004_rfcomm_usage.patch: applied upstream
> > > >
> > > > Sometimes it is a good idea to feed patches back to upstream so I don't
> > > > have to extract them from the packages.
> > >
> > > yep, I'm used to do it, I must have overlooked these patches.
> >
> > Do you have any other patches that are not upstream?
>
> I'm looking at them one by one, bluez debian packages are maintained with svn.
> You can browse the patches for bluez-utils at
> http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/?rev=0&sc=0
>
> you might be interested in:
>
> http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/007_hcid_typo.patch?op=file&rev=0&sc=0
> which fixes a small typo in hcid
>
> http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/008_pand_man.patch?op=file&rev=0&sc=0
> addition for pand manpage referring /etc/bluetooth/pan/dev-up execution
These two patches were already in the CVS.
> http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/006_xsims.patch?op=file&rev=0&sc=0
> more compatible usage of test in bluetooth.init and hsplay
Added this one. This will get you down to two.
> > And please drop your passkey agent think completely. This will be
> > distribution specific and can't be a solution. It is better to put the
> > passkey-agent.c example in the docs directory as an example and mention
> > it in a README.Debian.
> >
> > That said. I am missing a package for bluez-gnome which contains the
> > graphical passkey agent. New version is coming up also this week. It
> > will fix a small glitch with the status icon.
>
> indeed, how about this plan:
>
> - I will add to bluez-utils a default non-interactive passkey agent (more or less
> like now but less hackish) which uses /etc/bluetooth/passkeys/<bt_addr> like
> now
Doesn't make sense, because it is distro specific and you duplicate
functionality that is already present. Don't do this. This stuff must
die. I am serious about it.
> - bluez-gnome will provide the graphical passkey agent which takes over the
> non-interactive one
Make sure you deprecate bluez-pin, because that one is no longer working
or even useful at all.
> Marcel: can agents be "stackable", that is, if two agents are registered and
> first one doesn't supply an answer, the second will?
The default passkey agent (like bt-applet) is not stackable. There
should be only one default passkey agent and that one should be provided
by the Desktop environment (like GNOME, KDE etc.). However you can have
multiple device specific agents for connection wizards or other
situations where you expect a PIN request.
Regards
Marcel
_______________________________________________
Pkg-bluetooth-maintainers mailing list
Pkg-bluetooth-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-bluetooth-maintainers
^ permalink raw reply [relevance 90%]
* Bug#322732: [Bluez-devel] [Pkg-bluetooth-maintainers] Bug#322732: more on this bug (was: rfcomm bind fails with obscure error message)
2006-06-04 15:15 90% ` Bug#322732: " Filippo Giunchedi
@ 2006-06-04 15:46 90% ` Marcel Holtmann
0 siblings, 0 replies; 200+ results
From: Marcel Holtmann @ 2006-06-04 15:46 UTC (permalink / raw)
To: BlueZ development; +Cc: 322732-submitter, 322732
Hi Filippo,
> > > comments?
> >
> > check for EOPNOTSUPP error code and only then print this error.
>
> allright, I fixed this with the attached patch
the patch has been applied to the CVS now. Thanks.
Regards
Marcel
_______________________________________________
Pkg-bluetooth-maintainers mailing list
Pkg-bluetooth-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-bluetooth-maintainers
^ permalink raw reply [relevance 90%]
* Bug#322732: [Pkg-bluetooth-maintainers] Bug#322732: [Bluez-devel] more on this bug (was: rfcomm bind fails with obscure error message)
@ 2006-06-04 15:15 90% ` Filippo Giunchedi
2006-06-04 15:46 90% ` Bug#322732: [Bluez-devel] [Pkg-bluetooth-maintainers] Bug#322732: " Marcel Holtmann
0 siblings, 1 reply; 200+ results
From: Filippo Giunchedi @ 2006-06-04 15:15 UTC (permalink / raw)
To: 322732; +Cc: 322732-submitter, bluez-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 381 bytes --]
On Mon, May 29, 2006 at 03:16:21PM +0200, Marcel Holtmann wrote:
> > comments?
>
> check for EOPNOTSUPP error code and only then print this error.
allright, I fixed this with the attached patch
thanks,
filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:
Either this man is dead or my watch has stopped.
-- Groucho Marx
[-- Attachment #1.1.2: 010_rfcomm_tty.patch --]
[-- Type: text/plain, Size: 426 bytes --]
--- rfcomm/main.c (revision 154)
+++ rfcomm/main.c (working copy)
@@ -172,8 +172,12 @@
req.channel = 1;
}
- if ((err = ioctl(ctl, RFCOMMCREATEDEV, &req)) < 0 )
- perror("Can't create device");
+ if ((err = ioctl(ctl, RFCOMMCREATEDEV, &req)) < 0 ) {
+ if (err == EOPNOTSUPP)
+ fprintf(stderr, "RFCOMM TTY support not available\n");
+ else
+ perror("Can't create device");
+ }
return err;
}
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 211 bytes --]
_______________________________________________
Pkg-bluetooth-maintainers mailing list
Pkg-bluetooth-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-bluetooth-maintainers
^ permalink raw reply [relevance 90%]
* bug: 2.4.[<=6] kernel has Cyrix 'coma' bug?
@ 2001-07-22 13:10 93% Steven Lass
2001-07-22 21:36 82% ` Steven Lass
0 siblings, 1 reply; 200+ results
From: Steven Lass @ 2001-07-22 13:10 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]
dev-list,
Every 2.4 kernel that I've tried freezes my Cyrix MediaGX system at boot
up.
Typically the last messages displayed are:
Working around Cyrix MediaGX virtual DMA bugs
CPU: Cyrix Media GX Core/Bus Clock Stepping 02
Checking 'hlt' instruction
Occasionally, the "Checking 'hlt' instruction" is not displayed before
it freezes.
My system is a PowerSpec Model 1810 (no laughs please), my Phoenix BIOS
reports "Cyrix GX 3.2 180MHz".
I've compiled/installed numerous 2.2.x kernels w/o any trouble. The
Redhat 7.1 CDROM image freezes at boot. I've compiled the 2.4.4, 2.4.5,
& 2.4.6 kernels with various config settings, but they all freeze at
boot. I'm currently running redhat 7.0, so I've tried compiling with
gcc (gcc 2.96 20000731) & kgcc (egcs 1.1.2 release), no luck.
I'm willing to compile the 2.4.[<4} kernels or try any other
pre-compiled kernels is anyone has a suggestion.
Please CC: me on any response
-steve
[-- Attachment #2: Type: message/rfc822, Size: 1254 bytes --]
From: Steven Lass <stevenlass1@home.com>
To: stevenlass@mail.com
Subject: bug: 2.4.[<=6] kernel has Cyrix 'coma' bug?
Date: Sat, 21 Jul 2001 22:15:10 -0500
Message-ID: <3B5A453E.15B631F9@home.com>
dev-list,
Every 2.4 kernel that I've tried freezes my Cyrix MediaGX system at boot
up.
The point at which it hangs varies, but typically the last messages
displayed are:
Working around Cyrix MediaGX virtual DMA bugs
CPU: Cyrix Media GX Core/Bus Clock Stepping 02
Checking 'hlt' instruction
My system is a PowerSpec Model 1810 (no laughs please), my Phoenix BIOS
reports "Cyrix GX 3.2 180MHz".
I've compiled/installed numerous 2.2.x kernels w/o incident. The Redhat
7.1 CDROM image freezes. I've compiled the 2.4.4, 2.4.5, & 2.4.6
kernels with various config settings, but they all freeze. I'm
currently running redhat 7.0, so I've tried compiling with gcc (gcc 2.96
20000731) & kgcc (egcs 1.1.2 release), no luck.
I'm willing to compile the 2.4.[<4} kernels or try any other
pre-compiled kernels is anyone has a suggestion.
Please CC: me on any response
-steve
^ permalink raw reply [relevance 93%]
* Debian Bug#770122: patch as workaround/solution
@ 2014-11-23 17:16 99% Elimar Riesebieter
0 siblings, 0 replies; 200+ results
From: Elimar Riesebieter @ 2014-11-23 17:16 UTC (permalink / raw)
To: alsa-devel; +Cc: Teutone, 770122
[-- Attachment #1.1.1: Type: text/plain, Size: 245 bytes --]
Hi,
Iam forwarding this Debian bug to alsa-devel due to a not maintained
BugTracker at alsa project. Could one please have a look at it?
Thanks
Elimar
--
Alles was viel bedacht wird ist bedenklich!;-)
Friedrich Nietzsche
[-- Attachment #1.1.2: Type: message/rfc822, Size: 527901 bytes --]
[-- Attachment #1.1.2.1.1.1: Type: text/plain, Size: 1275 bytes --]
Thank you for looking into this so fast!
Okay I disabled the service to get back to the state I was in:
$ sudo systemctl disable alsa-fix.service
Removed
symlink /etc/systemd/system/multi-user.target.wants/alsa-fix.service.
Btw I did a fast test before that and after resume from hibernate the
workaround doesn't seem to work anymore (only after reboot probably)...
I am still learning; am on Debian since 3 weeks.
then I did a --reinstall of alsa-base/utils & libasound2 for pristine
installation of those
$ sudo apt-get install --reinstall alsa-base alsa-utils libasound2
I checked my $home/ folder for hidden files using
$ls -a
but there is no .asoundrc file there
I made a collection of screenshots of alsamixer and pulseaudio settings
for you; I hope they can help to resolve the issue. First two
screenshots are xterm output.
As you can see the channels are correctly auto-muted when I switch from
speaker to headphone jack, but there's simply no audio coming out of
that jack. Even pulseaudio shows a sound ping when I test headphone
configuration (last screenshot). I also tried muting and unmuting in
pulseaudio settings and switching to Analog Stereo configuration, no
deal.
I hope I'm able to help you fixing this!
[-- Attachment #1.1.2.1.1.2: alsamixer_headphones.png --]
[-- Type: image/png, Size: 9383 bytes --]
[-- Attachment #1.1.2.1.1.3: alsamixer_speaker.png --]
[-- Type: image/png, Size: 9245 bytes --]
[-- Attachment #1.1.2.1.1.4: alsamixer_terminal.png --]
[-- Type: image/png, Size: 20467 bytes --]
[-- Attachment #1.1.2.1.1.5: alsamixer_terminal_headphone_1.png --]
[-- Type: image/png, Size: 28397 bytes --]
[-- Attachment #1.1.2.1.1.6: alsamixer_terminal_headphone_2.png --]
[-- Type: image/png, Size: 27475 bytes --]
[-- Attachment #1.1.2.1.1.7: alsamixer_terminal_speaker_1.png --]
[-- Type: image/png, Size: 27720 bytes --]
[-- Attachment #1.1.2.1.1.8: alsamixer_terminal_speaker_2.png --]
[-- Type: image/png, Size: 27153 bytes --]
[-- Attachment #1.1.2.1.1.9: pulseaudio_settings_config_headphones.png --]
[-- Type: image/png, Size: 18289 bytes --]
[-- Attachment #1.1.2.1.1.10: pulseaudio_settings_output_headphones.png --]
[-- Type: image/png, Size: 34294 bytes --]
[-- Attachment #1.1.2.1.1.11: pulseaudio_sound_test_headphones.png --]
[-- Type: image/png, Size: 182852 bytes --]
[-- Attachment #1.1.2.1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #1.1.3: Type: message/rfc822, Size: 8560 bytes --]
From: Elimar Riesebieter <riesebie@lxtec.de>
To: 770122@bugs.debian.org
Subject: [Pkg-alsa-devel] Bug#770122: Bug#770122: patch as workaround/solution
Date: Thu, 20 Nov 2014 17:27:06 +0100
Message-ID: <20141120162705.GB3302@galadriel.home.lxtec.de>
* Teutone <whiteteutone@gmail.com> [2014-11-19 13:35 +0100]:
> Thank you for looking into this so fast!
>
> Okay I disabled the service to get back to the state I was in:
>
> $ sudo systemctl disable alsa-fix.service
> Removed
> symlink /etc/systemd/system/multi-user.target.wants/alsa-fix.service.
>
> Btw I did a fast test before that and after resume from hibernate the
> workaround doesn't seem to work anymore (only after reboot probably)...
> I am still learning; am on Debian since 3 weeks.
>
> then I did a --reinstall of alsa-base/utils & libasound2 for pristine
> installation of those
>
> $ sudo apt-get install --reinstall alsa-base alsa-utils libasound2
>
>
> I checked my $home/ folder for hidden files using
> $ls -a
> but there is no .asoundrc file there
>
> I made a collection of screenshots of alsamixer and pulseaudio settings
> for you; I hope they can help to resolve the issue. First two
> screenshots are xterm output.
>
> As you can see the channels are correctly auto-muted when I switch from
> speaker to headphone jack, but there's simply no audio coming out of
> that jack. Even pulseaudio shows a sound ping when I test headphone
> configuration (last screenshot). I also tried muting and unmuting in
> pulseaudio settings and switching to Analog Stereo configuration, no
> deal.
Please try as user:
$ mkdir $HOME/.pulse
$ echo "autospawn=no" >> $HOME/.pulse/client.conf
This prevents pulseaudio to restart when it's down.
To shutdown pulse:
$ pulseaudio -k
Please test sound now.
To restart pulse:
$ pulseaudio -D
Elimar
--
Alles was viel bedacht wird ist bedenklich!;-)
Friedrich Nietzsche
_______________________________________________
Pkg-alsa-devel mailing list
Pkg-alsa-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-alsa-devel
[-- Attachment #1.1.4: Type: message/rfc822, Size: 8618 bytes --]
[-- Attachment #1.1.4.1.1.1: Type: text/plain, Size: 780 bytes --]
On Thu, 2014-11-20 at 17:27 +0100, Elimar Riesebieter wrote:
> Please try as user:
>
> $ mkdir $HOME/.pulse
> $ echo "autospawn=no" >> $HOME/.pulse/client.conf
>
> This prevents pulseaudio to restart when it's down.
>
> To shutdown pulse:
> $ pulseaudio -k
>
> Please test sound now.
>
> To restart pulse:
> $ pulseaudio -D
>
> Elimar
> --
> Alles was viel bedacht wird ist bedenklich!;-)
> Friedrich Nietzsche
>
Okay I tried this, but no difference to sound test with pulseaudio.
Built in speakers work, headphone jack does not play a single sound,
nothing. Speakers get auto-muted when I plug in my headphones though.
Only difference, I can't use media buttons to control volume when
pulseaudio is turned off (guess that's normal)
[-- Attachment #1.1.4.1.1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #1.1.4.1.2: Type: text/plain, Size: 185 bytes --]
_______________________________________________
Pkg-alsa-devel mailing list
Pkg-alsa-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-alsa-devel
[-- Attachment #1.1.5: Type: message/rfc822, Size: 8393 bytes --]
From: Elimar Riesebieter <riesebie@lxtec.de>
To: Teutone <whiteteutone@gmail.com>, 770122@bugs.debian.org
Subject: [Pkg-alsa-devel] Bug#770122: Bug#770122: Bug#770122: patch as workaround/solution
Date: Sat, 22 Nov 2014 12:57:12 +0100
Message-ID: <20141122115712.GA2653@galadriel.home.lxtec.de>
* Teutone <whiteteutone@gmail.com> [2014-11-21 01:55 +0100]:
> On Thu, 2014-11-20 at 17:27 +0100, Elimar Riesebieter wrote:
> > Please try as user:
> >
> > $ mkdir $HOME/.pulse
> > $ echo "autospawn=no" >> $HOME/.pulse/client.conf
> >
> > This prevents pulseaudio to restart when it's down.
> >
> > To shutdown pulse:
> > $ pulseaudio -k
> >
> > Please test sound now.
> >
> > To restart pulse:
> > $ pulseaudio -D
> >
> > Elimar
> > --
> > Alles was viel bedacht wird ist bedenklich!;-)
> > Friedrich Nietzsche
> >
>
> Okay I tried this, but no difference to sound test with pulseaudio.
> Built in speakers work, headphone jack does not play a single sound,
> nothing. Speakers get auto-muted when I plug in my headphones though.
This looks like a driver bug. As I remember you're using linux-3.16.
It's pretty new, though. In sid we have linux-3.17 images which
worth to try. If that not helps I'd forward this bug to the kernel
team with your attention please. To browse the ALSA BTS [0] might be
helpful as well.
> Only difference, I can't use media buttons to control volume when
> pulseaudio is turned off (guess that's normal)
Thats not normal. My thinkpads are working with a straight ALSA. For
me there is no advantage to run pulseaudio. The "media buttons" are
working correct. Same on my powerbook (Yeah, it's PPC arch ;-)).
[0] https://bugtrack.alsa-project.org/alsa-bug
Elimar
--
Numeric stability is probably not all that
important when you're guessing;-)
_______________________________________________
Pkg-alsa-devel mailing list
Pkg-alsa-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-alsa-devel
[-- Attachment #1.1.6: Type: message/rfc822, Size: 10574 bytes --]
[-- Attachment #1.1.6.1.1.1: Type: text/plain, Size: 2703 bytes --]
On Sat, 2014-11-22 at 12:57 +0100, Elimar Riesebieter wrote:
> * Teutone <whiteteutone@gmail.com> [2014-11-21 01:55 +0100]:
>
> > On Thu, 2014-11-20 at 17:27 +0100, Elimar Riesebieter wrote:
> > > Please try as user:
> > >
> > > $ mkdir $HOME/.pulse
> > > $ echo "autospawn=no" >> $HOME/.pulse/client.conf
> > >
> > > This prevents pulseaudio to restart when it's down.
> > >
> > > To shutdown pulse:
> > > $ pulseaudio -k
> > >
> > > Please test sound now.
> > >
> > > To restart pulse:
> > > $ pulseaudio -D
> > >
> > > Elimar
> > > --
> > > Alles was viel bedacht wird ist bedenklich!;-)
> > > Friedrich Nietzsche
> > >
> >
> > Okay I tried this, but no difference to sound test with pulseaudio.
> > Built in speakers work, headphone jack does not play a single sound,
> > nothing. Speakers get auto-muted when I plug in my headphones though.
>
> This looks like a driver bug. As I remember you're using linux-3.16.
> It's pretty new, though. In sid we have linux-3.17 images which
> worth to try. If that not helps I'd forward this bug to the kernel
> team with your attention please. To browse the ALSA BTS [0] might be
> helpful as well.
I looked through the changelogs on
http://metadata.ftp-master.debian.org/changelogs//main/l/linux/linux_3.17-1~exp1_changelog and http://kernelnewbies.org/Linux_3.17 and could not find any news about audio drivers - plus I read the warning about data loss and experimental state of 3.17, and I'm feeling unsure if it's safe for me to use it, I am not that good at Linux yet... if you say it's relatively safe could you give me a few hints how to do the kernel update safely or point me to the direction where I can read about how to do it, please?
>
> > Only difference, I can't use media buttons to control volume when
> > pulseaudio is turned off (guess that's normal)
>
> Thats not normal. My thinkpads are working with a straight ALSA. For
> me there is no advantage to run pulseaudio. The "media buttons" are
> working correct. Same on my powerbook (Yeah, it's PPC arch ;-)).
Hmm. That's strange then... something seems really wrong with this
Macbook ***** :P I recently noticed that I have a slight sound problem
with my speakers, too - in Mac OS + Windows I get decent sound from
right and left built-in speaker; in Debian Jessie I only have the right
speaker working correctly, but the left one is a lot quieter... as if
it's also not working 100% with the driver...
>
> [0] https://bugtrack.alsa-project.org/alsa-bug
I'm unable to open that site - it seems to be down? Even with simple
http:// it just gives me a 404 Error... is it reachable for you?
Teutone
[-- Attachment #1.1.6.1.1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #1.1.6.1.2: Type: text/plain, Size: 185 bytes --]
_______________________________________________
Pkg-alsa-devel mailing list
Pkg-alsa-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-alsa-devel
[-- Attachment #1.1.7: Type: message/rfc822, Size: 9984 bytes --]
From: Elimar Riesebieter <riesebie@lxtec.de>
To: Teutone <whiteteutone@gmail.com>, 770122@bugs.debian.org
Subject: [Pkg-alsa-devel] Bug#770122: Bug#770122:
Date: Sat, 22 Nov 2014 15:59:07 +0100
Message-ID: <20141122145907.GA2531@galadriel.home.lxtec.de>
* Teutone <whiteteutone@gmail.com> [2014-11-22 15:06 +0100]:
> On Sat, 2014-11-22 at 12:57 +0100, Elimar Riesebieter wrote:
[...]
> > This looks like a driver bug. As I remember you're using linux-3.16.
> > It's pretty new, though. In sid we have linux-3.17 images which
> > worth to try. If that not helps I'd forward this bug to the kernel
> > team with your attention please. To browse the ALSA BTS [0] might be
> > helpful as well.
>
> I looked through the changelogs on
> http://metadata.ftp-master.debian.org/changelogs//main/l/linux/linux_3.17-1~exp1_changelog
> and http://kernelnewbies.org/Linux_3.17 and could not find any
> news about audio drivers - plus I read the warning about data loss
> and experimental state of 3.17, and I'm feeling unsure if it's
> safe for me to use it, I am not that good at Linux yet... if you
> say it's relatively safe could you give me a few hints how to do
> the kernel update safely or point me to the direction where I can
> read about how to do it, please?
Well, linux-3.17 is the stable mainline kernel. It's not
experimental and there are no known bugs about data loss. If you're
not comfortable to try 3.17 I can tell you that this kernel runs
fine. (3.14.25, 3.17.4, 3.18-rc5 here). But I won't force you to use
it. You can otherwise try some Live-Distros (Knoppix, GRML a.o) to
check your soundcard. Those are not running 3.17!
How to install Debian's 3.17:
As root:
# echo "deb http://ftp.de.debian.org/debian/unstable main non-free contrib" >> /etc/apt/sources.list.d/teutone.list
# apt-get update
# apt-get install -t unstable linux-image-3.17-1-amd64
Reboot to load the new kerenl and test sound.
To reverse it:
# rm -rf /etc/apt/sources.list.d/teutone.list
# apt-get update
# apt-get remove --purge linux-image-3.17-1-amd64
Thats it ;-)
>
> >
> > > Only difference, I can't use media buttons to control volume when
> > > pulseaudio is turned off (guess that's normal)
> >
> > Thats not normal. My thinkpads are working with a straight ALSA. For
> > me there is no advantage to run pulseaudio. The "media buttons" are
> > working correct. Same on my powerbook (Yeah, it's PPC arch ;-)).
>
> Hmm. That's strange then... something seems really wrong with this
> Macbook ***** :P I recently noticed that I have a slight sound problem
> with my speakers, too - in Mac OS + Windows I get decent sound from
> right and left built-in speaker; in Debian Jessie I only have the right
> speaker working correctly, but the left one is a lot quieter... as if
> it's also not working 100% with the driver...
If there is a hardware bug you can check live distris as mentioned
above. But there we can't help. Success to your hardware is needed,
though....
>
> >
> > [0] https://bugtrack.alsa-project.org/alsa-bug
>
> I'm unable to open that site - it seems to be down? Even with simple
> http:// it just gives me a 404 Error... is it reachable for you?
It looks like it is temporarely down :(
Elimar
--
On the keyboard of life you have always
to keep a finger at the escape key;-)
_______________________________________________
Pkg-alsa-devel mailing list
Pkg-alsa-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-alsa-devel
[-- Attachment #1.1.8: Type: message/rfc822, Size: 9937 bytes --]
[-- Attachment #1.1.8.1.1.1: Type: text/plain, Size: 1960 bytes --]
On Sat, 2014-11-22 at 15:59 +0100, Elimar Riesebieter wrote:
> * Teutone <whiteteutone@gmail.com> [2014-11-22 15:06 +0100]:
>
> > On Sat, 2014-11-22 at 12:57 +0100, Elimar Riesebieter wrote:
> [...]
> Well, linux-3.17 is the stable mainline kernel. It's not
> experimental and there are no known bugs about data loss. If you're
> not comfortable to try 3.17 I can tell you that this kernel runs
> fine. (3.14.25, 3.17.4, 3.18-rc5 here). But I won't force you to use
> it. You can otherwise try some Live-Distros (Knoppix, GRML a.o) to
> check your soundcard. Those are not running 3.17!
>
> How to install Debian's 3.17:
> As root:
> # echo "deb http://ftp.de.debian.org/debian/unstable main non-free contrib" >> /etc/apt/sources.list.d/teutone.list
> # apt-get update
> # apt-get install -t unstable linux-image-3.17-1-amd64
>
> Reboot to load the new kerenl and test sound.
>
> To reverse it:
> # rm -rf /etc/apt/sources.list.d/teutone.list
> # apt-get update
> # apt-get remove --purge linux-image-3.17-1-amd64
>
> Thats it ;-)
Alright, thanks for the fast response and extra terminal help ; ) (had
to switch to experimental debian distro + install kernel-headers as
well)
I am now on
uname -r
3.17-1-amd64
and tested my headphones after rebooting--- no difference. Still silent
as a grave. What's the next step then?
> > Hmm. That's strange then... something seems really wrong with this
> > Macbook ***** :P I recently noticed that I have a slight sound problem
> > with my speakers, too - in Mac OS + Windows I get decent sound from
> > right and left built-in speaker; in Debian Jessie I only have the right
> > speaker working correctly, but the left one is a lot quieter... as if
> > it's also not working 100% with the driver...
>
> If there is a hardware bug you can check live distris as mentioned
> above. But there we can't help. Success to your hardware is needed,
> though....
[-- Attachment #1.1.8.1.1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #1.1.8.1.2: Type: text/plain, Size: 185 bytes --]
_______________________________________________
Pkg-alsa-devel mailing list
Pkg-alsa-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-alsa-devel
[-- Attachment #1.1.9: Type: message/rfc822, Size: 9037 bytes --]
From: Elimar Riesebieter <riesebie@lxtec.de>
To: Teutone <whiteteutone@gmail.com>, 770122@bugs.debian.org
Subject: [Pkg-alsa-devel] Bug#770122: patch as workaround/solution
Date: Sun, 23 Nov 2014 14:54:20 +0100
Message-ID: <20141123135420.GA2868@galadriel.home.lxtec.de>
* Teutone <whiteteutone@gmail.com> [2014-11-22 21:13 +0100]:
> On Sat, 2014-11-22 at 15:59 +0100, Elimar Riesebieter wrote:
[...]
> > As root:
> > # echo "deb http://ftp.de.debian.org/debian/unstable main non-free contrib" >> /etc/apt/sources.list.d/teutone.list
> > # apt-get update
> > # apt-get install -t unstable linux-image-3.17-1-amd64
> >
> > Reboot to load the new kerenl and test sound.
> >
> > To reverse it:
> > # rm -rf /etc/apt/sources.list.d/teutone.list
> > # apt-get update
> > # apt-get remove --purge linux-image-3.17-1-amd64
> >
> > Thats it ;-)
>
> Alright, thanks for the fast response and extra terminal help ; ) (had
> to switch to experimental debian distro + install kernel-headers as
> well)
>
>
> I am now on
> uname -r
> 3.17-1-amd64
>
> and tested my headphones after rebooting--- no difference. Still silent
> as a grave. What's the next step then?
Forwarding this bug to the Debian kernel team and upstream.
Please be careful by updates now. First remove your source.list.d
entries for experimental, apr-get remove purge 3.17 and and run a
"apt-get update && apt-get dist-upgrade".
>
> > > Hmm. That's strange then... something seems really wrong with this
> > > Macbook ***** :P I recently noticed that I have a slight sound problem
> > > with my speakers, too - in Mac OS + Windows I get decent sound from
> > > right and left built-in speaker; in Debian Jessie I only have the right
> > > speaker working correctly, but the left one is a lot quieter... as if
> > > it's also not working 100% with the driver...
> >
> > If there is a hardware bug you can check live distris as mentioned
> > above. But there we can't help. Success to your hardware is needed,
> > though....
Before forwarding the bug we must be sure your hardware works correct.
Could you test another headpone and/or speaker set meanwhile?
Elimar
--
>what IMHO then?
IMHO - Inhalation of a Multi-leafed Herbal Opiate ;)
--posting from alex in debian-user--
_______________________________________________
Pkg-alsa-devel mailing list
Pkg-alsa-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-alsa-devel
[-- Attachment #1.1.10: Type: message/rfc822, Size: 3580 bytes --]
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Elimar Riesebieter <riesebie@lxtec.de>
Subject: Bug#770122: Info received (Bug#770122: patch as workaround/solution)
Date: Sun, 23 Nov 2014 13:57:08 +0000
Message-ID: <handler.770122.B770122.141675090215306.ackinfo@bugs.debian.org>
Thank you for the additional information you have supplied regarding
this Bug report.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.
Your message has been sent to the package maintainer(s):
Debian ALSA Maintainers <pkg-alsa-devel@lists.alioth.debian.org>
If you wish to submit further information on this problem, please
send it to 770122@bugs.debian.org.
Please do not send mail to owner@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.
--
770122: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770122
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
[-- Attachment #1.1.11: Type: message/rfc822, Size: 9499 bytes --]
[-- Attachment #1.1.11.1.1.1: Type: text/plain, Size: 1422 bytes --]
On Sun, 2014-11-23 at 14:54 +0100, Elimar Riesebieter wrote:
> Please be careful by updates now. First remove your source.list.d
> entries for experimental, apr-get remove purge 3.17 and and run a
> "apt-get update && apt-get dist-upgrade".
Okay, I followed the steps to revert to 3.16-4 and am back on
3.16.0-4-amd64 now.
> > > > Hmm. That's strange then... something seems really wrong with this
> > > > Macbook ***** :P I recently noticed that I have a slight sound problem
> > > > with my speakers, too - in Mac OS + Windows I get decent sound from
> > > > right and left built-in speaker; in Debian Jessie I only have the right
> > > > speaker working correctly, but the left one is a lot quieter... as if
> > > > it's also not working 100% with the driver...
> > >
> > > If there is a hardware bug you can check live distris as mentioned
> > > above. But there we can't help. Success to your hardware is needed,
> > > though....
>
> Before forwarding the bug we must be sure your hardware works correct.
> Could you test another headpone and/or speaker set meanwhile?
My hardware is absolutely fine; I boot into three different OS on my
Macbook: Debian Jessie, Windows & Mac OS - on Windows & Mac OS I have no
problems with neither the built-in speakers of the Macbook nor my good
old headphones. Forwarding this should be allright. Thank you for your
help until now!
Teutone
[-- Attachment #1.1.11.1.1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #1.1.11.1.2: Type: text/plain, Size: 185 bytes --]
_______________________________________________
Pkg-alsa-devel mailing list
Pkg-alsa-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-alsa-devel
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-200 of ~385414 next [<= 82%] | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2014-11-23 17:16 99% Debian Bug#770122: patch as workaround/solution Elimar Riesebieter
2001-07-22 13:10 93% bug: 2.4.[<=6] kernel has Cyrix 'coma' bug? Steven Lass
2001-07-22 21:36 82% ` Steven Lass
2014-06-16 3:02 90% Bug is a rework idea and not a bug for Bug Id 72851 on Bugzilla Nick Krause
2014-06-16 3:02 90% ` Nick Krause
2014-06-16 3:02 90% ` Nick Krause
[not found] <96DQe4a_2tH.A.4RE.497GNB@chimera>
2010-12-29 23:07 90% ` [Bug #25822] [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8 Rafael J. Wysocki
[not found] <20070208213609.GA6406@hardeman.nu>
[not found] ` <20070208215149.GL32661@doriath.informatik.uni-erlangen.de>
[not found] ` <22206.145.64.134.242.1171025126.squirrel@www.hardeman.nu>
[not found] ` <20070209134251.GO32661@doriath.informatik.uni-erlangen.de>
[not found] ` <35325.145.64.134.242.1171035160.squirrel@www.hardeman.nu>
[not found] ` <20070209155857.GP32661@doriath.informatik.uni-erlangen.de>
[not found] ` <56504.145.64.134.242.1171044839.squirrel@www.hardeman.nu>
[not found] ` <20070209183546.GQ32661@doriath.informatik.uni-erlangen.de>
[not found] ` <20070209203247.GA5378@hardeman.nu>
[not found] ` <20070209204431.GR32661@doriath.informatik.uni-erlangen.de>
2007-02-09 21:28 90% ` Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875 David Härdeman
[not found] <bug-45941-13602@https.bugzilla.kernel.org/>
2012-08-14 11:43 90% ` [Bug 45941] BUG: soft lockup - CPU#1 stuck for 21s! [kworker/1:1:64] BUG: soft lockup - CPU#4 stuck for 22s! [flush-252:0:384] bugzilla-daemon
2013-11-19 23:36 90% ` bugzilla-daemon
2012-08-24 10:05 90% ` bugzilla-daemon
[not found] <20060903124043.2028.48247.reportbug@forza>
[not found] ` <1157367160.32195.54.camel@aeonflux.holtmann.net>
[not found] ` <20060904100025.GA17058@esaurito.net>
[not found] ` <1157371912.32195.69.camel@aeonflux.holtmann.net>
2006-09-05 10:32 ` [Bluez-devel] Bug#385857: [Pkg-bluetooth-maintainers] Bug#385857: please upgrade to bluez-utils and bluez-libs 3.4 Filippo Giunchedi
2006-09-05 11:07 90% ` Bug#385857: " Marcel Holtmann
[not found] <bug-110972-502@http.bugs.freedesktop.org/>
2019-06-23 22:20 90% ` [Bug 110972] bug bug bugzilla-daemon
2019-06-23 14:02 90% ` bugzilla-daemon
2008-04-08 23:02 90% [Bug #10290] [BUG] Linux 2.6.25-rc6 - kernel BUG at fs/mpage.c:476! on powerpc Rafael J. Wysocki
[not found] <1313577856.13030.17.camel@scarafaggio>
2011-08-22 9:00 ` Bug#638172: BUG: soft lockup - CPU#0 stuck for 61s! [qemu-dm:3205] Ian Campbell
2011-08-24 20:24 ` Konrad Rzeszutek Wilk
2011-08-24 21:24 ` Ian Campbell
2011-08-25 6:52 90% ` Bug#638172: [Xen-devel] " Giuseppe Sacco
2011-08-25 6:56 ` Ian Campbell
2011-08-26 7:25 90% ` Bug#638172: " Ian Campbell
2011-08-26 8:28 90% ` Giuseppe Sacco
2011-08-26 8:31 90% ` Ian Campbell
2011-10-18 10:54 90% ` Ian Campbell
2011-10-18 11:00 90% ` Giuseppe Sacco
2011-08-25 7:23 90% ` Bug#638172: [Xen-devel] " Giuseppe Sacco
[not found] <bug-19942-10286@https.bugzilla.kernel.org/>
2010-10-11 20:45 89% ` [Bugme-new] [Bug 19942] New: Not a intel bug: kernel BUG at drivers/pci/intel-iommu.c:1656 Andrew Morton
[not found] <1c2b5af4-ea57-0b07-723d-cb4ccb760219@free.fr>
[not found] ` <2e69cb23-06ee-5bcd-4feb-0eb88c0f4143@free.fr>
[not found] ` <2e69cb23-06ee-5bcd-4feb-0eb88c0f4143-GANU6spQydw@public.gmane.org>
2019-01-31 16:02 88% ` Fwd: Bug#921004: downgrade to firmware-amd-graphics_20180825-1_all.deb Michel Dänzer
2012-08-05 22:36 87% [bugzilla-daemon@bugzilla.kernel.org: [Bug 45621] New: Kernel ooops: BUG: unable to handle kernel paging request at 000000080000001c] Theodore Ts'o
2005-12-05 14:57 87% Bug#341392: (fwd) Bug#341392: linux-2.6: kernel BUG at mm/slab.c:1807! maximilian attems
2008-08-31 4:51 87% [PATCH]atl1e:fix bug [Bug 11454] New: atl1e - BUG: scheduling while atomic: modprobe/678/0x00000002 jie.yang
2008-08-31 5:08 90% ` Matthew Wilcox
2008-08-31 5:31 89% ` Jie Yang
2004-02-25 23:48 85% [Bug 2195] New: Reproduced bug 1594: kernel BUG at mm/slab.c:1269 Martin J. Bligh
[not found] <20070911200437.GS17585@frodo.home.lxtec.de>
[not found] ` <20070120144825.28798.9415.reportbug@nias.19.ros.03046.com>
2007-09-11 20:06 84% ` Bug#407690: marked as done (ld10k1 segfaults on 2.6.19 kernel) Debian Bug Tracking System
[not found] <20070911201728.GT17585@frodo.home.lxtec.de>
[not found] ` <20070610045818.5861.54596.reportbug@jidanni2.jidanni.org>
2007-09-11 20:21 83% ` Bug#428234: marked as done (linux-sound-base: not empty so not removed) Debian Bug Tracking System
2009-10-13 20:09 83% [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot path [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot path [PATCH] git-p4: Fixed bug that didn't allow spaces in the depot path Per Strandh
2002-10-04 11:57 82% Wildcards matching ".": exports bug or just documentation bug? Stephen C. Tweedie
2002-11-13 13:55 82% ` Stephen C. Tweedie
[not found] <Pine.LNX.4.44.0305132214120.2091-100000@moisil.badula.org>
2003-05-14 8:27 82% ` FW: am-utils or kernel bug ? Seems to be kernel or glibc bug Nicolas Turro
2003-05-14 13:35 82% ` Ion Badulescu
2002-10-07 23:49 82% BUG: 2.5.41 left raid array to unclean mode (Kernel bug at raid1.c:667) Jani Averbach
2003-01-19 14:04 82% [Bug + Patch] opl3sa2 unregister bug Daniel Ritz
2003-02-28 15:28 82% Bug report bounced + bug report Han Holl
2003-02-28 16:58 82% ` Alan Cox
2001-03-22 7:15 82% [BUG] kernel BUG at slab.c:1402! -- 2.4.2-0.1.28 Greg Billock
2001-03-22 7:36 82% ` Keith Owens
2001-03-22 8:08 82% ` Andrew Morton
2003-01-07 21:10 82% [BUG] floopy driver bug in 2.4.20 Pozsar Balazs
2002-12-18 20:06 82% Bug by starting with missed first devies - bug fix included !! Christoph Plattner
2006-03-02 5:08 82% Attempting to use SCSI tape drive triggers kernel BUG Dave Jones
2001-05-27 17:20 82% BUG?: 2.4.5 breaks reiserfs (kernel BUG) Bjerkeset, Svein Olav
2001-05-27 22:22 82% ` Alexander Viro
2001-12-05 19:21 82% VIA acknowledges North Bridge bug (AKA Linux Kernel with Athlon optimizations bug) Troels Walsted Hansen
2001-12-05 21:09 82% ` Calin A. Culianu
2003-07-15 8:34 82% am-utils or kernel bug ? Seems to be kernel bug.. Any news ? Nicolas Turro
2003-07-15 14:35 82% ` Philippe Troin
2003-07-15 16:18 82% ` Nicolas Turro
2003-07-16 3:28 82% ` Philippe Troin
2001-12-24 22:48 82% [Fwd: Re: SDDR-31, or possible kernel bug] Kyle
[not found] <15778.27247.271665.487076@notabene.cse.unsw.edu.au>
2002-10-08 15:09 82% ` BUG: 2.5.41 left raid array to unclean mode (Kernel bug at raid1.c:667) Jani Averbach
2003-04-02 18:50 82% [BUG] E7x05 chipset bug in 2.5 kernels' AGPGART driver Fendrakyn
2003-04-02 22:10 ` Dave Jones
2003-04-04 7:58 82% ` Denis Vlasenko
[not found] <8E2EEEE24B6FD211ADC400104B71BA020169DB4A@MESSAGING>
2001-04-16 20:25 82% ` 2.4.3 VFS bug and namei.c bug Andre Hedrick
2001-09-08 11:06 82% 2.4.10-pre5: Bug in alloc_pages [should be bug in page_alloc.c] Nick Piggin
2002-04-10 7:04 82% Kernel Bug or XFree Bug? Brett Nuske
2001-06-19 10:34 82% [BUG] bug in mmap_kmem Yoav Etsion
2002-10-12 19:28 82% :Re: Bug on Mdk 9.0 Hell.Surfers
2001-02-12 12:03 82% [Linux-ia64] Pagesize bug vs. libpthread bug :( Francis Galiegue
2002-12-22 2:50 82% Dedicated kernel bug database Hell.Surfers
2002-01-17 16:27 82% [BUG] Suspected bug in getpeername and getsockname Balbir Singh
2002-01-17 20:24 82% ` kuznet
2002-01-17 21:11 82% ` David S. Miller
2003-06-03 13:54 82% Unconfirmed bug reports in my bug database john
2001-02-12 15:35 82% [Linux-ia64] Re: Pagesize bug vs. libpthread bug :( Bill Nottingham
2002-01-17 23:35 82% [BUG] Suspected bug in getpeername and getsockname Balbir Singh
2001-07-25 5:15 82% [BUG] hotplug network agent / apmd bug Ryan Mack
2001-07-25 20:23 82% ` Ryan Mack
2001-07-25 14:39 82% ` David Brownell
2002-01-18 0:05 82% [BUG] Suspected bug in getpeername and getsockname Balbir Singh
[not found] <Pine.LNX.4.21.0010171527340.2124-100000@anime.net>
2000-11-03 1:26 82% ` [tulip-bug] ADMtek Comet bug Dan Hollis
[not found] <Pine.LNX.4.55L.0307150859130.5146@freak.distro.conectiva>
[not found] ` <1058297936.4016.86.camel@tiny.suse.com>
[not found] ` <Pine.LNX.4.55L.0307160836270.30825@freak.distro.conectiva>
[not found] ` <20030718112758.1da7ab03.skraw@ithnet.com>
2003-07-18 12:23 82% ` Bug Report: 2.4.22-pre5: BUG in page_alloc (fwd) Marcelo Tosatti
2003-07-18 12:50 ` Stephan von Krawczynski
2003-07-18 14:14 82% ` Marcelo Tosatti
2003-07-18 15:13 82% ` Stephan von Krawczynski
2002-01-17 22:11 82% [BUG] Suspected bug in getpeername and getsockname Balbir Singh
2002-06-01 1:33 82% [small BUG] Makefile bug with gcc 3.1 and non english locales Edouard Gomez
2002-06-01 1:44 82% ` Kai Germaschewski
2003-03-12 2:08 82% [Bug] module unloading or unmap_vma bug ? Xiong Jiang
2000-09-11 15:19 82% [Fwd: [parisc-linux] Bug report] Ryan Bradetich
2001-07-11 18:01 82% PROBLEM: <BUG Report: kernel BUG at slab.c:1062! from pppd with speedtouch drivers and pppoatm> Richard Purdie
2001-07-11 18:19 82% ` Georg Nikodym
2003-03-10 15:16 82% Fwd: tcp seq nr wrapping bug + patch Ulrik De Bie
2003-04-24 18:33 82% [BUG 2.5.X] pipe/fcntl/F_GETFL/F_SETFL obvious kernel bug Jean Tourrilhes
2003-04-24 21:23 82% ` Andrew Morton
2003-04-24 21:35 82% ` Jean Tourrilhes
2003-02-08 20:45 82% [Kernel Bug Database] Bug report 34 - Matrox framebuffer drivers don't compile John Bradford
2003-02-12 20:52 82% ` James Simmons
2002-10-14 20:36 [BUG] raw over raid5: BUG at drivers/block/ll_rw_blk.c:1967 David Mansfield
2002-10-15 6:41 82% ` Neil Brown
2002-10-14 20:49 82% ` Andrew Morton
2002-10-14 21:57 82% ` David Mansfield
2002-10-14 22:18 82% ` David Mansfield
2002-02-26 11:37 ISO9660 bug and loopback driver bug Barubary
2002-02-26 11:54 82% ` Jesper Juhl
2002-02-26 12:01 82% ` Rainer Ellinger
2002-02-26 12:08 82% ` Barubary
2002-02-26 12:04 82% ` Alan Cox
2002-02-26 12:02 82% ` Barubary
2002-02-26 12:37 82% ` Alan Cox
2002-11-02 18:37 [BUG] USB Kernel bug in 2.5.45 Jochen Friedrich
2002-11-02 20:44 82% ` Greg KH
2002-11-02 23:10 82% ` Jochen Friedrich
2002-11-02 23:24 82% ` Greg KH
2012-03-04 20:29 3.3-rc6: Reported regressions from 3.2 Rafael J. Wysocki
2012-03-04 20:31 90% ` [Bug #42850] [BUG] Kernel Bug at fs/btrfs/volumes.c:3638 Rafael J. Wysocki
2012-03-04 20:31 90% ` Rafael J. Wysocki
2011-02-12 23:34 2.6.38-rc4-git5: Reported regressions 2.6.36 -> 2.6.37 Rafael J. Wysocki
2011-02-12 23:38 90% ` [Bug #25822] [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8 Rafael J. Wysocki
2011-02-12 23:38 90% ` Rafael J. Wysocki
2003-07-15 8:23 [BUG] kernel BUG at kernel/timer.c 2.6.0-test1 Rafal Bujnowski
2003-07-16 6:06 82% ` Paul Rolland
2003-07-17 8:06 82% ` Rafal Bujnowski
2007-01-15 10:18 [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf() Ludovic Drolez
2007-01-15 11:54 ` Carlo Marcelo Arenas Belon
2007-01-15 14:16 ` Julian Seward
2007-01-16 11:22 90% ` [Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf() + MMX bug Ludovic Drolez
2007-01-16 16:19 90% ` Ludovic Drolez
2007-01-16 17:50 90% ` Aurelien Jarno
2017-09-13 11:45 [U-Boot] [PATCH 0/6] Sync and consolidate Linux-derived printk, BUILD_BUG, BUG, WARN, etc Masahiro Yamada
2017-09-13 11:45 84% ` [U-Boot] [PATCH 6/6] bug.h: move runtime BUG/WARN macros into <linux/bug.h> Masahiro Yamada
2000-11-15 4:35 [BUG?] AMD K5 and 2.4 (was Re: Updated 2.4 TODO List) Barry K. Nathan
2000-11-15 19:58 82% ` [BUG?] AMD 5x86 and 2.4 (was Re: [BUG?] AMD K5 and 2.4) Barry K. Nathan
2000-11-27 1:25 82% ` Andreas Eibach
2000-11-16 11:00 82% ` Vojtech Pavlik
2002-02-26 23:17 ISO9660 bug and loopback driver bug - a bigger problem then it would appear? Jesper Juhl
2002-02-27 14:29 82% ` Richard B. Johnson
2002-02-27 16:54 82% ` Jesper Juhl
2012-03-11 21:23 3.3-rc7: Reported regressions from 3.2 Rafael J. Wysocki
2012-03-11 21:31 90% ` [Bug #42850] [BUG] Kernel Bug at fs/btrfs/volumes.c:3638 Rafael J. Wysocki
2012-03-11 21:31 90% ` Rafael J. Wysocki
2000-11-17 22:41 [PATCH] raid5 fix after xor.c cleanup Jasper Spaans
2000-11-18 11:35 ` Jasper Spaans
2000-11-18 22:53 ` [BUG] raid5 link error? (was [PATCH] raid5 fix after xor.c cleanup) Jasper Spaans
2000-11-20 0:41 ` Neil Brown
2000-11-26 2:26 ` [BUG] 2.4.0-test11-ac3 breaks raid autodetect (was Re: [BUG] raid5 link error? (was [PATCH] raid5 fix after xor.c cleanup)) Friedrich Lobenstock
2000-11-27 2:18 ` Neil Brown
2000-11-27 8:12 82% ` Luca Berra
2000-11-27 10:49 82% ` [KBUILD] " Christoph Hellwig
2001-06-19 21:23 intermittent hangs with threads (clone() bug?/linuxthreads bug?) Ed Connell
2001-06-20 8:22 82% ` bert hubert
2011-02-03 0:03 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37 Rafael J. Wysocki
2011-02-03 0:05 90% ` [Bug #25822] [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8 Rafael J. Wysocki
2011-02-03 0:05 90% ` Rafael J. Wysocki
2002-08-26 18:07 [BUG/PATCH] : bug in tty_default_put_char() Jean Tourrilhes
2002-08-26 19:31 82% ` Russell King
[not found] ` <20020826195346.GC8749@bougret.hpl.hp.com>
[not found] ` <20020826210159.E4763@flint.arm.linux.org.uk>
[not found] ` <20020826201732.GE8749@bougret.hpl.hp.com>
[not found] ` <20020826212223.H4763@flint.arm.linux.org.uk>
2002-08-28 22:41 ` Jean Tourrilhes
2002-08-28 23:16 82% ` Russell King
[not found] ` <1030388224.2797.2.camel@irongate.swansea.linux.org.uk>
2002-08-26 18:59 82% ` Jean Tourrilhes
2002-08-26 19:07 82% ` Alan Cox
2002-08-26 20:17 82% ` Russell King
2002-10-26 14:49 "mount" bug Harry Kalogirou
2002-10-27 12:57 82% ` fork bug [WAS: Re: "mount" bug] jb1
2002-10-27 19:49 82% ` Harry Kalogirou
2003-07-09 4:49 [Bug 892] New: kernel BUG at include/linux/list.h:148! Martin J. Bligh
2003-07-09 5:21 82% ` Andrew Morton
2003-01-15 21:33 [BUG] 2.5.5{7,8} QM_MODULES: Function not implemented Damian Kołkowski
2003-01-16 7:31 82% ` [BUG] QM_MODULES: Function not implemented... [ No bug! ] Damian Kolkowski
2002-11-04 2:22 linux/bug.h and asm/bug.h Rusty Russell
2002-11-04 2:43 82% ` William Lee Irwin III
2002-11-04 12:41 82% ` Ralf Baechle
2002-11-04 12:51 82% ` Russell King
2002-11-04 13:39 82% ` William Lee Irwin III
2002-10-29 20:15 [BUG] yet another icmp reply transition bug Harald Welte
2002-10-30 18:44 ` Balazs Scheidler
2002-10-31 9:13 82% ` Harald Welte
2002-10-31 9:49 82% ` Balazs Scheidler
2008-04-13 18:53 2.6.25-rc9: Reported regressions from 2.6.24 Rafael J. Wysocki
2008-04-13 18:56 90% ` [Bug #10290] [BUG] Linux 2.6.25-rc6 - kernel BUG at fs/mpage.c:476! on powerpc Rafael J. Wysocki
2002-01-17 23:20 [BUG] Suspected bug in getpeername and getsockname Balbir Singh
2002-01-17 23:26 82% ` David S. Miller
2003-06-14 6:35 [patch][2.5] speedstep_detect_speed might not reenable interrupts Samuel Thibault
2003-06-14 7:37 ` [BUG] 2.4.21 - kernel BUG at dev.c:991 Christopher S. Aker
2003-06-14 8:04 82% ` Christopher S. Aker
2009-05-05 10:28 [STABLE] Updates for BUG device Marcin Juszkiewicz
2009-05-05 10:28 89% ` [STABLE][PATCH 1/1] u-boot-bug: Added U-Boot for BUG (from BUG Labs SVN) Marcin Juszkiewicz
2009-05-05 11:25 90% ` Philip Balister
2002-05-24 10:04 [BUG] 2.4 VM sucks. Again Roy Sigurd Karlsbakk
2002-05-24 14:35 ` Martin J. Bligh
2002-05-24 19:32 ` Andrew Morton
2002-07-10 7:50 82% ` [2.4 BUFFERING BUG] (was [BUG] 2.4 VM sucks. Again) Roy Sigurd Karlsbakk
2002-07-10 8:05 82% ` Andrew Morton
2002-07-10 8:14 82% ` Roy Sigurd Karlsbakk
2011-06-10 10:00 [PATCH 0/1] libQtopenGL: Enable QtOpenGL Xiaofeng Yan
2011-06-10 10:00 90% ` [PATCH 1/1] poky-lsb: Compile library libQtOpenGL* for building an lsb image Fix bug [YOCTO #1020] This patch is part of fixing bug [YOCTO #1020]. If another patch to install libQtOpenGL* to lsb image is merged to poky, \ then this bug will be fixed.For an lsb image prepared to meet lsb requirement, library "libQtOpenGL*" should be compiled. So I add this patch for passing lsb test Xiaofeng Yan
2002-01-16 0:51 [BUG] Suspected bug in getpeername and getsockname Balbir Singh
2002-01-17 0:54 82% ` David S. Miller
2001-07-11 15:11 PROBLEM: <BUG Report: kernel BUG at slab.c:1062! from pppd with speedtouch drivers and pppoatm> Richard Purdie
2001-07-11 16:14 82% ` Greg KH
2001-07-11 15:37 82% ` dr john halewood
2001-07-11 15:55 82% ` Richard Purdie
2001-07-11 23:36 ` Richard Purdie
2001-07-11 23:51 82% ` Linus Torvalds
[not found] ` <200107112351.f6BNpa304221@penguin.transmeta.com>
2001-07-12 15:10 82% ` Richard Purdie
2003-03-21 7:58 2.5.65-mm3 Andrew Morton
2003-03-21 15:23 ` [BUG] 2.5.65-mm3 kernel BUG at fs/ext3/super.c:1795! Alexander Hoogerhuis
2003-03-21 20:39 82% ` Andrew Morton
2003-03-21 20:39 82% ` Andrew Morton
2003-03-22 2:55 82% ` Alexander Hoogerhuis
2003-03-22 2:55 82% ` Alexander Hoogerhuis
2011-02-21 22:29 2.6.38-rc5-git6: Reported regressions 2.6.36 -> 2.6.37 Rafael J. Wysocki
2011-02-21 22:37 90% ` [Bug #25822] [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8 Rafael J. Wysocki
2011-02-21 22:37 90% ` Rafael J. Wysocki
2001-11-12 16:42 PATCH 2.4.14 mregparm=3 compilation fixes Linus Torvalds
2001-11-12 18:51 ` Martin Dalecki
2001-11-12 20:05 ` Corsspatch patch-2.4.15-pre2 patch-2.4.15-pre3 Martin Dalecki
2001-11-12 20:13 82% ` BUG BUG hunt the bugs!!! patch-2.4.15-pre5 Martin Dalecki
2017-09-16 5:10 [U-Boot] [PATCH v2 0/8] Sync and consolidate Linux-derived printk, BUILD_BUG, BUG, WARN, etc Masahiro Yamada
2017-09-16 5:10 84% ` [U-Boot] [PATCH v2 7/8] bug.h: move runtime BUG/WARN macros into <linux/bug.h> Masahiro Yamada
2017-10-05 21:52 90% ` [U-Boot] [U-Boot, v2, " Tom Rini
2003-04-16 11:03 Fwd: [Bug 592] New: BUG at kernel/softirq.c:105 Russell King
2003-04-16 11:23 82% ` Patrick McHardy
2006-05-19 20:48 [Bluez-devel] more on this bug (was: rfcomm bind fails with obscure error message) Filippo Giunchedi
2006-05-29 13:16 ` [Pkg-bluetooth-maintainers] Bug#322732: " Marcel Holtmann
2006-06-04 15:15 90% ` Bug#322732: " Filippo Giunchedi
2006-06-04 15:46 90% ` Bug#322732: [Bluez-devel] [Pkg-bluetooth-maintainers] Bug#322732: " Marcel Holtmann
2001-08-17 10:13 K6 sig11 Bug detection James Nord
2001-08-17 12:05 82% ` [New URL FOR K6 bug] " André Dahlqvist
2001-10-12 7:59 RH 7.1 gcc 2.96 bug (was Re: TAKE - work around gcc bug during xfs_growfs ) erich
2001-10-12 13:41 82% ` Steve Lord
2001-04-26 3:39 aa's rwsem-generic-6 bug? Process stuck in 'R' state Bob McElrath
2001-04-26 4:11 ` it isn't aa's rwsem-generic-6 bug but something else [Re: aa's rwsem-generic-6 bug? Process stuck in 'R' state.] Andrea Arcangeli
2001-04-26 5:38 ` Bob McElrath
2001-04-26 15:45 82% ` Andrea Arcangeli
2001-04-26 16:10 82% ` Bob McElrath
2002-10-14 20:27 [BUG] Compile failure (gcc 2.96 bug?). 2.5.42 raid0.c David Mansfield
2002-10-14 20:54 82% ` Arjan van de Ven
2002-10-14 21:11 82% ` Arjan van de Ven
2002-10-27 13:33 [BUG]Kernel Panic while booting 2.5.44 Andreas Tscharner
2002-10-27 14:10 ` Alan Cox
2002-10-27 17:04 ` Andreas Tscharner
2002-11-03 11:08 82% ` [BUG] Kernel panic while booting 2.5.45 (was: Re: [BUG]Kernel Panic while booting 2.5.44) Andreas Tscharner
2002-10-01 20:08 [Linux-ia64] glibc bug / pthread bug??? Jack Steiner
2002-10-01 21:28 82% ` Boehm, Hans
2003-03-07 5:32 [Bug 449] New: Kernel BUG when tun device is closed Martin J. Bligh
2003-03-07 16:35 82% ` Kevin P. Fleming
2009-11-11 16:02 Bug 14579 - Devices disappear... and Bug 14577 - Data corruption with Adaptec Lukas Kolbe
2009-11-12 22:58 ` Sascha Frey
2009-11-13 11:59 ` Desai, Kashyap
2009-11-17 14:22 ` Lukas Kolbe
2009-11-18 4:54 ` Desai, Kashyap
2009-11-18 13:39 ` Lukas Kolbe
2009-11-19 5:13 ` Desai, Kashyap
2009-11-19 10:17 90% ` Bug 14579 (was: RE: Bug 14579 - Devices disappear... and Bug 14577 - Data corruption with Adaptec) Lukas Kolbe
2009-11-19 10:30 90% ` Desai, Kashyap
2009-11-19 10:48 90% ` Lukas Kolbe
2009-11-19 10:58 90% ` Desai, Kashyap
2001-03-19 1:14 [BUG] kernel BUG at printk.c:458! -- 2.4.2-ac20 BERECZ Szabolcs
2001-03-18 9:19 82% ` Arnaldo Carvalho de Melo
2001-03-19 1:40 82% ` Andrew Morton
2003-02-16 2:58 [Bug 365] New: Raid-0 causes kernel BUG at drivers/block/ll_rw_blk.c:1996 Martin J. Bligh
2003-02-16 9:54 82% ` Jens Axboe
2010-05-09 21:13 2.6.34-rc6-git6: Reported regressions from 2.6.33 Rafael J. Wysocki
2010-05-09 21:17 90% ` [Bug #15935] [BUG] btrfs: report a direct-IO bug Rafael J. Wysocki
2010-05-09 21:17 90% ` Rafael J. Wysocki
2011-08-28 18:58 3.1-rc3-git6: Reported regressions 2.6.39 -> 3.0 Rafael J. Wysocki
2011-08-28 19:01 90% ` [Bug #41102] BUG dentry: Poison overwritten / BUG buffer_head: Poison overwritten Rafael J. Wysocki
2011-08-30 12:13 90% ` Paul Bolle
2011-08-30 12:13 90% ` Paul Bolle
2011-08-30 18:47 90% ` Rafael J. Wysocki
2011-08-30 18:47 90% ` Rafael J. Wysocki
2002-10-22 1:08 Yay, bug tracking! (was Re: Bug tracking in the run up from 2.5 to 2.6) Jeff Garzik
2002-10-22 1:40 82% ` Rik van Riel
2002-10-22 1:43 82% ` Martin J. Bligh
2002-10-22 9:49 82% ` Alan Cox
2002-10-22 9:37 82% ` Jeff Garzik
2002-10-24 18:34 82% ` Cliff White
2003-06-15 18:20 [Bug 810] New: Kernel BUG at mm/slab.c:981 Martin J. Bligh
2003-06-15 18:38 82% ` Michael Buesch
2003-03-31 0:31 [parisc-linux] perl/gcc bug if someone wants to look :) Randolph Chung
2003-03-31 2:32 82% ` [parisc-linux] glibc/gcc bug -> perl/gcc bug? Carlos O'Donell
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.