parent interface. It calls if_addmulti() on it but temporarily sets the ioctl
hook to NULL. We need to account for that so we don't crash on multicast setup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34699 a95241bf-73f2-0310-859d-f6bbb57e9c96
- add the url to the empty image as a comment,
- add a .vmx for the nightly build.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34698 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use C++ comment styles.
* Use a common pointer orientation throughout the code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34693 a95241bf-73f2-0310-859d-f6bbb57e9c96
This gets rid of one layer of indirection, too.
Also, this removed a potential memory leakage, when deleting external memory
in destruct_pkt_mbuf. In the case where memory of type EXT_JUMBO9 was
previously allocated, this would have been wrongly catched by the condition
(ext_type & EXT_CLUSTER) != 0.
* Renamed some variables to more human readable style.
* Commented some constants in mbuf.h to make more clear what they indicate and
to show that they should not be treatet as flags, as it was the case one
some locations before.
* Removed the EXT_PACKET constant, as it requests the same cache as
EXT_CLUSTER. EXT_PACKET is a optimizing technique from BSD, where a cache
exists holding some preallocated mbuf + cluster memory. Such a thing is not
implemented in the compat layer, at all. Though EXT_CLUSTER tells more
clearly what the size of the external data buffer is.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34692 a95241bf-73f2-0310-859d-f6bbb57e9c96
also handles the M_PKTHDR flag. Before, the uninitialized fields could be left over
from earlier freed mbufs and on m_freem previous m_next fields could be returned
resulting in random mbufs being freed. This makes the iprowifi4965 work and fixes
#5089.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34691 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Cleaned up private method names as much as possible (it's probably not a good
idea to rename BStatable::set_stat() for compatibility reasons).
* Cleaned up sources.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34690 a95241bf-73f2-0310-859d-f6bbb57e9c96
that shows that something is obviously broken right now (I fixed some coding
style violations, though).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34689 a95241bf-73f2-0310-859d-f6bbb57e9c96
built for GCC4, though.
* Deleted the completely unused OldSoundFile.{cpp|h} files.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34688 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also check whether the port is closed after waiting.
* Don't increment read_count after waiting failed. That should have been the
cause of #5119.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34687 a95241bf-73f2-0310-859d-f6bbb57e9c96
* SetParameterValue(): Don't do anything, if the new output frequency value
is the same as before. This avoids hickups when switching between the pages
in the Media preflet.
* _FillNextBuffer(): Compare BBuffer and stream buffer size. They might
differ directly after setting another output frequency, which could cause
a crash.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34683 a95241bf-73f2-0310-859d-f6bbb57e9c96
as soon as a second thread got into the game: if a thread was notified that
a message is ready, another thread could call read_port() and steal it before
the previous thread could claim it. The "Extensions" menu still doesn't seem
to work, but I would guess that is unrelated.
* The threads of the test app never exited, as read_port() returns the number
of bytes it read, not just a status.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34681 a95241bf-73f2-0310-859d-f6bbb57e9c96
one more led, though), and the keys to be darker. I took this from the current
layout at the order page. The image on the main website is out of date. The
layout apparently was already up2date.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34677 a95241bf-73f2-0310-859d-f6bbb57e9c96
Renamed OpenTerminal to Open Terminal, since it sounds much more like a phrase
than a label for an add-on. Fixes#4434.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34676 a95241bf-73f2-0310-859d-f6bbb57e9c96
This driver was confirmed as working stable for a week by Algirdas Buckus.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34675 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Lithuanian Standard and Ergonomic keymaps added;
Patch by Algirdas Buckus. Thank you!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34674 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Round the DMA position for the buffer cycle computation. Apparently some
chipsets trigger the interrupt before the position has been updated.
- Don't just assume that stream->buffer_length frames have been processed
at that time. Use the exact stream position at that time. This makes the
performance time computation more precise and immune to the interrupt
being delayed.
* Init hda_stream::frames_count.
Audio skips on I/O seem to be gone for me, now. Not obviously motivated skips
still happen.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34671 a95241bf-73f2-0310-859d-f6bbb57e9c96
connect().
* This fixes not working connections whenever the incoming sa_len field happened
to be zero.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34669 a95241bf-73f2-0310-859d-f6bbb57e9c96
* static variables should start with s.
* function blocks should start on new line.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34668 a95241bf-73f2-0310-859d-f6bbb57e9c96
This probably fixes#2801 and is what the FreeBSD driver does.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34667 a95241bf-73f2-0310-859d-f6bbb57e9c96
This saves ~0.5s of boot time here, but I suspect it might be better for CD.
Enabled loadSymbols in kernel settings so the behavior should be the same as before this change.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34666 a95241bf-73f2-0310-859d-f6bbb57e9c96
descriptor n link position in buffer) registers. They contain "the number
of bytes that have been received off the link", which is not to be confused
with the number of bytes that have been transferred by the DMA engine.
The interrupt is triggered when the last byte of the buffer has been fetched
by the DMA engine, at which point the stream's LPIB is still somewhere in
the last buffer. So the interrupt handler could compute the wrong buffer
index, which would lead to the multi audio add-on filling the wrong
(currently being transferred) buffer, resulting in noisy sound. Now we use
the DMA position. Should fix#4072.
* Also removed the not (always) working hack-around for the "wrong" buffer
positions in the interrupt handler.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34664 a95241bf-73f2-0310-859d-f6bbb57e9c96
* There is firmware needed, which can be distributed with Haiku:
a) Get the firmware from www.ralinktech.com -> Software -> Linux
-> Firmware RT2501(RT2561/RT2661)
b) Extract the three binaries to /system/data/firmware/ralinkwifi/
c) Rename them by removing the '.bin' ending and append fw instead
(e.g.: rt2561.bin -> rt2561fw)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34663 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also note: the firmware needs to be installed in /system/data/firmware/marvell88w8335
and not malo8335 as I stated in commit r34661.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34662 a95241bf-73f2-0310-859d-f6bbb57e9c96
* This driver requires a firmware, which is not publicly available, and
therefor cannot distributed with Haiku. To retrieve and install the firmware
nonetheless following steps are required:
a) Download the firmware from http://www.nazgul.ch/malo/malo-firmware-1.4.tgz
b) Copy the included firmware files malo8335-h and malo8335-m to /system/data/firmware/malo8335/
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34661 a95241bf-73f2-0310-859d-f6bbb57e9c96
currently only shown in the monitor tool tip, that is now feels a bit crowded,
so a better solution would be nice. I'm hesitant to give it a more prominent
position, though, unless one has proof-read what the accelerants actually
return here.
* Added missing space between the serial number of the monitor and the date it
has been produced.
* Renamed fTempScreenMode to fUndoScreenMode, as it's only used to deliver that
functionality.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34659 a95241bf-73f2-0310-859d-f6bbb57e9c96
- enqueue_in_run_queue() no longer returns whether rescheduling is supposed
to happen. Instead is sets cpu_ent::invoke_scheduler on the current CPU.
- reschedule() does now handle cpu_ent::invoke_scheduler_if_idle(). No need
to let all callers do that.
* thread_unblock[_locked]() no longer return whether rescheduling is supposed
to happen.
* Got rid of the B_INVOKE_SCHEDULER handling. The interrupt hooks really
can't know, when it makes sense to reschedule or not.
* Introduced scheduler_reschedule_if_necessary[_locked]() functions for
checking+invoking the scheduler.
* Some semaphore functions (e.g. delete_sem()) invoke the scheduler now, if
they wake up anything with greater priority.
I've also tried to add scheduler invocations in the condition variable and
mutex/rw_lock code, but that actually has a negative impact on performance,
probably because it causes too much ping-ponging between threads when
multiple locking primitives are involved.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34657 a95241bf-73f2-0310-859d-f6bbb57e9c96
IORequest::Wait(). Wait() immediately returned when IsFinished() returned
true, but this is the case as soon as the last IOOperation has finished. The
I/O scheduler is not done with the request at this point, though, since it
will still be sitting in at least one of three doubly linked lists. Since the
usual procedure to issue synchronous I/O requests is to create an IORequest
on the stack, pass it to the I/O scheduler, and Wait() on it, Wait()
returning early might cause the IORequest object to be destroyed while it is
still in use, leading to invalid memory access in the I/O scheduler,
corruption of its list structures, as well as later corruption of the issuing
thread's stack.
Related tickets:
* #4431: The request issuing thread returned and already deleted the area the
request was writing to before NotifyFinished() was called.
* #3048, #4883: Caused by the on stack IORequest being overwritten with other
data while being handled by the I/O scheduler thread.
* #4517: Hard to say, but I've seen a such a problem too, after a thread
scheduling related change. An explanation would be a list structure
corruption in the I/O scheduler causing an infinite loop with disabled
interrupts.
* #2845, #3428, #3429: The block notifier/writer is I/O heavy and as such
quite likely to run into the stack corruption issue.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34655 a95241bf-73f2-0310-859d-f6bbb57e9c96
