* Re: new Debian packages
From: Les Bell @ 2002-12-15 2:03 UTC (permalink / raw)
To: Brian May; +Cc: Russell Coker, selinux
Brian May <bam@snoopy.apana.org.au> wrote:
>>
errr.... FreeS/WAN project aren't interested in X.509, X.509 is an extra
unsupported patch to the FreeS/WAN patch (although both are integrated
in the Debian packaging).
<<
You're quite right, Brian - X.509 is a patch, though it's integrated into
Super FreeS/WAN (http://www.freeswan.ca).
Best,
--- Les Bell, CISSP
[http://www.lesbell.com.au]
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: DMA from SCSI controller to PCI frame buffer memory.
From: Douglas Gilbert @ 2002-12-15 2:06 UTC (permalink / raw)
To: linux-kernel; +Cc: Jason Howard <""
Jason wrote:
> Any recommendations on where to start hacking? Would
> it be a good idea to add O_DIRECT to a mmaped PCI space?
> The kernel should not be doing any buffering whatsoever,
> as we will be coming close to filling the pci bus up
> with transfers from direct disk->fb already. (We are
> already doing buffering on the FB card as well)
Jason,
Here is a less general solution that I worked on some
time ago involving the scsi generic driver.
http://www.torque.net/sg/mem2disk.html
It worked ok for one application in the early 2.4 series.
Doug Gilbert
^ permalink raw reply
* PROBLEM: 2.4.{19,20} fails to resume if radeon.o is loaded
From: tho @ 2002-12-15 2:04 UTC (permalink / raw)
To: dri-devel; +Cc: linux-kernel
Hi,
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.
I noticed also that the radeon.o module sometimes refuses to
be removed claiming that some resources were still busy (while
I wasn't aware of using DRM).
Software:
vanilla Linux Kernel + FreeSWAN patch 2.4.19 as well as 2.4.20
Debian 3.0
modutils 2.4.21
binutils 2.12.90.0.1 20020307
gcc 2.95.4
Hardware:
IBM ThinkPad X22 (2662XXK)
ATI Radeon Mobility M6 LY
Please let me know, if I can help solving this issue by providing
more information or otherwise. I'm actually OK with how things
are right now (I don't use DRM), but this should be documented.
Maybe the kernel build system should prevent one from choosing
to build the radeon DRM as module, if CONFIG_APM is set?
Guenther
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: J.A. Magallon @ 2002-12-15 2:03 UTC (permalink / raw)
To: GrandMasterLee; +Cc: linux-kernel
In-Reply-To: <1039890995.17062.1.camel@localhost>
On 2002.12.14 GrandMasterLee wrote:
>On Sat, 2002-12-14 at 04:01, Dave Jones wrote:
>> On Fri, Dec 13, 2002 at 11:53:51PM -0500, Mike Dresser wrote:
>> > On Fri, 13 Dec 2002, Mike Dresser wrote:
>> >
>> > > The single P4/2.53 in another machine can haul down in 3m17s
>> > >
>> > Amend that to 2m19s, forgot to kill a background backup that was moving
>> > files around at about 20 meg a second.
>
>
>
>> Note that there are more factors at play than raw cpu speed in a
>> kernel compile. Your time here is slightly faster than my 2.8Ghz P4-HT for
>> example. My guess is you have faster disk(s) than I do, as most of
>> the time mine seems to be waiting for something to do.
>
>An easy way to level the playing field would be to use /dev/shm to build
>your kernel in. That way it's all in memory. If you've got a maching
>with 512M, then it's easily accomplished.
>
tmpfs does not guarantee you that it is always in ram. It also can be paged.
An easier way is to fill you page cache with the kernel tree like
werewolf:/usr/src/linux# grep -v -r "" *
and then build, so no disk read will be trown.
--
J.A. Magallon <jamagallon@able.es> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.20-jam1 (gcc 3.2 (Mandrake Linux 9.1 3.2-4mdk))
^ permalink raw reply
* lsscsi for lk 2.5.51
From: Douglas Gilbert @ 2002-12-15 1:51 UTC (permalink / raw)
To: linux-scsi; +Cc: patmans
[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]
Since sysfs now contains a reasonable amount of data about
scsi devices, it is possible to write an application
that scans this information and presents it in a "ls"
form (akin to lspci and lsusb).
Attached is a toy program called lsssci that could
grow into something more useful. It requires lk 2.5.51
or later.
$ lsscsi
[4:0:0:0] CDROM CREATIVE CD5233E 1.00 /dev/sr0
[3:0:0:0] disk Linux scsi_debug 0004 /dev/sdb
[2:0:6:0] tape SONY SDT-7000 0192
[0:0:8:0] disk FUJITSU MAM3184MP 0105 /dev/sda
This output corresponds to my system which has these "scsi"
devices:
$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 08 Lun: 00
Vendor: FUJITSU Model: MAM3184MP Rev: 0105
Type: Direct-Access ANSI SCSI revision: 03
Host: scsi2 Channel: 00 Id: 06 Lun: 00
Vendor: SONY Model: SDT-7000 Rev: 0192
Type: Sequential-Access ANSI SCSI revision: 02
Host: scsi3 Channel: 00 Id: 00 Lun: 00
Vendor: Linux Model: scsi_debug Rev: 0004
Type: Direct-Access ANSI SCSI revision: 03
Host: scsi4 Channel: 00 Id: 00 Lun: 00
Vendor: CREATIVE Model: CD5233E Rev: 1.00
Type: CD-ROM ANSI SCSI revision: 02
sysfs doesn't provide the ANSI SCSI revision number associated
with each device (hopefully Pat can add that in the future).
Otherwise, all the information that /proc/scsi/scsi uses 3
lines per device for, can be compressed onto one line. Putting
the device node (e.g. /dev/sda) seems a useful addition.
[That latter addition is only done currently for block scsi
devices (hence it doesn't appear for the tape).]
Doug Gilbert
[-- Attachment #2: lsscsi.c.gz --]
[-- Type: application/x-gzip, Size: 2279 bytes --]
^ permalink raw reply
* Re: MFS: possible bad behaviour of the function exists
From: Stas Sergeev @ 2002-12-15 1:50 UTC (permalink / raw)
To: linux-msdos
Hello.
J. Solomon Kostelnik wrote:
> I get this same problem in 1.1.3.7
Well, your problem is probably not the
same.
If the patch submitted under the same
subject doesn't help you, read on.
> I also get some very strange behavior if I try to save a file. If I
> attempt to save to a filename that does not exist, it will ask me if I
> want to replace the existing file!
I suffered from the same problem a lot.
It appears to be this:
--------D-216C00-----------------------------
INT 21 - DOS 4.0+ - EXTENDED OPEN/CREATE
AX = 6C00h
BL = open mode as in AL for normal open (see also AH=3Dh)
[]
BUG: this function has bugs (at least in DOS 5.0 and 6.2)
when used with
drives handled via the network redirector (INT 2F/AX=112Eh):
- CX (attribute) is not passed to the redirector if DL=11h,
- CX does not return the status, it is returned unchanged
because
DOS does a PUSH CX/POP CX when calling the redirector.
---
In case you suffer this BUG (applies also to a
PC-DOS), then the only solution would be to
switch to FreeDOS.
This bug plagued all the DosNavigator users
to death when they tried it under dosemu.
^ permalink raw reply
* Re: rmap and nvidia?
From: Eyal Lebedinsky @ 2002-12-15 1:40 UTC (permalink / raw)
To: Linux Kernel
In-Reply-To: <3DFBDAC6.40100@free.fr>
Philip Dodd wrote:
>
> Eyal Lebedinsky wrote:
> 8<
> > The replies for people in the know (Rik, wli) give a clue but not an
> > answer. Use mere mortals want a proper patch in order to build and
> > use this kernel.
>
> This driver, you mean ;-)
Well, yes and no. This kernel is of no use to me without this driver
right now.
--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>
^ permalink raw reply
* Re: rmap and nvidia?
From: Philip Dodd @ 2002-12-15 1:28 UTC (permalink / raw)
To: Eyal Lebedinsky; +Cc: Linux Kernel
In-Reply-To: <3DFBD98E.53E9D8BB@eyal.emu.id.au>
Eyal Lebedinsky wrote:
8<
> The replies for people in the know (Rik, wli) give a clue but not an
> answer. Use mere mortals want a proper patch in order to build and
> use this kernel.
8<
This driver, you mean ;-)
^ permalink raw reply
* Re: Modem Identification
From: Ray Olszewski @ 2002-12-15 1:19 UTC (permalink / raw)
To: Linux Newbie
In-Reply-To: <200212142014.07963.sotl155360@earthlink.net>
At 08:14 PM 12/14/02 -0500, Frank Roberts - SOTL wrote:
>Hi All
>
>
>Question:
> >From the command line how does one determine which port a modem is on?
It depends on exactly what you mean. I'm guessing that you intend to refer
to a situation where you have 2 or more serial ports in a computer, and a
modem conencted to one of them, but the ports are unlabeled so you dont
know which one the modem is attached to. In that case, I would use a
terminal app (such as minicom) to connect to each port, and see which port
(actuall, its associated /dev/ttyS* entry) gets responses from the modem to
typical AT commands.
There are many more things you *might* mean, though. So if I've guessed
wrong (and someone else does not guess right), please post a followup that
asks the question in a different, more specific form.
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
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: 2.4.21-pre1 broke the ide-tape driver
From: Marc-Christian Petersen @ 2002-12-15 1:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Mikael Pettersson
In-Reply-To: <200212150119.CAA02575@harpo.it.uu.se>
On Sunday 15 December 2002 02:19, Mikael Pettersson wrote:
Hi Mikael,
> Kernel 2.4.21-pre1 broke the ide-tape driver: the driver
> now hangs during initialisation. 2.2 kernels (with Andre's
> IDE patch) and 2.4 up to 2.4.20 do not have this problem.
> My box has a Seagate STT8000A ATAPI tape drive as hdd;
> hdc is a Philips CD-RW, and the controller is ICH2 (i850 chipset).
http://linux.bkbits.net:8080/linux-2.4/patch@1.828?nav=index.html|ChangeSet@-7d|cset@1.828
ciao, Marc
^ permalink raw reply
* Re: rmap and nvidia?
From: Eyal Lebedinsky @ 2002-12-15 1:23 UTC (permalink / raw)
To: Linux Kernel
In-Reply-To: <Pine.LNX.4.50L.0212141225320.32283-100000@imladris.surriel.com>
Rik van Riel wrote:
>
> On Sat, 14 Dec 2002, mdew wrote:
> > On Sat, 2002-12-14 at 22:38, William Lee Irwin III wrote:
> > > On Sat, Dec 14, 2002 at 10:36:10PM +1300, mdew wrote:
> > > > nv.c: In function `nv_get_phys_address':
> > > > nv.c:2182: warning: implicit declaration of function `pte_offset'
> > > > nv.c:2182: invalid type argument of `unary *'
> > >
> > > Use pte_offset_map() with a corresponding pte_unmap().
> >
> > err pardon?
>
> wli just gave you the information you need to create a patch
> for the nvidia driver.
The replies for people in the know (Rik, wli) give a clue but not an
answer. Use mere mortals want a proper patch in order to build and
use this kernel.
I will summarise my understanding so far; The original code says:
unsigned long
nv_get_phys_address(unsigned long address)
{
pgd_t *pg_dir;
pmd_t *pg_mid_dir;
pte_t *pte__, pte;
.....
#if defined (pte_offset_atomic)
pte__ = pte_offset_atomic(pg_mid_dir, address);
pte = *pte__;
pte_kunmap(pte__);
#else
pte__ = NULL;
pte = *pte_offset(pg_mid_dir, address);
#endif
if (!pte_present(pte))
goto failed;
return ((pte_val(pte) & KERN_PAGE_MASK) | NV_MASK_OFFSET(address));
.....
}
The last line above is the problem. So far I could see two possible
changes that will compile, but I do not know which will function
correctly. The first replacement option:
pte = *pte_offset(pg_mid_dir, address);
The second replacement option is more involved:
pte__ = pte_offset_map(pg_mid_dir, address);
pte = *pte__;
if (!pte_present(pte))
goto failed;
pte_unmap(pte__);
Reading the patch itself I see places where the first approach is used,
while elsewhere the second is used. I do not know what pte_val(pte)
requires though. Can we do the pte_unmap(pte__) earlier or is the
mapping
necessary for pte_present(pte)? Will this work:
pte__ = pte_offset_map(pg_mid_dir, address);
pte = *pte__;
pte_unmap(pte__);
In summary, you can see that for someone who is not intimately involved
the answers so far do not provide a working patch.
Thanks everybody.
--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>
^ permalink raw reply
* Modem Identification
From: Frank Roberts - SOTL @ 2002-12-15 1:14 UTC (permalink / raw)
To: Linux Newbie
Hi All
Question:
From the command line how does one determine which port a modem is on?
Thanks
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
* 2.4.21-pre1 broke the ide-tape driver
From: Mikael Pettersson @ 2002-12-15 1:19 UTC (permalink / raw)
To: marcelo; +Cc: linux-kernel
Kernel 2.4.21-pre1 broke the ide-tape driver: the driver
now hangs during initialisation. 2.2 kernels (with Andre's
IDE patch) and 2.4 up to 2.4.20 do not have this problem.
My box has a Seagate STT8000A ATAPI tape drive as hdd;
hdc is a Philips CD-RW, and the controller is ICH2 (i850 chipset).
dmesg log from inserting ide-tape as a module:
ide-tape: Dumping ATAPI Identify Device tape parameters
ide-tape: Protocol Type: <6>ATAPI
ide-tape: Device Type: 1 - <6>Streaming Tape Device
ide-tape: Removable: Yes
ide-tape: Command Packet DRQ Type: <6>Accelerated DRQ
ide-tape: Command Packet Size: <6>12 bytes
ide-tape: Model: Seagate STT8000A
ide-tape: Firmware Revision: 5.51
ide-tape: Serial Number:
ide-tape: Write buffer size: 372736 bytes
ide-tape: DMA: Yes
ide-tape: LBA: Yes
ide-tape: IORDY can be disabled: Yes
ide-tape: IORDY supported: Yes
ide-tape: ATAPI overlap supported: No
ide-tape: PIO Cycle Timing Category: 2
ide-tape: DMA Cycle Timing Category: 2
ide-tape: Single Word DMA supported modes: <6>0 <6>1 <6>2 <6>
ide-tape: Multi Word DMA supported modes: <6>0 <6>1 <6>2 <6>(active) <6>
ide-tape: Enhanced PIO Modes: Mode 3
ide-tape: Minimum Multi-word DMA cycle per word: <6>120 ns
ide-tape: Manufacturer's Recommended Multi-word cycle: <6>120 ns
ide-tape: Minimum PIO cycle without IORDY: <6>120 ns
ide-tape: Minimum PIO cycle with IORDY: <6>120 ns
ide-tape: hdd <-> ht0: Seagate STT8000A rev 5.51
--- long delay here, about a minute or so
hdd: irq timeout: status=0xd0 { Busy }
hdd: DMA disabled
hdd: ATAPI reset complete
--- long delay here, about a minute or so
hdd: irq timeout: status=0xd0 { Busy }
hdd: ATAPI reset complete
--- long delay here, about a minute or so
hdd: irq timeout: status=0xd0 { Busy }
hdd: ATAPI reset complete
--- at this point I'm tired of waiting and reboot the machine
/Mikael
^ permalink raw reply
* Re: [RFC] Hardware support notes for the kernel crypto API (2.5+)
From: James Morris @ 2002-12-15 1:15 UTC (permalink / raw)
To: Andrew McGregor; +Cc: linux-kernel, David S. Miller, cryptoapi-devel
In-Reply-To: <9000000.1039901292@localhost.localdomain>
On Sun, 15 Dec 2002, Andrew McGregor wrote:
> But OpenBSD has drivers, and they say that Broadcom were very good to deal
> with. I suggest writing the OpenBSD driver maintainer and asking who to
> contact.
The OpenBSD developer said he's given up talking to Broadcom and declined
to provide the email address of his contact.
Although I'm sure we can work something out if we can actually find the
right person to talk to.
- James
--
James Morris
<jmorris@intercode.com.au>
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH] fix endian problem in color_imageblit
From: Antonino Daplas @ 2002-12-15 1:05 UTC (permalink / raw)
To: Paul Mackerras
Cc: James Simmons, Linux Kernel Mailing List,
Linux Fbdev development list
In-Reply-To: <15864.1386.543811.337732@argo.ozlabs.ibm.com>
On Thu, 2002-12-12 at 08:41, Paul Mackerras wrote:
> This patch fixes the endian problems in color_imageblit(). With this
> patch, I get the penguin drawn properly on boot.
>
> The main change is that on big-endian systems, when we load a pixel
> from the source, we now shift it to the left-hand (most significant)
> end of the word. With this change the rest of the logic is correct on
> big-endian systems. This may not be the most efficient way to do
> things but it is a simple change that works and avoids disturbing the
> rest of the code.
>
Nice catch :-) We also need a similar fix for slow_imageblit(), so
James can you apply the attached patch also:
Also, I noticed that some drivers load the pseudo_palette with entries
whose length matches the length of the pixel. The cfb_* functions
always assume that each pseudo_palette entry is an "unsigned long", so
bpp16 will segfault, and so will bpp24/32 for 64-bit machines.
Tony
diff -Naur linux-2.5.51/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.51/drivers/video/cfbimgblt.c 2002-12-15 00:54:04.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c 2002-12-15 00:54:21.000000000 +0000
@@ -189,6 +189,7 @@
color = fgcolor;
else
color = bgcolor;
+ color <<= LEFT_POS(bpp);
val |= SHIFT_HIGH(color, shift);
/* Did the bitshift spill bits to the next long? */
Tony
^ permalink raw reply
* Kernel for Pentium 4 hyperthreading?
From: Scott Robert Ladd @ 2002-12-15 1:11 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20021215005654.GE27658@fs.tum.de>
Okay, I'm going bald even faster than usual.
I've just received a new computer based on a 2.8 GHz Pentium 4 with
hyper-threading enabled. Yes, HT is enabled in the BIOS; yes, /proc/cpuinfo
shows the 'ht' flag; yes, I've compiled 2.4.20 (stock) with SMP and ACPI
enabled.
No, it doesn't work. cat /proc/cpuinfo reports a single CPU.
I've also tried a 2.5.51 kernel -- and it, indeed, does find "both"
processors, listing them in cpuinfo as siblings. Looking at the boot logs,
2.5.51 seems to work just fien with my CPU.
For many reasons, I'd prefer to be running the 2.4.20 kernel (if nothing
else, I'm having trouble getting loadable modules -- the nVidia drivers for
one -- to work on 2.5.51.)
Can 2.4.20 handle a Pentium 4 (not Xeon, mind you) with HT? What could I be
missing in my kernel build?
What is especially frustrating is that the factory-installed Windows XP had
no trouble at all using the HT-enable P4 (until I sent WinXP to the great
bit-bucket in the sky).
Thanks in advance.
..Scott
^ permalink raw reply
* Re: [PATCH] Obvious(ish): 3c515 should work if ISAPNP is a module.
From: Matthew Bell @ 2002-12-15 1:05 UTC (permalink / raw)
To: kai-germaschewski, mwsb; +Cc: linux-parport, linux-kernel
Oh bum. I had it that way originally, for that reason, then left for a while, wondered what I was doing and removed the 'superflous' bit.
+#if defined(CONFIG_ISAPNP) || (defined (MODULE) && defined (CONFIG_ISAPNP_MODULE))
Matthew Bell
----- Original Message -----
From: Kai Germaschewski <kai-germaschewski@uiowa.edu>
Date: Sat, 14 Dec 2002 17:11:49 -0600 (CST)
To: Matthew Bell <mwsb@operamail.com>
Subject: Re: [PATCH] Obvious(ish): 3c515 should work if ISAPNP is a module.
> On Sun, 15 Dec 2002, Matthew Bell wrote:
>
> > This is valid for at least 2.4.20 and earlier; it works for me, and I
> > can't see any exceptional reason why it shouldn't work when ISAPNP is a
> > module.
>
> > --- linux-2.4.19.orig/drivers/net/3c515.c 2002-02-25 19:37:59.000000000 +0000
> > +++ linux-2.4.19/drivers/net/3c515.c 2002-08-03 18:24:05.000000000 +0100
> > @@ -370,7 +370,7 @@
> > { "Default", 0, 0xFF, XCVR_10baseT, 10000},
> > };
> >
> > -#ifdef CONFIG_ISAPNP
> > +#if defined(CONFIG_ISAPNP) || defined (CONFIG_ISAPNP_MODULE)
> > static struct isapnp_device_id corkscrew_isapnp_adapters[] = {
> > { ISAPNP_ANY_ID, ISAPNP_ANY_ID,
> > ISAPNP_VENDOR('T', 'C', 'M'), ISAPNP_FUNCTION(0x5051),
> [...]
>
> It's really only obvious*ish*: If isapnp is a module but 3c515 built-in,
> you'll get link errors. The real fix for this is to do
>
> +#ifdef __ISAPNP__
>
> which will get all cases right.
>
> --Kai
>
>
--
_______________________________________________
Get your free email from http://mymail.operamail.com
Powered by Outblaze
^ permalink raw reply
* Re: Why does the _DoubleTalk card_ not have a major assigned?
From: Adrian Bunk @ 2002-12-15 1:01 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: George G. Davis, Jim Van Zandt, device, lkml
In-Reply-To: <Pine.LNX.4.44.0212041646190.775-100000@xanadu.home>
On Wed, Dec 04, 2002 at 04:50:50PM -0500, Nicolas Pitre wrote:
> On Wed, 4 Dec 2002, Adrian Bunk wrote:
>
> > This is indeed true for the Comtrol Rocketport card but there's no
> > major for the DoubleTalk card (and this is the card I wanted to write
> > about).
>
> Maybe because it doesn't need a static major? For funky hardware like the
> Doubletalk for which the number of Linux users worldwide can probably be
> counted on your fingers you can just grep /proc/devices for its allocated
> major and create the /dev node on the fly.
Thanks for your answer, I knew that this might have been a silly
question (and my confusing first mail didn't make it better...).
> Nicolas
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Linux-2.4.20: bug with radeonfb
From: Adrian Bunk @ 2002-12-15 0:56 UTC (permalink / raw)
To: José Luis Tallón; +Cc: linux-kernel
In-Reply-To: <5.1.1.6.0.20021203004621.00b5a770@mail.adv-solutions.net>
On Tue, Dec 03, 2002 at 01:52:09AM +0100, José Luis Tallón wrote:
> Environment: gcc-2.95.4, latest dev tools from Debian "Sarge"( testing )
> Kernel: 2.4.20 + patch-2.4.20-ac1 from ftp.kernel.org
>...
> "No Go's":
> Radeon M7 AGP:
> - Framebuffer: unreadable output ( did work _perfectly_ with
> Linux-2.4.19 ).
> Looks like there's a bug somewhere in the rendering code( kernel
> autodetects and configures a 175x65 framebuffer, as previously):
> output seems to be "misplaced" -- might be a little assumption when
> calculating line offsets.
> Text lines, although bent to the right( 60º angle or so ), look _extremely
> long_ (might be a wrong appreciation)
> "Tux" logo is unrecogniceable too :(
>
> - DRM 4.1( v20020828 ) works nicely with XFree 4.2.1
> - Xvid extension works
>
> dmesg gives this ( double-checked with 2.4.19 ): relevant sections are
> identical to 2.4.19
> ---
> Pentium 4 Mobility - stepping 04
> [...]
> ref_clk=2700, ref_div=12, xclk=16600 from BIOS
> Samsung LTN-1050P1-L02 flatpanel
> DFP 1400x1050 from BIOS
> Radeon M7 LW DDR SGRAM 64MB
> colour framebuffer 175x65
>...
Does it work if you revert the patch against drivers/video/radeonfb.c
that is in -ac?
Does it work in plain 2.4.20 (without the -ac patch)?
> TIA
> Regards,
> J.L.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] Obvious(ish): 3c515 should work if ISAPNP is a module.
From: Zwane Mwaikambo @ 2002-12-15 0:55 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: Matthew Bell, linux-parport, linux-kernel
In-Reply-To: <Pine.LNX.4.50.0212141944400.32566-100000@montezuma.mastecende.com>
On Sat, 14 Dec 2002, Zwane Mwaikambo wrote:
> > +#ifdef __ISAPNP__
> >
> > which will get all cases right.
>
> ... but unfortunately thats currently going away ;) to make way for
> CONFIG_PNP
>
> Zwane
>
Someone needs their coffee...
--
function.linuxpower.ca
^ permalink raw reply
* Re: [PATCH] Obvious(ish): 3c515 should work if ISAPNP is a module.
From: Zwane Mwaikambo @ 2002-12-15 0:45 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: Matthew Bell, linux-parport, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212141709250.7099-100000@chaos.physics.uiowa.edu>
On Sat, 14 Dec 2002, Kai Germaschewski wrote:
> On Sun, 15 Dec 2002, Matthew Bell wrote:
>
> > This is valid for at least 2.4.20 and earlier; it works for me, and I
> > can't see any exceptional reason why it shouldn't work when ISAPNP is a
> > module.
>
> > --- linux-2.4.19.orig/drivers/net/3c515.c 2002-02-25 19:37:59.000000000 +0000
> > +++ linux-2.4.19/drivers/net/3c515.c 2002-08-03 18:24:05.000000000 +0100
> > @@ -370,7 +370,7 @@
> > { "Default", 0, 0xFF, XCVR_10baseT, 10000},
> > };
> >
> > -#ifdef CONFIG_ISAPNP
> > +#if defined(CONFIG_ISAPNP) || defined (CONFIG_ISAPNP_MODULE)
> > static struct isapnp_device_id corkscrew_isapnp_adapters[] = {
> > { ISAPNP_ANY_ID, ISAPNP_ANY_ID,
> > ISAPNP_VENDOR('T', 'C', 'M'), ISAPNP_FUNCTION(0x5051),
> [...]
>
> It's really only obvious*ish*: If isapnp is a module but 3c515 built-in,
> you'll get link errors. The real fix for this is to do
>
> +#ifdef __ISAPNP__
>
> which will get all cases right.
... but unfortunately thats currently going away ;) to make way for
CONFIG_PNP
Zwane
--
function.linuxpower.ca
^ permalink raw reply
* Re: Symlink indirection
From: Andrew Walrond @ 2002-12-15 0:41 UTC (permalink / raw)
To: Stephen Wille Padnos; +Cc: linux-kernel
In-Reply-To: <3DFB8B7C.10802@verizon.net>
Hi steve
Stephen Wille Padnos wrote:
>
> What would you expect to happen if you then did:
> echo "d/w" > d/w
>
> Which physical directory would you expect a new file to go into?
>
Using my example:
mkdir a
echo "a/x" > a/x
echo "a/y" > a/y
echo "a/z" > a/z
mkdir b
echo "b/y" > b/y
mkdir c
echo "c/z" > c/z
mkdir d
mount --bind a d
mount --bind --overlay b d
mount --bind --overlay c d
cat d/x
"a/x"
cat d/y
"b/y"
cat d/z
"c/z"
Then...
echo "d/w" > d/w would create a new file in directory a.
echo "d/y" > d/y would replace the file b/y
etc...
Is this sort of thing possible, or are there fundamental reasons that
would make it difficult?
Andrew
^ permalink raw reply
* Re: Re: pci-skeleton duplex check
From: Steffen Persvold @ 2002-12-15 0:37 UTC (permalink / raw)
To: Russell King
Cc: arun4linux, Michael Richardson, netdev, Linux Kernel Mailing List
In-Reply-To: <20021214161446.B23020@flint.arm.linux.org.uk>
On Sat, 14 Dec 2002, Russell King wrote:
> On Sat, Dec 14, 2002 at 08:05:30PM +0530, arun4linux wrote:
> > Interfaces should NEVER change in patch level versions.
> > Just *DO NOT DO IT*.
> > I do agree on this.
>
> Rubbish.
>
> Think about what you've just said. Patch level version changes are
> things like 2.5.43 to 2.5.44 or 2.4.19 to 2.4.20.
>
> You are saying that we shouldn't change any interfaces between (eg)
> 2.5.43 and 2.5.44, but we should change every interface we want to
> change between 2.4.15 and 2.5.0.
>
> This is obviously completely bogus. 2.5 is a _development_ tree.
> Everyone should expect anything, including interfaces to change
> between each development patch level.
>
> > This is a common complaint about linux kernel developers. And this always
> > gives an insecure feeling :-) for the device driver or kernel module
> > programmers.
>
> If interfaces are changed without extremely good reason between two
> _stable_ patch level versions, that would be a bug.
>
There have been a few during 2.4... The alloc_kiovec stuff for instance
and zap_page_range. 2.2 was much more stable.
Interface changes in development series is (or atleast should be to
everyone using linux) a known "feature".
Regards,
--
Steffen Persvold | Scali AS
mailto:sp@scali.com | http://www.scali.com
Tel: (+47) 2262 8950 | Olaf Helsets vei 6
Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY
^ permalink raw reply
* Re: new Debian packages
From: Brian May @ 2002-12-15 0:24 UTC (permalink / raw)
To: Les Bell; +Cc: Russell Coker, selinux
In-Reply-To: <OFABDD1FCC.C3C23AF2-ONCA256C90.00007F8A@lesbell.com.au>
On Sun, Dec 15, 2002 at 11:10:06AM +1100, Les Bell wrote:
> The FreeS/WAN developers seem mostly unconcerned by this - their view is
> that the kernel IPSec code is just one small part of a complete IPSec
> implementation; there's also a lot of user-space code for key management,
> authentication via X.509 certificates, etc. which they've been working on
errr.... FreeS/WAN project aren't interested in X.509, X.509 is an extra
unsupported patch to the FreeS/WAN patch (although both are integrated
in the Debian packaging).
I asked (in person) one of the FreeS/WAN developers about this at
OLS2002, and was told that they aren't currently interested in
supporting X.509 and have no plans to support it in the future.
(please correct me if I am mistaken though).
--
Brian May <bam@snoopy.apana.org.au>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: new Debian packages
From: Les Bell @ 2002-12-15 0:10 UTC (permalink / raw)
To: Russell Coker; +Cc: Brian May, selinux
Russell Coker <russell@coker.com.au> wrote:
>>
FreeS/WAN is in a similar situation, it's never going into the main kernel
tree and there's already a replacement for 2.6.
<<
The FreeS/WAN developers seem mostly unconcerned by this - their view is
that the kernel IPSec code is just one small part of a complete IPSec
implementation; there's also a lot of user-space code for key management,
authentication via X.509 certificates, etc. which they've been working on
for a long time now. FWIW, I'm sticking with FreeS/WAN for the time being.
. .
Best,
--- Les Bell, CISSP
[http://www.lesbell.com.au]
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ 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.