* Re: aic7xxx woes in 2.5
From: Justin T. Gibbs @ 2002-12-15 20:09 UTC (permalink / raw)
To: Andrew Morton, linux-scsi
In-Reply-To: <3DFC059A.9AA3F75F@digeo.com>
> For about six months in the 2.5 series, using aic7xxx, about every fourth
> boot one of my disks tends to get:
>
> (scsi1:A:4:0): parity-error detected in Data-in phase: SEQADDR(0x1ae)
> SCSIRATE(0x88) scsi1:0:4:0: Attempting to queue an ABORT message
>
> This is invariably fatal.
...
> This never happens in 2.4 kernels.
>
> It seems to happen a little more frequently on uniprocessor builds.
>
> So relevant questions would be:
>
> 1) Why does only 2.5 get the parity error?
Most likely different loads on your SCSI bus. The driver can't "make up"
SCSI bus parity errors.
> 2) Why does the recovery lock up?
I would actually have to know the sequencer instruction that we
are blocked on in the clear_critical_sections code to be able to
say. Several recovery bugs have been fixed in later driver versions.
> 3) Does anyone have a diff for Justin's new driver?
Just populate the scsi/aic7xxx directory with the files found
here:
http://people.FreeBSD.org/~gibbs/linux/SRC/
You will need to merge in the Kconfig and Makefile for the scsi
directory, but if you are running a fairly recent kernel, you
can just overwrite those files with those supplied in the linux-2.5
archive supplied at the above URL.
--
Justin
^ permalink raw reply
* Re: 2.4.20 st + aic7xxx (Adaptec 19160B) + VIA KT333 repeatable freeze
From: Justin T. Gibbs @ 2002-12-15 20:01 UTC (permalink / raw)
To: Keith Owens, Kevin Easton; +Cc: linux-kernel
In-Reply-To: <1047.1039952560@ocs3.intra.ocs.com.au>
> On Fri, 13 Dec 2002 11:51:27 +1100,
> Kevin Easton <kevin@sylandro.com> wrote:
>> I'm not sure exactly where this problem fits in, but I'm getting a
>> completely repeatable freeze (100% lockup, no response to keyboard)
>> triggered by writing to /dev/st0 (dd if=/dev/urandom of=/dev/st0 bs=512
>> count=163840 will reproduce it).
>> So... does anyone have any ideas how I should start trying to track this
>> down?
You might also look into your BIOS to ensure that the option "PCI Byte
Merging" is disabled. This option allows the chipset to perform illegal
byte merging on the PCI bus that will upset the Adaptec. Since the byte
merging will only occur in certain scenarios (heavily dependent on what
is going on with the SCSI bus), you may only see the lockup when accessing
a particular device or running a certain program.
The latest versions of the aic7xxx and aic79xx drivers will automatically
detect this broken VIA behavior and will fall back to using PIO for register
access. Although I haven't generated patches against 2.4.20, you can pull
down a src tarball for 2.4.X that should just drop in:
http://~people.FreeBSD.org/~gibbs/linux/SRC/
--
Justin
^ permalink raw reply
* Re: Modem Identification - Thanks
From: Frank Roberts - SOTL @ 2002-12-15 19:55 UTC (permalink / raw)
To: Linux Newbie
In-Reply-To: <5.1.0.14.1.20021214171540.020e0cb0@celine>
Hi All
I finally got the IBM A30P Think Pad I have been working on for the last month
on line.
Getting Linux on was a bitch you people may recall all my posts concerning the
various distributions over this.
The modem has proven to be equally chalanging mainly because of lack of
information on which is the best procedure to use.
The only major outstanding item required for this box is minicom or its
replacement. Hopefully the latter as I find minicom a trite stuffy but
usable.
Thanks again for all the great help.
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: Support for Arctic platform (405LP based)
From: Tom Rini @ 2002-12-15 19:51 UTC (permalink / raw)
To: Cort Dougan; +Cc: linuxppc-embedded
In-Reply-To: <20021215121526.M30941@duath.fsmlabs.com>
On Sun, Dec 15, 2002 at 12:15:26PM -0700, Cort Dougan wrote:
> How about killing the _2_4_devel tree? When I created it I want it to be a
> playground for stabilizing then moving things over to 2_4 failry quickly.
> It seems to have become the defacto "want board X, you better use
> _2_4_devel" tree.
That's been the stated goal for quite a number of months now. The
reason it hasn't 'died' yet is that some changes have taken a while to
get to the point where Paul is happy enough with them to send out to
Marcelo, and / or Marcelo has gotten far along in the -pre releases of
the next release that big arch specific changes aren't a good idea.
Hopefully starting the week of 12/23 I'll have time to get the 'classic'
PPC (and here it's really i8259 / OpenPIC stuff, the CPC700/CPC710
boards can / have gone out) to the _2_4 tree and onto Marcelo.
> When I went looking for a working 4xx tree recently I had to write a script
> that would go through the last year of changesets in _2_4 and _2_4_devel
> and try to build them then stick the result into a file. That ran for 7
> days on a 2.0Ghz Dual x86. Then, that only gave me a list of building
> trees. Knowing that there's only 1 tree would be much easier!
4xx in and of itself has things which still need to be done. The stock
answer for some time for a 'working' 4xx tree is to use _devel. I think
that it might be possible to get the basics of 4xx out to Marcelo, if
some of the cleanups done in 2.5 get (a) finished and then (b)
backported to 2.4. But that would still I suspect leave enet and other
things out at the moment.
> I'll send you some wonderful New Mexico wine in exchange for your efforts!
Woo! :)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: problem with Andrew's patch ext3
From: Octave @ 2002-12-15 19:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, ext3-users
In-Reply-To: <3DFCCB1D.53D841B@digeo.com>
> The patch is at
> http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.20/sync_fs.patch
> could you ensure that it was applied successfully?
it works with this patch. I think it is on my side (since I did not
find out the patch, I patched "handly" from lwn.net).
sorry for this noise
regards
Octave
^ permalink raw reply
* dosemu 1.1.3.9 for testing
From: Bart Oldeman @ 2002-12-15 19:45 UTC (permalink / raw)
To: linux-msdos
Hi,
it's at http://www.dosemu.org/testing. This should be the last testing
version before 1.1.4, the new development version.
Important things that changed from the user's perspective:
* 'make install' works again. It installs dosemu to locations
specified in compiletime-settings; a FreeDOS tarball is optional
(see compiletime-settings.help)
* setup-dosemu is broken (sorry, it needs adjustments to deal with the
paths and I'm not able to fix it quickly). For now, just edit
compiletime-settings* directly.
* for per-user installations:
use ~/.dosemurc instead of ~/dosemu/conf/dosemu.conf and
~/dosemu/conf/dosemurc.
boot.log is now in ~/.dosemu instead of ~/dosemu
* you can specify absolute paths for $_hdimage in dosemu.conf and
~/.dosemurc
* the default configuration files have everything commented out;
DOSEMU uses default values if the options are not set (corresponding
to the commented-out values).
Please let me know if anything is broken in the new 'make install'.
Bart
^ permalink raw reply
* Re: [Dri-devel] PROBLEM: 2.4.{19,20} fails to resume if radeon.o is loaded
From: Charl P. Botha @ 2002-12-15 19:37 UTC (permalink / raw)
To: gthomsen; +Cc: dri-devel, linux-kernel
In-Reply-To: <E18NO8U-0005j1-00@doma.ballum>
On Sat, Dec 14, 2002 at 06:04:06PM -0800, tho@doma.ballum.wikaba.com wrote:
> after about a dozen reboots and half a dozen fscks, I finally was
> able to pinpoint the reason of why my laptop (ThinkPad X22 (2662XXK))
> wasn't able to resume after suspend.
>
> The DRM module 'radeon.o' somehow prevents a successful resume (but
> not the suspend). Only after I made that module unavailable to the
> modutils, my laptop now successfully completes suspend/resume cycles.
http://www.google.com/search?q=dri+radeon+resume
Yields:
http://cpbotha.net/dri_resume.html
This is applicable only if you're interested in suspending/resuming with
active DRI, which it doesn't seem you are. So it's just FYI :)
--
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
^ permalink raw reply
* Patch - bug in adding/removing modules
From: Matthew Tippett @ 2002-12-15 19:23 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]
Although I was only looking at the battery module, I believe I have
fixed a potential oops regarding inserting and removing modules.
The attached patch fixes a problem that I have seen, a quick look at
other modules seems to have the same problem.
The description of the problem is ...
There is a macro called acpi_device_dir which returns a pointer to the a
battery instance directory in /proc/acpi/battery. When removing a
module, the device is removed from the proc heirachy, but the entry in
the device table is never set to null. So consequently when the device
is reinserted the add_fs call already sees the proc directory entry and
consequently uses the /proc/acpi/battery and along the way corrupts some
memory.
So the patch NULLs out the proc dir entry in the device structure in a
manner symmetric with the creation and deletion of the proc directory.
Regards,
Matthew
--
Matthew Tippett - matthew.tippett-rieW9WUcm8FFJ04o6PK0Fg@public.gmane.org - (416) 435-4118
Technology Forum - http://www.technology-forum.org/
Commercial Open Source - http://www.commercialos.org/
[-- Attachment #2: battery.diff --]
[-- Type: text/plain, Size: 373 bytes --]
--- battery.c.orig 2002-12-15 14:14:51.000000000 -0500
+++ battery.c 2002-12-15 14:11:29.000000000 -0500
@@ -658,8 +658,10 @@
{
ACPI_FUNCTION_TRACE("acpi_battery_remove_fs");
- if (acpi_device_dir(device))
+ if (acpi_device_dir(device)) {
remove_proc_entry(acpi_device_bid(device), acpi_battery_dir);
+ acpi_device_dir(device) = NULL;
+ }
return_VALUE(0);
}
^ permalink raw reply
* Re: Support for Arctic platform (405LP based)
From: Cort Dougan @ 2002-12-15 19:15 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20021213151808.GI19456@opus.bloom.county>
How about killing the _2_4_devel tree? When I created it I want it to be a
playground for stabilizing then moving things over to 2_4 failry quickly.
It seems to have become the defacto "want board X, you better use
_2_4_devel" tree.
When I went looking for a working 4xx tree recently I had to write a script
that would go through the last year of changesets in _2_4 and _2_4_devel
and try to build them then stick the result into a file. That ran for 7
days on a 2.0Ghz Dual x86. Then, that only gave me a list of building
trees. Knowing that there's only 1 tree would be much easier!
I'll send you some wonderful New Mexico wine in exchange for your efforts!
} One of my goals for winter break is to try and make the _devel tree less
} divergent, at least w.r.t. 'classic' PPCs. I'm not sure if 4xx support
} is in a stage yet that Paul is happy to move it to the _2_4 tree and
} then on to Marcelo yet.
}
} --
} Tom Rini (TR1265)
} http://gate.crashing.org/~trini/
}
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Kernel for Pentium 4 hyperthreading?
From: Dave Jones @ 2002-12-15 19:17 UTC (permalink / raw)
To: Scott Robert Ladd; +Cc: linux-kernel
In-Reply-To: <FKEAJLBKJCGBDJJIPJLJGEIHDLAA.scott@coyotegulch.com>
On Sun, Dec 15, 2002 at 12:40:59PM -0500, Scott Robert Ladd wrote:
> Dave Jones wrote:
> > Ah, apologies. Yes. In this case, you win. I bit the same problem you
> > had btw with this box in 2.4. You need an updated BIOS. Contact Intel.
>
> I'll ask Intel if there's a BIOS update. Computers are almost as bad as
> games now; the first thing you need to do before using them is patch!
>
> What evokes my curiosity is that the 2.5.51 kernel detects and correctly
> uses the processor siblings, while 2.4.20 does not. Given that 2.5.51 is
> running quite well, I think I'll just stay on the bleeding edge of Linux for
> a while.
I think the problem was a missing MP table in the factory-shipped BIOS.
2.5 used ACPI to enumerate the siblings, whereas the 2.4 ACPI is a
little out of date in that department.
At least that was my random guess when I hit that problem.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
^ permalink raw reply
* Re: 2.5.51 on Alpha oopses on mount
From: Richard Henderson @ 2002-12-15 18:57 UTC (permalink / raw)
To: Matt Reppert; +Cc: linux-kernel
In-Reply-To: <20021214123155.7383524c.arashi@arashi.yi.org>
On Sat, Dec 14, 2002 at 12:31:55PM -0600, Matt Reppert wrote:
> >>PC; fffffc00004a5240 <__copy_user+100/1d4> <=====
> Trace; fffffc0000385920 <sys_mount+40/160>
This fault is expected and is _supposed_ to be handled by the
exception mechanism. Why this stopped working, I don't know.
For grins, see if the following helps. It's something that I
need for the shared-library modules anyway, and it eliminates
an extra variable from the problem.
r~
===== arch/alpha/kernel/traps.c 1.20 vs edited =====
--- 1.20/arch/alpha/kernel/traps.c Fri Nov 8 05:48:56 2002
+++ edited/arch/alpha/kernel/traps.c Sat Dec 14 11:24:11 2002
@@ -638,7 +638,7 @@
got_exception:
/* Ok, we caught the exception, but we don't want it. Is there
someone to pass it along to? */
- if ((fixup = search_exception_table(pc, regs.gp)) != 0) {
+ if ((fixup = search_exception_table(pc)) != 0) {
unsigned long newpc;
newpc = fixup_exception(una_reg, fixup, pc);
===== arch/alpha/lib/clear_user.S 1.1 vs edited =====
--- 1.1/arch/alpha/lib/clear_user.S Tue Feb 5 09:40:21 2002
+++ edited/arch/alpha/lib/clear_user.S Sat Dec 14 11:12:14 2002
@@ -29,7 +29,7 @@
#define EX(x,y...) \
99: x,##y; \
.section __ex_table,"a"; \
- .gprel32 99b; \
+ .long 99b - .; \
lda $31, $exception-99b($31); \
.previous
@@ -80,7 +80,6 @@
ret $31, ($28), 1 # .. e1 :
__do_clear_user:
- ldgp $29,0($27) # we do exceptions -- we need the gp.
and $6, 7, $4 # e0 : find dest misalignment
beq $0, $zerolength # .. e1 :
addq $0, $4, $1 # e0 : bias counter
===== arch/alpha/lib/copy_user.S 1.1 vs edited =====
--- 1.1/arch/alpha/lib/copy_user.S Tue Feb 5 09:40:21 2002
+++ edited/arch/alpha/lib/copy_user.S Sat Dec 14 11:13:48 2002
@@ -30,29 +30,28 @@
#define EXI(x,y...) \
99: x,##y; \
.section __ex_table,"a"; \
- .gprel32 99b; \
+ .long 99b - .; \
lda $31, $exitin-99b($31); \
.previous
#define EXO(x,y...) \
99: x,##y; \
.section __ex_table,"a"; \
- .gprel32 99b; \
+ .long 99b - .; \
lda $31, $exitout-99b($31); \
.previous
.set noat
- .align 3
+ .align 4
.globl __copy_user
.ent __copy_user
__copy_user:
- ldgp $29,0($27) # we do exceptions -- we need the gp.
- .prologue 1
+ .prologue 0
and $6,7,$3
beq $0,$35
beq $3,$36
subq $3,8,$3
- .align 5
+ .align 4
$37:
EXI( ldq_u $1,0($7) )
EXO( ldq_u $2,0($6) )
@@ -73,7 +72,7 @@
beq $1,$43
beq $4,$48
EXI( ldq_u $3,0($7) )
- .align 5
+ .align 4
$50:
EXI( ldq_u $2,8($7) )
subq $4,8,$4
@@ -88,7 +87,7 @@
bne $4,$50
$48:
beq $0,$41
- .align 5
+ .align 4
$57:
EXI( ldq_u $1,0($7) )
EXO( ldq_u $2,0($6) )
@@ -105,7 +104,7 @@
.align 4
$43:
beq $4,$65
- .align 5
+ .align 4
$66:
EXI( ldq $1,0($7) )
subq $4,8,$4
===== arch/alpha/lib/ev6-clear_user.S 1.1 vs edited =====
--- 1.1/arch/alpha/lib/ev6-clear_user.S Tue Feb 5 09:40:22 2002
+++ edited/arch/alpha/lib/ev6-clear_user.S Sat Dec 14 11:14:24 2002
@@ -47,7 +47,7 @@
#define EX(x,y...) \
99: x,##y; \
.section __ex_table,"a"; \
- .gprel32 99b; \
+ .long 99b - .; \
lda $31, $exception-99b($31); \
.previous
@@ -62,9 +62,6 @@
# Pipeline info : Slotting & Comments
__do_clear_user:
- ldgp $29,0($27) # we do exceptions -- we need the gp.
- # Macro instruction becomes ldah/lda
- # .. .. E E :
and $6, 7, $4 # .. E .. .. : find dest head misalignment
beq $0, $zerolength # U .. .. .. : U L U L
===== arch/alpha/lib/ev6-copy_user.S 1.1 vs edited =====
--- 1.1/arch/alpha/lib/ev6-copy_user.S Tue Feb 5 09:40:22 2002
+++ edited/arch/alpha/lib/ev6-copy_user.S Sat Dec 14 11:14:59 2002
@@ -41,14 +41,14 @@
#define EXI(x,y...) \
99: x,##y; \
.section __ex_table,"a"; \
- .gprel32 99b; \
+ .long 99b - .; \
lda $31, $exitin-99b($31); \
.previous
#define EXO(x,y...) \
99: x,##y; \
.section __ex_table,"a"; \
- .gprel32 99b; \
+ .long 99b - .; \
lda $31, $exitout-99b($31); \
.previous
@@ -58,10 +58,7 @@
.ent __copy_user
# Pipeline info: Slotting & Comments
__copy_user:
- ldgp $29,0($27) # we do exceptions -- we need the gp.
- # Macro instruction becomes ldah/lda
- # .. .. E E
- .prologue 1
+ .prologue 0
subq $0, 32, $1 # .. E .. .. : Is this going to be a small copy?
beq $0, $zerolength # U .. .. .. : U L U L
===== arch/alpha/lib/ev6-strncpy_from_user.S 1.2 vs edited =====
--- 1.2/arch/alpha/lib/ev6-strncpy_from_user.S Thu Aug 8 12:28:01 2002
+++ edited/arch/alpha/lib/ev6-strncpy_from_user.S Sat Dec 14 11:16:49 2002
@@ -34,7 +34,7 @@
#define EX(x,y...) \
99: x,##y; \
.section __ex_table,"a"; \
- .gprel32 99b; \
+ .long 99b - .; \
lda $31, $exception-99b($0); \
.previous
@@ -46,11 +46,10 @@
.globl __strncpy_from_user
.ent __strncpy_from_user
.frame $30, 0, $26
- .prologue 1
+ .prologue 0
.align 4
__strncpy_from_user:
- ldgp $29, 0($27) # E E : becomes 2 instructions (for exceptions)
and a0, 7, t3 # E : find dest misalignment
beq a2, $zerolength # U :
===== arch/alpha/lib/ev67-strlen_user.S 1.2 vs edited =====
--- 1.2/arch/alpha/lib/ev67-strlen_user.S Thu Aug 8 12:28:01 2002
+++ edited/arch/alpha/lib/ev67-strlen_user.S Sat Dec 14 11:15:49 2002
@@ -30,7 +30,7 @@
#define EX(x,y...) \
99: x,##y; \
.section __ex_table,"a"; \
- .gprel32 99b; \
+ .long 99b - .; \
lda v0, $exception-99b(zero); \
.previous
@@ -56,9 +56,7 @@
.align 4
__strnlen_user:
- ldgp $29,0($27) # E E : we do exceptions -- we need the gp.
- /* Decomposes into lda/ldah */
- .prologue 1
+ .prologue 0
EX( ldq_u t0, 0(a0) ) # L : load first quadword (a0 may be misaligned)
lda t1, -1(zero) # E :
===== arch/alpha/lib/strlen_user.S 1.2 vs edited =====
--- 1.2/arch/alpha/lib/strlen_user.S Thu Aug 8 12:28:01 2002
+++ edited/arch/alpha/lib/strlen_user.S Sat Dec 14 11:16:04 2002
@@ -19,7 +19,7 @@
#define EX(x,y...) \
99: x,##y; \
.section __ex_table,"a"; \
- .gprel32 99b; \
+ .long 99b - .; \
lda v0, $exception-99b(zero); \
.previous
@@ -42,8 +42,7 @@
.align 3
__strnlen_user:
- ldgp $29,0($27) # we do exceptions -- we need the gp.
- .prologue 1
+ .prologue 0
EX( ldq_u t0, 0(a0) ) # load first quadword (a0 may be misaligned)
lda t1, -1(zero)
===== arch/alpha/lib/strncpy_from_user.S 1.2 vs edited =====
--- 1.2/arch/alpha/lib/strncpy_from_user.S Thu Aug 8 12:28:01 2002
+++ edited/arch/alpha/lib/strncpy_from_user.S Sat Dec 14 11:17:01 2002
@@ -19,7 +19,7 @@
#define EX(x,y...) \
99: x,##y; \
.section __ex_table,"a"; \
- .gprel32 99b; \
+ .long 99b - .; \
lda $31, $exception-99b($0); \
.previous
@@ -31,7 +31,7 @@
.globl __strncpy_from_user
.ent __strncpy_from_user
.frame $30, 0, $26
- .prologue 1
+ .prologue 0
.align 3
$aligned:
@@ -100,8 +100,6 @@
/*** The Function Entry Point ***/
.align 3
__strncpy_from_user:
- ldgp $29, 0($27) # we do exceptions -- we need the gp.
-
mov a0, v0 # save the string start
beq a2, $zerolength
===== arch/alpha/mm/extable.c 1.2 vs edited =====
--- 1.2/arch/alpha/mm/extable.c Mon Feb 4 23:40:23 2002
+++ edited/arch/alpha/mm/extable.c Sat Dec 14 11:23:06 2002
@@ -12,21 +12,17 @@
static inline unsigned
search_one_table(const struct exception_table_entry *first,
const struct exception_table_entry *last,
- signed long value)
+ unsigned long value)
{
- /* Abort early if the search value is out of range. */
- if (value != (signed int)value)
- return 0;
-
while (first <= last) {
const struct exception_table_entry *mid;
- long diff;
+ unsigned long mid_value;
mid = (last - first) / 2 + first;
- diff = mid->insn - value;
- if (diff == 0)
+ mid_value = (unsigned long)&mid->insn + mid->insn;
+ if (mid_value == value)
return mid->fixup.unit;
- else if (diff < 0)
+ else if (mid_value < value)
first = mid+1;
else
last = mid-1;
@@ -34,48 +30,13 @@
return 0;
}
-register unsigned long gp __asm__("$29");
-
-static unsigned
-search_exception_table_without_gp(unsigned long addr)
-{
- unsigned ret;
-
-#ifndef CONFIG_MODULES
- /* There is only the kernel to search. */
- ret = search_one_table(__start___ex_table, __stop___ex_table - 1,
- addr - gp);
-#else
- extern spinlock_t modlist_lock;
- unsigned long flags;
- /* The kernel is the last "module" -- no need to treat it special. */
- struct module *mp;
-
- ret = 0;
- spin_lock_irqsave(&modlist_lock, flags);
- for (mp = module_list; mp ; mp = mp->next) {
- if (!mp->ex_table_start || !(mp->flags&(MOD_RUNNING|MOD_INITIALIZING)))
- continue;
- ret = search_one_table(mp->ex_table_start,
- mp->ex_table_end - 1, addr - mp->gp);
- if (ret)
- break;
- }
- spin_unlock_irqrestore(&modlist_lock, flags);
-#endif
-
- return ret;
-}
-
unsigned
-search_exception_table(unsigned long addr, unsigned long exc_gp)
+search_exception_table(unsigned long addr)
{
unsigned ret;
#ifndef CONFIG_MODULES
- ret = search_one_table(__start___ex_table, __stop___ex_table - 1,
- addr - exc_gp);
- if (ret) return ret;
+ ret = search_one_table(__start___ex_table, __stop___ex_table-1, addr);
#else
extern spinlock_t modlist_lock;
unsigned long flags;
@@ -88,25 +49,12 @@
if (!mp->ex_table_start || !(mp->flags&(MOD_RUNNING|MOD_INITIALIZING)))
continue;
ret = search_one_table(mp->ex_table_start,
- mp->ex_table_end - 1, addr - exc_gp);
+ mp->ex_table_end - 1, addr);
if (ret)
break;
}
spin_unlock_irqrestore(&modlist_lock, flags);
- if (ret) return ret;
#endif
- /*
- * The search failed with the exception gp. To be safe, try the
- * old method before giving up.
- */
- ret = search_exception_table_without_gp(addr);
- if (ret) {
- printk(KERN_ALERT "%s: [%lx] EX_TABLE search fail with"
- "exc frame GP, success with raw GP\n",
- current->comm, addr);
- return ret;
- }
-
- return 0;
+ return ret;
}
===== arch/alpha/mm/fault.c 1.8 vs edited =====
--- 1.8/arch/alpha/mm/fault.c Wed Oct 30 10:42:09 2002
+++ edited/arch/alpha/mm/fault.c Sat Dec 14 11:23:31 2002
@@ -176,7 +176,7 @@
no_context:
/* Are we prepared to handle this fault as an exception? */
- if ((fixup = search_exception_table(regs->pc, regs->gp)) != 0) {
+ if ((fixup = search_exception_table(regs->pc)) != 0) {
unsigned long newpc;
newpc = fixup_exception(dpf_reg, fixup, regs->pc);
regs->pc = newpc;
===== include/asm-alpha/uaccess.h 1.2 vs edited =====
--- 1.2/include/asm-alpha/uaccess.h Mon Feb 11 05:42:53 2002
+++ edited/include/asm-alpha/uaccess.h Sat Dec 14 11:18:49 2002
@@ -126,7 +126,7 @@
__asm__("1: ldq %0,%2\n" \
"2:\n" \
".section __ex_table,\"a\"\n" \
- " .gprel32 1b\n" \
+ " .long 1b - .\n" \
" lda %0, 2b-1b(%1)\n" \
".previous" \
: "=r"(__gu_val), "=r"(__gu_err) \
@@ -136,7 +136,7 @@
__asm__("1: ldl %0,%2\n" \
"2:\n" \
".section __ex_table,\"a\"\n" \
- " .gprel32 1b\n" \
+ " .long 1b - .\n" \
" lda %0, 2b-1b(%1)\n" \
".previous" \
: "=r"(__gu_val), "=r"(__gu_err) \
@@ -149,7 +149,7 @@
__asm__("1: ldwu %0,%2\n" \
"2:\n" \
".section __ex_table,\"a\"\n" \
- " .gprel32 1b\n" \
+ " .long 1b - .\n" \
" lda %0, 2b-1b(%1)\n" \
".previous" \
: "=r"(__gu_val), "=r"(__gu_err) \
@@ -159,7 +159,7 @@
__asm__("1: ldbu %0,%2\n" \
"2:\n" \
".section __ex_table,\"a\"\n" \
- " .gprel32 1b\n" \
+ " .long 1b - .\n" \
" lda %0, 2b-1b(%1)\n" \
".previous" \
: "=r"(__gu_val), "=r"(__gu_err) \
@@ -178,10 +178,10 @@
" or %0,%1,%0\n" \
"3:\n" \
".section __ex_table,\"a\"\n" \
- " .gprel32 1b\n" \
+ " .long 1b - .\n" \
" lda %0, 3b-1b(%2)\n" \
- " .gprel32 2b\n" \
- " lda %0, 2b-1b(%2)\n" \
+ " .long 2b - .\n" \
+ " lda %0, 3b-2b(%2)\n" \
".previous" \
: "=&r"(__gu_val), "=&r"(__gu_tmp), "=r"(__gu_err) \
: "r"(addr), "2"(__gu_err)); \
@@ -192,7 +192,7 @@
" extbl %0,%2,%0\n" \
"2:\n" \
".section __ex_table,\"a\"\n" \
- " .gprel32 1b\n" \
+ " .long 1b - .\n" \
" lda %0, 2b-1b(%1)\n" \
".previous" \
: "=&r"(__gu_val), "=r"(__gu_err) \
@@ -240,7 +240,7 @@
__asm__ __volatile__("1: stq %r2,%1\n" \
"2:\n" \
".section __ex_table,\"a\"\n" \
- " .gprel32 1b\n" \
+ " .long 1b - .\n" \
" lda $31,2b-1b(%0)\n" \
".previous" \
: "=r"(__pu_err) \
@@ -250,7 +250,7 @@
__asm__ __volatile__("1: stl %r2,%1\n" \
"2:\n" \
".section __ex_table,\"a\"\n" \
- " .gprel32 1b\n" \
+ " .long 1b - .\n" \
" lda $31,2b-1b(%0)\n" \
".previous" \
: "=r"(__pu_err) \
@@ -263,7 +263,7 @@
__asm__ __volatile__("1: stw %r2,%1\n" \
"2:\n" \
".section __ex_table,\"a\"\n" \
- " .gprel32 1b\n" \
+ " .long 1b - .\n" \
" lda $31,2b-1b(%0)\n" \
".previous" \
: "=r"(__pu_err) \
@@ -273,7 +273,7 @@
__asm__ __volatile__("1: stb %r2,%1\n" \
"2:\n" \
".section __ex_table,\"a\"\n" \
- " .gprel32 1b\n" \
+ " .long 1b - .\n" \
" lda $31,2b-1b(%0)\n" \
".previous" \
: "=r"(__pu_err) \
@@ -298,13 +298,13 @@
"4: stq_u %1,0(%5)\n" \
"5:\n" \
".section __ex_table,\"a\"\n" \
- " .gprel32 1b\n" \
+ " .long 1b - .\n" \
" lda $31, 5b-1b(%0)\n" \
- " .gprel32 2b\n" \
+ " .long 2b - .\n" \
" lda $31, 5b-2b(%0)\n" \
- " .gprel32 3b\n" \
+ " .long 3b - .\n" \
" lda $31, 5b-3b(%0)\n" \
- " .gprel32 4b\n" \
+ " .long 4b - .\n" \
" lda $31, 5b-4b(%0)\n" \
".previous" \
: "=r"(__pu_err), "=&r"(__pu_tmp1), \
@@ -324,9 +324,9 @@
"2: stq_u %1,0(%4)\n" \
"3:\n" \
".section __ex_table,\"a\"\n" \
- " .gprel32 1b\n" \
+ " .long 1b - .\n" \
" lda $31, 3b-1b(%0)\n" \
- " .gprel32 2b\n" \
+ " .long 2b - .\n" \
" lda $31, 3b-2b(%0)\n" \
".previous" \
: "=r"(__pu_err), \
@@ -356,7 +356,7 @@
register long __cu_len __asm__("$0") = len;
__asm__ __volatile__(
- "jsr $28,(%3),__copy_user\n\tldgp $29,0($28)"
+ "jsr $28,(%3),__copy_user"
: "=r" (__cu_len), "=r" (__cu_from), "=r" (__cu_to), "=r"(pv)
: "0" (__cu_len), "1" (__cu_from), "2" (__cu_to), "3"(pv)
: "$1","$2","$3","$4","$5","$28","memory");
@@ -373,7 +373,7 @@
register const void * __cu_from __asm__("$7") = from;
register long __cu_len __asm__("$0") = len;
__asm__ __volatile__(
- "jsr $28,(%3),__copy_user\n\tldgp $29,0($28)"
+ "jsr $28,(%3),__copy_user"
: "=r"(__cu_len), "=r"(__cu_from), "=r"(__cu_to),
"=r" (pv)
: "0" (__cu_len), "1" (__cu_from), "2" (__cu_to),
@@ -413,7 +413,7 @@
register void * __cl_to __asm__("$6") = to;
register long __cl_len __asm__("$0") = len;
__asm__ __volatile__(
- "jsr $28,(%2),__do_clear_user\n\tldgp $29,0($28)"
+ "jsr $28,(%2),__do_clear_user"
: "=r"(__cl_len), "=r"(__cl_to), "=r"(pv)
: "0"(__cl_len), "1"(__cl_to), "2"(pv)
: "$1","$2","$3","$4","$5","$28","memory");
@@ -428,7 +428,7 @@
register void * __cl_to __asm__("$6") = to;
register long __cl_len __asm__("$0") = len;
__asm__ __volatile__(
- "jsr $28,(%2),__do_clear_user\n\tldgp $29,0($28)"
+ "jsr $28,(%2),__do_clear_user"
: "=r"(__cl_len), "=r"(__cl_to), "=r"(pv)
: "0"(__cl_len), "1"(__cl_to), "2"(pv)
: "$1","$2","$3","$4","$5","$28","memory");
@@ -471,7 +471,7 @@
/*
* About the exception table:
*
- * - insn is a 32-bit offset off of the kernel's or module's gp.
+ * - insn is a 32-bit pc-relative offset from the faulting insn.
* - nextinsn is a 16-bit offset off of the faulting instruction
* (not off of the *next* instruction as branches are).
* - errreg is the register in which to place -EFAULT.
@@ -502,7 +502,7 @@
};
/* Returns 0 if exception not found and fixup.unit otherwise. */
-extern unsigned search_exception_table(unsigned long, unsigned long);
+extern unsigned search_exception_table(unsigned long);
/* Returns the new pc */
#define fixup_exception(map_reg, fixup_unit, pc) \
^ permalink raw reply
* [2.5.5(01)]oops when catting info from /proc/bus/pnp/escd
From: Ruslan U. Zakirov @ 2002-12-15 18:53 UTC (permalink / raw)
To: kernelnewbies; +Cc: linux-kernel
=> cat /proc/bus/pnp/escd
Then this oops.
Unable to handle kernel paging request at virtual address ffffa00a
=> Could someone explain me in a few words what does it mean "unable
=> to handle..." or point me on docs?
Dec 16 22:35:06 cubloid-pc kernel: printing eip:
Dec 16 22:35:06 cubloid-pc kernel: 00007768
Dec 16 22:35:06 cubloid-pc kernel: *pde = 00001063
Dec 16 22:35:06 cubloid-pc kernel: *pte = 00000000
Dec 16 22:35:06 cubloid-pc kernel: Oops: 0000
Dec 16 22:35:06 cubloid-pc kernel: CPU: 0
Dec 16 22:35:06 cubloid-pc kernel: EIP: 0088:[<00007768>] Not tainted
Dec 16 22:35:06 cubloid-pc kernel: EFLAGS: 00010086
Dec 16 22:35:06 cubloid-pc kernel: EIP is at 0x7768
Dec 16 22:35:06 cubloid-pc kernel: eax: 000022ff ebx: 00a06816 ecx: 00000090 edx: 00000000
Dec 16 22:35:06 cubloid-pc kernel: esi: 0000000a edi: 00000000 ebp: c202790f esp: c2027e80
Dec 16 22:35:06 cubloid-pc kernel: ds: 00a0 es: 0098 ss: 0068
Dec 16 22:35:06 cubloid-pc kernel: Process cat (pid: 130, threadinfo=c2026000 task=c25a06e0)
Dec 16 22:35:06 cubloid-pc kernel: Stack: 000a0006 00a00000 00060098 7919774a 00000000 658a0090 682f7eb4 00680000
Dec 16 22:35:06 cubloid-pc kernel: 00000068 66840042 00960098 c2027efc 0080000b 00000042 00a00098 00000090
Dec 16 22:35:06 cubloid-pc kernel: 00000000 c01d6f2c 00000060 00000082 00000000 00000000 00000068 00000068
Dec 16 22:35:06 cubloid-pc kernel: Call Trace:
Dec 16 22:35:06 cubloid-pc kernel: [<c01d6f2c>] __pnp_bios_read_escd+0xe0/0x128
=> In this func "__pnp_bios_read_escd" error occured? I think so, am I
=> right?
Dec 16 22:35:06 cubloid-pc kernel: [<c01d6f85>] pnp_bios_read_escd+0x11/0x34
Dec 16 22:35:06 cubloid-pc kernel: [<c01d8002>] proc_read_escd+0x66/0xfc
Dec 16 22:35:06 cubloid-pc kernel: [<c015c577>] proc_file_read+0xb7/0x178
Dec 16 22:35:06 cubloid-pc kernel: [<c0139033>] vfs_read+0xa7/0x108
Dec 16 22:35:06 cubloid-pc kernel: [<c013927e>] sys_read+0x2a/0x40
Dec 16 22:35:06 cubloid-pc kernel: [<c0108a67>] syscall_call+0x7/0xb
Dec 16 22:35:06 cubloid-pc kernel:
Dec 16 22:35:06 cubloid-pc kernel: Code: Bad EIP value.
=> cat /proc/bus/pnp/escd_info
min_ESCD_write_size 8192
ESCD_size 3776
NVRAM_base 0xffffa000
=> We get this adress from call to another BIOS function, but may be
=> we have to allocate page or something else I don't know exactly
=> what. But I want to know more about it. And any suggextions or
=> explanations will be very good.
Beforehead Thanks to All.
Ruslan.
^ permalink raw reply
* [PROBLEM][2.5][AMD76X_PM]: Possible porting problem - Can't register AMD Northbridge?
From: Shawn Starr @ 2002-12-15 18:50 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel
Below is some debugging added as well as having the kernel partly -DDEBUG
enabled:
===============================================
amd76x_pm: amd76x_pm hardware power management 0.1.0
amd76x_pm: Looking for Northbridge...
bus pci: add driver amd76x_pm-nb
kobject amd76x_pm-nb: registering. parent: <NULL>, subsys: drivers
Inside driver_attach()
!bus->match not true continue on..
!dev->driver keep going...
inside bus_match()
inside pci_bus_match()
pci_bus_match(): About to search ids list...
pci_match_bus(): ids->vendor = 1022
pci_match_bus(): ids->subvendor = ffffffff
pci_match_bus(): ids->class_mask = 0
pci_match_bus(): ids->device = 700c
pci_match_bus(): ids->class = 0
pci_match_bus(): DECISION: ids->vendor 1022 == pci_dev->vendor 1022?
pci_match_bus(): DECISION ids->device 700c == pci_dev->device 700d?
pci_match_bus(): DECISION ids->subvendor ffffffff == pci_dev->subsystem_vendor
0?
pci_match_bus(): DECISION ids->subdevice ffffffff == pci_dev->subsystem_device
0?
bus_match(): match(): We didn't find a match. Failed
bus_match(): Returns -19 [-ENODEV]
Dec 14 23:20:37 unknown kernel: Driver_attach(): Returns 0
(This repeats a few times in the list then terminates with driver_attach
returning 0).
However when detecting the Southbridge:
amd76x_pm: Looking for Southbridge...
bus pci: add driver amd76x_pm-sb
kobject amd76x_pm-sb: registering. parent: <NULL>, subsys: drivers
Inside driver_attach()
!bus->patch not true continue on..
!dev->driver keep going...
inside bus_match()
inside pci_bus_match()
[First one doesnt match]
[Second one doesn't match]
[Third one doesn't match]
[Forth one doesn't match]
[Firth one doesn't match]
On the 6th list check:
pci_match_bus(): ids->vendor = 1022
pci_match_bus(): ids->subvendor = ffffffff
pci_match_bus(): ids->class_mask = 0
pci_match_bus(): ids->device = 7443
pci_match_bus(): ids->class = 0
pci_match_bus(): DECISION: ids->vendor 1022 == pci_dev->vendor 1022?
pci_match_bus(): DECISION ids->device 7443 == pci_dev->device 7443?
pci_match_bus(): DECISION ids->subvendor ffffffff == pci_dev->subsystem_vendor
1043?
pci_match_bus(): DECISION ids->subdevice ffffffff == pci_dev->subsystem_device
8044?
bus_match(): We matched!
amd76x_pm: Initializing southbridge Advanced Micro Devic AMD-768 [Opus] ACPI
bus_match(): Success! Attach it!
bound device '00:07.3' to driver 'amd76x_pm-sb'
sysfs_create_link: depth = 4, size = 33
sysfs_create_link: path ='../../../../devices/pci0/00:07.3'
bus_match(): Returns 0
driver_attach():bus_match() returns 1
[ It keeps searching the list after this for other new things]
We OOPs when we try to use pdev_nb->device in a switch because pdev = NULL!
because the Northbridge was not found.
Unable to handle kernel NULL pointer dereference at virtual address 00000026
printing eip:
e08a5568
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0060:[<e08a5568>] Not tainted
EFLAGS: 00010282
EIP is at 0xe08a5568
eax: 00000000 ebx: 00000000 ecx: c034d6d4 edx: 00000282
esi: e08a3000 edi: 00000000 ebp: de365fa0 esp: de365f94
ds: 0068 es: 0068 ss: 0068
Process insmod (pid: 127, threadinfo=de364000 task=de363940)
Stack: e08a5b00 00007443 c034fb98 de365fbc c012e6d1 40017000 00001dd3 0804a028
de364000 00000003 bffffd48 c01093db 40017000 00001dd3 0804a028
00000003
00000000 bffffd48 00000080 0000002b 0000002b 00000080 400fb36d
00000023
Call Trace:
[sys_init_module+433/464] sys_init_module+0x1b1/0x1d0
[syscall_call+7/11] syscall_call+0x7/0xb
Code: 0f b7 40 26 c7 04 24 60 5b 8a e0 89 44 24 04 e8 74 85 87 df
This of course, hangs insmod :(
Any pointers, Do we need to register the Northbridge and Southbridge and if
so, why can't we find it?
00:00.0 Class 0600: 1022:700c (rev 11) <---------- Northbridge
00:01.0 Class 0604: 1022:700d
00:07.0 Class 0601: 1022:7440 (rev 04)
00:07.1 Class 0101: 1022:7441 (rev 04)
00:07.3 Class 0680: 1022:7443 (rev 03) <----------- Southbridge
I have them on this MPX A7M266-D machine but its not finding it.
Shawn.
^ permalink raw reply
* Re: Determining Button State
From: James D Strandboge @ 2002-12-15 18:41 UTC (permalink / raw)
To: Pavel Machek; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20021210133100.GC2934-XqDnSF8rrUM@public.gmane.org>
On Tue, 2002-12-10 at 08:31, Pavel Machek wrote:
> Hi!
>
> > > Looking at rolling out some sort of ACPI script environment for acpid.
> > > Is there any way that the ACPI system determines exposes what state the
> > > subsystem is in.
> > >
> > > When I close the lid on my laptop, I get the event -
> > >
> > > button/lid LID 00000080 0000000b
> > > button/lid LID 00000080 0000000c
> > > button/lid LID 00000080 0000000d
> > > button/lid LID 00000080 0000000e
> > > button/lid LID 00000080 0000000f
> > >
> > > Which doesn't seem to have anything that indicates 'down or up'. I
> > > understand an 'up/down' doesn't make sense for Power or Sleep, but it
> > > seems pretty vital to something like a lid.
> >
> > Nope, and you can't use odd or even either because it changes. I did
> > this:
> ...
> > This however assumes that the lid is open when I power on (not an
> > unreasonable assumption usually, since I can't press the power button
> > otherwise). I chose /var/run since it is cleaned out automatically.
>
> Fortunately at least toshibas and thinkpads have
> power btn available with lid closed -- it is
> pretty bad to have to open the lid to turn
> the machine on -- especially with external
> keyboard and monitor. Toshiba has LEDs
> visible from the outside for added bonus.
That's cool. Is there anyway to poll the status of those led's from
linux (eg through acpi)? An even better way would be to ask the bios
the state of the lid when an event is generated-- or better still modify
the acpi code to generate 0 for closed and 1 for open (or just be
consistent about even and odd).
Jamie
--
Email: jstrand1-aYIB8uWIUb2Vn7q6wjsIow@public.gmane.org
GPG/PGP ID: 26384A3A
Fingerprint: D9FF DF4A 2D46 A353 A289 E8F5 AA75 DCBE 2638 4A3A
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* What has changed in the graphics part between 2.4.18 and 2.4.20
From: Andreas Tscharner @ 2002-12-15 18:43 UTC (permalink / raw)
To: Linux Kernel Mailinglist
Hello World,
I'm using the nVidia binary drivers (yes, I know that I should not use
them, but I need them if I want to play games like UT2003).
They work with kernel 2.4.18, but I got kernel hangs with 2.4.20. I have
submitted this bug to nVidia and wanted to ask here, what changes have
been made in the kernel 2.4.20 that may cause this problems.
Thanks and best 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
* Re: problem with Andrew's patch ext3
From: Andrew Morton @ 2002-12-15 18:34 UTC (permalink / raw)
To: Octave; +Cc: linux-kernel, ext3-users
In-Reply-To: <20021215182645.GS23211@ovh.net>
Octave wrote:
>
> On Sun, Dec 15, 2002 at 10:21:09AM -0800, Andrew Morton wrote:
> > Octave wrote:
> > >
> > > Hello Andrew,
> > >
> > > I patched 2.4.20 with your patch found out on http://lwn.net/Articles/17447/
> > > and I have a big problem with:
> > > once server is booted on 2.4.20 with your patch, when I want to reboot
> > > with /sbin/reboot, server makes a Segmentation fault and it crashs.
> >
> > It works OK here. Could you please check that the kernel was fully
> > rebuilt? Do a `make clean'? If the kernel was not fully rebuilt
> > then things will go wrong because a structure size was changed.
>
> yes, since I took a new tar.gz
> made dep && make clean && make bzImage
> I did it 5 times (for differents servers).
>
So is any additional information available? What was on the
console? If it was a kernel crash, a ksymoops trace would be
valuable.
The patch is at
http://www.zip.com.au/~akpm/linux/patches/2.4/2.4.20/sync_fs.patch
could you ensure that it was applied successfully?
^ permalink raw reply
* Re: [RFC][PATCH] net drivers and cache alignment
From: Jes Sorensen @ 2002-12-15 18:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: David S. Miller, jgarzik, linux-kernel, netdev
In-Reply-To: <3DF28988.93F268EA@digeo.com>
>>>>> "Andrew" == Andrew Morton <akpm@digeo.com> writes:
Andrew> Andrew Morton wrote:
>> Then I am most confused. None of these fields will be put under
>> busmastering or anything like that, so what advantage is there in
>> spreading them out?
Andrew> Oh I see what you want - to be able to pick up all the
Andrew> operating fields in a single fetch.
Andrew> That will increase the overall cache footprint though. I
Andrew> wonder if it's really a net win, over just keeping it small.
There's another case where it matters, I guess one could look at it as
similar to the SMP case, but between CPU and device. Some devices have
producer indices in host memory which they update whenever it
receiving a packet. By putting that seperate from TX data structures
you avoid the CPU and the NIC fighting over cache lines.
Cheers,
Jes
^ permalink raw reply
* Re: problem with Andrew's patch ext3
From: Octave @ 2002-12-15 18:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, ext3-users
In-Reply-To: <3DFCC815.3C0010F2@digeo.com>
On Sun, Dec 15, 2002 at 10:21:09AM -0800, Andrew Morton wrote:
> Octave wrote:
> >
> > Hello Andrew,
> >
> > I patched 2.4.20 with your patch found out on http://lwn.net/Articles/17447/
> > and I have a big problem with:
> > once server is booted on 2.4.20 with your patch, when I want to reboot
> > with /sbin/reboot, server makes a Segmentation fault and it crashs.
>
> It works OK here. Could you please check that the kernel was fully
> rebuilt? Do a `make clean'? If the kernel was not fully rebuilt
> then things will go wrong because a structure size was changed.
yes, since I took a new tar.gz
made dep && make clean && make bzImage
I did it 5 times (for differents servers).
Octave
>
> There is a locking error in that patch, and it needs revision. But
> that wouldn't explain this crash.
>
> And there is an unrelated use-after-free bug which could cause problems
> if the fs runs out of space or inodes.
>
> I'll get some fixes out later today. It hasn't been a good week.
^ permalink raw reply
* Oops removing battery module
From: Matthew Tippett @ 2002-12-15 18:13 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Another oops for you :)
The lead up to this is...
o Insert battery module (both BAT0 and BAT1 dirs are created)
o Remove battery module
o Insert battery module (no BAT? dir created,
info, state are directly in /proc/acpi/battery)
o Remove battery module (Ooops generated)
Regards
Matt
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c018ebcc>] Tainted: PF
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 00000008 ebx: 00000048 ecx: 00000000 edx: 00000000
esi: 000181a4 edi: 000181a4 ebp: 00008000 esp: cb371d00
ds: 0018 es: 0018 ss: 0018
Process kacpidpc (pid: 8428, stackpage=cb371000)
Stack: c5947428 c5947428 c2603b80 00000001 c029dbe8 c029dbe0 c0192714
00000002
c0171baf c5947428 cb371d54 00000040 c02935a5 c0293260 c0172137
c5947428
c5947428 cb371d84 c2603b80 c12ea8a8 cb371d84 00000040 c029378a
c0293260
Call Trace: [<c0192714>] [<c0171baf>] [<c0172137>] [<c0187c93>]
[<c01861c5>]
[<c0186c6c>] [<c018ec0a>] [<c01901bb>] [<c017203d>] [<c01871de>]
[<c01871f5>]
[<c016d54a>] [<c0187237>] [<c0187f86>] [<c0182400>] [<c01822c4>]
[<c0173094>]
[<c016b6c2>] [<c0172fcc>] [<c0105578>]
Code: 8b 04 30 89 83 80 d4 35 c0 8b 83 a0 d4 35 c0 ff 83 9c d4 35
>>EIP; c018ebcc <acpi_ut_acquire_from_cache+58/fc> <=====
>>esp; cb371d00 <_end+aff26f8/1049ca58>
Trace; c0192714 <acpi_ut_create_generic_state+c/18>
Trace; c0171baf <acpi_ds_result_stack_push+27/6c>
Trace; c0172137 <acpi_ds_create_walk_state+8f/d0>
Trace; c0187c93 <acpi_ps_delete_parse_tree+67/f4>
Trace; c01861c5 <acpi_ps_complete_this_op+1ed/214>
Trace; c0186c6c <acpi_ps_parse_loop+94c/e08>
Trace; c018ec0a <acpi_ut_acquire_from_cache+96/fc>
Trace; c01901bb <acpi_ut_exit+1f/2c>
Trace; c017203d <acpi_ds_push_walk_state+4d/58>
Trace; c01871de <acpi_ps_parse_aml+b6/288>
Trace; c01871f5 <acpi_ps_parse_aml+cd/288>
Trace; c016d54a <acpi_ds_call_control_method+16e/274>
Trace; c0187237 <acpi_ps_parse_aml+10f/288>
Trace; c0187f86 <acpi_psx_execute+266/2f0>
Trace; c0182400 <acpi_ns_execute_control_method+f0/110>
Trace; c01822c4 <acpi_ns_evaluate_by_handle+f0/13c>
Trace; c0173094 <acpi_ev_asynch_execute_gpe_method+c8/148>
Trace; c016b6c2 <acpi_os_queue_exec+9a/c0>
Trace; c0172fcc <acpi_ev_asynch_execute_gpe_method+0/148>
Trace; c0105578 <kernel_thread+28/38>
Code; c018ebcc <acpi_ut_acquire_from_cache+58/fc>
00000000 <_EIP>:
Code; c018ebcc <acpi_ut_acquire_from_cache+58/fc> <=====
0: 8b 04 30 mov (%eax,%esi,1),%eax <=====
Code; c018ebcf <acpi_ut_acquire_from_cache+5b/fc>
3: 89 83 80 d4 35 c0 mov %eax,0xc035d480(%ebx)
Code; c018ebd5 <acpi_ut_acquire_from_cache+61/fc>
9: 8b 83 a0 d4 35 c0 mov 0xc035d4a0(%ebx),%eax
Code; c018ebdb <acpi_ut_acquire_from_cache+67/fc>
f: ff 83 9c d4 35 00 incl 0x35d49c(%ebx)
4 warnings and 1 error issued. Results may not be reliable.
--
Matthew Tippett - matthew.tippett-rieW9WUcm8FFJ04o6PK0Fg@public.gmane.org - (416) 435-4118
Technology Forum - http://www.technology-forum.org/
Commercial Open Source - http://www.commercialos.org/
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: problem with Andrew's patch ext3
From: Andrew Morton @ 2002-12-15 18:21 UTC (permalink / raw)
To: Octave; +Cc: linux-kernel, ext3-users
In-Reply-To: <20021215144050.GY12395@ovh.net>
Octave wrote:
>
> Hello Andrew,
>
> I patched 2.4.20 with your patch found out on http://lwn.net/Articles/17447/
> and I have a big problem with:
> once server is booted on 2.4.20 with your patch, when I want to reboot
> with /sbin/reboot, server makes a Segmentation fault and it crashs.
It works OK here. Could you please check that the kernel was fully
rebuilt? Do a `make clean'? If the kernel was not fully rebuilt
then things will go wrong because a structure size was changed.
There is a locking error in that patch, and it needs revision. But
that wouldn't explain this crash.
And there is an unrelated use-after-free bug which could cause problems
if the fs runs out of space or inodes.
I'll get some fixes out later today. It hasn't been a good week.
^ permalink raw reply
* Re: Mirrored Display?
From: Antonino Daplas @ 2002-12-15 20:57 UTC (permalink / raw)
To: Michael Kaufmann; +Cc: Linux Fbdev development list
In-Reply-To: <200212151603.30592.kaufmann@sohard.de>
On Sun, 2002-12-15 at 22:03, Michael Kaufmann wrote:
> On Saturday 14 December 2002 23:29, you wrote:
> > On Fri, 2002-12-13 at 23:33, Michael Kaufmann wrote:
> > > Hello,
> > >
> > > i would like to use a mono LCD with a framebuffer driver.
> > >
> > > I've modified existing drivers, and after a lot of work i now have a
> > > clear picture on my display. Unfortunately, the complete picture is
> > > mirrored. The Bootlogo is top/right instead of top/left and the ascii
> > > output starts from right to left.
> > >
> > > Where is the right place to modify this behaviour?
> > > I'm also looking for a possibility to rotate the picture.
> > > Because my videocontroller can emulate 15 grayscales, i'm useing 4bpp.
> > >
> > > It would be very nice, if someone can guide me in the right direction.
> >
> > Are you using fbcon-cfb4.c to draw the characters? Is the whole display
> > mirrored, including individual characters? If you run an fb-based app
> > (like fbtest for instance), is the display also mirrored?
>
> Yes, i'm using fbon-cfb4.c. The console is on my display, i see the boot logo
> and the kernel messages in the display mirrored. I never used fbtest. By the
> way, where can i find fbtest? But i already startet nanox/microwindows on top
Check one of the links in www.linux-fbdev.org.
> of the fb, and the picture is also mirrored.
>
Ouch, your user apps are also mirrored :-(
> > If it's the whole display, maybe your hardware supports mirroring (some
> > hardware with video overlay need this to support YUV formats that are
> > either vertically or horizontally mirrored). Maybe it has something
> > like that. Otherwise, it will be difficult to correct this without
> > rewriting practically everything.
>
> No, i don't think so. It is a simple video controller. Nevertheless, i have
> just looked in the datasheet, and do not found such a feature.
>
> I don't think that this is a bug or something like this in the framebuffer.
> Because everthing works like i exect it, but i have to mirror the picture.
No, I never said this was a bug. Mirroring is a hardware feature
occasionally useful such as for mirrored mpegs.
> I have also measured with a scope all signals to the display, and the
> generated output looks like i expect it. The datastream starts with the first
> pixel (in the picture top/left) and continues with the second pixel (on the
> right of the first pixel) and so on.
> But my display is mapping this datastream from the right to the left.
This is the problem. You are writing each byte in the correct location
in the framebuffer, but somehow it gets shown in the "mirrored" location
of your display.
> Please take a look on the attached picture, i think it explains the behaviour.
> I can reproduce it without Linux with a simple monitor programm
>
> At the moment i have two explanations:
> 1) I have a display witch must be accessed unusual, and the LINUX FB doesn't
> support this kind of access (not yet).
> 2) There is a hardware problem with the signals to the display (changed
> signals like frame-pulse, and line-pulse, or something like this.
>
> I don't think that it is a hardware problem, but i will check the connection
> again. Is there really no way in the framebuffer to mirror and/or rotate the
> picture data?
> When i have to fix it in software, what kind of code do i have to rewrite?
Fixing the console is feasible enough though it entails a lot of work.
You have to rewrite all the functions in fbcon-cfb4.c so you go
"right->left" instead of "left->right". Do the same thing to
fbcon_show_logo() in fbcon.c, and fb_read/fb_write in fbmem.c.
Fixing user apps, that's the tough part. The framebuffer API is not
something like XAA which has specific hooks for filling, copying,
expanding, etc an area of pixels to the framebuffer. All the
framebuffer API provides are two ways to access the graphics memory
(similar to a watered-down version of X's DGA):
1. The standard file read/file write which will be intercepted by
fb_read and fb_write; and
2. mmap
Of the 2, mmap is usually chosen by user apps because it's simple and
fast. The disadvantage is that your driver has no control on what will
get displayed, and there is no feasible solution to this, except to
disable mmap by setting fb_fix_screeninfo.smem_len to zero. Hopefully,
if mmap is not possible, they will fall back to using file read and file
write.
User apps will always assume that the first pixel written to the
framebuffer will appear as the first pixel of the first scanline of your
display. Meaning, for apps that will always use mmap, you have to
rewrite them so they raster "right->left" instead of "left->right".
If you think about it, a hardware solution seems to be more feasible.
Tony
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* errors in symlinks in alsa-oss rc1 with mandrake 9.0
From: iriXx @ 2002-12-15 17:44 UTC (permalink / raw)
To: alsa-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi all
just a note to say i had to modify the symlinks to 'missing',
'mkinstalldirs' and 'install-sh' to get alsa-oss-0.9.0rc1 to install
under mandrake 9.0.
it seems that from 9.0 mandrake puts automake in /usr/share/automake-1.4
rather than /usr/share/automake. i dont know if anyone wants to add a
detection for this to the config script?
bw
m~
- --
iriXx
www.iriXx.org
copyleft: creativity, technology and freedom?
info@copyleftmedia.org.uk
www.copyleftmedia.org.uk
~ _
( ) ascii ribbon against html email
~ X
/ \ cat /dev/sda1 > /dev/dsp
~ *** stopping make sense ***
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE9/L+aGlmEEIa9/8YRApeaAJsGVSg/Bn9n0V+DdnapAFIR1C8boQCgqhHH
9M1ZetQs3d0qpvS/5mmN9Q0=
=cpwH
-----END PGP SIGNATURE-----
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Interoperability Testing
From: Trond Myklebust @ 2002-12-15 17:42 UTC (permalink / raw)
To: Meir Zaid; +Cc: nfs
In-Reply-To: <LOEPLAHJDCEFJHLCNHHCKEFOCBAA.meirz@actona.com>
>>>>> " " == Meir Zaid <meirz@actona.com> writes:
> Do you know of any conferences or interoperability labs that do
> this?
http://www.connectathon.org
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* RE: Kernel for Pentium 4 hyperthreading?
From: Scott Robert Ladd @ 2002-12-15 17:40 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel
In-Reply-To: <20021215155728.GB20335@suse.de>
Dave Jones wrote:
> Ah, apologies. Yes. In this case, you win. I bit the same problem you
> had btw with this box in 2.4. You need an updated BIOS. Contact Intel.
I'll ask Intel if there's a BIOS update. Computers are almost as bad as
games now; the first thing you need to do before using them is patch!
What evokes my curiosity is that the 2.5.51 kernel detects and correctly
uses the processor siblings, while 2.4.20 does not. Given that 2.5.51 is
running quite well, I think I'll just stay on the bleeding edge of Linux for
a while.
..Scott
--
Scott Robert Ladd
Coyote Gulch Productions, http://www.coyotegulch.com
No ads -- just very free (and somewhat unusual) code.
^ permalink raw reply
* [PATCH 2.4] Titan pci serial card recognition fix
From: Brian Murphy @ 2002-12-15 17:39 UTC (permalink / raw)
To: alan, linus; +Cc: linux-kernel
This patch fixes an error in the pci recognition table which
means that otherwise supportes Titan pci serial cards fail to
work.
This is the same as I just posted for the 2.5 kernel.
/Brian
--- drivers/char/serial.c 2002-12-15 18:21:15.000000000 +0100
+++ drivers/char/serial.c 2002-12-15 17:00:41.000000000 +0100
@@ -473,6 +473,7 @@
pbn_b1_4_115200,
pbn_b1_8_115200,
+ pbn_b1_1_921600,
pbn_b1_2_921600,
pbn_b1_4_921600,
pbn_b1_8_921600,
@@ -481,6 +482,8 @@
pbn_b1_4_1382400,
pbn_b1_8_1382400,
+ pbn_b1_bt_2_921600,
+
pbn_b2_1_115200,
pbn_b2_8_115200,
pbn_b2_4_460800,
@@ -494,6 +497,9 @@
pbn_b2_bt_4_115200,
pbn_b2_bt_2_921600,
+ pbn_bt_4_921600,
+ pbn_bt_8_921600,
+
pbn_panacom,
pbn_panacom2,
pbn_panacom4,
@@ -553,6 +559,7 @@
{ SPCI_FL_BASE1, 4, 115200 }, /* pbn_b1_4_115200 */
{ SPCI_FL_BASE1, 8, 115200 }, /* pbn_b1_8_115200 */
+ { SPCI_FL_BASE1, 1, 921600 }, /* pbn_b1_1_921600 */
{ SPCI_FL_BASE1, 2, 921600 }, /* pbn_b1_2_921600 */
{ SPCI_FL_BASE1, 4, 921600 }, /* pbn_b1_4_921600 */
{ SPCI_FL_BASE1, 8, 921600 }, /* pbn_b1_8_921600 */
@@ -561,6 +568,7 @@
{ SPCI_FL_BASE1, 4, 1382400 }, /* pbn_b1_4_1382400 */
{ SPCI_FL_BASE1, 8, 1382400 }, /* pbn_b1_8_1382400 */
+ { SPCI_FL_BASE1 | SPCI_FL_BASE_TABLE, 2, 921600 }, /* pbn_b1_bt_2_921600 */
{ SPCI_FL_BASE2, 1, 115200 }, /* pbn_b2_1_115200 */
{ SPCI_FL_BASE2, 8, 115200 }, /* pbn_b2_8_115200 */
{ SPCI_FL_BASE2, 4, 460800 }, /* pbn_b2_4_460800 */
@@ -574,6 +582,9 @@
{ SPCI_FL_BASE2 | SPCI_FL_BASE_TABLE, 4, 115200 }, /* pbn_b2_bt_4_115200 */
{ SPCI_FL_BASE2 | SPCI_FL_BASE_TABLE, 2, 921600 }, /* pbn_b2_bt_2_921600 */
+ { SPCI_FL_BASE_TABLE, 4, 921600 }, /* pbn_bt_4_921600 */
+ { SPCI_FL_BASE_TABLE, 8, 921600 }, /* pbn_bt_8_921600 */
+
{ SPCI_FL_BASE2, 2, 921600, /* IOMEM */ /* pbn_panacom */
0x400, 7, pci_plx9050_fn },
{ SPCI_FL_BASE2 | SPCI_FL_BASE_TABLE, 2, 921600, /* pbn_panacom2 */
@@ -1000,17 +1011,17 @@
pbn_b0_4_921600 },
{ PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_100L,
PCI_ANY_ID, PCI_ANY_ID,
- SPCI_FL_BASE1, 1, 921600 },
+ pbn_b1_1_921600 },
{ PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_200L,
PCI_ANY_ID, PCI_ANY_ID,
- SPCI_FL_BASE1 | SPCI_FL_BASE_TABLE, 2, 921600 },
+ pbn_b1_bt_2_921600 },
/* The 400L and 800L have a custom hack in get_pci_port */
{ PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_400L,
PCI_ANY_ID, PCI_ANY_ID,
- SPCI_FL_BASE_TABLE, 4, 921600 },
+ pbn_bt_4_921600 },
{ PCI_VENDOR_ID_TITAN, PCI_DEVICE_ID_TITAN_800L,
PCI_ANY_ID, PCI_ANY_ID,
- SPCI_FL_BASE_TABLE, 8, 921600 },
+ pbn_bt_8_921600 },
{ PCI_VENDOR_ID_SIIG, PCI_DEVICE_ID_SIIG_1S_10x_550,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.