silly gcc bug in RELENG_6
test.c:
typedef struct a astruct;
void
foobar(void)
{
int s = sizeof(astruct);
}
gcc test.c
test.c: In function `foobar':
test.c:6: error: invalid application of `sizeof' to incomplete type
`test.c'
Looks like someone goofed up some printf() args.
gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.4 [FreeBSD] 20050518
- Brian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Netgraph node, first steps in kernel land and a bloody crashdump
> OK, what we see here is that the printf call calls putchar() to print > the individual characters. The one it's printing now is 0x69 (frame > 7), lowercase 'i'. That's not in the (first) string passed to > printf(), but it could be in another parameter, or in the format > string. It's actually 69 decimal, or 'E', which would be consistent with the format string. Looking at line 355 of subr_prf.c, I'm going to hazard a guess that something smashed the value of v_putc, which should have been pointing to cnputc(). Could have been a stack smash inside cnputc, too, but I don't see any obvious way that could have happened. - Brian -- Brian Buchanan, CISSP [EMAIL PROTECTED] -- FreeBSD - The Power to Serve! http://www.freebsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wait()/alarm() race condition
On Sun, 30 Mar 2003, [ISO-8859-1] Mikko Työläjärvi wrote: > On Sun, 30 Mar 2003, Sean Hamilton wrote: > > > Dan Nelson wrote: > > | Just make sure your signal handler has the SA_RESTART flag unset > > | (either via siginterrupt() if the handler was installed with signal(), > > | or directly if the signal was installed with sigaction() ), and the > > | signal will interrupt the wait() call. > > > > Er, I think you've missed my problem. Or I'm not getting your solution. > > > > I'm concerned about this order of events: > > > > - alarm() > > - wait() returns successfully > > - if (alarmed...) [false] > > - SIGALRM is delivered, alarmed = true > > - loop > > - wait() waits indefinitely > > > > This is incredibly unlikely to ever happen, but it's irritating me somewhat > > that the code isn't airtight. Bad design. Surely there is some atomic means > > of setting a timeout on a system call. > > My stock solution to this kind of problem is to turn those pesky > signals into I/O and use an old fashioned select() loop to handle > them; create a pipe(2), let signal handlers write one-byte "messages" > (the signal number) into the pipe and then use select() to dequeue the > events (signals) from the pipe. > > Select() has a timeout parameter you can play with to your hearts > content, and provided you don't overflow the pipe, no events will > get lost. You'd have to install a hander for SIGCHLD, of course. Or how about kqueue(2) with EVFILT_SIGNAL. That would seem to be a more elegant solution. No signal handlers or alarm() required. -Brian -- Brian Buchanan, CISSP [EMAIL PROTECTED] -- FreeBSD - The Power to Serve! http://www.freebsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Tyan S4520 GCHE
I'm having problems getting SMP to work on a Tyan S4520 Thunder GCHE motherboard with 4x 1.9GHz Xeon processors: Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 16 pins in IOAPIC #1 Programming 16 pins in IOAPIC #2 AP #1 (PHY# 2) failed! panic y/n? [y] AP #2 (PHY# 4) failed! panic y/n? [y] AP #3 (PHY# 6) failed! panic y/n? [y] This is under FreeBSD 4.7-RELEASE. I also tried a recent -STABLE build and 5.0-RELEASE, with the same results. I've attached the "mptable -dmesg" output in the hopes that someone with more SMP knowledge might be able to give me some information as to what's wrong. Any help is much appreciated. Brian === MPTable, version 2.0.15 --- MP Floating Pointer Structure: location: BIOS physical address: 0x000f7450 signature:'_MP_' length: 16 bytes version: 1.4 checksum: 0x36 mode: Virtual Wire --- MP Config Table Header: physical address: 0x0009f170 signature:'PCMP' base table length:428 version: 1.4 checksum: 0x54 OEM ID: 'RCC ' Product ID: 'GCHE SERVER ' OEM table pointer:0x OEM table size: 0 entry count: 42 local APIC address: 0xfee0 extended table length:304 extended table checksum: 242 --- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model StepFlags 0 0x14BSP, usable 15 2 2 0x3febfbff 2 0x14AP, usable 15 2 2 0x3febfbff 4 0x14AP, usable 15 2 2 0x3febfbff 6 0x14AP, usable 15 2 2 0x3febfbff -- Bus:Bus ID Type 0 PCI 1 PCI 2 PCI 3 PCI 4 PCI 5 PCI 6 PCI 7 PCI 8 PCI 9 PCI 10 PCI 11 ISA -- I/O APICs: APIC ID Version State Address 8 0x11usable 0xfec0 9 0x11usable 0xfec01000 10 0x11usable 0xfec02000 -- I/O Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# ExtINT active-hiedge 11 0 80 INT active-hiedge 11 1 81 INT active-hiedge 11 0 82 INT active-hiedge 11 3 83 INT active-hiedge 11 4 84 INT active-hiedge 11 5 85 INT active-hiedge 11 6 86 INT active-hiedge 11 7 87 INT active-hiedge 11 8 88 INT active-hiedge 11 9 89 INT active-hiedge 1110 8 10 INT active-hiedge 1111 8 11 INT active-hiedge 1112 8 12 INT active-hiedge 1113 8 13 INT active-hiedge 1114 8 14 INT active-hiedge 1115 8 15 INT active-lo level0 10:A 10 13 INT active-lo level0 11:A 10 14 INT active-lo level0 12:A 10 15 INT active-lo level7 9:A 103 INT active-lo level7 9:B 104 -- Local Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# ExtINT active-hiedge 11 02550 NMI active-hiedge 11 02551 --- MP Config Extended Table Entries: -- System Address Space
Changes to IP fragment handling between 4.3 and 4-STABLE?
4.3-RELEASE seems to be vulnerable to a network denial of service condition when either IPF or IPFW is compiled into the kernel (or IPFW loaded as a kernel module) and the host is sent a large volume of fragmented packets. At this point, the scope of my testing has been limited to the packets generated by tfgen, a Windows traffic-generation program which spews large, fragmented UDP packets. 4-STABLE does not seem to be affected by this condition when configured with no firewall or with IPFW loaded as a kernel module. In all cases, IPFW was tested with the single rule "1 allow ip from any to any". The denial of service condition observed is that while receiving fragmented UDP packets at around 30Mbps on a 100Mbps interface, the host's network responsiveness drops to just about zero. So I suspect that 4.3-RELEASE has a bug either in both packet filters or in the common code connecting the filters into the IP stack. I'd like to know which is the case and in what files/revisions the bug was fixed, but my search through freebsd-hackers and freebsd-commit didn't turn up anything. Perhaps someone with familiarity with the code in question can give me a pointer. Thanks, Brian --- Brian Buchanan <[EMAIL PROTECTED]> Senior Software Engineer nCircle Network Security, Inc.http://www.ncircle.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCMCIA ATA flash broken in 4.5-RC
On Fri, 18 Jan 2002, M. Warner Losh wrote: > Try creating an entry that matches your card: > > card "CL ATA FLASH CARD LEXAR " "TIDALWV" > config "ata" 0x1 ? Warner, I added the pccard.conf entry: card "CL ATA FLASH CARD LEXAR " "TIDALWV" config 0x1 "ata" ? That did the trick. Thanks! Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PCMCIA ATA flash broken in 4.5-RC
I have an ATA compact flash which I used to be able to put into a PCMCIA
adapter and successfully mount under 4.3-RELEASE. Since CVSuping to
4.5-RC as of Wednesday, I get the following when I insert the card:
Jan 18 10:44:10 europa /kernel: pccard: card inserted, slot 0
Jan 18 10:44:16 europa pccardd[670]: Card "CL ATA FLASH CARD LEXAR
"("TIDALWV") [SH003] [(null)] matched "CL ATA FLASH CARD LEXAR "
("TIDALWV") [(null)] [(null)]
Jan 18 10:44:21 europa pccardd[670]: driver allocation failed for CL ATA
FLASH CARD LEXAR (TIDALWV): Device not configured
And when I remove it:
Jan 18 10:44:37 europa /kernel: pccard: card removed, slot 0
Jan 18 10:44:37 europa pccardd[670]: ata0: CL ATA FLASH CARD LEXAR
(TIDALWV) removed.
FreeBSD 4.5-RC #0: Wed Jan 16 11:21:46 PST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/EUROPA
pcic0: mem 0x5000-0x5fff irq 11
at device 2.0 on pci0
pcic0: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][FUNC
pci int + CSC serial isa irq]
pccard0: on pcic0
pcic1: mem 0x5010-0x50100fff irq 11
at device 2.1 on pci0
pcic1: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][FUNC
pci int + CSC serial isa irq]
pccard1: on pcic1
Any further information I can provide to help diagnose this? Anything
else I can try to get it working?
Thanks!
---
Brian Buchanan <[EMAIL PROTECTED]>
nCircle Network Security
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
