Re: acpi
On 2003-11-08 09:52 +0300, Konstantin Volevatch wrote: Why acpi.ko module missed after latest CVS update? Read UPDATING, or check the last few days worth of -current archives. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Periodic Crontabs
i seem to get random connection attempts to ports 111 and 16001 Connection attempt to TCP 127.0.0.1:16001 from 127.0.0.1:49838 flags:0x02 Connection attempt to TCP 127.0.0.1:111 from 127.0.0.1:49856 flags:0x02 was wondering what causing me from connecting to myself ? i dont use RPC and i dont use whatever 16001 uses the only ports opened are the ones opened by MSN,AIM,IRC so can someone tell me what trys to connect to those ports ive looked in the /etc/periodic/security no go ?? -chris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
SMP in GENERIC !
Hello, this is just to send a big bravo to all involved : a new GENERIC kernel is running my old BP6 as an SMP machine : multi% uname -a FreeBSD multi 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sat Nov 8 02:40:50 CET 2003 [EMAIL PROTECTED]:/files3/obj/files3/src/sys/GENERIC i386 multi% sysctl -a | grep cpu kern.threads.virtual_cpu: 2 kern.ccpu: 1948 kern.smp.cpus: 2 hw.ncpu: 2 machdep.cpu_idle_hlt: 1 machdep.hlt_cpus: 0 multi% (and ACPI is quite broken on this machine) and now, the same on the bi-Xeon machine at work ! TfH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the PS/2 mouse problem
Bruce Evans wrote:
On Fri, 7 Nov 2003, Morten Johansen wrote:
Morten Johansen wrote:
Scott Long wrote:
One thought that I had was to make psmintr() be INTR_FAST. I need to
stare at the code some more to fully understand it, but it looks like it
wouldn't be all that hard to do. Basically just use the interrupt
handler
to pull all of the data out of the hardware and into a ring buffer in
memory, and then a fast taskqueue to process that ring buffer. It would
at least answer the question of whether the observed problems are due to
ithread latency. And if done right, no locks would be needed in
psmintr().
However, it is usually easier to use a lock even if not strictly necessary.
psm as currently structured uses the technique of calling psmintr() from
the timeout handler. This requires a lock. If this were not done, then
the timeout routine would probably need to access hardware using scattered
i/o instructions, and these would need locks (to prevent them competing
with i/o instructions in psmintr()). Putting all the hardware accesses
in the fast interrupt handler is simpler. The sio driver uses this technique
but doesn't manage to put _all_ the i/o's in the interrupt handler, so it
ends up having to lock out the interrupt handler all over the place.
Ring buffers can be self-locking using delicate atomic instructions, but
they are easier to implement using locks.
I can reproduce the problem consistently on my machine, by moving the
mouse around, while executing e.g this command in a xterm:
dd if=/dev/zero of=test bs=32768 count=4000; sync; sync; sync
when the sync'ing sets in the mouse attacks.
It is very likely due to interrupt latency.
I'd be happy to test any clever patches.
Wow. You are completly right!
By using a MTX_SPIN mutex instead, and marking the interrupt handler
INTR_MPSAFE | INTR_FAST, my problem goes away.
I am no longer able to reproduce the mouse attack.
I have not noticed any side-effects of this. Could there be any?
I will file a PR with an updated patch, unless you think it's a better
idea to rearrange the driver.
Probably the locking could be done better anyway.
Er, psmintr() needs large changes to become a fast interrupt handler. it
does many things that may not be done by a fast interrupt handler, starting
with the first statement in it:
/* read until there is nothing to read */
while((c = read_aux_data_no_wait(sc-kbdc)) != -1) {
This calls into the keyboard driver, which is not written to support any
fast interrupt handlers.
Actually, it calls the keyboard controller driver, not the keyboard
driver.
In general, fast interrupt handlers may not call
any functions, since the any function doesn't know that it is called in
fast interrupt handler context and may do things that may not be done in
fast interrupt handler context. As it happens, read_aux_data_no_wait()
does the following bad things:
- it accesses private keyboard data. All data that is accessed by a fast
interrupt handler must be locked by a common lock or use self-locking
accesses. Data in another subsystem can't reasonably be locked by this
(although the keyboard subsystem is close to psm, you don't want to
export the complexities of psmintr()'s locking to the keyboard subsystem).
- it calls other functions. The closure of all these calls must be examined
and made fast-interrupt-handler safe before this is safe. The lowest level
will resolve to something like inb(PSMPORT) and this alone is obviously
safe provided PSMPORT is only accessed in the interrupt handler or is
otherwise locked. (Perhaps the private keyboard data is actually private
psm data that mainly points to PSMPORT. Then there is no problem with the
data accesses. But the function calls make it unclear who owns the data.)
The problem here is that the keyboard controller driver tries to be too
smart. If it detects that the hardware FIFO is full, it'll drain it into
a per-softc, per-function ring buffer. So having psm(4) just directly
read the hardware is insufficient in this scheme.
- it sometimes calls the DELAY() function, which is not permitted in fast
interrupt handlers since apart from locking issues, fast interrupt handlers
are not permitted to busy-wait.
Again, the keyboard controller driver is too smart for its own good. To
summarize:
read_aux_data_no_wait()
{
Does softc-aux ring buffer contain data?
return ring buffer data
Check the status register
Is the keyboard fifo full?
DELAY(7us)
read keyboard fifo into softc-kbd ring buffer
Check the status register
Is the aux fifo full?
DELAY(7us)
return aux fifo data
}
So you can wind up stalling for 14us in there, presumably because you
cannot read the status and data registers back-to-back without a delay.
I don't have the atkbd spec handy so I'm not sure how to optimize this.
Do you really need to check the status register
Re: Periodic Crontabs
On Sat, Nov 08, 2003 at 12:00:53AM -, [EMAIL PROTECTED] wrote: i seem to get random connection attempts to ports 111 and 16001 Connection attempt to TCP 127.0.0.1:16001 from 127.0.0.1:49838 flags:0x02 Connection attempt to TCP 127.0.0.1:111 from 127.0.0.1:49856 flags:0x02 first of all, -current is hardly the place to ask such a question (neither is -security, btw). now, a simple google search for 'port 16001' does wonders. it will tell you that port 16001 is the esd default port which is normal for systems running gnome. as for 111, there are lots of things that make rpc calls... pick one. kind regards, t. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Radeon DRM-Problem
Hi, thanks for the hints! Well, I didn't set anything special in XF86Config; I'll put in my XF86Config and attach an XFree86.0.log -- Section ServerLayout Identifier Layout0 Screen 0 Screen0 0 0 InputDeviceKeyboard0 CoreKeyboard InputDeviceMouse0 CorePointer EndSection Section Files RgbPath /usr/X11R6/lib/X11/rgb ModulePath /usr/X11R6/lib/modules FontPath /usr/X11R6/lib/X11/fonts/misc/ FontPath /usr/X11R6/lib/X11/fonts/Speedo/ FontPath /usr/X11R6/lib/X11/fonts/Type1/ FontPath /usr/X11R6/lib/X11/fonts/75dpi/ FontPath /usr/X11R6/lib/X11/fonts/100dpi/ FontPath /usr/X11R6/lib/X11/fonts/URW/ EndSection Section Module Load freetype # Load xtt Load extmod Load glx Load dri Load dbe Load record Load xtrap Load type1 Load speedo EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol SysMouse Option Device /dev/sysmouse Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbModel pc105 Option XkbLayout de EndSection Section Monitor Identifier Monitor0 VendorName MAX ModelNameBelinea101720 Option DPMS HorizSync31.5 - 64.3 VertRefresh 50.0 - 70.0 EndSection Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz ### [arg]: arg optional #Option NoAccel # [bool] #Option SWcursor # [bool] #Option Dac6Bit # [bool] #Option Dac8Bit # [bool] #Option ForcePCIMode # [bool] #Option CPPIOMode # [bool] #Option CPusecTimeout # i #Option AGPMode # i #Option AGPFastWrite # [bool] #Option AGPSize # i #Option RingSize # i #Option BufferSize# i #Option EnableDepthMoves # [bool] #Option EnablePageFlip# [bool] #Option NoBackBuffer # [bool] #Option PanelOff # [bool] #Option DDCMode # [bool] #Option CloneDisplay # i #Option CloneMode # [str] #Option CloneHSync# [str] #Option CloneVRefresh # [str] #Option UseFBDev # [bool] #Option VideoKey # i Identifier Card0 Driver ati VendorName ATI Technologies Inc BoardName Radeon RV200 QW [Radeon 7500] BusID PCI:1:0:0 EndSection Section Screen Identifier Screen0 Device Card0 MonitorMonitor0 DefaultDepth 24 SubSection Display Depth 24 Modes1280x1024 EndSubSection EndSection -- Regards, _ralf_ XFree86.0.log_Penguin Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acd0: FAILURE - READ_BIG status=51READY,DSC,ERROR
On Thu, Nov 06, 2003 at 11:15:07PM +0100, Soren Schmidt wrote: It seems Josef Karthauser wrote: -- Start of PGP signed section. I've been getting a lot of this kind of error from my cdrom drive on a variety of disks recently: acd0: FAILURE - READ_BIG status=51READY,DSC,ERROR sensekey=ILLEGAL REQUEST error=1ILLEGAL_LENGTH acd0: FAILURE - READ_BIG status=51READY,DSC,ERROR sensekey=ILLEGAL REQUEST error=1ILLEGAL_LENGTH acd0: FAILURE - READ_BIG status=51READY,DSC,ERROR sensekey=MEDIUM ERROR error=0 Is this a bug in the new atapi code or an indication of a hardware fault that's just developed? Acutally its fallout from the hacs I had to put into atapi-cd.c to work around deficiencies in GEOM. I might have a better way now, but it needs more testing. Ah, ok. So it's not a hardware problem. That's good to know. Joe p.s. are there any plans to fix power cycling of ide harddrives with an acpi suspend? I can get my machine to suspend, but the power runs down because the hard drive is still spinning. -S?ren -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = pgp0.pgp Description: PGP signature
rpc.lockd core dumped
Hi :) Are they any know issues with rpc.lockd under -CURRENT. I had a look at the gnats database and did not find anything related. I'm asking this because I have a lot of: kernel: pid 70065 (rpc.lockd), uid 0: exited on signal 11 (core dumped) Any idea ? I would be pleased to send more information but I didn't see where to find more debuging options for rpc.lockd. 5.1-CURRENT #0: Tue Nov 4 01:44:35 CET 2003 [EMAIL PROTECTED]:/usr/ obj/usr/src/sys/KERNSRV01 i386 Thanks in advance. -- Antoine Jacoutot [EMAIL PROTECTED] http://www.lphp.org PGP/GnuPG key: http://www.lphp.org/ressources/ajacoutot.asc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acd0: FAILURE - READ_BIG status=51READY,DSC,ERROR
It seems Josef Karthauser wrote: p.s. are there any plans to fix power cycling of ide harddrives with an acpi suspend? I can get my machine to suspend, but the power runs down because the hard drive is still spinning. Hmm, on the laptops I have thats done automatically, but that seems not to be the case always then, hmmm... I did have a plan to detach all devices on suspend, and attach them again on resume, but the upper layers dont like that... I'll think a bit more about it... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd core dumped
On Sat, 8 Nov 2003, Antoine Jacoutot wrote: AJHi :) AJ AJAre they any know issues with rpc.lockd under -CURRENT. AJI had a look at the gnats database and did not find anything related. AJI'm asking this because I have a lot of: AJkernel: pid 70065 (rpc.lockd), uid 0: exited on signal 11 (core dumped) AJ AJAny idea ? AJI would be pleased to send more information but I didn't see where to find AJmore debuging options for rpc.lockd. AJ AJ5.1-CURRENT #0: Tue Nov 4 01:44:35 CET 2003 [EMAIL PROTECTED]:/usr/ AJobj/usr/src/sys/KERNSRV01 i386 AJ AJThanks in advance. I can only say that I had a core dump under current on sparc, but the core file was unusable. Can you compile rcp.lockd with -g in CFLAGS and LDFLAGS and try to find out with gdb where it aborts? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd core dumped
On Saturday 08 November 2003 12:26, Harti Brandt wrote: I can only say that I had a core dump under current on sparc, but the core file was unusable. Can you compile rcp.lockd with -g in CFLAGS and LDFLAGS and try to find out with gdb where it aborts? Allright, as soon as I get home in 4/5 days, I'll do that. Thanks. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD-CURRENT kernel hangs on starting KDE
On Saturday 01 November 2003 23.25, you wrote: System: FreeBSD 5.1-CURRENT i386 Relevant hardware config: Mainboard : ASUS P4S533-E (SIS645DX north, SIS962/L south bridges) Memory : PC2700 512MB DDR RAM (memtest86 tested) VGA card : ATI RADEON 9000 PRO I had similar lockups with a SuperMicro P6DGH (dual PIII/850)/ATI All-in Wonder (RADEON 7200)/Intel Pro100+ which were solved by moving the Ethernet card to another IRQ (it was configured to share 11 by default, moved it to 9). The system would just stop working - mouse frozen, no keyboard response, etc. I use KDE, also. Mike Squires Thanks for your answer. I've examined my interrupt configuration and as it sees from the booting log the UDMA controller shares the IRQ with the VGA card: drm0: ATI Radeon If R250 9000 port 0xd800-0xd8ff mem 0xe780-0xe780,0xf800-0xfbff irq 11 at device 0.0 on pci1 atapci0: SiS 962 UDMA133 controller port 0xa400-0xa40f,0xa800-0xa803,0xb000-0xb007,0xb400-0xb403,0xb800-0xb807 irq 11 at device 2.5 on pci0 Ethernet uses a quite different IRQ, altough I've tried to turn off the sound card/ethernet cards built-in my mainboard (I have two ethernet cards) freeing some IRQ lines, that didn't help. I've tried to configure my VGA card and UDMA controller to allocate another IRQ through BIOS and /boot/device.hints but they always use the same IRQ line regardless any setting. Should I recompile the kernel with a new device.hints? Yesterday I synced the source tree and tested the newest kernel, which hung similarly at starting KDE. Anyway the lastest kernel, which worked (compiled on 25. of Sept.) had no any problem with the IRQ-s but since then I cannot even compile any working kernel with KDE... I'm sure there is no problem with my hardware. I would do appreciate any help. Thanks in advance, Tamás R. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: the PS/2 mouse problem
Scott Long wrote:
Bruce Evans wrote:
On Fri, 7 Nov 2003, Morten Johansen wrote:
Morten Johansen wrote:
Scott Long wrote:
One thought that I had was to make psmintr() be INTR_FAST. I need to
stare at the code some more to fully understand it, but it looks
like it
wouldn't be all that hard to do. Basically just use the interrupt
handler
to pull all of the data out of the hardware and into a ring buffer in
memory, and then a fast taskqueue to process that ring buffer. It
would
at least answer the question of whether the observed problems are
due to
ithread latency. And if done right, no locks would be needed in
psmintr().
However, it is usually easier to use a lock even if not strictly
necessary.
psm as currently structured uses the technique of calling psmintr() from
the timeout handler. This requires a lock. If this were not done, then
the timeout routine would probably need to access hardware using
scattered
i/o instructions, and these would need locks (to prevent them competing
with i/o instructions in psmintr()). Putting all the hardware accesses
in the fast interrupt handler is simpler. The sio driver uses this
technique
but doesn't manage to put _all_ the i/o's in the interrupt handler, so it
ends up having to lock out the interrupt handler all over the place.
Ring buffers can be self-locking using delicate atomic instructions, but
they are easier to implement using locks.
I can reproduce the problem consistently on my machine, by moving the
mouse around, while executing e.g this command in a xterm:
dd if=/dev/zero of=test bs=32768 count=4000; sync; sync; sync
when the sync'ing sets in the mouse attacks.
It is very likely due to interrupt latency.
I'd be happy to test any clever patches.
Wow. You are completly right!
By using a MTX_SPIN mutex instead, and marking the interrupt handler
INTR_MPSAFE | INTR_FAST, my problem goes away.
I am no longer able to reproduce the mouse attack.
I have not noticed any side-effects of this. Could there be any?
I will file a PR with an updated patch, unless you think it's a better
idea to rearrange the driver.
Probably the locking could be done better anyway.
Er, psmintr() needs large changes to become a fast interrupt handler. it
does many things that may not be done by a fast interrupt handler,
starting
with the first statement in it:
/* read until there is nothing to read */
while((c = read_aux_data_no_wait(sc-kbdc)) != -1) {
This calls into the keyboard driver, which is not written to support any
fast interrupt handlers.
Actually, it calls the keyboard controller driver, not the keyboard
driver.
In general, fast interrupt handlers may not call
any functions, since the any function doesn't know that it is called in
fast interrupt handler context and may do things that may not be done in
fast interrupt handler context. As it happens, read_aux_data_no_wait()
does the following bad things:
- it accesses private keyboard data. All data that is accessed by a fast
interrupt handler must be locked by a common lock or use self-locking
accesses. Data in another subsystem can't reasonably be locked by this
(although the keyboard subsystem is close to psm, you don't want to
export the complexities of psmintr()'s locking to the keyboard
subsystem).
- it calls other functions. The closure of all these calls must be
examined
and made fast-interrupt-handler safe before this is safe. The
lowest level
will resolve to something like inb(PSMPORT) and this alone is obviously
safe provided PSMPORT is only accessed in the interrupt handler or is
otherwise locked. (Perhaps the private keyboard data is actually
private
psm data that mainly points to PSMPORT. Then there is no problem
with the
data accesses. But the function calls make it unclear who owns the
data.)
The problem here is that the keyboard controller driver tries to be too
smart. If it detects that the hardware FIFO is full, it'll drain it into
a per-softc, per-function ring buffer. So having psm(4) just directly
read the hardware is insufficient in this scheme.
- it sometimes calls the DELAY() function, which is not permitted in fast
interrupt handlers since apart from locking issues, fast interrupt
handlers
are not permitted to busy-wait.
Again, the keyboard controller driver is too smart for its own good. To
summarize:
read_aux_data_no_wait()
{
Does softc-aux ring buffer contain data?
return ring buffer data
Check the status register
Is the keyboard fifo full?
DELAY(7us)
read keyboard fifo into softc-kbd ring buffer
Check the status register
Is the aux fifo full?
DELAY(7us)
return aux fifo data
}
So you can wind up stalling for 14us in there, presumably because you
cannot read the status and data registers back-to-back without a delay.
I don't have the atkbd spec handy so I'm not sure how to optimize this.
Do you really need to check the status register before reading the
PLEASE TEST: (laptop) autoconf at boot
Hi I'd like to present some patches to teach FreeBSD to automatically configure itself depending on what network it is started in. The system depends on rcng, so 5.x is a requirement. The setup of the various network profiles is done manually, after that, whenever the laptop boots or wakes up from suspend, it detects where it is located and configures itself accodringly. Please send all comments to freebsd-current so the discussion is not scattered over several mailing lists. How to patch: cd / fetch http://depot.fsck.ch/profile.diff patch profile.diff rm /etc/rc.d/profile.orig /usr/share/man/man8/profile.8.orig chmod 555 /etc/rc.d/profile man profile Features: - unattended startup, the laptop discovers automatically in what network it is started - read-only root partitions are supported - unintrusive. getting rid of everything profile-related is just a matter of turning it off in rc.conf and rm'ing the profile dir - everything under /etc is customizable per environment, not just the network Drawbacks: - setup is a bit tedious - autodetection after suspend/resume does not work completely yet - during normal operation, changes to /etc are not straight forward anymore. see the manpage for details. Notes: - I already have an idea about how to fix suspend/resume support. But as this involves some more changes to the system I'd like to hear a few opinions on the profile idea as a whole before starting with that. - The arguments for mdmfs/newfs are somewhat arbitrary. I just chose what seemed to work, someone with more insight might come up with a better sort of switches. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[Fwd: [Bug optimization/11741] internal compiler error at gcse.c:5318]
Maybe at a good time the next snapshot should be imported into freebsd to get this fix, too :-) Some ports (eg. mysql40, apache) are switchable to high optimization where a bug in gcse could cause invalid code which will be removed with the patch for this bug. Original Message Subject: [Bug optimization/11741] internal compiler error at gcse.c:5318 Date: 8 Nov 2003 15:24:38 - From: cvs-commit at gcc dot gnu dot org [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] --- Additional Comments From cvs-commit at gcc dot gnu dot org 2003-11-08 15:24 --- Subject: Bug 11741 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2003-11-08 15:24:33 Modified files: gcc: ChangeLog gcse.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20030926-1.c 20031108-1.c Log message: Backport from mainline PR optimization/10467 PR optimization/11741 * gcse.c (pre_insert_copy_insn): Tweak the logic for finding the appropriate set to match the code in hash_scan_insn. * gcc.dg/20030926-1.c: New test case. * gcc.dg/20031108-1.c: New test case. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.16114.2.801r2=1.16114.2.802 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcse.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.223.2.7r2=1.223.2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.2261.2.314r2=1.2261.2.315 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20030926-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=NONEr2=1.1.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20031108-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11741 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: [Bug optimization/11741] internal compiler error at gcse.c:5318]
On Sat, 08 Nov 2003 17:08:10 + Jens Rehsack [EMAIL PROTECTED] wrote: Maybe at a good time the next snapshot should be imported into freebsd to get this fix, too :-) Some ports (eg. mysql40, apache) are switchable to high optimization where a bug in gcse could cause invalid code which will be removed with the patch for this bug. Sure, I'll let the system to settle after last snapshot as it is still not clear whether or not it has broken anything. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3C940 / Asus P4P800 gigabit LAN driver
On Thu, Nov 06, 2003 at 09:52:27PM -0800, Matthew Dillon wrote: :I just tried Jung-uk Kim's driver on -stable and sofar it works OK: : ... and I just ported it to DragonFly and it works fine there too with an ASUS K8V Motherboard. Kudos! Good to hear that ;) Jung-uk has provided me with some more patches to fix some issues with promiscuous mode. I have not had time to look at those yet. [EMAIL PROTECTED] committed some extra PCI-IDs to sk(4) yesterday, you might want to fold those into DragonFly as well. cheers, Wilko -- | / o / /_ _ |/|/ / / /( (_) Bulte [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
hard lockup with new interrupt code, possible cause irq14: ata0
Hi! I have a problem with an SMP machine. The motherboard is a bp6. Mostly the machine already locksup during boot, it is not even resonding to serial console. One time i was able to login, i could see (in top) that this process root 20 0.0 0.0 0 12 ?? WL8:20PM 0:00.31 (irq14: ata0) started gaining all the cpu time and then the machine freezes. I tried a vmstat -i but about a second before it locks up there was nothing special there the rate for irq14: ata0 is 14 and there is a total of 1105. I tried booting in safe mode and without acpi, and there it still happens. The kernel was built from sources from about 10 hours ago. Attached you can find the output of a boot -v If you need anthing else let me know and i'll try to provide it as soon as i get up. Regards, flo Type '?' for a list of commands, 'help' for more detailed help. OK un bpo boot -v \|/-\|/SMAP type=01 base= len=0009fc00 SMAP type=01 base=0009fc00 len=0400 SMAP type=02 base=000f len=0001 SMAP type=02 base=fec0 len=1000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base= len=0001 SMAP type=01 base=0010 len=0fef SMAP type=03 base=0fff3000 len=d000 SMAP type=04 base=0fff len=3000 Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #77: Sat Nov 8 09:59:02 CET 2003 [EMAIL PROTECTED]:/space/obj/space/src/sys/BENDER Preloaded elf kernel /boot/kernel/kernel at 0xc07c. Preloaded acpi_dsdt /boot/bp6.aml at 0xc07c0250. MPTable: OEM0 PROD Calibrating clock(s) ... i8254 clock: 1193249 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 501138902 Hz CPU: Pentium II/Pentium II Xeon/Celeron (501.14-MHz 686-class CPU) Origin = GenuineIntel Id = 0x665 Stepping = 5 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 268369920 (255 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00829000 - 0x0fb49fff, 254939136 bytes (62241 pages) avail memory = 255336448 (243 MB) APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00fb110 bios32: Entry = 0xfb590 (c00fb590) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb5c0 pnpbios: Found PnP BIOS data at 0xc00fc1e0 pnpbios: Entry = f:c208 Rev = 1.0 Other BIOS signatures found: ioapic0: Assuming intbase of 0 ioapic0: intpin 0 - ExtINT (edge, activehi) ioapic0: intpin 1 - irq 1 (edge, activehi) ioapic0: intpin 2 - irq 2 (edge, activehi) ioapic0: intpin 3 - irq 3 (edge, activehi) ioapic0: intpin 4 - irq 4 (edge, activehi) ioapic0: intpin 5 - irq 5 (edge, activehi) ioapic0: intpin 6 - irq 6 (edge, activehi) ioapic0: intpin 7 - irq 7 (edge, activehi) ioapic0: intpin 8 - irq 8 (edge, activehi) ioapic0: intpin 9 - irq 9 (edge, activehi) ioapic0: intpin 10 - irq 10 (edge, activehi) ioapic0: intpin 11 - irq 11 (edge, activehi) ioapic0: intpin 12 - irq 12 (edge, activehi) ioapic0: intpin 13 - irq 13 (edge, activehi) ioapic0: intpin 14 - irq 14 (edge, activehi) ioapic0: intpin 15 - irq 15 (edge, activehi) ioapic0: intpin 16 - irq 16 (level, activelo) ioapic0: intpin 17 - irq 17 (level, activelo) ioapic0: intpin 18 - irq 18 (level, activelo) ioapic0: intpin 19 - irq 19 (level, activelo) ioapic0: intpin 20 - irq 20 (level, activelo) ioapic0: intpin 21 - irq 21 (level, activelo) ioapic0: intpin 22 - irq 22 (level, activelo) ioapic0: intpin 23 - irq 23 (level, activelo) ioapic0: intpin 1 trigger: edge ioapic0: intpin 1 polarity: active-hi ioapic0: Routing IRQ 0 - intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: active-hi ioapic0: intpin 3 trigger: edge ioapic0: intpin 3 polarity: active-hi ioapic0: intpin 4 trigger: edge ioapic0: intpin 4 polarity: active-hi ioapic0: intpin 5 trigger: edge ioapic0: intpin 5 polarity: active-hi ioapic0: intpin 6 trigger: edge ioapic0: intpin 6 polarity: active-hi ioapic0: intpin 7 trigger: edge ioapic0: intpin 7 polarity: active-hi ioapic0: intpin 8 trigger: edge ioapic0: intpin 8 polarity: active-hi ioapic0: intpin 9 trigger: edge ioapic0: intpin 9 polarity: active-hi ioapic0: intpin 13 trigger: edge ioapic0: intpin 13 polarity: active-hi ioapic0: intpin 14 trigger: edge ioapic0: intpin 14 polarity: active-hi ioapic0: intpin 19 trigger: level ioapic0: intpin 19
Re: hard lockup with new interrupt code, possible cause irq14: ata0
Try adding options NO_MIXED_MODE to your conf. That fixed boot-time hangs on my Asus A7M266-D. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd core dumped
On Sat, Nov 08, 2003 at 12:02:03PM +0100, Antoine Jacoutot wrote: Hi :) Are they any know issues with rpc.lockd under -CURRENT. I had a look at the gnats database and did not find anything related. I'm asking this because I have a lot of: kernel: pid 70065 (rpc.lockd), uid 0: exited on signal 11 (core dumped) Any idea ? I would be pleased to send more information but I didn't see where to find more debuging options for rpc.lockd. 5.1-CURRENT #0: Tue Nov 4 01:44:35 CET 2003 [EMAIL PROTECTED]:/usr/ obj/usr/src/sys/KERNSRV01 i386 Compile your rpc.lockd with -ggdb in the usual way (see the developer's handbook for more help on debugging application crashes). Is this repeatable? Kris pgp0.pgp Description: PGP signature
ATAPI-CD corruption since GEOMification ( possible fix)
With a -current built after atapi-cd was changed over to GEOM, reads
from a filesystem mounted on a CD device are being corrupted, with
junk being inserted into the file from offset 63489 onwards.
I had a quick look around atapi-cd.c, and I think I spotted the
problem: applying this patch certainly stopped the corruption
I was seeing. Anyone else seeing this? Can someone verify that
this is indeed the correct fix?
My CD device probes as:
acd1: CDRW CW088D ATAPI CD-R/RW at ata1-slave PIO4
If its of any interest.
Index: atapi-cd.c
===
RCS file: /usr/cvs/FreeBSD-CVS/src/sys/dev/ata/atapi-cd.c,v
retrieving revision 1.152
diff -u -r1.152 atapi-cd.c
--- atapi-cd.c 7 Nov 2003 08:31:09 - 1.152
+++ atapi-cd.c 8 Nov 2003 21:06:15 -
@@ -1018,7 +1018,7 @@
u_int pos, size = cdp-iomax - cdp-iomax % bp-bio_to-sectorsize;
struct bio *bp2;
- for (pos = 0; pos bp-bio_length; pos += bp-bio_length) {
+ for (pos = 0; pos bp-bio_length; pos += size) {
if (!(bp2 = g_clone_bio(bp))) {
bp-bio_error = ENOMEM;
break;
--
Peter Edwards.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tripwire Fails to build under 5.x
In message [EMAIL PROTECTED], Kris Kennaway writes: On Wed, Oct 01, 2003 at 03:49:30PM +0300, J8keR wrote: Does this mean wait until its fixed or am I missing some update ? It means wait until it's fixed, or fix it yourself and submit the patch. There are a lot of C++ issues with it, notably STLport issues. STLport that comes with tripwire does not build under -CURRENT. The STLport in the port collection is too new because tripwire depends on some unique quirks within the old STLport (as documented in their documentation -- STLport was too new and fluid so they chose to code for a specific version). I'm slowly but surely progressing. If people wish to expedite the process, I would welcome a patch. Cheers, -- Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ssh port forwarding changed under 5-CURRENT vs. STABLE?
On Thu, 06 Nov 2003, Aditya wrote: On Thu, Nov 06, 2003 at 03:29:21PM -0800, Kris Kennaway wrote: On Thu, Nov 06, 2003 at 01:43:43PM -0800, Aditya wrote: debug1: Connections to local port 8000 forwarded to remote address www.freebsd.org:80 debug1: Local forwarding listening on 127.0.0.1 port 8000. bind: Can't assign requested address channel_setup_fwd_listener: cannot listen to port: 8000 Could not request local forwarding. and I can't see any reason why the binding would fail: Is something else (e.g. another ssh session) already bound to that port? nope -- and I've tried all sorts of ports other than 8000 too: (I'm assuming you do have a lo0 device with 127.0.0.1) Have you tried binding it to the address on the interface which your host will send packets to the remote host over? -- David Taylor [EMAIL PROTECTED] The future just ain't what it used to be ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel halts before booting
My kernels now break into the debugger before booting!
Boot sequence goes like this:
...
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
cpuid = 0; apic id = 00
instruction pointer = 0x0:0xa00
stack pointer = 0x0:0xffe
frame pointer = 0x0:0x0
code segment= base 0x0, limit 0x0, type 0x0
= DPL 0, pres 0, def32 0, gran 0
processor eflags= interrupt enabled, vm86, IOPL = 0
current process = 0 ()
kernel: type 30 trap, code=0
stopped at 0xa00: cli
db cont
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #0: Fri Nov 7 17:17:10 EST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TEAM2
Preloaded elf kernel /boot/kernel/kernel at 0xc0751000.
MPTable: ASUSTEK0 P54NP400
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Pentium/P54C (132.00-MHz 586-class CPU)
Origin = GenuineIntel Id = 0x52c Stepping = 12
Features=0x3bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC
real memory = 134217728 (128 MB)
avail memory = 124928000 (119 MB)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
Intel Pentium detected, installing workaround for F00F bug
ioapic0: Assuming intbase of 0
ioapic0 Version 1.1 irqs 0-15 on motherboard
ACPI-0159: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TABLES
ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_TABLES
ACPI: table load failed: AE_NO_ACPI_TABLES
npx0: [FAST]
...
Also happens with GENERIC.
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ssh port forwarding changed under 5-CURRENT vs. STABLE?
On Sat, 08 Nov 2003, David Taylor wrote: Have you tried binding it to the address on the interface which your host will send packets to the remote host over? Erm, wait, I don't know what I was thinking there. ssh doesn't let you specify the local address it binds to. All I can say is it works here... However, changing the address on lo0 to 10.9.9.9 results in: debug1: channel 0: new [port listener] debug1: Local forwarding listening on 127.0.0.1 port 8000. bind: Can't assign requested address But: # ifconfig lo0 inet 127.0.0.1 $ ssh -L8000:www.freebsd.org:80 [host] gives [snip] debug1: channel 0: new [port listener] debug1: Local forwarding listening on 127.0.0.1 port 8000. debug1: fd 5 setting O_NONBLOCK debug2: fd 5 is O_NONBLOCK debug1: channel 1: new [port listener] So, it could be an idea to check the output of ifconfig lo0. -- David Taylor [EMAIL PROTECTED] The future just ain't what it used to be ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd core dumped
On Sat, 8 Nov 2003, Antoine Jacoutot wrote: Any idea ? I would be pleased to send more information but I didn't see where to find more debuging options for rpc.lockd. Check to make sure that rpc.statd is running. There was an old bug that rpc.lockd would dump core if it couldn't find a statd. -a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another 5.2 todo
Kris Kennaway wrote:
libm has been fixed, but there are several other libraries that either
need to get the same treatment or have their major version number
bumped.
See the attached mail.
Kris
Robert has offered to take care of libutil. We need someone to help
figure out the right approach for libncp and libopie. I'm tempted to
just bump their versions, but I'll wait for better wizdom from the
community first. Can anyone comment here?
I audited the results of my comparison script to look for other cases
of symbols being added to 5.x versions of libraries that have the same
version in 4.x, which do not resolve within this set of common
libraries. Here are the results:
== Comparing symbols in libisc.so.1
* pselect
Called from evGetNext(), which exists in 4.x's libisc. Perhaps libisc
is not widely used except for BIND applications.
== Comparing symbols in libm.so.2
* __fpclassifyd
* __fpclassifyf
Used in scalb() and scalf(), which exist on 4.x.
== Comparing symbols in libncp.so.1
* _getprogname
This is used in 5.x's ncp_getopt() and ncp_error() functions, which
also exist on 4.x.
== Comparing symbols in libopie.so.2
* __xuname
This is hidded inside the static uname() implementation in
sys/utsname.h and is referenced from opieinsecure() and
opienewseed(), which exist on 4.x.
== Comparing symbols in libutil.so.3
* __pw_scan
This one is OK because it is only used from pw_scan(), which does not
exist on 4.x.
* _time_to_time32
This is called from logout() on 5.x, which is a function also used in
4.x's libutil. For example, the following test application
demonstrates the breakage:
#include sys/types.h
#include libutil.h
main() {
logout(ttypa);
}
It runs correctly as root on 4.x, but gives the following as root on 5.x:
[EMAIL PROTECTED]:/home/kkenn /tmp/a
/usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol _time_to_time32
* mac_free
* mac_from_text
* mac_is_present
* mac_set_proc
These are called from setusercontext(), and might cause runtime
failures if a 4.x binary that uses setusercontext() is run on a 5.x
system that has MAC enabled.
Kris
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAPI-CD corruption since GEOMification ( possible fix)
V so, 08. 11. 2003 v 23:10, Peter Edwards pe: With a -current built after atapi-cd was changed over to GEOM, reads from a filesystem mounted on a CD device are being corrupted, with junk being inserted into the file from offset 63489 onwards. I had a quick look around atapi-cd.c, and I think I spotted the problem: applying this patch certainly stopped the corruption I was seeing. Anyone else seeing this? Can someone verify that this is indeed the correct fix? Yes, I see the corruption too. Yes, your fix works here. This is nasty! -- Pav Lucistnik [EMAIL PROTECTED] What do we know about love? Love is like a pear. Pear is sweet and have a specific shape. Try to exactly define the shape of a pear. -- Marigold: 50 Years Of Poetry signature.asc Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?= =?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?= =?ISO-8859-1?Q?_zpr=E1vy?=
build problems
I have had problems finishing buildworld and the problem is the same each time the build fails. It has failed 4 times at file:///usr/src/gnu/usr.bin/cvs/doc/. I have cvsuped 3 times in 2 days. I am running 5.1. Any info you might have would be helpful. Thanks, Jason ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build problems
On Sun, 09 Nov 2003 00:36:57 -0500 Jason [EMAIL PROTECTED] wrote: I have had problems finishing buildworld and the problem is the same each time the build fails. It has failed 4 times at file:///usr/src/gnu/usr.bin/cvs/doc/. I have cvsuped 3 times in 2 days. I am running 5.1. Any info you might have would be helpful. Thanks, Jason Are you using -02 optimizations in /etc/make.conf ? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hard lockup with new interrupt code, possible cause irq14: ata0
On Sat, 8 Nov 2003, Barney Wolff wrote: Try adding options NO_MIXED_MODE to your conf. That fixed boot-time hangs on my Asus A7M266-D. BTW, NO_MIXED_MODE is missing in NOTES. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
