-CURRENT and -STABLE fails on IBM R30 in agp_ali.c
Hello,
there is a problem in ali_agp.c (both, -CURRENT and -STABLE): If I
boot the generic kernel, it panics in agp_ali.c, when it tries to
allocate memory for the gatt. Some simlpe tests showed, that the
initial aperture size is reported as zero by the device:
static int
agp_ali_attach(device_t dev)
{
struct agp_ali_softc *sc = device_get_softc(dev);
struct agp_gatt *gatt;
int error;
error = agp_generic_attach(dev);
if (error)
return error;
sc->initial_aperture = AGP_GET_APERTURE(dev);
This is zero-^^
for (;;) {
gatt = agp_alloc_gatt(dev);
if (gatt)
break;
/*
* Probably contigmalloc failure. Try reducing the
* aperture so that the gatt size reduces.
*/
if (AGP_SET_APERTURE(dev, AGP_GET_APERTURE(dev) / 2)) {
agp_generic_detach(dev);
return ENOMEM;
}
}
sc->gatt = gatt;
/* Install the gatt. */
Since I don't have a machine ready running -CURRENT, I can't really
debug this. How can I disable agp0 on boot time?
Björn Fischer
--
-BEGIN GEEK CODE BLOCK-
GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L---(++) !E W- N+ o>+
K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+
--END GEEK CODE BLOCK--
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pax fix (was Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs)
On Wed, Jun 12, 2002 at 04:27:19AM +0200, Cyrille Lefevre wrote: [...] > already done using the NetBSD way. the problem is that they use > LC_TIME (hugh!) to pass the format string to strftime while > LC_TIME isn't suppose to contain any format strings but a locale > name. Ew! That won't work for my needs. > I'm not sure that adding a yet another non portable option would > be good. how about using env var PAX_TIMEFMT instead ? PAX_TIMEFMT would be fine. Does it already exist? Björn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pax fix (was Re: WARNING! New GNU Tar in 5-CURRENT could erroneously create world writeable dirs)
> PS : I've finished to merge diffs from OpenBSD last week, but diffs > w/ NetBSD are really big... so, be patient :P What about bin/35886? Björn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
On Thu, Feb 14, 2002 at 07:22:59PM -0500, Alexander N. Kabaev wrote:
> > This suggests a problem with the runtime-linker (rtld), not binutils.
> Actually, the bug is somewhere in the new binutils code, and I am very
> close to finding where it is exactly. The new liker fails to set
> DT_TEXTREL property in the shared library header even though its relocation
> table contains several entries which refer to the code segment. As a result,
> ld-elf.so.1 fails to enable writes on the text segment when relocating the
> binary and crashes with SIGBUS while processing the very first relocation
> record.
> I still need some time in debugger to find a proper way to fix this.
Interesting. Is the DF_TEXTREL flag set in DT_FLAGS instead? Is the
library linked w/ -enable-new-dtags? Are the new dtags enabled by
default in the new binutils? Someting in elf32.em?
Currently I'm experimenting with some code that enhances the FreeBSD
runtime linker to handle some newer ELF features, such as DT_RUNPATH,
DT_FLAGS and ${ORIGIN} substitution sequences
-Björn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Thu, Sep 14, 2000 at 02:37:06PM +0200, Poul-Henning Kamp wrote: [...] > The majority of these programs could be handled by adding knowledge > of "-" as a magic filename to fopen(3). > > At the same time I would really love if we implemented "|.*" to mean > "do an popen(3)" instead. This would break POSIX and raise a security flaw in many applications. fopen(3) *never* should perform a fork/exec. Scary. Bjoern -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L---(++) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Sat, Jun 17, 2000 at 01:56:11PM +0900, Mitsuru IWASAKI wrote: > I think OS-initiated S4 (hibernation) in FreeBSD has enough advantages > because we can do `Save-to-Disk' anywhere even on non-laptop machines > which BIOS doesn't support hibernation. > FreeBSD supports crash dump facility here, so I'm expecting that > `Save-to-Disk' by kernel would not be so difficult. We might need > dedicated swap partition for OS-initiated S4 because used swap areas > need to be protected for the system oprerations after awakening. > The boot loader is the best place for restoring the system context in > FreeBSD I think. Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt), turning power off, maybe adding some hardware or moving the machine to another location, then switching on again, restoring the system context, and the machine will proceed as if nothing had happened, do you? Björn -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L---(++) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nuts'n'bolts in vfs_bio
On Fri, Jan 29, 1999 at 01:23:05AM -0800, Matthew Dillon wrote: [...] > Please try this diff ( against RELENG_3 kern/vfs_bio.c ) and > tell me if it works. > > This is for STABLE only. Current already has this patch. Hello Matthew, thank you for reviewing vfs_bio.c. Your patch seems to solve the problem with NFS writes remaining uncommitted. At the time I can't see any NFS related data corruption. But when shutting down the server it still panics complaining about dirty bufs. (happens in 9 out of 10 times). Bjoern -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBLOSI$ P+++(-) L+++(-) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
nuts'n'bolts in vfs_bio
Hello, as Matthew said in freebsd-current@ vfs_bio:getblk() still needs work (B_CACHE/B_DELWRI stuff). Running 3.0-stable (Jan 26) it still happens that some NFS writes seem to remain uncommited on the server. Is there a chance to get it into -stable before releasing in mid February? Thanks, Bjoern -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBLOSI$ P+++(-) L+++(-) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: vinvalbuf: dirty bufs (during reboot, several times)
On Tue, Jan 19, 1999 at 11:00:55PM -0800, Matthew Dillon wrote: [...] > ::But there's still something wrong: When shutting down the server > ::it still sometimes panics in vinvalbuf() complaining 'bout dirty > ::pages. On the client side vi dies of SEGV (edited file and > ::/var/tmp/vi.recover on nfs fs) generating a wrong sized recover > ::file. After that the server panics on shutdown. Without triggering > ::the bug it shuts down gracefully. > :: > ::I'll try to receipe a situation for easily reproducing this. > :: > :: Bjoern > [...] > With that out of the way, if the vinvalbuf() problem still occurs > our best bet is if Bjoern can give us a repeatable vi SEGV / shutdown > sequence that results in the panic. > > If I can reproduce it on one of my machines, I can probably figure out > what is going on. If both of you are running NFS, it could possibly be > the NFS server forgetting to unbusy a page somewhere. If you aren't > running NFS, it could be an actual bug in FFS somewhere(!). ok, here are some instructions which -- I hope -- reproduce it (I haven't found a *nice* way; this is the ridiculous way): NFS server and client are completely 3.0-CURRENT (of CTM src-cur.3712.gz) with Luoqi's NFS fix. The server has all (physical) file systems mounted with softupdates except `/'. On the client simply edit `http://www.freebsd.org/~yokota/sc_update.txt' (hey, don't laugh. Other files won't do it. Not even files with the same size.) with FreeBSD vanilla vi (nvi). `sc_update.txt' is also attached to this mail if the file in it's original location had been changed recently. vi doesn't start normally, but skrews up and gets into an uninterruptible state. Trying to kill the beast makes it SEGV. (Of course everything is pretty normal when viing on the server.) The file system which contains the file and the one which contains /var/tmp/vi.recover are NFS ver2,udp,hard (although ver3,tcp/udp should work^H^H^H^Hfail, too). They don't need to be separate mounts. After the vi-SEGV try to shutdown the server with `shutdown -[rh] now'. You may shutdown the client first -- it makes no difference. Then you will get the panic. Good luck. Bjoern -- (sig_t*)NULL Last update: 12 January 1999. Kazutaka YOKOTA yok...@freebsd.org --- I) Syscons Update II) Splash Screen III) Splash Screen/Screen Saver FAQ --- I) Syscons Update Major update for the console driver started on 10 January. New keyboard and video card drivers have been introduced (This is just the begining. There will be more updates to follow in the next few months.) Because of these changes, you must update several things in your -current system. 1. You are required to update your kernel configuration file. If you are using syscons, controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 #device psm0at isa? tty irq 12 device vga0at isa? port ? conflicts device sc0 at isa? tty pseudo-device splash Note that `splash' is required if you intend to use screen savers or splash screen. !!IMPORTANT!! Due to sloppy programming of mine, the pseudo-device splash is ALWAYS needed for the syscons driver at the moment. The problem will be fixed soon .(12 Jan. 99) If you are pcvt user, controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 #device psm0at isa? tty irq 12 device vt0 at isa? tty 2. The following options for syscons are replaced by new ones. SC_ALT_SEQACCESS-> VGA_ALT_SEQACCESS SLOW_VGA-> VGA_SLOW_IOACCESS 3. The following flags for syscons are no longer available. 0x08Force detection of keyboard. 0x10Old-style (XT) keyboard support. 0x20Don't reset keyboard. Use corresponding new flags for atkbd instead. 0x01Don't install the keyboard driver if no keyboard is found, else we always assume a keyboard. 0x02Don't reset keyboard. 0x04XT keyboard support. 4. You must recompile screen saver modules and the vesa module in /sys/modules, as well as kbdcontrol and vidcontrol in /usr/src/usr.sbin. If you regularly do `make world', you will be in good shape. If you don't do it often, this may be a good opportunity. II) Splash Screen A splash screen module has been added. See /sys/modules/splash. This version has rather limited capabilities: it can handle W*ndows 256 color BMP file only (other color depth probably won't work); the size of the image must be 320x200 or less. In order to see splash image when your kernel loads, do the following: Make sure the following line is added to your kernel configuration file and rebuild a new kernel. pseudo-device splash Copy your favorite W*ndows BMP file to somewhere the boot loader can see. When the boot loader starts, load kernel, splash imag
Re: NFS problem found - pleaes try this patch.
On Tue, Jan 19, 1999 at 01:01:34PM +0200, Sheldon Hearn wrote: [...] > > But there's still something wrong: When shutting down the server > > it still sometimes panics in vinvalbuf() complaining 'bout dirty > > pages. > > I'm not sure this has anything to do with NFS. I got this after last > night's fresh world and kernel install. The vinvalbuf message occured > after the ``syncing disks ...done'' message but before the ``Rebooting'' > message and. Then why is the panic on the server triggered by the vi SEGV? No vi SEGV -> server goes down normally; vi SEGV -> server panics on shutdown. > However, I cannot reproduce the message since that reboot, with or > without NFS activity. It is somewhat tricky. There's actually only one file I've got that causes vi to SEGV (and the server to panic on shutdown). I'll have to look into vi source to find out how the vi.recover file is created. Maybe some locking is involvled, too. Bjoern -- (sig_t*)NULL To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: NFS problem found - pleaes try this patch.
On Mon, Jan 18, 1999 at 10:05:50AM -0500, Luoqi Chen wrote: > The check is correct and should be there, the B_CACHE bit was cleared because > I made a mistake when setting the valid bit in the vm page. [...] > Note the calculation of ev, the original code was a round-up and I changed it > to round-down in my -r1.188 commit (I thought it was a bug in the original > code, but it was actually me who didn't understand the nfs code well enough). The patch seems to solve the problem as nfs behaves as it did prior to -r1.188. Thanks. But there's still something wrong: When shutting down the server it still sometimes panics in vinvalbuf() complaining 'bout dirty pages. On the client side vi dies of SEGV (edited file and /var/tmp/vi.recover on nfs fs) generating a wrong sized recover file. After that the server panics on shutdown. Without triggering the bug it shuts down gracefully. I'll try to receipe a situation for easily reproducing this. Bjoern -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBLOSI$ P+++(-) L+++(-) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: NFS woes: getting worse?
On Thu, Jan 14, 1999 at 08:03:46PM -0800, Chris Timmons wrote: > > I have duplicated on two pairs of machines a case whereby you have two > -current machines as of ~20:00 UTC 1999/Jan/14 which cannot interoperate > via NFS without corruption. > [...] > 18034 bytes read by the NFS client, 19229 bytes read on the local system! > > The file shown in the kdump output above is "Makefile" (see path below), > and we can see that it's true size is 19229. This is just one instance of > the problem. [...] Same problems here -- or even worse. Running -current on a NFS-server and several diskless clients attached to it (I like the silence at my desk), I get truncated files and NFS-writes with a lot of ^...@^@^...@^@^@ and some other garbage in it. The ^...@^@^...@^@^...@-pages stuff seems to be reported as a kernel bug already. I tried several options: NFS-3/2, tcp/udp, hard/soft, (w/o) intr -- without success. At the time (src-cur.3702.gz/~12th Jan) even vi is not usable at all on the client side with a couple of files. Being very busy at the moment I don't have time to track this down myself. Bjoern To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
