Re: X11 crash on exit
Garrett Cooper wrote:
I implemented the fix I suggested earlier (scanning
the WindowTable to remove Window objects as they're
deleted) and it does consistently resolve the crash,
but now the X server restarts itself when xinit asks
it to exit, so there's clearly still something amiss.
Patch attached for anyone interested.
Patch, what patch?
-Garrett
Apologies. Patch pasted below (for mailing list) and attached (for
direct addressees):
--- dix/window.c.orig 2009-10-11 19:52:40.0 -0700
+++ dix/window.c2010-03-14 00:02:18.0 -0800
@@ -936,6 +936,7 @@
WindowPtr pParent;
WindowPtr pWin = (WindowPtr)value;
xEvent event;
+int i;
UnmapWindow(pWin, FALSE);
@@ -964,6 +965,13 @@
xfree(dixLookupPrivate(&pWin->devPrivates, FocusPrivatesKey));
dixFreePrivates(pWin->devPrivates);
xfree(pWin);
+
+for (i = 0; i < MAXSCREENS; ++i)
+{
+ if (WindowTable[i] == pWin)
+ WindowTable[i] = NullWindow;
+}
+
return Success;
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Sat, 13 Mar 2010 16:55:58 -0800 Weongyo Jeong wrote: > On Sat, Mar 13, 2010 at 11:12:05PM +0200, Alex RAY wrote: > > On Fri, 12 Mar 2010 15:13:34 -0800 > > Weongyo Jeong wrote: > > > > > > > > I thought that your opinion was right and if mem is > > > 0xf400-0xf4003fff (16 Kb) I thought the device has 4 cores. However > > > it looks this was wrong according to the below document: > > > > > > http://voodoowarez.com/bcm5365p.pdf > > > > > > Please see Section 3: PCI Core, PCI Bus (Page 34) that it indicates that > > > 16Kb, maybe 8 Kb in the old devices is core register region. > > > > > > "Accesses to the lower half of the core register region are translated > > >into system backplane accesses using the PCIBAR0Window register" > > > "Accesses to offsets 0x1000 to 0x17FF of this region initiate a direct > > >access to the external SPROM" > > > > > > If we just access memory using offset + core and bus_space_read_x > > > interfaces it would actually not access core register region. > > > > > > So without solving this problem it looks it could not remove coreswitch > > > routines. > > > > > > regards, > > > Weongyo Jeong > > > > > > > Hi, > > > > this document about SoC BCM5365P, not about PCI device with PCI to SSB > > bridge. > > Yes it's about SoC BCM5365P but I think the basic concept of Silicon > Backplane would be same at a PCI device with PCI to SSB bridge. > > > I know in SoC`s like BSM5365 (I test it in BCM5354 and BCM5836) core > > switching is not required. > > > > BCM5354 - > > http://lists.freebsd.org/pipermail/freebsd-mips/2009-June/000421.html > > BCM5836 - > > http://lists.freebsd.org/pipermail/freebsd-mips/2010-February/000635.html > > The above URLs you mentioned indicates that > > siba0: at mem 0x1800-0x18006fff on > nexus0 > siba_cc0: at mem 0x1800-0x18000fff irq 0 on siba0 > bfe0: at mem 0x18001000-0x18001fff irq 1 on > siba0 > siba_mips0: at mem 0x18002000-0x18002fff on siba0 > ohci0: at mem 0x18003000-0x18003fff irq 4 on > siba0 > > siba0 used memory region at starting 0x1800 that I think this is a > reason why it doesn't require core switching and each cores have their > own memory region at starting 0x1800. > > But in a case of PCI device with PCI to SSB bridge, it normally used > 0xf400, 0xfe20 or other address which reserved by parent PCI > bridge. > > > With PCI device, when device report memory window > > 0xf400-0xf4003fff, why we can`t use full window? > > Because I'm not a Silicon Backplane expert I could not answer this > question. But I'd like to make sure that memory window at 0xf400 > (size 16 Kbytes) comes from PCI BAR0 when pci(4) attached device. > Moreover I believe size of memory window also comes from PCI BAR0 size > testing of pci(4). > > Of course I think we can try to remap full memory window after > calculating numbers of core but it looks meaning would be little bit > different. > > > May be You can test your code without core switching? > > I tried to remove core switching code in siba_bwn bridge but after > moment I got stuck to go forward. For example, > > I have 1 device which attached with bwn(4) and it has 4 cores: > > 0x1800-0x18000fff ChipCommon > 0x18001000-0x18001fff EMAC > 0x18002000-0x18002fff PCI > 0x18003000-0x18003fff PCMCIA > > When it attached at siba_bwn it shows its memory region at 0xfe2fe000 - > 0xfe2f (8 Kbytes). Initial PCI BAR0 value was 0x18002000. Yes, You're right. I found another way. We can use SBtoPCITranslation2 (Offset 0x108) register, in that way we can access to SSB without coreswitching. (Page 42) Initial access for copy SPROM and preconfigure make via BAR0, then setup SBtoPCITranslation2 and access to SSB direct. > > If your opinion is right the memory region for full window should be > 0xfe2fe000 - 0xfe301fff (16 Kb for 4 core, each core consumes 0x1000 > size) > > Even if I tried to remap memory region from 0xfe2fe000 to 0xfe301fff and > setting PCI BAR0 to 0x1800, another problem is occurred for reading > SPROM data. To access external SPROM it could be possible to access > bus_space_read_2(bt, bh, 0x1000 ~ 0x17ff) at ChipCommon core. But > accessing register in a core could not over 0xfff because maximum size > of a core limited within 0x1000. > > That means internally in Silicon Backplane it has a special meaning if > it try to access over 0x1000 or 0x2000 which mentioned a quote at > Section 3: PCI Core, PCI Bus (Page 34). > > I guess you're thinking that we could access EMAC core using > bus_space_read_2(bt, bh, 0x1000 ~ 0x1fff) after setting full memory > window. But it looks it's not possible. > > regards, > Weongyo Jeong -- Alex RAY ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr
Re: X11 crash on exit
Peter Jeremy wrote: On 2010-Mar-14 00:04:21 -0800, Tim Kientzle wrote: Okay, I've updated a bunch of ports and am still seeing the crash. I rebuilt the server with debug symbols and finally got something informative; here's the relevant portion of the backtrace (frame #10 is the signal 11 delivery). #11 0x0819e363 in DeliverPropertyEvent (pWin=0x5a5a5a5a, value=0xbfbfec0c) at rrproperty.c:34 #12 0x0807015d in TraverseTree (pWin=0x28775f80, func=0x819e340 , data=0xbfbfec0c) at window.c:234 #18 0x0806f4e3 in FreeAllResources () at resource.c:824 #19 0x0806bbf0 in main (argc=4, argv=0xbfbfed68, envp=0xbfbfed7c) at main.c:411 This looks identical to the problem I reported as ports/131930. Whilst my patch wasn't applied, ISTR a similar patch got applied upstream to fix the issue. I've run through portsnap/portupgrade a few times, so my server should be up-to-date and I still see the crash. I suspect the upstream patch you're referring to would be the memset(WindowTable, 0, sizeof()) that appears a few lines after the call that triggers the crash. Other than that, I can confirm that you _can_ run X on an AA1, at least on 8.x (that's what I'm currently using). What window manager are you using? Right now, I'm using TWM but suspect there's something a bit better suited to this small screen. (Ideally, something that adapts well to either the built-in screen or the external 20" monitor I often use.) Are you using hal/dbus? Yes. I implemented the fix I suggested earlier (scanning the WindowTable to remove Window objects as they're deleted) and it does consistently resolve the crash, but now the X server restarts itself when xinit asks it to exit, so there's clearly still something amiss. Patch attached for anyone interested. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: X11 crash on exit
On 2010-Mar-14 00:04:21 -0800, Tim Kientzle wrote: >Okay, I've updated a bunch of ports and am still seeing the >crash. I rebuilt the server with debug symbols and finally >got something informative; here's the relevant portion of >the backtrace (frame #10 is the signal 11 delivery). > >#11 0x0819e363 in DeliverPropertyEvent (pWin=0x5a5a5a5a, >value=0xbfbfec0c) at rrproperty.c:34 >#12 0x0807015d in TraverseTree (pWin=0x28775f80, func=0x819e340 >, data=0xbfbfec0c) at window.c:234 >#13 0x08070206 in WalkTree (pScreen=0x2871f8c0, func=0x819e340 >, data=0xbfbfec0c) at window.c:262 >#14 0x0819e521 in RRDeliverPropertyEvent (pScreen=0x2871f8c0, >event=0xbfbfec0c) at rrproperty.c:63 >#15 0x0819e5a0 in RRDeleteAllOutputProperties (output=0x28778340) at >rrproperty.c:81 >#16 0x0819d2b7 in RROutputDestroyResource (value=0x28778340, pid=60) at >rroutput.c:414 >#17 0x0806f3d0 in FreeClientResources (client=0x287180c0) at resource.c:807 >#18 0x0806f4e3 in FreeAllResources () at resource.c:824 >#19 0x0806bbf0 in main (argc=4, argv=0xbfbfed68, envp=0xbfbfed7c) at >main.c:411 This looks identical to the problem I reported as ports/131930. Whilst my patch wasn't applied, ISTR a similar patch got applied upstream to fix the issue. My ports tree is currently in somewhat of a mess (I've installed the Xorg 7.5 patches) so I can't quickly check. Other than that, I can confirm that you _can_ run X on an AA1, at least on 8.x (that's what I'm currently using). Are you using hal/dbus? -- Peter Jeremy pgppUmaYd3NEI.pgp Description: PGP signature
Re: A tool for remapping bad sectors in CURRENT?
On Sun, 14 Mar 2010 17:18:45 +0100 Miroslav Lachman <000.f...@quip.cz> wrote: > Gary Jennejohn wrote: > > On Sun, 14 Mar 2010 10:55:19 +0100 > > Miroslav Lachman<000.f...@quip.cz> wrote: > > > > [big snip] > >> fsdb (inum: 3)> blocks > >> Blocks for inode 3: > >> Direct blocks: > >> 3001 (1 frag) > >> > >> fsdb (inum: 3)> findblk 3001 > >> fsdb (inum: 3)> > >> > >> findblk did not returned inode 3! > >> > > > > This is almost guaranteed to be a file system block and not > > a disk block. > > Do you mean the number 3001? > I am sorry for my ignorance, but it is not clear to me from fsdb manpage > what "blocks" means FS block and what disk block. > > And how can I use (calculate with) this numbers? > > How can I get the right number to pass to findlbk command (in the > example above) to give me back the inode 3? > > If FS block is 16384 bytes, then it means 16384/512 = 32 disk blocks per > FS block. > > If 3001 is FS block, then it means 3001*32 = 96032 disk block number. Am > I right? > > fsdb (inum: 3)> findblk 96032 > fsdb (inum: 3)> > > Again - findblk did not returned inode 3. > > So what is the exact formula to get the right findblk number and then > right inode number as result of findblk command? > > I am still lost in terms (words) and numbers :( > Well, it's pretty hairy. Looking at findblk() it does this to go from disk block to file system block (this is greatly simplified) file_system_blockno = disk_blockno >> fs_fsbtodb; So conversely, you'd do disk_blockno = file_system_blockno << fs_fsbtodb. You can get this information using "ffsinfo -l 0x001 -o some_file /dev/ataXY" (using ahci) and grep'ing for fsbtodb in some_file. The 0x001 means to only dump the first super block. I looked at a file system which has default 16kB file system blocks and fsbtodb is 2 ==> *multiply file_system_block by 4 not 32*. This is probably because it's a multiple of a 4kB block, which is the smallest usable file system block size AFAIK. BTW looking at the code leads me to conclude that fsdb will not print out anything if the disk block you're trying to find has bever been allocated to an inode ==> unused disk block, safe to overwrite. This assumes that you calculated the disk block correctly. --- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A tool for remapping bad sectors in CURRENT?
Gary Jennejohn wrote: On Sun, 14 Mar 2010 10:55:19 +0100 Miroslav Lachman<000.f...@quip.cz> wrote: [big snip] fsdb (inum: 3)> blocks Blocks for inode 3: Direct blocks: 3001 (1 frag) fsdb (inum: 3)> findblk 3001 fsdb (inum: 3)> findblk did not returned inode 3! This is almost guaranteed to be a file system block and not a disk block. Do you mean the number 3001? I am sorry for my ignorance, but it is not clear to me from fsdb manpage what "blocks" means FS block and what disk block. And how can I use (calculate with) this numbers? How can I get the right number to pass to findlbk command (in the example above) to give me back the inode 3? If FS block is 16384 bytes, then it means 16384/512 = 32 disk blocks per FS block. If 3001 is FS block, then it means 3001*32 = 96032 disk block number. Am I right? fsdb (inum: 3)> findblk 96032 fsdb (inum: 3)> Again - findblk did not returned inode 3. So what is the exact formula to get the right findblk number and then right inode number as result of findblk command? I am still lost in terms (words) and numbers :( Miroslav Lachman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A tool for remapping bad sectors in CURRENT?
On Sun, 14 Mar 2010 10:55:19 +0100 Miroslav Lachman <000.f...@quip.cz> wrote: [big snip] > fsdb (inum: 3)> blocks > Blocks for inode 3: > Direct blocks: > 3001 (1 frag) > > fsdb (inum: 3)> findblk 3001 > fsdb (inum: 3)> > > findblk did not returned inode 3! > This is almost guaranteed to be a file system block and not a disk block. --- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A tool for remapping bad sectors in CURRENT?
Dag-Erling Smørgrav wrote:
Miroslav Lachman<000.f...@quip.cz> writes:
So... can somebody with enough knowledge write some docs / script how
to find the affected file based on LBA read error from messages /
SMART log?
ZFS will tell you straight away, but I guess if you used ZFS, you
wouldn't be asking :)
Yes, but we have ZFS only on two servers, others are using UFS2 (some
with gmirror, some with gjournal)
For FFS, you can unmount the file system (boot from a CD or memory stick
or whatever if that file system is / or /usr), run fsdb on the failing
disk, use findblk to look up the inode number for the file that contains
the bad sector. Note that you have to convert the LBA to an offset
relative to the start of the partition.
As I write in my first post to this thread, I already tried fsdb +
findblk, but without success. Findblk did not returned any inode. Maybe
the meaning of block is of different size or something else I can't
understand.
So can you please show me some real world example?
I have one from the past:
__
/var/log/messages:
Sep 23 23:58:00 edith kernel: ad4: FAILURE - READ_DMA
status=51 error=40 LBA=79725056
Sep 23 23:58:00 edith kernel: GEOM_MIRROR: Request failed (error=5).
ad4[READ(offset=40819228672, length=131072)]
__
SMART log:
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 6f 82 c0 44 Error: UNC at LBA = 0x04c0826f = 79725167
The LBA of bad sector is *79725167*
__
Information about disk slices:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 209712447 (102398 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 254/ sector 63
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 209712510, size 1743807555 (851468 Meg), flag 0
beg: cyl 1023/ head 255/ sector 63;
end: cyl 1023/ head 254/ sector 63
__
According to LBA and size of s1, I thing the error is in s1
# /dev/mirror/gm0s1:
8 partitions:
#size offsetfstype [fsize bsize bps/cpg]
a: 20971520/
b: 25165824 2097152swap
c: 2097124470
d: 12582912 27262976/var
e: 146800640 39845888 /var/db
f: 16777216 186646528 /usr
g: 6288703 203423744 /tmp
And LBA 79725056 is on */var/db* (between offset 39845888 and 186646528)
__
s1 starts 63 sectors from the beginning of the drive and /var/db has
offset 39845888. So am I right that I need to find block number
*39879105* by findblk command?
LBA err - s1 start - /var/db offset = findblk inside /dev/mirror/gm0s1e
79725056 - 63 - 39845888 = 39879105
__
/# fsdb -r /dev/mirror/gm0s1e
** /dev/mirror/gm0s1e (NO WRITE)
Examining file system '/dev/mirror/gm0s1e'
Last Mounted on /var/db
current inode: directory
I=2 MODE=40755 SIZE=512
BTIME=May 1 08:07:23 2009 [0 nsec]
MTIME=Sep 24 15:52:01 2009 [0 nsec]
CTIME=Sep 24 15:52:01 2009 [0 nsec]
ATIME=Sep 24 16:24:34 2009 [0 nsec]
OWNER=root GRP=wheel LINKCNT=11 FLAGS=0 BLKCNT=4 GEN=4ebc65fc
findblk 39879105
findblk 39879106
findblk 39879107
findblk 39879108
.
.
I tried more than 256 incrementing block numbers, but findblk didn't
found any inode! (length=131072 in error message means 256 sectors, right?)
So there must be some misunderstanding on my part and that's why I am
asking for some step-by-step documentation or script "how to find file
by LBA read error message"
I tried the fsdb + findblk on well known data, but again without success.
I created file /tmp/test.txt, it has inum 3, than I use fsdb on gm0s1f
(gm0s1f is mounted as /tmp). Command "inode 3" inside fsdb prompt
returned informations about this file, command "blocks" returned 3001 as
block number, but command "findblk 3001" returned nothing instead of
inum 3!
Where is the error? What I am doing wrong?
__
~/# echo test > /tmp/test.txt
~/# ls -i /tmp/test.txt
3 /tmp/test.txt
~/# fsdb -r /dev/mirror/gm0s1f
** /dev/mirror/gm0s1f (NO WRITE)
Examining file system '/dev/mirror/gm0s1f'
Last Mounted on /tmp
current inode: directory
I=2 MODE=41777 SIZE=512
BTIME=Feb 7 18:32:22 2008 [0 nsec]
MTIME=Mar 14 10:33:22 2010 [0 nsec]
CTIME=Mar 14 10:33:22 2010 [0 nsec]
ATIME=Mar 14 10:33:35 2010 [0 nsec]
OWNER=root GRP=wheel LINKCNT=7 FLAGS=0 BLKCNT=4 GEN=3f7c9384
fsdb (inum: 2)> inode 3
current inode: regular file
I=3 MODE=100644 SIZE=5
BTIME=Mar 14 10:33:22 2010 [0 nsec]
MTIME=Mar 14 10:33:22 2010 [0 nsec]
CTIME=Mar 14 10:33:22 2010 [0 nsec]
ATIME=Mar 14 10:33:22 2010 [0 nsec]
OWNER=root GRP=wheel LINKCNT=1 FLAGS=0 BLKCNT=4 GEN=45c26de1
fsdb (inum: 3)> blocks
Blocks for inode 3:
Direct blocks:
3001 (1 frag)
fsdb (inum: 3)> findblk 3001
fsdb (inum: 3)>
findblk did not returned inode 3!
Unfortunately, you can't e
Re: X11 crash on exit
On Wed, Mar 10, 2010 at 10:40 PM, Tim Kientzle wrote: Trying to get X up and running on my Aspire One netbook and having a couple of problems. Here's the first: Whenever I exit, the server gets a Signal 11 and crashes ... FreeBSD 9.0-CURRENT r201154M: Tue Dec 29 09:27:29 PST 2009 GENERIC i386 xorg.conf is pretty vanilla except for the two monitors: 1600x1200 external on the VGA connector and 1024x600 LVDS display. This was autoprobed by the server: Section "Device" Identifier "Card0" Driver "intel" VendorName "Intel Corporation" BoardName "Mobile 945GME Express Integrated Graphics Controller" BusID "PCI:0:2:0" Option "monitor-LVDS" "LVDSMonitor" Option "monitor-VGA" "VGAMonitor" EndSection Okay, I've updated a bunch of ports and am still seeing the crash. I rebuilt the server with debug symbols and finally got something informative; here's the relevant portion of the backtrace (frame #10 is the signal 11 delivery). #11 0x0819e363 in DeliverPropertyEvent (pWin=0x5a5a5a5a, value=0xbfbfec0c) at rrproperty.c:34 #12 0x0807015d in TraverseTree (pWin=0x28775f80, func=0x819e340 , data=0xbfbfec0c) at window.c:234 #13 0x08070206 in WalkTree (pScreen=0x2871f8c0, func=0x819e340 , data=0xbfbfec0c) at window.c:262 #14 0x0819e521 in RRDeliverPropertyEvent (pScreen=0x2871f8c0, event=0xbfbfec0c) at rrproperty.c:63 #15 0x0819e5a0 in RRDeleteAllOutputProperties (output=0x28778340) at rrproperty.c:81 #16 0x0819d2b7 in RROutputDestroyResource (value=0x28778340, pid=60) at rroutput.c:414 #17 0x0806f3d0 in FreeClientResources (client=0x287180c0) at resource.c:807 #18 0x0806f4e3 in FreeAllResources () at resource.c:824 #19 0x0806bbf0 in main (argc=4, argv=0xbfbfed68, envp=0xbfbfed7c) at main.c:411 As you can see, the main loop is calling FreeAllResources at a time when the Window pointed to by WindowTable[0] has already been freed. I'm running with MALLOC_OPTIONS=J, so the Window structure was filled with 'Z' at that time, leading eventually to this crash when pWin->firstChild was dereferenced. I haven't yet tracked down exactly when the window in question was freed, so I'm not yet sure about the best fix. My current guess: DeleteWindow in dix/window.c should search WindowTable[] to see if the window being deleted is in the window table and remove it if so. I haven't looked carefully enough at the code yet to know whether it suffices to just set the corresponding WindowTable[] entry to NULL. I'll try that and let you know. Cheers, Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
