Re: XFree86 4.3 and Cyrillic Xkb layouts
Andrei Popov [EMAIL PROTECTED] writes: There's something fishy with Xkb in 4.3: whenever I try cyrillic layouts (e.g. ru, bg, ua, etc.), I cannot type a thing (and yes, cyrillic fonts are listed in font path). Running xev shows that event is there. Anyone seen the same behavior/knows what may be the cause? Please try setting the locale: export LC_CTYPE=ru_RU.KOI8-R or setenv LC_CTYPE ru_RU.KOI8-R -- Alexander Pohoyda [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still have a FIFO / named pipe problem?
On Sat, 15 Feb 2003 23:56:50 +0100 Simon 'corecode' Schubert [EMAIL PROTECTED] wrote: Lately Bruce Evans wrote: This change makes such opens bogusly time out after 1 second (unless there is already a writer). There seems to be a race in fifo_open(): opens for read don't terminate the wait if the reader goes away before the opener looks. It is not clear if sendmail is affected by this race or one of its own. Untested fix for this and rev.1.79, and for a similar race in blocking opens of named pipes for reading: fixes issues with apsfilter manual duplexing for me. could somebody please commit this patch? ping phk Bye, Alexander. -- There's no place like ~ http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still have a FIFO / named pipe problem?
In message [EMAIL PROTECTED], Alexander Leiding er writes: On Sat, 15 Feb 2003 23:56:50 +0100 Simon 'corecode' Schubert [EMAIL PROTECTED] wrote: Lately Bruce Evans wrote: This change makes such opens bogusly time out after 1 second (unless there is already a writer). There seems to be a race in fifo_open(): opens for read don't terminate the wait if the reader goes away before the opener looks. It is not clear if sendmail is affected by this race or one of its own. Untested fix for this and rev.1.79, and for a similar race in blocking opens of named pipes for reading: fixes issues with apsfilter manual duplexing for me. could somebody please commit this patch? ping phk I'm sort of expecting Bruce to commit his own patch ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
/usr/src5/sys/kern/kern_lock.c:243: could sleep with buf queue lock locked from /usr/src5/sys/kern/vfs_bio.c:2104
I'n not shure if this is still the place to drop these???
I haven't seen may off these lately on the list...
Found in my dmesg of yesterday, system is now 5 days up:
/usr/src5/sys/kern/kern_lock.c:243: could sleep with buf queue lock locked from
/usr/src5/sys/kern/vfs_bio.c:2104
freebee# uname -a
FreeBSD freebee.digiware.nl 5.0-CURRENT FreeBSD 5.0-CURRENT #4: Sat Mar 1 17:50:16
CET 2003 [EMAIL PROTECTED]:/mnt2/obj/usr/src5/sys/GENERIC i386
I'll install yesterdays kernel and run that to see if it reoccurs.
--WjW
èR{.nÇ+·¬zwfj)m¢f£¢·hkyàRàÂ+aº{.nÇ+·ç±×.®·§¶)í
æèw* ¶¦zË
Re: XFree86 4.3 and Cyrillic Xkb layouts
Please try setting the locale: export LC_CTYPE=ru_RU.KOI8-R or setenv LC_CTYPE ru_RU.KOI8-R Yow! Worked -- which is a bit strange: with 4.2 nothing like this was necessary... -- Alexander Pohoyda [EMAIL PROTECTED] Thanks, -- Andrei __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still have a FIFO / named pipe problem?
On Sun, 9 Mar 2003, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Alexander Leiding er writes: On Sat, 15 Feb 2003 23:56:50 +0100 Simon 'corecode' Schubert [EMAIL PROTECTED] wrote: Lately Bruce Evans wrote: This change makes such opens bogusly time out after 1 second (unless there is already a writer). There seems to be a race in fifo_open(): opens for read don't terminate the wait if the reader goes away before the opener looks. It is not clear if sendmail is affected by this race or one of its own. Untested fix for this and rev.1.79, and for a similar race in blocking opens of named pipes for reading: fixes issues with apsfilter manual duplexing for me. could somebody please commit this patch? ping phk I'm sort of expecting Bruce to commit his own patch ? I'm sort of expecting Poul-Henning to report whether it fixes the sendmail problem :-). Also, since I don't normally run -current, changes to it are hard to test properly. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do we still have a FIFO / named pipe problem?
In message [EMAIL PROTECTED], Bruce Evans writes: I'm sort of expecting Bruce to commit his own patch ? I'm sort of expecting Poul-Henning to report whether it fixes the sendmail problem :-). Also, since I don't normally run -current, changes to it are hard to test properly. Ahh, my report must have gotten lost then: Yes, it works for me. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
How does a module decide what to support?
From my observations (yes, please correct me if I am wrong), that modules define what to support in their respective makefiles in the form of SRC= aaa.c bbb.c opt_*.h Where opt_*.h are automagically generated if they are not in machine@ (and the generated files are just empty files that indicate that the kernel file does not specify this option), else they are linked from [EMAIL PROTECTED] If some makefile list SRC= a.c b.c opt_inet.h opt_inet6.h and kernel config lists 'option INET' *only*, then opt_inet.h has '#define INET 1' in it and opt_inet6.h is empty. Is this correct? Jiawei -- Without the userland, the kernel is useless. --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How does a module decide what to support?
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: From my observations (yes, please correct me if I am wrong), that modules define what to support in their respective makefiles in the form of SRC= aaa.c bbb.c opt_*.h Where opt_*.h are automagically generated if they are not in machine@ (and the generated files are just empty files that indicate that the kernel file does not specify this option), else they are linked from [EMAIL PROTECTED] If some makefile list SRC= a.c b.c opt_inet.h opt_inet6.h and kernel config lists 'option INET' *only*, then opt_inet.h has '#define INET 1' in it and opt_inet6.h is empty. Is this correct? Yes, I believe so. This is why module makefiles should explicitly create the opt_* files with the #define set, so the module supports all options. See the recent commits I did to the if_tun module, for example (thanks for pointing it out). -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Warning: driver mistake
Starting today I noticed this warning at bootup: WARNING: Driver mistake: make_dev(console) called before SI_SUB_DRIVERS Is there more info I should supply? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Warning: driver mistake
In message [EMAIL PROTECTED], walt writes: Starting today I noticed this warning at bootup: WARNING: Driver mistake: make_dev(console) called before SI_SUB_DRIVERS Is there more info I should supply? Ooops. No, that is plenty. I'll fix it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ATA CS5530 (cyrix) driver panic (ata_cyrix_setmode())
Hi, the current -current ata driver panics at boot
when using the CS5530 (National GX1, ex-cyrix).
This driver worked in the past on -current, likely
up until the major rework that appears to be
underway as of 20-Feb-2003 (that is, the creation
of ata-chipset.c, etc.)
Routine ata_cyrix_setmode() in ata-chipset.c
appears to be assuming that channel-dma has a
valid pointer to a struct ata_dma_funcs, and
that channel-r_bmio is a valid bus resource
id. This is not the case, both channel-dma and
channel-r_bmio (bus master I/O supported) are
0, which will result in panics. The first use (and
panic) occurs at:
atadev-channel-dma-alignment = 16;
ata_cyrix_setmode+0x8b: movl $0x10,0x20(%eax)
on my build (%eax is 0).
These panics occur regardless of the setting of
TUNABLE_INIT() ata_dma.
Routine ata_dmainit(), which mallocs the struct
ata_dma_funcs is (likely correctly) never called.
If required due to DMA support, it is allocated
during the driver probe via ctlr-dmainit(ch)
in ata_pcisub_probe() in ata-pci.c.
To make the system come up, I replaced
ata_cyrix_setmode() with the following:
static void
ata_cyrix_setmode(struct ata_device *atadev, int mode)
{
int error;
mode = ata_limit_mode(atadev, mode, ATA_UDMA2);
error = ata_command(atadev, ATA_C_SETFEATURES, 0, mode,
ATA_C_F_SETXFER, ATA_WAIT_READY);
if (bootverbose)
ata_prtdev(atadev, %s setting %s on Cyrix chip\n,
(error) ? failed : success, ata_mode2str(mode));
atadev-mode = mode;
}
This seems to work, I am using the system without
apparent problems, but it is strictly a by guess
and by god fix - I haven't studied or understood
the whole new ata driver scaffolding.
What is (a) correct fix? Is there a better and
more complete thing envisoned? Is there a tunable
I don't understand? Or a feature flag? Is the
current cyrix code in transit and untested?
Should ata_dma or r_bmio be checked in the
setmode codepath? Can I help assure this is fixed
right? I can at least test, if need be.
As a minor question, is the style to allocate
malloced data structures (such as ata_dma_funcs)
in the probe code instead of attach code, as seems
to be the intent in this driver, and leave permanent
bus resource allocation until the attach? (in this
case the ata_pcisub_probe() never reaches the
allocation code because it checks and finds r_bmio
is 0).
- bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ATA CS5530 (cyrix) driver panic (ata_cyrix_setmode())
It seems Bruce R. Montague wrote:
I'll look into it, thanks for reporting!
Hi, the current -current ata driver panics at boot
when using the CS5530 (National GX1, ex-cyrix).
This driver worked in the past on -current, likely
up until the major rework that appears to be
underway as of 20-Feb-2003 (that is, the creation
of ata-chipset.c, etc.)
Routine ata_cyrix_setmode() in ata-chipset.c
appears to be assuming that channel-dma has a
valid pointer to a struct ata_dma_funcs, and
that channel-r_bmio is a valid bus resource
id. This is not the case, both channel-dma and
channel-r_bmio (bus master I/O supported) are
0, which will result in panics. The first use (and
panic) occurs at:
atadev-channel-dma-alignment = 16;
ata_cyrix_setmode+0x8b: movl $0x10,0x20(%eax)
on my build (%eax is 0).
These panics occur regardless of the setting of
TUNABLE_INIT() ata_dma.
Routine ata_dmainit(), which mallocs the struct
ata_dma_funcs is (likely correctly) never called.
If required due to DMA support, it is allocated
during the driver probe via ctlr-dmainit(ch)
in ata_pcisub_probe() in ata-pci.c.
To make the system come up, I replaced
ata_cyrix_setmode() with the following:
static void
ata_cyrix_setmode(struct ata_device *atadev, int mode)
{
int error;
mode = ata_limit_mode(atadev, mode, ATA_UDMA2);
error = ata_command(atadev, ATA_C_SETFEATURES, 0, mode,
ATA_C_F_SETXFER, ATA_WAIT_READY);
if (bootverbose)
ata_prtdev(atadev, %s setting %s on Cyrix chip\n,
(error) ? failed : success, ata_mode2str(mode));
atadev-mode = mode;
}
This seems to work, I am using the system without
apparent problems, but it is strictly a by guess
and by god fix - I haven't studied or understood
the whole new ata driver scaffolding.
What is (a) correct fix? Is there a better and
more complete thing envisoned? Is there a tunable
I don't understand? Or a feature flag? Is the
current cyrix code in transit and untested?
Should ata_dma or r_bmio be checked in the
setmode codepath? Can I help assure this is fixed
right? I can at least test, if need be.
As a minor question, is the style to allocate
malloced data structures (such as ata_dma_funcs)
in the probe code instead of attach code, as seems
to be the intent in this driver, and leave permanent
bus resource allocation until the attach? (in this
case the ata_pcisub_probe() never reaches the
allocation code because it checks and finds r_bmio
is 0).
- bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ATA CS5530 (cyrix) driver panic (ata_cyrix_setmode())
It seems Bruce R. Montague wrote: Routine ata_cyrix_setmode() in ata-chipset.c appears to be assuming that channel-dma has a valid pointer to a struct ata_dma_funcs, and that channel-r_bmio is a valid bus resource id. This is not the case, both channel-dma and channel-r_bmio (bus master I/O supported) are 0, which will result in panics. The first use (and panic) occurs at: OK, just looked a bit more closely at this, if the r_bmio address is not set in the chipset registers something is wrong as these are used to setup PIO and DMA timings in the chipset. So if your BIOS doesn't set the bmio address, there is *no way* I can set any modes on your HW, ie you need to use whatever mode the BIOS has setup for you. Could you please dump the pci reg 0x20 (with pciconf) and verify that it is endeed 0 ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Warning: driver mistake
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], walt writes: Starting today I noticed this warning at bootup: WARNING: Driver mistake: make_dev(console) called before SI_SUB_DRIVERS Is there more info I should supply? Ooops. No, that is plenty. I'll fix it. Yes, fixed now. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA CS5530 (cyrix) driver panic (ata_cyrix_setmode())
Hi, re the ata driver and CS5530, Soren Schmidt asked: Could you please dump the pci reg 0x20 (with pciconf) and verify that it is endeed 0 ? Ok (it's _not_ 0): - geode# pciconf -r pci0:18:2 0x20 fc01 geode# pciconf -r pci0:18:2 32 fc01 - Is this 0x20 on F2, F2BAR4? Is it supposed to be 0, not the I/O mapped Bus Master IDE Registers...? I have a 5530 manual (although I'm uncertain if all the 5530s really look the same in all ways...). Bits 31:4 are the bus master IDE base address (0xfc0). The RO 1 indicates a 16-byte I/O range. I am using a reasonably recent National Semiconductor Centaurus 2 development board. My understanding is that this is National's current reference development platform. It uses National's XpressROM BIOS, intended for use with the GX1 and CS5530. This BIOS seems to evolve rather rapidly, it doesn't look like the BIOS is very recent. The BIOS screen says: -- Rev: v2.22 B Built: 07/01/2002 07:54:38 CPU: GX1 8.2 @334 Mhz PCI:33Mhz Multiplier:10x 5530A Rev:B1 Memory:192512k @83 MHz CAS:3 SDRAM Divisor:4 Shift SDCLK: 2.0 Floppy A:1.44M Drive 80:41174MB COM1:03F8 LPT1:0378 XpressROM V3.2.5 RTC:Present COM2:02F8VSA:0202 USB:EnabledVBIOS:040D PM:Disabled CPU Voltage 2.20 9211: B1/C1 -- I'll try to track down r_bmio life. The same hardware runs the /boot/kernel.last_good/kernel FreeBSD 5.0-CURRENT #3: Mon Jan 20 ... 2003 fine, there are no obvious driver problems. Other than the expected -current deltas, the only other difference between the two systems that I know of is that the older system is not using the TSC clock. I'll see if that changes things. They are basically both GENERIC. Other misc info: -- geode# dmesg | egrep 5530 atapci0: Cyrix 5530 ATA33 controller port 0xfc00-0xfc0f at device 18.2 on pci0 -- geode# pciconf -l [EMAIL PROTECTED]:0:0:class=0x06 card=0x chip=0x00011078 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:13:0: class=0x02 card=0x0020100b chip=0x0020100b rev=0x00 hdr=0x00 [EMAIL PROTECTED]:18:0:class=0x060100 card=0x chip=0x01001078 rev=0x30 hdr=0x00 [EMAIL PROTECTED]:18:1:class=0x068000 card=0x chip=0x01011078 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:18:2: class=0x010180 card=0x chip=0x01021078 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:18:3:class=0x040100 card=0x69b61078 chip=0x01031078 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:18:4:class=0x03 card=0x584d1078 chip=0x01041078 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:19:0:class=0x0c0310 card=0xa0f80e11 chip=0xa0f80e11 rev=0x06 hdr=0x00 - FreeBSD geode 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Sun Mar 9 06:47:09 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC i386 - bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA CS5530 (cyrix) driver panic (ata_cyrix_setmode())
Hi I didn;t see the original problem, just the reply.. Just one thing to be aware of when using the 5530. I used a 5530 on the Interjet-II. It has a terrible bug where it fails if the data being transferred to/from the disk by DMA is not alligned on a 16 byte boundary. programs such as newfs and fsck would sometimes make this happen when accessing a raw drive. This was not in the manual at that time, and I don't know if Soeren has the code to check for this. Such transffers must be done using PIO. This may be a red-herring.. (the symptom was that it would never complete the transfer and would hang the bus.) On Sun, 9 Mar 2003, Bruce R. Montague wrote: Hi, re the ata driver and CS5530, Soren Schmidt asked: Could you please dump the pci reg 0x20 (with pciconf) and verify that it is endeed 0 ? Ok (it's _not_ 0): - geode# pciconf -r pci0:18:2 0x20 fc01 geode# pciconf -r pci0:18:2 32 fc01 - Is this 0x20 on F2, F2BAR4? Is it supposed to be 0, not the I/O mapped Bus Master IDE Registers...? I have a 5530 manual (although I'm uncertain if all the 5530s really look the same in all ways...). Bits 31:4 are the bus master IDE base address (0xfc0). The RO 1 indicates a 16-byte I/O range. I am using a reasonably recent National Semiconductor Centaurus 2 development board. My understanding is that this is National's current reference development platform. It uses National's XpressROM BIOS, intended for use with the GX1 and CS5530. This BIOS seems to evolve rather rapidly, it doesn't look like the BIOS is very recent. The BIOS screen says: -- Rev: v2.22 B Built: 07/01/2002 07:54:38 CPU: GX1 8.2 @334 Mhz PCI:33Mhz Multiplier:10x 5530A Rev:B1 Memory:192512k @83 MHz CAS:3 SDRAM Divisor:4 Shift SDCLK: 2.0 Floppy A:1.44M Drive 80:41174MB COM1:03F8 LPT1:0378 XpressROM V3.2.5 RTC:Present COM2:02F8VSA:0202 USB:EnabledVBIOS:040D PM:Disabled CPU Voltage 2.20 9211: B1/C1 -- I'll try to track down r_bmio life. The same hardware runs the /boot/kernel.last_good/kernel FreeBSD 5.0-CURRENT #3: Mon Jan 20 ... 2003 fine, there are no obvious driver problems. Other than the expected -current deltas, the only other difference between the two systems that I know of is that the older system is not using the TSC clock. I'll see if that changes things. They are basically both GENERIC. Other misc info: -- geode# dmesg | egrep 5530 atapci0: Cyrix 5530 ATA33 controller port 0xfc00-0xfc0f at device 18.2 on pci0 -- geode# pciconf -l [EMAIL PROTECTED]:0:0:class=0x06 card=0x chip=0x00011078 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:13:0: class=0x02 card=0x0020100b chip=0x0020100b rev=0x00 hdr=0x00 [EMAIL PROTECTED]:18:0:class=0x060100 card=0x chip=0x01001078 rev=0x30 hdr=0x00 [EMAIL PROTECTED]:18:1:class=0x068000 card=0x chip=0x01011078 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:18:2: class=0x010180 card=0x chip=0x01021078 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:18:3:class=0x040100 card=0x69b61078 chip=0x01031078 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:18:4:class=0x03 card=0x584d1078 chip=0x01041078 rev=0x00 hdr=0x00 [EMAIL PROTECTED]:19:0:class=0x0c0310 card=0xa0f80e11 chip=0xa0f80e11 rev=0x06 hdr=0x00 - FreeBSD geode 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Sun Mar 9 06:47:09 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC i386 - bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fix for rtc, vmware modules and post-500104 -current
At 7:37 PM +0100 3/5/03, Marcin CIEÂLAK wrote: See the patches enclosed to emulators/rtc and emulators/vmware2 ports. Tested only for -current with: #define __FreeBSD_version 500104 This does get it so the vmware module will load correctly at system startup, and I think the result is basically working. There is still a complaint at system-startup about driver vmmon used unreserved major device number 200 but I don't know what the proper fix for that is. Unfortunately my X11-configuration is currently screwed up, so I can't really tell if vmware2 is working right. I can tell that these updates do get it working better. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- === lib/libpam/modules/pam_opieaccess cc1: warnings being treated as errors /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c: In function `pam_sm_authenticate': /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c:70: warning: passing arg 2 of `opielookup' discards qualifiers from pointer target type /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c:80: warning: passing arg 1 of `opieaccessfile' discards qualifiers from pointer target type *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess. *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam/modules. *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA CS5530 (cyrix) driver panic (ata_cyrix_setmode())
Hi, regarding the CS5530 driver initialization
(ata cyrix) panic, the problem of channel dma
and r_bmio fields being 0 is due to the hardware
PCI config cmd register not having the expected
value. In ata-pci.c / ata_pci_attach() the code
fragment:
/* is busmastering supported ? */
if ((cmd (PCIM_CMD_PORTEN | PCIM_CMD_BUSMASTEREN)) ==
(PCIM_CMD_PORTEN | PCIM_CMD_BUSMASTEREN)) {
failed because cmd was 0x01 instead of 0x05 (the
PORTEN | BUSMASTEREN is 0x05). The 5530 datasheet
(well, SC1200 datasheet) says cmd bit 2 (Bus
Master) must be set to 1... why isnt it?
Changing the code at the top of ata_pci_attach()
from:
cmd = pci_read_config(dev, PCIR_COMMAND, 2);
to:
pci_write_config(dev, PCIR_COMMAND, 0x05, 2 );
cmd = pci_read_config(dev, PCIR_COMMAND, 2);
causes the driver to not to panic on ata_cyrix_setmode();
it appears to complete both the probe and attach boot
operations.
Now the driver is dying (the system is hanging)
at the first attempt to use dma, that is, after
the first call to ata_dmastart(). The
ata_dmastart() completes ok, but the system
immediatly hangs (it appears up, but spinning at
interrupt level or somesuch, I can sometimes break
into ddb or scroll the console a bit before things
totally freeze). I'll see what else I can find.
Replacing use of the TSC by the 8254 appears to
have nothing to do with this problem (although
it's necessary for anything even close to accurate
sleep'ing).
The older version of -current doesn't have this
problem. I'll see if I can find why. It's the
same hardware, I can boot either system and the
old ata driver works ok. I'm debugging the new
-current under the old working -current. Did
something change in the PCI initialization that's
likely a cause?
- bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ATA CS5530 (cyrix) driver panic (ata_cyrix_setmode())
It seems Bruce R. Montague wrote:
/* is busmastering supported ? */
if ((cmd (PCIM_CMD_PORTEN | PCIM_CMD_BUSMASTEREN)) ==
(PCIM_CMD_PORTEN | PCIM_CMD_BUSMASTEREN)) {
failed because cmd was 0x01 instead of 0x05 (the
PORTEN | BUSMASTEREN is 0x05). The 5530 datasheet
(well, SC1200 datasheet) says cmd bit 2 (Bus
Master) must be set to 1... why isnt it?
Changing the code at the top of ata_pci_attach()
from:
cmd = pci_read_config(dev, PCIR_COMMAND, 2);
to:
pci_write_config(dev, PCIR_COMMAND, 0x05, 2 );
cmd = pci_read_config(dev, PCIR_COMMAND, 2);
causes the driver to not to panic on ata_cyrix_setmode();
it appears to complete both the probe and attach boot
operations.
Now the driver is dying (the system is hanging)
at the first attempt to use dma, that is, after
the first call to ata_dmastart(). The
ata_dmastart() completes ok, but the system
immediatly hangs (it appears up, but spinning at
interrupt level or somesuch, I can sometimes break
into ddb or scroll the console a bit before things
totally freeze). I'll see what else I can find.
Thats probably because the HW hasn't been setup to be able to
do busmastering.
The older version of -current doesn't have this
problem. I'll see if I can find why. It's the
same hardware, I can boot either system and the
old ata driver works ok. I'm debugging the new
-current under the old working -current. Did
something change in the PCI initialization that's
likely a cause?
Setting up busmastering and the enabled bit is a BIOS thing, I
only test for it being enabled and that has not changed in the
ATA driver for a lg time.
Now the driver fails to survive a missing DMA bit, and thats a
bug alright, the following patch should solve that:
Index: ata-chipset.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v
retrieving revision 1.11
diff -u -r1.11 ata-chipset.c
--- ata-chipset.c 3 Mar 2003 11:51:08 - 1.11
+++ ata-chipset.c 9 Mar 2003 21:58:52 -
@@ -480,7 +480,10 @@
if (ata_default_interrupt(dev))
return ENXIO;
-ctlr-setmode = ata_cyrix_setmode;
+if (ctlr-r_bmio)
+ ctlr-setmode = ata_cyrix_setmode;
+else
+ ctlr-setmode = ata_generic_setmode;
return 0;
}
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
CFR: add widely accepted _ISOC99_SOURCE
Many programs (from ports too) defines _ISOC99_SOURCE to get C99 functions, but we don't sense this define currently. Here is the fix for review: --- cdefs.h.bak Wed Oct 23 05:04:06 2002 +++ cdefs.h Mon Mar 10 09:11:01 2003 @@ -360,6 +360,9 @@ #define__POSIX_VISIBLE 198808 #define__ISO_C_VISIBLE 0 #endif /* _POSIX_C_SOURCE */ +#ifdef _ISOC99_SOURCE +#define__ISO_C_VISIBLE 1999 +#endif #else /*- * Deal with _ANSI_SOURCE: @@ -378,7 +381,7 @@ #define__XSI_VISIBLE 0 #define__BSD_VISIBLE 0 #define__ISO_C_VISIBLE 1990 -#elif defined(_C99_SOURCE) /* Localism to specify strict C99 env. */ +#elif defined(_ISOC99_SOURCE) /* Strict C99 env. */ #define__POSIX_VISIBLE 0 #define__XSI_VISIBLE 0 #define__BSD_VISIBLE 0 -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fix for rtc, vmware modules and post-500104 -current
In message: [EMAIL PROTECTED] Garance A Drosihn [EMAIL PROTECTED] writes: :driver vmmon used unreserved major device number 200 Actually, major numbers 200-253 are 'reserved for local use' and shouldn't be assigned autmatically. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA CS5530 (cyrix) driver panic (ata_cyrix_setmode())
Soeren Schmidt wrote: the following patch should solve that: Yes, it does, Thanks! All's well that... ends. - bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
