* Re: USB-storage/SCSI panic/error writing CF card
From: Patrick Mansfield @ 2003-01-09 18:53 UTC (permalink / raw)
To: linux-kernel, linux-scsi
In-Reply-To: <20030109183614.GA1167@Master.Wizards>
On Thu, Jan 09, 2003 at 01:36:14PM -0500, Murray J. Root wrote:
> Writing to the card sometimes hangs the process when unmounting
>
> Sometimes the data IS written to the card first, then it hangs the process.
>
> Sometimes the card is corrupt (cannot cd to the mountpoint -I/O error)
> /var/log/messages has several lines like:
> Jan 9 13:08:51 Master kernel: FAT: Filesystem panic (dev sd(8,1))
> Jan 9 13:08:51 Master kernel: Directory 4: invalid cluster chain
>
> Sometimes get kernel panic with ONLY these 2 lines:
> "Error handler thread not present at f7a57000 f7bf0d80 drivers/scsi/scsi-error.c 154"
> "In interrupt handler - not syncing"
> No messages in logs
The panic is caused by timeout on a scsi command when the error handler
has unexpectedly gone away, possibly because of this bug, where the erorr
handler exits early because of a SIGHUP:
http://marc.theaimsgroup.com/?l=linux-scsi&m=104145526331820&w=2
Fixing the panic won't fix the corruption. scsi should really offline the
adapter and scsi devices on the adapter rather than panic.
-- Patrick Mansfield
^ permalink raw reply
* [PATCH] cpufreq: gcc-2.91.66 compatibility
From: Dominik Brodowski @ 2003-01-09 19:02 UTC (permalink / raw)
To: torvalds; +Cc: akpm, linux-kernel, cpufreq
Make gcc-2.91.66 happy. Noted by Andrew Morton - thanks.
Dominik
diff -ruN linux-original/kernel/cpufreq.c linux/kernel/cpufreq.c
--- linux-original/kernel/cpufreq.c 2003-01-09 19:16:00.000000000 +0100
+++ linux/kernel/cpufreq.c 2003-01-09 19:17:02.000000000 +0100
@@ -734,8 +734,8 @@
}
#else
-#define cpufreq_sysctl_init()
-#define cpufreq_sysctl_exit()
+#define cpufreq_sysctl_init() do {} while(0)
+#define cpufreq_sysctl_exit() do {} while(0)
#endif /* CONFIG_SYSCTL */
#endif /* CONFIG_CPU_FREQ_24_API */
@@ -946,7 +946,7 @@
loops_per_jiffy = cpufreq_scale(l_p_j_ref, l_p_j_ref_freq, ci->new);
}
#else
-#define adjust_jiffies(...)
+#define adjust_jiffies(x...) do {} while (0)
#endif
@@ -1131,6 +1131,6 @@
}
EXPORT_SYMBOL_GPL(cpufreq_restore);
#else
-#define cpufreq_restore()
+#define cpufreq_restore() do {} while (0)
#endif /* CONFIG_PM */
^ permalink raw reply
* [PATCH 2.5.55] cpufreq: new p4-m stepping 7
From: Dominik Brodowski @ 2003-01-09 19:02 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, cpufreq
Add support for mobile Pentium IV processors with stepping 7.
Dominik
diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/speedstep.c linux/arch/i386/kernel/cpu/cpufreq/speedstep.c
--- linux-original/arch/i386/kernel/cpu/cpufreq/speedstep.c 2003-01-09 19:15:40.000000000 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/speedstep.c 2003-01-09 19:20:33.000000000 +0100
@@ -447,7 +447,7 @@
if (c->x86_model != 2)
return 0;
- if (c->x86_mask != 4)
+ if ((c->x86_mask != 4) && (c->x86_mask != 7))
return 0;
ebx = cpuid_ebx(0x00000001);
^ permalink raw reply
* Re: [PATCH] Embed __this_module in module itself.
From: Sam Ravnborg @ 2003-01-09 18:49 UTC (permalink / raw)
To: Miles Bader; +Cc: Sam Ravnborg, Rusty Russell, linux-kernel
In-Reply-To: <buoy95vrugy.fsf@mcspd15.ucom.lsi.nec.co.jp>
On Thu, Jan 09, 2003 at 10:18:53AM +0900, Miles Bader wrote:
> Sam Ravnborg <sam@ravnborg.org> writes:
> > Not knowing much about v850, I wonder why you do not need to set the -m
> > option. Most other architectures do this.
>
> ???
>
> A far as I can see, no architecture does anything different than the
> default.
A little grepping gave the following result:
i386/Makefile:LDFLAGS := -m elf_i386
m68k/Makefile:LDFLAGS := -m m68kelf
mips/Makefile:LDFLAGS := -G 0
ppc64/Makefile:LDFLAGS := -m elf64ppc
s390/Makefile:LDFLAGS := -m elf_s390
s390x/Makefile:LDFLAGS := -m elf64_s390
sh/Makefile:LDFLAGS := -EL
sh/Makefile:LDFLAGS := -EB
sparc/Makefile:LDFLAGS := -m elf32_sparc
sparc64/Makefile:LDFLAGS := -m elf64_sparc
x86_64/Makefile:LDFLAGS := -m elf_x86_64
Little less than half of the architectures defines their own LDFLAGS.
Most of them set an emulation, most probarly inherited from i386.
>
> [Why on earth would -m be needed, anyway?]
I do not know, but as can be seen above several architectures use it.
I have seen your proposed patch for gnu.linkonce.
I do prefer to have it in arch/v850/Makefile because this is a workaround
for an architecture specific bug in ld.
Why not provide your own link script?
Sam
^ permalink raw reply
* Re: Rage128 as secondary adapter
From: Stefan Reinauer @ 2003-01-09 18:39 UTC (permalink / raw)
To: Jon Smirl, fbdev
In-Reply-To: <20030109174706.1471.qmail@web14907.mail.yahoo.com>
* Jon Smirl <jonsmirl@yahoo.com> [030109 18:47]:
> Can someone with access to the Rage128 documentation
> tell me how to do this from protected mode? I have the
> ROM mapped so the code can get to constants stored in
> the ROM. What I need is a piece of C code equal to
> what the ROM initialization does minus the part about
> Int10 vector setup.
I'm almost certain that the information you need is only
available when signing an NDA and thus could not be used
in open source drivers. Also a big problem for open source
firmware implementations such as openbios
> The programmers at ATI probably have a piece of code
> available to do this since ATI's Windows driver can do
> it. I've tried emailing and signing up as a developer
> without response.
This is a pretty common experience.
Stefan.
--
The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense. -- E. W. Dijkstra
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: CRAMFS on MTD/NAND Issue
From: Russ Dill @ 2003-01-09 19:07 UTC (permalink / raw)
To: Henrik Nordstrom; +Cc: Thomas Gleixner, Srinivasu.Vaduguri, linux-mtd
In-Reply-To: <Pine.LNX.4.44.0301090206130.14735-100000@filer.marasystems.com>
On Wed, 2003-01-08 at 18:08, Henrik Nordstrom wrote:
> On Wed, 8 Jan 2003, Thomas Gleixner wrote:
>
> > Mount your rootfs _readonly_ and you have the _same_ including bad block
> > handling.
>
> If a flag could be added to a jffs2 image denying it to be mounted
> read-write then yes..
>
I might reiterate that the end goal of cramfs is efficency, and decent
speed. The end goal of jffs2 is quite different (although it still
strives for those things). iirc, cramfs images usually end up being 5%
to 10% smaller than jffs2 images, they boot a lot faster, the code is a
lot smaller (especially helpfull if you want fs support in your
bootloader)
--
Russ Dill <Russ.Dill@asu.edu>
^ permalink raw reply
* Re: Kernel configurator request
From: John Bradford @ 2003-01-09 18:41 UTC (permalink / raw)
To: Tomas Szepe; +Cc: linux-kernel
In-Reply-To: <20030106175443.GP5984@louise.pinerecords.com>
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]
> > Obviously I can work around this, but it would seem to me to be better
> > to have the kernel configurators generate .config files like this:
> >
> > #
> > # Automatically generated make config: don't edit
> > #
> >
> > #
> > # Very general options
> > #
> > [Very general options]
>
> [snip]
>
> John,
>
> AFAIK all you have to do to make this reality is add a "comment" clause
> where you need it.
Excellent...
John.
[-- Attachment #2: ASCII text --]
[-- Type: text/plain, Size: 300 bytes --]
--- linux-2.5.55-orig/arch/i386/Kconfig 2003-01-09 18:34:19.000000000 +0000
+++ linux-2.5.55/arch/i386/Kconfig 2003-01-09 18:39:34.000000000 +0000
@@ -3,6 +3,8 @@
# see Documentation/kbuild/kconfig-language.txt.
#
+comment "General options"
+
mainmenu "Linux Kernel Configuration"
config X86
^ permalink raw reply
* Re: [patch 2.5] 2-pass PCI probing, generic part
From: David Mosberger @ 2003-01-09 18:36 UTC (permalink / raw)
To: Ivan Kokshaysky
Cc: Linus Torvalds, Alan Cox, Grant Grundler, Paul Mackerras,
Benjamin Herrenschmidt, Eric W. Biederman, davidm,
Linux Kernel Mailing List, greg
In-Reply-To: <20030109204626.A2007@jurassic.park.msu.ru>
>>>>> On Thu, 9 Jan 2003 20:46:26 +0300, Ivan Kokshaysky <ink@jurassic.park.msu.ru> said:
Ivan> As discussed, this patch splits PCI probing into 2 phases.
Ivan> 1. Do the full bus enumeration, collect identification info for
Ivan> all devices, call early fixup routines. At this stage we
Ivan> can solve two kinds of problems:
Ivan> - turn off devices generating PCI traffic, so we'll be
Ivan> safe in the phase 2 (USB DMA case);
Ivan> - allow alternative probing methods for devices that
Ivan> cannot be safely probed by generic code (powermac I/O ASIC).
Ivan> 2. Sizing the BARs. Now it's possible to disable the device
Ivan> being probed, which should fix ia64 case. Note that we
Ivan> don't need to keep the device disabled when sizing ROM
Ivan> base register, as we probe with ROM-enable bit cleared.
Sounds good (haven't tested the code yet, but it looks fine to me).
--david
^ permalink raw reply
* USB-storage/SCSI panic/error writing CF card
From: Murray J. Root @ 2003-01-09 18:36 UTC (permalink / raw)
To: linux-kernel
kernel 2.5.55
USB support & OHCI-HCD compiled in
scsi support compiled in
scsi disk support as a module
usb-storage as a module
no devfs
ASUS P4S533 (SiS645DX chipset)
P4 2GHz
1G PC2700 RAM
SanDisk SDDR-77 ImageMate Dual Card Reader (using only CF)
Writing to the card sometimes hangs the process when unmounting
Sometimes the data IS written to the card first, then it hangs the process.
Sometimes the card is corrupt (cannot cd to the mountpoint -I/O error)
/var/log/messages has several lines like:
Jan 9 13:08:51 Master kernel: FAT: Filesystem panic (dev sd(8,1))
Jan 9 13:08:51 Master kernel: Directory 4: invalid cluster chain
Sometimes get kernel panic with ONLY these 2 lines:
"Error handler thread not present at f7a57000 f7bf0d80 drivers/scsi/scsi-error.c 154"
"In interrupt handler - not syncing"
No messages in logs
--
Murray J. Root
------------------------------------------------
DISCLAIMER: http://www.goldmark.org/jeff/stupid-disclaimers/
------------------------------------------------
Mandrake on irc.freenode.net:
#mandrake & #mandrake-linux = help for newbies
#mdk-cooker = Mandrake Cooker
#cooker = moderated Mandrake Cooker
^ permalink raw reply
* 2.4.21-pre3-ac2 oops
From: Geller Sandor @ 2003-01-09 18:33 UTC (permalink / raw)
To: linux-kernel
Hello!
I encountered a kernel oops. When that happened, I was extracting XFree86
4.2.1 sources to a reiserfs filesystem.
ksymoops 2.4.5 on i686 2.4.20-ac2. Options used
-V (default)
-k /var/log/ksymoops/20030109113946.ksyms (specified)
-l /var/log/ksymoops/20030109113946.modules (specified)
-o /lib/modules/2.4.21-pre3-ac2/ (specified)
-m /boot/System.map-2.4.21-pre3-ac2 (specified)
Jan 9 19:02:36 warpers kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000004
Jan 9 19:02:36 warpers kernel: c012ca10
Jan 9 19:02:36 warpers kernel: *pde = 00000000
Jan 9 19:02:36 warpers kernel: Oops: 0002
Jan 9 19:02:36 warpers kernel: CPU: 0
Jan 9 19:02:36 warpers kernel: EIP: 0010:[__free_pages_ok+624/652]
Not tainted
Jan 9 19:02:36 warpers kernel: EFLAGS: 00010246
Jan 9 19:02:36 warpers kernel: eax: 00000000 ebx: c106fa94 ecx:
c106fa94 edx: c12d0000
Jan 9 19:02:36 warpers kernel: esi: 00000000 edi: 00000020 ebp:
000001ba esp: c12d1dc4
Jan 9 19:02:36 warpers kernel: ds: 0018 es: 0018 ss: 0018
Jan 9 19:02:36 warpers kernel: Process kupdated (pid: 7, stackpage=c12d1000)
Jan 9 19:02:36 warpers kernel: Stack: c2899120 c106fa94 00000020
000001ba c013644e c106fa94 000000f0 00000020
Jan 9 19:02:36 warpers kernel: 000001ba c01349ac c2899120
c2899120 c2899120 c012d043 c012c11c 00000020
Jan 9 19:02:36 warpers kernel: 000000f0 00000020 00000006
00000006 c12d0000 00001145 000000f0 c029dd54
Jan 9 19:02:36 warpers kernel: Call Trace:
[try_to_free_buffers+146/236] [try_to_release_page+68/72] [__free_pages+27/28] [shrink_cache+724/764] [shrink_caches+88/136]
Jan 9 19:02:36 warpers kernel: Code: 89 58 04 89 03 8d 42 5c 89 43 04 89
5a 5c 89 73 0c ff 42 68
Using defaults from ksymoops -t elf32-i386 -a i386
>>ebx; c106fa94 <_end+d31120/d56968c>
>>ecx; c106fa94 <_end+d31120/d56968c>
>>edx; c12d0000 <_end+f9168c/d56968c>
>>esp; c12d1dc4 <_end+f93450/d56968c>
Code; 00000000 Before first symbol
00000000 <_EIP>:
Code; 00000000 Before first symbol
0: 89 58 04 mov %ebx,0x4(%eax)
Code; 00000003 Before first symbol
3: 89 03 mov %eax,(%ebx)
Code; 00000005 Before first symbol
5: 8d 42 5c lea 0x5c(%edx),%eax
Code; 00000008 Before first symbol
8: 89 43 04 mov %eax,0x4(%ebx)
Code; 0000000b Before first symbol
b: 89 5a 5c mov %ebx,0x5c(%edx)
Code; 0000000e Before first symbol
e: 89 73 0c mov %esi,0xc(%ebx)
Code; 00000011 Before first symbol
11: ff 42 68 incl 0x68(%edx)
Geller Sandor <wildy@petra.hos.u-szeged.hu>
^ permalink raw reply
* latest mtd code from CVS cannot be compiled with the latest linuxppc_2_4_devel tree? Weird???
From: Xiaogeng (Shawn) Jin @ 2003-01-09 18:51 UTC (permalink / raw)
To: linux-mtd
Hi,
I had a compilation error when compiling linuxppc_2_4_devel
(v2.4.21-pre3) with the latest mtd code. Here is the error message.
ppc_8xx-gcc -D__KERNEL__
-I/u/xjin/2_4_devel/Software/Linux/MPC855/linuxppc_2_4_
devel/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2
-fno-strict-aliasing
-fno-common -fomit-frame-pointer
-I/u/xjin/2_4_devel/Software/Linux/MPC855/linux
ppc_2_4_devel/arch/ppc -fsigned-char -msoft-float -pipe -ffixed-r2
-Wno-uninitia
lized -mmultiple -mstring -nostdinc -I
/opt/eldk2.0/usr/lib/gcc-lib/ppc-linux/
2.95.4/include -DKBUILD_BASENAME=mtdblock_core -c -o mtdblock-core.o
mtdblock-c
ore.c
In file included from
/u/xjin/2_4_devel/Software/Linux/MPC855/linuxppc_2_4_devel
/include/linux/blk.h:4,
from mtdblock-core.c:18:
/u/xjin/2_4_devel/Software/Linux/MPC855/linuxppc_2_4_devel/include/linux/blkdev.
h:147: parse error before `struct'
I tried to solve the problem by moving #include <linux/blk.h> forward,
which is originally after #include <linux/mtd/compatmac.h>. So
mtdblock-core.c became the following.
#include <linux/config.h>
#include <linux/types.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/blk.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/compatmac.h>
#include "mtdblock.h"
And the error was gone.
However when mtdblock-24.c was compiled, the same error message occured.
And this time I had no such luck because there seems to be some specific
sequence to be followed when headers are included. This time
<linux/blk.h> cannot be moved forward. So I doubt that I solved the
compilation error in mtdblock-core.c.
#include <linux/config.h>
#include <linux/types.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/compatmac.h>
#include "mtdblock.h"
#define DEVICE_REQUEST mtdblock_request
#define DEVICE_NR(device) (device)
#define DEVICE_ON(device)
#define DEVICE_OFF(device)
#define DEVICE_NO_RANDOM
#include <linux/blk.h>
The compiler I used is from ELDK 2.0 (ppc_8xx-gcc 2.95.4). Is it a known
problem that already has been solved?
--
Shawn Jin
RedSwitch Inc.
^ permalink raw reply
* Re: Radeonfb in 2.5.54bk
From: James Simmons @ 2003-01-09 18:17 UTC (permalink / raw)
To: Joshua Kwan; +Cc: linux-fbdev-devel
In-Reply-To: <20030107154141.259f84c3.joshk@ludicrus.ath.cx>
> Latest patch? If it's the one you pushed to BK a day or two ago, that is
> what I used in the compilation of my kernel. Hence it doesn't quite
> work.
>
> (to be precise, i issued:
> bk clone http://linux.bkbits.net:8080/linux-2.5
> bk -r get
> bk pull http://fbdev.bkbits.net:8080/fbdev-2.5)
>
> Anything wrong there? Do I have to bk -r get again?
>
> Looks like I am subscribing to this list then. Sigh... too many lists to
> take care of!! :(
More changes happened. Can you try another pull.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: const fb_{fillrect,copyarea,image}?
From: James Simmons @ 2003-01-09 18:16 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux Frame Buffer Device Development
In-Reply-To: <Pine.GSO.4.21.0301072227110.21057-100000@vervain.sonytel.be>
> drivers/video/fbmem.c:fb_show_logo() initializes only image.dx in each loop
> iteration:
>
> | for (x = 0; x < num_online_cpus() * (LOGO_W + 8) &&
> | x < info->var.xres - (LOGO_W + 8); x += (LOGO_W + 8)) {
> | image.dx = x;
> | info->fbops->fb_imageblit(info, &image);
> | done = 1;
> | }
Oh.
> > > Of course this means that we have to modify the clipping code, which currently
> > > just modifies the passed structure.
> >
> > :-( That is done to prevent someone from passing data that is larger than
> > the framebuffer.
>
> You can still do clipping without modifying the passed structure, right?
Probable it can be arranged this way.
> BTW, is it possible that someone passes data that is larger (except for bugs)?
> We have control over what happens in the kernel. Data passed from userspace is
> a different issue, of course.
Yes. Soon the standard ioctl for a cursor will be truly in place. This
means cfb_imageblit could be a issue from userland.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* [LARTC] Question on HTB and police
From: Cheng Kwok Wing, William @ 2003-01-09 18:15 UTC (permalink / raw)
To: lartc
Hi,
I've read the following post that the htb doesn't
support police. I would like to know if htb supports
police filter now.
Does anyone know anything about this???
William
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: MB without keyboard controller / USB-only keyboard ?
From: Randy.Dunlap @ 2003-01-09 18:16 UTC (permalink / raw)
To: Alan Cox; +Cc: Stephan von Krawczynski, Linux Kernel Mailing List
In-Reply-To: <1042137928.27796.48.camel@irongate.swansea.linux.org.uk>
On 9 Jan 2003, Alan Cox wrote:
| On Thu, 2003-01-09 at 17:39, Stephan von Krawczynski wrote:
| > > > pc_keyb: controller jammed (0xFF)
| > >
| > > Does your BIOS do keyboard emulation ?
| >
| > It is Compaq EVO D510. It has merely nothing of interest in the BIOS (no
| > keyboard emu). As far as I remember it contains an I845 chipset.
|
| Can you use the USB keyboard to configure the BIOS during boot. If so
| then it almost certainly has USB bios emulation. Another trivial test
| that would be useful is to stick a freedos boot floppy in the box and
| see if freedos works
| -
PS/2 keyboard emulation might not show up in the BIOS Setup menu.
Or do you know that the BIOS doesn't contain PS/2 keyboard emulation?
Have you installed Linux on it? If so, how did you do that?
Once past this hurdle, there are patches that can help.
--
~Randy
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH][FBDEV]: fb_putcs() and fb_setfont() methods
From: James Simmons @ 2003-01-09 18:09 UTC (permalink / raw)
To: Antonino Daplas
Cc: Geert Uytterhoeven, Petr Vandrovec, Linux Fbdev development list,
Linux Kernel List, davidm
In-Reply-To: <1042050026.982.172.camel@localhost.localdomain>
> :-) I did not want prolong the discussion, but...
>
> Geert is correct that the functions are generic. The fb_putcs() and
> fb_setfont() can be compared to Tile blitting. Tile blitting is a
> common operation in some games such as Warcraft, Starcraft, and most
> RPG's. I'm think there is Tile Blitting support in DirectFB.
>
> In a tile-based game, the basic unit is a Tile which is just a bitmap
> with a predefined width and height. The game has several tiles stored in
> memory each with it's own unique id. To draw the background/layer, a
> TileMap is constructed which is basically another array. Its format is
> something like this - TileMap[x] = y which means draw Tile y at screen
> position x.
>
> In the fbcon perspective, we can think of each character as a Tile, and
> fontdata as the collection of tiles. fb_char.data is basically a
> TileMap. Of course, tile blitting in games is more complicated than
> this, since games have multiple layers for the background, so layer
> position, transparency, etc has to be considered.
>
> So maybe if we can rename fb_putcs() to fb_tileblit(), fb_setfont() to
> fb_loadtiles(), struct fb_chars to struct fb_tilemap and struct
> fb_fontdata to struct fb_tiledata, maybe it will be more acceptable?
>
> It can be even be expanded by including fb_tiledata.depth
> fb_tiledata.cmap so we can support multi-colored tiled blitting.
This I have no problem with. I'm willing to accept this. As long as data
from the console layer is not touched. As for loadtiles one thing I like
to address is memory allocation. It probable is good idea to do things
like place the tile data in buffers allocated by pci_alloc_consistent.
The other fear is it will only support so many tiles.
^ permalink raw reply
* Question on SMP (super micro 370dl3)
From: AU @ 2003-01-09 18:15 UTC (permalink / raw)
To: Suse-linux-e; +Cc: Linux Kernel Mailing List
In-Reply-To: <1042137928.27796.48.camel@irongate.swansea.linux.org.uk>
Hi,
I have a question with my linux box. I am using supermicro 370dl3, dual
1GHz. 2 HD one on scsi aic-7892, the other one on Promise 100 TX2.
I am running SuSE 8.0, current kernel version is 2.4.18, coming with
installation. Now I am try to upgrade to 2.4.19. However, I use the 2.4.19
from ftp://ftp.suse.com/pub/people/mantel/linux-2.4.19-41.tar.bz2. It
doest boot up right. when it detect hd on pdc20268 then it give me "lost
interrupt" message. This message can go away if I use command line
"noapic" at boot prompt.
So, I switch to 2.4.19 from ftp.kernel.edu, then this kernel it boot fine
without any argument at boot prompt.
Can anybody guide me to make 2.4.19 from suse ftp site work without put
"noapic" at boot prompt.
One more thing this machine can not shutdown, even it is atx case. I tried
to put acpi on but it give me some table name error.
Thank you.
+AU
^ permalink raw reply
* Re: Wireless Extensions v16-3 - clean patches
From: Jean Tourrilhes @ 2003-01-09 18:13 UTC (permalink / raw)
To: Joshua M. Kwan; +Cc: linux-kernel
In-Reply-To: <20030109043119.GA13910@kanoe.ludicrus.net>
On Wed, Jan 08, 2003 at 08:31:19PM -0800, Joshua M. Kwan wrote:
> Hi Jean,
>
> I have attached two patches that allow current 2.5.54 BK and 2.4.20
> vanilla to patch cleanly from whatever WE they came with to WE16,
> from your site. This is easier since the patches on your website for
> 2.4.20 require two patches, and the 2.5.x one has a single reject
> that was not hard to resolve (just a few line breaks here and there
> and editing of the surrounding text confused patch.)
>
> For 2.5, the BK i diffed against was a fresh tree from today, but
> since you're the one that makes all the changes to those files
> anyway, it really doesn't matter until a new WE is pushed! And then
> this patch won't be necessary at all :)
>
> Both patches should be placed in the root of the source tree and
> applied with -p0.
>
> Hope this can benefit others who would like to easily upgrade their
> WE :)
>
> Regards
> Josh
Thanks for the good work !
For 2.4.X : 2.4.21-pre2 has WE-15, so if you get it it's only
one patch (the one on my page).
For 2.5.X : my Pcmcia cards still don't work with 2.5.54, so
I'm currently no too worried about 2.5.X at the moment.
Also, the current WE16-3 may not be the final version, as I'm
waiting for feedback from driver authors. Talking of feedback, which
part of WE16 do you need and why ?
Have fun...
Jean
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH][FBDEV]: fb_putcs() and fb_setfont() methods
From: James Simmons @ 2003-01-09 18:09 UTC (permalink / raw)
To: Antonino Daplas
Cc: Geert Uytterhoeven, Petr Vandrovec, Linux Fbdev development list,
Linux Kernel List, davidm
In-Reply-To: <1042050026.982.172.camel@localhost.localdomain>
> :-) I did not want prolong the discussion, but...
>
> Geert is correct that the functions are generic. The fb_putcs() and
> fb_setfont() can be compared to Tile blitting. Tile blitting is a
> common operation in some games such as Warcraft, Starcraft, and most
> RPG's. I'm think there is Tile Blitting support in DirectFB.
>
> In a tile-based game, the basic unit is a Tile which is just a bitmap
> with a predefined width and height. The game has several tiles stored in
> memory each with it's own unique id. To draw the background/layer, a
> TileMap is constructed which is basically another array. Its format is
> something like this - TileMap[x] = y which means draw Tile y at screen
> position x.
>
> In the fbcon perspective, we can think of each character as a Tile, and
> fontdata as the collection of tiles. fb_char.data is basically a
> TileMap. Of course, tile blitting in games is more complicated than
> this, since games have multiple layers for the background, so layer
> position, transparency, etc has to be considered.
>
> So maybe if we can rename fb_putcs() to fb_tileblit(), fb_setfont() to
> fb_loadtiles(), struct fb_chars to struct fb_tilemap and struct
> fb_fontdata to struct fb_tiledata, maybe it will be more acceptable?
>
> It can be even be expanded by including fb_tiledata.depth
> fb_tiledata.cmap so we can support multi-colored tiled blitting.
This I have no problem with. I'm willing to accept this. As long as data
from the console layer is not touched. As for loadtiles one thing I like
to address is memory allocation. It probable is good idea to do things
like place the tile data in buffers allocated by pci_alloc_consistent.
The other fear is it will only support so many tiles.
^ permalink raw reply
* Re: [PATCH] Fix socket.c compilation failure when CONFIG_NET=n
From: Jean Tourrilhes @ 2003-01-09 18:06 UTC (permalink / raw)
To: Miles Bader; +Cc: linux-kernel
In-Reply-To: <20030107064107.C19A73745@mcspd15.ucom.lsi.nec.co.jp>
On Tue, Jan 07, 2003 at 03:41:07PM +0900, Miles Bader wrote:
> [I send this to Linus earlier and he ignored it; maybe you're the right
> person...]
>
> In net/socket.c, <linux/wireless.h> is included twice, once conditionally
> (on CONFIG_NET_RADIO || CONFIG_NET_PCMCIA_RADIO) and once unconditionally.
> However, including <linux/wireless.h> defines WIRELESS_EXT, and this causes an
> #ifdef in `sock_ioctl' to reference `dev_ioctl', which isn't defined when
> CONFIG_NET=n, and so results in an unresolved symbol reference in that case.
>
> The following patch fixes this by removing the unconditional include, and only
> keeping the conditional one.
>
> Thanks,
>
> -Miles
>
> diff -ruN -X../cludes linux-2.5.54-moo.orig/net/socket.c linux-2.5.54-moo/net/socket.c
> --- linux-2.5.54-moo.orig/net/socket.c 2002-11-25 10:30:11.000000000 +0900
> +++ linux-2.5.54-moo/net/socket.c 2003-01-06 13:27:17.000000000 +0900
> @@ -75,7 +75,6 @@
> #include <linux/cache.h>
> #include <linux/module.h>
> #include <linux/highmem.h>
> -#include <linux/wireless.h>
> #include <linux/divert.h>
> #include <linux/mount.h>
This was included in 2.5.55, so I guess Linus didn't ignored you.
Regards,
Jean
^ permalink raw reply
* [parisc-linux] pa-risc 64 compilation
From: FARINATI,LEANDRO (HP-Brazil,ex1) @ 2003-01-09 17:52 UTC (permalink / raw)
To: Parisc-Linux List (E-mail)
Hi people,
I have a problem to compile an 64 kernel in an 64 machine. The
problem is: hppa64-linux-gcc compiler not found. Someone know what happened?
Where I find this gcc version?
Thanks in advance,
-----------------------------------------------------------------------
Leandro Marcondes Farinati
Software Developer
* leandro.farinati@hp.com
* +55-51-3316-2852 Telnet 725-2852
FAX +55-51-3316-2754 Mobile +55-51-9965-8020
^ permalink raw reply
* Re: MB without keyboard controller / USB-only keyboard ?
From: Alan Cox @ 2003-01-09 18:45 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: Linux Kernel Mailing List
In-Reply-To: <20030109183952.6be142fe.skraw@ithnet.com>
On Thu, 2003-01-09 at 17:39, Stephan von Krawczynski wrote:
> > > pc_keyb: controller jammed (0xFF)
> >
> > Does your BIOS do keyboard emulation ?
>
> It is Compaq EVO D510. It has merely nothing of interest in the BIOS (no
> keyboard emu). As far as I remember it contains an I845 chipset.
Can you use the USB keyboard to configure the BIOS during boot. If so
then it almost certainly has USB bios emulation. Another trivial test
that would be useful is to stick a freedos boot floppy in the box and
see if freedos works
^ permalink raw reply
* Re: atyfb: 2.5.54
From: Nico Schottelius @ 2003-01-09 8:38 UTC (permalink / raw)
To: James Simmons; +Cc: linux-fbdev-devel
In-Reply-To: <Pine.LNX.4.44.0301072154010.17129-100000@phoenix.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 731 bytes --]
James Simmons [Tue, Jan 07, 2003 at 09:54:51PM +0000]:
>
> > With 2.5.54 there is something like success with my hardware.
> > Now I get a cursor at the right position. I can't see what I type,
> > but I see the cursor moving correctly.
> > After unloading atyfb the console still behaves this way, nothing
> > changes.
> >
> > Are there some options I should set ? I am currently just loading
> > atyfb (with recognizes my card as PCI although it's AGP; seen in dmesg).
>
> Can do post your dmesg.
!dmesg
atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz XTAL, 230 MHz PLL, 50 Mhz MCLK
fb0: ATY Mach64 frame buffer device on PCI
Just tell me, if you need more information.
Nico
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: atyfb: 2.5.54
From: Nico Schottelius @ 2003-01-09 8:43 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: James Simmons, Linux Frame Buffer Device Development
In-Reply-To: <Pine.GSO.4.21.0301072257220.21057-100000@vervain.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 190 bytes --]
Geert Uytterhoeven [Tue, Jan 07, 2003 at 10:58:25PM +0100]:
> Atyfb is known not to work on some Rage Mobility P/M (incl. the one in my Vaio
> :-(
I hope this changes soon ;)
Nico
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Benjamin Herrenschmidt @ 2003-01-09 17:52 UTC (permalink / raw)
To: Ivan Kokshaysky
Cc: Linus Torvalds, Alan Cox, Grant Grundler, Paul Mackerras,
Eric W. Biederman, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <20030109204626.A2007@jurassic.park.msu.ru>
On Thu, 2003-01-09 at 18:46, Ivan Kokshaysky wrote:
> There is no need for changes to arch-specific code, as everything
> is hidden in pci_scan_bus(). However, it's possible to use
> pci_scan_bus_parented() and pci_probe_resources() directly,
> because some arch-specific fixups between these two might
> be useful.
>
> Note: on powermacs, if the I/O ASIC is behind PCI-PCI bridge, the
> bridge device probably should be marked as "skip_probe" as well.
Good.
Yes, On these, I'll skip the pci<->pci bridge in cases there is one on
the path too, this will add some nasty logic to the pmac pci code, but
that's ok as long as that crap doesn't leak out of
arch/ppc/platforms/pmac_*
Ben.
^ 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.